Active-DataGuard bei Autoscout24: eine Lesefarmim Praxiseinsatz
www.autoscout24.de
DOAG Konferenz20. – 22.11.2012,Nürnberg
www.autoscout24.de
Inhaltsverzeichnis
1. Rückblick auf die alte Architektur
2. DataGuard-Architektur
3. REDO-Transport
4. DataGuard-Konfiguration
5. Fast Start Failover (Observer)
6. Technische Probleme während der Realisierung
7. Performance
8. Praxistipps8. Praxistipps
9. Fazit
Seite 2Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Rückblich auf die alte Architektur
MView Replications-Architektur
AIX HACMP Cluster
K-Fall-Rechenzentrum
Primary-Rechenzentrum
Passiver HACMP Node
BA1 BA2
Lesen / Schreiben
Virt. IPMaster-Datenbankim SAN
Activer HACMP Node
MVIEW-ReplicationMVIEW-Replication
Virt. IP
tnsnames.ora tnsnames.ora
Schreiben
Lesen
Seite 4Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
MView Replications-Architektur
Vorteile
● Schreibzugriff auf Replica-DBs
Unterschiedliche Indexstruktur
Einsatz von statspack, AWR, logon trigger
● Datenreduzierung auf den Replica-DBs
● Unterschiedliche Datenbankversionen der Replica-DBs
NachteileNachteile
● Hohe Komplexität aufgrund verschiedener Replikationen
(z.B. bei Änderung der Datenstruktur)
● Permanenter Delay bei der MView-Replikation
● Master DB nur einmal vorhanden (nur Schutz bei Hardwareausfall des Server)
Seite 5
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Architektur
DataGuard-Architektur
Observer
K-Fall-Rechenzentrum
Primary-Rechenzentrum
ASYNC
ASYNCMaster-Datenbank K-Fall-Standby-Datenbank
BA1 BA2
Loadbalancer
LesenLesen / Schreiben
Active-DataGuard – LesefarmActive-DataGuard –Lesefarm
Loadbalancer
Seite 7Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Architektur
Realisierte Lesefarm mit Active-DataGuard unter RedHat 5.7 64bit
mit Oracle 11.2.0.3
Katastrophenfall-Absicherung
● Master-Datenbank im BA1 Primary-Rechenzentrum
● K-Fall-Standby-Datenbank im K-Fall-Rechenzentrum
● Observer (virtuell) überwacht beide Datenbanken
● Observer kann zwischen BA1 und BA2 schwenken● Observer kann zwischen BA1 und BA2 schwenken
Master-Datenbank mit 12 Active-Standby-Datenbanken
● Standby-Datenbanken befinden sich aufgeteilt in
BA1, BA2 und K-Fall-Rechenzentrum
● Aufteilung der Active-Standby-Datenbanken in Loadbalancer-Pools
und nach Aufgaben
Seite 8
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Architektur
Client-Zugriffe erfolgen über Loadbalancer
● Der Loadbalancer steuert die Client- und Applikationszugriffe auf die
Master- und Active-Standby-DB
● Der Loadbalancer prüft den Status der Master- und K-Fall-Standby-DB
(Primary-Role)
● Keine sonst übliche Service-Trigger-Konfiguration in DataGuard notwendig
● Die Zugriffe auf die Loadbalancer-Pools der Active-Standby-DB erfolgen nach
Round-RobinRound-Robin
Seite 9
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Architektur
Vorteile:
● einfache Umgebung, alle Datenbanken haben den gleichen Datenstand und
die gleiche Datenstruktur, keine Sonderlösungen mehr
Softwareentwickler haben es einfacher, keine Unterscheidung mehr für
Replications- bzw. Master-Tabellen
einfacher Aufbau von Testumgebungen möglich
weniger Standby-Datenbanken gegenüber der alten Architektur
● Administrationsaufwand geringer● Administrationsaufwand geringer
● Standby-DBs nahezu synchron mit der Master-DB, trotz ASYNC-Transport-Mode
● automatischer Failover auf die K-Fall-Standby-DB bei Ausfall der Master-DB
Seite 10
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Architektur
Nachteile:
● spezielle Indizes können auf den Standby-DBs nicht mehr angelegt werden
daher viel mehr Indizes auf der Master-DB
● Autoscout24-Applikationen mussten aufwendig auf das neue Lesekonzept
angepasst werden
● Performance-Analysemöglichkeiten auf Standby-Datenbanken schwierig,
dazu später mehr
● Keine unterschiedlichen Datenbankversionen auf den Standby-Datenbanken● Keine unterschiedlichen Datenbankversionen auf den Standby-Datenbanken
möglich
Seite 11
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
REDO-Transport
REDO-Transport-Prozesse
Primary-DB
● LGWR LogWriter
● LNS Log Networker Server (pro Standby)
NSSn (SYNC)
NSAn (ASYNC)
Standby-DBStandby-DB
● RFS Remote File Server
● Redo-Apply-Prozesse
MRP0 Managed Standby Recovery Process
PRnn Slave Prozesse des MRP0 für paralleles Recovery
Seite 13
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
REDO-Transport – SYNC-Modus
Seite 14
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
REDO-Transport – ASYNC-Modus
Seite 15
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Konfiguration
DataGuard-Konfiguration – Protection-Modus
Protection-Modus
Gewichtung folgender Kriterien im Fehlerfall:
● Datenverlust
● Verfügbarkeit der Primary-DB
● Performance der Primary-DB
Maximum Performance
● Transportmodus: ASYNC
Datenverlust im Fehlerfall der Primary
Verfügbarkeit der Primary unabhängig von Standbys
Performance der Primary unabhängig von Standbys
Seite 17
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Konfiguration - Überblick
DGMGRL> show configuration;Configuration - DG_AS24
Protection Mode: MaxPerformance
Databases:
OSID_MB - Primary database
OSID_SK - (*) Physical standby database
OSID_SB01 - Physical standby database
OSID_SB02 - Physical standby database
OSID_SB03 - Physical standby database
OSID_SB04 - Physical standby database
OSID_SB05 - Physical standby databaseOSID_SB05 - Physical standby database
OSID_SB07 - Physical standby database
OSID_SB08 - Physical standby database
OSID_SB09 - Physical standby database
OSID_SB10 - Physical standby database
OSID_SK01 - Physical standby database
OSID_SK02 - Physical standby database
OSID_SB11 - Physical standby database
OSID_SB06 - Physical standby database
Fast-Start Failover: ENABLED
Configuration Status:
SUCCESS
Seite 18
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Konfiguration - Überblick
DGMGRL> show database verbose ' OSID_MB' ;…
Properties:
DGConnectIdentifier = ‚osid_mb'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '900'
LogArchiveMaxProcesses = '30'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = ''
…
Seite 19
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Konfiguration - Überblick
… show database verbose ' OSID_MB' ;
LogFileNameConvert = '/u02/oradata/OSID, /u02/oradat a/OSID,
/u04/oradata/OSID, /u04/oradata/OSID'
FastStartFailoverTarget = 'OSID_SK'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'OSID'SidName = 'OSID'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PR OTOCOL=tcp)(HOST=master_server.domain)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=OSID_MB_DGMGRL.domain)
(INSTANCE_NAME=OSID)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'OSID_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'
Seite 20
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Konfiguration - Überblick
DGMGRL> show database 'OSID_SK';Database - OSID_SK
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
DGMGRL> show database 'OSID_SK' LogXptMode;LogXptMode = 'ASYNC'
DGMGRL> show database 'OSID_SB01';Database - OSID_SB01
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 1 second
Real Time Query: ON
DGMGRL> show database 'OSID_SB01' LogXptMode;LogXptMode = 'ASYNC'
Seite 21
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
DataGuard-Konfiguration - Überblick
Active-DataGuard
Enterprise Edition Option (ab 11g).
OPEN READ ONLY einer physical Standby bei geichzeitigen Redo Apply.
SQL> select db_unique_name,open_mode from v$database;
DB_UNIQUE_NAME OPEN_MODE
------------------------------ -------------------------------------------------- --------------------
OSID_SB01 READ ONLY WITH APPLY
SQL> select process,status from v$managed_standby where process='MRP0';
PROCESS STATUS
--------- ------------
MRP0 APPLYING_LOG
Seite 22
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Fast Start Failover (Observer)
FSFO – Fast Start Failover
Fast Start Failover
● Konfiguration eines automatischen Failover im Fehlerfall der Primary-DB
● FSFO-Parameter regeln die Initiierung einer Failover
Voraussetzungen für FSFO
● Protection-Modus (11g): Max. Availability(SYNC), Max. Performance(ASYNC)
● DataGuard-Broker-Konfiguration
● Flashback Database für Primary und Target-DB● Flashback Database für Primary und Target-DB
● Installation des Observer
Wann wird ein automatischer Failover initiiert?
● kein Connect zwischen Primary und Observer (shutdown abort)
● bestehender Connect zwischen Observer und Target-DB
● kein Connect zwischen Primary-DB und Target-DB
Seite 24
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
FSFO – Fast Start Failover
DGMGRL> show configuration verbose;
Configuration - DG_AS24
Protection Mode: MaxPerformance
Databases:
OSID_MB - Primary database
OSID_SK - (*) Physical standby database
OSID_SB02 - Physical standby database
OSID_SB03 - Physical standby database
…
(*) Fast-Start Failover target
Properties:
FastStartFailoverThreshold = '900'
OperationTimeout = '30'OperationTimeout = '30'
FastStartFailoverLagLimit = '900'
CommunicationTimeout = '180'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL‚
Fast-Start Failover: ENABLED
Threshold: 900 seconds
Target: OSID_SK
Observer: observer_host.domain
Lag Limit: 900 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Seite 25
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
FSFO – Fast Start Failover
DGMGRL> show fast_start failover;
Fast-Start Failover: ENABLED
Threshold: 900 seconds
Target: OSID_SK
Observer: observer_host.domain
Lag Limit: 900 seconds
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle Error Conditions:
(none)
Seite 26
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
FSFO – Fast Start Failover
Setup FSFO AS24
● Installation ObserverOracle Client (Minimum) und tnsnames.ora (Primary und Target DB)
● Set FastStartFailoverTarget für Primary und Target DB:DGMGRL> EDIT DATABASE ‘OSID_MB' SET PROPERTY FastStartFailoverTarget = ‘OSID_SK';
DGMGRL> EDIT DATABASE ‘OSID_SK' SET PROPERTY FastStartFailoverTarget = ‘OSID_MB‘;
● Set FastStartFailoverThreshold, FastStartFailoverLagLimit:DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 900;
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit = 900;
● Enable Fast Start FailoverDGMGRL> ENABLE FAST_START FAILOVER;
● Start Observernohup dgmgrl -logfile /home/oracle/local_scripts/log/observer_OSID.log sys/<pwd>@OSID_MB "start
observer file=fsfo_OSID.dat" &
Seite 27
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
FSFO – Fast Start Failover
Failover Tests
Überprüfung folgender Komponenten während und nach dem Test:
● Logfiles (alert.log, drc.log, observer.log)
● DG-Status über Broker
● Connection Test über Loadbalancer
● Monitoring der DBs (PRTG)
Einige TestszenarienEinige Testszenarien
● Crash der Primary-DB (shutdown abort) / kill SMON Process der Primary-DB /
Abschalten des Primary DB Servers (ILO-IP: Power Off)
Automatischer Failover nach Ablauf von FastStartFailoverThreshold
Reinstatement der Active Standby-DBs, die weiter sind als neue Primary-DB
Reinstatement der Primary erfolgt erst nach deren startup
Seite 28
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
FSFO – Fast Start Failover
Auszug aus logfile von Observer:17:27:06.88 Wednesday, February 15, 2012
Initiating Fast-Start Failover to database “OSID_SK"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "OSID_SK"
17:29:38.55 Wednesday, February 15, 2012
17:30:49.91 Wednesday, February 15, 2012
Initiating reinstatement for database "OSID_SB01"...
Reinstating database “OSID_SB01", please wait...
Reinstatement of database "OSID_SB01" succeededReinstatement of database "OSID_SB01" succeeded
17:34:15.03 Wednesday, February 15, 2012
17:34:15.04 Wednesday, February 15, 2012
Initiating reinstatement for database “OSID_SB02"...
Reinstating database "OSID_SB02", please wait...
Reinstatement of database "OSID_SB02" succeeded
17:36:24.05 Wednesday, February 15, 2012
17:36:24.06 Wednesday, February 15, 2012
Initiating reinstatement for database “OSID_SB03"...
Reinstating database "OSID_SB03", please wait...
Reinstatement of database "OSID_SB03" succeeded
Seite 29
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
FSFO – Fast Start Failover
Einige Testszenarien …
Test FastStartFailoverLagLimit: Erzeugen eines Apply Lag auf der Target-DB
(tc qdisc add dev bond0 root netem delay 10000ms)
shutdown abort Primary-DB
kein automatischer Failover nach Überschreiten von FastStartFailoverLagLimit
DGMGRL> show database 'OSID_SK';
Database - OSID_SKDatabase - OSID_SK
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 33 minutes 53 seconds
Apply Lag: 33 minutes 53 seconds
Real Time Query: OFF
Instance(s):
OSID
Database Warning(s):
ORA-16829: fast-start failover configuration is lagging
Database Status:
WARNING
Seite 30
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
FSFO – Fast Start Failover
Einige Testszenarien …
Primary-DB Server: shutdown Interfaces bond0,bond1; ziehen der Netzwerkkabel
Automatischer Failover nach Überschreiten von FastStartFailoverThreshold
Shutdown der Primary-DB
alert.log Primary DB:
……
2012-02-09 15:44:59.170000 +01:00
Primary has heard from neither observer nor target standby within
FastStartFailoverThreshold seconds.
It is likely an automatic failover has already occurred. Primary is shutting down.
…
Seite 31
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Technische Probleme während der Realisierung
Technische Probleme während der Realisierung
● Switchover funktionierte mit mehr als einer Standby-Datenbank nicht
BUG 12829021: SWITCHOVER FAILS WITH ORA-1093,
Patch 12829021, gefixt in PSU-Patch ab 11.2.0.3.2
● Nach Switchover/Failover wurde vom DataGuard-Broker LOG_ARCHIVE_DEST_1
falsch gesetzt.
Die neue Primary-DB kann so keine Archivelogs schreiben
MOS ID: 1364467.1 Broker overrides local LOG_ARCHIVE_DEST_n destination on Bystander MOS ID: 1364467.1 Broker overrides local LOG_ARCHIVE_DEST_n destination on Bystander
Standby
Workaround: log_archive_dest_1 ohne den db_unique_name konfigurieren
● Switchover und Switchover zurück funktionierte nicht, wenn er zu schnell
augeführt wurde
BUG 13355993: SWITCHOVER HANGS USING DATA GUARD BROKER ON SWITCH BACK
_smu_debug_mode=134217728 (disable min active SCN optimization feature) setzen
Seite 33
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Technische Probleme während der Realisierung
● Wurde mit XDB/XML ein HTTP-Port konfiguriert und die K-Fall-Standby-Datenbank
„Read Only“ geöffnet, funktionierte der Switchover/Failover nicht
auch hier der BUG 12829021: SWITCHOVER FAILS WITH ORA-1093 verantwortlich
● Aufruf einer PL/SQL-Procedure auf einer Active-Standby-Datenbank kann zu einer
PLS-801–Exception führen
Abhilfe schaffte der Conflict - Patch 12378705
Empfehlung bei so einer komplexen DataGuard-Umgebung:
testen, testen, testen
immer den aktuellsten PSU-Patch einsetzen
Ab PSU-Patch 11.2.0.3.3 trotzdem noch folgender Workaround notwendig:
log_archive_dest_1 ohne den db_unique_name konfigurieren
Seite 34
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Performance
Performance – Commit-Schreib-Rate
Commit-Schreib-Rate
● Erhöhte Commit-Schreib-Rate (log file sync) auf der Master-Datenbank
Statspack – Report der Master-DB:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
----------------------------------------- ------------ ----------- ------ ------
log file sync 1,016,261 56,517 56 47.7
PL/SQL lock timer 669 40,249 60163 34.0
CPU time 9,067 7.7
log file parallel write 499,553 5,531 11 4.7
db file sequential read 177,742 1,615 9 1.4
-------------------------------------------------------------
Commit-Schreib-Rate auf Master-Datenbank
Durchschn. Wartezeit, trotz SAN, 56 ms
Warum?
Seite 36
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Performance – Commit-Schreib-Rate
● 13 LNS-Prozesse lesen aus dem Redo-Log-Buffer der Master-Datenbank,
die Redo-Blöcke müssen allerdings vom LGWR bereits ins Online-Redo-Log
geschrieben worden sein
● Allerdings, wenn die Redo-Blöcke nicht mehr im Redo-Log-Buffer vorhanden sind,
dann lesen die LNS-Prozesse aus dem Online-Redo-Log
Online-Redo-Loglog file sync
Lesen aus Online-Redo-Log
Lesen aus Redo-Buffer
ASYNC Transport
SGA
Redo-Buffer
LGWR
LSNLSN
LSNLSN
LSNLNS
LSNLSN
LSNLSN
LSNLNS LNS
13 LNS-Prozesse
Seite 37
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Performance – Commit-Schreib-Rate
● Aber, Logbuffer Hitratio der LNS - Prozesse fast immer ~ 100%
(Metalink View X$LOGBUF_READHIST and In-Memory Log Buffer Hit Rate
Histogram [ID 951152.1])● Dennoch, aufgrund des erhöhten I/O-Lesen der LNS-Prozesse aus dem Online-
Redo-Log verschlechtert sich die Commit-Schreib-Rate (log file sync) auf der
Master-Datenbank
Seite 38
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Performance - Analyse
Analyse der Standby-Datenbanken
● Statspack- und AWR-Reports nicht auf Read-Only-Datenbanken anwendbar
eigenes Standby-Statspack ab Oracle 11MOS: Installing and Using Standby Statspack in 11g [ID 454848.1]
Während der Installation auf der Master-Datenbank wird ein
Package-Name erstellt: STATSPACK_<db_unique_name>_<db_name> Package-Name darf max. 30 Zeichen haben, sonst ORA 972 Package-Name darf max. 30 Zeichen haben, sonst ORA 972
("identifier is too long“), daher db_unique_name nicht zu groß wählen
keine Analyse von SQL-Anweisungen mit dem Standby-Statspack möglichAnalyseskripte sbrepsql.sql und sbrsqins.sql fehlen in 11.2.0.3
siehe MOS: Bug 14107433 sbrepsql.sql and sbrsqins.sql not included in
11.2 installation
Fixed in der Version 11.2.0.4
● Index Monitoring auf Read-Only-Datenbanken nicht möglich
Seite 39
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Performance - Systemstatistiken
Systemstatistiken
● mit Systemstatistiken kann der Cost-Base Optimizer (CBO) auch CPU- und
I/O-Kosten bei der Berechnung der Ausführungspläne verwenden
● Systemstatistiken können mit DBMS_STATS.GATHER_SYSTEM_STATS nur
auf der Master-Datenbank erstellt werden
● Sollten Systemstatistiken in einer Active-Standby-Umgebung erstellt werden?
Ja, aber nur dann, wenn die Hardwareausstattung der Standby-Server mit
dem Master-Server nahezu identisch ist (Storage- und CPU-Ausstattung)
Seite 40
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Praxistipps
Praxistipps
● Konfigurieren Sie Standby-Redo-Logs (SRL) in Master- und Standby-Datenbanken
RFS-Prozess schreibt sequenziell in die Standby-Redo-Logs (SRLs)
SRLs immer eins mehr als Redo-Logs konfigurieren
Spiegelung der SRLs nicht notwendig
● Archive-Prozesse erhöhen
Archive-Prozesse sorgen für den Heardbeat der Datenbanken innerhalb
der DataGuard-Umgebungder DataGuard-Umgebung
Archive-Prozesse schließen Gaps
Archive-Prozesse mindestens auf die Anzahl aller Datenbanken + 1 erhöhen
dgmgrl> edit database ‘DB1’ set property ’LogArchiveMaxProcesses‘= 14;
● Für das Temp-Tablespace ist die Maxsize nur auf Master-Datenbank einstellbar,
evtl. aber höherer Bedarf auf den Standby-Lesedatenbanken
Seite 42
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Praxistipps
● Monitoren Sie die DataGuard-Umgebung, hier nur 4 wichtige Checks
Observer-Statusselect count(*) from v$database where FS_FAILOVER_OBSERVER_PRESENT='YES';
Status der Master- und K-Fall-Standby-Datenbank, niemals beide
Datenbanken 'PRIMARY‘Master-Datenbank:
select count(*) from v$database where database_role='PRIMARY‘;
Standby-Datenbank:Standby-Datenbank:
select count(*) from v$database where open_mode='MOUNTED‘;
Monitoring Apply-Lag select to_number(substr(substr(value,2),1,2)*86400+substr(substr(value,2),4,2)*3600+substr
(substr(value,2),7,2)*60+substr(substr(value,2),10,2)) as lag from v$dataguard_stats where
name='apply lag';
Flashback-Database aktivselect flashback_on from v$database;
Seite 43
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Praxistipps
● Weitere Empfehlungen zur Konfiguration von DataGuard, siehe
Oracle® Database High Availability Best Practices
11g Release 2 (11.2)
9 Configuring Oracle Data Guard
http://docs.oracle.com/cd/E11882_01/server.112/e10803/config_dg.htm
Seite 44
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Fazit
● Die Active-DataGuard-Umgebung läuft sehr stabil und performant.
● Im ASYNC-Transport-Mode sind die Standby-Datenbanken nahezu synchron mit
der Master-Datenbank.
● Der Observer setzt, nach einem automatischen Failover, alle Standby-
Datenbanken automatisch auf den richtigen Stand zurück, wenn notwendig.
● Administrationsaufwand erheblich geringer gegenüber der „alten“ Umgebung
● Alle Datenbanken haben den gleichen Datenstand, es gibt keine
Sonderlösungen mehr
Entwicklungs- und Planungsaufwand geringer
der Aufbau von Testumgebungen ist nun viel einfacher
● Die Migration auf die neue DataGuard-Umgebung hat sich gelohnt!
Seite 45
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
www.autoscout24.de
Vielen Dank für Ihre Aufmerksamkeit!
Kontakt:AutoScout24 GmbH
Dingolfinger Straße 1-15
81673 München
Sabine Langer
Tel.: 089 444 56-1632
Kontakt: Michael Skowasch
www.autoscout24.de
Kontakt:ORDIX AG
Westernmauer 12-16
33098 Paderborn
Michael Skowasch
Tel.: 05251 1063-0
Fax : 0180 1 67349 0
Anhang – Load Profil Master DB
Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- --- -- ------- ------------
ServerName Linux x86 64-bit 16 16 2 126.0
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 35,200M Std Block Siz e: 8K
Shared Pool: 3,584M Log Buffer : 74,368K
Load Profile Per Second Per Transac tion Per Exec Per Call
~~~~~~~~~~~~ ------------------ --------------- -- ----------- -----------
DB time(s): 5.1 0.1 0.00 0.00
DB CPU(s): 1.0 0.0 0.00 0.00
Redo size: 511,375.8 9,229.3
Logical reads: 45,107.6 814. 1
Block changes: 3,710.9 67. 0
Physical reads: 924.3 16 .7
Physical writes: 396.0 7.2
User calls: 2,505.0 45.2
Parses: 41.4 0.8
Hard parses: 2.9 0.1
W/A MB processed: 4.5 0.1
Logons: 1.9 0.0
Executes: 1,489.3 26.9
Rollbacks: 0.0 0.0
Transactions: 55.4
Seite 47
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch
Anhang – Load Profil Active Standby DB
Host Name: ServerName Num CPUs: 4 Phys Memory (MB): 24,106
~~~~
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 13,248M Std Block Siz e: 8K
Shared Pool: 1,088M Log Buffer : 27,976K
Load Profile Total Per Se cond
~~~~~~~~~~~~ ------------------ -------------- ---
DB time(s): 7,587.2 2.1
DB CPU(s): 1,872.2 0.5
Redo MB applied: 869.4 0.2
Logical reads: 151,033,739.0 41,618. 6
Physical reads: 7,770,537.0 2,141 .2
Physical writes: 481,910.0 13 2.8
User calls: 6,490,563.0 1,788.5
Parses: 20,702.0 5.7
Hard parses: 5,881.0 1.6
W/A MB processed: 12,220.6 3.4
Logons: 680.0 0.2
Executes: 3,160,116.0 870.8
Rollbacks: 0.0 0.0
Seite 48
Active-DataGuard bei Autoscout24 | Sabine Langer, Michael Skowasch