Увеличить redo log oracle
Не так давно в моём рассказе про опыт миграции одной SAP системы я упоминал о ситуации, когда онлайн журнальные файлы (r edo log files ) Oracle оказались узким местом при импорте данных. Решением стало пересоздание данных файлов намного большего размера. Давайте поговорим об этом более детально.
Про журнальные файлы Oracle я рассказывал в этом посте. Существует два вида данных журналов - онлайн и оффлайн. Вторые являются копией первых при активации режима работы базы данных - ARCHIVELOG MODE . Именно про этот режим в большей степени был мой прошлый пост. Сегодняшний же рассказ про первый вид - online redo log files .
В утилите BR*Tools перейти по меню "2 - Space management -> 7 - Additional space functions -> 3 - Show redolog files -> cont, cont, cont" (рис. 2).
Первый запрос изменяет формат экрана для удобного просмотра результатов работы второго. А второй собирает информацию из двух системных представлений (Oracle Views) V$LOGFILE и V$LOG . Результатом будет список онлайн журналов с размером и статусом (рис. 3).
Как видно из снимков экранов в данном случае в системе 4 группы онлайн журнальных файлов, в каждой группе по 2 копии файлов, а размер каждого файла 200 Мб. Данные журналы используются по кругу, предыдущая информация каждый раз перезаписывается. В текущий момент времени запись может производиться только в одну группу. На снимках экранов это четвёртая группа файлов, она имеет статус CURRENT . Те журнальные файлы, записи в которых уже были внесены в дата-файлы, имеют статус INACTIVE . То есть система помечает, что их можно перезаписать. И существует еще статус ACTIVE, когда указатель переключился на следующий журнал, но перезаписывать журнал ещё нельзя. Так как СУБД ещё не зафиксировала данные изменения в дата-файлах.
Задача пересоздания онлайн журналов может возникнуть по разным причинам. Например, для решения проблемы с производительностью, когда в системном журнале Oracle наблюдаются ошибки вида 'Chekpoint not complete' (SAP note 79341 - Checkpoint not complete) и рекомендуется увеличить размер журнальных файлов. Или как в моей истории при импорте большого объёма данных в систему. Иногда бывает необходимо перенести файлы журналов в другое место, изменить состав групп или решить другие подобные административные задачи.
Пересоздать отдельную группу онлайн журнальных файлов можно на живую, при работающей системе. Единственное условие - группа не должна использоваться, то есть должна находиться в статусе INACTIVE . Для выполнения операции придётся использовать SQLPlus . В BR*Tools такой функциональности не предусмотрено. Ну и, как вы поймёте из описания процедуры, необходимо выбрать период с минимальной нагрузкой на систему. Нам необходимо чтобы во время проведения операции переключение между группами журналов происходило как можно реже.
Итак, перейдём к процедуре и инструментарию (набору SQL-запросов и команд). Для примера увеличим размер online redo log files до 250 Мб .
Для начала необходимо просмотреть информацию о текущем состоянии онлайн журнальных файлов, выполнив 2 SQL-запроса из списка выше (пункт 3) (рис. 4).
После этого выбираем первую неактивную группу онлайн журнальных файлов для удаления. В данном случае это группа 1 (G11). Удаление группы производится SQL-запросом вида:
Открыть еще один терминал операционной системы и в нём удалить файлы только что удалённой группы онлайн журналов. Для этого использовать команды вида:
Для удаления файлов необходимо иметь достаточные полномочия: суперпользователя root , пользователя < ora >sid (Oracle до версии 11g) либо пользователя oracle (при использовании базы данных Oracle 12c и выше) (рис. 6).
Вернуться в терминал с SQLPlus и создать удалённую группу онлайн журнальных файлов Oracle заново SQL-запросом вида:
После этого данная группа должна появиться в списке. Статус UNUSED означает что база данных эти журналы еще ни разу не использовала (рис. 7).
![]() |
Рис. 7. Процесс пересоздания онлайн журнальных файлов - 4. |
Если необходимо создать группу онлайн журнальных файлов с одним файлом, без зеркалирования, то в SQL-запросе в скобках указываем только один файл.
Повторить шаги, описанные в пунктах 3-5, для следующих групп онлайн журнальных файлов имеющих статус INACTIVE .
Для того, чтобы выполнить операцию удаления и создания для группы, файлы которой находятся в статусе ACTIVE или CURRENT , можно выбрать 2 способа. В первом случае просто подождать. Рано или поздно система заполнит текущий журнальный файл и переключится на следующий.
Во втором же случае можно выполнить следующие SQL-запросы:
ALTER SYSTEM CHECKPOINT;
Первый запрос принудительно переключает текущий журнал Oracle на следующий, а второй инициирует принудительное выполнение контрольной точки базы данных (Checkpoint). В этом случае все записи из журнала фиксируются в дата-файлах и журнал освобождается (рис. 8).
![]() |
Рис. 8. Пример переключения текущего журнального файла. |
В итоге после пересоздания всех групп журнальных файлов у вас должна получиться требуемая вам картина (рис. 9).
Подытожим. Онлайн журнальные файлы можно пересоздавать онлайн. Но для проведения операции необходимо выбирать период минимальной нагрузки на систему. Лучше предварительно создать всю последовательность команд в текстовом файле, чтобы провести операцию в максимально короткие сроки, не ловя моменты освобождения журнальных файлов нужной группы.
This chapter explains how to manage the online redo log. The current redo log is always online, unlike archived copies of a redo log. Therefore, the online redo log is usually referred to as simply the redo log .
This chapter contains the following topics:
Part III, "Automated File and Storage Management" for information about redo log files that are both created and managed by the Oracle Database server
Повреждение онлайнового журнала повторного выполнения
Включение параметра инициализации DB_BLOCK_CHECKSUM гарантирует проверку Oracle журналов повторного выполнения перед их архивированием. Если онлайновые журналы повторного выполнения повреждены, файл не может быть архивирован, и единственным решением может быть лишь их удаление и воссоздание заново. Но если есть только две группы журналов, вы не сможете этого сделать, поскольку Oracle требует постоянного наличия минимум двух групп файлов онлайновых журналов повторного выполнения. В этом случае можно создать новую (третью) группу журнала повторного выполнения и удалить текущую.
Также не удастся удалить файл онлайнового журнала повторного выполнения, если этот файл является частью текущей группы. В этом случае стратегия должна состоять в повторной инициализации файла журнала с помощью следующей команды:
Если группы журналов еще не были архивированы, можно применить следующий оператор:
Добавление групп журнала повторного выполнения
Хотя необходимо иметь минимум две группы онлайнового журнала повторного выполнения, идеальное количество таких групп для базы данных зависит только от интенсивности транзакций.
Совет. Начните с трех групп онлайнового журнала повторного выполнения и следите за журналом предупреждающих сигналов на предмет появления в нем любых ошибок журнала повторного выполнения. Если журнал сигналов часто показывает ожидание процесса-писателя журналов возможности записи в журнал, значит, следует увеличить количество групп журнала повторного выполнения.
Следующий оператор, который использует синтаксис ADD LOGFILE GROUP, добавляет новую группу журнала повторного выполнения в базу данных. Обратите внимание, что эта группа дублирована; в ней создается два файла журнала повторного выполнения, а не один:
В примере из предыдущего раздела были созданы три группы онлайнового журнала повторного выполнения, но каждая из них включала только по одному члену. Чтобы продублировать эти группы с целью повышения безопасности, потребуется добавить по одному члену в каждую группу. Для добавления одного члена в существующую группу используется оператор ADD LOGFILE MEMBER:
Как видите, размер нового члена группы журнала повторного выполнения, добавляемого в группу 2, специфицировать не понадобилось. Размер нового члена будет просто установлен равным размерам существующих членов группы.
Удаление онлайновых журналов повторного выполнения
С помощью следующей команды можно уничтожить всю группу журнала повторного выполнения:
Для удаления единственного члена группы служит такая команда:
Если файл онлайнового журнала повторного выполнения, который планируется удалить, активен или является текущим, Oracle не позволит это сделать. В этом случае сначала нужно с помощью следующей команды переключить файл журнала, после чего можно будет удалить его:
4. Force a CheckPoint
Now, we have to make all of the original groups to be INACTIVE, then drop them. An ACTIVE or CURRENT redo log group cannot be dropped.
SQL> alter system checkpoint;
6 rows selected.
9. Check Status of All Redo Logs
6 rows selected.
6 rows selected.
As you can see, "resize" is actually a repeated dropping/adding process, no magic inside. The similar techique can also be use to move redo log locations.
В начале хочу сразу обозначить, что я не являюсь супер бизоном, который знает Oracle вдоль и поперёк. С базами данных Oracle мне приходится иметь дело только с позиции SAP Basis консультанта, для которого база данных это лишь одна из компонент большой инфраструктуры. Да и мои взгляды на вопросы установки, мониторинга и администрирования сформированы через призму документации компании SAP.
Поэтому этот пост прошу воспринимать не как попытку показать какой я умный, а как попытку упорядочить картину прежде всего у себя в голове. Знаете же выражение: пока объяснял, сам понял. :)
Представим базовую часть СУБД Oracle в виде схемы, изображённой на рисунке 1. Предупреждаю сразу: тут далеко не все части и процессы Oracle. Я отобразил только те процессы и компоненты, которые важны в рамках механизмов, которые я буду описывать далее.
- инстанция базы данных, состоящая из процессов и общих областей памяти (System Global Area или SGA ),
- файлы базы данных на уровне файловой системы.
Как вы скорее всего уже знаете, при использовании базы данных Oracle в SAP системах в качестве клиентов базы данных выступают рабочие процессы SAP инстанций ( SAP WPs ). Каждому такому процессу соответствует один рабочий процесс со стороны инстанции Oracle ( shadow process ).
Самая маленькая логическая единица, которую Oracle использует при операциях с данными - это data block . При создании базы данных его размер можно выбрать, но в SAP инсталляциях размер data block всегда 8 Кб (8 192 байт).
Все данные базы данных Oracle содержатся в дата-файлах ( data files ), которые хранятся на дисковом хранилище. Однако обработка данных никогда не производится напрямую в файлах. При операциях чтения соответствующий процесс базы данных ( shadow process ) сначала копирует данные из дата-файлов в Database buffer cache (конечно, если этих данных еще нет в кэше). И только после этого передаёт данные пользователю, то есть рабочему процессу SAP. Так как все подключенные к инстанции Oracle пользователи могут совместно использовать одни и те же, скопированные из дата-файлов в Database buffer cache , данные, то данный механизм существенно ускоряет последующие операции чтения.
Размер Database buffer cache инстанции Oracle имеет ограниченный размер, так как оперативная память сервера не безгранична. Поэтому в кэше хранятся только последние прочитанные блоки данных. А перезапись блоков кэша происходит по алгоритму LRU («наиболее давно используемый»).
Любые изменения данных в базе данных (операции INSERT , UPDATE или DELETE ) также всегда производятся в Database buffer cache . При этом изменённые блоки кэша помечаются как « dirty blocks ». При копировании данных в кэш такие блоки ( dirty buffers ) не могут быть перезаписаны shadow процессами, до тех пор пока эти изменённые блоки не будут скопированы в дата-файлы. Записью « dirty blocks » занимается не shadow процесс, а специальный фоновый процесс инстанции Oracle - DBW0 (database writer).
- перед тем, как скопировать данные в кэш, shadow процесс сканирует области Database buffer cache на наличие не изменённых блоков, которые можно перезаписать. И если количество сканированных блоков достигает определённого порогового значения, то shadow процесс сигнализирует DBW0 , чтобы он записал часть « dirty blocks » на диск. DBW0 копирует часть « dirty blocks » в дата-файлы, используя алгоритм LSU (Least Number of Stream Used). После этого эти блоки в кэше становятся доступными для shadow процессов.
- в момент Checkpoint , когда DBW0 записывает все « dirty blocks » из Database buffer cache в файлы на дисках. Событие Checkpoint инициируется фоновым процессом CKPT . Детали будут чуть ниже.
Использование механизма отложенной записи повышает быстродействие. Во-первых, во многих случаях, прежде чем DBW0 скопирует блок на диск, данные в блоке могут несколько раз измениться. Во-вторых, повышается эффективность операций ввода-вывода, так как DBW0 часто выполняет запись сразу нескольких блоков параллельно.
Почти всегда можно руководствоваться правилом: чем больше данный кэш, тем быстрее работает база данных. Вспомните мой старый пост про это.
Но основанный на отложенной записи механизм должен избегать потери данных и обеспечивать консистентность базы данных, даже в случае сбоя любого компонента системы. А сбой может быть как аппаратным (например, сбой дискового хранилища), так и программным - сбой инстанции Oracle.
Как я уже рассказывал здесь, транзакция базы данных - это LUW (logical unit of work) сервера базы данных. Так как LUW всегда атомарная, то изменения из LUW должны быть или выполнены полностью, или полностью отменены. Для достижения консистентности данных (и консистентности чтения данных) в рамках концепции LUW СУБД Oracle использует Redo-записи для отката или восстановления (например, после сбоя) и Undo-записи для отката неподтверждённых (uncommitted) транзакций.
Redo-записи
Redo-записи содержат информацию необходимую и достаточную для того, чтобы реконструировать, восстановить или откатить, внесенные в базу данных с помощью SQL-запросов данные прежде всего в подтверждённых (commit) транзакциях.
Параллельно с изменением блоков данных в Database buffer cache , shadow процесс записывает Redo-записи в Redo log buffer . Это круговой буфер, находящийся в SGA , в который временно записываются все завершённые и незавершённые изменения данных. Фоновый процесс LGWR (log writer) периодически записывает порции записей из Redo log buffer последовательно на диск - в Online redo log file .
Oracle redo log file имеет заранее заданный фиксированный размер и не растёт динамически, как обычный файл. Поэтому, когда текущий Online redo log file заполняется, процесс LGWR закрывает файл и начинает запись в следующий. В SAP инсталляциях по умолчанию используется 4 группы Online redo log files по 2 копии файлов в каждой. Online redo log file , в который LGWR пишет в данный момент, называется CURRENT. А процедура переключения файлов называется log switch .
Так как количество Online redo log files также заранее ограничено, Oracle перезаписывает старые Redo-записи новыми, используя эти файлы по кругу.
Каждый log switch СУБД увеличивает LSN (log sequence number). С помощью LSN Oracle автоматически создаёт последовательные номера для Redo log files .
- при подтверждении (commit) любой транзакции,
- каждые 3 секунды,
- когда Redo log buffer полон на одну треть,
- когда DBW0 собирается записать изменённые блоки из Database buffer cache на диск, а некоторые соответствующие Redo-записи еще не были записаны в Online redo log files . Таким образом предотвращается попытка записи с опережением журналирования (write-ahead logging).
Этого достаточно для того, чтобы всегда иметь место для новых Redo-записей в Redo log buffer . При этом по умолчанию размер этого буфера при установке в SAP системах небольшой (1 - 8 Мб).
Дополнительно когда пользователь (рабочий процесс SAP) подтверждает завершение (commit) транзакции, транзакции присваивается SCN (system change number) базы данных. Oracle записывает SCN , вместе с Redo-записями транзакции в Redo log buffer . При этом DBW0 нет необходимости записывать блоки данных в момент подтверждения (commit) транзакции. Потому что в СУБД Oracle используется журналирование с опережением записи.
Новые значения модифицированных данных, которые хранятся в Redo-записях, называются «after images».
Undo-записи содержат информацию необходимую для отмены или отката любых изменений в блоках данных, которые были выполнены в результате неподтверждённых (uncommitted) транзакций .
Oracle хранит Undo-записи в специальных Undo сегментах, которые хранятся в специальном пространстве - Undo space. При этом Undo space может быть реализовано двумя способами:
- Automatic Undo Management ( AUM ),
- Manual Undo Management.
При AUM администратор должен лишь создать специальное табличное пространство - Undo tablespace ( PSAPUNDO ) достаточного размера и настроить пару параметров Oracle. Управление Undo сегментами СУБД осуществляет сама.
При ручном управлении необходимо создать и настроить некоторое количество Rollback segments , у которых необходимо тщательно рассчитать размер и параметры. Данные сегменты также располагаются в отдельном табличном пространстве ( PSAPROLL ). Про проблемы с данными сегментами у меня был отдельный пост.
Таким образом Undo-записи хранят информацию для транзакций, сохраняя её в Undo space, как минимум, до завершения транзакции. Так как данные записи используются для отката транзакций, то Undo-записи могут быть перезаписаны только после того, как транзакция будет подтверждена (commit) или сброшена (rollback).
Стоит отметить, что Oracle может использовать Undo-записи и для других целей. Например, для консистентного чтения из snapshots. В этом случае данные читаются из «before images». В то время, как происходит изменение этих же данных в ещё неподтверждённых (uncommitted) транзакциях.
Каждая база данных Oracle имеет свой контрольный файл ( control file ). Это маленький бинарный файл, необходимый как в момент старта базы данных, так и в процессе работы. Следовательно данный файл должен быть всегда доступен на запись.
Control file содержит записи, которые определяют физическую структуру и состояние базы данных. Например, в нём хранится информация о табличных пространствах, именах и положении дата-файлов и Online redo log files , а также текущий LSN .
Oracle control file очень важен для работы базы данных. Поэтому несколько копий могут быть сохранены в разных местах, а СУБД обновляет их одновременно. В SAP системах по умолчанию сконфигурировано 3 копии control files .
Checkpoint
Checkpoint это момент времени, в котором файлы базы данных находятся в консистентном состоянии. Достигается это состояние тем, что в этот момент DBW0 сбрасывает все текущие изменённые блоки из Database buffer cache в дата-файлы. За инициацию события Checkpoint отвечает специальный фоновый процесс CKPT , который и даёт команду процессу DBW0 начать запись блоков. Одновременно Checkpoint обозначает специальную позицию в Redo log .
- DBW0 активируется, получая сигнал в определённые моменты времени от фонового процесса CKTP .
- DBW0 копирует все текущие « dirty blocks » на диск. Причём, пока DBW0 закончит выполнять запись, другие блоки в кэше могут быть изменены, но они уже не записываются.
- Когда событие Checkpoint закончится (то есть будут записаны все выбранные блоки), самый старый буфер из « dirty blocks » в Database buffer cache будет обозначать точку в Redo log , после которой может быть начато восстановление в случае сбоя. Это позиция журнала и называется Checkpoint position .
- записывает информацию о Checkpoint в заголовок каждого дата-файла,
- записывает информацию о Checkpoint position в Online redo log file в контрольный файл Oracle ( control file ).
Информация о позиции Checkpoint в Online redo log file в контрольном файле необходима в процессе восстановления инстанции. Позиция Checkpoint сообщает инстанции Oracle, что все Redo-записи, которые были записаны до этого момента, не нуждаются в восстановлении. Так как эти данные уже записаны в дата-файлы.
Частота Checkpoints один из важных факторов, который напрямую влияет на время необходимое для восстановления инстанции в случае сбоя. Чем реже будут в системе происходить Checkpoints , тем большее времени будет необходимо инстанции для восстановления в случае сбоя.
Хотя частоту Checkpoint можно настроить через параметры Oracle, при разворачивании SAP систем эти параметры не используются. А Checkpoint всегда возникает только в моменты переключения Online redo log files ( log switch ).
Теперь основываясь на всех механизмах, которые были описаны выше, разберём как происходит восстановление базы данных.
Речь пойдёт не о восстановлении из резервной копии базы данных, которую должен выполнять администратор. А речь пойдёт об автоматическом восстановлении базы данных, которое СУБД производит в момент старта. Так называемое instance recovery. Оно необходимо, если предыдущий останов базы данных был выполнен не чисто, например, с опцией IMMEDIATE или ABORT. Или произошёл сбой работы сервера базы данных по аппаратной или программной причине.
- В control file находится последний Checkpoint . После этого, начиная с позиции Checkpoint , читаются Redo-записи из Online redo log files и заново проводятся все транзакции, указанные в журнале. Происходит процесс roll forward. Заметьте, что этот шаг всегда включает и проведение изменений для Undo space, то есть восстанавливаются «before images».
- Для всех заново применённых транзакций, которые не были подтверждены (commit) до сбоя или были отменены прямо перед сбоем (поэтому для них нет подтверждения в Redo log), выполняется откат. Для отката используется образ «before images» из Undo space. СУБД уверена, что это всегда возможно, потому что Undo-записи незавершённых транзакций из Undo space никогда не удаляются и не перезаписываются.
В результате после открытия консистентная база данных содержит только те изменения, которые были подтверждены (commit) перед сбоем.
Из процесса восстановления базы данных видно, что Online redo log files это одна из критически важных частей сервера Oracle. А если вспомнить, что в SAP установках Checkpoint наступает только в момент log switch , то при автоматическом восстановлении СУБД всегда нужен последний Online redo log file целиком. И если он будет потерян во время сбоя, то полное восстановление (complete recovery of database) будет невозможно. В результате чего данные будут потеряны, а база данных может оказаться в неконсистентном состоянии.
Поэтому-то Online redo log files должны храниться минимум в двух копиях, каждая из которых расположена на отдельном диске. Так же в продуктивной системе база данных должна работать в ARCHIVELOG режиме. В этом режиме фоновый процесс ARC0 (archiver) копирует каждый только что записанный Online redo log file в Offline redo log file . Offline redo log file в своём имени содержит LSN . Понятно, что копирование возможно начать только после переключения ( log switch ) и необходимо закончить до повторного возвращения процесса LGWR к этому файлу. Так как в таком режиме перезапись старых Redo-записей в Online redo log files не разрешается до тех пор, пока эти записи не скопированы в Offline redo log files .
Ну и должно соблюдаться ещё одно ограничение: могут быть перезаписаны только те Redo-записи, которые расположены до позиции Checkpoint в Redo log . То есть соответствующие им изменения уже записаны в дата-файлы. Это гарант возможности автоматического восстановления инстанции в случае сбоя.
Если хотите разобраться в вопросах администрирования базы данных Oracle на практике, то можете приобрести мой обучающий курс SAPADM 2.0. Этой теме в курсе полностью посвящён третий пакет заданий.
1. Check Current Redo Logs
They are all 50MB.
Создание групп онлайнового журнала повторного выполнения
Группы онлайнового журнала повторного выполнения
В случае мультиплексирования журнала повторного выполнения поддерживаются идентичные копии одних и тех же файлов. Предположим, что вы создаете две копии файла журнала повторного выполнения. Понадобится создать группу журналов повторного выполнения, которая будет включать эти два идентичных файла, именуемых членами группы. В любой заданный момент времени процесс LGWR будет писать в одну группу файлов онлайнового журнала повторного выполнения, и члены этой группы будут называться текущими.
Ниже описаны некоторые базовые условия для групп журнала повторного выполнения Oracle.
- Все файлы журнала повторного выполнения в группе должны иметь одинаковый размер.
- Хотя можно разместить оба члена группы онлайнового журнала повторного выполнения на одном физическом диске, разумнее разнести их по разным дискам, чтобы идентичные копии страховали друг друга на случай сбоя диска; в такой ситуации пострадает только один из членов группы. Oracle продолжит писать в уцелевшие члены группы онлайнового журнала повторного выполнения, когда один член окажется недоступным для записи (возможно, из-за проблем с дисковым приводом).
5. Drop Group 1, 2, 3
SQL> alter database drop logfile group 1, group 2, group 3;
8. Switch Logfile Several Times
SQL> alter system switch logfile;
3. Switch Logfile to New Groups
Make some redo log switching until you see Log Writer Process (LGWR) is working on the new redo.
SQL> alter system switch logfile;
6 rows selected.
Переименование файлов журнала повторного выполнения
Для переименования файла журнала повторного выполнения выполните следующие шаги.
- Остановите базу данных и запустите ее в смонтированном режиме:
- Переместите файлы в новое местоположение командой операционной системы:
- Воспользуйтесь командой ALTER DATABASE RENAME datafile TO для переименования этого файла внутри управляющего файла:
Planning the Redo Log
This section provides guidelines you should consider when configuring a database instance redo log and contains the following topics:
Онлайновые журналы повторного выполнения (redo logs) — это средства Oracle, благодаря которым гарантируется, что все изменения, проведенные пользователями, будут зафиксированы в журналах на случай, если произойдет сбой между моментом проведения изменений и моментом записи их в постоянное хранилище. Таким образом, журналы повторного выполнения — основа процесса восстановления.
Oracle организует свои файлы журналов повторного выполнения в группы журналов, и нужно иметь как минимум две разных группы журналов повторного выполнения и, минимум, по одному члену в каждом. Потребуется, самое меньшее, две группы, потому что когда один журнал повторного выполнения архивируется, процесс писатель журнала должен иметь возможность продолжать писать в активный журнал повторного выполнения.
Хотя база данных Oracle будет достаточно хорошо работать и с только одним членом в каждой группе журналов повторного выполнения, в Oracle настоятельно рекомендуют мультиплексировать онлайновые журналы повторного выполнения. Мультиплексирование означает просто то, что необходимо поддерживать более одного члена в каждой из групп журналов повторного выполнения. Все члены такой группы идентичны — мультиплексирование предназначено для защиты от потери одной из копий файла журнала. При мультиплексировании онлайновых журналов повторного выполнения процесс-писатель журналов выполняет запись параллельно во все файлы члены группы.
Совет. Всегда мультиплексируйте онлайновый журнал повторного выполнения, поскольку вы можете потерять данные, если случится сбой в онлайновом журнале повторного выполнения из-за проблем с диском. Мультиплексированные журналы повторного выполнения в идеале должны располагаться на разных дисковых приводах под управлением разных дисковых контроллеров.
Redo Log Contents
Redo log files are filled with redo records . A redo record, also called a redo entry , is made up of a group of change vectors , each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to the data segment block for the table, the undo segment data block, and the transaction table of the undo segments.
Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.
Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see "How Oracle Database Writes to the Redo Log") and are written to one of the redo log files by the Log Writer (LGWR) database background process. Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.
Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed. If necessary, the database can roll back these changes.
Redo Threads
When speaking in the context of multiple database instances, the redo log for each database instance is also referred to as a redo thread . In typical configurations, only one database instance accesses an Oracle Database, so only one thread is present. In an Oracle Real Application Clusters environment, however, two or more instances concurrently access a single database and each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo log files, thereby eliminating a potential performance bottleneck.
This chapter describes how to configure and manage the redo log on a standard single-instance Oracle Database. The thread number can be assumed to be 1 in all discussions and examples of statements. For information about redo log groups in a Real Application Clusters environment, please refer to Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide .
2. Add 3 Groups with New Size (1GB)
SQL> alter database add logfile group 4 ('/u01/app/oracle/oradata/ORCL/redo04.log') size 1g, group 5 ('/u01/app/oracle/oradata/ORCL/redo05.log') size 1g, group 6 ('/u01/app/oracle/oradata/ORCL/redo06.log') size 1g;
6 rows selected.
What Is the Redo Log?
The most crucial structure for recovery operations is the redo log , which consists of two or more preallocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.
How Oracle Database Writes to the Redo Log
The redo log of a database consists of two or more redo log files. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). See "Managing Archived Redo Logs" for more information.
LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure 6-1 illustrates the circular writing of the redo log file. The numbers next to each line indicate the sequence in which LGWR writes to each redo log file.
Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.
If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the datafiles.
If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file is available to LGWR after the changes recorded in it have been written to the datafiles and the file has been archived.
Figure 6-1 Reuse of Redo Log Files by LGWR
Active (Current) and Inactive Redo Log Files
Oracle Database uses only one redo log files at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file.
Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.
If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARC n ) has archived its contents. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the first available active file.
Log Switches and Log Sequence Numbers
A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.
Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.
Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.
Сравнение аппаратного зеркального отображения и мультиплексирования Oracle
Зеркальное отображение защитит данные от дисковых сбоев, но не защитит от непреднамеренного удаления файлов. Мультиплексирование гарантирует защиту файлов от подобного рода ошибок.
Если вы потеряете онлайновый журнал повторного выполнения, то можете утратить важные данные, поэтому при мультиплексированной системе журналов повторного выполнения фоновый процесс LGWR, который отвечает за запись данных из буфера журнала повторного выполнения, пишет одновременно во все (идентичные) файлы-члены мультиплексированной группы. Если возникнут проблемы записи в один из членов мультиплексированной группы журналов повторного выполнения, запись в другие члены группы пройдет беспрепятственно.
Мониторинг журналов повторного выполнения
Для мониторинга журналов повторного выполнения применяются два ключевых динамических представления — V$LOG и V$LOGFILE.
Представление V$LOGFILE содержит полные имена файлов журналов повторного выполнения, их состояние и тип, как показано ниже:
Представление V$LOG выдает детальную информацию о размерах и состоянии журналов повторного выполнения, а также показывает, были ли журналы архивированы:
The default size of redo logs during installation is 50MB which is too small for production databases. Of course, you can change the size of redo logs for your needs in DBCA if you know where to make the change.
As for built databases that you took over from other DBA, 50MB of redo logs could be very annoying because it makes log switching very frequently, most likely, you'll see:
Furthermore, it causes a lot of trivial and small sized files. In my opinion, 1GB of redo logs may be more appropriate for a production database.
To increase redo log size from 50MB to 1GB, we take the following steps to reach the goal.
But don't expect too much, there's no syntax available in Oracle to resize redo logs directly. In fact, the technique we used is a process of file replacement, you need to do it carefully.
6. Remove Redo Log Files
Now, you have to remove these physical log files by yourself, otherwise you will receive ORA-27038: created file already exists.
Be careful, don't remove online redo logs accidentally. A better practice to remove such sensitive files is to use interactive mode of rm .
[oracle@test ~]$ rm -i /u01/app/oracle/oradata/ORCL/redo01.log
rm: remove regular file `/u01/app/oracle/oradata/ORCL/redo01.log'? y
rm: remove regular file `/u01/app/oracle/oradata/ORCL/redo02.log'? y
rm: remove regular file `/u01/app/oracle/oradata/ORCL/redo03.log'? y
7. Add Group 1, 2, 3 with New Size (1GB)
SQL> alter database add logfile group 1 ('/u01/app/oracle/oradata/ORCL/redo01.log') size 1g, group 2 ('/u01/app/oracle/oradata/ORCL/redo02.log') size 1g, group 3 ('/u01/app/oracle/oradata/ORCL/redo03.log') size 1g;
6 rows selected.
Читайте также: