Optimieren der Leistung von Sicherungs- und Wiederherstellungsvorgängen in SQL Server
Microsoft SQL Server bietet die beiden folgenden Möglichkeiten, Sicherungs- und Wiederherstellungsvorgänge zu beschleunigen:
Durch Verwenden mehrerer Sicherungsmedien können Sicherungen auf alle Medien parallel geschrieben werden. Die Geschwindigkeit der Sicherungsmedien ist ein potenzieller Engpass des Sicherungsdurchsatzes. Durch das Verwenden mehrerer Medien wächst der Durchsatz proportional zur Anzahl der verwendeten Medien. Ebenso kann die Sicherung parallel von mehreren Medien wiederhergestellt werden. Weitere Informationen finden Sie nachfolgend in diesem Thema unter "Verwenden mehrerer Medien oder Geräte".
Verwenden einer Kombination aus vollständiger Sicherung, differenzieller Sicherung und (für das vollständige oder massenprotokollierte Wiederherstellungsmodell) Transaktionsprotokollsicherungen, um die Wiederherstellungszeit auf ein Minimum zu reduzieren. Differenzielle Datenbanksicherungen können normalerweise schneller als vollständige Datenbanksicherungen erstellt werden und reduzieren den Umfang an Transaktionsprotokollen, der zum Wiederherstellen der Datenbank erforderlich ist. Weitere Informationen finden Sie unter Erstellen einer vollständigen und einer differenziellen Sicherung einer SQL Server-Datenbank.
Verwenden mehrerer Medien oder Geräte
Das Kopieren der Daten und des Transaktionsprotokolls von den Sicherungsmedien auf die Datenbank- und Transaktionsprotokolldateien wird von Leser-/Schreiberthreads durchgeführt, wobei jedem Sicherungsmedium ein Thread zugeordnet ist. Die Leistung ist entweder durch die Fähigkeit der Sicherungsmedien begrenzt, die Daten bereitzustellen, oder durch die Fähigkeit der Datenbank- und Transaktionsprotokolldateien, die Daten anzunehmen. Daher steigt die Leistung mit der Anzahl der hinzugefügten Sicherungsmedien, bis der maximale Durchsatz der Datenbank- und Transaktionsprotokolldateien erreicht ist und keine Daten mehr angenommen werden können.
Mithilfe mehrerer Sicherungsmedien für Sicherungs- und Wiederherstellungsvorgänge kann SQL Server parallele E/A-Vorgänge verwenden, um die Geschwindigkeit der Sicherungs- und Wiederherstellungsvorgänge zu erhöhen, da auf jedes Sicherungsmedium zur selben Zeit wie auf andere Sicherungsmedien geschrieben oder jedes zur selben Zeit wie andere Sicherungsmedien gelesen werden kann. Bei Unternehmen mit großen Datenbanken kann der Zeitaufwand für Sicherungs- und Wiederherstellungsvorgänge mithilfe mehrerer Sicherungsmedien drastisch gesenkt werden. SQL Server unterstützt pro Sicherungsvorgang maximal 64 Sicherungsmedien.
Während des Schreibvorgangs einer Sicherung auf mehrere Sicherungsmedien treten eine Reihe von internen Synchronisierungspunkten auf. Die wichtigsten dieser Punkte treten dann auf, wenn alle Daten in der Datenbank gesichert wurden und im nächsten Schritt das Transaktionsprotokoll gesichert werden soll.
.gif "Wichtiger Hinweis") Wichtig |
|---|
Beim Verwenden mehrerer Sicherungsmedien für das Ausführen von Sicherungsvorgängen können die beteiligten Sicherungsmedien ausschließlich für Sicherungsvorgänge von SQL Server verwendet werden. Weitere Informationen finden Sie unter Verwenden von Sicherungsmedien. |
Das Erstellen und Wiederherstellen von Sicherungen mithilfe mehrerer Sicherungsmedien entspricht dem Erstellen und Wiederherstellen von Sicherungen mithilfe eines einzelnen Mediums. Der einzige Unterschied besteht darin, dass Sie alle beteiligten Sicherungsmedien angeben müssen, und nicht nur eines. Wenn beispielsweise eine Datenbanksicherung mithilfe von drei Sicherungsmedien wie beispielsweise \\.\TAPE0, \\.\TAPE1 und \\.\TAPE2 erstellt werden soll, muss jedes Bandmedium als Teil des Sicherungsvorgangs angegeben werden, obwohl weniger Bandsicherungsmedien beim Wiederherstellen der Sicherung zu einem späteren Zeitpunkt verwendet werden können.
Beim Erstellen einer Sicherung mithilfe mehrerer Sicherungsmedien auf austauschbaren Medien können die Geräte mit verschiedenen Geschwindigkeiten betrieben werden, und die Medienvolumes können verschieden großen Speicherplatz aufweisen. Wenn das Medienvolume auf einem Sicherungsgerät während eines Sicherungsvorgangs keinen ausreichenden Speicherplatz mehr zur Verfügung hat, wird der Schreibvorgang auf dem Medium beendet, und Sie werden aufgefordert, ein neues Medienvolume zur Verfügung zu stellen. Bis Sie das volle Medienvolume durch einen leeren ersetzt haben, wird das Medium blockiert. Währenddessen wird vom Sicherungsvorgang das Schreiben von Daten auf die Medien fortgesetzt, deren Medien noch ausreichenden Speicherplatz aufweisen. Wenn Sie das volle Medienvolume ersetzen, wird das entsprechende Medium verfügbar, und vom Sicherungsvorgang wird das Schreiben auf dieses Medium wieder aufgenommen. Beachten Sie allerdings Folgendes: Wenn ein interner Synchronisierungspunkt auftritt, während eines der Medien blockiert ist, wird der Sicherungsvorgang vollständig angehalten, bis das Medium wieder verfügbar ist.
Beispiel
Im folgenden Szenario werden drei Bandsicherungsmedien mit gleicher Geschwindigkeit zum Speichern einer vollständigen Datenbanksicherung verwendet. Die beiden ersten Bänder verfügen jeweils über 10 Gigabyte (GB) verfügbaren Speicherplatz, das Dritte aber nur über 5 GB. Wenn eine 20-GB-Datenbank auf alle drei Bandsicherungsmedien gleichzeitig gesichert wird, ist das dritte Band voll, bevor die Sicherung abgeschlossen ist. Sobald 5 GB auf das dritte Band geschrieben worden sind, beendet der Sicherungsvorgang das Schreiben auf das dritte Medium. Das Medium wird von dem Vorgang blockiert, und eine Aufforderung zum Einlegen eines neuen Bands wird angezeigt. Währenddessen werden jedoch vom Sicherungsvorgang weiter Daten auf die anderen zwei Medien geschrieben. Bevor das dritte Band ersetzt wird, tritt allerdings ein interner Synchronisierungspunkt auf. Der gesamte Sicherungsvorgang wird an diesem Punkt angehalten, bis ein neues Band in das dritte Medium eingelegt wird.
Optimieren der Leistung von vollständigen und differenziellen Sicherungen
Das Erstellen einer vollständigen oder differenziellen Sicherung besteht aus den folgenden Schritten:
Kopieren der Daten aus den Datenbankdateien auf die Sicherungsmedien.
Kopieren des Teils des Transaktionsprotokolls, der erforderlich ist, um ein Rollforward der Datenbank auf einen konsistenten Status auszuführen, auf dieselben Sicherungsmedien.
Das Erstellen einer differenziellen Sicherung ist identisch mit dem Erstellen einer vollständigen Sicherung, außer dass nur geänderte Daten kopiert werden. Beim Sichern einer Datenbankdatei werden einfach die Daten aus der Datei auf die Sicherungsmedien kopiert.
Die zum Speichern der Datenbank verwendeten Datenbankdateien sind nach Datenträgermedium sortiert, und jedem Medium ist ein Leserthread zugeordnet. Dann liest der Leserthread die Daten aus den Datenbankdateien. Ein Schreiberthread wird jedem Sicherungsmedium zugeordnet. Der Schreiberthread schreibt Daten auf das Sicherungsmedium. Mehr parallele Leseoperationen können verwendet werden, wenn die Datenbankdateien auf mehr logische Laufwerke aufgeteilt werden. Ähnlich können mehr parallele Schreiboperationen durchgeführt werden, wenn mehr Sicherungsmedien verwendet werden.
Im Allgemeinen bilden entweder die Datenbankdateien oder die Sicherungsmedien einen Engpass. Wenn der gesamte Lesedurchsatz größer als der gesamte Sicherungsmediendurchsatz ist, ist der Engpass bei den Sicherungsmedien zu suchen. Durch Hinzufügen von weiteren Datenbankmedien (und bei Bedarf von SCSI-Controllern) kann die Leistung gesteigert werden. Ist jedoch der gesamte Sicherungsdurchsatz größer als der gesamte Lesedurchsatz, so steigern Sie den Lesedurchsatz. Beispielsweise durch Hinzufügen von weiteren Datenbankdateien oder Medien (oder durch Hinzufügen von mehr Datenträgern in einem RAID-Medium).
Optimieren der Leistung der Transaktionsprotokollsicherung
Zum Erstellen einer Transaktionsprotokollsicherung muss lediglich der Teil des Protokolls kopiert werden, der noch nicht auf den Sicherungsmedien gesichert wurde. Auch wenn möglicherweise mehrere Transaktionsprotokolldateien vorhanden sind, stellt das Transaktionsprotokoll einen logischen Datenstrom dar, der sequenziell in einem Thread gelesen wird.
Ein Schreiberthread wird jedem Sicherungsmedium zugeordnet. Eine höhere Leistung wird erzielt, wenn weitere Sicherungsmedien hinzugefügt werden.
Ein Engpass kann das Datenträgermedium, das die Transaktionsprotokolldateien enthält, oder das Sicherungsmedium sein; dies ist von den relativen Geschwindigkeiten und der Anzahl der verwendeten Sicherungsmedien abhängig. Das Hinzufügen zusätzlicher Sicherungsmedien wirkt sich auf den Leistungszuwachs linear aus, bis die Kapazität des Datenträgermediums mit den Transaktionsprotokolldateien erreicht ist. Anschließend ist kein weiterer Leistungszuwachs möglich, ohne die Geschwindigkeit der Datenträgermedien mit dem Transaktionsprotokoll zu steigern, beispielsweise durch Verwenden von Datenträgerstriping.
Optimieren der Wiederherstellungsleistung
Das Wiederherstellen einer Datenbanksicherung oder einer differenziellen Sicherung erfolgt in vier Schritten:
Erstellen der Datenbank- und Transaktionsprotokolldateien, wenn sie noch nicht vorhanden sind.
Kopieren der Daten aus den Sicherungsmedien in die Datenbankdateien.
Kopieren des Transaktionsprotokolls aus den Transaktionsprotokolldateien.
Ausführen eines Rollforwards für das Transaktionsprotokoll, bei Bedarf mit anschließendem Neustart der Wiederherstellung.
Das Anwenden einer Transaktionsprotokollsicherung erfolgt in zwei Schritten:
Kopieren der Daten aus den Sicherungsmedien in die Transaktionsprotokolldatei.
Ausführen eines Rollforwards für das Transaktionsprotokoll.
Das Wiederherstellen einer Datenbankdatei erfolgt in zwei Schritten:
Erstellen von nicht vorhandenen Datenbankdateien.
Kopieren der Daten aus den Sicherungsmedien in die Datenbankdateien.
Dateiinitialisierung
Wenn die Datenbank- und Transaktionsprotokolldateien noch nicht vorhanden sind, müssen sie erstellt werden, bevor Daten auf sie wiederhergestellt werden können. Die Datenbank- und Transaktionsprotokolldateien werden erstellt, und der Inhalt der Dateien wird zu Null initialisiert. Separate Arbeitsthreads erstellen und initialisieren die Dateien parallel. Die Datenbank- und Transaktionsprotokolldateien sind nach Datenträgermedium sortiert, und jedem Datenträgermedium ist ein separater Arbeitsthread zugeordnet. Da das Erstellen und Initialisieren der Dateien einen sehr hohen Durchsatz verlangt, wird die höchste Leistung erzielt, indem die Dateien gleichmäßig auf die verfügbaren logischen Laufwerke verteilt werden.
Sofortige Dateiinitialisierung
In SQL Server 2005 und höheren Versionen können Datendateien sofort initialisiert werden. Dadurch kann die Datenbank- oder Dateigruppenwiederherstellung schnell ausgeführt werden. Durch die sofortige Dateiinitialisierung wird Speicherplatz freigegeben, ohne dass dieser Speicherplatz mit Nullen gefüllt wird. Der Speicherplatz wird vielmehr überschrieben, wenn neue Daten in die Dateien geschrieben werden. Die Initialisierung der Protokolldatei erfordert die Nullstellung zwar weiterhin, doch findet sie parallel mit der Übertragung der Daten von der Sicherung statt. Die Rollforwardphase der Wiederherstellung wird erst gestartet, wenn alle Daten übertragen worden sind und das gesamte Protokoll initialisiert worden ist.
.gif "Hinweis") Hinweis |
|---|
Die sofortige Dateiinitialisierung ist nur unter Microsoft Windows XP, Windows Server 2003 oder höheren Systemen verfügbar. |
Um die sofortige Dateiinitialisierung zu verwenden, müssen Sie das MSSQLSERVER-Dienstkonto unter einem Windows-Konto ausführen und das spezielle Windows-Privileg SE_MANAGE_VOLUME_NAME diesem Windows-Konto zuweisen. Dieses Privileg wird standardmäßig der Windows-Gruppe Administratoren zugewiesen. Falls Sie über Systemadministratorrechte verfügen, können Sie dieses Privileg zuweisen, indem Sie der Sicherheitsrichtlinie Durchführen von Volumewartungsaufgaben das Windows-Konto hinzufügen. Weitere Informationen zum Zuweisen von Benutzerrechten finden Sie in der Windows-Dokumentation.
Optimieren der Leistung der Bandsicherungsmedien
Mehrere Variablen beeinflussen die Leistung der Bandsicherungsmedien und bewirken, dass die Leistung der Sicherungs- und Wiederherstellungsvorgänge von SQL Server etwa linear mit der Anzahl der zusätzlich verwendeten Bandlaufwerke zunimmt.
Größe der Softwaredatenblöcke.
Anzahl der Bandlaufwerke, die an einen SCSI-Bus angeschlossen sind.
Typ des Bandlaufwerkes.
Die Größe der Softwaredatenblöcke wird von SQL Server auf optimale Leistung abgestimmt und darf nicht geändert werden. Die maximale Umfang von BLOCKSIZE beträgt 64 KB.
Viele Hochgeschwindigkeits-Bandlaufwerke zeigen ein besseres Leistungsverhalten, wenn sie für jedes verwendete Bandlaufwerk über einen eigenen SCSI-Bus verfügen. Laufwerke mit einer systemeigenen Übertragungsrate, die 50 Prozent der SCSI-Busgeschwindigkeit übersteigt, müssen an einen eigenen SCSI-Bus angeschlossen werden, um Leistungsverluste zu vermeiden. Weitere Informationen zu Einstellungen, die die Leistung der Bandlaufwerke betreffen, finden Sie in der Dokumentation des Bandlaufwerk-Herstellers.
| Wichtig |
|---|
Schließen Sie ein Bandlaufwerk in keinem Fall an denselben SCSI-Bus wie Datenträger oder CD-ROM-Laufwerke an. Die Fehlerbehandlungsroutinen für diese Geräte sind inkompatibel. |
Wenn mehrere Sicherungsvorgänge auf ein geladenes Band durchgeführt werden, können Sie die Leistung durch Angeben von NOREWIND steigern. Diese Option bewirkt, dass SQL Server das oder die Bänder nach dem Sicherungsvorgang offenhält. NOREWIND impliziert NOUNLOAD.
Optimieren der Leistung der Datenträger-Sicherungsmedien
Die reine E/A-Geschwindigkeit des Datenträger-Sicherungsmediums beeinflusst dessen Sicherungsleistung und bewirkt, dass die Leistung der Sicherungs- und Wiederherstellungsoperationen von SQL Server etwa linear mit der Anzahl der verwendeten Datenträgermedien zunimmt.
Die Verwendung von RAID-Medien als Datenträger-Sicherungsmedium muss sorgfältig bedacht werden. Beispielsweise besitzt RAID 5 eine geringe Schreibleistung, ungefähr vergleichbar mit der Geschwindigkeit eines einzelnen Datenträgers (aufgrund der Verwaltung der Paritätsinformation). Außerdem erfolgt das Anfügen von Daten an eine Datei mit signifikant geringerer Geschwindigkeit als der Schreibgeschwindigkeit des Mediums an sich.
Wenn das Sicherungsmedium mit hochgradigem Striping arbeitet, sodass die maximale Schreibgeschwindigkeit auf das Sicherungsmedium die beim Anfügen von Daten erzielbare Geschwindigkeit deutlich übersteigt, kann es sinnvoll sein, mehrere logische Sicherungsmedien auf demselben Stripeset zu platzieren. Mit anderen Worten, die Leistungsfähigkeit der Sicherung kann gesteigert werden, indem mehrere Sicherungsmedienfamilien auf demselben logischen Laufwerk platziert werden. Es lässt sich jedoch nur empirisch ermitteln, ob dies für eine bestimmte Umgebung einen Gewinn oder Verlust bedeutet. In der Regel ist es vorteilhafter, jedes Sicherungsmedium auf ein separates Datenträgermedium zu platzieren.
Grundsätzlich können auf einem SCSI-Bus nur wenige Datenträger mit maximaler Geschwindigkeit betrieben werden, auf dem Ultra-wide-Bus und dem Ultra-2-Bus einige mehr. Jedoch muss die Hardware stets sorgfältig konfiguriert werden, um die optimale Leistung zu erzielen.
Weitere Informationen zu Einstellungen, die die Datenträgerleistung betreffen, finden Sie in der Dokumentation des Datenträgerherstellers.
Datenkomprimierung
Moderne Bandlaufwerke sind mit integrierter Hardwaredatenkomprimierung ausgestattet, die die effektive Datenübertragungsrate zum Laufwerk deutlich erhöhen kann. Die Komprimierbarkeit der Daten in der Datenbank hängt von den Daten selbst und den verwendeten Bandlaufwerken ab. Typische Datenkomprimierungsraten liegen bei den meisten Datenbanken zwischen 1,2:1 und 2:1. Diese Komprimierungsraten sind typisch für Daten in vielen Geschäftsanwendungen, obwohl bestimmte Datenbanken höhere oder geringere Komprimierungsraten haben können. Beispielsweise kann eine Datenbank, die überwiegend bereits komprimierte Bilder enthält, von Bandlaufwerken nicht noch stärker komprimiert werden. Weitere Informationen zur Datenkomprimierung finden Sie in der Dokumentation des Bandlaufwerk-Herstellers.
Standardmäßig unterstützt SQL Server die Datenkomprimierung auf Hardwareebene; sie kann jedoch mithilfe des Ablaufverfolgungsflags 3205 deaktiviert werden. Durch Deaktivieren der Hardwarekomprimierung kann in seltenen Fällen die Leistung der Datensicherung verbessert werden. Wenn beispielsweise die Daten bereits vollständig komprimiert sind, wird durch Deaktivieren der Hardwarekomprimierung verhindert, dass das Bandlaufwerk Zeit für weitere Datenkomprimierungsversuche aufwendet.
Weitere Informationen zu Ablaufverfolgungsflags finden Sie unter Ablaufverfolgungsflags (Transact-SQL).
Sicherungskomprimierung
Standardmäßig steigt die CPU-Nutzung bei Sicherungen mit Sicherungskomprimierung erheblich an. Die durch den Komprimierungsvorgang zusätzlich beanspruchten CPU-Ressourcen können sich negativ auf gleichzeitige Vorgänge auswirken. Im Falle eines CPU-Konflikts kann es daher u. U. sinnvoll sein, in einer Sitzung, in der die CPU-Nutzung durch die Ressourcenkontrolle eingeschränkt ist, eine komprimierte Sicherung mit niedriger Priorität zu erstellen. Weitere Informationen finden Sie unter Vorgehensweise: Einschränken der CPU-Nutzung durch die Sicherungskomprimierung mithilfe der Ressourcenkontrolle (Transact-SQL).
Auf Band übertragene Daten
Beim Erstellen einer Datensicherung oder einer differenziellen Sicherung wird nur der Teil der Datenbank gesichert, der tatsächlich Daten enthält; nicht genutzter Speicherplatz wird nicht gesichert. Das Ergebnis sind schnellere Sicherungsvorgänge.
Obwohl Datenbanken in SQL Server so konfiguriert werden können, dass sie bei Bedarf automatisch vergrößert werden, können Sie auch weiterhin Speicherplatz in der Datenbank reservieren, um sicherzustellen, dass dieser Speicherplatz verfügbar ist. Das Reservieren von Speicherplatz in der Datenbank wirkt sich nicht negativ auf den Sicherungsdurchsatz oder die benötigte Gesamtzeit für die Datenbanksicherung aus.
Optimieren der Synchronisierung des Protokollversands
Beim Versuch, ein Protokollversandziel zu synchronisieren, ist es nicht erforderlich, WITH STANDBY zwischen RESTORE LOG-Schritten zu verwenden.