Горещо архивиране означава, че системата е готова и работи и актуализациите се извършват както обикновено
Тук бих обяснял Механизъм за проследяване от Oracle, когато правим горещо архивиране
Ръчно резервно копие
Започнете ръчно горещо архивиране с командата по-долу за пространство за таблици
alter tablespace ПОТРЕБИТЕЛИ започват архивиране;
Малко неща се случват по това време
1)DBWn проверява пространството за таблици (изписва всички мръсни блокове към даден SCN)
2)CKPT спира актуализирането на полето Checkpoint SCN в заглавките на файла с данни и вместо това започва да актуализира полето Hot Backup Checkpoint SCN
Заглавките на файла с данни, които съдържат SCN на последната завършена контролна точка, не се актуализират, докато файлът е в режим на горещо архивиране . Това позволява на процеса на възстановяване да разбере какви архивни регистрационни файлове за повторно изпълнение може да са необходими за пълното възстановяване на този файл.
3)LGWR започва да регистрира пълни изображения на променени блокове при първата промяна на блок, след като е записан от DBWn
Първият път, когато блок се промени във файл с данни, който е в режим на горещо архивиране, целият блок се записва в повторете регистрационните файлове, а не само променените байтове. Обикновено се записват само променените байтове (вектор за повторение). В режим на горещо архивиране целият блок се регистрира за първи път. Това е така, защото можете да попаднете в ситуация, в която процесът, копиращ файла с данни, и DBWR работят върху един и същи блок едновременно.
Да кажем, че са и коефициентът на блокиране на четене на ОС е 2K. Програмата за архивиране отива да чете 8k Oracle блок. Операционната система му дава 4k. Междувременно — DBWR поиска да пренапише този блок. ОС планира записването на DBWR да се случи точно сега. Целият 8k блок е пренаписан. Програмата за архивиране започва да работи отново (тук многозадачна ОС) и чете последните 4k от блока. Програмата за архивиране вече е получила счупен блок — главата и опашката са от два момента във времето.
Oracle не може да се справи с това по време на възстановяването. Следователно ние регистрираме цялото изображение на блока, така че по време на възстановяването този блок да бъде напълно пренаписан от повторното изпълнение и да е в съответствие поне със себе си. Можем да го възстановим от там.
Важен момент в Hot backup
1) За да ограничите ефекта от това допълнително регистриране, трябва да се уверите, че поставяте само едно пространство за таблица в даден момент в режим на архивиране и извеждате пространството за таблици от режим на архивиране веднага след като го архивирате. Това ще намали броя на блоковете, които може да се наложи да бъдат регистрирани до възможно най-малко.
2) Ако пространството за таблици е в режим на горещо архивиране и базата данни се прекратява. И тогава се опитвате да стартирате, той ще се оплаче от възстановяване, тъй като SCN на файла с данни на това пространство за таблици ще бъде по-стар, след това, за да стартираме базата данни, първо трябва да прекратим архивирането на това пространство за таблици. Той просто актуализира контролната точка SCN с Hot Backup Checkpoint SCN
Архивиране на мениджъра за възстановяване
Не е нужно да поставяме пространството на таблицата в режим на горещо архивиране, за да направим архивиране с помощта на hotbackmode
Тъй като RMAN е инструмент на Oracle, те знаят как да се справят със случая на счупен блок, така че не записва блокови фрагменти или частични блокове към архива, той записва пълното последователно блоково изображение на архивния носител. Така че мениджърът за възстановяване не трябва да записва пълния блок в регистрационния файл за повторно изпълнение. Така че това означава огромно спестяване при повторно регистриране от ръчно горещо архивиране
Също така rman не замразява заглавката на файла с данни, той продължава да прави контролна точка също както редовно, но изпълнява контролна точка към пространството за таблици.
Резервното копие на RMAN записва началния SCN, Absolute Fuzzy SCN (което е същото като стартирането на SCN в началото), когато архивирането започне и тъй като блоковете се архивират във файла с данни, блокът се проверява за SCN, ако е по-висок от началния SCN, Absolute Fuzzy SCN се актуализира с този номер. Същото важи и за всички блокове, когато целият файл с данни е архивиран, и двата номера се съхраняват в заглавката на архива.
Така че всеки път, когато RMAN възстанови тези резервни копия, те знаят, че знае от какво започва SCN до края на SCN, той трябва да възстанови файла с данни със сигурност
Така че по принцип няма излишни разходи като увеличено регистриране в RMAN горещо архивиране.
Същото важи и за архивиране на изображения с RMAN
