і при резервуванні і архівуванні баз даних. Резервування бази даних краще всього проводити в «холодному» вигляді, коли перед резервуванням БД закривається. Таке резервування найкраще виконувати в нічний час, коли користувачів можна відключати від бази. Однак у багатьох випадках цей варіант неприйнятний. По-перше, бази даних зараз нерідко досягають в обсязі сотень і тисяч гігабайт, тому їх копіювання вимагає занадто багато часу, і навіть ночі для цього не вистачить. Блокувати ж доступ до бази на тривалий час можуть дозволити собі деякі. По-друге, нерідко СУБД працюють в режимі on-line (наприклад, на серверах Internet), і відключення їх в принципі неможливо.
Щоб нівелювати проблеми копіювання баз даних, виробники систем резервування поставляють спеціальні агенти для конкретних СУБД. Більшість агентів розраховане на підтримку таких СУБД, як Oracle, Informix, Sybase. У свою чергу розробники потужних СУБД забезпечують свої продукти програмними інтерфейсами резервування або навіть окремими утилітами резервування. На жаль, поширені системи резервування підтримують обмежену кількість основних СУБД зважаючи екзотичності інших (в сенсі вузькості ринку). На жаль, самі виробники СУБД не дуже-то прагнуть заповнити цю прогалину. До того ж величезна кількість мережевих додатків спирається на власні бази даних, знайти для них агенти резервування також може виявитися непросто.
Найбільш популярний підхід до резервування активних БД полягає в тому, що в певний момент створюється повна копія бази. Усі наступні звернення до бази (у момент резервування) або кешируются, або заносяться на диск за допомогою переадресації. Після завершення копіювання ці оновлення вносяться в БД. Іноді кешируются не оновленої, а старі дані. Очевидно, щоб зберегти цілісність даних, БД повинна стійко функціонувати в момент резервування. Певні проблеми може доставити резервне копіювання звичайних користувальницьких файлів, якщо в момент резервування вони блоковані (відкриті для запису). Більшість систем резервування нижнього рівня не можуть обробляти їх і пропускають ці файли. Проте в даний час багато систем середнього і старшого рівня мають модулі, за допомогою яких вони можуть копіювати відкриті файли. Технологія резервування відкритих файлів аналогічна тому, як це реалізовано для СУБД, тобто за рахунок кешування старих даних або оновлень.
Глава 2. ORACLE DATA GUARD
.1 Резервні бази даних під керуванням Oracle Data Guard
Після того, як база даних наповнена інформацією, у адміністраторів баз даних (DBA) виникає природне бажання захистити дані від втрати, навіть якщо це не передбачалося спочатку при побудові інформаційної системи. Найпростіший спосіб - періодично копіювати файли бази або вивантажувати дані з таблиць програмними засобами. Ці методи відносяться до «холодного» і логічному резервуванню. Холодним воно називається, так як користувачі при цьому не працюють з базою даних і служби, через які вони працюють, «погашені». Якщо резервування потрібно виконувати так, щоб не створювалося перешкод роботі користувачів, такий тип резервування називається гарячим. Для логічного резервування зазвичай використовують утиліту експорту інформації, яка поставляється, наприклад, у складі ПЗ компанії Oracle (# «justify"> Вся інформація бази даних зберігається в файлах, число яких рідко змінюється в процесі роботи. Кілька кори...
