Configuration d'Autonomous Database avec l'architecture de référence
Oracle Autonomous Database on Dedicated Exadata Infrastructure est un environnement de base de données entièrement géré et hautement automatisé exécuté dans Oracle Cloud Infrastructure (OCI) avec des ressources matérielles et logicielles validées. Ces ressources isolées permettent aux entreprises de répondre à des exigences strictes en matière de sécurité, de disponibilité et de performances tout en réduisant les coûts et la complexité.
Conseil :
Si vous recherchez des conseils pour configurer rapidement un environnement de point de contact Autonomous Database, reportez-vous à Configuration d'Autonomous Database pour la vérification de concept.Connaissances préalables
Pour bien comprendre et apprécier ce cas d'emploi, vous devez avoir une compréhension de base d'Autonomous Database on Dedicated Exadata Infrastructure, y compris ses options de déploiement, ses composants d'infrastructure clés, ses rôles utilisateur et ses principales fonctionnalités. Pour plus d'informations, reportez-vous à A propos d'Autonomous Database on Dedicated Exadata Infrastructure.
Rubriques connexes
Cas d'emploi
La société Acme a choisi d'utiliser Autonomous Database on Dedicated Exadata Infrastructure pour ses applications de projet internes. Le service informatique d'Acme endosse le rôle d'administrateur de parc, responsable de la création et de la gestion des ressources d'infrastructure Exadata et de cluster de machines virtuelles Exadata Autonomous pour l'entreprise. Au sein de chaque équipe de projet ou secteur d'activité, les utilisateurs désignés prennent le rôle d'administrateur de base de données d'application, chargé de créer des bases de données Conteneur Autonomous (ACD) et des instances Autonomous Database pour leurs utilisateurs de base de données, y compris les développeurs d'application, les testeurs et les déployeurs.
Remarques :
Cet exemple illustre la création et la gestion par le DBA de l'application des ressources ACD. Cependant, votre organisation peut préférer que l'administrateur du parc entreprenne cette tâche lui-même.Acme I.T. allouera des ressources aux différentes équipes, garantissant ainsi la mise à disposition de CMA répondant aux SLA requis. En outre, pour contrôler l'allocation équitable des ressources, le service informatique d'Acme souhaite qu'aucune équipe de projet ou aucun secteur d'activité ne dispose d'un accès de gestion à l'infrastructure dédiée sous-jacente. En outre, conformément aux audits réglementaires, la direction d'Acme ne veut pas qu'Acme I.T. puisse accéder aux données appartenant à différentes équipes de projet ou secteurs d'activité, c'est-à-dire aux données qu'ils stockent dans leurs bases de données d'applications.
AcmeHR, une application RH interne développée et utilisée par Acme, fonctionne dans deux environnements distincts : l'un pour le développement et les tests (Dev) et l'autre pour la production (Prod). Acme I.T. s'engage à maintenir une isolation stricte entre ces environnements afin d'empêcher tout accès non autorisé ou toute interaction entre les équipes de développement et de production.
Ressources nécessaires
Composants d'OCI IAM
- Trois compartiments pour assurer l'isolement des ressources, comme décrit ci-dessous :
- FleetComp pour les ressources créées par l'IT Acme, la mise en réseau et les sous-réseaux privés utilisés par les bases de données de développement et de production.
- DevComp pour la base de données de développement.
- ProdComp pour la base de données de production.
- Trois groupes auxquels les utilisateurs peuvent être affectés, un pour chacun des utilisateurs Acme I.T., Dev et Prod. Ces groupes sont nommés FAGroup, DevGroup et ProdGroup.
- Stratégies requises pour indiquer l'accès utilisateur aux ressources aux niveaux du compartiment et de la location.
Ressources réseau
représente une liste de sécurité.
-
Déploiements Oracle Public Cloud :
- Un seul réseau cloud virtuel pour assurer la connectivité réseau à toutes les ressources d'infrastructure dédiées. Ce VCN se connectera au VPN de la société Acme à l'aide d'un VPN IPSec et aura une ressource de passerelle Internet qui bloque tout le trafic Internet entrant. Il sera nommé AcmeHRVCN.
- Trois sous-réseaux pour assurer l'isolation de l'accès réseau, l'un pour les ressources Autonomous Database des environnements Dev et Prod et l'autre pour les ressources client et de niveau intermédiaire de l'application. Ces sous-réseaux seront nommés DevVMSubnet, ProdVMSubnet et AppSubnet, respectivement.
Remarques :
Pour plus de simplicité, nous utilisons un seul VCN et utilisons des sous-réseaux pour assurer l'isolation du réseau. Toutefois, vous pouvez également créer plusieurs réseaux cloud virtuels afin de fournir l'isolation d'accès réseau requise. Dans cet exemple, nous créons les trois sous-réseaux : DevVMSubnet, ProdVMSubnet et AppSubnet sous FleetComp pour plus de simplicité. En fonction de vos besoins, vous pouvez éventuellement placer ces sous-réseaux dans des compartiments distincts. -
Déploiements Exadata Cloud@Customer :
- Configurez les règles réseau comme indiqué dans Exigences réseau pour Oracle Exadata Database Service on Cloud@Customer dans Préparation pour Exadata Database Service on Cloud@Customer.
- De plus, ouvrez le port 1522 pour autoriser le trafic TCP entre la base de données principale et la base de données de secours dans une configuration Autonomous Data Guard.
Ressources Autonomous Database
- Une infrastructure Exadata pour héberger deux AVMC. Il est nommé AcmeInfrastructure.
- Deux AVMC dans AcmeInfrastructure pour les environnements de développement et de production. Ces AVMC sont nommés respectivement DevAVMC et ProdAVMC.
- DevAVMC:
- Héberge la base de données Conteneur Autonomous et l'instance Autonomous Database, nommées respectivement DevACD et DevADB, pour le développement et le test de l'application AcmeHR.
- Un patch est toujours appliqué à la dernière RU (mise à jour de version).
- Conserve sept (7) jours de sauvegardes.
- Pour chaque mise à jour de version ou version de patch, AcmeHR déployé sur DevADB est testé avec la dernière mise à jour de version.
- En cas de problème critique, un patch exceptionnel est demandé. Après avoir appliqué le patch exceptionnel, AcmeHR est à nouveau validé pour s'assurer que le code est stable et adapté à la promotion en production. Pour en savoir plus sur les patches exceptionnels, reportez-vous à Maintenance du service Autonomous Database.
- ProdAVMC:
- Héberge la base de données Conteneur Autonomous et l'instance Autonomous Database provisionnées pour le déploiement de production de l'application AcmeHR. Ils sont nommés respectivement ProdACD et ProdADB.
- S'exécute toujours sur la version du logiciel N-1.
- Conserve les sauvegardes pendant une durée plus longue. Si nécessaire, les sauvegardes à long terme sont également activées.
- Des trimestres alternatifs appliqués au logiciel validé, c'est-à-dire que les unités de ressources validées dans DevAVMC sont déployées dans cette base de données.
Etapes principales
Avant de commencer à configurer des ressources Autonomous Database sur une infrastructure Exadata dédiée, Acme I.T. demande une augmentation de limite de service à l'aide de la console OCI pour ajouter des ressources d'infrastructure Exadata - Serveurs de base de données et serveurs de stockage à la location. Pour plus d'informations, reportez-vous à Demande d'augmentation de limite de service.
Voici les principales étapes à suivre pour implémenter ce cas d'emploi :
- L'administrateur de sécurité pour la location cloud de la société Acme crée les compartiments, groupes et stratégies de compartiment suivants pour l'isolation des ressources :
- Les compartiments FleetComp, DevComp et ProdComp.
- Groupes FAGroup, DevGroup et ProdGroup.
- Stratégies FleetCompPolicy, DevCompPolicy et ProdCompPolicy.
- Pour l'isolation des accès :
- Pour les déploiements Oracle Public Cloud, le service informatique Acme ou l'administrateur réseau pour Acme crée les ressources réseau suivantes dans le compartiment FleetComp :
- VCN : AcmeHRVCN
- Sous-réseaux privés : DevVMSubnet et ProdVMSubnet
- Sous-réseau public : AppSubnet
- Pour les déploiements Exadata Cloud@Customer, Acme I.T. ou l'administrateur réseau d'Acme s'assure :
- Configurez les règles réseau comme indiqué dans Exigences réseau pour Oracle Exadata Database Service on Cloud@Customer dans Préparation pour Exadata Database Service on Cloud@Customer.
- Ouvrez le port 1522 pour autoriser le trafic TCP entre la base de données principale et la base de données de secours dans une configuration Autonomous Data Guard.
- Pour les déploiements Oracle Public Cloud, le service informatique Acme ou l'administrateur réseau pour Acme crée les ressources réseau suivantes dans le compartiment FleetComp :
- Après avoir créé des ressources réseau, l'administrateur de sécurité ajoute l'utilisateur cloud d'un membre d'IT Acme désigné à FAGroup, autorisant ainsi cet utilisateur en tant qu'administrateur de parc.
- Le nouvel administrateur de parc autorisé crée les ressources d'infrastructure dédiée suivantes :
- Ressource d'infrastructure Exadata AcmeInfrastructure dans le compartiment FleetComp.
- Deux clusters de machines virtuelles Exadata Autonomous (AVMC) dans le compartiment FleetComp, indiquant l'infrastructure Exadata nouvellement créée :
- DevAVMC.
Pour les déploiements Oracle Public Cloud, spécifiez AcmeHRVCN et DevVMSubnet en tant que VCN et sous-réseau.
- ProdAVMC.
Pour les déploiements Oracle Public Cloud, spécifiez AcmeHRVCN et ProdVMSubnet en tant que VCN et sous-réseau.
- DevAVMC.
- L'administrateur de sécurité ajoute ensuite les utilisateurs cloud désignés aux environnements DevGroup et ProdGroup, les autorisant ainsi en tant qu'administrateurs de base de données d'application pour les environnements Dev et Prod.
- Les administrateurs de base de données d'application nouvellement autorisés créent les ressources suivantes dans leurs environnements de travail respectifs, à savoir Dev et Prod :
- Deux bases de données Conteneur Autonomous :
- DevACD dans le compartiment DevComp, en indiquant DevAVMC comme ressource sous-jacente
- ProdACD dans le compartiment ProdComp, en indiquant Prod AVMC comme ressource sous-jacente.
- Autonomous Database nommé DevADB dans le compartiment DevComp.
- Autonomous Database nommé ProdADB dans le compartiment ProdComp.
- Deux bases de données Conteneur Autonomous :
Etape 1. Création de compartiments
Au cours de cette étape, l'administrateur de la sécurité de la location cloud de la société Acme crée les compartiments FleetComp, DevComp et ProdComp.
Pour effectuer cette étape, l'administrateur de la sécurité suit les instructions fournies dans Gestion des compartiments dans la documentation Oracle Cloud Infrastructure afin de créer un compartiment à l'aide de la console Oracle Cloud. En suivant ces instructions, l'administrateur de la sécurité indique le compartiment racine de la location en tant que compartiment parent de chacun des trois compartiments.
Etape 2. Création de groupes
Au cours de cette étape, l'administrateur de sécurité crée les groupes FAGroup, DevGroup et ProdGroup.
Pour effectuer cette étape, l'administrateur de la sécurité suit les instructions fournies dans Gestion des groupes dans la documentation Oracle Cloud Infrastructure afin de créer un groupe à l'aide de la console Oracle Cloud.
Etape 3. Création de stratégies
Au cours de cette étape, l'administrateur de sécurité crée les stratégies FleetCompPolicy, DevCompPolicy et ProdCompPolicy.
Pour effectuer cette étape, l'administrateur de la sécurité suit les instructions fournies dans Gestion des stratégies dans la documentation Oracle Cloud Infrastructure afin de créer une stratégie à l'aide de la console Oracle Cloud.
Remarques :
Outre la création des instructions de stratégie requises, dans cet exemple, l'administrateur de la sécurité crée également des instructions de stratégie "USE tag-namespaces" pour permettre aux membres de groupe d'affecter des balises existantes aux ressources qu'ils créent. Pour permettre aux membres de groupe de créer des balises et d'utiliser des balises existantes, l'administrateur de la sécurité doit plutôt créer des instructions de stratégie "MANAGE tag-namespaces".En suivant ces instructions pour la stratégie FleetCompPolicy, l'administrateur de la sécurité effectue les opérations suivantes :
-
Définit le compartiment dans le menu latéral sur FleetComp avant de cliquer sur Créer une stratégie
-
Ajoute l'une des instructions de stratégie suivantes en fonction de leur plate-forme de déploiement :
- Déploiements Oracle Public Cloud :
- Autoriser le groupe FAGroup à gérer les infrastructures cloud-exadata-infrastructures dans le compartiment FleetComp
- Autoriser le groupe FAGroup à gérer les clusters cloud-autonomous-vmclusters dans le compartiment FleetComp
- Autoriser le groupe FAGroup à utiliser virtual-network-family dans le compartiment FleetComp
- Autoriser le groupe FAGroup à utiliser les espaces de noms de balise dans le compartiment FleetComp
- Autoriser le groupe DevGroup à lire les infrastructures cloud-exadata-infrastructures dans le compartiment FleetComp
- Autoriser le groupe DevGroup à lire les clusters cloud-autonomous-vmclusters dans le compartiment FleetComp
- Autoriser le groupe DevGroup à utiliser virtual-network-family dans le compartiment FleetComp
- Autoriser le groupe ProdGroup à lire les infrastructures cloud-exadata-infrastructures dans le compartiment FleetComp
- Autoriser le groupe ProdGroup à lire les clusters cloud-autonomous-vmclusters dans le compartiment FleetComp
- Autoriser le groupe ProdGroup à utiliser virtual-network-family dans le compartiment FleetComp
- Déploiements Exadata Cloud@Customer :
- Autoriser le groupe FAGroup à gérer les infrastructures exadata dans le compartiment FleetComp
- Autoriser le groupe FAGroup à gérer des clusters Autonomous-vmclusters dans le compartiment FleetComp
- Autoriser le groupe FAGroup à utiliser les espaces de noms de balise dans le compartiment FleetComp
- Autoriser le groupe DevGroup à lire les infrastructures d'exadata dans le compartiment FleetComp
- Autoriser le groupe DevGroup à lire les clusters Autonomous-vmclusters dans le compartiment FleetComp
- Autoriser le groupe ProdGroup à lire les infrastructures d'exadata dans le compartiment FleetComp
- Autoriser le groupe ProdGroup à lire les clusters Autonomous-vmclusters dans le compartiment FleetComp
- Déploiements Oracle Public Cloud :
En suivant ces instructions pour la stratégie DevCompPolicy, l'administrateur de la sécurité effectue les opérations suivantes :
-
Définit le compartiment dans le menu latéral sur DevComp avant de cliquer sur Créer une stratégie
-
Ajoute les instructions de stratégie suivantes :
- Autoriser le groupe DevGroup à gérer des bases de données de conteneur autonome dans le compartiment DevComp
- Autoriser le groupe DevGroup à gérer des bases de données autonomes dans le compartiment DevComp
- Autoriser le groupe DevGroup à gérer les sauvegardes autonomes dans le compartiment DevComp
- Autoriser le groupe DevGroup à gérer la famille d'instances dans le compartiment DevComp
- Autoriser le groupe DevGroup à utiliser les espaces de noms de balise dans le compartiment DevComp
- Autoriser le groupe DevGroup à gérer les mesures dans le compartiment DevComp
- Autoriser le groupe DevGroup à INSPECT les demandes de travail dans le compartiment DevComp
En suivant ces instructions pour la stratégie ProdCompPolicy, l'administrateur de la sécurité effectue les opérations suivantes :
-
Définit le compartiment dans le menu latéral sur ProdComp avant de cliquer sur Créer une stratégie
-
Ajoute les instructions de stratégie suivantes :
- Autoriser le groupe ProdGroup à gérer des bases de données de conteneur autonome dans le compartiment ProdComp
- Autoriser le groupe ProdGroup à gérer des bases de données autonomes dans le compartiment ProdComp
- Autoriser le groupe ProdGroup à gérer les sauvegardes autonomes dans le compartiment ProdComp
- Autoriser le groupe ProdGroup à gérer la famille d'instances dans le compartiment ProdComp
- Autoriser le groupe ProdGroup à utiliser les espaces de noms de balise dans le compartiment ProdComp
- Autoriser le groupe ProdGroup à gérer les mesures dans le compartiment ProdComp
- Autoriser le groupe ProdGroup à INSPECT les demandes de travail dans le compartiment ProdComp
Etape 4. Création du réseau cloud virtuel et de sous-réseaux
S'APPLIQUE À : 
Oracle Public Cloud uniquement
Au cours de cette étape, Acme I.T. ou l'administrateur réseau d'Acme crée le VCN AcmeHRVCN et les sous-réseaux DevVMSubnet, ProdVMSubnet et AppSubnet dans le compartiment FleetComp.
Pour effectuer cette étape, Acme I.T. consulte les fonctions de réseau du service informatique d'Acme afin de réserver une plage d'adresses IP CIDR qui n'entrera pas en conflit avec le réseau sur site de la société. (Sinon, le réseau cloud virtuel serait en conflit avec le réseau sur site, et aucun VPN IPSec ne pourrait être configuré.) La plage réservée est la plage CIDR 10.0.0.0/16.
Ensuite, Acme I.T. adapte les instructions du scénario B : sous-réseau privé avec un VPN dans la documentation Oracle Cloud Infrastructure pour créer le VCN, les sous-réseaux et d'autres ressources réseau à l'aide de la console Oracle Cloud.
- Deux sous-réseaux privés :
- 10.0.10.0/24 pour DevVMSubnet
- 10.0.20.0/24 pour ProdVMSubnet
- Un sous-réseau public :
- 10.0.100.0/24 pour AppSubnet
- DevSeclist : liste de sécurité de base pour DevVMSubnet. Elle est utilisée lorsque le sous-réseau DevVMSubnet est créé.
- ProdSeclist : liste de sécurité de base pour ProdVMSubnet. Elle est utilisée lorsque le sous-réseau ProdVMSubnet est créé.
- AppSeclist : liste de sécurité de base pour AppSubnet. Elle est utilisée lorsque le sous-réseau AppSubnet est créé.
Pour plus d'informations sur les exigences entrantes et sortantes AVMC, reportez-vous à Configuration requise pour provisionner un cluster de machines virtuelles Exadata Autonomous.
Règles de sécurité dans DevSeclist
Voici les règles entrantes créées dans DevSeclist :
| Sans conservation de statut | Source | Protocole IP | Plage de ports source | Plage de ports de destination | Type et code | Permet |
|---|---|---|---|---|---|---|
| No | 10.0.10.0/24 | ICMP | Toutes | Toutes | Toutes | Trafic ICMP pour : Tout |
| No | 10.0.10.0/24 | TCP | Toutes | Toutes | Trafic TCP pour les ports : Tout | |
| No | 10.0.100.0/24 | TCP | Toutes | 1521 | Trafic TCP pour le port : 1521 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Toutes | 2484 | Trafic TCPS pour le port : 2484 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Toutes | 6200 | ONS/FAN pour les ports : 6200 | |
| No | 10.0.100.0/24 | TCP | Toutes | 443 | Trafic HTTPS pour le port : 443 |
Voici les règles sortantes créées dans DevSeclist :
| Sans conservation de statut | Destination | Protocole IP | Plage de ports source | Plage de ports de destination | Type et code | Permet |
|---|---|---|---|---|---|---|
| No | 10.0.10.0/24 | ICMP | Toutes | Toutes | Toutes | Tout le trafic ICMP dans DevVMSubnet |
| No | 10.0.10.0/24 | TCP | Toutes | Toutes | Tout le trafic TCP dans DevVMSubnet |
Règles de sécurité dans ProdSeclist
Remarques :
Même si ProdSeclist a les mêmes règles de sécurité que DevSeclist, l'administrateur réseau a créé des listes de sécurité distinctes au lieu de créer une liste de sécurité unique pour les deux équipes de projet afin de prendre en charge toutes les règles de sécurité supplémentaires requises par l'une des équipes de projet à l'avenir.Voici les règles entrantes créées dans ProdSeclist :
| Sans conservation de statut | Source | Protocole IP | Plage de ports source | Plage de ports de destination | Type et code | Permet |
|---|---|---|---|---|---|---|
| No | 10.0.20.0/24 | ICMP | Toutes | Toutes | Toutes | Trafic ICMP pour : Tout |
| No | 10.0.20.0/24 | TCP | Toutes | Toutes | Trafic TCP pour les ports : Tout | |
| No | 10.0.100.0/24 | TCP | Toutes | 1521 | Trafic TCP pour le port : 1521 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Toutes | 2484 | Trafic TCPS pour le port : 2484 Oracle Net | |
| No | 10.0.100.0/24 | TCP | Toutes | 6200 | ONS/FAN pour les ports : 6200 | |
| No | 10.0.100.0/24 | TCP | Toutes | 443 | Trafic HTTPS pour le port : 443 |
Voici les règles sortantes créées dans ProdSeclist :
| Sans conservation de statut | Destination | Protocole IP | Plage de ports source | Plage de ports de destination | Type et code | Permet |
|---|---|---|---|---|---|---|
| No | 10.0.20.0/24 | ICMP | Toutes | Toutes | Toutes | Tout le trafic ICMP dans ProdVMSubnet |
| No | 10.0.20.0/24 | TCP | Toutes | Toutes | Tout le trafic TCP dans ProdVMSubnet |
Règles de sécurité dans AppSeclist
Voici la règle entrante créée dans AppSeclist :
| Sans conservation de statut | Source | Protocole IP | Plage de ports source | Plage de ports de destination | Type et code | Permet |
|---|---|---|---|---|---|---|
| No | 0.0.0.0/0 | TCP | Toutes | 22 | Toutes | Trafic SSH pour les ports : 22 |
Remarques :
Il est recommandé de remplacer 0.0.0.0/0 dans les règles de sécurité par votre liste approuvée d'adresses IP/de plage CIDR.Voici les règles sortantes créées dans AppSeclist :
| Sans conservation de statut | Destination | Protocole IP | Plage de ports source | Plage de ports de destination | Type et code | Permet |
|---|---|---|---|---|---|---|
| No | 10.0.10.0/24 | TCP | Toutes | 1521 | ||
| No | 10.0.10.0/24 | TCP | Toutes | 2484 | ||
| No | 10.0.10.0/24 | TCP | Toutes | 443 | ||
| No | 10.0.10.0/24 | TCP | Toutes | 6200 | ||
| No | 10.0.20.0/24 | TCP | Toutes | 1521 | ||
| No | 10.0.20.0/24 | TCP | Toutes | 2484 | ||
| No | 10.0.20.0/24 | TCP | Toutes | 443 | ||
| No | 10.0.20.0/24 | TCP | Toutes | 6200 |
Etape 5. Affectation d'un administrateur de parc
Au cours de cette étape, l'administrateur de la sécurité ajoute l'utilisateur cloud d'un membre désigné d'Acme I.T. au fichier FAGroup.
Pour effectuer cette étape, l'administrateur de la sécurité suit les instructions fournies dans Gestion des utilisateurs dans la documentation Oracle Cloud Infrastructure afin d'ajouter un utilisateur à un groupe à l'aide de la console Oracle Cloud.
Etape 6. Création de la ressource d'infrastructure Exadata
Au cours de cette étape, l'administrateur de parc suit les instructions fournies dans Création d'une ressource d'infrastructure Exadata pour créer une ressource d'infrastructure Exadata nommée AcmeInfrastructure dans le compartiment FleetComp.
Etape 7. Création des ressources de cluster de machines virtuelles Exadata Autonomous
Au cours de cette étape, l'administrateur de parc suit les instructions de création d'un cluster de machines virtuelles Exadata Autonomous pour créer DevAVMC et ProdAVMC dans le compartiment FleetComp avec les spécifications suivantes, en laissant tous les autres attributs avec leurs paramètres par défaut.
| Paramétrage | Environnement de développement | Environnement de production |
|---|---|---|
| Nom AVMC | DevAVMC | ProdAVMC |
| Infrastructure Exadata sous-jacente | AcmeInfrastructure | AcmeInfrastructure |
| Réseau cloud virtuel
S'APPLIQUE À : |
AcmeHRVCN | AcmeHRVCN |
| Sous-réseau
S'APPLIQUE À : |
DevVMSubnet | ProdVMSubnet |
Etape 8. Affecter des administrateurs de base de données d'application
Au cours de cette étape, l'administrateur de sécurité ajoute les utilisateurs cloud désignés à DevGroup, les autorisant ainsi en tant qu'administrateurs de base de données d'application pour les ressources de développement, puis répète le processus pour ProdGroup.
Pour effectuer cette étape, l'administrateur de la sécurité suit les instructions fournies dans Gestion des utilisateurs dans la documentation Oracle Cloud Infrastructure afin d'ajouter chaque utilisateur à un groupe à l'aide de la console Oracle Cloud.
Etape 9. Création de ressources de base de données Conteneur Autonomous
Au cours de cette étape, les administrateurs de base de données d'application respectifs suivent les instructions fournies dans Création d'une base de données Conteneur Autonomous afin de créer les bases de données Conteneur Autonomous pour les environnements Dev et Prod. Ces bases de données Conteneur Autonomous sont créées avec les spécifications suivantes, laissant tous les autres attributs à leurs paramètres par défaut.
| Paramétrage | Environnement de développement | Environnement de production |
|---|---|---|
| Compartiment | DevComp | ProdComp |
| Nom ACD | DevACD | ProdACD |
| AVMC sous-jacent | DevAVMC | ProdAVMC |
| Version de logiciel de base de données Conteneur | Dernière version du logiciel (N) | Prédécesseur immédiat de la version logicielle (N-1) |
| Version de maintenance | Dernière RU (mise à jour de version) | RU suivante (mise à jour de version) |
| Période de conservation de la sauvegarde | 7 jours | 30 jours |
Etape 10 . Création de ressources Autonomous Database
Au cours de cette étape, les administrateurs de base de données d'application respectifs suivent les instructions fournies dans Création d'une instance Autonomous Database afin de créer les instances Autonomous Database pour les environnements Dev et Prod. Ces bases de données sont créées avec les spécifications suivantes, laissant tous les autres attributs à leurs paramètres par défaut.
| Paramétrage | Environnement de développement | Environnement de production |
|---|---|---|
| Compartiment | DevComp | ProdComp |
| Nom de la base de données | DevADB | ProdADB |
| ACD sous-jacent | DevACD | ProdACD |
| Instance de base de données | Peut choisir de créer une instance Autonomous Database ou une instance Autonomous Database pour les développeurs | Autonomous Database |
Autonomous Database on Dedicated Exadata Infrastructure est désormais configuré pour développer et tester l'application AcmeHR, avec un déploiement ultérieur dans l'environnement de production.