Основи резервного копіювання та відновлення баз даних Oracle® 10 г, випуск 2 (10.2) говорить про це
Заархівовані журнали повтору є запорукою успішного відновлення медіа. Регулярно створюйте резервні копії.
Але мені цікаво, чому резервне копіювання журналів архівів настільки важливе. Чи можна було б здійснити оперативне відновлення, використовуючи звичайні резервні копії файлів даних RMAN.
Відповіді:
Ні, вам все ще потрібні архівовані журнали повторень. Резервна копія RMAN не є такою ж, як холодна резервна копія; при його відновленні вам потрібно застосувати всі повторення, створені з моменту запуску резервної копії, до моменту завершення резервного копіювання, щоб SCN відповідав усім файлам даних і файлу управління.
Розглянемо старі старовинні резервні копії. У цьому режимі цілі змінені блоки бази записуються до потоку повторного журналу, а файл копіюється в ОС. Це викликає розбиті блоки , тобто блок змінився під час зчитування з резервної копії. Отже, щоб відновити базу даних, ми відновлюємо DBF, потім процес відновлення накладає змінені блоки з архівованих журналів повтору на розбиті блоки у файлі, і ми повертаємося до послідовної бази даних.
У резервній копії RMAN проблема усунених блоків усувається, оскільки Oracle зчитує блоки через SGA, а не інструментом Unix cp. Однак DBF змінюється між часом зчитування першого блоку та останнього блоку, тому це та сама проблема, лише в більш масштабному масштабі. Тобто SCN змінюється між першим і останнім блоками в резервній копії. Архівні журнали повторень також охоплюють це.
RMAN дає керованість каталогом та засіб робити гарячі резервні копії без необхідності генерувати повтор із значно більшою швидкістю (що ставить власний стрес на диски, систему резервного копіювання тощо). Однак BACKUP DATABASEбуде НЕ дати вам послідовну базу даних і саме по собі; тільки спосіб зробити це в Oracle є холодним резервним копіюванням.
Резервне копіювання журналів Архів необхідне лише під час роботи в режимі журналу Архів, тому питання повертається до того, чи повинна це робити база даних чи ні. Це висвітлено в тому самому документі, на який ви посилаєтесь у заголовку « Вибір між ARCHIVELOG» та «NOARCHIVELOG Mode» . Ось уривок:
Вибір між режимом ARCHIVELOG та NOARCHIVELOG
Повторені журнали вашої бази даних забезпечують повний запис змін у файлах даних вашої бази даних (за кількома винятками, такими як навантаження прямого шляху).
Ви можете запустити свою базу даних в одному з двох режимів: режимі ARCHIVELOG або режимі NOARCHIVELOG. У режимі ARCHIVELOG використана онлайн-журнальна група повторень повинна бути скопійована до одного або декількох напрямків архіву, перш ніж її можна буде повторно використовувати. В архіві повторного журналу зберігаються всі транзакції, що зберігаються в цьому журналі, щоб потім їх можна було використовувати в операціях відновлення. У режимі NOARCHIVELOG онлайн-журнали повторних груп просто перезаписуються при повторному використанні журналу. Вся інформація про транзакції, записані в цій групі журналів повторень, втрачається.
2.3.3.1 Наслідки бігу в режимі NOARCHIVELOG
Запуск вашої бази даних в режимі NOARCHIVELOG накладає суворі обмеження на стратегію резервного копіювання та відновлення.
Ви не можете виконувати резервні копії бази даних в Інтернеті. Ви повинні закрити свою базу даних чисто перед тим, як зробити резервну копію в режимі NOARCHIVELOG.
Ви не можете використовувати будь-які методи відновлення даних, для яких потрібні архівовані журнали повторень. До них відносяться повне та поточне відновлення медіа, як описано у "Формах відновлення даних", та більш досконалі методи відновлення, такі як відновлення в часі окремих табличних просторів та база даних Flashback (описано в розширеному резервному копіюванні та відновлення бази даних Oracle Посібник користувача.).
Якщо ви працюєте в режимі NOARCHIVELOG і вам належить відновитись після пошкодження файлів даних через збій диска, у вас є два основні варіанти відновлення:
Відкиньте всі об’єкти, які мають будь-які розширення, розташовані у файлах, на які вони впливають, а потім видаліть файли. Залишок бази даних є недоторканим, але всі дані у файлах, які впливають на них, втрачаються.
Відновіть усю базу даних з останньої резервної копії та втрачайте всі зміни в базі даних після резервної копії. (Відновлення змін, оскільки резервне копіювання вимагало б відновлення медіа, яке використовує заархівовані журнали повтору.)
...
Якщо вимоги до продуктивності є крайніми або обмеження дискового простору є серйозним, можливо, бажано працювати в режимі NOARCHIVELOG, незважаючи на обмеження, які цей вибір накладає на ваші параметри відновлення.
Ви майже завжди хочете запускатись у режимі ARCHIVELOG, тому майже завжди хочете створити резервну копію ваших архівів.