Pular para o conteúdo principal

Restore #3 - Restore tablespace de UNDO com Backup

Restore #3 - Restore UNDO com Backup

Imagine seu tablespace de UNDO com problemas durante o horário de produção, o que você faria para corrigir o erro?

Usaremos dois cenários um restaurando a partir de um backup e outro sem backup. Nesse post usaremos backup.

Criando cenário:

1 - Faça um backup full da sua base de dados e em seguida verifique qual o seu tablespace de UNDO padrão

SQL> select file_name, online_status from dba_data_files;
/u01/app/oracle/oradata/TESTE/datafile/o1_mf_users_h2pfd4yt_.dbf                   ONLINE
/u01/app/oracle/oradata/TESTE/datafile/o1_mf_undotbs1_h30fdf6x_.dbf            ONLINE
/u01/app/oracle/oradata/TESTE/datafile/o1_mf_system_h2pfb7p9_.dbf               SYSTEM
/u01/app/oracle/oradata/TESTE/datafile/o1_mf_sysaux_h2pfcbsm_.dbf               ONLINE
 

2 - Remova o tablespace de UNDO

SQL> ! rm /u01/app/oracle/oradata/TESTE/datafile/o1_mf_undotbs1_h30fdf6x_.dbf
 
Olhando o log da minha base de dados, ainda não recebi nenhum alerta. Então vamos executar uma validação no banco de dados e olhar o log novamente.

RMAN> VALIDATE DATABASE;

Starting validate at 28-JAN-20
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=863 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=985 device type=DISK
RMAN-06169: could not read file header for datafile 4 error reason 5
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of validate command at 01/28/2020 10:49:51
RMAN-06056: could not access datafile 4
 


Restore:

Tente realizar o restore/recover somente do arquivo e veja o erro que irá acontecer no alert.log. Para que possamos realizar o restore teremos que dar shutdown no banco de dados.

Se executarmos o SHUTDOWN IMMEDIATE, iremos receber um erro. O motivo desse erro é que durante um SHUTDOWN IMMEDIATE, todas as sessões ativas são desconectadas imediatamente e todas as transações ativas são desfeitas (roll back).
Porém como no nosso caso, estamos sem o tablespace de UNDO, então não temos como realizar a operação de roll back.

SQL> SHUTDOWN IMMEDIATE;
ORA-01116: erro ao abrir o arquivo 4 do banco de dados
ORA-01110: 4 do arquivo de dados: '/u01/app/oracle/oradata/TESTE/datafile/o1_mf_undotbs1_h30fdf6x_.dbf'
ORA-27041: n?o e possivel abrir arquivo
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
 

A saída é executar o SHUTDOWN ABORT. Nesse caso o banco de dados será desligado de forma inconsistente.

SQL> SHUTDOWN ABORT;
 
Execute o STARTUP e repare que o banco de dados ficará no estado MOUNT


SQL> STARTUP
Instancia ORACLE iniciada.

Total System Global Area 2097150584 bytes
Fixed Size                  8899192 bytes
Variable Size             905969664 bytes
Database Buffers         1174405120 bytes
Redo Buffers                7876608 bytes
Banco de dados montado.
ORA-01157: n?o e possivel identificar/bloquear arquivo de dados 4 - consulte
arquivo de analise DBWR
ORA-01110: 4 do arquivo de dados:
'/u01/app/oracle/oradata/TESTE/datafile/o1_mf_undotbs1_h30fdf6x_.dbf'
 

Faça o RESTORE/RECOVER do datafile


RMAN> RESTORE DATAFILE 4;
RMAN> RECOVER DATAFILE 4;
 
Coloque o datafile online e execute a validação no banco de dados.


RMAN> SQL 'ALTER DATABASE DATAFILE 4 ONLINE';
RMAN> VALIDATE DATABASE;
 
Verifique o alert.log e veja se está tudo ok com seu banco de dados.

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â metro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo
Postar um comentário
Leia mais

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN
Postar um comentário
Leia mais

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G
Postar um comentário
Leia mais