MS SQL Server diminui com o tempo?

Algum de vocês já experimentou o seguinte e encontrou uma solução:

Uma grande parte do back-end do nosso site é o MS SQL Server 2005. Toda semana ou duas semanas o site começa a ficar mais lento - e vejo consultas demorando mais e mais para serem concluídas no SQL. Eu tenho uma consulta que eu gosto de 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

O que é bastante útil ... fornece um instantâneo de tudo o que está sendo executado naquele momento no servidor SQL. O interessante é que, mesmo que sua CPU esteja atrelada a 100% por algum motivo e o Activity Monitor esteja se recusando a carregar (tenho certeza que alguns de vocês já estiveram lá), essa consulta ainda retorna e você pode ver qual consulta está matando seu banco de dados.

Quando eu executo isso ou o Activity Monitor durante o tempo em que o SQL começou a ficar lento, não vejo nenhuma consulta específica causando o problema - elas TODAS estão sendo executadas mais lentamente. Se eu reiniciar o serviço MS SQL, tudo está bem, ele acelera - por uma semana ou duas até que aconteça novamente.

Nada em que consigo pensar mudou, mas isso começou há alguns meses atrás ... Idéias?

--Adicionado

Observe que, quando ocorre a desaceleração do banco de dados, não importa se estamos recebendo 100 mil visualizações de página por hora (hora mais movimentada do dia) ou 10 mil visualizações de página por hora (hora mais lenta), todas as consultas demoram mais para serem concluídas do que o normal. O servidor não está realmente estressado - a CPU não está alta, o uso do disco não parece estar fora de controle ... parece uma fragmentação de índice ou algo do tipo, mas esse não parece ser o caso.

Quanto a colar os resultados da consulta que colei acima, realmente não posso fazer isso. A Consulta acima lista o login do usuário que está executando a tarefa, toda a consulta, etc. etc. e eu realmente não gostaria de distribuir os nomes dos meus bancos de dados, tabelas, colunas e logins on-line:) ... podemos dizer que as consultas em execução naquele momento são normais, consultas padrão para o nosso site que são executadas o tempo todo, nada fora do normal.

- 24 de março

Já se passaram duas semanas desde a última reinicialização. Fiz várias alterações: encontrei algumas consultas em que estávamos fazendo uso pesado de tabelas temporárias que eram totalmente desnecessárias e nossos desenvolvedores mudaram a maneira como estavam fazendo isso. Ajustei o tamanho de alguns bancos de dados em constante crescimento (lenta mas seguramente) para um tamanho inteligente para o seu crescimento. Ajustei as configurações de crescimento automático para que tudo fosse mais inteligente (elas estavam TODAS configuradas para 1 MB de crescimento). Por fim, limpei um pouco o MSDB. Fazemos o envio de logs e realmente não precisamos manter anos e anos em pontos de backup, escrevi alguns scripts que mantêm isso por apenas alguns meses. Continuarei atualizando esse segmento, pois é muito cedo para saber se o problema já foi resolvido.

Nós achamos. Aconteceu que, na verdade, era um servidor da web que tinha um problema com um de seus pools de aplicativos. Ele ficava paralisado ao executar o mesmo conjunto de consultas repetidamente (o que acontecia nas tabelas temporárias). Seria apenas loop e loop e, eventualmente, faria o servidor SQL ficar triste. Depois que esse pool de aplicativos / máquinas ofensivos foi encontrado e 'descartado', tudo foi resolvido.

Você precisa se perguntar: o que acontece em uma reinicialização do serviço SQL? Muitas coisas, mas dois pontos relevantes vêm à mente:

1) a memória SQL é liberada.

É possível (sem ter certeza da probabilidade), que, se a configuração do MaxMemory estiver muito alta, o serviço SQL cresça para usar toda a memória disponível e o Windows comece a trocar coisas importantes pelo arquivo de troca. Verifique se o MaxMemory está definido como um valor razoável, deixando memória adicional suficiente para o que mais for necessário para executar nessa caixa (é um servidor SQL dedicado? Ou também é o servidor de aplicativos?)

2) O TempDB é reconstruído a partir dos tamanhos padrão.

Verifique os tamanhos padrão do arquivo tempdb, especialmente o tamanho padrão e o intervalo de crescimento do arquivo de log TempDB. Se o intervalo de crescimento estiver muito baixo, o log poderá criar uma incrível fragmentação interna, o que pode diminuir drasticamente o uso normal. Veja estes dois excelentes artigos de blog de Kimberly Tripp.

Você faz uso intenso de tabelas ou cursores temporários? Verifique se os cursores estão sendo fechados e desalocados corretamente. Também tenha cuidado com os servidores vinculados - precisamos usar um driver de buggy para um servidor Informix vinculado antigo e periodicamente significa que precisamos reiniciar o servidor.

Se parecer estranho, procure o estranho.

Se ajustar as configurações do servidor sql não ajudar a tentar o gerenciador de tarefas do Windows: vá para a guia processos, depois em opções> colunas> adicione tempo da CPU, manipula, lê, grava e outras opções de memória.

Volte para a lista de processos. Para cada coluna, classifique do mais alto para o mais baixo e observe os 5 principais processos. Alguma coisa fora do comum? por exemplo, um vazamento de memória em um processo terá um número bizarro de identificadores. Temos algumas impressoras * ki que adicionam um identificador ao processo DCSLoader a cada 2 segundos. Depois de algumas semanas, uma máquina lista muita memória livre e CPU, mas um processo com 100.000 identificadores e mal move o ponteiro do mouse.

Verifique também a sua lista de tarefas agendadas. Diga ao seu AV para não verificar arquivos .mdf.

Dave,

Você verificou as estatísticas de espera? a consulta que você deu acima lista a coluna 'last_wait_type'. essa coluna pode ter alguns detalhes sobre o que as consultas estão aguardando (rede, CPU, etc.)

Se o seu "Modelo de recuperação" de backup estiver COMPLETO, a execução de um backup do banco de dados e de um backup dos logs de transações melhorará as coisas? Em um sistema que está ficando sem espaço em disco, esse tipo de coisa pode explicar o problema.

Eu pareço ter uma configuração muito semelhante à sua (16 GB, atualizado para 32 GB e MD1000 com um terabyte de discos, dual quadcore xeon).

A única coisa que me ajudou a diagnosticar problemas bizarros como esse no passado é o beta_lockinfo de Erland Sommarskog. Execute-o quando estiver lento e compare.

Também tive muitos problemas com o SQL 2005 antes do SP2, mas o SP3 é realmente estável.

Espero que isso dê informações mais úteis:

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

Verifique se o db está bem com:

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

Fique de olho no espaço de registro com:

DBCC SQLPERF(LOGSPACE)

Se você ver a expansão acontecendo, isso definitivamente atrasará as coisas. Se você executar isso, verá seu espaço de log aproximar-se cada vez mais de 100%, o log será expandido e a porcentagem diminuirá à medida que houver espaço. Esperamos que você nunca consiga vê-lo expandir antes que seu backup entre em ação e limpe o log.

Principalmente configuração idiota. Acontece.

• Primeiro, você deve executar regularmente a desfragmentação do índice em uma execução de manutenção. Programe-o como atividade, imediatamente antes ou depois de fazer backups.

• Segundo, não faça o crescimento automático do seu banco de dados e, em especial, não o encaminhe automaticamente. Dependendo da carga, o autogrow / autoshrink são basicamente configurações de suicídio.

Não vi um SQL Server mais lento do que nunca. Você pode postar os resultados dessa consulta em períodos de estresse hugh? Tem certeza de que nada do seu lado sobrecarrega o SQL Server naquele momento?