| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
この章では、計画済の停止について説明します。また、各停止タイプを許容するか管理することで停止時間を最小化できるOracle運用ベスト・プラクティスについて説明します。
この章には、次の項目が含まれます。
計画済の停止は、アプリケーションをサポートするテクノロジ・インフラストラクチャの定期メンテナンスのために必要です。これには、次のタスクが含まれます。
ハードウェアのメンテナンス、修復およびアップグレード
ソフトウェアのアップグレードとパッチ適用
アプリケーションの(プログラム的な)変更、パッチおよびアップグレード
システムのパフォーマンスと管理性を向上するための変更
これらの作業の多くは、アプリケーションの可用性を連続的に維持したまま、実装することができます。
次の各項では、プライマリ・サイトとセカンダリ・サイトでの計画済の停止を削減するための推奨ベスト・プラクティスについて説明します。
表13-1に、プライマリ・サイトで計画済の停止を実行するための適切なソリューションを示します。この表には、13.2項「計画済の停止による停止時間の回避または短縮」の詳細な説明へのリンクが含まれます。
表13-1 プライマリ・サイトでの計画済の停止のソリューション
| 計画メンテナンス | 説明および例 | 優先されるOracleソリューション | 停止時間見積り |
|---|---|---|---|
|
サイト・メンテナンス |
プライマリ・データベースが現在使用不能になっているサイト全体で実行されるメンテナンスです。通常は、事前に広く通知されます。
|
13.2.1項 「Data Guardスイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス」 |
5分未満 |
|
データベース・クラスタ全体に影響するハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス |
データベース・サーバー・クラスタでのハードウェア・メンテナンスです。
|
13.2.1項 「Data Guardスイッチオーバーを使用したサイト、ハードウェアおよびソフトウェアのメンテナンス」 |
5分未満 |
|
データベース・クラスタのサブセットに影響するハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンス |
データベース・サーバーでのハードウェア・メンテナンスまたはシステム・ソフトウェア・メンテナンスです。停止時間の範囲は、データベース・クラスタの1つのノードに制限されます。
|
Oracle RACサービスの再配置(13.2.12項「システム・メンテナンスのための動的データベース・サービス」を参照) |
停止時間なし |
|
Oracle Grid Infrastructureへのパッチ・セット、メンテナンスまたはメジャー・アップグレードの実行(Oracle ClusterwareとOracle ASMを含む) |
Grid Infrastructureのソフトウェア・メンテナンスです。
|
詳細は、『Oracle Database 2日でReal Application Clustersガイド』、およびプラットフォーム固有の『Oracle Grid Infrastructureインストレーション・ガイド』のOracle Grid Infrastructureのアップグレード方法に関する付録を参照してください。 |
停止時間なし(ロール移行がない場合) 5分未満(ロール移行が行われる場合) |
|
Oracle Databaseへのパッチ・セット、メンテナンスまたはメジャー・アップグレードの実行 |
Oracle Databaseのソフトウェア・メンテナンスです。
|
|
5分未満 |
|
パッチ・セット更新(PSU)、クリティカル・パッチ・アップデート(CPU)またはパッチ・バンドルの適用 |
Grid InfrastructureまたはOracle Databaseのソフトウェア・メンテナンスです。
|
|
停止時間なし 停止時間なし(ロール移行がない場合、または |
|
Oracle個別パッチまたは診断パッチの適用 |
特定の顧客問題を修正するためのOracleソフトウェアへのパッチ適用。
|
|
停止時間なし 停止時間なし(ロール移行がないか、ロール移行が行われる場合は5分未満の場合) 停止時間なし |
|
データベース・オブジェクトの再編成または再定義 |
主にパフォーマンスや管理性を向上する目的で、Oracleデータベース・オブジェクトの論理構造または物理編成を変更します。 データまたはスキーマの変更です。 Oracleデータベースのオンライン再定義機能を使用すると、再編成または再定義中にオブジェクトを使用できます。
|
|
停止時間なし |
|
データベース・ストレージ・メンテナンス |
データベース・ファイルが存在するストレージのメンテナンスです。
|
Oracle ASMを使用したオンライン・ストレージ・メンテナンス(13.2.6項「ストレージ・メンテナンス」を参照) |
停止時間なし |
|
データベースのプラットフォームまたはロケーションの移行 |
プライマリ・データベースとスタンバイ・データベースのオペレーティング・システム・プラットフォームを変更します。 プライマリ・データベースの物理的な場所を変更します。
|
13.2.8項「データベースのプラットフォームまたはロケーションの移行」 |
5分未満から数時間 (選択した方法に依存) |
|
アプリケーションの変更 |
データ変更、スキーマおよびその他のプログラム的な変更が含まれます。
|
5分未満 |
セカンダリ・サイトの計画済の停止は、Active Data Guardを使用して読取り中心の作業をプライマリ・データベースからオフロードするアプリケーションの可用性に影響することがあります。セカンダリ・サイトで停止が発生したときにプライマリ・サイトで同時障害が発生すると、RTOおよびRPOに影響する可能性があります。セカンダリ・サイトの停止は、プライマリ・データベースの可用性に影響を与えずに管理できます。
最大保護データベース・モードで構成しており、プライマリ・データベースを保護するスタンバイ・データベースが1つのみの場合、プライマリ・データベースで停止時間が発生しないように、スタンバイ・インスタンスまたはデータベースで計画済の停止を実行する前に保護モードをダウングレードする必要があります。
最大保護データベース・モードで構成されていて、複数のスタンバイ・データベースが存在する場合、LGWR SYNC AFFIRM属性で構成された1つ以上のスタンバイ・データベースが利用でき、それプライマリ・データベースがREDOデータを転送できるかぎり、保護モードをダウングレードする必要はありません。
セカンダリ・サイトのメンテナンスをスケジュールする場合、サイト全体またはクラスタ全体の停止期間が増加するほどスタンバイ・データベースとプライマリ・データベースの差異が拡大し、それによりフォルト・トレランスを回復するための時間も増加することに注意してください。Data Guard保護モードの概要は、8.2項「保護モードとData Guardトランスポートの決定」を参照してください。
表13-2に、セカンダリ・サイトで計画済の停止を実行するための手順をまとめます。
表13-2 セカンダリ・サイトでの計画済の停止の管理
| 計画メンテナンス | Data Guardを使用したOracle Database 11g | Oracle Database 11g(MAA) |
|---|---|---|
|
サイト停止 |
停止前: 停止後: 12.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」 |
停止前: 停止後: 12.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」 |
|
管理リカバリ・プロセス(MRP)を実行しているノードでのハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス |
停止前: |
停止前: |
|
MRPを実行していないノードでのハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス |
適用なし |
プライマリ・スタンバイ・ノードまたはインスタンスは、管理リカバリ・プロセスで適用されるREDOログを受信するため、影響はありません。 停止後: 使用可能になったら、ノードとインスタンスを再起動します。 |
|
ハードウェアまたはOracle以外のデータベース・ソフトウェアのメンテナンス(クラスタ全体に影響) |
適用なし |
停止前: 停止後: 12.3.4項「セカンダリ・サイトまたはクラスタでの計画済の停止後またはクラスタ全体の停止後のフォルト・トレランスのリストア」 |
|
Oracleパッチとソフトウェアのアップグレード |
アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。 |
アップグレードのために停止時間が必要ですが、構成が最大保護データベース・モードでないかぎり、プライマリ・ノードに影響はありません。 |
計画済の停止の停止時間を回避または短縮するためのベスト・プラクティスには、次の項があります。
システムへの更新を実行する前に、入念なテストを実行することをお薦めします。
スイッチオーバーは、プライマリ・データベースとスタンバイ・データベース間のデータベース・ロールを切り替える一連の手順を含む計画済の移行です。スイッチオーバー操作に成功すると、スタンバイ・データベースがプライマリ・ロールを引き継ぎ、プライマリ・データベースがスタンバイ・データベースとなります。データベース・スイッチオーバーは、Oracle Enterprise ManagerまたはOracle Data Guardブローカによって、あるいはSQL*Plus文を発行することで実行できます。データベース・ロール管理のスコープでは、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にスタンバイ・データベースを元のロールに戻す操作です。
スイッチオーバーは、サイト・メンテナンス、およびハードウェアやソフトウェアのメンテナンス(Grid Infrastructureのアップグレードなど)を実行するとき、多くの状況で便利です。
プライマリ・データベースが起動しており、ターゲット・スタンバイ・データベースが使用可能で、すべてのアーカイブREDOログが使用できる場合、いつでもスイッチオーバーを実行できます。
スイッチオーバーは、次のような状況で役立ちます。
計画されたメンテナンス(プライマリ・ホストでのハードウェア・メンテナンスやファームウェア・パッチ適用など)
プライマリ・データベースをオープンしたままでのデータ障害の解決
セカンダリ・リソースのテストと検証(障害時リカバリの準備状況をテストする手段として)
SQL Applyを使用したローリング・アップグレードの実行(13.2.7.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」を参照)
スイッチオーバーは、次の場合には使用できないか、または効果がありません。
適用に必要なアーカイブREDOログ・ファイルがない場合
ポイント・イン・タイム・リカバリが必要な場合
プライマリ・データベースがオープンしておらず、オープンできない場合
スイッチオーバーを実行する前に、Data Guard構成のベスト・プラクティスを採用します。詳細は、8.5.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スイッチオーバーの実行後に、次の操作を行います。
データベースがセカンダリ・サイトに移動され、アプリケーション層もセカンダリ・サイトに移動される場合は、完全サイト・フェイルオーバーを実行します。詳細は、12.2.1項「サイト・フェイルオーバーの完了(セカンダリ・サイトへのフェイルオーバー)」を参照してください。
データベースのみがセカンダリ・サイトに移動される場合は、アプリケーション・フェイルオーバーを実行します。詳細は、12.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パッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるデータベース・ホーム・ソフトウェアをサポートします。
Data Guardは、プライマリ・システムとスタンバイ・システム間で異なる構成の実行を長期にわたりサポートしてきました。これには、次のサポートが含まれています。
ハードウェアの違い(たとえば、X3 Exadata Database MachineとX4 Exadata Database Machine)
オペレーティング・システムの違い(たとえば、Oracle Linux 5.7とOracle Linux 5.8)
データベース・ストレージの違い(たとえば、Oracle ASMベースのストレージとNFSベースのストレージ、Exadata 11.2とExadata 12.1)
Oracle Clusterwareのバージョンおよびパッチ・レベルの違い(たとえば、11.2.0.3 GIPSU4と11.2.0.3 GIPSU5)
しかし、データベース・ホーム・ソフトウェアの違いは、ロジカル・スタンバイ・データベースによってのみサポートされるローリング・アップグレードのシナリオに限定されていました。それより後のデータベース・ホーム・パッチ(Exadataバンドル・パッチやデータベースPSUなど)をフィジカル・スタンバイを備えたData Guard環境に適用するために、次のアクションのいずれかを実行する必要がありました。
プライマリ・データベースとスタンバイ・データベースの両方を停止し、両システムに更新を適用してから再起動する、または
フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換し、ローリング・アップグレード・プロセスを使用して更新を適用してから、スタンバイ・データベースを変換してフィジカル・スタンバイに戻す(一時ロジカル・スタンバイと呼ばれる機能)。
Data Guard Standby-First Patchの適用を使用すると、前述の違いに加えて、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるデータベース・ホーム・ソフトウェアがサポートされます。
Oracle Data Guard Standby-First Patchの適用は、プライマリ・データベースへのリスクが最小限のローリング方式でOracleパッチとパッチ・バンドルを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるデータベース・ホーム・ソフトウェアをサポートします。たとえば、Data Guard Standby-First Patchの適用を使用して、最初にデータベース・ホーム・パッチをフィジカル・スタンバイ・データベースに適用します。パッチをテストして評価するために、そのスタンバイを使用して読取り専用ワークロードまたは、スナップショット・スタンバイの場合は読取り/書込みワークロードを実行します。評価を通ると、データベース・ホーム・パッチの有効性と安定性の保証が強くなるので、パッチをプライマリ・システムにインストールします。
Oracle Data Guard Standby-First Patchの適用は、Oracle Engineered Systems (Exadata、SuperClusterなど)とEngineered Systems以外の両方で、Oracle Database 11.2.0.1以降の認定された個別パッチおよびパッチ・バンドル(Exadataに対するパッチ・セット更新やデータベース・パッチなど)に対してのみサポートされます。Data Guard Standby-Firstによって認定されたパッチおよびパッチ・バンドルは、パッチのREADMEで次のように提示しています。
Data Guard Standby-Firstでインストール可能
次のタイプのパッチは、Data Guard Standby-Firstによって認定される候補です。
データベース・ホームの個別パッチ
Exadataのバンドル・パッチ(Exadataの月および半期ごとのデータベース・パッチ)
データベースのパッチ・セット更新
|
注意: 異なるデータベース・ホーム・ソフトウェアを実行しているプライマリ・システムとフィジカル・スタンバイ・システム間の相互運用性を破壊する可能性があるモジュールを更新するパッチおよびパッチ・バンドルは、"Data Guard Standby-Firstでインストール可能"と認定されず、パッチのREADMEにそのように提示していません。 |
Oracleパッチ・セットおよびメジャー・リリース・アップグレードは、Data Guard Standby-First Patchの適用の対象にはなりません。たとえば、11.2.0.2から11.2.0.3へのアップグレードや11.2から12.1へのアップグレードは対象外です。データベース・パッチ・セットおよびメジャー・リリースには、Data Guard一時ロジカル・スタンバイ・ローリング・アップグレード・プロセスを使用します。
概要に関する項で前述した、すでにサポートされているプライマリ・システムとスタンバイ・システム間の他の構成の違いは、引き続きサポートされます。
Data Guard Standby-First Patchの適用のメリットは、次のとおりです。
ロール移行の前、またはプライマリ・データベースへの適用前に、リカバリ、バックアップまたは問合せ検証のためにフィジカル・スタンバイ・データベースにソフトウェア変更を適用する機能。これにより、プライマリ・データベースでのリスクと発生する可能性がある停止時間が軽減されます。
リスクを軽減し、停止時間を最小限に抑えて検証を完了した後で、ターゲット・データベースにスイッチオーバーする機能。
安定性やパフォーマンスが低下している場合に、スイッチバック(フォールバックとも呼ぶ)を行う機能。
|
関連項目:
|
Oracle RACを使用すると、特定のデータベース・パッチおよびグリッド・インフラストラクチャ・パッチを一度に1つのノードまたはインスタンスに適用して、アプリケーションおよびデータベースの継続的な可用性を維持することができます。データベース・ソフトウェアに個別パッチ、パッチ・セット更新(PSU)およびクリティカル・パッチ・アップデート(CPU)を適用するのは、通常、インストール環境で発生したソフトウェア問題の既知の修正策を実装する場合か、問題に関する情報を収集するための診断パッチを適用する場合です。このようなパッチ適用は、一般的に、計画された停止期間中のメンテナンスで実行されます。
Oracleでは、データベースをまったく停止しないか、最小限の停止時間でOracle RACのローリング・パッチ・アップグレードを実行できます。この操作を行うためのツールは、opatchコマンドライン・ユーティリティです。
Oracle RACローリング・パッチ・インストールのメリットは、パッチ・アップグレードに必要とされる計画済の停止期間中でも、Oracle RACインストール環境の一部のインスタンスを使用できることです。停止する必要があるのは、現在パッチを適用中のOracle RACインスタンスのみです。その他のインスタンスは、引き続き使用できます。これにより、このような計画済の停止に必要とされるアプリケーションの停止時間に対する影響を最小限に抑えることができます。Oracleのopatchユーティリティでは、Oracle RACインストール環境の異なるインスタンスに対して連続的にパッチを適用できます。
ローリング・パッチ・インストールは、オラクル社でローリング・アップグレードに適切であると認定されたパッチでのみ使用できます。パッチのREADMEファイルは、パッチをOracle RACローリング方式で適用できるかどうかを示します。一般に、ローリング方式でインストール可能なパッチは次のとおりです。
Exadata Databaseバンドル・パッチ
パッチ・セット更新(PSU)
クリティカル・パッチ・アップデート(CPU)
個別パッチ
診断パッチ
ローリング・パッチ・インストールは、Oracle Databaseソフトウェアが異なるノード間で共有されるデプロイメントでは使用できません。これに該当するのは、クラスタ・ファイル・システム(CFS)上、またはファイル・サーバーやNFSマウント・ドライブにより提供される共有ボリューム上にOracleホームが存在する場合です。この機能を使用できるのは、各ノードがOracleデータベース・ソフトウェアの独自のコピーを所有している場合のみです。
|
関連項目: パッチ・セット・アップグレードおよびリリース・アップグレードは、13.2.5項「Grid Infrastructureのアップグレード」および13.2.7項「データベースのアップグレード」を参照してください。 |
すべてのデータベース・パッチ・インストールで、次の推奨プラクティスを使用します。
Oracleサポート・サービスに連絡して、パッチが現在の問題とデプロイメント環境に有効であることを必ず確認します。
パッチを適用する計画とともに、パッチをバック・アウトする計画を作成します。
パッチは先にテスト環境に適用し、問題が修正されることを確認します。
パッチを適用する際の所要時間を見積もる場合、必要に応じてテクノロジ・スタックの他の層を起動および停止する時間も含めます。
パッチがOracle RACローリング・パッチ・インストールに適しておらず、パッチの適用時に停止時間が発生する可能性がある場合、13.2.7項「データベースのアップグレード」を参照して他の解決方法を実行できないかどうかを検討します。
次に、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を使用する場合には適用されません。詳細は、13.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ディスク・グループに追加すると仮定します。
非ASMストレージにデータベース・ファイルを格納する既存のOracleデータベースがある場合、そのデータベース・ファイルの一部または全部をOracle ASMに移行できます。ASMストレージへのデータベースの移行には、データファイル、REDOログ・ファイルおよび制御ファイルをASMに移動する必要があります。
データファイル
ALTER DATABASE MOVE DATAFILE SQL文を使用して、オンライン・データファイルを再配置できます。この文を使用すると、データベースがオープン状態でユーザーがデータファイルにアクセスしている間に、データファイルをASMストレージに再配置できます。
REDOログ・ファイル
ALTER DATABASE DROP LOGFILE GROUP SQL文を使用して非アクティブなREDOログ・ファイルを非ASMストレージから削除し、ALTER DATABASE ADD LOGFILE SQL文を使用してREDOログ・ファイルをASMストレージに追加します。
制御ファイル
制御ファイルをASMストレージに移行するには、データベースを停止し、Recovery Manager (RMAN)またはASMCMD使用して既存の制御ファイルをASMにコピーし、新しい場所を参照するようにデータベース初期化パラメータCONTROL_FILESを編集してからデータベースを起動します。
|
関連項目: 『Oracle Database管理者ガイド』 |
Oracle ASMへのディスクの追加および削除は停止時間なしで実行できます。ディスクが追加または削除されると、Oracle ASMではリバランス操作が自動的に開始され、ディスク・グループのコンテンツがディスク・グループのすべてのドライブに均等に分割されます。ストレージの追加または削除のベスト・プラクティスは次のとおりです。
Oracle ASMを使用してストレージの追加や削除を行う前に、ホスト・オペレーティング・システムとストレージ・ハードウェアが、停止時間なしでのストレージの追加や削除をサポートしていることを確認します。
複数のディスク・ドライブを追加または削除するときに単一のALTER DISKGROUPコマンドを使用します(この方法ではリバランス操作は1つのみですが、個々の削除と追加では2つ以上のリバランス操作があります。詳細は、3.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機能を使用できます。
データベース・アップグレードの実行方法は、次のことを考慮したうえで選択します。
アップグレードを完了するのに必要な停止時間
停止時間の前に必要な設定時間および作業
一時的に必要となる追加リソース(ディスク領域やCPUなど)
アップグレードを完了するのに許容される手順の複雑さ
表13-3に、データベース・アップグレードに使用できる方法と、特定のケースでその方法の使用が推奨される場合についてリストします。
表13-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を使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
すべてのデータベース・ディクショナリ・オブジェクトを新しいバージョンにアップグレードする。アップグレードは、パラレル・アップグレード・ユーティリティ(catctl.pl)を使用して同時に実行されるようになっています。
アップグレード完了後に、すべての無効なPL/SQLモジュールを再コンパイルします。再コンパイルを同時に実行すると、アップグレード時間を短縮できます。
データベースの再起動
アップグレードしたデータベースにクライアントを再接続する時間
DBUAの使用時にデータベース・アップグレードに必要とされる停止時間を短縮するには、次のようにします。
アップグレード並列度および並列度を使用して、無効なPL/SQLモジュールを再コンパイルします。
使用されていないデータベース・オプションをすべて削除します。
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スイッチオーバーを実行する時間
新規データベースにクライアントを再接続する時間
Oracle Database 12cリリース1 (12.1)の最初のパッチ・セットで開始しているデータベースで、既存のフィジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行するために優先される方法は、DBMS_ROLLING PL/SQLパッケージを使用する方法です。『Oracle Data Guard概要および管理』を参照してください。
|
関連項目:
|
一時ロジカル・スタンバイ・データベースを使用して、現在のフィジカル・スタンバイ・データベースを一時的にロジカル・スタンバイ・データベースに変換することにより、そのフィジカル・スタンバイ・データベースを使用してデータベースのローリング・アップグレードを実行できます。フィジカル・スタンバイ・データベースが1つのみの構成の場合は、一時ロジカル・スタンバイを使用します。一時ロジカル・スタンバイを使用したローリング・アップグレードの実行は、標準SQL Applyローリング・アップグレードと似ていますが、次の点が異なります。
保証付きリストア・ポイントがプライマリ・データベース上に作成され、スイッチオーバーの後、データベースをフィジカル・スタンバイ・データベースにフラッシュバックします。
フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換では、KEEP IDENTITY句を使用して、プライマリ・データベースと同じDB_NAMEおよびDBIDを保持します。
ALTER DATABASE CONVERT TO PHYSICAL STANDBY文が、元のプライマリ・データベースを、ロジカル・スタンバイからフィジカル・スタンバイ・データベースに変換します。
元のプライマリ・データベースは、一時ロジカル・スタンバイ・データベース・ロールからフィジカル・スタンバイ・データベースに変換された後で、REDO Applyを使用して実際にアップグレードされます。
Oracle Database 12cリリース1 (12.1)の最初のパッチ・セットで開始しているデータベースで、既存のフィジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行するために優先される方法は、DBMS_ROLLING PL/SQLパッケージを使用する方法です。『Oracle Data Guard概要および管理』を参照してください。
図13-1に、一時ロジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行するときに発生する処理のフローを示します。
|
注意: 図13-1に示す操作を簡略化するために、データベースのローリング・アップグレード手順を自動化するBourneシェル・スクリプトを使用できます(Oracle Database 11gリリース1以降)。データベースのローリング・アップグレードは、既存のData Guardフィジカル・スタンバイ・データベースおよび一時的なロジカル・スタンバイ・ローリング・アップグレード・プロセスを使用して実行されます。次の場所にあるMy Oracle Supportのノート949322.1の『Oracle 11g Data Guard: Database Rolling Upgrade Shell Script』で詳細に説明されている、physruという名前のBourneシェル・スクリプトをダウンロードできます。
|
図13-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の使用率が自然に縮小されます。マルチマスター・レプリケーションは、この移行フェーズ中に両方のデータベースの同期を保ちます。すべてのユーザーが新しいリリースに移行した後、単純な一方向レプリケーションは以前のデータベース・リリースの同期を維持して、前の箇条書き項目で説明したように高速フォールバック・オプションを提供できます。マルチマスター・レプリケーションは、すべてのアプリケーションに適しているわけではありません。競合の検出と解決が必要です。
データベースのアップグレードに13.2.7.2項「Data Guard SQL Applyまたは一時ロジカル・スタンバイ・データベースを使用したアップグレード」で説明した手順を使用できず、データベースまたはアプリケーションのアップグレードの際の停止時間を0 (ゼロ)にするか最小限に抑える必要がある場合は、Oracle GoldenGateを構成してデータベース・アップグレードを実行することで、停止時間を0 (ゼロ)または最小限に抑えることができます。詳細は、次の場所にあるホワイト・ペーパー『Zero-Downtime Database Upgrades Using Oracle GoldenGate』を参照してください。
|
関連項目: Oracle GoldenGateを使用したデータベース・アップグレードの詳細は、『Oracle GoldenGate Windows and UNIX管理者ガイド』を参照してください。 |
データのトランスポートを使用したデータベース・アップグレードに必要な停止時間は、次の操作に要する時間によって決定されます。
ソース・データベース・ユーザーの表領域を読取り専用モードにする時間。
トランスポータブル・メタデータおよび非トランスポータブル・データのデータ・ダンプ・インポートを実行する時間。
ソース・データベースのデータファイルをアップグレードしたターゲット・データベースで使用可能にする時間。理想的には、データファイルを現在の場所で使用します。
データのトランスポートを使用したデータベース・アップグレードの実行は、次の場合に推奨されます。
トランスポート・プロセスの一環としてデータファイルをコピーせずに、現在の場所でデータファイルを使用できる場合。ターゲット・データベースが異なるマシン上に存在する場合、ソース・システムとターゲット・システムの両方からそのストレージにアクセスできる必要があります。
DBUAがメンテナンス・ウィンドウ内に完了しない場合。
データ型の制限によりOracle GoldenGateまたはData Guard SQL Applyを使用できない場合。
フル・トランスポータブル・エクスポート/インポートを使用すると、データベースをOracle Database 11gリリース2 (11.2.0.3)以降からOracle Database 12cにアップグレードできます。そのためには、Oracle Database 12cをインストールし、空のデータベースを作成します。次に、フル・トランスポータブル・エクスポート/インポートを使用して、Oracle Database 11gリリース2 (11.2.0.3)データベースをOracle Database 12cデータベースにトランスポートします。
『Oracle Database管理者ガイド』を参照してください。
ソース・データベースがOracle Database 11gリリース2 (11.2.0.2)以前の場合、トランスポータブル表領域を使用すると、すべてのユーザー・データファイルを事前に作成および準備されたターゲット・データベースにトランスポートすることで、データベース・アップグレードを実行できます。次のことに注意してください。
SYSTEM表領域は、トランスポータブル表領域を使用しても移動できません。ユーザー定義やアプリケーションに必要なオブジェクトを含むターゲット・データベースのSYSTEM表領域の内容は、手動で構築する必要があります。SYSTEM表領域の内容を移動する場合、データ・ポンプを使用します。
|
関連項目:
|
データベースの移行を実行する場合、主要な目標は、既存のソース・システムから最新リリースを実行している新しいOracleデータベースにデータを移動することです。データの移行は、データ・ポンプ、トランスポータブル表領域、Oracle Data Guard、Oracle GoldenGateなどのツールで実行できます。ただし、移行中は、移行計画の目標となる2つの同等の重要度の項目に対処する必要があります。
簡略化: 移行中に、実装を簡略化します。様々なバージョンと様々なDBAによって進化してきたほとんどのデータベース環境には、古い情報が含まれます(また、現在のDBAはシステムで何かが使用されている理由について疑問を持つ場合があります)。簡略化の目的は、管理者が作業を高い信頼性で簡単に行えるようにすることです。この簡略化により、システムの可用性が高まります。
最適化: 移行中に、実装を最適化できます。多くの場合、移行には更新されたデータベース・バージョンが含まれるため、新しい機能が使用可能です。移行の実行中に、新しい機能とプラクティスの採用を検討する必要があります。
移行計画に次の手順を追加して、簡略化と最適化を行います。
移行方針を策定する場合の最初の手順は、新しいターゲット環境について理解し、ソース・システムからターゲット・システムにデータを物理的に移動する方法を決定することです。ターゲット環境の中心はOracle Databaseです。他のOracleデータベース・アップグレードや移行と同様に、『Oracle Databaseアップグレード・ガイド』とMy Oracle SupportにあるUpgrade Companionのドキュメントに記載されているガイドラインおよび推奨事項に従う必要があります。Oracle Upgrade Companions (ドキュメントID 1905086.1)を参照してください。
移行中にinit.oraを更新します。
既存のinit.oraファイルで、重要でなくなったと思われるパラメータを削除します。パラメータをデフォルト設定から変更する場合は、変更の妥当性を確認します。たとえば、以前のリリースで見つかった問題を回避するため(たとえば、以前のリリースで解決したオプティマイザの問題を処理するため)に設定されたアンダースコア・パラメータは削除できます。
移行中にSQLを更新します。
オプティマイザで目的の計画を強制的に生成するために挿入された、以前のOracle Databaseバージョンに追加されたSQLヒントを削除します。オプティマイザは一般に、適切な統計が提供されていれば、ヒントの必要なしに適切な実行計画を作成します。
移行中にスキーマ・オブジェクトを簡略化または変更します。
移行中に行えるスキーマ・レイアウトの変更があるかどうかを検討する必要があります。たとえば、次の場合を考えます。
大きな表のパーティション化スキームの変更
Oracle Exadataデータベース・マシンに移行する場合に、ハイブリッド列圧縮(HCC)などの新規に使用可能な圧縮機能の採用(詳細は、『Oracle Database概要』を参照)
暗号ハードウェア・アクセラレーションを提供するシステムに移行する場合には特に、透過的データ暗号化(TDE)の採用
また、索引の過剰な使用など、移行するべきでないオブジェクトがあるかどうかを判断します。データベースのスキーマ・オブジェクトを変更または削減する場合は、現在の形式でデータベースを移行し、移行後に変更を実行する方がよいか、または移行中に選択的に行う方がよいかを検討する必要があります。
使用していない表領域とデータファイルを移行中に削除します。
使用していないまたは不要な表領域とデータファイルを移行中に削除できるかどうかを検討する必要があります。表領域とデータファイルが少ない方が、管理性とパフォーマンスが向上します。
ターゲット・バージョンと一致するようにソース・データベースをアップグレードすることを検討します。これにより、(場合によっては大幅に)移行が向上します。たとえば、データ・ポンプのパラレル機能は新しいOracle Databaseリリースそれぞれで継続的に拡張されるため、ターゲット・バージョンと一致するようにソース・データベースをアップグレードした場合は、ソース・システムからのデータベース・エクスポートが向上し、完了までの時間が短くなります。
移行の前に、ソース・データベース内の不要なスキーマ・オブジェクトの削除を検討します。これにより、移行する必要のあるデータ量が削減されます。
ビジネス・ニーズと停止時間の要件を判断および検討します。必要な停止時間の長さに影響する要因について、13.2.8.3項「プラットフォームの移行とアップグレードに関するOracleの機能」でプラットフォームの移行に関するOracle機能を参照してください。
移行を段階的に実行するための要件または可能性があるかどうかを検討します。たとえば、ソース・データベースに大量の読取り専用データがある場合は、ライブ・データ移行の前に移行して停止時間を短縮できます。
プラットフォームの移行作業には、大量のテストが含まれます。
プラットフォーム移行とアップグレードを実行する場合、次のOracle機能を使用できます。
これらのデータベース・メンテナンス・タスクの実行方法は、次のことを考慮したうえで選択します。
メンテナンス操作を完了するのに必要な停止時間
停止時間の前に必要な設定時間および作業
一時的に必要となる追加リソースの量(ディスク領域やCPUなど)
メンテナンス操作を完了するのに許容される手順の複雑さ
表13-4に、プラットフォーム移行およびデータベース・アップグレードに使用できる方法と、操作ごとにその方法の使用が推奨される場合についてまとめます。
表13-4 プラットフォームおよびロケーション移行のオプション
| 操作 | 推奨される方法 | 代替の方法 |
|---|---|---|
|
同じエンディアン・プラットフォームへのプラットフォーム移行 |
プラットフォーム移行のためのフィジカル・スタンバイ・データベース |
|
|
異なるエンディアン・プラットフォームへのプラットフォーム移行 |
プラットフォーム移行のためのOracle Data Pump |
|
|
ロケーション移行のみ |
ロケーション移行のためのData Guard REDO Apply(フィジカル・スタンバイ・データベース) |
なし |
|
注意: すべてのプラットフォームのV$DATABASEビューを問い合せます。 |
プラットフォーム移行の推奨アプローチは、フィジカル・スタンバイを作成し、スイッチオーバーを実行することです。フィジカル・スタンバイ・データベースは、特定の異種プラットフォームの組合せをサポートします。プラットフォームの組合せの最新リストは、次の場所にある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のオブジェクトの再編成ウィザードを使用するかにかかわらず、再編成プロセス全体は、ユーザーが表への完全なアクセス権を持つときに行われるため、システムの可用性が確保されます。
図13-2に、SQL*PlusコマンドラインでDBMS_REDEFINITIONパッケージを呼び出すかわりに使用できるOracle Enterprise Managerのオブジェクトの再編成ウィザードのページを示します。ウィザードでいくつかの質問に答えると、スクリプトが生成され、再編成が実行されます。
図13-2 Oracle Enterprise Managerを使用したデータベース・オブジェクトの再編成
データの再編成を実行する場合は、次のことを考慮してください。
オンライン操作中の表における同時アクティビティを最小化します。
オンライン操作中は、実表でのユーザー・アクティビティを最小化することをお薦めします。オンライン操作中のデータベース・アクティビティによる影響は、表の10%未満とする必要があります。データベース管理者は、データベース・リソース・マネージャを使用してユーザーに十分なリソースを割り当てることで、データ再編成の影響を最小限に抑えることができます。
ピーク期間中にオンライン操作を実行することや、データのオンライン再編成中に大容量のデータ変更を伴うバッチ・ジョブを実行することは避けてください。
オンラインで索引を再構築する方法と、索引を削除してからオンラインで索引を再作成する方法の比較。
オンラインで索引を再構築する場合、操作中に新規索引用の追加ディスク領域が必要です。一方、索引を削除して再作成する場合、追加ディスク領域は必要ありません。
オンライン索引結合とオンライン索引再構築の比較。
オンライン索引結合は、インプレースのデータ再編成操作であるため、索引を再構築する場合のような追加ディスク領域は必要ありません。索引の再構築では、索引とソート領域の合計サイズに等しい一時ディスク領域が操作中に必要です。オンライン索引結合では、Bツリーの高さは減少しません。この場合、リーフ・ブロック数の削減が試行されるのみです。結合操作では、ユーザー用の領域は解放されませんが、索引スキャンのパフォーマンスは向上します。
索引を新規表領域に移動する必要がある場合は、オンライン索引再構築を使用してください。
ローカル索引およびグローバル索引のオンライン・メンテナンスの実行。
Oracle Database 11gでは、オンライン操作でローカル・パーティション索引とグローバル・パーティション索引の両方がサポートされます。表および索引がパーティション化されている場合、管理者は、一度に1つのパーティションを対象にこれらのオブジェクトのメンテナンスを実行することで、他のパーティションをオンラインのまま維持できます。
|
関連項目:
|
インスタンス、ノード、またはその他のコンポーネントを分離する必要のある計画済の停止では、サービスを再配置、無効化および有効化するOracle RACの機能を使用できます。
クライアントは、UCP、ODP.NET、OCIセッション・プールなどのFAN認識接続プールを使用している場合、ノードまたはインスタンスのメンテナンスに影響されません。ノード・またはインスタンスのメンテナンスのためのクライアント・サービスを正常に管理するのに必要不可欠な手順は、次のとおりです。
サービスおよび関連するインスタンスの現在ステータスをチェックし、サービスが正常に移動できることを確認します。
メンテナンス対象のノードで、サービスを通常どおり(FORCEオプションを使用せずに)停止します。
サービスを無効にします。これにより、計画外の停止が発生した場合に、適切な時間までクラスタウェアはサービスを起動しません。
現在のトランザクションが完了したら、長時間実行されているセッションを切断します。
メンテナンスによる影響を受けるサービスすべてに対して、手順2 - 4を繰り返します。
データベース・インスタンスを停止します。
必要なメンテナンスを実行します。
ノードでインスタンスを起動します。
前に無効にされたサービスを有効にします。
停止されたサービスを開始します。
サービスで接続が再度表示されているのを確認します。
メンテナンスのために停止が必要なそれぞれのノードまたはインスタンスに対して、この手順を繰り返します。
再配置機能では、サービスを別のインスタンスに移行できます。サービスとインスタンスは、ハードウェアまたはシステム・ソフトウェアでの修復、変更、アップグレードの実行中に選択的に無効化し、メンテナンスの完了後に再有効化することが可能です。これにより、メンテナンスによる停止中はサービスまたはインスタンスが起動しないことが保証されます。サービスとインスタンスは、計画済の停止の開始時に無効化します。その後、メンテナンスによる停止の後に有効化します。
Oracle RACを使用している場合、ノードの開始時にOracleクラスタウェア・デーモンが自動的に起動します。1つ以上のシステムの再起動や、オペレーティング・システム以外のすべてのプロセスの停止が必要なメンテナンスの実行時には、crsctlコマンドを使用してOracle Clusterwareデーモンの起動を停止および無効化します。メンテナンスが完了したら、crsctlコマンドでOracleクラスタウェア・デーモンを有効化して起動します。
|
関連項目:
|
