Oracle AI Database 23.26.2 vous permet de déployer une base de données enfichable (PDB) de secours et ses journaux de reprise (redo logs) via une seule commande Data Guard Broker, éliminant ainsi la routine de copie manuelle des fichiers qui ralentissait depuis longtemps la mise en place de la reprise après sinistre.

Pourquoi c'est important

La création d'une PDB de secours physique nécessitait une série d'actions manuelles : copier chaque fichier de données (datafile) vers le conteneur de secours, créer les journaux de reprise de secours (SRL) à l'aide de commandes ALTER explicites et vérifier l'ensemble de la configuration. Chaque étape comporte un risque de faute de frappe, d'oubli de fichier ou de groupe de journaux non correspondant, ce qui peut retarder les tests de récupération ou, dans le pire des cas, compromettre le basculement (failover). L'automatisation du processus réduit ces risques et permet aux DBA de se concentrer sur des tâches de plus haut niveau.

Comment les PDB de secours étaient construites auparavant

Dans l'architecture multitenant, une CDB (container database) primaire héberge une ou plusieurs PDB. Pour protéger une PDB, les administrateurs devaient :

  • Identifier et copier chaque fichier de données de l'hôte primaire vers l'hôte de secours.
  • Créer manuellement des SRL qui reflètent la structure des journaux de reprise de la primaire.
  • Exécuter des restaurations RMAN ou des commandes de duplication pour synchroniser le secours.
  • Effectuer une série d'étapes de vérification pour s'assurer que le secours pouvait accepter un switchover.

Le flux de travail pouvait durer plusieurs heures, en particulier pour les PDB volumineuses, et la moindre erreur pouvait rendre le secours inutilisable.

Ce que l'update 23.26.2 apporte

La dernière version d'Oracle AI Database intègre les étapes nécessaires dans le Data Guard Broker. En émettant une seule instruction ADD PLUGGABLE DATABASE, le broker :

  1. Enregistre la nouvelle PDB de secours auprès de la primaire.
  2. Copie les fichiers de données nécessaires en arrière-plan — aucune restauration RMAN ni copie manuelle de fichiers n'est nécessaire.
  3. Génère les journaux de reprise de secours appropriés, en les ajoutant automatiquement à la CDB de secours.
  4. Laisse la PDB en mode READ ONLY, prête pour un switchover de secours physique.

La commande utilisée lors du test était :

DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
       SOURCE IS 'amol' AT cdb1
       PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";

Un test en conditions réelles

L'auteur a créé une PDB de secours nommée AMOL sur une CDB secondaire (cdb2) qui reflétait une PDB primaire sur cdb1. Le broker a terminé l'opération instantanément. Aucune restauration RMAN n'a été exécutée, aucune copie manuelle de fichiers n'est apparue dans les journaux du système d'exploitation, et les groupes de journaux de reprise de secours sont apparus dans le catalogue sans aucune instruction ALTER DATABASE.

L'ouverture de la PDB l'a basculée en mode READ ONLY, confirmant son statut de secours physique. Une vérification rapide des fichiers de données a prouvé qu'ils avaient été provisionnés du côté secours. L'application des redo était déjà en cours, et le broker a indiqué que la configuration était prête pour un switchover.

Implications pour les DBA

L'automatisation réduit les risques d'erreur humaine et réduit considérablement le temps entre la planification et la mise en production du secours. Les équipes peuvent désormais provisionner des PDB de secours en quelques minutes plutôt qu'en quelques heures, ce qui est particulièrement précieux pour les environnements qui déploient fréquemment de nouveaux services.

Le revers de la médaille est une dépendance accrue à la logique interne du Data Guard Broker. Certains DBA préfèrent scripter chaque étape eux-mêmes pour conserver un contrôle granulaire ou pour s'intégrer à des outils de surveillance personnalisés. Dans des configurations complexes — réseaux multiples, stockage hétérogène ou structures de redo non standard — les administrateurs devront peut-être encore vérifier que les paramètres par défaut du broker sont conformes à leurs politiques.

À surveiller pour la suite

Oracle n'a pas annoncé d'autres extensions de cette automatisation, mais cette initiative suggère que les futures versions pourraient intégrer davantage de flux de travail de DR multitenant dans le broker. Surveillez :

  • Le support de types de secours supplémentaires (par exemple, les PDB de secours logiques).
  • Une journalisation étendue qui expose les décisions du broker à des fins d'audit.
  • Des vérifications de compatibilité avec des outils de sauvegarde tiers qui reposaient auparavant sur des étapes RMAN manuelles.

Si votre organisation utilise Oracle AI Database dans une configuration de haute disponibilité, tester la nouvelle commande sur une CDB hors production est le moyen le plus rapide d'évaluer l'impact.

À retenir : Oracle AI Database 23.26.2 transforme une configuration de PDB de secours complexe et sujette aux erreurs en une opération d'une seule ligne, offrant une reprise après sinistre plus rapide et plus fiable pour les environnements multitenant.