Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

TR-4981: Reducción de costos de Oracle Active Data Guard con Amazon FSx ONTAP

08/18/2025 Colaboradores

PDF

Allen Cao, Niyaz Mohamed, NetApp

Esta solución proporciona una descripción general y detalles para configurar Oracle Data Guard usando AWS FSx ONTAP como almacenamiento de base de datos de Oracle en el sitio de respaldo para reducir los costos operativos y de licencia de la solución Oracle Data Guard HA/DR en AWS.

Objetivo

Oracle Data Guard garantiza alta disponibilidad, protección de datos y recuperación ante desastres para datos empresariales en una configuración de replicación de base de datos principal y de base de datos en espera. Oracle Active Data Guard permite a los usuarios acceder a bases de datos en espera mientras la replicación de datos está activa desde la base de datos principal a las bases de datos en espera. Data Guard es una característica de Oracle Database Enterprise Edition. No requiere licencia separada. Por otro lado, Active Data Guard es una opción de Oracle Database Enterprise Edition y, por lo tanto, requiere una licencia independiente. Varias bases de datos en espera pueden recibir replicación de datos desde una base de datos principal en la configuración de Active Data Guard. Sin embargo, cada base de datos de reserva adicional requiere una licencia de Active Data Guard y almacenamiento adicional al tamaño de la base de datos principal. Los costos operativos se acumulan rápidamente.

Si desea reducir el costo de la operación de su base de datos Oracle y planea configurar un Active Data Guard en AWS, debería considerar una alternativa. En lugar de Active Data Guard, utilice Data Guard para replicar desde la base de datos principal a una única base de datos física en espera en el almacenamiento de Amazon FSx ONTAP . Posteriormente, se pueden clonar múltiples copias de esta base de datos en espera y abrirlas para acceso de lectura y escritura para atender muchos otros casos de uso, como informes, desarrollo, pruebas, etc. Los resultados netos ofrecen de manera efectiva las funcionalidades de Active Data Guard al tiempo que eliminan la licencia de Active Data Guard y los costos de almacenamiento adicionales para cada base de datos en espera adicional. En esta documentación, demostramos cómo configurar Oracle Data Guard con su base de datos principal existente en AWS y colocar una base de datos física en espera en el almacenamiento de Amazon FSx ONTAP . La base de datos en espera se respalda mediante una instantánea y se clona para acceso de lectura y escritura para los casos de uso según se desee.

Esta solución aborda los siguientes casos de uso:

Oracle Data Guard entre una base de datos principal en cualquier almacenamiento en AWS y una base de datos en espera en el almacenamiento de Amazon FSx ONTAP .
Clone la base de datos en espera mientras está cerrada para la replicación de datos para atender casos de uso como informes, desarrollo, pruebas, etc.

Audiencia

Esta solución está destinada a las siguientes personas:

Un administrador de bases de datos que configuró Oracle Active Data Guard en AWS para alta disponibilidad, protección de datos y recuperación ante desastres.
Un arquitecto de soluciones de bases de datos interesado en la configuración de Oracle Active Data Guard en la nube de AWS.
Un administrador de almacenamiento que administra el almacenamiento de AWS FSx ONTAP compatible con Oracle Data Guard.
Propietario de una aplicación a quien le gusta instalar Oracle Data Guard en un entorno AWS FSx/EC2.

Entorno de prueba y validación de soluciones

La prueba y validación de esta solución se realizó en un entorno de laboratorio de AWS FSx ONTAP y EC2 que podría no coincidir con el entorno de implementación final. Para más información, consulte la sección Factores clave a considerar en la implementación .

Arquitectura

Esta imagen proporciona una imagen detallada de la implementación de Oracle Data Guard en AWS con FSx ONTAP.

Componentes de hardware y software

Hardware

Almacenamiento de FSx ONTAP

Versión actual ofrecida por AWS

Un clúster FSx HA en la misma VPC y zona de disponibilidad

Instancia EC2 para computación

t2.xlarge/4vCPU/16G

Tres instancias EC2 T2 xlarge, una como servidor de base de datos principal, una como servidor de base de datos en espera y la tercera como servidor de base de datos clonado

Software

Red Hat Linux

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

Se implementó una suscripción a RedHat para realizar pruebas

Infraestructura de red de Oracle

Versión 19.18

Parche RU aplicado p34762026_190000_Linux-x86-64.zip

Base de datos Oracle

Versión 19.18

Parche RU aplicado p34765931_190000_Linux-x86-64.zip

Oracle OPatch

Versión 12.2.0.1.36

Último parche p6880880_190000_Linux-x86-64.zip

Configuración de Oracle Data Guard con configuración hipotética de DR de NY a LA

Base de datos

NOMBRE ÚNICO DE LA BASE DE DATOS

Nombre del servicio Oracle Net

Primario

db1_NY

db1_NY.demo.netapp.com

Modo de espera físico

db1_LA

db1_LA.demo.netapp.com

Factores clave a considerar en la implementación

Cómo funciona Oracle Standby Database FlexClone . AWS FSx ONTAP FlexClone proporciona copias compartidas de los mismos volúmenes de base de datos en espera que se pueden escribir. Las copias de los volúmenes son en realidad punteros que se vinculan a los bloques de datos originales hasta que se inicia una nueva escritura en el clon. Luego, ONTAP asigna nuevos bloques de almacenamiento para las nuevas escrituras. Cualquier E/S de lectura es atendida por bloques de datos originales bajo replicación activa. Por lo tanto, los clones son muy eficientes en términos de almacenamiento y pueden usarse para muchos otros casos de uso con una asignación de almacenamiento nuevo mínima e incremental para nuevas E/S de escritura. Esto proporciona un enorme ahorro en costos de almacenamiento al reducir sustancialmente el espacio de almacenamiento de Active Data Guard. NetApp recomienda minimizar las actividades de FlexClone en caso de que la base de datos cambie del almacenamiento principal al almacenamiento FSx en espera para mantener el rendimiento de Oracle en un alto nivel.
Requisitos del software de Oracle. En general, una base de datos física en espera debe tener la misma versión de Database Home que la base de datos principal, incluidas las excepciones de conjunto de parches (PSE), las actualizaciones de parches críticos (CPU) y las actualizaciones de conjunto de parches (PSU), a menos que esté en curso un proceso de aplicación de parches de Oracle Data Guard Standby-First (como se describe en la nota 1265700.1 de My Oracle Support en"soporte.oracle.com"
Consideraciones sobre la estructura del directorio de la base de datos en espera Si es posible, los archivos de datos, archivos de registro y archivos de control en los sistemas principal y en espera deben tener los mismos nombres y nombres de ruta y utilizar las convenciones de nombres de Arquitectura Flexible Óptima (OFA). Los directorios de archivo de la base de datos de reserva también deben ser idénticos entre los sitios, incluido el tamaño y la estructura. Esta estrategia permite que otras operaciones, como copias de seguridad, conmutaciones y conmutaciones por error, ejecuten el mismo conjunto de pasos, lo que reduce la complejidad del mantenimiento.
Modo de registro forzado. Para protegerse contra escrituras directas no registradas en la base de datos principal que no se pueden propagar a la base de datos en espera, active FORZAR REGISTRO en la base de datos principal antes de realizar copias de seguridad de archivos de datos para la creación de la base de datos en espera.
Gestión del almacenamiento de bases de datos. Para simplificar la operación, Oracle recomienda que cuando configure Oracle Automatic Storage Management (Oracle ASM) y Oracle Managed Files (OMF) en una configuración de Oracle Data Guard, los configure de manera simétrica en las bases de datos principales y en espera.
Instancias de cómputo EC2. En estas pruebas y validaciones, utilizamos una instancia AWS EC2 t2.xlarge como instancia de cómputo de la base de datos Oracle. NetApp recomienda utilizar una instancia EC2 de tipo M5 como instancia de cómputo para Oracle en una implementación de producción porque está optimizada para la carga de trabajo de la base de datos. Debe dimensionar la instancia EC2 adecuadamente para la cantidad de vCPU y la cantidad de RAM en función de los requisitos de carga de trabajo reales.
Implementación de clústeres de alta disponibilidad de almacenamiento FSx en una o varias zonas. En estas pruebas y validaciones, implementamos un clúster FSx HA en una única zona de disponibilidad de AWS. Para la implementación de producción, NetApp recomienda implementar un par FSx HA en dos zonas de disponibilidad diferentes. Un clúster FSx siempre se aprovisiona en un par HA que se refleja sincronizado en un par de sistemas de archivos activo-pasivo para proporcionar redundancia a nivel de almacenamiento. La implementación de múltiples zonas mejora aún más la alta disponibilidad en caso de falla en una sola zona de AWS.
Tamaño del clúster de almacenamiento FSx. Un sistema de archivos de almacenamiento Amazon FSx ONTAP proporciona hasta 160 000 IOPS SSD sin procesar, un rendimiento de hasta 4 GBps y una capacidad máxima de 192 TiB. Sin embargo, puede dimensionar el clúster en términos de IOPS aprovisionados, rendimiento y límite de almacenamiento (mínimo 1024 GiB) según sus requisitos reales al momento de la implementación. La capacidad se puede ajustar dinámicamente sobre la marcha sin afectar la disponibilidad de la aplicación.

Implementación de la solución

Se supone que ya tiene su base de datos Oracle principal implementada en el entorno AWS EC2 dentro de una VPC como punto de partida para configurar Data Guard. La base de datos principal se implementa utilizando Oracle ASM para la gestión del almacenamiento. Se crean dos grupos de discos ASM: +DATA y +LOGS para archivos de datos de Oracle, archivos de registro y archivos de control, etc. Para obtener detalles sobre la implementación de Oracle en AWS con ASM, consulte los siguientes informes técnicos para obtener ayuda.

Su base de datos Oracle principal puede ejecutarse en FSx ONTAP o en cualquier otro almacenamiento de su elección dentro del ecosistema AWS EC2. La siguiente sección proporciona procedimientos de implementación paso a paso para configurar Oracle Data Guard entre una instancia de base de datos EC2 principal con almacenamiento ASM y una instancia de base de datos EC2 en espera con almacenamiento ASM.

Requisitos previos para la implementación

Details

La implementación requiere los siguientes requisitos previos.

Se ha configurado una cuenta de AWS y se han creado los segmentos de red y VPC necesarios dentro de su cuenta de AWS.
Desde la consola de AWS EC2, debe implementar un mínimo de tres instancias de EC2 Linux: una como instancia de Oracle DB principal, una como instancia de Oracle DB en espera y una instancia de DB de destino clonada para informes, desarrollo y pruebas, etc. Consulte el diagrama de arquitectura en la sección anterior para obtener más detalles sobre la configuración del entorno. Revise también AWS"Guía del usuario para instancias de Linux" Para más información.
Desde la consola de AWS EC2, implemente clústeres de alta disponibilidad de almacenamiento de Amazon FSx ONTAP para alojar volúmenes de Oracle que almacenan la base de datos en espera de Oracle. Si no está familiarizado con la implementación del almacenamiento de FSx, consulte la documentación"Creación de sistemas de archivos FSx ONTAP" para obtener instrucciones paso a paso.
Los pasos 2 y 3 se pueden realizar utilizando el siguiente kit de herramientas de automatización de Terraform, que crea una instancia EC2 denominada ora_01 y un sistema de archivos FSx llamado fsx_01 . Revise las instrucciones cuidadosamente y cambie las variables para adaptarlas a su entorno antes de la ejecución. La plantilla se puede revisar fácilmente para adaptarla a sus propios requisitos de implementación.
```
git clone https://github.com/NetApp-Automation/na_aws_fsx_ec2_deploy.git
```

Asegúrese de haber asignado al menos 50G en el volumen raíz de la instancia EC2 para tener suficiente espacio para almacenar los archivos de instalación de Oracle.

Preparar la base de datos principal para Data Guard

Details

En esta demostración, configuramos una base de datos Oracle principal denominada db1 en la instancia de base de datos EC2 principal con dos grupos de discos ASM en una configuración de reinicio independiente con archivos de datos en el grupo de discos ASM +DATA y el área de recuperación flash en el grupo de discos ASM +LOGS. A continuación se ilustran los procedimientos detallados para configurar la base de datos principal para Data Guard. Todos los pasos deben ejecutarse como propietario de la base de datos (usuario Oracle).

Configuración de la base de datos principal db1 en la instancia de base de datos EC2 principal ip-172-30-15-45. Los grupos de discos ASM pueden estar en cualquier tipo de almacenamiento dentro del ecosistema 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
--------------------------------------------------------------------------------

Desde sqlplus, habilite el registro forzado en el servidor principal.
```
alter database force logging;
```
Desde sqlplus, habilite el flashback en el servidor principal. Flashback permite restablecer fácilmente la base de datos principal como reserva después de una conmutación por error.
```
alter database flashback on;
```
Configure la autenticación de transporte de rehacer usando el archivo de contraseña de Oracle: cree un archivo pwd en la base de datos principal usando la utilidad orapwd si no está configurada y cópielo al directorio de la base de datos en espera $ORACLE_HOME/dbs.

Cree registros de rehacer en espera en la base de datos principal con el mismo tamaño que el archivo de registro en línea actual. Los grupos de registros son uno más de los grupos de archivos de registro en línea. La base de datos principal puede luego pasar rápidamente a la función de espera y comenzar a recibir datos de rehacer, si es necesario.

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.

Desde sqlplus, cree un pfile a partir de spfile para editarlo.
```
create pfile='/home/oracle/initdb1.ora' from spfile;
```

Revise el archivo pfile y agregue los siguientes 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

Desde sqlplus, cree spfile en el directorio ASM +DATA a partir del pfile revisado en el directorio /home/oracle.
```
create spfile='+DATA' from pfile='/home/oracle/initdb1.ora';
```

Ubique el archivo spfile recién creado en el grupo de discos +DATA (usando la utilidad asmcmd si es necesario). Utilice srvctl para modificar la cuadrícula para iniciar la base de datos desde el nuevo spfile como se muestra a continuación.

[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 agregar db_unique_name para la resolución de nombres.

# 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))

Agregue el nombre del servicio de protección de datos db1_NY_DGMGRL.demo.netapp para la base de datos principal al archivo 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

Apague y reinicie la base de datos con srvctl y valide que los parámetros de protección de datos ahora estén activos.
```
srvctl stop database -d db1
```
```
srvctl start database -d db1
```

Esto completa la configuración de la base de datos principal para Data Guard.

Preparar la base de datos en espera y activar Data Guard

Details

Oracle Data Guard requiere la configuración del kernel del sistema operativo y pilas de software de Oracle, incluidos conjuntos de parches en la instancia de base de datos EC2 en espera para que coincida con la instancia de base de datos EC2 principal. Para una administración fácil y simplicidad, la configuración de almacenamiento de la base de datos de la instancia EC2 DB en espera idealmente también debería coincidir con la instancia EC2 DB principal, como el nombre, el número y el tamaño de los grupos de discos ASM. A continuación se detallan los procedimientos para configurar la instancia de base de datos EC2 en espera para Data Guard. Todos los comandos deben ejecutarse como ID de usuario propietario de Oracle.

Primero, revise la configuración de la base de datos principal en la instancia EC2 principal. En esta demostración, configuramos una base de datos Oracle principal denominada db1 en la instancia de base de datos EC2 principal con dos grupos de discos ASM +DATA y +LOGS en una configuración de reinicio independiente. Los grupos de discos ASM principales pueden estar en cualquier tipo de almacenamiento dentro del ecosistema EC2.

Seguir los procedimientos de la documentación"TR-4965: Implementación y protección de bases de datos Oracle en AWS FSx/EC2 con iSCSI/ASM" Instalar y configurar la red y Oracle en una instancia de base de datos EC2 en espera para que coincida con la base de datos principal. El almacenamiento de la base de datos se debe aprovisionar y asignar a una instancia de base de datos EC2 en espera desde FSx ONTAP con la misma capacidad de almacenamiento que la instancia de base de datos EC2 principal.

Detenerse en el paso 10 Oracle database installation sección. La base de datos en espera se instanciará desde la base de datos principal mediante la función de duplicación de base de datos dbca.

Una vez instalado y configurado el software de Oracle, desde el directorio de bases de datos en espera $ORACLE_HOME, copie la contraseña de Oracle de la base de datos principal.
```
scp oracle@172.30.15.45:/u01/app/oracle/product/19.0.0/db1/dbs/orapwdb1 .
```

Cree el archivo tnsnames.ora con las siguientes 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)
    )
  )

Agregue el nombre del servicio de protección de datos de base de datos al archivo 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

Establecer la ruta y la página de inicio del oráculo.

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

export PATH=$PATH:$ORACLE_HOME/bin

Utilice dbca para crear una instancia de la base de datos en espera desde la base de datos principal 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 la base de datos en espera duplicada. La base de datos en espera recién duplicada se abre inicialmente en modo de SOLO LECTURA.

[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

Reiniciar la base de datos en espera en mount Ponga en escena y ejecute el siguiente comando para activar la recuperación administrada de la base de datos en 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.

Validar el estado de recuperación de la base de datos en espera. Tenga en cuenta el recovery logmerger en APPLYING_LOG acción.

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>

Esto completa la configuración de protección de Data Guard para db1 desde el modo principal al modo en espera con la recuperación en espera administrada habilitada.

Configurar Data Guard Broker

Details

Oracle Data Guard Broker es un marco de gestión distribuida que automatiza y centraliza la creación, el mantenimiento y la supervisión de las configuraciones de Oracle Data Guard. La siguiente sección demuestra cómo configurar Data Guard Broker para administrar el entorno de Data Guard.

Inicie Data Guard Broker en las bases de datos principal y en espera con el siguiente comando a través de sqlplus.
```
alter system set dg_broker_start=true scope=both;
```

Desde la base de datos principal, conéctese a 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.

Cree y habilite la configuración de 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)

Validar el estado de la base de datos dentro del marco de gestión de 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>

En caso de falla, se puede utilizar Data Guard Broker para conmutar por error la base de datos principal a una en espera de manera instantánea.

Clonar base de datos en espera para otros casos de uso

Details

El beneficio clave de almacenar una base de datos en espera en AWS FSx ONTAP en Data Guard es que se puede clonar de forma flexible para atender a muchos otros casos de uso con una inversión mínima de almacenamiento adicional. En la siguiente sección, demostramos cómo crear instantáneas y clonar los volúmenes de base de datos montados y en espera de recuperación en FSx ONTAP para otros fines, como DEV, TEST, REPORT, etc., utilizando la herramienta NetApp SnapCenter .

A continuación se presentan procedimientos de alto nivel para clonar una base de datos de LECTURA/ESCRITURA desde la base de datos física en espera administrada en Data Guard usando SnapCenter. Para obtener instrucciones detalladas sobre cómo instalar y configurar SnapCenter, consulte"Soluciones de bases de datos en la nube híbrida con SnapCenter" Secciones relevantes de Oracle.

Comenzamos creando una tabla de prueba e insertando una fila en la tabla de prueba en la base de datos principal. Luego validaremos si la transacción pasa al modo de espera y finalmente al clon.

[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

Agregar clúster de almacenamiento FSx a Storage Systems en SnapCenter con IP de administración de clúster FSx y credencial fsxadmin.
Agregar AWS ec2-user a Credential en Settings .

Agregue una instancia de base de datos EC2 en espera y clone la instancia de base de datos EC2 a Hosts .

Captura de pantalla que muestra este paso en la GUI.

La instancia de base de datos EC2 clonada debe tener pilas de software Oracle similares instaladas y configuradas. En nuestro caso de prueba, la infraestructura de la red y Oracle 19C se instalaron y configuraron, pero no se creó ninguna base de datos.

Cree una política de respaldo adaptada para copias de seguridad completas de bases de datos montadas o sin conexión.
Aplicar la política de respaldo para proteger la base de datos en espera en Resources pestaña.
Haga clic en el nombre de la base de datos para abrir la página de copias de seguridad de la base de datos. Seleccione una copia de seguridad que se utilizará para clonar la base de datos y haga clic en Clone Botón para iniciar el flujo de trabajo de clonación.
Seleccionar Complete Database Clone y nombrar el SID de la instancia clonada.
Seleccione el host clonado, que aloja la base de datos clonada de la base de datos en espera. Acepte los valores predeterminados para archivos de datos, archivos de control y registros de rehacer. Se crearán dos grupos de discos ASM en el host clonado que corresponden a los grupos de discos en la base de datos en espera.
No se necesitan credenciales de base de datos para la autenticación basada en sistema operativo. Haga coincidir la configuración de inicio de Oracle con lo que está configurado en la instancia de base de datos EC2 clonada.
Si es necesario, cambie los parámetros de la base de datos de clonación y especifique los scripts que se ejecutarán antes de la clonación, si corresponde.
Ingrese SQL para ejecutar después de la clonación. En la demostración, ejecutamos comandos para desactivar el modo de archivo de base de datos para una base de datos de desarrollo/prueba/informe.
Configure la notificación por correo electrónico si lo desea.
Revise el resumen, haga clic Finish para iniciar el clon.
Supervisar el trabajo de clonación en Monitor pestaña. Observamos que tomó alrededor de 8 minutos clonar una base de datos con un tamaño de volumen de base de datos de aproximadamente 300 GB.
Validar la base de datos clonada de SnapCenter, que se registra inmediatamente en Resources Pestaña justo después de la operación de clonación.

Consulta la base de datos clonada desde la instancia EC2 clonada. Validamos que la transacción de prueba que ocurrió en la base de datos principal haya recorrido hasta la base de datos clonada.

[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>

Esto completa la clonación y validación de una nueva base de datos Oracle desde una base de datos en espera en Data Guard en el almacenamiento FSx para DEV, TEST, REPORT o cualquier otro caso de uso. Es posible clonar varias bases de datos Oracle desde la misma base de datos en espera en Data Guard.

Dónde encontrar información adicional

Para obtener más información sobre la información descrita en este documento, revise los siguientes documentos y/o sitios web:

Conceptos y administración de Data Guard

"https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/index.html#Oracle%C2%AE-Data-Guard"
WP-7357: Mejores prácticas para la implementación de bases de datos Oracle en EC2 y FSx

"Introducción"
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: Reducción de costos de Oracle Active Data Guard con Amazon FSx ONTAP

Creating your file...

Objetivo

Audiencia

Entorno de prueba y validación de soluciones

Arquitectura

Componentes de hardware y software

Configuración de Oracle Data Guard con configuración hipotética de DR de NY a LA

Factores clave a considerar en la implementación

Implementación de la solución

Requisitos previos para la implementación

Preparar la base de datos principal para Data Guard

Preparar la base de datos en espera y activar Data Guard

Configurar Data Guard Broker

Clonar base de datos en espera para otros casos de uso

Dónde encontrar información adicional