Mes: noviembre 2023

Nov

2023

PRE INSTALACIÓN DE SQL SERVER: Buenas prácticas

Hola, amigos y amigas del blog. Hoy vamos a hablar sobre algunos aspectos a tener en cuenta y las buenas prácticas antes de instalar SQL Server. Sé que a muchos os puede parecer una tarea trivial pero es clave para el rendimiento futuro de nuestro servidor, no queremos que nuestra instalación termine siendo un desastre, ¿verdad?

Lo primero que hay que hacer es verificar los requisitos mínimos del sistema para instalar SQL Server. No vaya a ser que nos quedemos sin espacio en el disco duro, o que nuestra memoria RAM no dé la talla. Para eso, podemos consultar la documentación oficial de Microsoft, o usar alguna herramienta como el Asistente de instalación de SQL Server, que nos ayuda a comprobar si nuestro equipo cumple con los requisitos.

Lo segundo que hay que hacer es planificar la configuración de SQL Server. Esto implica decidir qué características vamos a instalar, cómo vamos a organizar las instancias y las bases de datos, qué tipo de autenticación vamos a usar, cómo vamos a configurar la seguridad y el rendimiento, y otras opciones más. Para esto, yo siempre tengo en cuenta estos 4 puntos fundamentales:

ENTORNO

Se debe intentar que los servidores SQL sean dedicados, solo deben alojar aplicaciones de SQL server. En caso de que por necesidades de un aplicativo en SQL deba convivir con otros servicios de terceros debemos extremar la vigilancia sobre el rendimiento y la seguridad. Si seguimos las buenas prácticas de Microsoft, SQL Server no se instalará en ningún caso sobre un servidor que albergue el rol de controlador de dominio. Tampoco es recomendable instalar más de una instancia en un mismo servidor, si lo hacemos deberemos jugar después con resource governor para asegurarnos que el rendimiento de las instancias es el deseado.

SISTEMA OPERATIVO

La instalación de SQL Server se puede hacer sobre entornos Windows Server o Windows de usuario. Desde SQL Server 2017 también es posible instalar SQL Server sobre entornos Linux aunque en este caso es posible que no tengamos disponibles todas las características. En el caso de un sistema operativo Mac no hay soporte nativo, sin embargo, es posible beneficiarse de la posibilidad de instalación de SQL Server sobre contenedores Docker para tener una instancia funcional en estos entornos.

En caso de una instalación de un entorno de alta disponibilidad debe existir un Windows Server Failover Cluster entre los servidores o en el caso de Linux un clúster pacemaker.

DISCOS DUROS

Según las buenas prácticas, todo servidor SQL debe tener al menos 4 discos, uno para el sistema operativo y los de SQL: datos, log, y TempDB. Adicionalmente podrán existir más discos de datos o logs. A la hora de dimensionar los discos debemos dimensionar el disco de datos de manera que tenga capacidad suficiente para los datos actuales y futuros a medio plazo (en un mundo ideal este dato nos lo dará el equipo que solicita el servidor). Los discos de TempDB y Log deberán ser entre el 10 y el 30% de la capacidad total de los datos.

Si no nos ha quedado más remedio que instalar nuestro SQL en un servidor compartido con aplicaciones, estas deberemos instalarlas en un disco independiente a SQL Server. Del mismo modo, no es buena idea compartir discos duros entre varias instancias de SQL Server.

Para terminar con el apartado de discos duros, todos los discos de SQL server deben estar formateados con el valor bytes per cluster a 64kb. Para comprobarlo podemos ejecutar el siguiente comando de powershell: “fsutil fsinfo ntfsinfo <drive>”

SEGURIDAD

En un entorno dedicado para SQL Server solo los administradores del sistema operativo y los DBAs deberían tener acceso. Los servicios de SQL deben ejecutarse bajo cuentas de servicio que cumplan con las políticas de seguridad. En este sentido, tenemos que tener en cuenta que las cuentas que configuremos para el motor de bases de datos y para el agente de SQL Server deberán tener permisos sobre los directorios de datos o backups en función de lo que esperemos hacer en un futuro.

Con todo esto definido ya habríamos terminado de prepararnos y podemos pasar a descargar la versión de SQL que más se adapte a nuestras necesidades y, por fin, a instalar, que en este punto ya estaréis todos deseosos de empezar a cacharrear.

Esto sería todo por hoy, espero que os haya gustado este post sobre los aspectos a tener en cuenta y las buenas prácticas antes de instalar SQL Server. Si han quedado dudas o tenéis algún comentario, no dudéis en dejarlo abajo. Y si os ha gustado, compartidlo con vuestros colegas DBAs. Hasta la próxima.

Nov

2023

Tipos de datos numéricos en SQL Server

Recientemente un cliente me pidió ayuda porque uno de sus campos numéricos pierde precisión con los decimales. Como me parece muy importante quiero aprovechar para aclarar conceptos, es algo complejo, pero voy a tratar de dejarlo lo más claro posible. Como sabemos tenemos varios tipos de datos que nos van a permitir almacenar números en SQL Server. Vamos a ir viendo uno a uno, pero antes tenemos que saber que significan una serie de conceptos. Los tipos de datos en SQL Server tienen 3 cualidades:

PRECISIÓN: Cantidad máxima de dígitos que puede tener en total (entero + decimal).
ESCALA: Cantidad máxima de dígitos después del decimal que puede tener.
PRECISION_RADIX: Especifica la potencia en la que se expresa la precisión, admite los valores 2 o 10, luego profundizamos más sobre esto.

Ahora sí, los tipos de datos, partamos de esta imagen y vamos viendo en detalle:

Tipos de Datos: BIGINT, INT, SMALLINT y TINYINT

Estos tipos de datos se usan para almacenar datos numéricos exactos y enteros. NO ADMITEN DECIMALES. Tenemos que usar uno u otro en función de nuestras necesidades, aunque, siempre es recomendable el más pequeño posible para ahorrar espacio en disco y ganar rendimiento. Por ejemplo, para un valor de edad de una persona con un tinyint es más que suficiente (con el estado actual de la ciencia nadie va a vivir más de 255 años o no habría dinero para pagarle la pensión), pero para un ID de una tabla 255 posibles opciones se queda corto.

Tipos de Datos: DECIMAL y NUMERIC

Antes de seguir, vamos a aclarar una de las mayores dudas que tiene la gente en SQL Server: DECIMAL y NUMERIC son sinónimos, da igual cual uses, es lo mismo, no hay uno mejor, va a rendir igual, van a comportarse igual y cualquier otra cosa que podáis imaginar. ¿Claro esto? Vale genial, esta es la pregunta que más veces me han hecho desde que me dedico a las bases de datos y a partir de ahora al que me lo pregunte le mandaré a vosotros. Volviendo a lo nuestro, estos datos son numéricos con una precisión y una escala fija. La precisión máxima que pueden tener es de 38 y la escala puede ser desde 0 hasta la precisión que hayamos definido. El tamaño que ocupa en disco y por tanto su rendimiento dependerá de la precisión que definamos así que, como es lógico, tenemos que usar una precisión suficiente para almacenar lo que necesitamos, pero sin pasarnos.

Tipos de Datos: MONEY y SMALLMONEY

La teoría dice que son tipos de datos que usa SQL para almacenar valores monetarios, pero, permitidme ser muy claro en esto, es una GRANDISIMA MIERDA. No voy a decir más, os dejo una foto y al que vea usando datos de este tipo le cortaré las manos.

Nota: Ya sé lo que me vais a decir, que no se puede dividir dinero entre dinero, pero no lo uséis y os ahorraréis problemas.

Tipos de Datos: FLOAT Y REAL

Estos son tipos de datos numéricos y aproximados que se utilizan con datos numéricos de coma flotante. Para que nos entendamos son datos numéricos para operaciones científicas y no los vamos a usar para almacenar nuestros valores. Como máximo admiten hasta 15 dígitos el FLOAT y 7 el REAL, aunque en al consultar su precisión vemos 53 o 24 para estos tipos de datos, eso es el número de bits que almacena internamente. Lo importante aquí es que no son números exactos y cuando llegas a la precisión máxima va a redondear por lo que bajo ningún concepto deberíamos utilizarlos para almacenar nuestros valores numéricos. No tienen escala por defecto, admite tantos decimales como precisión tenga. Si os fijáis otra vez en la primera captura que os he puesto al principio, estos dos tipos de datos tienen un valor NUMERIC_PRECISION_RADIX distinto a los demás, esto es porque se almacenan en binario no en base decimal en la base de datos. Como esto está muy bien explicado en la Wikipedia y este post ya se ha alargado demasiado os dejo el enlace por si os interesa profundizar en el tema https://es.wikipedia.org/wiki/Coma_flotante.

Enhorabuena por haber llegado hasta aquí abajo, espero que hayáis aprendido tanto leyendo esto como yo me he desasnado escribiéndolo😝 Antes de cerrar os dejo un apunte más copiado directamente de la web de SQL y ya no os robo más tiempo.

CONVERISIONES DE DATOS

Al convertir de decimal o numeric a float o real se puede provocar una pérdida de precisión. Al convertir de int, smallint, tinyint, float, real, money o smallmoney a decimal o numeric se puede provocar un desbordamiento. De forma predeterminada, SQL Server usa el redondeo cuando convierte un número a un valor decimal o numeric con una precisión y una escala inferiores. Y a la inversa, si la opción SET ARITHABORT está establecida en ON, SQL Server genera un error cuando se produce un desbordamiento. La pérdida de únicamente precisión y escala no es suficiente para generar un error.