| Oracle Database高可用性ベスト・プラクティス 11gリリース2(11.2) B65088-05 |
|
 前 |
 次 |
この章では、計画済の停止について説明します。また、各停止タイプを許容するか管理することで停止時間を最小化できるOracle運用ベスト・プラクティスについて説明します。
この章には、次の項目が含まれます。
計画済の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャの定期メンテナンスのために必要です。これには、次のタスクが含まれます。
ハードウェアのメンテナンス、修復およびアップグレード
ソフトウェアのアップグレードとパッチ適用
アプリケーションの(プログラム的な)変更、パッチおよびアップグレード
システムのパフォーマンスと管理性を向上するための変更
これらの作業の多くは、アプリケーションの可用性を連続的に維持したまま、実装することができます。
次の各項では、プライマリ・サイトとセカンダリ・サイトでの計画済の停止を削減するための推奨ベスト・プラクティスについて説明します。
表14-1に、プライマリ・サイトで計画済の停止を実行するための適切なソリューションを示します。この表には、14.2項「計画済の停止による停止時間の回避または短縮」の詳細な説明へのリンクが含まれます。
表14-1 プライマリ・サイトでの計画済の停止のソリューション
| 計画済のメンテナンス | 説明および例 | 優先されるOracleソリューション | 停止時間見積り |
|---|---|---|---|
|
サイト・メンテナンス |
プライマリ・データベースが現在使用不能になっているサイト全体で実行されるメンテナンスです。通常は、事前に広く通知されます。
|
14.2.1項 「データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス」 |
5分未満 |
|
データベース・クラスタ全体に影響するハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス |
データベース・サーバー・クラスタでのハードウェア・メンテナンスです。
|
14.2.1項 「データベース・スイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス」 |
5分未満 |
|
データベース・クラスタのサブセットに影響するハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス |
データベース・サーバーでのハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンスです。停止時間の範囲は、データベース・クラスタの1つのノードに制限されます。
|
Oracle RACサービスの再配置(14.2.11項「システム・メンテナンスのための自動ワークロード管理」) |
停止時間なし |
|
Oracle Grid Infrastructureアップグレードへのパッチ・セット、メンテナンスまたはメジャー・アップグレードの実行(Oracle ClusterwareとOracle ASMを含む) |
Grid Infrastructureのソフトウェア・メンテナンスです。
|
詳細は、『Oracle Database 2日でReal Application Clustersガイド』、およびプラットフォーム固有の『Oracle Grid Infrastructureインストレーション・ガイド』のOracle Grid Infrastructureのアップグレード方法に関する付録を参照してください。 |
停止時間なし 5分未満 停止時間なし(ロール移行がないか、ロール移行が行われる場合は5分未満の場合) |
|
Oracle Databaseへのパッチ・セット、メンテナンスまたはメジャー・アップグレードの実行 |
Oracle Databaseのソフトウェア・メンテナンスです。
|
|
5分未満 |
|
パッチ・セット更新(PSU)、クリティカル・パッチ・アップデート(CPU)またはパッチ・バンドルの適用 |
Grid InfrastructureまたはOracle Databaseのソフトウェア・メンテナンスです。
|
|
停止時間なし 停止時間なし(ロール移行がないか、ロール移行が行われる場合は5分未満の場合) |
|
Oracle個別パッチまたは診断パッチの適用 |
特定の顧客問題を修正するためのOracleソフトウェアへのパッチ適用。
|
|
停止時間なし 停止時間なし(ロール移行がないか、ロール移行が行われる場合は5分未満の場合) 停止時間なし |
|
データベース・オブジェクトの再編成または再定義 |
主にパフォーマンスや管理性を向上する目的で、Oracleデータベース・オブジェクトの論理構造または物理編成を変更します。 データまたはスキーマの変更です。 Oracleデータベースのオンライン再定義機能を使用すると、再編成または再定義中にオブジェクトを使用できます。
|
|
停止時間なし |
|
データベース・ストレージ・メンテナンス |
データベース・ファイルが存在するストレージのメンテナンスです。
|
Oracle ASMを使用したオンライン・ストレージ・メンテナンス(14.2.5.2項「ストレージ・メンテナンス」を参照) |
停止時間なし |
|
データベースのプラットフォームまたはロケーションの移行 |
プライマリ・データベースとスタンバイ・データベースのオペレーティング・システム・プラットフォームを変更します。 プライマリ・データベースの物理的な場所を変更します。
|
14.2.7項「データベースのプラットフォームまたはロケーションの移行」 |
5分未満から数時間 (選択した方法に依存) |
|
アプリケーションの変更 |
データ変更、スキーマおよびその他のプログラム的な変更が含まれます。
|
5分未満 |
セカンダリ・サイトの計画済の停止は、Active Data Guardを使用して読取り中心の作業をプライマリ・データベースからオフロードするアプリケーションの可用性に影響することがあります。セカンダリ・サイトで停止が発生したときにプライマリ・サイトで同時障害が発生すると、RTOおよびRPOに影響する可能性があります。セカンダリ・サイトの停止は、プライマリ・データベースの可用性に影響を与えずに管理できます。
最大保護データベース・モードで構成しており、プライマリ・データベースを保護するスタンバイ・データベースが1つのみの場合、プライマリ・データベースで停止時間が発生しないように、スタンバイ・インスタンスまたはデータベースで計画済の停止を実行する前に保護モードをダウングレードする必要があります。
最大保護データベース・モードで構成されていて、複数のスタンバイ・データベースが存在する場合、LGWR SYNC AFFIRM属性で構成された1つ以上のスタンバイ・データベースが利用でき、それプライマリ・データベースがREDOデータを転送できるかぎり、保護モードをダウングレードする必要はありません。
セカンダリ・サイトのメンテナンスをスケジュールする場合、サイト全体またはクラスタ全体の停止期間が増加するほどスタンバイ・データベースとプライマリ・データベースの差異が拡大し、それによりフォルト・トレランスを回復するための時間も増加することに注意してください。Data Guard保護モードの概要は、9.2項「保護モードとData Guardトランスポートの決定」を参照してください。
表14-2に、セカンダリ・サイトで計画済の停止を実行するための手順をまとめます。
表14-2 セカンダリ・サイトでの計画済の停止の管理
| 計画済のメンテナンス | Data Guardを使用したOracle Database 11g | Oracle Database 11g(MAA) |
|---|---|---|
|
サイト停止 |
停止前: 停止後: 13.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」 |
停止前: 停止後: 13.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」 |
|
管理リカバリ・プロセス(MRP)を実行しているノードでのハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス |
停止前: |
停止前: |
|
MRPを実行していないノードでのハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス |
適用なし |
プライマリ・スタンバイ・ノードまたはインスタンスは、管理リカバリ・プロセスで適用されるREDOログを受信するため、影響はありません。 停止後: 使用可能になったら、ノードとインスタンスを再起動します。 |
|
ハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス(クラスタ全体に影響) |
適用なし |
停止前: 停止後: 13.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」 |
|
Oracleパッチとソフトウェアのアップグレード |
アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。 |
アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。 |
計画済の停止の停止時間を回避または短縮するためのベスト・プラクティスには、次の項があります。
システムへの更新を実行する前に、入念なテストを実行することをお薦めします。
スイッチオーバーは、プライマリ・データベースとスタンバイ・データベース間のデータベース・ロールを切り替える一連の手順を含む計画済の移行です。スイッチオーバー操作に成功すると、スタンバイ・データベースがプライマリ・ロールを引き継ぎ、プライマリ・データベースがスタンバイ・データベースとなります。データベース・スイッチオーバーは、Oracle Enterprise ManagerまたはOracle Data Guardブローカによって、あるいはSQL*Plus文を発行することで実行できます。データベース・ロール管理のスコープでは、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にスタンバイ・データベースを元のロールに戻す操作です。
スイッチオーバーは、サイト・メンテナンス、およびハードウェアやソフトウェアのメンテナンス(データベース・アップグレードなど)を実行するとき、多くの状況で便利です。
プライマリ・データベースが起動しており、ターゲット・スタンバイ・データベースが使用可能で、すべてのアーカイブREDOログが使用できる場合、いつでもスイッチオーバーを実行できます。
スイッチオーバーは、次のような状況で役立ちます。
計画されたメンテナンス(プライマリ・ホストでのハードウェア・メンテナンスやファームウェア・パッチ適用など)
プライマリ・データベースをオープンしたままでのデータ障害の解決
セカンダリ・リソースのテストと検証(障害時リカバリの準備状況をテストする手段として)
SQL Applyを使用したローリング・アップグレードの実行(14.2.6.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」を参照)
スイッチオーバーは、次の場合には使用できないか、または効果がありません。
適用に必要なアーカイブREDOログ・ファイルがない場合
ポイント・イン・タイム・リカバリが必要な場合
プライマリ・データベースがオープンしておらず、オープンできない場合
スイッチオーバーを実行する前に、Data Guard構成のベスト・プラクティスを採用します。詳細は、9.4.1項「Oracle Data Guardスイッチオーバーのベスト・プラクティス」を参照してください。
Oracle Enterprise Managerを使用して、動的にスイッチオーバーを実行することをお薦めします。Oracle Enterprise Managerを使用していない場合、DGMGRLコマンドライン・インタフェースまたはSQL*Plus文を使用して、手動でスイッチオーバーを実行することができます。
Oracle Enterprise Managerの使用(『Oracle Data Guard Broker』を参照)
DGMGRLコマンドライン・インタフェースの使用(『Oracle Data Guard Broker』を参照)
SQL*Plusの使用
Data Guardスイッチオーバーの実行後に、次の操作を行います。
データベースがセカンダリ・サイトに移動され、アプリケーション層もセカンダリ・サイトに移動される場合は、完全サイト・フェイルオーバーを実行します。詳細は、13.2.1項「サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)」を参照してください。
データベースのみがセカンダリ・サイトに移動される場合は、アプリケーション・フェイルオーバーを実行します。詳細は、13.2.4項「アプリケーション・フェイルオーバー」を参照してください。
Oracle Database 11gからは、一部の認定個別パッチおよび診断パッチにオンライン・パッチがサポートされます。オンライン・パッチは、インスタンスを停止しないでOracleインスタンスのプロセスにパッチを当てる機能です。インスタンスに関連付けられる各プロセスは、安全実行点でパッチを適用したコードをチェックし、続いてそのコードをプロセス空き領域にコピーします。このように、パッチを適用したプロセスは、正確に同じ時間に新しいコードを取り上げるわけではありません。
従来のパッチとオンライン・パッチの主要な違いは、従来のパッチがソフトウェア・レベルで実装され、オンライン・パッチがソフトウェアまたはOracle Databaseインスタンス・レベルで実装されるということです。つまり、従来のパッチを受信するORACLE_HOMEを使用するインスタンスは常にパッチが適用されたコードを受信するのに対して、オンライン・パッチを受信するORACLE_HOMEを受信するインスタンスがパッチを適用されたコードを受信するのは、パッチが適用されるときにそのインスタンスが指定されていた場合のみです。
|
注意: オンライン・パッチでは、次の点に注意してください。
|
オンライン・パッチのベスト・プラクティス:
次の計画メンテナンス中に、インスタンスを停止できる場合は、すべてのオンライン・パッチをロールバックし、オフライン方式でパッチを適用します。
パッチを緊急に適用する必要があり、パッチを適用する停止時間を確保できない場合は、オンラインでインストール可能なパッチをオンライン方式でインストールする必要があります。インスタンスの停止時間を許容できる場合は、(パッチのREADMEの説明に従って)オフライン方式でパッチを適用します。
パッチは一度に1つのインスタンスに適用します。
オンライン・パッチをロールバックする場合は、パッチが適用されたすべてのインスタンスが含まれていることを確認して、同じ$ORACLE_HOMEを使用する複数インスタンスにわたって異なるソフトウェアがあるような、危険で混乱した状況を回避します。
本番環境にデプロイする前に、テスト・システムへのメモリーの影響を評価します(例: pmapコマンドの使用)。
$ORACLE_HOME/hpatchディレクトリは決して削除しないでください。
|
関連項目:
|
Oracle Data Guard Standby-First Patchの適用は、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるソフトウェア・リリースをサポートして、本番データベースへのリスクが低いローリング方法でOracleパッチを適用および検証します。Oracle Data Guard Standby-First Patchの適用は、Oracle Database Enterprise Editionリリース2 (11.2)リリース11.2.0.1以降の認定ソフトウェア・パッチでサポートされます。ターゲット・パッチがStandby-First Patchとして認定されているかどうかを判断するには、パッチのREADMEを参照してください。
Oracle Database COMPATIBLE初期化パラメータ値は、プライマリ・システムとフィジカル・スタンバイ・システム間で同じままである必要があります。
既存のデータベースまたはOracle Grid Infrastructureソフトウェア・リリースに依存しないすべてのOracle Exadata Storage Serverソフトウェアの変更が適用されます。
プライマリ・システムとフィジカル・スタンバイ・システム間の相互運用性を中断する可能性のあるソフトウェア変更、またはすべてのSQLコード変更は適用できません。
Oracle Data Guard Standby-First Patchの適用は、プライマリ・データベースを前のソフトウェア・リリースにしたまま、最初にフィジカル・スタンバイ・データベースにパッチを適用する方法をサポートします。
スタンバイ・データベースがプライマリ・データベースから完全に切り離されている(つまり、ストレージ、ネットワークまたはクラスタ・コンポーネントを共有しない)場合は、次の操作を実行します。
データベース・ホームに適用される認定Oracleパッチをまずスタンバイ・データベースに適用し、テストできます。このカテゴリのOracleデータベース・ソフトウェアの例を次に示します。
Exadata Databaseバンドル・パッチ
パッチ・セット更新(PSU)
クリティカル・パッチ・アップデート(CPU)
個別パッチ
その他のOracleまたはシステム・ソフトウェアは、まずスタンバイ・データベースに適用し、テストできます。このカテゴリのソフトウェアの例を次に示します。
グリッド・ホームに適用されるOracleパッチ
オペレーティング・システム・パッチおよびファームウェア
ストレージ・パッチ
ネットワーク・パッチ
スタンバイ・データベースがプライマリ・データベースとインフラストラクチャまたはサーバー・コンポーネントを共有する場合は、プライマリ・データベースへのリスクを軽減する方法で共有コンポーネントへのパッチを評価することはできません。たとえば、プライマリ・データベースとは別のクラスタで実行されているスタンバイ・データベースがあり、それがプライマリ・データベースと同じストレージ・グリッドを共有する場合は、プライマリ・データベースに影響を与えずにスタンバイ・ストレージに最初にパッチを適用することはできません。
次に、Oracle Data Guard Standby-First Patchの適用の利点を示します。
ロール移行の前、またはプライマリ本番データベースへの適用前に、リカバリ、バックアップまたは問合せ検証のためにフィジカル・スタンバイ・データベースにソフトウェア変更を適用する機能。これにより、本番データベースでのリスクと潜在的な停止時間が軽減されます。
リストを軽減し、停止時間を最小限に抑えて検証を完了した後で、ターゲット・データベースにスイッチオーバーする機能。
安定性やパフォーマンスが大きく低下している場合に、スイッチバック(フォールバックとも呼ぶ)を行う機能。
Oracleパッチ・セットとメジャー・リリース・アップグレードは適用されません。パッチ・セットとメジャー・リリースにはData Guardの一時ロジカル・スタンバイ手法を使用します。詳細は、14.2.6.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」を参照してください。
|
関連項目:
|
Oracle RACでは、特定のデータベース・パッチをノードまたはインスタンスごとに適用できるため、アプリケーションとデータベースを継続的に使用できます。データベース・ソフトウェア用の個別パッチ、パッチ・セット更新(PSU)およびクリティカル・パッチ・アップデート(CPU)を適用するのは、通常、インストール環境で発生したソフトウェア問題の既知の修正策を実装する場合か、問題に関する情報を収集するための診断パッチを適用する場合です。このようなパッチ適用は、一般的に、計画された停止期間中のメンテナンスで実行されます。
Oracleでは、データベースをまったく停止しないか、最小限の停止時間でOracle RACのローリング・パッチ・アップグレードを実行できます。この操作を行うためのツールは、opatchコマンドライン・ユーティリティです。
Oracle RACローリング・アップグレードのメリットは、パッチ・アップグレードに必要とされる計画済の停止期間中でも、Oracle RACインストール環境の一部のインスタンスを使用できることです。停止する必要があるのは、現在パッチを適用中のOracle RACインスタンスのみです。その他のインスタンスは、引き続き使用できます。これにより、このような計画済の停止に必要とされるアプリケーションの停止時間に対する影響を最小限に抑えることができます。Oracleのopatchユーティリティでは、Oracle RACインストール環境の異なるインスタンスに対して連続的にパッチを適用できます。
ローリング・アップグレード機能は、オラクル社がローリング・アップグレードに適切であると認定したパッチでのみ使用できます。パッチのREADMEファイルは、パッチをOracle RACローリング方式で適用できるかどうかを示します。一般に、ローリング方式でインストール可能なパッチは次のとおりです。
Exadata Databaseバンドル・パッチ
パッチ・セット更新(PSU)
クリティカル・パッチ・アップデート(CPU)
個別パッチ
診断パッチ
パッチのローリング・アップグレードは、現在個別パッチでのみ使用可能です。ローリング・アップグレードは、パッチ・セットには使用できません。
ローリング・パッチ・アップグレードは、Oracleデータベース・ソフトウェアが異なるノード間で共有されるデプロイメントでは使用できません。これに該当するのは、クラスタ・ファイル・システム(CFS)上、またはファイル・サーバーやNFSマウント・ドライブにより提供される共有ボリューム上にOracleホームが存在する場合です。この機能を使用できるのは、各ノードがOracleデータベース・ソフトウェアの独自のコピーを所有している場合のみです。
すべてのデータベース・パッチ・アップグレードで、次の推奨プラクティスを使用します。
Oracleサポート・サービスに連絡して、パッチが現在の問題とデプロイメント環境に有効であることを必ず確認します。
パッチを適用する計画とともに、パッチをバック・アウトする計画を作成します。
パッチは先にテスト環境に適用し、問題が修正されることを確認します。
パッチを適用する際の所要時間を見積もる場合、必要に応じてテクノロジ・スタックの他の層を起動および停止する時間も含めます。
パッチがOracle RACローリング・アップグレードに適しておらず、パッチの適用時に停止時間が発生する可能性がある場合、14.2.6項「データベース・アップグレード」を参照して他の解決方法を実行できないかどうかを検討します。
次に、Oracle RACローリング・アップグレードの追加の推奨プラクティスを示します。
複数のインスタンスでOracleホームを共有している場合、それらすべてのインスタンスがパッチの適用により影響を受けます。管理者は、これにより意図しない別の問題が発生しないことを確認する必要があります。また、パッチの適用中は、ノード上のこのようなインスタンスをすべて停止する必要があります。計画済の停止を計画する場合、そのことを考慮する必要があります。ベスト・プラクティスとしては、類似するアプリケーションのみでノード上のOracleホームを共有します。これにより、パッチ適用の柔軟性が向上します。
各ノードのOracleインベントリは、インストールされているすべてのOracleソフトウェアの中央インベントリを保持するリポジトリです。インベントリは、各ノードに固有です。インベントリは、ノードにインストールされているすべてのOracleソフトウェアにより共有されます。このインベントリがノード間で類似するのは、デプロイされているOracleデータベース・ソフトウェア、デプロイメント構成およびパッチ・レベルに関してすべてのノードが同じである場合のみです。Oracleインベントリは、パッチ適用およびパッチ管理プロセスに非常に役立つため、その整合性を維持することをお薦めします。Oracleインベントリは、特定のノードのOracleソフトウェアにパッチをインストールするたびにバックアップする必要があります。この原則は、クラスタの各ノードのOracleインベントリに適用されます。
Oracle Universal Installerを使用してすべてのOracleデータベース・ソフトウェアをインストールします。これにより、関連するリポジトリ・エントリがクラスタの各ノードのOracleインベントリに作成されます。また、既存のOracle RACクラスタにノードを追加する場合もOracle Universal Installerを使用します。
ただし、この操作を実行していない場合や、なんらかの理由で実行できない場合、opatchユーティリティのattachオプションを使用して、既存のOracleデータベース・ソフトウェア・インストールに関する情報をOracleインベントリに追加できます。ノード情報もこのオプションで追加できます。
Oracleローリング・パッチ・アップグレードでは、その性質上、パッチをOracle RACクラスタの一部のノードにのみ適用できます。そのため、パッチの適用されているインスタンスと、パッチの適用されていないインスタンスが同時に稼働することになります。この状態は、ローリング・パッチ・アップグレード以外の方法では発生しません。Oracle RACデプロイをアクティブ化する前であれば、ローリング・パッチ・アップグレード以外の方法ですべてのインスタンスにパッチを適用します。パッチをすべてのインスタンスにデプロイする前にテストする必要がある場合、混在環境は役立ちます。これを実現するのに推奨される方法は、-localオプション付きでパッチを適用することです。
Oracle RACクラスタのすべてのインスタンスを同じパッチ・レベルで維持するため、検証の完了したパッチは、Oracle RACインストール環境のすべてのノードに適用することを強くお薦めします。Oracle RACクラスタの各インスタンスが同じパッチ・ソフトウェアを維持している場合、パッチの修正対象である問題を発生させることなくインスタンス間でサービスを移行できます。
すべてのパッチ(ローリング・アップグレードにより適用されるパッチを含む)は、オンラインで管理し、適用後も削除しないようにします。パッチを保存しておくと、パッチをロールバックまたは再適用する場合に役立ちます。
パッチは、クラスタのすべてのノードからアクセスできる場所に保存します。これにより、クラスタのすべてのノードで、同じようにパッチを適用またはロールバックできます。
ローリング・パッチ・アップグレードは、他の任意のパッチ・アップグレードと同様に、ノードで別のパッチ・アップグレードまたはOracleインストールが行われていない場合に実行します。複数のパッチの適用は、順次処理するため、計画済の停止はあらかじめそれに応じて計画します。
複数のパッチを同時に適用する必要があるが、ローリング・アップグレードできるパッチがその一部のみである場合は、すべてのパッチをローリング・アップグレードでない方式で適用します。これにより、パッチ適用プロセスの完了に必要とされる合計時間を短縮できます。
ローリング・アップグレードに適さないパッチの場合、Oracle RACデプロイ用として次に適切なオプションは、APPLYコマンドのMINIMIZE_DOWNTIMEオプションです。
ローリング・アップグレードを実行するのは、システム使用率が低く、エンド・ユーザーへのサービス中断の影響を最小にできるのが確実であるときです。
|
関連項目: opatchユーティリティの詳細は、『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド for Microsoft Windows and UNIX Systems』を参照してください。 |
次のソフトウェアのインストールは、デフォルトでOracle Universal Installer (OUI)によりホーム外で実行されます。OUIによって実行されるソフトウェア・インストールは、完全ソフトウェア・インストールです。
メジャー・リリース
メンテナンス・リリース
パッチ・セット(11gリリース2以降)
次のソフトウェアのインストールは、OPatchユーティリティによりインプレースで実行されます。OPatchは、インストールされるパッチの更新ソフトウェアで既存のソフトウェアを上書きすることにより、ソフトウェア更新を既存のORACLE_HOMEにインストールします。
個別パッチのインストール
バンドル・パッチのインストール
パッチ・セット更新(PSU)のインストール
クリティカル・パッチ・アップデート(CPU)のインストール
診断パッチのインストール
ホーム外パッチ適用の利点
新規ORACLE_HOMEでのソフトウェアのアップグレード中も、引き続きアプリケーションを使用できます。
クローニング手順にはソフトウェアの物理的なコピー操作が含まれるため、ORACLE_HOME内の構成は保持されます(たとえば、LISTENER.ORA、TNSNAMES.ORA、INITSID.ORAなどのファイル)。
元のORACLE_HOMEとパッチを適用したORACLE_HOME間でロールバックまたはテストする方が簡単です。
統合する場合、複数のバージョンのORACLE_HOMEを持つことができるため、このオプションでは統合のサポートが向上します。
ホーム外パッチ適用の使用上の考慮事項
クローニングによるホーム外パッチ・インストールを実行する場合、アプリケーション・コードおよびOracle固有のスクリプトにハードコードされているORACLE_HOME環境変数をすべて変更する必要があります。
ホーム外パッチ適用には、インプレース・パッチ適用よりも多くのディスク領域が必要です。
OPatchを使用したホーム外パッチ適用
従来、OPatchでインストールされるパッチはインプレースで行われるため、新しいコードは古いコードに直接適用されます。
インプレース・パッチの短所は次のとおりです。
新しいコードのインストール中は、アプリケーションはデータベースに接続できません。
パッチ・ロールバックが必要な場合、古いコードの再インストール中はアプリケーションがデータベースに接続できません。
|
注意: インプレース・データベース・パッチ・セット・アップグレードのこの短所は、Standby-First Patch Applyを使用する場合には適用されません。詳細は、14.2.3項「Data Guard Standby-First Patchの適用」を参照してください。 |
OPatchによって実行されるOracle Databaseソフトウェア・ホームまたはGrid Infrastructureソフトウェア・ホームへのソフトウェアのインストールは、OPatchを使用して新しいORACLE_HOMEにパッチを適用する前にORACLE_HOMEクローニング手法を使用して新しいホーム・ディレクトリにソフトウェアをコピーすることにより、ホーム外で実行できます。ホーム外パッチ適用を実行する高レベルのアプローチは次のとおりです。
アクティブなORACLE_HOMEを新しいORACLE_HOMEにクローニングします。
新しいORACLE_HOMEにパッチを適用します。
新しいORACLE_HOMEをアクティブなソフトウェア・ホームに切り替えます。この操作は、一度に1ノードずつローリング方式で実行できます。
|
関連項目: ホーム外パッチ適用の詳細は、次の場所にあるMy Oracle Supportのノート1136544.1の『Minimal downtime patching via cloning 11gR2 ORACLE_HOME directories on Oracle Database Machine』を参照してください。
|
OPlanは、インプレース・パッチ・インストールとホーム外パッチ・インストールの両方について、環境に固有のパッチ適用の手順を示すことで、パッチのインストール・プロセスを容易にするユーティリティです。現在、OPlanはExadata Databaseバンドル・パッチでサポートされます。最新情報は、次の場所にあるMy Oracle Supportのノート1306814.1の『Oracle Software Patching with OPLAN』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1306814.1
Oracle Database 11gリリース2 (11.2)以降では、Oracle ASMはOracle Grid Infrastructureコンポーネントをインストールするときにインストールされ、Oracle RACなどとともにクラスタにインストールされたときにOracle ClusterwareとOracleホームを共有します。Grid Infrastructureでパッチ適用やアップグレードなどのメンテナンスを実行する場合、Oracle ASMとOracle Clusterwareの両方に影響します。
Grid Infrastructureのアップグレードは、Oracle ClusterwareとOracle ASMを新しいメジャー・バージョン、メンテナンス・バージョンまたはパッチ・セットにすることを意味します。Grid Infrastructureのアップグレードは、ローリング方式で実行されます。
|
関連項目: 『Oracle Database 2日でReal Application Clustersガイド』詳細は、プラットフォームに固有の『Oracle Grid Infrastructureインストレーション・ガイド』でOracle Grid Infrastructureのアップグレード方法に関する付録を参照してください。 |
システム上にストレージを追加したり、アップグレードしたりするときは、次の手順を使用します。次の各項の手順では、ストレージをOracle ASMディスク・グループに追加すると仮定します。
ファイル・システムまたはRAWデバイスにデータベース・ファイルを格納する既存のOracleデータベースがある場合、それらのデータベース・ファイルの一部または全部をOracle ASMに移行できます。停止時間を最小にするには、フィジカル・スタンバイ・データベースを使用して、データをOracle ASM記憶域に移行します。Oracle Recovery Manager (RMAN)またはASMCMDユーティリティを使用すると、停止時間をほとんど発生させずにOracle ASMに移行できます。Oracle Recovery Manager (RMAN)とASMCMDユーティリティでは、個々のファイルをOracle ASMにコピーできます。
完全移行の場合は、Oracle Data GuardまたはOracle GoldenGateが、より少ない停止時間でOracle ASMに移行するためのより優れた代替方法です(移行は、スイッチオーバーの実行に要する時間と同じ程度で行われます)。
|
関連項目:
|
Oracle ASMへのディスクの追加および削除は停止時間なしで実行できます。ディスクが追加または削除されると、Oracle ASMではリバランス操作が自動的に開始され、ディスク・グループのコンテンツがディスク・グループのすべてのドライブに均等に分割されます。ストレージの追加または削除のベスト・プラクティスは次のとおりです。
Oracle ASMを使用してストレージの追加や削除を行う前に、ホスト・オペレーティング・システムとストレージ・ハードウェアが、停止時間なしでのストレージの追加や削除をサポートしていることを確認します。
複数のディスク・ドライブを追加または削除するときに単一のALTER DISKGROUPコマンドを使用します(この方法ではリバランス操作は1つのみですが、個々の削除と追加では2つ以上のリバランス操作があります。詳細は、4.5.4項「単一のコマンドを使用したストレージの追加または削除」を参照してください)。
たとえば、ストレージ・メンテナンスでドライブを追加し、既存のドライブを削除する場合は、既存のドライブを削除するためのDROP DISK句と、ドライブを追加するためのADD DISK句を指定した単一のALTER DISKGROUPコマンドを使用します。
ALTER DISKGROUP data
DROP DISK diska5
ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;
ディスク・グループからディスクを削除する場合、削除対象のドライブの内容が他のドライブに移行されるまでALTER DISKGROUP文が戻されないように、REBALANCE句にWAITオプションを指定します。文が完了したら、システムから安全にドライブを削除できます。たとえば、次のようになります。
ALTER DISKGROUP data DROP DISK diska5 ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9 REBALANCE WAIT;
標準または高冗長性ディスク・グループのディスクを削除する場合、完全な冗長性を再構築するのに十分な空き領域がディスク・グループに存在することを確認します。
Enterprise Managerを使用するか、V$ASM_OPERATIONを問い合せることでリバランス操作の進行状況を監視します。
データベース・アクティビティの頻度が低い期間に長く実行されるリバランス操作では、リバランスの最大能力が向上するため、リバランス時間を短縮できます。
|
関連項目: 『Oracle Automatic Storage Management管理者ガイド』 |
Oracle ASMローリング・アップグレードを実行すると、クラスタ化Oracle ASMノードのアップグレードまたはパッチ適用を独立して行うことで、データベース可用性に影響を与えずに稼働時間を最大化できます。Oracle ASMローリング・アップグレードを使用できるのは、Oracle Database 11g以上のリリースを実行している環境でクラスタ化Oracle ASMインスタンスをアップグレードする場合のみです。
|
関連項目: Oracle ASMローリング・アップグレードの使用方法の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
データベース・アップグレードは、データベースを新しいメジャー・リリース、メンテナンス・リリースまたはパッチ・セットにすることを意味します。データベース・アップグレードを実行する場合、次のOracle機能を使用できます。
データベース・アップグレードの実行方法は、次のことを考慮したうえで選択します。
アップグレードを完了するのに必要な停止時間
停止時間の前に必要な設定時間および作業
一時的に必要となる追加リソース(ディスク領域やCPUなど)
アップグレードを完了するのに許容される手順の複雑さ
表14-3に、データベース・アップグレードに使用できる方法と、特定のケースでその方法の使用が推奨される場合についてリストします。
表14-3 データベース・アップグレード・オプション
| アップグレード方法 | この方法を使用する場合 |
|---|---|
|
Database Upgrade Assistant (DBUA)を使用したアップグレード |
メンテナンス・ウィンドウが十分であるか、データ型制約によりこの表の他の方法を使用できない場合の推奨の方法 |
|
Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード |
DBUAがメンテナンス・ウィンドウ内に終了せず、データベースがOracle RACローリング・パッチ・アップグレードに適していない場合 フィジカル・スタンバイ・データベースが1つのみの構成の場合は、一時ロジカル・スタンバイを使用 |
|
|
Oracle GoldenGateは、完全データベース・レプリケーションの場合、データベース・バージョンがOracle 10g (Oracle Data Guardデータベース・ローリング・アップグレードの最小バージョン)より前の場合、前のバージョンへのレプリケートのために柔軟性が必要な場合(高速フォールバック・オプション)、またはマルチマスター・レプリケーションを使用した停止時間ゼロのアップグレードが必要な場合にすでに使用されています。 |
|
|
Data Guard SQL ApplyまたはOracle GoldenGateでサポートされないデータ型をデータベースで使用しており、ユーザー・スキーマが単純な場合 |
使用するアップグレード方法にかかわらず、『Oracle Databaseアップグレード・ガイド』のガイドラインおよび推奨事項と、その関連ドキュメントである次の場所にあるMy Oracle Supportのノート785351.1の『Oracle 11gR2 Upgrade Companion』に従う必要があります。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=785351.1
|
関連項目:
|
Database Upgrade Assistant(DBUA)は、データベースを以前のソフトウェア・リリースからインプレースでアップグレードする際に使用します。
最小限の停止時間でデータベース・アップグレードを実行する際に、DBUAを適切なツールとして使用するかどうかを決定する場合、次の点を考慮してください。
DBUAは、データベース・ディクショナリとすべてのコンポーネントをアップグレードします。例: 通常のユーザー・アクティビティにデータベースを使用できないときにインストールされたJavaやXDBなど。
DBUAを使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
すべてのデータベース・ディクショナリ・オブジェクトを新規バージョンにアップグレードする時間
データベースの再起動
アップグレードしたデータベースにクライアントを再接続する時間
DBUAの使用時にデータベース・アップグレードに必要とされる停止時間を短縮するには、次のようにします。
使用されていないデータベース・オプションをすべて削除します。
DBUAでは、アプリケーションで必要とされるかどうかにかかわらず、インストール済のすべてのデータベース・オプションがアップグレードされます。アップグレードの必要なオプションの数を減らすことで、アップグレード時間全体を短縮できます。
データ・ディクショナリ統計は、アップグレードの直前に更新します。
DBUAによるアップグレードの実行時間がメンテナンス・ウィンドウ内に収まる場合は、データベース・アップグレードにDBUAを使用してください。
|
関連項目:
|
Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用して、ローリング・アップグレードというプロセスを使用して最小限の停止時間でデータベースをアップグレードします。現在のところ、Data Guardでは、プライマリ・データベースとスタンバイ・データベースが同じプラットフォームで稼働する同機種環境をサポートしています。
|
関連項目: 異種環境に固有の例外、およびSQL Applyでのローリング・アップグレードに関するその他の最新情報は、次の場所にあるMy Oracle Supportのノート413484.1の『Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration』を参照してください。
|
従来の方法によるアップグレードがメンテナンス・ウィンドウ内に完了せず、アプリケーションでユーザー定義型を使用していない場合は、Data Guard SQL Applyのローリング・データベース・アップグレードを使用してください。パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、SQL Applyを使用するOracle Data Guardのソリューションをお薦めします。
データベース・アップグレード時の停止時間を最小化するためにData Guard SQL Applyが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
SQL Applyには、データ型の制限がいくつかあります(制限のリストは、『Oracle Data Guard概要および管理』を参照)。データ型の制限がある場合は、拡張データ型サポート(EDS)の実装を検討してください。ソース・データベースがSQL Applyでもともとサポートされていないデータ型を使用している場合、拡張データ型サポート(EDS)を使用することで、対応する拡張データ型をさらにいくつか増やすことができます。
SQL Applyローリング・アップグレードは、ソース・リリースがOracle Database 10gリリース1(10.1.0.3)以上であれば、メジャー・リリース・アップグレードを含むすべてのアップグレードに対して実行できます。作業を開始する前に、『Oracle Data Guard概要および管理』でSQL Applyローリング・アップグレードの詳細な手順と、サポートされるデータ型を確認してください。
ソース・データベースが、SQL Applyのローリング・アップグレードでサポートされていないソフトウェア・バージョンを使用している場合(Oracle Databaseリリース10.1.0.3より前のリリース)、またはEDSを使用してもSQL Applyのデータ型の競合を十分に解決できない場合は、Database Upgrade Assistant (DBUA)、トランスポータブル表領域またはOracle GoldenGateの使用を検討します。
Data Guard SQL Applyを使用したデータベース・アップグレード(ローリング・アップグレード)に必要な停止時間は、次の操作に要する時間によって決定されます。
Data Guardスイッチオーバーを実行する時間
新規データベースにクライアントを再接続する時間
|
関連項目:
|
一時ロジカル・スタンバイ・データベースを使用して、現在のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換することにより、そのフィジカル・スタンバイ・データベースを使用してデータベースのローリング・アップグレードを実行できます。フィジカル・スタンバイ・データベースが1つのみの構成の場合は、一時ロジカル・スタンバイを使用します。一時ロジカル・スタンバイを使用したローリング・アップグレードの実行は、標準SQL Applyローリング・アップグレードと似ていますが、次の点が異なります。
保証付きリストア・ポイントがプライマリ・データベース上に作成され、スイッチオーバーの後、データベースをフィジカル・スタンバイ・データベースにフラッシュバックします。
フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換では、KEEP IDENTITY句を使用して、プライマリ・データベースと同じDB_NAMEおよびDBIDを保持します。
ALTER DATABASE CONVERT TO PHYSICAL STANDBY文が、元のプライマリ・データベースを、ロジカル・スタンバイからフィジカル・スタンバイ・データベースに変換します。
元のプライマリ・データベースは、一時ロジカル・スタンバイ・データベース・ロールからフィジカル・スタンバイ・データベースに変換された後で、REDO Applyを使用して実際にアップグレードされます。
図14-1に、一時ロジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行するときに発生する処理のフローを示します。
|
注意: 図14-1に示す操作を簡略化するために、データベースのローリング・アップグレード手順を自動化するBourneシェル・スクリプトを使用できます(Oracle Database 11gリリース1以降)。データベースのローリング・アップグレードは、既存のData Guardフィジカル・スタンバイ・データベースおよび一時的なロジカル・スタンバイ・ローリング・アップグレード・プロセスを使用して実行されます。次の場所にあるMy Oracle Supportのノート949322.1の『Oracle 11g Data Guard: Database Rolling Upgrade Shell Script』で詳細に説明されている、physruという名前のBourneシェル・スクリプトをダウンロードできます。
|
図14-1 一時ロジカル・スタンバイ・データベースを使用したデータベース・ローリング・アップグレード
|
関連項目:
|
Oracle Data Guardでは対処するように設計されていない要件に対して、最小限の停止時間でデータベース・ソフトウェアをあるバージョンから別のバージョンにアップグレードするために、Data Guardデータベース・ローリング・アップグレードの代替方法としてOracle GoldenGateを使用することを検討してください。この目的では、Oracle GoldenGateはOracle Data Guardに比べて次の利点があります。
Oracle GoldenGateは、Oracle Database 10gより前のOracle DatabaseリリースからOracle Databaseをローリング方式でアップグレードできます(Data Guardデータベース・ローリング・アップグレードは、Oracle Database 10g以降でサポートされます)。
Oracle GoldenGateは、新しいOracle Databaseリリースから以前のOracle Databaseリリースへの一方向レプリケーション用に構成して、高速フォールバック・オプションを有効にできます(Oracle Data Guardでは、以前のデータベース・リリースから新しいリリースへのレプリケートのみ可能です)。これは、一定期間新しいリリースで操作する場合に役立ち、本番運用の開始数日後に予期しない問題が発生した場合に以前のリリースに迅速に戻すことができます。新しいリリースから以前のリリースへの一方向レプリケーションを構成することにより、問題を解決する一方で、データを失ったりダウングレードに時間をかけたりすることなく本番環境を以前のリリースに迅速に切り替えることができます。
Oracle GoldenGateは、異なるOracle Databaseリリース間のマルチマスター・レプリケーション用に構成して、停止時間ゼロのアップグレードを促進できます(Oracle Data Guardは一方向レプリケーション・ソリューションです)。新しいOracleリリースがデプロイされ、ユーザー接続の準備ができると、古いリリースの既存のユーザー接続でトランザクションの処理を継続したまま、新しいユーザー接続を新しいリリースに向けることができます。既存のユーザー接続が終了すると、ユーザーが停止時間を認識することなく、以前のリリースで動作しているOracle Databaseの使用率が自然に縮小されます。マルチマスター・レプリケーションは、この移行フェーズ中に両方のデータベースの同期を保ちます。すべてのユーザーが新しいリリースに移行した後、単純な一方向レプリケーションは以前のデータベース・リリースの同期を維持して、前の箇条書き項目で説明したように高速フォールバック・オプションを提供できます。マルチマスター・レプリケーションは、すべてのアプリケーションに適しているわけではありません。競合の検出と解決が必要です。
データベースのアップグレードに14.2.6.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」で説明した手順を使用できず、データベースまたはアプリケーションのアップグレードの際の停止時間を0 (ゼロ)にするか最小限に抑える必要がある場合は、Oracle GoldenGateを構成してデータベース・アップグレードを実行することで、停止時間を0 (ゼロ)または最小限に抑えることができます。詳細は、次の場所にあるホワイト・ペーパー『Zero-Downtime Database Upgrades Using Oracle GoldenGate』を参照してください。
|
関連項目: Oracle GoldenGateを使用したデータベース・アップグレードの詳細は、『Oracle GoldenGate Windows and UNIX管理者ガイド』を参照してください。 |
トランスポータブル表領域を使用すると、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、データベース・アップグレードを実行できます。
データベース・アップグレードの実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。
SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やアプリケーションに必要なオブジェクトを含むターゲット・データベースのSYSTEM表領域の内容は、手動で構築する必要があります。SYSTEM表領域の内容を移動する場合、データ・ポンプを使用します。
トランスポータブル表領域を使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
ソース・データベースの表領域を読取り専用モードにする時間。
トランスポータブル・メタデータのネットワーク・インポートを実行する時間。
ターゲット・データベースがリモート・システムに存在する場合、ソース・システムからターゲット・システムにすべてのデータファイルを転送する時間。ただし、トランスポータブル表領域を使用してデータベース・アップグレードを実行すると有益なのは、データファイルをその現在の場所で使用できる場合のみです。トランスポータブル表領域手法は、この手法を使用するとターゲットの場所にデータファイルをコピーする必要がある場合にはお薦めしません。
データファイルの転送時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを使用可能にするストレージ・インフラストラクチャを使用するか、フィジカル・スタンバイ・データベースを使用します。
トランスポータブル表領域を使用したデータベース・アップグレードの実行は、次の場合に推奨されます。
トランスポート・プロセスの一環としてデータファイルをコピーせずに、現在の場所でデータファイルを使用できる場合。ターゲット・データベースが異なるマシン上に存在する場合、ソース・システムとターゲット・システムの両方からそのストレージにアクセスできる必要があります。
DBUAがメンテナンス・ウィンドウ内に完了しない場合。
データ型の制限によりOracle GoldenGateまたはData Guard SQL Applyを使用できない場合。
Oracleデータベースに単純なスキーマが含まれる場合。
|
関連項目:
|
データベースの移行を実行する場合、主要な目標は、既存のソース・システムからOracle 11gデータベースにデータを移行することです。データの移行は、データ・ポンプ、トランスポータブル表領域、Oracle Data Guard、Oracle GoldenGateなどのツールで実行できます。ただし、移行中は、移行計画の目標となる2つの同等の重要度の項目に対処する必要があります。
簡略化: 移行中に、実装を簡略化します。様々なバージョンと様々なDBAによって進化してきたほとんどのデータベース環境には、古い情報が含まれます(また、現在のDBAはシステムで何かが使用されている理由について疑問を持つ場合があります)。簡略化の目的は、管理者が作業を高い信頼性で簡単に行えるようにすることです。この簡略化により、システムの可用性が高まります。
最適化: 移行中に、実装を最適化できます。多くの場合、移行には更新されたデータベース・バージョンが含まれるため、新しい機能が使用可能です。移行の実行中に、新しい機能とプラクティスの採用を検討する必要があります。
移行計画に次の手順を追加して、簡略化と最適化を行います。
移行方針を策定する場合の最初の手順は、新しいターゲット環境について理解し、ソース・システムからターゲット・システムにデータを物理的に移動する方法を決定することです。ターゲット環境の中心はOracle Databaseです。他のOracleデータベース・アップグレードや移行と同様に、『Oracle Databaseアップグレード・ガイド』とその関連ドキュメントである次の場所にあるMy Oracle Supportのノート785351.1の『Oracle 11gR2 Upgrade Companion』に記載されているガイドラインおよび推奨事項に従う必要があります。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=785351.1
移行中にinit.oraを更新します。
既存のinit.oraファイルで、重要でなくなったと思われるパラメータを削除します。パラメータをデフォルト設定から変更する場合は、変更の妥当性を確認します。たとえば、以前のリリースで見つかった問題を回避するため(たとえば、以前のリリースで解決したオプティマイザの問題を処理するため)に設定されたアンダースコア・パラメータは削除できます。
移行中にSQLを更新します。
オプティマイザで目的の計画を強制的に生成するために挿入された、以前のOracle Databaseバージョンに追加されたSQLヒントを削除します。オプティマイザは一般に、適切な統計が提供されていれば、ヒントの必要なしに適切な実行計画を作成します。
移行中にスキーマ・オブジェクトを簡略化または変更します。
移行中に行えるスキーマ・レイアウトの変更があるかどうかを検討する必要があります。たとえば、次の場合を考えます。
大きな表のパーティション化スキームの変更
Oracle Exadataデータベース・マシンに移行する場合に、ハイブリッド列圧縮(HCC)などの新規に使用可能な圧縮機能の採用(詳細は、『Oracle Database概要』を参照)
暗号ハードウェア・アクセラレーションを提供するシステムに移行する場合には特に、透過的データ暗号化(TDE)の採用
また、索引の過剰な使用など、移行するべきでないオブジェクトがあるかどうかを判断します。データベースのスキーマ・オブジェクトを変更または削減する場合は、現在の形式でデータベースを移行し、移行後に変更を実行する方がよいか、または移行中に選択的に行う方がよいかを検討する必要があります。
使用していない表領域とデータファイルを移行中に削除します。
使用していないまたは不要な表領域とデータファイルを移行中に削除できるかどうかを検討する必要があります。表領域とデータファイルが少ない方が、管理性とパフォーマンスが向上します。
ソース・データベースをOracle Database 11gリリース2にアップグレードすることを検討します。これにより、(場合によっては大幅に)移行が向上します。たとえば、Oracle Database 11gリリース2のデータ・ポンプのパラレル機能はOracle Databaseリリース10.2よりも大幅に向上しているため、ソース・データベースをOracle Database 11gリリース2にアップグレードした場合は、ソース・システムからのデータベース・エクスポートが向上し、より高速に完了します。
移行の前に、ソース・データベース内の不要なスキーマ・オブジェクトの削除を検討します。これにより、移行する必要のあるデータ量が削減されます。
ビジネス・ニーズと停止時間の要件を判断および検討します。必要な停止時間の長さに影響する要因について、14.2.7.3項「プラットフォームの移行とアップグレードに関するOracleの機能」でプラットフォームの移行に関するOracle機能を参照してください。
移行を段階的に実行するための要件または可能性があるかどうかを検討します。たとえば、ソース・データベースに大量の読取り専用データがある場合は、ライブ・データ移行の前に移行して停止時間を短縮できます。
プラットフォームの移行作業には、大量のテストが含まれます。
プラットフォーム移行とアップグレードを実行する場合、次のOracle機能を使用できます。
これらのデータベース・メンテナンス・タスクの実行方法は、次のことを考慮したうえで選択します。
メンテナンス操作を完了するのに必要な停止時間
停止時間の前に必要な設定時間および作業
一時的に必要となる追加リソースの量(ディスク領域やCPUなど)
メンテナンス操作を完了するのに許容される手順の複雑さ
表14-5に、プラットフォーム移行およびデータベース・アップグレードに使用できる方法と、操作ごとにその方法の使用が推奨される場合についてまとめます。
表14-5 プラットフォームおよびロケーション移行のオプション
| 操作 | 推奨される方法 | 代替の方法 |
|---|---|---|
|
同じエンディアン・プラットフォームへのプラットフォーム移行 |
プラットフォーム移行のためのフィジカル・スタンバイ・データベース |
|
|
異なるエンディアン・プラットフォームへのプラットフォーム移行 |
プラットフォーム移行のためのOracle Data Pump |
|
|
ロケーション移行のみ |
ロケーション移行のためのData Guard REDO Apply(フィジカル・スタンバイ・データベース) |
なし |
プラットフォーム移行の推奨アプローチは、フィジカル・スタンバイを作成し、スイッチオーバーを実行することです。フィジカル・スタンバイ・データベースは、特定の異種プラットフォームの組合せをサポートします。プラットフォームの組合せの最新リストは、次の場所にあるMy Oracle Supportのノート413484.1の『Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1
Oracle Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムとクラスタのアップグレードを実行する場合に推奨されるソリューションです。たとえば、Data Guardは次の場合にも推奨されます。
システム制約のためにOracle RACローリング・アップグレードを使用してアップグレードできないシステム・アップグレード。
Oracle ASMへの移行、クラスタ化されていない環境からのOracle RACへの移行、64ビット・システムへの移行、同じエンディアン形式の異なるプラットフォームへの移行、同じプロセッサ・アーキテクチャの異なるプラットフォームへの移行、またはWindowsからLinuxへ、LinuxからWindowsへの移行。
32ビットOracleバイナリを持つプライマリ・データベースがLinux 32ビット上にあり、64ビットOracleバイナリを持つフィジカル・スタンバイ・データベースがLinux 64ビット上にある場合。このような構成は、Data Guardのロール移行(スイッチオーバーおよびフェイルオーバー)時に、サポート・ノート414043.1に記載されている追加の手順に従う必要があります。
|
関連項目:
|
トランスポータブル・データベースは、データベース全体を、同じエンディアン形式を持つ別のプラットフォームに移行する場合、ただし移行元と移行先のプラットフォームの組合せで、クロスプラットフォームのフィジカル・スタンバイ・データベースが使用できない場合のみに推奨される方法です。
データベースを別のプラットフォームに移行する際にトランスポータブル・データベースが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
トランスポータブル・データベースでは、同じエンディアン形式のプラットフォーム間でのデータベースの移行がサポートされます。
トランスポータブル・データベースを使用したプラットフォーム移行に必要な停止時間は、次の操作に要する時間によって決定されます。
ソース・データベースを読取り専用モードにする時間。
データファイルを変換します。UNDOセグメントを含むファイル、またはHP Tru64との間で変換する場合は自動セグメント領域管理(ASSM)セグメント・ヘッダーを含むファイルのみ、変換が必要です。
すべてのデータファイルをソース・システムからターゲット・システムに転送する時間。
停止時間の総量を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。
|
関連項目:
|
Oracle GoldenGateを使用すると、最小限の停止時間でデータベースをあるプラットフォームから別のプラットフォームに移行できます。トランスポータブル・データベースで移行を迅速に実行できない状況において、アプリケーションでユーザー定義型を使用しておらず、移行を実行するために追加の管理作業が発生してもかまわない場合は、Oracle GoldenGateの使用を検討してください。
プラットフォーム移行の実行にOracle GoldenGateが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
Oracle GoldenGateでは、ユーザー定義型がサポートされません(オブジェクト型、REF値、VARRAY、ネストした表など)。
Oracle GoldenGate環境をセットアップして、維持するには、追加の管理上の労力が必要とされることがあります。
Oracle GoldenGateを使用したプラットフォーム移行に必要な停止時間は、キュー内の残りのトランザクションを適用する時間と、新規データベースにクライアントを再接続する時間によって決定されます。
|
関連項目: 『Oracle GoldenGate Windows and UNIX管理者ガイド』 |
Oracle Data Pumpテクノロジを使用すると、異なるプラットフォーム間や異なるデータベース・リリース間でデータおよびメタデータをあるデータベースから別のデータベースに高速に移動できます。
プラットフォーム移行にデータ・ポンプが適切な方法であるかどうかを決定する場合、次の点を考慮してください。
データ・ポンプを使用している場合にプラットフォーム移行に必要な停止時間は、完全データベース・エクスポートの実行、ターゲット・システムへのエクスポート・ダンプ・ファイルの転送、さらに完全データベース・インポートの実行に必要な時間によって決まります。
停止時間は、ソース・システムとターゲット・システム間で共有されているストレージへのエクスポートを実行することで短縮されるため、エクスポート・ダンプ・ファイルの転送の必要がなくなります。
データ・ポンプは、ネットワーク・インポートと呼ばれる、データベース・リンク上でのソース・データベースからのターゲット・データベースの直接ロード機能をサポートします。場合によっては、ネットワーク・インポートはエクスポート・データベースのマルチステップ・アプローチ、ダンプ・ファイルの転送およびデータベースのインポートより高速です。
異なるエンディアン形式のプラットフォームにデータベースを移行する場合、ネットワーク・インポート時間が許容範囲内であれば、データ・ポンプを使用してください。
|
関連項目:
|
トランスポータブル表領域は、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、プラットフォーム移行を実行します。トランスポータブル表領域は、Oracle GoldenGateでサポートされないデータ型をデータベースで使用しており、ユーザー・スキーマが単純な場合に使用します。
プラットフォーム移行の実行にトランスポータブル表領域が適切な方法であるかどうかを決定する場合、次の点を考慮してください。
SYSTEM表領域は、トランスポータブル表領域で移動できません。ユーザー定義やクライアントに必要なオブジェクトを含むターゲット・データベースのSYSTEM表領域の内容は、手動で構築する必要があります。SYSTEM表領域の必要な内容を移動する場合、データ・ポンプを使用します。
トランスポータブル表領域を使用したプラットフォーム移行またはデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
ソース・データベースの表領域を読取り専用モードにする時間。
トランスポータブル・メタデータのネットワーク・インポートを実行する時間。
すべてのデータファイルをソース・システムからターゲット・システムに転送する時間。
この時間を大幅に短縮するには、ファイルを物理的に移動することなくターゲット・システムでデータファイルを利用可能にするストレージ・インフラストラクチャを使用します。
RMANを使用してすべてのデータファイルを新規プラットフォームの形式に変換する時間
Oracle Data Pumpがメンテナンス・ウィンドウ内に完了せず、データ型の制限からOracle GoldenGateまたはData Guard SQL Applyを使用できない場合は、プラットフォームへの移行にトランスポータブル表領域を使用してください。
|
関連項目: トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Data Guard REDO Applyを使用すると、一時スタンバイ・データベースをリモートの場所に設定してスイッチオーバー操作を実行することで、最小限の停止時間でデータベースの場所をリモート・サイトに変更できます。
Data Guard REDO Applyを使用したロケーション移行に必要な停止時間は、スイッチオーバー操作を実行する時間によって決定されます。
|
関連項目: REDO Applyとフィジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
エディションベースの再定義を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。
アプリケーションを使用中にアップグレードするには、アプリケーションを構成するデータベース・オブジェクトをコピーし、コピーしたオブジェクトを個別に再定義します。アプリケーションのユーザーは、この変更による影響を受けず、変更されていないアプリケーションを引き続き実行します。変更内容が正しいことを確認したら、アップグレードしたアプリケーションをすべてのユーザーが使用できるようにします。
順調な場合は、ロールオーバーが可能です。アップグレード前とアップグレード後のエディションは同時に使用できるため、アップグレード後のエディションの公開前に開始されたセッションは、自然に終了するまで、引き続きアップグレード前のエディションを使用することができ、新しいセッションではアップグレード後のエディションが使用されます。順調でない場合は、アップグレード前のセッションをすべて終了させないと、新しいセッションでアップグレード後のエディションを使用できません。そのような場合、アプリケーションは少しの間停止することになります。
|
関連項目:
|
アプリケーションのアップグレードには、データベースのアップグレードに加えて、必要なアプリケーション・コードとスキーマの変更が含まれることがあります。データベースまたはアプリケーション・アップグレードの実行時に停止時間をゼロまたは最小限にする必要がある場合は、Oracle GoldenGateを使用して、わずかな停止時間または停止時間なしでデータベース・アップグレードを実行できます。Oracle GoldenGateは、継続的なシステム可用性を提供し、計画済の停止を排除して、中断のないビジネス操作を可能にします。
|
関連項目: 『Oracle GoldenGate Windows and UNIX管理者ガイド』 |
データ・サーバーに関連する多くの計画済の停止には、データベース・オブジェクトの再編成が伴います。Oracle Databaseのオンライン再編成および再定義機能を使用すると、基礎となるデータが変更されている間でも、データ再編成を実行することができます。この機能により、ユーザーがデータベースに完全にアクセスできる状態でデータ再編成操作が可能になるため、可用性と管理性が拡張されます。
高可用性システムでは、問合せやDMLのパフォーマンスを向上するために、頻繁にアクセスされる大規模な表を定期的に再定義する必要があります。オンライン再編成および再定義機能を使用すると、管理者は、ユーザーによるデータベースへの完全なアクセスを維持しながら、表の物理属性を変更し、データと表構造の両方を変換できる柔軟性を手にできます。この機能により、ミッション・クリティカルな環境で重要となるデータ可用性、問合せパフォーマンス、レスポンス時間およびディスク領域使用率が向上します。また、オンライン再編成および再定義機能により、アプリケーション・アップグレード・プロセスは、より簡単、安全、迅速になります。
推奨されるベスト・プラクティスは、DBMS_REDEFINITION PL/SQLパッケージを使用して表を再編成することです。これにより、表をオフラインにする必要のある従来の表の再定義メソッドに比べて可用性が大幅に向上します。DBMS_REDEFINITIONをコマンドラインで手動で呼び出すか、Oracle Enterprise Managerのオブジェクトの再編成ウィザードを使用するかにかかわらず、再編成プロセス全体は、ユーザーが表への完全なアクセス権を持つときに行われるため、システムの可用性が確保されます。
図14-2に、SQL*PlusコマンドラインでDBMS_REDEFINITIONパッケージを呼び出すかわりに使用できるOracle Enterprise Managerのオブジェクトの再編成ウィザードのページを示します。ウィザードでいくつかの質問に答えると、スクリプトが生成され、再編成が実行されます。
図14-2 Oracle Enterprise Managerを使用したデータベース・オブジェクトの再編成
データの再編成を実行する場合は、次のことを考慮してください。
オンライン操作中の表における同時アクティビティを最小化します。
オンライン操作中は、実表でのユーザー・アクティビティを最小化することをお薦めします。オンライン操作中のデータベース・アクティビティによる影響は、表の10%未満とする必要があります。データベース管理者は、データベース・リソース・マネージャを使用してユーザーに十分なリソースを割り当てることで、データ再編成の影響を最小限に抑えることができます。
ピーク期間中にオンライン操作を実行することや、データのオンライン再編成中に大容量のデータ変更を伴うバッチ・ジョブを実行することは避けてください。
オンラインで索引を再構築する方法と、索引を削除してからオンラインで索引を再作成する方法の比較。
オンラインで索引を再構築する場合、操作中に新規索引用の追加ディスク領域が必要です。一方、索引を削除して再作成する場合、追加ディスク領域は必要ありません。
オンライン索引結合とオンライン索引再構築の比較。
オンライン索引結合は、インプレースのデータ再編成操作であるため、索引を再構築する場合のような追加ディスク領域は必要ありません。索引の再構築では、索引とソート領域の合計サイズに等しい一時ディスク領域が操作中に必要です。オンライン索引結合では、Bツリーの高さは減少しません。この場合、リーフ・ブロック数の削減が試行されるのみです。結合操作では、ユーザー用の領域は解放されませんが、索引スキャンのパフォーマンスは向上します。
索引を新規表領域に移動する必要がある場合は、オンライン索引再構築を使用してください。
ローカル索引およびグローバル索引のオンライン・メンテナンスの実行。
Oracle Database 11gでは、オンライン操作でローカル・パーティション索引とグローバル・パーティション索引の両方がサポートされます。表および索引がパーティション化されている場合、管理者は、一度に1つのパーティションを対象にこれらのオブジェクトのメンテナンスを実行することで、他のパーティションをオンラインのまま維持できます。
|
関連項目:
|
インスタンス、ノード、またはその他のコンポーネントを分離する必要のある計画済の停止では、サービスを再配置、無効化および有効化するOracle RACの機能を使用できます。再配置機能では、サービスを別のインスタンスに移行できます。サービスとインスタンスは、ハードウェアまたはシステム・ソフトウェアでの修復、変更、アップグレードの実行中に選択的に無効化し、メンテナンスの完了後に再有効化することが可能です。これにより、メンテナンスによる停止中はサービスまたはインスタンスが起動しないことが保証されます。サービスとインスタンスは、計画済の停止の開始時に無効化します。その後、メンテナンスによる停止の後に有効化します。
Oracle RACを使用している場合、ノードの開始時にOracleクラスタウェア・デーモンが自動的に起動します。1つ以上のシステムの再起動や、オペレーティング・システム以外のすべてのプロセスの停止が必要なメンテナンスの実行時には、crsctlコマンドを使用してOracle Clusterwareデーモンの起動を停止および無効化します。メンテナンスが完了したら、crsctlコマンドでOracleクラスタウェア・デーモンを有効化して起動します。
|
関連項目:
|
