Fragen und Antworten zu SQL Unerwartete Konsistenzprüfungen, Behandeln von Problemen mit der Speicherauslastung, Weiteres

Paul S. Randal

F ich etwas geschieht, da ich einige unserer Datenbanken zu SQL Server 2005 verschoben haben ungewöhnliches bemerkt haben. Wenn der Server startet, sehe ich Nachrichten in der Fehlermeldung Protokoll, dass SQL Server Konsistenzprüfungen für die Datenbank als Teil des Startvorgangs ausgeführt wird. Dies wird für einige Datenbanken jedoch nicht für die Systemdatenbanken. Die Schecks scheint sehr schnell ausgeführt, unabhängig davon, wie groß die Datenbank ist, und jedem Start von SQL Server auftreten. Können Sie erklären, was passiert?

Ahaben sehr wenige Personen dazu in verschiedenen Onlineforen gebeten wurde. Hier ist ein Beispiel eines die Fehlermeldungen fraglichen Protokolls:

2009-06-16 18:12:16.85 spid5s
CHECKDB for database 'master' finished without errors
on 2009-05-12 16:07:15.647 (local time).
This is an informational message only; 
no user action is required.

Es sicherlich aussieht DBCC CHECKDB (der gesamten Datenbank-Konsistenzprüfungen ausführt) auf "Master" ausgeführt wurdeDatenbank, aber in Wirklichkeit nicht. Diese Meldung ist einfach eine Statistik über die Datenbank die "letzten bekannten guten" aufgerufen reporting.Uhrzeit.

Von an SQL Server 2005, wenn DBCC CHECKDB beendet Konsistenzüberprüfung einer Datenbank ohne suchen alle Konsistenzfehler (d. h., die Datenbank ist beschädigt-free), die Zeit, DBCC CHECKDB abgeschlossen, wird in der Seite Start der Datenbank (eine einzelne Seite in der Datenbank, die wichtige Metadaten zu speichert) eingetragen.

Jedem Start eine Datenbank einrichten (auf Instanz starten oder einer Datenbank verbinden), wird die Boot-Seite überprüft, um festzustellen, ob eine gespeicherte "Letzte als funktionierend" bekanntenZeit, und wenn dies der Fall ist, es im Fehlerprotokoll gemeldet wird. Leider gibt es ist keine dokumentierten Möglichkeit, diesen Wert Abfragen, aber können Sie eine Anzahl von undokumentierte Befehlen gefunden werden. Sankar Reddy, ein MVP, Fellow kürzlich Blogged ein Skript, die es für Sie gemeldet wird.

Die Gründe hinter die "letzten bekannten guten" SpeichernZeit ist, dass es kann in einer Notfallwiederherstellung zu wissen, wie lange (potenziell) eine Datenbank beschädigt wurden möglicherweise sehr nützlich.

Fmöhte ich feststellen, wie viel Speicher SQL Server von jeder Datenbank verwendet wird. Ich bemerkt plötzlich mit fast allen den verfügbaren Speicher auf dem Server eine SQL Server 2005-Instanz, und ich bin besorgt, dass irgendwo ein Problem vorhanden ist. Ist es möglich, herauszufinden, wo dieser Speicher innerhalb von SQL Server aus verwendet wird?

Adie gute Nachricht ist, dass diese nicht wahrscheinlich ein Problem ist. SQL Server 2005 verwendet, wie viel Arbeitsspeicher Es ist bei Bedarf können jedoch reagiert auf Anforderungen für Arbeitsspeicher Druck aus dem Betriebssystem um Speicher freizugeben. Die plötzliche Speichernutzung angezeigt werden, ist wahrscheinlich den Pufferpool erweitern, damit mehr die Datenbank im Arbeitsspeicher gehalten werden.

Im Pufferpool (auch als Puffercache bezeichnet) ist Teil der Speichermodul Ebene in SQL Server und ist verantwortlich für die Verwaltung im Arbeitsspeicher kopiert Teile die Datendateien in verschiedenen Datenbanken in SQL Server-Instanz. Wenn eine Abfrage gestartet, die erfordert viel Datenbankseiten in den Speicher (beispielsweise für einen großen Tabellenscan oder eine Verknüpfung) lesen wird, kann dann der Pufferpool nehmen mehr Serverspeicher vom Betriebssystem so erweitert werden kann. Diese kann an die zusätzliche Seitenbilder im Speicher ohne notwendigerweise speicherinternen Kopien anderer Datenbankseiten verwerfen, die für andere Abfragen verwendet werden.

Übrigens ist einer der Vorteile des Hinzufügens von mehr Arbeitsspeicher für SQL Server verwenden, der Pufferpool größer sein kann. Dies bedeutet, dass mehr Daten im Speicher zu einem bestimmten Zeitpunkt können potenziell führt zu weniger e/A und besseren Durchsatz der Arbeitsauslastung.

Es gibt andere möglichen Ursachen für SQL Server mit sehr viel Speicher, für Instanz wenn eine sehr große Anzahl von unterschiedlichen Abfragepläne sind in einem anderen Speicherbereich aufgerufen Cache Plan aber meine Schätzwert zwischengespeichert wird, dass es ist besonders wahrscheinlich des Pufferpools befinden, werden wie zuvor beschrieben haben.

In SQL Server 2005 können Sie bestimmen für jede Datenbank mithilfe von Dynamic Management Ansicht sys.dm_os_buffer_descriptors welchen Anteil den Pufferpool verwendet wird. Diese einfache Abfrage informiert Sie, wie viele 8 KB-Seiten im Pufferpool für jede Datenbank sind:

SELECT   
  (CASE WHEN ([is_modified] = 1) THEN 'Dirty'
ELSE 'Clean' END) AS 'Page State',
  (CASE WHEN ([database_id] = 32767) THEN 'Resource Database'
ELSE DB_NAME (database_id) END) AS 'Database Name',
   COUNT (*) AS 'Page Count'FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id], [is_modified]
   ORDER BY [database_id], [is_modified];GO

Erläutert dies etwas mehr in den Blogbeitrag „in dem Speichermodul: Neuigkeiten in der Pufferkomplex?. "

Den Befehl DBCC MEMORYSTATUS können Sie für die anderen Abschnitte des Speichers, SQL Server verwendet, wie viel Speicher SQL Server-Instanz überwachen, Ganzes verwenden, jedoch lässt nicht die Speichernutzung zu pro Datenbank unterteilt werden. Schauen Sie sich Knowledge Base-Artikel 907877, die beschreibt "MEMORYSTATUS DBCC-Befehl verwenden, um Speicherauslastung auf SQL Server 2005 überwachen."

FMal so oft wird eine der Datenbanken auf unsere SQL Server 2005-Instanz "Fehlerverdähtig". Wir können nicht auf die Datenbank zugreifen, und der Status ist als FEHLERVERDÄCHTIG. Gelegentlich wird der Status RECOVERY_PENDING angezeigt. Wissen, dass dies wird durch Beschädigung der Art verursacht, aber können Sie erklären, was eigentlich bedeutet und wie wiederhergestellt? In der Regel landen wir müssen aus alten Sicherungen wiederherstellen und Datenverlust, der nicht ideal ist.

Aes ist viel Verwirrung über was diese zwei Datenbanken besagt Mittelwert, aber Sie korrigieren, dass Sie durch einige Form der Beschädigung verursacht haben. Beide geben Sie an etwas mit Absturz Wiederherstellung getrennt hat.

Wenn eine Datenbank nicht ordnungsgemäß heruntergefahren, ist (mit anderen Worten, wenn die Datenbank heruntergefahren Transaktionen ohne Commit enthalten sind) und wenn die Datenbank erneut gestartet wird, müssen Sie über Absturz Wiederherstellung wechseln. Absturz Wiederherstellung ist der Prozess der sicherstellen, dass alle Transaktionen, die bei der die Datenbank übernommen waren Herunterfahren ordnungsgemäß in der Datenbank wiedergegeben werden, und alle Transaktionen ohne Commit bei der das Herunterfahren werden in keiner Weise in der Datenbank nicht wiedergegeben.

Eine viel tiefer Erläuterung der Funktionsweise der Wiederherstellung finden Sie unter meinem Artikel auf "Grundlagen Protokollierung und Wiederherstellung in SQL Server-"aus der Ausgabe Februar 2009.

Eine Datenbank erkennt, ob es klar Herunterfahren heruntergefahren oder nicht wurde – diese Informationen werden in der Datenbankstartseite, die ich in der Antwort auf die erste Frage beschrieben gespeichert. Wenn Absturz Wiederherstellung erforderlich ist, dann das Transaktionsprotokoll muss zugänglich sein, wie Sie alle Details der Transaktionen (Commit speichert) wiedergegeben werden müssen und welche Transaktionen (ohne Commit) müssen Rollback. Wenn das Transaktionsprotokoll nicht verfügbar ist (da es, z. B. gelöscht wurde), Absturz Wiederherstellung kann nicht gestartet, und der Zustand der Datenbank wird RECOVERY_PENDING. Der RECOVERY_PENDING-Status bedeutet Wiederherstellung konnte nicht gestartet werden.

Wenn das Transaktionsprotokoll verfügbar ist, startet der Recovery-Absturz ausgeführt. Wenn Sie aus irgendeinem Grund abgeschlossen nicht möglich, die Datenbank transaktionell inkonsistent ist, und der Status wird als FEHLERVERDÄCHTIG. Der Status FEHLERVERDÄCHTIG bedeutet Wiederherstellung gestartet, aber konnte nicht abgeschlossen werden.

Es gibt zwei Gründe, die Wiederherstellung nicht beenden konnte. Der erste ist eine Beschädigung des Transaktionsprotokolls selbst führt einen Protokolldatensatz Transaktion, der von SQL Server verarbeitet werden können. Der zweite ist Beschädigungen in die Datendateien ist aufgetreten während dem Wiederherstellungsmechanismus um einen Protokolldatensatz Transaktion auf einer Datenbankseite anzuwenden oder um die Auswirkungen eines Protokolleintrags Transaktion auf einer Datenbankseite umzukehren versucht.

Ein Problem kann eine Datenbank in den FEHLERVERDÄCHTIGEN Zustand ablegen. Wenn eine Transaktion durch einen Benutzer oder Anwendung abgebrochen wird und die Datenbank beim Rollback der Auswirkungen der Transaktion beschädigt findet, der Rollback kann nicht abgeschlossen, und die Datenbank ist transaktional inkonsistent. In diesem Fall die Datenbank automatisch offline geschaltet wird und des Status auf als FEHLERVERDÄCHTIG.

Es gibt zwei allgemeine Möglichkeiten zur Wiederherstellung in dieser Situation. Der erste ist Wiederherstellen von Sicherungen auf dem neuesten Stand. Wenn Ihre Sicherungen alte sind, wahrscheinlich arbeiten und Daten verloren gehen, und Sie Ihre Sicherungsstrategie mit Ziel mehrere häufig um Wiederherstellung ermöglichen, ohne dass eine große Datenmenge sichern sollten neu bewerten. Siehe meinen Artikel "Grundlegendes zu SQL Server-Sicherungen"in der Juli 2009 Ausgabe TechNet Magazine für einige Tipps zur Planung einer Sicherungsstrategie. Wenn Sie die Wiederherstellung Route in Anspruch nehmen, sollten Sie immer versuchen, eine Sicherung Tail des Protokolls als in diesem Artikel erläutert, dies können Sie Recht einrichten zum Zeitpunkt des Problems wiederherstellen, die die Datenbank als FEHLERVERDÄCHTIG vorgenommen.

Wenn keine Sicherungen verfügbar sind, können Sie einen Mechanismus namens Modus Notfall Reparatur. Betrachten Sie meinem umfassende Blogbeitrag, die beschreibt diese Funktion, deren Verwendung erläutert und zeigt einige Beispiele für.

Fwir haben synchrone Datenbankspiegelung mit SQL Server 2005 installiert, und wir haben festgestellt, dass manchmal es ein paar Sekunden für die Datenbank Spiegelung dauern kann Failover durchführen, wenn etwas mit dem primären Server schief geht. Ich dachte, dass synchrone Datenbankspiegelung mithilfe eines an instant Fehlererkennung beauftragt wurde. Woran liegt das?

Adie Verwendung von einem Zeugenserver mit Datenbankspiegelung kann einfach der Spiegelung Server automatisch Failoverantwort auszulösen. Der Zeuge (oder nicht) stimmt mit der Spiegelung, ob es kann "sehen"der Prinzipalserver. Wenn sowohl der Zeuge als auch die Spiegelung den Prinzipal nicht sehen, wird die Spiegelung initiiert das Failover und wird der neue Prinzipal. Das Vorhandensein einer Zeuge Servers in einer Konfiguration für die Datenbankspiegelung hat keinen Einfluss auf wie schnell ein Fehler entdeckt oder wie schnell ist ein Failover auftritt.

Sofortige Fehlererkennung ist ein verbreitetes Missverständnis, wie schnell ein Fehler entdeckt wird hängt vom Typ des Fehlers. Hier einige Beispiele:

1. Stürzt ab, der SQL Server-Instanz (mit der principal Datenbank). Solange Windows noch ausgeführt und reagieren ist, sollten der Fehler in höchstens einer Sekunde erkannt werden. Jede Sekunde eine ping die Zeuge und Spiegelung den Prinzipal. Wenn der SQL Server-Instanz nicht auf den TCP-Port empfangsbereit ist, die konfiguriert wurde, wird Windows erkennt dies und kann sofort reagieren, dass SQL Server nicht vorhanden ist.
2. Der gesamte Prinzipalserver stürzt ab. In diesem Fall Windows ist nicht vorhanden zu sagen, dass SQL Server nicht den definierten TCP-Port abhört, sodass nichts zu sagen gibt es noch nichts vorhanden. In diesem Fall wird der Fehler erkannt werden bis das Spiegelung Partner Timeout verstreicht. Dies ist die Anzahl der pro Sekunde einmal Pings, die auf nicht geantwortet werden muss, bis die Spiegelung einen Ausfall auf seitens des Prinzipals deklariert. Standardmäßig diese Anzahl auf 10 Pings (und so 10 Sekunden) festgelegt ist, aber wenn Sie aus irgendeinem Grund erhöht wurde, wird die Fehlererkennung länger dauern.
3. Transaktionsprotokoll-Laufwerk auf dem Prinzipal schlägt fehl. Anfänglich geschieht nichts, außer dass e/A gestartet wird, um auf das Protokolllaufwerk Warteschlange einrichten. Nach 20 Sekunden wird SQL Server eine Warnung in das Fehlerprotokoll drucken. Es ist nicht bis 40 Sekunden verstrichen sind, dass der SQL Server das Protokolllaufwerk deaktiviert ­ Zeile deklarieren und die Datenbank sowie Offlineschalten, einen Spiegelung Fehler auslösen.
4. Eine Datenbankseite beschädigt. In diesem Fall wenn eine regelmäßige Abfrage Beschädigung die Treffer, geschieht nichts überhaupt zu spiegeln. Wenn eine Transaktion rückgängig gemacht und die Seite Beschädigung auftritt, wird die Datenbank als FEHLERVERDÄCHTIG, werden jedoch als in der vorherigen Antwort beschriebenen und, wird einen Spiegelung Fehler sofort ausgelöst.
5. Wenn eine Datei oder Dateigruppe in der Prinzipaldatenbank offline geschaltet wird und die primäre Dateigruppe ist nicht betroffen, partielle Datenbankverfügbarkeit wird in der Enterprise Edition in loszulegen, wodurch ein Fehler nicht auftritt. Standard Edition wird jedoch ein Fehler ausgelöst.

Wie Sie sehen können, hängt die Geschwindigkeit, mit der ein Spiegelung Fehler entdeckt wird, wirklich auf welche Art von Fehler tritt auf, und gibt an, ob die Spiegelung Partner-Zeitüberschreitung aufgetreten ist.

Vielen Dank an Kimberly L. Tripp von leitende SQLskills.com für technisch überprüfen ist dieses Monats Spalte.

Paul S. Randal ist der leitende Direktor von SQLskills.com, einen regionalen Microsoft Director und ein SQL Server-MVP. Er wird im SQL Server-Speichermodul Team bei Microsoft von 1999 zu 2007 gearbeitet. Paul schrieb DBCC CHECKDB/Repair für SQL Server 2005 und SQL Server 2008-Entwicklung für das Kernspeichermodul zuständig war. Randal ist Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung und ein regelmäßiger Referent bei Konferenzen weltweit. Er Blogs SQLskills.com/blogs/paul, und Sie können ihn unter Twitter.com/PaulRandal auf Twitter finden.