Skip to main content
NetApp Solutions
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

Collaboratori
PDF

Allen Cao, Niyaz Mohamed, NetApp

Questa soluzione fornisce una panoramica e dettagli sulla configurazione di Oracle Data Guard utilizzando AWS FSX ONTAP come storage di database Oracle in standby per ridurre i costi operativi e di licenza della soluzione ha/DR Oracle Data Guard in AWS.

Scopo

Oracle Data Guard garantisce disponibilità elevata, protezione dei dati e ripristino di emergenza per i dati aziendali in una configurazione di replica del database primario e di standby. Oracle Active Data Guard consente agli utenti di accedere ai database di standby mentre la replica dei dati è attiva dal database principale ai database di standby. Data Guard è una funzionalità di Oracle Database Enterprise Edition. Non richiede licenze separate. D'altra parte, Active Data Guard è un'opzione Oracle Database Enterprise Edition, pertanto richiede licenze separate. Più database di standby possono ricevere la replica dei dati da un database primario nella configurazione di Active Data Guard. Tuttavia, ogni database di standby aggiuntivo richiede una licenza Active Data Guard e un'ulteriore capacità di archiviazione come dimensione del database primario. I costi operativi si sommano rapidamente.

Se sei entusiasta di ridurre i costi operativi del tuo database Oracle e stai pianificando di configurare un sistema Active Data Guard in AWS, dovresti prendere in considerazione un'alternativa. Invece di Active Data Guard, utilizza Data Guard per eseguire la replica dal database primario a un singolo database di standby fisico sullo storage Amazon FSX ONTAP. Successivamente, è possibile clonare e aprire più copie di questo database di standby per accedere in lettura/scrittura e soddisfare molti altri casi d'utilizzo, come creazione di report, sviluppo, test, ecc. I risultati della rete offrono in modo efficace le funzionalità di Active Data Guard eliminando al contempo la licenza di Active Data Guard e i costi di storage aggiuntivi per ogni database di standby aggiuntivo. In questa documentazione, dimostreremo 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 backup del database di standby viene eseguito tramite snapshot e clonato per l'accesso in lettura/scrittura per i casi d'utilizzo, in base alle necessità.

Questa soluzione risolve i seguenti casi di utilizzo:

  • Oracle Data Guard tra un database primario su qualsiasi storage in AWS e il database in standby sullo storage Amazon FSX ONTAP.

  • Clonazione del database in standby mentre è chiuso per la replica dei dati per casi di utilizzo come reporting, sviluppo, test, ecc.

Pubblico

Questa soluzione è destinata alle seguenti persone:

  • Un DBA che ha configurato Oracle Active Data Guard in AWS per garantire disponibilità elevata, protezione dei dati e disaster recovery.

  • Un Solution Architect per database interessato alla configurazione di Oracle Active Data Guard nel cloud AWS.

  • Un amministratore dello storage che gestisce lo storage AWS FSX ONTAP con supporto per Oracle Data Guard.

  • Proprietario di applicazioni che desidera supportare Oracle Data Guard in un ambiente AWS FSX/EC2.

Ambiente di test e convalida della soluzione

Il test e la convalida di questa soluzione sono stati eseguiti in un ambiente di laboratorio AWS FSX ONTAP e EC2 che potrebbe non corrispondere all'ambiente di implementazione finale. Per ulteriori informazioni, vedere la sezione Fattori chiave per l'implementazione.

Architettura

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

Componenti hardware e software

Hardware

Storage FSX ONTAP

Versione corrente offerta da AWS

Un cluster FSX ha nello stesso VPC e nella stessa 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 in standby e la terza come server DB clone

Software

RedHat Linux

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

Implementazione dell'abbonamento a RedHat per il test

Oracle Grid Infrastructure

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 da NY a LA DR

Database

DB_UNIQUE_NAME

Nome servizio netto Oracle

Primario

DB1_NY

db1_NY.demo.netapp.com

Standby fisico

DB1_LA

db1_LA.demo.netapp.com

Fattori chiave per l'implementazione

  • Come funziona FlexClone Oracle Standby Database. AWS FSX ONTAP FlexClone fornisce copie condivise degli stessi volumi di database di standby scrivibili. Le copie dei volumi sono in realtà puntatori che si ricollegano ai blocchi di dati originali fino all'avvio di una nuova scrittura nel clone. ONTAP alloca quindi nuovi blocchi storage per le nuove scritture. Tutti gli io in lettura sono gestiti da blocchi di dati originali sotto replica attiva. Pertanto, i cloni sono molto efficienti in termini di storage, che possono essere utilizzati per molti altri casi di utilizzo con una nuova allocazione di storage minima e incrementale per i nuovi io in scrittura. Ciò consente un notevole risparmio sui costi di storage riducendo sostanzialmente l'ingombro dello storage 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 in standby per garantire prestazioni Oracle di alto livello.

  • Requisiti del software Oracle. in generale, un database di standby fisico deve avere la stessa versione iniziale del database principale, incluse le eccezioni al set di patch (PSE), gli aggiornamenti critici delle patch (CPU), e gli aggiornamenti del set di patch (PSU), a meno che non sia in corso un processo di applicazione della patch standby-first di Oracle Data Guard (come descritto nella nota di supporto Oracle 1265700,1 all'indirizzo "support.oracle.com"

  • Considerazioni sulla struttura della directory del database di standby. se possibile, i file di dati, i file di log e i file di controllo sui sistemi primario e di standby devono avere gli stessi nomi e nomi di percorso e utilizzare le convenzioni di denominazione OFA (Optimal Flexible Architecture). Anche le directory di archivio del database di standby devono essere identiche tra i siti, comprese le dimensioni e la struttura. Questa strategia consente ad altre operazioni quali backup, switchover e failover di eseguire la stessa serie di passaggi, riducendo la complessità della manutenzione.

  • Imponi modalità di registrazione. per proteggere dalle scritture dirette non registrate nel database primario che non possono essere propagate al database di standby, attivare IMPONI REGISTRAZIONE nel database primario prima di eseguire i backup dei file di dati per la creazione in standby.

  • Gestione archiviazione database. per semplicità operativa, Oracle consiglia di impostare Oracle Automatic Storage Management (Oracle ASM) e Oracle Managed Files (OMF) in una configurazione Oracle Data Guard in modo simmetrico sui database primari 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 M5 di tipo EC2 come istanza di calcolo per Oracle nelle implementazioni in produzione, perché è ottimizzata per il carico di lavoro del database. È necessario dimensionare l'istanza EC2 in modo appropriato in base al numero di vCPU e alla quantità di RAM in base ai requisiti effettivi del carico di lavoro.

  • Implementazione di cluster ha storage FSX a singola o multi-zona. in questi test e convalide, abbiamo implementato un cluster ha FSX in una singola zona di disponibilità AWS. Per l'implementazione in produzione, NetApp consiglia di implementare una coppia FSX ha in due diverse zone di disponibilità. Un cluster FSX viene sottoposto a provisioning in una coppia ha sincronizzata in una coppia di file system Active-passive per fornire ridondanza a livello di storage. L'implementazione multi-zona migliora ulteriormente l'alta disponibilità in caso di guasto in una singola zona AWS.

  • Dimensionamento del cluster di storage FSX. Un file system storage Amazon FSX ONTAP offre fino a 160.000 IOPS SSD raw, throughput fino a 4Gbps Gbps e una capacità massima di 192TiB PB. Tuttavia, è possibile dimensionare il cluster in termini di IOPS con provisioning, throughput e limite di storage (minimo 1,024 GiB) in base ai requisiti effettivi al momento dell'implementazione. La capacità può essere regolata dinamicamente in tempo reale senza influire sulla disponibilità delle applicazioni.

Implementazione della soluzione

Si presuppone che il tuo database Oracle primario sia già implementato nell'ambiente AWS EC2 all'interno di un VPC come punto di partenza per la configurazione di Data Guard. Il database primario viene implementato utilizzando Oracle ASM per la gestione dello storage. Vengono creati due gruppi di dischi ASM: +DATA e +LOG per i file di dati Oracle, i file di registro, i file di controllo e così via Per informazioni sull'implementazione di Oracle in AWS con ASM, consultare i seguenti report tecnici per ottenere aiuto.

Il tuo database Oracle primario può essere eseguito su un FSX ONTAP o su qualsiasi altro storage scelto all'interno dell'ecosistema AWS EC2. Nella sezione seguente vengono fornite le procedure di distribuzione dettagliate per l'impostazione di Oracle Data Guard tra un'istanza primaria di database da EC2 GB con spazio di archiviazione ASM e un'istanza di standby di database da EC2 GB con spazio di archiviazione ASM.

Prerequisiti per l'implementazione

Details

L'implementazione richiede i seguenti prerequisiti.

  1. È stato impostato un account AWS e sono stati creati i segmenti VPC e di rete necessari all'interno dell'account AWS.

  2. Dalla console AWS EC2 è necessario implementare almeno tre istanze Linux EC2 GB, una come istanza primaria di Oracle DB, una come istanza standby di Oracle DB e un'istanza clone di database di destinazione per reporting, sviluppo e test, ecc. Fare riferimento al diagramma dell'architettura nella sezione precedente per ulteriori informazioni sulla configurazione dell'ambiente. Consulta anche l'AWS "Guida utente per istanze Linux" per ulteriori informazioni.

  3. Dalla console AWS EC2, implementa i cluster ha di storage Amazon FSX ONTAP per ospitare volumi Oracle che archiviano il database di standby Oracle. Se non hai dimestichezza con l'implementazione dello storage FSX, consulta la documentazione "Creazione di file system FSX ONTAP" per istruzioni dettagliate.

  4. 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. Prima dell'esecuzione, rivedere attentamente le istruzioni e modificare le variabili in base all'ambiente in uso. Il modello può essere facilmente rivisto in base ai tuoi requisiti di implementazione.

    git clone https://github.com/NetApp-Automation/na_aws_fsx_ec2_deploy.git
Nota Assicurarsi di aver allocato almeno 50 G nel volume root dell'istanza EC2 per avere spazio sufficiente per la fase dei file di installazione Oracle.

Preparare il database primario per Data Guard

Details

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

  1. Configurazione del database primario DB1 sull'istanza primaria EC2 DB 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
--------------------------------------------------------------------------------

  2. Da sqlplus, abilitare la registrazione forzata su primario.

    alter database force logging;

  3. Da sqlplus, attivare flashback su primario. Flashback consente di ripristinare facilmente il database primario come standby dopo un failover.

    alter database flashback on;

  4. Configurare l'autenticazione del trasporto di ripristino utilizzando il file password Oracle - creare un file pwd sul primario utilizzando l'utilità orapwd se non è impostata e copiarlo nella directory $ORACLE_HOME/dbs del database di standby.

  5. Creare log di ripristino in standby sul database primario con le stesse dimensioni del file di log online corrente. I gruppi di log sono più di un gruppo di file di log online. Il database primario può quindi passare rapidamente al ruolo di standby e iniziare a ricevere i dati di 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.

  6. Da sqlplus, creare un pfile da spfile per la modifica.

    create pfile='/home/oracle/initdb1.ora' from spfile;

  7. Rivedere il file 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

  8. Da sqlplus, creare spfile nella directory ASM +DATA da pfile rivisto nella directory /home/oracle.

    create spfile='+DATA' from pfile='/home/oracle/initdb1.ora';

  9. Individuare il nuovo spfile creato in +DATA disk group (utilizzando l'utilità asmcmd se necessario). Utilizzare srvctl per modificare la griglia per avviare il database dal nuovo spfile come illustrato 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

  10. Modificare tnsnames.ora per aggiungere db_unique_name per la risoluzione del nome.

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

  11. Aggiungere il nome del servizio protezione dati 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

  1. Chiudere e riavviare il database con srvctl e convalidare che i parametri di protezione dati siano ora attivi.

    srvctl stop database -d db1
    srvctl start database -d db1

L'impostazione del database primario per Data Guard viene completata.

Preparare il database di standby e attivare Data Guard

Details

Oracle Data Guard richiede la configurazione del kernel del sistema operativo e gli stack di software Oracle, inclusi i set di patch sull'istanza EC2 DB di standby, in modo che corrispondano all'istanza primaria EC2 DB. Per semplificare la gestione e la semplicità, la configurazione dello storage del database di istanza EC2 DB di standby dovrebbe corrispondere idealmente anche all'istanza primaria EC2 DB, come il nome, il numero e la dimensione dei gruppi di dischi ASM. Di seguito sono riportate le procedure dettagliate per impostare l'istanza di standby EC2 DB per Data Guard. Tutti i comandi devono essere eseguiti come ID utente proprietario di oracle.

  1. Innanzitutto, esaminare la configurazione del database primario sull'istanza EC2 primaria. In questa dimostrazione, abbiamo configurato un database Oracle primario chiamato DB1 sull'istanza DB primaria EC2 con due gruppi di dischi ASM +DATA e +LOGS nella configurazione di riavvio standalone. I gruppi di dischi ASM primari possono trovarsi su qualsiasi tipo di storage all'interno dell'ecosistema EC2.

  2. Seguire le procedure riportate nella documentazione "TR-4965: Implementazione e protezione del database Oracle in AWS FSX/EC2 con iSCSI/ASM" Per installare e configurare Grid e Oracle sull'istanza EC2 DB di standby in modo che corrispondano al database primario. È necessario eseguire il provisioning e allocare lo storage del database all'istanza EC2 DB in standby da FSX ONTAP con la stessa capacità di storage dell'istanza EC2 DB primaria.

    Nota Fermarsi al passo 10 in Oracle database installation sezione. Il database di standby verrà creato un'istanza dal database primario utilizzando la funzione di duplicazione del database dbca.

  3. Una volta installato e configurato il software Oracle, copiare la password oracle dal database principale dalla directory $ORACLE_HOME dbs.

    scp oracle@172.30.15.45:/u01/app/oracle/product/19.0.0/db1/dbs/orapwdb1 .

  4. 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)
    )
  )

  5. Aggiungere il nome del servizio protezione dati DB 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

  6. Imposta home e path oracle.

    export ORACLE_HOME=/u01/app/oracle/product/19.0.0/db1
    export PATH=$PATH:$ORACLE_HOME/bin

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

  8. Convalidare il database di standby duplicato. Il nuovo database di standby duplicato si apre inizialmente in modalità di 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

  9. Riavviare il database di standby in mount preparare ed eseguire il seguente comando 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.

  10. Convalidare lo stato di ripristino del database di standby. Notare la recovery logmerger poll 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 viene completata l'impostazione della protezione Data Guard per DB1 da primario a standby con ripristino in standby gestito abilitato.

Impostare 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. Nella sezione seguente viene illustrato come configurare Data Guard Broker per la gestione dell'ambiente Data Guard.

  1. Avviare il broker di protezione dei dati su entrambi i database primari e di standby con il seguente comando tramite sqlplus.

    alter system set dg_broker_start=true scope=both;

  2. 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.

  3. Creare e abilitare 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)

  4. Convalidare lo stato del database nel 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 guasto, Data Guard Broker può essere utilizzato per eseguire il failover del database primario in standby istantaneamente.

Clonare il database di standby per altri casi di utilizzo

Details

Il principale vantaggio dello staging del database di standby su AWS FSX ONTAP in Data Guard è la possibilità di creare con FlexClone il supporto di molti altri casi di utilizzo con un investimento minimo nello storage aggiuntivo. Nella sezione seguente, mostreremo come creare snapshot e clonare i volumi di database di standby montati e in fase di ripristino in FSX ONTAP per altri scopi, come SVILUPPO, TEST, REPORT, ecc. utilizzo dello strumento NetApp SnapCenter.

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

  1. Si inizia con la creazione di una tabella di test e l'inserimento di una riga nella tabella di test sul database primario. Quindi, convalideremo se la transazione passa in 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

  2. Aggiungi cluster di storage FSX a. Storage Systems In SnapCenter con IP di gestione cluster FSX e credenziale fsxadmin.

    Schermata che mostra questo passaggio nella GUI.

  3. Aggiungi AWS EC2 utente a. Credential poll Settings.

    Schermata che mostra questo passaggio nella GUI.

  4. Aggiungere l'istanza di standby EC2 DB e clonare l'istanza EC2 DB a. Hosts.

    Schermata che mostra questo passaggio nella GUI.

    Nota L'istanza EC2 DB clone deve avere stack software Oracle simili installati e configurati. Nel nostro test, l'infrastruttura di rete e Oracle 19C sono stati installati e configurati, ma non è stato creato alcun database.

  5. Creare un criterio di backup personalizzato per il backup completo del database non in linea/montato.

    Schermata che mostra questo passaggio nella GUI.

  6. Applicare i criteri di backup per proteggere il database di standby in Resources scheda.

    Schermata che mostra questo passaggio nella GUI.

  7. Fare clic sul nome del database per aprire la pagina di backup del database. Selezionare un backup da utilizzare per il clone del database e fare clic su Clone per avviare il flusso di lavoro di clonazione.

    Schermata che mostra questo passaggio nella GUI.

  8. Selezionare Complete Database Clone E denominare il SID dell'istanza clone.

    Schermata che mostra questo passaggio nella GUI.

  9. Selezionare l'host clone che ospita il database clonato dal database di standby. Accettare il valore predefinito per i file di dati, i file di controllo e i registri di ripristino. Sull'host clone verranno creati due gruppi di dischi ASM corrispondenti ai gruppi di dischi del database di standby.

    Schermata che mostra questo passaggio nella GUI.

  10. Non sono necessarie credenziali di database per l'autenticazione basata sul sistema operativo. Associare l'impostazione home Oracle a quanto configurato nell'istanza del database EC2 clone.

    Schermata che mostra questo passaggio nella GUI.

  11. Se necessario, modificare i parametri del database clone e specificare gli script da eseguire prima di cloen, se necessario.

    Schermata che mostra questo passaggio nella GUI.

  12. Immettere SQL da eseguire dopo la clonazione. Nella demo, abbiamo eseguito comandi per disattivare la modalità di archiviazione del database per un database dev/test/report.

    Schermata che mostra questo passaggio nella GUI.

  13. Configurare la notifica e-mail, se lo si desidera.

    Schermata che mostra questo passaggio nella GUI.

  14. Rivedere il riepilogo, fare clic su Finish per avviare il clone.

    Schermata che mostra questo passaggio nella GUI.

  15. Monitorare il processo clone in Monitor scheda. Abbiamo osservato che erano necessari circa 8 minuti per clonare un database di circa 300GB TB nelle dimensioni del volume del database.

    Schermata che mostra questo passaggio nella GUI.

  16. Convalidare il database clone da SnapCenter, che viene registrato immediatamente in Resources subito dopo l'operazione di clonazione.

    Schermata che mostra questo passaggio nella GUI.

  17. Eseguire una query nel database clone dall'istanza clone EC2. Abbiamo validato la transazione di test verificatasi nel database primario in modo da ottenere la clonazione del database.

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

Ciò completa il clone e la convalida di un nuovo database Oracle dal database di standby in Data Guard sullo storage FSX per LO SVILUPPO, IL TEST, IL REPORT o qualsiasi altro caso di utilizzo. È possibile clonare più database Oracle dallo stesso database di standby in Data Guard.

Dove trovare ulteriori informazioni

Per ulteriori informazioni sulle informazioni descritte in questo documento, consultare i seguenti documenti e/o siti Web: