Restore UNDO sem backup

Dúvidas, dicas e atualizações sobre o Treinamento Oracle Backup & Recovery.
Post Reply
gcomenale

Restore UNDO sem backup

Post by gcomenale »

Pessoal, estou tentando simular um cenário de perda de UNDO sem backup. Fazendo os procedimentos:

1 - alter system set undo_management='MANUAL' scope=spfile;
2 - create pfile from spfile
3 - shut abort;
4 - startup mount;
5 - drop datafile de UNDO e coloco OFFLINE
6 - alter database open
Depois desse passo ele me retorna que não acha o datafile da undo, mesmo eu colocando o undo_management como MANUAL e me derruba a instancia:

SQL> select status from v$instance;

STATUS
------------
MOUNTED


SQL> SELECT NAME, STATUS FROM v$DATAFILE;

NAME STATUS
--------------------------------------------- ----------
/u01/app/oracle/oradata/ORCL/system01.dbf SYSTEM
/u01/app/oracle/oradata/ORCL/soe01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/sysaux01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/undotbs01.dbf RECOVER
/u01/app/oracle/oradata/ORCL/example01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/users01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/ccdata01.dbf ONLINE
SQL> show parameter undo

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
temp_undo_enabled boolean FALSE
undo_management string MANUAL
undo_retention integer 900
undo_tablespace string UNDOTBS1

SQL> alter database datafile '/u01/app/oracle/oradata/ORCL/undotbs01.dbf' offline drop;

Database altered.

SQL> SELECT NAME, STATUS FROM v$DATAFILE;

NAME STATUS
--------------------------------------------- ----------
/u01/app/oracle/oradata/ORCL/system01.dbf SYSTEM
/u01/app/oracle/oradata/ORCL/soe01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/sysaux01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/undotbs01.dbf RECOVER
/u01/app/oracle/oradata/ORCL/example01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/users01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/ccdata01.dbf ONLINE

7 rows selected.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 4 cannot be read at this time
ORA-01110: data file 4: '/u01/app/oracle/oradata/ORCL/undotbs01.dbf'
ID do Processo: 2515
ID da Sess?o: 1 Numero de serie: 4080


Com o undo_management em MANUAL ele não deveria ignorar e abrir a instancia para eu poder abrir e criar uma nova UNDO?

portilho
Site Admin
Posts: 497
Joined: Wed May 29, 2013 8:51 am

Re: Restore UNDO sem backup

Post by portilho »

Oi Gabriel.
Parece que o procedimento está realmente correto, mas não funcionou.
Já visto acontecer, uma vez ou duas.
Tente restaurar a UNDO por backup mesmo (se tiver) e repetir o procedimento.

gcomenale

Re: Restore UNDO sem backup

Post by gcomenale »

É estranho porque eu apenas renomeei o datafile da undo para undotbs01.dbf.back e mesmo quando volto ao nome anterior ele não enxerga o datafile. Em casa eu mostro os detalhes.

gcomenale

Re: Restore UNDO sem backup

Post by gcomenale »

Repare como estranho é:

NAME STATUS
--------------------------------------------- -------
/u01/app/oracle/oradata/ORCL/system01.dbf SYSTEM
/u01/app/oracle/oradata/ORCL/soe01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/sysaux01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/undotbs01.dbf OFFLINE
/u01/app/oracle/oradata/ORCL/example01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/users01.dbf ONLINE
/u01/app/oracle/oradata/ORCL/ccdata01.dbf ONLINE


[oracle@nerv05-12cR1-01 ORCL]$ pwd
/u01/app/oracle/oradata/ORCL


[oracle@nerv05-12cR1-01 ORCL]$ ls -ltr undo*
-rw-r-----. 1 oracle oinstall 115351552 Mar 30 13:31 undotbs01.dbf.20150330_133418.bck
-rw-r-----. 1 oracle oinstall 115351552 Apr 8 21:08 undotbs01.dbf.20150408_211220.bck
-rw-r-----. 1 oracle oinstall 115351552 Apr 11 18:53 undotbs01.dbf


SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 4 cannot be read at this time
ORA-01110: data file 4: '/u01/app/oracle/oradata/ORCL/undotbs01.dbf'
ID do Processo: 1126
ID da Sess?o: 1 Numero de serie: 41209


Mesmo o datafile estando lá, ele não o lê.
As permissões estão as mesmas dos outros dbf's

[oracle@nerv05-12cR1-01 ORCL]$ ls -l
total 24940592
drwxr-xr-x. 2 oracle oinstall 4096 Apr 11 18:42 bb
-rw-r-----. 1 oracle oinstall 4294975488 Mar 29 21:15 cc01.dbf
-rw-r-----. 1 oracle oinstall 2147491840 Apr 13 17:55 ccdata01.dbf
-rw-r-----. 1 oracle oinstall 2147491840 Mar 30 13:31 ccdata01.dbf.20150330_133418.bck
-rw-r-----. 1 oracle oinstall 10141696 Apr 13 17:55 control01.ctl
-rw-r-----. 1 oracle oinstall 10076160 Mar 30 13:41 control01.ctl.20150330_134121.bck
-rw-r-----. 1 oracle oinstall 10076160 Mar 30 18:19 control01.ctl.20150330_181912.bck
-rw-r-----. 1 oracle oinstall 10141696 Apr 7 13:36 control01.ctl.20150407_133630.bck
-rw-r-----. 1 oracle oinstall 1304174592 Apr 13 17:55 example01.dbf
-rw-r-----. 1 oracle oinstall 1304174592 Mar 30 13:31 example01.dbf.20150330_133418.bck
-rw-r-----. 1 oracle oinstall 52429312 Apr 13 17:55 redo01.log
-rw-r-----. 1 oracle oinstall 52429312 Apr 13 17:55 redo02.log
-rw-r-----. 1 oracle oinstall 52429312 Apr 7 13:38 redo02.log.20150407_133910.bck
-rw-r-----. 1 oracle oinstall 52429312 Apr 13 17:55 redo03.log
-rw-r-----. 1 oracle oinstall 5368717312 Apr 13 17:55 soe01.dbf
-rw-r-----. 1 oracle oinstall 5368717312 Mar 30 13:31 soe01.dbf.20150330_133418.bck
-rw-r-----. 1 oracle oinstall 660611072 Apr 13 17:55 sysaux01.dbf
-rw-r-----. 1 oracle oinstall 650125312 Mar 30 13:31 sysaux01.dbf.20150330_133418.bck
-rw-r-----. 1 oracle oinstall 838868992 Apr 13 17:55 system01.dbf
-rw-r-----. 1 oracle oinstall 838868992 Mar 30 13:31 system01.dbf.20150330_133418.bck
-rw-r-----. 1 oracle oinstall 62922752 Apr 8 21:10 temp01.dbf
-rw-r-----. 1 oracle oinstall 62922752 Mar 30 13:39 temp01.dbf.20150330_133959.bck
-rw-r-----. 1 oracle oinstall 115351552 Apr 11 18:53 undotbs01.dbf
-rw-r-----. 1 oracle oinstall 115351552 Mar 30 13:31 undotbs01.dbf.20150330_133418.bck
-rw-r-----. 1 oracle oinstall 115351552 Apr 8 21:08 undotbs01.dbf.20150408_211220.bck
-rw-r-----. 1 oracle oinstall 5251072 Apr 13 17:55 users01.dbf
-rw-r-----. 1 oracle oinstall 5251072 Mar 29 20:56 users01.dbf.20150329_205913.bck
-rw-r-----. 1 oracle oinstall 5251072 Mar 30 13:31 users01.dbf.20150330_133418.bck

Sinceramente, não sei porque dele não reconhecer o arquivo.

Até com o dbf online:

SQL> alter database datafile 4 online;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01190: arquivo de controle ou arquivo de dados 4 e anterior ao ultimo RESETLOGS
ORA-01110: 4 do arquivo de dados: '/u01/app/oracle/oradata/ORCL/undotbs01.dbf'


SQL>

portilho
Site Admin
Posts: 497
Joined: Wed May 29, 2013 8:51 am

Re: Restore UNDO sem backup

Post by portilho »

O Oracle diz que não encontra o arquivo porque está em OFFLINE, isto está correto.
Só que agora ele está "velho demais", tem que recuperar de um backup.

gcomenale

Re: Restore UNDO sem backup

Post by gcomenale »

Sim, é verdade. O que achei estranho é que mesmo com o undo em MANUAL ele reclama do dbf até mesmo com ele offline.

gcomenale

Re: Restore UNDO sem backup

Post by gcomenale »

Me corrija se eu estiver errado:

Quando eu abro em resetlogs eu estou fazendo com que o controlfile que está com o SNC anterior aos dbfs "vá para frente" para chegar ao mesmo SCN dos dbfs?
Por exemplo:

Control File no SCN 458
Dbfs no SCN 567

Quando dou um open resetlogs o controlfile avança para o 567 e assim é possível abrir a instancia?

É possível fazer o contrário também?
Control File no SCN 567
Dbfs no SCN 458

Abrir a instancia com open resetlogs para que os dbfs arvancem para o SCN 567?

E outra pergunta, sempre que eu abro a base com resetlogs é um recovery incomplete?

portilho
Site Admin
Posts: 497
Joined: Wed May 29, 2013 8:51 am

Re: Restore UNDO sem backup

Post by portilho »

O SCN sempre avança (com o banco aberto), mesmo sem RESETLOGs.
Quando ocorre um RESETLOGs, DATAFILEs e CONTROLFILEs são sincronizados para o SCN mais novo, sim.
Mas esta sincronia não pode ocorrer de um DATAFILE pertence a outro RESETLOGs (INCARNATION). O SCN pode ser diferente (e geralmente é), mas o INCARNATION não.
Para utilizar um DATAFILE de outra INCARNATION, deve ser executado RESET DATABASE TO INCARNATION. Todos os DATAFILEs tem que estar na mesma INCARNATION. Se não estiverem, deve ser restaurado um BACKUP deles.

Um RESETLOGs não é, não causa um INCOMPLETE RECOVERY: um RESETLOGs só pode ocorrer após um INCOMPLETE RECOVERY.

Post Reply