FLASHBACK DATABASE дозволяє відкочувати все зміни в БД на деякий час назад не вдаючись до відновлення БД. Це дуже корисно використовувати наприклад коли потрібно відкотити оновлення додатка в базі даних. Відкочувати БД можна як до створеної точки відновлення, так і до конкретної тимчасової мітці і точці SCN. Однак це не "безкоштовна" для продуктивності технологія, при включенні опції FLASHBACK DATABASE в базі даних починають записуватися нові журнали (flashback logs) в області FRA.
Для використання FLASHBACK DATABASE потрібно наступне:
- Права SYSDBA;
- Включити FLASHBACK;
- Включити режим ARCHIVELOG;
- При використанні FLASHBACK база даних повинна бути в режимі mount;
- Для всіх табличних просторів потрібно включити FLASHBACK;
- Параметри db_recovery_file_dest і db_recovery_file_dest_size;
- Параметр db_flashback_retention_target;
Перевіримо, чи включений flashback, якщо немає, то включимо його.
Параметр db_flashback_retention_target показує на яку максимальну час можна відкотити БД. Він виставляється в хвилинах і за замовчуванням встановлений в 1 день.
Параметри db_recovery_file_dest і db_recovery_file_dest_size відповідають за шлях для FRA і його розмір.
Дізнаємося поточний SCN, щоб в майбутньому можна було відкотитися до нього. Для відкату БД повинна бути переведена в режим mount.
БД відкотилася до моменту до створення таблиці. Відновимо БД до стану перед відкотом.
Подивимося, як можна відкотитися до конкретного часу:
БД відкотилася до моменту до вставки запису в таблицю. Відновимо БД до стану перед відкотом.
Створимо точки відновлення: звичайну і гарантовану. У разі створення гарантованої точки, потрібно бути впевненим, що вистачить місця в FRA для необхідного часу зберігання її.
Flashback logs можна відключати для деяких табличних просторів. В такому випадку перед відкотом їх потрібно перевести в файли цього табличного простору в режим offline наступною командою: alter database datafile '/tmp/tsttbs.dbf' offline;
Обмеження Flashback database:
- Flashback Database може тільки скасувати зміни в файлі даних, зроблених самої СУБД.
- Не можна використовувати Flashback Database, щоб скасувати операцію shrink.
- Не можна відкотити віддалений файл. В цьому випадку віддалений файл відновлюємо з бекапу, а інші файли відкатуємо через flashback.
- Якщо контрольний файл відновлений з бекапу або перебудувати, вся інформація по flashback логам пропаде.
- Якщо ви використовуєте NOLOGGING операції, то після відкоту у вас можуть з'явитися зіпсовані блоки, над якими в цей час проходили NOLOGGING операції. Бажано робити бекап після кожної операції в режимі NOLOGGING.
Property Description
Parameter type Integer
Default value 1440 (minutes)
Modifiable ALTER SYSTEM
Range of values 0 to 232 - 1 (max value represented by 32 bits)
Basic No
поправ)
Звичайно ж в хвилинах.
Дякую за вашу спостережливість.
Статтю підправив.