Active-DataGuardbei Autoscout24: eine Lesefarm im … · mit Oracle 11.2.0.3 ... Aufruf einer PL/SQL-Procedureauf einer Active-Standby-Datenbank kann zu einer ... PL/SQL lock timer

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


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


Observer

K-Fall-Rechenzentrum

Primary-Rechenzentrum

ASYNC

ASYNCMaster-Datenbank K-Fall-Standby-Datenbank

BA1 BA2

Loadbalancer

LesenLesen / Schreiben

Active-DataGuard – LesefarmActive-DataGuard –Lesefarm

Loadbalancer



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



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



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



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


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


REDO-Transport – SYNC-Modus

Seite 14


REDO-Transport – ASYNC-Modus

Seite 15


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


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_SB05 - Physical standby databaseOSID_SB05 - Physical standby database





OSID_SK01 - Physical standby database

OSID_SK02 - Physical standby database



Fast-Start Failover: ENABLED

Configuration Status:

SUCCESS

Seite 18



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



… 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



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



Transport Lag: 0 seconds

Apply Lag: 1 second

Real Time Query: ON

DGMGRL> show database 'OSID_SB01' LogXptMode;LogXptMode = 'ASYNC'

Seite 21



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


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



DGMGRL> show configuration verbose;

Configuration - DG_AS24

Protection Mode: MaxPerformance

Databases:

OSID_MB - Primary database

OSID_SK - (*) Physical standby database



…

(*) Fast-Start Failover target

Properties:

FastStartFailoverThreshold = '900'

OperationTimeout = '30'OperationTimeout = '30'

FastStartFailoverLagLimit = '900'

CommunicationTimeout = '180'

FastStartFailoverAutoReinstate = 'TRUE'

FastStartFailoverPmyShutdown = 'TRUE'

BystandersFollowRoleChange = 'ALL‚


Threshold: 900 seconds

Target: OSID_SK

Observer: observer_host.domain

Lag Limit: 900 seconds

Shutdown Primary: TRUE

Auto-reinstate: TRUE

Seite 25



DGMGRL> show fast_start failover;


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



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



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



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


Initiating reinstatement for database "OSID_SB01"...

Reinstating database “OSID_SB01", please wait...

Reinstatement of database "OSID_SB01" succeededReinstatement of database "OSID_SB01" succeeded



Initiating reinstatement for database “OSID_SB02"...

Reinstating database "OSID_SB02", please wait...

Reinstatement of database "OSID_SB02" succeeded



Initiating reinstatement for database “OSID_SB03"...

Reinstating database "OSID_SB03", please wait...

Reinstatement of database "OSID_SB03" succeeded

Seite 29



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



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



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


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



● 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


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



● 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



● 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


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


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


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


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


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


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


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

[email protected]

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

[email protected]

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


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


Documents

Active-DataGuardbei Autoscout24: eine Lesefarm im … · mit Oracle 11.2.0.3 ... Aufruf einer PL/SQL-Procedureauf einer Active-Standby-Datenbank kann zu einer ... PL/SQL lock timer