Gibt es Probleme beim Bereitstellen einer SQL Server-Datenbank auf einem Produktionsserver durch Erstellen einer Sicherung?

7

Dies ist eine leicht belastete Frage, da ich bereits angenommen habe, dass das beschriebene Szenario falsch ist.

Ein DBA stellt eine von mir geschriebene Anwendung bereit, die eine MS SQL Server 2008-Datenbank enthält. Er hat mich gebeten, eine Datenbanksicherung von meinem Entwicklungscomputer zu erstellen, damit er sie auf dem Produktionsserver wiederherstellen und somit bereitstellen kann. Dies ist eine Bereitstellung auf der grünen Wiese, sodass keine Daten migriert werden müssen. Ich hatte erwartet, ein DDL-Skript bereitzustellen, das ich sorgfältig getestet und sichergestellt habe, dass es alles enthält, was erforderlich ist. Wenn ich es in SSMS ausführe, wird die Datenbank mit einem Klick erstellt.

Die Verwendung der Sicherungsfunktion für die Bereitstellung scheint mir nicht richtig zu sein, aber ohne ein Experte für SQL Server zu sein, kann ich mir keinen soliden Grund vorstellen, dies nicht zu tun. Ich hätte zum Beispiel gedacht, dass die Datenbank von der Entwicklungsmaschine „kontaminiert“ wird - vielleicht der Computername, die Verzeichnisstruktur oder die dort irgendwo gespeicherten Benutzernamen. Ist dies der Fall oder ist das Sichern und Wiederherstellen einer gültigen Bereitstellungstechnik?

Stephen Hewlett
quelle
Warum nicht die Frage wie "Ist es in Ordnung zu ..." stellen, anstatt die Frage so zu stellen, als ob etwas nicht stimmt?
Aaron Bertrand
... weil ich mehr daran interessiert bin, unbekannte Nachteile des Ansatzes zu entdecken, als Vorteile zu finden, die dem DBA bereits bekannt sind
Stephen Hewlett
Aber Ihre Frage lautet immer noch: "Ich weiß, dass das schlecht ist, aber sag mir warum!" Warum nicht fragen: "Gibt es unbekannte Nachteile ...?" Wenn das die Frage ist, die Sie wirklich stellen wollen?
Aaron Bertrand
1
Und sprechen Sie auch von einer einmaligen ersten Bereitstellung oder der Bereitstellung von Änderungen? Für mich sind das sehr unterschiedliche Fragen.
Aaron Bertrand
1
Zu Ihrer Information über "die Metadaten, die SQL Server hinter den Kulissen speichert": Ja, es gibt einige, die während der Sicherung / Wiederherstellung erhalten bleiben und von dem Problem betroffen sein können . Lesen Sie stackoverflow.com/q/2723061/105929 , dba.stackexchange.com/q/39500/708
Remus Rusanu

Antworten:

10

Bei der Verwendung von Sicherungsdateien als Bereitstellung ist alles falsch. Die Last für die Bereitstellung der DDL liegt jedoch nicht beim DBA, sondern bei der Entwicklung. Ihre Design- und Entwicklungsartefakte sollten Datenbankinstallations- und Upgrade-Skripte gewesen sein. Ändern Sie niemals etwas in der Datenbank manuell, alles sollte mit Ihrer App geändert werden. Rails bekommt dies mit der gesamten Migrationsinfrastruktur in den Griff, und Sie sollten versuchen, es auch zu übernehmen. Ich habe mich lange für die Verwendung ähnlicher Techniken ausgesprochen, siehe Versionskontrolle und Ihre Datenbank .

Lassen Sie mich zunächst erläutern, warum die quellcodebasierte Bereitstellung / Aktualisierung der binärbasierten Bereitstellung (.bak- oder diff-Tools) überlegen ist:

  • Quellcode kann in die Quellcodeverwaltung eingecheckt werden. Dies allein sollte das ganze Argument regeln. Die Quellcodeverwaltung gibt Ihrer Geschichte eine Zukunft, in der Sie zurückblicken und die Check-in-Notizen lesen und die Gründe für den aktuellen Status verstehen können.
  • Der Quellcode kann auf einen Blick schnell überprüft werden. Du siehst es dir an und liest es. Binärdatenbanken müssen angehängt werden und erfordern umfassende Kenntnisse der Metadatenkataloge, um auch die grundlegenden Eigenschaften lesen zu können
  • Quellcode ist sauber. Sie sehen CREATE TABLE Foo (...), was die Absicht klar vermittelt. Wenn Sie das Objekt durch die Binärverteilung extrahieren möchten, werden Sie in einer Vielzahl von Standardeigenschaften angezeigt. Sie verlieren die ursprüngliche Absicht.
  • Der Quellcode kann beim Einchecken einer Peer-Review unterzogen werden.
  • Der Quellcode wird in die zusammenhängende Bereitstellung integriert

Und ich habe auch Argumente, warum die Bereitstellung per Backup schlecht (sehr schlecht) ist:

  • Sie haben das Problem nur verschoben. Beim allerersten Update der App tritt das Problem auf, ein Update bereitzustellen, ohne die Daten zu verlieren. Dies kann am nächsten Tag nach der Bereitstellung auftreten, wenn ein Problem in der Produktion festgestellt wird und Sie vor der Lücke stehen: Wie kann die Produktionsdatenbank an die Entwicklungsdatenbank angepasst werden?
  • Datenbanken sind nicht eigenständig. Die Bereitstellung ruft Objekte außerhalb der Datenbank auf (Anmeldungen, SQL Agent-Jobs, Wartungsplan usw.), von denen keines mit einer Sicherung bereitgestellt werden kann.
  • Sie wissen nie, was Sie bereitgestellt haben. Vergessene Tische während der Entwicklung übrig? Testdaten? Es ist sehr schwierig, eine Datenbank zu bereinigen, aber es ist natürlich, Ihren Quellcode auf dem neuesten Stand und korrekt zu halten.
Remus Rusanu
quelle
Ich dachte, dass sich die Frage auf die Erstbereitstellung und nicht auf die regelmäßige Bereitstellung konzentrierte. Zumindest war das der Kontext, auf den ich geantwortet habe.
Aaron Bertrand
@AaronBertrand Manchmal bedeutet das Beantworten einer Frage, Antworten auf nicht gestellte oder nicht gedachte (Wort?) Fragen aufzuzeigen.
WernerCD
@WernerCD ja, danke, ich bin mit dem Konzept vertraut. Remus 'Antwort liest sich jedoch wie eine Punkt-für-Punkt-Dissertation darüber, warum Sie Backup / Restore nicht für Dot-Release-Bereitstellungen verwenden sollten, und scheint den tatsächlichen Anwendungsfall (anfängliche Bereitstellung) zu ignorieren.
Aaron Bertrand
5

Nein, es ist nichts falsch mit der Verwendung einen Backup für anfängliche Bereitstellung, in der Tat würde ich sagen , dass dies oft der sicherste Weg , es zu tun. Es gibt keine "Kontamination", die auftreten kann, es sei denn, Sie haben fest codierte Dinge wie Servernamen oder Datenbanknamen, die sich in der Produktion von denen in der Testumgebung unterscheiden.

Eine Sicherung / Wiederherstellung (ähnlich wie Ihr eigenes DDL-Skript, das auf die Datenbank beschränkt ist) bringt jedoch keine Anmeldungen auf Serverebene, Verbindungsserver, SQL Agent-Jobs usw. mit sich.

Es gibt einige andere Nebeneffekte, die Sie mit einem Backup erhalten, die Sie nicht unbedingt mit einem DDL-Skript erhalten, beispielsweise wenn Sie Ihre ursprüngliche Tabelle wie folgt erstellt haben:

CREATE TABLE dbo.foo
(
  bar INT PRIMARY KEY,
  mort INT FOREIGN KEY REFERENCES dbo.mort(MortID),
  x TINYINT CHECK (x IN (1,2)),
  y INT NOT NULL DEFAULT 1
);

Alle diese Einschränkungen haben systemgenerierte Namen, wie z PK__foo__DE90ECFFA28BBAB8. Wenn Sie dasselbe Skript in der Produktion ausführen, unterscheidet sich der Name, es sei denn, Sie haben die genaue Tabellendefinition in der Testumgebung geschrieben. Dies kann später zu Problemen führen, wenn Sie aus dem Test Drop / Create / Alter-Skripte generieren und diese in der Produktion ausführen müssen.

Sie erhalten auch alle Daten in Nachschlagetabellen usw., wenn Sie eine Sicherung erstellen, die Sie manuell skripten müssen, um diese Daten in die Produktion zu bringen. (Sie müssen jedoch sicherstellen, dass Sie alle Testdaten löschen, die Sie auch in der Produktion nicht benötigen .)

Und eine Schwäche beim Herausschreiben selbst besteht darin, dass Sie sicherstellen müssen, dass alle Objekte in der richtigen Abhängigkeitsreihenfolge erstellt werden. Möglicherweise sind im Test Abhängigkeiten vorhanden, die in der Produktion fehlen, da die Objekte nicht in der richtigen Reihenfolge generiert wurden.

Wenn es darauf ankommt, ist ein Backup einfach sauberer. Und Sie sollten die Datenbank testen, wenn sie bereitgestellt wird, damit Sie alle "Kontaminationen" schnell finden und in beiden Umgebungen korrigieren können.

Sobald die Datenbank zum ersten Mal bereitgestellt wurde, besteht die einzige Möglichkeit, Änderungen zu einem späteren Zeitpunkt bereitzustellen, darin, sie per Skript bereitzustellen. Ich hatte großes Glück, Vergleichs- / Bereitstellungsskripte mit SQL Compare von Red-Gate zu erstellen. Während Remus absolut Recht hat, ist diese Quellcodeverwaltung die beste Lösung dafür. In Wirklichkeit speichert die Quellcodeverwaltung normalerweise ein CREATE TABLESkript, das Sie nicht weit bringt, wenn Sie eine Spalte hinzugefügt und den Datentyp einer anderen Spalte geändert haben. Sie müssen noch eine Art Diff-Skript erstellen, das nur die Änderungen auf die Produktion anwendet, nicht die Tabelle löscht und neu erstellt.

Wenn Sie Dinge wie lokale Nachschlagetabellen haben, die sich in anderen Datenbanken befinden oder sich auf anderen Servern befinden könnten, sollten Sie Synonyme verwenden, anstatt diese Namen in Ihrem Code fest zu codieren. Dann müssen Sie nur sicherstellen, dass die Synonyme in jeder Umgebung korrekt sind, anstatt alle drei / vier Teilenamen in allen Ihren Modulen zu finden und sie bei der Bereitstellung zu aktualisieren. Wenn Sie lokale Dateipfade haben, die sich zwischen den Umgebungen unterscheiden, verwenden Sie eine zentrale Eigenschaftentabelle, anstatt diese Pfade in Ihre Prozeduren usw. fest zu codieren.

Theoretisch könnten Sie später eine Sicherungs- und Wiederherstellungsmethode verwenden, aber das funktioniert nicht gut, wenn die Produktionsdatenbank bereits verwendet wird. Es wird schwierig, eine Datenbank aus dem Test wiederherzustellen und keine der in der Produktion gesammelten Daten zu verlieren .

Aaron Bertrand
quelle
Ich denke, es ist besser, Kontaminationen zu vermeiden, als sie zu testen und zu versuchen, sie zu finden, obwohl mein Begriff „Kontamination“ derzeit ziemlich abstrakt ist und unbegründet sein könnte.
Stephen Hewlett
@ StephenHewlett Nun, wir können nicht vorhersagen, was wir nicht über Ihre Umgebung wissen. Der beste Weg, um eine Kontamination zu vermeiden, besteht darin, keine Dinge zu schreiben, die lokale Server- und Datenbanknamen, Dateipfade usw. fest codieren, die unterschiedlich sein könnten, wenn die Datenbank auf einen anderen Server verschoben wird. Wenn Sie ein Skript erstellen, können Sie diese übersehen, genauso wie Sie es vermissen, indem Sie eine Datenbanksicherung durchführen.
Aaron Bertrand
Ich habe die Datenbank aus dem Skript erstellt und nicht umgekehrt. Daher weiß ich, dass in "meinen" Daten nichts fest codiert ist. Es sind eher die Metadaten, die SQL Server hinter den Kulissen speichert - oder ein möglicher Mangel daran -, über die ich nachgedacht habe.
Stephen Hewlett
2

Ich sage, tu es nicht. Verwenden Sie ein SQL-Skript, das aus möglichst standardmäßigen Anweisungen erstellt wurde, und notieren Sie sich, für welche SQL Server-Versionen diese Version des Skripts funktioniert hat.

Ich hatte Probleme mit Software, die über ein Backup verteilt wurde, als ich die Software zu einem viel späteren Zeitpunkt erneut installieren musste.

Aufgrund des Alters des ursprünglichen Sicherungsabbilds, das für die Bereitstellung verwendet wurde und kein neueres verfügbar war, musste ich eine alte Version von SQL Server verwenden, da die neueren Versionen von SQL Server die Sicherung im alten Format nicht unterstützten. Während ich fast alle Anwendungsupdates nacheinander anwendete, musste ich ein SQL Server-Upgrade über die alte SQL Server-Version hinaus anwenden, da für das Anwendungsupdate eine neuere SQL Server-Version erforderlich war, als ursprünglich von der alten Version erforderlich Image "Deployment Backup".

Als DBA fand ich es SEHR frustrierend, herauszufinden und dann tatsächlich die erforderlichen Schritte auszuführen. Als zusätzlichen Bonus habe ich dies während einer Disaster Recovery-Situation getan, damit ich die aktuelle Produktionsdatenbank aus dem Backup wiederherstellen konnte, da die neueste Version der Software erforderlich war, die ohne die Installation des ursprünglichen "Deployment Backup" nicht installiert werden konnte.

BeowulfNode42
quelle
2

Ich denke, die Antwort darauf ist sowohl Ja als auch Nein. Du sagtest:

Dies ist eine Bereitstellung auf der grünen Wiese, sodass keine Daten migriert werden müssen.

Wenn es sich um eine Erstbereitstellung handelt, besteht kein Problem darin, eine Sicherungskopie einer Entwicklungsdatenbank für die Produktion zu erstellen. Wenn Sie das sagen, müssten Sie (oder hoffentlich Ihr DBA) offensichtlich die Datenbank bereinigen und alle Sicherheitsbenutzer und andere Gubbins entfernen, die möglicherweise mit der Datenbanksicherung wiederhergestellt wurden.

Jedoch:

Als langfristige Lösung ist dies keine gute Bereitstellungstechnik, da ein Client, sobald er die Datenbank verwendet, seine Daten dort hat, sodass Sie Ihre Datenbank nicht über ihre Datenbank wiederherstellen können.

Wenn Sie also zur ersten Bereitstellung zurückkehren, ist es in Ordnung, eine Sicherung einer leeren Datenbank wiederherzustellen. An diesem Punkt beginnen Sie jedoch mit der Versionskontrolle, um Updates und zukünftige Bereitstellungen zu verwalten und so eine saubere bereitstellbare Version der Datenbank beizubehalten.

Schritte:

  1. Erstellen Sie Ihre saubere Datenbank (bei Bedarf aus einer Sicherung wiederhergestellt)
  2. Versionskontrolle an dieser Stelle
  3. Skripten Sie alle Aktualisierungen der Datenbank und steuern Sie die Versionskontrolle
  4. Wenn eine neue Version / Version zur Bereitstellung bereit ist, führen Sie alle neuen Skripts für eine saubere Datenbank aus, um sie von Version X auf Version Y zu übertragen, und aktualisieren Sie dann die Version, die Sie in der Quellcodeverwaltung haben.
  5. Schließlich würden Sie die Skripte für die Client-Datenbank ausführen, um sie zu aktualisieren.

Alle Aktualisierungen, die Sie an der Datenbank vornehmen, werden vor der Bereitstellung lokal getestet, und beim Aktualisieren einer Clientdatenbank werden lediglich die Skripts ausgeführt, mit denen sie von einer Version in eine andere übertragen werden. Die Quellcodeverwaltung gibt Ihnen den Verlauf zwischen sauberen Versionen der Datenbank und den angewendeten Skripten an.

Gerber
quelle
Vergessen Sie nicht, dass sie gelegentlich von Grund auf neu installieren müssen (softwaremäßig) und ihre eigenen Daten aus dem Backup wiederherstellen müssen, und welche Reihenfolge sie damit durchlaufen müssen.
BeowulfNode42
das DBMS oder die darauf befindliche Anwendung neu installieren?
Tanner
Alle drei DMBS, Anwendungen und ihre eigenen Daten, da es sich um eine vollständige Disaster Recovery-Situation handelt, in der sie kein vollständiges System-Image haben.
BeowulfNode42
Ich denke nicht, dass die Neuerstellung eines Servers für die Installation seiner Software in einer Disaster Recovery-Situation für diese Frage relevant ist. In Bezug auf die Bereitstellung einer Datenbank würde die Datenbank in einer Disaster Recovery-Situation einfach ein Backup aus der vorherigen Nacht wiederherstellen, um die neueste Datenbank online zu stellen, vorausgesetzt, dies wird jede Nacht durchgeführt.
Tanner
Das wäre in Ordnung, wenn der Server selbst die Katastrophe überleben würde. Einige Katastrophen erfordern jedoch, dass ein Server mit neuer Hardware und Neuinstallationen von allem, einschließlich DBMS und der Anwendung, vollständig neu erstellt wird. Erst dann kann die Datenbanksicherung wiederhergestellt werden. Es ist die Neuinstallation oder Bereitstellung eines Systems, das bereit ist, die aktuelle Datenbanksicherung zu erhalten, über die ich spreche. Dies ist wahrscheinlich Jahre und mehrere Hauptversionen nach der ersten ursprünglichen Bereitstellung der Fall.
BeowulfNode42