Pular para o conteúdo principal

Restore #2 PDB TSPITR: Tablespace Point In Time Recovery de um PDB.

Restore #2 PDB TSPITR: Tablespace Point In Time Recovery de um PDB.


Neste cenário vamos simular a recuperação em um ponto específico no tempo para um tablespace de um PDB. O Oracle facilitou muito nossa vida na versão 12 em diante com este tipo de recuperação.
Nas versões anteriores não era possível fazer de forma automatizada este tipo de recuperação, era tudo manual.


Criando o cenário:

1 - Dentro nosso PDB, vamos criar um novo usuário e um novo tablespace. 


ALTER SESSION SET CONTAINER=PDBTESTE;
CREATE TABLESPACE NOVA_TBS DATAFILE SIZE 500m;
CREATE USER USER_TESTE IDENTIFIED BY teste default tablespace NOVA_TBS;
ALTER USER user_teste QUOTA UNLIMITED ON NOVA_TBS;
grant create session to user_teste;
grant create table to user_teste;
 
2 - Vamos criar um nova tabela e popular.

CREATE TABLE USER_TESTE.TABELA_TESTE (C NUMBER) TABLESPACE NOVA_TBS;
INSERT INTO USER_TESTE.TABELA_TESTE VALUES (1000);
INSERT INTO USER_TESTE.TABELA_TESTE SELECT * FROM user_teste.TABELA_TESTE;
COMMIT;
 

3 - Criaremos um backup full da base de dados em seguida realizar alguns switchs para que sejam gerados novos archives.

run{
backup format '/u01/app/oracle/oradata/TESTE/backup/%U' database;
sql 'ALTER SYSTEM SWITCH LOGFILE';
sql 'ALTER SYSTEM SWITCH LOGFILE';
}
 
 4 - Após isso iremos verifica o último archive gerado. No nosso caso, foi o 37.

RMAN> LIST ARCHIVELOG ALL;

List of Archived Log Copies for database with db_unique_name TESTE
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
33      1    36      A 27-JAN-20
        Name: /u01/app/oracle/oradata/TESTE/archive/1_36_1030548094.dbf

34      1    37      A 27-JAN-20
        Name: /u01/app/oracle/oradata/TESTE/archive/1_37_1030548094.dbf
 
5 - Agora vamos simular o erro. Iremos apagar a tabela criada que esta nosso novo tablespace.
Obs: Existem outras formas mais simples de se recuperar apenas uma tabela excluída usando o recurso Flashback, mas o foco aqui é outro em outro post falo sobre ele.

SQL> DROP TABLE TABELA_TESTE;
 

Restore:

Agora vamos executar o comando de recover utilizando um espaço auxiliar. Quando você estiver rodando o comando de recover, verá que o Oracle vai usar essa localixação auxiliar para criação de um nova instância temporária e em seguida vai apaga-lá.


RMAN> RECOVER TABLESPACE PDBTESTE:NOVA_TBS UNTIL SEQUENCE 37 AUXILIARY DESTINATION '/u01/app/oracle/oradata/TESTE/auxiliar/';

Starting recover at 27-JAN-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=494 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1347 device type=DISK
RMAN-05026: warning: presuming following set of tablespaces applies to specified point-in-time

List of tablespaces expected to have UNDO segments
 

Terminado o recover, você pode tentar consultar a tabela porém vai receber um erro porque ela vai estar offline.

SQL> select tablespace_name,status from dba_tablespaces;

TABLESPACE_NAME                                   STATUS
------------------------------                            ---------
SYSTEM                                                         ONLINE
SYSAUX                                                         ONLINE
UNDOTBS1                                                    ONLINE
TEMP                                                              ONLINE
USERS                                                            ONLINE
NOVA_TBS                                                    OFFLINE
 

Coloque o tablespace online e realize a consulta.

SQL> alter tablespace NOVA_TBS online;
SQL> select * from user_teste.TABELA_TESTE;
 

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