Eine umsichtige Maßnahme der Vorsperrplanung stellt sicher, dass eine SQL- oder MySQL-Datenbank nach der Konvertierung in den schreibgeschützten Status wie vorgesehen funktioniert und für die festgelegte Benutzergruppe zugänglich bleibt. Diese Voraussicht gewährleistet auch, dass die Datenbank sicher entsperrt werden kann, wenn in Zukunft Aktualisierungen oder Änderungen erforderlich sind.

Es hat einen gewissen Reiz, eine Datenbank schreibgeschützt zu machen, was bei Datenbankadministratoren gut ankommt. Es ist, als hätte die Datenbank ihre Reife erreicht und wäre bereit, sich in die Welt hinauszuwagen, ohne durch die Notwendigkeit ständiger Aktualisierungen belastet zu werden.

Natürlich sind die Gründe dafür, eine Datenbank vorübergehend oder dauerhaft auf schreibgeschützt zu setzen, so vielfältig wie die Datenbanken selbst. Hier finden Sie einen umfassenden Überblick über die Methoden zum Sperren des Inhalts einer SQL- oder MySQL-Datenbank, während Benutzern der Zugriff auf deren Inhalt ermöglicht wird.

Wie Atif Shehzad auf der Website „MSSQLTips“ scharfsinnig betont, ist es vor dem Sperren der Datenbank wichtig, sie zu optimieren, um Spitzenleistung sicherzustellen. Sie können beispielsweise weder Statistiken in einer schreibgeschützten Datenbank aktualisieren noch Indizes erstellen oder defragmentieren. Darüber hinaus können Sie den Objekten der Datenbank keine erweiterten Eigenschaften hinzufügen, ihre Berechtigungen bearbeiten oder Benutzer hinzufügen/entfernen.

Shehzad stellt ein sorgfältiges achtstufiges Pre-Lock-Skript zur Verfügung, das vor der Konvertierung einer Datenbank in den schreibgeschützten Zustand ausgeführt werden muss. Die Checkliste umfasst alles von der Erstellung einer Transaktionsprotokollsicherung bis hin zur Änderung von Berechtigungen und der Aktualisierung von Statistiken.

Eine achtstufige Checkliste vor der Sperrung stellt sicher, dass Ihre Datenbank optimiert und gesichert wird, bevor sie auf schreibgeschützt umgestellt wird. Quelle: MSSQLTips.

Sobald die Datenbank optimiert und gesichert ist, verwenden Sie entweder den Befehl „ALTER DATABASE [Datenbankname] SET READ_ONLY“ oder die gespeicherte Systemprozedur sp_dboption (ersteres wird empfohlen, da die gespeicherte Prozedur aus neueren Versionen von SQL Server entfernt wurde). Alternativ können Sie in SSMS mit der rechten Maustaste auf die Datenbank klicken, Eigenschaften > Optionen auswählen und den Status Datenbank schreibgeschützt auf True. Das Datenbanksymbol und der Name ändern sich in SSMS, um den schreibgeschützten Status anzuzeigen.

Eine MySQL-Datenbank in einen schreibgeschützten Zustand umwandeln – und den Prozess umkehren

Ein Hauptgrund für die Konfiguration einer MySQL-Datenbank als schreibgeschützt ist die Vermeidung von Datenverlusten während des Sicherungsvorgangs. Die MySQL-Dokumentationsbibliothek bietet umfassende Richtlinien für die Sicherung von Master- und Slave-Servern in einem Replikations-Setup, unter Verwendung einer globalen Lesesperre und der Manipulation der Systemvariablen read_only.

Quelle

Die Replikations-Setup-Richtlinien sehen einen Master-Server (M1), einen Slave-Server (S1) und Clients (C1 verbunden mit M1 und C2 verbunden mit S1) vor. Die Befehle, die den Übergang des Masters in einen Nur-Lese-Modus erleichtern und ihn nach Abschluss der Sicherung wieder in den Normalbetrieb versetzen, sind unten aufgeführt. (Beachten Sie, dass in bestimmten Versionen „ENABLED“ gleichbedeutend mit „1“ und „DISABLED“ gleichbedeutend mit „0“ ist.)

Die vorläufigen Befehle schalten die Datenbank auf schreibgeschützt um und die nachfolgenden Befehle stellen sie nach Abschluss der Sicherung wieder in ihren normalen Zustand zurück. Quelle: MySQL-Dokumentationsbibliothek.

Im schreibgeschützten Zustand kann die Datenbank abgefragt, aber nicht geändert werden. In einem Beitrag vom 23. August 2013 auf StackOverflow wird erklärt, wie man DML-Berechtigungen für bestimmte Benutzer widerruft und dann wieder einsetzt, eine Strategie, die sich weniger wahrscheinlich auf die Leistung der gesamten Datenbank auswirkt.