Es gibt bestimmte Aufgaben zur Datenbankwartung, z. B. das Neuorganisieren von Indizes, das Verschieben von Dateien, das Ändern von Schemata usw., bei denen alle Anwendungen deaktiviert werden müssen, die die Datenbank verwenden.

Was sind einige gute Strategien, um dies zu umgehen, abgesehen davon, dass Sie lediglich eine Nachricht auf Ihrer Website veröffentlichen, z. B. "Wir sind von Mitternacht bis 4 Uhr EST wegen Serverwartung außer Betrieb"?

Wenn Sie über eine Replikations- / Hochverfügbarkeitslösung verfügen, ist die Verwendung dieser Lösung zur Vermeidung von Ausfallzeiten die naheliegende Wahl. Lassen Sie einen Server aktualisieren, während der andere funktioniert, und wechseln Sie dann den nächsten und aktualisieren Sie ihn.

Wenn Sie nicht über eine solche Struktur verfügen, können Sie ein Mini-Replikations-Setup auf demselben Server durchführen, auf dem Sie zwei Kopien jeder Datenbank haben und eine aktualisieren, während die andere funktioniert, und dann die alte wieder synchronisieren. Dies erfordert noch einige Ausfallzeiten, jedoch weniger als 4 Stunden.

Die dritte Möglichkeit, um zu vermeiden, dass beide Datenbanken synchron bleiben, besteht darin, eine Kopie der Datenbank zu erstellen. Während eine Datenbank verwaltet wird, befinden sich die Kopie und die Apps, die sie verwenden, im schreibgeschützten Modus. Nachdem Sie fertig sind, wechseln Sie einfach die Apps in die aktualisierte Datenbank und schreiben erneut in die Datenbank.

Diese letzte Option erfordert natürlich Anwendungsunterstützung und Sinn (es gibt Anwendungen, bei denen ein schreibgeschützter Modus keinen Sinn ergibt.)

Wenn Sie SQL Server verwenden, können Sie die Indexfragmentierung ab SQL Server 2000 immer online entfernen. Der Befehl DBCC INDEXDEFRAG führt immer eine Online-Reorganisation durch. Ich habe es speziell als Online-Alternative zu DBCC DBREINDEX geschrieben.

Ab SQL Server 2005 ersetzt der Befehl ALTER INDEX ... REORGANIZE DBCC INDEXDEFRAG und ist auch immer online. Ebenfalls ab 2005 können Sie mit Enterprise Edition die Online-Indexwiederherstellung mit ALTER INDEX ... REBUILD ... WITH (ONLINE = ON) durchführen. Zu Beginn und am Ende des Vorgangs sind einige sehr kurzfristige Tabellensperren erforderlich, daher ist es nicht so online wie REORGANIZE (und die Wiederherstellung von Online-Indizes ist meistens kein so guter Marketingbegriff :-). Sie können Indizes sogar in neue Dateigruppen verschieben, indem Sie CREATE INDEX ... WITH DROP_EXISTING verwenden und ONLINE = ON angeben.

Vielen Dank

Allgemeine Wartungsaufgaben

Die meisten Wartungsaufgaben können ausgeführt werden, ohne die Website oder App offline zu schalten, wenn Sie über eine Datenbankreplikation verfügen . Sie entfernen eine Datenbank aus dem Replikatsatz, wenden das an, was Sie benötigen, und verbinden sie erneut mit Ihrem Replikatsatz. Während es ausgeschaltet ist, halten andere DBs die Lösung am Laufen.

Datenbankschema ändern

Wenn Sie Ihr aktualisieren müssen Datenbankschema , werden Sie zu bringen Sie Ihre Lösung für einige Minuten gezwungen werden (oder zu einem Nur - Lese - Zustand) IF der Wechsel bricht die alte Version. Wenn Ihr neues Schema nur Tabellen oder Felder erstellt, hat dies keine Auswirkungen auf eine alte Version ^1. Daher kann diese Art der Schemaänderung online ² und mithilfe einer blau-grünen Bereitstellung für Ihre Anwendung durchgeführt werden, um eine hohe Verfügbarkeit zu erzielen.

Wenn Ihr neues Schema ein vorhandenes Feld umbenennt oder entfernt, um 100% der Verfügbarkeit zu erreichen, müssen Sie die folgenden Schritte ausführen:

Ein Feld umbenennen

1. Wenn Sie von A nach B umbenennen müssen, wenden Sie eine Schemaänderung an, die ein neues Feld B hinzufügt und A-Inhalte dupliziert. Halten Sie auch A intakt.
2. Stellen Sie eine neue Anwendung bereit, die das Feld B verwendet, und verwenden Sie das Feld A nicht.
3. Wenden Sie eine Schemaänderung an, mit der A entfernt wird.

Ein Feld entfernen

1. Wenden Sie keine Schemaänderung an.
2. Stellen Sie eine neue Anwendung bereit, die das zu entfernende Feld nicht verwendet.
3. Wenden Sie eine Schemaänderung an, mit der das Feld entfernt wird.

Hinweis 1 : Einige ORM-Tools, wie z. B. das .NET Entity Framework, ordnen jede Schemaänderung einer Migrations-ID zu. Wenn Sie also eine neue Schemaversion bereitstellen, werden alte Anwendungen sofort beschädigt. Es ist auch vermeidbar, wenn Sie diese Prüfung deaktivieren .

Hinweis 2 : Wenn Ihr neues Schema eine eindeutige Einschränkung, Prüfung oder einen Fremdschlüssel hinzufügt, benötigt der Befehl alter table möglicherweise einige Zeit, wenn Sie Tausende von Zeilen haben. Während die Änderungstabelle verarbeitet wird, wird die Tabelle auch für die Auswahl gesperrt. Dies kann zu Zeitüberschreitungen bei Abfragen führen, je nachdem, wie groß Ihre Daten sind.

Die verfügbaren Optionen hängen weitgehend davon ab, welches Datenbankmodul Sie verwenden. Sie sollten zunächst alle erforderlichen Maßnahmen ergreifen, um Online-Sicherungen Ihrer Datenbank zu aktivieren, und vorzugsweise Schreibvorgänge zulassen, während die Sicherung ausgeführt wird. Dies erfordert normalerweise eine lineare Protokollierung von Transaktionen, die Ihnen auch die Möglichkeit geben sollte, Ihre Datenbank zu einem bestimmten Zeitpunkt wiederherzustellen, indem Sie die Transaktionsprotokolle weiterleiten.

Tabellen- und Index-Reorgs können etwas kniffliger sein, aber hoffentlich erlaubt Ihr Datenbankmodul zumindest schreibgeschützten Zugriff auf die Objekte, während sie neu organisiert werden. Wenn nicht, müssen Sie möglicherweise eine Möglichkeit finden, wie Ihre Anwendungen vorübergehend einen schreibgeschützten Klon der Tabelle verwenden können. Wenn Ihr DBMS nur wenig Online-Wartung bietet, müssen Sie auf der Anwendungsebene Kompromisse eingehen, um es auf eine teilweise oder vollständige Kopie der Daten umzuleiten.

Unabhängig von den Kosten ist die Datenbankreplikation fast immer eine komplexe Funktion. Noch schlimmer ist die bidirektionale Replikation, die es Ihren Anwendungen theoretisch ermöglichen würde, Daten in der sekundären Datenbank zu ändern, selbst wenn die primäre Datenbank wegen Wartungsarbeiten nicht verfügbar ist. Eine Replikation ist nicht unmöglich, erfordert jedoch einiges an Planung und Test, um sich in der Produktion zuverlässig zu verhalten.