Share via

SQL – Fragen und Antworten: Halten Sie Ihre Daten pflegeleicht

  • Artikel

In diesem Monat hilft unser SQL Server-Kolumnist den Lesern dabei, anhand von Dateigruppen unterschiedliche Daten zu analysieren, eine Strategie zu entwickeln und Daten zu verwalten.

Paul S. Randal

Zahlen lügen nicht

F: Ich versuche, die e/a-Wartezeit von einigen unserer Datenbanken Messen und erhalte ich unterschiedliche Ergebnisse von die Dynamic Management Views (DMVs) und die Systemmonitor-Leistungsindikatoren. Können Sie erklären, warum diese Zahlen nicht identisch sind?

A. Diese zwei Methoden verwenden die dm_io_virtual_file_stats DMV (siehe meine Blog-post für weitere Informationen zur Verwendung, die), und der AVG. Datenträger Sek./Lesevorgänge und AVG. Leistungsindikatoren für Datenträger Sek./Schreibvorgänge in das Objekt Physikalischer Datenträger im Systemmonitor. Es ist durchaus möglich, dass Sie möglicherweise unterschiedliche Ergebnisse zwischen den beiden Mechanismen sehen.

Die DMV misst die kumulative Lese- und Stall Schreibzeit oder Wartezeiten. Es tut dies für jede Datei in jeder Datenbank, da die Datenbank (in der Regel seit dem letzten Neustart der SQL Server -Instanz) online geschaltet wurde. Teilen Sie diese Summen durch die Anzahl von Lese- und Schreibzugriffen auf den durchschnittlichen lesen und schreiben I/O Wartezeiten. Diese Durchschnittswerte sind über den gesamten Zeitraum ab wann Sie zuerst abgefragt, die DMV zurück, wenn die betreffende Datenbank online geschaltet wurde.

Die Systemmonitor-Leistungsindikatoren sind ein gleitender Durchschnitt über ein kleiner Zeitraum. Diese zwei große Blog-Posts "Windows Performance Monitor Datenträger-Leistungsindikatoren Explained," und "Mess-Datenträgerlatenz mit Windows-Systemmonitor (Perfmon)," von der Windows Server Core Team genauer erklären. Sie bekommen, was beläuft sich auf eine sofortige Ansicht des Datenträgers lesen und Schreiben von Wartezeiten. Wie Sie sehen können, sind diese beiden Methoden zur Messung der Latenz sehr unterschiedlich, was zu unterschiedlichen Ergebnissen führen kann.

Die DMV misst nur die Wartezeit der SQL Server -Datenbankdateien. Der Systemmonitor ist alle i/OS auf diesem Volume messen. In einer shared-Storage-Umgebung das könnte bedeuten, dass viele andere nicht -SQL Server -Dateien, die einen Beitrag zu der i/o auf dem Volume zu laden. Dies könnte die durchschnittliche niedrige machen, was anbelangt Performance Monitor ist durch Messung viele i/OS über viele Dateien. Der Durchschnitt aus der DMV könnte höher sein, weil es weniger i/OS über weniger Dateien messen ist.

Aus den gleichen Gründen könnte schlechter Leistung für einige Zeit auf dem Volume, aber keine SQL Server i/OS im Prozess. Die Systemmonitor-Leistungsindikatoren würde die schwache Leistung widerspiegeln. Wie die DMV SQL Server i/o nur misst, sind nicht die DMV-Ergebnisse dieser Zeit schwache Leistungen betroffen.

Auch nicht vergessen Sie, dass die DMV aggregierte Daten sammelt. Wenn es eine Kündigungsfrist von Leistungseinbußen mit i/nur SQL Server OS auftreten gibt, werden die DMV-Ergebnisse von schlechter Leistung der i/o, betroffen sein, auch nach die Performance wieder verbessert. Die Systemmonitor-Leistungsindikatoren werden Wartezeiten während der Zeit der schlechten Leistung, dann niedrige Latenzzeiten wiederzugeben, wenn Performance verbessert.

Wie Sie sehen können, um die verschiedenen Werte Sinn müssen Sie berücksichtigen, was sie eigentlich Messen sind. Leider gibt es keine Möglichkeit, die DMV-Zähler zurückzusetzen, ohne dass die gewünschte Datenbank vorübergehend offline geschaltet.

HA für jedermann

F: Ich bin gebeten worden, über eine neue Strategie der Hochverfügbarkeit (HA) für unsere SQL-Server zu arbeiten. Ich bin auf der Suche nach einige Hinweise, was zu beachten und wo ich anfangen. Bieten Ihnen eine Beratung?

**A.**Ein Problem ist herauszufinden, welche HA-Technologie zu verwenden, wenn Sie Ihre Strategie zu entwerfen. Oft wird ein Unternehmen mit der etablierten Technologie gehen, nur weil es bereits vorhanden ist. Schlimmer noch, kann das Unternehmen eine beliebigen Technologie-Auswahl diesbezüglich klare Anforderungen machen.

Um die richtige HA-Strategie zu entwerfen, müssen Sie sammeln und analysieren Ihre Anforderungen. Ohne diesen wichtigen Schritt haben Sie keine Hoffnung auf Erfüllung der geschäftlichen Anforderungen mit Ihrer Strategie. Für jeden Teil der Daten, die auf die HA-Strategie angewendet wird, benötigen Sie die Antworten auf folgenden Fragen:

  1. Wie wichtig ist diese im Vergleich zu allen anderen Daten? Besagt, dass alles oberste Priorität ist und ebenso geschützt werden muss arbeitet mit einer kleinen Menge von Daten, sondern wird zunehmend unpraktisch mit mehreren Terabyte verteilt mehrere Instanzen des SQL Server .
  2. Wie viele Daten kann das Unternehmen leisten, zu verlieren? Unternehmer möchte verständlicherweise kein Datenverlust zu sehen.
  3. Wie lange können die Daten nicht verfügbar sein? Unternehmer, wie auch zu sehen, keine Ausfallzeiten. Obwohl Sie nahe kommen können, ist es leider nicht in der Realität erreichbar.
  4. Elemente zu tun, Nein. 1 oder Nr. 2 Wechsel an verschiedenen Zeiten des Tages oder am Wochenende? Dies kann eine tief greifende Wirkung auf Ihre Fähigkeit, Anforderungen zu erfüllen haben. Keine Ausfallzeiten und Datenverlust sind für einen begrenzten Zeitraum weitaus erreichbar — sagen, 09 zu 17 an Wochentagen — im Vergleich zu 24 x 365.
  5. Ist es akzeptabel, die Arbeitsauslastung Erhaltung Datenverfügbarkeit und Haltbarkeit beeinträchtigen? Die einzigen Technologien, die Datenverlust bieten können erfordern, synchrone Spiegelung der Transaktionsprotokoll-Datensätze (Datenbankspiegelung oder SQL Server 2012 Availability Groups) oder I/O-Subsystem schreibt (SAN-Replikation). Beides können zu einer Verzögerung der Verarbeitung führen, aber es ist ein Kompromiss.
  6. Muss die sekundäre Kopie der Daten lesbar oder schreibbar sein?

Nachdem Sie mit diesen Anforderungen konfrontiert sind, können durch die Beschränkungen durch das Geschäft arbeiten und dann gefährden. Es ist wichtig zu erkennen, dass die Einschränkungen, die, denen Sie in arbeiten, können bedeuten, dass Sie alle Anforderungen erfüllen können. In diesem Fall müssen Sie und die Business-Manager einen Kompromiss zustimmen. Andernfalls wird keiner HA-Strategie, die Sie entwerfen, Erwartungen zu erfüllen. Es ist sogar eher Ihre Lösung bestehen wird, mehrere Technologien, also die Grenzen der einzelnen, als auch zu wissen, wie sie zusammenarbeiten, ist entscheidend für Ihren Erfolg.

Es drohen möglicherweise eines der folgenden Einschränkungen:

  • Budget
  • Verfügbare elektrische Leistung
  • Physischen Raum für neue Server, Racks und Klimaanlagen
  • Personal — es ist niemand zur Verfügung, um neue Systeme zu verwalten oder niemand hat derzeit die Fähigkeiten zur Implementierung und Verwaltung der neuen Technologies, die erforderlich

Es gibt detaillierte Beschreibungen der Technologien und strategischen Beispiele in diese zwei White-Papers:

Obwohl diese White Papers, für SQL Server 2008/2008 R2, alles in ihnen noch gilt. Überprüfen Sie auch heraus im White Paper "AlwaysOn – Architektur-Führer: Aufbau einer Hochverfügbarkeit und Disaster-Recovery-Lösung durch Verwendung von AlwaysOn Availability Groups, "für die neuesten Technologien der SQL Server 2012.

Gruppe bis

F: Ich habe von einigen meiner Kollegen gesagt, dass ich Dateigruppen für neue Datenbanken anstatt eine einzelne Datendatei verwendet werden sollte. Können Sie einige der Vorteile und Nachteile dadurch erklären?

**A.**Ich kann keine Nachteile der Verwendung von Dateigruppen, außer vielleicht zu weit gehen und mit Hunderten von ihnen denken. Soweit die Vorteile gehen, beginnen mehrere Dateigruppen, als Ihre Datenbanken werden größer (mehr als 50 GB - 100 GB) notwendig geworden. Dennoch gibt es drei Hauptgründe für Sie.

Dateigruppen ermöglichen eine schnelle und gezielte Wiederherstellung während einer Naturkatastrophe. Stellen Sie sich vor, Sie haben eine 1-TB-Datenbank mit den meisten Platz mit der sales-Tabelle, die Daten von 2009 enthält bis heute. Wenn die Datenbank in eine Katastrophe zerstört wird, was ist der kleinste Betrag, den Sie wiederherstellen können? Wenn es alles in einer Dateigruppe ist es keine Optionen — Sie müssen den gesamten 1TB, inklusive aller ältere Daten wiederherstellen.

Ein besserer Ansatz für Disaster Recovery ist, wenn Sie separate Dateigruppen haben: primäre, 2009, 2010, 2011, 2012 und 2013. Sie möchten im Katastrophenfall die 2013-Daten so schnell wie möglich online zu sein. Das ist, was Ihr Vertriebssystem Online Transaction Processing (OLTP) unterstützt. Solange Sie SQL Server Enterprise Edition haben, können Sie nutzen partielle Datenbankverfügbarkeit und beginnt dieser Prozeß durch Wiederherstellen der primären Dateigruppe, die mithilfe der WITH PARTIAL-Syntax. Dann können Sie die anderen Dateigruppen wiederherstellen, die Sie wollen sofort online. Dann können Sie die Wiederherstellungssequenz beenden.

Sie können die anderen Dateigruppen wiederherstellen, online und in Ihrer Freizeit. Jetzt sind Sie nutzt ein weiteres Feature des Enterprise-Edition "online schrittweise Wiederherstellung" bezeichnet. Dies ist eine Kombination von Merkmalen bei sehr großen Datenbanken (VLDBs). Diese Features die Ausfallzeiten und geben Sie eine Menge an Flexibilität, wenn es darum geht, die Priorisierung der Wiederherstellungssequenz während einer Katastrophe. Es bedeutet auch, dass Sie eine schrittweise Wiederherstellung durchführen können, wenn nur ein Teil der Datenbank aus irgendeinem Grund beschädigt wird. Dies schränkt weitere Ausfallzeiten Anforderungen im Katastrophenfall.

Der zweite Grund für die Verwendung von Dateigruppen ist zu unterstützen, Partitionierung und bessere Verwaltbarkeit. Partitionierung können Sie einfach laden und Löschen von Daten aus einer großen Tabelle sehr schnell, ohne dass eine Menge des Transaktionsprotokolls. Vollständig erläutert die Vorteile der Partitionierung ist, würde den Rahmen dieses Artikels sprengen, aber die folgenden Whitepapers machen einen tollen Job, mit verschiedenen Beispielszenarien:

Eine andere Eigenschaft der Verwaltbarkeit befasst sich mit Fragmentierung. Mit dem gleichen Verkaufstisch-Beispiel als vor, wenn Sie Indizes für die Tabelle sales, die fragmentiert und der Tabelle und Indizes nicht sind partitioniert, dann die ALTER INDEX... Neuerstellung oder REORGANIZE Befehle müssen für den Betrieb auf den gesamten Index defragmentiert wird. Dies gilt, obwohl die älteren Daten wird nicht fragmentiert werden. Wenn Sie die Tabelle in mehrere Partitionen, jeweils in einer separaten Dateigruppe geteilt haben können Sie nur die Partitionen der Indizes defragmentieren, die fragmentiert sind. Das spart viel Zeit und Ressourcen.

Schließlich können Dateigruppen Sie unterschiedliche Arbeitslasten innerhalb der Datenbank auf verschiedene Teile der i/o-Subsystem zu isolieren. Zum Beispiel stellen Sie vor, Sie haben einige leicht verwendeten Tabellen und ein paar, die stark verwendet und aktualisiert werden. Wenn alles in einer Dateigruppe ist, stellen Sie möglicherweise fest, dass die betriebliche Leistung auf den leicht gebrauchten Tischen wegen Operationen auf den häufig aktualisierten Tabellen gefährdet ist.

In diesem Fall könnten Sie die leicht verwendeten Tabellen in eine Dateigruppe auf einen eigenen Teil des i/o-Subsystem unterteilen. Speichern Sie jeder der stark gebrauchten und aktualisierten Tabellen in separaten Dateigruppen. Haben Sie jeweils einen eigenen Teil des i/o-Subsystem. Dies abgrenzt wird die I/O-Belastung, also die Arbeitsauslastungen mit einander stören nicht.

Sie haben auch innerhalb einer einzelnen Tabelle, dazu, wenn es ein OLTP-Workload auf die aktuellsten Daten (z. B. in einen Verkaufstisch, wie weiter oben beschrieben) und die Arbeitsauslastung für eine Daten-Lager auf die älteren Daten. Dies ist ein Fall, wo Partitionierung wird notwendig sein und unterschiedliche Arbeitslasten separaten Partitionen der Tabelle für separate Dateigruppen beschränkt sein werden — wieder Segregieren Arbeitslasten voneinander.

Paul S. Randal

Paul S. Randal ist der Geschäftsführer von SQLskills.com, Microsoft regional Director und einem SQL Server MVP. Er arbeitete an der SQL Server Storage Engine Team bei Microsoft von 1999 bis 2007. Er schrieb DBCC CHECKDB/Repair für SQL Server 2005 und war verantwortlich für das Kernspeichermodul während SQL Server 2008-Entwicklung. Randal ist Experte für Disaster Recovery, hohe Verfügbarkeit und Datenbankwartung und ein regelmäßiger Referent auf Konferenzen weltweit. Er Blogs auf SQLskills.com/blogs/paul, und Sie finden ihn auf Twitter bei twitter.com/PaulRandal.

Verwandte Inhalte