MS SQL Server rallenta nel tempo?

Qualcuno di voi ha sperimentato quanto segue e ha trovato una soluzione:

Gran parte del back-end del nostro sito Web è MS SQL Server 2005. Ogni settimana o due settimane il sito inizia a funzionare più lentamente - e vedo che le query impiegano sempre più tempo per essere completate in SQL. Ho una domanda che mi piace usare:

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

Il che è abbastanza utile ... fornisce un'istantanea di tutto ciò che è in esecuzione proprio in quel momento contro il tuo server SQL. La cosa bella è che anche se la tua CPU è bloccata al 100% per qualche motivo e Activity Monitor si rifiuta di caricare (sono sicuro che alcuni di voi sono stati lì) questa query ritorna ancora e puoi vedere quale query sta uccidendo il tuo DB.

Quando eseguo questo, o Activity Monitor durante i periodi in cui SQL ha iniziato a rallentare, non vedo alcuna query specifica che causa il problema: sono TUTTI in esecuzione più lentamente su tutta la linea. Se riavvio il servizio MS SQL, allora tutto va bene, accelera subito - per una settimana o due fino a quando non si ripete.

Nulla che mi venga in mente è cambiato, ma questo è appena iniziato alcuni mesi fa ... Idee?

--Added

Si noti che quando si verifica questo rallentamento del database, non importa se stiamo ottenendo 100.000 visualizzazioni di pagina all'ora (ora del giorno più occupata) o 10.000 visualizzazioni di pagina all'ora (tempo lento), il completamento delle query richiede più tempo del normale. Il server non è davvero sotto stress: la CPU non è alta, l'utilizzo del disco non sembra essere fuori controllo ... sembra una frammentazione dell'indice o qualcosa del genere, ma non sembra essere il Astuccio.

Per quanto riguarda incollare i risultati della query che ho incollato sopra, non posso davvero farlo. La query sopra elenca il login dell'utente che esegue l'attività, l'intera query, ecc. Ecc. E non vorrei davvero distribuire online i nomi dei miei database, tabelle, colonne e accessi:) ... I posso dirti che le query in esecuzione in quel momento sono normali, query standard per il nostro sito che funzionano sempre, nulla fuori dalla norma.

- 24 marzo

Sono passate circa due settimane dall'ultimo riavvio. Ho apportato diverse modifiche: ho trovato alcune query in cui stavamo facendo un uso pesante di tabelle temporanee che erano totalmente inutili e che i nostri sviluppatori hanno cambiato il modo in cui lo stavano facendo. Ho adattato le dimensioni di alcuni dei database in costante (lento ma sicuro) sviluppo a una dimensione intelligente per la loro crescita. Ho regolato le impostazioni di crescita automatica per tutto e per essere più intelligente (erano TUTTI impostati su una crescita di 1 MB). Infine ho ripulito un po 'MSDB. Effettuiamo il log shipping e davvero non abbiamo avuto bisogno di mantenere anni e anni di punti di backup, ho scritto alcuni script che lo mantengono solo per pochi mesi. Continuerò ad aggiornare questo thread, poiché è troppo presto per dire se il problema è stato ancora risolto.

L'abbiamo trovato. Si è scoperto che in realtà era un server Web che aveva un problema con uno dei suoi pool di app. Rimarrebbe bloccato eseguendo lo stesso set di query più e più volte (che è successo a gestire le tabelle temporanee). Sarebbe solo loop and loop e alla fine causerebbe il server SQL essere triste. Una volta trovato questo pool di macchine / app offensivo e 'messo giù' tutto è stato risolto.

Devi chiederti, cosa succede al riavvio del servizio SQL? Molte cose, ma vengono in mente due punti rilevanti:

1) La memoria SQL viene liberata.

È possibile (non sono sicuro della probabilità) che, se l'impostazione MaxMemory è impostata su un valore troppo elevato, il servizio SQL cresce per utilizzare tutta la memoria disponibile e Windows inizia a scambiare elementi importanti nel file di scambio. Verifica che MaxMemory sia impostato su un valore ragionevole, lasciando sufficiente memoria aggiuntiva per qualsiasi altra cosa debba essere eseguita su quella casella (è un server SQL dedicato? O è anche il server delle app?)

2) TempDB viene ricostruito dalle dimensioni predefinite.

Controlla le dimensioni del tuo file tempdb predefinito, in particolare la dimensione predefinita e l'intervallo di crescita del file di registro TempDB. Se l'intervallo di crescita è impostato su BASSO, il registro può generare un'incredibile frammentazione interna, che può rallentare notevolmente il normale utilizzo. Vedi questi due eccellenti articoli sul blog di Kimberly Tripp.

Usi pesantemente tabelle o cursori temporanei? Verificare che eventuali cursori vengano chiusi e allocati correttamente. Fai anche attenzione ai server collegati: dobbiamo utilizzare un driver con errori per un vecchio server Informix collegato e ciò significa periodicamente che è necessario riavviare il server.

Se sembra strano, cerca quello strano.

Se modificare le impostazioni del server sql non aiuta a provare il task manager di windows: vai alla scheda processi, quindi opzioni> colonne> aggiungi tempo cpu, handle, lettura, scrittura, altro e opzioni di memoria.

Torna all'elenco dei processi. Per ogni colonna ordina per ordine dal più alto al più basso e osserva i primi 5 processi. Qualcosa fuori dall'ordinario? ad esempio, una perdita di memoria in un processo avrà un numero bizzarro di handle. Abbiamo alcune stampanti * ki che aggiungono un handle al processo DCSLoader ogni 2 secondi. Dopo alcune settimane una macchina elenca molta memoria libera e CPU ma un processo con 100.000 handle e sposta a malapena il puntatore del mouse.

Controlla anche l'elenco delle attività pianificate. Di 'al tuo AV di non scansionare i file .mdf.

Dave,

Hai controllato le statistiche di attesa? la query che hai dato sopra elenca la colonna 'last_wait_type'. quella colonna potrebbe contenere alcuni dettagli su cosa stanno aspettando le query (rete, CPU, ecc.)

Se il tuo "modello di recupero" di backup è COMPLETO, fare un backup del DB e quindi un backup dei registri delle transazioni migliora le cose? Su un sistema che sta esaurendo lo spazio su disco, questo tipo di cose potrebbe spiegare il problema.

Mi sembra di avere una configurazione molto simile alla tua (16Gb, aggiornata a 32Gb e MD1000 con un terabyte di dischi, dual quadcore xeon).

L'unica cosa che mi ha aiutato a diagnosticare bizzarri problemi come quello in passato è beta_lockinfo di Erland Sommarskog. Eseguilo quando è lento e confronta.

Inoltre ho avuto una folle quantità di problemi con SQL 2005 prima di SP2, ma SP3 è davvero stabile.

Spero che questo dia informazioni più utili:

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

Assicurati che db sia ok 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

Tieni d'occhio lo spazio di log con:

DBCC SQLPERF(LOGSPACE)

Se vedi l'espansione in corso, questo rallenterà sicuramente le cose. Se esegui questo, vedrai il tuo spazio di registro sempre più vicino al 100%, quindi il registro si espanderà e la percentuale si ridurrà man mano che avrà un po 'di spazio. Spero che non lo vedrai mai espandersi prima che il backup inizi e cancelli il registro.

Per lo più configurazione idiota. Succede.

• Innanzitutto, è necessario eseguire regolarmente la deframmentazione dell'indice in una corsa di manutenzione. Pianificalo come attività, subito prima o dopo aver effettuato i backup.

• In secondo luogo, non aumentare automaticamente la velocità del database e soprattutto non riporlo automaticamente. A seconda del carico, l'autogrow / autoshrink sono fondamentalmente impostazioni suicide.

Non ho mai visto un rallentamento di SQL Server come quello praticamente mai. Puoi pubblicare i risultati di quella query in periodi di forte stress? Non c'è nulla di sicuro che sovraccarichi SQL Server in quel momento?