| Oracle® Exadata Database Machineメンテナンス・ガイド 12c リリース2 (12.2) E84907-03 |
|
 前 |
 次 |
Exadataソフトウェア更新は、次の3つの主要コンポーネントに適用されます。
Exadataストレージ・サーバー
Exadataデータベース・サーバー
Exadata InfiniBandスイッチ
Exadataストレージ・サーバーおよびExadataデータベース・サーバーの更新には、一般的に、次のものに対する更新が含まれています。
Oracle Linuxオペレーティング・システム
Exadataソフトウェア
ファームウェア(たとえば、ディスク、フラッシュ、RAIDコントローラ、ILOM、HCA)
一般的に、コンポーネントは推奨される最小リリースと揃えることをお薦めしますが、コンポーネントごとに別々に更新することもできます。たとえば、Exadata InfiniBandスイッチをExadataストレージ・サーバーおよびExadataデータベース・サーバーよりも後に更新できます。ただし、My Oracle Supportノート888828.1を参照して、依存性がないかどうかを確認する必要があります。
リリースされるすべてのExadataソフトウェア更新を個別に適用することが必要になるわけではありません。たとえば、リリースを2つか3つスキップして、より新しいリリースに直接更新できます。データベース・サーバーは年に2回更新することをお薦めします。
この項では、3つの主要コンポーネントのそれぞれに関して、更新を準備、適用およびロールバックする方法について説明します。まず汎用的なアプローチについて説明し、その後、一般的な更新シナリオを示します。
イメージ・バージョンのコンポーネント
リリースのイメージ・バージョンは、次の3つのコンポーネントで構成されています。たとえば、imageinfo -verが12.1.2.1.1.150316.2を返した場合、次のようになります。
製品バージョンは12.1.2.1.1です。
日付コードは150316です。
Oracleの内部ビルド番号は2です。このコンポーネントはオプションです。
ほとんどの状況においては、製品バージョン(たとえば12.1.2.1.1)のみでリリースを参照することで十分です。ただし、アップグレードするときには、インストール済リリースおよびターゲット・リリースの製品バージョンと日付コードの両方を考慮する必要があります。アップグレードは、次の場合に.許可されます。
ターゲット・リリースの製品バージョンがインストール済ソフトウェアよりも大きく、かつ
ターゲット・リリースの日付コードがインストール済ソフトウェアよりも大きい必要があります。
たとえば、製品バージョン12.1.1.1.2と日付コード150411で構成されるイメージ・バージョン12.1.1.1.2.150411を現在実行しているシステムがあるとします。
12.1.2.1.2.150617.1へのアップグレードは、両方のルールが満たされているため、許可されます。
12.1.2.1.1.150316.2へのアップグレードは、インストール済ソフトウェアの日付コード150411がターゲット・リリースの日付コード150316よりも大きいため、許可されません。
ソフトウェア更新を開始する前に、ベスト・プラクティスを確認し、アップグレードするバージョンを決定し、適切なパッチ適用ソフトウェアを入手する必要があります。
Exadata Database Machineで実行するソフトウェアは、2つのカテゴリに分かれます。
Exadataインフラストラクチャ・ソフトウェア
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア
次の表は、Exadata Database Machineで実行するソフトウェアの2つの主なカテゴリを説明しています。
| ソフトウェア | インストールされているコンポーネント | ソフトウェアの内容 | ソフトウェア・バージョンの例 |
|---|---|---|---|
Exadataインフラストラクチャ・ソフトウェア |
|
|
Exadataストレージ・サーバーおよびデータベース・サーバー:
Exadata InfiniBandスイッチ
|
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア |
Exadataデータベース・サーバー |
|
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ソフトウェア・メンテナンスのその他の関連情報ソースへの参照
主なソフトウェア・カテゴリ(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の後続のパッチ・セット・リリースまたはデータベース・パッチより前に修正が必要なユーザーに提供される個別のバグ修正です。個別パッチのインストールは必要に応じて行われ、定期的にスケジュールされた計画メンテナンス・イベントではありません。 |
各ソフトウェア・リリース・タイプには様々な可用性の頻度があります。
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か月を超えないようにしてください。 |
Exadataソフトウェアの定期的な更新を計画する必要があります。
次に、リリースの通常の間隔を使用した4年サイクルにわたる四半期に一度の高度なソフトウェア・メンテナンス計画の例を3つ示します。
注意:
リリース頻度は、ここに記載されている内容によって異なります(特に新機能を含むリリースの場合)。例5-1 本番システム・ソフトウェアのメンテナンス計画
目標 - 重要な修正やセキュリティ修正が使用可能になったら適用し、新機能リリースをできるだけ遅く導入することで、リスクを最小限にします。 可能な場合は、Exadataの新機能リリースとDatabaseの新機能リリースを同時に導入しないでください。
| アクション | Y1 Q1 | Y1 Q2 | Y1 Q3 | Y1 Q4 | Y2 Q1 | Y2 Q2 | Y2 Q3 | Y2 Q4 | Y3 Q1 | Y3 Q2 | Y3 Q3 | Y3 Q4 | Y4 Q1 | Y4 Q2 | Y4 Q3 | Y4 Q4 | Y5 Q1 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
次のExadata継続リリースへの更新 |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
||||
次のExadata機能リリースへの更新 |
X |
X |
X |
X |
|||||||||||||
次のデータベース・プロアクティブ・バンドル・パッチへの更新 |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
||
次のデータベース・パッチ・セット・リリースへの更新 |
X |
||||||||||||||||
次のデータベース・メジャー・リリースまたはメンテナンス・リリースへの更新 |
X |
例5-2 本番システム・ソフトウェアの更新の少ないメンテナンス計画
目標 - 代替四半期更新を適用することで、メンテナンス時間を最小限にします。可能な場合は、Exadataの新機能リリースとDatabaseの新機能リリースを同時に導入しないでください。
| アクション | Y1 Q1 | Y1 Q2 | Y1 Q3 | Y1 Q4 | Y2 Q1 | Y2 Q2 | Y2 Q3 | Y2 Q4 | Y3 Q1 | Y3 Q2 | Y3 Q3 | Y3 Q4 | Y4 Q1 | Y4 Q2 | Y4 Q3 | Y4 Q4 | Y5 Q1 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
次のExadata機能リリースへの更新 |
X |
X |
X |
||||||||||||||
次のExadata継続リリースへの更新 |
X |
X |
X |
X |
X |
||||||||||||
次のデータベース・メジャー・リリースまたはメンテナンス・リリースへの更新 |
X |
||||||||||||||||
次のデータベース・パッチ・セット・リリースへの更新 |
X |
||||||||||||||||
次のデータベース・プロアクティブ・バンドル・パッチへの更新 |
X |
X |
X |
X |
X |
例5-3 開発およびテスト・システム・ソフトウェアのメンテナンス計画
目標 - 最新の機能およびソフトウェア更新をできるだけ早く導入します。
| アクション | Y1 Q1 | Y1 Q2 | Y1 Q3 | Y1 Q4 | Y2 Q1 | Y2 Q2 | Y2 Q3 | Y2 Q4 | Y3 Q1 | Y3 Q2 | Y3 Q3 | Y3 Q4 | Y4 Q1 | Y4 Q2 | Y4 Q3 | Y4 Q4 | Y5 Q1 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
次のExadata機能リリースへの更新 |
X |
X |
X |
X |
|||||||||||||
次のExadata継続リリースへの更新 |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
||||
次のデータベース・メジャー・リリースまたはメンテナンス・リリースへの更新 |
X |
X |
|||||||||||||||
次のデータベース・パッチ・セット・リリースへの更新 |
X |
X |
|||||||||||||||
次のデータベース・プロアクティブ・バンドル・パッチへの更新 |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
X |
Oracle Exadata Database Machineソフトウェアを更新する場合、更新されるコンポーネントに応じて特定のユーティリティを使用します。
| 更新タイプ | ユーティリティ | コンポーネント | 説明 |
|---|---|---|---|
更新前の準備状況チェック |
Oracle ExaCHK |
Exadata Database Machine |
メンテナンス準備状況を確認し、重大な問題の発生を特定し、ソフトウェアを更新するバージョン推奨を提供するために使用されるExadataヘルスチェック・ツールです。 My Oracle Supportのドキュメント1070954.1からOracle ExaCHKを取得してください。 |
Exadataインフラストラクチャ・ソフトウェア |
patchmgr |
|
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パッチ・セット、メジャー・リリースまたはメンテナンス・リリースをインストールし、Grid Infrastructureをアップグレードするソフトウェア・インストール・ツールです。たとえば、OUIは、 Database 12.2.0.1をインストールしたり、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ソフトウェアのプロビジョニング、パッチ適用およびアップグレードを行うソフトウェア・メンテナンス・ツールです。 RHPをOracle Clusterwareの機能として使用します。 |
Exadataインフラストラクチャ・ソフトウェア Oracle Grid InfrastructureおよびOracle Databaseソフトウェア |
Enterprise Manager Cloud Control |
|
Enterprise Manager Cloud Controlには、ソフトウェア更新をExadataシステムに適用するライフサイクル管理機能があります。 |
関連トピック
ソフトウェア更新の計画の一環として、更新を実行する様々な方法、およびソフトウェアを更新するためのベスト・プラクティスを確認する必要があります。
データベースがオンラインで使用可能な間はローリング形式でソフトウェア更新を実行し、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ソフトウェア・ホームから実行するデータベースは影響を受けません。 |
非ローリング |
|
データベース使用不可 ワークロードをOracle Data GuardまたはOracle Golden Gateスタンバイ・システムに移動して、影響を最小限に抑えます。 |
適格な修正のオンライン更新は、Oracle LinuxおよびOracle Databaseでサポートされています。
通常、計画ソフトウェア更新では、更新後にコンポーネントを再起動する必要があります。たとえば、Exadataデータベース・サーバーは、Exadataソフトウェア・リリースを適用した後に再起動して、システム・ファームウェアを更新し、新しいOracle Linuxカーネルをアクティブにする必要があります。同様に、Oracleデータベース・インスタンスを停止してから再起動して、ソフトウェア更新をデータベース・ホームに適用する必要があります。
ただし、オンラインで適用が可能で、修正を適用してアクティブにするためにコンポーネントを再起動する必要がない個別修正が提供される場合もあります。適格な修正のオンライン更新は、次のコンポーネントでサポートされています。
Kspliceオフライン・クライアントを使用したExadataデータベース・サーバー上のOracle Linuxカーネル。
OPatchオンライン・パッチ適用を使用したOracle Database。
通常、オンライン更新は、次にスケジュールされた計画ソフトウェア・メンテナンスの前に重要な修正をシステムに適用する必要がある場合に、一時的な措置として実行されます。
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を使用して、パッチ・セットおよびリリース更新でのデータベース・アップグレードによる停止時間を減らします。データベースのアップグレード中の停止時間は、ソース・データベースがオンラインのままで現在のバージョンを実行して、ターゲット・データベースを新しいバージョンにアップグレードし、同期を維持することを許可することにより短縮されます。 |
関連トピック
次の操作のプラクティスによって、最適なソフトウェア・メンテナンスが可能になります。
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更新が失敗します。
関連トピック
最も安定したセキュアなシステムを維持するために、定期的に更新されるすべてのコンポーネントのソフトウェアは、推奨される最小リリースと揃えることをお薦めします。
ただし、ソフトウェア・メンテナンス・ウィンドウ中にコンポーネントのサブセットのみを更新することがサポートされており、残りのコンポーネントは以前のバージョンのままです。 たとえば、次のシナリオがサポートされます。
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への更新)。
関連トピック
一般に、ソフトウェア更新を実行すると、更新は、ビジネス・ニーズおよびメンテナンス・ウィンドウの要件に基づいた順序でコンポーネントに適用されます。
ソフトウェア更新を適用する推奨順序は次のとおりです。
Oracle Grid InfrastructureおよびOracle Databaseソフトウェア
Exadataデータベース・サーバー・ソフトウェア
Exadataストレージ・サーバー・ソフトウェア
Exadata InfiniBandスイッチ・ソフトウェア
特定の更新順序が必要になる例外があります。これは、更新するバージョンのExadataソフトウェアの補足READMEに記載されています。 必須の更新順序の例をいくつか示します。
Oracle ASM Cluster File System (Oracle ACFS)が構成されているシステムを更新する場合は、データベース・サーバー(非Oracle VMまたはOracle VM)をExadataソフトウェア・リリース12.2に更新する前に、Grid Infrastructureホームにバグ22810422に対する修正を含める必要があります。
Oracle VM構成をExadataソフトウェア・リリース12.1からExadataソフトウェア・リリース12.2に更新する場合、dom0をExadataソフトウェア・リリース12.2に更新する前に、すべてのdomUをExadataソフトウェア・リリース12.2に更新する必要があります。
Oracle VM構成を更新する場合、domUをExadataソフトウェア・リリース12.2に更新する前に、domUのGrid Infrastructureホームは、プロアクティブ・バンドル・パッチ・リリース12.1.0.2.161018 (2016年10月)以降を実行している必要があります。
一般に、ソフトウェア更新順序の要件が発生するのは、1つ以上のコンポーネントを新機能を含む新しいバージョンに更新する場合です(たとえば、Exadataソフトウェアをリリース12.1からリリース12.2に更新する場合など)。詳細は、更新するソフトウェア・バージョンのExadataソフトウェアの補足READMEを参照してください。
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)のみでリリースを参照することで十分です。
特定のターゲット・バージョンへのアップグレードでは、patchmgrによって施行される次のルールに従う必要があります。
ターゲット・リリースの製品バージョンがインストール済ソフトウェアよりも大きい
かつ
ターゲット・リリースの日付コードがインストール済ソフトウェアよりも大きい必要があります。
たとえば、製品バージョン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よりも大きいため、許可されません。
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ホーム・バイナリの再リンク
既知の問題の更新されたベスト・プラクティス構成の変更および回避策の適用
ストレージ・サーバーおよびInfiniBandスイッチの更新では、更新対象のExadataソフトウェア・リリースにバンドルされているバージョンのpatchmgrを使用します。
データベース・サーバーの更新では、My Oracle Supportのパッチ21634633からpatchmgrを使用します。 Exadataデータベース・サーバーを更新する際には、常にMy Oracle Supportのパッチ21634633から最新のpatchmgrを使用することをお薦めします。
前提条件
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に置き換えられています。
例
例5-4 ストレージ・サーバー更新の前提条件チェックの実行後のストレージ・サーバーの更新
./patchmgr -cells cell_group -patch_check_prereq ./patchmgr -cells cell_group -patch
例5-5 ローリング形式でのストレージ・サーバーの更新
次のコマンドは、ストレージ・サーバーをローリング形式で更新し、更新が進むと電子メール通知を受信し、更新が完了した後にセルへのパスワードなしのSSHアクセスを削除します。
./patchmgr -cells cell_group -patch -rolling -unkey -smtp_from "dbm01@example.com" -smtp_to "admin1@example.com,admin2@example.com"
例5-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オプションを使用してロギング・ディレクトリを取得します。次に例を示します。
最初のpatchmgrの実行のロギング・ディレクトリは、自動的に生成されます。
./patchmgr -cells cell_group -patch -log_dir auto
最後のセルが更新に失敗し、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
最後のセルのみを含むようにcell_groupファイルを更新するか、最後のセルのみを含む別のファイルを使用します。 最初のpatchmgrの実行からロギング・ディレクトリを指定すると、このセルのグループのすべてのログが同じロギング・ディレクトリに作成されます。
./patchmgr -cells cell_group -patch -log_dir /tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee
例5-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
関連トピック
この項では、Exadataコンポーネントへのソフトウェア更新を実行するために必要な、高度なアクションについて説明します。
Exadata Database Machine上のソフトウェアの更新を実行するには、次のアクションを実行する必要があります。
ターゲット・リリースを特定する - ターゲット・リリースは、次のいずれかによって決定されます。
My Oracle Supportのドキュメント888828.1の推奨事項。
Oracle ExaCHKレポートの「MAAスコアカード」セクションのバージョン推奨。
Oracle ExaCHKを実行する - Oracle ExaCHKの最新バージョンを実行して、システムのソフトウェア・メンテナンス準備状況を確実にします(My Oracle Supportのドキュメント 1070954.1を参照してください)。 レポートで、次の点を確認します。
ベースラインから逸脱したFAILまたはWARNINGチェックを修正します。
「MAAスコアカード」セクションでバージョン推奨を確認します。 Oracle ExaCHKは、現在のソフトウェア・バージョンの一貫性、互換性、および最新であるかどうかを評価します。
「MAAスコアカード」セクションで重大な問題が発生しているかどうか確認します。 ターゲット・バージョンの選択によって、重大な問題の発生が解決されます。
次のタイミングでOracle ExaCHKの最新バージョンを実行することをお薦めします。
毎月(Exadataのベスト・プラクティスに従っているシステムを維持するため)
メンテナンス準備状況を確実にするためのソフトウェア更新の1週間前
メンテナンス準備状況を確実にするためのソフトウェア更新の前日
ソフトウェア更新が完了した直後
前提条件チェックを実行する -
My Oracle Supportから、ターゲット・ソフトウェア・リリースおよびソフトウェア更新ユーティリティ(patchmgr、OPatchなど)の最新バージョンをダウンロードします。
前提条件チェックを実行し、問題を修正します。 初期の前提条件チェックの実行は、問題を修正するための時間を確保するために、メンテナンス・ウィンドウの数日または数週間前に実行する必要があります。更新の直前に、前提条件チェックを再度実行します。
注意:
データベース・サーバーの前提条件チェックおよび-nomodify_at_prereqフラグの実行には、特別な考慮が必要です。 詳細は、「Exadataデータベース・サーバーの更新」を参照してください。最新ドキュメントを確認する -
Oracle ExaCHKによってまだ自動的にチェックされていない、最近公開された重大な問題については、My Oracle Supportのドキュメント1270094.1を確認してください。
ソフトウェアがリリースされた後に検出された既知の問題のターゲット・ソフトウェア・バージョンについては、My Oracle Supportの補足READMEを確認してください。
Exadataストレージ・サーバーを更新するプロセスの概要を示します。
Patchmgrは、ストレージ・サーバーのローリング形式または非ローリング形式での更新オーケストレーションを管理します。 -rollingオプションを使用する場合は、Oracle ASM高冗長性ディスク・グループを使用して、更新中に別のストレージ・サーバーでのディスクの障害に耐えるようにすることをお薦めします。
My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。 My Oracle Supportのドキュメント888828.1を参照してください。
更新するストレージ・サーバーのリストを含むファイルを作成します。このファイルは、component_list_fileとして指定されます。
component_list_file内のすべてのストレージ・サーバー上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。
patchmgr前提条件チェックを実行し、問題を修正します。
ストレージ・サーバーが非ローリングで更新される場合は、Oracle Clusterwareおよびストレージ・サーバーにアクセスするすべてのデータベースを停止します。
patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でストレージ・サーバーを更新します。
ストレージ・サーバーが非ローリングで更新された場合は、Oracle Clusterwareおよびすべてのデータベースを再起動します。
関連トピック
Exadataデータベース・サーバーを更新する場合、仮想化環境には別の手順があります。
注意:
Patchmgrは、Exadataデータベース・サーバーのローリング形式または非ローリング形式での更新オーケストレーションを管理します。-rollingオプションを使用する場合、クライアントの高可用性のためのOracle RACの機能を使用して、メンテナンス時に停止するデータベース・インスタンスに接続されたクライアント・アプリケーションへの影響を最小限に抑えることをお薦めします。 Oracle VMが構成されていないExadataデータベース・サーバーの更新に関連する手順の概要です。
My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。
My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。 My Oracle Supportのドキュメント888828.1を参照してください。
更新するデータベース・サーバーのリストを含むcomponent_list_fileを作成します。
component_list_file内のすべてのデータベース・サーバー上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。
patchmgrバックアップを実行して、データベース・サーバーのルート・ファイル・システムおよびオペレーティング・システムをバックアップします。
patchmgr前提条件チェックを実行し、問題を修正します。
patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーを更新します。
個別に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)の更新
My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。
My Oracle SupportからターゲットのdomU Exadataソフトウェアをダウンロードし、それを駆動システム上で実行します。 My Oracle Supportのドキュメント888828.1を参照してください。
更新するデータベース・サーバーdomUのリストを含むcomponent_list_fileを作成します。
component_list_file内のすべてのデータベース・サーバーdomU上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。
patchmgrバックアップを実行して、データベース・サーバーdomUのルート・ファイル・システムおよびオペレーティング・システムをバックアップします。
patchmgr前提条件チェックを実行し、問題を修正します。
patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーdomUを更新します。
Patchmgrは、InfiniBandスイッチのローリング形式での更新オーケストレーションを管理します
My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。 My Oracle Supportのドキュメント888828.1を参照してください。
更新するInfiniBandスイッチのリストを含むcomponent_list_fileを作成します。
component_list_file内のすべてのInfiniBandスイッチ上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。
patchmgr前提条件チェックを実行し、問題を修正します。
InfiniBandスイッチを更新するpatchmgrを実行します。 InfiniBandスイッチは、常にローリング形式で更新します。
Oracle Grid InfrastructureまたはOracle Databaseソフトウェアを更新する手順は、実行しているソフトウェア更新のタイプによって異なります。
新しいプロアクティブ・バンドル・パッチへの更新
新しいプロアクティブ・バンドル・パッチへの更新は、インプレースまたはアウトオブプレースで実行できます。インプレースとアウトオブプレースの両方の方法で、ローリング更新と非ローリング更新がサポートされています。
インプレース
Oracle Grid InfrastructureまたはOracle Databaseソフトウェアが更新中のノードで停止している間に、OPatchを使用して現在のソフトウェア・ホームに更新が適用されます。
これは、プロアクティブ・バンドル・パッチのREADMEに記載されているように、Oracle Grid InfrastructureまたはOracle Databaseソフトウェアにプロアクティブ・バンドル・パッチ更新を適用するデフォルトの方法です。プロアクティブ・バンドル・パッチを適用する手順は、各ノードで実行する必要があります。
アウトオブプレース(推奨)
Grid Infrastructureおよび/またはDatabaseソフトウェアの実行中に、新しいソフトウェア・ホームが準備され、更新されます。新しいホームが準備されると、Grid Infrastructureおよび/またはDatabaseはすばやく停止し、新しいホームに切り替えられ、再起動されます。
アウトオブプレースは、インプレース更新より次のような大きな利点があります。
Grid Infrastructureおよび/またはDatabaseソフトウェアがオンライン中に新しいホームを準備できるため、リスクは低くなります。
新しいソフトウェア・ホームへの切替えは、インプレースの更新を適用するよりも速いため、停止時間は短くなります。
元のソフトウェア・ホームに簡単に戻すことができるため、ロールバックが高速になります。
アウトオブプレース更新を導入するための推奨方法は、Oracle Rapid Home Provisioning (RHP)を使用することです。RHPには次の利点があります。
クラスタ内のすべてのノードにソフトウェア更新を配布します。
1つのコマンドを使用して、ローリング形式または非ローリング形式でクラスタ全体の更新をオーケストレートします。
アプリケーションの可用性を維持するために、データベース・サービスの再配置を制御します。
アウトオブプレースのソフトウェア更新は、Enterprise Manager Cloud Controlでもサポートされています。
RHPまたはEMなしでのアウトオブプレースのソフトウェア更新は、My Oracle Supportのドキュメント2087150.1に従って行うことができます。
OJVMパッチ・セット更新
OJVMパッチ・セット更新(PSU)は、OJVMのセキュリティ脆弱性に対処するデータベース・ホーム用の個別のソフトウェア更新です。 これは、標準プロアクティブ・バンドル・パッチとは別にインストールされます。 OJVM PSUパッチは、特定の状況でOracle RACローリング形式でインストールできます。
新しいパッチ・セット・リリース、メジャー・リリースまたはメンテナンス・リリースへの更新
Grid InfrastructureまたはDatabaseの上位パッチ・セット、メンテナンスまたはメジャー・リリースに更新するには、My Oracle Supportの手順を追った説明に従ってください。
12.2.0.1への更新 - Exadata Database Machine用の12.2.0.1 Grid InfrastructureおよびDatabaseへのアップグレード(My Oracle Supportのドキュメント2111010.1)
12.1.0.2への更新 - Exadata Database Machine用の12.1.0.2 Grid InfrastructureおよびDatabaseへのアップグレード(My Oracle Supportのドキュメント1681467.1)
11.2.0.4への更新 - Exadata Database Machine用の11.2.0.4 Grid InfrastructureおよびDatabaseへのアップグレード(My Oracle Supportのドキュメント1565291.1およびMy Oracle Supportのドキュメント1555036.1)
関連トピック
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データベース・サーバーをパラレルに更新できます。非ローリング更新では、データベースの完全停止と引き換えに所要時間全体が短縮されます。
関連トピック
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以上に更新し、その後、更新ユーティリティを使用する必要があります。詳細は次の表を参照してください。
表5-1 更新パス
| 現時点でインストールされているOracle Exadataソフトウェア・リリース | 現在インストールされているOracle Linuxリリース | 推奨アクション |
|---|---|---|
リリース11.2.2.4.2以上 |
リリース5.5以上 |
更新ユーティリティを使用してターゲット・リリースに更新します。 |
リリース11.2.2.4.2より前 |
リリース5.5以上 |
|
リリース11.2.2.4.2より前 |
リリース5.5より前 |
|
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の詳細は、前提条件チェックの実行を参照してください。
次の表では、Exadataデータベース・サーバーのカスタマイズに伴うリスクに関するいくつかのガイドを示します。前提条件チェックではほとんどのカスタマイズについてチェックしますが、構成変更の中には、データベース・サーバーを更新できるようにするために、ロールバックする必要があるものがあります。引き続き必要となるものについては、更新処理後にリストアできます。
表5-2 カスタマイズとそのリスク
| 項目 | カスタマイズ・レベル | リスク |
|---|---|---|
デフォルト指定のエンジニアド・システム・ソフトウェア・スタック |
なし |
なし |
システム・ユーザー(root/oracle)のインタラクティブ・シェル・プロファイルの設定 |
低 |
高 |
VGExaDbのすべての空き領域の使用 |
低 |
低 |
追加の(Exadata以外の) rpmパッケージのインストール |
中 |
低 |
様々なマウント・ポイントがあるファイル・システムのカスタマイズ |
中 |
低 |
現在のExadataイメージに付属のパッケージの更新 |
中 |
低 |
構成ファイルのカスタマイズ、基本的なオペレーティング・システム機能の変更 |
高 |
中 |
追加の(Exadata以外の) rpm以外のパッケージのインストール |
高 |
中 |
LVMレイアウトの変更 |
高 |
高 |
patchmgrは、Oracle Exadataデータベース・サーバーを更新するための更新ユーティリティです。
リリース12.2.1.1.0 (Exadata x86_64の場合)および12.1.2.4.0 (Exadata SPARCの場合)以降、Exadataデータベース・サーバーのExadataソフトウェア更新はpatchmgrユーティリティによってのみ適用できます。
注意:
Exadataデータベース・サーバーを更新するためのpatchmgrユーティリティは、Exadataソフトウェア更新に付属のpatchmgrスクリプトとは異なります。
データベース・サーバー用のpatchmgrは、dbserver.patch.zipにパッケージされ、My Oracle Supportノート1553103.1から独立したダウンロードとして入手できます。このユーティリティは既知の問題およびベスト・プラクティスに対処し、新しいハードウェアをサポートするために頻繁に更新されるため、常に最新のリリースを使用してください。
ユーティリティは、すべての世代のハードウェア、11.2.3.1.0以降のExadataストレージ・サーバー・リリース、およびOracle Virtual Server (dom0)とExadata Virtual Machines (domU)を実行しているOracle Exadataデータベース・サーバーをサポートしています。Oracle Exadataソフトウェア更新のREADMEファイルには、更新自体が特定の世代のハードウェアに適用可能かどうかが記載されています。READMEは、dbserver.patch.zipに付属していませんが、Oracle Exadataソフトウェア更新のzipファイルには付属しています。
ユーティリティは、Oracle Linux 5からOracle Linux 6へのExadataソフトウェア更新もサポートしています。
ユーティリティでは、オーケストレーションに対処します。更新は、1つまたは複数のExadataデータベース・サーバーを対象にローリング方式または非ローリング方式で実行できます。
更新ユーティリティは、次のタスクを実行します。
次のような、準備、更新、検証のすべての手順を自動化します。
データベース、Grid InfrastructureスタックまたはdomUの停止
Oracle Enterprise Manager Cloud Controlエージェントの停止
リモート・ネットワーク・マウントのアンマウント(必要な場合)
Exadataデータベース・サーバーを更新する前に、組込みのdbserver_backup.shスクリプトを使用して、オペレーティング・システムをホストするファイル・システムのバックアップを実行します。
Oracleベスト・プラクティスおよび最新の既知の問題に対する修正を適用します。
更新が成功したことを確認し、Oracleバイナリを再リンクして、OracleスタックおよびdomUを起動します。
すべてのExadataデータベース・サーバーを一度に更新することを計画している場合は、更新対象のExadataデータベース・サーバーのグループ外にあるLinuxノードから更新ユーティリティを実行することが要件になります。これは、更新ユーティリティではその実行元のExadataデータベース・サーバーを更新できないためです。他にOracle LinuxまたはOracle Solarisを実行しているシステムがない場合には、Exadataデータベース・サーバーのいずれかから更新ユーティリティを実行できます。このような場合は、指定したdbs_groupファイルに、更新ユーティリティを実行するExadataデータベース・サーバーがリストされていないことを確認してください。
更新対象のすべてのExadataデータベース・サーバーのrootユーザーに対して、駆動ノードからrootユーザーのSSH等価を設定する必要があります。
関連トピック
デフォルトでは、更新ユーティリティは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
関連トピック
Exadataデータベース・サーバーの更新には、次のタイムラインをお薦めします。このアプローチに従うことによって、必要な是正処置を実行するための時間を確保できます。
注意:
前提条件チェックなどの変更を加える前に、バックアップを作成してください。
表5-3 更新を実行するためのタイムライン
| いつ | タスク |
|---|---|
更新までの数週間から数日前 |
|
更新直前 |
|
更新時 |
|
更新後 |
|
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データベース・サーバーを更新します。
Oracle Exadataソフトウェア更新を保持しているOracle Exadataチャンネルは、My Oracle Supportからダウンロード可能なイメージ(圧縮ISOファイル)として入手でき、次の2つの方法で使用できます。
-iso_repoフラグを使用して、更新ユーティリティの引数として圧縮ファイルの場所を使用します。
HTTPを使用して公開し、-yum_repoフラグを使用してURLを更新ユーティリティで使用します。
圧縮ファイルの場所は更新ユーティリティに直接渡すことができ、これは次の場合にお薦めします。
リポジトリYUM HTTPサーバーとして使用可能な別のサーバーが存在しない。
追加ULNチャンネルからの更新を必要とするカスタマイズされたソフトウェアが、Exadataデータベース・サーバーに存在しない。
簡略化されたメソッドが推奨される。
注意:
圧縮ISOイメージは、更新ユーティリティを実行しているノード上にのみ存在する必要があります。圧縮ISOイメージの配信は、更新ユーティリティによって処理されます。
前提条件チェックを実行(-precheck)して、リポジトリが使用可能であることを検証できます。
このメソッドは、次の条件が満たされた場合に推奨されます。
更新する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以上が実行されている必要があります。
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以外のデータベース・サーバー)を使用することをお薦めします。
次のコマンドを使用して、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
圧縮ISOイメージをWebサーバーの/u01/app/oracle/stageにコピーします。
次のコマンドを使用して、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
rootユーザーとして、httpdサービスを開始します。これは、httpdがインストール済であることを前提としています。
[root@nonExadataHost ]# service httpd start
Webブラウザを使用して、接続したYUM HTTPリポジトリを識別してテストします。リポジトリURLの例を、次に示します。
http://yum-repo/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base/x86_64/
rootユーザーとして前提条件チェックを実行して、リポジトリが正しく設定されていることを検証します。前提条件チェックの実行を参照してください。
リリース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ファイル内にリストされたパッケージは更新中に削除されません。
セキュリティの確保やカスタマイズのために、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コマンドを使用しないでください。
実際の更新を行う前に、常に、前提条件チェックを実行する必要があります。前提条件チェックでは停止時間は必要なく、次のような重要な検証を実行します。
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
次のリリースに更新するときは、変更を加える前に、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 "sender@somedomain.com" -smtp_to "recipient@example.com"
ローリング方式(-rollingフラグを使用)または非ローリング方式で、Exadataデータベース・サーバーの実際の更新を実行できます。デフォルトは非ローリング方式です。
また、root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行の説明に従って、更新はrootとしてもroot以外のユーザーとしても(-log_dirフラグを使用)実行できます。
更新は、Minimum依存性チェックが成功した場合にのみ続行します。更新を続行するために、カスタマイズを削除することが必要になる場合があります。
デフォルトでは、更新によって、非アクティブなシステム・イメージにバックアップが作成されます。-nomodify_at_prereqフラグを使用しないで前提条件チェックの実行前にすでにバックアップを作成している場合には、更新を実行するときに–nobackupフラグを使用してバックアップをスキップできます。
注意:
-nobackupフラグを使用するのは、前提条件チェックの実行前に、-nomodify_at_prereqフラグを指定しないですでにバックアップを作成していた場合のみとしてください。
更新アクションには、次のフラグが必要です。
-upgrade。更新アクションを指定します。
-iso_repo (ISOイメージの場合)または-yum_repo (HTTPの場所の場合)。YUMリポジトリを指します(例5-9を参照)
-target_version。更新先のリリースを指定します。パッチのREADMEには、常に、この情報が含まれています。
バックアップ中および更新中のアクティブなリモート・ネットワーク・マウントを許可する追加のフラグ(-allow_active_network_mounts)を指定し、更新ステータス通知用の電子メールの受信者(-smtp_from"addr"および-smtp_to"addr1 addr2 addr3...")を指定できます
例5-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 "sender@somedomain.com" -smtp_to "receiver@somedomain.com" -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 "sender@somedomain.com" -smtp_to "receiver@somedomain.com" -nobackup
例5-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 "sender@somedomain.com" -smtp_to "receiver@somedomain.com" -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 "sender@somedomain.com" -smtp_to "receiver@somedomain.com" –nobackup
バックアップを使用すると、更新の成否に関係なく、更新をロールバックできます。このバックアップは、計画メンテナンスの前のExadataデータベース・サーバーのバックアップで説明しているように、非アクティブなシステム・パーティションに格納されています。
更新をロールバックするとき、更新ユーティリティでは次のアクションを実行します。
スタックおよびdomUを停止します。
アクティブなパーティションを非アクティブ化し、非アクティブなパーティションをアクティブ化します。
非アクティブなパーティションから/bootをリストアします。
GRUBブート・ローダーを更新します。
非アクティブなシステム・パーティションを1つのみ保持することで、ロールバック・オプションが前回のアクティブ・イメージのみに制限されます。
例5-10 ロールバックの実行
[root@dm01 ]# ./patchmgr -dbnodes dbs_group -rollback -target_version 12.1.2.3.0.160207
-dbnodesには、更新するデータベース・ノードのリストを指定します。
-rollbackには、ロールバック・アクションを指定します。
-target_versionには、ロールバック先のターゲット・リリースを指定します。
その他のオプションは、更新ユーティリティに組込みのヘルプを参照してください。
注意:
以前のイメージにロールバックするときには、ファームウェア更新はロールバックされません。ロールバックした後、必要に応じて、次のコマンドを実行し、より古いバージョンのファームウェアを適用します。
/etc/init.d/lsidiag stop /etc/init.d/lsi_mrdsnmpd stop /opt/oracle.cellos/CheckHWnFWProfile -action updatefw -mode exact
最後のコマンドは、リリース11.2.3.3.0以上にのみ適用されます。
更新ユーティリティによって生成されるログ・ファイルを使用して、更新をトラブルシューティングできます。
更新ユーティリティは、Exadataデータベース・サーバーの更新をオーケストレートします。ログ・ファイル(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更新よりも前に更新アクションが失敗した場合は、エラーを解決した後で更新を再試行できます。更新が途中で中断した場合は、ロールバックし、エラーを解決してから再試行することをお薦めします。
Exadataストレージ・サーバー・リリース更新には、Exadataストレージ・サーバー内の次のコンポーネントに対する更新が含まれています。
Oracle Linuxオペレーティング・システム
ファームウェア(フラッシュ、ディスク、RAIDコントローラ、ILOM、HCA)
Exadataソフトウェア
更新されるソフトウェアおよびファームウェアは、ストレージ・サーバーに適用された現在のExadataソフトウェア・リリースおよび更新先のリリースによって異なります。Linuxオペレーティング・システム・パッケージおよびExadataソフトウェアは常に更新されるのに対して、ファームウェア更新は選択した少数のコンポーネントに対してのみ適用されることや、まったく適用されないことがあります。
Exadataストレージ・サーバーに対する更新は、特に指定されている場合を除き、Exadataデータベース・サーバーまたはInfiniBandスイッチへの更新とは関係なく適用できます。リリースされるすべてのExadataソフトウェア更新を個別に適用することが必要になるわけではありません。たとえば、リリースを2つか3つスキップして、より新しいリリースに直接更新できます。
Exadataストレージ・サーバーの更新は、常にアウトオブプレースで実行されます。つまり、Exadataストレージ・サーバー・ソフトウェアを含む新規バージョンのオペレーティング・システムは、非アクティブなシステム・パーティションにインストールされます。Exadataソフトウェアを更新するためのユーティリティは、更新自体に付属しています。
クラスタ全体の停止時間が許容されない場合は、ローリング方式でストレージ・サーバーを更新できます。ローリングとは、一度に1つのExadataストレージ・サーバーを更新することです。クラスタ全体の停止時間が許容される場合は、すべてのExadataストレージ・サーバーをパラレルに更新できます。非ローリング更新では、所要時間全体が短縮されます。
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
注意:
Exadata更新を本番システムで実行する前に、テスト・システムで検証することをお薦めします。
次のアプローチに従うと、必要な是正処置を実行するための時間を確保できます。
表5-4 更新を実行するためのタイムライン
| いつ | タスク |
|---|---|
更新までの数週間から数日前 |
|
更新時 |
|
更新後 |
|
Exadataストレージ・サーバーを更新する前に、次の準備手順を実行します。
更新(およびロールバック)アクションは、ローリング方式または非ローリング方式で実行できます。また、前提条件チェックもローリング方式または非ローリング方式で実行できます。デフォルトは非ローリング方式です。
更新ユーティリティを駆動するユーザーに対してSSH等価を設定します。
Oracle ExaCHKをダウンロードして実行します。未解決の問題がある場合は、確認して対処します。My Oracle Supportノート1070954.1を参照してください。
リリース固有のMy Oracle Supportノートで既知の問題および回避策を確認します。
更新またはロールバックの方式に対して前提条件をチェックします。
ローリング更新を実行するための前提条件:
My Oracle Supportノート888828.1の記載に従って、Grid InfrastructureホームおよびDatabaseホームのソフトウェア・バージョンとパッチ・レベルがExadataストレージ・サーバー・ローリング・セル更新の最小要件を満たしていることを検証します。
それぞれの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修復タイマーがデフォルト値よりも低い場合には、修復タイマーを更新期間のデフォルト値に設定してください。すべてのストレージ・サーバーの更新が正常に完了した後で、現在値に戻してもかまいません。
非ローリング更新を実行するための前提条件:
次のコマンドを使用して、各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
次のコマンドを使用して、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の状態を確認する必要があります。
更新するすべてのストレージ・サーバー上にあるすべてのセル・サービスを停止します。このことを行うには、rootユーザーが、各セルに対してcellcli -e 'alter cell shutdown services all'を実行するか、または、次のdcliコマンドを実行して、すべてのセルを同時に処理します。
[root@dm01 ]# dcli -g cell_group -l root "cellcli -e alter cell shutdown services all"
システムが次の条件を満たしているかどうかをチェックします。
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の指示に従ってください。
更新を解凍します。patch_release.date_codeディレクトリに抽出されます。このパッチ・ディレクトリに移動します。
ターゲット・リリースのMy Oracle Supportノートに添付されているpatchmgrプラグインをダウンロードし、My Oracle Supportノートの記載に従ってインストールします。実際に更新の適用を開始する直前に、リリース・ノートに記載されているMy Oracle Supportノート、問題および回避策を確認することをお薦めします。
-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
前提条件チェックを実行します。
Exadataデータベース・サーバーからrootユーザーとしてローリング更新の前提条件チェックを実行している例:
[root@dm01 ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -rolling -smtp_from "sender@example.com" -smtp_to receiver@example.com
Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング更新の前提条件チェックを実行している例:
[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch_check_prereq -smtp_from "sender@example.com" -smtp_to "receiver@example.com"
関連トピック
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 "sender@somedomain.com" -smtp_to receiver@somedomain.com
Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング方式で更新を実行するには、次のようにします。
[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch -smtp_from "sender@somedomain.com" -smtp_to "receiver@somedomain.com"
更新の完了後、-cleanupオプションを使用してストレージ・サーバーをクリーン・アップし、すべての一時的な更新ファイルまたはロールバック・ファイルをクリーン・アップします。このオプションでは、失効した更新状態とロールバック状態をクリーン・アップし、ストレージ・サーバー上で最大1.5GBのディスク領域をクリーン・アップします。このオプションは、更新ユーティリティの停止した実行または失敗した実行を再試行する前に使用してください。詳細は、手順8を参照してください。
更新したExadataストレージ・サーバーをロールバックできるのは、それが正常に更新されている場合のみです。つまり、imageinfoコマンドがアクティブ・イメージ・ステータスにsuccessを返す必要があります。更新が不完全か失敗したストレージ・サーバーはロールバックできません。ロールバックは、ローリング方式または非ローリング方式で行うことができます。
次のコマンドで、ストレージ・サーバーがロールバックされるバージョンおよび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以上にロールバックされるストレージ・サーバーは、現在設定されているフラッシュ・キャッシュ・モードを保持します。
次のコマンドを使用して、ロールバックの前提条件をチェックします。
[root@dm01 ]# ./patchmgr -cells cell_group -rollback_check_prereq [-rolling]
ロールバックを実行します。
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
-cleanupオプションを使用してExadataストレージ・サーバーをクリーン・アップし、すべての一時的な更新ファイルまたはロールバック・ファイルをクリーン・アップします。このオプションでは、失効した更新状態とロールバック状態をクリーン・アップし、Exadataストレージ・サーバー上で最大1.5GBのディスク領域をクリーン・アップします。このオプションは、patchmgrユーティリティの停止した実行または失敗した実行を再試行する前に使用してください。
[root@dm01 ]# ./patchmgr -cells cell_group -cleanup
更新対象の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
関連トピック
InfiniBandスイッチを更新およびダウングレードするには、ストレージ・サーバー更新に付属している同じ更新ユーティリティを使用します。更新ユーティリティを使用できる最小スイッチ・ファームウェア・リリースは1.3.3-2です。スイッチのファームウェアは、常にローリング形式で更新します。
注意:
InfiniBandスイッチ・ファームウェアの更新に使用されるpatchmgrは、Exadataデータベース・サーバー・ソフトウェア更新に使用されるものとは異なります。
ラックにスパイン・スイッチが存在する場合は、それを最初に更新する必要があります。ラックにスパイン・スイッチが存在しない場合は、まずサブネット・マネージャが実行されているスイッチを更新します。スイッチでサブネット・マネージャが実行されていない場合は、任意の順序で更新を実行できます。
InfiniBandスイッチを更新するには、スイッチのファームウェアがリリース1.3.3-2以上である必要があります。スイッチのファームウェアがそれより前のリリースである場合は、My Oracle Supportノート888828.1の説明に従って、ファームウェアをリリース1.3.3-2に更新します。InfiniBandスイッチが実行しているソフトウェアのバージョンを特定するには、versionコマンドを使用します。
rootユーザーによるスイッチへのSSHアクセスが可能なExadataデータベース・サーバーにrootユーザーとしてログインします。データベース・サーバーは、スイッチと同じInfiniBandネットワークに属している必要があります。
スイッチのバージョンを特定します。
[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
データベース・サーバーに適切なパッチ・ファイルをダウンロードします。パッチ情報は、My Oracle Supportノート888828.1を参照してください。
更新を解凍します。ファイルは、patch_release.date>ディレクトリに解凍されます。
ファイルを作成し、更新する必要があるすべてのInfiniBandスイッチを1行に1スイッチずつリストします。ラック内のスイッチを識別するには、ibswitchesコマンドを使用します。他のExadata以外のエンジニアド・システムからのスイッチが同じファブリックに表示される場合がありますが、現時点では更新する必要がない可能性もあることに注意してください。次に、ibswitchesを実行した後に作成されるファイルの例を示します。
[root@dm01 ]# cat ibswitches.lst myibswitch-01 myibswitch-02
注意:
ファイル名を指定しない場合、コマンドの実行対象は、ibswitchesコマンドを実行することによってこのホストから検出されたすべてのInfiniBandスイッチとなります。
<patch_release.date>ディレクトリに移動します。
前提条件チェックを実行します。
[root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -upgrade -ibswitch_precheck [-force] [-unkey]
注意:
-unkeyオプションは、終了する前に、InfiniBandスイッチへのパスワードなしのSSHアクセスを削除します。
-forceオプションを指定すると、InfiniBandトポロジの障害とサーバーからスイッチへの接続がオーバーライドされます。スイッチのアップグレードには影響しません。
コマンドの出力で全体的なステータスがSUCCESSになった場合は、アップグレードに進みます。コマンドの出力で全体的なステータスがFAILになった場合は、出力でエラーのサマリーを確認し、どのチェックが失敗したかを特定して、エラーを修正します。すべてのエラーを修正した後、前提条件チェックを再実行し、成功するまでこれを繰り返します。
次のコマンドを使用して、スイッチを更新します。
[root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -upgrade [-force] [-unkey]
ファームウェアをダウングレードすると、Exadataストレージ・サーバー更新に付属している、より古いファームウェア更新が再適用されます。つまり、ストレージ・サーバー更新にはどのリリースにダウングレードできるかが定義されています。これはリリースごとに異なることがあり、更新前に使用していたファームウェアではない場合があります。更新先のリリースに付属している、より古いファームウェアの詳細は、パッチのREADMEを参照してください。
InfiniBandスイッチ・ファームウェアをダウングレードするコマンドの例:
[root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -downgrade -ibswitch_precheck [-force] [-unkey] [root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -downgrade [-force] [-unkey]
Exadata Database Machine上でソフトウェアを更新する前に、SSH等価を構成する必要があります。
Oracle LinuxまたはOracle Solarisを実行している任意のサーバーからrootユーザーまたはroot以外のユーザーとしてExadataデータベース・サーバーおよびExadataストレージ・サーバーのExadata更新ユーティリティを実行できます。ターゲットのExadataサーバーのrootユーザーに対してSSH等価が設定されているかぎり、ユーティリティでは任意のExadataサーバーで前提条件チェック、更新、ロールバックの各アクションを実行できます。
注意:
安全な環境を構築しているお客様の場合、Exadataストレージ・サーバーへのSSHアクセスを無効にしていることがあります。通常の操作中に、Exadataストレージ・サーバーがSSHアクセスを必要とすることはありません。一方、更新ユーティリティなどの管理用ユーティリティでは、SSHアクセスを必要とします。ストレージ・サーバーのロック解除の詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドのストレージ・サーバーでのSSHの無効化 の項のサブセクション、セルの一時的なロック解除を参照してください。
カスタム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を削除した後、更新または前提条件チェックを再起動します。
関連トピック
アーキテクチャの異なるカスタム・パッケージがデータベース・サーバーにインストールされている場合は、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問題の解決策となります。
