Отправляет email-рассылки с помощью сервиса Sendsay

Открыто о СУБД Oracle на русском

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "СУБД Oracle "с нуля"" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Сентябрь 2002   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
12.09.2002
14:53:12
15:23:14
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Сергей

Статистика

10.773 подписчиков
-8 за неделю
←   Все выпуски   →

Открыто о СУБД Oracle на русском : Переключение журналов и немного терминологии


Информационный Канал Subscribe.Ru

Выпуск 12

Переключение журналов и немного терминологии

Уважаемые подписчики! Этот выпуск посвящен описанию процесса переключения журнала повторного выполнения на другую группу файлов и создан на основе материалов замечательного сайта Ixora.

Шаги переключения журнала

При переключении журнала генерация информации повторного выполнения (redo) полностью прекращается. Это делается с помощью установки переменной SGA, отражающей причину и статус преключения журнала. Сеансы проверяют эту переменную при выделении места в буфере журнала (log buffer), и если выполняется переключение журнала, они ждут наступления соотвествующего события из нескольких, связаных с переключением. Никакое место в буфере журнала не выделяется, пока переключение журнала не завершится, поэтому по ходу переключения ожиданий события log buffer space (доступа к буферу журнала) не будет. Однако, если много процессов ждало завершения переключения журнала, сразу после него может произойти всплеск генерации информации повторного выполнения, что приведет к "наведенным" ожиданиям доступа к буферу журнала.

Процесс LGWR выполняет для переключения журнала следующие четыре шага.

  1. Он выполняет транзакцию управляющего файла (controlfile transaction) для выбора следующего используемого файла журнала (log file) и очистки соответствующей записи в управляющем файле. Обычно выбирается файл журнала с наименьшим порядковым номером журнала (log sequence number). При необходимости, переключение журнала в этот момент откладывается, пока процесс DBWn не завершит обработку контрольной точки, вызванной предыдущим переключением с этого файла журнала, и пока процесс ARCn не заархивирует его содержимое. Если это происходит, сеансы, ожидающие переключения журнала, засыпают в ожидании событий log switch (checkpoint incomplete) или log file switch (archiving needed), а не события log file switch completion.
  2. Он сбрасывает любую оставшуюся в буфере журнала повторного выполнения информацию на диск, а затем записывает номер системного изменения (SCN) последней записи повторного выполнения в журнальном файле (максимальный SCN, high SCN) в блок заголовка журнального файла. Как только эти записи завершены, процесс LGWR закрывает журнальный файл.
  3. Затем он увеличивает значение SCN и выполняет вторую транзакцию управляющего файла, чтобы пометить следующий файл журнала как текущий (CURRENT), а прежний файл журнала как активный (ACTIVE). Статус этого журнального файла изменится на не активный (INACTIVE) как только процесс DBWn завершит обработку контрольной точки, вызванной переключеним журнала. Если база данных работает в режиме ARCHIVELOG, то процесс LGWR также добавляет предыдущий журнальный файл в список архива через раздел записей файлов журнала в управляющем файле (см. представление V$ARCHIVE) и, если включено автоматическое архивирование, запускает фоновый процесс ARCn для его архивирования. Начиная с версии Oracle 8.1, процесс LGWR может порождать несколько новых процессов ARCn, вплоть до значения параметра log_archive_max_processes, если все существующие процессы архивирования заняты.
  4. Наконец, процесс LGWR открывает все файлы, входящие в новую группу файлов журнала, и записывает новый порядковый номер журнала и минимальный номер системного изменения (low SCN) в блок заголовка. Затем он снова разрешает генерировать информацию повторного выполнения.

Записи в блоки заголовка файла журнала в ходе операций открытия и закрытия файла журнала являются операциями последовательной записи файла журнала (log file single write). Записи заголовка блока должны выполняться последовательно (а не параллельно во все файлы группы), поскольку в информацию заголовка входит номер файла, а он у каждого файла группы уникальный.

Причины переключения журнала

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

  1. Обычно журнал переключается, когда процесс, генерирующий информацию повторного выполнения, не может выделить место в буфере журнала, поскольку недостаточно места осталось в текущем файле журнала. Тогда процесс обращается к процессу LGWR с требованием переключить журнал, и сеанс "засыпает" в ожидании события log file switch completion.
  2. Переключение журнала можно принудительно вызвать вручную с помощью оператора ALTER SYSTEM SWITCH LOGFILE или, во всех действующих потоках (enabled threads), с помощью оператора ALTER SYSTEM ARCHIVE LOG CURRENT.
  3. Переключение журнала также может вызываться автоматически в сравнительно не загруженных потоках базы данных параллельного сервера Oracle (Oracle parallel server), чтобы гарантировать возможность восстановления. При повторном использовании файла журнала любым потоком, соответствующее значение SCN (force SCN), записанное в управляющем файле, заменяется на 1 большим, чем максимальный SCN в повторно используемом файле журнала (если только оно уже не имеет большее значение). Если минимальный SCN для текущего файла журнала в любом активном потоке после этого становится меньше, чем force SCN, в этом потоке происходит переключение журнала. Это позволяет архивировать файл журнала. Пока этот журнальный файл не будет заахвивирован, более свежая информация повторного выполнения в архивной копии недавно использованного повторно журнального файла может оказаться неприменимой для восстановления в некоторых ситуациях или для восстановления резервной (standby) базы данных.

    Если поток, требующий принудительного переключения журнала, не открыт, экземпляр, увеличивший значение force SCN, выполнит переключение журнала от имени закрытого потока, а первый же доступный процесс ARCn в любом экземпляре заархивирует журнальный файл. Однако, если поток открыт, эти действия долден выполнить соответствующий экземпляр. Для этого устанавливается блокировка экземпляра KK. Процесс LGWR в каждом экземпляре удерживает блокировку KK для своего собественного потока. Поле id2 при этом содержит номер потока. Когда эта блокировка устанавливается другим экземпляром, процесс LGWR распознает, что необходимо принудительно переключить журнал.

Транзакции управляющего файла

На время транзакций управляющего файла (controlfile transactions) сеансы должны устанавливать исключительную блокировку очереди управляющих файлов (CF enqueue). Это предотвращает одновременное выполнение транзакций управляющих файлов и чтение управляющих файлов по ходу изменений, поскольку для чтения управляющего файла необходимо установить разделяемую блокировку очереди управляющих файлов. Однако необходимо также обеспечить восстановление на случай сбоя процесса, экземпляра или системы в ходе транзакции управляющего файла.

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

Возможность восстановления для изменений других разделов записей управляющего файла обеспечивается за счет дублирования всей информации. Каждый логический блок представлен двумя физическими блоками. Один содержит текущую информацию, а другой - либо старую копию информации, либо версию, ожидающую фиксации. Для слежения за тем, какой физический экземпляр каждого логического блока содержит текущую информацию, сервер Oracle поддерживает битовую карту версий блоков (block version bitmap) сместе с записью информации о базе данных в первом разделе управляющего файла.

Чтобы прочитать информацию из управляющего файла сеанс должен сначала прочитать битовую карту версий блоков и определить, какой физический блок читать. Затем, если логический блок надо изменить, изменение сначала записывается в парный текущему физический блок соответствующего логического блока, а затем зафиксировать изменение неделимой перезаписью блока, содержащего битовую карту версий блоков, соответствующий бит в которой показывает, что логический блок теперь надо читать из другого физического. Если необходимо внести изменения в несколько записей одного блока управляющего файла, например, при изменении номера SCN контрольной точки во всех активных файлах данных, эти изменения буферизуются и записываются вместе. Учтите, что каждая транзакция управляющего файла требует выполнения не менее 4 последовательных операций ввода/вывода с управляющим файлом, а, может, и больше, если затронуто несколько блоков или управляющий файл мультиплексирован, а асинхронный ввод/вывод не доступен. Поэтому транзакции управляющего файла - потенциально дорогостоящие операции с точки зрения задержек при вводе/выводе.

При фиксации транзакции управляющего файла увеличивается порядковый номер управляющего файла (controlfile sequence number). Это номер записан в битовой карте версий блоков и записи с информацией о базе данных в первом разделе управляющего файла. Он используется в заголовке кэша каждого блока управляющего файла вместо номера изменения SCN для выявления "битых" блоков при "горяем" резервном копировании. Он также используется в запросах, выполняющих чтение нескольких управляющих файлов для гарантированного получения согласованного моментального снимка содержимого управляющих файлов. Если значения не совпадают, выдается сообщение об ошибке ORA-00235.

Механизм транзакции управляющего файла не используется для изменения информации о выполнении обработки контрольной точки (checkpoint heartbeat). Вместо этого, размер записи о ходе обработки контрольной точки полагается равным половине блока управляющего файла, так что для раздела записи о ходе обработки контрольной точки выделяется один физический блок на каждый поток. Затем, вместо использования пары физических блоков для представления каждого логического, каждая запись о ходе выполнения контрольной точки сохраняется в отдельном физическом блоке, так что записи эти выполняются и фиксируются неделимо (atomically), независимо от любых других данных.

Выпуск создан на основе публикации на сайте Ixora. © 2002, Ixora Pty Ltd.

В следующем выпуске

Пока точно не знаю. Возможно, кое что про использование REF CURSOR, или опять для АБД: "Мифы об экстентах"... Следите за новостями на сайте проекта Open Oracle.

С наилучшими пожеланиями,

  В.К.

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное