| Oracle® Database 2日でReal Application Clustersガイド 12c リリース1 (12.1) B71293-05 |
|
 前 |
 次 |
Oracle Real Application Clusters(Oracle RAC)環境でOracleソフトウェアを管理し、パッチを適用するには、Oracle Universal InstallerまたはOPatchユーティリティを使用します。
参照:
ソフトウェアの管理およびパッチ・リリースの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
OPatchの最新バージョンを入手する方法の詳細は、Oracle OPatchユーザーズ・ガイドfor Windows and UNIXを参照してください
オラクル社では、オラクル社のソフトウェアについてパッチと呼ばれる製品フィックスを発行しています。パッチは特定のリリースおよびバージョンのOracle製品と関連付けられています。
パッチ適用サイクルでは、パッチをダウンロードして適用し、バグ修正がパッチに適切に反映されているかどうかを確認します。
パッチ適用では、特定のリリース内に、あるバージョンのソフトウェア製品を別のバージョンに移行します。これは、あるリリースの製品を別の新しいリリースのソフトウェア製品に移行するアップグレードとは異なります。インストール済のOracleソフトウェアにパッチを適用すると、そのソフトウェアのホーム・ディレクトリの実行可能ファイル、ライブラリおよびオブジェクト・ファイルが更新されます。パッチの適用によって、構成ファイルおよびオラクル社提供のSQLスキーマも更新できます。
Oracleソフトウェアで発生したバグを修正するために、次の種類のパッチが定期的にリリースされています。
| パッチ・タイプ | 説明 |
|---|---|
個別パッチ |
単一のバグまたはバグのコレクションを修正するためにリリースされました。以前はパッチ・セット例外(PSE)、個別パッチまたはホット・フィックスと呼ばれていました。 |
個別パッチ(セキュリティ・バグ修正用) |
顧客固有のセキュリティ修正を用意するためにリリースされました。以前はテスト・パッチ、修正検証バイナリまたはe-fixと呼ばれていました。 |
診断パッチ |
単一の修正またはバグ修正のコレクションの診断および検証を主に支援します。 |
バンドル・パッチ更新 |
特定の製品またはコンポーネントを対象とする修正の累積コレクション。以前はメンテナンス・パック、サービス・パック、累積パッチ、更新リリースまたはMLRと呼ばれていました。 |
パッチ・セット更新(PSU) |
重大な問題に対する十分にテスト済および証明済のバグ修正を含む累積パッチ・バンドル。PSUの新規内容には制限があり、再証明が必要な変更は含まれません。 |
セキュリティ・パッチ更新 |
セキュリティ・バグ修正の累積コレクション。以前はクリティカル・パッチ更新またはCPUと呼ばれていました。 |
個別パッチは、特定の不具合に対して顧客が使用できる不具合の修正です。個別パッチを適用するには、特定のベース・リリースまたはパッチ・セットがインストールされている必要があります。これらのパッチはバージョン管理されず、一般に将来のパッチ・セットおよび次の製品リリースで使用可能になります。個別パッチは、Oracle Databaseインストールに含まれているEnterprise Manager Cloud ControlまたはOPatchを使用して適用されます。
パッチ・セット更新(PSU)およびパッチ・バンドルは、完全なテスト済の統合された製品修正を配布するためのメカニズムです。パッチ・セット内のすべての修正が、テスト済で、互いに機能することが動作保証されています。パッチ・セットに低影響のパッチのみが含まれるため、更新したOracle Databaseソフトウェアに対してアプリケーションまたはツールを認定する必要はありません。パッチ・セットを適用すると、数多くの様々なファイルおよびユーティリティが変更されます。その結果、Oracle Database 11.2.0.3.0からOracle Database 11.2.0.3.2のように、Oracleソフトウェアのリリース番号が変わります。PSUを適用するにはOPatchを使用します。
Cloud Controlをそのプロビジョニングおよびパッチ適用機能と使用することで、Oracle Grid InfrastructureおよびOracle RACソフトウェアのパッチ適用を自動化できます。
Cloud Controlを使用してOracleソフトウェアにパッチを適用するには、最初に次のシステム構成タスクを実行する必要があります。
すべてのクラスタ・ノードへのEnterprise Manager Agentのインストール
パッチ適用タスクの完了に必要な権限をホスト・ユーザーが確実に保持するためのPDPセットアップの使用
Enterprise Managerでの指定および優先資格証明の構成
パッチ・ファイルを格納するためのソフトウェア・ライブラリの構成
このタスクの実行方法と、Cloud Controlを使用したOracle Grid InfrastructureおよびOracle RACソフトウェアのパッチ適用方法の詳細は、PDFファイル(http://www.oracle.com/technetwork/oem/pdf/512066.pdf)に記載されています。
この章の以降の項では、Cloud Controlを使用しないパッチのインストール方法について説明します。
パッチおよびパッチ・セットは、Oracle Support Services WebサイトにあるMy Oracle Supportから取得します。
Oracle Support ServicesのWebサイトはhttps://support.oracle.comにあります。
My Oracle Support Webサイトでパッチを検索するには、次の手順を実行します。
参照:
ソフトウェアの管理およびパッチ・リリースの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
Oracle RACデータベース(Oracle ASMインストール)またはOracle Clusterwareインストールにパッチを適用する前に、オペレーティング・システム環境を準備し、ローカルでパッチをステージングする必要があります。
PATHを更新して、OPatchディレクトリを含めることができます。 参照:
Oracle Databaseソフトウェアを最新の状態に保つ方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
Oracle OPatchユーザーズ・ガイドfor Windows and UNIX
OPatchでOracleホームが存在するかどうかが検証されます。
環境変数ORACLE_HOMEが、パッチを適用しようとしている製品のOracleホームに設定されている必要があります。また、パッチ適用対象のOracleホームと同じバージョン番号の、OPatchのバージョンを使用する必要があります。
環境変数の設定の詳細は、各ベンダーのマニュアルを参照してください。
Linuxで変数ORACLE_HOMEの現在の設定をチェックするには、次の手順を実行します。
パッチ操作を実行する前に、パッチを適用しているソフトウェア・ディレクトリをバックアップすることを強くお薦めします。Oracle DatabaseまたはOracle Grid Infrastructureソフトウェアのインストール・ディレクトリがこれに該当します。
ソフトウェアのインストールをバックアップするには、次の手順を実行します。
zip、cp -r、tarまたはcpioなどのオペレーティング・システム・ユーティリティを使用して、Oracleホーム・ディレクトリ内のソフトウェアをディスクにバックアップします。OPatchの実行中にopatch実行可能ファイルへのパスを指定するか、環境変数PATHを更新して、OPatchディレクトリを含めることができます。
opatchバイナリ・ファイルはOracle_home/OPatchディレクトリにあります。
Oracle LinuxシステムでPATH環境変数を更新するには、次の手順を実行します。
ユーザー等価は、各ノードのオペレーティング・システム・ユーザーが同一であると判断された場合に存在します。
ユーザー等価関係の構成の詳細は、「Linuxシステムのオペレーティング・システム・ユーザーおよびグループの構成」を参照してください。
オペレーティング・システムのSSHコマンドを使用して、ユーザー等価関係が有効であることを確認します。
参照:
SSHの構成方法は、ご使用のオペレーティング・システムのOracle Grid Infrastructureインストレーションおよびアップグレード・ガイドを参照してください。
Oracle RAC環境でのパッチの適用は、単一ノードへのパッチの適用とは若干異なります。OPatchでは、クラスタを検出すると、OUIを使用してソフトウェア・インベントリを問い合せ、ローカル・ノード名およびノード・リストを検索します。
パッチをインストールする前に、パッチ適用対象のソフトウェア・ディレクトリから実行されているすべてのアプリケーションを停止する必要があります。クラスタでは、パッチ適用対象のソフトウェアに応じて、他のアプリケーションの停止が必要になる場合があります。次の表では、Oracleソフトウェアをパッチする際に停止するアプリケーションを示しています。
表10-1 Oracleホーム・ディレクトリへのパッチの適用
| Oracleホーム・ディレクトリ | 停止するアプリケーション |
|---|---|
Oracle RACデータベース |
Oracle RACデータベース、Enterprise Manager Agent、リスナー、およびOracle RACのホーム・ディレクトリで実行されるその他のアプリケーション |
Oracle Grid Infrastructure |
Oracle RACデータベースとそのOracle RACホーム・ディレクトリから実行されるすべてのアプリケーション、クラスタ・データベースと同じOracle ASMインスタンスを使用する単一インスタンス・データベース、Oracle ASMインスタンス、すべてのノード・アプリケーション、Oracle Clusterware、およびGridホーム・ディレクトリから実行されるその他のアプリケーション |
参照:
Oracle Universal Installerインストレーション・ガイド
パッチの自動化の詳細は、Oracle OPatchユーザーズ・ガイドfor Windows and UNIXを参照してください
パッチの適用、またはGridホームのソフトウェア・ファイルへのその他の変更を行う前に、最初にGridホームのロックを解除する必要があります。
クラスタ用Oracle Grid Infrastructureにパッチを適用するには、次の2つの作業が必要です。
Gridホームのロックを解除します。
Gridホームにパッチを適用します。
Gridホームのロックを解除するには、次の手順を実行します。
すべてのノードへのパッチの適用では、まずクラスタ内のすべてのノードが停止されてから、すべてのノードにパッチが適用されます。
すべてのノードにパッチが適用された後、各ノードのOracle Clusterwareスタックおよび登録されているすべてのリソースが再起動されます。通常この方法は非常に重要なパッチの場合に使用され、停止時間は最大になります。OPatchは、パッチをローリング方式で適用できない場合、およびminimize_downtimeオプションを指定しなかった場合にこの方法を使用します。
ローリング方式でのパッチ適用では、1つのノード・グループが停止され、それらのノードにパッチが適用された後、再起動されます。
ローリング方式のパッチ適用は、クラスタ内のすべてのノードにパッチが適用されるまでグループごとに個々に行われます。Oracle RACまたはクラスタ用Oracle Grid Infrastructureインストールに個別パッチを適用する方法としては、これが最も効率的です。ノードのグループごとにパッチを適用することで、別のノードの1つ以上のインスタンスを常に使用できるため、クラスタ・データベースの停止時間はゼロになります。
ほとんどのパッチはローリング方式で適用できますが、一部のパッチはこの方法では適用できません。ローリング・パッチ方式でパッチを適用できるかどうかは、パッチのREADMEファイルに記載されています。ローリング・パッチ方式でパッチを適用できない場合、パッチを適用するときに、「最小停止時間でのパッチの適用」または「すべてのノードへのパッチの適用」を使用する必要があります。
最小停止時間でのパッチの適用では、パッチを適用するためにすべてのノードを停止する必要がある時間が短縮されます。
最小停止時間でのパッチの適用では、1つのセットのノードに対して、停止およびパッチの適用を順に実行します。最初のセットのノードにパッチを適用した後、2つ目のセットのノードを停止します。次に、最初のセットのノードを再起動し、2つ目のセットのノードにパッチを適用します。2つ目のセットのノードは、パッチの適用後に再起動します。この方法を使用した場合、同時にすべてのノードを停止する方法と比較すると、Oracle RACの停止時間が短くなります。
最小停止時間でのパッチの適用では、次のアクションが実行されます。
常に、ローカル・ノードに最初にパッチが適用されます。
ローカル・ノードは、他のノードにパッチを適用する場合のベースとして使用されます。
ユーザーは、残りのノードから最初にパッチを適用するノードのセットを入力するように求められます。
ユーザーは最初のセットの各ノードについて、インスタンスを停止するよう求められ、停止後にパッチがノードに伝播されてから、次のノードで処理が続行されます。最初のセットのノードにパッチが適用されると、ユーザーは残りのノードを停止するよう求められます。
ローカル・ノードにパッチが適用されると、パッチは最後のセットのノードに伝播され、インベントリが更新されます。最後のインスタンスがリモート・ノードで停止されます。ユーザーはこの時点で、残りのノードにパッチを適用する前に、パッチ適用済のノード(最初のノード・セット)を起動できます。
Oracle Linux上のOracle RACデータベースおよびOracle Clusterwareに最新のパッチ・セットを適用する方法は、My Oracle SupportのWebサイトで、Oracle 12cリリース1 (12.1)サポート・ステータスおよびアラートのドキュメントを検索してください。
このドキュメントはOracle 12cリリース1に使用可能なパッチ・セットの概要を提供します。このドキュメントを使用して、プラットフォームに合ったパッチ・セット・ノートを簡単に特定、確認できます。Oracle Databaseのパッチ・セット・ノートのドキュメントには次の情報が含まれています。
システム要件とパッチ・セットのインストールまたは再インストールの方法に関する情報
これまでに修正された特定のプラットフォーム用のOracle Database固有のバグをすべて網羅したリスト
特定のプラットフォーム用のOracle Databaseに関する既知の問題のリスト
My Oracle Supportでパッチ・セット・ノートを検索するには、次の手順を実行します。
Oracle RAC環境へのパッチ適用は複雑である場合があり、パッチのデプロイメントをトラブルシューティングする必要があることがあります。
Oracle RACデータベースへのパッチの適用で問題が発生した場合、一般的な問題であれば、上述のトピックで解決方法を確認できます。発生した問題が表示されない場合、ログおよびトレース・ファイルを確認して、My Oracle Supportを使用してヘルプを取得します。
適用、ロールバックおよびlsinventory操作のログが保持されます。 参照:
Oracle OPatchユーザーズ・ガイドfor Windows and UNIX
OPatchによって自動的にOracle RACまたはそのノードが検出されない場合は、インベントリの内容を調べ、その内容が完全であることを確認します。
OPatchのノード・リストを更新するには、次の手順を実行します。
参照:
ノード・リストの更新の詳細は、Oracle Universal Installerインストレーション・ガイドを参照してください。
ロギングとトレースは、デバッグのための一般的な支援機能です。OPatchでは、すべての適用、ロールバックおよびlsinventory操作のログが保持されます。
ログ・ファイルはOracle_home/cfgtoollogs/opatchディレクトリに配置されます。各ログ・ファイルには操作のタイム・スタンプが付加されます。ログ・ファイルの名前は、opatch_mm-dd-yyyy_hh-mm-ss.logの形式になり、ここで、mm-dd-yyyyは現在の日付を、hh-mm-ssは現在の時刻を表しています。OPatchを実行するたびに、新しいログ・ファイルが作成されます。
たとえば、ログ・ファイルが2015年5月17日の午後11時55分に作成された場合、ログ・ファイルの名前は次のようになります。
opatch_05-17-2015_23-55-00.log
OPatchでは、OPatchで実行されたコマンドの索引と、それに関連付けられているログ・ファイルもOracle_home/cfgtoollogs/opatchディレクトリのopatch_history.txtファイルに保持されます。opatch_history.txtファイルのサンプルを次に示します。
Date & Time : Tue Apr 26 23:00:55 PDT 2015 Oracle Home :/u01/app/oracle/product/12.1.0/dbhome_1OPatch Ver. : 12.1.0.0.0 Current Dir : /scratch/oui/OPatch Command : lsinventory Log File :/u01/app/oracle/product/12.1.0/dbhome_1/cfgtoollogs/opatch/opatch-2015_Apr_26_23-00-55-PDT_Tue.log
参照:
Oracle OPatchユーザーズ・ガイドfor Windows and UNIX
このエラーは、パッチの適用のためにOPatchユーティリティで使用されているディレクトリがOPatchユーティリティで確認されている内容のテンプレートと一致しない場合、またはOPatchユーティリティが無効なディレクトリから実行されている場合に発生する可能性があります。
Patch_Shiphomeディレクトリには、次の構造が存在する必要があります。
メタデータ・ファイルを含むetcサブディレクトリ
パッチ・ファイルを含むfilesサブディレクトリ
同じディレクトリ下のetc/config/inventory.xmlファイルおよびactions.xmlファイル
「有効なパッチ領域ではありません」エラーを解決するには、次の手順を実行します。
参照:
Oracle OPatchユーザーズ・ガイドfor Windows and UNIX
アップグレードは、新しいソフトウェア・リリースまたはバージョンのインストール時、またはパッチ・セットの適用時に実行されます。
アップグレードの場合、インストールされているOracleソフトウェア・ファイルのすべてではないがその大部分が変更されます。一方、パッチの場合は通常、ごく一部のファイルのみが変更されます。ローリング・アップグレードを実行することも、Oracle DatabaseおよびOracle Clusterwareソフトウェアを停止してアップグレードを実行することもできます。
ソフトウェアを新しいリリースにアップグレードする場合、アウトオブプレースのアップグレードを実行します。アウトオブプレース・アップグレードを実行するには、クラスタ用Oracle Grid Infrastructureを新しいGridホームにインストールします。アップグレードを実行する場合、既存のソフトウェアの場所を選択するかわりに、新しいGridホームの場所を指定します。
アウトオブプレース・アップグレードを実行する場合、旧バージョンと新バージョンのソフトウェアが同時にノードに存在することになり、各バージョンは別々のホームの場所にありますが、いつでもアクティブになるのは、1つのバージョンのソフトウェアのみです。Oracle Database 11gソフトウェアをOracle Database 12cリリース1 (12.1)にアップグレードするには、クラスタ用Oracle Grid InfrastructureおよびOracle Databaseを新しいOracleホーム・ディレクトリにインストールします。アップグレード・プロセスの最後に、クラスタ用Oracle Grid InfrastructureまたはOracle Database 12cリリース1 (12.1)ソフトウェアを使用するため、ソフトウェアのアクティブ・バージョンが変更されます。
Database Upgrade Assistant(DBUA)を使用すると、既存のデータベースを現在のリリースのOracle Databaseにアップグレードできます。Database Upgrade Assistant(DBUA)は、アップグレード・プロセスを順番に説明し、新しいリリース用にデータベースを構成します。DBUAはアップグレード処理を自動化し、表領域、オンラインREDOログ・ファイルなどの構成オプションの適切な推奨値を示します。
参照:
DBUAを使用したデータベースのアップグレードの詳細はOracle Database 2日でデータベース管理者を参照
ソフトウェア・アップグレードの実行の詳細は、ご使用のオペレーティング・システムのOracle Grid Infrastructureインストレーションおよびアップグレード・ガイドを参照してください。
Oracle Databaseアップグレード・ガイド
