Das Problem Die Idee

Betrifft
Standby – Aber logisch!
Art der Info
Lösungskonzept (Januar 2003)
Autor
Martin Wunderli ([email protected])
Quelle
Beratungstätigkeit
Schlüsselworte
Data Guard, Logische Standby Datenbank
Das Problem
Ein Consulting Unternehmen mit mehreren Niederlassungen betreibt ein kleines
Rechenzentrum mit der zentralen IT Infrastruktur. Alle Applikationen sind Web-basiert, die
Auftragserfassung- und abwicklung sowie die Stundenerfassung der Consultants kann von
jeder Niederlassung oder aus dem Internet mit einfachsten Mitteln (Web Browser) erfolgen.
Auch das Controlling erfolgt auf diese Art, alle Auswertungen erfolgen über
Datenbankreports als PDF Dateien (Browser Plugin). Aufgrund dessen kann die
Leitungskapazität zwischen den Standorten gering gehalten werden.
Im Rahmen des Jahresabschlusses müssen nun sowohl die Bereichsleiter an den Standorten
als auch die Buchhaltung wiederholt eine grosse Menge an Reports erstellen. Während die
teilweise notwendigen Datenmodifikation sehr gering sind und problemlos zentralisiert
ablaufen können (Web Interface), belasten die Reports die Datenbank enorm. Eine Lösung,
welche die vorhandene Infrastruktur nicht überlastet ist gefragt.
Die Idee
Eine Ansatz wäre der Aufbau eines Real Application Clusters. Dies wird aber vor allem aus
Gründen der Hardware- und Softwarekosten verworfen. Zudem wäre es nicht sinnvoll, für
eine relativ beschränkte Zeitperiode grössere Investitionen zu tätigen.
Was gebraucht wird, ist ein zusätzliches Reporting System, das in die bestehende
Infrastruktur hineinpasst und dessen Hardware später, wenn die Reportlast nicht mehr so
hoch ist, ohne Abstriche für andere Zwecke verwendet werden kann. Zudem sollten die
Modifikationen auf der zentralen Datenbank möglichst zügig auf diesem Zusatzsystem zur
Vefügung stehen.
Oracle bietet mit der Standby/Data Guard Technologie eine Lösung in der gewünschten
Richtung. Eine 'normale' Standby Datenbank (eine sogenannte physische Standby
Datenbank) kann jedoch nur für Abfragen genutzt werden, wenn der Transfer und die
Applikation der Redo Logs (der Änderungen am Hauptsystem) gestoppt wird (open read
only). Seit Version 9.2 gibt es hier aber eine neue Variante: Die logische Standby
Datenbank.
Seite 1 von 5
Das Konzept
Eine logische Standby Datenbank wird nicht durch die direkte Applikation der Redo Log
Dateien aktualisert, sondern es werden die SQL Statements aus den archivierten Redo Logs
extrahiert und dann appliziert. Dadurch muss die Datenbank sich nicht in einem Recovery
Modus befinden (besser: Sie kann sich nicht in diesem Modus befinden) und neben der
Applikation der extrahierten SQL Statements können Reports ablaufen.
Man könnte nun meinen, dass die logische Standby Datenbank die ideale Variante wäre,
um eine Datenbank z.B. von einem HP/UX Server auf einen Linux Server zu spiegeln. Dies
geht aber nicht, da eine physische Standby Datenbank sich von einer logischen durch die
Log Apply Services, nicht aber durch die Log Transport Services unterscheidet.
Log Transport
Services
Log Apply
Services
LGWR
Primary
Standby
ARCH
Online
Redo Log
Archived
Redo Log
Recover
Standby
LogMiner
Archived
Redo Log
Das heisst, dass die auf der Standby Seite ankommenden Redo Logs mit der Architektur des
Standby Datenbankservers kompatibel sein müssen, damit der LogMiner die SQL
Statements extrahieren kann.
Die Implementation
Eine logische Standby Datenbank kann entweder durch den Data Guard Wizard oder aber
manuell aufgesetzt werden. Die Wizard Implementation ist problemlos mit wenigen
Mausklicks zu meistern, versteckt aber die technischen Grundlagen und lässt dem
Administrator nicht die gleichen Freiheiten wie der manuelle Setup.
Seite 2 von 5
Das manuelle Aufsetzen erfordert unter anderem eine Database Point in Time Recovery, ist
aber im Manual und in der Metalink Note 186150.1 gut beschrieben. Insbesondere werden
die einzelnen Voraussetzungen beim manuellen Setup sehr viel klarer als beim Wizard
gestützten. So zeigt sich in einem der Schritte, wie Oracle hier die zu verändernden Rows
identifiziert: Auf der Primary Datenbank muss die Menge der Redo Information pro Update
um vorhandene Primary Key oder Index Attribute Werte ergänzt werden:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE
INDEX) COLUMNS;
Umgekehrt bedeutet dies aber, dass Tabellen ohne Primary Key oder zumindest Unique
Index nicht auf eine logische Standby Datenbank dupliziert werden können. Auch Tabellen
mit LONG Attributen sind in einer logischen Standby Datenbank tabu.
Der Betrieb
Logische Standby Datenbanken können genauso wie ihre physischen Pendants mit dem
Data Guard Manager im OEM oder mit dem dgmgrl Kommandozeilen Interface betrieben
werden.
Seite 3 von 5
Switchovers (Vertausch der Rollen von Standby und Primary Datenbank) und Failovers
(Aktivieren der Standby Datenbank) sind daher einfach möglich:
baloo:wunderli:DB5 /home/wunderli> dgmgrl
DGMGRL for Linux: Version 9.2.0.1.0 - Production.
(c) Copyright 2002 Oracle Corporation. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/manager@DB5bagheera
Connected.
DGMGRL> switchover to bagheera_site
Performing switchover NOW. Please wait...
Switchover succeeded. New primary is "bagheera_site"
DGMGRL>
Updates auf den logischen Standby Datenbanken sind aber nicht möglich und enden in
einer Fehlermeldung:
SQL> connect scott/tiger
Connected.
SQL> update emp set ename=upper(ename);
update emp set ename=upper(ename)
*
ERROR at line 1:
ORA-01031: insufficient privileges
Der User SYS kann aber grundsätzlich alle Tabellen modifizieren und so logische Fehler
korrigieren/erzeugen ☺, was den Applikationsusern nicht möglich ist.
SQL> connect sys/manager as sysdba
Connected.
SQL> update scott.emp set ename=upper(ename) where ename='scott';
1 row updated.
SQL> commit;
Commit complete.
Sollten Tabellen auf der Primary Datenbank verändert werden, die nicht auf der Standby
Datenbank nachgeführt werden können, so steht für deren Behandlung ein GUI im Data
Guard Manager zur Verfügung. Je nach Fehler kann es aber kompliziert werden, die
Ursache dafür herauszufinden. Im folgenden Beispiel konnten nicht alle
Angestelltennamen auf Grossschreibung geändert werden, weil dies bei einem User schon
manuell durch SYS (illegal!) gemacht worden war:
Seite 4 von 5
Fazit
Falls Sie an weiteren Informationen zu Hochverfügbarkeit im Allgemeinen oder Standby
Datenbanken/Data Guard im Speziellen interessiert sind, empfehlen wir Ihnen unseren 3tägigen Kurs AI9-B-DBA oder spezialisertes Consulting. Wir sind auch gerne bereit, InHouse ein 1-tägiges Seminar zum Thema Oracle9i Release 2 Hochverfügbarkeit
durchzuführen.
Martin Wunderli
Trivadis AG
Dr. Martin Wunderli
Kanalstrasse 5
CH-8152 Glattbrugg
Seite 5 von 5
Mail:
Tel:
Fax:
Internet:
[email protected]
+41 1 808 70 20
+41 1 808 70 21
http://www.trivadis.com