Hot back-up betekent dat het systeem actief is en dat de updates gewoon doorgaan
Ik zou hier het Mechanisme volgen door Oracle uitleggen wanneer we hot back-up maken
Handmatige hotback-up
Handmatige hotbackup starten met onderstaande opdracht voor een tablespace
verander tablespace GEBRUIKERS beginnen met back-up;
Er gebeuren op dat moment weinig dingen
1)DBWn controleert de tablespace (schrijft alle vuile blokken weg vanaf een bepaalde SCN)
2)CKPT stopt met het bijwerken van het Checkpoint SCN-veld in de datafile-headers en begint in plaats daarvan met het updaten van het Hot Backup Checkpoint SCN-veld
De datafile-headers die de SCN van het laatst voltooide checkpoint bevatten, worden niet bijgewerkt terwijl een bestand zich in de hot-backupmodus bevindt . Hierdoor kan het herstelproces begrijpen welke logbestanden voor het opnieuw uitvoeren van het archief nodig kunnen zijn om dit bestand volledig te herstellen.
3)LGWR begint met het loggen van volledige afbeeldingen van gewijzigde blokken de eerste keer dat een blok wordt gewijzigd nadat het is geschreven door DBWn
De eerste keer dat een blok wordt gewijzigd in een gegevensbestand dat zich in de hotback-modus bevindt, wordt het hele blok naar de logbestanden opnieuw uitvoeren, niet alleen de gewijzigde bytes. Normaal gesproken worden alleen de gewijzigde bytes (een redo-vector) geschreven. In de hot-back-upmodus wordt het hele blok de eerste keer gelogd. Dit komt omdat je in een situatie kunt komen waarin het proces dat het databestand en DBWR kopieert tegelijkertijd aan hetzelfde blok werkt.
Laten we zeggen dat dit het geval is en dat de OS-blokkerende leesfactor 2K is. Het back-upprogramma gaat een 8k Oracle-blok lezen. Het besturingssysteem geeft het 4k. Ondertussen - DBWR heeft gevraagd om dit blok te herschrijven. het besturingssysteem plant de DBWR-schrijfactie nu. Het hele 8k-blok wordt herschreven. Het back-upprogramma begint weer te lopen (multi-tasking OS hier) en leest de laatste 4k van het blok. Het back-upprogramma heeft nu een gebroken blok gekregen - de kop en de staart zijn van twee tijdstippen.
Oracle kan daar tijdens het herstel niet mee omgaan. Daarom loggen we de volledige blokafbeelding, zodat dit blok tijdens het herstel volledig wordt herschreven vanuit opnieuw en ten minste consistent is met zichzelf. We kunnen het daar herstellen.
Belangrijk punt in Hot back-up
1)Om het effect van deze extra logging te beperken, moet je ervoor zorgen dat je slechts één tablepspace tegelijk in de back-upmodus plaatst en de tablespace uit de back-upmodus haalt zodra je er een back-up van hebt gemaakt. Dit zal het aantal blokken dat gelogd moet worden tot een minimum beperken.
2) Als de tablespace in hotbackup-modus staat en de database wordt afgebroken. En dan probeer je te starten, het zal klagen over herstel omdat het databestand SCN van die tabelruimte ouder zal zijn, om vervolgens de database te starten, moeten we eerst de back-up van die tabelruimte beëindigen. Het werkt eenvoudig het controlepunt SCN bij met de Hot Backup Controlepunt SCN
Recovery Manager-back-up
We hoeven de tabelruimte niet in de hotbackup-modus te zetten om de back-up te maken met behulp van de hotback-modus
Omdat RMAN een Oracle-tool is, weten ze hoe ze met het gebroken blok moeten omgaan, dus het schrijft geen blokfragmenten of gedeeltelijke blokken naar de back-up, schrijft het de volledige consistente blokafbeelding naar de back-upmedia. De herstelmanager hoeft dus niet het volledige blok in het logbestand voor opnieuw uitvoeren op te nemen. Het betekent dus een enorme besparing in het opnieuw loggen van handmatige hotback-up.
Ook bevriest rman de datafile-header niet, het blijft het checkpoint net zo regelmatig controleren, maar het voert wel een checkpoint uit naar de tablespace.
RMAN-back-up noteert de startende SCN, Absolute Fuzzy SCN (wat hetzelfde is als het starten van SCN in het begin) wanneer de back-up begint en aangezien de blokken een back-up zijn in het databestand, wordt het blok gecontroleerd op de SCN, als het hoger is dan het starten SCN, Absolute Fuzzy SCN wordt bijgewerkt met dat nummer. Hetzelfde geldt voor alle blokken, wanneer het hele databestand een back-up is, worden deze beide nummers opgeslagen in de back-upkop.
Dus wanneer RMAN deze back-up heeft hersteld, weten ze dat het weet vanaf welk begin SCN SCN eindigt, het databestand zeker moet herstellen
Dus eigenlijk is er geen overhead zoals meer logging in RMAN hot backup.
Hetzelfde geldt voor beeldback-up met RMAN