Enabling Active Data Guard Option (using SQL *Plus)

Disponível para ambientes do tipo “Physical Standby”, o Active Data Guard permite que o processo de Redo Apply fique ativo, mesmo que o o banco Standby esteja aberto. Essa opção exige um licenciamento específico para ser utilizada. Desse modo, conseguimos realizar no Standby: consultas (Select), rodar procedures e functions PL/SQL (desde que não executem nenhuma manipulação de dados), utilizar DB_LINKS, usar o “SET ROLE, ALTER SESSION, ALTER SYSTEM” e ainda DMLs em tabelas do tipo Global Temporary (o que ajuda naqueles tipos de aplicações de relatórios que criam objetos temporários). Porém, não conseguimos fazer DMLs, DDLs, acessar local sequences e DMLs em tabelas do tipo local temporary. Neste artigo vamos explorar como habilitar o Active Data Guard usando o utilitário SQL *Plus.

Checando os bancos de dados envolvidos:

[oracle@fornix1 ~]$ sqlplus / as sysdba
 
SQL*Plus: Release 19.0.0.0.0 - Production on Tue Jun 1 04:40:03 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,OPEN_MODE,DATABASE_ROLE FROM V$DATABASE;
 
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
CORTEX    READ WRITE           PRIMARY
[oracle@fornix2 trace]$ sqlplus / as sysdba
 
SQL*Plus: Release 19.0.0.0.0 - Production on Tue Jun 1 04:40:36 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,OPEN_MODE,DATABASE_ROLE FROM V$DATABASE;
 
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
CORTEX    MOUNTED              PHYSICAL STANDBY

Vamos parar o Redo Apply no Standby:

[oracle@fornix2 trace]$ sqlplus / as sysdba
 
SQL*Plus: Release 19.0.0.0.0 - Production on Tue Jun 1 04:42:59 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> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
 
Database altered.

Abrindo o banco do Standby:

SQL> ALTER DATABASE OPEN;
 
Database altered.

Iniciando processo de Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
 
Database altered.

Percebemos que o Open_Mode do Standby é alterado:

SQL> SELECT NAME,OPEN_MODE,DATABASE_ROLE FROM V$DATABASE;
 
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
CORTEX    READ ONLY WITH APPLY PHYSICAL STANDBY
 
SQL> SELECT INSTANCE_NAME,STATUS FROM V$INSTANCE;
 
INSTANCE_NAME    STATUS
---------------- ------------
CORTEXDR         OPEN

Uma vez habilitado, é possível monitorarmos o “Apply Lag” neste tipo de ambiente também conhecido como Real-Time Query environment:

SQL> SELECT value "Lag", datum_time "Received Time", Time_Computed "Time Computed " FROM V$DATAGUARD_STATS WHERE name like 'apply lag';
 
Lag
----------------------------------------------------------------
Received Time                  Time Computed
------------------------------ ------------------------------
+00 00:00:00
06/01/2021 04:52:05            06/01/2021 04:52:07

Para realizarmos um teste, vamos criar uma tabela no banco Primary com um registro:

SQL> CREATE TABLE SOE.TESTE1 (DESCRICAO VARCHAR2(20));
 
Table created.
 
SQL> INSERT INTO SOE.TESTE1 (DESCRICAO) VALUES ('ACTIVE DATA GUARD');
 
1 row created.
 
SQL> COMMIT;
 
Commit complete.

No ambiente Standby, já podemos notar que a tabela e seu registro já estão disponíveis para consumo:

SQL> SELECT NAME,OPEN_MODE,DATABASE_ROLE FROM V$DATABASE;
 
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
CORTEX    READ ONLY WITH APPLY PHYSICAL STANDBY
 
SQL> SELECT * FROM SOE.TESTE1;
 
DESCRICAO
--------------------
ACTIVE DATA GUARD

Dropando tabela do Primary:

SQL> DROP TABLE SOE.TESTE1;
 
Table dropped.

No standby já vemos o reflexo imediato:

SQL> SELECT * FROM SOE.TESTE1;
SELECT * FROM SOE.TESTE1
                  *
ERROR at line 1:
ORA-00942: table or view does not exist

Para voltarmos o ambiente para o Physical Standby tradicional, basta pararmos o Redo Apply, monstarmos o banco e ligarmos novamente o Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
 
Database altered.
 
SQL> SHU IMMEDIATE;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP MOUNT;
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.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
 
Database altered.

Validando Standby:

SQL> SELECT NAME,OPEN_MODE,DATABASE_ROLE FROM V$DATABASE;
 
NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
CORTEX    MOUNTED              PHYSICAL STANDBY

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.

Leave a Comment

Your email address will not be published.