Para melhor visualização, recomendo resolução de no mínimo 1024 x 768 e navegador Mozilla Firefox


segunda-feira, 1 de fevereiro de 2016

RMAN - Recuperando blocos de dados corrompidos (Block Media Recovery)

Por Eduardo Legatti

Olá,

Com o RMAN (Recovery Manager) é possível recuperar blocos de dados que foram corrompidos por algum motivo, seja por falhas de hardware, sistema operacional, ou até mesmo por problemas na própria instância do Oracle. Sempre que o erro "ORA-01578: bloco de dados ORACLE danificado (arquivo núm. string, bloco núm. string)" é reportado, significa que o Oracle tentou acessar algum bloco de dados corrompido em um arquivo de dados (datafile). Quando isso acontece, o DBA precisa identificar os blocos que foram corrompidos, a natureza da corrupção, e analisar as opções disponíveis para resolver o problema. Para um melhor entendimento sobre o conceito de tablespaces, segmentos (segments), extensões (extents) e blocos (blocks), acesse o artigo de Março/2008.

Quais opções temos para resolver o problema e suspender a emissão do erro ORA-01578?
  • Se for identificado que o segmento afetado é um índice de tabela, recriá-lo resolverá o problema.
  • Caso seja outro segmento como uma tabela, verificar se existe uma cópia da tabela em outro lugar de forma que seja possível reconstruir as linhas afetadas.
  • Executar CREATE TABLE...AS SELECT na tabela identificada com blocos corrompidos de forma a isolar as linhas saudáveis das linhas corrompidas.
  • Ignorar os blocos corrompidos fazendo uso de algumas procedures da package DBMS_REPAIR. (FIX_CORRUPT_BLOCKS e SKIP_CORRUPT_BLOCKS).
  • Realizar uma recuperação do bloco corrompido (Block Media Recovery).
Dentre as opções citadas acima, irei tratar neste artigo a recuperação física do bloco corrompido utilizando a técnica "Block Media Recovery" do RMAN. Para tanto, um backup físico do banco de dados, ou até mesmo um backup físico da tablespace afetada pela corrupção do bloco deverá estar disponível. Vale a pena salientar que o backup a ser utilizado deverá um que foi criado antes do bloco ter sido corrompido. Para realizar uma simulação, irei executar primeiro um backup da tablespace TBS_DATA_01, depois irei corromper alguns blocos no arquivo de dados pertencente a tablespace em questão, e por fim realizar a recuperação dos blocos corrompidos usando o RMAN através do comando BLOCKRECOVER.

[oracle@server01 ~]$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Mon Feb 1 10:27:33 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: BD01 (DBID=3046620119)

RMAN> backup tablespace TBS_DATA_01;

Starting backup at 01/02/2016
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=6 device type=DISK
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00058 name=/data/oracle/BD01/TBS_DATA_01.dbf
channel ORA_DISK_1: starting piece 1 at 01/02/2016
channel ORA_DISK_1: finished piece 1 at 01/02/2016
piece handle=/backup/flash_recovery_area/BD01/backupset/2016_02_01/o1_mf_nnndf_TAG20160105T144408_c8qwps0q_.bkp tag=TAG20160105T144408 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 01/02/2016

Após a realização do backup da tablespace TBS_DATA_01, alvo de blocos de dados que irei corromper mais a frente, segue abaixo a tabela que possivelmente será vítima destes blocos corrompidos. A tabela T1 está alocada na tablespace TBS_DATA_01, no arquivo de dados número 58, e possui atualmente 13 MB de tamanho com cerca de 1 milhão de linhas.
 
SQL> select segment_name,
  2         tablespace_name,
  3         header_file,
  4         header_block,
  5         blocks,
  6         bytes
  7    from dba_segments
  8   where segment_name = 'T1';

SEGMENT_NAME    TABLESPACE_NAME   HEADER_FILE HEADER_BLOCK     BLOCKS      BYTES
--------------- ----------------- ----------- ------------ ---------- ----------
T1              TBS_DATA_01                58          130       1664   13631488

1 linha selecionada.

SQL> select count(*) from T1;

  COUNT(*)
----------
   1000000

1 linha selecionada.

Irei executar o comando ANALYZE para validar e certificar que o segmento T1 está íntegro e não possui qualquer problema de corrupção em seus blocos de dados. Se nenhuma mensagem de erro for emitida é porque a tabela está íntegra e consistente.
 
SQL> analyze table T1 validate structure;

Tabela analisada.

Agora irei corromper alguns blocos do arquivo de dados TBS_DATA_01.dbf. Como o bloco de cabeçalho do datafile é o 130, irei corromper os seguintes blocos acima dele: 140, 240, 340 e 440 conforme demonstrado abaixo.
 
[oracle@server01 ~]$ dd if=/dev/zero of=TBS_DATA_01.dbf bs=8192 seek=140 conv=notrunc count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 4.9809e-05 s, 164 MB/s

[oracle@server01 ~]$ dd if=/dev/zero of=TBS_DATA_01.dbf bs=8192 seek=240 conv=notrunc count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 4.5978e-05 s, 178 MB/s

[oracle@server01 ~]$ dd if=/dev/zero of=TBS_DATA_01.dbf bs=8192 seek=340 conv=notrunc count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 4.3908e-05 s, 187 MB/s

[oracle@server01 ~]$ dd if=/dev/zero of=TBS_DATA_01.dbf bs=8192 seek=440 conv=notrunc count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 4.3342e-05 s, 189 MB/s

Para garantir que os dados serão lidos diretamente do arquivo de dados TBS_DATA_01.dbf e não do buffer cache na SGA, irei forçar a limpeza do cache e realizar a execução de uma instrução SELECT na tabela T1.
 
SQL> alter system flush buffer_cache;

Sistema alterado.

Veremos abaixo que tanto a instrução SELECT quanto o comando ANALYZE irão falhar e emitir o erro ORA-01578. Percebe-se que a mensagem de erro virá acompanhada do número do arquivo de dados e do número do bloco afetado. Neste caso, (arquivo núm. 58, bloco núm. 140).
 
SQL> select count(*) from T1;
select count(*) from T1
*
ERRO na linha 1:
ORA-01578: bloco de dados ORACLE danificado (arquivo núm. 58, bloco núm. 140)
ORA-01110: 58 do arquivo de dados: '/data/oracle/BD01/TBS_DATA_01.dbf'

SQL> analyze table T1 validate structure;
analyze table T1 validate structure
*
ERRO na linha 1:
ORA-01578: bloco de dados ORACLE danificado (arquivo núm. 58, bloco núm. 140)
ORA-01110: 58 do arquivo de dados: '/data/oracle/BD01/TBS_DATA_01.dbf'

Para identificar qual objeto foi afetado pela corrupção do bloco, bastará executar o SQL abaixo que seleciona dados da view de dicionários de dados DBA_EXTENTS. Como demonstrado pelo resultado abaixo, foi comprovado que o segmento afetado pelos blocos corrompidos foi a tabela T1.
 
SQL> select segment_type,owner,segment_name from dba_extents
  2  where file_id = 58 and 131 between block_id
  3  and block_id+blocks -1;

SEGMENT_TYPE       OWNER                          SEGMENT_NAME
------------------ ------------------------------ ------------------------------
TABLE              SCOTT                          T1

1 linha selecionada.

Existem outras formas de diagnosticar e coletar maiores informações sobre blocos que foram corrompidos nos arquivos de dados do Oracle. Dentre elas posso citar a utilização do utilitário DBVERIFY e do próprio comando VALIDATE do utilitário RMAN. Para usar o DBVERIFY, irei me certificar do tamanho padrão do bloco utilizado pela tablespace TBS_DATA_01.
 
SQL> select tablespace_name,block_size
       from dba_tablespaces
      where tablespace_name = 'TBS_DATA_01';

TABLESPACE_NAME                BLOCK_SIZE
------------------------------ ----------
TBS_DATA_01                          8192

Abaixo irei fazer uma análise no arquivo de dados TBS_DATA_01.dbf. Para tanto, após entrar no diretório onde está localizado o arquivo de dados, executarei o DBVERIFY através do utilitário dbv.
 
[oracle@server01 ~]$ dbv blocksize=8192 file=TBS_DATA_01.dbf feedback=1000

DBVERIFY: Release 11.2.0.3.0 - Production on Mon Feb 1 10:49:42 2016

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - Verification starting : FILE = /data/oracle/BD01/TBS_DATA_01.dbf
Page 140 is marked corrupt
Corrupt block relative dba: 0x0e80008c (file 58, block 140)
Completely zero block found during dbv:

Page 240 is marked corrupt
Corrupt block relative dba: 0x0e8000f0 (file 58, block 240)
Completely zero block found during dbv:

Page 340 is marked corrupt
Corrupt block relative dba: 0x0e800154 (file 58, block 340)
Completely zero block found during dbv:

Page 440 is marked corrupt
Corrupt block relative dba: 0x0e8001b8 (file 58, block 440)
Completely zero block found during dbv:

DBVERIFY - Verification complete

Total Pages Examined         : 1920
Total Pages Processed (Data) : 1520
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 160
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 236
Total Pages Marked Corrupt   : 4
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 2253598227 (1825.2253598227)

Acima é possível perceber que os blocos corrompidos foram identificados e prontamente reportados pelo utilitário. Utilizando o comando VALIDATE do RMAN para validar a tablespace TBS_DATA_01, veremos que também será reportado informações sobre blocos corrompidos.

RMAN> validate tablespace TBS_DATA_01;

Starting validate at 01/02/2016
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=6 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00058 name=/data/oracle/BD01/TBS_DATA_01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01

List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
58   FAILED 0              236          1920            7840568913427
  File Name: /data/oracle/BD01/TBS_DATA_01.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              1520
  Index      0              0
  Other      4              164

validate found one or more corrupt blocks
See trace file /u01/app/oracle/diag/rdbms/bd01/BD01/trace/BD01_ora_11127.trc for details
Finished validate at 01/02/2016

A partir do Oracle 11g, quando uma instrução SQL é abortada devido a emissão do erro ORA-01578 pelo fato de a mesma ter tentado acessar algum bloco corrompido, o Oracle prontamente já carrega informações na view dinâmica de desempenho V$DATABASE_BLOCK_CORRUPTION com informações do bloco corrompido. No entanto, se eu quiser saber todos os blocos que estão corrompidos, preferencialmente executo o comando VALIDATE DATABASE no RMAN. Desta forma a view será carregada de uma única vez com todos os blocos corrompidos encontrados no banco de dados.
 
SQL> select * from v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
---------- ---------- ---------- ------------------ --------------------
        58        140          1                  0 ALL ZERO
        58        240          1                  0 ALL ZERO
        58        340          1                  0 ALL ZERO
        58        440          1                  0 ALL ZERO

4 linhas selecionadas.

No resultado acima, os blocos corrompidos estão listado na coluna BLOCK#. Segue abaixo uma consulta que eu criei que retorna informações adicionais sobre os blocos corrompidos. Essas informações incluem o nome do arquivo de dados, nome da tablespace, nome do objeto que foi afetado, entre outras. Para fins estéticos, eu omiti algumas colunas do resultado do SQL abaixo.
 
SQL> SELECT file#,
  2         file_name,
  3         c.tablespace_name,
  4         block#,
  5         corruption_change#,
  6         corruption_type,
  7         segment_type,
  8         a.owner,
  9         segment_name,
 10         partition_name,
 11         skip_corrupt
 12    FROM dba_extents a, V$DATABASE_BLOCK_CORRUPTION b, dba_data_files c, dba_tables d
 13   WHERE     b.file# = c.file_id
 14         AND a.file_id = b.file#
 15         AND a.segment_name=d.table_name
 16         AND b.block# BETWEEN a.block_id AND a.block_id + a.blocks - 1;

FILE#   FILE_NAME                              TABLESPACE_NAME    BLOCK#
------- -------------------------------------- --------------- ---------
     58 /data/oracle/BD01/TBS_DATA_01.dbf   TBS_DATA_01           140
     58 /data/oracle/BD01/TBS_DATA_01.dbf   TBS_DATA_01           240
     58 /data/oracle/BD01/TBS_DATA_01.dbf   TBS_DATA_01           340
     58 /data/oracle/BD01/TBS_DATA_01.dbf   TBS_DATA_01           440

Agora irei me certificar que realmente possuo um backup da tablespace TBS_DATA_01 conforme demonstrado abaixo.

RMAN> list backup of tablespace TBS_DATA_01;

using target database control file instead of recovery catalog

List of Backup Sets
===================

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
4095    Full    1.99M      DISK        00:00:01     01/02/2016
        BP Key: 4095   Status: AVAILABLE  Compressed: YES  Tag: TAG20160105T144408
        Piece Name: /backup/flash_recovery_area/BD01/backupset/2016_02_01/o1_mf_nnndf_TAG20160105T144408_c8qwps0q_.bkp
  List of Datafiles in backup set 4095
  File LV Type Ckp SCN    Ckp Time   Name
  ---- -- ---- ---------- ---------- ----
  58      Full 7840568913504 01/02/2016 /data/oracle/BD01/TBS_DATA_01.dbf

Por fim, irei realizar um recovery do bloco 140 do arquivo de dados 58 fazendo uso do RMAN através do comando BLOCKRECOVER como demonstrado a seguir.

RMAN> blockrecover datafile 58 block 140;

Starting recover at 01/02/2016
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=223 device type=DISK

channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00058
channel ORA_DISK_1: reading from backup piece /backup/flash_recovery_area/BD01/backupset/2016_02_01/o1_mf_nnndf_TAG20160105T144408_c8qwps0q_.bkp
channel ORA_DISK_1: piece handle=/backup/flash_recovery_area/BD01/backupset/2016_02_01/o1_mf_nnndf_TAG20160105T144408_c8qwps0q_.bkp tag=TAG20160105T144408
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished recover at 01/02/2016

Ao acessar a view V$DATABASE_BLOCK_CORRUPTION, poderemos perceber que a linha referente ao bloco 140 desapareceu.
 
SQL> select * from v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTION_TYPE
---------- ---------- ---------- ------------------ --------------------
        58        240          1                  0 ALL ZERO
        58        340          1                  0 ALL ZERO
        58        440          1                  0 ALL ZERO

3 linhas selecionadas.

Se quisermos recuperar todos os blocos listados na view V$DATABASE_BLOCK_CORRUPTION de uma única vez, bastará utilizar o comando abaixo.

RMAN> blockrecover corruption list;

Starting recover at 01/02/2016
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=223 device type=DISK

channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00058
channel ORA_DISK_1: reading from backup piece /backup/flash_recovery_area/BD01/backupset/2016_02_01/o1_mf_nnndf_TAG20160105T144408_c8qwps0q_.bkp
channel ORA_DISK_1: piece handle=/backup/flash_recovery_area/BD01/backupset/2016_02_01/o1_mf_nnndf_TAG20160105T144408_c8qwps0q_.bkp tag=TAG20160105T144408
channel ORA_DISK_1: restored block(s) from backup piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished recover at 01/02/2016


Pronto. Os blocos foram recuperados e a instrução SELECT na tabela T1 irá executar sem problemas.
 
SQL> select * from v$database_block_corruption;

não há linhas selecionadas

SQL> select count(*) from T1;

  COUNT(*)
----------
   1000000

1 linha selecionada.

segunda-feira, 4 de janeiro de 2016

RMAN - Restaurando o backup de um banco de dados Physical Standby para uso no modo READ/WRITE

Por Eduardo Legatti

Olá,

Nos artigos de Novembro/2011, Janeiro/2012 e Outubro/2012 eu abordei alguns cenários usando o RMAN (Recovery Manager) envolvendo clonagem de bancos de dados através do comando DUPLICATE, restauração e recuperação de um banco de dados em uma outra máquina e até mesmo a criação de um banco de dados standby pelo RMAN. No artigo deste mês irei abordar também a restauração e recuperação de um banco de dados pelo RMAN, mas a diferença é que o backup utilizado será um backup frio (Cold Backup) feito um banco de dados Physical Standby. Dentre alguns motivos para se realizar o backup de um banco de dados standby, imagine que o banco de dados primário (Primary) esteja em um servidor remoto em algum serviço na nuvem e o banco de dados standby esteja em um servidor local usando a infraestrutura da sua própria empresa. Imaginando que o banco de dados tenha centenas de giga bytes de tamanho, qual seria a melhor alternativa no que se refere a custo e tempo para restaurar uma cópia desse banco em um servidor local da empresa?

Uma alternativa seria fazer o download de um monstruoso backup físico  que está localizado remotamente na nuvem, o que consumiria um tráfego de dados imenso e, dependendo da velocidade do download, poderia levar dias para concluir, e isso se o download não falhar. A outra alternativa seria fazer um backup do banco de dados standby que já é replicado em um servidor que está na empresa, restaurá-lo, abri-lo como como de leitura/escrita e usá-lo. Neste caso a alternativa 2, na minha opinião, seria a mais adequada.

No mais, segue abaixo os procedimentos que usarei para restaurar um banco de dados standby em um outro servidor e abri-lo como leitura/escrita. Vale a pena salientar que podemos abrir diretamente um banco de dados standby para leitura/escrita através do recurso SNAPSHOT STANDBY database à partir do Oracle 11g, mas o que eu quero mostrar nesse artigo é a possibilidade que temos de fazer o backup de um backup standby e restaurá-lo como se fosse um banco de dados comum.

Em relação ao backup do banco de dados standby BD01 que usarei como exemplo, segue abaixo os comandos que executei. Vale a pensa salientar que alguns comandos podem ser executados tanto pelo SQL*Plus quanto pelo RMAN.

RMAN> sql "alter database recover managed standby database cancel";
RMAN> configure controlfile autobackup off;
RMAN> backup as compressed backupset format '/backup/standby/BD01/BKP_%d_FULL_COLD_%T_%s.bkp' database;
RMAN> backup current controlfile format '/backup/standby/BD01/BKP_%d_CONTROLFILE_%T_%s.bkp';
RMAN> backup spfile format '/backup/standby/BD01/BKP_%d_SPFILE_%T_%s.bkp';
RMAN> sql "alter database recover managed standby database using current logfile disconnect from session";

Após a execução do cold backup pelo RMAN, poderemos ver abaixo que os seguintes arquivos foram criados.

$ ls -lh /backup/flash_recovery_area/BD01
total 1.6G
-rw-r----- 1 oracle oinstall 1.5M Jan 1 10:00 BKP_BD01_CONTROLFILE_20160101_4547.bkp
-rw-r----- 1 oracle oinstall 1.6G Jan 1 10:00 BKP_BD01_FULL_COLD_20160101_4545.bkp
-rw-r----- 1 oracle oinstall 1.5M Jan 1 10:00 BKP_BD01_FULL_COLD_20160101_4546.bkp
-rw-r----- 1 oracle oinstall  96K Jan 1 10:00 BKP_BD01_SPFILE_20160101_4548.bkp

Como irei realizar a restauração deste backup em um outro servidor diferente do servidor aonde está configurado o banco standby, irei criar as estrutura de diretórios conforme demonstrado abaixo.
  • Copiar ou criar o arquivo de senha orapwBD01 para o servidor de destino no diretório $ORACLE_HOME/dbs
  • Criar as estruturas de diretórios em $ORACLE_BASE/ADMIN
  • Copiar o backup para a flash_recovery_area no servidor de destino (utilizarei o mesmo caminho do servidor de origem)
  • Criar a estrutura de diretório que será o destino dos datafiles restaurados (/recovery/oradata/BD01)
Já que a restauração dos arquivos de dados será realizada em uma localização diferente, não precisarei criar os diretórios referentes às localizações dos datafiles iguais ao banco de dados de origem. Após a criação das estruturas acima, irei realizar a restauração do spfile, controlfile e remover as configurações no spfile relacionadas ao Data Guard. Após abrir o banco de dados no modo MOUNT, irei catalogar os arquivos de backup através do RMAN usando o comando CATALOG conforme roteiro abaixo. O destino dos arquivos de dados restaurados será /recovery/oradata/BD01.

$ export ORA_RMAN_SGA_TARGET=512
$ export ORACLE_SID=BD01
$ rman target /
RMAN> startup nomount;
RMAN> restore spfile from '/backup/flash_recovery_area/BD01/BKP_BD01_SPFILE_20160101_4548.bkp';
RMAN> startup nomount force;
RMAN> sql "alter system set control_files=''/recovery/oradata/BD01/control01.ctl'',''/recovery/oradata/BD01/control02.ctl'',''/recovery/oradata/BD01/control03.ctl'' scope=spfile";
RMAN> sql "alter system set log_archive_dest_2=''''";
RMAN> sql "alter system set log_archive_config=''''";
RMAN> sql "alter system set fal_client=''''";
RMAN> startup nomount force;
RMAN> restore controlfile from '/backup/flash_recovery_area/BD01/BKP_BD01_CONTROLFILE_20160101_4547.bkp';
RMAN> alter database mount;
RMAN> catalog start with '/backup/flash_recovery_area/BD01' noprompt;

Após executar os comandos acima, irei executar o comando SET NEW NAME de forma que os arquivos de dados sejam restaurados em /recovery/oradata/BD01. Vale a pena salientar que à partir do Oracle 11g podemos utilizar o comando SET NEWNAME FOR DATABASE que fará esse trabalho para todos os datafiles.

RMAN> run {
2> set newname for database to '/recovery/oradata/BD01/%b';
3> restore database;
4> switch datafile all;}

Uma outra forma seria usar a opção disponível nas versões anteriores, ou seja, executar o comando para cada datafile conforme demonstrado abaixo.

RMAN> run {
 2> set newname for datafile 1 to '/recovery/oradata/BD01/system01.dbf';
 3> set newname for datafile 2 to '/recovery/oradata/BD01/sysaux01.dbf';
 4> set newname for datafile 4 to '/recovery/oradata/BD01/users01.dbf';
 5> set newname for datafile 5 to '/recovery/oradata/BD01/DATA_ORCL_01_001.dbf';
 6> set newname for datafile 6 to '/recovery/oradata/BD01/undotbs01.dbf';
 7> set newname for datafile 7 to '/recovery/oradata/BD01/LOB_ORCL_01_001.dbf';
 8> set newname for datafile 8 to '/recovery/oradata/BD01/DATA_PAT_01_001.dbf';
 9> set newname for datafile 9 to '/recovery/oradata/BD01/DATA_RH_01_001.dbf';
10> set newname for datafile 10 to '/recovery/oradata/BD01/DATA_SIG_01_001.dbf';
11> set newname for datafile 14 to '/recovery/oradata/BD01/LOB_PAT_01_001.dbf';
12> set newname for datafile 15 to '/recovery/oradata/BD01/LOB_RH_01_001.dbf';
13> set newname for datafile 16 to '/recovery/oradata/BD01/LOB_SIG_01_001.dbf';
14> set newname for datafile 17 to '/recovery/oradata/BD01/INDX_PAT_01_001.dbf';
15> set newname for datafile 18 to '/recovery/oradata/BD01/INDX_RH_01_001.dbf';
16> set newname for datafile 19 to '/recovery/oradata/BD01/INDX_ORCL_01_001.dbf';
17> set newname for datafile 20 to '/recovery/oradata/BD01/INDX_SIG_01_001.dbf';
18> restore database;
19> switch datafile all;}

Por fim, após a restauração realizada, bastará apenas abrir o banco de dados com a opção RESETLOGS e alterar a tablespace TEMP para o novo destino.

SQL> alter database open resetlogs;
SQL> alter database tempfile 1 drop;
SQL> alter tablespace temp add tempfile '/recovery/oradata/BD01/temp01.dbf' size 100M;

Segue abaixo a simulação completa dos procedimentos que que foram realizados.

[oracle@serv01 ~]$ ls -lh /backup/flash_recovery_area/BD01
total 1.6G
-rw-r----- 1 oracle oinstall 1.5M Jan 1 10:00 BKP_BD01_CONTROLFILE_20160101_4547.bkp
-rw-r----- 1 oracle oinstall 1.6G Jan 1 10:00 BKP_BD01_FULL_COLD_20160101_4545.bkp
-rw-r----- 1 oracle oinstall 1.5M Jan 1 10:00 BKP_BD01_FULL_COLD_20160101_4546.bkp
-rw-r----- 1 oracle oinstall  96K Jan 1 10:00 BKP_BD01_SPFILE_20160101_4548.bkp


[oracle@serv01 ~]$ export ORA_RMAN_SGA_TARGET=512
[oracle@serv01 ~]$ export ORACLE_SID=BD01
[oracle@serv01 ~]$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Fri Jan 1 10:02:30 2015

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN> startup nomount;

startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initBD01.ora'

starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started

Total System Global Area     534462464 bytes

Fixed Size                     2230072 bytes
Variable Size                192940232 bytes
Database Buffers             331350016 bytes
Redo Buffers                   7942144 bytes

RMAN> restore spfile from '/backup/flash_recovery_area/BD01/BKP_BD01_SPFILE_20160101_4548.bkp';

Starting restore at 01/01/2016
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=396 device type=DISK

channel ORA_DISK_1: restoring spfile from AUTOBACKUP /backup/flash_recovery_area/BD01/BKP_BD01_SPFILE_20160101_4548.bkp
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 01/01/2016

RMAN> startup nomount force;

Oracle instance started

Total System Global Area     313159680 bytes

Fixed Size                     2227944 bytes
Variable Size                130023704 bytes
Database Buffers             176160768 bytes
Redo Buffers                   4747264 bytes

RMAN> sql "alter system set control_files=''/recovery/oradata/BD01/control01.ctl'',''/recovery/oradata/BD01/control02.ctl'',''/recovery/oradata/BD01/control03.ctl'' scope=spfile";

sql statement: alter system set control_files=''/recovery/oradata/BD01/control01.ctl'',''/recovery/oradata/BD01/control02.ctl'',''/recovery/oradata/BD01/control03.ctl'' scope=spfile

RMAN> sql "alter system set log_archive_dest_2=''''";

sql statement: alter system set log_archive_dest_2=''''

RMAN> sql "alter system set log_archive_config=''''";

sql statement: alter system set log_archive_config=''''

RMAN> sql "alter system set fal_client=''''";

sql statement: alter system set fal_client=''''

RMAN> startup nomount force;

Oracle instance started

Total System Global Area     313159680 bytes

Fixed Size                     2227944 bytes
Variable Size                130023704 bytes
Database Buffers             176160768 bytes
Redo Buffers                   4747264 bytes

RMAN> restore controlfile from '/backup/flash_recovery_area/BD01/BKP_BD01_CONTROLFILE_20160101_4547.bkp';

Starting restore at 01/01/2016
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=96 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
output file name=/recovery/oradata/BD01/control01.ctl
output file name=/recovery/oradata/BD01/control02.ctl
output file name=/recovery/oradata/BD01/control03.ctl
Finished restore at 01/01/2016

RMAN> alter database mount;

database mounted
released channel: ORA_DISK_1

RMAN> catalog start with '/backup/flash_recovery_area/BD01' noprompt;

Starting implicit crosscheck backup at 01/01/2016
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=96 device type=DISK
Crosschecked 75 objects
Finished implicit crosscheck backup at 01/01/2016

Starting implicit crosscheck copy at 01/01/2016
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 01/01/2016

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /backup/flash_recovery_area/BD01_STBY/archivelog/2015_11_16/o1_mf_1_1_c4n0kxrj_.arc

searching for all files that match the pattern /backup/flash_recovery_area/BD01

List of Files Unknown to the Database
=====================================
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_5_c4mpoood_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_7_c4mpoq1w_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_6_c4mpopbz_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_6_c4n012cg_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_3_c4mw8xf6_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_2_c4mpmotd_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_3_c4mzz2fn_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_2_c4mw8wmv_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_1_c4mpmo59_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_3_c4mpmpjf_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_1_c4mw8vsj_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_7_c4n0132l_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_5_c4n011nv_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_2_c4mzz1o5_.log
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_1_c4mzz0tn_.log
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_FULL_COLD_20160101_4545.bkp
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_SPFILE_20160101_4548.bkp
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_FULL_COLD_20160101_4546.bkp
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_CONTROLFILE_20160101_4547.bkp
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_FULL_COLD_20160101_4545.bkp
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_SPFILE_20160101_4548.bkp
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_FULL_COLD_20160101_4546.bkp
File Name: /backup/flash_recovery_area/BD01/BKP_BD01_CONTROLFILE_20160101_4547.bkp

List of Files Which Where Not Cataloged
=======================================
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_5_c4mpoood_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_7_c4mpoq1w_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_6_c4mpopbz_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_6_c4n012cg_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_3_c4mw8xf6_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_2_c4mpmotd_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_3_c4mzz2fn_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_2_c4mw8wmv_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_1_c4mpmo59_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_3_c4mpmpjf_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_1_c4mw8vsj_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_7_c4n0132l_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_5_c4n011nv_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_2_c4mzz1o5_.log
  RMAN-07529: Reason: catalog is not supported for this file type
File Name: /backup/flash_recovery_area/BD01_STBY/onlinelog/o1_mf_1_c4mzz0tn_.log
  RMAN-07529: Reason: catalog is not supported for this file type

RMAN> run {
2> set newname for database to '/recovery/oradata/BD01/%b';
3> restore database;
4> switch datafile all;}

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting restore at 01/01/2016
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /recovery/oradata/BD01/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /recovery/oradata/BD01/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /recovery/oradata/BD01/users01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /recovery/oradata/BD01/DATA_ORCL_01_001.dbf
channel ORA_DISK_1: restoring datafile 00006 to /recovery/oradata/BD01/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /recovery/oradata/BD01/LOB_ORCL_01_001.dbf
channel ORA_DISK_1: restoring datafile 00008 to /recovery/oradata/BD01/DATA_PAT_01_001.dbf
channel ORA_DISK_1: restoring datafile 00009 to /recovery/oradata/BD01/DATA_RH_01_001.dbf
channel ORA_DISK_1: restoring datafile 00010 to /recovery/oradata/BD01/DATA_SIG_01_001.dbf
channel ORA_DISK_1: restoring datafile 00014 to /recovery/oradata/BD01/LOB_PAT_01_001.dbf
channel ORA_DISK_1: restoring datafile 00015 to /recovery/oradata/BD01/LOB_RH_01_001.dbf
channel ORA_DISK_1: restoring datafile 00016 to /recovery/oradata/BD01/LOB_SIG_01_001.dbf
channel ORA_DISK_1: restoring datafile 00017 to /recovery/oradata/BD01/INDX_PAT_01_001.dbf
channel ORA_DISK_1: restoring datafile 00018 to /recovery/oradata/BD01/INDX_RH_01_001.dbf
channel ORA_DISK_1: restoring datafile 00019 to /recovery/oradata/BD01/INDX_ORCL_01_001.dbf
channel ORA_DISK_1: restoring datafile 00020 to /recovery/oradata/BD01/INDX_SIG_01_001.dbf
channel ORA_DISK_1: reading from backup piece /backup/flash_recovery_area/BD01/BKP_BD01_FULL_COLD_20160101_4545.bkp
channel ORA_DISK_1: piece handle=/backup/flash_recovery_area/BD01/BKP_BD01_FULL_COLD_20160101_4545.bkp tag=TAG20160101T090038
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:32:26
Finished restore at 01/01/2016

datafile 1 switched to datafile copy
input datafile copy RECID=34 STAMP=895946013 file name=/recovery/oradata/BD01/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=35 STAMP=895946013 file name=/recovery/oradata/BD01/sysaux01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=36 STAMP=895946013 file name=/recovery/oradata/BD01/users01.dbf
datafile 5 switched to datafile copy
input datafile copy RECID=37 STAMP=895946013 file name=/recovery/oradata/BD01/DATA_ORCL_01_001.dbf
datafile 6 switched to datafile copy
input datafile copy RECID=38 STAMP=895946013 file name=/recovery/oradata/BD01/undotbs01.dbf
datafile 7 switched to datafile copy
input datafile copy RECID=39 STAMP=895946013 file name=/recovery/oradata/BD01/LOB_ORCL_01_001.dbf
datafile 8 switched to datafile copy
input datafile copy RECID=40 STAMP=895946014 file name=/recovery/oradata/BD01/DATA_PAT_01_001.dbf
datafile 9 switched to datafile copy
input datafile copy RECID=41 STAMP=895946014 file name=/recovery/oradata/BD01/DATA_RH_01_001.dbf
datafile 10 switched to datafile copy
input datafile copy RECID=42 STAMP=895946014 file name=/recovery/oradata/BD01/DATA_SIG_01_001.dbf
datafile 14 switched to datafile copy
input datafile copy RECID=43 STAMP=895946014 file name=/recovery/oradata/BD01/LOB_PAT_01_001.dbf
datafile 15 switched to datafile copy
input datafile copy RECID=44 STAMP=895946014 file name=/recovery/oradata/BD01/LOB_RH_01_001.dbf
datafile 16 switched to datafile copy
input datafile copy RECID=45 STAMP=895946014 file name=/recovery/oradata/BD01/LOB_SIG_01_001.dbf
datafile 17 switched to datafile copy
input datafile copy RECID=46 STAMP=895946014 file name=/recovery/oradata/BD01/INDX_PAT_01_001.dbf
datafile 18 switched to datafile copy
input datafile copy RECID=47 STAMP=895946014 file name=/recovery/oradata/BD01/INDX_RH_01_001.dbf
datafile 19 switched to datafile copy
input datafile copy RECID=48 STAMP=895946014 file name=/recovery/oradata/BD01/INDX_ORCL_01_001.dbf
datafile 20 switched to datafile copy
input datafile copy RECID=49 STAMP=895946014 file name=/recovery/oradata/BD01/INDX_SIG_01_001.dbf

RMAN> alter database open resetlogs;

database opened

RMAN> exit

Recovery Manager complete.

[oracle@serv01 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Jan 1 10:45:32 2015

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select file#,name from v$tempfile;

     FILE# NAME
---------- ----------------------------------------
         1 /data/oradata/BD01/temp01.dbf

SQL> alter database tempfile 1 drop;

Banco de dados alterado.

SQL> alter tablespace temp add tempfile '/recovery/oradata/BD01/temp01.dbf' size 100M;

Tablespace alterado.

terça-feira, 1 de dezembro de 2015

Um pouco sobre o ORATOP: Utilitário para monitoramento de bancos de dados Oracle

Por Eduardo Legatti

Olá,

Assim como temos o comando top em sistemas Linux para exibir os processos em execução no sistema operacional bem como analisar a carga de trabalho do sistema, a Oracle criou o comando oratop que vem com o mesmo propósito de análise de carga de trabalho para bancos de dados Oracle. Com o utilitário oratop, podemos visualizar as sessões que estão conectadas na instância de um banco de dados Oracle e investigar, por exemplo, quais sessões estão impactando de forma negativa na performance geral do sistema. Assim como o comando top, o comando oratop também fornece as informações em tempo real. Enfim, com ele é possível identificar os principais eventos de espera (wait events) de forma cumulativa ou por sessão de banco de dados que estão ocorrendo no banco de dados. Vale a pena salientar que o oratop está disponível para download através do My Oracle Support (Metalink) através da note Doc ID 1500864.1.

Segue abaixo as versões de bancos de dados que atualmente suportam o oratop.
  • Oracle 11g R2 (11.2.0.3, 11.2.0.4)
  • Oracle 12cR1 (12.1.0.1, 12.1.0.2) 
Segue abaixo as plataformas de O/S que atualmente suportam o oratop.
  • IBM AIX on POWER Systems (64-bit)
  • HP-UX PA-RISC (64-bit)
  • HP-UX Itanium
  • Linux x86-64
  • Linux x86
  • Oracle Solaris on x86-64 (64-bit)
  • Oracle Solaris on SPARC (64-bit)

Para que o oratop funcione é necessário que pelo menos um Oracle Client esteja instalado e que as variáveis de ambiente $ORACLE_HOME, $LD_LIBRARY_PATH e $PATH estejam setadas corretamente:
 
export TMP=/tmp
export TMPDIR=$TMP
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:/usr/sbin:$PATH
export ORACLE_TERM=vt100
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib
export NLS_DATE_FORMAT=DD/MM/YYYY
export EDITOR=vi

Particularmente, prefiro utilizá-lo no próprio servidor onde já existe uma instalação do Oracle Database e com instâncias que poderão ser monitoradas, mas nada impede de utilizá-lo para monitorar instâncias Oracle remotamente já que o mesmo aceita um serviço TNS.

$ ./oratop username/password@tns_alias

Segue abaixo uma figura que mostra em detalhes as sessões que podemos analisar com o oratop.



Por padrão o oratop é executado utilizando o formato standard com refresh de 5 segundos e com os wait events sendo computados de forma cumulativa. Particularmente gosto de ter uma visão um pouco mais detalhada e geralmente executo da seguinte forma.
export ORACLE_SID=BD01
./oratop -f -d -i 1 / as sysdba

Onde:
  • f – opção de formato detalhado
  • d – eventos de espera em tempo real (o default é cumulativo)
  • i – atualização das informações (em segundos)

Vale a pena salientar que tais configurações podem ser alteradas de forma interativa. Segue abaixo as opções que podermos utilizar.
$ ./oratop -h
oratop: Release 14.1.2
Usage:
         oratop [ [Options] [Logon] ]

         Logon:
                {username[/password][@connect_identifier] | / }
                [AS {SYSDBA|SYSOPER}]

                connect_identifier:
                     o Net Service Name, (TNS) or
                     o Easy Connect (host[:port]/[service_name])
         Options:
             -d : real-time (RT) wait events, section 3 (default is Cumulative)
             -k : FILE#:BLOCK#, section 4 lt is (EVENT/LATCH)
             -m : MODULE/ACTION, section 4 (default is USERNAME/PROGRAM)
             -s : SQL mode, section 4 (default is process mode)
             -c : database service mode (default is connect string)
             -f : detailed format, 132 columns (default: standard, 80 columns)
             -b : batch mode (default is text-based user interface)
             -n : maximum number of iterations (requires number)
             -i : interval delay, requires value in seconds (default: 5s)
             -v : oratop release version number
             -h : this help

Em relação ao help interativo, segue abaixo várias opções que poderemos setar para visualizar e analisar as informações.

oratop: Release 14.1.2

Interactive Keys: [default]
        d : toggle between [Cumulative (C)] & Real-Time (RT) (section 3)
        k : toggle between [EVENT/LATCH] & object FILE#:BLOCK# (proc section 4)
        m : Toggle between [USERNAME/PROGRAM] & MODULE/ACTION (proc section 4)
        s : switch to SQL mode (section 4)
        f : toggle between [standard] & detailed format (long)
        p : switch to [process] mode (section 4)
        t : tablespace information
        x : basic SQL plan table (requires sql_id input)
        i : refresh interval, requires value in seconds [5s]
        q : quit/ exit program (also, { Q | Esc | function keys })

Abbreviations:
        [N/B]: count(N)/ Byte(B) - (k)illo, (M)ega, (G)iga, (T)erra, [PEZY]
        [T]  : Time - (u)micro, (m)illi, (s)econd, (h)our, (d)ay, (y)ear
        [m/s]: stats interval size, (m) 1 minute, (s) 15s, else, Real Time
        [c]  : database service centric

Acronym Help Menu:
        Section 1 - DATABASE        .. [1]
        Section 2 - INSTANCE        .. [2]
        Section 3 - DB WAIT EVENTS  .. [3]
        Section 4 - PROCESS         .. [4]
        Quit Help                   .. (q|Q)


Section 1 - database Global Database information
------------------------------------------------

   Version        : Oracle major version
   role           : database_role
   db name        : db_unique_name
   time        [s]: time as of the most recent stats (hh24:mi:ss)
   up          [T]: database uptime
   ins         [N]: total number of instance(s)
   sn        [c,N]: total user sessions (active/inactive)
   us        [c,N]: number of distinct users
   mt        [s,N]: global database memory total (sga+pga)
   fra         [N]: flashback recovery area %used, (red > 90%)
   er          [N]: diag active problem count (faults)
   % db      [s,N]: database time as %(dbtime/cpu) (red if > 99%)


Section 2 - instance Top 5 Instance(s) Activity Ordered by Database time desc
-----------------------------------------------------------------------------

   ID        [c,N]: inst_id (instance id)
   %CPU      [m,N]: host cpu busy %(busy/busy+idle). (red if > 90%)
   LOAD      [m,N]: current os load. (red if > 2*#cpu & high cpu)
   %DCU      [m,N]: db cpu otusef as %host cpu. (red if > 99% & high AAS)
   AAS       [s,N]: Average Active Sessions. (red if > #cpu)
   ASC       [c,N]: active Sessions on CPU
   ASI       [c,N]: active Sessions waiting on user I/O
   ASW       [c,N]: active Sessions Waiting, non-ASI (red if > ASC+ASI)
   ASP       [m,N]: active parallel sessions (F/G)
   AST       [c,N]: Active user Sessions Total (ASC+ASI+ASW)
   UST       [c,N]: user Sessions Total (ACT/INA)
   MBPS      [m,N]: i/o megabytes per second (throughput)
   IOPS      [m,N]: i/o requests per second
   IORL      [m,T]: avg synchronous single-block read latency. (red > 20ms)
   LOGR      [s,N]: logical reads per sec
   PHYR      [s,N]: physical reads per sec)
   PHYW      [s,N]: physical writes per sec
   %FR       [s,N]: shared pool free %
   PGA       [s,N]: total pga allocated
   TEMP      [s,N]: temp space used
   UTPS      [s,N]: user transactions per sec
   UCPS    [c,m,N]: user calls per sec
   SSRT    [c,m,T]: sql service response time (T/call)
   DCTR      [m,N]: database cpu time ratio
   DWTR      [m,N]: database wait time ratio. (red if > 50 & high ASW)
   %DBT      [s,N]: instance %Database Time (e.g. non-rac shows 100%)


Section 3 - db wait events Top 5 Timed Events Cluster-wide, non-idle Ordered by wait time
-----------------------------------------------------------------------------------------

  EVENT      : wait event name. (red if active)
        (C)  : Cumulative since instance startup
  WAITS      : total waits
  TIME(s)    : total wait time in seconds)
  AVG_MS     : average wait time in milliseconds
  PCT        : percent of wait time (all events)
  WAIT_CLASS : name of the wait class


Section 4 - process Non-Idle processes Ordered by event wait time desc
----------------------------------------------------------------------

   ID          [N]: inst_id. (red if blocking)
   SID         [N]: session identifier. (red if blocking)
   SPID        [N]: server process os id
   USERNAME       : Oracle user name
   PROGRAM        : process program name
   SRV            : SERVER (dedicated, shared, etc.)
   SERVICE        : db service_name
   PGA         [N]: pga_used_mem. (red if continuously growing)
   SQL_ID/BLOCKER : sql_id or the final blocker's (inst:sid, in red)
   OPN            : operation name, e.g. select
   E/T         [T]: session elapsed time (active/inactive)
   STA            : ACTive|INActive|KILled|CAChed|SNIped
   STE            : process state, e.g. on CPU or user I/O or WAIting
   WAIT_CLASS     : wait_class for the named event
   EVENT/*LATCH   : session wait event name. Auto toggle with *latch name.
                    (red if process is hung/spin)
   W/T         [T]: event wait time. (red if > 1s)
  

Utilizando a opção "t" no modo interativo, podemos obter algumas informações relacionadas às tablespaces. Dependendo do formato da tela (standard ou detailed) mais informações sobre as tablespaces irão ser mostradas. Chamo a atenção apenas para a informação SIZE que não é referente ao tamanho atual dos datafiles pertencentes à tablespace, mas sim a informação de MAX SIZE, ou seja, o tamanho máximo que a tablespace poderá atingir em função do AUTOEXTEND configurado em cada datafile.

TABLESPACE INFORMATION:

TABLESPACE_NAME               SIZE  USED  USE%  STATUS     BIG  NDBF  LOGGING
----------------------------  ----  ----  ----  ---------  ---  ----  ---------
SYSAUX                         32G  1.6G   5.0  ONLINE     NO      1  LOGGING
SYSTEM                         32G  800M   2.4  ONLINE     NO      1  LOGGING
TEMP                           10G  1.0M     0  ONLINE     NO      1  NOLOGGING
UNDOTBS1                      8.0G   71M   0.9  ONLINE     NO      1  LOGGING
USERS                            0  1.1M  111M  ONLINE     NO      1  LOGGING
TBS_DATA_01                    32G   19M     0  ONLINE     NO      1  LOGGING
TBS_DATA_02                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_DATA_03                    32G   22M     0  ONLINE     NO      1  LOGGING
TBS_DATA_04                    32G  2.2M     0  ONLINE     NO      1  LOGGING
TBS_DATA_05                    32G   64k     0  ONLINE     NO      1  LOGGING
TBS_DATA_06                    32G  375M   1.1  ONLINE     NO      1  LOGGING
TBS_DATA_07                    32G   96M   0.3  ONLINE     NO      1  LOGGING
TBS_DATA_08                    64G   44G  69.1  ONLINE     NO      2  LOGGING
TBS_DATA_09                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_DATA_10                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_DATA_11                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_DATA_12                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_DATA_13                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_DATA_14                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_DATA_15                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_01                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_02                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_03                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_04                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_05                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_06                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_07                    32G  2.4G   7.6  ONLINE     NO      1  LOGGING
TBS_INDX_08                    32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_INDX_09                    32G   47M   0.1  ONLINE     NO      1  LOGGING
TBS_INDX_10                    32G  2.6G   8.0  ONLINE     NO      1  LOGGING
TBS_INDX_11                    32G   64k     0  ONLINE     NO      1  LOGGING
TBS_INDX_12                    32G  437M   1.3  ONLINE     NO      1  LOGGING
TBS_INDX_13                    32G   57M   0.2  ONLINE     NO      1  LOGGING
TBS_LOB_01                     96G   70G  73.3  ONLINE     NO      3  LOGGING
TBS_LOB_02                     32G  5.6G  17.4  ONLINE     NO      1  LOGGING
TBS_LOB_03                     32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_LOB_04                     32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_LOB_05                     32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_LOB_06                     32G  1.0M     0  ONLINE     NO      1  LOGGING
TBS_LOB_07                     32G  1.2M     0  ONLINE     NO      1  LOGGING
TBS_LOB_08                     32G  3.8G  11.9  ONLINE     NO      1  LOGGING
TBS_LOB_09                     32G   64k     0  ONLINE     NO      1  LOGGING
TBS_LOB_10                     32G  2.9M     0  ONLINE     NO      1  LOGGING
----------------------------  ----  ----  ----
Total:                        1.4T  132G   9.5

press Enter to return

terça-feira, 3 de novembro de 2015

RMAN - Abordando a política de retenção (RECOVERY WINDOW) em backups incrementais

Por Eduardo Legatti

Olá,

Nos artigos de Outubro/2010 e Julho/2012 eu abordo um pouco sobre estratégias de backup utilizando o RMAN (Recovery Manager). Vale a pena recapitular que no Oracle, quando fazemos backups utilizando o RMAN, além da opção do backup FULL, temos também a opção de utilizarmos os backups incrementais. No RMAN, o termo "backup incremental" é utilizado para fazer referência a dois tipos: incremental diferencial e incremental cumulativo. O backup incremental inicial é conhecido como backup Nivel-0 (nível zero) e cada backup incremental realizado após o inicial é chamado de backup Nivel-1 (nível um). Os backups incrementais Nivel-1 podem ser cumulativos ou diferenciais.

Usar backups incrementais cumulativos significa que cada backup incremental se tornará progressivamente maior e mais demorado até que outro Nivel-0 seja executado, mas durante uma operação de recuperação, somente dois conjuntos de backups (Backup sets) serão necessários (O Nivel-0 e o último Nivel-1).
Os backups incrementais diferenciais somente registram as alterações referentes ao o último backup. Portanto, cada conjunto deles poderá ser menor ou maior do que o anterior, sem nenhuma sobreposição em seus blocos de dados. Entretanto, uma operação de recuperação poderá ser mais demorada pelo fato de terem mais conjuntos de backups para serem lidos em vez de apenas dois como no cumulativo (por exemplo: O Nivel-0, e vários Nivel-1). No mais, em relação aos backups incrementais, já li sobre DBAs levantando dúvidas no que se refere à política de retenção baseada no tempo (RECOVERY WINDOW) quando são utilizados backups incrementais como parte da política de backup. Muitas dessas dúvidas se referem sobre quando um conjunto de backups (backup sets) ficará obsoleto dentro de uma política de backup incremental.

Bom, para começar vale a pena salientar o que seria uma política de retenção no RMAN. Basicamente temos 3 opções:


Redundancy Backup Retention Policy



Com essa política o RMAN mantém X números de backups do banco de dados (número de cópias a serem retidas) para ficarem disponíveis para recuperação. Segue abaixo uma ilustração supondo que é realizada uma operação de backup 1 vez por dia. 

RMAN> configure retention policy to redundancy 2
 


Como demonstrado na figura acima, é possível perceber que o backup realizado na segunda-feira ficou obsoleto após o backup de quarta-feira ter sido realizado, e assim por diante. O que importa neste caso é o número de cópias que precisam ficar retidas. Como demonstrado na imagem, ao realizar o terceiro backup na quarta-feira, o primeiro backup que foi realizado na segunda-feira ficou obsoleto.


Recovery Window Backup Retention Policy



Essa política especifica que o RMAN deve reter todos os backups (baseado no tempo) durante um determinado X número de dias antes de torná-los obsoletos. A questão que devemos fazer ao optar por essa política é perguntar por quanto tempo queremos manter os backups para que seja possível uma recuperação em qualquer período em um tempo no passado (em dias) dentro da janela de retenção. Segue uma ilustração supondo que é realizada uma operação de backup 1 vez por dia.

RMAN> configure retention policy to recovery window of 1 day




Como demonstrado na figura acima, é possível perceber que o backup realizado na segunda-feira ficou obsoleto após o backup de quarta-feira ter sido realizado, e assim por diante. Isso significa que é possível recuperar o banco de dados em qualquer ponto no tempo dentro da janela de retenção de 1 dia.


NONE (os backups nunca ficam obsoletos)



Essa política especifica que o RMAN deve reter todos os backups sem nunca torná-los obsoletos.

RMAN> configure retention policy to none




Como demonstrado na figura acima, todos os backups realizados estarão disponíveis e não ficarão obsoletos.

Em relação ao backups incrementais, um backup de NIVEL-1 é inútil sem a existência de um backup de NIVEL-0. Portanto, se aos domingos são realizados backups de NIVEL-0 e nos demais dias (segunda-feira até sábado) são realizados backups de NIVEL-1, então mesmo que a minha política de retenção baseada em tempo (RECOVERY WINDOW) estiver configurado para 2 dias, na prática na primeira semana a retenção será de 9 dias, pois o backup de NIVEL-0 não poderá ficar obsoleto, já que o mesmo é necessário para realização de recover dos backups de NIVEL-1. Neste caso, um backup de NIVEL-0 só ficará obsoleto após a geração de um novo backup NIVEL-0 realizado na semana seguinte, conforme demonstrado na ilustração abaixo.





Na figura acima, o backup de NIVEL-0 realizado no dia 1 e todos os backups NIVEL-1 realizados até o dia 7 ficarão obsoletos somente a após a geração do backup NIVEL-1 no dia 10.

Segue abaixo uma evidência na qual são realizados backups NIVEL-0 (aos domingos) e NIVEL-1 (resto da semana) em um banco de dados que possui a política de retenção de 2 dias (RECOVERY WINDOW OF 2 DAYS). Conforme exemplificado na imagem acima, podemos verificar abaixo que nenhum backup se tornou obsoleto dentro dos 9 dias de realização dos backups.
RMAN> show all;

RMAN configuration parameters for database with db_unique_name BD01 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

RMAN> list backup summary;

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---------------
9337652 B  0  A DISK        01/10/2015      1       1       YES        LEVEL-0_SEMANAL
9337696 B  A  A DISK        01/10/2015      1       1       YES        ARCHIVES_DIARIO
9340964 B  1  A DISK        02/10/2015      1       1       YES        LEVEL-1_DIARIO
9341007 B  A  A DISK        02/10/2015      1       1       YES        ARCHIVES_DIARIO
9343776 B  1  A DISK        03/10/2015      1       1       YES        LEVEL-1_DIARIO
9346935 B  A  A DISK        03/10/2015      1       1       YES        ARCHIVES_DIARIO
9346949 B  1  A DISK        04/10/2015      1       1       YES        LEVEL-1_DIARIO
9350199 B  A  A DISK        04/10/2015      1       1       YES        ARCHIVES_DIARIO
9350213 B  1  A DISK        05/10/2015      1       1       YES        LEVEL-1_DIARIO
9353555 B  A  A DISK        05/10/2015      1       1       YES        ARCHIVES_DIARIO
9353569 B  1  A DISK        06/10/2015      1       1       YES        LEVEL-1_DIARIO
9353612 B  A  A DISK        06/10/2015      1       1       YES        ARCHIVES_DIARIO
9356729 B  1  A DISK        07/10/2015      1       1       YES        LEVEL-1_DIARIO
9356772 B  A  A DISK        07/10/2015      1       1       YES        ARCHIVES_DIARIO
9360532 B  0  A DISK        08/10/2015      1       1       YES        LEVEL-0_SEMANAL
9360576 B  A  A DISK        08/10/2015      1       1       YES        ARCHIVES_DIARIO
9363815 B  1  A DISK        09/10/2015      1       1       YES        LEVEL-1_DIARIO
9363858 B  A  A DISK        09/10/2015      1       1       YES        ARCHIVES_DIARIO


RMAN> report obsolete;

RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 2 days
no obsolete backups found
 

Postagens populares