Automatisierung des Datenbank-Betriebs (in einer sehr

Automatisierung des Datenbank-Betriebs
(in einer sehr großen Oracle-Umgebung)
Effizienzsteigerung durch den Einsatz von Skripten und Prozeduren
Robert Kruzynski
Trivadis GmbH München
DOAG NRW 05.06.2007
Einleitung
 In einer großen Oracle-Umgebung gibt es häufig wiederkehrende
Aufgaben
 Software-Installationen
 Server und Datenbankumzüge
 Versions- und Plattformwechsel
 Wiederherstellung und Klonen von Datenbanken
 DB-Reorgs
 Diese Aufgaben lassen sich automatisieren
 realisiert wird es meistens in einer Skript-Sprache
 sehr wichtig ist dabei die Standardisierung einer Umgebung
(Namenskonventionen,Hardware- und Software-Stand,Schnittstellen
zu anderen Betriebsgruppen)
 der Initialaufwand ist zwar hoch, rechnet sich ab einer bestimmten
Menge an Datenbanken
 Der Pflegeaufwand sollte nicht vernachlässigt werden. Je höher der
Automatisierungsgrad, desto höher der Pflegeaufwand.
© 2007
Erfahrungsbericht
 Bei einem Trivadis-Kunden in München fallen jährlich folgende
Tätigkeiten an
 >300 Oracle RDBMS Installationen
 >300 Oracle Client Installationen
 >400 neue Datenbanken
 >200 gelöschte Datenbanken
 >200 Oracle Relinks (verursacht durch Server-Patch-Aktionen)
 >50 Serverablösen
 >800 Datenbankumzüge (inkl. Plattformwechsel)
 >800 Upgrades
 >200 bestellte Datenbankklons
 >100 Recoveries
 >5000 Tablespace-Erweiterungen bzw. Verkleinerungen
© 2007
Software-Installationen
 Ausgangspunkt ist ein existierender Oracle-User mit ausreichend
großem HOME-Verzeichnis
 Prüfung der Systemvoraussetzungen
 Erstellung der Umgebung (inkl. Installation der Betriebsprozeduren)
 Silent-Installation vom NFS-Share inklusive des aktuellen Patch-Sets,
CPU-Patch, Single-Patches (opatch), changePerm.sh
 Relink
 Funktionsprüfung
 Eintrag ins Inventar
© 2007
Relinks der Oracle-Software
 ein Relink erscheint einfach, kann aber mühsam und zeitraubend werden
(bei mehreren Software Installationen/Server)
 bestimmte Oracle-Versionen/Plattformen müssen speziell behandelt
werden (z.B. OID-Installationen)
 zunächst wird alles notwendige heruntergefahren, Überwachung und
Cronjobs deaktiviert
 es wird geprüft, ob bestimmte Libraries nicht in Verwendung sind
 Relink wird gestartet
 File-Permissions werden angepasst und kontrolliert
 jedes ORACLE_HOME wird einzeln überprüft
 sind bestimmte Libraries bzw. Binaries neu erstellt worden?
 funktionieren: sqlplus '/ as sysdba', tnsping, remote-connect?
 Startup, Aktivierung von Cronjobs und Überwachung
© 2007
Erstellung neuer Datenbanken
 Skript basiert auf einer Template-Datei
 bereitet die Umgebung vor (auf allen Cluster-Knoten)
 berücksichtigt versionsspezifische Einstellungen (z.B. init.ora-Parameter)
 erstellt eigene Dictionary-Erweiterungen und zusätzliche Tablespaces
 installiert nach Bedarf Oracle Text bzw. Statspack
 CPU Patch (catcpu.sql)
 generiert einen bzw. mehrere OID-Einträge
 erstellt einen Inventar- und Monitoring-Eintrag
© 2007
Löschen von Datenbanken
 Löschen bestimmter Dateien und Verzeichnisse lokal und auf allen
Cluster-Knoten
 Löschen der Crontab- und oratab-Einträge
 Löschen der OID-Einträge
 Löschen aus der Inventar- und Überwachungsdatenbank
© 2007
Datenübernahme-Tool
 verwendet Export/Import
 parallelisiert bis auf Subpartitionsebene, parallele Streams werden
automatisch (nach Größe) zusammengestellt
 Export und Import können wahlweise gleichzeitig gestartet werden und
kommunizieren über eine Pipe (keine Dumpfile-Erstellung)
 wahlweise Ausschalten des Archivelog Modus
 Daten-Import ohne Constraints, Trigger und Indizes
 Parallele Index-Erstellung (Syntax-Generierung aus dem Indexfile)
 MAXPERFORMANCE Schalter
 workarea_size_policy=manual
 sort_area_size=2GB, create_bitmap_area_size=200MB
 log_buffer=200MB, Verdopplung der SGA und DBWR-Prozesse
 Sonderbehandlung der größten Segmente
 Indizes werden PARALLEL und mit NOLOGGING angelegt
 Primary und Foreign Keys mit ENABLE NOVALIDATE
© 2007
Datenübernahme-Tool
 Übernahme der Oracle-Text Präferenzen
 Dependent-Indizes (FBI, Oracle Text) werden am Ende erstellt
 wahlweise paralleler MView-Refresh (Indizes zuerst UNUSABLE)
 Übernahme von SYS-Grants
 Abschließender Struktur-Import
 Statistik-Übernahme mittels DBMS_STATS (EXPORT/IMPORT)
 anschließender Recompile
 gemessene Performance
 Siebel CRM 400GB ab 6h
 Bank 1TB ab 12h
 DWH 2TB ab 24h
© 2007
Datenbankumzug/Plattformwechsel
 erstellt die Datenbank bzw. löscht eine bereits vorhandene Datenbank
 passt folgendes an
 init.ora Parameter
 Tablespaces
 Redo Logs
 schätzt / prüft UNDO und TEMP Platzbedarf
 startet Datenübernahme
 arbeitet „schrittweise“
© 2007
Upgrade I
 der Versionswechsel von 9 auf 10 wird mittels catupgrd.sql durchgeführt
 vor catupgrd.sql wird folgendes geprüft bzw. generiert
 dba_registry, bestimmte init.ora Parameter, letztes Backup, NCHARSet, Filesystem-Platz
 alle DB-Links auf ihre Funktionstüchtigkeit
 create database link Syntax wird generiert (für event. Downgrade)
 ein Struktur-Export wird erzeugt
 SYS- und PUBLIC-grants werden abgespeichert
 dba_2pc_pending wird geprüft und aufgeräumt
 validate structure aller SYS-objekte
 dbms_stats.gather_dictionary_stats
 9i-Statspack Daten werden gesichert und gelöscht
 das spfile wird vorbereitet
 Cronjobs und Überwachung werden temporär ausschaltet
 die Umgebung wird auf 10g umgestellt (alle Cluster-Knoten)
© 2007
Upgrade II
 startup upgrade, create tablespace sysaux, catupgrd.sql
 nach catupgrd.sql wird folgendes durchgeführt:
 Recompile
 Anpassung von ca. 30 Parameter im spfile
 Erstellung und Zuweisung eines eigenen Profils (mit
failed_login_attempts unlimited)
 move/rebuild aller CTXSYS-Segmente nach SYSAUX
 ggf. Statspack-Installation
 Größen bestimmter Tablespaces werden auf 70%-Belegung eingestellt
 Cronjobs und Überwachung werden aktiviert
 Inventar wird aktualisiert
 Full Backup wird gestartet
 Der Downgrade-Fall ist übrigens auch automatisiert und wird bei
kritischen Datenbanken getestet
© 2007
Klonen von Datenbanken
 Vorbereitung der Klondatenbank
 lokal oder remote mittels ssh
 Erstellung der Datenbankumgebung bzw. Löschen einer vorhandenen
Datenbank
 Konfiguration eines statischen Listeners
 DUPLICATE DATABASE (optional Skip Tablespace)
© 2007
Recoveries
 folgende Recovery-Arten werden unterstützt:
 Target (full bzw. partial)
 Disaster (Originalserver nicht erreichbar)
 Switch Target to incremental updated copy
 Activate incremental updated copy as a clone
 bei Bedarf werden das Spfile und die Controlfiles wiederhergestellt
 Disaster-Recovery kann auf einem beliebigen Server mit ausreichend
großen Filesystemen und Tape-Zugriff durchgeführt werden. Es wird
kein Zugriff auf den Originalserver benötigt. Die Datenbankumgebung
wird bei Bedarf automatisch erzeugt.
© 2007
Fazit
 Bei entsprechend hohen Automatisierungsgrad lassen sich Datenbanken
sehr effizient betreiben
 Die Fehlerquote wird dabei noch reduziert, weil wiederkehrende
Aufgaben exakt gleich durchgeführt werden
 Automatisierung erfordert aber viel DBA- und Scripting-Erfahrung
 Der Teufel steckt bekanntlich im Detail...
© 2007
Vielen Dank!
?
www.trivadis.com
[email protected]