| Oracle® Database高可用性概要 11gリリース2 (11.2) B56308-04 |
|
 前 |
 次 |
計画停止時間は、計画外停止時間と同様、業務に悪影響を及ぼします。これは、特に、複数のタイムゾーンのユーザーをサポートする必要がある、または顧客に24時間年中無休でインターネット・アクセスを提供する必要があるグローバル企業に当てはまります。
以前は、次のような作業を実行する場合に停止時間が必要でした。
データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークを更新するためのパッチ適用またはシステムの再構成などの定期的なメンテナンス。
ハードウェア、データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークの主要アップグレードまたは新規導入などの新規デプロイメント。
4.1項に、あらゆるタイプの計画メンテナンスによる停止時間を防止、許容および短縮するためのOracle高可用性ソリューションを要約します。
Oracleでは、あらゆるタイプの計画メンテナンスに対して停止時間を防止、許容および短縮するための高可用性ソリューションを提供しています。表4-1では、計画停止時間用の各種Oracle高可用性ソリューション、および各ソリューションで達成可能な停止時間について説明しています。どのような場合でも、計画メンテナンス操作を実行する前に広範囲なテストを行うことをお薦めします。また、各Oracle高可用性アーキテクチャでのあらゆるタイプの計画停止時間に対する達成可能なリカバリ時間の概要は、表7-5を参照してください。
表4-1 計画停止時間用Oracle高可用性ソリューション
| メンテナンス・タイプ | 推奨されるOracleソリューション | ソリューションの説明 | 停止時間 |
|---|---|---|---|
|
オペレーティング・システムおよびハードウェアのアップグレード |
Oracle Real Application ClustersおよびOracle ClusterwareまたはOracle RAC One Node(単一インスタンスOracle RACデータベースの場合) |
|
停止時間ゼロ |
|
Oracle個別パッチ |
Oracle Real Application Clusters(Oracle RAC) |
|
停止時間ゼロ脚注1 |
|
Oracle Clusterwareのアップグレードおよびパッチ |
Oracle ClusterwareまたはOracle RAC One Node(単一インスタンスOracle RACデータベースの場合) |
|
停止時間ゼロ |
|
Oracle ASMのアップグレード |
Oracle Automatic Storage Management |
|
停止時間ゼロ |
|
ストレージの移行脚注2 |
Oracle Automatic Storage Management |
|
停止時間ゼロ |
|
Exadata Storageへの移行 |
「Best Practices for Migrating to Oracle Exadata Storage Server」プレゼンテーション脚注3で説明されているOracle MAAのベスト・プラクティス |
|
停止時間は選択したソリューションによって異なる |
|
Exadata Storageのアップグレード |
Exadataパッチ・マネージャ |
|
停止時間ゼロ |
|
単一インスタンス・データベースのOracle RACへの移行 |
Oracle Clusterware |
|
停止時間ゼロ |
|
Oracle ASMへの移行、またはOracle RACへの単一インスタンス・データベースの移行 |
|
|
数秒から数分 |
|
パッチ・セットおよびデータベースのアップグレード |
SQL Applyを使用したOracle Data Guard |
|
数秒から数分 |
|
Oracle個別パッチ、Oracleクラスタウェアのアップグレードおよびパッチ、Oracle ASMのアップグレード、オペレーティング・システムおよびハードウェアのアップグレード |
Oracle Data Guard Standby-First Patchの適用 |
My Oracle Support Noteの「Oracle Patch Assurance - Data GuardのStandby-First Patchの適用」
|
数秒から数分 |
|
WindowsプラットフォームとLinuxプラットフォーム、および選択したその他のプラットフォーム間でのプラットフォームの移行脚注4 |
|
|
数秒から数分 |
|
同じエンディアン形式のプラットフォーム間でのプラットフォームの移行 |
トランスポータブル・データベース |
|
数分から数時間 |
|
異なるエンディアン形式のプラットフォーム間でのプラットフォームの移行 |
トランスポータブル表領域 |
|
数時間 |
|
パッチ・セットとデータベースのアップグレード、プラットフォームの移行、ローリング・アップグレード、および異なるキャラクタ・セットが必要な場合 |
Oracle GoldenGateおよびOracle Streams |
数秒から数分 |
|
|
アプリケーションのアップグレード |
アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード |
|
脚注1ローリング・アップグレードの実行で適用できないパッチは、パッチ適用による可用性の影響が少ないOPatchユーティリティのMINIMIZE_DOWNTIMEオプションで適用できます。
脚注2従来型のストレージから低コストのストレージへの移行などの例があります。
脚注3Oracle MAA Webサイト(http://www.oracle.com/goto/maa)から入手できます。
脚注4My Oracle Support(旧OracleMetalink)Note 413484.1(http://support.oracle.com/)を参照してください。
|
関連項目:
|
システムとハードウェアのアップグレード時の停止時間を回避するには、Oracle RACを使用するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeを使用できます。
4.1.2項に示すように、Oracle RACまたはOracle RAC One Nodeを使用してアップグレードを実行できない場合は、Oracle Data Guardとフィジカル・スタンバイ・データベースを使用するソリューションをお薦めします。もしくは、4.1.4項に示すように、Oracle Clusterwareを使用したコールド・クラスタ・フェイルオーバーを使用することもできます。
次のリストに、Oracle RACを使用してアップグレードする場合の手順の高レベルの概要を示します。
次の前提条件チェックを実行します。
計画メンテナンスがオペレーティング・システムの観点からローリング形式で行うことができるかどうかを確認します。
データベースとクラスタウェアのバージョンが、新規システムおよびハードウェアの変更で動作保証されているかどうかを確認します。
クラスタ内の複数のインスタンスでアプリケーション・サービスが稼働している場合は、アプリケーション・サービスを停止します。アップグレード対象のインスタンスのみでアプリケーション・サービスが稼働している場合は、クラスタ内の別のノードにサービスを再配置します。
高速アプリケーション通知(FAN)を使用している場合、アプリケーション・サービスを停止すると、接続が接続先インスタンスから暗黙的にリダイレクトされます。
IMMEDIATEオプションを指定して接続先インスタンスを停止します。
Oracle Clusterwareを停止して無効にします。
Oracle Clusterwareを無効にすると、自動起動しなくなります。
メンテナンスを実行します。
Oracle Clusterwareを有効にして、起動します。
この手順により、データベース・インスタンスが暗黙的に起動されます。
アプリケーション・サービスを起動します。
この手順により、FANを使用している場合、接続先インスタンスに接続が暗黙的にリダイレクトされます。
次のノードですべての手順を繰り返します。
また、使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。
Oracle Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムとクラスタのアップグレードを実行する場合に推奨されるソリューションです。Oracle Data Guardは、Oracle ASM、Oracle RACおよび64ビット・システムへの移行、WindowsとLinux間での移行、あるいは同じプロセッサ・アーキテクチャのプラットフォームへの移行にも推奨されます。次に例を示します。
システムの制限によりOracle RACのローリング・アップグレードを使用してアップグレードできないシステム・アップグレードには、Oracle Data Guardを使用します。
Oracle ASMへの移行、クラスタ化されていない環境からOracle RACへの移行、同じエンディアン形式の別のプラットフォームへの移行、または同じプロセッサ・アーキテクチャの別のプラットフォームへの移行を行う場合、Oracle Data Guardを使用します。スイッチオーバーを実行するのに必要な時間は発生する停止時間のみです。詳細は、My Oracle Supportのノート413484.1の「同一Data Guard構成の異機種間プライマリ・スタンバイおよびフィジカル・スタンバイに関するData Guardのサポート」を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=413484.1
通常、フィジカル・スタンバイ・データベースを最初にアップグレードしてから、フィジカル・スタンバイ・データベースに対してOracle Data Guardスイッチオーバーを実行します。
フィジカル・スタンバイ・データベースのアップグレードおよびスイッチオーバーの実行手順:
システムをアップグレードするか、またはフィジカル・スタンバイ・データベース・システムを移行先環境に変更します。
たとえば、Oracle ASMを使用して、スタンバイ・データベースを単一インスタンス・データベースからOracle RACデータベースに変換できます。プライマリ・データベースへの影響はありません。次に、スタンバイ・データベースを再起動し、これが移行先環境に合っているかどうかを確認して、REDO Applyによるスタンバイ・データベースへのREDOデータの適用が終わるまで待機します。
Oracle Data Guardスイッチオーバーを実行します。最適なスイッチオーバーの所要時間は、数秒から数分程度です。
元のプライマリ・データベースを停止します(これでスタンバイ・データベースになる)。
アップグレードするか、元のプライマリ・データベースへのシステム変更を行います。
スタンバイ・データベースとしてアップグレードしたデータベースを再起動し、リカバリでデータベースを自動的に同期化します。
必要に応じて、Oracle Data Guardスイッチオーバーを実行して、スタンバイ・データベースをプライマリ・データベース・ロールに戻します。
|
注意: Oracle Databaseパッチ・セットの適用またはOracle Databaseのアップグレードを同時に行う場合、32ビットから64ビットへの変換は自動的に行われます。オペレーティング・システムのみをアップグレードする場合は、My Oracle SupportのNote 414043.1(http://support.oracle.com/)に記述されている追加のアップグレード後の手順を実行する必要があります。アップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』も参照してください。 |
システムおよびクラスタのアップグレードと移行では、次のベスト・プラクティスおよびガイドラインを考慮します。
スイッチオーバーを高速化するには、スタンバイ・データベースでリアルタイム適用が使用されるように構成し、できれば、アーカイブ・ログ・ギャップが存在しないように、スイッチオーバー操作の開始前にデータベースがほとんど同期化されているようにします。
Oracle RACローリング・アップグレードまたはオンライン・パッチを使用できない場合は、Oracle Data Guardおよびフィジカル・スタンバイ・データベースを使用して、システムおよびクラスタのアップグレードを実行します。詳細は、『Oracle Data Guard概要および管理』を参照してください。
通常、データベース・ソフトウェアへのOracleパッチは、ソフトウェアの問題に対する既知の修正を実装するため、または診断パッチを適用して問題に関する情報を収集するために適用します。パッチの適用は、予定したメンテナンス停止の際に行うように計画します。
Oracleデータベース・パッチを適用する際に停止時間を回避するには、Oracle RACを使用してローリング・パッチ・アップグレードを実行します。RACを使用すると新規パッチの約90% を適用できます。Oracleには、OPatchコマンドライン・ユーティリティを使用した、データベースの停止時間がほとんどないかゼロの、Oracle RACを使用したローリング・パッチのアップグレードを行う機能があります。Oracle RACを使用できない場合は、Oracle Data Guardおよびフィジカル・スタンバイ・データベースを使用します。詳細は、4.1.2項を参照してください。
パッチには複数の種類があります。
個別パッチ
パッチ・セットのリリース間の特定の修正を提供するために作成される1つのパッチ。
バンドル・パッチ
パッチ・セット間で発行されるパッチを集めたもの。パッチ・バンドルは通常は累積されます。Database用のMicrosoft Windowsバグ修正は、通常は個別パッチではなくパッチ・バンドルで発行されます。
パッチ・セット更新(PSU)
該当製品の最重要の修正を含む四半期ごとのパッチ(セキュリティ修正を含む)で、1つのパッチを適用して多くの問題を解決できます。
クリティカル・パッチ・アップデート(CPU)
四半期ごとに提供される優先度の高い修正(通常はセキュリティ上の問題)を集めたもの。CPUは、セキュリティの事前修正の観点から累積されますが、セキュリティ以外のパッチ(マージ・リクエストの必要性を軽減)と競合するパッチに対処できるように他の修正が含まれる場合があります。
診断パッチ
バグの修正ではなく、問題の診断に限定して作成されるパッチ。
Oracle RACによるローリング・アップグレードでは、計画停止の間、Oracle RACインストールのインスタンスを、1つを除いてすべて使用できます。その結果、計画停止に必要なアプリケーション停止時間に対する影響はさらに減少します。OracleのOPatchユーティリティを使用すると、インストール済のOracle RACの異なるインスタンスに対してパッチを連続的に適用できます。
ローリング・アップグレードの実行は、ローリング・アップグレード用に認可されているパッチの場合のみ可能です。
オンライン・パッチは、インスタンスがオンラインのままで適用できる特殊な個別パッチまたは診断パッチです。次の場合にのみ、個別パッチまたは診断パッチをオンラインで適用してください。
パッチのREADMEには、オンラインで適用できることが記載されています。
パッチはすぐに適用する必要がありますが、通常(オフライン)バージョンのパッチを適用する場合は、データベース・インスタンスを停止できません。
OPatchコマンドライン・ユーティリティを使用してOracleデータベースでオンライン・パッチ適用を実行できます。
また、オンライン・パッチを実行するときは、次の点に注意してください。
オラクル社では、正規の個別または診断パッチをコンボ・パッチとして提供しており、同じバグ修正でオンライン・パッチとオフライン・パッチの両方が含まれています。
そのため、このオンライン・パッチを最初に適用すると、計画外停止時間を回避できます。ただし、オンライン・パッチではメモリーのオーバーヘッドが発生するため、計画停止時にオンライン・パッチをロールバックしてオフライン・パッチを適用する必要があります。
オンライン・パッチを適用すると、各Oracleプロセスではパッチの適用時にプログラム・グローバル領域(PGA)のメモリーを多く使用するため、システムのメモリー消費が増加します。オンライン・パッチを適用する前に、メモリー要件を考慮してください。各オンライン・パッチは独自のものであり、メモリー要件はパッチごとに異なります。パッチをまずテスト・システムに適用することで、本番システムでのオンライン・パッチの効果を評価し、追加のメモリー使用量を予測できます。
|
関連項目:
|
Oracle Clusterwareのアップグレード時の停止時間を回避するには、Oracle Clusterwareのローリング・アップグレードを実行するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeの使用を検討してください。
Oracle Clusterwareへのアップグレードはすべて、ローリング方式で実行できます。
|
関連項目:
|
Oracle ASMのアップグレードには、ローリング・アップグレードの実行をお薦めします。Oracle Database 11g(およびこれ以降のリリース)でのアップグレードはすべて、ローリング方式で実行できます。
詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
ストレージの移行を実行するには、Oracle ASMを使用するソリューションをお薦めします。
Oracle ASMを使用して、すべてのディスクを1つのストレージ・アレイに追加した後、別のアレイからすべてのディスクを削除できます。Oracle ASMは、データベースが稼働したままの状態で、自動的にデータのリバランスを行い、新規ストレージに移行します。ソース・ストレージ・アレイを削除する前に、リバランスが完了したかどうか確認してください。
詳細は、MAAホワイト・ペーパー「Migration to Automatic Storage Management(ASM)」および「Best Practices for Creating a Low-Cost Storage Grid for Oracle Databases」(http://www.oracle.com/goto/maa)を参照してください。
MAAプレゼンテーション「Exadataデータベース・マシンへの移行のためのベスト・プラクティス」のガイドラインには、従来のストレージからOracle Exadata Storage Serverへの移行前および移行後のベスト・プラクティスが定義されています。これらのベスト・プラクティスは、アプリケーション・サービスのレベルおよび属性を考慮して最適な移行方法を判断するのに役立ちます。MAAプレゼンテーションは、MAA Webサイト(http://www.oracle.com/goto/maa)から入手できます。
アップグレードを実行するためのソリューションおよびツールの詳細は、Oracle Exadata Storage Server Softwareのドキュメントを参照してください。
|
関連項目:
|
パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、SQL Applyを使用するOracle Data Guardのソリューションをお薦めします。このソリューションについては、4.1.9.1項で説明します。ソース・データベースがSQL Applyでもともとサポートされていないデータ型を使用している場合、拡張データ型サポート(EDS)を使用することで、対応する拡張データ型をさらにいくつか増やすことができます。
ソース・データベースが、SQL Applyのローリング・アップグレードでサポートされていないソフトウェア・バージョンを使用している場合(Oracle Databaseリリース10.1.0.3より前のリリース)、またはEDSを使用してもSQL Applyのデータ型の競合を十分に解決できない場合、Database Upgrade Assistant(DBUA)脚注1、トランスポータブル表領域またはOracle GoldenGateの使用を検討します。
DBUAには、アップグレード・プロセスの手順を示すグラフィカル・ユーザー・インタフェース(GUI)ユーティリティが備わっており、データベースのアップグレードの方法としては最も簡単で推奨できる方法です。ただし、DBUAでデータベースのアップグレードにかかる時間が定義されたメンテナンス・ウィンドウの期間に納まらない場合は、1時間未満でデータベース・アップグレードを実行するために、トランスポータブル表領域機能の使用を検討してください。
SQL Applyを使用できず、メンテナンス・ウィンドウで停止時間を1時間未満にする必要がある場合、およびアップグレードされるデータベースに単純なスキーマや、トランスポート・プロセスの一部として転送する必要のないデータ・ファイル(データ・ファイルが所定の場所で使用される場合など)が少ない場合には、トランスポータブル表領域を使用します。トランスポータブル表領域ソリューションについては4.1.9.2項で説明します。
Oracle GoldenGateは、データベース・アップグレードを実行する際の最も柔軟な方法と、追加のデータ型サポートを提供します。このソリューションについては、4.1.9.4項で説明します。
Oracle RACを使用してパッチ・セットのローリング・アップグレードを実行しないでください。また、使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。
詳細と、ユーザーの構成に適したデータベース・アップグレード方法の選択に役立つ情報は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。
次のリストで、アップグレードの高レベルの手順を説明します。
ロジカル・スタンバイ・データベースを新規リリースにアップグレードして、変更を評価します。
SQL ApplyによってREDOデータがすべてロジカル・スタンバイ・データベースに適用されたかどうかを確認します。
アプリケーションを切断します。
Oracle Data Guardスイッチオーバーを実行します。
アプリケーションを新規プライマリ・データベースに再接続します。
元のプライマリ・データベースを停止します(これでロジカル・スタンバイ・データベースになる)。
新しいスタンバイ・データベースでデータベース・ソフトウェアのアップグレード手順を実行します。
スタンバイ・データベースを再起動し、リカバリが同期化されるようにします。
必要に応じて、Oracle Data Guardスイッチオーバーを実行して元のデータベースに戻ります。
パッチ・セットおよびデータベース・アップグレードを実行する際は、次の点を考慮してください。
SQL Applyによるローリング・アップグレードは、Oracle Databaseリリース10.1.0.3以上の場合のみサポートされます。詳細は、『Oracle Data Guard概要および管理』のSQL Applyを使用したOracle Databaseのアップグレードに関する章を参照してください。
SQL Applyにはいくつかのデータ型制限があります(制限のリストは、『Oracle Data Guard概念および管理』を参照)。データ型の制限がある場合は、拡張データ型サポート(EDS)の実装を検討してください。
EDSによりSQL Applyで、1つのデータベースから別のデータベースに、本来サポートされていないいくつかのデータ型を含む表への変更をレプリケートできます。Oracle Database 10gリリース2(10.2.0.4)パッチ・セット3から、SQL Applyでは、EDSの基礎となるロジカル・スタンバイ・データベースでトリガーを起動させる機能がサポートされています。EDSの概要は、http://www.oracle.com/goto/maaで入手可能なMAAホワイト・ペーパー「Extended Datatype Support Using SQL Apply and Oracle Streams」を参照してください。
本来SQL Applyではサポートされていないデータ型をサポートするためのEDSの使用例は、http://support.oracle.com/のNote 559353.1を参照してください。
Oracle Database 11gリリース11.1以降では、フィジカル・スタンバイ・データベースでKEEP IDENTITY句および一時的なロジカル・スタンバイ・データベースを使用して、ローリング・データベース・アップグレードを実行できます。
Oracle RACによるローリング・アップグレードができず、データ型の制限がない場合は、Oracle Data Guardが最適なアプローチです。
|
関連項目:
|
データ型が競合するためにSQL Applyを使用できず、テストの結果、DBUAでのアップグレードが稼働時間の要件を満たせないことがわかる場合、トランスポータブル表領域ソリューションを利用したデータベースのアップグレードを検討してください。
トランスポータブル表領域機能を利用してOracle Databaseをアップグレードするには、次の手順に従います。
トランスポート先システムにOracle Databaseソフトウェアをインストールし、ソース・データベースで最初の手順を実行し、トランスポート・プロセスの準備をします。
ソースおよびトランスポート先データベースを準備します。
ソース・データベースから情報を収集します。
Database Configuration Assistant(DBCA)でトランスポート先データベースを作成します。
Oracle Data Pump使用のためと、トランスポートされる表領域を受け入れるために、トランスポート先データベースの準備をします。
次の手順でユーザー表領域をトランスポートします。
ユーザーを切断し、ソース・データベースへのアクセスを制限することで、ソース・データベースのトランスポートの準備をし、すべてのユーザー表領域をREAD ONLYにして、ソース・データベースから順序の開始値を取得します。
ユーザー表領域をトランスポートします。
トランスポート先データベースが完全であり機能することを確認した上でバックアップします。
トランスポータブル表領域を使用する場合、次の点を考慮してください。
トランスポータブル表領域機能は、単純なスキーマを持ち、トランスポート・プロセスの一部としてデータ・ファイルを転送する必要がない(データ・ファイルが所定の場所で使用される場合など)データベースに対して、1時間未満でデータベース・アップグレードを実行するためのオプションです。次のWebサイトにあるMAAホワイト・ペーパー「Database Upgrade Using Transportable Tablespace」を参照してください。
トランスポータブル表領域機能を使用すると、以前のリリースのソフトウェアが稼働するデータベースから、現行リリースのソフトウェアが稼働する空のトランスポート先データベースに、すべてのユーザー表領域を移動することにより、データベースのアップグレード時間が短縮されます。トランスポータブル表領域を持つ表領域データ・ファイルは、データ・ファイルをトランスポート先データベースにコピーし、オブジェクト・メタデータをトランスポート先データベースにインポートすることで、データベースに接続されます。
図4-1の構成は、Oracle Data Guardデータベース・ローリング・アップグレードによりサポートされないアップグレードおよび移行などによる、停止時間および計画停止の危険性を最小限に抑えるためのOracle GoldenGateおよびOracle Data Guardの構成方法を示します。これには、異なるハードウェア・アーキテクチャおよびオペレーティング・システムへの移行、データベース・オブジェクトを変更するアプリケーション・アップグレードの実行などが含まれます。この構成では、フィジカル・スタンバイ・データベースにより、移行の前後および移行中の停止時間またはデータ損失を防く災害からの保護が提供されます。また、移行の実行に必要な作業から本番データベースを分離することにより、パフォーマンスへの影響または操作上の危険性を回避します。
スタンバイ・データベース(図4-1の右上)から新しい本番データベース(右下)にGoldenGateをレプリケートするには、Oracle GoldenGateアーカイブ・ログ・モードが必要です。アーカイブ・ログ・モードの要件を満たすことができない場合は、元の本番データベース(左上のデータベース)から直接レプリケートします。
これらの要件は、新しいプラットフォーム上にパラレル環境を作成することにより達成されます。計画された移行のタイプによっては、新規プライマリ・データベースのインスタンス化が、既存のスタンバイ・データベースのバックアップのリストアと同じくらい単純になる可能性があります。より複雑な移行の場合は、Oracleトランスポータブル・テクノロジやOracle Data Pumpなどの、別のOracleテクノロジを使用して新規プライマリ・データベースをインスタンス化します。インスタンス化の後、新しい本番システム上で追加の変更を実装します。すべての変更が実装されると、新規フィジカル・スタンバイ・データベースが作成され、稼働開始後の継続的なデータ保護が提供されます。Oracle GoldenGateの異機種間レプリケーション(以前に構成済)が使用されて、新しい本番システムと、新しい環境の実装中に古いシステムで発生したすべてのトランザクションが同期化されます。同期化が完了すると、本番システムは新しい環境で稼働できるようになります。また、しばらくの間、新しい本番システムと同期された古い環境を保持するために、稼働後にOracle GoldenGate異機種間レプリケーションを使用するオプションもあります。ファスト・フォールバック・オプションでは、予期せぬ問題が発生する可能性があります。
Oracle GoldenGateは、Oracle Data Guard SQL Applyと機能上類似しています。SQL Applyと同様に、Oracle GoldenGateでは拡張データ型サポート(EDS)を利用して、本来サポートされていないいくつかのデータ型を含む表に対する変更を、データベース間でレプリケートできます。
Oracle GoldenGateを使用したデータベース・アップグレードの実行手順:
アップグレード・プロセスを開始する前に、ユーザー定義型を持つデータベースでデータベース・アップグレードを実行する方法については、Oracle GoldenGateのドキュメントを参照してください。
PRE_INSTANTIATIONプロシージャを使用して、Oracle Goldengateを構成します。
複製データベースを作成します。(理想的なレプリカは、最新のフィジカル・スタンバイ・データベースとして始まります。)
データベースをアクティブにして、後続バージョンにアップグレードします。
必要に応じて、POST_INSTANTIATIONプロシージャを使用して、追加の構成を実行します。
Oracle GoldenGateレプリケーションを有効にします。
レプリカのアップグレード中に、ソース・データベースはそのまま稼働し続けます。レプリカが遅れを取り戻したら、スイッチオーバーを実行します。
|
関連項目:
|
同じエンディアン形式のプラットフォーム間でプラットフォームの移行を実行する場合、次のアプローチを検討します。
LinuxおよびWindowsプラットフォーム間で移行を実行するには、Oracle Data Guard(フィジカル・スタンバイ・データベース)のソリューションをお薦めします。このソリューションについては、4.1.2項で説明します。
クロス・プラットフォームのフィジカル・スタンバイ・データベースが移行対象のプラットフォームの組合せに使用できない場合、トランスポータブル・データベース機能を使用します。このソリューションについては、4.1.10.1項で説明します。
トランスポータブル・データベース機能で移行を迅速に実行できない場合は、Oracle GoldenGateを使用します。このソリューションについては、4.1.10.2項で説明します。
クロス・プラットフォームのフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースが、該当するプラットフォームの組合せに対してサポートされていない場合のみ、プラットフォーム移行にトランスポータブル・データベースを使用してください。脚注2
たとえば、Windows x86-64からLinux x86-64に移動する場合、トランスポータブル・データベースではなく、クロス・プラットフォームのスタンバイ・データベースを使用するのが適しています。停止時間が少なく(スイッチオーバーに要する時間のみ)、新しいプラットフォームでスタンバイ・データベースを一時的に実行して、すべてが計画どおりに機能するかどうかを確認できます。
トランスポータブル・データベース(移動先システムの変換を含む)を使用したプラットフォームの移行を実行する高レベルの手順を次に示します。
読取り専用モードでソース・データベースを設定します。
RMANのCONVERT DATABASEコマンドを実行します。
移動先システムにファイルを移動します。
RMAN生成スクリプトを実行して、UNDOが含まれるデータ・ファイルを移動先プラットフォームの形式に変換します。
RMAN生成スクリプトを実行して、移行を完了します。
トランスポータブル・データベース・ソリューションを使用する場合、プラットフォームの移行に必要な停止時間は、次の操作に要する時間によって異なります。
読取り専用モードでソース・データベースを設定
UNDOが含まれるデータ・ファイルを新しいプラットフォームの形式に変換(UNDOが含まれていないデータ・ファイルは変換不要)
ソース・システムから移動先システムにすべてのデータ・ファイルを転送します。
ストレージ・インフラストラクチャを使用すると、物理的にファイルを移動しなくても移動先システムでデータ・ファイルを使用できるため、この時間を大幅に短縮できます。
SQLスクリプトutlirp.sqlおよびutlrp.sqlを使用して、すべてのPL/SQLを無効化および再コンパイル
詳細は、http://www.oracle.com/goto/maaから入手可能なホワイト・ペーパー「Platform Migration Using Transportable Database」を参照してください。
Oracle GoldenGateを使用すると、Oracleのプラットフォームやデータベースのリリースに関係なく、複数のデータベース間で更新をレプリケートできます。したがって、Oracle GoldenGateは、データベースのアップグレードおよびプラットフォームの移行に最も高速なアプローチを提供することになります。
Oracle GoldenGateでは、幅広いデータ型のデータベースをサポートしていますが、一部のデータ型のデータ移動は本来サポートされていません。ただし、このデータ型の制限は、拡張データ型サポート(EDS)を使用すると回避でき、Oracle GoldenGateの柔軟性を生かしてさらに多くの拡張データ型に対応できます。
この回避策を実現するために、PL/SQLパッケージEXTENDED_DATATYPE_SUPPORT(EDS)を使用して適切なデータベース・オブジェクトを生成できます。EXTENDED_DATATYPE_SUPPORTパッケージは、この記事の添付ファイルとしてダウンロードできます。ダウンロードしたファイル(My Oracle SupportのNote 556742.1:1からダウンロード可能)には、ReadmeファイルおよびデータベースにロードするSQLファイルが含まれます。
EDSパッケージによって、次のデータ型を含む表のOracle GoldenGateサポートを有効にする回避スクリプトが生成されます。
単純なオブジェクト型を含むオブジェクト列
ネストしたオブジェクト型を含むオブジェクト列
VARRAY
空間型SDO_GEOMETRY
XML型
EDSパッケージをインストールしたら、EDS_SUPPORTEDビューの問合せを実行して、Oracle GoldenGateで本来サポートされていないがEDSでサポート可能なデータ型の表のリストを識別できます。
Oracle GoldenGateの実装は非常に柔軟でカスタマイズ可能なため、構成、テストおよび管理で付加的な作業が伴います。
Oracle GoldenGateでのプラットフォームの移行手順:
ソース・データベースでOracle GoldenGate環境を設定します。
ソース・データベースから新しい移動先データベースへデータをコピーして、レプリカ・データベースをインスタンス化します。
移動先データベースでOracleGoldenGate環境を設定します。
Oracle GoldenGateで、ソース・データベースに加えられた変更をすべて移動先データベースに伝播して、移動先データベースとソース・データベースを完全に同期できるようにします。
ユーザーを移動先データベースに接続して、ソース・データベースを停止します。
Oracle GoldenGate構成を削除します。
|
関連項目:
|
異なるエンディアン形式のプラットフォームでプラットフォーム移行を実行する場合、次のアプローチを検討します。
停止時間を大幅に短縮するには、異なるエンディアン形式のプラットフォーム間でプラットフォーム移行を実行するための、トランスポータブル表領域機能のソリューションをお薦めします。トランスポータブル表領域を使用した移行は、このリストの後で説明します。
トランスポータブル表領域ソリューションには、キャラクタ・セット、不透明型およびシステム表領域オブジェクトに関して制限があります。前述の各ソリューションと異なり、手順は自動化されません。
次の事項がすべて当てはまる場合、トランスポータブル表領域を使用してプラットフォーム移行を実行します。
ソース・プラットフォームと移行先プラットフォームのエンディアン形式が異なる。
完全なデータ・ポンプ・エクスポートおよびインポートの実行に必要な時間がメンテナンス・ウィンドウの期間に納まらない。
すべてのアプローチの中で最も単純な方法として、Oracle Data Pumpの使用を検討してください。Oracle Data Pumpの使用方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。
計画停止時間が数秒の可能性がある場合は、4.1.10.2項で説明するように、Oracle GoldenGateの使用を検討してください。
トランスポータブル表領域を使用したデータベースの新規プラットフォームへの移行方法を説明する高レベルの手順を次に示します。
移行先プラットフォームで、新しい空のデータベースを作成します。
トランスポート操作に必要なオブジェクトを、ソース・データベースから移動先データベースにインポートします。
すべてのユーザー表領域のトランスポータブルなメタデータをソース・データベースからエクスポートします。
ユーザー表領域のデータ・ファイルを移動先システムに転送します。
RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します。
すべてのユーザー表領域のトランスポータブルなメタデータを移動先データベースにインポートします。
残りの(トランスポート操作で移動されなかった)データベース・オブジェクトとメタデータをソース・データベースから移動先データベースにインポートします。
|
ヒント: 移動先データベースが移行時に新しい場所(新しいデータ・センターなど)に移動する場合は、移動先データベースと共存している最初のプライマリ・データベースからフィジカル・スタンバイ・データベースを作成します。Oracle Data Guardスイッチオーバー後、ファイル転送時間が停止時間の一部となることなく、表領域をソースから移動先にトランスポートします。 |
|
関連項目:
|
システムおよびデータベースの変更には、次の各項で説明する動的リソース・プロビジョニング機能を使用します。
Oracleでは、サービスを中断することなく、ハードウェアの要求の変化に適応できるように、データベースの動的再構成のサポートを継続的に拡大しています。Oracle Databaseは、ハードウェアおよびデータベース構成への様々な変更に対して、次の機能を提供して動的に対応します。
対称型マルチプロセッシング(SMP)サーバーからのプロセッサの追加および削除
Oracle RAC環境でのノードとインスタンスの追加および削除
データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるデータベース・ディスクの追加および削除
データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるストレージ・アレイまたはExadataセルの追加および削除脚注3
Oracle ASMを使用したデータベース・ストレージ全体のI/Oロードの自動リバランス
ストレージ構成が変更するたびに自動的にデータベース・ストレージのリバランスを行う、Oracle ASMを使用したディスクの追加または削除時のオンラインによるデータ・ファイルの移動
次のいずれかのSQL*Plus文を使用することで、インスタンスを停止せずに、ほとんどすべての初期化パラメータを変更
ALTER SESSION文は、セッション中にパラメータの値を変更します。
ALTER SYSTEM文は、インスタンスの期間中、インスタンスのすべてのセッションでパラメータの値を変更します。
これらの機能により、エンタープライズ・グリッド・コンピューティングの基本要件であるシステム変更およびキャパシティ・オンデマンド・プロビジョニングがコストなしで実現されます。
2つのメモリー管理初期化パラメータ、MEMORY_TARGETとMEMORY_MAX_TARGETは、システム・グローバル領域(SGA)、プログラム・グローバル領域(PGA)およびOracle Databaseの実行に必要なその他のメモリーの自動管理を可能にします。
MEMORY_MAX_TARGETは、MEMORY_TARGETの動的な最大値を指定します。
表4-2 MEMORY_MAX_TARGETおよびMEMORY_TARGET
| 1つ目の条件 | 2つ目の条件 | 結果 |
|---|---|---|
|
|
|
初期化パラメータはデフォルト値(0)のままで、Oracle Databaseでは、メモリーは自動的にチューニングされません。 |
|
|
|
データベースでは、 |
|
|
|
|
Oracle Databaseでは非集中型ポリシーを使用して、SGAおよびPGAの各サブコンポーネントのメモリーを解放して取得します。また、メモリーのグラニュルをあまり必要としないコンポーネントから、より必要とするコンポーネントに転送するようオペレーティング・システムに要求することにより、メモリーを自動的にチューニングします。メモリー転送の粒度は、現在の空きメモリーと、サービスに支障のない基本レベルを維持するためにオペレーティング・システムが必要とするメモリー量によって決まります。
|
注意: MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータを使用する自動メモリー管理は、Linux、Windows、Solaris、HP-UXおよびAIXでサポートされます。サポートされるすべてのプラットフォームの詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。 |
Oracle ASMでは、使用可能なディスク全体にデータ・ファイル、制御ファイルおよびログ・ファイルを自動的に分散します。ディスク、Exadataセルまたはストレージ・アレイの追加と削除など、ストレージ構成に変更があった場合に、データベース・ストレージのリバランスが行われます。Oracle ASMは、データベース・ファイルのミラー化を通じて冗長性を提供するとともに、使用可能なすべてのディスクにわたりデータベース・ファイルを自動的にストライプ化することにより最適なパフォーマンスを提供します。
|
関連項目: Oracle ASMの詳細は、次のマニュアルを参照してください。
|
可用性および管理性を強化する1つの方法として、データの再編成操作中、データベースへの通常のアクセス権をユーザーに与えます。Oracle Databaseのオンライン再編成および再定義機能により、管理者は、データベースへの通常のアクセス権をユーザーに与えたまま、表の物理属性を変更したり、データおよび表構造の両方を変換したりするなど多くの柔軟性が得られます。この機能によって、データの可用性、問合せのパフォーマンス、レスポンス時間およびディスク領域の使用率が向上します。これらは、すべてミッションクリティカルな環境において重要で、アプリケーションのアップグレード・プロセスをより簡単、安全かつ高速なものにします。
オンライン再編成および再定義アーキテクチャには次のような利点があります。
オンラインの表編成および再定義:
表の物理属性をオンラインで変更します(新しい場所への表の移動、表のパーティショニング、1つの構成(ヒープ構成など)から別の構成(索引構成など)への表の変換など)。
名前、型、サイズなどの多くの論理属性を変更します。列を追加、削除またはマージできます。ただし、表の主キーは変更できません。
オンライン索引操作:
索引をオンラインで作成し、それらを同時に分析します。論理ROWIDの物理的推測コンポーネント(索引構成表の2次索引およびマッピング表で使用)のオンライン修復も使用できます。
索引構成表および2次索引をオンラインで再編成して、再編成のメンテナンス・ウィンドウを排除できます。2次索引は、ブロック・ヒント(物理的推測)の効率的な使用をサポートします。索引編成表で2次索引に格納される論理ROWIDの無効な物理的推測のオンライン修復も実行できます。
2次索引を再構築せずに索引構成表または表パーティションを再編成できるため、再編成のメンテナンス期間が短縮されます。
パーティション化された表のオンライン移動
アドバンスト・キュー、クラスタ表、マテリアライズド・ビューおよび抽象データ型(オブジェクト)に対するオンラインで再編成のサポート
デフォルト値による高速なADD COLUMN操作(すべての行をデフォルト値に更新する必要はありません)
不可視の索引によるアプリケーションの移行とテストの高速化
明示的なヒントで移行の速度を上げ、終了したらヒントを削除します。
新しく作成された索引の早まった使用を防止します。
必要に応じて、索引を可視化してDROP INDEXの影響をテストするため、索引の再構築は必要ありません。
DML操作の実行を中断しない索引のオンライン作成(DMLの排他ロックは不要)
オンライン再定義が論理的にオブジェクトに影響を与えない場合(列が表に追加される場合やプロシージャがパッケージに追加される場合など)、依存オブジェクトの再コンパイルは不要
オンラインでの表DDL操作の簡略化(停止ではなく、アクティブなDML操作を待つオプション)
マテリアライズド・ビューやマテリアライズド・ビュー・ログがある表の再定義をサポート
表の物理属性の変更、およびデータと表構造の両方を変換する機能は、Oracle8iリリース以降に使用可能になりました。データ再編成の機能を表4-3に包括的に示します。
表4-3 各リリースの新規データ再編成機能
| 機能 | Oracle 9i | Oracle Database 10gリリース1 | Oracle Database 10gリリース2 | Oracle Database 11g |
|---|---|---|---|---|
|
パッケージ |
表記憶域パラメータの変更 異なる表領域への表の移動 パラレル問合せのサポートの追加 パーティション化サポートの追加または削除 断片化を回避するための表の再作成 表から索引構成表または索引構成表から表への変更 列の追加または削除 関数を使用した列の変換 |
権限、制約およびトリガーのクローニング LONGからLOBへの変換一意キーを使用した再編成 表順序の基準となる列の指定 |
単一のパーティションの再編成 アドバンスト・キューおよびクラスタ表 ADTを含んだ表 統計の保存およびクローニング チェック制約およびNOT NULL制約 ネストした表の依存オブジェクトのコピー |
マテリアライズド・ビュー・ログやマテリアライズド・ビューを含む表 再定義が論理的にオブジェクトに影響を与えない場合、依存オブジェクトの再コンパイルは不要 |
|
未使用の領域の解放 |
適用不可 |
次の文で ALTER TABLEALTER INDEXALTER MATERIALIZED VIEWALTER MATERIALIZED VIEW LOG |
適用不可 |
適用不可 |
|
オンラインでの索引の作成 |
|
適用不可 |
適用不可 |
DMLをロックしないオンライン索引作成(ワークロードに依存しない透過的な作成が可能) |
|
オンラインでの索引の結合 |
|
適用不可 |
適用不可 |
適用不可 |
|
オンラインでの索引構成表の移動 |
|
適用不可 |
適用不可 |
適用不可 |
|
関連項目: 『Oracle Database管理者ガイド』 |
新規プラットフォームへのデータベースの移行には、トランスポータブル・テクノロジの機能を使用します。トランスポータブル・テクノロジでは、トランスポータブル・データベースとトランスポータブル表領域が提供されます。
トランスポータブル・データベース機能は、データベース全体(ユーザー・データとOracleディクショナリ)を同じエンディアン形式の新しいプラットフォームに移動する場合に使用されます。トランスポータブル・データベースでは、すべてのユーザー・データをソース・データベースからアンロードして移動先データベースにロードする時間のかかる方法を使用せずに、新しいプラットフォームに最小限の停止時間で移行できます。
トランスポータブル表領域機能は、あるデータベースのサブセットを別のデータベースに移動します。エンディアン形式が異なるプラットフォーム間でも可能です。
トランスポータブル表領域機能のクロス・プラットフォーム機能を使用すると、データベース内のすべてのユーザー・データを、異なるエンディアン形式の新しいプラットフォームに移行できます。この方法でトランスポータブル表領域機能を使用すれば、すべてのユーザー・データをソース・データベースからアンロードして移動先データベースにロードする時間のかかる方法を使用せずに、新しいプラットフォームに最小限の停止時間で移行できます。
トランスポータブル表領域機能を使用すれば、データベースには単純なスキーマがあり、トランスポート・プロセス中にデータ・ファイルをコピーする必要がない場合(データ・ファイルが所定の場所で使用されている場合など)、データベースのアップグレードのための停止時間を短縮できます。
|
関連項目:
|
アプリケーションの変更には次に示す機能を使用します。これらの機能を使用することで、アプリケーションのデータベース・オブジェクトの変更に必要なアプリケーションの停止時間を大幅に短縮する(またはゼロにする)ことができます。
エディションベースの再定義により、アプリケーションの使用中にアプリケーションのデータベース・コンポーネントをアップグレードできるため、停止時間を最小化またはゼロにすることができます。管理者が変更を行っても、アプリケーションのユーザーには影響はなく、アップグレードされたアプリケーションがユーザー全員に使用可能になるまで、ユーザーは変更されていないアプリケーションを引き続き実行します。
順調な場合は、ロールオーバーが可能です。アップグレード前とアップグレード後のエディションは同時に使用できるため、アップグレード後のエディションの公開前に開始されたセッションは、自然に終了するまで、引き続きアップグレード前のエディションを使用することができ、新しいセッションではアップグレード後のエディションが使用されます。順調でない場合は、アップグレード前のセッションをすべて終了させないと、新しいセッションでアップグレード後のエディションを使用できません。そのような場合、アプリケーションは少しの間停止することになります。
この後の項では、エディションベースの再定義のエディション、エディショニング・ビューおよびcrosseditionトリガーの機能について説明します。詳細は、『Oracle Database開発ガイド』を参照してください。
エディションは非スキーマ・オブジェクトであり、所有者が存在しません。エディションは単一のネームスペースで作成され、データベース内で複数のエディションが共存できます。エディション機能を使用すると、データベース・オブジェクトをコピーし、コピーしたオブジェクトを分離して再定義できます。
エディションにより、新しいコードのインストールや、データ変更を行うためのプライバシ・メカニズムが提供され、実行中の本番アプリケーションではその変更は見えません。必要な変更がすべて非公開で行われ、1つの原子動作で公開されます。
1つ以上の表の構造を変更する場合、オンライン・アプリケーション・アップグレード中に基礎となる表に加えられる変更からアプリケーション・コードを隔離するには、エディショニング・ビュー機能も使用する必要があります。表は編集できません。
基礎となる表に列が追加され、それらを公開してデータを移入するために、アップグレード後のエディションで新しいエディショニング・ビューが作成されます。(エディションには、基礎となる表のバージョンは使用できません。)
エディショニング・ビューにはトリガーを作成でき、ビューの列はSQLのヒントで使用できます。エディショニング・ビューを定義するSELECT文には、FROMリストとNO WHERE句に表を1つ指定します。SELECTリストを使用して、表の列のサブセットを推定し、通常はそれらの名前を変更します。その結果、このリストにより物理列の論理列へのマッピングが定義されます。
crosseditionトリガーは、エディションベースの再定義の一部として使用され、アップグレード前のエディションとアップグレード後のエディションのデータが互いに一致するように保ちます。アップグレード前のアプリケーションは、変更が適用され、アップグレード前のエディションがアップグレード後のエディションに再定義されている間もそのまま使用されます。
表構造の変更中に、ユーザーが表のデータを変更できるようにするには、forward crosseditionトリガーも使用します。他のユーザーがアプリケーションの古いバージョンを使用し続けている間、アップグレード済のアプリケーションを一部のユーザーが使用できるようにするには、reverse crosseditionトリガーも使用します。crosseditionトリガーは、アップグレードしたアプリケーションをユーザー全員が使用できるようにしたら削除するか無効にするため、アプリケーションの永続的な部品ではありません。
高速ローリング・アップグレードにOracle GoldenGateを使用することを検討してください。ただし、Oracle GoldenGateによるアップグレードでは、データベースの停止時間を最小限またはゼロにできますが、このソリューションを構成するには、運用面での投資がある程度必要になります。必要に応じて、3.7項およびGoldenGateのドキュメントを参照してください。
データ定義言語(DDL)コマンドには、内部構造で排他ロックが必要です。DDLコマンドが発行されると、これらのロックは使用できず、DDLが何秒か後に成功する場合があっても、文はすぐに失敗します。WAITオプション(新しいデフォルト)でDDLを指定すると、この問題が解決します。待機時間をインスタンス全体(初期化パラメータ・ファイル)で指定し、セッション・レベルで待機時間を変更します。
WAITオプションでDDLコマンドを指定すると、すぐにエラーが発生するのではなく、コマンドが成功するまでの猶予期間を定義する柔軟性が得られるため、このようなエラーに対処する追加のアプリケーション・ロジックが必要になります。詳細は、『Oracle Database管理者ガイド』を参照してください。
状態(ENABLEおよびDISABLE)と順序付け(FOLLOWS)はトリガーの起動を制御するためのトリガーです。このような状態が追加されたことで、トリガーの管理制御が向上しています。CREATE TRIGGER文を無効な状態で使用すれば、有効にする前にコンパイルが成功したかどうかを検証できます。また、トリガーの順序をFOLLOWS句で制御できます。詳細は、『Oracle Database開発ガイド』を参照してください。
列のデフォルト値は、NOT NULLとして指定された列のデータ・ディクショナリで管理されます。
DEFAULT値とNOT NULL制約を指定して新しい列を追加する場合、デフォルト値を既存のすべてのレコードに格納する必要がなくなります。この拡張は、既存のデータ量に関係なく動作し、スキーマ変更を数秒以内に行えるほか、領域を消費することもありません。詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Database 11gより前のリリースでは、メタデータはオブジェクト全体の粒度でオブジェクト間の相互の依存性を記録します。(たとえば、PL/SQLの単位PはPL/SQLの単位Qに依存し、ビューVは表Tに依存するとします。)このような場合、依存オブジェクトは場合によって不必要に無効になっていました。たとえば、ビューVが表Tの列C1、C2およびC3にのみ依存し、新しい列C99が追加される場合、ビューVの有効性は論理的に影響を受けません。それにもかかわらず、以前のリリースでは、Vは列C99が加えられたことによって無効になっていました。
Oracle Database 11gリリース1(11.1)から、依存性メタデータはよりきめ細かい粒度レベルで記録されるため、C99が追加されたことでビューVが無効になることはありません。同様に、プロシージャPがパッケージPKGの要素E1およびE2にのみ依存し、要素E99がPKGに追加される場合も、プロシージャPは無効になりません。(Oracle Database 10gでは、PKGに要素E99が加えられると、プロシージャPは無効になります)。
依存対象のオブジェクトの変更に応じて依存オブジェクトが結果的に無効になることが少なくなることで、アプリケーションの可用性を向上させることができます。これは、開発環境や、稼働中のアプリケーションを解析またはアップグレードする場合に役立ちます。スキーマ・オブジェクトに対する変更には互換性が必要であるため、Oracle Databaseのパッチ・セットを適用する場合にこれが役立ちます。詳細は、『Oracle Database開発ガイド』を参照してください。
不可視の索引は、索引を使用できなくしたり、索引を削除したりすることの代替方法です。不可視の索引はDML操作に対して維持されますが、ヒントで索引を明示的に指定しないかぎり、オプティマイザで使用されません。
アプリケーション全体をオフラインにできないときでも、アプリケーションの変更が必要になることがしばしばあります。不可視の索引を使用すると、アプリケーション全体に影響を与えることなく、アプリケーションの特定の操作やモジュールに対して一時的な索引構造を利用できます。さらに、不可視の索引を使用して、索引をすぐに削除せずに削除のテストを行うことができるため、本番環境でテストするための猶予期間ができます。詳細は、『Oracle Database管理者ガイド』を参照してください。
この機能は、表のオンライン再定義後に依存PL/SQLパッケージを再コンパイルする必要性を最小限に抑えます。再定義によってPL/SQLパッケージに論理的な影響が出ない場合、再コンパイルは必要ありません。この最適化はデフォルトで有効です。
再コンパイルが必要な場合、この機能によって、表のオンライン再定義後に依存PL/SQLパッケージを手動で再コンパイルする時間が短縮され、その手間が軽減されます。再コンパイルには、再定義によって論理的に影響を受けないビュー、シノニム、その他の表依存オブジェクト(トリガーを除く)なども含まれます。オンラインでの表の再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。
脚注の凡例
脚注1: DBUAでは停止時間が発生します。停止時間の量は、要因の数によって異なります。アップグレード・オプションとしてDBUAを選択したときの追加の考慮事項は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。Oracle DatabaseソフトウェアのアップグレードにDBUAを使用する手順は、『Oracle Databaseアップグレード・ガイド』を参照してください。
http://support.oracle.com/)を参照してください。http://www.oracle.com/technetwork/database/exadata/index.htm)を参照してください。