Oracle® Database

アドバンスト・レプリケーション

11gリリース2(11.2)

B72089-02(原本部品番号:E10706-06)

2013年6月

Oracle Databaseアドバンスト・レプリケーション, 11g リリース2 (11.2)

B72089-02

Copyright © 1996, 2013, Oracle and/or its affiliates. All rights reserved.

原本著者:  Randy Urbano

原本協力者: Nimar Arora、Yuen Chan、Alan Downing、Curt Elsbernd、Yong Feng、Jairaj Galagali、Lewis Kaplan、Jonathan Klein、Jing Liu、Edwina Lu、Pat McElroy、Maria Pratt、Arvind Rajaram、Neeraj Shodhan、Wayne Smith、Jim Stamos、Janet Stern、Mahesh Subramaniam、Lik Wong、David Zhang

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 アドバンスト・レプリケーションの概要

- レプリケーションの概要

- レプリケーションを使用するアプリケーション

- レプリケーションのオブジェクト、グループおよびサイト

- レプリケーション・オブジェクト

- レプリケーション・グループ

- レプリケーション・サイト

- レプリケーション環境のタイプ

- マルチマスター・レプリケーション

- マスター・グループの静止

- マテリアライズド・ビュー・レプリケーション

- 読取り専用マテリアライズド・ビューの概要

- 更新可能マテリアライズド・ビューの概要

- 書込み可能マテリアライズド・ビューの概要

- マテリアライズド・ビューを使用した行と列のサブセット化の概要

- マテリアライズド・ビューのリフレッシュ

- リフレッシュ・グループ

- マテリアライズド・ビュー・ログ

- デプロイメント・テンプレート

- マルチマスターとマテリアライズド・ビューのハイブリッド構成

- スケジュール・リンク

- レプリケーション環境の管理ツール

- Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェース

- レプリケーション・マネージメントAPI

- レプリケーション・カタログ

- 分散スキーマ管理

- レプリケーションの競合

- マルチマスター・レプリケーションのその他のオプション

- 同期レプリケーション

- プロシージャ・レプリケーション

- 競合の検出とプロシージャ・レプリケーション

2 マスター・レプリケーションの概要とアーキテクチャ

- マスター・レプリケーションの概念

- マスター・レプリケーションについて

- マルチマスター・レプリケーション

- シングル・マスター・レプリケーション

- マスター・サイト

- マルチマスター・レプリケーションの使用目的

- フェイルオーバー

- ロード・バランシング

- 非接続マテリアライズド・ビュー環境のサポート

- Oracle Real Application Clustersとアドバンスト・レプリケーションとの比較

- マルチマスター・レプリケーション・プロセス

- 非同期レプリケーション

- 同期レプリケーション

- 競合解消の概念

- オブジェクト型およびコレクションでのレプリケーションの動作方法

- レプリケーション・サイトでの型の一致

- オブジェクト表とレプリケーション

- コレクション列を含む表

- REF列を含む表

- マスター・レプリケーションのアーキテクチャ

- マスター・サイトのメカニズム

- マスター・サイトのロールおよびユーザー

- データベース・リンクとレプリケーション

- レプリケーション・オブジェクト

- 順序のレプリケーションの代替方法

- 内部トリガー

- 遅延トランザクション

- 内部プロシージャ

- キュー

- 管理メカニズム

- レプリケーションの操作モード

- レプリケーション・モードの制御

- 管理要求

- 管理要求キュー

- 編成メカニズム

- マスター・グループ

- 列グループ

- 伝播メカニズム

- 伝播のタイプ

- 同期データ伝播

- 複合モードのマルチマスター・システムについて

- 伝播の開始

- パフォーマンス・メカニズム

- パラレル伝播

- 最小限の通信

- 遅延秒数

- レプリケーションの保護メカニズム

- データ伝播の依存性の維持

- 競合解消メカニズム

- 競合検出時の行の識別

- 上書きによる競合解消方法

3 マテリアライズド・ビューの概要とアーキテクチャ

- マテリアライズド・ビューの概要

- マテリアライズド・ビューについて

- マテリアライズド・ビューの使用目的

- ネットワーク負荷の軽減

- 大規模デプロイメント環境の作成

- データのサブセット化の有効化

- モバイル・コンピューティングの有効化

- 読取り専用、更新可能および書込み可能のマテリアライズド・ビュー

- 読取り専用マテリアライズド・ビュー

- 更新可能マテリアライズド・ビュー

- 書込み可能マテリアライズド・ビュー

- 使用可能なマテリアライズド・ビュー

- 主キー・マテリアライズド・ビュー

- オブジェクト・マテリアライズド・ビュー

- ROWIDマテリアライズド・ビュー

- 複合マテリアライズド・ビュー

- マテリアライズド・ビューの操作に必要な権限

- 作成者が所有者である場合

- 作成者が所有者でない場合

- リフレッシャが所有者である場合

- リフレッシャが所有者でない場合

- マテリアライズド・ビューを使用したデータのサブセット化

- 副問合せを使用するマテリアライズド・ビュー

- 副問合せを使用するマテリアライズド・ビューでの制限事項

- 副問合せを含むUNIONを使用するマテリアライズド・ビューでの制限事項

- マテリアライズド・ビューの高速リフレッシュ機能に関する判断

- 多重化マテリアライズド・ビュー

- 多重化マテリアライズド・ビューの使用例

- 多重化マテリアライズド・ビューの使用上の制限事項

- オブジェクト型およびコレクションでのマテリアライズド・ビューの動作方法

- レプリケーション・サイトでの型の一致

- 列オブジェクトを使用したマスターの列のサブセット化

- オブジェクト表に基づいたマテリアライズド・ビュー

- コレクション列を含むマテリアライズド・ビュー

- REF列を含むマテリアライズド・ビュー

- マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでのマテリアライズド・ビューの登録

- 登録されたマテリアライズド・ビューに関する情報の表示

- 内部メカニズム

- マテリアライズド・ビューの手動による登録

- マテリアライズド・ビューのアーキテクチャ

- マスター・サイトおよびマスター・マテリアライズド・ビュー・サイトのメカニズム

- マスター表およびマスター・マテリアライズド・ビュー

- マテリアライズド・ビュー・ログの内部トリガー

- マテリアライズド・ビュー・ログ

- マテリアライズド・ビュー・サイトのメカニズム

- 索引

- 更新可能マテリアライズド・ビュー・ログ

- 更新可能マテリアライズド・ビュー・ログの内部トリガー

- 編成メカニズム

- マテリアライズド・ビュー・グループ

- リフレッシュ・グループ

- リフレッシュ・グループのサイズ

- リフレッシュ処理

- リフレッシュ・タイプ

- リフレッシュの開始

- 制約およびリフレッシュ

4 デプロイメント・テンプレートの概要およびアーキテクチャ

- 大規模デプロイメントの課題

- デプロイメント・テンプレートおよび大規模デプロイメントの目標

- Oracleデプロイメント・テンプレートの概念

- デプロイメント・テンプレートの要素

- テンプレート一般情報

- テンプレートのオブジェクト定義

- テンプレート・パラメータ

- WHERE句のテンプレート・パラメータとセキュリティ

- ユーザー認証

- デプロイメント・サイト

- デプロイメント・テンプレートのパッケージ化とインスタンス化

- オンライン・インスタンシエーション

- オフライン・インスタンシエーション

- デプロイメント・テンプレートのインスタンス化の使用例

- デプロイメント・テンプレートのアーキテクチャ

- システム表に格納されたテンプレート定義

- 標準DDLの使用

- パッケージ化およびインスタンス化のプロセス

- オンライン・インスタンシエーション用のデプロイメント・テンプレートのパッケージ化

- オフライン・インスタンシエーション用のデプロイメント・テンプレートのパッケージ化

- オンライン・インスタンシエーション

- オフライン・インスタンシエーション

- パッケージ化およびインスタンス化のオプション

- インスタンス化の結果

- マテリアライズド・ビュー・グループ

- リフレッシュ・グループ

- デプロイメント・テンプレートの設計

- デプロイメント・テンプレートを使用した列のサブセット化

- 行のサブセット化

- 割当て表を使用した行のサブセット化

- データ・セット

- 設計に関するその他の考慮事項

- マテリアライズド・ビュー作成のローカル制御

- マテリアライズド・ビューのローカル制御

5 競合解消の概念およびアーキテクチャ

- 競合解消の概念

- データ要件およびアプリケーション要件の理解

- 競合の検出と解消の例

- レプリケーションの競合のタイプ

- 更新の競合

- 一意性競合

- 削除の競合

- データの競合およびトランザクションの順序

- 競合の検出

- 異なるタイプの競合の検出方法

- 競合検出時の行の識別

- 競合解消

- 多重化マテリアライズド・ビューと競合解消

- 更新可能マテリアライズド・ビューの列のサブセット化と競合解消

- ネストした表と競合解消

- 競合回避のテクニック

- 列グループの使用

- プライマリ・サイトおよび動的サイト所有権データ・モデルの使用

- 特定のタイプの競合の回避

- 競合解消のアーキテクチャ

- サポート・メカニズム

- 列グループ

- エラー・キュー

- 更新の競合の一般的な解消方法

- 最新のタイムスタンプ

- 上書き

- 更新の競合のその他の解消方法

- 加算

- 平均

- 廃棄

- 最も古いタイムスタンプ

- 最大値

- 最小値

- 優先グループ

- サイト優先順位

- 一意性競合の解消方法

- サイト名の追加

- 順序の追加

- 廃棄

- 削除の競合解消方法

- 古い値の送信および比較

- 送信および比較の例

- 列オブジェクト使用時の送信および比較

6 レプリケーション環境の計画

- レプリケート表に関する考慮事項

- 主キーとレプリケート表

- 外部キーとレプリケート表

- レプリケート表のデータ型に関する考慮事項

- サポートされていない表タイプ

- 行レベルでの依存性の追跡

- 初期化パラメータ

- マスター・サイトとマテリアライズド・ビュー・サイトの比較

- マスター・サイトの利点

- マテリアライズド・ビュー・サイトの利点

- マテリアライズド・ビューの準備

- マテリアライズド・ビュー・サイトのユーザーの作成

- マスター・サイト・ユーザーの作成

- マテリアライズド・ビュー・サイトでのスキーマの作成

- データベース・リンクの作成

- 権限の割当て

- マスター・サイトでのスケジュール・パージ

- スケジュール・プッシュ

- ジョブ・スレーブの割当て

- マテリアライズド・ビュー・ログの作成

- マテリアライズド・ビュー・ログへの列のロギング

- マテリアライズド・ビュー環境の作成

- レプリケーション・マネージメント・インタフェースを使用したマテリアライズド・ビュー環境の作成

- レプリケーション・マネージメントAPIを使用したマテリアライズド・ビュー環境の作成

- 新規マテリアライズド・ビュー・サイトを追加するときの問題の回避

- アドバンスト・レプリケーション環境の相互運用性

- スケジュール・リンクのガイドライン

- 定期的なプッシュのスケジューリング

- 連続的なプッシュのスケジューリング

- 遅延トランザクション・キューのスケジュール・パージのガイドライン

- 定期的なパージのスケジューリング

- 連続的なパージのスケジューリング

- シリアル伝播およびパラレル伝播

- デプロイメント・テンプレート

- デプロイメント・テンプレートをインスタンス化するマテリアライズド・ビュー・サイトの準備

- ネットワーク接続性

- データベースのバージョン

- マテリアライズド・ビュー・サイトの設定

- 必要なスキーマの作成

- データベース・リンクの作成

- オンライン・インスタンシエーションおよびオフライン・インスタンシエーション

- 必要なロールバック・セグメントの作成

- 競合解消

- セキュリティとレプリケーション

- 耐障害性を実現するための設計

- Oracle Real Application Clustersとレプリケーションの比較

- 耐障害性を実現するレプリケーション環境の設計

- 耐障害性の高いシステムの実装

- レプリケーション環境におけるデータベースのリカバリ

A レプリケーションに関する問題のトラブルシューティング

- データベース・リンクに関する問題の診断方法

- マスター・サイトに関する問題の診断方法

- 新しいマスター・サイトでレプリケート・オブジェクトが作成されない場合

- DDLによる変更がマスター・サイトに伝播されない場合

- DMLによる変更が他のサイトに非同期で伝播されない場合

- DMLをレプリケート表に適用できない場合

- バルク更新および制約違反

- レプリケート・オブジェクトの再作成

- 表のレプリケーション・サポートを生成できない場合

- レプリケート・プロシージャまたはレプリケート・トリガーに関する問題

- 遅延トランザクション・キューに関する問題の診断方法

- スケジュール・リンクのジョブのチェック

- 同期レプリケーション使用時の分散トランザクションの問題

- データベース・リンク指定の不備

- 不適切なレプリケーション・カタログ・ビュー

- マテリアライズド・ビューに関連する問題の診断方法

- マテリアライズド・ビュー・サイトでのレプリケート・オブジェクトの作成に関する問題

- デプロイメント・テンプレートのオフライン・インスタンシエーションの実行に関する問題

- リフレッシュに関する問題

- リフレッシュに関する一般的な問題

- 自動リフレッシュの再試行

- 新規マテリアライズド・ビュー・サイトでの高速リフレッシュ・エラー

- マテリアライズド・ビューが繰り返しリフレッシュされる場合

- マテリアライズド・ビュー・ログが大きくなりすぎる場合

- リフレッシュに関する問題の高度なトラブルシューティング

B 列長セマンティクスとUnicode

- レプリケーション・サイトおよび表の列に関する列長セマンティクス

- マルチマスター環境での列長セマンティクス・サポート

- アドバンスト・レプリケーションによって生成された表に対する列長セマンティクス・サポート

- 事前作成された表に対する列長セマンティクス・サポート

- マテリアライズド・ビューでの列長セマンティクス・サポート

- ビルトインのコンテナ表を含むマテリアライズド・ビュー

- 更新可能マテリアライズド・ビューに対する列長セマンティクス・サポート

- DDL伝播と列長セマンティクス

- Unicodeに対するレプリケーション・サポート

- NCLOBデータ型列のレプリケーション

索引

図一覧

- 1-1 マルチマスター・レプリケーション

- 1-2 読取り専用マテリアライズド・ビューのレプリケーション

- 1-3 更新可能マテリアライズド・ビューのレプリケーション

- 1-4 ハイブリッド構成

- 1-5 Enterprise Managerのアドバンスト・レプリケーション・インタフェース

- 2-1 マルチマスター・レプリケーション

- 2-2 複数ポイントの更新アクセスをサポートするマルチマスター・レプリケーション

- 2-3 データベース・リンクを表す矢印

- 2-4 すべてのサイトで同じレプリケーション・オブジェクトを含むマスター・グループhr_mg

- 2-5 各マスター・サイトで同一のマスター・グループ

- 2-6 非同期データ・レプリケーションのメカニズム

- 2-7 同期データ・レプリケーションのメカニズム

- 2-8 行レベルの同期レプリケーションを使用した変更の伝播

- 2-9 伝播モードの選択

- 2-10 順序に関する考慮事項

- 3-1 1つのマスター・サイトに接続されたマテリアライズド・ビュー

- 3-2 単純マテリアライズド・ビューと複合マテリアライズド・ビューの比較

- 3-3 多対1副問合せを使用した行のサブセット化

- 3-4 1対多副問合せを使用した行のサブセット化

- 3-5 多対多副問合せを使用した行のサブセット化

- 3-6 副問合せおよびUNIONを使用した行のサブセット化

- 3-7 多重化マテリアライズド・ビュー

- 3-8 マテリアライズド・ビューのレベル

- 3-9 マスター・マテリアライズド・ビュー

- 3-10 マテリアライズド・ビューのレプリケーション・オブジェクト

- 3-11 マスター・サイトおよびマスター・マテリアライズド・ビュー・サイトのオブジェクト

- 3-12 マテリアライズド・ビュー・グループとマスター・グループの対応

- 3-13 複数のマテリアライズド・ビュー・グループのオブジェクトを含むリフレッシュ・グループ

- 3-14 マテリアライズド・ビューの高速リフレッシュ

- 4-1 デプロイメント・テンプレートのビューの関係

- 4-2 デプロイメント・テンプレートに追加するテンプレートの要素

- 4-3 オンライン・インスタンシエーション

- 4-4 オフライン・インスタンシエーション

- 4-5 オンライン・インスタンシエーション時のパラメータのチェック

- 4-6 列がサブセット化されたデータのレプリケート

- 4-7 製品と倉庫の関係

- 4-8 営業担当員用テンプレートと顧客サービス技術者用テンプレートの相違

- 5-1 競合解消と多重化マテリアライズド・ビュー

- 5-2 優先グループの使用方法

- 5-3 列グループとデータ伝播

- 6-1 推奨されるスキーマおよびデータベース・リンク構成

- 6-2 マテリアライズド・ビュー環境作成のためのフローチャート

- 6-3 耐障害性を実現するための方法: レプリケーションまたはOracle Real Application Clusters

表一覧

- 3-1 マテリアライズド・ビューの作成に必要な権限(作成者が所有者でない場合)

- 3-2 マテリアライズド・ビューのリフレッシュに必要な権限(リフレッシャが所有者でない場合)

- 3-3 大規模リフレッシュ・グループおよび小規模リフレッシュ・グループ

- 4-1 デプロイメント・テンプレートのインスタンス化の使用例

- 4-2 パッケージ化およびインスタンス化のオプション

- 5-1 例: サイト優先順位による競合解消方法を使用した場合の順序競合

- 5-2 更新の競合の一般的な解消方法のデータ収束プロパティ

- 5-3 更新の競合のその他の解消方法のデータ収束プロパティ

- 6-1 アドバンスト・レプリケーションにおいて重要な初期化パラメータ

- 6-2 マスター・サイトとマテリアライズド・ビュー・サイトの特性

- 6-3 定期的なプッシュのスケジューリングの設定

- 6-4 連続的なプッシュをシミュレートする設定

- 6-5 定期的なパージのスケジューリングの設定

- 6-6 連続的なパージのスケジューリングの設定

- B-1 生成された表に対する列長セマンティクス・サポート

- B-2 事前作成された表に対する列長セマンティクス・サポート

- B-3 更新可能マテリアライズド・ビューに対する列長セマンティクス・サポート

- B-4 グローバリゼーション・サポート・キャラクタ・セットに対するレプリケーション・サポート

はじめに

『Oracle Databaseアドバンスト・レプリケーション』では、アドバンスト・レプリケーションの機能について説明します。具体的には、アドバンスト・レプリケーションの概要およびレプリケーション環境の計画とレプリケーションに関する問題のトラブルシューティングの情報を提供します。

ここでは、次の項目について説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Databaseアドバンスト・レプリケーション』は、データベース管理者と、レプリケーション環境を開発およびメンテナンスするアプリケーション開発者を対象としています。これらの管理者およびアプリケーション開発者は、次のような作業を1つ以上実行します。

- レプリケーション環境の計画

- 次のタイプのレプリケーション環境の構成

- 読取り専用マテリアライズド・ビュー

- 更新可能マテリアライズド・ビュー

- シングル・マスター・レプリケーション

- マルチマスター・レプリケーション

- デプロイメント・テンプレートを使用したマテリアライズド・ビュー環境の作成

- 競合解消の構成

- レプリケーション環境の管理

- トラブルシューティング・アクティビティの実行(必要な場合)

- ジョブ・キューの管理

- 遅延トランザクションの管理

- Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用した、レプリケーション環境の作成、監視および管理

このマニュアルを使用するには、リレーショナル・データベースの概念、分散データベースの管理、PL/SQL (プロシージャ・レプリケーションを使用する場合)、およびアドバンスト・レプリケーション環境が実行されるオペレーティング・システムについてよく理解している必要があります。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』

- Oracle Enterprise Managerのアドバンスト・レプリケーションのオンライン・ヘルプ

- 『Oracle Database概要』

- 『Oracle Database管理者ガイド』

- 『Oracle Database SQL言語リファレンス』

- 『Oracle Database PL/SQL言語リファレンス』

- 『Oracle Streamsレプリケーション管理者ガイド』(ご使用のアドバンスト・レプリケーション環境をOracle Streamsへ移行する場合)

このマニュアルに記載されている多数の例は、Oracle Databaseとともにデフォルトでインストールされる、サンプル・データベースのサンプル・スキーマを使用しています。サンプル・スキーマの作成方法およびその使用方法については、『Oracle Databaseサンプル・スキーマ』を参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 アドバンスト・レプリケーションの概要

この章では、アドバンスト・レプリケーションに関する基本的な概念および用語について説明します。

この章には、次の項が含まれます。

- レプリケーションの概要

- レプリケーションを使用するアプリケーション

- レプリケーションのオブジェクト、グループおよびサイト

- レプリケーション環境のタイプ

- レプリケーション環境の管理ツール

- レプリケーションの競合

- マルチマスター・レプリケーションのその他のオプション

注意:
Trusted Oracleを使用している環境でレプリケーションを使用する方法は、Oracleセキュリティ関連製品のドキュメントを参照してください。

レプリケーションの概要

レプリケーションとは、分散データベース・システムを構成する複数のデータベースのデータベース・オブジェクト(表など)をコピーおよびメンテナンスするプロセスです。1つのサイトに適用された変更は、ローカルで取得および格納された後、リモートの各場所に転送され、適用されます。アドバンスト・レプリケーションは、Oracleサーバーの完全に統合された機能で、別の独立したサーバーではありません。

レプリケーションは、分散データベース・テクノロジを使用して複数サイト間でデータを共有する機能ですが、レプリケート・データベースと分散データベースは異なります。分散データベースの場合は、多くの場所からデータを使用できますが、特定の表が存在するのは1つの場所のみです。たとえば、employees表は分散データベース・システム内のny.example.comデータベースのみに含まれますが、この分散データベース・システムにはhk.example.comデータベースとla.example.comデータベースも含まれています。レプリケーションでは、複数の場所で同一のデータを使用できます。たとえば、employees表は、ny.example.com、hk.example.comおよびla.example.comで使用できます。

レプリケーションを使用するのは、次の理由によります。

可用性

レプリケーションを行うと、複数サイト間でアクティビティを均衡化できるので、共有データに高速にローカル・アクセスできます。各ユーザーは同時に別々のサーバーにアクセスでき、その結果全サーバーの負荷が軽減されます。また、ユーザーはアクセス・コストが最も低いレプリケーション・サイト(通常、ユーザーから地理的に最も近いサーバー)のデータを利用できます。

パフォーマンス

レプリケーションを行うと、複数サイト間でアクティビティを均衡化できるので、共有データに高速にローカル・アクセスできます。各ユーザーは同時に別々のサーバーにアクセスでき、その結果全サーバーの負荷が軽減されます。

モバイル・コンピューティング

マテリアライズド・ビューとは、ある一時点におけるターゲット表の完全または部分的なコピー(レプリカ)です。マテリアライズド・ビューを使用すると、ユーザーは中央のデータベース・サーバーに接続せずにデータベースのサブセットを操作できます。その後、中央のデータベース・サーバーとの接続が確立された時点で、必要に応じてマテリアライズド・ビューを同期化(リフレッシュ)できます。ユーザーがマテリアライズド・ビューをリフレッシュすると、マテリアライズド・ビュー・サイトのすべての変更が中央のデータベースに反映され、ユーザーが接続されていない間に中央のデータベースで発生した変更が、マテリアライズド・ビューに反映されます。

ネットワーク負荷の軽減および大規模デプロイメント

レプリケーションを使用すると、複数の場所にデータを分散できます。したがって、アプリケーションは中央の1つのサーバーではなく様々な地域サーバーにアクセスできます。このように構成することで、ネットワーク負荷は大幅に軽減されます。

レプリケーションの使用方法の詳細は、以降の章で説明します。

注意:
アドバンスト・レプリケーション機能は、すべてのOracle Databaseのインストール時に自動的にインストールおよびアップグレードされます。

関連項目:
分散データベースの詳細は、『Oracle Database管理者ガイド』を参照してください。

レプリケーションを使用するアプリケーション

レプリケーションは、要件が異なる様々なアプリケーションをサポートしています。アプリケーションの中には、比較的自律的な個別のマテリアライズド・ビュー・サイトに適しているものもあります。たとえば、営業支援システム、フィールド・サービス、小売りなどの大規模デプロイメントアプリケーションでは、通常、中央のデータベース・システムと、中央のデータベースと非接続状態にあることが多い多数の小規模リモート・サイトとの間で定期的にデータを同期化する必要があります。営業担当員は、中央のデータベースに接続されているかどうかに関係なく、トランザクションを完了できる必要があります。この場合、リモート・サイトは自律的である必要があります。

これに対し、コール・センターやインターネット・システムなどのアプリケーションでは、複数のサーバー上のデータを継続的かつほぼ即時に同期化し、常に同じ内容のサービスを利用できる必要があります。たとえば、インターネット上の小売りWebサイトでは、顧客が閲覧する情報がどのサイトのオンライン・カタログでも同じであることが必要です。この場合、サイトの自律性よりもデータ整合性が重要です。

アドバンスト・レプリケーションは、前述の2種類のアプリケーションでそれぞれに使用することも、2種類のアプリケーションを組み合せたシステムで使用することもできます。実際、1つのアドバンスト・レプリケーション環境で、大規模デプロイメントレプリケーションとサーバー/サーバー・レプリケーションの両方をサポートできるので、一貫した環境に統合することが可能です。このような環境では、たとえば、営業支援システムと顧客サービスのコール・センターの間でデータを共有できます。

アドバンスト・レプリケーションは、異なるリリースのOracleを使用する環境や別々のオペレーティング・システムでOracleを実行する環境でデータをレプリケートできます。したがって、このような環境でデータを使用するアプリケーションは、アドバンスト・レプリケーションを使用できます。

レプリケーションのオブジェクト、グループおよびサイト

次の項では、レプリケーション・オブジェクト、レプリケーション・グループ、レプリケーション・サイトなど、レプリケーション・システムの基本構成要素について説明します。

レプリケーション・オブジェクト

レプリケーション・オブジェクトは、分散データベース・システム内の複数のサーバーに存在するデータベース・オブジェクトです。レプリケーション環境では、1つのサイトのレプリケーション・オブジェクトに加えられた更新がすべて、その他の各サイトにあるコピーに適用されます。アドバンスト・レプリケーションを使用すると、次のタイプのオブジェクトをレプリケートできます。

- 表

- 索引

- ビューおよびオブジェクト・ビュー

- パッケージおよびその本体

- プロシージャおよびファンクション

- ユーザー定義型および型の本体

- トリガー

- シノニム

- 索引タイプ

- ユーザー定義演算子

表に関しては、レプリケーションでは高度な機能(パーティション表、索引構成表、ユーザー定義型を基にした列を含む表、オブジェクト表など)をサポートしています。

レプリケーション・グループ

レプリケーション環境では、レプリケーション・グループを使用してレプリケーション・オブジェクトを管理します。レプリケーション・グループは、論理的に関連付けられたレプリケーション・オブジェクトの集合です。

レプリケーション・グループ内に関連するデータベース・オブジェクトを編成すると、多数のオブジェクトをまとめて簡単に管理できます。通常、レプリケーション・グループを作成および使用して、特定のデータベース・アプリケーションのサポートに必要なスキーマ・オブジェクトを編成します。ただし、レプリケーション・グループおよびスキーマは、相互に対応している必要はありません。レプリケーション・グループには、複数のスキーマのオブジェクトを含めることができ、1つのスキーマには、複数のレプリケーション・グループ内のオブジェクトを含めることができます。ただし、各レプリケーション・オブジェクトは、1つのレプリケーション・グループのメンバーにしかなれません。

レプリケーション・サイト

レプリケーション・グループは、複数のレプリケーション・サイトに存在できます。レプリケーション環境では、マスター・サイトとマテリアライズド・ビュー・サイトという2つの基本的なタイプのサイトがサポートされます。1つのサイトは、1つのレプリケーション・グループのマスター・サイトであり、同時に別のレプリケーション・グループのマテリアライズド・ビュー・サイトにもなることができます。ただし、同一レプリケーション・グループ内のマスター・サイトとマテリアライズド・ビュー・サイトになることはできません。

マスター・サイトとマテリアライズド・ビュー・サイトの違いは次のとおりです。

- マスター・サイトのレプリケーション・グループは、マスター・グループと呼ばれます。マテリアライズド・ビュー・サイトのレプリケーション・グループはマスター・グループを基にしており、マテリアライズド・ビュー・グループと呼ばれます。また、すべてのマスター・グループには、マスター定義サイトが1つずつ存在します。レプリケーション・グループのマスター定義サイトは、レプリケーション・グループおよびグループ内のオブジェクトを管理する制御センターとして機能するマスター・サイトです。

- マスター・サイトでは、レプリケーション・グループ内のすべてのオブジェクトの完全なコピーが保持されますが、マテリアライズド・ビュー・サイトのマテリアライズド・ビューには、マスター・グループ内の表データのすべてが含まれる場合と一部が含まれる場合があります。たとえば、hr_repgマスター・グループに表employeesおよびdepartmentsが含まれている場合、マスター・グループに含まれているすべてのマスター・サイトでは、employeesおよびdepartmentsの完全なコピーを保持する必要があります。一方、あるマテリアライズド・ビュー・サイトにはemployees表のマテリアライズド・ビューのみを含め、別のマテリアライズド・ビュー・サイトにはemployees表とdepartments表を両方とも含めることができます。

- マルチマスター・レプリケーション環境のすべてのマスター・サイトは、相互に直接通信を行って、レプリケーション・グループのデータの変更を絶えず伝播します。マテリアライズド・ビュー・サイトには、ある一時点における表データのイメージ、すなわちマテリアライズド・ビューが含まれています。通常、マテリアライズド・ビューは、定期的にリフレッシュされてマスター・サイトと同期化されます。マテリアライズド・ビューはリフレッシュ・グループに編成できます。リフレッシュ・グループ内のマテリアライズド・ビューは、1つ以上のマテリアライズド・ビュー・グループに含めることができ、各マテリアライズド・ビューは、リフレッシュ・グループ内のすべてのマテリアライズド・ビューのデータがトランザクションの一貫性を保つ特定の時点と一致するように、同時にリフレッシュされます。

レプリケーション環境のタイプ

アドバンスト・レプリケーションは、次のタイプのレプリケーション環境をサポートしています。

- マルチマスター・レプリケーション

- マテリアライズド・ビュー・レプリケーション

- マルチマスターとマテリアライズド・ビューのハイブリッド構成

マルチマスター・レプリケーション

マルチマスター・レプリケーション(peer-to-peerレプリケーションまたはn-wayレプリケーションとも呼ばれます)を使用すると、同等ピアとして機能する複数サイトでレプリケート・データベース・オブジェクトのグループを管理できます。マルチマスター・レプリケーション環境では各サイトがマスター・サイトで、各サイトが他のマスター・サイトと通信します。

アプリケーションは、マルチマスター構成のサイトにある任意のレプリケート表を更新できます。マルチマスター環境でマスター・サイトとして機能しているOracle Databaseサーバーで、すべての表レプリカのデータが自動的に収集され、グローバルなトランザクション一貫性およびデータ整合性が保証されます。

マルチマスター・レプリケーションを実装する最も一般的な方法は非同期レプリケーションです。他の方法として、同期レプリケーションとプロシージャ・レプリケーションがあります。同期レプリケーションを使用する場合には、表のデータ操作言語(DML)の変更についての情報が、変更が行われたマスター・サイトの遅延トランザクション・キューに格納されます。この変更は、遅延トランザクションと呼ばれます。遅延トランザクションは、他の関連するマスター・サイトに定期的に送信(または伝播)されます。これらの間隔で時間の量を制御できます。

非同期レプリケーションを使用すると、同じ行の値が2つの別のマスター・サイトでほぼ同時に更新される場合があるため、データ競合が発生する可能性があります。ただし、競合は技術によって回避することができ、競合が発生した場合は、Oracleが提供する組込みメカニズムにより問題を解決できます。解消されない競合に関する情報は、エラー・ログに格納されます。

図1-1 マルチマスター・レプリケーション

マスター・グループの静止

マスター・グループで管理作業を実行するために、マスター・グループのレプリケーション・アクティビティをすべて停止することが必要な場合があります。たとえば、新しいマスター・グループ・オブジェクトを追加するには、マスター・グループのレプリケーション・アクティビティをすべて停止する必要があります。マスター・グループのレプリケーション・アクティビティをすべて停止することを、グループの静止といいます。マスター・グループの静止中は、マスター・グループ内のオブジェクトに対してDML文を発行できません。また、マスター・グループを静止する前に、遅延トランザクションをすべて伝播しておく必要があります。ユーザーは静止中のマスター・グループ内の表に対して、問合せを引き続き実行できます。

マテリアライズド・ビュー・レプリケーション

マテリアライズド・ビューには、ある一時点におけるターゲット・マスターの完全コピーまたは部分的なコピーが含まれます。ターゲット・マスターは、マスター・サイトのマスター表またはマテリアライズド・ビュー・サイトのマスター・マテリアライズド・ビューのいずれかです。マスター・マテリアライズド・ビューは、別のマテリアライズド・ビューのマスターとして機能するマテリアライズド・ビューです。多重化マテリアライズド・ビューは、マスター表ではなく他のマテリアライズド・ビューを基にしたマテリアライズド・ビューです。

マテリアライズド・ビューには、次の利点があります。

- ローカル・アクセスが可能なため、応答時間を短縮し、可用性を向上できます。

- ユーザーはローカルなマテリアライズド・ビューに問合せを実行できるため、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに対する問合せ負荷が軽減されます。

- ターゲット・マスターのデータ・セットのうち、選択したサブセットのみをレプリケート可能にすることにより、データ・セキュリティを高めることができます。

マテリアライズド・ビューは、読取り専用、更新可能または書込み可能のいずれかで、このようなマテリアライズド・ビューには前述したリストにない他の利点があります。

読取り専用マテリアライズド・ビューの概要

基本的な構成では、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータを基に作成された表データに対して、マテリアライズド・ビューは読取り専用アクセスを提供します。アプリケーションでは読取り専用マテリアライズド・ビューからデータを問い合せることにより、ネットワークが使用できるかどうかに関係なくマスター・サイトへのネットワーク・アクセスを回避できます。ただし、アプリケーションでデータ操作言語(DML)による変更を実行する場合は、システムのあらゆる場所からマスター・サイトのデータにアクセスする必要があります。図1-2は、基本的な読取り専用レプリケーションを示します。読取り専用マテリアライズド・ビューのマスター表およびマスター・マテリアライズド・ビューは、レプリケーション・グループに属する必要はありません。

読取り専用マテリアライズド・ビューには、次の利点があります。

- 更新できないため、競合の可能性がありません。

- 複合マテリアライズド・ビューをサポートします。複合マテリアライズド・ビューの例として、集合演算またはCONNECT BY句を含むマテリアライズド・ビューがあります。

関連項目:
複合マテリアライズド・ビューの詳細は、「使用可能なマテリアライズド・ビュー」を参照してください。

図1-2 読取り専用マテリアライズド・ビューのレプリケーション

更新可能マテリアライズド・ビューの概要

より高度な構成では、更新可能マテリアライズド・ビューを作成でき、これを使用すると、ユーザーはマテリアライズド・ビューに対して行の挿入、更新および削除の操作を実行することで、ターゲット・マスター表またはマスター・マテリアライズド・ビューの行を挿入、更新および削除できます。更新可能マテリアライズド・ビューには、ターゲット・マスター内のデータのサブセットも含められます。図1-3は、更新可能マテリアライズド・ビューを使用したレプリケーション環境を示します。

更新可能マテリアライズド・ビューは、レプリケーションをサポートするように設定されている表やその他のマテリアライズド・ビューに基づいています。実際、更新可能マテリアライズド・ビューは、別のレプリケーション・グループに基づいたマテリアライズド・ビュー・グループに含まれている必要があります。更新可能マテリアライズド・ビューへの変更をリフレッシュ中にマスターにプッシュするには、更新可能マテリアライズド・ビューがマテリアライズド・ビュー・グループに属する必要があります。

図1-3 更新可能マテリアライズド・ビューのレプリケーション

更新可能マテリアライズド・ビューには、次の特性があります。

- 常に1つの表に基づいています。ただし、副問合せで複数の表を参照できます。

- 増分リフレッシュ(または高速リフレッシュ)を実行できます。

- 更新可能マテリアライズド・ビューに加えられた変更は、マテリアライズド・ビューのリモートのマスター表またはマスター・マテリアライズド・ビューに伝播されます。次に、マスターへの更新が他のすべてのレプリケーション・サイトにカスケードして伝播されます。

更新可能マテリアライズド・ビューには、次の利点があります。

- マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに接続されていない状態でも、ローカルのレプリケート・データ・セットに対して問合せおよび更新ができます。

- データの更新をサポートしていますが、リソースはマルチマスター・レプリケーションの場合よりも少なくて済みます。マルチマスター・レプリケーションでは定期的な間隔で変更が伝播されますが、マテリアライズド・ビューは必要に応じてリフレッシュできるため、ネットワーク・リソースにかかる負荷を軽減できます。さらに、マテリアライズド・ビューは非常に少ないデータしか含まないデータベース内にも常駐させることが可能なため、マテリアライズド・ビュー・クライアントのためのディスク領域とメモリー要件は、マスター・サイトを含むOracleサーバーに対する要件より少なくて済みます。

書込み可能マテリアライズド・ビューの概要

FOR UPDATE句を使用してマテリアライズド・ビューを作成し、このマテリアライズド・ビューをマテリアライズド・ビュー・グループに追加しないことが可能です。この場合、ユーザーはこのマテリアライズド・ビューに対してデータ操作言語(DML)による変更を実行できますが、この変更はマスターにプッシュされず、マテリアライズド・ビューがリフレッシュされた場合は変更が失われます。このようなマテリアライズド・ビューは、書込み可能マテリアライズド・ビューと呼ばれます。

マテリアライズド・ビューを使用した行と列のサブセット化の概要

行と列のサブセット化により、マスター表またはマスター・マテリアライズド・ビューのデータの部分的なコピーを含むマテリアライズド・ビューを作成できます。このようなマテリアライズド・ビューは、すべてのデータ・セットを必要としない地域事業所や営業担当員に役立ちます。

行のサブセットでは、WHERE句を使用して、マスター内の必要な行のみをマテリアライズド・ビューに含めることができます。列のサブセットでは、マスター内の必要な列のみをマテリアライズド・ビューに含めることができます。マテリアライズド・ビューを作成する際に、SELECT文で特定の列を指定してこれらを実行します。

注意:
更新可能マテリアライズド・ビューの列のサブセット化は、デプロイメント・テンプレートおよびOracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用する場合にのみサポートされます。この制限は、読取り専用マテリアライズド・ビューの列のサブセット化にはあてはまりません。

関連項目:

- 「マテリアライズド・ビューを使用したデータのサブセット化」

- 「デプロイメント・テンプレートを使用した列のサブセット化」

マテリアライズド・ビューのリフレッシュ

マテリアライズド・ビューとマスター表またはマスター・マテリアライズド・ビューとの間で一貫性を保つには、マテリアライズド・ビューを定期的にリフレッシュする必要があります。マテリアライズド・ビューをリフレッシュするには、次の3つの方法があります。

- マテリアライズド・ビュー・ログを使用して、最後のリフレッシュ以降に変更されている行のみを更新する高速リフレッシュ。

- マテリアライズド・ビュー全体を更新する完全リフレッシュ。

- 可能なときに高速リフレッシュを実行する強制リフレッシュ。高速リフレッシュが実行できない場合は、完全リフレッシュが実行されます。

リフレッシュ・グループ

マテリアライズド・ビュー間のトランザクションの一貫性を保つことが重要なときは、マテリアライズド・ビューをリフレッシュ・グループに編成できます。リフレッシュ・グループをリフレッシュすることで、リフレッシュ・グループ内のすべてのマテリアライズド・ビューのデータが、トランザクションの一貫性を保つ特定の時点のデータと確実に一致します。読取り専用マテリアライズド・ビューと更新可能マテリアライズド・ビューは、どちらもリフレッシュ・グループに含められます。リフレッシュ・グループ内のマテリアライズド・ビューを個別にリフレッシュすることも可能ですが、リフレッシュ・グループ内のその他のマテリアライズド・ビューはリフレッシュされないため、リフレッシュ・グループを編成する意味がなくなります。

マテリアライズド・ビュー・ログ

マテリアライズド・ビュー・ログは、マテリアライズド・ビューのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにある表で、DMLによってマスター表またはマスター・マテリアライズド・ビューに加えられたすべての変更を記録します。マテリアライズド・ビュー・ログは1つのマスター表またはマスター・マテリアライズド・ビューと対応付けられ、それぞれのマスター表またはマスター・マテリアライズド・ビューには、マスターからリフレッシュされるマテリアライズド・ビューの数に関係なく、1つのマテリアライズド・ビュー・ログがあります。マテリアライズド・ビューの高速リフレッシュは、マテリアライズド・ビューのマスターにマテリアライズド・ビュー・ログがある場合にのみ可能です。マテリアライズド・ビューを高速リフレッシュすると、マテリアライズド・ビューと対応付けられたマテリアライズド・ビュー・ログのエントリで、最後のリフレッシュ以降に追加されたエントリがマテリアライズド・ビューに適用されます。

デプロイメント・テンプレート

デプロイメント・テンプレートを使用すると、多くのリモート・マテリアライズド・ビュー・サイトの配置およびメンテナンス作業が簡単になります。また、デプロイメント・テンプレートを使用すると、マスター・サイトでマテリアライズド・ビュー定義の集合を定義でき、その定義中のパラメータを使用してマテリアライズド・ビューを個々のユーザーまたはユーザーのタイプにあわせてカスタマイズできます。

たとえば、営業用に1つのテンプレートを作成し、サービス技術員用に別のテンプレートを作成する場合などです。この場合、販売地域や顧客サポート・レベルなどのパラメータ値を使用できます。リモート・ユーザーは、マスター・サイトに接続するときに、使用可能なテンプレートのリストを問い合せることができます。ユーザーがテンプレートをインスタンス化すると、リモート・サイトで適切なマテリアライズド・ビューが作成され、データが移入されます。パラメータ値は、リモート・ユーザーが指定するか、マスター・サイトに保持されている表の値を利用します。

オンライン・インスタンシエーションおよびオフライン・インスタンシエーション

ユーザーがマテリアライズド・ビュー・サイトでテンプレートをインスタンス化すると、オブジェクトDDL(たとえば、CREATE MATERIALIZED VIEW文やCREATE TABLE文)が実行されて、マテリアライズド・ビュー・サイトに適切なスキーマ・オブジェクトが作成され、そのオブジェクトに適切なデータが移入されます。テンプレートのインスタンス化は、マスター・サイトに接続した状態でネットワークを介して行うことも(オンライン・インスタンシエーション)、あるいはマスター・サイトから切断された状態で行うこともできます(オフライン・インスタンシエーション)。

オフライン・インスタンシエーションは、ピーク期間中のサーバー負荷を軽減したり、リモート接続時間を短縮するために使用されます。テンプレートをオフラインでインスタンス化するには、テンプレートおよび必要なデータをテープやCD-ROMなどのストレージ・メディアにパッケージ化します。そして、マスター・サイトではなく、テンプレートとデータが入ったストレージ・メディアからデータをプルします。

マルチマスターとマテリアライズド・ビューのハイブリッド構成

マルチマスター・レプリケーションとマテリアライズド・ビューは、様々なアプリケーションの要件を満たすようにハイブリッド(複合)構成として組み合せられます。ハイブリッド構成では、マスター・サイトの数に制限がなく、各マスターに複数のマテリアライズド・ビュー・サイトを対応付けられます。

たとえば、図1-4に示すように、2つのマスター間のマルチマスター(またはn-way)レプリケーションでは、2つの地域をサポートするデータベース間の全表レプリケーションをサポートできます。マテリアライズド・ビューをマスター上に定義すると、全表または表のサブセットを各地域内のサイトにレプリケートできます。

図1-4 ハイブリッド構成

マテリアライズド・ビューとレプリケート・マスター表との主な違いは次のとおりです。

- レプリケート・マスター表にはレプリケートされている表全体のデータが含まれている必要がありますが、マテリアライズド・ビューはマスター表のデータのサブセットをレプリケートできます。

- マルチマスター・レプリケーションを使用すると、変更が発生するたびに各トランザクションの変更内容をレプリケートできます。マテリアライズド・ビューのリフレッシュを使用すると、一定の間隔でバッチ処理されるため、マルチマスター・レプリケーションより少ない頻度で複数のトランザクションの内容をより効率的に伝播できます。

- 同一データの複数のコピーに変更が加えられることにより競合が発生する場合は、競合の検出と解消は常にマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで発生します。

スケジュール・リンク

マスター・サイトとマテリアライズド・ビュー・サイトは、スケジュール・リンクを使用して他のサイトにデータの変更を伝播します。スケジュール・リンクは、ユーザー定義スケジュールを使用して遅延トランザクションをプッシュするデータベース・リンクです。スケジュール・リンクによって、あるマスター・サイトから別のマスター・サイトへの遅延トランザクション・キューの伝播方法、あるいは、あるマテリアライズド・ビュー・サイトからそのマスター・サイトへの遅延トランザクション・キューの伝播方法が決定されます。スケジュール・リンクを作成すると、遅延トランザクション・キューをシステムの別のサイトにプッシュするジョブがローカル・ジョブ・キューに作成されます。

レプリケーション環境の管理ツール

レプリケーション環境を構成、管理および監視するために、いくつかのツールを使用できます。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでは、レプリケーション環境の管理に役立つ強力なGraphical User Interface(GUI)を利用でき、レプリケーション・マネージメントApplication Program Interface(API)では、使い慣れたAPIを使用してレプリケーション管理のためのカスタマイズ・スクリプトを作成できます。レプリケーション・カタログを使用して、レプリケーション環境に関する情報を管理することもできます。

Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェース

レプリケーション環境の構成と管理に利用できるように、Oracle Enterprise Managerには洗練されたアドバンスト・レプリケーション・インタフェースが用意されています。アドバンスト・レプリケーション・インタフェースを使用するには、Enterprise Managerの「データ移動」サブページへ移動します。アドバンスト・レプリケーション・インタフェースの詳細は、主にこのツールのオンライン・ヘルプを参照してください。図1-5は、Enterprise Managerのアドバンスト・レプリケーション・インタフェースを示しています。

図1-5 Enterprise Managerのアドバンスト・レプリケーション・インタフェース

関連項目:
Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのオンライン・ヘルプ

レプリケーション・マネージメントAPI

レプリケーション・マネージメントAPIは、アドバンスト・レプリケーション環境を構成する際に使用するプロシージャおよびファンクションをカプセル化したPL/SQLパッケージのセットです。レプリケーション・マネージメントAPIは、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの機能をコマンドラインで実行します。つまり、アドバンスト・レプリケーション・インタフェースは、レプリケーション・マネージメントAPIのプロシージャとファンクションを使用して処理を実行します。たとえば、アドバンスト・レプリケーション・インタフェースを使用してマスター・グループを作成するときに、このインタフェースでは、DBMS_REPCATパッケージ内のCREATE_MASTER_REPGROUPプロシージャをコールして作業を完了させます。レプリケーション・マネージメントAPIを使用すると、レプリケーション環境を管理するカスタム・スクリプトを簡単に作成できます。

関連項目:
レプリケーション・マネージメントAPIの使用方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

レプリケーション・カタログ

レプリケーション環境の各マスター・サイトおよびマテリアライズド・ビュー・サイトには、それぞれレプリケーション・カタログがあります。サイトのレプリケーション・カタログは、そのサイトのレプリケーション・オブジェクトとレプリケーション・グループに関する管理情報をメンテナンスしている、データ・ディクショナリの表およびビューの固有のセットです。レプリケーション環境に関係する各サーバーでは、そのレプリケーション・カタログの情報を使用して、レプリケーション・グループのオブジェクトのレプリケーションを自動化できます。

関連項目:
レプリケーション・カタログの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

分散スキーマ管理

レプリケーション環境では、すべてのDDL文は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはレプリケーション・マネージメントAPIのDBMS_REPCATパッケージを使用して発行する必要があります。具体的には、DBMS_REPCATパッケージを使用する場合、マスター・グループにオブジェクトを追加するためにCREATE_MASTER_REPOBJECTプロシージャ、レプリケート・オブジェクトを変更するためにALTER_MASTER_REPOBJECTプロシージャを使用します。EXECUTE_DDLプロシージャを使用することもできます。

アドバンスト・レプリケーション・インタフェースまたはDBMS_REPCATパッケージのいずれかを使用すると、レプリケーション環境に属するすべてのサイトにすべてのDDL文がレプリケートされます。レプリケート・オブジェクトの作成にエクスポート/インポートを使用できる場合もあります。

注意:
SQL*Plusなどのツールを使用して直接DDL文を発行すると、他のサイトにはレプリケートされません。

レプリケーションの競合

非同期のマルチマスター・レプリケーション環境および更新可能マテリアライズド・ビュー・レプリケーション環境では、たとえば異なるサイトから発行された2つのトランザクションがほぼ同時に同じ行を更新する場合などに発生するレプリケーション競合に対処する必要があります。データ競合が発生した場合は、ビジネス・ルールに従って競合を解消し、すべてのサイトを適正に収束するためのメカニズムが必要です。

アドバンスト・レプリケーションでは、レプリケート環境で発生したすべての競合がログに記録されるのみでなく、様々なビルトインの競合解消方法が用意されており、これらの方法を使用してデータベースの競合解消システムを定義すると、ビジネス・ルールに従って競合を解消できます。ビルトインの競合解消方法によって競合を解消できない場合は、独自の競合解消方法を作成して使用することもできます。

関連項目:

- データ競合が発生しないようにデータベースを設計する方法、および競合が発生した場合に使用する競合解消方法を作成する方法の詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

- Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して競合解消方法を構成する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

- レプリケーション・マネージメントAPIを使用して競合解消方法を作成する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

マルチマスター・レプリケーションのその他のオプション

マルチマスター・レプリケーションを実装する最も一般的な方法は非同期レプリケーションです。ただし、他にも同期レプリケーションとプロシージャ・レプリケーションの2つのオプションがあります。

同期レプリケーション

マルチマスター・レプリケーション環境では、非同期レプリケーションまたは同期レプリケーションを使用してデータをコピーできます。非同期レプリケーションを使用する場合、1つのマスター・サイトに加えられた変更は、一定時間後に関係するすべてのマスター・サイトに反映されます。同期レプリケーションの場合は、1つのマスター・サイトに加えられた変更は即時に、関係するすべてのマスター・サイトに反映されます。

同期レプリケーションを使用して表を更新すると、関係するすべてのマスター・サイトで更新内容が即時にレプリケートされます。つまり、それぞれのトランザクションはすべてのマスター・サイトと関連があります。したがって、なんらかの理由から1つのマスター・サイトでトランザクションを処理できなかった場合、そのトランザクションはすべてのマスター・サイトでロールバックされます。

同期レプリケーションを使用して競合の発生を回避できますが、処理を円滑に行うには非常に安定した環境が必要です。たとえば、ネットワーク上の問題により1つのマスター・サイトと通信できない場合、ユーザーがレプリケート表を問い合せることはできますが、通信が再び確立されるまではどのトランザクションも完了しません。また、同期レプリケーションをシミュレートするように非同期レプリケーションを構成することもできます。

関連項目:
非同期レプリケーション環境での同期レプリケーションのシミュレーション方法の詳細は、「連続的なプッシュのスケジューリング」を参照してください。

プロシージャ・レプリケーション

バッチ処理アプリケーションでは、1つのトランザクション内で大量のデータを変更できます。この場合、通常の行レベル・レプリケーションを実行すると、大量のデータ変更のためにネットワークの負荷が増大する可能性があります。このような問題を回避するために、レプリケーション環境で動作するバッチ処理アプリケーションでは、プロシージャ・レプリケーションを使用して、データ・レプリカを収集する簡単なストアド・プロシージャ・コールをレプリケートできます。プロシージャ・レプリケーションでは、アプリケーションが表の更新に使用するストアド・プロシージャのコールのみがレプリケートされます。データの変更自体はレプリケートされません。

プロシージャ・レプリケーションを使用するには、システムのデータを変更するパッケージをすべてのサイトにレプリケートする必要があります。パッケージをレプリケートした後に、各サイトでこのパッケージ用のラッパーを生成する必要があります。アプリケーションがデータを変更するパッケージ・プロシージャをローカル・サイトでコールすると、ラッパーにより、最終的にレプリケーション環境内の他のすべてのサイトで同じパッケージ・プロシージャがコールされます。プロシージャ・レプリケーションは、非同期または同期で実行できます。

競合の検出とプロシージャ・レプリケーション

プロシージャ・レプリケーションを使用してデータをレプリケートする場合、データをレプリケートするプロシージャにより、レプリケート・データの整合性が保証される必要があります。つまり、このようなプロシージャは、レプリケーションの競合を回避または検出し、競合を適切に解消するように設計する必要があります。したがって、プロシージャ・レプリケーションは、主に大規模バッチ操作によってのみデータベースを変更する場合に使用されます。このような状況では、多数のトランザクションが同じデータで競合することはないため、レプリケーションの競合はほとんど発生しません。

関連項目:
プロシージャ・レプリケーションの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

2 マスター・レプリケーションの概要とアーキテクチャ

この章では、シングル・マスター・レプリケーション環境およびマルチマスター・レプリケーション環境での、Oracleのマスター・レプリケーション・サイトの概念およびアーキテクチャについて説明します。

この章には、次の項が含まれます。

- マスター・レプリケーションの概念

- マスター・レプリケーションのアーキテクチャ

マスター・レプリケーションの概念

マスター・レプリケーションのアーキテクチャの詳細を理解するには、マスター・レプリケーションの概念について知っておく必要があります。マスター・レプリケーションの使用方法と目的がわかると、アーキテクチャの個々の要素がどのように相互に作用してマルチマスター・レプリケーション環境が作成されるのか理解が深まります。

この項には、次の項目が含まれます。

- マスター・レプリケーションについて

- マルチマスター・レプリケーションの使用目的

- マルチマスター・レプリケーション・プロセス

- 競合解消の概念

- オブジェクト型およびコレクションでのレプリケーションの動作方法

マスター・レプリケーションについて

Oracleには、シングル・マスター・レプリケーションとマルチマスター・レプリケーションという、2つのタイプのマスター・レプリケーションがあります。マルチマスター・レプリケーションは、複数のマスター・サイトを含んでおり、各マスター・サイトが同等ピアとして機能します。シングル・マスター・レプリケーションでは、マテリアライズド・ビュー・レプリケーションをサポートする1つのマスター・サイトが、数百、数千のマテリアライズド・ビュー・サイトをサポートします。また、1つ以上のマテリアライズド・ビュー・サイトをサポートする1つのマスター・サイトが、複数マスター・サイト環境の一部として含まれるハイブリッド・レプリケーション環境(マルチマスター・レプリケーションとマテリアライズド・ビュー・レプリケーションの組合せ)を構成することも可能です。

マテリアライズド・ビューは、マスター・サイトのマスター表またはマテリアライズド・ビュー・サイトのマテリアライズド・ビューのいずれかに基づきます。マテリアライズド・ビューがマテリアライズド・ビューに基づいている場合は、多重化マテリアライズド・ビュー環境が作成されます。このような環境では、他のマテリアライズド・ビューの基になるマテリアライズド・ビューがマスター・マテリアライズド・ビューと呼ばれます。

関連項目:
多重化マテリアライズド・ビューの詳細は、第3章「マテリアライズド・ビューの概要とアーキテクチャ」を参照してください。

マルチマスター・レプリケーション

マルチマスター・レプリケーション(peer-to-peerレプリケーションまたはn-wayレプリケーションとも呼ばれます)は、同等な複数のマスター・サイトから構成されており、どのマスター・サイトでも更新が可能です。個々のマスター・サイトに対する更新処理は、関係するすべてのマスター・サイトに伝播されます。図2-1は、マルチマスター・レプリケーション・システムを示します。

マルチマスター・レプリケーション環境でマスター・サイトとして機能しているOracle Databaseサーバーで、すべての表レプリカのデータが自動的に収束され、グローバルなトランザクション一貫性とデータ整合性が保証されます。競合解消は、各マスター・サイトで独自に行われます。マルチマスター・レプリケーションでは、各マスター・サイトのレプリケート表の完全なレプリカが提供されます。

ハイブリッド・レプリケーション環境(複数のマスター・サイトと各マスター・サイトがサポートする1つ以上のマテリアライズド・ビュー・サイトから構成される環境)の場合、ターゲット・マスター・サイトからマルチマスター・レプリケーション環境の他のすべてのマスター・サイトにマテリアライズド・ビューのすべての更新内容が伝播されます。次に、各マスター・サイトが、マテリアライズド・ビューのリフレッシュ時に変更をマテリアライズド・ビューに伝播します。

図2-1 マルチマスター・レプリケーション

シングル・マスター・レプリケーション

1つのマスター・サイトを、1つ以上のマテリアライズド・ビュー・サイトのターゲット・マスター・サイトとして機能させることもできます。マルチマスター・レプリケーションでは、1つのサイトに対して行った更新処理はその他のすべてのマスター・サイトに伝播されましたが、シングル・マスター・レプリケーションでは、マテリアライズド・ビューにより、更新がそのターゲット・マスター・サイトにのみ反映されます。

競合解消は、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでのみ処理されます。マテリアライズド・ビュー・レプリケーションには、レプリケート表の全部または一部のレプリカを含めることができます。

関連項目:
1つのマスター・サイトを使用するマテリアライズド・ビュー・レプリケーションの詳細は、第3章「マテリアライズド・ビューの概要とアーキテクチャ」を参照してください。

マスター・サイト

マスター・サイトは、マルチマスター・レプリケーション環境のノード、あるいはシングル・マスター・レプリケーション環境またはマルチマスター・レプリケーション環境の1つ以上のマテリアライズド・ビュー・サイトのマスター(あるいはその両方)として設定できます。レプリケート・オブジェクトはマスター・サイトに格納され、ユーザーがアクセスできます。

マスター定義サイト

マルチマスター・レプリケーション環境では、1つのマスター・サイトがマスター・グループのマスター定義サイトとして機能します。この特定のサイトで、マルチマスター・レプリケーション環境の管理作業やメンテナンス作業の多くが実行されます。

マスター定義サイトはマルチマスター環境のどのマスター・サイトでもかまいませんが、各マスター・グループ内に設定できるのは1つのみです。また、必要に応じて、マスター定義サイトを別のマスター・サイトに変更することもできます。

マテリアライズド・ビュー・レプリケーションをサポートするシングル・マスター・サイトは、デフォルトでマスター定義サイトになります。

マルチマスター・レプリケーションの使用目的

基本的に、レプリケーションを使用するのは、必要なときに必要な場所でデータを確実に使用するためです。次の項では、情報の配布要件が異なるいくつかの環境について説明します。使用するレプリケーション環境には、次のような要件が1つ以上ある可能性があります。

フェイルオーバー

マルチマスター・レプリケーションは、ミッション・クリティカルなデータベースの可用性を保護できます。たとえば、マルチマスター・レプリケーション環境では、システムまたはネットワーク障害が発生してプライマリ・サイトが使用できなくなった場合に備え、データベース内のデータをレプリケートしてフェイルオーバー・サイトを確立できます。このようなフェイルオーバー・サイトは、プライマリ・サイトが同時に稼働しているときでも、アプリケーションからアクセスできる完全に機能したデータベースとして機能します。

Oracle Netを使用すると、接続時に自動的に起動されるフェイルオーバーを構成でき、この機能により、最初のマスター・サイトに障害が発生した場合、Oracle Netは別のマスター・サイトに接続を切り替えることができます。自動的な接続時フェイルオーバーを構成するには、tnsnames.oraファイルでFAILOVER_MODEパラメータをonに設定し、複数の接続記述子を指定します。

関連項目:
接続時フェイルオーバーの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

ロード・バランシング

マルチマスター・レプリケーションは、次のような目的で複数ポイントのデータベース情報にアクセスすることが必要なトランザクション処理アプリケーションに役立ちます。

- 過度のアプリケーション負荷の分散

- 連続的な可用性の保証

- よりローカライズされたデータ・アクセスの提供

アプリケーション負荷を分散することが必要なアプリケーションとして一般的なものに、サービス指向のアプリケーションがあります。

図2-2 複数ポイントの更新アクセスをサポートするマルチマスター・レプリケーション

非接続マテリアライズド・ビュー環境のサポート

マテリアライズド・ビュー・レプリケーションを使用すると、ユーザーは、マスター・サイトに接続せずに、マスター・サイトからのレプリケート・データの全部またはサブセットをリモートで格納できます。たとえば、営業支援システムでは、個人のラップトップ(非接続デバイス)に個々の営業担当員に関連するデータのサブセットを格納します。

マスター・サイトは、マテリアライズド・ビュー環境のターゲットとして機能します。マスター・サイトのサポートには、次のものがあります。

- すべてのマテリアライズド・ビュー・サイトをサポートするシングル・マスター・サイト。競合解消がマスター・サイトまたは(多重化マテリアライズド・ビュー環境の)マスター・マテリアライズド・ビュー・サイトでのみ実行されるため、データの不一致が発生する確率が低下します。

- マルチマスター・レプリケーションとマテリアライズド・ビュー・レプリケーションの組合せで、マテリアライズド・ビューのグループがマルチマスター構成の様々なマスターをターゲットとします。この構成は、複数のマスター・ノードにまたがってネットワーク負荷を分散し、マスター・ノードのいずれかが使用不可になった場合に、スケーラビリティや可用性を向上させます。

Oracle Real Application Clustersとアドバンスト・レプリケーションとの比較

アドバンスト・レプリケーションとOracle Real Application Clusters (Oracle RAC)のどちらを使用するかを検討する必要があるのは、ロード・バランシングと耐障害性の面です。

- ロード・バランシング: アドバンスト・レプリケーションでは、複数のデータベースに対する読取りロード・バランシングが可能であり、Oracle RACでは、複数のインスタンスに対する読取りおよび書込みロード・バランシングが可能です。書込みはそれぞれ各レプリケーション・サイトで実行する必要があるため、レプリケーションでは書込みロード・バランシングは行われません。

- 耐障害性: アドバンスト・レプリケーションでは、各レプリケーション・サイトが地理的に異なる地域に置かれている可能性があるため、自然災害、停電またはサボタージュに対する耐障害性が高くなります。Oracle RACは、物理的に同一の環境にあるクラスタまたはその他の大規模パラレル・システム上で動作するため、アドバンスト・レプリケーションでは対処できる物理的問題に対する耐障害性はありません。

- 相互運用性: アドバンスト・レプリケーションは、Oracleが稼働している様々なプラットフォームおよびオペレーティング・システム間でデータをレプリケートできます。Oracle RAC環境内のインスタンスは、同一プラットフォーム上で実行する必要があります。

マルチマスター・レプリケーション・プロセス

マルチマスター・レプリケーションには、非同期と同期という2つのタイプがあります。

非同期レプリケーション(ストア/フォワード・レプリケーションとも呼ばれます)では、ローカルで加えられたすべての変更を取得してキューに格納し、一定の間隔でリモート・サイトに伝播して変更を適用します。この形式のレプリケーションでは、すべてのサイトでデータが収束するまでに一定の時間がかかります。

同期レプリケーション(リアルタイム・レプリケーションとも呼ばれます)では、1つのトランザクションの一部として、レプリケーション環境に関係するすべてのサイトで変更を適用し、レプリケート・プロシージャを実行します。いずれかのサイトでデータ操作言語(DML)文またはプロシージャが失敗すると、トランザクション全体がロールバックされます。同期レプリケーションを使用すると、各サイトのデータ整合性がリアルタイムで保証されます。

マスター・サイトの伝播モードは、非同期から同期に、または同期から非同期に変更できます。マスター・グループ内のマスター・サイトの伝播モードを変更した場合、すべてのマスター・グループ・オブジェクトに対してレプリケーション・サポートを再度生成する必要があります。レプリケーション・サポートを再生成すると、内部トリガーがアクティブ化され、内部パッケージが再生成されて、すべてのマスター・サイトにあるオブジェクトのレプリケーションがサポートされます。また、マルチマスター・レプリケーション環境では、同期レプリケーションおよび非同期レプリケーションの両方を混在させることも可能です。

関連項目:
詳細は、「複合モードのマルチマスター・システムについて」を参照してください。

非同期レプリケーション

非同期レプリケーションでは、DMLまたはレプリケート・プロシージャを実行すると、マルチマスター・レプリケーション環境のすべてのマスター・サイトに個別に伝播されます。各トランザクションにおいてデータが伝播されるのは、DMLまたはレプリケーション・プロシージャをローカルで実行した後です。

非同期レプリケーションがデフォルトのレプリケーション・モードです。非同期レプリケーションでは、同期レプリケーションの場合よりもネットワーク・リソースやハードウェア・リソースの使用を抑えることができるため、可用性およびパフォーマンスが高くなります。

ただし、非同期レプリケーションを使用すると、変更内容が伝播されるまでの一定時間、レプリケーション環境にある別のマスター・サイトのデータ・セットと一致しません。また、非同期レプリケーションでは、データの競合が発生する可能性もあります。

非同期レプリケーション・プロセスは次のとおりです。

1. DML文を発行または、レプリケート・プロシージャのラッパーを実行します。
表がレプリケーション用に設定された後、ユーザーがこの表に対してコミットしたDMLは、他のすべてのマスター・サイトへのレプリケーション用に取得されます。

挿入、更新または削除の対象となる各行に対して、内部トリガーによって遅延リモート・プロシージャ・コール(RPC)が作成され、遅延トランザクション・キューに入れられます。遅延トランザクション・キューには、すべての遅延RPCが入っています。

プロシージャがレプリケートされており、そのラッパーがマスター・サイトで実行されると、プロシージャ・コールが遅延トランザクション・キューに入れられます。

2. 遅延RPCを遅延トランザクション・キューに格納します。
遅延トランザクション・キュー内の各トランザクションには、遅延トランザクションの伝播先が定義されている接続先リストがあり、このリストには、発行元サイト以外の全マスター・サイトが記載されています。各サイトには遅延トランザクション・キューが1つあり、この1つのキューが複数のレプリケーション・グループにより使用されます。

3. 接続先へ遅延トランザクション・キューのエントリを送信します。
スケジュールした間隔で、または必要に応じて、遅延トランザクション・キュー内の遅延トランザクションがターゲットの接続先に伝播されます。接続先ごとにスケジュール間隔を変えられます。

4. 遅延トランザクション・キューのエントリがリモートの接続先で適用されます。
遅延トランザクションがターゲット宛先に伝播されているため、内部パッケージをコールすることによって各遅延RPCが宛先サイトで適用されます。遅延トランザクションを宛先サイトで正しく適用できない場合、宛先サイトのエラー・キューに再送および配置されます。ここでは、DBAがエラーの状態を修正し、遅延トランザクションを再度適用します。

遅延トランザクション・キューのエントリがリモートの接続先で適用されるときに、データ競合がないかがチェックされます。データ競合が検出された場合、その競合はリモートの接続先でログに記録され、オプションで競合解消方法が起動します。

5. 遅延トランザクションがすべてのリモート・マスター・サイトに正常にプッシュされた後、元のサイトではこのトランザクションが遅延トランザクション・キューからすぐにはパージされません。ユーザーが定義した間隔で実行されるパージ・ジョブにより、後でパージできます。

関連項目:
詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

同期レプリケーション

同期レプリケーションでは、1つのトランザクションが終了するまでの間に、ローカル・サイトで加えられた変更をレプリケーション環境内の同期リンクしたマスター・サイトに伝播します。いずれかのマスター・サイトで伝播に失敗した場合、ローカルのマスター・サイトで最初に加えられた変更を含め、トランザクション全体がロールバックされます。この厳しい規則により、レプリケーション環境全体のデータ整合性を保つことができます。非同期レプリケーションとは異なり、マスター・サイト間のデータが一致しない時間はありません。

関連項目:
1つの環境で同期レプリケーションと非同期レプリケーションを混在させる方法の詳細は、「複合モードのマルチマスター・システムについて」を参照してください。

同期レプリケーションでは、レプリケーション環境でデータ競合が発生しないことも保証されています。このようなメリットがある一方で、停止時間に関する制限が多いハードウェア・リソースやネットワーク・リソースを必要とするというデメリットもあります。たとえば、ノードが6つあるマルチマスター環境で、1つのマスター・サイトが使用できなくなった場合、どのマスター・サイトでもトランザクションは完了しません。

ただし、非同期レプリケーションでは、ダウンしたサイトが使用可能になるまで元のサイトで遅延トランザクションが保持されます。その間に、他のレプリケーション・サイトにはトランザクションが正常に伝播され適用されます。

また、同期レプリケーションを使用すると、問合せがローカルで実行されるため高パフォーマンスを維持できるのに対して、更新処理には時間がかかります。これは、すべての更新内容が正しく伝播され、リモートの接続先サイトへ正しく適用できるように、2フェーズ・コミット・プロトコルを使用しているためです。

関連項目:
2フェーズ・コミットの詳細は、『Oracle Database管理者ガイド』を参照してください。

同期レプリケーションは、次のように行われます。

1. DML文を発行または、レプリケート・プロシージャのラッパーを実行します。
表がレプリケーション用に設定された後、ターゲット表に対してユーザーがコミットしたDMLが、他のすべてのマスター・レプリケーション・サイトへのレプリケーション用に取得されます。

プロシージャがレプリケートされており、そのラッパーがマスター・サイトで実行されると、プロシージャ・コールがレプリケーション用に取得されます。

2. DMLまたはラッパーを実行すると即時に接続先のサイトに伝播されます。
内部トリガーは、DMLを取得し、これらのアクションを即時にレプリケーション環境の各マスター・サイトに伝播します。そして、これらのアクションをプロパゲータのデータベース・リンクのセキュリティ・コンテキストで適用し、内部RPCを使用して接続先サイトにこれらのアクションを適用します。

内部トリガーと同様に、レプリケート・プロシージャのラッパーは、レプリケーション環境の各マスター・サイトにプロシージャ・コールを即時に伝播します。

いずれかのマスター・レプリケーション・サイトでトランザクションが失敗した場合、すべてのマスター・サイトでトランザクションがロールバックされます。この方法により、すべてのマスター・サイト間でのデータ整合性が保証されます。トランザクションがいずれかのサイトで失敗するとロールバックを実行する必要があるので、同期レプリケーションは、可用性の高いネットワーク、データベースおよびそれに関連するハードウェアに大きく依存します。

競合解消の概念

表がレプリケートされるときに、任意のレプリケーション・サイト(マスター・サイトまたはマテリアライズド・ビュー・サイトのいずれか)のレプリケート表に適用されるDMLのうち、接続先サイトでデータ競合を発生させるDMLは、接続先サイトのOracleサーバーによって自動的に検出されます。マテリアライズド・ビュー・サイトで発生したデータ競合は、マテリアライズド・ビューのターゲット・マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで検出され、解消されます。

たとえば、次のマスター・グループが1時間に1回変更を伝播するようにスケジュールされていると仮定します。

時間

マスター・サイトA

マスター・サイトB

状態

8:00 AM

マスター・サイトBに変更を伝播

マスター・サイトAに変更を伝播

データの収束

8:15 AM

行1を更新

-

-

8:30 AM

-

行1を更新

-

9:00 AM

マスター・サイトBに変更を伝播

マスター・サイトAに変更を伝播

行1で競合検出

2つのデータ伝播の間の時間を伝播間隔とみなした場合、1つの間隔中に複数のサイトが同じ行を更新すると競合が発生します。

前述した更新の競合のみでなく、挿入および削除時にも競合が発生します。次のようなタイプの競合について考えてみます。各競合は、同じ間隔内に競合するアクションが起こると発生します。

競合タイプ

要約

更新の競合

DML文が他のサイトに伝播される前に、複数のDML文が複数のレプリケーション・サイトで同一行に適用される場合。

一意性競合

複数のサイトで挿入を実行した結果、各挿入の主キー(またはその他の一意の列のセット)に同じ値が存在する場合、またはあるサイトで更新を実行した結果、主キー(またはその他の一意の列のセット)が変更され、その主キーに別のサイトで挿入した値と同じ値が存在する場合。

削除の競合

あるサイトで行が削除され、別のサイトで同じ行に対して更新が行われる場合(この結果、存在しない行を更新しようとする可能性や、または複数のサイトで同じ間隔で同じ行を削除しようとする可能性があります)。

関連項目:
その他のタイプのデータ競合の詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

データ競合が検出されると、次のアクションが発生します。

1. 競合解消方法によって、データ競合の解消が試みられます。

2. 競合が解消されない場合は、接続先サイトのエラー・キューでデータ競合がログに記録されます。

エラー・キューにデータ競合がログされた場合、データベース管理者はデータ競合を手動で解消する必要があります。

オラクル社が提供する競合解消方法またはユーザー定義の競合解消方法を使用する場合、Oracleサーバーはデータ競合の自動的な解消を試みます。ユーザーが実装する競合解消方法は、レプリケーション環境で定義されているビジネス・ルールに準拠し、データ収束を保証する必要があります。実装する競合解消方法の要件に合うように、表の変更が必要になる可能性があります。たとえば、最新のタイムスタンプによる競合の解消方法では、実装対象の表にタイムスタンプ列が必要になります。

オブジェクト型およびコレクションでのレプリケーションの動作方法

Oracleのオブジェクト型はユーザー定義データ型で、これを使用すると現実の複雑なエンティティ(顧客や注文など)をデータベース内に単一エンティティ(オブジェクト)としてモデル化できます。オブジェクト型は、CREATE TYPE ... AS OBJECT文を使用して作成します。オブジェクト型とオブジェクトは、マルチマスター・レプリケーション環境のマスター・サイト間でレプリケートできます。

表の1列を占有するOracleオブジェクトを、列オブジェクトと呼びます。一般に、列オブジェクトが含まれている表にはその他の列も含まれており、このような列のデータ型は組込みデータ型(VARCHAR2やNUMBERなど)の場合があります。オブジェクト表とは、各行がオブジェクトを表す特殊な表です。オブジェクト表の各行は行オブジェクトです。

コレクションをレプリケートすることもできます。コレクションとは、VARRAYデータ型およびネストした表のデータ型に基づいたユーザー定義データ型です。VARRAYはCREATE TYPE ... AS VARRAY文を、ネストした表はCREATE TYPE ... AS TABLE文を使用して作成します。

注意:
アドバンスト・レプリケーションでは、型継承や型進化をサポートしていません。また、NOT FINAL句で作成された型はサポートしていません。レプリケート表またはレプリケートされたオブジェクト表の列がユーザー定義型に基づいている場合、ユーザー定義型を変更することはできません。

関連項目:
ユーザー定義型、列オブジェクト、オブジェクト表およびコレクションの詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。この項では、このマニュアルに記載されている基本的な情報を理解していることを前提としています。

レプリケーション・サイトでの型の一致

ユーザー定義型には、オブジェクト、ネストした表およびVARRAYを含み、CREATE TYPE文で作成された型がすべて含まれます。ユーザー定義型に基づいたスキーマ・オブジェクトをレプリケートするには、全レプリケーション・サイトに同一のユーザー定義型自体が存在する必要があります。

ユーザー定義型とそれに基づいたスキーマ・オブジェクトをレプリケートする場合は、次の条件が適用されます。

- 全レプリケーション・サイトで、オブジェクト識別子(OID)、スキーマ所有者およびレプリケートされるユーザー定義型のタイプ名が同一である必要があります。

- ユーザー定義型がオブジェクト型の場合は、全レプリケーション・サイトで、オブジェクト型の属性の順序とデータ型が一致する必要があります。属性の順序とデータ型は、オブジェクト型を作成するときに設定します。たとえば、次のようなオブジェクト型の場合を考えます。

CREATE TYPE cust_address_typ AS OBJECT
(street_address     VARCHAR2(40),
postal_code        VARCHAR2(10),
city               VARCHAR2(30),
state_province     VARCHAR2(10),
country_id         CHAR(2));
/

全レプリケーション・サイトで、street_addressはこの型の最初の属性でVARCHAR2(40)、postal_codeは2番目の属性でVARCHAR2(10)、cityは3番目の属性でVARCHAR2(30)、というようになっている必要があります。

- 全レプリケーション・サイトで、ユーザー定義型のハッシュコードが一致する必要があります。Oracleでは、ユーザー定義型が検査され、ハッシュコードが割り当てられます。この検査では、型の属性、属性の順序および型の名前が調べられます。複数の型についてこれらの項目がすべて同じである場合、型のハッシュコードは同じです。型のハッシュコードは、DBA_TYPE_VERSIONSデータ・ディクショナリ・ビューを問い合せて表示できます。

全レプリケーション・サイトでユーザー定義型を同一にするには、次のいずれかの方法でユーザー定義型を作成する必要があります。

- レプリケーション・マネージメントAPIの使用

- CREATE TYPE文の使用

- エクスポート/インポートの使用

レプリケーション・マネージメントAPIの使用

オラクル社では、ユーザー定義型を含むレプリケート・オブジェクトの作成、変更または削除には、レプリケーション・マネージメントAPIの使用をお薦めします。レプリケーション・マネージメントAPIを使用しないと、レプリケーション・エラーが発生することがあります。たとえば、前述の条件を満たすユーザー定義型をマスター・グループの全レプリケーション・サイトに追加する場合は、マスター定義サイトでその型を作成し、DBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用して、マスター・グループにその型を追加します。

関連項目:
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』

CREATE TYPE文の使用

型を作成するには、レプリケーション・サイトでCREATE TYPE文を使用できます。事前に全レプリケーション・サイトで型を作成し、これをレプリケーション・グループに追加するときに実行する必要がある場合があります。

この方法を選択する場合は、次のことを確認する必要があります。

- 全レプリケーション・サイトで型が同じスキーマ内にあること。

- 全レプリケーション・サイトで型の属性および順序が同一であること。

- 全レプリケーション・サイトで型の各属性のデータ型が同一であること。

- 全レプリケーション・サイトで型のオブジェクト識別子が同一であること。

型のオブジェクト識別子は、DBA_TYPESデータ・ディクショナリ・ビューを問い合せると検出できます。たとえば、cust_address_typのオブジェクト識別子(OID)を検出するには、次の問合せを入力します。

SELECT TYPE_OID FROM DBA_TYPES WHERE TYPE_NAME = 'CUST_ADDRESS_TYP';

TYPE_OID
--------------------------------
6F9BC33653681B7CE03400400B40A607

また、複数のレプリケーション・サイトに新しい型を作成する場合は、型の作成中に各サイトで同一のOIDを指定できます。この場合、次の問合せを実行すると、グローバルに一意のOIDを識別できます。

SELECT SYS_GUID() OID FROM DUAL;

型のOIDを認識した後、次の手順を実行して、型が存在していないレプリケーション・サイトで型を作成します。

1. 型を所有するユーザーとしてレプリケーション・サイトにログインします。レプリケーション・サイトにこのユーザーがない場合は、ユーザーを作成します。

2. CREATE TYPE文を発行し、OIDを指定します。

CREATE TYPE oe.cust_address_typ OID '6F9BC33653681B7CE03400400B40A607'
AS OBJECT (
street_address     VARCHAR2(40),
postal_code        VARCHAR2(10),
city               VARCHAR2(30),
state_province     VARCHAR2(10),
country_id         CHAR(2));
/

これで、レプリケーション・サイトで型を使用できます。

関連項目:
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』

エクスポート/インポートの使用

エクスポート・ユーティリティおよびインポート・ユーティリティを使用すると、レプリケーション・サイト間の型の一致を維持できます。ユーザー定義型に基づいたオブジェクト表またはユーザー定義型に基づいた列オブジェクトを含む表をエクスポートするとき、エクスポートを実行するユーザーにこれらの型に対するアクセス権がある場合は、ユーザー定義型も自動的にエクスポートされます。このような表を別のレプリケーション・サイトでインポートしたときのユーザー定義型は、エクスポートを実行したサイトと同一の型になります。

したがって、エクスポート/インポートを使用して新規レプリケーション・サイトで事前にレプリケーション表を作成しておき、これらの表をレプリケーション・グループに追加するときに「既存オブジェクトの使用」オプションを指定できます。この方法を使用すれば、レプリケーション・サイトで型が一致するようになります。

関連項目:
エクスポート/インポートの詳細は、『Oracle Databaseユーティリティ』を参照してください。

オブジェクト表とレプリケーション

オブジェクト表をレプリケートする場合は、次の条件が適用されます。

- 全レプリケーション・サイトでオブジェクト表のOIDを同じにする必要があります。

- 全レプリケーション・サイトでオブジェクト表の各行オブジェクトのOIDを同じにする必要があります。

この条件を満たすには、レプリケーション・マネージメントAPIを使用して、オブジェクト表をレプリケーション・グループに追加し、オブジェクト表を変更し、さらにレプリケーション・グループからオブジェクト表を削除します。たとえば、オブジェクト表をマスター・グループに追加するときにDBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用すると、この条件が満たされます。この条件を満たすために、エクスポート/インポートを使用してレプリケーション・サイトでオブジェクト表を事前に作成することもできます。

もう1つのオプションとしては、複数のレプリケーション・サイトでオブジェクト表を作成するときにオブジェクト表のOIDを指定する方法があります。このオプションを使用する場合は、次の手順を実行します。

1. DUALビューに対する問合せを実行し、グローバルに一意のOIDを求めます。

SELECT SYS_GUID() OID FROM DUAL;

OID
--------------------------------
81D98C325D4A45D0E03408002074B239

2. 各レプリケーション・サイトで、手順1で戻されたOIDを使用してcategories_tabオブジェクト表を作成します。

CREATE TABLE oe.categories_tab5 OF oe.category_typ
OID '81D98C325D4A45D0E03408002074B239'
(category_id PRIMARY KEY);

コレクション列を含む表

コレクション列とは、VARRAYデータ型およびネストした表のデータ型に基づいた列です。Oracleではコレクション列のレプリケーションをサポートしています。コレクション列を含む表をレプリケーション・グループに追加すると、コレクション列内のデータは自動的にレプリケートされます。コレクション列がVARRAYの場合、4KBより大きいVARRAYはBLOBとして格納されます。

コレクション列がネストした表の場合は、ネストした表の記憶表内の各行に対して行レベルのレプリケーションが実行されます。たとえば、記憶表の5つの行での変更により、5つの別々のリモート・プロシージャ・コール(RPC)が発生し、競合検出およびオプションの競合解消のフェーズが5つになります。記憶表は索引構成表として格納できます。

さらに、ネストした表を含む行に対するDMLにより、親表に対するRPCと、ネストした表の記憶表で影響を受ける各行に対するRPCがそれぞれ別々に発生します。Oracleでは、親表の作成中に整合性制約を明示的に指定しないかぎり、親表の行と記憶表の行との間の参照整合性検査は実行しません。競合をすべて検出するために、レプリケート表にはこのような制約を指定することをお薦めします。

ネストした表とその記憶表との間の競合が検出されるように、この2つの間には遅延可能な外部キー制約を定義することをお薦めします。遅延可能な外部キー制約がないと、競合により記憶表に行が挿入されアクセスできなくなることがあります。遅延可能な外部キー制約が定義してあると、このような場合はエラーが発生して競合が検出されます。制約を遅延させるには、SET CONSTRAINTS文のDEFERRED句を使用します。

次のアクションは、レプリケート表内のネストした表の記憶表に対して直接実行することはできません。

- レプリケーション・グループへの記憶表の追加

- 記憶表の変更

- 記憶表の削除

- 記憶表に対するレプリケーション・サポートの生成

これらのアクションは、記憶表の親表に対して実行するときに間接的に発生します。さらに、記憶表内の列のサブセットはレプリケートできません。

REF列を含む表

REFとはOracleの組込みデータ型で、オブジェクト表内の行オブジェクトを指す論理的なポインタです。有効範囲付きREFは、指定されたオブジェクト表に対する参照のみを含むREFで、有効範囲なしREFにはデータベース内のすべてのオブジェクト表に対する参照を含められます。有効範囲付きREFは、有効範囲なしREFと比べて必要とする記憶領域が少なく、より効率的なアクセスを提供します。Oracleでは、REF型の表のレプリケーションをサポートします。

有効範囲付きREF

有効範囲付きREFを含む表がレプリケートされ、REFにより参照されているオブジェクト表がレプリケートされない場合は、有効範囲付きREFを含む表をレプリケートする前に、参照されているオブジェクト表のないサイトに表を作成する必要があります。そうしないと、有効範囲付きREFにより、参照されているオブジェクト表が検出できないときに、この表のレプリケートによりエラーが発生します。このような場合は、通常、参照されているオブジェクト表もレプリケートすることが最善の方法で、レプリケートしないと、様々なレプリケーション・サイトでこの表の同期がなくなる可能性があります。

有効範囲なしREF

有効範囲なしREFを含む表がレプリケートされ、REFにより参照されているオブジェクト表がレプリケートされない場合、REFで参照オブジェクトが検出できない場合に、レプリケート・サイトで参照先がないREFが発生する可能性があります。レプリケートされたREFが有効になるには、参照されているオブジェクト表が各レプリケーション・サイトに存在する必要があります。

WITH ROWIDオプションを使用して作成されたREF

REF列にWITH ROWIDオプションを指定すると、REFで参照されている行オブジェクトの行IDのヒントがメンテナンスされます。REFに含まれている行IDを使用して、参照されているオブジェクトを直接検出できます(OID索引から行IDをフェッチする必要はありません)。WITH ROWIDオプションは、有効範囲付きREFに対してはサポートされていません。

WITH ROWIDオプションを使用して作成されたREFをレプリケートすると、REFが最初に作成または変更されたサイトを除き、各レプリケーション・サイトで行IDヒントが正しくなくなります。他のサイトではREFに含まれているROWID情報が無意味になります(行IDヒントは自動的には修正されません)。無効な行IDヒントは、パフォーマンス上の問題の原因になります。この場合は、ANALYZE TABLE文のVALIDATE STRUCTUREオプションを使用して、各レプリケーション・サイトの正しくない行IDヒントを判断できます。

関連項目:
ANALYZE TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

マスター・レプリケーションのアーキテクチャ

レプリケーション環境は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのオンライン・ヘルプおよび『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』で説明している手順や例に従えば作成できますが、レプリケーションのアーキテクチャを理解すると、レプリケーションをサポートするデータベース環境の設定、レプリケーション環境のチューニングやトラブルシューティングを、必要に応じて実施するための重要な情報が得られます。この項では、メカニズムとプロセスの観点からレプリケーションのアーキテクチャについて説明します。

この項には、次の項目が含まれます。

- マスター・サイトのメカニズム

- 管理メカニズム

- 編成メカニズム

- 伝播メカニズム

- パフォーマンス・メカニズム

- レプリケーションの保護メカニズム

- 競合解消メカニズム

マスター・サイトのメカニズム

Oracleでは、レプリケーション環境をサポートするために、マルチマスター・レプリケーション環境またはシングル・マスター・レプリケーション環境のいずれかに関係する各マスター・サイトで次のメカニズムを使用しています。これらのマスター・サイト・メカニズムの一部は、特定の環境でのみ必要となります。

マスター・サイトのロールおよびユーザー

セキュリティ要件によっては、管理、伝播および受信の3つのロールが1人のレプリケーション管理者に統合されている場合があります。実際、ほとんどのマルチマスター・レプリケーション環境では、1人のユーザーがレプリケーションの管理、伝播および受信のロールを実行します。セキュリティ要件がより厳格な場合は、次のロールを別々のユーザーに割り当てることができます。

注意:
このコンテキストのロールという用語は、SQL用語のロールとは関連がありません。レプリケーションにおけるロールは、PL/SQLのストアド・プロシージャまたは個々の権限(あるいはその両方)を使用して付与されます。

レプリケーション管理者

レプリケーション管理者は、レプリケーション環境のマスター・サイトに関連するすべての管理機能を実行します。一般的に、1つのレプリケーション環境に対して1人のレプリケーション管理者を置くことをお薦めします。レプリケーション管理者は、レプリケーションをサポートするようにデータベースを準備することに加えて次の作業を実行します。

- 個々のマスター・レプリケーション・グループの作成とメンテナンス

- 各マスター・サイトの追加と削除

- キューの管理

- レプリケーション環境の状態(通常および静止中)の制御

レプリケーション管理者のデフォルトのユーザー名はREPADMINですが、別のユーザー名を使用することもできます。

プロパゲータ

プロパゲータは、遅延トランザクション・キューに含まれる各トランザクションを接続先に伝播する作業を実行します。プロパゲータは、各データベースに1つ存在します。つまり、異なるスキーマを管理するために複数のレプリケーション管理者を置くことはできますが、それぞれのデータベースには1つのプロパゲータしか配置できません。

受信者

受信者は、プロパゲータから遅延トランザクションを受信し、それを適用します。受信者に遅延トランザクション内のコールを適用する適切な権限が付与されていない場合、遅延トランザクション全体が接続先のエラー・キューに入れられます。受信者を登録するには、DBMS_REPCAT_ADMINパッケージ内のREGISTER_USER_REPGROUPプロシージャを使用します。

データベース・リンクとレプリケーション

データベース・リンクは、マスター・サイトとマテリアライズド・ビュー・サイト間でデータをレプリケートするためのパイプ役になります。マルチマスター環境では、各マスター・サイトからその他の各マスター・サイトに対してデータベース・リンクが存在します。つまり、各マスター・サイトにつきN - 1個(Nはマスター・サイトの合計数)のデータベース・リンクが存在します。

図2-3 データベース・リンクを表す矢印

図2-3では、各マスター・サイトから他のマスター・サイトに対して2つ(N-1、すなわちこの例では3-1 = 2)のデータベース・リンクが存在します。この構成では、マルチマスター・レプリケーションに必要な両方向通信チャネルがマスター・サイト間で保証されます。マテリアライズド・ビュー・サイトの場合は、マテリアライズド・ビュー・サイトからマスター・サイトへのリンクのみが必要な点に注意してください。マスター・サイトからマテリアライズド・ビュー・サイトへのデータベース・リンクは不要です。

最も基本的なデータベース・リンクは、個々のマスター・サイトのレプリケーション管理者と、関係する他のマスター・サイトのレプリケーション管理者とを結ぶデータベース・リンクです。

ただし、通常はレプリケーション環境にデータベース・リンクのセットを追加します。レプリケーション管理者のデータベース・リンクを作成する前に、CONNECT TO句を指定せずに各マスター・サイト間にパブリック・データベース・リンクを作成します。パブリック・データベース・リンクは、リモート・データベースのサービス名を指定するUSING句を使用して各データベース・リンクのターゲットを指定します。

パブリック・データベース・リンクを作成した後で、レプリケーション管理者のプライベート・データベース・リンクを作成できます。プライベート・データベース・リンクの作成時はCONNECT TO句を指定しますが、対応付けられたパブリック・データベース・リンクにより、USING句の指定が不要になります。

パブリック・データベース・リンクとプライベート・データベース・リンクの両方を使用すると、データベース・リンクの管理に必要な労力が軽減されます。次の利点もあります。

- 複数のセットのプライベート・データベース・リンクで同じパブリック・データベース・リンクを共有でき、しかもデータベース・リンクの管理が簡単になります。

- データベース・リンクのターゲット・データベースを変更した一方で、ターゲット・データベースのサービス名がそのままの場合、変更する必要があるのはtnsnames.oraファイルのターゲット・データベースのエントリのみです。USING句により指定されるのはリモート・ターゲット・データベースのサービス名であることを覚えておいてください。ターゲットが同じプライベート・データベース・リンクはすべて、パブリック・データベース・リンクのUSING句で定義した接続先にリンクされます。
たとえば、データベースを別のサーバーに移動しても同じサービス名をそのまま使用する場合は、各レプリケーション・サイトでtnsnames.oraファイルのリモート・データベースのエントリを更新すれば、データベース・リンクを再作成する必要はありません。

前述のように、レプリケーション管理者は、通常、マルチマスター環境の管理作業および伝播作業を実行します。これらの作業を実行するのは1人のユーザーであるため、レプリケーション管理者用にプライベート・データベース・リンクを1セットのみ作成する必要があります。

ただし、レプリケーション管理者以外のユーザーが伝播を実行するマルチマスター・レプリケーション環境では、これらのユーザーのそれぞれに対して適切なプライベート・データベース・リンク・セットを作成する必要があります。

関連項目:

- データベース・リンクおよびその作成方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

- サービス名とtnsnames.oraファイルの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

アドバンスト・レプリケーション・インタフェースにより作成されたデータベース・リンク

Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのウィザードを使用してレプリケーション・サイトを設定すると、デフォルトでは、tnsnames.oraファイルまたはOracle Management Serverのサービス名の説明を含むUSING句を使用して、データベース・リンクが作成されます。

たとえば、tnsnames.oraファイルでサイトのエントリが次のように指定されているとします。

HQ.MYCOMPANY.COM =
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=server1)(PORT=1521))
(CONNECT_DATA=(SID=hqdb)(SERVER=DEDICATED)))

この場合、サービス名はHQ.MYCOMPANY.COMで、その説明は最初の等号の後に続くテキストです。次の文は、ウィザードにより作成されたHQ.MYCOMPANY.COMサイトへのデータベース・リンクの例を示します。

CREATE PUBLIC DATABASE LINK "HQ.MYCOMPANY.COM" USING
'(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=server1)(PORT=1521))
(CONNECT_DATA=(SID=hqdb)(SERVER=DEDICATED)))';

ウィザードはサービス名自体ではなくサービス名の説明を使用しますが、これは、tnsnames.oraファイル内の情報がサイトごとに異なる可能性があるためです。たとえば、ウィザードがサービス名のみを使用し、サービス名の説明を使用しなかった場合は、全サイトに同一サービス名が存在し、全サイトのtnsnames.oraファイル内の情報が同じであることをユーザーが確認する必要があります(アドバンスト・レプリケーション・インタフェースではこの要件をチェックできません)。

ウィザードは、サービス名の説明を使用することで、データベース・リンクが全レプリケーション・サイトで有効なことを保証します。このタイプのデータベース・リンクの弱点は、まれにデータベースのサービス名の説明が変更された場合に、データベース・リンクを削除して再作成が必要になることです。説明ではなくサービス名のみを使用してデータベース・リンクを作成した場合は、全サイトでtnsnames.oraファイルを変更してもデータベース・リンクをそのまま使用できます。

注意:
ウィザードのデフォルトの動作は、このウィザードのカスタマイズ画面を編集して上書きできます。

接続修飾子

接続修飾子を使用すると、同じリモート・データベースにリンクされている複数のデータベース・リンクに異なるパスを指定して接続を確立できます。たとえば、データベースnyでは、ny.example.comという名前の2つのパブリック・データベース・リンクに異なるパスを指定して、リモート・データベースに接続できます。

- ny.example.com@ethernet: イーサネット・リンクを使用してnyに接続するリンクです。

- ny.example.com@modem: モデム・リンクを使用してnyに接続する別のリンクです。

レプリケーションでは、接続修飾子の使用により、複数のマスター・グループの伝播特性をより厳密に制御できます。たとえば、各マスター・サイトに3つの別のマスター・グループがあり、接続修飾子を指定していないと想定した場合、遅延トランザクション・キューの伝播のスケジューリング特性はどのマスター・グループも同じです。この3つのマスター・グループのうち、1つのマスター・グループが遅延トランザクションを1時間に1回伝播し、残りの2つのマスター・グループが1日に1回伝播したとすると、コストが高くなる可能性があります。

接続修飾子をマスター・グループと対応付けると、遅延トランザクション・キューの伝播のスケジューリング特性を、前述のようなデータベース・レベルではなくマスター・グループ・レベルで個別に定義できます。

関連項目:
データベース・リンク用の接続修飾子の定義の詳細は、『Oracle Database管理者ガイド』を参照してください。

マスター・グループを作成するときに、そのグループに対応するすべてのスケジュール・リンクに1つの接続修飾子を使用するよう指定できます。ただし、マスター・グループに接続修飾子を使用すると、各マスター・サイトで接続修飾子を使用してデータベース・リンクを作成しないと情報が伝播されません。マスター・グループを作成した後は、グループの接続修飾子の削除、追加または変更はできません。

注意:
接続修飾されたリンクと複数のマスター・グループを使用するマルチマスター環境でのトランザクションの一貫性を保持するため、接続修飾子が異なる複数グループのレプリケーション・オブジェクトを、単一のトランザクションで操作することはできません。

注意:
接続修飾子を使用する場合は、すべてのマスター・サイトのOPEN_LINKS初期化パラメータの値を大きくすることが必要な場合があります。デフォルトでは、プロセスごとのオープン・リンク数は4つです。用途に応じて、必要な値を見積もります。OPEN_LINKSの詳細は、「初期化パラメータ」および『Oracle Databaseリファレンス』を参照してください。

レプリケーション・オブジェクト

レプリケーション環境の中で最も理解しやすいのは、レプリケート・オブジェクト自体です。レプリケート・オブジェクトの中では、レプリケート表がレプリケーション環境の基盤です。次の項では、関連するデータベース・オブジェクトのレプリケーションについて説明します。特に、次のタイプのデータベース・オブジェクトをレプリケートする場合の利点および制限事項を中心に説明します。

- 表

- 索引

- パッケージおよびその本体

- プロシージャおよびファンクション

- ユーザー定義型および型の本体

- トリガー

- ビュー、オブジェクト・ビューおよびシノニム

- 索引タイプ

- ユーザー定義演算子

表

ほとんどの場合、レプリケート表がレプリケーション環境の基盤です。レプリケーション用の表を選択し、レプリケーション・サポートを生成すると、表に対してDMLが適用されているかどうかを検出するために、内部トリガーによって監視が行われます。

関連項目:
「内部トリガー」

表をレプリケートするときは、表構造と表データをリモート・データ・サイトにレプリケートすることも、表構造のみをレプリケートすることもできます。また、同じ名前と構造の表がターゲットのレプリケーション・サイトにすでに存在する場合は、レプリケーション環境内の既存のオブジェクトを使用することもできます。

注意:

- 自己参照型整合性制約がある表では、正しい順序で削除が実行される保証はありません。このような表で削除を実行する場合は、プロシージャ・レプリケーションを使用します。詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- 循環依存性を持つ表または自己参照型制約のある表を含むマスター・グループに新規マスター・サイトを追加する場合は、新規マスター・サイトで表定義を再作成し、データを手動でロードする必要があります。循環依存性の例としては、「表Aには表Bに対する外部キー制約があり、表Bには表Aに対する外部キー制約がある」などがあります。

- レプリケート表からファンクション索引を削除する場合、またはレプリケート表にファンクション索引を追加する場合、表のレプリケーション・サポートを再生成する必要があります。

表のレプリケーションは、表データに加えられたすべての変更をレプリケーション環境に関係するすべてのサイトにレプリケートすることを目的としていますが、これ以外の用途もあります。

- オブジェクトおよびデータのトランスポート: オブジェクトがターゲットの接続先サイトにレプリケートされると、それ以降レプリケーション・サポートは自動的には生成されません。オブジェクトとデータのトランスポートにより、オブジェクトとデータをリモートの接続先に簡単に配布できます。レプリケーション・オブジェクトの削除およびレプリケーション・サポートの生成を行っていない場合は、表(またはその他のオブジェクト)およびデータはリモートの接続先サイトに残り、リモートの接続先サイトの変更は一切レプリケートされません。この方法により、標準のデータベース環境とデータ・セットを新しいデータベース環境に配布できます。

- オブジェクトのトランスポート: 同様に、データをコピーせずにターゲットの接続先サイトに表をレプリケートできます。この方法により、接続先サイトにオブジェクトが作成されますが、データは移入されません。したがって、空のデータベース環境を即時に配布できます。

関連項目:
「レプリケート表に関する考慮事項」

索引

レプリケーション用の表が選択され、リモート接続先サイトで作成されると、表内での制約の施行に使用する索引がリモート・サイトで自動的に作成されます。ただし、パフォーマンス上の理由から索引を使用する場合は、レプリケーション用の索引を明示的に選択して、レプリケーション環境に関係する他のマスター・サイトに作成する必要があります。索引が別のサイトにレプリケートされると、ローカルで作成されたかのように動作します。索引のレプリケーション・サポートを生成する必要はありません。

Oracleではドメイン索引のレプリケーションをサポートしています。ドメイン索引の記憶表の定義はレプリケートできますが、記憶表には通常はROWID情報が含まれているため、記憶表自体はレプリケートできません。

関連項目:

- 外部キー列に対する索引のレプリケーションの詳細は、「外部キーとレプリケート表」を参照してください。

- 拡張索引の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。

パッケージおよびその本体

レプリケーション用のパッケージとパッケージ本体を選択し、必要なレプリケーション・サポートを生成すると、プロシージャ・レプリケーションを実行できます。プロシージャ・レプリケーションを使用すると、レプリケーション環境でシリアルに実行されて大量の行を処理する、大規模なバッチ指向操作のパフォーマンスが向上します。

レプリケーション・サポートを使用するプロシージャのパラメータはすべて、INパラメータである必要があり、「レプリケート表のデータ型に関する考慮事項」で説明されているデータ型の要件を満たす必要があります。OUTモードおよびIN/OUTモードはサポートされていません。

レプリケート・プロシージャは、パッケージ内で宣言する必要があります。スタンドアロン・プロシージャにはレプリケーション・サポートはありません。

関連項目:
プロシージャ・レプリケーションの使用方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

注意:
「表」で説明した概念と同様に、レプリケーション・サポートを生成せずにレプリケーション用のパッケージおよびパッケージ本体を選択すると、このオブジェクトをリモート・サイトに簡単に配布できます。ただしその場合、パッケージに対するコールはレプリケートされません。

プロシージャおよびファンクション

パッケージの一部として宣言されていないプロシージャおよびファンクションは、レプリケーション・サポートされません。スタンドアロンのプロシージャとファンクションを使用してプロシージャ・レプリケーション環境を作成できませんが、レプリケーションを使用してこれらのスタンドアロンのプロシージャとファンクションをレプリケーション環境の各サイトに配布することはできます。スタンドアロンのプロシージャまたはファンクションがレプリケーションを使用してリモート・サイトで作成されると、作成されたオブジェクトはレプリケーション・サポートされず、ローカルで作成されたかのように動作します。

ユーザー定義型および型の本体

ユーザー定義型を含むスキーマ・オブジェクトをレプリケートするには、全レプリケーション・サイトに同一のユーザー定義型が存在する必要があります。

関連項目:
「オブジェクト型およびコレクションでのレプリケーションの動作方法」

トリガー

各マスター・サイトにアプリケーション・ロジックまたはデータベース・ロジックがあることを確認するために、レプリケーション用のトリガーを選択できます。トリガーのレプリケーションの重要な例として、DMLが表に適用されたときに表に自動的にタイムスタンプを挿入するトリガーのレプリケーションがあります。

トリガーが再起動されないようにするには、APIコールをトリガーに挿入して、トリガーがローカル・コールまたはリモート・コールによって起動されているかどうかを検出することが重要です。これにより、トリガーが行を更新して、その更新が別のマスターサイトに伝播されたときトリガー再起動の原因となる状況を回避できます。

次のコード例の5行目を見てください。

1) CREATE OR REPLACE TRIGGER hr.insert_time
2)    BEFORE
3)       INSERT OR UPDATE ON hr.employees FOR EACH ROW
4)    BEGIN
5)       IF DBMS_REPUTIL.FROM_REMOTE = FALSE THEN
6)          :NEW.TIMESTAMP := SYSDATE;
7)       END IF;
8)    END;
9) /

DBMS_REPUTIL.FROM_REMOTEファンクションによって挿入または更新がローカルで開始されたと判断されると、定義されているアクション(タイムスタンプ割当て)が実行されます。挿入または更新がリモート・サイトから開始されたと判断された場合は、タイムスタンプ値は割り当てられません。この例は、timestamp列がhr.employees表に追加されたことを前提としています。

関連項目:
レプリケート・トリガーの作成方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

ビュー、オブジェクト・ビューおよびシノニム

ビュー、オブジェクト・ビューまたはシノニムをレプリケーション環境に関係する他のマスター・サイトに配布するには、レプリケーションを使用します。オブジェクトが他のサイトにレプリケートされると、そのオブジェクトはローカルで作成されたかのように動作します。変更を取得するためにオブジェクトを監視する内部トリガーまたはパッケージはありません。ただし、オブジェクトはレプリケート・オブジェクトであるため、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはレプリケーション・マネージメントAPIを使用して削除または変更できます。

索引タイプ

Oracleでは索引タイプのレプリケーションをサポートしています。Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはDBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用して、索引タイプの実装に使用するタイプとタイプ本体のファンクションを明示的にレプリケートする必要があります。

関連項目:
拡張索引の詳細は、『Oracle Databaseデータ・カートリッジ開発者ガイド』を参照してください。

ユーザー定義演算子

オブジェクト指向アプリケーションの開発者は、ユーザー定義演算子と呼ばれるドメイン固有の演算子(Contains、Within_Distance、Similarなど)を使用して、組込みのリレーショナル演算子(+、-、/、*、LIKEなど)のリストを拡張できます。ユーザー定義演算子をレプリケーション環境に関係する他のマスター・サイトに配布するには、レプリケーションを使用します。オブジェクトが他のサイトにレプリケートされると、演算子はローカルで作成されたかのように動作します。変更を取得するためにオブジェクトを監視する内部トリガーまたはパッケージはありません。ただし、レプリケート・オブジェクトであるため、レプリケーション・マネージメントAPIを使用して削除または変更できます。

関連項目:
『Oracle Databaseデータ・カートリッジ開発者ガイド』

順序のレプリケーションの代替方法

異なるデータベースの2つの順序で同じ値が生成されることがあるため、順序のレプリケーションはサポートしていません。

順序のレプリケーションの代替方法が3つあり、これらの方法を使用すると、一意の値の生成と一意性のデータ競合が確実に回避されます。次のSELECT文を実行すれば、一意識別子を取り出せます。

SELECT SYS_GUID() OID FROM DUAL;

このSQL文は、グローバルに一意な16バイトの識別子を返します。この値は、タイムスタンプと日付スタンプおよびマシン識別子を使用してグローバルに一意な識別子を生成するアルゴリズムに基づいています。グローバルに一意な識別子は、次の形式で表示されます。

4595EF13AB785E73E03400400B40F58B

SYS_GUID()ファンクションを使用する第2の方法として、各マスター・サイトに順序を作成し、サイト名(またはその他のグローバルに一意な値)とローカルの順序を連結する方法があります。この方法は、順序の値の重複や、「競合解消の概念」で説明している挿入競合の発生を回避するのに役立ちます。

さらに、レプリケーション環境内で一意の値を生成するように各マスター・サイトで順序を作成する方法があります。これを実現するには、CREATE SEQUENCE文で開始値、増分値および最大値の組合せを使用します。たとえば、次のように設定すると想定します。

パラメータ

マスター・サイトA

マスター・サイトB

マスター・サイトC

START WITH

1

3

5

INCREMENT BY

10

10

10

範囲の例

1, 11, 21, 31, 41,...

3, 13, 23, 33, 43,...

5, 15, 25, 35, 45,...

同様の方法を使用して、各サイトに対して一意の範囲を生成するSTART WITHとMAXVALUEを指定することにより、各マスター・サイトごとに異なる範囲を定義できます。

内部トリガー

内部トリガーは、レプリケート・データの更新に関する情報の取得および格納に使用します。内部トリガーによって、ローカル・サイトで加えられたデータ変更をリモート・サイトで再生成するリモート・プロシージャ・コール(RPC)が作成されます。遅延RPCは、遅延トランザクション・キューに格納され、レプリケーション環境に関係する他のマスター・サイトに伝播されます。データ・レプリケーションをサポートする内部トリガーは、Oracleサーバー実行モジュール内の必須コンポーネントです。したがって、システム・リソースを最小限に使用して、レプリケート・データへの更新内容を高速に取得し、格納できます。

遅延トランザクション

前述の内部トリガーによって生成されるRPCを伝播(送信および実行)することにより、データ・レプリケーション情報が転送されます。このRPCは、遅延トランザクション・キューに格納されます。各RPCには、接続先サイトでの内部プロシージャの実行コマンドのみでなく、ターゲット・サイトにレプリケートされるデータも含まれています。Oracleでは分散トランザクション・プロトコルを使用しているため、グローバルなデータベース整合性が自動的に保護され、データの耐障害性が保証されます。

内部プロシージャ

内部トリガーによって作成された遅延RPCがレプリケーション環境に関係する他のマスター・サイトに伝播されると、遅延RPCは接続先サイトの内部プロシージャによってリモート・サイトで適用されます。この内部プロシージャは、表のレプリケーション・サポートを生成するときに自動的にアクティブ化されます。また、この内部プロシージャは、発行元サイトの遅延トランザクション・キューから受信されるRPCに基づいて実行されます。

キュー

次のキューは、アドバンスト・レプリケーションによって生成されるトランザクションを管理します。

遅延トランザクション・キュー

このキューには、マスター・グループ内の別の接続先に伝播されるトランザクション(たとえば、DML)が格納されます。遅延伝播用に、サイトの遅延トランザクション・キューの内部トリガーによって生成されるRPCが格納されます。また、トランザクションを構成するすべてのRPCがトランザクションとして伝播されてリモートで適用されるように、開始トランザクションに関する情報も記録されます。Oracleのレプリケーション機能では、Oracle Advanced Queuingのメカニズムを使用して遅延トランザクション・キューが実装されます。

注意:
ENABLE RESTRICTED SESSION句を指定したSQL文ALTER SYSTEMで制限付きセッションを使用可能にすると、遅延トランザクションは伝播されません。制限付きセッションが使用禁止になっている場合は、伝播されます。

エラー・キュー

このキューには、ローカル・サイトでの適用に失敗した遅延トランザクションに関する情報が格納されます。エラー・キューにはレプリケーション環境のその他の各マスター・サイトのエラー情報は表示されません。エラー状態が解消されると、トランザクションを再度実行するか、エラー・キューからトランザクションを削除できます。

ジョブ・キュー

伝播プロセスは、ジョブ・キュー・メカニズムおよび遅延トランザクションを使用して管理されます。各サーバーには、ローカル・ジョブ・キューがあります。サーバーのジョブ・キューは、ジョブの実行を要求するPL/SQLコールやジョブの実行時期など、ローカル・ジョブに関する情報を格納するデータベース表です。レプリケーション環境の一般的なジョブには、遅延トランザクションをリモートのマスター・サイトにプッシュするジョブ、遅延トランザクション・キューから適用済のトランザクションをパージするジョブおよびマテリアライズド・ビューのリフレッシュ・グループをリフレッシュするジョブがあります。

管理メカニズム

通常はレプリケーション環境をサポートする管理作業を処理するために、いくつかのメカニズムが必要です。このメカニズムを使用すると、レプリケーション環境をオンまたはオフにしたり、レプリケーション環境の作成時または変更時に生成される管理作業を監視できます。

レプリケーションの操作モード

レプリケーション環境の操作モードは3つあります。

通常

通常モードのレプリケーション環境では、レプリケーションを使用できます。レプリケーション環境はこのモードで実行されます。レプリケート・オブジェクトに対してトランザクションを実行でき、トランザクションは適切に伝播されます。

静止

静止モードは、レプリケーション環境が通常モードから静止中モードに移行する段階のモードです。レプリケーション環境の静止中は、ユーザーは、レプリケート・オブジェクトに対してトランザクションを実行できませんが、既存の遅延トランザクションは伝播されます。静止表に対する問合せはできます。各接続先へのすべての遅延トランザクションが正しく伝播終了すると、レプリケーション環境は静止中モードに変わります。

静止中

静止中レプリケーション環境は通常のレプリケーションの使用では無効とみなすことができ、主に(レプリケート・オブジェクトの追加や削除などの)管理目的で使用されます。このモードではレプリケーションは「停止」されます。静止状態では、ユーザーはレプリケーションをオフにしないかぎり、静止マスター・グループのレプリケート・オブジェクトに対するトランザクションの実行はできません。これによりレプリケーションの再開後にデータの不一致が発生する場合があります。トランザクションには、レプリケート表に対するDMLやレプリケート・プロシージャ用のラッパーの実行などがあります。マスター表が静止中の場合、これらのマスター表に基づくマテリアライズド・ビューは自身の変更をターゲット・マスター表に伝播できませんが、マテリアライズド・ビューへのローカルな変更は継続できます。

レプリケーション環境は、マスター・グループ・レベルで静止します。マスター・グループに含まれているすべてのマスター・サイトが影響を受けます。マスター・グループが静止中状態になると、遅延トランザクション・キューのトランザクションが他のマスター・サイトに正常に伝播されたか、エラー・キューに入れられたことを確認できます。ユーザーは静止中のマスター・グループに属する表に対しては、引き続き問合せを実行できます。

1つのマスター・グループを静止しても、その他のマスター・グループには影響しません。通常モードのマスター・グループでは、その他のマスター・グループの静止中も更新処理を継続できます。

レプリケーション・モードの制御

レプリケーションの3つの操作モードは、中断および再開の2つのメカニズムで制御されます(静止モードは通常モードから静止中モードへの移行段階のモードです)。

中断

中断メカニズムを実行すると、マスター・グループのレプリケーション操作モードが、通常から静止中への移行モードである静止モードになります。遅延トランザクション・キューに、マスター・グループへ未伝播の遅延トランザクションがないときは、レプリケーション環境は静止中モードに変わります。

中断メカニズムを実行できるのは、レプリケーション環境が通常モードの場合のみです。レプリケーション環境を変更する必要がある場合は、中断メカニズムを実行します。

再開

再開メカニズムによって、マスター・グループのレプリケーション操作モードが静止中モードから通常モードに変わります。レプリケーション環境で管理作業(たとえば、レプリケート・オブジェクトの追加)を実行していた場合は、再開メカニズムが実行される前に管理要求キュー(DBA_REPCATLOG)が空であることを確認する必要があります。

管理要求

レプリケーション環境を構成および管理するために、関係する各サーバーはOracleのレプリケーション・マネージメントAPIを使用します。サーバーのレプリケーション・マネージメントAPIは、レプリケーション機能を構成するために管理者が使用できるプロシージャおよびファンクションをカプセル化したPL/SQLパッケージのセットです。また、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでは、各サイトのレプリケーション・マネージメントAPIのプロシージャおよびファンクションを使用して作業を実行します。

管理要求とは、Oracleのレプリケーション・マネージメントAPIのプロシージャまたはファンクションをコールすることです。たとえば、Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマスター・グループを作成するときに、このインタフェースは、DBMS_REPCAT.CREATE_MASTER_REPGROUPプロシージャをコールして作業を実行します。管理要求には、追加のレプリケーション・マネージメントAPIコールを生成して要求を処理するものもあります。

管理要求のメカニズム

Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用するか、DBMS_REPCATパッケージのプロシージャをコールしてレプリケーション・システムを管理すると、内部メカニズムによって要求は同期ブロードキャストされます。なんらかの理由で同期でのブロードキャストが失敗した場合は、エラー・メッセージが戻され、それを含むトランザクションがロールバックされます。

Oracleサーバーが管理要求を受信すると、 DBA_REPCATLOGビューに要求が記録され、対応するDDL文がDBA_REPCATLOGビューの子表に記録されます。マスター・サイトのマスター・グループの管理要求を表示すると、別のマスター・サイトからのコールバックを待機している要求が含まれる場合があります。このような要求は、AWAIT_CALLBACK要求と呼ばれます。DBA_REPCATLOGビュー内の管理要求がすべて適用され、エラーがすべて解決されるまで、マスター・レプリケーション・アクティビティは再開できません。

Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してレプリケーション・グループの管理要求を作成する際、そのグループに対してジョブが存在しない場合は、ローカル・ジョブ・キューにジョブが自動的に挿入されます。このジョブは定期的にDBMS_REPCAT.DO_DEFERRED_REPCAT_ADMINプロシージャを実行します。要求を同期ブロードキャストすると、レプリケートされた変更を各マスター・サイトに適用するためにこのジョブが即時に開始されます。

エラーがない場合、バックグラウンド・プロセスがジョブ実行用に使用可能なときはDO_DEFERRED_REPCAT_ADMINが実行されます。バックグラウンド・プロセスの実行頻度は自動的に判断されます。未処理ジョブを実行するために十分な数のバックグラウンド・プロセスを使用できない場合、処理が遅れることがあります。

マスター・サイトでDO_DEFERRED_REPCAT_ADMINをコールするたびに、DBA_REPCATLOGビューがチェックされ、実行する必要のある要求があるかどうかが確認されます。管理要求が1つでも存在すると、要求が適用され、ローカル・ビューが適切に更新されます。このイベントは、各マスター・サイトで非同期に発生します。

DO_DEFERRED_REPCAT_ADMINは、所定の順序でローカルの管理要求を実行します。DO_DEFERRED_REPCAT_ADMINがマスター定義サイトではないマスター・サイトで実行される場合、可能な範囲で処理が実行されます。ただし、レプリケート表へのデータの移入などのいくつかの非同期アクティビティでは、マスター定義サイトとの通信が必要になります。通信が不可能な場合は、DO_DEFERRED_REPCAT_ADMINによって管理要求の実行が停止され、管理要求が順序を無視して実行されるのを防ぎます。マスター定義サイトで管理要求を更新または削除する最終ステップなど、マスター定義サイトとの通信の中には遅延可能なものもありますが、そのような通信によってDO_DEFERRED_REPCAT_ADMINによる追加の要求の実行が妨げられることはありません。

各マスター・サイトで管理要求が成功または失敗したことが、各サイトのDBA_REPCATLOGビューに記述されます。マスター・グループごとに、各管理要求に対応する状態がEnterprise Managerのアドバンスト・レプリケーション・インタフェースに表示されます。最後に、各マスター・サイトは、その管理要求の状態をマスター定義サイトに伝播します。マスター・サイトで要求が正常に完了した場合、マスター定義サイトのDBA_REPCATLOGビューからサイトのコールバックが削除されます。

すべてのサイトで要求が正常に完了した場合は、マスター定義サイトを含むすべてのサイトのDBA_REPCATLOGビューのエントリがすべて削除されます。マスター定義サイト以外のサイトで要求が失敗した場合は、マスター・サイトの要求が削除され、マスター定義サイト内の対応するAWAIT_CALLBACK要求がERRORステータスと失敗の理由で更新されます。

変更を同期でブロードキャストすることで、すべてのサイトで変更を確実に認識し、同期が取れた状態に保持できます。後の特定の時点でサイトに変更を適用でき、変更の適用に最も適した時点を自由に選択できます。

オブジェクトにレプリケーション・サポートが必要な場合、オブジェクトの変更後にレプリケーション・サポートを再生成する必要があります。Oracleでは、内部トリガーをアクティブ化し、パッケージを再生成して、すべてのマスター・サイトにある変更後のオブジェクトのレプリケーションをサポートしています。

注意:
エラーなしにこれらのプロシージャを完了させるにはDDLをマスター定義サイトで正常に適用する必要がありますが、これによって、DDLが各マスター・サイトで正常に適用されることが保証されるわけではありません。Enterprise Managerのアドバンスト・レプリケーション・インタフェースにより、すべての管理要求の状態が表示されます。また、DBA_REPCATLOGビューには、一時的な状態および要求によって生成される非同期のエラー・メッセージが含まれます。

DDL変更によって影響を受けるマテリアライズド・ビュー・サイトは、そのマテリアライズド・ビュー・サイトのリフレッシュを次に実行するときに更新されます。すべてのマスター・サイトが他のマスター・サイトと通信できるのに対して、マテリアライズド・ビュー・サイトが通信できるのは、対応付けられたマスター・サイトのみです。

マテリアライズド・ビューのマスターに変更を加えた結果、マテリアライズド・ビューの形式を変更する必要がある場合は、マテリアライズド・ビューを削除してから再作成します。

管理要求キュー

DBA_REPCATLOGビュー(通常、管理要求キューと呼ばれます)には、レプリケーション環境を管理および変更する管理要求が格納されます。一部のDBMS_REPCATプロシージャは、実行すると管理要求キューにリストされます。たとえば、既存のマスター・グループにレプリケート表を追加すると、DBMS_REPCAT.CREATE_MASTER_REPOBJECTプロシージャという要求が表示されます。

管理要求キューを表示するには、DBA_REPCATLOGビューを問い合せるか、Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「管理要求」ページを表示します。

各要求には、要求の状態を表すステータスがあります。状態は、次のとおりです。

- READY: READY状態は、要求を実行する準備が整っている状態を示します。管理要求キューを監視しているときに、ある要求がしばらくの間READY状態である場合、その要求の前にコールバック待機中の要求が存在している可能性があります。通常、READY状態の管理要求は、ジョブが要求を実行するのを待機しています。このような要求は、DBMS_REPCATパッケージ内のDO_DEFERRED_REPCAT_ADMINプロシージャを使用して手動で実行できます。

- AWAIT_CALLBACK: AWAIT_CALLBACK状態は、ある要求が別のサイトでの実行を待機中であり、かつその実行の確認を待機している状態を示します。要求がコールバックを受信すると、その要求は削除されるか、状態が変更されます。要求が正常に適用された場合はその要求キューから削除され、失敗した場合はそのステータスがERRORに変更されます。この状態は、マスター定義サイトでのみ発生します。

- ERROR: 要求を正常に実行できない場合、ERROR状態になります。エラー番号がERRNUM列に表示され、エラー・メッセージが管理要求キューの「メッセージ」列(Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用している場合は「管理要求」ページの「ステータス」フィールドの「エラー」)に表示されます。

注意:
要求がERROR状態にある場合は、エラー番号による説明に従ってエラー状態を解消し、要求を再送信してください。

- DO_CALLBACK: マスター・サイトの要求がDO_CALLBACK状態にある場合、要求が成功したか失敗したかどうかをマスター・サイトからマスター定義サイトに通知する必要があります。この状態は、マスター定義サイト以外のマスター・サイトでのみ発生します。

各マスター・サイトの管理要求キューには、そのマスター・サイトで実行される管理要求のみがリストされています。ただし、マスター・グループのマスター定義サイトには、各マスター・サイトで実行される管理要求がリストされています。DBAは、マスター定義サイトの管理要求キューを使用すると、レプリケーション環境のすべてのマスター・サイトの管理要求を監視できます。

注意:
ENABLE RESTRICTED SESSION句を指定したSQL文ALTER SYSTEMで制限付きセッションを使用可能にすると、管理要求は実行されません。制限付きセッションが使用禁止になっている場合は、実行されます。

編成メカニズム

Oracleでは、編成メカニズムを使用して前述のマスター・サイトを編成し、管理メカニズムを使用して個別のレプリケーション・グループを作成します。編成メカニズムの中で最も重要なのは、マスター・グループです。追加の編成メカニズムは、レプリケート表の競合解消に使用する列をグループ化するのに役立ちます。

マスター・グループ

レプリケーション環境では、レプリケーション・グループを使用してレプリケーション・オブジェクトを管理します。レプリケーション・グループは、常にトランザクションの一貫性を保つように更新されるレプリケーション・オブジェクトの集合です。

レプリケーション・グループ内に関連するデータベース・オブジェクトを編成すると、多数のオブジェクトをまとめて簡単に管理できます。通常、レプリケーション・グループを作成および使用して、特定のデータベース・アプリケーションのサポートに必要なスキーマ・オブジェクトを編成します。ただし、レプリケーション・グループとスキーマが相互に対応している必要はありません。レプリケーション・グループのオブジェクトは、複数のデータベース・スキーマから作成でき、スキーマには異なるレプリケーション・グループのメンバーであるオブジェクトを入れることができます。制限は、レプリケーション・オブジェクトが1つのグループのメンバーにしかなれないことです。

マルチマスター・レプリケーション環境では、レプリケーション・グループはマスター・グループと呼ばれます。異なるサイトの対応するマスター・グループには、レプリケーション・オブジェクトの同一のセットが含まれている必要があります(「レプリケーション・オブジェクト」を参照してください)。図2-4は、各マスター・サイトにレプリケート・オブジェクトの同一のレプリカが含まれているマスター・グループhr_mgを示します。

図2-4 すべてのサイトで同じレプリケーション・オブジェクトを含むマスター・グループhr_mg

マスター・サイトのマスター・グループ編成は、マテリアライズド・ビュー・サイトでのレプリケーション・オブジェクトの編成に不可欠です。

関連項目:
マテリアライズド・ビュー・サイトでの編成メカニズムの詳細は、「編成メカニズム」を参照してください。

また、各マスター・サイトに複数のレプリケーション・グループが含まれている例を図2-5に示します。各マスター・サイトの各グループに含まれているオブジェクトのセットは、同一であることが必要です。

図2-5 各マスター・サイトで同一のマスター・グループ

列グループ

列グループは、競合解消ルーチンと関係するすべての列をグループ化する編成メカニズムを提供します。グループのいずれかの列で競合が発生した場合、残りの列を使用して競合を解消できます。たとえば、表の列グループにmin_price、list_price、cost_priceおよびtimestampというフィールドが含まれており、list_priceフィールドで競合が発生した場合、タイムスタンプによる競合解消ルーチンを使用していたと想定すると、timestampフィールドを使用して競合を解消できます。

表のすべての列を1つの列グループにまとめる必要はありません。すべての列を1つの列グループにまとめれば設定や管理は簡単になりますが、レプリケート表のパフォーマンスが低下し、データ競合が発生する可能性が高くなることがあります。「パフォーマンス・メカニズム」で説明しているように、表の1つの列グループで競合が発生した場合、最小限の通信機能によって、表のその他の列グループからはデータが送信されません。したがって、すべての列を1つの列グループにまとめると、DBMS_REPCATパッケージ内のSEND_OLD_VALUESプロシージャおよびCOMPARE_OLD_VALUESプロシージャを使用しないかぎり、最小限の通信機能の利点がなくなってしまう可能性があります。

関連項目:
列グループの詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

伝播メカニズム

伝播は、レプリケーション環境のすべてのマスター・サイトにすべてのアクションを送信または配布するメカニズムであり、レプリケーションにおいて不可欠な要素です。

伝播のタイプ

内部トリガーはレプリケート表に適用されるすべてのDMLを取得するため、レプリケーション環境の他のマスター・サイトにDMLを伝播(送信)する必要があります。内部トリガーの詳細は、「内部トリガー」を参照してください。

アドバンスト・レプリケーションでは、非同期レプリケーションおよび同期レプリケーションの両方をサポートしています。

非同期

一般的なレプリケーション構成では、非同期データ・レプリケーションを使用します。非同期データ・レプリケーションは、アプリケーションで表のローカル・レプリカを更新し、レプリケーション情報をローカル・キューに格納し、その後で他のレプリケーション・サイトにレプリケーション情報を転送する場合に発生します。このため、非同期データ・レプリケーションはストア/フォワード・レプリケーションとも呼ばれます。

図2-6に示すように、Oracleでは内部トリガー、遅延トランザクション、遅延トランザクション・キューおよびジョブ・キューを使用して、更新可能マテリアライズド・ビューからマスター表に対する伝播の他、レプリケーション環境のマスター・サイト間でも、データレベルの変更を非同期に伝播します。

図2-6 非同期データ・レプリケーションのメカニズム

同期

Oracleでは、特定の要件を持つアプリケーションに対しては同期データ伝播もサポートしています。同期データ伝播は、アプリケーションによって表のローカル・レプリカが更新され、同じトランザクション内で同じ表の少なくとも1つの他のレプリカも更新されたときに発生します。したがって、同期データ・レプリケーションはリアルタイム・データ・レプリケーションとも呼ばれます。アプリケーションでレプリケート・サイトを継続的に同期化する必要があるとき以外は、同期レプリケーションを使用しないでください。

図2-7 同期データ・レプリケーションのメカニズム

図2-7に示すように、同じ内部トリガーを使用して、データレベルの変更をその他のレプリケーション・サイトに非同期にレプリケートして、行レベルの同期データ・レプリケーションをサポートするリモート・プロシージャ・コール(RPC)を生成します。ただし、このRPCの実行は延期されません。かわりに、データ・レプリケーションRPCは、ローカル・レプリカを変更する同一のトランザクションの境界内で実行されます。したがって、レプリケート表を管理する同期リンクされたすべてのサイトで、データレベルの変更が可能な必要があり、可能でない場合、トランザクションはロールバックされます。

同期データ伝播

図2-8に示すように、アプリケーションによってローカルのレプリケート表にDMLによる変更が加えられ、レプリケーション・グループで行レベルの同期レプリケーションを使用しているときは常に、変更内容は内部トリガーによってレプリケーション環境の他のマスター・サイトに同期伝播されます。アプリケーションでローカルな変更が適用されると、内部トリガーからリモート・マスター・サイトで生成されたプロシージャに対して、レプリケーション・プロパゲータのセキュリティ・コンテキストでコールが発行されます。障害が発生した場合は、すべての分散トランザクションがコミットまたはロールバックされます。

関連項目:
分散トランザクションの詳細は、『Oracle Database管理者ガイド』を参照してください。

図2-8 行レベルの同期レプリケーションを使用した変更の伝播

制限事項

2つの異なるサイトで同じ行が同時に更新されるときは、同期レプリケーションで使用されるロック・メカニズムにより、デッドロックが発生することがあります。アプリケーションでレプリケート表への同期更新が実行されると、まずローカル行がロックされ、次にAFTER ROWトリガーを使用して対応するリモート行がロックされます。各サイトでトランザクションがコミットされると、ロックは解放されます。

注意:
レプリケーション・データのリアルタイム伝播を使用するレプリケーション・システムは、システム内のすべてのサイトが同時に使用可能な場合にのみ機能するため、システムとネットワークの可用性に大きく依存します。

同期を取ってレプリケートされるトランザクションの接続先

同期レプリケーションのサポートに必要なリモート・プロシージャ・コールは、各オブジェクトの内部トリガーに組み込まれています。レプリケート・オブジェクトのレプリケーション・サポートを生成すると、すべてのマスター・サイトでトリガーがアクティブ化され、新しいサイトに必要なリモート・プロシージャ・コールが追加されます。反対に、マスター・グループからマスター・サイトを削除すると、内部トリガーからコールが削除されます。

競合の検出

マスター・グループのすべてのサイトが互いに同期通信している場合は、アプリケーションでレプリケーションの競合が発生することはありません。ただし、別のサイトに非同期で変更を送信するサイトが1つでもあると、レプリケーション環境のいずれかのサイトで競合が発生する可能性があります。

変更が同期伝播されている場合は、エラーが発生し、ロールバックが必要になります。変更内容が非同期で伝播されている場合は、競合が自動的に検出されてエラー・キューでログに記録されるか、適切な解消方法を指定している場合にはその競合が解消されます。

関連項目:
第5章「競合解消の概念およびアーキテクチャ」

複合モードのマルチマスター・システムについて

状況によっては、一部のマスター・サイトでマスター・グループの変更内容を非同期で伝播し、他のマスター・サイトでは同期伝播するような複合モード環境の設定が必要な場合があります。新規マスター・サイトをデータ伝播モードが異なるグループに追加するときは、その順番が重要となることがあります。

たとえば、A、BおよびCの3つのマスター・サイトがあると想定します。まずマスター定義サイトとしてサイトAを作成し、次に同期伝播モードでサイトBを追加した場合、サイトAからサイトBへも、サイトBからサイトAへも変更は同期を取って送信されます。どのサイトでも遅延トランザクションは作成されないため、どちらかのサイトでリンクをスケジュールする必要はありません。

次に、非同期伝播モードでマスター・サイトCを作成するとします。伝播モードは、図2-9に示すようになります。

図2-9 伝播モードの選択

次に、サイトAからサイトC、サイトBからサイトC、サイトCからサイトAおよびサイトBへの遅延トランザクション・キューの伝播をスケジュールする必要があります。

別の例として、サイトAをマスター定義サイトとして作成し、サイトCを非同期伝播モードで追加した後、サイトBを同期伝播モードで追加する場合を考えてみます。伝播モードは、図2-10に示すようになります。

図2-10 順序に関する考慮事項

複合モードのマルチマスター・システムに新規マスター・サイトを追加するときは、その追加が既存のサイトとのデータ伝播モードに与える影響を考慮してください。

伝播の開始

同期伝播を使用する場合、DMLが即時に伝播され、自動的に開始されます。非同期伝播を使用する場合は、2つの方法で遅延トランザクションを伝播できます。

- スケジュール・ジョブ: 通常、設定したスケジュール間隔に従って遅延トランザクションを自動的に伝播するには、スケジュール・ジョブを使用します。

- 手動による伝播: ストアド・プロシージャを実行したり、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、変更を手動で伝播することもできます。遅延トランザクションがジョブ・キューによって自動的に伝播されるまで待機しない場合は、遅延トランザクションを手動で伝播する必要があります。

パフォーマンス・メカニズム

他のエンタープライズ・データベース・ソリューションと同様に、データベース管理者にとってパフォーマンスは常に重要な課題です。アドバンスト・レプリケーションには、レプリケーション環境のパフォーマンスを高めるいくつかのメカニズムがあります。

パラレル伝播

パラレル伝播では、スループットを向上させるため、複数のパラレル伝送ストリームを使用してレプリケート・トランザクションを非同期で伝播します。必要に応じて依存トランザクションの実行が命令され、グローバルなデータベースの整合性が保証されます。

パラレル伝播では、使用可能なパラレル処理のプールが使用されます。これは、パラレル問合せ、パラレル・ロード、パラレル・リカバリなどの他のパラレル操作に使用されるプールと同じです。各サーバー・プロセスでは、シングル・ストリームを介してトランザクションが伝播されます。これらのサーバー・プロセスは、パラレル・コーディネータ・プロセスにより制御されます。コーディネータでは、トランザクション依存性を追跡しサーバー・プロセスに作業を割り当て、その進行状況を追跡します。

操作の実行中は、パラレル処理がサーバーのパラレル操作に対応付けられた状態になります。操作が完了すると、サーバー・プロセスは他のパラレル操作の処理に使用できます。たとえば、Oracle Databaseで接続先への遅延トランザクション・キューのパラレル・プッシュが実行されるときは、キューのプッシュに使用されるすべてのパラレル処理は、プッシュが完了するまで占有されます。

サーバー用のパラレル処理のプールを正しく構成するには、レプリケーション・システムの構成に関する問題を考慮する必要があります。

- シリアル伝播を使用するようにすべてのスケジュール・リンクを構成すると、レプリケーション・システムではパラレル処理は使用されません。したがって、レプリケーションを考慮して、パラレル処理のプールのサイズを調整する必要はありません。シリアル伝播は、通常、下位互換性が必要な場合にのみ使用します。

- 1つ以上のスケジュール・リンクをパラレル伝播を使用するように構成する場合、それぞれのリンクが変更を接続先にプッシュするために使用するパラレル処理の数を考慮する必要があります。さらに、別の操作によって使用されないように、各プッシュでパラレル・サーバーを保持する時間を考慮する必要があります。たとえば、遅延秒数値を大きくして連続的な伝播用にスケジュール・リンクを構成すると、接続先にトランザクションをプッシュするために使用するパラレル処理が保持されます。したがって、サーバーの他のパラレル操作で使用するプロセスを十分に確保するために、対応するデータベース・サーバーのパラレル処理の数を増やす必要があります。

パラレル問合せプロセスのデータベース・サーバーのプールを構成するには、次の初期化パラメータを使用します。

- PARALLEL_MAX_SERVERS

- PARALLEL_MIN_SERVERS

関連項目:

- 「初期化パラメータ」

- 『Oracle Databaseリファレンス』

パラレル伝播の実装

ほとんどのユーザーの場合、パラレル伝播パラメータ値を1に設定すると、十分なパフォーマンスが得られます。1に設定すると、シリアル伝播ではなく、前項で説明した最適化されたデータの交換方式が使用されます。ただし、一部のユーザーは、パラレル伝播値をさらにチューニングすることが必要な場合があります。

パラレル伝播値をさらにチューニングする場合、次の手順の実行をお薦めします。

1. パラレル伝播値を1に設定します。

2. 使用しているデータベース環境をテストし、伝播スループットを慎重に測定します。
パラレル伝播値が1でパフォーマンス目標が達成される場合は、パラレル伝播が実装されたことになるため、残りの手順を実行する必要はありません。

注意:
パラレル伝播値を大きくすると、パラレル伝播のパフォーマンスが向上する一方で、追加のパラレル処理のサポートに必要なリソースが増大します。

3. パラレル伝播値を1に設定した場合よりもスループットを向上させたい場合は、パラレル伝播値を2に設定します。

4. 使用しているデータベース環境をテストし、伝播スループットを慎重に測定します。

通常、伝播値を2に設定すると、伝播スループットは低下します。これは、依存トランザクションを使用可能なパラレル処理に割り当て、追加トランザクションを割り当てる前に必要なコミットを待機しているコーディネータに関連したラウンドトリップ遅延によるものです。

パラレル伝播値を4に設定して手順3と4を繰り返し、さらに、パラレル伝播値を8に設定して同じ手順を繰り返します。それでもスループットが改善されない場合は、使用している環境のトランザクションの相互依存性が非常に高いことが考えられます。パラレル伝播値を1に下げ、手順5に進んでください。

関連項目:
トランザクション依存性を下げるテクニックの詳細は、「パラレル伝播のチューニング」を参照してください。

パラレル伝播値を2、4または8のいずれかに設定することでパフォーマンスが向上した場合は、トランザクションの相互依存性は低いといえます。パラレル伝播値は9以上の値に設定してもかまいません。必ず使用している環境を完全にテストし、パラレル化が増大すれば、追加のパラレル処理のサポートに必要なリソースも増大することに注意してください。

5. テスト結果に基づき、使用している環境でパフォーマンスが最善になる値にパラレル伝播を設定します。

パラレル伝播のチューニング

パラレル伝播のパフォーマンス上の利点を最大限に活用するには、作成する依存トランザクションの数を減らします。トランザクションは、依存関係にあるすべてのトランザクションがコミットされるまで開始できません。

依存トランザクションの数を減らすには、次のようにします。

- 可能であれば、トランザクションを小さくします(つまり、自律性を損なわない範囲で、コミットの回数を増やします)。

- 挿入を受け取る各表の空きリスト数を増やします。

- ホットスポット(頻繁に修正される行。同じ行がアクセスされると、それらのトランザクションはシリアライズされます)は避けるようにします。たとえば、行のカウンタを使用するかわりにOracle順序を使用して、それを「手動で」インクリメントします。

- 行レベルの依存性の追跡を行うようにします。

関連項目:
「パラレル化を改善するための行レベルでの依存性の追跡の使用」

最小限の通信

行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。デフォルトでは、レプリケート表内の変更された各行の競合を検出するために通信する必要があるデータの量を最小化します。具体的には、次の値が伝播されます。

- 主キー値および変更された各列グループの各列の古い値(変更前の値)

- それぞれの更新された列の新しい値

注意:

- 挿入された行には古い値はありません。また、削除された行には新しい値はありません。

- DBMS_REPCATパッケージのCREATE_MVIEW_REPOBJECTおよびGENERATE_REPLICATION_SUPPORTプロシージャを実行するときに、min_communicationパラメータにデフォルト値のTRUEを設定し、レプリケーション環境が最小限の通信を使用するようにします。

遅延秒数

パフォーマンスに直接かかわるメカニズムではありませんが、delay_secondsパラメータ値を適切に設定すると、遅延トランザクションの伝播のタイミングをより詳細に制御できます。

遅延トランザクションをプッシュする場合は、SCHEDULE_PUSHプロシージャまたはPUSHファンクションにdelay_secondsパラメータを設定します。遅延トランザクションをパージする場合は、SCHEDULE_PURGEプロシージャまたはPURGEファンクションにdelay_secondsパラメータを設定します。これらのプロシージャとファンクションは、DBMS_DEFER_SYSパッケージにあります。

delay_secondsパラメータは、ジョブが遅延トランザクション・キューを認識し続ける時間を制御します。delay_secondsパラメータ値を最大限に活用した2つの例を次に示します。

delay_seconds = 0(デフォルト)

間隔を60分に設定したスケジュール・ジョブが午後2時30分に起動され、遅延トランザクション・キューをチェックする場合、既存の遅延トランザクションはすべて伝播されます。伝播には2分かかるので、ジョブが完了するのは午後2時32分です。

遅延トランザクションが午後2時34分にキューに入れられた場合、ジョブが完了しているためこの遅延トランザクションは伝播されません。このシナリオでは、遅延トランザクションは午後3時30分に伝播されます。

delay_seconds = 300

間隔を60分に設定したスケジュール・ジョブが午後2時30分に起動され、遅延トランザクション・キューをチェックする場合、既存の遅延トランザクションはすべて伝播されます。伝播には2分かかるので、ジョブが完了するのは午後2時32分です。

遅延トランザクションが午後2時34分にキューに入れられた場合、既存の遅延トランザクションの伝播完了後も300秒間(5分間)はジョブによって遅延トランザクション・キューが認識されるので、この遅延トランザクションは伝播されます。このシナリオでは、この遅延トランザクションは午後2時34分に伝播されます。

さらに頻繁にジョブが実行されるように設定できないかという疑問が生じます。ジョブを開始および停止すると、ジョブを開始して一定時間認識し続けるよりもはるかに大きいオーバーヘッドが発生します。delay_secondsパラメータ値を使用すると、ジョブの開始および停止に伴うオーバーヘッドを削減できるだけでなく、スケジュール・ジョブのサポートに必要なREDOロギングの量を減らすことができます。

パフォーマンスにかかわるほとんどの機能と同様に、デメリットもあります。次の理由により、delay_secondsパラメータの長さは常にチェックするようにします。

- パラレル伝播: 遅延トランザクション・キューをプッシュするときに使用する各パラレル処理は、その伝播ジョブが完了するまでその他のパラレル・アクティビティでは使用できません。長いdelay_seconds値を定義すると、他の操作がパラレル処理を使用できなくなる可能性があります。パラレル伝播を使用するには、SCHEDULE_PUSHプロシージャまたはPUSHファンクションのparallelismパラメータを1以上に設定します。

- シリアル伝播: (パラレル伝播ではなく)シリアル伝播しか使用しない場合、delay_seconds値を設定するとオープン・セッションが遅延時間中スリープするため、この値を設定しても前述のようなメリットはありません。シリアル伝播を使用するには、SCHEDULE_PUSHプロシージャまたはPUSHファンクションのparallelismパラメータを0(ゼロ)に設定します。

- 精度パージ: DBMS_DEFER_SYS.PURGEプロシージャを使用しているときにpurge_method_preciseメソッドを指定し、delay_seconds値に大きい値を定義した場合、指定したパージの実行時にパフォーマンスが低下する可能性があります。purge_method_preciseは別の選択肢(purge_method_quick)よりもコストがかかりますが、遅延トランザクションとプロシージャ・コールは、正常にプッシュされた後で確実にパージされます。

delay_secondsパラメータに20分(パラメータ設定では1200秒)を超える値を設定しても、通常はメリットはありません。

さらに、parallelismパラメータを0に設定してシリアル伝播を使用している場合は、delay_seconds値はあまり大きくは設定しません。パラレル伝播と異なり、シリアル伝播ではdelay_seconds値の時間が経過した後にのみキューがチェックされます。シリアル伝播を使用し、delay_secondsを20分に設定した場合は、スケジュール・ジョブが20分間すべてスリープし、その間に遅延トランザクション・キューに入れられた遅延トランザクションは、20分経過するまでプッシュされません。したがって、シリアル伝播を使用する場合は、delay_seconds値を60秒以下に設定するようにします。

パラレル伝播値を20分に設定する場合、パラレル・プッシュによって1分に1回チェックされます。リソースを20分間ロックしておいてもかまわない場合は、20分間という比較的長いdelay_seconds値が使用環境で最も効率的といえます。リソースを20分間ロックできない場合は、delay_seconds値を10秒または20秒に設定することを考えます。1200秒に設定した場合よりもジョブの実行回数を多くする必要がありますが、delay_seconds機能を利用するメリットは残ります(デフォルトの0秒に設定した場合と比較した場合)。

レプリケーションの保護メカニズム

マルチマスター・レプリケーション環境では、障害の発生時でも、リモート・サイトに伝播されたトランザクションは消失されず、再伝播されないことが保証されています。トランザクションは次の方法で保護されます。

- 1つのローカル・トランザクション内で発行された複数のプロシージャ・コールは、1つのトランザクションとしてリモートで実行されます。

- 伝播の実行中にネットワークまたはリモート・データベースに障害が発生した場合、トランザクションはリモート・サイトでロールバックされ、リモート・データベースが再度アクセス可能になって伝播が正常に完了するまで、レプリケーション元のサイトのローカル・キューに残ります。

- トランザクションがローカル・サイトのキューから削除されるのは、すべての接続先サイトへの伝播および適用が正常に完了してからです。トランザクションがすべての接続先サイトに正常に伝播された後でも、パージ・ジョブによって削除されるまで、トランザクションはキューに残ります。

パラレル伝播の場合は、パラレル操作用に最適化された特殊な分散トランザクション・プロトコルが使用されます。リモート・サイトは、正常に伝播されたトランザクションを記録し、この情報が要求されたときに情報をローカル・サイトに戻します。ローカル・サイトは、この情報を記録し、すべての接続先サイトに伝播されたエントリをローカル・キューからパージします。障害が発生した場合、ローカル・サイトは、適切な時点から伝播を続行できるように、正常に伝播されたトランザクションに関する情報をリモート・サイトに要求します。

注意:
伝播が正常に完了しても、必ずしもトランザクションがリモート・サイトで正常に適用されるとはかぎりません。解消不能な競合や記憶領域不足などのエラーが発生すると、トランザクションでエラーが発生することがあり、そのエラーはエラー・トランザクションとしてリモート・サイトのログに記録されます。

関連項目:

- 「パラレル伝播」

- Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用したエラー・トランザクションの表示および管理の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

データ伝播の依存性の維持

Oracleは、レプリケート・トランザクションがリモート・サイトに伝播されたときの依存性の順序を維持します。たとえば、次のようなトランザクションがあったとします。

1. トランザクションAが受注を取り消します。

2. トランザクションBが取消しを検出して返金を処理します。

トランザクションBは、ローカル・システムでの受注の取消し(トランザクションA)のコミット済の更新を参照するので、トランザクションBはトランザクションAに依存しています。

トランザクションA(受注の取消し)が正常に伝播された後で、トランザクションB(返金)が伝播されます。取消しの適用後に返金を処理する更新が適用されます。

パラレル伝播の依存性の追跡

ローカル・システムで新規トランザクションが実行されるときは、次の処理が実行されます。

1. Oracleは、新しいトランザクションにより見られるデータを依存SCNとして更新する最新のトランザクションのシステム変更番号(SCN)を記録します。SCNは、この章の後半で説明するように、データ・ブロック・レベルまたは行レベルで記録できます。

2. 依存SCN以下のSCNを持つトランザクションが、リモート・システムに正常に伝播されるようにします。

3. 待機中の依存トランザクションが伝播されます。

注意:
トランザクション間で依存関係の可能性がないときは、トランザクションはパラレルで伝播されます。

パラレル伝播は、シリアル伝播とは異なる方法でデータ整合性を保持します。シリアル伝播では、依存性を維持するために、ローカル・システム上でコミットするときと同じ順序ですべてのトランザクションが適用されます。パラレル伝播では、依存性を追跡し、依存性があるときはコミットされた順に実行し、依存性がないときはパラレルで実行します。シリアル伝播でもパラレル伝播でも、トランザクション内の実行順序は保持されます。遅延トランザクションは、各サイトで、ローカル・トランザクション内で実行された順序と同じ順序で、リモート・プロシージャ・コールを実行します。

注意:
シングル・コーディネータ・プロセスは、リモート・サイトに対する各データベース・リンクに存在しています。同じリモート・サイトに対する各データベース・リンクには、異なる接続修飾子が必要です。

関連項目:
「接続修飾子」

パラレル化を改善するための行レベルでの依存性の追跡の使用

表を作成するときは、システム変更番号(SCN)を追跡するために次のオプションを指定できます。

- NOROWDEPENDENCIES。SCNがデータ・ブロック・レベルで追跡されることを指定します(デフォルト)。

- ROWDEPENDENCIES。SCNが表の各行に対して追跡されることを指定します。

表にNOROWDEPENDENCIES句を使用すると、データ・ブロックSCNはデータ・ブロックに格納されている行の最新の更新を追跡します。その前に更新されている他の行は、同じデータ・ブロックに格納されている可能性がありますが、これらの行がいつ更新されたかを示す情報は、新規SCNがデータ・ブロック・レベルで適用されたときに失われます。

表にROWDEPENDENCIES句を使用すると、1つのデータ・ブロックに複数のSCNを格納できます。つまり、1つのSCNがデータ・ブロック内に格納されている行のそれぞれに対する変更を追跡します。同一データ・ブロックに格納されている2つの行が別々のトランザクションにより変更された場合、行のそれぞれにはこの変更を追跡するSCNがあります。SCNを行レベルで追跡するには、表の各行が6バイトの記憶領域を追加使用します。

表にROWDEPENDENCIES句を使用するとパラレル伝播が使用可能になり、遅延トランザクション・キューの適用時に、より効率良く依存性を追跡して変更に順序を付けられます。効率が上がることによりパフォーマンスが向上し、レプリケーション環境でのスケーラビリティが高まります。

次の問合せを使用すると、現在ROWDEPENDENCIES句を使用している表をリストできます。

SELECT OWNER, TABLE_NAME FROM DBA_TABLES
WHERE DEPENDENCIES = 'ENABLED';

関連項目:
ROWDEPENDENCIES句を使用した表の作成方法の詳細は、「行レベルでの依存性の追跡」を参照してください。

パラレル化を改善するためのトランザクション依存性の最小化

レプリケート表のいくつかでROWDEPENDENCIES句を使用していない場合は、トランザクション依存性を最小化することで、これらの表のパラレル伝播のパフォーマンスを改善できます。

この場合、アプリケーション条件によっては、トランザクション間に依存関係を確立して、遅延トランザクションの伝播を強制的にシリアライズできます。複数の非関連トランザクションによってレプリケート表内の同じデータ・ブロックが変更される場合、対応するトランザクションはリモート接続先へシリアル伝播されます。

データ・ブロック・レベルで作成されたトランザクション依存性を最小化するには、データ・ブロックの変更が1つまたは少数のデータ・ブロックに集中することを回避します。たとえば、レプリケート表にINSERTアクティビティが頻繁に発生する場合は、表の空きリストを複数作成することで、新しい行の記憶域を複数のデータ・ブロックに分散できます。

多数のトランザクションすべてが同一の小さい表を更新する状態は、できるだけ避けてください。たとえば、複数のトランザクションが1つの小さい表に読取りと更新を行い、主キーの順序番号生成をシミュレートするのは、望ましいアプリケーション設計とはいえません。このように設計すると、すべてのトランザクションが同じデータ・ブロックを更新します。より優れたソリューションは、順序を作成し順序番号をキャッシュに格納することで、主キーの生成を最適化し、パラレル伝播のパフォーマンスを改善できます。

競合解消メカニズム

レプリケーション環境の受信マスター・サイトでは、次のような更新の競合、一意性競合および削除の競合が検出されます。

- 主キー列または更新された列グループの列のいずれかで、レプリケート行の古い値(変更前の値)と受信サイトの同じ行の現在の値が異なる場合、受信サイトで更新の競合が検出されます。

- レプリケート行のINSERTまたはUPDATEの実行中に一意制約違反が発生した場合、受信サイトで一意性競合が検出されます。

- 行の主キーが存在しないために受信サイトでUPDATE文またはDELETE文の対象の行が見つからない場合、受信サイトで削除の競合が検出されます。

注意:
行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。パフォーマンスを最大にするには、更新の競合の検出および解消サポートに使用するデータの量をチューニングします。詳細は、「古い値の送信および比較」を参照してください。

競合検出時の行の識別

レプリケーションの競合を正確に検出するには、データ・レプリケーション時に別々のサイトの対応する行を一意に識別し、一致させる必要があります。通常、Oracleのレプリケーション機能では、表の主キーを使用して表内の行を一意に識別します。表に主キーがない場合は、(データ・レプリケーション時に表内の行を一意に識別するために使用する列または列のセットである)代替キーを指定する必要があります。

注意:
アプリケーションで表の主キーまたは代替キーを更新しないようにしてください。これにより、行を識別し、レプリケート・データの整合性を保つことができます。

上書きによる競合解消方法

Oracleには、データ競合が検出されたときに競合解消方法を定義するメカニズムがあります。ビルトインの競合解消方法は次のとおりです。

- 最新のタイムスタンプおよび最も古いタイムスタンプ

- 上書きおよび廃棄

- 最大値および最小値

- 加算および平均

- タイムスタンプ

- 優先グループ

- サイト優先順位

ビルトインの競合解消方法ではレプリケーション環境のニーズが満たされない場合、PL/SQLを使用して独自の競合解消方法を作成し、ユーザー定義の競合解消方法として実装できます。競合解消の仕組みの詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

関連項目:
Oracle Enterprise Managerを使用した競合解消の実装方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを、レプリケーション・マネージメントAPIを使用した競合解消の実装方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

3 マテリアライズド・ビューの概要とアーキテクチャ

この章では、マテリアライズド・ビューの概念およびアーキテクチャについて説明します。

この章には、次の項が含まれます。

- マテリアライズド・ビューの概要

- マテリアライズド・ビューのアーキテクチャ

マテリアライズド・ビューの概要

Oracleでは、マテリアライズド・ビュー(以前はスナップショットと呼ばれていたもの)を使用して、レプリケーション環境のマスター・サイト以外のサイトにデータをレプリケートし、コストのかかる問合せをデータ・ウェアハウス環境にキャッシュします。この章およびこのマニュアル全体では、レプリケーション環境で使用するマテリアライズド・ビューについて説明します。

この項には、次の項目が含まれます。

- マテリアライズド・ビューについて

- マテリアライズド・ビューの使用目的

- 読取り専用、更新可能および書込み可能のマテリアライズド・ビュー

- 使用可能なマテリアライズド・ビュー

- マテリアライズド・ビューの操作に必要な権限

- マテリアライズド・ビューを使用したデータのサブセット化

- マテリアライズド・ビューの高速リフレッシュ機能に関する判断

- 多重化マテリアライズド・ビュー

- オブジェクト型およびコレクションでのマテリアライズド・ビューの動作方法

- マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでのマテリアライズド・ビューの登録

関連項目:
データ・ウェアハウスでのマテリアライズド・ビューの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

マテリアライズド・ビューについて

マテリアライズド・ビューとは、ある一時点におけるターゲット・マスターのレプリカのことです。マスターは、マスター・サイトのマスター表またはマテリアライズド・ビュー・サイトのマスター・マテリアライズド・ビューのいずれかです。マルチマスター・レプリケーションでは、表は他のマスター・サイトによって連続的に更新されますが、マテリアライズド・ビュー・レプリケーションでは、シングル・マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトからバッチ更新(リフレッシュとも呼ばれます)が実行されるたびに、1つ以上のマスターから更新されます(図3-1を参照してください)。図3-1の矢印は、データベース・リンクを表します。

図3-1 1つのマスター・サイトに接続されたマテリアライズド・ビュー

マテリアライズド・ビューが高速リフレッシュされると、Oracleでは最後のリフレッシュ以降にマスター表またはマスター・マテリアライズド・ビューに加えられたすべての変更をチェックして、マテリアライズド・ビューに適用される変更があるかどうかを調べる必要があります。したがって、最後のリフレッシュ以降にマスターに対して変更が加えられている場合は、マテリアライズド・ビューのリフレッシュでは変更を適用する時間がかかります。ただし、最後のリフレッシュ以降にマスターに対して何も変更が加えられていない場合は、マテリアライズド・ビューのリフレッシュはすばやく行われます。

マテリアライズド・ビューの使用目的

マテリアライズド・ビューを使用する目的には、次のようなものがあります。

- ネットワーク負荷の軽減

- 大規模デプロイメント環境の作成

- データのサブセット化の有効化

- モバイル・コンピューティングの有効化

ネットワーク負荷の軽減

ネットワーク負荷の軽減が目的の1つである場合は、マテリアライズド・ビューを使用して会社のデータベースを地域サイトに分散できます。会社全体で1つのデータベース・サーバーにアクセスするのではなく、ユーザーの負荷を複数のデータベース・サーバーに分散します。多重化マテリアライズド・ビューを使用すると、他のマテリアライズド・ビューに基づいたマテリアライズド・ビューを作成でき、これにより、クライアントはマスター・サイトのかわりにマテリアライズド・ビューにアクセスできるため、ユーザーの負荷をさらに分散させることができます。レプリケートされるデータ量を減らすために、マテリアライズド・ビューをマスター表またはマスター・マテリアライズド・ビューのサブセットにできます。

マルチマスター・レプリケーションでも会社のデータベースが複数のサイトに分散されますが、マルチマスター・レプリケーションはトランザクションごとに処理を行うため、マテリアライズド・ビューを使用したレプリケーションよりもネットワーク要件が多くなります。また、マルチマスター・レプリケーションではリアルタイムまたはほぼリアルタイムにレプリケーションが提供されるため、ネットワークの通信量が増大する結果となり、専用のネットワーク・リンクが必要となることもあります。

マテリアライズド・ビューは、1つのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトから効率的なバッチ処理を使用して更新されます。マテリアライズド・ビュー・レプリケーションでは一定時間おきにデータが更新されるので、マルチマスター・レプリケーションの場合よりもネットワーク要件が少なく、依存性も高くありません。マルチマスター・レプリケーションではネットワーク上で常に通信が行われますが、マテリアライズド・ビュー・レプリケーションでは定期的なリフレッシュのみが必要になります。

マテリアライズド・ビューを使用したデータのレプリケーションでは、専用のネットワーク接続が不要なうえ、ターゲット・データへのローカル・アクセスを実行できるためデータの可用性が高くなります。これらのメリットに加え、大規模デプロイメントおよびデータのサブセット化(いずれもネットワーク負荷を軽減します)というメリットにより、レプリケート・データベースのパフォーマンスと信頼性が大幅に向上します。

大規模デプロイメント環境の作成

デプロイメント・テンプレートを使用すると、マテリアライズド・ビュー環境をローカルで事前作成できます。また、デプロイメント・テンプレートを使用すれば、マテリアライズド・ビュー環境を迅速かつ簡単に配置でき、営業支援システムやその他の大規模デプロイメント環境をサポートできます。パラメータを使用すると、デプロイメント・テンプレートを変更せずに個々のユーザー用のカスタム・データ・セットを作成できます。このテクノロジによって、データベースのインフラストラクチャを数百人または数千人のユーザーに提供できます。

データのサブセット化の有効化

マルチマスター・レプリケーションでは、表全体をレプリケートする必要がありますが、マテリアライズド・ビューでは、列レベルまたは行レベル(あるいはその両方)でのサブセット化に基づいたデータをレプリケートできます。データのサブセット化により、特定のサイトのみに関係する情報をレプリケートできます。たとえば、各地の営業所ではその地域に必要なデータのみをレプリケートし、不要なネットワークの通信量を減らすことができます。

モバイル・コンピューティングの有効化

マテリアライズド・ビューは専用のネットワーク接続を必要としません。マテリアライズド・ビューでは、ジョブをスケジュールしてリフレッシュ処理を自動化するというオプションもありますが、必要に応じて手動でリフレッシュでき、これは、ラップトップ上で実行される販売アプリケーションなどには理想的です。たとえば、開発者は、必要なときにリフレッシュを実行するレプリケーション・マネージメントAPIを販売アプリケーションに統合できます。1日の受注業務を終えた営業担当員は、ネットワークにダイアルアップ接続し、統合されたメカニズムを使用してデータベースをリフレッシュすることによって、本社に受注を転送できます。

読取り専用、更新可能および書込み可能のマテリアライズド・ビュー

マテリアライズド・ビューは読取り専用、更新可能または書込み可能のいずれかです。読取り専用マテリアライズド・ビューに対してはデータ操作言語(DML)文を実行できませんが、更新可能および書込み可能のマテリアライズド・ビューに対しては実行できます。

注意:
デフォルトの主キーオプションを使用して定義された読取り専用、更新可能および書込み可能のマテリアライズド・ビューでは、マテリアライズド・ビューの定義問合せでマスター内の主キー列をすべて参照する必要があります。

関連項目:

- 読取り専用、更新可能および書込み可能のマテリアライズド・ビューの概要は、「マテリアライズド・ビュー・レプリケーション」を参照してください。

- 「レプリケート表に関する考慮事項」

読取り専用マテリアライズド・ビュー

マテリアライズド・ビューの作成中に、FOR UPDATE句を指定しないか、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでこれと同等のオプションを使用禁止にすると、マテリアライズド・ビューを読取り専用にできます。読取り専用マテリアライズド・ビューでは更新可能マテリアライズド・ビューと同じメカニズムを多数使用しますが、読取り専用の場合は、マテリアライズド・ビュー・グループに属する必要がありません。

また、読取り専用マテリアライズド・ビューを使用すると、マテリアライズド・ビューが原因でマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでデータ競合が発生することを回避できますが、リモート・マテリアライズド・ビュー・サイトでの更新はできなくなります。読取り専用マテリアライズド・ビューの例を次に示します。

CREATE MATERIALIZED VIEW hr.employees AS
SELECT * FROM hr.employees@orc1.example.com;

更新可能マテリアライズド・ビュー

マテリアライズド・ビューの作成中に、FOR UPDATE句を指定するか、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでこれと同等のオプションを使用可能にすると、マテリアライズド・ビューを更新可能にできます。更新可能マテリアライズド・ビューへの変更をリフレッシュ中にマスターにプッシュするには、更新可能マテリアライズド・ビューがマテリアライズド・ビュー・グループに属する必要があります。

更新可能マテリアライズド・ビューを使用すると、ユーザーがマテリアライズド・ビュー・サイトでデータを変更できるため、マスター・サイトの負荷が軽減されます。更新可能マテリアライズド・ビューの例を次に示します。

CREATE MATERIALIZED VIEW hr.departments FOR UPDATE AS
SELECT * FROM hr.departments@orc1.example.com;

次の文ではマテリアライズド・ビュー・グループが作成されます。

BEGIN
DBMS_REPCAT.CREATE_MVIEW_REPGROUP (
gname => 'hr_repg',
master => 'orc1.example.com',
propagation_mode => 'ASYNCHRONOUS');
END;
/

次の文では、hr.departmentsマテリアライズド・ビューがマテリアライズド・ビュー・グループに追加され、このマテリアライズド・ビューが更新可能になります。

BEGIN
DBMS_REPCAT.CREATE_MVIEW_REPOBJECT (
gname => 'hr_repg',
sname => 'hr',
oname => 'departments',
type => 'SNAPSHOT',
min_communication => TRUE);
END;

/

Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、マテリアライズド・ビュー・グループを作成し、これにマテリアライズド・ビューを追加することもできます。

更新可能マテリアライズド・ビューが存在するシングル・マスター・サイト環境では、次のような場合に、マスター・サイトの管理操作を実行するときの静止が不要になります。

- マスター・グループへの管理操作を実行する前に、更新可能マテリアライズド・ビューを含むデータベースで遅延トランザクションをすべて伝播する場合。

- マスター・サイトに対する管理操作を完了し、更新可能マテリアライズド・ビューのレプリケーション・サポートを再生成するまで、そのマテリアライズド・ビューに対してデータ操作言語(DML)による変更を許可しない場合。

これらのアクションを実行しない場合は、マスター・グループに管理操作を実行する前にマスター・グループを静止します。

注意:

- 更新可能マテリアライズド・ビューを作成するときは、列別名を使用しないでください。CREATE_MVIEW_REPOBJECTプロシージャを使用してマテリアライズド・ビューをマテリアライズド・ビュー・グループに追加しようとしたときに、列の別名が原因でエラーが発生します。

- マスター表またはマスター・マテリアライズド・ビューの列にデフォルト値が定義されていても、これらに基づいた更新可能マテリアライズド・ビューがそのデフォルト値を自動的に使用するわけではありません。

- 更新可能マテリアライズド・ビューとともに使用するDELETE CASCADE制約は、遅延可能である必要があります。

関連項目:

- 詳細は、「マテリアライズド・ビュー・グループ」を参照してください。

- 列別名の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

書込み可能マテリアライズド・ビュー

書込み可能マテリアライズド・ビューとは、FOR UPDATE句を使用して作成されるが、マテリアライズド・ビュー・グループには属さないマテリアライズド・ビューです。ユーザーは書込み可能マテリアライズド・ビューに対してDML操作を実行できますが、マテリアライズド・ビューをリフレッシュしたときに、この変更はマスターにプッシュされず、マテリアライズド・ビュー自体からも変更が失われます。通常、高速リフレッシュが可能な読取り専用マテリアライズド・ビューが使用できる場合は、書込み可能マテリアライズド・ビューも使用できます。

注意:
書込み可能マテリアライズド・ビューはほとんど使用されないため、マテリアライズド・ビューに関するドキュメントのほとんどは、読取り専用および更新可能マテリアライズド・ビューのみを説明しています。

使用可能なマテリアライズド・ビュー

Oracleでは、様々なレプリケーション環境(および非レプリケーション環境)で使用できるいくつかのタイプのマテリアライズド・ビューを用意しています。次の項では、それぞれのタイプのマテリアライズド・ビューと、各マテリアライズド・ビューに最適な環境について説明します。

次の項では、様々なタイプのマテリアライズド・ビューの作成例を示しています。

- 主キー・マテリアライズド・ビュー

- オブジェクト・マテリアライズド・ビュー

- ROWIDマテリアライズド・ビュー

- 複合マテリアライズド・ビュー

どのタイプのマテリアライズド・ビューを作成する場合でも、マテリアライズド・ビューの問合せで表所有者のスキーマ名を指定します。たとえば、次のCREATE MATERIALIZED VIEW文について考えます。

CREATE MATERIALIZED VIEW hr.employees
AS SELECT * FROM hr.employees@orc1.example.com;

この文では、問合せにスキーマhrが指定されています。

注意:
ON COMMITオプションが指定されたマテリアライズド・ビューのマスター表に対する変更を含む分散トランザクションを実行することはできません。ON COMMITオプションが指定されたマテリアライズド・ビューとは、CREATE MATERIALIZED VIEW文でON COMMIT REFRESH句を使用して作成するマテリアライズド・ビューです。ON DEMANDオプションが指定されたマテリアライズド・ビューのマスター表に対する変更を含む分散トランザクションは実行できます。

主キー・マテリアライズド・ビュー

主キー・マテリアライズド・ビューがマテリアライズド・ビューのデフォルト・タイプです。マテリアライズド・ビューがマテリアライズド・ビュー・グループの一部として作成され、マテリアライズド・ビューの定義でFOR UPDATEを指定した場合、マテリアライズド・ビューは更新可能です。更新可能マテリアライズド・ビューは、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでレプリケーション・グループと同じ名前のマテリアライズド・ビュー・グループに属する必要があります。さらに、更新可能マテリアライズド・ビューは、マスター・レプリケーション・グループと別のデータベースに配置する必要があります。

変更は、(ROWIDではなく)行の主キー値によって識別される、行レベルの変更に従って伝播されます。更新可能な主キー・マテリアライズド・ビューを作成するSQL文の例を次に示します。

CREATE MATERIALIZED VIEW oe.customers FOR UPDATE AS
SELECT * FROM oe.customers@orc1.example.com;

リモート・マテリアライズド・ビュー・サイトで行のサブセットを作成できるように、主キー・マテリアライズド・ビューには副問合せを含められます。副問合せは主問合せに埋め込まれた問合せで、CREATE MATERIALIZED VIEW文に複数のSELECT文が使用されます。この副問合せには、基本的なWHERE句のように単純なものと、マルチレベルのWHERE EXISTS句のように複雑なものとがあります。参照される各マスターにマテリアライズド・ビュー・ログがある場合は、選択されたクラスの副問合せを含む主キー・マテリアライズド・ビュー・サイトに高速リフレッシュを実行できます。高速リフレッシュでは、マテリアライズド・ビュー・ログを使用して、最後のリフレッシュ以降に変更が加えられた行のみを更新します。

次のマテリアライズド・ビューは、副問合せを含むWHERE句を使用して作成されています。

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id AND c.credit_limit > 10000);

このタイプのマテリアライズド・ビューは、副問合せマテリアライズド・ビューと呼ばれます。

注意:
このoe.ordersマテリアライズド・ビューを作成するには、マスターのマテリアライズド・ビュー・ログにcredit_limitをロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

関連項目:

- マテリアライズド・ビュー・グループの詳細は、「マテリアライズド・ビュー・グループ」を参照してください。

- 副問合せを使用するマテリアライズド・ビューの詳細は、「副問合せを使用するマテリアライズド・ビュー」を参照してください。

- 高速リフレッシュの詳細は、「リフレッシュ・タイプ」を参照してください。

- マテリアライズド・ビュー・ログの詳細は、「マテリアライズド・ビュー・ログ」を参照してください。

- 副問合せの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

オブジェクト・マテリアライズド・ビュー

マテリアライズド・ビューがオブジェクト表に基づいてOF type句を使用して作成されている場合、このマテリアライズド・ビューはオブジェクト・マテリアライズド・ビューと呼ばれます。オブジェクト・マテリアライズド・ビューは、オブジェクト表と同じ構造です。つまり、オブジェクト・マテリアライズド・ビューは行オブジェクトから構成され、各行オブジェクトはオブジェクト識別子(OID)列により識別されます。

関連項目:
「オブジェクト表に基づいたマテリアライズド・ビュー」

ROWIDマテリアライズド・ビュー

Oracleでは、デフォルトの主キー・マテリアライズド・ビューの他に、ROWIDマテリアライズド・ビューもサポートしています。ROWIDマテリアライズド・ビューは、マスター表の行の物理的な行識別子(ROWID)に基づいて作成されます。ROWIDマテリアライズド・ビューを使用するのは、主キーを持たないマスター表に基づくマテリアライズド・ビュー、またはマスター表の一部の主キー列を含むマテリアライズド・ビューの場合です。

ROWIDマテリアライズド・ビューを作成するCREATE MATERIALIZED VIEW文の例を次に示します。

CREATE MATERIALIZED VIEW oe.orders REFRESH WITH ROWID AS
SELECT * FROM oe.orders@orc1.example.com;

関連項目:

- ROWIDマテリアライズド・ビューと主キー・マテリアライズド・ビューの相違点の詳細は、「マテリアライズド・ビュー・ログ」を参照してください。

- CREATE MATERIALIZED VIEW文のWITH ROWID句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

複合マテリアライズド・ビュー

高速リフレッシュを実行するには、マテリアライズド・ビューの定義問合せで一定の制限事項を守る必要があります。マテリアライズド・ビューの定義問合せが汎用的なものであり、制限事項を守ることができない場合は、そのマテリアライズド・ビューは複合マテリアライズド・ビューであり、高速リフレッシュを実行できません。

具体的には、マテリアライズド・ビューの定義問合せに次のものが含まれる場合、そのマテリアライズド・ビューは複合マテリアライズド・ビューとみなされます。

- CONNECT BY句
たとえば、次の文では複合マテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW hr.emp_hierarchy AS
SELECT LPAD(' ', 4*(LEVEL-1))||email USERNAME
FROM hr.employees@orc1.example.com START WITH manager_id IS NULL
CONNECT BY PRIOR employee_id = manager_id;

- INTERSECT、MINUSまたはUNION ALL集合演算
たとえば、次の文にはUNION ALL集合演算が含まれているため、複合マテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW hr.mview_employees AS
SELECT employees.employee_id, employees.email
FROM hr.employees@orc1.example.com
UNION ALL
SELECT new_employees.employee_id, new_employees.email
FROM hr.new_employees@orc1.example.com;

- DISTINCTまたはUNIQUEキーワード
たとえば、次の文では複合マテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW hr.employee_depts AS
SELECT DISTINCT department_id FROM hr.employees@orc1.example.com
ORDER BY department_id;

- 集計関数(場合による)。集計関数を定義問合せに指定して、単純マテリアライズド・ビューを作成することもできます。
たとえば、次の文では複合マテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW hr.average_sal AS
SELECT AVG(salary) "Average" FROM hr.employees@orc1.example.com;

- 副問合せ以外で指定される結合(場合による)。結合を定義問合せに指定して、単純マテリアライズド・ビューを作成することもできます。
たとえば、次の文では複合マテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW hr.emp_join_dep AS
SELECT last_name
FROM hr.employees@orc1.example.com e, hr.departments@orc1.example.com d
WHERE e.department_id = d.department_id;

- UNION演算子(場合による)。
具体的には、次の条件のいずれかが満たされた場合に、UNION演算子を指定したマテリアライズド・ビューは複合マテリアライズド・ビューになります。

- UNION内の問合せが複合問合せの場合。ここまでの箇条書きの項目は、問合せによりマテリアライズド・ビューが複合マテリアライズド・ビューになる場合を示します。

- 最も外側のSELECTリスト列が、UNION内の問合せに一致しない場合。次の例で、最初の問合せの最も外側のSELECTリストにはorder_totalのみが含まれ、2番目の問合せの最も外側のSELECTリストにはcustomer_idが含まれています。したがって、マテリアライズド・ビューは複合マテリアライズド・ビューです。

CREATE MATERIALIZED VIEW oe.orders AS
SELECT order_total
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT cust_first_name, cust_last_name
FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.credit_limit > 50)
UNION
SELECT customer_id
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT cust_first_name, cust_last_name
FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.account_mgr_id = 30);

最も内側のSELECTリストは、マテリアライズド・ビューが複合マテリアライズド・ビューであるかどうかには関係しません。この例では、UNION内の両方の問合せで、最も内側のSELECTリストはcust_first_nameとcust_last_nameです。

- 「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明されている要件に適合しない句。

注意:
複合マテリアライズド・ビューでは高速リフレッシュができず、ネットワークのパフォーマンスが低下する場合があるため、できるだけ使用しないでください(詳細は、「リフレッシュ処理」を参照してください)。

関連項目:

- 集計関数と結合を含むマテリアライズド・ビューの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

- CONNECT BY句、集合演算、DISTINCTキーワードおよび集計関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

単純マテリアライズド・ビューと複合マテリアライズド・ビューの比較

アプリケーションによっては、複合マテリアライズド・ビューの使用を考慮することが必要な場合があります。図3-2とその後に続く本文では、考慮の必要な場合について説明します。

図3-2 単純マテリアライズド・ビューと複合マテリアライズド・ビューの比較

- 複合マテリアライズド・ビュー: 図3-2の方法Aは、複合マテリアライズド・ビューを示しています。データベースII内のマテリアライズド・ビューでは、マテリアライズド・ビューのリフレッシュ中に結合操作が完了しているので、非常に効率的に問合せが行われます。ただし、複合マテリアライズド・ビューであるため完全リフレッシュを実行する必要があり、多くの場合、完全リフレッシュは、高速リフレッシュに比べ実行速度が遅くなります。

- 結合ビューを含む単純マテリアライズド・ビュー: 図3-2の方法Bは、データベースII内の2つの単純マテリアライズド・ビューと、マテリアライズド・ビューのデータベース内で結合を実行するビューを示しています。ビューに対する問合せのパフォーマンスは、方法Aの複合マテリアライズド・ビューに対する問合せのパフォーマンスに比べよくありません。ただし、単純マテリアライズド・ビューの方が、高速リフレッシュとマテリアライズド・ビュー・ログを使用してより高速にリフレッシュできます。

要約すると、使用する方法は次のようにして判断できます。

- リフレッシュを実行する頻度が少なく、より高速な問合せのパフォーマンスを優先する場合は、方法A(複合マテリアライズド・ビュー)を使用します。

- 頻繁にリフレッシュを実行し、問合せのパフォーマンスを優先する必要がない場合は、方法B(単純マテリアライズド・ビュー)を使用します。

マテリアライズド・ビューの操作に必要な権限

マテリアライズド・ビューに対しては、次の3種類のユーザーが操作を実行します。

- 作成者: マテリアライズド・ビューを作成するユーザー。

- リフレッシャ: マテリアライズド・ビューをリフレッシュするユーザー。

- 所有者: マテリアライズド・ビューを所有するユーザー。マテリアライズド・ビューは、このユーザーのスキーマ内に入れられます。

1人のユーザーが特定のマテリアライズド・ビューに対してこのすべての操作を実行できます。ただし、レプリケーション環境によっては、特定のマテリアライズド・ビューに対して別々のユーザーがこの操作を実行します。これらの操作の実行に必要な権限は、1人のユーザーが操作を実行するか別々のユーザーが実行するかにより異なります。以降の項で、権限要件を詳しく説明します。

マテリアライズド・ビュー・サイトのマテリアライズド・ビューの所有者に、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトへのプライベート・データベース・リンクがある場合は、このデータベース・リンクがマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのマスターの所有者に接続します。それ以外の場合は、データベース・リンク経由の接続に関する通常の規則が適用されます。

注意:
以降の項では、クエリー・リライトが使用可能なマテリアライズド・ビューの作成に必要な要件については説明されていません。詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

関連項目:
以降の項ではデータベース・リンクについて説明しています。データベース・リンクの使用方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

作成者が所有者である場合

マテリアライズド・ビューの作成者が所有者でもある場合、このユーザーには、マテリアライズド・ビューを作成する次の権限が必要であり、これらの権限は明示的に付与されるか、ロールを介して付与されます。

- CREATE MATERIALIZED VIEWまたはCREATE ANY MATERIALIZED VIEW

- CREATE TABLEまたはCREATE ANY TABLE

- マスターおよびマスターのマテリアライズド・ビュー・ログに対するSELECTオブジェクト権限またはSELECT ANY TABLEシステム権限。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがリモートの場合は、マテリアライズド・ビュー・サイトのユーザーがデータベース・リンクを介して接続する先のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーに、SELECTオブジェクト権限を付与する必要があります。

作成者が所有者でない場合

マテリアライズド・ビューの作成者が所有者でない場合は、マテリアライズド・ビューを作成する権限を作成者と所有者に付与する必要があります。作成者の権限と所有者の権限は、いずれもロールを介してではなく、明示的に付与する必要があります。

表3-1は、マテリアライズド・ビューの作成者が所有者でない場合に必要な権限を示します。

表3-1 マテリアライズド・ビューの作成に必要な権限(作成者が所有者でない場合)

作成者

所有者

CREATE ANY MATERIALIZED VIEW

CREATE TABLEまたはCREATE ANY TABLE

マスターおよびマスターのマテリアライズド・ビュー・ログに対するSELECTオブジェクト権限またはSELECT ANY TABLEシステム権限。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがリモートの場合は、マテリアライズド・ビュー・サイトのユーザーがデータベース・リンクを介して接続する先のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーに、SELECTオブジェクト権限を付与する必要があります。

リフレッシャが所有者である場合

マテリアライズド・ビューのリフレッシャが所有者でもある場合、このユーザーには、マスターおよびマスターのマテリアライズド・ビュー・ログに対するSELECTオブジェクト権限またはSELECT ANY TABLEシステム権限が必要です。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがリモートの場合は、マテリアライズド・ビュー・サイトのユーザーがデータベース・リンクを介して接続する先のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーに、SELECTオブジェクト権限を付与する必要があります。この権限は、明示的にまたはロールを介して付与できます。

リフレッシャが所有者でない場合

マテリアライズド・ビューのリフレッシャが所有者でない場合は、リフレッシャと所有者に権限を付与する必要があります。これらの権限は、明示的にまたはロールを介して付与できます。

表3-2は、マテリアライズド・ビューのリフレッシャが所有者でない場合に必要な権限を示します。

表3-2 マテリアライズド・ビューのリフレッシュに必要な権限(リフレッシャが所有者でない場合)

リフレッシャ

所有者

ALTER ANY MATERIALIZED VIEW

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがローカルの場合は、マスターおよびマスターのマテリアライズド・ビュー・ログに対するSELECTオブジェクト権限またはSELECT ANY TABLEシステム権限。

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトがリモートの場合は、マテリアライズド・ビュー・サイトのユーザーがデータベース・リンクを介して接続する先のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのユーザーに、SELECTオブジェクト権限を付与する必要があります。

マテリアライズド・ビューを使用したデータのサブセット化

ある状況において、マテリアライズド・ビューにマスター表またはマスター・マテリアライズド・ビューのデータのサブセットを反映させる必要のある場合があります。行のサブセット化では、WHERE句を使用して、マスター内の必要な行のみをマテリアライズド・ビューに含めることができます。列のサブセット化では、マスター内の必要な列のみをマテリアライズド・ビューに含めることができます。これを行うには、マテリアライズド・ビューの作成中に、SELECT文に該当する列を指定します。デプロイメント・テンプレートを使用してマテリアライズド・ビューを作成する場合には、更新可能マテリアライズド・ビューで列サブセットを定義できます。

データのサブセット化の使用目的には、次のようなものがあります。

- ネットワークの通信量の軽減: 列のサブセットを含むマテリアライズド・ビューでは、マテリアライズド・ビューの定義問合せのWHERE句を満たす変更のみがマテリアライズド・ビュー・サイトに伝播されます。このため、転送データ量が減少し、ネットワーク通信量が軽減されます。

- 機密データの保護: マテリアライズド・ビューの定義問合せを満たすデータ以外は表示できません。

- リソース要件の削減: マテリアライズド・ビューがラップトップに格納される場合は、一般にハード・ディスクは会社のサーバーよりもはるかに小さくなります。サブセット化したマテリアライズド・ビューにより、使用する記憶領域をかなり小さくすることができます。

- リフレッシュ時間の短縮: マテリアライズド・ビュー・サイトに伝播されるデータが少なくなるため、リフレッシュ処理が高速になります。これは、ラップトップからダイアルアップ接続を使用してマテリアライズド・ビューをリフレッシュする必要のあるユーザーにとって不可欠です。

たとえば、次の文では、oe.orders@orc1.example.comマスター表に基づいたマテリアライズド・ビューが作成され、sales_rep_id番号が173の営業担当員の行のみが含まれます。

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
SELECT * FROM oe.orders@orc1.example.com
WHERE sales_rep_id = 173;

受注表でsales_rep_id番号が173以外の行は、このマテリアライズド・ビューからは除外されます。

注意:
以降の項では、副問合せを使用した行のサブセット化について説明します。列のサブセット化の詳細は、「デプロイメント・テンプレートを使用した列のサブセット化」を参照してください。

副問合せを使用するマテリアライズド・ビュー

前述の例は、他のマテリアライズド・ビューへの参照制約がない個別のマテリアライズド・ビューでは非常にうまく機能します。しかし、複数の表の情報に基づいたデータをレプリケートする場合は、これらのマテリアライズド・ビューのメンテナンスと定義が難しくなります。次の項では、副問合せが役立つ場合の例を示します。

多対1副問合せ

oeスキーマにcustomers表とorders表が含まれている場合に、orders表とcustomers表の両方のデータに基づいたorders表のマテリアライズド・ビューを作成するとします。たとえば、営業担当員が、信用限度額が$10,000を超える顧客の注文をすべて調べる必要があるとします。この場合、ordersマテリアライズド・ビューを作成するCREATE MATERIALIZED VIEW文には、多対1関係の副問合せが含まれますが、これは、それぞれの顧客が多数の注文をしている可能性があるためです。

図3-3では、customers表とorders表はcustomer_id列を介して関係していることが示されています。営業担当員の目的は、次の文で達成されます。つまり、次の文では、信用限度額が$10,000より大きい顧客の注文が含まれたマテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id AND c.credit_limit > 10000);

注意:
このoe.ordersマテリアライズド・ビューを作成するには、マスターのマテリアライズド・ビュー・ログにcredit_limitをロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

図3-3 多対1副問合せを使用した行のサブセット化

この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で更新も可能です。信用限度額が$10,000を超える新規顧客が発生した場合は、後続のリフレッシュ処理中に新規データがこのマテリアライズド・ビュー・サイトに伝播されます。同様に、顧客の信用限度額が$10,000以下になった場合は、後続のリフレッシュ処理中に、その顧客のデータがこのマテリアライズド・ビューから削除されます。

1対多副問合せ

oeスキーマにcustomers表とorders表が含まれている場合に、customers表とorders表の両方のデータに基づいたcustomers表のマテリアライズド・ビューを作成するとします。たとえば、営業担当員が、受注合計額が$20,000以上の全顧客を調べる必要があるとすると、最も効率的な方法は、定義問合せに1対多副問合せを指定したマテリアライズド・ビューを作成することです。

customers表に対するCREATE MATERIALIZED VIEW文の定義問合せには、1対多関係を持つ副問合せが含まれます。つまり、それぞれの顧客が多数の注文をしている可能性があります。

図3-4では、orders表とcustomers表はcustomer_id列を介して関係していることが示されています。営業担当員の目的は、次の文で達成されます。つまり、次の文では、受注合計額が$20,000より大きい全顧客が含まれたマテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW oe.customers REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.customers@orc1.example.com c
WHERE EXISTS
(SELECT * FROM oe.orders@orc1.example.com o
WHERE c.customer_id = o.customer_id AND o.order_total > 20000);

注意:
このoe.customersマテリアライズド・ビューを作成するには、orders表のマテリアライズド・ビュー・ログにcustomer_idとorder_totalをロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

図3-4 1対多副問合せを使用した行のサブセット化

この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で、更新も可能です。受注合計額が$20,000を超える新規顧客が発生した場合は、後続のリフレッシュ処理中に新規データがこのマテリアライズド・ビュー・サイトに伝播されます。同様に、$20,000を超える受注合計額に含まれている注文を顧客が取り消して、受注合計額が$20,000より低くなった場合は、後続のリフレッシュ処理中に、その顧客のデータがこのマテリアライズド・ビューから削除されます。

多対多副問合せ

oeスキーマにorder_items表とinventories表が含まれている場合に、inventories表とorder_items表の両方のデータに基づいたinventories表のマテリアライズド・ビューを作成するとします。たとえば、営業担当員が、現在のインベントリ数が1以上の各製品で、製品のproduct_idがorder_items表に含まれている全製品のインベントリを調べる必要があるとします。つまり、営業担当員は、顧客が注文した全製品について、インベントリが1以上の製品を調べる必要があります。この場合、インベントリとは、特定の倉庫にある製品の数です。このため、特定の製品は多数の受注項目と多数のインベントリに含まれる可能性があります。

この営業担当員の目的を達成するには、order_items表とinventories表との間の多対多関係に対する副問合せを使用したマテリアライズド・ビューを作成します。

inventoriesマテリアライズド・ビューを作成する場合は、order_items表に含まれている製品に関して、現在の数量が1以上のインベントリを取り出します。図3-5では、inventories表とorder_items表はproduct_id列を介して関係していることが示されています。次の文によりこのマテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW oe.inventories REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.inventories@orc1.example.com i
WHERE i.quantity_on_hand > 0 AND EXISTS
(SELECT * FROM oe.order_items@orc1.example.com o
WHERE i.product_id = o.product_id);

注意:
このoe.inventoriesマテリアライズド・ビューを作成するには、マスターのマテリアライズド・ビュー・ログにorder_items表のproduct_id列をロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

図3-5 多対多副問合せを使用した行のサブセット化

この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で、更新も可能です。製品に対して1以上のインベントリがorder_items表で見つかった場合は、後続のリフレッシュ処理中に新規データがこのマテリアライズド・ビュー・サイトに伝播されます。同様に、顧客が製品の注文を取り消して、その製品に対する他の注文がorder_items表にない場合は、後続のリフレッシュ処理中に、その製品のインベントリがこのマテリアライズド・ビューから削除されます。

副問合せおよびUNIONを使用するマテリアライズド・ビュー

1つのマテリアライズド・ビューに、複数の問合せの結果に完全に一致するデータを含める場合は、UNION演算子を使用できます。UNION演算子を使用してマテリアライズド・ビューを作成する場合は、UNION演算子の前後に1つずつSELECT文を使用します。結果のマテリアライズド・ビューには、いずれかの問合せにより選択された行が含まれます。

UNION演算子は、副問合せのWHERE句にOR式を使用せずに「OR」条件を満たす高速リフレッシュ可能なマテリアライズド・ビューを作成する方法として使用できます。副問合せのWHERE句にOR式を使用すると、場合によっては結果のマテリアライズド・ビューが複合マテリアライズド・ビューになり、高速リフレッシュができなくなることがあります。

関連項目:
副問合せでのOR式の詳細は、「副問合せを使用するマテリアライズド・ビューでの制限事項」を参照してください。

たとえば、営業担当員が、特定のcategory_idの製品で、カリフォルニアの倉庫にある製品、または翻訳された製品説明(フランス語翻訳用)に「Rouge」という単語が含まれている製品の製品情報を求めているとします。次の文では、UNION演算子と副問合せを使用して、category_id 29の製品について、マテリアライズド・ビューにこのデータを取り出します。

CREATE MATERIALIZED VIEW oe.product_information REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.product_information@orc1.example.com pi
WHERE pi.category_id = 29 AND EXISTS
(SELECT * FROM oe.product_descriptions@orc1.example.com pd
WHERE pi.product_id = pd.product_id AND
pd.translated_description LIKE '%Rouge%')
UNION
SELECT * FROM oe.product_information@orc1.example.com pi
WHERE pi.category_id = 29 AND EXISTS
(SELECT * FROM oe.inventories@orc1.example.com i
WHERE pi.product_id = i.product_id AND EXISTS
(SELECT * FROM oe.warehouses@orc1.example.com w
WHERE i.warehouse_id = w.warehouse_id AND EXISTS
(SELECT * FROM hr.locations@orc1.example.com l
WHERE w.location_id = l.location_id
AND l.state_province = 'California')));

注意:
oe.product_informationマテリアライズド・ビューを作成するには、各マスターのマテリアライズド・ビュー・ログに、oe.product_descriptions表のtranslated_description、hr.locations表のstate_provinceおよびoe.warehouses表のlocation_id列をロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

図3-6に、この文に含まれているマスター表の関係を示します。

図3-6 副問合せおよびUNIONを使用した行のサブセット化

この文には、UNION演算子の他に次の副問合せが含まれています。

- product_information表とproduct_descriptions表を参照する副問合せ。1つの製品には複数の製品説明(異なる言語用)があるため、これは1対多副問合せです。

- product_information表とinventories表を参照する副問合せ。1つの製品は多数のインベントリに含まれることがあるため、これは1対多副問合せです。

- inventories表とwarehouses表を参照する副問合せ。多数のインベントリを1つの倉庫に格納できるため、これは多対1副問合せです。

- warehouses表とlocations表を参照する副問合せ。多数の倉庫を1つの場所に配置できるため、これは多対1副問合せです。

この文により作成されるマテリアライズド・ビューは、高速リフレッシュが可能で、更新も可能です。カリフォルニアの倉庫に格納されているか、翻訳された製品説明に文字列「Rouge」を含む新製品が追加されると、後続のリフレッシュ処理中に新規データがproduct_informationマテリアライズド・ビューに伝播されます。

副問合せを使用するマテリアライズド・ビューでの制限事項

副問合せを使用するマテリアライズド・ビューの定義問合せには、マテリアライズド・ビューの高速リフレッシュ機能を保つためのいくつかの制限事項があります。

副問合せを使用する高速リフレッシュ・マテリアライズド・ビューの制限事項は、次のとおりです。

- マテリアライズド・ビューは、主キー・マテリアライズド・ビューである必要があります。

- マスターのマテリアライズド・ビュー・ログに、副問合せで参照されている列が含まれている必要があります。含める列の詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

- 副問合せが多対多または1対多の場合は、主キーの一部ではない結合列をマスターのマテリアライズド・ビュー・ログに含める必要があります。この制限は、多対1の副問合せには適用されません。

- 副問合せは、肯定副問合せであることが必要です。たとえば、EXISTS条件は使用できますが、NOT EXISTS条件は使用できません。

- 副問合せは、EXISTSを使用して各ネスト・レベルを接続する必要があります(INは使用できません)。

- 各表は1つのEXISTS式にのみ含められます。

- 結合式では、完全一致または等価比較(等価結合)を使用する必要があります。

- 各表は副問合せ内で1回のみ結合できます。

- 各ネスト・レベルの各表に、主キーが存在している必要があります。

- 各ネスト・レベルでは、上位のレベルの表のみを参照できます。

- 副問合せにはAND条件を含められますが、各OR条件は1行に含まれている列のみを参照できます。1つの副問合せ内の複数のOR条件は、AND条件を使用して接続できます。

- 副問合せ内で参照されている表はすべて、同一のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイト内にある必要があります。

注意:
CREATE MATERIALIZED VIEW文にON PREBUILT TABLE句および副問合せが含まれている場合、この副問合せは多対多として扱われます。したがって、この場合は、結合列をマテリアライズド・ビュー・ログに記録する必要があります。CREATE MATERIALIZED VIEW文のON PREBUILT TABLE句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

関連項目:
主キー・マテリアライズド・ビューの詳細は、「主キー・マテリアライズド・ビュー」を参照してください。

副問合せを含むUNIONを使用するマテリアライズド・ビューでの制限事項

副問合せを含むUNIONを使用する高速リフレッシュ・マテリアライズド・ビューには、次の制限事項があります。

- 各UNIONブロック内の副問合せには、「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明したすべての制限事項が適用されます。

- 副問合せが多対1の場合でも、すべての結合列をマスターのマテリアライズド・ビュー・ログに含める必要があります。

- 「複合マテリアライズド・ビュー」で説明した、UNIONSを含む句に対するすべての制限事項が適用されます。

副問合せを含むUNIONを使用するマテリアライズド・ビューの例

次の文は、oe.ordersマテリアライズド・ビューを作成します。各UNIONブロック内の副問合せが、「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明した副問合せに関する制限事項を満たしているため、このマテリアライズド・ビューは高速リフレッシュができます。

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.credit_limit > 50)
UNION
SELECT *
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.account_mgr_id = 30);

副問合せには、各表は1つのEXISTS式にしか含められないという制限事項があります。ここでは、customers表が2つのEXISTS式で使用されていますが、これらのEXISTS式は別々のUNIONブロックにあります。「副問合せを使用するマテリアライズド・ビューでの制限事項」で説明した制限事項は、各UNIONブロックに対してのみ適用されるもので、CREATE MATERIALIZED VIEW文全体に適用されるものではないため、このマテリアライズド・ビューは高速リフレッシュが可能です。

これに対して、次の文で作成されたマテリアライズド・ビューは高速リフレッシュができません。これは、orders表が同一UNIONブロック内の2つのEXISTS式で参照されているためです。

CREATE MATERIALIZED VIEW oe.orders AS
SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id  -- first reference to orders table
AND c.credit_limit > 50
AND EXISTS
(SELECT * FROM oe.orders@orc1.example.com o
WHERE order_total > 5000
AND o.customer_id = c.customer_id)) -- second reference to orders table
UNION
SELECT *
FROM oe.orders@orc1.example.com o
WHERE EXISTS
(SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id
AND c.account_mgr_id = 30);

マテリアライズド・ビューの高速リフレッシュ機能に関する判断

マテリアライズド・ビューの副問合せが前述の制限事項を満たすかどうかを判断するには、高速リフレッシュを指定してマテリアライズド・ビューを作成します。副問合せマテリアライズド・ビューに関する制限事項に違反している場合は、エラーが戻されます。強制リフレッシュを指定した場合、Oracleでは高速リフレッシュが実行できなければ完全リフレッシュが自動的に実行されるため、エラーは戻されません。

また、DBMS_MVIEWパッケージ内のEXPLAIN_MVIEWプロシージャを使用して、既存のマテリアライズド・ビュー、あるいはまだ作成されていないマテリアライズド・ビューに関して次の情報を判断できます。

- マテリアライズド・ビューの機能

- 各機能を使用できるかどうか

- 機能を使用できない理由(機能を使用できない場合)

この情報は、VARRAYまたはMV_CAPABILITIES_TABLEに格納できます。この表に情報を格納する場合は、EXPLAIN_MVIEWプロシージャを実行する前に、Oracle_home/rdbms/adminディレクトリにあるutlxmv.sqlスクリプトを実行してこの表を作成する必要があります。

たとえば、oe.ordersマテリアライズド・ビューの機能を判断するには、次のように入力します。

EXECUTE DBMS_MVIEW.EXPLAIN_MVIEW ('oe.orders');

または、マテリアライズド・ビューがまだ作成されていない場合は、その作成に使用する問合せを指定できます。

BEGIN
DBMS_MVIEW.EXPLAIN_MVIEW ('SELECT * FROM oe.orders@orc1.example.com o
WHERE EXISTS (SELECT * FROM oe.customers@orc1.example.com c
WHERE o.customer_id = c.customer_id AND c.credit_limit > 500)');
END;
/

MV_CAPABILITIES_TABLEを問い合せて結果を表示します。

注意:
MV_CAPABILITIES_TABLEは、事前作成されたコンテナ表に依存するマテリアライズド・ビューのリフレッシュ機能を示しません。たとえば、事前作成されたコンテナ表でのパーティション・メンテナンス操作の後に完全なリフレッシュが必要ですが、MV_CAPABILITIES_TABLEではこの制限が示されません。

関連項目:
EXPLAIN_MVIEWプロシージャの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

多重化マテリアライズド・ビュー

他のマテリアライズド・ビューに基づいたマテリアライズド・ビューを作成する機能により、多重化マテリアライズド・ビューを作成できます。他のマテリアライズド・ビューに基づいたマテリアライズド・ビューは、読取り専用または更新可能です。図3-7の矢印は、データベース・リンクを表します。

図3-7 多重化マテリアライズド・ビュー

多重化マテリアライズド・ビューを使用する場合、マスター表に基づいたマテリアライズド・ビューはレベル1のマテリアライズド・ビューと呼ばれます。次に、レベル1のマテリアライズド・ビューに基づいたマテリアライズド・ビューは、レベル2のマテリアライズド・ビューと呼ばれます。その次はレベル3、その次はレベル4というようになります。図3-8は、これらのレベルを示します。

図3-8 マテリアライズド・ビューのレベル

他のマテリアライズド・ビューのマスターとして機能するマテリアライズド・ビューは、マスター・マテリアライズド・ビューと呼ばれます。どのレベルのマテリアライズド・ビューでもマスター・マテリアライズド・ビューにすることができ、図3-8に示したように、マスター・マテリアライズド・ビューに基づいたマテリアライズド・ビューは複数あります。図3-8では、レベル2の2つのマテリアライズド・ビューがレベル1の1つのマテリアライズド・ビューに基づいています。

図3-9は、レベル1(orders_1)とレベル2(orders_2)にあるマスター・マテリアライズド・ビューを示します。

図3-9 マスター・マテリアライズド・ビュー

レベル1のマテリアライズド・ビューorders_1のマスターは、マスター・サイトにあるマスター表ordersですが、レベル2から開始すると、各マテリアライズド・ビューにはその上のレベルにマスター・マテリアライズド・ビューがあります。たとえば、レベル2のマテリアライズド・ビューorders_2のマスターは、レベル1のマテリアライズド・ビューorders_1です。

マスター・マテリアライズド・ビューは、マスター・サイトのマスター表と同じように機能します。つまり、レベル2のマテリアライズド・ビューからレベル1のマテリアライズド・ビューにプッシュされる変更は、レベル1のマテリアライズド・ビューからマスター表にプッシュされる変更と同じ方法で処理されます。

マスター・マテリアライズド・ビュー・サイトには受信者を登録する必要があります。受信者は、マスター・マテリアライズド・ビューに基づいた多重化マテリアライズド・ビュー・サイトのプロパゲータから遅延トランザクションを受信し、それを適用する必要があります。

関連項目:
「受信者」

多重化マテリアライズド・ビューを使用すると、レプリケーション環境を柔軟に設計できます。マテリアライズド・ビュー・サイトによっては、マスター表のデータをすべてレプリケートする必要のないサイトもあり、実際、このようなサイトにはすべてのデータを格納する記憶域容量がない場合があります。さらに、レプリケートするデータが少ないことにより、ネットワーク上のアクティビティも減少します。

多重化マテリアライズド・ビューは、3レベル以上の構造を持つ組織や、ネットワーク・リソースの制約がある組織に理想的です。たとえば、統合本社、各国本社、各国支店を持つ会社があるとします。この会社では、各国本社レベルと支店レベルにデータをレプリケートするコンピュータが多数あります。この場合、レプリケーション環境は、統合本社にマスター・サイトを、各国本社レベルにマテリアライズド・ビューを配置して構成できます。各国本社レベルのマテリアライズド・ビューは、それぞれの国にあてはまるデータ・サブセットのみをマスター表からレプリケートします。ここで多重化マテリアライズド・ビューを使用すると、各国本社レベルのマテリアライズド・ビューに基づいて支店レベルのマテリアライズド・ビューを配置できます。支店レベルのマテリアライズド・ビューには、レベル1のマテリアライズド・ビューからのデータで、ローカルな顧客にあてはまるデータ・サブセットのみが含まれます。

多重化マテリアライズド・ビューの使用例

全社員の情報を本社(米国)でメンテナンスする多国籍企業があったとします。この会社では、hrスキーマ内の表を使用して社員情報をメンテナンスします。この会社には14か国に本店がそれぞれ1つと、その14か国の主要都市に地区オフィスが多数あります。

たとえば、英国全体で本店が1つありますが、ロンドンにもオフィスが1つあります。英国本店では英国全土の全社員の情報をメンテナンスし、ロンドン・オフィスではこのオフィスの社員のみの社員情報をメンテナンスします。この例では、hr.employeesマスター表が米国の本社にあり、各地区オフィスには必要な社員情報のみを含むhr.employeesマテリアライズド・ビューがあります。

次の文では、英国本店のhr.employeesマテリアライズド・ビューを作成します。この文は、本社のデータベース内のマスター表orc1.example.comに問い合せます。この文では、country_idがUKの社員のみがマテリアライズド・ビューに含まれるように、副問合せを使用しています。

CREATE MATERIALIZED VIEW hr.employees REFRESH FAST FOR UPDATE AS
SELECT * FROM hr.employees@orc1.example.com e
WHERE EXISTS
(SELECT * FROM hr.departments@orc1.example.com d
WHERE e.department_id = d.department_id
AND EXISTS
(SELECT * FROM hr.locations@orc1.example.com l
WHERE l.country_id = 'UK'
AND d.location_id = l.location_id));

注意:
このhr.employeesマテリアライズド・ビューを作成するには、次の列をロギングする必要があります。

- department_id列を、orc1.example.comにあるhr.employeesマスター表のマテリアライズド・ビュー・ログにロギングする必要があります。

- country_id列を、orc1.example.comにあるhr.locationsマスター表のマテリアライズド・ビュー・ログにロギングする必要があります。

詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

次の文では、英国本店のレベル1のマテリアライズド・ビューに基づいてロンドン・オフィスのhr.employeesマテリアライズド・ビューを作成します。この文は、英国本店のデータベースにあるマテリアライズド・ビューreg_uk.example.comに問い合せます。この文では、cityがLondonの社員のみがマテリアライズド・ビューに含まれるように、副問合せを使用しています。

CREATE MATERIALIZED VIEW hr.employees REFRESH FAST FOR UPDATE AS
SELECT * FROM hr.employees@reg_uk.example.com e
WHERE EXISTS
(SELECT * FROM hr.departments@reg_uk.example.com d
WHERE e.department_id = d.department_id
AND EXISTS
(SELECT * FROM hr.locations@reg_uk.example.com l
WHERE l.city = 'London'
AND d.location_id = l.location_id));

注意:
このhr.employeesマテリアライズド・ビューを作成するには、次の列をロギングする必要があります。

- department_id列を、reg_uk.example.comにあるhr.employeesマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログにロギングする必要があります。

- country_id列を、reg_uk.example.comにあるhr.locationsマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログにロギングする必要があります。

詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

多重化マテリアライズド・ビューの使用上の制限事項

マスター・マテリアライズド・ビューおよびマテリアライズド・ビューに基づいたマテリアライズド・ビューの両方は、主キー・マテリアライズド・ビューである必要があります。

多重化マテリアライズド・ビューに対するその他の制限事項

次のタイプのマテリアライズド・ビューは、更新可能マテリアライズド・ビューのマスターとしては指定できません。

- ROWIDマテリアライズド・ビュー

- 複合マテリアライズド・ビュー

- 読取り専用マテリアライズド・ビュー

ただし、これらのマテリアライズド・ビューは、読取り専用マテリアライズド・ビューのマスターとして指定できます。

マテリアライズド・ビューに基づいた更新可能マテリアライズド・ビューに対するその他の制限事項

マテリアライズド・ビューに基づいた更新可能マテリアライズド・ビューには、次の制限事項があります。

- マスター・マテリアライズド・ビュー・サイトのマテリアライズド・ビュー・グループと同じ名前のマテリアライズド・ビュー・グループに属する必要があります。

- マスター・マテリアライズド・ビュー・サイトのマテリアライズド・ビュー・グループとは別のデータベースに入れる必要があります。

- 読取り専用マテリアライズド・ビューではなく、別の更新可能マテリアライズド・ビュー(複数も可)に基づいている必要があります。

- マスター・マテリアライズド・ビュー・サイトのPUBLICにより所有されるマテリアライズド・ビュー・グループ内のマテリアライズド・ビューに基づいている必要があります。

オブジェクト型およびコレクションでのマテリアライズド・ビューの動作方法

Oracleのオブジェクト型はユーザー定義データ型で、これを使用すると現実の複雑なエンティティ(顧客や注文など)をデータベース内に単一エンティティ(オブジェクト)としてモデル化できます。オブジェクト型は、CREATE TYPE ... AS OBJECT文を使用して作成します。オブジェクト型とオブジェクトは、レプリケーション環境のマスター・サイトとマテリアライズド・ビュー・サイト間でレプリケートできます。

表の1列を占有するOracleオブジェクトを、列オブジェクトと呼びます。一般に、列オブジェクトが含まれている表にはその他の列も含まれており、このような列のデータ型は組込みデータ型(VARCHAR2やNUMBERなど)の場合があります。オブジェクト表とは、各行がオブジェクトを表す特殊な表です。オブジェクト表の各行は行オブジェクトです。

コレクションをレプリケートすることもできます。コレクションとは、VARRAYデータ型およびネストした表のデータ型に基づいたユーザー定義データ型です。VARRAYはCREATE TYPE ... AS VARRAY文を、ネストした表はCREATE TYPE ... AS TABLE文を使用して作成します。

注意:

- ON COMMITオプションが指定されたマテリアライズド・ビューを、ユーザー定義型またはオラクル社が提供する型を使用するマスターに基づいて作成することはできません。ON COMMITオプションが指定されたマテリアライズド・ビューとは、CREATE MATERIALIZED VIEW文でON COMMIT REFRESH句を使用して作成するマテリアライズド・ビューです。

- アドバンスト・レプリケーションでは、型継承をサポートしていません。また、NOT FINAL句で作成された型はサポートしていません。

関連項目:

- ユーザー定義型、Oracleオブジェクトおよびコレクションの詳細は、『Oracle Databaseオブジェクト・リレーショナル開発者ガイド』を参照してください。この項では、このマニュアルに記載されている基本的な情報を理解していることを前提としています。

- ユーザー定義型およびオラクル社が提供する型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

レプリケーション・サイトでの型の一致

ユーザー定義型には、オブジェクト、ネストした表、VARRAY、索引タイプなど、CREATE TYPE文で作成された型がすべて含まれます。ユーザー定義型に基づいたスキーマ・オブジェクトをレプリケートするには、全レプリケーション・サイトに同一のユーザー定義型自体が存在する必要があります。さらに、ユーザー定義型が使用されるレプリケーション・グループにユーザー定義型を追加することをお薦めします(ただし、これは必須ではありません)。

ユーザー定義型とそれに基づいたスキーマ・オブジェクトをレプリケートする場合は、次の条件が適用されます。

- マスター・サイトとマテリアライズド・ビュー・サイトでレプリケートされるユーザー定義型は、これらの型に依存するマテリアライズド・ビューを作成する前にマテリアライズド・ビュー・サイトで作成する必要があります。

- ユーザー定義型を持つマテリアライズド・ビューを作成するには、マテリアライズド・ビューの基になるマスターがすべて同一マスター・サイト上にある必要があります。

- ユーザー定義型は全レプリケーション・サイトで同一にする必要があります。

- レプリケートされる各ユーザー定義型について、オブジェクト識別子(OID)、スキーマ所有者および型の名前を全レプリケーション・サイトで同一にする必要があります。

- ユーザー定義型がオブジェクト型の場合は、全レプリケーション・サイトで、オブジェクト型の属性の順序とデータ型が一致する必要があります。属性の順序とデータ型は、オブジェクト型を作成するときに設定します。たとえば、次のようなオブジェクト型の場合を考えます。

CREATE TYPE cust_address_typ AS OBJECT
(street_address     VARCHAR2(40),
postal_code        VARCHAR2(10),
city               VARCHAR2(30),
state_province     VARCHAR2(10),
country_id         CHAR(2));
/

全レプリケーション・サイトで、street_addressはこの型の最初の属性でVARCHAR2(40)、postal_codeは2番目の属性でVARCHAR2(10)、cityは3番目の属性でVARCHAR2(30)、というようになっている必要があります。

- 全レプリケーション・サイトで、ユーザー定義型のハッシュコードが一致する必要があります。Oracleでは、ユーザー定義型が検査され、ハッシュコードが割り当てられます。この検査では、型の属性、属性の順序および型の名前が調べられます。複数の型についてこれらの項目がすべて同じである場合、型のハッシュコードは同じです。型のハッシュコードは、DBA_TYPE_VERSIONSデータ・ディクショナリ・ビューを問い合せて表示できます。

全レプリケーション・サイトでユーザー定義型を同一にするには、次のいずれかの方法でマテリアライズド・ビュー・サイトにユーザー定義型を作成する必要があります。

- レプリケーション・マネージメントAPIの使用

- CREATE TYPE文の使用

レプリケーション・マネージメントAPIの使用

マテリアライズド・ビュー・サイトでユーザー定義型を含むレプリケート・オブジェクトを作成、変更または削除する場合は、レプリケーション・マネージメントAPIの使用をお薦めします。レプリケーション・マネージメントAPIを使用しない場合、レプリケーション・エラーが発生することがあります。

マスター・サイトとマテリアライズド・ビュー・サイトで同一のユーザー定義型を作成するには、DBMS_REPCATパッケージ内のCREATE_MVIEW_REPOBJECTプロシージャを使用します。このプロシージャは型を作成してマテリアライズド・ビュー・グループに追加します。マテリアライズド・ビュー・サイトからユーザー定義型を削除するには、DBMS_REPCATパッケージ内のDROP_MVIEW_REPOBJECTプロシージャを使用します。

関連項目:
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』

CREATE TYPE文の使用

型を作成するには、マテリアライズド・ビュー・サイトでCREATE TYPE文を使用できます。型を使用する読取り専用マテリアライズド・ビューを作成し、この読取り専用マテリアライズド・ビューをマテリアライズド・ビュー・グループに追加しない場合は、この方法が必要になることがあります。

この方法を選択する場合は、次のことを確認する必要があります。

- マテリアライズド・ビュー・サイトとマスター・サイトで型が同一スキーマ内にあること。

- マテリアライズド・ビュー・サイトとマスター・サイトで型の属性および順序が同一であること。

- マテリアライズド・ビュー・サイトとマスター・サイトで型の各属性のデータ型が同一であること。

- マテリアライズド・ビュー・サイトとマスター・サイトで型のオブジェクト識別子が同一であること。

型のオブジェクト識別子は、DBA_TYPESデータ・ディクショナリ・ビューを問い合せると検出できます。たとえば、cust_address_typのオブジェクト識別子(OID)を検出するには、次の問合せを入力します。

SELECT TYPE_OID FROM DBA_TYPES WHERE TYPE_NAME = 'CUST_ADDRESS_TYP';

TYPE_OID
--------------------------------
6F9BC33653681B7CE03400400B40A607

これで、マスター・サイトでの型のOIDが認識できたため、次の手順を実行して、マテリアライズド・ビュー・サイトでこの型を作成します。

1. マスター・サイトでこの型を所有するユーザーとして、マテリアライズド・ビュー・サイトにログインします。マテリアライズド・ビュー・サイトにこのユーザーがない場合はユーザーを作成します。

2. CREATE TYPE文を発行し、OIDを指定します。

CREATE TYPE oe.cust_address_typ OID '6F9BC33653681B7CE03400400B40A607'
AS OBJECT (
street_address     VARCHAR2(40),
postal_code        VARCHAR2(10),
city               VARCHAR2(30),
state_province     VARCHAR2(10),
country_id         CHAR(2));
/

これで、マテリアライズド・ビュー・サイトでこの型を使用できます。

列オブジェクトを使用したマスターの列のサブセット化

読取り専用マテリアライズド・ビューでは、その他の属性はレプリケートせずに列オブジェクトの特定の属性のみをレプリケートできます。たとえば、前述のcust_address_typユーザー定義データ型を使用して、customers_subマスター表がマスター・サイトorc1.example.comに作成されているとします。

CREATE TABLE oe.customers_sub (
customer_id        NUMBER(6)  PRIMARY KEY,
cust_first_name    VARCHAR2(20),
cust_last_name     VARCHAR2(20),
cust_address       oe.cust_address_typ);

次の読取り専用マテリアライズド・ビューをリモート・マテリアライズド・ビュー・サイトに作成できます。

CREATE MATERIALIZED VIEW oe.customers_mv1 AS
SELECT customer_id, cust_last_name, c.cust_address.postal_code
FROM oe.customers_sub@orc1.example.com c;

ここでは、postal_code属性がcust_address列オブジェクト内に指定されています。

更新可能マテリアライズド・ビューでは列オブジェクト全体をレプリケートします。列オブジェクトの属性を部分的にレプリケートすることはできません。次の文はcust_address列オブジェクト全体を指定しているため有効です。

CREATE MATERIALIZED VIEW oe.customers_mv1 FOR UPDATE AS
SELECT customer_id, cust_last_name, cust_address
FROM oe.customers_sub@orc1.example.com;

関連項目:
デプロイメント・テンプレートを使用した列のサブセット化の詳細は、「デプロイメント・テンプレートを使用した列のサブセット化」を参照してください。列のサブセット化は、デプロイメント・テンプレートを使用した場合にのみサポートされます。

オブジェクト表に基づいたマテリアライズド・ビュー

マテリアライズド・ビューがオブジェクト表に基づいてOF type句を使用して作成されている場合、このマテリアライズド・ビューはオブジェクト・マテリアライズド・ビューと呼ばれます。オブジェクト・マテリアライズド・ビューは、オブジェクト表と同じ構造です。つまり、オブジェクト・マテリアライズド・ビューは行オブジェクトで構成されます。オブジェクト表に基づいたマテリアライズド・ビューがOF type句を使用せずに作成されている場合、このマテリアライズド・ビューは読取り専用で、オブジェクト・マテリアライズド・ビューではありません。つまり、このようなマテリアライズド・ビューには、行オブジェクトではなく通常の行が含まれています。

オブジェクト表に基づいたマテリアライズド・ビューを作成するには、マテリアライズド・ビューが依存する型がマテリアライズド・ビュー・サイトに必要で、それぞれの型にはマスター・サイトと同じオブジェクト識別子が必要です。

OF type句を使用したオブジェクト・マテリアライズド・ビューの作成

必要な型をマテリアライズド・ビュー・サイトに作成した後、OF type句を指定してオブジェクト・マテリアライズド・ビューを作成できます。

たとえば、次のSQL文でorc1.example.comマスター・サイトにoe.categories_tabオブジェクト表を作成するとします。

CREATE TYPE oe.category_typ AS OBJECT
(category_name           VARCHAR2(50),
category_description    VARCHAR2(1000),
category_id             NUMBER(2));
/

CREATE TABLE oe.categories_tab OF oe.category_typ
(category_id    PRIMARY KEY);

oe.categories_tabマスター表に基づいて高速リフレッシュが可能なマテリアライズド・ビューを作成するには、この表のマテリアライズド・ビュー・ログを作成します。

CREATE MATERIALIZED VIEW LOG ON oe.categories_tab WITH OBJECT ID;

オブジェクト表に対するマテリアライズド・ビュー・ログを作成する場合には、WITH OBJECT ID句が必要です。

マスター・サイトの同じ型と同じオブジェクト識別子を持つoe.category_typ型をマテリアライズド・ビュー・サイトに作成した後、次のSQL文のようにOF type句を使用して、oe.categories_tabオブジェクト表に基づくオブジェクト・マテリアライズド・ビューを作成できます。

CREATE MATERIALIZED VIEW oe.categories_objmv OF oe.category_typ
REFRESH FAST FOR UPDATE
AS SELECT * FROM oe.categories_tab@orc1.example.com;

この場合、typeはoe.category_typです。

注意:
型はマテリアライズド・ビュー・サイトとマスター・サイトで同一にする必要があります。詳細は、「レプリケーション・サイトでの型の一致」を参照してください。

オブジェクト表に基づいてOF type句を使用せずに作成したマテリアライズド・ビュー

オブジェクト表に基づいてOF type句を使用せずにマテリアライズド・ビューを作成した場合、このマテリアライズド・ビューは読取り専用となり、基になるオブジェクト表のオブジェクト・プロパティは失われます。つまり、作成された読取り専用マテリアライズド・ビューにはマスターの列が1つ以上含まれますが、それぞれの行はリレーショナル表の行として機能します。行は行オブジェクトではありません。

たとえば、次のSQL文を使用して、categories_tabマスター表に基づいたマテリアライズド・ビューを作成できます。

CREATE MATERIALIZED VIEW oe.categories_relmv
AS SELECT * FROM oe.categories_tab@orc1.example.com;

この場合、categories_relmvマテリアライズド・ビューは読取り専用で、このマテリアライズド・ビューの行は、リレーショナル表の行と同じように機能します。

オブジェクト・マテリアライズド・ビューでのOIDの保持

オブジェクト・マテリアライズド・ビューは、マスターのオブジェクト識別子(OID)指定を継承します。マスターに主キー・ベースのOIDがある場合、マテリアライズド・ビューの行オブジェクトのOIDは主キー・ベースになります。マスターにシステム生成されたOIDがある場合、マテリアライズド・ビューの行オブジェクトのOIDはシステム生成されたOIDです。また、オブジェクト・マテリアライズド・ビューの各行のOIDは、マスター内の同じ行のOIDと一致し、マテリアライズド・ビューのリフレッシュ中、OIDは保持されます。この結果、オブジェクト表の行に対するREFは、マテリアライズド・ビュー・サイトでも有効になります。

コレクション列を含むマテリアライズド・ビュー

コレクション列とは、VARRAYデータ型およびネストした表のデータ型に基づいた列です。Oracleではコレクション列を含むマテリアライズド・ビューの作成をサポートしています。

コレクション列がネストした表の場合は、マテリアライズド・ビューの作成中にオプションとしてnested_table_storage_clauseを指定できます。nested_table_storage_clauseを使用すると、ネストした表用の記憶表の名前をマテリアライズド・ビューに指定できます。たとえば、マスター・サイトorc1.example.comにマスター表people_reltabを作成し、この表にネストした表phones_ntabが含まれているとします。

CREATE TYPE oe.phone_typ AS OBJECT (
location    VARCHAR2(15),
num         VARCHAR2(14));
/

CREATE TYPE oe.phone_ntabtyp AS TABLE OF oe.phone_typ;
/

CREATE TABLE oe.people_reltab (
id               NUMBER(4) CONSTRAINT pk_people_reltab PRIMARY KEY,
first_name       VARCHAR2(20),
last_name        VARCHAR2(20),
phones_ntab      oe.phone_ntabtyp)
NESTED TABLE phones_ntab STORE AS phone_store_ntab
((PRIMARY KEY (NESTED_TABLE_ID, location)));

このSQL文の最後の行のPRIMARY KEY指定に注意してください。親表に基づいてマテリアライズド・ビューを作成する場合は、記憶表に主キーを指定する必要があります。この例では、記憶表はphone_store_ntabで、親表はpeople_reltabです。

高速リフレッシュ可能なマテリアライズド・ビューを作成する場合は、親表と記憶表の両方にマテリアライズド・ビュー・ログを作成し、ネストした表の列を親表のマテリアライズド・ビュー・ログのフィルタ列として指定します。

CREATE MATERIALIZED VIEW LOG ON oe.people_reltab;

ALTER MATERIALIZED VIEW LOG ON oe.people_reltab ADD(phones_ntab);

CREATE MATERIALIZED VIEW LOG ON oe.phone_store_ntab WITH PRIMARY KEY;

マテリアライズド・ビュー・サイトで必要な型を作成し、それぞれの型のオブジェクト識別子がマスター・サイトのオブジェクト識別子と同じになるようにします。この後、people_reltabに基づいてマテリアライズド・ビューを作成し、次の文を使用してその記憶表を指定できます。

CREATE MATERIALIZED VIEW oe.people_reltab_mv
NESTED TABLE phones_ntab STORE AS phone_store_ntab_mv
REFRESH FAST AS SELECT * FROM oe.people_reltab@orc1.example.com;

この場合、nested_table_storage_clauseは前述の例の「NESTED TABLE」で始まる行であり、これによって記憶表の名前がphone_store_ntab_mvであることを指定します。nested_table_storage_clauseはオプションです。この句を指定しない場合、記憶表には自動的に名前が付けられます。記憶表の名前を表示するには、DBA_NESTED_TABLESデータ・ディクショナリ表を問い合せます。

記憶表には次の特性があります。

- 個別のセカンダリ・マテリアライズド・ビューです。

- ネストした表を含むマテリアライズド・ビューをリフレッシュすると、自動的にリフレッシュされます。

- ネストした表を含むマテリアライズド・ビューを削除すると、自動的に削除されます。

- マスターの記憶表の主キー制約を継承します。

記憶表はマスターの記憶表の主キー制約を継承するため、STORE AS句にはPRIMARY KEYを指定しないでください。

マテリアライズド・ビュー内のネストした表の記憶表に対して次のアクションを直接実行することはできません。

- 記憶表のリフレッシュ

- レプリケーション・グループへの記憶表の追加

- 記憶表の変更

- 記憶表の削除

- 記憶表に対するレプリケーション・サポートの生成

これらのアクションは、ネストした表を含むマテリアライズド・ビューに対する実行時に間接的に発生します。さらに、記憶表内の列のサブセットはレプリケートできません。

関連項目:
nested_table_storage_clauseの詳細は、『Oracle Database SQL言語リファレンス』のCREATE TABLE文に関する説明を参照してください。

コレクション列を含むマテリアライズド・ビューに関する制限事項

コレクション列を含むマテリアライズド・ビューには、次の制限事項があります。

- コレクション列の行のサブセット化はできません。ただし、ネストした表の親表に対しては行のサブセット化を使用でき、その結果、マスター・マテリアライズド・ビューのネストした表がサブセット化されます。

- コレクション列の列のサブセット化はできません。

- ネストした表の記憶表には主キーが必要です。

- ネストした表の親表で高速リフレッシュ可能にするには、親表とネストした表の両方の記憶表にマテリアライズド・ビュー・ログが必要です。

REF列を含むマテリアライズド・ビュー

REF列を含むマテリアライズド・ビューを作成できます。REFとはOracleの組込みデータ型で、オブジェクト表内の行オブジェクトを指す論理的なポインタです。有効範囲付きREFは、指定された表のみへの参照を含むREFで、有効範囲なしREFは、データベース内で対応するオブジェクト型に基づいたすべてのオブジェクト表に対する参照を含められます。有効範囲付き REFは、有効範囲なしREFと比べて必要とする記憶領域が少なく、より効率的なアクセスを提供します。

次の項で説明するように、マテリアライズド・ビューの作成中にREF列の有効範囲を変更して、マテリアライズド・ビュー・サイトのローカルなマテリアライズド・ビューまたは表を指すように変更できます。REF列の有効範囲を変更しないと、リモートのマスターを指したままになります。有効範囲なしREF列は、常にマスターを指します。マテリアライズド・ビューのREF列がリモート・マスターを指す場合、REFには参照先がないとみなされます。SQLでは、参照先がないREFを参照解除すると、NULLが返されます。また、PL/SQLではUTL_OBJECTパッケージを使用したREFの参照解除のみがサポートされ、参照先がないREFに対しては例外が発生します。

有効範囲付きREF列

有効範囲付きREF列を含むマスターに基づいてマテリアライズド・ビューを作成する場合は、REFの有効範囲をマテリアライズド・ビュー・サイトの別のオブジェクト表またはオブジェクト・マテリアライズド・ビューに変更できます。通常、REF列の有効範囲は、元のリモート・オブジェクト表ではなくローカル・オブジェクト・マテリアライズド・ビューに変更します。マテリアライズド・ビューの有効範囲を変更するには、CREATE MATERIALIZED VIEW文にSCOPE FOR句を使用するか、マテリアライズド・ビューを作成した後でALTER MATERIALIZED VIEW文を使用します。REF列の有効範囲を変更しないと、マテリアライズド・ビューはマスターのREF列をそのまま保持します。

たとえば、次の文を使用してorc1.example.comマスター・サイトにcustomers_with_refマスター表を作成するとします。

-- Create the user-defined data type cust_address_typ.
CREATE TYPE oe.cust_address_typ AS OBJECT
(street_address     VARCHAR2(40),
postal_code        VARCHAR2(10),
city               VARCHAR2(30),
state_province     VARCHAR2(10),
country_id         CHAR(2));
/

-- Create the object table cust_address_objtab.
CREATE TABLE oe.cust_address_objtab OF oe.cust_address_typ;

-- Create table with REF to cust_address_typ.
CREATE TABLE oe.customers_with_ref (
customer_id        NUMBER(6) PRIMARY KEY,
cust_first_name    VARCHAR2(20),
cust_last_name     VARCHAR2(20),
cust_address       REF oe.cust_address_typ
SCOPE IS oe.cust_address_objtab);

マスター・サイトの型と同じオブジェクト識別子を持つcust_address_typがマテリアライズド・ビュー・サイトにあると仮定した場合、次の文を使用するとcust_address_objtab_mvオブジェクト・マテリアライズド・ビューを作成できます。

CREATE MATERIALIZED VIEW oe.cust_address_objtab_mv OF oe.cust_address_typ AS
SELECT * FROM oe.cust_address_objtab@orc1.example.com;

これで、次の文を使用してcustomers_with_refマスター表のマテリアライズド・ビューを作成し、REFの有効範囲をcust_address_objtab_mvマテリアライズド・ビューに変更できます。

CREATE MATERIALIZED VIEW oe.customers_with_ref_mv
(SCOPE FOR (cust_address) IS oe.cust_address_objtab_mv)
AS SELECT * FROM oe.customers_with_ref@orc1.example.com;

マテリアライズド・ビューを作成するときにSCOPE FOR句を使用する場合は、SCOPE FOR句に指定するマテリアライズド・ビューまたは表を先に作成する必要があります。そうしないと、マテリアライズド・ビューの作成中にSCOPE FOR句を指定できません。たとえば、cust_address_objtab_mvマテリアライズド・ビューを作成する前に、customers_with_ref_mvマテリアライズド・ビューを作成すると、customers_with_ref_mvマテリアライズド・ビューを作成するときにSCOPE FOR句を使用できません。この場合、REFはリモート・マスター・サイトのオブジェクト表を指すため、参照先がないとみなされます。

ただし、マテリアライズド・ビューを作成するときにSCOPE FOR句を使用しない場合でも、SCOPE FOR句を指定するようにマテリアライズド・ビューを変更できます。たとえば、次の文でcustomers_with_ref_mvマテリアライズド・ビューを変更できます。

ALTER MATERIALIZED VIEW oe.customers_with_ref_mv
MODIFY SCOPE FOR (cust_address) IS oe.cust_address_objtab_mv;

有効範囲なしREF列

有効範囲なしREF列を含むリモート・マスターに基づいてマテリアライズド・ビューを作成した場合、マテリアライズド・ビューにREF列は作成されますが、REFはリモート・データベースを指すため参照先がないとみなされます。

マテリアライズド・ビュー・ログへのREF列のロギング

必要であれば、REF列をマテリアライズド・ビュー・ログにロギングできます。

関連項目:
詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

WITH ROWID句を使用して作成されたREF

REF列に対してWITH ROWID句を指定すると、REFで参照されているオブジェクトの行IDがメンテナンスされます。REFに含まれている行IDを使用して、参照されているオブジェクトを直接検出できます(OID索引から行IDをフェッチする必要はありません)。したがって、WITH ROWID句は行IDヒントを指定するために使用します。WITH ROWID句は、有効範囲付きREFに対してはサポートされていません。

WITH ROWID句を使用して作成されたREFをレプリケートすると、REFが最初に作成または変更されたサイトを除き、各レプリケーション・サイトでは行IDヒントが正しくなくなります。他のサイトではREFに含まれているROWID情報が無意味になります(行IDヒントは自動的には修正されません)。無効な行IDヒントは、パフォーマンス上の問題の原因になります。この場合は、ANALYZE TABLE文のVALIDATE STRUCTUREオプションを使用して、各レプリケーション・サイトの正しくない行IDヒントを判断できます。

関連項目:
ANALYZE TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでのマテリアライズド・ビューの登録

マスター・サイトとマスター・マテリアライズド・ビュー・サイトでは、マテリアライズド・ビューに関する情報がマスター表またはマスター・マテリアライズド・ビューに基づいて自動的に登録されます。次の項では、マテリアライズド・ビューの登録メカニズムについて説明します。

登録されたマテリアライズド・ビューに関する情報の表示

レベル1のマテリアライズド・ビューまたはマテリアライズド・ビュー・グループは、マスター・サイトに登録されます。レベル2以上の多重化マテリアライズド・ビューまたはマテリアライズド・ビュー・グループは、マスター・サイトではなくマスター・マテリアライズド・ビュー・サイトに登録されます。マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでDBA_REGISTERED_MVIEWSデータ・ディクショナリ・ビューを問い合せると、リモート・マテリアライズド・ビューに関する次の情報を表示できます。

- 所有者、名前およびマテリアライズド・ビューを含むデータベース

- マテリアライズド・ビューの定義問合せ

- マテリアライズド・ビューのその他の特性(リフレッシュ方式など)

さらに、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでDBA_MVIEW_REFRESH_TIMESビューを問い合せると、各リモート・マテリアライズド・ビューの最新リフレッシュ時刻を取得できます。管理者は、この情報を使用してマテリアライズド・ビューのアクティビティを監視し、マスター表またはマスター・マテリアライズド・ビューの削除、変更または再配置が必要な場合にマテリアライズド・ビュー・サイトへの変更を調整できます。

内部メカニズム

Oracleでは、マテリアライズド・ビューが作成されると、それをマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに登録し、マテリアライズド・ビューが削除されるとその登録を解除します。同じことがマテリアライズド・ビュー・グループにも当てはまります。

マスター・マテリアライズド・ビューを削除した場合、これに基づいたマテリアライズド・ビューは自動的には削除されません。これらのマテリアライズド・ビューは手動で削除する必要があります。このようなマテリアライズド・ビューを削除せずに、すでに削除されているマスター・マテリアライズド・ビューに対してそのマテリアライズド・ビューからリフレッシュしようとすると、エラーが戻されます。

たとえば、orders_lev1というマテリアライズド・ビューがoe.ordersマスター表に基づいており、orders_lev2というマテリアライズド・ビューがorders_lev1に基づいているとします。orders_lev1を削除しても、orders_lev2はそのまま残ります。ここで、orders_lev2をリフレッシュしようとすると、orders_lev1はすでに存在しないため、エラーが戻されます。

注意:
マテリアライズド・ビューを作成(または削除)するとき、このマテリアライズド・ビューがマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに登録(または登録解除)されるとはかぎりません。マテリアライズド・ビューを作成中にOracleで正常に登録できない場合は、DBMS_MVIEWパッケージ内のREGISTER_MVIEWプロシージャを使用して手動で登録を完了する必要があります。マテリアライズド・ビューを削除するときにOracleで正常にその登録を解除できない場合は、手動で登録を解除するまで、そのマテリアライズド・ビューの登録情報がマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに残ります。複合マテリアライズド・ビューは登録されない場合があります。

マテリアライズド・ビューの手動による登録

必要な場合は、登録を手動でメンテナンスできます。マテリアライズド・ビューの登録情報を追加、変更または削除するには、DBMS_MVIEWパッケージにあるREGISTER_MVIEWおよびUNREGISTER_MVIEWプロシージャを使用します。

関連項目:
REGISTER_MVIEWプロシージャおよびUNREGISTER_MVIEWプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

マテリアライズド・ビューのアーキテクチャ

図3-10は、マテリアライズド・ビューのレプリケーションに使用されるオブジェクトを示します。これらのオブジェクトの一部はオプションで、作成したマテリアライズド・ビュー環境のサポートに必要な場合にのみ使用します。たとえば、読取り専用マテリアライズド・ビューがある場合は、マテリアライズド・ビュー・サイトには更新可能マテリアライズド・ビュー・ログや内部トリガーはありません。また、高速リフレッシュができない複合マテリアライズド・ビューがある場合は、マスター・サイトにマテリアライズド・ビュー・ログがない可能性があります。

図3-10 マテリアライズド・ビューのレプリケーション・オブジェクト

マスター・マテリアライズド・ビューには、マテリアライズド・ビュー・ログと更新可能マテリアライズド・ビュー・ログの両方が含まれている場合があります。マスター・マテリアライズド・ビュー・サイトを計画する場合は、この2つのログに必要な追加領域を考慮してください。

この項には、次の項目が含まれます。

- マスター・サイトおよびマスター・マテリアライズド・ビュー・サイトのメカニズム

- マテリアライズド・ビュー・サイトのメカニズム

- 編成メカニズム

- リフレッシュ処理

マスター・サイトおよびマスター・マテリアライズド・ビュー・サイトのメカニズム

マテリアライズド・ビューの高速リフレッシュをサポートするために、図3-11に示されている3つのメカニズムがマスター・サイトとマスター・マテリアライズド・ビュー・サイトの両方で必要です。

注意:
マスター・マテリアライズド・ビューには、この項で説明されているメカニズムの他に、「マテリアライズド・ビュー・サイトのメカニズム」で説明されているメカニズムも含まれています。

図3-11 マスター・サイトおよびマスター・マテリアライズド・ビュー・サイトのオブジェクト

マスター表およびマスター・マテリアライズド・ビュー

マスター表またはマスター・マテリアライズド・ビューは、マテリアライズド・ビューの基礎です。マスター表はターゲット・マスター・サイトにあり、マスター・マテリアライズド・ビューはマスター・マテリアライズド・ビュー・サイトにあります。マスターがマスター表の場合、この表はマテリアライズド・ビュー・レプリケーションとマルチマスター・レプリケーションの両方に関与している可能性があります。マテリアライズド・ビューが指すマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトは1つのみです。マスター表またはマスター・マテリアライズド・ビューに加えられた変更はマテリアライズド・ビュー・ログに記録され、リフレッシュ処理中にマテリアライズド・ビューに伝播されます。

注意:
高速リフレッシュ可能マテリアライズド・ビューは、マスター表、マスター・マテリアライズド・ビュー、またはマスター表かマスター・マテリアライズド・ビューのシノニムに基づく必要があります。完全リフレッシュは、ビューに基づいたマテリアライズド・ビューで使用する必要があります。

マテリアライズド・ビュー・ログの内部トリガー

DMLを使用してマスター表またはマスター・マテリアライズド・ビューに変更が加えられると、内部トリガーにより、影響を受けた行に関する情報がマテリアライズド・ビュー・ログに記録されます。この情報には、主キー、行IDまたはオブジェクト識別子(あるいはこれらすべて)の値のみでなく、マテリアライズド・ビュー・ログにロギングされる他の列の値も含まれます。これは、ターゲットのマスター表またはマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログを作成するときに自動的にアクティブになるAFTER ROW内部トリガーです。このトリガーは、INSERT文、UPDATE文またはDELETE文により表のデータが変更されるたびに、マテリアライズド・ビュー・ログに行を挿入します。このトリガーは、常に最後に起動されるトリガーです。

注意:
マテリアライズド・ビューに副問合せが含まれている場合は、副問合せで参照される列のログが必要になることがあります。副問合せマテリアライズド・ビューの詳細は、「マテリアライズド・ビューを使用したデータのサブセット化」、ログが必要になる列の詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

マテリアライズド・ビュー・ログ

マスターに基づいてマテリアライズド・ビューを高速リフレッシュする場合は、マスター上にマテリアライズド・ビュー・ログが必要です。マスター表またはマスター・マテリアライズド・ビューにマテリアライズド・ビュー・ログを作成すると、基になる表がマテリアライズド・ビュー・ログとして作成されます。マテリアライズド・ビュー・ログには、マスター表またはマスター・マテリアライズド・ビューで更新された行の主キー、行IDまたはオブジェクト識別子(あるいはこれらすべて)を含められます。マテリアライズド・ビュー・ログには、副問合せを含むマテリアライズド・ビューの高速リフレッシュをサポートする他の列を含めることもできます。

マテリアライズド・ビュー・ログの表の名前は、MLOG$_master_nameです。マテリアライズド・ビュー・ログは、ターゲット・マスターと同じスキーマ内に作成されます。1つのマテリアライズド・ビュー・ログは、マスター表またはマスター・マテリアライズド・ビューに対する複数のマテリアライズド・ビューをサポートできます。前の項で説明したように、ターゲット・マスターに対してDMLトランザクションが発生するたびに、内部トリガーによってマテリアライズド・ビュー・ログに変更情報が追加されます。

マテリアライズド・ビュー・ログには次のタイプがあります。

- 主キー: マテリアライズド・ビューは、マスター表またはマスター・マテリアライズド・ビューが変更されると、影響を受けた行の主キーに基づいて変更内容を記録します。

- 行ID: マテリアライズド・ビューは、マスター表またはマスター・マテリアライズド・ビューが変更されると、影響を受けた行の行IDに基づいて変更内容を記録します。

- オブジェクトID: マテリアライズド・ビューは、マスター・オブジェクト表またはマスター・オブジェクト・マテリアライズド・ビューが変更されると、影響を受けた行オブジェクトのオブジェクト識別子に基づいて変更内容を記録します。

- 組合せ: マテリアライズド・ビューは、3つのオプションの組合せに基づいてマスター表またはマスター・マテリアライズド・ビューへの変更を記録します。主キー、ROWID、影響を受ける行のオブジェクト識別子に基づいて変更を記録できます。このようなマテリアライズド・ビュー・ログは、主キー、ROWIDおよびオブジェクト・マテリアライズド・ビューをサポートし、マスターに基づく3つのすべてのタイプのマテリアライズド・ビューのある環境で役立ちます。

組合せマテリアライズド・ビュー・ログは、1種類のタイプの値を追跡するマテリアライズド・ビュー・ログと同じように機能しますが、複数のタイプの値が記録されるという点のみが異なります。たとえば、組合せマテリアライズド・ビュー・ログは、影響を受けた行の主キーと行IDの両方を追跡および記録できます。

主キーに基づいたマテリアライズド・ビュー・ログと行IDに基づいたマテリアライズド・ビュー・ログの間に大きな違いはありませんが(影響を受けた行を記録する際に、主キーと物理行IDのどちらを使用するかという点のみが異なります)、実際に与える影響は非常に大きくなります。ROWIDマテリアライズド・ビューとマテリアライズド・ビュー・ログを使用すると、ROWIDマテリアライズド・ビューを高速リフレッシュできなくなるため、マスター表の再編成および切捨てが難しくなります。マスター表の再編成または切捨てを実行した場合はマスター表の行IDが変更されるため、ROWIDマテリアライズド・ビューは完全リフレッシュする必要があります。

注意:

- マスター表の再編成には、DBMS_MVIEWパッケージのBEGIN_TABLE_REORGANIZATIONおよびEND_TABLE_REORGANIZATIONプロシージャを使用します。詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

- マスター表を再編成するもう1つの方法としては、表のオンライン再定義がありますが、オンライン再定義は、マテリアライズド・ビュー・ログ、マスター・マテリアライズド・ビューおよびマテリアライズド・ビューを持つマスター表に対しては使用できません。オンライン再定義は、マテリアライズド・ビュー・ログを持たないマスター表に対して実行できます。表のオンライン再定義の詳細は、『Oracle Database管理者ガイド』を参照してください。

オブジェクト表に基づいたマテリアライズド・ビュー・ログ

オブジェクト表に対してマテリアライズド・ビュー・ログを作成できます。たとえば、次のSQL文を使用して、categories_typユーザー定義型を作成できます。

CREATE TYPE oe.category_typ AS OBJECT
(category_name           VARCHAR2(50),
category_description    VARCHAR2(1000),
category_id             NUMBER(2));
/

この型に基づいてオブジェクト表を作成するとき、オブジェクト識別子がシステム生成のものか主キーに基づいたものかを指定できます。

CREATE TABLE oe.categories_tab_sys OF oe.category_typ
(category_id    PRIMARY KEY)
OBJECT ID SYSTEM GENERATED;

CREATE TABLE oe.categories_tab_pkbased OF oe.category_typ
(category_id    PRIMARY KEY)
OBJECT ID PRIMARY KEY;

オブジェクト表に基づいてマテリアライズド・ビューを作成するときは、WITH OBJECT ID句を指定してオブジェクト識別子をロギングする必要がありますが、オブジェクト識別子が主キー・ベースの場合は、主キーもロギングされるように指定できます。

たとえば、次の文ではcategories_tab_sysオブジェクト表のマテリアライズド・ビュー・ログを作成し、オブジェクト識別子列をロギングするように指定します。

CREATE MATERIALIZED VIEW LOG ON oe.categories_tab_sys
WITH OBJECT ID;

次の文では、categories_tab_pkbasedオブジェクト表のマテリアライズド・ビュー・ログを作成し、オブジェクト識別子列とともに主キー列をロギングするように指定します。

CREATE MATERIALIZED VIEW LOG ON oe.categories_tab_pkbased
WITH OBJECT ID, PRIMARY KEY;

異なるスキーマへのマテリアライズド・ビュー・ログのインポートに関する制限事項

マテリアライズド・ビュー・ログは、DDL文で明示的に指定されたスキーマ名でエクスポートされます。そのため、マテリアライズド・ビュー・ログは、エクスポート元のスキーマとは異なるスキーマにはインポートできません。指定したスキーマのマテリアライズド・ビュー・ログを含むエクスポート・ダンプ・ファイルをインポートするために、REMAP_SCHEMAインポート・パラメータを指定するデータ・ポンプ・インポート・ユーティリティを使用してインポートを試行すると、インポート・ログ・ファイルにエラーが書き込まれ、項目はインポートされません。

マテリアライズド・ビュー・サイトのメカニズム

マテリアライズド・ビューを作成すると、そのマテリアライズド・ビューをサポートするための追加のメカニズムがマテリアライズド・ビュー・サイトで作成されます。具体的には、1つ以上の索引が作成されます。更新可能なマテリアライズド・ビューを作成する場合は、マテリアライズド・ビュー・サイトに内部トリガーとローカル・ログ(更新可能なマテリアライズド・ビュー・ログ)も作成されます。

注意:

- マテリアライズド・ビュー・サイトがマスター・マテリアライズド・ビュー・サイトの場合は、この項で説明されているメカニズムに加えて、前項で説明されているメカニズムも含まれています。詳細は、「マスター・サイトおよびマスター・マテリアライズド・ビュー・サイトのメカニズム」を参照してください。

- マテリアライズド・ビュー名のサイズの上限は30バイトです。31バイト以上の名前でマテリアライズド・ビューを作成しようとすると、エラーが戻されます。

関連項目:
図3-10「マテリアライズド・ビューのレプリケーション・オブジェクト」

索引

主キーおよびROWIDマテリアライズド・ビューのそれぞれに対して、リモート・マテリアライズド・ビュー・サイトに1つ以上の索引が作成されます。主キー・マテリアライズド・ビューの場合、索引はターゲット・マスター表またはマスター・マテリアライズド・ビューの主キーに対応し、名前に_PKが含まれます。マテリアライズド・ビュー・サイトに同じ名前の索引がすでに存在する場合は、番号が追加されます。ROWIDマテリアライズド・ビューの場合、索引はROWID列に対応し、名前にI_SNAP$_が含まれます。副問合せを使用するマテリアライズド・ビューの高速リフレッシュをサポートするために、リモート・マテリアライズド・ビュー・サイトに追加の索引が作成されることもあります。

更新可能マテリアライズド・ビュー・ログ

更新可能マテリアライズド・ビュー・ログ(USLOG$_materialized_view_name)は、高速リフレッシュ中にマテリアライズド・ビューで上書きまたは削除する行を判断するために使用されます。このログは読取り専用マテリアライズド・ビューでは作成されず、また完全リフレッシュ中にはこのログは使用されません(完全リフレッシュの場合はマテリアライズド・ビュー全体が置き換えられるためです)。

更新可能マテリアライズド・ビューとマスターとの間に競合がある場合は、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのマテリアライズド・ビュー・ログには存在しないエントリが、リフレッシュ中に更新可能マテリアライズド・ビュー・ログに残ることがあります。この場合は、更新可能マテリアライズド・ビュー・ログを使用してマテリアライズド・ビューの行が削除または上書きされます。

更新可能マテリアライズド・ビュー・ログは、次のように、書込み可能マテリアライズド・ビューの高速リフレッシュにも使用されます。

1. ユーザーが、リモート・マスターを持つ書込み可能マテリアライズド・ビューに行を挿入します。このビューは書込み可能であり更新可能ではないため、このトランザクションはマテリアライズド・ビュー・サイトの遅延トランザクション・キューには格納されません。

2. この挿入に関する情報が、更新可能マテリアライズド・ビュー・ログにロギングされます。

3. ユーザーがマテリアライズド・ビューを高速リフレッシュします。

4. 更新可能マテリアライズド・ビュー・ログの情報を使用して、挿入された行が削除されます。高速リフレッシュの完了後、マテリアライズド・ビューはマスターと同一である必要があります。このため、挿入された行を削除する必要があります。

更新可能マテリアライズド・ビュー・ログの内部トリガー

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでの内部トリガーと同じように、マテリアライズド・ビュー・サイトの内部トリガーも更新可能マテリアライズド・ビューに適用されるDMLによる変更をUSLOG$_materialized_view_nameログに記録します。読取り専用マテリアライズド・ビューではこのトリガーは作成されません。

編成メカニズム

前項で説明されているメカニズムに加えて、マテリアライズド・ビュー・サイトのマテリアライズド・ビューを編成するメカニズムが他にもいくつかあります。このメカニズムによって、マテリアライズド・ビュー・サイトと、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイト間の編成上の整合性、およびターゲット・レプリケーション・グループとのトランザクション(読取り)一貫性が保たれます。これらのメカニズムは、マテリアライズド・ビュー・グループとリフレッシュ・グループです。

マテリアライズド・ビュー・グループ

レプリケーション・システム内のマテリアライズド・ビュー・グループは、ターゲット・レプリケーション・グループにあるオブジェクトの一部または完全なコピーをマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでメンテナンスします。マテリアライズド・ビュー・グループは、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのレプリケーション・グループの境界を超えられません。図3-12は、マスター・サイトのグループAおよびグループBと、マテリアライズド・ビュー・サイトのグループAおよびグループBとの相関関係を示します。

図3-12 マテリアライズド・ビュー・グループとマスター・グループの対応

マテリアライズド・ビュー・サイトのグループA(図3-12を参照)には、マスター・サイトの対応するグループAにあるオブジェクトの一部しか含まれていません。マテリアライズド・ビュー・サイトのグループBには、マスター・サイトのグループBのオブジェクトがすべて含まれています。しかし、マテリアライズド・ビュー・サイトのグループBにマスター・サイトのグループAのオブジェクトが含まれることはありません。図3-12に示されているように、マテリアライズド・ビュー・グループの名前は、その基になるマスター・グループと同じ名前になります。たとえば、personnelマスター・グループに基づいたマテリアライズド・ビュー・グループは、personnelという名前です。

マテリアライズド・ビュー・グループは、マテリアライズド・ビュー・サイトとマスター・サイトまたはマスター・マテリアライズド・ビュー・サイト間の編成上の整合性を維持するという目的のみでなく、更新可能マテリアライズド・ビューのサポートでも必要になります。マテリアライズド・ビューがマテリアライズド・ビュー・グループに属していない場合は、読取り専用または書込み可能マテリアライズド・ビューです。

マテリアライズド・ビューのグループ所有者

マテリアライズド・ビューのグループ所有者により、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトの単一のレプリケーション・グループに基づいた複数のマテリアライズド・ビュー・グループが使用可能になります。たとえば、マテリアライズド・ビュー・サイトと同じデータベース内で複数のユーザーをサポートするには、1つのターゲット・マスター・グループに複数のマテリアライズド・ビュー・グループを作成できます。複数のマテリアライズド・ビュー・グループを作成すると、各マテリアライズド・ビュー・グループのマテリアライズド・ビュー定義に異なる副問合せを定義でき、各ユーザーは自分用のデータのサブセットのみにアクセスできます。

複数のマテリアライズド・ビュー・グループを定義すると、データ・セットをグループ・レベルで制御できるようになります。たとえば、これらの部門に対してhr、personnelおよびmanufacturingという異なるマテリアライズド・ビュー・グループを作成した場合、各部門を個々のオブジェクトとしてではなく、グループとして管理できます。たとえば、オブジェクトをグループとして削除できます。

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトの単一のレプリケーション・グループに基づいた複数のマテリアライズド・ビュー・グループを同一マテリアライズド・ビュー・サイトで使用できるようにするには、マテリアライズド・ビュー・グループを定義するときにグループ所有者を追加識別子として指定します。

グループ所有者を指定してマテリアライズド・ビュー・グループを定義した後、同じグループ所有者を定義してマテリアライズド・ビュー・オブジェクトをターゲット・マテリアライズド・ビュー・グループに追加します。グループ所有者を使用する場合は、各マテリアライズド・ビュー・オブジェクトが一意の名前を持つ必要があります。1つのマテリアライズド・ビュー・サイトに、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトの同一レプリケーション・グループに基づいたマテリアライズド・ビュー・グループが複数ある場合は、マテリアライズド・ビュー・グループのオブジェクト名に、別のマテリアライズド・ビュー・グループのマテリアライズド・ビュー・オブジェクトと同じ名前を使用することはできません。名前の競合を避けるには、オブジェクト名の最後にグループ所有者を追加します。たとえば、hrとacというグループ所有者がいる場合は、employeesマテリアライズド・ビュー・オブジェクトには、それぞれemployees_hrおよびemployees_acという名前を付けます。

また、1つのマテリアライズド・ビュー・サイトの同じレプリケーション・グループに基づいたマテリアライズド・ビュー・グループはすべて、同じマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトを指す必要があります。たとえば、hrとpersonnelにより所有されるグループが同一マテリアライズド・ビュー・サイトにあると想定して、hrにより所有されているhr_repgマテリアライズド・ビュー・グループがorc1.example.comマスター・サイトの対応するマスター・グループに基づいている場合、personnelにより所有されているhr_repgマテリアライズド・ビュー・グループも、orc1.example.comの対応するマスター・グループに基づいている必要があります。

関連項目:
レプリケーション・マネージメントAPIを使用したグループ所有者の定義方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

リフレッシュ・グループ

複数のマテリアライズド・ビュー間の参照整合性およびトランザクション(読取り)一貫性を保つために、Oracle Databaseでは、個々のマテリアライズド・ビューをリフレッシュ・グループの一部としてリフレッシュできます。リフレッシュ・グループ内のすべてのマテリアライズド・ビューのリフレッシュが終了すると、グループ内のすべてのマテリアライズド・ビューのデータはトランザクションの一貫性を保つ特定の時点のデータに対応します。

図3-13に示すように、リフレッシュ・グループには複数のマテリアライズド・ビュー・グループのマテリアライズド・ビューを含めることができるため、レプリケーション・グループ境界にまたがってトランザクション(読取り)一貫性を保つことができます。

図3-13 複数のマテリアライズド・ビュー・グループのオブジェクトを含むリフレッシュ・グループ

マテリアライズド・ビュー・グループごとに1つのリフレッシュ・グループを定義するよりも、複数のマテリアライズド・ビュー・グループのオブジェクトを含む1つの大きなリフレッシュ・グループを使用する方が効率的な場合があります。このように構成すると、マテリアライズド・ビューのリフレッシュに必要なオーバーヘッドの量が削減されます。リフレッシュ・グループには、マテリアライズド・ビューを最大400個まで含められます。

1つのマテリアライズド・ビュー・グループの内容をリフレッシュするために複数のリフレッシュ・グループを使用する構成は避けてください。複数のリフレッシュ・グループを使用して1つのマテリアライズド・ビュー・グループの内容をリフレッシュすると、マテリアライズド・ビュー・データの整合性が失われる原因となり、マテリアライズド・ビュー・サイトで参照整合性の問題が発生することがあります。このような構成は、データベース環境について十分な知識があり、参照整合性の問題の発生を回避できる場合にのみ使用してください。

リフレッシュ・グループのサイズ

リフレッシュ・グループのサイズを決定するときは、サイズの違いによるメリットとデメリットの両方を考慮する必要があります。Oracleは、大規模リフレッシュ・グループに対応できるように最適化されています。したがって、大規模リフレッシュ・グループと小規模リフレッシュ・グループを比較した場合、グループ内のマテリアライズド・ビューが類似していると想定すると、大規模リフレッシュ・グループの方が同じ数のマテリアライズド・ビューを高速にリフレッシュできます。たとえば、マテリアライズド・ビューを20ずつ含む5つのリフレッシュ・グループよりも、100のマテリアライズド・ビューを含む1つのリフレッシュ・グループの方が高速にリフレッシュできます。また、大規模リフレッシュ・グループを使用すると、1回のレプリケーション・マネージメントAPIコールで、より多くのマテリアライズド・ビューをリフレッシュできます。

リフレッシュ・グループのリフレッシュ時に、グループ内の各マテリアライズド・ビューは、マテリアライズド・ビュー・サイトでグループ内のすべてのマテリアライズド・ビューのリフレッシュが終了するまでロックされます。リフレッシュ操作中にユーザーがマテリアライズド・ビューを更新するとデータの整合性が損なわれる可能性があるので、これを回避するためにマテリアライズド・ビューのロックは必須です。したがって、リフレッシュ・グループの規模が小さいということは、リフレッシュ実行時のマテリアライズド・ビューのロック時間が短くなることを意味します。

リフレッシュの実行時は、ネットワーク接続を維持する必要があります。リフレッシュ実行時にネットワーク接続が切断または妨害されると、データベースの整合性を保つためにすべての変更がロールバックされます。したがって、ネットワーク接続を維持することが困難な場合は、リフレッシュ・グループの規模を小さくします。

アドバンスト・レプリケーションでは、NULLリフレッシュの最適化が行われます。つまり、特定のマテリアライズド・ビューの最後のリフレッシュ以降にマスター表またはマスター・マテリアライズド・ビューが変更されなかった場合、このマテリアライズド・ビューに対してマテリアライズド・ビュー・グループのリフレッシュ時に余分な時間はほとんどかかりません。

表3-3に、大規模リフレッシュ・グループと小規模リフレッシュ・グループの利点をまとめます。

表3-3 大規模リフレッシュ・グループおよび小規模リフレッシュ・グループ

大規模リフレッシュ・グループの利点

小規模リフレッシュ・グループの利点

- 同数のマテリアライズド・ビューを複数のリフレッシュ・グループに分けてリフレッシュするよりも高速にリフレッシュできます。

- マテリアライズド・ビューのロック時間が短くなります。

- 1回のレプリケーション・マネージメントAPIコールでリフレッシュできます。

- ネットワーク接続が失われたことが原因でリフレッシュ実行時に変更がロールバックされる可能性が低くなります。

リフレッシュ処理

マテリアライズド・ビューのデータは、そのマスター表またはマスター・マテリアライズド・ビューの現行のデータと常に一致しているとはかぎりません。マテリアライズド・ビューは、ある一時点(作成時またはリフレッシュ時)に存在していたデータとして、トランザクション(読取り)一貫性を保ってマスターを反映したものです。マテリアライズド・ビューのデータをマスターのデータとほぼ一致させるには、マテリアライズド・ビューを定期的にリフレッシュする必要があります。マテリアライズド・ビュー・リフレッシュは、より新しい状態のマスター表またはマスター・マテリアライズド・ビューをマテリアライズド・ビューに反映させる効果的なバッチ操作です。

更新可能マテリアライズド・ビューのリフレッシュでは、まず、マテリアライズド・ビュー・サイトの遅延トランザクションがマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにプッシュされます。次に、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータがプルされ、マテリアライズド・ビューに適用されます。

マスター表の1行は、マテリアライズド・ビューのリフレッシュとリフレッシュの間に何度も更新される場合がありますが、リフレッシュでは、その行はマテリアライズド・ビュー内で現行のデータを使用して1回のみ更新されます。たとえば、マテリアライズド・ビューの前回のリフレッシュ以降に、マスター表の1行が10回更新されても、次回のリフレッシュではマテリアライズド・ビュー内の対応する行は1度のみ更新されます。

より新しいマスター・データを反映するために、各マテリアライズド・ビューのリフレッシュ間隔およびリフレッシュ方法を決定します。たとえば、アプリケーションで頻繁に更新されるマスター表に基づいたマテリアライズド・ビューは、頻繁にリフレッシュする必要があります。これに対して、比較的静的なマスターに基づいたマテリアライズド・ビューは、あまり頻繁にリフレッシュする必要はありません。つまり、アプリケーションの特性および要件を分析して、マテリアライズド・ビューの適切なリフレッシュ間隔を判断します。

マテリアライズド・ビューのリフレッシュには、いくつかのリフレッシュ・タイプとリフレッシュ開始方法がサポートされています。

リフレッシュ・タイプ

マテリアライズド・ビューをリフレッシュするには、高速リフレッシュ、完全リフレッシュまたは強制リフレッシュのいずれかを使用できます。

完全リフレッシュ

マテリアライズド・ビューの完全リフレッシュを実行するには、マテリアライズド・ビューを管理するサーバーがマテリアライズド・ビューの定義問合せを実行します(これは基本的に、マテリアライズド・ビューを再作成する処理です)。マテリアライズド・ビューをリフレッシュするために、問合せの結果セットが現在のマテリアライズド・ビュー・データを置き換えます。完全リフレッシュはあらゆるマテリアライズド・ビューで実行できます。定義問合せを満たすデータの量によっては、完全リフレッシュの実行に高速リフレッシュの場合よりもかなり長い時間がかかる場合があります。

マスター・マテリアライズド・ビューの完全リフレッシュを実行した場合、それ以降にこのマスター・マテリアライズド・ビューに基づいたマテリアライズド・ビューに対して実行するリフレッシュは、完全リフレッシュにする必要があります。マスター・マテリアライズド・ビューが完全リフレッシュを実行した後でこのようなマテリアライズド・ビューに高速リフレッシュを実行しようとすると、次のエラーが戻されます。

ORA-12034 mview log is younger than last refresh

注意:
マテリアライズド・ビューで完全リフレッシュを実行する場合は、効率を最大化するために、PCTFREEを0に、PCTUSEDを99に設定します。

高速リフレッシュ

高速リフレッシュを実行するには、マテリアライズド・ビューを管理しているマスターが、マテリアライズド・ビューの最新リフレッシュ後にマスターに加えられた変更を識別し、その変更内容をマテリアライズド・ビューに適用します。高速リフレッシュは、関係する各サーバーおよびネットワークでレプリケートするデータが少なくて済むため、マスターに加えられた変更が少ないときは完全リフレッシュよりも効率的です。

マテリアライズド・ビューの高速リフレッシュは、マスター表またはマスター・マテリアライズド・ビューにマテリアライズド・ビュー・ログがある場合にのみ可能です。また、高速リフレッシュを完全リフレッシュより高速にするには、CREATE MATERIALIZED VIEW文の各結合列に対して索引が必要です。

SQL*Loaderを使用してマスター表またはマスター・マテリアライズド・ビューでダイレクト・パス・ロードを行うと、それ以後は高速リフレッシュを実行してもダイレクト・パス・ロード中に発生した変更は適用されません。また、マスターに対してその他のバルク・ロード操作を行った結果加えられた変更も適用されません。このような操作の例としては、APPENDヒントを指定したINSERT文と、INSERT ... SELECT * FROM文などがあります。

図3-14 マテリアライズド・ビューの高速リフレッシュ

パーティション化されたマスター表に基づくマテリアライズド・ビューがある場合、パーティション・チェンジ・トラッキング(PCT)を使用して、特定のパーティションに対応しているマテリアライズド・ビューの行を識別できます。また、PCTは、マテリアライズド・ビューのマスター表のパーティション・メンテナンス操作後、高速リフレッシュをサポートするために使用されます。マテリアライズド・ビューでのPCTに基づくリフレッシュは、様々な条件が満たされた場合のみ可能になります。

関連項目:
PCTおよびPCTに基づいたリフレッシュの詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。

更新可能な多重化マテリアライズド・ビューがある場合、多重化マテリアライズド・ビューに対して加えられたDML変更はこのマテリアライズド・ビューに複数回取り出され、マテリアライズド・ビューがリフレッシュされるたびにデータ整合性が保たれます。次に、この動作をわかりやすく説明します。

次のような特性を持つレプリケーション環境の例について考えます。

- マスター・サイトorc1.example.comにoe.customers表があります。

- レベル1のマテリアライズド・ビュー・サイトca.usに、orc1.example.comのoe.customers表に基づいたoe.customers_region更新可能マテリアライズド・ビューがあります。

- レベル2の更新可能マテリアライズド・ビュー・サイトsf.caに、ca.usのoe.customers_regionマテリアライズド・ビューに基づいたoe.customers_sf更新可能マテリアライズド・ビューがあります。

前述の内容を前提として、次のような使用例が考えられます。

1. sf.caのoe.customers_sf更新可能マテリアライズド・ビューで、顧客のcredit_limitが3000から5000に変更されました。

2. この変更が、sf.caの遅延トランザクション・キューに入れられます。

3. レベル2のマテリアライズド・ビューoe.customers_sfの高速リフレッシュにより、credit_limitの新しい値がca.usのoe.customers_regionマテリアライズド・ビューにプッシュされます。

4. この変更が、ca.usのoe.customers_regionマテリアライズド・ビューに適用されます。

5. ca.usサイトでのcredit_limitに対する更新が、レベル1のマテリアライズド・ビュー・サイトの遅延トランザクション・キューとマテリアライズド・ビュー・ログの両方に記録されます。

6. レベル2のマテリアライズド・ビューoe.customers_sfの高速リフレッシュにより、このsf.caのマテリアライズド・ビューにcredit_limitの5000という値がプルされます。

7. レベル1のマテリアライズド・ビューoe.customers_regionの高速リフレッシュにより、credit_limitの新しい値がorc1.example.comのoe.customersマスター表にプッシュされます。

8. この変更が、orc1.example.comのoe.customersマスター表に適用されます。

9. orc1.example.comサイトでのcredit_limitに対する更新が、このマスター・サイトの遅延トランザクション・キューとマテリアライズド・ビュー・ログの両方に記録されます。

10. レベル1のマテリアライズド・ビューoe.customers_regionが新しく高速リフレッシュされ、ca.usのこのマテリアライズド・ビューにcredit_limitの5000という値がプルされます。

11. ca.usサイトでのcredit_limitに対する更新が、このレベル1のマテリアライズド・ビュー・サイトのマテリアライズド・ビュー・ログに記録されます。

12. レベル2のマテリアライズド・ビューoe.customers_sfの高速リフレッシュにより、このsf.caのマテリアライズド・ビューにcredit_limitの5000という値が再度プルされます。

強制リフレッシュ

マテリアライズド・ビューの強制リフレッシュを実行するために、マテリアライズド・ビューを管理するサーバーは高速リフレッシュの実行を試みます。高速リフレッシュが実行できない場合は、完全リフレッシュが実行されます。高速リフレッシュが実行できない場合にマテリアライズド・ビューのリフレッシュを実行するには、強制リフレッシュの設定を使用します。

リフレッシュの開始

管理者は、リフレッシュ・グループを作成するときに、スケジュールした間隔でマテリアライズド・ビューを自動的にリフレッシュするようにグループを構成できます。逆に、リフレッシュ・グループを手動または必要に応じてリフレッシュするように、スケジュール情報を省略することもできます。ダイアルアップ・ネットワーク接続を使用してリフレッシュを実行する場合は、手動リフレッシュが理想的なソリューションになります。

スケジュールしたリフレッシュ

自動リフレッシュのためのリフレッシュ・グループを作成するには、作成プロセスで、スケジュールしたリフレッシュ間隔をグループに指定する必要があります。グループのリフレッシュ間隔を設定するときは、次の特性を考慮してください。

- リフレッシュ間隔を指定する日付または日付式の値は、将来の特定の時点である必要があります。

- リフレッシュ間隔は、リフレッシュの実行に必要な時間よりも長くする必要があります。

- 相対日付式の値は、最新のリフレッシュ日付から計算される特定の時点である必要があります。ネットワークまたはシステムの障害により、グループのリフレッシュがスケジュールどおりに実行されない場合、相対日付式の結果は状況に応じて変更されることがあります。

- 明示的日付式の値は、最新のリフレッシュ日付に関係なく特定の時点である必要があります。

- 古いデータに対する環境の許容度を考慮してください。許容度が低い場合はリフレッシュ間隔を小さくし、許容度が高い場合はリフレッシュ間隔を大きくします。

リフレッシュ間隔の指定に使用できる単純な日付式の例を、次に示します。

- 1時間間隔の指定:

SYSDATE + 1/24

- 7日間隔の指定:

SYSDATE + 7

関連項目:
日付算術の詳細は、『Oracle Database管理者ガイド』および『Oracle Database SQL言語リファレンス』を参照してください。

必要に応じたリフレッシュ

環境や状況によっては、スケジュールしたマテリアライズド・ビュー・リフレッシュの実行が適切でない場合もあります。たとえば、マスター表にバルク・データをロードした直後は、依存マテリアライズド・ビューにマスター表のデータは反映されていません。次に実行予定の自動グループ・リフレッシュを待たずに、対応付けられたマテリアライズド・ビューにマスター表の新規行をすぐに伝播するために、依存マテリアライズド・ビュー・グループを手動でリフレッシュすることもできます。

マテリアライズド・ビューが非接続環境のラップトップの営業支援システムと統合されている場合は、マテリアライズド・ビューを必要に応じてリフレッシュすることもできます。営業支援ソフトウェアを設計する開発者がアプリケーション・コントロール(ボタンなど)を作成し、営業担当員は、1日の受注をサーバーに転送するときに、ダイアルアップ・ネットワーク接続を確立し、アプリケーション・コントロールを使用してマテリアライズド・ビューをリフレッシュできます。

hr_refgリフレッシュ・グループを必要に応じてリフレッシュする例を次に示します。

EXECUTE DBMS_REFRESH.REFRESH('hr_refg');

注意:
レプリケーション環境で使用されているマテリアライズド・ビューのリフレッシュに、DBMS_MVIEW.REFRESH_ALL_MVIEWSまたはDBMS_MVIEW.REFRESH_DEPENDENTプロシージャを使用しないでください。かわりに、DBMS_REFRESH.REFRESHまたはDBMS_MVIEW.REFRESHプロシージャを使用してください。

制約およびリフレッシュ

マテリアライズド・ビューのリフレッシュ中の整合性制約違反を回避するために、各マテリアライズド・ビューの主キー以外の整合性制約を遅延可能にします。これには、NOT NULL制約を持つLOB列が必要です。また、外部キー制約によって関連付けられているすべてのマテリアライズド・ビューは、まとめてリフレッシュするか、同じリフレッシュ・グループでリフレッシュする必要があります。

注意:

- マテリアライズド・ビューの主キー制約は、遅延可能である場合とない場合があります。

- 更新可能マテリアライズド・ビューとともに使用するDELETE CASCADE制約は、遅延可能である必要があります。

関連項目:
制約を遅延可能にする方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

4 デプロイメント・テンプレートの概要およびアーキテクチャ

この章では、デプロイメント・テンプレートの概要と、デプロイメント・テンプレートを使用して簡単かつ効率的にマテリアライズド・ビュー・サイトを配布する方法について説明します。

この章には、次の項が含まれます。

- 大規模デプロイメントの課題

- Oracleデプロイメント・テンプレートの概念

- デプロイメント・テンプレートのアーキテクチャ

- デプロイメント・テンプレートの設計

- マテリアライズド・ビュー作成のローカル制御

注意:
デプロイメント・テンプレートを作成する前に、第3章「マテリアライズド・ビューの概要とアーキテクチャ」を読んでください。マテリアライズド・ビューについての理解は、デプロイメント・テンプレートを作成する際に役立ちます。

大規模デプロイメントの課題

Oracleデプロイメント・テンプレートは、広範囲に分散したマテリアライズド・ビュー環境を効率的にデプロイし、管理するためのツールです。デプロイメント・テンプレートの概念、アーキテクチャおよび使用方法について説明する前に、大規模デプロイメントの環境の課題について検討します。

時と場所を問わず正確な情報を入手する必要性は、ますます強くなっています。また、情報は分散し、ユーザーもネットワークに接続されていない環境にいることが多く、実際に利用する場所に情報を配布する必要があります。

たとえば、モバイル端末を使用する営業担当員の場合を考えます。正確な顧客情報をラップトップ上で自由自在に参照したいと考えている営業担当員の数は、数百名あるいは数千名にも及ぶ可能性があります。これに応えるため、データベース管理者は、データおよびデータベース・インフラストラクチャ(表、索引、制約、トリガーなど)を適切なタイミングで効率よくすべてのサイトに提供する必要があります。

これまでDBAは、独自のデプロイ方法を開発する必要がありました。一般に、DBAは、リモート・マテリアライズド・ビュー・サイトにマテリアライズド・ビュー環境を作成するための非常に複雑なスクリプトを作成する必要がありました。さらに、それに加えて、DBAはデータ・セットをマテリアライズド・ビュー・サイトでカスタマイズすることが必要な場合もありました。スクリプトを作成した後も、スクリプトをデプロイするために手動でパッケージ化し、実装する必要があり、多くの場合その両方に多大なトラブルシューティングが必要でした。

このような問題点をもとに、効率的な大規模デプロイメントを行うための新しいテクノロジとリソースが生まれました。大規模デプロイメントとは、データベース・インフラストラクチャ、データおよびフロントエンド・アプリケーションを多数のユーザーに配布するプロセスのことです。アドバンスト・レプリケーションでは、大規模デプロイメントという用語はデータおよびデータ・インフラストラクチャの配布のみを指します。

デプロイメント・テンプレートおよび大規模デプロイメントの目標

大規模デプロイメントのツールおよびテクノロジは、データおよびデータベース・インフラストラクチャを配布するデータベース管理者を支援する必要があります。デプロイメント・テンプレートの目標は、一度定義した環境をもとに必要な数のデプロイメント・テンプレートのインスタンスを作成し、個々のサイトでカスタマイズを行えるようにすることです。

この目標を実現するために、Oracleのデプロイメント・テンプレートでは次のことが可能です。

1回のマテリアライズド・ビュー環境の定義

デプロイメント・テンプレートを使用してマテリアライズド・ビュー環境の構造を1回定義することにより、各ユーザー(サイト)がフロントエンド・アプリケーションをサポートするデータベース・インフラストラクチャを利用できるようにします。

個別のマテリアライズド・ビュー・サイトのカスタマイズ

デプロイメント・テンプレートのパラメータを使用して各マテリアライズド・ビュー環境をカスタマイズし、各ユーザーが必要な特定のデータ・サブセットを受信できるようにします。

大規模デプロイメントには、モバイル端末を使用する営業担当員やサービス技術員、小売店、リモートの在庫保管サイトなどへの情報の配布といった様々な用途があります。このような環境では、デプロイメント・テンプレートを使用してリモート・サイトにデータベース・インフラストラクチャを作成しますが、これは主に、デプロイメント・テンプレートがデータのサブセット化、非接続環境でのレプリケーション、および少ないリソース要件をサポートしているからです(これはラップトップ・ユーザーに最適です)。

Oracleデプロイメント・テンプレートの概念

データベース管理者は、Oracleから提供されているデプロイメント・テンプレートを使用して、マテリアライズド・ビュー環境をパッケージ化し、安全性の高いカスタム・デプロイを簡単に実行できます。デプロイメント・テンプレートのパッケージ化とは、デプロイメント・テンプレートにより作成されるマテリアライズド・ビュー環境を定義するプロセスです。デプロイメント・テンプレートのパッケージ化により、テンプレートをリモート・マテリアライズド・ビュー・サイトでインスタンス化する準備が整います。インスタンス化によって、マテリアライズド・ビュー・サイトのオブジェクトが作成され、マテリアライズド・ビューにデータが移入されます。

デプロイメント・テンプレートには、固定データ・セットを使用する1つのマテリアライズド・ビューのみを含む単純なものも、1つ以上の変数に基づく動的データ・セットを使用する数百のマテリアライズド・ビューを含む複雑なものもあります。デプロイメント・テンプレートには、次の機能があります。

- 集中制御

- マテリアライズド・ビュー環境を繰り返しデプロイする機能

- リモート・サイトでのデータのサブセット化およびカスタマイズを可能にする、テンプレート・パラメータ

- テンプレートのインスタンス化およびデータ・アクセスを制御する、認証ユーザー・リスト

マテリアライズド・ビュー環境をデプロイするには、その前にマスター・サイトにデプロイメント・テンプレートを作成します。このテンプレートには、リモート・サイトのオブジェクトやターゲット・リフレッシュ・グループを作成するデータ定義言語(DDL)など、マテリアライズド・ビュー環境をデプロイするために必要なすべての情報を格納します。また、このテンプレートには、ユーザーのセキュリティ情報へのリンクや、カスタム・マテリアライズド・ビュー作成のためのテンプレート・パラメータも格納します。

この項には、次の項目が含まれます。

- デプロイメント・テンプレートおよび大規模デプロイメントの目標

- デプロイメント・テンプレートの要素

- デプロイメント・テンプレートのパッケージ化とインスタンス化

デプロイメント・テンプレートの要素

各デプロイメント・テンプレートには、マテリアライズド・ビュー・サイトに必要なマテリアライズド・ビューおよびそれに関連するオブジェクトを作成するための設計図を含めます。具体的には、デプロイメント・テンプレートをマスター・サイトに作成し、マテリアライズド・ビュー環境を作成するために必要なマテリアライズド・ビュー、トリガー、ビューなどをこのデプロイメント・テンプレートに追加します。また、オプションでテンプレート・パラメータや認証ユーザーを定義して、インスタンス化プロセス実行時の柔軟性や安全性を大幅に向上させることもできます。

デプロイメント・テンプレートの要素は、次の4つのカテゴリに分類できます。

- テンプレート一般情報

- テンプレートのオブジェクト定義

- テンプレート・パラメータ

- ユーザー認証

テンプレート一般情報

テンプレート名、ターゲット・リフレッシュ・グループ、およびプライベートまたはパブリックの状態から構成されるテンプレート一般情報は、Oracleデプロイメント・テンプレートで使用される情報です。図4-1に示すように、REFRESH_TEMPLATE_NAMEは、デプロイメント・テンプレートのデータ・ディクショナリ・ビューのどの場面でも使用します。マテリアライズド・ビュー環境のオブジェクトをテンプレートに追加し、その後、指定されたテンプレートの識別に応じて配布するテンプレートをリリースします(図4-2を参照してください)。

デプロイメント・テンプレートは、1つのマスター・サイトで定義します。マスター・サイトに同じ名前のデプロイメント・テンプレートを2つ定義することはできませんが、デプロイメント・テンプレートを同じ名前で他のサイトにコピーすることはできます。

図4-1 デプロイメント・テンプレートのビューの関係

図4-2 デプロイメント・テンプレートに追加するテンプレートの要素

テンプレートのオブジェクト定義

デプロイメント・テンプレートを定義した後で、テンプレートにオブジェクトを追加します。テンプレートがマテリアライズド・ビュー・サイトでインスタンス化されると、オブジェクトDDL(CREATE MATERIALIZED VIEW、CREATE TABLEなど)が実行され、適切なオブジェクトがマテリアライズド・ビュー・サイトに作成されます。

デプロイメント・テンプレートには既存のマスター・オブジェクトに基づいたオブジェクトを追加できますが、必要な場合は、DDLを定義し、テンプレート・オブジェクトを作成してオブジェクトを作成することもできます。新しいオブジェクトDDLを作成した場合は、実行エラーを防ぐためにDDLが字句規則に適合しているかどうかのチェックが行われます。デプロイメント・テンプレートに追加する更新可能マテリアライズド・ビューはマスター・グループ内の表に基づいている必要がありますが、読取り専用マテリアライズド・ビューなどのその他のオブジェクトは、マスター・グループに属していないオブジェクトに基づいていてもかまいません。

通常、テンプレートにはマテリアライズド・ビューを追加しますが、必要な場合はその他のオブジェクトも追加できます。たとえば、マテリアライズド・ビュー・サイトでのデータ整合性を規定するための制約、データ表示のためのビュー、ローカルなデータ記憶域に格納するための表などを追加できます。場合によっては、デプロイメント・テンプレートにアプリケーションのすべてのオブジェクトを含めることもできます。デプロイメント・テンプレートを使用して作成したマテリアライズド・ビューは、テンプレートに定義されたリフレッシュ・グループに自動的に追加されます。

デプロイメント・テンプレートを使用してインスタンス化できないオブジェクト型は、次のとおりです。

- ユーザー定義型

- ユーザー定義型の本体

- ユーザー定義演算子

- 索引タイプ

デプロイメント・テンプレートを使用して、これらのオブジェクト型に基づいたオブジェクトをインスタンス化することもできません。

関連項目:
リフレッシュ・グループの詳細は、「テンプレート一般情報」を参照してください。

テンプレート・パラメータ

各ターゲット・マテリアライズド・ビュー・サイトで一意のデータ・セットが必要な場合は、オブジェクトDDLで変数を定義できます。変数を定義してパラメータ付きテンプレートを作成すると、テンプレートをインスタンス化するときにカスタム・データ・セットを使用できるため、マテリアライズド・ビュー・サイトごとに異なるデータ・セットを使用できます。これらのパラメータは、オブジェクトDDLに組み込まれます。テンプレートのインスタンス化時に、個別のユーザー値がパラメータに代入されます。

Oracleでは、テンプレートにデフォルト値およびユーザー固有のパラメータ値を指定できます。パラメータ値は、デプロイメント・テンプレートの作成時または作成後に指定できますが、テンプレートをインスタンス化する前に指定する必要があります。テンプレートのインスタンス化時にパラメータの値を指定することはできません。

ユーザー固有のパラメータ値を使用した場合は、指定されたユーザーがテンプレートをインスタンス化するときにそのパラメータ値が自動的に使用されます。たとえば、変数regionについて考えます。テンプレートsales_tempに対して次のようなユーザー固有のパラメータ値を指定したとします。

ユーザー

地域

fay

east

baer

west

この場合、マテリアライズド・ビューの定義SELECT文は次のようになります。

SELECT cust_id, sales_to_date, status FROM table_x WHERE region_id=:region;

ユーザーfayおよびbaerがテンプレートsales_tempをインスタンス化すると、作成されるマテリアライズド・ビュー・データ・セットは次のようになります。

ユーザーfay

-

ユーザーbaer

cust_id

地域

-

cust_id

地域

a123

east

-

b123

west

a234

east

-

b234

west

a345

east

-

b345

west

a456

east

-

b456

west

WHERE句のテンプレート・パラメータとセキュリティ

カスタマイズしたデータ・サブセットを作成する他に、CREATE MATERIALIZED VIEW文のWHERE句でテンプレート・パラメータを指定して、マテリアライズド・ビュー・サイトではWHERE句の条件を満たすデータのみを表示および変更するようにできます。たとえば、ユーザー固有のパラメータ・リストのregionパラメータに次のように指定したとします。

ユーザー

地域

fay

east

baer

west

ユーザーfayがインスタンス化したマテリアライズド・ビューにアクセスするユーザーは、地域eastのデータのみを参照でき、このWHERE句に適合するデータのみを表示、更新または削除できます。つまり、このマテリアライズド・ビューには地域eastのデータしか含まれていないため、このマテリアライズド・ビューのユーザーは地域westのデータを表示、更新または削除できません。

ユーザー認証

デプロイメント・テンプレートは、パブリックまたはプライベートのいずれかとして定義できます。これは、テンプレートの作成時に設定します。パブリック・テンプレートは、マスター・サイトへのアクセス権を持つすべてのユーザーがインスタンス化できます。

テンプレートがプライベート用として作成されている場合は、認証ユーザーのみがターゲット・テンプレートをインスタンス化できます。プライベート用として規定する場合は、マスター・サイトに認証されたユーザーのリストを作成します。認証されていないユーザーがターゲット・テンプレートをインスタンス化しようとすると、そのインスタンス化プロセスは失敗します。

デプロイメント・サイト

集中制御の目的で、リモート・マテリアライズド・ビュー・サイトでインスタンス化された環境の特性の一部を監視および管理できます。具体的には、デプロイメント・テンプレートをインスタンス化したサイトを監視できます(デプロイメント・テンプレート名、認証ユーザーおよびインスタンス化された環境の状態を含みます)。

デプロイメント・テンプレートのパッケージ化とインスタンス化

デプロイメント・テンプレートの定義が完了した後で、テンプレートをパッケージ化して、リモート・マテリアライズド・ビュー・サイトでインスタンス化できます。パッケージ化したデプロイメント・テンプレートがマテリアライズド・ビュー・サイトでインスタンス化されると、マテリアライズド・ビュー・サイト・オブジェクトが作成され、マテリアライズド・ビューにデータが移入されます。リモート・マテリアライズド・ビュー・サイトは、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションのいずれかを使用して作成できます。

オンライン・インスタンシエーション

オンライン・インスタンシエーションでは、マテリアライズド・ビュー・サイトはターゲット・マスター・サイトに接続した状態でデプロイメント・テンプレートをインスタンス化できます。オンライン・インスタンシエーション・プロセスでは、マテリアライズド・ビュー・サイトの構造が作成され、指定したデータ・サブセットがマスター・サイトから取り出されて適切なマテリアライズド・ビューに格納されます。

図4-3 オンライン・インスタンシエーション

オンライン・インスタンシエーション用のデプロイメント・テンプレートのパッケージ化は、スクリプト・ファイルの生成を意味し、このスクリプト・ファイルがマテリアライズド・ビュー・サイトで実行されると、マテリアライズド・ビュー・オブジェクトが作成された後にマスター・サイトに接続され、マテリアライズド・ビューにデータが移入されます。マスター・サイトからネットワーク経由でマテリアライズド・ビューにデータを移入するには、CREATE MATERIALIZED VIEW ... AS SELECTなどのSQL文を使用します。

オンライン・インスタンシエーションのメリットの1つは、データ・サブセットがインスタンス化プロセス実行時点の最新の状態である点です。ただし、これにはデメリットもあります。オンライン・インスタンシエーションの実行中はマテリアライズド・ビュー・サイトとマスター・サイトが接続されている必要があるため、作成するマテリアライズド・ビュー環境のサイズによっては、ネットワークの通信量が増大する可能性があります。

また、モデム接続を使用しているラップトップ・ユーザーは、接続時間が長くなることがあります。接続時間は、作成されるオブジェクトの数、マテリアライズド・ビューの副問合せの複雑さ、送信されるデータの量によって変わり、低帯域幅のモデムで接続している場合、これらの要素による影響は特に大きくなります。

オフライン・インスタンシエーション

ピーク使用期間中のサーバー負荷を小さくし、リモートの接続時間を短縮するには、使用環境のテンプレートのオフライン・インスタンシエーションを選択します。オフライン・インスタンシエーション用のテンプレートのパッケージ化は、DDLおよびデータ操作言語(DML)を含むスクリプトまたはバイナリ・ファイルの生成を意味し、このスクリプトまたはバイナリ・ファイルによって、デプロイメント・テンプレートに定義したマテリアライズド・ビュー環境が作成され、データが移入されます。スクリプトまたはバイナリ・ファイルをパッケージ化してストレージ・メディア(テープ、CD-ROMなど)に保存し、マテリアライズド・ビュー・サイトに転送する方法を提供します。各マテリアライズド・ビュー・サイトで、それぞれのオフライン・インスタンシエーション・スクリプトが必要です。

インスタンス化用のテンプレートをパッケージ化すると、マテリアライズド・ビューの基になっているテンプレートの各マスター表のマテリアライズド・ビュー・ログに対して、変更のロギングが開始されます。特定のマスター表のマテリアライズド・ビュー・ログに記録された変更内容は、マスター表に基づくすべてのマテリアライズド・ビューがインスタンス化後にリフレッシュされるまで消去されません。したがって、テンプレートをパッケージ化した後で、テンプレートのインスタンス化とマテリアライズド・ビューのリフレッシュをできるだけ早く実行して、マテリアライズド・ビュー・ログが大きくなりすぎないようにする必要があります。

インスタンス化時は、テンプレートとデータがマスター・サイトではなくストレージ・メディアからプルされます。この操作により、ネットワークの通信量を軽減でき、ネットワークに常時接続する必要がなくなります。ただし、インスタンス化後は、マテリアライズド・ビュー・サイトにはパッケージ化した時点のマスター・サイトのデータが反映されているので、リフレッシュによって更新する必要があります。

図4-4 オフライン・インスタンシエーション

オフライン・インスタンシエーションは、多数のラップトップやその他の非接続環境のコンピュータでターゲット・テンプレートをインスタンス化する大規模デプロイメントに最適なソリューションです。

多重化マテリアライズド・ビューのオフライン・インスタンシエーション

デプロイメント・テンプレートのオフライン・インスタンシエーションを使用してマテリアライズド・ビュー・サイトを作成すると、マスター表に定義されている競合解消方法がマテリアライズド・ビュー・サイトにプルされません。このマテリアライズド・ビュー・サイトに基づいてマテリアライズド・ビュー(多重化マテリアライズド・ビュー)を作成する場合は、データ整合性を保つためにこれらの競合解消方法が必要になることがあります。オンライン・インスタンシエーションを使用すると、インスタンス化中に競合解消方法がプルされます。

デプロイメント・テンプレートのインスタンス化の使用例

表4-1に、デプロイメント・テンプレートのインスタンス化の使用例の概要を示します。

表4-1 デプロイメント・テンプレートのインスタンス化の使用例

インスタンス化のタイプ

説明

オフライン

ユーザーは、SQL*Plusを使用してオフライン・インスタンシエーション・スクリプトを実行します。オフライン・インスタンシエーション・スクリプトには、マテリアライズド・ビュー・サイトのオブジェクトを作成するCREATE文と、マテリアライズド・ビューにデータを移入するINSERT文が含まれます。

オンライン

ユーザーは、SQL*Plusを使用してオンライン・インスタンシエーション・スクリプトを実行します。オンライン・インスタンシエーション・スクリプトには、マテリアライズド・ビュー・サイトのオブジェクトを作成するCREATE文が含まれます。マテリアライズド・ビュー・オブジェクトが作成されると、オンライン・インスタンシエーション・スクリプトがマスター・サイトに接続し、CREATE MATERIALIZED VIEW ... AS SELECT文を使用してマテリアライズド・ビューを作成し、これにデータを移入します。

DBAまたはターゲット・ユーザーのいずれかが、デプロイメント・テンプレートをパッケージ化できます。デプロイメント・テンプレートをパッケージ化するには、アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザード(オフライン・インスタンシエーションの場合)またはレプリケーション・マネージメントAPI(オフラインまたはオンライン・インスタンシエーションの場合)を使用します。デプロイメント・テンプレートをパッケージ化するには、エンド・ユーザーはパブリックAPIを使用し、DBAは一般的にプライベートAPIを使用します。

通常、デプロイメント・テンプレートをオフラインでインスタンス化する場合はDBAがパッケージ化を実行しますが、デプロイメント・テンプレートをオンラインでインスタンス化する場合はユーザーがパッケージ化を実行する可能性があります。ただし、ユーザーまたはDBAにとっては使用するAPIコールが異なること以外に制約はなく、どちらもオンラインまたはオフラインによるパッケージ化を実行できます。

デプロイメント・テンプレートをパッケージ化するには、次のレプリケーション・マネージメントAPIのファンクションを使用できます。

プライベート・ファンクション(DBAのみ使用):

- DBMS_REPCAT_RGT.INSTANTIATE_OFFLINEファンクション

- DBMS_REPCAT_RGT.INSTANTIATE_ONLINEファンクション

パブリック・ファンクション:

- DBMS_REPCAT_INSTANTIATE.INSTANTIATE_OFFLINEファンクション

- DBMS_REPCAT_INSTANTIATE.INSTANTIATE_ONLINEファンクション

注意:
オフライン・インスタンシエーション用のデプロイメント・テンプレートをパッケージ化すると、関連するマテリアライズド・ビュー・ログにより、テンプレートにパッケージ化したマテリアライズド・ビューのロギングが開始されます。この即時ロギングによって、マテリアライズド・ビュー・サイトでオフライン・インスタンシエーション完了後に高速リフレッシュを実行できます。オフライン・インスタンシエーションの実行後、マテリアライズド・ビュー・ログを監視して、リモート・マテリアライズド・ビュー・サイトのリフレッシュが迅速に実行されていることを確認してください。テンプレートをパッケージ化するときにロギングが開始されるため、リモート・マテリアライズド・ビュー・サイトがリフレッシュされないとマテリアライズド・ビュー・ログが大きくなりすぎることがあります。

関連項目:
「デプロイメント・テンプレートをインスタンス化するマテリアライズド・ビュー・サイトの準備」を参照してください。ファンクションの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

デプロイメント・テンプレートのアーキテクチャ

Oracleでは、マテリアライズド・ビュー環境を迅速かつ効率的に配布するために、デプロイメント・テンプレートに標準マテリアライズド・ビュー・アーキテクチャを使用しています。デプロイメント・テンプレートでは、マテリアライズド・ビュー定義の作成、リフレッシュ特性、競合解消およびグループ化に、マテリアライズド・ビュー環境を手動で作成する場合と同じ方法を使用します。ただし、デプロイメント・テンプレートではDDLを実行してオブジェクトを即時に作成するのではなく、テンプレートをインスタンス化するときに、デプロイメント・テンプレートに含まれるオブジェクトDDLが実行される点が異なります。

この項には、次の項目が含まれます。

- システム表に格納されたテンプレート定義

- パッケージ化およびインスタンス化のプロセス

- インスタンス化の結果

システム表に格納されたテンプレート定義

デプロイメント・テンプレートでは、マテリアライズド・ビュー・サイトでDDLを実行してマテリアライズド・ビュー環境を即時に作成するのではなく、マテリアライズド・ビューおよび関連するオブジェクト定義がデプロイメント・テンプレートに格納されます。すべてのオブジェクト定義をデプロイメント・テンプレートに追加した後、テンプレートをインスタンス化すると、格納されているすべてのDDLがリモート・マテリアライズド・ビュー・サイトで実行され、必要なマテリアライズド・ビュー環境が作成されます。

これらのオブジェクト定義はすべて、デプロイメント・テンプレートの定義サイトにあるシステム表に、デプロイメント・テンプレート名をキーにして格納されます。デプロイメント・テンプレートをパッケージ化すると、格納されているオブジェクトDDLがシステム表からプルされ、バイナリ・ファイルのインスタンス化スクリプトが作成されます。

標準DDLの使用

テンプレートのオブジェクト定義は、マテリアライズド・ビュー・サイトでローカルにオブジェクトを作成する場合と同じDDLを使用して作成されます。たとえば、次の文を発行するとマテリアライズド・ビューが作成されます。

CREATE MATERIALIZED VIEW hr.departments_mv
REFRESH FAST WITH PRIMARY KEY FOR UPDATE AS SELECT
department_id, department_name, manager_id, location_id
FROM hr.departments@orc1.example.com;

これと同じマテリアライズド・ビューをデプロイメント・テンプレートに追加するには、アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザードを使用するか、次の例に示すようにCREATE_TEMPLATE_OBJECTファンクションを使用します。

DECLARE
tempstring VARCHAR2(3000);
a NUMBER;
BEGIN
tempstring := 'CREATE MATERIALIZED VIEW hr.departments_mv
REFRESH FAST WITH PRIMARY KEY FOR UPDATE AS SELECT
department_id, department_name, manager_id, location_id
FROM hr.departments@orc1.example.com';
a := DBMS_REPCAT_RGT.CREATE_TEMPLATE_OBJECT (
refresh_template_name => 'hr_refg_dt',
object_name => 'departments_mv',
object_type => 'MATERIALIZED VIEW',
ddl_text => tempstring,
master_rollback_seg => 'rbs');
END;
/

注意:
ddl_textパラメータの一重引用符で囲まれたDDL文の末尾には、セミコロンを付けないでください。

このファンクションを実行すると、dt_mviewenvという名前のデプロイメント・テンプレートにマテリアライズド・ビュー定義が追加されます。このマテリアライズド・ビューがインスタンス化されると、マテリアライズド・ビューmview_testが作成されます。マテリアライズド・ビューを作成するのみでなく、表、トリガー、プロシージャ、索引およびその他のオブジェクト定義をデプロイメント・テンプレートに追加できます。

マテリアライズド・ビューを作成するときは、マテリアライズド・ビューの問合せで表所有者のスキーマ名を必ず指定してください。前述の例では、employees表の所有者にhrが指定されています。

関連項目:
このファンクションの使用方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』の「DBMS_REPCAT_RGT.CREATE_TEMPLATE_OBJECT」を参照してください。

パッケージ化およびインスタンス化のプロセス

リモート・マテリアライズド・ビュー・サイトでのインスタンス化用にデプロイメント・テンプレートをパッケージ化するときは、オンライン・インスタンシエーション用とオフライン・インスタンシエーション用のテンプレートを用意します。インスタンス化プロシージャによって、リモート・マテリアライズド・ビュー環境が作成され、その環境にデータが移入されます。

オンライン・インスタンシエーション用のデプロイメント・テンプレートのパッケージ化

オンライン・インスタンシエーション用にデプロイメント・テンプレートをパッケージ化すると、リモート・マテリアライズド・ビュー環境の作成に必要なDDLが生成され、すべてのテンプレート・パラメータが代入されます。生成されたDDLが格納される場所は、マテリアライズド・ビュー・クライアントのタイプによって異なります。

オンライン・インスタンシエーション・スクリプトは、テンプレートをパッケージ化するレプリケーション・マネージメントAPIが実行されるコンピュータのハード・ドライブ上にローカルに格納されます。このコンピュータがマテリアライズド・ビュー・サイトのコンピュータでない場合は、オンライン・インスタンシエーション・ファイルをマテリアライズド・ビュー・サイトに転送する必要があります。

オフライン・インスタンシエーション用のデプロイメント・テンプレートのパッケージ化

オフライン・インスタンシエーション用にデプロイメント・テンプレートをパッケージ化するときに、リモート・マテリアライズド・ビュー環境の作成に必要なDDLとマテリアライズド・ビュー環境へのデータの移入に必要なDMLを、生成したファイルに格納します。また、パッケージ化の最中に、すべてのテンプレート・パラメータの代入が実行されます。

テンプレートをパッケージ化するときに、オフライン・インスタンシエーション用のスクリプトまたはバイナリ・ファイルを作成し、ハード・ディスク、CD-ROM、テープなどのストレージ・デバイスに保存します。オフライン・インスタンシエーション用のデプロイメント・テンプレートをパッケージ化するには、アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザードまたはレプリケーション・マネージメントAPIを使用します。

オフライン・インスタンシエーション・スクリプトは、テンプレートをパッケージ化する要求が発行されるコンピュータのハード・ドライブ上にローカルに格納されます。このコンピュータがマテリアライズド・ビュー・サイトのコンピュータでない場合は、オフライン・インスタンシエーション・ファイルをマテリアライズド・ビュー・サイトに転送する必要があります。

リモート・マテリアライズド・ビュー・サイトでテンプレートをインスタンス化するときは、ストレージ・メディアまたはローカルのハード・ドライブからスクリプトまたはバイナリ・ファイルが実行されます。これにより、マテリアライズド・ビュー環境が作成され、パッケージ作成プロセスで定義したデータ・セットが環境に移入されます。前述のように、個々のサイト用のデータ・セットを定義するテンプレート・パラメータはすべて、パッケージ作成プロセスで定義します。

オンライン・インスタンシエーション

オンライン・インスタンシエーション・プロセスでは、マテリアライズド・ビュー・サイトの構造が作成され、指定したデータ・サブセットがマスター・サイトから取り出されて適切なマテリアライズド・ビューに格納されます。リモート・マテリアライズド・ビュー・サイトでオンライン・インスタンシエーション・プロセスを開始すると、デプロイメント・テンプレート用に定義したパラメータが評価されます。パラメータに定義した値は、テンプレートのオブジェクトDDLを実行するときに、リモート・マテリアライズド・ビュー・サイトにカスタム・データ・セットをインストールするために使用されます。同時に、マテリアライズド・ビューがマスター・サイトに登録され、マテリアライズド・ビュー・ログにマスター表への変更のロギングが開始されます。

テンプレート・パラメータの値を定義するには、デフォルト・パラメータ値とユーザー・パラメータ値という2つの方法を使用できます。Oracleはこれらのパラメータ値が存在するかどうかをチェックし、次の順に使用します。

1. ユーザー・パラメータ値

2. デフォルト・パラメータ値

ユーザー・パラメータ値が定義してあり、リストに含まれているユーザーがテンプレートをインスタンス化する場合、テンプレートをインスタンス化するときにユーザー・パラメータ値が使用されます。ユーザー・パラメータ値を定義していない場合は、デフォルト・パラメータ値が使用されます。図4-5は、パラメータのチェック・プロセスを示します。

図4-5 オンライン・インスタンシエーション時のパラメータのチェック

パラメータのチェックが終わると、テンプレートによって作成されたオブジェクトが、テンプレートの作成時に指定したリフレッシュ・グループに追加されます。

オフライン・インスタンシエーション

大規模デプロイメントの環境では、ほとんどのマテリアライズド・ビュー環境でオフライン・インスタンシエーションを使用して、必要なマテリアライズド・ビュー環境を作成します。デプロイメント・テンプレートをパッケージ化すると、スクリプトまたはバイナリ・ファイルが作成され、マテリアライズド・ビュー環境の作成に必要なDDL、インスタンス化プロセスで使用されるパラメータ値およびマテリアライズド・ビュー環境へのデータの移入に必要なDMLが格納されます。

スクリプトまたはバイナリ・ファイルは、CD-ROMやフロッピィ・ディスクなどのストレージ・メディアにコピーしたり、WebサイトやFTPサイトに保存してリモート・マテリアライズド・ビュー・サイトにダウンロードしたりできます。また、DBMS_FILE_TRANSFERパッケージを使用して転送することもできます。このような柔軟な配布メカニズムによって、管理者とユーザーは最も効率的な方法でデプロイメント・テンプレートをインスタンス化できます。

パッケージ化およびインスタンス化のオプション

デプロイメント・テンプレートのパッケージ化とインスタンス化には、様々なオプションがあります。表4-2では、それらのオプションおよびパッケージ化とインスタンス化のメカニズムについて説明し、操作を実行するときに使用するドキュメントを示しています。

表4-2 パッケージ化およびインスタンス化のオプション

インスタンス化のタイプ

テンプレートのパッケージ化に使用するもの

パッケージ化に関するドキュメント

テンプレートのインスタンス化に使用するもの

インスタンス化に関するドキュメント

オフライン

アドバンスト・レプリケーション・インタフェースの「配置テンプレートの作成」ウィザード

アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照。

オフライン・インスタンシエーション・スクリプトおよびSQL*Plus

アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照。

オフライン

レプリケーション・マネージメントAPI(PL/SQLパッケージおよびSQL*Plus)

『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のパッケージ化に関する説明を参照。

オフライン・インスタンシエーション・スクリプトおよびSQL*Plus

『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のデプロイメント・テンプレートのインスタンス化に関する説明を参照。

オンライン

レプリケーション・マネージメントAPI(PL/SQLパッケージおよびSQL*Plus)

『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のパッケージ化に関する説明を参照。

オンライン・インスタンシエーション・スクリプトおよびSQL*Plus

『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のデプロイメント・テンプレートのインスタンス化に関する説明を参照。

インスタンス化の結果

リモート・マテリアライズド・ビュー・サイトでデプロイメント・テンプレートのインスタンス化を実行すると、マテリアライズド・ビュー・サイトでローカルにマテリアライズド・ビュー環境を作成した場合と同じ構造が作成されます。具体的には、指定した名前でマテリアライズド・ビューが作成され、制約整合性を保つために主キーに基づいて索引が作成されます。また、テンプレートのその他のオブジェクトも、マテリアライズド・ビューで手動で作成した場合と同じように作成されます。

オフライン・インスタンシエーションの場合は、サーバーでパッケージ化してからリモート・マテリアライズド・ビュー・サイトでインスタンス化するまでの時間が長くなると、インスタンス化後の最初のリフレッシュに必要な時間も長くなります。マテリアライズド・ビュー・サイトでは、マスター・サイトのマテリアライズド・ビュー・ログを使用して、テンプレートがパッケージ化された時点以降の高速リフレッシュを実行します。前述のように、マスター表に対して行った変更は、デプロイメント・テンプレートをパッケージ化するとただちにマテリアライズド・ビュー・ログに記録されます。

関連項目:
詳細は、「マテリアライズド・ビューのアーキテクチャ」を参照してください。

マテリアライズド・ビュー・グループ

インスタンス化したデプロイメント・テンプレートによって作成されたオブジェクトは、オブジェクトのマスター・グループ名と同じ名前のマテリアライズド・ビュー・グループに自動的に追加されます。たとえば、マスター・グループpersonnelおよびtechnicalのオブジェクトを含むdt_mviewenvデプロイメント・テンプレートをインスタンス化した場合、テンプレート・オブジェクトはマテリアライズド・ビュー・グループpersonnelおよびtechnicalにそれぞれ追加されます。前述のように、マテリアライズド・ビュー・グループはターゲット・マスター・グループと編成上の整合性を保つのみでなく、更新可能マテリアライズド・ビューを使用するために必要です。

関連項目:
詳細は、「マテリアライズド・ビュー・グループ」を参照してください。

リフレッシュ・グループ

最初にデプロイメント・テンプレートを作成するときは、テンプレートのマテリアライズド・ビュー・オブジェクトを追加するリフレッシュ・グループの名前を定義する必要があります。インスタンス化プロセスが完了した後で、マスター・サイトに常時ネットワーク接続している場合は、リフレッシュ・グループ内のマテリアライズド・ビューを設定した間隔で自動的にリフレッシュするように指定できます。

Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはDBMS_REFRESH.CHANGEプロシージャを使用して、リフレッシュ・グループのリフレッシュ間隔と次回リフレッシュするデータを変更できます。アドバンスト・レプリケーション・インタフェースでこれらの設定を変更するには、リフレッシュ・グループを選択して、「次の日付」フィールドと「間隔」フィールドを編集します。DBMS_REFRESH.CHANGEプロシージャを使用してこれらの設定を変更する場合は、intervalパラメータとnext_dateパラメータを適切に設定します。マテリアライズド・ビュー・サイトからマスター・サイトに常時ネットワーク接続していない場合は、必要に応じてリフレッシュ・グループをリフレッシュできます。

next_dateとintervalの指定に使用できる簡単な日付式の例を、次に示します。

- next_dateまたはintervalが1時間の指定:

SYSDATE + 1/24

- next_dateまたはintervalが7日の指定:

SYSDATE + 7

関連項目:
日付算術の詳細は、『Oracle Database管理者ガイド』および『Oracle Database SQL言語リファレンス』を参照してください。

デプロイメント・テンプレートの設計

デプロイメント・テンプレートのパラメータと副問合せによるサブセット化を組み合せることで、データベース管理者は、副問合せと行がサブセット化されたデータを使用して広範囲に分散したデータベース環境を管理できます。列のサブセット化の要件およびレプリケーション環境に必要なデータ・セットについては、さらにいくつかの設計上の考慮事項があります。

マテリアライズド・ビュー・データ・セットはマテリアライズド・ビューの問合せに基づいて定義されます(つまり、ユーザーに表示されるのは、マテリアライズド・ビューの定義問合せに適合するデータのみです)。行および列のサブセット化により、カスタマイズ・データ・セットを含むマテリアライズド・ビューを作成できます。このようなマテリアライズド・ビューは、すべてのデータ・セットを必要としない地域事業所や営業担当員に役立ちます。

この項には、次の項目が含まれます。

- デプロイメント・テンプレートを使用した列のサブセット化

- 行のサブセット化

- データ・セット

- 設計に関するその他の考慮事項

関連項目:
データのサブセット化の詳細は、「マテリアライズド・ビューを使用したデータのサブセット化」を参照してください。

デプロイメント・テンプレートを使用した列のサブセット化

列のサブセット化を使用すると、マスター表の列をマテリアライズド・ビューから除外できます。これを行うには、マテリアライズド・ビューの作成中に、SELECT文に該当する列を指定します。列のサブセット化は、デプロイメント・テンプレートを使用した場合にのみ可能です。デプロイメント・テンプレートを作成する前に、テンプレートの設計を行う必要があります。

たとえば、多くの軽量なクライアントを含む大規模デプロイメントの環境では、LOBデータ自体を実際にレプリケートするのではなく、LOBデータを含む表をレプリケートすることが必要な場合があります。これを行うには、列のサブセットを定義するときに、レプリケート対象として選択した列からLOB列を除外します。

読取り専用マテリアライズド・ビューでは列の任意のサブセットを選択できます。更新可能マテリアライズド・ビューでは、列のサブセットに次の列が含まれている必要があります。

- 主キー列

- レプリケート列の競合解消に使用するすべての列(図4-6を参照してください)

注意:
列のサブセット化は列グループ内に構成することもできますが、これを行うとサイト間でデータの一貫性がなくなる可能性があるため、この方法はお薦めしません。列のサブセット化を使用する場合は、列グループ・レベルで列を除外するようにしてください。

図4-6 列がサブセット化されたデータのレプリケート

列pk、empid、salaryおよびlevel(図4-6を参照)をレプリケートするマテリアライズド・ビューを追加する場合は、Time Stamp列も含める必要があります。この列は、列グループAに含まれる列の競合解消に使用されるためです。

注意:

- 列のサブセット化は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマテリアライズド・ビューをデプロイメント・テンプレートに追加する場合にのみ使用できます。レプリケーション・マネージメントAPIを使用している場合は、列のサブセット化は使用できません。

- 列のサブセット化を定義するときは、マスター定義サイトが使用できる必要があります。複数のマスター・グループからの列がサブセット化されたマテリアライズド・ビューがデプロイメント・テンプレートに含まれている場合は、各グループのマスター定義サイトが使用できる必要があります。

行のサブセット化

行のサブセット化では、WHERE句を使用して、マスター表の行をマテリアライズド・ビューから除外できます。たとえば、次の文では、oe.orders@orc1.example.comマスター表に基づいたマテリアライズド・ビューが作成され、sales_rep_id番号が173の営業担当員の行のみが含まれます。

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.orders@orc1.example.com
WHERE sales_rep_id = 173;

orders表でsales_rep_id番号が173以外の行は、このマテリアライズド・ビューからは除外されます。

割当て表を使用した行のサブセット化

行のサブセット化に割当て表を使用する方が役に立つ場合があります。割当て表を使用すると、データベース内のあるエンティティを別のエンティティに関連付けることができ、どちらのエンティティの表にも割当て情報を格納する必要がありません。このテクニックについて、例を使用してわかりやすく説明します。

oeスキーマでは、product_id列がproduct_information表の主キーで、warehouse_id列がwarehouses表の主キーです。このスキーマではinventories表は、product_id列およびwarehouse_id列を使用して製品を倉庫に割り当てるため、割当て表として機能します。これら2つの列は、inventories表の主キーを形成します。

oeスキーマ内のこの3つの表(inventories、product_informationおよびwarehouses)を使用すると、どの製品がどの倉庫にあるかを追跡するために、product_id情報をwarehouses表に格納する必要も、warehouse_id情報をproduct_information表に格納する必要もありません。これがいかに重要かを理解するために、inventories表が存在せず、warehouse_id列がproduct_information表の外部キーである場合の例について考えてみます。

この場合、営業担当員が最寄の倉庫の製品情報を格納するには、CREATE MATERIALIZED VIEW文のWHERE句にその倉庫のwarehouse_idを指定する必要があります。たとえば、営業担当員は、次の文を使用してマテリアライズド・ビューを作成します。

CREATE MATERIALIZED VIEW oe.product_information REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.product_information@orc1.example.com
WHERE warehouse_id = 1;

この構成のデメリットは、warehouse_idがマテリアライズド・ビュー定義にハードコードされているということです。会社が倉庫1を閉鎖するか、この営業担当員により近い場所に新しい倉庫を開設した場合、このマテリアライズド・ビュー定義は変更または再作成する必要があります。これと比べて、副問合せでの行のサブセット化と割当て表を使用する場合は、マテリアライズド・ビュー環境に対する変更を容易に制御できます。

oeスキーマでは、warehouse_id列はproduct_information表の一部ではありません。そのかわり、製品はinventories表を介して倉庫に割り当てられます。製品と倉庫間のこの関係を図4-7に示します。

図4-7 製品と倉庫の関係

新しい倉庫が建てられたり他の倉庫が閉鎖された場合は、inventories表を使用して製品を別の倉庫に割り当てられます。inventories表のような割当て表は、単一の管理点を作成するのみでなく、副問合せでの行のサブセット化とともに使用して、セキュリティを確保することもできます。たとえば、必要な場合は、特定の営業担当員が特定の倉庫のデータは見られるがその他の倉庫のデータは見られないように制限できます。

各営業担当員に特定の地域の担当責任があり、その地域の倉庫に格納されている製品の情報のみを必要とすると想定します。この場合、inventories表を割当て表として使用し、それとともに副問合せでの行のサブセット化を使用して、特定の営業担当員に関係する情報のみを含むproduct_informationマテリアライズド・ビューを作成できます。次の文により、適切なデータが営業担当員に提供されます。

CREATE MATERIALIZED VIEW oe.product_information REFRESH FAST FOR UPDATE AS
SELECT * FROM oe.product_information@orc1.example.com pi
WHERE EXISTS
(SELECT * FROM oe.inventories@orc1.example.com inv
WHERE pi.product_id = inv.product_id
AND EXISTS
(SELECT * FROM oe.warehouses@orc1.example.com w
WHERE inv.warehouse_id = w.warehouse_id
AND EXISTS
(SELECT * FROM hr.locations@orc1.example.com loc
WHERE w.location_id = loc.location_id
AND loc.postal_code = :p_code)));

注意:
このoe.product_informationマテリアライズド・ビューを作成するには、postal_codeをhr.locations表のマテリアライズド・ビュー・ログにロギングする必要があります。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

product_informationマテリアライズド・ビューは、p_code変数により指定された郵便番号が示す倉庫に格納されている製品の製品情報が移入されます。CREATE MATERIALIZED VIEW文の最後の行にあるp_code変数に注意してください。

この柔軟な機能により、管理者はinventories表に簡単な変更を加えるだけで、マテリアライズド・ビューのデータ・セットを容易に制御でき、マテリアライズド・ビュー作成のためにSQL文を変更する必要はありません。たとえば、新製品が特定の倉庫に追加された場合、管理者はこの製品を倉庫に割り当てる行をinventories表に追加するのみです。マテリアライズド・ビューの次のリフレッシュの後、倉庫の製品情報を追跡するマテリアライズド・ビュー・サイトに製品のデータが追加されます。

データ・セット

デプロイメント・テンプレートを設計するときは、ターゲット・データにアクセスする様々なユーザーのタイプを考慮します。たとえば、営業担当員と技術者はいずれも顧客情報を必要としますが、両方が販売情報を必要とするわけではありません。ユーザーが自分に無関係なデータを含むデプロイメント・テンプレートをインスタンス化すると、余分な記憶領域が必要になり、リフレッシュ時間が長くなるため、このようなインスタンス化は避けてください。

逆に、販売情報と顧客情報の両方を必要とするユーザーが、重複したデータを共有する複数のデプロイメント・テンプレートをインスタンス化する必要があることも不都合です。複数のテンプレートをインスタンス化すると、データ整合性の問題が発生することがあります。つまり、各デプロイメント・テンプレートが異なるリフレッシュ・グループを使用するため、2つのデプロイメント・テンプレートのデータが別々のタイミングでリフレッシュされてデータ整合性の問題が発生する可能性があります。

この場合は、営業担当員、顧客サービス技術者、および両方のデータ・セットを必要とするユーザー向けに、それぞれ1つずつデプロイメント・テンプレートを作成するのが最善のソリューションです。

時間と手間をかけずに3種類のデプロイメント・テンプレートを作成するには、まず両方のデータ・セットを含むテンプレートを作成し、それを2つコピーして、それぞれ不要な項目を削除して2つのテンプレートを作成するのが最善の方法です。

図4-8 営業担当員用テンプレートと顧客サービス技術者用テンプレートの相違

設計上のもう1つの考慮点は、パラメータの使用です。図4-8に示されている表の多くでcustomer_idフィールドが使用される場合、テンプレート・オブジェクトのそれぞれに同じパラメータを定義できます。同じパラメータを使用すると、必要なデフォルト・パラメータ値の定義は1回のみで、インスタンス化プロセス時にその定義がすべてのオブジェクトに使用されます。

副問合せに基づくサブセット化を行うマテリアライズド・ビューで使用する場合は、1つのテンプレート・パラメータを使用するとさらに便利です。パラメータを1つにすることによって、ユーザーは必要な顧客に関するデータのみを受け取ることができます。たとえば、次のCREATE MATERIALIZED VIEW文について考えます。

CREATE MATERIALIZED VIEW sales.orders AS
SELECT * FROM sales.orders@orc1.example.com o
-- conditions for customers
WHERE EXISTS
( SELECT c_id FROM sales.customer@orc1.example.com c
WHERE o.c_id = c.c_id
AND EXISTS
( SELECT * FROM sales.assignment@orc1.example.com a
WHERE a.c_id = c.c_id
AND EXISTS
( SELECT * FROM sales.salesperson@orc1.example.com s
WHERE s.s_id = :salesperson_id)));

CREATE MATERIALIZED VIEW sales.customer AS
SELECT c_id FROM sales.customer@orc1.example.com c
-- conditions for customers
WHERE EXISTS
( SELECT * FROM sales.assignment@orc1.example.com a
WHERE a.c_id = c.c_id
AND EXISTS
( SELECT * FROM sales.salesperson@orc1.example.com s
WHERE s.s_id = :salesperson_id)));

作成する2つのマテリアライズド・ビューには明示的なsalesperson_idフィールドが含まれていませんが、副問合せに基づくサブセット化を行うことによって、パラメータを使用して必要なデータ・セットのみをインスタンス化できるので、非常に効率的です。1つのパラメータ(:salesperson_id)を使用すると、マテリアライズド・ビューの管理およびインスタンス化が、DBAおよびデプロイメント・テンプレートを使用するユーザーの両方にとって容易になります。

設計に関するその他の考慮事項

最後に、リモート・マテリアライズド・ビュー・サイトで他にどのようなオブジェクトを作成する必要があるかを考えます。具体的には、次の点を検討してください。

- マテリアライズド・ビュー・サイトとマスター・サイト間に必要なデータベース・リンクを作成するDDLを含める必要があるかどうか

- マテリアライズド・ビュー環境で必要となるトリガーまたはプロシージャの種類

- 非レプリケート・データを格納する表を作成する必要があるかどうか

- 索引を追加する必要があるかどうか

マテリアライズド・ビュー作成のローカル制御

デプロイメント・テンプレートは、マテリアライズド・ビュー環境を作成および配布するための最も効率的な方法です。配布先が2つまたは3つのサイトのみの場合でも、デプロイメント・テンプレートを使用することによって、個々のサイトにマテリアライズド・ビュー環境を作成するよりもはるかに少ない手順でマテリアライズド・ビュー環境を作成できます。デプロイメント・テンプレートを使用すると、1度マテリアライズド・ビュー環境を作成して、必要な数のサイトにそれを配布できます。

ただし、マテリアライズド・ビュー環境を作成して配布するのにデプロイメント・テンプレートを使用することが最も効率的な方法ならば、どのような場合にリモート・マテリアライズド・ビュー・サイトでローカルにマテリアライズド・ビュー環境を作成するのかという疑問が1つ残っています。通常、マテリアライズド・ビュー・サイトでローカル制御を維持する必要がある場合は、「マテリアライズド・ビュー・グループ・ウィザード」を使用してマテリアライズド・ビュー環境を作成するか、マテリアライズド・ビュー・サイトでローカルにマテリアライズド・ビュー環境を作成します。

マテリアライズド・ビュー作成のローカル制御が便利なのは、マテリアライズド・ビュー・サイトで、受け取るデータを制御することが望ましい場合などです。たとえば、通常は読取り専用マテリアライズド・ビュー・サイトである意思決定支援サイト(DSS)の場合、特に便利です。DSSサイトでは複雑な問合せを実行することがありますが、OLTPサイトの速度を低下させないようにしたり、OLTPサイトのDBAの負担を軽減するにはローカル制御が必要です。

マテリアライズド・ビューのローカル制御

デプロイメント・テンプレートの主な利点の1つに、DBAがデプロイメント・テンプレートの作成を集中して管理できる点があります。ただし、マテリアライズド・ビュー・サイトでなんらかの制御が必要になる場合があります。

次の場合はローカル制御が必要です。

- マテリアライズド・ビュー・サイトに熟練したDBAがいる場合

- マテリアライズド・ビュー・サイトが信頼できるサイトである場合

- マテリアライズド・ビュー・サイトで行のサブセット化を実行する場合

マテリアライズド・ビュー・グループは、マテリアライズド・ビュー・サイトのDBAまたはSQLの知識を持ったシステム・アナリストがアドバンスト・レプリケーション・インタフェースの「マテリアライズド・ビュー・グループの作成」ウィザードを使用してマテリアライズド・ビュー・サイトでローカルに作成するため、マテリアライズド・ビュー・サイトでも制御できます。

ローカル制御を行う最適な例として、次の例を考えます。マルチマスター・レプリケーションでは行および列のサブセット化ができないため、主にデータのサブセット化のみの目的で更新可能マテリアライズド・ビュー・サイトが作成されることがあります。これらのサイトは通常は安全で、熟練したDBAが存在し、ユーザーやアプリケーションの要件を満たすためにローカル制御を行う必要があります。「マテリアライズド・ビュー・グループ・ウィザード」またはレプリケーション・マネージメントAPIを使用して作成したマテリアライズド・ビュー・グループでは、安全性の高い更新可能マテリアライズド・ビュー・サイトの要件を満たすために必要なローカル制御を実行できます。

また、前述のように、デプロイメント・テンプレートを使用してマテリアライズド・ビュー環境を作成すると、マテリアライズド・ビュー環境のすべてのオブジェクトが同じリフレッシュ・グループに追加されます。このことはほとんどのインストレーションでは問題ありませんが、場合によってはマテリアライズド・ビュー・グループ内のオブジェクトをいくつかの異なるリフレッシュ・グループに割り当てる必要があります。

5 競合解消の概念およびアーキテクチャ

レプリケーション環境によっては、複数サイト間でのデータ・レプリケーションによって発生する可能性のあるデータ競合を解消する競合解消方法を作成する必要があります。

この章には、次の項が含まれます。

- 競合解消の概念

- 競合解消のアーキテクチャ

競合解消の概念

レプリケーションの競合は、複数のサイトから同じデータを同時に更新できるレプリケーション環境で発生します。たとえば、別々のサイトから発生した2つのトランザクションによって、同じ行がほとんど同時に更新されたときに競合が発生します。レプリケーション環境を構成するときは、レプリケーションの競合が発生する可能性の有無を考慮する必要があります。システム設計に競合を発生させる可能性がある場合や、競合が発生した場合には、なんらかの方法で競合を解消しないかぎりシステム・データは収束しません。

一般的に、まず必要なのは競合が発生しないレプリケーション環境を設計することです。ほとんどのシステム設計では、いくつかのテクニックを使用することによって、レプリケートするデータの全体または大部分で競合を回避できます。しかし、多くのアプリケーションでは、データの一部を複数のサイトからいつでも更新できる必要があります。その場合、レプリケーションの競合の発生に対処できる必要があります。

次の各項で、競合解消に関する次の項目について説明します。

- レプリケーションの競合を考慮してレプリケーション・システムを設計する方法

- 使用するレプリケーション環境で発生する可能性のある競合タイプの判別方法

- レプリケーション環境の設計においてレプリケーションの競合を回避する方法

- 競合を回避できない設計でOracleが競合を検出および解消する方法

この項には、次の項目が含まれます。

- データ要件およびアプリケーション要件の理解

- レプリケーションの競合のタイプ

- データの競合およびトランザクションの順序

- 競合の検出

- 競合解消

- 競合回避のテクニック

データ要件およびアプリケーション要件の理解

どのようなタイプのデータベース・アプリケーションおよびサポート・データベースを設計する場合でも、データベースまたはアプリケーション自体を構築する前にアプリケーション要件を理解することは非常に重要です。たとえば、各アプリケーションは、機能境界や依存性(受注入力、出荷、請求など)が正しく定義され、モジュール化されている必要があります。さらに、サポート・データベースのデータを正規化して、アプリケーション・システムのモジュール間の隠れた依存性を軽減する必要があります。

レプリケーション環境で動作するデータベースを作成する場合は、基本的なデータベース設計のルールのみでなく、その他の要件も検討する必要があります。まず、レプリケート・データを扱うアプリケーションの一般的な要件を考慮します。たとえば、一部のアプリケーションは読取り専用マテリアライズド・ビューの使用でも十分に対応できるので、結果的にレプリケーションの競合の発生を完全に回避できます。これに対して、大部分のレプリケート・データが読取り専用で、一部のデータ(たとえば、1つまたは2つの表、あるいは特定の表内の1つまたは2つの列)をすべてのレプリケーション・サイトで更新可能にする必要があるアプリケーションもあります。この場合は、レプリケーションの競合が発生したときにレプリケート・データの整合性が完全に保たれるように、競合解消方法を決定する必要があります。

競合の検出と解消の例

競合を考慮したレプリケート・データベースの設計方法をよく理解するために、競合の検出および解消が可能な場合と不可能な場合がある、次のような環境を考えてみます。

- 通常、同じ商品に対して複数の予約を受け付けることができない予約システムでは、競合を解消できません。たとえば、コンサートの特定の座席を予約するときには競合を解消する方法がないため、予約システムの異なるレプリカにアクセスする異なるエージェントが、複数の顧客のために同じ座席を予約できません。

- 顧客管理システムでは、通常、競合を解消できます。たとえば、複数の営業担当員がレプリケーション環境内の異なるデータベースの顧客住所情報をメンテナンスできます。競合が発生しても、レコードに最新の更新内容を適用することで、更新の競合を解消できます。

レプリケーションの競合のタイプ

レプリケート・データベース環境で検出されるデータ競合のタイプは、次のとおりです。

- 更新の競合

- 一意性競合

- 削除の競合

レプリケーション環境で発生する可能性が最も高いのは更新の競合ですが、一意性競合および削除の競合にも対処できるように準備する必要があります。これらのタイプの競合を回避できるようにデータベースを設計することをお薦めします。

更新の競合

更新の競合は、ある行に対する更新のレプリケーションが同じ行に対する別の更新と競合したときに発生します。異なるサイトから発生した2つの異なるトランザクションによって、同じ行がほとんど同時に更新されたときに発生することがあります。

一意性競合

一意性競合は、行のレプリケーションによってエンティティの整合性(主キー制約や一意制約など)が失われるときに発生します。たとえば、2つの異なるサイトから発生した2つのトランザクションで、同じ主キー値を使用してそれぞれの表レプリカに行を挿入した場合について考えます。この場合、トランザクションのレプリケーションが原因で一意性競合が発生します。

削除の競合

削除の競合は、異なるサイトから発生した2つのトランザクションのうち、1つのトランザクションで行が削除され、もう1つのトランザクションで同じ行に対して更新または削除が行われたときに発生します。これは、更新または削除の対象となる行が存在しなくなるためです。

データの競合およびトランザクションの順序

順序競合は、マスター・サイトが3つ以上あるレプリケーション環境で発生します。なんらかの理由でマスター・サイトXへの伝播がブロックされた場合、レプリケート・データへの更新を他のマスター・サイト間で伝播できます。伝播を再開したときに、これらの更新がその他のマスターで発生した順序と異なる順序でサイトXに伝播されると、更新の競合が発生する可能性があります。デフォルトでは、発生した競合はエラー・ログに記録され、依存関係にあるトランザクションが伝播および適用された後で再実行できます。順序競合の例は、表5-1を参照してください。

マスター・サイトが3つ以上あるレプリケーション環境でデータ収束を保証するには、マスター・サイトがいくつあっても確実にデータ収束を行える競合解消方法(最も新しいタイムスタンプ、最小値、最大値、優先グループ、加算)を選択する必要があります。

最小値、最大値、優先グループおよび加算による競合解消方法は、一定の条件が存在するかぎり、マスター・サイトがいくつあってもデータ収束が保証されます。詳細は、「競合解消のアーキテクチャ」で説明している競合解消方法を参照してください。

レプリケートされたトランザクションが順不同で適用されると、データ競合を受信するのみでなく、データのサポートがリモート・サイトに正常に伝播されていないと、そのサイトで参照整合性の問題が発生する場合があります。新規の顧客が受注部門に連絡する場合の使用例を考えます。顧客記録が作成され、受注が行われます。受注データが顧客データより前にリモート・サイトに伝播されると、受注で参照されている顧客はリモート・サイトに存在しないため、参照整合性エラーが発生します。

参照整合性エラーが発生した場合は、サポート・データがリモート・サイトに伝播された後でエラーが発生したトランザクションを再度実行すると、簡単に解決できます。

競合の検出

レプリケーション・システムの各マスター・サイトは、レプリケーションの競合が発生するとそれを自動的に検出し、解消します。たとえば、あるマスター・サイトがシステム内の別のマスター・サイトに遅延トランザクション・キューをプッシュするときに、レプリケーションの競合があれば、その競合は呼び出された受信サイトのリモート・プロシージャによって自動的に検出されます。

マテリアライズド・ビュー・サイトが対応するマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに遅延トランザクションをプッシュすると、受信サイトで競合の検出および解消が行われます。マテリアライズド・ビュー・サイトでは、マテリアライズド・ビューのリフレッシュを実行することによってデータをリフレッシュします。このリフレッシュの仕組みによって、リフレッシュ完了後には、競合解消結果を含めたマテリアライズド・ビューのデータが、対応するマスター表またはマスター・マテリアライズド・ビューのデータと同一になります。したがって、マテリアライズド・ビュー・サイトでレプリケーションの競合の検出または解消を実行する必要はありません。

異なるタイプの競合の検出方法

レプリケーション・システムでの受信側のマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでは、次のような更新の競合、一意性競合および削除の競合が検出されます。

- レプリケート行の古い値(変更前の値)と受信サイトの同じ行の現在の値が異なる場合、受信サイトで更新の競合が検出されます。

- レプリケート行のINSERTまたはUPDATEの実行中に一意制約違反が発生した場合、受信サイトで一意性競合が検出されます。

- 行の主キーが存在しないために受信サイトでUPDATE文またはDELETE文の対象の行が見つからない場合、受信サイトで削除の競合が検出されます。

注意:

- 列を更新して、この列の古い値と新しい値が等しい場合、この列の更新で競合は検出されません。

- 行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。パフォーマンスを最大にするには、更新の競合の検出および解消サポートに使用するデータの量をチューニングします。詳細は、「古い値の送信および比較」を参照してください。

競合検出時の行の識別

レプリケーションの競合を正確に検出するには、データ・レプリケーション時に別々のサイトの対応する行を一意に識別し、一致させる必要があります。通常、アドバンスト・レプリケーションでは、表の主キーを使用して表内の行を一意に識別します。表に主キーがない場合は、(データ・レプリケーション時に表内の行を一意に識別するために使用する列または列のセットである)代替キーを指定する必要があります。

注意:
アプリケーションで表の主キーまたは代替キーを更新しないようにしてください。これは、Oracleで行を識別し、レプリケート・データの整合性を保つためです。

競合解消

競合が検出された場合は、競合を解消してすべてのサイトでデータ収束を実行します。Oracleには、更新の競合を解消するビルトインの競合解消方法が用意されており、通常は、この方法を使用することで、様々なレプリケーション環境のデータ収束を保証できます。また、一意性競合に対する競合解消方法もありますが、これはデータ収束を保証しません。

削除の競合または順序競合については、ビルトインの競合解消方法はありません。ただし、ビジネス・ルールに固有の競合解消方法を独自に作成できます。データ収束を保証しない競合解消方法(特に、一意性競合および削除の競合の解消方法)を作成する場合、通知機能を作成してデータベース管理者にデータ収束を手動で実現するように依頼する必要があります。

ビルトインの競合解消方法またはユーザー定義の競合解消方法のいずれを使用する場合も、競合が検出されると即時に適用されます。定義した競合解消方法で競合を解消できない場合は、その競合はエラー・キューにロギングされます。

競合解消が1つの時点で失敗するのを回避するために、別の競合解消方法を定義して、主要な競合解消方法の予備を作成できます。たとえば、タイムスタンプが同一であるため、最も新しいタイムスタンプによる競合解消方法では競合を解消できない場合(このような状況が発生することはほとんどありません)、サイト優先の競合解消方法を定義でき、これにより、タイムスタンプを使用せずにデータ競合を解消できます。

関連項目:
変更をレプリケートせずに表を変更する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。自動的に解消されない競合を手動で解消するときに、この方法が必要になることがあります。

多重化マテリアライズド・ビューと競合解消

マスター表とこのマスター表に基づいた更新可能マテリアライズド・ビューがあった場合、マテリアライズド・ビューをリフレッシュすると変更がマスター・サイトにプッシュされ、プッシュによって競合が発生した場合には、マスター・サイトが構成済の競合解消方法を使用して競合を処理します。次に、マテリアライズド・ビューはリフレッシュ完了時にマスターの変更を取り出します。リフレッシュは、常にマテリアライズド・ビュー・サイトで開始されます。

同様に、更新可能マテリアライズド・ビューのマスター・マテリアライズド・ビューは、マスター表と同じ動作をします。ただし、マスター・マテリアライズド・ビューでは、マテリアライズド・ビューからのプッシュによって発生する競合を処理するときに、マスターからプルした競合解消方法を使用します。この場合、マスターはマスター・サイトのマスター表、あるいは別のマテリアライズド・ビュー・サイトのマスター・マテリアライズド・ビューのいずれかです。競合解消方法をマテリアライズド・ビューに直接構成することはできません。かわりに、更新可能マテリアライズド・ビューを作成したとき、およびマテリアライズド・ビューのレプリケーション・サポートを生成したときに、上位のマスターから競合解消方法が自動的にプルされます。読取り専用マテリアライズド・ビューは、マスターから競合解消方法をプルしません。

たとえば、レベル3のマテリアライズド・ビューがレベル2のマスター・マテリアライズド・ビューに変更をプッシュしたとします。このプッシュにより、レベル2のマテリアライズド・ビューで競合が発生したとします。レベル2のマテリアライズド・ビューでは、競合を処理するために、レベル1のマスター・マテリアライズド・ビューから以前にプルした競合解消方法を使用します。同様に、レベル1のマテリアライズド・ビューでは、マスター・サイトから以前にプルした競合解消方法を使用して競合を処理します。図5-1に、この構成を示します。

図5-1 競合解消と多重化マテリアライズド・ビュー

各更新可能マテリアライズド・ビューは、従属するマテリアライズド・ビューがない場合でも、マスターから競合解消方法をプルします。読取り専用マテリアライズド・ビューは、マスターから競合解消方法をプルしません。

多重化マテリアライズド・ビューが含まれる環境でマスター表の競合解消方法を変更する場合は、次の一般的な手順を実行します。

1. 列グループまたはキー列のいずれかを変更する場合で、マスター表に基づいたどの更新可能マテリアライズド・ビューとも最小限の通信しか実行していない場合は、次のサブステップを実行します。

1. 変更するマスター表から最下位のマテリアライズド・ビューをリフレッシュします。リフレッシュにより、各マテリアライズド・ビューからすべての遅延トランザクションがそれぞれのマスターにプッシュされます。たとえば、マテリアライズド・ビューが3レベルある場合は、レベル3のマテリアライズド・ビューをリフレッシュします。

2. 手順aでリフレッシュしたマテリアライズド・ビューで、データ操作言語(DML)による変更をすべて停止します。

3. マスター・サイトのマスター表に基づいたレベル1のマテリアライズド・ビューに手順aおよび手順bを実行するまで、各マテリアライズド・ビュー・レベルに対してこの2つの手順を繰り返します。

2. 必要な場合は、マスター・グループを静止します。

3. マスター定義サイトで競合解消方法を変更します。

4. DBMS_REPCATパッケージのGENERATE_REPLICATION_SUPPORTプロシージャまたはOracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、マスター定義サイトで影響を受けるオブジェクトのレプリケーション・サポートを再生成します。

5. 手順2でマスター・グループを静止した場合は、マスター・グループのレプリケーション・アクティビティを再開します。

6. レプリケーション・サポートがまだ再生成されていない、最上位のレベル番号のマテリアライズド・ビューのレプリケーション・サポートを再生成します。再生成中に、現在の競合解消方法が上位のマスターからプルされます。この手順を初めて実行した場合、これがレベル1のマテリアライズド・ビュー用で、2回目に実行した場合はレベル2のマテリアライズド・ビュー用、というようになります。DBMS_REPCATパッケージのGENERATE_MVIEW_SUPPORTプロシージャまたはOracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、マテリアライズド・ビューのレプリケーション・サポートを再生成します。

7. 手順1でサブステップを実行した場合は、現在DML変更が禁止されている、最上位のレベル番号のマテリアライズド・ビューでDML変更を使用できるようにします。この手順を初めて実行した場合、これがレベル1のマテリアライズド・ビュー用で、2回目に実行した場合はレベル2のマテリアライズド・ビュー用、というようになります。

8. マスター表から最下位のマテリアライズド・ビューに手順6および手順7を実行するまで、各マテリアライズド・ビュー・レベルに対してこの2つの手順を繰り返します。たとえば、マテリアライズド・ビューが3レベルある場合は、最後の手順はレベル3のマテリアライズド・ビューに対して実行されます。

レプリケーション・サポートのこの再生成は、自動的には実行されません。複数のデータベース管理者がマスター・サイトとマテリアライズド・ビュー・サイトを管理する環境では、マスター・サイトのデータベース管理者は影響される全マテリアライズド・ビュー・サイトのデータベース管理者に対して、競合解消方法の変更を通知する必要があります。その後、すべてのデータベース管理者が協力して、前述の手順を適切に実行する必要があります。

更新可能マテリアライズド・ビューの列のサブセット化と競合解消

列のサブセット化を使用すると、マテリアライズド・ビューの作成中にSELECT文で特定の列を指定することによって、マスター表の列をマテリアライズド・ビューから除外できます。更新可能マテリアライズド・ビューに列グループの列のサブセットのみが含まれる場合、競合解消方法が廃棄またはサイト優先順位のいずれかでない場合には、この列グループで競合解消方法を作成しないでください。競合解消方法がサイト優先順位の場合、列のサブセット化は、マスター・サイトがマテリアライズド・ビュー・サイトよりも高い優先番号を持つシングル・マスター・レプリケーション環境でのみ使用する必要があります。

前述の廃棄による解消方法およびサイト優先順位による解消方法以外の競合解消方法の場合、更新可能マテリアライズド・ビューは列グループ内のいくつかの列に関する変更情報を送信しますが、その他の列に関しては情報を送信しないため、競合解消方法が適用されるときにエラーが戻されます。廃棄による解消方法とサイト優先順位による解消方法は列情報に依存しないため、これらの競合解消方法は列のサブセット化とともに使用できます。

たとえば、employeesマスター表に列グループがあり、この列グループにはemployee_id列、manager_id列、department_id列およびtimestamp列が含まれているとします。最新のタイムスタンプによる競合解消方法をマスター・サイトの列グループに対して定義します。次に、employeesマスター表に基づいてemployees_mvという更新可能マテリアライズド・ビューを作成しますが、列のサブセット化を使用して、このマテリアライズド・ビューからdepartment_id列を除外します。マテリアライズド・ビューでemployee_id列またはmanager_id列が更新されると、次のリフレッシュ時にこの変更情報がマスター・サイトに送信されます。マスター・サイトでは、競合解消方法が適用されるときに、列グループの残りの列(department_id)に関する情報がないため、エラーが戻されます。

多重化マテリアライズド・ビューを使用する場合は、前述のことを考慮します。競合解消方法がマスター・サイトからマスター・マテリアライズド・ビュー・サイトに取り出されるため、マスター・マテリアライズド・ビュー・サイトとそれに基づいた更新可能マテリアライズド・ビューに対しても、これと同じ規則が適用されます。

関連項目:
「デプロイメント・テンプレートを使用した列のサブセット化」

ネストした表と競合解消

各ネストした表の列に対して、表にNESTED_TABLE_ID列という非表示列が作成されます。また、ネストした表の要素を格納するために、記憶表という個別の表が作成されます。この記憶表には、各親表の行用のネストした表の各要素の行が格納されます。また、この記憶表には、親表のNESTED_TABLE_ID列に対応し、特定の親行用のネストした表の要素を特定するために使用されるNESTED_TABLE_ID列も含まれます。ネストした表の列では、アドバンスト・レプリケーションにおいて特別な考慮が必要です。基礎となる記憶表は、親表と同程度の競合解消に対する考慮が必要で、さらに考慮すべき問題があります。

アドバンスト・レプリケーションでは、ネストした表に対するデータ操作言語(DML)文を、親表および記憶表に対するDML文とは別に処理します。ネストした表の列に対してDML文が実行された場合、DML文のタイプにより実行されるアクションが異なります。DML文のタイプとそれぞれのタイプに対して実行されるアクションを、次の表に示します。

INSERT文

DELETE文

UPDATE文

- 新規行を記憶表に挿入します(ネストした表の値がNULLでも空でもない場合)。

- 新規行を親表に挿入します。NESTED_TABLE_IDの値は以前に挿入した記憶表の行を指します。

- 削除される親表に対応付けられている記憶表の行を削除します。

- 親表の行を削除します。

- 新規行を記憶表に挿入します(ネストした表の列が、NULLでも空でもない表の値に設定されている場合)。

- 親表の行を更新します。

- 古い記憶表の行を削除します。

ネストした表の競合の例

次の例は、ネストした表に対するDML文が、解消の困難な競合につながる可能性があることを示しています。コード例に続いて、競合を最小化する方法について説明しています。

各学部の情報をdepartment表に格納する大学があったとします。この表には、各学部の履修課程の情報を格納するネストした表が含まれています。

CREATE TYPE Course AS OBJECT (
course_no NUMBER(4),
title VARCHAR2(35),
credits NUMBER(1));
/

CREATE TYPE CourseList AS TABLE OF Course;
/

CREATE TABLE department (
name VARCHAR2(20) primary key,
director VARCHAR2(20),
office VARCHAR2(20),
courses CourseList)
NESTED TABLE courses STORE AS courses_tab(
(PRIMARY KEY(nested_table_id,course_no)));

この大学はアメリカ全土にキャンパスがあり、マルチマスター・レプリケーションを使用して様々なキャンパスをサポートしています。各キャンパスではdepartment表を更新できます(この表はレプリケート表です)。マスター・サイトの1つであるuniv1.example.comで、Psychology学部に対して情報が挿入されます。

INSERT INTO department
VALUES('Psychology', 'Irene Friedman', 'Fulton Hall 133',
CourseList(Course(1000, 'General Psychology', 5),
Course(2100, 'Experimental Psychology', 4),
Course(2200, 'Psychological Tests', 3),
Course(2250, 'Behavior Modification', 4),
Course(3540, 'Groups and Organizations', 3),
Course(3552, 'Human Factors in Business', 4),
Course(4210, 'Theories of Learning', 4)));

アドバンスト・レプリケーションにより、この挿入が全マスターに伝播されます。

次に、Psychologyクラスに関する変更情報が届きます。つまり、クラスが1つ追加されます。この情報がuniv1.example.comで更新されます。

UPDATE department SET courses = CourseList(
Course(1000, 'General Psychology', 5),
Course(2100, 'Experimental Psychology', 4),
Course(2200, 'Psychological Tests', 3),
Course(2250, 'Behavior Modification', 4),
Course(3540, 'Groups and Organizations', 3),
Course(3552, 'Human Factors in Business', 4),
Course(4210, 'Theories of Learning', 4),
Course(4320, 'Cognitive Processes', 4))
WHERE name = 'Psychology';

univ1.example.comが更新をコミットした後、他のマスター・サイトに変更が伝播される前に、別のマスター・サイトuniv2.example.comが、4320および4410という2つのクラスが追加されたという情報を受け取ります。

UPDATE department SET courses = CourseList(
Course(1000, 'General Psychology', 5),
Course(2100, 'Experimental Psychology', 4),
Course(2200, 'Psychological Tests', 3),
Course(2250, 'Behavior Modification', 4),
Course(3540, 'Groups and Organizations', 3),
Course(3552, 'Human Factors in Business', 4),
Course(4210, 'Theories of Learning', 4),
Course(4320, 'Cognitive Processes', 4),
Course(4410, 'Abnormal Psychology', 4))
WHERE name = 'Psychology';

univ1.example.comでの更新とuniv2.example.comでの更新の両方がプッシュされます。

department表に更新競合がありそうです。更新を行ったユーザーは、それがINSERT文後の最初の更新であると思っています。しかし、実際にはローカルの更新が最初に行われているため、これらは親表での更新となるのでNESTED_TABLE_IDは変更されています。これはネストした表の列での更新(記憶表の行とNESTED_TABLE_IDを変更)のみで、問題が多くなります。親表での他の列の更新は問題はありません。

ローカルな表を最新状態にすることにより、この競合が解消されるとします。ローカルな更新によりすでに削除されている行を無視するように、記憶表に対して削除による競合解消方法が必要になります。記憶表に挿入された新規行は、リモート・サイトでの更新のため、親表に参照先がありません。記憶表のこの新規行も処理する必要があります。そうしない場合、これらの行が孤立してしまいます。記憶表には、department表からアクセスできないcourse行が増えてしまいます。

記憶表の行を操作しながら親表を更新するという競合解消は、マルチマスター・レプリケーション環境に2つのマスター・サイトがある場合は非常に困難で、マスター・サイトが増えた場合はほとんど不可能です。このような更新が必要な場合は、ネストした表に競合解消方法を定義せずに、競合は手動で解消するというのが最善の方法です。競合解消方法が正しくない場合、データの相違が発生する可能性があります。つまり、異なるマスター上の表が一致しなくなる危険性があります。

問題になる可能性のある更新を回避するための推奨事項

次に示した方法(推奨)により、前項で説明した更新の問題を回避できます。

- ネストした表に対して、最初は遅延されている外部キー制約を使用します。この制約により、記憶表で参照先がない行が発生しません。このような外部キー制約の例を、次に示します。

ALTER TABLE courses_tab add CONSTRAINT courses_fk
FOREIGN KEY(NESTED_TABLE_ID) REFERENCES department(courses)
INITIALLY DEFERRED;

- 親表に対するすべての挿入で、空のネストした表が挿入されるようにします。ネストした表の値にNULLは使用しないでください。これにより、再利用可能なNESTED_TABLE_IDを作成できます。空のネストした表を含む挿入の例を、次に示します。

INSERT INTO department (name, director, office, courses)
VALUES('Psychology', 'Irene Friedman', 'Fulton Hall 133', CourseList());

- すべての挿入、削除および更新は、DMLを介して親表に実行するのではなく、ネストした表に対して直接実行します。これにより、現在のNESTED_TABLE_ID値を再利用できます。
ネストした表から行を直接削除する例を、次に示します。

DELETE FROM TABLE
(SELECT courses FROM department WHERE name = 'Psychology');

univ1.example.comのネストした表に次の行が直接挿入される例を考えてみます。

INSERT INTO TABLE
(SELECT courses FROM department WHERE name = 'Psychology')
VALUES (Course(5000, 'Social Psychology', 5));

INSERT INTO TABLE
(SELECT courses FROM department WHERE name = 'Psychology')
VALUES (Course(5100, 'Psychology of Personality', 4));

次に、univ1.example.comに対する前述の挿入がプッシュされる前に、次の行がuniv2.example.comのネストした表に直接挿入されます。

INSERT INTO TABLE
(SELECT courses FROM department WHERE name = 'Psychology')
VALUES (Course(5000, 'Social Psychology', 5));

INSERT INTO TABLE
(SELECT courses FROM department WHERE name = 'Psychology')
VALUES (Course(5100, 'Psychology of Personality', 4));

INSERT INTO TABLE
(SELECT courses FROM department WHERE name = 'Psychology')
VALUES (Course(5500, 'Cognitive Neuroscience', 5));

ここで、course 5000および5100に関して記憶表に挿入された行で主キー競合が発生しますが、1つのサイトからの挿入が失敗しても問題のない競合解消方法を記憶表に定義すると正しい結果が得られます。ただし、この場合、これらの挿入により「ネストした表の競合の例」で説明された複数の表が関与する複雑な問題は発生せず、NESTED_TABLE_IDの値も変更されないため、この値が失われることはありません。

- ネストした表の列の操作を含む挿入および更新を回避するようなトリガーを、親表に対して使用することを考慮します。このようなトリガーの例を次に示します。

CREATE OR REPLACE TRIGGER depart_trig
AFTER INSERT OR UPDATE ON department
FOR EACH ROW
DECLARE
new_ntid raw(100);
old_ntid raw(100);
BEGIN
-- obtain the nested table ids
SELECT sys_op_tosetid(:new.courses) INTO new_ntid from dual;
SELECT sys_op_tosetid(:old.courses) INTO old_ntid from dual;
IF INSERTING THEN
-- raise error on insert of a null nested table column
IF :new.courses IS NULL THEN
raise_application_error(-20011, 'inserting null nested table ref');
END IF;
-- raise error if new rows are inserted in the storage table
-- this is not strictly necessary, but it does enforce DML access
-- semantics of separate DMLS on parent table and storage table
IF :new.courses.count != 0 THEN
raise_application_error(-20012,
'inserting rows into storage table while inserting parent table row');
END IF;
ELSE
-- raise error if update has caused the NESTED_TABLE_ID to change
IF new_ntid != old_ntid THEN
raise_application_error(-20013,
'updating storage table reference while updating parent table row');
END IF;
END IF;
END;
/

前述の推奨事項は、記憶表の行が別の記憶表の行の親になる複数レベルのネストにも適用されます。これらの推奨事項は、ネストの各レベルでの適切な競合対策になります。

競合回避のテクニック

Oracleではデータ競合を解消する強力な競合解消方法がありますが、レプリケート・データベースやフロントエンド・アプリケーションの設計時にまず優先する必要があるのは、データ競合を回避することです。以降の項では、レプリケーション競合の一部または全部を回避するためのテクニックを簡単に説明します。

列グループの使用

列グループを使用すると、列グループに対して競合解消方法を適用しない場合でも、競合の回避に役立ちます。レプリケート表に複数列グループが含まれている場合、更新の競合が発生しているかどうかの分析は列グループごとに個別に行われます。

たとえば、列グループa_cgと列グループb_cgが含まれているレプリケート表を考えてみます。列グループa_cgには、a1、a2およびa3という列が含まれています。列グループb_cgには、b1、b2およびb3という列が含まれています。

レプリケーション・サイトのsf.example.comとla.example.comで次の更新が発生します。

- ユーザーwsmithがsf.example.comの1つの行の列a1を更新します。

- 同一時刻に、ユーザーmrothがla.example.comの同一行の列b2を更新します。

この場合、Oracleでは列グループa_cgとb_cgでの更新は別々に分析されるため、競合は発生しません。ただし、列グループa_cgとb_cgがなかった場合は、表の全列が1つの列グループに入ることになり、競合が発生します。また、列グループが存在し、ユーザーmrothが列b2ではなくa3を更新した場合は、a1とa3が同じa_cg列グループにあるため、競合が発生します。

関連項目:
列グループの詳細は、「列グループ」を参照してください。

プライマリ・サイトおよび動的サイト所有権データ・モデルの使用

レプリケーションの競合の発生を回避する1つの方法として、システム内でレプリケート・データに同時更新アクセスできるサイトの数を制限する方法があります。プライマリ・サイト所有権と動的サイト所有権という、レプリケート・データの2つの所有権モデルにより、この方法がサポートされます。

プライマリ・サイト所有権

プライマリ所有権は、読取り専用レプリケーション環境でサポートされるレプリケート・データ・モデルです。プライマリ所有権によって、一連のレプリケート・データに更新アクセスできるサーバーは1つに限定されるため、すべてのタイプのレプリケーションの競合が発生しません。

表レベルでデータの所有権を制御せずに、アプリケーションで行のサブセット化および列のサブセット化の機能を使用すると、データの静的所有権をより細かく設定できます。たとえば、サイト別の基準でレプリケート表の特定の列または行に更新アクセスできます。

動的サイト所有権

動的所有権レプリケート・データ・モデルは、プライマリ・サイト所有権よりも制限の少ないモデルです。動的所有権の場合、データ・レプリカを更新する権利はサイトからサイトへ移動しますが、ある時点で特定のデータに更新アクセスできるサイトは1つしかありません。ワークフロー・システムに動的所有権の概念がわかりやすく示されています。たとえば、関連する部門のアプリケーションでは、注文を更新できる時期を判断するために、製品注文のステータス・コード(enterable、shippable、billableなど)を使用できます。

関連項目:
動的所有権データ・モデルの使用方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

特定のタイプの競合の回避

プライマリ・サイト所有権および動的所有権データ・モデルを使用するとアプリケーション要件に対して制限が多すぎる場合には、共有所有権データ・モデルを使用する必要があります。その場合でも、通常は、特定のタイプの競合を回避するためにいくつかの簡単な方法を使用する必要があります。

一意性競合の回避

一意性競合が発生しないようにレプリケーション環境を構成するのは非常に簡単です。たとえば、順序が互いに排他的な一連の順序番号を生成するように、各サイトで順序を作成できます。ただし、この方法を使用する場合、サイト数またはレプリケート表内の項目数が増加するほど問題が多く発生します。

また、複合主キーの一部として一意のサイト識別子を追加する方法もあります。

さらに、SYS_GUIDファンクションを使用してグローバルに一意の値を選択できます。選択した値を主キー(または一意の)値として使用すると、一意性競合がグローバルに回避されます。

注意:
順序は、レプリケーションの有効なオブジェクト型ではありません。したがって、各サイトで順序を作成する必要があります。

関連項目:
順序の詳細は、「順序のレプリケーションの代替方法」を、SYS_GUIDファンクションの詳細は『Oracle Database SQL言語リファレンス』を参照してください。

削除の競合の回避

削除の競合は、レプリケート・データ環境では常に回避する必要があります。一般的に、非同期の共有所有権データ・モデル環境で動作するアプリケーションでは、DELETE文を使用して行を削除しないでください。かわりに、アプリケーションで行に削除のマークを付けて、論理的に削除された行をプロシージャ・レプリケーションを使用して定期的にパージするようにシステムを構成できます。

関連項目:
削除の競合を防止するように表を準備し、マークされた行をパージするレプリケート・プロシージャを作成する方法は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』に記載された削除の競合防止方法の作成手順を参照してください。

更新の競合の回避

レプリケーション・システムでは、一意性競合と削除の競合の発生を回避するように試みた後、さらに更新の競合の発生数を少なく抑える必要があります。ただし、共有所有権データ・モデルでは、更新の競合をすべて回避することはできません。更新の競合をすべて回避できない場合は、発生する可能性のあるレプリケーションの競合のタイプを正確に理解し、競合が発生したときに解消できるようにシステムを構成する必要があります。

順序競合の回避

順序競合はできるかぎり回避するか自動的に解消するようにします。たとえば、順序競合が発生する可能性のあるマルチマスター構成で収束を保証する競合解消方法を選択します。

表5-1の例は、3つのマスター・サイトでどのような場合に順序競合が発生するかを示しています。マスター・サイトAの優先順位は30、マスター・サイトBの優先順位は25、マスター・サイトCの優先順位は10で、xは、サイト優先順位による競合解消方法が割り当てられている列グループ内の特定の行の列です。優先順位の値が最も高いサイトに、最も高い優先順位が割り当てられています。優先順位値は任意のOracle番号で、連続する整数でなくてもかまいません。

表5-1 例: サイト優先順位による競合解消方法を使用した場合の順序競合

時間

アクション

サイトA

サイトB

サイトC

1

すべてのサイトが稼働していて、x = 2で一致します。

2

2

2

2

サイトAでx = 5に更新します。

5

2

2

3

サイトCが使用不可になります。

5

2

ダウン

4

サイトAがサイトBに更新をプッシュします。サイトAとサイトBがx = 5で一致します。サイトCは使用不可のままです。更新トランザクションはサイトAのキューに残ります。

5

5

ダウン

5

サイトCがx = 2で使用可能になります。サイトAとサイトBはx = 5で一致します。

5

5

2

6

サイトBでx = 5をx = 7に更新します。

5

7

2

7

サイトBがトランザクションをサイトAにプッシュします。サイトAとサイトBがx = 7で一致します。サイトCはx = 2のままです。

7

7

2

8

サイトBがトランザクションをサイトCにプッシュします。サイトCの古い値はx = 2で、サイトBの古い値はx = 5です。競合が検出され、サイトCの優先順位(10)より高い優先順位(25)を持つサイトBの更新を適用することで、競合が解消されます。すべてのサイトがx = 7で一致します。

7

7

7

9

サイトAがそのトランザクション(x = 5)を正常にサイトCにプッシュします。サイトCの現在の値(x = 7)がサイトAの古い値(x = 2)と一致しないため、競合が検出されます。サイトAはサイトC(10)より高い優先順位(30)を持ちます。サイトAの古い更新(x = 5)を適用することで、競合が解消されます。この競合処理の順序が原因で、サイトのデータは収束しません。

7

7

5

競合解消のアーキテクチャ

レプリケーション環境に競合解消方法を実装するときに、アーキテクチャ上のメカニズムやプロセスを意識することはほとんどありません。この項では、競合解消に関連するいくつかのサポート・メカニズムについて説明し、Oracleに組み込まれている競合解消方法を様々な観点から説明します。

この項には、次の項目が含まれます。

- サポート・メカニズム

- 更新の競合の一般的な解消方法

- 更新の競合のその他の解消方法

- 一意性競合の解消方法

- 削除の競合解消方法

- 古い値の送信および比較

サポート・メカニズム

Oracleの競合解消に関連する最も重要なメカニズムは列グループであり、更新の競合の検出および解消はすべて、列グループに基づいて行われます。また、エラー・キューには、レプリケーション環境の競合検出アクティビティを監視するための重要な情報が記録されています。

列グループ

Oracleでは、更新の競合を検出および解消するために列グループを使用します。列グループは、レプリケート表の1つ以上の列を論理的にグループ化したものです。レプリケート表の各列は、1つの列グループの一部になります。マスター定義サイトでレプリケート表を構成するときに、列グループを作成して、各グループに列および対応する競合解消方法を割り当てることができます。

列グループには次のような特性があります。

- 列が属するのは1つの列グループのみです。

- 列グループは、表の1つ以上の列で構成できます。

- 競合解消が適用されるのは、列グループ内の列のみです。

関連項目:
列グループを使用した競合回避の詳細は、「列グループの使用」を参照してください。

複数列グループでのデータ整合性の保証

列グループを使用すると、データのタイプに応じて異なる競合解消方法を指定できます。たとえば、数値データの多くには算術的な解決メソッドが適しており、文字データの多くにはタイムスタンプによる解決メソッドが適しています。ただし、列グループの列を選択するときには、十分に考えた上で列をグループ化することが重要です。表内の複数の列で相互に整合性を保つ必要がある場合は、データ整合性を保証するためにそれらの列を同じ列グループに入れます。

たとえば、顧客表の郵便番号列で1つの解決メソッドを使用し、都市名列には別の解決メソッドを使用している場合、サイトは都市名に一致しない郵便番号に収束します。したがって、一般的には、競合解消方法が住所全体に対して適用されるように、1つの住所のすべての構成要素を1つの列グループに入れる必要があります。

シャドウ列グループ

デフォルトでは、各レプリケート表にシャドウ列グループがあります。表のシャドウ列グループには、特定の列グループ内にないすべての列が含まれます。表のシャドウ・グループには、競合解消方法を割り当てることはできません。したがって、列に競合解消方法を使用する必要がある場合は、列グループに必ずその列を入れてください。シャドウ列グループ内の列に関係する競合は検出されますが、このような競合を解消する競合解消方法は適用されません。

列オブジェクトと列グループ

ユーザー定義型に基づいたOracleオブジェクトのうち、表の1列を占有するOracleオブジェクトを列オブジェクトと呼びます。1つの列オブジェクトは複数の列グループにまたがることはできません。つまり、1つの列グループと1つの列オブジェクトがあった場合、列オブジェクトとその全属性が列グループに含まれているか、列オブジェクトとその全属性が列グループから除外されているかのいずれかです。

Oracleのビルトインの競合解消方法では、未定義の列オブジェクトの属性値に基づいて競合を解消することはできません。列オブジェクトがNULLの場合、その属性は未定義です。

オブジェクト表と列グループ

オブジェクト表とは、各行がユーザー定義型に基づいたオブジェクトを表す特殊な表です。オブジェクト表内の列のサブセットを含む列グループを指定できます。

ネストした表と列グループ

ネストした表の記憶表は、競合解消では独立した表として扱われます。したがって、記憶表内の列のサブセットに基づいた列グループを作成できます。

エラー・キュー

競合解消方法によってデータ競合を解消できない場合、または競合解消方法を定義していなかった場合は、エラー・キューにデータ競合に関する情報が記録されます。

関連項目:
エラー・キューの詳細は、「エラー・キュー」を参照してください。

更新の競合の一般的な解消方法

Oracleでは更新の競合の解消方法として8つのビルトインの方法を用意していますが、このうち最も一般的に実装されるのは、最新のタイムスタンプによる競合解消方法および上書きによる競合解消方法です。

この2つの競合解消方法は使いやすく、適切な環境ではデータ収束が保証されるため、最も一般的です。最新のタイムスタンプによる競合解消方法および上書きによる競合解消方法の詳細は、以降の2つの項で説明します。

表5-2 更新の競合の一般的な解消方法のデータ収束プロパティ

解消方法

複数のマスター・サイトでの収束

最新のタイムスタンプ

収束します(予備の方法を設定した場合)

上書き

収束しません

注意:
Oracleのビルトインの競合解消方法では、1つ以上のマテリアライズド・ビュー・サイトを持つシングル・マスター・サイト環境での収束を提供します。

最新のタイムスタンプ

最新のタイムスタンプによる方法を使用すると、更新発生時のタイムスタンプによって識別された最も新しい更新を原因とする競合を解消できます。

最新のタイムスタンプを使用した更新の競合解消方法の例を次に示します。

1. フェニックスの顧客が地元の営業担当員に電話をかけ、自分の住所情報を更新します。

2. 電話を切った後で、営業担当員に伝えた郵便番号が間違っていたことに顧客が気付きます。

3. 顧客は営業担当員に電話して正しい郵便番号を伝えようとしますが、担当者に電話がつながりません。

4. 顧客はニューヨーク本社に電話します。フェニックス・サイトではなく、ニューヨーク・サイトで住所情報が正しく更新されます。

5. ニューヨーク本社とフェニックス営業所を接続するネットワークが一時的にダウンします。

6. ニューヨークとフェニックスを接続するネットワークが回復すると、同じ住所に対する2つの更新が認識され、各サイトでの競合が検出されます。

7. 最新のタイムスタンプによる方法を使用して最新の更新内容が選択され、正しい郵便番号の住所が適用されます。

ターゲット環境 最新のタイムスタンプによる競合解消方法は、複数のマスター・サイトがあるレプリケーション環境でデータが収束するように機能します。タイムスタンプは常に増加しているので、この方法は複数のマスター・サイト間でのデータ収束を保証できる数少ない競合解消方法の1つです。また、任意の数のマテリアライズド・ビューがある環境でもうまく機能します。

サポート・メカニズム タイムスタンプによる方法を使用するには、レプリケート表内のDATE型の列を指定する必要があります。アプリケーションで列グループ内の列を更新するときは、ローカルSYSDATEで指定されたタイムスタンプ列の値も更新する必要があります。他のサイトから適用される変更については、タイムスタンプ値を発行元サイトのタイムスタンプ値に設定する必要があります。

注意:
タイムスタンプによる競合解消方法を使用するときは、2つのサイトのタイムスタンプが同じ場合にサイト優先順位などの予備の方法がコールされるように設定する必要があります。

タイムスタンプの設定に関する問題

タイムスタンプによる解消方法を使用する場合は、レプリケート・データを管理している異なるサイトの標準時間帯を慎重に考慮してください。たとえば、レプリケーション環境が複数の標準時間帯にわたっている場合、システムを使用するアプリケーションは、すべてのタイムスタンプをグリニッジ標準時(GMT)などの共通の標準時間帯に変換する必要があります。さらに、システム内の2つのサイトのシステム時計が正しく同期化されていない場合、タイムスタンプの比較が不正確になり、アプリケーション要件を満たすことができない可能性があります。

EARLIESTまたはLATESTタイムスタンプによる更新の競合の解消方法を使用する場合は、次の方法でタイムスタンプ列をメンテナンスできます。

- 各アプリケーションに、タイムスタンプを同期化する機能を組み込む方法

- すべてのアプリケーションのタイムスタンプを自動的に同期化させる、レプリケート表のトリガーを作成する方法

クロックは、秒数を増加する値としてカウントします。タイムスタンプのメカニズムを正しく設計し、2つのサイトのタイムスタンプが同一である場合の予備の方法を作成した場合は、最新のタイムスタンプによる方法で収束が保証されます(最大値による方法と同様)。ただし、最も古いタイムスタンプによる方法では、複数のマスター・サイトの収束は保証されません。

最新のタイムスタンプによる方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して最新のタイムスタンプによる競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

上書き

上書きによる方法では、接続先サイトの現在の値を、発行元サイトの新しい値で上書きするため、マスター・サイトが複数の場合のデータ収束は保証されません。この方法は、1つのマスター・サイトおよび複数のマテリアライズド・ビュー・サイトで使用するように設計されています。複数のマスター・サイトでこの方法を使用することもできますが、データ収束は保証されないので、なんらかのユーザー定義による通知機能とともに使用する必要があります。

たとえば、主に問合せに使用する1つのマスター・サイトがあり、すべての更新をそのマテリアライズド・ビュー・サイトで実行する場合は、廃棄による競合解消方法を選択できます。上書きによる方法は、次のような場合に役立ちます。

- 最大の目的がデータ収束である場合

- マスター・サイトが1つしかない場合

- 更新の選択について、ビジネス・ルールが特にない場合

- 複数のマスター・サイトがある環境で、DEFERRORデータ・ディクショナリ・ビューでロギングした競合の解消をローカルのデータベース管理者にまかせる方法ではなく、データが正しく適用されるように確認する担当者への通知機能を使用する場合

ターゲット環境 上書きによる競合解消方法では、1つのマスター・サイトと任意の数のマテリアライズド・ビューから構成されるレプリケーション環境でのデータ収束が保証されます。この点を考慮すると、上書きによる競合解消方法は大規模デプロイメント環境で理想的な方法です。

競合が検出された場合、マテリアライズド・ビュー・サイトの値が使用されます。つまり、最後にリフレッシュが実行されたマテリアライズド・ビューに優先順位が与えられます。

サポート・メカニズム 上書きによる競合解消方法では、その他のサポート・メカニズムは必要ありません。

上書きによる方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して上書きによる競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

更新の競合のその他の解消方法

最新のタイムスタンプまたは上書きによる競合解消方法を使用してもレプリケーション環境で発生した更新の競合を解消できない場合は、その他の6つのビルトインの競合解消方法を使用できます。

表5-3 更新の競合のその他の解消方法のデータ収束プロパティ

解消方法

複数のマスター・サイトでの収束

加算

収束します

平均

収束しません

廃棄

収束しません

最も古いタイムスタンプ

収束しません

最大値

収束します(列値は常に増加する必要あり)

最小値

収束します(列値は常に減少する必要あり)

優先グループ

収束します(順序付けられた更新値がある場合)

サイト優先順位

収束しません

加算

加算による競合解消方法は、数値型の単一列のみで構成される列グループで機能します。競合が発生した場合、いずれか一方の値を選択するのではなく、2つの値の差が現在の値に加算されます。

加算による方法では、次の式に基づいて、発行元サイトの古い値と新しい値の差を、接続先サイトの現在の値に加算します。

current value = current value + (new value - old value)

この競合解消方法では、マスター・サイトやマテリアライズド・ビュー・サイトがいくつあっても値は収束します。

ターゲット環境 加算による競合解消方法では、最も適切なデータを選択するのではなくデータを収束するように設定されています。この方法は、預金の預入れや引出しが頻繁に行われてデータ競合が発生する可能性がある金融環境で便利であり、収支では、いずれか一方の値を選択するのではなく、データを収束させることが重要です。

サポート・メカニズム 加算による競合解消方法では、その他のサポート・メカニズムは必要ありません。

加算による方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して加算による競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

平均

平均による競合解消方法は、加算による方法の場合と同様に、数値型の単一列のみで構成される列グループで機能します。この方法では、現在の値に2つの値の差を追加するのではなく、現在の値と新しい値の平均を計算することで競合を解消します。

平均による競合解消方法では、発行元サイトの新しい列値と接続先サイトの現在の値の平均をとります。

current value = (current value + new value)/2

レプリケーション環境に複数のマスター・サイトが存在する場合、平均による方法では収束を保証できません。

ターゲット環境 平均による方法では、複数のマスター・サイトが存在するレプリケーション環境でのデータ収束を保証できないので、この方法は、1つのマスター・サイトと任意の数の更新可能マテリアライズド・ビューから構成される大規模デプロイメントの環境で実装するのが理想的です。

平均による方法は、いずれか一方の値を選択するのではなく、2つの値の平均をとる科学アプリケーションで使用すると便利です(たとえば、平均温度や平均体重を計算する場合などです)。

サポート・メカニズム 平均による競合解消方法では、その他のサポート・メカニズムは必要ありません。

平均による方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して平均による競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

廃棄

廃棄による競合解消方法では、発行元サイトの値は無視されるため、複数のマスター・サイトでのデータ収束が保証されることはありません。廃棄による方法では、発行元サイトからの新しい値を無視し、接続先サイトの現在の値を保持します。この方法は、1つのマスター・サイトと複数のマテリアライズド・ビュー・サイトの間で使用するか、なんらかのユーザー定義による通知機能とともに使用してください。

たとえば、1つのマスター・サイトとこのマスター・サイトに基づいた複数のマテリアライズド・ビューがあり、マテリアライズド・ビュー・サイトは主に問合せに使用され、更新はすべてマスター・サイトで実行される場合は、廃棄による競合解消方法を選択できます。廃棄による方法は、次のような場合に役立ちます。

- 最大の目的がデータ収束である場合

- マスター・サイトが1つしかない場合

- 更新の選択について、ビジネス・ルールが特にない場合

- 複数のマスター・サイトがある環境で、DEFERRORビューでロギングした競合の解消をローカルのデータベース管理者にまかせる方法ではなく、データが正しく適用されるように確認する担当者への通知機能を使用する場合

ターゲット環境 廃棄による競合解消方法は、1つのマスター・サイトと任意の数のマテリアライズド・ビュー・サイトから構成される大規模デプロイメント・モデルに最も適しています。競合が検出された場合、マテリアライズド・ビュー・サイトの値は無視されます(つまり、最初にリフレッシュが実行されたマテリアライズド・ビューに優先順位が与えられます)。

サポート・メカニズム 廃棄による競合解消方法では、その他のサポート・メカニズムは必要ありません。

廃棄による方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して廃棄による競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

最も古いタイムスタンプ

最も古いタイムスタンプによる方法を使用すると、更新発生時のタイムスタンプによって識別された最も古い更新を原因とする競合を解消できます。

ターゲット環境 最も古いタイムスタンプによる競合解消方法は、1つのマスター・サイトと任意の数のマテリアライズド・ビューから構成されるレプリケーション環境でデータが収束するように機能します。タイムスタンプは常に増加しているので、最も古いタイムスタンプによる競合解消方法では、複数のマスター・サイトがあるレプリケーション環境のデータ収束は保証できません。この方法は、2つのトランザクションのタイムスタンプが同じである場合に備えて予備の競合解消方法を作成してある場合は、マテリアライズド・ビューの数にかかわらず機能します。

サポート・メカニズム タイムスタンプによる方法を使用するには、レプリケート表内のDATE型の列を指定する必要があります。アプリケーションで列グループ内の列を更新するときは、ローカルSYSDATEで指定されたタイムスタンプ列の値も更新する必要があります。他のサイトから適用される変更については、タイムスタンプ値を発行元サイトのタイムスタンプ値に設定する必要があります。「タイムスタンプの設定に関する問題」を確認してください。

注意:
タイムスタンプによる競合解消方法を使用するときは、2つのサイトのタイムスタンプが同じ場合にサイト優先順位などの予備の方法がコールされるように設定する必要があります。

最も古いタイムスタンプによる方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して最も古いタイムスタンプによる競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

最大値

アドバンスト・レプリケーションによって列グループに競合が検出され、最大値による競合解消方法がコールされると、列グループ内の指定した列について、発行元サイトの新しい値と接続先サイトの現在の値が比較されます。最大値による競合解消方法を選択する場合は、列を指定する必要があります。

指定した列の新しい値が現在の値より大きい場合に、その行のその他のエラーがすべて解消されていると、発行元サイトの列グループの値が接続先サイトに適用されます。指定した列の新しい値が現在の値より小さい場合は、列グループの現在の値を変更しないかぎり競合は解消されます。

注意:
指定した列の2つの値が同じ場合(たとえば、指定した列が競合を発生させた列ではない場合)、競合は解消されず、列グループの列の値は変更されません。この場合は、予備の競合解消方法を指定してください。

列グループ内の列のデータ型に制約はありません。複数のマスター・サイトのデータ収束が保証されるのは、列の値が常に増加している場合のみです。

注意:
競合解消が制約によって妨げられる可能性があるため、CHECK制約を使用して常に増加する値を制限しないでください。

ターゲット環境 最大値による競合解消方法を定義済で、競合解消に使用するターゲット列の値がすべてのサイトで常に増加している場合は、マスター・サイトやマテリアライズド・ビュー・サイトの数にかかわらずデータ収束は保証されます。

サポート・メカニズム 最大値による競合解消方法では、その他のサポート・メカニズムは必要ありません。

最大値による方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して最大値による競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

最小値

アドバンスト・レプリケーションによって列グループに競合が検出され、最小値による競合解消方法がコールされると、列グループ内の指定した列について、発行元サイトの新しい値と接続先サイトの現在の値が比較されます。最小値による競合解消方法を選択する場合は、列を指定する必要があります。

指定した列の新しい値が現在の値より小さい場合に、その行のその他のエラーがすべて解消されていると、発行元サイトの列グループの値が接続先サイトに適用されます。指定した列の新しい値が現在の値より大きい場合は、列グループの現在の値を変更しないかぎり競合は解消されます。

注意:
指定した列の2つの値が同じ場合(たとえば、指定した列が競合を発生させた列ではない場合)、競合は解消されず、列グループの列の値は変更されません。この場合は、予備の競合解消方法を指定してください。

列グループ内の列のデータ型に制約はありません。複数のマスター・サイトのデータ収束が保証されるのは、列の値が常に減少している場合のみです。

注意:
競合解消が制約によって妨げられる可能性があるため、CHECK制約を使用して常に減少する値を制限しないでください。

ターゲット環境 最小値による競合解消方法を定義済で、競合解消に使用するターゲット列の値がすべてのサイトで常に減少している場合は、マスター・サイトやマテリアライズド・ビュー・サイトの数にかかわらずデータ収束は保証されます。

サポート・メカニズム 最小値による競合解消方法では、その他のサポート・メカニズムは必要ありません。

最小値による方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して最小値による競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用して最小値による競合解消方法と最大値による競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

優先グループ

優先グループを使用すると、特定の列に格納される可能性がある各値に優先順位レベルを割り当てることができます。競合が検出されると、「優先順位」列の値が低い表が、より高い優先順位値を持つ表のデータによって更新されます。したがって、値が大きいことは優先順位が高いことを意味します。

優先グループを使用しており、優先順位列の値が常に増加している場合は、複数のマスター・サイトでの収束が保証されます。つまり、優先順位列の値は、イベントの順序、たとえば、ordered(注文)、shipped(出荷)、billed(請求)に対応します。

図5-2に示すように、各優先グループのメンバーに割り当てられている優先順位レベル(「優先順位」列に格納される値)はDBA_REPPRIORITYビューに表示されます。「優先順位」列に格納される可能性があるすべての値に対して、優先順位を指定する必要があります。

図5-2 優先グループの使用方法

現行の位置で定義されたすべての優先グループの値は、DBA_REPPRIORITYビューに表示されます。図5-2の例では、site-priorityとorder-statusという2つの優先グループがあります。customer表は、site-priority優先グループを使用しています。この例のorder-status優先グループでは、billed(優先順位値=3)はshipped (優先順位値=2)よりも優先順位が高く、shippedはordered(優先順位値=1)よりも優先順位が高くなっています。

Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して優先グループによる更新の競合解消方法を選択するには、その前に表内に優先順位列を指定する必要があります。

ターゲット環境 優先グループによる競合解消方法は、ワークフロー環境用に設定されたレプリケーション環境で役に立ちます。たとえば、order-statusがshipping状態になると、order entry部門による更新は常に上書きされます。

サポート・メカニズム ターゲット列に含まれる値の優先順位を定義する必要があります。この優先順位を定義するのは、指定された列値の優先順位に基づいて競合を解消するためです。優先順位の定義は、優先グループに格納されます。

優先グループによる方法の実装 Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して優先グループによる競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

サイト優先順位

サイト優先順位は、特殊な種類の優先グループです。サイト優先順位を使用する場合、指定する優先順位列は、更新が発行されたサイトのグローバル・データベース名に自動的に更新されます。各データベース・サイトに割り当てられた優先順位レベルは、DBA_REPPRIORITYビューに表示されます。

あるサイトが最も正確な情報を持っている可能性が高いとみなされる場合、サイト優先順位が役に立つことがあります。たとえば、図5-2では、new_york.example.comサイト(優先順位値 = 2)は本社で、houston.example.comサイト(優先順位値 = 1)は営業所にある更新可能マテリアライズド・ビューです。したがって、本社オフィスは、各顧客のクレジット限度額に関する最も正確な情報を持っている可能性が営業所よりも高いと考えられます。

注意:
DBA_REPPRIORITYビューの優先グループ列には、site-priority優先グループおよびorder-status優先グループの両方が表示されます。

サイト優先順位による方法のみを使用する場合は、複数のマスター・サイトでのデータ収束は保証されませんが、サイト優先順位はマルチマスター環境に適した予備の競合解消方法です。特に最新のタイムスタンプによる方法で2つのタイムスタンプがまったく同じである場合の予備の方法として役立ちます。

優先グループの場合と同様、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して列グループに対してサイト優先順位による競合解消方法を選択する前に、いくつかの準備を済ませておく必要があります。

ターゲット環境 優先グループと同様に、サイト優先順位による競合解消方法は、ワークフロー環境で実装されるのが一般的です。また、サイト優先順位による競合解消方法を大規模デプロイメントの環境(1つのマスター・サイトおよび任意の数のマテリアライズド・ビュー・サイトから構成される環境)で使用すると、データ収束を保証できます。

サイト優先順位による競合解消方法は、マルチマスター環境で主要な競合解消方法が失敗した場合の予備の方法としても適しています。

サポート・メカニズム 行が更新されたときにサイト情報を格納するための列を指定する必要があります。また、行が更新または挿入されたときにこのサイト列に更新中のサイトのグローバル名を移入するトリガーも作成する必要があります。このトリガーの例は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

レプリケーション環境に関係する各サイトの優先順位も定義する必要があります。この優先順位を定義するのは、更新または挿入を実行したサイトの優先順位に基づいて競合を解消するためです。サイト優先順位の定義は、優先グループに格納されます。

サイト優先順位による方法の実装 Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してサイト優先順位による競合解消方法を定義する方法については、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
レプリケーション・マネージメントAPIを使用してこのタイプの競合解消方法を定義する方法については、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

一意性競合の解消方法

Oracleには、一意性競合を解消するビルトインの方法が3つ用意されています。

- 発行元サイトのグローバル・サイト名を、発行元サイトの列値に追加する方法

- 生成された順序番号を、発行元サイトの列値に追加する方法

- 発行元サイトの行値を廃棄する方法

次の項では、一意性競合解消方法について、詳しく説明します。

注意:
Oracleのビルトインの一意性競合の解消方法では、実際にはレプリケーション環境のデータは収束しません(これらの方法は、制約違反を解決するテクニックのみを提供します)。Oracleの一意性競合の解消方法を使用する場合には、一意性競合の発生を知らせる通知メカニズムを同時に使用して、必要に応じて手動でレプリケート・データを収束する必要があります。

注意:
列に対する一意性競合の解消方法を追加するには、その列に対する一意索引の名前が、一意制約または主キー制約の名前と同じである必要があります。

サイト名の追加

サイト名の追加による競合解消方法では、トランザクションの発生元サイトのグローバル・データベース名が、dup_val_on_index例外を生成しているレプリケートされた列値に追加されます。この方法を使用すると一意の整合性制約に違反せずに列を挿入または更新できますが、複数のマスター・サイト間での収束は提供されません。そのために発生した矛盾は手動で解決する必要があるため、この方法は、なんらかの通知機能とともに使用することを想定しています。

注意:
サイト名の追加および順序の追加は、いずれもキャラクタ列のみに使用できます。

サイト名の追加による解消方法は、データの完全な正確さよりもデータの可用性の方が重要な場合に役立ちます。データがレプリケートされた後ですぐに使用可能な状態にするには、次のようにします。

- サイト名の追加による方法を選択します。

- 競合をロギングするのではなく、通知スキームを使用して、適切な担当者に重複を解消するように警告します。

サイト名の追加による方法では、一意性競合が発生すると、トランザクションの発行元サイトのグローバル・データベース名が、レプリケートされた列値に追加されます。名前は最初のピリオド(.)までが追加されます。たとえば、houston.example.comはhoustonになります。

順序の追加

順序の追加による競合解消方法では、生成された順序番号が、dup_val_on_index例外を生成している列値に追加されます。この方法を使用すると一意の整合性制約に違反せずに列を挿入または更新できますが、複数のマスター・サイト間での収束は提供されません。そのために発生した矛盾は手動で解決する必要があるため、この方法は、なんらかの通知機能とともに使用することを想定しています。

注意:
サイト名の追加および順序の追加は、いずれもキャラクタ列のみに使用できます。

サイト名の追加による解消方法は、データの完全な正確さよりもデータの可用性の方が重要な場合に役立ちます。データがレプリケートされた後ですぐに使用可能な状態にするには、次のようにします。

- 順序の追加による方法を選択します。

- 競合をロギングするのではなく、通知スキームを使用して、適切な担当者に重複を解消するように警告します。

順序の追加による方法では、生成された順序番号が列値に追加されます。列値は必要に応じて切り捨てられます。列値の生成された部分が列の長さを超えた場合、この競合解消方法ではエラーは解決されません。

廃棄

一意性の廃棄による競合解消方法では、エラーを発生させた発行元サイトの列を単に廃棄することによって一意性競合を解消します。この方法では、複数のマスター・サイト間での収束は保証されないため、通知機能とともに使用する必要があります。

追加による方法とは異なり、一意性の廃棄による方法では、データの正確さを検証できるまで、データの伝播が最小限にとどめられます。

削除の競合解消方法

Oracleでは、削除の競合を解消するビルトインの方法は提供していません。「削除の競合の回避」で説明されているように、データベースとフロントエンド・アプリケーションは削除の競合を回避するように設計する必要があります。これには、行に削除のマークを付け、プロシージャ・レプリケーションを使用して、論理的に削除された行を定期的にパージします。

関連項目:

- 削除の競合の回避方法は、「削除の競合の回避」を参照してください。

- レプリケーション環境に競合の回避方法を作成する方法は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

古い値の送信および比較

行の更新の競合を検出および解消するには、伝播サイトから受信サイトに新旧の行に関するデータを送信する必要があります。環境によって、更新の競合の検出および解消をサポートするために伝播されるデータの量は異なります。

DBMS_REPCAT.SEND_OLD_VALUESプロシージャおよびDBMS_REPCAT.COMPARE_OLD_VALUESプロシージャを使用することによって、競合の検出および解消に必要な場合にかぎり、古い値が送信され、データ伝播を削減できる場合があります。たとえば、タイムスタンプ列が更新されると必ず列が更新されることが保証される場合、最新のタイムスタンプによる競合の検出および解消方法には、列グループ内の非キー列および非タイムスタンプ列の古い値は必要ありません。

提案:
LOBデータ型をレプリケートしていて、これらの列で競合が発生しないと考えられる場合は、古い値の伝播をさらに最小化することが特に有効です。

注意:
予想される競合を検出および解消できるように、適切な古い値を伝播する必要があります。ユーザー指定の競合解消プロシージャでは、送信される古い列値NULLを適切に処理できる必要があります。データ伝播をさらに削減するためにSEND_OLD_VALUESプロシージャおよびCOMPARE_OLD_VALUESプロシージャを使用すると、予期しない競合に対する保護が低下します。

データ伝播をさらに削減するには、次のプロシージャを実行します。

DBMS_REPCAT.SEND_OLD_VALUES(
sname           IN  VARCHAR2,
oname           IN  VARCHAR2,
{ column_list   IN  VARCHAR2,
| column_table  IN  DBMS_UTILITY.VARCHAR2s | DBMS_UTILITY.LNAME_ARRAY,}
operation       IN  VARCHAR2 := 'UPDATE',
send            IN  BOOLEAN  := TRUE );

DBMS_REPCAT.COMPARE_OLD_VALUES(
sname           IN  VARCHAR2,
oname           IN  VARCHAR2,
{ column_list   IN  VARCHAR2,
| column_table  IN  DBMS_UTILITY.VARCHAR2s | DBMS_UTILITY.LNAME_ARRAY,}
operation       IN  VARCHAR2 := 'UPDATE',
compare         IN  BOOLEAN := TRUE );

これらのプロシージャを実行した後で、変更を有効にするために、DBMS_REPCAT.GENERATE_REPLICATION_SUPPORTプロシージャでmin_communicationをTRUEに設定してレプリケーション・サポートを生成する必要があります。

注意:
operationパラメータを使用すると、行が削除されたときまたは非キー列が更新されたとき(あるいはその両方)に、非キー列の古い値を送信するかどうかを決定できます。古い値を送信しない場合、古い値のかわりにNULLが送信され、更新または削除が適用されるときに古い値とターゲット・サイドの列の現在の値が等しいとみなされます。

古い列値に対して指定した動作は、DBA_REPCOLUMNデータ・ディクショナリ・ビューの2つの列、COMPARE_OLD_ON_DELETE(YまたはN)およびCOMPARE_OLD_ON_UPDATE(YまたはN)に公開されます。

送信および比較の例

次の例では、これらのプロシージャを使用してデータ伝播をさらに削減する方法を示します。列が3つあるrsmith.reportsという表を考えてみます。列1は主キーであり、独自の列グループ(列グループ1)を構成します。列2および列3は、2番目の列グループ(列グループ2)に属します。

図5-3 列グループとデータ伝播

2番目の列グループの競合解消方針は、サイト優先順位です。列2は、サイト名を含むVARCHAR2型の列です。列3は、LOB列です。LOBを更新するときは必ず、更新が行われたサイトのグローバル名で列2も更新する必要があります。LOBに対するピース単位の更新にはトリガーがないため、LOBに対してピース単位の更新を行う場合は常に列2を明示的に更新する必要があります。

DBMS_REPCAT.GENERATE_REPLICATION_SUPPORTプロシージャでmin_communicationをTRUEに設定してrsmith.reportsのレプリケーション・サポートを生成し、次にUPDATE文を使用して列2(サイト名)と列3(LOB)を変更するとします。サイト名の新しい値とLOBの新しい値が更新されているので、遅延リモート・プロシージャ・コール(RPC)にはこれらの値が含まれます。遅延RPCには、主キー(列1)の古い値、サイト名(列2)の古い値およびLOB(列3)の古い値も含まれます。

注意:
競合の検出および解消には、LOBの古い値は必要ありません。競合の検出と解消に必要なのは、列C2(サイト名)のみです。LOBの古い値を送信すると、伝播時間が大幅に増加する可能性があります。

列C2または列C3が更新されたときにLOBの古い値を伝播しない場合は、次のコールを実行します。

BEGIN
DBMS_REPCAT.SEND_OLD_VALUES(
sname           =>  'rsmith',
oname           =>  'reports',
column_list     =>  'c3',
operation       =>  'UPDATE',
send            =>  FALSE );
END;
/

BEGIN
DBMS_REPCAT.COMPARE_OLD_VALUES(
sname           =>  'rsmith',
oname           =>  'reports',
column_list     =>  'c3',
operation       =>  'UPDATE',
compare         =>  FALSE);
END;
/

変更を有効にするには、DBMS_REPCAT.GENERATE_REPLICATION_SUPPORTプロシージャでmin_communicationをTRUEに設定してrsmith.reportsのレプリケーション・サポートを生成する必要があります。続いてUPDATE文を使用して列2(サイト名)と列3(LOB)を変更するとします。遅延RPCには、主キー(列1)の古い値、サイト名(列2)の古い値と新しい値、およびLOB(列3)の新しい値が含まれます。遅延RPCは、主キーの新しい値とLOBの古い値についてはNULLを含みます。

注意:
Oracleの競合解消では、LOBのピース単位の更新はサポートしていません。

列オブジェクト使用時の送信および比較

リーフ属性がレプリケーション・キー列でない場合は、古い値を送信および比較するときに、列オブジェクトのリーフ属性を指定できます。たとえば、次のcust_address_typオブジェクト型を作成するとします。

CREATE TYPE cust_address_typ AS OBJECT
(street_address     VARCHAR2(40),
postal_code        VARCHAR2(10),
city               VARCHAR2(30),
state_province     VARCHAR2(10),
country_id         CHAR(2));
/

この型を列オブジェクトとして使用し、customers表を作成します。

CREATE TABLE customers
(customer_id        NUMBER(6),
cust_first_name    VARCHAR2(20),
cust_last_name     VARCHAR2(20),
cust_address       cust_address_typ,
phone_numbers      phone_list_typ);

customers表のcust_address_typ型のstreet_address属性の古い値を送信および比較する場合は、次のプロシージャを使用して、属性値を送信および比較するように指定します。

BEGIN
DBMS_REPCAT.SEND_OLD_VALUES(
sname           =>  'oe',
oname           =>  'customers',
column_list     =>  'cust_address.street_address', -- object attribute
operation       =>  'UPDATE',
send            =>   TRUE );
END;
/

BEGIN
DBMS_REPCAT.COMPARE_OLD_VALUES(
sname           =>  'oe',
oname           =>  'customers',
column_list     =>  'cust_address.street_address', -- object attribute
operation       =>  'UPDATE',
compare         =>   TRUE);
END;
/

注意:
1つの列オブジェクトにオブジェクト属性が複数レベルある場合、column_listパラメータに指定できるのは最後の属性(またはリーフ属性)のみです。中間の属性は指定できません。

列オブジェクト全体を送信および比較することも指定できます。たとえば、次のプロシージャでは、cust_address列オブジェクト全体を指定しています。

BEGIN
DBMS_REPCAT.SEND_OLD_VALUES(
sname           =>  'oe',
oname           =>  'customers',
column_list     =>  'cust_address', -- entire column object
operation       =>  'UPDATE',
send            =>   TRUE );
END;
/

BEGIN
DBMS_REPCAT.COMPARE_OLD_VALUES(
sname           =>  'oe',
oname           =>  'customers',
column_list     =>  'cust_address', -- entire column object
operation       =>  'UPDATE',
compare         =>   TRUE);
END;
/

関連項目:
DBMS_REPCAT.SEND_OLD_VALUESプロシージャおよびDBMS_REPCAT.COMPARE_OLD_VALUESプロシージャの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

6 レプリケーション環境の計画

レプリケーション環境の計画を開始する前に、これまでの章で説明したレプリケーションの概念およびアーキテクチャについて理解することが重要です。この章では、レプリケーションの概念およびアーキテクチャについて理解していることを前提に、レプリケーション環境の計画に関する重要な考慮事項について説明します。

この章には、次の項が含まれます。

- レプリケート表に関する考慮事項

- 初期化パラメータ

- マスター・サイトとマテリアライズド・ビュー・サイトの比較

- アドバンスト・レプリケーション環境の相互運用性

- スケジュール・リンクのガイドライン

- 遅延トランザクション・キューのスケジュール・パージのガイドライン

- シリアル伝播およびパラレル伝播

- デプロイメント・テンプレート

- 競合解消

- セキュリティとレプリケーション

- 耐障害性を実現するための設計

レプリケート表に関する考慮事項

次の項では、レプリケーション環境で使用する表に関する考慮事項について説明します。

- 主キーとレプリケート表

- 外部キーとレプリケート表

- レプリケート表のデータ型に関する考慮事項

- サポートされていない表タイプ

- 行レベルでの依存性の追跡

主キーとレプリケート表

各レプリケート表には、可能なかぎり主キーを設定します。主キーを設定できない場合、各レプリケート表に、表の各行の一意の識別子として使用できる列のセットが含まれている必要があります。レプリケーション環境で使用する表に主キーまたは一意の列のセットがない場合は、レプリケート表を必要に応じて修正します。さらに、マスター表またはマスター・マテリアライズド・ビューに基づいて主キー・マテリアライズド・ビューを作成する場合は、そのマスターに主キーを設定する必要があります。

外部キーとレプリケート表

外部キー参照制約を持つ表をレプリケートする場合は、親表で更新および削除が許可されていない場合を除き、常に外部キー列に索引を付けて、これらの索引をレプリケートすることをお薦めします。索引は自動的にはレプリケートされません。索引をレプリケートするには、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはDBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用して、索引を付けた表を含むマスター・グループに索引を追加します。

レプリケート表のデータ型に関する考慮事項

アドバンスト・レプリケーションでは、次のデータ型の列を持つ表およびマテリアライズド・ビューのレプリケーションをサポートしています。

- VARCHAR2

- NVARCHAR2

- NUMBER

- DATE

- TIMESTAMP

- TIME WITH TIME ZONE

- TIMESTAMP LOCAL TIME ZONE

- INTERVAL YEAR TO MONTH

- INTERVAL DAY TO SECOND

- RAW

- ROWID

- CHAR

- NCHAR

- BASICFILE記憶域を持つCLOB

- BASICFILE記憶域を持つNCLOB

- BASICFILE記憶域を持つBLOB

- CLOBとして格納されているXMLType

- 型継承または型進化を使用していないユーザー定義型

- 型継承または型進化を使用していない、オラクル社が提供する型

ピース単位の更新と追加がこれらのLOB列に適用されると、マルチマスター・レプリケーションに使用する遅延および同期のリモート・プロシージャ・コール・メカニズムによって、サポートされているLOBデータ型にピース単位の変更のみが伝播されます。ただし、マテリアライズド・ビューの定義問合せのWHERE句でLOB列は参照できません。

ユーザー定義型(列オブジェクト、オブジェクト表、REF、VARRAY、ネストした表など)を使用する表およびマテリアライズド・ビューはレプリケートできます。

アドバンスト・レプリケーションでは、次のデータ型の列を持つ表およびマテリアライズド・ビューのレプリケーションをサポートしていません。

- FLOAT

- BINARY_FLOAT

- BINARY_DOUBLE

- LONG

- LONG RAW

- SECUREFILE記憶域を持つCLOB

- SECUREFILE記憶域を持つNCLOB

- SECUREFILE記憶域を持つBLOB

- BFILE

- オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType

- Expression型

- 型継承または型進化を使用しているユーザー定義型

- 型継承または型進化を使用している、オラクル社が提供する型

アドバンスト・レプリケーションでサポートされるには、LONGデータ型を、BASICFILE記憶域を持つLOBに変換する必要があります。

マスター表または更新可能マテリアライズド・ビュー内のUROWID列のレプリケーションもサポートされていません。ただし、読取り専用マテリアライズド・ビューではUROWID列を使用できます。

関連項目:

- レプリケート表でのLONG列からLOB列への変換の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

サポートされていない表タイプ

アドバンスト・レプリケーションでは、次の表タイプのレプリケーション、およびそれらの表タイプに基づくマテリアライズド・ビューをサポートしていません。

- 表圧縮機能によって圧縮された表

- 仮想列を含む表

- 一時表

- フラッシュバック・データ・アーカイブの表

さらに、透過的データ暗号化を使用して暗号化された列のある表は、マスター・レプリケーションではサポートされていません。ただし、暗号化された列のある表に基づくマテリアライズド・ビューはサポートされています。

行レベルでの依存性の追跡

表を作成するときは、システム変更番号(SCN)を追跡するために次のオプションを指定できます。

- NOROWDEPENDENCIES。SCNがデータ・ブロック・レベルで追跡されることを指定します(デフォルト)。

- ROWDEPENDENCIES。SCNが表の各行に対して追跡されることを指定します。

ROWDEPENDENCIESオプションを使用すると、パラレル伝播使用時のパフォーマンスとスケーラビリティが向上しますが、このオプションでは、各行に6バイトの追加記憶領域が必要になります。

次のSQL文では、ROWDEPENDENCIESオプションを使用して表を作成します。

CREATE TABLE order_items
(order_id          NUMBER(12),
line_item_id       NUMBER(3)  NOT NULL,
product_id         NUMBER(6)  NOT NULL,
unit_price         NUMBER(8,2),
quantity           NUMBER(8)
) ROWDEPENDENCIES;

このorder_items表の各行でSCNが追跡されます。表がクラスタの一部である場合は、CREATE CLUSTER文でROWDEPENDENCIESオプションを使用することもできます。

関連項目:
ROWDEPENDENCIESオプションの詳細は「データ伝播の依存性の維持」を参照してください。

初期化パラメータ

表6-1に、レプリケーション環境の操作性、信頼性およびパフォーマンスにとって重要な初期化パラメータを示します。この表では、各パラメータが変更可能かどうかを示しています。変更可能な初期化パラメータは、インスタンスの実行中に、ALTER SYSTEM文を使用して変更できます。一部の変更可能なパラメータは、ALTER SESSION文を使用して1つのセッションでも変更できます。

表6-1 アドバンスト・レプリケーションにおいて重要な初期化パラメータ

パラメータ

値

説明

推奨事項

GLOBAL_NAMES

デフォルト: false

範囲: trueまたはfalse

変更: 可

データベース・リンクの名前を接続先データベースの名前と同じにするかどうかを指定します。

GLOBAL_NAMESは、マスター・サイトやマテリアライズド・ビュー・サイトなどのレプリケーション環境に含まれる各データベースでTRUEに設定する必要があります。

JOB_QUEUE_PROCESSES

デフォルト: 1000

範囲: 0から1000

変更: 可

各インスタンスのJnジョブ・スレーブの番号を指定します(J000 ... J999)。ジョブ・スレーブでは、DBMS_JOBによって作成された要求が処理されます。

サイトでJOB_QUEUE_PROCESSESを0に設定した場合、サイトのすべてのグループに対して手動で管理要求を適用し、遅延トランザクション・キューを手動でプッシュおよびパージする必要があります。

このパラメータは設定解除するか、または 1以上に設定する必要があります。設定する場合は、同時に実行できるジョブの最大数に1を加えた値と同じ値に設定する必要があります。

MEMORY_MAX_TARGET

デフォルト: 0

範囲: 0からOracle Databaseで使用可能な物理メモリー・サイズ

変更: 不可

システム全体で使用できるOracle Database用の最大メモリー量を指定します。

MEMORY_TARGETパラメータがゼロ以外の値に設定されているときに、Oracle Databaseの最大メモリー使用量を指定する必要がある場合は、このパラメータをゼロ以外の大きな値に設定してください。

MEMORY_TARGET

デフォルト: 0

範囲: 152MBからMEMORY_MAX_TARGET設定

変更: 可

システム全体で使用できるOracle Database用のメモリー量を指定します。

MEMORY_TARGETをゼロ以外の大きな値に設定することによって(使用しているプラットフォームでこのパラメータがサポートされている場合)、Oracle Databaseのメモリー使用量の自動チューニングを使用可能にすることをお薦めします。

OPEN_LINKS

デフォルト: 4

範囲: 0から255

変更: 不可

1つのセッションで同時にオープンするリモート・データベース接続の最大数を指定します。この接続には、データベース・リンクと呼ばれるスキーマ・オブジェクトと、外部プロシージャおよびカートリッジ(それぞれ別のプロセスを使用します)が含まれます。

同期レプリケーションを使用する場合は、OPEN_LINKSを少なくともマスター・サイト数と同じ数に設定する必要があります。たとえば、マスター・サイトが5つある環境では、OPEN_LINKSを少なくとも5に設定する必要があります。

PARALLEL_MAX_SERVERS

デフォルト: 自動的に導出される。

範囲: 0から3600

変更: 可

インスタンスのパラレル実行プロセスおよびパラレル・リカバリ・プロセスの最大数を指定します。インスタンス起動時に作成されるプロセスの数は、要求が増えるに従い、このパラメータに指定した値まで増えます。

パラレル伝播を使用する場合は、パラレル伝播をサポートするのに十分な大きさの値を指定してください。

PARALLEL_MIN_SERVERS

デフォルト: 0

範囲: 0からPARALLEL_MAX_SERVERSの値

変更: 可

インスタンスのパラレル実行プロセスの最小数を指定します。この値は、インスタンスの起動時に作成されるパラレル実行プロセスの数です。

パラレル伝播を使用する場合、各ストリームに少なくとも1つのプロセスがあることを確認してください。

PROCESSES

デフォルト: 100

範囲: 6からオペレーティング・システム固有の制限。

変更: 不可

Oracleに同時に接続できる、オペレーティング・システムのユーザー・プロセスの最大数を指定します。

このパラメータの値は、ロック、ジョブ・スレーブ、パラレル実行プロセスなどのすべてのバックグラウンド・プロセスについて使用できる値にする必要があります。

REPLICATION_DEPENDENCY_TRACKING

デフォルト: true

範囲: trueまたはfalse

変更: 不可

データベースに対する読取り/書込み操作の依存性の追跡を使用可能または使用禁止にします。依存性の追跡は、レプリケーション環境で変更をパラレル伝播するときは必須です。

TRUE: 依存性の追跡を使用可能にします。

FALSE: データベースに対する読取り/書込み操作の実行を高速化しますが、パラレル伝播を実行するための依存性情報は生成しません。

通常はTRUEを指定します。アプリケーションがレプリケート表に読取り/書込み操作を実行しないことが確認できない場合は、FALSEを指定しないでください。

SGA_TARGET

デフォルト: 0

範囲: 64MBからオペレーティング・システム固有の制限。

変更: 可

すべてのSGAコンポーネントの合計サイズを指定します。

MEMORY_MAX_TARGETとMEMORY_TARGETが0(ゼロ)に設定されている場合、SGA_TARGETをゼロ以外の大きな値に設定することによって、SGAメモリーの自動チューニングを使用可能にすることをお薦めします。

SHARED_POOL_SIZE

デフォルト: 0

SGA_TARGETがゼロ以外の値に設定されている場合: このパラメータを指定しないと、デフォルトは0になります(Oracle Databaseによって内部的に決定されます)。このパラメータを指定すると、そのユーザー指定値はメモリー・プールの最小値を示します。

SGA_TARGETがゼロに設定されていない場合(32ビット・プラットフォーム): 64 MB。最も近いグラニュル・サイズに切り上げられます。

SGA_TARGETがゼロに設定されていない場合(64ビット・プラットフォーム): 128 MB。最も近いグラニュル・サイズに切り上げられます。

範囲: オペレーティング・システム固有の制限までのグラニュル・サイズ。

変更: 可

共有プールのサイズをバイト単位で指定します。共有プールには、共有カーソル、ストアド・プロシージャ、制御構造およびその他の構造が含まれます。この値を大きくするほど、マルチユーザー・システムのパフォーマンスは向上します。この値を小さくすると、使用するメモリー量は減ります。

一般的に、Oracle Databaseの共有プールは、非レプリケーション環境よりもレプリケーション環境の場合の方を大きくする必要があります。

共有プールの使用率は、ビューV$SGASTATを問い合せることにより監視できます。

関連項目:

- これらの初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

- MEMORY_TARGET、MEMORY_MAX_TARGETおよびSGA_TARGETパラメータの詳細は、『Oracle Database管理者ガイド』を参照してください。

マスター・サイトとマテリアライズド・ビュー・サイトの比較

レプリケーション環境を計画するときは、レプリケーション環境に関係する各サイトをマスター・サイトにするかマテリアライズド・ビュー・サイトにするかを決定する必要があります。これを決定する際は、両方のタイプのレプリケーション・サイトの特性と利点を考慮してください。1つのレプリケーション環境で、マスター・サイトとマテリアライズド・ビュー・サイトの両方をサポートできます。

表6-2 マスター・サイトとマテリアライズド・ビュー・サイトの特性

マスター・サイト

マテリアライズド・ビュー・サイト

通常、少数のマスター・サイトと通信しますが、多数のマテリアライズド・ビュー・サイトとも通信する場合もあります。

1つのマスター・サイトまたは1つのマスター・マテリアライズド・ビュー・サイトと通信します。

他のマスター・サイトのデータの完全なコピーである大量のデータを含んでいます。

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータのサブセットである少量のデータを含んでいます。

通常、データ伝播の間隔は短く、継続的に通信します。

バルク・データ移送の間隔は長く、定期的に通信します。

マスター・サイトの利点

マスター・サイトには次のような利点があります。

- リモート・サイトからのデータ・アクセスの可用性を高めるサポートを提供します。

- 変更が自動的にかつ通常は短い間隔で伝播されるので、データ操作言語(DML)による変更が頻繁に行われても適切に対処できます。

- 表をロックせずに、DMLによる変更とデータ伝播を同時に行うことができます。

- フェイルオーバーによる保護を提供できます。

マスター・サイトの設定には、アドバンスト・レプリケーション・インタフェースの「レプリケーション用のマスター・サイトの構成」ウィザードまたはレプリケーション・マネージメントAPIのいずれかを使用します。

関連項目:

- 「レプリケーション用のマスター・サイトの構成」ウィザードを使用してOracle Enterprise Managerでマスター・サイトを設定する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

- レプリケーション・マネージメントAPIを使用してマスター・サイトを設定する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- フェイルオーバーによる保護を使用したレプリケーション環境の設計の詳細は、「耐障害性を実現するための設計」を参照してください。

マテリアライズド・ビュー・サイトの利点

マテリアライズド・ビュー・サイトには次のような利点があります。

- モバイル・コンピューティングをサポートしています。

- マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータのサブセットを含められます。

マテリアライズド・ビュー・サイトの設定には、アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードまたはレプリケーション・マネージメントAPIのいずれかを使用できます。

関連項目:

- 「レプリケーション用のマテリアライズド・ビュー・サイトの構成」ウィザードを使用してOracle Enterprise Managerでマテリアライズド・ビュー・サイトを設定する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

- レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

マテリアライズド・ビューの準備

マテリアライズド・ビュー・レプリケーションに関する問題の多くは、環境の準備が正しく行われていないことによるものです。マテリアライズド・ビュー環境を作成するには、事前に次の4つのことを行う必要があります。

- 必要なスキーマの作成

- 必要なデータベース・リンクの作成

- 適切な権限の割当て

- 十分なジョブ・プロセスの割当て

アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードは、これらの作業を自動的に実行します。以降では、レプリケーション環境の理解とレプリケーション・マネージメントAPIの使用に役立つ情報を提供します。「設定ウィザード」を実行した後で、必要なマテリアライズド・ビュー・ログを作成します。インタフェースを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

関連項目:
「マテリアライズド・ビュー・ログの作成」

アドバンスト・レプリケーション・インタフェースを使用できない場合、レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』の第2章でマテリアライズ・ビュー・サイトの設定に関する説明を参照してください。

次の項では、アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードまたは『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』に記述されているスクリプトを使用してマテリアライズド・ビュー・サイトを設定する方法について説明します。

マテリアライズド・ビュー・サイトのユーザーの作成

各マテリアライズド・ビューには、マテリアライズド・ビュー・サイトで管理アクティビティやリフレッシュ・アクティビティを実行する何人かのユーザーが必要です。マテリアライズド・ビューの管理者とリフレッシャには、必要な権限を作成して付与する必要があります。

マスター・サイト・ユーザーの作成

マテリアライズド・ビュー・サイトのユーザーのかわりに作業を実行するには、ターゲット・マスター・サイトにも同等のプロキシ・ユーザーが必要です。通常は、プロキシ・マテリアライズド・ビュー管理者とプロキシ・リフレッシャを作成します。

マテリアライズド・ビュー・サイトでのスキーマの作成

リモート・データベースのマテリアライズド・ビューを含むスキーマは、マスター・データベースのマスター表を含むスキーマに対応している必要があります。したがって、マテリアライズド・ビューを使用してレプリケートするマスター表を含むスキーマを識別してください。マスター・データベースのターゲット・スキーマを識別した後、リモート・データベースで、対応するアカウントを同じ名前で作成します。たとえば、すべてのマスター表がny.example.comデータベースのsalesスキーマ内にある場合は、対応するsalesスキーマをマテリアライズド・ビュー・データベースsf.example.comに作成します。

関連項目:
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』に記載されている手順では、マテリアライズド・ビュー・グループを作成する指示の中で説明されているスクリプトの一部として、必要なスキーマが作成されます。

データベース・リンクの作成

マテリアライズド・ビューの定義問合せでは、1つ以上のデータベース・リンクを使用してリモート表のデータを参照します。マテリアライズド・ビューを作成するには、使用する予定のデータベース・リンクが使用可能になっている必要があります。さらに、リモート・データベースにアクセスするためにデータベース・リンクで使用するアカウントには、セキュリティ・コンテキストが定義され、そのコンテキストに基づいてマテリアライズド・ビューが作成され、リフレッシュが実行されます。

正常な動作を保証するために、マテリアライズド・ビューの定義問合せでは、ユーザー名とパスワードが定義に埋め込まれているデータベース・リンクを使用する必要があります(マテリアライズド・ビューを作成するときは、パブリック・データベース・リンクを使用できません)。ユーザー名とパスワードが埋め込まれているデータベース・リンクは常に、指定されたアカウントを使用してリモート・データベースとの接続を確立します。また、リンクで使用するリモート・アカウントには、マテリアライズド・ビューの定義問合せの中で参照されるデータにアクセスするために必要なSELECT権限が必要です。

マテリアライズド・ビューを作成するには、いくつかの管理データベース・リンクを作成する必要があります。具体的には、マテリアライズド・ビュー・サイトからマスター・サイトへのPUBLICデータベース・リンクを作成します。これを作成すると、各プライベート・データベース・リンク内にUSING句を含める必要がなくなるため、プライベート・データベース・リンクを定義しやすくなります。また、マテリアライズド・ビュー管理者からプロキシ管理者へのプライベート・データベース・リンクおよびプロパゲータから受信者へのプライベート・データベース・リンクも作成する必要がありますが、これらのデータベース・リンクは、アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードを使用すると自動的に作成されます。

関連項目:
詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のセキュリティ・オプションに関する説明を参照してください。

管理データベース・リンクを作成した後、マテリアライズド・ビュー・データベースの各レプリケート・マテリアライズド・ビュー・スキーマをマスター・データベースの対応するスキーマに接続するプライベート・データベース・リンクを作成する必要があります。マテリアライズド・ビュー・データベースの各プライベート・データベース・リンクには、対応付けられたマスター・データベースのアカウント情報を埋め込むことが必要です。たとえば、マテリアライズド・ビュー・データベースのhrスキーマには、hrというユーザー名とパスワードを使用してマスター・データベースに接続するプライベート・データベース・リンクが必要です。

図6-1 推奨されるスキーマおよびデータベース・リンク構成

マルチマスター・レプリケーションの場合、レプリケーション・プロパゲータおよび受信者スキーマの仮想プライベート・データベース(VPD)の制限はありません。マテリアライズド・ビューの場合、マテリアライズド・ビューに対する定義問合せは、VPDによって変更されません。VPDは、マテリアライズド・ビューの作成とリフレッシュの両方を実行するスキーマに対してNULLポリシーを戻す必要があります。USING TRUSTED CONSTRAINTS句を指定した場合は、NULL以外のVPDポリシーを持つマテリアライズド・ビューを作成できます。この場合、マテリアライズド・ビューが正しく動作することを確認します。マテリアライズド・ビューの結果は、VPDポリシーによってフィルタ処理された行と列に基づいて計算されます。したがって、正しい結果を得るには、マテリアライズド・ビュー定義をVPDポリシーで調整する必要があります。

関連項目:

- データベース・リンクの詳細は、『Oracle Database管理者ガイド』を参照してください。

- VPDの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

- アドバンスト・レプリケーションおよびOracle Label Securityの詳細は、Oracle Label Security管理者ガイドを参照してください。

権限の割当て

マテリアライズド・ビューの作成者と所有者は、ともにマテリアライズド・ビューの定義SELECT文を発行できる必要があります。マテリアライズド・ビューの所有者とは、マテリアライズド・ビューが含まれているスキーマのことです。レプリケーション管理者またはマテリアライズド・ビュー管理者以外のユーザーがマテリアライズド・ビューを作成する場合は、そのユーザーにCREATE MATERIALIZED VIEW権限および定義SELECT文を実行する適切なSELECT権限が付与されている必要があります。

関連項目:
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』に記載されている手順では、マテリアライズド・ビュー・グループを作成する指示の中で説明されているスクリプトの一部として、必要な権限が付与されます。権限要件は、「マテリアライズド・ビューの操作に必要な権限」でも説明されています。

マスター・サイトでのスケジュール・パージ

遅延トランザクション・キューのサイズを適正に保つために、パージ操作をスケジュールして、正常に送信されたすべての遅延トランザクションを遅延トランザクション・キューから削除します。この操作はマスター・サイトですでに実行済の場合があります。パージ操作を再びスケジュールしてもマスター・サイトに悪影響はありませんが、パージ・スケジュールの特性が変更される可能性があります。

スケジュール・プッシュ

マテリアライズド・ビュー・サイトでプッシュをスケジュールすると、データベース・リンクを使用して、マテリアライズド・ビュー・サイトの遅延トランザクションが対応するターゲット・マスター・サイトに自動的に伝播されます。このタイプのデータベース・リンクは、スケジュール・リンクと呼ばれます。マテリアライズド・ビュー・グループは1つのターゲット・マスター・サイトのみを持つので、通常、マテリアライズド・ビュー・サイトの各マテリアライズド・ビュー・グループには1つのスケジュール・リンクのみが存在します。

ジョブ・スレーブの割当て

レプリケーション環境の自動化を処理するために、十分なジョブ・スレーブを割り当てることが重要です。ジョブ・スレーブは、遅延トランザクション・キューの伝播、遅延トランザクション・キューのパージ、マテリアライズド・ビューのリフレッシュなどを自動的に行います。

マルチマスター・レプリケーションの場合、各マスター・サイト間にスケジュール・リンクがあります。たとえば、マスター・サイトが6つある場合、各サイトには他の5つのサイトへのスケジュール・リンクがあります。通常、スケジュール・リンクごとにプロセスが1つ必要です。遅延トランザクション・キューのパージやその他のユーザー定義ジョブのために、追加のジョブ・プロセスが必要になります。

マテリアライズド・ビュー・レプリケーションの特性として、マテリアライズド・ビュー・サイトには、通常、マスター・データベースへのスケジュール・リンクが1つあり、少なくとも1つのジョブ・プロセスが必要です。マテリアライズド・ビュー・サイトで必要なジョブ・プロセスの数は、パージ・スケジュール、ユーザー定義ジョブおよびスケジュール・リンクに依存しますが、通常は1つから3つを必要とします。また、それぞれの並列度に対して少なくとも1つのジョブ・スレーブが必要です。

ユーザーがアプリケーション・インタフェースを使用してマテリアライズド・ビューを手動でリフレッシュする場合は、スケジュール・リンクを作成する必要がなくなり、マテリアライズド・ビュー・サイトで必要なジョブ・プロセスが1つ減ります。

ジョブ・スレーブは、データベースの初期化パラメータ・ファイルにあるJOB_QUEUE_PROCESSES初期化パラメータを使用して定義されます。この初期化パラメータは、変更可能です。そのため、インスタンス実行中に変更できます。ジョブ・スレーブの間隔は自動的に判断されます。つまり、ジョブ・スレーブが起動してジョブを実行するタイミングはOracleが判断します。

関連項目:
JOB_QUEUE_PROCESSESの詳細は、「初期化パラメータ」および『Oracle Databaseリファレンス』を参照してください。

マテリアライズド・ビュー・ログの作成

リモート・マテリアライズド・ビュー・サイトのマテリアライズド・ビュー・グループおよびマテリアライズド・ビューを作成する前に、必要なマテリアライズド・ビュー・ログをマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに作成しておく必要があります。マテリアライズド・ビュー・ログは、高速リフレッシュを使用するマテリアライズド・ビューを1つでもサポートしているすべてのマスター表またはマスター・マテリアライズド・ビューで必要になります。

マテリアライズド・ビュー・ログを作成するには、次の権限が必要です。

- CREATE ANY TABLE

- CREATE ANY TRIGGER

- SELECT(マテリアライズド・ビュー・ログのマスターに対する権限)

- COMMENT ANY TABLE

関連項目:
Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにマテリアライズド・ビュー・ログを作成する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

マテリアライズド・ビュー・ログへの列のロギング

マテリアライズド・ビュー・ログを作成する場合は、必要に応じてログに列を追加できます。マテリアライズド・ビューを高速リフレッシュするには、マテリアライズド・ビュー・ログに次のタイプの列を追加する必要があります。

- 副問合せのWHERE句で参照される列で、等価結合の一部ではなく、主キー列でもない列。このような列は、フィルタ列と呼ばれます。

- 副問合せが多対多または1対多のいずれかの関係の場合に、等価結合内の列で主キー列ではない列。副問合せが多対1の場合は、マテリアライズド・ビュー・ログに結合列を追加する必要はありません。

コレクション列はマテリアライズド・ビュー・ログに追加できません。また、完全リフレッシュを使用するマテリアライズド・ビューの場合は、マテリアライズド・ビュー・ログは不要です。

たとえば、次のようなDDLを考えてみます。

1) CREATE MATERIALIZED VIEW oe.customers REFRESH FAST AS
2)  SELECT * FROM oe.customers@orc1.example.com c
3)  WHERE EXISTS
4)    (SELECT * FROM oe.orders@orc1.example.com o
5)     WHERE c.customer_id = o.customer_id AND o.order_total > 20000);

このDDLの5行目では、WHERE句内で3つの列が参照されています。列orders.customer_idとcustomers.customer_idは等価結合句の一部として参照されています。customers.customer_idは主キー列であるため、この列はデフォルトでロギングされますが、orders.customer_idは主キー列ではないため、マテリアライズド・ビュー・ログに追加する必要があります。また、列orders.order_totalは追加フィルタ列であるため、これもロギングする必要があります。

したがって、orders.customer_idとorders.order_totalをoe.orders表のマテリアライズド・ビュー・ログに追加します。

これらの列が追加されたマテリアライズド・ビュー・ログを作成するには、次の文を発行します。

CREATE MATERIALIZED VIEW LOG ON oe.orders
WITH PRIMARY KEY (customer_id,order_total);

oe.customers表にマテリアライズド・ビュー・ログがすでに存在する場合は、次の文を発行してこれらの列を追加できます。

ALTER MATERIALIZED VIEW LOG ON oe.orders ADD (customer_id,order_total);

ユーザー定義データ型を使用している場合は、列オブジェクトの属性をマテリアライズド・ビュー・ログにロギングできます。たとえば、oe.customers表にcust_address.postal_code属性がある場合、次の文を発行すると、この属性をマテリアライズド・ビュー・ログにロギングできます。

ALTER MATERIALIZED VIEW LOG ON oe.customers ADD (cust_address.postal_code);

作成するマテリアライズド・ビューの定義問合せを分析し、マテリアライズド・ビュー・ログに追加する必要がある列を識別することをお薦めします。マテリアライズド・ビュー・ログに列を追加せずに、追加列を必要とするマテリアライズド・ビューを作成またはリフレッシュしようとした場合、マテリアライズド・ビューの作成またはリフレッシュは失敗します。

注意:
マテリアライズド・ビューを高速リフレッシュするには、副問合せ内の結合列をマテリアライズド・ビュー・ログに追加する必要があります(結合列が主キー列ではなく、副問合せが多対多または1対多のいずれかの関係の場合)。副問合せが多対1の場合は、マテリアライズド・ビュー・ログに結合列を追加する必要はありません。

関連項目:

- 副問合せを使用するマテリアライズド・ビューの詳細は、「マテリアライズド・ビューを使用したデータのサブセット化」を参照してください。

- 副問合せを含むマテリアライズド・ビューに関する追加情報は、「副問合せを使用するマテリアライズド・ビューでの制限事項」を参照してください。

- マテリアライズド・ビュー・ログの作成方法の詳細は、「マテリアライズド・ビュー・ログの作成」を参照してください。

マテリアライズド・ビュー環境の作成

マテリアライズド・ビュー環境は、様々な場所から様々な方法で作成できます。一般的には、マスター・サイトのデプロイメント・テンプレートを使用してマテリアライズド・ビュー環境をローカルで事前作成し、それをターゲット・マテリアライズド・ビュー・サイトに個別に配置します。

また、マテリアライズド・ビュー・サイトへの接続を確立してマテリアライズド・ビュー環境を直接作成する方法もあります。

レプリケーション・マネージメント・インタフェースを使用したマテリアライズド・ビュー環境の作成

デプロイメント・テンプレートを使用してOracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでマテリアライズド・ビュー環境をまとめて作成する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

また、リモート・マテリアライズド・ビュー・サイトに直接接続し、Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマテリアライズド・ビュー環境を個別に作成する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

図6-2 マテリアライズド・ビュー環境作成のためのフローチャート

レプリケーション・マネージメントAPIを使用したマテリアライズド・ビュー環境の作成

デプロイメント・テンプレートを使用してレプリケーション・マネージメントAPIでマテリアライズド・ビュー環境をまとめて事前作成する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のデプロイメント・テンプレートの作成に関する説明を参照してください。

また、リモート・マテリアライズド・ビュー・サイトに直接接続し、レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを個別に作成する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のマテリアライズド・ビュー・グループの作成に関する説明を参照してください。

新規マテリアライズド・ビュー・サイトを追加するときの問題の回避

1つ以上のマテリアライズド・ビュー・サイトを含むマテリアライズド・ビュー環境を作成した後、新しくマテリアライズド・ビュー・サイトを追加することがあります。次の2つの条件がどちらも成立する場合は、新規マテリアライズド・ビュー・サイトに作成したマテリアライズド・ビューを高速リフレッシュしようとしたときに問題が発生することがあります。

- 新規マテリアライズド・ビュー・サイトのマテリアライズド・ビューと、他のマテリアライズド・ビュー・サイトの既存マテリアライズド・ビューが、同一のマスター表またはマスター・マテリアライズド・ビューに基づいている場合。

- 新規マテリアライズド・ビュー・サイトに新規マテリアライズド・ビューを作成中に、既存のマテリアライズド・ビューをリフレッシュする場合。

問題が発生するのは、新規マテリアライズド・ビューが最初の高速リフレッシュを実行する前に、マスターのマテリアライズド・ビュー・ログがパージされたときです。このようなときに新規マテリアライズド・ビュー・サイトでマテリアライズド・ビューを高速リフレッシュしようとすると、次のエラーが発生することがあります。

ORA-12004 REFRESH FAST cannot be used for materialized view materialized_view_name
ORA-12034 materialized view log on materialized_view_name younger than last refresh

これらのエラーを受け取った場合の解決策は、新規マテリアライズド・ビューの完全リフレッシュを実行することのみです。

この問題を回避するには、次のオプションのいずれかを選択します。

- デプロイメント・テンプレートを使用してマテリアライズド・ビュー・サイトにマテリアライズド・ビュー環境を作成します。デプロイメント・テンプレートを使用すると、この問題は発生しません。

関連項目:
デプロイメント・テンプレートの詳細は、第4章「デプロイメント・テンプレートの概要およびアーキテクチャ」を参照してください。

- 新規マテリアライズド・ビュー・サイトにダミーのマテリアライズド・ビューを作成してから、本番のマテリアライズド・ビューを作成します。ダミーのマテリアライズド・ビューを作成することにより、本番のマテリアライズド・ビューを作成中にマテリアライズド・ビュー・ログがパージされなくなります。

マテリアライズド・ビュー・サイトにダミーのマテリアライズド・ビューを作成する場合は、次の手順を実行します。

1. マスター表またはマスター・マテリアライズド・ビューに基づいたdummy_mviewという名前のダミーのマテリアライズド・ビューを作成します。たとえば、salesというマスター表に基づいたダミー・マテリアライズド・ビューを作成するには、新規マテリアライズド・ビュー・サイトで次の文を発行します。

CREATE MATERIALIZED VIEW dummy_mview REFRESH FAST AS
SELECT * FROM pr.sales@orc1.example.com WHERE 1=0;

2. 本番のマテリアライズド・ビューを新規マテリアライズド・ビュー・サイトに作成します。

3. 新規マテリアライズド・ビュー・サイトで本番のマテリアライズド・ビューの高速リフレッシュを実行します。

4. ダミー・マテリアライズド・ビューを削除します。

アドバンスト・レプリケーション環境の相互運用性

異なるサイトで別々のリリースのOracle Databaseを含むアドバンスト・レプリケーション環境の構成を計画する場合、その環境は次の要件を満たす必要があります。

- Oracle Database 11gのマスター・サイトは、Oracle9i リリース2(9.2)以上のマスター・サイトとのみ相互運用できる。

- Oracle Database 11gのマテリアライズド・ビュー・サイトは、Oracle9i リリース2(9.2)以上のマスター・サイトとのみ相互運用できる。

- Oracle Database 11gのマスター・サイトは、Oracle9i リリース2(9.2)以上のマテリアライズド・ビュー・サイトとのみ相互運用できる。

関連項目:
NCHARまたはNVARCHAR2データ型を使用するアドバンスト・レプリケーション環境における相互運用性の詳細は、「Unicodeに対するレプリケーション・サポート」を参照してください。

スケジュール・リンクのガイドライン

スケジュール・リンクによって、あるマスター・サイトから別のマスター・サイトへの遅延トランザクション・キューの伝播方法、または、あるマテリアライズド・ビュー・サイトからそのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトへの遅延トランザクション・キューの伝播方法が決まります。スケジュール・リンクを作成すると、遅延トランザクション・キューをシステムの別のサイトにプッシュするジョブがローカル・ジョブ・キューに作成されます。リモート・マスター・サイトへの遅延トランザクションの伝播は、レプリケーション・プロパゲータのセキュリティ・コンテキスト内で行われます。

スケジュール・リンクを構成すると、シリアル伝播またはパラレル伝播を使用して情報をプッシュできます。一般的に、parallelismパラメータを1に設定した場合でも、パラレル伝播を使用する必要があります。

レプリケーション環境のスケジュール・リンクを作成する前に、レプリケーションをシステム全体でグローバルに発生させる方法を慎重に検討する必要があります。たとえば、一定の間隔で遅延トランザクションを伝播できます。この場合、プッシュする頻度と時刻を決定する必要があります。また、リアルタイム・レプリケーション(同期レプリケーション)をシミュレートするために、各スケジュール・リンクを使用して、マスター・サイトの遅延トランザクション・キューをその接続先に連続的にプッシュする場合もあります。

あるいは、夜間など、必ず接続できる時間帯や通信コストが最低の時間帯にプッシュをスケジュールする場合もあります。さらに、レプリケーションによるネットワーク・リソースへの負荷を分散するために、各マスター・サイト間でリンクのスケジュールをずらすこともできます。

関連項目:
シリアル伝播およびパラレル伝播に関連する問題の詳細は、「シリアル伝播およびパラレル伝播」を参照してください。

定期的なプッシュのスケジューリング

サイトの遅延トランザクション・キューをリモートの接続先に定期的にプッシュするようにスケジュールできます。たとえば、1日に1回または1時間に1回というように設定できます。これを行うには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャを使用し、表6-3に示されている設定を指定します。

表6-3 定期的なプッシュのスケジューリングの設定

SCHEDULE_PUSHプロシージャのパラメータ

値

delay_seconds

0

interval

適切な日付式。たとえば、1時間の間隔を指定するには、'sysdate + 1/24'を使用します。

定期的なプッシュのスケジューリングには、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用することもできます。これを行うには、スケジュール・リンクを設定するときに、「遅延秒数」を0(ゼロ)に設定します。

次に、遅延トランザクション・キューを定期的にプッシュする間隔(「送信間隔」コントロール)を設定します。

1時間ごとの定期的プッシュをスケジュールする例を、次に示します。

BEGIN
DBMS_DEFER_SYS.SCHEDULE_PUSH (
destination => 'orc2.example.com',
interval => 'SYSDATE + (1/24)',
next_date => SYSDATE,
delay_seconds => 0);
END;
/

関連項目:

- 遅延秒数の設定の詳細は、「遅延秒数」を参照してください。

- DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- Enterprise Managerでのアドバンスト・レプリケーション・インタフェースの使用方法については、このインタフェースのオンライン・ヘルプを参照してください。

連続的なプッシュのスケジューリング

非同期レプリケーション・メカニズムを使用している場合でも、スケジュール・リンクを構成すると、連続的なリアルタイム・レプリケーションをシミュレートできます。これを行うには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャを使用し、表6-4に示されている設定を指定します。

表6-4 連続的なプッシュをシミュレートする設定

SCHEDULE_PUSHプロシージャのパラメータ

値

delay_seconds

1200

interval

delay_seconds設定よりも低い値

parallelism

1以上

execution_seconds

delay_seconds設定よりも高い値

このように設定すると、「間隔」に設定した時間中ずっと、遅延トランザクション・キューに入れられるトランザクションが連続的にプッシュされます。delay_secondsパラメータに指定されている間に、伝播するトランザクションが遅延トランザクション・キューにない場合は、このジョブにより使用されているリソースが解放され、次のジョブ・スレーブが使用可能になったときに新しく開始されます。

parallelismパラメータを0(ゼロ)に設定してシリアル伝播を使用している場合は、delay_secondsおよびintervalパラメータの設定を低くして環境に適切な値にし、連続的なプッシュをシミュレートできます。ただし、シリアル伝播を使用している場合、連続的なプッシュのシミュレーションでプッシュ・ジョブを頻繁に開始する必要がある場合はコストが高くなります。

連続的なプッシュをシミュレートする例を次に示します。

BEGIN
DBMS_DEFER_SYS.SCHEDULE_PUSH (
destination => 'orc2.example.com',
interval => 'SYSDATE + (1/144)',
next_date => SYSDATE,
parallelism => 1,
execution_seconds => 1500,
delay_seconds => 1200);
END;
/

関連項目:

- 遅延秒数の設定の詳細は、「遅延秒数」を参照してください。

- シリアル伝播およびパラレル伝播に関連する問題の詳細は、「シリアル伝播およびパラレル伝播」を参照してください。

- DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

遅延トランザクション・キューのスケジュール・パージのガイドライン

スケジュール・パージによって、マスター・サイトまたはマテリアライズド・ビュー・サイトの遅延トランザクション・キューから適用済のトランザクションをパージする方法が決定されます。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「構成ウィザード」を使用してマスター・サイトまたはマテリアライズド・ビュー・サイトを設定すると、一定の基準でローカル遅延トランザクション・キューをパージするジョブが各サイトのローカル・ジョブ・キューに作成されます。レプリケーション環境のサイトを構成する前に、パージを発生させる方法を慎重に検討する必要があります。たとえば、次のような方法があります。

- サイトの遅延トランザクション・キューのプッシュとパージを同期化できます。たとえば、トランザクション・キューのプッシュとパージを連続的に行うように構成できます。このように構成した場合、パフォーマンスが向上することがありますが、これは、最後にプッシュされたトランザクションに関する情報が、対応するパージ操作に使用するサーバーのバッファ・キャッシュにすでに存在していることが多いためです。

- サーバーがCPUの限界に達していない場合、遅延トランザクション・キューの連続的なパージをスケジュールすると、可能なかぎりキューのサイズを小さく保つことができます。

- 通常の営業時間帯にトランザクションのスループットが非常に大きくなるサーバーでは、1日の遅延トランザクション全体を格納できる場合は、オフピーク時にパージが行われるようにスケジュールできます。

定期的なパージのスケジューリング

サイトの遅延トランザクション・キューを定期的にパージするようにスケジュールできます。たとえば、1日に1回または1週間に1回というように設定できます。これを行うには、DBMS_DEFER_SYS.SCHEDULE_PURGEプロシージャを使用し、表6-5に示されている設定を指定します。

表6-5 定期的なパージのスケジューリングの設定

SCHEDULE_PURGEプロシージャのパラメータ

値

delay_seconds

0

interval

適切な日付式。たとえば、間隔を1日に指定するには、'sysdate + 1'を使用します。

定期的なパージのスケジューリングには、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用することもできます。これを行うには、「遅延秒数」を0(ゼロ)に設定します。次に、遅延トランザクション・キューを定期的にパージする間隔(「パージ間隔」コントロール)を設定します。

1日に1回の定期的なパージをスケジュールする例を、次に示します。

BEGIN
DBMS_DEFER_SYS.SCHEDULE_PURGE (
next_date => SYSDATE,
interval => 'SYSDATE + 1',
delay_seconds => 0);
END;
/

関連項目:

- DBMS_DEFER_SYS.SCHEDULE_PURGEプロシージャの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- Enterprise Managerでのアドバンスト・レプリケーション・インタフェースの使用方法については、このインタフェースのオンライン・ヘルプを参照してください。

連続的なパージのスケジューリング

サイトの遅延トランザクション・キューの連続的なパージを設定するには、DBMS_DEFER_SYS.SCHEDULE_PURGEプロシージャを使用し、表6-6に示されている設定を指定します。

表6-6 連続的なパージのスケジューリングの設定

SCHEDULE_PURGEプロシージャのパラメータ

値

delay_seconds

500000

interval

delay_seconds設定よりも低い値

purge_method

dbms_defer_sys.purge_method_quick 設定

連続的なパージの設定には、アドバンスト・レプリケーション・インタフェースを使用することもできます。これを行うには、「パージ・スケジュール」ページで、「遅延秒数」を500,000に設定し、間隔(「間隔」フィールド)を、「遅延秒数」設定よりも小さい値に設定します。

連続的なパージをシミュレートする例を次に示します。

BEGIN
DBMS_DEFER_SYS.SCHEDULE_PURGE (
next_date => SYSDATE,
interval => 'SYSDATE + (1/144)',
purge_method => dbms_defer_sys.purge_method_quick,
delay_seconds => 500000);
END;
/

関連項目:

- 遅延秒数の設定の詳細は、「遅延秒数」を参照してください。

- DBMS_DEFER_SYS.SCHEDULE_PURGEプロシージャの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- Enterprise Managerでのアドバンスト・レプリケーション・インタフェースの使用方法については、このインタフェースのオンライン・ヘルプを参照してください。

シリアル伝播およびパラレル伝播

レプリケーション環境のスケジュール・リンクを作成すると、シリアル伝播またはパラレル伝播を使用して各サイトから接続先に変更を非同期伝播できます。レプリケーション環境を構成する前に、シリアル伝播またはパラレル伝播のいずれを使用するかを決定する必要があります。

- シリアル伝播では、レプリケート・トランザクションは、ソース・システムでコミットされたのと同じ順序で一度に1つずつ伝播されます。シリアル伝播を使用するスケジュール・リンクを構成するには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャのparallelismパラメータを0(ゼロ)に設定します。または、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、「送信スケジュールの編集」ページの「伝播プロセス」制御を0(ゼロ)に設定します。

- パラレル伝播では、スループットを向上させるため、レプリケート・トランザクションは複数のパラレル・ストリームを使用して伝播されます。必要に応じて依存トランザクションの実行命令が発行されるので、データ整合性が保持されます。パラレル伝播を使用するスケジュール・リンクを構成するには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャのparallelismパラメータを1以上に設定します。または、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、「送信スケジュールの編集」ページの「伝播プロセス」制御を1以上に設定します。通常は、パラレル伝播を使用します。

関連項目:

- 「パラレル伝播」

- DBMS_DEFER_SYSパッケージの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- Enterprise Managerでのアドバンスト・レプリケーション・インタフェースの使用方法については、このインタフェースのオンライン・ヘルプを参照してください。

デプロイメント・テンプレート

レプリケーション環境にマテリアライズド・ビュー・サイトを含める場合、デプロイメント・テンプレートを使用してマテリアライズド・ビュー・サイトにレプリケート・オブジェクトを作成できます。

関連項目:
デプロイメント・テンプレートの詳細は、第4章「デプロイメント・テンプレートの概要およびアーキテクチャ」を参照してください。

デプロイメント・テンプレートをインスタンス化するマテリアライズド・ビュー・サイトの準備

デプロイメント・テンプレートを使用する場合、デプロイメント・テンプレートのインスタンス化のためにマテリアライズド・ビュー・サイトを準備する必要があります。デプロイメント・テンプレートが適切に設計されている場合は、リモート・マテリアライズド・ビュー・サイトで必要な準備作業はほとんどありません。この項では、リモート・マテリアライズド・ビュー・サイトで実行する最も一般的な準備作業について説明します。必要な準備作業がすべて完了した後で、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションを実行できます。

次の点を考慮して、マテリアライズド・ビュー・スナップショット・サイトでインスタンス化を実行するために必要な準備作業を決定します。

- リモート・マテリアライズド・ビュー・サイトからターゲット・マスター・サイトにネットワーク接続されているかどうか。

- マテリアライズド・ビュー・サイトにOracle9i リリース2(9.2)以上のデータベースがあるかどうか。

- リモート・マテリアライズド・ビュー・サイトがマテリアライズド・ビュー・レプリケーションをサポートするように設定されているかどうか。

- デプロイメント・テンプレートに必要なスキーマがマテリアライズド・ビュー・サイトに存在するかどうか。

- 必要なデータベース・リンクがデプロイメント・テンプレートに含まれていない場合、マテリアライズド・ビュー・サイトからマスター・サイトに必要なデータベース・リンクが存在するかどうか。

- マテリアライズド・ビューでデプロイメント・テンプレートをインスタンス化するために、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションのどちらを使用するか。

- デプロイメント・テンプレートに必要なロールバック・セグメントがマテリアライズド・ビュー・サイトに存在し、かつそのロールバック・セグメントがオンラインであるかどうか。

次の項では、これらの考慮事項に対する指針を示します。

ネットワーク接続性

ネットワーク接続性は、すべてのレプリケーション環境においてアドバンスト・レプリケーションの重要な要素です。ターゲット・マスター・サイトに対する適切なOracle Net接続がリモート・マテリアライズド・ビュー・サイトにあるかどうかを確認します。

関連項目:
Oracleネットワーク接続の設定方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

データベースのバージョン

マテリアライズド・ビュー・サイトをOracle Database 11gと連携させるには、Oracle9i リリース2 (9.2)以上のデータベースを使用している必要があります。マテリアライズド・ビュー・サイトがこれらの要件を満たしていない場合は、デプロイメント・テンプレートをインスタンス化する前にマテリアライズド・ビュー・サイトのデータベースをアップグレードする必要があります。

マテリアライズド・ビュー・サイトの設定

各マテリアライズド・ビュー・サイトには、マテリアライズド・ビュー・サイトをサポートする特殊な権限を持つユーザーが何人か必要です。これらのユーザーは、管理に必要な権限を持ち、さらにデータの伝播とリフレッシュも実行します。

マテリアライズド・ビュー・サイトの設定では、マテリアライズド・ビューの自動リフレッシュ(オプション)や遅延トランザクション・キューのパージを実行するいくつかの自動化ジョブをスケジュールする必要もあります。

マテリアライズド・ビュー・サイトの設定に使用するツールは、次のとおりです。

- アドバンスト・レプリケーション・インタフェース: アドバンスト・レプリケーション・インタフェースを使用してリモート・マテリアライズド・ビュー・サイトに接続し、レプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードを使用できます。

関連項目:
Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。

- レプリケーション・マネージメントAPI: Enterprise Managerのアドバンスト・レプリケーション・インタフェースでリモート・マテリアライズド・ビュー・サイトに接続できない場合は、レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを設定します。マテリアライズド・ビュー・サイトを設定するAPIコールを含むSQLスクリプトを作成するときに、その他の準備作業(必要なスキーマ、データベース・リンク、ロールバック・セグメントの作成など、次の3つの項で説明する作業)を実行するためのDDLとAPIコールも追加できます。作成したスクリプトは、オフライン・インスタンシエーション・ファイルとともに配布し、オフライン・インスタンシエーション・ファイルよりも前に実行する必要があります。

関連項目:
レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

必要なスキーマの作成

インスタンス化するデプロイメント・テンプレートで複数のスキーマにオブジェクトが作成される場合は、必要なスキーマがすべて作成済であることを確認する必要があります。また、デプロイメント・テンプレートをインスタンス化するユーザーは、そのスキーマに対する適切なCREATE権限を持っている必要があります。たとえば、デプロイメント・テンプレートでスキーマoeにプロシージャを作成し、ユーザーhrがこのテンプレートをインスタンス化する場合、hrにはスキーマoeに対するCREATE ANY PROCEDURE権限が必要です。

データベース・リンクの作成

リモート・マテリアライズド・ビュー・サイト用に必要なすべてのデータベース・リンクを作成するDDLをデプロイメント・テンプレートに含めると便利ですが、必ずしもそうする必要はありません。データベース・リンクDDLがデプロイメント・テンプレートに含まれていない場合は、デプロイメント・テンプレートをインスタンス化する前に、ターゲット・マスター・サイトへのデータベース・リンクを手動で作成します。データベース・リンクは、オンライン・インスタンシエーション時にマテリアライズド・ビューにデータを移入したり、マテリアライズド・ビュー環境を適切にメンテナンスするために必要です。

オンライン・インスタンシエーションおよびオフライン・インスタンシエーション

デプロイメント・テンプレートをマテリアライズド・ビュー・サイトでインスタンス化するときは、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションのいずれかを選択できます。オンライン・インスタンシエーションでは、マテリアライズド・ビューのデータはインスタンス化時にマスター・サイトからプルされます。オフライン・インスタンシエーションでは、マテリアライズド・ビューのデータはテンプレート自体にパッケージ化されており、テンプレートをインスタンス化するときにローカルで適用されます。一般的に、マテリアライズド・ビューに大量のデータが含まれている場合は、オフライン・インスタンシエーションの方がネットワーク・リソースの使用率を最小化できます。

関連項目:
オンライン・インスタンシエーションおよびオフライン・インスタンシエーションの詳細は、「デプロイメント・テンプレートのパッケージ化とインスタンス化」を参照してください。

必要なロールバック・セグメントの作成

インスタンス化しているデプロイメント・テンプレートで、現在リモート・マテリアライズド・ビュー・サイトに存在しない特定のロールバック・セグメントを使用する場合は、必要なロールバック・セグメントを作成します。テンプレート・オブジェクトがデフォルトのロールバック・セグメントと特定のロールバック・セグメントのうちのどちらを使用しているのかを確認するには、DBA_REPCAT_TEMPLATE_OBJECTSデータ・ディクショナリ・ビューを問い合せます。

関連項目:
レプリケーションに関係するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

競合解消

非同期のマルチマスター・レプリケーション環境および更新可能マテリアライズド・ビュー・レプリケーション環境では、たとえば異なるサイトから発行された2つのトランザクションがほぼ同時に同じ行を更新する場合などに発生するレプリケーション競合に対処する必要があります。可能なかぎり、競合の発生を回避できるようにレプリケーション環境を計画してください。レプリケーション環境でデータ競合が発生した場合は、ビジネス・ルールに従って競合を解消し、すべてのサイトでデータを適正に収束することを保証するメカニズムが必要です。

関連項目:
競合の回避および競合が発生した場合の競合解消方法の詳細は、第5章「競合解消の概念およびアーキテクチャ」を参照してください。

セキュリティとレプリケーション

セキュリティは、マルチマスター・レプリケーション環境およびマテリアライズド・ビュー・レプリケーション環境のどちらの環境でも重要な課題です。レプリケーション環境を構成する場合、まずセキュリティ対策を講じる必要があります。

関連項目:
レプリケーション環境でのセキュリティ・オプションの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

耐障害性を実現するための設計

耐障害性機能とは、システムまたはサイトの障害時にもアプリケーションを継続して実行できる機能です。また、アプリケーションをフェイルオーバー・システム上で実行でき、障害発生時にプライマリ・システム上でアクセスしていたのと同じか、またはほとんど同じデータにアクセスできます。図6-3に示されているように、Oracleサーバーではマルチマスター・レプリケーションとOracle Real Application Clusters (Oracle RAC)という、耐障害性を実現する2つのテクノロジを提供しています。

図6-3 耐障害性を実現するための方法: レプリケーションまたはOracle Real Application Clusters

Oracle Real Application Clustersとレプリケーションの比較

Oracle Real Application Clusters (Oracle RAC)は、Oracleサーバーのインスタンスをサポートするシステムに障害が発生したときに、システムの耐障害性を確保するフェイルオーバーをサポートしています。Oracle RACには、クラスタまたは大規模パラレル・ハードウェア・プラットフォームが必要なため、クラスタまたは大規模パラレル・システムが稼働しているローカル環境での処理システムを障害から保護する場合に適しています。

このような環境では、Oracle RACは耐障害性を実現するための理想的なソリューションで、大量のトランザクションをサポートしており、インスタンス障害が発生した場合でもトランザクションの消失やデータの不整合が発生することがありません。Oracle RAC環境では、1つのインスタンスで障害が発生しても、他の正常なインスタンスによって未完了のトランザクションが自動的にリカバリされます。障害が発生したシステムで実行されていたアプリケーションはフェイルオーバー・システムで実行でき、データベースのすべてのデータにアクセスできます。

ただし、Oracle RACには、サイト全体におよぶ障害(停電、洪水、火事、破壊行為など)によってクラスタまたは大規模パラレル・システム全体が操作不能になるような状況に対しては耐障害性がありません。サイト障害に対して耐障害性を確保するために、マルチマスター・レプリケーションを使用して、地理的に離れた場所でデータベースのレプリカをメンテナンスできます。さらに、マルチマスター・レプリケーションを使用すると、異なるオペレーティング・システムまたはOracleの異なるリリース(あるいはその両方)が稼働するサイト間でデータをレプリケートできます。

ローカル・システムに障害が発生しても、アプリケーションはリモート・サイトで実行を継続できます。マルチマスター・レプリケーションを使用する場合は、障害サイトでのトランザクションのリカバリと、障害サイトを再開したときのデータの非一貫性を防ぐために、なんらかの管理手順が必要になることがあります。

注意:
スタンバイ・データベースを構成して、Oracle Databaseをサイト障害から守ることもできます。

関連項目:

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

耐障害性を実現するレプリケーション環境の設計

耐障害性を実現するためにレプリケーション機能を使用する場合は、次の事項を考慮してください。

- レプリケーション機能によって、プライマリ・システムと同じ量のトランザクションを処理できる必要があります。

- プライマリ・サイトで障害が発生した場合、プライマリ・サイトで少し前にコミットされたトランザクションは、フェイルオーバー・サイトにまだ非同期に伝播されていない可能性があります。このトランザクションは消失したように見えます。
この消失したトランザクションは、プライマリ・サイトがリカバリされたときに処理する必要があります。

たとえば、リモートのフェイルオーバー・サイトのメンテナンスにレプリケーションを使用する受注入力システムにおいて、システムの実行時にプライマリ・システムで障害が発生したとします。

障害発生時、少し前にプライマリ・サイトで実行された2つのトランザクションの変更は、フェイルオーバー・サイトに伝播および適用させていません。最初のトランザクションは新規の受注の入力で、2番目のトランザクションは既存の受注の取消しです。

新規受注入力の場合、フェイルオーバー・システムでの処理の継続中にその受注が存在しないことが発見されると、再入力されると考えられます。既存の受注の取消しの場合は、受注の取消しは発見されずに、受注処理が継続されると考えられます(つまり、取り消された商品が出荷されて、顧客に請求が送られます)。

プライマリ・サイトがリストアされた場合を考えます。フェイルオーバー・システムで実行されたすべての変更をプライマリ・システムに単に戻すと、競合が発生します。

具体的には、プライマリ・システムに障害が発生する直前に受注された商品に対する注文が重複します。さらに、プライマリ・システムでは取り消されているはずの受注の出荷および請求トランザクションにより、データが変更されます。

こうした状況に対処するには、システムを綿密に設計する必要があります。次の項では、このプロセスについて説明します。

耐障害性の高いシステムの実装

アドバンスト・レプリケーションでは、レプリケートされた複数のマスター・サイトを使用してサイト障害に対する耐障害性を提供しています。実装の最も容易な方法から順番にリストした次の方法のいずれかを使用してシステムを構成する必要があります。

- フェイルオーバー・サイトは読取りアクセス専用で使用します。つまり、プライマリ・サイトで障害が発生した場合でも、フェイルオーバー・サイトでは更新できません。

- 障害の後、プライマリ・サイトは、エクスポートおよびインポート、または全体バックアップによって、フェイルオーバー・サイトからリストアされます。

- すべてのデータおよびトランザクションでは、競合を完全に解消します。このためには、綿密な設計および実現が必要です。重複トランザクションなど、プライマリ・サイトがリストアしたときに発生する競合を、適切かつ確実に解消する必要があります。

- アプリケーション・レベルのルーチンやプロシージャを独自に作成して、プライマリ・サイトがリストアされたとき、およびアクティブなフェイルオーバー・システムでキューに入れられていたトランザクションがプライマリ・サイトに伝播および適用されたときに発生するデータの不整合を処理します。

Oracle Netを使用すると、接続時に自動的に起動されるフェイルオーバーを構成でき、この機能により、最初のマスター・サイトに障害が発生した場合、Oracle Netは別のマスター・サイトに接続を切り替えることができます。自動的な接続時フェイルオーバーを構成するには、tnsnames.oraファイルでFAILOVERオプションをonに設定し、複数の接続記述子を指定します。

関連項目:
接続時フェイルオーバーの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

レプリケーション環境におけるデータベースのリカバリ

レプリケーション環境のマスター・サイトであるデータベースをリカバリすると、レプリケート・データの一貫性が失われてレプリケーション・エラーが発生することがあります。たとえば、リストアされたマスター・サイトが別のマスター・サイトに異なるトランザクションを伝播していることがあります。場合によっては、不正確なリカバリ操作を修正するために、追加の手順を実行する必要があります。その方法の1つは、リカバリしたデータベース内のすべてのレプリケート・オブジェクトを削除し、再作成する方法です。

レプリケート・オブジェクトの削除および再作成を実行する前に、リストアしたデータベースから保留中の遅延トランザクションおよび遅延エラー・レコードを削除し、未解決の分散トランザクションを解決してください。リストアされたデータベースがいくつかのレプリケーション環境のマスター定義サイトであった場合、オブジェクトを削除および作成する前に新しいマスター定義サイトを設定する必要があります。リストアされたデータベースがマスターであるマテリアライズド・ビュー、およびリストアされたデータベース内のマテリアライズド・ビューは、完全リフレッシュを行う必要があります。

データに対する継続的なアクセスを可能にするため、マスター定義サイトの変更(リストアされるデータベースがマスター定義サイトであった場合)、またはマテリアライズド・ビュー・サイトのマスター・サイトの変更(それらのマスター・サイトがリストアされている場合)が必要な場合があります。

インポートされたデータに対するチェックの実行

レプリケート・オブジェクトやアドバンスト・レプリケーションで使用するオブジェクト(DBA_REPSITESデータ・ディクショナリ・ビューなど)のエクスポートおよびインポートを実行した後は、DBMS_REPCATパッケージのREPCAT_IMPORT_CHECKプロシージャを実行する必要があります。

次の例では、このプロシージャを使用して、マテリアライズド・ビュー・サイトのhr_repgレプリケーション・グループのオブジェクトをチェックして、オブジェクト識別子とステータス値が適切であることを確認します。

BEGIN
DBMS_REPCAT.REPCAT_IMPORT_CHECK( gname     =>   'hr_repg',
master    =>   FALSE);
END;
/

関連項目:
『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のREPCAT_IMPORT_CHECKプロシージャを参照してください。

A レプリケーションに関する問題のトラブルシューティング

この付録では、レプリケーション環境を管理するためのトラブルシューティングのガイドラインについて説明します。

この付録には、次の項が含まれます。

- データベース・リンクに関する問題の診断方法

- マスター・サイトに関する問題の診断方法

- 遅延トランザクション・キューに関する問題の診断方法

- マテリアライズド・ビューに関連する問題の診断方法

データベース・リンクに関する問題の診断方法

データベース・リンクが正常に機能していないと考えられる場合、Oracle Enterprise Manager、SQL*Plusまたは別のツールを使用してデータベース・リンクを削除し、再作成します。

- データベース・リンク名が、ターゲット・データベースのグローバル名と同じであることを確認します。

- スケジュールした間隔が意図したとおりであることを確認します。

- スケジュールした間隔が、必要な実行時間よりも短くないことを確認します。

指定サイトへのデータベース・リンクで接続修飾子を使用した場合は、そのサイトにリンクする他のサイトでも同じ接続修飾子を使用する必要があります。たとえば、次のようにデータベース・リンクを作成するとします。

CREATE DATABASE LINK dbs1.example.com@myethernet CONNECT TO repadmin
IDENTIFIED BY password USING 'connect_string_myethernet';

マスター・サイトかマテリアライズド・ビュー・サイトかにかかわらず、dbs1.example.com@myethernetに対応付けられたすべてのサイトで、接続修飾子myethernetを使用する必要があります。

関連項目:
データベース・リンクと接続修飾子の詳細は、『Oracle Database管理者ガイド』を参照してください。

マスター・サイトに関する問題の診断方法

マルチマスター・レプリケーション・システムで問題が発生する可能性があります。次の各項で、これらの問題とその解決方法について説明します。

- 新しいマスター・サイトでレプリケート・オブジェクトが作成されない場合

- DDLによる変更がマスター・サイトに伝播されない場合

- DMLによる変更が他のサイトに非同期で伝播されない場合

- DMLをレプリケート表に適用できない場合

- バルク更新および制約違反

- レプリケート・オブジェクトの再作成

- 表のレプリケーション・サポートを生成できない場合

- レプリケート・プロシージャまたはレプリケート・トリガーに関する問題

新しいマスター・サイトでレプリケート・オブジェクトが作成されない場合

マスター・グループに新しいマスター・サイトを追加しても、新しいマスター・サイトで適切なオブジェクトが作成されない場合は、次の処理を実行します。

- 必要なプライベート・データベース・リンクが新しいマスター・サイトと既存のマスター・サイトの間に存在することを確認します。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「構成ウィザード」を使用してサイトを設定した場合は、何も問題はありません。リンクは、既存の各サイトから新しいサイトへ、および新しいサイトから既存の各サイトへ相互に存在している必要があります。

- すべてのサイトで管理要求が正常に終了していることを確認します。管理要求がまだ実行されていない場合、保留になっている管理要求を手動で実行し、即時に操作を完了させることができます。

DDLによる変更がマスター・サイトに伝播されない場合

マスター・グループ・オブジェクトを作成しても、またはマスター定義サイトでマスター・グループ・オブジェクトの定義を変更しても、変更がマスター・サイトに伝播されない場合は、すべてのサイトで管理要求が正常に完了していることを確認します。管理要求が保留になっている場合は、手動で実行して即時に操作を完了させることができます。

レプリケーションAPIを通してDDL文を実行すると、DDLを送信するユーザー名においてDDL文が実行されます。発行者のスキーマ以外のスキーマ内のオブジェクトにDDL文を適用するときは、発行者に文を実行する適切な権限が必要です。また、文の中でスキーマを明示的に指定する必要があります。たとえば、DBMS_REPCAT.CREATE_MASTER_ REPOBJECTプロシージャのddl_textパラメータに次のように指定するとします。

CREATE TABLE oe.new_employees AS SELECT * FROM hr.employees WHERE ...;

それぞれの表名にはスキーマ名が含まれるので、レプリケーション管理者がoeやhrまたは別のユーザーであっても、必要な権限があれば、この文は正しく機能します。

注意:
各スキーマ・オブジェクトの名前を適切なスキーマで修飾してください。

DMLによる変更が他のサイトに非同期で伝播されない場合

マスター・サイトのデータを更新し、その変更がレプリケーション環境の他のサイトに非同期で伝播されない場合は、次の処理を実行します。

- Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、対応する遅延トランザクションが接続先にプッシュされているかどうかをチェックします。プッシュされていない場合、スケジュール・リンクがキューを接続先サイトにプッシュするまでの待ち時間をチェックできます。リンクによるスケジュール・プッシュを待機できない場合、遅延トランザクションを手動で実行できます。

- スケジュール・リンクのプッシュ間隔が経過しても対応する遅延トランザクションがプッシュされない場合は、リンクの対応するジョブをチェックします。

- 遅延トランザクションが接続先に伝播されても、エラーのために実行できない場合もあります。接続先サイトのDEFERRORのデータ・ディクショナリ・ビューでエラーの有無を調べます。

関連項目:
変更をレプリケートせずに表を変更する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。レプリケート表のデータを手動で同期する際にこの方法が必要になる場合があります。

DMLをレプリケート表に適用できない場合

レプリケート表を変更しようとしたときにdeferred_rpc_quiesce例外を受け取った場合は、レプリケート・オブジェクトが属するマスター・グループが静止または静止中になっています。先に進むには、レプリケーション管理者がマスター・グループのレプリケーション・アクティビティを再開する必要があります。

バルク更新および制約違反

1つのUPDATE文をレプリケート表に適用すると、ゼロ以上の行を更新できます。UPDATE文を実行すると、ゼロ以上の更新要求が、更新される行ごとに1つずつ遅延実行用のキューに入れられます。Oracleでは文末で制約のチェックをまとめて行うので、制約が存在する場合はこの機能が重要になります。たとえば、バルク更新では一意制約違反が発生しなくても、同じ順序で1行ずつ更新すると一意制約違反が発生する場合があります。

更新順序が重要である場合は、適切な順序で1行ずつ更新します。これによって、遅延トランザクション・キューにおける更新要求の順序を定義できます。

レプリケート・オブジェクトの再作成

パッケージ、プロシージャ、ビューなどのオブジェクトをマスター・グループに追加する場合は、オブジェクトの状態が有効である必要があります。オブジェクトの状態が無効の場合は、マスター・グループにオブジェクトを追加する前に、オブジェクトを再コンパイルするか、オブジェクトを削除して再作成してください。DBA_REPOBJECTのデータ・ディクショナリ・ビューでレプリケーション・オブジェクトの状態を調べます。

表のレプリケーション・サポートを生成できない場合

表のレプリケーション・サポートを生成すると、ローカル・サイトで内部トリガーがアクティブ化されます。レプリケーションに関連するほとんどのパッケージ(DBMS_REPCATやDBMS_DEFERなど)について、EXECUTE権限を、レプリケーション管理者およびレプリケート・オブジェクトを所有するユーザーに付与する必要があります。多くの一般的なレプリケーション・シナリオでレプリケーション管理者が必要とする権限は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「構成ウィザード」およびDBMS_REPCAT_ADMINパッケージを使用して付与します。ただし、レプリケート・オブジェクトの所有者がレプリケーション管理者でない場合は、DBMS_DEFERに対するEXECUTE権限をオブジェクトの所有者に対して明示的に付与する必要があります。

レプリケート・プロシージャまたはレプリケート・トリガーに関する問題

予期しない未解消の競合を発見した場合で、プロシージャ・レプリケーションと行レベルのレプリケーションが表に混在しているときは、プロシージャを注意深く検証し、レプリケート・プロシージャが競合の原因かどうかを確認します。次のチェックを実行します。

- プロシージャでの更新と行レベルの更新の順序競合でないことを確認してください。

- レプリケート・プロシージャが更新の実行前に表をEXCLUSIVEモードにロックしているかどうか、行レベルの更新の競合を回避するために他のメカニズムを使用しているかどうかをチェックします。

- レプリケート・プロシージャの最初で行レベルのレプリケーションを使用禁止にし、最後に再び使用可能にしていることをチェックします。

- プロシージャの実行時に例外が発生した場合も、行レベルのレプリケーションを再び使用可能にしていることを確認します。

- レプリケート・プロシージャがすべてのマスター・サイトで実行されたことをチェックします。

レプリケート表で定義したレプリケート・トリガーのすべてについて、同様のチェックを行う必要があります。

遅延トランザクション・キューに関する問題の診断方法

サイトの遅延トランザクションが接続先にプッシュされない場合、その原因は次の各項で説明している問題である可能性があります。

- スケジュール・リンクのジョブのチェック

- 同期レプリケーション使用時の分散トランザクションの問題

- データベース・リンク指定の不備

- 不適切なレプリケーション・カタログ・ビュー

スケジュール・リンクのジョブのチェック

スケジュール・リンクを作成すると、対応するジョブがサイトのジョブ・キューに追加されます。スケジュール・リンクが定期的な間隔で遅延トランザクションをプッシュするように設定しているときに問題が検出された場合は、まずジョブ・キューに関する問題かどうかを確認する必要があります。

同期レプリケーション使用時の分散トランザクションの問題

同期レプリケーションを使用する場合、Oracleでは分散トランザクションを使用して、そのトランザクションがリモート・サイトで正しくコミットされるようにします。分散トランザクションでは2フェーズ・コミットが使用されます。非同期レプリケーションでは2フェーズ・コミットは使用されません。

関連項目:
分散トランザクション使用時の問題の診断方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

データベース・リンク指定の不備

指定したリモート・サイトにトランザクションがプッシュされていない場合、トランザクションの接続先の指定方法に問題がある場合があります。スケジュール・リンクを作成するときは、完全なデータベース・リンク名を指定する必要があります。

不適切なレプリケーション・カタログ・ビュー

ビューの定義が不適切であると、遅延トランザクションが正しく動作しない場合があります。DEFCALLDESTビューとDEFTRANDESTビューの定義は、catdefer.sqlとcatrepc.sqlとで異なります。レプリケーションを使用するときは常に、catrepc.sqlの定義を使用する必要があります。catdefer.sqlを(再)ロードする場合は、その後でcatrepc.sqlのビュー定義がロードされるようにしてください。

マテリアライズド・ビューに関連する問題の診断方法

レプリケーション・システムのマテリアライズド・ビュー・サイトでは様々な問題が発生します。次の項では、これらの問題とその解決方法をいくつか説明します。

- マテリアライズド・ビュー・サイトでのレプリケート・オブジェクトの作成に関する問題

- リフレッシュに関する問題

- リフレッシュに関する問題の高度なトラブルシューティング

マテリアライズド・ビュー・サイトでのレプリケート・オブジェクトの作成に関する問題

マテリアライズド・ビュー・サイトでオブジェクトの作成に失敗した場合は、次の処理を実行します。

- 更新可能マテリアライズド・ビューの場合は、対応するマスター表またはマスター・マテリアライズド・ビューにマテリアライズド・ビュー・ログがあることを確認します。

- オブジェクトを作成する権限があるかどうかを確認します。マテリアライズド・ビューの場合は、マスター表またはマスター・マテリアライズド・ビューとそのマテリアライズド・ビュー・ログに対するSELECT権限が必要です。詳細は、「権限の割当て」を参照してください。

- 既存のマテリアライズド・ビューをマテリアライズド・ビュー・グループに追加する場合は、マテリアライズド・ビューを再作成してグループに追加します。

- 高速リフレッシュを実行する主キーまたは副問合せマテリアライズド・ビューを作成する場合は、マスター表やマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログに主キーがロギングされていることを確認します。

- 高速リフレッシュを実行するROWIDマテリアライズド・ビューを作成する場合は、マスター表のマテリアライズド・ビュー・ログにROWIDがロギングされていることを確認します。

- 副問合せマテリアライズド・ビューの場合は、必要な列がマテリアライズド・ビュー・ログに追加されていることを確認します。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。

- 高速リフレッシュを実行するマテリアライズド・ビューと関連するすべての表に対して、マテリアライズド・ビュー・ログが存在することを確認します。マテリアライズド・ビューに副問合せが含まれている場合は、副問合せで参照される表のそれぞれに対してマテリアライズド・ビュー・ログが必要です。

デプロイメント・テンプレートのオフライン・インスタンシエーションの実行に関する問題

デプロイメント・テンプレートをオフラインでインスタンス化しようとしたときに、一時表領域でエクステントを初期化できないというエラーを受け取った場合に、一時データベースが自動的に拡張されるように、一時データベースのデータファイルを調整する必要があります。

たとえば、次の文を発行してデータファイルを調整します。

ALTER DATABASE TEMPFILE '/u02/oracle/rbdb1/temp.dbf'
AUTOEXTEND ON
NEXT 10M;

この調整を行った後、マテリアライズド・ビュー・サイトでデプロイメント・テンプレートをオフラインでインスタンス化します。

リフレッシュに関する問題

次の項では、マテリアライズド・ビューのリフレッシュに関するいくつかの一般的な問題について説明します。

リフレッシュに関する一般的な問題

次のようないくつかの一般的な要因で、マテリアライズド・ビューのグループの自動リフレッシュが実行されない場合があります。

- マテリアライズド・ビュー・データベースでのジョブ・スレーブの欠落

- ネットワークまたはサーバー障害の影響

- サーバー・シャットダウンの影響

マテリアライズド・ビューのリフレッシュ・グループで問題が発生したときは、前述の状況が原因かどうかを確認します。

自動リフレッシュの再試行

グループの自動リフレッシュが失敗すると、グループはリフレッシュ実行予定のままになります。次の条件に基づいて、グループの自動リフレッシュが再試行されます。

- グループのリフレッシュを初回は1分後、次は2分後、その次は4分後というように、失敗するたびに再試行間隔を倍にします。

- 再試行間隔はリフレッシュ間隔自体より長い時間にはなりません。

- 最高16回まで自動リフレッシュを再試行します。

リフレッシュ・グループのリフレッシュを16回再試行してもエラーが発生する場合は、グループは破損しているとみなされます。Schema Managerの「リフレッシュ・グループ」プロパティ・シートの「一般」ページを参照すると、いつリフレッシュ・グループが破損したかがわかります。USER_REFRESHおよびUSER_REFRESH_CHILDRENデータ・ディクショナリ・ビューのBROKEN列を問い合せて、リフレッシュ・グループの現在の状態を知ることもできます。

マテリアライズド・ビューのリフレッシュ・グループの破損によるエラーは、トレース・ファイルに記録されます。リフレッシュ・グループが正常にリフレッシュされない原因となった問題を修正し、グループを手動でリフレッシュする必要があります。この結果、破損フラグがリセットされ、自動リフレッシュが実行できるようになります。

関連項目:
マテリアライズド・ビュー・トレース・ファイルの名前の形式はjnで、nはオペレーティング・システム固有です。各システムにおける名前は、オペレーティング・システム固有のOracleドキュメントを参照してください。

新規マテリアライズド・ビュー・サイトでの高速リフレッシュ・エラー

新規マテリアライズド・ビュー・サイトでマテリアライズド・ビュー作成中に、マスター表またはマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログがパージされる場合があります。これが発生すると、次のエラーが検出される場合があります。

ORA-12004 REFRESH FAST cannot be used for materialized view materialized_view_name
ORA-12034 materialized view log on materialized_view_name younger than last refresh

関連項目:
この問題を回避する方法については、「新規マテリアライズド・ビュー・サイトを追加するときの問題の回避」を参照してください。

マテリアライズド・ビューが繰り返しリフレッシュされる場合

マテリアライズド・ビュー・グループのリフレッシュが継続的に繰り返される場合、グループのリフレッシュ間隔をチェックします。グループの自動リフレッシュ間隔は、リフレッシュを開始する前に評価されます。グループのリフレッシュ間隔がグループのすべてのマテリアライズド・ビューのリフレッシュに要する時間よりも短い場合、ジョブ・スレーブで未処理ジョブのキューがチェックされるたびに、グループ・リフレッシュが繰り返し開始されます。

マテリアライズド・ビュー・ログが大きくなりすぎる場合

マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでマテリアライズド・ビュー・ログが大きくなりすぎる場合は、ネットワークまたはサイトの障害のためにマテリアライズド・ビューが削除されたことが、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで認識されているかどうかをチェックします。マテリアライズド・ビュー・ログの部分的なパージ、あるいは未使用のマテリアライズド・ビュー・サイトの登録の解除が必要になる場合があります。

関連項目:
マテリアライズド・ビュー・ログの管理方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

リフレッシュに関する問題の高度なトラブルシューティング

マテリアライズド・ビューのリフレッシュに関する問題が発生している場合、次の処理を実行します。

- DBA_REFRESH_CHILDRENビューに表示されているNEXT_DATE値をチェックして、リフレッシュがスケジュールされているかどうかを判断します。

- リフレッシュ間隔が経過している場合は、DBA_REFRESHビューで、マテリアライズド・ビューのリフレッシュが対応付けられたジョブ番号をチェックして、ジョブ・キューに関する問題の診断を行います。

- 実行中のジョブ・スレーブがあるかどうかをチェックします。JOB_QUEUE_PROCESSES初期化パラメータをチェックし、DBA_JOBS_RUNNINGビューを問い合せ、オペレーティング・システムを使用してジョブ・スレーブが稼働中かどうかをチェックします。

- 2つのマテリアライズド・ビュー間のマスター・ディテール関係を定義すると、エラーが発生することもあります。マスター・ディテール関係は、宣言参照整合性の制約を使用して、マスター表に対してのみ定義します。その後、関連するマテリアライズド・ビューを同じリフレッシュ・グループ内に入れて、この関係を保ちます。ただし、遅延(遅延可能)制約はマテリアライズド・ビューに対して定義します。

- マテリアライズド・ビューのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに未解決の競合が記録されている場合、REFRESH_AFTER_ERRORSをTRUEに設定しないとマテリアライズド・ビューをリフレッシュできません。このパラメータは、マテリアライズド・ビューのリフレッシュ・グループの作成または変更時に設定できます。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースに、これと対応するパラメータがあります。

- 同じリフレッシュ・グループ内のマテリアライズド・ビューでは、行は1つのトランザクションで更新されます。このようなトランザクションは非常に大きくなる可能性があるので、大きなロールバック・セグメント(リフレッシュ中に使用するように指定したロールバック・セグメントを含む)がマテリアライズド・ビュー・サイトで必要になるか、または、リフレッシュをより頻繁に実行してトランザクションのサイズを小さくする必要があります。

- OracleエラーORA-12004が発生した場合は、マテリアライズド・ビュー・ログを管理するためにマスター・サイトでロールバック・セグメントが不足したか、マテリアライズド・ビュー・ログの情報が古い可能性があります。たとえば、マテリアライズド・ビュー・ログがパージまたは再作成された可能性があります。

- 1つのマテリアライズド・ビューの完全リフレッシュでは、内部的にTRUNCATE機能が使用されるので、処理速度が向上し、ロールバック・セグメントの必要量が少なくなります。ただし、マテリアライズド・ビューが完全リフレッシュされるまで、マテリアライズド・ビューには一時的にデータが表示されないことがあります。複数のマテリアライズド・ビュー(リフレッシュ・グループなど)をリフレッシュするときは、TRUNCATE機能は使用されません。

- マスター表を再編成するとき(たとえば、システム・リソースの再利用などの目的で)は、マスター表にTRUNCATE機能を実行して、ROWIDマテリアライズド・ビューの完全リフレッシュを実行する必要があります。そうしないと、マテリアライズド・ビューがマスター表への誤ったROWIDを持つことになります。マスター表の再編成には、DBMS_MVIEWパッケージのBEGIN_TABLE_REORGANIZATIONおよびEND_TABLE_REORGANIZATIONプロシージャを使用します。詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

- リフレッシュの実行中にエラーORA-00942(表またはビューが存在しません)が発生した場合は、データベース・リンクをチェックし、マスター表またはマスター・マテリアライズド・ビューとマテリアライズド・ビュー・ログに対して必要な権限を持っていることを確認します。

- 高速リフレッシュが成功した後で障害が発生した場合、次の点をチェックします。

- マテリアライズド・ビュー・ログの切捨て、パージまたは削除が実行されたかどうか

- マテリアライズド・ビュー・ログに対する必要な権限を持っているかどうか

- 強制リフレッシュに非常に長い時間を要する場合は、リフレッシュ時に使用するマテリアライズド・ビュー・ログが削除されていないかチェックします。

- BUILD DEFERREDを使用して作成したマテリアライズド・ビューの最初の高速リフレッシュが失敗した場合は、その他の問題をチェックする前に、前の完全リフレッシュが成功していたことを確認します。

関連項目:
マテリアライズド・ビュー・ログの管理方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。

B 列長セマンティクスとUnicode

この付録には、列長セマンティクスおよびUnicodeに対するレプリケーション・サポートに関する情報が含まれています。

この付録には、次の項が含まれます。

- レプリケーション・サイトおよび表の列に関する列長セマンティクス

- マルチマスター環境での列長セマンティクス・サポート

- マテリアライズド・ビューでの列長セマンティクス・サポート

- DDL伝播と列長セマンティクス

- Unicodeに対するレプリケーション・サポート

関連項目:
長さセマンティクスおよびUnicodeの詳細は、次のマニュアルを参照してください。

- 『Oracle Databaseグローバリゼーション・サポート・ガイド』

- 『Oracle Database SQL言語リファレンス』

レプリケーション・サイトおよび表の列に関する列長セマンティクス

列長セマンティクスにより、列の長さをバイト単位に指定するか文字単位に指定するかが決まります。列の長さをバイト単位に指定する場合はBYTEを、文字単位に指定する場合はCHARを使用します。CHAR列セマンティクスは、コードポイント長セマンティクスとも呼ばれます。

キャラクタ・セットによっては1文字に複数バイトを必要とするものがあるため、列に10 BYTEと指定すると、実際に格納される文字数が10文字より少ないことがありますが、10 CHARと指定すると、どのキャラクタ・セットでも列に10文字が格納されます。CHAR列セマンティクスを指定できるのは、Oracle9i Database以上のデータベースです。

Oracle Databaseの長さセマンティクスはNLS_LENGTH_SEMANTICS初期化パラメータを使用して設定し、すべてのVARCHAR2列およびCHAR列で、この初期化パラメータにデフォルトとして指定された値が使用されます。この初期化パラメータを設定しない場合、デフォルト設定はBYTEです。

それぞれの列で、データベースの列長セマンティクスを上書きできます。たとえば、サイトの列長セマンティクスがCHARの場合でも、CREATE TABLE文またはALTER TABLE文を使用して、個々の列の長さのセマンティクスにBYTEを指定できます。

次の文では表を作成し、列長をバイト単位に指定します。

CREATE TABLE byte_col (a VARCHAR2(10 BYTE));

次の文では表を作成し、列長を文字単位に指定します。

CREATE TABLE char_col (a VARCHAR2(10 CHAR));

マルチマスター環境での列長セマンティクス・サポート

マスター・グループ内のすべてのマスター・サイトの列長セマンティクスは同じにする必要があり、マスター表内の個々の列長セマンティクスはすべてのマスター・サイトで同じにする必要があります。マスター定義サイトのマスター・グループに表があり、その表を新規マスター・サイトにレプリケートする場合は、次のいずれかの方法で新規サイトに表を作成できます。

- 新規マスター・サイトをマスター・グループに追加するときに、アドバンスト・レプリケーションによって新規マスター・サイトにその表を生成することを指定します。

- 新規マスター・サイトをマスター・グループに追加する前に、そのマスター・サイトで表を事前に手動で作成します。

以降の項では、この2つの表の作成方法のそれぞれに対する列長セマンティクス・サポートを説明します。

アドバンスト・レプリケーションによって生成された表に対する列長セマンティクス・サポート

アドバンスト・レプリケーションで新規マスター・サイトに表を生成するように指定し、CHAR列セマンティクスを使用している場合は、マスター定義サイトと新規マスター・サイトの両方でOracle9i Database以上が稼働している必要があります。BYTE列セマンティクスを指定する場合は、これらのサイトで以前のリリースのOracleが稼働していてもかまいません。

このサポートについて、表B-1に要約します。

表B-1 生成された表に対する列長セマンティクス・サポート

マスター定義サイトのリリース

マスター定義サイトの列セマンティクス

新規マスター・サイトのリリース

新規マスター・サイトの列セマンティクス

9.2以上

CHAR

9.2以上

CHAR

9.2以上

CHAR

9.2未満

サポートされていません

任意のリリース

BYTE

任意のリリース

BYTE

事前作成された表に対する列長セマンティクス・サポート

新規マスター・サイトに表を事前作成するときに、CHAR列セマンティクスを使用する場合は、マスター定義サイトと新規マスター・サイトの両方でOracle9i Database以上が稼働している必要があります。BYTE列セマンティクスを指定する場合は、これらのサイトで以前のリリースのOracleが稼働していてもかまいません。

また、表を手動で事前に作成しているため、新規マスター表内の列には、マスター定義サイトでの表の列とは異なる列長セマンティクスを指定している可能性があります。マスター表内の列は各マスター・サイトで同じ列セマンティクスを使用する必要があるため、その場合はエラーが発生します。

このサポートについて、表B-2に要約します。

表B-2 事前作成された表に対する列長セマンティクス・サポート

マスター定義サイトのリリース

マスター定義サイトの列セマンティクス

新規マスター・サイトのリリース

新規マスター・サイトの列セマンティクス

サポート

9.2以上

CHAR

9.2以上

CHAR

あり

9.2以上

CHAR

9.2以上

BYTE

なし

9.2以上

BYTE

9.2以上

CHAR

なし

9.2以上

(マルチバイト・キャラクタ・セット)

CHAR

9.2未満

BYTE

なし

9.2以上

(シングルバイト・キャラクタ・セット)

CHAR

9.2未満

BYTE

あり

9.2未満

BYTE

9.2以上

(マルチバイト・キャラクタ・セット)

CHAR

なし

9.2未満

BYTE

9.2以上

(シングルバイト・キャラクタ・セット)

CHAR

あり

任意のリリース

BYTE

任意のリリース

BYTE

あり

マテリアライズド・ビューでの列長セマンティクス・サポート

マテリアライズド・ビューを作成するとき、マテリアライズド・ビュー内の列長セマンティクスは次のように決定されます。

- マスター列がBYTEまたはCHARとして明示的に指定されている場合は、マテリアライズド・ビュー内の列はその明示的な指定を保持します。次の例では、a列に対してCHAR列セマンティクスが明示的に指定されています。

CREATE TABLE char_col (a VARCHAR2(10 CHAR));

- マスター表内の列が明示的に指定されない場合は、マテリアライズド・ビュー内の列はマテリアライズド・ビュー・サイトのデフォルトの列長セマンティクスを使用します。次の例では、a列の列長セマンティクスが明示的に指定されていません。

CREATE TABLE char_col (a VARCHAR2(10));

Oracle9i Database以上のマスターに明示的なCHAR指定の列があり、Oracle9i Databaseより前のリリースを稼働しているマテリアライズド・ビュー・サイトがこのマスターに基づいてマテリアライズド・ビューを作成しようとすると、マテリアライズド・ビューの作成は失敗します。

ビルトインのコンテナ表を含むマテリアライズド・ビュー

マテリアライズド・ビュー・サイトでマテリアライズド・ビューを作成する前にコンテナ表を事前に作成した場合、コンテナ表の列長セマンティクスはマスターの列長セマンティクスと一致する必要があります。列長セマンティクスが一致しない場合は、マテリアライズド・ビューの作成中にORA-12060エラーが返されます。マテリアライズド・ビューの表を事前に作成するには、CREATE MATERIALIZED VIEW文のON PREBUILT TABLE句を使用します。

関連項目:
CREATE MATERIALIZED VIEW文のON PREBUILT TABLE句の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

更新可能マテリアライズド・ビューに対する列長セマンティクス・サポート

更新可能マテリアライズド・ビューの列長セマンティクスがマテリアライズド・ビューのマスターの列長セマンティクスに一致する場合は、次の操作が常にサポートされます。

- 更新可能マテリアライズド・ビューのリフレッシュ

- マテリアライズド・ビューに加えられたDML変更のマスターへのプッシュ

ただし、列長セマンティクスが一致せず、マスターがOracle9i Database以上の場合は、マテリアライズド・ビューをマテリアライズド・ビュー・グループに追加しようとしたときにエラーが発生します。マテリアライズド・ビューが更新可能マテリアライズド・ビューになるには、マテリアライズド・ビュー・グループに属している必要があります。レプリケーション・マネージメントAPIを使用する場合は、DBMS_REPCATパッケージ内のCREATE_MVIEW_REPOBJECTプロシージャを実行して、マテリアライズド・ビューをマテリアライズド・ビュー・グループに追加します。

表B-3に、更新可能マテリアライズド・ビューに対する列長セマンティクスのサポートについて要約します。

表B-3 更新可能マテリアライズド・ビューに対する列長セマンティクス・サポート

マスター・サイトのリリース

マスター・サイトの列セマンティクス

マテリアライズド・ビュー・サイトのリリース

マテリアライズド・ビュー・サイトの列セマンティクス

更新可能マテリアライズド・ビューのサポート

9.2以上

CHAR

9.2以上

CHAR

あり

9.2以上

CHAR

9.2以上

BYTE

なし

9.2以上

BYTE

9.2以上

CHAR

なし

9.2以上

(マルチバイト・キャラクタ・セット)

CHAR

9.2未満

BYTE

なし

9.2以上

(シングルバイト・キャラクタ・セット)

CHAR

9.2未満

BYTE

あり

9.2未満

BYTE

9.2以上

CHAR

あり

任意のリリース

BYTE

任意のリリース

BYTE

あり

注意:
表B-3に示されているマスター・サイトは、マルチマスター・レプリケーション環境のマスター・サイトか、マスター・マテリアライズド・ビュー・サイトのいずれかです。

DDL伝播と列長セマンティクス

DBMS_REPCATパッケージを使用すると、新規レプリケート表を作成するデータ定義言語(DDL)文、あるいは既存のレプリケート表に列を追加するDDL文を伝播できます。このようなDDL文により作成された新規列でCHAR列セマンティクスを使用する場合は、CHAR列セマンティクスを明示的に指定するようにします。指定しない場合、レプリケーション・サイト自体でデフォルトとしてCHAR列セマンティクスを設定していても、列は常にBYTE列セマンティクスになります。

DDL文を伝播するには、DBMS_REPCATパッケージ内の次のプロシージャを使用します。

- ALTER_MASTER_REPOBJECT

- CREATE_MASTER_REPOBJECT

- EXECUTE_DDL

関連項目:
CHAR列セマンティクスの明示的な指定方法の詳細は、「レプリケーション・サイトおよび表の列に関する列長セマンティクス」を参照してください。

Unicodeに対するレプリケーション・サポート

Unicodeは、任意の言語からの情報を1つのキャラクタ・セットを使用して格納できる汎用のエンコードされたキャラクタ・セットです。Unicodeは使用されるプラットフォーム、プログラムまたは言語に関係なく、すべてのキャラクタにそれぞれ一意のコード値を提供します。Unicodeはマルチマスター・レプリケーション環境およびマテリアライズド・ビュー・レプリケーション環境の両方でサポートされます。Oracle9i Database以上では、NCHARまたはNVARCHAR2データ型として指定される列は、すべてUnicode形式で格納されます。

マスター・サイトとマテリアライズド・ビュー・サイトの両方で、NCHARまたはNVARCHAR2データ型を使用すると、異なるリリースのOracleが稼働する環境でのレプリケーションが可能になります。ただし、レプリケーション・サイトの一方がOracle9i Databaseより前のリリースで、可変幅キャラクタ・セットを使用している場合は、レプリケーションをお薦めしません(データが失われる可能性があります)。

表B-4に、レプリケーションが推奨される場合について要約します。

表B-4 グローバリゼーション・サポート・キャラクタ・セットに対するレプリケーション・サポート

NCHAR列またはNVARCHAR2列を含むローカル・データベースのリリース

NCHAR列およびNVARCHAR2列を含むリモート・データベースのリリース

レプリケーションの推奨

9.2以上

(Unicode形式の格納)

9.2以上

(Unicode形式の格納)

あり

9.2未満

(固定幅または可変幅の各国語キャラクタ・セット形式)

9.2未満

(固定幅または可変幅の各国語キャラクタ・セット形式)

あり

9.2以上

(Unicode形式の格納)

9.2未満

(可変幅の各国語キャラクタ・セット形式)

推奨しません

9.2以上

(Unicode形式の格納)

9.2未満

(固定幅の各国語キャラクタ・セット形式)

あり

9.2未満

(可変幅の各国語キャラクタ・セット形式)

9.2以上

(Unicode形式の格納)

推奨しません

9.2未満

(固定幅の各国語キャラクタ・セット形式)

9.2以上

(Unicode形式の格納)

あり

注意:
表B-4でレプリケーションを推奨しないと示されている場合、2つのサイト間でレプリケーションを設定してもエラーは検出されませんが、後でデータが失われる可能性があります。データが失われた場合は、エラーが発生します。

NCLOBデータ型列のレプリケーション

NCLOBデータ型は常に固定幅です。したがって、NCLOBデータ型の列のレプリケーションは制限なしでサポートされます。

索引
A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  Q  R  S  T  U  V  W

A

アカウント

マテリアライズド・ビューのための作成, 6.3.3.3

加算による競合解消方法, 5.2.3.1 管理要求キュー, 2.2.2.4 管理要求, 2.2.2.3

状態, 2.2.2.4

AWAIT_CALLBACK, 2.2.2.4

DO_CALLBACK, 2.2.2.4

ERROR, 2.2.2.4

READY, 2.2.2.4

アドバンスト・レプリケーション・インタフェース, 1.5.1 別名

列

更新可能マテリアライズド・ビュー, 3.1.3.2

AND条件

単純副問合せマテリアライズド・ビュー, 3.1.6.2

順序の追加による競合解消方法, 5.2.4.2 サイト名の追加による競合解消方法, 5.2.4.1 割当て表, 4.4.2.1 非同期レプリケーション, 1.4.1, 2.2.4.1.1 平均による競合解消方法, 5.2.3.2

B

バルク更新, A.2.5

BYTEキャラクタ・セマンティクス, B.1

C

CHARキャラクタ・セマンティクス, B.1

キャラクタ・セット

レプリケーション, B

コレクション

マテリアライズド・ビュー, 3.1.9.4

制限事項, 3.1.9.4.1

レプリケーション, 2.1.5.3, 3.1.9.4 列グループ, 5.2.1.1

列オブジェクト, 5.2.1.1.3

ネストした表, 5.2.1.1.5

オブジェクト表, 5.2.1.1.4

シャドウ, 5.2.1.1.2

列オブジェクト

列グループ, 5.2.1.1.3

競合解消

古い値の比較, 5.2.6.2

古い値の送信, 5.2.6.2

マテリアライズド・ビュー

列のサブセット化, 3.1.9.2

レプリケーション, 2.1.5, 3.1.9 列のサブセット化, 1.4.2.4

デプロイメント・テンプレート, 4.4.1

マテリアライズド・ビュー

列オブジェクト, 3.1.9.2

更新可能マテリアライズド・ビュー

競合解消, 5.1.5.2

列

キャラクタ・セマンティクス, B.1

列グループ, 2.2.3.2, 5.2.1.1

列オブジェクト, 5.2.1.1.3

複数の列グループでのデータ整合性の保証, 5.2.1.1.1

ネストした表, 5.2.1.1.5

オブジェクト表, 5.2.1.1.4

シャドウ, 5.2.1.1.2

完全リフレッシュ, 1.4.2.5, 3.2.4.1.1 複合マテリアライズド・ビュー, 3.1.4.4, 3.1.4.4.1

PCTFREEの値, 3.2.4.1.1

PCTUSEDの値, 3.2.4.1.1

圧縮, 6.1.4 競合解消, 2.2.7.2

加算による方法, 5.2.3.1

順序の追加による方法, 5.2.4.2

サイト名の追加による方法, 5.2.4.1

アーキテクチャ, 5.2

平均による方法, 5.2.3.2

競合の回避, 5.1.6

列グループ, 5.2.1.1

列オブジェクト, 5.2.1.1.3

データ整合性, 5.2.1.1.1

ネストした表, 5.2.1.1.5

オブジェクト表, 5.2.1.1.4

シャドウ, 5.2.1.1.2

列のサブセット化

更新可能マテリアライズド・ビュー, 5.1.5.2

概念, 5.1 解消方法のデータ収束プロパティ, 5.2.3 データ要件, 5.1.1 削除の競合, 5.1.2.3 競合の検出, 5.1.4 廃棄による方法, 5.2.3.3, 5.2.4.3 動的サイト所有権, 5.1.6.2 最も古いタイムスタンプによる方法, 5.2.3.4 エラー・キュー, 5.2.1.2 同期伝播, 2.2.4.2.1 最新のタイムスタンプによる方法, 5.2.2.1 最大値による方法, 5.2.3.5 削除の競合の解消方法, 5.2.5 一意性競合の解消方法, 5.2.4 更新の競合の解消方法, 5.2.2 最小値による方法, 5.2.3.6 多重化マテリアライズド・ビュー, 5.1.5.1 ネストした表, 5.1.5.3 上書きによる方法, 5.2.2.2 パフォーマンス

古い値の比較, 5.2.6

古い値の送信, 5.2.6

ビルトインの方法, 5.1.5 プライマリ・サイト所有権, 5.1.6.2 優先グループによる方法, 5.2.3.7 レプリケーション, 1.6, 2.1.4 サイト優先順位による方法, 5.2.3.8

予備の方法, 5.2.2.1, 5.2.3.4

トランザクションの順序, 5.1.3 競合のタイプ, 5.1.2 一意性競合, 5.1.2.2 更新可能マテリアライズド・ビュー

列のサブセット化, 5.1.5.2

更新の競合, 5.1.2.1 競合

回避, 5.1.6

削除, 5.1.2.3

回避, 5.1.6.3.2

検出, 2.2.4.2.3, 2.2.7, 5.1.4

行の識別, 2.2.7.1, 5.1.4.2

エラー・キュー, 5.2.1.2 順序

回避, 5.1.6.3.4

プロシージャ・レプリケーション, 1.7.2.1 一意性, 5.1.2.2

回避, 5.1.6.3.1

更新, 5.1.2.1

回避, 5.1.6.3.3

接続修飾子, 2.2.1.2.2

問題の診断方法, A.1

制約違反, A.2.5 制約

遅延可能, 3.2.4.3

参照

自己参照型, 2.2.1.3.1

連続的なパージ

スケジューリング, 6.6.2

連続的なプッシュ

スケジューリング, 6.5.2

CREATE TYPE文

OID句, 2.1.5.1.2, 3.1.9.1.2

CREATE_MVIEW_REPGROUPプロシージャ, 3.1.3.2 CREATE_MVIEW_REPOBJECTプロシージャ, 3.1.3.2

D

データ・ディクショナリ

レプリケーション, 1.5.3

データ整合性

パラレル伝播, 2.2.6.1.1

シリアル伝播, 2.2.6.1.1

データ伝播

依存性の維持, 2.2.6.1

非同期, 2.2.4.1.1

同期, 2.2.4.1.2

データベース・リンク

アドバンスト・レプリケーション・インタフェース, 2.2.1.2.1

接続修飾子, 2.2.1.2.2

問題の診断方法, A.1

指定の不備, A.3.3

マテリアライズド・ビュー・サイト, 6.3.3.4, 6.8.1.5

レプリケーション, 2.2.1.2

スケジュール・リンク, 1.4.3.1

日付式, 3.2.4.2.1, 4.3.3.2 DBA_MVIEW_REFRESH_TIMESビュー, 3.1.10.1 DBA_REGISTERED_MVIEWSビュー, 3.1.10.1 DBA_REPCATLOGビュー, 2.2.2.3.1 DBA_TYPE_VERSIONS

レプリケーション, 2.1.5.1, 3.1.9.1

DBMS_DEFER_SYSパッケージ

SCHEDULE_PUSHプロシージャ, 6.5.1, 6.5.2

DBMS_MVIEWパッケージ, 3.1.10.3

EXPLAIN_MVIEWプロシージャ, 3.1.7

REGISTER_MVIEWプロシージャ, 3.1.10.3

DBMS_REPCATパッケージ, 2.2.2.3.1, 2.2.2.3.1, 2.2.2.4, 3.1.3.2, 6.11.3.1.1

COMPARE_OLD_VALUESプロシージャ

競合解消, 5.2.6

CREATE_MVIEW_REPGROUPプロシージャ, 3.1.3.2 DO_DEFERRED_REPCAT_ADMINプロシージャ, 2.2.2.3.1, 2.2.2.4 SEND_OLD_VALUESプロシージャ

競合解消, 5.2.6

DDL文

レプリケーション, 1.5.4

問題のトラブルシューティング, A.2.2

デッドロック

解消

同期伝播, 2.2.4.2.1

遅延トランザクション・キュー, 1.4.1, 2.2.1.6

問題の診断方法, A.3

伝播済トランザクションのパージ, 6.6

プッシュ, 2.2.1.8.3

スケジュール・パージ, 6.3.3.6

スケジュール・プッシュ, 6.3.3.7

DELAY_SECONDSパラメータ, 2.2.5.3 依存性

最小化, 2.2.6.1.3

依存性

順序

レプリケート・トランザクション, 2.2.6.1

追跡

パラレル伝播, 2.2.6.1.1

行レベル, 2.2.6.1.2, 6.1.5

デプロイメント・テンプレート, 1.4.2.8, 4

マテリアライズド・ビューの追加, 4.3.1.1

インスタンス化の結果, 4.3.3

アーキテクチャ, 4.3

列のサブセット化, 4.4.1

概念, 4.2

データ・セット, 4.4.3

DDL文, 4.3.1.1

定義の格納, 4.3.1

設計, 4.4

要素, 4.2.1

テンプレート一般情報, 4.2.1.1

インスタンス化, 1.4.2.8.1, 4.2.2

オフライン, 4.2.2.2, 4.3.2.4

オンライン, 4.2.2.1, 4.3.2.3

オプション, 4.3.2.5

プロセス, 4.3.2

使用例, 4.2.2.3

トラブルシューティング, A.4.2

ローカル制御, 4.5.1 マテリアライズド・ビュー・グループ, 4.3.3.1 マテリアライズド・ビュー・ログ, 4.2.2.3 マテリアライズド・ビュー・サイト, 4.2.1.6 オブジェクト

定義, 4.2.1.2, 4.3.1.1

パッケージ化, 4.2.2

オフライン・インスタンシエーション用, 4.3.2.2

オンライン・インスタンシエーション用, 4.3.2.1

オプション, 4.3.2.5

プロシージャ, 4.2.2.3

プロセス, 4.3.2

パラメータ, 4.2.1.3

セキュリティ, 4.2.1.4

マテリアライズド・ビュー・サイトの準備, 6.8 リフレッシュ・グループ, 4.3.3.2 行のサブセット化, 4.4.2 ユーザー認証, 4.2.1.5 ユーザー定義型, 4.2.1.2 WHERE句, 4.2.1.4 ダイレクト・パス・ロード

高速リフレッシュ, 3.2.4.1.2

廃棄による競合解消方法, 5.2.3.3, 5.2.4.3 分散スキーマ管理, 1.5.4 分散トランザクション

問題, A.3.2

DML文

レプリケーション

問題のトラブルシューティング, A.2.3

DO_DEFERRED_REPCAT_ADMINプロシージャ, 2.2.2.3.1, 2.2.2.3.1, 2.2.2.4 ドメイン索引

レプリケーション, 2.2.1.3.2

動的サイト

所有権, 5.1.6.2

E

最も古いタイムスタンプによる競合解消方法, 5.2.3.4

Enterprise Manager

アドバンスト・レプリケーション・インタフェース, 1.5.1, 2.2.1.2.1

エラー

エラー・キュー, 2.2.1.8.2

競合, 5.2.1.2

EXISTS条件

副問合せを使用するマテリアライズド・ビュー, 3.1.6.2

EXPLAIN_MVIEWプロシージャ, 3.1.7

F

フェイルオーバー・サイト

FAILOVERオプションを使用した実装, 6.11.3

高速リフレッシュ, 1.4.2.5, 3.2.4.1.2

問題の回避, 6.3.6

使用可能かどうかの判断, 3.1.7

ダイレクト・パス・ロード, 3.2.4.1.2

多重化マテリアライズド・ビュー, 3.2.4.1.2

フィルタ列, 6.3.4.1 フラッシュバック・データ・アーカイブ, 6.1.4 強制リフレッシュ, 1.4.2.5, 3.2.4.1.3 外部キー

レプリケート表, 6.1.2

ファンクション索引

レプリケーション, 2.2.1.3.1

ファンクション

レプリケート, 2.2.1.3.4

G

GLOBAL_NAMES初期化パラメータ, 6.2

グループ所有者

マテリアライズド・ビュー・グループ, 3.2.3.1.1

H

水平パーティション化。「行のサブセット化」を参照

I

インポート

マテリアライズド・ビュー・ログ, 3.2.1.3.2

レプリケーションのチェック, 6.11.3.1.1

索引

マテリアライズド・ビュー・サイト, 3.2.2.1

外部キー, 6.1.2

レプリケーション, 2.2.1.3.2

索引タイプ

レプリケーション, 2.2.1.3.8

初期化パラメータ

編集, 6.3.3.8

GLOBAL_NAMES, 6.2

JOB_QUEUE_PROCESSES, 6.2

MEMORY_MAX_TARGET, 6.2

MEMORY_TARGET, 6.2

NLS_LENGTH_SEMANTICS, B.1

OPEN_LINKS, 2.2.1.2.2, 6.2

PARALLEL_MAX_SERVERS, 2.2.5.1, 6.2

PARALLEL_MIN_SERVERS, 2.2.5.1, 6.2

PROCESSES, 6.2

レプリケーション, 6.2

REPLICATION_DEPENDENCY_TRACKING, 6.2

SGA_TARGET, 6.2

SHARED_POOL_SIZE, 6.2

INIT.ORAパラメータ。「初期化パラメータ」を参照 インスタンス化

デプロイメント・テンプレート, 1.4.2.8.1, 4.2.2

相互運用性

レプリケーション, 6.4

J

ジョブ・キュー, 2.2.1.8.3

ジョブ・スレーブ

レプリケーション, 6.3.3.8

JOB_QUEUE_PROCESSES初期化パラメータ, 6.2, 6.3.3.8 ジョブ

スケジュール・リンクのチェック, A.3.1

レプリケーション, 2.2.2.3.1

L

最新のタイムスタンプ

競合解消方法, 5.2.2.1

長さセマンティクス

レプリケーション, B.1

レベル

多重化マテリアライズド・ビュー, 3.1.8

M

多対多副問合せ

マテリアライズド・ビュー, 3.1.6.1.3

多対1副問合せ

マテリアライズド・ビュー, 3.1.6.1.1

大規模デプロイメント, 3.1.2.2, 4.1 マスター定義サイト, 1.3.3, 2.1.1.3.1 マスター・グループ, 1.3.3, 2.2.3.1 マスター・マテリアライズド・ビュー・サイト, 3.2.1 マスター・マテリアライズド・ビュー, 1.4.2, 3.1.8, 3.2.1.1

マテリアライズド・ビュー・ログ, 3.2.1.3

マスター・サイト, 1.3.3

追加

循環依存性, 2.2.1.3.1

自己参照型制約, 2.2.1.3.1

利点, 6.3.1 バルク更新, A.2.5 マテリアライズド・ビュー・サイトとの比較, 6.3 制約

違反, A.2.5

DDLによる変更が伝播されない場合, A.2.2 問題の診断方法, A.2 DMLによる変更が伝播されない場合, A.2.3 内部トリガー, 3.2.1.2 長さセマンティクス, B.2

事前作成された表, B.2.2

マテリアライズド・ビューの登録, 3.1.10 マテリアライズド・ビュー, 3.2.1 新しいマスター・サイトでレプリケート・オブジェクトが作成されない場合, A.2.1 レプリケーション, 2.2.1 ロール, 2.2.1.1 スケジュール・リンク

ガイドライン, 6.5

スケジュール・パージ, 6.3.3.6

ガイドライン, 6.6

ユーザー, 2.2.1.1 マスター表

マテリアライズド・ビュー・ログ, 3.2.1.3

マテリアライズド・ビュー, 3.2.1.1

オンラインでの再定義, 3.2.1.3

再編成, 3.2.1.3

マテリアライズド・ビュー・グループ, 1.3.3, 3.1.8.2.2, 3.2.3.1

デプロイメント・テンプレート, 4.3.3.1

グループ所有者, 3.2.3.1.1

所有権, 3.1.8.2.2

更新可能マテリアライズド・ビュー, 3.2.3.1

マテリアライズド・ビュー・ログ, 1.4.2.7, 3.2.1.3

列の追加, 6.3.4.1

列のロギング, 3.1.6.2

多対多副問合せ, 3.1.6.2

多対1副問合せ, 3.1.6.2

ON PREBUILT TABLE句, 3.1.6.2

1対多副問合せ, 3.1.6.2

組合せ, 3.2.1.3 作成, 6.3.4 デプロイメント・テンプレート, 4.2.2.3 フィルタ列, 6.3.4.1 インポート, 3.2.1.3.2 結合列, 6.3.4.1 列のロギング, 6.3.4.1 オブジェクト識別子, 3.2.1.3 オブジェクト表, 3.2.1.3.1 主キー, 3.2.1.3 作成に必要な権限, 6.3.4 REF, 3.1.9.5.3 ROWID, 3.2.1.3 トリガー, 3.2.1.2 トラブルシューティング, A.4.3.5 基礎となる表, 3.2.1.3 マテリアライズド・ビュー・サイト, 1.3.3

追加

問題の回避, 6.3.6

利点, 6.3.2 マスター・サイトとの比較, 6.3 データベース・リンク, 6.3.3.4, 6.8.1.5 データベースのバージョン, 6.8.1.2 遅延トランザクション・キュー

スケジュール・プッシュ, 6.3.3.7

デプロイメント・テンプレート, 4.2.1.6 長さセマンティクス, B.3

ビルトインのコンテナ表, B.3.1

ローカルでの作成, 4.5 ネットワーク接続性, 6.8.1.1 デプロイメント・テンプレートの準備, 6.8 ロールバック・セグメント, 6.8.1.7 スケジュール・パージ

ガイドライン, 6.6

スケジュール・リンク

ガイドライン, 6.5

スキーマ, 6.8.1.4 設定, 6.8.1.3 マテリアライズド・ビュー, 1.4.2, 3

アーキテクチャ, 3.2

BUILD DEFERRED

トラブルシューティング, A.4.4

性能, 3.1.7 コレクション列

制限事項, 3.1.9.4.1

列オブジェクト

列のサブセット化, 3.1.9.2

列のサブセット化, 1.4.2.4

列オブジェクト, 3.1.9.2

複合, 3.1.4.4, 3.1.4.4.1

PCTFREEの値, 3.2.4.1.1

PCTUSEDの値, 3.2.4.1.1

概念, 3.1 制約

遅延可能, 3.2.4.3

作成, 6.3.5 スキーマの作成, 6.3.3.3 作成者, 3.1.5 データのサブセット化, 3.1.2.3, 3.1.6 デプロイメント・テンプレート, 1.4.2.8, 4

ユーザー定義型, 4.2.1.2

モバイル・コンピューティング, 3.1.2.4 索引, 3.2.2.1 長さセマンティクス, B.3

ビルトインのコンテナ表, B.3.1

ローカル制御, 4.5.1 大規模デプロイメント, 3.1.2.2 マスター・マテリアライズド・ビュー・サイト, 3.2.1 マスター・マテリアライズド・ビュー, 3.2.1.1 マスター・サイト, 3.2.1 マスター表, 3.2.1.1 マテリアライズド・ビュー・グループ, 3.2.3.1 マテリアライズド・ビュー・ログ, 1.4.2.7, 3.2.1.3 多重化, 1.4.2, 3.1.8, 3.1.8.2.2

競合解消, 5.1.5.1

高速リフレッシュ, 3.2.4.1.2

レベル, 3.1.8

マスター・マテリアライズド・ビュー, 3.1.8

制限事項, 3.1.8.2

ネストした表

制限事項, 3.1.9.4.1

ネットワーク負荷, 3.1.2.1 オブジェクト・マテリアライズド・ビュー, 3.1.9.3.1

OIDの保持, 3.1.9.3.3

オブジェクト表, 3.1.9.3 所有者, 3.1.5 パーティション・チェンジ・トラッキング(PCT), 3.2.4.1.2 準備, 6.3.3 主キー, 3.1.4.1 権限, 3.1.5, 6.3.3.5 読取り専用, 1.4.2.1, 3.1.3.1

登録, 3.1.10.3

登録解除, 3.1.10.3

リフレッシュ・グループ, 1.4.2.6, 3.2.3.2

サイズ, 3.2.3.3

リフレッシャ, 3.1.5 リフレッシュ, 1.4.2.5, 3.2.4

完全, 3.2.4.1.1

障害, A.4.3.2

高速, 3.1.7, 3.2.4.1.2

強制, 3.2.4.1.3

開始, 3.2.4.2

間隔, 3.2.4.2.1

必要に応じた, 3.2.4.2.2

最終リフレッシュ時刻の問合せ, 3.1.10.1

再試行, A.4.3.2

トラブルシューティング, A.4.3, A.4.3.4

REF, 3.1.9.5

ロギング, 3.1.9.5.3

有効範囲付き, 3.1.9.5.1

有効範囲なし, 3.1.9.5.2

WITH ROWID句, 3.1.9.5.4

登録, 3.1.10 再編成, 3.2.1.3 行のサブセット化, 1.4.2.4, 3.1.6 ROWID, 3.1.4.3 単純, 3.1.4.4.1 単純副問合せ

AND条件, 3.1.6.2

副問合せ, 3.1.6.1

列のロギング, 3.1.6.2

EXISTS条件, 3.1.6.2

結合, 3.1.6.2

多対多, 3.1.6.1.3

多対1, 3.1.6.1.1

1対多, 3.1.6.1.2

OR条件, 3.1.6.2

制限事項, 3.1.6.2, 3.1.6.2

トレース・ファイル, A.4.3.2 トラブルシューティング, A.4 タイプ, 3.1.4 副問合せを使用したUNION, 3.1.6.1.4

制限事項, 3.1.6.3

更新可能, 1.4.2.2, 3.1.3.2

列別名, 3.1.3.2

DELETE CASCADE制約, 3.1.3.2, 3.2.4.3

長さセマンティクス, B.3.2

マテリアライズド・ビュー・グループ, 3.2.3.1

更新可能マテリアライズド・ビュー・ログ, 3.2.2.2

トリガー, 3.2.2.3

ユーザー定義, 3.1.9 ユーザー定義データ型

ON COMMIT REFRESH句, 3.1.9

使用目的, 3.1.2 VARRAY

r, 3.1.9.4.1

書込み可能, 3.1.3.3 最大値による競合解消方法, 5.2.3.5 MEMORY_MAX_TARGET初期化パラメータ, 6.2 MEMORY_TARGET初期化パラメータ, 6.2 最小限の通信, 2.2.5.2 最小値による競合解消方法, 5.2.3.6 マルチマスター・レプリケーション, 1.4.1, 2

アーキテクチャ, 2.2

非同期, 2.1.3, 2.1.3.1

概念, 2.1

非接続マテリアライズド・ビュー, 2.1.2.3

フェイルオーバー, 2.1.2.1

ロード・バランシング, 2.1.2.2

同期, 2.1.3, 2.1.3.2

トランザクション伝播保護, 2.2.6

使用目的, 2.1.2

多重化マテリアライズド・ビュー, 1.4.2, 3.1.8

競合解消, 5.1.5.1

高速リフレッシュ, 3.2.4.1.2

レベル, 3.1.8

マスター・マテリアライズド・ビュー, 3.1.8

制限事項, 3.1.8.2.1

マテリアライズド・ビュー・グループ

所有権, 3.1.8.2.2

制限事項, 3.1.8.2

N

NCHARデータ型

Unicode, B.5

NCLOBデータ型

長さセマンティクス, B.5.1

ネストした表

列グループ, 5.2.1.1.5

競合解消, 5.1.5.3

マテリアライズド・ビュー, 3.1.9.4

制限事項, 3.1.9.4.1

レプリケーション, 2.1.5.3, 3.1.9.4 ネットワーク

FAILOVERオプション, 6.11.3

NLS_LENGTH_SEMANTICS初期化パラメータ, B.1 NOROWDEPENDENCIES句, 2.2.6.1.2 NVARCHARデータ型

Unicode, B.5

n-wayレプリケーション。「マルチマスター・レプリケーション」を参照

O

オブジェクト識別子

レプリケーションのための一致, 2.1.5.1, 3.1.9.1

オブジェクト・マテリアライズド・ビュー, 3.1.9.3.1

OIDの保持, 3.1.9.3.3

オブジェクト表

列グループ, 5.2.1.1.4

マテリアライズド・ビュー・ログ, 3.2.1.3.1

マテリアライズド・ビュー, 3.1.9.3

レプリケーション, 2.1.5.2

オブジェクト・リレーショナル・モデル

レプリケーション, 2.1.5, 3.1.9

オブジェクト

レプリケート

再作成, A.2.6

OF object_type句

オブジェクト・マテリアライズド・ビュー, 3.1.9.3.1

OID句

CREATE TYPE文, 2.1.5.1.2, 3.1.9.1.2

ON COMMIT REFRESH句

CREATE MATERIALIZED VIEW, 3.1.9

ON PREBUILT TABLE句, 3.1.6.2

長さセマンティクス, B.3.1

1対多副問合せ

マテリアライズド・ビュー, 3.1.6.1.2

表のオンライン再定義, 3.2.1.3 OPEN_LINKS初期化パラメータ, 2.2.1.2.2, 6.2 OR条件

副問合せを使用するマテリアライズド・ビュー, 3.1.6.2

Oracle Real Application Clusters

アドバンスト・レプリケーションとの比較, 2.1.2.4, 6.11.1

上書きによる競合解消方法, 5.2.2.2

P

パッケージ

レプリケーション, 2.2.1.3.3

デプロイメント・テンプレートのパッケージ化, 4.2.2 パラレル伝播, 2.2.5.1

レプリケーション環境用の構成, 2.2.5.1

依存性

追跡, 2.2.6.1.1

実装, 2.2.5.1.1 計画, 6.7 レプリケーション環境, 6.7 行レベルSCN, 2.2.6.1.2 チューニング, 2.2.5.1.2 PARALLEL_MAX_SERVERS初期化パラメータ, 2.2.5.1, 6.2 PARALLEL_MIN_SERVERS初期化パラメータ, 2.2.5.1, 6.2 パラメータ

デプロイメント・テンプレート, 4.2.1.3

PCTFREEパラメータ

複合マテリアライズド・ビューの値, 3.2.4.1.1

PCTUSEDパラメータ

複合マテリアライズド・ビューの値, 3.2.4.1.1

peer-to-peerレプリケーション。「マルチマスター・レプリケーション」を参照 パフォーマンス

レプリケーション, 2.2.5

定期的なパージ

スケジューリング, 6.6.1

定期的なプッシュ

スケジューリング, 6.5.1

計画

レプリケーション用, 6

主キー制約

マテリアライズド・ビュー, 3.1.4.1

レプリケート表, 6.1.1

プライマリ・サイト

所有権, 5.1.6.2

優先グループによる競合解消方法, 5.2.3.7 権限

マテリアライズド・ビュー, 3.1.5, 6.3.3.5

プロシージャ・レプリケーション, 1.7.2

競合の検出, 1.7.2.1

制限事項, 2.2.1.3.3

ラッパー, 1.7.2

プロシージャ

レプリケート, 2.2.1.3.4

PROCESSES初期化パラメータ, 6.2 伝播, 2.2.4

開始, 2.2.4.4

モード, 2.2.4.3

パラレル, 2.2.5.1

実装, 2.2.5.1.1

チューニング, 2.2.5.1.2

プロパゲータのセキュリティ・コンテキスト, 2.2.4.2 プロパゲータ

レプリケーション, 2.2.1.1.2

パージ

遅延トランザクション・キュー

連続的なスケジューリング, 6.6.2

定期的なスケジューリング, 6.6.1

プッシュ

遅延トランザクション・キュー

連続的なスケジューリング, 6.5.2

定期的なスケジューリング, 6.5.1

Q

静止, 1.4.1.1, 2.2.2.1

シングル・マスター

減少, 3.1.3.2

R

read-o, 3.1.10.3

読取り専用マテリアライズド・ビュー, 1.4.2.1, 3.1.3.1

登録

手動, 3.1.10.3

受信者

レプリケーション, 2.2.1.1.3

リカバリ

レプリケーション環境, 6.11.3.1

表の再定義

オンライン

レプリケーション, 3.2.1.3

参照整合性

自己参照型制約, 2.2.1.3.1

リフレッシュ

自動, 3.2.4.2.1

完全, 3.2.4.1.1

障害, A.4.3.2

高速, 3.2.4.1.2

使用可能かどうかの判断, 3.1.7

強制, 3.2.4.1.3 グループ, 3.2.4.2.1 開始, 3.2.4.2 間隔, 3.2.4.2.1 手動, 3.2.4.2.2 マテリアライズド・ビュー, 1.4.2.5, 3.2.4 必要に応じた, 3.2.4.2.2 再試行, A.4.3.2 ロールバック・セグメント

トラブルシューティング, A.4.4

スケジューリング, 3.2.4.2.1

トラブルシューティング, A.4.4

トラブルシューティング

ORA-12004エラー, A.4.4

ORA-942エラー, A.4.4

マテリアライズド・ビューの切捨て

トラブルシューティング, A.4.4

リフレッシュ・グループ, 1.3.3, 1.4.2.6, 3.2.3.2

デプロイメント・テンプレート, 4.3.3.2

サイズに関する考慮事項, 3.2.3.3

トラブルシューティング, A.4.3

REFRESHプロシージャ, 3.2.4.2.2 REFRESH_ALL_MVIEWSプロシージャ, 3.2.4.2.2 REFRESH_DEPENDENTプロシージャ, 3.2.4.2.2 REF

マテリアライズド・ビュー, 3.1.9.5

レプリケーション, 2.1.5.4, 3.1.9.5

REGISTER_MVIEWプロシージャ, 3.1.10.3 REPCAT_IMPORT_CHECKプロシージャ, 6.11.3.1.1 レプリケーション

レプリケーション, 1.5, 2.2.2

管理要求キュー, 2.2.2.4

管理要求, 2.2.2.3

状態, 2.2.2.4

アプリケーションでの使用, 1.2 割当て表, 4.4.2.1 非同期伝播, 1.4.1, 2.2.4.1.1 可用性, 6.11 キャラクタ・セット, B インポートされたデータのチェック, 6.11.3.1.1 列グループ, 2.2.3.2 列のサブセット化, 1.4.2.4 Oracle Real Application Clustersとの比較, 2.1.2.4, 6.11.1 競合解消, 1.6, 2.1.4, 2.2.7.2 競合

検出, 2.2.7

プロシージャ・レプリケーション, 1.7.2.1

接続修飾子, 2.2.1.2.2 データ要件, 5.1.1 データベース・リンク, 2.2.1.2

アドバンスト・レプリケーション・インタフェース, 2.2.1.2.1

CONNECT TO句, 2.2.1.2

USING句, 2.2.1.2

DDL文, 1.5.4 遅延トランザクション・キュー, 2.2.1.8.1

問題の診断方法, A.3

遅延トランザクション, 1.4.1, 2.2.1.6 定義, 1.1 DELAY_SECONDSパラメータ, 2.2.5.3 依存性

最小化, 2.2.6.1.3

依存性の追跡, 2.2.6.1.2 デプロイメント・テンプレート, 1.4.2.8, 4

ユーザー定義型, 4.2.1.2

分散スキーマ管理, 1.5.4 エラー・キュー, 2.2.1.8.2 フェイルオーバー, 6.11.3 フィルタ列, 6.3.4.1 グループ, 1.3.2, 2.2.3.1 ハイブリッド構成, 1.4.3 インポートのチェック, 6.11.3.1.1 索引タイプ, 2.2.1.3.8 初期化パラメータ, 6.2 内部プロシージャ, 2.2.1.7 内部トリガー, 2.2.1.5 相互運用性, 6.4 概要, 1.1 ジョブ・キュー, 2.2.1.8.3 ジョブ・スレーブ, 6.3.3.8 ジョブ, 2.2.2.3.1 大規模デプロイメント, 4.1 マスター, 1.4.2 マスター定義サイト, 1.3.3 マスター・グループ, 1.3.3, 2.2.3.1 マスター・マテリアライズド・ビュー, 1.4.2 マスター・サイト, 1.3.3, 2.2.1

利点, 6.3.1

マテリアライズド・ビュー・グループ, 1.3.3 マテリアライズド・ビュー・ログ, 1.4.2.7 マテリアライズド・ビュー・サイト

利点, 6.3.2

マテリアライズド・ビュー, 1.4.2, 3 最小限の通信, 2.2.5.2 モード, 2.2.2.1 マルチマスター, 1.4.1, 2 多重化マテリアライズド・ビュー, 1.4.2 オブジェクト, 2.2.1.3 パフォーマンス, 2.2.5 計画, 6 問題

トラブルシューティング, A

プロシージャ・レプリケーション, 1.7.2 プロシージャ

トラブルシューティング, A.2.8

伝播, 2.2.4 プロパゲータ, 2.2.1.1.2 静止, 1.4.1.1, 2.2.2.1 リアルタイム・レプリケーション。「同期レプリケーション」を参照 受信者, 2.2.1.1.3 リフレッシュ, 1.4.2.5 リフレッシュ・グループ, 1.3.3, 1.4.2.6 レプリケーション管理者, 2.2.1.1.1 レプリケーション・マネージメントAPI, 1.5.2 再開, 2.2.2.2.2 行のサブセット化, 1.4.2.4 スケジュール・リンク, 1.4.3.1 「マテリアライズド・ビュー」を参照 シングル・マスター, 2.1.1.2 サイト, 1.3.3

選択, 6.3

耐障害性, 6.11 中断, 2.2.2.2.1 同期, 1.7.1, 2.2.4.1.2 表, 6.1

DMLの非互換性, A.2.4

依存性の追跡, 6.1.5

DMLの非互換性, A.2.4

トランザクション伝播保護, 2.2.6 トランザクション

依存性の順序, 2.2.6.1

トリガー

トラブルシューティング, A.2.8

トラブルシューティング, A Unicode, B.5 サポートされていないデータ型

BFILE, 6.1.3

LONG, 6.1.3

サポートされていない表タイプ, 6.1.4 ユーザー定義データ型, 2.1.5, 3.1.9 使用方法, 1.1 仮想プライベート・データベース(VPD), 6.3.3.4 レプリケーション・カタログ, 1.5.3

DBA_MVIEW_REFRESH_TIMES, 3.1.10.1

DBA_REGISTERED_MVIEWS, 3.1.10.1

DBA_REPCATLOG, 2.2.2.3.1

不適切なビュー, A.3.4

USER_REFRESH, A.4.3.2

USER_REFRESH_CHILDREN, A.4.3.2

レプリケーション・マネージメントAPI, 1.5.2, 2.2.2.3 レプリケーション・オブジェクト, 1.3.1, 2.2.1.3.7, 2.2.1.3.7

マテリアライズド・ビュー・サイト

作成に関する問題, A.4.1

ファンクション, 2.2.1.3.4 索引, 2.2.1.3.2

ファンクション, 2.2.1.3.1

外部キー, 6.1.2

パッケージ, 2.2.1.3.3 プロシージャ, 2.2.1.3.4 再作成, A.2.6 順序, 2.2.1.4 表, 2.2.1.3.1, 6.1

依存性の追跡, 6.1.5

DMLの非互換性, A.2.4

外部キー, 6.1.2

主キー, 6.1.1

サポートを生成できない場合, A.2.7

トリガー, 2.2.1.3.6 REPLICATION_DEPENDENCY_TRACKING初期化パラメータ, 6.2 制限事項

プロシージャ・レプリケーション, 2.2.1.3.3

ロールバック・セグメント

マテリアライズド・ビュー・サイト, 6.8.1.7

行のサブセット化, 1.4.2.4

デプロイメント・テンプレート, 4.4.2

マテリアライズド・ビュー, 3.1.6

ROWDEPENDENCIES句, 2.2.6.1.2

表の作成, 6.1.5

ROWID

ROWIDマテリアライズド・ビュー, 3.1.4.3

行

競合検出時の識別, 2.2.7.1

S

SCHEDULE_PUSHプロシージャ, 6.5.1, 6.5.2

スケジュール・リンク, 1.4.3.1, 6.3.3.7

連続的なプッシュ, 6.5.2

ガイドライン, 6.5

パラレル伝播, 6.7

定期的なプッシュ, 6.5.1

シリアル伝播, 6.7

スケジュール・パージ

ガイドライン, 6.6

定期的なパージ, 6.6.1

スキーマ

マテリアライズド・ビューのための作成, 6.3.3.3

セキュリティ

デプロイメント・テンプレート, 4.2.1.4

SEND_OLD_VALUESプロシージャ, 5.2.6 順序

レプリケーション, 2.2.1.4

SGA_TARGET初期化パラメータ, 6.2 シャドウ列グループ, 5.2.1.1.2 SHARED_POOL_SIZE初期化パラメータ, 6.2 単純マテリアライズド・ビュー, 3.1.4.4.1 サイト優先順位による競合解消方法, 5.2.3.8

予備の方法として, 5.2.2.1, 5.2.3.4

スナップショット。「マテリアライズド・ビュー」を参照 ストア/フォワード・レプリケーション。「非同期レプリケーション」を参照 副問合せ

UNION

マテリアライズド・ビュー, 3.1.6.1.4

マテリアライズド・ビュー, 3.1.6.1, 3.1.6.2

AND条件, 3.1.6.2

列のロギング, 3.1.6.2

EXISTS条件, 3.1.6.2

結合, 3.1.6.2

多対多, 3.1.6.1.3

多対1, 3.1.6.1.1

1対多, 3.1.6.1.2

制限事項, 3.1.6.2

サブセット化

マテリアライズド・ビュー, 3.1.6

列オブジェクト, 3.1.9.2

耐障害性, 6.11

設計上の考慮事項, 6.11.2

実装, 6.11.3

Oracle Real Application Clusters, 6.11.1

同期レプリケーション, 1.7.1, 2.2.4.1.2, 2.2.4.1.2

トランザクションの接続先, 2.2.4.2.2

シノニム, 2.2.1.3.7

レプリケーション, 2.2.1.3.7

システム変更番号

行レベル, 2.2.6.1.2, 6.1.5

T

表圧縮, 6.1.4

表

長さセマンティクス, B.2

事前作成

長さセマンティクス, B.2.2

レプリケーション・サポートの生成に関する問題, A.2.7 オンラインでの再定義

レプリケーション, 3.2.1.3

レプリケート, 2.2.1.3.1, 6.1

依存性の追跡, 6.1.5

DMLの非互換性, A.2.4

一時表, 6.1.4 トレース・ファイル

マテリアライズド・ビュー, A.4.3.2

トランザクション

伝播

保護メカニズム, 2.2.6

透過的データ暗号化, 6.1.4 トリガー

マテリアライズド・ビュー・ログ, 3.2.1.2

更新可能マテリアライズド・ビュー・ログ, 3.2.2.3

レプリケート,2.2.1.3.6

トラブルシューティング

レプリケーションの問題, A

U

Unicode

NCHARデータ型, B.5

NVARCHARデータ型, B.5

レプリケーション, B.5

UNION

副問合せ

マテリアライズド・ビュー, 3.1.6.1.4

マテリアライズド・ビューでの制限事項, 3.1.6.3

UNREGISTER_MVIEWプロシージャ, 3.1.10.3 更新可能, 5.1.5.2 更新可能マテリアライズド・ビュー・ログ, 3.2.2.2

トリガー, 3.2.2.3

更新可能マテリアライズド・ビュー, 1.4.2.2, 3.1.3.2

列のサブセット化, 5.1.5.2

DELETE CASCADE制約, 3.1.3.2, 3.2.4.3

長さセマンティクス, B.3.2

マテリアライズド・ビュー・グループ, 3.2.3.1

us, 3.1.9.2 USER_REFRESHビュー, A.4.3.2 USER_REFRESH_CHILDRENビュー, A.4.3.2 ユーザー定義データ型

マテリアライズド・ビュー, 3.1.9

コレクション, 3.1.9.4

オブジェクト表, 3.1.9.3

ON COMMIT REFRESH句, 3.1.9

REF, 3.1.9.5

型の一致, 3.1.9.1

レプリケーション, 2.1.5, 3.1.9

コレクション, 2.1.5.3, 3.1.9.4

列オブジェクト, 2.1.5, 3.1.9

オブジェクト表, 2.1.5.2

REF, 2.1.5.4, 3.1.9.5

型の一致, 2.1.5.1, 3.1.9.1

USLOG$_, 3.2.2.2

V

VARRAY

マテリアライズド, 3.1.9.4

マテリアライズド・ビュー

制限事項, 3.1.9.4.1

レプリケーション, 2.1.5.3, 3.1.9.4 垂直パーティション化。「列のサブセット化」を参照 ビュー, 2.2.1.3.7

レプリケーション, 2.2.1.3.7

仮想列, 6.1.4 仮想プライベート・データベース(VPD)

アドバンスト・レプリケーション要件, 6.3.3.4

W

WHERE句

デプロイメント・テンプレート, 4.2.1.4

WITH ROWID句

REF, 3.1.9.5.4

ラッパー

プロシージャ・レプリケーション, 1.7.2

書込み可能マテリアライズド・ビュー, 3.1.3.3

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。