Резервне копіювання Oracle. Бекап бази Oracle з Bacula Enterprise. Бекап БД Oracle за допомогою RMAN Backup Database

Операції резервного копіювання та відновлення в Oracle можна розділити на три види:

1. Логічне резервне копіювання - проводиться за допомогою утиліти ехр, що входить до складу Oracle, яка дозволяє експортувати всю базу, задані схеми або таблиці. У разі експорту всієї бази виконується так званий повний експорт (при цьому експортуються всі таблиці бази даних) або інкрементний (вивантажуються таблиці, що змінилися з останнього експорту). Для Oracle 10g ХЕ, в якому обсяг бази не перевищує 4 Гбайт, можна скористатися повним експортом.

2. Фізичне резервне копіювання - виконується після встановлення бази та передбачає копіювання файлів даних, керуючих файлів, оперативних журналів повтору та файлу init.ora з налаштуваннями бази.

3. Оперативне резервне копіювання - здійснюється у базі, що функціонує як ARCHIVELOG. У цьому вся режимі проводиться архівація оперативних журналів повтору і ведеться журнал всіх транзакцій.

Для невеликих навчальних баз даних найпростішим і найнадійнішим є повне логічне резервне копіювання та фізичне резервне копіювання. Логічне резервне копіювання виконується за допомогою утиліти ехр.ехе, розміщеної в папці oraclexe\app\oracle\product\10.2.0\server\BIN\. Утиліта є консольною програмою, що отримує параметри через командний рядок. Оскільки параметрів зазвичай буває багато (5-10 штук), зручно створити профіль із параметрами і потім передати його утиліті експорту за допомогою параметра parfile.

Розглянемо приклад типових профілів. Спочатку вирішимо найпоширенішу завдання - створення резервної копії однієї чи кількох схем. Як приклад розглянемо копіювання схеми STUDENT із навчальним прикладом. Для цього створимо текстовий файл exp_stud.prm, який містить такі рядки:

USERID = ім'я/пароль
LOG = oralOstud.log FILE = oralOstud.dmp 0WNER = STUDENT

Потім зробимо експорт, виконавши команду ехр parfile=exp_stud.prm, у результаті буде створено файл ora10stud.dmp, що містить резервну копію схеми STUDENT. Цей файл має бінарний формат і дуже добре стискається будь-яким архіватором, тому для автоматизації процедури резервного копіювання зручно створити ВАТ-файл, що містить команду експорту та виклик архіватора для стиснення отриманого дампа.

У нашому випадку параметр USERID містить ім'я та пароль для доступу до бази даних, параметр LOG задає ім'я файлу, в який записується протокол роботи, параметр FILE задає ім'я файлу резервної копії, OWNER - одна або кілька схем, що експортуються (якщо вказується кілька схем, то вони перераховуються через кому).

Для повного експорту профіль трохи зміниться:

USERID = ім'я/пароль
LOG = oralOfull.log FILE = oralOfull.dmp FULL = Y

Важливим моментом є те, що експорт конкретної схеми можна виконувати від імені її власника, але для повного експорту необхідно володіти роллю DBA, в іншому випадку спроба повного експорту завершиться помилкою ЄХР-00023 з повідомленням. ». Розмір дампи у разі повного експорту порожньої бази Oracle 10g ХЕ становить 43 Мбайт (9 Мбайт після стиснення WinRar). Настійно рекомендується виконувати періодичне резервне копіювання навіть на навчальній базі - відомі десятки та сотні випадків, коли в ході вивчення Oracle відбувається пошкодження бази, видалення користувача або інша операція, що призводить до втрати створених об'єктів.

Логічний імпорт є дзеркальною операцією щодо експорту та виконується за допомогою утиліти IMP. У ході імпорту необов'язково імпортувати всю наявну в дампі інформацію - можна зробити імпорт заданих схем чи таблиць. Параметри утиліти IMP зручно розміщувати у профілях, наприклад, для імпорту схеми STUDENT можна застосувати профіль наступного виду:

USERID = student/student LOG = oralOstudimp.log FILE = oralOstud.dmp
ROWS = Y
GRANTS = Y
INDEXES = Y
FR0MUSER= STUDENT
T0USER = STUDENT

Параметр FROMUSER вказує, з яких облікових записів у дампі береться інформація, а TOUSER - до яких облікових записів імпортується. Це дуже зручна можливість утиліти імпорту, оскільки дозволяє імпортувати дані однієї схеми в іншу.

Параметри ROWS (рядки таблиць), GRANTS (повноваження об'єкти), INDEXES (індекси) вказують, які типи об'єктів імпортуються.

Розглянемо кілька типових ситуацій, що зустрічаються на практиці:

необхідно імпортувати об'єкти STUDENT в обліковий запис STUDENT1. У цьому випадку слід задати параметри FROMUSER=STUDENT та TOUSER=STUDENT1;

Перед імпортом необхідно видалити всі об'єкти зі схеми, інакше в процесі імпорту будуть видаватися помилки IMP-00015 для кожної таблиці, що імпортується (імпорт даних у цьому випадку не проводиться). Якщо з будь-яких причин необхідно завантажити дані в існуючу таблицю, можна застосувати параметр IGNORE=Y. що призведе до ігнорування помилок під час створення об'єктів та до продовження імпорту даних. Однак у разі застосування параметра IGNORE=Y необхідно враховувати, що в таблицях без первинного ключа може виникнути подвоєння записів (оскільки кожна операція імпорту завантажує нові дані, а старі при цьому не знищуються).

IMP має одну цікаву функцію - замість виконання команд у базі даних ця утиліта виводить їх у протокол, генеруючи тим самим скрипти, що містять DML-оператори. Щоб увімкнути цю функцію, необхідно вказати параметр SHOW=Y.

Бла бла бла. Завжди потрібно робити бекапи, інакше буде як на картинці "Він цмокнув базу і не робив бекапи".

Бекапи повинні виконуватися автоматично згідно з встановленими правилами. Адміністратор повинен втручатися, якщо щось пішло не так, а не щоразу, коли знадобився бекап.

Бекапи слід зберігати на іншому сервері, бажано не в тому самому приміщенні. Якщо такої можливості немає, слід зберігати на якомусь іншому диску, відмінному від того, де зберігаються файли бази даних.

Резервне копіювання баз даних Oracle передбачає створення резервних копій файлів даних, керуючих файлів та файлів архівних журналів. До складу запасного набору можуть включатися файли spfile, init.ora, listener.ora і tnsnames.ora.

Резервне копіювання виконується:

  • Засобами операційної системи.
  • Засобами RMAN (Recovery Manager).

Для централізованого зберігання бекапів великої кількості баз даних Oracle пропонує використовувати Oracle Catalog - ще одна база, створена спеціально для бекапів (Що в ній зберігається поки сказати не можу. Не використовував ніколи). Чомусь я думав, що в ній зберігаються бекапи. Але чогось став сумніватися у цьому.

Крім бекапів, можна експортувати потрібну схему у файл. Після за бажання її можна також імпортувати. При цьому не потрібні інші файли, крім самого файлу дампа.

Режими ARCHIVELOG та NOARCHIVELOG

Oracle записує всі зміни, які вносяться в блоки даних, що знаходяться в пам'яті, в оперативні журнали повторного виконання (online redo logs), і робить це, як правило, перед їх записом у файли бази даних. Під час відновлення Oracle використовує зафіксовані у файлах цих журналів зміни для приведення бази даних в актуальний стан. Oracle підтримує два режими для керування такими файлами.

  • Режим архівування журналів (ARCHIVELOG). У цьому режимі Oracle зберігає (архівує) заповнені журнали повторного виконання. Отже, наскільки давно не виконувалося резервне копіювання, якщо використовується режим ARCHIVELOG, базу даних завжди можна буде відновити до будь-якої точки в часі за допомогою архівних журналів.
  • Режим без архівування журналів (NOARCHIVELOG). У цьому режимі заповнені журнали повторного виконання перезаписуються, а не зберігаються. Це означає, що у разі використання режиму NOARCHIVELOG виконувати відновлення можна буде тільки з резервної копії і що всі інші зміни, які були внесені до бази даних після виконання резервного копіювання, будуть втрачатися. Цей режим забезпечує можливість відновлення тільки після відмови екземляра бази даних. У разі виникнення неполадок з носієм (наприклад, втрата диска), що функціонує в режимі NOARCHIVELOG, базу даних можна буде відновити тільки з резервної копії і, звичайно, з втратою всіх змін, які були внесені до неї після створення цієї резервної копії.

У режимі ARCHIVELOG працюють майже всі виробничі бази даних. Режим NOARCHIVELOG використовується тільки тоді, коли є можливість відновити дані з інших джерел, або коли база даних поки що знаходиться тільки на стадії розробки або тестування і тому не потребує відновлення її даних з точністю до хвилини.

Резервне копіювання всієї або частини бази даних

Піддавати резервному копіюванню можна як всю базу даних так і тільки її частину, на кшталт табличного простору або файлу даних, що входить до її складу. Зверніть увагу, що у випадку, коли база даних функціонує в режимі NOARCHIVELOG, здійснювати резервне копіювання лише частини бази даних, що також називається частковим резервним копіюванням (partial database backup), не можна, якщо всі ті табличні простори і файли, які підлягають резервному копіюванню, не є доступними тільки для читання. Виконувати резервне копіювання всієї бази даних, також зване повним резервним копіюванням (whole database backup), можна як режимі ARCHIVELOG, і у режимі NOARCHIVELOG.

Найчастіше виконується повне резервне копіювання. Воно передбачає копіювання як всіх файлів даних, але ще одного важливого файла – управляючого. Без файлу, що управляє Oracle, не буде відкривати базу даних, тому для відновлення крім резервних копій всіх файлів даних, необхідно також обов'язково володіти і новою резервною копією файлу, що управляє.

Узгоджене (consistent) та неузгоджене (inconsistent) резервне копіювання

Узгоджене резервне копіювання (consistent backup) призводить до створення узгоджених резервних копій і вимагає проведення відновлення. При застосуванні резервної копії для відновлення бази даних або її частини (наприклад, табличного простору або файлу даних), спочатку зазвичай потрібно відновити дані з резервної копії (тобто процедуру RESOTRE), а потім – відновлення працездатності бази даних (тобто . процедуру RECOVER). У разі узгодженого резервного копіювання жодного з цих відновлювальних кроків виконувати не потрібно. У разі неузгодженого резервного копіювання (inconsistent backup) виконання цих відновлювальних кроків завжди є обов'язковим.

Oracle надає кожній транзакції унікальний системний номер зміни (System Change Number - SCN). Кожна фіксація, наприклад, буде проводити збільшення цього номера. Всякий раз, коли Oracle встановлює контрольну точку, всі дані, що змінилися в оперативних файлу даних записуються на диск. І щоразу, коли це відбувається. Oracle виконує оновлення контрольної точки потоку (thread checkpoint) у файлі, що управляє. Під час цього оновлення Orale робить так, щоб усі доступні для читання та запису файли даних та керуючі файли узгоджувалися з тим самим SCN-номером. База даних вважається узгодженою тоді, коли SCN-номери, що зберігаються в заголовках всіх файлів даних, є ідентичними і збігаються з інформацією про заголовки файлів даних, що міститься в файлах, що управляють. Головне запам'ятати, що той самий SCN-номер повинен обов'язково бути присутнім у всіх файлах даних і керуючому файлі (або файлах). Присутність ідентичного SCN- номера означає, що у файлах даних містяться дані за один і той же проміжок часу. Якщо дані є узгодженими, жодні кроки по відновленню після повернення (або копіювання) набору файлів резервних копій на колишнє місце не знадобляться.

Для створення узгодженої резервної копії бази даних необхідно або закривати (звичайною командою SHUTDOWN або SHUTDOWN TRANSACTIONAL, але не командою SHUTDOWN ABORT), або зупиняти (за допомогою команди акуратного завершення роботи) та запускати знову в режимі монтування.

При виконанні неузгодженого резервного копіювання виходить, що файли резервної копії містяться дані за різні проміжки часу. Справа в тому, що більшість виробничих систем не допускається переривати для проведення узгодженого резервного копіювання. Натомість необхідно, щоб ці бази даних працювали 24 години на добу 7 днів на тиждень. Це, отже, означає, що резервне копіювання цих баз даних має виконуватися оперативному режимі, тобто. доки вони залишаються відкритими для транзакцій. Зміна файлів даних користувачами під час резервного копіювання якраз і призводить до отримання неузгоджених резервних копій. Виконання неузгодженого резервного копіювання означає отримання якихось неправильних резервних копій. Однак під час відновлення лише повернення таких резервних копій на колишнє місце недостатньо. Крім повернення їх на колишнє місце, потрібно також обов'язково застосувати всі архівні та оперативні журнали повторного виконання, які були створені в проміжку з моменту виконання резервного копіювання і до моменту, до якого необхідно відновити базу даних. Oracle зчитуватиме ці файли і автоматично застосовуватиме до файлів цих резервних копій всі необхідні зміни.

Оскільки при відритій базі даних можна здійснювати лише неузгоджене резервне копіювання, для більшості виробничих баз даних застосовуються стратегії саме з процедурами неузгодженого резервного копіювання в основі.

Резервне копіювання відкритої та закритої бази даних

Резервне копіювання відкритої бази даних (open backup), також зване оперативним (online backup) або гарячим резервним копіюванням (hot/warm backup), передбачає створення резервних копій при відкритій та доступній для користувачів базі даних. Виконувати оперативне резервне копіювання всієї бази даних (як і тільки табличного простору або файлу даних, що належить їй) можна тільки в тому випадку, якщо база даних функціонує в режимі ARCHIVELOG. Проводити його, коли база даних функціонує у режимі NOARCHIVELOG, не можна.

Резервне копіювання закритої бази даних (closed backup), також зване холодним резервним копіюванням (cold backup), передбачає створення резервних копій при закритій (зупиненій) базі даних. Таке резервне копіювання завжди призводить до створення узгоджених резервних копій, якщо база даних не була зупинена командою SHUTDOWN ABORT.

Фізичне та логічне резервне копіювання

З технічної точки зору процедури резервного копіювання Oracle можна поділити на логічні та фізичні. Під логічним резервним копіюванням (logical backup) мається на увазі створення резервних копій за допомогою утиліти Data Pump Export, які містять логічні об'єкти на кшталт таблиць та процедур. Ці резервні копії зберігаються в особливому двійковому форматі, і дані з них можуть вилучатися тільки за допомогою утиліти Data Pump Import.

Під фізичним резервним копіювання (physical backup) мається на увазі створення резервних копій ключових файлів бази даних Oracle, тобто. файлів даних, файлів архівних журналів повторного виконання та керуючих файлів. Ці резервні копії можуть зберігатися як на дискових, так і на стрічкових накопичувачах

Рівні резервного копіювання

Нижче наведено рівні, на яких дозволяється виконувати резервне копіювання баз даних Oracle:

  • Рівень усієї бази даних. Цей рівень передбачає виконання резервного копіювання всіх файлів, зокрема і файлу, що управляє. Виконувати резервне копіювання на рівні всієї бази даних можна як у режимі ARCHIVELOG, так і NOARCHIVELOG.
  • Рівень табличного простору. Цей рівень передбачає виконання резервного копіювання всіх фалів даних, що належать конкретному табличному простору. Виконувати резервне копіювання на такому рівні можна лише у разі використання режиму ARCHIVELOG.
  • Рівень файлу даних. Цей рівень передбачає виконання резервного копіювання єдиного файлу даних. Виконувати резервне копіювання на такому рівні можна лише у разі використання режиму ARCHIVELOG.

Oracle Database зберігає всі файли створеної бази у файлах даних. Незважаючи на те, що всі дані логічно містяться в табличних просторах, вони фактично є вмістом файлів на жорсткому диску комп'ютера. Так, кожна таблиця бази даних зберігається як рядків конкретного файлу даних. Часто для відновлення даних певної бази достатньо відновити її файли даних і імпортувати їх в Oracle Database.

Структура бази даних Oracle Database

У процесі роботи екземпляр бази даних Oracle Database використовує кілька груп файлів, які потрібно архівувати для подальшого відновлення. Це:

    Файли даних та табличних просторів (*.DBF).

    Назва файлів даних та табличних просторів, а також шляхи до них можна подивитися за допомогою SQL Plus, якщо виконати наступний запит:

    SELECT t.name “Tablespace”, f.name “Datafile” FROM v$tablespace t, v$datafile f WHERE t.ts# = f.ts# ORDER BY t.name;

    Файли конфігурації бази даних (*.ora).

    Конфігураційні файли бази даних Oracle мають розширення *.ora і розміщені у папці:


    Керуючі файли бази даних (*.DBF).

    Найпростіший спосіб визначити шлях і назви файлів, що управляють, це знайти в конфігураційному файлі *.ORA рядок control_files, в якій будуть перераховані керуючі файли, що використовуються цим екземпляром.


    Також, щоб визначити назви та шляхи до керуючих файлів у SQL*Plus необхідно виконати запит:

    SELECT value FROM v$parameter WHERE name = 'control_files';

    Файли журналів транзакцій (*.LOG).

    Щоб дізнатися імена онлайнових журналів транзакцій та шляхи до них, необхідно в SQL Plus виконати наступний запит:

    SELECT member FROM v $ logfile;

    В результаті роботи цього запиту вийде такий звіт:


    Щоб визначити шляхи до тек, де зберігаються архівні журнали транзакцій, необхідно виконати такий запит:

    SELECT destination FROM v$archive_dest where status='VALID';

    В результаті роботи цього запиту вийде звіт:


  • Файл паролів (*.ora).

    Як правило, це файли з розширенням *.ora, ім'я яких починається із символів PWD.

    Наприклад: PWDXE.ora

Отже, для збереження, архівування або бекапу бази даних Oracle Database копії саме зазначених груп файлів слід створювати, а це:

  • *.DBF– файли даних, табличних просторів та файли бази даних. Розташовані:
    C:\oraclexe\app\oracle\oradata\XE
  • *.ora– файли конфігурації бази даних та файли паролів.
    Файли конфігурації:
    C:\oraclexe\app\oracle\product\11.2.0\server\dbs
    Файли паролів (PW...ora):
    C:\oraclexe\app\oracle\product\11.2.0\server\database
  • *.LOG- Файли журналів транзакцій:
    C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG
де ХЕ – це назва бази даних у нашому випадку.

Резервна копія бази даних Oracle Database

Резервну копію бази даних Oracle Database (backup) можна зробити двома способами:

Архівація засобами операційної системи

Архівація засобами операційної системи передбачає «ручне» копіювання всіх робочих файлів бази даних Oracle, таких як:

  • Файли табличного простору.
  • Керуючі файли.
  • Файли журналів транзакцій.
  • Конфігураційні файли.

У цьому випадку процес архівації полягає в простому копіюванні файлів, що управляють, файлів табличних просторів, конфігурації, архівних журналів транзакцій в резервну директорію або на резервний сервер. Архівація проводиться при зупиненому примірнику бази даних, при цьому робота користувачів з нею неможлива.

Для відновлення пошкодженої під час збою бази даних, її необхідно зупинити та переписати резервні копії робочих файлів та журналів транзакцій на колишнє місце.

Архівація та відновлення за допомогою інструментів Export/Import

Архівацію та відновлення бази даних Oracle Database можна проводити за допомогою стандартних механізмів Експорту та Імпорту до Oracle. Для підвищення надійності безпеки даних необхідно періодично, залежно від інтенсивності роботи з базою, виробляти повний експорт. При досить інтенсивному внесенні змін до даних необхідно робити експорт один раз на тиждень.

Для цього:


Імпорт файлу, створеного раніше архіву, здійснюється аналогічним чином:


Відновлення загубленої бази даних Oracle Database

У разі видалення або втрати з якоїсь причини бази даних Oracle Database, її можна відновити, відновивши файли за допомогою Hetman Partition Recoveryта відновити їх способом, описаним у розділі «Архівація засобами операційної системи».

Для цього:


Наприклад, відновлення файлів бази даних описано процес відновлення файлів *.DBF. Але врахуйте, що для відновлення всіх даних працездатної бази також необхідно відновити відповідні *.ORA і *.LOG файли.

Резервування та відновлення бази даних за допомогою Oracle Recovery Manager (RMAN)

Oracle Recovery Manager (RMAN) – це ще один інструмент створення резервної копії бази даних Oracle Database. Відрізняється він від інших інструментів тим, що з його допомогою створюється повна копія всієї бази даних, а не лише даних із неї. Також, що важливо, Oracle Recovery Manager поєднує в собі функціональність SQL Command Line одночасно звільняючи користувача від повної залежності від її команд. Цей інструмент встановлюється на комп'ютер одночасно і разом з установкою Oracle Database.

Щоб створити резервну копію бази за допомогою RMAN:


Щоб відновити базу даних із резервної копії бази за допомогою Oracle Recovery Manager (RMAN):


До речі, у разі втрати або видалення файлу бекапу бази даних Oracle Database, *.BKPфайл бекапу можна також відновити за допомогою Hetman Partition Recovery, після чого відновити описаним вище способом у базі даних, використовуючи Oracle Recovery Manager (RMAN).

У цьому документі описані правила та процедури, які необхідно дотримуватись для резервного копіювання Oracle на рівні підприємств за допомогою Bacula Enterprise Edition. Документ також включає різні сценарії відновлення бекапу Oracle.

Огляд резервного копіювання Oracle

Bacula Enterprise Edition використовує унікальний плагін бекапа Oracle, який дозволяє спростити резервне копіювання Oracle та його відновлення. Плагін дозволяє використовувати передові методи для «гарячого» та «холодного» резервного копіювання Oracle та відновлення даних та конфігурацій, що зберігаються на серверах 10 та 11 поколінь. Плагін бекапу бази Oracle дозволяє відновлювати Oracle на конкретний момент часу (до контрольної точки), фільтрувати об'єкти під час резервного копіювання Oracle та їх відновлення. Він також дозволяє створювати бекапи Oracle з інформацією про конфігурацію, наприклад параметри. Плагін бекапу БД Oracle підтримується платформами Linux 32/64 біт, що підтримуються Oracle, а також БД Oracle 10.x, 11.x.

Інші переваги резервного копіювання Oracle за допомогою Bacula:

  • При використанні режиму RMAN плагін дозволяє створювати інкрементальні та диференціальні бекапи Oracle на рівні блоків.
  • Функція відстеження змін RMAN, яка використовується для подальших інкрементальних бекапів, суттєво покращує створення резервних копій, записуючи змінені блоки кожного файлу даних у файл відстеження змін.
  • Адміністратор БД не повинен мати навичок роботи з БД Oracle або вміти створювати складні скіпти для бекапу Oracle.
  • Цей плагін для створення та відновлення бекапів Oracle призначений також для створення резервних копій інформації про конфігурацію, наприклад параметрів.

У цьому документі представлені різні способи та стратегії резервного копіювання Oracle з використанням ПЗ Bacula Enterprise Edition та відповідного плагіна.

Глосарій бекапу Oracle

У документі використовуються такі терміни:

  • ARC(архівний журнал реєстрацій)– стандартний метод, який використовується для забезпечення цілісності даних. Основна ідея ARC полягає в тому, що зміни, які вносяться до файлів даних (у яких знаходяться таблиці та індекси), будуть записані тільки після того, як зміни будуть зареєстровані в журналі, тобто після того, як записи в журналі, що описують зміни, будуть перенесені у постійне сховище.
  • PITRВідновлення Oracle до заданої контрольної точки (PITR) відновлює БД до певного моменту часу, а потім використовує інкрементальні бекапи та відкати для відновлення БД до вказаної точки. PITR відновлення іноді називають неповним, тому що в результаті PITR відновлення БД відновлюється до конкретного моменту, а сама процедура не використовує всі файли журналу резервного копіювання Oracle.
  • RMANДиспетчер відновлення Oracle або утиліта RMAN, командний рядок та інструмент на базі Oracle Enterprise Manager – метод резервного копіювання та відновлення БД, рекомендований компанією Oracle. Утиліта RMAN призначена для роботи безпосередньо з сервером. Утиліта дозволяє визначати пошкоджені блоки даних під час резервного копіювання та відновлення БД. Утиліта RMAN оптимізує продуктивність та споживання пам'яті під час створення бекапу шляхом ущільнення файлів та стиснення набору резервних копій.
    http://docs.oracle.com/cd/B28359_01/backup.111/b28270/toc.htm
  • EXP/IMPУтиліти експорту (exp)/імпорту (imp) Oracle використовуються для виконання логічного резервного копіювання/відновлення БД. При експорті створюється дамп об'єктів БД у вигляді бінарного файлу, який потім може бути імпортований в іншу БД Oracle.
  • Data PumpТехнологія Oracle Data Pump – це більш сучасна, швидка та гнучка альтернатива утилітам “exp” та “imp”, які використовувалися у попередніх версіях Oracle. На жаль, цей новий метод не підтримує виведення даних безпосередньо у файл FIFO. Тому використання інструментів Data Pumpвимагає, щоб ви спочатку створили дамп даних на диску, а потім рахували ці дані за допомогою Bacula Enterprise File Daemon. Поточна версія плагіна бекапу Oracle не підтримує технології Data Pump.
  • SBTЗа замовчуванням RMAN посилає всі бекапи Oracle у спеціальний системний каталог на диску. Ви також можете налаштувати RMAN таким чином, щоб бекапи створювалися на інших носіях, наприклад магнітних стрічках, за допомогою SBT модуля. Bacula в цьому випадку буде виступати в якості Диспетчера носіїв (Media Manager), а дані будуть передаватися безпосередньо від RMAN до Bacula.
  • libobkІнтерфейс SBT реалізований з урахуванням файлу бібліотеки libobk.
  • TablespaceБД поділена на логічні сховища, які називаються табличними просторами, які групуються на основі логічної структури. Наприклад, табличні простори, як правило, групують усі прикладні об'єкти з метою спрощення адміністрування.
  • Схема- Це сукупність об'єктів БД. Схемой володіє користувач БД. Схема має те саме ім'я, що і її користувач. Об'єкти схеми – це логічні структури, які пов'язані з даними БД. Об'єкти схеми включають такі структури, як таблиці, види, індекси. (Між табличним простором і схемою немає зв'язку. Об'єкти однієї схеми, можуть бути в різних табличних просторах, а табличні простори можуть містити об'єкти їх різних схем.)
  • ІнстансСервер БД Oracle складається з БД Oracle та інстансу БД Oracle. Щоразу під час запуску БД виділяється системна глобальна область (SGA) і запускаються фонові процеси Oracle. Комбінація фонових процесів та буферів пам'яті називається інстансом Oracle.
  • SIDСистемний ID Oracle (SID) використовується для ідентифікації БД у системі. Тому в одній системі не може існувати більше однієї БД з унікальним SID. Як правило, SID задається змінною “ORACLE_SID”. Як варіант, ви можете знайти цей ідентифікатор у першому полі (before 🙂 конфігураційного файлу /etc/oratab).
  • КопіяЩоразу при відкритті БД за допомогою команди ALTER DATABASE OPEN RESETLOGS створюється така копія.
  • SCNСистемний номер зміни (SCN) — номер Oracle, який збільшується послідовно з кожною зміною, що вноситься в БД: вставкою, оновленням, видаленням. Номер SCN також збільшується внаслідок взаємодії БД.
  • Відновлення Oracle- Дія, що призводить до вилучення даних з бекапу. Після відновлення БД, можливо, потрібно повернути її до вихідного стану, тобто відкотити вперед до певної контрольної точки.
  • Повернення до вихідного стану– це процедура оновлення відновленого файлу даних з використанням архівних журналів реєстрації операцій «redo» та поточних журналів реєстрацій, тобто із застосуванням змін, внесених до БД після створення бекапу.
  • Функція Proxy Copy– це функція утиліти RMAN, яка не підтримується поточною реалізацією інтерфейсу SBT Bacula Enterprise.

Умовні позначення

  • Значення, укладені у дужки< >вводяться користувачами, наприклад, потрібно замінити на поточний номер ORACLE_SID. Якщо ваш номер ORACLE_SID є тестовим TEST, файл, записаний як init .ora виглядатиме як initTEST.ora.
  • % означає, що команда має бути запущена звичайним користувачем.
  • # означає, що команда має бути запущена через обліковий запис привілейованого користувача.
  • RMAN> означає, що команда має бути запущена всередині сесії rman.
  • SQL> означає, що команда має бути запущена всередині сесії sqlplus.
  1. Бекап Oracleз плагіном

Вибір методу бекапу Oracle: Дамп або утиліта RMAN

У таблиці нижче показано переваги методів відновлення бекапів, які підтримує плагін Bacula Enterprise для Oracle. Щоб вибрати той чи інший метод, керуйтеся такими можливостями, як можливість відновлення бекапу Oracle до заданої контрольної точки, можливість фільтрації об'єктів під час резервного копіювання або відновлення. Також користувач може комбінувати методи створення дампи та використання утиліти RMAN PITR для одного кластера.

Утиліта RMAN також дозволяє використовувати сучасні методи, завдяки яким ви можете надсилати дані через SBT інтерфейс Bacula Enterprise, наприклад, на магнітну стрічку та диск одночасно для більш швидкого відновлення.

Функція Дамп RMAN RMAN SBT
Можливість відновлення одного об'єкта (таблиця, схема…) Так Ні Ні
Можливість відновлення одного файлу (індекс, БД, таблиця…) Ні Так Так
Швидкість створення бекапу Oracle Низька Висока Висока
Швидкість відновлення Низька Висока Висока *
Розмір бекапу Oracle Малий Великий Великий
Розмір на локальному диску під час створення бекапу Нічого Весь бекап Нічого
Розмір на локальному диску під час відновлення Нічого Весь бекап Необхідні об'єкти
Можливість відновлення до контрольної точки Ні Так Так
Підтримка інкрементального/диференціального бекапу Oracle Ні Так Так
Паралельне відновлення Так Так Так
Онлайн бекап Oracle Так Так Так
Узгодженість Так Так Так
Можливість відновлення до попередньої основної версії Oracle Ні Ні Ні

Таблиця 1. Способи відновлення Oracle

* При використанні інтерфейсу RMAN SBT швидкість відновлення залежатиме від різних елементів, таких як тип носія (магнітна стрічка або диск), швидкість передачі по мережі, доступність пристрою з демоном-охоронцем, і т.д. пристрій з демоном-охоронцем може використовувати той же том диска для безлічі паралельних відновлень. Таким чином, існує можливість одночасного виконання кількох завдань з відновлення та резервного копіювання Oracle.

Конфігурація RMAN SBT

У цьому розділі посібника користувача описано правильне встановлення та конфігурування SBT інтерфейсу Bacula Enterprise за допомогою Oracle та RMAN.

При створенні бекапу Oracle або запуску резервного копіювання з RMAN, RMAN знадобиться зв'язатися з централізованим директором Bacula Enterprise Director для отримання інформації про файли та томи, або для запуску резервного копіювання або відновлення Oracle. Для встановлення зв'язку потрібні спільні командні файли FIFO та b-консоль.

При використанні плагіна oracle-sbt-fd директор не зможе запустити резервне копіювання Oracle з b-консолі або з розкладу. Тільки утиліта RMAN зможе ініціювати сесію та запустити резервне копіювання. Зверніть увагу на те, що ви, як і раніше, запускаєте стандартне системне резервне копіювання Oracle, а потім використовуйте RunScript для автоматичного виклику RMAN.

Налаштування Bacula.У разі використання інтерфейсу SBT необхідно встановити b-консоль (консоль Bacula). Консоль повинна дозволяти підключатися до централізованого директора та отримувати доступ до локального клієнта, завдання резервного копіювання Oracle та інших характеристик пулу.

Щоб використовувати консоль з обмеженими можливостями, можна скористатися таким визначенням консолі:

Малюнок 1. Бекап Oracle при взаємодії між RMAN та Bacula

Користувач “oracle” ОС Unix повинен мати можливість відобразити b-консоль та вважати відповідний конфігураційний файл bconsole.conf, який не є конфігурацією за умовчанням. Ви можете скопіювати бінарний та конфігураційний файл до папки /opt/bacula/oracleза допомогою наступних команд Unix:

Важливо: Можливо, після кожного оновлення Bacula Enterprise вам знадобиться копія бінарної b-консолі.

Виконання паралельних завдань при бекапі БД Oracle

Щоб запустити резервне копіювання Oracle або відновлення за допомогою декількох каналів, вам необхідно гарантувати, що всі необхідні ресурси плагіна бекапу БД Oracle правильно налаштовані за допомогою команди Maximum Concurrent Jobs, щоб дозволити виконання паралельних завдань.

  • Director: Director (ex: 100)
  • Director: Client (ex: 10)
  • Director: Job (ex: 10)
  • Director: Storage (ex: 10)
  • Storage: Storage (ex: 100)
  • Storage: Device (ex: 10 або 10 пристроїв, згрупованих у віртуальний перемикач Virtual Changer)
  • Client: FileDaemon (ex: 10)

Щоб забезпечити паралельне виконання завдань резервного копіювання та відновлення за допомогою одного ресурсу Director Storage, конфігурація повинна використовувати дисковод Virtual Changer. Інформація про особливу конфігурацію викладена у технічній документації Disk Backup.

Обмеження, пов'язані з носіями

Oracle вимагає, щоб Диспетчер носіїв (Media Manager) Bacula Enterprise не об'єднував потоки даних від двох паралельних API сесій в тому самому послідовному пристрої. Це означає, що, якщо ви використовуєте накопичувач на основі магнітної стрічки для бекапу БД Oracle, ви повинні використовувати різні стрічкові накопичувачі для кожного паралельного завдання резервного копіювання. Дане обмеження не стосується дискових накопичувачів. Це обмеження передбачає особливо тривале відновлення.

Конфігурація Bacula SBT

libobkможна налаштувати за допомогою файлу /opt/bacula/oracle/sbt.confабо / opt/bacula/etc/sbt.confабо за допомогою команди RMAN SEND. У таблиці 2 наведені використовувані дескриптори:

Параметр Опис приклад
client Ім'я клієнта Bacula client=oracle-fd
restoreclient Ім'я клієнта Bacula, що використовується для відновлення restoreclient=oracle-fd
job Команда b-консолі з аргументами

bconsole="/tmp/bconsole -n"
restorejob Ім'я завдання відновлення Bacula. Якщо встановлено декілька завдань відновлення у вашій конфігурації, а цей параметр не використовується, плагін SBT автоматично вибере першу задану задачу відновлення. restorejob=RestoreFiles
waitjobcompletion Очікування завершення завдання в кінці сесії SBT. За замовчуванням сесія завершується якнайшвидше. Зверніть увагу на те, що цей параметр потрібно використовувати тільки при запуску резервного копіювання з утиліти RMAN. waitjobcompletion
update Тип поновлення (локальний каталог). Якщо ім'я файлу є у локальному каталозі, плагін відповідає безпосередньо RMAN не зв'язуючись директором Bacula Director. Використовуйте update=force, щоб примусово задати перевірку Bacula Director. update=force
jobopt Додатковий параметр завдання jobopt="spooldata=no"
backupdir Папка локального каталогу backupdir=/opt/bacula/oracle
ctrlfile Основний шлях до файлу, що управляє ctrlfile=/tmp/oracle
ctrltimeout Пауза під час підключення до Bacula ctrltimeout=300
retry Кількість спроб при підключенні до Bacula
localdir Локальна папка файлу даних, який перевірить SBT плагін до виклику завдання відновлення Bacula.

Localdir=/tmp/@ORACLE/sbt
catalog Ім'я каталогу Bacula catalog="MyCatalog 2"
trace Шлях до файлу файл трасування trace=/tmp/log.txt
debug Рівень налагодження

Таблиця 2. Конфігурація SBT libobk

Як мінімальні параметри, які необхідно вказати у файлі конфігурації, виступають такі, як клієнт, завдання та b-консоль. Зверніть увагу на те, що необхідно використовувати подвійні лапки, якщо конфігурований елемент містить пробіли (наприклад, b-консоль).

Ці параметри можна перезаписати за допомогою команди RMAN SEND.

Команда SEND обмежена 512 байтами, тому можна використовувати кілька команд SEND, щоб задати всі параметри. Краще уникати довгі шляхи при використанні SBT інтерфейсу.

Конфігурація FileSet

Плагін бекапу бази Oracle SBT (oracle-sbt) приймає параметри Job FileSet, як описано в таблиці 3.

Таблиця 3. Параметри плагіна Oracle SBT

Тестування конфігурації sbt.conf

Щоб протестувати конфігурацію плагіна Bacula Enterprise Oracle SBT, привілейований користувач може використовувати такі команди:

У разі виникнення помилки підключення з'явиться повідомлення. Поки ви не налаштуєте правильно налаштування підключення, немає сенсу запускати резервне копіювання Oracle RMAN.

Внутрішній каталог Bacula SBT

Файл libobk Bacula Enterprise використовує локальний каталог для зберігання інформації про всі файли. Ця інформація може застаріти. Тому можна використовувати параметр update=force у файлі sbt.conf або команду SEND для примусового пошуку каталогу Bacula.

Каталог за замовчуванням зберігається в / opt/bacula/oracle/bacula-sbt.catі може бути частиною звичайного бекапу системи.

Здатність збереження бекапу Oracle RMAN

При використанні плагіна RMAN SBT Bacula Enterprise, здатність збереження бекапу Oracle, задана утилітою RMAN, повинна відповідати Bacula або збереженню завдання в пам'яті. Коли RMAN надішле команди на видалення файлів бекапу, Bacula не намагатиметься що-небудь очищати або видаляти.

Приклади бекапів Oracle

У наступному прикладі описано одночасний запуск 3 паралельних задач Bacula зі створення резервних копій. При цьому утиліта RMAN надсилатиме в них дані, використовуючи так званий циклічний алгоритм. Якщо утиліта RMAN не зможе зв'язатися з Bacula по одному або більше каналах, RMAN автоматично надішле дані до доступного каналу. Це означає, що якщо ваше сховище або централізований директор зайняті (обмежені кількістю пристроїв або налаштуванням максимальної кількості паралельних завдань), RMAN знайде вихід автоматично.

У цьому прикладі RMAN використовує 3 завдання Bacula для відновлення 3 файлів.

Конфігурація режиму RMAN

У цьому розділі посібника користувача описується процедура конфігурування утиліти RMAN для правильної роботи з частиною плагіна бекапу бази Oracle, яка не використовує SBT інтерфейс.

Поточна версія плагіна бекапу БД Oracle підтримує лише БД, запущені з активним режимом ARCHIVELOG.

Конфігурація ARCHIVELOG у Oracle

Щоб використовувати режим створення бекапів Oracle з RMAN, необхідно запустити БД в режимі ARCHIVELOG. Щоб перевірити, як налаштована ваша база даних, ви можете використовувати наступну команду SQL.

Щоб активувати режим архівування для БД, можна використовувати команду ALTER DATABASE ARCHIVELOG у стані SYSDBA.

  • Зупиніть роботу БД за допомогою команди SHUTDOWN
  • Створіть бекап БД
  • Відредагуйте файл init .ora, щоб налаштувати розташування архівного журналу реєстрації
  • Запустіть БД, не відкриваючи за допомогою команди STARTUP MOUNT
  • Змініть режим архівування за допомогою ALTER DATABASE ARCHIVELOG; та відкрийте її за допомогою команди ALTER DATABASE OPEN;
  • Зупиніть роботу БД за допомогою команди SHUTDOWN IMMEDIATE
  • Ще раз створіть бекап БД, оскільки зміна ARCHIVELOG оновить файли, що управляють, і перетворить старі бекапи на непридатні для використання. Плагін Bacula Enterprise для Oracle створить RMAN бекап, поміщений у вкладену папку в місці, де знаходиться архівний журнал реєстрації, вказаний у файлі init .ora.

Оптимізація інкрементального бекапу Oracle

Функція відстеження змін утиліти RMAN для створення інкрементальних бекапів Oracle підвищує ефективність таких бекапів шляхом запису змінених блоків у кожному файлі даних у файл відстеження змін. Якщо функція відстеження змін активна, утиліта RMAN використовує файл відстеження змін для визначення змінених блоків для створення інкрементальних бекапів. Таким чином, відпадає необхідність у скануванні кожного блоку у файлі даних.

Після активації функції відстеження змін, у разі першого повного бекапу, системі, як і раніше, доведеться відсканувати всі файли даних, оскільки файл відстеження змін ще не відображає стану всіх блоків. Будь-який наступний інкрементальний бекап, який використовує цей повний бекап як материнський, буде використовувати файл відстеження змін.

Наступна команда SQL, запущена як sysdba, дозволяє активувати функцію відстеження змін та використовувати розташування “/path/to/file” як місце розташування архівного журналу реєстрації. (Зверніть увагу на те, що файл повинен знаходитися в діючій папці, в яку користувач Oracle може записувати дані).

Здатність збереження бекапу RMAN

При використанні режиму RMAN разом із плагіном Bacula Enterprise для Oracle, кожна задача Bacula запускатиме RMAN для створення набору резервних копій. Ми рекомендуємо конфігурувати утиліту RMAN, щоб видаляти старі файли через певний час. Незважаючи на те, що цю операцію можна виконувати відразу після завершення створення бекапу, ми рекомендуємо зберігати дані на диску довше, щоб не виникали труднощі з можливістю відновлення Oracle до контрольних точок. Наступна команда допоможе задати період зберігання файлів Oracle 7 днів. Цього часу має вистачити за умови, що ви виконуєте резервне копіювання Oracle щонайменше раз на 7 днів.

Більш детальну інформацію ви знайдете у посібнику до утиліти RMAN

docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmconfb.htm#i1019318

Конфігурація плагіна Oracle для RMAN

У разі використання функції PITR відновлення утиліти RMAN, плагін Bacula для Oracle вимагатиме активації режиму Accurate. Ви повинні активувати режим Accurate у ресурсі завдання. Зверніть увагу на те, що в поєднанні з плагіном, функція Accurate використовується для того, щоб гарантувати, що всі нові файли, будуть зберігатися плагіном Bacula, але не будуть позначатися як віддалені, оскільки, швидше за все, вони можуть стати в нагоді.

У режимі RMAN плагін для Oracle також дозволяє використовувати додаткові параметри, що задаються через командний рядок плагіна. Дивіться таблицю нижче:

Параметр Опис За замовчуванням приклад
mode Необхідно активувати PITR бекап у режимі RMAN Дамп mode=rman
Oracle_user Привілейований користувач Unix Oracle oracle oracle_user=oracle10
sid Oracle SID SID=XE
Oracle_SID Oracle SID Oracle_SID=XE
Oracle_HOME Oracle HOME ORACLE_HOME=/opt/oracle/…
verbose Висновок RMAN відображається як 0 у завданні verbose=1
sbt Використання SBT в RMAN sbt
ctrlfile Основний шлях до файлів керування при використанні SBT ctrlfile=/tmp/oracle

Таблиця 4. Параметри плагіна для Oracle у режимі RMAN

Потім, використовуючи where=/ або where= плагін завантажить цей SQL файл у вашу базу даних. Якщо деякі ролі вже існують, з'явиться повідомлення про помилку в журналі реєстрації завдань. Також можна відновити файл users.sql file у локальний каталог, відредагувати та завантажити його за допомогою sqlplus, щоб відновити будь-яку вибрану частину файлу.

Відновлення однієї БД Oracle.Щоб відновити одну схему за допомогою плагіна Bacula Enterprise для Oracle, необхідно вибрати схему каталогу під час команди відновлення, вибір повинен містити файл даних (data.dmp) і скрипт створення схеми (user.sql).

Мал. 3 Вміст БД з дампом у BWeb

Як тільки буде обрано каталог БД, ви зможете використовувати параметр where для відновлення схеми нову схему з іншим ім'ям. Щоб створити нове ім'я схеми, потрібно прирівняти параметр where до одного слова, яке містить символи A..Z, 0-9, і _. Потім плагін Bacula створить зазначену схему і відновить дані.

Ми рекомендуємо вам завжди використовувати в назві схем великі літери. Плагін Bacula Enterprise для Oracle відтворить нову схему, використовуючи ім'я, яке ви вказали у параметрі where=. Якщо ви будете використовувати великі та малі літери в імені, може виникнути ситуація, при якій вам доведеться укласти ім'я схеми в лапки, щоб отримати до неї доступ.

Після відновлення, вам, можливо, потрібно скинути пароль схеми, яку ви щойно створили, використовуючи ті ж параметри, що й у вихідній схемі. Щоб це зробити, виконайте:

Якщо ви задасте параметр, рівний never, плагін Bacula перевірить список схем і перерве завдання, якщо поточна схема, що відновлюється, вже існує.

Якщо параметр where – це каталог (що містить /), плагін Bacula відновить усі файли до цього каталогу. Таким чином, ви зможете використовувати каталог imp і відновити тільки тригери, таблиці, індекси і т.д.

Відновлення однієї таблиці Oracle.Щоб відновити один об'єкт, наприклад, таблицю зі створеного вами дампа, вам необхідно спочатку відновити файл дамп в локальний каталог. Потім, за допомогою інструмента imp імпортувати потрібний об'єкт. Більш детальну інформацію ви знайдете у документації з імпорту об'єктів у Oracle.

Відновлення дамп файлів Oracle у каталог.Щоб відновити SQL дампи в каталог, ви можете призначити параметр, де будь-який діючий каталог.

Процес відновлення Oracle з плагіном Bacula створить наступні папки при відновленні схеми SYS Oracle SID XE, і відновить у неї вибрані файли.

Відновлення всієї БД Oracle.Щоб відновити всі бази даних та конфігурації бази даних, просто відновіть всі файли, розташовані в /@ORACLE/ , використовуйте replace=always та where=/.

Обмеження бекапу та відновлення Oracle

Плагіни за промовчанням не сумісні із завданнями Copy/Migration/VirtualFull.

Створити резервну копію даних бази oracle можна двома способами:

  • Використовуючи засоби операційної системи.
  • Використовуючи утиліти самої бази даних.

У кожного з цих способів є переваги та недоліки. У разі створення резервної копії засобами операційної системи необхідно, щоб на всьому протязі процесу створення резервної копії екземпляр був зупинений, щоб уникнути неузгодженості даних, що неприпустимо у разі необхідності функціонування системи в режимі 24/7. Другий основний недолік це складність адміністрування великої кількості резервних та трудомісткість їх перевірки на помилки.

Використовуючи утиліти бази даних цих недоліків, можна уникнути, але з'являються інші недоліки, складність налаштування та власний синтаксис команд.

Вбудовані утиліти бази даних для створення резервних копій – це насамперед exp та expdp, що дозволяють створювати логічну резервну копію (тобто копію об'єкта бази даних). Такий спосіб створення резервної копії простий, а основний його недолік - це час відновлення з копії у разі необхідності перевстановлення екземпляра та можливість відновити об'єкт лише на конкретний момент здійснення бекапу.

Найпотужнішою, створеною компанією oracle спеціально для створення резервних копій баз даних, є утиліта RMAN. Яка дозволяє створювати повну копію бази даних без зупинки екземпляра та відновлювати її на будь-який момент у минулому, сама стежить за застарілими копіями і видаляє їх за необхідності, а також перевіряє їх на наявність помилок. Але при цьому має серйозний недолік складна в налаштуванні та адмініструванні. Познайомимося ближче з налаштуванням та адмініструванням цієї утиліти.

Утиліта RMAN з'явилася у версії 8g та удосконалювалася у наступних. Налаштуємо цю утиліту для створення резервних копій нашої бази даних.

Насамперед потрібно зрозуміти з чого складається база даних і вирішити, з якою періодичністю необхідно робити резервну копію. У нашому випадку це база даних oracle і складається з наступних файлів:

  • табличні простори;
  • керуючі файли;
  • журнали повторного виконання;
  • файли даних (init.ora, spfile, tnsnames.ora, listener.ora, orapwd);

Вибравши дані для збереження визначаємося зі стратегією копіювання, а саме вибираємо періодичність, тип резервних копій, що створюються, і час їх зберігання. Резервні копії бувають інкрементними повними - тобто повністю скопійований файл, інкрементними кумулятивними - коли копія містить лише різницю даних між поточним станом і станом на час останнього інкрементного бекапу і інкрементними диференціальними - такі копії містять в собі різницю між поточним станом і станом бекапу. Вибір стратегії визначається режимом роботи бази даних, якщо це база даних із частим внесенням змін, бажано частіше робити інкрементальні повні копії це дозволить швидше відновити роботу бази після збою, т.к. не доведеться виконувати велику кількість транзакцій. Якщо ж ця база даних використовується в основному для зберігання та читання, то інкрементальні копії можна робити рідко та обмежитись регулярними кумулятивними.

Наша база даних використовується в основному для зберігання і мало змінюється в часі тому виберемо наступну стратегію: створення інкрементної копії раз на тиждень 3 ночі в неділю, і створення кумулятивних копій щоночі в 3 години, це дозволить не займаючи багато дискового простору швидко відновити базу використовуючи максимум 2 копії.

Після того як ми визначилися з тим, що копіювати і з якою періодичністю можемо переходити до налаштування екземпляра бази даних. Насамперед слід переконатися, що база даних функціонує в режимі архівування журналів повторного виконання (archivelog), перевірити це можна запитом:

Виберіть log_mode from v$database; від будь-якого користувача із правами sysdba. Якщо запит повернув archivelog, то все в порядку переходимо до наступного пункту, якщо noarchivelog то потрібно перезапустити базу в режимі archivelog. Для цього потрібно перезапустити базу в режимі mount командою:
startup mount immediate та виконати команду
alter database archivelog; вона активує режим archivelog, після цього залишається тільки відкрити базу даних командою:
alter database open;

Збереження копій журналів повторного виконання необхідне створення узгоджених інкрементних гарячих копій бази даних, і навіть можливості відновлення стану бази даних будь-якої миті у минулому.

Після того як ми перевели базу даних в режим archivelog, необхідно задати їй параметри області пакетного відновлення. Перевіримо, чи не задані вони вже запитом:

Select name, value from v$parameter where name like "db_recovery_file_dest%"; якщо не задані то задаємо командами:
alter system set db_recovery_file_dest_size=50G scope=both; задає максимальний розмір області пакетного відновлення та
alter system set db_recovery_file_dest="/storage/recovery_area" scope=both; задає розташування області пакетного відновлення у файловій системі. Створення області пакетного відновлення необхідно для того, щоб rman міг самостійно видаляти застарілі копії, а також відстежувати вільний дисковий простір, що залишився, і попереджати якщо його залишається мало.

Після налаштування екземпляра можна переходити до налаштування самої утиліти rman, для цього підключившись до rman послідовністю команд

Rman connect target user/pass@sid виконуємо команду
show all;

Насамперед конфігуруємо параметри безпеки резервних копій це робиться або параметром CONFIGURE RETENTION POLICY або встановлюється кількість копій які одночасно зберігаються, або вказується період, у який копія вважається актуальною. Встановимо параметр recovery window рівний 7 дням командою:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; увімкнемо автобекап контрл файлу при кожному створенні резервної копії буде створюватися копія контрл файлу:
CONFIGURE CONTROLFILE AUTOBACKUP ON; активуємо оптимізацію щоб rman не створював копії файлів вже існують резервні копії ідентичні існуючій:
CONFIGURE BACKUP OPTIMIZATION ON; і розпаралелімо на 2 канали процес створення резервної копії:
CONFIGURE DEVICE TYPE DISK PARALLELISM 2; Параметри пристрою, на який зберігається інформація, шифрування, стиснення, формат автобекапу контрл файлу та максимальний розмір файлу копії ми не змінюватимемо.

Після цього налаштування залишається тільки створити в операційній системі файли виконання для rman і додати їх до планувальника завдань.

Для воскресіння:

#!/bin/bash export ORACLE_HOME=/u01/11g/ export NLS_LANG=american_america.AL32UTF8 export ORACLE_SID=kagu1251 rman connect target user/pass BACKUP INCREMENTAL LEVEL 0 DATABASE; BACKUP DATAFILE "/oradata/db/admin/kagu/pfile/init.ora.6302012163819"; BACKUP DATAFILE "/u01/11g/network/admin/listener.ora"; BACKUP DATAFILE "/u01/11g/network/admin/tnsnames.ora"; BACKUP DATAFILE "/u01/11g/dbs/spfilekagu.ora"; BACKUP DATAFILE "/u01/11g/dbs/orapwkagu1251";

Для решти днів:

#!/bin/bash export ORACLE_HOME=/u01/11g/ export NLS_LANG=american_america.AL32UTF8 export ORACLE_SID=kagu1251 rman connect target user/pass BACKUP INCREMENTAL LEVEL 1 DATABASE; BACKUP DATAFILE "/oradata/db/admin/kagu/pfile/init.ora.6302012163819"; BACKUP DATAFILE "/u01/11g/network/admin/listener.ora"; BACKUP DATAFILE "/u01/11g/network/admin/tnsnames.ora"; BACKUP DATAFILE "/u01/11g/dbs/spfilekagu.ora"; BACKUP DATAFILE "/u01/11g/dbs/orapwkagu1251";

Для відновлення всієї бази даних після повного зникнення застосовується команда RESTORE DATABASE, після її виконання необхідно синхронізувати дані за допомогою архівних журналів командою RECOVER DATABASE, відновлення відбувається в режимі mount.

Для відновлення конкретного табличного простору необхідно спочатку перевести його в режим OFFLINE командою:

ALTER TABLESPACE user OFFLINE;

Після цього виконати його відновлення та синхронізацію:

RESTORE TABLESPACE user; RECOVER TABLESPACE user; Після завершення перевести його в режим онлайн командою:
ALTER TABLESPACE user ONLINE;

Також можна відкотити базу даних на певний момент часу тому для цього виконується команда:

SET UNTIL TIME "Jan 29 2013 20:00:00";

Це відновлення потрібно робити коли база даних знаходиться в режимі mount, а при відкритті вказати опцію RESETLOGS, щоб не виконувались зміни, збережені в журналах повторного виконання, створені після точки відновлення.

Для спостереження за створеними резервними копіями зручна команда CROSSCHEK, яка дозволяє перевірити наявність резервних копій в області пакетного відновлення та можливість доступу до них. Для тестування файлів резервних копій на логічні чи фізичні помилки використовується команда VALIDATE.



ПОХОДЖЕННЯ СТАТТІ