...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
| Status | ||||||
|---|---|---|---|---|---|---|
|
Wir empfehlen die Durchführung einer Konsistenzprüfung mit SQL
...
Server DBCC CHECKDB ehe Sie online eine vollständige Datenbanksicherung vornehmen.
DBCC CHECKDB (aus der Microsoft MSDN Bibliothek) überprüft die logische und physische Integrität aller Objekte in einer Datenbank. Datenkorruption kann innerhalb einer Datenbank zu vielfältigen Problemen führen. DBCC CHECKDB warnt Sie vor Korruption, damit diese behoben werden kann, bevor sich die Probleme verschlimmern.
...
Weitere Informationen zu DBCC CHECKDB finden Sie in der Microsoft SQL Server Dokumentation.
...
| Note |
|---|
Warnung Die Ausführung von DBCC CHECKDB ist zeitintensiv, verbraucht Ressourcen und belastet die Produktionssysteme von FactoryLogix erheblich—insbesondere Datenbanken mit mehr als einem Terabyte. |
Auf Standardhardware mit einem guten I/O Subsystem, können I/O Durchsätze im Bereich von 100-150 GB/h erreicht werden. In Anbetracht derartiger I/O Durchsätze ist das Ausführen von DBCC CHECKDB auf einem Produktionssystem nicht immer sinnvoll. Aus diesem Grund entscheiden sich einige Kunden dafür, DBCC CHECKDB überhaupt nicht aus zu führen.
Obwohl die Zuverlässigkeit von Hardware und Software stetig zunimmt, kann es dennoch zu physischen Schäden kommen (beispielsweise ein katastrophaler Stromausfall ohne ein Battery Backup für Hardware-Komponenten). Physische Schäden an Verbindungen und Hardware-Komponenten können niemals ausgeschlossen werden. Wenn es zu einem kritischen Fehler kommt, können Daten manchmal nur wiederhergestellt werden, indem die FactoryLogix-Datenbank durch Zurücksetzen auf eine vorherige Datenbanksicherung wiederhergestellt wird und anschließend alle Transaktionsprotokolle bis zum aktuellsten angewendet werden.
Um physische Schäden frühzeitig erkennen zu können, muss Ihre Backup-Methode zuverlässig sein. Wenn Sie die Auswirkungen physischer Schäden minimieren möchten, sollten die folgenden drei Maßnahmen befolgt werden:
Führen Sie DBCC CHECKDB regelmäßig auf einem Sandbox-System aus, welches ein wiederhergestelltes Abbild der Produktionsumgebung enthält.
Die verbrauchten Ressourcen und die Zeitdauer des DBCC CHECKDB betreffen die Benutzer auf einem derartigen System nicht.Führen Sie DBCC CHECKDB regelmäßig auf dem Produktionssystem aus, jedoch nur innerhalb eines geplanten Wartungsfensters.
Testen Sie die Wiederherstellung der FactoryLogix-Datenbank aus einer Online-Sicherung oder einer Differenz- und Transaktionsprotokollsicherung.
...
Note
Die Tatsache, dass eine Tape-basierte Sicherung durchgeführt wurde, bedeutet nicht automatisch, dass diese auf dem Tape konsistent ist oder von diesem gelesen werden kann. Bänder und Kassetten können ausfallen. Ein Backup in einem Tresor zu haben, garantiert noch nicht, dass Daten im Katastrophenfall erfolgreich wiederhergestellt werden können - das Backup muss außerdem auch lesbar sein.
Behalten Sie für große Datenbanken mit einem Volumen von Terabyte eine zweite Kopie der Datenbank in ihrem neuesten Status bei, indem Sie entweder den Protokollversand oder die Datenbankspiegelung verwenden.
Diese beiden High-Availability-Methoden entkoppeln Hardware-Komponenten und können so ein physisch konsistentes Image der Produktionsdatenbank auf einem sekundären Standort bereitstellen.
Verwandte Themen |
|---|