Преглед на първоначалните компоненти

1.Преглед на първоначалните компоненти

Oracle архитектурата включва определен брой първоначални компоненти, които са показани на фигура 1.1 и дискутирани по-долу:

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

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

1.2 Oracle инстанция

Една Oracle база се състои от набор от файлове на операционната система съдържащи данни вкарани от потребителите или от приложенията, както и структурна информация за самата база наречена “метаданни”. Тази информация се съхранява перманентно в тези файлове. Но за да може да извикаме даден изглед или да променим данни съхранени в базата Oracle трябва да стартира набор от процеси, наречени фонови процеси, както и да задели памет (SGA-System Global Area), която да бъде използвана по време на работата на базата данни. Съвкупността от фонови процеси и заделената памет за Главна Системна област изграждат една Oracle инстанция. За това преди да може една база от данни да бъде използвана , Oracle инстанцията трябва да бъде стартирана. Когато Oracle инстанция не е стартирана , тогава данните в базата данни са запазени , но няма да бъдат достъпни за потребителите или за приложенията.

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

1.3 Oracle Database

Главната цел на БД е да съхранява и да обработва свързана информация. Една Oracle база от данни има логическа и физическа структура. Физическата структура на базата от данни е множество от файлове на операционната система в базата от данни. Физическата структура на една Oracle БД включва три типа файлове: Control-ни файлове, Data файлове и Online redo log файлове. Тези файлове осъществяват реално физическото складиране на информацията в БД. Файловете на Oracle Database Server-а се използват за да се подсигури цялостта на данните, както и че могат да бъдат възстановени в случай на проблеми в инстанцията.

• 
  Потребителски дефинирани характеристики, които позволяват на файловете с данни автоматично да се разширяват , когато пространството в базата данни не достига.
  
• 
  Един или повече файлове с данни формират една логическа структура наречена таблично пространство.
  

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

Oracle сървърът също така използва и други файлове, които не са част от БД

• 
  Параметричният файл дефинира характеристиките на една Oracle инстанция. Например, те съдържат параметър за размера на структурата на паметта в SGA
  
• 
  Password файла автентицира потребителските привилегии да стартират и спират една Oracle БД.
  
• 
  Archive redo log файловете са offline копия на online redo log файловете които може да са ни необходими за възстановяване на базата в случай на проблем
  

spfileSID.ora

STARTUP

По правило за да стартирате и отворите една база, трябва да се свържете като SYSDBA и да изпълните STARTUP командата. Oracle сървърът, тогава ще прочете файла с инициализационните параметри и ще подготви инстанцията в съответствие с параметрите съхранени във файла.

Всъщност съществуват два типа инициализационни параметри:

• 
  Статичен параметричен файл, PFILE обикновено с референция към initSID.ora
  
• 
  Постоянен параметричен файл на сървъра, SPFILE, обикновено с референция към spifileSID.ora
  

• 
  Списък с параметрите на инстанцията
  
• 
  Името на базата с която се асоциира инстанцията
  
• 
  Разпределението на структурата на паметта на SGA
  
• 
  Името и мястото на контролните файлове
  
• 
  Какво да прави с Online redo log файлове
  
• 
  Информация за undo сегментите
  

PFILE е текстов файл, който може да бъде редактиран използвайки стандартен текстов редактор. PFILE може само да се чете , докато инстанцията е стартирана. Ако файла е модифициран тогава инстанцията трябва да бъде спряна и рестартирана за да може промените в параметрите да бъдат ефективни. По принцип PFILE се намира в $ORACLE_HOME\dbs и е именуван initSID.ora

Един SPFILE , новост в Oracle 9i, е бинарен файл. Този файл трудно може да бъде модифициран ръчно и трябва винаги да бъде от страната на сървъра. След като е създаден файла той се обслужва от Oracle сървъра. Ако го модифицирате ръчно можете да го направите неизползваем. SPFILE притежава способността да извършва промени постоянно в базата по време на спиране и стартиране на базата. Също така притежава способността за самостоятелно оптимизиране на стойностите на параметрите, записани във файла.

SPFILE се създава от PFILE като се използва командата CREATE SPFILE. Тази команда изисква SYSDBA привилегии за да може да бъде изпълнена. Тази команда може да бъде изпълнена преди или след стартиране на инстанцията.

Където:

• 
  SPFILE-NAME: име на SPFILE което да бъде създадено
  
• 
  PFILE-NAME: име на PFILE , който трябва да бъде използван за да се създаде SPFILE. PFILE трябва да съществува от страна на сървъра.
  

Когато стартираме БД , трябва да изберем степен (ниво) на което да стартира. Следващите примери описват различните степени на стартиране на инстанцията.

1. 
   Стартиране на инстанцията (STARTUP NOMOUNT)
   

Стартирането на една инстанция включва следните задачи:

• 
  Прочитане на инициализационния файл от $ORACLE_HOME\dbs в следния ред:
  
  • 
    Първо spfileSID.ora
    
  • 
    Ако не е открит, тогава spfile.ora
    
  • 
    Ако не е открит, тогава initSID.ora
    

• 
  Установяване на SGA
  
• 
  Стартиране на фоновите процеси
  
• 
  Отварят се alertSID.log и trace файловете
  

2. 
   Монтиране на базата (STARTUP MOUNT)
   

• 
  Преименуване на файловете с данни
  
• 
  Включване или изключване на online redo log файловете в архивен режим
  
• 
  Пълно възстановяване на базата
  

1. 
   Асоцииране на базата с предишни стартирани инстанции
   
2. 
   Открива и отваря контролен файл указан в параметричния файл
   
3. 
   Прочитане на контролните файлове за да открие името и статуса на дата фаловете и online redo log файловете. Всъщност през това време не се извършва никаква проверка за това дали съществуват файлове с данни и online redo log файловете.
   

Нормално работеща БД означава ,че една инстанция е стартирана, базата е монтирана и отворена. С нормално работеща БД всеки валиден потребител може да се свърже към БД и да изпълнява типични операции за достъп до данни.

Отварянето на една БД включва следните задачи:

• 
  Отваря online data файловете
  
• 
  Отваря online redo log файловете
  

По време на това финално ниво, Oracle сървърът проверява дали всички файлове с данни и online redo log файлове могат да бъдат отворени и проверява за цялостта на базата данни. Ако е необходимо, SMON фоновите процеси инициират възстановяване на инстанцията.

От изложените до дук основни елементи изграждащи една база данни става ясно,че за да може да бъде създаден един ефективен архив на данните е нужно да се архивират следните файлове:

• 
  Контролните файлове
  
• 
  Файловете с данни
  
• 
  Архивираните възстановяващи логове (в случай , че базата е в ARCHIVELOG режим)
  
• 
  Сървърният параметричен файл (spfile)
  
• 
  Password файла
  
• 
  Мрежовите конфигурационни файлове на Oracle сървъра(въпреки че те лесно биха могли да бъдат създадени отново)
  

При Oracle са възможни два основни типа за възстановяване в зависимост от това дали се архивират или не възстановяващите(redo log files) логове:

1. 
   NOARCHIVELOG режим в Oracle
   

Когато базата данни работи в ARCHIVELOG режим, в този случай освен, че може да бъде възстановена цялата база , може да бъдат извършени възстановяващи операции и само върху повредените файлове с данни и да се приложи информацията от възстановяващите логове от момента на архивирането да момента на останалата част от базата данни. Тази процедура минимизира времето за възстановителни и възобновителни операции. Частично възстановяване от този тип може да бъде извършвано , докато базата данни не е достъпна. Алтернативно, засегнатите от процеса таблични пространства могат да бъдат поставени в режим „offline“ и възстановяването да бъде извършено с останалата налична част на базата данни. Oracle значително подобри възможността за прецизиране на процеса на възстановяване, като осигури възможност за възобновяване и възстановяване на отделни блокове с данни вместо на цели файлове с данни. Фигура 2.2 по-долу, илюстрира архивирането и възстановяването с архивирани възстановяващи логове.

Очевидно е че възстановяващите логове са от изключителна важност . За първи път Oracle дава възможност за анализиране на тези файлове с помощта на инструмента LogMiner, въведен в Oracle 8i. От Oracle 9i нататък LogMiner е достъпен през графичният потребителски интерфейс на Oracle Enterprise Manager и осигурява анализ на логовете за всички типове данни. Ако възстановяващите логове са повредени , LogMiner вече може да прочита при необходимост повредените записи, за да даде възможност след възникването на повреда от този тип да се анализира евентуалното отражение върху транзакциите.



Фигура 2.2 илюстрира архивирането и възстановяването с архивирани възстановяващи логове.

Глава II. Проучване и анализ на средствта за архивиране и възстановяване.
1. Архивирне със средствата на ОС (User Managed)

Възможностите на Операционната система в това отношение са много ограничени. В Windows съществува инструмент за архивиране и възстановяване наречен ntbackup.exe, който е много удобен със своя графичен потребителски интерфейс. Освен това, този инструмент много лесно може да бъде свързан и към лентово устройство. Това му дава изключително предимство, тъй като архивите вместо да се записват първо на локален диск могат директно да бъдат „качвани” на ленти, с което ще се спести време и място за архивиране , но дори и в този случай това остава единственото му предимство. Защо? Ако трябва да се архивират файловете на една Oracle база данни то това трябва да стане само ако базата данни е спряна. Причината, е че ако базата е отворена и по време на архивирането някой блок на файла с данни бъде модифициран, тогава копието на този блок ще бъде неконсистентно и от тук невъзможността да бъде направено възстановяване от архива. Ако използваме командите на операционната система за копиране на данни ( „copy” в Windows и „cp” в UNIX/Linux) и не искаме да спираме базата, тогава варианта в този случай е да се поставят табличните пространства в специален режим „режим за архивиране” преди да бъдат копирани файловете асоциирани към съответното таблично пространство. Когато табличното пространство е в такъв режим, контролният номер на промяната (SCN), който е маркиран в хедъра на всеки файл с данни в съответното таблично пространство, е „замразен” докато табличното пространство не бъде извадено от специалният режим. Допълнително, всеки път когато един блок с данни в табличното пространство бъде модифициран, непроменените блокове се копират във възстановяващите логове (противно на това че само променените редове би трябвало да се копират, когато табличното пространство не е в „режим за архивиране”). Това ще предизвика увеличавани на броя на възстановяващите логове, което е главният недостатък на този начин за архивиране. Този начин е крайно труден и дори непрепоръчителен в сравнение с това да бъде спряна базата за да бъде направено пълно архивно копие. Иначе казано: със средствата на операционната система сме ограничени до това, да направим така нареченият „студен” архив.

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

--поставя USERS табличното пространство в режим за архивиране

Горният скрипт трябва да бъде изпълнен през “sqlplus” инструмента на Oracle. Този вариант за архивиране е подходящ единствено за сравнително малки по обем бази данни и при които съществува възможността за спиране на базата за известен период(например вечер). Но дори и в този случай ще дойде момент, в който базата ще нарастне и ще трябва да се търси алтернативен вариант. Тъй като големината на такъв вид архив е равен на големината на базата данни или казано по-просто ако файловете на базата данни e с общ размер 20 GB, то и архивното копие ще е 20 GB. За големите по обем бази данни този вариант е абсолютно неприемлив.

За първи път Recovery Manager (RMAN) е въведен при Oracle 8 и осигурява архивиране и възстановяване чрез управление от сървъра. RMAN дава възможност да се извършат и проследят операциите по архивиране и възстановяване. RMAN извършва следното:

• 
  Архивира един или повече файлове с данни на диск или лента.
  
• 
  Архивира архивните възстановяващи логове на диск или лента.
  
• 
  Възстановява файловете с данни от диска или лентата.
  
• 
  Възобновява и прилага архивираните възстановяващи логове, за да извърши възстановяване.
  
• 
  Процесите на прочитане и запис на различните Oracle файлове, които са в процес на архивиране, автоматично стават паралелни.
  

RMAN използва католога също така, за да извършва така наречените допълващи архивирания. RMAN ще архивира само блоковете на базата данни, които са били променени от момента на последното архивиране. Когато RMAN архивира само отделни променени блокове от базата данни при бази, в които се променя малък процент от данните в големи таблици, общото време за архивиране и възстановяване може да бъде значително намалено. При Oracle Database 10g RMAN може да приложи допълнително архивиране към определен архив на базата данни. Освен това при тази версия на базата данни производителността при допълващо архивиране е подобрена. RMAN съхранява метаданните за своите операции в контролният файл на базата данни върху която работи, и като опция, в отделна схема в Oracle база като катоалог за възстановяване.

Друго основно предимство, което RMAN предлага е свързано с това, че чрез него реализирането на „горещи” и „online“ архиви е значително улеснено. Освен това RMAN намалява допълнителните ресурси, необходими за създаването на онлайн архиви.

Преди RMAN (в Oracle 7) „горещото” архивиране се извършваше след подаване на команда ALTER TABLESPACE BEGIN BACKUP за таблично пространство, чиито файлове с данни трябва да бъдат архивирани. Архивирането на файловете с данни ставаше с помощта на командите на операционната система и с подаване на командата ALTER TABLESPACE END BACKUP. Oracle продължава да записва блоковете на файловете с данни, докато те са в процес на архивиране и съответно не съществуват ограничения за действията на потребителите. Това означава, че архивите на файловете с данни могат да съдържат блокове от различни моменти във времето, тъй като самият процес на архивиране отнема определено време, през което е възможно записване на блокове във файлове с данни.

Да разгледаме следния пример. Процесът на операционната система, който чете даден файл с данни, прочита първия блок на опреционната система в рамките на Oracle блока, изграден от два блока на операционната система, и записва този блок на лентата в момент Т. В момент Т+1 Oracle обновява блок на базата данни във файла с данни. И двата блока на операционната система във файла с данни на диска вече се отчитат за актуализирани към момент Т+1. След това процесът на операционната система за архивиране прочита и архивира втория блок на операционната система като блок към момента Т+1. Архивът на файла с данни вече съдържа смесени блокове на базата данни. Двата блока на операционната система, които изграждат Oracle блока, са архивирани спрямо различен момент от време – първият блок на операционната система е архивиран към момент Т, докато вторият е архивиран към момент Т+1.

За да се справи с тази потенциална несъвместимост, Oracle 7 архивираше автоматично включената допълнителна възстановяваща информация с цел да коригира ситуации от този тип за всяко таблично пространство, за което е подаден команда ALTER TABLESPACE BEGIN BACKUP. В Oracle Database 10g с подаването на командата ALTER DATABASE се задава за всички таблични пространства в базата данни режим на така нареченото „горещо” архивиране.

В Oracle 8, RMAN е Oracle процес, а в следващите по-нови версии на базата данни RMAN чете и записва Oracle блокове, а не блокове на операционната система. Докато RMAN архивира даден файл с данни, в този файл могат да се записват блокове, а не блокове на операционната система в рамките на Oracle блока. Това отстранява възможността от поява на смесени Oracle блокове в архивите на даден файл с данни и поради това не се налага да се използва командата ALTER TABLESPACE и допълнителната възстановяваща информация.

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

В Oracle Database 10g RMAN се използва, за да поддържа автоматизираното дисково базирано архивиране. Дисково базираните стратегии имат едно преимущество пред лентите: те дават възможност за произволен достъп до всички данни, като по този начин могат да се архивират или възстановят само промените. RMAN се занимава с изтриването на архивните файлове, които повече не са необходими. И накрая с RMAN архивите е възможно да се възстановят индивидуални блокове в случай на повреда в блоковете на даден файл с данни.

3. Защита на данните чрез “standby server”

За първи път функционалността за физическа резервна база данни е въведена в Oracle 7.3, за да се осигури създаването на резервно копие на базата данни. В Oracle 9i тази концепция е допълнително разширена и вече включва и поддръжка на логическа резервна база данни. Този подобрен набор от функции е наречен Oracle Data Guard.

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



Фигура 3.1 Схема на работа на резервната база данни („standby database”)

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

Във версиите преди Oracle Database 10g, когато резервната база данни се използва за генериране на справки, архивната възстановяваща информация от основният сървър не може да бъде прилагана. Възстановяването може да продължи, когато резервната база данни бъде затворена за достъп на потребителите. Този фактор има важно значение за времето, което ще бъде необходимо при прекъсването на работата за възстановяването с помощта на резервната база данни. Ако основният сървър откаже, докато резервната база данни е отворена за генериране на справки, то преди тази резервна база данни да бъде приведена в работен режим , трябва да бъде приложена архивната възстановяваща информация от основната база , която е била акумулирана, докато към резервната база данни са изпращани заявки. Това прилагане на архивната възстановяваща информация увеличава продължителността на прекъсването на работата. За това трябва да се прецени предимството от използването на резервната база данни за генериране на справки спрямо времето за възстановяване и продължителността на прекъсването на работата, възникващо поради необходимостта да се приложи архивната възстановяваща информация на резервната база. Oracle Database 10g за първи път въвежда функция, работеща в реално време и позволява възстановяващите данни да бъдат прилагани върху резервната база в момента на тяхното получаване.

Преди Oracle Database 10g, след като веднъж дадена резервна база данни е била отворена за достъп в режим за четене и писане, подобно на ситуацията с достъпа само за четене, тази база не можеше повече да бъде използвана като резервна база, от което следва и че не би могло в последствие да се възобнови прилагането на възстановяващата архивна информация. Резервната база данни трябваше да бъде отново клонирана от основната база данни дори ако инцидентно е отворена за работа в режим за четене и писане.

Сега с новата функционалност на Oracle Database 10g наречена Data Guard стана възможно смяната на ролите на продукционната среда със „standby” сървъра. Именно, продукционната среда да стане „standby” сървър а „standby” сървъра да стане продукционен, без това да се отрази много във времето. Освен това, зависимостта между двете бази данни може да се настрои в такъв режим, че загубата на данни да бъде нулева. Oracle Data Guard е един много ефективен начин за управление, наблюдение и автоматизация на софтуерната инфраструктура за създаване и поддържане на „standby” бази данни, както и за защита на данните от грешки, аварии и повреди.

Всяка Data Guard „standby” база данни може да се намира на отдалечени на стотици и дори хиляди километри от продукционната база данни или да бъдат в същият град, същият квартал и дори в същата сграда. Ако продукционната база данни стане недостъпна заради планирано или непланирано прекъсване, Data Guard може да превключи всяка „standby” база данни в ролята на продукционна база, по такъв начин се минимизира времето на неработоспособност и се избягват възможностите за загуба на данни. Освен това Data Guard е идеално допълнение към Oracle Real Application Clusters (RAC) и може да се използва в комбинция с други Oracle решения като Oracle Fleshback и Oracle Recovery Manager (RMAN).

В някои ситуации , бизнесът не може да си позволи да изгуби данни на каквато и да е цена. В други ситуации, дадени приложения може да изискват максимално бързодействие на базата данни и може да се толерира потенциална загуба на данни. Data Guard в Oracle 10g ни предоставя три режима на защита за да бъдат удовлетворени различните изисквания.

• 
  Максимална защита (Maximum Protection) – Този режим на работа предлага най-високо ниво на защита на данните. Данните синхронно се предават на „standby” базата от продукционната база и всяка транзакция в продукционната база се записва едва тогава , когато възстановителната информация за нея е записана на поне един „standby” сървър конфигуриран в този режим. Ако последният „standby” сървър конфигуриран в този режим по някаква причина стане недостъпен, всички процеси на продукционната база спират също. Така този режим гарантира нулева загуба на данните, дори и в случай на много и различни проблеми в даден момент.
  

• 
  Максимална наличност (Maximum Availability) – този режим е подобен на режима максимална защита с нулева згуба на данните. Разликата е, че ако „standby” сървърът отпадне поради някаква причина (например комуникационен проблем), процесите на продукционният сървър ще продължат да вървят. Когато проблем бъде отстранен „standby” базата данни автоматично се синхронизира с продукционната.
  

• 
  Максимална Производителност (Maximum Performance) – Този режим не предлага нулева защита на данните, но това е за сметка на производителността в сравнение с останалите два режима на работа. В този режим възстановяващата информация се пренася асинхронно към „standby” сървърът , което ще рече, че „commit” операциите на продукционният сървър не изчакват за потвърждение от „standby” сървърът.
  

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

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

Експорт/Импорт инструментите се използват обикновенно за следните задачи:

• 
  Архивиране и възстановяване на малки бази данни (Ако са големи по удачно е да се използва RMAN)
  
• 
  Преместване на данни между Oracle бази данни на различни платформи(например от Windows на UNIX)
  
• 
  Реорганизация на данните, за да се елиминира фрагментация на данните.
  
• 
  Надстройване на базата данни към по нова версия на Oracle
  

Преди да започнем да изграждаме една стратегия е редно да си отговорим на въпроса „Какво искаме да съхраним и каква загуба можем да понесем?”. Това ще ни помогне да определим най-точната стратегия. Задачата на дипломната работа определя и отговора на този въпрос, а именно:

Да се състави, разработи и тества стратегия за архивиране и възстановяване на база данни под управлението на Oracle Database 10g Server, имаща за цел да се осигури резервиране на данните, както и да бъде възстановен нормалният ритъм на работа в най-кратки срокове с минимална загуба на данните.

Всички варианти, разгледани до тук предлагат определен тип защита срещу евентуална загуба на изключително важни данни – или на цялата база данни.

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

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

На фиг 5.1 могат да се видят предимствата от използване на RMAN пред потребителски управляван архив със средствата на ОС.