La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

TR-5002 : Réduction des coûts d'Oracle Active Data Guard avec Azure NetApp Files

08/18/2025 Contributeurs

La solution fournit une vue d'ensemble et des détails sur la configuration d'Oracle Data Guard à l'aide de Microsoft Azure NetApp Files (ANF) comme stockage de base de données principal et de secours afin de réduire les coûts de licence et d'exploitation de la solution Oracle Data Guard HA/DR dans le cloud Azure.

But

Oracle Data Guard garantit une haute disponibilité, une protection des données et une reprise après sinistre pour les données d'entreprise dans une configuration de réplication de base de données principale et de base de données de secours. Oracle Active Data Guard permet aux utilisateurs d'accéder aux bases de données de secours pendant que la réplication des données est active de la base de données principale vers les bases de données de secours. Data Guard est une fonctionnalité d'Oracle Database Enterprise Edition. Cela ne nécessite pas de licence distincte. D'autre part, Active Data Guard est une option Oracle Database Enterprise Edition et nécessite donc une licence distincte. Plusieurs bases de données de secours peuvent recevoir la réplication des données à partir d'une base de données principale dans la configuration Active Data Guard. Cependant, chaque base de données de secours supplémentaire nécessite une licence Active Data Guard et un stockage supplémentaire en fonction de la taille de la base de données principale. Les coûts opérationnels s’accumulent rapidement.

Si vous souhaitez réduire les coûts de votre exploitation de base de données Oracle et envisagez de configurer un Active Data Guard dans le cloud Azure, vous devriez envisager une alternative. Au lieu d’Active Data Guard, utilisez Data Guard pour répliquer de la base de données principale vers une seule base de données de secours physique sur le stockage Azure NetApp Files . Par la suite, plusieurs copies de cette base de données de secours peuvent être clonées et ouvertes pour un accès en lecture/écriture afin de servir de nombreux autres cas d'utilisation tels que le reporting, le développement, les tests, etc. Les résultats nets fournissent efficacement les fonctionnalités d'Active Data Guard tout en éliminant la licence Active Data Guard. Dans cette documentation, nous montrons comment configurer un Oracle Data Guard avec votre base de données principale existante et votre base de données de secours physique sur le stockage ANF. La base de données de secours est sauvegardée et clonée pour un accès en lecture/écriture pour les cas d'utilisation souhaités via l'outil de gestion de base de données NetApp SnapCenter . L'équipe d'ingénierie des solutions NetApp fournit également une boîte à outils d'automatisation pour actualiser le clone selon un calendrier défini par l'utilisateur pour une gestion complète et automatisée du cycle de vie du clone de base de données sans intervention de l'utilisateur.

Cette solution répond aux cas d’utilisation suivants :

Implémentation d'Oracle Data Guard entre une base de données principale et une base de données de secours physique sur le stockage Microsoft Azure NetApp Files dans les régions Azure.
Sauvegardez et clonez la base de données de secours physique pour répondre à des cas d'utilisation tels que le reporting, le développement, les tests, etc.
Gestion du cycle de vie de l'actualisation du clone de base de données Oracle via l'automatisation.

Public

Cette solution est destinée aux personnes suivantes :

Un administrateur de base de données qui configure Oracle Active Data Guard dans le cloud Azure pour une haute disponibilité, une protection des données et une reprise après sinistre.
Un architecte de solutions de base de données intéressé par la configuration d'Oracle Active Data Guard dans le cloud Azure.
Un administrateur de stockage qui gère le stockage Azure NetApp Files prenant en charge Oracle Data Guard.
Un propriétaire d’application qui aime mettre en place Oracle Data Guard dans un environnement cloud Azure.

Environnement de test et de validation de solutions

Les tests et la validation de cette solution ont été effectués dans un environnement de laboratoire cloud Azure qui peut ne pas correspondre à l’environnement de déploiement utilisateur réel. Pour plus d'informations, consultez la section Facteurs clés à prendre en compte lors du déploiement .

Architecture

Cette image fournit une image détaillée de l’implémentation d’Oracle Data Guard dans le cloud Azure sur ANF.

Composants matériels et logiciels

Matériel

Azure NetApp Files

Version actuelle proposée par Microsoft

Deux pools de capacité de 3 Tio, niveau de service standard, qualité de service automatique

Machines virtuelles Azure pour serveurs de base de données

Standard B4ms (4 vcpus, 16 Gio de mémoire)

Trois machines virtuelles de base de données, une comme serveur de base de données principal, une comme serveur de base de données de secours et la troisième comme serveur de base de données clone

Logiciel

RedHat Linux

Red Hat Enterprise Linux 8.6 (LVM) - x64 Gen2

Abonnement RedHat déployé pour les tests

Base de données Oracle

Version 19.18

Patch RU appliqué p34765931_190000_Linux-x86-64.zip

Oracle OPatch

Version 12.2.0.1.36

Dernier correctif p6880880_190000_Linux-x86-64.zip

SnapCenter

Version 6.0.1

Version 6.0.1.4487

NFS

Version 3.0

dNFS activé pour Oracle

Configuration d'Oracle Data Guard avec configuration hypothétique de reprise après sinistre de New York à Los Angeles

Base de données

DB_UNIQUE_NAME

Nom du service Oracle Net

Primaire

NTAP_NY

NTAP_NY.internal.cloudapp.net

Attendre

NTAP_LA

NTAP_LA.internal.cloudapp.net

Facteurs clés à prendre en compte lors du déploiement

Clone de base de données de secours. Lors de la réception et de l'application des journaux de transactions de la base de données principale, la base de données de secours physique peut être clonée et montée sur une machine virtuelle DB pour prendre en charge d'autres charges de travail telles que DEV, TEST ou Report. Le clone peut être un clone fin ou épais. À l'heure actuelle, ANF ne prend en charge que le clone épais, qui est une copie complète de la base de données de secours. L'option de clone mince ANF sera bientôt disponible. Pour les copies clonées de manière fine des volumes de base de données, il partage les mêmes volumes de base de données de secours et utilise la technologie de copie sur écriture pour gérer les E/S d'écriture. Ainsi, les clones sont très efficaces en termes de stockage et peuvent être utilisés pour de nombreux autres cas d'utilisation avec une allocation de stockage minimale et incrémentielle pour les nouvelles E/S d'écriture. Cela permet de réaliser d’énormes économies de coûts de stockage en réduisant considérablement l’empreinte de stockage d’Active Data Guard. NetApp recommande de minimiser les activités FlexClone en cas de basculement de la base de données du stockage principal vers le stockage ANF de secours afin de maintenir les performances Oracle à un niveau élevé.
Configuration requise pour le logiciel Oracle. En général, une base de données de secours physique doit avoir la même version de base de données que la base de données principale, y compris les exceptions de jeu de correctifs (PSE), les mises à jour de correctifs critiques (CPU) et les mises à jour de jeu de correctifs (PSU), sauf si un processus d'application de correctif Oracle Data Guard Standby-First est en cours (comme décrit dans la note My Oracle Support 1265700.1 à l'adresse"support.oracle.com" .
Considérations relatives à la structure du répertoire de la base de données de secours. Si possible, les fichiers de données, les fichiers journaux et les fichiers de contrôle sur les systèmes principal et de secours doivent avoir les mêmes noms et chemins d'accès et utiliser les conventions de dénomination OFA (Optimal Flexible Architecture). Les répertoires d'archivage de la base de données de secours doivent également être identiques entre les sites, y compris la taille et la structure. Cette stratégie permet à d’autres opérations telles que les sauvegardes, les basculements et les basculements d’exécuter le même ensemble d’étapes, réduisant ainsi la complexité de la maintenance.
Forcer le mode de journalisation. Pour vous protéger contre les écritures directes non enregistrées dans la base de données principale qui ne peuvent pas être propagées vers la base de données de secours, activez FORCE LOGGING sur la base de données principale avant d'effectuer des sauvegardes de fichiers de données pour la création de secours.
Dimensionnement de la machine virtuelle Azure. Dans ces tests et validations, nous avons utilisé une machine virtuelle Azure - Standard_B4ms avec 4 vCPU et 16 Gio de mémoire. Vous devez dimensionner la machine virtuelle Azure DB de manière appropriée en fonction du nombre de processeurs virtuels et de la quantité de RAM en fonction des exigences réelles de la charge de travail.
* Configuration des Azure NetApp Files .* Les Azure NetApp Files sont alloués dans le compte de stockage Azure NetApp comme Capacity Pools . Dans ces tests et validations, nous avons déployé un pool de capacité de 3 Tio pour héberger la base de données principale Oracle dans la région Est et une base de données de secours dans la région Ouest 2. Le pool de capacité ANF propose trois niveaux de service : Standard, Premium et Ultra. La capacité d'E/S du pool de capacité ANF est basée sur la taille du pool de capacité et son niveau de service. Pour le déploiement en production, NetApp recommande d'effectuer une évaluation complète des besoins en débit de votre base de données Oracle et de dimensionner le pool de capacité de la base de données en conséquence. Lors de la création d'un pool de capacité, vous pouvez définir la qualité de service sur Auto ou Manuel et le chiffrement des données au repos sur Simple ou Double.
Configuration dNFS. En utilisant dNFS, une base de données Oracle exécutée sur une machine virtuelle Azure avec stockage ANF peut générer beaucoup plus d’E/S que le client NFS natif. Le déploiement Oracle automatisé à l’aide de la boîte à outils d’automatisation NetApp configure automatiquement dNFS sur NFSv3.

Déploiement de la solution

Il est supposé que votre base de données Oracle principale est déjà déployée dans un environnement cloud Azure au sein d’un VNet comme point de départ pour la configuration d’Oracle Data Guard. Idéalement, la base de données principale est déployée sur un stockage ANF avec montage NFS. Trois points de montage NFS sont créés pour le stockage de la base de données Oracle : mount /u01 pour les fichiers binaires Oracle, mount /u02 pour les fichiers de données Oracle et un fichier de contrôle, mount /u03 pour les fichiers journaux Oracle actuels et archivés, et un fichier de contrôle redondant.

Votre base de données Oracle principale peut également être exécutée sur un stockage NetApp ONTAP ou tout autre stockage de votre choix au sein de l’écosystème Azure ou d’un centre de données privé. La section suivante fournit des procédures de déploiement étape par étape pour la configuration d’un Oracle Data Guard entre une base de données Oracle principale dans Azure avec stockage ANF et une base de données Oracle de secours physique dans Azure avec stockage ANF.

Prérequis pour le déploiement

Details

Le déploiement nécessite les prérequis suivants.

Un compte cloud Azure a été configuré et les sous-réseaux VNet et réseau nécessaires ont été créés dans votre compte Azure.
À partir de la console du portail cloud Azure, vous devez déployer au moins trois machines virtuelles Azure Linux, une comme serveur de base de données Oracle principal, une comme serveur de base de données Oracle de secours et un serveur de base de données cible cloné pour la création de rapports, le développement, les tests, etc. Consultez le diagramme d'architecture dans la section précédente pour plus de détails sur la configuration de l'environnement. Consultez également le site Microsoft"Machines virtuelles Azure" pour plus d'informations.

La base de données Oracle principale doit avoir été installée et configurée sur le serveur de base de données Oracle principal. En revanche, dans le serveur de base de données Oracle de secours ou le serveur de base de données Oracle clone, seul le logiciel Oracle est installé et aucune base de données Oracle n'est créée. Idéalement, la disposition des répertoires de fichiers Oracle doit correspondre exactement sur tous les serveurs de base de données Oracle. Pour plus de détails sur la recommandation NetApp pour le déploiement automatisé d’Oracle dans le cloud Azure et ANF, veuillez vous référer aux rapports techniques suivants pour obtenir de l’aide.

"TR-4987 : Déploiement Oracle simplifié et automatisé sur Azure NetApp Files avec NFS"

Assurez-vous d’avoir alloué au moins 128 Go dans le volume racine des machines virtuelles Azure afin de disposer de suffisamment d’espace pour préparer les fichiers d’installation d’Oracle.

À partir de la console du portail cloud Azure, déployez deux pools de capacité de stockage ANF pour héberger les volumes de base de données Oracle. Les pools de capacité de stockage ANF doivent être situés dans différentes régions pour imiter une véritable configuration DataGuard. Si vous n'êtes pas familier avec le déploiement du stockage ANF, consultez la documentation"Démarrage rapide : configurer Azure NetApp Files et créer un volume NFS" pour des instructions étape par étape.
Lorsque la base de données Oracle principale et la base de données Oracle de secours sont situées dans deux régions différentes, une passerelle VPN doit être configurée pour autoriser le flux de trafic de données entre deux réseaux virtuels distincts. La configuration détaillée du réseau dans Azure dépasse le cadre de ce document. Les captures d'écran suivantes fournissent des références sur la manière dont les passerelles VPN sont configurées, connectées et dont le flux de trafic de données est confirmé en laboratoire.

Passerelles VPN de laboratoire :

La passerelle vnet principale :

État de la connexion de la passerelle Vnet :

Valider que les flux de trafic sont établis (cliquez sur les trois points pour ouvrir la page) :

Préparer la base de données principale pour Data Guard

Details

Dans cette démonstration, nous avons configuré une base de données Oracle principale appelée NTAP sur le serveur Azure DB principal avec trois points de montage NFS : /u01 pour le binaire Oracle, /u02 pour les fichiers de données Oracle et un fichier de contrôle Oracle, /u03 pour les journaux actifs Oracle, les fichiers journaux archivés et un fichier de contrôle Oracle redondant. Ce qui suit illustre les procédures détaillées de configuration de la base de données principale pour la protection Oracle Data Guard. Toutes les étapes doivent être exécutées en tant que propriétaire de la base de données Oracle ou par défaut oracle utilisateur.

La base de données principale NTAP sur le serveur Azure DB principal orap.internal.cloudapp.net est initialement déployée en tant que base de données autonome avec l’ANF comme stockage de base de données.

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

Connectez-vous au serveur de base de données principal en tant qu'utilisateur Oracle. Connectez-vous à la base de données via sqlplus, activez la journalisation forcée sur le primaire.

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.

Depuis sqlplus, activez le flashback sur la base de données principale. Flashback permet de rétablir facilement la base de données principale en tant que base de données de secours après un basculement.
```
alter database flashback on;
```
```
SQL> alter database flashback on;

Database altered.
```
Configurez l'authentification du transport de rétablissement à l'aide du fichier de mot de passe Oracle - créez un fichier pwd sur le principal à l'aide de l'utilitaire orapwd s'il n'est pas défini et copiez-le dans le répertoire de la base de données de secours $ORACLE_HOME/dbs.

Créez des journaux de rétablissement de secours sur la base de données principale avec la même taille que le fichier journal en ligne actuel. Les groupes de journaux sont un groupe de fichiers journaux en ligne de plus. La base de données principale peut alors rapidement passer au rôle de secours lorsqu'un basculement se produit et commence à recevoir des données de rétablissement. Répétez la commande suivante quatre fois pour créer quatre fichiers journaux de secours.

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

À partir de sqlplus, créez un pfile à partir de spfile pour l'édition.
```
create pfile='/home/oracle/initNTAP.ora' from spfile;
```

Révisez le pfile et ajoutez les paramètres suivants.

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

Depuis sqlplus, recréez le spfile à partir du pfile révisé pour écraser le spfile existant dans le répertoire $ORACLE_HOME/dbs.
```
create spfile='$ORACLE_HOME/dbs/spfileNTAP.ora' from pfile='/home/oracle/initNTAP.ora';
```

Modifiez Oracle tnsnames.ora dans le répertoire $ORACLE_HOME/network/admin pour ajouter db_unique_name pour la résolution de nom.

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

Si vous choisissez de nommer votre serveur Azure DB différemment de la valeur par défaut, ajoutez les noms au fichier hôte local pour la résolution du nom d’hôte.

Ajoutez le nom du service de protection des données NTAP_NY_DGMGRL.internal.cloudapp.net pour la base de données principale au fichier 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)
    )
  )

Arrêtez et redémarrez la base de données via sqlplus et vérifiez que les paramètres de protection des données sont désormais actifs.

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

Ceci termine la configuration de la base de données principale pour Data Guard.

Préparez la base de données de secours et activez Data Guard

Details

Oracle Data Guard nécessite une configuration du noyau du système d'exploitation et des piles logicielles Oracle, y compris des ensembles de correctifs sur le serveur de base de données de secours, pour correspondre au serveur de base de données principal. Pour une gestion et une simplicité aisées, la configuration de stockage de la base de données du serveur de base de données de secours doit idéalement correspondre également à celle du serveur de base de données principal, comme la disposition du répertoire de la base de données et les tailles des points de montage NFS. Vous trouverez ci-dessous les procédures détaillées pour configurer le serveur de base de données Oracle de secours et activer Oracle DataGuard pour la protection HA/DR. Toutes les commandes doivent être exécutées avec l'ID utilisateur propriétaire Oracle par défaut oracle .

Tout d’abord, vérifiez la configuration de la base de données principale sur le serveur de base de données Oracle principal. Dans cette démonstration, nous avons configuré une base de données Oracle principale appelée NTAP dans le serveur de base de données principal avec trois montages NFS sur le stockage ANF.
Si vous suivez la documentation NetApp TR-4987 pour configurer le serveur de base de données de secours Oracle"TR-4987 : Déploiement Oracle simplifié et automatisé sur Azure NetApp Files avec NFS" , utiliser une balise -t software_only_install à l'étape 2 de Playbook execution pour exécuter l'installation automatisée d'Oracle. La syntaxe de commande révisée est répertoriée ci-dessous. La balise permettra d'installer et de configurer la pile logicielle Oracle, mais ne permettra pas de créer une base de données.
```
ansible-playbook -i hosts 4-oracle_config.yml -u azureuser -e @vars/vars.yml -t software_only_install
```

La configuration du serveur de base de données Oracle de secours sur le site de secours dans le laboratoire de démonstration.

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

Une fois le logiciel Oracle installé et configuré, définissez le répertoire d'accueil et le chemin d'accès Oracle. De plus, à partir du répertoire de base de données de secours $ORACLE_HOME, copiez le mot de passe Oracle de la base de données principale si vous ne l'avez pas encore fait.
```
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 .
```

Mettre à jour le fichier tnsnames.ora avec les entrées suivantes.

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

Ajoutez le nom du service de protection des données DB au fichier 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))
  )

Lancez dbca pour instancier la base de données de secours à partir de la base de données principale 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.

Valider la base de données de secours dupliquée. La base de données de secours nouvellement dupliquée est initialement ouverte en mode LECTURE SEULE.

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

Redémarrez la base de données de secours dans mount étape et exécutez la commande suivante pour activer la récupération gérée de la base de données de secours.

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.

Valider l’état de récupération de la base de données de secours. Remarquez le recovery logmerger dans APPLYING_LOG action.
```
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>

Ceci termine la configuration de la protection Data Guard pour NTAP du serveur principal au serveur de secours avec la récupération de secours gérée activée.

Configurer Data Guard Broker

Details

Oracle Data Guard Broker est un framework de gestion distribué qui automatise et centralise la création, la maintenance et la surveillance des configurations Oracle Data Guard. La section suivante montre comment configurer Data Guard Broker pour gérer l'environnement Data Guard.

Démarrez Data Guard Broker sur les bases de données principales et de secours avec la commande suivante via sqlplus.
```
alter system set dg_broker_start=true scope=both;
```

À partir de la base de données principale, connectez-vous à Data Guard Borker en tant que 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>

Créez et activez la configuration de 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)

Valider l'état de la base de données dans le cadre de gestion Data Guard Broker.

DGMGRL> show database db1_ny;

Database - db1_ny

  Role:               PRIMARY
  Intended State:     TRANSPORT-ON
  Instance(s):
    db1

Database Status:
SUCCESS

DGMGRL> show database db1_la;

Database - db1_la

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 2.00 KByte/s
  Real Time Query:    OFF
  Instance(s):
    db1

Database Status:
SUCCESS

DGMGRL>

En cas de panne, Data Guard Broker peut être utilisé pour basculer instantanément la base de données principale vers la base de données de secours. Si Fast-Start Failover est activé, Data Guard Broker peut basculer la base de données principale vers la base de données de secours lorsqu'une panne est détectée sans intervention de l'utilisateur.

Cloner la base de données de secours pour d'autres cas d'utilisation

Details

Le principal avantage de l’hébergement de la base de données de secours Oracle sur l’ANF dans la configuration Oracle Data Guard est qu’elle peut être rapidement clonée pour servir de nombreux autres cas d’utilisation avec un investissement de stockage supplémentaire minimal si un clone fin est activé. NetApp recommande d’utiliser l’outil d’interface utilisateur SnapCenter pour gérer votre base de données Oracle DataGuard. Dans la section suivante, nous démontrons comment capturer et cloner les volumes de base de données de secours montés et en cours de récupération sur l'ANF à d'autres fins, telles que DEV, TEST, REPORT, etc., à l'aide de l'outil NetApp SnapCenter .

Vous trouverez ci-dessous des procédures de haut niveau pour cloner une base de données en LECTURE/ÉCRITURE à partir de la base de données de secours physique gérée dans Oracle Data Guard à l'aide de SnapCenter. Pour obtenir des instructions détaillées sur la façon d'installer et de configurer SnapCenter pour Oracle sur ANF, veuillez vous référer au TR-4988"Sauvegarde, récupération et clonage de bases de données Oracle sur ANF avec SnapCenter" pour plus de détails.

Nous commençons la validation du cas d’utilisation en créant une table de test et en insérant une ligne dans la table de test de la base de données principale. Nous validerons ensuite que la transaction traverse jusqu'au standby et enfin au 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>

Dans la configuration de SnapCenter , un utilisateur Unix (azureuser pour la démonstration) et des informations d'identification Azure (azure_anf pour la démonstration) ont été ajoutés à Credential dans Settings .
Utilisez les informations d'identification azure_anf pour ajouter le stockage ANF à Storage Systems . Si vous disposez de plusieurs comptes de stockage ANF dans votre abonnement Azure, assurez-vous de cliquer sur la liste déroulante pour choisir le bon compte de stockage. Nous avons créé deux comptes de stockage Oracle dédiés pour cette démonstration.

Tous les serveurs de base de données Oracle ont été ajoutés à SnapCenter Hosts .

Capture d'écran montrant cette étape dans l'interface graphique.

Le serveur de base de données clone doit avoir des piles logicielles Oracle identiques installées et configurées. Dans notre cas de test, le logiciel Oracle 19C est installé et configuré, mais aucune base de données n'est créée.

Créez une politique de sauvegarde adaptée à la sauvegarde complète de la base de données hors ligne/montée.
Appliquer une politique de sauvegarde pour protéger la base de données de secours dans Resources languette. Lors de la découverte initiale, l'état de la base de données s'affiche comme suit : Not protected .
Vous avez la possibilité de déclencher une sauvegarde manuellement ou de la planifier à une heure définie après l'application d'une politique de sauvegarde.
Après une sauvegarde, cliquez sur le nom de la base de données pour ouvrir la page de sauvegarde de la base de données. Sélectionnez une sauvegarde à utiliser pour le clonage de la base de données et cliquez sur Clone bouton pour lancer le workflow de clonage.
Sélectionnez le Complete Database Clone et nommez l'instance clone SID.
Sélectionnez le serveur de base de données cloné, qui héberge la base de données clonée à partir de la base de données de secours. Acceptez la valeur par défaut pour les fichiers de données et les journaux de rétablissement. Placez un fichier de contrôle sur le point de montage /u03.
Aucune information d'identification de base de données n'est nécessaire pour l'authentification basée sur le système d'exploitation. Faites correspondre les paramètres d'accueil d'Oracle avec ce qui est configuré sur le serveur de base de données cloné.
Modifiez les paramètres de la base de données clonée si nécessaire, par exemple en réduisant la taille PGA ou SGA pour une base de données clonée. Spécifiez les scripts à exécuter avant le clonage, le cas échéant.
Entrez SQL à exécuter après le clone. Dans la démo, nous avons exécuté des commandes pour désactiver le mode d'archivage de base de données pour une base de données dev/test/report.
Configurez la notification par e-mail si vous le souhaitez.
Consultez le résumé, cliquez Finish pour démarrer le clone.
Surveiller le travail de clonage dans Monitor languette. Nous avons observé qu'il fallait environ 14 minutes pour cloner une base de données d'environ 950 Go de volume de base de données.
Validez la base de données clonée à partir de SnapCenter, qui est immédiatement enregistrée dans Resources onglet juste après l'opération de clonage.

Interrogez la base de données clonée à partir du serveur de base de données clonée. Nous avons validé que la transaction de test qui s'est produite dans la base de données principale avait été transmise à la base de données 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

Ceci termine la démonstration du clone de base de données de secours Oracle dans le stockage Oracle Data Guard sur Azure ANF pour DEV, TEST, REPORT ou tout autre cas d'utilisation. Plusieurs bases de données Oracle peuvent être clonées à partir de la même base de données de secours dans Oracle Data Guard sur ANF.

Où trouver des informations supplémentaires

Pour en savoir plus sur les informations décrites dans ce document, consultez les documents et/ou sites Web suivants :

Azure NetApp Files

"https://azure.microsoft.com/en-us/products/netapp"
TR-4988 : Sauvegarde, récupération et clonage de bases de données Oracle sur ANF avec SnapCenter

"TR-4988 : Sauvegarde, récupération et clonage de bases de données Oracle sur ANF avec SnapCenter"
TR-4987 : Déploiement Oracle simplifié et automatisé sur Azure NetApp Files avec NFS

"TR-4987 : Déploiement Oracle simplifié et automatisé sur Azure NetApp Files avec NFS"
Concepts et administration d'Oracle Data Guard

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

TR-5002 : Réduction des coûts d'Oracle Active Data Guard avec Azure NetApp Files

Creating your file...

But

Public

Environnement de test et de validation de solutions

Architecture

Composants matériels et logiciels

Configuration d'Oracle Data Guard avec configuration hypothétique de reprise après sinistre de New York à Los Angeles

Facteurs clés à prendre en compte lors du déploiement

Déploiement de la solution

Prérequis pour le déploiement

Préparer la base de données principale pour Data Guard

Préparez la base de données de secours et activez Data Guard

Configurer Data Guard Broker

Cloner la base de données de secours pour d'autres cas d'utilisation

Où trouver des informations supplémentaires