La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

TR-4981: Riduzione dei costi di Oracle Active Data Guard con Amazon FSx ONTAP

08/18/2025 Collaboratori

PDF

Allen Cao, Niyaz Mohamed, NetApp

Questa soluzione fornisce una panoramica e dettagli per la configurazione di Oracle Data Guard utilizzando AWS FSx ONTAP come storage del database Oracle del sito di standby per ridurre i costi di licenza e operativi della soluzione Oracle Data Guard HA/DR in AWS.

Scopo

Oracle Data Guard garantisce elevata disponibilità, protezione dei dati e ripristino di emergenza per i dati aziendali in una configurazione di replicazione del database primario e del database di standby. Oracle Active Data Guard consente agli utenti di accedere ai database di standby mentre è attiva la replicazione dei dati dal database primario ai database di standby. Data Guard è una funzionalità di Oracle Database Enterprise Edition. Non richiede licenze separate. D'altro canto, Active Data Guard è un'opzione di Oracle Database Enterprise Edition e pertanto richiede una licenza separata. Nella configurazione di Active Data Guard, più database standby possono ricevere la replica dei dati da un database primario. Tuttavia, ogni database di standby aggiuntivo richiede una licenza Active Data Guard e spazio di archiviazione aggiuntivo pari alle dimensioni del database primario. I costi operativi aumentano rapidamente.

Se desideri ridurre i costi operativi del tuo database Oracle e stai pianificando di configurare Active Data Guard in AWS, dovresti prendere in considerazione un'alternativa. Invece di Active Data Guard, utilizza Data Guard per replicare dal database primario a un singolo database standby fisico sullo storage Amazon FSx ONTAP . Successivamente, è possibile clonare più copie di questo database standby e aprirle per l'accesso in lettura/scrittura, al fine di soddisfare molti altri casi d'uso, quali reporting, sviluppo, test, ecc. I risultati netti forniscono in modo efficace le funzionalità di Active Data Guard, eliminando al contempo la licenza di Active Data Guard e i costi di archiviazione aggiuntivi per ogni database standby aggiuntivo. In questa documentazione, illustriamo come configurare Oracle Data Guard con il database primario esistente in AWS e posizionare il database di standby fisico sullo storage Amazon FSx ONTAP . Il database di standby viene sottoposto a backup tramite snapshot e clonato per l'accesso in lettura/scrittura in base ai casi d'uso desiderati.

Questa soluzione affronta i seguenti casi d'uso:

Oracle Data Guard tra un database primario su qualsiasi storage in AWS e un database di standby su storage Amazon FSx ONTAP .
Clonare il database di standby mentre è chiuso per la replica dei dati da utilizzare in casi d'uso quali reporting, sviluppo, test, ecc.

Pubblico

Questa soluzione è destinata alle seguenti persone:

Un DBA che ha configurato Oracle Active Data Guard in AWS per garantire elevata disponibilità, protezione dei dati e ripristino di emergenza.
Un architetto di soluzioni di database interessato alla configurazione di Oracle Active Data Guard nel cloud AWS.
Un amministratore di storage che gestisce lo storage AWS FSx ONTAP che supporta Oracle Data Guard.
Un proprietario di applicazioni che desidera installare Oracle Data Guard nell'ambiente AWS FSx/EC2.

Ambiente di test e convalida della soluzione

I test e la convalida di questa soluzione sono stati eseguiti in un ambiente di laboratorio AWS FSx ONTAP ed EC2 che potrebbe non corrispondere all'ambiente di distribuzione finale. Per ulteriori informazioni, consultare la sezione Fattori chiave per la considerazione dell'implementazione .

Architettura

Questa immagine fornisce un quadro dettagliato dell'implementazione di Oracle Data Guard in AWS con FSx ONTAP.

Componenti hardware e software

Hardware

Archiviazione FSx ONTAP

Versione attuale offerta da AWS

Un cluster FSx HA nella stessa VPC e zona di disponibilità

Istanza EC2 per il calcolo

t2.xlarge/4vCPU/16G

Tre istanze EC2 T2 xlarge EC2, una come server DB primario, una come server DB standby e la terza come server DB clone

Software

RedHat Linux

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

Abbonamento RedHat distribuito per i test

Infrastruttura Oracle Grid

Versione 19.18

Patch RU applicata p34762026_190000_Linux-x86-64.zip

Database Oracle

Versione 19.18

Patch RU applicata p34765931_190000_Linux-x86-64.zip

Oracle OPatch

Versione 12.2.0.1.36

Ultima patch p6880880_190000_Linux-x86-64.zip

Configurazione di Oracle Data Guard con ipotetica configurazione DR da NY a LA

Banca dati

DB_NOME_UNICO

Nome del servizio Oracle Net

Primario

db1_NY

db1_NY.demo.netapp.com

Standby fisico

db1_LA

db1_LA.demo.netapp.com

Fattori chiave per la considerazione dell'implementazione

Come funziona Oracle Standby Database FlexClone . AWS FSx ONTAP FlexClone fornisce copie condivise degli stessi volumi di database in standby che sono scrivibili. Le copie dei volumi sono in realtà puntatori che rimandano ai blocchi di dati originali finché non viene avviata una nuova scrittura sul clone. ONTAP alloca quindi nuovi blocchi di archiviazione per le nuove scritture. Tutti gli I/O di lettura vengono gestiti dai blocchi di dati originali sottoposti a replicazione attiva. Pertanto, i cloni sono molto efficienti in termini di archiviazione e possono essere utilizzati per molti altri casi d'uso con una nuova allocazione di archiviazione minima e incrementale per i nuovi I/O di scrittura. Ciò consente un notevole risparmio sui costi di archiviazione riducendo sostanzialmente l'ingombro di Active Data Guard. NetApp consiglia di ridurre al minimo le attività FlexClone in caso di passaggio del database dallo storage primario allo storage FSx di standby, per mantenere elevate le prestazioni di Oracle.
Requisiti software Oracle. In generale, un database standby fisico deve avere la stessa versione di Database Home del database primario, incluse le eccezioni del set di patch (PSE), gli aggiornamenti delle patch critiche (CPU) e gli aggiornamenti del set di patch (PSU), a meno che non sia in corso un processo di applicazione delle patch standby-first di Oracle Data Guard (come descritto nella nota 1265700.1 di My Oracle Support all'indirizzo"support.oracle.com"
Considerazioni sulla struttura della directory del database di standby. Se possibile, i file di dati, i file di registro e i file di controllo sui sistemi primario e di standby dovrebbero avere gli stessi nomi e percorsi e utilizzare le convenzioni di denominazione Optimal Flexible Architecture (OFA). Anche le directory di archivio sul database di standby devono essere identiche in tutti i siti, comprese le dimensioni e la struttura. Questa strategia consente ad altre operazioni, come backup, switchover e failover, di eseguire la stessa serie di passaggi, riducendo la complessità della manutenzione.
Modalità di registrazione forzata. Per proteggersi dalle scritture dirette non registrate nel database primario che non possono essere propagate al database di standby, attivare FORCE LOGGING nel database primario prima di eseguire backup dei file di dati per la creazione di standby.
Gestione dell'archiviazione del database. Per semplicità operativa, quando si imposta Oracle Automatic Storage Management (Oracle ASM) e Oracle Managed Files (OMF) in una configurazione Oracle Data Guard, Oracle consiglia di impostarli in modo simmetrico sui database primario e di standby.
Istanze di calcolo EC2. In questi test e convalide, abbiamo utilizzato un'istanza AWS EC2 t2.xlarge come istanza di calcolo del database Oracle. NetApp consiglia di utilizzare un'istanza EC2 di tipo M5 come istanza di elaborazione per Oracle nella distribuzione di produzione perché è ottimizzata per il carico di lavoro del database. È necessario dimensionare l'istanza EC2 in modo appropriato per il numero di vCPU e la quantità di RAM in base ai requisiti effettivi del carico di lavoro.
Distribuzione di cluster HA di storage FSx a zona singola o multizona. In questi test e convalide, abbiamo distribuito un cluster FSx HA in una singola zona di disponibilità AWS. Per la distribuzione in produzione, NetApp consiglia di distribuire una coppia FSx HA in due diverse zone di disponibilità. Un cluster FSx viene sempre fornito in una coppia HA sincronizzata in una coppia di file system attivi-passivi per fornire ridondanza a livello di storage. L'implementazione multizona migliora ulteriormente l'elevata disponibilità in caso di guasto in una singola zona AWS.
Dimensionamento del cluster di archiviazione FSx. Un file system di storage Amazon FSx ONTAP fornisce fino a 160.000 IOPS SSD raw, fino a 4 GBps di throughput e una capacità massima di 192 TiB. Tuttavia, è possibile dimensionare il cluster in termini di IOPS forniti, throughput e limite di archiviazione (minimo 1.024 GiB) in base alle esigenze effettive al momento della distribuzione. La capacità può essere regolata dinamicamente al volo senza compromettere la disponibilità dell'applicazione.

Distribuzione della soluzione

Si presume che il database Oracle primario sia già distribuito nell'ambiente AWS EC2 all'interno di una VPC come punto di partenza per la configurazione di Data Guard. Il database primario viene distribuito utilizzando Oracle ASM per la gestione dello storage. Vengono creati due gruppi di dischi ASM, +DATA e +LOGS, per i file di dati Oracle, i file di registro, i file di controllo ecc. Per i dettagli sulla distribuzione di Oracle in AWS con ASM, fare riferimento ai seguenti report tecnici per assistenza.

Il database Oracle primario può essere eseguito su un FSx ONTAP o su qualsiasi altro storage tra quelli disponibili nell'ecosistema AWS EC2. Nella sezione seguente vengono fornite procedure di distribuzione dettagliate per la configurazione di Oracle Data Guard tra un'istanza primaria di EC2 DB con storage ASM e un'istanza di EC2 DB di standby con storage ASM.

Prerequisiti per la distribuzione

Details

Per la distribuzione sono richiesti i seguenti prerequisiti.

È stato configurato un account AWS e sono stati creati i segmenti di rete e VPC necessari all'interno del tuo account AWS.
Dalla console AWS EC2, è necessario distribuire almeno tre istanze EC2 Linux, una come istanza Oracle DB primaria, una come istanza Oracle DB di standby e un'istanza DB di destinazione clone per reporting, sviluppo, test ecc. Per maggiori dettagli sulla configurazione dell'ambiente, consultare il diagramma dell'architettura nella sezione precedente. Esaminare anche AWS"Guida utente per istanze Linux" per maggiori informazioni.
Dalla console AWS EC2, distribuisci cluster HA di storage Amazon FSx ONTAP per ospitare volumi Oracle che archiviano il database standby Oracle. Se non hai familiarità con la distribuzione dell'archiviazione FSx, consulta la documentazione"Creazione di file system FSx ONTAP" per istruzioni dettagliate.
I passaggi 2 e 3 possono essere eseguiti utilizzando il seguente toolkit di automazione Terraform, che crea un'istanza EC2 denominata ora_01 e un file system FSx denominato fsx_01 . Rivedere attentamente le istruzioni e modificare le variabili in base all'ambiente prima dell'esecuzione. Il modello può essere facilmente modificato in base alle proprie esigenze di distribuzione.
```
git clone https://github.com/NetApp-Automation/na_aws_fsx_ec2_deploy.git
```

Assicurati di aver allocato almeno 50 G nel volume radice dell'istanza EC2 per avere spazio sufficiente per organizzare i file di installazione di Oracle.

Preparare il database primario per Data Guard

Details

In questa dimostrazione, abbiamo configurato un database Oracle primario denominato db1 sull'istanza primaria del database EC2 con due gruppi di dischi ASM in configurazione di riavvio autonoma con file di dati nel gruppo di dischi ASM +DATA e area di ripristino flash nel gruppo di dischi ASM +LOGS. Di seguito vengono illustrate le procedure dettagliate per la configurazione del database primario per Data Guard. Tutti i passaggi devono essere eseguiti come proprietario del database, ovvero utente Oracle.

Configurazione del database primario db1 sull'istanza primaria del database EC2 ip-172-30-15-45. I gruppi di dischi ASM possono trovarsi su qualsiasi tipo di storage all'interno dell'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
--------------------------------------------------------------------------------

Da sqlplus, abilitare la registrazione forzata sul database primario.
```
alter database force logging;
```
Da sqlplus, abilitare il flashback sul primario. Flashback consente di ripristinare facilmente il database primario come standby dopo un failover.
```
alter database flashback on;
```
Configurare l'autenticazione del trasporto redo utilizzando il file password di Oracle: creare un file pwd sul database primario utilizzando l'utility orapwd se non è impostata e copiarlo nella directory $ORACLE_HOME/dbs del database di standby.

Crea log redo di standby sul DB primario con le stesse dimensioni del file di log online corrente. I gruppi di log sono un'aggiunta ai gruppi di file di log online. Il database primario può quindi passare rapidamente al ruolo di standby e iniziare a ricevere dati redo, se necessario.

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.

Da sqlplus, creare un pfile da spfile per la modifica.
```
create pfile='/home/oracle/initdb1.ora' from spfile;
```

Rivedere il pfile e aggiungere i seguenti parametri.

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

Da sqlplus, creare spfile nella directory ASM +DATA dal pfile rivisto nella directory /home/oracle.
```
create spfile='+DATA' from pfile='/home/oracle/initdb1.ora';
```

Individuare il file spfile appena creato nel gruppo di dischi +DATA (utilizzando l'utilità asmcmd se necessario). Utilizzare srvctl per modificare la griglia per avviare il database dal nuovo spfile come mostrato di seguito.

[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

Modificare tnsnames.ora per aggiungere db_unique_name per la risoluzione dei nomi.

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

Aggiungere il nome del servizio Data Guard db1_NY_DGMGRL.demo.netapp per il database primario al file 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

Arrestare e riavviare il database con srvctl e verificare che i parametri di Data Guard siano ora attivi.
```
srvctl stop database -d db1
```
```
srvctl start database -d db1
```

Questa operazione completa la configurazione del database primario per Data Guard.

Preparare il database di standby e attivare Data Guard

Details

Oracle Data Guard richiede la configurazione del kernel del sistema operativo e gli stack software Oracle, inclusi i set di patch sull'istanza EC2 DB di standby, per corrispondere all'istanza EC2 DB primaria. Per una gestione semplice e intuitiva, la configurazione di archiviazione del database dell'istanza EC2 DB di standby dovrebbe idealmente corrispondere anche a quella dell'istanza EC2 DB primaria, ad esempio per quanto riguarda nome, numero e dimensione dei gruppi di dischi ASM. Di seguito sono riportate le procedure dettagliate per la configurazione dell'istanza EC2 DB di standby per Data Guard. Tutti i comandi devono essere eseguiti come ID utente proprietario di Oracle.

Per prima cosa, rivedere la configurazione del database primario sull'istanza EC2 primaria. In questa dimostrazione, abbiamo configurato un database Oracle primario denominato db1 sull'istanza primaria del database EC2 con due gruppi di dischi ASM +DATA e +LOGS nella configurazione di riavvio autonoma. I gruppi di dischi ASM primari possono trovarsi su qualsiasi tipo di storage all'interno dell'ecosistema EC2.
Seguire le procedure nella documentazione"TR-4965: Distribuzione e protezione del database Oracle in AWS FSx/EC2 con iSCSI/ASM" per installare e configurare la griglia e l'istanza Oracle su EC2 DB in standby in modo che corrispondano al database primario. Lo spazio di archiviazione del database deve essere predisposto e allocato all'istanza EC2 DB di standby da FSx ONTAP con la stessa capacità di archiviazione dell'istanza EC2 DB primaria.

Fermati al passo 10 Oracle database installation sezione. Il database di standby verrà istanziato dal database primario utilizzando la funzione di duplicazione del database dbca.
Una volta installato e configurato il software Oracle, dalla directory $ORACLE_HOME dbs di standby, copiare la password Oracle dal database primario.
```
scp oracle@172.30.15.45:/u01/app/oracle/product/19.0.0/db1/dbs/orapwdb1 .
```

Creare il file tnsnames.ora con le seguenti voci.

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

Aggiungere il nome del servizio DB Data Guard al file 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

Imposta la home e il percorso dell'oracolo.

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

export PATH=$PATH:$ORACLE_HOME/bin

Utilizzare dbca per creare un'istanza del database standby dal database primario 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.

Convalida il database standby duplicato. Il database di standby appena duplicato viene inizialmente aperto in modalità SOLA LETTURA.

[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

Riavviare il database di standby in mount eseguire il comando seguente per attivare il ripristino gestito dal database di standby.

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.

Convalida lo stato di ripristino del database di standby. Nota il recovery logmerger In APPLYING_LOG azione.

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>

In questo modo si completa la configurazione della protezione di Data Guard per db1 da primario a standby con il ripristino standby gestito abilitato.

Configurazione di Data Guard Broker

Details

Oracle Data Guard Broker è un framework di gestione distribuito che automatizza e centralizza la creazione, la manutenzione e il monitoraggio delle configurazioni di Oracle Data Guard. La sezione seguente illustra come configurare Data Guard Broker per gestire l'ambiente Data Guard.

Avviare Data Guard Broker sui database primari e di standby con il seguente comando tramite sqlplus.
```
alter system set dg_broker_start=true scope=both;
```

Dal database primario, connettersi a Data Guard Borker come 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.

Crea e abilita la configurazione di 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)

Convalida lo stato del database all'interno del framework di gestione di 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>

In caso di errore, Data Guard Broker può essere utilizzato per eseguire il failover immediato del database primario in modalità standby.

Clona il database di standby per altri casi d'uso

Details

Il vantaggio principale dello staging del database standby su AWS FSx ONTAP in Data Guard è che può essere FlexClonato per soddisfare molti altri casi d'uso con un investimento minimo in termini di storage aggiuntivo. Nella sezione seguente, illustreremo come creare snapshot e clonare i volumi del database di standby montati e in fase di ripristino su FSx ONTAP per altri scopi, come DEV, TEST, REPORT, ecc., utilizzando lo strumento NetApp SnapCenter .

Di seguito sono riportate le procedure di alto livello per clonare un database READ/WRITE dal database standby fisico gestito in Data Guard utilizzando SnapCenter. Per istruzioni dettagliate su come impostare e configurare SnapCenter, fare riferimento a"Soluzioni di database cloud ibrido con SnapCenter" sezioni Oracle pertinenti.

Iniziamo creando una tabella di prova e inserendo una riga nella tabella di prova sul database primario. Verificheremo quindi se la transazione è passata allo standby e infine al 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

Aggiungi cluster di archiviazione FSx a Storage Systems in SnapCenter con IP di gestione del cluster FSx e credenziali fsxadmin.
Aggiungi AWS ec2-user a Credential In Settings .

Aggiungi l'istanza EC2 DB in standby e clona l'istanza EC2 DB a Hosts .

Screenshot che mostra questo passaggio nell'interfaccia grafica.

L'istanza clone del database EC2 dovrebbe avere stack software Oracle simili installati e configurati. Nel nostro caso di prova, l'infrastruttura grid e Oracle 19C sono stati installati e configurati, ma non è stato creato alcun database.

Creare una policy di backup personalizzata per il backup completo del database offline/montato.
Applicare la politica di backup per proteggere il database di standby in Resources scheda.
Fare clic sul nome del database per aprire la pagina dei backup del database. Selezionare un backup da utilizzare per la clonazione del database e fare clic su Clone pulsante per avviare il flusso di lavoro di clonazione.
Selezionare Complete Database Clone e assegnare un nome SID all'istanza clone.
Selezionare l'host clone che ospita il database clonato dal database di standby. Accettare l'impostazione predefinita per i file di dati, i file di controllo e i redo log. Verranno creati due gruppi di dischi ASM sull'host clone, corrispondenti ai gruppi di dischi sul database di standby.
Per l'autenticazione basata sul sistema operativo non sono necessarie credenziali del database. Abbinare le impostazioni home di Oracle a quelle configurate nell'istanza del database EC2 clone.
Se necessario, modificare i parametri del database clone e specificare gli script da eseguire prima della clonazione, se presenti.
Immettere SQL per l'esecuzione dopo la clonazione. Nella demo, abbiamo eseguito comandi per disattivare la modalità di archiviazione del database per un database dev/test/report.
Se lo desideri, configura la notifica via email.
Rivedi il riepilogo, clicca Finish per avviare il clone.
Monitora il lavoro di clonazione in Monitor scheda. Abbiamo osservato che ci vogliono circa 8 minuti per clonare un database di circa 300 GB di volume.
Convalida il database clone da SnapCenter, che viene immediatamente registrato in Resources scheda subito dopo l'operazione di clonazione.

Interroga il database clone dall'istanza EC2 clone. Abbiamo convalidato che la transazione di prova avvenuta nel database primario era stata trasferita al database 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>

In questo modo si completa la clonazione e la convalida di un nuovo database Oracle dal database di standby in Data Guard su storage FSx per DEV, TEST, REPORT o qualsiasi altro caso d'uso. In Data Guard è possibile clonare più database Oracle dallo stesso database standby.

Dove trovare ulteriori informazioni

Per saperne di più sulle informazioni descritte nel presente documento, consultare i seguenti documenti e/o siti web:

Concetti e amministrazione di Data Guard

"https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/index.html#Oracle%C2%AE-Data-Guard"
WP-7357: Best practice per la distribuzione di Oracle Database su EC2 e FSx

"Introduzione"
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: Riduzione dei costi di Oracle Active Data Guard con Amazon FSx ONTAP

Creating your file...

Scopo

Pubblico

Ambiente di test e convalida della soluzione

Architettura

Componenti hardware e software

Configurazione di Oracle Data Guard con ipotetica configurazione DR da NY a LA

Fattori chiave per la considerazione dell'implementazione

Distribuzione della soluzione

Prerequisiti per la distribuzione

Preparare il database primario per Data Guard

Preparare il database di standby e attivare Data Guard

Configurazione di Data Guard Broker

Clona il database di standby per altri casi d'uso

Dove trovare ulteriori informazioni