Em muitas situações, precisamos validar algum deploy importante em nosso ambiente produtivo, para ver se sua implementação será bem sucedida e se não trará malefícios (até em termos de performance) para o banco como um todo. Nesses casos, podemos utilizar um recurso muito interessante: Snapshot Databases, que faz parte da licença do Enterprise Edition. Neste caso, conseguimos realizar operações de alterações no Snap, como DDLs, DMLs,etc, e durante sua vida útil, os Redos do primary são apenas transmitidos ao standby, mas não aplicados. No momento da criação do Snapshot Database, um Guaranteed Restore Point (GRP) é criado nos bastidores, para que nos permita realizar a conversão depois para Standby Database. Neste artigo vamos demonstrar como realizar essa operação utilizando o SQL *Plus.
Validando ambiente primary e standby que serão usados:
[oracle@fornix1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jun 3 05:23:25 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 DB_UNIQUE_NAME,DATABASE_ROLE,OPEN_MODE FROM V$DATABASE;
DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE
------------------------------ ---------------- --------------------
cortex PRIMARY READ WRITE
[oracle@fornix2 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jun 3 05:23: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> SELECT DB_UNIQUE_NAME,DATABASE_ROLE,OPEN_MODE FROM V$DATABASE;
DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE
------------------------------ ---------------- --------------------
cortexDR PHYSICAL STANDBY MOUNTED
O processo em si é muito simples. Vamos parar o processo de Redo Apply do Standby, conforme abaixo:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
Devemos garantir que o Standby esteja em mount state (que já é o meu caso), e disparar o comando de conversão:
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
Database altered.
Agora podemos abrir o Standby em read/write mode:
SQL> ALTER DATABASE OPEN;
Database altered.
Podemos notar que o database role é exibido como snapshot, além de já termos garantido que o ambiente tenha o Flashback Database habilitado:
SQL> SELECT DATABASE_ROLE, OPEN_MODE, FLASHBACK_ON FROM V$DATABASE;
DATABASE_ROLE OPEN_MODE FLASHBACK_ON
---------------- -------------------- ------------------
SNAPSHOT STANDBY READ WRITE YES
Simulando a execução de DDL e DML no Snapshot Standby:
SQL> CREATE TABLE SOE.VALIDACAO (DESCRICAO VARCHAR2(40));
Table created.
SQL> INSERT INTO SOE.VALIDACAO (DESCRICAO) VALUES ('SNAP STANDBY');
1 row created.
SQL> COMMIT;
Commit complete.
SQL> SELECT * FROM SOE.VALIDACAO;
DESCRICAO
----------------------------------------
SNAP STANDBY
Podemos notar que os Redos gerados pelo primary ainda não enviados ao Standby, mas como dito no início do artigo, os mesmos não são aplicados. Serão usados depois para a conversão do Snapshot Database para Standby Database:
SQL> SELECT DB_UNIQUE_NAME,DATABASE_ROLE,OPEN_MODE FROM V$DATABASE;
DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE
------------------------------ ---------------- --------------------
cortex PRIMARY READ WRITE
SQL> ALTER SYSTEM SWITCH LOGFILE ;
System altered.
SQL> SELECT THREAD#, MAX(SEQUENCE#) FROM V$LOG GROUP BY THREAD# ;
THREAD# MAX(SEQUENCE#)
---------- --------------
1 101
SQL> SELECT PROCESS,STATUS,SEQUENCE# FROM V$MANAGED_STANDBY;
PROCESS STATUS SEQUENCE#
--------- ------------ ----------
ARCH CONNECTED 0
DGRD ALLOCATED 0
DGRD ALLOCATED 0
ARCH CONNECTED 0
ARCH CLOSING 99
ARCH CLOSING 100
LNS CONNECTED 0
DGRD ALLOCATED 0
RFS IDLE 0
RFS IDLE 101
10 rows selected.
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