SQL Server

Aquí encontraras todos nuestros post relacionados con SQL Server desde cero hasta un nivel avanzado. Desde infraestructura hasta modelado de datos.

26
Feb
2024

Eventos Extendidos en SQL Server: Una Guía Completa

Bienvenidos a este emocionante viaje al corazón de SQL Server. Hoy, nos sumergimos en el fascinante mundo de los eventos extendidos (también conocidas como Extended Events, xEvents o simplemente XE). Si aún estás utilizando el antiguo SQL Profiler/SQL Trace, es hora de dar la bienvenida a una herramienta más moderna y poderosa. En este artículo, explicaremos cómo crear sesiones de eventos, analizar datos y obtener información valiosa sobre el motor interno de SQL Server.

¿Qué son los eventos extendidos?

Los eventos extendidos son una herramienta poderosa para supervisar y solucionar problemas de rendimiento en SQL Server, Azure SQL Database y Azure SQL Managed Instance. A diferencia de las características obsoletas de Seguimiento de SQL y SQL Server Profiler, los xEvents ofrecen una mayor flexibilidad y escalabilidad.

Los Extended Events son una característica ligera de monitoreo de rendimiento que nos permite recopilar datos para supervisar y solucionar problemas. A diferencia del antiguo SQL Trace, xEvents ofrecen una visión escalable del comportamiento de SQL Server con un impacto mínimo en el rendimiento.

Ventajas de los Eventos Extendidos

Como ya hemos señalado, una de las mayores virtudes de los Eventos Extendidos es su ligereza. Los xEvents utilizan recursos mínimos del sistema. Todo esto además proporcionándonos un grado de precisión y detalles como ninguna otra herramienta. Son capaces de proporcionarnos una vista detallada del motor de base de datos a través de una interfaz gráfica. Y es que esta es otra de sus ventajas, nuestro SQL Server Management Studio (SSMS) ofrece una interfaz gráfica para crear, modificar y analizar sesiones de eventos.

Conceptos Clave

Antes de empezar a crear nuestra primera sesión de eventos extendidos tenemos que conocer una serie de conceptos que vamos a necesitar.Si habéis trabajado antes con el seguimiento de eventos para Windows esto os va a sonar, xEvents se basa en estos conceptos para llevar esta monitorización a SQL Server. Sin embargo, necesita de conceptos nuevos que son específicos de SQL Server. Vamos a ver los principales.

Motor de Eventos Extendidos

Es la base de todo esto, el motor de xEvents implementa y administra las sesiones de eventos extendidos. Es responsable de recopilar y relacionar los datos.

Sesiones de Eventos Extendidos

Una sesión se crea en el proceso del motor de base de datos donde se hospeda el motor de eventos extendidos. Proporciona el contexto necesario para comprender la infraestructura y el procesamiento que ocurre.

Paquetes de Eventos Extendidos

Los paquetes son contenedores de objetos que las sesiones de eventos extendidos utilizan para obtener y procesar datos durante su ejecución.

Destinos de Eventos Extendidos

Los consumidores de eventos pueden recibir datos durante una sesión. Llamamos consumidores de eventos al destino que va a recibir la información que extraemos de nuestra sesión de XE. Pueden ser archivos, tablas o incluso aplicaciones externas.

Arquitectura de Eventos Extendidos

Ahora que ya tenemos claro los conceptos básicos de los eventos extendidos podemos profundizar más técnicamente. xEvents es un sistema de control de eventos para servidores que permite la correlación de datos del motor de base de datos y, en ciertas condiciones, de las bases de datos y del sistema operativo. Los datos de eventos se pueden utilizar dentro y fuera de una aplicación, proporcionando información útil para la supervisión y el rendimiento. Los datos se pueden consumir o analizar mediante diversas herramientas, como SQL Server Management Studio, XEvent Profiler o el Monitor de rendimiento.

El diseño de Eventos Extendidos es flexible e independiente del evento, permitiendo que cualquier evento se enlace con cualquier destino. Es decir, los eventos están separados de los consumidores de eventos, lo que significa que cualquier destino puede recibir cualquier evento. Además, se pueden asociar acciones a cualquier evento y se pueden filtrar dinámicamente los datos del evento. XE puede generar datos de eventos de forma sincrónica y proporciona un enfoque unificado para controlar los eventos en todo el sistema del servidor, integrándose con las herramientas de ETW existentes y ofreciendo un mecanismo configurable de control de eventos que utiliza T-SQL.

Crea tu sesión de Eventos Extendidos

Ya hemos dicho que una de las ventajas de los xEvents es su interfaz gráfica. Desde SSMS, conectados a una instancia de bases de datos encontraremos la opción Eventos Extendidos en el apartado Administración. Tenemos además un asistente para facilitarnos la tarea de creación de sesiones que nos irá guiando por los pasos necesarios además de poder elegir entre diferentes plantillas ya predefinidas.

Explorando los Datos

Una vez que tengamos nuestra sesión de eventos, podremos ver los datos que nos proporciona. Uno de los eventos más interesantes es query_post_execution_showplan, que nos ofrece el plan de ejecución real después de que se haya ejecutado una consulta. Esto incluye estadísticas de rendimiento en tiempo real. 

Sin embargo, este evento tiene un alto costo Por suerte, existen alternativas más ligeras para obtener planes de ejecución individuales como query_thread_profile. Disponible desde SQL Server 2014 SP2 y SQL Server 2016, este evento muestra un perfil detallado por operador e hilo de ejecución en un plan real. Aunque puede ser muy detallado, es útil para análisis a gran escala.

Conclusión

En resumen, los eventos extendidos son una herramienta esencial para cualquier administrador o desarrollador que desee profundizar en el rendimiento y la optimización en entornos SQL Server. Son una herramienta poderosa para comprender el comportamiento interno de SQL Server. Al adoptarlas, obtendrás información valiosa sin afectar significativamente el rendimiento del sistema. 

¡Espero que esta guía te ayude a aprovechar al máximo los eventos extendidos! Sigue atento al blog porque a lo largo de esta semana vamos a publicar artículos más prácticos donde usaremos estos eventos extendidos para solucionar problemas de rendimiento de nuestro SQL Server.

Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en SQL Server, 4 comentarios
23
Feb
2024

SQL consume mucha RAM. Solución a problemas de memoria

Bienvenidos a este tercer artículo sobre el uso que hace SQL Server de la memoria RAM. En los últimos días ya hemos visto cómo se gestiona la RAM en SQL y la configuración especial LPIM para optimizar el rendimiento en caso de presión de memoria. Pero si recordáis, en este último artículo, os decía que antes de tocar LPIM lo mejor era afrontar el problema. Por ello vamos a dedicar este artículo a ver cómo podemos detectar y afrontar problemas de consumo excesivo de memoria RAM.

Determinando el consumo excesivo de memoria

¿Realmente tenemos un problema? Esta es la principal pregunta, normalmente, a ojos del que no conoce el funcionamiento de SQL Server puede ser preocupante la gran cantidad de memoria que SQL Server suele tener reservada. Sin embargo, nosotros que somos buenos DBAs (y hemos leído el artículo sobre la RAM del otro día) sabemos que no nos podemos fiar de eso pues SQL Server siempre va a reservar toda la RAM que tenga a su disposición hasta el máximo que le hayamos asignado. Esto no quiere decir que la esté usando así que vamos a ver cómo podemos realmente darnos cuenta. 

Analizando el consumo de memoria RAM de SQL Server

SQL Server pone a nuestra disposición unas vistas de administración dinámica (dm views) que nos pueden dar cierta información sobre la RAM. Estas vistas son, según la documentación oficial, sys.dm_os_process_memory y sys.dm_os_sys_memory. Aunque a mi me gusta también consultar sys.dm_os_sys_info y sys.dm_os_performance_counters.

Vista sys.dm_os_process_memory

En esta vista podemos encontrar datos sobre la cantidad de memoria en uso y disponible en nuestro SQL Server. Podéis consultar la documentación oficial de la vista aquí. Yo os recomiendo estas:

En esta consulta de Pinal Dave, muy interesante podemos ver la memoria en uso y un par de avisos sobre presión de memoria. Si los dos avisos están en 0 es que todo está bien.

SELECT physical_memory_in_use_kb/1024 [Physical Memory Used in MB],
process_physical_memory_low [Physical Memory Low],
process_virtual_memory_low [Virtual Memory Low]
FROM sys.dm_os_process_memory;
sys.dm_os_process_memory

Esta otra consulta nos da un poco más de información, en ella vamos a poder ver el detalle de lo que está consumiendo la memoria RAM por parte de SQL Server:

SELECT
  physical_memory_in_use_kb/1024 AS sql_physical_memory_in_use_MB,
   large_page_allocations_kb/1024 AS sql_large_page_allocations_MB,
   locked_page_allocations_kb/1024 AS sql_locked_page_allocations_MB,
   virtual_address_space_reserved_kb/1024 AS sql_VAS_reserved_MB,
   virtual_address_space_committed_kb/1024 AS sql_VAS_committed_MB,
   virtual_address_space_available_kb/1024 AS sql_VAS_available_MB,
   page_fault_count AS sql_page_fault_count,
   memory_utilization_percentage AS sql_memory_utilization_percentage,
   process_physical_memory_low AS sql_process_physical_memory_low,
   process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;
sys.dm_os_process_memory

Vista sys.dm_os_sys_memory

Esta vista de sistema nos va a dar menos variedad de información pero no por ello menos útil. A diferencia de la anterior aquí veremos los datos de memoria de nuestro servidor no solo de SQL Server. Podéis ver todas las columnas disponibles en la vista aquí, aunque yo os recomiendo esta consulta.

SELECT total_physical_memory_kb/1024 [Total Physical Memory in MB],
available_physical_memory_kb/1024 [Physical Memory Available in MB],
system_memory_state_desc
FROM sys.dm_os_sys_memory;
sys.dm_os_sys_memory

Vista sys.dm_os_sys_info;

Esta vista es muy interesante pues además de la memoria en uso por SQL Server nos va a mostrar una estimación de lo que SQL Server espera necesitar. Si combinado con las anteriores vemos que el valor necesitado es menor que el disponible podemos respirar tranquilos. Os dejo un ejemplo de uso sencillo:

SELECT committed_kb/1024 [SQL Server Committed Memory in MB],
committed_target_kb/1024 [SQL Server Target Committed Memory in MB]
FROM sys.dm_os_sys_info;
sys.dm_os_sys_info

Vista sys.dm_os_performance_counters

Esta vista nos va a mostrar todos los contadores de rendimiento, incluidos los de SQL Server. Con ella podremos tener una visión más completa de lo que está pasando. Para el caso que nos ocupa os recomiendo filtrar por la palabra memoria:

SELECT object_name, counter_name, instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name like '%Memory%'
sys.dm_os_performance_counters

Bonus 

Además de todas estas vistas de sistema, SQL pone a nuestra disposición el comando DBCC MEMORYSTATUS. Este comando nos va a dar mucha información (demasiada) sobre todo el estado de la memoria. Está diseñado para ser una herramienta de diagnóstico para los ingenieros de soporte de Microsoft por lo que, a nosotros, simples mortales, nos va a confundir más que otra cosa. Si tienes curiosidad sobre este comando puedes pasarte por su página en los books online de SQL Server dónde lo explican en detalle.

DBCC_MEMORYSTATUS

¿Qué hago si realmente hay un problema con la memoria?

Si llegados a este punto has detectado que si que tenias un problema real con el consumo de memoria RAM, te compadezco. Estás en una situación en la que a ninguno nos gustaría estar, pero no te preocupes, vivimos de esto y es lo que nos da dinero. Sigue leyendo que aún hay más artículo para que puedas salir airoso de este marronazo.

Lo primero que tendrás que determinar es si el problema está ocurriendo ahora mismo o ya ha pasado. Si estás en el primer caso puedes hacer uso de procedimientos almacenados como sp_who3, sp_whoisactive o sp_blitzwho para determinar el consumo de memoria de cada una de las consultas en ejecución y tirar de las orejas a alguien.

Si, como me pasa a mi, en tu país también está mal visto (y hasta penado por ley) el castigo físico, analiza las consultas que más memoria consumen y trata de optimizarlas. Quizá solo te falta un índice. O a lo mejor es al revés y te sobran. O están bien definidos pero sin mantenimiento. Te aseguro que con esto de los índices vas a resolver el 70% de las incidencias que te puedas encontrar. El resto de casos puede ser debido a ordenaciones sin miedo a lo que pueda pasar o al uso de operadores como UNION, DISTINCT, etc… que cargan el resultado en memoria para eliminar registros duplicados.

Si el problema ya ha pasado y no tienes tanta suerte de acceder a las consultas en ejecución, revisa los índices que te faltan y los que no se usan que es probable que con eso lo soluciones. Te dejo por aquí todo lo que se ha hablado en este blog sobre índices.

Conclusión

Afrontar una incidencia sobre el consumo de memoria en SQL Server puede ser un desafío. Espero que con estas herramientas de diagnóstico, nativas y de terceros, podáis enfrentaros mejor a ellas. Tampoco está de más ser proactivos y revisar de vez en cuando el uso de índices para ahorrarnos problemas. Un buen mantenimiento de índices y estadísticas nos evitará más de un disgusto. Recordad que un diagnóstico y una resolución rápida son fundamentales para mantener un entorno SQL Server saludable y eficiente. La superación de estos retos garantiza un funcionamiento fluido de la base de datos y contribuye a la eficacia general de la empresa, a la satisfacción del cliente y, en última instancia, a la cuenta de resultados.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

CRÉDITOS: Varias de las consultas de este post son originales de Pinal Dave de SQLAuthority y del blog SQLHack. 

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 5 comentarios
22
Feb
2024

Optimizando SQL Server con Lock Pages in Memory (LPIM)

Continuamos con la serie de artículos sobre la optimización de la RAM de nuestro SQL Server que empezamos ayer. Hoy vamos a hablar de una característica muy interesante de SQL Server que puede ayudar a mejorar el rendimiento de nuestras bases de datos: el bloqueo de páginas de memoria o Lock Pages in Memory (LPIM). No es una característica de SQL Server sino una configuración de Windows Server que nos permitirá controlar lo que pasa cuando el sistema tiene presión de RAM y tiene que paginar a disco.

¿Qué es Lock Pages in Memory?

El bloqueo de páginas en memoria (LPIM) es una política de Windows que evita que el sistema realice la paginación de los datos a la memoria virtual del disco durante la presión de memoria. En otras palabras, LPIM bloquea los datos en la memoria RAM. No importa que otros procesos o el propio sistema operativo necesiten esa memoria, nuestro SQL va a decir “tu problema no es mi problema” y no las va a liberar. Esto puede mejorar el rendimiento del sistema y puede ser muy útil para SQL Server aunque también es muy peligroso.

¿Cómo funciona LPIM en SQL Server?

Cuando SQL Server se ejecuta en una cuenta que tiene el privilegio LPIM, puede bloquear las páginas de memoria en la RAM física y evitar que el sistema operativo las pagine a la memoria virtual en el disco duro. Esto significa que SQL Server usará la memoria tanto como sea necesario, y no la liberará al sistema operativo en circunstancias normales. Este comportamiento puede aumentar el rendimiento del sistema y de SQL Server si hay presión de memoria en el sistema.

¿Cómo habilitar LPIM en SQL Server?

Como hemos comentado, para habilitar LPIM en SQL Server, debemos conceder el privilegio a la cuenta de servicio de SQL Server. Para hacerlo debemos seguir los siguientes pasos:

  1. En el menú Inicio, seleccionamos Ejecutar.
  2. En el cuadro Abrir, escribimos gpedit.msc.
  3. En la consola Directiva de grupo local, expandimos Configuración del equipo.
  4. Expandimos Configuración de Windows.
  5. Expandimos Configuración de seguridad.
  6. Expandimos Directivas locales.
  7. Seleccionamos la carpeta Asignación de derechos de usuario.
  8. En el panel, vamos a la directiva Bloquear páginas en la memoria y hacemos doble clic en ella.
  9. En el cuadro de diálogo Configuración de la directiva de seguridad local, seleccionamos **Agregar usuario o grupo…*.
  10. Agregamos la cuenta de servicio de SQL Server.
  11. Seleccionamos Aceptar.
  12. Reiniciamos la instancia SQL Server para que se aplique la configuración.

Ventajas y desventajas de LPIM

Según lo que hemos visto en la teoría, con LPIM mejoraremos el rendimiento al evitar que las páginas se muevan entre RAM y disco, reducimos la latencia. Además ganamos estabilidad al asignar memoria física específicamente para SQL Server, evitando conflictos con otros procesos o aplicaciones. Por último, ganamos un mayor control sobre cómo se utiliza la memoria en nuestra instancia. 

Sin embargo, estamos hablando de una configuración a bastante bajo nivel que interfiere en la gestión de memoria del sistema operativo. Cualquier mala decisión por nuestra parte podría acarrear resultados no deseados. En este sentido, es importante tener en cuenta que si se concede el privilegio LPIM, se recomienda encarecidamente establecer la memoria máxima de SQL Server en un valor específico, en lugar de dejar el valor predeterminado de 2 PB. Esto se debe a que si el valor de Memoria de servidor máxima se establece en una cifra demasiado alta, puede hacer que una única la instancia de SQL Server compita por la memoria con otras instancias de SQL Server hospedadas en el mismo host, otras aplicaciones o incluso con el propio sistema operativo.

¿Cuándo habilitar LPIM?

Llegamos a un punto clave, internet está dividido sobre este tema. Incluso la propia documentación oficial de Microsoft parece recomendarlo en algunos apartados y desaconsejarlo en otras páginas. Así que, aquí está SoyDBA para intentar aclarar las dudas. A priori, parece que ante un escenario de presión de memoria podría ser recomendable activar esta característica. Si a menudo nos encontramos con escenarios en los que SQL Server sufre de problemas de memoria y vemos el típico error 17890  en el log deberíamos por lo menos plantearnos esta solución. Quizá soy yo muy conservador pero, personalmente, no creo que sea recomendable en ningún otro escenario. Si no es para solucionar un problema no metería mano en configuraciones de este calado en el sistema operativo. Y por supuesto, nunca lo pondría en producción sin una buena batería de pruebas en un entorno para ese fin. En resumen, yo no lo haría si no hay un problema, y si lo hay sólo activaría LPIM si no puedo aumentar el hardware de la máquina que sería el segundo paso (el primero es tratar de reducir el consumo, obviamente).

LPIM en máquinas virtuales

No quería cerrar este artículo sin comentar un pequeño detalle y es que esta configuración no deberíamos tocarla en servidores virtuales. Todos los principales proveedores de máquinas virtuales tienen su propia gestión de la memoria de las máquinas virtuales y configurar LPIM en una máquina virtual nos va a causar problemas graves de rendimiento, tanto de nuestro propio servidor como en el resto de máquinas alojadas en el mismo host e, incluso, en el propio sistema del host.

Conclusión

LPIM puede ser una herramienta valiosa para mejorar el rendimiento de SQL Server. Sin embargo, como con cualquier herramienta, es importante entender cómo funciona y cómo usarla correctamente para obtener los mejores resultados. Me vienen a la cabeza aquellas sabias palabras “Un gran poder conlleva una gran responsabilidad” y es que, en este contexto, tienen incluso más sentido que cuando el Tio Ben (a punto de morir) se las dijo a Spiderman.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 0 comentarios
21
Feb
2024

Uso de RAM en SQL Server: Un Análisis Profundo

En el mundo de las bases de datos, la gestión eficiente de la memoria es crucial para garantizar un rendimiento óptimo. En SQL Server, la memoria juega un papel vital en el almacenamiento de datos y en la ejecución de consultas. Hoy, vamos a iniciar una serie de artículos en los que podremos profundizar en cómo SQL Server utiliza la memoria RAM y cómo podemos ajustarla para mejorar el rendimiento.

¿Cómo Utiliza SQL Server la Memoria RAM?

SQL Server es conocido por su eficiente uso de la memoria. Desde que se inicia, SQL Server se va reservando una gran cantidad de memoria, que luego utiliza para almacenar datos y procedimientos almacenados en caché. Con el paso del tiempo, SQL habrá reservado hasta el máximo de memoria configurada o el máximo disponible. De esta manera reduce la necesidad de realizar costosas operaciones de lectura en disco. Sin embargo, puede suponer un problema cuando esa memoria reservada la necesita el sistema operativo u otros procesos. Entonces, ¿qué sucede cuando otras aplicaciones ejecutándose en el mismo servidor que también necesitan memoria? Aquí es donde entran en juego las opciones de memoria mínima y máxima.

Opciones de Memoria RAM Mínima y Máxima

La cantidad de RAM que va a usar nuestro SQL server estará definida por dos configuraciones principales de la instancia. Una de ellas es la memoria máxima de SQL Server y otra es la memoria mínima. Estas opciones de memoria mínima y máxima nos permiten controlar cuánta memoria puede utilizar SQL Server. Estas opciones son especialmente útiles cuando tenemos varias aplicaciones ejecutándose en el mismo servidor aunque, es recomendable configurarlas siempre, aunque el servidor sea dedicado.

Memoria Mínima

Esta opción nos permite especificar la cantidad mínima de memoria que SQL Server se reservará. Esto no significa que cuando SQL se inicie tendrá ya reservada esta cantidad de RAM sino que, una vez que la alcance no la va a liberar bajo ningún concepto. Porque sí, aunque antes hemos dicho que SQL se reserva la memoria para usarla después puede ser que la libere en caso de que el sistema operativo lo solicite. Para esto sirve realmente este parámetro, para que este mínimo siempre esté reservado y no se libere. 

Esta configuración cobra una especial relevancia en entornos virtualizados, donde el sistema hipervisor podría desasignar los recursos de nuestro servidor si no se están usando.

Memoria Máxima

Esta opción nos permite limitar la cantidad de memoria que SQL Server puede utilizar. Esto es útil para asegurarnos de que otras aplicaciones en el servidor tengan suficiente memoria para funcionar correctamente. Aunque tengamos un servidor dedicado para SQL Server, tenemos que configurar también este parámetro para asegurarnos que el sistema operativo, antivirus, etc… funcionen correctamente. Como norma general configuraremos una memoria máxima para la instancia de SQL Server del 75% de la RAM no utilizada por otras instancias o aplicaciones. Tenemos que tener en cuenta ese 25% libre ya que este máximo de memoria es para las funciones principales de SQL Server, sin embargo no incluye otros buffers de memoria como los de los procedimientos CLR, las consultas por linked servers y otras. Los clerks de memoria no incluidos en el límite máximo de la misma varían en función de la versión de SQL Server.

Es importante recordar que estas opciones deben ajustarse con cuidado. Si establecemos una memoria mínima demasiado alta, podríamos privar a otras aplicaciones de la memoria que necesitan. Y si establecemos una memoria máxima demasiado baja, podríamos limitar el rendimiento de SQL Server.

Configurar la RAM en SQL Server

Para configurar las opciones que hemos visto podemos hacerlo mediante la interfaz gráfica del SSMS o mediante T-SQL. Para hacerlo por el entorno gráfico, en las propiedades de nuestra instancia, nos dirigiremos al apartado Memoria.

RAM SQL Server

Podemos usar también el comando sp_configure a través de código:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'max server memory', 10240;
GO
sp_configure 'min server memory', 1024;
GO
RECONFIGURE;
GO

Consideraciones para la RAM con varias instancias

Como ya hemos comentado antes, estas dos configuraciones son aún más importantes cuando tenemos más de una instancia en el servidor. Para estos escenarios hay varias maneras de trabajar. La primera sería no hacer nada y dejar todo por defecto pero esto, como os podéis imaginar, no es una buena idea. Ya que aquí somos buenos DBAs (vosotros más que yo, seguro) vamos a ver el resto de opciones:

Configuraremos solo la memoria máxima de cada instancia en función de las necesidades de cada una de ellas teniendo en cuenta siempre no superar el umbral del 75% que comentábamos antes. Con esto nos aseguraremos de que cada instancia consume su parte de recursos, sin embargo cuando una de las instancias esté parada, esa cantidad de memoria quedará libre.

Otra opción sería no configurar la memoria máxima y configurar un valor relativamente alto para la memoria mínima de las instancias. De esta manera las instancias podrán usar más RAM de la que configuramos como valor mínimo pero, cuando una de ellas necesite más recursos, podrá reclamar parte de lo que está usando el resto, siempre respetando el valor mínimo de las instancias. Este método tiene la ventaja de que cuando una instancia no se está ejecutando, el resto puede utilizar su parte de recursos. Por contra, cuando una instancia parada se levanta, puede tardar más en obtener los recursos necesarios para funcionar de manera óptima.

Como última opción nos quedaría una combinación de las dos anteriores. Esta será mi recomendación si me preguntáis. Configuraremos una memoria mínima suficiente para cubrir las necesidades mínimas de cada instancia y un valor de memoria máximo para cubrir las necesidades recomendadas más un margen (por lo que pueda pasar). De esta manera, estaremos aprovechando al máximo las posibilidades que nos brinda SQL Server.

Conclusión

El manejo de la memoria en SQL Server es un tema complejo, pero con un poco de conocimiento y las herramientas adecuadas, podemos optimizar el rendimiento de nuestras bases de datos. Recuerda, cada sistema es único, por lo que es importante monitorizar el rendimiento y ajustar las configuraciones según sea necesario.

Nos queda pendiente ver en próximos artículos configuraciones avanzadas de memoria y cómo identificar y afrontar los problemas más comunes de consumo de memoria. Manteneos atentos.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 1 comentario
20
Feb
2024

¿Qué nivel de RAID elegir para SQL Server?

En este artículo vamos a hablar de un tema muy importante para el rendimiento de nuestras bases de datos: el nivel de RAID más adecuado para los discos de los servidores de SQL Server. Aunque en el mundo de las máquinas virtuales y de la nube cada vez tenemos menos control sobre este tema, sigue siendo importante. Y seguro que, si lleváis tiempo en esto de las bases de datos, sobre todo en temas de arquitectura, habéis tocado el tema en alguna ocasión.

¿Qué es un RAID y por qué nos interesa?

RAID son las siglas de Redundant Array of Independent Disks, es decir, un conjunto redundante de discos independientes. Se trata de una forma de combinar varios discos físicos en una unidad lógica que mejora el rendimiento y la tolerancia a fallos. Con un RAID podemos aumentar la velocidad de lectura y escritura de los datos, así como protegerlos en caso de que uno o más discos fallen. Además nos ofrece una gran capacidad de redimensionamiento con unas posibilidades de crecer o decrecer impresionantes.

Niveles de RAID

Existen diferentes tipos de RAID, cada uno con sus ventajas e inconvenientes. Los más comunes son:

RAID 0

Consiste en dividir los datos en bloques y distribuirlos entre dos o más discos. No hay redundancia, por lo que si uno de los discos falla se pierden todos los datos. Sin embargo, ofrece el mayor rendimiento, ya que se aprovecha al máximo la capacidad y la velocidad de todos los discos.

RAID 1

Consiste en duplicar los datos en dos o más discos. Hay redundancia total, por lo que si uno de los discos falla se puede recuperar toda la información del otro. Sin embargo, se desperdicia la mitad de la capacidad y se reduce el rendimiento, ya que se tiene que escribir lo mismo en todos los discos.

RAID 5

Consiste en dividir los datos en bloques y distribuirlos entre tres o más discos, junto con un bloque de paridad que permite reconstruir los datos en caso de fallo de uno de los discos. Hay redundancia parcial, por lo que se puede tolerar la pérdida de un disco sin perder datos. Ofrece un buen equilibrio entre rendimiento y capacidad, ya que solo se pierde el espacio equivalente a un disco.

RAID 6

Es similar al 5, pero con dos bloques de paridad en lugar de uno. Esto permite tolerar la pérdida de dos discos sin perder datos. Ofrece mayor seguridad que el RAID 5, pero menor rendimiento y capacidad, ya que se pierde el espacio equivalente a dos discos.

RAID 10

Es una combinación de RAID 0 y 1. Consiste en crear varios grupos de discos en RAID 0 y luego duplicarlos en RAID 1. Ofrece el máximo rendimiento y seguridad, pero también el mayor coste y desperdicio de espacio, ya que se necesita el doble de discos que en un RAID 0.

¿Qué nivel de RAID elegir para SQL Server? 

El problema de SQL Server en este sentido, es que no todos los archivos tienen un uso de disco semejante. Al revés, cada archivo de SQL hace un uso distinto del disco por lo que no hay una solución ideal para todos los casos. Es por esto que vamos a diferenciar 4 grandes grupos distintos en función de sus necesidades. Por un lado tenemos las bases de datos de sistema master y msdb, por otro los archivos de log de transacciones (LDF), en tercer lugar los archivos de datos (MDF y NDF) y por último la base de datos de sistema TempDB. Cada uno tiene unas características y necesidades diferentes:

Base de datos master 

Esta base de datos contiene la información sobre las bases de datos y las configuraciones del servidor. Es un archivo pequeño pero crítico, ya que sin él no se puede iniciar SQL Server. Por eso, lo ideal es almacenarlo en un nivel que ofrezca la máxima seguridad, como el RAID 1 o el 10.

Archivos de Logs

Los archivos de logs contienen el historial de todas las transacciones realizadas en la base de datos. Es un archivo que crece continuamente y que requiere una alta velocidad de escritura. Por eso, lo ideal es almacenarlo en un nivel que ofrezca el máximo rendimiento, como el RAID 0 o el 10.

Archivos de datos

Los archivos de datos contienen los datos propiamente dichos de la base de datos. Es un archivo que puede ser muy grande y que requiere una buena velocidad tanto de lectura como de escritura. Por eso, lo ideal es almacenarlo en un nivel que ofrezca un buen equilibrio entre rendimiento, capacidad y seguridad, como el RAID 5 o el 6. 

TempDB

Este archivo almacena los datos temporales generados por las consultas y operaciones internas del servidor. Es un archivo muy utilizado y muy sensible al rendimiento, por lo que requiere una atención especial. Lo ideal es almacenarlo en un nivel que ofrezca la mayor velocidad posible, como el RAID 0 o el 10. Sin embargo, hay que tener en cuenta que el archivo temporal se borra cada vez que se reinicia SQL Server, por lo que no hay que preocuparse por la seguridad o la capacidad de los discos así que podremos alojarlos también en un disco SSD que no tengamos configurado en RAID.

Conclusión

Como vemos, no hay una respuesta única al nivel de RAID óptimo para SQL Server, sino que depende del tipo y la importancia de cada archivo. Como norma general, la opción RAID 10 parece la menos mala dando un buen compromiso entre rendimiento y profundidad. Sin embargo, es la opción más costosa así que no es la adecuada para todo el mundo. Lo más recomendable es analizar las características y necesidades específicas de cada caso y elegir el nivel que mejor se adapte a ellas. Tendremos que conocer bien el uso de nuestro servidor para poder priorizar una solución RAID sobre otra en caso de que no tengamos la posibilidad de implementar varias.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

CREDITOS: Hoy quiero dar las gracias a mi amigo Aurelio Montalvillo García, arquitecto de soluciones IT que revisó este post antes de su publicación y me aconsejó alguna mejora.

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 1 comentario
19
Feb
2024

Cómo planificar una migración de SQL Server paso a paso

En este artículo quiero compartir con vosotros algunos consejos y buenas prácticas para planificar una migración exitosa de SQL Server. Se que este tipo de proyectos pueden ser complejos y desafiantes, pero también muy gratificantes si se hacen bien. Por eso, quiero ayudaros a evitar los errores más comunes y a aprovechar las herramientas y recursos disponibles.

Definir el alcance y los objetivos de la migración

Lo primero que hay que hacer es definir el alcance y los objetivos de la migración. ¿Qué versión de SQL Server queremos migrar? ¿A qué plataforma o servicio? ¿Qué nivel de compatibilidad necesitamos? ¿Qué impacto tendrá en el rendimiento, la seguridad y la disponibilidad de nuestros datos? Estas son algunas de las preguntas que debemos responder antes de empezar.

Identificar los objetos que hay que migrar

Debemos controlar todos los objetos de nuestra instancia y que no son de base de datos ya que no migran con un backup. Estos objetos pueden ser trabajos del Agente SQL, alertas, operadores, credenciales, claves, certificados, proxies, servidores vinculados, etc. Cada uno de estos objetos puede tener sus propias particularidades y requerimientos para la migración. Debemos analizarlos con detalle y planificar cómo migrarlos sin perder funcionalidad ni integridad.

Evaluar el estado actual de la instancia y base de datos

Cuando tengamos el escenario y los objetos a migrar, empezaremos a evaluar el estado actual de nuestra instancia y base de datos. Es importante identificar los posibles riesgos y problemas que podrían surgir durante el proceso. Para ello, podemos utilizar el Data Migration Assistant (DMA), una herramienta gratuita de Microsoft que nos permite analizar la compatibilidad, la calidad y la preparación de nuestra base de datos para la migración.

El DMA nos ofrece dos tipos de análisis: el de evaluación y el de migración. El análisis de evaluación nos permite detectar los posibles problemas de compatibilidad con la versión o plataforma destino. También nos va a sugerir mejoras en cuanto a rendimiento, seguridad y características modernas. El análisis de migración nos permite estimar el tiempo y el esfuerzo necesarios para realizar la migración, así como los pasos a seguir para llevarla a cabo.

En anteriores artículos hemos hablado en detalle sobre el DMA para realizar estos análisis. Os recomiendo que lo reviséis si queréis profundizar más en esta herramienta. Aquí os dejo el enlace.

Planificar las acciones necesarias para ejecutar la migración con éxito

Después de realizar los análisis con el DMA, tendremos una visión más clara de lo que implica la migración y podremos planificar las acciones necesarias para ejecutarla con éxito. Algunas de estas acciones pueden ser resolver los problemas de compatibilidad identificados por el DMA, ya sea modificando el código o aplicando las opciones de compatibilidad adecuadas. Además podremos optimizar el rendimiento y la seguridad de nuestra instancia y base de datos, aprovechando las recomendaciones del DMA y las características modernas de SQL Server.

Lo siguiente que debemos hacer es elegir el método más adecuado para realizar la migración, según el tamaño, la complejidad y los requisitos de nuestra instancia y base de datos. Podemos optar por usar el propio DMA, que nos permite migrar tanto el esquema como los datos, o usar otras herramientas como el SQL Server Migration Assistant (SSMA), el SQL Server Integration Services (SSIS) o el Azure Database Migration Service (DMS). También podemos buscar métodos de migración Online como replicaciones, log shipping, database mirroring o incluso Always On, dependiendo de si vamos a cambiar o no de versión. Os recomiendo la serie de post sobre alta disponibilidad para que conozcáis las ventajas y las limitaciones de cada uno de estos métodos.

Cuando tengamos claro cómo vamos a hacerlo, os recomiendo preparar un documento de Excel con todos los pasos de todos los equipos implicados indicando horarios estimados y el impacto que puede tener. Esto nos ayudará a preparar la migración y sobre todo a no tener problemas el día de la migración ya que al estar todo detallado no se nos olvidará nada. Es importante definir bien una serie de pruebas exhaustivas antes, durante y después de la migración, para asegurarnos de que todo funciona correctamente y no hay pérdida ni corrupción de datos. Además deberemos preparar un plan de contingencia por si algo sale mal durante la migración, que nos permita restaurar el estado anterior sin afectar al negocio.

Conclusión

Como veis, planificar una migración de SQL Server requiere un análisis previo y una ejecución cuidadosa. Pero no os preocupéis, porque desde www.soydba.es estamos aquí para acompañaros en todo el proceso y resolver todas vuestras dudas. Si queréis podéis pedírmelo y os haré llegar una plantilla de documento de migración que suelo usar yo para no dejarme nada.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en SQL Server, 4 comentarios
16
Feb
2024

DRP ¿Cómo sobrevivir a una caída total de las bases de datos?

Hoy nos sumergimos en las profundidades del Plan de Recuperación ante Desastres (DRP) en el mundo de las bases de datos. Los DRP son algo imprescindible para todos los que trabajamos con entornos de producción con cierta criticidad. Puede parecer algo lejano y muy avanzado si estás empezando en este mundo, pero no te preocupes, vamos a intentar aclarar el mar de acrónimos y jerga técnica que rodea este tema. 

¿Qué es un DRP?

Lo primero de todo sería aclarar que el DRP forma parte del BCP (plan de continuidad de negocio). En ocasiones se pueden llegar a confundir pero no son lo mismo. Mientras que un DRP es un plan técnico que se centra en recuperar la infraestructura, el BCP incluye mucha más información como los pasos necesarios para mitigar pérdidas y recuperar toda la organización. 

¿Para qué sirve el DRP?

Vale, ya hemos dicho que el DRP es un plan puramente técnico que recoge de la manera más detallada posible las acciones a realizar ante un incidente. Pero, ¿para qué sirve? Puede parecernos que algunas cosas son demasiado obvias para ponerlas en un documento y que nosotros como buenos DBAs sabemos que hay que hacer en caso de incidente. Sin embargo, tenéis que pensar que en caso de crisis, con la presión que vamos a tener encima, lo mejor es tener todo documentado y seguir un guion. El futuro de nuestra empresa estará en esa intervención y tendremos que estar a la altura.
Los beneficios de tener un DRP previamente pensado y documentado son varios, entre ellos podemos destacar:

  1. Reduce el tiempo de inactividad al máximo lo que se traduce en un mejor servicio para nuestros clientes y proveedores.
  2. Minimiza las pérdidas por inactividad al conseguir un mejor tiempo de respuesta.
  3. Reduce el estrés de la toma de decisiones. En un momento crítico, es de vital importancia que todo el mundo sepa cómo actuar y no pierda los nervios.
  4. Asegura que todo el mundo podrá volver a acceder a su información. 
  5. Nos ayuda a cumplir con la legislación vigente en entornos regulados.

Los 4+1 pasos para el éxito de nuestro DRP

Genial, necesitamos un DRP pero, ¿por dónde empezamos?. No te asustes que no es tan difícil. En tan solo 5 pasos vas a poder tenerlo todo atado ya verás.

1 Definiciones

Todo DRP debe empezar definiendo las necesidades de alcance y los objetivos del propio plan. Podríamos definir tres apartados dentro de este paso, el primero es el alcance es decir, qué servicios queremos tener cubiertos por el plan de recuperación.
Una vez que hemos definido el alcance o perímetro de nuestro DRP el siguiente apartado sería saber de que nos queremos proteger, pregúntate: ¿Qué podría pasar? ¿un apagón? ¿Un incendio? ¿Un ataque de ransomware? ¿O tal vez una ardilla se coma los cables del servidor? (Sí, eso también pasa. ¿Verdad compañeros?). 

Por último, sabiendo que queremos proteger y de que lo siguiente sería definir lo que se conoce como BIA (Business Impact Analysis) o análisis de impacto de negocio. Aquí, tendremos que colaborar con otras áreas de la empresa para conocer el impacto de una crisis en su actividad y la de nuestros clientes.

2 Diseñar las estrategias de recuperación

Ahora que sabemos qué y de qué nos tenemos que proteger llega el momento del cómo. Diseñaremos una estrategia de recuperación para cada uno de los incidentes previamente descritos. Por ejemplo, esta es una lista de los escenarios más comunes y alternativas para su recuperación.

INCIDENTEEstrategia de RECUPERACIÓN
Borrado accidental de datosRestaurar copia de seguridad
Indisponibilidad de una base de datos
  1. Restaurar copia de seguridad
  2. Balanceo a otro nodo del cluster
Indisponibilidad de un servidor
  1. Balanceo a otro nodo del cluster.
  2. Reinstalación + restaurar copias.
Indisponibilidad de un centro de datos (CPD)
  1. Balanceo a otra ubicación geográfica.
  2. Reinstalación en otra ubicación y restaurar copias

3 Procedimentar las estrategias de recuperación

Como hemos dicho, no tenemos que dar nada por sentado y tenemos que detallar todos los pasos por lo que es el momento de explicar paso a paso como realizar todas y cada una de las acciones descritas en el paso anterior. Cuanto más detalle mejor, no olvidéis detallar la ubicación de las copias de seguridad o las direcciones IP y nombre de los servidores de respaldo, por ejemplo.

Podemos partir de la tabla anterior y añadir otra columna con los pasos, como en este ejemplo:

INCIDENTEEstrategia de RECUPERACIÓNProcedimiento de ACTUACIÓN
Borrado accidental de datosRestaurar copia de seguridad
  1. Identificar el problema.
  2. Avisar a todos los usuarios afectados.
  3. Intentar reparar el problema.
  4. Restaurar copia de seguridad de las bases de datos desde \\NuestroNAS\Copias\NuestroServer\NuestraBD
    4.1 Verificar que hay espacio disponible y solucionarlo en caso que sea necesario.
    4.2 Restaurar la base de datos.
  5. Probar que todo funciona.
  6. Avisar a los usuarios de que se ha resuelto la incidencia
  7. Monitorizar el correcto funcionamiento

4 Estimación de tiempos e impacto

Ya hemos visto todo lo que hay que hacer y como, es el momento de documentar cuánto tiempo vamos a tardar en cada uno de los escenarios y cual va a ser el impacto en los sistemas. Esto es lo que técnicamente se conoce como RPO y RTO que son las siglas en inglés de punto de recuperación objetivo y tiempo de recuperación objetivo.

El RPO hace referencia al máximo tiempo de pérdida de datos admisible, por ejemplo si tenemos una copia de seguridad diaria, en caso de fallo del servidor principal podremos tener hasta 24 horas de pérdida de datos.

El RTO es un poco más difícil de calcular, y seguramente tendremos que hacer pruebas para saberlo con exactitud, y hace referencia al tiempo que tardaremos en tener el servicio operativo nuevamente. Si en este punto hemos hecho todo bien, los RPO y RTO de las estrategias de recuperación estarán dentro de los márgenes admisibles que definimos en el paso número 2. 

5 Paso EXTRA: Revisión y pruebas

Aunque con los 4 pasos anteriores teóricamente habríamos completado nuestro DRP es importante que lo pongamos en práctica y que comprobemos que realmente funciona como habíamos pensado. Esto no hay que hacerlo solo una vez y olvidarnos, nuestras bases de datos son sistemas vivos que van cambiando día a día por lo que al menos una vez al año deberíamos hacer el ejercicio de probar el DRP y en caso de que sea necesario modificarlo para que se adapte a la situación actual de los sistemas. Este paso es el más importante y, en ocasiones, habrá entidades reguladoras que nos exijan evidencias de éxito de estos DRP Test.

Conclusión

Los DRP son imprescindibles para cualquier empresa que tenga sistemas en producción. Ya sea porque un regulador lo establece, porque estás tratando de adecuarte a la ISO 27001 o porque has pensado que este tipo de planes son importantes para ti, espero que este post te haya ayudado a resolver las dudas que tenías antes de empezar a leer. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Publicado por Roberto Carrancio en Alta Disponibilidad, SQL Server, 1 comentario