MS SQL Server se ralentiza con el tiempo?

¿Alguno de ustedes ha experimentado lo siguiente y ha encontrado una solución?

Una gran parte del back-end de nuestro sitio web es MS SQL Server 2005. Cada semana o dos semanas el sitio comienza a funcionar más lentamente, y veo que las consultas tardan más y más en completarse en SQL. Tengo una consulta que me gusta usar:

USE master
select text,wait_time,blocking_session_id AS "Block",
percent_complete, * from sys.dm_exec_requests 
CROSS APPLY sys.dm_exec_sql_text(sql_handle)  AS s2 order by start_time asc

Lo cual es bastante útil ... ofrece una instantánea de todo lo que se está ejecutando en ese momento en su servidor SQL. Lo bueno es que, incluso si su CPU está vinculada al 100% por alguna razón y Activity Monitor se niega a cargar (estoy seguro de que algunos de ustedes han estado allí), esta consulta aún regresa y puede ver qué consulta está matando su base de datos.

Cuando ejecuto esto, o Activity Monitor durante los momentos en que SQL ha comenzado a disminuir, no veo ninguna consulta específica que cause el problema: TODOS se ejecutan más lentamente en todos los ámbitos. Si reinicio el servicio MS SQL, todo está bien, se acelera rápidamente, durante una semana o dos hasta que vuelva a suceder.

Nada de lo que se me ocurre ha cambiado, pero esto acaba de comenzar hace unos meses ... ¿Ideas?

--Adicional

Tenga en cuenta que cuando se produce esta ralentización de la base de datos, no importa si estamos obteniendo 100K visitas a la página por hora (hora más ocupada del día) o 10K visitas a la página por hora (tiempo lento), todas las consultas tardan más tiempo en completarse de lo normal. El servidor no está realmente bajo presión: la CPU no es alta, el uso del disco no parece estar fuera de control ... parece una fragmentación del índice o algo por el estilo, pero ese no parece ser el problema. caso.

En cuanto a pegar los resultados de la consulta que pegué anteriormente, realmente no puedo hacer eso. La consulta anterior enumera el inicio de sesión del usuario que realiza la tarea, la consulta completa, etc., y realmente no me gustaría entregar los nombres de mis bases de datos, tablas, columnas y los inicios de sesión en línea:) ... I podemos decirle que las consultas que se ejecutan en ese momento son consultas normales y estándar para nuestro sitio que se ejecutan todo el tiempo, nada fuera de lo normal.

24 de marzo

Han pasado aproximadamente dos semanas desde el último reinicio. Hice varios cambios: encontré algunas consultas en las que hacíamos un uso intensivo de las tablas temporales que eran totalmente innecesarias y nuestros desarrolladores cambiaron cómo lo hacían. Ajusté el tamaño de algunas de las bases de datos en constante crecimiento (lento pero seguro) a un tamaño inteligente para su crecimiento. Ajusté la configuración de crecimiento automático para que todo fuera más inteligente (TODOS estaban configurados con un crecimiento de 1 MB). Por último, limpié un poco MSDB. Realizamos envíos de registros y realmente no necesité mantener años y años de puntos de respaldo, he escrito algunos scripts que mantienen esto solo unos pocos meses. Seguiré actualizando este hilo, ya que es demasiado pronto para saber si el problema ya está resuelto.

Lo encontramos. Resultó que en realidad era un servidor web que tenía un problema con uno de sus grupos de aplicaciones. Se quedaría atascado ejecutando el mismo conjunto de consultas una y otra vez (lo que sucedió en las tablas temporales). Simplemente se repetirá y eventualmente hará que el servidor SQL esté triste. Una vez que se encontró esta máquina ofensiva / grupo de aplicaciones y se 'eliminó' todo se resolvió.

Tiene que preguntarse, ¿qué sucede al reiniciar el servicio SQL? Muchas cosas, pero me vienen a la mente dos puntos relevantes:

1) Se libera memoria SQL.

Es posible (no estoy seguro de qué tan probable), si su configuración MaxMemory está configurada demasiado alta, el servicio SQL crece para usar toda la memoria disponible y Windows comienza a intercambiar cosas importantes en el archivo de intercambio. Verifique para asegurarse de que MaxMemory esté configurado en un valor razonable, dejando suficiente memoria adicional para cualquier otra cosa que se necesite ejecutar en ese cuadro (¿es un servidor SQL dedicado? ¿O también es el servidor de aplicaciones?)

2) TempDB se reconstruye a partir de los tamaños predeterminados.

Compruebe los tamaños de archivo tempdb predeterminados, especialmente el tamaño predeterminado y el intervalo de crecimiento del archivo de registro TempDB. Si el intervalo de crecimiento se establece demasiado BAJO, entonces el registro puede generar una fragmentación interna increíble, que puede ralentizar drásticamente el uso normal. Vea estos dos excelentes artículos de blog de Kimberly Tripp.

¿Hace un uso intensivo de tablas o cursores temporales? Verifique que los cursores se estén cerrando y desasignando correctamente. También tenga cuidado con los servidores vinculados: tenemos que usar un controlador defectuoso para un antiguo servidor Informix vinculado y periódicamente significa que tenemos que reiniciar el servidor.

Si se ve raro, entonces busca lo extraño.

Si ajustar la configuración del servidor SQL no ayuda a probar el administrador de tareas de Windows: vaya a la pestaña de procesos, luego a las opciones> columnas> agregue tiempo de CPU, identificadores, lectura, escritura, otros y las opciones de memoria.

Regrese a la lista de procesos. Para cada columna, ordene de mayor a menor y observe los 5 procesos principales. ¿Algo fuera de lo común? Por ejemplo, una pérdida de memoria en un proceso tendrá un número extraño de identificadores. Tenemos algunas impresoras * ki que agregan un controlador al proceso DCSLoader cada 2 segundos. Después de algunas semanas, una máquina enumera mucha memoria y CPU libres, pero un proceso con 100,000 controladores y apenas mueve el puntero del mouse.

Consulte también su lista de tareas programadas. Dígale a su AV que no escanee archivos .mdf.

Dave

¿Has revisado las estadísticas de espera? la consulta que realizó anteriormente enumera la columna 'last_wait_type'. esa columna puede tener algunos detalles sobre lo que están esperando las consultas (red, CPU, etc.)

Si su "Modelo de recuperación" de copia de seguridad está COMPLETO, ¿tomar una copia de seguridad de la base de datos y luego una copia de seguridad de los registros de transacciones mejora las cosas? En un sistema que se está quedando sin espacio en disco, este tipo de cosas podrían explicar el problema.

Parece que tengo una configuración muy similar a la tuya (16 Gb, actualizada a 32 Gb, y MD1000 con un terabyte de discos, doble quadcore xeon).

Lo único que me ha ayudado a diagnosticar problemas extraños como ese en el pasado es beta_lockinfo de Erland Sommarskog. Ejecútelo cuando sea lento y compare.

También he tenido una cantidad increíble de problemas con SQL 2005 antes de SP2, pero SP3 es realmente estable.

Espero que esto brinde más información útil:

SELECT  D.text SQLStatement,
        A.Session_ID SPID,
        C.BlkBy,
        ISNULL(B.status, A.status) Status,
        A.login_name Login,
        A.host_name HostName,
        DB_NAME(B.Database_ID) DBName,
        B.command,
        ISNULL(B.cpu_time, A.cpu_time) CPUTime,
        ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO,
        A.last_request_start_time LastBatch,
        A.program_name
FROM    sys.dm_exec_sessions A
        LEFT JOIN sys.dm_exec_requests B
        ON A.session_id = B.session_id
        LEFT JOIN (
                   SELECT   A.request_session_id SPID,
                            B.blocking_session_id BlkBy
                   FROM     sys.dm_tran_locks AS A
                            INNER JOIN sys.dm_os_waiting_tasks AS B
                            ON A.lock_owner_address = B.resource_address
                  ) C
        ON A.Session_ID = C.SPID
        OUTER APPLY sys.dm_exec_sql_text(sql_handle) D
WHERE   DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's
ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC

Asegúrese de que db esté bien con:

DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database.
DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views

Vigile el espacio de registro con:

DBCC SQLPERF(LOGSPACE)

Si ve que la expansión continúa, eso sin duda retrasará las cosas. Si ejecuta esto, verá que su espacio de registro se acerca cada vez más al 100%, luego el registro se expandirá y el porcentaje se reducirá a medida que tenga algo de espacio. Con suerte, nunca podrá ver cómo se expande antes de que su copia de seguridad se active y borre el registro.

Configuración principalmente idiota. Sucede

• Primero, debería ejecutar regularmente desfragmentación de índice en una ejecución de mantenimiento. Programe como actividad, justo antes o después de hacer copias de seguridad.

• En segundo lugar, no crezca automáticamente su base de datos y, especialmente, no la reduzca automáticamente. Dependiendo de la carga, el crecimiento automático / autoencogimiento son básicamente configuraciones suicidas.

No se ha visto un SQL Server más lento que nunca. ¿Puedes publicar los resultados de esa consulta en momentos de gran estrés? ¿Seguro que nada en su extremo sobrecarga SQL Server en ese momento?