Documentazione di Oracle Cloud Infrastructure

Applicazione manuale di patch e aggiornamento di un sistema di infrastruttura Exadata Cloud

Questo argomento descrive le procedure per applicare patch e aggiornare vari componenti in Exadata Cloud Service al di fuori dell'automazione cloud.

Per informazioni relative all'applicazione di patch e all'aggiornamento con dbaascli, vedere "Applicazione di patch a Oracle Grid Infrastructure e ai database Oracle mediante dbaascli".

Nota

Per ulteriori indicazioni su come ottenere un servizio continuo durante le operazioni di applicazione delle patch, consultare il white paper Application Checklist for Continuous Service for MAA Solutions.

Argomenti correlati

Argomento padre: applicazione di patch e aggiornamento a un sistema di infrastruttura Exadata Cloud

Applicazione manuale di patch al software Oracle Database e Oracle Grid Infrastructure

Per l'ora legale e alcune patch di routine o una tantum, può essere necessario applicare le patch manualmente al software.

Per eseguire l'applicazione di patch di routine del software Oracle Database e Oracle Grid Infrastructure, Oracle consiglia di utilizzare le funzionalità fornite da Oracle Exadata Database Service on Dedicated Infrastructure. Tuttavia, in alcune circostanze, può essere necessario applicare manualmente le patch al software Oracle Database o Oracle Grid Infrastructure:
  • Applicazione di patch DST (Daylight Savings Time): poiché non possono essere applicate in sequenza, le patch per le definizioni DST di Oracle Database non vengono incluse nei set di patch di routine per l'infrastruttura Exadata Cloud. Se è necessario applicare le patch alle definizioni DST di Oracle Database, è necessario farlo manualmente. Vedere l'ID documento My Oracle Support 412160.1.
  • Applicazione di patch non di routine o singole: se si verifica un problema che richiede una patch non inclusa in alcun set di patch di routine, utilizzare Oracle Support Services per identificare e applicare la patch appropriata.

Per informazioni generali sull'applicazione di patch a Oracle Database, vedere le informazioni sugli aggiornamenti e i requisiti dei set di patch nella Guida all'aggiornamento di Oracle Database per la release in uso.

Aggiornamento manuale del sistema operativo cluster VM Exadata Cloud

Per aggiornare i sistemi operativi dei nodi di calcolo Exadata, utilizzare lo strumento patchmgr.

Questa utility gestisce da remoto l'intero aggiornamento di uno o più nodi di calcolo, incluse le operazioni di pre-reboot, reboot e post-reboot. È possibile eseguire la utility da un nodo di calcolo Exadata o da un server non Exadata su cui è in esecuzione Oracle Linux. Il server su cui si esegue l'utilità è noto come "sistema di guida". Non è possibile utilizzare il sistema di guida per aggiornarsi. Pertanto, se il sistema di gestione è uno dei nodi di calcolo Exadata in un sistema che si sta aggiornando, è necessario eseguire un'operazione separata su un sistema di gestione diverso per aggiornare tale server.

I due scenari riportati di seguito descrivono le modalità tipiche di esecuzione degli aggiornamenti.

Scenario 1: sistema di gestione non Exadata

Il modo più semplice per eseguire l'aggiornamento del sistema Exadata consiste nell'utilizzare un server Oracle Linux separato per aggiornare tutti i nodi di calcolo Exadata nel sistema.

Scenario 2: sistema di gestione dei nodi Exadata

È possibile utilizzare un nodo di calcolo Exadata per guidare gli aggiornamenti per il resto dei nodi di calcolo nel sistema, quindi utilizzare uno dei nodi aggiornati per guidare l'aggiornamento nel nodo del driver Exadata originale.

Ad esempio, si sta aggiornando un sistema Exadata half rack che dispone di quattro nodi di calcolo: node1, node2, node3 e node4. In primo luogo, utilizzare node1 per gestire gli aggiornamenti di node2, node3 e node4. Utilizzare quindi node2 per eseguire l'aggiornamento di node1.

Il sistema di gestione richiede l'accesso dell'utente root SSH a ogni nodo di calcolo che la utility aggiornerà.

Argomento padre: applicazione manuale di patch e aggiornamento di un sistema di infrastruttura Exadata Cloud

Preparazione per gli aggiornamenti del sistema operativo

Determinare la versione software più recente disponibile e la connettività al repository yum appropriato

Attenzione:

Non installare NetworkManager nell'istanza dell'infrastruttura Exadata Cloud. L'installazione di questo pacchetto e il reboot del sistema comporta una grave perdita di accesso al sistema.
  • Prima di iniziare gli aggiornamenti, vedere Versioni software di Exadata Cloud Service (ID documento 2333222.1) per determinare la versione software e la versione di destinazione più recenti da utilizzare.
  • Alcuni passi del processo di aggiornamento richiedono la specifica di un repository YUM. L'URL del repository YUM è: 
    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    Gli identificativi di area sono stringhe di testo utilizzate per identificare le aree di Oracle Cloud Infrastructure (ad esempio, us-phoenix-1). È possibile trovare un elenco completo degli identificativi delle aree in Aree.

    È possibile eseguire il seguente comando curl per determinare la versione più recente del repository YUM per l'area dell'istanza di Exadata Cloud Service: 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    Questo esempio restituisce la versione più recente del repository YUM per l'area occidentale degli Stati Uniti (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 -
  • Per applicare gli aggiornamenti del sistema operativo, è necessario configurare la VCN del sistema per consentire l'accesso al repository YUM. Per ulteriori informazioni, vedere Opzione 2: gateway di servizi per i repository di storage degli oggetti e YUM.

Per aggiornare il sistema operativo su tutti i nodi di calcolo di un'istanza dell'infrastruttura Exadata Cloud

Procedura per aggiornare tutti i nodi di calcolo utilizzando patchmgr.

Questa procedura di esempio si basa sui seguenti presupposti:

  • Il sistema dispone di due nodi di calcolo, node1 e node2.
  • La versione della destinazione è 18.1.4.0.0.180125.3.
  • Ciascuno dei due nodi viene utilizzato come sistema di guida per l'aggiornamento sull'altro.
  1. Raccogliere i dettagli dell'ambiente.
    1. SSH a node1 come root ed eseguire il comando seguente per determinare la versione di Exadata:
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. Passare all'utente Grid e identificare tutti i calcoli nel cluster.
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. Configurare il sistema di guida.
    1. Tornare all'utente root in node1 e verificare se esiste già una coppia di chiavi SSH root (id_rsa e id_rsa.pub). In caso contrario, generarlo.
      [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. Distribuire la chiave pubblica sui nodi di destinazione e verificare questo passo. In questo esempio, l'unico nodo di destinazione è 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. Nel nodo di destinazione (node2, in questo esempio), aggiungere la chiave pubblica radice di node1 al file authorized_keys radice.
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Scaricare dbserver.patch.zip come p21634633_12*_Linux-x86-64.zip nel sistema di guida (node1, in questo esempio) e decomprimerlo. Per informazioni sui file in questo file .zip, vedere dbnodeupdate.sh e dbserver.patch.zip: Aggiornamento del software del server di database Exadata mediante la utility DBNodeUpdate e patchmgr (ID documento 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. Creare il file dbs_group contenente la lista dei nodi di calcolo da aggiornare. Includere i nodi elencati dopo aver eseguito il comando olsnodes nel passo 1, ad eccezione del nodo del sistema di guida. In questo esempio, dbs_group deve includere solo node2.
      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
[root@node1 dbserver_patch_5.180228]# cat dbs_group
node2
  3. Eseguire un'operazione di controllo preliminare dell'applicazione delle patch.
    Nota

    È necessario eseguire l'operazione di controllo preliminare con l'opzione -nomodify_at_prereq per evitare modifiche al sistema che potrebbero influire sul backup eseguito nel passo successivo. In caso contrario, il backup potrebbe non essere in grado di eseguire il rollback del sistema allo stato originale, se necessario. 
    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    L'output dovrebbe essere simile al seguente: 
    [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. Eseguire il backup del sistema corrente.
    Nota

    Questa è la fase appropriata per eseguire il backup prima di apportare eventuali modifiche al sistema. 
    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    L'output dovrebbe essere simile al seguente: 
    [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. Rimuovere tutti gli RPM personalizzati dai nodi di calcolo di destinazione che verranno aggiornati. Gli RPM personalizzati vengono riportati nei risultati del controllo preliminare. Sono inclusi gli RPM installati manualmente dopo il provisioning del sistema.
    • Se si sta aggiornando il sistema dalla versione 12.1.2.3.4.170111 e i risultati del controllo preliminare includono krb5-workstation-1.10.3-57.el6.x86_64, rimuoverlo. (Questo elemento è considerato un RPM personalizzato per questa versione).
    • Non rimuovere exadata-sun-vm-computenode-exact o oracle-ofed-release-guest. Questi due RPM vengono gestiti automaticamente durante il processo di aggiornamento.
  6. Eseguire il comando nohup per eseguire l'aggiornamento.
    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &
    L'output dovrebbe essere simile al seguente:
    [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. Al termine dell'operazione di aggiornamento, verificare la versione del kernel nel nodo di calcolo che è stato aggiornato.
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. f il sistema di guida è un nodo di calcolo che deve essere aggiornato (come in questo esempio), ripetere i passi da 2 a 7 di questa procedura utilizzando un nodo di calcolo aggiornato come sistema di guida per aggiornare il nodo di calcolo rimanente. In questo esempio di aggiornamento, utilizzare node2 per aggiornare node1.
  9. Su ogni nodo di calcolo, eseguire il comando uptrack-install come root per installare gli aggiornamenti ksplice disponibili.
    uptrack-install --all -y

Installazione di pacchetti aggiuntivi del sistema operativo

Rivedere queste linee guida prima di installare pacchetti di sistemi operativi aggiuntivi per Oracle Exadata Database Service on Dedicated Infrastructure.

È consentito installare e aggiornare i pacchetti del sistema operativo in Oracle Exadata Database Service on Dedicated Infrastructure purché non si modifichino il kernel o i pacchetti specifici di InfiniBand. Tuttavia, il supporto tecnico Oracle, inclusi installazione, test, certificazione e risoluzione degli errori, non si applica ai software non Oracle installati.

Tenere inoltre presente che se si aggiungono o si aggiornano pacchetti separati da un aggiornamento del software Oracle Exadata, tali aggiunte o aggiornamenti di pacchetti possono presentare problemi quando si applica un aggiornamento del software Oracle Exadata. Si possono verificare problemi perché pacchetti software aggiuntivi aggiungono nuove dipendenze che possono interrompere un aggiornamento di Oracle Exadata. Per questo motivo, Oracle consiglia di ridurre al minimo la personalizzazione.

Se si installano pacchetti aggiuntivi, Oracle consiglia di disporre di script che automatizzino la rimozione e la reinstallazione di tali pacchetti. Dopo un aggiornamento di Oracle Exadata, se si installano pacchetti aggiuntivi, verificare che i pacchetti aggiuntivi siano ancora compatibili e che siano ancora necessari.

Per ulteriori informazioni, fare riferimento alla guida di manutenzione di Oracle Exadata Database Machine.

Aggiornamento degli strumenti in un'istanza dell'infrastruttura Exadata Cloud

Gli strumenti specifici per il cloud vengono utilizzati nelle VM guest dell'infrastruttura Exadata Cloud per le operazioni locali, inclusi i comandi dbaascli.

Gli strumenti cloud vengono aggiornati automaticamente da Oracle quando vengono rese disponibili nuove release. Se necessario, è possibile seguire i passi descritti in Aggiornamento di Cloud Tooling mediante dbaascli per assicurarsi di disporre della versione più recente degli strumenti cloud su tutte le virtual machine nel cluster VM