Меню

Перевірка резервного копіювання та відновлення Oracle RMAN (практичний посібник)

validate oracle rman backup

Спробуйте Наш Інструмент Для Усунення Проблем

Як створити та перевірити резервну копію Oracle RMAN: Дізнайтеся за допомогою команд RMAN та процесу відновлення

запитання та відповіді на інтерв’ю у maven для досвідчених

У цьому підручнику ми обговоримо перевірку та тестування резервних копій бази даних Oracle. Ми пояснимо такі поняття, як, що, чому і як щодо резервних копій бази даних та методи перевірки резервної копії.

Ми візьмемо База даних Oracle як приклад для цього підручника.

Приклад: Тестування резервних копій баз даних Oracle RMAN:

Тестування резервного копіювання та відновлення Oracle RMAN

Що ви дізнаєтесь:

Процес перевірки резервної копії бази даних Oracle за допомогою RMAN

Ми класифікували його на наступні чотири розділи

  1. Що таке резервна копія?
  2. Чому резервне копіювання?
  3. Як зробити резервну копію?
  4. Як протестувати / перевірити резервну копію бази даних - стратегії відновлення?

Також читайте=> Все про тестування баз даних

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

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

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

Резервна копія - це точна копія вашої бази даних, яка може допомогти вам відновити ваші дані у разі втрати даних.

Перевірка резервного копіювання бази даних 1

Чому резервне копіювання бази даних?

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

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

Гіпотетично кажучи, припустімо, що є мільйони клієнтів, і кожен з них виконує мільйони транзакцій, і база даних випадково виходить з ладу і втрачає свої дані, чи не попросимо ми всіх цих клієнтів повторно ввести свої дані ще раз? Як би впорався із втратою такої кількості даних? Це було б вкрай неприйнятно.

Подібним чином, розглянемо телекомунікаційну компанію, яка підтримує мільйони клієнтів і має всі їхні дані щодо номерів телефонів, адрес, кредиту, що очікують на оплату. Що робити, якщо ми втратимо всі їх дані? Компанія приречена і мала б нести величезні витрати, потенційно зупинивши організацію. Це, безумовно, була б величезна катастрофа.

Як зробити резервну копію бази даних?

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

Спосіб No1)Фізичні резервні копії :

  1. 3рдпартійні резервні копії - такі як Veritas NetBackup, SAP, IBM Tivoli Manager, EMC, HP
  2. Керовані користувачем резервні копії - Резервне копіювання бази даних за допомогою утиліт ОС, таких як copy (windows), cp (Unix).
  3. Безпечне резервне копіювання Oracle
  4. Моя улюблена та найбільш улюблена рекомендована утиліта Oracle - Recover Manager ( RMAN ).

Спосіб No2)Логічні резервні копії:

  1. Звичайні утиліти експорту / імпорту та утиліти Datapump. Логічне резервне копіювання - це резервне копіювання логічних даних - об'єктів, таких як таблиці, індекси тощо, які є складовими бази даних, незалежно від розташування вищевказаних об'єктів.

Щоб зрозуміти фізичну та логічну структуру зберігання бази даних, до якої ви могли б звернутися це і ця документація оракула .

Який найкращий метод резервного копіювання бази даних?

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

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

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

У цій статті ми в основному зупинимося на резервних копіях RMAN. Це призводить до того, що ми знаємо, як саме ми виконуємо резервне копіювання.

Команди резервного копіювання Oracle RMAN (Oracle Recovery Manager)

Ми можемо зробити резервну копію даних або за допомогою режиму Enterprise Manager (GUI), або за допомогою командного рядка ОС.

Перевірка резервного копіювання бази даних 2

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

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

RMAN Середовище складається з двох компонентів:

1) Цільова база даних (база даних, яку ви б створили, зробили відновлення та

два) Клієнт RMAN, який є клієнтом, який інтерпретує команди користувача та виконує їх від імені користувача під час підключення до цільової бази даних.

Проста команда для підключення до бази даних за допомогою RMAN така:

C:Usersxyz> rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Sun Sep 28 17:32:48 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1361070653) RMAN>

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

У цьому прикладі ми маємо справу з базою даних з іменем ORCL .

Ми зробимо резервну копію даних, які належать до бази даних ORCL.

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

Для цього ми можемо скористатися спеціальним каталогом з іменем db_recovery_file_dest який служить резервним місцем. Визначте розмір цього параметра за допомогою db_recovery_file_dest_size що позначає розмір цього місця резервного копіювання.

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

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

RMAN або будь-який інший інструмент фізичного резервного копіювання може створювати резервні копії файлів даних, файлів керування, файлів параметрів, архівованих файлів журналів переробки. Файли, пов’язані з мережею, потрібно резервно копіювати вручну за допомогою утиліт ОС, таких як cp або copy.

Для резервного копіювання бази даних ми використовуємо:

'Резервна база даних' - це так просто. Отже, почнемо робити резервні копії нашої бази даних ORCL.

Оскільки ми вже підключилися до цільової бази даних (ORCL), ми запускаємо команду “резервна база даних”.

Перевірка резервного копіювання бази даних 3

RMAN> backup database; Starting backup at 05-OCT-14 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=198 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF input datafile file number=00002 name=D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF input datafile file number=00005 name=D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF input datafile file number=00003 name=D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF input datafile file number=00004 name=D:APP1SUNTYADAORADATAORCLUSERS01.DBF channel ORA_DISK_1: starting piece 1 at 05-OCT-14 channel ORA_DISK_1: finished piece 1 at 05-OCT-14 piece handle=D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP tag=TAG20141005T162412 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:04:27 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 05-OCT-14 channel ORA_DISK_1: finished piece 1 at 05-OCT-14 piece handle=D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NCSNF_TAG20141005T162412_B3293806_.BKP tag=TAG20141005T162412 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04 Finished backup at 05-OCT-14

Тут ми спостерігаємо, що резервне копіювання всіх пов’язаних файлів бази даних - файлів даних, контрольних файлів, spfile (файл параметрів) завершено. Операція резервного копіювання зайняла близько 4 хвилин 27 секунд (час, що минув). Це невелика тестова база даних, що містить лише 5 файлів даних, тому для резервного копіювання знадобилося зовсім менше часу.

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

Щоб знати деталі щодо щойно створеної резервної копії, ми виконаємо:

RMAN> резервне копіювання списку;

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

List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 4 Full 1.39G DISK 00:04:23 05-OCT-14 BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP List of Datafiles in backup set 4 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF 2 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF 3 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF 4 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUSERS01.DBF 5 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 5 Full 9.58M DISK 00:00:06 05-OCT-14 BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NCSNF_TAG20141005T162412_B3293806_.BKP SPFILE Included: Modification time: 05-OCT-14 SPFILE db_unique_name: ORCL Control File Included: Ckp SCN: 9705762 Ckp time: 05-OCT-14

Ця резервна копія розміщується в розташуванні DB_RECOVERY_FILE_DEST, яке визначено як D: APP1 SUNTYADA FLASH_RECOVERY_AREA

SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string D:app1suntyadaflash_recovery_area db_recovery_file_dest_size big integer 3912M

Розмір, визначений для нашого місця резервного копіювання, становить 3912 МБ.

Використовуйте VALIDATE для перевірки файлів бази даних та резервних копій:
RMAN> БАЗА ДАНИХ, ЩО ДОЗВІЛЬНІ

Перевірте резервну копію RMAN

Як ми можемо перевірити або перевірити, чи можемо ми відновити нашу базу даних під час будь-якої кризи?

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

Все залежить від того, як ви розробили резервні копії, інтервали, за якими планується резервне копіювання, чи берете ви повне резервне копіювання та маєте додаткові резервні копії.

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

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

Використовуйте команду BACKUP VALIDATE для перевірки резервних файлів:

Команда лише для перевірки фізичної пошкодження:

RMAN> РЕЗЕРВНА ДІЙСНІСТЬ
БАЗА ДАНИХ
АРХІВЕЛОГ ВСЕ;

Команда для перевірки фізичної та логічної корупції:

RMAN> РЕЗЕРВНА ДІЙСНІСТЬ
ПЕРЕВІРИТИ ЛОГІЧНЕ
БАЗА ДАНИХ
АРХІВЕЛОГ ВСЕ;

RMAN> РЕЗЕРВНА БАЗА ДАНИХ ДЛЯ ВАЛІДАТИ ;

Тестуйте резервну копію бази даних 5 нових

Starting backup at 05-OCT-14 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF input datafile file number=00002 name=D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF input datafile file number=00005 name=D:APP1SUNTYADAORADATAORCLEXAMPLE01.DB input datafile file number=00003 name=D:APP1SUNTYADAORADATAORCLUNDOTBS01.DB input datafile file number=00004 name=D:APP1SUNTYADAORADATAORCLUSERS01.DBF channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45 List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 1 OK 0 13430 106376 9708800 File Name: D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 75217 Index 0 12706 Other 0 5015 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 2 OK 0 21161 95409 9708826 File Name: D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 23010 Index 0 21760 Other 0 29429 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 3 OK 0 0 5762 9708826 File Name: D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 5760 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 4 OK 1125 228 5765 9528788 File Name: D:APP1SUNTYADAORADATAORCLUSERS01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 2295 Index 0 39 Other 0 3198 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 5 OK 0 1687 10498 9585679 File Name: D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 4760 Index 0 1261 Other 0 2788 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 List of Control File and SPFILE =============================== File Type Status Blocks Failing Blocks Examined ------------ ------ -------------- --------------- SPFILE OK 0 2 Control File OK 0 608 Finished backup at 05-OCT-14

Як ви можете помітити вище, статус кожного файлу - ' в порядку ”, Що означає, що вони придатні для використання та можуть бути використані для відновлення файлів у будь-який момент часу.

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

Використовуйте команду RESTORE для перевірки резервної копії:

RMAN> ВІДНОВИТИ ДАНУ БАЗУ ДАНИХ;
ВІДНОВИТИ АРХІВЕЛОГ ВСІ ДІЯЛЬНІ;

RMAN> ВІДНОВИТИ ПОПЕРЕДЖЕННЯ БАЗИ ДАНИХ;

Перевірка резервного копіювання бази даних 6

Starting restore at 05-OCT-14 using channel ORA_DISK_1 List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 4 Full 1.39G DISK 00:04:23 05-OCT-14 BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP List of Datafiles in backup set 4 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF 2 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF 3 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF 4 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUSERS01.DBF 5 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF List of Archived Log Copies for database with db_unique_name ORCL ===================================================================== Key Thrd Seq S Low Time ------- ---- ------- - --------- 367 1 366 A 02-OCT-14 Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLARCHIVELOG2014_10_05O1_MF_1_366_B32925TJ_.ARC Media recovery start SCN is 9684060 Recovery must be done beyond SCN 9704654 to clear datafile fuzziness Finished restore at 05-OCT-14

Висновок

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

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

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

Повідомте нас, якщо у вас є запитання, пов’язані з Oracle або будь-яким іншим тестуванням резервного копіювання та відновлення бази даних.

Рекомендована література

^