Възстановяване на данни

Здравейте, скъпи посетители на сайта okITgo.ru! В настоящата статия искам да говоря повече за възстановяването на данни от бази данни на Oracle. Същността на процеса е доста проста, но ясното разбиране за това е много важно при администрирането на сървъра на база данни на Oracle и всъщност при изпълнение на такава задача като възстановяване на изгубена информация.

Процес на възстановяване на данни: Основни понятия

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

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

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

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

Възстановяване и възстановяване на база данни

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

Формуляри за възстановяване на данни

Примерният сценарий по-горе очерта основите на възстановяването и процеса на възстановяване. Няколко варианта на този скрипт са важни за вашата работа по архивиране и възстановяване.

Разгледайте тези сортове по-подробно:

Възстановяване на устройство с файл с данни: Възстановяване на файл с данни, промяна на приложението (възстановяване)

Възстановяване на носител на файл с данни(често наричано простовъзстановяване на носител) е най-простата форма на извършвано от потребителя възстановяване на данни. Може да се използва за възстановяване на изгубен или повреден текущ файл с данни, файл с параметри (SPFILE) или контролен файл. Също така, този вид възстановяване може да възпроизведе промени, които са били записани в журналите за повторение, но не и във файловете с данни за таблично пространство, което е било взето офлайн без опцията OFFLINE NORMAL. Възстановяването на носител на файлове с данни може да се извърши или с Recovery Manager, или чрез персонализирано архивиране и възстановяване. (За персонализирано архивиране и възстановяване това всъщност е основният наличен метод.)

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

Няколко ситуации ви задължават да извършите възстановяване на медия:

Възстановявате файл с данни от резервно копие.
Възстановявате контролен файл от резервно копие (дори ако всички файлове с данни са актуални).
Файлът с данни се прехвърля офлайн (или от вас, или автоматично от базата данни) без опцията OFFLINE NORMAL.

За да бъде наличен файл с данни за възстановяване на носител, едно от двете изречения трябва да е вярно:

Базата данни, която притежава файла с данни, не трябва да е отворена;

Конкретният файл с данни, който трябва да бъде възстановен, трябва да е офлайн, ако базата данни е отворена.

Файл с данни, който се нуждае от възстановяване на носителя, не може да бъде прехвърлен онлайн, докато възстановяването на носителя не завърши. Базата данни не може да бъде отворена, ако поне един от онлайн файловете с данни се нуждае от възстановяване на носителя.

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

Пълно, непълно и своевременно възстановяване

Пълно възстановяванее възстановяването на базата данни до най-скорошния момент, без да се губи нито една от завършените транзакции. Като цяло, под термина"възстановяване" обикновено се разбира като пълно възстановяване.

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

Възстановяването в определен момент също е единствената опция, ако трябва да извършите възстановяване и откриете, че няма архивиран журнал, обхващащ времето между архивирането, от което е направено възстановяването, и целевия SCN за възстановяването. Без липсващ регистрационен файл нямате запис на актуализации на вашите файлове с данни през този период. Единственият ви избор в този случай е да възстановите базата данни от момента, в който е направено архивирането, до възможно най-късно, което позволява неразделен набор от архивирани журнали, след което изпълнете OPEN RESETLOGS - в този случай, разбира се, всички промени в и след липсващия журнал ще бъдат загубени. (Ако установите, че сте загубили архивираните регистрационни файлове и вашата база данни е все още отворена, очевидно трябва незабавно да направите пълно архивиране, докато можете :-))

Забележка: Ако само едно таблично пространство е претърпяло загуба на данни, имате опцията да извършите възстановяване в даден момент затова таблично пространство вместо цялата база данни. В бъдеще планирам да опиша възстановяването в момента за таблично пространство (съкратено като TSPITR - от англ. TableSpace Point-In-Time Recovery).

Автоматично възстановяване след повреда на инстанция: Възстановяване след авария

Процесът навъзстановяване при сриве специална форма на възстановяване, която възниква веднага щом екземплярът на базата данни се стартира за първи път след срив (или ПРЕКРАТЯВАНЕ НА ИЗКЛЮЧВАНЕ). При възстановяване след авария целта е да се приведат файловете с данни в транзакционно последователно състояние, като се запазят всички завършени транзакции до момента, в който е възникнал сривът.

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

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

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

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

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