GUIA PARA CONFIGURANDO E UTILIZAÇÃO DO ORACLE DATA GUARD
Procedimento que se destina a descrever os passos necessários para a preparação do ambiente de banco de dados e para a configuração do Oracle Data Guard.
SUMÁRIO
- 01. DETALHAMENTO DO AMBIENTE DE ORIGEM E DESTINO
- 02. CONFIGURAÇÃO DE SISTEMA OPERACIONAL REDE (SERVIDOR / OUVINTE / TNSNAMES)
- 03. ALTERANDO AS CONFIGURAÇÕES DO BANCO DE DADOS PRIMÁRIO
- 04. CRIAÇÃO DOS STANDBY REDO LOG FILES NO BANCO DE DADOS PRIMÁRIO
- 05. CRIAÇÃO DE ARQUIVOS (ORAPW E PFILE)
- 06. CRIAÇÃO DO SERVIDOR STANDBY BASEADO NO PRIMÁRIO
- 07. CRIAÇÃO DO BANCO DE DADOS SECUNDÁRIO USANDO DUPLICATE
- 08. AJUSTES FINAIS NO BANCO DE DADOS SECUNDÁRIO E VERIFICAÇÕES
- 09. MODOS DE PROTEÇÃO
- 10. BANCO DE DADOS SECUNDÁRIO EM MODO SOMENTE DE LEITURA E ACTIVE DATA GUARD
- 11. CHAVEAMENTO: INVERSÃO DO PAPEL ENTRE OS BANCOS DE DADOS PRIMÁRIO E STANDBY
- 12. CHAVEAMENTO EM CASO DE FALHA (FAILOVER)
- 13. RECUPERAÇÃO DE UM DESASTRE ATRAVÉS DO RECURSO DE FLASHBACK
- 14. RECUPERAÇÃO DE UM DESASTRE ATRAVÉS DA FERRAMENTA RMAN
CONFIGURAÇÃO DO ORACLE DATA GUARD (PHYSICAL STANDBY)
01. DETALHAMENTO DO AMBIENTE DE ORIGEM E DESTINO
=====================================================================
Environment | PRIMARY | STANDBY |
=====================================================================|
DB NAME | PROD | PROD |
DB UNIQUE NAME | PROD | PRODS |
IP | 192.168.1.1 | 192.168.1.2 |
DB VERSION | 19.3 | 19.3 |
OS VERSION | ORACLE LINUX 8.8 | ORACLE LINUX 8.8 |
===================================================================== DB_NAME: O mesmo para todas as base de dados: primario e STANDBY
DB_UNIQUE_NAME: Identificador Unico da bases
02. CONFIGURAÇÃO DE SISTEMA OPERACIONAL REDE (SERVIDOR / OUVINTE / TNSNAMES)
Verifique o IP do servidor através do seguinte comando:
Verifique o nome do servidor através do seguinte comando:hostname, ip addr
| PRIMARY | STANDBY |
|---|---|
|
|
2.1 – Adicionando a entrada de Rede: HOSTS (ambos os servidores):
| PRIMARY | STANDBY |
|---|---|
vi /etc/hosts
|
vi /etc/hosts
|
2.2 – Adicionando a entrada de Rede: LISTENER (ambos os servidores):
| PRIMARY | STANDBY |
|---|---|
vi $ORACLE_HOME/network/admin/listener.ora
|
vi $ORACLE_HOME/network/admin/listener.ora
|
2.3 – Adicionando a entrada de Rede: TNSNAMES (ambos os servidores):
| PRIMARY | STANDBY |
|---|---|
vi $ORACLE_HOME/network/admin/tnsnames.ora
|
vi $ORACLE_HOME/network/admin/tnsnames.ora
|
2.4 – Verificando e Testando a conectividade:
Após as alterações, será necessário reiniciar os serviços tanto no Primário quanto no Standby:
| PRIMARY | STANDBY |
|---|---|
|
|
tnsping DG_PROD
TNS Ping Utility for Linux: Version 19.0.0.0.0 - PRODuction on 22-SEP-2023 14:38:04
Copyright (c) 1997, 2019, Oracle. All rights reserved.
Used parameter files: /u01/app/oracle/PRODuct/19.3.0/dbhome_1/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.1)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = DG_PROD)))
OK (0 msec) 03. ALTERANDO AS CONFIGURAÇÕES DO BANCO DE DADOS PRIMÁRIO
3.1 – Verificando as configurações Atuais:
SELECT name,DB_UNIQUE_NAME,open_mode,log_mode,force_logging,flashback_on,database_role FROM V$DATABASE;
NAME DB_UNIQUE_NAME OPEN_MODE LOG_MODE FORCE_LOGGING FLASHBACK_ON DATABASE_ROLE
__________ _________________ _____________ _____________ ________________ _______________ ________________
PROD PROD READ WRITE NOARCHIVELOG NO NO PRIMARY 3.2 – Verificando o Log Mode
Precisa estar em modo de ARCHIVELOG.
Caso contrário (NOARCHIVELOG), execute o procedimento abaixo:
SELECT LOG_MODE FROM V$DATABASE;
LOG_MODE
_____________
ARCHIVELOG Se nao estiver em modo ARCHIVE execute no sqlplus:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN; Verifica se esta como FORCE LOGGING
SELECT FORCE_LOGGING FROM V$DATABASE;
FORCE_LOGGING
---------------------------------------
NO ALTER DATABASE FORCE LOGGING;
-- Outras opcoes:
ALTER DATABASE SET STANDBY NOLOGGING FOR LOAD PERFORMANCE;
ALTER DATABASE SET STANDBY NOLOGGING FOR DATA AVAILABILITY;
SELECT FORCE_LOGGING FROM V$DATABASE;
FORCE_LOGGING
---------------------------------------
YES 3.3 – Habilitando o recurso de FLASHBACK
SELECT flashback_on FROM V$DATABASE;
FLASHBACK_ON
------------------
NO
ALTER DATABASE FLASHBACK ON;
SELECT FLASHBACK_ON FROM V$DATABASE;
FLASHBACK_ON
------------------
YES 3.5 – Resultado as execuções acima:
SELECT name,db_unique_name,open_mode,log_mode,force_logging,flashback_on,database_role FROM V$DATABASE;
NAME DB_UNIQUE_NAME OPEN_MODE LOG_MODE FORCE_LOGGING FLASHBACK_ON DATABASE_ROLE
_______ _________________ _____________ _____________ ________________ _______________ ________________
PROD PROD READ WRITE ARCHIVELOG YES YES PRIMARY 3.6 – Parâmetros de configuração do Servidor Primário:
--PRIMARY:
ALTER SYSTEM SET DB_UNIQUE_NAME='PROD' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,PRODS)' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/oraarch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PROD' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1='ENABLE' SCOPE=BOTH ;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=DG_PRODS ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODS' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3='ENABLE' SCOPE=BOTH ;
ALTER SYSTEM SET FAL_SERVER='DG_PRODS' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30;
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;
ALTER SYSTEM SET DB_ULTRA_SAFE=DATA_AND_INDEX SCOPE=SPFILE;
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='PRODS','PROD','PRODS','PROD' SCOPE=SPFILE;
ALTER SYSTEM SET DB_FILE_NAME_CONVERT='PRODS','PROD','PRODS','PROD' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_FORMAT = 'PROD_%T_%S_%R.ARC' SCOPE=SPFILE;
--ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='AUTO' SCOPE=BOTH; ===> será executado após o DUPLICATE
3.7 – Adicionando standby logfiles no Servidor Primário
A contagem do grupo de arquivo de log em espera é sempre grupo de arquivo de log online +1
O tamanho do arquivo de log em espera deve ser o mesmo que o arquivo de log online
Use a consulta abaixo para encontrar os detalhes do logfile online.
PRIMARY:
--PRIMARY:
SELECT GROUP#,BYTES/1024/1024 "Online Loggroup Size in MB" FROM V$LOG;
GROUP# Online Loggroup Size in MB
_________ _____________________________
4 3072
5 3072
6 3072
7 3072
8 3072 A consulta retornou 5 grupos de log on-line com 3 GB de tamanho, deve-se adicionar 6 grupos de arquivos de log em espera a cada 3 GB.
Assim, o número de redo logs de espera necessários é: (5+1)*1=6.
(maximum number of logfiles for each thread + 1) * maximum number of threads
Mais informação em:
https://docs.oracle.com/cd/B19306_01/server.102/b14239/create_ps.htm#i69583
-- Verificar os grupos e arquivo de REDO ---
---- Verificar os grupos e arquivo de REDO ---
SELECT * FROM V$LOG;
SELECT GROUP#,THREAD#,MEMBERS,BYTES FROM V$LOG;
SELECT GROUP#, BYTES/1024/1024 MB FROM V$LOG;
SELECT * FROM V$LOGFILE ORDER BY GROUP#;
SELECT GROUP#,MEMBER FROM V$LOGFILE;
SELECT GROUP#,MEMBER,TYPE FROM V$LOGFILE WHERE TYPE='STANDBY' ORDER BY 1,2;
SELECT TYPE, COUNT(*) FROM V$LOGFILE GROUP BY TYPE;
SELECT * FROM V$STANDBY_LOG;
SELECT GROUP#, BYTES FROM V$STANDBY_LOG;
SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
SELECT A.GROUP#, A.MEMBER, B.BYTES FROM V$LOGFILE A, V$STANDBY_LOG B WHERE A.GROUP# = B.GROUP#;
SELECT THREAD#, INSTANCE FROM V$THREAD ; 04. CRIAÇÃO DOS STANDBY REDO LOG FILES NO BANCO DE DADOS PRIMÁRIO
--PRIMÁRIO
ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 ('/u01/oradata/PROD/PROD/redos1.log') SIZE 3072m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 ('/u01/oradata/PROD/PROD/redos2.log') SIZE 3072m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 ('/u01/oradata/PROD/PROD/redos3.log') SIZE 3072m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 14 ('/u01/oradata/PROD/PROD/redos4.log') SIZE 3072m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 15 ('/u01/oradata/PROD/PROD/redos5.log') SIZE 3072m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 16 ('/u01/oradata/PROD/PROD/redos6.log') SIZE 3072m;
05. CRIAÇÃO DE ARQUIVOS (ORAPW E PFILE)
Gerar os arquivos controlfile e parameter file (pfile), no ambiente do banco de dados primário, para posteriormente efetuar a cópia desses arquivos para o ambiente do banco de dados secundário:
5.1 – Geração dos arquivos de controle
--PRIMARY
cd /oratmp
sqlplus / as sysdba
CREATE PFILE='/oratmp/initPRODS.ora' FROM SPFILE;
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/oratmp/control01.ctl';
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/oratmp/control02.ctl';5.2 – Reiniciar para que os parâmetros estáticos passem a ter efeito:
STARTUP FORCE
exit;5.3 – Após a criação, enviar os arquivos para o standby :
--PRIMARY
scp $ORACLE_HOME/dbs/orapwPROD oracle@192.168.1.2:$ORACLE_HOME/dbs
scp /oratmp/initPRODS.ora oracle@192.168.1.2:$ORACLE_HOME/dbs
scp /oratmp/control01.ctl oracle@192.168.1.2:/u01/oradata/PROD/PROD/control01.ctl
scp /oratmp/control02.ctl oracle@192.168.1.2:/u01/app/oracle/fast_recovery_area/PROD/control02 06. CRIAÇÃO DO SERVIDOR STANDBY BASEADO NO PRIMÁRIO
6.1 – Baseado no servidor Primário, crie os diretórios no Standby.
--STANDBY
mkdir -pv /u01/app/oracle/admin/PROD/adump Para gerar arquivo com a lista de diretórios dirs01/ dirs02
find . -type d > dirs01.txt
xargs mkdir -p < dirs01.txt 6.2 – Carregando a Base Standby baseado no arquivo de parâmetro do Primário:
--STANDBY
sqlplus
STARTUP NOMOUNT PFILE='/u01/app/oracle/PRODuct/19.3.0/dbhome_1/dbs/initPRODS.ora';
CREATE SPFILE FROM PFILE='/u01/app/oracle/PRODuct/19.3.0/dbhome_1/dbs/initPRODS.ora';
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;6.2 – Parâmetros de configuração do Servidor Standby:
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST ='/storage/21S/flashback' SCOPE=SPFILE;
ALTER SYSTEM SET DB_UNIQUE_NAME='PRODS' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='PROD','PRODS','PROD','PRODS' SCOPE=SPFILE;
ALTER SYSTEM SET DB_FILE_NAME_CONVERT ='PROD','PRODS','PROD','PRODS' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,PRODS)' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/oraarch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRODS' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1='ENABLE' SCOPE=BOTH ;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=DG_PROD ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD' SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3='ENABLE' SCOPE=BOTH ;
ALTER SYSTEM SET FAL_SERVER='DG_PROD' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30;
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_FORMAT = 'PROD_%T_%S_%R.ARC' SCOPE = SPFILE;
ALTER SYSTEM SET DB_ULTRA_SAFE=DATA_AND_INDEX SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP NOMOUNT;Procedimento Alternativo / Ajuste Manualmente para as seguintes informações
--STANDBY
vi /u01/app/oracle/PRODuct/19.3.0/dbhome_1/dbs/initPRODS.ora *.db_file_name_convert='PROD','PRODS','PROD','PRODS'
*.db_name='PROD'
*.db_recovery_file_dest='/storage/21S/flashback'
*.db_unique_name='PRODS'
*.fal_server='DG_PROD'
*.log_archive_config='DG_CONFIG=(PROD,PRODS)'
*.log_archive_dest_1='LOCATION=/oraarch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRODS'
*.log_archive_dest_2='location=USE_DB_RECOVERY_FILE_DEST'
*.log_archive_dest_3='SERVICE=DG_PROD ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PROD'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_3='ENABLE'
*.log_file_name_convert='PROD','PRODS','PROD','PRODS'07. CRIAÇÃO DO BANCO DE DADOS SECUNDÁRIO USANDO DUPLICATE
7.0 – Ajustar os seguintes parâmetros no RMAN
show all;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/storage/.../backupset/%F';
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/.../snapcf_PROD.f'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 8 BACKUP TYPE TO COMPRESSED BACKUPSET;7.1 – Inicie a conexão com o RMAN no ambiente do banco de dados primário executando o comando abaixo, especificando uma string de conexão completa passando a senha do usuário SYS (sendo a mesma nos dois ambientes, visto que o arquivo de senha foi copiado do ambiente do banco de dados primário para o ambiente do banco de dados secundário), para as duas instâncias primária (TARGET) e secundária (AUXILIARY). Não tente usar autenticação por usuário de sistema operacional:
rman TARGET sys/senha@DG_PROD AUXILIARY sys/senha@DG_PRODS Se a conexão for bem sucedida, será exibida uma informação similar à seguinte:
connected to target database: PROD (DBID=1234567890)
connected to auxiliary database: PROD (not mounted)
Observe que a conexão com o banco de dados secundário deverá estar no modo não montado. Caso contrário será exibida a seguinte informação:
connected to target database: PROD (DBID=1234567890)
connected to auxiliary database (not started)
Neste caso, faça as seguintes verificações e ajustes necessários para que se possibilite a conexão adequada com o banco de dados secundário em modo (not mounted):
- verificar se o listener está ok nos dois ambientes;
- verificar se estão corretas as informações contidas nos arquivos tnsnames.ora e listener.ora, nos dois ambientes;
- verificar se o parâmetro ORACLE_HOME do arquivo listener.ora está correto, uma barra no final pode ser a causa de problema;
- ajustar em cada conexão do arquivo tnsnames.ora, tentar alterar na seção CONNECT_DATA, alternar entre os parâmetros SID e SERVICE_NAME.
7.2 – Agora execute o comando que iniciará o processo de duplicação do banco de dados primário para o banco de dados secundário, com o seguinte comando:
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK DORECOVER;7.3 – Garantirá que todas as modificações dos arquivos de dados no banco de dados primário serão refletidas no site de espera.
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT='AUTO' SCOPE=BOTH;08. AJUSTES FINAIS NO BANCO DE DADOS SECUNDÁRIO E VERIFICAÇÕES
8.1 – Se o comando DUPLICATE foi executado com sucesso, saia do RMAN e entre no sqlplus e faça as seguintes verificações:
-- PRIMARY
SELECT name,database_role,controlfile_type,open_mode FROM V$DATABASE;
NAME DATABASE_ROLE CONTROLFILE_TYPE OPEN_MODE
------------- ---------------- ------------------ ----------
ORCL PRIMARY CURRENT READ WRITE-- STANDBY
SELECT name,database_role,controlfile_type,open_mode FROM V$DATABASE;
NAME DATABASE_ROLE CONTROLFILE_TYPE OPEN_MODE
----------- ---------------- ------------------- ----------
ORCL PHYSICAL STANDBY STANDBY MOUNTED8.2 – Inicie o modo de recuperação usando um dos seguintes comandos:
-- STANDBY:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
-- OU --
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;8.3 – Neste ponto pode-se efetuar as verificações necessárias do funcionamento do Oracle Data Guard nos dois ambientes. São diversas as formas de verificação, como exemplo seguem algumas:
Listando as informações dos Lags:
-- STANDBY
SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like '%lag';
NAME VALUE DATUM_TIME TIME_COMPUTED
______________ ____________ __________________ ______________________
transport lag +00 00:00:00 09/22/2023 17:14:28 09/22/2023 17:14:29
apply lag +00 00:00:00 09/22/2023 17:14:28 09/22/2023 17:14:298.4 – Listando as informações dos processos com situação e sequência associadas:
-- STANDBY
SELECT process, status, sequence#, block# FROM v$managed_standby;
SELECT process, status, sequence#, block# FROM v$managed_standby;
SELECT process, status, thread#, sequence#, block#, blocks FROM v$managed_standby;
SELECT thread#, sequence#, status FROM v$managed_standby WHERE process='MRP0';
THREAD# SEQUENCE# STATUS
__________ ____________ _______________
1 12 APPLYING_LOG
8.5 –Listando os dados das sequências e se foram ou não aplicadas no banco de dados secundário:
-- PRIMARY
SELECT thread#, sequence#, completion_time, standby_dest, archived, applied FROM v$archived_log WHERE standby_dest = 'YES' ORDER BY 2;
THREAD# SEQUENCE# COMPLETIO STA ARC APPLIED
---------- ---------- --------- --- --- ---------
1 4 26-SEP-24 YES YES YES
1 5 27-SEP-24 YES YES YES
1 6 27-SEP-24 YES YES YES
-- STANDBY
SELECT sequence#, first_time, next_time, applied FROM V$archived_log WHERE applied='YES' ORDER BY next_time;
SEQUENCE# FIRST_TIM NEXT_TIME APPLIED
---------- --------- --------- ---------
4 26-SEP-24 26-SEP-24 YES
5 26-SEP-24 27-SEP-24 YES
6 27-SEP-24 27-SEP-24 YES8.6 –Listando o último log aplicado:
-- STANDBY
SELECT thread#, max(sequence#) as "last_applied_log" FROM v$log_history GROUP BY thread#;8.7 –Verifica e estado do transporte para o STANDBY
-- STANDBY
SELECT d.dest_id, d.dest_name, d.status, d.transmit_mode, d.affirm, d.reopen_secs, d.delay_mins, d.net_timeout, s.type, s.recovery_mode, s.synchronized, s.protection_mode, s.synchronization_status
FROM v$archive_dest d inner join v$archive_dest_status s on d.dest_id = s.dest_id
WHERE d.dest_name = 'LOG_ARCHIVE_DEST_2';
DEST_ID DEST_NAME STATUS TRANSMIT_MODE AFFIRM REOPEN_SECS DELAY_MINS NET_TIMEOUT TYPE RECOVERY_MODE SYNCHRONIZED PROTECTION_MODE SYNCHRONIZATION_STATUS
__________ _____________________ _________ ________________ _________ ______________ _____________ ______________ ________ __________________________ _______________ ______________________ _________________________
2 LOG_ARCHIVE_DEST_2 VALID SYNCHRONOUS NO 300 0 0 LOCAL MANAGED REAL TIME APPLY NO MAXIMUM PERFORMANCE STATUS NOT AVAILABLE
8.8 –Verifica o configurações e Status
-- PRIMARY | STANDBY
SELECT * FROM V$DATAGUARD_CONFIG;8.9 – Verifica o atraso, transporte, aplicação, tempo estimado em caso de transição para PRIMARY
-- STANDBY
SELECT * FROM V$DATAGUARD_STATS;8.10 –Verifica o detalhes das operações de transporte e aplicação de redo.
-- PRIMARY | STANDBY
SELECT * FROM V$DATAGUARD_STATUS order by timestamp desc;8.11 –Verifica o Gap em aplicação de archive
-- PRIMARY
SELECT * FROM V$ARCHIVE_GAP;8.12 –Verifica se archives destinados ao STANDBY ja foram aplicados
-- PRIMARY
SELECT thread#, sequence#, completion_time, standby_dest, archived, applied FROM V$ARCHIVED_LOG WHERE standby_dest = 'YES' order by completion_time desc;
8.13 –Verifica último archive destinado ao STANDBY e que foi aplicado
-- PRIMARY
SELECT thread#, max(completion_time), max(sequence#) FROM V$ARCHIVED_LOG WHERE standby_dest = 'YES' AND applied = 'YES' GROUP BY thread#;
8.14 –Verifica o último sequence# aplicado para cada thread
-- PRIMARY
SELECT max(sequence#) as last_sequence, thread# FROM V$ARCHIVED_LOG WHERE resetlogs_change# = ( SELECT max(resetlogs_change#) FROM V$ARCHIVED_LOG) GROUP BY thread#;
8.15 –Verifica o Sequence# de archive mais recente em cada destino Sequence# deve ser o mesmo em todos os destinos, caso contrário um deles possivelmente estará com algum erro.
-- PRIMARY
SELECT destination, status, archived_thread#, archived_seq# FROM v$archive_dest_status WHERE status <> 'DEFERRED' AND status <> 'INACTIVE';
8.16 –Verifica se algum archived log esta faltando em um destino especifico
*Assumindo que local archive esta em dest_id = 1 e STANDBY esta em dest_id = 2
-- PRIMARY
SELECT thread#, sequence#
FROM v$archived_log prim
WHERE
resetlogs_change# = (SELECT resetlogs_change# FROM v$database)
AND dest_id = 1
AND sequence# not IN ( SELECT sequence# FROM v$archived_log WHERE dest_id = 3 AND thread# = prim.thread# AND resetlogs_change# = prim.resetlogs_change# )
AND sequence# >= ( SELECT max(sequence#) FROM v$archived_log WHERE dest_id = 3 AND thread# = prim.thread# AND resetlogs_change# = prim.resetlogs_change# );
09. MODOS DE PROTEÇÃO
9. Modos de proteção
São 3 (três) os modos de proteção que podem ser configurados no banco de dados primário:
- Máxima disponibilidade (Maximum availability): as transações no banco de dados primário não são "comitadas" até que as informações do redo tenham sido escritas nos arquivos online redo log e standby redo logs do banco de dados secundário. Se não há um ambiente de banco de dados secundário disponível, essa configuração funcionará como se estivesse no modo de máximo desempenho, até que o banco de dados secundário esteja disponível.
- Máximo desempenho (Maximum performance): as transações no banco de dados primário são "comitadas" tão logo as informações do redo tenham sido escritas no arquivo online redo log. A transferência das informações do redo para o banco de dados secundário é assíncrona, ou seja, não impacta no desempenho do banco de dados primário.
- Máxima proteção (Maximum protection): as transações no banco de dados primário não são "comitadas" até que a informações tenham sido escritas nos arquivos online redo log e standby redo logs do banco de dados secundário. Se o banco de dados secundário estiver indisponível, o banco de dados primário é "derrubado".
Por padrão, para uma configuração nova, o banco de dados primário é definido no modo de máximo desempenho. Utilize o seguinte comando para verificação:
SELECT protection_mode FROM v$database;Para alteração do modo de proteção, utilize os seguintes comandos. Observe as alterações necessárias nos parâmetros:
- Máxima disponibilidade (Maximum availability)
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=PRODS AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODS';
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;- Máximo desempenho (Maximum performance)
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=PRODS NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODS';
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;- Máxima proteção (Maximum protection)
--Maximum protection
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=PRODS AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODS';
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
ALTER DATABASE OPEN;10. BANCO DE DADOS SECUNDÁRIO EM MODO SOMENTE DE LEITURA E ACTIVE DATA GUARD
Também é possível colocar o banco de dados secundário em modo de somente leitura, para que seja possível efetuar uma consulta neste banco. Porém, durante esse tempo o banco de dados estará desatualizado em relação ao banco de dados primário, até que seja retornado o processo de aplicação dos redos log files. Execute os seguintes comandos para colocar em modo de somente leitura:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;Para retornar à situação normal de funcionamento do Oracle Data Guard, execute:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
A partir da versão 11g do Oracle, foi introduzido o recurso Active Data Guard, que permite ao banco de dados secundário funcionar em modo somente de leitura, mas ainda assim continuar aplicando os redos log files. Para uso deste recurso é necessário um licenciamento específico. De qualquer forma seguem os comandos para habilitar o active data guard:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
11. CHAVEAMENTO: INVERSÃO DO PAPEL ENTRE OS BANCOS DE DADOS PRIMÁRIO E STANDBY
Os bancos de dados envolvidos no ambiente de alta disponibilidade com o Oracle Data Guard podem, se necessário, ter seus papéis invertidos. E este processo pode ocorrer sem qualquer problema em tempo de execução sem qualquer perda de dados ou limpeza de redo log files.
Essa inversão de papéis recebe o nome de switchover, e pode ser feita com os seguintes passos:
11.1 – Identificando os bancos através da consulta (database_role):
-- PRIMARY
SELECT name,db_unique_name,open_mode,log_mode,database_role FROM V$DATABASE;
NAME DB_UNIQUE_NAME OPEN_MODE LOG_MODE DATABASE_ROLE
__________ _________________ _____________ _____________ ________________
prod prod READ WRITE ARCHIVELOG PRIMARY
--STANDBY
SELECT name,db_unique_name,open_mode,log_mode,database_role FROM V$DATABASE;
NAME DB_UNIQUE_NAME OPEN_MODE LOG_MODE DATABASE_ROLE
__________ _________________ ____________ _____________ ___________________
prod prods MOUNTED ARCHIVELOG PHYSICAL STANDBY
Ou atraves da view v$dataguard_config;
SELECT * FROM V$DATAGUARD_CONFIG;
DB_UNIQUE_NAME PARENT_DBUN DEST_ROLE CURRENT_SCN CON_ID
_________________ ______________ ___________________ ________________ _________
PROD NONE PRIMARY DATABASE 2000754792365 0
PRODS PROD PHYSICAL STANDBY 2000754792310 0
Podemos preservar o estado das conexões no switchover com o parâmetro standby_db_preserve_states:
• NONE: sessões de usuários e buffers não preservados (padrão)
• ALL: sessões de usuários e buffers preservados
• SESSION: sessões de usuário preservadas
• BUFFER: buffers preservados
Obs: Esse procedimento deve ser realizado para versões acima de 12.2.0.1, e também para standby físico. Deve ser configurado antes de iniciar o standby.
11.2 – Consultar o parâmetro:
-- PRIMARY
SHOW PARAMETER STANDBY_DB_PRESERVE_STATES;
NAME TYPE VALUE
-------------------------- ------ -----
standby_db_preserve_states string NONE
ALTER SYSTEM SET STANDBY_DB_PRESERVE_STATES=ALL SCOPE=SPFILE;
11.3 – Consultar como estão as configurações e status:
-- PRIMARY
SELECT d.dest_id, d.dest_name, d.status, d.transmit_mode, d.affirm, d.reopen_secs, d.delay_mins, d.net_timeout, s.type, s.recovery_mode, s.synchronized, s.protection_mode, s.synchronization_status from v$archive_dest d inner join v$archive_dest_status s on d.dest_id = s.dest_id where d.dest_name = 'LOG_ARCHIVE_DEST_3';
11.4 – Verificar se Standby está pronto para assumir como Primário:
-- PRIMARY
ALTER DATABASE SWITCHOVER TO PRODS VERIFY;11.5 – No Servidor Standby (PRODS): verificando se log_archive_dest tem configuração preparada para enviar redo quando ele assumir papel de Primary.
-- STANDBY
select dest_id, dest_name, status, target, destination, transmit_mode, affirm, valid_type, valid_role, valid_now from v$archive_dest where dest_id <= 3;11.6 – Realizando a mudança entre bases:
-- PRIMARY
ALTER DATABASE SWITCHOVER TO PRODS;OBS: PROD será abaixado automaticamente, sendo possível constatar através do comando:
ps -ef | grep pmon11.7 – PRODS que originalmente era Standby se torna o Primário:
SELECT name,DB_UNIQUE_NAME,open_mode,log_mode,force_logging,flashback_on,database_role FROM V$DATABASE;
NAME DB_UNIQUE_NAME OPEN_MODE LOG_MODE DATABASE_ROLE
__________ _________________ ____________ ___________________ _______________
PROD PRODS MOUNTED ARCHIVELOG PRIMARY
Troca Realizada:
Agora PRODS é o Primário e PROD se tornou o standby.
Abrindo o banco:
-- PRIMARY(PRODS)
ALTER DATABASE OPEN;
ALTER PLUGGABLE DATABASE ALL OPEN;Em PROD (que agora é Standby):Montando e Habilitando para receber e aplicar os arquivos Redos
--STANDBY(PROD)
STARTUP MOUNT;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Verificar a troca:
Em PRODS (que agora é primário):
-- PRIMARY(PRODS)
SELECT * FROM V$DATAGUARD_CONFIG;-- PRIMARY(PRODS)
SELECT D.DEST_ID, D.DEST_NAME, D.STATUS, D.TRANSMIT_MODE, D.AFFIRM, D.REOPEN_SECS, D.DELAY_MINS, D.NET_TIMEOUT, S.TYPE, S.RECOVERY_MODE, S.SYNCHRONIZED, S.PROTECTION_MODE, S.SYNCHRONIZATION_STATUS
FROM V$ARCHIVE_DEST D INNER JOIN V$ARCHIVE_DEST_STATUS S ON D.DEST_ID = S.DEST_ID WHERE D.DEST_NAME = 'LOG_ARCHIVE_DEST_3';
--PRIMARY(PRODS)
SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like '%lag';
NAME VALUE DATUM_TIME TIME_COMPUTED
________________ ____________ ___________________ ______________________
transport lag +00 00:00:00 09/25/2023 13:11:49 09/25/2023 13:11:51
apply lag +00 00:00:00 09/25/2023 13:11:49 09/25/2023 13:11:51Tal procedimento se aplica por exemplo para aplicação de algum patch ou outra manutenção qualquer no servidor ou instância e pode ser revertida para a configuração anterior, o que é chamado de switchback.
12. CHAVEAMENTO EM CASO DE FALHA (FAILOVER)
Usado quando ocorre indisponibilidade não programada do ambiente do banco de dados primário, neste caso o banco de dados secundário pode ser configurado como banco de dados primário utilizando os seguintes comandos:
12.1 – Verificar a configuração:
--STANDBY(PROD)
SELECT * FROM V$DATAGUARD_CONFIG;12.2 – Verificar os erros gerados
--STANDBY SOBREVIVENTE
select * from v$dataguard_status where severity = 'Warning' or error_code <> 0;
12.3 – Parar a replicação:
--STANDBY SOBREVIVENTE
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
12.4 – Colocar o Standby como banco ativo:
--STANDBY SOBREVIVENTE
ALTER DATABASE OPEN;
ALTER PLUGGABLE DATABASE pdbXXX OPEN;
Verificar a configuração:
--STANDBY SOBREVIVENTE
select * from v$dataguard_config;Neste ponto, com o antigo banco de dados secundário configurado como banco de dados primário, sugere-se efetuar imediatamente um backup completo.
Restabelecendo a disponibilidade do antigo banco de dados primário, pode-se configurá-lo como um banco de dados secundário. Isso se o Flashback Database foi habilitado, como sugerido neste documento anteriormente, pode ser feito de modo relativamente fácil. Se não, todo o processo desde o início deverá ser executado, mas desta vez usando o banco de dados primário original, como secundário.
13. RECUPERAÇÃO DE UM DESASTRE ATRAVÉS DO RECURSO DE FLASHBACK
13.1 – Colocando o servidor que falhou de volta como Standby Fisico, usando FLASHBACK
--STANDBY SOBREVIVENTE QUE SE TORNOU PRIMÁRIO
SELECT STANDBY_BECAME_PRIMARY_SCN FROM V$DATABASE;
STANDBY_BECAME_PRIMARY_SCN
_____________________________
200075491209013.2 – Monta a base defeituosa:
--ANTIGO PRIMÁRIO COM FALHA
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
FLASHBACK DATABASE TO SCN [snc obtido acima];13.3 – Converter em Standby
--ANTIGO PRIMÁRIO RECUPERADO
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
13.4 – Consultando o envio do log
--ANTIGO PRIMÁRIO RECUPERADO
select d.dest_id, d.dest_name, d.status, d.transmit_mode, d.affirm, d.reopen_secs, d.delay_mins, d.net_timeout, s.type, s.recovery_mode, s.synchronized, s.protection_mode, s.synchronization_status
from v$archive_dest d inner join v$archive_dest_status s on d.dest_id = s.dest_id where d.dest_name = 'LOG_ARCHIVE_DEST_3';13.5 – Girando o Switch
--STANDBY SOBREVIVENTE QUE SE TORNOU PRIMÁRIO
ALTER SYSTEM SWITCH LOGFILE; 13.6 – Iniciar aplicação de redo
--ANTIGO PRIMÁRIO RECUPERADO
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
13.7 – Verificar se está em conformidade
--ANTIGO PRIMÁRIO RECUPERADO QUE SE TORNOU STANDBY
SELECT * FROM V$DATAGUARD_STATS;
SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like '%lag';14. RECUPERAÇÃO DE UM DESASTRE ATRAVÉS DA FERRAMENTA RMAN
14.1 – Colocando o servidor que falhou de volta como Standby Fisico, usando RMAN
Verificar se esta ok:
--STANDBY SOBREVIVENTE QUE SE TORNOU PRIMÁRIO
SELECT STANDBY_BECAME_PRIMARY_SCN FROM V$DATABASE;
STANDBY_BECAME_PRIMARY_SCN
_____________________________
200075491209014.2 – Monta a base defeituosa:
--ANTIGO PRIMÁRIO COM FALHA
rman
STARTUP MOUNT;14.3 – Restaurar a base de dados:
--ANTIGO PRIMÁRIO COM FALHA SENDO RECUPERADO
RMAN>
RUN {
SET UNTIL SCN [SNC_OBTIDO_ACIMA + 1];
RESTORE DATABASE;
RECOVER DATABASE;
}Comando Alternativo:
--ANTIGO PRIMÁRIO COM FALHA SENDO RECUPERADO
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CHANGE [SNC_OBTIDO_ACIMA + 1]; 14.4 –Converter em Standby:
--ANTIGO PRIMÁRIO RECUPERADO QUE SE TORNOU STANDBY
ALTER DATABASE CONVERT TO PHYSICAL STANDBY; 14.5 – Abrir a base para sincronizar o control file:
--ANTIGO PRIMÁRIO RECUPERADO QUE SE TORNOU STANDBY
ALTER DATABASE OPEN READ ONLY;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT; 14.6 – Verifique, no novo Primary, se transporte esta configurado:
-- STANDBY SOBREVIVENTE QUE SE TORNOU PRIMÁRIO
select d.dest_id, d.dest_name, d.status, d.transmit_mode, d.affirm, d.reopen_secs, d.delay_mins, d.net_timeout, s.type, s.recovery_mode, s.synchronized, s.protection_mode, s.synchronization_status
from v$archive_dest d inner join v$archive_dest_status s on d.dest_id = s.dest_id where d.dest_name = 'LOG_ARCHIVE_DEST_3'; 14.7 – Girar o logfile:
-- STANDBY SOBREVIVENTE QUE SE TORNOU PRIMÁRIO
ALTER SYSTEM SWITCH LOGFILE;14.8 – Iniciar aplicacao de redo:
--ANTIGO PRIMÁRIO RECUPERADO QUE SE TORNOU STANDBY
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
14.9 – Verificar a configuração
--ANTIGO PRIMÁRIO RECUPERADO QUE SE TORNOU STANDBY
SELECT * FROM V$DATAGUARD_STATS;
Comando Alternativo com mais detalhes
--ANTIGO PRIMÁRIO RECUPERADO QUE SE TORNOU STANDBY
SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like '%lag';| PRIMARY | STANDBY |
|---|---|
|
|
COMENTÁRIOS
0.0 / 5
0 Avaliações
5
(0)
4
(0)
3
(0)
2
(0)
1
(0)
