En mi artículo anterior sobre las bases de datos del sistema de SQL Server, aprendimos sobre cada base de datos del sistema que viene como parte de la instalación de SQL Server. El artículo actual se centrará en los problemas más frecuentes relacionados con la base de datos tempdb y cómo resolverlos correctamente.
Base de datos temporal de SQL Server
Como indica el nombre de esta base de datos del sistema, tempdb sostiene objetos temporales creado por SQL Server. Se relacionan con varias operaciones y actúan como un área de trabajo global para todos los usuarios que se conectan a las instancias de SQL Server.
La base de datos Tempdb contendrá los siguientes tipos de objetos mientras los usuarios realizan sus operaciones:
- Los usuarios crean explícitamente los objetos temporales. Pueden ser tablas e índices temporales locales o globales, variables de tabla, tablas utilizadas en funciones con valores de tabla y cursores.
- Objetos internos creados por el motor de base de datos como
- Tablas de trabajo que almacenan resultados intermedios para carretes, cursores, clasificaciones y objetos grandes temporales (LOB).
- Archivos de trabajo mientras se realizan operaciones Hash Join o Hash agregado.
- Resultados de ordenación intermedia al crear o reconstruir índices si SORT_IN_TEMPDB está activado y otras operaciones como consultas GROUP BY, ORDER BY o SQL UNION.
- Los almacenes de versiones que admiten la función de control de versiones de filas, ya sea el almacén de versiones comunes o el almacén de versiones de compilación de índice en línea, utiliza los archivos de base de datos tempdb.
La base de datos tempdb se crea cada vez que se inicia el servicio SQL Server. Por lo tanto, la hora de creación de la base de datos tempdb se puede considerar como una hora aproximada de inicio del servicio SQL Server. Podemos identificarlo desde sys.databases DMV utilizando la consulta que se muestra a continuación:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
Sin embargo, el inicio real de SQL Server Service implica iniciar todas las bases de datos del sistema en una secuencia específica. Puede ocurrir un poco antes de la hora de creación de tempdb. Podemos obtener el valor usando sys.databases DMV ejecutando la siguiente consulta en sys.dm_os_sys_info DMV .
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
Los ms_ticks La columna especifica el número de milisegundos desde que se inició la computadora o el servidor. El sqlserver_start_time_ms_ticks columna especifica el número de milisegundos desde que ms_ticks número cuando se inició el servicio de SQL Server.
Podemos encontrar más información sobre el orden de las bases de datos que se iniciaron al iniciar los servicios de SQL Server en el Registro de errores de SQL Server.
En SSMS, expanda Administración > Registros de errores del servidor SQL > abrir el actual registro de errores. Aplicar el Inicio subir base de datos filtra y haz clic en Fecha para ordenarlo en orden ascendente:
Podemos ver que la base de datos maestra se inició primero al iniciar el servicio de SQL Server. Luego siguieron todas las bases de datos de usuarios y todas las demás bases de datos del sistema. Finalmente, el tempdb comenzó. También puede obtener esta información mediante programación ejecutando xp_readerrorlog procedimiento del sistema:
Nota Nota:es posible que los dos enfoques anteriores no muestren la información necesaria si el servicio de SQL Server no se reinició recientemente y el registro de errores de SQL Server se recicló, lo que podría haber enviado registros de errores más antiguos a archivos más antiguos. En ese caso, es posible que necesitemos escanear los datos en los archivos de registro de errores de SQL Server archivados.
Problemas frecuentes en la base de datos SQL TempDB
Como tempdb proporciona un área de trabajo global para todas las sesiones o actividades de los usuarios, puede convertirse en un cuello de botella de rendimiento para las operaciones de los usuarios si no se configura cuidadosamente. En mi artículo anterior, discutimos las mejores prácticas recomendadas para implementar en la base de datos tempdb. Sin embargo, incluso después de implementarlos, es posible que encontremos problemas con frecuencia:
- Crecimiento desigual de archivos en archivos de datos tempdb.
- Los archivos de datos de Tempdb están creciendo a un valor enorme y necesitan reducir Tempdb.
Crecimiento desigual de archivos entre archivos de datos TempDB
A partir de SQL Server 2000, la recomendación predeterminada es tener varios archivos de datos según el número de núcleos lógicos disponibles en el servidor.
Cuando tenemos varios archivos de datos, por ejemplo, 4 archivos de datos tempdb como en la imagen a continuación, el crecimiento automático de los archivos de datos tempdb ocurrirá en 64 MB en forma rotativa a partir de tempdev> temp2> temp3> temp4> tempdev> y así sucesivamente.
Si uno de los tamaños de archivo no puede crecer automáticamente por alguna razón, resultará en tamaños enormes de ciertos archivos en comparación con otros archivos. Conduce a una sobrecarga adicional colocada en archivos grandes y un impacto negativo en el rendimiento de la base de datos tempdb.
Necesitamos asegurarnos manualmente de que todos los archivos de datos tempdb tengan el mismo tamaño en cualquier momento manualmente para evitar problemas de contención o rendimiento hasta SQL Server 2014. Microsoft cambió este comportamiento a partir de SQL Server 2016 y versiones posteriores al implementar algunas características que serán discutido más adelante en este artículo.
Para superar los problemas de rendimiento anteriores, SQL Server ha introducido 2 indicadores de seguimiento llamado 1117 y 1118 para evitar los problemas de contención en torno a tempdb.
- Bandera de rastreo 1117 – permite el crecimiento automático de todos los archivos dentro de un solo grupo de archivos
- Bandera de rastreo 1118 – habilita EXTENSIONES COMPLETAS UNIFORMES para tempdb
Bandera de rastreo 1117
Sin Trace Flag 1117 habilitado, cada vez que tempdb se configura con varios archivos de datos que tienen un tamaño uniforme y los archivos de datos deben crecer automáticamente, SQL Server de forma predeterminada intentará aumentar el tamaño de los archivos de forma rotativa si todos los archivos. Si los archivos de datos no tienen el mismo tamaño, entonces SQL Server intentará aumentar el tamaño del archivo de datos más grande de tempdb y utilizará este archivo más grande para la mayoría de las operaciones del usuario, lo que generará problemas de contención de tempdb.
Para resolver este problema, SQL Server introdujo Trace Flag 1117. Una vez habilitado, si un archivo dentro de un grupo de archivos necesita crecer automáticamente, crecerá automáticamente todos los archivos dentro de ese grupo de archivos. Resuelve los problemas de contención de tempdb. Sin embargo, el problema es que una vez que se habilita el indicador de seguimiento 1117, también se configura el crecimiento automático para todas las bases de datos de usuarios.
Bandera de seguimiento 1118
Trace Flag 1118 se utiliza para habilitar EXTENSIONES COMPLETAS UNIFORMES. Demos un paso atrás para entender cómo SQL Server almacena los datos básicos.
Página es la unidad fundamental de almacenamiento en SQL Server con un tamaño de 8 Kilobytes (KB).
Extensión es un conjunto de 8 páginas físicamente contiguas con un tamaño de 64 KB (8*8 KB). Según la cantidad de objetos o propietarios que almacenan los datos dentro de una extensión, la extensión se puede clasificar en:
- Extensiones uniformes son 8 páginas contiguas utilizadas o accedidas por un solo objeto o propietario;
- Mixto Extensiones – son 8 páginas contiguas utilizadas o accedidas por un mínimo de 2 y un máximo de 8 objetos o propietarios
Habilitar Trace Flag 1118 permitirá que tempdb tenga extensiones uniformes, lo que resultará en un mejor rendimiento.
Cómo habilitar las marcas de seguimiento 1117 y 1118
Trace Flags se puede habilitar a través de varios enfoques. Puede definir la forma adecuada de las siguientes opciones:
Parámetros de inicio del servicio de SQL Server
Disponible permanentemente incluso después de reiniciar el servicio SQL. La forma recomendada es habilitar Trace Flags 1117 y 1118 a través de los parámetros de inicio del servicio SQL Server .
Abra Administrador de configuración de SQL Server y haga clic en Servicios de SQL Server para listar los servicios disponibles en ese servidor:
- Haga clic derecho en Servidor SQL (MSSQLSERVER) > Propiedades > Parámetros de inicio .
- Tipo:T en el campo vacío para indicar la Bandera de seguimiento .
- Proporcione valores 1117 y 1118 como se muestra a continuación.
- Haga clic en Agregar para que se agreguen los indicadores de seguimiento como parámetros de inicio.
Luego haga clic en Aceptar para que las marcas de seguimiento se agreguen de forma permanente para esta instancia de SQL Server. Reinicie el servicio de SQL Server para que se reflejen los cambios.
TRACEON DBCC (, -1)
Habilite una marca de rastreo globalmente. El servicio de SQL Server perderá las marcas de seguimiento al reiniciar el servicio. Para habilitar una marca de rastreo globalmente, ejecute el siguiente script en una nueva ventana de consulta:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON ()
Habilite el indicador de seguimiento a nivel de sesión. Se aplica solo a la sesión actual creada por el usuario. Para habilitar un indicador de rastreo a nivel de sesión, ejecute el siguiente script en una nueva ventana de consulta:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
Para ver la lista de marcas de rastreo habilitadas en una instancia de SQL Server, podemos usar DBCC TRACESTATUS comando:
DBCC TRACESTATUS();
Como podemos ver, Los indicadores de seguimiento 1117 y 1118 están habilitados globalmente en mi instancia junto con la sesión .
Para desactivar un Trace Flag, podemos usar el comando DBCC TRACEOFF como:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
Mejoras de la base de datos temporal de SQL Server 2016
En las versiones de SQL Server de SQL Server 2000 a SQL Server 2014, debemos habilitar Trace Flags 1117 y 1118 junto con el monitoreo completo de tempdb para evitar problemas de contención de tempdb. A partir de SQL Server 2016 y versiones posteriores, los indicadores de seguimiento 1117 y 1118 se implementan de forma predeterminada.
Sin embargo, según mi experiencia personal, es mejor hacer crecer previamente tempdb a un tamaño enorme para evitar la necesidad de crecimiento automático varias veces y para eliminar los tamaños de archivo desiguales o los archivos únicos que SQL Server usa mucho .
Podemos verificar cómo se implementan Trace Flag 1117 y 1118 en SQL Server 2016:
Bandera de rastreo 1117 que establece el crecimiento automático de todos los archivos dentro de un grupo de archivos ahora es una propiedad del grupo de archivos . Podemos configurarlo mientras creamos un nuevo grupo de archivos o modificamos uno existente.
Para verificar la propiedad de crecimiento automático del grupo de archivos , ejecute el siguiente script desde sys.filegroups DMV :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
Para modificar la propiedad de crecimiento automático del grupo de archivos principal de la base de datos AdventureWorks , ejecutamos el siguiente script con AUTOGROW_ALL_FILES para hacer crecer automáticamente todos los archivos por igual o AUTOGROW_SINGLE_FILE para permitir el crecimiento automático de un solo archivo de datos.
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
Bandera de rastreo 1118 que establece la propiedad Extensión uniforme de los archivos de datos está habilitada de forma predeterminada para tempdb y todas las bases de datos de usuario a partir de SQL Server 2016 . No podemos cambiar las propiedades de tempdb, ya que ahora solo admite la opción Extensión uniforme.
Para bases de datos de usuarios, podemos modificar este parámetro. Las bases de datos maestra, modelo y msdb del sistema admiten extensiones mixtas de forma predeterminada y tampoco se pueden cambiar.
Para modificar los valores de propiedad de asignación de páginas mixtas para las bases de datos de usuario, use el siguiente script:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
Para verificar la propiedad de asignación de páginas mixtas, podemos consultar is_mixed_page_allocation_on columna de sys.databases DMV con el valor 0, que indica una asignación de página de extensión uniforme, y 1 para indicar la asignación de página de extensión mixta.
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
Los archivos de datos de TempDB crecen hasta alcanzar un valor enorme y requieren una reducción de TempDB
En SQL Server 2014 o versiones anteriores, si los indicadores de seguimiento 1117 y 1118 no se configuran correctamente junto con varios archivos de datos creados para la base de datos tempdb, algunos de esos archivos crecerán inevitablemente. Si sucede, un DBA generalmente intenta reducir los archivos de datos tempdb. Pero es un impropio enfoque para manejar este escenario.
Hay otras opciones disponibles para reducir la tempdb.
Consideremos los comandos DBCC disponibles para Shrink tempdb y los impactos de realizar estas operaciones.
DBCC SHRINKDATABASE
La DBCC SHRINKDATABASE El comando de la consola funciona al reducir el final de los archivos de datos/registro .
Para reducir con éxito una base de datos, el comando necesita espacio libre al final del archivo. Si hay transacciones activas al final del archivo, los archivos de la base de datos no se pueden reducir.
El impacto de ejecutar DBCC SHRINKDATABASE es que intentará borrar el espacio libre disponible al final de cada archivo de datos o archivo de registro que podría haberse reservado para el crecimiento futuro de los datos de la tabla. Por lo tanto, la ejecución de este comando puede generar tamaños de archivo desiguales que provoquen problemas de contención de tempdb.
La sintaxis para reducir una base de datos de usuario, por ejemplo, la base de datos Adventureworks sería
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);ARCHIVO REDUCTOR DBCC
DBCC SHRINKFILE El comando de la consola funciona de manera similar a DBCC SHRINKDATABASE, pero reduce los datos de la base de datos o los archivos de registro especificados .
Si identifica que un archivo de datos tempdb en particular es enorme, podemos intentar reducir ese elemento en particular usando DBCC SHRINKFILE como se muestra a continuación.
Tenga cuidado al usar este comando en tempdb porque si un archivo se reduce a un valor más bajo o más alto que otros archivos de datos, ese archivo de datos en particular no se usará de manera efectiva. O bien, se usará con más frecuencia, lo que provocará problemas de contención de tempdb.
La sintaxis para ejecutar la operación DBCC SHRINKFILE en un archivo de datos de AdventureWorks de 1 GB (1024 MB) sería:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
BÚFERES DE LIMPIEZA DE GOTAS DE DBCC
Los DBCC DROPCLEANBUFFERS El comando de consola se usa para borrar todos los búfer limpios del grupo de búfer y los objetos de almacén de columnas del grupo de objetos de almacén de columnas .
Simplemente ejecute el siguiente comando:
DBCC DROPCLEANBUFFERSDBCC FREEPROCCACHE
El DBCC FREEPROCCACHE el comando borra todo el caché del plan de ejecución del procedimiento almacenado .
SQL Server utiliza la memoria caché del plan de ejecución de procedimientos para ejecutar las mismas llamadas de procedimiento más rápido. Después de ejecutar DBCC FREEPROCCACHE, la caché del plan se borra. Por lo tanto, SQL Server debe volver a crear ese caché cuando se ejecuta el procedimiento almacenado en la instancia. Deja un impacto negativo grave cuando se ejecuta en las instancias de base de datos de producción.
¡No se recomienda ejecutar DBCC FREEPROCCACHE en la instancia de la base de datos de Producción!
La sintaxis para ejecutar DBCC FREEPROCCACHE es la siguiente:
DBCC FREEPROCCACHEDBCC FREESESSIONCACHE
El DBCC FREESESSIONCACHE comando borra la memoria caché de conexión de consulta de distribución de la instancia de SQL Server . Será útil cuando haya muchas consultas distribuidas ejecutándose en una instancia particular de SQL Server.
La sintaxis para ejecutar DBCC FREESESSIONCACHE sería:
DBCC FREESESSIONCACHECACHÉ DEL SISTEMA LIBRE DE DBCC
El DBCC FREESYSTEMCACHE comando borra todas las entradas de caché no utilizadas de todo el caché . SQL Server hace esto de forma predeterminada para que haya más memoria disponible para nuevas operaciones. Sin embargo, podemos ejecutarlo manualmente usando el siguiente comando:
DBCC FREESYSTEMCACHEComo sabemos, tempdb almacena todos los objetos de usuario temporales u objetos internos, incluidos el caché del plan de ejecución, los datos del grupo de búfer, los cachés de sesión y los cachés del sistema. Por lo tanto, ejecutar los 6 comandos DBCC anteriores ayudará a eliminar los archivos de datos tempdb que impiden el proceso normal de reducción.
A pesar de que hemos seguido los pasos sobre cómo reducir tempdb a través de varios enfoques, las mejores prácticas recomendadas para tratar con la base de datos tempdb se enumeran a continuación:
a. Reinicie SQL Server Services si es posible para recrear los archivos de datos tempdb de manera uniforme. El impacto potencial sería que perderíamos todos los planes de ejecución y otra información de caché discutida anteriormente.
b. Crezca previamente los archivos de datos de tempdb a un tamaño de archivo enorme disponible en la unidad que contiene los archivos de datos de tempdb. Esto evitará que SQL Server aumente el tamaño de los archivos de manera desigual en las versiones de SQL Server 2014 y anteriores.
c. Si los servicios de SQL Server no se pueden reiniciar debido a RTO o RPO, pruebe los comandos DBCC anteriores después de comprender claramente los impactos.
d. Reducir la base de datos tempdb o los archivos de datos no es un enfoque recomendado y, por lo tanto, nunca lo haga en su entorno de producción a menos que no haya otras opciones.
Conclusión
Hemos aprendido más sobre el funcionamiento interno de tempdb para que podamos configurar tempdb para un mejor rendimiento evitando problemas de contención en tempdb. También hemos analizado los problemas frecuentes en tempdb, las medidas disponibles en SQL Server en varias versiones y cómo manejarlo de manera eficiente. Además de eso, hemos examinado por qué la reducción de la base de datos tempdb o los archivos de datos no es un enfoque recomendado al tratar con la base de datos tempdb.
