Martin Wunderli

Transkript

1 Betrifft Standby Aber logisch! Art der Info Lösungskonzept (Januar 2003) Autor Quelle Martin Wunderli 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 s (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

2 Das Konzept Eine logische Standby Datenbank wird nicht durch die direkte Applikation der Dateien aktualisert, sondern es werden die SQL Statements aus den archivierten s 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 Online ARCH Archived Standby Recover Standby Archived LogMiner Das heisst, dass die auf der Standby Seite ankommenden s 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

3 Das manuelle Aufsetzen erfordert unter anderem eine Database Point in Time Recovery, ist aber im Manual und in der Metalink Note 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

4 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 Production. (c) Copyright 2002 Oracle Corporation. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect sys/manager@db5bagheera 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 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 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

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 3- tägigen Kurs AI9-B-DBA oder spezialisertes Consulting. Wir sind auch gerne bereit, In- House ein 1-tägiges Seminar zum Thema Oracle9i Release 2 Hochverfügbarkeit durchzuführen. Martin Wunderli Trivadis AG Mail: martin.wunderli@trivadis.com Dr. Martin Wunderli Tel: Kanalstrasse 5 Fax: CH-8152 Glattbrugg Internet: Seite 5 von 5