Раздел: журналы повторного выполнения

О некоторых атрибутах параметра инициализации LOG_ARCHIVE_DEST_n писалось здесь. Продолжим эту тему, затронув опции важные для организации standby.

Первое, на что хотелось обратить внимание: параметр LOG_ARCHIVE_DEST_n можно использовать со множеством атрибутов, но параметр принимает одно значение. То есть все его опции-атрибуты нужно задавать одной строкой. Это его отличает от других параметров, которые могут принимать несколько значений (например, CONTROL_FILES).

Добавил dbstalker в 30 июля 2008 г. [Ссылка | Комментарии (0) ]

Представление V$ARCHIVE_DEST показывает текущее состояние (режим, статус, значение) всех мест архивации журнальных файлов. Если у Вас организован STANDBY, то особо важно следить за этим представлением, так же как и за представлением V$ARCHIVE_DEST_STATUS. Пример можно здесь посмотреть здесь.

Добавил dbstalker в 28 июля 2008 г. [Ссылка | Комментарии (0) ]

На этот вопрос исчерпывающе ответил Том Кайт здесь. Но у меня организован standby и к тому же из-за специфики эксплуатации серверов передача архивных файлов может происходить с опозданием. Поэтому технология упаковки архивных журналов другая.Упаковываться должны только те файлы, что уже накатаны на резервном сервере.

Добавил dbstalker в 24 июля 2008 г. [Ссылка | Комментарии (0) ]

Помимо задания месторасположения таким способом , существует еще другой способ – с помощью параметров инициализации: LOG_ARCHIVE_DEST и LOG_ARCHIVE_DUPLEX_DEST. Если у Вас Oracle Enterprise Edition, то, пожалуй, лучше использовать LOG_ARCHIVE_DEST_n (больше возможностей). Параметр LOG_ARCHIVE_DEST несовместим с LOG_ARCHIVE_DEST_n, поэтому один из них должен быть равным '' (null string).

Добавил dbstalker в 14 июля 2008 г. [Ссылка | Комментарии (0) ]

Архивные журнальные файлы могут располагаться в нескольких местах ( максимум 10). Задать их место расположение можно с помощью параметра LOG_ARCHIVE_DEST_n (для Oracle Enterprise Edition), имеющего ключевые слова SERVICE и LOCATION.

Замечание:

Параметр LOG_ARCHIVE_DEST_n несовместим с LOG_ARCHIVE_DEST, поэтому один из них должен быть равным '' (null string).

Добавил dbstalker в 7 июля 2008 г. [Ссылка | Комментарии (3) ]

Самая ПЕРВАЯ обязанность администратора – поддержка базы данных в рабочем состоянии. Даже если в системе происходит сбой (пропало питание, носитель пришел в непригодность и т.д.), администратор должен в максимально сжатые сроки поднять базу без потерь данных. Значит, к сбоям администратор должен готовиться загодя.

Добавил dbstalker в 7 июля 2008 г. [Ссылка | Комментарии (0) ]

Этот фоновый процесс имеет смысл запускать, только если база данных работает в режиме ARCHIVELOG. Процесс копирует оперативные файлы журнала повторного выполнения в архивные файлы журнала повторного выполнения после заполнения оперативных журналов или их переключения.

Добавил dbstalker в 4 июля 2008 г. [Ссылка | Комментарии (2) ]

В каком режиме будет работать Ваша база данных, устанавливается во время инсталляции. Если же база создается вручную, то необходимо в операторе CREATE DATABASE указать желаемый режим (обычно по умолчанию NOARCHIVELOG). Однако в процессе работы базы данных есть возможность поменять режим. Об этом здесь.

Добавил dbstalker в 4 июля 2008 г. [Ссылка | Комментарии (0) ]

При эксплуатации в этом режиме активным является процесс архивирования - оперативный журнал (группа) не перезаписывается до тех пор, пока не будет заархивирован. Для процесса архивации оперативный журнал становится доступным сразу же после переключения.

Добавил dbstalker в 4 июля 2008 г. [Ссылка | Комментарии (0) ]

В этом режиме не происходит архивирования. То есть, как только оперативный журнал (группа) становится неактивным, то его уже можно перезаписывать.

Добавил dbstalker в 3 июля 2008 г. [Ссылка | Комментарии (1) ]

Все мы знаем, что база данных не может существовать без оперативных журнальных файлов. Что касается архивных журналов, тут мнения расходятся.

Добавил dbstalker в 3 июля 2008 г. [Ссылка | Комментарии (0) ]

Администратор в повседневной работе достаточно часто использует следующие представления:

Добавил dbstalker в 3 июля 2008 г. [Ссылка | Комментарии (0) ]

Мне приходилось восставливать базы данных , увы, не единожды. А вот сегодня со мной произошел казус : Нужно восстановить базу на новом сервере по холодной копии двухнедельной давности и архивным журналам за эти две недели. Задача элементарная.

Добавил dbstalker в 30 мая 2008 г. [Ссылка | Комментарии (4) ]

Почему содержимое буферного кеша так важно? Неужели не достаточно данных, что находятся в файлах данных на диске?

Добавил dbstalker в 19 мая 2008 г. [Ссылка | Комментарии (0) ]

В файле трассировки были обнаружены сообщения:

LGWR: Archivelog for thread 1 sequence 7061 will NOT be compressed
*** 2008-02-13 03:20:53.582
LGWR: Archivelog for thread 1 sequence 7062 will NOT be compressed
*** 2008-02-13 03:38:32.362
LGWR: Archivelog for thread 1 sequence 7063 will NOT be compressed

Как выяснилось, это сообщение не указывает ни на проблему в базе данных, ни на ошибку в конфигурации, ни на ошибку в установке параметров. Просто сжатие архивных файлов не доступно в ORACLE 10g. Вроде бы оно уже доступно в версии 10.2.0.3.0.

Это все. Если у Вас больше информации, то поделитесь. Будем благодарны.

Добавил dbstalker в 13 февраля 2008 г. [Ссылка | Комментарии (1) ]

Чтобы разобраться в ситуации, когда появляется такое сообщение в журнале оповещений, необходимо предварительно уяснить для себя: что такое нормальная и инкрементальная контрольные точки, а также что такое журналы повторного выполнения.

Добавил dbstalker в 19 декабря 2007 г. [Ссылка | Комментарии (3) ]

Если поврежден неактивный файл, то это вообще не проблема: удаляется и создается заново.

Если поврежден активный или текущий файл?

Добавил dbstalker в 2 ноября 2007 г. [Ссылка | Комментарии (0) ]

Возникла проблема при старте базы: утеряны были не текущие журнальные файлы.С этой проблемой удалось справиться относительно легко.

Добавил dbstalker в 18 октября 2007 г. [Ссылка | Комментарии (0) ]

Основные команды: создание и удаление групп, элементов групп, очистка файлов, выполнение контрольной точки, переключение журналов.

Добавил dbstalker в 11 октября 2007 г. [Ссылка | Комментарии (0) ]

Задача простая, но хочется предложить уже опробованную технологию.

Добавил dbstalker в 6 июня 2007 г. [Ссылка | Комментарии (0) ]

На примере журнальных файлов можно демонстрировать закон единства и борьбы противоположностей.

• Для оптимизации производительности Вам необходимо конфигурировать LGWR и DBWR так, чтобы операции записи выполнялись как можно реже.
• для минимизации времени восстановления екземпляра, Вам необходимо конфигурировать LGWR и DBWR так, чтобы операции записи производились как можно чаще.

Добавил dbstalker в 10 октября 2007 г. [Ссылка | Комментарии (0) ]

Из каких событий состоит процесс переключения журналов. Об этом кратко и упрощенно.

Добавил dbstalker в 10 октября 2007 г. [Ссылка | Комментарии (0) ]

Данные формируются в SGA в буфере журнала повторного выполнения. Как только транзакция фиксируется, фоновым процессом LGWR («писатель» журнальных файлов – пишет на диск информацию об измененных данных, поддерживает целостность данных) данные сбрасываются на диск (также данные из буфера журнала повторного выполнения сбрасываются на диск при простое LGWR более трех секунд, или при заполнении буфера журнала повторного выполнения на треть, или при записи в него 1 Мбайта данных).

Транзакции присваивается системный номер изменений(SCN), который ставит в соответствие записи в журнальном файле каждой фиксированной транзакции. Только после завершения этого процесса, пользователю сообщается, что транзакция завершена.

Процесс LGWR в журналы записывает последовательно, а не вразброс, как вынужден выполнять ввод-вывод процесс DBWn. Это является главной причиной разделения функции записи на диск на два процесса: процесс LGWR и процесс DBWn.

Добавил dbstalker в 10 октября 2007 г. [Ссылка | Комментарии (0) ]

Формируемые данные для журналов повторного выполнения представляют собой запись, состоящую из векторов изменений. Эти вектора описывают изменения, сделанные в

1. блоке сегмента данных таблицы
2. блоке данных сегмента отката
3. таблице транзакций сегментов отката.

Добавил dbstalker в 10 октября 2007 г. [Ссылка | Комментарии (5) ]

Журналы повторного выполнения очень важны для функционирования базы данных ORACLE. Проще говоря, без них база работать не будет.Эти журналы являются хронологией выполнения транзакций.

Добавил dbstalker в 10 октября 2007 г. [Ссылка | Комментарии (2) ]