Eai pessoal, tudo bem?
Fiz um lab para testar algumas funcionalidades do snapshot standby e depois retornei ele para um standby físico e notifiquei o procedimento aqui no artigo, espero que sirva para ajudar quem queira fazer um lab parecido para estudar mais sobre dataguard.
Então vamos lá tenho a minha seguinte configuração de DG para esse ambiente
Configuration - dgProtection Mode: MaxPerformanceMembers:orcl - Primary database orcldg - Physical standby databaseFast-Start Failover: DisabledConfiguration Status:SUCCESS (status updated 5 seconds ago)
No primário eu tenho as seguintes tablespaces
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;TABLESPACE_NAME------------------------------SYSTEMSYSAUXUNDOTBS1TEMPUSERSTBS_10M_PRIM
Agora vou converter o standby físico para o standby snapshot através do broker
[oracle@ol7-dba ~]$ dgmgrl sys/oracle@orclDGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue May 28 17:17:02 2024Version 19.3.0.0.0Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.Welcome to DGMGRL, type "help" for information.Connected to "orcl"Connected as SYSDBA.DGMGRL> show configuration;Configuration - dg Protection Mode: MaxPerformance Members: orcl - Primary database orcldg - Physical standby databaseFast-Start Failover: DisabledConfiguration Status:SUCCESS (status updated 59 seconds ago)DGMGRL> CONVERT DATABASE orcldg TO SNAPSHOT STANDBY;Converting database "orcldg" to a Snapshot Standby database, please wait...Database "orcldg" converted successfully
Após isso já consigo verificar o banco que antes era physical standby como snapshot standby através da configuração do broker
DGMGRL> show configuration verbose;Configuration - dg Protection Mode: MaxPerformance Members: orcl - Primary database orcldg - Snapshot standby database Properties: FastStartFailoverThreshold = '30' OperationTimeout = '30' TraceLevel = 'USER' FastStartFailoverLagLimit = '30' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' ConfigurationWideServiceName = 'orcl_CFG'Fast-Start Failover: DisabledConfiguration Status:SUCCESSDGMGRL>
Também consigo verificar via SQL que o banco já se encontra com a role de snapshot
SQL> SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;OPEN_MODE DATABASE_ROLE------------------- ----------------READ WRITE SNAPSHOT STANDBY
Agora posso verificar também os restore points criados para realizar a conversão para um standby físico futuramente
SQL> SELECT NAME, SCN, TIME, GUARANTEE_FLASHBACK_DATABASE FROM V$RESTORE_POINT;NAME SCN TIME GUARANTEE_FLASHBACK_DATABASE--------------------------- ---------- ---------------------------- ----------------------------SNAPSHOT_STANDBY_REQUIRED ########## 28-MAY-24 05.12.06.000000 YES_05/28/2024 17:12:06 000 PMSQL>
Consigo verificar também que só existe um flashback log para aquele restore point
SQL> SELECT FLASHBACK_ON FROM V$DATABASE;FLASHBACK_ON------------------RESTORE POINT ONLY
Agora vou validar o SCN dos 2 databases
Primario
SQL> SELECT CURRENT_SCN FROM V$DATABASE;CURRENT_SCN----------- 3440607
Snapshot
SQL> SELECT CURRENT_SCN FROM V$DATABASE;CURRENT_SCN----------- 3442867
Irei criar uma tablespace TESTE para o meu Snapshot Standby
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;TABLESPACE_NAME------------------------------SYSTEMSYSAUXUNDOTBS1TEMPUSERSTBS_10M_PRIMTESTE
E consigo validar que ela não será mais criada no meu banco primário
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;TABLESPACE_NAME------------------------------SYSTEMSYSAUXUNDOTBS1TEMPUSERSTBS_10M_PRIM
Uma informação legal de se passar também é que embora o snapshot standby seja um banco onde eu possa realizar mudanças sem impactar o meu banco primário, eu mesmo assim não consigo realizar nenhum tipo de alteração nele que possa comprometer o banco principal em uma possível troca de roles futuramente, como no exemplo a baixo ao tentar apagar a tablespace USERS no meu standby snapshot
SQL> ALTER DATABASE DEFAULT TABLESPACE TESTE;Database altered.SQL> DROP TABLESPACE USERS;DROP TABLESPACE USERS*ERROR at line 1:ORA-38881: Cannot drop tablespace USERS on primary database due to guaranteed restore points.
No geral operações que interfiram nos datafiles do banco acabam não podendo ser realizadas pelo snapshot standby, mas o resize de datafiles acaba sendo uma exceção ao caso
SQL> SET LINES WINDOWSQL> SELECT FILE_NAME, FILE_ID, BYTES/1024/1024 MB FROM DBA_DATA_FILES WHERE TABLESPACE_NAME IN ('TBS_10M_PRIM', 'TBS_10M_SNAP');FILE_NAME---------------------------------------------------------------------------------------------------- FILE_ID MB---------- ----------/u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dggwj0_.dbf 13 10/u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dhrdf2_.dbf 15 10SQL> ALTER DATABASE DATAFILE '/u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dhrdf2_.dbf' RESIZE 20M;Database altered.SQL> ALTER DATABASE DATAFILE '/u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dggwj0_.dbf' RESIZE 20M;Database altered.
Porém na hora de realizar uma operação de shrink, embora o banco me deixa diminuir o datafile criado no snapshot, ele não me deixa realizar o downsize do meu datafile criado no banco primário justamente por conta do meu restore garantido
SQL> ALTER DATABASE DATAFILE '/u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dhrdf2_.dbf' RESIZE 10M;Database altered.SQL> ALTER DATABASE DATAFILE '/u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dggwj0_.dbf' RESIZE 10M;ALTER DATABASE DATAFILE '/u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dggwj0_.dbf' RESIZE 10M*ERROR at line 1:ORA-38883: Cannot shrink data file /u02/oradata/ORCLDG/datafile/o1_mf_tbs_10m__m5dggwj0_.dbf on primary database due to guaranteed restore points.SQL>
Por fim vou voltar o snapshot standby para um standby físico através do SQL
SQL> SHUTDOWN IMMEDIATEORA-01109: database not openDatabase dismounted.ORACLE instance shut down.SQL> STARTUP MOUNTORACLE instance started.Total System Global Area 1426059984 bytesFixed Size 9134800 bytesVariable Size 352321536 bytesDatabase Buffers 1056964608 bytesRedo Buffers 7639040 bytesDatabase mounted.SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;Database altered.SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;Database altered.SQL> Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - ProductionVersion 19.3.0.0.0[oracle@ol7-dg trace]$ dgmgrl sys/oracle@orclDGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue May 28 17:53:00 2024Version 19.3.0.0.0Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.Welcome to DGMGRL, type "help" for information.Connected to "orcl"Connected as SYSDBA.DGMGRL> ENABLE CONFIGURATION;Enabled.
Assim nossa configuração já estará normalizada
DGMGRL> ENABLE CONFIGURATION;Enabled.DGMGRL> show configuration;Configuration - dg Protection Mode: MaxPerformance Members: orcl - Primary database orcldg - Physical standby databaseFast-Start Failover: DisabledConfiguration Status:SUCCESS (status updated 38 seconds ago)DGMGRL>
Consigo verificar também que a tablespace TESTE criada no meu snapshot standby não estará aparecendo no meu banco primário
SQL> SELECT TABLESPACE_NAME FROM DBA_TABLESPACES;TABLESPACE_NAME------------------------------SYSTEMSYSAUXUNDOTBS1TEMPUSERSTBS_10M_PRIM6 rows selected.SQL> SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE;OPEN_MODE DATABASE_ROLE-------------------- ----------------READ WRITE PRIMARYSQL>