8 Exadataソフトウェアの更新

Oracle Exadataでは、定期的な更新が必要になる各種のソフトウェアが使用されています。

• Exadataソフトウェアの更新について
  
• ソフトウェア・メンテナンスの計画
  ソフトウェア更新を開始する前に、ベスト・プラクティスを確認し、アップグレードするバージョンを決定し、適切なパッチ適用ソフトウェアを入手する必要があります。
• Exadataソフトウェア更新の実行の概要
  Exadataコンポーネントのソフトウェア更新ごとに、そのソフトウェア更新を完了するために様々なアクションが必要になります。
• Exadata Patchmgr更新ユーティリティ
  Patchmgrは、Exadataインフラストラクチャ・コンポーネントのソフトウェアの更新に使用されるユーティリティです。
• Oracle Exadataデータベース・サーバーの更新
  次の情報と手順を使用して、Oracle Exadataのデータベース・サーバーを更新します。
• Oracle Exadata Storage Serverのソフトウェアの更新
  次の情報と手順を使用して、Oracle Exadataのストレージ・サーバーを更新します。
• RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードおよびダウングレード
  このトピックでは、RoCEネットワーク・ファブリック・スイッチのファームウェアをアップグレードおよびダウングレードする手順について説明します。
• InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアの更新
  このトピックでは、InfiniBandネットワーク・ファブリック・スイッチのファームウェアをアップグレードおよびダウングレードする手順について説明します。
• Oracle LinuxでのOracle Java SEのアップグレード
  データベース・サーバーおよびストレージ・サーバーでOracle Linux を実行しているOracle Java SE (JDK)をアップグレードできます。
• SSH等価の設定
  Oracle Exadata Database Machine上でソフトウェアを更新する前に、SSH等価を構成する必要があります。
• Oracle Exadataでのソフトウェア更新のトラブルシューティング
  Oracle Exadataでソフトウェアの更新時にエラーまたは問題が発生した場合に、次のトピックを確認します

8.1 Exadataソフトウェアの更新について

Exadataソフトウェア更新は、次の3つの主要コンポーネントに適用されます。

• Exadataストレージ・サーバー
• Exadataデータベース・サーバー
• Exadata RDMAネットワーク・ファブリックのスイッチ

Exadataストレージ・サーバーおよびExadataデータベース・サーバーの更新には、一般的に、次のものに対する更新が含まれています。

• Oracle Linuxオペレーティング・システム
• Oracle Exadata System Software
• ファームウェア(たとえば、ディスク、フラッシュ、RAIDコントローラ、ILOM、HCA)

更新は、Oracle Grid Infrastructureホーム、Oracle Databaseホーム(dbnodeupdate.sh -cステップの再リンク以外)または顧客がインストールしたソフトウェアの変更は行いません。

一般的に、コンポーネントは推奨される最小リリースと揃えることをお薦めしますが、コンポーネントごとに別々に更新することもできます。たとえば、RDMAネットワーク・ファブリックスイッチをExadataストレージ・サーバーおよびExadataデータベース・サーバーよりも後に更新できます。ただし、My Oracle Support Doc ID 888828.1を参照して、依存性がないかどうかを確認する必要があります。

リリースされるすべてのOracle Exadata System Software更新を個別に適用することが必要になるわけではありません。たとえば、リリースを2つか3つスキップして、より新しいリリースに直接更新できます。データベース・サーバーは年に2回更新することをお薦めします。

アップグレードは、次の場合に.許可されます。

1. ターゲット・リリースの製品バージョンがインストール済ソフトウェアよりも大きく、かつ
2. ターゲット・リリースの日付コードはインストール済ソフトウェアよりも大きいです。

たとえば、製品バージョン12.1.1.1.2と日付コード150411で構成されるイメージ・バージョン12.1.1.1.2.150411を現在実行しているシステムがあるとします。

• 12.1.2.1.2.150617.1へのアップグレードは、両方のルールが満たされているため、許可されます。
• 12.1.2.1.1.150316.2へのアップグレードは、インストール済ソフトウェアの日付コード150411がターゲット・リリースの日付コード150316よりも大きいため、許可されません。

• Exadataサーバー上のOracle Linux 8へのアップグレードについて
  Oracle Exadata System Softwareリリース23.1.0にアップグレードすると、Oracle Linuxバージョンは、Unbreakable Enterprise Kernel (UEK) 6を持つOracle Linux 8にアップグレードされます。
• Exadataサーバー上のOracle Linux 7へのアップグレードについて
  Oracle Exadata System Softwareリリース19.1.0にアップグレードすると、Oracle LinuxバージョンはOracle Linux 6からOracle Linux 7にアップグレードされます。

8.1.1 Exadataサーバー上のOracle Linux 8へのアップグレードについて

Oracle Exadata System Softwareリリース23.1.0にアップグレードすると、Oracle Linuxバージョンは、Unbreakable Enterprise Kernel (UEK) 6を持つOracle Linux 8にアップグレードされます。

Oracle Exadata X10Mモデルで導入されたAMDプロセッサ・アーキテクチャをサポートするには、Unbreakable Enterprise Kernel (UEK) 6が必要です。

8.1.2 Exadataサーバー上のOracle Linux 7へのアップグレードについて

Oracle Exadata System Softwareリリース19.1.0にアップグレードすると、Oracle LinuxバージョンはOracle Linux 6からOracle Linux 7にアップグレードされます。

Oracle Exadata System Softwareリリース19.1.0は、Oracle Linux 7で実行されるOracle Database 19cをサポートします。Oracle Exadata System Softwareリリース19.1.0にアップグレードすると、オペレーティング・システムが同時にアップグレードされます。

Exadata Database Machineでquorumディスクを使用する場合、My Oracle Supportノート2453054.1を参照してください。

8.2 ソフトウェア・メンテナンスの計画

ソフトウェア更新を開始する前に、ベスト・プラクティスを確認し、アップグレードするバージョンを決定し、適切なパッチ適用ソフトウェアを入手する必要があります。

• Exadata Database Machineソフトウェアおよび更新の理解
  Exadata Database Machineに必要な各種のソフトウェア更新についての理解は、更新スケジュールの計画を立てる際に役立ちます。
• ソフトウェア・メンテナンスの構成および操作のベスト・プラクティス
  ソフトウェア更新の計画の一環として、更新を実行する様々な方法、およびソフトウェアを更新するためのベスト・プラクティスを確認する必要があります。
• Exadataソフトウェア・イメージ・バージョンの理解
  Exadataイメージ・バージョン番号には、製品バージョン、日付コードおよびビルド番号が含まれます。
• 新しいExadataバージョンへの更新のルール
  更新時には、インストール済リリースと対象リリースの両方の製品バージョンと日付コードについて考慮する必要があります。

8.2.1 Exadata Database Machineソフトウェアおよび更新の理解

Exadata Database Machineに必要な各種のソフトウェア更新についての理解は、更新スケジュールの計画を立てる際に役立ちます。

• Oracle Exadataで更新するソフトウェアについて
  Oracle Exadataで実行するソフトウェアは2つの主なカテゴリに分類できます。
• ソフトウェア・リリース・タイプ
  
• ソフトウェア・リリース可用性
  
• ソフトウェア更新頻度
  Exadataソフトウェアの定期的な更新を計画する必要があります。
• ソフトウェア更新ユーティリティ
  Oracle Exadataでソフトウェアを更新する場合、更新されるコンポーネントに応じて特定のユーティリティを使用します。

8.2.1.1 Oracle Exadataで更新するソフトウェアについて

Oracle Exadataで実行するソフトウェアは2つの主なカテゴリに分類できます。

• Oracle Exadata System Software

• Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

次の表は、Oracle Exadataで実行するソフトウェアの2つの主なカテゴリを説明しています。

ソフトウェア	インストールされているコンポーネント	ソフトウェアの内容	ソフトウェア・バージョンの例
Oracle Exadata System Software	Exadataストレージ・サーバー Exadataデータベース・サーバー Exadata RDMAネットワーク・ファブリックのスイッチ	Oracle Linuxオペレーティング・システム Oracle VM Server (Oracle VM構成のデータベース・サーバー上) Oracle Exadata System Software ファームウェア(たとえば: ディスク、フラッシュ、RAIDコントローラ、ILOM、HCA、RDMAネットワーク・ファブリック・スイッチ・ファームウェア)	ストレージ・サーバーおよびデータベース・サーバーのOracle Exadata System Software。 12.2.1.1.0 12.1.2.3.4 InfiniBandネットワーク・ファブリック・スイッチ・ファームウェア: 2.2.4-3 2.1.8-1 RoCEネットワーク・ファブリック・スイッチ・ファームウェア: 7.0(3)I7(6)
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	Exadataデータベース・サーバー	Oracle Gridインフラストラクチャ(Gridホーム) Oracle Database (Databaseホーム)	12.2.0.1.0 12.1.0.2.160117 11.2.0.4.161018

Oracle Exadataがデプロイされると、表に説明されているすべてのソフトウェアがインストールおよび構成され、Oracle Databaseのパフォーマンスと可用性が向上します。大規模なエンドツーエンド・テストによって、Oracle Exadataに付属するすべてのソフトウェア・コンポーネントは、シームレスに連携します。

My Oracle Support Doc ID 888828.1は、Oracle Exadataで実行するソフトウェアの情報のプライマリ・ソースです。次の情報が含まれます。

• 現在と以前のすべてのリリースのリスト
• 機能使用状況の最小要件
• Oracle Exadata System SoftwareとOracle Databaseソフトウェアのバージョン間の互換性要件
• 特定のハードウェア・リリースの互換性要件
• Oracle Exadataで使用する場合の関連製品のガイドライン
• Oracle Exadataソフトウェア・メンテナンスのその他の関連情報ソースへの参照

8.2.1.2 ソフトウェア・リリース・タイプ

次の表に、Oracle Exadata System Softwareのリリース・タイプを示します。

リリース・タイプ	説明および内容
メジャー・バージョン	メジャー・バージョンは、Oracle Exadata System Softwareを支える主要なOracle Linuxオペレーティング・システム(OS)バージョンを識別します。たとえば、ExaOL6X、ExaOL7X、ExaOL8Xなどです。
ソフトウェア・リリース	ソフトウェア・リリースには、新機能、バグ修正、セキュリティ修正が含まれ、新しい世代のExadataシステム・ハードウェアおよび新しいOracle Databaseソフトウェア・リリースのサポートが含まれる場合があります。 Oracle Exadata System Softwareリリース18.1以降、Exadataソフトウェア・リリースは、リリース番号の最初の2桁を使用して表されます。たとえば、18.1、19.1、19.2などです。 以前は、最初の4桁がExadataソフトウェア・リリースを表していました。たとえば、12.2.1.1 ソフトウェア・リリースは、以前のソフトウェア・リリースまたはメンテナンス・リリースの更新に使用できます。
メンテナンス・リリース	メンテナンス・リリースには、バグ修正、セキュリティ修正が含まれ、機能拡張が含まれる場合があります。 Oracle Exadata System Softwareリリース18.1以降、メンテナンス・リリースは、リリース番号の3番目の桁を使用して表されます。たとえば、23.1.2、23.1.3、23.1.4などです。 以前は、5番目の桁がメンテナンス・リリースを表していました。たとえば、12.1.2.3.4 メンテナンス・リリースは、以前のソフトウェア・リリースまたはメンテナンス・リリースの更新に使用できます。
個別パッチ	個別パッチは、修正がメンテナンス・リリースまたはソフトウェア・リリースに含まれるまで待てないユーザーが使用できる1回かぎりのバグ修正です。個別パッチのインストールは必要に応じて行われ、定期的にスケジュールされた計画メンテナンス・イベントではありません。

8.2.1.3 ソフトウェア・リリース可用性

次の表に、Oracle Exadata System Software、Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのリリース・サイクルの概要を示します。

ソフトウェア	リリース・タイプ	リリース頻度	最新バージョンを維持する重要度	新しいリリースを導入する際の推奨事項
Oracle Exadata System Software	ソフトウェア・リリース	6から18か月	中	新機能を導入し、重要な修正およびセキュリティ更新を取得する場合に更新します。
Oracle Exadata System Software	メンテナンス・リリース	毎月	高	重要な修正およびセキュリティ更新を取得する場合に定期的に更新します。 最新のメンテナンス・リリースの12か月以内に維持することをお薦めします。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	長期リリース	24か月以上	中	長期リリースは、最高レベルの安定性と最長期間のエラー修正サポートのために使用します。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	イノベーション・リリース	12から24か月	中	イノベーション・リリースは、新機能をできるだけ早く導入する場合に使用します。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	リリース更新(RU)	3か月(四半期)	高	重要な修正およびセキュリティ更新を取得する場合に四半期に一度更新します。 最新のリリース更新の12か月以内に維持することをお薦めします。

8.2.1.4 ソフトウェア更新頻度

Exadataソフトウェアの定期的な更新を計画する必要があります。

次に、リリースの通常の間隔を使用した4年サイクルにわたる四半期ごとの更新を含む高度なソフトウェア・メンテナンス計画の例を3つ示します。この例は、特定の目標を満たすように設計された様々な更新戦略を示しています。

ノート:

実際のリリース頻度は、これらの例とは異なる場合があります。

• 例8-1 本番システム・ソフトウェアのメンテナンス計画

• 例8-2 本番システム・ソフトウェアの更新の少ないメンテナンス計画

• 例8-3 開発およびテスト・システム・ソフトウェアのメンテナンス計画

例8-1 本番システム・ソフトウェアのメンテナンス計画

目標 — 重要な修正とセキュリティ修正を定期的に適用し、新しい機能リリースを必要な場合にのみ導入して、新しいExadataソフトウェア・リリースと新しいOracle Databaseリリースを同時に導入しないことにより、リスクを最小限に抑えます。

アクション	Y1 Q1	Y1 Q2	Y1 Q3	Y1 Q4	Y2 Q1	Y2 Q2	Y2 Q3	Y2 Q4	Y3 Q1	Y3 Q2	Y3 Q3	Y3 Q4	Y4 Q1	Y4 Q2	Y4 Q3	Y4 Q4	Y5 Q1
最新のOracle Exadata System Softwareメンテナンス・リリースへの更新	-	X	X	X	X	-	X	X	X	X	-	X	X	X	X	-	X
最新のOracle Exadata System Softwareリリースへの更新	X	-	-	-	-	X	-	-	-	-	X	-	-	-	-	X	-
最新のOracle Databaseリリース更新(RU)への更新	X	-	X	X	X	X	X	X	X	X	X	X	X	X	X	X	X
最新のOracle Databaseイノベーション・リリースへの更新	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
最新のOracle Database長期リリースへの更新	-	X	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-

例8-2 本番システム・ソフトウェアの更新の少ないメンテナンス計画

目標 — より少ない頻度で更新を適用することにより、リスクを管理し、メンテナンス時間を短縮します。新しいOracle Database機能リリースは必要に応じて導入します。Exadataのソフトウェア・リリースとOracle Databaseの新機能リリースを同時に導入しないことでリスクを最小限に抑えます。

アクション	Y1 Q1	Y1 Q2	Y1 Q3	Y1 Q4	Y2 Q1	Y2 Q2	Y2 Q3	Y2 Q4	Y3 Q1	Y3 Q2	Y3 Q3	Y3 Q4	Y4 Q1	Y4 Q2	Y4 Q3	Y4 Q4	Y5 Q1
最新のOracle Exadata System Softwareメンテナンス・リリースへの更新	-	-	-	X	-	X	-	-	-	X	-	X	-	-	-	X	-
最新のOracle Exadata System Softwareリリースへの更新	-	X	-	-	-	-	-	X	-	-	-	-	-	X	-	-	-
最新のOracle Databaseリリース更新(RU)への更新	-	X	-	-	-	X	-	X	-	X	-	X	-	X	-	-	-
最新のOracle Databaseイノベーション・リリースへの更新	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	X	-
最新のOracle Database長期リリースへの更新	-	-	-	X	-	-	-	-	-	-	-	-	-	-	-	-	-

例8-3 開発およびテスト・システム・ソフトウェアのメンテナンス計画

目標 — 最新の機能およびソフトウェア更新を四半期ごとに導入します。

アクション	Y1 Q1	Y1 Q2	Y1 Q3	Y1 Q4	Y2 Q1	Y2 Q2	Y2 Q3	Y2 Q4	Y3 Q1	Y3 Q2	Y3 Q3	Y3 Q4	Y4 Q1	Y4 Q2	Y4 Q3	Y4 Q4	Y5 Q1
最新のOracle Exadata System Softwareメンテナンス・リリースへの更新	-	X	X	X	X	-	X	X	X	X	-	X	X	X	X	-	X
最新のOracle Exadata System Softwareリリースへの更新	X	-	-	-	-	X	-	-	-	-	X	-	-	-	-	X	-
最新のOracle Databaseリリース更新(RU)への更新	-	X	X	X	X	-	X	X	X	X	-	X	X	X	X	-	X
最新のOracle Databaseイノベーション・リリースへの更新	-	-	-	-	-	X	-	-	-	-	X	-	-	-	-	-	-
最新のOracle Database長期リリースへの更新	X	-	-	-	-	-	-	-	-	-	-	-	-	-	-	X	-

8.2.1.5 ソフトウェア更新ユーティリティ

Oracle Exadataでソフトウェアを更新する場合、更新されるコンポーネントに応じて特定のユーティリティを使用します。

更新タイプ	ユーティリティ	コンポーネント	説明
更新前の準備状況チェック	Oracle EXAchk	Oracle Exadata	メンテナンス準備状況を確認し、重大な問題の発生を特定し、ソフトウェアを更新するバージョン推奨を提供するために使用されるヘルス・チェック・ツールです。 My Oracle Supportのドキュメント1070954.1からOracle EXAchkを取得してください。
Oracle Exadata System Software	patchmgr	Oracle Exadataストレージ・サーバー Oracle Exadataデータベース・サーバー RDMAネットワーク・ファブリックのスイッチ	Oracle Exadata データベース・サーバー、ストレージ・サーバーまたはRDMAネットワーク・ファブリック・スイッチのすべてのソフトウェア(Oracle Linux、Oracle Exadata System Software、ファームウェア)を更新する、Oracle Exadataソフトウェア更新ツール。たとえば、patchmgrではOracle Exadataのストレージ・サーバーとデータベース・サーバーをOracle Exadata System Softwareバージョン12.2.1.1.0に、またはInfiniBandネットワーク・ファブリック・スイッチをバージョン2.2.4-3に更新します。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア・リリース更新	OPatchまたはopatchauto	Oracle Exadataデータベース・サーバー	リリース更新をOracle Grid InfrastructureホームまたはOracle Databaseホームに適用するソフトウェア更新ツールです。 たとえば、OPatchは、12.1.0.2.170117リリース更新を12.1.0.2 Oracle Grid InfrastructureおよびOracle Databaseホームに適用します。 My Oracle Supportのドキュメント274526.1からOPatchを取得してください。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのパッチ・セット、メジャー・リリースまたはリリース更新	Oracle Universal Installer	Oracle Exadataデータベース・サーバー	Oracle Grid InfrastructureおよびOracle Databaseパッチ・セット、メジャーまたはリリース更新をインストールし、Oracle Grid Infrastructureをアップグレードするソフトウェア・インストール・ツールです。 たとえば、Oracle Universal Installerは、Oracle Database 12.2.0.1をインストールしたり、Oracle Grid Infrastructureをインストールして12.1.0.2から12.2.0.1へアップグレードします。 アップグレードするOracle Grid InfrastructureおよびOracle DatabaseリリースにバンドルされているOracle Universal Installerのバージョンを使用します。
Oracle Databaseのアップグレード	Oracle Database AutoUpgrade	Oracle Exadataデータベース・サーバー	1つのコマンドおよび構成ファイルを使用して1つ以上のOracleデータベースをアップグレードできるOracle Databaseアップグレード・ユーティリティ。 AutoUpgradeでは、アップグレード前タスクの実行、必要に応じた自動修正の実行、データベース・アップグレードの実行、アップグレード後タスクの完了を行うことができます。 AutoUpgradeには、組込みのスケジューリング機能、自動再試行とフォールバック、およびアップグレード中の初期化パラメータの設定、変更または削除機能が含まれています。
Oracle Databaseのアップグレード	Database Upgrade Assistant(DBUA)	Oracle Exadataデータベース・サーバー	新しいパッチ・セット、メジャー・リリースまたはリリース更新にデータベースをアップグレードするデータベース・ツールです。たとえば、DBUAは、データベースを12.1.0.1から12.1.0.2にアップグレードしたり、12.1.0.2から12.2.0.1にアップグレードします。 アップグレードするOracle Grid InfrastructureおよびOracle DatabaseリリースにバンドルされているDBUAを使用します。
Oracle Exadata System Software Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	フリート・パッチ適用およびプロビジョニング(以前は高速ホーム・プロビジョニング(RHP)と呼ばれていました)	Exadataストレージ・サーバー Exadataデータベース・サーバー RDMAネットワーク・ファブリックのスイッチ	集中化されたサーバーから1つ以上のクラスタ上のOracle Grid InfrastructureおよびOracle Databaseソフトウェアのプロビジョニング、パッチ適用およびアップグレードを行うソフトウェア・メンテナンス・ツールです。 Oracle Clusterwareの機能としてフリート・パッチ適用およびプロビジョニングを使用します。 Oracle Grid Infrastructureリリース18c以降、フリート・パッチ適用およびプロビジョニングでは、Oracle Grid InfrastructureおよびOracle Databaseホームに加えて、Oracle Exadataのコンポーネント(データベース・ノード、ストレージ・セルおよびRDMAネットワーク・ファブリック・スイッチ)へのパッチ適用がサポートされています。
Oracle Exadata System Software Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	Oracle Enterprise Manager Cloud Control	Exadataストレージ・サーバー Exadataデータベース・サーバー RDMAネットワーク・ファブリックのスイッチ	Oracle Enterprise Manager Cloud Controlには、ソフトウェア更新をOracle Exadataに適用するライフサイクル管理機能があります。 ノート: Oracle Enterprise Manager Cloud Controlリリース13.4では、Oracle Exadata System Softwareを更新する機能が非推奨になりました。

8.2.2 ソフトウェア・メンテナンスの構成および操作のベスト・プラクティス

ソフトウェア更新の計画の一環として、更新を実行する様々な方法、およびソフトウェアを更新するためのベスト・プラクティスを確認する必要があります。

• ローリング更新および非ローリング更新の理解
  データベースがオンラインで使用可能な間はローリング形式でソフトウェア更新を実行し、Oracle ClusterwareおよびOracle Databaseが停止している場合は非ローリング形式で実行できます。
• Oracle LinuxカーネルおよびOracle Databaseの個別修正のオンライン更新
  適格な修正のオンライン更新は、Oracle LinuxおよびOracle Databaseでサポートされています。
• 最適なソフトウェア・メンテナンスの構成プラクティス
  Exadata Database Machineを構成する場合は、ソフトウェア更新を実行する影響およびリスクを減らす機能を導入することが重要です。
• 最適なソフトウェア・メンテナンスの操作のプラクティス
  
• バージョン互換性および複合バージョンのサポート
  最も安定したセキュアなシステムを維持するために、定期的に更新されるすべてのコンポーネントのソフトウェアは、推奨される最小リリースと揃えることをお薦めします。

8.2.2.1 ローリング更新および非ローリング更新の理解

データベースがオンラインで使用可能な間はローリング形式でソフトウェア更新を実行し、Oracle ClusterwareおよびOracle Databaseが停止している場合は非ローリング形式で実行できます。

更新を実行する形式は、更新の頻度には影響しませんが、更新にかかる時間には影響します。一般に、次の2つの方式があります。

• ローリング・ソフトウェア更新 — ローリング・ソフトウェア更新は、一度に1つの特定のコンポーネントに対して実行される更新で、他のコンポーネントはリクエストの処理中オンラインのままです。ローリング・ソフトウェア更新について次の重要な点に注意してください。

  • ローリング更新では、アプリケーション停止時間が非ローリング更新より短くなります。

  • 更新が完了するまでの時間全体は長くなります。これは、1つのコンポーネントがオフラインで一度に更新され、他のすべてのコンポーネントはオンラインのままで稼働しているためです。

  • 既存のデータベース接続への影響は、更新されるコンポーネントに応じて異なります。

    • Oracle Exadataストレージ・サーバーまたはRDMAネットワーク・ファブリック・スイッチのローリング更新 — ローリング更新中、すべてのデータベースは完全にオンラインで使用可能なままです。データベース接続への中断はありません。

    • Oracle Exadataデータベース・サーバー、Oracle Grid InfrastructureまたはOracle Databaseのローリング更新 — Oracle Real Application Clusters (Oracle RAC)を使用するマルチインスタンス・データベースは、更新中も使用可能です。ただし、ローカル・データベース・インスタンスが停止すると、更新されるサーバー上のデータベース接続は中断されます。表8-1に説明されているように、クライアントの高可用性のためのOracle RACの機能を使用して、アプリケーションの中断を最小限にします。

• 非ローリング・ソフトウェア更新 — 非ローリング・ソフトウェア更新は、すべての特定のコンポーネントに対して実行される更新で、これらのコンポーネントはオフラインになります。非ローリング・ソフトウェア更新について次の重要な点に注意してください。

  • 非ローリング更新は、メンテナンス時間全体ではローリング更新より高速です。これは、複数のコンポーネントがパラレルに更新されるためです。
  • 更新中、すべての特定のコンポーネントがオフラインで、1つのデータベース(またはシステム上のすべてのデータベース)もオフラインになるため、結果としてアプリケーションへの完全な停止となります
  • 非ローリング形式で更新されるOracle Exadataによって処理された重要なアプリケーションは、Oracle Data Guardを使用する環境のスタンバイ・システムに頻繁に移動されます。

• ローリング・ソフトウェア更新と非ローリング・ソフトウェア更新の組合せ — 同じメンテナンス・ウィンドウで複数のコンポーネントを更新する場合、ローリング方式と非ローリング方式の組合せを使用して、アプリケーションの停止時間とメンテナンス時間の望ましいバランスを実現できます。アプリケーションが接続の中断を効率的に処理しない状況で使用される一般的な組合せとして、Oracle Exadataストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチの更新をローリング形式で実行してから、Oracle Grid Infrastructure、Oracle DatabaseおよびOracle Exadataデータベース・サーバーの更新を非ローリング形式で実行します。

patchmgr更新ユーティリティは、Oracle Exadataのインフラストラクチャ・コンポーネント(ストレージ・サーバー、データベース・サーバーおよびRDMAネットワーク・ファブリック・スイッチ)のローリング形式または非ローリング形式での更新オーケストレーションを管理します。

次の表は、各コンポート・タイプでサポートされる更新方式を説明しています。

表8-1 ローリング・アップグレードと非ローリング・アップグレード

方式	コンポーネントのサポート	更新中のデータベース可用性の影響
ローリング	Oracle Exadataストレージ・サーバー	影響なし。 Oracle RACおよび単一インスタンス・データベースは、クラスタ内のすべてのノードで完全に使用可能なままです。
ローリング	RDMAネットワーク・ファブリックのスイッチ	影響なし。 Oracle RACおよび単一インスタンス・データベースは、クラスタ内のすべてのノードで完全に使用可能なままです。
ローリング	Oracle Exadataデータベース・サーバー	ローカル接続が切断され、すべてのローカル・インスタンスが停止します。 Oracle RACデータベースは、クラスタ内の他のノード全体で使用可能なままです。
ローリング	Oracle Grid Infrastructure	ローカル接続が切断され、すべてのローカル・インスタンスが停止します。 Oracle RACデータベースは、クラスタ内の他のノード全体で使用可能なままです。
ローリング	Oracle Database - リリース更新(RU)	更新されるデータベース・ホームでは、ローカル接続が切断され、ローカル・インスタンスが停止します。 Oracle RACデータベースは、クラスタ内の他のノード全体で使用可能なままです。 他のOracle Databaseソフトウェア・ホームから実行するデータベースは影響を受けません。
非ローリング	Oracle Exadataストレージ・サーバー Oracle Exadataデータベース・サーバー Oracle Grid Infrastructure Oracle Database - リリース更新(RU) Oracle Database - パッチ・セット Oracle Database - リリース	データベース使用不可 ワークロードをOracle Data GuardまたはOracle GoldenGateスタンバイ・システムに移動して、影響を最小限に抑えます。

8.2.2.2 Oracle LinuxカーネルおよびOracle Databaseの個別修正のオンライン更新

 適格な修正のオンライン更新は、Oracle LinuxおよびOracle Databaseでサポートされています。

通常、計画ソフトウェア更新では、更新後にコンポーネントを再起動する必要があります。たとえば、Exadataデータベース・サーバーは、Exadataソフトウェア・リリースを適用した後に再起動して、システム・ファームウェアを更新し、新しいOracle Linuxカーネルをアクティブにする必要があります。同様に、Oracleデータベース・インスタンスを停止してから再起動して、ソフトウェア更新をデータベース・ホームに適用する必要があります。

ただし、オンラインで適用が可能で、修正を適用してアクティブにするためにコンポーネントを再起動する必要がない個別修正が提供される場合もあります。適格な修正のオンライン更新は、次のコンポーネントでサポートされています。

• Kspliceオフライン・クライアントを使用したExadataデータベース・サーバー上のOracle Linuxカーネル。

• OPatchオンライン・パッチ適用を使用したOracle Database。

通常、オンライン更新は、次にスケジュールされた計画ソフトウェア・メンテナンスの前に重要な修正をシステムに適用する必要がある場合に、一時的な措置として実行されます。

8.2.2.3 最適なソフトウェア・メンテナンスの構成プラクティス

Exadata Database Machineを構成する場合は、ソフトウェア更新を実行する影響およびリスクを減らす機能を導入することが重要です。

構成のプラクティス	ソフトウェア・メンテナンスのために使用	用途
Oracle ASM高冗長性ディスク・グループ	ローリング更新 - Exadataストレージ・サーバー	データベースをオンラインのままにしてローリング形式でストレージ・サーバー更新を実行する場合、高冗長性のOracle ASMディスク・グループを構成することを強くお薦めします。高冗長性ディスク・グループは、ローリング更新中に別のストレージ・サーバーでのディスクの障害に耐えることができます。 ローリングまたはオンラインのストレージ・サーバーの更新中、更新されるストレージ・サーバーのディスクは、更新中にpatchmgrによって1つのストレージ・サーバー上でオフラインになります。更新が完了すると、ディスクはOracle ASMによって再同期化され、patchmgrは次のストレージ・サーバーの更新を開始します。 ディスクのオフライン中、ディスク・グループの冗長性は低くなります。ローリング更新中に標準冗長性ディスク・グループの冗長性が低いと、別のストレージ・サーバーでディスクに障害が発生した場合にディスマウントされ、データが失われる可能性があります。 Oracle ASMディスク・グループの冗長性は、通常、システムの初期構成時に設定されます。そのため、システム構成の前に、ストレージ・サーバー更新の実行を計画する方法(ローリングまたは非ローリング)を考慮します。 Oracle Data Guardフィジカル・スタンバイ・システムは、ローリング・ストレージ・サーバー更新中のディスク障害に対して保護することもできます。
クライアントの高可用性のためのOracle RACの機能	ローリング更新 - Exadataデータベース・サーバー、Oracle Grid InfrastructureまたはOracle Databaseソフトウェア	クラスタ内の他のサーバー上でデータベース・サービスの実行中に1つのベース・サーバー上でExadataデータベース・サーバー、Oracle Grid InfrastructureまたはOracle Databaseソフトウェアの更新をローリング形式で一度に実行する場合、更新されるExadataデータベース・サーバー上ではデータベース・サービスを停止する必要があります。 メンテナンス中に停止されるデータベース・インスタンスに接続されたクライアント・アプリケーションへの影響を最小限に抑えるには、データベース・サービス、高速アプリケーション通知(FAN)、高速接続フェイルオーバー(FCF)およびアプリケーション・コンティニュイティを使用するように、クライアント・アプリケーションを構成します。
Oracle Data Guardフィジカル・スタンバイ・データベース	ローリング更新または非ローリング更新(Oracle Databaseパッチ・セットおよびリリース更新を除く)	Oracle Data Guard Standby-First Patchの適用は、プライマリ・データベースへのリスクが最小限のローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるExadataインフラストラクチャ、Oracle Grid InfrastructureおよびOracle Databaseソフトウェアをサポートします。
Oracle Data Guard一時ロジカル・スタンバイ・データベース	ローリング更新または非ローリング更新	Oracle Data Guardロジカル・スタンバイ・データベースを使用して、パッチ・セットおよびリリース更新でのデータベース・アップグレードによる停止時間を減らします。 データベースのアップグレードによる停止時間は、プライマリ・データベースがオンラインのままで現在のバージョンを実行して、ロジカル・スタンバイ・データベースを新しいバージョンにアップグレードし、同期を維持することを許可することにより短縮されます。
Oracle GoldenGate	ローリング更新または非ローリング更新	Oracle GoldenGateを使用して、パッチ・セットおよびリリース更新でのデータベース・アップグレードによる停止時間を減らします。データベースのアップグレード中の停止時間は、ソース・データベースがオンラインのままで現在のバージョンを実行して、ターゲット・データベースを新しいバージョンにアップグレードし、同期を維持することを許可することにより短縮されます。

8.2.2.4 最適なソフトウェア・メンテナンスの操作のプラクティス

次の操作のプラクティスによって、最適なソフトウェア・メンテナンスが可能になります。

• Oracle EXAchkを定期的に実行する — Exadataシステムが現在のベスト・プラクティスと常に変化するベスト・プラクティスを満たし続けていることを確認するための一般的なヘルス・チェック・ツールとして、Oracle EXAchkを毎月実行します。exachkレポートは次のように利用します。

  • ベースライン比較 - レポート比較機能(-diffオプション)を使用して、現在のレポートを承認されたベースライン・レポートと比較します。

  • 重大な問題の発生 - 重大な問題が発生しているかどうかレポートを確認します。迅速に対処して、Oracle EXAchkによってレポートされた重大な問題を解決します。

  • バージョン推奨 - バージョン推奨があるかどうかレポートを確認します。「MAAスコアカード」セクションでは、現在のソフトウェア・バージョンの一貫性、互換性、および最新であるかどうかを評価します。

• Oracle EXAchkを使用してメンテナンス準備状況を確認する — ソフトウェア・メンテナンスを実行する前に、Oracle EXAchkを実行して、システムが正常な状態であることを確認します。ソフトウェアを更新する前に、FAILまたはWARNINGチェックを修正します。ソフトウェア・メンテナンスの完了後にOracle EXAchkを再実行して、システム状態を確認します。

• ソフトウェアを定期的に更新する — すべてのソフトウェアを定期的に更新します。最新または最近のリリースでソフトウェアをメンテナンスすると、ソフトウェア・セキュリティの向上、新しい関連ソフトウェアとの継続した互換性、問題に対する最適なサポートと迅速な解決、新しく検出された問題を修正する機能などの利点があります。

• 更新ユーティリティの最新バージョンを使用する — ソフトウェア更新ユーティリティ(Oracle EXAchk、patchmgrおよびOPatch)の最新バージョンを使用します。

  Oracle EXAchkは、新しい機能、修正、ベスト・プラクティスのヘルス・チェック、およびバージョン推奨が含まれるように、定期的に更新されます。データベース・サーバーのPatchmgrは、新しい機能、修正、およびデータベース・サーバー更新の既知の問題の回避策が含まれるように、定期的に更新されます。OPatchは、新しい機能および修正が含まれるように、定期的に更新されます。

• ストレージ・サーバーの更新はRDMAネットワーク・ファブリック・スイッチの更新とは別に実行します — ストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチを同時に更新しないでください。RDMAネットワーク・ファブリックのネットワーク接続は、ストレージ・サーバーの更新のいくつかの重要な段階で安定している必要があります。RDMAネットワーク・ファブリック・スイッチのファームウェア更新にはスイッチの再起動が必要になるため、RDMAネットワーク・ファブリックの一部の接続に中断が発生します。

• サポートされていないシステム変更を回避する — Oracle Exadataは統合システムであり、Oracle Databaseを実行するための最適なプラットフォームになるように設計されています。Oracle Exadataストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチには、Oracle Databaseの実行に必要なすべてのソフトウェアが含まれており、Oracle Databaseを最適に実行するように構成されます。Oracle Exadataのストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチに対するソフトウェア更新は、patchmgrを使用して実行します。Oracle Exadataドキュメントに目的の変更の実行ステップが記載されていない場合、構成またはインストール済ソフトウェアは手動で(patchmgrを使用せずに)変更できない可能性があります。サポートされていない手動の変更が即時に反映されると、次のような悪い結果が多く発生する可能性があります。

  • 今後のpatchmgrソフトウェア更新の失敗
  • システムのレスキュー不可
  • ソフトウェア不具合の効率的な診断不可

  Oracle Exadataストレージ・サーバーまたはRDMAネットワーク・ファブリック・スイッチの目的の変更について記載されていない場合、詳細はOracleサポート・サービスに連絡してください。

• データベース・サーバーのカスタマイズを最小限にする — Oracle Exadataは統合システムであり、Oracle Databaseを実行するための最適なプラットフォームになるように設計されています。Oracle Exadataデータベース・サーバーには、Oracle Databaseの実行に必要なすべてのソフトウェアが含まれており、Oracle Databaseを最適に実行するように構成されます。Oracle Exadataデータベース・サーバーへのソフトウェア更新は、patchmgrを使用して実行されます。ただし、サイト固有の追加のソフトウェア(モニタリング・エージェントやバックアップ・エージェントなど)の手動インストールが必要になる場合があります。

  データベース・サーバーの手動カスタマイズはサポートされていますが、パッケージを追加または更新することによってオペレーティング・システムをカスタマイズすると、今後patchmgrを使用してOracle Exadata System Software更新を適用するとき(たとえば、Oracle Exadataサーバーの更新前にカスタマイズを削除し、Exadata更新の完了後にカスタマイズを再適用する場合)に、追加のアクションが必要になることがあります。これは、追加したソフトウェアによって、今後のOracle Exadata System Software更新では提供されない新しい依存性が追加される場合があるためです。データベース・サーバーのカスタマイズを最小限にすることをお薦めします。詳細は、トピック「Oracle Exadataデータベース・サーバーの更新」を参照してください。

• サポートされている構成変更をテストする — データベース・サーバーのサイト固有のカスタマイズを完全にテストする必要があります(構成変更後にデータベース・サーバーが正常に再起動したことを確認するなど)。システムが正常に再起動できなくなるカスタム構成変更を行うと、今後のOracle Exadata System Software更新が失敗します。

8.2.2.5 バージョン互換性および複合バージョンのサポート

最も安定したセキュアなシステムを維持するために、定期的に更新されるすべてのコンポーネントのソフトウェアは、推奨される最小リリースと揃えることをお薦めします。

ただし、ソフトウェア・メンテナンス・ウィンドウ中にコンポーネントのサブセットのみを更新することがサポートされており、残りのコンポーネントは以前のバージョンのままです。たとえば、次のシナリオがサポートされます。

• Oracle Exadataストレージ・サーバーのサブセットを新しいバージョンのOracle Exadata System Softwareに更新しますが、残りのストレージ・サーバーは以前のOracle Exadata System Softwareのバージョンのままです。

• Oracle Exadataストレージ・サーバーを新しいバージョンのOracle Exadata System Softwareに更新しますが、データベース・サーバーは以前のOracle Exadata System Softwareのバージョンのままです。

• Oracle Exadataデータベース・サーバーを新しいバージョンのOracle Exadata System Softwareに更新しますが、ストレージ・サーバーは以前のOracle Exadata System Softwareのバージョンのままです。

• Oracle Exadataストレージ・サーバーを新しいバージョンのOracle Exadata System Softwareに更新しますが、RDMAネットワーク・ファブリック・スイッチは以前のOracle Exadata System Softwareのバージョンのままです。

• RDMAネットワーク・ファブリック・スイッチを新しいバージョンのOracle Exadata System Softwareに更新しますが、Oracle Exadataストレージ・サーバーは以前のOracle Exadata System Softwareのバージョンのままです。

• Oracle Exadataストレージ・サーバーを新しいバージョンのOracle Exadata System Softwareに更新しますが、Oracle Grid InfrastructureまたはOracle Databaseソフトウェアは以前のリリースおよび更新レベルのままです。

複合バージョン(同じコンポーネント内または異なるコンポーネント間)はサポートされていますが、これは、ローリング・アップグレードの目的で、ローリング・アップグレード中に存在する一時的な構成のみにすることを強くお薦めします。

複合バージョンの場合、次のルールおよび考慮事項に従う必要があります。

• 特定の世代のOracle Exadataハードウェアには、最小要件としてOracle Exadata System Softwareバージョンがあります。たとえば、Oracle Exadata X6ハードウェアには、Oracle Exadata System Softwareリリース12.1.2.3.1以降が必要になります。

• 特定のOracle Databaseリリースには、Oracle Exadataの機能を完全にサポートするための最低限のOracle Exadata System Softwareリリースが必要です。たとえば、Oracle Database 12cリリース2 (12.2)では、Oracle Exadataのすべてのオフロード機能をサポートするために、ストレージ・サーバーでOracle Exadata System Softwareリリース12.2.1.1.0以上が必要です。

• Oracle Exadata System Softwareの新しいリリースで提供されている機能には、最低でもOracle Grid InfrastructureまたはOracle Databaseのソフトウェア・リリースまたはリリース更新が必要です。たとえば、Oracle Exadataの機能である圧縮型索引スキャンのためのSmart Scanオフロードには、ストレージ・サーバー上にOracle Database 12.2とOracle Exadata System Software 12.2が必要です。

• Oracle Grid Infrastructureでは、ローリング更新中にのみ複合バージョンがサポートされています(たとえば、リリース12.1.0.2から12.2.0.1への更新中、またはリリース12.1.0.2.161018から12.1.0.2.170117への更新中)。Oracle Clusterwareの機能には、クラスタがローリング・アップグレード・モードの場合に制限されているものもあります。

• Oracle Databaseでは、ローリング更新中にのみ複合バージョンがサポートされています(たとえば、リリース12.1.0.2.161018から12.1.0.2.170117への更新中)。

8.2.3 Exadataソフトウェア・イメージ・バージョンの理解

Exadataイメージ・バージョン番号には、製品バージョン、日付コードおよびビルド番号が含まれます。

Exadataストレージ・サーバーまたはExadataデータベース・サーバーにインストールされるExadataバージョンは、imageinfoコマンドで決定されます。Exadataリリースのイメージ・バージョンは、3つのコンポーネントで構成されています。たとえば、コマンドimageinfo -verが12.1.2.1.1.150316.2を返した場合、次のようになります。

• 製品バージョンは12.1.2.1.1です。

• 日付コードは150316です。

• Oracleの内部ビルド番号は2です。このコンポーネントは常に使用されるとはかぎりません。

ほとんどの状況においては、製品バージョン(たとえば12.1.2.1.1)のみでリリースを参照することで十分です。ただし、アップグレードするときには、インストール済リリースおよびターゲット・リリースの製品バージョンと日付コードの両方を考慮する必要があります。

Oracle Exadata System Softwareリリース18.1以降、製品バージョンでは、Year.Update.Revisionで構成される3つのフィールド形式(18.1.0など)が使用されます。

8.2.4 新しいExadataバージョンへの更新のルール

アップグレードするときには、インストール済リリースおよびターゲット・リリースの製品バージョンと日付コードの両方を考慮する必要があります。

ほとんどの状況においては、製品バージョン(たとえば12.1.2.1.1)のみでリリースを参照することで十分です。

特定のターゲット・バージョンへのアップグレードでは、patchmgrによって施行される次のルールに従う必要があります。

1. ターゲット・リリースの製品バージョンがインストール済ソフトウェアよりも大きい

   かつ

2. ターゲット・リリースの日付コードがインストール済ソフトウェアよりも大きい必要があります。

たとえば、製品バージョン12.1.1.1.2と日付コード150411で構成されるイメージ・バージョン12.1.1.1.2.150411を現在実行しているExadata Database Machineがあるとします。    

• 12.1.2.1.2.150617.1へのアップグレードは、両方のルールが満たされているため、許可されます。

• 12.1.2.1.1.150316.2へのアップグレードは、インストール済ソフトウェアの日付コード150411がターゲット・リリースの日付コード150316よりも大きいため、許可されません。

8.3 Exadataソフトウェア更新の実行の概要

Exadataコンポーネントのソフトウェア更新ごとに、そのソフトウェア更新を完了するために様々なアクションが必要になります。

• ソフトウェア・メンテナンス前に実行するアクション
  Exadata Database Machine上のソフトウェアの更新を実行するには、次のアクションを実行する必要があります。
• Exadataストレージ・サーバー更新の実行の概要
  Exadataストレージ・サーバーを更新するプロセスの概要を示します。
• Exadataデータベース・サーバー更新の実行の概要
  Exadataデータベース・サーバーを更新する場合、仮想化環境には別のステップがあります。
• RoCEネットワーク・ファブリック・スイッチ更新の実行の概要
  patchmgrは、RoCEネットワーク・ファブリック・スイッチのローリング形式の更新オーケストレーションを管理します
• InfiniBandネットワーク・ファブリック・スイッチ更新の実行の概要
  patchmgrは、InfiniBandネットワーク・ファブリック・スイッチのローリング形式の更新オーケストレーションを管理します
• Oracle Grid InfrastructureおよびOracle Database更新の実行の概要
  Oracle Grid InfrastructureまたはOracle Databaseソフトウェアを更新するステップは、実行しているソフトウェア更新のタイプによって異なります。
• ソフトウェア更新実行時のsudoの使用
  dbnodeupdate.shおよびpatchmgr (およびdbnodeupdateオーケストレーション)の実行時には、sudoを使用できます。

8.3.1 ソフトウェア・メンテナンス前に実行するアクション

Exadata Database Machine上のソフトウェアの更新を実行するには、次のアクションを実行する必要があります。

• ターゲット・リリースの識別

  ターゲット・リリースは、次のいずれかによって判別できます。

  • My Oracle Supportのドキュメント888828.1の推奨事項。

  • Oracle ExaCHKレポートの「MAAスコアカード」セクションのバージョン推奨。

• Oracle ExaCHKを実行する

  Oracle ExaCHKの最新バージョンを実行することで、システムのソフトウェア・メンテナンス準備状況を確実にします(My Oracle Supportのドキュメント1070954.1を参照してください)。 レポートで、次の点を確認します。

  1. ベースラインから逸脱したFAILまたはWARNINGチェックを修正します。

  2. 「MAAスコアカード」セクションでバージョン推奨を確認します。 Oracle ExaCHKは、現在のソフトウェア・バージョンの一貫性、互換性、および最新であるかどうかを評価します。

  3. 「MAAスコアカード」セクションで重大な問題が発生しているかどうか確認します。 ターゲット・バージョンの選択によって、重大な問題の発生が解決されます。

  次のタイミングでOracle ExaCHKの最新バージョンを実行することをお薦めします。

  • 毎月(Exadataのベスト・プラクティスに従っているシステムを維持するため)

  • メンテナンス準備状況を確実にするためのソフトウェア更新の1週間前

  • メンテナンス準備状況を確実にするためのソフトウェア更新の前日

  • ソフトウェア更新が完了した直後

• 前提条件チェックを実行する

  1. My Oracle Supportから、ターゲット・ソフトウェア・リリースおよびソフトウェア更新ユーティリティ(patchmgr、OPatchなど)の最新バージョンをダウンロードします。

  2. 前提条件チェックを実行し、問題を修正します。  初期の前提条件チェックの実行は、問題を修正するための時間を確保するために、メンテナンス・ウィンドウの数日または数週間前に実行する必要があります。更新の直前に、前提条件チェックを再度実行します。

• 最新ドキュメントを確認する

  1. Oracle ExaCHKによってまだ自動的にチェックされていない、最近公開された重大な問題については、My Oracle Supportのドキュメント1270094.1を確認してください。  

  2. ソフトウェアがリリースされた後に検出された既知の問題のターゲット・ソフトウェア・バージョンについては、My Oracle Supportの補足READMEを確認してください。

8.3.2 Exadataストレージ・サーバー更新の実行の概要

Exadataストレージ・サーバーを更新するプロセスの概要を示します。

Patchmgrは、ストレージ・サーバーのローリング形式または非ローリング形式での更新オーケストレーションを管理します。  -rollingオプションを使用する場合は、Oracle ASM高冗長性ディスク・グループを使用して、更新中に別のストレージ・サーバーでのディスクの障害に耐えるようにすることをお薦めします。 

1. My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。 My Oracle Supportのドキュメント888828.1を参照してください。

2. 更新するストレージ・サーバーのリストを含むファイルを作成します。このファイルは、component_list_fileとして指定されます。

3.  component_list_file内のすべてのストレージ・サーバー上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。

4. patchmgr前提条件チェックを実行し、問題を修正します。 

5. ストレージ・サーバーが非ローリングで更新される場合は、Oracle Clusterwareおよびストレージ・サーバーにアクセスするすべてのデータベースを停止します。

6. patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でストレージ・サーバーを更新します。

7. ストレージ・サーバーが非ローリングで更新された場合は、Oracle Clusterwareおよびすべてのデータベースを再起動します。

8.3.3 Exadataデータベース・サーバー更新の実行の概要

Exadataデータベース・サーバーを更新する場合、仮想化環境には別のステップがあります。

ノート:

Patchmgrは、Exadataデータベース・サーバーのローリング形式または非ローリング形式での更新オーケストレーションを管理します。 -rollingオプションを使用する場合、クライアントの高可用性のためのOracle RACの機能を使用して、メンテナンス時に停止するデータベース・インスタンスに接続されたクライアント・アプリケーションへの影響を最小限に抑えることをお薦めします。 

• 非仮想化構成を更新するステップ
  Oracle VMが構成されていないExadataデータベース・サーバーの更新に関連するステップの概要です。
• 仮想化構成を更新するステップ
  個別にpatchmgrを実行して、管理ドメイン(dom0)とユーザー・ドメイン(domU)が個別に更新されます。

8.3.3.1 非仮想化構成を更新するステップ

Oracle VMが構成されていないExadataデータベース・サーバーの更新に関連するステップの概要です。

1.  My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。 

2. My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。  My Oracle Supportのドキュメント888828.1を参照してください。

3. 更新するデータベース・サーバーのリストを含むcomponent_list_fileを作成します。 

4.  component_list_file内のすべてのデータベース・サーバー上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。

5. patchmgrバックアップを実行して、データベース・サーバーのルート・ファイル・システムおよびオペレーティング・システムをバックアップします。 

6. patchmgr前提条件チェックを実行し、問題を修正します。 

7. patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーを更新します。

8.3.3.2 仮想化構成を更新するステップ

個別にpatchmgrを実行して、管理ドメイン(dom0)とユーザー・ドメイン(domU)が個別に更新されます。

管理ドメイン(dom0)の更新

•  My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。 

• My Oracle Supportからターゲットのdom0 Exadataソフトウェアをダウンロードし、それを駆動システム上で実行します。  My Oracle Supportのパッチ・ドキュメント888828.1を参照してください。 

• 更新するデータベース・サーバーdom0のリストを含むcomponent_list_fileを作成します。  

•  component_list_file内のすべてのデータベース・サーバーdom0上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。 

• patchmgrバックアップを実行して、データベース・サーバーdom0のルート・ファイル・システムおよびオペレーティング・システムをバックアップします。

• patchmgr前提条件チェックを実行し、問題を修正します。 

• patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーdom0を更新します。

ユーザー・ドメイン(domU)の更新

1.  My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。 

2. My Oracle SupportからターゲットのdomU Exadataソフトウェアをダウンロードし、それを駆動システム上で実行します。  My Oracle Supportのドキュメント888828.1を参照してください。

3. 更新するデータベース・サーバーdomUのリストを含むcomponent_list_fileを作成します。   

4.  component_list_file内のすべてのデータベース・サーバーdomU上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。  

5. patchmgrバックアップを実行して、データベース・サーバーdomUのルート・ファイル・システムおよびオペレーティング・システムをバックアップします。

6. patchmgr前提条件チェックを実行し、問題を修正します。 

7. patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーdomUを更新します。

8.3.4 RoCEネットワーク・ファブリック・スイッチ更新の実行の概要

patchmgrは、RoCEネットワーク・ファブリック・スイッチのローリング形式の更新オーケストレーションを管理します

ノート:

ストレージ・サーバーの更新は、RDMAネットワーク・ファブリック・スイッチの更新とは別に実行します。ストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチを同時に更新しないでください。RDMAネットワーク・ファブリックのネットワーク接続は、ストレージ・サーバーの更新のいくつかの重要な段階で安定している必要があります。RDMAネットワーク・ファブリック・スイッチのファームウェア更新にはスイッチの再起動が必要になるため、RDMAネットワーク・ファブリックの一部の接続に中断が発生します。

patchmgrを使用する際の一般的なステップは次のとおりです。

1. My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。My Oracle Supportのドキュメント888828.1を参照してください。

2. 更新するRoCEネットワーク・ファブリック・スイッチのリストを含むcomponent_list_fileを作成します。

3. component_list_file内のすべてのRoCEネットワーク・ファブリック・スイッチ上でrootに対してpatchmgrを実行するユーザーからSSH等価を構成します。

4. patchmgr前提条件チェックを実行し、問題を修正します。

5. patchmgrを実行してRoCEネットワーク・ファブリック・スイッチを更新します。RoCEネットワーク・ファブリック・スイッチは、常にローリング方式で更新されます。

8.3.5 InfiniBandネットワーク・ファブリック・スイッチ更新の実行の概要

patchmgrは、InfiniBandネットワーク・ファブリック・スイッチのローリング形式の更新オーケストレーションを管理します

ノート:

ストレージ・サーバーの更新は、RDMAネットワーク・ファブリック・スイッチの更新とは別に実行します。ストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチを同時に更新しないでください。RDMAネットワーク・ファブリックのネットワーク接続は、ストレージ・サーバーの更新のいくつかの重要な段階で安定している必要があります。RDMAネットワーク・ファブリック・スイッチのファームウェア更新にはスイッチの再起動が必要になるため、RDMAネットワーク・ファブリックの一部の接続に中断が発生します。

patchmgrを使用する際の一般的なステップは次のとおりです。

1. My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。My Oracle Supportのドキュメント888828.1を参照してください。

2. 更新するInfiniBandネットワーク・ファブリック・スイッチのリストを含むcomponent_list_fileを作成します。

3. component_list_file内のすべてのInfiniBandネットワーク・ファブリック・スイッチ上でrootに対してpatchmgrを実行するユーザーからSSH等価を構成します。

4. patchmgr前提条件チェックを実行し、問題を修正します。

5. patchmgrを実行してInfiniBandネットワーク・ファブリック・スイッチを更新します。InfiniBandネットワーク・ファブリック・スイッチは、常にローリング方式で更新されます。

8.3.6 Oracle Grid InfrastructureおよびOracle Database更新の実行の概要

Oracle Grid InfrastructureまたはOracle Databaseソフトウェアを更新するステップは、実行しているソフトウェア更新のタイプによって異なります。

リリース更新(RU)への更新

新しいリリース更新(RU)の更新は、インプレースまたはアウトオブプレースで実行できます。インプレースとアウトオブプレースの両方の方法で、ローリング更新と非ローリング更新がサポートされています。

• インプレース

  Oracle Grid InfrastructureまたはOracle Databaseソフトウェアが更新中のノードで停止している間に、OPatchを使用して現在のソフトウェア・ホームに更新が適用されます。

  これは、RU READMEに記載されているように、Oracle Grid InfrastructureまたはOracle DatabaseソフトウェアにRUを適用するデフォルトの方法です。RUを適用するステップは、各ノードで実行する必要があります。

• アウトオブプレース(推奨)

  Oracle Grid InfrastructureおよびOracle Databaseソフトウェアの実行中に、新しいソフトウェア・ホームが準備され、更新されます。新しいホームが準備されると、Oracle Grid InfrastructureおよびOracle Databaseはすばやく停止し、新しいホームに切り替えられ、再起動されます。

  アウトオブプレースは、インプレース更新より次のような大きな利点があります。

  • Oracle Grid InfrastructureおよびOracle Databaseソフトウェアがオンライン中に新しいホームを準備できるため、リスクは低くなります。
  • 新しいソフトウェア・ホームへの切替えは、インプレースの更新を適用するよりも速いため、停止時間は短くなります。
  • 元のソフトウェア・ホームに簡単に戻すことができるため、ロールバックが高速になります。

  アウトオブプレース更新を導入する推奨の方法は、フリート・パッチ適用およびプロビジョニング(以前は高速ホーム・プロビジョニングと呼ばれていました)を使用することです。次の利点があります。

  • クラスタ内のすべてのノードにソフトウェア更新を配布します。
  • 1つのコマンドを使用して、ローリング形式または非ローリング形式でクラスタ全体の更新をオーケストレートします。
  • アプリケーションの可用性を維持するために、データベース・サービスの再配置を制御します。

  アウトオブプレースのソフトウェア更新は、Oracle Enterprise Manager Cloud Controlでもサポートされています。

  フリート・パッチ適用およびプロビジョニングまたはOracle Enterprise Manager Cloud Controlのないアウトオブプレースのソフトウェア更新は、My Oracle Supportのドキュメント2087150.1に従って行うことができます。

OJVM更新

OJVM更新は、OJVMのセキュリティ脆弱性に対処するデータベース・ホーム用の個別のソフトウェア更新です。標準ソフトウェア更新とは別にインストールされます。OJVM更新は、特定の状況でローリング形式でインストールできます。

新しいリリースへの更新

Oracle Grid InfrastructureまたはOracle Databaseの上位リリースに更新するには、My Oracle Supportのステップバイステップのリリース手順に従ってください。

8.3.7 ソフトウェア更新実行時のsudoの使用

dbnodeupdate.shおよびpatchmgr (およびdbnodeupdateオーケストレーション)の実行時には、sudoを使用できます。

• sudoによるpatchmgr (およびdbnodeupdateオーケストレーション)の実行
  sudoを使用してpatchmgr (dbserver.patch.zipにパッケージされている)を実行することにより、セルのパッチ適用、RDMAネットワーク・ファブリックスイッチのパッチ適用、dbnodeupdate.shの実行のオーケストレーションなど、patchmgrの任意の機能を実行できます。
• sudoによるdbnodeupdate.shの実行
  sudoを使用してdbnodeupdate.shを使用する前に、/etc/sudoersファイルを構成します。

8.3.7.1 sudoによるpatchmgr (およびdbnodeupdateオーケストレーション)の実行

sudoを使用してpatchmgr (dbserver.patch.zipにパッケージされている)を実行することにより、セルのパッチ適用、RDMAネットワーク・ファブリックスイッチのパッチ適用、dbnodeupdate.shの実行のオーケストレーションなど、patchmgrの任意の機能を実行できます。

patchmgrはdbserver.patch.zipにパッケージ化されています。sudoを使用してpatchmgrを実行するために/etc/sudoersファイルを設定するには、次のステップを実行します。

1. rootユーザーとしてログインし、visudoを使用して/etc/sudoersを編集します。

   # visudo

2. oracleユーザーなどroot以外のユーザーが、patchmgrをrootとして実行できるように、sudoersファイルの最後に次のエントリを追加します。

   ノート:

   行の最初のフィールドは、patchmgrコマンドのsudoアクセス権が付与される非rootユーザーを指定します。次の行では、oracleユーザーを例として使用しています。必要に応じて、異なるユーザーを指定できます。

   oracle  ALL=(ALL)    NOPASSWD:SETENV: /u01/stage/patch/dbserverpatch/patchmgr
   

3. rootとして、/u01/stage/patch/dbserverpatchディレクトリを作成し、dbserver.patch.zipを解凍します。

   # mkdir -p /u01/stage/patch/dbserverpatch/
   # cp dbserver.patch.zip /u01/stage/patch/dbserverpatch/
   # cd /u01/stage/patch/dbserverpatch/
   # unzip dbserver.patch.zip
   

4. /u01/stage/patch/dbserverpatch/dbserver_patch_x.yymmddディレクトリ下のすべてを、/u01/stage/patch/dbserverpatch/に移動します。

   # mv /u01/stage/patch/dbserverpatch/dbserver_patch_x.yymmdd/* /u01/stage/patch/dbserverpatch/
   

ノート:

• patchmgrは、sudoを使用して実行する場合でも、更新されるすべてのデータベース・ノードのroot SSH等価を要求します。
• 前述の設定では、/u01/stage/patch/dbserverpatchのすべての内容がrootによって所有されている必要があります。
• dbserver.patch.zipを更新する場合は、新しいバージョンをsudoersで指定した同じ場所に配置する必要があります。

正しく設定されたかどうかを確認するために、oracleユーザーとして前提条件チェック・モードでpatchmgrを実行します。

[oracle]$ cd /u01/stage/patch/dbserverpatch/

[oracle]$ sudo ./patchmgr --dbnodes dbgroup --precheck     \
  --repo http://my-yum-repo/yum/EngineeredSystems/exadata/dbserver/23.1.8.0.0/base/x86_64/  \
  --target_version 23.1.8.0.0.231109

8.3.7.2 sudoによるdbnodeupdate.shの実行

sudoを使用してdbnodeupdate.shを使用する前に、/etc/sudoersファイルを構成します。

1. rootユーザーとしてログインし、visudoを使用して/etc/sudoersを編集します。

   # visudo

2. oracleユーザーなどのroot以外のユーザーが、dbnodeupdate.shをrootとして実行できるように、sudoersファイルの最後に、次のエントリを(すべてを1行で)追加します。

   ノート:

   行の最初のフィールドは、dbnodeupdate.shコマンドのsudoアクセス権が付与される非rootユーザーを指定します。次の行では、oracleユーザーを例として使用しています。必要に応じて、異なるユーザーを指定できます。

   oracle  ALL=(ALL)    NOPASSWD:SETENV: /u01/stage/patch/dbnodeupdate/dbnodeupdate.sh
   

3. rootとして、/u01/stage/patch/dbnodeupdateディレクトリを作成し、dbnodeupdate.zipを解凍します。

   # mkdir -p /u01/stage/patch/dbnodeupdate
   # cp dbnodeupdate.zip /u01/stage/patch/dbnodeupdate
   # cd /u01/stage/patch/dbnodeupdate
   # unzip dbnodeupdate.zip
   

正しく設定されたかどうかを確認するために、oracleユーザーとして前提条件チェック・モードでdbnodeupdate.shを実行します。

[oracle]$ cd /u01/stage/patch/dbnodeupdate

[oracle]$ sudo ./dbnodeupdate.sh -u -l http://my-yum-repo/yum/EngineeredSystems/exadata/dbserver/12.1.2.1.3/base/x86_64/ -v

dbnodeupdateは、root権限なしで実行された場合に終了します。

ノート:

• 前述の設定では、/u01/stage/patch/dbnodeupdateのすべてがrootによって所有されている必要があります。
• dbnodeupdateユーティリティを更新する場合は、新しいバージョンをsudoersで指定した同じ場所に配置する必要があります。

8.4 Exadata Patchmgr更新ユーティリティ

Patchmgrは、Exadataインフラストラクチャ・コンポーネントのソフトウェアの更新に使用されるユーティリティです。

• Exadata Patchmgr更新ユーティリティについて
  Patchmgrは、ソフトウェアの更新処理を簡単にするためのものです。
• patchmgrの取得
  patchmgrユーティリティはMy Oracle Supportからダウンロードできます。
• patchmgrの構文
  patchmgrは、Oracle Exadataインフラストラクチャ・コンポーネントのソフトウェアの更新に使用されるユーティリティです。

8.4.1 Exadata Patchmgr更新ユーティリティについて

Patchmgrは、ソフトウェアの更新処理を簡単にするためのものです。

Patchmgrには次の機能があります。

• 1回の起動で、Oracle Exadataのすべてのストレージ・サーバー、データベース・サーバーまたはRDMAネットワーク・ファブリック・スイッチを更新します。

• ローリング更新の実行時に、一度にコンポーネント1つずつ、ソフトウェア更新をオーケストレートします。

• 非ローリング更新の実行時に、同時にすべてのコンポーネントへのソフトウェア更新をパラレル化します。

• 必要に応じて、すべてのコンポーネント・ソフトウェア(ファームウェア、オペレーティング・システムおよびOracle Exadata System Softwareなど)を更新します。

  • データベース・サーバーには、Oracle Databaseの実行に必要なすべてのソフトウェアが含まれており、Oracle Databaseを最適に実行するように構成されます。ただし、サイト固有の追加のソフトウェア(モニタリング・エージェントやバックアップ・エージェントなど)の手動インストールが必要になる場合があります。データベース・サーバーの手動カスタマイズはサポートされていますが、パッケージを追加または更新することによってオペレーティング・システムをカスタマイズすると、今後patchmgrを使用してOracle Exadata System Software更新を適用するときに、追加のアクションが必要になることがあります。

  • Oracle Exadataドキュメントに目的の変更の実行ステップが記載されていない場合、ストレージ・サーバーまたはRDMAネットワーク・ファブリック・スイッチの構成、またはインストール済ソフトウェアは手動で変更(patchmgrを使用せずに更新)できない可能性があります。

• Patchmgrは、Oracle Linuxを実行しているエンジニアド・システムのrootユーザーまたはroot以外のユーザーとして実行できます。

• patchmgrの複数の起動は、同じソフトウェア・ディレクトリから実行できます。

データベース・サーバーを更新する場合、patchmgrは必要に応じて次を管理します。

• データベースとクラスタウェアの停止および起動
• ユーザー・ドメインの停止および起動(domU)
• Oracle Enterprise Manager Cloud Controlエージェントの停止および起動
• リモート・ネットワーク・マウントのアンマウント
• ロールバックに使用できるルート・ファイル・システムのオペレーティング・システムのバックアップの実行
• データベース・ホームとOracle Grid Infrastructureホーム・バイナリの再リンク
• 既知の問題の更新されたベスト・プラクティス構成の変更および回避策の適用

8.4.2 patchmgrの取得

patchmgrユーティリティはMy Oracle Supportからダウンロードできます。

Oracle Exadata System Softwareリリース19.3.0より前のサーバーとRDMAネットワーク・ファブリック・スイッチ更新には、Oracle Exadata System Softwareリリースにバンドルされているバージョンのpatchmgrを使用します。

Oracle Exadata System Softwareリリース19.3.0以降では、サーバーとRDMAネットワーク・ファブリック・スイッチ用に別々のpatchmgrディストリビューションがあります。

デフォルトでは、関連するサーバーまたはスイッチの更新に適切なpatchmgrディストリビューションが含まれています。ただし、Oracle Exadataサーバーまたはスイッチを更新する際には、常にMy Oracle Supportから最新のpatchmgrを使用することをお薦めします。patchmgrユーティリティは既知の問題およびベスト・プラクティスに対処し、新しいハードウェアをサポートするために頻繁に更新されます。My Oracle Supportのドキュメント888828.1を参照してください。

8.4.3 patchmgrの構文

patchmgrは、Oracle Exadataインフラストラクチャ・コンポーネントのソフトウェアの更新に使用されるユーティリティです。

前提条件

Patchmgrは、Oracle Linuxを実行しているOracle Exadataデータベース・サーバーまたはOracle Exadata以外のシステムである駆動システムで実行されます。これにより、中央のサーバーからpatchmgrを実行して、複数のOracle Exadataシステムを更新できます。patchmgrがOracle Exadataデータベース・サーバーから実行される場合、patchmgrに提供されるグループ・ファイルにそのデータベース・サーバーを含めることはできません。

構文

Patchmgr構文は、更新するコンポーネントによって異なりますが、一般的なpatchmgr構文は次のとおりです。

./patchmgr -component component_list_file -action required_arguments [optional_arguments]

オプション

オプション	説明
component	更新するコンポーネントを表します。有効な値は、-cells、-dbnodes、-ibswitchesまたは-roceswitchesです
component_list_file	更新するコンポーネントのホスト名を含むテキスト・ファイル。たとえば、Oracle Exadataのストレージ・サーバーを更新(-cellsを使用)する場合は、component_list_fileにストレージ・サーバーのすべてのホスト名のリストを含めます。
action	実行する操作。ほとんどの場合、アクションは更新されるコンポーネントに固有です。
required_arguments	特定のアクションに必要な追加引数。
optional_arguments	特定のアクションに必要なオプション引数。

使用上のノート

• Oracle Exadata System Softwareリリース19.3以降では、オプションの先頭に--を付けます。このリリースより前のリリースでは、オプションの先頭に-を付けました。

• patchmgrの複数の起動は、-log_dirオプションを使用して同じソフトウェア・ディレクトリから同時に実行できます。これにより、patchmgrは、複数のOracle Exadataシステムを同じソフトウェア・ディレクトリから同時に更新できます。

• Patchmgrは、rootユーザーとしてもroot以外のユーザーとしても実行できます。patchmgrをroot以外のユーザーとして実行するには、-log_dirオプションを使用する必要があります。

• patchmgrを実行しているユーザーは、patchmgrが更新するサーバーまたはスイッチへのrootレベルのSSH等価が構成されている必要があります。SSH等価は双方向である必要があります。つまり、patchmgrを実行するユーザーは、パスワードなしでSSHを使用してrootユーザーとしてターゲット・サーバーまたはスイッチにアクセスできる必要があり、ターゲット・サーバーまたはスイッチのrootユーザーは、パスワードなしでSSHを使用して、patchmgrを実行するユーザーとして駆動システムにアクセスできる必要があります。

• 以前のリリースでは、dbnodeupdate.shユーティリティを使用してデータベース・サーバーを更新していました。dbnodeupdate.shはpatchmgrと統合され、patchmgrに置き換えられています。

• ストレージ・サーバーのpatchmgr構文
  patchmgrを使用して、Oracle Exadataストレージ・サーバーのソフトウェアを更新できます。
• データベース・サーバーのpatchmgr構文
  patchmgrを使用して、Oracle Exadataデータベース・サーバーのソフトウェアを更新できます。
• RoCEネットワーク・ファブリック・スイッチのpatchmgr構文
  patchmgrを使用して、RoCEネットワーク・ファブリック・スイッチのソフトウェアを更新できます。
• InfiniBandネットワーク・ファブリック・スイッチのpatchmgr構文
  patchmgrを使用して、InfiniBandネットワーク・ファブリック・スイッチのソフトウェアを更新できます。
• 管理ネットワーク・スイッチのpatchmgr構文
  patchmgrを使用して、Oracle Exadata Database Machine X7-2以降のシステムにある9000シリーズの管理ネットワーク・スイッチでファームウェア・アップグレードを実行できます。

8.4.3.1 ストレージ・サーバーのpatchmgr構文

patchmgrを使用して、Oracle Exadataストレージ・サーバーのソフトウェアを更新できます。

前提条件

patchmgrは、Oracle Linuxを実行しているOracle Exadataデータベース・サーバーまたはOracle Exadata以外のシステムである駆動システムで実行されます。これにより、中央のサーバーからpatchmgrを実行して、複数のOracle Exadataシステムを更新できます

ストレージ・サーバーのpatchmgr構文

./patchmgr --cells cell_host_file 
{ { --patch_check_prereq | --rollback_check_prereq } [--rolling] [--unkey] [--ignore_alerts] [--ignore_date_validations] | 
  { --patch | --rollback } [--rolling] [--unkey] [--ignore_alerts] | 
  --cleanup [--unkey] }
[ --log_dir { log_directory | auto } ]

メイン引数

引数	説明
--cells cell_host_file	cell_host_fileは、更新するストレージ・サーバーのホスト名を含むテキスト・ファイルです。ファイルには、1行に1つのストレージ・サーバー・ホスト名またはIPアドレスが含まれます。リスト・ファイルが指定されていない場合、ストレージ・サーバーのパッチ適用は失敗します。
--patch	可能な場合はファームウェアの更新(BIOS、ディスク・コントローラ、可能な場合はディスク・ドライブ)を含むパッチをストレージ・サーバー・リスト・ファイル内のすべてのストレージ・サーバーに適用します。
--rollback	パッチをロールバックします。
--cleanup	すべてのストレージ・サーバーですべてのパッチ・ファイルおよび一時コンテンツをクリーン・アップします。クリーン・アップする前に、問題の診断および分析用のログと情報を収集します。パッチが失敗した場合は、各ストレージ・サーバーのディレクトリ/root/_cellupd_dpullec_を削除することにより、パッチ・ファイルのクリーン・アップを手動で実行できます。

サポートされているオプション

ストレージ・サーバーのパッチ適用およびロールバックでは、次のオプションがサポートされています。

表8-2 ストレージ・サーバーのpatchmgrオプション

オプション	説明
--get property	特定のプロパティに関する情報を取得します。プロパティは、log_dirに設定できます。これは、すべてのログ・ファイルに割り当てられたディレクトリです。
--ignore_alerts	Exadataストレージ・サーバーのアクティブ・ハードウェア・アラートを無視し、パッチ適用を続行します。
--ignore_date_validations	日付バージョン検証を無視します。これにより、日付スタンプを以前の最新のリリースにアップグレードできます。たとえば、19.1.2.0.0.190306から19.2.0.0.0.190225にアップグレードする場合です。
--log_dir ( log_directory| auto )	ログ・ディレクトリへの絶対パスを指定するか、またはautoを指定して、起動ディレクトリおよびノード・リスト・ファイルのコンテンツに基づくログ・ディレクトリを使用できます。 -log_dirオプションを指定すると、複数のパッチ・マネージャ呼出しを実行することも、root以外のユーザーとしてパッチ・マネージャを実行することもできます。
--patch_check_prereq	すべてのストレージ・サーバーで前提条件チェックを実行して、パッチをストレージ・サーバーに適用できるかどうかを判断します。
--rollback_check_prereq	すべてのストレージ・サーバーで前提条件チェックを実行して、ストレージ・サーバーをこの特定のパッチに対してロールバックできるかどうかを判断します。
--rolling	ローリング方式で更新を実行することを指定します。指定しない場合、更新は非ローリング方式で実行されます。 環境変数EXA_PATCH_ACTIVATE_TIMEOUT_SECONDSは、グリッド・ディスクがアクティブ化されるまで待機するタイムアウト値を制御します。デフォルトでは36000 (10時間)に設定されます。 ノート: -rollingオプションが指定されている場合でも、常に非ローリング方式で前提条件チェックとクリーン・アップが実行されます。
--smtp_from "email_addr"	patchmgr通知の送信元(from)の電子メール・アドレスを指定します。
--smtp_to "email_addr1 email_addr2 email_addr3 ..."	patchmgr通知の送信先(to)の電子メール・アドレスを指定します。
--smtp_set_envelope_sender	「Return-Path:」メール・ヘッダーと同じ送信元(from)アドレスが使用されることを指定します。
--unkey	終了する前にセルへのパスワードなしのSSHアクセスを削除します。

使用上のノート

• Oracle Exadata System Softwareリリース19.3以降では、オプションの先頭に--を付けます。このリリースより前のリリースでは、オプションの先頭に-を付けました。
• patchmgrの複数の起動は、--log_dirオプションを使用して同じソフトウェア・ディレクトリから同時に実行できます。これにより、patchmgrは、複数のOracle Exadataシステムを同じソフトウェア・ディレクトリから同時に更新できます。

• Patchmgrは、rootユーザーとしてもroot以外のユーザーとしても実行できます。patchmgrを実行しているユーザーは、patchmgrが更新するサーバーまたはスイッチへのrootレベルのSSH等価が構成されている必要があります。patchmgrをroot以外のユーザーとして実行するには、-log_dirオプションを使用する必要があります。

例8-4 ストレージ・サーバー更新の前提条件チェックの実行後のストレージ・サーバーの更新

./patchmgr -cells cell_group -patch_check_prereq 
./patchmgr -cells cell_group -patch

例8-5 ローリング形式でのストレージ・サーバーの更新

次のコマンドは、ストレージ・サーバーをローリング形式で更新し、更新が進むと電子メール通知を受信し、更新が完了した後にセルへのパスワードなしのSSHアクセスを削除します。

./patchmgr -cells cell_group -patch -rolling -unkey -smtp_from "[e-mail]" -smtp_to "[e-mail],[e-mail]"

例8-6 複数のストレージ・サーバーの一度での更新

次のコマンドは、3つのOracle Exadataシステム上のストレージ・サーバーを同じソフトウェア・ディレクトリから同時に更新します。1つはローリング更新を使用する更新、その他の更新は非ローリングです。

この例では、次のようになります。

• 各patchmgrコマンドは、別々の端末のウィンドウから実行する必要があります。
• patchmgrの各実行では、component_list_fileの内容に基づいて自動的に生成される一意のロギング・ディレクトリ名が使用されます。

(terminal1) ./patchmgr -cells cell_group_exa01 -patch -rolling -log_dir auto 
(terminal2) ./patchmgr -cells cell_group_exa02 -patch -log_dir auto 
(terminal3) ./patchmgr -cells cell_group_exa03 -patch -log_dir auto

後続のpatchmgrの実行で、異なる内容の変更された component_list_fileを使用するが、以前のpatchmgrの実行と同じロギング・ディレクトリを使用するには、-get log_dirオプションを使用してロギング・ディレクトリを取得します。たとえば:

1. 最初のpatchmgrの実行のロギング・ディレクトリは、自動的に生成されます。

   ./patchmgr -cells cell_group -patch -log_dir auto

2. 最後のセルが更新に失敗し、patchmgrが最初のpatchmgrの実行と同じロギング・ディレクトリを使用して、最後のセルに対してのみ再実行されると仮定します。-get log_dirオプションを使用し、元のcomponent_list_fileを使用してロギング・ディレクトリを取得します。

   ./patchmgr -cells cell_group -patch -log_dir auto -get log_dir log_dir=/tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee

3. 最後のセルのみを含むようにcell_groupファイルを更新するか、最後のセルのみを含む別のファイルを使用します。最初のpatchmgrの実行からロギング・ディレクトリを指定すると、このセルのグループのすべてのログが同じロギング・ディレクトリに作成されます。

   ./patchmgr -cells cell_group -patch -log_dir /tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee

8.4.3.2 データベース・サーバーのpatchmgr構文

patchmgrを使用して、Oracle Exadataデータベース・サーバーのソフトウェアを更新できます。

前提条件

patchmgrは、Oracle Linuxを実行しているOracle Exadataデータベース・サーバーまたはOracle Exadata以外のシステムである駆動システムで実行されます。これにより、中央のサーバーからpatchmgrを実行して、複数のOracle Exadataシステムを更新できます。patchmgrがOracle Exadataデータベース・サーバーから実行される場合、そのデータベース・サーバーはパッチを適用するサーバーをリストしたファイルには含まれません。

データベース・サーバーのpatchmgr構文

./patchmgr --dbnodes database_node_file
{ --backup --repo { base_URL | zipped_iso_file } [--rolling] [--unkey] |
  --precheck --repo { base_URL | zipped_iso_file } --target_version version [--unkey] |
  --upgrade --repo { base_URL | zipped_iso_file } --target_version version [--rolling] [--unkey] | 
  --complete [ --target_version version ] [--unkey] |
  --rollback [--rolling] [--unkey] |
  --cleanup  [--unkey] }
[ --log_dir { log_directory | auto } ]

メイン引数

引数	説明
--dbnodes database_node_file	database_node_fileは、更新するデータベース・サーバーのホスト名を含むテキスト・ファイルです。ファイルには、1行に1つのデータベース・サーバー・ホスト名またはIPアドレスが含まれます。リスト・ファイルが指定されていない場合、データベース・サーバーのパッチ適用は失敗します。
--backup	ホスト・リストに指定されたデータベース・ノードのバックアップを実行します。--rollingオプションが指定されていないかぎり、非ローリング方式でバックアップを実行します。
--precheck	ホスト・リストで指定されたデータベース・ノードでアップグレード前の検証チェックを非ローリング方式で実行します。
--upgrade	ホスト・ファイルに指定されたデータベース・ノードをアップグレードします。--rollingオプションが指定されていないかぎり、非ローリング方式でアップグレードを実行します。
--complete	「完了ステップ」のみを実行します。通常、これはすでに--upgradeの一部として実行されているため、これを別々に実行する必要はありません。ノート: データベース・スタックまたはユーザー・ドメインが起動している場合、それを停止して再起動します。
--rollback	ホスト・ファイルに指定されたデータベース・ノードをロールバックします。--rollingオプションが指定されていないかぎり、非ローリング方式でロールバックを実行します。
--cleanup	非ローリング方式で、ホスト・リストに指定されたデータベース・サーバーのすべての一時コンテンツをクリーン・アップします。

サポートされているオプション

ストレージ・サーバーのパッチ適用およびロールバックでは、次のオプションがサポートされています。

表8-3 データベース・サーバーのpatchmgrオプション

オプション	説明
--allow_active_network_mounts	アクティブなNFSまたはSMBマウントを使用してdbnodeupdateを実行することを許可します。 これはdbnodeupdate.sh -aコマンドと同等です。
--allow_non_signed_repo	署名されていないリポジトリでのdbnodeupdateの実行を許可します。(Oracle Exadata System Softwareリリース19.2以降)
--dbnode_patch_base	パッチISOイメージとdbnodeupdateアーカイブ・ファイルが解凍されるターゲット・データベース・サーバー上のユーザーの推奨の場所。 ノート: 提供された場所はローカル・ファイル・システムの絶対パスである必要があり、十分な空き領域およびinodeが必要です。
--force_remove_custom_rpms	データベース・サーバーのアップグレードに主要なオペレーティング・システムのアップグレードが含まれている場合は、カスタムRPMを削除します。たとえば、Oracle Linux 7からOracle Linux 8へのアップグレードです。
--ignore_alerts	Exadataサーバーのアクティブ・ハードウェア・アラートを無視し、パッチ適用を続行します。
--log_dir ( log_directory| auto )	ログ・ディレクトリへの絶対パス、またはautoを指定して、patchmgrの起動ディレクトリおよびノード・リスト・ファイルのコンテンツに基づくログ・ディレクトリを使用できます。 --log_dirオプションを指定すると、複数のパッチ・マネージャ呼出しを実行することも、root以外のユーザーとしてパッチ・マネージャを実行することもできます。
--no_connection_draining	以前は高速ホーム・プロビジョニング(RHP)と呼ばれていたフリート・パッチ適用およびプロビジョニングのデータベース接続の排出を無効にします。接続排出の可用性は、Oracle Grid Infrastructureのリリースによって決まります。このオプションは、ローリング更新にのみ適用されます。
--nobackup	アップグレードの前にデータベース・サーバーをバックアップしないでください。
--repo { base_URL | zipped_iso_file }	Exadata更新リポジトリのベースURLまたは圧縮されたISOファイルへのパスを指定します。 このオプションは、--backup、--precheckおよび--upgradeアクションに指定する必要があります。
--rolling	更新が一度に1つのサーバーのローリング方式で実行されるよう指定します。指定しない場合、更新は非ローリング方式で実行されます。 環境変数EXA_PATCH_ACTIVATE_TIMEOUT_SECONDSは、グリッド・ディスクがアクティブ化されるまで待機するタイムアウト値を制御します。デフォルトでは36000 (10時間)に設定されます。 ノート: -rollingオプションが指定されている場合でも、常に非ローリング方式で前提条件チェックとクリーン・アップが実行されます。
--rolling_backups	各ノードを更新する前にローリング方式でバックアップするようpatchmgrに指示します。このオプションが指定されていない場合(デフォルト)、patchmgrは最初のノードを更新する前に、すべてのノードのバックアップをパラレルに完了します。 このオプションは--rollingオプションと一緒にのみ使用できます。それ以外の場合、このオプションは無視され、デフォルトのバックアップ方法が使用されます。 --nobackupがコマンドに含まれている場合、このオプションは無視されます。
--skip_gi_db_validation	Oracle Grid InfrastructureおよびOracle DatabaseホームとOracle Linux 7との互換性の動作保証をスキップします。 Oracle Linux 6からOracle Linux 7へのアップグレードの場合のみ。
--smtp_from "email_addr"	patchmgr通知の送信元(from)の電子メール・アドレスを指定します。
--smtp_to "email_addr1 email_addr2 email_addr3 ..."	patchmgr通知の送信先(to)の電子メール・アドレスを指定します。
--smtp_set_envelope_sender	「Return-Path:」メール・ヘッダーと同じ送信元(from)アドレスが使用されることを指定します。
--target_version version	パッチのREADMEファイルに指定されている完全パッチ・バージョン。たとえば、次のようになります: 23.1.8.0.0.231109 このオプションは、--precheckおよび--upgradeアクションに指定する必要があります。
--unkey	終了する前にサーバーへのパスワードなしのSSHアクセスを削除します。

例

例8-7 データベース・サーバーのバックアップ後の更新の実行

次のコマンドは、Oracle Exadataデータベース・サーバーをバックアップし、データベース・サーバー更新の前提条件チェックを実行し、データベース・サーバーをローリング形式で更新します。

[root@pmserver ~]# ./patchmgr --dbnodes dbnode_group --backup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109

[root@pmserver ~]# ./patchmgr --dbnodes dbnode_group --precheck --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109

[root@pmserver ~]# ./patchmgr --dbnodes dbnode_group --upgrade --nobackup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109 --rolling

8.4.3.3 RoCEネットワーク・ファブリック・スイッチのpatchmgr構文

patchmgrを使用して、RoCEネットワーク・ファブリック・スイッチのソフトウェアを更新できます。

前提条件

patchmgrは、Oracle Linuxを実行しているOracle Exadataデータベース・サーバーまたはOracle Exadata以外のシステムである駆動システムで実行されます。これにより、中央のサーバーからpatchmgrを実行して、複数のOracle Exadataシステムを更新できます。

ノート:

Oracle Exadata System Softwareリリース19.3.9より前では、RoCEネットワーク・ファブリック・スイッチにパッチを適用するために、非rootユーザーとしてpatchmgrを実行する必要があります。

RoCEネットワーク・ファブリック・スイッチのpatchmgr構文

./patchmgr --roceswitches [roceswitch_list_file] 
    { --upgrade [--roceswitch-precheck] [--unkey] [--force] |
      --downgrade [--roceswitch-precheck] [--unkey] [--force] |
      --apply-config [--unkey] [--force] |
      --verify-config [ --newswitchlist new_list_file ] [--unkey] }
    [ -log_dir { absolute_path_to_log_directory | AUTO } ]

メイン引数

引数	説明
--roceswitches [roceswitch_list_file]	patchmgrがRoCEネットワーク・ファブリック・スイッチで機能することを指定します。 指定すると、スイッチのリスト・ファイルでRoCEネットワーク・ファブリック・スイッチが指定されます。 最も簡単な形式では、ファイルの各行には、1つのスイッチのホスト名またはIPアドレスが記載されています。この場合、各スイッチはシングルラックExadata環境のリーフ・スイッチと見なされます。たとえば: rack1sw-rocea0 rack1sw-roceb0 各スイッチの構成タイプを指定するには、スイッチのリスト・ファイルで各スイッチのホスト名またはIPアドレスにコロン(:)とタグを付けます。次のタグがサポートされます。 leaf - シングル・ラック・システムのリーフ・スイッチを示します。タグが指定されていない場合、この構成タイプであると見なされます。 mspine - スパイン・スイッチを示します。1つのスパイン・スイッチ構成では、Exadata Secure RDMA Fabric Isolationがある場合とない場合の、シングル・ラック・システムとマルチラック・システムのすべてのスパイン・スイッチがサポートされます。 mleaf - マルチラックX8Mシステムのリーフ・スイッチを示します。 sfleaf - Exadata Secure RDMA Fabric Isolationのサポートが有効なシングル・ラック・システムのリーフ・スイッチを示します。 msfleaf - Exadata Secure RDMA Fabric Isolationのサポートが有効なマルチラックX8Mシステムのリーフ・スイッチを示します。 leaf23 - 23個のホスト・ポートを持つように構成されたシングル・ラック・システムのリーフ・スイッチを示します。この構成は、3つのデータベース・サーバーと11個のストレージ・サーバーを持つ8ソケット・システム(X8M-8以降)にのみ必要です。 mleaf23 - 23個のホスト・ポートを持つように構成されたマルチラック・システムのリーフ・スイッチを示します。この構成は、3つのデータベース・サーバーと11個のストレージ・サーバーを持つ8ソケットX8M-8システムにのみ必要です。 mleaf_u14 - 14個のスイッチ間リンクで構成されたマルチラック・システムのリーフ・スイッチを示します。これはX9M以降のモデル・システムの一般的なマルチラック・リーフ・スイッチ構成です。 msfleaf_u14 - Exadata Secure RDMA Fabric Isolationのサポートが有効になっている、14個のスイッチ間リンクで構成されたマルチラック・システムのリーフ・スイッチを示します。この構成は、Secure Fabricが有効になっているX9M以降のモデル・システムに必要です。 mleaf23_u13 - 23個のホスト・ポートと13個のスイッチ間リンクで構成されたマルチラック・システムのリーフ・スイッチを示します。この構成は、3つのデータベース・サーバーと11個のストレージ・サーバーを持つ8ソケットX9M-8システムにのみ必要です。 たとえば: rack1sw-rocea0:leaf rack1sw-roceb0:leaf マルチラック構成の場合のみ、各スイッチに一意のループバック・オクテットも指定します。 ループバック・オクテットは、スイッチを一意に識別するスイッチ・ループバック・アドレスの最後のオクテットです。 各スイッチのループバック・オクテットを指定するには、ピリオド(.)と数値のループバック・オクテット値を、スイッチのリスト・ファイルのタグが付けられた各スイッチのエントリに追加します。 注意: マルチラック構成のすべてのスイッチには、一意のループバック・オクテットが必要です。複数のスイッチが同じループバック・オクテットを使用すると、RoCEネットワーク・ファブリックは正しく機能しないため、システムが停止します。 リーフ・スイッチの場合、最初のループバック・オクテット値として101から開始し、次のように増分します: 101 - ラック1の下位リーフ・スイッチ(次の例ではrack1sw-rocea0) 102 - ラック1の上位リーフ・スイッチ(次の例ではrack1sw-roceb0) 103 - ラック2の下位リーフ・スイッチ(次の例ではrack2sw-rocea0) 104 - ラック2の上位リーフ・スイッチ(次の例ではrack2sw-roceb0) 105 - ラック3の下位リーフ・スイッチ 106 - ラック3の上位リーフ・スイッチなど。 スパイン・スイッチの場合、最初のループバック・オクテット値として201から開始し、次のように増分します: 201 - ラック1のスパイン・スイッチ(次の例ではrack1sw-roces0) 202 - ラック2のスパイン・スイッチ(次の例ではrack2sw-roces0) 203 - ラック3のスパイン・スイッチ 204 - ラック4のスパイン・スイッチなど。 たとえば、2ラックExadata X9Mシステムのスイッチのリスト・ファイルの内容は、次のようになります: rack1sw-rocea0:mleaf_u14.101 rack1sw-roceb0:mleaf_u14.102 rack1sw-roces0:mspine.201 rack2sw-rocea0:mleaf_u14.103 rack2sw-roceb0:mleaf_u14.104 rack2sw-roces0:mspine.202 ファイル名を指定しない場合、このコマンドは、patchmgrを実行しているホストから検出されたすべてのRoCEネットワーク・ファブリック・スイッチで機能します。
--upgrade	RoCEネットワーク・ファブリック・スイッチのファームウェアをアップグレードします。 必要に応じて、スイッチ・アラートをOracle Auto Service Request (ASR)に伝播するクライアント・ソフトウェア・コンポーネントもインストールまたはアップグレードします。 ノート: 2022年8月のpatchmgrリリース以降、patchmgrはRoCEネットワーク・ファブリックで追加の一連のチェックを実行します。これらのチェックは、ファームウェア・アップグレードの直前および--roceswitch-precheckオプションを使用した前提条件チェック時に行われます。これらのチェックにより、RoCEネットワーク・ファブリックの予期しない問題に関連する障害のリスクが軽減されます。たとえば、ストレージ・サーバー上のRoCEネットワーク・ファブリック・ポートのいずれかが停止している場合、唯一の動作可能なポートに接続されているスイッチがアップグレードのためにオフラインになると、ストレージ・サーバーは使用できなくなります。チェックが失敗した場合、patchmgrは問題を報告し、ただちに終了します。この場合、アップグレードを実行する前に、RoCEネットワーク・ファブリックの問題を修正する必要があります。
--downgrade	RoCEネットワーク・ファブリック・スイッチのファームウェアをダウングレードします。 ノート: 2022年8月のpatchmgrリリース以降、patchmgrはRoCEネットワーク・ファブリックで追加の一連のチェックを実行します。これらのチェックは、ファームウェア・ダウングレードの直前および--roceswitch-precheckオプションを使用した前提条件チェック時に行われます。これらのチェックにより、RoCEネットワーク・ファブリックの予期しない問題に関連する障害のリスクが軽減されます。たとえば、ストレージ・サーバー上のRoCEネットワーク・ファブリック・ポートのいずれかが停止している場合、唯一の動作可能なポートに接続されているスイッチがアップグレードのためにオフラインになると、ストレージ・サーバーは使用できなくなります。チェックが失敗した場合、patchmgrは問題を報告し、ただちに終了します。この場合、ダウングレードを実行する前に、RoCEネットワーク・ファブリックの問題を修正する必要があります。
--apply-config	各スイッチにゴールデン構成テンプレートを適用します。 このオプションは、スイッチごとの構成タイプを指定するスイッチのリスト・ファイル内のタグに依存します。
--verify-config [ --newswitchlist new_list_file ]	各スイッチ構成をゴールデン構成に対して検証します。 検証は、--upgradeまたは--downgradeを使用するときに自動的に実行されます。このオプションを使用して、スタンドアロン操作として検証を実行できます。 指定した場合、--newswitchlistオプションによって、各スイッチの現在の構成に一致するエントリを含む、新しいスイッチのリスト・ファイルが生成されます。

サポートされているオプション

次のオプションは、RoCEネットワーク・ファブリック・スイッチの構成およびファームウェアの更新でサポートされています。

表8-4 RoCEネットワーク・ファブリック・スイッチのpatchmgrオプション

オプション	説明
--roceswitch-precheck	リスト・ファイル内のRoCEネットワーク・ファブリック・スイッチでスイッチ・ファームウェアのアップグレードまたはダウングレード・シミュレーションを実行しますが、実際のインストールは実行しません。このオプションは、--upgradeまたは--downgradeとともに使用します。
--unkey	このオプションを--upgradeまたは--downgradeと組み合せると、RoCEネットワーク・ファブリック・スイッチへのパスワードなしSSHアクセスを有効にする構成設定が削除されます。
--force	このオプションを--upgradeまたは--downgradeと組み合せると、スイッチがすでにターゲット・ファームウェア・バージョンにある場合や、RoCEネットワーク・ファブリック・スイッチに重大でない障害が発生している場合でも、アップグレードまたはダウングレードを続行します。 このオプションを--apply-configと組み合せると、現在のスイッチ構成がスイッチのリスト・ファイルで指定された構成タイプと一致するかどうかを判別するチェックがバイパスされます。
-log_dir ( absolute_path_to_log_directory | AUTO )	patchmgrをroot以外のユーザーとして実行する場合は、-log_dirを使用して、ログ・ディレクトリへの絶対パスを指定するか、キーワードAUTOを使用します。AUTOを指定すると、patchmgrによって、patchmgrの起動元ディレクトリとノード・リスト・ファイルのコンテンツに基づいて、ログ・ディレクトリへのパスが生成および設定されます。 ノート: -log_dirの指定は、root以外のユーザーとしてパッチ・マネージャを実行する場合に必要であり、これを指定することによって複数のパッチ・マネージャ呼出しが有効になります。

使用上のノート

• Oracle Exadata System Softwareリリース19.3以降では、オプションの先頭に--を付けます。このリリースより前のリリースでは、オプションの先頭に-を付けました。

例8-8 RoCEネットワーク・ファブリック・スイッチのファームウェアをアップグレードするためのpatchmgrの使用

この例では、すべての検出されたスイッチでアップグレードの前提条件チェックを実行してから、スイッチをアップグレードします。

$ ./patchmgr --roceswitches --upgrade --roceswitch-precheck

$ ./patchmgr --roceswitches --upgrade

例8-9 RoCEネットワーク・ファブリック・スイッチにゴールデン構成を適用するためのpatchmgrの使用

この例では、switches.lstファイルで指定されたとおりに、ゴールデン構成の設定をRoCEネットワーク・ファブリック・スイッチに適用します。この操作のログは/tmp/switchlogsに書き込まれます。

$ cat switches.lst
switch456-rocea0:leaf          
switch456-roceb0:leaf          

$ ./patchmgr --roceswitches switches.lst --apply-config –log_dir /tmp/switchlogs

8.4.3.4 InfiniBandネットワーク・ファブリック・スイッチのpatchmgr構文

patchmgrを使用して、InfiniBandネットワーク・ファブリック・スイッチのソフトウェアを更新できます。

前提条件

patchmgrは、Oracle Linuxを実行しているOracle Exadataデータベース・サーバーまたはOracle Exadata以外のシステムである駆動システムで実行されます。これにより、中央のサーバーからpatchmgrを実行して、複数のOracle Exadataシステムを更新できます。

InfiniBandネットワーク・ファブリック・スイッチのpatchmgr構文

./patchmgr --ibswitches [ibswitch_list_file]
{ --upgrade | --downgrade } [--ibswitch_precheck] [--unkey] [ --force [ yes | no ]]

メイン引数

引数	説明
--ibswitches ibswitch_list_file	InfiniBandネットワーク・ファブリック・スイッチのリスト・ファイルの名前を指定します。ファイルには1行に1つのスイッチのホスト名またはIPアドレスが記載されています。ファイル名が指定されていない場合は、このホストから検出されたすべてのInfiniBandネットワーク・ファブリック・スイッチでこのコマンドが実行されます。
--upgrade	リスト・ファイル内のInfiniBandネットワーク・ファブリック・スイッチを$EXADATA_IMAGE_IBSWITCH_UPGRADE_VERSIONにアップグレードします。
--downgrade	リスト・ファイル内のInfiniBandネットワーク・ファブリック・スイッチを$EXADATA_IMAGE_IBSWITCH_DOWNGRADE_VERSIONにダウングレードします。

サポートされているオプション

次のオプションは、InfiniBandネットワーク・ファブリック・スイッチの構成およびファームウェアの更新でサポートされています。

表8-5 InfiniBandネットワーク・ファブリック・スイッチのpatchmgrオプション

オプション	説明
--force [yes | no]	重要でない障害があってもアップグレードまたはダウングレードを続行するよう指定します。値yesは、自動回答プロンプトありで続行するように指定します。値noは、自動応答プロンプトなしで続行するよう指定します。デフォルト値はyesです。
--ibswitch_precheck	リスト・ファイル内のInfiniBandネットワーク・ファブリック・スイッチの更新前検証チェックを実行します。
--smtp_from "email_addr"	patchmgr通知の送信元(from)の電子メール・アドレスを指定します。
--smtp_to "email_addr1 email_addr2 email_addr3 ..."	patchmgr通知の送信先(to)の電子メール・アドレスを指定します。
--smtp_set_envelope_sender	「Return-Path:」メール・ヘッダーと同じ送信元(from)アドレスが使用されることを指定します。
--unkey	終了する前に、InfiniBandネットワーク・ファブリック・スイッチへのパスワードなしのSSHアクセスを削除します。

使用上のノート

• Oracle Exadata System Softwareリリース19.3以降では、オプションの先頭に--を付けます。このリリースより前のリリースでは、オプションの先頭に-を付けました。

例8-10 InfiniBandネットワーク・ファブリック・スイッチに対するpatchmgrの使用

この例では、すべてのスイッチで更新の前提条件チェックを実行してから、ib_groupファイルに指定されたスイッチをアップグレードします。

./patchmgr --ibswitches --upgrade --ibswitch_precheck 

./patchmgr --ibswitches ib_group --upgrade

8.4.3.5 管理ネットワーク・スイッチのpatchmgr構文

patchmgrを使用して、Oracle Exadata Database Machine X7-2以降のシステムにある9000シリーズの管理ネットワーク・スイッチでファームウェア・アップグレードを実行できます。

前提条件

patchmgrは、Oracle Linuxを実行しているOracle Exadataデータベース・サーバーまたはOracle Exadata以外のシステムである駆動システムで実行されます。これにより、中央のサーバーからpatchmgrを実行して、複数のOracle Exadataシステムを更新できます。

管理ネットワーク・スイッチのpatchmgr構文

./patchmgr --adminswitches [adminswitch_list_file]
{ --upgrade | --downgrade } [--adminswitch-precheck] [--unkey] [--force]
[ -log_dir { absolute_path_to_log_directory | AUTO } ]

メイン引数

引数	説明
--adminswitches [adminswitch_list_file]	patchmgrが管理ネットワーク・スイッチで機能することを指定します。 指定した場合、スイッチ・リスト・ファイルによって管理ネットワーク・スイッチが識別されます。ファイルの各行には、1つのスイッチのホスト名またはIPアドレスが記載されています。 ファイル名を指定しない場合、このコマンドは、patchmgrを実行しているホストから検出されたすべての管理ネットワーク・スイッチで機能します。
--upgrade	管理ネットワーク・スイッチのファームウェアをアップグレードします。
--downgrade	管理ネットワーク・スイッチのファームウェアをダウングレードします。

サポートされているオプション

管理ネットワーク・スイッチのファームウェア更新では、次のオプションがサポートされています。

表8-6 管理ネットワーク・スイッチのPatchmgrオプション

オプション	説明
--adminswitch-precheck	リスト・ファイル内の管理ネットワーク・スイッチでスイッチ・ファームウェアのアップグレードまたはダウングレード・シミュレーションを実行しますが、実際のインストールは実行しません。このオプションは、--upgradeまたは--downgradeとともに使用します。
--unkey	このオプションを--upgradeまたは--downgradeと組み合せると、管理ネットワーク・スイッチへのパスワードなしSSHアクセスを有効にする構成設定が削除されます。
--force	このオプションを--upgradeまたは--downgradeと組み合せると、スイッチがすでにターゲット・ファームウェア・バージョンにある場合や、管理ネットワーク・スイッチに重大でない障害が発生している場合でも、アップグレードまたはダウングレードを続行します。
-log_dir ( absolute_path_to_log_directory | AUTO )	patchmgrをroot以外のユーザーとして実行する場合は、-log_dirを使用して、ログ・ディレクトリへの絶対パスを指定するか、キーワードAUTOを使用します。AUTOを指定すると、patchmgrによって、patchmgrの起動元ディレクトリとスイッチ・リスト・ファイルのコンテンツに基づいて、ログ・ディレクトリへのパスが生成および設定されます。 ノート: -log_dirの指定は、root以外のユーザーとしてパッチ・マネージャを実行する場合に必要であり、これを指定することによって複数のパッチ・マネージャ呼出しが有効になります。

例8-11 管理ネットワーク・スイッチのファームウェアをアップグレードするためのpatchmgrの使用

この例では、switches.lstファイルで指定されたスイッチでアップグレード前提条件チェックを実行してから、スイッチをアップグレードします。

$ cat switches.lst
dbm0sw-adm0                  

$ ./patchmgr --adminswitches switches.lst --upgrade --adminswitch-precheck

$ ./patchmgr --adminswitches switches.lst --upgrade

8.5 Oracle Exadata Database Serverの更新

次の情報と手順を使用して、Oracle Exadataのデータベース・サーバーを更新します。

• Oracle Exadata Database Serverの更新の概要
  データベース・サーバーの更新時には、複数のソフトウェアを更新する必要があります。
• Oracle以外のソフトウェアのインストール、更新および管理
  Oracle Exadataデータベース・サーバーへのOracleブランド以外のRPMのインストールおよび更新は、カーネルとRDMAネットワーク・ファブリックのパッケージをそのまま維持する場合にのみ可能です。
• カスタマイズのレベルと影響
  
• Exadataデータベース・サーバーの更新ユーティリティ
  patchmgrは、Oracle Exadataデータベース・サーバーを更新するための更新ユーティリティです。
• ツール実行ホストの更新
  
• root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行
  
• Exadataデータベース・サーバーを更新する場合にお薦めするタイムライン
  
• Exadataデータベース・サーバー更新のダウンロードおよび配布
  
• 個々のパッケージの更新
  
• 前提条件チェックの実行
  
• 計画メンテナンスの前のExadataデータベース・サーバーのバックアップ
  次のリリースに更新するときは、変更を加える前に、Exadataデータベース・サーバーのバックアップを作成することをお薦めします。
• 更新の実行
  ローリング方式(--rollingフラグを使用)または非ローリング方式で、Exadataデータベース・サーバーの実際の更新を実行できます。デフォルトは非ローリング方式です。
• 更新のロールバック
  

8.5.1 Oracle Exadata Database Serverの更新の概要

データベース・サーバーの更新時には、複数のソフトウェアを更新する必要があります。

Oracle Exadataデータベース・サーバー・リリースの更新には、データベース・サーバー内の次のコンポーネントに対する更新が含まれています:

• Oracle Linuxオペレーティング・システム
• ファームウェア(ディスク、RAIDコントローラ、ILOM、HCA)
• Oracle Exadata System Software

特定のリリースで更新されるソフトウェアおよびファームウェアのコンポーネントは、データベース・サーバーが実行されている現在のOracle Exadata System Softwareリリースおよび更新先のリリースによって異なります。Oracle Linuxオペレーティング・システム・パッケージおよびOracle Exadata System Softwareは常に更新されますが、ファームウェアは選択した少数のコンポーネントに対して更新されたり、まったく更新されないことがあります。

Oracle Exadataデータベース・サーバーに対する更新は、My Oracle Supportノート888828.1で特に指定されている場合を除き、ストレージ・サーバーまたはRDMAネットワーク・ファブリック・スイッチとは関係なく適用できます。

データベース・サーバーの更新は、常にインプレースで実行されます。つまり、アクティブなオペレーティング・システムが更新されます。実際の更新はYUMを使用して実行されますが、これを実行するコマンドはpatchmgrというOracle Exadataユーティリティにラップされています。

更新処理中の検証ステップと準備ステップの厳密な順序を維持するために、YUMコマンドは更新ユーティリティにラップされています。また、Oracle提供のユーティリティを使用することで、既知の問題に対する修正の適用およびベスト・プラクティスを強制できます。

Oracle ClusterwareプロセスおよびOracle Real Application Clusters (Oracle RAC)データベース・インスタンスが、更新対象のデータベース・サーバー上で実行されていない必要があります。アプリケーション・レベルの影響を軽減するには、テクニカル・リファレンス・ペーパー『高可用性Oracle Databaseでのクライアント・フェイルオーバーのベスト・プラクティス』で説明されているクライアント・フェイルオーバーのベスト・プラクティスに従ってください。

クラスタ全体の停止時間が許容されない場合は、ローリング方式でデータベース・サーバーを更新できます。つまり、一度に1つのデータベース・サーバーを更新します。クラスタ全体の停止時間が許容される場合は、すべてのデータベース・サーバーをパラレルに更新できます。非ローリング更新は、更新の完了までにかかる全体的な時間が短縮されますが、データベースの完全な停止が発生します。

8.5.2 Oracle以外のソフトウェアのインストール、更新および管理

Oracle Exadataデータベース・サーバーへのOracleブランド以外のRPMのインストールおよび更新は、カーネルとRDMAネットワーク・ファブリックのパッケージをそのまま維持する場合にのみ可能です。

パッケージを追加または更新することによってオペレーティング・システムをカスタマイズすると、Oracle Exadata System Software更新を適用するときに問題が発生することがあります。これは、Oracle以外のソフトウェアによって、Oracle Exadata System Software更新では提供されない新しい依存性が追加される場合があるためです。このため、Oracle Exadataイメージはそのままに近い状態を維持して、カスタマイズをできるかぎり少なくすることをお薦めします。

ノート:

Oracle Exadataには、32ビット・ソフトウェアは付属していません。つまり、システムに32ビットRPMを導入するカスタマイズがある場合は、Oracle Exadata System Software更新を阻害するため、削除する必要があります。

Oracle Exadataイメージによって提供されたパッケージを追加または更新した場合には、次のように、必要に応じてexadata-sun-computenode-exact rpmを削除できます:

[root@dm01 ]# rpm -e exadata-sun-computenode-exact

カスタマイズしたパッケージをインストールした場合には、スクリプトで、自動的に、それらのパッケージを削除(Oracle Exadata System Softwareの更新前に実行)およびインストール(Oracle Exadata System Softwareの更新後に実行)することをお薦めします。Oracle Exadata System Softwareの更新後、カスタマイズしたパッケージを再インストールする前に、互換性が維持され、かつ引き続き必要であることを確認してください。

ノート:

Oracle Support Servicesからの指示がないかぎり、パッケージに対して強制的にrpm -Uvh --nodepsコマンドを使用しないでください。

追加のソフトウェアをインストールする以外のカスタマイズにも、同じ原則が適用されます。オペレーティング・システムに対するカスタマイズは、できるかぎり少なくすることをお薦めします。データベース・サーバーに対する変更は前述の境界内で許容されますが、オラクル社でオペレーティング・システムのあらゆる構成項目に対するあらゆるカスタマイズを予期することはできません。

Oracle Exadataユーティリティが依存する、一般的ないくつかの標準があります。これらの標準は、ベスト・プラクティスに基づき、かつ、長期にわたって検証されています。Oracle Exadata標準から逸脱すると、システムの設定が最適でなくなる可能性があり、また、オラクル社が個別の構成を予期してソフトウェアを検証することは困難であることから、リスクが発生します。このため、カスタマイズによって予期しない結果が発生することがあります。ソフトウェアを追加したり、システム構成をカスタマイズしたりすると、標準のOracle Exadata更新処理に対してステップの変更や追加が必要になることがあります。カスタマイズの有無に関係なく、Oracle Exadata System Software更新を本番システムで実行する前に、テスト・システムで検証することをお薦めします。

8.5.3 カスタマイズのレベルと影響

次の表では、Exadataデータベース・サーバーのカスタマイズに伴うリスクに関するいくつかのガイドを示します。前提条件チェックではほとんどのカスタマイズについてチェックしますが、構成変更の中には、データベース・サーバーを更新できるようにするために、ロールバックする必要があるものがあります。引き続き必要となるものについては、更新処理後にリストアできます。

表8-7 カスタマイズとそのリスク

項目	カスタマイズ・レベル	リスク
デフォルト指定のエンジニアド・システム・ソフトウェア・スタック	なし	なし
システム・ユーザー(root/oracle)のインタラクティブ・シェル・プロファイルの設定	低	高
VGExaDbのすべての空き領域の使用	低	低
追加の(Exadata以外の) rpmパッケージのインストール	中	低
様々なマウント・ポイントがあるファイル・システムのカスタマイズ	中	低
現在のExadataイメージに付属のパッケージの更新	中	低
構成ファイルのカスタマイズ、基本的なオペレーティング・システム機能の変更	高	中
追加の(Exadata以外の) rpm以外のパッケージのインストール	高	中
LVMレイアウトの変更	高	高

8.5.4 Exadataデータベース・サーバーの更新ユーティリティ

patchmgrは、Oracle Exadataデータベース・サーバーを更新するための更新ユーティリティです。

リリース12.2.1.1.0以降、Exadataデータベース・サーバーのExadataソフトウェア更新はpatchmgrユーティリティを使用してのみ適用できます。

ノート:

Exadataデータベース・サーバーを更新するためのpatchmgrユーティリティは、Exadataソフトウェア更新に付属のpatchmgrスクリプトとは異なります。

patchmgrユーティリティは、すべての世代のハードウェア、11.2.3.1.0以降のExadataストレージ・サーバー・リリース、およびOracle Virtual Server (dom0)とExadata Virtual Machines (domU)を実行しているExadataデータベース・サーバーをサポートしています。Oracle Exadata System Software更新のREADMEファイルには、更新自体が特定の世代のハードウェアに適用可能かどうかが記載されています。READMEは、dbserver.patch.zipに付属していませんが、Oracle Exadata System Software更新のzipファイルには付属しています。

このユーティリティでは、主要なオペレーティング・システムのアップグレードを含むExadataソフトウェアの更新もサポートされています。たとえば、Oracle Linux 7からOracle Linux 8へのアップグレードです。

ユーティリティでは、オーケストレーションに対処します。更新は、1つまたは複数のExadataデータベース・サーバーを対象にローリング方式または非ローリング方式で実行できます。

更新ユーティリティは、次のタスクを実行します。

• 次のような、準備、更新、検証のすべてのステップを自動化します。
  • データベース、Grid InfrastructureスタックまたはdomUの停止
  • Oracle Enterprise Manager Cloud Controlエージェントの停止
  • リモート・ネットワーク・マウントのアンマウント(必要な場合)
• Exadataデータベース・サーバーを更新する前に、組込みのdbserver_backup.shスクリプトを使用して、オペレーティング・システムをホストするファイル・システムのバックアップを実行します。
• Oracleベスト・プラクティスおよび最新の既知の問題に対する修正を適用します。
• 更新が成功したことを確認し、Oracleバイナリを再リンクして、OracleスタックおよびdomUを起動します。

8.5.5 ツール実行ホストの更新

すべてのExadataデータベース・サーバーを一度に更新することを計画している場合は、更新対象のExadataデータベース・サーバーのグループ外にあるLinuxノードから更新ユーティリティを実行することが要件になります。これは、更新ユーティリティではその実行元のExadataデータベース・サーバーを更新できないためです。他にOracle LinuxまたはOracle Solarisを実行しているシステムがない場合には、Exadataデータベース・サーバーのいずれかから更新ユーティリティを実行できます。このような場合は、指定したdbs_groupファイルに、更新ユーティリティを実行するExadataデータベース・サーバーがリストされていないことを確認してください。

更新対象のすべてのExadataデータベース・サーバーのrootユーザーに対して、駆動ノードからrootユーザーのSSH等価を設定する必要があります。

8.5.6 root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行

デフォルトでは、更新ユーティリティはrootとして実行することを前提としています。ただし、リモート・ホストからroot以外のユーザーとして更新ユーティリティを実行することもできます。また、複数の起動を同時に実行することもできます。これにより、Exadataデータベース・サーバーの複数の論理グループを同時に更新できます。これを行うには、-log_dirフラグを指定して更新ユーティリティを実行します。

現在のユーザーのSSH等価が更新対象のExadataデータベース・サーバーのrootユーザーに対して設定されていることを確認してください。

次の例では、root以外のユーザーとして実行し、複数の起動を実行するオプションを示します。

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes ~/dbs_group -upgrade -iso_repo /u01/ /p23557378_121223_Linux-x86-64.zip
 -target_version 12.1.2.4.0.160710 -log_dir auto

-log_dirには、ログ・ディレクトリへの絶対パスか、キーワードautoを指定します。後者の場合、起動ディレクトリおよびノードのリスト・ファイルの内容に基づいて、ユーティリティがログ・ディレクトリへのパスを生成して設定します。その後、Exadataデータベース・サーバーのリストを変更した場合に、起動するときに同じログ・ディレクトリが使用されるようにするには、-get log_dirフラグを使用して、以前のセッションで使用していた-log_dirの場所を取得します。たとえば、次のコマンドを入力したとします。

[oracle@nonExadata ]$ ./patchmgr -dbnodes ~/dbs_group_test  -log_dir auto -get log_dir

このコマンドによって、次のような出力が返されます。

log_dir=/u01/test/dbserver_patch_5.160715/log/dbm01_dbm02_e8f1f75

後続のコマンドでは、log_dir値を使用します。たとえば:

[oracle@nonExadata ]$ ./patchmgr -dbnodes ~/dbs_group_test -precheck 
-log_dir /u01/test/dbserver_patch_5.160715/log/dbm01_dbm02_e8f1f75 
-iso_repo /u01/test/dbserver_patch_5.160715/p23557378_121223_Linux-x86-64.zip 
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts

8.5.7 Exadataデータベース・サーバーを更新する場合にお薦めするタイムライン

Exadataデータベース・サーバーの更新には、次のタイムラインをお薦めします。このアプローチに従うことによって、必要な是正処置を実行するための時間を確保できます。

ノート:

前提条件チェックなどの変更を加える前に、バックアップを作成してください。

表8-8 更新を実行するためのタイムライン

いつ	タスク
更新までの数週間から数日前	My Oracle Supportノート1553103.1から最新のdbserver.patch.zipをダウンロードします。 My Oracle Supportノート1070954.1から最新のExachkをダウンロードします。 リリース固有のMy Oracle Supportノートで既知の問題を調査します。 My Oracle Supportノート1270094.1を調べてExadataの重大な問題を調査します。 Exachkを実行します。 まず前提条件チェックを実行します。 詳細は、前提条件チェックの実行を参照してください。
更新直前	My Oracle Supportノート1553103.1から最新のdbserver.patch.zipをダウンロードします。 My Oracle Supportノート1070954.1から最新のExachkをダウンロードします。 リリース固有のMy Oracle Supportノートで既知の問題を調査します。 My Oracle Supportノート1270094.1を調べてExadataの重大な問題を調査します。 Exachkを実行し、必要に応じて是正処置を行います。
更新時	-backupフラグを使用してバックアップのみの実行を行います。 詳細は、計画メンテナンスの前のExadataデータベース・サーバーのバックアップを参照してください。 2回目の前提条件チェックを実行します。 ブロックしているrpmがある場合は、それを削除し、前提条件チェックを再実行して、すべての変更が完了しているかどうかを検証します。 更新を実行します。すでにバックアップのみの実行を行ったため、-nobackupフラグを使用してバックアップをスキップします。 詳細は、更新の実行を参照してください。
更新後	Exachkを実行します。 Exadataを更新する前に、削除したExadata以外のrpmを再インストールします。

8.5.8 Exadataデータベース・サーバー更新のダウンロードおよび配布

各Exadataデータベース・サーバー更新は、圧縮されたISOイメージ・ファイルとして、およびOracle Unbreakable Linux Network (ULN)上のチャネルとしてパッケージ化されます。Oracleは、Exadataハードウェアおよびソフトウェア・スタック全体で、各リリースのパッケージをキュレート、テストおよび認定します。Exadata ISOおよびULNチャネルには、Exadata System SoftwareおよびOracle Database (Oracle Grid Infrastructureを含む)の実行に必要なパッケージのみが含まれます。

Exadataデータベース・サーバーの更新は、次の方法で利用できます:

• ローカルYUMリポジトリ・ミラーの使用

  この方法では、YUMリポジトリ・サーバーを使用して、Exadataデータベース・サーバー・ソフトウェア更新ごとにULNチャネルをミラー化します。この方法は、次の場合に推奨されます:

  • 更新するExadataデータベース・サーバーの数が多い。

  • ネットワークにYUMリポジトリ・サーバーがすでに存在するか、別のLinuxサーバーにローカルULNミラーを構築するためのインフラストラクチャが存在する。

  • すべてのExadataデータベース・サーバーから、YUMリポジトリ・サーバーにアクセス可能である。

• YUMリポジトリとしてのISOファイルの使用

  この方法では、標準のWebサーバーを使用して、Exadataデータベース・サーバー・ソフトウェア更新を含むISOファイルをYUMリポジトリとして表示します。この方法は、次の場合に推奨されます:

  • 更新するExadataデータベース・サーバーの数が多い。

  • ネットワークにまだYUMリポジトリ・サーバーがないため、作成する必要がない。

  • ネットワーク上に、すべてのExadataデータベース・サーバーからアクセスできるWebサーバーがある。

• ISOファイルの直接使用

  この方法では、Exadata patchmgrユーティリティを使用して、Exadataデータベース・サーバー・ソフトウェア更新を含むISOファイルに直接アクセスします。

  このアプローチでは、Exadata patchmgrユーティリティを実行しているサーバー上のISOファイルのコピーのみが必要なので、簡略である点が主な利点です。ただし、このアプローチを使用して、patchmgrユーティリティは、更新のターゲットであるすべてのExadataデータベース・サーバーにISOファイル全体を伝播する必要があります。一方、patchmgrは、他の方法を使用する場合にのみ、個々のパッケージを更新ターゲットに伝播します。したがって、このアプローチでは、更新されるサーバーごとに追加の空きローカル・ストレージ領域が必要です。

次のトピックでは、これらのメソッドの詳細を説明します:

• ULN Oracle ExadataチャネルでのローカルYUMリポジトリ・ミラーの使用
  
• YUMリポジトリとしてのISOファイルの使用
  
• ISOファイルの直接使用
  

8.5.8.1 ULN Oracle ExadataチャネルでのローカルYUMリポジトリ・ミラーの使用

ローカルYUMリポジトリ・サーバーは、Oracle Unbreakable Linux Network (ULN)からダウンロードされたExadataデータベース・サーバー・ソフトウェア更新パッケージのローカル・コピー(ミラー)を含む個別のLinuxサーバーです。リポジトリの構成後、すべてのExadataデータベース・サーバーがリポジトリに接続して更新を取得できます。

ノート:

Exadataデータベース・サーバーを、ローカルULNミラーとして使用することはできません。Exadataソフトウェア更新に関連する再起動による中断を回避するには、別のサーバーを使用します。また、別のサーバーを使用すると、リポジトリの構築に必要なパッケージと、Exadataシステム機能をサポートするためにインストールまたは更新されたパッケージとの依存性の競合を回避できます。

使用できる独立したサーバーがない場合は、かわりにISOイメージによる直接的な方法を使用してください。「ISOファイルの直接使用」を参照してください。

一般に、ローカルYUMリポジトリ・サーバーを設定する手順は次のとおりです:

1. YUMリポジトリおよびWebサーバーをサポートするようにソフトウェア・パッケージをインストールおよび構成します。

2. ULNへのシステムの登録

3. ミラー化するExadataデータベース・サーバー更新を含むULNチャネルをサブスクライブします。

正確な手順は、ローカルYUMリポジトリ・サーバーで使用されるOracle Linuxのバージョン(Exadataで使用されるOracle Linuxのバージョンと無関係)によって異なります。状況に応じて適切なバージョンのOracle Linuxドキュメントを参照してください。ガイドとして、現在のOracle Linuxリリースに基づく手順は、ローカルULNミラーの設定を参照してください。

Exadataデータベース・サーバー・ソフトウェアを含むULNチャネルでは、exadata_dbserverで始まる識別子が使用されます。使用可能なExadataチャネルは、ULN Webインタフェースまたはuln-channelユーティリティを使用して検索できます。たとえば:

[root@yumrepo ~]# uln-channel --available-channels
...
exadata_dbserver_22.1.18.0.0_x86_64_base
exadata_dbserver_22.1.19.0.0_x86_64_base
exadata_dbserver_22.1.20.0.0_x86_64_base
...
exadata_dbserver_23.1.7.0.0_x86_64_base
exadata_dbserver_23.1.8.0.0_x86_64_base
exadata_dbserver_23.1.9.0.0_x86_64_base
...

関連するチャネルを識別する場合は、ULN Webインタフェースまたはuln-channelユーティリティを使用して、それをサブスクライブし、Exadataシステム全体で使用するためにミラー化することもできます。単一のYUMリポジトリ・サーバーは、複数のExadataデータベース・サーバー・ソフトウェア・チャネルをミラー化でき、各チャネルには、OL6、OL7、OL8などの特定のOracle Linuxリリースに基づくソフトウェアが含まれていることに注意してください。たとえば:

[root@yumrepo ~]# uln-channel --add --channels exadata_dbserver_22.1.20.0.0_x86_64_base
[root@yumrepo ~]# uln-channel --add --channels exadata_dbserver_23.1.8.0.0_x86_64_base

ULNミラーを作成した後、--repoオプションを指定してExadata patchmgrユーティリティを使用して参照できます。たとえば:

[root@pmserver ~]# patchmgr --dbnodes database_node_file --precheck --repo http://yumrepo/yum/exadata_dbserver_23.1.8.0.0_x86_64_base --target_version 23.1.8.0.0.231109
[root@pmserver ~]# patchmgr --dbnodes database_node_file --upgrade --repo http://yumrepo/yum/exadata_dbserver_23.1.8.0.0_x86_64_base --target_version 23.1.8.0.0.231109 --rolling

patchmgrを実行しているサーバーは、YUMリポジトリ・サーバーと異なる場合があります。また、--repoオプションで指定する正確なURLは、ULNミラーおよび関連するWebサーバーの設定方法によって異なります。

8.5.8.2 YUMリポジトリとしてのISOファイルの使用

各Exadataデータベース・サーバー更新は、圧縮されたISOイメージ・ファイルとしてパッケージ化されます。ISOイメージ・ファイルは、自己完結型YUMリポジトリとして編成されています。標準HTTP Webサーバーを使用して、ISOファイルをすべてのExadataデータベース・サーバーのYUMリポジトリとして提供できます。

ノート:

YUMリポジトリのホストにExadataデータベース・サーバーを使用しないでください。Exadataソフトウェア更新に関連する再起動による中断を回避するには、別のサーバーを使用します。

使用できる独立したサーバーがない場合は、かわりにISOイメージによる直接的な方法を使用してください。「ISOファイルの直接使用」を参照してください。

一般的な手順は次のとおりです。状況やサーバー構成に応じて例のコマンドを調整する必要があります。

1. Exadataデータベース・サーバー更新パッチをMy Oracle SupportからWebサーバーにダウンロードします。

   各Exadataデータベース・サーバー更新パッチには、圧縮されたISOイメージ・ファイルが含まれています。

   使用可能なExadataデータベース・サーバー更新パッチを検索するには、My Oracle Supportドキュメント888828.1を参照してください。

2. パッチ・アーカイブを解凍し、ISOイメージ・ファイルをマウントします。

   たとえば:

   [root@webServer /var/stage]# unzip p35869377_231000_Linux-x86-64.zip
   [root@webServer /var/stage]# mkdir -p /var/www/html/yum/EXADATA/dbserver/23.1.8/base
   [root@webServer /var/stage]# mount -o loop /var/stage/exadata_ol8_base_repo_23.1.8.0.0.231109.iso /var/www/html/yum/EXADATA/dbserver/23.1.8/base

   この例では、Exadataリリース23.1.8のExadataデータベース・サーバー更新パッチ・アーカイブ(p35869377_231000_Linux-x86-64.zip)を使用します。このアーカイブには、exadata_ol8_base_repo_23.1.8.0.0.231109.ISOという名前のISOイメージ・ファイルが含まれています。この例では、圧縮パッチ・アーカイブが/var/stageにダウンロードされていることを前提としています。また、この例では、Webサーバーのドキュメント・ルート・ディレクトリが/var/www/htmlにあり、ISOイメージ・ファイルのマウント・ポイントが/var/www/html/yum/EXADATA/dbserver/23.1.8/baseであると想定しています。

3. Exadataデータベース・サーバー更新のYUMリポジトリの可用性および内容を確認します。

   前述の例に基づいて、選択したExadataデータベース・サーバー更新のYUMリポジトリをhttp://webServer/yum/EXADATA/dbserver/23.1.8/base/x86_64/で使用できるようになりました。

   patchmgr更新ユーティリティで事前チェック操作を実行すると、YUMリポジトリの可用性と内容を確認できます。コマンドで、--repoオプションを使用してYUMリポジトリURLを指定します。

   たとえば:

   [root@pmserver ~]# patchmgr --dbnodes database_node_file --precheck --repo http://webServer/yum/EXADATA/dbserver/23.1.8/base/x86_64/ --target_version 23.1.8.0.0.231109

   patchmgrを実行しているサーバーは、YUMリポジトリ・サーバーと異なる場合があります。

4. YUMリポジトリを使用して更新を実行します。

   patchmgrコマンドで、--repoオプションを使用してYUMリポジトリURLを指定します。

   たとえば:

   [root@pmserver ~]# patchmgr --dbnodes database_node_file --upgrade --repo http://webServer/yum/EXADATA/dbserver/23.1.8/base/x86_64/ --target_version 23.1.8.0.0.231109 --rolling

8.5.8.3 ISOファイルの直接使用

各Exadataデータベース・サーバー更新は、圧縮されたISOイメージ・ファイルとしてパッケージ化されます。このファイルは、patchmgr更新ユーティリティで直接使用できます。

このアプローチでは、Exadata patchmgrユーティリティを実行しているサーバー上の圧縮済ISOファイルのコピーのみが必要なので、簡略である点が主な利点です。ただし、このアプローチを使用して、patchmgrユーティリティは、更新のターゲットであるすべてのExadataデータベース・サーバーに圧縮済ISOファイル全体を伝播する必要があります。一方、patchmgrは、他の方法を使用する場合にのみ、個々のパッケージを更新ターゲットに伝播します。したがって、このアプローチでは、更新されるサーバーごとに追加の空きローカル・ストレージ領域が必要です。

一般的な手順は次のとおりです。状況やサーバー構成に応じて例のコマンドを調整する必要があります。

1. Exadataデータベース・サーバー更新パッチをMy Oracle Supportからpatchmgrサーバーにダウンロードします。

   各Exadataデータベース・サーバー更新パッチには、圧縮されたISOイメージ・ファイルが含まれています。

   使用可能なExadataデータベース・サーバー更新パッチを検索するには、My Oracle Supportドキュメント888828.1を参照してください。

2. 圧縮済ISOファイルは、patchmgr更新ユーティリティで直接使用します。

   patchmgrコマンドで、--repoオプションを使用して圧縮済ISOファイルを指定します。

   たとえば:

   [root@pmserver ~]# patchmgr --dbnodes database_node_file --precheck --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109
   [root@pmserver ~]# patchmgr --dbnodes database_node_file --upgrade --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109 --rolling

   この例では、Exadataリリース23.1.8のExadataデータベース・サーバー更新パッチ・アーカイブ(p35869377_231000_Linux-x86-64.zip)を使用します。この例では、圧縮パッチ・アーカイブが/var/stageにダウンロードされていることを前提としています。

8.5.9 個々のパッケージの更新

セキュリティの確保やカスタマイズのために、Exadataリリースによって提供される個々の(汎用的な) Linuxパッケージを更新することが必要になる場合もあります。これを行うには、まずexadata-sun-computenode-exact rpmを削除します。

このrpmを削除することは、機能には影響を及ぼしませんが、ロックが削除されます。このロックを削除することで、特定の個々のLinux rpmを更新できるようになります。

必要に応じて、次のようにexadata-sun-computenode-exact rpmを削除できます。

[root@dm01 ]# rpm -e exadata-sun-computenode-exact

新しいリリースに更新するときに、更新ユーティリティはロックをリストアしようとします(exadata-sun-computenode-exact)。このことは、たとえば、より新しいリリースにより新しいパッケージが同梱されている場合に発生することがあります。

exadata-sun-computenode-exact rpmをリストアできない場合、更新ユーティリティはexadata-sun-computenode-minimumにフォールバックします。

ノート:

Oracleサポート・サービスからの指示がないかぎり、パッケージで強制的にrpm -Uvh --nodepsコマンドを使用しないでください。

8.5.10 前提条件チェックの実行

実際の更新を行う前に、常に、前提条件チェックを実行する必要があります。前提条件チェックでは停止時間は必要なく、次のような重要な検証を実行します:

• Exadataリリースの検証(Oracle Linux 5.5を実行している11.2.2.4.2以上)

• ユーザー入力の検証

• インストール・メディア(ISOかHTTPのいずれかのYUMリポジトリ)の検証

• ディスク領域およびスナップショットの検証

• 更新を正常に終了するために重要なYUM設定の検証

• 既知の問題とベスト・プラクティスに基づくチェック

更新ユーティリティによって実行される最も重要な検証は、YUM依存性チェックです。YUM依存性チェックは、実際のYUM更新は行わず、依存性の検証を行うYUM更新テスト実行コマンド(11.2.3.3.0で導入)です。これは、更新を続行できるかどうかを判断する最終テストです。正常に更新できない場合、その原因がカスタマイズであることがよくあります。たとえば、RPMを追加でインストールしたことによって、YUMリポジトリにない依存パッケージが必要になることがあります。この場合、競合を解決するための是正処置を実行する必要があります。

YUM依存性チェック(テスト実行)は、MinimumおよびExact依存性に対して検証されます。これらの依存性は非機能Exadata RPMによって成立し、管理者がシステムをカスタマイズするときに、元のExadataリリースとまったく同じ(かそれに近い)状態を維持するために役立ちます。更新ユーティリティでは、次のようにexadata-sun-computenode-exact rpmおよびexadata-sun-computenode-minimum rpmを使用します。

• exadata-sun-computenode-exact rpmでは、更新中にOracle Exadataブランド・パッケージの特定のリリースのみが許可されるようにします(リリース=x)。

• exadata-sun-computenode-minimum rpmでは、更新中にOracle Exadataブランド・パッケージの特定のリリース以上のリリースが許可されるようにします(リリース>=x)。

exadata-sun-computenode-exact rpmを使用すると、すべてのOracle Exadataパッケージが基本インストールとまったく同じになるため、システムはより新しいリリースに新しくイメージ化されたかのように見えます。一方、exadata-sun-computenode-minimum rpmを使用すると、Minimum依存性が設定され、すべてのパッケージのインストールが強制されるものの、パッケージをそれより後のバージョンにすることも許容されます。基本インストールは、常に、両方のRPMを使用して開始されます。カスタマイズや更新を許可するには、exadata-sun-computenode-exactを削除する必要があります。

デフォルトでは、後のExadataリリースに更新するときに、更新ユーティリティはExact依存性を一致させようとします。Exact依存性が競合して成立しない場合、ユーティリティはフォールバックし、Minimum依存性を成立させるために、exadata-sun-computenode-minimum rpmの適用を試みます。このような場合、exadata-sun-computenode-exact rpmはインストールされていません。

Exact依存性の欠如または未更新は許容され、問題にはなりません。システムをExact依存性に従って更新する必要がある場合、すべての競合を解決する必要があります。ログ・ファイルを調べて、競合するパッケージを確認し、それらを慎重に削除してから、前提条件チェック・モードで更新ユーティリティを再実行します。

前提条件チェックが失敗した場合は、更新ユーティリティのログ・ファイルで詳細を確認し、失敗した依存性を判断できます。Exact依存性とMinimum依存性の両方が一致しないときには、更新は続行できません。

このような場合は、ログ・ファイルを調べて、依存性が失敗した原因を特定します。失敗した依存性を取り除いた後、更新ユーティリティを再実行して、少なくともMinimum依存性が成立することを確認します。

前提条件チェック中または更新の開始前に、依存性エラーが発生した場合、次のようにして問題を解決します。

• ログ・ファイルに記載されたYUMエラーを分析します。Errorを検索します。

• 内容によっては、依存性の問題や競合の原因となるrpmパッケージを、アンインストール、インストールまたは更新する必要があります。ログ・ファイルには、失敗した依存性が記載されています。

アンインストールしたカスタムrpmパッケージが引き続き必要となり、かつ、更新したシステムと互換性がある場合には、更新後にそのパッケージを再インストールする必要があります。

その他のオプションは、更新ユーティリティに組込みのヘルプを参照してください。

前提条件チェックの例

次のコマンドは、ISOリポジトリを使用した前提条件チェックの例を示しています。このコマンドは、rootとして実行します。

[root@pmserver ]# ./patchmgr --dbnodes dbs_group --precheck --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109

• --dbnodesには、更新するデータベース・ノードのリストを指定します。

• --precheckには、前提条件チェック・アクションを指定します。

• --repoには、更新リポジトリを含む圧縮ISOファイルの場所を指定します。圧縮されたISOファイルを指定する場合は、更新ユーティリティを実行しているノードでファイル・パスにアクセスできる必要があります。または、YUMリポジトリへのURLを指定することもできます。

• --target_versionには、データベース・サーバーの更新先のターゲット・リリースを指定します。

8.5.11 計画メンテナンスの前のExadataデータベース・サーバーのバックアップ

次のリリースに更新するときは、変更を加える前に、Exadataデータベース・サーバーのバックアップを作成することをお薦めします。

これは、他の変更を(手動で)加える前にバックアップ専用モードで更新ユーティリティを実行して、前提条件/依存性チェックに合格させるということです。バックアップのみアクションでは、アクティブなルートと/bootファイル・システムのみをバックアップします。更新(失敗した場合)をロール・バックするには、これで十分です。

ノート:

ブートできない障害からシステムをリカバリするには、更新ユーティリティに組込みのバックアップ(dbserver_backup.sh)では不十分です。ダブル・ディスク障害などの障害からデータベース・サーバー全体をリカバリするために、追加の(検証済の)バックアップ/リストア手順を採用することをお薦めします。

標準の仮想化されたExadataデータベース・サーバー(domU)の場合、アクティブなシステム・イメージを/dev/mapper/VGExaDb-LVDbSys1上のファイル・システムから実行しているときには、バックアップは/dev/mapper/VGExaDb-LVDbSys2に作成されます(その逆も同じです)。/dev/mapper/VGExaDb-LVDbSys2をアクティブなイメージとするdom0をExadataデータベース・サーバーで実行している場合、バックアップは/dev/mapper/VGExaDb-LVDbSys3に移動します(その逆も同じです)。

つまり、更新のロールバック時に、標準のデータベース・サーバーおよびdomUのアクティブなシステム・イメージは/dev/mapper/VGExaDb-LVDbSys2になり、dom0のアクティブなシステム・イメージは/dev/mapper/VGExaDb-LVDbSys3になります。

アクティブなシステム・パーティションをバックアップするプロセスでは、Sys* LVMのデフォルトのLVMスキームがあること、および両方のLVMが同じサイズであることを必要とします。サイズが異なる場合、大きい方のLVMパーティションを小さい方のLVMパーティションにバックアップできないためです。LVM VGExaDb-LVDbSys1パーティションのサイズ変更は、VGExaDb-LVDbSys2が同じサイズに変更される場合にかぎり、許可されます。

バックアップの実行中、ファイル・システムのビューの一貫性はLVMスナップショットによって保たれます。このLVMスナップショットは、バックアップ・スクリプトによって保守され、常に、VGExaDbに1Gの空きVG領域を必要とします。

スナップショットの領域は、/dev/VGExaDb/LVDoNotRemoveOrUseというプレースホルダLVMを使用することで、オラクル社によって保証されます。バックアップ・スクリプトを実行すると、このプレースホルダは削除され、スナップショットに使用可能な1Gの空き領域が常に確保されます。バックアップが完了すると、スナップショットは削除され、/dev/VGExaDb/LVDoNotRemoveOrUse LVMが再作成されます。

バックアップの実行にかかる時間は、システムのビジー状態およびバックアップ対象データのサイズとタイプによって異なります。たとえば、数百万個の小さいファイルをバックアップすると、より大きい数個のファイルをバックアップするよりも大幅に長い時間がかかることがあります。このため、ルート・ファイル・システムに、データベース.audファイルを保持するディレクトリがないことを確認することをお薦めします。次の点に注意してください。

• バックアップは1つのみ保持できます。新規にバックアップを実行すると、既存のバックアップが上書きされます。

• --backupフラグを指定して(またはデフォルト更新モードで)更新ユーティリティを再実行すると、既存のバックアップが上書きされます。

• /boot内およびアクティブなSys LVM上にあるすべてのファイルがバックアップされます。たとえば、/u01内のファイルはバックアップされません。

バックアップのみの例

次の例では、rootとしてバックアップのみを実行する例を示します。

[root@pmserver ]# ./patchmgr --dbnodes dbs_group --backup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109 --allow_active_network_mounts

• --dbnodesには、更新するデータベース・ノードのリストを指定します。

• --backupには、バックアップのみのアクションを指定します。

• --repoには、更新リポジトリを含む圧縮ISOファイルの場所を指定します。圧縮されたISOファイルを指定する場合は、更新ユーティリティを実行しているノードでファイル・パスにアクセスできる必要があります。または、YUMリポジトリへのURLを指定することもできます。

• --target_versionには、バックアップの実行対象となるターゲット・リリースを指定します。

• --allow_active_network_mountsを指定すると、バックアップ操作の実行中、アクティブなネットワーク・マウントがアクティブなままになります。

次の例では、root以外のユーザーとして実行したバックアップのみアクションを示します。

[oracle@pmserver ]$ ./patchmgr --dbnodes ~/dbs_group -backup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109 --log_dir auto --allow_active_network_mounts --smtp_from "[e-mail]" --smtp_to "[e-mail]"

8.5.12 更新の実行

ローリング方式(--rollingフラグを使用)または非ローリング方式で、Exadataデータベース・サーバーの実際の更新を実行できます。デフォルトは非ローリング方式です。

また、「root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行」の説明に従って、更新はrootとしてもroot以外のユーザーとしても(--log_dirフラグを使用)実行できます。

更新は、Minimum依存性チェックが成功した場合にのみ続行します。更新を続行するために、カスタマイズを削除することが必要になる場合があります。

デフォルトでは、更新によって、非アクティブなシステム・イメージにバックアップが作成されます。すでにバックアップを作成してあり、前提条件チェックの実行前にイメージを変更していない場合は、更新の実行時に-–nobackupフラグを省略できます。

ノート:

--nobackupフラグを使用するのは、前提条件チェックの実行前にすでにバックアップを作成しており、イメージを変更していない場合のみです。

更新アクションには、次のフラグが必要です。

• -–upgradeには、更新アクションを指定します

• --repoには、Exadata更新リポジトリのベースURLまたは圧縮済ISOファイルへのパスを指定します。

• --target_versionには、更新先のリリースを指定します。パッチのREADMEには、常に、この情報が含まれています。

バックアップ中および更新中のアクティブなリモート・ネットワーク・マウントを許可する追加のフラグ(--allow_active_network_mounts)を指定し、更新ステータス通知用の電子メールの受信者(--smtp_from "addr"および--smtp_to "addr1 addr2 addr3...")を指定できます

例8-12 YUMリポジトリのISOイメージを使用した更新の実行

次の例では、rootとして実行し、YUMリポジトリのISOイメージを使用した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[root@pmserver ]# ./patchmgr --dbnodes ~/dbs_group --upgrade --repo /var/stage/p35869377_231000_Linux-x86-64.zip 
--target_version 23.1.8.0.0.231109 --allow_active_network_mounts --smtp_from "[e-mail]" 
--smtp_to "[e-mail]" --nobackup

次の例では、ISO YUMリポジトリを使用してリモート・ホストからroot以外のユーザーとして実行した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[oracle@pmserver ]$ ./patchmgr --dbnodes ~/dbs_group --upgrade --repo /var/stage/p35869377_231000_Linux-x86-64.zip 
--target_version 23.1.8.0.0.231109 --allow_active_network_mounts --log_dir auto --smtp_from "[e-mail]" 
--smtp_to "[e-mail]" --nobackup

例8-13 YUMリポジトリのHTTPの場所を使用した更新の実行

次の例では、YUMリポジトリのHTTPを使用してrootとして実行した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[root@pmserver ]# ./patchmgr --dbnodes ~/dbs_group --upgrade --repo http://yum-repo/yum/EXADATA/dbserver/23.1.8/base/x86_64/ 
--target_version 23.1.8.0.0.231109 --allow_active_network_mounts --smtp_from "[e-mail]" --smtp_to "[e-mail]"
--nobackup

次の例では、YUMリポジトリのHTTPを使用してリモート・ホストからroot以外のユーザーとして実行した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[oracle@pmserver ]$ ./patchmgr --dbnodes ~/dbs_group --upgrade --repo http://yum-repo/yum/EXADATA/dbserver/23.1.8/base/x86_64/ 
--target_version 23.1.8.0.0.231109 --allow_active_network_mounts --log_dir auto --smtp_from "[e-mail]" 
--smtp_to "[e-mail]" –nobackup

8.5.13 更新のロールバック

バックアップを使用すると、更新の成否に関係なく、更新をロールバックできます。このバックアップは、計画メンテナンスの前のExadataデータベース・サーバーのバックアップで説明しているように、非アクティブなシステム・パーティションに格納されています。

更新をロールバックするとき、更新ユーティリティでは次のアクションを実行します。

• スタックおよびdomUを停止します。
• アクティブなシステム・パーティションを非アクティブ化し、非アクティブなシステム・パーティションをアクティブ化します。
• 非アクティブなパーティションから/bootをリストアします。
• GRUBブート・ローダーを更新します。

非アクティブなシステム・パーティションを1つのみ保持することで、ロールバック・オプションが前回のアクティブ・イメージのみに制限されます。

ノート:

• Oracle Linux 6に更新したシステムでは、更新を継続する前にバックアップを実行する必要があります。LVMが有効なシステムをOracle Linux 5からOracle Linux 6へ更新する場合、バックアップが自動で実行されます。
• Oracle VM Server (dom0)として実行するデータベース・サーバーは、ロールバックの際にアクティブなシステム・パーティションとして、LVDbSys2とLVDbSys3との間をスイッチします。
• Oracle VM (domU)として実行するデータベース・サーバーでは、物理ハードウェア・デプロイメントよりも、LVDbSys1のサイズは小型です。

例8-14 patchmgrを使用した更新のロールバック

[root@pmserver ]# ./patchmgr --dbnodes dbs_group --rollback

--dbnodesには、更新するデータベース・ノードのリストを指定します。

--rollbackには、ロールバック・アクションを指定します。

その他のオプションは、更新ユーティリティに組込みのヘルプを参照してください。

ノート:

以前のイメージにロールバックするときには、ファームウェア更新はロールバックされません。Oracle Exadata System Softwareリリースでは、それ以降のファームウェア・リリースをサポートしています。ロールバックした後、必要に応じて、次のコマンドを実行し、より古いバージョンのファームウェアを適用します。

/etc/init.d/lsidiag stop

/etc/init.d/lsi_mrdsnmpd stop

/opt/oracle.cellos/CheckHWnFWProfile -action updatefw -mode exact

最後のコマンドは、リリース11.2.3.3.0以上にのみ適用されます。

8.6 Oracle Exadata Storage Server上のソフトウェアの更新

次の情報と手順を使用して、Oracle Exadataのストレージ・サーバーを更新します。

• Oracle Exadata Storage Serverの更新の概要
  ストレージ・サーバーを更新する場合、更新が必要なソフトウェアには複数のタイプがあり、更新の実行方法も異なります。
• ストレージ・サーバーの自動更新のスケジュール
  Oracle Exadata System Softwareリリース18.1.0.0.0以降では、ストレージ・サーバーのソフトウェア更新をスケジュールできます。
• Oracle Exadata Storage Serverの更新ユーティリティ
  
• Oracle Exadata Storage Serverを更新する場合にお薦めするタイムライン
  
• Exadataストレージ・サーバーを更新するための準備
  Exadataストレージ・サーバーを更新する前に、次の準備ステップを実行します。
• Exadataストレージ・サーバーの更新の実行
  
• Exadataストレージ・サーバーに対する更新のロールバック
  

8.6.1 Oracle Exadata Storage Serverの更新の概要

ストレージ・サーバーを更新する場合、更新が必要なソフトウェアには複数のタイプがあり、更新の実行方法も異なります。

Oracle Exadata System Softwareリリースの更新には、次に示すOracle Exadataストレージ・サーバー内のコンポーネントに対する更新が含まれています:

• Oracle Linuxオペレーティング・システム
• ファームウェア(Flash、Disk、RAIDコントローラ、Integrated Lights Out Manager (ILOM)、HCA)
• Oracle Exadata System Software

更新されるソフトウェアおよびファームウェアは、ストレージ・サーバーに適用された現在のOracle Exadata System Softwareリリースおよび更新先のリリースによって異なります。Oracle Linuxオペレーティング・システム・パッケージおよびOracle Exadata System Softwareは常に更新されるのに対して、ファームウェア更新は選択した少数のコンポーネントに対してのみ適用されることや、まったく適用されないことがあります。

特に指定がないかぎり、Oracle Exadataストレージ・サーバーの更新は、Oracle Exadataデータベース・サーバーまたはRDMAネットワーク・ファブリックのスイッチの更新とは別に適用できます。リリースされるすべてのOracle Exadata System Software更新を個別に適用することが必要になるわけではありません。たとえば、リリースを2つか3つスキップして、より新しいリリースに直接更新できます。

Oracle Exadata System Softwareの更新は、常に「ホーム外」で実行されます。これは、Oracle Exadata System Softwareを含む新しいバージョンのオペレーティング・システムが、非アクティブなシステム・パーティションにインストールされることを意味します。Oracle Exadata System Softwareを更新するためのユーティリティは、その更新自体に付属しています。

クラスタ全体の停止時間が許容されない場合は、ローリング方式でストレージ・サーバーを更新できます。ローリングとは、一度に1つのストレージ・サーバーを更新することです。クラスタ全体の停止時間が許容される場合は、すべてのストレージ・サーバーをパラレルに更新できます。非ローリング更新では、所要時間全体が短縮されます。

Oracle Exadata System Softwareリリース18c (18.1.0)以降では、patchmgrを使用するよりもスケーラブルな方法でソフトウェアを更新できます。ストレージ・サーバーによって前提条件が自動的に検証され、指定したURLから更新ソフトウェアがダウンロードされます。各ストレージ・サーバーでは、ソフトウェアをそのアクティブ・パーティションにダウンロードした後、そのパッシブ・パーティションにロードします。指定した時刻に、ストレージ・サーバーは新しいバージョンで再起動します。ストレージ・サーバーでは、Oracle Automatic Storage Management (Oracle ASM)ディスクの非アクティブ化ステータスに基づいて、ディスクを安全に非アクティブ化して、ストレージ・サーバーを新しいソフトウェア・バージョンで再起動できるかどうかが判断されます。これらの更新スケジュールでは、patchmgrプロセスで現在使用されているものと同じスクリプトが起動されます。

8.6.2 ストレージ・サーバーの自動更新のスケジュール

Oracle Exadata System Softwareリリース18.1.0.0.0以降では、ストレージ・サーバーのソフトウェア更新をスケジュールできます。

外部サーバー(たとえば、Oracle Exadata Database Server)から、次のステップを実行します。

HTTPSプロトコルを使用してソフトウェア更新ストアにアクセスする場合は、デフォルトでTLS証明書チェックが必要になります。ソフトウェア更新をホストするWebサーバーの証明書の検証に失敗した場合は、次のエラーが返されます。

CELL-00076: An error occurred during download of software update:
source https://example.com:port is not available. 
CELL-00092: The store's TLS certificate cannot be authenticated with 
known CA certificates

1. Webサーバーでホストされているディレクトリにソフトウェア更新のZIPファイルをコピーします。
2. Oracle Exadata System Software 18c (18.1.0)または18c (18.1.1)を使用している場合、パッチ・ファイルの名前が18.1.1.0.0.171018.patch.zipのようになっている必要があります。

   ダウンロードしたパッチの名前がp26875767_181100_Linux-x86-64.zipのようになっている場合は、ファイル名を18.1.1.0.0.17018.patch.zipに変更してください。ZIPファイル内のディレクトリ名に使用されているリリース番号と日付文字列を含むようにZIPファイル名を変更します。たとえば、パッチp26875767_181100_Linux-x86-64.zipを解凍すると、ディレクトリpatch_18.1.1.0.0.171018が抽出されます。

   Oracle Exadata System Softwareリリース18.1.2以降を使用している場合、検証ステップ実行時にMy Oracle Supportからダウンロードされたパッチの名前が自動的に変更されます。

3. ストレージ・サーバーのソフトウェア更新を実行するための適切な時間を決定します。
4. 更新対象のセルをリストしたファイルを外部サーバー上に作成します。このファイルにcellsという名前を付けます。
5. dcliを使用して、セルの更新をスケジュールします。
   1. 必要に応じて、パスワードなしのアクセスを設定します。

      $ dcli –g cells –k 

   2. 更新時に使用するソフトウェア更新のZIPファイルの場所を指定します。

      $ dcli –g cells cellcli –e 'alter softwareUpdate store=\"https://host/exa-updates/cell\"'

   3. ストレージ・サーバーでOracle Exadata System Softwareの更新を開始する時刻を指定します。

      ソフトウェア・ストアの場所を入力する前に時間を指定すると、適切なストアの場所が設定される前にソフトウェア更新のダウンロードが開始される可能性があります。

      $ dcli –g cells cellcli –e 'alter softwareUpdate time=\"1 AM Thursday\"'
      

6. 更新が実行されるまで待機します。

   更新スケジュールの1週間前までに、管理サーバー(MS)によってファイルのダウンロードが開始され、事前チェックが実行されます。いずれかのセルがスケジュールどおりに更新されない場合は、MSによってアラートが生成されます。

8.6.3 Oracle Exadata Storage Serverの更新ユーティリティ

Oracle Exadata Storage Serverを更新するには、patchmgr更新ユーティリティを使用します。Exadataストレージ・サーバー更新の場合、ユーティリティは更新自体と同梱(および出荷)され、ストレージ・サーバー更新としてMy Oracle Supportからダウンロードできます。

ノート:

Exadataストレージ・サーバーの更新に使用されるpatchmgrは、Exadataデータベース・サーバー・ソフトウェア更新の適用に使用されるpatchmgrとは異なります。

保有しているExadataハードウェアがユーティリティでサポートされているかどうかは、更新しようとしているExadataストレージ・サーバー・リリースによって異なります。ユーティリティは、指定したExadataストレージ・サーバー全体にわたって更新処理をオーケストレートします。ユーティリティでは、ローリング方式または非ローリング方式で更新を実行できます。更新ユーティリティは、Exadataデータベース・サーバー、またはOracle LinuxかOracle Solarisを実行している他のサーバーから実行できます。

更新ユーティリティは、次のタスクを実行します。

• 準備、更新、検証の各ステップを自動化します。

• ロールバックを自動化します。

更新ユーティリティは、複数のセッションをサポートしています。そのため、Exadataストレージ・サーバーのリリース12.1.2.3.2以降およびExadataデータベース・サーバーのリリース11.2.3.1.0以降の同じサーバーから、複数の更新を同時に実行できます。つまり、同じサーバーから複数のラックを同時に更新できます。更新ユーティリティは、rootとしてもroot以外のユーザーとしても実行できます。デフォルトでは、更新ユーティリティはrootユーザーとして実行されることを前提としています。ただし、複数セッションのサポートを有効にしたり、root以外のユーザーとして実行する場合には、-log_dirフラグを使用する必要があります。-log_dirフラグは、ディスク上の場所とキーワードautoという2つのタイプの引数をサポートしています。autoを指定した場合、更新ユーティリティはcell_groupファイルにリストされているストレージ・サーバーに基づいて独自のログ・ディレクトリを作成します。この動作により、cell_groupファイルから1つ以上のクラスタが追加または削除されたものと同じクラスタ内に、更新の実行のたびに、更新ユーティリティによって新しいディレクトリが作成されます。このようなディレクトリを取得(および再利用)するために、更新ユーティリティでは-getフラグを使用して自分のセッション用のログ・ディレクトリを特定できます。-getフラグは、作業ディレクトリをスキャンしてログ・ディレクトリ内のディレクトリを調べ、cell_groupに対応するディレクトリを返します。たとえば、次のコマンド:

[oracle@nonExadataHost ]#./patchmgr -dbnodes ~/cell_group  -log_dir auto -get log_dir

以前のコメントによって、次のような出力が返される場合があります。

log_dir=/u01/test/patch_12.1.2.4.0.160802/log/dbm02celadm01_dbm02celadm02_9cfbc690

後続の更新セッションで、ログ・ディレクトリの場所を再利用できます。

[oracle@nonExadataHost ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -log_dir /u01/test/patch_12.1.2.4.0.160802/log
/dbm02celadm01_dbm02celadm02_9cfbc690

8.6.4 Oracle Exadata Storage Serverを更新する場合にお薦めするタイムライン

ノート:

Oracle Exadata System Softwareの更新を本番システムで実行する前に、テスト・システムで検証することをお薦めします。

次のアプローチに従うと、必要な是正処置を実行するための時間を確保できます。

表8-9 更新を実行するためのタイムライン

いつ	タスク
更新までの数週間から数日前	My Oracle Supportノート888828.1から必要なOracle Exadata System Softwareの更新をダウンロードします。 My Oracle Supportノート1070954.1から最新のOracle EXAchkをダウンロードします。 リリース固有のMy Oracle Supportノートで既知の問題を確認します。 Oracle EXAchkを実行します 前提条件チェックを実行します。詳細は、Exadataストレージ・サーバーを更新するための準備を参照してください。 要注意の結果を修正し、必要に応じて前述のステップを再実行します。
更新時	My Oracle Supportノート888828.1からOracle Exadata System Softwareの更新をダウンロードします。 My Oracle Supportノート1070954.1から最新のOracle EXAchkをダウンロードします。 リリース固有のMy Oracle Supportノートで既知の問題を確認します。 Oracle EXAchkを実行し、必要に応じて是正処置を行います。 必要に応じて前提条件チェックおよび是正処置を実行します。 更新を実行します。詳細は、Exadataストレージ・サーバーの更新の実行を参照してください。
更新後	Oracle EXAchkを実行します。

8.6.5 Exadataストレージ・サーバーを更新するための準備

Exadataストレージ・サーバーを更新する前に、次の準備ステップを実行します。

更新(およびロールバック)アクションは、ローリング方式または非ローリング方式で実行できます。また、前提条件チェックもローリング方式または非ローリング方式で実行できます。デフォルトは非ローリング方式です。

1. 更新ユーティリティを駆動するユーザーに対してSSH等価を設定します。
2. Oracle ExaCHKをダウンロードして実行します。未解決の問題がある場合は、確認して対処します。My Oracle Supportノート1070954.1を参照してください。
3. リリース固有のMy Oracle Supportノートで既知の問題および回避策を確認します。
4. 更新またはロールバックの方式に対して前提条件をチェックします。

   ローリング更新を実行するための前提条件:

   1. My Oracle Supportノート888828.1の記載に従って、Grid InfrastructureホームおよびDatabaseホームのソフトウェア・バージョンとパッチ・レベルがExadataストレージ・サーバー・ローリング・セル更新の最小要件を満たしていることを検証します。
   2. それぞれのOracle ASMディスク・グループについて、failgroup_repair_timeまたはdisk_repair_timeを検証します。

      ローリング方式で更新を適用する場合、更新ユーティリティは一度に1つのサーバーを更新します。まず、すべてのグリッド・ディスクおよびASMディスクをオフラインにし、次に、サーバーに更新を適用し、その後、すべてのASMディスクおよびグリッド・ディスクをオンラインに戻します。Oracle ASM修復タイムアウト属性disk_repair_timeおよびfailgroup_repair_timeは、1つのストレージ・サーバー更新を完了できる十分な大きさの値に設定する必要があります。それぞれのデフォルト値である3.6hおよび24hが推奨値です。ローリング中に、compatible.asmが12.1.0.2.0以上のストレージ・サーバー更新ディスク・グループはfailgroup_repair_timeの値を使用し、compatible.asmが12.1.0.2.0未満のディスク・グループはdisk_repair_timeの値を使用することに注意してください。

      ASM修復タイムアウト属性がデフォルト以上の値に設定されていることを検証してください。Oracle ASMインスタンスのすべてのマウント済ディスク・グループについて修復時間属性をチェックするには、次のコマンドを使用します。

      SQL> col attribute format a30
      SQL> col value format a10
      SQL> select dg.name as diskgroup, a.name as attribute, a.value
           from v$asm_diskgroup dg, v$asm_attribute a
           where dg.group_number=a.group_number
             and (a.name like '%repair_time' or a.name = 'compatible.asm');
      
      DISKGROUP                      ATTRIBUTE                      VALUE
      ------------------------------ ------------------------------ ----------
      DATA                           disk_repair_time               3.6h
      DATA                           failgroup_repair_time          24.0h
      DATA                           compatible.asm                 12.1.0.2.0
      RECO                           disk_repair_time               3.6h
      RECO                           failgroup_repair_time          24.0h
      RECO                           compatible.asm                 12.1.0.2.0
      
      

      ディスク・グループのOracle ASM修復タイマーがデフォルト値よりも低い場合には、修復タイマーを更新期間のデフォルト値に設定してください。すべてのストレージ・サーバーの更新が正常に完了した後で、現在値に戻してもかまいません。

   非ローリング更新を実行するための前提条件:

   1. 次のコマンドを使用して、各Exadataデータベース・サーバー上のOracleコンポーネントをシャットダウンして停止します。Grid_homeはOracle Grid Infrastructureソフトウェアがインストールされているディレクトリです。

      [root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl stop crs"
      

      前記のコマンドを使用してもOracle Clusterwareが停止しなかった場合は、次のコマンドを使用して強制的に停止します。

      [root@dm01 ]# crsctl stop crs -f
      

   2. 次のコマンドを使用して、Oracle Clusterwareステータスを確認します。Grid_homeはOracle Grid Infrastructureソフトウェアがインストールされているディレクトリです。

      [root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl check crs"
      

      すべてのOracle Clusterwareコンポーネントがオフラインである必要があります。Oracle VMを実行している構成で非ローリング更新を実行している場合には、すべてのVMクラスタでOracle Clusterwareの状態を確認する必要があります。

5. システムが次の条件を満たしているかどうかをチェックします。
   • Oracle Exadata Database MachineハードウェアがSunのサーバーを使用している。
   • インストール済のOracle Exadataソフトウェア・リリースがリリース11.2.2.2.0よりも前のものである。
   • インストール済のLinux ofaパッケージが1.5.1-4.0.28よりも前のものである。

   システムが前の条件をすべて満たしている場合に、Exadataストレージ・サーバーでOracle Linuxを実行していると、ファイル・システムが破損し、その結果、再起動後にルート・ファイル・システムが読取り専用としてマウントされることがあります。ストレージ・サーバーおよびデータベース・サーバーを更新する前に、My Oracle Supportノート1589868.1の指示に従ってください。

6. 更新を解凍します。patch_release.date_codeディレクトリに抽出されます。このパッチ・ディレクトリに移動します。

7. ターゲット・リリースのMy Oracle Supportノートに添付されているpatchmgrプラグインをダウンロードし、My Oracle Supportノートの記載に従ってインストールします。実際に更新の適用を開始する直前に、リリース・ノートに記載されているMy Oracle Supportノート、問題および回避策を確認することをお薦めします。
8. -cleanupフラグを使用して、以前の更新ユーティリティ実行をクリーン・アップします。

   ノート:

   初めてストレージ・サーバーを更新するときには、クリーン・アップを実行する前に、-reset_forceフラグを使用する必要があります。

   rootユーザーとして-reset_forceを使用する例:

   [root@dm01 ]# ./patchmgr -cells ~/cell_group –reset_force
   

   root以外のユーザーとして-reset_forceを使用する例:

   [oracle@nonExadataHost ]# ./patchmgr -cells ~/cell_group -log_dir auto –reset_force
   

   rootユーザーとして-cleanupを使用する例:

   [root@dm01 ]# ./patchmgr -cells ~/cell_group -cleanup
   

   root以外のユーザーとして-cleanupを使用する例:

   [oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto –cleanup
   

9. 前提条件チェックを実行します。

   Exadataデータベース・サーバーからrootユーザーとしてローリング更新の前提条件チェックを実行している例:

   [root@dm01 ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -rolling -smtp_from "[e-mail]"  
   -smtp_to [e-mail]
   

   Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング更新の前提条件チェックを実行している例:

   [oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch_check_prereq -smtp_from "[e-mail]"
   -smtp_to "[e-mail]"
   

8.6.6 Exadataストレージ・サーバーの更新の実行

Exadataストレージ・サーバーを更新するための準備で前提条件ステップを実行した後、実際の更新ステップを実行できます。

Exadataストレージ・サーバーに更新を適用するときには、次の点に注意してください。

• シリアル・コンソールまたはILOM Webベースのコンソールを使用して、更新ユーティリティを起動しないでください。

  シリアル・コンソールには、stderrまたはstdoutへの書込みが試行されると、システムが停止するという既知の問題があります。シリアル・コンソールから更新を開始した場合には、更新が停止することがあります。

  次のコマンドからの出力がserialである場合は、シリアル・コンソールを使用しています。

  [root@dm01 ]# ./echo $consoletype
  

• 必要に応じて、ILOM Webベースのコンソールを使用して、更新中にストレージ・サーバーを監視します。ILOM Webベースのコンソールは、トラブルシューティングが必要になった場合に使用する必要があります。

• ストレージ・サーバーのILOMおよびシリアル・コンソールにアクセスするには、rootユーザーとしてILOMホスト名またはIPアドレスへのSSHを使用します。シリアル・コンソールを起動するには、次を実行します。

  start /SP/console
  

  停止するには、[Esc]キーと(を順に押します。

• 更新手順またはロールバック手順ごとに新規ログイン・セッションを開始します。更新が適用されたのと同じログイン・セッションからロールバック手順を実行しないでください。ロールバック手順を実行したログイン・セッションから更新を実行しないでください。

• 更新処理を中断しないでください。

• ストレージ・サーバーをpatchmgrユーティリティ起動システムとして使用する必要がある場合は、更新のステージング領域として/opt/oracleを使用しないでください。このようにすると、更新が失敗し、ストレージ・サーバーが破損します。ステージング領域として/tmpディレクトリを使用してください。つまり、更新のファイルを/tmpに解凍します。

• 更新処理中に、ストレージ・サーバーは必要に応じて自動的に再起動します。更新の適用中に、ストレージ・サーバーを再起動したり、電源を入れ直さないでください。

• 書込み可能モードでログ・ファイルを編集したり、開かないでください。ログは、view、less、more、tailのいずれを使用しても表示できます。更新中にログ・ファイルを編集した場合には、更新処理が中断することがあります。

• patchmgrセッションの終了時、patchmgr.stdoutログ・ファイルは個々のストレージ・サーバー・ログ・ファイルに分かれ、それぞれcell_name.logという形式で名前が付与されます。また、/var/log/cellosの内容が非アクティブなセル・パーティションから/var/log/cellos/inactive_partitionディレクトリにコピーされます。非アクティブなパーティションの場所を特定するには、次のコマンドを使用します。

  [root@dm01 ]# ./imageinfo -inactive -sys
  

更新の実行例:

Exadataデータベース・サーバーからrootとしてローリング方式で更新を実行するには、次のようにします。

[root@dm01 ]# ./patchmgr -cells ~/cell_group -patch -rolling -smtp_from "[e-mail]" -smtp_to [e-mail]

Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング方式で更新を実行するには、次のようにします。

[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch -smtp_from "[e-mail]" -smtp_to "[e-mail]"

更新の完了後、-cleanupオプションを使用してストレージ・サーバーをクリーン・アップし、すべての一時的な更新ファイルまたはロールバック・ファイルをクリーン・アップします。このオプションでは、失効した更新状態とロールバック状態をクリーン・アップし、ストレージ・サーバー上で最大1.5GBのディスク領域をクリーン・アップします。このオプションは、更新ユーティリティの停止した実行または失敗した実行を再試行する前に使用してください。詳細は、ステップ8を参照してください。

8.6.7 Exadataストレージ・サーバーに対する更新のロールバック

更新したExadataストレージ・サーバーをロールバックできるのは、それが正常に更新されている場合のみです。つまり、imageinfoコマンドがアクティブ・イメージ・ステータスにsuccessを返す必要があります。更新が不完全か失敗したストレージ・サーバーはロールバックできません。ロールバックは、ローリング方式または非ローリング方式で行うことができます。

1. 次のコマンドで、ストレージ・サーバーがロールバックされるバージョンおよびflashCacheMode設定をチェックします。

   [root@dm01 ]# dcli -l root -g cell_group imageinfo -ver -inactive
   
   [root@dm01 ]# dcli -l root -g cell_group cellcli -e 'list cell attributes flashCacheMode
   

   ノート:

   ライトバック・フラッシュ・キャッシュを有効にした状態でストレージ・サーバーをリリース11.2.3.2.0よりも前のリリースにロールバックする必要がある場合は、ロールバック・アクションを実行する前に、フラッシュ・キャッシュをwritethroughフラッシュ・キャッシュに変換する必要があります。My Oracle Supportノート1500257.1のスクリプトを使用して、ライトバック・フラッシュ・キャッシュ無効にしてください。リリース11.2.3.2.0以上にロールバックされるストレージ・サーバーは、現在設定されているフラッシュ・キャッシュ・モードを保持します。

2. 次のコマンドを使用して、ロールバックの前提条件をチェックします。

   [root@dm01 ]# ./patchmgr -cells cell_group -rollback_check_prereq [-rolling]
   

3. ロールバックを実行します。

   rootとして非ローリング方式でロールバックを実行する例:

   [root@dm01 ]# ./patchmgr -cells ~/cell_group -rollback
   

   root以外のユーザーとしてローリング方式でロールバックを実行する例:

   [oracle@nonExadataHost ]#./patchmgr -cells ~/cell_group -rollback -rolling -log_dir auto
   

   ノート:

   以前のイメージにロールバックするときには、ファームウェア更新はロールバックされません。ロールバックした後、必要に応じて、次のコマンドを実行し、より古いバージョンのファームウェアを適用します。

   /etc/init.d/lsidiag stop
   
   /etc/init.d/lsi_mrdsnmpd stop
   
   /opt/oracle.cellos/CheckHWnFWProfile -action updatefw -mode exact

4. -cleanupオプションを使用してExadataストレージ・サーバーをクリーン・アップし、すべての一時的な更新ファイルまたはロールバック・ファイルをクリーン・アップします。このオプションでは、失効した更新状態とロールバック状態をクリーン・アップし、Exadataストレージ・サーバー上で最大1.5GBのディスク領域をクリーン・アップします。このオプションは、patchmgrユーティリティの停止した実行または失敗した実行を再試行する前に使用してください。

   [root@dm01 ]# ./patchmgr -cells cell_group -cleanup
   

8.7 RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードおよびダウングレード

このトピックでは、RoCEネットワーク・ファブリック・スイッチのファームウェアをアップグレードおよびダウングレードする手順について説明します。

RoCEネットワーク・ファブリック・スイッチ・ファームウェアを更新する場合は、次の点に注意してください。

• RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードおよびダウングレードは、patchmgrユーティリティを使用して実行します。
• Oracle Exadata System Softwareリリース19.3.0以降では、サーバーとRDMAネットワーク・ファブリック・スイッチ用に別々のpatchmgrディストリビューションがあります。RoCEネットワーク・ファブリック・スイッチのパッチZIPファイルに含まれているpatchmgrディストリビューションを使用していることを確認します。
• RoCEネットワーク・ファブリック・スイッチにアクセスできるマシンに適切なパッチZIPファイルをダウンロードします。パッチ情報は、My Oracle Supportノート888828.1を参照してください。
• patchmgrは、各スイッチに対するパスワードなしのsshアクセスを構成します。この場合、そのスイッチにadminユーザーのパスワードを入力する必要があります。
• root以外のユーザーを使用してパッチを実行する必要があり、patchmgrに-log_dirオプションを指定する必要があります。
• スイッチのファームウェアは、常にローリング形式でアップグレードします(一度に1つのスイッチ)。
• ストレージ・サーバーの更新は、RDMAネットワーク・ファブリック・スイッチの更新とは別に実行します。ストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチを同時に更新しないでください。RDMAネットワーク・ファブリックのネットワーク接続は、ストレージ・サーバーの更新のいくつかの重要な段階で安定している必要があります。RDMAネットワーク・ファブリック・スイッチのファームウェア更新にはスイッチの再起動が必要になるため、RDMAネットワーク・ファブリックの一部の接続に中断が発生します。
• 2022年8月のpatchmgrリリース以降、patchmgrはRoCEネットワーク・ファブリックで追加の一連のチェックを実行します。これらのチェックは、ファームウェア・アップグレードまたはダウングレードの直前および--roceswitch-precheckオプションを使用した前提条件チェック時に行われます。これらのチェックにより、RoCEネットワーク・ファブリックの予期しない問題に関連する障害のリスクが軽減されます。たとえば、ストレージ・サーバー上のRoCEネットワーク・ファブリック・ポートのいずれかが停止している場合、唯一の動作可能なポートに接続されているスイッチがアップグレードのためにオフラインになると、ストレージ・サーバーは使用できなくなります。チェックが失敗した場合、patchmgrは問題を報告し、ただちに終了します。この場合、アップグレードまたはダウングレードを実行する前に、RoCEネットワーク・ファブリックの問題を修正する必要があります。

次の手順を使用して、RoCEネットワーク・ファブリック・スイッチのファームウェアをアップグレードおよびダウングレードします。

• RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードまたはダウングレードの準備
  RoCEネットワーク・ファブリック・スイッチをアップグレードする場合は、特定の順序に従う必要があります。
• RoCEネットワーク・ファブリック・スイッチ・ファームウェア・ソフトウェアのアップグレード
  patchmgrコマンドを使用して、RoCEネットワーク・ファブリック・スイッチをアップグレードします。
• RoCEネットワーク・ファブリック・スイッチ・ファームウェアのダウングレード
  ファームウェアのダウングレードとは、古いファームウェアを適用することです。

8.7.1 RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードまたはダウングレードの準備

RoCEネットワーク・ファブリック・スイッチをアップグレードする場合は、特定の順序に従う必要があります。

1. RoCEネットワーク・ファブリック・スイッチへのアクセス権を持つサーバーにログインします。
2. サーバーに適切なパッチ・ファイルをダウンロードします。

   Oracle Exadata System Softwareリリース19.3.0以降では、スイッチの更新内容は個別のパッチに含まれています。パッチ情報は、My Oracle Supportノート888828.1を参照してください。

3. パッチ・ファイルを解凍します。

   ファイルがpatch_switch_releaseディレクトリに解凍されます。

4. patchmgrユーティリティを含むディレクトリに移動します。

   たとえば:

   # cd patch_switch_19.3.0.0.0.190915

5. RoCEネットワーク・ファブリック・スイッチの更新を駆動するためのスイッチのリスト・ファイルを作成します。
   1. アップグレードするスイッチのホスト名またはIPアドレスを含むファイルを作成します。スイッチは1行に1つずつ入力してください。
      たとえば、1行に1つのスイッチのホスト名が記載されるswitches.lstという名前のファイルを作成します。シングル・ラック・システムでは、ファイルの内容は次のようになります。

      switch123-rocea0
      switch123-roceb0

   2. 各行にタグを付けて、各スイッチの構成タイプを指定します。

      各スイッチの構成タイプを指定するには、スイッチのリスト・ファイルで各スイッチのホスト名またはIPアドレスにコロン(:)とタグを付けます。次のタグがサポートされます。

      • leaf - シングル・ラック・システムのリーフ・スイッチを示します。タグが指定されていない場合、この構成タイプであると見なされます。
      • mspine - スパイン・スイッチを示します。1つのスパイン・スイッチ構成では、Exadata Secure RDMA Fabric Isolationがある場合とない場合の、シングル・ラック・システムとマルチラック・システムのすべてのスパイン・スイッチがサポートされます。
      • mleaf - マルチラックX8Mシステムのリーフ・スイッチを示します。
      • sfleaf - Exadata Secure RDMA Fabric Isolationのサポートが有効なシングル・ラック・システムのリーフ・スイッチを示します。
      • msfleaf - Exadata Secure RDMA Fabric Isolationのサポートが有効なマルチラックX8Mシステムのリーフ・スイッチを示します。
      • leaf23 - 23個のホスト・ポートを持つように構成されたシングル・ラック・システムのリーフ・スイッチを示します。この構成は、3つのデータベース・サーバーと11個のストレージ・サーバーを持つ8ソケット・システム(X8M-8以降)にのみ必要です。
      • mleaf23 - 23個のホスト・ポートを持つように構成されたマルチラック・システムのリーフ・スイッチを示します。この構成は、3つのデータベース・サーバーと11個のストレージ・サーバーを持つ8ソケットX8M-8システムにのみ必要です。
      • mleaf_u14 - 14個のスイッチ間リンクで構成されたマルチラック・システムのリーフ・スイッチを示します。これはX9M以降のモデル・システムの一般的なマルチラック・リーフ・スイッチ構成です。
      • msfleaf_u14 - Exadata Secure RDMA Fabric Isolationのサポートが有効になっている、14個のスイッチ間リンクで構成されたマルチラック・システムのリーフ・スイッチを示します。この構成は、Secure Fabricが有効になっているX9M以降のモデル・システムに必要です。
      • mleaf23_u13 - 23個のホスト・ポートと13個のスイッチ間リンクで構成されたマルチラック・システムのリーフ・スイッチを示します。この構成は、3つのデータベース・サーバーと11個のストレージ・サーバーを持つ8ソケットX9M-8システムにのみ必要です。
      たとえば:

      switch123-rocea0:leaf
      switch123-roceb0:leaf

   3. マルチラック構成の場合のみ、各スイッチに一意のループバック・オクテットを指定します。

      ループバック・オクテットは、スイッチを一意に識別するスイッチ・ループバック・アドレスの最後のオクテットです。

      各スイッチのループバック・オクテットを指定するには、ピリオド(.)と数値のループバック・オクテット値を、スイッチのリスト・ファイルのタグが付けられた各スイッチのエントリに追加します。有効なループバック・オクテット値の範囲は次のとおりです。

      • 101-118 (リーフ・スイッチ)
      • 201-208 (スパイン・スイッチ)
      たとえば、2ラック・システムのスイッチのリスト・ファイルの内容は、次のようになります。

      rack1sw-rocea0:mleaf.101
      rack1sw-roceb0:mleaf.102
      rack1sw-roces0:mspine.201
      rack2sw-rocea0:mleaf.103
      rack2sw-roceb0:mleaf.104
      rack2sw-roces0:mspine.202

6. ファームウェアをアップグレードまたはダウングレードする前に、前提条件チェックを実行します。

   # ./patchmgr --roceswitches switches.lst {--upgrade | --downgrade} --roceswitch-precheck [--force]
     [-log_dir {absolute_path_to_log_directory | AUTO}]

   patchmgrコマンドの内容は、次のとおりです。

   • --roceswitch-precheckは、patchmgrに対して、スイッチでファームウェアのアップグレードまたはダウングレード・シミュレーションを実行するように指示します。

   • --forceは、オプションで、スイッチがすでにターゲット・ファームウェア・バージョンにある場合や、RoCEネットワーク・ファブリックに重大でない障害が発生している場合でも、操作を続行します。

   • -log_dirはログ・ディレクトリへの絶対パスを指定し、AUTOはログ・ディレクトリを自動的に作成するようにpatchmgrに指示します。このオプションは、root以外のユーザーとしてpatchmgrを実行している場合に必要です。

   ノート:

   Oracle Exadata System Softwareリリース19.3.9より前では、RoCEネットワーク・ファブリック・スイッチにパッチを適用するために、非rootユーザーとしてpatchmgrを実行する必要があります。

   ノート:

   現在のユーザーは、patchmgrを実行する前にSSHの同等性を構成しておく必要があります。構成されていない場合、patchmgrには、SSHの同等性のためにキーおよびキー交換を設定するオプションが用意されています。

   コマンドの出力で全体的なステータスがSUCCESSになった場合は、アップグレードに進みます。コマンドの出力で全体的なステータスがFAILになった場合は、出力でエラーのサマリーを確認し、どのチェックが失敗したかを特定して、エラーを修正します。すべてのエラーを修正した後、前提条件チェックを再実行し、成功するまでこれを繰り返します。

   ノート:

   ゴールデン構成設定がスイッチに適用されていないため、Config validation failedエラーが表示される場合があります。この場合は、現在のパッチからゴールデン構成設定を適用し、前提条件チェックを繰り返します。「Cisco Nexus 9336C-FX2 RoCEネットワーク・ファブリック・スイッチへのゴールデン構成設定の適用」を参照してください。

8.7.2 RoCEネットワーク・ファブリック・スイッチ・ファームウェア・ソフトウェアのアップグレード

patchmgrコマンドを使用して、RoCEネットワーク・ファブリック・スイッチをアップグレードします。

このタスクを開始する前に、「RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードおよびダウングレード」のノートを確認し、「RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードまたはダウングレードの準備」のステップを完了してください。

1. パッチをダウンロードしたサーバーで、patchmgrコマンドを使用してスイッチをアップグレードします。

   # ./patchmgr --roceswitches switches.lst --upgrade [--force]
     [-log_dir {absolute_path_to_log_directory | AUTO}]

   patchmgrコマンドの内容は、次のとおりです。

   • --forceは、オプションで、スイッチがすでにターゲット・ファームウェア・バージョンにある場合や、RoCEネットワーク・ファブリックに重大でない障害が発生している場合でも、操作を続行します。

   • -log_dirはログ・ディレクトリへの絶対パスを指定し、AUTOはログ・ディレクトリを自動的に作成するようにpatchmgrに指示します。このオプションは、root以外のユーザーとしてpatchmgrを実行している場合に必要です。

   ノート:

   Oracle Exadata System Softwareリリース19.3.9より前では、RoCEネットワーク・ファブリック・スイッチにパッチを適用するために、非rootユーザーとしてpatchmgrを実行する必要があります。
2. アップグレードを検証します。

   show versionコマンドを使用して、スイッチのファームウェア・バージョンを確認します。

   たとえば:

   # show version
   Cisco Nexus Operating System (NX-OS) Software
   TAC support: http://www.cisco.com/tac
   Copyright (C) 2002-2019, Cisco and/or its affiliates.
   All rights reserved.
   ...
   
   Software
     BIOS: version 05.33
     NXOS: version 7.0(3)I8(1)
     BIOS compile time: 09/08/2018
     NXOS image file is: bootflash:///nxos.7.0.3.I8.1.bin
     NXOS compile time: 3/5/2019 13:00:00 [03/05/2019 22:04:55]
   
   Hardware
     cisco Nexus9000 C9336C-FX2 Chassis
     Intel(R) Xeon(R) CPU D-1526 @ 1.80GHz with 24571632 kB of memory.
     Processor Board ID FDO23040CS1
   
     Device name: dbm01sw-rocea0
     bootflash: 115805356 kB
   Kernel uptime is 17 day(s), 20 hour(s), 50 minute(s), 25 second(s)
   
   Last reset at 188268 usecs after Mon Aug 12 17:14:40 2019
     Reason: Module PowerCycled
     System version:
     Service: HW check by card-client
   
   plugin
     Core Plugin, Ethernet Plugin
   
   Active Package(s):

8.7.3 RoCEネットワーク・ファブリック・スイッチ・ファームウェアのダウングレード

ファームウェアのダウングレードとは、古いファームウェアを適用することです。

ノート:

現在のストレージ・サーバーのリリースにより、ダウングレードできるリリースが決まります。これはリリースごとに異なることがあり、アップグレード前に使用していたファームウェアではない場合があります。アップグレード先のリリースに付属している、より古いファームウェアの詳細は、パッチのREADMEファイルを参照してください。

このタスクを開始する前に、「RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードおよびダウングレード」のノートを確認し、「RoCEネットワーク・ファブリック・スイッチ・ファームウェアのアップグレードまたはダウングレードの準備」のステップを完了してください。

1. patchmgrコマンドを使用して、RoCEネットワーク・ファブリック・スイッチのファームウェアをダウングレードします。

   # ./patchmgr --roceswitches switches.lst --downgrade [--force]
     [-log_dir {absolute_path_to_log_directory | AUTO}]

   patchmgrコマンドの内容は、次のとおりです。

   • --forceは、オプションで、スイッチがすでにターゲット・ファームウェア・バージョンにある場合や、RoCEネットワーク・ファブリックに重大でない障害が発生している場合でも、操作を続行します。

   • -log_dirはログ・ディレクトリへの絶対パスを指定し、AUTOはログ・ディレクトリを自動的に作成するようにpatchmgrに指示します。このオプションは、root以外のユーザーとしてpatchmgrを実行している場合に必要です。

   ノート:

   Oracle Exadata System Softwareリリース19.3.9より前では、RoCEネットワーク・ファブリック・スイッチにパッチを適用するために、非rootユーザーとしてpatchmgrを実行する必要があります。
2. show versionコマンドを使用して、スイッチ・ファームウェアがダウングレードされていることを確認します。

   # show version
   Cisco Nexus Operating System (NX-OS) Software
   TAC support: http://www.cisco.com/tac
   Copyright (C) 2002-2019, Cisco and/or its affiliates.
   All rights reserved.
   ...
   
   Software
     BIOS: version 05.33
     NXOS: version 7.0(3)I7(6)
     BIOS compile time: 09/08/2018
     NXOS image file is: bootflash:///nxos.7.0.3.I7.6.bin
     NXOS compile time: 3/5/2019 13:00:00 [03/05/2019 22:04:55]
   
   Hardware
     cisco Nexus9000 C9336C-FX2 Chassis
     Intel(R) Xeon(R) CPU D-1526 @ 1.80GHz with 24571632 kB of memory.
     Processor Board ID FDO23040CS1
   
     Device name: dbm01sw-rocea0
     bootflash: 115805356 kB
   Kernel uptime is 17 day(s), 20 hour(s), 50 minute(s), 25 second(s)
   
   Last reset at 188268 usecs after Mon Aug 12 17:14:40 2019
     Reason: Module PowerCycled
     System version:
     Service: HW check by card-client
   
   plugin
     Core Plugin, Ethernet Plugin
   
   Active Package(s):

8.8 InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアの更新

このトピックでは、InfiniBandネットワーク・ファブリック・スイッチのファームウェアをアップグレードおよびダウングレードする手順について説明します。

InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアを更新する場合は、次の点に注意してください。

• InfiniBandネットワーク・ファブリック・スイッチのアップグレードは、patchmgrを使用して実行します。

• 更新ユーティリティを使用できる最小スイッチ・ファームウェア・リリースは1.3.3-2です。スイッチのファームウェアは、常にローリング形式で更新します。

• InfiniBandネットワーク・ファブリック・スイッチにアクセスできるマシンに適切なパッチZIPファイルをダウンロードします。パッチ情報は、My Oracle Supportノート888828.1を参照してください。

• スイッチのファームウェアは、常にローリング形式でアップグレードします。

ノート:

Oracle Exadata System Softwareリリース19.3.0より前のストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチ更新には、Oracle Exadata System Softwareリリースにバンドルされているバージョンのpatchmgrを使用します。Oracle Exadata System Softwareリリース19.3.0以降、RDMAネットワーク・ファブリック・スイッチとストレージ・サーバーには個別のpatchmgrダウンロードが存在します。

ストレージ・サーバーの更新は、RDMAネットワーク・ファブリック・スイッチの更新とは別に実行します。ストレージ・サーバーとRDMAネットワーク・ファブリック・スイッチを同時に更新しないでください。RDMAネットワーク・ファブリックのネットワーク接続は、ストレージ・サーバーの更新のいくつかの重要な段階で安定している必要があります。RDMAネットワーク・ファブリック・スイッチのファームウェア更新にはスイッチの再起動が必要になるため、RDMAネットワーク・ファブリックの一部の接続に中断が発生します。

• InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアの更新の準備
  InfiniBandネットワーク・ファブリック・スイッチを更新する場合は、特定の順序に従う必要があります。
• InfiniBandネットワーク・ファブリック・スイッチ・ファームウェア・ソフトウェアの更新
  patchmgrコマンドを使用して、InfiniBandネットワーク・ファブリック・スイッチを更新します。
• InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアのダウングレード
  ファームウェアのダウングレードとは、Oracle Exadata System Software更新に付属している古いファームウェア更新を適用することです。

8.8.1 InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアの更新の準備

InfiniBandネットワーク・ファブリック・スイッチを更新する場合は、特定の順序に従う必要があります。

• ラックにスパイン・スイッチが存在する場合は、それを最初に更新する必要があります。
• ラックにスパイン・スイッチが存在しない場合は、まずサブネット・マネージャが実行されているスイッチを更新します。
• スイッチでサブネット・マネージャが実行されていない場合は、任意の順序で更新を実行できます。

InfiniBandネットワーク・ファブリック・スイッチを更新するには、スイッチのファームウェアがリリース1.3.3-2以上である必要があります。スイッチのファームウェアがそれより前のリリースである場合は、My Oracle Supportノート888828.1の説明に従って、ファームウェアをリリース1.3.3-2に更新します。

1. rootユーザーによるスイッチへのSSHアクセスが可能なOracle Exadataデータベース・サーバーにrootユーザーとしてログインします。
   データベース・サーバーは、スイッチと同じInfiniBandネットワーク・ファブリックのネットワークに属している必要があります。
2. InfiniBandネットワーク・ファブリック・スイッチが実行しているソフトウェアのバージョンを特定するには、versionコマンドを使用します。

   [root@dbm01-ibs0 ~]# version
   
   SUN DCS 36p version: 2.1.8-1
   Build time: Sep 18 2015 10:26:47
   SP board info:
   Manufacturing Date: 2015.07.01
   Serial Number: "NCDLD0049"
   Hardware Revision: 0x0200
   Firmware Revision: 0x0000
   BIOS version: SUN0R100
   BIOS date: 06/22/2010
   

3. データベース・サーバーに適切なパッチ・ファイルをダウンロードします。
   パッチ情報は、My Oracle Supportノート888828.1を参照してください。
4. 更新を解凍します。
   ファイルはpatch_release.dateディレクトリに解凍されます。
5. 更新する必要のあるInfiniBandネットワーク・ファブリック・スイッチをすべてリストしたファイルを作成します(1行につき1つのスイッチ)。

   ラック内のスイッチを識別するには、ibswitchesコマンドを使用します。同じファブリック上にOracle Exadata以外のエンジニアド・システムのスイッチが表示される場合がありますが、現時点では更新しないでください。

   次に、ibswitchesコマンドを実行した後に作成されるファイルの例を示します。

   [root@dm01 ]# cat ibswitches.lst
   myibswitch-01
   myibswitch-02

   ノート:

   ファイル名が指定されていない場合は、ibswitchesコマンドを実行することによってこのホストから検出されたすべてのInfiniBandネットワーク・ファブリック・スイッチでコマンドが実行されます。
6. patch_release.dateディレクトリに移動します。
7. 前提条件チェックを実行します。

   [root@dm01 ]# ./patchmgr --ibswitches ibswitches.lst --upgrade --ibswitch_precheck [--force] [--unkey]
   

   ノート:

   Oracle Exadata System Softwareリリース19.3.0以降、patchmgrコマンドでは、キーワードの前の単一ハイフンのかわりに--を使用します。

   --unkeyオプションは、終了する前に、InfiniBandネットワーク・ファブリック・スイッチへのパスワードなしのSSHアクセスを削除します。

   --forceオプションを指定すると、InfiniBandネットワーク・ファブリック・トポロジの障害とサーバーからスイッチへの接続がオーバーライドされます。スイッチのアップグレードには影響しません。

コマンドの出力で全体的なステータスがSUCCESSになった場合は、アップグレードに進みます。コマンドの出力で全体的なステータスがFAILになった場合は、出力でエラーのサマリーを確認し、どのチェックが失敗したかを特定して、エラーを修正します。すべてのエラーを修正した後、前提条件チェックを再実行し、成功するまでこれを繰り返します。

8.8.2 InfiniBandネットワーク・ファブリック・スイッチ・ファームウェア・ソフトウェアの更新

patchmgrコマンドを使用して、InfiniBandネットワーク・ファブリック・スイッチを更新します。

patchmgrユーティリティを使用できるスイッチ・ファームウェアの最小リリースは1.3.3-2です。スイッチ・ファームウェアはローリング形式でアップグレードされます。

• ラックにスパイン・スイッチが存在する場合は、スパイン・スイッチを最初にアップグレードします。
• ラックにスパイン・スイッチが存在しない場合は、最初にサブネット・マネージャが実行されているスイッチをアップグレードします。
• スイッチでサブネット・マネージャが実行されていない場合は、任意の順序でアップグレードを実行できます。

このタスクを開始する前に、InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアの更新の準備のステップを完了しておく必要があります。

1. スイッチへのrootユーザーによるSSHアクセスを持つOracle Exadataラックのデータベース・サーバーに、rootユーザーとしてログインします。
   データベース・サーバーは、スイッチと同じInfiniBandネットワーク・ファブリックのネットワークに属している必要があります。
2. データベース・サーバーに適切なパッチ・ファイルをダウンロードします。
   パッチ情報は、My Oracle Supportノート888828.1を参照してください。
3. パッチ・ファイルを解凍します。
   ファイルはpatch_release.dateディレクトリに解凍されます。
4. patch_release.dateディレクトリに移動します。
5. patchmgrを使用して、前提条件チェックを実行します。

   --unkeyオプションは、終了する前に、InfiniBandネットワーク・ファブリック・スイッチへのパスワードなしのSSHアクセスを削除します。

   --forceオプションを指定すると、InfiniBandネットワーク・ファブリック・トポロジの障害とサーバーからスイッチへの接続がオーバーライドされます。スイッチのアップグレードには影響しません。

   # ./patchmgr --ibswitches ibswitches.lst --upgrade --ibswitch_precheck [--force] [--unkey]
   

   ノート:

   Oracle Exadata System Softwareリリース19.3.0以降、patchmgrコマンドでは、キーワードの前の単一ハイフンのかわりに--を使用します。

   コマンドの出力で全体的なステータスがSUCCESSになった場合は、アップグレードに進みます。

   コマンドの出力で全体的なステータスがFAILになった場合は、出力でエラーのサマリーを確認し、どのチェックが失敗したかを特定して、エラーを修正します。

   エラーを修正したら、前提条件チェックを再実行し、成功するまでこれを繰り返します。

6. 次のコマンドを使用して、スイッチをアップグレードします。

   [root@dm01 ]# ./patchmgr --ibswitches ibswitches.lst --upgrade [--force] [--unkey]

7. コマンドの出力をチェックし、アップグレードを検証します。

   出力はSUCCESSになる必要があります。エラーが存在する場合は、それらのエラーを修正し、アップグレード・コマンドを再実行してください。

8.8.3 InfiniBandネットワーク・ファブリック・スイッチ・ファームウェアのダウングレード

ファームウェアのダウングレードとは、Oracle Exadata System Software更新に付属している古いファームウェア更新を適用することです。

現在のOracle Exadata System Softwareの更新により、ダウングレードできるリリースが決まります。これはリリースごとに異なることがあり、更新前に使用していたファームウェアではない場合があります。更新先のリリースに付属している、より古いファームウェアの詳細は、パッチのREADMEファイルを参照してください。

このタスクのすべてのステップを、rootユーザーとして完了します。

1. patchmgrコマンドに--precheckオプションを指定して実行し、スイッチのファームウェアをダウングレードする準備ができていることを確認します。

   ibswitches.lstファイルは、更新する必要があるInfiniBandネットワーク・ファブリック・スイッチのホスト名がすべて含まれるファイルです(1行につき1つのスイッチ)。

   # ./patchmgr --ibswitches ibswitches.lst --downgrade --ibswitch_precheck [--force] [--unkey]

   ノート:

   Oracle Exadata System Softwareリリース19.3.0以降、patchmgrコマンドでは、キーワードの前の単一ハイフンのかわりに--を使用します。

   --unkeyオプションは、終了する前に、InfiniBandネットワーク・ファブリック・スイッチへのパスワードなしのSSHアクセスを削除します。

   --forceオプションを指定すると、InfiniBandネットワーク・ファブリック・トポロジの障害とサーバーからスイッチへの接続がオーバーライドされます。スイッチのアップグレードには影響しません。

2. patchmgrコマンドを使用して、InfiniBandネットワーク・ファブリック・スイッチのファームウェアをダウングレードします。

   # ./patchmgr --ibswitches ibswitches.lst --downgrade [--force] [--unkey]

3. versionコマンドを使用して、スイッチのファームウェアがダウングレードされていることを確認します。

   # version
   
   SUN DCS 36p version: 2.1.8-1
   Build time: Sep 18 2015 10:26:47
   SP board info:
   Manufacturing Date: 2015.07.01
   Serial Number: "NCDLD0049"
   Hardware Revision: 0x0200
   Firmware Revision: 0x0000
   BIOS version: SUN0R100
   BIOS date: 06/22/2010

8.9 Oracle LinuxでのOracle Java SEのアップグレード

データベース・サーバーおよびストレージ・サーバーでOracle Linux を実行しているOracle Java SE (JDK)をアップグレードできます。

Oracle Exadata System Softwareリリース12.1.2.1.0以降では、Oracle ExadataサーバーにJava JDKパッケージが含まれています。以前のリリースのOracle Exadata System Softwareでは、JDKパッケージは使用されません。以前のリリースのOracle Exadata System Softwareを実行しているサーバーにjava-version-openjdkなどのパッケージがインストールされている場合、パッケージはOracle Exadataによって使用されず、削除が可能です。

JDKパッケージを更新するには、JDK RPMパッケージをダウンロードして更新し、新しいJDKパッケージを使用するようにMSを再構成する必要があります。JDKパッケージを更新するには、ULN (Oracle Linux 6以降を使用)を使用するようYUMを構成するか、パッケージを直接ダウンロードします。

• MSプロセスの停止
  JDKパッケージを更新する前に、管理サーバー(MS)を停止する必要があります。
• Java JDKパッケージのダウンロードおよび更新
  現在の環境に応じて、3つの手順のいずれかを使用してJDKパッケージをダウンロードおよび更新できます。
• 管理サーバー(MS)の再構成および再起動
  Java JDKパッケージを更新したら、MSを再構成して再起動する必要があります。

8.9.1 MSプロセスの停止

JDKパッケージを更新する前に、管理サーバー(MS)を停止する必要があります。

1. rootユーザーとして、サーバーにログインします。
2. MSを停止します。

   • データベース・サーバー上:

     dbmcli -e alter dbserver shutdown services ms

   • ストレージ・サーバー上:

     cellcli -e alter cell shutdown services ms

8.9.2 Java JDKパッケージのダウンロードおよび更新

現在の環境に応じて、3つの手順のいずれかを使用してJDKパッケージをダウンロードおよび更新できます。

YUMおよびUnbreakable Linux Network (ULN)の使用は、Oracle Linuxを実行しているOracle Exadataオンプレミス・データベース・サーバーでのみサポートされます。これは、ストレージ・サーバーまたはOracle VM環境の管理ドメイン(dom0)またはユーザー・ドメイン(domU)ではサポートされていません。

次のいずれかの方法を使用して、JDKパッケージをダウンロードおよび更新します。

• YUMおよびULNを使用したデータベース・サーバーのJDKパッケージの更新
  オンプレミスのOracle Exadataのデータベース・サーバーがOracle Linux 6以降を実行している場合、YUMおよびUnbreakable Linux Network (ULN)を使用して更新プロセスを簡略化できます。
• Oracle Exadata System Softwareバージョン12.1.2.1.0から12.1.2.2.0へのJDKパッケージの手動更新
  最新バージョンのパッケージをダウンロードし、rpmユーティリティを使用してインストールすることで、JDK 7パッケージを最新リリースに更新します。
• Oracle Exadata System Softwareリリース12.1.2.2.1以降でのJDKパッケージの手動更新
  最新バージョンのパッケージをダウンロードし、rpmユーティリティを使用してインストールすることで、JDK 8パッケージを最新リリースに更新します。

8.9.2.1 YUMおよびULNを使用したデータベース・サーバーのJDKパッケージの更新

オンプレミスのOracle Exadataのデータベース・サーバーがOracle Linux 6以降を実行している場合、YUMおよびUnbreakable Linux Network (ULN)を使用して更新プロセスを簡略化できます。

JDKパッケージを直接ダウンロードするか、YUMおよびULNを使用できます。YUMおよびULNを使用したJDKパッケージの更新には、次のタスクが含まれます。

• Oracleパブリック・リポジトリに接続するためのYUMの構成
  Oracle Linux YUMサーバーは、最新のOracle Linuxパッケージをインストールするための無料で便利な方法を提供します。Unbreakable Linux Network (ULN)では、特定のバージョンのパッチおよび正誤表を更新できます。
• Oracle Linux システムのULNへの登録
  YUMリポジトリへのアクセスを構成したら、Oracle Linuxデータベース・サーバーをULNに登録する必要があります。
• ULNを使用したデータベース・サーバーでのJDKのアップグレード
  

8.9.2.1.1 Oracleパブリック・リポジトリに接続するためのYUMの構成

Oracle Linux YUMサーバーは、最新のOracle Linuxパッケージをインストールするための無料で便利な方法を提供します。Unbreakable Linux Network (ULN)では、特定のバージョンのパッチおよび正誤表を更新できます。

この手順は、Oracle Linuxを実行しているOracle Exadataオンプレミス・データベース・サーバーでのみサポートされます。これは、ストレージ・サーバーまたはOracle VM環境の管理ドメイン(dom0)またはユーザー・ドメイン(domU)ではサポートされていません。

Oracle Linux Yum Serverはパブリック・リポジトリです。Oracle Linux Yum Serverから更新を入手する方法の詳細は、http://yum.oracle.comを参照してください。ULNの詳細は、http://linux.oracle.comを参照してください。

1. データベース・サーバー上のrootユーザーとして、RHNS-CA-CERT証明書が期限切れになっていないことを確認します。

   # yum list installed

   証明書が期限切れの場合は、My Oracle SupportのドキュメントID 2207336.1を参照して問題を修正してください。

2. /etc/yum.repos.dディレクトリに移動します。

   # cd /etc/yum.repos.d

3. リポジトリ構成ファイルをダウンロードします。

   curlユーティリティを使用して、システムにとって適切なリポジトリ構成ファイルをダウンロードします。かわりに、http://yum.oracle.com/public-yum-release.repoの内容をファイルにコピーできます。この場合、releaseはOracle Linuxリリースに対応します(例: ol6またはol7)。

   たとえば、curlを使用してOracle Linux 6リポジトリの構成を取得するには、次のコマンドを使用します。

   # curl -O http://yum.oracle.com/public-yum-ol6.repo

   詳細は、次を参照してください。
4. データベース・サーバーでrhn-setupパッケージをインストールして、uln_registerを有効にします。

   警告:

   ストレージ・サーバーをULNまたはパブリックyumサーバーに登録しないでください。

   # yum install rhn-setup.noarch

警告:

最新リリースのOracle Linuxを使用していない場合は、ファイル/etc/yum.repos.d/public-yum-ol6.repoを編集し、システム・バージョンと一致するように正しいリポジトリを有効にする必要があります。Oracleサポート・サービスに連絡して、My Oracle SupportのドキュメントID 2241729.1を参照してください。

8.9.2.1.2 Oracle Linux システムのULNへの登録

YUMリポジトリへのアクセスを構成したら、Oracle Linuxデータベース・サーバーをULNに登録する必要があります。

警告:

ストレージ・サーバーをULNまたはパブリックyumサーバーに登録しないでください。

1. uln_registerを実行して、ULNにシステムを登録します。

   # uln_register

   ULNアカウントがない場合は、https://linux.oracle.comで登録できます。ULNの登録には、Oracle LinuxまたはOracle VMサポートの有効なカスタマ・サポートID (CSI)が必要です。

   システムを登録するときに、プロキシ・サーバーが必要な場合は、––proxyオプションを使用して、使用するHTTPプロキシを指定します。

   # uln_register --proxy=proxy_hostname:port_number

   プロキシに認証が必要な場合は、追加のオプション--proxyUserおよび--proxyPasswordを使用してユーザー名とパスワードを指定します。

   # uln_register --proxy=proxy_hostname:port_number 
   --proxyUser=username --proxyPassword=password

2. プロンプトが表示されたら、ULNユーザー名、パスワードおよびCSIを入力します。
   
   
   図uln_login_screen.jpgの説明
   
3. 「プロファイルの作成 — ハードウェア」ページで、必要な情報を入力します。
   1. ULNで識別できるシステムの名前を入力します。
   2. ULNでシステムに適切なパッケージを選択できるようにするハードウェアおよびソフトウェア・プロファイル・データをアップロードするかどうかを選択します。
      
      
      図uln_create_profile_screen.jpgの説明
      

8.9.2.1.3 ULNを使用したデータベース・サーバーでのJDKのアップグレード

このステップを開始する前に、「MSプロセスの停止」のステップを完了していることを確認してください。

YUMリポジトリを構成し、データベース・サーバーをULNに登録した後、ULNチャネルからRPMをダウンロードできます。

Oracle Exadata System Softwareバージョン12.1.2.1.0から12.1.2.2.0の場合、Oracle Exadata Database Serverには、RPMとしてインストールされるJDK 7パッケージが含まれています。RPMを更新するには、ULNチャネルのJava SE 7 for Oracle Linuxを使用します。JDK 7を確認してください。JDK 8以降は使用しないでください。

Oracle Exadata System Softwareバージョン12.1.2.2.1以降の場合、Oracle Exadata Database Serverには、RPMとしてインストールされるJDK 8パッケージが含まれています。RPMを更新するには、ULNチャネルのJava SE 8 for Oracle Linuxを使用します。JDK 8を確認してください。

警告:

ストレージ・サーバーをULNに登録しないでください。

1. Webブラウザを使用してhttps://linux.oracle.com/にログインします。
2. Oracle Java SEをインストールするOracle Exadata Database Serverを見つけて、そのシステムの名前をクリックします。

   次のイメージでは、サーバー名は非表示になりました。

   
   
   図uln_registered_systems.jpgの説明
   
3. 「サブスクリプションの管理」をクリックします。
4. 矢印ボタンを使用して、目的のJava SEチャネルを「使用可能なチャネル」リストからサブスクライバ・チャネルリストに移動し、「サブスクリプションの保存」をクリックします。
   
   
   図uln_manage_subscriptions.jpgの説明
   
5. プロンプトが表示されたら、「承認」をクリックしてライセンス契約に同意します。
6. データベース・サーバーで、yum.repos.dディレクトリからJDKをアップグレードします。

   # yum check-update jdk
   Loaded plugins: rhnplugin, ulninfo
   This system is receiving updates from ULN.
   ol6_x86_64_JavaSE7_public
   By downloading and/or using this software program you agree that your use is 
   subject to the applicable license agreement at https://linux.oracle.com
   /licenses.html.
   
   exadata_dbserver_18.1.4.0.0_x86_64_base                        | 1.2 kB   00:00
   exadata_dbserver_18.1.4.0.0_x86_64_base/primary                | 436 kB   00:00
   exadata_dbserver_18.1.4.0.0_x86_64_base                                     470/470
   ol6_x86_64_JavaSE7_public                                      | 1.2 kB   00:00
   ol6_x86_64_JavaSE7_public/primary                              | 5.9 kB   00:00
   ol6_x86_64_JavaSE7_public                                                     16/16
   ol6_x86_64_ksplice                                             | 1.2 kB   00:00
   ol6_x86_64_ksplice/primary                                     | 160 kB   00:00
   ol6_x86_64_ksplice                                                        1436/1436
   public_ol6_latest                                                       40132/40132
   ...
   Running transaction
     Installing : jdk1.8.0_172-1.8.0_172-fcs.x86_64                                        1/1 
   Unpacking JAR files...
   	rt.jar...
   	jsse.jar...
   	charsets.jar...
   	localedata.jar...
   	jfxrt.jar...
     Verifying  : jdk1.8.0_172-1.8.0_172-fcs.x86_64                                       1/1 
   
   Installed:
     jre.x86_64 0:1.8.0_172-fcs                                                
   
   Complete!

JDKの更新を完了するには、「管理サーバー(MS)の再構成および再起動」のステップに従います。

8.9.2.2 Oracle Exadata System Softwareバージョン12.1.2.1.0から12.1.2.2.0へのJDKパッケージの手動更新

最新バージョンのパッケージをダウンロードし、rpmユーティリティを使用してインストールすることで、JDK 7パッケージを最新リリースに更新します。

このステップを開始する前に、「MSプロセスの停止」のステップを完了していることを確認してください。

Oracle Exadata System Softwareバージョン12.1.2.1.0から12.1.2.2.0では、Oracle Exadata Storage Serverには、RPMとしてインストールされるJDK 7パッケージが含まれています。

(dbnodeupdateまたはpatchmgrを使用して)サーバー・イメージへのアップグレード後、JDKのバージョンを確認します。アップグレード中にJDKパッケージが古いバージョンに戻った場合、ここでの手順を使用してJDKパッケージを最新バージョンに更新します。

1. My Oracle SupportのドキュメントID 1439822.1にあるリンクを使用して、JDK 7の最新バージョンをダウンロードします。JDK 8以降をダウンロードしないでください。
2. ZIPファイルの内容を抽出します。
3. JDK RPMを見つけます。
   ファイルの名前はjdk-version-linux-x64.rpmのようになります(たとえばjdk-7u91-linux-x64.rpm)。
4. RPMファイルのみをターゲット・サーバーにコピーします。
   ファイルは、/tmpなどの一時ディレクトリに配置できます。
5. rootユーザーとして、インストールされているJDK RPMの現在のバージョンを決定します。

   # rpm -q jdk

6. JDKパッケージがインストールされ、更新する必要がある場合は、rpmコマンドを使用して更新をインストールします。

   # rpm -Uvh /tmp/jdk-version-linux-x64.rpm

7. JDKパッケージが更新されたことを確認します。

   # rpm -q jdk

8. ステージングされた更新ファイルを削除します。

   # rm -f /tmp/jdk-version-linux-x64.rpm

JDKの更新を完了するには、「管理サーバー(MS)の再構成および再起動」のステップに従います。

8.9.2.3 Oracle Exadata System Softwareリリース12.1.2.2.1以降でのJDKパッケージの手動更新

最新バージョンのパッケージをダウンロードし、rpmユーティリティを使用してインストールすることで、JDK 8パッケージを最新リリースに更新します。

このステップを開始する前に、「MSプロセスの停止」のステップを完了していることを確認してください。

Oracle Exadata System Softwareリリース12.1.2.2.1以降では、Oracle Exadata Serverには、RPMとしてインストールされるJDK 8パッケージが含まれています。

(dbnodeupdateまたはpatchmgrを使用して)サーバー・イメージへのアップグレード後、JDKのバージョンを確認します。アップグレード中にJDKパッケージが古いバージョンに戻った場合、ここでの手順を使用してJDKパッケージを最新バージョンに更新します。

1. My Oracle SupportのドキュメントID 1439822.1にあるリンクを使用して、JDK 8の最新バージョンをダウンロードします。JDK 8の更新のみをダウンロードします。
2. ZIPファイルの内容を抽出します。
3. JDK RPMを見つけます。
   ファイルの名前はjdk-version-linux-x64.rpmのようになります(たとえばjdk-8u172-linux-x64.rpm)。
4. RPMファイルのみをターゲット・サーバーにコピーします。
   ファイルは、/tmpなどの一時ディレクトリに配置できます。
5. rootユーザーとして、インストールされているJDK RPMの現在のバージョンを決定します。

   # rpm -qa|grep jdk
   jdk1.8.0_66-1.8.0_66-fcs.x86_64

6. JDKパッケージがインストールされ、更新する必要がある場合は、rpmコマンドを使用して更新をインストールします。

   # rpm -Uvh /tmp/jdk-version-linux-x64.rpm

7. JDKパッケージが更新されたことを確認します。

   JDK 8では、更新されたパッケージによって現在インストールされているパッケージが置き換えられないため、2つのバージョンのJDKパッケージがインストールされます。

   # rpm -qa | grep jdk
   jdk1.8.0_66-1.8.0_66-fcs.x86_64
   jdk1.8.0_172-1.8.0_172-fcs.x86_64

8. 古いJDKパッケージをサーバーから削除します。
   古いバージョンが更新66だった場合、コマンドは次のようになります。

   # rpm -e --nodeps jdk.1.8.0_66-1.8.0_66-fcs.x86_64

9. 更新されたJDKのみがサーバーで使用できることを確認します。

   # rpm -qa |grep jdk
   jdk1.8.0_172-1.8.0_172-fcs.x86_64

10. ステージングされた更新ファイルを削除します。

    # rm -f /tmp/jdk-version-linux-x64.rpm

JDKの更新を完了するには、「管理サーバー(MS)の再構成および再起動」のステップに従います。

8.9.3 管理サーバー(MS)の再構成および再起動

Java JDKパッケージを更新したら、MSを再構成して再起動する必要があります。

1. データベース・サーバーまたはストレージ・サーバーにrootとしてログインします。
2. MSが停止していることを確認します。
   • データベース・サーバー上:

     dbmcli -e alter dbserver shutdown services ms

   • ストレージ・サーバー上:

     cellcli -e alter cell shutdown services ms

3. MSを再構成します。

   システムで次を実行します:

   • Oracle Exadata System Softwareリリース12.2.x、バージョン12.2.1.1.4以降。

   • Oracle Exadata System Softwareリリース18c、バージョン18.1.2以降。

   • リリース19.1.0以降のすべてのOracle Exadata System Softwareバージョン。

   1. UNIXスクリプト・ディレクトリに移動します。
      • データベース・サーバー上:

        cd /opt/oracle/dbserver/dbms/deploy/scripts/unix

      • ストレージ・サーバー上:

        cd /opt/oracle/cell/cellserv/deploy/scripts/unix

   2. MSを再デプロイします。
      • データベース・サーバー上:

        sh setup_dynamicDeploy DB

      • ストレージ・サーバー上:

        sh setup_dynamicDeploy

4. MSを再起動します。
   • データベース・サーバー上:

     dbmcli -e alter dbserver startup services ms

   • ストレージ・サーバー上:

     cellcli -e alter cell startup services ms

8.10 SSH等価の設定

Oracle Exadata Database Machine上でソフトウェアを更新する前に、SSH等価を構成する必要があります。

Oracle Exadata Database Server、Oracle Exadata Storage ServerおよびRDMAネットワーク・ファブリック・スイッチのExadata更新ユーティリティは、Oracle Linuxを実行している任意のサーバーから、rootユーザーまたはroot以外のユーザーのどちらとしてでも実行できます。ターゲットのExadataサーバーのrootユーザーに対してSSH等価が設定されているかぎり、ユーティリティでは任意のExadataサーバーで前提条件チェック、更新、ロールバックの各アクションを実行できます。

1. cell_groupまたはdbs_groupという名前のファイルを作成し、更新するストレージ・サーバーまたはデータベース・サーバーのそれぞれについて、ストレージ・サーバーまたはデータベース・サーバーのホスト名またはIPアドレスを1行に1つずつ記載します。
2. 既存のSSH等価がないかどうかを確認します。
   次のコマンドでは、パスワードを求められることはなく、ユーザーによる操作も必要ありません。cell_groupファイルに記載されたホスト名のリストを返します。

   [oracle@nonExadataHost ]# ./dcli -g cell_group -l root 'hostname -i'

3. SSH等価をまだ設定していない場合には、起動サーバーから設定します。
   root SSH等価がすでにある場合は、このステップを実行しないでください。
   次のコマンドを使用して、SSHキーを生成します。

   [oracle@nonExadataHost ]# ssh-keygen [-t rsa]

   -tオプションを使用して、キー・タイプ(RSAまたはDSAなど)を指定できます。-tオプションを指定しない場合、RSAはデフォルトで構成されています。

   rootユーザーのSSHキーが作成されるように、デフォルト値をそのまま使用します。

4. SSHキーをプッシュしてSSH等価を設定します。
   プロンプトが表示されたら、rootのパスワードを入力します。

   [oracle@nonExadataHost ]# dcli -g cell_group -l root –k

ノート:

安全な環境を構築しているお客様の場合、Oracle Exadata Storage ServerへのSSHアクセスを無効にしていることがあります。通常の操作中に、Oracle Exadata Storage ServerがSSHアクセスを必要とすることはありません。一方、更新ユーティリティなどの管理用ユーティリティでは、SSHアクセスを必要とします。ストレージ・サーバーのロック解除の詳細は、ストレージ・サーバーでのSSHの無効化のトピックのサブ項目、セルの一時的なロック解除を参照してください。

8.11 Oracle Exadataでのソフトウェア更新のトラブルシューティング

Oracle Exadataでソフトウェアの更新時にエラーまたは問題が発生した場合に、次のトピックを確認します

• Exadataデータベース・サーバー更新のトラブルシューティング
  更新ユーティリティによって生成されるログ・ファイルを使用して、更新をトラブルシューティングできます。
• Exadataストレージ・サーバー更新の監視、検証およびトラブルシューティング
  
• Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティング
  カスタムrpmがインストールされているExadataデータベース・サーバーで前提条件チェックまたは更新を実行すると、競合によって前提条件チェックまたは更新が失敗する場合があります。
• Exadataデータベース・サーバーでのmultilib問題のトラブルシューティング
  

8.11.1 Exadataデータベース・サーバー更新のトラブルシューティング

更新ユーティリティによって生成されるログ・ファイルを使用して、更新をトラブルシューティングできます。

更新ユーティリティは、Exadataデータベース・サーバーの更新をオーケストレートします。patchmgrツールを使用したデータベース・ノードの更新は簡潔で、最小限の情報のみが画面に出力されます。追加情報が必要な場合は、patchmgrログと、patchmgrが他のサーバーからコピーしたdbnodeupdate.shログ(使用できる場合)を確認できます。ログ・ファイル(dbnodeupdate.log)およびdiagファイル(dbnodeupdate.<runid>.diag)は、最終的に次の2つの場所に存在します。

• 更新した各データベース・サーバー上の/var/log/cellosディレクトリに配置されます。
• 更新ユーティリティを実行しているノード上に統合されます。

更新ユーティリティを実行しているノード上では、-log_dirフラグをautoに設定した場合、ログ・ファイルはlog/<リスト・ファイル内のノードのコンテンツに基づいたディレクトリ>ディレクトリ(更新ユーティリティが起動されたディレクトリからの相対位置)に格納されます。たとえば、更新ユーティリティが/u01/dbserver.patchにある場合、ログ・ディレクトリは/u01/dbserver.patch/dm01db01_dm01db02_e8f1f753のようになります。

ログ・ディレクトリにある重要なファイルは次のとおりです。

• patchmgr.logには、様々なデータベース・サーバーでリモート更新コマンドを実行したときの画面出力がまとめられています。
• <hostname>_dbnodeupdate.<runid>.diagは、データベース・サーバーでの特定の実行に関するdiagファイルです。
• <hostname>_dbnodeupdate.logには、dbnodeupdate.logの出力にリモート・データベース・サーバーの/var/log/cellosからの情報を追記したものが含まれています。

前提条件チェック、バックアップ更新またはロールバックが失敗すると、画面上のエラー・メッセージには、どのノードでどのステップが失敗したかに関する情報が示されます。詳細な情報が必要な場合には、前述のログ・ファイルを参照してください。ログ・ファイルで新しい実行の開始を検索してください(zzzを検索します)。

その時間が実行に一致するかどうかをチェックします。一致した場合は、さらに調べるためにrunidをノートにとります。次に、ERRORを検索します。

実際のYUM更新よりも前に更新アクションが失敗した場合は、エラーを解決した後で更新を再試行できます。更新が途中で失敗した場合は、ロールバックし、エラーを解決してから再試行することをお薦めします。

まれに、patchmgrで更新のステータス(更新の成否)を判断できないことがあります。このような場合は、更新が失敗したことを示すメッセージが表示されます。ただし、更新が正常に完了している可能性もあります。更新の実際のステータスを確認するには:

• (データベース)ノードのイメージ・ステータスをチェックします。これを行うには、imageinfoコマンドを実行します。「Image status 」行にステータスが表示されます。
• Exadataソフトウェアのバージョンをチェックします。これはimageinfoコマンドから確認することもできます。

イメージ・ステータスが成功(success)で、Exadataバージョンが予想される新しいバージョンの場合、更新は成功しているため、update failed (更新の失敗)メッセージは無視して構いません。その後、次の手順を実行します。

• 特定のノード上でdbnodeupdate.sh -cを手動で実行し、更新の完了ステップを実行します。
• 完了したノードを(データベース)ノード・ファイルから削除します。
• patchmgrを再実行し、残りのノードに対して更新を実行します。

更新が失敗したかどうかのチェックには、次のようなものがあります。

• patchmgrを使用してデータベース・ノードを更新するための正しい構文は、patchmgrオンライン・ヘルプを参照してください。
• patchmgrを使用する前にSSH等価を構成する必要があります。
• My Oracle Supportノート1553103.1から最新のdbserver.patch.zipをダウンロードします。
• patchmgrオーケストレーションに失敗した理由を分析するには、Oracleサポート・サービスでサービス・リクエストを開きます。

8.11.2 Exadataストレージ・サーバー更新の監視、検証およびトラブルシューティング

更新対象のExadataストレージ・サーバーを監視する方法として、電子メール・アラートを使用することをお薦めします。これらのアラートを設定するには、更新ユーティリティで-smtp_fromフラグおよび-smtp_toフラグに電子メール・アドレスを指定します。

トラブルシューティングのために必要となった場合には、別のターミナル・セッションまたはターミナル・ウィンドウからless -rf patchmgr.stdoutを使用して更新アクティビティを監視して、更新ユーティリティが出力した未加工のログの詳細を表示できます。

また、ストレージ・サーバーのアクティビティを監視することもでき、そのためには、更新ユーティリティが起動した5分後に、更新対象の個々のストレージ・サーバーのシリアル・コンソールまたはWebベースのILOMコンソールにログインします。5分待つと、更新ユーティリティがILOMをリセットする時間を確保できます。ILOMをリセットすると、WebベースのILOMコンソールおよびシリアル・コンソールから切断されます。ILOMがリセットされた後、再接続できます。5分待つことによって、再接続する必要がなくなります。ILOMの更新中には接続が失われ、再接続が必要になります。ILOMには、更新アクションが表示されません。必要に応じて、プロセスが正しく進行していることを確認できるように、通常のセル起動や再起動やその他のアクティビティを監視すると有用です。

patchmgrユーティリティが完了した後、次のように更新ステータスを検証します。

各セルでimageinfoコマンドおよびimagehistoryコマンドを使用して、イメージ・ステータスおよび履歴をチェックします。大容量ドライブまたは高パフォーマンス・ドライブを使用するシステムに対する更新が正常に完了すると、次のような出力が表示されます。

Kernel version: 2.6.39-400.281.1.el6uek.x86_64 #1 SMP Fri Jun 17 20:10:16 PDT 2016 x86_64
Cell version: OSS_12.1.2.3.2_LINUX.X64_160721
Cell rpm version: cell-12.1.2.3.2_LINUX.X64_160721-1.x86_64

Active image version: 12.1.2.3.2.160721
Active image kernel version: 2.6.39-400.281.1.el6uek
Active image activated: 2016-07-21 13:04:34 -0500
Active image status: success
Active system partition on device: /dev/md5
Active software partition on device: /dev/md7

Cell boot usb partition: /dev/sdac1
Cell boot usb version: 12.1.2.3.2.160721

Inactive image version: 12.1.2.3.1.160411
Inactive image activated: 2016-04-11 19:58:28 -0700
Inactive image status: success
Inactive system partition on device: /dev/md6
Inactive software partition on device: /dev/md8

Inactive marker for the rollback: /boot/I_am_hd_boot.inactive
Inactive grub config for the rollback: /boot/grub/grub.conf.inactive
Inactive kernel version for the rollback: 2.6.39-400.128.21.el5uek
Rollback to the inactive partitions: Possible

Extreme Flashドライブを使用するシステムに対する更新が正常に完了すると、同様の出力が表示されますが、USBのパスが異なります。

Kernel version: 2.6.39-400.281.1.el6uek.x86_64 #1 SMP Fri Jun 17 20:10:16 PDT 2016 x86_64
Cell version: OSS_12.1.2.3.2_LINUX.X64_160721
Cell rpm version: cell-12.1.2.3.2_LINUX.X64_160721-1.x86_64

Active image version: 12.1.2.3.2.160721
Active image kernel version: 2.6.39-400.281.1.el6uek
Active image activated: 2016-07-21 13:04:34 -0500
Active image status: success
Active system partition on device: /dev/md5
Active software partition on device: /dev/md7

Cell boot usb partition: /dev/sda1
Cell boot usb version: 12.1.2.3.2.160721

Inactive image version: 12.1.2.3.1.160411
Inactive image activated: 2016-04-11 19:58:28 -0700
Inactive image status: success
Inactive system partition on device: /dev/md6
Inactive software partition on device: /dev/md8

Inactive marker for the rollback: /boot/I_am_hd_boot.inactive
Inactive grub config for the rollback: /boot/grub/grub.conf.inactive
Inactive kernel version for the rollback: 2.6.39-400.128.21.el5uek
Rollback to the inactive partitions: Possible

8.11.3 Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティング

カスタムrpmがインストールされているExadataデータベース・サーバーで前提条件チェックまたは更新を実行すると、競合によって前提条件チェックまたは更新が失敗する場合があります。

前提条件チェックまたは更新を行うときに、更新ユーティリティは2つの依存性チェックを実行します。Minimum依存性に対するチェックと、Exact依存性に対するチェックです。

依存性の失敗をトリアージするには、ログ・ファイルを調べます。これは、ターゲットのExadataデータベース・サーバー上のdbnodeupdate.logである場合と、更新ユーティリティ(patchmgr)の起動元のログ・ディレクトリにある<hostname>_dbnodeupdate.logである場合があります。

ログ・ファイルで各実行の先頭を特定するには、zzzで始まる行を検索します。たとえば:

zzz - /u01/patches/YUM/dbnodeupdate.sh called with arguments -u -l
/u01/patches/YUM/p23564643_121232_Linux-x86-64.zip -v -N at  2016-08-23 23:31:54

日付スタンプは、調査対象の実行の時間と一致する必要があります。各実行は一意のrunidで識別され、これは、次のように、同じログ・ファイルの各実行の先頭に出現することもあります。

[1472009516][2016-08-23 23:31:59 -0400][INFO][/u01/patches/YUM/dbnodeupdate.sh][InitLogfile][]  # dbnodeupdate.sh script rel.
 : 5.160809 started at  (runid :230816233155)

カスタムrpmがある場合は、固有の実行のdiagファイルを調べると、それをチェックすることもできます。diagファイルはrunidで識別され、ターゲットのExadataデータベース・サーバー上の/var/log/cellosか、更新ユーティリティを駆動しているディレクトリにあります。この例では、ファイル名はdbnodeupdate.230816233155.diagになっています。そのファイルで、RunDetectCustomRpmsShおよびrpm -qa --qf "%{n}-%{v}-%{r}.%{arch}"\nというヘッダーのセクションを探します。インストール済の(追加の)パッケージがある場合は、それに関する詳細を確認できます。

ログ・ファイルで、依存性チェックの結果について、開始(zzz)から下方向にExact dependencies (大文字小文字が区別されます)を検索します。この場合、次のようになっています。

Exact dependencies     : Will fail on a next update
Minimum dependencies   : Will fail on a next update

Minimum依存性チェックにパスするかぎり、更新または前提条件チェックは失敗しません。MinimumとExactの両方の依存性が失敗した場合は、エラーの原因を特定する必要があります。

エラーの原因となっている依存性を見つけるには、[ExecUpgrade][] Performing yum package dependencyを検索します。ここが、YUM(通常はテスト実行が先)が実行される場所です。依存性問題があるときには、Error:で始まるYUMメッセージが表示されます。たとえば:

--> Finished Dependency Resolution
Error: Package: krb5-devel-1.10.3-33.el6.x86_64 (@ol6_latest)
Requires: krb5-libs = 1.10.3-33.el6
Removing: krb5-libs-1.10.3-33.el6.x86_64 (installed)
        krb5-libs = 1.10.3-33.el6
Updated By: krb5-libs-1.10.3-42z1.el6_7.x86_64 (exadata_generated_160616114412)
          krb5-libs = 1.10.3-42z1.el6_7
You could try using --skip-broken to work around the problem

この例のエラー・メッセージによると、krb5-devel-1.10.3-33.el6.x86_64 (krb5-devel)パッケージはExadata以外のチャンネル(ol6_latest)からインストールされています。このkrb5-develパッケージは、krb5-libsに依存しています。ただし、このExadata更新ではkrb5-libsパッケージを使用できません。krb5-develを更新しないでkrb5-libsを更新することはできないため、依存性チェックは失敗します。krb5-develの新規バージョンがExadata更新に含まれていないため、パッケージは事前更新するか削除する必要があります。事前更新とは、Exadata更新を実行する前に個々のパッケージを手動で更新することです。これを行うには、rpm -Uvh <package-name>コマンドを使用します。

カスタム・パッケージを削除することをお薦めします。次のrpmコマンドを使用してください。

[root@dm01 ]# rpm –e krb5-devel

エラーの原因となっているrpmを削除した後、更新または前提条件チェックを再起動します。

8.11.4 Exadataデータベース・サーバーでのmultilib問題のトラブルシューティング

アーキテクチャの異なるカスタム・パッケージがデータベース・サーバーにインストールされている場合は、Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティングで説明しているものと同様の問題が発生することがあります。このことは、通常、i686パッケージがExadataデータベース・サーバーにインストールされている場合に発生します。

ノート:

64ビット(x86_64)以外のパッケージもサポートされていますが、32ビット・ソフトウェアは使用しないことをお薦めします。サード・パーティが提供する特定の機能が必要になったときには、64ビット・バージョンを要求することをお薦めします。

通常、Exadataブランドのx86_64ビットrpmはExadata更新で更新されます。ただし、アーキテクチャがx86_64ビットでない、同様のパッケージをインストールしていた場合、更新ユーティリティは64ビット・パッケージを更新できません。ログ・ファイルに次のエラーが示されます。

--> Finished Dependency Resolution
    Error:  Multilib version problems found. This often means that the root
           cause is something else and multilib version checking is just
           pointing out that there is a problem. Eg.:
           
             1. You have an upgrade for libuuid which is missing some
                dependency that another package requires. Yum is trying to
                solve this by installing an older version of libuuid of the
                different architecture. If you exclude the bad architecture
                yum will tell you what the root cause is (which package
                requires what). You can try redoing the upgrade with
                --exclude libuuid.otherarch ... this should give you an error
                message showing the root cause of the problem.
           
             2. You have multiple architectures of libuuid installed, but
                yum can only see an upgrade for one of those arcitectures.
                If you don't want/need both architectures anymore then you
                can remove the one with the missing update and everything
                will work.
           
             3. You have duplicate versions of libuuid installed already.
                You can use "yum check" to get yum show these errors.
           
           ...you can also use --setopt=protected_multilib=false to remove
           this checking, however this is almost never the correct thing to
           do as something else is very likely to go wrong (often causing
           much more problems).
           
           Protected multilib versions: libuuid-2.17.2-12.24.0.1.el6.x86_64 != libuuid-2.17.2-12.18.0.1.el6.i686

rpm –e <package_name.i686>を実行して、i686またはi386パッケージを削除することが、multilib問題の解決策となります。