Збої та Відновлення

Здрастуйте, шановні відвідувачі сайту okITgo.ru! Продовжуючи тему бекапу та відновлення, хотів би докладніше зупинитися на типових збоях та відновленні, яке необхідне для ліквідації наслідків того чи іншого збою, аварії, краху екземпляра тощо. При плануванні вашої стратегії бекапу та відновлення Ви повинні спробувати передбачити помилки, які виникнуть, і забезпечити створення бекапів, необхідних для відновлення цих помилок. Тоді як існує кілька типів проблем, які можуть перервати нормальну роботу бази даних Oracle або вплинути на операції введення/виводу, лише два з них вимагають втручання DBA та відновлення носія: збій носія та помилки користувача. Аварії екземпляра, проблеми з мережею, збої фонових процесів бд Oracle і збої через виконання операторів (наприклад, вичерпання деякого ресурсу, такого як вільний простір у файлі даних) можуть вимагати втручання DBA, і навіть можуть викликати крах екземпляра бази, але взагалі вони не викликають втрати інформації чи необхідності відновлюватися з бекапу.

Збій Носія

Робота бази після збою носія онлайн журналів змін або контрольних файлів залежить від того, чи захищений онлайн журнал змін або контрольний файлмультиплексуванням(multiplexing), що власне рекомендується. Коли онлайн журнал оновлень або контрольний файл мультиплексовані, несілько копій цих файлів існують у системі. Мультиплексовані файли слід зберігати на різних дисках.

Якщо збій носія пошкоджує диск, що містить одну копію мультиплексованого онлайн журналу змін, база даних зазвичай може продовжувати працюватибез суттєвої перерви. Ушкодження мультиплексованого онлайн журналу змін викликає зупинку роботи БД і може стати причиною безповоротної втрати інформації.

Пошкодження контрольного файлу (хоч мультиплексованого, хоч ні) зупиняє роботу БД, коли вона намагається прочитати або записати в пошкоджений контрольний файл (що відбувається часто, наприклад, для кожної контрольної точки або перемикання журналу).

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

Якщо екземпляр не може писати у файл данихтабличного простору SYSTEM, табличного простору відкату (undo) (якщо бд врежимі автоматичного управління відкатом(automatic undo management mode), що є кращим вибором Релізі 10g), або файл даних табличного простору, що містить активні сегменти відкату (приручному режимі управління відкатом(manual undo management mode)), то база генерує помилку і завершує екземпляр. Усі файли табличного простору SYSTEM і всі файли даних, що містять сегменти відкату, повинні знаходитися в режимі онлайн для правильної роботи бази даних.

Якщо екземпляр не може писати у файл даних, що не входить до переліку вище, результат залежить від того, чи запущена база в режимі ARCHIVELOG .

У режимі ARCHIVELOG база даних записує помилку у файл трасування письменника бази і переводить файл даних, при спробі запису який виникла помилка, в оффлайн-режим. (Всі інші файли даних у табличному просторі, що містить файл даних, залишаються в режимі онлайн.) Ви можете виправити причину помилки, а потім реставрувати і відновити даний табличний простір.

У режимі NOARCHIVELOG фоновийпроцес-письменник бд (database writer background process або DBWR) припиняється і відбувається збій екземпляра, причина проблеми визначає необхідне рішення. Якщо проблема тимчасова (наприклад, контролер диска було вимкнено), то зазвичай достатньо виконати аварійне відновлення, використовуючи файли онлайн журналів змін. У таких ситуаціях екземпляр може бути перезавантажений без вживання відновлення носія. Однак, якщо файл даних пошкоджений, Ви повинні реставруватиузгоджений бекапбази повністю.

Помилки Користувача

Як правило, помилки користувача, такі як видалення таблиці або видалення рядків з таблиці, вимагають одне з наступних рішень:

Реімпорт віддаленого об'єкта, якщо існує підходящий файл експорту, або цей об'єкт, як і раніше, доступний у запасній (standby) бд
Виконання відновлення табличного простору на момент часу (TSPITR) одного або кількох табличних просторів
Повторне введення втраченої інформації вручну, якщо існує їх запис
Повернення бд до минулого стану, використовуючи відновлення бази на момент часу
Використання ретроспективних можливостей Oracle для відновлення від логічного пошкодження шляхом повернення пошкоджених об'єктів у минулий стан

Опції відновлення, доступні для Вас, будуть функцією вашої стратегії бекапу. Наприклад, якщо база працює в режимі NOARCHIVELOG, то у Вас є обмежені можливості відновлення на момент часу.