Problemstellung

Soll für eine Anwendung ein Patch/Upgrade installiert werden, so sollen in der Regel die Benutzer in dieser Zeit nicht auf die Anwendung zugreifen dürfen. Übernimmt die Datenbank die Autorisierung/Authentifizierung, so können die Accounts dazu gesperrt (locked) werden – was bei einer großen Anzahl von Nutzern mit Aufwand verbunden ist.

Ein SQL-Script zu schreiben, das alle Datenbankbenutzer sperrt, ist sicher kein Problem. Die „richtigen“ Benutzer dabei ausschließen (den installierenden User, SYS und SYSTEM) bzw. die richtige Benutzer-Auswahl (nicht alle Datenbankbenutzer arbeiten gegen das zu aktualisierende Datenbank-Schema), ist sicher auch kein Problem… es geht aber bequemer.

Sperrlisten helfen

quasiDBA implementiert zu diesem Zweck die Sperrlisten – eine benannte Liste von Datenbank-Benutzern, die einfach zu pflegen ist und jeweils in ihrer Gesamtheit gesperrt bzw. frei gegeben wird.

Die Sperrlisten und der Status der zugeordneten Accounts werden in der Übersicht angezeigt; im Dialog für die Sperrliste kann man sie bearbeiten sowie die Accounts aus dieser Liste (in ihrer Gesamtheit bzw. ausgewählte Accounts) sperren und entsperren.

Der Filter schränkt die Liste der aktiven Benutzer auf die Benutzer ein, welche mindestens ein Objektprivileg auf eine Tabelle des ausgewählten Anwendungsschemas haben.

Indem ein Account in die Liste der gesperrten Benutzer verschoben wird, wird der Account gesperrt und der Liste zugeordnet. Ein Account, der in der Liste gesperrt und einzeln wieder frei gegeben (unlock) wurde, bleibt der Liste zugeordnet.

Somit ist leicht möglich, alle Datenbank-Benutzer, die gegen ein Schema arbeiten, auszuwählen und zu sperren – nach dem Upgrade werden sie hier mit „Alle entsperren“ wieder frei gegeben; für das nächste Upgrade wird diese Liste einfach vernwendet und ggf. neue Benutzer hinzugefügt.

Teile diesen Artikel:
Tagged with →  

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *