He estado enseñando y escribiendo sobre errores comunes de SQL Server durante muchos años. También escribí un blog sobre esto hace años, sin embargo, con el paso del tiempo, la orientación ha cambiado un poco. Este artículo ampliará mi artículo anterior y señalará cómo se aplican a SQL Server, Azure SQL Database y Azure SQL Managed Instance.
Durante muchos años he encontrado usuarios que cometen los mismos errores. Yo los llamo errores, sin embargo, en la mayoría de los casos, es más simplemente que las cosas no se hacen correctamente porque las personas que manejan el medio ambiente no saben nada mejor. Estos son algunos de los elementos más críticos que cualquier persona que instale y admita SQL Server debe conocer:
- Copias de seguridad
- DBCC CHECKDB
- Configuración de la memoria
- Estadísticas
- Mantenimiento de índices
- MAXDOP y umbral de costo para paralelismo
- Alertas del Agente SQL Server
Copias de seguridad
Siempre reviso las copias de seguridad primero cuando miro un nuevo sistema. Tener copias de seguridad adecuadas para cumplir con los objetivos de recuperación es fundamental. La pérdida de datos puede ser perjudicial para una organización. Cuando miro las copias de seguridad, verifico el modelo de recuperación y el historial actual de copias de seguridad para cada base de datos. Normalmente encuentro una combinación de lo siguiente:
- Ninguna copia de seguridad:no hay registro de ninguna copia de seguridad para la base de datos
- Copias de seguridad faltantes:no hay copias de seguridad de registros para una base de datos que usa el modelo de recuperación completa
- No hay copias de seguridad recientes:la última copia de seguridad fue hace semanas/meses/años
Las copias de seguridad mal configuradas son perjudiciales para una organización cuando surge una situación de recuperación. Trabajar con los clientes y tener que decirles que han perdido datos nunca es divertido ni fácil. Tener copias de seguridad adecuadas para cumplir con los SLA debe ser la principal prioridad de cualquier organización, además de asegurarse de que haya copias de estas copias de seguridad almacenadas en una ubicación secundaria fuera del sitio.
Esta situación se aplica a SQL Server local e IaaS. Azure SQL Database y Azure Managed Instance tienen copias de seguridad administradas.
DBCC CHECKDB
Desafortunadamente, la corrupción de la base de datos ocurre. Sin verificar regularmente si hay corrupción, los clientes pueden encontrarse en un mal lugar al no tener copias de seguridad para recuperarse cuando esa corrupción afecta los datos físicos. Para comprobar si hay corrupción, se debe ejecutar DBCC CHECKDB en cada base de datos de forma regular. Lo que encuentro es muy similar a las copias de seguridad:
- No se realizaron DBCC CHECKDB en absoluto
- Los DBCC CHECKDB se realizan solo en bases de datos seleccionadas
- DBCC CHECKDBs realizados por última vez hace meses o años
En el peor de los casos, un informe programado de trabajo falló DBCC CHECKDBs
Nunca es agradable encontrar corrupción o que un cliente se comunique con un problema de corrupción cuando la corrupción es un montón o un índice agrupado y no hay copias de seguridad antes de que ocurra la corrupción. En estos casos, la corrupción son los datos reales y comenzar la restauración desde antes de la corrupción es, en la mayoría de los casos, la única opción. En los casos en que la corrupción es un índice no agrupado, reconstruir el índice es la solución.
En algunas situaciones, tuve que trabajar con clientes que tenían daños desagradables sin las copias de seguridad adecuadas, donde pude generar un script en la base de datos y copiar manualmente todos los datos utilizables en una base de datos recién creada. Estas situaciones costosas se pueden evitar fácilmente ejecutando DBCC CHECKDB y manteniendo una copia de seguridad adecuada.
Aconsejo a los clientes que ejecuten DBCC CHECKDB localmente, IaaS, Azure SQL Database y Azure SQL Managed Instance. Azure hace un gran trabajo comprobando daños físicos; sin embargo, siento que los consumidores deben verificar si hay corrupción lógica.
Configuración de memoria
Una instalación predeterminada de Microsoft SQL Server tiene un valor mínimo de memoria establecido en 0 y un valor máximo de memoria del servidor establecido en 2147483647 MB, que son 2 petabytes. Antes de SQL Server 2012, el valor máximo de memoria del servidor solo se aplicaba al grupo de búfer, por lo que los clientes necesitaban limitar la cantidad de memoria que el grupo de búfer podía usar para ahorrar memoria para el sistema operativo y otros procesos. SQL Server 2012 introdujo una reescritura del administrador de memoria para que el valor máximo de memoria del servidor se aplique a todas las asignaciones de memoria de SQL Server.
Es muy recomendable establecer un valor máximo para su instancia de SQL Server. Jonathan Kehayias ha escrito una publicación de blog sobre la cantidad de memoria que realmente necesita mi servidor SQL, con una fórmula que ayuda a establecer la línea de base para el valor máximo de memoria. En los casos de un servidor SQL compartido, recomiendo a mis clientes que establezcan el valor mínimo en el 30 % de la memoria del servidor.
En situaciones con múltiples instancias o donde el servidor se usa para SQL Server, SSIS, SSAS o SSRS, debe evaluar cuánta memoria necesitan esos otros sistemas y reducir el valor máximo de memoria del servidor para permitir la memoria adecuada para el sistema operativo y el otro. servicios.
Este problema es válido para local, IaaS y parcialmente para Instancia administrada de Azure SQL. Instancia administrada establece un valor máximo de memoria del servidor en función del nivel implementado; sin embargo, cuando probé el cambio de tamaño del entorno, el valor máximo de memoria no se modificó dinámicamente. En esa situación, deberá actualizar manualmente el valor. Este problema no se aplica a Azure SQL Database.
Estadísticas
El optimizador de consultas utiliza estadísticas para crear planes de ejecución. Esto significa que SQL Server necesita que las estadísticas estén actualizadas para que el optimizador de consultas tenga más posibilidades de crear un buen plan de ejecución. De forma predeterminada, las estadísticas se actualizan después de que se hayan modificado el 20% +500 filas de datos. Eso puede llevar mucho tiempo en mesas más grandes. A partir del nivel de compatibilidad 130, se ha reducido el umbral de actualizaciones de estadísticas para tablas grandes. Para SQL Server 2008R – 2014, puede reducir este umbral utilizando el indicador de seguimiento 2371.
Regularmente encuentro que los clientes no actualizan manualmente las estadísticas e incluso con el umbral más bajo, descubrí que la actualización manual hace que el entorno sea más estable.
Recomiendo que los clientes utilicen un script de terceros para actualizar las estadísticas. Ola Hallengren ha publicado una solución de mantenimiento ampliamente utilizada para SQL Server. Parte de ese proceso es su procedimiento Index Optimize, que puede tomar parámetros adicionales para actualizar las estadísticas.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Descubrí que los clientes que usan productos o scripts de terceros para realizar el mantenimiento del índice en función del nivel de fragmentación del índice no consideran que las reorganizaciones no actualizan las estadísticas como lo hacen las reconstrucciones. Muchas de estas aplicaciones de terceros tienen opciones para actualizar estadísticas al igual que el procedimiento Index Optimize de Ola, solo necesita activarlo.
La actualización de las estadísticas se aplica a las instalaciones locales, IaaS, Azure SQL Database y Azure SQL Managed Instance.
Mantenimiento de índice
Sigue siendo importante realizar el mantenimiento del índice mediante la eliminación de la fragmentación de sus índices. Parte de la documentación retirada de Microsoft indicaba que la fragmentación de índices puede tener un impacto negativo del 13 al 460 % según el tamaño del entorno y el nivel de fragmentación. Si bien el hardware como las SAN inteligentes, el disco de estado sólido y otros avances han ayudado a acelerar las cosas, el espacio desperdiciado en el índice puede traducirse en espacio desperdiciado en el grupo de búfer, así como en el despilfarro de más E/S.
La fragmentación ocurre a través de operaciones regulares como inserciones, actualizaciones y eliminaciones. Para remediar esto, se necesita un mantenimiento de índice adecuado para reconstruir o reorganizar sus índices. Vuelvo a recurrir a Ola Hallengren, por su guión de Index Optimize. El script de Ola brinda la capacidad de especificar la reconstrucción o reorganización según el nivel de fragmentación y las páginas mínimas. Muchas herramientas de terceros ofrecen la misma lógica. Los planes de mantenimiento de bases de datos de SQL Server anteriores a SQL Server 2016 solo permitían reconstruir o reorganizar todos los índices. A partir de SQL Server 2016, ahora puede especificar una lógica similar en función de los niveles de fragmentación. Sin embargo, no olvide esas estadísticas si está utilizando lógica inteligente basada en niveles de fragmentación.
Me gusta el script de Ola y las herramientas de terceros que se registran en una tabla. Luego puedo consultar la tabla para ver si tengo puntos calientes de índice donde la fragmentación se produce constantemente en niveles altos y solucionar por qué la fragmentación es tan frecuente y si se puede hacer algo.
Hay excepciones a cada regla o mejor práctica. Algunos patrones de acceso a los datos conducen a una fragmentación constante. El costo de reconstruir/reorganizar constantemente esas tablas puede no valer la pena y puede excluirse del mantenimiento. Esas situaciones deben evaluarse caso por caso.
Esto se aplica a las instalaciones locales, IaaS, Azure SQL Database y Azure SQL Managed Instance.
MAXDOP
Encuentro que el grado máximo de paralelismo y el umbral de costo para el paralelismo generalmente se dejan en los valores predeterminados en los servidores del cliente. Para MAXDOP, el valor predeterminado es cero, lo que significa que se podría usar un número "ilimitado" de CPU para ejecutar una región paralela de una consulta. Técnicamente, hasta 64 procesadores, a menos que habilite una marca de rastreo para usar más.
Hace una década, cuando los procesadores tenían menos núcleos, este valor era aceptable. Hoy en día, con una alta densidad de núcleos y servidores de múltiples sockets, una cantidad ilimitada de CPU para el paralelismo no es tan buena. Microsoft ha brindado orientación sobre qué valores usar para MAXDOP.
Si está en SQL Server 2008 – SQL Server 2014, para un solo nodo NUMA con menos de 8 procesadores lógicos, mantenga MAXDOP en o por debajo de la cantidad de procesadores lógicos. Si tiene más de 8 procesadores lógicos, mantenga MAXDOP en 8. Si tiene varios nodos NUMA con menos de 8 procesadores lógicos por nodo NUMA, mantenga MAXDOP en el número de procesadores lógicos por nodo NUMA o por debajo de este. Mayor que 8, mantenga MAXDOP en 8.
SQL Server 2016 introdujo nodos soft-NUMA. Durante el inicio del servicio, si Motor de base de datos detecta más de 8 núcleos físicos por nodo NUMA o socket, los nodos NUMA de software se crean automáticamente. El motor se encarga de colocar procesadores lógicos del mismo núcleo físico en diferentes nodos NUMA de software. Por ese motivo, tenemos una guía ligeramente diferente para MAXDOP para SQL Server 2016 en adelante.
Si utiliza SQL Server 2016 y versiones posteriores, para un único nodo NUMA con menos de 16 procesadores lógicos, mantenga MAXDOP en el número de procesadores lógicos o por debajo de este. Si tiene más de 16 procesadores lógicos, mantenga MAXDOP en 16. Si tiene varios nodos NUMA con menos de 16 procesadores lógicos por nodo NUMA, mantenga MAXDOP en el número de procesadores lógicos por nodo NUMA o por debajo de este. Más de 16, mantenga MAXDOP a la mitad de la cantidad de procesadores lógicos por nodo NUMA con un valor MAX de 16.
Si está virtualizado principalmente en máquinas con 8 o menos procesadores lógicos con un MAXDOP predeterminado, probablemente esté bien. Si tiene un gran hardware físico con valores predeterminados, debería considerar optimizar MAXDOP.
Todas las cifras anteriores son pautas, no verdades duras. Sus cargas de trabajo varían y se debe tener en cuenta al determinar qué valor es el más óptimo para su carga de trabajo.
La configuración de MAXDOP se aplica a instancias locales, IaaS y Azure SQL Managed Instance. Sin embargo, existe una configuración de ámbito de base de datos que se puede aplicar por base de datos a partir de SQL Server 2016, y esto se aplica a Azure SQL Database.
Umbral de costo para paralelismo
El umbral de costo para el paralelismo tiene un valor predeterminado de 5. El historial de este número se remonta a los primeros días de SQL Server y la estación de trabajo en la que se realizó la prueba de carga de trabajo. Con el hardware moderno, la estimación del costo de 5 está desactualizada. Las pruebas han demostrado que aumentar el número de 5 a un valor más alto evitará que las consultas de ejecución más corta tengan un plan paralelo. Tiendo a recomendar aumentar este valor a un número más alto después de examinar Plan Cache. En muchos casos termino comenzando con un valor de 25 y luego superviso más y ajusto desde allí, si es necesario. Para obtener más información sobre el ajuste del umbral de costo para el paralelismo, Jonathan Kehayias escribió:Ajuste del "umbral de costo para el paralelismo" de Plan Cache.
Esto se aplica a instancias locales, IaaS y Azure SQL Managed Instance.
Alertas del Agente SQL Server
Todos deberían aprovechar las alertas del Agente SQL, a menos que tengan una aplicación de terceros que supervise las mismas condiciones de error. Configurar alertas es fácil y gratuito, y tenerlas configuradas le brindará información crítica cuando sus servidores tengan problemas.
Escribí un artículo titulado Alertas del Agente SQL Server, que brinda instrucciones paso a paso sobre cómo crear alertas para errores de gravedad 19-25 y error 825. Habilitar estas alertas es fácil:habilite el correo de la base de datos, cree un operador de correo y luego cree el alertas Esto se puede lograr usando la GUI o con T-SQL. Animo a todos a escribir este proceso usando T-SQL y convertirlo en parte de su construcción de servidor estándar.
Esto se aplica a instancias locales, IaaS y Azure SQL Managed Instance.
Resumen
Como puede ver, hay muchas configuraciones que deben modificarse a partir de los valores predeterminados después de instalar SQL Server. Esta no es una lista comprensible; sin embargo, cubre muchos de los problemas más críticos y que afectan el rendimiento que encuentro, y que he agrupado en mi categoría de "contratiempos de SQL Server".
