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

08/18/2025 Collaboratori

PDF

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

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 nel cloud Azure, dovresti prendere in considerazione un'alternativa. Invece di Active Data Guard, utilizzare Data Guard per replicare dal database primario a un singolo database di standby fisico nell'archiviazione di Azure NetApp Files . Successivamente, è possibile clonare più copie di questo database di standby e aprirle per l'accesso in lettura/scrittura, al fine di soddisfare molti altri casi d'uso, quali reporting, sviluppo, test, ecc. Il risultato finale fornisce in modo efficace le funzionalità di Active Data Guard, eliminando al contempo la licenza di Active Data Guard. In questa documentazione, illustriamo come configurare Oracle Data Guard con il database primario esistente e il database standby fisico su storage ANF. Il database di standby viene sottoposto a backup e clonato per l'accesso in lettura/scrittura per i casi d'uso desiderati tramite lo strumento di gestione del database NetApp SnapCenter . Il team di NetApp Solutions Engineering fornisce inoltre un kit di strumenti di automazione per aggiornare i cloni in base alla pianificazione definita dall'utente, per una gestione completa e automatizzata del ciclo di vita dei cloni del database, senza necessità di intervento da parte dell'utente.

Questa soluzione affronta i seguenti casi d'uso:

Implementazione di Oracle Data Guard tra un database primario e un database di standby fisico su un archivio Microsoft Azure NetApp Files nelle regioni di Azure.
Eseguire il backup e la clonazione del database di standby fisico per soddisfare casi d'uso quali reporting, sviluppo, test, ecc.
Gestione del ciclo di vita dell'aggiornamento dei cloni del database Oracle tramite automazione.

Pubblico

Questa soluzione è destinata alle seguenti persone:

Un DBA che configura Oracle Active Data Guard nel cloud Azure per garantire elevata disponibilità, protezione dei dati e ripristino di emergenza.
Architetto di soluzioni di database interessato alla configurazione di Oracle Active Data Guard nel cloud Azure.
Un amministratore di storage che gestisce lo storage Azure NetApp Files che supporta Oracle Data Guard.
Un proprietario di applicazioni a cui piace installare 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 ambiente di laboratorio cloud di Azure che potrebbe non corrispondere all'effettivo ambiente di distribuzione dell'utente. 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 nel cloud Azure su ANF.

Componenti hardware e software

Hardware

Azure NetApp Files

Versione attuale offerta da Microsoft

Due pool di capacità da 3 TiB, livello di servizio standard, QoS automatico

Macchine virtuali di Azure per server DB

Standard B4ms (4 vCPU, 16 GiB di memoria)

Tre VM 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

Abbonamento RedHat distribuito per i 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

Versione 6.0.1.4487

NFS

Versione 3.0

dNFS abilitato per Oracle

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

Banca dati

DB_NOME_UNICO

Nome del servizio Oracle Net

Primario

NTAP_NY

NTAP_NY.internal.cloudapp.net

Stand-by

NTAP_LA

NTAP_LA.internal.cloudapp.net

Fattori chiave per la considerazione dell'implementazione

Clone del database di standby. Durante la ricezione e l'applicazione dei registri delle transazioni dal database primario, il database di standby fisico può essere clonato e montato su una VM DB per supportare altri carichi di lavoro quali DEV, TEST o Report. Il clone può essere sottile o spesso. Al momento, ANF supporta solo il thick clone, ovvero una copia completa del database standby. L'opzione clone sottile ANF sarà rilasciata a breve. Per copie clonate in modo sottile di volumi di database, condivide gli stessi volumi di database del database di standby e utilizza la tecnologia copy-on-write per gestire gli I/O di scrittura. 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 ANF 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.
Dimensionamento delle VM di Azure. In questi test e convalide abbiamo utilizzato una VM di Azure - Standard_B4ms con 4 vCPU e 16 GiB di memoria. È necessario dimensionare la VM di Azure DB in modo appropriato per il numero di vCPU e la quantità di RAM in base ai requisiti effettivi del carico di lavoro.
* Configurazione Azure NetApp Files .* I Azure NetApp Files vengono allocati nell'account di archiviazione di 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 East e un database standby nella regione West 2. Il pool di capacità ANF prevede tre livelli di servizio: Standard, Premium e Ultra. La capacità IO del pool di capacità ANF si basa sulla dimensione del pool di capacità e sul suo livello di servizio. Per l'implementazione in produzione, NetApp consiglia di effettuare una valutazione completa dei requisiti di throughput del database Oracle e di dimensionare di conseguenza il pool di capacità del database. Durante la creazione di un pool di capacità, è possibile impostare QoS su Automatico o Manuale e la crittografia dei dati a riposo su Singola o Doppia.
Configurazione dNFS. Utilizzando dNFS, un database Oracle in esecuzione su una macchina virtuale di Azure con storage ANF può gestire un I/O significativamente maggiore rispetto al client NFS nativo. La distribuzione Oracle automatizzata tramite il toolkit di automazione NetApp configura automaticamente dNFS su NFSv3.

Distribuzione della soluzione

Si presuppone che il database Oracle primario sia già distribuito in un ambiente cloud Azure all'interno di una rete virtuale come punto di partenza per la configurazione di Oracle Data Guard. Idealmente, il database primario viene distribuito su un archivio ANF con montaggio NFS. Vengono creati tre punti di montaggio NFS per l'archiviazione del database Oracle: mount /u01 per i file binari Oracle, mount /u02 per i file di dati Oracle e un file di controllo, mount /u03 per i file di registro Oracle correnti e archiviati e un file di controllo ridondante.

Il database Oracle primario può anche essere eseguito su un archivio NetApp ONTAP o su qualsiasi altro archivio a scelta all'interno dell'ecosistema Azure o di un data center privato. Nella sezione seguente vengono fornite procedure di distribuzione dettagliate per la configurazione di Oracle Data Guard tra un Oracle DB primario in Azure con storage ANF e un Oracle DB di standby fisico in Azure con storage ANF.

Prerequisiti per la distribuzione

Details

Per la distribuzione sono richiesti i seguenti prerequisiti.

È stato configurato un account cloud Azure e sono state create le subnet di rete e la rete virtuale necessarie all'interno dell'account Azure.
Dalla console del portale cloud di Azure, è necessario distribuire almeno tre VM Azure Linux, una come server Oracle DB primario, una come server Oracle DB di standby e un server DB di destinazione clone per reporting, sviluppo, test ecc. Per maggiori dettagli sulla configurazione dell'ambiente, vedere il diagramma dell'architettura nella sezione precedente. Esaminare anche Microsoft"Macchine virtuali di Azure" per maggiori informazioni.
Il database Oracle primario avrebbe dovuto essere installato e configurato nel server Oracle DB primario. D'altro canto, nel server Oracle DB di standby o nel server Oracle DB clone, viene installato solo il software Oracle e non viene creato alcun database Oracle. Idealmente, il layout delle directory dei file Oracle dovrebbe corrispondere esattamente su tutti i server Oracle DB. Per maggiori dettagli sulle raccomandazioni NetApp per la distribuzione automatizzata di Oracle nel cloud Azure e ANF, fare riferimento ai seguenti report tecnici.
- "TR-4987: Distribuzione Oracle semplificata e automatizzata su Azure NetApp Files con NFS"
  
  Assicurati di aver allocato almeno 128 GB nel volume radice delle VM di Azure per avere spazio sufficiente per organizzare i file di installazione di Oracle.
Dalla console del portale cloud di Azure, distribuire due pool di capacità di archiviazione ANF per ospitare i volumi del database Oracle. I pool di capacità di archiviazione ANF devono essere situati in regioni diverse per imitare una vera configurazione DataGuard. Se non si ha familiarità con la distribuzione dell'archiviazione ANF, consultare la documentazione"Avvio rapido: configurare Azure NetApp Files e creare un volume NFS" per istruzioni dettagliate.
Quando il database Oracle primario e il database Oracle di standby si trovano in due regioni diverse, è necessario configurare un gateway VPN per consentire il flusso del traffico dati tra due reti virtuali separate. La configurazione dettagliata della rete in Azure esula dallo scopo di questo documento. Gli screenshot seguenti forniscono alcuni riferimenti su come i gateway VPN sono configurati e connessi e su come il flusso del traffico dati viene confermato in laboratorio.

Gateway VPN di laboratorio:

Il gateway vnet primario:

Stato della connessione del gateway Vnet:

Verificare che i flussi di traffico siano stabiliti (cliccare sui tre punti per aprire la pagina):

Preparare il database primario per Data Guard

Details

In questa dimostrazione, abbiamo configurato un database Oracle primario denominato NTAP sul server Azure DB primario con tre punti di montaggio NFS: /u01 per il 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 la configurazione del database primario per la protezione Oracle Data Guard. Tutti i passaggi devono essere eseguiti come proprietario del database Oracle o come predefinito oracle utente.

Il database primario NTAP sul server primario di Azure DB orap.internal.cloudapp.net viene inizialmente distribuito come database autonomo con ANF come archivio 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

Accedi al server DB primario come utente Oracle. Accedi al database tramite sqlplus, abilita la registrazione forzata sul database 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, abilitare il 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 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 quando si verifica un failover e inizia a ricevere dati redo. Ripetere il seguente comando quattro volte 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 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, ricrea spfile dal pfile rivisto per sovrascrivere lo 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 dei nomi.

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 al server Azure DB un nome diverso da quello predefinito, aggiungere i nomi al file host locale per la risoluzione dei nomi host.

Aggiungere il nome del servizio Data Guard 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)
    )
  )

Arrestare e riavviare il database tramite sqlplus e verificare che i parametri di Data Guard 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 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 sul server DB di standby, per corrispondere al server DB primario. Per una gestione semplice e intuitiva, la configurazione dell'archiviazione del database del server DB di standby dovrebbe idealmente corrispondere anche a quella del server DB primario, ad esempio il layout della directory del database e le dimensioni dei punti di montaggio NFS. Di seguito sono riportate le procedure dettagliate per configurare il server Oracle DB di standby e attivare Oracle DataGuard per la protezione HA/DR. Tutti i comandi devono essere eseguiti come ID utente proprietario Oracle predefinito oracle .

Per prima cosa, rivedere la configurazione del database primario sul server Oracle DB primario. In questa dimostrazione, abbiamo configurato un database Oracle primario denominato NTAP nel server DB primario con tre mount NFS su storage ANF.
Se si segue la documentazione NetApp TR-4987 per configurare il server DB standby Oracle"TR-4987: Distribuzione Oracle semplificata e automatizzata su Azure NetApp Files con NFS" , usa un tag -t software_only_install nel passaggio 2 di Playbook execution per eseguire l'installazione automatizzata di Oracle. Di seguito è riportata la sintassi rivista del comando. Il tag consentirà l'installazione e la configurazione dello stack software Oracle, ma non consentirà la creazione di un database.
```
ansible-playbook -i hosts 4-oracle_config.yml -u azureuser -e @vars/vars.yml -t software_only_install
```

Configurazione del server Oracle DB in standby nel sito 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 la home e il percorso di Oracle. Inoltre, dalla directory $ORACLE_HOME del database di standby, copiare la password Oracle dal database primario, se non lo si è ancora fatto.
```
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 .
```

Aggiornare 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 DB Data Guard 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 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 standby duplicato. Il database di standby appena duplicato viene inizialmente aperto in modalità 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 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 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.

Convalida lo stato di ripristino del database di standby. Nota il recovery logmerger In 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 si completa la configurazione della protezione Data Guard per NTAP 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 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>

Crea e abilita 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 all'interno del framework di gestione 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 su quello di standby. Se Fast-Start Failover è abilitato, Data Guard Broker può eseguire il failover del database primario sullo standby quando viene rilevato un errore senza l'intervento dell'utente.

Clona il database di standby per altri casi d'uso

Details

Il vantaggio principale dell'hosting del database Oracle standby sull'ANF nella configurazione Oracle Data Guard è che può essere rapidamente clonato per soddisfare molti altri casi d'uso con un investimento minimo di storage aggiuntivo se è abilitato un clone sottile. NetApp consiglia di utilizzare lo strumento SnapCenter UI per gestire il database Oracle DataGuard. Nella sezione seguente, illustreremo come creare snapshot e clonare i volumi del database di standby montati e in fase di ripristino sull'ANF 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 Oracle Data Guard utilizzando SnapCenter. Per istruzioni dettagliate su come impostare e configurare SnapCenter per Oracle su ANF, fare riferimento a TR-4988"Backup, ripristino e clonazione del database Oracle su ANF con SnapCenter" per i dettagli.

Iniziamo la convalida del caso d'uso creando una tabella di test e inserendo una riga nella tabella di test nel database primario. Verificheremo quindi che la transazione passi allo standby e infine al 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 SnapCenter , è stato aggiunto un utente Unix (azureuser per la demo) e una credenziale Azure (azure_anf per la demo) Credential In Settings .
Utilizzare le credenziali azure_anf per aggiungere l'archiviazione ANF a Storage Systems . Se nel tuo abbonamento Azure sono presenti più account di archiviazione ANF, assicurati di fare clic sull'elenco a discesa per scegliere l'account di archiviazione corretto. Per questa dimostrazione abbiamo creato due account di archiviazione Oracle dedicati.

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

Screenshot che mostra questo passaggio nell'interfaccia grafica.

Il server DB clone deve avere stack software Oracle identici installati e configurati. Nel nostro caso di prova, il software Oracle 19C è installato e configurato, 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. Quando viene inizialmente scoperto, lo stato del database viene visualizzato come Not protected .
È possibile attivare manualmente un backup oppure pianificarlo a un orario stabilito dopo l'applicazione di una policy di backup.
Dopo un backup, 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.
Seleziona il Complete Database Clone e assegnare un nome SID all'istanza clone.
Selezionare il server DB clone che ospita il database clonato dal DB standby. Accetta l'impostazione predefinita per i file di dati e i redo log. Inserire un file di controllo nel punto di montaggio /u03.
Per l'autenticazione basata sul sistema operativo non sono necessarie credenziali del database. Abbinare le impostazioni home di Oracle a quelle configurate sul server DB clone.
Se necessario, modificare i parametri del database clone, ad esempio riducendo le dimensioni PGA o SGA per un database clone. Specificare gli script da eseguire prima del clone, se presenti.
Immettere SQL per eseguire il clone. 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.
Monitorare il lavoro di clonazione in Monitor scheda. Abbiamo osservato che ci sono voluti circa 14 minuti per clonare un database di circa 950 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 dal server del database clone. Abbiamo convalidato che la transazione di prova avvenuta nel database primario era stata trasferita 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

Questo completa la dimostrazione del clone del database standby Oracle in Oracle Data Guard su Azure ANF Storage per DEV, TEST, REPORT o qualsiasi altro caso d'uso. È possibile clonare più database Oracle dallo stesso database standby in Oracle Data Guard su ANF.

Dove trovare ulteriori informazioni

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

Azure NetApp Files

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

"TR-4988: Backup, ripristino e clonazione del database Oracle su ANF con SnapCenter"
TR-4987: Distribuzione Oracle semplificata e automatizzata su Azure NetApp Files con NFS

"TR-4987: Distribuzione Oracle semplificata e automatizzata su Azure NetApp Files con NFS"
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 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