1. 高可用性概要
  2. 計画停止時間用Oracle Database高可用性ソリューション

5 計画停止時間用Oracle Database高可用性ソリューション

計画停止時間は、計画外停止時間と同様、業務に悪影響を及ぼします。これは、特に、複数のタイムゾーンのユーザーをサポートする必要がある、または顧客に24時間年中無休でインターネット・アクセスを提供する必要があるグローバル企業に当てはまります。

以前は、次のような作業を実行する場合に停止時間が必要でした。

  • データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークを更新するためのパッチ適用またはシステムの再構成などの定期的なメンテナンス。

  • ハードウェア、データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークの主要アップグレードまたは新規導入などの新規デプロイメント。

この章のトピックは、次のとおりです:

この章の内容は次のとおりです。

5.1 移行用高可用性ソリューション

表5-1は、移行に対する高レベルな高可用性ソリューションの説明です。各ソリューションについては、表に示した各項で説明しています。

表5-1 移行用高可用性ソリューション

移行タイプ 推奨されるOracleソリューション ソリューションの説明 停止時間

異なるプラットフォームへのデータベースの移行

Oracle Data Guard、データ・ポンプ、Recovery ManagerおよびOracle GoldenGate

プラットフォームの移行

Oracle Data GuardまたはGoldenGateの場合数秒から数分

データ・ポンプおよびRecovery Managerの場合数秒から数分

異なるキャラクタ・セットへのデータベースの移行

Oracle GoldenGate

異なるキャラクタ・セットへのデータベースの移行

数秒から数分

プラガブル・データベースまたは別のプラガブル・データベースに移行

プラガブル・データベースのリモート・クローニング

データ・ポンプ、Recovery ManagerおよびOracle GoldenGate

SQL*Plus

マルチテナント・アーキテクチャへの移行

GoldenGateの場合数秒から数分

データ・ポンプおよびRecovery Managerの場合数秒から数分

プラガブル・データベースのリモート・クローニングの場合は数分から数時間

ストレージの移行

Oracle Automatic Storage ManagementおよびOracle Data Guard

Oracle ASM記憶域への移行

Oracle ASMの場合停止時間ゼロ

Data Guardの場合数秒から数分

単一インスタンス・システムからOracle RACクラスタへのデータベースの移行

Oracle Data Guard

単一インスタンス・システムからOracle RACクラスタへのデータベースの移行

数秒から数分

この章の内容は次のとおりです。

5.1.1 プラットフォームの移行

既存のデータベースを現在のシステムとは異なるオペレーティング・システムが実行しているシステムへと移動する場合、異なるプラットフォームへのデータベースの移行が必要です。たとえば、Microsoft WindowsからLinuxへ、またはAIXやHP-UXからOracle Linuxを実行中のOracle Exadata Database Machineへデータベースを移動する場合、データベースの移行が必要です。データベース移行オプションは、ソース・データベースのプラットフォームとソース・データベースのバージョンに大きく依存します。異なるプラットフォームへのデータベースの移行は、次のいずれかのソリューションにより実行できます。

  • Data Guard異機種間フィジカル・スタンバイ

  • データ・ポンプの全体トランスポータブル・エクスポート/インポート

  • データ・ポンプの表領域トランスポータブル・エクスポート/インポート

  • Recovery Managerの非一貫性バックアップを使用したPDBのクラス・プラットフォーム・トランスポート

  • Recovery ManagerのPDBの表領域のクラス・プラットフォーム・トランスポート

次の機能を前述の移行ソリューションと組み合せて使用して、データベース移行の停止時間を短縮できます。

  • Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポート

  • Recovery Managerの非一貫性バックアップを使用したPDBのクラス・プラットフォーム・トランスポート

  • Oracle GoldenGate

この章の内容は次のとおりです。

5.1.1.1 Oracle Exadata Database MachineまたはOracle SuperClusterへのデータベースの移行

Oracle Exadata Database MachineまたはOracle SuperClusterへのデータベースの移行は、この項で説明するプラットフォーム間の移行と同じ方法を使用します。Oracle ExadataおよびOracle SuperClusterのターゲット・プラットフォームについて、表5-2で説明します。

表5-2 設計されたシステムへのプラットフォームの移行

エンジニアド・システム データベース・プラットフォーム

Oracle Exadata Database Machine

Oracle Linux x86 64ビット(リトル・エンディアン)

Oracle SuperCluster

Oracle Solaris SPARC (ビッグ・エンディアン)
5.1.1.2 プラットフォームの移行ソリューション

表5-3に、データベース移行シナリオに使用する推奨ソリューションを示します。各ソリューションについては、表に示した各項で説明しています。

表5-3 データベース移行シナリオおよびソリューション

データベース移行シナリオ 使用するソリューション

同じエンディアン形式のプラットフォームへの移行

  1. Recovery ManagerのPDBの表領域のクラス・プラットフォーム・トランスポート

  2. Data Guardの異種構成

  3. Recovery Managerの非一貫性バックアップを使用したPDBのクラス・プラットフォーム・トランスポート

  4. Recovery ManagerでのクローズしたPDBのクラス・プラットフォーム・トランスポート

  5. Data Guard異機種間フィジカル・スタンバイが使用できない場合のデータ・ポンプの全体トランスポータブル・エクスポート/インポート

  6. データ・ポンプの全体トランスポータブル・エクスポート/インポートが使用できない場合のデータ・ポンプの表領域トランスポータブル・エクスポート/インポート

  7. Data Guard異機種間フィジカル・スタンバイが使用できず、データ・ポンプでは不可能なほど停止時間を短くする必要がある場合のOracle Golden Gate

異なるエンディアン形式のプラットフォームへの移行

  1. データ・ポンプの全体トランスポータブル・エクスポート/インポート

  2. データ・ポンプの全体トランスポータブル・エクスポート/インポートが使用できない場合のデータ・ポンプの表領域トランスポータブル・エクスポート/インポート

  3. データ・ポンプでは不可能なほど停止時間を短くする必要がある場合のOracle Golden Gate
5.1.1.2.1 Data Guardの異種構成

Data Guardは、制限された数のプラットフォームの組合せに対し(WindowsからLinuxなど)、フィジカル・スタンバイ・データベースのプライマリ・システムとは異なるプラットフォームでの実行をサポートします。異機種間プライマリ/スタンバイの組合せをサポートするプラットフォーム間移行は、Data Guardのスイッチオーバー操作のみで実行できます。この方法を使用するには、次の条件を満たす必要があります。

  • プラットフォームの組合せは、My Oracle Supportのノート413484.1にサポート対象として記載されている必要があります。

  • ソース・データベースとターゲット・データベースのOracle Databaseリリースは同じである必要があります。

関連項目:

My Oracle SupportのNote 413484.1 (http://support.oracle.com/)

5.1.1.2.2 データ・ポンプの全体トランスポータブル・エクスポート/インポート

全体トランスポータブル・エクスポート/インポート機能を使用すると、データベース全体をあるプラットフォームから別のプラットフォームにコピーできます。データ・ポンプを使用してエクスポート・ダンプ・ファイルを生成し、必要な場合、ダンプ・ファイルとユーザー定義の表領域のデータ・ファイルをターゲット・データベースに転送し、その後、エクスポート・ダンプ・ファイルをインポートできます。全体トランスポータブル・エクスポートは、Oracle Database 11g リリース2(11.2.0.3)以降を実行しているソース・データベースでサポートされます。

データのトランスポートの一般的な制限および完全トランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』のデータのトランスポートに関する項を参照してください。

全体トランスポータブル・エクスポートでは、データベースの完全なコピーを作成するために必要なすべてのオブジェクトおよびデータがエクスポートされます。次のデータ移動方法の組合せが使用されます。

  • トランスポータブル表領域に存在するオブジェクトは、そのメタデータのみがダンプ・ファイル・セットにアンロードされ、データ自体はデータ・ファイルをターゲット・データベースにコピーしたときに移動されます。コピーする必要のあるデータ・ファイルは、エクスポート操作のログ・ファイルの最後に表示されます。

  • 非トランスポータブル表領域に存在するオブジェクト(SYSTEMやSYSAUXなど)は、ダイレクト・パス・アンロードおよび外部表を使用して、そのメタデータとデータの両方がダンプ・ファイル・セットにアンロードされます。

データベースを新しいプラットフォームに移行するのに必要な時間は次の要因により異なります。

  • データ・サイズ

  • メタデータ・サイズ

データベース移行の手順の概要は、次のとおりです。

  1. 新しい空のデータベースをターゲット・プラットフォーム上に作成します。
  2. アプリケーションを停止します(データへの読取り専用アクセスは引き続き許可されます)。
  3. ソース・データベースでユーザー表領域を読取り専用にします。
  4. ソース・データベースの全体トランスポータブル・エクスポートを実行します。
  5. ユーザー表領域のデータ・ファイルとエクスポート・ダンプ・ファイルを宛先システムに送信します。
  6. RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します(必要な場合)。
  7. ターゲット・データベースへの全体トランスポータブル・インポートを実行します。
  8. ターゲット・データベースでユーザー表領域を読取り/書込みにします。
  9. アプリケーションを開始し、ターゲット・データベースに接続します。

移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体トランスポータブル・エクスポート/インポートとあわせて使用します。

関連項目:

詳細は、「データベース移行の停止時間を短縮する方法」の項を参照してください。

5.1.1.3 データ・ポンプの表領域トランスポータブル・エクスポート/インポート

表領域トランスポータブル・エクスポート/インポート機能を使用して、ユーザー定義の表領域全体を、あるプラットフォームのデータベースから別のプラットフォームで実行しているデータベースにコピーできます。表領域トランスポータブル・エクスポートでは、ユーザー定義の表領域の特定のセット内にある表のメタデータ(およびその表の依存オブジェクト)のみがエクスポートされます。表領域データ・ファイルは別の操作でコピーされます。次に、トランスポータブル表領域インポートが実行され、メタデータを含むダンプ・ファイルのインポートと、使用するデータ・ファイルの指定が行われます。表領域トランスポータブル・エクスポートは、バージョン10.0互換以降のソース・データベースおよびターゲット・データベース用の異なるプラットフォーム間でサポートされます。

データのトランスポートの一般的な制限および表領域のトランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』のデータのトランスポートに関する項を参照してください。

データベースを新しいプラットフォームに移行するのに必要な時間は次の要因により異なります。

  • データ・サイズ

  • メタデータ・サイズ

高度な手順は次のとおりです。

  1. 新しい空のデータベースをターゲット・プラットフォーム上に作成します。
  2. アプリケーションを停止します(データへの読取り専用アクセスは引き続き許可されます)。
  3. トランスポート操作に必要なオブジェクトを、ターゲット・データベースにインポートします。
  4. ソース・データベースでユーザー表領域を読取り専用にします。
  5. ソース・データベースの全体トランスポータブル・エクスポートを実行します。
  6. ユーザー表領域のデータ・ファイルとエクスポート・ダンプ・ファイルを宛先システムに送信します。
  7. RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します(必要な場合)。
  8. すべてのユーザー表領域のトランスポータブル・インポートを実行します。
  9. トランスポートできないデータベース・オブジェクトをエクスポートおよびインポートします。
  10. ターゲット・データベースでユーザー表領域を読取り/書込みにします。
  11. アプリケーションを開始し、ターゲット・データベースに接続します。

移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの表領域トランスポータブル・エクスポート/インポートとあわせて使用します。

関連項目:

データベース移行の停止時間を短縮する方法

5.1.1.4 データベース移行の停止時間を短縮する方法

以降の項で説明する方法を前述の移行方法と組み合せて使用して、データベース移行の停止時間を短縮できます。

5.1.1.4.1 Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポート

データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートを使用したデータベースの移行に必要な停止時間は、主に次の2つの要因で決定されます。

  • データ・サイズ

  • メタデータ・サイズ

移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートとあわせて使用します。移行による停止時間は、ソース・データベースをオンラインにしたまま、ほとんどのデータの移動を許可することにより短縮されます。Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートとあわせて使用する場合、必要な停止時間は、主に次の要因で決定されます。

  • データの変更率

  • メタデータ・サイズ

RMANにより、ソース・システムのユーザー定義の表領域の非一貫性バックアップを作成し、それをターゲット・システムにリストアすることで、ソース・システムのデータベースをオンラインにしたままで、データベースの大部分をターゲット・システムにトランスポートできます。最初のバックアップ/リストア操作は時間がかかる可能性があるので、非一貫性バックアップで生成されたデータ・ファイルには、クロス・プラットフォームの増分バックアップを使用して、1回または複数回のロール・フォワードが行われる可能性があります。トランスポートを完了するためにデータ・ファイルの一貫性を保つには、表領域が読取り専用モードのときに取得した、最終クロス・プラットフォーム増分バックアップを適用します。最後の手順は、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートを使用して移行を完了することです。

ターゲット・システムにデータベースを移動する手順の概要は、次のとおりです。

フェーズ1: 準備フェーズ

  1. すべてのユーザー定義表領域のRMANクロス・プラットフォーム非一貫性バックアップを作成します。

  2. クロス・プラットフォーム非一貫性バックアップをターゲット・システムにリストアします。ターゲット・システムで作成されたターゲット・データ・ファイルは外部データ・ファイルと呼ばれます。

フェーズ2: ロール・フォワード・フェーズ

  1. すべてのユーザー定義表領域のRMANクロス・プラットフォーム増分バックアップを作成します。

  2. クロス・プラットフォーム増分バックアップを適用することによって、ターゲット・システムの外部データファイルをリカバリします。

    ロール・フォワード・フェーズは必要な回数繰り返され、ソース・データベースまで外部データ・ファイルを取り込みます。

フェーズ3: トランスポート・フェーズ

  1. アプリケーションを停止します。
  2. ユーザー定義の表領域を読取り専用にします。
  3. フェーズ2(ロール・フォワード・フェーズ)をもう一度繰り返します。
  4. データ・ポンプの全体トランスポータブル・エクスポート/インポートを使用してデータベースを移行するか、またはデータ・ポンプの表領域トランスポータブル・エクスポート/インポートを使用してユーザー定義の表領域を移行します。
  5. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:

『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』

5.1.1.4.2 Oracle GoldenGateを使用した移行の停止時間の短縮

Oracle GoldenGateを使用して移行の停止時間を短縮します。移行による停止時間は、ソース・データベースをオンラインにしたまま、ターゲット・データベースを作成し、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。

高度な手順は次のとおりです。

  1. Oracle GoldenGate Extractグループを開始して、実行中のデータの変更を抽出します。
  2. データ・ポンプの全体トランスポータブル・エクスポート/インポート、またはデータ・ポンプの表領域トランスポータブル・エクスポート/インポートを使用して、ターゲット・データベースを作成します。
  3. Oracle GoldenGate Replicatグループを開始し、ターゲット・データベースの作成中に変更された行を再同期します。
  4. アプリケーションを停止します。
  5. Oracle GoldenGate Replicatの終了を待機して、証跡ファイルの残りの変更を適用します。
  6. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:

Oracle GoldenGate

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1276058.1のOracle GoldenGateベスト・プラクティス: Oracleソース・データベースからのインストール

5.1.2 異なるキャラクタ・セットへのデータベースの移行

Oracle GoldenGateを使用してキャラクタ・セットの移行の停止時間を短縮します。キャラクタ・セットの移行による停止時間は、ソース・データベースをオンラインにしたまま、ターゲット・データベースを作成し、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。

高度な手順は次のとおりです。

  1. 目的のキャラクタ・セットで空のターゲット・データベースを作成します。
  2. 変更－同期「抽出」グループを開始して、実行中のデータの変更を抽出します。
  3. データ・ポンプの全体トランスポート不可能なエクスポート/インポートを実行します。インポート・プロセス中に、データは新しいキャラクタ・セットに自動的に変換されます。
  4. 変更-同期「Replicat」グループを開始し、ターゲット・データベースの作成中に変更された行を再同期します。
  5. アプリケーションを停止します。
  6. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:

Oracle GoldenGate

5.1.3 マルチテナント・アーキテクチャへの移行

非コンテナ・データベース(非CDB)または切断されたプラガブル・データベース(PDB)の、ターゲットCDB内のPDBへの移行は、次のいずれかのソリューションにより実行できます。

  • CREATE PLUGGABLE DATABASE文

  • データ・ポンプの全体トランスポータブル・エクスポート/インポート

  • データ・ポンプの表領域トランスポータブル・エクスポート/インポート

表5-4 プラガブル・データベース移行ソリューション

解決策 使用する状況

CREATE PLUGGABLE DATABASE文

非CDBまたは切断されたPDBがOracle Database 12 cであり、ターゲットCDBと同じエンディアン形式の場合に使用します。

データ・ポンプの全体トランスポータブル・エクスポート/インポート

非CDBがOracle Database 11g リリース2(11.2.0.3)以降であるか、非CDBがCDBとは異なるエンディアン形式である場合に使用します。

データ・ポンプの表領域トランスポータブル・エクスポート/インポート

非CDBのバージョンがOracle Database 11g リリース2(11.2.0.3)より前の場合に使用します。

プラガブル・データベースのリモート・クローニング

既存のPDBをあるCDBから別のCDBへクローニングする場合に使用します。

以降の項で説明する方法を前述のソリューションと組み合せて使用して、移行の停止時間を短縮できます。

マルチテナント・アーキテクチャへの移行時の停止時間を短縮するためにこれらの機能を使用することは、異なるプラットフォームへのデータベースの移行の停止時間を短縮するためにこれらの機能を使用することと同じです。

関連項目:

Oracle MAAホワイト・ペーパー『高可用性ベスト・プラクティス: サービスとしてのデータベース統合の基盤』(http://www.oracle.com/goto/maa)

Oracle Database管理者ガイド

5.1.4 Oracle ASM記憶域への移行

以降の項では、Oracle ASM記憶域への移行について説明します。

この章の内容は次のとおりです。

5.1.4.1 Data Guardを使用したOracle ASM管理対象ストレージへの移行

データベースでストレージの管理にOracle ASMを現在使用してしていない場合、データベースの全体または一部をOracle ASMに移行して、データベース管理を簡略化できます。Data Guardを使用して、Oracle ASMへの移行時の停止時間を最小化します。高度な手順は次のとおりです。

  1. Oracle ASM記憶域を使用したスタンバイ・データベースの作成
  2. Data Guardスイッチオーバーを実行する時間

関連項目:

5.1.4.2 Oracle ASMリバランスを使用した新しいストレージへの移行

既存のストレージ・デバイスがすでにOracle ASMによって管理されており、新しいストレージに配置される予定で、新しいストレージは既存のデータベース・サーバーまたはクラスタに接続される場合、Oracle ASMを使用してストレージの移行を実行します。Oracle ASMを使用して、新しいストレージのすべてのディスクを追加し、既存のストレージからすべてのディスクを削除できます。Oracle ASMは、データベースが稼働したままの状態で、自動的にデータのリバランスを行い、新規ストレージに移行します。既存のストレージ・デバイスを削除する前に、リバランスが完了したかどうか確認してください。

高度な手順は次のとおりです。

  1. 新しいストレージを既存のシステムに接続して構成します。
  2. Oracle ASMコマンドを使用して、新しいストレージをOracle ASMに追加し、元のストレージをOracle ASMから削除します。
  3. データを新しいストレージに移動するOracle ASMリバランス操作の完了を待ちます。
  4. 元のストレージ・デバイスを切断します。

関連項目:

Oracle Automatic Storage Management管理者ガイド

5.1.4.3 オンライン・データ・ファイルの再配置によるOracle ASMの移行

ALTER DATABASE MOVE DATAFILE SQL文を使用して、データ・ファイルをASMに再配置する方法の詳細は、「オンライン・データファイルの名前変更と再配置」を参照してください。

5.1.5 単一インスタンス・システムからOracle RACクラスタへのデータベースの移行

単一インスタンスのOracle Databaseを実行している非クラスタ・システムからOracle RACを実行しているクラスタ環境への移行時にData Guardを使用するか、位置の変換を実行できます。必要な停止時間は使用するオプションに応じて異なります。

関連項目:

単一インスタンスOracleデータベースのOracle RACおよびOracle RAC One Nodeへの変換の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle MAAホワイト・ペーパー『Oracle RACの高速スタンバイ・デプロイメント』(http://www.oracle.com/goto/maa)

5.2 動的およびオンライン・リソース・プロビジョニング

システムおよびデータベースの変更には、次の各項で説明する動的リソース・プロビジョニング機能を使用します。

この章の内容は次のとおりです。

5.2.1 オンライン・データファイルの名前変更と再配置

すべてのデータファイルは、オンライン(使用可能)またはオフライン(使用不可能)のいずれかです。個々のデータ・ファイルまたは一時ファイルの可用性は、ファイルをオフラインにするか、オンラインにして変更できます。オフラインのデータファイルには、ファイルが再びオンラインになるまでアクセスできません。

Oracle Database 12cリリース1(12.1)から、SQLを使用して、データベースがオープンで、ファイルにアクセスしている間に、オンライン・データ・ファイルを1つのフィジカル・ファイルから別のファイルへ移動できます。

ALTER DATABASE MOVE DATAFILE SQL文を使用して、オンライン・データファイルの名前変更や再配置が可能です。この文を使用すると、データベースのオープン時にユーザーがデータ・ファイルにアクセスしている際、データ・ファイルを名前変更または再配置できます。

オンライン・データファイルを名前変更または再配置すると、データベースの制御ファイルに記録されている、データファイルへのポインタが変更されます。また、ファイルは、オペレーティング・システム・レベルでも物理的に名前変更または再配置されます。

次のいずれかのタスクを実行する場合、ユーザーがデータファイルにアクセスできるようにする必要があるため、オンライン・データファイルを名前変更または再配置することができます。

  • あるタイプの記憶域から別のタイプの記憶域に、データファイルを移動します。

  • 頻繁にアクセスしないデータファイルを、より低コストの記憶域に移動します。

  • 表領域を読取り専用にし、そのデータファイルを1回のみ書込み可能な記憶域に移動します。

  • データベースをOracle Automatic Storage Management(Oracle ASM)に移動します。

  • データ・ファイルの名前をより説明的な名前に変更

関連項目:

オンライン・データ・ファイルの名前変更または再配置については、『Oracle Database管理者ガイド』を参照してください。

5.2.2 データベースの動的再構成

Oracleでは、サービスを中断することなく、ハードウェアの要求の変化に適応できるように、データベースの動的再構成のサポートを継続的に拡大しています。

Oracle Clusterwareのオンラインでのリソース属性の変更を使用すると、リソースの特定の属性を変更でき、変更を有効にするためにリソースを再起動する必要がありません。オンラインでのリソース属性の変更は、SRVCTLおよびCRSCTLコマンドを使用すれば可能です。

Oracle Databaseは、ハードウェアおよびデータベース構成への様々な変更に対して、次の機能を提供して動的に対応します。

  • 対称型マルチプロセッシング(SMP)サーバーからのプロセッサの追加および削除

  • Oracle RAC環境でのノードとインスタンスの追加および削除

  • 自動共有メモリー管理を使用した、共有メモリーの割当ての動的な拡張と縮小、およびオンラインでのメモリーのチューニング

  • データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるデータベース・ディスクの追加および削除

  • データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるストレージ・アレイまたはExadataセルの追加および削除

  • Exadata Databaseサーバー、Exadata Storage Server、またはExadataラックを追加して拡張し、停止時間なしで既存のExadata Elasticシステムを変更

  • Oracle ASMを使用したデータベース・ストレージ全体のI/Oロードの自動リバランス

  • ストレージ構成が変更するたびに自動的にデータベース・ストレージのリバランスを行う、Oracle ASMを使用したディスクの追加または削除時のオンラインによるデータ・ファイルの移動

  • リソース・マネージャのコンシューマ・グループおよびプランを使用して、データベース・セッション・リソース使用量を動的に制御

  • 次のいずれかのSQL*Plus文を使用することで、インスタンスを停止せずに、ほとんどすべての初期化パラメータを変更

    • ALTER SESSION文は、セッション中にパラメータの値を変更します。

    • ALTER SYSTEM文は、インスタンスの期間中、インスタンスのすべてのセッションでパラメータの値を変更します。

これらの機能により、エンタープライズ・グリッド・コンピューティングの基本要件であるシステム変更およびキャパシティ・オンデマンド・プロビジョニングがコストなしで実現されます。

関連項目:

自動メモリー管理をサポートするプラットフォームの詳細は、『Oracle Database管理者ガイド』を参照してください。

柔軟な構成の変更の詳細は、『Oracle Exadata Database Machineメンテナンス・ガイド』を参照してください。

5.2.3 メモリー管理の自動チューニング

2つのメモリー管理初期化パラメータ、MEMORY_TARGETとMEMORY_MAX_TARGETは、システム・グローバル領域(SGA)、プログラム・グローバル領域(PGA)およびOracle Databaseの実行に必要なその他のメモリーの自動管理を可能にします。

MEMORY_MAX_TARGETパラメータは、MEMORY_TARGETの動的な最大値を指定します。

表5-5 MEMORY_MAX_TARGETおよびMEMORY_TARGET

1つ目の条件 2つ目の条件 結果

MEMORY_MAX_TARGETを省略する

MEMORY_TARGETを省略する

初期化パラメータはデフォルト値(0)のままで、Oracle Databaseでは、メモリーは自動的にチューニングされません。

MEMORY_MAX_TARGETを省略する

MEMORY_TARGETの値を含める

データベースでは、MEMORY_MAX_TARGETがMEMORY_TARGETの値に自動的に設定されます。

MEMORY_TARGETを省略する

MEMORY_MAX_TARGETの値を含める

MEMORY_TARGETパラメータがデフォルトでゼロになります。

Oracle Databaseでは非集中型ポリシーを使用して、SGAおよびPGAの各サブコンポーネントのメモリーを解放して取得します。また、メモリーのグラニュルをあまり必要としないコンポーネントから、より必要とするコンポーネントに転送するようオペレーティング・システムに要求することにより、メモリーを自動的にチューニングします。メモリー転送の粒度は、現在の空きメモリーと、サービスに支障のない基本レベルを維持するためにオペレーティング・システムが必要とするメモリー量によって決まります。

注意:

MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータを使用する自動メモリー管理は、Linux、Windows、Solaris、HP-UXおよびAIXでサポートされます。サポートされているすべてのプラットフォームの詳細は、Oracle Database管理者ガイドを参照してください。

5.2.4 データ・ファイル、制御ファイルおよびログ・ファイルの分散の自動化

Oracle ASMでは、使用可能なディスク全体にデータ・ファイル、制御ファイルおよびログ・ファイルを自動的に分散します。ディスク、Exadataセルまたはストレージ・アレイの追加と削除など、ストレージ構成に変更があった場合に、データベース・ストレージのリバランスが行われます。Oracle ASMは、データベース・ファイルのミラー化を通じて冗長性を提供するとともに、使用可能なすべてのディスクにわたりデータベース・ファイルを自動的にストライプ化することにより最適なパフォーマンスを提供します。

関連項目:

Oracle ASMの詳細は、『Oracle Database概要』および『Oracle Automatic Storage Managementの管理者ガイド』を参照してください。

5.3 オンライン再編成および再定義

可用性および管理性を強化する1つの方法として、データの再編成操作中、データベースへの通常のアクセス権をユーザーに与えます。Oracle Databaseのオンライン再編成および再定義機能により、管理者は、データベースへの通常のアクセス権をユーザーに与えたまま、表の物理属性を変更したり、データおよび表構造の両方を変換したりするなど多くの柔軟性が得られます。この機能によって、データの可用性、問合せのパフォーマンス、レスポンス時間およびディスク領域の使用率が向上します。これらは、すべてミッションクリティカルな環境において重要で、アプリケーションのアップグレード・プロセスをより簡単、安全かつ高速なものにします。

オンライン再編成および再定義アーキテクチャには次のような利点があります。

  • オンラインの表編成および再定義:

    • 表の物理属性をオンラインで変更します(新しい場所への表の移動、表のパーティショニング、1つの構成(ヒープ構成など)から別の構成(索引構成など)への表の変換、およびデータ圧縮(高度な行圧縮)の有効化など)。

    • 名前、型、サイズなどの多くの論理属性を変更します。列を追加、削除またはマージできます。ただし、表の主キーは変更できません。

    • REDEF_TABLEプロシージャは、1つのコマンドで1つの表のオンライン表再構成を自動化します(Oracle Database 12cでの新機能)。

    • 未使用の列をオンラインに設定します(Oracle Database 12cでの新機能)。

  • オンライン索引操作:

    • 索引をオンラインで作成し、それらを同時に分析します。論理ROWIDの物理的推測コンポーネント(索引構成表の2次索引およびマッピング表で使用)のオンライン修復も使用できます。

    • 索引構成表および2次索引をオンラインで再編成して、再編成のメンテナンス・ウィンドウを排除できます。2次索引は、ブロック・ヒント(物理的推測)の効率的な使用をサポートします。索引編成表で2次索引に格納される論理ROWIDの無効な物理的推測のオンライン修復も実行できます。

    • 2次索引を再構築せずに索引構成表または表パーティションを再編成できるため、再編成のメンテナンス期間が短縮されます。

    • Oracle Database 12cの新機能には、オンラインでの索引の削除、索引の表示可能/不可視の変更、オンラインでの索引使用禁止の変更、およびオンラインでの制約の削除があります。

  • パーティション化された表のオンライン移動および分割時に索引を維持

  • パーティション化されていない表のオンライン移動時に索引を維持

  • 高度な圧縮オプションのライセンスを所有している場合は、基本圧縮、高度な行圧縮、およびオンラインのパーティションに対するハイブリッド列圧縮が可能。

  • アドバンスト・キュー、クラスタ表、マテリアライズド・ビューおよび抽象データ型(オブジェクト)に対するオンラインで再編成のサポート

  • デフォルト値による高速なADD COLUMN操作(すべての行をデフォルト値に更新する必要はありません)

  • 不可視の索引によるアプリケーションの移行とテストの高速化

    • 明示的なヒントで移行の速度を上げ、終了したらヒントを削除します。

    • 新しく作成された索引の早まった使用を防止します。

    • 必要に応じて、索引を可視化してDROP INDEXの影響をテストするため、索引の再構築は必要ありません。

  • DML操作の実行を中断しない索引のオンライン作成(DMLの排他ロックは不要)

  • オンラインでの表DDL操作の簡略化(停止ではなく、アクティブなDML操作を待つオプション)

  • 複数のパーティションを再定義する完了時間を短縮するための、単一の再定義セッションでの複数のパーティションの再定義(Oracle Database 12cの新機能)。

  • これらの表の再定義の停止時間をなくすための、定義された仮想プライベート・データベース(VPD)ポリシーのある表の再定義(Oracle Database 12cの新機能)。

  • 最適化されたマテリアライズド・ビュー・ログの処理によるSYNC_INTERIM_TABLEパフォーマンスの向上(Oracle Database 12cの新機能)。

  • 最適化されたマテリアライズド・ビュー・ログの処理によるFINISH_REDEF_TABLEパフォーマンスの向上(Oracle Database 12cの新機能)。

物理表属性の変更、およびデータと表構造の両方を変換する機能は、Oracle8iリリース以降に使用可能になりました。データ再編成の機能を表5-6に包括的に示します。

表5-6 各リリースの新規データ再編成機能

操作 Oracle Database 9i Oracle Database 10gリリース1 Oracle Database 10gリリース2 Oracle Database 11g Oracle Database 12c

パッケージDBMS_REDEFINITIONを使用したオンライン再編成

表記憶域パラメータの変更

異なる表領域への表の移動

パラレル問合せのサポートの追加

パーティション化サポートの追加または削除

表の再作成による断片化の回避

表から索引構成表への変更、またはその逆

列の追加または削除

関数を使用した列の変換
  • 権限、制約およびトリガーのクローン
  • LONGをLOBに変換
  • 一意のキーを使用した再編成
  • 表の順序を決定する列の指定
  • 単一パーティションの再編成
  • アドバンスト・キュー表とクラスタ表
  • ADTを含む表
  • 統計の保持とクローン
  • CHECKおよびNOT NULL制約のクローン
  • ネストされた表の依存オブジェクトのコピー
  • マテリアライズド・ビュー・ログまたはマテリアライズド・ビューを含む表
  • 再定義がオブジェクトに論理的に影響しない場合、依存オブジェクトの再コンパイルなし

複数パーティションの再定義完了にかかる時間を短縮するための、単一の再定義セッションでの複数パーティションの再定義。

表の再定義に対する停止時間をなくすために、Oracle Virtual Private Databaseポリシーが定義されている表の再定義。

オンラインでの索引の削除(リリース10gおよび11gでの索引のオンライン作成/再構築)

索引の表示可能/不可視の変更、オンラインでの索引使用禁止の変更

オンラインでの制約の削除(リリース11 gのオンラインでの制約作成)

オンラインでの未使用列の設定(リリース11gのオンラインでの列の追加)

単一セッションでのオンライン、複数パーティションの再定義

Oracle Virtual Private Databaseポリシーを含む表のオンライン再定義

新しいREDEF_TABLEプロシージャを使用した単一コマンドの再定義

エディションベースの再定義の拡張

SQLを使用したオンライン表操作

        

パーティションのオンライン移動

パーティションのオンライン分割

オンラインでの表の移動

未使用領域の再利用

該当なし

次の文でSHRINK SPACE句を使用:

  • ALTER TABLE
  • ALTER INDEX
  • ALTER MATERIALIZED VIEW
  • ALTERMATERIALIZEDVIEWLOG

該当なし

該当なし

該当なし

オンラインでの索引の作成

CREATE INDEX emp.ename.idx ON emp(ename) ONLINE;

  • パラレル操作をサポート

  • パーティションをサポート

  • クラスタを除くすべての索引タイプ

該当なし

該当なし

DMLをロックしないオンライン索引作成(ワークロードに依存しない透過的な作成が可能)

該当なし

オンラインでの索引の結合

ALTER INDEX emp.ename_idx COALESCE;

  • パラレル操作をサポート

  • パーティションをサポート

  • すべての索引タイプ

該当なし

該当なし

該当なし

該当なし

オンラインでの索引構成表の移動

ALTER TABLE emp MOVE ONLINE;

  • パラレル操作はサポート対象外

  • パーティションをサポート

  • 索引構成表のみ

該当なし

該当なし

該当なし

該当なし

5.4 システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション

Oracleでは、あらゆるタイプの計画メンテナンスに対して停止時間を防止、許容および短縮するための高可用性ソリューションを提供しています。表5-7および表5-8では、計画停止時間用の各種Oracle高可用性ソリューション、および各ソリューションで達成可能な停止時間について説明しています。

どのような場合でも、計画メンテナンス操作を実行する前に広範囲なテストを行うことをお薦めします。各Oracle高可用性アーキテクチャのすべての計画停止時間タイプの達成可能なリカバリ時間に関する概要は、「高可用性アーキテクチャ」の表を参照してください。

表5-7 システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション

メンテナンス・タイプ 推奨されるOracleソリューション ソリューションの説明 停止時間

オペレーティング・システムおよびハードウェアのアップグレード

Oracle Real Application ClustersおよびOracle Clusterware、Oracle RAC One NodeまたはData Guard Standby-First Patchの適用

オペレーティング・システムのアップグレードおよびハードウェアのアップグレード

Oracle RACおよびOracle RAC One Nodeの場合停止時間ゼロ。

Standby-First Patchの適用の場合数秒から数分

Oracle仮パッチまたは診断パッチ

Oracle Real Application ClustersおよびOracle Clusterware、Oracle RAC One Nodeまたはオンライン・パッチ

オンライン・パッチの適用

停止時間なし

ローリング・アップグレードの実行で適用できないパッチは、パッチ適用による可用性の影響が少ないOPatchユーティリティのMINIMIZE_DOWNTIMEオプションで適用できます。

Oracle DatabaseおよびOracle Grid Infrastructureバンドル・パッチ、パッチ・セット・アップデート(PSU)、クリティカル・パッチ・アップデート(CPU)

Data Guard Standby-First Patchの適用、Oracle Real Application ClustersおよびOracle ClusterwareまたはOracle RAC One Node

Data Guardを使用したシステムおよびクラスタのアップグレード

Standby-First Patchの適用の場合数秒から数分

Oracle RACおよびOracle RAC One Nodeの場合停止時間ゼロ

Oracle DatabaseおよびOracle Grid Infrastructureパッチ・セット(Oracle Database 12.1.0.1から12.1.0.2など)およびメジャー・アップグレード(Oracle Database 12.1から12.2など)

Oracle Data Guard

Data Guardを使用したDatabaseのローリング・アップグレード

数秒から数分

Exadata Storageのアップグレード

Exadata PatchMgrユーティリティ

Exadata Storage Serverソフトウェアのローリング・アップグレード

停止時間なし

アプリケーション・アップグレード

アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード

アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード

停止時間なし

表5-8 MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画メンテナンス・マトリックス

イベント Bronze、Silver、GoldおよびPlatinumサービス・レベル層のソリューション 予想される停止時間

移行

関連項目: http://www.oracle.com/goto/maaのMAAホワイト・ペーパー『データベース統合の高可用性ベスト・プラクティス: Database-as-a-Serviceの基盤』のマルチテナント・アーキテクチャの移行に関する項

状況により異なる

動的およびオンライン・リソース・プロビジョニングまたは

オンライン再編成および再定義

すべての層: それぞれのPDB内で選択されたオブジェクトのオンライン再編成および再定義

関連項目: 「動的およびオンライン・リソース・プロビジョニング」および「オンライン再編成および再定義」

ゼロ

オンラインパッチ

すべての層: 関連している場合は、CDB全体のオンライン・パッチ適用が可能

ゼロ

データベースおよびグリッド・インフラストラクチャのパッチおよび個別パッチ

すべての層: PDBを切断して、ソフトウェア・リリースがターゲット対象である別のCDBに接続可能

SILVER: 関連する場合は、CDB全体で、Oracle RAC One Nodeのローリング・アップグレードを使用可能

GOLD/PLATINUM: 関連する場合は、CDB全体で、Oracle RACのローリング・アップグレードを使用可能。PLATINUM層には、アプリケーション・コンティニュイティも追加されます。

GOLD: CDB全体で、Data Guard Standby-First Patch適用を使用でき、Data Guardスイッチオーバーを発行可能

PLATINUM: CDB全体で、Data Guard Standby-First Patch適用を使用でき、Data Guardスイッチオーバーとアプリケーション・コンティニュイティを発行可能

データファイル・コピー・オプションがない場合、予想される時間は数秒から数時間

サービスの再配置によりゼロ

サービスの再配置によりゼロ

アプリケーションの停止なし

数秒から数分

アプリケーションの停止なし

データベース・パッチセット

すべての層: PDBを切断して、ソフトウェア・リリースがターゲット対象である別のCDBに接続可能

GOLD/PLATINUM: パッチセットおよびデータベースのメジャー・リリースに対して、CDB全体で、Data Guardデータベース・ローリング・アップグレードを使用可能

PLATINUM: ターゲットのソフトウェア・バージョンに存在するセカンダリGoldenGateレプリカに、CDBまたはPDBをフェイルオーバー可能

データファイル・コピー・オプションがない場合、予想される時間は数秒から数時間

数秒から数分

停止時間ゼロ

アプリケーション・アップグレード

PLATINUM: エディションベースの再定義は、この機能を利用するために、開発者による設計が必要

PLATINUM: ターゲット・アプリケーションを変更すれば、PDBをGoldenGateレプリカにスイッチオーバー可能

関連項目: 「アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード」

ゼロ

移動サービスにより、停止時間はゼロからほぼゼロ

この章の内容は次のとおりです。

関連項目:

SQL ApplyでData Guardを使用してOracle Databaseをアップグレードするには、『Oracle Data Guard概要および管理』 を参照してください。

ローリング・アップグレードのベスト・プラクティスに関するホワイト・ペーパー(http://www.oracle.com/goto/maa)を参照してください。

5.4.1 オペレーティング・システムのアップグレードおよびハードウェアのアップグレード

システムとハードウェアのアップグレード時の停止時間を回避するには、Oracle RACを使用するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeを使用できます。

「Data Guardを使用したシステムおよびクラスタのアップグレード」に示すように、Oracle RACまたはOracle RAC One Nodeを使用してアップグレードを実行できない場合は、Data Guardとフィジカル・スタンバイ・データベースを使用するソリューションをお薦めします。もしくは、「Oracle Clusterwareを使用したローリング・アップグレード」に示すように、Oracle Clusterwareを使用したコールド・クラスタ・フェイルオーバーを使用することもできます。

次のリストに、Oracle RACを使用してアップグレードする場合の手順の高レベルの概要を示します。

  1. 次の前提条件チェックを実行します。

    • 計画メンテナンスがオペレーティング・システムの観点からローリング形式で行うことができるかどうかを確認します。

    • データベースとクラスタウェアのバージョンが、新規システムおよびハードウェアの変更で動作保証されているかどうかを確認します。

  2. クラスタ内の複数のインスタンスでアプリケーション・サービスが稼働している場合は、アプリケーション・サービスを停止します。アップグレード対象のインスタンスのみでアプリケーション・サービスが稼働している場合は、クラスタ内の別のノードにサービスを再配置します。

    高速アプリケーション通知(FAN)を使用している場合、アプリケーション・サービスを停止すると、接続が接続先インスタンスから暗黙的にリダイレクトされます。

  3. IMMEDIATEオプションを指定して接続先インスタンスを停止します。
  4. Oracle Clusterwareを停止して無効にします。

    Oracle Clusterwareを無効にすると、自動起動しなくなります。

  5. メンテナンスを実行します。
  6. Oracle Clusterwareを有効にして、起動します。

    この手順により、データベース・インスタンスが暗黙的に起動されます。

  7. アプリケーション・サービスを起動します。

    この手順により、FANを使用している場合、接続先インスタンスに接続が暗黙的にリダイレクトされます。

  8. 次のノードですべての手順を繰り返します。

使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

5.4.2 オンライン・パッチの適用

通常、仮パッチおよび診断パッチは、ローリング方法で一度に1つのノードに適用されます。ソフトウェア・ホームへのパッチの適用中、ホームから実行中のソフトウェア(データベース・インスタンスなど)はシャットダウンされます。ただし、パッチを緊急にインストールする必要があり、現時点でシャットダウンできない場合には、ソフトウェアが実行中のまま、適格な仮パッチおよび診断パッチをオンラインで適用できます。

次の場合にのみ、パッチをオンラインで適用してください。

  • パッチのREADMEには、オンラインで適用できることが記載されています。

  • パッチはすぐに適用する必要がありますが、通常(オフライン)バージョンのパッチを適用する場合は、データベース・インスタンスを停止できません。

OPatchコマンドライン・ユーティリティを使用してOracleデータベースでオンライン・パッチ適用を実行できます。

オンライン・パッチを実行するときは、次の点に注意してください。

  • オラクル社では、正規の個別または診断パッチをコンボ・パッチとして提供しており、同じバグ修正でオンライン・パッチとオフライン・パッチの両方が含まれています。

    そのため、このオンライン・パッチを最初に適用すると、計画外停止時間を回避できます。ただし、オンライン・パッチではメモリーのオーバーヘッドが発生するため、計画停止時にオンライン・パッチをロールバックしてオフライン・パッチを適用する必要があります。

  • オンライン・パッチを適用すると、各Oracleプロセスではパッチの適用時にプログラム・グローバル領域(PGA)のメモリーを多く使用するため、システムのメモリー消費が増加します。オンライン・パッチを適用する前に、メモリー要件を考慮してください。各オンライン・パッチは独自のものであり、メモリー要件はパッチごとに異なります。パッチをまずテスト・システムに適用することで、本番システムでのオンライン・パッチの効果を評価し、追加のメモリー使用量を予測できます。

関連項目:

My Oracle Supportのノート761111.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=761111.1)『RDBMSオンライン・パッチ(ホット・パッチ)』を参照してください。

ローリング・アップグレードおよびローリング・パッチの概要は、『Oracle Databaseアップグレード・ガイド』を参照してください。

オンラインでのパッチ適用とOPatchユーティリティの詳細は、『Oracle OPatchユーザー・ガイド』を参照してください。

5.4.3 Data Guardを使用したシステムおよびクラスタのアップグレード

Data Guardとフィジカル・スタンバイ・データベースは、Oracle RACローリング・アップグレードを使用してアップグレードできないシステムとクラスタのアップグレード(Oracle Grid Infrastructureのアップグレードなど)を実行する場合に推奨されるソリューションです。

Data Guardは、Oracle ASM、Oracle RACおよび64ビット・システムへの移行、WindowsとLinux間での移行、あるいは同じプロセッサ・アーキテクチャのプラットフォームへの移行にも推奨されます。次に例を示します。

  • システムの制限によりOracle RACのローリング・アップグレードを使用してアップグレードできないシステム・アップグレードには、Data Guardを使用します。

  • Oracle ASMへの移行、クラスタ化されていない環境からOracle RACへの移行、同じエンディアン形式の別のプラットフォームへの移行、または同じプロセッサ・アーキテクチャの別のプラットフォームへの移行を行う場合、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

通常、フィジカル・スタンバイ・データベースが実行されているシステムまたはクラスタを最初にアップグレードしてから、フィジカル・スタンバイ・データベースに対してData Guardスイッチオーバーを実行します。データベース・ソフトウェアがアップグレードされている場合は、「Data Guardを使用したローリング・パッチ・インストール」を参照してください。

この章の内容は次のとおりです。

5.4.3.1 フィジカル・スタンバイ・データベースのアップグレード

フィジカル・スタンバイ・データベースのアップグレードおよびスイッチオーバーの実行手順:

  1. システムをアップグレードするか、またはフィジカル・スタンバイ・データベース・システムを移行先環境に変更します。

    たとえば、Oracle ASMを使用して、スタンバイ・データベースを単一インスタンス・データベースからOracle RACデータベースに変換できます。プライマリ・データベースへの影響はありません。次に、スタンバイ・データベースを再起動し、これが移行先環境に合っているかどうかを確認して、REDO Applyによるスタンバイ・データベースへのREDOデータの適用が終わるまで待機します。

  2. Data Guardスイッチオーバーを実行する時間最適なスイッチオーバーの所要時間は、数秒から数分程度です。
  3. 元のプライマリ・データベースを停止します(これでスタンバイ・データベースになる)。
  4. アップグレードするか、元のプライマリ・データベースへのシステム変更を行います。
  5. スタンバイ・データベースとしてアップグレードしたデータベースを再起動し、リカバリでデータベースを自動的に同期化します。
  6. 必要に応じて、Data Guardスイッチオーバーを実行して、スタンバイ・データベースをプライマリ・データベース・ロールに戻します。

注意:

Oracle Databaseパッチ・セットの適用またはOracle Databaseのアップグレードを同時に行う場合、32ビットから64ビットへの変換は自動的に行われます。オペレーティング・システムのみをアップグレードする場合は、My Oracle Supportのノート414043.1(http://support.oracle.com/)に記述されている追加のアップグレード後の手順を実行する必要があります。

5.4.3.2 システムおよびクラスタのアップグレードのベスト・プラクティス

システムおよびクラスタのアップグレードと移行では、次のベスト・プラクティスおよびガイドラインを考慮します。

  • スイッチオーバーを高速化するには、スタンバイ・データベースでリアルタイム適用が使用されるように構成し、できれば、アーカイブ・ログ・ギャップが存在しないように、スイッチオーバー操作の開始前にデータベースがほとんど同期化されているようにします。

  • Oracle RACローリング・アップグレードまたはオンライン・パッチを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用して、システムおよびクラスタのアップグレードを実行します。

関連項目:

システムとクラスタのアップグレードの実行の詳細は、『Oracle Data Guard概要および管理』を参照してください。

5.4.4 Oracle Real Application Clustersを使用したパッチ適用およびローリング・アップグレード

通常、データベース・ソフトウェアへのOracleパッチは、ソフトウェアの問題に対する既知の修正を実装するため、または診断パッチを適用して問題に関する情報を収集するために適用します。アップグレードやパッチ適用は、スケジュールされたメンテナンス期間中に実行するよう計画してください。ビジネス・ニーズに最適なローリング・パッチ適用または非ローリング・パッチ適用のオプションを使用してください。

パッチには複数の種類があります。

  • 個別パッチ

    個別パッチは、Exadataの後続のパッチ・セット・リリースまたはデータベース・パッチより前に修正が必要なユーザーに提供されるバグ修正です。個別パッチのインストールは必要に応じて行われるため、定期的にスケジュールされる計画メンテナンス・イベントではありません。

  • バンドル・パッチ

    パッチ・セット間で発行されるパッチを集めたもの。パッチ・バンドルは通常は累積されます。Oracle Database用のMicrosoft Windowsバグ修正は、通常は個別パッチではなくパッチ・バンドルで発行されます。

  • パッチ・セット

    パッチ・セットには主にバグ修正が含まれますが、小規模な新機能や機能変更が含まれる場合もあります。

  • パッチ・セット更新(PSU)

    該当製品の最重要の修正を含む四半期ごとのパッチ(セキュリティ修正を含む)で、1つのパッチを適用して多くの問題を解決できます。

  • クリティカル・パッチ・アップデート(CPU)

    四半期ごとに提供される優先度の高い修正(通常はセキュリティ上の問題)を集めたもの。CPUは、セキュリティの事前修正の観点から累積されますが、セキュリティ以外のパッチ(マージ・リクエストの必要性を軽減)と競合するパッチに対処できるように他の修正が含まれる場合があります。

  • 診断パッチ

    バグの修正ではなく、問題の診断に限定して作成されるパッチ。

この章の内容は次のとおりです。

5.4.4.1 Oracle Real Application Clustersを使用したローリング・パッチ・インストール

Oracleデータベース・パッチを適用する際に停止時間を回避するには、Oracle RACを使用してローリング・パッチ・アップグレードを実行します。Oracle RACを使用するとパッチの約90%を適用できます。Oracleには、OPatchコマンドライン・ユーティリティを使用した、データベースの停止時間がほとんどないかゼロの、Oracle RACを使用したローリング・パッチのアップグレードを行う機能があります。Oracle RACを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用します。

Oracle RACのローリング・アップグレードでは、計画停止の間、Oracle RACデータベースのインスタンスを、1つを除いてすべて使用できるため、計画メンテナンスに必要なアプリケーション停止時間に対する影響はさらに減少します。OracleのOPatchユーティリティを使用すると、Oracle RACデータベースの異なるインスタンスに対してパッチを連続的に適用できます。

ローリング・アップグレードの実行は、ローリング・アップグレード用に認可されているパッチの場合のみ可能で、それについてはREADMEに記載されています。

関連項目:

アプリケーションを中断せずに、ローリング・パッチを正常に適用する手順は、My Oracle Supportのノート1593712.1 (http://support.oracle.com)を参照してください。

ローリング・パッチ・アップグレードでのData Guardの使用については、「Data Guardを使用したシステムおよびクラスタのアップグレード」を参照してください。

5.4.4.2 Data Guardを使用したローリング・パッチ・インストール

ローリング方式での更新の適用にOracle RACを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用します。Data Guard Standby-First Patchの適用では、ローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で、異なるパッチ・セット更新(PSU)、バンドル・パッチまたは個別パッチを使用できます。

ターゲット・パッチがData Guard Standby-Firstのインストール対応と認定されているかどうかを判断するには、パッチのREADMEを確認してください。

関連項目:

  • Oracle Data Guard Standby First Patchの適用の詳細は、My Oracle Supportのノート1265700.1 (http://support.oracle.com)を参照してください。

5.4.5 Oracle Clusterwareを使用したローリング・アップグレード

Oracle Clusterwareのアップグレード時の停止時間を回避するには、Oracle Clusterwareのローリング・アップグレードを実行するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeの使用を検討してください。

ローリング・アップグレードでは、停止時間が回避され、ソフトウェアが新しいバージョンにアップグレードされる間、Oracle Clusterwareの連続的な可用性が確保されます。Oracle Clusterware 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリは、グリッド・インフラストラクチャという単一バイナリとしてインストールされます。Oracle Clusterwareをローリング方式でOracle Clusterware 10gおよびOracle Clusterware 11gからアップグレードできます。

Oracle Clusterwareへのアップグレードはすべて、ローリング方式で実行できます。

関連項目:

オペレーティング・システム固有のOracle ClusterwareまたはOracle Real Application Clustersインストレーション・ガイド(https://docs.oracle.com/database)を参照してください。

5.4.6 Oracle Automatic Storage Managementを使用したローリング・アップグレード

Oracle ASMのアップグレードには、ローリング・アップグレードの実行をお薦めします。Oracle Database 11g(およびこれ以降のリリース)でのアップグレードはすべて、ローリング方式で実行できます。

Oracle Clusterware 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリは、グリッド・インフラストラクチャという単一バイナリとしてインストールされます。Oracle ASMはローリング方式でOracle Database 11gリリース1 (11.1)からのみアップグレードできます。

関連項目:

Oracle Automatic Storage Management管理者ガイド

5.4.7 Exadata Storage Serverソフトウェアのローリング・アップグレード

Exadata Storage Serverソフトウェアのローリング・アップグレード中、ストレージ・サーバーには一度に1つずつ、すべてのサーバーが更新されるまでパッチが適用されます。ローリング・パッチ適用は、Oracle ASMの冗長性と自動ディスク再同期化を利用して、パッチの適用中でもデータベースが稼働し続けられるようにします。Exadata Storage Serverソフトウェアのローリング・アップグレード・オーケストレーションは、Exadata Storage Serverソフトウェアとともに提供されるPatchMgrユーティリティにより管理されます。

関連項目:

5.4.8 Data Guardを使用したDatabaseのローリング・アップグレード

パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、SQL Applyを使用するData Guardのソリューションをお薦めします。ソース・データベースがSQL Applyでもともとサポートされていないデータ型を使用している場合、拡張データ型サポート(EDS)を使用することで、対応する拡張データ型をさらにいくつか増やすことができます。

ソース・データベースが、SQL Applyのローリング・アップグレードでサポートされていないソフトウェア・バージョンを使用している場合(Oracle Databaseリリース10.1.0.3より前のリリース)、またはEDSを使用してもSQL Applyのデータ型の競合を十分に解決できない場合、Oracle Active Data Guardを使用したローリング・アップグレード、Database Upgrade Assistant(DBUA)、トランスポータブル表領域またはOracle GoldenGateの使用を検討します。

  • Oracle Active Data Guardを使用したローリング・アップグレードでは、Data Guardのフィジカル・スタンバイ・データベースおよびSQL Applyプロセスを使用します。

  • DBUAには、アップグレード・プロセスの手順を示すグラフィカル・ユーザー・インタフェース(GUI)ユーティリティが備わっており、データベースのアップグレードの方法としては最も簡単で推奨できる方法です。ただし、DBUAでデータベースのアップグレードにかかる時間が定義されたメンテナンス・ウィンドウの期間に納まらない場合は、1時間未満でデータベース・アップグレードを実行するために、トランスポータブル表領域機能の使用を検討してください。

  • SQL Applyを使用できず、メンテナンス・ウィンドウで停止時間を1時間未満にする必要がある場合、およびアップグレードされるデータベースに単純なスキーマや、トランスポート・プロセスの一部として転送する必要のないデータ・ファイル(データ・ファイルが所定の場所で使用される場合など)が少ない場合には、トランスポータブル表領域を使用します。

  • Oracle GoldenGateは、データベース・アップグレードを実行する際の最も柔軟な方法と、追加のデータ型サポートを提供します。

DBUAで停止時間が発生します。停止時間の量は、要因の数によって異なります。

Oracle RACを使用してパッチ・セットのローリング・アップグレードを実行しないでください。使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。

Oracle Data Guard Brokerは、Oracle Database 12cリリース2でOracle Active Data Guardのローリング・アップグレードをサポートします。Oracle Active Data Guardのローリング・アップグレードは、Oracle Database 12cリリース1で導入されました。これにより、多くの手動手順を単純なPL/SQLパッケージDBMS_ROLLINGで自動化することで、一時ロジカル・データベースのローリング・アップグレード処理の実行が容易になります。データベースのローリング・アップグレードが容易になるだけでなく、自動化処理により信頼性も大幅に向上します。Oracle Data Guard Brokerでは、現在、DGMGRLコマンドライン・インタフェースからOracle Active Data Guardのローリング・アップグレードを制御できます。また、Data Guard Brokerのサポートによって、REDOトランスポート宛先の設定などの作業が透過的に処理され、ローリング・アップグレード処理が大幅に簡略化されます。

この章の内容は次のとおりです。

関連項目:

「Data Guardおよびフィジカル・スタンバイ・データベースを使用したデータベース・アップグレードの実行」では、Oracle Active Data Guardを使用したローリング・アップグレードについて説明します。

「トランスポータブル表領域を使用したデータベース・アップグレードの実行」では、トランスポータブル表領域ソリューションについて説明します。

Oracle GoldenGateを使用したデータベース・アップグレードの実行

構成に適したデータベース・アップグレード方法を選択する方法、およびDBUAをアップグレード・オプションとして選択する際の追加の考慮事項については、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

DBUAを使用したOracle Databaseソフトウェアのアップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

5.4.8.1 Data Guardおよびフィジカル・スタンバイ・データベースを使用したデータベース・アップグレードの実行

Oracle Active Data Guardを使用したローリング・アップグレードでは、新しいPL/SQLパッケージが提供され、フィジカル・スタンバイ・データベースを使用して、データベースのローリング・アップグレード(Oracle Databaseの後続のリリースまたは新しいパッチ・セットへ、または別のデータベース・メンテナンスを実行するとき)を実行する多くのプロセスを自動化します。アップグレード計画を入力すると、PL/SQLパッケージにより、その計画に従ってアップグレードの3つのフェーズ(起動、切替えおよび終了)が自動化されます。

アップグレード中、SQL Applyがすべてのバージョンにわたってスタンバイを同期させるために使用されますが、アップグレードが完了すると、Data Guard構成がプライマリ・データベースおよびフィジカル・データベースの元の状態に戻されます。

スタンバイ・データベースがアップグレード・モードでオープンされている間にプライマリ・データベースのREDOを継続して受信するために、アップグレードのターゲットであるスタンバイ・データベースを有効化することによって、Data Guardデータベースのローリング・アップグレード処理中にデータ保護が維持されます。

プロセス中にエラーが発生した場合、エラーを修正してアップグレードを再開するか、構成の元の状態に戻るかのいずれかを選択できます。これは、Oracle Database 12c リリース1(12.1)以降のデータベース・ローリング・アップグレード用にサポートされています。

Oracle Database 12cリリースには、データベース・ローリング・アップグレードをサポートするために、Data Guard SQL Apply用のREDOベースの追加のネイティブ・レプリケーションが含まれています(一時ロジカル・スタンバイ)。サポートされるデータ型には、Oracle Securefile、XML、Database File System (DBFS)、XDB、Oracle Spatial、Oracle TextおよびOracle Multimediaなどがあります。

Data Guardブローカもデータベース・ローリング・アップグレードをサポートします。

Oracle Database 12c以降、Oracle Enterprise Manager Cloud Control (Cloud Control)では、Data Guard構成のデータベースのローリング・アップグレードを実行するためのオプションが提供されています。手順は、Cloud Control内のオンライン・ヘルプに記載されています。

関連項目:

サポートされるデータ型の全リストは、『Oracle Data Guard概要および管理』の付録Cを参照してください。

5.4.8.2 データ・ポンプの全体トランスポータブル・エクスポート/インポート使用のデータベース・アップグレード

フル・トランスポータブル・エクスポート/インポートを使用すると、データベースをリリース11.2.0.3以上からOracle Database 12cにアップグレードできます。そのためには、Oracle Database 12cをインストールし、空のデータベースを作成します。次に、フル・トランスポータブル・エクスポート/インポートを使用して、リリース11.2.0.3データベースをOracle Database 12cデータベースにトランスポートします。

関連項目:

手順の概要は、「データ・ポンプの全体トランスポータブル・エクスポート/インポート」を参照してください。

データのトランスポートの一般的な制限および全体トランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』を参照してください。

5.4.8.3 トランスポータブル表領域を使用したデータベース・アップグレードの実行

データ型が競合するためにSQL Applyを使用できず、テストの結果、DBUAでのアップグレードが稼働時間の要件を満たせないことがわかる場合、トランスポータブル表領域ソリューションを利用したデータベースのアップグレードを検討してください。

トランスポータブル表領域機能を利用してOracle Databaseをアップグレードするには、次の手順に従います。

  1. トランスポート先システムにOracle Databaseソフトウェアをインストールし、ソース・データベースで最初の手順を実行し、トランスポート・プロセスの準備をします。

  2. ソースおよびトランスポート先データベースを準備します。

    1. ソース・データベースから情報を収集します。

    2. Database Configuration Assistant(DBCA)でトランスポート先データベースを作成します。

    3. Oracle Data Pump使用のためと、トランスポートされる表領域を受け入れるために、トランスポート先データベースの準備をします。

  3. 次の手順でユーザー表領域をトランスポートします。

    1. ユーザーを切断し、ソース・データベースへのアクセスを制限することで、ソース・データベースのトランスポートの準備をし、すべてのユーザー表領域をREAD ONLYにして、ソース・データベースから順序の開始値を取得します。

    2. ユーザー表領域をトランスポートします。

  4. トランスポート先データベースが完全であり機能することを確認した上でバックアップします。

トランスポータブル表領域の機能を使用する場合、次の点を考慮してください。

  • トランスポータブル表領域機能は、単純なスキーマを持ち、トランスポート・プロセスの一部としてデータ・ファイルを転送する必要がない(データ・ファイルが所定の場所で使用される場合など)データベースに対して、1時間未満でデータベース・アップグレードを実行するためのオプションです。次のWebサイトにあるMAAホワイト・ペーパー「Database Upgrade Using Transportable Tablespace」を参照してください。

    http://www.oracle.com/goto/maa

  • トランスポータブル表領域機能を使用すると、以前のリリースのソフトウェアが稼働するデータベースから、現行リリースのソフトウェアが稼働する空のトランスポート先データベースに、すべてのユーザー表領域を移動することにより、データベースのアップグレード時間が短縮されます。トランスポータブル表領域を持つ表領域データ・ファイルは、データ・ファイルをトランスポート先データベースにコピーし、オブジェクト・メタデータをトランスポート先データベースにインポートすることで、データベースに接続されます。

5.4.8.4 Oracle GoldenGateを使用したデータベース・アップグレードの実行

Oracle GoldenGateを使用してデータベースのアップグレードの停止時間を短縮します。データベースのアップグレードによる停止時間は、ソース・データベースがオンラインのままで現在のバージョンを実行して、ターゲット・データベースを新しいバージョンのアップグレードし、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。

高度な手順は次のとおりです。

  1. 変更－同期「抽出」グループを開始して、実行中のデータの変更を抽出します。
  2. 複製ターゲット・データベースを作成します。理想的な複製ターゲット・データベースは、最新のフィジカル・スタンバイ・データベースとして始まります。
  3. ターゲット・データベースをターゲット・バージョンにアクティブ化してアップグレードします(または、表7-6に示すメンテナンス・アクションを実行します)。
  4. 変更-同期「Replicat」グループを開始し、ターゲット・データベースの作成およびアップグレード中に変更された行を再同期します。
  5. アプリケーションを停止します。
  6. アプリケーションを開始し、ターゲット・データベースに接続します。

関連項目:

オンライン・データベース・アップグレードの実行の詳細は、Oracle GoldenGateのドキュメント(http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html)を参照してください。

Oracle MAAホワイト・ペーパー『Oracle GoldenGateを使用した停止時間ゼロのデータベース・アップグレード』(http://www.oracle.com/goto/maa)

データベースの複製に関する詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

5.4.8.5 Oracle GoldenGateおよびData Guardを使用したデータ・アップグレードの実行

図5-1の構成は、Data Guardデータベース・ローリング・アップグレードによりサポートされないアップグレードおよび移行などによる、停止時間および計画停止の危険性を最小限に抑えるためのOracle GoldenGateおよびData Guardの構成方法を示します。これには、異なるハードウェア・アーキテクチャおよびオペレーティング・システムへの移行、データベース・オブジェクトを変更するアプリケーション・アップグレードの実行などが含まれます。この構成では、フィジカル・スタンバイ・データベースにより、移行の前後および移行中の停止時間またはデータ損失を防く災害からの保護が提供されます。また、移行の実行に必要な作業から本番データベースを分離することにより、パフォーマンスへの影響または操作上の危険性を回避します。

図5-1 計画停止時間を最小限に抑えるためのOracle GoldenGate構成

図5-1の説明が続きます
「図5-1 計画停止時間を最小限に抑えるためのOracle GoldenGate構成」の説明

スタンバイ・データベース(図5-1の右上)から新しい本番データベース(右下)にGoldenGateをレプリケートするには、Oracle GoldenGateアーカイブ・ログ・モードが必要です。アーカイブ・ログ・モードの要件を満たすことができない場合は、元の本番データベース(左上のデータベース)から直接レプリケートします。

スタンバイ(図5-1の左上)からの抽出は可能ですが、ALOモードでのクラシック・キャプチャが必要です。

これらの要件は、新しいプラットフォーム上にパラレル環境を作成することにより達成されます。計画された移行のタイプによっては、新規プライマリ・データベースのインスタンス化が、既存のスタンバイ・データベースのバックアップのリストアと同じくらい単純になる可能性があります。より複雑な移行の場合は、Oracleトランスポータブル・テクノロジやOracle Data Pumpなどの、別のOracleテクノロジを使用して新規プライマリ・データベースをインスタンス化します。インスタンス化の後、新しい本番システム上で追加の変更を実装します。すべての変更が実装されると、新規フィジカル・スタンバイ・データベースが作成され、稼働開始後の継続的なデータ保護が提供されます。Oracle GoldenGateの異機種間レプリケーション(以前に構成済)が使用されて、新しい本番システムと、新しい環境の実装中に古いシステムで発生したすべてのトランザクションが同期化されます。同期化が完了すると、本番システムは新しい環境で稼働できるようになります。また、しばらくの間、新しい本番システムと同期された古い環境を保持するために、稼働後にOracle GoldenGate異機種間レプリケーションを使用するオプションもあります。ファスト・フォールバック・オプションでは、予期せぬ問題が発生する可能性があります。

関連項目:

スタンバイ・データベースに対するALOの詳細は、Oracle GoldenGate for Oracle Databaseのインストールおよび構成を参照

5.5 オンライン・アプリケーションのメンテナンスおよびアップグレード

アプリケーションの変更には次に示す機能を使用します。これらの機能を使用することで、アプリケーションのデータベース・オブジェクトの変更に必要なアプリケーションの停止時間を大幅に短縮する(またはゼロにする)ことができます。

この章の内容は次のとおりです。

5.5.1 エディションベースの再定義

エディションベースの再定義(EBR)を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。

アプリケーションを使用中にアップグレードするには、アプリケーションを構成するデータベース・オブジェクトをコピーし、コピーしたオブジェクトを個別に再定義します。アプリケーションのユーザーは、この変更による影響を受けず、変更されていないアプリケーションを引き続き実行します。変更が正しいことを確認できたら、アップグレードしたアプリケーションをすべてのユーザーが使用できるようにします。

この後の項では、エディションベースの再定義のエディション、エディショニング・ビューおよびcrosseditionトリガーの機能について説明します。

詳細は、『Oracle Database開発ガイド』を参照してください。

この章の内容は次のとおりです。

5.5.1.1 エディション

エディションは非スキーマ・オブジェクトであり、所有者が存在しません。エディションは1つのネームスペースに作成されます。複数のエディションがデータベースに共存することができます。エディション機能を使用すると、データベース・オブジェクトをコピーし、コピーしたオブジェクトを分離して再定義できます。

データベースには少なくとも1つのエディションが必要です。新規作成またはアップグレードされたOracle Databaseはすべて、ora$baseという名前の1つのエディションから開始されます。

エディションにより、新しいコードのインストールや、データ変更を行うためのプライバシ・メカニズムが提供され、実行中の本番アプリケーションではその変更は見えません。必要な変更がすべて非公開で行われ、1つの動作で公開されます。カットオーバーはセッションが使用するエディションによってのみ決定されます。

5.5.1.2 エディショニング・ビュー

1つ以上の表の構造を変更する場合、オンライン・アプリケーション・アップグレード中に基礎となる表に加えられる変更からアプリケーション・コードを隔離するには、エディショニング・ビュー機能も使用する必要があります。表は編集できません。

基礎となる表に列が追加され、それらを公開してデータを移入するために、アップグレード後のエディションで新しいエディショニング・ビューが作成されます。

エディショニング・ビューにはトリガーを作成でき、ビューの列はSQLのヒントで使用できます。エディショニング・ビューの副問合せの定義は、選択した列の別名を推定または定義できるのみです。SELECTリストを使用して、表の列のサブセットを推定し、通常はそれらの名前を変更します。その結果、このリストにより物理列の論理列へのマッピングが定義されます。

5.5.1.3 crosseditionトリガー

crosseditionトリガーは、エディションベースの再定義の一部として使用され、アップグレード前のエディションとアップグレード後のエディションのデータが互いに一致するように保ちます。アップグレード前のアプリケーションは、変更が適用され、アップグレード前のエディションがアップグレード後のエディションに再定義されている間もそのまま使用されます。

表構造の変更中に、ユーザーが表のデータを変更できるようにするには、forward crosseditionトリガーを使用します。他のユーザーがアプリケーションの古いバージョンを使用し続けている間、アップグレード済のアプリケーションを一部のユーザーが使用できるようにするには、reverse crosseditionトリガーも使用します。crosseditionトリガーは、アップグレードしたアプリケーションをユーザー全員が使用できるようにしたら削除するか無効にするため、アプリケーションの永続的な部品ではありません。

5.5.2 ローリング・アップグレードに使用するOracle GoldenGate

高速ローリング・アップグレードにOracle GoldenGateを使用することを検討してください。ただし、Oracle GoldenGateによるアップグレードでは、データベースの停止時間を最小限またはゼロにできますが、このソリューションを構成するには、運用面での投資がある程度必要になります。

関連項目:

Oracle GoldenGateおよびOracle GoldenGateのドキュメント

5.5.3 WAITオプションを使用したDDL

データ定義言語(DDL)コマンドには、内部構造で排他ロックが必要です。DDLコマンドが発行されると、これらのロックは使用できず、DDLが何秒か後に成功する場合があっても、文はすぐに失敗します。WAITオプション(新しいデフォルト)でDDLを指定すると、この問題が解決します。待機時間をインスタンス全体(初期化パラメータ・ファイル)で指定し、セッション・レベルで待機時間を変更します。

WAITオプションでDDLコマンドを指定すると、すぐにエラーが発生するのではなく、コマンドが成功するまでの猶予期間を定義する柔軟性が得られるため、このようなエラーに対処する追加のアプリケーション・ロジックが必要になります。

5.5.4 CREATE TRIGGERのENABLE、DISABLEおよびFOLLOWS句

状態(ENABLEおよびDISABLE)と順序付け(FOLLOWS)はトリガーの起動を制御するためのトリガーです。このような状態が追加されたことで、トリガーの管理制御が向上しています。CREATE TRIGGER文を無効な状態で使用すれば、有効にする前にコンパイルが成功したかどうかを検証できます。また、トリガーの順序をFOLLOWS句で制御できます。

5.5.5 ADD COLUMN機能の拡張

列のデフォルト値は、NOT NULLとして指定された列のデータ・ディクショナリで管理されます。

DEFAULT値とNOT NULL制約を指定して新しい列を追加する場合、デフォルト値を既存のすべてのレコードに格納する必要がなくなります。この拡張は、既存のデータ量に関係なく動作し、スキーマ変更を数秒以内に行えるほか、領域を消費することもありません。

5.5.6 きめ細かな依存性

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のパッチ・セットを適用する場合にこれが役立ちます。

5.5.7 不可視の索引

不可視の索引は、索引を使用できなくしたり、索引を削除したりすることの代替方法です。不可視の索引はDML操作に対して維持されますが、ヒントで索引を明示的に指定しないかぎり、オプティマイザで使用されません。

アプリケーション全体をオフラインにできないときでも、アプリケーションの変更が必要になることがしばしばあります。不可視の索引を使用すると、アプリケーション全体に影響を与えることなく、アプリケーションの特定の操作やモジュールに対して一時的な索引構造を利用できます。さらに、不可視の索引を使用して、索引をすぐに削除せずに削除のテストを行うことができるため、本番環境でテストするための猶予期間ができます。

5.5.8 非表示の列

不可視の列は、列を名前で明示的に指定した場合のみ表示されるユーザー指定の列です。既存のアプリケーションに影響を与えずに、非表示列を表に追加し、必要に応じてその列を表示することができます。

表を使用するアプリケーションを中断しないで表を変更する場合に、不可視の列を使用することがあります。表に不可視の列を追加した後、不可視の列にアクセスする必要がある問合せおよびその他の操作では、名前で明示的にその列を参照する必要があります。不可視の列が考慮されるアプリケーションを移行するとき、不可視の列を可視にできます。

5.5.9 同じ列セットに対する複数の索引

Oracle Database 12cでは、Bツリー索引とビットマップ索引の両方を同じ列のセットに作成できます。この機能を使用すれば、特徴が異なってさえいれば、既存の索引と同じ列のセットに、索引を作成できます。この機能により、アプリケーションを破壊することなく、索引のタイプをパッチ・エディションで変更できます。複数の索引のうちいつでも表示できるのは1つのみです。

関連項目:

詳細は、『Oracle Database管理者ガイド』の同じ列セットでの複数索引の作成に関する項を参照してください。

5.5.10 表のオンライン再定義後の依存PL/SQLの再コンパイル

この機能は、表のオンライン再定義後に依存PL/SQLパッケージを再コンパイルする必要性を最小限に抑えます。再定義によってPL/SQLパッケージに論理的な影響が出ない場合、再コンパイルは必要ありません。この最適化はデフォルトで有効です。

再コンパイルが必要な場合、この機能によって、表のオンライン再定義後に依存PL/SQLパッケージを手動で再コンパイルする時間が短縮され、その手間が軽減されます。再コンパイルには、再定義によって論理的に影響を受けないビュー、シノニム、その他の表依存オブジェクト(トリガーを除く)なども含まれます。

関連項目:

表のオンライン再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。