Сривове и възстановяване

Здравейте, скъпи посетители на сайта okITgo.ru! Продължавайки темата за архивиране и възстановяване, бих искал да се спра по-подробно на типичните повреди и възстановяване, което е необходимо, за да се премахнат последствията от определена повреда, авария, срив на екземпляр и т.н. Когато планирате своята стратегия за архивиране и възстановяване, трябва да се опитате да предвидите грешките, които ще възникнат, и да се уверите, че създавате резервните копия, необходими за възстановяване от тези грешки. Въпреки че има няколко типа проблеми, които могат да прекъснат нормалната работа на база данни на Oracle или да повлияят на I/O операциите, само два от тях изискват намеса на DBA и възстановяване на носител: повреда на носител и грешка на потребителя. Сривовете на екземпляра, проблемите с мрежата, сривовете на фоновите процеси на базата данни на Oracle и сривовете, дължащи се на изпълнение на оператор (например изчерпване на някакъв ресурс, като например свободно място във файл с данни), може да изискват намеса на DBA и дори да доведат до срив на екземпляра на базата данни, но като цяло те не причиняват загуба на информация или необходимост от възстановяване от резервно копие.

Неизправност на носителя

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

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

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

Ефектът от грешка при запис на файл с данни зависи от това в кое таблично пространство се намира файлът с данни.

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

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

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

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

Потребителски грешки

Обикновено потребителски грешки като изтриване на таблица или изтриване на редове от таблица изискват едно от следните решения:

Повторно импортиране на изтрит обект, ако съществува подходящ файл за експортиране или ако обектът все още е наличен в резервната база данни
Извършване на възстановяване в момент на време (TSPITR) на едно или повече таблични пространства
Ръчно повторно въвеждане на изгубена информация, ако има запис за тях
Връщане на база данни към предишно състояние с помощта на възстановяване в даден момент
Използване на ретроспективните възможности на Oracle Database за възстановяване от логическа повреда чрез връщане на повредени обекти в минало състояние

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