Mike Dietrich BU Database Technologies

,QVHUW3LFWXUH+HUH! 2UDFOH'DWDJXDUGJ Mike Dietrich BU Database Technologies

$JHQGD Oracle DataGuard Kurzüberblick Snapshot Standby Standby aufbauen mit RMAN Active Dataguard Rolling Upgrades mit Transient Logical Standby Vermischtes

2UDFOH 'DWD*XDUG 5HGR7UDQVSRUW 7UDQVDFWLRQV 3URGXFWLRQ 6WDQGE\ /*:5 /16 /*:56<1& 5)6 3URGXFWLRQ 'DWDEDVH 2QOLQH 5HGR /RJV /*:5$6<1& /16 5)6 6WDQGE\ 5HGR /RJV *DS5HVROXWLRQ $5&+ $5&+ 5)6 $UFKLYHG 5HGR/RJV $UFKLYHG 5HGR/RJV

2UDFOH 'DWD*XDUG $SSO\6HUYLFHV 6WDQGE\ Redo Data From Site A 5)6 6WDQGE\ 5HGR/RJV $5&+ Physical (Redo Apply) $SSO\ Logical (SQL Apply) Standby Database $UFKLYHG 5HGR/RJV

2UDFOH'DWD*XDUGhEHUEOLFN 3 Möglichkeiten zur Administration Pures SQL DataGuard Broker und DGMGRL DataGuard Broker und EM GridControl $NWXHOOQXU'*)XQNWLRQDOLWlW JUDILVFKPLWGHP*&QXW]EDU

2UDFOH'DWD*XDUGhEHUEOLFN Dokumentation

6QDSVKRW6WDQGE\ Was sagt die Dokumentation? 6QDSVKRW6WDQGE\'DWDEDVH A VQDSVKRWVWDQGE\ database is DIXOO\XSGDWDEOHVWDQGE\GDWDEDVH that is created by FRQYHUWLQJDSK\VLFDOVWDQGE\GDWDEDVH into a snapshot standby database. Like a physical or logical standby database, a snapshot standby database receives and archives redo data from a primary database. Unlike a physical or logical standby database, DVQDSVKRWVWDQGE\GDWDEDVHGRHVQRWDSSO\WKHUHGRGDWD that it receives. The redo data received by a snapshot standby database is not applied until the snapshot standby is converted back into a physical standby database, after first discarding any local updates made to the snapshot standby database. A snapshot standby database is best used in scenarios that require a updatable snapshot of a physical standby database. Note that because received by a snapshot standby database is not applied until it is converted into a physical standby, the time needed to perform a role transition proportional to the amount of redo data that needs to be applied.

6QDSVKRW6WDQGE\ Physical Standby Read/Write öffnen, Testen, Daten ändern - und danach einfach auf Knopfdruck wieder zurückstellen und synchronisieren Einsatz: Testdatenbank, Entwicklungssystem 8SGDWHV 3ULPDU\ 'DWDEDVH

6QDSVKRW6WDQGE\ Physical Standby als Snapshot Standby: $/7(5'$7$%$6( &219(577261$36+2767$1'%< Redo-Transport läuft weiter Alternativ im DGMGRL: '*0*5/!&219(57'$7$%6(VWE\7261$36+2767$1'%< Wichtige Anmerkung: Man muss mit User/Pw@connect auf der Primary-DB eingeloggt sein Wieder zurück: $/7(5'$7$%$6( &219(57723+<6,&$/67$1'%< Alternativ im DGMGRL: '*0*5/!&219(57'$7$%6(VWE\723+<6,&$/67$1'%<

6QDSVKRW6WDQGE\ Anmerkungen: Weniger Schritte notwendig, als in 10gR2 Der Redo-Transport läuft im Hintergrund weiter =HUR'DWD/RVV möglich!!! Nach dem Rückkonvertieren in eine Physical Standby werden die aufgelaufenen Logdateien nachgefahren Im Standby-RAC darf nur eine Instanz gestartet sein Funktioniert nicht, wenn: Nur eine Standby vorhanden ist und Max-Protection-Mode eingestellt wurde Wenn die Standby das Ziel bei Fast-Start-Failover ist

6WDQGE\DXIEDXHQPLW50$1 "Duplicate Standby" nun auch über ein Netzwerk und ohne vorheriges Backup möglich RMAN-Klausel: FROM ACTIVE DATABASE Oracle-Net muss vorab konfiguriert werden SPFILE kann angepasst werden Auch im EM über "Clone Database" machbar (?!?) Wer hat Angst vor RMAN??

6WDQGE\DXIEDXHQPLW50$1 Ohne Backup eine Standby aufbauen Vorgehen: 1. Datenbank im Archivelogmode? 2. Standby-Redologs anlegen 3. Force Logging einschalten 4. Listener/TNS-Konfiguration vornehmen Listener muss Kenntnis von der zu erzeugenden Zieldatenbank haben 5. Password-File mit orapw(d) anlegen 6. Zieldatenbank in den NOMOUNT-Status fahren Keine init.ora notwendig!!!

6WDQGE\DXIEDXHQPLW50$1 Ohne Backup eine Standby aufbauen 7. RMAN-Skript ablaufen lassen: UXQ^ '83/,&$7(7$5*(7'$7$%$6( )2567$1'%< )520$&7,9('$7$%$6( '25(&29(5 63),/( 3$5$0(7(5B9$/8(B&219(57XVWE\ 6(7'%B81,48(B1$0( 67%< 6(76*$B7$5*(7 0 6(7/2*B),/(B1$0(B&219(57 6(7'%B),/(B1$0(B&219(57 XVWE\ XVWE\ 12),/(1$0(&+(&. `

6WDQGE\DXIEDXHQPLW50$1 Ohne Backup eine Standby aufbauen 8. Dataguard konfigurieren Entweder manuell eintragen: FAL_SERVER, FAL_CLIENT, DG_CONFIG LOG_ARCHIVE_DEST_n STANDBY_FILE_MANAGEMENT Oder besser: Mit DGMGRL konfigurieren lassen SPFILE ist Vorraussetzung '*B%52.(5B67$57 übernehmen 758( ins SPFILE

6WDQGE\DXIEDXHQPLW50$1 '*0*5/ Konfiguration a. &5($7(&21),*85$7,21'*B(19 $635,0$5<'$7$%$6(,6RUFO &211(&7,'(17,),(5,6RUFO b. c. $'''$7$%$6(VWE\$6&211(&7,'(17,),(5,6VWE\ (',7'$7$%$6(VWE\6(73523(57< 6WDQGE\$UFKLYH/RFDWLRQ DUFKIVDUFK (',7'$7$%$6(VWE\6(73523(57< 6WDQGE\)LOH0DQDJHPHQW $872 d. (1$%/(&21),*85$7,21 e. Bei Problemen: 6+2:'$7$%$6(VWE\,QFRQVLVWHQW3URSHUWLHV

6WDQGE\DXIEDXHQPLW50$1 Fazit: Eine Standby ohne vorheriges Backup direkt aufbauen zu lassen, ist wirklich smart Deutliche Verfahrensvereinfachung, falls keine Grid Control im Einsatz ist Zeitersparnis bei grossen Datenbanken

$FWLYH'DWDJXDUG 9RU 11J: Physical Standby Read-Only öffnen und Abfragen ausführen Währenddessen werden Redologs zwar transportiert, nicht aber angewendet Daraus resultieren beim Failover/Switchover längere Umschaltzeiten + Standby gibt "veraltete" Daten zurück

$FWLYH'DWDJXDUG $E11g: Physical Standby Read-Only öffnen und Abfragen ausführen Währenddessen werden Redologs transportiert und sofort angewendet Alle Datentypen werden unterstützt Konsitente Leseergebnisse

$FWLYH'DWDJXDUG Vorgehensweise: 1. $/7(5'$7$%$6( 5(&29(50$1$*('67$1'%<'$7$%$6(&$1&(/ 2. 3. $/7(5'$7$%$6(23(1 $/7(5'$7$%$6( Wieder zurück: 1. 2. 5(&29(50$1$*('67$1'%<'$7$%$6( 86,1*&855(17/2*),/(',6&211(&7 $/7(5'$7$%$6(&/26(RGHU5HVWDUW $/7(5'$7$%$6( 5(&29(50$1$*('67$1'%<'$7$%$6( 86,1*&855(17/2*),/(',6&211(&7

/HVH)DUPHQPLW$FWLYH'DWDJXDUG Praktisches Anwendungsszenario: Auktionsplattform /HVH'%V 8SGDWHV 5HGR6KLSSLQJ 3ULPlU 'DWHQEDQN 6WDQGE\'DWHQEDQN /HVH'% XQG )DVW6WDUW )DLORYHU7DUJHW

/HVH)DUPHQPLW$FWLYH'DWDJXDUG Nach einem Failover/Switchover: /HVH'%V 8SGDWHV 5HGR6KLSSLQJ 1HXH6WDQGE\'% /HVH'% XQG 1HXH3ULPlU 'DWHQEDQN )DLORYHU 7DUJHW

$FWLYH'DWDJXDUG Ist das nun das Ende von Logical Standby? "

$FWLYH'DWDJXDUG Fazit: "Killer"-Feature Das Argument, eine Standby stehe ja nur nutzlos für den )DOOGHU)lOOH in der Ecke rum, gehört damit endgültig der Vergangenheit an

5ROOLQJ8SJUDGHV Rolling Upgrades ab 10.1.0.3 Logical Standby Datenbank notwendig

5ROOLQJ8SJUDGHV Transient Logical Standby bedeutet: 1. Existierende Physical Standby Datenbank 2. Umwandlung in eine Logical Standby 3. Upgrade/Patching der Logical Standby 4. Rollentausch - Standby wird zur Produktions-DB 5. Zurücksetzen der ehemaligen Produktions-DB auf einen garantierten Restore Point 6. Einspielen eines Physical Standby Controlfiles Damit wird die ehemalige Produktions-DB zur Physical Standby 7. Starten in der neuen SW-Umgebung 8. Nachfahren der Loginformationen 9. Kontrollierter Rollentausch zurück

5ROOLQJ8SJUDGHV Vorbereitung auf PROD: Flashback einschalten bzw. Datenbank mounten und dann:!&5($7(5(6725(32,17 SUHBXSJUDGH *8$5$17(( )/$6+%$&.'$7$%$6( Physical Standby Controlfile anlegen:!$/7(5'$7$%$6(&5($7(3+<6,&$/67$1'%< &21752/),/( $6WPSFWOSK\V5(86( LOG_ARCHIVE_DEST_3 definieren.

5ROOLQJ8SJUDGHV Vorbereitung: Logminer Dictionary auf PROD aufbauen:!(;(&87('%06b/2*67'%<%8,/' Physical Standby in eine Logical Standby konvertieren:!$/7(5'$7$%$6(5(&29(572/2*,&$/67$1'%<.((3,'(17,7< Die Logical Standby behält damit denselben DB_NAMEn und dieselbe DBID wie die Primärdatenbank. Nur eine Rolling-Switchover-Operation ist möglich. Remote Archivelogs werden nicht gelöscht Logical Standby öffnen und Logapply einschalten:!$/7(5'$7$%$6(23(1!$/7(5'$7$%$6(67$57 /2*,&$/67$1'%<$33/<,00(',$7(

5ROOLQJ8SJUDGHV Upgrade:!$/7(5'$7$%$6(6723/2*,&$/67$1'%<$33/<; Upgrade der Logical Standby Seite Zwischenstand:!$/7(5'$7$%$6(67$57/2*,&$/67$1'%<$33/<,00(',$7(; PROD (A) ist noch Produktions-System LOGI (B) ist Logical Standby - aber bereits upgegraded

5ROOLQJ8SJUDGHV Switchover/Rollentausch: Einphasige Switchover-Operation durchführen:!$/7(5'$7$%$6(&200,7726:,7&+29(5 72/2*,&$/67$1'%<>DXI$ @ 3URG!$/7(5'$7$%$6(&200,7726:,7&+29(5 72/2*,&$/35,0$5<>DXI% @ /RJLFDO Zwischenstand: PROD (A) ist nun eine Logical Standby LOGI (B) ist nun Produktionssystem

5ROOLQJ8SJUDGHV Rücktransformation: Zuerst wird die Logical Standby (A - PROD) zurückgesetzt:!6+87'2:1,00(',$7(!67$578302817!)/$6+%$&.'$7$%6(725(6725(32,17suhbxsjudgh Anschliessend wird die Logical Standby (A - PROD) zu einer Physical Standby "rückkonvertiert": 64/!6+87'2:1,00(',$7( 50$1!67$57831202817 50$1!5(6725(&21752/),/()520 WPSFWOSK\ 50$1!6+87'2:1 Und schliesslich in-synch gebracht - als Physical Standby:!6+87'2:1,00(',$7(!5(&29(50$1$*('67$1'%<'$7$%$6( 86,1*&855(17/2*),/(',6&211(&7

5ROOLQJ8SJUDGHV Finaler Switchover: Auf B (LOGI - aktuelles Produktions-System):!6(/(&76:,7&+29(5B67$786)5209'$7$%$6( 5HVXOWDW 7267$1'%<"""'DQQ!$/7(5'$7$%$6(&200,7726:,7&+29(5723+<6,&$/67$1'%< :,7+6(66,216+87'2:1!6+87'2:1,00(',$7(!67$578302817 Auf A (PROD - aktuelle Physical Standby):!6(/(&76:,7&+29(5B67$786)5209'$7$%$6( 5HVXOWDW 7235,0$5<"""'DQQ!$/7(5'$7$%$6(&200,7726:,7&+29(57235,0$5<!6+87'2:1,00(',$7(!67$578302817

5ROOLQJ8SJUDGHV Fussnote: Rolling Upgrade nur auf zwei unabhängigen Maschinen durchführbar: Der Dataguard-Broker muss abgestellt werden Während der Konvertierung und des Upgrades der Logical Standby gelten die üblichen Restriktionen (Datentypen!!!)

5ROOLQJ8SJUDGHV Fazit: Ein sehr schneller Weg für ein Rolling Upgrade Downtime < 1min durchaus erreichbar Bei hardware-identischen Systemen aber sehr verlockend, da evtl. nur ein einziger Switchover (also nur 1x Downtime) notwendig ist

$JHQGD Oracle DataGuard Kurzüberblick Snapshot Standby Standby aufbauen mit RMAN Real-Time-Query Rolling Upgrades mit Transient Logical Standby Vermischtes

9HUPLVFKWHV Security: Redo-Übertragung kann - bei Verwendung von OID und ASO - auch ohne SYS-Authentifizierung erfolgen (SSL) Ein nicht-sys-user kann für die Redo-Übertragung genutzt werden: init-parameter: UHGRBWUDQVSRUWBXVHU User muss SYSOPER Privileg haben User/Password muss gleich über alle DBs der Konfiguration sein

9HUPLVFKWHV Logical Standby: XMLType data type (CLOB) Transparent Data Encryption (TDE) DBMS_FGA (Fine Grained Auditing) DBMS_RLS (Virtual Private Database) Rollen-spezifische DBMS_SCHEDULER Jobs (PRIMARY, LOGICAL STANDBY, BOTH) Dynamisch veränderbare SQL Apply Parameter Parallel DDL Ausführung auf der Standby-Datenbank Schnelleres SQL Apply Interne Optimierungen

9HUPLVFKWHV Fast Start Failover: Nun auch LGWR ASYNC erlaubt (MaxPerformance) User-defined Failover-Kriterien Broker Agent /*:5$6<1& Broker Agent Data Guard Broker

9HUPLVFKWHV Redo Transport: Redo Compression /2*B$5&+,9(B'(67B 6(59,&( VWE\6<1&&2035(66,21 (1$%/( YDUFKLYHBGHVW - Spalte: COMPRESSION=ENABLE DISABLE Optimierter ASYNC-Transport im MaxPerformanceMode

9HUPLVFKWHV RMAN und Dataguard Block Change Tracking nun auch auf der Physical Standby zuschaltbar für )DVW,QFUHPHQWDO%DFNXSV Archive Log Deletion Policy Nun auch "Shipped" konfigurierbar "Applied On Standby" gilt nun für alle Destinations Transparentes Backup, Restore & Recovery mit allen Datenbanken in der Konfiguration

9HUPLVFKWHV Heterogene Dataguard-Umgebung möglich: Windows + Linux Grid Control Logminer Interface Fehlertoleranter Observer Automatische Propagierung von Jobs nach einem Switchover/Failover Standby aus einem vorherigen RMAN Backup anlegen lassen

9HUPLVFKWHV White Paper: KWWSZZZRUDFOHFRPWHFKQRORJ\GHSOR\DYDLODELOLW\SGI WZSBGDWDJXDUGBJUSGI

)D]LW Oracle Dataguard 11J ist: