Data Guard Standby Redolog Apply

1. Data Guard Standby Redolog
Apply
Planboard Oracle DBA Symposium 2009
Rick van Ek

2. Wie ben ik?
 Rick van Ek
 rick.v.ek@xs4all.nl
 Van Ek IT Consultancy BV
 Werkt met Oracle producten sinds 1992
 Zelfstandig sinds 1996
 Oracle database
 Baan IV software

3. Waar gaan we het over hebben?
Korte introductie standby databases
Inleiding van de praktijk casus
Consequenties voor upload redolog apply
Demo archivelog transport
Wat meten we waar

4. Introductie physical standby
Definition Physical Standby Databases
A physical standby database is an exact, block-
for-block copy of a primary database. A physical
standby is maintained as an exact copy through a
process called Redo Apply, in which redo data
received from a primary database is continuously
applied to a physical standby database using the
database recovery mechanisms.

5. Introductie physical standby

6. log_archive_dest parameter
 Affirm / noaffirm – bevestiging voor of na het
schrijven van standby redolog
 Compression – vereist oracle advanced
compression option
 Max-connections – maakt meerdere network
connections mogelijk
 Arch / lgwr – beslist welk proces het transport
doet.
 Sync / async – wel of geen bevestiging van
redo transport

7. Compression of redolog transport
 Oracle 11g – kent compression parameter in
log_archive_dest_n
– Alleen wijziging in parameter
 Oracle 10g – compression door middel van een
ssh tunnel
– Heeft een script nodig voor opzetten tunnel
– Tnsnames moet aangepast worden
– Ssh heeft hogere service level op network.

8. Redo transport / process
logwriter synchroon

9. Redo transport / proces
logwriter asynchroon

10. Redo transport / process archive

11. Wat is een gap en hoe detecteer je die?
Een gap is een archivelog file die nodig is in het
recover process en die niet op de standby
database aanwezig is.
Op de standby kan je deze terugvinden in
gv$archive_gap, mits de database in 'managed
recovery mode' staat.
In het gedrag kan je het zien als archive logs niet
meer ge'applied' worden. De betreffende
archivelog is degene die na de laatst ge'applied'
log komt.

12. FAL process
FAL = Fetch Archive Log
Fal server – is een process dat op de primary
instance draait
Fal client – is een process dat op de standby
instance draait
Zodra de standby, recovery process, bemerkt dat
archivelogs niet aanwezig zijn. Zal de Fal client de
betreffende archive op vragen bij de primary, Fal
server. Het archiver process zal de betreffende
archive log versturen.

13. Physical Standby - Fetch Archive Log

14. Hoe ziet de casus configuratie eruit?


Casus: praktijkgeval van een klant.
`
– Primary database op een locatie ergens in EU
– Standby database in Nederland
– Wan verbinding met lage bandbreedte
– Redolog 100 MB max
– Iedere 10 minuten archivelog, minimaal
– 100MB/10min. netto 171 KB/sec minimaal nodig
– Initiele instelling : logwriter , synchroon,
maximale connecties niet ingesteld.
– Bandbreedte varieert van 60KB/s - 600 KB/s
gemiddeld vaker 100 – 150 KB/sec

15. Infrastructure van de Casus
Archive transport
Primary Standby
Client Conn.
Management conn.

16. Welke problemen zijn er onderkend?
 Opzetten initiele standby database, duurt erg
lang.
 Als er batch jobs draaien dan vertraagd de
gehele database.
 'LNS wait on SENDREQ'.
 Kleine transacties en kleine hoeveelheden
geen problemen
 Network kent service levels, tcp zit in de
laagste klasse.

17. Welke problemen zijn er onderkend?
 Door service levels wordt bandbreedte bepaald.
 Gap resolving veroorzaakt een nieuw gap.
 Gap resolving neemt te veel tijd in beslag,
constant gaps aanwezig
 De grote batches die eenmaal per dag draaien
kunnen makkelijk 3 volle archivelogs per 10
minuten genereren.

18. Oplossingen voor bekende problemen.
Instantiate: verstuur een compressed backup.
 Monitor logwriter waits. Gebruik archiver voor
log transport ipv logwriter.
 Log transport algemeen, gebruik compressie
 Bepaal je netto maximale bandbreedte.
 Reduceer transacties indien mogelijk.
 Zorg dat grote transactions plaatsvinden op
gunstig tijdstip.

19. Wat wil je weten over het redo transport?
 Wachten de processen op het netwerk?
 Komen er regelmatig gaps voor?
 Worden die snel ge'resolved'?
 Hoe groot zijn de redologs, gemiddeld/piek?
 Wat is je netto bandbreedte?
 Welke parameters zijn gezet die invloed hierop
hebben?

20. Demo time
 Start transport – ship only, no apply
 Stop transport
 Genereer transactions, redo
 Expire one file
 Backup archives
 Delete one / two archives
 Start transport en managed recovery
 Laat de status van de processen en archives
zien.

21. Welke middelen zijn er om te meten?
 Tracing van processen, parameter
log_archive_trace
 Gap op standby, gv$archive_gap ( alleen in
managed recovery mode)
 Recovery status standby,
gv$managed_standby
 Status en locatie archive logs, gv$archived_log
 Logminer , onderzoek eens wat er in de redo zit
Sniffer software

22. Monitoring redologs
PRIMARY DATABASE STANDBY DATABASE
Monitor Redo Apply Alert log Alert log
V$ARCHIVE_DEST_STATUS V$ARCHIVED_LOG
V$LOG_HISTORY
V$MANAGED_STANDBY
Monitor redo transport Alert log Alert log
V$ARCHIVED_LOG V$ARCHIVED_LOG
V$ARCHIVE_DEST_STATUS
V$ARCHIVE_DEST
`

23. LOG_ARCHIVE_TRACE parameter
and levels of tracing data
Level Meaning
0 Disables archived redo log tracing (default setting)
1 Tracks archiving of log files
2 Tracks archive status by archive log file destination
4 Tracks archive operational phase
8 Tracks archive log destination activity
16 Tracks detailed archive log destination activity
32 Tracks archive log destination parameter modifications
64 Tracks ARCn process state activity
1 28 Tracks FAL server process activity
2 56 Track RFS Logical Client
51 2 Tracks LGWR redo shipping network activity
1 0 24 Tracks RFS physical client
20 48 Tracks RFS/ARCn ping heartbeat
40 96 Tracks real-time apply activity
81 9 2 Tracks Redo Apply activity (media recovery or physical
standby)

24. Samenvatting
 Waar zijn je redologs
 Wat zijn je doorlooptijden
 Welke processen zijn betrokken
 Onderzoek eens wat er in de redo zit
 Besef wat de gevolgen kunnen zijn voor je
beschikbaarheid
 Als je geen consessies hoeft te doen, doe het
dan niet.

25. Bron vermelding
Oracle® Data Guard Concepts and Administration
Data Guard Redo Apply and
Media Recovery Best Practices
Oracle Database 10g Release 2

26. Data Guard Standby Redolog
Apply
Planboard Oracle DBA Symposium 2009
Rick van Ek

27. Wie ben ik?
 Rick van Ek
 rick.v.ek@xs4all.nl
 Van Ek IT Consultancy BV
 Werkt met Oracle producten sinds 1992
 Zelfstandig sinds 1996
 Oracle database
 Baan IV software

28. Waar gaan we het over hebben?
Korte introductie standby databases
Inleiding van de praktijk casus
Consequenties voor upload redolog apply
Demo archivelog transport
Wat meten we waar

29. Introductie physical standby
Definition Physical Standby Databases
A physical standby database is an exact, block-
for-block copy of a primary database. A physical
standby is maintained as an exact copy through a
process called Redo Apply, in which redo data
received from a primary database is continuously
applied to a physical standby database using the
database recovery mechanisms.
Een physical standby is een binaire copy van de
primary database die constant aan het
ge'recovered' wordt.
De transactions van de primary worden in de vorm
van redo log naar de standby gestuurd via het
netwerk.

30. Introductie physical standby
Basis van de standby is de redo die naar het RFS
process wordt gestuurd.
RFS staat voor Remote File Server, wat eigenlijk al
aangeeft wat het doet. Voor dit proces moet de
instance bestaan. Het is niet voldoende om alleen
een listener te hebben draaien. Zodra de instance
processen gestart zijn functioneerd het transport al.
Ongeacht of de recovery al gestart is.

31. log_archive_dest parameter
 Affirm / noaffirm – bevestiging voor of na het
schrijven van standby redolog
 Compression – vereist oracle advanced
compression option
 Max-connections – maakt meerdere network
connections mogelijk
 Arch / lgwr – beslist welk proces het transport
doet.
 Sync / async – wel of geen bevestiging van
redo transport
Het transport wordt gekonfigureerd doormiddel van de low_archive_dest
parameter in de spfile of init.ora file. Er is hier veel in te stellen alleen de
belangrijkste voor deze presentatie worden hier behandeld. De
genoemde parameters hebben alleen een directe invloed op de
performance in meerdere en mindere mate.

32. Compression of redolog transport
 Oracle 11g – kent compression parameter in
log_archive_dest_n
– Alleen wijziging in parameter
 Oracle 10g – compression door middel van een
ssh tunnel
– Heeft een script nodig voor opzetten tunnel
– Tnsnames moet aangepast worden
– Ssh heeft hogere service level op network.
Compressie is alleen voorhanden op Oracle 11g met het Oracle
Compression option.
Onder Oracle 10g hebben we scripts gemaakt die een ssh tunnel met
compression starten. Hier voor moet de tnsnames worden aangepast
aangezien deze verwijzen moet naar localhost met het portnummer van
de listener.
# =======================================
SSH tunnel from Primary server.
# =======================================
while true
do
ssh -N -C -L Prim:Portnr:Stndb:Portnr Prim
sleep 5
done

33. Redo transport / process
logwriter synchroon
LNS – Logwriter Network Server
Het LNS proces neemt zijn data gelijk van de output buffers van het lgwr
proces. Dit heeft tot gevolg dat wanneer het netwerk het niet kan
bijhouden dit direct invloed heeft op de lgwr. Die wordt dan afgeremd.

34. Redo transport / proces
logwriter asynchroon
LNS – Logwriter Network Server
In asynchroon mode het LSN process neemt zijn data van de redologs.
In principe is het process daarmee los gekoppeld van het logwriter process.
Er kunnen nog steeds waits ontstaan door dat het lgwr proces klaar in
met alle redologs maar lsn niet. Het lgwr process wordt dan vertraagd.

35. Redo transport / process archive
Als het archive proces gebruikt wordt voor het transport dan kent men geen
sync of async modus. Doordat het transport door een seperaat archive
proces gedaan wordt is er geen invloed van de het transport op de
primary database.

36. Wat is een gap en hoe detecteer je die?
Een gap is een archivelog file die nodig is in het
recover process en die niet op de standby
database aanwezig is.
Op de standby kan je deze terugvinden in
gv$archive_gap, mits de database in 'managed
recovery mode' staat.
In het gedrag kan je het zien als archive logs niet
meer ge'applied' worden. De betreffende
archivelog is degene die na de laatst ge'applied'
log komt.
Ieder redo die niet gelijk over gestuurd is is een gap,
echter. Het FAL process gaat pas aan de slag met
om het archive log op te halen als de recovery
manager er om vraagt.

37. FAL process
FAL = Fetch Archive Log
Fal server – is een process dat op de primary
instance draait
Fal client – is een process dat op de standby
instance draait
Zodra de standby, recovery process, bemerkt dat
archivelogs niet aanwezig zijn. Zal de Fal client de
betreffende archive op vragen bij de primary, Fal
server. Het archiver process zal de betreffende
archive log versturen.

38. Physical Standby - Fetch Archive Log
V$archive_gap wordt gevuld door het mrp process.
Pas als het betreffende archive log gerecovered moet
worden wordt het gedetecteerd. Indien de database
niet in recovery modus staat, om welke reden dan
ook. Moet gekeken worden of alle archive log files
geshipped worden.

39. Hoe ziet de casus configuratie eruit?


Casus: praktijkgeval van een klant.
`
– Primary database op een locatie ergens in EU
– Standby database in Nederland
– Wan verbinding met lage bandbreedte
– Redolog 100 MB max
– Iedere 10 minuten archivelog, minimaal
– 100MB/10min. netto 171 KB/sec minimaal nodig
– Initiele instelling : logwriter , synchroon,
maximale connecties niet ingesteld.
– Bandbreedte varieert van 60KB/s - 600 KB/s
gemiddeld vaker 100 – 150 KB/sec
Bandbreedte is niet goed te meten omdat dit constant
afhankelijk is van de drukte op het netwerk en van
de prioriteit die jij hebt en de anderen.
Hoe lager jouw prioriteit hoe groter de kans dat je
moet wachten op ander verkeer.
Met TCP verkeer is de gemiddelde bandbreedte
60KB/s.
Met ssh verkeer, die overigens de hoogste prioriteit
heeft, is dit tussen de 100 – 150 kb/s

40. Infrastructure van de Casus
Archive transport
Primary Standby
Client Conn.
Management conn.
Ieder blokje steld een listener voor. Ieder instance
kent 3 listeners. Een listener voor redolog transport,
een listener voor de gebruikers en een listener voor
administrative zaken.
Hier de listerner voor redo log transport maken
gebruik van een ssh tunnel.

41. Welke problemen zijn er onderkend?
 Opzetten initiele standby database, duurt erg
lang.
 Als er batch jobs draaien dan vertraagd de
gehele database.
 'LNS wait on SENDREQ'.
 Kleine transacties en kleine hoeveelheden
geen problemen
 Network kent service levels, tcp zit in de
laagste klasse.

42. Welke problemen zijn er onderkend?
 Door service levels wordt bandbreedte bepaald.
 Gap resolving veroorzaakt een nieuw gap.
 Gap resolving neemt te veel tijd in beslag,
constant gaps aanwezig
 De grote batches die eenmaal per dag draaien
kunnen makkelijk 3 volle archivelogs per 10
minuten genereren.

43. Oplossingen voor bekende problemen.
Instantiate: verstuur een compressed backup.
 Monitor logwriter waits. Gebruik archiver voor
log transport ipv logwriter.
 Log transport algemeen, gebruik compressie
 Bepaal je netto maximale bandbreedte.
 Reduceer transacties indien mogelijk.
 Zorg dat grote transactions plaatsvinden op
gunstig tijdstip.
Ga gefaseerd van logwriter synchroon naar logwriter
async naar archiver process. Bij iedere stap doe je
consessie.
Gebruik compressie, dat is initieel uitgevonden om
groote bestanden via modem te versturen. Het is
dus niet vreemd om die te gebruiken.
Doe een aantal testen met copieren over het
netwerk, gebruik scp, en maak een statistiek.
In deze casus werd de applicatie ontwikkeld met een
tool die standard een select for update gebruikte.
Inventariseer de batches, kijk wanneer die draaien en
wat dat aan redo opleverd, soms kunnen die
gemakkelijk geoptimaliseerd worden.

44. Wat wil je weten over het redo transport?
 Wachten de processen op het netwerk?
 Komen er regelmatig gaps voor?
 Worden die snel ge'resolved'?
 Hoe groot zijn de redologs, gemiddeld/piek?
 Wat is je netto bandbreedte?
 Welke parameters zijn gezet die invloed hierop
hebben?

45. Demo time
 Start transport – ship only, no apply
 Stop transport
 Genereer transactions, redo
 Expire one file
 Backup archives
 Delete one / two archives
 Start transport en managed recovery
 Laat de status van de processen en archives
zien.

46. Welke middelen zijn er om te meten?
 Tracing van processen, parameter
log_archive_trace
 Gap op standby, gv$archive_gap ( alleen in
managed recovery mode)
 Recovery status standby,
gv$managed_standby
 Status en locatie archive logs, gv$archived_log
 Logminer , onderzoek eens wat er in de redo zit
Sniffer software
Als je gaat meten doe het systematisch, bekijk
doorloop tijden. Kijk welke processen betrokken
zijn aan de primary kant. Probeer het gedrag te
achter halen. Als je op bepaalde momenten veel
redo hebt, kijk dan wat daar in zit. Logminer geeft je
de mogelijkheid om te kijken welke transactions er
in zitten. Informeer of die echt allemaal nodig zijn.

47. Monitoring redologs
PRIMARY DATABASE STANDBY DATABASE
Monitor Redo Apply Alert log Alert log
V$ARCHIVE_DEST_STATUS V$ARCHIVED_LOG
V$LOG_HISTORY
V$MANAGED_STANDBY
Monitor redo transport Alert log Alert log
V$ARCHIVED_LOG V$ARCHIVED_LOG
V$ARCHIVE_DEST_STATUS
V$ARCHIVE_DEST
`

48. LOG_ARCHIVE_TRACE parameter
and levels of tracing data
Level Meaning
0 Disables archived redo log tracing (default setting)
1 Tracks archiving of log files
2 Tracks archive status by archive log file destination
4 Tracks archive operational phase
8 Tracks archive log destination activity
16 Tracks detailed archive log destination activity
32 Tracks archive log destination parameter modifications
64 Tracks ARCn process state activity
128 Tracks FAL server process activity
256 Track RFS Logical Client
512 Tracks LGWR redo shipping network activity
1024 Tracks RFS physical client
2048 Tracks RFS/ARCn ping heartbeat
4096 Tracks real-time apply activity
8192 Tracks Redo Apply activity (media recovery or physical
standby)

49. Samenvatting
 Waar zijn je redologs
 Wat zijn je doorlooptijden
 Welke processen zijn betrokken
 Onderzoek eens wat er in de redo zit
 Besef wat de gevolgen kunnen zijn voor je
beschikbaarheid
 Als je geen consessies hoeft te doen, doe het
dan niet.
Hoe meer consessies gedaan worden ten behoeven
van snelle log transport. Des te minder garantie is
er dat de redologs op tijd op de standby staan.
Hoe minder consessies gedaan worden des te beter
men kan garanderen dat de redologs op de
standby staan bij een calamiteit.

50. Bron vermelding
Oracle® Data Guard Concepts and Administration
Data Guard Redo Apply and
Media Recovery Best Practices
Oracle Database 10g Release 2