Разработване на стратегия за аварийно възстановяване на база от данни управлявана от Oracle Database 10g Server


Таблица 5.1 Сравнение между RMAN и Потребителски управляван метод



страница3/4
Дата14.01.2017
Размер0.55 Mb.
#12592
1   2   3   4
Таблица 5.1 Сравнение между RMAN и Потребителски управляван метод

Мениджър на възстановяване (Recovery Manager)

Потребителски управляван метод

Използва Приложно-програмен интерфейс за управление на лентови устройства, така че RMAN работи еднакво добре с над 20 различни приложения за управление на лентови устройства.

Няма поддръжка за Приложно-програмен интерфейс. !


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

Изисква поставяне на табличните пространства в режим на архивиране за да извърши архивиране

Извършва инкрементални архиви, които резервират само тези блокове с данни, които са били променени след последно направения архив.

Архивира всички блокове а не само променените.

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

Не поддържа проверка за грешки.

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

Включва всички блокове с данни, независимо дали съдържат данни или не.

Може да складира много важна справочна информация , като:

  • Схема на базата данни в определен период от време

  • Кои файлове се нуждаят от архивиране

  • Кои файлове нямат актуален архив от даден брой дни

  • Кои архиви могат да бъдат изтрити, защото са остарели или не биха могли да се използват за възстановяване.

  • Настоящите RMAN настройки

Не включва никакви справочни функционалности.

Съхранява RMAN скриптове в каталога за възстановяване.

Изисква заделяне на пространство за съхранение на скриптовете и поддръжка.

Позволява лесно дублиране на продукционна база данни с цел създаване на тестова или резервна база данни.

Изисква следваните на сложна процедура за създаване на тестова или резервна база данни.

Изпълнява проверка за да установи дали архива на деска или лента е на разположение.

Тази проверка трябва да се извърши от потребителя.

Изпълнява автоматична паралелизация на операциите по архивиране или възстановяване.

Може да се направи ръчно с помощта на команди на операционната система, като предварително установим кои файлове искаме да архивираме или възстановим.

Тества дали файловете могат да бъдат архивирани или възстановени, без в действителност да извършва архивиране или възстановяване.

Изисква от нас действително да възстановим архива за да можем да установим дали е възможно да се възстанови.

От така изложените преимущества и недостатъци на единият и другият вариант, за решаването на едната част от задачата „да се осигури резервираност на данните” най подходящ е избора за използване на RMAN като средство за архивиране и възстановяване. За решаването на втората част от задачата „да бъде възстановен нормалният ритъм на работа в най-кратки срокове” остава единственият избор – създаване на резервна база от данни (“standby database”) конфигурирана в Data Guard. Това ще ни осигури, в случай на отпадане на основната база да можем да активираме резервната база данни и по този начин да възстановим работата на потребителите и приложенията.

Това решение задължително води до няколко изисквания , които трябва да се покрият за да реализираме стратегията ни.

1. Основната база трябва да работи в ARCHIVELOG режим

2. Да се вземе пред вид каква да бъде репликацията


  • Синхронна – наречена още репликация в реално време, може да се използва, когато няма толеранс за евентуални загуби на данни. Данните на резервният сървър постоянно трябва да съответстват на данните от продукционната база и да отразяват всички извършени транзакции.

  • Асинхронна – наречена още отложена репликация. При този тип репликция транзакциите се извършват на основната база данни и се репликират по-късно към резервната база данни. Докато резервната база данни не се обнови с отложените транзакции, съхранявани в специална опашка или на отделен дисков масив(по добрия вариант), данните в него се различават от данните в основната база.

3. Типове архиви.

  • Пълен архив – Както подсказва името, архивиране на всеки блок от данни на базата.

  • Инкрементален архив – За разлика от пълният , архивират се само тези блокове от данни , които са променени от последния пълен архив. Наричан още и архив от първо ниво.

  • Комбинация от двата типа архиви


Глава III. Разработвне на стратегия за архивирне и възстановяване на данни при възникване на аварийна ситуация в среда управлявана от Oracle DB 10g Server.

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



1. Анализ и избор на стратегия.

Съществуват различни видове стратегии в Oracle за да се осигури резервираност на данните и тяхното възстановяване в случай на кризисна ситуация. Но като цяло те могат да бъдат разделени в три отделни групи.



  • Стратегия основана на студен бекъп

  • Стратегия основана на RMAN(Recovery Manager)

  • Стратегия основана на “standby server”

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

1.1 Стратегия основана на студен бекъп.

Следващата фигура 1.1 показва възможността за възстановяване на базата данни с помощта на студен бекъп и прилагане на архивните възстановяващи логове.





Фигура 1.1 Схема на възстановяване на база данни при студен бекъп и прилагане на възстановяващи архивни логове

Тази стратегия гарантира възможността за възстановяване на базата данни , но недостатъкът и е, че изисква, както беше споменато по-рано, свободно дисково пространство, поне толкова , колкото е големината на самата база данни. Също така, всички архивни възстановяващи логове от момента на пълният архив до момента на следващия създаден пълен архив трябва да се съхраняват на сигурно място, което също води до необходимост от достатъчно дисково пространство. Друг съществен недостатък е и времето за възстановяване на копието на архива, както и прилагането на архивните възстановяващи логове.



1.2 Стратегия пълен горещ RMAN архив с последващи инкрементални (диференциални) архив.

Следващата фигура показва възможна стратегия за архивиране с помощта на инкрементален (диференциален) архив от първо ниво.





Фигура 1.2. Схема на възстановяване на база данни от пълен „горещ” архив плюс инкрементални архиви

В примера посочен в схемата, графикът за архивиране е следният:



  • Неделя – пълен архив

  • Понеделник – Събота – инкрементлен: В понеделник се архивират промените направени от последният пълен архив до момента. Вторник се архивират промените направени от понеделник насам и т.н. до събота.

При инкременталният (диференциален) архив, RMAN архивира всички блокове с данни променени от последният инкрементален или пълен архив. Например при диференциален архив от първо ниво, RMAN установява кой архив от първо ниво е най-последен и архивира блоковете с данни модифицирани от последният такъв архив. Ако не съществува инкрементален архив, RMAN архивирва блоковете променени от последният пълен архив насам. Ако не съществува пълен архив, RMAN осъществява пълен архив.

Предимството от този начин на архивиране е, че се редуцира необходимото пространство за архива, както и времето за архивиране. Недостатък е, че в случай на кризисна ситуация примерно в петък, трябва да се възстанови първо пълният архив след това всеки инкрементален архив един по-един до момента на възникване на проблема, което ще увеличи времето за възстановяване.



1.3 Стратегия пълен „горещ” архив с последващ комулативен инкрементален бекъп.



Фигура 1.3. Схема на възстановяване на база данни от пълен „горещ” архив плюс инкрементален комулативен архив

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



1.4 Избор.

От посочените до този момент варианти един добър вариант за реализация на стратегия се явява вариантът с пълен архив в неделя и комулативни архиви от понеделник до събота, извършвани на един от двата сървъра – продукционният или резервният. Всички архивни логове ще се записват на ленти всеки час от понеделник до неделя, което ще ни гарантира минимална загуба на архивни логове. Предимствата на Oracle Data Guard 10g ще ни даде възможността за бързо превключване от продукционният сървър към резервният сървър, което в съчетание с RMAN бекъп стратегия ще ни осигури максимална резервираност на данните и минимално време за възстановяване на работният процес. На фигура 1.4 по-долу е изложена конфигурацията на стратегията за резервираност на данните.





Фигура 1.4 Конфигурацията на стратегията за резервираност на данните

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





Фигура 1.5 Промяната в конфигурацията след отпадане на продукционният сървър

Глава IV. Внедряване и тестване на разработената стртегия в условията на реална екплоатция.
1. Конфигуриране на RMAN

RMAN е средство работещо от командният ред и се инсталира като част от инсталацията на стандартна базата данни. Трябва да се отбележи , че RMAN е само команден интерфейс към базата данни – действителният бекъп се осъществява от сървърен процес на Oracle базата данни.

RMAN може да бъде стартиран от командният ред на машината на която е разположена базата данни по следният начин:

C:\>rman target /

Recovery Manager: Release 10.2.0.1.0 - Production on ╧Є └яЁ. 25 08:48:39 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

connected to target database: MYDB (DBID=2561178296)



RMAN>

Първият ред е този на който въвеждаме командата за изпълнение а следващите редове са резултат от изпълнението на командата. В резултат имаме върнат промпт в RMAN, който е индикация за това, че RMAN е готов за по-нататъшна работа. Тук извикваме RMAN на сървъра на който е разположена базата данни и се свързваме към сървъра използвайки акаунт принадлежащ на групата ORA_DBA на операционната система. Това ни позволява да се свържем към базата данни (as sysdba) без да е необходимо да използваме парола.Това може да се настрои като укажем параметъра SQLNET.AUTHENTICATION_SERVICES = (NTS) в sqlnet.ora файла.

От този момент RMAN може да бъде стартиран в два режима – с каталог и без каталог. Преди, архивната информация и скриптовете се съхраняваха в друга база данни позната като RMAN каталог. Сега RMAN съхранява архивната информация в контролният файл на базата която резервираме. Каталожният режим е по-гъвкав, но изисква поддръжка на отделна база на отделна машина. Режима без каталог има своето предимство именно за това че не се нуждае от отделна база , но предава повече отговорност на контролният файл. Ще използваме режим без каталог, с оглед на това че няма да е необходимо да се поддържа още една отделна база данни.

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

„show all”.

RMAN> show all;

using target database control file instead of recovery catalog

RMAN configuration parameters are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'E:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\SNCFMYDB.ORA'; # defult



RMAN>
Тези настройки са направени по подразбиране, както може да се види и ще ни гарантират едно консистентно копие на нашата база данни , но за нуждите ни ще трябва да променим някои от тях. Тъй като RMAN има свой собствен команден език, по-нататък ще се фокусирам само върху тези, които ще променя и някой за които ще е нужно да се дискутират .

  1. Политика на съхранение (RETENTION POLICY): това ще инструктира RMAN да пази един архив назад. Всички други назад са кандидати за изтриване. В нашият случай няма да променяме нищо за този параметър, тъй като стратегията ни е да се прави един пълен архив всеки ден.

  2. Тип на устройството по подразбиране (DEFAULT DEVICE TYPE): стойностите мога да бъдат “disc” и “sbt” (system backup to tape). Идеята ни е да архивираме на локален диск и след това с приложение за архивиране на линтови устройства да качиме архива. За това по подразбиране ще го оставим да бъде на диск.

  3. Конфигуриране на контролният файл да се архивира автоматично или не (CONFIGURE CONTROLFILE AUTOBACKUP OFF ). Когато е настроен на “ON”, RMAN ще архивира контролният файл и сървърният параметричен файл всеки път когато извършваме архивиране.

  4. По подразбиране, RMAN автоматично генерира служебно име за този архив и го съхранява в “flash recovery area”. Ще преконфигурираме тази стойност, така че да съхранява архива на посочена от нас директория.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:\backup_db\ctl_sp_%F';

new RMAN configuration parameters:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:\backup_db\ctl_sp_%F';

new RMAN configuration parameters are successfully stored



RMAN>

  1. Стойността "%F" указва на RMAN да добвя в името на архивният файл идентификационният номер на базата данни и времеви маркер на направеният архив

  2. Device Type Format: Това специфицира мястото и името на архивните файлове. Необходимо е да се специфицира формата за всеки канал. Стйността „%U” ще генерира уникални имена за всеки архивен файл. Стойността MAXPIECESIZE указва максималната големина за всеки архивен файл.

  3. Паралелизъм (PARALLELISM): Този атрибут указва на RMAN колко сървърни процеса да се използват за създаването на архива.

Всеки от посочените по-горе параметри може да бъде променен използвайки командите извикани с командата „show all”. Например може да променим автоматичното архивиране на контролният файл да бъде изключено с помощта на командата

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP OFF;

using target database controlfile instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
new RMAN configuration parameters are successfully stored

RMAN>
2. RMAN скрипт за автоматично архивиране.

До сега изяснихме някои особени параметри нужни за конфигуриране на RMAN бекъп, сега можем да направим скрипта който автоматично да се изпълнява за да архивира базата данни. Скрипта ще архивира базата данни, ще проверява дали архива може да бъде възстановен, и ще изтрива всички стари архиви съобразно политиката за съхранение на архивите и накрая ще качва новосъздаденият архив на ленти. В зависимост от това върху каква операционна система ще се стартира скрипта, ще използваме инструмента на дадената ОС за изпълнение на задачи (crontab на UNIX/LINUX или Windows Scheduler на Windows ) за периодично изпълнение на създаденият скрипт. Самият архив ще се прави на локален диск и след като приключи ще бъде копиран върху ленти.

Скрипта за създаване на пълен архив ще запазим във файл наречен “rman_backup_level0.rcv” със следните параметри:



CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP OFF;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'd:\temp\ctl_sp_bak_L0_%F.BAK';

CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK to 1;

CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT 'D:\temp\DATA_L0_%U';

CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT 'D:\temp\DATA_L0_%U';

CONFIGURE MAXSETSIZE TO UNLIMITED;

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:\temp\SNCFMYDATA.ORA';
crosscheck backupset;

crosscheck copy;

delete noprompt expired backup;

delete noprompt expired copy;

delete noprompt obsolete;

sql 'alter system archive log current';

backup as compressed backupset incremental level=0 tag=LEVEL0 database include current controlfile plus archivelog;

backup current controlfile for standby format='D:\temp\stb_ctl_file_L0_%U.BAK';

sql 'alter system archive log current';
host 'copy D:\oracle\product\10.2.0\admin\MYDB\pfile\init.ora D:\temp\';

host 'copy D:\oracle\product\10.2.0\db_1\database\PWDMYDB.ora D:\temp\';

host 'copy D:\oracle\product\10.2.0\db_1\NETWORK\ADMIN\tnsnames.ora D:\temp\';
restore database validate from tag=LEVEL0;

restore controlfile validate from tag=LEVEL0;
exit;

Този скрипт първо извършва конфигурация на някои от опциите, след това извършва проверка за наличните бекъпи и съгласно зададения период за съхранение изтрива ненужните (тези които са „EXPIRED”) бекъп файлове и започва да създава бекъп на базата данни плюс контролният файл, като създава и един „standby” контролен файл (в случай , че трябва да се възстанови резервната „standby” база). На следващта стъпка се копират важните конфигурационни файлове и накрая се стартира процеса за валидирне на направения бекъп дали ще може да се възстанови.

Скрипта в този случай не може да се изпълнява директно в Windows (за разлика от това в Linux/Unix) и за това се стартира от bat файл.

Сега вече може да изпълним bat файла и в директорията, която е посочена в настройките за място на архива ще започне да се генерират файловете на RMAN архива.



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

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

3. Тестове за възстановяване чрез RMAN backup

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



  1. Възстановяване на повреден или липсващ файл с данни.

  2. Възстановяване на повреден или липсващ online възстановяващ лог

  3. Възстановяване на повреден или липсващ контролен файл

3.1. Възстановяване на повреден или липсващ файл с данни.

Случай А. Възстановяване на липсващ файл с данни

За да симулирам тази ситуация, ще спра базата данни и след това ще изтрия някой файл с данни, и след това ще се опитам да вдигна базата данни отново, което би трябвало да генерира съобщение за грешка .


C:\> sqlplus / as sysdba
SQL*Plus: Release 10.2.0.3.0 - Production on ╧Є └ту. 8 16:16:53 2008
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production

With the Partitioning, OLAP and Data Mining options


SQL> shutdown immediate; --- спирам базата

Database closed.

Database dismounted.

ORACLE instance shut down.




Сподели с приятели:
1   2   3   4




©obuch.info 2024
отнасят до администрацията

    Начална страница