6 Exadataソフトウェアの更新

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

• Exadataソフトウェアの更新について
• ソフトウェア・メンテナンスの計画
• Exadataサーバー上のOracle Linux 7へのアップグレードについて
• Exadataソフトウェア更新の実行の概要
• Exadataデータベース・サーバーの更新
• Oracle Exadata System Softwareリリース11.2.2.4.2を実行しているデータベース・サーバーの更新
• Oracle Exadata Storage Serverの更新
• Exadata InfiniBandスイッチ・ファームウェアの更新
• Oracle LinuxでのOracle Java SEのアップグレード
• SSH等価の設定
• Oracle Exadata Database Machineでのソフトウェア更新のトラブルシューティング

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

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

• Exadataストレージ・サーバー
• Exadataデータベース・サーバー
• Exadata InfiniBandスイッチ

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

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

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

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

リリースされるすべてのExadataソフトウェア更新を個別に適用することが必要になるわけではありません。たとえば、リリースを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よりも大きいため、許可されません。

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

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

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

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

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

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

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

Exadata Database Machineで実行するソフトウェアは、2つのカテゴリに分かれます。

• Exadataインフラストラクチャ・ソフトウェア

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

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

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

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

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

• 現在と以前のすべてのリリースのリスト

• 機能使用状況の最小要件

• ExadataバージョンとDatabaseバージョン間の互換性要件

• 特定のハードウェア・リリースの互換性要件

• Exadataで使用する場合の関連製品のガイドライン

• Exadataソフトウェア・メンテナンスのその他の関連情報ソースへの参照

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

主なソフトウェア・カテゴリ(Exadataインフラストラクチャ・ソフトウェアと、Grid InfrastructureおよびDatabaseソフトウェア)は、リリース・タイプによってさらに分類されます。 

ソフトウェア	リリース・タイプ	説明および内容
Exadataインフラストラクチャ・ソフトウェア	機能リリース	最初の4桁は、Exadataの機能リリースを表します(12.2.1.1.0など)。 機能リリースには、新機能、バグ修正およびセキュリティ修正が含まれています。以前の機能リリースまたは継続リリースの更新に使用される場合もあります。 11.2.3.3.1から12.1.2.3.4までの以前のリリースから、機能リリース12.2.1.1.0に直接更新できます。
Exadataインフラストラクチャ・ソフトウェア	継続リリース	5桁目は、機能リリースへの累積更新を表します(12.1.2.3.4など)。 継続リリースには、バグ修正およびセキュリティ修正が含まれています。特定の機能リリースには、約4つの継続リリースがあります。継続リリースは以前の機能リリースまたは継続リリースの更新に使用される場合もあります。 11.2.3.3.1から12.1.2.3.3までの以前のリリースから、継続リリース12.1.2.3.4に直接更新できます。
Exadataインフラストラクチャ・ソフトウェア	個別パッチ	個別パッチは、継続リリースまたは機能リリースより前に修正が必要なユーザーに提供される個別のバグ修正です。個別パッチのインストールは必要に応じて行われ、定期的にスケジュールされた計画メンテナンス・イベントではありません。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	メジャー・リリースまたはメンテナンス・リリース	1桁目および2桁目は、メジャー・データベース・リリースおよびメンテナンス・データベース・リリースを表します(12.2や12.1など)。 メジャー・リリースまたはメンテナンス・リリースには、新機能、バグ修正およびセキュリティ修正が含まれています。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	パッチ・セット・リリース	4桁目は、パッチ・セット・リリースを表します(12.2.0.1や12.1.0.2など)。  パッチ・セット・リリースには、主にバグ修正が含まれています。ただし、パッチ・セット・リリースに小規模な新機能や機能変更が含まれる場合もあります。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	プロアクティブ・バンドル・パッチ	5桁目は、パッチ・セット・リリースへの累積更新を表します(12.1.0.2.170117や11.2.0.4.161018など)。 プロアクティブ・バンドル・パッチには、バグ修正およびセキュリティ修正が含まれています。標準のOracle Grid Infrastructure PSU (GIPSU)のスーパーセットです。Exadataシステムにインストールできるのはプロアクティブ・バンドル・パッチのみで、標準のPSUはインストールできません(Oracle Database 12.1.0.1は例外で、これには標準のGIPSUが使用されています)。 Oracle Database 11.2では、プロアクティブ・バンドル・パッチはExadataのデータベース・パッチと呼ばれます。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	個別パッチ	個別パッチは、Exadataの後続のパッチ・セット・リリースまたはデータベース・パッチより前に修正が必要なユーザーに提供される個別のバグ修正です。個別パッチのインストールは必要に応じて行われ、定期的にスケジュールされた計画メンテナンス・イベントではありません。

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

各ソフトウェア・リリース・タイプには様々な可用性の頻度があります。

Exadataの継続リリースと、四半期ごとのGrid InfrastructureおよびDatabaseのプロアクティブ・バンドル・パッチは、Oracleクリティカル・パッチ・アップデート(CPU)プログラムの一部として、四半期サイクルで定期的にリリースされます。 これらの四半期ごとのリリースは、事前の重要な修正やセキュリティ脆弱性に対処するために提供されます。 

ソフトウェア	リリース・タイプ	リリース頻度	最新バージョンを維持する重要度	新しいリリースを導入する際の推奨事項
Exadataインフラストラクチャ・ソフトウェア	機能リリース	6から18か月	中	新機能を導入し、重要な修正およびセキュリティ更新を取得する場合に更新します。
Exadataインフラストラクチャ・ソフトウェア	継続リリース	3か月(四半期)	高	重要な修正およびセキュリティ更新を取得する場合に四半期に一度更新します。ラグが12か月を超えないようにしてください。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	メジャー・リリースまたはメンテナンス・リリース	24か月以上	低	新機能を導入する場合に更新します。現在のリリースのライフタイム・サポートの終了日より前に更新します。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	パッチ・セット・リリース	12から24か月	中	現在のパッチ・セットのエラー修正サポートの終了日より前(通常は次のパッチ・セット・リリースから1年以内)に更新します。  詳細は、My Oracle Supportのドキュメント742060.1を参照してください。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	プロアクティブ・バンドル・パッチ	3か月(四半期)	高	重要な修正およびセキュリティ更新を取得する場合に四半期に一度更新します。ラグが12か月を超えないようにしてください。

6.2.1.3 ソフトウェア更新頻度

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

次に、リリースの通常の間隔を使用した4年サイクルにわたる四半期に一度の高度なソフトウェア・メンテナンス計画の例を3つ示します。

注意:

リリース頻度は、ここに記載されている内容によって異なります(特に新機能を含むリリースの場合)。

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

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

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

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

目標 - 重要な修正やセキュリティ修正が使用可能になったら適用し、新機能リリースをできるだけ遅く導入することで、リスクを最小限にします。可能な場合は、Exadataの新機能リリースとDatabaseの新機能リリースを同時に導入しないでください。

図6-1 本番システム・ソフトウェアを更新する頻度

「図6-1 本番システム・ソフトウェアを更新する頻度」の説明

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

目標 - 代替四半期更新を適用することで、メンテナンス時間を最小限にします。可能な場合は、Exadataの新機能リリースとDatabaseの新機能リリースを同時に導入しないでください。

図6-2 少ない頻度の本番システム・ソフトウェア更新

「図6-2 少ない頻度の本番システム・ソフトウェア更新」の説明

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

目標 - 最新の機能およびソフトウェア更新をできるだけ早く導入します。

図6-3 開発およびテスト・システム・ソフトウェアを更新する頻度

「図6-3 開発およびテスト・システム・ソフトウェアを更新する頻度」の説明

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

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

更新タイプ	ユーティリティ	コンポーネント	説明
更新前の準備状況チェック	Oracle EXAchk	Exadata Database Machine	メンテナンス準備状況を確認し、重大な問題の発生を特定し、ソフトウェアを更新するバージョン推奨を提供するために使用されるExadataヘルスチェック・ツールです。 My Oracle Supportのドキュメント1070954.1からOracle EXAchkを取得してください。
Exadataインフラストラクチャ・ソフトウェア	patchmgr	Exadataストレージ・サーバー Exadataデータベース・サーバー Exadata InfiniBandスイッチ	Exadataデータベース・サーバー、ストレージ・サーバーまたはInfiniBandスイッチ上のすべてのソフトウェア(Oracle Linux、Exadataインフラストラクチャ・ソフトウェア、ファームウェア)を更新するExadataソフトウェア更新ツールです。たとえば、patchmgrは、Exadataストレージ・サーバーおよびデータベース・サーバーをExadataバージョン12.2.1.1.0に更新したり、Exadata InfiniBandスイッチをバージョン2.2.4-3に更新します。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのプロアクティブ・バンドル・パッチ	OPatchまたはopatchauto	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(OUI)	Exadataデータベース・サーバー	Grid InfrastructureおよびDatabaseパッチ・セット、メジャー・リリースまたはメンテナンス・リリースをインストールし、Oracle Grid Infrastructureをアップグレードするソフトウェア・インストール・ツールです。たとえば、OUIは、Oracle Database 12.2.0.1をインストールしたり、Oracle Grid Infrastructureをインストールして12.1.0.2から12.2.0.1にアップグレードします。 アップグレードするOracle Grid InfrastructureおよびOracle DatabaseリリースにバンドルされているOUIのバージョンを使用します。
Oracleデータベースのアップグレード	Database Upgrade Assistant(DBUA)	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 Grid InfrastructureおよびOracle Databaseソフトウェア	フリート・パッチ適用およびプロビジョニング(以前は高速ホーム・プロビジョニング(RHP)と呼ばれていました)	Exadataデータベース・サーバー	集中化されたサーバーから1つ以上のクラスタ上のOracle Grid InfrastructureおよびOracle Databaseソフトウェアのプロビジョニング、パッチ適用およびアップグレードを行うソフトウェア・メンテナンス・ツールです。 Oracle Clusterwareの機能としてフリート・パッチ適用およびプロビジョニングを使用します。
Exadataインフラストラクチャ・ソフトウェア Oracle Grid InfrastructureおよびOracle Databaseソフトウェア	Oracle Enterprise Manager Cloud Control。	Exadataストレージ・サーバー Exadataデータベース・サーバー Exadata InfiniBandスイッチ	Oracle Enterprise Manager Cloud Controlには、ソフトウェア更新をExadataシステムに適用するライフサイクル管理機能があります。

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

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

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

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

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

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

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

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

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

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

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

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

  • 非ローリング更新は、メンテナンス時間全体ではローリング更新より高速です。これは、複数のコンポーネントがパラレルに更新されるためです。

  • 更新中、すべての特定のコンポーネントがオフラインで、1つのデータベース(またはシステム上のすべてのデータベース)もオフラインになるため、結果としてアプリケーションへの完全な停止となります

  • 非ローリング形式で更新されるExadata Database Machineによって処理された重要なアプリケーションは、Oracle Data Guardを使用する環境のスタンバイ・システムに頻繁に移動されます。

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

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

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

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

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

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

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

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

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

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

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

6.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を使用して、パッチ・セットおよびリリース更新でのデータベース・アップグレードによる停止時間を減らします。データベースのアップグレード中の停止時間は、ソース・データベースがオンラインのままで現在のバージョンを実行して、ターゲット・データベースを新しいバージョンにアップグレードし、同期を維持することを許可することにより短縮されます。

6.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は、新しい機能および修正が含まれるように、定期的に更新されます。

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

  • 今後のpatchmgrソフトウェア更新の失敗

  • システムのレスキュー不可

  • ソフトウェア不具合の効率的な診断不可

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

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

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

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

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

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

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

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

•  Exadataストレージ・サーバーを新しいバージョンのExadataソフトウェアに更新しますが、Exadataデータベース・サーバーは以前のExadataソフトウェアのバージョンのままです。

•  Exadataデータベース・サーバーを新しいバージョンのExadataソフトウェアに更新しますが、Exadataストレージ・サーバーは以前のExadataソフトウェアのバージョンのままです。

•  Exadataストレージ・サーバーを新しいバージョンのExadataソフトウェアに更新しますが、InfiniBandスイッチは以前のExadataソフトウェアのバージョンのままです。

•  InfiniBandスイッチを新しいバージョンのExadataソフトウェアに更新しますが、Exadataストレージ・サーバーは以前のExadataソフトウェアのバージョンのままです。

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

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

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

• 特定の世代のExadataハードウェアに必要な最低限のExadataソフトウェア・バージョンがあります。 たとえば、Exadata X6ハードウェアには、Exadataソフトウェア12.1.2.3.1以上が必要です。  

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

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

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

•  Databaseでは、ローリング更新のみの目的で、プロアクティブ・バンドル・パッチの複合バージョンがサポートされています(たとえば、12.1.0.2.161018から12.1.0.2.170117への更新)。

6.2.2.6 更新の順序

一般に、ソフトウェア更新を実行すると、更新は、ビジネス・ニーズおよびメンテナンス・ウィンドウの要件に基づいた順序でコンポーネントに適用されます。

ソフトウェア更新を適用する推奨順序は次のとおりです。

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

2. Oracle Exadata Database Serverソフトウェア

3. Oracle Exadata Storage Serverソフトウェア

4. Exadata InfiniBandスイッチ・ソフトウェア

特定の更新順序が必要になる例外があります。これは、更新するバージョンのOracle Exadata System Softwareの補足READMEに記載されています。 必須の更新順序の例をいくつか示します。

• Oracle ASM Cluster File System (Oracle ACFS)が構成されているシステムを更新する場合は、データベース・サーバー(非Oracle VMまたはOracle VM)をOracle Exadata System Softwareリリース12.2に更新する前に、Oracle Grid Infrastructureホームにバグ22810422に対する修正を含める必要があります。

• Oracle VM構成をOracle Exadata System Softwareリリース12.1からリリース12.2に更新する場合は、管理ドメインをOracle Exadata System Softwareリリース12.2に更新する前に、すべてのユーザー・ドメインをOracle Exadata System Softwareリリース12.2に更新する必要があります。

• Oracle VM構成を更新する場合は、ユーザー・ドメインをOracle Exadata System Softwareリリース12.2に更新する前に、ユーザー・ドメイン内のOracle Grid Infrastructureホームがプロアクティブ・バンドル・パッチ・リリース12.1.0.2.161018 (2016年10月)以降を実行している必要があります。

一般に、ソフトウェア更新順序の要件が発生するのは、1つ以上のコンポーネントを新機能を含む新しいバージョンに更新する場合です(たとえば、Oracle Exadata System Softwareをリリース12.1からリリース12.2に更新する場合など)。詳細は、更新するソフトウェア・バージョンのOracle Exadata System Softwareの補足READMEを参照してください。

6.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)のみでリリースを参照することで十分です。ただし、アップグレードするときには、インストール済リリースおよびターゲット・リリースの製品バージョンと日付コードの両方を考慮する必要があります。

12.2.0.2.0リリース以降では、製品バージョンに12.2.0.2などの従来の命名法を使用しなくなりました。かわりに、製品バージョンはYear.Update.Revisionで構成される3フィールド形式(例: 18.1.0)となっています。

6.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よりも大きいため、許可されません。

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

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

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

• 単一の起動の場合、すべてのExadataストレージ・サーバー、Exadataデータベース・サーバーまたはInfiniBandスイッチを更新します。

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

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

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

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

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

• Patchmgrは、rootユーザーまたはroot以外のユーザーとして、Oracle Linuxを実行するExadataシステムまたは非Exadataシステムから実行できます。

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

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

• データベースとクラスタウェアの停止および起動

• ユーザー・ドメインの停止および起動(domU)

• Oracle Enterprise Manager Cloud Controlエージェントの停止および起動

• リモート・ネットワーク・マウントのアンマウント

• ロールバックに使用できるルート・ファイル・システムのオペレーティング・システムのバックアップの実行

• データベース・ホームとOracle Grid Infrastructureホーム・バイナリの再リンク

• 既知の問題の更新されたベスト・プラクティス構成の変更および回避策の適用

6.2.5.1 patchmgrの取得

ストレージ・サーバーおよびInfiniBandスイッチの更新では、更新対象のExadataソフトウェア・リリースにバンドルされているバージョンのpatchmgrを使用します。

データベース・サーバー用のpatchmgrは、dbserver.patch.zipにパッケージされ、My Oracle Supportノート1553103.1またはパッチ21634633から独立したダウンロードとして入手できます。

Exadataデータベース・サーバーを更新する際には、常にMy Oracle Supportから最新のpatchmgrを使用することをお薦めします。patchmgrユーティリティは既知の問題およびベスト・プラクティスに対処し、新しいハードウェアをサポートするために頻繁に更新されます。

6.2.5.2 patchmgrの構文

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

前提条件

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

構文

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

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

オプション

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

使用上の注意

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

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

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

例

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

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

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

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

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

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

次のコマンドは、3つの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

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

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

./patchmgr -dbnodes dbnode_group -backup -iso_repo /tmp/p25640941_122111_Linux-x86-64.zip -target_version 12.2.1.1.1.170419 
./patchmgr -dbnodes dbnode_group -precheck -iso_repo /tmp/p25640941_122111_Linux-x86-64.zip -target_version 12.2.1.1.1.170419 
./patchmgr -dbnodes dbnode_group -upgrade -nobackup -iso_repo /tmp/p25640941_122111_Linux-x86-64.zip -target_version 12.2.1.1.1.170419

6.2.5.3 patchmgrのオプション

patchmgrコマンドとともに様々なオプションを使用できます。

patchmgrを使用してデータベース・ノードを更新する場合、次のオプションがサポートされています。

表6-1 patchmgrのオプション: 必須オプション

オプション	説明
-dbnodeslist_file	データベース・ノードのリスト・ファイルの名前を指定します。ファイルには1行に1つのホスト名またはIPアドレスが記載されています。

表6-2 patchmgrのオプション: アクション・オプション

オプション	説明
-precheck	リスト・ファイルに指定されたデータベース・ノードに対して更新前の検証チェックを実行します(実際の更新は行いません)。
-upgrade	リフト・ファイルに指定されているデータベース・ノードをアップグレードします。
-backup	リフト・ファイルに指定されているデータベース・ノードをバックアップします。
-rollback	リフト・ファイルに指定されているデータベース・ノードをロールバックします。
-cleanup	非ローリング方式で、ホスト・リストに指定されたデータベース・ノードのすべての一時コンテンツを削除します。通常、このオプションはアップグレードまたはロールバックの操作の後に使用します。
-get property	指定されたプロパティに関する情報を戻します。プロパティは次のとおりです。 log_dir ログ・ディレクトリを返します。

表6-3 patchmgrのオプション: サポート・オプション

オプション	説明
-iso_repo repo_location	圧縮ISOファイルのパスを指定します。dbnodeupdate.zipファイルと同じディレクトリにそのファイルを配置することをお薦めします。 -backup、-precheckおよび-upgradeアクションには、このオプションまたは-yum_repoオプションを指定する必要があります。 -yum_repoオプションとともにこのオプションを使用することはできません。
-yum_repo repo_location	yumのHTTPリポジトリへのURLを指定します。 -backup、-precheckおよび-upgradeアクションには、このオプションまたは-iso_repoオプションを指定する必要があります。 -iso_repoオプションとともにこのオプションを使用することはできません。
-log_dir log_directory_or_auto	ログ・ディレクトリへの絶対パスを指定するか、またはautoを指定して、起動ディレクトリおよびノード・リスト・ファイルのコンテンツに基づくログ・ディレクトリを使用できます。 -log_dirオプションを指定すると、複数のパッチ・マネージャ呼出しを実行することも、root以外のユーザーとしてパッチ・マネージャを実行することもできます。
-nobackup	アップグレード・アクションでデータベース・ノードのバックアップを実行しないことを指定します。
-target_version version	更新先の完全なリリース・バージョンを指定します。この情報は、パッチのREADMEファイルにあります。
-unkey	終了する前に、データベース・ノードへのパスワードなしのSSHアクセスを削除します。
-rolling	ローリング方式で更新を実行することを指定します。指定しない場合、更新は非ローリング方式で実行されます。 注意: ロールバックは、このオプションを指定しない場合でも、常にローリング方式で実行されます。 注意: -rollingオプションが指定されている場合でも、常に非ローリング方式で事前チェックとクリーン・アップが実行されます。
-allow_active_network_mounts	アクティブなNFSまたはSMBマウントを使用してdbnodeupdateを実行することを許可します。 これはdbnodeupdate.sh -Aコマンドと同等です。
-force_remove_custom_rpms	Oracle Linux 5からOracle Linux 6へのデータベース・ノードの更新時にカスタムRPMを削除します。 これはdbnodeupdate.sh -Rコマンドと同等です。
-nomodify_at_prereq	前提条件の確認時にRPMを変更しません。 これはdbnodeupdate.sh -Nコマンドと同等です。

表6-4 patchmgrのオプション: メール・オプション

オプション	説明
-smtp_from "from_email"	patchmgr通知の送信元(from)の電子メール・アドレスを指定します。
-smtp_to "to_email1 to_email2 to_email3 ..."	patchmgr通知の送信先(to)の電子メール・アドレスを指定します。
-smtp_set_envelope_sender	「Return-Path:」メール・ヘッダーと同じ送信元(from)アドレスが使用されることを指定します。

6.3 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を参照してください。

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

この項では、Exadataコンポーネントへのソフトウェア更新を実行するために必要な、高度なアクションについて説明します。

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

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

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

• Exadata InfiniBandスイッチ更新の実行の概要

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

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

     注意:

      データベース・サーバーの前提条件チェックおよび-nomodify_at_prereqフラグの実行には、特別な考慮が必要です。  詳細は、「Exadataデータベース・サーバーの更新」を参照してください。

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

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

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

6.4.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およびすべてのデータベースを再起動します。

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

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

注意:

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

6.4.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オプション)方式でデータベース・サーバーを更新します。

6.4.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を更新します。

6.4.4 Exadata InfiniBandスイッチ更新の実行の概要

Patchmgrは、InfiniBandスイッチのローリング形式での更新オーケストレーションを管理します 

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. InfiniBandスイッチを更新するpatchmgrを実行します。 InfiniBandスイッチは、常にローリング形式で更新します。

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

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

新しいプロアクティブ・バンドル・パッチへの更新

新しいプロアクティブ・バンドル・パッチへの更新は、インプレースまたはアウトオブプレースで実行できます。インプレースとアウトオブプレースの両方の方法で、ローリング更新と非ローリング更新がサポートされています。

• インプレース

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

  これは、プロアクティブ・バンドル・パッチのREADMEに記載されているように、Oracle Grid InfrastructureまたはOracle Databaseソフトウェアにプロアクティブ・バンドル・パッチ更新を適用するデフォルトの方法です。プロアクティブ・バンドル・パッチを適用する手順は、各ノードで実行する必要があります。

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

  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パッチ・セット更新(PSU)は、OJVMのセキュリティ脆弱性に対処するデータベース・ホーム用の個別のソフトウェア更新です。 これは、標準プロアクティブ・バンドル・パッチとは別にインストールされます。 OJVM PSUパッチは、特定の状況でローリング形式でインストールできます。

新しいパッチ・セット・リリース、メジャー・リリースまたはメンテナンス・リリースへの更新

Grid InfrastructureまたはDatabaseの上位パッチ・セット、メンテナンスまたはメジャー・リリースに更新するには、My Oracle Supportの手順を追った説明に従ってください。

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

6.4.6.1 sudoによるdbnodeupdate.shの実行

sudoを使用してdbnodeupdate.shを実行するために/etc/sudoersファイルを設定するには、次の手順を実行します。

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

   # visudo
   

2. oracleユーザーなどのroot以外のユーザーが、dbnodeupdateを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を実行します。

[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での指定と同じ場所に配置する必要があります。

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

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

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     \
   -yum_repo http://my-yum-repo/yum/EngineeredSystems/exadata/dbserver/12.1.2.1.3/base/x86_64/  \
   -target_version 12.1.2.1.3.151021

6.5 Exadataデータベース・サーバーの更新

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

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

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

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

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

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

ClusterwareプロセスおよびOracle RACデータベース・インスタンスが、更新対象のデータベース・サーバー上で実行されていない必要があります。アプリケーション・レベルの影響を減らすには、高可用性Oracle Databaseのクライアント・フェイルオーバーのベスト・プラクティスに関する項で説明されているクライアント・フェイルオーバーのベスト・プラクティスに従います。

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

• Exadataデータベース・サーバーの更新パス
• Exadata以外のソフトウェアのインストール、更新および管理
• カスタマイズのレベルと影響
• Exadataデータベース・サーバーの更新ユーティリティ
• ツール実行ホストの更新
• root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行
• Exadataデータベース・サーバーを更新する場合にお薦めするタイムライン
• Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定
• Exadata廃止パッケージの管理
• 個々のパッケージの更新
• 前提条件チェックの実行
• 計画メンテナンスの前のExadataデータベース・サーバーのバックアップ
• 更新の実行
• 更新のロールバック
• Exadataデータベース・サーバー更新のトラブルシューティング

6.5.1 Exadataデータベース・サーバーの更新パス

Oracle Linux 5.5以上およびOracle Exadataソフトウェア・リリース11.2.2.4.2以上が実行されているExadataデータベース・サーバーを更新するには、更新ユーティリティを使用してExadataソフトウェア更新を適用する必要があります。

11.2.2.4.2よりも古いExadataソフトウェア・リリースを実行しているExadataデータベース・サーバーを更新するには、まず、そのサーバーをOracle Linux 5.5およびExadataソフトウェア・リリース11.2.2.4.2以上に更新し、その後、更新ユーティリティを使用する必要があります。詳細は次の表を参照してください。

表6-5 更新パス

現時点でインストールされているOracle Exadataソフトウェア・リリース	現在インストールされているOracle Linuxリリース	推奨アクション
リリース11.2.2.4.2以上	リリース5.5以上	更新ユーティリティを使用してターゲット・リリースに更新します。
リリース11.2.2.4.2より前	リリース5.5以上	パッチ13513611を使用して、データベース・サーバーをリリース11.2.2.4.2に更新します。パッチ13513611のREADMEに記載されたセクション8の手順を参照してください。 更新ユーティリティを使用して、より後のリリースに更新します。
リリース11.2.2.4.2より前	リリース5.5より前	リリース11.2.3.2.0に更新します。詳細は、My Oracle Supportノート1284070.1を参照してください。 更新ユーティリティを使用して、より後のリリースに更新します。

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

Exadataデータベース・サーバー上でExadata以外のブランドのrpmをインストールおよび更新することは、カーネルおよびInfiniBand固有のパッケージが変更されないかぎり、許可されます。

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

注意:

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

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

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

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

注意:

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

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

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

関連項目:

exadata-sun-computenode-exactの詳細は、前提条件チェックの実行を参照してください。

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

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

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

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

6.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ファイルには付属しています。

また、このユーティリティでは、Oracle Linux 5からOracle Linux 6への更新またはOracle Linux 6からOracle Linux 7へのExadataソフトウェア更新もサポートしています。

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

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

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

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

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

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

6.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

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

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

注意:

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

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

いつ	タスク
更新までの数週間から数日前	My Oracle Supportノート1553103.1から最新のdbserver.patch.zipをダウンロードします。 My Oracle Supportノート1070954.1から最新のExachkをダウンロードします。 リリース固有のMy Oracle Supportノートで既知の問題を調査します。 My Oracle Supportノート1270094.1を調べてExadataの重大な問題を調査します。 Exachkを実行します。 まず前提条件チェックを実行します。 注意: YUM依存性チェックが機能するようにするために、更新ユーティリティがExadataデータベース・サーバーに最小限の変更を加える場合があります。何も変更されないようにする場合は、-nomodify_at_prereqフラグを指定して前提条件チェックを実行します。 詳細は、前提条件チェックの実行を参照してください。 要注意の結果を修正します。この時点では、rpmを削除できない場合、依存性問題は無視してもかまいません。-nomodify_at_prereqを指定したため、依存性が破損している可能性があります。
更新直前	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回目の前提条件チェックを実行します。今回は、-nomodify_at_prereqフラグを省略して、YUM依存性を機能させるために必要となる変更を更新ユーティリティが加えることができるようにします。詳細は、前提条件チェックの実行を参照してください。 ブロックしているrpmがある場合は、それを削除し、前提条件チェックを再実行して、すべての変更が完了しているかどうかを検証します。 更新を実行します。すでにバックアップのみの実行を行ったため、-nobackupフラグを使用してバックアップをスキップします。 詳細は、更新の実行を参照してください。
更新後	Exachkを実行します。 Exadataを更新する前に、削除したExadata以外のrpmを再インストールします。

6.5.8 Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

Exadataデータベース・サーバーのExadataソフトウェア更新手順では、配信にUnbreakable Linux Network (ULN)を使用します。更新は、グループ化されたパッケージ・セット(rpm)としてチャンネルに配信されます。前提条件チェックまたは更新を実行する前に、これらのパッケージをローカルに使用できるようにする必要があります。

チャンネルは、ローカルのExadata以外のデータベース・サーバーによってサブスクライブできます。これでチャンネル・コンテンツがローカル・サーバーにダウンロードされ、リポジトリがExadataデータベース・サーバーの更新に使用されるYUMリポジトリとして使用可能になります。

データ・センターから使用できるインターネット接続がない場合や、ULNを同期できない場合には、使用準備済のYUMリポジトリをISOイメージとしてダウンロードできます。

注意:

各Exadataストレージ・サーバー更新には、それぞれ独自のチャンネル/ISOイメージが付属しています。このISOイメージおよびULNチャンネルは、汎用的なLinux ULNチャンネルと完全に置き換わることを意図したものではありません。Exadata ISOおよびULNチャンネルには、Oracle Exadataチャンネル・コンテンツのみが含まれています。使用する環境で、Oracle Exadata ULNチャンネルやISOイメージに更新が含まれていない他のLinuxパッケージを使用している場合には、必要に応じて、Linux ULNチャンネルを使用して、そのパッケージを更新します。

Exadataソフトウェア更新をホストするためのYUMリポジトリを構築するには、次の方法を使用します。更新ユーティリティは、ローカルのYUMリポジトリを使用して、Exadataデータベース・サーバーを更新します。

• My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、圧縮イメージの場所を更新ユーティリティに渡します。これは、推奨アプローチです。

• 独立したサーバー上のULN Oracle Exadataチャンネルからローカル・ミラーをYUM HTTPリポジトリとして設定します。

• My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、それをWebサーバー上でYUM HTTPリポジトリとして使用できるようにします。

6.5.8.1 My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、圧縮イメージの場所を更新ユーティリティに渡す

Oracle Exadataソフトウェア更新を保持しているOracle Exadataチャンネルは、My Oracle Supportからダウンロード可能なイメージ(圧縮ISOファイル)として入手でき、次の2つの方法で使用できます。

• -iso_repoフラグを使用して、更新ユーティリティの引数として圧縮ファイルの場所を使用します。

• HTTPを使用して公開し、-yum_repoフラグを使用してURLを更新ユーティリティで使用します。

圧縮ファイルの場所は更新ユーティリティに直接渡すことができ、これは次の場合にお薦めします。

• リポジトリYUM HTTPサーバーとして使用可能な別のサーバーが存在しない。

• 追加ULNチャンネルからの更新を必要とするカスタマイズされたソフトウェアが、Exadataデータベース・サーバーに存在しない。

• 簡略化されたメソッドが推奨される。

注意:

圧縮ISOイメージは、更新ユーティリティを実行しているノード上にのみ存在する必要があります。圧縮ISOイメージの配信は、更新ユーティリティによって処理されます。

前提条件チェックを実行(-precheck)して、リポジトリが使用可能であることを検証できます。

6.5.8.2 独立したサーバー上のULN Oracle Exadataチャンネルからローカル・ミラーをYUM HTTPリポジトリとして設定する

このメソッドは、次の条件が満たされた場合に推奨されます。

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

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

• 別のLinuxサーバーにULNミラーを構築するインフラストラクチャが存在する。

• Exadataデータベース・サーバーで、他のULNチャンネルからの更新が必要なカスタマイズされたソフトウェアを使用している。

ミラー・サーバーは、ULNからダウンロードした場合と同じく、Exadataデータベース・サーバー用にダウンロードしたExadataソフトウェア更新を保持する独立したLinuxサーバーです。Exadataデータベース・サーバーは、このローカル・ミラー(YUM HTTPリポジトリ)に接続して更新を取得します。

注意:

Exadataデータベース・サーバーを、ローカルULNミラーとして使用することはできません。そのようにすると、リポジトリを構築するためにULNが必要とするパッケージと、Exadataソフトウェア更新によってExadataデータベース・サーバーにインストールまたは更新されたパッケージとの間に、依存性の競合が発生する場合があります。使用できる独立したサーバーがない場合は、かわりにISOイメージによる方法を使用してください。My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、圧縮イメージの場所を更新ユーティリティに渡すを参照してください。

ローカル・リポジトリを初めて設定するとき、YUMリポジトリをホストするサーバーで使用するLinuxリリースによっては、追加のLinuxサブスクリプションが必要になる場合があります。サーバーは、次のような追加ULNチャンネルにサブスクライブして、リポジトリを構築する必要があります。

• 64ビット・システム: Enterprise Linux 5システムの場合: el5_x86_64_addonsが必要です。

• 64ビット・システム: Oracle Linux 5システムの場合: el5_x86_64_addonsが必要です。

• 64ビット・システム: Oracle Linux 6システムの場合: ol6_x86_64_addonsが必要です。

注意:

登録後、ローカルULNミラーを実行しているオペレーティング・システムに応じて、システム・サーバーはel5_x86_64_latest、ol5_x86_64_latestまたはol6_x86_64_latestを自動的にサブスクライブします。

ローカルULNミラーをYUMリポジトリとして作成および保守するには、「ローカルUnbreakable Linux Networkミラーの作成方法」(http://www.oracle.com/technetwork/articles/servers-storage-admin/yum-repo-setup-1659167.html)の説明に従って、前提条件およびサーバー設定手順を確認してください。前述の手順5については、リストされたチャンネルに加えて、Exadataのために次の手順を実行します。

• Oracle ExadataパッチのREADMEにリストされているチャンネルを追加します。たとえば、exadata_dbserver_12.1.2.3.2_x86_64_baseです。

  サブスクライブするOracle Exadataチャンネルは、更新するOracle Exadataソフトウェア・リリースによって異なります。詳細は、リリースに対応したパッチのREADMEを参照してください。

前のリンクに示されているYUMミラー作成手順では、ローカル・ミラーへの移入に使用できるスクリプト(uln-yum-mirror)が用意されています。rootとしてこのスクリプトを実行すると、ULNからリポジトリを保持するローカル・ディレクトリへのrpmのダウンロードが始まります。

Webサーバーをインストールし、そのdocument Rootディレクトリがディスク上のこのリポジトリの場所を指すように構成する必要があります。これにより、HTTP Webサーバーを使用するOracle Exadata Linuxデータベース・サーバーで、Oracle Exadataチャンネル・コンテンツを使用できるようになります。これについては、前述の手順の手順7で説明されています。

更新ユーティリティを実行するときには、リポジトリの場所へのURLを指定します。このURLは、常に、repodataディレクトリのレベルである必要があります。前提条件チェック(-precheck)を実行して、リポジトリが機能していることを検証できます。前提条件チェックの実行で、YUMリポジトリを使用した前提条件チェックの例を参照してください。

注意:

IPv6アドレスのみをリスニングしているYUMリポジトリにアクセスするには、Exadataデータベース・サーバーでExadataリリース12.1.2.2.0以上が実行されている必要があります。

6.5.8.3 My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、それをWebサーバー上でYUM HTTPリポジトリとして使用できるようにする

Oracle Exadataソフトウェア更新を保持するISOイメージ・チャンネルをダウンロードして解凍し、すべてのOracle Exadataデータベース・サーバーへのHTTP接続が可能なWebサーバーに配置できます。このメソッドは、次の条件が満たされた場合に推奨されます。

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

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

  注意:

  Exadata以外のシステムでこのISOイメージに対して更新ユーティリティを実行する場合は、各データベース・サーバーでローカルに対処されます。このような場合、ローカル・ミラーを設定する必要はありません。

• 追加ULNチャンネルからの更新を必要とするカスタマイズされたソフトウェアが、データベース・サーバーに存在しない。

  注意:

  データベース・サーバーにカスタム・ソフトウェアがインストールされている場合には、ISOではなくHTTP YUMリポジトリを使用すると、より適切です。これは、rpmを元どおりに追加/インストールする際の柔軟性が向上するためです。

Oracle Exadataチャンネル・コンテンツのISOイメージを、HTTPサーバーを実行するLinuxベースのサーバーで使用するには、次の手順を使用します。この手順は、他のオペレーティング・システムに応じて調整できます。この手順では、ISOイメージは/u01/app/oracle/stageディレクトリにコピーされます。Webサーバー・ドキュメント内のDocument Rootエントリは/var/www/htmlです。手順では、例としてリリース12.1.1.1.0を使用しています。

注意:

Webサーバーとして、独立したサーバー(Exadata以外のデータベース・サーバー)を使用することをお薦めします。

1. 次のコマンドを使用して、ISOイメージ・マウント・ポイントをrootユーザーとして作成します。

   [root@nonExadataHost ]# mkdir -p /var/www/html/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base
   
   [root@nonExadataHost ]# mkdir –p /u01/app/oracle/stage
   

2. 圧縮ISOイメージをWebサーバーの/u01/app/oracle/stageにコピーします。

3. 次のコマンドを使用して、ISOイメージをrootユーザーとして、解凍およびマウントします。

   [root@nonExadataHost ]# unzip p17997668_121110_Linux-x86-64.zip
   
   [root@nonExadataHost ]# mount -o loop /u01/app/oracle/stage /121110_base_repo.iso /var/www/html/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base
   

4. rootユーザーとして、httpdサービスを開始します。これは、httpdがインストール済であることを前提としています。

   [root@nonExadataHost ]# service httpd start
   

5. Webブラウザを使用して、接続したYUM HTTPリポジトリを識別してテストします。リポジトリURLの例を、次に示します。

   http://yum-repo/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base/x86_64/
   

6. rootユーザーとして前提条件チェックを実行して、リポジトリが正しく設定されていることを検証します。前提条件チェックの実行を参照してください。

6.5.9 Exadata廃止パッケージの管理

リリース11.2.3.3.0以上に更新すると、Exadataデータベース・サーバーの一部のパッケージが廃止されて使用できなくなります。Exadataデータベース・サーバーの更新中に、更新ユーティリティは除外rpmリストおよび廃止rpmリストをログ・ファイルに出力します。

次の例では、ログ・ファイルに出力された除外リストおよび廃止リストを示します。この例では、除外リストはまだユーザーにより作成されていません。

RPM exclusion list  : Not in use (add rpms to /etc/exadata/yum/exclusion.lst and restart dbnodeupdate.sh)
RPM obsolete list   : /etc/exadata/yum/obsolete.lst (lists rpms to be removed by the update)
                    : RPM obsolete list is extracted from exadata-sun-computenode-11.2.3.3.0.131014.1-1.x86_64.rpm

どのパッケージが廃止されるかを確認するには、obsolete.lstファイルの内容を確認します。このファイルには、Exadataによって廃止されるように定義されたパッケージが記載されています。これらのパッケージは、何もアクションを実行しない場合、更新中に削除されます。このリストに手動で追加されたパッケージは無視されます。次に、obsolete.lstファイルのごく一部をサンプルとして示します。

[root@dm01 ]# cat /etc/exadata/yum/obsolete.lst
# Generated by dbnodeupdate.sh runid: 021213024645
at.x86_64
java-*-openjdk
rhino.noarch
jline.noarch
jpackage-utils.noarch

obsolete.lstファイルにリストされたパッケージが削除されないようにするには、/etc/exadata/yum/exclusion.lstファイルを作成し、保持するパッケージのrpm名(ワイルドカード使用可)を記載します。/etc/exadata/yum/exclusion.lstファイルを、使用するすべてのExadataデータベース・サーバーに配置します。

次の例は、除外リストに追加されたパッケージを示します。

[root@dm01 ]# cat /etc/exadata/yum/exclusion.lst
java-*-openjdk

exclusion.lstファイルにエントリを追加し、更新ユーティリティを再実行すると、除外リストが検出されます。除外リスト上のrpmパッケージは、obsolete.lstファイルに表示されていますが、exclusion.lstファイル内にリストされたパッケージは更新中に削除されません。

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

セキュリティの確保やカスタマイズのために、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コマンドを使用しないでください。

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

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

• 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前提条件チェックが確実に機能するように、更新ユーティリティによる前提条件チェック中に、特定のパッケージが削除されることがあります。これは、一部のExadataストレージ・サーバーには、解決する必要がある既知の依存性があるためです。前提条件チェック中にこのようなRPMが削除されることは少なく、削除されてもExadataの機能には影響を及ぼしませんが、システムによっては前提条件チェックによる変更が許可されないこともあります。このようなシステムには、-nomodify_at_prereqフラグを使用することをお薦めします。このフラグを使用すると、更新ユーティリティはシステムからパッケージを削除するのではなく、削除した(インストールしたか、あるいはインストールしなかった)パッケージのリストを生成します。このフラグを使用すると、依存性チェックが失敗する場合があります。このため、計画メンテナンス・ウィンドウでバックアップのみの実行を行った後で、-nomodify_at_prereqフラグを指定しないで依存性チェックを再実行することをお薦めします。

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

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

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

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

デフォルトでは、アクティブなNFSマウントなど前提条件チェックで警告が発生すると、チェックは失敗します。アクティブなNFSマウントを許可する場合、リリース12.1.2.1.1以降では-allow_active_network_mountsフラグを使用できます。

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

前提条件チェックの例

次のコマンドは、ISOを使用してRPMを削除しない前提条件チェックの例を示しています。このコマンドは、rootとして実行します。

[root@dm01 ]# ./patchmgr -dbnodes dbs_group -precheck -iso_repo /u01/exa/p22750145_121230_Linux-x86-64.zip 
-target_version 12.1.2.3.0.160207.3 -nomodify_at_prereq

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

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

-iso_repoには、更新ユーティリティを実行しているノード上にあるISO (YUM)リポジトリの場所を指定します。これは、-yum_repo<location>で置き換えることができます。

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

-nomodify_at_prereqは、前提条件チェック時にRPMが削除されないことを示します。

次のコマンドは、ISOを使用して必要なRPMの削除を許可する前提条件チェックの例を示しています。このコマンドは、root以外のユーザーとして実行します。

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes dbs_group -precheck -iso_repo /u01/exa/p22750145_121230_Linux-x86-64.zip 
-target_version 12.1.2.3.0.160207.3 -log_dir auto

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

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

このことは、-nomodify_at_prereqフラグを指定しないで前提条件チェックを実行する前や、前提条件/依存性チェックにパスするためのその他の変更を(手動で)加える前に、バックアップのみモードで更新ユーティリティを実行することを意味します。バックアップのみアクションでは、アクティブなルートと/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が再作成されます。

バックアップは、すべてのシステム・サービスが稼働している間に実行できます。リリース12.1.2.1.1以降、ユーティリティは-allow_active_network_mountsフラグでアクティブなネットワーク・マウント(NFS)をサポートしています。

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

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

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

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

バックアップのみの例

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

[root@dm01 ]# ./patchmgr -dbnodes dbs_group -backup -iso_repo /u01/exa/p22750145_121230_Linux-x86-64.zip 
-target_version 12.1.2.3.0.160207.3 -allow_active_network_mounts

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

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

• -iso_repoには、更新ユーティリティを実行しているノード上にあるISO (YUM)リポジトリの場所を指定します。あるいは、-yum_repoフラグを使用して、YUMリポジトリのHTTPの場所を指定することもできます。

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

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

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

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes ~/dbs_group_scab -backup -iso_repo /u01/iso/p23557378_121223_Linux-x86-64.zip 
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -smtp_from "[e-mail]" 
-smtp_to "[e-mail]"

6.5.13 更新の実行

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

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

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

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

注意:

-nobackupフラグを使用するのは、前提条件チェックの実行前に、-nomodify_at_prereqフラグを指定しないですでにバックアップを作成していた場合のみとしてください。

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

• -upgrade。更新アクションを指定します。

• -iso_repo (ISOイメージの場合)または-yum_repo (HTTPの場所の場合)。YUMリポジトリを指します(例6-9を参照)

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

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

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

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

[root@dm01 ]# ./patchmgr -dbnodes ~/dbs_group -upgrade -iso_repo /u01/iso/p23557378_121223_Linux-x86-64.zip 
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -smtp_from "[e-mail]" 
-smtp_to "[e-mail]" -nobackup

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

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes ~/dbs_group -upgrade -iso_repo /u01/iso/p23557378_121223_Linux-x86-64.zip 
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -log_dir auto -smtp_from "[e-mail]" 
-smtp_to "[e-mail]" -nobackup

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

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

[root@dm01 ]$ ./patchmgr -dbnodes ~/dbs_group -upgrade -yum_repo http://yum-repo/yum/ol6/EXADATA/dbserver/12.1.2.2.3/base/x86_64/ 
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -smtp_from "[e-mail]" -smtp_to "[e-mail]"
-nobackup

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

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

6.5.14 更新のロールバック

バックアップを使用すると、更新の成否に関係なく、更新をロールバックできます。このバックアップは、計画メンテナンスの前の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のサイズは小型です。

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

[root@dm01 ]# ./patchmgr -dbnodes dbs_group -rollback -target_version 12.1.2.3.0.160207

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

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

-target_versionには、ロールバック先のターゲット・リリースを指定します。

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

注意:

以前のイメージにロールバックするときには、ファームウェア更新はロールバックされません。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以上にのみ適用されます。

6.6 Oracle Exadata System Softwareリリース11.2.2.4.2を実行しているデータベース・サーバーの更新

Oracle Exadata System Softwareリリース11.2.2.4.2を実行しているデータベース・サーバーの更新には、サーバーでyumを使用する準備のための更新が含まれます。

サーバーは、dbnodeupdate.shユーティリティを使用して準備します。このため、Oracle Exadata System Softwareリリース11.2.2.4.2からの更新では、2つのdbnodeupdate.shユーティリティを別々の引数で実行する必要があります。どのコマンドをいつ実行するか、ユーティリティから指示があります。

データベース・サーバーの更新は、次の前提条件に基づいています。

• Oracle Exadata System Softwareのリリースは11.2.2.4.2です。
• データベース・サーバーで、Oracle Linux 5.5以上を実行している。
• データベース・サーバー更新が、ローカルULNミラーまたはローカルISOイメージとして使用可能である。

この項では、次の項目について説明します。

• リリース11.2.2.4.2のデータベース・サーバー上でのdbnodeupdate.shユーティリティの使用の準備
• dbnodeupdate.shユーティリティの実行

6.6.1 リリース11.2.2.4.2のデータベース・サーバー上でのdbnodeupdate.shユーティリティの使用の準備

この手順では、サーバー上でユーティリティをダウンロードおよび準備する方法について説明します。

dbnodeupdate.shユーティリティは、My Oracle SupportのドキュメントID 1553103.1から入手できます。dbnodeupdate.shユーティリティは、11.2.2.4.2を実行しているリリースを、直接Oracle Linux 6に更新できます。

1. dbnodeupdate.shユーティリティをMy Oracle Supportからダウンロードします。
2. データベース・サーバーにrootユーザーとしてログインします。
3. 圧縮ファイルを、データベース・サーバーの/u01/dbnodeupdateディレクトリに置きます。このディレクトリがまだ存在しない場合は、ディレクトリを作成します。
4. /u01/dbnodeupdateディレクトリ内のp16486998_12xxxx_Linux-x86-64.zipパッケージ・ファイルを、次のコマンドを使用して解凍します。

   [root@dm01 ]# unzip p16486998_12xxxx_Linux-x86-64.zip
   

   注意:

   • 圧縮ISOを使用する場合、データベース・サーバーにアップロードして、使用可能な空き領域の/u01/dbnodeupdateディレクトリに置きます。このディレクトリがまだ存在しない場合は、ディレクトリを作成します。
   • ローカルULNミラーを使用する場合、HTTPの場所が使用可能であるか確認します。
   • ISOコンテンツがWeb上で使用可能な場合、コンテンツをWebサーバーにアップロードして、マウントし、URLを確認します。
   • SUDO権限のあるユーザーは、SUDOを使用してdbnodeupdate.shユーティリティを実行できます。

6.6.2 dbnodeupdate.shユーティリティの実行

リリース11.2.2.4.2を実行するデータベース・サーバーでdbnodeupdate.shユーティリティを使用できます。

1. データベース・サーバーにrootユーザーとしてログインします。
2. 次のコマンドを使用してdbnodeupdate.shユーティリティを実行します。ここで、repoはULNミラーのHTTPの場所または圧縮ISOイメージの場所です。

   [root@dm01 ]# ./dbnodeupdate.sh -u -l repo
   

   データベース・サーバーは自動的に再起動します。

   注意:

   再起動の直前に、次の手順の指示が画面に表示されます。
3. 手順2で説明したように、再起動の後、次のコマンドを実行します。圧縮ISOイメージが使用された場合、ユーティリティはISOイメージを自動的に再マウントします。

   [root@dm01 ]# ./dbnodeupdate.sh -u -p 2 
   

4. 次のコマンドを使用して、更新を終了します。

   [root@dm01 ]# ./dbnodeupdate.sh -c
   

   完了の手順では、ユーティリティが、更新後のチェック、ベスト・プラクティスの適用、Oracleホームの再リンクを実行した後、スタックを再起動します。

   注意:

   dbnodeupdate.sh -cコマンドの入力時に、更新の実行が継続中の場合があります。この時、ユーティリティはイメージ・ステータスを判別するまで待機します。保留中の更新が有効になるまでの待機中に、システムが再起動することがあります。このような場合、システムがオンラインに戻ってからdbnodeupdate.sh -cコマンドを再び入力します。

6.7 Oracle Exadata Storage Serverの更新

Oracle Exadata System Softwareリリースの更新には、次に示すOracle Exadata Storage Server内のコンポーネントに対する更新が含まれています。

• Oracle Linuxオペレーティング・システム

• ファームウェア(フラッシュ、ディスク、RAIDコントローラ、ILOM、HCA)

• Oracle Exadata System Software

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

Oracle Exadata Storage Serverに対する更新は、特に指定されている場合を除き、Oracle Exadata Database ServerまたはInfiniBandスイッチへの更新とは無関係に適用できます。リリースされるすべてのOracle Exadata System Software更新を個別に適用することが必要になるわけではありません。たとえば、リリースを2つか3つスキップして、より新しいリリースに直接更新できます。

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

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

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

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

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

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

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

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

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

• Exadataストレージ・サーバー更新の監視、検証およびトラブルシューティング

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

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によってアラートが生成されます。

6.7.2 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

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

注意:

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

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

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

いつ	タスク
更新までの数週間から数日前	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を実行します。

6.7.4 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]"
   

6.7.5 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を参照してください。

6.7.6 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 -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
   

6.8 Exadata InfiniBandスイッチ・ファームウェアの更新

InfiniBandスイッチを更新およびダウングレードするには、ストレージ・サーバー更新に付属している同じ更新ユーティリティを使用します。更新ユーティリティを使用できる最小スイッチ・ファームウェア・リリースは1.3.3-2です。スイッチのファームウェアは、常にローリング形式で更新します。

注意:

InfiniBandスイッチ・ファームウェアの更新に使用されるpatchmgrは、Exadataデータベース・サーバー・ソフトウェア更新に使用されるものとは異なります。

• InfiniBandスイッチ・ファームウェア更新の準備

• InfiniBandスイッチ・ファームウェア・ソフトウェアの更新

• InfiniBandスイッチ・ファームウェア・ソフトウェアのダウングレード

6.8.1 InfiniBandスイッチ・ファームウェア更新の準備

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

InfiniBandスイッチを更新するには、スイッチのファームウェアがリリース1.3.3-2以上である必要があります。スイッチのファームウェアがそれより前のリリースである場合は、My Oracle Supportノート888828.1の説明に従って、ファームウェアをリリース1.3.3-2に更新します。InfiniBandスイッチが実行しているソフトウェアのバージョンを特定するには、versionコマンドを使用します。

1. rootユーザーによるスイッチへのSSHアクセスが可能なExadataデータベース・サーバーにrootユーザーとしてログインします。データベース・サーバーは、スイッチと同じInfiniBandネットワークに属している必要があります。

2. スイッチのバージョンを特定します。

   [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コマンドを使用します。他の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]
   

   注意:

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

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

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

6.8.2 InfiniBandスイッチ・ファームウェア・ソフトウェアの更新

次のコマンドを使用して、スイッチを更新します。

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

6.8.3 InfiniBandスイッチ・ファームウェア・ソフトウェアのダウングレード

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

InfiniBandスイッチ・ファームウェアをダウングレードするコマンドの例:

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

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

6.9 Oracle LinuxでのOracle Java SEのアップグレード

データベース・サーバーおよびストレージ・サーバーでOracle Linux 6を実行しているOracle Java SE (JDK)をアップグレードできます。

Oracle Exadata System Softwareリリース12.1.2.1.0以降では、Oracle Exadata Database MachineサーバーにJava JDKパッケージが含まれています。以前のリリースのOracle Exadata System Softwareでは、JDKパッケージは使用されません。以前のリリースのOracle Exadata System Softwareを実行しているサーバーにjava-version-openjdkなどのパッケージがインストールされている場合、パッケージはOracle Exadata Database Machineによって使用されず、削除が可能です。詳細は、My Oracle Supportノート1405320.1を参照してください。

JDKパッケージを更新するには、JDK RPMパッケージをダウンロードして更新し、新しいJDKパッケージを使用するようにMSを再構成する必要があります。JDKパッケージを更新するには、ULNを使用するようにYUMを構成するか(現在、Oracle Linux 6でのみ使用可能)、直接パッケージ・ダウンロード(ULNを使用できない場合)を使用します。

• MSプロセスの停止
• Java JDKパッケージのダウンロードおよび更新

• 管理サーバー(MS)の再構成

6.9.1 MSプロセスの停止

JDKパッケージを更新する前に、管理サーバー(MS)を停止する必要があります

注意:

これらの手順は、オンプレミスのデプロイメントおよび管理ドメイン(dom0)にのみ適用可能です。ゲスト・ドメイン(domU)にはMSがインストールされていません。

1. サーバーにrootユーザーとしてログインします。
2. MSを停止します。
   • データベース・サーバーの場合:

     dbmcli -e alter dbserver shutdown services ms

   • ストレージ・サーバーの場合:

     cellcli -e alter cell shutdown services ms

6.9.2 Java JDKパッケージのダウンロードおよび更新

現在の環境に応じて、3つの手順のいずれかを使用してJDKパッケージをダウンロードおよび更新できます。

YUMおよびUnbreakable Linux Network (ULN)の使用は、Oracle Linux 6を実行しているOracle Exadata Database Machineオンプレミス・データベース・サーバーでのみサポートされます。これは、ストレージ・サーバーまたはOracle VM環境の管理ドメイン(dom0)またはユーザー・ドメイン(domU)ではサポートされていません。

次のいずれかの方法を使用して、JDKパッケージをダウンロードおよび更新します。

• YUMおよびULNを使用したデータベース・サーバーのJDKパッケージの更新
• Oracle Exadata System Softwareバージョン12.1.2.1.0から12.1.2.2.0へのJDKパッケージの手動更新
• Oracle Exadata System Softwareリリース12.1.2.2.1以降でのJDKパッケージの手動更新

6.9.2.1 YUMおよびULNを使用したデータベース・サーバーのJDKパッケージの更新

オンプレミスのOracle Exadata Database Machineのデータベース・サーバーがOracle Linux 6を実行している場合、YUMおよびUnbreakable Linux Network (ULN)を使用して更新プロセスを簡略化できます。

JDKパッケージを直接ダウンロードするか、YUMおよびULNを使用できます。YUMおよびULNを使用したJDKパッケージの更新には、次のタスクが含まれます。

1. Oracleパブリック・リポジトリに接続するためのYUMの構成
2. Oracle Linux 6システムのULNへの登録
3. ULNを使用したデータベース・サーバーでのJDKのアップグレード

6.9.2.1.1 Oracleパブリック・リポジトリに接続するためのYUMの構成

Oracle Linux YUMサーバーは、最新のOracle Linuxパッケージをインストールするための無料で便利な方法を提供します。Unbreakable Linux Network (ULN)では、特定のバージョンのパッチおよび正誤表を更新できます。

この手順は、Oracle Linux 6を実行しているOracle Exadata Database Machineオンプレミス・データベース・サーバーでのみサポートされます。これは、ストレージ・サーバーまたは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)。

   たとえば、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を参照してください。

6.9.2.1.2 Oracle Linux 6システムの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の説明
      

6.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)の再構成」の手順に従います。

6.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)の再構成」の手順に従います。

6.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)の再構成」の手順に従います。

6.9.3 管理サーバー(MS)の再構成

Java JDKパッケージを更新したら、更新されたJDKバージョンを使用するようにMSプロセスを再構成する必要があります。

ユーザー・ドメイン(domU)にMSがインストールされていないため、これらの手順は仮想デプロイメント上の物理デプロイメントおよび管理ドメイン(dom0)にのみ適用可能です。

1. データベース・サーバーまたはストレージ・サーバーにrootとしてログインします。
2. MSプロセスが停止していることを確認します。
   • データベース・サーバーの場合:

     dbmcli -e alter dbserver shutdown services ms

   • ストレージ・サーバーの場合:

     cellcli -e alter cell shutdown services ms

3. Oracle Exadata System Softwareリリース12.2.x、バージョン12.2.1.1.4以降またはOracle Exadata System Softwareリリース18c、バージョン18.1.2以降の場合、次の手順を実行します(他のリリースは必要ありません)。
   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

6.10 SSH等価の設定

Oracle Exadata Database Machine上でソフトウェアを更新する前に、SSH等価を構成する必要があります。

Oracle Exadata Database ServerおよびOracle Exadata Storage Serverの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アクセスを必要とします。ストレージ・サーバーのロック解除の詳細は、『Oracle Exadata System Softwareユーザーズ・ガイド』のストレージ・サーバーでのSSHの無効化のトピックのセルの一時的なロック解除に関するサブセクションを参照してください。

6.11 Oracle Exadata Database Machineでのソフトウェア更新のトラブルシューティング

Oracle Exadata Database Machineでソフトウェアの更新時にエラーまたは問題が発生した場合に、次のトピックを確認します

• Exadataデータベース・サーバー更新のトラブルシューティング
• Exadataストレージ・サーバー更新の監視、検証およびトラブルシューティング
• Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティング
• Exadataデータベース・サーバーでのmultilib問題のトラブルシューティング

6.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サポート・サービスでサービス・リクエストを開きます。

6.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

6.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というヘッダーのセクションを探します。インストール済の(追加の)パッケージがある場合は、それに関する詳細を確認できます。

ログ・ファイルで、MinimumおよびExact依存性チェックの結果について、開始(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を削除した後、更新または前提条件チェックを再起動します。

6.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問題の解決策となります。