Уважаемые подписчики! Этот выпуск посвящен описанию процесса переключения журнала повторного выполнения на другую группу файлов и создан на основе материалов замечательного сайта Ixora.
При переключении журнала генерация информации повторного выполнения (redo) полностью прекращается. Это делается с помощью установки переменной SGA, отражающей причину и статус преключения журнала. Сеансы проверяют эту переменную при выделении места в буфере журнала (log buffer), и если выполняется переключение журнала, они ждут наступления соотвествующего события из нескольких, связаных с переключением. Никакое место в буфере журнала не выделяется, пока переключение журнала не завершится, поэтому по ходу переключения ожиданий события log buffer space (доступа к буферу журнала) не будет. Однако, если много процессов ждало завершения переключения журнала, сразу после него может произойти всплеск генерации информации повторного выполнения, что приведет к "наведенным" ожиданиям доступа к буферу журнала.
Процесс LGWR выполняет для переключения журнала следующие четыре шага.
Записи в блоки заголовка файла журнала в ходе операций открытия и закрытия файла журнала являются операциями последовательной записи файла журнала (log file single write). Записи заголовка блока должны выполняться последовательно (а не параллельно во все файлы группы), поскольку в информацию заголовка входит номер файла, а он у каждого файла группы уникальный.
Переключение журнала - это когда сервер Oracle прекращает записывать в текущий файл журнала, закрывает его, открывает следующий файл журнала и начинает в него записывать информацию повторного выполнения. Переключение журнала процессом LGWR может произойти по одной из трех причин.
Если поток, требующий принудительного переключения журнала, не открыт, экземпляр, увеличивший значение 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.
С наилучшими пожеланиями,
В.К.
|
|