|
Аруп Нанда
Точки восстановления на определенный момент времени в прошлом
(Restore to the Point, By Arup Nanda)
Источник: журнал Oracle Magazine, November/December 2006
(http://www.oracle.com/technology/oramag/oracle/06-nov/o66recovery.html).
Используйте именованные точки восстановления для отката базы данных с помощью технологии Oracle Flashback (технология выполнения ретроспективных операций)
Джейн, главный администратор базы данных банка Acme Bank, сегодня принимала трех посетителей. Первый посетитель – Пол, начальник отдела обеспечения качества (QA, Quality Assurance). В его отделе создаются разнообразные сценарии тестов приложений. Для каждого сценария собираются тестовые данные, а после прогона каждого теста для восстановления их предтестовых значений требуется модификация данных.
Второй посетитель – Том, операционный менеджер. Он отвечает за пакетную обработку файлов с финансовой информацией, получаемых из каждого филиала банка. Если при обработке какого-либо файла обнаруживается ошибка, то процесс обработки прерывается и его необходимо начать с самого начала.
Третий посетитель – Гарри, бизнес-менеджер приложения, разработанного сторонней фирмой. Он отвечает за процесс модернизации этого приложения. Гарри получает от поставщика обновления для модификации структуры базы данных, модификации данных и т.д. Большинство обновлений проходят беспрепятственно, но когда происходит сбой, все "подвисает". Команда Гарри тратит значительное время, отыскивая способы отмены ошибочных изменений.
Пол, Том и Гарри попросили Джейн помочь повысить эффективность выполнения их процессов. Джейн заверила, что у нее есть решение. К счастью, в банке Acme используется СУБД Oracle Database 10g Release 2, поэтому для отката базы данных на определенный момент времени в прошлом можно использовать именованные точки восстановления.
Настройка
Джейн попросила своих посетителей присесть и напомнила им, как можно откатить базу данных на какой-то момент времени, используя простой оператор – оператор FLASHBACK DATABASE (ретроспективный откат базы данных). Джейн также сказала, что в СУБД Oracle Database 10g Release 2 эта функциональность существенно усовершенствована – появилась возможность давать имена конкретным моментам времени, эта возможность называется точками восстановления (restore point). Поэтому Пол, Том или Гарри (или по их поручению администраторы базы данных) могут пометить нужный логический момент времени и, в случае необходимости, выполнить ретроспективный откат базы данных на этот момент.
Джейн приступила к демонстрации на сервере тестовой базы данных. Она отметила, что сервер должен работать в режиме архивирования журнальных файлов (опция archivelog), а также должна быть включена журнализация ретроспективных данных. Сначала она остановила экземпляр сервера базы данных и вновь запустила его в режиме со смонтированной базой данных (mounted mode):
shutdown immediate;
startup mount;
Затем она перевела сервер в режим архивирования журнала:
alter database archivelog;
Для сбора ретроспективных данных Джейн сначала установила два параметра инициализации:
alter system set db_recovery_file_dest_size = 2G;
alter system set db_recovery_file_dest = '/u02/flashbackarea/acmeprd';
В режиме обеспечения ретроспективного отката базы данных (flashback mode) сервер создает файлы журналов ретроспективных данных (flashback log files), в которые после изменения данных записываются их старые образы. Местонахождение этих файлов указывается параметром db_recovery_file_dest, а максимальный размер задается параметром db_recovery_file_dest_size, значение которого в данном случае равно 2 ГБ.
Затем Джейн включает журнализацию ретроспективных данных:
alter database flashback on;
И открывает базу данных:
alter database open;
Она проверяет статусы режимов архивирования журнала и журнализации ретроспективных данных:
select flashback_on, log_mode
from v$database;
FLASHBACK_ON LOG_MODE
------------ ----------------
YES ARCHIVELOG
Это подтверждает, что экземпляр действительно работает в режиме обеспечения ретроспективного отката базы данных.
Точки восстановления
Джейн продолжает демонстрацию, показывая, какие выгоды от использования технологии ретроспективного отката базы данных может получить команда Пола. Джейн создает точку восстановления qa_gold:
create restore point qa_gold;
Джейн напоминает всем, что этот оператор появился в СУБД Oracle Database 10g Release 2. Он создает именованную точку восстановления, которая является псевдонимом системного номера изменений SCN (system change number) базы данных на текущий момент времени.
Джейн выполняет прогон одного из тестов команды Пола, изменяющего тестовые данные. Для отката базы данных до созданной точки восстановления Джейн останавливает экземпляр сервера базы данных, вновь запускает его в режиме со смонтированной базой данных и выполняет оператор ретроспективного отката базы данных:
shutdown immediate;
startup mount;
flashback database to restore point qa_gold;
И это все; теперь база данных "откачена" до точки восстановления qa_gold. Джейн не нужно создавать резервную копию базы данных и выполнять восстановление базы на определенный момент в прошлом (point-in-time recovery). Пол никогда не был таким счастливым.
Для Тома Джейн продемонстрировала немного другой подход. Команда Тома выполняет пакетную обработку по одному файлу одновременно, поэтому Джейн предложила создавать точку восстановления после обработки каждого файла, используя некоторое предопределенное соглашение по именованию, например, after_branch_n, где n – идентификатор филиала банка (BRANCH_ID).
Для отслеживания обрабатываемых файлов у Тома есть таблица PROC, которая имеет только один столбец – BRANCH_ID; в нем хранится идентификатор филиала, чей файл обрабатывается в данное время. Джейн показала пример использования точек восстановления при типичной пакетной обработке:
1. Для обозначения начала процесса обработки она создает точку восстановления start_batch.
create restore point start_batch;
2. Для указания обрабатываемого филиала она обновляет таблицу PROC:
update proc set branch_id = 1;
commit;
3. Она запускает пакетное задание для обработки данных филиала 1.
4. После обработки файла филиала 1 она создает новую точку восстановления:
create restore point after_branch_1;
Этот процесс повторяется до завершения обработки файлов всех филиалов.
Джейн демонстрирует процесс восстановления на примере ошибки при обработке файла филиала 23. Когда возникает эта ошибка, значение столбца BRANCH_ID в таблице PROC будет равно 23:
SQL> select branch_id from proc;
BRANCH_ID
---------
23
В этом случае Джейн откатывает изменения до точки восстановления after_branch_22:
shutdown immediate;
startup mount;
flashback database to restore point
after_branch_22;
alter database open;
Для подтверждения успешного выполнения отката она снова проверяет таблицу PROC:
SQL> select branch_id from proc;
BRANCH_ID
---------
22
Теперь значение этого столбца – 22, оно указывает последний успешно обработанный файл. Отменены все изменения, сделанные в базе данных после создания этой точки восстановления.
Иногда при обработке какого-то файла возникает ошибка, но ее замечают гораздо позднее. Например, ошибка при обработке файла филиала 23 может быть обнаружена при обработке файла филиала 29. Джейн заверила Тома, что он может легко откатить все до точки восстановления after_branch_22.
Отвечая на вопрос Гарри об обновлении приложения, Джейн предложила решение очень похожее на решение для Пола. Перед началом модернизации системы базы данных Гарри или администратор базы должны создать точку восстановления pre_change. Если эта модернизация не будет успешной, все что нужно сделать – откатить базу данных до этой точки восстановления, используя рассмотренные выше операторы ретроспективного отката.
Гарантированные точки восстановления
Пол, Том и Гарри покинули офис Джейн и вернулись в свои подразделения для тестирования предложенных решений.
Спустя несколько часов в офис Джейн вернулся Том с сообщением об ошибке. Когда он пытался выполнить ретроспективный откат базы данных до точки восстановления, возникла ошибка:
ORA-38729: Not enough flashback
database log data to do FLASHBACK.
Ошибка указывает, что для отката до точки восстановления недостаточно журналов ретроспективных данных. Объяснение Джейн было простым – эти журналы будут поддерживаться столько времени, сколько указано в параметре инициализации db_flashback_retention_target (его значение по умолчанию – 1 440 минут, одни сутки).
Устаревшие журналы автоматически не удаляются; однако максимальный размер области для быстрого восстановления (flash recovery area) определяется параметром инициализации db_recovery_file_dest_size, значение которого в данном случае равно 2 ГБ. Когда у Тома эта область увеличилась до 2 ГБ, сервер Oracle Database должен высвободить место для новых журналов, удаляя более старые журналы. Поэтому во время отката произошла ошибка из-за нехватки нужных журналов.
Том спросил, как же обеспечить гарантированный откат до конкретной точки восстановления.
Джейн заверила его, что для этого есть соответствующий механизм – гарантированные точки восстановления (guaranteed restore point). Она показала, как создавать гарантированную точку восстановления:
create restore point after_branch_22
guarantee flashback database;
В этом случае сервер Oracle Database не будет вытеснять старые журналы ретроспективных данных, необходимых для этой точки восстановления.
Администрирование
После успешного обсуждения проблемы Тома Джейн собрала своих администраторов базы данных, чтобы убедиться, что они понимают, как администрировать точки восстановления. Сначала она показала им, как узнавать число созданных точек восстановления:
select * from v$restore_point
order by scn;
Результаты этого запроса показаны на листинге 1. Комментируя их, Джейн описала назначение столбцов. Столбец NAME – имя точки восстановления; столбцы SCN и TIME – номер SCN и отметка времени (в расширенном формате) создания точки восстановления соответственно; столбец GUARANTEE_FLASHBACK_DATABASE (его имя показано как "GUA") указывает, гарантированная ли данная точка восстановления; столбец STORAGE_SIZE указывает размер памяти, используемый для этой точки восстановления (ненулевые значения будут только у этих гарантированных точек восстановления). И наконец, столбец DATABASE_INCARNATION# указывает инкарнацию базы данных, которая была во время создания точки восстановления. Если был выполнен ретроспективный откат базы данных, а затем она была открыта со сбросом номеров журнальных файлов (опция resetlogs), то создается новая инкарнация базы данных.
|
ЛИСТИНГ 1: содержимое представления V$RESTORE_POINT. |
SCN DATABASE_INCARNATION# GUA STORAGE_SIZE TIME NAME
-------- --------------------- ---- ------------ ------------------------------- ------------
14390197 6 NO 0 01-AUG-06 01.12.27.000000000 PM QA_GOLD
24390219 6 NO 0 01-AUG-06 02.13.16.000000000 PM AFTER_BRANCH_1
34390232 6 NO 0 01-AUG-06 03.13.34.000000000 PM AFTER_BRANCH_2
44390243 6 NO 0 01-AUG-06 04.13.49.000000000 PM AFTER_BRANCH_3
54394187 7 YES 3981312 02-AUG-06 05.35.19.000000000 AM AFTER_BRANCH_4 |
Если точки восстановления становятся ненужными, продолжила Джейн, их можно удалить. Например:
drop restore point after_branch_1;
Заключение
Используя точки восстановления, администраторы базы данных могут помечать моменты времени, а затем использовать их для быстрого отката и наката базы данных на конкретный момент времени. Точки восстановления очень полезны для быстрого восстановления базы данных после пользовательских ошибок, однако их прекрасно можно использовать и в других случаях. В таблице 1 резюмируются различные сценарии проблем и пути их решения с помощью точек восстановления.
Таблица 1. Возможные варианты использования точек восстановления
|
Сценарий |
Решение |
|
При выполнении пакетных программ в базе данных могут непреднамеренно возникать какие-то несоответствия, для устранения которых перед запуском других пакетных программ может потребоваться восстановление базы на определенный момент в прошлом. |
Создание точки восстановления перед запуском каждого пакетного задания. В случае возникновения проблем, откат базы данных до этой точки. |
|
При модернизации схемы базы данных и развертывании приложений, в которых широко применяются изменения схемы, могут возникать ошибки, в результате которых база данных может стать несогласованной, поэтому может потребоваться ее восстановление на определенный момент в прошлом. |
Создание точки восстановления перед началом модернизации. В случае сбоя при развертывании приложений, откат базы данных до этой точки. |
|
В отделе обеспечения качества аккуратно подготавливают тестовые данные, но после каждого прогона теста они оказываются модифицированными и перед прогоном следующего теста их нужно восстановить. |
Создание точки восстановления перед прогоном первого теста. Откат базы данных до этой точки после прогона каждого теста. |
===================================================================
Арап Нанда (Arup Nanda) (arup@proligence.com) – администратор баз данных Oracle с двенадцатилетним стажем. Он занимается всеми аспектами администрирования – от оптимизации производительности до информационной безопасности и аварийного восстановления. Арап – соавтор книги "PL/SQL for DBAs" (O'Reilly Media, 2005). В 2003 г. он был удостоен награды журнала Oracle Magazine "Oracle's DBA of the Year" (администратор года баз данных Oracle). | 
