В oracle 11g се появяват много нови и невероятни възможности. Направо немислими. Както казва Пламен Зюмбюлев, „Това да пачваш binary-тата докато работят е невероятна глезотия“.
Но аз се наслушах за 11g в последните 7 дни. Сега ще говоря за Oracle 6. И в Оracle 6 се появяват много нови и немислими неща, с които днес сме свикнали. Има възможност да се прави бекъп на БД докато тя работи. Нещо, което тогава е изглеждало немислимо. А днес е немислимо обратното…
И като се замислиш… ама те потребителите РАБОТЯТ! Как може да направиш копие на БД, докато всички пишат и нищо не усещат?
По това време не е имало RMAN. Той се появява в Oracle 7. По време на шестицата са се появили alter tablespace ... begin backup и
alter tablespace ... end backup. Пускаш първото, копираш файловете с каквото искаш OS utility и после пускаш второто.
И до днес се чудех как всъщност става трика. Това, че header-а на data файловете се „замразява“ е ясно, то е описано. Това е защото външното utility, с което копираш, няма идея какво копира и може да прочете header-а последен, примерно. Но как става номера със самите блокове? В документацията не е описано, нито в курсовете казва някой. Ето какво е казано в новата документация (11g):
When updates are made to files in backup mode, additional redo data is logged. This additional data is needed to repair fractured blocks that might be backed up by the operating system utility.
Същото пише и във всички други източници. Това обяснява, че се генерира повече redo, за да се оправи системата с т.нар. fractured blocks. Ама как?
Всъщност, нека дефинирам проблема с fractured blocks. Всичко в Oracle е нацепено на блокчета. Обикновено всичките са еднакви по размер – примерно, 8 КВ. Проблема е, че когато това „външно“ за БД utility (примерно cp, или dd, или Windows Explorer…) чете файла с данни, за да го копира, то не се съобразява с това. И прави заявки за четене по колкото у е удобно – примерно по 100 КВ. Така може да се случи един блок да бъде прочетен на 2 части, с 2 IO операции. Обаче между двете операции може DBWR да се намеси и да промени блока. И понеже не може да се „замразят“ хедърите на всички блокчета (защото потребителите няма да могат да работят), се получават предпоставки блока да е съвсем омешан.
Та, какво прави alter tablespace ... begin backup за да спаси това? Ми, всъщност, елементарно е. Просто поставя tablespace в backup режим и от там нататък първия, който промени даден блок, не записва в redo само промяната си, а целия блок, както е бил в началото. Така за всеки блок имаме началното му състояние и всички последващи промени.
Елементарно, нали? Само трябва да се сетиш… 🙂
Сега, много години по-късно, този механизъм още работи. Вече има rman, който сам се грижи за четенето. Той си знае как е устроена всякак БД и чете блоковете на една IO операция. Така няма нужда от тези хватки за допълнително redo. Но все още разполагаме и с alter tablespace ... begin backup. Въпрос на избор.
