Dataguard – Blog DBA Dutra

Refresh database from Data Guard

André Luiz Dutra Ontalba — Wed, 13 Dec 2023 20:17:28 +0000

My client asked me for help. He needs to update the DEV environment every month

The current process (using export-import) takes a few days.

To reduce the time, an alternative approach was implemented

Replicate constantly all production changes to a standby database. This is achieved using Data Guard
For the refresh
- Stop synchronization
- Drop old DEV databases
- Create new DEV databases by cloning from the standby database
- Restart synchronization

The new procedure should considerably reduce the refresh time considerably to a few hours.

1 Pre-Requirements

Oracle version and Patch Level on Primary and Secondary should be same.
Db_unique_name on standby and primary database should be different in order to used in DG_CONFIG setting of the LOG_ARCHIVE_CONFIG parameter.

Standby preparation

Check if standby is in sync with primary

****** To check archivelog apply lag

SELECT al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied" FROM
(select thread# thrd, MAX(sequence#) almax FROM v$archived_log WHERE resetlogs_change#=(SELECT resetlogs_change#
FROM v$database) GROUP BY thread#) al, (SELECT thread# thrd, MAX(sequence#) lhmax FROM v$log_history
WHERE resetlogs_change#=(SELECT resetlogs_change# FROM v$database) GROUP BY thread#) lh WHERE al.thrd = lh.thrd;

Convert standby in snapshot standby


shutdown immediate
startup mount
alter database convert to snapshot standby;
alter database open;

Create DB links between Standby and DEV

---- Standby

alter pluggable database ALL open read only;
CREATE USER c##r_clone identified by Oracle23 CONTAINER=ALL;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SYSOPER, RESOURCE, CREATE ANY TABLE, UNLIMITED TABLESPACE TO  c##r_clone CONTAINER=ALL;
GRANT DBA to c##r_clone;

CREATE DATABASE LINK refresh_link CONNECT TO c##r_clone identified by Oracle23 using 'DUTSD'; 

----- Dev Database

CREATE DATABASE LINK refresh_link CONNECT TO c##r_clone identified by Oracle23 using 'DUTSST';

alter pluggable database ALL open read only;
CREATE USER c##r_clone identified by Oracle23 CONTAINER=ALL;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SYSOPER, RESOURCE, CREATE ANY TABLE, UNLIMITED TABLESPACE TO  c##r_clone CONTAINER=ALL;
GRANT DBA to c##r_clone;

Cleanup old PDB’s in DUTSD

####### DROP OLD PDB - DUTSD
Show pdbs; 

ALTER PLUGGABLE DATABASE  CLOSE;
DROP PLUGGABLE DATABASE  INCLUDING DATAFILES;

3 Clone PDBs

The files of standby were created using OMF convention. For this reason the database files need to be converted from

+DATA01/DUTSD//DATAFILE/. to

+DATA01/DUTSST/DATAFILE/.dbf’

Clone DUTSD

CREATE PLUGGABLE DATABASE DUTSD FROM DUTSD@refresh_link storage unlimited tempfile reuse 
file_name_convert=('+DATA01/DUTSD/CCA899613E3D0713E0531114C30A2022/DATAFILE/duts01.474.1147957609','+DATA01/DUTSST/DATAFILE/duts01.dbf',
'+DATA01/DUTSD/CCA899613E3D0713E0531114C30A2022/DATAFILE/duts02.269.1147957617','+DATA01/DUTSST/ /DATAFILE/duts02.dbf') 
keystore identified by "Duts23" parallel 6;

4 Finalize the refresh

. oraenv
sqlplus / as sysdba
shutdown immediate

startup mount

Restore datafiles permissions

exec dbms_dnfs.restore_datafile_permissions('');

Convert the snapshot back to physical standby

show pdbs
alter database convert to physical standby;
shutdown immediate
startup

See you soon in other articles.

Stay tuned by following us on Twitter @aontalba and Linkedin.

Disclaimer: “The postings on this site are my own and do not necessarily represent my current employer positions, strategies, or opinions. The information here was edited to be useful for general purpose, specific data, and identifications was removed to allow reaching a generic audience and to be useful.”

Usando a feature recover standby database from service Dataguard no 19c

André Luiz Dutra Ontalba — Tue, 21 Jan 2020 07:13:53 +0000

Introdução

O Oracle Dataguard, que faz parte do MAA (Max Availability Architecture) é um produto utilizado em larga escala, por diversas empresas, ao redor do mundo. Sua principal funcionalidade é manter uma cópia atualizada do banco de dados primário em um site secundário, na maioria dos casos.

Com a introdução do Active Dataguard no Oracle 11g o produto ganhou novas funcionalidades, permitindo que os usuários utilizem o banco de dados de standby para geração de reports, levou o produto que já era bom a um nível ainda melhor. Ao poder gerar reports com o banco de dados aberto em modo read only with apply, é retirado muita carga do banco de dados de primário.

Com o Oracle 19c, foi introduzido um recurso que permite que DML feito no standby seja redirecionado para o banco de dados primário e depois seja enviado via archivelog para o standby, note que não é recomendado direcionar cargas intensas de modificações no standby database para redirecionar ao banco primário.

As vezes, por algumas falhas como GAP de archivelogs ou alguma reconfiguração, se faz necessário recriar o standby database, e no Oracle 18c é possível, de maneira bem simples, recriar o standby database com um único comando via RMAN.

Benefícios de usar a nova funcionalidade

Simplicidade para criação ou recriação
Melhor controle do processo

Cenário

Primary database: orclcdb
Standby database: orclstb

O banco de dados de standby e primário estão sendo gerenciados pelo Dataguard broker (DGMGRL), que nos auxilia na administração de um ambiente Dataguard, simplificando operações como switchover e diversos outras operações. Para maiores informações, consulte o manual https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/index.html

Verificação do Dataguard

Usando a interface de linha de comando do Oracle Dataguard Broker, emitimos o comando show configuration para mostrar as configurações dos bancos de dados protegidos, no nosso caso, os bancos são orclcdb, o primário e o orclstb que é o nosso standby que irei recriar em seguida após ocasionar uma falha, removendo alguns datafiles do mesmo.

Note, que pela imagem abaixo, não temos problemas e no caso de uma falha do banco primário, o banco de dados de standby poderia ser utilizado como banco primário fazendo um switchover manual, sem maiores problemas. Note que é possível automatizar essa operação, configurando Fast-Start Failover

Gerando problemas no standby

Na imagem abaixo, podemos verificar os datafiles do meu banco de dados de standby, onde iremos causar danos e reconstruir o mesmo a partir do comando recover standby database from service. A listagem abaixo, mostra todos os datafiles do banco de dados em questão (orclstb)

Agora, iremos remover o datafile principal do banco de dados de standby, /u01/app/oracle/oradata/ORCLSTB/system01.dbf

Como esperado, após removermos um datafile, propositalmente o nosso ambiente apresenta problemas, vejam:

Desabilitando o apply no banco de dados de standby

Antes de iniciar o recover do standby database, precisamos parar o sincronismo de archivelogs que estão sendo enviados do banco primário, para isso, usamos o comando abaixo para editar o state do database, ou então, vai se deparar com o erro:

 starting media recovery
 media recovery failed
 RMAN-00571: ===========================================================
 RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
 RMAN-00571: ===========================================================
 RMAN-03002: failure of recover command at 01/19/2020 11:16:26
 RMAN-03015: error occurred in stored script Memory Script
 RMAN-11003: failure during parse/execution of SQL statement: alter database recover
  if needed standby start
 ORA-01153: an incompatible media recovery is active

Após pararmos o recover, basta se logar no RMAN e emitir o comando recover standby database from service, como veremos a seguir:

 [oracle@ora19c ~]$ rman target=sys/oracle@orclstb
  
 Recovery Manager: Release 19.0.0.0.0 - Production on Sun Jan 19 11:27:59 2020
 Version 19.3.0.0.0
  
 Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
  
 connected to target database: ORCLCDB (DBID=2780785463, not open)
  
 RMAN> recover standby database from service orclcdb;
  
 Starting recover at 19-JAN-20
 using target database control file instead of recovery catalog
 Oracle instance started
  
 Total System Global Area    1895823376 bytes
  
 Fixed Size                     9136144 bytes
 Variable Size                436207616 bytes
 Database Buffers            1442840576 bytes
 Redo Buffers                   7639040 bytes
  
 contents of Memory Script:
 {
    restore standby controlfile from service  'orclcdb';
    alter database mount standby database;
 }
 executing Memory Script
  
 Starting restore at 19-JAN-20
 allocated channel: ORA_DISK_1
 channel ORA_DISK_1: SID=39 device type=DISK
  
 channel ORA_DISK_1: starting datafile backup set restore
 channel ORA_DISK_1: using network backup set from service orclcdb
 channel ORA_DISK_1: restoring control file
 channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
 output file name=/u01/app/oracle/oradata/ORCLSTB/control01.ctl
 output file name=/u01/app/oracle/fast_recovery_area/ORCLSTB/control02.ctl
 Finished restore at 19-JAN-20
  
 released channel: ORA_DISK_1
 Statement processed
  
 contents of Memory Script:
 {
 set newname for datafile  1 to 
  "/u01/app/oracle/oradata/ORCLSTB/system01.dbf";
    restore from service  'orclcdb' datafile
     1;
    catalog datafilecopy  "/u01/app/oracle/oradata/ORCLSTB/system01.dbf";
    switch datafile all;
 }
 executing Memory Script
  
 executing command: SET NEWNAME
  
 Starting restore at 19-JAN-20
 Starting implicit crosscheck backup at 19-JAN-20
 allocated channel: ORA_DISK_1
 channel ORA_DISK_1: SID=49 device type=DISK
 Crosschecked 3 objects
 Finished implicit crosscheck backup at 19-JAN-20
  
 Starting implicit crosscheck copy at 19-JAN-20
 using channel ORA_DISK_1
 Crosschecked 2 objects
 Finished implicit crosscheck copy at 19-JAN-20
  
 searching for all files in the recovery area
 cataloging files...
 cataloging done
  
 List of Cataloged Files
 =======================
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_25_gyq4g4hz_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_26_gyq5km3v_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_27_gyq64bom_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_28_gyq64n7f_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_29_gyq64zy8_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_30_gyq6vxg5_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_32_gyq6vzrv_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_31_gyq6vzs6_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_33_gyq84b59_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_34_gyq88dll_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_35_gyq9rvx9_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_36_gyqcf807_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_37_gyqcfsk1_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_38_gyqcg4l3_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_39_gyqckh4o_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_41_gyqckkfk_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_40_gyqckkg6_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_42_gyqcpsko_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/o1_mf_1_43_gyqdchj7_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/o1_mf_1_44_gyso1jwz_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/o1_mf_1_45_gytopnjo_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/o1_mf_1_46_gytowb7h_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_47_h1gstntb_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_48_h1gtcgd0_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_49_h1gv3wqn_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_50_h1gv8rbs_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/o1_mf_1_51_h1gvo2x8_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_16/o1_mf_1_52_h21lqfd2_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_16/o1_mf_1_53_h21m7fwt_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_19/o1_mf_1_54_h28w8y78_.arc
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/o1_mf_s_1026372241_gyq6h263_.bkp
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/o1_mf_s_1026373077_gyq7r09k_.bkp
 File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/o1_mf_s_1026378166_gyqd9fxy_.bkp
  
 using channel ORA_DISK_1
  
 channel ORA_DISK_1: starting datafile backup set restore
 channel ORA_DISK_1: using network backup set from service orclcdb
 channel ORA_DISK_1: specifying datafile(s) to restore from backup set
 channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/ORCLSTB/system01.dbf
 channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
 Finished restore at 19-JAN-20
  
 cataloged datafile copy
 datafile copy file name=/u01/app/oracle/oradata/ORCLSTB/system01.dbf RECID=5 STAMP=1030102136
  
 datafile 1 switched to datafile copy
 input datafile copy RECID=5 STAMP=1030102136 file name=/u01/app/oracle/oradata/ORCLSTB/system01.dbf
  
 contents of Memory Script:
 {
   recover database from service  'orclcdb';
 }
 executing Memory Script
  
 Starting recover at 19-JAN-20
 using channel ORA_DISK_1
 skipping datafile 1; already restored to SCN 4595092
 skipping datafile 3; already restored to SCN 4594570
 skipping datafile 5; already restored to SCN 2163739
 skipping datafile 6; already restored to SCN 2163739
 skipping datafile 7; already restored to SCN 4594577
 skipping datafile 8; already restored to SCN 2163739
 skipping datafile 9; already restored to SCN 4594580
 skipping datafile 10; already restored to SCN 4594582
 skipping datafile 12; already restored to SCN 4594588
 skipping datafile 13; already restored to SCN 4594593
 skipping datafile 14; already restored to SCN 4594596
 skipping datafile 15; already restored to SCN 4594598
 skipping datafile 19; already restored to SCN 4594600
 skipping datafile 20; already restored to SCN 4594604
 skipping datafile 21; already restored to SCN 4594611
  
 starting media recovery
  
 media recovery complete, elapsed time: 00:00:00
 Finished recover at 19-JAN-20
 Finished recover at 19-JAN-20
  
 RMAN>

Como podemos ver, como uma única linha do RMAN, foi possível recuperar o meu banco de dados de standby, se os danos fossem outros, o resultado final seria o mesmo que obtivemos nesse exemplo, banco de dados restaurado e pronto para ser sincronizado novamente.

Então, pela interface do DGMGRL, ativamos o sincronismo novamente conforme vemos abaixo:

Para validar, se tudo ocorreu bem, vamos realizer um switchover para trocar os papéis dos bancos de dados fazendo com que o banco primário vire standby e vice versa. Como podemos ver na imagem abaixo, sem problemas para realizar o switchover:

Agora o meu banco de dados orclstb, originalmente standby database, agora passou a ser meu banco de dados primário, com todos os pdbs abertos para uso.

Todos os nossos PDBs estão abertos e como podemos ver, a instance com db_unique_name = orclstb agora está com a ROLE (papel) PRIMARY.

Conclusão:A Oracle sempre está evoluindo e o produto sempre agregando novas funcionalidades, temos que concordar que essa funcionalidade salva um bom tempo de trabalho para os DBAs e ainda simplifica demais a criação de um standby database.

Esperamos ter ajudado !!

Até a próxima !!

André Luiz Dutra Ontalba / Rodrigo Mufalani / Y V RaviKumar

Configure Data Guard Physical Setup usando Data Broker no Oracle Database 19c / Data Guard Physical Setup using Data Broker in Oracle Database 19c

André Luiz Dutra Ontalba — Sat, 11 May 2019 21:48:56 +0000

Configure o Data Guard Physical com Data Broker no Oracle Database 19c

Ambiente

Necessário ter dois servidores (VMs ou físicos) com um sistema operacional e Oracle instalado. Meu ambiente eu usei Oracle Linux 7.6 e Oracle Database 19c.
O servidor primário (duts-dg1) tem uma instância em execução.
O servidor em standby (duts-dg2) somente a instalação dos binários.
Sem nenhum bloqueio a comunicação entre as máquinas sobre o listener.

Primary Server Setup

Logging

Verifique se o banco de dados primário está no modo ARCHIVELOG.

SELECT log_mode FROM v$database;

LOG_MODE

————

NOARCHIVELOG

SQL>

Se estiver em NOARCHIVELOG mode, altere para o modo ARCHIVELOG.

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

Habilite o log FORCE LOGGING.

ALTER DATABASE FORCE LOGGING;

— Make sure at least one logfile is present.

ALTER SYSTEM SWITCH LOGFILE;

Crie os standby redo logs no database primário (em caso de switchovers). O standby redo logs deve ser o mesmo tamanho que os redo logs e deve haver um grupo extra por thread. No meu caso, os seguintes standby redo logs deve ser criado em ambos os servidores.

— If Oracle Managed Files (OMF) is not used.

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo01.log’) SIZE 100M;

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo02.log’) SIZE 100M;

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo03.log’) SIZE 100M;

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo04.log’) SIZE 100M;

— If Oracle Managed Files (OMF) is used.

ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;

Se voce que usar a feature flashback database, ative no servidor primário agora, e ele será ativo no standby também. Eu sempre uso em meus ambientes.

ALTER DATABASE FLASHBACK ON;

Initialization Parameters

Verifique a configuração dos parâmetros DB_UNIQUE_NAME e DB_NAME . Nesse caso, eles são definidos como “duts” no banco de dados primário.

SQL> show parameter db_name

NAME TYPE VALUE

———————————— ———– ——————————

db_name string duts

SQL> show parameter db_unique_name

NAME TYPE VALUE

———————————— ———– ——————————

db_unique_name string duts

SQL>

O DB_NAME do standby database será o mesmo que o da primário, mas deve ser diferente o valor do DB_UNIQUE_NAME. Para este exemplo, o banco de dados standby terá o valor “duts_stby”.

Verifique se o parâmetro STANDBY_FILE_MANAGEMENT está definido.

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Service Setup

As entradas para os bancos de dados primário e em standby são necessárias no “$ORACLE_HOME/network/admin/tnsnames.ora” em ambos servidores.

Você pode criá-los usando o utilitário de configuração de rede (netca) ou manualmente.

As seguintes entradas foram usadas durante esta configuração. Observe o uso do SID, em vez do SERVICE_NAME nas entradas. Isto é importante quando o broker for se conectar a os bancos de dados quando eles estão em shutdown, porque os serviços não estarão ativos.

duts =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))

)

(CONNECT_DATA =

(SID = duts)

)

duts_stby =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))

)

(CONNECT_DATA =

(SID = duts)

)

O arquivo “$ORACLE_HOME/network/admin/listener.ora” no servidor primário contém a seguinte configuração.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = duts_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/19.0.0/db_1)

(SID_NAME = duts)

)

ADR_BASE_LISTENER = /u01/app/oracle

O arquivo “$ORACLE_HOME/network/admin/listener.ora” no servidor standby contém a seguinte configuração.

Uma vez que o broker será necessário se conectar ao banco de dados quando estiver em shutdown. Não podemos confiar no registro automático com o listener, Portanto, uma a entrada explícita para o banco de dados.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = duts_stby_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/19.0.0/db_1)

(SID_NAME = duts)

)

ADR_BASE_LISTENER = /u01/app/oracle

Uma vez que o listener.ora estiver ok, reinicie o listener em ambos os servers.

lsnrctl stop

lsnrctl start

Configuração do Servidor Standby

Preparando o Duplicate

Crie um arquivo de parâmetros “/tmp/initduts_stby.ora” para o standby database com os seguintes conteúdos.

*.db_name=’duts’

Crie os diretórios necessários no servidor standby

mkdir -p /u02/data/duts/pdbseed

mkdir -p /u02/data/duts/pdb1

mkdir -p /u02/app/oracle/fast_recovery_area/duts

mkdir -p /u02/app/oracle/admin/duts/adump

Criar um arquivo de senha, com a mesma senha do SYS usado no banco de dados primário.

$ orapwd file=/u01/app/oracle/product/19.0.0/db_1/dbs/orapwduts password=oracle entries=10

Criando o Standby usando o DUPLICATE

Inicie a instancia auxiliar no servidor standby com o arquivo de parâmetros gerados.

$ export ORACLE_SID=duts

$ sqlplus / as sysdba

SQL> STARTUP NOMOUNT PFILE=’/tmp/initduts_stby.ora’;

Conecte-se ao RMAN, especificando a string completa para o TARGET e AUXILIARY. Não tente usar a autenticação do sistema operacional.

$ rman TARGET sys/oracle@duts AUXILIARY sys/oracle@duts_stby

Agora emita o seguinte comando DUPLICATE.

DUPLICATE TARGET DATABASE

FOR STANDBY

FROM ACTIVE DATABASE

DORECOVER

SPFILE

SET db_unique_name=’duts_stby’ COMMENT ‘Is standby 19c’

NOFILENAMECHECK;

Se você precisar converter locais de arquivos, ou alterar quaisquer parâmetros de inicialização, você pode fazer isso durante a duplicate usando o comando Set.

DUPLICATE TARGET DATABASE

FOR STANDBY

FROM ACTIVE DATABASE

DORECOVER

SPFILE

SET db_unique_name=’duts_stby’ COMMENT ‘Is standby 19c’

SET db_file_name_convert=’/u01/data/duts/’,’/u02/data/duts/’

SET log_file_name_convert=’/u01/data/duts/’,’/u02/data/duts/’

SET job_queue_processes=’0′

NOFILENAMECHECK;

Uma breve explicação das cláusulas individuais é mostrada abaixo.

FOR STANDBY: Isto informa que o comando DUPLICATE deve ser utilizado para um standby, por isso não vai forçar uma troca do DBID.
FROM ACTIVE DATABASE: O DUPLICATE será criado diretamente a partir dos DataFiles de origem, sem nehum backup adicional.
DORECOVER: O DUPLICATE incluirá a etapa de recuperação, trazendo o standby até o ponto atual no tempo.
SPFILE: Nos permite redefinir valores no SPFile quando ele é copiado do servidor de origem.
NOFILENAMECHECK: Locais de arquivo de destino não são verificados.

Uma vez que o DUPLICATE está completo, podemos começar a usar o broker.

Ativando Broker

Neste ponto, temos o banco de dados primário e o standby database, então agora precisamos começar a usar o Data Guard Broker para gerenciá-los. Faça a conexão em ambos databases (primário e standby) e emitir o seguinte comando.

ALTER SYSTEM SET dg_broker_start=true;

No servidor primário, emita o seguinte comando para registrar o servidor primário com o Broker.

$ dgmgrl sys/oracle@duts

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 14:39:33 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS duts CONNECT IDENTIFIER IS duts;

Configuration “dg_config” created with primary database “duts”

DGMGRL>

Agora adicione o banco de dados standby.

DGMGRL> ADD DATABASE duts_stby AS CONNECT IDENTIFIER IS duts_stby MAINTAINED AS PHYSICAL;

Database “duts_stby” added

DGMGRL>

Agora vamos ativar a nova configuração.

DGMGRL> ENABLE CONFIGURATION;

Enabled.

DGMGRL>

Os comandos a seguir mostram como verificar a configuração e o status dos bancos de dados do Broker.

DGMGRL> SHOW CONFIGURATION;

Configuration – dg_config

Protection Mode: MaxPerformance

Members:

duts – Primary database

duts_stby – Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS (status updated 26 seconds ago)

DGMGRL> SHOW DATABASE duts;

Database – duts

Role: PRIMARY

Intended State: TRANSPORT-ON

Instance(s):

duts

Database Status:

SUCCESS

DGMGRL> SHOW DATABASE duts_stby;

Database – duts_stby

Role: PHYSICAL STANDBY

Intended State: APPLY-ON

Transport Lag: 0 seconds (computed 1 second ago)

Apply Lag: 0 seconds (computed 1 second ago)

Average Apply Rate: 5.00 KByte/s

Real Time Query: OFF

Instance(s):

duts

Database Status:

SUCCESS

DGMGRL>

Database Switchover

Um banco de dados pode estar em um dos dois modos mutuamente exclusivos (Primário ou standby). Essas funções podem ser alteradas em tempo de execução sem perda de dados ou reset dos redo logs. Este processo é conhecido como um Switchover e podem ser executadas usando os seguintes comandos. Conecte-se ao banco de dados primário (duts) e faça o switchover para o banco de dados standby (duts_stby).

$ dgmgrl sys/oracle@duts

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 14:55:33 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> SWITCHOVER TO duts_stby;

Performing switchover NOW, please wait…

Operation requires a connection to instance “duts” on database “duts_stby”

Connecting to instance “duts”…

Connected as SYSDBA.

New primary database “duts_stby” is opening…

Operation requires start up of instance “duts” on database “duts”

Starting instance “duts”…

ORACLE instance started.

Database mounted.

Switchover succeeded, new primary is “duts_stby”

DGMGRL>

Vamos mudar de volta para o primário original. Conecte-se ao novo primário (duts_stby) e faça o switchover para o novo banco de dados standby (duts).

$ dgmgrl sys/oracle@duts_stby

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 14:57:20 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> SWITCHOVER TO duts;

Performing switchover NOW, please wait…

Operation requires a connection to instance “duts” on database “duts”

Connecting to instance “duts”…

Connected as SYSDBA.

New primary database “duts” is opening…

Operation requires start up of instance “duts” on database “duts_stby”

Starting instance “duts”…

ORACLE instance started.

Database mounted.

Switchover succeeded, new primary is “duts”

DGMGRL>

Database Failover

Se o banco de dados primário não estiver disponível, o banco de dados standby poderá ser ativado como um banco de dados primário usando as instruções a seguir. Conecte-se ao banco de dados standby (duts_stby) e ao failover.

$ dgmgrl sys/oracle@duts_stby

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 15:00:20 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> FAILOVER TO duts_stby;

Performing failover NOW, please wait…

Failover succeeded, new primary is “duts_stby”

DGMGRL>

Uma vez que o banco de dados standby é agora o banco de dados primário, deve ser feito um backup imediatamente do mesmo.

O banco de dados primário original agora pode ser configurado como um standby. Se o flashback database foi habilitado no banco de dados primário, então isso pode ser feito relativamente facil com o seguinte comando.

DGMGRL> REINSTATE DATABASE duts;

Reinstating database “duts”, please wait…

Operation requires shut down of instance “duts” on database “duts”

Shutting down instance “duts”…

ORACLE instance shut down.

Operation requires start up of instance “duts” on database “duts”

Starting instance “duts”…

ORACLE instance started.

Database mounted.

Continuing to reinstate database “duts” …

Reinstatement of database “duts” succeeded

DGMGRL>

Se flashback database não estiver ativado, você terá que recriar manualmente duts como um standby. O processo basicamente o inverso do que você fez anteriormente.

# 1) Cleanup the old instance.

sqlplus / as sysdba <

SHUTDOWN IMMEDIATE;

EXIT;

EOF

rm -Rf /u01/data/duts/*

rm -Rf /u01/app/oracle/fast_recovery_area/duts

rm -Rf /u01/app/oracle/fast_recovery_area/duts_stby

rm -Rf /u01/app/oracle/admin/duts

mkdir -p /u01/app/oracle/fast_recovery_area/duts

mkdir -p /u01/app/oracle/admin/duts/adump

mkdir -p /u01/data/duts/pdbseed

mkdir -p /u01/data/duts/pdb1

rm $ORACLE_HOME/dbs/spfileduts.ora

export ORACLE_SID=duts

sqlplus / as sysdba <

STARTUP NOMOUNT PFILE=’/tmp/initduts_stby.ora’;

EXIT;

EOF

# 2) Connect to RMAN.

$ rman TARGET sys/oracle@duts_stby AUXILIARY sys/oracle@duts

# 3) Duplicate the database.

DUPLICATE TARGET DATABASE

FOR STANDBY

FROM ACTIVE DATABASE

DORECOVER

SPFILE

SET db_unique_name=’duts’ COMMENT ‘Is standby 19c’

SET db_file_name_convert=’/u02/data/duts/’,’/u01/data/duts/’

SET log_file_name_convert=’/u02/data/duts/’,’/u01/data/duts/’

SET job_queue_processes=’0′

NOFILENAMECHECK;

# 4) Connect to DGMDRL on the current primary.

$ dgmgrl sys/oracle@duts_stby

# 5) Enable the new standby.

DGMGRL> ENABLE DATABASE duts;

Flashback Database

Ele já foi mencionado na seção anterior, mas vale a pena chamar sua atenção para Flashback Database mais uma vez. Embora um switchover/switchback é seguro para ambos o banco de dados primário e standby, a failover transforma o banco de dados primário inútil para converter para um banco de dados em standby. Se flashback database não estiver ativo, o banco de dados primário original deve ser desfeito e recriado como um banco de dados em standby.

Uma alternativa é habilitar flashback database no banco de dados primário (e o standby se desejado) assim, no caso de um failover, o primário pode ser feito um flashed back para o um ponto antes do failover e rapidamente convertido em um banco de dados standby, como mostrado acima.

Criação de application services

Para facilitar a administração de conexões de cliente, e para tornar as operações SWITCHOVER mais transparentes para os clientes, é recomendável criar serviços no banco de dados.

Exemplo, definição de serviço « DUTSS » :

begin DBMS_SERVICE.CREATE_SERVICE ( service_name => ‘DUTSS’,

network_name => ‘ DUTSS ‘,

failover_method => ‘BASIC’,

failover_type => ‘SELECT’,

failover_retries => 180,

failover_delay => 1);

end;

Neste caso, há 180 tentativas e um delay de 1 segundo(Então, basicamente 3 minutos antes do switching). Isto deve ser adaptado dependendo de suas necessidades e exigências.

Este é o serviço que devem ser usados pelo client.

Criando trigger de Startup

Para gerenciar o início automático dos serviços, em especial no caso de uma transição de função, a seguinte TRIGGER deve ser criado (exemplo para o serviço DUTS). A trigger deve ser criado no SYS:

Connect SYS as SYSDBA

CREATE OR REPLACE TRIGGER manage_app_services

AFTER STARTUP

ON DATABASE

DECLARE

role VARCHAR (30);

BEGIN

SELECT DATABASE_ROLE INTO role FROM V$DATABASE;

IF role = ‘PRIMARY’

THEN

DBMS_SERVICE.START_SERVICE (‘DUTSS’);

END IF;

END;

Em seguida, reiniciamos o banco de dados primário para verificar se o serviço foi iniciado:

sqlplus / as sysdba

shutdown immediate ;

startup

Conexões de cliente

Para fazer as transições de função (como resultado de um SWITCHOVER ou FAILOVER) transparente para os usuários do banco de dados a connection string precisa ser configurado com um failover connection string.

Isso pode ser configurado no TNSNAMES.ORA, configurando dois endereços ou duas descrições para o mesmo alias.

Exemplo de um alias definido para DUTS:

DUTS =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))

)

(CONNECT_DATA = (SERVICE_NAME = DUTSS))

)

Com esse método, os clientes tentarão primeiro se conectar ao primeiro endereço (correspondente ao servidor primário). Se estiver operacional, a conexão é estabelecida com esta base.

Se este primeiro endereço não responde (servidor primário indisponível ou serviços parados), em seguida, o cliente tenta se conectar ao segundo endereço (apontando para o servidor standby). Se estiver operacional (que será o caso apenas depois de um SWITCHOVER ou um FAILOVER), em seguida, o cliente se conectará à base de emergência de forma transparente e automática.

Environments

You have two servers (VMs or physical) with an operating system and Oracle installed on them. My environment I’ve used Oracle Linux 7.6 and Oracle Database 19c.
The primary server (duts-dg1) has a running instance.
The standby server (duts-dg2) has a software only installation.
There is nothing blocking communication between the machines over the listener ports.

Primary Server Setup

Logging

Check that the primary database is in archivelog mode.

SELECT log_mode FROM v$database;

LOG_MODE

————

NOARCHIVELOG

SQL>

If it is noarchivelog mode, switch is to archivelog mode.

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

Enabled forced logging by issuing the following command.

ALTER DATABASE FORCE LOGGING;

— Make sure at least one logfile is present.

ALTER SYSTEM SWITCH LOGFILE;

Create standby redo logs on the primary database (in case of switchovers). The standby redo logs should be at least as big as the largest online redo log and there should be one extra group per thread compared the online redo logs. In my case, the following standby redo logs must be created on both servers.

— If Oracle Managed Files (OMF) is not used.

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo01.log’) SIZE 100M;

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo02.log’) SIZE 100M;

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo03.log’) SIZE 100M;

ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/data/duts/std_redo04.log’) SIZE 100M;

— If Oracle Managed Files (OMF) is used.

ALTER DATABASE ADD STANDBY LOGFILE SIZE 100M;

If you want to user flashback database, enable it on the primary now, so it will be enabled on the standby also. I always use it in my environments.

ALTER DATABASE FLASHBACK ON;

Initialization Parameters

Check the setting for the DB_NAME and DB_UNIQUE_NAME parameters. In this case they are both set to “duts” on the primary database.

SQL> show parameter db_name

NAME TYPE VALUE

———————————— ———– ——————————

db_name string duts

SQL> show parameter db_unique_name

NAME TYPE VALUE

———————————— ———– ——————————

db_unique_name string duts

SQL>

The DB_NAME of the standby database will be the same as that of the primary, but it must have a different DB_UNIQUE_NAME value. For this example, the standby database will have the value “duts_stby”.

Make sure the STANDBY_FILE_MANAGEMENT parameter is set.

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Service Setup

Entries for the primary and standby databases are needed in the “$ORACLE_HOME/network/admin/tnsnames.ora” files on both servers.

You can create these using the Network Configuration Utility (netca) or manually.

The following entries were used during this setup. Notice the use of the SID, rather than the SERVICE_NAME in the entries. This is important as the broker will need to connect to the databases when they are down, so the services will not be present.

duts =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))

)

(CONNECT_DATA =

(SID = duts)

)

duts_stby =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))

)

(CONNECT_DATA =

(SID = duts)

)

The “$ORACLE_HOME/network/admin/listener.ora” file on the primary server contains the following configuration.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = duts_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/19.0.0/db_1)

(SID_NAME = duts)

)

ADR_BASE_LISTENER = /u01/app/oracle

The “$ORACLE_HOME/network/admin/listener.ora” file on the standby server contains the following configuration.

Since the broker will need to connect to the database when it’s down, we can’t rely on auto-registration with the listener, hence the explicit entry for the database.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = duts_stby_DGMGRL)

(ORACLE_HOME = /u01/app/oracle/product/19.0.0/db_1)

(SID_NAME = duts)

)

ADR_BASE_LISTENER = /u01/app/oracle

Once the listener.ora changes are in place, restart the listener on both servers.

lsnrctl stop

lsnrctl start

Standby Server Setup

Prepare for Duplicate

Create a parameter file for the standby database called “/tmp/initduts_stby.ora” with the following contents.

*.db_name=’duts’

Create the necessary directories on the standby server.

mkdir -p /u02/data/duts/pdbseed

mkdir -p /u02/data/duts/pdb1

mkdir -p /u02/app/oracle/fast_recovery_area/duts

mkdir -p /u02/app/oracle/admin/duts/adump

Create a password file, with the SYS password matching that of the primary database.

$ orapwd file=/u01/app/oracle/product/19.0.0/db_1/dbs/orapwduts password=oracle entries=10

Create Standby Using DUPLICATE

Start the auxiliary instance on the standby server by starting it using the temporary “init.ora” file.

$ export ORACLE_SID=duts

$ sqlplus / as sysdba

SQL> STARTUP NOMOUNT PFILE=’/tmp/initduts_stby.ora’;

Connect to RMAN, specifying a full connect string for both the TARGET and AUXILIARY instances. Do not attempt to use OS authentication.

$ rman TARGET sys/oracle@duts AUXILIARY sys/oracle@duts_stby

Now issue the following DUPLICATE command.

DUPLICATE TARGET DATABASE

FOR STANDBY

FROM ACTIVE DATABASE

DORECOVER

SPFILE

SET db_unique_name=’duts_stby’ COMMENT ‘Is standby 19c’

NOFILENAMECHECK;

If you need to convert file locations, or alter any initialization parameters, you can do this during the DUPLICATE using the SET command.

DUPLICATE TARGET DATABASE

FOR STANDBY

FROM ACTIVE DATABASE

DORECOVER

SPFILE

SET db_unique_name=’duts_stby’ COMMENT ‘Is standby 19c’

SET db_file_name_convert=’/u01/data/duts/’,’/u02/data/duts/’

SET log_file_name_convert=’/u01/data/duts/’,’/u02/data/duts/’

SET job_queue_processes=’0′

NOFILENAMECHECK;

A brief explanation of the individual clauses is shown below.

FOR STANDBY: This tells the DUPLICATE command is to be used for a standby, so it will not force a DBID change.

FROM ACTIVE DATABASE: The DUPLICATE will be created directly from the source datafiles, without an additional backup step.

DORECOVER: The DUPLICATE will include the recovery step, bringing the standby up to the current point in time.

SPFILE: Allows us to reset values in the spfile when it is copied from the source server.

NOFILENAMECHECK: Destination file locations are not checked.

Once the command is complete, we can start using the broker.

Enable Broker

At this point we have a primary database and a standby database, so now we need to start using the Data Guard Broker to manage them. Connect to both databases (primary and standby) and issue the following command.

ALTER SYSTEM SET dg_broker_start=true;

On the primary server, issue the following command to register the primary server with the broker.

$ dgmgrl sys/oracle@duts

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 14:39:33 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS duts CONNECT IDENTIFIER IS duts;

Configuration “dg_config” created with primary database “duts”

DGMGRL>

Now add the standby database.

DGMGRL> ADD DATABASE duts_stby AS CONNECT IDENTIFIER IS duts_stby MAINTAINED AS PHYSICAL;

Database “duts_stby” added

DGMGRL>

Now we enable the new configuration.

DGMGRL> ENABLE CONFIGURATION;

Enabled.

DGMGRL>

The following commands show how to check the configuration and status of the databases from the broker.

DGMGRL> SHOW CONFIGURATION;

Configuration – dg_config

Protection Mode: MaxPerformance

Members:

duts – Primary database

duts_stby – Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS (status updated 26 seconds ago)

DGMGRL> SHOW DATABASE duts;

Database – duts

Role: PRIMARY

Intended State: TRANSPORT-ON

Instance(s):

duts

Database Status:

SUCCESS

DGMGRL> SHOW DATABASE duts_stby;

Database – duts_stby

Role: PHYSICAL STANDBY

Intended State: APPLY-ON

Transport Lag: 0 seconds (computed 1 second ago)

Apply Lag: 0 seconds (computed 1 second ago)

Average Apply Rate: 5.00 KByte/s

Real Time Query: OFF

Instance(s):

duts

Database Status:

SUCCESS

DGMGRL>

Database Switchover

A database can be in one of two mutually exclusive modes (primary or standby). These roles can be altered at runtime without loss of data or resetting of redo logs. This process is known as a Switchover and can be performed using the following commands. Connect to the primary database (duts) and switchover to the standby database (duts_stby).

$ dgmgrl sys/oracle@duts

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 14:55:33 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> SWITCHOVER TO duts_stby;

Performing switchover NOW, please wait…

Operation requires a connection to instance “duts” on database “duts_stby”

Connecting to instance “duts”…

Connected as SYSDBA.

New primary database “duts_stby” is opening…

Operation requires start up of instance “duts” on database “duts”

Starting instance “duts”…

ORACLE instance started.

Database mounted.

Switchover succeeded, new primary is “duts_stby”

DGMGRL>

Let’s switch back to the original primary. Connect to the new primary (duts_stby) and switchover to the new standby database (duts).

$ dgmgrl sys/oracle@duts_stby

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 14:57:20 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> SWITCHOVER TO duts;

Performing switchover NOW, please wait…

Operation requires a connection to instance “duts” on database “duts”

Connecting to instance “duts”…

Connected as SYSDBA.

New primary database “duts” is opening…

Operation requires start up of instance “duts” on database “duts_stby”

Starting instance “duts”…

ORACLE instance started.

Database mounted.

Switchover succeeded, new primary is “duts”

DGMGRL>

Database Failover

If the primary database is not available the standby database can be activated as a primary database using the following statements. Connect to the standby database (duts_stby) and failover.

$ dgmgrl sys/oracle@duts_stby

DGMGRL for Linux: Release 19.0.0.0.0 – Production on Tue May 11 15:00:20 2019

Version 19.2.0.0.0

Welcome to DGMGRL, type “help” for information.

Connected as SYSDBA.

DGMGRL> FAILOVER TO duts_stby;

Performing failover NOW, please wait…

Failover succeeded, new primary is “duts_stby”

DGMGRL>

Since the standby database is now the primary database it should be backed up immediately.

The original primary database can now be configured as a standby. If flashback database was enabled on the primary database, then this can be done relatively easily with the following command.

DGMGRL> REINSTATE DATABASE duts;

Reinstating database “duts”, please wait…

Operation requires shut down of instance “duts” on database “duts”

Shutting down instance “duts”…

ORACLE instance shut down.

Operation requires start up of instance “duts” on database “duts”

Starting instance “duts”…

ORACLE instance started.

Database mounted.

Continuing to reinstate database “duts” …

Reinstatement of database “duts” succeeded

DGMGRL>

If flashback database is not enabled, you would have to manually recreate duts as a standby. The basic process is the reverse of what you did previously.

# 1) Cleanup the old instance.

sqlplus / as sysdba <

SHUTDOWN IMMEDIATE;

EXIT;

EOF

rm -Rf /u01/data/duts/*

rm -Rf /u01/app/oracle/fast_recovery_area/duts

rm -Rf /u01/app/oracle/fast_recovery_area/duts_stby

rm -Rf /u01/app/oracle/admin/duts

mkdir -p /u01/app/oracle/fast_recovery_area/duts

mkdir -p /u01/app/oracle/admin/duts/adump

mkdir -p /u01/data/duts/pdbseed

mkdir -p /u01/data/duts/pdb1

rm $ORACLE_HOME/dbs/spfileduts.ora

export ORACLE_SID=duts

sqlplus / as sysdba <

STARTUP NOMOUNT PFILE=’/tmp/initduts_stby.ora’;

EXIT;

EOF

# 2) Connect to RMAN.

$ rman TARGET sys/oracle@duts_stby AUXILIARY sys/oracle@duts

# 3) Duplicate the database.

DUPLICATE TARGET DATABASE

FOR STANDBY

FROM ACTIVE DATABASE

DORECOVER

SPFILE

SET db_unique_name=’duts’ COMMENT ‘Is standby 19c’

SET db_file_name_convert=’/u02/data/duts/’,’/u01/data/duts/’

SET log_file_name_convert=’/u02/data/duts/’,’/u01/data/duts/’

SET job_queue_processes=’0′

NOFILENAMECHECK;

# 4) Connect to DGMDRL on the current primary.

$ dgmgrl sys/oracle@duts_stby

# 5) Enable the new standby.

DGMGRL> ENABLE DATABASE duts;

Flashback Database

It was already mentioned in the previous section, but it is worth drawing your attention to Flashback Database once more. Although a switchover/switchback is safe for both the primary and standby database, a failover renders the original primary database useless for converting to a standby database. If flashback database is not enabled, the original primary must be scrapped and recreated as a standby database.

An alternative is to enable flashback database on the primary (and the standby if desired) so in the event of a failover, the primary can be flashed back to the time before the failover and quickly converted to a standby database, as shown above.

Creation of application services

To facilitate the administration of client connections, and to make SWITCHOVER operations more transparent for clients, it is recommended to create database SERVICES.

Example, service definition « DUTSS » :

begin DBMS_SERVICE.CREATE_SERVICE ( service_name => ‘DUTSS’,

network_name => ‘ DUTSS ‘,

failover_method => ‘BASIC’,

failover_type => ‘SELECT’,

failover_retries => 180,

failover_delay => 1);

end;

In this case, there are 180 retries and a delay of 1 second (so basically 3 minutes before switching). This should be adapted depending on your needs and requirements.

These are the services that should be used by client application connections.

Creating the Startup trigger

To manage the automatic start of the services, in particular in the event of a role transition, the following TRIGGER must be created (example for the DUTS service). The trigger must be created under SYS:

Connect SYS as SYSDBA

CREATE OR REPLACE TRIGGER manage_app_services

AFTER STARTUP

ON DATABASE

DECLARE

role VARCHAR (30);

BEGIN

SELECT DATABASE_ROLE INTO role FROM V$DATABASE;

IF role = ‘PRIMARY’

THEN

DBMS_SERVICE.START_SERVICE (‘DUTSS’);

END IF;

END;

Then we restart the PRIMARY database to check that the service is started:

sqlplus / as sysdba

shutdown immediate ;

startup

Client connections

To make the role transitions (as a result of a SWITCHOVER or FAILOVER) transparent to users the client database connection string needs to be configured with a failover connection string.

This can be configured at the TNSNAMES.ORA file level by configuring two addresses or two descriptions for the same alias.

Example of an alias defined for DUTS:

DUTS =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg1)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = duts-dg2)(PORT = 1521))

)

(CONNECT_DATA = (SERVICE_NAME = DUTSS))

)

With this method, clients will attempt to first connect to the first address (corresponding to the primary server and database). If it is operational (which should be the case in a nominal way), the connection is established with this base.

If this first address does not respond (primary server unavailable or services stopped), then the client tries to connect to the second address (pointing to the standby server). If it is operational (which will be the case only after a SWITCHOVER or a FAILOVER), then the client will connect to the emergency base transparently and automatically.

Hope this helps !!!

Soon we will have more articles on the Oracle 19c.

Instalando Oracle Data Guard 12c

André Luiz Dutra Ontalba — Mon, 05 Oct 2015 18:19:35 +0000

Do que se trata o artigo:

Neste artigo vamos realizar a instalação do Oracle Data Guard 12c.

Em que situação o tema é útil:

Montagem de ambiente Contingência com Oracle Data Guard

Olá amigos, hoje vamos a um desafio bem grande montar um Oracle Data Guard 12c

Como laboratório vamos estar usando as mídias do Oracle Database 12c e do virtualbox que se encontram nos links abaixo:

Vamos precisar das seguintes mídias para realizar a instalação do ambiente:

Oracle Linux: Realizar o download das mídias do Oracle Linux 6 Update 5 – 64 Bits.

VirtualBox: Realizar da última versão estável.
Oracle Database 12c Release 1 (12.1.0.1.0): Realizar da última versão do Oracle 12c para Linux – X86_64.

Bem agora que já fizemos toda parte de download do material para montar este ambiente vamos iniciar as instalações.

Primeiramente vamos criar as maquinas para o ambiente do Data Guard, conforme os procedimentos abaixo.

Nesta tela definimos o tipo de SO e a versão do mesmo, vamos utilizar o Oracle Linux 6 Update 5 em 64 Bits e vamos nomear este equipamento de DG1.

Nesta tela vamos definir o tamanho da memória do node neste caso vamos ter 2048 MB.

Nesta tela vamos selecionar a criação do drive que vai receber o sistema operacional do NODE1, selecione a opção “Create a virtual hard drive now”, e depois clique em NEXT.

Nesta tela vamos selecionar o tipo de arquivo do disco virtual no caso vamos utilizar o VDI, depois de selecionar clique em NEXT.

Nesta tela vamos selecionar o tipo de alocação do disco, selecione a opção “Dynamically allocated”, e depois clique em NEXT.

Nesta tela vamos definir o tamanho do disco para instalar o SO e os binários do Oracle Database, estamos usando 20 GB.

Após criamos a máquina vamos agora habilitar 1 placa de redes que ser utilizado na rede do Data Guard.

Para chegar na tela a seguir, selecione a máquina que você criou e clique no botão settings do Virtualbox e depois que abrir a janela selecione a opção Network.

Nesta tela vamos definir na primeira placa de rede que a mesma vai funcionar na rede Host-only do virtualbox.

Depois de selecionar a opção clique no OK e vamos instalar o Sistema Operacional Oracle Linux 6. Para isso clique no item Storage e selecione a mídia do Oracle Linux 6.

Depois de um Start na máquina Virtual DG1 e vamos iniciar a instalação do S.O.

Bem nesta tela selecione a opção “Install or Upgrade an existing system”, e depois de um ENTER.

Nesta tela selecione a opção SKIP, pois não é necessário a validação da mídia, após selecionado de um ENTER.

Continue com a instalação do Oracle Linux como você faria para um servidor normal. Nas próximas três telas selecionar Language, teclado e dispositivos de armazenamento do tipo básico.

Confirmar para descartar quaisquer dados.

Defina “Hostname” para db01dg e pressione “Configure Network”.

Na tela de conexões de rede, selecione “System eth0”, que será usada para a rede pública, e pressione “Edit”

Certifique-se de que “Conectar automaticamente” está marcada. Selecione a aba “Configurações IPv4”; alterar o método para “Manual”;

Pressione o botão “Add” e preencha Endereço: 192.168.56.71; Máscara de rede: 255.255.255.0; Gateway: 0.0.0.0.

Pressione o botão “Apply”.

Fechar tela Conexões de rede e vá para a tela de configuração seguinte.

Selecione o fuso horário.

Digite a senha do Root, coloquei como oracle.

Selecione “Use All Space” para o tipo de preparação do disco e marque a opção “Review and modify partitioning layout”, clique em NEXT.

Clique em NEXT e confirme através de avisos e criar partições.

Manter padrões de tela do carregador de inicialização.

Na tela de instalação do tipo de software, selecione “Database Server” e verifique o botão “Personalizar agora”.

Pressione Next.

Na tela Personalização selecione “Databases” e desmarque todos os itens.

Selecione “Desktops” e marque “Ferramentas gráficas de administração” “Desktop” e em seguida, pressione Next e aguarde até o final da instalação e depois Reinicie o Sistema Operacional.

Quando ele volta, não haverá mais telas de configuração para lidar com óbvias. Não crie conta ‘Oracle’, isso será feito mais tarde. Você pode ignorar as configurações Kdump.

Parabéns! O Linux foi instalado.

Bem após ter instalado o Linux, abra um terminal no Linux para que possamos dar continuidade as atividades.

Instalação do Oracle Database – Pré requisitos.

Bem após ter instalado o Linux, abra um terminal no Linux para que possamos dar continuidade as atividades.

Todas as ações nesta seção devem ser executados pelo usuário root e devem ser executadas nos dois nodes.

Instalar pacote “oracle-rdbms-server-12cR1-preinstall”. Este pacote realiza pré-requisitos do kernel incluindo mudança de parâmetros e criação de conta Oracle Linux.

Execute no terminal o comando abaixo:

yum install oracle-rdbms-server-12cR1-preinstall

Aguarde até o mesmo fazer download da internet deste pacote e realizar a instalação do mesmo.

Vamos agora desabilitar o SELINUX do sistema operacional.

vi /etc/selinux/config

Dentro do arquivo trocar o SELINUX que estiver setado para a opção abaixo.

SELINUX=disabled

Salve o arquivo e saia do mesmo :wq no editor.

Após feito este passo, vamos configurar a parte de network para comunicação das máquinas.

Edite o arquivo hosts localizado no /etc:

vi /etc/hosts

Limpe todas as configurações do arquivo e adicione a seguintes entradas:

192.168.56.71 db01dg db01dg192.168.56.72 db02dg db02dg

Após feito isso salve o arquivo e saia com o comando :wq

Desabilite o Firewall do Linux da seguinte forma:

service iptables stop

service ip6tables stop

chkconfig iptables off

chkconfig ip6tables off

Após feito isso vamos clonar o equipamento para criar o DG2.

Instalando Oracle Database 12C.

Faça o login no “db01dg” como usuário oracle para iniciarmos a instalação do binário do Oracle Database 12c.

$ cd /media/database

$ ./runInstaller

Desmarque a opção “I wish to receive security update via My Oracle Support” e pressione o botão “Next”.

Selecione “Skip software updates”, e clique em “NEXT”.

Selecione a opção “Install database software Only”, e clique em “NEXT”.

Selecione a opção “Single Instance database installation” e clique em “NEXT”.

Na tela de Languages, clique em Next.

Na tela de “Database Edition”, selecione a opção Enterprise Edition e clique em “NEXT”.

Na tela de “Installation Location”, recomendamos seguir a sugestão padrão, caso seja necessário altere o caminho, e após isso clique em “NEXT”.

Mantenha os padrões em “Operating Systems Groups” e pressione “Next”. Ignorar aviso na tela seguinte.

No item Prerequisite Checks, na minha instalação passou sem grandes problemas, caso apresente algo a vocês verifiquem os alertas, solucione os problemas antes da instalação.

Após tudo OK clique em Install.

Após o termino da instalação irá apresentar uma tela para execução de um script que deve ser executado.

Após isso vamos fazer a configuração do bash_profile do usuário oracle no DG1.

Edite o arquivo hosts localizado no /home/oracle/:

vi /home/oracle/.bash_profie

Adicione as seguintes configurações:

# Oracle Settings

export TMP=/tmp

export TMPDIR=$TMP

export ORACLE_HOSTNAME=db01dg

export ORACLE_BASE=/oracle

export ORACLE_HOME=$ORACLE_BASE/12.1.0

export ORACLE_SID=DG1

export ORACLE_TERM=xterm

export PATH=/usr/sbin:$ORACLE_HOME/bin:$PATH

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib

Após feito isso salve o arquivo e saia com o comando :wq

Após a clonagem, teremos os seguintes ambientes para os testes de Data Guard:

TIPO	VM	HOSTNAME	IP	SID
PRIMARY	DG1	DB01DG	192.168.56.71	DG1
STANDBY	DG2	DB02DG	192.168.56.72	DG2ST

Clone equipamento para criação do DG2.

De um shutdown na sua máquina DG1 para que possamos iniciar o clone do ambiente.

No menu do VirtualBox “MACHINE” selecione a opção clone.

Digite “DG2” para o nome da nova máquina.

Certifique-se de que “Reinitialize the MAC address of all network cards” não está marcada. Em seguida, pressione “Next”:

Mantenha a opção “Full Clone” selecionado e pressione “Clone” para iniciar o clone do ambiente.

Após finalizar o clone com a máquina DG1 ainda em shutdown inicie a máquina DG2 e conecte como ROOT.

Após feito isso vamos configurar alguns itens para que não apresente problemas nas máquinas.

Primeiro vamos alterar o hostname do equipamento conforme instrução abaixo:

vi /etc/sysconfig/network

Quando abrir o arquivo altere o item HOSTNAME que esta configurado com o nome do DG2 para o item abaixo

HOSTNAME=db02dg

Após isso precisamos realizar a edição dos ip´s da placa de rede eth0 da máquina clonada.

Clique com o botão direito no ícone que demonstra 2 computadores para habilitar a edição das conexões de rede.

Edite a placa eth0, com o ip conforme imagem.

Após feito o altere o MAC adresses de cada placa estamos trocando somente o final para 00 de todas as placas.

Após isso vamos fazer a configuração do bash_profile do usuário oracle no DG2.

Edite o arquivo hosts localizado no /home/oracle/:

vi /home/oracle/.bash_profie

Adicione as seguintes configurações:

# Oracle Settings

export TMP=/tmp

export TMPDIR=$TMP

export ORACLE_HOSTNAME=db02dg

export ORACLE_BASE=/oracle

export ORACLE_HOME=$ORACLE_BASE/12.1.0

export ORACLE_SID=DG2ST

export ORACLE_TERM=xterm

export PATH=/usr/sbin:$ORACLE_HOME/bin:$PATH

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib

Após feito isso salve o arquivo e saia com o comando :wq

Após feito isso de um shutdown no equipamento e altere o MAC adresses também no VirtualBox.

Após feito isso vamos iniciar a criação dos database.

Criando Database Oracle 12C.

Faça o login no DG1 como usuário oracle para criação do banco de dados.

$ dbca

Neste item selecione a opção “Create Database” e clique em NEXT.

Neste item selecione a opção “Advanced Mode” para que possamos realizar uma instalação customizada e clique em NEXT.

Neste item selecione a “Template General Purpose or Transaction Processing” como modelo de banco de dados e clique em NEXT.

Neste item digite o “Global Database Name” e o “SID” neste caso estamos usando DG1, após feito isso clique em NEXT.

Neste item selecione a opção de “Configure Enterprise Manager(EM) Database Express”, após feito isso clique em NEXT.

Neste item selecione a opção “Use the Same Administrative Password for All Accounts” para que possamos usar uma única senha lembrando que isso é um laboratório e como boas práticas, devemos sempre ter senhas com complexidade e diferentes para todos os usuários. Após feito isso clique em NEXT.

Neste item selecione a opção “Select” depois digite LISTENER e digite 1521 no item “PORT”,após feito isso clique em NEXT.

Neste item selecione a opção “File System” em “Database Files” depois selecione “Use Database File Locations from Template”.

Após feito isso selecione a opção “File System” em “Storage Type do Recovery Related Files” e selecione as opções “Specify Fast Recovery Area” e “Enable Archiving”, após feito isso clique em NEXT.

Neste item não marque nada e clique em NEXT.

Neste item como estamos montando um laboratório, deixe as opções já selecionadas e após feito isso clique em NEXT.

Neste item selecione a opção “Create Dtabase”, após feito isso clique em NEXT.

Neste item será exibido uma resumo do que você configurou, após fazer a analise clique em FINISH.

Aguarde o final da instalação e clique em CLOSE.

Criando e configurando Oracle Data Guard 12C.

Após feito toda parte de infraestrutura, vamos iniciar a criação do Data Guard.

No banco dados primário no DG1, vamos habilitar o archivelog mode.

Para você pode checar o modo de arquivamento do se o seu banco, através da seguinte consulta:

SQL> SELECT LOG_MODE FROM V$DATABASE;

LOG_MODE

————

NOARCHIVELOG

Antes de ativar o arquivamento do banco de dados, vamos certificar o status do nosso listener e do próprio banco de dados.

[oracle@db01dg ~]$ sqlplus / as sysdba

SQL*Plus: Version 12.1.0.1.0 – Production on 25-SEP-2015 14:35:22

SQL> startup

ORACLE instance started.

Total System Global Area 1853947904 bytes

Fixed Size 2229384 bytes

Variable Size 452987768 bytes

Database Buffers 1392508928 bytes

Redo Buffers 6221824 bytes

Database mounted.

Database opened.

SQL>

Com o database primário iniciado, vamos criar o diretório para onde os archives logs gerados pelo banco será salvo.

SQL> !mkdir -p /oracle/arch

Precisamos agora, definir o formato que será gravado o nosso arquivo de log no disco e a sua localização, temos para isso dois parâmetros: o log_archive_format e log_archive_dest_1.

SQL> alter system set log_archive_format=’orcl_%t_%s_%r.arc’ scope=spfile;

System altered.

SQL> alter system set log_archive_dest_1=’LOCATION=/oracle/arch’ scope=spfile;

System altered.

Com todas as configurações feitas, vamos agora ativar o modo de ARCHIVELOG. Para que isso é necessário baixar e subir a instância do banco Oracle.

SQL> shut immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 1853947904 bytes

Fixed Size 2229384 bytes

Variable Size 452987768 bytes

Database Buffers 1392508928 bytes

Redo Buffers 6221824 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 /oracle/arch

Oldest online log sequence 1

Next log sequence to archive 3

Current log sequence 3

Agora precisamos habilitar o modo de FORCE LOGGING no banco de dados Oracle, todas as mudanças que ocorrem no banco de dados são gerados logs, exceto para as tabelas e tablespaces temporários. Isso é fundamental para o Oracle Data Guard, pois assegura que toda transação efetivada (commit) pode ser capturada através dos arquivos de log do Oracle (redo ou archive).

Podemos ativar o modo de FORCE LOGGING da seguinte maneira:

alter database force logging;

select force_logging from v$database;

SQL> select force_logging from v$database;

FOR
—
YES

Agora precisamos criar os arquivos de STANDBY REDO para o ambiente, o Oracle Data Guard pode recuperar e aplicar mais dados do Standby Redo Log do que no convencional Redo Log, por isso a criação de SRL se faz necessária quando estamos montando um Oracle Data Guard.

Com a formula seguinte, é possível determinar o número apropriado dos SRL:

(maximum number of logfiles for each thread + 1) * maximum number of threads

Para o nosso caso: (3 + 1) * 1 = 4

É necessário também que o tamanho do SRL seja exatamente igual ao do Redo Log presente no seu banco, que no nosso ambiente é 100M.

Vamos então adicionar os 4 SRL para o database primário:

alter database add standby logfile group 4 ‘/oracle/oradata/DG1/redo_st04.log’ size 100M;

alter database add standby logfile group 5 ‘/oracle/oradata/DG1/redo_st05.log’ size 100M;

alter database add standby logfile group 6 ‘/oracle/oradata/DG1/redo_st06.log’ size 100M;

alter database add standby logfile group 7 ‘/oracle/oradata/DG1/redo_st07.log’ size 100M;

select group#, sequence#, archived, status from v$standby_log;

Agora vamos configurar os parâmetros de inicialização do ambiente no DG1.

Para uma configuração simples de Oracle Data Guard, basicamente precisamos mudar os 8 parâmetros de inicialização abaixo:
alter system set LOG_ARCHIVE_CONFIG=’DG_CONFIG=(DG1,DG2ST)’;

alter system set LOG_ARCHIVE_DEST_1=’LOCATION=/oracle/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DG1′;

alter system set LOG_ARCHIVE_DEST_2=’SERVICE=DG2ST LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DG2ST’;

alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE;

alter system set FAL_SERVER=DG2ST;

alter system set FAL_CLIENT=DG1;

alter system set DB_FILE_NAME_CONVERT=’/oracle/oradata/DG2ST’,’/oracle/oradata/DG1′ scope=spfile;

alter system set LOG_FILE_NAME_CONVERT=’/oracle/oradata/DG2ST’,’/oracle/oradata/DG1′ scope=spfile;

Segue a explicação de cada um deles:

LOG_ARCHIVE_CONFIG: Habita ou desabilita o comportamento de enviar as mensagens do redo log para o destino. Com a opção DG_CONFIG, podemos definir um range de até 9 destinos, definindo através do DB_UNIQUE_NAME de cada um deles.

LOG_ARCHIVE_DEST_1: Especifica o caminho do primeiro destino de archive do banco de dados. No nosso caso ele será gravado no caminho “/oracle/arch” do servidor do banco primário. A opção VALID_FOR define como será gravado os dados.

LOG_ARCHIVE_DEST_2: Esse parâmetro, defini o segundo destino de archive. Nesse parâmetro que concentra a mágica do Oracle Data Guard, diferente com o que fizemos no primeiro destino (LOG_ARCHIVE_DEST_1), vamos fazer com que o segundo destino de archive do banco primário seja gravado no primeiro destino de archive do banco standby. Veja que é exatamente o que definimos nesse parâmetro, pedidos para o LGWR escrever os dados de log através do serviço chamado “DG2ST” para o banco de dados “DG2ST”.

LOG_ARCHIVE_DEST_STATE_1: Com esse parâmetro, apenas definimos que o primeiro destino de archive está habitado. Por enquanto o segundo destino de archive (LOG_ARCHIVE_DEST_STATE_2) que levará os dados de log para o Data Guard, matemos desativado.

FAL_SERVER e FAL_CLIENT: São parâmetros de inicialização usados para o FAL (fetch archive log), ou seja é utilizado para a detecção e resolução dos destinos do Data Guard. Basicamente, o no banco primário o FAL_SERVER será o TNS service name do banco standby e vice-versa.

DB_FILE_NAME_CONVERT: Ele não é mandatório para o Data Guard, na verdade sua função não é nem para o Data Guard, ele é apenas utilizado no momento do recovery. Esse parâmetro como o nome diz converte o nome do datafile e tempfile do primário database para o correspondente caminho no standby database, é utíl muito útil no momento do recover, pois assim podemos renomear os datafiles facilmente. No nosso caso, vamos converter todos os datafiles que estão no caminho “/oracle/oradata/DG1” no primário database para o novo caminho “/oracle/oradata/DG2ST” no standby database.

LOG_FILE_NAME_CONVERT: O parâmetro LOG_FILE_NAME_CONVERT faz exatamente o que o DB_FILE_NAME_CONVERT faz, porém apenas com redo logs. Agora vamos fazer o backup do banco de dados no DG1. Com todas as configurações feitas, precisamos agora realizar um backup do banco primário. O backup será feito através do RMAN no seguinte caminho: “/oracle/backup/”

Siga os passos abaixo:

[oracle@db01dg ~]$ mkdir -p /oracle/backup/
[oracle@db01dg ~]$ rman target /

Recovery Manager: Release 12.1.0.1.0 – Production on Fri Sep 25 14:59:17 2015

connected to target database: DG1 (DBID=1872722065)

RMAN> run {
2> allocate channel c1 type disk;
3> allocate channel c2 type disk;
4> backup database format ‘/oracle/backup/%d_%s_%p_%U.bkp’;
5> backup archivelog all format ‘/oracle/backup/ARCH_%d_%s_%p_%U.bkp’;
6> backup current controlfile for standby format ‘/oracle/backup/control_%d_%U.bkp’;
7> }

using target database control file instead of recovery catalog
allocated channel: c1
channel c1: SID=47 device type=DISK

allocated channel: c2
channel c2: SID=43 device type=DISK

Starting backup at 25-SEP-15
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00001 name=/oracle/oradata/DG1/system01.dbf
input datafile file number=00006 name=/oracle/oradata/DG1/users01.dbf
channel c1: starting piece 1 at 25-SEP-15
channel c2: starting full datafile backup set
channel c2: specifying datafile(s) in backup set
input datafile file number=00003 name=/oracle/oradata/DG1/sysaux01.dbf
input datafile file number=00004 name=/oracle/oradata/DG1/undotbs01.dbf
channel c2: starting piece 1 at 25-SEP-15
channel c1: finished piece 1 at 25-SEP-15
piece handle=/oracle/backup/DG1_1_1_01qi21dp_1_1.bkp tag=TAG20150925T150321 comment=NONE
channel c1: backup set complete, elapsed time: 00:01:55
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
channel c2: finished piece 1 at 25-SEP-15
piece handle=/oracle/backup/DG1_2_1_02qi21dq_1_1.bkp tag=TAG20150925T150321 comment=NONE
channel c2: backup set complete, elapsed time: 00:01:55
channel c2: starting full datafile backup set
channel c2: specifying datafile(s) in backup set
including current SPFILE in backup set
channel c2: starting piece 1 at 25-SEP-15
including current control file in backup set
channel c1: starting piece 1 at 25-SEP-15
channel c2: finished piece 1 at 25-SEP-15
piece handle=/oracle/backup/DG1_4_1_04qi21hd_1_1.bkp tag=TAG20150925T150321 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:01
channel c1: finished piece 1 at 25-SEP-15
piece handle=/oracle/backup/DG1_3_1_03qi21hd_1_1.bkp tag=TAG20150925T150321 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:01
Finished backup at 25-SEP-15

Starting backup at 25-SEP-15
current log archived
channel c1: starting archived log backup set
channel c1: specifying archived log(s) in backup set
input archived log thread=1 sequence=2 RECID=1 STAMP=891354582
channel c1: starting piece 1 at 25-SEP-15
channel c2: starting archived log backup set
channel c2: specifying archived log(s) in backup set
input archived log thread=1 sequence=3 RECID=2 STAMP=891356064
input archived log thread=1 sequence=4 RECID=3 STAMP=891356721
channel c2: starting piece 1 at 25-SEP-15
channel c1: finished piece 1 at 25-SEP-15
piece handle=/oracle/backup/ARCH_DG1_5_1_05qi21hi_1_1.bkp tag=TAG20150925T150522 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:15
channel c2: finished piece 1 at 25-SEP-15
piece handle=/oracle/backup/ARCH_DG1_6_1_06qi21hi_1_1.bkp tag=TAG20150925T150522 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:15
Finished backup at 25-SEP-15

Starting backup at 25-SEP-15
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
including standby control file in backup set
channel c1: starting piece 1 at 25-SEP-15
channel c1: finished piece 1 at 25-SEP-15
piece handle=/oracle/backup/control_DG1_07qi21i2_1_1.bkp tag=TAG20150925T150538 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:01
Finished backup at 25-SEP-15
released channel: c1
released channel: c2

RMAN>

Agora devemos criar uma cópia do arquivo de inicialização do nosso banco primário, a cópia deve ser feita no mesmo caminho do backup que acabamos de fazer, isso porque iremos mover toda essa pasta para o servidor do banco DG2.

[oracle@db01dg ~]$ sqlplus / as sysdba

SQL*Plus: Version 12.1.0.1.0 – Production on 25-SEP-2015 14:35:22

SQL> create pfile=’/oracle/backup/initDG2.ora’ from spfile;

File created.

Agora devemos realizar a cópia do arquivo de senha para o servidor DG2.

cd $ORACLE_HOME/dbs
[oracle@db01dg ~]$ scp orapwDG1 db02dg:/oracle/12.1.0/dbs/orapwDG2
oracle@db02dg password: ******* orapwDG1 100% 96KB 96.0KB/s 00:00

O Oracle Data Guard é totalmente configurado para ser executado em cima do Oracle NET. Toda sua comunicação com os bancos de DG1 e DG2 é feito através do serviços configurados no TNS. No nosso caso, assim como foi configurado os parâmetros acima, precisamos ter os serviços “DG1” e “DG2” em ambas as máquinas.

[oracle@db01dg ~] cd $ORACLE_HOME/network/admin
[oracle@db01dg admin]$ vi tnsnames.ora

Inclua estas entradas no arquivo do TNSNAMES
DG1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = db01dg)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DG1)
)
)
DG2ST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = db02dg)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DG2ST)
)
)

Após feito isso salve o arquivo e saia com o comando :wq

Agora vamos realizar um teste de conectividade.

[oracle@db01dg admin]$ tnsping DG1

TNS Ping Utility for Linux: Version 12.1.0.1.0 – Production on 25-SEP-2015 14:33:22

Used parameter files:

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = db01dg)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DG1)))

[oracle@db01dg admin]$ tnsping DG2ST

TNS Ping Utility for Linux: Version 12.1.0.1.0 – Production on 25-SEP-2015 14:33:29

Used parameter files:

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = db02dg)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DG2ST)))

Lembrando que na máquina DG2 o serviço do LISTENER deve estar iniciado.

Agora temos agora o nosso banco primário DG1 todo configurado e pronto para iniciar o standby, precisamos apenas mover o backup e o arquivo de inicialização que estão no nosso servidor primário para o banco standby DG2.

[oracle@db01dg admin]$ cd /oracle/backup

[oracle@db01dg backup]$ ls -ltr
total 1383856
-rw-r—–. 1 oracle oinstall 607723520 Sep 25 15:05 DG1_2_1_02qi21dq_1_1.bkp
-rw-r—–. 1 oracle oinstall 685727744 Sep 25 15:05 DG1_1_1_01qi21dp_1_1.bkp
-rw-r—–. 1 oracle oinstall 98304 Sep 25 15:05 DG1_4_1_04qi21hd_1_1.bkp
-rw-r—–. 1 oracle oinstall 10092544 Sep 25 15:05 DG1_3_1_03qi21hd_1_1.bkp
-rw-r—–. 1 oracle oinstall 51418112 Sep 25 15:05 ARCH_DG1_6_1_06qi21hi_1_1.bkp
-rw-r—–. 1 oracle oinstall 51900416 Sep 25 15:05 ARCH_DG1_5_1_05qi21hi_1_1.bkp
-rw-r—–. 1 oracle oinstall 10092544 Sep 25 15:05 control_DG1_07qi21i2_1_1.bkp
-rw-r–r–. 1 oracle oinstall 1379 Sep 25 15:11 initDG2ST.ora
[oracle@db01dg backup]$

Para que a restauração seja mais fácil, sem a necessidade de catalogar os backup, vamos criar o mesmo diretório no servidor DG2.

[oracle@db01dg backup]$ ssh oracle@db02dg mkdir -p /oracle/backup
oracle@db02dg’s password: *****

Com o diretório criado, vamos mover todos os arquivos da pasta /oracle/backup/ para o servidor DG2.

[oracle@db01dg backup]$ scp * db02dg:`pwd`
oracle@db02dg’s password: *******
ARCH_DG1_5_1_05qi21hi_1_1.bkp 100% 49MB 49.5MB/s 00:00
ARCH_DG1_6_1_06qi21hi_1_1.bkp 100% 49MB 49.0MB/s 00:01
control_DG1_07qi21i2_1_1.bkp 100% 9856KB 9.6MB/s 00:00
DG1_1_1_01qi21dp_1_1.bkp 100% 654MB 19.2MB/s 00:34
DG1_2_1_02qi21dq_1_1.bkp 100% 580MB 17.1MB/s 00:34
DG1_3_1_03qi21hd_1_1.bkp 100% 9856KB 9.6MB/s 00:01
DG1_4_1_04qi21hd_1_1.bkp 100% 96KB 96.0KB/s 00:00
initDG2ST.ora 100% 1379 1.4KB/s 00:00
[oracle@db01dg backup]$

Agora que finalizamos toda configuração no DG1 vamos fazer a configuração do DG2 – Standby.

Vamos editar o arquivo initDG2.ora para acrescentarmos alguns parâmetros necessários do Oracle Data Guard.

Para isso, conecte na máquina de standby DG2 e faça as alterações como abaixo, observe que os parâmetros em negrito, são os parâmetros necessários para o Data Guard.

[oracle@db02dg~] $ cd /oracle/backup
[oracle@db02dg backup]$ ls -ltr
total 1383856
-rw-r—–. 1 oracle oinstall 607723520 Sep 25 15:05 DG1_2_1_02qi21dq_1_1.bkp
-rw-r—–. 1 oracle oinstall 685727744 Sep 25 15:05 DG1_1_1_01qi21dp_1_1.bkp
-rw-r—–. 1 oracle oinstall 98304 Sep 25 15:05 DG1_4_1_04qi21hd_1_1.bkp
-rw-r—–. 1 oracle oinstall 10092544 Sep 25 15:05 DG1_3_1_03qi21hd_1_1.bkp
-rw-r—–. 1 oracle oinstall 51418112 Sep 25 15:05 ARCH_DG1_6_1_06qi21hi_1_1.bkp
-rw-r—–. 1 oracle oinstall 51900416 Sep 25 15:05 ARCH_DG1_5_1_05qi21hi_1_1.bkp
-rw-r—–. 1 oracle oinstall 10092544 Sep 25 15:05 control_DG1_07qi21i2_1_1.bkp
-rw-r–r–. 1 oracle oinstall 1379 Sep 25 15:11 initDG2ST.ora

[oracle@db01dg backup]$ vi initstdby.ora

*.audit_file_dest=’/oracle/admin/DG2ST/adump’
*.compatible=’12.1.0.0.0′
*.control_files=’/oracle/oradata/DG2ST/control01.ctl’,’/oracle/oradata/DG2ST/control02.ctl’
*.db_block_size=8192
*.diagnostic_dest=’/oracle’
*.log_archive_format=’orcl_%t_%s_%r.arc’
*.open_cursors=300
*.pga_aggregate_target=616562688
*.sga_target=1849688064
*.undo_tablespace=’UNDOTBS1′
*.db_name=DG1
*.db_unique_name=DG2ST
*.db_file_name_convert=’/oracle/oradata/DG1′,’/oracle/oradata/DG2ST’
*.log_file_name_convert=’/oracle/oradata/DG1′,’/oracle/oradata/DG2ST’
*.log_archive_config=’DG_CONFIG=(DG1,DG2ST)’
*.log_archive_dest_1=’LOCATION=/oracle/archive/DG2ST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DG2ST’
*.log_archive_dest_2=’SERVICE=DG1 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DG1′
*.log_archive_dest_state_1=’ENABLE’
*.fal_client=’DG2ST’
*.fal_server=’DG1′
*.remote_login_passwordfile=’EXCLUSIVE’
*.standby_file_management=auto

Assim como fizemos na máquina DG1 (servidor primário), temos que configurar da mesma maneira no servidor DG2 o TNSNAMES.

[oracle@db02dg ~] cd $ORACLE_HOME/network/admin
[oracle@db02dg admin]$ vi tnsnames.ora

Inclua estas entradas no arquivo do TNSNAMES

DG1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = db01dg)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DG1)
)
)
DG2ST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = db02dg)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DG2ST)
)
)

Após feito isso salve o arquivo e saia com o comando :wq

Agora vamos realizar um teste de conectividade.

[oracle@db02dg admin]$ tnsping DG1

TNS Ping Utility for Linux: Version 12.1.0.1.0 – Production on 25-SEP-2015 14:33:22

Used parameter files:

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = db01dg)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DG1)))

[oracle@db02dg admin]$ tnsping DG2ST

TNS Ping Utility for Linux: Version 12.1.0.1.0 – Production on 25-SEP-2015 14:33:29

Used parameter files:

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = db02dg)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DG2ST)))

Lembrando que na máquina DG2 o serviço do LISTENER deve estar iniciado.

Agora para Para iniciar a instância DG2ST, precisamos dos seguintes diretórios criados:

[oracle@db02dg ~]$ mkdir -p /oracle/admin/DG2ST/adump

[oracle@db02dg ~]$ mkdir -p /oracle/oradata/DG2ST

[oracle@dg02dg ~]$ mkdir -p /oracle/arch

Agora os passos necessários para iniciar a instância DG2ST em estado nomount. Primeiro, vamos criar o spfile através do arquivo pfile “/oracle/backup/initDG2ST.ora”.

[oracle@dg02dg ~]$ echo $ORACLE_SID
D2GST

[oracle@dg02dg ~]$ sqlplus / as sysdba

SQL*Plus: Version 12.1.0.1.0 – Production on 25-SEP-2015 14:35:22

SQL> create spfile from pfile=’/oracle/backup/initDG2ST.ora’;

File created.

SQL> startup nomount
ORACLE instance started.

Total System Global Area 1853947904 bytes
Fixed Size 2229384 bytes
Variable Size 452987768 bytes
Database Buffers 1392508928 bytes
Redo Buffers 6221824 bytes

Com todas as configurações acima realizadas, vamos agora a restauração do banco DG1 para o standby DG2ST. A restauração será feita através do comando duplicate do RMAN, para isso precisamos estar conectados em ambos os bancos de dados (DG1 e DG2ST), isso é feito da seguinte maneira:

$ rman target sys/oracle@DG1 auxiliary /

Onde:

target -> Representa o nosso banco de dados destino, que no caso é o banco DG1 (database primário). A conexão será feita com o usuário com o usuário sys e senha oracle através do TNSNAME DG1.

auxiliary -> Representa o banco na máquina que estamos conectado, que no caso é a instância DG2ST, definido pela variável de ambiente ORACLE_SID. A conexão será feita pelo sistema operacional “/”.

Recovery Manager: Release 12.1.0.1.0 – Production on Fri Sep 25 14:59:17 2015

connected to target database: DG1 (DBID=1872722065)
connected to auxiliary database: DG2ST (not mounted)

RMAN> duplicate target database for standby;

Starting Duplicate Db at 25-SEP-15
using target database control file instead of recovery catalog
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=111 device type=DISK

contents of Memory Script:
{
restore clone standby controlfile;
}
executing Memory Script

Starting restore at at 25-SEP-15
using channel ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: reading from backup piece /oracle/backup/control_DG1_07o6ou86_1_1.bkp
channel ORA_AUX_DISK_1: piece handle=/oracle/backup/control_DG1_07o6ou86_1_1.bkp tag=TAG20130410T225358
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/oracle/oradata/DG2ST/control01.ctl
output file name=/oracle/oradata/DG2ST/control02.ctl
Finished restore at at 25-SEP-15

contents of Memory Script:
{
sql clone ‘alter database mount standby database’;
}
executing Memory Script

sql statement: alter database mount standby database

contents of Memory Script:
{
set newname for tempfile 1 to
“/oracle/oradata/DG2ST /temp01.dbf”;
switch clone tempfile all;
set newname for datafile 1 to
“/oracle/oradata/DG2ST /system01.dbf”;
set newname for datafile 2 to
“/oracle/oradata/DG2ST/sysaux01.dbf”;
set newname for datafile 3 to
“/oracle/oradata/DG2ST/undotbs01.dbf”;
set newname for datafile 4 to
“/oracle/oradata/DG2ST/users01.dbf”;
set newname for datafile 5 to
“/oracle/oradata/DG2ST/example01.dbf”;
restore
clone database
;
}
executing Memory Script

executing command: SET NEWNAME

renamed tempfile 1 to /oracle/oradata/DG2ST/temp01.dbf in control file

executing command: SET NEWNAME

Starting restore at 25-SEP-15
using channel ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00002 to /oracle/oradata/DG2ST/sysaux01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00003 to /oracle/oradata/DG2ST/undotbs01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00004 to /oracle/oradata/DG2ST/users01.dbf
channel ORA_AUX_DISK_1: reading from backup piece /oracle/backup/DG_1_2_1_02o6ou56_1_1.bkp
channel ORA_AUX_DISK_1: piece handle=/oracle/backup/DG1_2_1_02o6ou56_1_1.bkp tag=TAG20130410T225222
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:25
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /oracle/oradata/DG2ST/system01.dbf
channel ORA_AUX_DISK_1: restoring datafile 00005 to /oracle/oradata/DG2ST/example01.dbf
channel ORA_AUX_DISK_1: reading from backup piece /oracle/backup/DG1_1_1_01o6ou56_1_1.bkp
channel ORA_AUX_DISK_1: piece handle=/oracle/backup/DG1_1_1_01o6ou56_1_1.bkp tag=TAG20130410T225222
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:55
Finished restore at 25-SEP-15

contents of Memory Script:
{
switch clone datafile all;
}
executing Memory Script

datafile 1 switched to datafile copy
input datafile copy RECID=2 STAMP=812419999 file name=/oracle/oradata/DG2ST/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=3 STAMP=812419999 file name=/oracle/oradata/DG2ST/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=4 STAMP=812419999 file name=/oracle/oradata/DG2ST/undotbs01.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=5 STAMP=812419999 file name=/oracle/oradata/DG2ST/users01.dbf
datafile 5 switched to datafile copy
input datafile copy RECID=6 STAMP=812419999 file name=/oracle/oradata/DG2ST/example01.dbf
Finished Duplicate Db at 25-SEP-15

RMAN>

Restore finalizado com sucesso.

Vamos realmente conferir se o banco DG2ST restaurado está no modo STANDBY:

SQL> select name, db_unique_name, database_role from v$database;

NAME DB_UNIQUE_NAME DATABASE_ROLE
——— —————————— —————-
DG1 DG2ST PHYSICAL STANDBY

Show, nosso banco DG2ST está definido como PHYSICAL STANDBY.

Agora com a restauração completa do banco de dados DG2ST, temos agora que informar ao database primário (DG1) para começar a enviar os logs das alterações feitas para o banco DG2ST.

Isso é feito conforme o parâmetro log_archive_dest_state_2.

Agora, através desse segundo destino de archive habilitado, todas as alterações feitas no DG1 será automaticamente enviada para o banco DG2ST (database standby).

Com os logs sendo encaminhado no banco DG2ST, vamos informar ao Oracle Data Guard para que o banco DG2ST comece a trabalhar com esses logs que estão sendo encaminhado do banco DG1.

Ao executar os comandos abaixo, estamos solicitando para que o Data Guard inicie os processos background para que automaticamente sejam restaurados os logs.

SQL> show parameter instance_name

NAME TYPE VALUE
———————————— ———– ——————————
instance_name string stdby

SQL> alter database recover managed standby database disconnect;

Database altered.

SQL>

Agora que fizemos isso, temos o nosso Data Guard pronto e habilitado.

Agora para finalizar vamos verificar o sincronismo do Data Guard está funcionando. Para isso, temos que checar se o destino de log 1 está na mesma sequência do destino de log 2, ou seja, cada sequência gerada no destino 1 (destino do banco DG1l) deverá gerar a mesma sequência no destino 2 (destino do banco DG2ST), garantindo assim que ambas estão sincronizadas.

Essa forma de monitorar, funciona apenas para o tipo do Data Guard que estamos criando, o tipo ASYNC. Existe a forma SYNC, que muda a forma de como monitorar também, mais isso fica para um próximo artigo, por enquanto basta saber que o Data Guard ASYNC deve gerar a mesma sequência no destino 1 como no destino 2.

Vamos verificar através da view v$archived_log, conforme query abaixo:

Deve ser rodado está query no DG1.

Observe que a partir da sequência 5, o Oracle está gerando a mesma sequência tanto no destino 1 como no destino 2. Isso se repete até o sequência 12, que é a última sequência gerada para o banco DG1.

Para validar a sincronização, podemos forçar a geração de uma nova sequência, execute o comando abaixo.

SQL> alter system switch logfile;

Agora após feito isso, checamos novamente com a consulta acima, para verificar se a sequência 13 foi gerada no destino 1 e destino 2.

Olhe e veja a sequência 13 foi gerada em ambos os destino.

Agora repita o comando do switch do redo e veja como ficou a sequência 14:

Uma outra de analisar e verificar a sincronia do seu Data Guard é através do arquivo de log do seu banco de dados, veja no banco DG1 a seguinte mensagem:

LNS: Standby redo logfile selected for thread 1 sequence 14 for destination LOG_ARCHIVE_DEST_2

Isso confirma que o processo LNS do banco DG1, capturou a sequência 14 da tread 1 e enviou para o destino LOG_ARCHIVE_DEST_2.

De um more no alert.log, para verificar a transação.

Thu Sep 25 00:17:30 2015
Thread 1 advanced to log sequence 14 (LGWR switch)
Current log# 2 seq# 14 mem# 0: /oracle/oradata/DG1/redo02.log
Thu Sep 25 00:17:30 2015
Archived Log entry 20 added for thread 1 sequence 13 ID 0x4f860f89 dest 1:
Thu Sep 25 00:17:30 2015
LNS: Standby redo logfile selected for thread 1 sequence 14 for destination LOG_ARCHIVE_DEST_2

Com o envio da sequência 14, confirmada pelo alert.log do banco DG1, temos no alert.log do DG2ST que o processo RFS capturou a sequência 14 aplicou com sucesso no banco DG2ST.

Thu Sep 25 00:17:58 2015
RFS[4]: Selected log 5 for thread 1 sequence 14 dbid 1334188681 branch 806407947
Thu Sep 25 00:17:58 2015
Archived Log entry 9 added for thread 1 sequence 14 ID 0x4f860f89 dest 1:
Thu Sep 25 00:17:58 2015
Media Recovery Log /oracle/arch/DG1_1_14_806407947.arc
Media Recovery Waiting for thread 1 sequence 15

Conclusões

Bem amigos vimos a criação de um laboratório para Oracle Data Guard 12c, está é uma das formas de trabalhar com o Data Guard, se vocês quiserem apreender mais recomendo estudar as outras formas de configurar o Data Guard, como por exemplo a SYNC, Snapshot Data Guard e Active Data Guard.

É muito importante também aprender os outros tipos de proteção (Maximum Availability. Maximum Performance e Maximum Protection) entender o que o Redo Transport Services pode ajudar na melhoria do seu Data Guard, assim como aprender a administrar melhor o seu Data Guard.

Até a próxima!

André

BLOG DBADUTRA

Dataguard – Blog DBA Dutra

Refresh database from Data Guard

1 Pre-Requirements

2 Preparation

Standby preparation

3 Clone PDBs

4 Finalize the refresh

Usando a feature recover standby database from service Dataguard no 19c

Configure Data Guard Physical Setup usando Data Broker no Oracle Database 19c / Data Guard Physical Setup using Data Broker in Oracle Database 19c

Hope this helps !!!

Soon we will have more articles on the Oracle 19c.

Instalando Oracle Data Guard 12c