機械翻訳について
  1. Exadata Database Service on Dedicated Infrastructure
  2. How-toガイド
  3. Exadata Cloud Infrastructureシステムのパッチ適用および更新
  4. Exadata Cloud Infrastructureシステムの手動でのパッチ適用および更新

Exadata Cloud Infrastructureシステムの手動によるパッチ適用および更新

このトピックでは、クラウド自動化の外部でExadata Cloud Serviceの様々なコンポーネントにパッチ適用および更新する手順について説明します。

dbaascliでのパッチ適用および更新の詳細は、"「dbaascliを使用したOracle Grid InfrastructureおよびOracle Databasesへのパッチ適用」"を参照してください。

ノート:

パッチ適用操作時の継続的サービスの実現に関する詳細なガイダンスは、『MAAソリューションの継続的サービスのアプリケーション・チェックリスト』(ホワイト・ペーパー)を参照してください。

関連トピック

親トピック: Exadata Cloud Infrastructureシステムのパッチ適用および更新

Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアへの手動でのパッチ適用

夏時間、および一部の定期パッチまたは個別パッチでは、ソフトウェアに手動でパッチを適用する必要があります。

Oracle DatabaseおよびOracle Grid Infrastructureソフトウェアの定期的なパッチ適用を実行するには、OracleではOracle Exadata Database Service on Dedicated Infrastructureが提供する機能を使用することをお薦めします。 ただし、状況によっては、Oracle DatabaseまたはOracle Grid Infrastructureソフトウェアに手動でパッチを適用する必要があります:
  • 夏時間(DST)のパッチ適用: ローリング方式では適用できないため、Oracle Database DST定義のパッチはExadataクラウド・インフラストラクチャのルーチン・パッチ・セットに含まれません。 Oracle Database DST定義にパッチを適用する必要がある場合は、手動で行う必要があります。 My Oracle Support Doc ID 412160.1を参照してください。
  • 非定例または個別パッチ適用: ルーチン・パッチ・セットに含まれていないパッチが必要な問題が発生した場合は、Oracle Support Servicesを使用して適切なパッチを特定および適用します。

Oracle Databaseへのパッチ適用に関する一般的な情報は、ご使用のリリースの「Oracle Databaseアップグレード・ガイド」でパッチ・セットの更新および要件に関する情報を参照してください。

関連トピック

親トピック: Exadata Cloud Infrastructureシステムの手動でのパッチ適用および更新

Exadata Cloud VMクラスタOSの手動更新

patchmgrツールを使用して、Exadataコンピュート・ノードのオペレーティング・システムを更新します。

このユーティリティでは、1つ以上のコンピュート・ノードの更新全体(再起動前、再起動および再起動後のステップの実行など)をリモートで管理します。 このユーティリティは、Exadataコンピュート・ノードまたはOracle Linuxを実行しているExadata以外のサーバーから実行できます。 ユーティリティを実行するサーバーは、「駆動システム」と呼ばれます。 駆動システムを使用してそれ自体を更新することはできません。 したがって、更新しているシステムで駆動システムがExadataコンピュート・ノードの1つである場合、別の駆動システムで別の操作を実行してそのサーバーを更新する必要があります。

次の2つのシナリオは、更新を実行する一般的な方法を示しています:

シナリオ1: Exadata以外の駆動システム

Exadataシステムの更新を実行する最も簡単な方法は、別のOracle Linuxサーバーを使用して、システム内のすべてのExadataコンピュート・ノードを更新することです。

シナリオ2: Exadataノード駆動システム

1つのExadataコンピュート・ノードを使用して、システムの残りのコンピュート・ノードの更新を駆動し、更新されたノードのいずれかを使用して元のExadataドライバ・ノードで更新を駆動できます。

たとえば: 4つのコンピュート・ノードがあるハーフ・ラックのExadataシステムを更新しています - node1、node2、node3およびnode4。 最初に、node1を使用してnode2、node3およびnode4の更新を駆動します。 次に、node2を使用してnode1の更新を実行します。

駆動システムでは、ユーティリティが更新する各コンピュート・ノードへのルート・ユーザーSSHアクセスが必要です。

親トピック: Exadata Cloud Infrastructureシステムの手動でのパッチ適用および更新

OSの更新の準備

使用可能な最新のソフトウェア・バージョンと適切なyumリポジトリへの接続の確認

注意:

Exadata Cloud InfrastructureインスタンスにNetworkManagerをインストールしないでください。 このパッケージをインストールしてシステム・リブートすると、システムへの重大なアクセス消失が発生します。
  • 更新を開始する前に、「Exadata Cloud Serviceソフトウェア・バージョン」 (「ドキュメントID 2333222.1」)を確認して、使用する最新のソフトウェア・バージョンとターゲット・バージョンを確認します。
  • 更新プロセスの一部のステップでは、YUMリポジトリを指定する必要があります。 YUMリポジトリのURLは次のとおりです: 
    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    リージョン識別子は、Oracle Cloud Infrastructureリージョンを識別するために使用されるテキスト文字列です(例: us-phoenix-1)。 リージョン識別子の完全なリストは、「リージョン」にあります。

    次のcurlコマンドを実行して、Exadata Cloud Serviceインスタンス・リージョンの最新バージョンのYUMリポジトリを確認できます: 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    次の例では、米国西部(フェニックス)リージョンのYUMリポジトリの最新バージョンが返されます: 
    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 -
  • OSの更新を適用するには、YUMリポジトリへのアクセスを許可するようにシステムVCNを構成する必要があります。 詳細は、「オプション2: Object StorageとYUMリポジトリの両方へのサービス・ゲートウェイ。」を参照してください。

関連トピック

親トピック: Exadata Cloud VMクラスタOSの手動更新

Exadata Cloud Infrastructureインスタンスのすべてのコンピュート・ノードでOSを更新するには

patchmgrを使用してすべてのコンピュート・ノードを更新するプロシージャ。

この例の手順では、次のことが想定されています:

  • システムには、node1とnode2の2つのコンピュート・ノードがあります。
  • ターゲット・バージョンは18.1.4.0.0.180125.3です。
  • 2つの各ノードは、他のノードで更新するための駆動システムとして使用されます。
  1. 環境の詳細を収集します。
    1. rootとしてSSHからnode1に、次のコマンドを実行してExadataのバージョンを確認します:
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. グリッド・ユーザーに切り替えて、クラスタ内のすべてのコンピュートを識別します。
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. 駆動システムを構成します。
    1. node1のrootユーザーに切り替えます。root sshキー・ペア(id_rsaおよびid_rsa.pub)がすでに存在するかどうかを確認します。 存在しない場合は生成します。 
      [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. 公開キーをターゲット・ノードに配布して、このステップを確認します。 この例では、ターゲット・ノードは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. ターゲット・ノード(この例ではnode2)で、ルートauthorized_keysファイルにnode1のルート公開キーを追加します。
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. dbserver.patch.zipをp21634633_12*_Linux-x86-64.zipとして駆動システム(この例ではnode1)にダウンロードし、解凍します。 dbnodeupdate.shおよびdbserver.patch.zipを参照してください: この.zipのファイルの詳細は、DBNodeUpdateユーティリティおよびpatchmgrを使用したExadataデータベース・サーバー・ソフトウェアの更新(ドキュメントID 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. 更新するコンピュート・ノードのリストを含むdbs_groupファイルを作成します。 ステップ1でolsnodes コマンドを実行した後にリストされたノード(駆動システム・ノードを除く)を含めます。 この例では、dbs_groupにnode2のみを含める必要があります。 
      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
[root@node1 dbserver_patch_5.180228]# cat dbs_group
node2
  3. パッチ適用の事前チェック操作を実行します。

    ノート:

    次のステップで実行するバックアップに影響を与える可能性があるシステムへの変更を防ぐには、-nomodify_at_prereqオプションを指定して事前チェック操作を実行する必要があります。 そうしないと、必要に応じてバックアップがシステムをロールバックできない場合があります。 
    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    出力は次のようになります: 
    [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. 現在のシステムをバックアップします。

    ノート:

    これは、システムに変更を加える前にバックアップを取得するのに適切な段階です。 
    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    出力は次のようになります: 
    [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. 更新されるターゲット・コンピュート・ノードからすべてのカスタムRPMを削除します。 カスタムRPMは事前チェック結果でレポートされます。 これには、システムのプロビジョニング後に手動でインストールされたRPMが含まれます。
    • バージョン12.1.2.3.4.170111からシステムを更新するときに、事前チェックの結果にkrb5-workstation-1.10.3-57.el6.x86_64が含まれている場合は、これを削除します。 (このアイテムは、このバージョンのカスタムRPMとみなされます。)
    • exadata-sun-vm-computenode-exactまたはoracle-ofed-release-guestは削除しないでください。 これら2つのRPMは、更新プロセス中に自動的に処理されます。
  6. nohupコマンドを実行して更新を実行します。
    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &
    出力は次のようになります:
    [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. 更新操作が完了したら、更新されたコンピュート・ノード上のカーネルのバージョンを確認します。
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. 駆動システムが(この例のように)更新が必要なコンピュート・ノードである場合、残りのコンピュート・ノードを更新する駆動システムとして、更新されたコンピュート・ノードを使用してこの手順のステップ2から7を繰り返します。 この例では、node2を使用してnode1を更新します。
  9. 各コンピュート・ノードで、uptrack-installコマンドをrootとして実行し、使用可能なksplice更新をインストールします。
    uptrack-install --all -y

親トピック: Exadata Cloud VMクラスタOSの手動更新

追加のオペレーティング・システム・パッケージのインストール

Oracle Exadata Database Service on Dedicated Infrastructureの追加のオペレーティング・システム・パッケージをインストールする前に、次のガイドラインを確認してください。

カーネルまたはInfiniBand固有のパッケージを変更しないかぎり、Oracle Exadata Database Service on Dedicated Infrastructureでオペレーティング・システム・パッケージをインストールおよび更新できます。 ただし、インストール、テスト、動作保証およびエラー解決を含むOracleテクニカル・サポートは、インストールするOracle以外のソフトウェアには適用されません。

また、Oracle Exadataソフトウェア更新とは別にパッケージを追加または更新すると、Oracle Exadataソフトウェア更新の適用時にこれらのパッケージの追加または更新によって問題が発生する可能性があることにも注意してください。 追加のソフトウェア・パッケージによって、Oracle Exadataの更新を中断する可能性のある新しい依存関係が追加されるため、問題が発生することがあります。 このため、Oracleではカスタマイズを最小限に抑えることをお薦めします。

追加のパッケージをインストールする場合、Oracleでは、これらのパッケージの削除および再インストールを自動化するスクリプトを用意することをお薦めします。 Oracle Exadataの更新後、追加のパッケージをインストールする場合は、追加のパッケージにまだ互換性があり、これらのパッケージがまだ必要であることを確認します。

詳細は、「Oracle Exadata Database Machineメンテナンス・ガイド」を参照してください。

関連トピック

親トピック: Exadata Cloud VMクラスタOSの手動更新

Exadata Cloud Infrastructureインスタンスのツールの更新

クラウド固有のツールは、Exadata Cloud InfrastructureゲストVMで、dbaascliコマンドなどのローカル操作に使用されます。

クラウド・ツールは、新しいリリースが使用可能になり次第、Oracleによって自動的に更新されます。 必要に応じて、「dbaascliを使用したクラウド・ツールの更新」のステップに従って、VMクラスタ内のすべての仮想マシンに最新バージョンのクラウド・ツールがあることを確認できます

関連トピック

親トピック: Exadata Cloud Infrastructureシステムの手動でのパッチ適用および更新