Welche Methoden befolgen Sie, um falsche Datenaktualisierungen in großen Datenbanken zu vermeiden?

Ein typischer Rat vor jeder Produktionsbereitstellung ist, zuerst die Datenbank zu sichern. Auf diese Weise haben Sie immer noch ein Backup, um alte Datensätze zu vergleichen und zu korrigieren, wenn das neue Update ein Problem aufweist, das zu potenziellem Datenverlust oder logischer Datenbeschädigung führen kann.

Dies kann jedoch gut funktionieren, bis die DB-Größe nur noch wenige GB beträgt. Sobald die DB-Größe sehr groß ist, dauert es lange, bis die Sicherungen abgeschlossen sind. Welche bewährten Methoden sollten in solchen Situationen befolgt werden, um eine Beschädigung logischer Daten aufgrund logischer Probleme bei einer Codebereitstellung zu vermeiden?

Als jemand, der sich regelmäßig mit dem Aktualisieren der Produktionsdatenbank für Kunden für unsere Software-Upgrades befasst hat, sage ich Ihnen, dass der beste Weg, um Fehler zu minimieren, darin besteht, Aktualisierungen so einfach wie möglich durchzuführen.

Wenn Sie eine Änderung an allen Datensätzen und nicht an bestimmten Datensätzen vornehmen können, ist dies vorzuziehen.

Mit anderen Worten, wenn Sie eine Liste mit IDs von Datensätzen erhalten, deren Status geändert werden muss, sollten Sie sich fragen, warum die Aktualisierung im Kontext des Programms durchgeführt wird. Es kann sein , dass der 10 Datensätze , die Sie aktualisieren müssen, wird nur die Tabelle hat 10 Elemente. Daher sollten Sie sich fragen, ob Sie konzeptionell nur den Status aller Datensätze aktualisieren.

Wenn Sie einfügen können, ist es vorzuziehen.

Das Hinzufügen eines Datensatzes ist in sich abgeschlossen. Damit meine ich, es gibt nur einen Nebeneffekt beim Hinzufügen eines Datensatzes, und das ist die Existenz eines Datensatzes, der vorher nicht existiert hat. Daher sollte es keine Probleme geben, es sei denn, Sie fügen einen Datensatz hinzu, der nicht vorhanden sein sollte.

Wenn Sie das Löschen vermeiden können, ist dies vorzuziehen.

Wenn Sie eine Löschung durchführen, entfernen Sie Daten, die ohne eine Sicherung nicht wiederherstellbar wären. Versuchen Sie nach Möglichkeit, die Daten so zu organisieren, dass Sie Datensätze deaktivieren können, indem Sie ihren Status ändern, anstatt den Datensatz physisch zu löschen. Der Datenüberschuss kann in einer Partition abgelegt oder in einem späteren Moment vollständig entfernt werden, sobald Sie sicher sind, dass keine Probleme vorliegen.

Haben Sie eine konsistente Update-Richtlinie.

Wenn Sie einen Datensatz aktualisieren müssen, kann Folgendes passieren:

1. Ihr Datensatz existiert nicht.
2. Ihr Datensatz existiert, wurde aber bereits geändert.
3. Ihr Datensatz ist vorhanden und muss geändert werden.

Sie benötigen eine Richtlinie, um die Vorgehensweise zu bestimmen, falls etwas nicht wie geplant verläuft. Der Einfachheit halber sollten Sie auf allen Ebenen konsistent sein und diese Richtlinie in jeder Situation dieses Typs anwenden , nicht nur für bestimmte Tabellen. Dies erleichtert die spätere Wiederherstellung von Daten. Im Allgemeinen ist es meine Regel, das Skript so zu schreiben, dass es später erneut ausgeführt werden kann. Sollte das Skript fehlschlagen, ist es schön zu wissen, dass Sie die richtigen Anpassungen vornehmen und erneut ausführen können. Sie können jedoch Ihre eigene Richtlinie auswählen, die am besten zu Ihnen passt.

Backups

Dies ist keinesfalls eine Entschuldigung dafür, dass Sie vor einem Update in einer Produktionsumgebung ein Backup durchführen müssen! Obwohl ich ein Backup habe, halte ich es für ein Versäumnis, das Backup verwenden zu müssen. Datenverlust ist auch im schlimmsten Fall nicht möglich .

Fazit

Sie werden es nicht immer so haben, wie Sie es wollen. Das Tabellenschema wird wahrscheinlich nicht von Ihnen festgelegt. Daher sind die Aktualisierungstypen, die Sie erwarten können, sowohl kompliziert als auch riskant. Wenn Sie diesbezüglich eine Meinung haben, sollten Sie diese Punkte berücksichtigen, da sie Aktualisierungen unkompliziert und ohne nennenswertes Risiko vornehmen.

Viel Glück!

Zu diesem Zeitpunkt sollten Sie ein kommerzielles DB-System verwenden, das Snapshots unterstützt (Oracles nennt es Flashback ) - genau dafür sind sie gedacht .

Denken Sie daran, dass Sie ohnehin ein Backup-Konzept benötigen - mehr Daten bedeuten nicht, dass Sie Backups löschen, weil sie schwierig werden, ganz im Gegenteil. Sie benötigen eine Art kontinuierliches Backup, z. B. basierend auf der Replikation mit automatischem Failover.

Dies ist ein riesiger Bereich - erwarten Sie also, dass diese Frage in relativ kurzer Zeit geschlossen wird, aber aus dem Häuschen (als ehemaliger DBA für riesige Datenbanken):

Mart / Repository

Sie können ein gewisses Risiko mindern, wenn Sie über eine separate Datenbank für Aktualisierungen und eine separate Datenbank verfügen, die jeder verwendet. Dann müssen nur noch die Daten von einem DB in den anderen kopiert werden, nachdem verschiedene Prüfungen stattgefunden haben. Mart / Repository ist, wie es manchmal beschrieben wird, aber Sie könnten primäre / sekundäre, Master / Slave usw. haben.

Quellcode

Haben Sie für alles, was sich ändern kann, einen Quellcode, der sich darauf bezieht, wie die Daten aktualisiert wurden. Wie viele davon Sie haben, variiert von DB zu DB, aber Sie haben möglicherweise eine für jeden Benutzer, jede Rolle, jeden Datenfeed, jedes Codemodul usw.

Datum erstellen / aktualisieren

Etwas, das beim Verfolgen von Fehlern sehr hilfreich sein kann, ist das Erstellen und Aktualisieren von Daten für jede Zeile. Dann sehen Sie auf einen Blick, welche Zeilen aktualisiert wurden.

ETL

Wenn die Datenbankaktualisierung Teil einer Datenfactory ist, können Sie möglicherweise einen vorherigen Jahrgang aus Einfachdateien wiederherstellen.

Backup

Vollständige Sicherungen nehmen natürlich viel Speicherplatz in Anspruch, aber das übliche Szenario sieht vor, dass eine vollständige Sicherung in regelmäßigen Abständen (etwa wöchentlich) und eine teilweise Sicherung häufiger (täglich usw.) durchgeführt wird.

Zeitpunkt der Wiederherstellung

Abhängig davon, welches RDBMS Sie verwenden, kann die Wiederherstellung zu einem bestimmten Zeitpunkt erfolgen. Auf diese Weise können Sie zu der Zeit zurückkehren, als ein guter Zustand bekannt war. Dies erfordert jedoch eine große Menge an Speicherplatz, der sich erhöht, je weiter Sie zurückkehren möchten.

Prüfung

Wenn Sie über Prüftabellen verfügen, erfahren Sie, wer (oder was) eine Zeile aktualisiert hat. Dies kann Ihnen einen guten Ausgangspunkt für die Untersuchung geben.

Geschichte

Bei einigen kritischen Tabellen wird zum Zeitpunkt der Aktualisierung eine Kopie der entsprechenden Zeile erstellt, damit die Daten bei Bedarf wiederhergestellt werden können.

Datenvalidierung

Stellen Sie sicher, dass grundlegende Validierungsprüfungen für die Daten durchgeführt werden, bevor sie gespeichert werden - zusätzlich zu den grundlegenden Datentypprüfungen.

Referentielle Integrität

Referentielle Integrität ist keine Wunderwaffe, kann jedoch dazu beitragen, dass die Daten gut strukturiert sind.

Viele Male, wenn wir ein "One-Shot" -Update durchführen, sichern wir die Produktion und stellen sie auf einem Testserver wieder her. Dann erstellen wir einen Testanzug und führen den einen Schuss aus. Wir überprüfen anhand der Tests, ob sich die Daten geändert haben, und stellen sicher, dass die Aktualisierung erfolgreich ist, und ändern die Daten so, wie wir es erwarten. Dies wird als Trocken- oder Probelauf bezeichnet. Ich empfehle dies zu tun.

Dies gibt jedem ein gutes Gefühl, dass der eine Schuss erfolgreich sein wird. Wir können nicht 100% garantieren, da die Daten ab dem Datum des Testlaufs aktualisiert werden, aber wir steigern das Vertrauen und die Erfolgsfaktoren. Dies gibt auch einen guten Überblick über alle Probleme, die auftreten werden, da wir eine Kopie der Produktion verwenden. Wenn das Update aus irgendeinem Grund fehlschlägt, können wir bei Bedarf vor dem Wiederherstellen immer zum Back-Run gehen. Wir hätten jedoch Probleme mit dem Dry-Run finden und beheben müssen.

Wenn Sie nicht die gesamte Datenbank verwenden können (wenn diese wirklich groß ist), exportieren Sie eine kleinere Stichprobengröße und führen Sie das Update (kleiner Probelauf) für die tatsächlichen Daten aus. Ich bevorzuge den gesamten Datensatz, wenn möglich, um sicherzustellen, dass der Test so vollständig wie möglich ist.