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

TR-5002: Riduzione dei costi di Oracle Active Data Guard con Azure NetApp Files

12/18/2024 Collaboratori

PDF

Allen Cao, Niyaz Mohamed, NetApp

La soluzione fornisce una panoramica e dettagli per la configurazione di Oracle Data Guard utilizzando Microsoft Azure NetApp Files (ANF) come storage primario e di standby per database al fine di ridurre i costi operativi e di licenza della soluzione ha/DR Oracle Data Guard nel cloud Azure.

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 ansioso di ridurre i costi operativi del tuo database Oracle e stai pianificando di configurare un servizio Active Data Guard nel cloud Azure, dovresti prendere in considerazione un'alternativa. Invece di Active Data Guard, utilizzare Data Guard per eseguire la replica dal database primario a un singolo database fisico di standby sullo storage Azure NetApp Files. Successivamente, più copie di questo database di standby possono essere clonate e aperte per l'accesso in lettura/scrittura per soddisfare molti altri casi di utilizzo, come la creazione di report, lo sviluppo, i test, ecc. i risultati della rete offrono in modo efficace le funzionalità di Active Data Guard eliminando la licenza di Active Data Guard. In questa documentazione, viene illustrato come configurare Oracle Data Guard con il database primario e il database di standby fisico esistenti sullo storage ANF. Viene eseguito il backup e il cloning del database di standby per l'accesso in lettura/scrittura per i casi d'utilizzo desiderati tramite il tool di gestione del database NetApp SnapCenter. Il team per i tecnici delle soluzioni NetApp fornisce inoltre un kit di strumenti di automazione per aggiornare i cloni in base a una pianificazione definita dall'utente per un Lifecycle management completo e automatizzato dei cloni del database senza richiedere l'intervento dell'utente.

Questa soluzione risolve i seguenti casi di utilizzo:

Implementazione di Oracle Data Guard tra un database primario e un database di standby fisico su storage Microsoft Azure NetApp Files nelle aree Azure.
Eseguire il backup e clonare il database di standby fisico per casi di utilizzo come reporting, sviluppo, test, ecc.
Lifecycle management per il refresh dei cloni dei database Oracle tramite automazione.

Pubblico

Questa soluzione è destinata alle seguenti persone:

Un DBA che configura Oracle Active Data Guard nel cloud Azure 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 Azure.
Un amministratore dello storage che gestisce storage Azure NetApp Files con supporto per Oracle Data Guard.
Un proprietario delle applicazioni che ama supportare Oracle Data Guard in un ambiente cloud Azure.

Ambiente di test e convalida della soluzione

Il test e la convalida di questa soluzione sono stati eseguiti in un'impostazione di laboratorio cloud Azure che potrebbe non corrispondere all'ambiente di implementazione utente effettivo. Per ulteriori informazioni, vedere la sezione Fattori chiave per l'implementazione.

Architettura

Questa immagine fornisce un quadro dettagliato dell'implementazione di Oracle Data Guard nel cloud Azure su ANF.

Componenti hardware e software

Hardware

Azure NetApp Files

Versione attuale offerta da Microsoft

Due pool di capacità 3 TiB, Standard Service Level, Auto QoS

Macchine virtuali Azure per server DB

B4ms standard (4 vcpus, 16 GB di memoria GiB)

Tre macchine virtuali DB, una come server DB primario, una come server DB di standby e la terza come server DB clone

Software

RedHat Linux

Red Hat Enterprise Linux 8,6 (LVM) - x64 Gen2

Implementazione dell'abbonamento a RedHat per il test

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

SnapCenter

Versione 6.0.1

Build 6.0.1.4487

NFS

Versione 3.0

DNFS abilitato per Oracle

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

Database

DB_UNIQUE_NAME

Nome servizio netto Oracle

Primario

NTAP_NY

NTAP_NY.internal.cloudapp.net

Standby

NTAP_LA

NTAP_LA.internal.cloudapp.net

Fattori chiave per l'implementazione

Clone database standby. Durante la ricezione e l'applicazione dei log delle transazioni dal database primario, è possibile clonare e montare un database fisico in standby su una macchina virtuale del database per supportare altri carichi di lavoro come SVILUPPO, TEST o report. Il clone può essere un clone sottile o spesso. Al momento, ANF supporta solo cloni thick, ovvero una copia completa del database di standby. L'opzione thin clone ANF verrà rilasciata a breve. Per le copie clonate in modo sottile di volumi di database, condivide gli stessi volumi DB del database di standby e utilizza la tecnologia copy-on-write per gli io in scrittura. 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à di FlexClone in caso di passaggio del database dallo storage primario a quello ANF di standby per mantenere prestazioni Oracle ad 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.
Dimensionamento di Azure VM. In questi test e convalide, è stato utilizzato Azure VM - Standard_B4ms con 4 vCPU di memoria and16 GiB. È necessario dimensionare correttamente la macchina virtuale del database di Azure in base al numero di vCPU e alla quantità di RAM in base ai requisiti effettivi dei carichi di lavoro.
Configurazione Azure NetApp Files. I Azure NetApp Files vengono allocati nell'account di storage Azure NetApp come Capacity Pools. In questi test e convalide, abbiamo distribuito un pool di capacità da 3 TiB per ospitare Oracle Primary nella regione est e un database di standby nella regione West 2. Il pool di capacità ANF offre tre livelli di servizio: Standard, Premium e Ultra. La capacità io del pool di capacità ANF si basa sulle dimensioni del pool di capacità e sul suo livello di servizio. Per la distribuzione in produzione, NetApp consiglia di valutare completamente i requisiti di throughput del database Oracle e di dimensionare di conseguenza il pool di capacità del database. Per la creazione di un pool di capacità, puoi impostare la QoS su Auto o Manual e la crittografia dei dati a riposo Single o Double.
Configurazione DNFS. Con DNFS, un database Oracle in esecuzione su Azure Virtual Machine con storage ANF può aumentare in maniera significativa l'i/o del client NFS nativo. L'implementazione automatica di Oracle utilizzando il toolkit di automazione NetApp configura automaticamente DNFS su NFSv3.

Implementazione della soluzione

Si presuppone che il database Oracle primario sia già distribuito in un ambiente cloud Azure all'interno di un VNET come punto di partenza per la configurazione di Oracle Data Guard. Idealmente, il database primario viene implementato su storage ANF con montaggio NFS. Tre punti di montaggio NFS vengono creati per lo storage del database Oracle: Mount /U01 per i file binari di Oracle, mount /U02 per i file di dati di Oracle e un file di controllo, mount /U03 per i file di log di Oracle correnti e archiviati e un file di controllo ridondante.

Il tuo database Oracle primario può anche essere eseguito su uno storage NetApp ONTAP o su qualsiasi altro storage scelto all'interno dell'ecosistema Azure o in un data center privato. La sezione seguente descrive le procedure di distribuzione dettagliate per la configurazione di Oracle Data Guard tra un database Oracle primario in Azure con storage ANF e un database Oracle DB fisico di standby in Azure con storage ANF.

Prerequisiti per l'implementazione

Details

L'implementazione richiede i seguenti prerequisiti.

È stato configurato un account cloud Azure e sono state create le subnet VNET e di rete necessarie all'interno dell'account Azure.
Dalla console del portale cloud Azure è necessario implementare almeno tre macchine virtuali Azure Linux, una come server Oracle DB primario, una come server Oracle DB di standby e un server DB clone di destinazione per il reporting, lo sviluppo e il test, ecc. per ulteriori dettagli sulla configurazione dell'ambiente, vedere lo schema dell'architettura nella sezione precedente. Per ulteriori informazioni, consultare anche Microsoft"Macchine virtuali Azure".
Il database Oracle primario deve essere installato e configurato nel server DB Oracle primario. D'altro canto, nel server Oracle DB di standby o nel server Oracle DB clone, viene installato solo il software Oracle e non vengono creati database Oracle. Idealmente, il layout delle directory dei file Oracle dovrebbe corrispondere esattamente a quello di tutti i server Oracle DB. Per dettagli sui consigli di NetApp per l'implementazione automatizzata di Oracle nel cloud Azure e ANF, fai riferimento ai seguenti report tecnici per assistenza.
- "TR-4987: Implementazione di Oracle semplificata e automatizzata su Azure NetApp Files con NFS"
  
  Assicurarsi di aver allocato almeno 128G MB nel volume root delle macchine virtuali di Azure in modo da avere spazio sufficiente per preparare i file di installazione di Oracle.
Dalla console del portale cloud Azure, implementa due pool di capacità dello storage ANF per ospitare volumi di database Oracle. I pool di capacità di archiviazione ANF devono trovarsi in aree diverse per simulare una configurazione DataGuard effettiva. Se non si ha dimestichezza con l'implementazione dello storage ANF, consultare la documentazione "QuickStart: Configurazione di Azure NetApp Files e creazione di un volume NFS" per istruzioni dettagliate.
Quando il database Oracle primario e il database Oracle di standby si trovano in due aree diverse, è necessario configurare un gateway VPN per consentire il flusso del traffico di dati tra due reti VLAN separate. La configurazione dettagliata della rete in Azure esula dall'ambito di questo documento. Le seguenti schermate forniscono un riferimento su come i gateway VPN sono configurati, connessi e il flusso di traffico di dati viene confermato nel laboratorio.

Gateway VPN Lab:

Il gateway vnet primario:

Stato di connessione del gateway VNET:

Verificare che i flussi di traffico siano stati stabiliti (fare clic su tre punti per aprire la pagina):

Preparare il database primario per Data Guard

Details

In questa dimostrazione, abbiamo configurato un database Oracle primario chiamato NTAP sul server DB Azure primario con tre punti di montaggio NFS: /U01 per il file binario Oracle, /U02 per i file di dati Oracle e un file di controllo Oracle, /U03 per i log attivi Oracle, i file di log archiviati e un file di controllo Oracle ridondante. Di seguito vengono illustrate le procedure dettagliate per l'impostazione del database primario per la protezione Oracle Data Guard. Tutti i passaggi devono essere eseguiti come proprietario del database Oracle o come utente predefinito oracle.

Il database NTAP primario sul server DB Azure primario orap.internal.cloudapp.net viene inizialmente implementato come database standalone con ANF come storage del database.

orap.internal.cloudapp.net:
resource group: ANFAVSRG
Location: East US
size: Standard B4ms (4 vcpus, 16 GiB memory)
OS: Linux (redhat 8.6)
pub_ip: 172.190.207.231
pri_ip: 10.0.0.4

[oracle@orap ~]$ df -h
Filesystem                 Size  Used Avail Use% Mounted on
devtmpfs                   7.7G  4.0K  7.7G   1% /dev
tmpfs                      7.8G     0  7.8G   0% /dev/shm
tmpfs                      7.8G  209M  7.5G   3% /run
tmpfs                      7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/mapper/rootvg-rootlv   22G  413M   22G   2% /
/dev/mapper/rootvg-usrlv    10G  2.1G  8.0G  21% /usr
/dev/sda1                  496M  181M  315M  37% /boot
/dev/mapper/rootvg-homelv  2.0G   47M  2.0G   3% /home
/dev/sda15                 495M  5.8M  489M   2% /boot/efi
/dev/mapper/rootvg-varlv   8.0G  1.1G  7.0G  13% /var
/dev/mapper/rootvg-tmplv    12G  120M   12G   1% /tmp
/dev/sdb1                   32G   49M   30G   1% /mnt
10.0.2.36:/orap-u02        500G  7.7G  493G   2% /u02
10.0.2.36:/orap-u03        450G  6.1G  444G   2% /u03
10.0.2.36:/orap-u01        100G  9.9G   91G  10% /u01

[oracle@orap ~]$ 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.
#
#
NTAP:/u01/app/oracle/product/19.0.0/NTAP:N

Accedere al server DB principale come utente oracle. Accedere al database tramite sqlplus, attivare la registrazione forzata su primario.

alter database force logging;

[oracle@orap admin]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Nov 26 20:12:02 2024
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 database force logging;

Database altered.

Da sqlplus, attivare flashback sul DB primario. Flashback consente di ripristinare facilmente il database primario come standby dopo un failover.
```
alter database flashback on;
```
```
SQL> alter database flashback on;

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

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 quando si verifica un failover e inizia a ricevere i dati di redo. Ripetere quattro volte il comando seguente per creare quattro file di registro di standby.

alter database add standby logfile thread 1 size 200M;

SQL> alter database add standby logfile thread 1 size 200M;

Database altered.

SQL> /

Database altered.

SQL> /

Database altered.

SQL> /

Database altered.


SQL> set lin 200
SQL> col member for a80
SQL> select group#, type, member from v$logfile;

    GROUP# TYPE    MEMBER
---------- ------- --------------------------------------------------------------------------------
         3 ONLINE  /u03/orareco/NTAP/onlinelog/redo03.log
         2 ONLINE  /u03/orareco/NTAP/onlinelog/redo02.log
         1 ONLINE  /u03/orareco/NTAP/onlinelog/redo01.log
         4 STANDBY /u03/orareco/NTAP/onlinelog/o1_mf_4__2m115vkv_.log
         5 STANDBY /u03/orareco/NTAP/onlinelog/o1_mf_5__2m3c5cyd_.log
         6 STANDBY /u03/orareco/NTAP/onlinelog/o1_mf_6__2m4d7dhh_.log
         7 STANDBY /u03/orareco/NTAP/onlinelog/o1_mf_7__2m5ct7g1_.log

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

Rivedere il file pfile e aggiungere i seguenti parametri.

vi /home/oracle/initNTAP.ora

Update the following parameters if not set:

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

Da sqlplus, ricreare spfile da pfile rivisto per sovrascrivere spfile esistente nella directory $ORACLE_HOME/dbs.
```
create spfile='$ORACLE_HOME/dbs/spfileNTAP.ora' from pfile='/home/oracle/initNTAP.ora';
```

Modificare Oracle tnsnames.ora nella directory $ORACLE_HOME/network/admin per aggiungere db_unique_name per la risoluzione del nome.

vi $ORACLE_HOME/network/admin/tnsnames.ora

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

NTAP_NY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = orap.internal.cloudapp.net)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = NTAP)
    )
  )

NTAP_LA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = oras.internal.cloudapp.net)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = NTAP)
    )
  )

LISTENER_NTAP =
  (ADDRESS = (PROTOCOL = TCP)(HOST = orap.internal.cloudapp.net)(PORT = 1521))

Se si sceglie di assegnare un nome al server DB Azure diverso da quello predefinito, aggiungere i nomi al file host locale per la risoluzione del nome host.

Aggiungere il nome del servizio protezione dati NTAP_NY_DGMGRL.internal.cloudapp.net per il database primario al file listener.ora.

vi $ORACLE_HOME/network/admin/listener.ora

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

LISTENER.NTAP =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = orap.internal.cloudapp.net)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER.NTAP =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = NTAP_NY_DGMGRL.internal.cloudapp.net)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/NTAP)
      (SID_NAME = NTAP)
    )
  )

Chiudere e riavviare il database tramite sqlplus e convalidare che i parametri di protezione dati siano ora attivi.

shutdown immediate;

startup;

SQL> show parameter name

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

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      NTAP_NY.internal.cloudapp.net
SQL> sho parameter log_archive_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest                     string
log_archive_dest_1                   string      LOCATION=USE_DB_RECOVERY_FILE_
                                                 DEST VALID_FOR=(ALL_LOGFILES,A
                                                 LL_ROLES) DB_UNIQUE_NAME=NTAP_
                                                 NY
log_archive_dest_10                  string
log_archive_dest_11                  string
log_archive_dest_12                  string
log_archive_dest_13                  string
log_archive_dest_14                  string
log_archive_dest_15                  string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_16                  string
log_archive_dest_17                  string
log_archive_dest_18                  string
log_archive_dest_19                  string
log_archive_dest_2                   string      SERVICE=NTAP_LA ASYNC VALID_FO
                                                 R=(ONLINE_LOGFILES,PRIMARY_ROL
                                                 E) DB_UNIQUE_NAME=NTAP_LA
log_archive_dest_20                  string
log_archive_dest_21                  string
.
.

Questa operazione completa l'impostazione 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 sul server DB di standby, in modo che corrispondano al server DB primario. Per semplificare la gestione e la semplicità, la configurazione dello storage del database del server DB di standby dovrebbe idealmente corrispondere anche al server DB primario, come il layout della directory del database e le dimensioni dei punti di montaggio NFS. Di seguito sono riportate le procedure dettagliate per la configurazione del server Oracle DB di standby e l'attivazione di Oracle DataGuard per la protezione ha/DR. Tutti i comandi devono essere eseguiti come id utente predefinito del proprietario di Oracle oracle .

Innanzitutto, esaminare la configurazione del database primario sul server database Oracle primario. In questa dimostrazione, abbiamo configurato un database Oracle primario, chiamato NTAP, nel server DB primario, con tre mount NFS sullo storage ANF.
Se si segue la documentazione NetApp TR-4987 per configurare il server database di standby Oracle "TR-4987: Implementazione di Oracle semplificata e automatizzata su Azure NetApp Files con NFS", utilizzare un tag -t software_only_install nel passaggio 2 di per eseguire l'installazione automatica di Playbook execution Oracle. La sintassi del comando modificata è elencata di seguito. Il tag consente di installare e configurare lo stack software Oracle, ma non di creare un database.
```
ansible-playbook -i hosts 4-oracle_config.yml -u azureuser -e @vars/vars.yml -t software_only_install
```

La configurazione del server Oracle DB in standby nel laboratorio dimostrativo.

oras.internal.cloudapp.net:
resource group: ANFAVSRG
Location: West US 2
size: Standard B4ms (4 vcpus, 16 GiB memory)
OS: Linux (redhat 8.6)
pub_ip: 172.179.119.75
pri_ip: 10.0.1.4

[oracle@oras ~]$ df -h
Filesystem                 Size  Used Avail Use% Mounted on
devtmpfs                   7.7G     0  7.7G   0% /dev
tmpfs                      7.8G     0  7.8G   0% /dev/shm
tmpfs                      7.8G  265M  7.5G   4% /run
tmpfs                      7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/mapper/rootvg-rootlv   22G  413M   22G   2% /
/dev/mapper/rootvg-usrlv    10G  2.1G  8.0G  21% /usr
/dev/sda1                  496M  181M  315M  37% /boot
/dev/mapper/rootvg-varlv   8.0G  985M  7.1G  13% /var
/dev/mapper/rootvg-homelv  2.0G   52M  2.0G   3% /home
/dev/mapper/rootvg-tmplv    12G  120M   12G   1% /tmp
/dev/sda15                 495M  5.8M  489M   2% /boot/efi
/dev/sdb1                   32G   49M   30G   1% /mnt
10.0.3.36:/oras-u01        100G  9.5G   91G  10% /u01
10.0.3.36:/oras-u02        500G  8.1G  492G   2% /u02
10.0.3.36:/oras-u03        450G  4.8G  446G   2% /u03

Una volta installato e configurato il software Oracle, impostare home e percorso oracle. Inoltre, dalla directory $ORACLE_HOME dbs di standby, copiare la password oracle dal database principale se non è stata eseguita questa operazione.
```
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/NTAP
```
```
export PATH=$PATH:$ORACLE_HOME/bin
```
```
scp oracle@10.0.0.4:$ORACLE_HOME/dbs/orapwNTAP .
```

Aggiorna il file tnsnames.ora con le seguenti voci.

vi $ORACLE_HOME/network/admin/tnsnames.ora

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

NTAP_NY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = orap.internal.cloudapp.net)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = NTAP)
    )
  )

NTAP_LA =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = oras.internal.cloudapp.net)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = NTAP)
    )
  )

Aggiungere il nome del servizio protezione dati DB al file listener.ora.

vi $ORACLE_HOME/network/admin/listener.ora

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

LISTENER.NTAP =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = oras.internal.cloudapp.net)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = NTAP)
    )
  )

SID_LIST_LISTENER.NTAP =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = NTAP_LA_DGMGRL.internal.cloudapp.net)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/NTAP)
      (SID_NAME = NTAP)
    )
  )

LISTENER =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = oras.internal.cloudapp.net)(PORT = 1521))
  )

Avviare dbca per creare un'istanza del database di standby dal database primario NTAP.

dbca -silent -createDuplicateDB -gdbName NTAP -primaryDBConnectionString orap.internal.cloudapp.net:1521/NTAP_NY.internal.cloudapp.net -sid NTAP -initParams fal_server=NTAP_NY -createAsStandby -dbUniqueName NTAP_LA

[oracle@oras admin]$ dbca -silent -createDuplicateDB -gdbName NTAP -primaryDBConnectionString orap.internal.cloudapp.net:1521/NTAP_NY.internal.cloudapp.net -sid NTAP -initParams fal_server=NTAP_NY -createAsStandby -dbUniqueName NTAP_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/NTAP_LA/NTAP_LA.log" for further details.

Convalidare il database di standby duplicato. Il nuovo database di standby duplicato si apre inizialmente in modalità di SOLA LETTURA.

[oracle@oras admin]$ 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.
#
#
NTAP:/u01/app/oracle/product/19.0.0/NTAP:N
[oracle@oras admin]$ export ORACLE_SID=NTAP
[oracle@oras admin]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Nov 26 23:04:07 2024
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
--------- --------------------
NTAP      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      NTAP
db_unique_name                       string      NTAP_LA
global_names                         boolean     FALSE
instance_name                        string      NTAP
lock_name_space                      string
log_file_name_convert                string
pdb_file_name_convert                string
processor_group_name                 string

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      NTAP_LA.internal.cloudapp.net
SQL> show parameter log_archive_config

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

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_server                           string      NTAP_NY
SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u02/oradata/NTAP/system01.dbf
/u02/oradata/NTAP/sysaux01.dbf
/u02/oradata/NTAP/undotbs01.dbf
/u02/oradata/NTAP/pdbseed/system01.dbf
/u02/oradata/NTAP/pdbseed/sysaux01.dbf
/u02/oradata/NTAP/users01.dbf
/u02/oradata/NTAP/pdbseed/undotbs01.dbf
/u02/oradata/NTAP/NTAP_pdb1/system01.dbf
/u02/oradata/NTAP/NTAP_pdb1/sysaux01.dbf
/u02/oradata/NTAP/NTAP_pdb1/undotbs01.dbf
/u02/oradata/NTAP/NTAP_pdb1/users01.dbf

NAME
--------------------------------------------------------------------------------
/u02/oradata/NTAP/NTAP_pdb2/system01.dbf
/u02/oradata/NTAP/NTAP_pdb2/sysaux01.dbf
/u02/oradata/NTAP/NTAP_pdb2/undotbs01.dbf
/u02/oradata/NTAP/NTAP_pdb2/users01.dbf
/u02/oradata/NTAP/NTAP_pdb3/system01.dbf
/u02/oradata/NTAP/NTAP_pdb3/sysaux01.dbf
/u02/oradata/NTAP/NTAP_pdb3/undotbs01.dbf
/u02/oradata/NTAP/NTAP_pdb3/users01.dbf

19 rows selected.

SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------------
/u02/oradata/NTAP/control01.ctl
/u03/orareco/NTAP_LA/control02.ctl

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

    GROUP# TYPE    MEMBER
---------- ------- --------------------------------------------------------------------------------
         1 ONLINE  /u03/orareco/NTAP_LA/onlinelog/o1_mf_1_mndl6mxh_.log
         2 ONLINE  /u03/orareco/NTAP_LA/onlinelog/o1_mf_2_mndl7jdb_.log
         3 ONLINE  /u03/orareco/NTAP_LA/onlinelog/o1_mf_3_mndl8f03_.log
         4 STANDBY /u03/orareco/NTAP_LA/onlinelog/o1_mf_4_mndl99m7_.log
         5 STANDBY /u03/orareco/NTAP_LA/onlinelog/o1_mf_5_mndlb67d_.log
         6 STANDBY /u03/orareco/NTAP_LA/onlinelog/o1_mf_6_mndlc2tw_.log
         7 STANDBY /u03/orareco/NTAP_LA/onlinelog/o1_mf_7_mndlczhb_.log

7 rows selected.

Riavviare il database di standby in mount fase 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 6442449688 bytes
Fixed Size                  9177880 bytes
Variable Size            1090519040 bytes
Database Buffers         5335154688 bytes
Redo Buffers                7598080 bytes
Database mounted.
SQL> alter database recover managed standby database disconnect from session;

Database altered.

Convalidare lo stato di ripristino del database di standby. Notare la recovery logmerger poll APPLYING_LOG azione.
```
SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS;
```

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

ROLE                        THREAD#  SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
post role transition              0          0 IDLE
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         18 APPLYING_LOG
managed recovery                  0          0 IDLE
RFS async                         1         18 IDLE
RFS ping                          1         18 IDLE
archive redo                      0          0 IDLE
redo transport timer              0          0 IDLE

ROLE                        THREAD#  SEQUENCE# ACTION
------------------------ ---------- ---------- ------------
gap manager                       0          0 IDLE
archive redo                      0          0 IDLE
archive redo                      0          0 IDLE
redo transport monitor            0          0 IDLE
log writer                        0          0 IDLE
archive local                     0          0 IDLE

17 rows selected.

SQL>

In questo modo viene completata l'impostazione della protezione Data Guard per NTAP 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.

Avviare il broker di protezione dei dati sia sul database primario che su quello 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@orap ~]$ dgmgrl sys@NTAP_NY
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Dec 11 20:53:20 2024
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 "NTAP_NY"
Connected as SYSDBA.
DGMGRL>

Creare e abilitare la configurazione di Data Guard Broker.

DGMGRL> create configuration dg_config as primary database is NTAP_NY connect identifier is NTAP_NY;
Configuration "dg_config" created with primary database "ntap_ny"
DGMGRL> add database NTAP_LA as connect identifier is NTAP_LA;
Database "ntap_la" added
DGMGRL> enable configuration;
Enabled.
DGMGRL> show configuration;

Configuration - dg_config

  Protection Mode: MaxPerformance
  Members:
  ntap_ny - Primary database
    ntap_la - Physical standby database

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 3 seconds ago)

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 errore, Data Guard Broker può essere utilizzato per eseguire il failover del database primario in standby istantaneamente. Se Fast-Start Failover è attivato, Data Guard Broker può eseguire il failover del database primario in standby quando viene rilevato un errore senza l'intervento dell'utente.

Clonare il database di standby per altri casi di utilizzo

Details

Il vantaggio principale dell'hosting del database di standby Oracle su ANF nella configurazione di Oracle Data Guard è che può essere rapidamente clonato per soddisfare molti altri casi di utilizzo con un investimento di storage aggiuntivo minimo se è abilitato un thin clone. NetApp consiglia di utilizzare lo strumento UI di SnapCenter per gestire il database Oracle DataGuard. Nella sezione seguente, mostreremo come creare snapshot e clonare i volumi di database di standby montati e in fase di ripristino su ANF per altri scopi, come SVILUPPO, TEST, REPORT, ecc., utilizzando lo 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 Oracle Data Guard utilizzando SnapCenter. Per istruzioni dettagliate su come configurare SnapCenter per Oracle su ANF, fare riferimento al documento TR-4988 "Backup, ripristino e cloning di database Oracle su ANF con SnapCenter" per ulteriori informazioni.

Si inizia la convalida dell'utilizzo creando una tabella di test e inserendo una riga nella tabella di test nel database primario. Quindi, si convaliderà che la transazione attraversa fino alla modalità standby e infine il clone.

[oracle@orap ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Dec 11 16:33:17 2024
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=ntap_pdb1;

Session altered.

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

Table created.

SQL> insert into test values(1, sysdate, 'a test transaction at primary database NTAP on DB server orap.internal.cloudapp.net');

1 row created.

SQL> commit;

Commit complete.

SQL> select * from test;

        ID
----------
DT
---------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
         1
11-DEC-24 04.38.44.000000 PM
a test transaction at primary database NTAP on DB server orap.internal.cloudapp.
net


SQL> select instance_name, host_name from v$instance;

INSTANCE_NAME
----------------
HOST_NAME
----------------------------------------------------------------
NTAP
orap


SQL>

Nella configurazione di SnapCenter, un utente unix (azureuser per la demo) e una credenziale Azure (Azure_anf per la demo) sono stati aggiunti a Credential in Settings.
Utilizzare la credenziale Azure_ANF per aggiungere l'archiviazione ANF a Storage Systems. Se disponi di più account storage ANF nella partizione Azure, fai clic sull'elenco a discesa per scegliere l'account storage giusto. Per questa dimostrazione, abbiamo creato due account storage Oracle dedicati.

Tutti i server Oracle DB sono stati aggiunti a SnapCenter Hosts .

Schermata che mostra questo passaggio nella GUI.

Il server DB clone deve avere stack software Oracle identici installati e configurati. Nel nostro test case, il software Oracle 19C è installato e configurato, ma non è stato creato alcun database.

Creare un criterio di backup personalizzato per il backup completo del database non in linea/montato.
Applicare i criteri di backup per proteggere il database di standby nella Resources scheda. Quando viene rilevato inizialmente, lo stato del database viene visualizzato come Not protected.
È possibile attivare un backup manualmente o impostarlo su una pianificazione a un'ora prestabilita dopo l'applicazione di un criterio di backup.
Dopo un backup, 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 sul Clone pulsante per avviare il flusso di lavoro dei cloni.
Selezionare Complete Database Clone e assegnare un nome al SID dell'istanza clone.
Selezionare il server DB clone, che ospita il database clonato dal database di standby. Accettare il valore predefinito per i file di dati, ripetere i log. Mettere un controlfile sul punto di montaggio /U03.
Non sono necessarie credenziali di database per l'autenticazione basata sul sistema operativo. Associare le impostazioni iniziali Oracle a quelle configurate sul server DB clone.
Se necessario, modificare i parametri del database clone, ad esempio la riduzione delle dimensioni di PGA o SGA per un database clone. Specificare gli script da eseguire prima del clone, se presenti.
Immettere SQL da eseguire dopo il clone. Nella demo, abbiamo eseguito comandi per disattivare la modalità di archiviazione del database per un database dev/test/report.
Configurare la notifica e-mail, se lo si desidera.
Rivedere il riepilogo, fare clic su Finish per avviare il clone.
Monitorare il lavoro di clonazione nella Monitor scheda. Abbiamo osservato che erano necessari circa 14 minuti per clonare un database di circa 950GB TB nelle dimensioni del volume del database.
Convalidare il database clone da SnapCenter, che viene registrato immediatamente in Resources subito dopo l'operazione di clonazione.

Eseguire una query sul database clone dal server DB clone. Abbiamo validato la transazione di test verificatasi nel database primario in base al database clone.

[oracle@orac ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Dec 11 20:16:09 2024
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
--------- -------------------- ------------
NTAPDEV   READ WRITE           NOARCHIVELOG

SQL> select instance_name, host_name from v$instance;

INSTANCE_NAME
----------------
HOST_NAME
----------------------------------------------------------------
NTAPDEV
orac


SQL> alter pluggable database all open;

Pluggable database altered.

SQL> alter pluggable database all save state;

Pluggable database altered.


SQL> alter session set container=ntap_pdb1;

Session altered.

SQL> select * from test;

        ID
----------
DT
---------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
         1
11-DEC-24 04.38.44.000000 PM
a test transaction at primary database NTAP on DB server orap.internal.cloudapp.
net

La dimostrazione del clone del database di standby Oracle in Oracle Data Guard sullo storage Azure ANF per lo SVILUPPO, IL TEST, IL REPORT o qualsiasi altro caso di utilizzo è completata. È possibile clonare più database Oracle dallo stesso database di standby in Oracle Data Guard su ANF.

Dove trovare ulteriori informazioni

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

Azure NetApp Files

"https://azure.microsoft.com/en-us/products/netapp"
TR-4988: Backup, recovery e cloning di database Oracle su ANF con SnapCenter

"https://docs.netapp.com/us-en/netapp-solutions/databases/snapctr_ora_azure_anf.html"
TR-4987: Implementazione di Oracle semplificata e automatizzata su Azure NetApp Files con NFS

"https://docs.netapp.com/us-en/netapp-solutions/databases/automation_ora_anf_nfs.html"
Concetti e amministrazione di Oracle Data Guard

"https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/index.html#Oracle%C2%AE-Data-Guard"

TR-5002: Riduzione dei costi di Oracle Active Data Guard con Azure NetApp Files

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

Fattori chiave per l'implementazione

Implementazione della soluzione

Prerequisiti per l'implementazione

Preparare il database primario per Data Guard

Preparare il database di standby e attivare Data Guard

Impostare Data Guard Broker

Clonare il database di standby per altri casi di utilizzo

Dove trovare ulteriori informazioni