Nachricht

DBA*Robot - einfache Automatisierung der Einspielung von Oracle Datenbankskripts. Üblicherweise macht man das mit SQL*Plus. DBA*Robot ist für die Verarbeitung von Skripts optimiert und dafür viel besser geeignet. Eine Installation kann daher im Idealfall vollautomatisch ablaufen. Die DB-Maintenance in engen Wartungsfenstern ist stressig genug. DBA*Robot reduziert die Fehlerquellen und entlastet den DBA. Nutzen Sie diesen wichtigen Beitrag für die Stabilität und Sicherheit Ihrer Oracle Datenbank!

DBA*Robot ist in Java geschrieben und weitgehend plattformunabhängig. Vorausgesetzt wird eine Java Runtime ab Version 5.0 (1.5).

Die wichtigsten Vorzüge sind (siehe auch den entsprechenden Artikel im SOUG Newsletter) :

  • automatischer Login, keine Passworteingaben (ausser dem Masterpasswort) notwendig
  • kontrollierter Ablauf, automatische Filterung 'unkritischer Fehler'
  • automatisches Recompilieren allfällig invalid gewordener Datenbankobjekte
  • saubere Logausgabe
  • Unterstützung geschlossener Accounts
  • Unterstützung von Restricted Sessions
  • Schutz von Produktionsinstanzen
  • Verschlüsselung des Master Passwortes
  • Aufruf über die Kommandozeile oder ein einfaches GUI

Automatischer Login

Die Passworteingabe bei Schemawechseln ist einer der fehleranfälligsten und ärgerlichsten Punkte während dem Ablauf eines Skriptes. Das hartcodieren eines Passworts im Skript verbietet sich aus Sicherheitsgründen. Üblicherweise wird im Skript eine Variable eingebaut:

connect myAccount/&&myAccountPassword@db

Der DBA erhält zur Laufzeit einen Prompt und muss das Passwort eingeben. Zuerst einmal muss dem DBA jedes benötigte Passwort bekannt sein, dann darf er bei der Eingabe keine Fehler machen und schliesslich muss er während dem ganzen Ablauf zur Stelle sein und den Ablauf überwachen, denn es könnte ja noch eine weitere Eingabe notwendig sein.

DBA*Robot löst dieses Problem elegant. Steht der OCI Thick Driver zur Verfügung, so wird eine OCI Proxy Connection verwendet, die kein Passwort benötigt. Steht nur der Thin Driver zur Verfügung, wird das jeweilige Passwort kurz auf einen bekannten Wert geändert und dann wieder zurückgesetzt. Beide Mechanismen sind für den Benutzer völlig transparent.

Intelligente Fehlerbehandlung

Mit SQL*Plus ist es sehr schwierig, die unkritischen von den kritischen Fehlern zu unterscheiden, denn alles läuft unstruktiert über den Bildschirm. Man kann eigentlich nur wählen, ob Fehler generell ignoriert werden sollen, oder ob das Skript abbrechen soll. Viele Exceptions während dem Ablauf eines Skriptes sind aber völlig unkritisch, zumal wenn ein Skript wiederholt ausgeführt wird (was währdend dem Entwicklungs- und Testprozess hoffentlich einige Male der Fall ist).DBA*Robot erkennt unkritische Fehler (z.B. löschen eines Objektes, das nicht mehr existiert) automatisch, diese werden ignoriert. Bei kritischen Fehlern wird die Verarbeitung unverzüglich abgebrochen.

Automatisches Recompile

Bei Änderungen an Datenbank-Objekten können abhängige Prozeduren, Views oder Trigger invalid werden. DBA*Robot löst die Abhängigkeiten auf und führt alle notwendigen Recompilationen in der richtigen Reihenfolge aus. Allfällige Inkonsistenzen oder Codingfehler werden somit sofort ersichtlich. Ist ein Recompile auf gewissen Accounts nicht erwünscht, so können diese mittels des -i Switches oder einem Eintrag im Propertyfile ausgeblendet werden.

Geschlossene Accounts

In einer Produktionsdatenbank wird Schema-Accounts in der Regel aus sicherheitsgründen das 'CREATE SESSION'-Privileg entzogen. DBA*Robot vergibt das Privileg (falls notwendig und falls die entsprechende Option gewählt wurde) automatisch, wenn in einen Account eingeloggt werden muss.

Restricted Sessions

Damit während einer Migration keine Usersessions mit der Installation kollidieren können, wird die DB üblicherweise in den Restricted Session Mode gesetzt. DBA*Robot vergibt das in dieser Situation notwendige 'RESTRICTED SESSION' Privileg automatisch.

Schutz von Produktionsinstanzen

Im Propertyfile lassen sich Zuordnungen von Hosts und Db-Instanzen definieren, die einfach verhindern, dass z.B. von einem Entwicklungssystem versehentlich auf eine Produktionsinstanz zugegriffen werden kann. Z.B.:

instance.allow.hostdeva = devdba,devdbb,devdbc
instance.allow.hostdevb = devdba,devdbb,devdbc
instance.allow.hostprod = proddb

oder

instance.disallow.hostdeva = proddb
instance.disallow.hostdevb = proddb

oder

instance.allow.hostprod = proddb
instance.disallow.* = proddb

Verschlüsselung des Masterpasswortes

Optional lässt sich der Connectstring des Masteraccountes verschlüsselt im Propertyfile ablegen. Damit ist auch für den Masteraccount keine Passwortangabe mehr notwendig. Dies ist sinnvoll, wenn eine Installation vollautomatisch ablaufen soll, z.B. als Bestandteil einer Packageinstallation. In diesem Fall muss der Zugriff auf das Programm auf Betriebssystemebene eingeschränkt werden, um keine Sicherheitsloch entstehen zu lassen.