Oracle Database 12c: O que há de novo dentro do Oracle Data Guard 12cR1?

Por Joel Pérez , Wissem El Khlifi e Rodrigo Mufalani
Postado em Maio de 2014


Introdução:

Este artigo descreve as novas funcionalidades e melhorias que foram adicionadas ao Oracle Data Guard 12c Release 1.

Oracle Data guard visão geral:

O Oracle Data Guard fornece soluções para maximizar alta disponibilidade do banco de dados Oracle. Oracle Data Guard mantém um ou vários bancos de dados secundários como alternativas ao primário (database de produção),  para protegê-lo de perda de dados, corrupções, disastres, erros e outras possíveis falhas.
Oracle Data Guard também pode ser usado para load balancing: O standby database pode ser aberto para queries, testes e relatórios. (Oracle Active Data Guard Option)
Nós DBA’s podemos escolher entre failover manual ou automático do banco de produção para um banco de dados de standby.

O que há de novo no Oracle Data Guard 12cR1?

  1. FarSync Standby:

Introdução:

Antes do Oracle 12c, cascading standby database era um standby database que recebia seus redo logs de um outro standby database, não do primary database. O standby database, que serve para cascatear standby database, é criado a partir do primary database usando RMAN (active) com o método de duplicação ativa ou restaurado de um backup do banco primário.

A imagem a seguir mostra um banco de dados primário enviando dados de redo pela rede para um physical standby database (físico) e um logical standby database (lógico). O physical standby database retransmite os dados de redo para um outro physical standby database (Cascading standby 1). O logical standby database transforma os dados de redo em SQL, que são transmitidos para um outro logical standby database (Cascading standby 2).

Os standbys databases físicos e lógicos cascateados são databases com standby control files, server parameter files, data files e etc …
Oracle database 12cR1 vêm com uma nova standby role chamada “FarSync Standby”. O novo standby trabalha como um coordenador entre o primário e todos seus standby databases. “FarSync Standby” é um Standby Database em cascata que atua como repositório de archivelogs.
Farsync standby somente podem ter um spfile, standby control file, standby redo logs e archivelog srecebidos do primary database. Farsync standby não pode ser aberto para acesso, não pode aplicar redo, não pode funcionar como primary role o user convertido para qualquer tipo de standby database e não tem qualquer datafile.
Farsync standby pode rodar em um servidor com poucos recursos de processamento, pois ele age somente como repositório de archivelogs para um outro standby databases.
Com o Oracle Database 12c Release 1, criar uma instância farsync perto ao banco de dados primário tem o benefício do sincronismo local de redo com garantia de “perda de dados zero” quando os standby databases estão longe.Há ganho de performance usando redo transport compression e para servir multiplos destinos assíncronos. Switchover& Failover para o standby é transparente.
Farsync standby pode operar em modos de máxima proteção, maxima disponibilidade ou maxima performance.

A imagem seguinte mostra um primary database enviando dados de redo usando Oracle network services para um farsync standby.  Ofarsync standby retransmite os dados de redo para outros physical standby databases.

Criando uma instância FarSync Standby:

Abaixo está o passo a passo para criação de um farsync standby database.

Pré-requisitos

  • O Primary database deve estar em archive log mode.
  • O Primary e o Farsync standby tem que estar na mesma versão e o mesmo nível de patchset aplicado.
  • FORCE LOGGING deve estar habilitado no Primary Database
  • O Primary Database deve estar usando um SPFILE
  • Deve haver conexão de rede entre o Primary e o far standby system
  • O Listener deve estar configurado e iniciado no Primary database e no farsync standby.
  • Criar os Standby redo log file no primary database. O Standby redologs deve ter pelo menos o tamanho do maior redolog no primary database. O standby redolog deve ter pelo menos um grupo de redolog a mais do que o primary database.

 

Informações do ambiente

No exemplo seguinte, temos um primary database, um farsync  standby e dois physical standby databases.

ROLE

DB_UNIQUE_NAME

Primary

Livedb

FarSync Standby

Livefs

Standby database

livestby1

Standby database

livestby2

Criando um FarSync Standby
Durante o processo de criação de um physical standby, um physical standby controlfile deve ser criado no primary database. O standby controlfile é usado para montar o banco de dados de standby físico. Porém, durante o processo de criação de uma instance farsync, um “farsync” standby controlfile deve ser usado para montar o farsync standby. Note que o novo comando “alter database create farsync instance controlfile”:
Exemplo:
Rode o seguinte comando no primary database


SQL>alter database create farsync instance controlfile as ‘/home/oracle/wissem/far_stby_ctl.ctl’;

Crie uma entrada de TNS para resolver farsync standby no primary database.


livedb =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = livedb.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = livedb)
    )
  )

livefs =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = livefs.domain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = livefs)   
)
)

  Configure os seguintes parâmetros de inicialização no Primary Database:

  • log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DEST’
  • log_archive_dest_2 ='SERVICE=livefs SYNC COMPRESSION=ENABLE VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=livefs'
    #(Note que habilitamos a compressão)
  • LOG_ARCHIVE_DEST_STATE_2=ENABLE
  • log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
  • log_archive_max_processes = 8

Criando um parameter file (standby) a partir do primary database spfile:


SQL>create pfile=’/home/oracle/wissem/pfile_far_stby.ora’ from spfile;

Edite o pfile criado no passo anterior e mude os seguintes parâmetros:

  • control_files=‘/home/oracle/wissem/far_stby_ctl.ctl’
  • db_unique_name=’livefs’
  • log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
  • fal_server=’livedb’
  • log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DESTVALID_FOR=(ALL_LOGFILES,ALL_ROLES)
  • DB_UNIQUE_NAME=livefs’
  • log_archive_dest_2 = ’ SERVICE=livestby1 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=livestby1'
  • log_archive_dest_3=’ SERVICE=livestby2 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=livestby2'
  • LOG_ARCHIVE_DEST_STATE_2=ENABLE
  • LOG_ARCHIVE_DEST_STATE_3=ENABLE
  • log_archive_max_processes = 8

Crie uma entrada TNS para resolver o primary database e os dois physical standby databases no farsync standby. Copie as mesmas informações para os bancos de dados livestby1 e livestby2.


livedb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = livedb.domain.com)(PORT = 1521))
(CONNECT_DATA =
  (SERVER = DEDICATED)
(SERVICE_NAME = livedb)
)
)

livefs =
  (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = livefs.domain.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = livefs)
)
)
Livestby1 =
(DESCRIPTION =
  (ADDRESS = (PROTOCOL = TCP)(HOST = Livestby1.domain.com)(PORT = 1521))
(CONNECT_DATA =
   (SERVER = DEDICATED)  
(SERVICE_NAME = Livestby1)
)
)
Livestby2=
(DESCRIPTION = 
(ADDRESS = (PROTOCOL = TCP)(HOST = Livestby2.domain.com)(PORT = 1521))
(CONNECT_DATA =  (SERVER = DEDICATED)
(SERVICE_NAME = Livestby2)
)
)

Inicie em modo NOMOUNT o farsync standby:


Startup nomountpfile=’/home/oracle/wissem/pfile_far_stby.ora’;


Monte o farsync standby:


Alter database mount;


Consulte a v$database:


Select database_role from v$database;

A consulta deve retornar “FAR SYNC STANDBY”como database role.

 

Criando o standby redolog files no farsync standby. Standby redolog files são necessários para armazenar o redo recebido do primary database. Standby redologs devem ser no mínimo maior do que o maior redologfile no primary database.  O standby redolog deve ter ao menos um grupo de redolog a mais do que o primary database.


SQL>alter database add standby logfile THREAD 1 size 1G;

Verifique se os archivelogs estão sendo recebidos no farsync standby, para isso consulte a view v$archive_dest_Status
Criando Physical Standby databases
Use o mesmo procedimento para criar physical standby databases usado no 11g Release 2.
Você pode usar um dos seguintes métodos:

  1. Criando manualmente via User-Managed Backups
  2. Usando RMAN Backup-based Duplication
  3. Criando um Standby Database do Primary Database ativo, sem um backup, usando RMAN Duplicate

Copie o pfiledo primary database para o physical standby e mude os seguintes valores:
Para o Livestby1 physical standby database:

  • db_unique_name=’livestby1’
  • log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
  • fal_server=’livefs’     #the farsync standby name.
  • log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DESTVALID_FOR=(ALL_LOGFILES,ALL_ROLES)
  • DB_UNIQUE_NAME=livestby1’
  • log_archive_dest_2=’ SERVICE=livefs VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)DB_UNIQUE_NAME=livefs'
  • LOG_ARCHIVE_DEST_STATE_2=ENABLE
  • log_archive_max_processes = 8

Para o Livestby2 physical standby database:

  • db_unique_name=’livestby2’
  • log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’
  • fal_server=’livefs’#The farsync standby name.
  • log_archive_dest_1 = ‘location=USE_DB_RECOVERY_FILE_DESTVALID_FOR=(ALL_LOGFILES,ALL_ROLES)
  • DB_UNIQUE_NAME=livestby2’
  • log_archive_dest_2=’ SERVICE=livefs VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)DB_UNIQUE_NAME=livefs'
  • LOG_ARCHIVE_DEST_STATE_2=ENABLE
  • log_archive_max_processes = 8

Os passos para criar um physical Standby database, nós podemos iniciar diretamente o RMAN Duplicatedo site Standby. Este método irá deixar o physical standby no modo MOUNT.


$ export ORACLE_SID = livestby1
SQL> startup nomountpfile =’pfile_location’
RMAN>connecttargetsys/<Password>@livedb
RMAN>connectauxiliary /
RMAN>duplicatetarget database for standby fromactive database nofilenamecheck;

Passos pós-criação dos Physical Standby databases

1) Os physical standby databases (livestby1, livestby2) estão em modo MOUNT, baixe os standby databases com o comando shutdown immediate;
2) Reinicie os physical standby databases usando o spfile;
3) Adicione standby redolog files nos physical standby databases;
4) Inicie a aplicação de redo;


ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 8 DISCONNECT;

Verifique se há algum erro:


Select message, timestamp
From v$dataguard_status
Where severity in ('Error','Fatal')
Order by timestamp;

 

  • Cascateando um Standby Database em Real-Time

Introdução:

Antes do Oracle 12c, cascading standby database é um standby database que recebe redologs de um outro standby database, não do primary database. O standby database, que serve como cascateamento de standby database, é criado a partir do primary database usando o Método de Duplicação Ativa do RMAN ou restaurando de um backup do primary database. A propagação de redo para o nó terminal  do cascateamento de standby database não é feita em tempo real. Isso significa que que uma Log Sequence é transferida para o terminal standby database(s) somente depois de um Log Switch no primary database.
No Oracle 12c release 1, agora é possível fazer propagação em tempo real de todo Log Sequence, o que significa, tão rápido quanto os dados de redo são escritos no standby redolog do primeiro standby database.

Pré-requisitos

  • Primeiro nó do (Cascading) Standby deve ser um Physical ou FarSync Standby Database
  • Standby RedoLogs devem ser colocados e usados ao menos em um Cascading Standby Database;
  • Active Data Guard Option deve estar licenciada;
  • Primary, Cascading e Cascaded Standby Database db_unique_name devem estar presentes no dg_confige nolog_archive_config de todos os databases.

 

Habilitar Cascateamento de um Standby Database em Real-Time

Informação do Ambiente

No seguinte exemplo, nós temos um primary database, um farsync  standby e dois physical standby databases.

ROLE

DB_UNIQUE_NAME

Primary

Livedb

First Cascading Standby (canbeFarSync Standby)

Livefs

Terminal Standby database

livestby1

Terminal Standby database

livestby2

Habilitar cascata em tempo real

Configurando cascateamento de standby databases seguindo os mesmos passos do 11g release 2 ou seguindo os mesmos passos mencionados no primeiro capítulo (farsync standby).

  • No primeiro setup, o método de transporte de log deve ser “SYNC”e  os Standby redologs devem estar configurados no Standby Database em cascata, como mostrado no capítulo anterior.
  • DG_CONFIG do parâmetro log_archive_config deve ter todos os UNIQUE database names dos databases envolvidos (Primary, first cascading database, terminal cascading databases).


log_archive_config= ’dg_config=(livedb,livefs,livestby1,livestby2)’

  • log_archive_dest_n no cascading Standby Database devem ter a mesma configuração:


‘valid_for=(STANDBY_LOGFILES,STANDBY_ROLE)’

  • FAL_SERVER  no primeiro cascading Standby Database deve estar configurado para o Primary ou qualquer outro Standby Database servindo o Primary Database  diretamente.
  • FAL_SERVER no nó terminal do Standby Database em cascata deve estar configurado para cascading Standby Database ou para o Primary Database.
  • Especifique o Log Transport Method como ASYNC para habilitar Real-Time Cascading. Note que “SYNC” log transport method não habilita cascade em tempo real.
  • Usando DBMS_ROLLING para realizar Rolling Upgrades

O Oracle database 12cR1 vêm com a possibilidade  de dividir o ambiente de data guard em dois grupos: O leadinggroup (LG) e o trailinggroup (TG).
O leadinggroup é atualizado primeiro com tudo que contém o novo banco de dados primário. Durante um processo de upgrade, um trailing group database que contém o database primário corrente rodando os binários antigos até que todos os databases do leading group são atualizados. O futuro primário é sincronizado com o velho primário aplicando as mudanças que estavam sendo geradas no primário antigo durante o processo do upgrade. Rolling upgrade garante high availabilitydo ambiente durante o processo do upgrade.
No exemplo seguinte nos iremos usar o DBMS_ROLLING para realizar um rolling upgrade.

Informações do Ambiente

No exemplo seguinte, teremos um primary database e dois physical standby databases.

ROLE

DB_UNIQUE_NAME

GROUP

Primary

Livedb

TG

Standby database

livestby1

TG

Standby database

livestby2

LG

  • Criação do upgrade plan:
SQL> EXECUTE DBMS_ROLLING.INIT_PLAN (future_primary => 'livestby2');
  • Construção do upgrade plan:
SQL> EXECUTE DBMS_ROLLING.BUILD_PLAN; 
  • Inicialização do rolling upgrade:


SQL> EXECUTE DBMS_ROLLING.START_PLAN;

  • Upgrade do LG standby e reinicialize o mesmo em modo READ WRITE usando a versão atualizada do Oracle Database software.
  • Switchover para o LG:
SQL> EXECUTE DBMS_ROLLING.SWITCHOVER; 
  • Mounte o primary “livedb” anterior usando a versão atualizada do Oracle Database software.
  • Mounteos physical standbys do primary “livestby1” anterior usando a versão atualizada do Oracle Database software.
  • Finalize o rolling upgrade:
SQL> EXECUTE DBMS_ROLLING.FINISH_PLAN;

Mais detalhes sobre o DBMS_ROLLING podem ser encontrados aqui:
http://docs.oracle.com/cd/E16655_01/server.121/e17640/dbms_rolling_upgrades.htm#CJAEIFEB

  • SYSDG Privilege

Um usuário que recebeu o privilégio SYSDG pode executar todas as operações em um dataguard usando SQL*Plus ou todos os comando do Data Guard Broker via DGMGRL.
A seguinte lista de comandos que é permita ao usuário que recebeu o privilégio SYSDG rodar

  • STARTUP
  • SHUTDOWN
  • ALTER DATABASE
  • ALTER SESSION
  • ALTER SYSTEM
  • CREATE RESTORE POINT (incluindo GUARANTEED Restore Points)
  • CREATE SESSION
  • DROP RESTORE POINT (incluindo GUARANTEED Restore Points)
  • FLASHBACK DATABASE
  • SELECT ANY DICTIONARY (DBA_ Views)
  • SELECT
    • X$ Tables
    • V$ and GV$ Views
    • APPQOSSYS.WLM_CLASSIFIER_PLAN
  • DELETE
    • APPQOSSYS.WLM_CLASSIFIER_PLAN
  • EXECUTE
    • SYS.DBMS_DRS
  • Movimentação de datafiles no Standby

Antes do 12c, Nós podíamos copiar e renomear um Datafile enquanto Managed Recovery estava parado e o Datafile a ser copiado estava OFFLINE se o Physical Standby Database estivesse aberto em modo READ ONLY utilizando o RMAN , SQL*Plus ou o comando copy do sistema operacional.

Desde o Oracle 12c release 1 é possível mover um standby datafile ONLINE usando o comando:


alter database move datafile '/home/oracle/wissem/data.189.782738241' to '+DATA';
  • Recover Standby Database usando Service Names

Desde do Oracle 12c release 1, é possível fazer recover de um standby database usando um backup comprimido, pela rede (compressed backup over the network). O DBA pode rodar o recover de um standby database server utilizando um servicename válido do primary database. Rodando através do  RMAN o comando listado abaixo:

rmantarget/
recover database fromservicelivedbusingcompressedbackupset;



Joel é um DBA expert com mais de 12 anos de experiência, especializado nas áreas de bases de dados com especial ênfase em soluções de alta disponibilidade (RAC, Dataguard, e outros). É um palestrante habitual em eventos de Oracle como: OTN LAD TOUR e outros. É o primeiro latino-americano a ser nomeado "OTN Expert " no ano de 2003 e é Oracle ACE Director. Durante estes anos, Joel trabalhou como consultor senior em um grande número de empresas e clientes em diversos países:Venezuela, Panama, Costa Rica, Dominican Rep., Haiti, Nicaragua, Guatemala, Colombia, Honduras, Ecuador, Mexico, India, Italy, Franceandothers. Joel isfrequent speaker atmanyconferencessuch as OTN LAD TOUR andothers. Joel wasthefirstLatin American tobenamed “OTN Expert” in year 2003, Oracle ACE since 2004 and Oracle ACE Directorsince 2012.

Wissem é um DBA Sr. com mais de 12 anos de experiência, especializado nas soluções RAC &Dataguard. Atualmente trabalha para “Schneider Electric / APC Global operations”. Wissem trabalhou também para várias empresas internacionais líderes em seus sectores como Bancos, Telecomunicações, Internet e Energia. Wissem foi o primer Oracle ACE na Espanha e é um OCP DBA. Siga Wissem no seu blog www.oracle-class.com ou no twitter @orawiss

Mufalani é um DBA Sr. com mais de 10 anos de experiência, começou com o Oracle 8i, mas teve a oportunidade de dar suporte a Oracle 7.3.4 em diante. É especialista em banco de dados Oracle com foco principal em Performance &Tuning e RAC. É palestrante em eventos de Oracle como: OTN LAD TOUR e outros. Atualmente trabalha como consultor diversas empresas no segmento de variados ramos como: Educação, Saúde, Tecnologia, Seguros e etc. Foi o terceiro Oracle ACE a ser nomeado no Brasil e é OCP DBA nas versões 10g e 11g. Siga Mufalani em seu blog www.mufalani.com.br/blog ou no twitter @mufalani