Documentation sur Oracle Cloud Infrastructure

Application manuelle de correctifs et de mises à jour à un système Exadata Cloud Infrastructure

Cette rubrique décrit les procédures pour appliquer des correctifs et des mises à jour à divers composants dans le service Exadata Cloud en dehors de l'automatisation en nuage.

Pour plus d'informations sur l'application de correctifs et de mises à jour avec dbaascli, voir "Application de correctifs à Oracle Grid Infrastructure et aux bases de données Oracle à l'aide de dbaascli".

Note

Pour obtenir des conseils pour assurer un service continu pendant les opérations d'application de correctifs, voir le document technique Liste de vérification pour le service continu pour les solutions MAA.

Rubriques connexes

Rubrique parent : Appliquer des correctifs et des mises à jour à un système Exadata Cloud Infrastructure

Application manuelle de correctifs aux logiciels Oracle Database et Oracle Grid Infrastructure

Pour l'heure avancée et certains correctifs de routine ou ponctuels, il peut être nécessaire d'appliquer manuellement des correctifs aux logiciels.

Pour appliquer des correctifs de routine aux logiciels Oracle Database et Oracle Grid Infrastructure, Oracle vous recommande d'utiliser les installations fournies par le service Oracle Exadata Database sur une infrastructure dédiée. Toutefois, dans certains cas, il peut être nécessaire d'appliquer manuellement des correctifs au logiciel Oracle Database ou Oracle Grid Infrastructure :
  • Correctif d'heure avancée (DST) : Comme ils ne peuvent pas être appliqués de manière continue, les correctifs des définitions DST d'Oracle Database ne sont pas inclus dans les jeux de correctifs de routine pour Exadata Cloud Infrastructure. Si vous devez appliquer des correctifs aux définitions DST d'Oracle Database, vous devez le faire manuellement. Voir My Oracle Support, ID document 412160.1.
  • Correctif non programmé ou ponctuel : Si vous rencontrez un problème qui nécessite un correctif qui n'est inclus dans aucun jeu de correctifs de routine, travaillez avec le soutien technique d'Oracle pour identifier et appliquer le correctif approprié.

Pour des informations générales sur l'application de correctifs Oracle Database, voir "Mises à jour de jeu de correctifs et exigences pour la mise à niveau d'Oracle Database" dans le Guide de mise à niveau d'Oracle Database pour votre version.

Mise à jour manuelle du système d'exploitation de grappe de machines virtuelles Exadata Cloud

Vous mettez à jour les systèmes d'exploitation des noeuds de calcul Exadata à l'aide de l'outil patchmgr.

Cet utilitaire gère la mise à jour complète d'un ou de plusieurs noeuds de calcul à distance, notamment les étapes de préredémarrage, de redémarrage et de post-redémarrage. Vous pouvez exécuter l'utilitaire à partir d'un noeud de calcul Exadata ou d'un serveur non Exadata exécutant Oracle Linux. Le serveur sur lequel vous exécutez l'utilitaire est appelé "système directeur". Vous ne pouvez pas utiliser le système directeur pour le mettre à jour. Par conséquent, s'il est l'un des noeuds de calcul Exadata sur un système que vous mettez à jour, vous devez exécuter une opération distincte sur un système directeur différent pour mettre à jour ce serveur.

Les deux scénarios suivants décrivent la manière habituelle d'effectuer des mises à jour :

Scénario 1 : Système directeur non Exadata

Le moyen le plus simple d'exécuter la mise à jour du système Exadata est d'utiliser un serveur Oracle Linux distinct pour actualiser tous les noeuds de calcul Exadata du système.

Scénario 2 : Système directeur de noeud Exadata

Vous pouvez utiliser un noeud de calcul Exadata pour diriger la mise à jour des autres noeuds de calcul du système, puis vous servir d'un des noeuds mis à jour pour diriger la mise à jour du premier noeud directeur Exadata.

Par exemple : Vous mettez à jour un système Exadata d'un demi-bâti, qui comporte quatre noeuds de calcul : node1, node2, node3 et node4. Utilisez d'abord node1 pour effectuer les mises à jour de node2, node3 et node4. Utilisez ensuite node2 pour mettre à jour node1.

Le système directeur requiert l'accès SSH de l'utilisateur racine pour chaque noeud de calcul à mettre à jour.

Rubrique parent : Application manuelle de correctifs et de mises à jour à un système Exadata Cloud Infrastructure

Préparation des mises à jour du système d'exploitation

Déterminez la dernière version de logiciel disponible et connectez-vous au référentiel yum approprié

Attention :

N'installez pas NetworkManager sur l'instance Exadata Cloud Infrastructure. L'installation de cet ensemble et le redémarrage du système entraînent des pertes graves d'accès au système.
  • Avant de commencer vos mises à jour, consultez Versions logicielles du service Exadata Cloud (ID document 2333222.1) pour déterminer la dernière version du logiciel et la version cible à utiliser.
  • Certaines étapes du processus de mise à jour exigent que vous indiquez un référentiel YUM. L'URL du référentiel YUM est : 
    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    Les identificateurs de région sont des chaînes de texte servant à identifier les régions Oracle Cloud Infrastructure (par exemple us-phoenix-1). Vous pouvez trouver une liste complète des identificateurs de région sous Régions.

    Vous pouvez exécuter la commande curl suivante pour déterminer la dernière version du référentiel YUM pour la région de l'instance du service Exadata Cloud : 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    Cet exemple retourne la version la plus récente du référentiel YUM pour la région États-Unis - Ouest (Phoenix) : 
    curl -s -X GET http://yum-us-phoenix-1.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
<a href="18.1.4.0.0/">18.1.4.0.0/</a> 01-Mar-2018 03:36 -
  • Pour appliquer les mises à jour du système d'exploitation, le réseau VCN du système doit être configuré de manière à autoriser l'accès au référentiel YUM. Pour plus d'informations, voir Option 2 : Accès par la passerelle de service au service de stockage d'objets et aux référentiels YUM.

Pour mettre à jour le système d'exploitation sur tous les noeuds de calcul d'une instance Exadata Cloud Infrastructure

Procédure de mise à jour de tous les noeuds de calcul à l'aide de patchmgr.

Cet exemple de procédure suppose les conditions suivantes :

  • Le système comporte deux noeuds de calcul : node1 et node2.
  • La version cible est 18.1.4.0.0.180125.3.
  • Chacun des deux noeuds est utilisé comme système directeur pour la mise à jour de l'autre.
  1. Collectez les détails de l'environnement.
    1. SSH to node1 as root and run the following command to determine the version of Exadata:
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. Passez à l'utilisateur grid et identifiez toutes les instances de calcul dans la grappe.
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. Configurez le système directeur.
    1. Retournez à l'utilisateur root sur le node1. Vérifiez si une paire de clés SSH racine (id_rsaet id_rsa.pub) existe déjà. Si tel n'est pas le cas, générez-la.
      [root@node1 .ssh]#  ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory
[root@node1 .ssh]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.fraad1client.exadataclientne.oraclevcn.com
The key's randomart image is:
+--[ RSA 2048]----+
|o..     + .      |
|o.     o *       |
|E     . o o      |
| . .     =       |
|  o .   S =      |
|   +     = .     |
|    +   o o      |
|   . .   + .     |
|      ...        |
+-----------------+
    2. Distribuez la clé publique aux noeuds cibles, puis vérifiez cette étape. Dans cet exemple, le seul noeud cible est node2.
      [root@node1 .ssh]# scp -i ~opc/.ssh/id_rsa ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
id_rsa.pub

[root@node2 ~]# ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
[root@node2 ~]# date
Wed Feb 28 03:33:45 UTC 2018
    3. Sur le noeud cible (node2 dans cet exemple), ajoutez la clé publique racine de node1 au fichier root authorized_keys.
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Téléchargez dbserver.patch.zip sous le nom p21634633_12*_Linux-x86-64.zip dans le système directeur (node1 dans cet exemple) et décompressez-le. Voir dbnodeupdate.sh et dbserver.patch.zip : Mise à jour du logiciel du serveur de base de données Exadata à l'aide de l'utilitaire DBNodeUpdate et de patchmgr (ID document 1553103.1) pour plus d'informations sur les fichiers de ce .zip.
      [root@node1 patch]# mkdir /root/patch
[root@node1 patch]# cd /root/patch
[root@node1 patch]# unzip p21634633_181400_Linux-x86-64.zip
Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
   creating: dbserver_patch_5.180228.2/ibdiagtools/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
  inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
 extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
  inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
  inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
   creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
  inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
   creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
  inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
  inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
  inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
  inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
  inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
  inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
   creating: dbserver_patch_5.180228.2/linux.db.rpms/
  inflating: dbserver_patch_5.180228.2/md5sum_files.lst
  inflating: dbserver_patch_5.180228.2/patchmgr
  inflating: dbserver_patch_5.180228.2/xcp
  inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
  inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
  inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
  inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
  inflating: dbserver_patch_5.180228.2/exadata.img.env
  inflating: dbserver_patch_5.180228.2/README.txt
  inflating: dbserver_patch_5.180228.2/exadataLogger.pm
  inflating: dbserver_patch_5.180228.2/patch_bug_26678971
  inflating: dbserver_patch_5.180228.2/dcli
  inflating: dbserver_patch_5.180228.2/patchReport.py
 extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
   creating: dbserver_patch_5.180228.2/plugins/
  inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
  inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
  inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
  inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
  inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
  inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
  inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
  inflating: dbserver_patch_5.180228.2/patchmgr_functions
  inflating: dbserver_patch_5.180228.2/exadata.img.hw
  inflating: dbserver_patch_5.180228.2/libxcp.so.1
  inflating: dbserver_patch_5.180228.2/imageLogger
  inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
  inflating: dbserver_patch_5.180228.2/fwverify
    5. Créez le fichier dbs_group qui contient la liste des noeuds de calcul à mettre à jour. Incluez les noeuds listés après l'exécution de la commande olsnodes à l'étape 1, sauf pour le noeud de système directeur. Dans cet exemple, dbs_group doit inclure uniquement node2.
      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
[root@node1 dbserver_patch_5.180228]# cat dbs_group
node2
  3. Exécutez une opération de vérification préalable pour l'application de correctifs.
    Note

    Vous devez exécuter l'opération de vérification préalable avec l'option -nomodify_at_prereq pour éviter toute modification du système qui pourrait avoir une incidence sur la sauvegarde que vous effectuez à l'étape suivante. Sinon, la sauvegarde risque de ne pas pouvoir repositionner le système à son état initial, si nécessaire. 
    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    La sortie doit ressembler à l'exemple suivant : 
    [root@node1 dbserver_patch_5.180228]# ./patchmgr -dbnodes dbs_group -precheck -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -nomodify_at_prereq

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s).
  4. Sauvegardez le système courant.
    Note

    C'est à cette étape que vous devez effectuer la sauvegarde, avant toute modification du système. 
    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    La sortie doit ressembler à l'exemple suivant : 
    [root@node1 dbserver_patch_5.180228]#  ./patchmgr -dbnodes dbs_group -backup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
************************************************************************************************************
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
  5. Supprimez tous les RPM personnalisés des noeuds de calcul cibles qui seront mis à jour. Les paquets RPM personnalisés sont signalés dans les résultats de la vérification préalable. Ils incluent les paquets RPM installés manuellement après le provisionnement du système.
    • Si vous mettez à jour le système à partir de la version 12.1.2.3.4.170111 et que les résultats de la vérification préalable incluent krb5-workstation-1.10.3-57.el6.x86_64, supprimez-le. (Cet élément est considéré comme un RPM personnalisé pour cette version.)
    • Ne supprimez pas exadata-sun-vm-computenode-exact ni oracle-ofed-release-guest. Ces deux paquets RPM sont traités automatiquement au cours de la mise à jour.
  6. Exécutez la commande nohup pour effectuer la mise à jour.
    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &
    La sortie doit ressembler à l'exemple suivant :
    [root@node1 dbserver_patch_5.180228]# nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -target_version 18.1.4.0.0.180125.3  -allow_active_network_mounts &

************************************************************************************************************
NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
NOTE
NOTE    Database nodes will reboot during the update process.
NOTE
WARNING Do not interrupt the patchmgr session.
WARNING Do not resize the screen. It may disturb the screen layout.
WARNING Do not reboot database nodes during update or rollback.
WARNING Do not open logfiles in write mode and do not try to alter them.
*********************************************************************************************************

2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. Une fois l'opération de mise à jour terminée, vérifiez la version du noyau du noeud de calcul mis à jour.
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. Si le système directeur est un noeud de calcul à mettre à jour (comme dans cet exemple), répétez les étapes 2 à 7 de cette procédure en utilisant un noeud de calcul mis à jour comme système directeur pour actualiser le noeud de calcul restant. Dans cet exemple de mise à jour, utilisez node2 pour mettre à jour node1.
  9. Sur chaque noeud de calcul, exécutez la commande uptrack-install en tant qu'utilisateur racine pour installer les mises à jour ksplice disponibles.
    uptrack-install --all -y

Installation de programmes de système d'exploitation supplémentaires

Consultez ces directives avant d'installer des programmes de système d'exploitation pour le service Oracle Exadata Database sur une infrastructure dédiée.

Vous êtes autorisé à installer et mettre à jour des programmes de système d'exploitation sur le service Oracle Exadata Database sur une infrastructure dédiée, à condition de ne pas modifier les programmes propres au noyau ou à InfiniBand. Cependant, le soutien technique d'Oracle, notamment l'installation, les tests, la certification et la résolution des erreurs, ne s'applique à aucun logiciel non Oracle que vous installez.

Sachez également que si vous ajoutez ou mettez à jour des programmes distincts d'une mise à jour logicielle Oracle Exadata, ces ajouts ou mises à jour de programme peuvent poser des problèmes lorsque vous appliquez une mise à jour logicielle Oracle Exadata. Des problèmes peuvent se produire, car des programmes logiciels supplémentaires ajoutent de nouvelles dépendances pouvant interrompre une mise à jour Oracle Exadata. Pour cette raison, Oracle recommande de minimiser la personnalisation.

Si vous installez des programmes supplémentaires, Oracle recommande d'automatiser leur suppression et leur réinstallation. Après une mise à jour Oracle Exadata, si vous installez des programmes supplémentaires, vérifiez que ceux-ci sont toujours compatibles et que vous en avez encore besoin.

Pour plus d'informations, consultez le guide de maintenance d'Oracle Exadata Database Machine.

Mise à jour des outils sur une instance Exadata Cloud Infrastructure

Les outils propres au nuage sont utilisés sur les machines virtuelles invitées Exadata Cloud Infrastructure pour des opérations locales, notamment les commandes dbaascli.

Les outils en nuage sont automatiquement mis à jour par Oracle lorsque de nouvelles versions sont disponibles. Si nécessaire, vous pouvez suivre les étapes sous Mise à jour des outils en nuage à l'aide de dbaascli pour vous assurer d'avoir la dernière version des outils en nuage sur toutes les machines virtuelles de la grappe de machines virtuelles