Меню

Проверете резервното копиране и възстановяване на Oracle RMAN (практически урок)

validate oracle rman backup

Опитайте Нашия Инструмент За Премахване На Проблемите

Как да създадете и проверите резервно копие на Oracle RMAN: Научете с RMAN команди и процес на възстановяване

въпроси и отговори за интервю за тестване на мобилни приложения

В този урок ще обсъдим проверката и тестването на резервните копия на вашата база данни на Oracle. Ще обясняваме концепции като какво, защо и как за резервните копия на базата данни и методи за тестване на архивирането.

Ние ще вземем База данни на Oracle като казус за този урок.

Казус: Тестване на резервни копия на базата данни на Oracle RMAN:

Тестване на архивиране и възстановяване на Oracle RMAN

Какво ще научите:

Процес на валидиране на резервно копие на базата данни на Oracle с помощта на RMAN

Категоризирали сме го в следващите четири раздела

  1. Какво е резервно копие?
  2. Защо архивиране?
  3. Как да архивирате?
  4. Как да тествате / валидирате архивирането на вашата база данни - стратегии за възстановяване?

Прочетете също=> Всичко за тестването на база данни

Какво представлява архивирането на база данни?

Преди да започнем да научаваме повече за архивирането, трябва да разберем най-важния актив на организацията - данните. Като се има предвид, че вашата организация работи на базата данни на Oracle. За да разберете термина „база данни“, можете да се обърнете към Тук серия Oracle Database Testing .

Данните на дадена организация са най-неразделната част от организацията. Помислете за търговия на дребно, банкова компания. Всички те имат огромно количество данни - потребител, система и т.н. Като администратор на база данни, системен администратор или всеки персонал, на когото е възложена задачата да защитава тези данни, трябва да знае колко важни са данните за организацията. Как да се уверя, че данните са винаги достъпни? Архивирайте тези данни.

Архивирането е точно копие на вашата база данни, което може да ви помогне да възстановите данните си в случай на загуба на данни.

Тествайте архивиране на база данни 1

Защо архивиране на база данни?

Помислете за прост случай, при който вашата банкова организация, която разполага с данни за милиони клиенти по отношение на номера на сметки, имена, номинирани, банково салдо и организацията е загубила всичките си данни, как биха реагирали клиентите им на тях? Как би се справила организацията с натиска да загуби толкова много данни? Как биха отговорили на толкова много недоволство на клиентите?

Ето защо правим резервно копие на тези данни, така че в случай на повреда на диск (съхранение), дисковия контролер (контролер за съхранение), ние винаги можем да разчитаме на нашия архив, откъдето можем да го възстановим в базата данни, т.е. файлова система за съхранение и да нямаме клиентите губят някоя от данните си.

Хипотетично казано, да предположим, че има милиони клиенти и всеки от тях извършва милиони транзакции и базата данни случайно се срива и губи данните си, бихме ли помолили всички тези клиенти да въведат отново данните си отново? Как бих се справила със загубата на толкова много данни? Това би било крайно неприемливо.

По подобен начин помислете за телекомуникационна компания, която поддържа милиони клиенти и разполага с всичките им данни относно телефонни номера, адреси, кредит на разположение, чакащи плащания. Ами ако загубим всичките им данни? Компанията е обречена и ще трябва да поеме огромни разходи, които потенциално ще спрат организацията. Със сигурност би било огромна катастрофа.

Как да направите резервно копие на базата данни?

За архивиране на данни в база данни на Oracle имаме няколко метода. Те могат да бъдат класифицирани като физически и логически архиви

Метод # 1)Физически архиви :

  1. 3rdпартийни архиви - като Veritas NetBackup, SAP, IBM Tivoli Manager, EMC, HP
  2. Управлявани от потребителя архиви - Архивиране на база данни с помощта на помощни програми на OS като копиране (windows), cp (Unix)
  3. Oracle Secure Backup
  4. Моята любима и най-предпочитана препоръчителна помощна програма на Oracle - Recover Manager ( RMAN ).

Метод # 2)Логически архиви:

  1. Конвенционални помощни програми за експортиране / импортиране и помощни програми за Datapump. Логическото архивиране е архивиране на логически данни - обекти като таблици, индекси и т.н., които са съставни части на база данни, независимо от местоположението на горните обекти.

За да разберете физическите и логическите структури за съхранение на база данни, към които можете да се обърнете това и тази документация на oracle .

Кой е най-добрият метод за архивиране на база данни?

Всяка от тези стратегии за архивиране има свои собствени плюсове и минуси и няма да се занимаваме твърде много с тях в тази статия.

Трябва да разберем, че освен ако нямате физическо архивиране, просто наличието на логическо архивиране не винаги е безопасно срещу физическа повреда на данните, проблеми със съхранението на хардуера. Наличието на валиден, добър физически архив го прави добра стратегия за архивиране и възстановяване. Винаги се уверете, че имате физическо архивиране на място.

В действителност можем да използваме който и да е от горните методи, но винаги трябва да сме сигурни, че имаме добра стратегия за архивиране и възстановяване, за да избегнем ненужни хълцания по време на работата на база данни. Винаги се препоръчва да тествате своите стратегии за гръб и възстановяване на огледална тестова система, за да можем да предвидим времето, необходимо за стартиране на вашата база данни в случай на непредвидени ситуации.

В тази статия ще се съсредоточим основно върху резервните копия на RMAN. Това ни води до точка да знаем как точно извършваме архивирането.

Команди за архивиране на Oracle RMAN (Oracle Recovery Manager)

Можем да архивираме данни или с помощта на режим на Enterprise Manager (GUI), или чрез подканата от командния ред на OS.

Тествайте архивиране на база данни 2

RMAN е надежден, сложен инструмент, предоставен от Oracle за извършване на архивиране и възстановяване.

RMAN се инсталира автоматично, когато инсталирате базата данни на Oracle, така че не е необходима допълнителна инсталация за използване RMAN .

The 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 или всеки друг инструмент за физическо архивиране може да архивира файлове с данни, да контролира файлове, файлове с параметри, архивирани файлове за повторно регистриране. Файловете, свързани с мрежата, трябва да се архивират ръчно с помощта на помощни програми на OS като 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 MB.

Използвайте 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 или други тестове за архивиране и възстановяване на база данни.

Препоръчително четене

^