| Oracle® Database高可用性概要 12cリリース1 (12.1) B71280-03 |
|
 前 |
 次 |
計画停止時間は、計画外停止時間と同様、業務に悪影響を及ぼします。これは、特に、複数のタイムゾーンのユーザーをサポートする必要がある、または顧客に24時間年中無休でインターネット・アクセスを提供する必要があるグローバル企業に当てはまります。
以前は、次のような作業を実行する場合に停止時間が必要でした。
データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークを更新するためのパッチ適用またはシステムの再構成などの定期的なメンテナンス。
ハードウェア、データベース、アプリケーション、オペレーティング・システム、ミドルウェアまたはネットワークの主要アップグレードまたは新規導入などの新規デプロイメント。
この章の内容は次のとおりです。
表5-1は、移行に対する高レベルな高可用性ソリューションの説明です。各ソリューションについては、表に示した各項で説明しています。
表5-1 移行用高可用性ソリューション
| 移行タイプ | 推奨されるOracleソリューション | ソリューションの説明 | 停止時間 |
|---|---|---|---|
|
異なるプラットフォームへのデータベースの移行 |
Oracle Data Guard、データ・ポンプ、Recovery ManagerおよびOracle GoldenGate |
|
Oracle Data GuardまたはGoldenGateの場合数秒から数分 データ・ポンプおよびRecovery Managerの場合数秒から数分 |
|
異なるキャラクタ・セットへのデータベースの移行 |
|
5.1.2項「異なるキャラクタ・セットへのデータベースの移行」 |
数秒から数分 |
|
プラガブル・データベースまたは別のプラガブル・データベースに移行 プラガブル・データベースのリモート・クローニング |
データ・ポンプ、Recovery ManagerおよびOracle GoldenGate SQL*Plus |
|
GoldenGateの場合数秒から数分 データ・ポンプおよびRecovery Managerの場合数秒から数分 プラガブル・データベースのリモート・クローニングの場合は数分から数時間 |
|
ストレージの移行 |
|
Oracle ASMの場合停止時間ゼロ Data Guardの場合数秒から数分 |
|
|
単一インスタンス・システムからOracle RACクラスタへのデータベースの移行 |
|
5.1.5項「単一インスタンス・システムからOracle RACクラスタへのデータベースの移行」 |
数秒から数分 |
既存のデータベースを現在のシステムとは異なるオペレーティング・システムが実行しているシステムへと移動する場合、異なるプラットフォームへのデータベースの移行が必要です。たとえば、Microsoft WindowsからLinuxへ、またはAIXやHP-UXからOracle Linuxを実行中のOracle Exadata Database Machineへデータベースを移動する場合、データベースの移行が必要です。データベース移行オプションは、ソース・データベースのプラットフォームとソース・データベースのバージョンに大きく依存します。異なるプラットフォームへのデータベースの移行は、次のいずれかのソリューションにより実行できます。
Data Guard異機種間フィジカル・スタンバイ
データ・ポンプの全体トランスポータブル・エクスポート/インポート
データ・ポンプの表領域トランスポータブル・エクスポート/インポート
次の機能を前述の移行ソリューションと組み合せて使用して、データベース移行の停止時間を短縮できます。
Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポート
Oracle GoldenGate
Oracle Exadata Database MachineまたはOracle SuperClusterへのデータベースの移行は、この項で説明するプラットフォーム間の移行と同じ方法を使用します。Oracle ExadataおよびOracle SuperClusterのターゲット・プラットフォームについて、表5-2で説明します。
表5-2 設計されたシステムへのプラットフォームの移行
| 設計されたシステム | データベース・プラットフォーム |
|---|---|
|
Oracle Exadata Database Machine |
Oracle Linux x86 64ビット(リトル・エンディアン)または Oracle Solaris x86-64 (リトル・エンディアン) |
|
Oracle SuperCluster |
Oracle Solaris SPARC (ビッグ・エンディアン) |
表5-3に、データベース移行シナリオに使用する推奨ソリューションを示します。各ソリューションについては、表に示した各項で説明しています。
表5-3 データベース移行シナリオおよびソリューション
| データベース移行シナリオ | 使用するソリューション |
|---|---|
|
同じエンディアン形式のプラットフォームへの移行 |
|
|
異なるエンディアン形式のプラットフォームへの移行 |
|
Data Guardは、制限された数のプラットフォームの組合せに対し(WindowsからLinuxなど)、フィジカル・スタンバイ・データベースのプライマリ・システムとは異なるプラットフォームでの実行をサポートします。異機種間プライマリ/スタンバイの組合せをサポートするプラットフォーム間移行は、Data Guardのスイッチオーバー操作のみで実行できます。この方法を使用するには、次の条件を満たす必要があります。
プラットフォームの組合せは、My Oracle Supportのノート413484.1にサポート対象として記載されている必要があります。
ソース・データベースとターゲット・データベースのOracle Databaseリリースは同じである必要があります。
全体トランスポータブル・エクスポート/インポート機能を使用すると、データベース全体をあるプラットフォームから別のプラットフォームにコピーできます。データ・ポンプを使用してエクスポート・ダンプ・ファイルを生成し、必要な場合、ダンプ・ファイルとユーザー定義の表領域のデータ・ファイルをターゲット・データベースに転送し、その後、エクスポート・ダンプ・ファイルをインポートできます。全体トランスポータブル・エクスポートは、Oracle Database 11g リリース2(11.2.0.3)以降を実行しているソース・データベースでサポートされます。
データのトランスポートの一般的な制限および完全トランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』のデータのトランスポートに関する項を参照してください。
全体トランスポータブル・エクスポートでは、データベースの完全なコピーを作成するために必要なすべてのオブジェクトおよびデータがエクスポートされます。次のデータ移動方法の組合せが使用されます。
トランスポータブル表領域に存在するオブジェクトは、そのメタデータのみがダンプ・ファイル・セットにアンロードされ、データ自体はデータ・ファイルをターゲット・データベースにコピーしたときに移動されます。コピーする必要のあるデータ・ファイルは、エクスポート操作のログ・ファイルの最後に表示されます。
非トランスポータブル表領域に存在するオブジェクト(SYSTEMやSYSAUXなど)は、ダイレクト・パス・アンロードおよび外部表を使用して、そのメタデータとデータの両方がダンプ・ファイル・セットにアンロードされます。
データベースを新しいプラットフォームに移行するのに必要な時間は次の要因により異なります。
データ・サイズ
メタデータ・サイズ
データベース移行の手順の概要は、次のとおりです。
新しい空のデータベースをターゲット・プラットフォーム上に作成します。
アプリケーションを停止します(データへの読取り専用アクセスは引き続き許可されます)。
ソース・データベースでユーザー表領域を読取り専用にします。
ソース・データベースの全体トランスポータブル・エクスポートを実行します。
ユーザー表領域のデータ・ファイルとエクスポート・ダンプ・ファイルを宛先システムに送信します。
RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します(必要な場合)。
ターゲット・データベースへの全体トランスポータブル・インポートを実行します。
ターゲット・データベースでユーザー表領域を読取り/書込みにします。
アプリケーションを開始し、ターゲット・データベースに接続します。
移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体トランスポータブル・エクスポート/インポートとあわせて使用します。
表領域トランスポータブル・エクスポート/インポート機能を使用して、ユーザー定義の表領域全体を、あるプラットフォームのデータベースから別のプラットフォームで実行しているデータベースにコピーできます。表領域トランスポータブル・エクスポートでは、ユーザー定義の表領域の特定のセット内にある表のメタデータ(およびその表の依存オブジェクト)のみがエクスポートされます。表領域データ・ファイルは別の操作でコピーされます。次に、トランスポータブル表領域インポートが実行され、メタデータを含むダンプ・ファイルのインポートと、使用するデータ・ファイルの指定が行われます。表領域トランスポータブル・エクスポートは、バージョン10.0互換以降のソース・データベースおよびターゲット・データベース用の異なるプラットフォーム間でサポートされます。
データのトランスポートの一般的な制限および表領域のトランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』のデータのトランスポートに関する項を参照してください。
データベースを新しいプラットフォームに移行するのに必要な時間は次の要因により異なります。
データ・サイズ
メタデータ・サイズ
高度な手順は次のとおりです。
新しい空のデータベースをターゲット・プラットフォーム上に作成します。
アプリケーションを停止します(データへの読取り専用アクセスは引き続き許可されます)。
トランスポート操作に必要なオブジェクトを、ターゲット・データベースにインポートします。
ソース・データベースでユーザー表領域を読取り専用にします。
ソース・データベースの全体トランスポータブル・エクスポートを実行します。
ユーザー表領域のデータ・ファイルとエクスポート・ダンプ・ファイルを宛先システムに送信します。
RMANを使用して、データ・ファイルを移動先システムのエンディアン形式に変換します(必要な場合)。
すべてのユーザー表領域のトランスポータブル・インポートを実行します。
トランスポートできないデータベース・オブジェクトをエクスポートおよびインポートします。
ターゲット・データベースでユーザー表領域を読取り/書込みにします。
アプリケーションを開始し、ターゲット・データベースに接続します。
移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの表領域トランスポータブル・エクスポート/インポートとあわせて使用します。
以降の項で説明する方法を前述の移行方法と組み合せて使用して、データベース移行の停止時間を短縮できます。
データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートを使用したデータベースの移行に必要な停止時間は、主に次の2つの要因で決定されます。
データ・サイズ
メタデータ・サイズ
移行による停止時間を短縮するために、Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートとあわせて使用します。移行による停止時間は、ソース・データベースをオンラインにしたまま、ほとんどのデータの移動を許可することにより短縮されます。Recovery Managerの非一貫性表領域のクロス・プラットフォーム・トランスポートを、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートとあわせて使用する場合、必要な停止時間は、主に次の要因で決定されます。
データの変更率
メタデータ・サイズ
RMANにより、ソース・システムのユーザー定義の表領域の非一貫性バックアップを作成し、それをターゲット・システムにリストアすることで、ソース・システムのデータベースをオンラインにしたままで、データベースの大部分をターゲット・システムにトランスポートできます。最初のバックアップ/リストア操作は時間がかかる可能性があるので、非一貫性バックアップで生成されたデータ・ファイルには、クロス・プラットフォームの増分バックアップを使用して、1回または複数回のロール・フォワードが行われる可能性があります。トランスポートを完了するためにデータ・ファイルの一貫性を保つには、表領域が読取り専用モードのときに取得した、最終クロス・プラットフォーム増分バックアップを適用します。最後の手順は、データ・ポンプの全体または表領域トランスポータブル・エクスポート/インポートを使用して移行を完了することです。
ターゲット・システムにデータベースを移動する手順の概要は、次のとおりです。
フェーズ1: 準備フェーズ
すべてのユーザー定義表領域のRMANクロス・プラットフォーム非一貫性バックアップを作成します。
クロス・プラットフォーム非一貫性バックアップをターゲット・システムにリストアします。ターゲット・システムで作成されたターゲット・データ・ファイルは外部データ・ファイルと呼ばれます。
フェーズ2: ロール・フォワード・フェーズ
すべてのユーザー定義表領域のRMANクロス・プラットフォーム増分バックアップを作成します。
クロス・プラットフォーム増分バックアップを適用することによって、ターゲット・システムの外部データファイルをリカバリします。
ロール・フォワード・フェーズは必要な回数繰り返され、ソース・データベースまで外部データ・ファイルを取り込みます。
フェーズ3: トランスポート・フェーズ
アプリケーションを停止します。
ユーザー定義の表領域を読取り専用にします。
フェーズ2(ロール・フォワード・フェーズ)をもう一度繰り返します。
データ・ポンプの全体トランスポータブル・エクスポート/インポートを使用してデータベースを移行するか、またはデータ・ポンプの表領域トランスポータブル・エクスポート/インポートを使用してユーザー定義の表領域を移行します。
アプリケーションを開始し、ターゲット・データベースに接続します。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
Oracle GoldenGateを使用して移行の停止時間を短縮します。移行による停止時間は、ソース・データベースをオンラインにしたまま、ターゲット・データベースを作成し、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。
高度な手順は次のとおりです。
Oracle GoldenGate Extractグループを開始して、実行中のデータの変更を抽出します。
データ・ポンプの全体トランスポータブル・エクスポート/インポート、またはデータ・ポンプの表領域トランスポータブル・エクスポート/インポートを使用して、ターゲット・データベースを作成します。
Oracle GoldenGate Replicatグループを開始し、ターゲット・データベースの作成中に変更された行を再同期します。
アプリケーションを停止します。
Oracle GoldenGate Replicatの終了を待機して、証跡ファイルの残りの変更を適用します。
アプリケーションを開始し、ターゲット・データベースに接続します。
|
関連項目:
|
Oracle GoldenGateを使用してキャラクタ・セットの移行の停止時間を短縮します。キャラクタ・セットの移行による停止時間は、ソース・データベースをオンラインにしたまま、ターゲット・データベースを作成し、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。
高度な手順は次のとおりです。
目的のキャラクタ・セットで空のターゲット・データベースを作成します。
変更－同期「抽出」グループを開始して、実行中のデータの変更を抽出します。
データ・ポンプの全体トランスポート不可能なエクスポート/インポートを実行します。インポート・プロセス中に、データは新しいキャラクタ・セットに自動的に変換されます。
変更-同期「Replicat」グループを開始し、ターゲット・データベースの作成中に変更された行を再同期します。
アプリケーションを停止します。
アプリケーションを開始し、ターゲット・データベースに接続します。
非コンテナ・データベース(非CDB)または切断されたプラガブル・データベース(PDB)の、ターゲットCDB内のPDBへの移行は、次のいずれかのソリューションにより実行できます。
CREATE PLUGGABLE DATABASE文
データ・ポンプの全体トランスポータブル・エクスポート/インポート
データ・ポンプの表領域トランスポータブル・エクスポート/インポート
表5-4 プラガブル・データベース移行ソリューション
| ソリューション | 使用する場合 |
|---|---|
|
|
非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 ASMを現在使用してしていない場合、データベースの全体または一部をOracle ASMに移行して、データベース管理を簡略化できます。Data Guardを使用して、Oracle ASMへの移行時の停止時間を最小化します。高度な手順は次のとおりです。
Oracle ASM記憶域を使用したスタンバイ・データベースの作成
Data Guardスイッチオーバーを実行する時間
|
関連項目:
|
既存のストレージ・デバイスがすでにOracle ASMによって管理されており、新しいストレージに配置される予定で、新しいストレージは既存のデータベース・サーバーまたはクラスタに接続される場合、Oracle ASMを使用してストレージの移行を実行します。Oracle ASMを使用して、新しいストレージのすべてのディスクを追加し、既存のストレージからすべてのディスクを削除できます。Oracle ASMは、データベースが稼働したままの状態で、自動的にデータのリバランスを行い、新規ストレージに移行します。既存のストレージ・デバイスを削除する前に、リバランスが完了したかどうか確認してください。
高度な手順は次のとおりです。
新しいストレージを既存のシステムに接続して構成します。
Oracle ASMコマンドを使用して、新しいストレージをOracle ASMに追加し、元のストレージをOracle ASMから削除します。
データを新しいストレージに移動するOracle ASMリバランス操作の完了を待ちます。
元のストレージ・デバイスを切断します。
|
関連項目: 『Oracle Automatic Storage Management管理者ガイド』 |
ALTER DATABASE MOVE DATAFILE SQL文を使用して、データファイルをASMに再配置する方法の詳細は、5.2.1項「オンライン・データファイルの名前変更と再配置」を参照してください。
単一インスタンスのOracle Databaseが実行している非クラスタ・システムからOracle RACが実行しているクラスタ環境への移行時にData Guardを使用します。スイッチオーバーを実行するのに必要な時間は発生する停止時間のみです。
システムおよびデータベースの変更には、次の各項で説明する動的リソース・プロビジョニング機能を使用します。
すべてのデータファイルは、オンライン(使用可能)またはオフライン(使用不可能)のいずれかです。個々のデータ・ファイルまたは一時ファイルの可用性は、ファイルをオフラインにするか、オンラインにして変更できます。オフラインのデータファイルには、ファイルが再びオンラインになるまでアクセスできません。
Oracle Database 12cリリース1(12.1)から、SQLを使用して、データベースがオープンで、ファイルにアクセスしている間に、オンライン・データ・ファイルを1つのフィジカル・ファイルから別のファイルへ移動できます。
ALTER DATABASE MOVE DATAFILE SQL文を使用して、オンライン・データファイルの名前変更や再配置が可能です。この文を使用すると、データベースのオープン時にユーザーがデータ・ファイルにアクセスしている際、データ・ファイルを名前変更または再配置できます。
オンライン・データファイルを名前変更または再配置すると、データベースの制御ファイルに記録されている、データファイルへのポインタが変更されます。ファイルはオペレーティング・レベルでも物理的に名前の変更や再配置が行われます。
次のいずれかのタスクを実行する場合、ユーザーがデータファイルにアクセスできるようにする必要があるため、オンライン・データファイルを名前変更または再配置することができます。
あるタイプの記憶域から別のタイプの記憶域に、データファイルを移動します。
頻繁にアクセスしないデータファイルを、より低コストの記憶域に移動します。
表領域を読取り専用にし、そのデータファイルを1回のみ書込み可能な記憶域に移動します。
データベースをOracle Automatic Storage Management (Oracle ASM)に移動
データフェイルの名前をより説明的な名前に変更
|
関連項目: オンライン・データ・ファイルの名前の変更または再配置方法に詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracleでは、サービスを中断することなく、ハードウェアの要求の変化に適応できるように、データベースの動的再構成のサポートを継続的に拡大しています。
Oracle Clusterwareのオンラインでのリソース属性の変更を使用すると、リソースの特定の属性を変更でき、変更を有効にするためにリソースを再起動する必要がありません。オンラインでのリソース属性の変更は、SRVCTLおよびCRSCTLコマンドを使用すれば可能です。
Oracle Databaseは、ハードウェアおよびデータベース構成への様々な変更に対して、次の機能を提供して動的に対応します。
対称型マルチプロセッシング(SMP)サーバーからのプロセッサの追加および削除
Oracle RAC環境でのノードとインスタンスの追加および削除
データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるデータベース・ディスクの追加および削除
データベース・アクティビティに影響しない、Oracle ASMを使用したオンラインによるストレージ・アレイまたはExadataセルの追加および削除脚注1
停止時間なしで、Quarter Rack、Half Rack、Full Rackへのアップグレード、およびMultiple Full Rackまでのすべての方法により、Exadataシステムを拡張
Oracle ASMを使用したデータベース・ストレージ全体のI/Oロードの自動リバランス
ストレージ構成が変更するたびに自動的にデータベース・ストレージのリバランスを行う、Oracle ASMを使用したディスクの追加または削除時のオンラインによるデータ・ファイルの移動
リソース・マネージャのコンシューマ・グループおよびプランを使用して、データベース・セッション・リソース使用量を動的に制御
次のいずれかのSQL*Plus文を使用することで、インスタンスを停止せずに、ほとんどすべての初期化パラメータを変更
ALTER SESSION文は、セッション中にパラメータの値を変更します。
ALTER SYSTEM文は、インスタンスの期間中、インスタンスのすべてのセッションでパラメータの値を変更します。
これらの機能により、エンタープライズ・グリッド・コンピューティングの基本要件であるシステム変更およびキャパシティ・オンデマンド・プロビジョニングがコストなしで実現されます。
|
関連項目: 自動メモリー管理をサポートするプラットフォームの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
2つのメモリー管理初期化パラメータ、MEMORY_TARGETとMEMORY_MAX_TARGETは、システム・グローバル領域(SGA)、プログラム・グローバル領域(PGA)およびOracle Databaseの実行に必要なその他のメモリーの自動管理を可能にします。
MEMORY_MAX_TARGETパラメータは、MEMORY_TARGETの動的な最大値を指定します。
表5-5 MEMORY_MAX_TARGETおよびMEMORY_TARGET
| 条件 | 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つの構成(ヒープ構成など)から別の構成(索引構成など)への表の変換、およびデータ圧縮(高度な行圧縮)の有効化など)。
名前、型、サイズなどの多くの論理属性を変更します。列を追加、削除またはマージできます。ただし、表の主キーは変更できません。
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 |
|---|---|---|---|---|---|
|
パッケージ |
表記憶域パラメータの変更 異なる表領域への表の移動 パラレル問合せのサポートの追加 パーティション化サポートの追加または削除 表の再作成による断片化の回避 表から索引構成表への変更、またはその逆 列の追加または削除 関数を使用した列の変換 |
権限、制約およびトリガーのクローニング LONGからLOBへの変換一意キーを使用した再編成 表順序の基準となる列の指定 |
単一のパーティションの再編成 アドバンスト・キューおよびクラスタ表 ADTを含んだ表 統計の保存およびクローニング チェック制約およびNOT NULL制約 ネストした表の依存オブジェクトのコピー |
マテリアライズド・ビュー・ログやマテリアライズド・ビューを含む表 再定義が論理的にオブジェクトに影響を与えない場合、依存オブジェクトの再コンパイルは不要 |
複数パーティションの再定義完了にかかる時間を短縮するための、単一の再定義セッションでの複数パーティションの再定義。 表の再定義に対する停止時間をなくすために、Oracle Virtual Private Database (VPD)ポリシーが定義されている表の再定義。 オンラインでの索引の削除(リリース10gおよび11gでの索引のオンライン作成/再構築) 索引の表示可能/不可視の変更、オンラインでの索引使用禁止の変更 オンラインでの制約の削除(リリース11 gのオンラインでの制約作成) オンラインでの未使用列の設定(リリース11gのオンラインでの列の追加) パーティションのオンラインでの移行(内部的にオンライン再定義を利用) 単一セッションでのオンライン、複数パーティションの再定義 Oracle Virtual Private Databseポリシーを含む表のオンライン再定義 新しい エディションベースの再定義の拡張 |
|
未使用領域の再利用 |
適用不可 |
次の文で ALTER TABLEALTER INDEXALTER MATERIALIZED VIEWALTER MATERIALIZED VIEW LOG |
適用不可 |
適用不可 |
適用不可 |
|
オンラインでの索引の作成 |
|
適用不可 |
適用不可 |
DMLをロックしないオンライン索引作成(ワークロードに依存しない透過的な作成が可能) |
適用不可 |
|
オンラインでの索引の結合 |
|
適用不可 |
適用不可 |
適用不可 |
適用不可 |
|
オンラインでの索引構成表の移動 |
|
適用不可 |
適用不可 |
適用不可 |
適用不可 |
|
関連項目: 『Oracle Database管理者ガイド』 |
Oracleでは、あらゆるタイプの計画メンテナンスに対して停止時間を防止、許容および短縮するための高可用性ソリューションを提供しています。表5-7および表5-8では、計画停止時間用の各種Oracle高可用性ソリューション、および各ソリューションで達成可能な停止時間について説明しています。
どのような場合でも、計画メンテナンス操作を実行する前に広範囲なテストを行うことをお薦めします。個々のOracle高可用性アーキテクチャの計画停止時間タイプすべての達成可能なリカバリ時間に関する概要は、第7章「高可用性アーキテクチャ」の表を参照してください。
表5-7 システムおよびソフトウェア・メンテナンス用Oracle高可用性ソリューション
| メンテナンス・タイプ | 推奨されるOracleソリューション | ソリューションの説明 | 停止時間 |
|---|---|---|---|
|
オペレーティング・システムおよびハードウェアのアップグレード |
Oracle Real Application ClustersおよびOracle Clusterware、Oracle RAC One NodeまたはData Guard Standby-First Patchの適用 |
5.4.1項「オペレーティング・システムのアップグレードおよびハードウェアのアップグレード」 |
Oracle RACおよびOracle RAC One Nodeの場合停止時間ゼロ。 Standby-First Patchの適用の場合数秒から数分 |
|
Oracle仮パッチまたは診断パッチ |
Oracle Real Application ClustersおよびOracle Clusterware、Oracle RAC One Nodeまたはオンライン・パッチ |
|
停止時間ゼロ脚注1 |
|
Oracle DatabaseおよびOracle Grid Infrastructureバンドル・パッチ、パッチ・セット・アップデート(PSU)、クリティカル・パッチ・アップデート(CPU) |
Data Guard Standby-First Patchの適用、Oracle Real Application ClustersおよびOracle ClusterwareまたはOracle RAC One Node |
5.4.3項「Data Guardを使用したシステムおよびクラスタのアップグレード」 |
Standby-First Patchの適用の場合数秒から数分 Oracle RACおよびOracle RAC One Nodeの場合停止時間ゼロ |
|
Oracle DatabaseおよびOracle Grid Infrastructureパッチ・セット(Oracle Database 11.2.0.2または11.2.0.3など)およびメジャー・アップグレード(Oracle Database 11.2から12.1など) |
|
5.4.8項「Data Guardを使用したDatabaseのローリング・アップグレード」 |
数秒から数分 |
|
Exadata Storageのアップグレード |
Exadata PatchMgrユーティリティ |
5.4.7項「Exadata Storage Serverソフトウェアのローリング・アップグレード」 |
停止時間ゼロ |
|
アプリケーションのアップグレード |
アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード |
5.5項「アプリケーションのオンライン・メンテナンスおよびオンライン・アップグレード」 |
脚注1ローリング・アップグレードの実行で適用できないパッチは、パッチ適用による可用性の影響が少ないOPatchユーティリティのMINIMIZE_DOWNTIMEオプションで適用できます。
表5-8 MAA参照アーキテクチャおよびマルチテナント・アーキテクチャの計画メンテナンス・マトリックス
| イベント | Bronze、Silver、GoldおよびPlatinumサービス・レベル層のソリューション | 予想される停止時間 |
|---|---|---|
|
移行 |
関連項目: |
状況により異なる |
|
動的およびオンライン・リソース・プロビジョニングまたは オンライン再編成および再定義 |
すべての層: それぞれの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レプリカにスイッチオーバー可能 |
ゼロ 移動サービスにより、停止時間はゼロからほぼゼロ |
|
関連項目:
|
システムとハードウェアのアップグレード時の停止時間を回避するには、Oracle RACを使用するソリューションをお薦めします。単一インスタンスOracle RACデータベースの場合は、Oracle RAC One Nodeを使用できます。
5.4.3項に示すように、Oracle RACまたはOracle RAC One Nodeを使用してアップグレードを実行できない場合は、Data Guardとフィジカル・スタンバイ・データベースを使用するソリューションをお薦めします。もしくは、5.4.5項に示すように、Oracle Clusterwareを使用したコールド・クラスタ・フェイルオーバーを使用することもできます。
次のリストに、Oracle RACを使用してアップグレードする場合の手順の高レベルの概要を示します。
次の前提条件チェックを実行します。
計画メンテナンスがオペレーティング・システムの観点からローリング形式で行うことができるかどうかを確認します。
データベースとクラスタウェアのバージョンが、新規システムおよびハードウェアの変更で動作保証されているかどうかを確認します。
クラスタ内の複数のインスタンスでアプリケーション・サービスが稼働している場合は、アプリケーション・サービスを停止します。アップグレード対象のインスタンスのみでアプリケーション・サービスが稼働している場合は、クラスタ内の別のノードにサービスを再配置します。
高速アプリケーション通知(FAN)を使用している場合、アプリケーション・サービスを停止すると、接続が接続先インスタンスから暗黙的にリダイレクトされます。
IMMEDIATEオプションを指定して接続先インスタンスを停止します。
Oracle Clusterwareを停止して無効にします。
Oracle Clusterwareを無効にすると、自動起動しなくなります。
メンテナンスを実行します。
Oracle Clusterwareを有効にして、起動します。
この手順により、データベース・インスタンスが暗黙的に起動されます。
アプリケーション・サービスを起動します。
この手順により、FANを使用している場合、接続先インスタンスに接続が暗黙的にリダイレクトされます。
次のノードですべての手順を繰り返します。
使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。
通常、仮パッチおよび診断パッチは、ローリング方法で一度に1つのノードに適用されます。ソフトウェア・ホームへのパッチの適用中、ホームから実行中のソフトウェア(データベース・インスタンスなど)はシャットダウンされます。ただし、パッチを緊急にインストールする必要があり、現時点でシャットダウンできない場合には、ソフトウェアが実行中のまま、適格な仮パッチおよび診断パッチをオンラインで適用できます。
次の場合にのみ、パッチをオンラインで適用してください。
パッチのREADMEには、オンラインで適用できることが記載されています。
パッチはすぐに適用する必要がありますが、通常(オフライン)バージョンのパッチを適用する場合は、データベース・インスタンスを停止できません。
OPatchコマンドライン・ユーティリティを使用してOracleデータベースでオンライン・パッチ適用を実行できます。
オンライン・パッチを実行するときは、次の点に注意してください。
オラクル社では、正規の個別または診断パッチをコンボ・パッチとして提供しており、同じバグ修正でオンライン・パッチとオフライン・パッチの両方が含まれています。
そのため、このオンライン・パッチを最初に適用すると、計画外停止時間を回避できます。ただし、オンライン・パッチではメモリーのオーバーヘッドが発生するため、計画停止時にオンライン・パッチをロールバックしてオフライン・パッチを適用する必要があります。
オンライン・パッチを適用すると、各Oracleプロセスではパッチの適用時にプログラム・グローバル領域(PGA)のメモリーを多く使用するため、システムのメモリー消費が増加します。オンライン・パッチを適用する前に、メモリー要件を考慮してください。各オンライン・パッチは独自のものであり、メモリー要件はパッチごとに異なります。パッチをまずテスト・システムに適用することで、本番システムでのオンライン・パッチの効果を評価し、追加のメモリー使用量を予測できます。
|
関連項目:
|
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スイッチオーバーを実行します。データベース・ソフトウェアがアップグレードされている場合は、5.4.4.2項「Data Guardを使用したローリング・パッチ・インストール」を参照してください。
フィジカル・スタンバイ・データベースのアップグレードおよびスイッチオーバーの実行手順:
システムをアップグレードするか、またはフィジカル・スタンバイ・データベース・システムを移行先環境に変更します。
たとえば、Oracle ASMを使用して、スタンバイ・データベースを単一インスタンス・データベースからOracle RACデータベースに変換できます。プライマリ・データベースへの影響はありません。次に、スタンバイ・データベースを再起動し、これが移行先環境に合っているかどうかを確認して、REDO Applyによるスタンバイ・データベースへのREDOデータの適用が終わるまで待機します。
Data Guardスイッチオーバーの実行。最適なスイッチオーバーの所要時間は、数秒から数分程度です。
元のプライマリ・データベースを停止します(これでスタンバイ・データベースになる)。
アップグレードするか、元のプライマリ・データベースへのシステム変更を行います。
スタンバイ・データベースとしてアップグレードしたデータベースを再起動し、リカバリでデータベースを自動的に同期化します。
必要に応じて、Data Guardスイッチオーバーを実行して、スタンバイ・データベースをプライマリ・データベース・ロールに戻します。
|
注意: Oracle Databaseパッチ・セットの適用またはOracle Databaseのアップグレードを同時に行う場合、32ビットから64ビットへの変換は自動的に行われます。オペレーティング・システムのみをアップグレードする場合は、My Oracle Supportのノート414043.1(http://support.oracle.com/)に記述されている追加のアップグレード後の手順を実行する必要があります。アップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。 |
システムおよびクラスタのアップグレードと移行では、次のベスト・プラクティスおよびガイドラインを考慮します。
スイッチオーバーを高速化するには、スタンバイ・データベースでリアルタイム適用が使用されるように構成し、できれば、アーカイブ・ログ・ギャップが存在しないように、スイッチオーバー操作の開始前にデータベースがほとんど同期化されているようにします。
Oracle RACローリング・アップグレードまたはオンライン・パッチを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用して、システムおよびクラスタのアップグレードを実行します。詳細は、『Oracle Data Guard概要および管理』を参照してください。
通常、データベース・ソフトウェアへのOracleパッチは、ソフトウェアの問題に対する既知の修正を実装するため、または診断パッチを適用して問題に関する情報を収集するために適用します。アップグレードやパッチ適用は、スケジュールされたメンテナンス期間中に実行するよう計画してください。ビジネス・ニーズに最適なローリング・パッチ適用または非ローリング・パッチ適用のオプションを使用してください。
パッチには複数の種類があります。
個別パッチ
個別パッチは、Exadataの後続のパッチ・セット・リリースまたはデータベース・パッチより前に修正が必要なユーザーに提供されるバグ修正です。個別パッチのインストールは必要に応じて行われるため、定期的にスケジュールされる計画メンテナンス・イベントではありません。
バンドル・パッチ
パッチ・セット間で発行されるパッチを集めたもの。パッチ・バンドルは通常は累積されます。Oracle Database用のMicrosoft Windowsバグ修正は、通常は個別パッチではなくパッチ・バンドルで発行されます。
パッチ・セット
パッチ・セットには主にバグ修正が含まれますが、小規模な新機能や機能変更が含まれる場合もあります。
パッチ・セット更新(PSU)
該当製品の最重要の修正を含む四半期ごとのパッチ(セキュリティ修正を含む)で、1つのパッチを適用して多くの問題を解決できます。
クリティカル・パッチ・アップデート(CPU)
四半期ごとに提供される優先度の高い修正(通常はセキュリティ上の問題)を集めたもの。CPUは、セキュリティの事前修正の観点から累積されますが、セキュリティ以外のパッチ(マージ・リクエストの必要性を軽減)と競合するパッチに対処できるように他の修正が含まれる場合があります。
診断パッチ
バグの修正ではなく、問題の診断に限定して作成されるパッチ。
Oracleデータベース・パッチを適用する際に停止時間を回避するには、Oracle RACを使用してローリング・パッチ・アップグレードを実行します。Oracle RACを使用するとパッチの約90%を適用できます。Oracleには、OPatchコマンドライン・ユーティリティを使用した、データベースの停止時間がほとんどないかゼロの、Oracle RACを使用したローリング・パッチのアップグレードを行う機能があります。Oracle RACを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用します。詳細は、5.4.3項を参照してください。
Oracle RACのローリング・アップグレードでは、計画停止の間、Oracle RACデータベースのインスタンスを、1つを除いてすべて使用できるため、計画メンテナンスに必要なアプリケーション停止時間に対する影響はさらに減少します。OracleのOPatchユーティリティを使用すると、Oracle RACデータベースの異なるインスタンスに対してパッチを連続的に適用できます。
ローリング・アップグレードの実行は、ローリング・アップグレード用に認可されているパッチの場合のみ可能で、それについてはREADMEに記載されています。
|
関連項目: アプリケーションを中断せずに、ローリング・パッチを正常に適用する手順は、My Oracle Supportのノート1593712.1 (http://support.oracle.com)を参照してください。 |
ローリング方式での更新の適用にOracle RACを使用できない場合は、Data Guardおよびフィジカル・スタンバイ・データベースを使用します。Data Guard Standby-First Patchの適用では、ローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で、異なるパッチ・セット更新(PSU)、バンドル・パッチまたは個別パッチを使用できます。
ターゲット・パッチがData Guard Standby-Firstのインストール対応と認定されているかどうかを判断するには、パッチのREADMEを確認してください。
|
関連項目:
|
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 ASMのアップグレードには、ローリング・アップグレードの実行をお薦めします。Oracle Database 11g(およびこれ以降のリリース)でのアップグレードはすべて、ローリング方式で実行できます。
Oracle Clusterware 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリは、グリッド・インフラストラクチャという単一バイナリとしてインストールされます。Oracle ASMはローリング方式でOracle Database 11gリリース1 (11.1)からのみアップグレードできます。
詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
Exadata Storage Serverソフトウェアのローリング・アップグレード中、ストレージ・サーバーには一度に1つずつ、すべてのサーバーが更新されるまでパッチが適用されます。ローリング・パッチ適用は、Oracle ASMの冗長性と自動ディスク再同期化を利用して、パッチの適用中でもデータベースが稼働し続けられるようにします。Exadata Storage Serverソフトウェアのローリング・アップグレード・オーケストレーションは、Exadata Storage Serverソフトウェアとともに提供されるPatchMgrユーティリティにより管理されます。
|
関連項目:
|
パッチ・セットおよびデータベースのアップグレードを最小の停止時間で実行するには、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)脚注2、トランスポータブル表領域またはOracle GoldenGateの使用を検討します。
Oracle Active Data Guardを使用したローリング・アップグレードでは、Data Guardのフィジカル・スタンバイ・データベースおよびSQL Applyプロセスを使用します。5.4.8.1項で、Oracle Active Data Guard機能を使用したローリング・アップグレードについて説明します。
DBUAには、アップグレード・プロセスの手順を示すグラフィカル・ユーザー・インタフェース(GUI)ユーティリティが備わっており、データベースのアップグレードの方法としては最も簡単で推奨できる方法です。ただし、DBUAでデータベースのアップグレードにかかる時間が定義されたメンテナンス・ウィンドウの期間に納まらない場合は、1時間未満でデータベース・アップグレードを実行するために、トランスポータブル表領域機能の使用を検討してください。
SQL Applyを使用できず、メンテナンス・ウィンドウで停止時間を1時間未満にする必要がある場合、およびアップグレードされるデータベースに単純なスキーマや、トランスポート・プロセスの一部として転送する必要のないデータ・ファイル(データ・ファイルが所定の場所で使用される場合など)が少ない場合には、トランスポータブル表領域を使用します。トランスポータブル表領域ソリューションについては5.4.8.3項で説明します。
Oracle GoldenGateは、データベース・アップグレードを実行する際の最も柔軟な方法と、追加のデータ型サポートを提供します。このソリューションについては、5.4.8.4項で説明します。
Oracle RACを使用してパッチ・セットのローリング・アップグレードを実行しないでください。使用しているオペレーティング・システム別のOracle Real Application Clustersのインストレーション・ガイドを参照してください。
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などがあります。サポートされるデータ型の全リストは、『Oracle Data Guard概要および管理』の付録Cを参照してください。
Data Guardブローカもデータベース・ローリング・アップグレードをサポートします。
Oracle Database 12c以降、Oracle Enterprise Manager Cloud Control (Cloud Control)では、Data Guard構成のデータベースのローリング・アップグレードを実行するためのオプションが提供されています。手順は、Cloud Control内のオンライン・ヘルプで説明されています。
|
関連項目:
|
フル・トランスポータブル・エクスポート/インポートを使用すると、データベースをリリース11.2.0.3以上からOracle Database 12cにアップグレードできます。そのためには、Oracle Database 12cをインストールし、空のデータベースを作成します。次に、フル・トランスポータブル・エクスポート/インポートを使用して、リリース11.2.0.3データベースをOracle Database 12cデータベースにトランスポートします。
手順の概要は、5.1.1.2.2項「データ・ポンプの全体トランスポータブル・エクスポート/インポート」を参照してください。
データのトランスポートの一般的な制限および全体トランスポータブル・エクスポート/インポート特有の制限については、『Oracle Database管理者ガイド』を参照してください。
データ型が競合するためにSQL Applyを使用できず、テストの結果、DBUAでのアップグレードが稼働時間の要件を満たせないことがわかる場合、トランスポータブル表領域ソリューションを利用したデータベースのアップグレードを検討してください。
トランスポータブル表領域機能を利用してOracle Databaseをアップグレードするには、次の手順に従います。
トランスポート先システムにOracle Databaseソフトウェアをインストールし、ソース・データベースで最初の手順を実行し、トランスポート・プロセスの準備をします。
ソースおよびトランスポート先データベースを準備します。
ソース・データベースから情報を収集します。
Database Configuration Assistant(DBCA)でトランスポート先データベースを作成します。
Oracle Data Pump使用のためと、トランスポートされる表領域を受け入れるために、トランスポート先データベースの準備をします。
次の手順でユーザー表領域をトランスポートします。
ユーザーを切断し、ソース・データベースへのアクセスを制限することで、ソース・データベースのトランスポートの準備をし、すべてのユーザー表領域をREAD ONLYにして、ソース・データベースから順序の開始値を取得します。
ユーザー表領域をトランスポートします。
トランスポート先データベースが完全であり機能することを確認した上でバックアップします。
トランスポータブル表領域の機能を使用する場合、次の点を考慮してください。
トランスポータブル表領域機能は、単純なスキーマを持ち、トランスポート・プロセスの一部としてデータ・ファイルを転送する必要がない(データ・ファイルが所定の場所で使用される場合など)データベースに対して、1時間未満でデータベース・アップグレードを実行するためのオプションです。次のWebサイトにあるMAAホワイト・ペーパー「Database Upgrade Using Transportable Tablespace」を参照してください。
トランスポータブル表領域機能を使用すると、以前のリリースのソフトウェアが稼働するデータベースから、現行リリースのソフトウェアが稼働する空のトランスポート先データベースに、すべてのユーザー表領域を移動することにより、データベースのアップグレード時間が短縮されます。トランスポータブル表領域を持つ表領域データ・ファイルは、データ・ファイルをトランスポート先データベースにコピーし、オブジェクト・メタデータをトランスポート先データベースにインポートすることで、データベースに接続されます。
Oracle GoldenGateを使用してデータベースのアップグレードの停止時間を短縮します。データベースのアップグレードによる停止時間は、ソース・データベースがオンラインのままで現在のバージョンを実行して、ターゲット・データベースを新しいバージョンのアップグレードし、同期を維持することを許可することにより短縮されます。Oracle GoldenGateを使用したときに必要な停止時間は、アプリケーションがターゲット・データベースに再接続するのにかかる時間です。
高度な手順は次のとおりです。
変更－同期「抽出」グループを開始して、実行中のデータの変更を抽出します。
複製ターゲット・データベースを作成します。理想的な複製ターゲット・データベースは、最新のフィジカル・スタンバイ・データベースとして始まります。
ターゲット・データベースをターゲット・バージョンにアクティブ化してアップグレードします(または、表7-6に示すメンテナンス・アクションを実行します)。
変更-同期「Replicat」グループを開始し、ターゲット・データベースの作成およびアップグレード中に変更された行を再同期します。
アプリケーションを停止します。
アプリケーションを開始し、ターゲット・データベースに接続します。
|
関連項目:
|
図5-1の構成は、Data Guardデータベース・ローリング・アップグレードによりサポートされないアップグレードおよび移行などによる、停止時間および計画停止の危険性を最小限に抑えるためのOracle GoldenGateおよびData Guardの構成方法を示します。これには、異なるハードウェア・アーキテクチャおよびオペレーティング・システムへの移行、データベース・オブジェクトを変更するアプリケーション・アップグレードの実行などが含まれます。この構成では、フィジカル・スタンバイ・データベースにより、移行の前後および移行中の停止時間またはデータ損失を防く災害からの保護が提供されます。また、移行の実行に必要な作業から本番データベースを分離することにより、パフォーマンスへの影響または操作上の危険性を回避します。
スタンバイ・データベース(図5-1の右上)から新しい本番データベース(右下)にGoldenGateをレプリケートするには、Oracle GoldenGateアーカイブ・ログ・モードが必要です。アーカイブ・ログ・モードの要件を満たすことができない場合は、元の本番データベース(左上のデータベース)から直接レプリケートします。
スタンバイ(図5-1の左上)からの抽出は可能ですが、ALOモードでのクラシック・キャプチャが必要です。スタンバイ・データベースに対するALOの詳細は、Oracle Data Guardのドキュメントを参照してください。
http://docs.oracle.com/goldengate/1212/gg-winux/GIORA/classic_capture.htm#A1740233
これらの要件は、新しいプラットフォーム上にパラレル環境を作成することにより達成されます。計画された移行のタイプによっては、新規プライマリ・データベースのインスタンス化が、既存のスタンバイ・データベースのバックアップのリストアと同じくらい単純になる可能性があります。より複雑な移行の場合は、Oracleトランスポータブル・テクノロジやOracle Data Pumpなどの、別のOracleテクノロジを使用して新規プライマリ・データベースをインスタンス化します。インスタンス化の後、新しい本番システム上で追加の変更を実装します。すべての変更が実装されると、新規フィジカル・スタンバイ・データベースが作成され、稼働開始後の継続的なデータ保護が提供されます。Oracle GoldenGateの異機種間レプリケーション(以前に構成済)が使用されて、新しい本番システムと、新しい環境の実装中に古いシステムで発生したすべてのトランザクションが同期化されます。同期化が完了すると、本番システムは新しい環境で稼働できるようになります。また、しばらくの間、新しい本番システムと同期された古い環境を保持するために、稼働後にOracle GoldenGate異機種間レプリケーションを使用するオプションもあります。ファスト・フォールバック・オプションでは、予期せぬ問題が発生する可能性があります。
アプリケーションの変更には次に示す機能を使用します。これらの機能を使用することで、アプリケーションのデータベース・オブジェクトの変更に必要なアプリケーションの停止時間を大幅に短縮する(またはゼロにする)ことができます。
エディションベースの再定義(EBR)を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。
アプリケーションを使用中にアップグレードするには、アプリケーションを構成するデータベース・オブジェクトをコピーし、コピーしたオブジェクトを個別に再定義します。アプリケーションのユーザーは、この変更による影響を受けず、変更されていないアプリケーションを引き続き実行します。変更が正しいことを確認できたら、アップグレードしたアプリケーションをすべてのユーザーが使用できるようにします。
この後の項では、エディションベースの再定義のエディション、エディショニング・ビューおよびcrosseditionトリガーの機能について説明します。
詳細は、『Oracle Database開発ガイド』を参照してください。
エディションは非スキーマ・オブジェクトであり、所有者が存在しません。エディションは単一のネームスペースで作成され、データベース内で複数のエディションが共存できます。エディション機能を使用すると、データベース・オブジェクトをコピーし、コピーしたオブジェクトを分離して再定義できます。
データベースには少なくとも1つのエディションが必要です。新規作成またはアップグレードされたOracle Databaseはすべて、ora$baseという名前の1つのエディションから開始されます。
エディションにより、新しいコードのインストールや、データ変更を行うためのプライバシ・メカニズムが提供され、実行中の本番アプリケーションではその変更は見えません。必要な変更がすべて非公開で行われ、1つの動作で公開されます。カットオーバーはセッションが使用するエディションによってのみ決定されます。
1つ以上の表の構造を変更する場合、オンライン・アプリケーション・アップグレード中に基礎となる表に加えられる変更からアプリケーション・コードを隔離するには、エディショニング・ビュー機能も使用する必要があります。表は編集できません。
基礎となる表に列が追加され、それらを公開してデータを移入するために、アップグレード後のエディションで新しいエディショニング・ビューが作成されます。
エディショニング・ビューにはトリガーを作成でき、ビューの列はSQLのヒントで使用できます。エディショニング・ビューの副問合せの定義は、選択した列の別名を推定または定義できるのみです。SELECTリストを使用して、表の列のサブセットを推定し、通常はそれらの名前を変更します。その結果、このリストにより物理列の論理列へのマッピングが定義されます。
crosseditionトリガーは、エディションベースの再定義の一部として使用され、アップグレード前のエディションとアップグレード後のエディションのデータが互いに一致するように保ちます。アップグレード前のアプリケーションは、変更が適用され、アップグレード前のエディションがアップグレード後のエディションに再定義されている間もそのまま使用されます。
表構造の変更中に、ユーザーが表のデータを変更できるようにするには、forward crosseditionトリガーを使用します。他のユーザーがアプリケーションの古いバージョンを使用し続けている間、アップグレード済のアプリケーションを一部のユーザーが使用できるようにするには、reverse crosseditionトリガーも使用します。crosseditionトリガーは、アップグレードしたアプリケーションをユーザー全員が使用できるようにしたら削除するか無効にするため、アプリケーションの永続的な部品ではありません。
高速ローリング・アップグレードにOracle GoldenGateを使用することを検討してください。ただし、Oracle GoldenGateによるアップグレードでは、データベースの停止時間を最小限またはゼロにできますが、このソリューションを構成するには、運用面での投資がある程度必要になります。必要に応じて、3.2項「Oracle GoldenGate」およびOracle 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管理者ガイド』を参照してください。
不可視の列は、列を名前で明示的に指定した場合のみ表示されるユーザー指定の列です。既存のアプリケーションに影響を与えることなく不可視の列を表に追加でき、必要ならばその列を表示可能にできます。
その表を使用するアプリケーションを破壊することなく、表に変更を加える場合、不可視の列を使用できます。表に不可視の列を追加すると、その不可視の列にアクセスする必要のある問合せやその他の操作では、名前で明示的にその列を参照する必要があります。不可視の列を説明するためのアプリケーションを移行する場合、不可視の列を表示することができます。
詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Database 12cでは、Bツリー索引とビットマップ索引の両方を同じ列のセットに作成できます。この機能を使用すれば、特徴が異なってさえいれば、既存の索引と同じ列のセットに、索引を作成できます。この機能により、アプリケーションを破壊することなく、索引のタイプをパッチ・エディションで変更できます。複数の索引のうちいつでも表示できるのは1つのみです。
詳細は、『Oracle Database管理者ガイド』の「同じ列セットでの複数索引の作成」を参照してください。
この機能は、表のオンライン再定義後に依存PL/SQLパッケージを再コンパイルする必要性を最小限に抑えます。再定義によってPL/SQLパッケージに論理的な影響が出ない場合、再コンパイルは必要ありません。この最適化はデフォルトで有効です。
再コンパイルが必要な場合、この機能によって、表のオンライン再定義後に依存PL/SQLパッケージを手動で再コンパイルする時間が短縮され、その手間が軽減されます。再コンパイルには、再定義によって論理的に影響を受けないビュー、シノニム、その他の表依存オブジェクト(トリガーを除く)なども含まれます。オンラインでの表の再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。
脚注の凡例
脚注 1: : Exadataのホワイト・ペーパー『Oracle Exadata Storage Serverへの移行のベスト・プラクティス』(
http://www.oracle.com/technetwork/database/exadata/index.htm)を参照してください。