SQL – Fragen und Antworten: Sicherung und Einrichtung
SQL Server ist eine leistungsfähige Plattform. Die Einrichtung der Transaktionsprotokolleinstellungen und anderer Konfigurationsoptionen erfordert jedoch gewisse Kenntnisse.
Paul S. Randal
Transaktionsprotokolle des XXXL
Frage: Unser Produkt verwendet SQL Server zum Speichern von Daten. Hin so oft lassen Sie eine neue Version der unser Produkt, die ein Aktualisierungsskript gegen die Datenbank ausgeführt werden. Wie wir unsere neuesten Aktualisierungsskript auf eine repräsentative Testdatenbank getestet wurden, wurde die Transaktionsprotokolldatei auf mehr als 40 GB. Wir möchten verhindern, dass die Protokolldatei größer so groß. Was sind unsere Optionen? Wir haben das Modell der vollständigen Wiederherstellung für den Notfall verwenden.
A: Zunächst ist es, dass Sie gegen repräsentative Kundendaten Tests sind großartig. So viele Male angezeigt geschichteten Anwendungshersteller testen diese Arten von Skripts auf kleine Datenmengen und veröffentlichen Sie an Ihre Kunden in allen Arten von Produktions-Problemen führen. Ich werde Ihre Frage beantwortet, als ob Sie sich die Benutzer befinden. Sie können dann in den Kontext Ihrer Kunden übersetzen.
Sie sagen, müssen Sie das Modell der vollständigen Wiederherstellung zu bleiben. Dies bedeutet, Sie sind bereits führen Transaktionsprotokollsicherungen, und Sie verfügen nicht über die allgemeine Probleme mit dem Transaktionsprotokoll wächst außerhalb des Steuerelements. Dies ist in Ordnung, führen Transaktionsprotokollsicherungen ist der einzige Vorgang, mit der das Transaktionsprotokoll löschen, nachdem der Commit für Transaktionen ausgeführt wurden. (Hintergrundinformationen, finden Sie unter technet.microsoft.com/magazine/2009.02.logging , die erläutert, wie das Transaktionsprotokoll funktioniert und wie verschiedene Wiederherstellungsmodelle sein Verhalten beeinflussen.)
Haben gesagt, ist die Häufigkeit, mit der Sie Sicherungen des Transaktionsprotokolls ausführen, eine Sache, die wird bestimmt, wie schnell das Transaktionsprotokoll deaktivieren und nicht vergrößert werden kann. Beispielsweise wenn normalen Sicherungsauftrags alle 30 Minuten eine Sicherung des Transaktionsprotokolls durchführt, muss die Transaktionsprotokolldatei sein ausreicht, um die maximale Speichergröße Transaktionsprotokolldaten aufzunehmen, die in einem Zeitraum von 30-minütigen generiert werden können. Andernfalls wird er vergrößert.
Wenn das Aktualisierungsskript 60 Minuten ausgeführt wird, konnte, erarbeiten auf 20 GB des Transaktionsprotokolls generiert alle 30 Minuten, damit die Transaktionsprotokolldatei auf 20 GB haben. Ist wahrscheinlich immer noch zu groß, so müssen Sie mehrere Transaktionsprotokollsicherungen durchführen, häufig während das Aktualisierungsskript ausgeführt wird. Dies ermöglicht es, dass das Transaktionsprotokoll öfter deaktivieren und verhindern, dass es so groß größer. Wir haben eine ähnliche Situation an einer Stelle Client und jetzt mehrere Stunden einmal pro Minute eine Transaktionsprotokollsicherung durchführen, während ein ähnliches Skript auf einer großen Datenbank ausgeführt wurde.
Was zu beachten ist, dass diese “ zusätzliche ” Transaktion Sicherungen Formular Teil der Protokollsicherungskette protokollieren und Notfall-Wiederherstellung erforderlich sind. Stellen Sie sicher, dass Sie aussagekräftige Namen haben und nicht gelöscht werden.
Es ist ein weiterer Faktor berücksichtigen: Was ist die größte einzelne Transaktion, die als Teil des Aktualisierungsvorgangs auftritt, Engineering zu haben? Das Transaktionsprotokoll kann nur löschen, wenn die Protokolleinträge von Transaktionen (der möglicherweise ein wenig oversimplifying werden – finden Sie unter den oben genannten Artikel Weitere Details). Dies bedeutet, dass eine lang andauernde Transaktion lassen wird nicht, das Protokoll zu löschen, obwohl das Transaktionsprotokoll Sicherung sichert die generierten Transaktionsprotokoll.
Enthält das Aktualisierungsskript eine Transaktion, die 15 GB Speicherplatz erfordern, müssen die Transaktionsprotokolldatei mindestens 15 GB für die gesamte Transaktion zu speichern, bis es überträgt. Das Transaktionsprotokoll wird nicht löschen, ist dies der Fall, unabhängig davon, wie oft Sie eine Transaktionsprotokollsicherung durchführen. In diesem Fall ist die einzige Vorgehensweise möglichst umfangreiche Transaktion in kleinere Einheiten aufteilen.
Sollten Sie diese beachten: die Größe des Transaktionsprotokolls erforderlich, um das Aktualisierungsskript ausgeführt wird bestimmt durch die Häufigkeit der Sicherungen des Transaktionsprotokolls und der Größe der einzelnen größten Transaktion, die Sie erstellen.
Konfiguration Conundrum
Frage: Wir sind einige neuen direkt angeschlossener Speicher für eine unserer Datenbank-Server bereitgestellt, und wir möchten Sie sicherstellen, dass wir alle unsere Optionen verstehen und erhalten die Konfiguration korrekt. Können Sie verschiedene Konfigurationseinstellungen erklären, denen wir bewusst sein sollten soweit SQL Server betrifft, ist?
A: Es gibt unzählige Einstellungen und Konfigurationsoptionen beim Speicher bereitstellen, damit einen dedizierte Storage Administrator umfassen und Videoqualität. Es gibt sicherlich einige Optionen, die mit denen SQL Server-Administrator besorgt sein sollte, und achten Sie darauf, diese entsprechend festgelegt.
Die erste dieser ist die zugrunde liegende RAID-Ebene. Die verschiedenen RAID-Ebenen haben unterschiedliche Kompromisse, Bezug auf Leistung und Redundanz werden. Beispielsweise die kostengünstigste RAID-Konfiguration, die immer noch einige Redundanz bietet RAID-5, aber diese Konfiguration kann nur mit einem einzelnen Laufwerkfehler bewältigen (außer bei Verwendung von RAID-6, oder hot Spare-Laufwerke konfiguriert), und kann die Leistung für Schreibzugriff Heavy-Arbeitslasten, abhängig von der Anzahl der Laufwerke im Array werden manchmal beeinträchtigen.
RAID 10 bietet die beste Redundanz, aber es ist teurer. Die Gesamtkapazität des Arrays ist höchstens halb die Gesamtkapazität der konstituierenden Laufwerke. Eine gute Beschreibung der verschiedenen RAID-Ebenen werden in Anhang A des Whitepapers TechNet “ Physischer Datenbankentwurf Storage . ” dargestellt.
Die wichtigsten Faktoren zu berücksichtigen sind die Stripesetgröße RAID, NTFS-Zuordnungseinheit (die Clustergröße) und die Festplattenausrichtung Partition. Alle diese Faktoren drastisch Leistung Wenn verringern können festgelegt falsch. Am wichtigsten ist die Partition Festplattenausrichtung für Datenträger, die mit Windows Server 2003 erstellt. Hier wird eine Ausrichtung 31.5 KB wird standardmäßig nicht häufig RAID Stripe-Größe von 64 KB (oder ein Vielfaches davon) entspricht. Daher verfügt jedes e/A im Wesentlichen zum Lesen oder Schreiben von zwei RAID-Streifen, um die e/A zu erfüllen. Dadurch natürlich enorme Verschlechterung der Leistung.
Windows Server 2008 eine Ausrichtung 1 MB wird standardmäßig verwendet. Alle Datenträger auf Windows Server 2003 erstellt und für das Hosten von Windows Server 2008 aktualisiert haben keine Ihre Ausrichtung geändert, damit Sie dennoch betroffen sein könnten. Die Behebung dieses Problems bedeutet Neuformatierung des Volumes, aber die Leistungssteigerungen können Sie häufig einen Schritt lohnt.
Eine ausführliche Beschreibung dieser ist wirklich über den Rahmen dieses Artikels hinaus, aber es gibt weitere Details (und Links für Weitere Informationen), in meinem Blogbeitrag “ sind die Datenträgerpartition versetzt, RAID stripe Größen und NTFS Zuordnungseinheiten ordnungsgemäß festgelegt? ”
Bei jeder neuen Speicher bereitstellen zu können, ist es ratsam, Belastungstests und Leistungstests vor dem Start einer Produktion Arbeitsauslastung. Belastungstests kann Konfigurationsprobleme zu leeren, die zu Ausfallzeiten oder Datenverlust führen kann. Tests können Sie feststellen, dass der neue Speicher der e/a-Kapazität die Arbeitsauslastung bietet Leistung erforderlich ist. Microsoft bietet kostenlose Tools können Sie mit dieser Option, die Sie auch im Whitepaper “ Pre-Deployment e/a-Empfehlungen . ” mehr über erfahren können
Spieglein, Spieglein
Frage: Ich bin ein wenig über die Art der Zeugenserver verwechselt, bei der Einrichtung der Datenbankspiegelung. Verfügt der Zeugenserver wie leistungsfähig sein? Ist dies die Anzahl der Datenbanken abhängig für das Failover wird? Spielt es in dem Datencenter der Zeugenserver platzieren? Ich möchte sicherstellen, dass die höchste Verfügbarkeit für die gespiegelten Datenbanken zu erhalten.
A: Die Rolle von der Zeugenserver ist eine der am häufigsten missverstandenen Aspekte von jedem System zur Datenbankspiegelung. Bei einer synchronen Datenbankspiegelung Konfiguration der Zeugenserver dient ausschließlich zum ein automatisches Failover zu ermöglichen, falls der primäre Server ausfällt.
Der Prinzipalserver sendet die Datensätze des Transaktionsprotokolls kontinuierlich an den Spiegelserver nie der Zeugenserver. Der Prinzipal, Spiegel- und Zeugenserverinstanzen Pingserver einander jede Sekunde als Teil des Mechanismus für automatische Fehlererkennung. Wenn der Spiegelserver feststellt, dass er mit dem Prinzipalserver Gründen kommunizieren kann, kann nicht es ein automatisches Failover initiiert, wenn der Zeugenserver zustimmt, die Sie auch mit dem Prinzipalserver kommunizieren kann. Zwei Server zum Akzeptieren der Bedingungen, bildet ein Quorum, und der Spiegelserver initiiert ein automatisches Failover. Wenn ein Zeugenserver nicht vorhanden ist, kann kein Quorum vorhanden sein und ein automatischer Failover ist nicht möglich.
Auf diese Weise bezüglich der Zeugenserver ausschließlich dazu beitragen, ein Quorum zu bilden. Es wird nicht einen Failover auslösen oder spielen eine beliebige Stelle in die gespiegelte Datenbank hostet. Es ist in der Regel das Quorum zwischen den Servern Prinzipal- und die Spiegeldatenbank vorhanden.
Wie der Zeugenserver keine Verarbeitung als solche, muss es keinen leistungsstarken Server sein. Sie können eine beliebige Edition von SQL Server, einschließlich kostenlosen SQL Server Express Edition hosten. Es gibt auch keine Beschränkung für die Anzahl der Sitzungen, für die eine bestimmte Instanz von SQL Server als Zeuge fungieren kann, der Datenbankspiegelung.
Der Zeugenserver wird am besten in einem separaten Datencenter aus den Prinzipal oder Spiegel-Servern platziert werden. In den meisten Unternehmen verfügen nicht jedoch drei Rechenzentren, daher ist die Frage, ob der Zeugenserver mit dem Spiegelserver oder mit dem Prinzipalserver platziert werden soll.
Wenn nur zwei Datenzentren zur Verfügung stehen, sollte der Zeugenserver immer mit dem Prinzipalserver platziert werden. Der Grund, warum hat mit der ein Quorum zu bilden. Wenn der Zeuge und Spiegelung veröffentlichende befinden und die Netzwerkverbindung auf dem Prinzipalserver fällt, ein Quorum wird zwischen dem Zeugenserver und Spiegelung zu bilden und der Spiegelserver wird einen Failover initiiert.
Der Prinzipalserver, die nicht alle Probleme haben können, wird die Prinzipaldatenbank offline schalten, wenn er das Quorum verliert. Es wird vorausgesetzt, dass die Spiegelung in diesem Fall einen Failover durchgeführt werden. Um dies zu verhindern, kann die Positionierung die Prinzipal- und Zeugenserverinstanzen Server den Prinzipal das Quorum mit der Zeuge im Falle eines Netzwerkfehlers verwalten. Die Prinzipaldatenbank bleibt verfügbar.
Der Zeugenserver ist völlig optional, aber es gibt keine Möglichkeit, ein automatisches Failover – und somit die höchste Verfügbarkeit der Datenbank gespiegelt wird, ohne eine. Die Datenbankspiegelung funktioniert in jeder andere Weise identisch. Wenn ein Zeugenserver konfiguriert ist, aber aus irgendeinem Grund nicht mehr verfügbar ist, besteht kein Verlust Spiegelung Funktionen außer ein automatisches Failover auszuführen.
Sie können auch zwei Zeugen für einer Datenbankspiegelungssitzung lassen. Die einzige Möglichkeit, um noch mehr Redundanz Zeuge-Serverrolle hinzuzufügen, besteht darin, Zeuge SQLServer-Instanz auf einem Failovercluster bereitgestellt haben. Sie erhalten weitere Informationen zu Konfigurationen in der TechNet Whitepaper “ Database Mirroring in SQLServer 2005 . ” für die Datenbankspiegelung
.jpg)
Paul S. Randal ist die Verwaltung von Director SQLskills.com, einen regionalen Microsoft-Leiter und SQL Server-MVP. Er gearbeitet, die SQL Server-Speichermodul Team bei Microsoft von 1999 2007. Er schrieb DBCC CHECKDB/Repair für SQL Server 2005 und während der Entwicklung von SQL Server 2008 für das Kernspeichermodul zuständig ist. Paul Randal ist Experte für Notfallwiederherstellung, hohe Verfügbarkeit und Datenbankwartung und regelmäßiger Referent bei Konferenzen in aller Welt. Er bloggt auf SQLskills.com/blogs/paul, und Sie können ihn auf Twitter am Twitter.com/PaulRandal finden.