Операции по управлению процессами восстановления подвержены большему количеству ошибок и потому нуждаются в устранении неполадок больше каких-либо других операций по администрированию баз данных Oracle. Если выполнение процедуры восстановления в производственной среде постоянно сопровождается выдачей ошибок Oracle, оно становится лишь более стрессовым событием. За годы работы администратор баз данных может столкнуться с множеством различных проблем. В этой статье моего блога рассказывается о нескольких наиболее типичных сообщениях об ошибках, которые могут появляться во время сеанса восстановления.
Ошибка ORA-01194
При попытке запустить базу данных после выполнения процедуры клонирования базы данных обычно будет появляться ошибка ORA-01194. В листинге 1 ниже показана возможная последовательность сообщений Oracle и ответов администратора баз данных.
SQL> startup
ORACLE instance started.
Total System Global Area 118255568 bytes
Fixed Size 282576 bytes
Variable Size 83886080 bytes
Database Buffers 33554432 bytes
Redo Buffers 532480 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
для открытия базы данных требуется обязательно использовать
параметр RESETLOGS или NORESETLOGS
SQL> alter database open noresetlogs;
alter database open noresetlogs
*
ERROR at line 1:
ORA-01588: must use RESETLOGS option for database open
для открытия базы данных требуется обязательно использовать
параметр RESETLOGS
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
файл 1 нуждается в дополнительном восстановлении,
чтобы быть согласованным
ORA-01110: data file 1: 'C:\ORACLENT\ORADATA\MANAGER\SYSTEM01.DBF'
файл данных 1: 'C:\ORACLENT\ORADATA\MANAGER\SYSTEM01.DBF'
SQL> recover database until cancel using backup controlfile;
ORA-00279: change 405719 generated at 05/26/2008 15:51:04 needed for thread 1
для потока 1 требуется изменение 405719, сгенерированное 05/26/2008 15:51:04
ORA-00289: suggestion : C:\ORACLENT\RDBMS\ARC00019.001
предлагается использовать: C:\ORACLENT\RDBMS\ARC00019.001
ORA-00280: change 405719 for thread 1 is in sequence #19
необходимое для потока 1 изменение 405719 находится в журнале
с порядковым номером 19
Specify log: {=suggested | filename | AUTO | CANCEL}
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
предупреждение: процедура RECOVER удалась, но OPEN RESETLOGS приведет
к выдаче показанной ниже ошибки
ORA-01194: file 1 needs more recovery to be consistent
файл 1 нуждается в дополнительном восстановлении,
чтобы быть согласованным
ORA-01110: data file 1: 'C:\ORACLENT\ORADATA\MANAGER\SYSTEM01.DBF'
файл данных 1: 'C:\ORACLENT\ORADATA\MANAGER\SYSTEM01.DBF'
SQL
Oracle будет продолжать выдавать сообщение об ошибке ORA-01194, и даже применение команды RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE (позволяющей имитировать восстановление) не поможет остановить это. Проблема состоит в том, что необходимые для выполнения восстановления изменения находятся в самом последнем оперативном журнале повторного выполнения, а не в каком-то архивном журнале, который Oracle может предлагать. После применения этого оперативного журнала повторного выполнения, Oracle сможет завершить процедуру восстановления успешно, как показано в листинге 2:
SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;
ORA-00279: change 405719 generated at 06/30/2008 15:51:04 needed for thread 1
для потока 1 требуется изменение 405719, сгенерированное 05/26/2008 15:51:04
ORA-00289: suggestion : C:\ORACLENT\RDBMS\ARC00019.001
предлагается использовать: C:\ORACLENT\RDBMS\ARC00019.001
ORA-00280: change 405719 for thread 1 is in sequence #19
необходимое для потока 1 изменение 405719 находится в журнале
с порядковым номером 19
Specify log: {=suggested | filename | AUTO | CANCEL}
C:\ORACLENT\ORADATA\MANAGER\REDO03.LOG
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
SQL>
Ошибка ORA-01152
Ошибка ORA-01152 (сопровождаемая сообщением “File # was not restored from a sufficiently old backup” (“Файл # не был восстановлен из достаточно старой резервной копии”)) преследует довольно многие сеансы по восстановлению данных. Она представляет собой довольно интересную ситуацию и имеет подобное предыдущему примеру решение. Администратор предоставляет все архивные журналы повторного выполнения, которые запрашивает Oracle, но все равно получает эту же ошибку, как показано в листинге 3 ниже:
ORA-00289: suggestion: /u01/app/oracle/admin/finance/arch/finance/_0000012976.arc
предлагается использовать: /u01/app/oracle/admin/finance/arch/
finance/_0000012976.arc
ORA-00280: change 962725326 for thread 1 is in sequence #12976
необходимое для потока 1 изменение 962725326 находится в журнале
с порядковым номером #12976
ORA-00278: logfile '/u01/app/oracle/admin/finance/arch/finance/_0000012975.arc'
no longer needed for this recovery
файл журнала '/u01/app/oracle/admin/finance/arch/finance/_0000012975.arc'
больше не требуется для данного процесса восстановления
Specify log: {=suggested | filename | AUTO | CANCEL}
Укажите журнал: {=suggested | filename | AUTO | CANCEL}
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
предупреждение: процедура RECOVER удалась, но OPEN RESETLOGS приведет
к выдаче показанной ниже ошибки
ORA-01152: file 1 was not restored from a sufficiently old backup
файл 1 не был восстановлен из достаточно старой резервной копии
ORA-01110: data file 1: '/pase16/oradata/finance/system_01.dbf'
файл данных 1: '/pase16/oradata/finance/system_01.dbf'
ORA-01112: media recovery not started
восстановление носителя не запущено
В ответ на предыдущие ошибки была использована следующая команда RECOVER:
SQL> recover database until cancel using backup controlfile; ORA-00279: change 962726675 generated at 07/30/2008 04:32:48 needed for thread 1 необходимое для потока 1 изменение 962725326 было сгенерировано 07/30/2008 04:32:48 ORA-00289: suggestion : /u01/app/oracle/admin/finance/arch/finance/_0000012977.arc предлагается использовать:/u01/app/oracle/admin/finance/arch/finance/ _0000012977.arc ORA-00280: change 962726675 for thread 1 is in sequence #12977 необходимое для потока 1 изменение 962725326 находится в журнале с порядковым номером #12976
В ответ Oracle снова запрашивает архивный журнал повторного выполнения, но поскольку в процессе восстановления уже было сказано о том, что никаких архивных журналов повторного выполнения больше использовать не нужно, можно проигнорировать этот вводящий в заблуждение запрос и предоставить Oracle имена восстановленных оперативных журналов повторного выполнения, начиная с самого первого. В одном из них как раз и будет присутствовать запрашиваемый процессом восстановления номер изменения (SCN=962726675). То есть достаточно указать Oracle на свои файлы журналов повторного выполнения, а точнее — на один из каждой группы этих журналов. В листинге 4 показана остальная часть данного процесса восстановления.
Specify log: {=suggested | filename | AUTO | CANCEL}
/pase04/oradata/finance/redo01a.rdo
ORA-00279: change 962746677 generated at 07/30/2008 04:33:52 needed for thread 1
необходимое для потока 1 изменение 962725326 было
сгенерировано 07/30/2008 04:32:48
ORA-00289: suggestion : /u01/app/oracle/admin/finance/arch/finance/_0000012978.arc
предлагается использовать:/u01/app/oracle/admin/finance/arch/finance/
_0000012978.arc
ORA-00280: change 962746677 for thread 1 is in sequence #12978
необходимое для потока 1 изменение 962725326 находится в журнале
с порядковым номером #12976
ORA-00278: log file '/pase04/oradata/finance/redo01a.rdo'no longer needed for
this recovery
файл журнала '/u01/app/oracle/admin/finance/arch/finance/_0000012975.
arc' больше не требуется для данного процесса восстановления
Specify log: {=suggested | filename | AUTO | CANCEL}
/pase04/oradata/finance/redo02a.rdo
Log applied.
Media recovery complete.
SQL>
Ошибка ORA-00376
Другой типичной ошибкой, которая может часто встречаться во время сеансов восстановления, является ORA-00376, обозначающая, что базе данных не удается прочитать определенный файл или файлы. Она приводит к появлению таких сообщений:
ORA-00376: file 10 cannot be read at this time файл 10 не удается прочитать в этот момент ORA-01110: data file 10: '/u01/app/oracle/remorse/data_01.dbf' файл данных 10: '/u01/app/oracle/remorse/data_01.dbf'
Как правило, ошибка ORA-00376 возникает из-за пребывания файла данных или табличного пространства в автономном режиме. Перевод табличного пространства или файла данных обратно в оперативный режим позволяет легко устранить проблему. Иногда эта ошибка также возникает из-за несуществования файла данных на уровне табличного пространства. В таком случае табличное пространство потребуется переести в автономный режим, воссоздавать его с правильным именем файла данных и затем снова вернуть в оперативный режим.
Функция Flashback Transaction Backout
Предлагаемая в Oracle функция Flashback Transaction Backout (ретроспективная отмена транзакций) позволяет откатывать или отменять даже уже зафиксированные транзакции. С ее помощью можно выполнять откат транзакции, а также всех зависимых от нее транзакций, без перевода базы данных в автономный режим. Oracle использует данные отката для создания так называемых компенсационных транзакций (compensation transactions) и возвращает данные в состояние, в котором они находились до изменения. Если набор связанных транзакций состоит из сложных операций вставки, обновления и удаления, функция Flashback Transaction Backout позволяет отменять весь набор изменений буквально одним щелчком (в случае использования интерфейса Database Control).
Для выполнения ретроспективной отмены транзакций применяется процедура TRANSACTION_BACKOUT из пакета DBMS_FLASHBACK. Структура этой процедуры выглядит так:
PROCEDURE TRANSACTION_BACKOUT Argument Name Type In/Out Default? ----------------- ------------- -------- ---------- NUMTXNS NUMBER IN NAMES TXNAME_ARRAY IN OPTIONS BINARY_INTEGER IN DEFAULT TIMEHINT TIMESTAMP IN
Функция ретроспективной отмены работает главным образом за счет данных отката, которые сохраняются в табличном пространстве отката. Однако базе данных также требуются и данные повторного выполнения, генерируемые блоками отмены. Поэтому для выполнения операции Flashback Transaction Backout необходимо иметь доступ как к сегментам отката, так и к архивным журналами повторного выполнения.
Предварительные условия
Прежде чем использовать функцию Flashback Transaction Backout, нужно обязательно включить в базе данных дополнительную журнализацию:
SQL> alter database add supplemental log data; SQL> alter database add supplemental log data (primary key) columns;
При желании разрешить пользоваться функцией Flashback Transaction Backout какому-то пользователю, необходимо выдать ему следующие привилегии:
SQL> grant execute on dbms_flashback to hr; SQL> grant select any transaction to hr;
Помимо этого, если пользователь захочет выполнять откат транзакций, в которых задействованы таблицы, принадлежащие схеме другого пользователя, ему потребуется иметь соответствующие DML-привилегии на уровне объектов другого пользователя.
Отмена транзакций
Для выполнения отмены транзакции, как уже упоминалось выше, нужно использовать процедуру DBMS_FLASHBACK.TRANSACTION_BACKOUT. Эта процедура имеет следующие параметры:
PROCEDURE TRANSACTION_BACKOUT Argument Name Type In/Out Default? -------------- --------------- ------- ---------- NUMBEROFXIDS NUMBER IN XIDS XID_ARRAY IN OPTIONS BINARY_INTEGER IN DEFAULT SCNHINT TIMESTAMP IN
Ниже показано, что означают эти параметры.
- numberofxids — количество подлежащих отмене транзакций.
- xids — список идентификаторов транзакций, которые должны передаваться в виде массива.
- options — опции отмены, касающиеся порядка, в котором должны отменяться родительские и дочерние транзакции. Эти опции перечислены ниже.
- nocascade — используется по умолчанию и предусматривает выполнение отмены транзакций, у которых не должно быть никаких зависимых транзакций.
- cascade — предусматривает выполнение отмены сначала зависимых транзакций, а потом родительских.
- nocascade_force — предусматривает выполнение отмены только родительских транзакций и игнорирование всех зависимых транзакций.
- noconflict_only — предусматривает выполнение отмены только тех изменений, которые не имеют конфликтных строк в транзакции.
- scnhint — SCN-номер в начале той транзакции, которая откатывается.
TRANSACTION_BACKOUT представляет собой перегруженную процедуру и потому может иметь массу вариаций, в зависимости от задаваемых параметров. Хотя и можно задавать параметр xids, еще можно указывать вместо него параметр tsnames и тем самым передавать массив имен транзакций вместо массива идентификаторов транзакций. Вместо параметра scnhint еще можно задавать параметр timehint и тем самым указывать время в начале откатываемой транзакции вместо SCN-номера. В случае использования имен транзакций, а не идентификаторов, применение параметра timehint вместо параметра scnhint является обязательным.
Чем больше данных отмены было сгенерировано транзакцией, которая отменяется, тем больше времени будет занимать ее аннулирование. При выполнении процедуры TRANSACTION_BACKOUT база данных не откатывает транзакции автоматически. Она выполняет необходимые DML-операций для отмены транзакций, но прямо перед их фиксацией останавливается и блокирует задействованные строки и таблицы, тем самым защищая ту транзакцию, которую требуется аннулировать, от воздействия других транзакций. Потом она генерирует отчет по отмене транзакции, который администратор баз данных может просматривать перед тем, как финализировать отмену транзакции путем фиксации внесенных процедурой TRANSACTION_BACKOUT изменений. Процедура TRANSACTION_BACKOUT предусматривает заполнение представлений DBA_FLASHBACK_TRANSACTION_STATE и DBA_FLASHBACK_TRANSACTION_REPORT. После выполнения отмены транзакций база данных записывает информацию о каждой из них в представление DBA_FLASHBACK_TRANSACTION_STATE. С помощью запроса к представлению DBA_FLASHBACK_TRANSACTION_REPORT можно легко просматривать отчеты по всем операциям отмены транзакций.
Использование процедуры TRANSACTION_BACKOUT
В следующем примере показано, как использовать процедуру TRANSACTION_BACKOUT для выполнения ретроспективной отмены транзакции. Прежде чем выполнять эту процедуру, нужно сначала создать переменную типа XID_ARRAY для хранения набора идентификаторов транзакций:
declare
trans_arr xid_array;
begin
trans_arr := xid_array('030003000D02540','D10001000D02550');
dbms_flashback.transaction_backout (
numtxns => 1,
xids => trans_arr,
options => dbms_flashback.nocascade
);
end;
Приведенный выше код выполняет ретроспективную отмену главных и зависимых транзакций за один шаг. Для выполнения ретроспективной отмены транзакций также можно пользоваться интерфейсом Enterprise Manager.
