O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

TR-4981: Redução de custos do Oracle Active Data Guard com Amazon FSx ONTAP

08/18/2025 Colaboradores

PDFs

Allen Cao, Niyaz Mohamed, NetApp

Esta solução fornece uma visão geral e detalhes para configurar o Oracle Data Guard usando o AWS FSx ONTAP como armazenamento de banco de dados Oracle em site standby para reduzir o licenciamento e o custo operacional da solução Oracle Data Guard HA/DR na AWS.

Propósito

O Oracle Data Guard garante alta disponibilidade, proteção de dados e recuperação de desastres para dados corporativos em uma configuração de replicação de banco de dados primário e banco de dados standby. O Oracle Active Data Guard permite que os usuários acessem bancos de dados standby enquanto a replicação de dados está ativa do banco de dados principal para os bancos de dados standby. O Data Guard é um recurso do Oracle Database Enterprise Edition. Não requer licenciamento separado. Por outro lado, o Active Data Guard é uma opção do Oracle Database Enterprise Edition, portanto, requer uma licença separada. Vários bancos de dados em espera podem receber replicação de dados de um banco de dados primário na configuração do Active Data Guard. No entanto, cada banco de dados de espera adicional requer uma licença do Active Data Guard e armazenamento extra, conforme o tamanho do banco de dados primário. Os custos operacionais aumentam rapidamente.

Se você deseja reduzir os custos da operação do seu banco de dados Oracle e planeja configurar um Active Data Guard na AWS, considere uma alternativa. Em vez do Active Data Guard, use o Data Guard para replicar do banco de dados primário para um único banco de dados de espera físico no armazenamento Amazon FSx ONTAP . Posteriormente, várias cópias desse banco de dados standby podem ser clonadas e abertas para acesso de leitura/gravação para atender a muitos outros casos de uso, como relatórios, desenvolvimento, testes etc. Os resultados líquidos efetivamente fornecem funcionalidades do Active Data Guard, ao mesmo tempo em que eliminam a licença do Active Data Guard e o custo extra de armazenamento para cada banco de dados standby adicional. Nesta documentação, demonstramos como configurar um Oracle Data Guard com seu banco de dados primário existente na AWS e colocar o banco de dados standby físico no armazenamento Amazon FSx ONTAP . O banco de dados em espera é copiado por meio de snapshot e clonado para acesso de leitura/gravação para casos de uso conforme desejado.

Esta solução aborda os seguintes casos de uso:

Oracle Data Guard entre um banco de dados primário em qualquer armazenamento na AWS e um banco de dados standby no armazenamento Amazon FSx ONTAP .
Clone o banco de dados em espera enquanto estiver fechado para replicação de dados para atender a casos de uso como relatórios, desenvolvimento, teste, etc.

Público

Esta solução é destinada às seguintes pessoas:

Um DBA que configurou o Oracle Active Data Guard na AWS para alta disponibilidade, proteção de dados e recuperação de desastres.
Um arquiteto de soluções de banco de dados interessado na configuração do Oracle Active Data Guard na nuvem AWS.
Um administrador de armazenamento que gerencia o armazenamento AWS FSx ONTAP compatível com o Oracle Data Guard.
Um proprietário de aplicativo que gosta de instalar o Oracle Data Guard no ambiente AWS FSx/EC2.

Ambiente de teste e validação de soluções

O teste e a validação desta solução foram realizados em um ambiente de laboratório AWS FSx ONTAP e EC2 que pode não corresponder ao ambiente de implantação final. Para mais informações, consulte a seção Fatores-chave para consideração de implantação .

Arquitetura

Esta imagem fornece uma visão detalhada da implementação do Oracle Data Guard na AWS com FSx ONTAP.

Componentes de hardware e software

Hardware

Armazenamento FSx ONTAP

Versão atual oferecida pela AWS

Um cluster FSx HA na mesma VPC e zona de disponibilidade

Instância EC2 para computação

t2.xlarge/4vCPU/16G

Três instâncias EC2 T2 xlarge EC2, uma como servidor de banco de dados primário, uma como servidor de banco de dados em espera e a terceira como servidor de banco de dados clone

Software

RedHat Linux

RHEL-8.6.0_HVM-20220503-x86_64-2-Hora2-GP2

Assinatura RedHat implantada para teste

Infraestrutura de grade Oracle

Versão 19.18

Patch RU aplicado p34762026_190000_Linux-x86-64.zip

Banco de Dados Oracle

Versão 19.18

Patch RU aplicado p34765931_190000_Linux-x86-64.zip

Oracle OPatch

Versão 12.2.0.1.36

Último patch p6880880_190000_Linux-x86-64.zip

Configuração do Oracle Data Guard com configuração hipotética de NY para LA DR

Banco de dados

DB_UNIQUE_NAME

Nome do serviço Oracle Net

Primário

db1_NY

db1_NY.demo.netapp.com

Standby físico

db1_LA

db1_LA.demo.netapp.com

Fatores-chave para consideração de implantação

Como funciona o Oracle Standby Database FlexClone . O AWS FSx ONTAP FlexClone fornece cópias compartilhadas dos mesmos volumes de banco de dados em espera que são graváveis. As cópias dos volumes são, na verdade, ponteiros que fazem o link de volta aos blocos de dados originais até que uma nova gravação seja iniciada no clone. O ONTAP então aloca novos blocos de armazenamento para as novas gravações. Quaisquer E/S de leitura são atendidas por blocos de dados originais sob replicação ativa. Dessa forma, o clone é muito eficiente em termos de armazenamento e pode ser usado para muitos outros casos de uso com alocação mínima e incremental de novo armazenamento para novas E/S de gravação. Isso proporciona uma tremenda economia de custos de armazenamento ao reduzir substancialmente o espaço de armazenamento do Active Data Guard. A NetApp recomenda minimizar as atividades do FlexClone no caso de troca do banco de dados do armazenamento primário para o armazenamento FSx de espera, a fim de manter o desempenho do Oracle em alto nível.
Requisitos de software Oracle. Em geral, um banco de dados standby físico deve ter a mesma versão do Database Home que o banco de dados primário, incluindo Patch Set Exceptions (PSEs), Critical Patch Updates (CPUs) e Patch Set Updates (PSUs), a menos que um processo Oracle Data Guard Standby-First Patch Apply esteja em andamento (conforme descrito na nota 1265700.1 do My Oracle Support em"support.oracle.com"
Considerações sobre a estrutura do diretório do banco de dados em espera. Se possível, os arquivos de dados, arquivos de log e arquivos de controle nos sistemas primário e de espera devem ter os mesmos nomes e nomes de caminho e usar convenções de nomenclatura da Arquitetura Flexível Ótima (OFA). Os diretórios de arquivamento no banco de dados de espera também devem ser idênticos entre os sites, incluindo tamanho e estrutura. Essa estratégia permite que outras operações, como backups, alternâncias e failovers, executem o mesmo conjunto de etapas, reduzindo a complexidade da manutenção.
Modo de registro forçado. Para proteger contra gravações diretas não registradas no banco de dados primário que não podem ser propagadas para o banco de dados em espera, ative FORÇAR REGISTRO no banco de dados primário antes de executar backups de arquivos de dados para criação em espera.
Gerenciamento de armazenamento de banco de dados. Para simplificar a operação, a Oracle recomenda que, ao configurar o Oracle Automatic Storage Management (Oracle ASM) e o Oracle Managed Files (OMF) em uma configuração do Oracle Data Guard, você os configure simetricamente nos bancos de dados primário e em espera.
Instâncias de computação do EC2. Nesses testes e validações, usamos uma instância t2.xlarge do AWS EC2 como instância de computação do banco de dados Oracle. A NetApp recomenda usar uma instância EC2 do tipo M5 como instância de computação para Oracle na implantação de produção porque ela é otimizada para carga de trabalho de banco de dados. Você precisa dimensionar a instância do EC2 adequadamente para o número de vCPUs e a quantidade de RAM com base nos requisitos reais da carga de trabalho.
Implantação de clusters de HA de armazenamento FSx em uma ou várias zonas. Nesses testes e validações, implantamos um cluster FSx HA em uma única zona de disponibilidade da AWS. Para implantação de produção, a NetApp recomenda implantar um par FSx HA em duas zonas de disponibilidade diferentes. Um cluster FSx é sempre provisionado em um par de HA que é espelhado de forma sincronizada em um par de sistemas de arquivos ativos-passivos para fornecer redundância em nível de armazenamento. A implantação em várias zonas aumenta ainda mais a alta disponibilidade em caso de falha em uma única zona da AWS.
Dimensionamento do cluster de armazenamento FSx. Um sistema de arquivos de armazenamento Amazon FSx ONTAP fornece até 160.000 IOPS SSD brutos, taxa de transferência de até 4 GBps e capacidade máxima de 192 TiB. No entanto, você pode dimensionar o cluster em termos de IOPS provisionados, taxa de transferência e limite de armazenamento (mínimo de 1.024 GiB) com base nos seus requisitos reais no momento da implantação. A capacidade pode ser ajustada dinamicamente sem afetar a disponibilidade do aplicativo.

Implantação da solução

Supõe-se que você já tenha seu banco de dados Oracle primário implantado no ambiente AWS EC2 dentro de uma VPC como ponto de partida para configurar o Data Guard. O banco de dados principal é implantado usando o Oracle ASM para gerenciamento de armazenamento. Dois grupos de discos ASM - +DATA e +LOGS - são criados para arquivos de dados, arquivos de log, arquivos de controle etc. do Oracle. Para obter detalhes sobre a implantação do Oracle na AWS com ASM, consulte os seguintes relatórios técnicos para obter ajuda.

Seu banco de dados Oracle principal pode ser executado em um FSx ONTAP ou em qualquer outro armazenamento de opções dentro do ecossistema AWS EC2. A seção a seguir fornece procedimentos de implantação passo a passo para configurar o Oracle Data Guard entre uma instância de banco de dados EC2 primária com armazenamento ASM para uma instância de banco de dados EC2 em espera com armazenamento ASM.

Pré-requisitos para implantação

Details

A implantação requer os seguintes pré-requisitos.

Uma conta da AWS foi configurada e os segmentos de VPC e rede necessários foram criados dentro da sua conta da AWS.
No console do AWS EC2, você precisa implantar no mínimo três instâncias do EC2 Linux, uma como instância primária do Oracle DB, uma como instância de standby do Oracle DB e uma instância de destino do clone do DB para relatórios, desenvolvimento, testes etc. Consulte o diagrama de arquitetura na seção anterior para obter mais detalhes sobre a configuração do ambiente. Revise também a AWS"Guia do usuário para instâncias Linux" para maiores informações.
No console do AWS EC2, implante clusters de HA de armazenamento do Amazon FSx ONTAP para hospedar volumes Oracle que armazenam o banco de dados Oracle standby. Se você não estiver familiarizado com a implantação do armazenamento FSx, consulte a documentação"Criação de sistemas de arquivos FSx ONTAP" para obter instruções passo a passo.
As etapas 2 e 3 podem ser executadas usando o seguinte kit de ferramentas de automação do Terraform, que cria uma instância EC2 denominada ora_01 e um sistema de arquivos FSx chamado fsx_01 . Revise as instruções cuidadosamente e altere as variáveis para adequá-las ao seu ambiente antes da execução. O modelo pode ser facilmente revisado para atender às suas próprias necessidades de implantação.
```
git clone https://github.com/NetApp-Automation/na_aws_fsx_ec2_deploy.git
```

Certifique-se de ter alocado pelo menos 50 GB no volume raiz da instância do EC2 para ter espaço suficiente para preparar os arquivos de instalação do Oracle.

Preparar o banco de dados primário para o Data Guard

Details

Nesta demonstração, configuramos um banco de dados Oracle primário chamado db1 na instância primária do EC2 DB com dois grupos de discos ASM na configuração de reinicialização autônoma com arquivos de dados no grupo de discos ASM +DATA e área de recuperação flash no grupo de discos ASM +LOGS. A seguir são ilustrados os procedimentos detalhados para configurar o banco de dados primário para o Data Guard. Todas as etapas devem ser executadas como proprietário do banco de dados - usuário Oracle.

Configuração do banco de dados primário db1 na instância primária do EC2 DB ip-172-30-15-45. Os grupos de discos ASM podem estar em qualquer tipo de armazenamento dentro do ecossistema EC2.

[oracle@ip-172-30-15-45 ~]$ cat /etc/oratab

# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by either Database Configuration Assistant while creating
# a database or ASM Configuration Assistant while creating ASM instance.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third field indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
+ASM:/u01/app/oracle/product/19.0.0/grid:N
db1:/u01/app/oracle/product/19.0.0/db1:N

[oracle@ip-172-30-15-45 ~]$ /u01/app/oracle/product/19.0.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
               ONLINE  ONLINE       ip-172-30-15-45          STABLE
ora.LISTENER.lsnr
               ONLINE  ONLINE       ip-172-30-15-45          STABLE
ora.LOGS.dg
               ONLINE  ONLINE       ip-172-30-15-45          STABLE
ora.asm
               ONLINE  ONLINE       ip-172-30-15-45          Started,STABLE
ora.ons
               OFFLINE OFFLINE      ip-172-30-15-45          STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
      1        ONLINE  ONLINE       ip-172-30-15-45          STABLE
ora.db1.db
      1        ONLINE  ONLINE       ip-172-30-15-45          Open,HOME=/u01/app/o
                                                             racle/product/19.0.0
                                                             /db1,STABLE
ora.diskmon
      1        OFFLINE OFFLINE                               STABLE
ora.driver.afd
      1        ONLINE  ONLINE       ip-172-30-15-45          STABLE
ora.evmd
      1        ONLINE  ONLINE       ip-172-30-15-45          STABLE
--------------------------------------------------------------------------------

No sqlplus, habilite o registro forçado no primário.
```
alter database force logging;
```
No sqlplus, habilite o flashback no primário. O Flashback permite restabelecer facilmente o banco de dados primário como um standby após um failover.
```
alter database flashback on;
```
Configure a autenticação de transporte de refazer usando o arquivo de senha do Oracle - crie um arquivo pwd no primário usando o utilitário orapwd, se não estiver definido, e copie para o diretório $ORACLE_HOME/dbs do banco de dados standby.

Crie logs de refazer em espera no banco de dados principal com o mesmo tamanho do arquivo de log on-line atual. Os grupos de log são mais um que os grupos de arquivos de log on-line. O banco de dados primário pode então transitar rapidamente para a função de espera e começar a receber dados de repetição, se necessário.

alter database add standby logfile thread 1 size 200M;

Validate after standby logs addition:

SQL> select group#, type, member from v$logfile;

    GROUP# TYPE    MEMBER
---------- ------- ------------------------------------------------------------
         3 ONLINE  +DATA/DB1/ONLINELOG/group_3.264.1145821513
         2 ONLINE  +DATA/DB1/ONLINELOG/group_2.263.1145821513
         1 ONLINE  +DATA/DB1/ONLINELOG/group_1.262.1145821513
         4 STANDBY +DATA/DB1/ONLINELOG/group_4.286.1146082751
         4 STANDBY +LOGS/DB1/ONLINELOG/group_4.258.1146082753
         5 STANDBY +DATA/DB1/ONLINELOG/group_5.287.1146082819
         5 STANDBY +LOGS/DB1/ONLINELOG/group_5.260.1146082821
         6 STANDBY +DATA/DB1/ONLINELOG/group_6.288.1146082825
         6 STANDBY +LOGS/DB1/ONLINELOG/group_6.261.1146082827
         7 STANDBY +DATA/DB1/ONLINELOG/group_7.289.1146082835
         7 STANDBY +LOGS/DB1/ONLINELOG/group_7.262.1146082835

11 rows selected.

No sqlplus, crie um pfile a partir do spfile para edição.
```
create pfile='/home/oracle/initdb1.ora' from spfile;
```

Revise o pfile e adicione os seguintes parâmetros.

DB_NAME=db1
DB_UNIQUE_NAME=db1_NY
LOG_ARCHIVE_CONFIG='DG_CONFIG=(db1_NY,db1_LA)'
LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db1_NY'
LOG_ARCHIVE_DEST_2='SERVICE=db1_LA ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db1_LA'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
FAL_SERVER=db1_LA
STANDBY_FILE_MANAGEMENT=AUTO

No sqlplus, crie um spfile no diretório ASM +DATA a partir do pfile revisado no diretório /home/oracle.
```
create spfile='+DATA' from pfile='/home/oracle/initdb1.ora';
```

Localize o spfile recém-criado no grupo de discos +DATA (usando o utilitário asmcmd, se necessário). Use srvctl para modificar a grade para iniciar o banco de dados a partir do novo spfile, conforme mostrado abaixo.

[oracle@ip-172-30-15-45 db1]$ srvctl config database -d db1
Database unique name: db1
Database name: db1
Oracle home: /u01/app/oracle/product/19.0.0/db1
Oracle user: oracle
Spfile: +DATA/DB1/PARAMETERFILE/spfile.270.1145822903
Password file:
Domain: demo.netapp.com
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
Services:
OSDBA group:
OSOPER group:
Database instance: db1
[oracle@ip-172-30-15-45 db1]$ srvctl modify database -d db1 -spfile +DATA/DB1/PARAMETERFILE/spfiledb1.ora
[oracle@ip-172-30-15-45 db1]$ srvctl config database -d db1
Database unique name: db1
Database name: db1
Oracle home: /u01/app/oracle/product/19.0.0/db1
Oracle user: oracle
Spfile: +DATA/DB1/PARAMETERFILE/spfiledb1.ora
Password file:
Domain: demo.netapp.com
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Disk Groups: DATA
Services:
OSDBA group:
OSOPER group:
Database instance: db1

Modifique tnsnames.ora para adicionar db_unique_name para resolução de nomes.

# tnsnames.ora Network Configuration File: /u01/app/oracle/product/19.0.0/db1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

db1_NY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = db1)
    )
  )

db1_LA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-67.ec2.internal)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = db1)
    )
  )

LISTENER_DB1 =
  (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521))

Adicione o nome do serviço de proteção de dados db1_NY_DGMGRL.demo.netapp para o banco de dados primário no arquivo listener.ora.

#Backup file is  /u01/app/oracle/crsdata/ip-172-30-15-45/output/listener.ora.bak.ip-172-30-15-45.oracle line added by Agent
# listener.ora Network Configuration File: /u01/app/oracle/product/19.0.0/grid/network/admin/listener.ora
# Generated by Oracle configuration tools.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = db1_NY_DGMGRL.demo.netapp.com)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/db1)
      (SID_NAME = db1)
    )
  )

ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON              # line added by Agent
VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON            # line added by Agent

Desligue e reinicie o banco de dados com srvctl e valide se os parâmetros do Data Guard agora estão ativos.
```
srvctl stop database -d db1
```
```
srvctl start database -d db1
```

Isso conclui a configuração primária do banco de dados para o Data Guard.

Preparar o banco de dados standby e ativar o Data Guard

Details

O Oracle Data Guard requer configuração do kernel do sistema operacional e pilhas de software Oracle, incluindo conjuntos de patches na instância do EC2 DB em espera para corresponder à instância do EC2 DB principal. Para facilitar o gerenciamento e a simplicidade, a configuração de armazenamento do banco de dados da instância do EC2 DB em espera deve, idealmente, corresponder também à instância do EC2 DB principal, como o nome, o número e o tamanho dos grupos de discos ASM. A seguir estão os procedimentos detalhados para configurar a instância do EC2 DB em espera para o Data Guard. Todos os comandos devem ser executados como ID de usuário proprietário do Oracle.

Primeiro, revise a configuração do banco de dados primário na instância primária do EC2. Nesta demonstração, configuramos um banco de dados Oracle primário chamado db1 na instância primária do EC2 DB com dois grupos de discos ASM +DATA e +LOGS na configuração de reinicialização autônoma. Os grupos de discos ASM primários podem estar em qualquer tipo de armazenamento dentro do ecossistema EC2.

Siga os procedimentos na documentação"TR-4965: Implantação e proteção de banco de dados Oracle no AWS FSx/EC2 com iSCSI/ASM" para instalar e configurar o grid e o Oracle na instância do EC2 DB em espera para corresponder ao banco de dados primário. O armazenamento do banco de dados deve ser provisionado e alocado para a instância de banco de dados EC2 em espera do FSx ONTAP com a mesma capacidade de armazenamento que a instância de banco de dados EC2 primária.

Pare no passo 10 em Oracle database installation seção. O banco de dados standby será instanciado a partir do banco de dados primário usando a função de duplicação de banco de dados dbca.

Depois que o software Oracle estiver instalado e configurado, no diretório de banco de dados standby $ORACLE_HOME, copie a senha do Oracle do banco de dados principal.
```
scp oracle@172.30.15.45:/u01/app/oracle/product/19.0.0/db1/dbs/orapwdb1 .
```

Crie o arquivo tnsnames.ora com as seguintes entradas.

# tnsnames.ora Network Configuration File: /u01/app/oracle/product/19.0.0/db1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

db1_NY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = db1)
    )
  )

db1_LA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-67.ec2.internal)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = db1)
    )
  )

Adicione o nome do serviço de proteção de dados do BD ao arquivo listener.ora.

#Backup file is  /u01/app/oracle/crsdata/ip-172-30-15-67/output/listener.ora.bak.ip-172-30-15-67.oracle line added by Agent
# listener.ora Network Configuration File: /u01/app/oracle/product/19.0.0/grid/network/admin/listener.ora
# Generated by Oracle configuration tools.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-67.ec2.internal)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = db1_LA_DGMGRL.demo.netapp.com)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/db1)
      (SID_NAME = db1)
    )
  )

ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON              # line added by Agent
VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON            # line added by Agent

Defina o caminho e a origem do oráculo.

export ORACLE_HOME=/u01/app/oracle/product/19.0.0/db1

export PATH=$PATH:$ORACLE_HOME/bin

Use o dbca para instanciar o banco de dados standby a partir do banco de dados primário db1.

[oracle@ip-172-30-15-67 bin]$ dbca -silent -createDuplicateDB -gdbName db1 -primaryDBConnectionString ip-172-30-15-45.ec2.internal:1521/db1_NY.demo.netapp.com -sid db1 -initParams fal_server=db1_NY -createAsStandby -dbUniqueName db1_LA
Enter SYS user password:

Prepare for db operation
22% complete
Listener config step
44% complete
Auxiliary instance creation
67% complete
RMAN duplicate
89% complete
Post duplicate database operations
100% complete

Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/db1_LA/db1_LA.log" for further details.

Validar banco de dados de espera duplicado. O banco de dados em espera recém-duplicado é aberto inicialmente no modo SOMENTE LEITURA.

[oracle@ip-172-30-15-67 bin]$ export ORACLE_SID=db1
[oracle@ip-172-30-15-67 bin]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Aug 30 18:25:46 2023
Version 19.18.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.18.0.0.0

SQL> select name, open_mode from v$database;

NAME      OPEN_MODE
--------- --------------------
DB1       READ ONLY

SQL> show parameter name

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cdb_cluster_name                     string
cell_offloadgroup_name               string
db_file_name_convert                 string
db_name                              string      db1
db_unique_name                       string      db1_LA
global_names                         boolean     FALSE
instance_name                        string      db1
lock_name_space                      string
log_file_name_convert                string
pdb_file_name_convert                string
processor_group_name                 string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      db1_LA.demo.netapp.com
SQL>
SQL> show parameter log_archive_config

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      DG_CONFIG=(db1_NY,db1_LA)
SQL> show parameter fal_server

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_server                           string      db1_NY

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
+DATA/DB1_LA/DATAFILE/system.261.1146248215
+DATA/DB1_LA/DATAFILE/sysaux.262.1146248231
+DATA/DB1_LA/DATAFILE/undotbs1.263.1146248247
+DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/DATAFILE/system.264.1146248253
+DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/DATAFILE/sysaux.265.1146248261
+DATA/DB1_LA/DATAFILE/users.266.1146248267
+DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/DATAFILE/undotbs1.267.1146248269
+DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/system.268.1146248271
+DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/sysaux.269.1146248279
+DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/undotbs1.270.1146248285
+DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/users.271.1146248293

NAME
--------------------------------------------------------------------------------
+DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/system.272.1146248295
+DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/sysaux.273.1146248301
+DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/undotbs1.274.1146248309
+DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/users.275.1146248315
+DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/system.276.1146248317
+DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/sysaux.277.1146248323
+DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/undotbs1.278.1146248331
+DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/users.279.1146248337

19 rows selected.

SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------------
+DATA/DB1_LA/CONTROLFILE/current.260.1146248209
+LOGS/DB1_LA/CONTROLFILE/current.257.1146248209

SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
+DATA/DB1_LA/TEMPFILE/temp.287.1146248371
+DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/TEMPFILE/temp.288.1146248375
+DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/TEMPFILE/temp.290.1146248463
+DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/TEMPFILE/temp.291.1146248463
+DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/TEMPFILE/temp.292.1146248463

SQL> select group#, type, member from v$logfile order by 2, 1;

    GROUP# TYPE    MEMBER
---------- ------- ------------------------------------------------------------
         1 ONLINE  +LOGS/DB1_LA/ONLINELOG/group_1.259.1146248349
         1 ONLINE  +DATA/DB1_LA/ONLINELOG/group_1.280.1146248347
         2 ONLINE  +DATA/DB1_LA/ONLINELOG/group_2.281.1146248351
         2 ONLINE  +LOGS/DB1_LA/ONLINELOG/group_2.258.1146248353
         3 ONLINE  +DATA/DB1_LA/ONLINELOG/group_3.282.1146248355
         3 ONLINE  +LOGS/DB1_LA/ONLINELOG/group_3.260.1146248355
         4 STANDBY +DATA/DB1_LA/ONLINELOG/group_4.283.1146248357
         4 STANDBY +LOGS/DB1_LA/ONLINELOG/group_4.261.1146248359
         5 STANDBY +DATA/DB1_LA/ONLINELOG/group_5.284.1146248361
         5 STANDBY +LOGS/DB1_LA/ONLINELOG/group_5.262.1146248363
         6 STANDBY +LOGS/DB1_LA/ONLINELOG/group_6.263.1146248365
         6 STANDBY +DATA/DB1_LA/ONLINELOG/group_6.285.1146248365
         7 STANDBY +LOGS/DB1_LA/ONLINELOG/group_7.264.1146248369
         7 STANDBY +DATA/DB1_LA/ONLINELOG/group_7.286.1146248367

14 rows selected.

SQL> select name, open_mode from v$database;

NAME      OPEN_MODE
--------- --------------------
DB1       READ ONLY

Reinicie o banco de dados em espera em mount prepare e execute o seguinte comando para ativar a recuperação gerenciada do banco de dados em espera.

alter database recover managed standby database disconnect from session;

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 8053062944 bytes
Fixed Size                  9182496 bytes
Variable Size            1291845632 bytes
Database Buffers         6744440832 bytes
Redo Buffers                7593984 bytes
Database mounted.
SQL> alter database recover managed standby database disconnect from session;

Database altered.

Valide o status de recuperação do banco de dados em espera. Observe o recovery logmerger em APPLYING_LOG Ação.

SQL> SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS;

ROLE                        THREAD#  SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
recovery apply slave              0          0 IDLE
recovery apply slave              0          0 IDLE
recovery apply slave              0          0 IDLE
recovery apply slave              0          0 IDLE
recovery logmerger                1         30 APPLYING_LOG
RFS ping                          1         30 IDLE
RFS async                         1         30 IDLE
archive redo                      0          0 IDLE
archive redo                      0          0 IDLE
archive redo                      0          0 IDLE
gap manager                       0          0 IDLE

ROLE                        THREAD#  SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
managed recovery                  0          0 IDLE
redo transport monitor            0          0 IDLE
log writer                        0          0 IDLE
archive local                     0          0 IDLE
redo transport timer              0          0 IDLE

16 rows selected.

SQL>

Isso conclui a configuração da proteção do Data Guard para o db1, do primário para o em espera, com a recuperação do em espera gerenciado habilitada.

Configurar o Data Guard Broker

Details

O Oracle Data Guard Broker é uma estrutura de gerenciamento distribuída que automatiza e centraliza a criação, a manutenção e o monitoramento das configurações do Oracle Data Guard. A seção a seguir demonstra como configurar o Data Guard Broker para gerenciar o ambiente do Data Guard.

Inicie o Data Guard Broker nos bancos de dados primário e standby com o seguinte comando via sqlplus.
```
alter system set dg_broker_start=true scope=both;
```

No banco de dados primário, conecte-se ao Data Guard Borker como SYSDBA.

[oracle@ip-172-30-15-45 db1]$ dgmgrl sys@db1_NY
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Aug 30 19:34:14 2023
Version 19.18.0.0.0

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

Welcome to DGMGRL, type "help" for information.
Password:
Connected to "db1_NY"
Connected as SYSDBA.

Crie e habilite a configuração do Data Guard Broker.

DGMGRL> create configuration dg_config as primary database is db1_NY connect identifier is db1_NY;
Configuration "dg_config" created with primary database "db1_ny"
DGMGRL> add database db1_LA as connect identifier is db1_LA;
Database "db1_la" added
DGMGRL> enable configuration;
Enabled.
DGMGRL> show configuration;

Configuration - dg_config

  Protection Mode: MaxPerformance
  Members:
  db1_ny - Primary database
    db1_la - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 28 seconds ago)

Valide o status do banco de dados dentro da estrutura de gerenciamento do Data Guard Broker.

DGMGRL> show database db1_ny;

Database - db1_ny

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    db1

Database Status:
SUCCESS

DGMGRL> show database db1_la;

Database - db1_la

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 2.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    db1

Database Status:
SUCCESS

DGMGRL>

Em caso de falha, o Data Guard Broker pode ser usado para fazer failover do banco de dados primário para o standby instantaneamente.

Clonar banco de dados standby para outros casos de uso

Details

O principal benefício de preparar um banco de dados standby no AWS FSx ONTAP no Data Guard é que ele pode ser FlexClonado para atender a muitos outros casos de uso com investimento mínimo em armazenamento adicional. Na seção a seguir, demonstramos como fazer um snapshot e clonar os volumes de banco de dados em espera montados e em recuperação no FSx ONTAP para outros propósitos, como DEV, TEST, REPORT, etc., usando a ferramenta NetApp SnapCenter .

A seguir estão os procedimentos de alto nível para clonar um banco de dados de LEITURA/GRAVAÇÃO do banco de dados de espera físico gerenciado no Data Guard usando o SnapCenter. Para obter instruções detalhadas sobre como configurar e configurar o SnapCenter, consulte"Soluções de banco de dados em nuvem híbrida com SnapCenter" seções relevantes do Oracle.

Começamos criando uma tabela de teste e inserindo uma linha na tabela de teste no banco de dados primário. Em seguida, validaremos se a transação passará para o modo de espera e, finalmente, para o clone.

[oracle@ip-172-30-15-45 db1]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 31 16:35:53 2023
Version 19.18.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.18.0.0.0

SQL> alter session set container=db1_pdb1;

Session altered.

SQL> create table test(
  2  id integer,
  3  dt timestamp,
  4  event varchar(100));

Table created.

SQL> insert into test values(1, sysdate, 'a test transaction on primary database db1 and ec2 db host: ip-172-30-15-45.ec2.internal');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from test;

        ID
----------
DT
---------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
         1
31-AUG-23 04.49.29.000000 PM
a test transaction on primary database db1 and ec2 db host: ip-172-30-15-45.ec2.
internal

SQL> select instance_name, host_name from v$instance;

INSTANCE_NAME
----------------
HOST_NAME
----------------------------------------------------------------
db1
ip-172-30-15-45.ec2.internal

Adicionar cluster de armazenamento FSx a Storage Systems no SnapCenter com IP de gerenciamento de cluster FSx e credencial fsxadmin.
Adicionar AWS ec2-user a Credential em Settings .

Adicionar instância de banco de dados EC2 em espera e clonar instância de banco de dados EC2 para Hosts .

Captura de tela mostrando esta etapa na GUI.

A instância do EC2 DB clone deve ter pilhas de software Oracle semelhantes instaladas e configuradas. Em nosso caso de teste, a infraestrutura de grade e o Oracle 19C foram instalados e configurados, mas nenhum banco de dados foi criado.

Crie uma política de backup personalizada para backup completo do banco de dados offline/montado.
Aplicar política de backup para proteger o banco de dados em espera em Resources aba.
Clique no nome do banco de dados para abrir a página de backups do banco de dados. Selecione um backup a ser usado para clonagem do banco de dados e clique em Clone botão para iniciar o fluxo de trabalho de clonagem.
Selecione Complete Database Clone e nomeie o SID da instância do clone.
Selecione o host clone, que hospeda o banco de dados clonado do banco de dados em espera. Aceite o padrão para arquivos de dados, arquivos de controle e logs de refazer. Dois grupos de discos ASM serão criados no host clone, correspondendo aos grupos de discos no banco de dados em espera.
Nenhuma credencial de banco de dados é necessária para autenticação baseada em sistema operacional. Corresponda a configuração inicial do Oracle com o que está configurado na instância do banco de dados EC2 clone.
Altere os parâmetros do banco de dados clone, se necessário, e especifique os scripts a serem executados antes da clonagem, se houver.
Digite SQL para executar após o clone. Na demonstração, executamos comandos para desativar o modo de arquivamento de banco de dados para um banco de dados de desenvolvimento/teste/relatório.
Configure a notificação por e-mail, se desejar.
Revise o resumo, clique Finish para iniciar o clone.
Monitorar trabalho de clonagem em Monitor aba. Observamos que demorava cerca de 8 minutos para clonar um banco de dados com cerca de 300 GB de volume.
Valide o banco de dados clone do SnapCenter, que é imediatamente registrado em Resources guia logo após a operação de clonagem.

Consulte o banco de dados clone da instância EC2 clone. Validamos que a transação de teste que ocorreu no banco de dados primário foi transferida para o banco de dados clone.

[oracle@ip-172-30-15-126 ~]$ export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dev
[oracle@ip-172-30-15-126 ~]$ export ORACLE_SID=db1dev
[oracle@ip-172-30-15-126 ~]$ export PATH=$PATH:$ORACLE_HOME/bin
[oracle@ip-172-30-15-126 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Sep 6 16:41:41 2023
Version 19.18.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.18.0.0.0

SQL> select name, open_mode, log_mode from v$database;

NAME      OPEN_MODE            LOG_MODE
--------- -------------------- ------------
DB1DEV    READ WRITE           NOARCHIVELOG

SQL> select instance_name, host_name from v$instance;

INSTANCE_NAME
----------------
HOST_NAME
----------------------------------------------------------------
db1dev
ip-172-30-15-126.ec2.internal

SQL> alter session set container=db1_pdb1;

Session altered.

SQL> select * from test;

        ID
----------
DT
---------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
         1
31-AUG-23 04.49.29.000000 PM
a test transaction on primary database db1 and ec2 db host: ip-172-30-15-45.ec2.
internal


SQL>

Isso conclui a clonagem e a validação de um novo banco de dados Oracle a partir do banco de dados standby no Data Guard no armazenamento FSx para DEV, TEST, REPORT ou qualquer outro caso de uso. Vários bancos de dados Oracle podem ser clonados do mesmo banco de dados standby no Data Guard.

Onde encontrar informações adicionais

Para saber mais sobre as informações descritas neste documento, revise os seguintes documentos e/ou sites:

Conceitos e Administração do Data Guard

"https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/index.html#Oracle%C2%AE-Data-Guard"
WP-7357: Melhores práticas de implantação do Oracle Database no EC2 e FSx

"Introdução"
Amazon FSx ONTAP

"https://aws.amazon.com/fsx/netapp-ontap/"
Amazon EC2

https://aws.amazon.com/pm/ec2/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&s_kwcid=AL!4422!3!467723097970!e!!g!!aws%20ec2&ef_id=Cj0KCQiA54KfBhCKARIsAJzSrdqwQrghn6I71jiWzSeaT9Uh1-vY-VfhJixF-xnv5rWwn2S7RqZOTQ0aAh7eEALw_wcB:G:s&s_kwcid=AL!4422!3!467723097970!e!!g!!aws%20ec2

TR-4981: Redução de custos do Oracle Active Data Guard com Amazon FSx ONTAP

Creating your file...

Propósito

Público

Ambiente de teste e validação de soluções

Arquitetura

Componentes de hardware e software

Configuração do Oracle Data Guard com configuração hipotética de NY para LA DR

Fatores-chave para consideração de implantação

Implantação da solução

Pré-requisitos para implantação

Preparar o banco de dados primário para o Data Guard

Preparar o banco de dados standby e ativar o Data Guard

Configurar o Data Guard Broker

Clonar banco de dados standby para outros casos de uso

Onde encontrar informações adicionais