SQL – Fragen und Antworten: Dynamic Data and Disaster Recovery

  • Artikel

In diesem Monat-Lösungen für den Erfolg von SQL führen den Farbumfang aus einer Tempdb erweitern und ein Problem half-baked Disaster Recovery-Pläne-clustering.

Paul S. Randal

Platz ausfüllen

F: Eine der für die ich verantwortlich bin Produktionsserver hat ein Problem. Die tempdb-Datenbank wächst großes Instanzobjekt alle paar Tage. Dies ist ein relativ neues Problem. Die Unterschiede in der Anzahl der Verbindungen an den Server oder die Speicherauslastung wird nicht angezeigt. Wie können Sie die Situation überwachen um zu bestimmen, was den Tempdb-Speicherplatz belegt?

A. Es gibt zahlreiche Gründe für die Verwendung von Tempdb wachsen konnte:

  • Verwenden des Versioning Systems (für Snapshot-Isolation oder Onlineindexvorgänge, z. B.) könnte den Versionsspeicher in Tempdb zu wachsen.
  • Ein Abfrageplan konnte aufgrund der veraltete Statistiken ändern, die wiederum einem Abfrage-Plan-Operator die Ergebnisse in einem großen Spill Speicher in Tempdb verursachen würde.
  • Ein Benutzer kann neue Anwendungscode bereitgestellt haben, die temporäre Tabellen zu speichern, die teilweise verarbeitet Daten verwendet.

Was auch immer es ist, gibt es einige einfachen Möglichkeiten zum Aufspüren, was vor sich geht. Als Erstes sollten Sie tun, ist die allgemeine Verwendung des Tempdb-Speicherplatz mit der Dynamic Management View (DMV) sys.dm_db_file_space_usage zu untersuchen. Wenn Sie die Ergebnisse dieser DMV alle 30 Sekunden erfasst haben, z. B. sind Sie um festzustellen, ob die Verwendung zusätzlicher Platz vom Versionsspeicher, Benutzerobjekte oder Objekte, die zur Unterstützung der Abfrageverarbeitung der erstellt wird.

Wenn der Versionsspeicher, der den Speicherplatz beansprucht ist, können Sie mit Hilfe der sys.dm_tran_top_version_generators DMV Drilldown. Müssen Sie es mit sys.partitions und sys.indexes abzurufenden wirklich nützlichen Informationen aus beitreten, aber, informiert Sie darüber, welche Tabellen haben die meisten Versionen generiert wird.

Wenn es etwas else Speicherplatz belegen ist, können Sie einen Drilldown durch die Erfassung der Ergebnisse aus sys.dm_db_task_space_usage mit einer ähnlichen Häufigkeit. Fügen Sie dann die DMV mit dm_exec_requests, um herauszufinden, welche Verbindungen und Abfragen Speicher belegen sind.

Wenn sich herausstellt eine lange gespeicherte Prozedur sein, müssen Sie Instrumentieren die Prozedur, um die Tempdb-Speicherplatz verwendet, so dass Sie arbeiten können, welche Anweisungen innerhalb der Prozedur der Schuldigen sind in regelmäßigen Abständen ausgeben. Ich habe es mehrere Male auf Client-Systemen zu tun.

Finden Sie viel mehr Informationen über die Verwendung von diesen DMVs im White Paper "Working with tempdb in SQL Server 2005." (Dieses Dokument gilt auch für spätere Versionen von SQL Server.)

Gute Clustern

F: Angenommen Sie wurden gebeten, das Schema für eine Datenbank entwerfen, die Daten für eine neue Anwendung gespeichert werden sollen. Ich habe alle Arten von Beratung über die Auswahl von "guten" gruppierten Indexschlüssel für meine Tabellen gelesen. Können Sie erklären, was eine "gute" gruppierten Indexschlüssels macht und warum dies so sehr wichtig ist?

A. Dies ist eine komplexe Frage und nahezu unmöglich, hier umfassend zu beantworten. Kurz gesagt, ist ein "gute" Schlüssel des gruppierten Indexes eine, die sorgfältig ausgewählt worden ist, um eine schlechte Leistung und unnötig belegtem Speicherplatz zu minimieren. The four qualities of a good clustered index key are: narrow, static, unique and ever-increasing:

  • Narrow (taking up as few bytes as possible): All non-clustered index records include the clustered index key. Je größer ist, beansprucht mehr Speicherplatz doppelte Informationen in nicht gruppierten Indizes.
  • Static (unchanging): Changes to key values are expensive. SQL Server ist eine wichtige Aktualisierung als Löschvorgang + Einfügevorgang (finden Sie in meinem Blogbeitrag here), und jedes Mal einen gruppierten Indexschlüssels aktualisiert wird, alle übereinstimmende Zeilen in nicht gruppierten Indizes auch aktualisiert werden müssen. Wichtige Änderungen können auch auf freien Speicherplatz auf Seiten von Daten führen, wenn dieser Schlüssel Position im Index nicht mehr verwendet wird.
  • Unique: This avoids having SQL Server add a hidden four-byte column to “uniquify” duplicate key values—thus making the key wider.
  • Ever-increasing: The insert pattern of new records does result in random inserts into the clustered index that can cause expensive page-split operations. Dies führt die logische Fragmentierung und unnötig belegtem Speicherplatz auf Datenseiten-Dateien.

Angesichts dieser Qualitäten für eine gute gruppierten Indexschlüssels, ein natürlicher Schlüssel, die geeignet ist oft gibt es keine (z. B. eine abgeleitet von den Tabellendaten), so dass Sie einen Ersatzschlüssel (z. B. eine künstliche Tabellenspalte) verwenden. Eine BIGINT IDENTITY-Spalte ist ein Beispiel für einen guten Ersatzschlüssel. Lesen Sie Weitere ausführliche Erläuterungen und Begründungen Kimberly Tripp Blog Kategorie Clustering Key.

Für den schlimmsten Fall vorbereiten

F: In der die jüngsten Erdbeben in Neuseeland und Japan die Aktivierung erfolgt ich Disaster Recovery-Plan untersucht und festgestellt, dass es wirklich veraltet ist. Ich habe erfolglos versucht, unser Unternehmen umarbeiten und Testen den Plan zu erhalten. Nicht einfach Meinung sind, müssen wir uns jemals eine Katastrophe. Können Sie mir einige Tipps zur Verwendung mit Management Ansatz mitteilen?

A. Ich freue mich zu hören, dass Sie Ihre Disaster Recovery (DR) Strategie in der Wake diese vergangenen Katastrophen proaktiv analysieren. Viele Unternehmen sind verletzt und haben die Haltung, die Sie in Ihrer Frage beschreiben. Auch umfangreiche Naturkatastrophen relativ selten sind, mehr lokalisierte Probleme wie der Erstellung von Bränden oder Stromausfälle sind relativ häufig, und ein Unternehmen sollte nicht angenommen es zufällige Fehler immun ist.

Selbst wenn Sie auf der Seite Management abrufen können, ist eine umfangreiche Tests, Sie können selbst, wie Kopien von Datenbanken aus Sicherungen wiederherstellen durchführen. Dies prüft die Integrität von Sicherungen und backup-Strategie, und Sie können sicherstellen, dass die Zeit für die Wiederherstellung der maximal zulässige Ausfallzeit für eine bestimmte Datenbank erfüllt. Sehr oft ist dies das erste Problem beim Testen von Disaster Recovery-Strategie gefunden. Daten-Volumes im Laufe der Zeit wachsen und Zeit erhöht sich entsprechend wiederherzustellen.

Andere Teile der DR-Strategie sind viel schwerer zu selbst, wie z. B. bei einem Failover ein Datenbankspiegelungs-Partnerschaft oder einem Failovercluster zu testen. Beide erfordern einige Ausfallzeiten von Anwendungen (beide Failover und Failback).

As far as convincing management is concerned, ask them whether they’d rather find out the DR strategy doesn’t work during a planned test with all staff on-hand to assist with the recovery, or when disaster strikes for real at 2 a.m. on a public holiday when only a bare-minimum staff is on-hand.

Es gibt zahlreiche hoch veröffentlichten Vorfälle der Unternehmen, die Ausfälle leiden, da eine DR-Strategie nicht ausreichend war. Möchte Management ihrem Unternehmen weiter in die Schlagzeilen werden? Melodramatic klingt vielleicht, aber es ist ein fairer Punkt.

Disaster Recovery ist alles über die Minimierung der Kosten für das Unternehmen und seinen Kunden. Wenn Clients aufgrund von Ausfällen Leiden oder Vertrauen in die Fähigkeit des Unternehmens zur schnellen Wiederherstellung verloren haben, können sie an anderer Stelle ihres Unternehmens dauern. Dies beeinträchtigt die offensichtlich das Betriebsergebnis.

Als Technologen müssen wir bitten Sie Management, IT-Katastrophen hinsichtlich der finanziellen Auswirkungen auf das Unternehmen zu betrachten. Ich habe hier, um eine effektive Taktik in Management investieren Zeit und Geld in untätig und Testen von Disaster Recovery-Strategie verleitet werden gefunden. Weitere Informationen hierzu finden Sie in meinem neuesten Blog über here.

Komprimieren von Kosten

F: Ich würde gern das Datenkomprimierung Feature in SQL Server 2008 verwenden, um unsere Speicherkosten reduzieren, aber ich habe gelesen, ist nur für Datawarehouses, und ich werde enorme Performance-Probleme entstehen, wenn ich versuche, ihn in ein System online Transaction processing (OLTP) verwenden. Ist das wahr?

A. Diese Antwort ist richtig, dass das Feature der Datenkomprimierung Datawarehouse verwenden ursprünglich vorgesehen war. Datenkomprimierung verringert die Größe der Tabelle und der Index-Datensätze. Dies bedeutet mehr Datensätze auf einer Seite 8 KB Daten Datei passt und daher weniger Seiten der Daten sind erforderlich, um die Daten auf dem Datenträger zu speichern. Daraus ergeben sich kleinere Speicherplatzanforderungen für die Datenbank, halten die komprimierten Daten, was wiederum zu erhebliche Kosteneinsparungen führen kann, da weniger Speicher der Enterprise-Klasse erforderlich ist.

Der Kompromiss ist natürlich, dass die Daten vor der Verwendung dekomprimiert werden müssen. Die Daten ist nicht dekomprimiert werden, wenn Sie in der SQL Server-Pufferpool (in-Memory-Cache-Datei Datenseiten) gelesen wird. Es wird nur dekomprimiert, wenn er tatsächlich benötigt wurde, um eine Abfrage zu erfüllen. Dekomprimierung verwendet CPU-Ressourcen, also ein Kompromiss Speicherplatznutzung gegen CPU-Ressourcen.

Ein typischen Datawarehouse verfügt über eine große Datenmenge (denken Hunderte von Gigabyte bis mehrere Terabyte). Das Zugriffsmuster für diese Daten ist in der Regel eine große Datenmenge in den Pufferpool eingelesen einmal verarbeitet und anschließend nicht wieder verwendet lange genug, die es nicht genügend Arbeitsspeicher entfernt wurde.

Mit diesem Muster Access ist es sinnvoll, die Anzahl der e/a-Lesevorgänge zu minimieren, indem Sie die Daten auf eine viel kleinere Größe komprimiert. Dies müsste weniger SQL Server-Datei-Seiten zu speichern, und weniger e/a-Operationen auf diesen Seiten zu lesen. Dies führt in der Regel für eine schnellere Abwicklung dieser Abfragetypen. Eine weitere Kompromiss ist die Abfragegeschwindigkeit gegen die CPU-Ressourcen (für das Dekomprimieren von Daten).

Wenn Sie eine OLTP-Arbeitslast in Betracht ziehen, besteht in der Regel viel höhere Volatilität der Daten als in einem Datawarehouse. Dies bedeutet, wenn Sie Datenkomprimierung verwenden, erhalten Sie eine hohe CPU-Kosten aufgrund der Konstanten Dekomprimierung der eingelesenen Daten und Komprimierung der Daten eingefügt oder aktualisiert wird entstehen. Sie müssen die vor-und Nachteile sorgfältiger betrachten, wenn die Datenkomprimierung für eine OLTP-Datenbank in Betracht ziehen.

Rückkehr zu der Frage, obwohl die Datenkomprimierung Datawarehouses ursprünglich angestrebt wurde, haben viele SQL Server-Kunden gefunden, dass sie eine große Menge an CPU "Head Room" auf ihren Servern haben. Sie können die zusätzliche CPU-Auslastung und potenziell länger Abfrage-Ausführungszeit der großen Platzersparnis und Storage-Einsparungen, die bei Verwendung der Datenkomprimierung abzurufenden leisten. Datenkomprimierung können für OLTP-Umgebungen nützlich sein. Nur stellen Sie sicher, dass Sie die Platzersparnis und Leistungseinbußen bei Arbeitsauslastung auswerten vor dem Start der Produktion.

Die Prozedur Sp_estimate_data_compression_savings können Sie Speicherplatz einsparen Ihnen eine Vorstellung von den Prozentsatz-Einsparungen, die Sie erwarten können. Es ist wichtig, da aktivieren (oder deaktivieren) Sie hierfür die Datenkomprimierung erfolgt mit einen Neuerstellungsvorgang. Dies kann in sich selbst teuer sein. Weitere Informationen finden Sie im Whitepaper "Data Compression: Strategy, Capacity Planning and Best Practices."

Paul S. Randal

**Paul S. Randal**ist die Verwaltung von Direktor von SQLskills.com, Microsoft regional Director und ein SQL Server-MVP. Er widmete sich das SQL Server-Speichermodul Team bei Microsoft von 1999 bis 2007. Er schrieb DBCC CHECKDB/Repair für SQL Server 2005 und war bei der Entwicklung von SQL Server 2008 für das Kernspeichermodul zuständig. Paul Randal ist Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung und regelmäßiger Referent bei Konferenzen in aller Welt. HE Blogs unter SQLskills.com/blogs/paul, und Sie finden ihn auf Twitter unter twitter.com/PaulRandal.

Verwandter Inhalt