Automatisation de la récupération après sinistre pour MySQL HeatWave avec des canaux de réplication à l'aide d'OCI Full Stack Disaster Recovery

Introduction

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestre la transition du calcul, de la base de données et des applications entre les régions OCI du monde entier en un seul clic. Les clients peuvent automatiser les étapes nécessaires à la récupération d'un ou de plusieurs systèmes métier sans repenser ou modifier l'architecture de l'infrastructure, des bases de données ou des applications existantes et sans avoir besoin de serveurs de gestion ou de conversion spécialisés.

MySQL HeatWave est un service de base de données entièrement géré déployé dans Oracle Cloud Infrastructure (OCI) qui prend en charge les opérateurs et les développeurs qui cherchent à déployer rapidement des applications sécurisées et natives du cloud. MySQL HeatWave est la seule offre MySQL qui inclut la possibilité d'utiliser HeatWave, un accélérateur de requêtes en mémoire intégré hautes performances. HeatWave permet aux clients d'exécuter des analyses sophistiquées directement sur leur base de données MySQL opérationnelle, éliminant ainsi la nécessité d'une migration et d'une intégration des données complexes, chronophages et coûteuses avec une base de données d'analyse distincte. HeatWave accélère considérablement les performances de MySQL pour les analyses et les workloads mixtes. HeatWave est entièrement optimisé pour OCI et MySQL HeatWave est 100 % conçu, géré et pris en charge par les équipes d'ingénierie OCI et MySQL.

Dans ce tutoriel, vous apprendrez à automatiser les plans de récupération après sinistre pour MySQL HeatWave dans OCI avec la réplication de canal. Il décrit les procédures d'utilisation d'OCI Full Stack DR qui prend désormais en charge nativement MySQL HeatWave pour gérer les opérations de permutation et de basculement.

Description de l'architecture

L'architecture présentée dans ce tutoriel présente MySQL HeatWave dans lequel la réplication entrante est utilisée pour activer la réplication de données asynchrone entre le système de base de données principal et une réplique distante, ce qui garantit une synchronisation efficace des données entre les régions.

full-stack-disaster-recovery-heatwave.png

Description de l'illustration full-stack-disaster-recovery-heatwave.png,

Remarque : le mode Lecture seule doit être activé pour la réplique MySQL HeatWave dans la région de récupération après sinistre afin de garantir l'intégrité des données et d'empêcher toute modification involontaire.

Prérequis (préparation utilisateur)

Avant de lancer la configuration de réplication, assurez-vous que les prérequis suivants sont respectés. Il s'agit notamment des exigences propres à la réplication et des prérequis d'infrastructure et de configuration supplémentaires nécessaires à la prise en charge d'une architecture Full Stack Disaster Recovery robuste pour MySQL HeatWave sur Oracle Cloud Infrastructure (OCI).

Configuration du système MySQL HeatWave - Récapitulatif de haut niveau

Vous trouverez ci-dessous un récapitulatif général des étapes requises pour configurer la réplication inter-région pour MySQL HeatWave sur Oracle Cloud Infrastructure (OCI), afin de garantir une synchronisation des données sécurisée, fiable et évolutive entre les régions.

En suivant ces étapes, vous pouvez implémenter une configuration de réplication inter-région robuste pour MySQL sur OCI, améliorant ainsi la résilience et la disponibilité de votre application dans les régions géographiques.

Remarque : le tutoriel suivant : Configuration de la copie de récupération après sinistre inter-région MySQL HeatWave dans OCI fournit un guide complet pour le déploiement de la récupération après sinistre pour le système de base de données MySQL, garantissant la résilience et la continuité en cas de défaillance du système.

Définitions et hypothèses tout au long du tutoriel

Objectifs

Les tâches suivantes seront abordées dans ce tutoriel :

  1. Tâche 1 : créer des groupes de protection de récupération après sinistre dans les deux régions
  2. Tâche 2 : ajout de MySQL HeatWave aux groupes de protection de récupération après sinistre dans les deux régions
  3. Tâche 3 : Créer des plans de récupération après sinistre dans la région 2
  4. Tâche 4 : exécuter les prévérifications des plans de récupération après sinistre dans la région 2
  5. Tâche 5 : exécuter le plan de permutation dans la région 2
  6. Tâche 6 : Créer des plans de récupération après sinistre dans la région 1

Tâche 1 : créer des groupes de protection de récupération après sinistre dans les deux régions

Créez des groupes de protection de récupération après sinistre dans les régions 1 et 2 si les groupes de protection de cette pile d'applications n'existent pas encore.

Tâche 1.1 : créer un groupe de protection dans la région 1

  1. Accédez à la console OCI et accédez à Groupes de protection de récupération après sinistre comme illustré dans la figure 1.1.

    1. Assurez-vous que le contexte de région OCI est défini sur Region 1 (Ashburn).
    2. Cliquez sur Migration et récupération après sinistre.
    3. Cliquez sur Groupes de protection de récupération après sinistre.

    drpg-create-iad-nav.png
    Figure 1.1 : Accédez aux groupes de protection de récupération après sinistre.

  2. Cliquez sur Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue.

    drpg-create-iad-create.png
    Figure 1.2 : cliquez sur Créer une protection de récupération après sinistre.

  3. Créez un groupe de protection de récupération après sinistre (DRPG) de base dans la région 1, comme illustré à la figure 1.3. Le pair, le rôle et les membres seront affectés dans des étapes ultérieures.

    1. Utilisez un nom explicite pour le DRPG.
    2. Sélectionnez le compartiment dans lequel créer le DRPG.
    3. Sélectionnez le bucket OCI Object Storage pour les journaux OCI Full Stack DR.
    4. Cliquez sur Créer.

    drpg-create-iad-finish.png
    Figure 1.3 : Paramètres nécessaires pour créer un groupe de protection de récupération après sinistre dans la région 1

Tâche 1.2 : créer un groupe de protection dans la région 2

  1. Accédez à la console OCI, puis à Groupes de protection de récupération après sinistre, comme illustré à la figure 1.4.

    1. Assurez-vous que le contexte de région OCI est défini sur Région 2 (Phoenix).
    2. Cliquez sur Migration et récupération après sinistre.
    3. Cliquez sur Groupes de protection de récupération après sinistre.

    drpg-create-phx-nav.png
    Figure 1.4 : Accédez aux groupes de protection de récupération après sinistre.

  2. Cliquez sur Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue.

    drpg-create-phx-create.png
    Figure 1.5 : cliquez sur Créer une protection de récupération après sinistre.

  3. Créez un groupe de protection de récupération après sinistre (DRPG) de base dans la région 2, comme illustré à la figure 1.6. Le pair, le rôle et les membres seront affectés dans des étapes ultérieures.

    1. Utilisez un nom explicite pour le DRPG.
    2. Sélectionnez le compartiment dans lequel créer le DRPG.
    3. Sélectionnez le bucket OCI Object Storage pour les journaux OCI Full Stack DR.
    4. Cliquez sur Créer.

    drpg-create-phx-finish.png
    Figure 1.6 : Paramètres nécessaires pour créer un groupe de protection de récupération après sinistre dans la région 2

Tâche 1.3 : Associer des groupes de protection dans la région 1 et la région 2

Associez les DRPG de chaque région en tant que pairs et affectez les rôles homologues de la base de données principale et de la base de données de secours. Les rôles de la base de données principale et de la base de données de secours sont automatiquement modifiés par OCI Full Stack DR dans le cadre de toute exécution d'opération de récupération après sinistre/de plan de récupération après sinistre. Il n'est pas nécessaire de gérer les rôles manuellement à tout moment.

  1. Accédez à la page des détails du groupe de protection de récupération après sinistre.

    1. Assurez-vous que le contexte de région OCI est défini sur Région 1 (Ashburn).
    2. Cliquez sur Action.
    3. Cliquez sur Associer pour lancer le processus.

    drpg-assoc-iad-begin.png
    Figure 1.7 : Commencer l'association DRPG

  2. Entrez les paramètres comme indiqué dans l'image suivante.

    1. Rôle : sélectionnez le rôle Principal. OCI Full Stack DR affectera automatiquement le rôle de secours à la région 2.
    2. Région homologue : sélectionnez la région 2 (Phoenix), où l'autre DRPG a été créé.
    3. Groupe de protection de récupération après sinistre homologue : sélectionnez le DRPG homologue qui a été créé.
    4. Cliquez sur Associer.

    drpg-assoc-iad-params.png
    Figure 1.8 : Paramètres nécessaires pour associer les DRPG

  3. Autorisez la fin de la demande de travail avant de continuer.

    drpg-assoc-iad-finish.png
    Figure 1.9 : Association DRPG terminée.

Une fois l'association terminée, la récupération après sinistre complète de la pile OCI affiche un résultat similaire à celui illustré dans l'image suivante.

  1. Le DRPG homologue principal actuel est Ashburn (région 1).
  2. Le pair de secours actuel DRPG est Phoenix (région 2).

drpg-assoc-iad-completed.png
Figure 1.10 : Affichage de la relation homologue du point de vue du DRPG individuel

Les mêmes informations peuvent être trouvées chaque fois que le contexte/la vue est d'un point de vue global montrant tous les groupes de protection de récupération après sinistre comme indiqué dans l'image suivante.

  1. Le DRPG homologue principal actuel est Ashburn (région 1).
  2. Le pair de secours actuel DRPG est Phoenix (région 2).

drpg-assoc-phx-completed.png
Figure 1.11 : Affichage de la relation homologue du point de vue global DRPG

Tâche 2 : ajout de MySQL HeatWave au groupe de protection de récupération après sinistre

Tâche 2.1 : ajouter MySQL HeatWave à DRPG dans la région 1

  1. Sélectionnez le DRPG dans la région 1 comme indiqué dans l'image suivante.

    1. Assurez-vous que le contexte de région OCI est la région 1 (Ashburn).
    2. Sélectionnez le DRPG dans la région 1.
    3. Sélectionnez Membres.
    4. Cliquez sur Gérer les membres pour lancer le processus.

    drpg-add-iad-nav.png
    Figure 2.1 : Comment commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 1

  2. Cliquez sur Ajouter un membre,

    drpg-add-iad-begin.png
    Figure 2.2 : Commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 1

  3. Ajoutez le fichier MySQL HeataWave au DRPG de la région 1.

    1. Entrez le système MySQL Database en tant que type de ressource membre.
    2. Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave principal dans la région 1 dans le champ Système de base de données.
    3. Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave de réplique dans la région 2 dans le champ Système de base de données homologue.
    4. Saisissez le nom utilisateur Admin.
    5. Sélectionnez le compartiment approprié, puis choisissez la clé secrète du mot de passe d'administration.
    6. Saisissez le nom d'utilisateur de réplication.
    7. Sélectionnez le compartiment approprié, puis choisissez la clé secrète de mot de passe de réplication.
    8. Cliquez sur Ajouter.

    Paramètres facultatifs:

    • Délai d'expiration du rapprochement : indique le temps, en secondes, d'attente de la synchronisation GTID (Global Transaction Identifier) au cours du processus de rapprochement. Ce paramètre de délai d'attente garantit que le système laisse suffisamment de temps pour la synchronisation GTID avant de considérer que l'opération a échoué ou s'est terminée.
    • Continuer lors du délai d'expiration du rapprochement : en activant cette option, le système contourne le processus de validation GTID une fois le délai d'expiration dépassé. Cela permet de procéder au basculement ou à la permutation, même si la synchronisation GTID est incomplète.

    drpg-add-mysql-iad-params.png
    Figure 2.3 : Paramètres nécessaires pour ajouter MySQL HeatWave

  4. Publier les modifications dans la région DRPG 1

    Cliquez sur Publier des modifications. drpg-add-mysql-iad-publish.png
    Figure 2.4 : Publier les modifications

    Confirmez, en cliquant sur Publier les modifications drpg-add-mysql-iad-publish-confirm.png
    Figure 2.4 : Publier les modifications

    drpg-add-mysql-iad-completed.png
    Figure 2.5 : MySQL HeatWave ajouté au DRPG dans la région 1.

Tâche 2.2 : ajouter MySQL HeatWave à DRPG dans la région 2

  1. Sélectionnez le DRPG dans la région 2 comme indiqué dans l'image suivante.

    1. Assurez-vous que le contexte de région OCI est la région 2 (Phoenix).
    2. Sélectionnez le DRPG dans la région 2.
    3. Sélectionnez Membres.
    4. Cliquez sur Gérer les membres pour lancer le processus.

    drpg-add-phx-nav.png
    Figure 2.6 : Comment commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 2

  2. Cliquez sur Ajouter un membre,

    drpg-add-phx-begin.png
    Figure 2.7 : commencez à ajouter des membres au groupe de protection de récupération après sinistre dans la région 2.

  3. Ajoutez le fichier MySQL HeataWave au DRPG dans la région 2.

    1. Entrez le système MySQL Database en tant que type de ressource membre.
    2. Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave de réplique dans la région 2 dans le champ Système de base de données.
    3. Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave principal dans la région 1 dans le champ Système de base de données homologue.
    4. Saisissez le nom utilisateur Admin.
    5. Sélectionnez le compartiment approprié, puis choisissez la clé secrète du mot de passe d'administration.
    6. Saisissez le nom d'utilisateur de réplication.
    7. Sélectionnez le compartiment approprié, puis choisissez la clé secrète de mot de passe de réplication.
    8. Cliquez sur Ajouter.

    Paramètres facultatifs:

    • Délai d'expiration du rapprochement : indique le temps, en secondes, d'attente de la synchronisation GTID (Global Transaction Identifier) au cours du processus de rapprochement. Ce paramètre de délai d'attente garantit que le système laisse suffisamment de temps pour la synchronisation GTID avant de considérer que l'opération a échoué ou s'est terminée.
    • Continuer lors du délai d'expiration du rapprochement : en activant cette option, le système contourne le processus de validation GTID une fois le délai d'expiration dépassé. Cela permet de procéder au basculement ou à la permutation, même si la synchronisation GTID est incomplète.

    drpg-add-mysql-phx-params.png
    Figure 2.8 : Paramètres nécessaires pour ajouter MySQL HeatWave

  4. Publiez les modifications dans la région DRPG 2.

    Cliquez sur Publier des modifications. drpg-add-mysql-phx-publish.png
    Figure 2.9 : Publier les modifications

    Confirmez en cliquant sur Publier les modifications. drpg-add-mysql-phx-publish-confirm.png
    Figure 2.10 : Publier les modifications

    drpg-add-mysql-phx-completed.png
    Figure 2.11 : MySQL HeatWave ajouté au DRPG dans la région 2

Tâche 3 : Créer des plans de récupération après sinistre dans la région 2

Dans cette tâche, nous allons créer les plans de permutation et de basculement initiaux associés au groupe de protection de récupération après sinistre de secours dans la région 2 (Phoenix).

L'objectif de ces plans est de faire passer la charge globale de la région principale (région 1) à la région de secours (région 2). Dans le cadre d'une opération de récupération après sinistre, les rôles des groupes de protection de récupération après sinistre dans les deux régions sont automatiquement inversés : le groupe de protection de la région 1 devient le groupe de secours, tandis que le groupe de protection de la région 2 assume le rôle principal après un basculement ou une permutation.

OCI Full Stack DR pré-remplira ces plans avec des étapes intégrées dérivées des ressources membres ajoutées lors des tâches précédentes. Les plans de récupération après sinistre sont automatiquement préremplis avec les tâches de récupération de MySQL HeatWave appropriées, car MySQL HeatWave est intégré à Full Stack Disaster Recovery.

Les plans de récupération après sinistre sont toujours créés au sein du groupe de protection qui détient le rôle de secours. Etant donné que la région 2 (Phoenix) est actuellement le groupe de protection de secours, nous commencerons à y créer les plans.

Tâche 3.1 : Créer des plans de récupération après sinistre

  1. Créez un plan de base en sélectionnant le DRPG dans la région 2 (Phoenix)

    1. Assurez-vous que le contexte de région OCI est la région 2 (Phoenix).
    2. Sélectionnez le DRPG de secours dans la région 2.
    3. Sélectionnez Plans.
    4. Cliquez sur Créer un plan pour lancer le processus.

    plan-create-phx-nav.png
    Figure 3.1 : Comment commencer à créer des plans de récupération après sinistre de base dans la région 2

  2. Créez un plan de permutation.

    1. Entrez un nom simple mais significatif pour le plan Permutation. Le nom doit être aussi court que possible mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
    2. Sélectionnez Type de plan comme Basculement (planifié).

    plan-create-phx-so.png
    Figure 3.2 : Paramètres nécessaires à la création d'un plan de permutation de récupération après sinistre

    plan-create-phx-so-created.png
    Figure 3.3 : Plan de permutation de récupération après sinistre

    Cliquez sur le nom du plan de récupération après sinistre pour afficher les détails du plan et les groupes de plans. plan-create-phx-so-details.png
    Figure 3.4 : Groupe de plans MySQL HeatWave de permutation de récupération après sinistre

  3. Créez un plan de basculement.

    1. Entrez un nom simple mais significatif pour le plan de basculement. Le nom doit être aussi court que possible mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
    2. Sélectionnez Type de plan comme Basculement (non planifié).

    plan-create-phx-fo.png
    Figure 3.5 : Paramètres nécessaires pour créer un plan de basculement de récupération après sinistre

    plan-create-phx-fo-created.png
    Figure 3.6 : Plan de basculement de récupération après sinistre

    Cliquez sur le nom du plan de récupération après sinistre pour afficher les détails du plan et les groupes de plans. plan-create-phx-fo-details.png
    Figure 3.7 : Groupe de plans MySQL HeatWave de basculement de récupération après sinistre

Le groupe de protection de récupération après sinistre de secours de la région 2 doit désormais disposer des deux plans de récupération après sinistre. Ils gèrent la transition des charges de travail de la région 1 vers la région 2.

Remarque : après l'exécution initiale du plan Permutation, nous allons créer ultérieurement des plans correspondants dans la région 1 pour réémettre les charges globales de la région 2.

  1. (Facultatif) Créer des plans d'analyse de récupération après sinistre - Lancer l'analyse et arrêter l'analyse.

Tout comme les plans de permutation de rôles et de basculement, vous pouvez créer un plan de récupération après sinistre Start Drill. Au cours de l'exploration, un système de base de données est créé à l'aide des dernières sauvegardes disponibles, simulant un scénario de récupération après sinistre dans lequel vous devez récupérer des opérations dans la région de récupération après sinistre.

  1. Entrez un nom simple mais significatif pour le plan Démarrer l'exploration. Le nom doit être aussi court que possible mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.

  2. Sélectionnez Type de plan comme Démarrer l'exploration.

    plan-create-phx-startdrill.png
    Figure 3.8 : Paramètres nécessaires pour créer un plan d'exploration de début

L'arrêt de l'exploration doit être créé/exécuté une fois l'arrêt de l'exploration terminé. Ce plan est chargé de mettre fin aux systèmes de base de données créés lors de l'exécution de l'analyse de démarrage et de nettoyer les ressources temporaires utilisées à des fins de test.

Tâche 4 : exécuter les prévérifications dans la région 2

Les plans de reprise après sinistre et de basculement ont été créés dans la région de secours 2. Ces plans permettent à OCI Full Stack DR de faire passer les charges de travail de la région 1 à la région 2. La tâche suivante consiste à exécuter les prévérifications pour les plans de permutation et de basculement afin de garantir la préparation et de valider le processus de transition.

Tâche 4.1 : lancer les prévérifications pour le plan de permutation

Exécutez des prévérifications pour le plan de récupération après sinistre de permutation.

  1. Assurez-vous que le contexte de région est défini sur la région de secours 2.
  2. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné, il doit s'agir du rôle de secours.
  3. Cliquez sur le nom du plan de permutation.
  4. Cliquez sur Action.
  5. Cliquez sur Exécuter les prévérifications.

prévérifications-so-phx-begin.png
Figure 4.1 : Affichage de l'exécution des prévérifications du plan de permutation

prévérifications-so-phx-run.png
Figure 4.2 : Affichage de l'exécution des prévérifications du plan de permutation

Groupes d'exécution de plan des prévérifications de permutation. prévérifications-so-phx-completed.png
Figure 4.3 : Affichage des prévérifications terminées du plan de permutation

Tâche 4.2 : lancer les prévérifications du plan de basculement

Exécutez les prévérifications pour le plan de récupération après sinistre de basculement.

  1. Assurez-vous que le contexte de région est défini sur la région de secours 2.
  2. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné, il doit s'agir du rôle de secours.
  3. Cliquez sur le nom du plan de basculement.
  4. Cliquez sur Action.
  5. Cliquez sur Exécuter les prévérifications.

prévérifications-fo-phx-begin.png
Figure 4.4 : Affichage de l'exécution des prévérifications du plan de basculement

prévérifications-fo-phx-run.png
Figure 4.5 : Affichage de l'exécution des prévérifications du plan de basculement

Groupes d'exécution de plan des prévérifications de permutation. prévérifications-fo-phx-completed.png
Figure 4.6 : Affichage des prévérifications terminées du plan de basculement

Tâche 5 : exécuter le plan de permutation de rôles dans la région 2

Exécutez le plan de reprise après sinistre pour commencer le processus de transition de l'application WordPress avec MySQL HeatWave de la région 1 vers la région 2.

  1. Assurez-vous que le contexte de région est défini sur la région de secours 2.
  2. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné, il doit s'agir du rôle de secours.
  3. Cliquez sur le nom du plan de permutation.
  4. Cliquez sur Action.
  5. Cliquez sur Exécuter le plan.

exec-so-phx-begin.png
Figure 5.1 : Procédure d'exécution du plan de permutation de rôles

Cette tâche exécute le plan de permutation dans la région 2.

  1. Désélectionnez Activer les prévérifications, car elles ont déjà été exécutées dans la tâche 4.
  2. Cliquez sur Exécuter le plan de récupération après sinistre.

exec-so-phx-run.png
Figure 5.2 : Procédure d'exécution du plan de permutation de rôles

Cliquez sur Exécuter le plan de récupération après sinistre pour commencer la exec-so-phx-run-confirm.png
Figure 5.3 : indique comment confirmer l'exécution du plan de permutation.

Surveillez le plan de permutation jusqu'à ce que la charge globale complète passe de la région 1 à la région 2.

exec-so-phx-dans-progress.png
Figure 5.4 : Affichage de l'exécution du groupe de plans de permutation en cours.

L'exécution du plan de permutation est terminée.

exec-so-phx-completed.png
Figure 5.5 : Affichage de l'exécution d'un plan de permutation terminé.

Tâche 6 : créer des plans de récupération après sinistre dans la région 1

Avec la réussite de la permutation par OCI Full Stack DR, la région 2 a désormais pris le rôle de région principale, tandis que la région 1 a évolué pour servir de région de secours.

Suivez la même approche détaillée dans la tâche 3, créez les plans de permutation et de basculement au sein du groupe de protection de récupération après sinistre pour la région 1, qui sert désormais de région homologue de secours.

plan-créer-iad.png
Figure 6.1 : Capture d'écran illustrant les plans créés dans la région 1

plan-so-iad-details.png
Figure 6.2 : Capture d'écran illustrant le plan de permutation dans la région 1

plan-foad-details.png
Figure 6.3 : Capture d'écran illustrant le plan de basculement en cas d'incident dans la région 1

Etapes suivantes

Pour plus d'informations, reportez-vous à la documentation sur OCI Full Stack DR et MySQL HeatWave dans la section Liens associés.

Accusés de réception

Ressources de formation supplémentaires

Explorez d'autres ateliers sur le site docs.oracle.com/learn ou accédez à d'autres contenus d'apprentissage gratuits sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, consultez Oracle Help Center.