В первой части поста я остановился на онлайн журнальных файлах. Продолжим.
Онлайн журнальные файлы используются по кругу (рис. 1).
После того, как полностью заполнен онлайн журнал группы G11, начинается запись в журнал группы G12 и так далее, пока не дойдет до группы G14. После использования последней группы, процесс записи должен переключиться на первый журнал и начать запись в него. И тут есть 2 варианта. Дело в том, что экземпляр ORACLE может работать в двух режимах:
В первом случае, если база данных находится в режиме ARCHIVELOG, то прежде чем процесс записи в онлайн журналы сможет удалить данные и начать писать в журнал, журнальный файл должен быть сохранен в специальную директорию. По-умолчанию, это директория /oracle/<SID>/oraarch (до версии базы данных ORACLE 9i это была директория /oracle/<SID>/saparch). Сохраненные файлы имеют порядковый номер и называются оффлайн журнальными файлами ORACLE. Вид имеют примерно такой:
Так же стоит отметить, что копирование производится в директорию, которая имеет ограниченный размер. Поэтому, если директория переполнится, то работа базы данных будет невозможна. Все операции изменения данных просто "повиснут", так как процесс записи в онлайн журнальные файлы не сможет записать команды изменения данных (SQL запросы типа DELETE, UPDATE, INSERT и так далее). Подробно о важности контроля свободного места в директории /oracle/<SID>/oraarch я писал в этом посте.
Как уже отмечалось, данные файлы очень важны для восстановления системы, поэтому их надо резервировать. SAP рекомендует создавать две копии оффлайн журнальных файлов, после чего удалять их из директории /oracle/<SID>/oraarch.
Если потеря части данных, например, за день или два, не критична для SAP системы, то такую систему я предпочитаю переводить в режим NOARCHIVELOG. Это может быть демонстрационная или учебная система, система разработки или тестовая. Так же бывает удобным временный перевод системы в такой режим при проведении больших операций с системой. Например, копировании манданта. Конечно, тут надо принимать решение исходя из ситуации, но если не будет необходимости восстанавливать систему на период времени в середине процесса копирования манданта, то зачем тогда нужны журнальные файлы за этот период? А при крупных операциях их будет очень много. Отмечу сразу это не для продуктивной системы. Продуктивная система это особый случай. Тут только ARCHIVELOG режим.
Как бы то ни было, но у NOARCHIVELOG режима есть ряд плюсов:
Посмотреть в каком режиме работает база данных и переключить в другой можно следующими способами:
Дополнительно на данную тему можно почитать в SAP курсе ADM505 или на этой странице в SAP Help Library.
Автор: Шиболов Вячеслав Анатольевич
Онлайн журнальные файлы используются по кругу (рис. 1).
Рис. 1. Запись в онлайн журнальные файлы ORACLE. |
После того, как полностью заполнен онлайн журнал группы G11, начинается запись в журнал группы G12 и так далее, пока не дойдет до группы G14. После использования последней группы, процесс записи должен переключиться на первый журнал и начать запись в него. И тут есть 2 варианта. Дело в том, что экземпляр ORACLE может работать в двух режимах:
- ARCHIVELOG MODE,
- NOARCHIVELOG MODE,
В первом случае, если база данных находится в режиме ARCHIVELOG, то прежде чем процесс записи в онлайн журналы сможет удалить данные и начать писать в журнал, журнальный файл должен быть сохранен в специальную директорию. По-умолчанию, это директория /oracle/<SID>/oraarch (до версии базы данных ORACLE 9i это была директория /oracle/<SID>/saparch). Сохраненные файлы имеют порядковый номер и называются оффлайн журнальными файлами ORACLE. Вид имеют примерно такой:
<SID>ARCHARC04761_0696002781.001Это и есть некая история операций с данными во временном срезе с помощью которой можно проводить восстановление базы данных практически на любую точку в прошлом. Стоит отметить, что для восстановления обязательно нужна копия дата файлов базы, на которые можно "накатывать" последовательно журналы. Последовательность крайне важна. Если потеряете хотя бы один оффлайн журнальный файл, дальнейшее восстановление во времени будет невозможно. Копированием онлайн журнальных файлов в оффлайн журнальные файлы занимается процесс ARC0 (Часть I: рис. 1). Он обязательно должен быть запущен, установкой параметра log_archive_start = true.
Так же стоит отметить, что копирование производится в директорию, которая имеет ограниченный размер. Поэтому, если директория переполнится, то работа базы данных будет невозможна. Все операции изменения данных просто "повиснут", так как процесс записи в онлайн журнальные файлы не сможет записать команды изменения данных (SQL запросы типа DELETE, UPDATE, INSERT и так далее). Подробно о важности контроля свободного места в директории /oracle/<SID>/oraarch я писал в этом посте.
Как уже отмечалось, данные файлы очень важны для восстановления системы, поэтому их надо резервировать. SAP рекомендует создавать две копии оффлайн журнальных файлов, после чего удалять их из директории /oracle/<SID>/oraarch.
Если потеря части данных, например, за день или два, не критична для SAP системы, то такую систему я предпочитаю переводить в режим NOARCHIVELOG. Это может быть демонстрационная или учебная система, система разработки или тестовая. Так же бывает удобным временный перевод системы в такой режим при проведении больших операций с системой. Например, копировании манданта. Конечно, тут надо принимать решение исходя из ситуации, но если не будет необходимости восстанавливать систему на период времени в середине процесса копирования манданта, то зачем тогда нужны журнальные файлы за этот период? А при крупных операциях их будет очень много. Отмечу сразу это не для продуктивной системы. Продуктивная система это особый случай. Тут только ARCHIVELOG режим.
Как бы то ни было, но у NOARCHIVELOG режима есть ряд плюсов:
- не нужно выделять отдельную файловую систему и мониторить свободное место в директории /oracle/<SID>/oraarch,
- цикл резервного копирования упрощается: делать необходимо только холодные копии базы данных,
- немного увеличивается быстродействие работы базы данных и SAP системы соответственно.
Если подытожить, то основной плюс - это снижение трудозатрат администратора системы.
Посмотреть в каком режиме работает база данных и переключить в другой можно следующими способами:
- Используя SQLPlus и SQL запросы следующего вида:
- > select LOG_MODE from V$DATABASE; - просмотр текущего режима,
пример:
- > alter database NOARCHIVELOG; - перевод базы данных в NOARCHIVELOG режим,
- > alter database ARCHIVELOG; - перевод базы данных в ARCHIVELOG режим.
Команды необходимо выполнять в состоянии базы данных MOUNT.
пример:
- Через утилиту BR*TOOLS можно посмотреть режим или переключить.
Для просмотра режима необходимо, запустив утилиту в командной строке, перейти в пункт меню:
- (1) Instance management -> (8) Additional instance functions -> (1) Show instance statusпример:
Для изменения режима необходимо пройти путь по меню:
- (1) Instance management -> (3) Alter database instance -> (3) Set archivelog mode или (4) Set noarchivelog mode
пример:
Необходимо учитывать перезагрузку базы данных в случае переключения режима. - В SAP системе через транзакцию DBACOCKPIT можно посмотреть текущий режим работы базы данных.
Для этого в древовидном меню надо выбрать пункт: "Space -> Database -> Overview":
- Через утилиту BRSPACE можно переключить режим работы. Для этого в командной строке надо выполнить команду вида:
- > brspace –f dbalter –a archlog
- > brspace –f dbalter –a noarchlog
Для просмотра текущего состояния можно выполнить команду без опций:
- > brspace
Дополнительно на данную тему можно почитать в SAP курсе ADM505 или на этой странице в SAP Help Library.
Автор: Шиболов Вячеслав Анатольевич
Комментариев нет:
Отправить комментарий