MS SQL Server verlangsamt sich im Laufe der Zeit?

Hat einer von Ihnen Folgendes erlebt und eine Lösung gefunden:

Ein großer Teil des Backends unserer Website ist MS SQL Server 2005. Jede oder zwei Wochen läuft die Website langsamer - und ich sehe, dass Abfragen in SQL immer länger dauern. Ich habe eine Abfrage, die ich gerne verwende:

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

Was ziemlich nützlich ist ... es gibt einen Schnappschuss von allem, was gerade auf Ihrem SQL Server läuft. Das Schöne ist, dass diese Abfrage auch dann zurückgegeben wird, wenn Ihre CPU aus irgendeinem Grund auf 100% festgelegt ist und Activity Monitor das Laden verweigert (ich bin sicher, dass einige von Ihnen dort waren), immer noch zurückgegeben wird und Sie sehen können, welche Abfrage Ihre Datenbank zerstört.

Wenn ich dies oder den Aktivitätsmonitor während der Zeit ausführe, in der SQL langsamer wird, werden keine spezifischen Abfragen angezeigt, die das Problem verursachen. ALLE werden auf der ganzen Linie langsamer ausgeführt. Wenn ich den MS SQL-Dienst neu starte, ist alles in Ordnung, es beschleunigt sich - für ein oder zwei Wochen, bis es wieder passiert.

Nichts, woran ich denken kann, hat sich geändert, aber das hat erst vor ein paar Monaten begonnen ... Ideen?

--Hinzugefügt

Beachten Sie, dass es bei dieser Datenbankverlangsamung keine Rolle spielt, ob 100.000 Seitenaufrufe pro Stunde (geschäftigere Tageszeit) oder 10.000 Seitenaufrufe pro Stunde (langsame Zeit) angezeigt werden. Die Abfragen dauern alle länger als normal. Der Server ist nicht wirklich unter Stress - die CPU ist nicht hoch, die Festplattennutzung scheint nicht außer Kontrolle zu sein ... es fühlt sich an wie Indexfragmentierung oder ähnliches, aber das scheint nicht der Fall zu sein Fall.

Was das Einfügen der Ergebnisse der oben eingefügten Abfrage angeht, kann ich das wirklich nicht. Die obige Abfrage listet die Anmeldung des Benutzers auf, der die Aufgabe ausführt, die gesamte Abfrage usw. usw. und ich möchte die Namen meiner Datenbanken, Tabellen, Spalten und Anmeldungen wirklich nicht online verteilen :) ... I. Ich kann Ihnen sagen, dass die zu diesem Zeitpunkt ausgeführten Abfragen normale Standardabfragen für unsere Website sind, die ständig ausgeführt werden und nichts Außergewöhnliches sind.

- 24. März

Seit dem letzten Neustart sind ungefähr zwei Wochen vergangen. Ich habe einige Änderungen vorgenommen: Ich habe einige Abfragen gefunden, bei denen wir temporäre Tabellen stark genutzt haben, die völlig unnötig waren, und unsere Entwickler haben ihre Vorgehensweise ändern lassen. Ich habe die Größe einiger der ständig (langsam aber sicher) wachsenden Datenbanken auf eine intelligente Größe für ihr Wachstum angepasst. Ich habe die Einstellungen für das automatische Wachstum so angepasst, dass alles intelligenter ist (alle waren auf 1 MB Wachstum eingestellt). Zuletzt habe ich MSDB ein bisschen aufgeräumt. Wir protokollieren den Versand und mussten wirklich keine jahrelangen Sicherungspunkte aufbewahren. Ich habe einige Skripte geschrieben, die dies nur auf wenige Monate beschränken. Ich werde diesen Thread weiter aktualisieren, da es noch zu früh ist, um festzustellen, ob das Problem noch gelöst ist.

Wir haben es gefunden. Es stellte sich heraus, dass es sich tatsächlich um einen Webserver handelte, der ein Problem mit einem seiner App-Pools hatte. Es würde stecken bleiben und immer wieder die gleichen Abfragen ausführen (was zufällig in temporären Tabellen der Fall war). Es würde nur eine Schleife und eine Schleife bilden und schließlich dazu führen, dass der SQL Server traurig ist. Sobald dieser fehlerhafte Maschinen- / App-Pool gefunden und "abgelegt" wurde, wurde alles behoben.

Sie müssen sich fragen, was bei einem Neustart des SQL-Dienstes passiert. Vieles, aber zwei relevante Punkte fallen mir ein:

1) SQL-Speicher wird freigegeben.

Es ist möglich (nicht sicher, wie wahrscheinlich), dass, wenn Ihre MaxMemory-Einstellung zu hoch eingestellt ist, der SQL-Dienst wächst, um den gesamten verfügbaren Speicher zu nutzen, und Windows beginnt, wichtige Daten in die Auslagerungsdatei auszutauschen. Stellen Sie sicher, dass MaxMemory auf einen angemessenen Wert eingestellt ist und genügend zusätzlichen Speicher für alles übrig bleibt, was auf dieser Box ausgeführt werden muss (handelt es sich um einen dedizierten SQL-Server? Oder handelt es sich auch um den App-Server?).

2) TempDB wird aus den Standardgrößen neu erstellt.

Überprüfen Sie Ihre Standard-Tempdb-Dateigrößen, insbesondere die Standardgröße und das Wachstumsintervall der TempDB-Protokolldatei. Wenn das Wachstumsintervall zu niedrig eingestellt ist, kann das Protokoll eine unglaubliche interne Fragmentierung aufbauen, die die normale Nutzung drastisch verlangsamen kann. Sehen Sie sich diese beiden ausgezeichneten Blog-Artikel von Kimberly Tripp an.

Verwenden Sie häufig temporäre Tabellen oder Cursor? Überprüfen Sie, ob alle Cursor geschlossen und ordnungsgemäß freigegeben wurden. Achten Sie auch auf Verbindungsserver - wir müssen einen fehlerhaften Treiber für einen alten Verbindungs-Informix-Server verwenden, und dies bedeutet regelmäßig, dass wir den Server neu starten müssen.

Wenn es komisch aussieht, dann suche das Seltsame.

Wenn das Optimieren der SQL Server-Einstellungen nicht hilft, versuchen Sie es mit dem Windows-Task-Manager: Gehen Sie zur Registerkarte Prozesse, dann zu Optionen> Spalten> CPU-Zeit hinzufügen, Handles, Lesen, Schreiben, andere und die Speicheroptionen.

Gehen Sie zurück zur Prozessliste. Sortieren Sie für jede Spalte nach dem höchsten zum niedrigsten Wert und sehen Sie sich die fünf wichtigsten Prozesse an. Etwas Außergewöhnliches? Beispiel: Ein Speicherverlust in einem Prozess hat eine bizarre Anzahl von Handles. Wir haben einige * ki-Drucker, die dem DCSLoader-Prozess alle 2 Sekunden ein Handle hinzufügen. Nach ein paar Wochen listet eine Maschine viel freien Speicher und CPU auf, aber ein Prozess mit 100.000 Handles und bewegt den Mauszeiger kaum.

Überprüfen Sie auch Ihre Liste der geplanten Aufgaben. Weisen Sie Ihren AV an, keine .mdf-Dateien zu scannen.

Dave,

Haben Sie die Wartestatistiken überprüft? In der oben angegebenen Abfrage wird die Spalte 'last_wait_type' aufgeführt. Diese Spalte enthält möglicherweise einige Details dazu, worauf die Abfragen warten (Netzwerk, CPU usw.).

Wenn Ihr Backup "Wiederherstellungsmodell" VOLL ist, verbessert eine Sicherung der Datenbank und dann eine Sicherung der Transaktionsprotokolle die Dinge überhaupt? Auf einem System, auf dem nicht genügend Speicherplatz vorhanden ist, kann dies das Problem erklären.

Ich habe anscheinend eine Konfiguration, die Ihrer sehr ähnlich ist (16 GB, aktualisiert auf 32 GB, und MD1000 mit einem Terabyte Festplatten, Dual Quadcore XEON).

Das einzige, was mir in der Vergangenheit geholfen hat, solche bizarren Probleme zu diagnostizieren, ist beta_lockinfo von Erland Sommarskog. Führen Sie es aus, wenn es langsam ist, und vergleichen Sie es.

Außerdem hatte ich vor SP2 unglaublich viele Probleme mit SQL 2005, aber SP3 ist wirklich stabil.

Hoffe das gibt mehr nützliche Infos:

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

Stellen Sie sicher, dass db in Ordnung ist mit:

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

Behalten Sie den Logspace im Auge mit:

DBCC SQLPERF(LOGSPACE)

Wenn Sie eine Expansion sehen, wird dies die Dinge definitiv verlangsamen. Wenn Sie dies ausführen, wird Ihr Logspace immer näher an 100% heranrücken, dann wird das Log erweitert und der Prozentsatz wird kleiner, wenn er etwas Platz hat. Hoffentlich werden Sie nie sehen, wie es erweitert wird, bevor Ihr Backup startet und das Protokoll löscht.

Meistens idiotische Konfiguration. Das passiert.

• Zunächst sollten Sie die Indexdefragmentierung in einem Wartungslauf regelmäßig ausführen. Planen Sie es als Aktivität, kurz bevor oder nachdem Sie Backups erstellt haben.

• Zweitens sollten Sie Ihre Datenbank nicht automatisch vergrößern und insbesondere nicht automatisch verkleinern. Je nach Last sind Autogrow / Autoshrink grundsätzlich Selbstmordeinstellungen.

Ich habe noch nie so eine Verlangsamung von SQL Server gesehen. Können Sie die Ergebnisse dieser Abfrage in Zeiten großen Stresses veröffentlichen? Sicher, dass zu diesem Zeitpunkt nichts an Ihrem Ende SQL Server überlastet?