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.
- 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