Änderungen des SQL Server 2014-Schemas in einer Umgebung mit mehreren Benutzern rund um die Uhr

Wir haben SQL Server 2014 Enterprise installiert, um eine Datenbank auszuführen, die rund um die Uhr verfügbar sein sollte. Unsere Datenbank ist groß genug (200 GB +). Wir haben auch eine Reihe von Diensten, die jede Minute unsere Datenbank abrufen, um neue Daten zu lesen, zu aktualisieren oder einzufügen. Wir möchten unseren Kunden eine "Hot" -Reploy-Funktion zur Verfügung stellen und unsere täglichen Updates (.net- und Schema-Updates) für die Kunden transparent machen. Wir haben eine Lösung gefunden, die auf einem Cluster mit Load Balancer basiert, um die Binärdateien unserer App zu aktualisieren, aber wir haben immer noch ein Missverständnis hinsichtlich des Bereitstellungsprozesses von Datenbankaktualisierungen und der Best Practices zur Lösung dieses Problems.

Fahren Sie bei Schemaänderungen einen Server herunter, wenden Sie Schemaänderungen an, stellen Sie ihn wieder her, und wenden Sie dieselben Änderungen auf die zweite Instanz an. Kann es mit SQL Server-Tools durchgeführt werden, und ist dies ein gängiger Ansatz? Wie werden Daten nach dem Sichern des Servers synchronisiert? Oder denke ich komplett in die falsche Richtung und gibt es bessere Lösungen?

Unsere gängigen Schemaänderungen: Spalte hinzufügen / löschen, gespeicherte Prozedur hinzufügen / löschen

Im Folgenden wird ein bisschen mehr Planung und Test erforderlich sein.

Blaugrünes Konzept:

Der Kern von Blue-Green Concept besteht darin, Ihre Produktion in zwei Umgebungen zu unterteilen, die jederzeit identisch sind (Datensynchronisation)

1. Das Blue (Current) hat die aktuelle Version des Schemas / Builds oder Produkts und ist Ihre "LIVE" -Umgebung.

2. Gleichzeitig ist Green Ihre Staging- / Testumgebung, in der Sie Ihr Schema / Build oder Produkt auf das NEXT-Release aktualisieren, einen vollständigen Regressionstest durchführen und sich von Ihren Geschäftsbenutzern abmelden lassen. Wenn Sie einmal glücklich sind, werden Sie während einer Übergangszeit das Grüne als Ihre "LIVE" -Umgebung fördern und das Blaue als Pre-Prod / Staging oder Test für die nächste Veröffentlichung herabstufen.

Auf diese Weise haben Sie eine sehr geringe Ausfallzeit und das Risiko eines Bereitstellungsfehlers auf einem aktiven System (das sich im Wartungsfenster befindet, da Sie ein Upgrade durchführen) wird stark minimiert. Wenn Sie dem blau-grünen Ansatz folgen, wechseln Sie zwischen der LIVE- und der VORHERIGEN Version, die für die nächste Version bereitgestellt werden.

Dies erfordert wiederum mehr Hardware / Lizenzierung sowie Planung und Test.

Die meisten Schritte können mithilfe von DACPACs und PowerShell automatisiert werden. Wenn Sie mehrere Instanzen auf einem Server installieren, stellen Sie außerdem sicher, dass Sie die Speichereinstellungen neu ausgleichen, wenn Sie zwischen Blau und Grün wechseln. Die LIVE-Umgebung erhält mehr Speicher als die passive Umgebung.

In meiner aktuellen Umgebung haben wir das Blue / Green-Modell für die Bereitstellung von agilem Code implementiert, mit dem wir alle zwei Wochen auf Code umstellen können. Es ist auch ein Kinderspiel, ein Rollback durchzuführen, falls etwas schrecklich schief geht. Wir haben den Großteil des Bereitstellungsmaterials mithilfe von Dacpacs und PowerShell automatisiert.

(Bildquelle)

Lesen Sie auch den Artikel von Grant Fritchey zur Fehlerbehebung bei Rollback und Wiederherstellung. Herausforderungen und Strategien

Wenn Ihre Datenbank nicht repliziert wird, werden Add-and-Drop-Spalten sehr schnell ausgeführt. Weil add column nur eine leere Position ist, die von SQL erstellt wird. Die Drop-Spalte löscht nur die Referenz.

Andernfalls ist Vorsicht geboten, wenn es Einschränkungen oder Indexe gibt.

ADD/DELETEProzeduren wirken sich nur auf die Ausführung selbst aus. Die Empfehlung ist, vor jeder Änderung daran die Neukompilierung auszuführen

sp_recompile 'myproc'