Восстановление из резервной копии Oracle RMAN приводит к сбою около 60% времени (режим noarchivelog)

Question

У меня странный случай, когда восстановление созданной резервной копии Oracle RMAN иногда срабатывает, а в другое время нет.

Мы используем Oracle 12c. База данных работает в режиме noarchivelog.

Полная версия: У нас есть большая установка CI, где узел может занять задание, строить себя из репо и запускать тесты. Для некоторых тестов требуется сборка базы данных. Для ускорения испытаний мы

• Первая попытка восстановления базы данных из резервной копии.
• Если это не удается, мы удаляем базу данных, перестраиваем оболочку и данные. Повторно создайте резервную копию и запустите тесты.

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

Мы используем следующий скрипт для резервного копирования

rman target=/ << EOF 
RUN { 
    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; 
    SHUTDOWN IMMEDIATE; 
    STARTUP MOUNT; 
    BACKUP DATABASE; 
} 
EXIT; 
EOF 

и последующее восстановление

rman target=/ << EOF 
RUN { 
    SHUTDOWN IMMEDIATE; 
    STARTUP MOUNT; 
    RESTORE DATABASE; 
    RECOVER DATABASE; 
    ALTER DATABASE OPEN RESETLOGS; 
} 
EXIT; 
EOF 

Когда дела идут плохо, это происходит на этапе выздороветь.

Ошибки не всегда одинаковы. Ниже приведены некоторые, которые я видел

Это один, как представляется, наиболее часто в последнее время

04:23:10 channel ORA_DISK_1: restore complete, elapsed time: 00:00:15 
04:23:10 Finished restore at 06-02-2017 04:23:10 
04:23:10 
04:23:10 Starting recover at 06-02-2017 04:23:10 
04:23:10 using channel ORA_DISK_1 
04:23:11 
04:23:11 starting media recovery 
04:23:11 
04:23:11 archived log for thread 1 with sequence 52 is already on disk as file /oracle/oradata/DB1/redoDB11.log 
04:23:11 archived log for thread 1 with sequence 53 is already on disk as file /oracle/oradata/DB1/redoDB12.log 
04:23:11 archived log for thread 1 with sequence 54 is already on disk as file /oracle/oradata/DB1/redoDB13.log 
04:23:11 RMAN-08187: WARNING: media recovery until SCN 1662458 complete 
04:23:11 Finished recover at 06-02-2017 04:23:11 
04:23:11 
04:23:15 RMAN-00571: =========================================================== 
04:23:15 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
04:23:15 RMAN-00571: =========================================================== 
04:23:15 RMAN-03002: failure of sql statement command at 02/06/2017 04:23:14 
04:23:15 ORA-01147: SYSTEM tablespace file 1 is offline 
04:23:15 ORA-01110: data file 1: '/oracle/oradata/DB1/DB1_system.dbf' 
04:23:15 
04:23:15 RMAN> 
04:23:15 
04:23:15 Recovery Manager complete. 

Другая ошибка

09:49:17 Finished restore at 27-01-2017 09:49:14 
09:49:17 
09:49:17 Starting recover at 27-01-2017 09:49:14 
09:49:17 using channel ORA_DISK_1 
09:49:17 
09:49:17 starting media recovery 
09:49:17 
09:49:17 archived log for thread 1 with sequence 52 is already on disk as file /oracle/oradata/DB1/redoDB11.log 
09:49:17 archived log for thread 1 with sequence 53 is already on disk as file /oracle/oradata/DB1/redoDB12.log 
09:49:17 archived log for thread 1 with sequence 54 is already on disk as file /oracle/oradata/DB1/redoDB13.log 
09:49:17 RMAN-08187: WARNING: media recovery until SCN 1755105 complete 
09:49:17 Finished recover at 27-01-2017 09:49:15 
09:49:17 
09:49:17 RMAN-00571: =========================================================== 
09:49:17 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
09:49:17 RMAN-00571: =========================================================== 
09:49:17 RMAN-03002: failure of sql statement command at 01/27/2017 09:49:16 
09:49:17 ORA-01147: SYSTEM tablespace file 1 is offline 
09:49:17 ORA-01110: data file 1: '/oracle/oradata/DB1/DB1_system.dbf' 
09:49:17 
09:49:17 RMAN> 

И еще один

11:17:55 starting media recovery 
11:17:55 media recovery failed 
11:17:55 RMAN-00571: =========================================================== 
11:17:55 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
11:17:55 RMAN-00571: =========================================================== 
11:17:55 RMAN-03002: failure of recover command at 01/27/2017 11:17:55 
11:17:55 ORA-00283: recovery session canceled due to errors 
11:17:55 RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed 
11:17:55 start until cancel 
11:17:55 ORA-00283: recovery session canceled due to errors 
11:17:55 ORA-16433: The database or pluggable database must be opened in read/write mode. 
11:17:55 
11:17:55 RMAN> 

И еще который отличается от вышеприведенных трех, эта ошибка терпит неудачу при ВОССТАНОВЛЕНИИ

09:14:11 Starting restore at 06-02-2017 09:14:11 
09:14:11 allocated channel: ORA_DISK_1 
09:14:11 channel ORA_DISK_1: SID=12 device type=DISK 
09:14:12 
09:14:12 creating datafile file number=1 name=/oracle/oradata/DB1/DB1_system.dbf 
09:14:12 RMAN-00571: =========================================================== 
09:14:12 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
09:14:12 RMAN-00571: =========================================================== 
09:14:12 RMAN-03002: failure of restore command at 02/06/2017 09:14:12 
09:14:12 ORA-01180: can not create datafile 1 
09:14:12 ORA-01110: data file 1: '/oracle/oradata/DB1/DB1_system.dbf' 
09:14:12 
09:14:12 RMAN> 

Любая помощь будет очень признательна. Спасибо!

Answer 1

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

RESTORE DATABASE; 
RECOVER DATABASE; 
ALTER DATABASE OPEN RESETLOGS; 

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

RECOVER DATABASE; Первые попытки сделать вашу резервную копию последовательной, применяя резервные архивные журналы повторного использования, архивированные журналы повтора и/или повторные журналы. Затем он попытается свернуть вашу базу данных вперед от точки резервного копирования до самого последнего журнала повтора. Поскольку вы работаете в режиме NOARCHIVELOG, этот шаг приведет к появлению ошибок, подобных тем, которые вы видите.

ALTER DATABASE OPEN RESETLOGS; приносит вашу базу данных он-лайн. RESETLOGS очищает журналы повтора, и это необходимо после неполного восстановления (если база данных не может выполнить перемотку вперед и применить весь повтор из архивных архивов, архивных журналов и журналов повтора).

Имея это в виду, ваш скрипт должен выглядеть следующим образом:

RUN { 
    SHUTDOWN IMMEDIATE; 
    STARTUP MOUNT; 
    RESTORE DATABASE; 
    ALTER DATABASE OPEN RESETLOGS; 
} 

В качестве примечания, вы должны также настроить SPFILE + CONTROLFILE Autobackup из RMAN. Эта резервная копия автоматически берется при резервном копировании базы данных.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; 
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; 

Как JSapkoka сказал, вы должны также восстановить SPFILE и CONTROLFILE первой, а также, что, полное восстановление сценарий будет выглядеть примерно так:

RUN { 
    SHUTDOWN IMMEDIATE; 
    STARTUP NOMOUNT; 
    SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'autobackup_format'; 
    RESTORE SPFILE FROM AUTOBACKUP; 
    SHUTDOWN IMMEDIATE; 
    STARTUP NOMOUNT; 
    RESTORE CONTROLFILE FROM AUTOBACKUP; 
    ALTER DATABASE MOUNT; 
    RESTORE DATABASE; 
    ALTER DATABASE OPEN RESETLOGS; 
}