Unterbrechen Schemaänderungen Verfügbarkeitsgruppen oder werden sie transparent behandelt?

Meine Organisation plant die Einführung von SQL Server 2012-Verfügbarkeitsgruppen und ich versuche zu verstehen, welche Auswirkungen (falls vorhanden) dies auf unseren Anwendungsaktualisierungsprozess haben wird.

Wir veröffentlichen Anwendungsaktualisierungen in einem 8-wöchigen Zyklus. Jede Veröffentlichung kann Schemaänderungen und / oder Datenmigrationen enthalten.

Ich versuche zu verstehen, ob die HA / DR-Lösung die Schemaänderungen transparent behandelt oder nicht (neue Spalten, Indizes werden zu Sekundärdateien hinzugefügt) oder ob manuelle Eingriffe erforderlich sind, um das Schema für jede Instanz zu erstellen und dann Immer wieder einzuschalten.

Ich gehe davon aus, dass das Datenmigrationsstück transparent behandelt wird, möchte dies aber auch bestätigen.

Ich gehe auch pauschal davon aus, dass es keinen Unterschied in diesen Verhaltensweisen gibt, basierend auf der Konfiguration der Verfügbarkeitsgruppen, die ebenfalls falsch sein kann. Lass es mich wissen, bitte.

In einer Nussschale; In jeder Version meiner Anwendung kann ich eine sehr große Tabelle (10 bis 100 Millionen Datensätze) ändern, indem ich Spalten hinzufüge. Einige Spalten sind möglicherweise "netto neu", sodass sie die Funktionen zur Änderung des Enterprise Online-Schemas verwenden können. Andere Spalten können ein Refactoring einer vorhandenen Spalte sein (FullName wird in Vorname und Nachname aufgeteilt), und für jede Zeile in der Tabelle wird eine Migration ausgeführt, um diese Felder zu füllen. Erfordern diese Verhaltensweisen, dass DBAs die AlwaysOn-Konfiguration ändern, oder wird dies standardmäßig behandelt und alle Secondaries erhalten die DDL- und DML-Anweisungen "kostenlos"?

Vielen Dank für jede Klarheit, die Sie zur Verfügung stellen können.

Schemaänderungen und Datenänderungen sind im Wesentlichen gleich. Es funktioniert heute wie herkömmliches Spiegeln: Was im Protokoll auf der Primärseite passiert ist, passiert auf der Sekundärseite. Nicht alles, was in Vegas passiert, muss in Vegas bleiben. :-)

Sie sollten vorsichtig sein, wenn Sie eine Anwendung haben, die auf die primäre Anwendung verweist, und diese aktualisieren, um sie an Schemaänderungen anzupassen. Möglicherweise haben Sie jedoch eine andere Anwendung, die auf die sekundäre Anwendung verweist (z. B. mit schreibgeschützter Absicht), und diese App-Änderung müsste ebenfalls synchronisiert werden.

Ein weiteres potenzielles Problem besteht darin, dass Ihre Datenbank, die Teil einer Verfügbarkeitsgruppe ist, Verweise auf Objekte in anderen Datenbanken enthält (z. B. eine statische Nachschlagetabelle, die in einer Dienstprogrammdatenbank gespeichert ist). Wenn sich diese Änderungen ändern und die AG von diesen Objekten abhängt, müssen Sie diese Änderungen manuell übertragen. Gleiches gilt für Jobs, Anmeldungen auf Serverebene, Verbindungsserver usw. - alles, was außerhalb der Datenbank liegt und / oder nicht transaktionsfähig ist. Datenbankbenutzer können verwaist werden (enthaltene Benutzer beiseite). Ich weiß, dass dies wahrscheinlich offensichtlich ist, wollte es aber der Vollständigkeit halber explizit auflisten.

Weitere Antworten von Remus: Benutzer bitten darum, möglicherweise Abfragen auf dem sekundären Replikat zu entfernen und den Status der Wiederherstellungswarteschlangengröße in der folgenden Tabelle zu überprüfen: sys.dm_hadr_database_replica_states AlwaysOn DDL- und Schemaänderungen