Grid Infrastructure管理

この項では、クラスタリングと高可用性をサポートするOracle Grid Infrastructureの管理に重点を置きます。主なタスクには、Grid Infrastructureホーム(dbaascli gridHome create)の構成、Grid Infrastructure (dbaascli grid upgrade)のアップグレード、およびTCPS (Transport Layer Security)証明書の構成(dbaascli grid configureTCPS)、削除(dbaascli grid removeTCPSCert)またはローテーション(dbaascli grid rotateTCPSCert)による管理が含まれます。これらのコマンドにより、Grid Infrastructureの設定、メンテナンスおよびセキュリティが効率的に確保されます。

dbaascli gridHome create
dbaascli grid configureTCPS
dbaascli grid removeTCPSCert
dbaascli grid rotateTCPSCert
dbaascli grid upgrade
dbaascli grid patch

dbaascli gridHome create

Grid Infrastructureホームを構成するには、dbaascli gridHome createコマンドを使用します。

前提条件:

rootユーザーとしてコマンドを実行します。

構文:

dbaascli gridHome create --version value [--resume [--sessionID value]] [--waitForCompletion value]

パラメータ:

パラメータ	説明
`--version`	グリッド・ホームのバージョンを指定します。
`--resume`	前回の実行を再開します
`--sessionID`	特定のセッションIDを再開するように指定します。
`--waitForCompletion`	`false`は、バックグラウンドで操作を実行するように指定します。有効な値: `true`または`false`

よくある質問:

Q: dbaascli gridHome createコマンドの目的は何ですか。

A: dbaascli gridHome createコマンドは、Oracle Base Database Cloud@Customer環境でOracle GridインフラストラクチャのGrid Infrastructureホームを構成するために使用します。

Q: dbaascli gridHome createコマンドを実行するための前提条件は何ですか。

A: このコマンドは、rootユーザーとして実行する必要があります。

Q: 作成する Grid Infrastructureホームのバージョンを指定する方法は?

A: --versionオプションを使用して、Gridホームのバージョンを指定します。Gridホームを作成する場合、これは必須オプションです。

質問: 以前のdbaascli gridHome create sessionを再開できますか。

A: はい。--resumeオプションを使用して、前のセッションを再開できます。オプションで、--sessionIDオプションを使用してセッションIDを指定して、特定のセッションを再開できます。

質問: dbaascli gridHome createコマンドでは、–resumeオプションは何を行いますか。

A: --resumeオプションを使用すると、以前に中断または不完全な操作を再開できます。

Q: バックグラウンドで操作を実行するにはどうすればよいですか?

A: --waitForCompletionオプションをfalseに設定して、操作をバックグラウンドで実行できます。このオプションに有効な値は、true (デフォルト)またはfalseです。

Q: –waitForCompletionが指定されていない場合、デフォルトの動作は何ですか。

A: --waitForCompletionが指定されていない場合、操作はフォアグラウンドで実行され、コマンドは操作が完了するまで待機してから、ユーザーに制御を戻します。

質問: –sessionIDオプションの目的は何ですか。

A: --sessionIDオプションは、操作が不完全または中断された場合に再開する前のセッションのIDを指定するために使用します。

質問: dbaascli gridHome createコマンドを使用して既存のGridホームをアップグレードできますか。

A: いいえ。このコマンドは、既存のGrid Infrastructureホームをアップグレードするのではなく、新しいGrid Infrastructureホームを構成するために特に使用されます。

質問: バージョン19.9.0.0.0のGridホームを作成するコマンド例は何ですか。

A: コマンドの例を次に示します。

dbaascli gridHome create --version 19.9.0.0.0

質問: dbaascli gridHome createコマンドが中断された場合はどうすればよいですか。

A: --resumeオプションを使用して操作を再開できます。セッションIDがある場合は、--sessionIDオプションを使用して指定し、特定のセッションを再開できます。

質問: セッションIDなしで–resumeオプションを指定できますか。

A: はい。セッションIDを指定せずに--resumeオプションを使用できます。この場合、システムは最新のセッションを再開しようとします。

質問: –waitForCompletion falseを指定するとどうなりますか。

A: --waitForCompletion falseを指定すると、操作はバックグラウンドで実行されるため、操作が完了するまでコマンドラインの使用を続行できます。

Q: バックグラウンド操作の進行状況を追跡することは可能ですか?

A: dbaascliコマンドは、バックグラウンド操作を追跡するための直接的な方法を提供しません。システム・ログまたはセッション・ステータスを手動で確認する必要がある場合があります。

Q: 無効なGridホーム・バージョンを作成するときに指定できますか。

A: いいえ、--versionオプションには有効なGrid Infrastructureバージョンが含まれている必要があります。無効なバージョンが指定されている場合、コマンドはエラーを返します。

Q: 作成に使用するGridホームのバージョンを確認するにはどうすればよいですか。

A: Oracleのドキュメントを参照するか、データベース管理者に問い合せて、使用している環境で使用する正しいGridホームのバージョンを判断できます。

Q: dbaascli gridHome createコマンドを実行する前に確認すべきことは何ですか。

A: rootユーザーとしてログインし、Grid Infrastructureに使用するバージョンが環境と互換性があることを確認します。

dbaascli grid configureTCPS

既存のクラスタにTCPSを構成するには、dbaascli grid configureTCPSコマンドを使用します。

前提条件:

rootユーザーとしてコマンドを実行します。

構文:

dbaascli grid configureTCPS
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]

パラメータ:

パラメータ	説明
`--pkcs12WalletFilePath`	証明書ファイルの絶対パス(`pkcs12`ウォレット形式)を指定します
`--caCertChain`	中間CAおよびルートCA証明書を含む証明書の連結リストです
`--precheckOnly`	`yes`は、1を指定するとこの操作の事前チェックのみが実行されます。有効な値: `yes`または`no`。
`--serverCert`	TCPS構成で使用またはローテーションするPEM証明書のパスを指定します。
`--privateKey`	証明書の秘密キー・ファイルのパスを指定します。
`--certType`	Grid Infrastructureウォレットに追加される証明書のタイプです。許容される値は、`SELF_SIGNED_CERT`、`CA_SIGNED_CERT`または`PKCS12_CERT`です。デフォルト: `SELF_SIGNED_CERT`
`--privateKeyPasswordProtected`	秘密キーがパスワードで保護されるかどうかを指定します。有効な値: `true`または`false` デフォルト: `true`。

Oracle Base Database Cloud@CustomerのTCPS構成:

TCPSの動作は、Oracle Base Database Cloud@Customerデプロイメント・タイプによって異なります。

Oracle Database 19c以降では、新たにプロビジョニングされたデータベースに対してTCPSがデフォルトで有効になっています。この動作が導入される前にプロビジョニングされた既存のデータベースでは、TCPSが有効になっていない可能性があります。

既存のデータベースに対してTCPSを有効にするには、次のようにWALLET_LOCATIONパラメータを追加して、すべてのデータベース・ノードでデータベース固有のsqlnet.oraファイルを更新します。

WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

すべてのデータベース・ノードでsqlnet.oraファイルを更新した後、データベースを再起動してTCPSを有効にします。

データベースがWALLET_ROOTパラメータを使用するように構成されていない場合、TCPSを有効にすると、Oracle Zero Data Loss Recovery Appliance (ZDLRA)接続に影響する可能性があります。TCPSを有効にする前に、次の前提条件を満たしていることを確認します。

データベースでOracle Databaseリリース更新19.17以降が実行されています。
データベースがWALLET_ROOTパラメータを使用するように構成されています。
データベースがZDLRAバックアップ用に構成されている場合は、RMANチャネル構成がWALLET_ROOT/server_sepsのRA_WALLETを参照していることを確認します。

たとえば:

RMANに接続します。
次のコマンドを実行します:
```
SHOW CHANNEL;
```

出力に次のようなRA_WALLETエントリが含まれていることを確認します。

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%I_%U_%T_%t' PARMS "SBT_LIBRARY=/u02/app/oracle/product/19.0.0.0/dbhome_1/lib/libra.so, ENV=(RA_WALLET='location=file:/var/opt/oracle/dbaas_acfs/dbrs19c/wallet_root/server_seps credential_alias=DBRS')";

この例では、RA_WALLETの場所は、TCPSと互換性のあるWALLET_ROOT/server_sepsを指しています。

よくある質問:

質問: dbaascli grid configureTCPSコマンドの目的は何ですか。

A: dbaascli grid configureTCPSコマンドは、Oracle Base Database Cloud@Customer環境で既存のクラスタのTransport Layer Security (TCPS)を構成するために使用します。

Q: dbaascli grid configureTCPSコマンドを実行するための前提条件は何ですか。

A: このコマンドは、rootユーザーとして実行する必要があります。

Q: Oracle Base Database Cloud@Customerシステムでは、TCPSはデフォルトで有効になっていますか。

A: いいえ。TCPSは、Oracle Base Database Cloud@Customerシステムではデフォルトで有効になっていません。TCPSを有効にするには、特定のデータベースのsqlnet.oraファイルを更新し、データベースを再起動する必要があります。

Q: Oracle Base Database Cloud@CustomerシステムでTCPSを有効にした結果、どうなりますか。

A: Oracle Base Database Cloud@CustomerシステムでTCPSを有効にすると、Zero Data Loss Recovery Appliance (ZDLRA)接続が失敗します。ZDLRAまたはTCPS構成のいずれかのみを有効にできますが、両方を同時に有効にすることはできません。

質問: –pkcs12WalletFilePathオプションは何を指定していますか。

A: --pkcs12WalletFilePathオプションは、TCPS構成に使用されるPKCS12ウォレット形式で証明書ファイルへの絶対パスを指定します。

質問: –caCertChainオプションは何に使用されますか。

A: --caCertChainオプションは、中間CA証明書とルートCA証明書を含む証明書の連結されたリストを指定します。

質問: –precheckOnlyオプションは何を行いますか。

A: --precheckOnlyオプションは、TCPS構成操作の事前チェックのみを実行するかどうかを指定します。使用できる値は、yesまたはnoです。

質問: –serverCertオプションは何を指定していますか。

A: --serverCertオプションは、TCPS構成に使用またはローテーションされる PEM証明書へのパスを指定します。

Q: TCPS構成の秘密キーはどのように指定しますか。

A: --privateKeyオプションを使用して、サーバー証明書に関連付けられた秘密キー・ファイルへのパスを指定します。

質問: –certTypeオプションの許容値は何ですか。

A: --certTypeオプションの許容値は次のとおりです。

SELF_SIGNED_CERT
CA_SIGNED_CERT
PKCS12_CERT

デフォルト値はSELF_SIGNED_CERTです。

Q: 秘密鍵のパスワードはデフォルトで保護されていますか?

A: はい。--privateKeyPasswordProtectedオプションはデフォルトでtrueに設定されており、秘密キーがパスワードで保護されていることを示します。秘密キーがパスワードで保護されていない場合は、これをfalseに設定できます。

質問: TCPSを構成する前に事前チェックを実行できますか。

A: はい。--precheckOnlyオプションを「はい」に設定することで、操作の事前チェックのみを実行できます。これは、変更を行う前に環境を検証するのに役立ちます。

Q: PKCS12ウォレット・ファイルに不正なパスを指定した場合はどうなりますか。

A: --pkcs12WalletFilePathに不正なパスが含まれている場合、コマンドは失敗し、TCPS構成は続行されません。

Q: 秘密鍵がパスワードで保護されている場合はどうすればよいですか?

A: 秘密キーがパスワードで保護されている場合は、--privateKeyPasswordProtectedオプションがtrue (デフォルト)に設定されていることを確認します。

Q: 独自のCA署名付き証明書をTCPS構成に指定できますか?

A: はい。--serverCertおよび--privateKeyオプションを使用して、--certTypeをCA_SIGNED_CERTに設定することで、独自のCA署名証明書を指定できます。

Q: 自己署名証明書を使用してTCPSを構成するコマンド例は何ですか。

A: 以下に例を示します。

dbaascli grid configureTCPS --serverCert /path/to/self_signed_cert.pem --privateKey /path/to/private_key.pem --certType SELF_SIGNED_CERT

Q: TCPS構成にPKCS12証明書を使用できますか。

A: はい。--pkcs12WalletFilePathオプションを指定し、--certTypeをPKCS12_CERTに設定することで、PKCS12証明書を使用できます。

Q: dbaascli grid configureTCPSコマンドを実行する前に、何を確認する必要がありますか。

A: 有効な証明書ファイルと秘密キー・ファイルがあり、rootユーザーとしてログインしていることを確認します。また、ZDLRAをTCPSと同時に実行できないため、ZDLRAを使用する場合の影響を理解してください。

例: dbaascli grid configureTCPS

自己署名証明書を使用してグリッドを構成するには:

dbaascli grid configureTCPS

CA署名証明書を使用してグリッドを構成するには:

dbaascli grid configureTCPS --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --private_key_password_protected false

dbaascli grid removeTCPSCert

Grid Infrastructureウォレットから既存のTCPS証明書を削除するには、dbaascli grid removeTCPSCertコマンドを使用します。

前提条件:

rootユーザーとしてコマンドを実行します。

構文:

dbaascli grid removeTCPSCert --subject <value>
 {
   --userCert | --trustedCert | --requestedCert
 }
 [--serialNumber <value>] [--executePrereqs] [--resume [--sessionID <value>]] [--bounceListeners]

パラメータ:

パラメータ	説明
`--subject`	証明書のサブジェクトを指定
`--userCert`	ユーザー証明書を示すフラグ
`--trustedCert`	信頼できる証明書を示すフラグ
`--requestedCert`	リクエストされた証明書を示すフラグ
`--serialNumber`	証明書のシリアル番号を指定します
`--executePrereqs`	前提条件チェックを実行し、結果を報告します
`--resume`	前回の実行を再開します
`--sessionID`	特定のセッションIDを再開するように指定します。
`--bounceListeners`	Grid Infrastructureリスナーおよびスキャン・リスナーをバウンスするフラグ

よくある質問:

質問: dbaascli grid removeTCPSCertコマンドの目的は何ですか。

A: dbaascli grid removeTCPSCertコマンドを使用して、Oracle Base Database Cloud@Customer環境のGrid Infrastructureウォレットから既存のTCPS証明書を削除します。

Q: dbaascli grid removeTCPSCertコマンドを実行するための前提条件は何ですか。

A: このコマンドは、rootユーザーとして実行する必要があります。

質問: dbaascli grid removeTCPSCertコマンドで–subjectオプションは何が指定されていますか。

A: --subjectオプションは、Grid Infrastructureウォレットから削除する証明書のサブジェクトを指定します。

質問: –userCertフラグの目的は何ですか。

A: --userCertフラグは、削除する証明書がユーザー証明書であることを示します。

質問: –trustedCertフラグはどのような場合に使用しますか。

A: Grid Infrastructureウォレットから信頼できる証明書を削除する場合は、--trustedCertフラグを使用します。

質問: –requestedCertフラグは何を行いますか。

A: --requestedCertフラグは、削除される証明書がリクエストされた証明書であることを示します。

質問: –serialNumberオプションは何を指定していますか。

A: --serialNumberオプションは、削除する証明書のシリアル番号を指定します。これは、同じサブジェクトを持つ証明書が複数ある場合に、証明書を一意に識別するのに役立ちます。

質問: –executePrereqsオプションの目的は何ですか。

A: --executePrereqsオプションは、証明書を削除する前に前提条件チェックを実行し、結果をレポートして、環境が操作に対して適切に準備されていることを確認します。

Q: –resumeオプションは何を行いますか。

A: 以前に中断されていた場合、--resumeオプションは削除操作を再開します。

Q: 中断された操作を再開するときにセッションIDを指定するにはどうすればよいですか。

A: --sessionIDオプションを使用して、再開する中断された操作のセッションIDを指定します。

質問: –bounceListenersフラグは何を行いますか。

A: --bounceListenersフラグは、TCPS証明書の削除後にGrid Infrastructureリスナーおよびスキャン・リスナーを再起動するために使用されます。

Q: リスナーをバウンスせずにTCPS証明書を削除することはできますか?

A: はい、--bounceListenersフラグはオプションです。指定しない場合、リスナーは自動的にバウンスされません。

Q: 私はいかに操作を安全に動かすことを保障してもいいですか。

A: --executePrereqsオプションを使用すると、コマンドを実行する前に前提条件チェックを実行でき、削除処理の前にすべてが順番に動作していることを確認できます。

Q: シリアル番号で特定のユーザー証明書を削除する必要がある場合はどうすればよいですか?

A: --subjectオプションを使用して証明書のサブジェクトを指定し、--userCertフラグを使用して証明書がユーザー証明書であることを示し、--serialNumberオプションを使用して証明書のシリアル番号を指定します。

Q: 一度に複数の証明書を削除することはできますか?

A: いいえ、このコマンドは、指定されたサブジェクトおよびその他のパラメータに基づいて、一度に単一の証明書を削除するように設計されています。

Q: 証明書の削除プロセスが中断されるとどうなりますか?

A: 中断されたプロセスの--sessionIDとともに--resumeオプションを使用して操作を再開できます。

質問: rootユーザーとしてコマンドを実行する必要がありますか。

A: はい。TCPS証明書を削除するために必要な権限を取得するには、dbaascli grid removeTCPSCertコマンドをrootユーザーとして実行する必要があります。

Q: 削除する証明書はどのようにして識別できますか?

A: 証明書をサブジェクトで識別し、オプションでシリアル番号で識別して、削除する正しい証明書をターゲットにしていることを確認できます。

Q: 信頼できる証明書を削除するコマンドの例を教えてください。

A: 以下に例を示します。

dbaascli grid removeTCPSCert --subject "CN=example_cert" --trustedCert

dbaascli grid rotateTCPSCert

TCPS証明書をローテーションするには、dbaascli grid rotateTCPSCertコマンドを使用します。

前提条件:

rootユーザーとしてコマンドを実行します。

構文:

dbaascli grid rotateTCPSCert
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]

パラメータ:

パラメータ	説明
`--pkcs12WalletFilePath`	証明書ファイルの絶対パス(`pkcs12`ウォレット形式)を指定します
`--caCertChain`	中間CAおよびルートCA証明書を含む証明書の連結リストです
`--precheckOnly`	`yes`は、1を指定するとこの操作の事前チェックのみが実行されます。有効な値: `yes`または`no`。
`--serverCert`	TCPS構成で使用またはローテーションするPEM証明書のパスを指定します。
`--privateKey`	証明書の秘密キー・ファイルのパスを指定します。
`--certType`	Grid Infrastructureウォレットに追加される証明書のタイプです。許容される値は、`SELF_SIGNED_CERT`、`CA_SIGNED_CERT`または`PKCS12_CERT`です。デフォルト: `SELF_SIGNED_CERT`
`--privateKeyPasswordProtected`	秘密キーがパスワードで保護されるかどうかを指定します。有効な値: `true`または`false` デフォルト: `true`。

よくある質問:

質問: dbaascli grid rotateTCPSCertコマンドの目的は何ですか。

A: dbaascli grid rotateTCPSCertコマンドを使用して、Oracle Base Database Cloud@Customer環境のGrid InfrastructureウォレットでTCPS (Transport Layer Security Protocol)証明書をローテーションします。

Q: dbaascli grid rotateTCPSCertコマンドを実行するための前提条件は何ですか。

A: このコマンドは、rootユーザーとして実行する必要があります。

質問: –pkcs12WalletFilePathオプションは何を指定していますか。

A: --pkcs12WalletFilePathオプションは、TCPS構成のPKCS12ウォレット形式で証明書ファイルへの絶対パスを指定します。

質問: –caCertChainオプションの目的は何ですか。

A: --caCertChainオプションは、TCPS構成用に、中間CA証明書とルートCA証明書を含む証明書の連結されたリストを指定します。

質問: –precheckOnlyオプションは何を行いますか。

A: --precheckOnlyオプションを使用すると、実際の変更を行わずに事前チェックを実行できます。有効な値は、事前チェックのみを実行する場合は"yes"、ローテーションを続行する場合は"no"です。

質問: –serverCertオプションはどのように使用されますか。

A: --serverCertオプションは、TCPS構成に使用またはローテーションされる PEM (Privacy Enhanced Mail)サーバー証明書へのパスを指定します。

質問: –privateKeyオプションは何を指定していますか。

A: --privateKeyオプションは、TCPSのローテーションに使用されるサーバー証明書に対応する秘密キー・ファイルへのパスを指定します。

質問: –certTypeオプションの有効な値は何ですか。

A: --certTypeオプションは、Grid Infrastructureウォレットに追加する証明書のタイプを指定するために、次の値を受け入れます。

SELF_SIGNED_CERT (デフォルト)
CA_SIGNED_CERT
PKCS12_CERT

質問: –privateKeyPasswordProtectedオプションは何を行いますか。

A: --privateKeyPasswordProtectedオプションは、秘密キーがパスワードで保護されているかどうかを示します。有効な値は、true (デフォルト)およびfalseです

質問: 証明書をローテーションせずにdbaascli grid rotateTCPSCertコマンドを実行できますか。

A: はい。--precheckOnly yesオプションを使用すると、証明書をローテーションせずに事前チェックのみを実行できます。

Q: PKCS12ウォレットを使用して証明書をローテーションするコマンドの例は何ですか。

A: コマンドの例を次に示します。

dbaascli grid rotateTCPSCert --pkcs12WalletFilePath /path/to/wallet.p12 --certType PKCS12_CERT

Q: CA署名証明書チェーンを使用してサーバー証明書をローテーションするにはどうすればよいですか。

A: 次に示すように、--serverCertおよび--caCertChainオプションを使用します。

dbaascli grid rotateTCPSCert --serverCert /path/to/serverCert.pem --caCertChain /path/to/caChain.pem

Q: –privateKeyPasswordProtectedを指定しないとどうなりますか。

A: --privateKeyPasswordProtectedオプションを指定しない場合、このコマンドは秘密キーがパスワードで保護されていると想定します(デフォルト: true)。

Q: 自己署名証明書をローテーションできますか?

A: はい。デフォルトの--certType SELF_SIGNED_CERTオプションを使用するか、明示的に指定することで、自己署名証明書をローテーションできます。

Q: 秘密鍵を提供せずに証明書をローテーションするにはどうすればよいですか?

A: 特定の証明書タイプ(PKCS12など)では、ウォレットに含まれているため、個別の秘密キー・ファイルを指定する必要がない場合があります。ただし、秘密鍵が必要な場合は、--privateKeyオプションを使用して指定する必要があります。

Q: バックグラウンドで証明書をローテーションする場合はどうなりますか?

A: dbaascli grid rotateTCPSCertコマンドは、バックグラウンド実行のための明示的なオプションを提供しません。このコマンドは、バックグラウンド・セッションで直接実行できます(たとえば、nohupまたは同様のツールを使用します)。

質問: 指定しない場合、デフォルトの証明書タイプは何ですか。

A: デフォルトの証明書タイプはSELF_SIGNED_CERTです。

例: dbaascli grid rotateTCPSCert

自己署名証明書を使用して証明書をローテーションするには(デフォルト・オプション):

dbaascli grid rotateTCPSCert

CA署名証明書を使用して証明書をローテーションするには:

dbaascli grid rotateTCPSCert --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --privateKeyPasswordProtected true

dbaascli grid upgrade

Oracle Grid Infrastructureをあるメジャー・バージョンから別のメジャー・バージョンにアップグレードするには、dbaascli grid upgradeコマンドを使用します。

前提条件:

rootユーザーとしてコマンドを実行します。

構文:

dbaascli grid upgrade --version
[--resume]
[--executePrereqs]
[--containerURL]
[--softwareOnly]
[--targetHome]
[--revert]

パラメータ:

パラメータ	説明
`--version`	ターゲット・バージョンを指定します
`--resume`	前回の実行を再開します
`--executePrereqs`	Grid Infrastructureアップグレードの前提条件を実行する
`--containerUrl`	Grid InfrastructureイメージをフェッチするためのカスタムURLを指定します
`--softwareOnly`	Grid Infrastructureソフトウェアのみをインストールします。
`--targetHome`	既存のターゲットGridホームのパスを指定します
`--revert`	失敗した実行を元に戻す

よくある質問:

質問: dbaascli grid upgradeコマンドの目的は何ですか。

A: dbaascli grid upgradeコマンドは、Oracle Base Database Cloud@Customer仮想マシン上のOracle Grid Infrastructureをあるメジャー・バージョンから別のメジャー・バージョンにアップグレードするために使用します。

Q: dbaascli grid upgradeコマンドを実行するための前提条件は何ですか。

A: このコマンドは、rootユーザーとして実行する必要があり、Oracle Base Database Cloud@Customer仮想マシンに接続する必要があります。

Q: –versionオプションは何を指定していますか。

A: --versionオプションは、アップグレード先のOracle Grid Infrastructureのターゲット・バージョンを指定します。

Q: –resumeオプションは何を行いますか。

A: --resumeオプションは、以前に中断または失敗した Grid Infrastructureアップグレードプロセスを再開します。

質問: –executePrereqsオプションはどのように使用されますか。

A: --executePrereqsオプションは、実際のアップグレードを実行せずに、Grid Infrastructureのアップグレードの前提条件チェックのみを実行します。

質問: –containerURLオプションの目的は何ですか。

A: --containerURLオプションは、アップグレードのためにGrid Infrastructureソフトウェア・イメージをフェッチするためのカスタムURLを指定します。

質問: –softwareOnlyオプションは何を行いますか。

A: --softwareOnlyオプションは、Grid環境を構成またはアップグレードせずに、Grid Infrastructureソフトウェアのみをインストールします。

質問: –targetHomeオプションはいつ使用しますか。

A: --targetHomeオプションは、アップグレードが実行される既存のターゲットGridホームへのパスを指定します。

Q: アップグレードが失敗した場合はどうなりますか。

A: アップグレードが失敗した場合は、--revertオプションを使用して、アップグレードを前の状態にロールバックできます。

Q: Grid Infrastructureのアップグレードを段階的に実行できますか?

A: はい。--softwareOnlyオプションを使用することで、まずソフトウェアをインストールしてから完全アップグレードを完了し、段階的なアップグレードが可能です。

Q: dbaascli grid upgradeコマンドを使用してソフトウェアのみアップグレードするには、どのようにするのですか。

A: ソフトウェアのみをアップグレードするには、次の構文を使用します。

dbaascli grid upgrade --version <target_version> --softwareOnly

Q: アップグレードを実行せずに、アップグレードの前提条件をチェックできますか。

A: はい、次のものを使用して前提条件チェックのみを実行できます。

dbaascli grid upgrade --version <target_version> --executePrereqs

Q: カスタムコンテナURLを使用して Grid Infrastructureをアップグレードする方法は?

A: Grid InfrastructureイメージをフェッチするためのURLは、次のように指定できます。

dbaascli grid upgrade --version <target_version> --containerURL <custom_url>

Q: 以前に中断したアップグレードプロセスを再開するにはどうすればよいですか?

A: 以前に中断または失敗したアップグレードを再開するには、次を使用します。

dbaascli grid upgrade --version <target_version> --resume

Q: dbaascli grid upgradeコマンドで–revertオプションは何をしますか。

A: --revertオプションは、失敗した、または中断された Grid Infrastructureのアップグレードを元の状態にロールバックします。

Q: Grid Infrastructureをすぐに構成せずに完全アップグレードを実行できますか。

A: はい、最初に --softwareOnlyオプションを使用してソフトウェアのみをインストールしてから、あとで構成できます。

Q: アップグレードが失敗し、変更を元に戻すにはどうすればよいですか。

A: --revertオプションを使用して、失敗したアップグレードをロールバックします。

dbaascli grid upgrade --version <target_version> --revert

例: dbaascli grid upgrade

dbaascli grid upgrade --version 19.11.0.0.0 --executePrereqs
DBAAS CLI version MAIN
Executing command grid upgrade --version 19.11.0.0.0 --executePrereqs

dbaascli grid patch

指定したマイナー・バージョンになるようにOracle Grid Infrastructureにパッチを適用するには、dbaascli grid patchコマンドを使用します。

前提条件:

rootユーザーとしてコマンドを実行します。

構文:

dbaascli grid patch
 {
            --targetVersion <value>
            | --targetHome <value>
        }
        [--executePrereqs] [--nodeList <value>] [--continueWithDbDowntime] [--drainTimeoutInSeconds <value>] [--containerURL <value>] [--imageFile <value>] [--patchInParallel]
        {
            [--resume [--sessionID <value>]]
            | [--rollback [--sessionID <value>]]
        }
        [--waitForCompletion <value>]

パラメータ:

パラメータ	説明
`--targetVersion`	ピリオドで区切られた5つの数値セグメントとして指定されたOracleホームのターゲット・バージョンを指定します(例: 19.12.0.0.0)
`--targetHome`	アウトオブプレース・パッチ適用のためのターゲットGrid Infrastructureホームの完全修飾パスを指定します。
`--containerURL`	Grid InfrastructureイメージをフェッチするためのカスタムURLを指定します
`--executePrereqs`	prereqsを実行するオプション
`--nodeList`	ノードのサブセットでパッチ適用を実行する必要がある場合に、ノードのカンマ区切りリストを指定します
`--patchInParallel`	リモート・ノードへのパッチ適用をパラレルに実行することを指定します。
`--rollback`	パッチ適用済のOracleホームをロールバックすることを指定します
`--resume`	前回の実行を再開します
`--sessionID`	特定のセッションIDを再開するように指定します。
`--continueWithDbDowntime`	データベースの停止時間を使用してパッチ適用を続行します。このオプションは、アクティブ・インスタンスが1つのみ稼働し、停止時間でもパッチ適用操作を続行できる環境で使用できます。
`--drainTimeoutInSeconds`	データベースの停止中に、リソースの排出を完了する時間を秒単位で指定します。
`--createImage`	アクティブなGridホームのコピーから、指定したターゲット・バージョンにパッチを適用してイメージを作成する
`--createImageDir`	イメージを作成するディレクトリの完全修飾パスを指定します
`--imageFile`	使用するイメージの完全修飾パスを指定します
`--patchInParallel`	リモート・ノードへのパッチ適用をパラレルに実行
`--waitForCompletion`	`false`は、バックグラウンドで操作を実行するように指定します。有効な値: `true`または`false`

よくある質問:

質問: dbaascli grid patchコマンドは何をしますか。

A: dbaascli grid patchコマンドを使用して、指定したマイナー・バージョンにOracle Grid Infrastructureにパッチを適用します。

質問: dbaascli grid patchコマンドを実行するには、特別な権限が必要ですか。

A: はい、rootユーザーとしてdbaascli grid patchコマンドを実行する必要があります。

Q: Oracle Grid Infrastructureにパッチを適用するときにターゲット・バージョンを指定できますか。

A: はい、--targetVersionオプションを使用してターゲット・バージョンを指定できます。

質問: パッチのターゲット・バージョンはどのように指定するのですか。

A: --targetVersionオプションとそれに続くバージョン番号を19.12.0.0.0の形式で使用します。

質問: dbaascli grid patchコマンドで–containerURLオプションは何を行いますか。

A: --containerURLオプションを使用すると、Grid InfrastructureイメージをフェッチするためのカスタムURLを指定できます。

質問: –executePrereqsオプションの目的は何ですか。

A: --executePrereqsオプションは、パッチを適用する前に前提条件チェックを実行するために使用します。

Q: dbaascli grid patchコマンドを使用してノードのサブセットにパッチを適用するにはどうすればよいですか。

A: --nodeListオプションに続けて、ノード名のカンマ区切りリストを指定して、ノードのサブセットにのみパッチを適用します。

質問: –rollbackオプションを使用するとどうなりますか。

A: --rollbackオプションは、パッチが適用されたOracleホームを以前の状態にロールバックします。

Q: 以前のパッチ適用セッションを再開できますか。

A: はい。--resumeオプションを使用して、最後のパッチ適用セッションを再開できます。特定のセッションIDがある場合は、--sessionIDオプションで指定できます。

質問: –continueWithDbDowntimeオプションは何に使用されますか。

A: --continueWithDbDowntimeオプションを使用すると、データベースの停止時間がある場合でもパッチ適用を続行できます。通常は、アクティブなインスタンスが1つしかない環境で使用されます。

Q: パッチを適用したGridホームからイメージを作成するにはどうすればよいですか。

A: --createImageオプションを使用してイメージを作成します。--createImageDirオプションを使用して、イメージを作成するディレクトリを指定できます。

質問: –imageFileオプションの目的は何ですか。

A: --imageFileオプションを使用すると、パッチ適用に使用するイメージ・ファイルの完全修飾パスを指定できます。

Q: dbaascli grid patchコマンドをバックグラウンドで実行するにはどうすればよいですか。

A: falseに設定された--waitForCompletionオプションを使用して、操作をバックグラウンドで実行できます。

質問: パッチ・イメージをフェッチするためにカスタムURLを使用できますか。

A: はい。--containerURLオプションを使用して、Grid InfrastructureイメージをフェッチするためのカスタムURLを指定できます。

Q: すべてのノードにパッチを適用しない場合は、どのようにしてパッチを適用しますか。

A: --nodeListオプションを使用して、パッチを適用するノードをノード名のカンマ区切りリストで指定できます。

Q: パッチをロールバックする必要がある場合はどうすればよいですか。

A: dbaascli grid patchコマンドの--rollbackオプションを使用して、パッチをロールバックします。

Q: 環境にアクティブなインスタンスが1つしかなく、停止時間を継続する必要がある場合は、パッチ適用操作をどのように処理しますか。

A: --continueWithDbDowntimeオプションを使用して、データベースの停止時間でもパッチ適用を続行します。

Q: パッチが適用されたGridホームのイメージを作成できますか。

A: はい。--createImageオプションを使用して、パッチが適用されたGridホームのイメージを作成できます。必要に応じて、--createImageDirを使用してイメージを保存するディレクトリを指定します。

Q: 中断後にパッチ適用セッションを再開するにはどうすればよいですか。

A: --resumeオプションを使用して、パッチ適用セッションを再開します。セッションIDがわかっている場合は、--sessionIDで指定できます。

質問: パッチ適用プロセスが途中で失敗した場合はどうなりますか。

A: パッチ適用プロセスが失敗した場合は、--resumeオプションを使用してプロセスを再起動できます。--rollbackオプションを使用して、前の状態に戻すこともできます。

Q: パッチ適用前にすべての前提条件が満たされていることを確認するにはどうすればよいですか。

A: --executePrereqsオプションを使用して、パッチを適用する前にすべての前提条件チェックを実行します。

Q: ターミナルを中断しないように、バックグラウンドでパッチ適用を実行できますか。

A: はい、--waitForCompletion falseオプションを使用して、パッチ適用プロセスをバックグラウンドで実行できます。

Q: パッチ適用後にGridホーム・イメージを作成するにはどうすればよいですか。

A: パッチが適用されたGridホームから新しいイメージを作成するには、--createImageオプションを使用します。必要に応じて、--createImageDirを使用してディレクトリを指定します。

質問: パッチ適用に既存のイメージ・ファイルを使用するには、どうすればいいですか。

A: --imageFileオプションを使用して、パッチ適用に使用するイメージ・ファイルへの完全修飾パスを指定できます。

Q: パッチ適用中のデータベースの停止時間を回避するにはどうすればよいですか。

A: 環境に複数のアクティブ・インスタンスが実行されていることを確認します。アクティブ・インスタンスが1つのみの環境を対象とした--continueWithDbDowntimeオプションの使用を回避できます。

Q: バックグラウンドで実行されているパッチの進行状況を確認するにはどうすればよいですか。

A: --waitForCompletion falseでパッチを実行する場合、psなどのオペレーティング・システム・コマンドを使用してバックグラウンド・ジョブのステータスをチェックするか、Gridホームにあるログをチェックできます。

Q: dbaascli grid patchを使用してより高いメジャー・バージョンにパッチを適用することは可能ですか。

A: いいえ。dbaascli grid patchでは、現在のメジャー・バージョンのマイナー・バージョンへのパッチ適用のみが許可されます。メジャー・アップグレードの場合は、別のアップグレード・プロセスに従う必要があります。

Q: パッチ適用中に特定の前提条件チェックをスキップできますか。

A: いいえ、--executePrereqsを使用すると、すべての前提条件チェックが実行されます。ただし、前提条件チェックの結果を確認し、続行する前に問題を手動で処理できます。

Q: パッチ適用プロセスがスタックまたはハングした場合、どうすればよいですか。

A: パッチ適用プロセスが応答しない場合は、オペレーティング・システムのコマンドを使用して停止してから、--resumeオプションを使用して再開できます。これが機能しない場合は、--rollbackオプションを使用してパッチを元に戻してください。

Q: 複数のクラスタ間でパッチ適用プロセスを自動化できますか。

A: はい。適切なオプションを指定してdbaascli grid patchコマンドを含むスクリプトを使用すると、異なるクラスタ間でパッチ適用を自動化できます。

Q: パッチ適用プロセスのログはどこにありますか。

A: ログは通常、Oracle Gridホームのログ・ディレクトリまたは設定時に指定されたデフォルトの場所にあります。パッチ適用プロセスの詳細は、これらのログをモニターできます。

Q: ユーザー操作なしでサイレント・パッチ・プロセスを作成することはできますか。

A: はい。コマンドで必要なすべてのオプションを指定し、バックグラウンド(--waitForCompletion false)で実行することで、非対話型のパッチ適用プロセスを作成できます。

質問: パッチを適用する前に、使用可能なパッチ更新を確認できますか。

A: dbaascli grid patchコマンド自体には、使用可能なパッチをリストするオプションはありません。ただし、Oracle SupportなどのOracleの標準メソッドを使用して、最新のパッチを識別できます。

Q: dbaascliを使用して複数のOracle Homesにパッチを適用できますか。

A: いいえ、dbaascli grid patchコマンドは、特定のOracle Grid Infrastructureホームに一度にパッチを適用するように設計されています。このコマンドは、ホームごとに個別に実行する必要があります。

Q: Grid Infrastructureにパッチを適用するときに停止時間を完全に防ぐ方法はありますか。

A: 停止時間を最小限に抑えるには、ノードごとにパッチを適用できるように、環境に複数のアクティブなデータベース・インスタンス(RAC構成)があることを確認します。この場合、--continueWithDbDowntimeオプションは使用しないでください。

Q: RAC One Node環境のパッチ適用はどのようにして処理するのですか。

A: RAC One Node環境では、アクティブ・インスタンスが1つのみ存在する場合があるため、--continueWithDbDowntimeオプションには注意する必要があります。RAC One Nodeの具体的なパッチ適用ガイドラインについては、Oracleのドキュメントを参照してください。

質問: 以前のパッチのセッション履歴を参照できますか。

A: dbaascliユーティリティは、セッション履歴を直接表示する方法を提供しません。ただし、以前のパッチ適用セッションのログは、Gridホームのlogsディレクトリにあります。

例:

例: 基本的なグリッド・パッチ適用

dbaascli grid patch --targetVersion 19.12.0.0.0

Oracle Grid Infrastructureにバージョン19.12.0.0.0のパッチを適用します。

例: カスタム・コンテナURLを使用したパッチ適用

dbaascli grid patch --targetVersion 19.12.0.0.0 --containerURL https://example.com/custom/url

カスタム・コンテナURLを使用してGrid Infrastructureイメージをフェッチし、Grid Infrastructureをバージョン19.12.0.0.0にパッチを適用します。

例: 前提条件チェックを使用したパッチ適用

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs

前提条件チェックを実行した後、Grid Infrastructureにバージョン19.12.0.0.0をパッチします。

例: ノードのサブセットへのパッチ適用

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node2,node3

指定されたノード(node1、node2およびnode3)でGrid Infrastructureをバージョン19.12.0.0.0にパッチを適用します。

例: パッチをロールバックする

dbaascli grid patch --rollback

Oracle Grid Infrastructureで最後に適用されたパッチをロールバックします。

例: 以前のパッチ操作の再開

dbaascli grid patch --resume

停止した場所から以前のパッチ適用操作を再開します。

例: 特定のセッションIDによるパッチ操作の再開

dbaascli grid patch --resume --sessionID 12345

セッションID 12345を使用してパッチ適用操作を再開します。

例: データベース・ダウンタイムを使用したパッチ適用の許可

dbaascli grid patch --targetVersion 19.12.0.0.0 --continueWithDbDowntime

必要に応じてデータベースのダウンタイムを許可しながら、Grid Infrastructureにバージョン19.12.0.0.0をパッチ適用します。

例: パッチを適用したイメージの作成

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /path/to/dir

パッチを適用したGridホーム(バージョン19.12.0.0.0)のイメージを作成し、指定したディレクトリに格納します。

例: 既存のイメージ・ファイルの使用

dbaascli grid patch --targetVersion 19.12.0.0.0 --imageFile /path/to/image/file.zip

/path/to/image/file.zipにある既存のイメージファイルを使用して、Grid Infrastructureにバージョン19.12.0.0.0をパッチします。

例: バックグラウンドでのパッチ適用操作の実行

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion false

Grid Infrastructureにバージョン19.12.0.0.0をパッチ適用し、バックグラウンドで操作を実行します。

例: ノードの前提条件、カスタムURLおよびサブセットの組合せ

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs --containerURL https://example.com/custom/url --nodeList node1,node2

Grid Infrastructureをバージョン19.12.0.0.0にパッチ適用し、前提条件チェックを実行し、イメージのカスタムURLを使用し、パッチを node1および node2にのみ適用します。

例: 既存のイメージ・ファイルを使用したパッチ適用済イメージの作成

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /path/to/dir --imageFile /path/to/existing/image.zip

パッチを適用したイメージを作成し、パッチの既存のイメージ・ファイルを使用しているときに、指定されたディレクトリに格納します。

例: パッチ適用を行わない前提条件の確認

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs

パッチを実際に適用せずに、バージョン19.12.0.0.0にパッチを適用するためのすべての前提条件が満たされているかどうかを確認します。

例: パッチの実行および前提条件の失敗の無視

dbaascli grid patch --targetVersion 19.12.0.0.0 --continueWithDbDowntime --executePrereqs

前提条件チェックが失敗した場合でもパッチを実行します。これは、停止時間が許容され、特定の前提条件を無視できるシナリオで役立ちます。

例: パッチ・ログでの問題のチェック

tail -f /u01/app/grid/logs/grid_patch.log

パッチ適用プロセス中に問題を診断するために、パッチ・ログをリアルタイムでモニターします。

例: パラレル環境でのパッチの適用

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node2 --waitForCompletion false

ノードのサブセット(node1およびnode2)でGrid Infrastructureにパッチを適用し、バックグラウンドでプロセスを実行します。

例: 外部ソースからの特定のイメージ・ファイルの使用

dbaascli grid patch --targetVersion 19.12.0.0.0 --imageFile /mnt/images/grid_patch_19.12.zip

外部ストレージ・デバイスにある事前ダウンロード済のイメージ・ファイルを使用して、Grid Infrastructureにパッチを適用します。

例: カスタム・セッションIDを使用したパッチの実行

dbaascli grid patch --targetVersion 19.12.0.0.0 --resume --sessionID 67890

セッションID 67890を使用して、中断されたパッチ適用操作を再開します。

例: 後で実行するためのパッチ適用のスケジュール

echo "dbaascli grid patch --targetVersion 19.12.0.0.0" | at 02:00

Linuxのatコマンドを使用して、午前2時に実行するようにパッチ適用コマンドをスケジュールします。

例: 完了のタイムアウトの指定

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion true --continueWithDbDowntime --timeout 7200

ダウンタイムを許可しながらGrid Infrastructureにパッチを適用しますが、タイムアウトまでに最大7200秒(2時間)完了するまで待機します。

例: 別の環境のカスタム・イメージの作成

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /backups/images/grid_patch

パッチが適用されたGrid Infrastructureのカスタム・イメージを作成し、他の環境で使用するために/backups/images/grid_patchディレクトリに格納します。

例: 中断後のパッチのリカバリ

dbaascli grid patch --resume --continueWithDbDowntime

データベースの停止時間が許可された状態で、パッチ適用プロセスが中断された場合はリカバリして再開します。

例: 前提条件チェックとバックグラウンド実行の結合

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs --waitForCompletion false

前提条件を確認し、パッチをバックグラウンドで実行します。

例: より高速なパッチ適用のためのイメージ作成のスキップ

dbaascli grid patch --targetVersion 19.12.0.0.0 --patchInParallel --continueWithDbDowntime --waitForCompletion false

Grid Infrastructureをバージョン19.12.0.0.0にノード間でパラレルにパッチを適用し、データベースのダウンタイムを許容し、処理を高速化するイメージを作成せずにパッチを適用します。

例: ログを介したパッチの進捗の監視

tail -f /u01/app/grid/logs/grid_patch_progress.log

パッチ適用の進行状況のログ・ファイルをリアルタイムで監視し、パッチ適用プロセスの各ステップに関するインサイトを提供します。

例: カスタム・ドレイン・タイムアウトを使用したパッチ適用

dbaascli grid patch --targetVersion 19.12.0.0.0 --drainTimeoutInSeconds 3600 --continueWithDbDowntime

Grid Infrastructureにパッチを適用し、カスタムのタイムアウトを1時間(3600秒)に設定して、データベースのダウンタイム中にリソースを正常に排出できるようにします。

例: 前提条件チェックを使用した特定のノードへのパッチの適用

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node4 --executePrereqs

ノードnode1およびnode4のみをバージョン19.12.0.0.0にパッチを適用し、前提条件チェックを事前に実行します。

例: 完了を待機しないパッチ適用

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion false

バックグラウンドでGrid Infrastructureのバージョン19.12.0.0.0へのパッチ適用を開始し、プロセスの完了を待たずに他のタスクを実行できるようにします。

例: ドレイン・タイムアウトの問題後の失敗したパッチの再適用

dbaascli grid patch --resume --drainTimeoutInSeconds 7200

前のパッチ適用セッションを再開し、リソース・ドレイン・タイムアウトを2時間(7200秒)まで延長します。これは、前の試行の時間が不足しているために失敗した場合です。

例: 特定のセッションIDを使用したリアルタイムでのパッチ・ログの表示

tail -f /u01/app/grid/logs/grid_patch_12345.log

セッションIDが12345のパッチ適用セッションのログ・ファイルをリアルタイムでモニターします。

例: 新しいターゲット・ホームへのパッチ適用

dbaascli grid patch --targetHome /u01/app/grid_home_19c --executePrereqs

前提条件チェックを使用して、/u01/app/grid_home_19cにある新しいOracle Gridホームへのアウトオブプレース・パッチを実行します。

例: バックグラウンド・パッチ・ジョブの停止

ps -ef | grep dbaascli | grep patch | awk '{print $2}' | xargs kill -9

関連付けられたプロセスID (PID)を検索して停止することで、バックグラウンド・パッチ・ジョブを停止します。

例: ログのないパッチ完了の確認

dbaascli grid status --targetVersion 19.12.0.0.0

現在のGrid Infrastructureバージョン・ステータスを確認することで、バージョン19.12.0.0.0へのパッチが正常に適用されたかどうかを確認します。