Recovery Verbeteringen In Oracle9i
Recovery Verbeteringen In Oracle9i
  • Minimal I/O Recovery
  • Fast-Start Time-Based Recovery
  • Flash Freeze
  • Media Recovery Verbeteringen

Minimal I/O Recovery

De snelheid van crash recovery hangt af van de snelheid dat de data gelezen kan worden uit de redo logs samen met de tijd dat het systeem nodig heeft om de dirty blocks uit het heugen naar de datafiles te schrijven ten tijde van de crash. Het verwerken van de blocken die in geheugen zitten en niet dirty zijn, is onnodig, dus dat zal in Oracle 9 niet meer gebeuren.

Om onnodige verwerking te voorkomen, is de recovery in 2 fases verdeeld.De eerste sequentiële lees actie, scant de logs vanaf de laatste checkpoint om erachter te komen welke blocks niet-bewaarde veranderingen bevat die recovered moeten worden. Deze informatie wordt in de PGA opgeslagen en gebruikt voor de 2de fase van de recovery.
De tweede fase leest alleen blocks, geïdentificeerd in de eerste fase, die in aanmerking komen voor recovery. Deze blocken worden verwerkt om de recovery van datafiels te complementeren.

Omdat het lezen van logfiles een stuk sneller is dan het verwerken van de blocken, is de tijd die nodig is om 2 lees acties te doen en de onveranderde blocken uitsluiten, een stuk sneller dan het verweken van ieder block.

Fast-Start Time-Based Recovery

In Oracle 9i is het mogelijk om de de opdracht mee te geven om een fast-start checkpointing architectuur te gebruiken. Dit stelt het DBWn proces in staat om periodiek dirty buffers naar disk te schrijven en het checkpoint incrimenteel naar voren te zetten. Dit zal de Mean Time To Recovery (MTTR) verlagen en het aantal I/O pieken tijdens logswitches verminderen. Dit in tegenstelling tot het wegschrijven van een checkpoint bij een specifieke gebeurtenis als logswitch.


De FAST_START_MTTR_TARGET initialisatie parameter wordt gebruikt om het aantal seconden te specificeren dat een crash recovery zou moeten duren. Oracle gebruikt deze target time om de FAST_START_IO_TARGET en LOG_CHECKPOINT_INTERVAL parameters te configureren om de crash recovery tijd terug te brengen naar een tijd die zo dicht als mogelijk in de buurt komt als opgegeven in de target. De FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL en LOG_CHECKPOINT_TIMEOUT parameters zouden niet gezet moeten worden omdat deze het proces verstoren.

De maximum waarde voor FAST_START_MTTR_TARGET is 3600 (1 uur), waarden die hoger liggen zullen naar beneden worden afgerond. Er is geen minimum waarde, maar te lage waardes zullen misschien niet mogelijk zijn omdat dit is gelimiteerd aan 1000, de laagste waarde die dirty buffers waarde mag hebben. Hierbij opgeteld komt nog de tijd die de database nodig heeft om te mounten.

Als de waarde te laag is gezet, zal de effectieve waarde van MTTR target die waarde zijn die het systeem kan bereiken. Als de waarde te hoog gezet wordt zal de effectieve waarde van MTTR geschat worden op basis van de gehele buffer cache die dirty is. De ESTIMATED_MTTR kolom in de V$INSTANCE_RECOVERY view kan gebruikt worden om de effectieve MTTR te bekijken. Als de parameter setting, die de ESTIMATED_MTTR kolom altijd verschilt van de de effectieve MTTR, dan zou deze aangepast moeten worden omdat dat aangeeft dat deze waarde is gezet op een onrealistische waarde.


Onthoud dat de extra checkpointing die gedaan moet worden om de crash recovery tijd te verminderen wel van invloed kan zijn op de systeem performance. Een balans zou bereikt moeten worden tussen de algehele systeem performance en de crash recovery time. Zet FAST_START_MTTR_TARGET op 0 om fast-start checkpointing uit te zetten.

De FAST_START_IO_TARGET initialisatie parameter wortd gebruikt om het maximum aantal dirty blocks in de buffer cache aan te geven. Zijn gebruik is ten gunste van de FAST_START_MTTR_TARGET overbodig geworden. In opvolging hiervan is de DB_BLOCK_MAX_DIRTY_TARGET parameter verwijderd.

Flash Freeze

Flash Freeze is een onderzoeks tool dat een diagnostische snapshot van het gehele systeem kan nemen op het moment dat een fout voor de eerste keer voorkomt. De database kan herstart worden op een andere node in het cluster of de ´bevroren´ instance kan gederegistreerd worden uit een Real Application Cluster, zodat de bevroren instance beschikbaar is voor offline diagnose. De verzamelde data kan dan gebruikt worden om het probleem te vinden die de fout heeft veroorzaakt en dit voorkomen voor toekomstig falen.

Media Recovery Verbeteringen

In Oracle8i zou media recovery mislukken indien er een corrupt redo block was welke nodig was om een point in time recovery te verrchten startend vanaf een SCN die voor het corrupte block lag. Oracle9i heeft een tal verbeteringen waaronder:
  • Mislukte recoveries laten de database in een cnosistente staat die als read only geopend kan worden of met resetlogs.
  • De DBA kan de recovery de opdracht geven om blocken als corrupt te markeren en de opgeleverde inconsistentie te negeren zodat de recovery tot voorbij de corruptie kan doorgaan.
  • De DBA kan een rail Recovery beginnen om te checken hoe erg de consistentie zal zijn die door de overgeslagen blocken zal zijn als de recovery compleet is. Dit kan je bereiken door het TEST clause mee te geven aan het eind van het recovery commando.
 

Advertentie

>

Poll

Voorkeur
 

Wie is er aanwezig

We hebben 262 gasten online