Active Data Guard. Susanne Jahr. DOAG 2008 Jahreskonferenz Nürnberg im Dezember 2008

Transkript

1 DOAG 2008 Jahreskonferenz Nürnberg im Dezember 2008

2 Die Firma Herrmann & Lenz wurde 1995 gegründet und hat aktuell 13 Mitarbeiter. Firmensitz: Burscheid (bei Köln). Beratung, Schulung und Ferwartung für das Thema Oracle Datenbanken. Schwerpunktthemen: Hochverfügbarkeit, Tuning, Migrationen und Troubleshooting. Viele DOAG-Aktivitäten (Leitung der Regionalgruppe NRW, Vorträge für Regios, SIGs und Konferenzen). 2 / 24

3 Weitere Aktivitäten 3 / 24

4 Inhalt / 24

5 - was bisher existiert Konzept der Standby-Datenbank in Grundzügen schon seit langer Zeit Release 7.3: manueller Recovery Modus Release 8i: managed Recovery Modus (Read-Only Standby Database seit 8.1.5) Release 9i: Oracle Data Release 11: 5 / 24

6 Enterprise Edition (wie bei jedem Einsatz von Oracle Data ) Option zusätzlich zu lizenzieren! Physical (NICHT logical!) Standby Database 6 / 24

7 Wie wird Data bisher genutzt? Ausfallsicherheit für den Desaster-Fall Ausfall der Hardware auf der Primärseite Datenkorruption / Anwenderfehler (falls ein Delay eingestellt wurde) Möglichkeit des Read-Only-Zugriffs bei gleichzeitiger Aussetzung des Log Applys (z.b. für Reporting) während der Read-Only-Öffnung aufgelaufene Archive-Logs werden nach erneutem Start des Log Applys nachgefahren - jedoch nur, wenn die Standby-Datenbank zuvor wieder geschlossen und in den Mount-Status versetzt wurde! 7 / 24

8 Funktion bisher und mit ADG 8 / 24

9 Was geht jetzt mit? Das Zauberwort heißt Dies ermöglicht den Read-Only-Zugriff auf physikalische Standby-Datenbanken unter gleichzeitiger Fortsetzung des Log Applys Es gibt also keine Zeitverzögerung, wenn ein oder Failover während eines Read-Only-Zugriffs notwendig werden sollte Frage: welche Vorteile hat eigentlich die physikalische Standby-Datenbank - und welche die logische? 9 / 24

10 Physical vs. Logical Standby Vorzüge Logical Standby: 1 Lesezugriff ist ohnehin möglich, da für den Logical SQL Apply erforderlich 2 Strukturänderungen auf der Standby-Seite gegenüber der Primärseite in begrenztem Umfang möglich, etwa durch zusätzliche oder andere Indizes oder Views Vorzüge Physical Standby 1 Unterstützung aller Datentypen inklusive BFILE, VARRAYS, NESTED TABLES 2 Unterstützung von Multimedia-Datentypen wie SPATIAL und ORACLE TEXT 3 zusätzlich ab 11g mit : Read-Only Standby Datenbank bei gleichzeitigem Log Apply auch auf Physical Standby-Systemen! 10 / 24

11 LGWR: Kann -Informationen auf die Standby-Datenbank unabhängig vom nächsten Logswitch übertragen erfordert Standby logs ermöglicht Apply Übertragung synchron oder asynchron zum Transaktions-Commit einzige Möglichkeit für die synchrone Übertragung - asynchron zum Transaktions-Commit geht nicht mit dem Archiver! entlastet den LGWR durch Übernahme des Transports Voraussetzung für den Maximum Availability oder Maximum Protection Mode 11 / 24

12 Exkurs: Data Protection-Modi Maximum Performance Der Default-Modus. Transaktions-Commit, sobald erforderliche -Informationen ins Online-log geschrieben wurden. Schreiben in eine oder mehrere Standby-Datenbanken asynchron zum Commit Maximum Availability Transaktions-Commit, wenn alle erforderlichen -Informationen ins Online-log sowie in mindestens eine Standby-Datenbank geschrieben wurden. Ist keine Standby-Datenbank erreichbar, wird in den Maximum Performance-Modus umgeschaltet, bis das Problem behoben ist Maximum Protection "No Data Loss"-Lösung. -Informationen müssen vor einem Commit ins Online-log sowie in mindestens eine Standby-Datenbank geschrieben werden. Gelingt dies nicht, fährt die Primäre Datenbank herunter! 12 / 24

13 (1) Möglichkeit, auch bei Physical Standby-Datenbanken den Log Apply im Read-Only-Modus fortzusetzen Neue Oracle-Option... da ist doch sicher alles spektakulär anders???... zuerst nicht, später dann schon / 24

14 Data Konfiguration Primärseite db_name= ORA11G db_unique_name= MASTER fal_client= master fal_server= servant log_archive_config= dg_config=(master,servant) log_archive_dest_1= LOCATION=/opt/oracle/archive VALID_FOR=(all_logfiles,all_roles) db_unique_name=master log_archive_dest_2= SERVICE=SERVANT LGWR ASYNC VALID_FOR=(online_logfiles,primary_role) db_unique_name=servant Standby-Seite db_name= ORA11G db_unique_name= SERVANT fal_client= servant fal_server= master log_archive_config= dg_config=(master,servant) log_archive_dest_1= LOCATION=/opt/oracle/archive VALID_FOR=(all_logfiles,all_roles) db_unique_name=servant log_archive_dest_2= SERVICE=MASTER LGWR ASYNC VALID_FOR=(online_logfiles,primary_role) db_unique_name=master 14 / 24

15 (2) Alles beim Alten bei Installation und Konfiguration Keine zusätzlichen Parameter Betrieb wird ebenfalls wie gewohnt mit SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE [USING CURRENT LOGFILE] DISCONNECT FROM SESSION; aufgenommen 15 / 24

16 (3) nun öffnen wir unsere Standby-Datenbank Read-Only... alter database recover managed standby database cancel Tue Nov 11 21:45: MRP0: Background Media Recovery cancelled with status Completed: alter database recover managed standby database cancel alter database open... Physical standby database opened for read only access. Completed: alter database open... können aber JETZT den Apply fortsetzen: Tue Nov 11 21:46: alter database recover managed standby database using current logfile disconnect from session -- Connected User is Valid RFS[5]: Assigned to RFS process 8772 RFS[5]: Identified database type as physical standby RFS[6]: Successfully opened standby log 11: /opt/oracle/data/servant/servant/onlinelog/o1_mf_11_4fnmrfr0_.log Tue Nov 11 21:47: wenn das nicht spektakulär ist / 24

17 17 / 24

18 Nach dem Rollentausch Meistens enden Data -Beschreibungen und HowTo s mit dem Rollentausch, aber was passiert eigentlich mit den beim / Failover? Soll die neue Datenbank (meist ja in Verbindung mit einem neuen Host) automatisch genutzt werden? Soll es einen getrennten Eintrag in der tnsnames.ora für die Standby-Datenbank geben? Gibt es die Möglichkeit der zentralen Steuerung für alle bezüglich des genutzten Eintrags? Wird ein Directory-Service verwendet? 18 / 24

19 Client-Überlegungen manuelles Eingreifen ist sowohl bei einem als auch nach einem Failover wahrscheinlich ohnehin notwendig am einfachsten: zweiter Eintrag für das Standby-System in der tnsnames.ora der (oder einer zentralen) - nicht überall möglich! nach Rollentausch: zentral die auf einen neuen Eintrag in der tnsnames.ora umbiegen ebenfalls denkbar: die Adresse des Standby-Systems an zweiter Stelle in der Adressliste des Primärsystems Implementierung: Nutzung eines Client-Services durch Definition eines weiteren Service-Namens im init.ora-parameter service_names 19 / 24

20 Beispiel tnsnames.ora CLSRV.HL.DE = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = PRODHOST.HL.DE)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP) (HOST = STDBYHOST.HL.DE)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = CLSRV.HL.DE) (SERVER = DEDICATED) ) ) Im Beispiel würde immer zunächst der Primär-Host angesprochen, da an erster Stelle in der Adressliste genannt bei Ausfall der Primärseite würde dann der zweite Eintrag verwendet, also der Standby-Host 20 / 24

21 Beispiel Services Definition des entsprechenden service_names-parameters jeweils auf der Primärseite MASTER SQL> ALTER SYSTEM SET service_names= MASTER.HL.DE, CLSRV.HL.DE ; SERVANT (nach einem oder Failover) SQL> ALTER SYSTEM SET service_names= SERVANT.HL.DE, CLSRV.HL.DE ; Denkbar: Definition weiterer Services, die sich gezielt an den Standby-Host verbinden, um etwa Reporting-Funktionen auszuüben 21 / 24

22 Gibt es gar nichts zu kritisieren? Höchstens ein kleines bisschen - aber dafür kann der Data nichts... Verlagerung von Reporting-Aufgaben auf die Standby-Seite funktioniert nur, wenn die eingesetzte Reporting-Software sich auf SELECT-Statements beschränkt Diverse Reporting-Tools hinterlegen bei Erstellung eines Reports bestimmte User- und Sessioninformationen per DML in der Datenbank Dies bleibt auch mit weiterhin ausgeschlossen - es handelt sich immer noch um eine physikalische Standby-Datenbank! 22 / 24

23 Weitere Fragen? Hier gibt es nach der Konferenz auch unsere Vorträge in der aktuellsten Fassung zum Download! 23 / 24

24 Herrmann & Lenz weitere Vorträge bei der DOAG-Jahreskonferenz Dierk Lenz: Einfluss von Programmierschnittstellen auf Anwendungsperformance Montag 1.12., 14:00 Uhr, Tokio Wilhelm Breßer: Unsichere Bindevariablen Mittwoch 3.12., 14:00 Uhr, Neu Delhi Performance-Aspekte bei der Anwendungsprogrammierung für Oracle Datenbanken Schulungstag Donnerstag / 24