Documentation Oracle Cloud Infrastructure

Application de patches à un système Exadata Cloud Infrastructure et mise à jour de celui-ci de façon manuelle

Cette rubrique décrit les procédures d'application de patches et de mise à jour relatives aux différents composants d'Exadata Cloud Service en dehors de l'automatisation du cloud.

Pour plus d'informations concernant l'application de patches et la mise à jour avec dbaascli, reportez-vous à Application de patches à Oracle Grid Infrastructure et aux bases de données Oracle à l'aide de dbaascli.

Remarque

Afin d'obtenir des instructions supplémentaires relatives à la continuité d'un service pendant les opérations d'application de patches, reportez-vous au livre blanc Liste de contrôle d'application pour la continuité de service des solutions MAA.

Rubriques connexes

Rubrique parent : Application de patches à un système Exadata Cloud Infrastructure et mise à jour de celui-ci

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

Pour l'heure d'été et certains patches de routine ou exceptionnels, il peut être nécessaire d'appliquer manuellement les patches aux logiciels.

Pour appliquer des patches de routine aux logiciels Oracle Database et Oracle Grid Infrastructure, Oracle recommande d'utiliser les fonctionnalités fournies par Oracle Exadata Database Service on Dedicated Infrastructure. Toutefois, dans certains cas, il peut être nécessaire d'appliquer manuellement les patches aux logiciels Oracle Database ou Oracle Grid Infrastructure :
  • Application de patches à l'heure d'été : comme ils ne peuvent pas être appliqués en mode non simultané, les patches des définitions de l'heure d'été Oracle Database ne sont pas inclus dans les ensembles de patches de routine pour Exadata Cloud Infrastructure. Pour appliquer des patches aux définitions de l'heure d'été d'Oracle Database, vous devez procéder manuellement. Reportez-vous au document My Oracle Support portant l'ID 412160.1.
  • Application de patches autres que les patches de routine ou de patches exceptionnels : si vous rencontrez un problème qui nécessite un patch non inclus dans un ensemble de patches de routine, contactez Oracle Support Services afin d'identifier et d'appliquer le patch approprié.

Pour obtenir des informations générales sur l'application de patches à Oracle Database, reportez-vous aux informations relatives aux mises à jour d'ensemble de patches et aux exigences du Guide de mise à niveau Oracle Database de votre version.

Mise à jour manuelle du système d'exploitation de cluster de machines virtuelles cloud Exadata

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

Cet utilitaire gère à distance la mise à jour complète de noeuds de calcul, y compris l'exécution des étapes avant, pendant et après le 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 nommé "système pilote". Vous ne pouvez pas utiliser le système pilote pour effectuer sa propre mise à jour. Par conséquent, si le système pilote 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 autre système pilote pour mettre à jour ce serveur.

Les deux scénarios suivants présentent des méthodes standard d'exécution des mises à jour :

Scénario 1 : système pilote non Exadata

La façon la plus simple d'exécuter la mise à jour du système Exadata consiste à utiliser un serveur Oracle Linux distinct pour mettre à jour tous les noeuds de calcul Exadata dans le système.

Scénario 2 : système pilote de noeud Exadata

Vous pouvez utiliser un noeud de calcul Exadata pour piloter les mises à jour des autres noeuds de calcul du système, puis utiliser l'un des noeuds mis à jour pour réaliser la mise à jour sur le noeud de pilote Exadata d'origine.

Par exemple : vous mettez à jour un système Exadata à demi-rack contenant quatre noeuds de calcul : node1, node2, node3 et node4. Utilisez d'abord node1 pour piloter les mises à jour de node2, de node3 et de node4. Utilisez ensuite node2 pour piloter la mise à jour de node1.

Le système pilote nécessite un accès SSH d'utilisateur root à chaque noeud de calcul que l'utilitaire va mettre à jour.

Rubrique parent : Application de patches à un système Exadata Cloud Infrastructure et mise à jour de celui-ci de façon manuelle

Préparation aux mises à jour de système d'exploitation

Déterminez la dernière version logicielle disponible et la connectivité au référentiel yum approprié.

Attention :

N'installez pas NetworkManager sur l'instance Exadata Cloud Infrastructure. L'installation de ce package et le redémarrage du système entraînent une perte sévère d'accès au système.
  • Avant de commencer les mises à jour, reportez-vous à Exadata Cloud Service Software Versions ( ID de document 233222.1) pour déterminer la dernière version logicielle et la version cible à utiliser.
  • Certaines étapes du processus de mise à jour exigent que vous indiquiez un référentiel YUM. L'URL du référentiel YUM est la suivante : 
    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 utilisées pour identifier les régions Oracle Cloud Infrastructure (par exemple, us-phoenix-1). Vous trouverez la liste complète des identificateurs de région dans Régions.

    Vous pouvez exécuter la commande curl suivante pour déterminer la dernière version du référentiel YUM de la région de votre instance Exadata Cloud Service : 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    Cet exemple renvoie la version la plus récente du référentiel YUM pour la région Ouest des Etats-Unis (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 cloud virtuel du système doit être configuré de façon à autoriser l'accès au référentiel YUM. Pour plus d'informations, reportez-vous à Option 2 : passerelle de service vers Object Storage et les référentiels YUM.

Procédure de mise à jour du 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 repose sur les conditions suivantes :

  • Le système dispose de deux noeuds de calcul : node1 et node2.
  • La version cible est 18.1.4.0.0.0.180125.3.
  • Chacun des deux noeuds est utilisé comme système pilote pour mettre à jour l'autre noeud.
  1. Collectez les informations relatives à l'environnement.
    1. Accédez via SSH à node1 en tant qu'utilisateur root et exécutez la commande suivante pour déterminer la version d'Exadata :
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. Passez à l'utilisateur grid et identifiez tous les noeuds de calcul dans le cluster.
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. Configurez le système pilote.
    1. Revenez à l'utilisateur root sur node1 et vérifiez si une paire de clés SSH racine (id_rsa et id_rsa.pub) existe déjà. Si ce 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 vers les noeuds cible et 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 racine authorized_keys.
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Téléchargez dbserver.patch.zip en tant que p21634633_12*_Linux-x86-64.zip sur le système pilote (node1 dans cet exemple) et décompressez-le. Pour plus d'informations sur les fichiers de ce ZIP, reportez-vous à dbnodeupdate.sh et dbserver.patch.zip : mise à jour du logiciel de serveur de base de données Exadata à l'aide de l'utilitaire DBNodeUpdate et de patchmgr (ID de document 1553103.1).
      [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 répertoriés après l'exécution de la commande olsnodes à l'étape 1, sauf le noeud de système pilote. 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 pré-vérification de l'application de patches.
    Remarque

    Vous devez exécuter l'opération de pré-vérification avec l'option -nomodify_at_prereq pour empêcher toute modification du système susceptible d'affecter la sauvegarde que vous effectuez à l'étape suivante. Dans le cas contraire, la sauvegarde risque de ne pas pouvoir restaurer l'état d'origine du système 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 en cours.
    Remarque

    Il s'agit de la phase appropriée pour 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. Enlevez tous les RPM personnalisés des noeuds de calcul cible qui seront mis à jour. Les RPM personnalisés sont signalés dans les résultats de la pré-vérification. Ils incluent les RPM qui ont été 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 prévérification incluent krb5-workstation-1.10.3-57.el6.x86_64, enlevez cet élément. (Il est considéré comme un RPM personnalisé pour cette version.)
    • N'enlevez pas exadata-sun-vm-computenode-exact, ni oracle-ofed-release-guest. Ces deux RPM sont gérés automatiquement lors du processus de 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 sur le noeud de calcul mis à jour.
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. Si le système pilote est un noeud de calcul qui doit être mis à 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 pilote pour mettre à jour 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 root pour installer les mises à jour ksplice disponibles.
    uptrack-install --all -y

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

Consultez ces instructions avant d'installer des packages de système d'exploitation supplémentaires pour Oracle Exadata Database Service on Dedicated Infrastructure.

Vous êtes autorisé à installer et mettre à jour des packages de système d'exploitation sur Oracle Exadata Database Service on Dedicated Infrastructure à condition de ne pas modifier les packages propres au noyau ou à InfiniBand. Toutefois, le support technique Oracle, notamment pour l'installation, le test, la certification et la résolution d'erreur, ne s'applique pas aux logiciels autres qu'Oracle que vous installez.

De plus, si vous ajoutez ou mettez à jour des packages en dehors d'une mise à jour du logiciel Oracle Exadata, ces ajouts ou mises à jour peuvent entraîner des problèmes lors de l'application d'une mise à jour du logiciel Oracle Exadata. Par exemple, les packages logiciels supplémentaires peuvent ajouter de nouvelles dépendances susceptibles d'interrompre une mise à jour Oracle Exadata. Pour cette raison, Oracle recommande de restreindre la personnalisation.

Si vous installez des packages supplémentaires, Oracle vous recommande de disposer de scripts permettant d'automatiser la suppression et la réinstallation de ces packages. Après toute mise à jour d'Oracle Exadata, vérifiez que les packages supplémentaires éventuellement installés sont toujours compatibles et que vous en avez toujours besoin.

Pour plus d'informations, reportez-vous au Guide de maintenance Oracle Exadata Database Machine.

Mise à jour des outils sur une instance Exadata Cloud Infrastructure

Des outils propres au cloud sont utilisés sur les machines virtuelles invitées Exadata Cloud Infrastructure pour les opérations locales, y compris les commandes dbaascli.

Les outils cloud sont automatiquement mis à jour par Oracle lorsque de nouvelles versions sont disponibles. Si nécessaire, vous pouvez suivre les étapes décrites dans Mise à jour des outils cloud à l'aide de dbaascli pour vous assurer que vous disposez de la dernière version des outils cloud sur toutes les machines virtuelles du cluster de machines virtuelles.