Neste artigo, vamos explorar uma situação de Falha Parcial, onde a camada de Banco de Dados é afetada (apenas o banco Primary), e a camada de Aplicação (Client) consegue realizar o redirecionamento das conexões (inclusive as vigentes) para o banco Standby. Esse recurso é possível graças a implementação de alguns pré-requisitos:
- Database Services
- Data Broker com Fast-Start Failover (FSFO)
- Oracle Restart (para instâncias single, que é o nosso caso)
- Configuração na camada client (que pode ser OCI, JDBC e ODP.Net)
Desse modo, quando o evento de falha é identificado, o Relocate do Serviço de Banco de Dados é realizado, e o Broker envia uma notificação FAN para a camada client, informando sobre a situação. Como a camada client já estava com suas configurações realizadas previamente, ela consegue direcionar as conexões para o novo banco Primary. Vamos iniciar o processo de preparação:
No ambiente Standby, vamos validar que o banco está up, e mudar a sua opção de startup (que está em mount) para OPEN. Assim, quando ligarmos o processo de Apply, o recurso de Real-Time Query estará habilitado:
[oracle@fornix2 ~]$ srvctl status database -d cortexdr
Database is running.
[oracle@fornix2 ~]$ srvctl update database -db cortexdr -startoption OPEN
Ligando o processo de Redo Apply:
[oracle@fornix2 ~]$ dgmgrl sys/oracle@CORTEXDR as sysdba
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Sat Jun 14 05:04:17 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected to "cortexDR"
Connected as SYSDBA.
DGMGRL> EDIT DATABASE CORTEXDR SET STATE=APPLY-ON;
Succeeded.
Iniciando o processo do Observer:
[oracle@fornix2 ~]$ dgmgrl sys/oracle@CORTEXDR as sysdba
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Jun 14 05:13:22 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected to "cortexDR"
Connected as SYSDBA.
DGMGRL> START OBSERVER FILE='/home/oracle/CORTEXDR.dat';
[W000 2021-06-14T05:13:33.678-03:00] FSFO target standby is cortexdr
Observer 'fornix2' started
[W000 2021-06-14T05:13:33.832-03:00] Observer trace level is set to USER
[W000 2021-06-14T05:13:33.832-03:00] Try to connect to the primary.
[W000 2021-06-14T05:13:33.832-03:00] Try to connect to the primary cortex.
[W000 2021-06-14T05:13:33.898-03:00] The standby cortexdr is ready to be a FSFO target
[W000 2021-06-14T05:13:34.898-03:00] Connection to the primary restored!
[W000 2021-06-14T05:13:36.899-03:00] Disconnecting from database cortex.
Agora podemos checar a configuração do nosso Data Guard através do Broker:
[oracle@fornix1 ~]$ dgmgrl sys/oracle@CORTEX as sysdba
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Jun 14 05:15:35 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected to "cortex"
Connected as SYSDBA.
DGMGRL> SHOW CONFIGURATION;
Configuration - cortex
Protection Mode: MaxPerformance
Members:
cortex - Primary database
cortexdr - (*) Physical standby database
Fast-Start Failover: Enabled in Potential Data Loss Mode
Configuration Status:
SUCCESS (status updated 15 seconds ago)
DGMGRL> SHOW DATABASE CORTEX;
Database - cortex
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
cortex
Database Status:
SUCCESS
DGMGRL> SHOW DATABASE CORTEXDR;
Database - cortexdr
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: 0 Byte/s
Real Time Query: ON
Instance(s):
CORTEXDR
Database Status:
SUCCESS
Criando um novo Database Service no banco Primary e o iniciando:
[oracle@fornix1 ~]$ srvctl add service -db CORTEX -service BSS -role PRIMARY -notification TRUE -failovermethod BASIC -failoverdelay 3 -failoverretry 120 -failovertype SELECT
[oracle@fornix1 ~]$ srvctl start service -service BSS -db CORTEX
[oracle@fornix1 ~]$
Criando um Database Service também no ambiente Standby (não podemos esquecer de deixar o parâmetro ROLE como PRIMARY):
[oracle@fornix2 ~]$ srvctl add service -db CORTEXDR -service BSS -role PRIMARY -notification TRUE -failovermethod BASIC -failoverdelay 3 -failoverretry 120 -failovertype SELECT
[oracle@fornix2 ~]$
Verificando os serviços criados:
[oracle@fornix1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Mon Jun 14 05:17:41 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> select name from dba_services ;
NAME
----------------------------------------------------------------
SYS$BACKGROUND
SYS$USERS
cortex_CFG
BSS
cortexXDB
cortex.localdomain
6 rows selected.
[oracle@fornix2 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Mon Jun 14 05:18:09 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> select name from dba_services ;
NAME
----------------------------------------------------------------
SYS$BACKGROUND
SYS$USERS
cortex_CFG
BSS
cortexXDB
cortex.localdomain
6 rows selected.
Para simular a camada Client, editei o arquivo “tnsnames.ora” do Oracle Client instalado em meu notebook pessoal, para acessar os ambientes:
O teste de tnsping está OK:
Realizando a conexão com a última STRING adicionada (que usa os recursos de Failover):
Para completar essa camada, vamos adicionar ao arquivo sqlnet.ora a linha abaixo, no Oracle Client do meu notebook:
Agora vem a parte legal do teste. Vamos disparar o comando abaixo de consulta através do meu Oracle Client, que demora alguns minutos para concluir, devido plano cartesiano gerado. Enquanto a consulta é realizada, vamos abortar a instância do banco Primary. Isso provocará em nossa sessão Client uma experiência de congelamento. Uma vez identificado a indisponibilidade do Primary, o FSFO vai abrir o até então Standby como Primary, mandar a FAN notification para o Client, que redirecionará a sessão ativa para o novo Primary, e então continuar a execução do select. Importante citarmos que execuções de DML não possuem esse comportamento.
select x.employee_id from hr.employees x, hr.employees y, hr.employees z;
[oracle@fornix1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Mon Jun 14 05:23:12 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> SHU ABORT;
ORACLE instance shut down.
Sessão em Hang:
FSFO identificando que o Primary está inacessível e fazendo desse modo o Failover:
Failover realizado:
[S002 2021-06-14T05:24:09.628-03:00] Initiating Fast-start Failover.
Performing failover NOW, please wait...
Failover succeeded, new primary is "cortexdr"
Nesse ponto, nossa sessão contina o seu processamento de onde tinha parado, sem necessidade de intervenção:
Processamento realizado:
E agora podemos constatar que a instância que estamos conectados é o novo Primary:
Vamos subir a antiga instância do Primary:
[oracle@fornix1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Mon Jun 14 05:29:21 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup;
ORACLE instance started.
Total System Global Area 2583690520 bytes
Fixed Size 8899864 bytes
Variable Size 553648128 bytes
Database Buffers 2013265920 bytes
Redo Buffers 7876608 bytes
Database mounted.
Database opened.
Reinstate realizado automaticamente:
[W000 2021-06-14T05:30:36.891-03:00] The standby cortex is ready to be a FSFO target
Reinstatement of database "cortex" succeeded
2021-06-14T05:31:22.128-03:00
[W000 2021-06-14T05:31:22.949-03:00] Successfully reinstated database cortex.
Realizando um Switchover para o Primary original:
[oracle@fornix1 ~]$ dgmgrl sys/oracle@CORTEX as sysdba DGMGRL for Linux: Release 19.0.0.0.0 - Production on Mon Jun 14 05:35:05 2021
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected to "cortex"
Connected as SYSDBA.
DGMGRL> SHOW CONFIGURATION;
Configuration - cortex
Protection Mode: MaxPerformance
Members:
cortexdr - Primary database
cortex - (*) Physical standby database
Fast-Start Failover: Enabled in Potential Data Loss Mode
Configuration Status:
SUCCESS (status updated 47 seconds ago)
DGMGRL> SWITCHOVER TO CORTEX;
Performing switchover NOW, please wait...
New primary database "cortex" is opening...
Oracle Clusterware is restarting database "cortexdr" ...
Connected to an idle instance.
Connected to an idle instance.
Connected to an idle instance.
Connected to an idle instance.
Connected to an idle instance.
Connected to "cortexDR"
Connected to "cortexDR"
Switchover succeeded, new primary is "cortex"
DGMGRL> SHOW CONFIGURATION;
Configuration - cortex
Protection Mode: MaxPerformance
Members:
cortex - Primary database
cortexdr - (*) Physical standby database
Fast-Start Failover: Enabled in Potential Data Loss Mode
Configuration Status:
SUCCESS (status updated 43 seconds ago)
DGMGRL>
Observer:
É possível ver que nossa sessão agora alcança a instância do Primary original, de forma totalmente transparente:
Obs: Este procedimento foi criado pelo senhor Ahmed Baraka (www.ahmedbaraka.com) e foi apenas reproduzido por mim em um laboratório pessoal para fins de aprendizado.
Portuguese
English
Spanish