Recover table no 12cr2 em ambiente Multitenant
Revisão de Paloma Aguiar
Sem sombra de dúvida o RMAN é uma mão na roda na vida do DBA Oracle. É um canivete Suíço com inúmeras funções. O RMAN pode ser utilizado para inúmeras funções que vão muito além do backup database, entre estas funções podemos destacar sua utilização como ferramenta de migração entre versões, Clone database, standby, backup de archives, backup incremental, backup incremental diferencial e ainda temos a possibilidade de abrir o database mesmo com a ausência de archives com a opção reset logs, Database point-in-time a lista de funcionalidades é gigante, impossível imaginar Oracle Database sem o utilitário RMAN. A versão 12c do Oracle Database presenteou os administradores de banco de dados com uma nova função adicionada ao RMAN, a nova função é RECOVER TABLE. Com o uso desta função do RMAN é possível realizar o restore e recovery de uma única tabela a partir de um backup full. Está função torna o RMAN ainda mais dinâmico e facilita muito a vida do DBA no dia a dia. No decorrer do artigo vou demonstrar como utilizar a funcionalidade RECOVER TABLE para realizar o processo de restore/recover de uma única tabela a partir de um backup full, estes passos serão realizados em um ambiente configurado como Multitenant. O ambiente Multitenant apresenta algumas particularidades para fazer o uso da função RECOVER TABLE.
Validação do ambiente
Para utilizar a funcionalidade de RECOVER TABLE precisamos que a instância (CDB) esteja configurada em Archive Mode. Como estamos em ambiente Multitenant será necessário realizar a validação com o escopo da sessão para o root container.
Para validar se a instância está configurada em archive mode basta executar o comando archive log list logado na instância, conforme demonstrado na listagem 1.
Listagem 1: Validando archive mode
SQL> conn / as sysdba
Connected.
SQL> alter session set container=cdb$root;
Session altered.
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /u01/app/oracle/product/12.2.0.1/dbs/arch
Oldest online log sequence 24
Current log sequence 26
Como podemos verificar na listagem 1, a instância não está com o Archive Mode habilitado. Para habilitar o Archive Mode será necessário realizar o ajuste de parâmetros e realizar stop/start do ambiente. Importante destacar que é necessário realizar o stop/start de todos os containers. O procedimento de shutdown e start do root container é demonstrado na listagem 2.
Listagem 2: Configurando archive mode
SQL> conn / as sysdba
Connected.
SQL> alter session set container=cdb$root;
SQL> alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/product/12.2.0.1/dbs/arch' scope = both;
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>startup mount
ORACLE instance started.
Total System Global Area 1577058304 bytes
Fixed Size 8793208 bytes
Variable Size 503317384 bytes
Database Buffers 1056964608 bytes
Redo Buffers 7983104 bytes
Database mounted.
SQL>alter database archivelog;
Database altered.
SQL>alter database open;
Database altered.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/12.2.0.1/dbs/arch
Oldest online log sequence 24
Next log sequence to archive 26
Current log sequence 26
A listagem 2 demonstra os passos para habilitar o Archive Mode na instância. Para validar se os switchs estão ocorrendo sem problema usaremos o comando alter system switch logfile que será demonstrado na listagem 3.
Listagem 3: Validação archive mode
SQL> conn / as sysdba
Connected.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/12.2.0.1/dbs/arch
Oldest online log sequence 24
Next log sequence to archive 26
Current log sequence 26
SQL> alter system switch logfile;
System altered.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/12.2.0.1/dbs/arch
Oldest online log sequence 25
Next log sequence to archive 27
Current log sequence 27
Analisando a listagem 3, podemos comprovar que o switch ocorreu normalmente. Podemos observar que o campo current log sequence foi incrementado em uma sequencia após a execução do comando de switch. A listagem 4 demonstra a validação nos demais containers.
Listagem 4: Validando os PDB
SQL> alter session set container=PDB1;
Session altered.
SQL> archive log list Database log mode
Archive Mode Automatic archival
Enabled Archive destination /u01/app/oracle/product/12.2.0.1/dbs/arch
Oldest online log sequence 25
Next log sequence to archive 27
Current log sequence 27
SQL> SQL> alter session set container=PDB2;
Session altered.
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/12.2.0.1/dbs/arch
Oldest online log sequence 25
Next log sequence to archive 27
Current log sequence 27
SQL>
Como foi observado na listagem 4, quando estamos em um ambiente Multitenant os containers herdam as configurações do root container. Com o ambiente validado, vamos para o nosso próximo passo que é a criação da estrutura de teste.
Criando a estrutura de teste
Para facilitar a demonstração criaremos algumas estruturas auxiliares na instância de banco de dados, para isso utilizaremos o container PDB1. Primero passo será uma nova tablespace que será utilizada para armazenar os dados de um novo usuário. Este novo usuário será utilizado como base durante todo o teste. A listagem 5 demonstra os passos de create tablespace e user.
Listagem 5: Criando a Tablespace e Usuário
sqlplus /nolog
conn / as sysdba
alter session set container=PDB1;
create tablespace tbs_usrbackup datafile '/u02/oradata/UPGR/tbs_ usrbackup_01.dbf' size 1g autoextend
on next 1024m maxsize 32000m;
create user usrbackup identified by test123 default tablespace tbs_usrbackup quota unlimited on tbs_usrbackup;
grant connect to usrbackup;
grant create session to usrbackup;
Com a tablespace e usuário de teste criados estamos prontos para criar uma nova tabela, está tabela será utilizada para o teste de recuperação. A nova tabela será baseada da tabela de sistema all_tables, afim de ter uma quantidade considerável de linhas.
Listagem 6: DDL tabela teste
sqlplus /nolog
conn / as sysdba
alter session set container=PDB1;
create table usrbackup.test123 as select * from all_tables;
SQL> select count(*) from usrbackup.test123 ;
----------
22671
Como verificamos na listagem 6 a tabela foi criada e temos alguns registros que usaremos como base para validação posterior. O próximo passo do teste é criar um backup full da instância.
Criando um backup full
Após ter criado a estrutura auxiliar o próximo passo é executar um backup full. Desta forma teremos um ponto seguro como base. O próximo script demonstra os comandos do RMAN para fazer um novo backup full. Você pode utiliza-lo como base para futuros backup. A única alteração necessária é no allocate channel. O allocate Channel indica o caminho em que serão salvos os pieces de backup. Ajuste para que atenda as especificações do ambiente que será utilizado para teste.
Listagem 7: Rman Script
rman target /
RMAN> RUN {
change archivelog all crosscheck;
sql "alter system switch logfile";
allocate channel d1 type disk format '/home/oracle/backup/bkp2_db_%d_%D%M%Y%t1.rman';
backup AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 0 DATABASE INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG ;
release channel d1;
}
Aguarde a conclusão do backup full para iniciar os steps pre restore/recover. Podemos realizar a validação do termino do backup e seu status realizando uma query na view V$RMAN_BACKUP_JOB_DETAILS, conforme demonstrado na listagem 8.
Listagem 8: Validação do backup full
SQL> conn / as sysdba
Connected.
select SESSION_KEY, INPUT_TYPE, STATUS, to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,
to_char(END_TIME,'mm/dd/yy hh24:mi') end_time, elapsed_seconds/3600 hrs
from V$RMAN_BACKUP_JOB_DETAILS
where start_time > sysdate-1
and input_type = 'DB INCR'
order by session_key;
SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME HRS
----------- ------------- --------- -------------- -------------- -------
2 DB INCR COMPLETED 08/29/17 02:10 08/29/17 02:13 .04
Na listagem 8 podemos observar que o status do backup full incremental está completed, caso houvesse erro ou falha teriamos os status COMPLETED WITH ERRORS ou FAILED.
Dropando a tabela
Após realizado o backup full com sucesso podemos dropar a tabela e posteriormente realizar o restore/recover. Abaixo os passos usados para realizar o drop da tabela.
Listagem 9: Drop table
SQL>
SQL> sqlplus /nolog
SQL> conn / as sysdba
SQL> alter session set container=PDB1;
SQL>
SQL> drop table usrbackup.TEST123;
Table dropped.
SQL> quit
Utilizei o Drop table no exemplo por referencia para ilustração, pode ser utilizado delete ou truncate.
Restaurando a tabela
Neste ponto estamos prontos para iniciar o processo de restore/recover. Abaixo segue o script que utilizei para restaurar a tabela TEST123.
Listagem 10: RMAN recover
rman target /
RMAN> RECOVER TABLE usrbackup.TEST123 of pluggable database pdb1 UNTIL TIME "TO_DATE('29/08/2017
02:13:00','DD/MM/RRRR HH24:MI:SS')" AUXILIARY DESTINATION '/home/oracle/backup/aux';
Ao executar o script do RMAN, uma série de processos que executam em background tornam possível recuperar a tabela. Pontos de destaque no script são as clausulas of pluggable database e UNTIL TIME, como estamos usando um ambiente Multitenant é necessário informar em qual container a tabela foi criada e que será restaurada. A clausula UNTIL TIME do script indica até o horário que os archives devem ser aplicados, este horário deve ser inferior ao horário em que o usuário removeu os dados da tabela.
Para um melhor entendimento vou analisar os principais steps do processo de recover. Utilizarei como base o log do RMAN.
- O primeiro passo do RMAN é criar uma instancia em memória. Esta instancia será utilizada para o restore e recover e nos passos seguintes para extração da tabela.
Listagem 11: Create instance
Creating automatic instance, with SID='ammu' initialization parameters used for automatic instance: db_name=CDB2 db_unique_name=ammu_pitr_pdb1_CDB2 compatible=12.2.0 db_block_size=8192 db_files=200 diagnostic_dest=/u01/app/oracle _system_trig_enabled=FALSE sga_target=1504M processes=200 db_create_file_dest=/home/oracle/backup/aux log_archive_dest_1='location=/home/oracle/backup/aux' enable_pluggable_database=true - É criado um diretório com nome padrão e o caminho será o informado na clausula AUXILIARY DESTINATION do script do RMAN.
Listagem 12: Create directory
database opened contents of Memory Script: { sql clone 'alter pluggable database PDB1 open'; } executing Memory Script sql statement: alter pluggable database PDB1 open contents of Memory Script: { # create directory for datapump import sql 'PDB1' "create or replace directory TSPITR_DIROBJ_DPDIR as '' /home/oracle/backup/aux''"; # create directory for datapump export sql clone 'PDB1' "create or replace directory TSPITR_DIROBJ_DPDIR as '' /home/oracle/backup/aux''"; } executing Memory Script - Criado o diretório o RMAN inicia um Expdp da tabela que foi indicada na clausula recover table.
Listagem 13: Export da table
sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as ''/home/oracle/backup/aux'' sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as ''/home/oracle/backup/aux'' Performing export of tables... EXPDP> Starting "SYS"."TSPITR_EXP_ammu_hysx": EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE EXPDP> . . exported "USRBACKUP"."TEST123" 2.700 MB 22671 rows EXPDP> Master table "SYS"."TSPITR_EXP_ammu_hysx" successfully loaded/unloaded - Assim que o Expdp finalizar será iniciado um processo de Impdp, que utilizará as mesmas informações usadas no Expdp.
Listagem 14: Import da table
Performing import of tables... IMPDP> Master table "SYS"."TSPITR_IMP_ammu_agit" successfully loaded/unloaded IMPDP> Starting "SYS"."TSPITR_IMP_ammu_agit": IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA IMPDP> . . imported "USRBACKUP"."TEST123" 2.700 MB 22671 rows IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER IMPDP> Job "SYS"."TSPITR_IMP_ammu_agit" successfully completed at Tue Aug 29 03:10:59 2017 elapsed 0 00:00:14 Import completed - O ultimo passo realizado é a remoção da instância temporária que foi criada no processo de restore.
Listagem 15: Remoção da instância
Removing automatic instance Automatic instance removed auxiliary instance file /home/oracle/backup/aux/CDB2/57D1BF03A565299BE055000000000001/datafile/ o1_mf_temp_dt9hor8p_.tmp deleted
Concluído os 5 steps com sucesso a tabela estará disponível ao usuário. Como temos a informação da quantidade de registros existentes antes do drop. Podemos facilmente validar a efetividade do restore. A validação é demonstrada na listagem 16.
Listagem 16: Validação dos registros
SQL>
SQL> sqlplus /nolog
SQL> conn / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on Tue Aug 29 03:12:14 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> select count(*) from usrbackup.test123 ;
COUNT(*)
----------
22671
Conclusão
Sem dúvida uma grata ajuda aos administradores de banco de dados Oracle. Até a versão 11g para realizar a mesma operação precisaríamos fazer um restore do último backup full, aplicar os archives até o ponto anterior ao drop, abrir o database com a opção de open resetlogs, exportar os dados da tabela e importar. Com a função de RECOVER TABLE o processo foi automatizado e diminuiu muito a complexidade do processo. Como a função também pode ser utilizado em ambiente Multitenant, sem dúvida acrescentou muito ao RMAN.
rolegar@gmail.com - https://br.linkedin.com/in/ronaldoolegario
DBA Oracle/Sybase, SQLServer e Cloudera Administrator Senior, atuando a mais de 12 anos na área TI é formado em Ciência da Computação pela PUC-RS, possui certificações de Oracle Professional 10g e 11g, Oracle Real Application Cluster 10G e Oracle Goldengate Certified Specialist.