Schemaänderungen ohne Ausfall laufender Anwendungen

Eine Schemamigration kann erfolgreich sein, während die Anwendung ausfällt. Bei einer rollenden Einführung greifen alte und neue Prozesse gleichzeitig auf dieselbe Datenbank zu. Eine direkte Umbenennung oder ein sofort verpflichtendes neues Feld kann die noch aktive alte Version beschädigen. Entscheidend ist der Vertrag zwischen Anwendung und Daten, nicht nur ALTER TABLE.

Zuerst kompatibel erweitern

Eine sinnvolle Reihenfolge erweitert das Schema, führt Code für beide Formen ein, ergänzt historische Daten, prüft das Ergebnis und entfernt erst später den alten Vertrag. Eine nullable Spalte ist häufig ein geeigneter Anfang. Sie benötigt trotzdem Schemasperren; eine kleine Metadatenänderung garantiert keine blockierungsfreie Ausführung.

Das Beispiel verwendet eine kleine temporäre Tabelle. Führen Sie die Blöcke nacheinander aus. NOT NULL ist eine eigene Freigabestufe und sollte nicht automatisch unmittelbar auf das Hinzufügen folgen.

CREATE TABLE #Orders(OrderId int PRIMARY KEY, Amount decimal(12,2));
INSERT #Orders VALUES(1,10),(2,20);
ALTER TABLE #Orders ADD CurrencyCode char(3) NULL;

UPDATE #Orders SET CurrencyCode='USD' WHERE CurrencyCode IS NULL;
SELECT OrderId,Amount,CurrencyCode FROM #Orders ORDER BY OrderId;

IF EXISTS(SELECT 1 FROM #Orders WHERE CurrencyCode IS NULL)
    THROW 50000, 'Backfill is incomplete.', 1;
ALTER TABLE #Orders ALTER COLUMN CurrencyCode char(3) NOT NULL;

Legen Sie produktiv vor Abschluss der Nachbefüllung fest, wie neue Schreibvorgänge CurrencyCode setzen. USD gilt hier ausschließlich wegen der definierten Bedeutung der Übungsdaten. Ein bequemer Default ersetzt nicht die Ermittlung historischer Währungen. Unbekannte Werte benötigen Klärung, keine erfundenen Angaben.

Konkurrierende Änderungen beherrschen

Existieren alte und neue Felder nebeneinander, muss für jede Phase die maßgebliche Darstellung feststehen. Doppelte Schreibvorgänge müssen atomar sein oder abgeglichen werden. Sonst kann ein Fehler nur eine Darstellung ändern. Ein Fallback-Lesen kann Verfügbarkeit erhalten und gleichzeitig Abweichungen verbergen. Messen Sie solche Abweichungen vor der Leserumstellung ausdrücklich.

Bearbeiten Sie große Tabellen in wiederanlaufbaren Paketen mit stabilem Schlüsselbereich. Das Auswahlprädikat darf neuere Anwendungswerte nicht überschreiben. Bestätigen Sie Fortschritt und Änderungen gemeinsam, wenn der Fortschritt ausfallsicher sein muss. Eine Zeilengrenze begrenzt nicht automatisch gelesene Zeilen oder das Journalaufkommen von Triggern und Indizes.

Schemaänderungen können hinter langen Lesern oder Schreibern warten. Definieren Sie ein passendes Timeout und Wiederholungsverhalten, untersuchen Sie Blockierer und starten Sie nicht immer neue Migrationen, solange eine frühere wartet. Online-Optionen hängen von Operation, Version und Edition ab und bedeuten nicht vollständige Sperrfreiheit.

Rückkehr als Kompatibilitätsfrage prüfen

Vor dem Entfernen muss nachgewiesen sein, dass keine unterstützte Anwendungsversion, kein Bericht, Job, Export oder dynamischer SQL-Pfad das alte Feld benötigt. Katalogabhängigkeiten helfen, erkennen aber keine außerhalb der Datenbank erzeugten Zeichenfolgen vollständig. Ergänzen Sie Inventar durch Ausführungsdaten und gemischte Versionstests.

Ein Code-Rollback ist nur einfach, solange die Datenbank den alten Vertrag unterstützt. Enthalten neue Schreibvorgänge Werte, die die alte Darstellung nicht ausdrücken kann, geht bei einer Rückkehr möglicherweise Bedeutung verloren. Dokumentieren Sie die letzte reversible Stufe und einen datenerhaltenden Wiederherstellungsweg für spätere Phasen.

Prüfen Sie neben Zeilenanzahlen transformierte Werte, Constraints und typische Lese- und Schreibvorgänge beider Versionen. Unterbrechen Sie die Nachbefüllung absichtlich und testen Sie die Fortsetzung. Migrationskennungen und Abschlussstatus müssen bereits angewendete Schritte von fehlgeschlagenen unterscheiden.

Entfernen Sie die alte Form erst in einer eigenen Freigabe nach einer stabilen Beobachtungsphase. So bleibt für jeden Schritt klar, welche Version lesen und schreiben darf, welche Daten maßgeblich sind und welche Rückkehr noch ohne Informationsverlust möglich ist.

Technische Referenzen: Microsoft Learn: ALTER TABLE · Microsoft Learn: Dependency metadata.