Hot backup betyder att systemet är igång och uppdateringar pågår som vanligt
Jag skulle här förklara Mechanism Following av Oracle när vi tar hot backup
Manuell Hotbackup
Manuell hotbackup börjar med kommandot nedan för ett tabellutrymme
ändra tabellutrymme ANVÄNDARE börjar säkerhetskopiera;
Få saker händer vid den tiden
1)DBWn kontrollerar tabellutrymmet (skriver ut alla smutsiga block från en given SCN)
2)CKPT slutar uppdatera fältet Checkpoint SCN i datafilshuvudena och börjar uppdatera fältet Hot Backup Checkpoint SCN istället
Datafilrubrikerna som innehåller SCN för den senast avslutade checkpointen uppdateras inte medan en fil är i hot backup-läge . Detta gör att återställningsprocessen förstår vilka loggfiler som kan behövas för att återställa den här filen helt.
3)LGWR börjar logga hela bilder av ändrade block första gången ett block ändras efter att ha skrivits av DBWn
Första gången ett block ändras i en datafil som är i hot backup-läge skrivs hela blocket till gör om loggfiler, inte bara de ändrade byten. Normalt skrivs bara de ändrade byten (en redo vektor). I hot backup-läge loggas hela blocket första gången. Detta beror på att du kan hamna i en situation där processen som kopierar datafilen och DBWR arbetar på samma block samtidigt.
Låt oss säga att de är det och OS-blockerande läsfaktor är 2K . Säkerhetskopieringsprogrammet går att läsa ett 8k Oracle-block. OS ger det 4k. Under tiden — DBWR har bett att få skriva om detta block. OS schemalägger att DBWR-skrivningen ska ske just nu. Hela 8k-blocket skrivs om. Säkerhetskopieringsprogrammet börjar köras igen (multi-tasking OS här) och läser de sista 4k av blocket. Säkerhetskopieringsprogrammet har nu fått ett brutet block — huvudet och svansen är från två tidpunkter.
Oracle kan inte hantera det under återhämtningen. Därför loggar vi hela blockbilden så att detta block under återställning skrivs om helt från redo och åtminstone överensstämmer med sig självt. Vi kan återställa det därifrån.
Viktig punkt i Hot backup
1)För att begränsa effekten av denna extra loggning bör du se till att du bara placerar ett tabellutrymme åt gången i säkerhetskopieringsläge och ta bort tabellutrymmet ur säkerhetskopieringsläget så snart du har säkerhetskopierat det. Detta kommer att minska antalet block som kan behöva loggas till ett minimum.
2) Om tabellutrymmet är i hotbackup-läge och databasen avbryts. Och sedan försöker du starta, det kommer att klaga på återställning eftersom datafilen SCN för det tabellutrymmet kommer att vara äldre, sedan för att starta databasen måste vi först avsluta säkerhetskopieringen av det tabellutrymmet. Den uppdaterar helt enkelt checkpoint SCN med Hot Backup Checkpoint SCN
Recovery Manager backup
Vi behöver inte sätta tabellutrymmet i hotbackup-läge för att ta säkerhetskopian med hotback-läget
Eftersom RMAN är Oracle-verktyget vet de hur de ska hantera det brutna blockfallet, så det skriver inte blockfragment eller partiella block till säkerhetskopian, skriver den hela konsekventa blockbilden till backupmediet. Så återställningshanteraren behöver inte registrera hela blocket till redo-loggfilen. Så det innebär enorma besparingar i gör om loggning från manuell hotbackup-fall
rman fryser inte heller datafilens rubrik, den fortsätter att checkpoint lika vanligt, men den utför en checkpoint till tabellutrymmet.
RMAN backup noterar start-SCN,Absolute Fuzzy SCN(vilket är samma som att starta SCN i början) när säkerhetskopieringen börjar och eftersom blocken säkerhetskopieras i datafilen, kontrolleras blocket för SCN, om det är högre än start SCN, Absolute Fuzzy SCN uppdateras med det numret. Detsamma gäller för alla block, när hela datafilen är backup lagras dessa båda siffror i backup header.
Så närhelst RMAN återställde dessa säkerhetskopior, de vet att de vet från vilken början SCN till slut SCN, måste den säkert återställa datafilen
Så i princip finns det inga overhead som ökad inloggning i RMAN hot backup.
Samma sak gäller för bildsäkerhetskopiering med RMAN