it-swarm.com.de

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

Ein typischer Ratschlag vor Produktionsbereitstellungen 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 in wenigen GB angegeben ist. Sobald die DB-Größe sehr groß ist, dauert das Sichern lange. Welche Best Practices sollten in solchen Situationen befolgt werden, um eine Beschädigung der logischen Daten aufgrund logischer Probleme bei einer Codebereitstellung zu vermeiden?

20
Pritam Barhate

Als jemand, der sich regelmäßig mit der Aktualisierung 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 zu gestalten.

Wenn Sie alle Datensätze anstelle bestimmter Datensätze ändern 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 von den 10 Datensätzen, die Sie aktualisieren müssen, nur die Tabelle hat 10 Elemente enthält. 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 geschlossen. Damit meine ich, dass das Hinzufügen eines Datensatzes nur einen Nebeneffekt hat, nämlich das Vorhandensein eines Datensatzes, der zuvor nicht vorhanden war. Daher sollten keine Probleme auftreten, 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 sonst nicht wiederhergestellt werden könnten. 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 eine Partition gestellt oder zu einem späteren Zeitpunkt 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 eines von mehreren Dingen passieren:

  1. Ihr Datensatz existiert nicht.
  2. Ihr Datensatz ist vorhanden, wurde jedoch bereits geändert.
  3. Ihr Datensatz existiert und erfordert die Änderung.

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 any Situationen dieses Typs anwenden, nicht nur für bestimmte Tabellen. Dies erleichtert die spätere Wiederherstellung von Daten. Im Allgemeinen ist es meine Richtlinie, 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 entschuldigt Sie keinesfalls, ein Backup durchzuführen, bevor Sie ein Update in einer Produktionsumgebung durchführen! Selbst bei einem Backup halte ich es für einen Fehler, das Backup verwenden zu müssen. Datenverlust kann auch im Szenario Worst-Case nicht möglich sein.

Fazit

Sie werden es nicht immer so haben, wie Sie es wollen. Das Tabellenschema wird wahrscheinlich nicht von Ihnen festgelegt. Daher bedeutet dies, dass die Arten von Aktualisierungen, die Sie erwarten können, sowohl kompliziert als auch riskant sind. Wenn Sie diesbezüglich ein Mitspracherecht haben, ist es hilfreich, diese Punkte zu berücksichtigen, da Aktualisierungen unkompliziert und ohne erhebliches Risiko vorgenommen werden.

Viel Glück!

25
Neil

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

Denken Sie daran, dass Sie ohnehin ein Backup-Konzept benötigen. Wenn Sie mehr Daten haben, bedeutet dies nicht, dass Sie Backups löschen, da diese schwierig werden, im Gegenteil. Sie benötigen eine Art kontinuierliches Backup, z. basierend auf Replikation mit automatischem Failover.

12

Dies ist ein riesiger Bereich - erwarten Sie also, dass diese Frage in relativ kurzer Zeit geschlossen wird, aber auf den ersten Blick (als ehemaliger DBA in riesigen Datenbanken):

Mart/Repository

Sie können ein gewisses Risiko verringern, wenn Sie über eine separate Datenbank für Updates und eine separate Datenbank verfügen, die von allen Benutzern verwendet wird. Dann müssen nur noch die Daten von einer Datenbank in die andere kopiert werden, nachdem verschiedene Überprüfungen stattgefunden haben. Mart/Repository wird manchmal beschrieben, aber Sie haben möglicherweise Primär/Sekundär, Master/Slave usw.

Quellcode

Haben Sie für alles, was sich ändern kann, einen Quellcode, der sich auf 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.

Erstellungs-/Aktualisierungsdatum

Etwas, das bei der Verfolgung von Fehlern sehr hilfreich sein kann, ist die Erstellung und Aktualisierung 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 Flatfiles wiederherstellen.

Backup

Vollständige Sicherungen beanspruchen natürlich viel Speicherplatz, aber das übliche Szenario besteht darin, dass eine vollständige Sicherung in regelmäßigen Abständen (z. B. wöchentlich) und teilweise (täglich usw.) teilweise durchgeführt wird.

Zeitpunkt der Wiederherstellung

Abhängig davon, welches RDBMS Sie verwenden, gibt es einige Unterstützungspunkte für die Wiederherstellung. Auf diese Weise können Sie auf die Zeit zurücksetzen, als ein guter Zustand bekannt war. Dies erfordert jedoch eine große Menge an Speicherplatz, die sich erhöht, je weiter Sie zurückgehen möchten.

Audit

Wenn Sie Audit-Tabellen haben, 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 - über die grundlegenden Datentypprüfungen hinaus.

Referenzielle Integrität

Die referenzielle Integrität ist kein Wundermittel, kann jedoch dazu beitragen, dass die Daten gut strukturiert sind.

3
Robbie Dee

Wenn wir ein "One-Shot" -Update durchführen, sichern wir häufig die Produktion und stellen sie auf einem Testserver wieder her. Dann erstellen wir eine Reihe von Tests und führen den einen Schuss aus. Wir überprüfen, ob sich die Daten durch die Tests geändert haben, und stellen sicher, dass das Update 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 dafür, 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 stärken das Vertrauen und die Erfolgsfaktoren. Dies gibt auch eine echte Vorstellung von Problemen, die auftreten werden, wenn wir eine Kopie der Produktion verwenden. Wenn das Update aus irgendeinem Grund fehlschlägt, können wir bei Bedarf vor dem Wiederherstellen jederzeit zum Back Run zurückkehren. Wir hätten jedoch alle Probleme mit dem Trockenlauf finden und beheben müssen.

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

2
Jon Raynor