Pular para o conteúdo principal

Restore #4 - Restore Tablespace UNDO sem backup

Restore #4 - Tablespace UNDO sem backup


Agora vamos recuperar o banco de dados com o tablespace de UNDO comrrompido. 


Criando o cenário:

1 - Localize o caminho do seu tablespace de UNDO e faça um escrita no arquivo. Forçando uma corrupção.

[oracle@teste dbs]$ echo "Thiago Castro" > /u01/app/oracle/oradata/TESTE/datafile/o1_mf_undotbs1_h33p4c21_.dbf
 


2 - Da mesma forma feita no Restore #3, se tentarmos fechar o banco com SHUTDOWN IMMEDIATE, não teremos sucesso. Vamos usar SHUTDOW ABORT.


SQL> shut immediate;
ORA-01115: erro de IO ao ler o bloco do arquivo 18 (bloco # 1)
ORA-01110: 18 do arquivo de dados: '/u01/app/oracle/oradata/TESTE/datafile/o1_mf_undotbs1_h33p4c21_.dbf'
ORA-27072: Erro de entrada/saida no arquivo
Additional information: 4
Additional information: 1

Restore:
1 - Crie um arquivo PFILE a partir do SPFILE

SQL> CREATE PFILE FROM SPFILE;
 
2 - No PFILE altere o parâmetro e realize STARTUP

UNDO_MANAGEMENT = MANUAL


SQL> STARTUP

Total System Global Area 2097150584 bytes
Fixed Size                  8899192 bytes
Variable Size             872415232 bytes
Database Buffers         1207959552 bytes
Redo Buffers                7876608 bytes
Banco de dados montado.
ORA-01157: n?o e possivel identificar/bloquear arquivo de dados 18 - consulte
arquivo de analise DBWR
ORA-01110: 18 do arquivo de dados:
'/u01/app/oracle/oradata/TESTE/datafile/o1_mf_undotbs1_h33p4c21_.dbf'
  
3 - Veja que a instância está montada e não aberta devido ao erro.
Então vamos ignoraro datafile corrompido. Em seguida abrir o banco de dados.

SQL> ALTER DATABASE DATAFILE 18 OFFLINE DROP
SQL> ALTER DATABASE OPEN;

4 - Agora vamos remover o tablespace de UNDO antigo e criar um novo como o mesmo nome.
 

SQL> DROP TABLESPACE UNDOTBS1;
SQL> CREATE UNDO TABLESPACE UNDOTBS1;

5 - Se algum erro for reportado durante a exclusão do tablespace, pode existir ainda algum arquivo em uso. Então, se necessário use o parâmetro "_offline_rollback_segments". Ele pode ser adicionado no PFILE da instância.
 
Exemplo de uso:
"_OFFLINE_ROLLBACK_SEGMENTS"=('_SYSSMU22$','_SYSSMU23$','_SYSSMU24$')

Use a consulta abaixo para saber o nome dos seguementos.
SQL>SELECT SEGMENT_NAME FROM DBA_ROLLBACK_SEGS WHERE STATUS = 'NEEDS RECOVERY';



6 - Reinicie a instância

SQL> SHUT IMMEDIATE;
SQL>STARTUP
 
 








































Comentários

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

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

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