De acordo a nossa querida documentação, em um Dataguard configurado em MaxProtection não permite o Primary Database continuar o processamento se o Standby Database falhar.

maximum protection shuts the primary database down rather than allowing it to continue processing transactions that are unprotected

Definição completa aqui.

Mas o que acontece se deliberamente emitimos um shutdown immediate no Standby Database ?

Vamos testar esse cenário em laboratório.

Aqui eu tenho um Dataguard com replicação física no Oracle 12.1.0.2, tendo uma instância Far Sync ali no meio só pra deixar mais interessante.

[oracle@lab01 ~]$ dgmgrl /
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected as SYSDG.
DGMGRL> show configuration;

Configuration - dg1_conf

  Protection Mode: MaxAvailability
  Members:
  prod    - Primary database
    stdb    - Physical standby database
    prod_fs - Far sync instance

Fast-Start Failover: DISABLED

Como atualmente a configuração está em MaxAvailability, vamos colocar em MaxProtection. Note que se você for testar, o comando abaixo pode gerar alguns erros se você não preencher todos os requisitos para habilitar o MaxPotection.

DGMGRL> edit configuration set protection mode as MaxProtection;
Succeeded.

Agora vamos ao SQLPLUS na nossa instância standby no servidor lab02:

[oracle@lab02 trace]$ . oraenv
 ORACLE_SID = [stdb] ?
 The Oracle base remains unchanged with value /u01/app/oracle

 [oracle@lab02 trace]$ sqlplus / as sysdba
 SQL*Plus: Release 12.1.0.2.0 Production on Wed Jan 13 22:47:49 2021
 Copyright (c) 1982, 2014, Oracle.  All rights reserved.
 Connected to:
 Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
 With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
 SQL> shutdown immediate;
 ORA-01154: database busy. Open, close, mount, and dismount not allowed now

Olha só que maravilha, ele não deixou mesmo.

Mensagem destacada:

 ORA-01154: database busy. Open, close, mount, and dismount not allowed now

Vamos ver o que ele colocou no alert log:

Wed Jan 13 22:48:36 2021
 Attempt to shut down Standby Database
 Standby Database operating in NO DATA LOSS mode
 Detected primary database alive, shutdown primary first, shutdown aborted
 Wed Jan 13 22:51:46 2021
 Attempt to shut down Standby Database
 Standby Database operating in NO DATA LOSS mode
 Detected primary database alive, shutdown primary first, shutdown aborted

Aqui a regra é clara: “Standby Database operating in NO DATA LOSS mode”, MaxProtection é a configuração que não permite perda de dados, é preferível parar a produção do que perder uma única transação, conforme a documentação citada anteriormente.

Nesse cenário, o Oracle simplesmente barrou a nossa tentativa, no alert log do Primary Database não é gravado nada.

E se for um shutdown abort ?

Vamos testar algo mais interessante, um shutdown abort:

SQL> shutdown immediate;
 ORA-01154: database busy. Open, close, mount, and dismount not allowed now
 SQL> shutdown abort;
 ORACLE instance shut down.

Olha só, ao abort ninguém resiste. Vamos ver o que aconteceu com nosso Primary Database.

Error 1034 received logging on to the standby
Wed Jan 13 23:02:13 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:18 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:18 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:23 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:23 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:28 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:28 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:33 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:33 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:38 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:38 2021
Errors in file /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_arc1_3427.trc:
ORA-01034: ORACLE not available
PING[ARC1]: Heartbeat failed to connect to standby 'stdb'. Error is 1034.
Wed Jan 13 23:02:38 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:38 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:44 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:44 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:49 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:49 2021
LGWR: Error 1034 attaching to RFS for reconnect
Wed Jan 13 23:02:54 2021
Error 1034 received logging on to the standby
Wed Jan 13 23:02:54 2021
LGWR: Error 1034 attaching to RFS for reconnect

Vamos tentar conectar no banco:

[oracle@lab02 ~]$ sqlplus maicon/dibiei@prod
 SQL*Plus: Release 12.1.0.2.0 Production on Wed Jan 13 23:02:51 2021
 Copyright (c) 1982, 2014, Oracle.  All rights reserved.
 ^C^C^C^C^C^C^C^C^C^X

Travado. Até aqui ele não caiu, mas também não conseguimos nem acessar.

Esperamos mais um pouco e o Primary Database também é abortado com a seguinte mensagem no alert log:

LGWR: All standby destinations have failed
 
 WARN: All standby database destinations have failed
 WARN: Instance shutdown required to protect primary
 
 LGWR (ospid: 3352): terminating the instance due to error 16098
 Wed Jan 13 23:05:48 2021
 System state dump requested by (instance=1, osid=3352 (LGWR)), summary=[abnormal instance termination].
 System State dumped to trace file /u01/app/oracle/diag/rdbms/prod/prod/trace/prod_diag_3342_20210113230548.trc
 Wed Jan 13 23:05:48 2021
 ORA-1092 : opitsk aborting process
 Wed Jan 13 23:05:49 2021
 Dumping diagnostic data in directory=[cdmp_20210113230548], requested by (instance=1, osid=3352 (LGWR)), summary=[abnormal instance termination].
 Wed Jan 13 23:05:49 2021
 Instance terminated by LGWR, pid = 3352