Recover table no 12cr2 em ambiente Multitenant

Introdução a nova funções do Rman Recover Table

Por Ronaldo dos reis Olegario
Publicado em Novembro 2017


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.

  1. 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

  2. É 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

  3. 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

  4. 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

  5. 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.