Configurando o Oracle 26ai para Data Guard – Parte 1

Quem já montou um Oracle Data Guard se identifica com o procedimento: abre o bloco de notas, que contém o passo a passo da configuração do banco primário, faz o DUPLICATE, na sequência configura o standby, e adiciona tudo ao DG Broker.

Bom, temos boas novas no 26ai: agora o DGMGRL conta com um novo comando, o PREPARE DATABASE FOR DATA GUARD, que nos ajuda com a configuração do banco primário e do standby, e vai eliminar alguns dos passos do nosso antigo fluxo. Nessa parte 1, vou falar o que muda na configuração do banco primário. Já deixa seu procedimento aí do lado, pra atualizar pra versão 26ai!

Cenário

Eu recentemente instalei o Oracle Database 26ai gerenciado pelo Oracle Restart no VirtualBox. O banco de dados está com todas as configurações padrão, ou seja, está em modo NOARCHIVELOG, Flashback Database desabilitado, FORCE LOGGING não habilitado, retenção de flashback default, dg_broker desabilitado, três grupos de Online Redo Log (OLRs) e sem Standby Redo Logs (SRLs):

SQL> select log_mode, flashback_on, force_logging from v$database;

LOG_MODE     FLASHBACK_ON       FORCE_LOGGING
------------ ------------------ ---------------------------------------
ARCHIVELOG   NO                 NO

SQL> show parameter dg_broker

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
dg_broker_config_file1               string      /u01/app/oracle/product/26.23.
                                                 1/dbhome_1/dbs/dr1orcl.dat
dg_broker_config_file2               string      /u01/app/oracle/product/26.23.
                                                 1/dbhome_1/dbs/dr2orcl.dat
dg_broker_start                      boolean     FALSE

SQL> show parameter flashback

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_log_dest                string
db_flashback_log_dest_size           big integer 0
db_flashback_retention_target        integer     1440

SQL> set lines window
set pages 10000
select thread#, group#, sequence#, archived, status, bytes/1024/1024 "Tamanho MB" from v$log;

   THREAD#     GROUP#  SEQUENCE# ARC STATUS           Tamanho MB
---------- ---------- ---------- --- ---------------- ----------
         1          1          7 YES INACTIVE                200
         1          2          8 YES INACTIVE                200
         1          3          9 NO  CURRENT                 200

SQL> set lines window
set pages 10000
select group#, sequence#, thread#, archived, status, bytes/1024/1024 "Tamanho MB" from v$standby_log;

no rows selected

O há de novo?

Bom na versão 26ai, o DGMGRL tem um novo comando: o PREPARE DATABASE FOR DATA GUARD. Ele automatiza muita coisa, com algumas ressalvas, que vou explicar mais tarde. A sintaxe básica dele é:

PREPARE DATABASE FOR DATA GUARD 
[WITH DB_UNIQUE_NAME IS <db_unique_name>] 
[DB_RECOVERY_FILE_DEST IS <directory_location>]  
[DB_RECOVERY_FILE_DEST_SIZE is <size>] 
[BROKER_CONFIG_FILE_1 IS <broker_config_file_1_location>] 
[BROKER_CONFIG_FILE_2 IS <broker_config_file_2_location>] 
[RESTART] 
[no_srl]; 

Basicamente, com esse comando é possível configurar todos esses parâmetros do banco de dados diretamente através do DG Broker. Porém, esse comando vai além. Ele também:

  • Adiciona os Standby Redo Logs caso eles não existam, ou caso estejam configurados incorretamente, os recria;
  • Habilita o Archivelog, o Flashback e o Force Logging;
  • Se for um ambiente single instance iniciado pelo PFILE, ele usa os valores em memória dos parâmetros, e cria um SPFILE;
  • Seta a política de deleção de archive logs para SHIPPED TO ALL STANDBY;
  • Seta os seguintes parâmetros de inicialização:
    • DB_FILES=1024
    • LOG_BUFFER=256M
    • DB_BLOCK_CHECKSUM=TYPICAL (se configurado com um valor diferente de FULL)
    • DB_LOST_WRITE_PROTECT=TYPICAL (se configurado com um valor diferente de FULL)
    • DB_FLASHBACK_RETENTION_TARGET=120 (se configurado com o valor default, caso contrário não altera)
    • PARALLEL_THREADS_PER_CPU=1
    • DG_BROKER_START=TRUE

Executando o comando

Já na primeira tentativa, tomei um erro:

$ dgmgrl /
DGMGRL for Linux: Release 23.26.1.0.0 - Production on Wed Mar 4 20:28:25 2026
Version 23.26.1.0.0

Copyright (c) 1982, 2026, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "orcl"
Connected as SYSDG.
DGMGRL> PREPARE DATABASE FOR DATA GUARD
> WITH DB_UNIQUE_NAME IS orcl
> DB_RECOVERY_FILE_DEST IS "+RECO"
> DB_RECOVERY_FILE_DEST_SIZE IS "9G"
> BROKER_CONFIG_FILE_1 IS "+DATA/dr1orcl.dat"
> BROKER_CONFIG_FILE_2 IS "+RECO/dr2orcl.dat"
> RESTART;

ORA-1031: insufficient privileges

Aqui, como estou passando a opção RESTART, para reiniciar o banco e alterar os parâmetros estáticos alterados, é necessário conectar ao DGMGRL com SYSDBA ou SYSDG. Outro detalhe importante é que se você tentar logar com um serviço não estático, o erro abaixo é retornado:

$ dgmgrl sys@orcl
DGMGRL for Linux: Release 23.26.1.0.0 - Production on Wed Mar 4 20:35:13 2026
Version 23.26.1.0.0

Copyright (c) 1982, 2026, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Password:
Connected to "orcl"
Connected as SYSDBA.
DGMGRL>
DGMGRL>
DGMGRL> PREPARE DATABASE FOR DATA GUARD
> WITH DB_UNIQUE_NAME IS orcl
> DB_RECOVERY_FILE_DEST IS "+RECO"
> DB_RECOVERY_FILE_DEST_SIZE IS "9G"
> BROKER_CONFIG_FILE_1 IS "+DATA/dr1orcl.dat"
> BROKER_CONFIG_FILE_2 IS "+RECO/dr2orcl.dat"
> RESTART;

Validating database "orcl" before executing the command.
  DGM-17297: This command requires a bequeath connection or a connect identifier that specifies a static service name.
Failed.

Então lembre-se de usar o serviço estático ou a conexão bequeath, junto com SYSDBA ou SYSDG:

$ dgmgrl / as sysdba
DGMGRL for Linux: Release 23.26.1.0.0 - Production on Wed Mar 4 20:35:46 2026
Version 23.26.1.0.0

Copyright (c) 1982, 2026, Oracle and/or its affiliates.  All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "orcl"
Connected as SYSDBA.
DGMGRL>
DGMGRL> PREPARE DATABASE FOR DATA GUARD
> WITH DB_UNIQUE_NAME IS orcl
> DB_RECOVERY_FILE_DEST IS "+RECO"
> DB_RECOVERY_FILE_DEST_SIZE IS "9G"
> BROKER_CONFIG_FILE_1 IS "+DATA/dr1orcl.dat"
> BROKER_CONFIG_FILE_2 IS "+RECO/dr2orcl.dat"
> RESTART;

Validating database "orcl" before executing the command.
Preparing database "orcl" for Data Guard.
Initialization parameter DB_FILES set to 1024.
Initialization parameter LOG_BUFFER set to 268435456.
Database must be restarted after setting static initialization parameters.
Shutting down database "orcl".
Database closed.
Database dismounted.
ORACLE instance shut down.
Starting database "orcl" to mounted mode.
ORACLE instance started.
Database mounted.
Initialization parameter DB_LOST_WRITE_PROTECT set to 'TYPICAL'.
RMAN ARCHIVELOG deletion policy set to TO SHIPPED TO ALL STANDBY.
Initialization parameter DB_RECOVERY_FILE_DEST_SIZE set to '9G'.
Initialization parameter DB_RECOVERY_FILE_DEST set to '+RECO'.
Initialization parameter DG_BROKER_CONFIG_FILE1 set to '+DATA/dr1orcl.dat'.
Initialization parameter DG_BROKER_CONFIG_FILE2 set to '+RECO/dr2orcl.dat'.
LOG_ARCHIVE_DEST_n initialization parameter already set for local archival.
Adding standby log group size 209715200 and assigning it to thread 1.
Adding standby log group size 209715200 and assigning it to thread 1.
Adding standby log group size 209715200 and assigning it to thread 1.
Initialization parameter STANDBY_FILE_MANAGEMENT set to 'AUTO'.
Initialization parameter DG_BROKER_START set to TRUE.
Force logging mode enabled.
Flashback Database enabled.
Database opened.
Succeeded.

Analisando as alterações

Executado o comando, vamos às validações:

SQL> select log_mode, flashback_on, force_logging from v$database;

LOG_MODE     FLASHBACK_ON       FORCE_LOGGING
------------ ------------------ ---------------------------------------
ARCHIVELOG   YES                YES

SQL> show parameter flashback

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_flashback_log_dest                string
db_flashback_log_dest_size           big integer 0
db_flashback_retention_target        integer     1440

SQL> show parameter db_reco

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_auto_rekey               string      ON
db_recovery_file_dest                string      +RECO
db_recovery_file_dest_size           big integer 9G

SQL> show parameter dg_broker

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
dg_broker_config_file1               string      +DATA/dr1orcl.dat
dg_broker_config_file2               string      +RECO/dr2orcl.dat
dg_broker_start                      boolean     TRUE

SQL> set lines window
set pages 10000
select group#, sequence#, thread#, archived, status, bytes/1024/1024 "Tamanho MB" from v$standby_log;

    GROUP#  SEQUENCE#    THREAD# ARC STATUS     Tamanho MB
---------- ---------- ---------- --- ---------- ----------
         4          0          1 YES UNASSIGNED        200
         5          0          1 YES UNASSIGNED        200
         6          0          1 YES UNASSIGNED        200

SQL> set lines window
set pages 10000
select thread#, group#, sequence#, archived, status, bytes/1024/1024 "Tamanho MB" from v$log;

   THREAD#     GROUP#  SEQUENCE# ARC STATUS           Tamanho MB
---------- ---------- ---------- --- ---------------- ----------
         1          1          4 NO  CURRENT                 200
         1          2          2 YES INACTIVE                200
         1          3          3 YES INACTIVE                200

$ rman target /

Recovery Manager: Release 23.26.1.0.0 - Production on Wed Mar 4 22:03:42 2026
Version 23.26.1.0.0

Copyright (c) 1982, 2026, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ORCL (DBID=1753635689)

RMAN> show all;
show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES256'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/26.23.1/dbhome_1/dbs/snapcf_orcl.f'; # default

Bom, primeiro vamos aos pontos que deram certo: Force Logging, Flashback, Archivelog e DG Broker habilitados, caminhos dos arquivos de configuração do DG Broker atualizados, política de deleção de archive logs alterada para SHIPPED TO ALL STANDBY no RMAN e SRLs criados.

Três pontos de atenção aqui: no meu teste a retenção dos flashback logs que estava no valor default de 1440 minutos não foi alterada para 120 minutos, conforme a documentação do comando sugere que ele faria. Então esse é uma configuração que precisa ser revisada ao executar essa preparação do banco primário.

O segundo ponto é que o modo Froce Logging pode não ser o adequeado para todos os cenários, portanto deve ser configurado de acordo.

Outro detalhe que me chamou a atenção e que inicialmente pensei se tratar de uma falha, foi que o PREPARE DATABASE FOR DATA GUARD criou apenas três SRLs no banco. Como eu tinha três ORLs inicialmente, esperava que ele seguisse a regra que diz que devemos ter um SRL a mais em relação aos OLRs. Bom, pesquisando um pouco, encontrei o detalhe: na versão 19c, realmente essa recomendação existe, conforme mostra a doc:

Já na documentação da 26ai, temos:

Ou seja, a documentação da nova versão nos diz que devemos ter um número igual ou superior de SRLs em relação aos OLRs.

Antes de dizer se podemos manter essa configuração assim ou não, precisamos entender o porquê desse SRL a mais: toda vez que o banco primário realiza um switch log file, o standby também passa a escrever o redo recebido em um novo SRL. Temos um problema se o SRL onde o standby deve escrever após um switch log file do banco primário estiver cheio, e ainda não houver sido arquivado, gerando um wait event do tipo log file switch completion.

Ou seja, esse SRL adicional não se faz necessário em ambientes que conseguem arquivar os SRLs antes que ele seja necessário para receber o redo gerado pelo banco primário.

Vou colocar num cenário fictício aqui, pra ilustrar melhor. Vamos considerar que temos 3 SRLs de 10GB cada, e que o banco de dados segue o padrão ideal da Oracle, de 5 log switches por hora:

Nesse cenário, o SRL passa a ser escrito novamente após 24 minutos. Ou seja, ele precisa ser arquivado em menos de 24 minutos, para que não tenhamos que esperar para escrever nesse SRL. Para calcular throughput mínimo necessário desse archiving, teríamos:

Ou seja, precisamos de um throughput superior a 7,11 MB/s para não termos contenção para esse caso, uma taxa que HDDs SAS enterprise conseguem suprir tranquilamente. Obviamente, que é necessário analisar o ambiente como um todo, se existem outras operações de escritas intensivas sendo realizadas no mesmo disco, por exemplo.

Enfim, voltando ao ponto dos SRLs, ainda podemos utilizar a regra antiga, adicionando um SRL a mais em relação aos OLRs, mas tendo em mente que não é algo “escrito em pedra”.

Conclusão

Para fechar então: no meu ponto de vista, essa é uma adição muito bem vinda e que vai eliminar alguns passos manuais da preparação do banco primário para a criação da configuração Data Guard, mesmo com os pontos de atenção em relação à retenção dos flashback logs, o Force Logging e o número de SRLs criados pelo broker.

A documentação do novo comando segue abaixo:

Na parte 2, vou trazer a execução do comando no standby. Stay tuned!

Publicar comentário