A medida que termina el 2014, estoy lanzando una serie de publicaciones sobre comprobaciones de estado proactivas de SQL Server, basadas en una que escribí a principios de este año:Problemas de rendimiento:el primer encuentro. En esa publicación, discutí lo que busco primero cuando soluciono un problema de rendimiento en un entorno desconocido. En esta serie de publicaciones, quiero hablar sobre lo que busco cuando me comunico con mis clientes a largo plazo. Brindamos un servicio de DBA remoto, y una de nuestras tareas regulares es una "mini" auditoría de salud mensual de su entorno. Contamos con monitoreo y, por lo general, estoy trabajando en proyectos, por lo que estoy en el entorno con regularidad. Pero como un paso adicional para asegurarnos de que no nos falta nada, una vez al mes revisamos los mismos datos que recopilamos en nuestra auditoría de salud estándar y buscamos cualquier cosa fuera de lo común. Eso podría ser muchas cosas, ¿verdad? ¡Sí! Entonces, comencemos con el espacio.
Vaya, ¿espacio? Sí, espacio. No te preocupes, pasaré a otros temas. ☺
Qué revisar
¿Por qué comenzaría con el espacio? Porque es algo que a menudo veo descuidado, y si se queda sin espacio en disco para los archivos de su base de datos, se vuelve extremadamente limitado en lo que puede hacer en su base de datos. ¿Necesita agregar datos pero no puede hacer crecer el archivo porque el disco está lleno? Lo sentimos, ahora los usuarios no pueden agregar datos. ¿No realiza copias de seguridad de registros por algún motivo, por lo que el registro de transacciones llena la unidad? Lo sentimos, ahora no puedes modificar ningún dato. El espacio es fundamental. Tenemos trabajos que monitorean el espacio libre en el disco y en los archivos, pero aun así verifico lo siguiente para cada auditoría y comparo los valores con los del mes anterior:
- Tamaño de cada archivo de registro
- Tamaño de cada archivo de datos
- Espacio libre en cada archivo de datos
- Espacio libre en cada unidad con archivos de base de datos
- Espacio libre en cada unidad con archivos de copia de seguridad
Crecimiento del archivo de registro
La mayoría de los problemas que veo relacionados con el espacio en disco se deben al crecimiento del archivo de registro. El crecimiento generalmente ocurre por una de dos razones:
- La base de datos se encuentra en recuperación COMPLETA y, por algún motivo, no se realizan copias de seguridad del registro de transacciones
- Alguien ejecuta una sola transacción muy grande que consume todo el espacio de registro existente, lo que obliga al archivo a crecer
También he visto crecer el archivo de registro como parte del mantenimiento del índice. Para reconstrucciones, cada asignación se registra y para índices grandes, eso puede generar una cantidad significativa de registro. Incluso con copias de seguridad regulares del registro de transacciones, el registro aún puede crecer más rápido de lo que pueden ocurrir las copias de seguridad. Para administrar el registro, debe ajustar la frecuencia de las copias de seguridad o modificar la metodología de mantenimiento de su índice.
Debe determinar por qué creció el archivo de registro, lo que puede ser complicado a menos que lo esté rastreando. Tengo un trabajo que se ejecuta cada hora para tomar una instantánea del tamaño y uso del archivo de registro:
USE [Baselines];
GO
IF (NOT EXISTS (SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'SQLskills_TrackLogSpace'))
BEGIN
CREATE TABLE [dbo].[SQLskills_TrackLogSpace](
[DatabaseName] [VARCHAR](250) NULL,
[LogSizeMB] [DECIMAL](38, 0) NULL,
[LogSpaceUsed] [DECIMAL](38, 0) NULL,
[LogStatus] [TINYINT] NULL,
[CaptureDate] [DATETIME2](7) NULL
) ON [PRIMARY];
ALTER TABLE [dbo].[SQLskills_TrackLogSpace] ADD DEFAULT (SYSDATETIME()) FOR [CaptureDate];
END
CREATE TABLE #LogSpace_Temp (
DatabaseName VARCHAR(100),
LogSizeMB DECIMAL(10,2),
LogSpaceUsed DECIMAL(10,2),
LogStatus VARCHAR(1)
);
INSERT INTO #LogSpace_Temp EXEC('dbcc sqlperf(logspace)');
INSERT INTO Baselines.dbo.SQLskills_TrackLogSpace
(DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus)
SELECT DatabaseName, LogSizeMB, LogSpaceUsed, LogStatus
FROM #LogSpace_Temp;
DROP TABLE #LogSpace_Temp; Utilizo esta información para determinar cuándo comenzó a crecer el archivo de registro y empiezo a revisar los registros y el historial de trabajos para ver qué información adicional puedo encontrar. El crecimiento del registro debe ser estático:el registro debe tener el tamaño adecuado y administrarse a través de copias de seguridad (si se ejecuta en recuperación COMPLETA), y si el archivo necesita ser más grande, necesito entender por qué y cambiar su tamaño en consecuencia.
Si está lidiando con este problema y aún no estaba rastreando de manera proactiva los eventos de crecimiento de archivos, es posible que aún pueda averiguar qué sucedió. SQL Server captura los eventos de crecimiento automático; Aaron Bertrand de SQL Sentry escribió en su blog sobre esto en 2007, donde muestra cómo descubrir cuándo ocurrieron estos eventos (siempre y cuando fueran lo suficientemente recientes como para seguir existiendo en el seguimiento predeterminado).
Tamaño y espacio libre en archivos de datos
Probablemente ya haya escuchado que sus archivos de datos deben tener un tamaño predeterminado para que no tengan que crecer automáticamente. Si sigue esta guía, probablemente no haya experimentado el evento en el que el archivo de datos crece inesperadamente. Pero si no está administrando sus archivos de datos, es probable que tenga un crecimiento regular, ya sea que se dé cuenta o no (especialmente con la configuración de crecimiento predeterminada del 10 % y 1 MB).
Hay un truco para predimensionar los archivos de datos:no desea dimensionar una base de datos demasiado grande, porque recuerde, si va a restaurar, digamos, un entorno de desarrollo o control de calidad, los archivos tienen el mismo tamaño, incluso si son no está lleno de datos. Pero aún desea administrar manualmente el crecimiento. Encuentro que los DBA tienen más dificultades con las nuevas bases de datos. Los usuarios comerciales no tienen idea de las tasas de crecimiento y la cantidad de datos que se agregan, y esa base de datos es un poco suelta en su entorno. Debe prestar mucha atención a estos archivos hasta que tenga una idea del tamaño y el crecimiento esperado. Utilizo una consulta que da información sobre el tamaño y el espacio libre:
SELECT
[file_id] AS [File ID],
[type] AS [File Type],
substring([physical_name],1,1) AS [Drive],
[name] AS [Logical Name],
[physical_name] AS [Physical Name],
CAST([size] as DECIMAL(38,0))/128. AS [File Size MB],
CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128. AS [Space Used MB],
(CAST([size] AS DECIMAL(38,0))/128) - (CAST(FILEPROPERTY([name],'SpaceUsed') AS DECIMAL(38,0))/128.) AS [Free Space],
[max_size] AS [Max Size],
[is_percent_growth] AS [Percent Growth Enabled],
[growth] AS [Growth Rate],
SYSDATETIME() AS [Current Date]
FROM sys.database_files; Cada mes, verifico el tamaño de los archivos de datos y el espacio utilizado, luego decido si es necesario aumentar el tamaño. También superviso el seguimiento predeterminado de los eventos de crecimiento, ya que me indica exactamente cuándo se produce el crecimiento. Con la excepción de las nuevas bases de datos, siempre puedo adelantarme al crecimiento automático de archivos y manejarlo manualmente. Bueno, casi siempre. Justo antes de las vacaciones del año pasado, el departamento de TI de un cliente me notificó que había poco espacio libre en una unidad (espero ese pensamiento para la siguiente sección). Ahora, la notificación se basa en un umbral de menos del 20 % gratis. Esta unidad tenía más de 1 TB, por lo que había alrededor de 150 GB libres cuando revisé la unidad. Todavía no era una emergencia, pero necesitaba entender adónde se había ido el espacio.
Al revisar los archivos de la base de datos para una base de datos, pude ver que estaban llenos, y el mes anterior cada archivo tenía más de 50 GB libres. Luego busqué en los tamaños de las tablas y descubrí que en una tabla se habían agregado más de 270 millones de filas en los últimos 16 días, lo que totaliza más de 100 GB de datos. Resulta que hubo una modificación del código y el nuevo código registraba más información de la prevista. Rápidamente configuramos un trabajo para purgar las filas y recuperar el espacio libre en los archivos (y arreglaron el código). Sin embargo, no pude recuperar espacio en disco; tendría que reducir los archivos y esa no era una opción. Luego tuve que determinar cuánto espacio quedaba en el disco y decidir si era una cantidad con la que me sentía cómodo o no. Mi nivel de comodidad depende de saber cuántos datos se agregan por mes:la tasa de crecimiento típica. Y solo sé cuántos datos se agregan porque superviso el uso de archivos y puedo estimar cuánto espacio se necesitará para este mes, para este año y para los próximos dos años.
Espacio de disco
Mencioné anteriormente que tenemos trabajos para monitorear el espacio libre en el disco. Esto se basa en un porcentaje, no en una cantidad fija. Mi regla general ha sido enviar notificaciones cuando menos del 10% del disco está libre, pero para algunas unidades, es posible que deba configurarlo más alto. Por ejemplo, con una unidad de 1 TB, recibo una notificación cuando hay menos de 100 GB libres. Con una unidad de 100 GB, recibo una notificación cuando hay menos de 10 GB libres. Con una unidad de 20 GB... bueno, ya ves a dónde voy con esto. Ese umbral debe alertarlo antes de que haya un problema. Si solo tengo 10 GB libres en una unidad que aloja un archivo de registro, es posible que no tenga suficiente tiempo para reaccionar antes de que aparezca como un problema para los usuarios, dependiendo de la frecuencia con la que verifique el espacio de tamaño libre y cuál sea el problema. es.
Es muy fácil usar xp_fixeddrives para verificar el espacio libre, pero no lo recomendaría ya que no está documentado y el uso de procedimientos almacenados extendidos en general ha quedado obsoleto. Tampoco informa el tamaño total de cada unidad y es posible que no informe sobre todos los tipos de unidades que pueden estar utilizando sus bases de datos. Siempre que esté ejecutando SQL Server 2008R2 SP1 o superior, puede usar sys.dm_os_volume_stats, que es mucho más conveniente, para obtener la información que necesita, al menos sobre las unidades donde existen los archivos de la base de datos:
SELECT DISTINCT vs.volume_mount_point AS [Drive], vs.logical_volume_name AS [Drive Name], vs.total_bytes/1024/1024 AS [Drive Size MB], vs.available_bytes/1024/1024 AS [Drive Free Space MB] FROM sys.master_files AS f CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id) AS vs ORDER BY vs.volume_mount_point;
A menudo veo un problema con el espacio en disco en los volúmenes que alojan tempdb. He perdido la cuenta de las veces que he tenido clientes con un crecimiento de tempdb inexplicable. A veces son solo unos pocos GB; más recientemente fue de 200 GB. Tempdb es una bestia complicada:no hay una fórmula a seguir para dimensionarlo y, con demasiada frecuencia, se coloca en una unidad con poco espacio libre que no puede manejar el evento loco causado por el desarrollador novato o DBA. El dimensionamiento de los archivos de datos de tempdb requiere que ejecute su carga de trabajo durante un ciclo comercial "normal" para determinar cuánto usa tempdb y luego dimensionarlo en consecuencia.
Recientemente escuché una sugerencia sobre una forma de evitar quedarse sin espacio en una unidad:cree una base de datos sin datos y dimensione los archivos para que consuman la cantidad de espacio que desee "reservar". Luego, si se encuentra con un problema, simplemente suelte la base de datos y vuelva a tener espacio libre. Personalmente, creo que esto crea todo tipo de otros problemas y no lo recomendaría. Pero si tiene administradores de almacenamiento a los que no les gusta ver cientos de GB sin usar en una unidad, esta sería una forma de hacer que una unidad "parezca" llena. Me recuerda algo que escuché decir a un buen amigo mío:"Si no puedo trabajar contigo, trabajaré a tu alrededor".
Copias de seguridad
Una de las tareas principales de un DBA es proteger los datos. Las copias de seguridad son un método utilizado para protegerlo y, como tal, las unidades que contienen esas copias de seguridad son una parte integral de la vida de un DBA. Presumiblemente, está manteniendo una o más copias de seguridad en línea, para restaurarlas inmediatamente si es necesario. Su libro de ejecución de SLA y DR ayuda a determinar cuántas copias de seguridad debe mantener en línea y debe asegurarse de tener ese espacio disponible. Le recomiendo que tampoco elimine las copias de seguridad antiguas hasta que la copia de seguridad actual se haya completado correctamente. Es demasiado fácil caer en la trampa de eliminar copias de seguridad antiguas y luego ejecutar la copia de seguridad actual. Pero, ¿qué sucede si falla la copia de seguridad actual? Y, ¿qué pasa si estás usando compresión? Espera un segundo... las copias de seguridad comprimidas son más pequeñas, ¿verdad? Son más pequeños, al final. Pero, ¿sabía que el tamaño del archivo .bak generalmente comienza más grande que el tamaño final? Puede usar el indicador de rastreo 3042 para cambiar este comportamiento, pero debe pensar que con las copias de seguridad, necesita mucho espacio. Si su copia de seguridad es de 100 GB y mantiene el valor de 3 días en línea, necesita 300 GB para los 3 días de copias de seguridad, y luego probablemente una cantidad saludable (el doble del tamaño de la base de datos actual) gratis para la próxima copia de seguridad. Sí, esto significa que en cualquier momento tendrá más de 100 GB libres en esta unidad. Está bien. Es mejor que tener éxito en el trabajo de eliminación y que falle el trabajo de copia de seguridad y descubrir tres días después que no tienes ninguna copia de seguridad (eso le pasó a un cliente en mi trabajo anterior).
La mayoría de las bases de datos aumentan de tamaño con el tiempo, lo que significa que las copias de seguridad también aumentan. No olvide verificar regularmente el tamaño de los archivos de copia de seguridad y asigne espacio adicional según sea necesario; tener una política de "200 GB gratis" para una base de datos que ha crecido a 350 GB no será muy útil. Si los requisitos de espacio cambian, asegúrese de cambiar también las alertas asociadas.
Uso del Asesor de rendimiento
Hay varias consultas incluidas en esta publicación que puede usar para monitorear el espacio, si necesita implementar su propio proceso. Pero si tiene SQL Sentry Performance Advisor en su entorno, esto se vuelve mucho más fácil con las Condiciones personalizadas. Hay varias condiciones de existencias incluidas de forma predeterminada, pero también puede crear las suyas propias.
Dentro del cliente de SQL Sentry, abra el Navegador, haga clic con el botón derecho en Grupos compartidos (Global) y seleccione Agregar condición personalizada → SQL Sentry. Proporcione un nombre y una descripción para la condición, luego agregue una comparación numérica y cambie el tipo a Consulta de repositorio. Introduzca la consulta:
SELECT MIN(FreeSpace*100.0/Size) FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk;
Cambie Igual a Es menor que y establezca un Valor explícito de 10. Finalmente, cambie la Frecuencia de evaluación predeterminada a algo menos frecuente que cada 10 segundos. Una vez al día o una vez cada 12 horas es probablemente un buen valor:no debería necesitar verificar el espacio libre más de una vez al día, pero puede verificarlo con la frecuencia que desee. La siguiente captura de pantalla muestra la configuración final:
Una vez que haga clic en Guardar para la condición, se le preguntará si desea asignar acciones para la condición personalizada. La opción Enviar a canales de alerta está seleccionada de forma predeterminada, pero es posible que desee realizar otras tareas, como Ejecutar un trabajo; por ejemplo, copiar copias de seguridad antiguas en otra ubicación (si esa es la unidad con poco espacio).
Como mencioné anteriormente, un espacio libre predeterminado del 10 % para todas las unidades probablemente no sea adecuado para todas las unidades de su entorno. Puede personalizar la consulta para diferentes instancias y unidades, por ejemplo:
SELECT Alert = MAX(CASE WHEN Name = N'C:' AND [FreeSpace%] < 10 THEN 1 WHEN Name = N'S:' AND [FreeSpace%] < 25 THEN 1 WHEN Name = N'T:' AND [FreeSpace%] < 20 THEN 1 ELSE 0 END) FROM ( SELECT d.Name, d.FreeSpace * 100.0/d.Size AS [FreeSpace%] FROM SQLSentry.dbo.PerformanceAnalysisDeviceLogicalDisk AS d INNER JOIN SQLSentry.dbo.EventSourceConnection AS c ON d.DeviceID = c.DeviceID WHERE c.ObjectName = N'HANK\SQL2012' -- replace with your server/instance ) AS s;
Puede modificar y expandir esta consulta según sea necesario para su entorno y luego cambiar la comparación en la condición en consecuencia (básicamente evaluando como verdadero si el resultado es alguna vez 1):
Si desea ver Performance Advisor en acción, no dude en descargar una versión de prueba.
Tenga en cuenta que para estas dos condiciones, solo se le alertará una vez, incluso si varias unidades caen por debajo de su umbral. En entornos complejos, es posible que desee inclinarse hacia una mayor cantidad de condiciones más específicas para proporcionar alertas más flexibles y personalizadas, en lugar de menos condiciones generales.
Resumen
Hay muchos componentes críticos en un entorno de SQL Server, y el espacio en disco es uno que necesita ser monitoreado y mantenido de manera proactiva. Con solo un poco de planificación, esto es fácil de hacer y alivia muchas incógnitas y la resolución reactiva de problemas. Ya sea que use sus propios scripts o una herramienta de terceros, asegurarse de que haya suficiente espacio libre para los archivos de la base de datos y las copias de seguridad es un problema que se puede resolver fácilmente y vale la pena el esfuerzo.
