Управление онлайновыми журналами Oracle Redo logs

Андрей Волков

Андрей Волков

Системное, сетевое администрирование +DBA. И немного программист!))  Профиль автора.

Online redo logs - управление журнальными файлами в базе данных OracleОнлайновые журналы повторного выполнения (redo logs) — это средства Oracle, благодаря которым гарантируется, что все изменения, проведенные пользователями, будут зафиксированы в журналах на случай, если произойдет сбой между моментом проведения изменений и моментом записи их в постоянное хранилище. Таким образом, журналы повторного выполнения — основа процесса восстановления.

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

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


Совет. Всегда мультиплексируйте онлайновый журнал повторного выполнения, поскольку вы можете потерять данные, если случится сбой в онлайновом журнале повторного выполнения из-за проблем с диском. Мультиплексированные журналы повторного выполнения в идеале должны располагаться на разных дисковых приводах под управлением разных дисковых контроллеров.


 

Сравнение аппаратного зеркального отображения и мультиплексирования Oracle

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

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

Мультиплексирование redo log файлов в Oracle

 

Группы онлайнового журнала повторного выполнения

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

Ниже описаны некоторые базовые условия для групп журнала повторного выполнения Oracle.

  • Все файлы журнала повторного выполнения в группе должны иметь одинаковый размер.
  • Хотя можно разместить оба члена группы онлайнового журнала повторного выполнения на одном физическом диске, разумнее разнести их по разным дискам, чтобы идентичные копии страховали друг друга на случай сбоя диска; в такой ситуации пострадает только один из членов группы. Oracle продолжит писать в уцелевшие члены группы онлайнового журнала повторного выполнения, когда один член окажется недоступным для записи (возможно, из-за проблем с дисковым приводом).

 

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

SQL> CREATE DATABASE
     . . .
     LOGFILE GROUP 1 ('/u01/app/oracle/nicko/redo01.log') SIZE 100M,
             GROUP 2 ('/u01/app/oracle/nicko/redo02.log') SIZE 100M,
             GROUP 3 ('/u01/app/oracle/nicko/redo03.log') SIZE 100M,
     . . .
Database created.
SQL> 

 

Добавление групп журнала повторного выполнения

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


Совет. Начните с трех групп онлайнового журнала повторного выполнения и следите за журналом предупреждающих сигналов на предмет появления в нем любых ошибок журнала повторного выполнения. Если журнал сигналов часто показывает ожидание процесса-писателя журналов возможности записи в журнал, значит, следует увеличить количество групп журнала повторного выполнения.


Следующий оператор, который использует синтаксис ADD LOGFILE GROUP, добавляет новую группу журнала повторного выполнения в базу данных. Обратите внимание, что эта группа дублирована; в ней создается два файла журнала повторного выполнения, а не один: 

SQL> ALTER DATABASE
     ADD LOGFILE GROUP 4 ('/u01/app/oracle/nicko/log4a.rdo',
                          '/u01/app/oracle/nicko/log4b.rdo') SIZE 500M;
Database altered.
SQL>

В примере из предыдущего раздела были созданы три группы онлайнового журнала повторного выполнения, но каждая из них включала только по одному члену. Чтобы продублировать эти группы с целью повышения безопасности, потребуется добавить по одному члену в каждую группу. Для добавления одного члена в существующую группу используется оператор ADD LOGFILE MEMBER

SQL> ALTER DATABASE ADD LOGFILE MEMBER
     '/u01/app/oracle/nicko/log1b.rdo'
     TO GROUP 2;
Database altered.
SQL>

Как видите, размер нового члена группы журнала повторного выполнения, добавляемого в группу 2, специфицировать не понадобилось. Размер нового члена будет просто установлен равным размерам существующих членов группы.

 

Переименование файлов журнала повторного выполнения

Для переименования файла журнала повторного выполнения выполните следующие шаги.

  1. Остановите базу данных и запустите ее в смонтированном режиме: 
    SQL> STARTUP MOUNT 
    
  2. Переместите файлы в новое местоположение командой операционной системы:
    SQL> host mv /u10/app/oracle/oradata/nina/log01.rdo
    /a10/app/oracle/oradata/nina/log01.rdo 
    
  3. Воспользуйтесь командой ALTER DATABASE RENAME datafile TO для переименования этого файла внутри управляющего файла:
    SQL> ALTER DATABASE RENAME
    '/u10/app/oracle/oradata/nina/log01.rdo' TO
    '/a10/app/oracle/oradata/nina/log01.rdo'; 
    

 

Удаление онлайновых журналов повторного выполнения

С помощью следующей команды можно уничтожить всю группу журнала повторного выполнения:

SQL> ALTER DATABASE DROP LOGFILE GROUP 3; 

Для удаления единственного члена группы служит такая команда:

SQL> ALTER DATABASE DROP LOGFILE MEMBER '/u01/app/oracle/oradata/nina/log01.rdo'; 

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

SQL> ALTER SYSTEM SWITCH LOGFILE;

 

Повреждение онлайнового журнала повторного выполнения

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

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

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;

Если группы журналов еще не были архивированы, можно применить следующий оператор:

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1; 

 

Мониторинг журналов повторного выполнения

Для мониторинга журналов повторного выполнения применяются два ключевых динамических представления — V$LOG и V$LOGFILE.

Представление V$LOGFILE содержит полные имена файлов журналов повторного выполнения, их состояние и тип, как показано ниже:

SQL> SELECT * FROM V$LOGFILE;
GROUP #   STATUS    TYPE                  MEMBER
--------  -------  ------  --------------------------------------
   3      STALE    ONLINE  /u10/app/oracle/oradata/nina/log01.rdo
   2               ONLINE  /u10/app/oracle/oradata/nina/log01.rdo
   1               ONLINE  /u10/app/oracle/oradata/nina/log01.rdo
3 rows selected. 

Представление V$LOG выдает детальную информацию о размерах и состоянии журналов повторного выполнения, а также показывает, были ли журналы архивированы:

SQL> SELECT group#, sequence#, bytes, archived, members, status
2* FROM V$LOG;
  GROUP#    SEQUENCE#      BYTE     ARCHIVED   MEMBERS      STATUS
----------  ----------  ----------  ---------  --------  ------------
    1           8       104857600      NO         1        INACTIVE
    2          10       104857600      NO         1         CURRENT
    3           7       104857600      NO         1        INACTIVE
    4           9        10485760      NO         3        INACTIVE
SQL>

Вас заинтересует / Intresting for you:

Oracle и непроцедурный доступ ...
Oracle и непроцедурный доступ ... 8524 просмотров Antoni Tue, 21 Nov 2017, 13:32:50
Создание базы данных Oracle
Создание базы данных Oracle 34442 просмотров Александров Попков Wed, 14 Nov 2018, 12:44:39
Видеокурс по администрированию...
Видеокурс по администрированию... 10719 просмотров Илья Дергунов Mon, 14 May 2018, 05:08:47
СУБД Oracle: обзор характерист...
СУБД Oracle: обзор характерист... 15814 просмотров Antoni Fri, 24 Nov 2017, 07:35:05
Войдите чтобы комментировать