Hot backup znamená, že systém je v provozu a aktualizace probíhají jako obvykle
Zde bych vysvětlil mechanismus, který Oracle sleduje, když provádíme zálohování za provozu
Ruční Hotbackup
Spusťte ruční zálohování pomocí níže uvedeného příkazu pro tabulkový prostor
alter tablespace USERS zahájí zálohování;
V tu chvíli se stane jen málo věcí
1)DBWn kontroluje tabulkový prostor (zapisuje všechny špinavé bloky od daného SCN)
2)CKPT přestane aktualizovat pole Checkpoint SCN v záhlavích datových souborů a místo toho začne aktualizovat pole Hot Backup Checkpoint SCN
Záhlaví datového souboru, která obsahují SCN posledního dokončeného kontrolního bodu, nejsou aktualizována, když je soubor v režimu horké zálohy . To umožňuje procesu obnovy pochopit, jaké soubory protokolu opakování archivu mohou být potřebné k úplné obnově tohoto souboru.
3) LGWR začne protokolovat úplné obrazy změněných bloků při první změně bloku po zapsání pomocí DBWn
Při první změně bloku v datovém souboru, který je v režimu horké zálohy, se celý blok zapíše do opakujte soubory protokolu, nejen změněné bajty. Normálně se zapisují pouze změněné bajty (vektor redo). V režimu horké zálohy se poprvé zaprotokoluje celý blok. Je to proto, že se můžete dostat do situace, kdy proces kopírování datového souboru a DBWR pracují na stejném bloku současně.
Řekněme, že ano a faktor čtení blokování OS je 2K. Zálohovací program přečte 8k Oracle blok. OS tomu dává 4k. Mezitím — DBWR požádalo o přepsání tohoto bloku. OS naplánuje zápis DBWR právě teď. Celý 8k blok je přepsán. Zálohovací program se znovu spustí (multi-tasking OS zde) a načte poslední 4k bloku. Záložní program nyní získal zlomený blok — hlava a ocas jsou ze dvou časových bodů.
Oracle se s tím během obnovy nemůže vypořádat. Proto zaprotokolujeme celý obraz bloku, takže během obnovy je tento blok zcela přepsán z redo a je přinejmenším konzistentní sám se sebou. Můžeme to odtud obnovit.
Důležitý bod v Hot backup
1) Abyste omezili účinek tohoto dodatečného protokolování, měli byste zajistit, abyste v režimu zálohování umístili vždy pouze jeden tabulkový prostor a převedli tabulkový prostor z režimu zálohování, jakmile jej zazálohujete. Tím se sníží počet bloků, které může být nutné protokolovat, na minimum.
2) Pokud je tabulkový prostor v režimu hotbackup a databáze se přeruší. A pak se pokusíte spustit, bude si stěžovat na obnovu, protože datový soubor SCN tohoto tabulkového prostoru bude starší, pak pro spuštění databáze musíme nejprve ukončit zálohování tohoto tabulkového prostoru. Jednoduše aktualizuje kontrolní bod SCN pomocí Hot Backup Checkpoint SCN
záloha správce obnovení
Nepotřebujeme umístit tabulkový prostor do režimu hotbackup, abychom provedli zálohu pomocí režimu hotback
Protože RMAN je nástroj Oracle, vědí, jak zacházet s rozbitým blokem, takže nezapisuje fragmenty bloku nebo částečné bloky do zálohy, zapíše úplný konzistentní obraz bloku na záložní médium. Správce obnovy tedy nemusí zaznamenávat celý blok do souboru protokolu redo. Znamená to tedy obrovskou úsporu při opakovaném protokolování z případu ručního zálohování za provozu
rman také nezmrazí hlavičku datového souboru, pokračuje v kontrolním bodu stejně pravidelně, ale provádí kontrolní bod do tabulkového prostoru.
Záloha RMAN si poznamená počáteční SCN, Absolutní fuzzy SCN (což je stejné jako počáteční SCN na začátku), když zálohování začíná, a protože jsou bloky zálohovány v datovém souboru, blok je zkontrolován na SCN, pokud je vyšší než počáteční. SCN, Absolute Fuzzy SCN se aktualizuje o toto číslo. Totéž platí pro všechny bloky, když je zálohován celý datový soubor, jsou tato obě čísla uložena v záhlaví zálohy.
Takže kdykoli RMAN obnovil tyto zálohy, vědí, že ví od začátku SCN po konec SCN, musí pro jistotu obnovit datový soubor
Takže v zásadě neexistuje žádná režie, jako je zvýšené protokolování v RMAN hot backup.
Totéž platí pro zálohování obrazu pomocí RMAN