Стратегії резервного копіювання і відновлення баз даних SQLBase

Зміст



Введення


Стратегія відновлення повинна займати належне місце, щоб запобігти випадковій втраті даних. Можливості по відновленню даних повинні знаходиться на тому ж високому рівні, що й кошти резервного копіювання.


Відновлення баз даних – це відповідь адміністраторів даних на закон Мерфі. Бази даних неминуче пошкоджуються або втрачаються з різних причин: через системні або апаратних збоїв, помилок операторів, неправильних або неприпустимих даних, програмних помилок, комп'ютерних вірусів та природних катаклізмів.


Оскільки будь-яка організація сильно залежить від своїх баз даних, необхідно дотримуватися правильної стратегії, щоб швидко і точно відновити базу даних після її втрати або пошкодження. Крім того, оскільки відновлення даних повинне бути поставлено настільки ж добре, як і їх резервування, ця стратегія також повинна включати в себе узгоджену систему резервного копіювання даних.


Нижче описані основні можливості, які повинні бути реалізовані для забезпечення точного відновлення:



  1. Резервне копіювання даних в обсязі, достатньому для повернення бази даних до узгодженого стану, незалежно від її поточного стану.
  2. Реєстрація транзакцій та змін бази даних.
  3. Відновлення бази даних з достатньою кількістю можливостей для її приведення у вихідне робочий стан, з мінімальними втратами даних і часу.

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


Резервне копіювання баз даних


Що таке резервна копія?


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


Резервна копія складається з бази даних (файл з розширенням BKP) і всіх log-файлів, необхідних для приведення BKP-файлу до узгодженого станом під час резервування. Необхідно пам'ятати, що незалежно від типу виконуваного резервного копіювання резервовані дані повинні бути непошкодженими. Тому рекомендується перевіряти базу даних ("check database") перед резервним копіюванням і проводити цю процедуру тільки тоді, коли база даних знаходиться в стійкому стані.


Резервування може бути здійснено або в режимі онлайн, використовуючи ПО резервного копіювання SQLBase (сервер SQLBase запущений, а користувачі підключені до бази даних), або в режимі оффлайн з допомогою стандартних команд операційної системи, тобто використовуючи COPY (відключений сервер SQLBase або демонтована база даних), а потім команду "set nextlog". Найбільш часто використовуваний варіант – резервування в режимі онлайн, оскільки для більшості операцій дуже складно знайти відповідний час, коли всі користувачі відключені від усіх баз даних, з тим щоб можна було коректно завершити роботу сервера SQLBase або демонтувати всі бази даних. Це необхідно, тому що сервер SQLBase утримує базу даних у вигляді відкритого файлу, починаючи з моменту підключення першого процесу і закінчуючи демонтажем бази даних або вимиканням сервера SQLBase.


Що таке log-файли, навіщо вони потрібні, і чому від них не можна відмовитися


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


Слід звернути увагу, що база даних складається з файлу з розширенням DBS і log-файлів. У разі видалення log-файлів база даних стає недоступною для використання! За замовчуванням SQLBase автоматично видаляє log-файли після їх резервування, або коли вони не потрібні для відновлення після збоїв або відкату. Це поведінку можна змінити, встановивши для бази даних параметр LOGBACKUP в положення ON з допомогою інтерфейсу SQLTalk. При такому положенні параметра log-файли зберігаються до тих пір, поки не створюється їх резервна копія за допомогою спеціальної команди "backup logs". Це єдиний спосіб видалення log-файлів. Цей параметр повинен бути в положенні ON, якщо необхідно застосувати команди "backup database" або "backup logs". І навпаки, не потрібно встановлювати цей параметр у цьому положенні, якщо немає намірів використовувати команду "backup logs" або впроваджувати можливість "rollforward" (відновлення з повтором всіх завершених транзакцій) в стратегію відновлення, тобто якщо передбачається робити тільки "моментальні знімки".


Максимальний розмір log-файлів, що створюються для кожної бази даних, можна вказати, задавши параметр LOGFILESIZE за допомогою SQLTalk (за умовчанням цей розмір – 1 МБ). Спочатку log-файли мають мінімальний розмір, а потім вони ростуть в обсязі до вказаної межі. Якщо за допомогою SQLTalk встановити параметр LOGFILEPREALLOC в положення ON, то є можливість створювати для кожної бази даних шаблони log-файлів максимального розміру. Якщо необхідно багато log-файлів, можна встановити їх максимальний обсяг великим (скажімо 5 МБ) і заздалегідь призначити розмір файлів. Це призведе до зменшення кількості операцій введення / виведення, необхідних для створення нових файлів або дописування існуючих.


Log-файли можуть бути видалені тільки після застосування команди "release log" або "backup logs", і якщо вони не є "блокованими". Log-файл виявляється блокованим в наступних випадках:



  1. Поточна транзакція здійснює запис в цей log-файл. Блокування може бути знята з цього файлу лише після завершення або відкоту транзакції.
  2. Передостання контрольна крапка була створена при використанні даного чи попереднього log-файлу. Наприклад, якщо контрольна крапка була створена в 6.log, то цей log-файл і всі наступні будуть блоковані. У цьому випадку блокування можна зняти за допомогою команди "release log".
  3. Параметр LOGBACKUP знаходиться в положенні ON, а у даного log-файлу ще немає резервної копії. Блокування з нього може бути знята тільки за допомогою команди "backup logs". Виконання команди "backup snapshot" ніяк не відіб'ється на блокуванні цього log-файлу.

Log-файли, для яких була зроблена резервна копія, повинні регулярно видалятися вручну. Зберігаються тільки log-файли, що мають пряме відношення до BKP-файлу в області резервного копіювання. Наприклад, якщо в якийсь день створюється резервна копія у вигляді моментального знімка, то всі попередні резервні копії log-файлів можуть бути видалені. Будьте уважні: ці файли можуть займати значний обсяг дискового простору.


Резервне копіювання в режимі онлайн


Перевага цього методу полягає у відсутності необхідності переривати роботу користувачів, підключених в цей момент до бази даних. Це особливо важливо для операцій, що вимагають цілодобового доступу до бази даних. Формат резервного копіювання в режимі онлайн має вигляд:


Існує два основних варіанти резервування в режимі онлайн. Перший відповідає використанню команди "backup snapshot" (закінчений сам по собі), і другий – послідовному застосуванню команд "backup database "," release log "і" backup logs "(вони всі необхідні для узгодженого резервування).


Незалежно від обраного варіанту, резервне копіювання складається з наступної послідовності кроків:


– Створення BKP-файлу в обраній області резервного копіювання (backup database);
– Оновлення самих останніх log-файлів, оскільки в них міститься вся інформація про поточний резервування (release log);
– Копіювання всіх належних розблокованих log-файлів, що передують поточному log-файлу, в обрану галузь резервного копіювання (backup logs).
У разі використання методу моментальних знімків (backup snapshot) всі ці кроки виконуються автоматично.


При виконанні резервування пунктом призначення даних може служити клієнтський комп'ютер або сама мережа. Це вказується в ключі "directory-name" команди резервного копіювання. Також необхідно добре уявляти собі різницю між ключами "on server" і "on client" цієї команди. При використанні ключа "on client" всі дані і log-файли будуть поміщені в зазначений каталог певного комп'ютера (навіть якщо це мережевий сервер). Використання ключа "on server" призведе до резервування прямо на сервері без попереднього збереження даних на клієнтському комп'ютері. Це може призвести до значного виграшу в швидкості резервного копіювання і скорочення мережевого трафіку!


Якщо використовується ключ "on client", тобто дані зберігаються на клієнтському комп'ютері, каталог повинен бути заданий повним локальним шляхом або у вигляді мережевого диска, наприклад, C: SQLBASEBACKUPSDB1 (локальний шлях) або F: BACKUPSDB1 (мережевий диск). Однак, при застосуванні ключа "on server" вказується диск повинен бути локальним для сервера, а не мережевим. Якщо використовується сервер Novell, то шлях до потрібного каталогу повинен бути зазначений у форматі сервера Novell. Наприклад, якщо резервне копіювання бази даних здійснюється в каталозі:


SERVER1SYS:SQLBASEBACKUPSDB1


моментальний знімок бази даних DB1 може бути зроблений таким чином:


BACKUP SNAPSHOT FROM DB1 TO SQLBASEBACKUPSDB1 ON SERVER;


Необхідно пам'ятати про те, що не обов'язково мати доступ на запис або підключення до сервера або каталогу, де зберігаються дані. Сервер може без жодних проблем зберегти резервні копії у своєму кореневому каталозі, якщо йому так було зазначено. Тому слід бути уважними при завданні їхнього пункту призначення! Також не робіть помилку, поміщаючи резервні копії в підкаталог самої бази даних. При видаленні бази даних (перед відновленням) видаляється весь її каталог з усіма підкаталогами. У цьому випадку з резервними копіями можна розпрощатися.


Метод моментальних знімків


Створення моментальних знімків (команда backup snapshot) – найпростіший метод резервного копіювання баз даних. У цьому випадку копіюються база даних і log-файли, необхідні для відновлення бази даних до узгодженого стану. Перед резервуванням log-файлів проводиться їх оновлення, що дозволяє включити в резервну копію поточний активний log-файл. У цьому варіанті резервного копіювання потрібно одна команда для резервування даних і одна для їх відновлення. Зазвичай цей метод застосовується один раз увечері, перед резервним копіюванням сервера на магнітну стрічку, і, може бути, один раз протягом дня. Недолік цього методу полягає в тому, що створення моментальних знімків дуже великої бази даних може вимагати значних витрат часу, і, крім того, варіанти відновлення обмежені поверненням бази даних в стан на момент формування останнього моментального знімка. Будь-які зміни, зроблені після даного знімка, будуть втрачені.


Використання послідовності Backup Database, Release Log і Backup Logs


Цей метод резервного копіювання даних трохи більш складний, але гнучкість відновлення коштує додаткових зусиль. Він вимагає резервного копіювання бази даних, розблокування log-файлу (оскільки той містить інформацію про поточну резервної копії), а потім резервування log-файлів. Увага! Ніколи не робіть резервної копії тільки однієї бази даних без log-файлів. Цей метод резервного копіювання дозволяє зрідка резервувати базу даних разом з її log-файлами, після чого регулярно створювати резервні копії тільки одних log-файлів, наприклад, кілька разів на день. Це дозволяє провести відновлення бази даних, а потім використовувати можливість "rollforward" log-файлів для відновлення роботи, виконаної протягом дня. Те, наскільки часто створюються резервні копії log-файлів, залежить від обсягу доступного простору на диску і від того, яку кількість даних користувач може собі дозволити втратити. Зауважимо: накопичення log-файлів може привести до дуже швидкого заповнення диска. Такий підхід особливо зручний для великих баз даних, оскільки резервне копіювання файлу бази даних, що віднімає багато часу, виконується рідко, а періодичне створення резервних копій log-файлів можна виконати досить швидко. Недоліком методу є скупчуванню log-файлів до їх резервування.


Сегментоване резервування баз даних перевищують 2 ГБ


У минулому будь-яку базу даних SQLBase розміри більше 2 ГБ було необхідно розбивати на частини. Починаючи з SQLBase версії 7.5.0, це обмеження було піднято для баз даних на всіх операційних системах, за винятком сімейства Novell. Тепер їх розмір може зростати до 256 ГБ без необхідності розбиття. Втім, це обмеження діє тільки для DBS-файлу, а не тимчасових файлів або з розширенням. Bkp. Щоб справитися з таким обмеженням, було запроваджено новий метод сегментованого резервного копіювання.


Настройте контрольний файл і покладіть в той же каталог, де зберігаються резервні копії. Не потрібно вносити будь-які зміни в оператори резервного копіювання або запущені програми. Сервер SQLBase знаходить контрольний файл в цільовому каталозі і сегментує резервну копію відповідним чином. Контрольний файл має розширення. Bcf, а його ім'я збігається з назвою резервованій бази даних. Для створення цього файлу можна використовувати будь-який редактор текстових файлів (наприклад, notepad.exe).


Контрольний файлі мають такий вигляд:


FILEPREFIX префікс
DIR каталог, куди поміщається резервна копія сегмента
SIZE розмір в МБ


Можна вказати декілька операторів DIR, щоб розбити базу даних на сегменти, кожний з яких менше 2 Гбайт. Зауважимо, що сумарний обсяг, що задається всіма операторами SIZE, повинен бути досить великим, щоб дозволити зробити резервну копію всієї бази даних. Наприклад:


FILEPREFIX MIKE
DIR C:BACKUPSMIKE SIZE 1000
DIR C:BACKUPSMIKE SIZE 1000
DIR C:BACKUPSMIKE SIZE 500


дозволяє створити три файли в каталозі C: BACKUPSMIKE:


MIKE.1 1 ГБ
MIKE.2 1 ГБ
MIKE.3 0,5 ГБ


Зверніть увагу на те, що ці файли створюються, тільки якщо база даних вимагає стільки місця. У наведеному вище прикладі, якщо б розмір бази даних становив лише 1,8 ГБ, то були б створені лише два сегменти: MIKE.1 і MIKE.2 розміром 1 ГБ і 0,8 ГБ, відповідно.


Яке програмне забезпечення слід використовувати для проведення резервного копіювання


Можна використовувати: надається компанією Gupta інтерфейс SQLTalk для виконання команд, показаних вище; продукт SQLConsole (використовує виклики C / API), щоб планувати створення резервних копій; власне програмне забезпечення, яке при резервуванні враховує всі можливі особливості конкретної системи, наприклад, проводить перевірку бази даних перед резервним копіюванням.


SQLConsole – Цей продукт поставляється компанією Gupta і, завдяки своїм чудовим можливостям моніторингу, дозволяє проводити за розкладом створення резервних копій, включаючи перевірку бази даних і оновлення статистики. Цей досить складний продукт володіє великим набором налаштувань для виконання резервного копіювання.


Поради з резервного копіювання


Вище були розглянуті основні моменти та рекомендації щодо проведення резервного копіювання в режимі онлайн. Зробимо їх короткий огляд:



  1. Виконуйте перевірку бази даних ("check database") перед її резервуванням. Якщо перевірка виявила помилки в базі даних, не записуйте її резервну копію поверх непошкодженою копії.
  2. Якщо не передбачається створити моментальний знімок, перевірте послідовність резервного копіювання, тобто порядок проходження команд "" backup database "," release log "і" backup logs ".
  3. Щоб заощадити час, по можливості використовуйте ключ "on server"!
  4. При використанні ключа "on server" на сервері Novell, шлях до цільового каталогу повинен бути зазначений у форматі сервера Novell, а не у вигляді мережевого диска.
  5. Не знімайте НІЯКІ log-файли з поточного каталогу їх зберігання, що задається твердженням logdir = в конфігураційному файлі сервера під назвою sql.ini (або затвердження dbdir =, якщо logdir = не визначено).
  6. Періодично видаляйте з області резервного копіювання старі log-файли, щоб звільнити простір на диску. Не можна прати файли, пов'язані з поточним BKP-файлу. Безпечним є видалення з області резервного копіювання будь-яких log-файлів, які були створені раніше поточного BKP-файлу.
  7. Якщо параметр LOGBACKUP знаходиться в положенні ON і використовується команда "backup snapshot", log-файли не будуть розблоковані. Щоб добитися цього, виконайте команду "backup logs".
  8. Не розміщуйте резервні копії в підкаталог самої бази даних.
  9. Якщо під час створення резервної копії у вигляді моментального знімка була зроблена перезавантаження комп'ютера клієнта, то при спробі повторного резервування бази даних може з'явитися повідомлення про тому, що резервне копіювання вже знаходиться в процесі виконання. Це може відбутися при підключенні до сервера до завершення попереднього сеансу. Виник ускладнення можна подолати, завершивши перерваний сеанс за допомогою SQLConsole або перезапуску сервера SQLBase.

Резервне копіювання в режимі оффлайн


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


Для створення резервних копій DBS-файлу бази даних і всіх log-файлів з її каталогу, використовуйте команди або утиліти операційної системи (наприклад, команду "copy" чи кошти ARCServe). Якщо параметр LOGBACKUP знаходиться в положенні OFF, log-файли копіюватися не будуть. Однак, якщо він знаходиться в положенні ON, необхідно повідомити сервер SQLBase, чи були log-файли резервовані чи вони залишаться "блокованим". Це можна зробити за допомогою команди "nextlog" з арсеналу інтерфейсу SQLTalk від Gupta. Для цього потрібно бути приєднаним до бази даних. Використовується наступний формат:


SET NEXTLOG [ціле число]


Заданий число вказує наступний резервований log-файл. Наприклад, якщо останніми в архів були відправлені резервні копії 4.LOG і 5.LOG, потрібно виконати команду "set nextlog 6".


Недолік резервного копіювання в режимі оффлайн полягає в необхідності демонтажу бази даних або відключення сервера SQLBase. Це відбувається через те, що з моменту першого підключення сервер SQLBase виступає по відношенню до бази даних як абонента запису, і цей зв'язок не розривається до тих пір, поки не буде демонтована база даних або відключений сервер. Це означає, що всі користувачі повинні бути від'єднані, щоб демонтувати базу даних або відключити сервер SQLBase. Пошук відповідного часу або від'єднання користувачів, які забули завершити сеанс перед відходом з роботи, можуть перетворитися на справжню проблему!


Відновлення бази даних


Що таке відновлення


Тут описуються різні варіанти відновлення бази даних до узгодженого стану на основі вибраних параметрів резервного копіювання.


Комплект відновлення складається з резервних копій BKP-файла і пов'язаних з ним log-файлів. BKP-файл даремний без асоційованих log-файлів. Процес відновлення, по суті, проходить в три етапи:



  1. Скопіюйте BKP-файл у каталог бази даних.
  2. Скопіюйте log-файли в каталог бази даних.
  3. Запустіть двоходовий (redo і undo) процес rollforward (відновлення з повтором всіх завершених транзакцій) щодо нового DBS-файлу.

Команда відновлення має наступний формат:


У разі використання команди "restore snapshot", подальші дії не потрібні, оскільки всі етапи відновлення будуть виконані автоматично. При виборі варіанту "restore database" після відновлення бази даних потрібно виконати команду "rollforward". Слід зазначити, що, як і у фазі резервного копіювання, при використанні ключа "on server" (при якому час відновлення значно скорочується) на сервері Novell, шлях до цільового каталогу повинен бути зазначений у форматі сервера Novell, а не у вигляді мережевого диска. Процес rollforward полягає у відновленні всіх змін, зроблених після резервування бази даних, щоб привести її в узгоджене стан. Log-файли містять інформацію про всі транзакції, як успішних, так і тих, для яких був зроблений відкат. У процесі rollforward звернення до log-файлів відбувається двічі. Під час проходу "redo" SQLBase локалізує початкову точку всіх транзакцій і застосовує всі успішні транзакції до даної резервної копії. У проході "undo" відбувається звернення всіх транзакцій, для яких проводився відкат. В кінці процесу відкоту база даних знаходиться в повністю узгодженому стані без незавершених транзакцій. Команда "rollforward" має наступний формат:


При використанні команди "rollforward to backup" буде відновлена вся робота, здійснена аж до моменту створення резервної копії бази даних. Це еквівалентно виконанню команди "restore snapshot". При цьому не відновлюються ніякі додаткові log-файли, які могли бути резервовані після створення вихідної резервної копії.


Команда "rollforward to time" дозволяє відновлювати дані до певного моменту часу. Це дуже добре підходить для відкоту значного обсягу помилково зроблених змін. Наприклад, якщо який-небудь новий необережний програміст вилучив половину бази даних і зафіксував цю зміну, то її можна відновити до стану на момент видалення за допомогою резервної копії та процесу rollforward.


У результаті команди "rollforward to end" обробляються всі log-файли з послідовними номерами, починаючи з першого файлу від моменту створення резервної копії. У цьому випадку відновлюється максимально можливий обсяг роботи. Після обробки останнього log-файлу з'явиться повідомлення про те, що наступний log-файл не може бути знайдений. Це нормально! Просто виконайте команду "rollforward end", щоб завершити відновлення і процес rollforward.


Зверніть увагу, що необхідно мати і послідовно використовувати ВСІ log-файли, щоб відкат був успішним. Якщо будь-які log-файли втрачені, операція rollforward буде зупинена в очікуванні пропущених файлів. Якщо це можливо, можна застосувати команду "restore logs", щоб зробити потрібні log-файли доступними, а потім використовувати команду "rollforward continue", щоб продовжити процес. Якщо який-то з необхідних log-файлів недоступний, застосуйте команду "rollforward end" для завершення процесу. База даних буде відновлена тільки з урахуванням останнього обробленого log-файлу.


Рекомендації по відновленню

Пара рад, на що потрібно звернути особливу увагу при проведенні відновлення бази даних:



  1. Після завершення виконання команди "restore snapshot" може з'явитися повідомлення "cannot connect to the database" (не вдається підключитися до бази даних). По суті, це проблема синхронізації. Після завершення відновлення стара база даних видаляється, BKP-файл копіюється з каталогу резервного копіювання в каталог бази даних і встановлюється. Після цього процес відновлення намагається під'єднатися до бази даних для обробки log-файлів. Якщо система завантажена або сервер SQLBase занадто повільно працює, щоб вчасно обробити повідомлення про оновлення установки бази даних, процес відновлення не може до неї підключитися. Рішенням цього утруднення є збільшення значення параметра CONNECTTIMEOUT в секції маршрутизатора (router) конфігураційного файлу sql.ini. Цей параметр вказує час очікування (у секундах) після невдалого підключення до сервера перед наступною спробою з'єднання. Наприклад, якщо для успішного підключення до бази даних потрібно задати параметру CONNECTTIMEOUT значення 20, створіть у секції маршрутизатора рядок зі значенням: connecttimeout = 20.
  2. Наявність лише однієї BKP-файлу без log-файлів означає велику проблему. Тим не менше, і в цьому випадку можна спробувати щось зробити. Іноді це працює, але нічого не можна гарантувати. Припустимо, що база даних називається MIKE.BKP. Використовуючи SQLTalk, виконайте команду завдання імені сервера (set server), а потім зробіть наступне:

RESTORE DATABASE FROM [шлях до каталогу резервних копій] ON SERVER TO MIKE;


З'явиться повідомлення <<Database has been restored. Use rollforward to complete recovery>> (База даних відновлена. Використовуйте команду rollforward для завершення відновлення).


ROLLFORWARD MIKE TO BACKUP; (Зауважимо, що "to backup" – схоже, єдина опція, яка може спрацювати)
Виникне повідомлення <<You must restore the database first>> (Спочатку необхідно відновити базу даних).


ROLLFORWARD MIKE TO BACKUP; (Так, виконаєте цю команду ще раз!) Буде видано повідомлення <<Rollforward completed>> (Процес rollforward завершено).


CONNECT MIKE 1 username/password;
З'явиться повідомлення <<Connected to MIKE>> (Встановлено з'єднання з базою даних MIKE).
Проведіть перевірку бази даних (команда "check database"), щоб дізнатися про його стан.


Сценарії


Тут порівнюються різні методи резервного копіювання і що виникають у результаті можливості відновлення.


Нижче наведено кілька порівнянь різних методів резервного копіювання, щоб дати уявлення про вимоги до дискового простору і можливості відновлення. Передбачається наступне: стандартний розмір log-файлу – 1 МБ, їх відлік починається з 1.LOG, для всіх log-файлів створені шаблони максимального розміру і всі транзакції завершені до створення резервних копій.


Метод моментальних знімків:


Якщо в цей момент сталася відмова системи, можливості відновлення будуть доступні тільки для попередньої резервної копії. Відновлення останніх трьох log-файлів транзакцій неможливо, так як порушена безперервність послідовності log-файлів (файли 1-7 в області бази даних було розблоковано, оскільки транзакції були завершені і не потребували відновлення після збою або в відкат).


Після моментального знімку:


Область бази даних Область резервного копіювання


Зауважимо, що файл 4.LOG з області резервного копіювання призначений для видалення, оскільки відповідні йому транзакції включені в файл DB1.BKP, а створений він був раніше цього файлу.


Backup Database і Backup Logs:


Зауважимо, що всі log-файли знаходяться в області бази даних до їхнього резервування командою "backup logs", навіть якщо всі транзакції були завершені.


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


Якщо в цей момент сталася відмова системи, можливості відновлення доступні для самої останньої транзакції шляхом відновлення BKP-файлу, обробки спочатку log-файлів 1-4 з області резервного копіювання, а потім файлів 5-8 з області бази даних.


_____________________________________________
Після завершення методів "release log" і "backup logs"


Зауважимо, що жоден log-файл з області резервного копіювання не призначений для видалення, оскільки вони ВСІ повинні бути використані разом з DB1.BKP з тієї ж області, щоб зробити його узгодженим з файлом DB1.DBS з області бази даних.


Зауважимо, що раз були створені резервні копії бази даних і log-файлів, log-файли 1-10 з області резервного копіювання можуть бути розблоковані, оскільки новий BKP-файл повинен містити всі відповідні транзакції, а дата і час їх створення будуть більш ранніми, ніж у файлу DB1.BKP.


Висновок


Той, кому ще ніколи не доводилося відновлювати свої дані, може вважатися щасливою людиною. Однак статистика стверджує, що іноді це доводиться робити! Розробляйте свою стратегію відновлення даних вже зараз, до того, як в цьому виникне реальна необхідність.

Додаткова інформація



Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*