Quando configuramos um Data Guard Logical Standby, a intenção primária é proteger as tabelas replicadas no ambiente standby para evitar que os usuários realizem alterações nelas, como DMLs e DDLs (uma vez que o banco de dados fica aberto neste cenário). Para isso, podemos utilizar no destino a propriedade “Guard”. Seu valor padrão está como ALL, o que significa que o Oracle impedirá que qualquer usuário (exceto o SYS) realize alterações em qualquer dado no logical standby database. Vejamos o exemplo abaixo que utiliza uma tabela usada pelo SQL Apply:
[oracle@fornix2 admin]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Apr 2 06:09:57 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 GUARD_STATUS FROM V$DATABASE;
GUARD_S
-------
ALL
SQL> conn SOE/soe
Connected.
SQL> SHOW USER;
USER is "SOE"
SQL> UPDATE SOE.MERCURIO SET NOME='BRUNO';
UPDATE SOE.MERCURIO SET NOME='BRUNO'
*
ERROR at line 1:
ORA-16224: Database Guard is enabled
Vejamos que este valor não permite criação de novos objetos no Standby. É como se o banco estivesse em read-only, sem a necessidade de fazermos um shutdown no ambiente:
SQL> CREATE TABLE SOE.MERCURIO2 ( ID NUMBER PRIMARY KEY, NOME VARCHAR2(30)) ;
CREATE TABLE SOE.MERCURIO2 ( ID NUMBER PRIMARY KEY, NOME VARCHAR2(30))
*
ERROR at line 1:
ORA-16224: Database Guard is enabled
Caso mudemos o valor dessa propriedade para STANDBY, o Oracle não permitirá mudanças de nenhum usuário (exceto SYS) nas tabelas que são mantidas pelo SQL Apply. Façamos uma simulação:
[oracle@fornix2 admin]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Apr 2 06:18:01 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 GUARD STANDBY;
Database altered.
SQL> conn SOE/soe
Connected.
SQL> sho user;
USER is "SOE"
SQL> UPDATE SOE.MERCURIO SET NOME='BRUNO';
UPDATE SOE.MERCURIO SET NOME='BRUNO'
*
ERROR at line 1:
ORA-16224: Database Guard is enabled
Porém, os outros objetos que não estão sendo usados pelo SQL Apply, podem ser manipulados sem problemas:
SQL> CREATE TABLE SOE.MERCURIO2 ( ID NUMBER PRIMARY KEY, NOME VARCHAR2(30)) ;
Table created.
SQL> INSERT INTO SOE.MERCURIO2 VALUES (1, 'STRING A') ;
1 row created.
SQL> commit;
Commit complete.
SQL> DROP TABLE SOE.MERCURIO2;
Table dropped.
Caso mudemos o valor da propriedade para NONE, o Oracle respeitará os privilégios que os usuários possuem, ou seja, como se fosse o método típico que temos no primary:
[oracle@fornix2 admin]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Apr 2 06:21: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> ALTER DATABASE GUARD NONE;
Database altered.
SQL> CONN SOE/soe
Connected.
SQL> SHOW USER;
USER is "SOE"
SQL> INSERT INTO SOE.MERCURIO VALUES (4, 'STRING D') ;
1 row created.
SQL> COMMIT;
Commit complete.
SQL> DELETE FROM SOE.MERCURIO WHERE NOME='STRING D';
1 row deleted.
SQL> COMMIT;
Commit complete.
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