Pular para o conteúdo

Recomendações Standby Database Oracle Standard Edition (11.2.0.4)

Recomendações Standby Database Oracle Standard Edition (11.2.0.4)

Antes de iniciar este artigo, é importante deixar claro que a Oracle oficialmente não considera como solução de DR a utilização do “Standby” database na versão Oracle Standard Editition. Esta solução é uma alternativa pois, não é possível o uso do Oracle Data Guard na versão SE.

Neste artigo algumas palavras serão utilizadas como nologging, unrecoverable, logging e force logging. Caso você não esteja familiarizado com estas palavras e conceitos relacionados a estas, sugiro a leitura deste documento: The Gains and Pains of Nologging Operations (Doc ID 290161.1)

Um dos primeiros passos antes da criação de um banco de dados Standby Database é saber como o banco de dados primário se comporta. Exemplo: possui operações nologging? quantidade de geração de archives diários? etc. No nosso caso iremos focar em operações nologging. O não conhecimento do funcionamento do seu banco de dados primário poderá diretamente afetar a sua estratégia de recuperação em caso de um desastre e no pior dos casos, saber disto somente durante uma recuperação.

A opção mais rápida para resolver operações nologging e ativar o force logging no nível do banco de dados mas, as vezes a solução mais rápida dependendo do caso poderá não ser a melhor, especialmente quando na versão Standard Edition não possui processos automáticos como há no Data Guard.

Separei alguns passos para checagem de informações que entendo como importantes antes da criação do Standby Database (versão 11.2.0.4) versão SE.

#1 – Identificação de alterações unrecoverable

O comando abaixo irá reportar a existência de operações (nologging) feitas no banco de dados que são consideradas pelo Oracle não recuperáveis.

set lines 400
col tablespace_name for a30
col file_name for a54

select df.tablespace_name,
       df.file_name,
       v.file#,
       v.unrecoverable_time,
       v.unrecoverable_change#
  from dba_data_files df,
       v$datafile     v
 where v.file# = df.file_id
   and v.unrecoverable_change# > 0

order by unrecoverable_time,tablespace_name, file_name;

#2 – Identificação das operações nologging

Geralmente através da lista dos datafiles listados no comando acima você terá uma direção da origem das operações de nologging. Conseguirá identificar objetos que estão em nologging etc.

Uma particularidade identificada na versão SE 11.2.0.4 é a seguinte: caso não tenha aplicação alguma rodando no banco de dados e mesmo assim tiver recorrência de operações nologging procure pelos jobs internos da Oracle (Auto Tasks), exemplo: ORA$AT_SA_SPC%. A Oracle fez algumas mudanças internas na versão 11.2.0.4 na forma de coleta de algumas tasks internas, como por exemplo o “Auto Space Advisor”. Este processo executa operações internas de nologging como mostrado abaixo.

Este comando foi extraído de um arquivo de trace gerado pela execução da rotina o “Auto Space Advisor”:

Command: 
----- Current SQL Statement for this session (sql_id=9mksnadjuygkc) ----- 
create table "SCHEMA_NAME".CMP3$91777 tablespace "SCHEMA_TABLESPACE_NAME" nologging lob (XXX) store as (tablespace "SCHEMA_TABLESPACE_NAME" enable storage in row nocache nologging) as select /*+ DYNAMIC_SAMPLING(0) FULL("SCHEMA_NAME"."QM_LOB_NAME") */ * from "SCHEMA_NAME"."XXX" sample block( 44.64) mytab 
----- PL/SQL Stack -----

Atráves de pesquisas, identifiquei que há um Bug # 24374872 “Excessive sampling by compression advisor causes high redo and table space usage” que não é especificamente para correção das operações de nologging mas sim para corrigir situações relacionais ao redolog e ao consumo de espaço de objetos (tabelas). Este é um patch genérico específico para versão 11.2.0.4.

#3 – Alternativa para suspender operações nologging (Auto Tasks)

Dica: antes de fazer qualquer desativação de rotinas internas do Oracle caso você não tenha certeza do impacto que poderá ser gerado no banco de dados recorra a documentação da Oracle e caso necessário, abra um chamado na Oracle descrevendo a situação e peça orientação.

Caso a opção force logging não seja viável, como alternativa há opção de desativar as Auto Tasks através da dbms_auto_task_admin.disable. Segue abaixo um exemplo:

Identificar quais são os jobs que estão ativos no banco de dados:

select client_name,status from dba_autotask_client;

Executar o comando abaixo para desativar a rotina:

BEGIN
   dbms_auto_task_admin.disable(client_name => 'auto space advisor',operation => NULL,window_name => NULL);
END; 
/

A desativação desta rotina fará com que as operações internas de nologging sejam suspensas e com isso o Oracle deverá parar de mostrar informações unrecoverable na v$datafile.

#4 – Faça um backup full ou incremental após operações de nologging

O exemplo a seguir irá simular uma operação de nologging em determinada tablespace, como identificar esta operação e os passos a serem tomados para “cobrir” esta operação com um backup full ou incremental. Este tipo de ação é fundamental para evitar erros como o apresentado abaixo em caso de um recuperação do banco de dados.

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 4, block # 440)

ORA-01110: data file 4: ‘/u01/oradata/db01/users01.dbf’

ORA-26040: Data block was loaded using the NOLOGGING option

Os passos abaixo deverão ser executados no banco de dados primário. Como fazer um backup incremental e aplicar estas alterações no banco de dados standby ficará para outro artigo.

1) Executar o comando report do RMAN para reportar unrecoverable no banco de dados:

RMAN> report unrecoverable database;
using target database control file instead of recovery catalog

Report of files that need backup due to unrecoverable operations

File Type of Backup Required Name
---- ----------------------- -----------------------------------

RMAN>

2) Gerar um operação de nologging:

create table test_nologging tablespace users nologging as select * from dba_source;
14:08:30 > create table test_nologging tablespace users nologging as select * from dba_source;

Table created.

3) Executar novamente o comando report do RMAN para reportar unrecoverable no banco de dados:

RMAN> report unrecoverable database;

Report of files that need backup due to unrecoverable operations

File Type of Backup Required Name
---- ----------------------- -----------------------------------
4    full or incremental     /u01/oradata/db01/users01.dbf

RMAN>

4) Após o RMAN identifcar o datafile que recebeu a operação de nologging, fazer um backup full ou incremental. Neste caso fiz apenas um backup incremental para tablespace users.

RMAN> backup incremental level 1 cumulative tag 'lvl_1_tablespace_users' tablespace users;

Starting backup at 30-JUN-2017 09:11:53
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2645 device type=DISK
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00004 name=/u01/oradata/db01/users01.dbf

channel ORA_DISK_1: starting piece 1 at 30-JUN-2017 09:11:53
channel ORA_DISK_1: finished piece 1 at 30-JUN-2017 09:11:54

piece handle=/u00/app/oracle/product/11.2.0.4/db_1/dbs/5ss832qp_1_1 tag=LVL_1_TABLESPACE_USERS comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 30-JUN-2017 09:11:54

Starting Control File and SPFILE Autobackup at 30-JUN-2017 09:11:54

piece handle=/u07/app/oracle/rmanbackups/cf_c-3816558725-20170630-01_20170630 comment=NONE

Finished Control File and SPFILE Autobackup at 30-JUN-2017 09:11:55

5) Executar novamente o comando report do RMAN para reportar unrecoverable no banco de dados:

RMAN> report unrecoverable database;

Report of files that need backup due to unrecoverable operations

File Type of Backup Required Name
--- ----------------------- -----------------------------------

RMAN>

#5 – Documentação

Selecionei alguns documentos que acho importante a leitura para entender melhor como é o funcionamento do Oracle com operações nologging e como atuar para corrigir determinadas situações.

Referências

  • Doc ID 33405.1: For tables please see “Extracting Data from a Corrupt Table using dbms_repair or Event 10231;
  • Doc ID 269274.1: Check For Logging / Nologging On DB Object(s);
  • Doc ID 794505.1: ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution;
  • Doc ID 1459778.1: Use RMAN to format corrupt data block which is not part of any object;
  • Doc ID 336133.1: How to Format Corrupted Block Not Part of Any Segment.
Leonardo Bissoli

Leonardo Bissoli

Leonardo Bissoli possui MBA em Gestão Empresarial pela Fundação Getúlio Vargas. Com mais de 15 anos de experiência em TI, trabalhou em grandes empresas como DBA, Arquiteto Corporativo e de Soluções. Atualmente mora na Irlanda e trabalha em uma multinacional francesa como Oracle DBA Senior. Possui as certificações OCE RAC 10g, OCP 10g, 11g, 12c, Oracle Database Cloud Services 2017 PreSales Specialist, Oracle Big Data 2015 Sales Specialist entre outras certificações. É fundador do OUGC - Oracle User Group Cork na Irlanda.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Marcações:
plugins premium WordPress