Oracle® TimesTen In-Memory Database

開発者および管理者ガイド

11g リリース2(11.2.2)

B66443-07(原本部品番号:E21635-11)

2014年10月

Oracle TimesTen In-Memory Database開発者および管理者ガイド, 11g リリース2(11.2.2)

B66443-07

Copyright © 2012, 2014, 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および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の登録商標です。

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

目次

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

はじめに

- 対象読者

- 関連ドキュメント

- 表記規則

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

新機能

- リリース11.2.2.8.0の新機能

- リリース11.2.2.7.0の新機能

- リリース11.2.2.5.0の新機能

- リリース11.2.2.4.0の新機能

- リリース11.2.2.2.0の新機能

- リリース11.2.2.1.0の新機能

- リリース11.2.2.0.0の新機能

1 TimesTenレプリケーションの概要

- レプリケーションとは

- レプリケーションの互換性の要件

- レプリケーション・エージェント

- データベース間の更新のコピー

- デフォルトのレプリケーション

- RETURN RECEIPTレプリケーション

- RETURN TWOSAFEレプリケーション

- レプリケーション・スキームのタイプ

- アクティブ・スタンバイ・ペアおよび読取り専用サブスクライバ

- クラシック・レプリケーション

- データベース全体のレプリケーションまたは選択レプリケーション

- 単方向レプリケーションまたは双方向レプリケーション

- 直接レプリケーションまたは伝播

- キャッシュ・グループとレプリケーション

- AWTキャッシュ・グループのレプリケート

- Oracle Databaseに伝播するサブスクライバを持つAWTキャッシュ・グループのレプリケート

- 読取り専用キャッシュ・グループのレプリケート

- 順序およびレプリケーション

- 外部キーとレプリケーション

- エージングおよびレプリケーション

2 スタート・ガイド

- 1つのサブスクライバを持つアクティブ・スタンバイ・ペアの構成

- 手順1: マスター・データベースおよびサブスクライバ・データベースのDSNの作成

- 手順2: いずれかのマスター・データベースでの表の作成

- 手順3: アクティブ・スタンバイ・ペアの定義

- 手順4: マスター・データベースでのレプリケーション・エージェントの起動

- 手順5: マスター・データベースのACTIVE状態への設定

- 手順6: アクティブ・データベースでのユーザーの作成

- 手順7: スタンバイ・データベースへのアクティブ・データベースの複製

- 手順8: スタンバイ・データベースでのレプリケーション・エージェントの起動

- 手順9: サブスクライバへのスタンバイ・データベースの複製

- 手順10: サブスクライバでのレプリケーション・エージェントの起動

- 手順11: アクティブ・データベースにある表へのデータの挿入

- 手順12: アクティブ・スタンバイ・ペアおよび表の削除

- 1つのマスターと1つのサブスクライバを持つレプリケーション・スキームの構成

- 手順1: マスターおよびサブスクライバのDSNの作成

- 手順2: マスター・データベースでの表およびレプリケーション・スキームの作成

- 手順3: サブスクライバ・データベースでの表およびレプリケーション・スキームの作成

- 手順4: 各データベースでのレプリケーション・エージェントの起動

- 手順5: マスター・データベースにある表へのデータの挿入

- 手順6: レプリケーション・スキームおよび表の削除

3 アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義

- マスター・データベースの状態の概要

- データベースの複製

- アクティブ・スタンバイ・ペアの制限

- データベースのDSNの定義

- アクティブ・スタンバイ・ペアの表要件

- アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義

- アクティブ・スタンバイ・ペア内のデータベースの識別

- アクティブ・スタンバイ・ペアに対するRETURNサービスの使用

- アクティブ・スタンバイ・ペアに対するSTORE属性の設定

- アクティブ・スタンバイ・ペアに対するネットワーク操作の構成

- アクティブ・スタンバイ・ペアの自動クライアント・フェイルオーバーの使用

- レプリケーションに対するデータベース・オブジェクトの挿入または除外

- アクティブ・スタンバイ・ペア内の外部キーで関連付けられている表のレプリケーション

- アクティブ・スタンバイ・ペア内のマテリアライズド・ビュー

- アクティブ・スタンバイ・ペア内の順序のレプリケート

4 レプリケーション・スキームの属性とオプションの定義

- RETURNサービスの使用

- クラシック・レプリケーション・スキーム内の各サブスクライバに対する異なるRETURNサービスの指定

- RETURN RECEIPT

- RETURN RECEIPT BY REQUEST

- RETURN TWOSAFE

- RETURN TWOSAFE BY REQUEST

- NO RETURN

- STORE属性の設定

- RETURNサービス・タイムアウト時間の設定

- RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理

- レプリケート表の列定義オプション

- 表定義チェックをRELAXEDに設定して表をレプリケートするアクティブ・スタンバイ・ペアの例

- 表定義チェックをRELAXEDに設定したクラシック・レプリケーション・スキームの例

- レプリケートの通信量の圧縮

- ポート割当て

- リモート・レプリケーション・エージェントからの応答の待機タイムアウトの設定

- トランザクション・ログ障害しきい値の設定

- 競合への対応としてのクラシック・レプリケーションの一時停止と再開

- ネットワークの構成

- ネットワーク帯域幅要件

- WAN環境でのレプリケーション

- ROUTE句を使用したネットワーク・インタフェースの構成

- ROUTE句を使用しない場合のネットワーク・インタフェースの構成

- UNIX上にあるデータベース・ホストのROUTE句を使用しない指定

- Windowsでのホスト名の解決

- TimesTenデーモンおよびサブデーモンのユーザー指定アドレス

- レプリケート・データベースのローカル・ホストの識別

5 キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの管理

- キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定

- アクティブ・データベースの障害からのリカバリ

- スタンバイ・データベースが使用可能な場合のリカバリ

- レプリケーションがRETURN RECEIPTまたは非同期の場合

- レプリケーションがRETURN TWOSAFEの場合

- 元のノードへのフェイルバック

- スタンバイ・データベースの障害からのリカバリ

- アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ

- アクティブ・データベースのリカバリ

- スタンバイ・データベースのリカバリ

- サブスクライバ・データベースの障害からのリカバリ

- アクティブ・データベースとスタンバイ・データベースの役割の入替え

- 二重のアクティブ・データベースの検出

6 キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理

- キャッシュ・グループが構成されたアクティブ・スタンバイ・ペア

- 読取り専用キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定

- AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定

- レプリケーションで使用されるユーザー名またはパスワードの変更

- アクティブ・データベースの障害からのリカバリ

- スタンバイ・データベースが使用可能な場合のリカバリ

- レプリケーションがRETURN RECEIPTまたは非同期の場合

- レプリケーションがRETURN TWOSAFEの場合

- 非同期のデータがキャッシュ・グループにある場合

- 元のノードへのフェイルバック

- スタンバイ・データベースの障害からのリカバリ

- アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ

- アクティブ・データベースをリカバリし、新しいスタンバイ・データベースを複製する

- スタンバイ・データベースをリカバリして新しいアクティブ・マスターにする

- バックアップからアクティブ・マスターをリストアする

- サブスクライバ・データベースの障害からのリカバリ

- アクティブ・データベースとスタンバイ・データベースの役割の入替え

- 二重のアクティブ・データベースの検出

- アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用

- アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用に関する要件

- 障害時リカバリ・サブスクライバのローリング・アウト

- 障害時リカバリ・サイトへの切替え

- 障害時リカバリ・サイトへの切替え後の新しいアクティブ・スタンバイ・ペアの作成

- 1つのデータベースへの切替え

- プライマリ・サイトでの元の構成への復元

7 アクティブ・スタンバイ・ペアの変更

- アクティブ・スタンバイ・ペアのDDLの変更

- アクティブ・スタンバイ・ペアのすべてのデータベースへのオブジェクト・レプリケーションの制御

- 自動的にレプリケートできるDDL文

- 既存のアクティブ・スタンバイ・ペアでの新しいPL/SQLオブジェクトの作成

- アクティブ・スタンバイ・ペアのDDLの変更に関する制限

- 例: アクティブ・スタンバイ・ペアのDDLの変更

- アクティブ・スタンバイ・ペアへのその他の変更

- 例: アクティブ・スタンバイ・ペアの変更

8 Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理

- Oracle ClusterwareがTimesTenを管理する方法の概要

- 必要な権限

- ハードウェアおよびソフトウェアの要件

- 制限されたコマンドおよびSQL文

- cluster.oracle.iniファイルによるOracle Clusterware管理の構成

- 基本的な可用性の構成

- 高度な可用性の構成

- アクティブ・スタンバイ・ペアへのキャッシュ・グループの挿入

- キャッシュ・グリッドへのアクティブ・スタンバイ・ペアの挿入

- アプリケーション・フェイルオーバーの実装

- 両方のマスター・ノードの永続的な障害からのリカバリ

- RepDDL属性の使用

- クラスタの作成および初期化

- Oracle Clusterwareのインストール

- 各ホストへのTimesTenのインストール

- TimesTenクラスタ情報の登録

- TimesTenクラスタ・エージェントの起動

- 1つのホストでのTimesTenデータベースの作成および移入

- その他のホストでのシステムDSNファイルの作成

- cluster.oracle.iniファイルの作成

- 仮想IPアドレスを管理するためのOracle Clusterwareリソースの作成

- アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成

- アクティブ・スタンバイ・ペアおよびアプリケーションの起動

- キャッシュ・グループのロード

- クラスタへの複数のアクティブ・スタンバイ・ペアの挿入

- 障害時リカバリ・サブスクライバとしてのOracle Databaseの構成

- Oracle Clusterwareによって管理されていない読取り専用サブスクライバの構成

- TimesTenキャッシュ・グリッドとOracle Clusterwareの併用

- キャッシュ・グリッド・メンバーのクラスタの作成および初期化

- アクティブ・スタンバイ・ペア・グリッド・メンバーの障害およびリカバリ

- グリッド内のアクティブ・スタンバイ・ペアのスキーマの変更

- キャッシュ・グループの追加

- キャッシュ・グループの削除

- 既存のキャッシュ・グループの変更

- 障害からのリカバリ

- Oracle Clusterwareが構成されている場合にTimesTenでリカバリを実行する方法

- アクティブ・データベースまたはそのホストで障害が発生した場合

- スタンバイ・データベースまたはそのホストで障害が発生した場合

- 読取り専用サブスクライバまたはそのホストで障害が発生した場合

- 両方のマスター・ノードで障害が発生した場合

- グリッドに接続していない場合の自動リカバリ

- アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードの手動リカバリ

- 高度な可用性の場合の手動リカバリ

- 基本的な可用性の場合の手動リカバリ

- データベースが破損した場合の同じマスター・ノードへの手動リカバリ

- RETURN TWOSAFEが構成されている場合の手動リカバリ

- 3つ以上のマスター・ホストで障害が発生した場合

- アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行

- Clusterwareによる管理

- Oracle Clusterwareソフトウェアのローリング・アップグレードの実行

- TimesTenのアップグレード

- クラスタでのホストの管理

- クラスタへのホストの追加

- クラスタからのホストの削除

- クラスタでのアクティブ・スタンバイ・ペアの管理

- クラスタへのアクティブ・スタンバイ・ペアの追加

- クラスタからのアクティブ・スタンバイ・ペアの削除

- アクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理

- Oracle Clusterwareによって管理される読取り専用サブスクライバの追加

- Oracle Clusterwareによって管理される読取り専用サブスクライバの削除

- Oracle Clusterwareによって管理されていない読取り専用サブスクライバの追加または削除

- Oracle Clusterwareによって管理されていない読取り専用サブスクライバの再作成

- スキーマの変更

- Oracle Clusterwareのスキーマ変更の簡素化

- サブスクライバおよびデータベース属性の管理

- マスター・データベースの役割の入替え

- 異なるホストへのデータベースの移動

- ホスト・メンテナンスまたはネットワーク・メンテナンスの実行

- クラスタ全体でのメンテナンスの実行

- Oracle Clusterware使用時のユーザー名やパスワードの変更

- TimesTenデータベースのRAMポリシーの管理

- クラスタ・ステータスの監視

- クラスタ・ステータスの取得

- メッセージ・ログ・ファイル

9 クラシック・レプリケーション・スキームの定義

- 高可用性システムの設計

- フェイルオーバーおよびリカバリの使用例の検討

- パフォーマンスとリカバリのトレードオフについての判断

- ワークロードの分散

- クラシック・レプリケーション・スキームの定義

- レプリケーション・スキームおよびレプリケート・オブジェクトの所有者

- データベース名

- クラシック・レプリケーション・スキームの表要件および制限

- 複数のマスターが関与するクラシック・レプリケーション・スキームの制限

- レプリケーション要素の定義

- DATASTORE要素の定義

- 表要素の定義

- クラシック・レプリケーション・スキーム内の外部キーで関連付けられている表のレプリケーション

- 順序のレプリケート

- レプリケートされたデータベースでのビューおよびマテリアライズド・ビュー

- 表要素に対するレプリケーション競合の確認

- DATASTORE要素に対する送信永続性の設定

- クラシック・レプリケーション・スキームでのRETURNサービスの使用

- クラシック・レプリケーション・スキームでのSTORE属性の設定

- クラシック・レプリケーション・スキームに対するネットワーク操作の構成

- クラシック・レプリケーション・スキームの構文の例

- 単一クラシック・サブスクライバ・スキーム

- RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム

- 異なるサブスクライバへの表のレプリケーション

- 伝播スキーム

- 双方向の分割ワークロード・スキーム

- 双方向の分散ワークロード・スキーム

- データベースへのクラシック・レプリケーション・スキームの適用

- スクリプトによるクラシック・レプリケーション・スキームの作成

10 クラシック・レプリケーション・スキームの変更

- クラシック・レプリケーション・スキームの変更

- 既存のクラシック・レプリケーション・スキームへの表または順序の追加

- 既存のクラシック・レプリケーション・スキームへのPL/SQLオブジェクトの追加

- 既存のクラシック・レプリケーション・スキームへのDATASTORE要素の追加

- DATASTORE要素追加時の表または順序の挿入

- DATASTORE要素追加時の表または順序の除外

- クラシック・レプリケーション・スキームからの表または順序の削除

- DATASTORE要素の一部としてレプリケートされる表または順序の削除

- TABLEまたはSEQUENCE要素としてレプリケートされる表または順序の削除

- サブスクライバ・データベースの作成とクラシック・レプリケーション・スキームへの追加

- クラシック・レプリケーション・スキームからのサブスクライバ・データベースの削除

- クラシック・レプリケーション・スキームでのTABLEまたはSEQUENCE要素名の変更

- クラシック・レプリケーション・スキームでのマスター・データベースの交換

- クラシック・レプリケーション・スキームでの競合検出の無効化

- クラシック・レプリケーション・スキームでのRETURN RECEIPTサービスの無効化

- クラシック・レプリケーション・スキームのポート番号の変更

- レプリケーション・ルートの変更

- ログ障害しきい値の変更

- クラシック・レプリケーション・スキームでレプリケートされた表の変更

- クラシック・レプリケーション・スキームでレプリケートされた表の切捨て

- クラシック・レプリケーション・スキームの削除

11 レプリケート・システムの設定

- レプリケーション環境の設定

- データベースの設定

- レプリケート・データベースの接続属性

- パラレル・レプリケーションの構成

- 自動パラレル・レプリケーションの構成

- コミット依存性を無効にした自動パラレル・レプリケーションの構成

- クラシック・レプリケーション・スキームに対するユーザー定義のパラレル・レプリケーションの構成

- レプリケート・データベースでのトランザクション・ログの管理

- ログ・バッファのフラッシュについて

- マスター・データベースでのトランザクション・ログの増大について

- ロギングの接続属性の設定

- サブスクライバへのマスター・データベースの複製

- 多数のサブスクライバの構成

- 異なるリリース間でのデータベースのレプリケート

- レプリケーション・エージェントの起動および停止

- サブスクライバのレプリケーション状態の設定

12 レプリケーションの監視

- レプリケーション・エージェントの状態の表示

- ttStatusを使用したレプリケーション・エージェントのステータスの取得

- ttAdmin -queryを使用したポリシー設定の確認

- ttDataStoreStatusを使用したレプリケーション・エージェントのステータスの取得

- マスター・データベース情報の表示

- ttRepAdminを使用したマスター・データベースに関する情報の表示

- レプリケーション表の問合せによるマスター・データベースに関する情報の取得

- サブスクライバ・データベース情報の表示

- ttRepAdminユーティリティによるサブスクライバ・ステータスの表示

- ttReplicationStatus組込みプロシージャによるサブスクライバ・ステータスの表示

- レプリケーション表の問合せによるサブスクライバに関する情報の表示

- サブスクライバ情報

- レプリケート・データベースの構成の表示

- ttIsql repschemesコマンドによる構成情報の表示

- ttRepAdminユーティリティによる構成情報の表示

- レプリケーション表の問合せによる構成情報の表示

- レプリケート・ログ・レコードの表示

- TTREP.REPPEERS表を使ったレプリケーションの監視

- ttLogHolds組込みプロシージャを使ったレプリケーションの監視

- ttRepAdminユーティリティを使ったレプリケーションの監視

- ttBookMark組込みプロシージャを使ったレプリケーションの監視

- ttRepAdminを使用したレプリケーション・ステータスの表示

- MAINスレッド・ステータス・フィールド

- レプリケーション・ピア・ステータス・フィールド

- TRANSMITTERスレッド・ステータス・フィールド

- RECEIVERスレッド・ステータス・フィールド

- RETURNサービス・トランザクションのステータスの確認

- RETURNサービスが無効にされているかどうかの確認

- RETURNサービスの最後に返されたステータスの確認

- レプリケーション・ログの未処理トランザクションの分析

13 レプリケーション競合の解消

- レプリケーション競合が発生する理由

- 更新競合および挿入競合

- 削除/更新競合

- タイムスタンプを使用した競合の解消

- ローカル更新のタイムスタンプ比較

- タイムスタンプ比較の構成

- レプリケート表へのタイムスタンプ列の挿入

- CHECK CONFLICTS句の構成

- システム・タイムスタンプ列のメンテナンスの有効化

- ユーザー・タイムスタンプ列のメンテナンスの有効化

- 競合のレポート

- テキスト・ファイルへの競合のレポート

- XMLファイルへの競合のレポート

- 一意競合のレポート

- 更新競合のレポート

- 削除/更新競合のレポート

- 競合のレポートの一時停止と再開

- 競合レポートのXML Document Type Definition(DTD)

- ドキュメントの本文

- 一意競合の要素

- 更新競合の要素

- 削除/更新競合の要素

14 レプリケーション・パフォーマンスの向上

- トランザクション・ログ・バッファ・サイズおよびCPUの調整

- レプリケートされる表を変更するときのパフォーマンスの考慮事項

- アクティブ・スタンバイ・ペアのレプリケーション・スループットの向上

- レプリケーションのトランスミッタとレシーバおよびXLAリーダーの制限

15 データベースのフェイルオーバーおよびリカバリの管理

- データベースのフェイルオーバーおよびリカバリの概要

- 一般的なフェイルオーバーおよびリカバリの手順

- サブスクライバの障害

- マスターの障害

- 障害が発生したマスター・データベースの自動キャッチアップ

- アクティブ・スタンバイ・ペアにマスター・キャッチアップが必要な場合

- 双方向の分散ワークロード・スキームの障害

- ネットワークの障害

- 順序に関連した障害

- 障害が発生したデータベースのリカバリ

- コマンドラインからの障害が発生したデータベースのリカバリ

- Cプログラムからの障害が発生したデータベースのリカバリ

- 非永続的データベースのリカバリ

- 障害リカバリ・スクリプトの作成

A Oracle ClusterwareのTimesTen構成属性

- 属性のリスト

- 必要な属性

- MasterHosts

- 場合によって必要な属性

- AppCheckCmd

- AppFailureInterval

- AppName

- AppRestartAttempts

- AppStartCmd

- AppStopCmd

- AppType

- AppUptimeThreshold

- CacheConnect

- GridPort

- MasterVIP

- RemoteSubscriberHosts

- RepBackupDir

- SubscriberHosts

- SubscriberVIP

- VIPInterface

- VIPNetMask

- オプションの属性

- AppFailoverDelay

- AppFailureThreshold

- AppScriptTimeout

- AutoRecover

- DatabaseFailoverDelay

- FailureThreshold

- MasterStoreAttribute

- RepBackupPeriod

- RepDDL

- RepFullBackupCycle

- ReturnServiceAttribute

- SubscriberStoreAttribute

- TimesTenScriptTimeout

索引

はじめに

Oracle TimesTen In-Memory Database (TimesTen)は、迅速な応答およびスループット用にメモリーが最適化されたリレーショナル・データベースです。実行時にはデータベース全体がメモリーに常駐し、リカバリおよび再起動できるようにディスク記憶域に保存されます。レプリケーション機能によって、高可用性が実現されます。TimesTenでは、OracleインタフェースであるPL/SQL、OCIおよびPro*C/C++に加えて、標準的なアプリケーション・インタフェースであるJDBC、ODBCおよびODP.NETがサポートされます。TimesTenは、単独で使用することもOracle Databaseのキャッシュとして使用することもできます。

トランザクションのリアルタイム・レプリケーションによって、インメモリー・データベースの高可用性が実現されます。このマニュアルでは、レプリケーションの構成、管理および使用方法について説明します。

対象読者

このマニュアルは、TimesTen間のレプリケーションを使用および管理するアプリケーション開発者およびシステム管理者を対象としています。このマニュアルを使用するには、データベース・システムの動作についての理解が必要です。また、SQL(Structured Query Language)およびODBC(Open DataBase Connectivity)またはJDBC(Java DataBase Connectivity)のいずれかに関する知識も必要です。

関連ドキュメント

TimesTenのドキュメントは、次のURLのOracle Technology Networkで入手できます。

http://www.oracle.com/technetwork/database/database-technologies/timesten/documentation/index.html

Oracle DatabaseのドキュメントもOracle Technology Networkで入手できます。これは、TimesTenでサポートされているが、説明されていないOracle Databaseの機能の場合に役立ちます。

http://www.oracle.com/pls/db112/homepage/

表記規則

TimesTenは複数のプラットフォームをサポートしています。このマニュアルに記述されている内容は、特に表記しないかぎり、サポートされるすべてのプラットフォームに適用されます。WindowsはサポートされているすべてのWindowsプラットフォームを表します。UNIXという用語は、サポートされるすべてのUNIXおよびLinuxプラットフォームを表します。TimesTenでサポートされている特定のバージョンのプラットフォームについては、『Oracle TimesTen In-Memory Databaseリリース・ノート』の「プラットフォーム」を参照してください。

注意:
TimesTenのドキュメントでは、「データ・ストア」と「データベース」という用語を同じ意味で使用しています。両方の用語は、TimesTenデータベースを指します。

このマニュアルの表記規則は、次のとおりです。

規則

意味

太字

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

イタリック体

イタリックは、ドキュメントのタイトル、強調またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

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

固定幅フォントのイタリック

固定幅フォントのイタリックは、置き換える必要があるコード例の変数です。次に例を示します。
Driver=install_dir/lib/libtten.sl

install_dirをご使用のTimesTenインストール・ディレクトリに置き換えます。

[ ]

大カッコは、カッコ内の項目を任意に選択することを表します。大カッコは、入力しないでください。

{ }

中カッコは、カッコ内の項目のうち、1つが必須であることを表します。中カッコは、入力しないでください。

|

縦線(パイプ)は、選択項目の引数を区切ります。

. . .

引数の後の水平の省略記号は、1行のコマンドラインで複数の引数を使用できることを表します。

%

%は、UNIXのシェル・プロンプトを表します。

#

#は、UNIXのルート・プロンプトを表します。

このマニュアルでは、次の変数を使用して、パス、ファイルおよびユーザー名を表します。

規則

意味

install_dir

TimesTenの現在のリリースがインストールされているディレクトリのパスです。

TTinstance

TimesTenのインストールで指定するインスタンス名です。インストール時に、英数字の一意のインスタンス名でTimesTenの各インストールを識別する必要があります。この名前はインストール・パスに表示されます。

bitsまたはbb

32または64の2桁の数字は、32-bitまたは64-bitのオペレーティング・システムを表します。

releaseまたはrr

リリース番号の最初の3つの部分(ドットが付く場合と付かない場合があります)。リリース番号の最初の3つの部分は、TimesTenのメジャー・リリースを表します。たとえば、1122または11.2.2はTimesTen 11gリリース2(11.2.2)を表します。

jdk_version

2桁の数字は、JDKのメジャー・リリースのバージョン番号を表します。たとえば、14はJDK 1.4を表し、5はJDK 5を表します。

DSN

データソースの名前です。

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

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 TimesTen In-Memory Databaseリリース11.2.2の新機能の概要を説明します。また、詳細情報へのリンクを示します。

リリース11.2.2.8.0の新機能

- 非同期レプリケーションを使用し、キャッシュ・グループを含まないアクティブなスタンバイ・ペアでは、自動パラレル・レプリケーションの依存性コミットを無効にできます。これによって、TimesTenがトランザクションの依存性を自動的に強制するが、サブスクライバ・データベース上でマスター・データベース上と同じ順序でコミットされるトランザクションは強制しない、複数のスレッドに対するパラレル・レプリケーションが可能になります。詳細は、「コミット依存性を無効にした自動パラレル・レプリケーションの構成」を参照してください。

リリース11.2.2.7.0の新機能

- DDLReplicationLevelおよびDDLReplicationAction接続属性は、DDL文によって作成または削除されるどのオブジェクトがアクティブ・スタンバイ・ペア・レプリケーション・スキームに含まれるデータベースに自動的にレプリケートされるかを制御します。このリリースでは、DDLReplicationLevel接続属性の新しいレベル3 (デフォルトではない)により、CREATE VIEWまたはDROP VIEW文、CREATE SEQUENCEまたはDROP SEQUENCE文、およびキャッシュ管理ユーザー名およびパスワードを設定するttCacheUidPwdSet組込みプロシージャの実行結果のレプリケーションが追加されています。DDLReplicationLevel=3で、DDLReplicationAction接続属性をINCLUDEに設定した場合、作成されたすべての新しい順序がレプリケーション・スキームに含まれます。詳細は、「アクティブ・スタンバイ・ペアのすべてのデータベースへのオブジェクト・レプリケーションの制御」を参照してください。

- Oracle Clusterwareを使用する場合は、ユーザー名やパスワードを変更した後に新しいttCWAdmin -reauthenticateコマンドを実行して、これらの新しいユーザー名とパスワードをOracle Clusterwareで有効にし、保存する必要があります。詳細は、「Oracle Clusterware使用時のユーザー名やパスワードの変更」を参照してください。

リリース11.2.2.5.0の新機能

- ALTER TABLEを使用して列を追加または削除する場合、余分な領域またはパーティションが追加される可能性があり、それによってレプリケーションのパフォーマンスが低下する可能性があります。relaxedレプリケーションを使用している場合は、ttMigrate -relaxedUpgradeを使用して余分な領域とパーティションを排除できます。詳細は、「レプリケート表の列定義オプション」を参照してください。

- ttXactLogユーティリティには、新規の-logAnalyzeコマンドがあり、レプリケーション・ログを分析して、アクティブからスタンバイ・マスターおよびサブスクライバにレプリケートされずに残っている量と、現在の構成でパラレル・レプリケーション用に適切に負荷を分散できるかどうかを測定できます。詳細は、「レプリケーション・ログの未処理トランザクションの分析」を参照してください。

リリース11.2.2.4.0の新機能

- データベースの複製が行われるローカルまたはリモートの特定のネットワーク・インタフェースを使用する場合に、ネットワーク・インタフェースの別名またはIPアドレスを指定できるようになりました。詳細は、「データベースの複製」を参照してください。

リリース11.2.2.2.0の新機能

- デフォルトでは、レプリケーションはシングル・スレッドで実行されます。ソース・データベースからターゲット・データベースに更新を送信し、その更新をターゲット・データベースで適用するための複数のスレッドを構成するパラレル・レプリケーションを構成することによって、パフォーマンスを向上させることができます。詳細は、「パラレル・レプリケーションの構成」を参照してください。

リリース11.2.2.1.0の新機能

- Oracle ClusterwareがTimesTenアクティブ・スタンバイ・ペアを管理している際の、TimesTenアプリケーションの動作に対する追加の制御が可能です。AppFailureInterval、AppRestartAttemptsおよびAppUptimeThresholdはClusterwareの新しい属性です。「アプリケーション・フェイルオーバーの実装」を参照してください。

リリース11.2.2.0.0の新機能

- 永続コミット動作が変更されました。「DURABLE COMMIT」を参照してください。

- LOB列はレプリケートできます。「アクティブ・スタンバイ・ペアの表要件」と「クラシック・レプリケーション・スキームの表要件および制限」を参照してください。

- TimesTenではインメモリー列圧縮が提供されます。ただし、圧縮された列を含む表はレプリケートできません。この制限については、「アクティブ・スタンバイ・ペアの表要件」と「クラシック・レプリケーション・スキームの表要件および制限」で説明されています。

1 TimesTenレプリケーションの概要

次の項では、TimesTenレプリケーションの概要を示します。

- レプリケーションとは

- レプリケーションの互換性の要件

- レプリケーション・エージェント

- データベース間の更新のコピー

- レプリケーション・スキームのタイプ

- キャッシュ・グループとレプリケーション

- 順序およびレプリケーション

- 外部キーとレプリケーション

- エージングおよびレプリケーション

レプリケーションとは

レプリケーションとは、複数のデータベースにデータのコピーを保持するプロセスのことです。レプリケーションは、パフォーマンスへの影響を最小限に抑えながら、アプリケーションでのデータの高可用性を実現することを目的としています。障害からのリカバリ以外に、レプリケーション・スキームでは、アプリケーションのワークロードを複数のデータベースに分散して最高のパフォーマンスを実現し、オンラインによるアップグレードおよびメンテナンスを簡素化することもできます。

レプリケーションとは、データをマスター・データベースからサブスクライバ・データベースにコピーするプロセスのことです。レプリケーションは、各データベースのレプリケーション・エージェントによって制御されます。マスター・データベースのレプリケーション・エージェントは、マスター・データベースのトランザクション・ログからレコードを読み取ります。レプリケートされた要素への変更をサブスクライバ・データベースのレプリケーション・エージェントに転送します。その後、サブスクライバ・データベースのレプリケーション・エージェントが、それらの更新をサブスクライバ・データベースに適用します。マスターからの更新転送時にサブスクライバのレプリケーション・エージェントが稼働していない場合、サブスクライバ・データベースで更新が適用されるようになるまで、マスターはその更新をトランザクション・ログに保持します。

最大限の高可用性を実現するには、アクティブ・スタンバイ・ペア構成をお薦めします。アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、データは読取り専用サブスクライバにコピーされる前に、アクティブ・データベースからスタンバイ・データベースにコピーされます。

データベース間で内容すべてとともにレプリケートされるエンティティは、レプリケーション要素と呼ばれます。TimesTenでは、レプリケーション要素として、データベース、キャッシュ・グループ、表および順序がサポートされています。また、TimesTenではXLAブックマークもレプリケートされます。アクティブ・スタンバイ・ペアは、キャッシュ・グループが構成されたデータベースでサポートされる唯一のレプリケーション・スキームです。

また、アクティブ・スタンバイ・ペア内で特定のDDL文を実行すると、一部の文がレプリケーション・スキーム内のその他のノードに対してレプリケートされます。詳細は、「アクティブ・スタンバイ・ペアのDDLの変更」を参照してください。

レプリケーションの互換性の要件

TimesTenレプリケーションは、同一のプラットフォーム間およびビットレベル間においてのみサポートされます。同一ホスト上のデータベース間でレプリケートすることもできますが、通常、レプリケーションは、別のホスト上のデータベースに更新をコピーするために使用します。こうすることで、ホスト障害によるデータの損失を防ぐことができます。

データベースには、同じDatabaseCharacterSetデータベース属性およびTypeModeデータベース属性を持つDSNが必要です。

レプリケーション・エージェント

データベース間でのレプリケーションは、レプリケーション・エージェントによって制御されます。各データベースは、次の情報によって識別されます。

- データベースに対するファイル・システムのパス名から導出されるデータベース名

- ホスト名

マスター・データベースのレプリケーション・エージェントは、トランザクション・ログからレコードを読み取り、レプリケート対象の要素への変更を検出した場合はそれらをサブスクライバ・データベースのレプリケーション・エージェントに転送します。その後、サブスクライバ・データベースのレプリケーション・エージェントが、それらの更新をサブスクライバ・データベースに適用します。マスター・エージェントは、更新転送時にサブスクライバ・エージェントが稼働していない場合、転送可能になるまでそれらの更新をトランザクション・ログに保持します。

レプリケーション・エージェントは、TCP/IPストリーム・ソケットを介して通信します。レプリケーション・エージェントは、TCP/IPアドレス、ホスト名およびその他の構成情報をレプリケーション表(『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』を参照)から取得します。

データベース間の更新のコピー

デフォルトでは、更新はデータベース間で非同期にコピーされます。非同期レプリケーションでは、最高のパフォーマンスが実現しますが、レプリケート対象の更新がサブスクライバ・データベースでコミットされたことを示す確認応答はアプリケーションに送信されません。マスター・データベースとサブスクライバ・データベース間でのレプリケート・データの一貫性をより高いレベルで保証する必要があるアプリケーションでは、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスのいずれかを有効にできます。

- RETURN RECEIPTサービスでは、サブスクライバが更新を受信したことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、アプリケーションをレプリケーション・メカニズムと緩やかに同期化します。

- RETURN TWOSAFEサービスでは、サブスクライバが更新を受信およびコミットしたことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、完全な同期化が行われます。

RETURN RECEIPTレプリケーションでは、同期性を低くすることによって、RETURN TWOSAFEレプリケーションよりパフォーマンスへの影響が小さくなっています。非同期、RETURN RECEIPTおよびRETURN TWOSAFEのレプリケーションの動作の詳細は、次の項を参照してください。

- デフォルトのレプリケーション

- RETURN RECEIPTレプリケーション

- RETURN TWOSAFEレプリケーション

デフォルトのレプリケーション

デフォルトのTimesTenレプリケーションを使用した場合、アプリケーションは、マスター・データベースを更新すると、サブスクライバがその更新を受信および適用するまで待機せずに処理を続行します。マスターおよびサブスクライバのデータベースには、サブスクライバが更新を正常に受信およびコミットしたことを確認するための内部メカニズムがあります。これらのメカニズムは、更新がサブスクライバで1回のみ適用されることを保証しますが、アプリケーションからは完全に独立しています。

デフォルトのTimesTenレプリケーションは、最高のパフォーマンスを実現しますが、アプリケーションは、サブスクライバ上のレプリケート対象の要素の受信プロセスと完全に切り離されます。

図1-1 基本的な非同期レプリケーション・サイクル

デフォルトのTimesTenレプリケーション・サイクルは次のとおりです。

1. アプリケーションは、ローカル・トランザクションをマスター・データベースにコミットし、他のトランザクションを続行できます。

2. コミット時に、TimesTenデーモンがトランザクションの更新レコードをトランザクション・ログ・バッファに書き込みます。

3. マスター・データベースのレプリケーション・エージェントは、コミット済トランザクションの更新レコードのバッチをログ・バッファからトランザクション・ログ・ファイルにフラッシュするようにデーモンに指示します。マスターで障害が発生して、チェックポイント・ファイルおよびトランザクション・ログ・ファイルからデータベースをリカバリする必要がある場合は、この手順によって、リカバリされたマスターにサブスクライバにレプリケートしたすべてのデータが含まれていることが保証されます。

4. マスター・レプリケーション・エージェントは、トランザクション更新レコードのバッチをサブスクライバ・レプリケーション・エージェントに転送し、サブスクライバ・レプリケーション・エージェントは、それらをサブスクライバ・データベースに適用します。更新レコードは、マスター・データベースのトランザクション・ロードに応じて256KB以下のバッチでディスクにフラッシュされ、サブスクライバに転送されます。バッチは、トランザクション・ログ・バッファにログ・データがなくなった場合、または現在のバッチがほぼ256KBの場合に作成されます。

5. サブスクライバ・レプリケーション・エージェントは、更新レコードのバッチを受信したことを示す確認応答をマスター・レプリケーション・エージェントに返信します。確認応答には、サブスクライバが最後にディスクにフラッシュしたレコードのバッチに関する情報が含まれます。これで、マスター・レプリケーション・エージェントは、すべてのサブスクライバが受信、適用およびディスクへのフラッシュを完了した更新レコードをトランザクション・ログからパージし、別の更新レコードのバッチを送信できるようになり、サブスクライバ・レプリケーション・エージェントは、非同期で手順6の処理に進みます。

6. サブスクライバ・レプリケーション・エージェントは、データベースを更新し、デーモンにトランザクション更新レコードをトランザクション・ログ・バッファに書き込むように指示します。

7. サブスクライバ・データベースのレプリケーション・エージェントは、個別のスレッドを使用して、トランザクション・ログ・ファイルに更新レコードをフラッシュするようにデーモンに指示します。

RETURN RECEIPTレプリケーション

RETURN RECEIPTサービスは、マスターでのコミット後、コミットされたトランザクションの更新をサブスクライバが受信するまでアプリケーションをブロックして、マスター・データベースとサブスクライバ・データベース間に特定のレベルの同期を提供します。

RETURN RECEIPTをリクエストするアプリケーションは、基本的な非同期の場合と同じ方法でマスター・データベースを更新します。ただし、レプリケート対象の要素を更新するトランザクションをアプリケーションでコミットすると、マスター・データベースは、そのトランザクションの更新がサブスクライバで受信されたことを示す確認応答を受信するまでアプリケーションをブロックします。

RETURN RECEIPTレプリケーションでは、パフォーマンスは低下しますが、マスター・データベースとサブスクライバ・データベース間でのより高いレベルのデータの整合性および一貫性がアプリケーションで保証されます。このアプリケーションでは、マスターで障害が発生した場合でも、マスターでコミットされたトランザクションがサブスクライバ・データベースに保持されることが高度なレベルで保証されます。

図1-2 RETURN RECEIPTレプリケーション

図1-2は、RETURN RECEIPTレプリケーション・サイクルが図1-1に示した基本的な非同期サイクルと同じであることを示していますが、マスター・レプリケーション・エージェントは、トランザクションをコミットした後でアプリケーション・スレッドをブロックし(手順1)、サブスクライバが更新バッチの受信を確認する(手順5)までそのスレッドを制御します。マスター・レプリケーション・エージェントは、サブスクライバからRETURN RECEIPTの確認応答を受信した時点で、そのスレッドの制御をアプリケーションに返し(手順6)、アプリケーションでトランザクションを続行できるようにします。

構成可能なタイムアウト時間(デフォルトは10秒)内にサブスクライバがトランザクションの受信を確認できない場合、マスター・レプリケーション・エージェントは、サブスクライバから更新の確認応答を受信しなかったことを示す警告を返し、スレッドの制御をアプリケーションに返します。その後、アプリケーションは、マスターに対して別のトランザクションをコミットできるようになり、マスターは以前と同様にサブスクライバへのレプリケーションを続行します。

RETURN RECEIPTトランザクションでタイムアウトが発生する原因は多数考えられます。最も可能性の高い原因は、ネットワークの問題、レプリケーション・エージェントの障害、またはマスター・レプリケーション・エージェントでトランザクション・ロードに対して大幅な遅延が発生しているため、タイムアウトが発生する前にRETURN RECEIPTトランザクションをレプリケートできない場合です。RETURN RECEIPTタイムアウトの管理方法については、「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。

RETURN RECEIPTレプリケーションの構成方法については、「RETURN RECEIPT」を参照してください。

RETURN TWOSAFEレプリケーション

RETURN TWOSAFEサービスは、マスターとサブスクライバ間の完全な同期レプリケーションを実現します。トランザクションがマスターでコミットされた後にサブスクライバに送信される前述のレプリケーション・モードとは異なり、TWOSAFEモードのトランザクションは、マスターでコミットされる前に、まずサブスクライバでコミットされます。

図1-3 RETURN TWOSAFEレプリケーション

RETURN TWOSAFEレプリケーションに構成された、マスターとサブスクライバ間でのレプリケーションの動作を次に説明します。

1. アプリケーションが、マスター・データベースでトランザクションをコミットします。

2. マスター・レプリケーション・エージェントが、トランザクション・レコードをログに書き込み、特殊なプリコミット・ログ・レコードをコミット・レコードの前に挿入します。このプリコミット・レコードは、サブスクライバでのコミットのステータスを示す確認応答をマスター・レプリケーションが受信するまで、ログ内でプレース・ホルダとして機能します。

注意:
RETURN TWOSAFEトランザクションの送信は非永続的です。このため、マスター・レプリケーション・エージェントは、サブスクライバに送信する前のログ・レコードをディスクにフラッシュすることはできません。この処理は、レプリケーションが非同期またはRETURN RECEIPTのレプリケーションに構成されている場合、デフォルトで行われます。

3. マスター・レプリケーション・エージェントが、更新レコードのバッチをサブスクライバに送信します。

4. サブスクライバ・レプリケーション・エージェントが、サブスクライバ・データベースでトランザクションをコミットします。

5. サブスクライバ・レプリケーション・エージェントが、サブスクライバでトランザクションがコミットされたかどうか、およびコミットが成功したかどうかについての通知とともに確認応答を返します。

6. サブスクライバでコミットが成功した場合、マスター・レプリケーション・エージェントが、マスター・データベースでトランザクションをコミットします。

7. マスター・レプリケーション・エージェントが、制御をアプリケーションに返します。
構成可能なタイムアウト時間(デフォルトは10秒)内にサブスクライバがトランザクションのコミットを確認できない場合、またはサブスクライバからの確認応答がコミットの失敗を示している場合、レプリケーション・エージェントは、マスター・データベースでトランザクションをコミットせずに制御をアプリケーションに返します。その後、アプリケーションは、無条件にコミットするか、コミットを再試行するかを決定できます。必要に応じて、マスター・レプリケーション・エージェントに指示してタイムアウトしたすべてのトランザクションをコミットするようにレプリケーション・スキームを構成できます。

RETURN TWOSAFEレプリケーションの構成方法については「RETURN TWOSAFE」を参照してください。

レプリケーション・スキームのタイプ

レプリケーション・スキームを作成して、マスターおよびサブスクライバのデータベースの特定の構成を定義できます。この項では、レプリケーション・スキームの作成時に、マスター・データベースとサブスクライバ・データベース間に定義可能な関係について説明します。

マスターとサブスクライバ間の関係を定義する場合、次のレプリケーション・スキームついて考慮する必要があります。

- アクティブ・スタンバイ・ペアおよび読取り専用サブスクライバ

- クラシック・レプリケーション

アクティブ・スタンバイ・ペアおよび読取り専用サブスクライバ

図1-4は、1つのアクティブ・マスター、1つのスタンバイ・マスター、そして4つの読取り専用サブスクライバ・データベースのアクティブ・スタンバイ・ペアのレプリケーション・スキームを示しています。

図1-4 アクティブ・スタンバイ・ペア

アクティブ・スタンバイ・ペアはデータベース全体をレプリケートすることも、表およびキャッシュ・グループなどの要素を選択することもできます。

アクティブ・スタンバイ・ペアでは、2つのデータベースがマスターとして定義されます。1つは、アクティブ・マスターで、もう1つはスタンバイ・マスターです。アクティブ・マスター・ディレクトリは、アプリケーションで直接更新されます。スタンバイ・マスターは、アプリケーションで更新することはできません。アクティブ・マスターからの更新を受信し、それらの変更を最大127の読取り専用サブスクライバ・データベースに伝播します。この構成では、スタンバイ・マスターがサブスクライバ・データベースより常に先行し、アクティブ・アスターで障害が発生した場合は、スタンバイ・マスターに即時にフェイルオーバーできます。

1つのマスター・データベースのみが、特定の時間にアクティブ・マスターとして機能できます。Oracle Clusterwareを使用して、アクティブ・スタンバイ・ペアのフェイルオーバーおよびリカバリを管理できます。第8章「Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理」を参照してください。また、フェイルオーバーおよびリカバリを手動で管理することもできます。第5章「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの管理」または第6章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

スタンバイ・マスターで障害が発生した場合は、アクティブ・マスターから読取り専用サブスクライバに変更を直接レプリケートします。スタンバイ・データベースは、リカバリ後、アクティブ・マスターに接続し、スタンバイ・マスターの停止またはリカバリ中にサブスクライバに送信された更新を受信します。アクティブ・マスターとスタンバイ・マスターで同期が取られている場合、スタンバイ・マスターは、サブスクライバへの変更の伝播を再開します。

アクティブ・スタンバイ・ペアの設定の詳細は、「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定」、「読取り専用キャッシュ・グループが工程されたアクティブ・スタンバイ・ペアの設定」または「AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定」を参照してください。

クラシック・レプリケーション

クラシック・レプリケーション・スキームでは、マスターとサブスクライバとの間の関係を設計できます。次の各項では、クラシック・レプリケーション・スキームについて説明します。

- データベース全体のレプリケーションまたは選択レプリケーション

- 単方向レプリケーションまたは双方向レプリケーション

- 直接レプリケーションまたは伝播

データベース全体のレプリケーションまたは選択レプリケーション

図1-5に、マスター・データベース全体をサブスクライバにレプリケートする全体レプリケーション・スキームを示します。

図1-5 マスター・データベース全体のレプリケート

また、マスター・データベースとサブスクライバ・データベースを構成して、マスター・データベース内の一部の要素を選択してサブスクライバにレプリケートできます。図1-6に、選択レプリケーションの例を示します。図の左側のマスター・データベースでは、同じ要素を選択して複数のサブスクライバにレプリケートしている一方で、右側のマスターでは、サブスクライバごとに異なる要素をレプリケートしています。

図1-6 複数サブスクライバへの選択要素のレプリケート

単方向レプリケーションまたは双方向レプリケーション

単方向レプリケーションでは、マスター・データベースから1つ以上のサブスクライバ・データベースに更新が送信されます。双方向レプリケーションでは、双方向に動作する2つのデータベースがあり、各データベースはマスターとサブスクライバの両方の機能を実行します。

双方向レプリケーションには、次の基本的な使用方法があります。

- 分割ワークロード構成

- 分散ワークロード

分割ワークロード構成

分割ワークロード構成では、各データベースが一部の要素に対してはマスターとして、他の要素に対してはサブスクライバとして機能します。

図1-7の例について考えてみます。ここでは、ChicagoのアカウントはデータベースAで処理され、New YorkのアカウントはデータベースBで処理されます。

図1-7 分割ワークロードの双方向レプリケーション

分散ワークロード

分散ワークロード・レプリケーション・スキームでは、ユーザーのアクセスは、すべての要素に対する更新を互いにレプリケートする複製アプリケーションとデータベースの組合せに分散されます。障害が発生した場合、その影響を受けたユーザーを任意のアプリケーションとデータベースの組合せに簡単に切り替えることができます。図1-8に、分散ワークロード構成を示します。ユーザーは、他方のデータベースでマスターおよびサブスクライバの両方として機能する、各データベースの複製アプリケーションにアクセスします。

図1-8 分散ワークロード構成

データベースが分散ワークロード構成でレプリケートされる場合、個々のユーザーが同じ行を同時に更新し、互いにその更新をレプリケートする可能性があります。アプリケーションでは、このような更新が発生しないこと、発生した場合でもその競合が許容可能であること、または第13章「レプリケーション競合の解消」で説明している競合解消メカニズムを利用して、競合を適切に解消できることが保証されている必要があります。

注意:
RETURN TWOSAFE戻りサービスを構成して分散ワークロードを使用しないでください。

直接レプリケーションまたは伝播

サブスクライバは、レプリケート対象の更新をマスターから受信して自身のサブスクライバに渡すプロパゲータとして機能するように定義できます。

プロパゲータは、より低い帯域幅のネットワーク接続(イントラネットでのサーバー間の接続など)でのレプリケーション・パフォーマンスの最適化に有効です。たとえば、図1-9に示す、マスターがイントラネット接続を介して4つのサブスクライバに直接レプリケートする直接レプリケーション構成について考えてみます。この方法でネットワーク接続を介して各サブスクライバにレプリケートすると、ネットワークの帯域幅が効率的に使用されません。

図1-9 マスターによるネットワーク上の複数サブスクライバへの直接レプリケート

最適なパフォーマンスを実現するために、図1-10に示す、マスターがネットワーク接続を介して1つのプロパゲータにレプリケートする構成について考えてみます。その後、このプロパゲータが、自身のローカル・エリア・ネットワーク上の各サブスクライバに更新を転送します。

図1-10 マスターによるネットワーク上の単一プロパゲータへのレプリケート

また、プロパゲータは、多数のサブスクライバにレプリケートする必要があるマスター・データベースを含む構成でレプリケーション・ロードを分散する場合にも有効です。たとえば、図1-11に示すとおり、マスターで、12のサブスクライバに直接レプリケートするより、3つのプロパゲータにレプリケートする方がより効率的です。

図1-11 プロパゲータを使用した多数のサブスクライバへのレプリケート

注意:
各プロパゲータはワン・ホップであるため、更新を1回のみ転送できます。プロパゲータを階層化して、プロパゲータ間で更新を転送することはできません。

キャッシュ・グループとレプリケーション

『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』で説明されているように、キャッシュ・グループとは、中央のOracle Databaseに保存されている表のグループが、ローカルのTimesTen Application-Tier Database Cache (TimesTen Cache)にキャッシュされたものです。この項では、TimesTenデータベース間でキャッシュ・グループをレプリケートする方法について説明します。アクティブ・スタンバイ・ペアを使用して、ASYNCHRONOUS WRITETHROUGHキャッシュ・グループまたは読取り専用キャッシュ・グループをレプリケートすることにより、高可用性を実現できます。

この項では、キャッシュ・グループをレプリケートする次の方法について説明します。

- AWTキャッシュ・グループのレプリケート

- Oracle Databaseに伝播するサブスクライバを持つAWTキャッシュ・グループのレプリケート

- 読取り専用キャッシュ・グループのレプリケート

キャッシュ・グループのレプリケーションの構成の詳細は、第6章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

AWTキャッシュ・グループのレプリケート

ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループを、オプションの読取り専用サブスクライバを持つアクティブ・スタンバイ・ペアの一部として構成すると、高可用性を実現し、アプリケーションのワークロードを分散できます。図1-12にこの構成を示します。

図1-12 アクティブ・スタンバイ・ペアによるAWTキャッシュ・グループのレプリケーション

アプリケーションによる更新は、アクティブ・データベースに対して行われ、スタンバイ・データベースにレプリケートされてから、そのスタンバイによってOracle Databaseに非同期で書き込まれます。同時に、これらの更新は、スタンバイから読取り専用サブスクライバにレプリケートされ、読取り専用サブスクライバによって、読取りアプリケーションのロードが分散されます。読取り専用サブスクライバにある表は、キャッシュ・グループにはありません。

スタンバイ・データベースが存在しない場合、アクティブ・データベースによって、アプリケーションによる更新の受入れおよびOracle Databaseと読取り専用サブスクライバへの非同期での更新の書込みの両方が実行されます。このような状況は、スタンバイが作成されていない場合、またはアクティブで障害が発生し、スタンバイが新しいアクティブになった場合に発生します。TimesTenでは、スタンバイが新しいアクティブになった場合、AWTキャッシュ・グループが再構成されます。

アクティブ・データベースのあるノードで障害が発生した場合、スタンバイ・ノードが新しいアクティブ・ノードになります。TimesTenは、アプリケーションから直接更新され、Oracle Databaseへ非同期に更新の伝播を続行できるように、自動的にAWTキャッシュ・グループを再構成します。

Oracle Databaseに伝播するサブスクライバを持つAWTキャッシュ・グループのレプリケート

アクティブ・スタンバイ・ペアのレプリケーション構成の一部として、障害時リカバリ用の特別な読取り専用サブスクライバをリモート・サイトに作成することによって、サイトの完全な障害からリカバリできます。図1-13にこの構成を示します。

図1-13 アクティブ・スタンバイ・ペアでの障害時リカバリ構成

スタンバイ・データベースは、読取り専用サブスクライバのキャッシュ・グループ表に更新を送信します。この特別なサブスクライバはリモートの障害時リカバリ・サイトに配置されており、(同様に障害時リカバリ・サイトに配置されている)2番目のOracle Databaseに更新を伝播できます。読取り専用サブスクライバおよびOracle Databaseを持つ障害時リカバリ・サイトを2つ以上設定できます。「アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用」を参照してください。

読取り専用キャッシュ・グループのレプリケート

読取り専用キャッシュ・グループのキャッシュ動作では、Oracle Database表でコミットされた更新が対応するTimesTenキャッシュ表に自動的にリフレッシュされます。図1-14に、アクティブ・スタンバイ・ペアによってレプリケートされた読取り専用キャッシュ・グループを示します。

図1-14 アクティブ・スタンバイ・ペアによる読取り専用キャッシュ・グループのレプリケーション

読取り専用キャッシュ・グループがアクティブ・スタンバイ・ペアによってレプリケートされると、アクティブ・データベースのキャッシュ・グループがOracle Databaseから自動リフレッシュされ、更新がスタンバイにレプリケートされます(スタンバイのキャッシュ・グループにもAUTOREFRESHが構成されていますが、状態はPAUSEDになっています)。アクティブに障害が発生した場合に備えて、AUTOREFRESH STATEをONに設定しておくと、スタンバイは、障害が発生したマスター・データベースの役割を引き継ぐ際に自動リフレッシュされるように、自動的に再構成されます。また、TimesTenでは、Oracle Databaseからアクティブ・データベースに自動リフレッシュされた更新が、スタンバイにレプリケートされたかどうかも追跡されます。これによって、アクティブで障害が発生した場合でも、自動リフレッシュ・プロセスを適切な時点から継続できるようになり、自動リフレッシュされた更新が失われなくなります。この構成には、読取り専用サブスクライバ・データベースを含めることもできます。これによって、読取りワークロードを多数のデータベースに分散させることができます。スタンバイ・データベースのキャッシュ・グループは、サブスクライバの通常の(キャッシュされていない)表にレプリケートします。

順序およびレプリケーション

一部のレプリケーション構成では、複数のデータベース間で順序の同期を保持する必要があります。たとえば、順序を使用して各行の主キー値を指定するレプリケート表が含まれているマスター・データベースが存在するとします。サブスクライバ・データベースは、マスター・データベースのホット・バックアップとして使用されています。順序の現在値に対する更新がレプリケートされない場合、マスターで障害が発生した後にサブスクライバで新しい行を挿入すると、最初にマスターで挿入した行と競合する可能性があります。

TimesTenレプリケーションでは、いずれのデータベースで挿入した行もこの構成で競合しないようにするために、順序の値の増分をサブスクライバ・データベースにレプリケートできます。順序をレプリケートするレプリケーション・スキームの作成方法の詳細は、「順序のレプリケート」を参照してください。

外部キーとレプリケーション

外部キーで互いに関連付けられている表は、すべての表をレプリケートするか一部の表のみをレプリケートするかを選択できます。ただし、関連付けられている表のレプリケート方法は、レプリケーション・スキームの種類によって異なります。詳細は次の各項を参照してください。

- 「アクティブ・スタンバイ・ペア内の外部キーで関連付けられている表のレプリケーション」

- 「クラシック・レプリケーション・スキーム内の外部キーで関連付けられている表のレプリケーション」

エージングおよびレプリケーション

表またはキャッシュ・グループに最低使用頻度(LRU)または時間ベースのエージングが構成されている場合は、レプリケーションの実行に次のルールが適用されます。

- レプリケートされる表およびキャッシュ・グループのエージング構成は、すべてのピア・データベースで同じにする必要があります。

- レプリケーション・スキームがアクティブ・スタンバイ・ペアの場合、エージングはアクティブ・データベースでのみ実行されます。エージングによる削除は、スタンバイ・データベースにレプリケートされます。アクティブ・データベースおよびスタンバイ・データベースの両方で、エージング構成がONに設定されている必要があります。TimesTenでは、データベースの役割がアクティブかスタンバイかに基づいて、実際にエージングを実行しているデータベースが自動的に判別されます。

- レプリケーション・スキームがアクティブ・スタンバイ・ペアではない場合、エージングは各データベースで個々に実行されます。エージングによって実行された削除は、他のデータベースにレプリケートされません。

- アクティブ・スタンバイ・ペアによってレプリケートされたデータベースにASYNCHRONOUS WRITETHROUGHキャッシュ・グループがある場合、エージングによる削除処理はOracle Databaseには伝播されません。

2 スタート・ガイド

次の項では、サンプル・レプリケーション・スキームを構成および起動する方法を示します。

- 1つのサブスクライバを持つアクティブ・スタンバイ・ペアの構成

- 1つのマスターと1つのサブスクライバを持つレプリケーション・スキームの構成

注意:
この章の手順を実行するには、ADMIN権限が必要です。

1つのサブスクライバを持つアクティブ・スタンバイ・ペアの構成

この項では、1つのサブスクライバを持つアクティブ・スタンバイ・ペアの作成方法について説明します。アクティブ・データベースはmaster1です。スタンバイ・データベースはmaster2です。サブスクライバ・データベースはsubscriber1です。わかりやすくするために、すべてのデータベースは同じコンピュータserver1に存在することとします。

図2-1にこの構成を示します。

図2-1 1つのサブスクライバを持つアクティブ・スタンバイ・ペア

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

- 手順1: マスター・データベースおよびサブスクライバ・データベースのDSNの作成

- 手順2: いずれかのマスター・データベースでの表の作成

- 手順3: アクティブ・スタンバイ・ペアの定義

- 手順4: マスター・データベースでのレプリケーション・エージェントの起動

- 手順5: マスター・データベースのACTIVE状態への設定

- 手順6: アクティブ・データベースでのユーザーの作成

- 手順7: スタンバイ・データベースへのアクティブ・データベースの複製

- 手順8: スタンバイ・データベースでのレプリケーション・エージェントの起動

- 手順9: サブスクライバへのスタンバイ・データベースの複製

- 手順10: サブスクライバでのレプリケーション・エージェントの起動

- 手順11: アクティブ・データベースにある表へのデータの挿入

- 手順12: アクティブ・スタンバイ・ペアおよび表の削除

手順1: マスター・データベースおよびサブスクライバ・データベースのDSNの作成

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明に従って、master1、master2およびsubscriber1というDSNを作成します。

UNIXシステムの場合は、テキスト・エディタを使用して次のodbc.iniファイルを作成します。

[master1]
DRIVER=install_dir/lib/libtten.so
DataStore=/tmp/master1
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

[master2]
DRIVER=install_dir/lib/libtten.so
DataStore=/tmp/master2
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

[subscriber1]
DRIVER=install_dir/lib/libtten.so
DataStore=/tmp/subscriber1
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

Windowsの場合は、ODBCアドミニストレータを使用して同じ接続属性を設定します。他のすべての設定には、デフォルト値を使用します。

手順2: いずれかのマスター・データベースでの表の作成

ttIsqlユーティリティを使用して、master1データベースに接続します。

% ttIsql master1

Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.

connect "DSN=master1";
Connection successful: DSN=master1;UID=timesten;DataStore=/tmp/master1;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;TypeMode=0;
(Default setting AutoCommit=1)
Command>

employees表を作成します。

Command> CREATE TABLE employees
>   ( employee_id   NUMBER(6) PRIMARY KEY,
>    first_name     VARCHAR2(20),
>    last_name      VARCHAR2(25) NOT NULL,
>    email          VARCHAR2(25) NOT NULL UNIQUE,
>    phone_number   VARCHAR2(20),
>    hire_date      DATE NOT NULL,
>    job_id         VARCHAR2(10) NOT NULL,
>    salary         NUMBER(8,2),
>    commission_pct NUMBER(2,2),
>    manager_id     NUMBER(6),
>    department_id  NUMBER(4)
> ) ;

手順3: アクティブ・スタンバイ・ペアの定義

master1で、アクティブ・スタンバイ・ペアを定義します。

Command> CREATE ACTIVE STANDBY PAIR master1, master2
> SUBSCRIBER subscriber1;

アクティブ・スタンバイ・ペアの定義の詳細は、第3章「アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義」を参照してください。

手順4: マスター・データベースでのレプリケーション・エージェントの起動

master1で、レプリケーション・エージェントを起動します。

Command> CALL ttRepStart;

手順5: マスター・データベースのACTIVE状態への設定

アクティブ・スタンバイ・ペアの新しいデータベースの状態は、アクティブ・データベースが設定されるまでIDLE状態になります。

ttRepStateSet組込みプロシージャを使用して、master1をアクティブ・データベースとして指定します。

Command> CALL ttRepStateSet('ACTIVE');

master1の状態を確認します。

Command> CALL ttRepStateGet;
< ACTIVE, NO GRID >
1 row found.

手順6: アクティブ・データベースでのユーザーの作成

ttuserというパスワードを持つユーザーttuserを作成し、ttuserにADMIN権限を付与します。ADMIN権限を持つユーザーの作成は、次の手順のアクセス制御で必要です。

Command> CREATE USER ttuser IDENTIFIED BY ttuser;
User created.
Command> GRANT ADMIN TO ttuser;

手順7: スタンバイ・データベースへのアクティブ・データベースの複製

ttIsqlを終了し、ttuser (ADMIN権限を持つ、作成されたユーザー)としてttRepAdminユーティリティを-duplicateオプションとともに使用して、アクティブ・データベースをスタンバイ・データベースに複製します。2つの異なるホストを使用している場合は、ターゲット・ホストからttRepAdminコマンドを入力してください。

% ttRepAdmin -duplicate -from master1 -host server1 -uid ttuser -pwd ttuser
master2

手順8: スタンバイ・データベースでのレプリケーション・エージェントの起動

ttIsqlを使用してmaster2データベースに接続し、レプリケーション・エージェントを起動します。

% ttIsql master2
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.

connect "DSN=master2";
Connection successful: DSN=master2;UID=timesten;DataStore=/tmp/master2;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;TypeMode=0;
(Default setting AutoCommit=1)

Command> CALL ttRepStart;

スタンバイ・データベースのレプリケーション・エージェントを起動すると、状態が自動的にSTANDBYに設定されます。master2の状態を確認します。

Command> CALL ttRepStateGet;
< STANDBY, NO GRID >
1 row found.

手順9: サブスクライバへのスタンバイ・データベースの複製

ttIsqlを終了し、ttuser (ADMIN権限を持つ、作成されたユーザー)としてttRepAdminユーティリティを使用し、スタンバイ・データベースをサブスクライバ・データベースに複製します。

% ttRepAdmin -duplicate -from master2 -host server1 -uid ttuser -pwd ttuser
subscriber1

手順10: サブスクライバでのレプリケーション・エージェントの起動

ttIsqlを使用してsubscriber1に接続し、レプリケーション・エージェントを起動します。subscriber1の状態を確認します。サブスクライバ・データベースのレプリケーション・エージェントを開始すると、自動的に、サブスクライバ・データベースの状態が「IDLE」に設定されます。すべてのサブスクライバ・データベースの状態が、「IDLE」に設定されます。

% ttIsql subscriber1

Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.

connect "DSN=subscriber1";
Connection successful: DSN=subscriber1;UID=timesten;DataStore=/stmp/subscriber1;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;TypeMode=0;
(Default setting AutoCommit=1)

Command> CALL ttRepStart;

Command> call ttRepStateGet;
< IDLE, NO GRID >
1 row found.

手順11: アクティブ・データベースにある表へのデータの挿入

ttIsqlユーティリティを使用して、master1データベースに接続します。

% ttIsql master1

Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.

connect "DSN=master1";
Connection successful: DSN=master1;UID=timesten;DataStore=/tmp/master1;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;TypeMode=0;
(Default setting AutoCommit=1)
Command>

master1のemployees表に行を1つ挿入します。

Command> INSERT INTO employees VALUES
> ( 202,
>   'Pat',
>   'Fay',
>   'PFAY',
>   '603-123-7777',
>   TO_DATE('17-AUG-1997', 'dd-MON-yyyy'),
>   'MK_REP',
>   6000,
>   NULL,
>   201,
>   20
);
1 row inserted.
Command> SELECT * FROM employees;
< 202, Pat, Fay, PFAY, 603-123-7777, 1997-08-17 00:00:00, MK_REP,
6000, <NULL>, 201, 20 >
1 row found.

master2およびsubscriber1に挿入がレプリケートされたことを確認します。ttIsqlを使用して、master2に接続します。

% ttIsql master2
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.

connect "DSN=master2";
Connection successful: DSN=master2;UID=timesten;DataStore=/tmp/master2;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;TypeMode=0;
(Default setting AutoCommit=1)

データがmaster2にレプリケートされていることを確認します。

Command> SELECT * FROM employees;
< 202, Pat, Fay, PFAY, 603-123-7777, 1997-08-17 00:00:00, MK_REP,
6000, <NULL>, 201, 20 >
1 row found.

同じ手順をsubscriber1で実行して、データがサブスクライバにレプリケートされていることを確認します。

手順12: アクティブ・スタンバイ・ペアおよび表の削除

ttIsqlを使用して各データベースに接続し、各データベースでレプリケーション・エージェントを終了します。

Command> CALL ttRepStop;

各データベースでアクティブ・スタンバイ・ペアを削除します。その後、アクティブ・スタンバイ・ペアを削除した任意のデータベースにあるemployees表を削除できます。

Command> DROP ACTIVE STANDBY PAIR;

Command> DROP TABLE employees;

1つのマスターと1つのサブスクライバを持つレプリケーション・スキームの構成

この項では、マスター・データベース(masterds)内の単一表の内容をサブスクライバ・データベース(subscriberds)の表にレプリケートするレプリケーション・スキームの構成方法について説明します。わかりやすくするために、両方のデータベースは同じコンピュータに存在することとします。

図2-2 単純なレプリケーション・スキーム

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

- 手順1: マスターおよびサブスクライバのDSNの作成

- 手順2: マスター・データベースでの表およびレプリケーション・スキームの作成

- 手順3: サブスクライバ・データベースでの表およびレプリケーション・スキームの作成

- 手順4: 各データベースでのレプリケーション・エージェントの起動

- 手順5: マスター・データベースにある表へのデータの挿入

- 手順6: レプリケーション・スキームおよび表の削除

手順1: マスターおよびサブスクライバのDSNの作成

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明に従って、masterdsおよびsubscriberdsというDSNを作成します。

UNIXシステムの場合は、テキスト・エディタを使用して各データベースで次のodbc.iniファイルを作成します。

[masterds]
DataStore=/tmp/masterds
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

[subscriberds]
DataStore=/tmp/subscriberds
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

Windowsの場合は、ODBCアドミニストレータを使用して同じ接続属性を設定します。他のすべての設定には、デフォルト値を使用します。

手順2: マスター・データベースでの表およびレプリケーション・スキームの作成

ttIsqlユーティリティを使用して、masterdsに接続します。

% ttIsql masterds
Copyright (c) 1996-2011, Oracle.  All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.

connect "DSN=masterds";
Connection successful: DSN=masterds;UID=timesten;
DataStore=/tmp/masterds;DatabaseCharacterSet=AL32UTF8;
ConnectionCharacterSet=AL32UTF8;TypeMode=0;
(Default setting AutoCommit=1)
Command>

employees表を作成します。

Command> CREATE TABLE employees
>   ( employee_id   NUMBER(6) PRIMARY KEY,
>    first_name     VARCHAR2(20),
>    last_name      VARCHAR2(25) NOT NULL,
>    email          VARCHAR2(25) NOT NULL UNIQUE,
>    phone_number   VARCHAR2(20),
>    hire_date      DATE NOT NULL,
>    job_id         VARCHAR2(10) NOT NULL,
>    salary         NUMBER(8,2),
>    commission_pct NUMBER(2,2),
>    manager_id     NUMBER(6),
>    department_id  NUMBER(4)
> ) ;

employees表をmasterdsからsubscriberdsにレプリケートする、repschemeというレプリケーション・スキームを作成します。

Command> CREATE REPLICATION repscheme
> ELEMENT e TABLE employees
> MASTER masterds
> SUBSCRIBER subscriberds;

手順3: サブスクライバ・データベースでの表およびレプリケーション・スキームの作成

subscriberdsに接続し、手順2と同じ手順に従って、同じ表とレプリケーション・スキームを作成します。

手順4: 各データベースでのレプリケーション・エージェントの起動

masterdsおよびsubscriberdsでレプリケーション・エージェントを起動します。

Command> call ttRepStart;

ttIsqlを終了します。ttStatusユーティリティを使用して、両方のデータベースのレプリケーション・エージェントが稼働していることを確認します。

% ttStatus
TimesTen status report as of Thu Aug 11 17:05:23 2011

Daemon pid 18373 port 4134 instance ttuser
TimesTen server pid 18381 started on port 4136
------------------------------------------------------------------------
Data store /tmp/masterds
There are 16 connections to the data store
Shared Memory KEY 0x0201ab43 ID 5242889
PL/SQL Memory KEY 0x0301ab43 ID 5275658 Address 0x10000000
Type            PID     Context     Connection Name              ConnID
Process         20564   0x081338c0  masterds                          1
Replication     20676   0x08996738  LOGFORCE                          5
Replication     20676   0x089b69a0  REPHOLD                           2
Replication     20676   0x08a11a58  FAILOVER                          3
Replication     20676   0x08a7cd70  REPLISTENER                       4
Replication     20676   0x08ad7e28  TRANSMITTER                       6
Subdaemon       18379   0x080a11f0  Manager                        2032
Subdaemon       18379   0x080fe258  Rollback                       2033
Subdaemon       18379   0x081cb818  Checkpoint                     2036
Subdaemon       18379   0x081e6940  Log Marker                     2035
Subdaemon       18379   0x08261e70  Deadlock Detector              2038
Subdaemon       18379   0xae100470  AsyncMV                        2040
Subdaemon       18379   0xae11b508  HistGC                         2041
Subdaemon       18379   0xae300470  Aging                          2039
Subdaemon       18379   0xae500470  Flusher                        2034
Subdaemon       18379   0xae55b738  Monitor                        2037
Replication policy  : Manual
Replication agent is running.
Cache Agent policy  : Manual
PL/SQL enabled.
------------------------------------------------------------------------
Data store /tmp/subscriberds
There are 16 connections to the data store
Shared Memory KEY 0x0201ab41 ID 5177351
PL/SQL Memory KEY 0x0301ab41 ID 5210120 Address 0x10000000
Type            PID     Context     Connection Name              ConnID
Process         20594   0x081338f8  subscriberds                      1
Replication     20691   0x0893c550  LOGFORCE                          5
Replication     20691   0x089b6978  REPHOLD                           2
Replication     20691   0x08a11a30  FAILOVER                          3
Replication     20691   0x08a6cae8  REPLISTENER                       4
Replication     20691   0x08ad7ba8  RECEIVER                          6
Subdaemon       18376   0x080b1450  Manager                        2032
Subdaemon       18376   0x0810e4a8  Rollback                       2033
Subdaemon       18376   0x081cb8b0  Flusher                        2034
Subdaemon       18376   0x08246de0  Monitor                        2035
Subdaemon       18376   0x082a20a8  Deadlock Detector              2036
Subdaemon       18376   0x082fd370  Checkpoint                     2037
Subdaemon       18376   0x08358638  Aging                          2038
Subdaemon       18376   0x083b3900  Log Marker                     2040
Subdaemon       18376   0x083ce998  AsyncMV                        2039
Subdaemon       18376   0x08469e90  HistGC                         2041
Replication policy  : Manual
Replication agent is running.
Cache Agent policy  : Manual
PL/SQL enabled.

手順5: マスター・データベースにある表へのデータの挿入

ttIsqlを使用して、マスター・データベースに接続し、employees表にいくつかの行を挿入します。

% ttIsql masterds
Command> INSERT INTO employees VALUES
> ( 202,
>   'Pat',
>   'Fay',
>   'PFAY',
>   '603-123-7777',
>   TO_DATE('17-AUG-1997', 'dd-MON-yyyy'),
>   'MK_REP',
>   6000,
>   NULL,
>   201,
>   20
);
1 row inserted.

サブスクライバ用に、2番目のコマンド・プロンプト・ウィンドウを開きます。サブスクライバ・データベースに接続し、employees表の内容を確認します。

% ttIsql subscriberds
Command> SELECT * FROM employees;
< 202, Pat, Fay, PFAY, 603-123-7777, 1997-08-17 00:00:00, MK_REP,
6000, <NULL>, 201, 20 >
1 row found.

図2-3は、masterdsに挿入された行がsubscriberdsにレプリケートされたことを示します。

図2-3 サブスクライバ・データベースへの変更のレプリケート

手順6: レプリケーション・スキームおよび表の削除

レプリケーション・テストを完了した後、masterdsおよびsubscriberdsの両方でレプリケーション・エージェントを停止します。

Command> CALL ttRepStop;

マスター・データベースおよびサブスクライバ・データベースからemployees表およびrepschemeレプリケーション・スキームを削除するには、両方のデータベースで次の文を入力します。

Command> DROP REPLICATION repscheme;
Command> DROP TABLE employees;

3 アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義

次の項では、高可用性システムの設計およびレプリケーション・スキームの定義方法を示します。

- マスター・データベースの状態の概要

- データベースの複製

- アクティブ・スタンバイ・ペアの制限

- データベースのDSNの定義

- アクティブ・スタンバイ・ペアの表要件

- アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義

- アクティブ・スタンバイ・ペア内のデータベースの識別

- アクティブ・スタンバイ・ペアに対するRETURNサービスの使用

- アクティブ・スタンバイ・ペアに対するSTORE属性の設定

- アクティブ・スタンバイ・ペアに対するネットワーク操作の構成

- アクティブ・スタンバイ・ペアの自動クライアント・フェイルオーバーの使用

- レプリケーションに対するデータベース・オブジェクトの挿入または除外

- アクティブ・スタンバイ・ペア内の外部キーで関連付けられている表のレプリケーション

- アクティブ・スタンバイ・ペア内のマテリアライズド・ビュー

- アクティブ・スタンバイ・ペア内の順序のレプリケート

レプリケーションに必要な帯域幅の量を減らす方法については、「レプリケートの通信量の圧縮」を参照してください。

マスター・データベースの状態の概要

この項では、マスター・データベースの可能性のある状態の概要を示します。これらの状態は、章の後半で説明するタスクで参照されています。

マスター・データベースは、次のいずれかの状態になります。

- ACTIVE: この状態のデータベースが、アクティブ・データベースです。アプリケーションで、そのレプリケーション表を更新できます。

- STANDBY: この状態のデータベースが、スタンバイ・データベースです。アプリケーションでは、スタンバイ・データベースのレプリケートされていない表のみを更新できます。レプリケートされていない表とは、CREATE ACTIVE STANDBY PAIR文のEXCLUDE TABLEまたはEXCLUDE CACHE GROUP句を使用してレプリケーション・スキームから除外された表のことです。

- FAILED: この状態のデータベースが、障害が発生したマスター・データベースです。更新は、このデータ・ストアにはレプリケートされません。

- IDLE: この状態のデータベースでは、アクティブ・スタンバイ・ペア内での役割が割り当てられていません。更新することはできません。すべてのデータベースがIDLE状態になります。

- RECOVERING: 前述の障害が発生したマスター・データベースは、アクティブ・データベースと更新を同期している場合、RECOVERING状態になります。

ttRepStateGet組込みプロシージャを使用して、マスター・データベースの状態を検出できます。

データベースの複製

レプリケーション・スキームの設定またはリカバリの管理における共通のタスクは、データベースの複製です。ttRepAdminユーティリティの-duplicateオプションまたはttRepDuplicateEx C関数を使用して、データベースを複製します。

データベースを複製する場合は、次の条件を満たす必要があります。

- インスタンス管理者が複製操作を実行します。

- インスタンス管理者のユーザー名は、複製に含まれる両方のインスタンスで同じである必要があります。

- ソース・データベースで、ADMIN権限があるユーザーのユーザー名とパスワードを入力する必要があります。

- ターゲットDSNにクライアント属性およびサーバー属性を含めることはできません。

ソース・データベースで、次のように入力してユーザーを作成し、そのユーザーにADMIN権限を付与します。

Command> CREATE USER ttuser IDENTIFIED BY ttuser;
User created.

Command> GRANT ADMIN TO ttuser;

インスタンス管理者のユーザー名がtimestenであるとします。ターゲット・ホストでtimestenとしてログインし、次のようにhost1のデータベースdsn1をdsn2に複製します。

ttRepAdmin -duplicate -from dsn1 -host host1 dsn2

Enter internal UID at the remote datastore with ADMIN privileges: ttuser
Enter password of the internal Uid at the remote datastore:

リモート・データベースの内部ユーザーのパスワードを入力するよう要求されたら、ttuserと入力します。

データベースの複製が行われる特定のローカルまたはリモートのネットワーク・インタフェースを使用する場合は、オプションでネットワーク・インタフェースの別名またはIPアドレスを指定できます。ソース・ホストとターゲット・ホストのローカルおよびリモートのネットワーク・インタフェースを指定するには、ttRepAdmin -duplicateの-localIPオプションと-remoteIPオプションを使用します。一方または両方のネットワーク・インタフェースが指定されていない場合は、TimesTenによって選択されます。

キャッシュ・グループが含まれるアクティブ・データベースを複製している場合は、-keepCGオプションを使用します。また、-cacheUidおよび-cachePwdオプションを使用して、キャッシュ管理ユーザー名およびパスワードを指定する必要もあります。キャッシュ管理ユーザー・パスワードを指定しない場合、ttRepAdminによってパスワードが要求されます。キャッシュ管理ユーザー名がorauserで、パスワードがorapwdである場合、host1のデータベースdsn1を複製します。

ttRepAdmin -duplicate -from dsn1 -host host1 -keepCG
-connStr "DSN=dsn2;UID=;PWD="

Enter internal UID at the remote datastore with ADMIN privileges: ttuser
Enter password of the internal Uid at the remote datastore:

パスワードを求めるプロンプトが表示されたら、ttuserと入力します。次に、ttRepAdminユーティリティにより、キャッシュ管理ユーザーとパスワードを求めるプロンプトが表示されます。

Enter cache administrator UID: orauser
Enter cache administrator password:

キャッシュ管理パスワードを要求されたら、orapwdと入力します。

dsn2のUIDおよびPWDは、インスタンス管理者である現在のOSユーザーとして接続が確立されるように、接続文字列でNULL値として指定されます。インスタンス管理者のみがttRepAdmin -duplicateを実行できます。dsn2がPWDではなくPWDCryptで構成されている場合は、接続文字列がDSN=dsn2;UID=;PWDCrypt=となります。

キャッシュ・グループが構成されたスタンバイ・データベースを読取り専用サブスクライバに複製する場合は、-nokeepCGオプションを使用します。この例では、dsn2がスタンバイ・データベース、sub1が読取り専用サブスクライバです。

ttRepAdmin -duplicate -from dsn2 -host host2 -nokeepCG
-connStr "DSN=sub1;UID=;PWD="

ttRepAdminユーティリティによって-uidおよび-pwdの値を入力するよう要求されます。

AWTまたは増分自動リフレッシュ・キャッシュ・グループを使ってレプリケーション・スキームの複製を実行中に、Oracle Databaseにアクセスできない場合(Oracle Databaseが停止しているか、接続できない場合)、ttRepAdmin -duplicateコマンドはAWTまたは増分自動リフレッシュ・キャッシュ・グループが複製された後に、Oracle Database上の(AWTおよび自動リフレッシュ・キャッシュ・グループを管理するためにキャッシュが使用する)メタデータを更新することができません。この場合、次のいずれかのオプションを使用して複製を実行します。

- すべてのAWTまたは増分自動リフレッシュ・キャッシュ・グループがアクティブ・スタンバイ・ペアのレプリケーション・スキームに含まれている状況で、障害が発生したアクティブ・マスターまたはスタンバイ・マスターのいずれかをリカバリするためにttRepAdmin -duplicateを使用している場合は、-keepCG -recoveringNodeオプションを使用します。このオプションを使用する場合は、複製処理の間に発生する変更が追跡されるので、完全な自動リフレッシュを開始する必要がなくなります。

- これを使用しない場合は、-keepCG -deferCacheUpdateオプションを使用します。このオプションでは完全な自動リフレッシュが開始されることがあります。

-keepCG -recoveringNodeオプションまたは-keepCG -deferCacheUpdateオプションを使用して複製処理を完了した後に、複製処理は正常に終了したがOracle Databaseメタデータへの更新は、キャッシュ・エージェントとレプリケーション・エージェントが起動するまで保留されるという警告メッセージが表示されます。したがって、複製処理が完了したら、新しいノードでキャッシュ・エージェントとレプリケーション・エージェントの両方を起動します。TimesTenのノード障害が次々に発生し、Oracle Databaseとの接続で問題が断続的に発生する場合、キャッシュ・エージェントとレプリケーション・エージェントを起動すると完全自動リフレッシュが開始されることがあります。

ttRepAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepAdminに関する説明を参照してください。ttRepDuplicateEx C関数の詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』のttRepDuplicateExに関する説明を参照してください。

アクティブ・スタンバイ・ペアの制限

アクティブ・スタンバイ・ペアを計画する場合は、次のことに注意してください。

- 初期設定の場合、スタンバイ・データベースの作成は、ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用してアクティブ・データベースを複製する方法で行います。

- 高可用性を実現するには、アクティブとスタンバイの各マスター・データベースと、サブスクライバ・データベースが異なるマシン上にある必要があります。

- 特にマスター・データベース・キャッチアップ、スタンバイ・マスター・リカバリ、RETURNサービスの処理などの集中操作でパフォーマンスの問題が発生しないようにするには、マスター・データベースがインストールされているホスト上にあるホスト間のネットワーク待機時間を100ミリ秒未満にすることをお薦めします。

注意:
RETURNサービスを使用する場合、アクティブ・マスターはスタンバイ・マスターからの応答を待機します。帯域幅が原因で待機時間のレスポンス時間が定義したタイムアウトを超える場合、トランザクションのパフォーマンスに悪影響を及ぼします。RETURNサービスのタイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。

- アクティブ・ノードとスタンバイ・ノード間の時間誤差は、250ミリ秒を超えることはできません。各ノードのシステム・クロックの同期がとられるように調整する場合は、時間をさかのぼって設定しないでください。

- ALTER ACTIVE STANDBY PAIR文は、アクティブ・データベースでのみ実行できます。アクティブ・データベースでALTER ACTIVE STANDBY PAIRを実行する場合は、アクティブ・データベースを複製してスタンバイ・データベースを再生成する必要があります。また、すべてのサブスクライバを、スタンバイ・データベースから再生成する必要があります。「データベースの複製」を参照してください。

- 読取り専用サブスクライバは、スタンバイ・データベースを複製することでのみ作成できます。スタンバイ・データベースを使用できない場合は、アクティブ・データベースを複製することで読取り専用サブスクライバを作成できます。「データベースの複製」を参照してください。

- サブスクライバ・データベースは、最大127まで指定できます。

- スタンバイ・データベースから読取り専用サブスクライバへのレプリケーションが非同期で実行されます。

- スタンバイ・データベースまたはサブスクライバ・データベースでは、レプリケーション表に対して書込みを実行できません。ただし、順序およびXLAブックマークに対する処理は実行できます。また、読取りも実行できます。

- フェイルオーバー後は、アクティブ・データベースを複製することでのみ、アクティブ・データベースから新しいスタンバイ・データベースをリカバリできます(アクティブ・データベースとスタンバイ・データベース間でRETURN TWOSAFEレプリケーションが使用されていない場合)。RETURN TWOSAFEレプリケーションが使用されている場合は、かわりにマスターの自動キャッチアップ機能を使用できます。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。

- 一時データベースはレプリケートできません。

- 圧縮された列を含む表はレプリケートできません。

データベースのDSNの定義

アクティブ・スタンバイ・ペアを定義する前に、アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバ・データベースのDSNを定義します。UNIXの場合は、odbc.iniファイルを作成します。Windowsの場合は、ODBCアドミニストレータを使用し、データベースを指定して接続属性を設定します。例については、「手順1: マスター・データベースおよびサブスクライバ・データベースのDSNの作成」を参照してください。

レプリケーション・スキームで指定された各データベースの名前は、そのデータベースのDSN定義内のDataStoreデータ・ストア属性で指定された、パスを除くデータベース・ファイル名の接頭辞と一致する必要があります。混乱を避けるには、各DSN定義内のDataStoreデータ・ストア属性とData Source Nameデータ・ストア属性に同じ名前を使用します。DataStoreの値は、大/小文字を区別します。たとえば、データベースのパスがdirectory/subdirectory/foo.ds0の場合、使用するデータベース名はfooになります。

アクティブ・スタンバイ・ペアの表要件

アクティブ・スタンバイ・ペアを作成する前に、レプリケート対象のオブジェクトを作成する必要があります。

アクティブ・スタンバイ・ペア内でレプリケートする表には、次のいずれかが必要です。

- 主キー

- NOT NULL列に定義された一意索引

レプリケーションでは、主キーまたは一意索引を使用して、レプリケート表の各行を識別します。レプリケーションでは、表の索引配列の順次確認で検出された最初の使用可能な索引を常に選択します。主キーがない場合、レプリケーションでは、NULL列が含まれていない最初の一意索引を選択します。また、アクティブ・データベース内のレプリケート表に対して選択された索引は、スタンバイ・データベース内の対応する表にも存在している必要があります。

注意:
レプリケート表のキーは、各更新レコードでサブスクライバに転送されます。キーが小さいほど、より効率的に転送されます。

レプリケート表には、次のようなデータ型の制限があります。

- レプリケート表のVARCHAR2、NVARCHAR2、VARBINARYおよびTT_VARCHAR列のサイズは、4MBに制限されます。VARCHAR2列の場合、文字長セマンティクスを使用する際の最大長は、特定のデータベース・キャラクタ・セットを使用する際に1文字が占めるバイト数によって異なります。たとえば、1文字に4バイトが必要なキャラクタ・セットでは、最大長は100万文字になります。NVARCHAR2の列の場合、1文字に2バイトが必要なため、文字長セマンティクスを使用する際の最大長は、200万文字になります。

- レプリケート表のBLOBデータ型を含む列のサイズは、16MBに制限されます。レプリケート表のCLOBデータ型またはNCLOBデータ型を含む列のサイズは、4MBに制限されます。

- 主キー列にはLOBデータ型を設定できません。

圧縮された列を含む表はレプリケートできません。

アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義

アクティブ・スタンバイ・ペアのレプリケーション・スキームは、SQL文CREATE ACTIVE STANDBY PAIRを使用して作成します。CREATE ACTIVE STANDBY PAIR文を使用して他のレプリケーション処理を実行するには、ADMIN権限が必要です。データベースを複製できるのはインスタンス管理者のみです。

注意:
例については、「手順3: アクティブ・スタンバイ・ペアの定義」を参照してください。「CREATE ACTIVE STANDBY PAIR」の完全な構文は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。

表3-1は、アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成するために使用されるCREATE ACTIVE STANDBY PAIR文のコンポーネントを示します。各コンポーネントについては、この章の対応するトピックで説明されます。

表3-1 アクティブ・スタンバイ・ペアのレプリケーション・スキームのコンポーネント

コンポーネント

参照先

CREATE ACTIVE STANDBY PAIR FullDatabaseName, FullDatabaseName

「アクティブ・スタンバイ・ペア内のデータベースの識別」

[ReturnServiceAttribute]

「RETURNサービスの使用」

[SUBSCRIBER FullDatabaseName [,...]]

「アクティブ・スタンバイ・ペア内のデータベースの識別」

[STORE FullDatabaseName [StoreAttribute [...]]]

「STORE属性の設定」

[NetworkOperation [...]]

ROUTE句を使用したネットワーク・インタフェースの構成

[{INCLUDE|EXCLUDE}

{TABLE [[Owner.]TableName[,...]]|

CACHE GROUP [[Owner.]CacheGroupName[,...]|

SEQUENCE [[Owner.]SequenceName[,...]]}

[,...]]

「レプリケーションに対するデータベース・オブジェクトの挿入または除外」

アクティブ・スタンバイ・ペア内のデータベースの識別

最初のコンポーネントは、アクティブ・データベース、スタンバイ・データベースおよび任意のサブスクライバ・データベースを識別します。最初のデータベース名は、アクティブ・データベースを指定します。2番目のデータベース名は、スタンバイ・データベースを指定します。読取り専用サブスクライバ・データベースは、SUBSCRIBER句によって識別されます。

「データベースのDSNの定義」で説明されている完全なデータベース名を使用します。

Command> CREATE ACTIVE STANDBY PAIR master1, master2
> SUBSCRIBER subscriber1;

高可用性システムを実現するには、アクティブ・データベースとスタンバイ・データベースは別々のホストに存在する必要があります。読取り専用のサブスクライバは、ローカルまたはリモートのいずれにもできます。リモート・サブスクライバによって、サイト固有の障害から保護されます。

また、IPアドレスまたは二重引用符で囲まれたホストのリテラル名を使用して、データベースが存在するホストを指定できます。FullDatabaseNameの一部としてホストIDを指定します。

DatabaseName [ON Host]

Hostは、IPアドレスまたはホストのリテラル名のいずれかです。hostnameオペレーティング・システム・コマンドから返された値を使用します。ホスト名は二重引用符で囲むことをお薦めします。次に例を示します。

Command> CREATE ACTIVE STANDBY PAIR
> repdb1 ON "host1",
> repdb2 ON "host2";

アクティブ・スタンバイ・ペアに対するRETURNサービスの使用

RETURNサービスを指定してレプリケーション・スキームを構成すると、レプリケーション・データが、アクティブ・データベースおよびスタンバイ・データベース上で一貫していることをより高いレベルの信頼性を持って保証できます。レプリケーション・スキーム用にRETURNサービスを構成する方法の完全な詳細は、「RETURNサービスの使用」を参照してください。

アクティブ・スタンバイ・ペアに対するSTORE属性の設定

CREATE ACTIVE STANDBY PAIR文またはALTER ACTIVE STANDBY PAIR文のSTORE属性句は、RETURNサービス、圧縮、タイムアウト、永続コミット動作および表定義チェックのオプション動作を設定するために使用されます。STORE属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE ACTIVE STANDBY PAIRに関する説明を参照してください。

注意:
ALTER ACTIVE STANDBY PAIRを使用してSTORE属性のいずれかを変更する場合、「アクティブ・スタンバイ・ペアへのその他の変更」で説明されている手順に従う必要があります。

アクティブ・スタンバイ・ペアに対してSTORE属性を構成および使用する方法の詳細は、「STORE属性の設定」を参照してください。

アクティブ・スタンバイ・ペアに対するネットワーク操作の構成

レプリケーション・ホストにネットワーク・インタフェースが複数ある場合は、デフォルト以外のインタフェースを使用するようにレプリケーションを構成することもできます。詳細は、「ROUTE句を使用したネットワーク・インタフェースの構成」を参照してください。

アクティブ・スタンバイ・ペアの自動クライアント・フェイルオーバーの使用

自動クライアント・フェイルオーバーは、TimesTenアクティブ・スタンバイ・ペア・レプリケーション構成での高可用性シナリオで使用されます。TimesTenのアクティブ・ノードに障害が発生すると、元のスタンバイ・ノードが新しいアクティブ・ノードになり、自動クライアント・フェイルオーバー機能によって、アプリケーション接続が自動的に新しいアクティブ・ノードに送られます。

自動クライアント・フェイルオーバーの構成および使用の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の自動クライアント・フェイルオーバーの使用に関する説明を参照してください。

注意:
自動クライアント・フェイルオーバーは、Oracle Clusterwareが使用されている場合のOracle Clusterwareに対する補完機能ですが、この2つの機能は互いに依存しません。Oracle Clusterwareの詳細は、第8章「Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理」を参照してください。

レプリケーションに対するデータベース・オブジェクトの挿入または除外

デフォルトでは、アクティブ・スタンバイ・ペアはデータベース全体をレプリケートします。INCLUDE句を使用すると、INCLUDE句に指定される表、キャッシュ・グループおよび順序のみをレプリケートします。INCLUDE句が定義されたアクティブ・スタンバイ・ペアの他のデータベース・オブジェクトはレプリケートされません。たとえば、このINCLUDE句では、アクティブ・スタンバイ・ペアによってレプリケートされる3つの表が指定されています。

INCLUDE TABLE employees, departments, jobs

CREATE ACTIVE STANDBY PAIR文のEXCLUDE句を使用することによって、レプリケーションから除外する特定の表、キャッシュ・グループまたは順序を選択できます。オブジェクト・タイプごとに1つのEXCLUDE句を使用します。次に例を示します。

EXCLUDE TABLE ttuser.tab1, ttuser.tab2
EXCLUDE CACHE GROUP ttuser.cg1, ttuser.cg2
EXCLUDE SEQUENCE ttuser.seq1, ttuser.seq2

注意:
CYCLE属性が指定された順序はレプリケートできません。

アクティブ・スタンバイ・ペア内の外部キーで関連付けられている表のレプリケーション

アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、外部キーで互いに関連付けられている表は、すべての表をレプリケートするか一部の表のみをレプリケートするかを選択できます。アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成前または後に、表および外部キー関係をアクティブ・マスターに作成できます。

- アクティブ・スタンバイ・ペアの作成前: アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成前に、表および外部キー関係をアクティブ・マスターに作成できます。次に、アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

- アクティブ・スタンバイ・ペアの作成後: アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成後に、表および外部キー関係をアクティブ・マスターに作成できます。表がスタンバイ・マスターに自動的にレプリケートされ、レプリケーション・スキームに追加されるようにするには、デフォルト・モード(DDLReplicationLevelが2以上に設定され、DDLReplicationAction=INCLUDE)を使用する必要があります。

外部キーを持つ子表でON DELETE CASCADEが定義されている場合は、その子表に対して外部キーで関連付けられている他のすべての表をレプリケートする必要があります。これにより、アクティブ・マスター・データベースでカスケード削除を実行した場合にスタンバイ・マスター表で外部キー競合が発生しなくなります。

TimesTenでは、カスケード削除が1つの操作としてレプリケートされ、親表で行が削除された場合に子表で発生する個々の行削除はサブスクライバにレプリケートされません。そのため、親表で削除された外部キーの値を含む行がサブスクライバ・データベースの子表に存在する場合は、その行がマスター・データベースの子表に存在していなかった場合でも削除されます。

アクティブ・スタンバイ・ペア内のマテリアライズド・ビュー

マテリアライズド・ビューまたは非マテリアライズド・ビューが含まれているデータベースをレプリケートする場合は、ビューに関連付けられているディテール表のみがレプリケートされます。ビュー自体はレプリケートされません。一致するビューは、スタンバイ・データベースで定義できますが、必須ではありません。ディテール表がレプリケートされると、TimesTenはそれに対応するビューを自動的に更新します。ただし、TimesTenレプリケーションでは、レプリケート対象のディテール表の構造が両方のデータベースで同じかどうかのみが検証されます。マテリアライズド・ビューが各データベースで同じである必要はありません。

アクティブ・スタンバイ・ペア内の順序のレプリケート

順序は、アクティブ・スタンバイ・ペアから除外したり、CYCLE属性が指定されていないかぎり、レプリケートされます。「レプリケーションに対するデータベース・オブジェクトの挿入または除外」を参照してください。順序のレプリケーションは、アクティブ・データベースで順序が更新されるたびに、スタンバイ・データベースで順序番号の範囲を予約することによって最適化されます。順序番号の範囲を予約すると、トランザクション・ログの更新回数を減らすことができます。順序番号の範囲はキャッシュと呼ばれます。アクティブ・データベースでの順序の更新のレプリケートは、順序の更新後にレプリケート・トランザクションが実行される場合、または順序の更新がレプリケート・トランザクションで使用される場合にのみ実行されます。

MINVALUEが1で、INCREMENTが1、デフォルトのCacheが20の順序my.sequenceについて考えてみます。my.sequence.NEXTVALを初めて参照すると、アクティブ・データベースの順序の現在値は2に変更され、新しい現在値21(20+1)がスタンバイ・データベースにレプリケートされます。アクティブ・データベースのmy.seq.NEXTVALへの次の19回の参照では、スタンバイ・データベースの現在値21がアクティブ・データベースの現在値より大きいため、新しい現在値のレプリケートは行われません。my.seq.NEXTVALへの21回目の参照では、前回レプリケートされたスタンバイ・データベースの現在値21が、この時点でアクティブ・データベースの現在値22より小さくなるため、新しい現在値41(21+20)がスタンバイ・データベースに送信されます。

SELECT my.seq.NEXTVAL FROM sys.dualなどの順序に対する操作では、順序値は増加しますが、レプリケートされる表でのトランザクションをその後に行うまでレプリケートは実行されません。この動作には、レプリケートされる表でのトランザクションをその後に行うまでこれらの順序の更新がログからパージされないという副作用があります。このため、これらの順序の更新のみがログの末尾に存在する場合は、ttRepSubscriberWaitおよびttRepAdmin -waitで障害が発生します。

4 レプリケーション・スキームの属性とオプションの定義

次の項では、アクティブ・スタンバイ・ペアとクラシック・レプリケーション(マスターとサブスクライバが関与)の両方に対して構成可能なRETURNサービス・オプション、STORE属性、およびネットワーク操作について説明します。レプリケーション・スキーム間の相違については、各項で詳細に説明されます。

- RETURNサービスの使用

- STORE属性の設定

- ネットワークの構成

RETURNサービスの使用

RETURNサービスを指定してレプリケーション・スキームを構成すると、レプリケーション・データが、レプリケーション・スキーム内のデータベース上で一貫していることをより高いレベルの信頼性を持って保証できます。

注意:
この項では、RETURNサービスに精通していることを前提にしています。RETURNサービスの概要は、「データベース間の更新のコピー」を参照してください。

この項では、RETURN RECEIPTおよびRETURN TWOSAFEサービスの構成方法および管理方法について説明します。CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文を使用してレプリケーション・スキームで定義されるいずれのスタンバイまたはサブスクライバの表要素およびデータベース要素に対してもRETURNサービスを指定できます。デフォルトはNO RETURNサービス(非同期レプリケーション)で、最適なパフォーマンス・オプションです。

注意:
ttRepXactStatusプロシージャを使用してRETURN RECEIPTトランザクションまたはRETURN TWOSAFEトランザクションのステータスを確認できます。詳細は、「RETURNサービス・トランザクションのステータスの確認」を参照してください。

次の項では、レプリケーション・スキームで使用できるRETURNサービスを説明します。

- クラシック・レプリケーション・スキーム内の各サブスクライバに対する異なるRETURNサービスの指定

- RETURN RECEIPT

- RETURN RECEIPT BY REQUEST

- RETURN TWOSAFE

- RETURN TWOSAFE BY REQUEST

- NO RETURN

クラシック・レプリケーション・スキーム内の各サブスクライバに対する異なるRETURNサービスの指定

クラシック・レプリケーション・スキームでは、CREATE REPLICATION文またはALTER REPLICATION文の各SUBSCRIBER句でリストされるサブスクライバの表要素およびデータベース要素に対して、異なるRETURNサービスを指定できます。

例4-1に、SubDatabase1とSubDatabase2に異なるRETURNサービス属性を定義する個別のSUBSCRIBER句を示します。

例4-1 各サブスクライバで異なるRETURNサービス

CREATE REPLICATION Owner.SchemeName
ELEMENT ElementNameElementType
MASTER DatabaseName ON "HostName"
SUBSCRIBER SubDatabase1 ON "HostName" ReturnServiceAttribute1
SUBSCRIBER SubDatabase2 ON "HostName" ReturnServiceAttribute2;

また、要素で定義されるすべてのサブスクライバに、同じRETURNサービス属性を指定することもできます。例4-2に、1つのSUBSCRIBER句を使用して、SubDatabase1とSubDatabase2の両方に同じRETURNサービス属性を定義する例を示します。

例4-2 すべてのサブスクライバで同じRETURNサービス

CREATE REPLICATION Owner.SchemeName
ELEMENT ElementNameElementType
MASTER DatabaseName ON "HostName"
SUBSCRIBER SubDatabase1 ON "HostName",
SubDatabase2 ON "HostName"
ReturnServiceAttribute;

RETURN RECEIPT

TimesTenでは、アプリケーションをレプリケーション・メカニズムと疎結合または同期するためにオプションのRETURN RECEIPTサービスが提供されています。

- アクティブ・スタンバイ・ペアでは、RETURN RECEIPT句を指定して、スタンバイ・データベースのRETURN RECEIPTサービスを有効にできます。RETURN RECEIPTが有効になっている場合、アプリケーションがアクティブ・データベースの要素に対するトランザクションをコミットすると、スタンバイがトランザクション更新の受信を確認するまでブロックされたままになります。

- クラシック・レプリケーション・スキームでは、RETURN RECEIPT句を指定して、サブスクライバ・データベースのRETURN RECEIPTサービスを有効にできます。RETURN RECEIPTが有効になっている場合、アプリケーションは、マスター・データベースの要素に対するトランザクションをコミットすると、サブスクライバがトランザクション更新の受信を確認するまでブロックされたままになります。マスターが複数のサブスクライバに要素をレプリケートしている場合、すべてのサブスクライバがトランザクション更新の受信を確認するまで、アプリケーションはブロックされたままになります。

注意:
また、タイムアウトが特定の回数発生した後、RETURN RECEIPTサービスを無効にするようにレプリケーション・エージェントを構成できます。タイムアウトの詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。

構成可能なタイムアウト時間内にスタンバイまたはサブスクライバでトランザクションの受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。

例4-3 アクティブ・スタンバイ・ペアに対するRETURN RECEIPTの定義

次の例は、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN RECEIPTサービスが有効になります。

Command> CREATE ACTIVE STANDBY PAIR
> master1,
> master2
> RETURN RECEIPT;

例4-4 クラシック・レプリケーション・スキームに対するRETURN RECEIPTの定義

マスター・データベース(masterds)のtab表に対してコミットしたすべてのトランザクションがサブスクライバ(subscriberds)で受信されたことを確認する場合、要素記述(e)は次のようになります。

注意: RETURN RECEIPTサービスを使用するクラシック・レプリケーション・スキームのその他の例は、例9-5および例9-6を参照してください。

ELEMENT e TABLE tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT

RETURN RECEIPT BY REQUEST

RETURN RECEIPTは、すべてのトランザクションに対して受信の通知を有効にします。RETURN RECEIPT BY REQUEST句を使用すると、アプリケーションで識別される特定のトランザクションに対してのみ確認応答の受信通知を有効にできます。

RETURN RECEIPT BY REQUESTを指定する場合は、ttRepSyncSet組込みプロシージャをアクティブ・データベースまたはマスター・データベースで使用して、トランザクションに対してRETURN RECEIPTサービスを有効にする必要があります。RETURN RECEIPTサービスを有効にするコールは、トランザクションの一部である必要があります(AutoCommitは無効である必要があります)。

構成可能なタイムアウト時間内にスタンバイ・データベースまたはサブスクライバ・データベースでトランザクション更新の受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。

例4-5 アクティブ・スタンバイ・ペアに対するRETURN RECEIPT BY REQUEST

次の例は、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN RECEIPTサービスが有効になります。

Command> CREATE ACTIVE STANDBY PAIR
> master1,
> master2
> RETURN RECEIPT BY REQUEST;

例4-6 クラシック・レプリケーション・スキームに対するRETURN RECEIPT BY REQUEST

マスター・データベース(masterds)のtab表に対してコミットした特定のトランザクションがサブスクライバ(subscriberds)で受信されたことの確認を有効にする場合、要素記述(e)は次のようになります。

ELEMENT e TABLE tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT BY REQUEST

例4-7 ttRepSyncSet によるRETURNサービスの要求

確認応答のRETURN RECEIPTを必要とするトランザクションをコミットする前に、ttRepSyncSetをコールします。次の例は、最初の列が0x01に、2つ目の列が45秒のタイムアウト値に設定されたRETURN RECEIPTに対する要求を設定します。

Command> autocommit off;
Command> CALL ttRepSyncSet(0x01, 45, 1);

ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次の例は、前述の例でttRepSyncSet組込みプロシージャを使用して設定された値を示しています。

Command> CALL ttRepSyncGet;
< 01, 45, 1 >
1 row found.

詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepSyncSetおよびttRepSyncGetに関する説明を参照してください。

RETURN TWOSAFE

TimesTenでは、アプリケーションをレプリケーション・メカニズムと完全に同期するために、RETURN TWOSAFEサービスが提供されています。RETURN TWOSAFEサービスの場合、各レプリケーション・トランザクションは、アクティブ・データベースでコミットされる前にスタンバイ・データベースでコミットされます。スタンバイまたはサブスクライバでトランザクションがコミットされたかどうかをレプリケーションで確認できなかった場合は、エラー通知が返されます。エラー受信後、アプリケーションで、障害のタイプに応じて、固有のアクションまたは事前に構成されているアクションのいずれかを実行できます。

注意:
レプリケーションがRETURN TWOSAFEで構成されている場合は、自動コミット・モードを無効にする必要があります。

サブスクライバに対してRETURN TWOSAFEサービスを有効にするには、CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文にRETURN TWOSAFE属性を指定します。

- アクティブ・スタンバイ・ペアを使用している場合、RETURN TWOSAFEを使用してレプリケートされた操作が含まれているトランザクションでは、PassThroughを0 (ゼロ)より大きい値に設定することはできません。PassThroughが0より大きい場合は、エラーが返され、トランザクションをロールバックする必要があります。

- クラシック・レプリケーション・スキームを使用している場合は、RETURN TWOSAFEは、2つのデータベースが常に同期されている必要があるレプリケーション・スキームでの使用を前提としています。一方のデータベースの役割はアクティブ状態で、もう一方のデータベースの役割はスタンバイ状態ですが、いつでもアクティブ状態になることができる準備ができている必要があります。RETURN TWOSAFEは、2つのみのデータベースによる双方向レプリケーション・スキームで使用します。
アプリケーションは、マスター・データベースでトランザクションをコミットすると、トランザクションが正常にコミットされたことがサブスクライバで確認されるまでブロックされたままになります。両方のデータベースで同じ更新または削除を開始すると、コミットがデッドロックする可能性があり、これは処理を停止することでのみ解決できます。

構成可能なタイムアウト時間内にスタンバイまたはサブスクライバでトランザクション更新のコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。

例4-8 アクティブ・スタンバイ・ペアでのRETURN TWOSAFE

次の例は、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN TWOSAFEサービスが有効になります。

Command> CREATE ACTIVE STANDBY PAIR
> master1,
> master2
> RETURN TWOSAFE;

例4-9 クラシック・レプリケーション・スキームでのRETURN TWOSAFE

マスター・データベース(databaseA)でコミットされたすべてのトランザクションがサブスクライバ(databaseB)でもコミットされたことを確認する場合、要素記述(a)は次のようになります。

ELEMENT a DATASTORE
MASTER databaseA ON "system1"
SUBSCRIBER databaseB ON "system2"
RETURN TWOSAFE

RETURN TWOSAFEが指定された双方向構成でdatabaseAおよびdatabaseBの両方を指定するCREATE REPLICATION文全体は、次のようになります。

CREATE REPLICATION bidirect
ELEMENT a DATASTORE
MASTER databaseA ON "system1"
SUBSCRIBER databaseB ON "system2"
RETURN TWOSAFE
ELEMENT b DATASTORE
MASTER databaseB ON "system2"
SUBSCRIBER databaseA ON "system1"
RETURN TWOSAFE;

RETURN TWOSAFE BY REQUEST

RETURN TWOSAFEは、すべてのトランザクションに対してスタンバイ・データベースでのコミットの通知を有効にします。RETURN TWOSAFE BY REQUEST句を使用すると、アプリケーションで識別される特定のトランザクションのみに関するスタンバイでのコミットの通知を有効にできます。

スタンバイ・データベースまたはサブスクライバ・データベースにRETURN TWOSAFE BY REQUESTを指定する場合は、アクティブ・データベースまたはマスター・データベースでttRepSyncSet組込みプロシージャを使用して、トランザクションに対してRETURN TWOSAFEサービスを有効にする必要があります。RETURN TWOSAFEサービスを有効にするコールは、トランザクションの一部である必要があります(autocommitは無効である必要があります)。

ALTER TABLE文を使用して、RETURN TWOSAFE BY REQUESTトランザクションの一部であるレプリケート表を変更することはできません。DDLCommitBehavior=0(デフォルト)の場合、ALTER TABLE操作の前にコミットが実行されるためこのALTER TABLE操作は成功し、ALTER TABLE操作はRETURN TWOSAFE BY REQUESTトランザクションの一部ではない新しいトランザクションで実行されることになります。DDLCommitBehavior=1の場合、ALTER TABLE操作の結果はエラー8051になります。

注意:
RETURNサービス・タイムアウト時間の設定の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。

タイムアウト時間内にスタンバイまたはサブスクライバでトランザクションのコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。アプリケーションではタイムアウトの処理方法を選択できます。「RETURNサービス・タイムアウト時間の設定」を参照してください。

アクティブ・スタンバイ・ペアを使用している場合、RETURN TWOSAFEを使用してレプリケートされた操作が含まれているトランザクションでは、PassThroughを0 (ゼロ)より大きい値に設定することはできません。PassThroughが0より大きい場合は、エラーが返され、トランザクションをロールバックする必要があります。

例4-10 アクティブ・スタンバイ・ペアに対するRETURN TWOSAFE BY REQUST

次の例は、master1がアクティブ・データベース、master2がスタンバイ・データベースであるアクティブ・スタンバイ・ペアを作成します。スタンバイ・データベースに対しては、RETURN TWOSAFE BY REQUESTサービスが有効になります。

Command> CREATE ACTIVE STANDBY PAIR
> master1,
> master2
> RETURN TWOSAFE BY REQUEST;

サブスクライバでのコミットの確認が必要なトランザクションのコミットをコールする前に、ttRepSyncSet組込みプロシージャをコールしてRETURNサービスをリクエストし、タイムアウト時間を45秒に設定し、タイムアウト・エラー発生時の動作をNO ACTION(1)に指定します。

Command> CALL ttRepSyncSet(0x01, 45, 1);

ttRepSyncGet組込みプロシージャを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。

Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.

例4-11 クラシック・レプリケーション・スキームに対するRETURN TWOSAFE BY REQUEST

マスター・データベース(databaseA)でコミットされた特定のトランザクションがサブスクライバ(databaseB)でもコミットされたことの確認を有効にする場合、要素記述(a)は次のようになります。

ELEMENT a DATASTORE
MASTER databaseA ON "system1"
SUBSCRIBER databaseB ON "system2"
RETURN TWOSAFE BY REQUEST;

サブスクライバでのコミットの確認が必要なトランザクションのコミットをコールする前に、ttRepSyncSet組込みプロシージャをコールしてRETURNサービスをリクエストし、タイムアウト時間を45秒に設定し、タイムアウト・エラー発生時の動作をNO ACTION(1)に指定します。

Command> CALL ttRepSyncSet(0x01, 45, 1);

ttRepSyncGet組込みプロシージャを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。

Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.

NO RETURN

NO RETURN句を使用して、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスのいずれか(有効にされているサービスに応じて)を明示的に無効にできます。デフォルト設定はNO RETURNです。この属性は、通常、以前にALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文で定義されたRETURNサービスを削除するためにレプリケーション・スキームを変更する場合のみ使用されます。例10-13を参照してください。

STORE属性の設定

CREATE ACTIVE STANDBY PAIR、ALTER ACTIVE STANDBY PAIR、CREATE REPLICATIONおよびALTER REPLICATION文のSTORE属性句は、RETURNサービス、圧縮、タイムアウト、永続コミット動作および表定義チェックのオプション動作を設定するために使用されます。クラシック・レプリケーション・スキームでは、競合レポートを表レベルで定義することもできます。

注意:
STORE属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の「CREATE ACTIVE STANDBY PAIR」および「CREATE REPLICATION」を参照してください。

クラシック・レプリケーション・スキームを使用している場合、FAILTHRESHOLDおよびTIMEOUT属性は、特定のクラシック・レプリケーション・スキーム定義に対して固有に設定できます。つまり、これらの属性は、レプリケート・データベースに異なるクラシック・レプリケーション・スキーム定義を適用している場合に、異なって設定できます。これは他の属性には適用されず、他の属性は、すべてのクラシック・レプリケーション・スキーム定義で同じである必要があります。たとえば、1つのクラシック・レプリケーション・スキームにPORT属性を設定すると、すべてのクラシック・レプリケーション・スキームにその設定が適用されます。STORE句を使用してFAILTHRESHOLD属性を設定するクラシック・レプリケーション・スキームの例は、例9-5を参照してください。

注意:
ALTER ACTIVE STANDBY PAIRを使用してSTORE属性のいずれかを変更する場合、「アクティブ・スタンバイ・ペアへのその他の変更」で説明されている手順に従う必要があります。

次の各項では、いくつかのSTORE属性について説明します。

- RETURNサービス・タイムアウト時間の設定

- レプリケート表の列定義オプション

- レプリケートの通信量の圧縮

- ポート割当て

- リモート・レプリケーション・エージェントからの応答の待機タイムアウトの設定

- トランザクション・ログ障害しきい値の設定

- 競合への対応としてのクラシック・レプリケーションの一時停止と再開

RETURNサービス・タイムアウト時間の設定

次に、「RETURNサービスの使用」で説明されているRETURNサービスの1つを使用して構成されているレプリケーション・スキームでタイムアウトが発生する状況を説明します。

- アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、RETURN WAIT TIMEで指定した時間内にスタンバイ・データベースがアクティブ・データベースに確認応答を送信できない場合にタイムアウトが発生します。
タイムアウト時間内にスタンバイ・データベースでアクティブ・データベースからのトランザクションの更新を確認できない場合、アプリケーションは、コミット・リクエストに対するerrRepReturnFailed警告を受信します。

- クラシック・レプリケーション・スキームでは、RETURN WAIT TIMEで指定した時間内にいずれかのサブスクライバがマスターに確認応答を送信できない場合にタイムアウトが発生します。
サブスクライバ障害が発生した場合、ユーザーまたはマスター・レプリケーション・エージェントによりレプリケーション状態がstopに設定される可能性があります。サブスクライバが、RETURNサービスを使用しているトランザクションを確認できず、マスターに対してタイムアウトする場合もあります。

タイムアウト時間内にいずれかのサブスクライバがトランザクション更新を確認できない場合、アプリケーションは、コミット・リクエストに対するerrRepReturnFailed警告を受信します。

RETURNサービスは、レプリケーション障害が発生した場合、またはレプリケーションに時間がかかりすぎて、レプリケートされる前にRETURNサービス・トランザクションがタイムアウトした場合にタイムアウトします。ただし、レプリケーション障害が同時に発生しないかぎり、スタンバイまたはサブスクライバからRETURNサービスの確認を取得することに失敗しても、トランザクションがレプリケートされていないこと、または将来レプリケートされないことを意味しない場合もあります。

デフォルトのRETURNサービス・タイムアウト時間は10秒です。異なるRETURNサービス・タイムアウト時間は、次のいずれかの方法で指定できます。

- CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文にRETURN WAIT TIMEを指定します。
RETURN WAIT TIME属性は、RETURNサービスの応答を待機する時間(秒)を指定します。値が0(ゼロ)の場合は、待機なしを意味します。

次の例は、アクティブ・スタンバイ・ペアのアクティブ・データベース(master1)を変更して、RETURNサービスの待機時間を25秒に設定します。

Command> ALTER ACTIVE STANDBY PAIR
> ALTER STORE master1 SET RETURN WAIT TIME 25;

- returnWaitパラメータの新しいタイムアウト値を指定し、アクティブ・データベース(アクティブ・スタンバイ・ペアの場合)またはマスター・データベース(クラシック・レプリケーション・スキームの場合)のいずれかでttRepSyncSet組込みプロシージャをコールすることにより、異なるRETURNサービスのタイムアウト時間をプログラムで指定します。
次の例は、ttRepSyncSetを使用して、RETURNサービスの待機時間を25秒に設定する方法を示します。

Command> CALL ttRepSyncSet (0x01, 25, 1);

タイムアウト時間は、設定後、再設定するか、またはアプリケーション・セッションが終了するまで、後続のすべてのRETURNサービス・トランザクションに適用されます。クラシック・レプリケーション・スキームの場合、タイムアウト設定は、すべてのサブスクライバのすべてのRETURNサービスに適用されます。

注意:
他のSTORE属性を設定して、タイムアウトが過剰に発生する場合にRETURNサービス・ブロッキングを自動的に無効にし、状況が改善されるとRETURNサービス・ブロッキングを再度有効にするポリシーを設定できます。「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。

例4-12 双方向(クラシック)レプリケーション・スキームの両方のデータベースでのタイムアウト時間の設定

bidirectレプリケーション・スキームで、双方向にレプリケートされるデータベースdatabaseAおよびdatabaseBの両方のタイムアウト時間を30秒に設定する場合、CREATE REPLICATION文は次のようになります。

CREATE REPLICATION bidirect
ELEMENT a DATASTORE
MASTER databaseA ON "system1"
SUBSCRIBER databaseB ON "system2"
RETURN TWOSAFE
ELEMENT b DATASTORE
MASTER databaseB ON "system2"
SUBSCRIBER databaseA ON "system1"
RETURN TWOSAFE
STORE databaseA RETURN WAIT TIME 30
STORE databaseB RETURN WAIT TIME 30;

例4-13 タイムアウト時間の再設定

タイムアウト時間を45秒に再設定するには、ttRepSyncSet組込みプロシージャを使用します。requestReturnおよびlocalAction値を再設定しないようにするには、NULLを指定します。

Command> CALL ttRepSyncSet(NULL, 45, NULL);

RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理

次の項では、RETURNサービス・トランザクションで発生したタイムアウトを検出および対応する方法について説明します。

注意:
タイムアウトへの対応方法の1つは、RETURNサービスを無効にすることです。RETURNサービスが有効にされているか、または無効にされているかを確認するには、ttRepSyncSubscriberStatus組込みプロシージャをコールするか、またはttRepReturnTransitionTrap SNMPトラップを使用します。詳細は、「RETURNサービスが無効にされているかどうかの確認」を参照してください。

- RETURNサービス・ブロッキングの手動による無効化

- RETURNサービス障害/リカバリ・ポリシーの設定

RETURNサービス・ブロッキングの手動による無効化

レプリケーションが停止した場合、またはレプリケート・システムのパフォーマンスにRETURNサービス・タイムアウト障害が悪影響を及ぼし始めた場合は、なんらかの方法で対処する必要があります。RETURNサービス・タイムアウトの許容しきい値は、特定のアプリケーションのタイムアウトの履歴頻度およびパフォーマンスと可用性の関係によって異なるため、問題に対処する場合、これらの両方の要素について考慮する必要があります。

RETURN RECEIPTサービスを使用している場合、次の方法で手動により対処できます。

- ALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文を使用して、RETURN RECEIPTブロッキングを無効にします。RETURN RECEIPTブロッキングを無効にすると決めた場合、これを再度有効にするという判断は、RETURN RECEIPTトランザクションがタイムアウトしないと確信できるレベルに基づいて行います。
次の例は、ALTER ACTIVE STANDBY PAIR文を使用して、10回の失敗後にRETURN RECEIPTを無効にします。

Command> ALTER ACTIVE STANDBY PAIR
> ALTER STORE master1 SET DISABLE RETURN ALL 10;

- ttDurableCommit組込みプロシージャをコールし、スタンバイ・データベースまたはサブスクライバ・データベースで受信されたかどうかを確認できなくなったアクティブ・データベースまたはマスター・データベースのトランザクションを永続的にコミットします。

RETURNサービス障害/リカバリ・ポリシーの設定

手動でRETURNサービス・タイムアウト障害に対処するかわりに、RETURNサービス障害およびリカバリ・ポリシーをレプリケーション・スキームに設定して対処することもできます。これらのポリシーは、レプリケーション状態の変化の検出およびRETURNサービス・タイムアウトの追跡を行い、事前に設定した方法で自動的に対処するようにレプリケーション・エージェントに直接指示します。

RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスを使用する場合は、CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文の次の属性によって障害/リカバリ・ポリシーを設定します。

- RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED

- DISABLE RETURN

- RESUME RETURN

- DURABLE COMMIT

- LOCAL COMMIT ACTION

これらの属性によって設定したポリシーは、変更されるまで適用されます。DURABLE COMMITを除いて、これらのポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。

RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED

レプリケーションが停止した場合は、RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED属性によって、RETURN RECEIPTまたはRETURN TWOSAFEサービスを継続して有効にするか、無効にするかが決定されます。

- アクティブ・スタンバイ・ペアでの「停止」とは、(ttAdmin -repStop activeなどによって)アクティブ・レプリケーション・エージェントが停止されたこと、または(ttRepAdmin -state stop standbyなどによって)スタンバイ・データベースのレプリケーション状態がアクティブ・データベースに対してstopまたはpauseに設定されることを意味しています。指定したFAILTHRESHOLD値を超えている障害が発生したスタンバイ・データベースは、failed状態に設定されますが、最終的にはアクティブ・データベースのレプリケーション・エージェントによってstop状態に設定されます。

- クラシック・レプリケーション・スキームでの「停止」とは、(ttAdmin -repStop masterなどによって)マスター・レプリケーション・エージェントが停止されたこと、または(ttRepAdmin -state stop subscriberなどによって)サブスクライバ・データベースのレプリケーション状態がマスター・データベースに対してstopまたはpauseに設定されることを意味します。指定したFAILTHRESHOLD値を超えている障害が発生したサブスクライバは、failed状態に設定されますが、最終的にはマスター・レプリケーション・エージェントによってstop状態に設定されます。

注意:
スタンバイ・データベースまたはサブスクライバ・データベースは、RETURN WAIT TIMEで指定されたタイムアウト時間を超えるとその期間中は使用できなくなりますが、マスター・レプリケーション・エージェントでは継続してstart状態であるとみなされます。タイムアウトに関連する障害ポリシーは、DISABLE RETURN属性によって設定されます。

- RETURN SERVICES OFF WHEN REPLICATION STOPPEDは、レプリケーションが停止するとRETURNサービスを無効にし、RETURN RECEIPTサービス使用時のデフォルト設定です。

- RETURN SERVICES ON WHEN REPLICATION STOPPEDは、レプリケーションが停止した場合でもRETURNサービスを継続して有効にすることができ、RETURN TWOSAFEサービス使用時のデフォルト設定です。

例4-14 アクティブ・スタンバイ・ペアに対するRETURN SERVICES ON WHEN REPLICATION STOPPED

次の例は、RETURN TWOSAFE RETURNサービスを使用するアクティブ・スタンバイ・ペアを作成し、レプリケーションが停止したときにRETURNサービスが無効になるよう(デフォルトとは逆)定義します。

Command> CREATE ACTIVE STANDBY PAIR
> master1,
> master2
> RETURN TWOSAFE
> STORE master2 RETURN SERVICES OFF WHEN REPLICATION STOPPED;

アプリケーションでアクティブ・データベースmaster1への更新をコミットする場合は、ttRepAdminを使用してスタンバイ・データベースmaster2をstop状態に設定します。

ttRepAdmin -receiver -name master2 -state stop master1

アプリケーションは、レプリケーション状態がstartに再設定され、master2からRETURN RECEIPT確認応答を受信するまでこの確認応答を継続して待機します。

ttRepAdmin -receiver -name master2 -state start master1

例4-15 クラシック・レプリケーション・スキームに対するRETURN SERVICES ON WHEN REPLICATION STOPPED

masterdsデータベースからsubscriber1データベースに更新をレプリケートするように、CREATE REPLICATION文を構成します。このCREATE REPLICATION文では、RETURN RECEIPTおよびRETURN SERVICES ON WHEN REPLICATION STOPPEDの使用が指定されています。

CREATE REPLICATION myscheme
ELEMENT e TABLE tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1 ON "server2"
RETURN RECEIPT
STORE masterds ON "server1"
RETURN SERVICES ON WHEN REPLICATION STOPPED;

アプリケーションでマスターへの更新をコミットする場合は、ttRepAdminを使用してsubscriber1をstop状態に設定します。

ttRepAdmin -receiver -name subscriber1 -state stop masterds

アプリケーションは、レプリケーション状態がstartに再設定され、subscriber1からRETURN RECEIPT確認応答を受信するまでこの確認応答を継続して待機します。

ttRepAdmin -receiver -name subscriber1 -state start masterds

DISABLE RETURN

DISABLE RETURN値を設定すると、データベースは、RETURN WAIT TIMEで設定されたタイムアウト時間を超えているRETURN RECEIPTトランザクションおよびRETURN TWOSAFEトランザクションの数を追跡します。タイムアウト数がDISABLE RETURNで設定した最大値を超えると、アプリケーションは、デフォルトのレプリケーション・サイクルに戻り、レプリケート対象の更新に対するスタンバイまたはサブスクライバからの確認応答を待機しなくなります。

RETURNサービス・ブロッキングが無効である場合、アクティブ・データベースまたはマスター・データベースのアプリケーションは、レプリケーション更新を受信またはコミットしたスタンバイまたはサブスクライバからの確認応答を待機している間、実行をブロックしません。RETURNサービスが有効であるか無効であるかに関係なく、トランザクションは引き続きスタンバイまたはサブスクライバにレプリケートされます。RETURNサービスが無効な場合、トランザクションは非同期モードで送信されます。アクティブ・データベースまたはマスター・データベースは、レプリケートされた更新の各バッチに関する、スタンバイ・データベースまたはサブスクライバ・データベースからの確認応答を引き続きリスニングします。

DISABLE RETURNを次のように構成します。

- アクティブ・スタンバイ・ペアの場合、SUBSCRIBERを指定することは、ALLを指定することと同じです。どちらの設定でも、スタンバイ・データベースが参照されます。

- クラシック・レプリケーション・スキームの場合、DISABLE RETURN SUBSCRIBERを設定して、タイムアウトしたサブスクライバに対してのみRETURNサービス・ブロッキングを無効にするポリシーを設定するか、またはDISABLE RETURN ALLを設定して、すべてのサブスクライバに対してRETURNサービス・ブロッキングを無効にするポリシーを設定できます。

注意:
DISABLE RETURN障害ポリシーによってスタンバイ・データベースまたは特定のサブスクライバが無効にされているかどうかを確認するには、ttRepSyncSubscriberStatus組込みプロシージャまたはSNMPトラップttRepReturnTransitionTrapを使用します。

DISABLE RETURN障害ポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。RESUME RETURNなしでDISABLE RETURNが指定されている場合、データベースのレプリケーション・エージェントが再起動されるまでRETURNサービスはオフのままです。

- アクティブ・スタンバイ・ペアの場合、この障害ポリシーは、レプリケーション・エージェントを停止し、DISABLE RETURNをNumFailuresの値を0 (ゼロ)にして指定すると取り消すことができます。

- クラシック・レプリケーション・スキームの場合、この障害ポリシーは、レプリケーション・エージェントを停止し、DISABLE RETURN SUBSCRIBERまたはDISABLE RETURN ALLのいずれかをNumFailuresの値を0 (ゼロ)にして指定すると取り消すことができます。
DISABLE RETURNは、各サブスクライバのタイムアウトの累積カウントを保持します。複数のサブスクライバが存在する場合にDISABLE RETURN SUBSCRIBERを設定すると、レプリケーション・エージェントは、タイムアウトのしきい値に最初に達したサブスクライバのRETURNサービス・ブロッキングを無効にします。その後、他のいずれかのサブスクライバがタイムアウトのしきい値に達すると、レプリケーション・エージェントは、そのサブスクライバのRETURNサービス・ブロッキングも同様に無効にします。

障害ポリシーをトリガーするタイムアウトのカウントは、レプリケーション・エージェントを再起動したとき、DISABLE RETURN値を0に設定したとき、またはRETURNサービス・ブロッキングがRESUME RETURNによって再度有効にされたときにリセットされます。

例4-16 アクティブ・スタンバイ・ペアに対するDISABLE RETURN

master1データベースからmaster2データベースに更新をレプリケートするように、CREATE ACTIVE STANDBY PAIR文を構成します。CREATE ACTIVE STANDBY PAIR文では、NumFailuresの値を5にしてRETURN RECEIPTおよびDISABLE RETURN ALLの使用が指定されています。RETURN WAIT TIMEは30秒に設定されています。

CREATE ACTIVE STANDBY PAIR
master1,
master2
RETURN RECEIPT
STORE master1
DISABLE RETURN ALL 5
RETURN WAIT TIME 30;

アプリケーションでアクティブ・データベースへの更新をコミットすると、スタンバイ・データベースmaster2で問題が発生し、レプリケート対象のトランザクション更新の確認に失敗します。アプリケーションは、アクティブ・データベースmaster1への次の更新をコミットするまで30秒ブロックされます。アプリケーション・セッションの期間中、このコミット/タイムアウトのサイクルは、DISABLE RETURNによってmaster2のRETURN RECEIPTブロッキングが無効になるまでこの後4回繰り返されます。

アクティブ・スタンバイ・ペアにDISABLE RETURN属性を設定するもう1つの例は、例4-18を参照してください。

例4-17 クラシック・レプリケーション・スキームに対するDISABLE RETURN SUBSCRIBER

マスター・データベースmasterdsからサブスクライバ・データベースのsubscriber1およびsubscriber2に更新をレプリケートするように、CREATE REPLICATION文を構成します。CREATE REPLICATION文では、NumFailuresの値を5にしてRETURN RECEIPTおよびDISABLE RETURN SUBSCRIBERの使用が指定されています。RETURN WAIT TIMEは30秒に設定されています。

CREATE REPLICATION myscheme
ELEMENT e TABLE tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1 ON "server2",
subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
DISABLE RETURN SUBSCRIBER 5
RETURN WAIT TIME 30;

アプリケーションでマスターへの更新をコミットすると、subscriber1で問題が発生し、レプリケート対象のトランザクション更新の確認に失敗します。アプリケーションは、マスター・データベースmasterdsへの次の更新をコミットするまで30秒ブロックされます。アプリケーション・セッションの期間中、このコミット/タイムアウトのサイクルは、DISABLE RETURNによってsubscriber1のRETURN RECEIPTブロッキングが無効になるまでこの後4回繰り返されます。アプリケーションは、subscriber1からではなく、subscriber2からのRETURN RECEIPT確認応答を継続して待機します。

クラシック・レプリケーション・スキームにDISABLE RETURN属性を設定するもう1つの例は、例4-19を参照してください。

RESUME RETURN

RETURNサービス・ブロッキングがDISABLE RETURNによって無効になっている場合、RESUME RETURN属性は、RETURNサービスの再有効化に関するポリシーを設定します。RETURNサービス・リカバリ・ポリシーは、RESUME RETURN属性を設定し、再開待機時間の値を指定して設定できます。

RETURNサービス・ブロッキングがスタンバイ・データベースまたはサブスクライバ・データベースに関して無効になっており、待機時間がRESUME RETURNに定義されていると、次の事象が発生します。

- アクティブ・データベースまたはマスター・データベースのアプリケーションは、スタンバイまたはサブスクライバからの確認応答を待機している間、実行をブロックしません。トランザクションは引き続きスタンバイまたはサブスクライバに非同期モードでレプリケートされます。アクティブ・データベースまたはマスター・データベースは、レプリケートされた更新の各バッチに関する、スタンバイ・データベースまたはサブスクライバ・データベースからの確認応答を引き続きリスニングします。

- RETURNサービス・ブロックが無効な場合、RESUME RETURNは最後のトランザクションのコミット確認応答時間を評価して、待機時間がRESUME RETURNにより構成されている待機時間制限よりも短いかどうかを確認します。コミット確認応答時間がRESUME RETURNにより設定されている待機時間制限よりも短い場合、TimesTenは、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスを再度有効にします。

注意:
コミット確認応答時間とは、アプリケーションがコミットを実行してから、アクティブ・データベースまたはマスター・データベースがスタンバイまたはサブスクライバから更新の確認応答を受信するまでに経過した時間のことです。
確認応答された最後のトランザクションの待機時間をTimesTenが評価した後に、現在のトランザクションはスタンバイまたはサブスクライバにレプリケートされます。最後のトランザクションからの待機時間が評価された後、RETURNサービスが再度有効にされ、その後、現在のトランザクションが送信されます。

RESUME RETURNポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。RETURN RECEIPT再開ポリシーは、レプリケーション・エージェントを停止した後、ALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文を使用してRESUME RETURNを0 (ゼロ)に設定して取り消すことができます。

例4-18 アクティブ・スタンバイ・ペアに対するRESUME RETURN

RETURN RECEIPTブロッキングがmaster2に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、RETURN RECEIPTブロッキングは、アクティブ・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の8ミリ秒未満でその更新の確認応答が受け取られた場合にかぎり、アクティブが更新の確認応答をスタンバイから受け取るとすぐに、master2に対して再度有効にされます。

Command> CREATE ACTIVE STANDBY PAIR
> master1,
> master2
> RETURN RECEIPT
> STORE master1
> DISABLE RETURN ALL 5
> RESUME RETURN 8;

例4-19 クラシック・レプリケーション・スキームに対するRESUME RETURN

RETURN RECEIPTブロッキングがsubscriber1に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、RETURN RECEIPTブロッキングは、マスター・データベースのアプリケーションで更新がコミットされてから指定されている待機時間の8ミリ秒未満でその更新の確認応答が受け取られた場合にかぎり、マスターが更新の確認応答をサブスクライバから受け取るとすぐに、subscriber1に対して再度有効にされます。

CREATE REPLICATION myscheme
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1 ON "server2",
subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
DISABLE RETURN SUBSCRIBER 5
RESUME RETURN 8;

DURABLE COMMIT

DURABLE COMMIT属性を設定して、DISABLE RETURNでRETURNサービス・ブロッキングを無効にしたアプリケーションに永続コミット・ポリシーを指定できます。DURABLE COMMITをONに設定すると、アクティブ・データベースまたはマスター・データベースのDurableCommits一般接続属性が上書きされ、RETURNサービス・ブロッキングを無効にしたトランザクションに対して永続コミットが強制実行されます。

また、DURABLE COMMITをONに設定すると、レプリケーション・エージェントが実行中であるか停止中であるかに関係なく、RETURNサービス・ブロッキングが無効になっている場合、永続コミットが発行されます。また、ttRepStateSave組込みプロシージャでスタンバイ・データベースまたはサブスクライバ・データベースがfailedとしてマークされている場合も、永続コミットが発行されます。

クラシック・レプリケーション・スキームの場合、DURABLE COMMITは、サブスクライバが1つのみ存在する場合に役立ちます。ただし、2つのサブスクライバに同じデータをレプリケートし、一方のサブスクライバのRETURNサービス・ブロッキングを無効にした場合は、永続コミットを有効にするより、他方のサブスクライバを使用した方が、より高いパフォーマンスを得ることができます。

例4-20 アクティブ・スタンバイ・ペアでのDURABLE COMMIT ON

DISABLE RETURN ALLポリシーを設定してすべてのサブスクライバのRETURN RECEIPTブロッキングを無効にした場合、DURABLE COMMIT ONを設定します。RETURN RECEIPTブロッキングを無効にすると、コミットが永続的にディスクにコミットされ、冗長性が提供されます。

Command> CREATE ACTIVE STANDBY PAIR
> master1,
> master2
> RETURN RECEIPT
> STORE master1
> DISABLE RETURN ALL 5
> DURABLE COMMIT ON
> RESUME RETURN 8;

例4-21 クラシック・レプリケーション・スキームでのDURABLE COMMIT ON

DISABLE RETURN ALLポリシーを設定してすべてのサブスクライバのRETURN RECEIPTブロッキングを無効にした場合、DURABLE COMMIT ONを設定します。RETURN RECEIPTブロッキングを無効にすると、コミットが永続的にディスクにコミットされ、冗長性が提供されます。

CREATE REPLICATION myscheme
ELEMENT e TABLE tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber ON "server2",
subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
DISABLE RETURN ALL 5
DURABLE COMMIT ON
RESUME RETURN 8;

LOCAL COMMIT ACTION

RETURN TWOSAFEサービスを使用している場合、LOCAL COMMIT ACTIONを設定して、タイムアウト時のアクティブ・レプリケーション・エージェントまたはマスター・レプリケーション・エージェントの応答方法を指定できます。ttRepSyncSet組込みプロシージャのlocalActionパラメータを使用して、特定のトランザクションに対するこの設定を無効にすることができます。

TWOSAFEトランザクションのレプリケーション中にタイムアウトを受信した場合に、実行可能なアクションは次のとおりです。

- COMMIT: タイムアウト時、コミット関数はcommitを実行して、トランザクションをローカルに終了しようとします。同じトランザクション上でこれ以上の処理を行うことはできません。

- NO ACTION: タイムアウト発生時、コミット関数はアプリケーションに返され、トランザクションはコミット・コールを入力したときと同じ状態のままになりますが、アプリケーションはレプリケートされた表を更新できません。アプリケーションはコミットを再発行できます。これはデフォルトです。

コールしてエラーが返された場合は、「RETURNサービス・トランザクションのステータスの確認」で説明されているttRepXactStatusプロシージャを使用して、トランザクションのステータスを確認できます。エラーに応じて、アプリケーションで次のいずれかの処理を選択できます。

- コミット・コールの再発行: この処理は、RETURN TWOSAFEレプリケーション・サイクル全体を繰り返すため、サブスクライバでのレプリケートされたコミットの成功または失敗が認識された場合、またはタイムアウト時間に達した場合にコミット・コールが返されます。

- トランザクションのロールバック: コールしてスタンバイまたはサブスクライバでのトランザクションの適用に関するエラー(主キー検索障害など)が返された場合は、アクティブまたはマスターでトランザクションをロールバックできます。

レプリケート表の列定義オプション

レプリケーション・スキームに含まれるレプリケート表の列の定義は、必ずしも同一である必要はありません。

- TABLE DEFINITION CHECKING値がEXACTに設定されている場合、列の定義は、アクティブ・データベースとスタンバイ・データベースの間で同一である必要があります。この属性は、物理構造が同一の表のレプリケーションを可能にします。

- TABLE DEFINITION CHECKING値がRELAXED (デフォルト)に設定されている場合、レプリケート表の列の定義は、同一である必要はありません。RELAXED属性を使用する場合、レプリケート表に同じキー定義、列数、列名および列のデータ型が必要です。
表定義チェックが、スタンバイ・データベースで発生します。アクティブ・データベースとスタンバイ・データベースの両方に対してこの属性をRELAXEDに設定しても、スタンバイ・データベースのみにこの属性値を設定した場合と同じ効果となります。

注意:
TABLE DEFINITION CHECKINGの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE ACTIVE STANDBY PAIRに関する説明またはCREATE REPLICATIONに関する説明を参照してください。

TABLE DEFINITION CHECKING RELAXED属性では、両方のマスター・データベースで表の物理的構造が同じである必要はありません。たとえば、表の列の順序が異なっていたり、表のパーティション数が異なる場合は、データをレプリケートできるのは、RELAXED属性を使用した場合です。このため、列を追加または削除して表を変更する場合、RELAXED属性を使用する必要があります。『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER TABLE」に示すとおり、表の変更時に列を追加すると、追加のパーティションが作成されます。列を削除しても、自動的に領域が解放されることはありません。表を変更するDML文は、マスターで実行された後、スタンバイ・データベースおよびサブスクライバにレプリケートされるようにすることをお薦めします。

異なる物理構造を補っている場合、RELAXED設定によってパフォーマンスがわずかに低下する可能性があります。表の物理構造が同じ場合は、パフォーマンスへの影響はありません。ttMigrate -r -relaxedUpgrade (表定義チェックがRELAXEDに設定されたデータベースでのみ有効)を使用して、表のすべての追加パーティションを1つのパーティションに結合し、削除された列によって発生した余分な領域をなくすことによって、パフォーマンスの問題(異なる物理構造、追加のパーティションまたは余分な領域によるもの)は排除できます。レプリケーション・スキームに含まれるすべてのデータベースでこれを行うと、結果として物理構造が同じになるため、パフォーマンスを最大にすることができます。

注意:
各表で使用する場合のパーティションの確認方法については、例4-18および『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』の表のパーティション数の確認に関する説明を参照してください。
TABLE DEFINITION CHECKINGのEXACTおよびRELAXED属性のパフォーマンスに関する考慮事項については、「レプリケートされる表を変更するときのパフォーマンスの考慮事項」を参照してください。

表定義チェックがRELAXEDに設定されていることを確認するには、アクティブ・データベースまたはマスター・データベースでレプリケーション・エージェントを停止した後、ALTER ACTIVE STANDBY PAIR文またはALTER REPLICATION文を実行して、表定義チェックをRELAXEDに設定します。最後に、ttRepAdmin -duplicateコマンドを使用して、これらの変更をスタンバイ・データベースとサブスクライバにロールアウトします。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のALTER ACTIVE STANDBY PAIR文に関する説明およびALTER REPLICATION文に関する説明を参照してください。

次の項では、表定義チェックをRELAXEDに設定する例を示します。

- 表定義チェックをRELAXEDに設定して表をレプリケートするアクティブ・スタンバイ・ペアの例

- 表定義チェックをRELAXEDに設定したクラシック・レプリケーション・スキームの例

表定義チェックをRELAXEDに設定して表をレプリケートするアクティブ・スタンバイ・ペアの例

次の例は、アクティブ・スタンバイ・ペアのレプリケーション・スキームでTABLE DEFINITION CHECKING属性をEXACTまたはRELAXEDのいずれかに設定した場合の影響を示します。

例4-22 アクティブ・スタンバイ・ペアで同一の表のレプリケーション

master1データベースに表t1を作成します。

CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c INT);

アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。master2スタンバイ・データベースに対して、TABLE DEFINITION CHECKINGをEXACTに設定します。

Command> CREATE ACTIVE STANDBY PAIR master1, master2
> STORE master2 TABLE DEFINITION CHECKING EXACT;

残りの手順を実行してアクティブ・データベースをスタンバイ・データベースに複製し、レプリケーション・エージェントを両方のデータベースで起動して、アクティブ・データベースの状態を設定します(第2章「スタート・ガイド」参照)。

master1のt1に行を1つ挿入します。

Command> INSERT INTO t1 VALUES (4,5,6);
1 row inserted.

master2のt1の結果を確認します。

Command> SELECT * FROM t1;
< 4, 5, 6>
1 row found.

例4-23 アクティブ・スタンバイ・ペアで表定義チェックをRELAXEDに変更

アクティブ・スタンバイ・ペアのレプリケーション・スキームの表定義チェックをrelaxedに変更できます。まず、アクティブ・データベースを変更する前に、アクティブ・データベースのレプリケーション・エージェントを停止します。次のようにすると、dsn1アクティブ・データベースが変更されるため、表定義チェックはRELAXEDに設定されます。

ALTER ACTIVE STANDBY PAIR
ALTER STORE master1 SET TABLE DEFINITION CHECKING RELAXED;

実行が完了すると、複製によってスタンバイ・データベースに変更がロールアウトされます。最後に、複製によってサブスクライバに変更がロールアウトされます。

表定義チェックをRELAXEDに設定したクラシック・レプリケーション・スキームの例

次の例は、クラシック・レプリケーション・スキームでTABLE DEFINITION CHECKING属性をEXACTまたはRELAXEDのいずれかに設定した場合の影響を示します。

例4-24 クラシック・レプリケーション・スキームで同一の表のレプリケーション

dsn1データベースに表t1を作成します。

CREATE TABLE ttuser.t1 (a INT PRIMARY KEY, b INT, c INT);

ttuser.t1表をdsn2データベースに、dsn1データベースの表と完全に同じに作成します。

レプリケーション・スキームttuser.rep1を作成します。サブスクライバdsn2で、TABLE DEFINITION CHECKINGをEXACTに設定します。

CREATE REPLICATION ttuser.rep1
ELEMENT e1 TABLE ttuser.t1
MASTER dsn1
SUBSCRIBER dsn2
STORE dsn2 TABLE DEFINITION CHECKING EXACT;

両方のデータベースのレプリケーション・エージェントを起動します。dsn1のttuser.t1に行を1つ挿入します。

Command> INSERT INTO ttuser.t1 VALUES (4,5,6);
1 row inserted.

dsn2のttuser.t1の結果を確認します。

Command> SELECT * FROM ttuser.t1;
< 4, 5, 6>
1 row found.

例4-25 クラシック・レプリケーション・スキームで異なる位置にある列を持つ表のレプリケーション

dsn1データベースに表t1を作成します。

CREATE TABLE ttuser.t1 (a INT PRIMARY KEY, b INT, c INT);

dsn1データベースのttuser.t1の列とは異なる順番の列を持つ表ttuser.t1をdsn2データベースに作成します。両方の表で列名およびデータ型が同じであり、両方の表でaが主キーであることに注意します。

CREATE TABLE ttuser.t1 (c INT, a INT PRIMARY KEY, b INT);

レプリケーション・スキームttuser.rep1を作成します。サブスクライバdsn2で、TABLE DEFINITION CHECKINGをRELAXEDに設定します。

CREATE REPLICATION ttuser.rep1
ELEMENT e1 TABLE ttuser.t1
MASTER dsn1
SUBSCRIBER dsn2
STORE dsn2 TABLE DEFINITION CHECKING RELAXED;

両方のデータベースのレプリケーション・エージェントを起動します。dsn1のttuser.t1に行を1つ挿入します。

Command> INSERT INTO ttuser.t1 VALUES (4,5,6);
1 row inserted.

dsn2のttuser.t1の結果を確認します。

Command> SELECT * FROM ttuser.t1;
< 5, 6, 4 >
1 row found.

例4-26 クラシック・レプリケーション・スキームで異なるパーティション数を持つ表のレプリケーション

表を変更して列を追加すると、その後その新しい列を削除しても、表のパーティション数は増加します。TABLE DEFINITION CHECKINGをRELAXEDに設定すると、パーティションの数が異なる表をレプリケートできます。

dsn1に、列が2つある表ttuser.t3を作成します。

CREATE TABLE ttuser.t3 (a INT PRIMARY KEY, b INT);

dsn2に、列が1つあり、その列が主キーである表ttuser.t3を作成します。

CREATE TABLE ttuser.t3 (a INT PRIMARY KEY);

dsn2の表に列を追加します。これにより、パーティションの数は2つになりますが、dsn1の表のパーティションは1つです。

ALTER TABLE ttuser.t3 ADD COLUMN b INT;

両方のデータベースでレプリケーション・スキームを作成します。

CREATE REPLICATION reppart
ELEMENT e2 TABLE ttuser.t3
MASTER dsn1
SUBSCRIBER dsn2
STORE dsn2 TABLE DEFINITION CHECKING RELAXED;

両方のデータベースのレプリケーション・エージェントを起動します。dsn1のttuser.t3に行を1つ挿入します。

Command> INSERT INTO ttuser.t3 VALUES (1,2);
1 row inserted.

dsn2のttuser.t3の結果を確認します。

Command> SELECT * FROM ttuser.t3;
< 1, 2 >
1 row found.

例4-27 クラシック・レプリケーション・スキームで表定義チェックをRELAXEDに変更

クラシック・レプリケーション・スキームの表定義チェックをRELAXEDに変更できます。まず、マスター・データベースのレプリケーション・スキームを変更する前に、マスター・データベースのレプリケーション・エージェントを停止します。次のようにすると、dsn1マスター・データベースが変更されるため、表定義チェックはRELAXEDに設定されます。

ALTER REPLICATION reppart
ALTER STORE dsn1 SET TABLE DEFINITION CHECKING RELAXED;

実行が完了すると、複製によってスタンバイ・マスターに変更がロールアウトされます。最後に、複製によってサブスクライバに変更がロールアウトされます。

レプリケートの通信量の圧縮

低帯域幅のネットワークを介してレプリケーションを行う場合、または大量のデータのレプリケーションを行う場合は、レプリケーションに必要な帯域幅の量を減らすCOMPRESS TRAFFIC属性を設定できます。COMPRESS TRAFFIC属性を使用すると、CREATE ACTIVE STANDBY PAIR文、ALTER ACTIVE STANDBY PAIR文、CREATE REPLICATION文またはALTER REPLICATION文のSTOREパラメータで指定されたデータベースからレプリケートされたデータが圧縮されます。TimesTenでは、他のデータベースからの通信量は圧縮されません。

圧縮アルゴリズムは速度に関しては最適化されますが、COMPRESS TRAFFIC属性を有効にすると、レプリケーションのスループットおよび待機時間に影響を与えます。

例4-28 アクティブ・スタンバイ・ペアのアクティブ・データベースからの通信量の圧縮

たとえば、アクティブ・データベースdsn1からのレプリケートの通信量は圧縮し、スタンバイ・データベースdsn2からのレプリケートの通信量は圧縮しない場合、CREATE ACTIVE STANDBY PAIR文は次のようになります。

CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2"
SUBSCRIBER dsn3 ON "host3"
STORE dsn1 ON "host1" COMPRESS TRAFFIC ON;

例4-29 アクティブ・データベースとスタンバイ・データベースの両方からの通信量の圧縮

dsn1およびdsn2のデータベースからのレプリケートの通信量を圧縮するには、次のように入力します。

CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2"
SUBSCRIBER dsn3 ON "host3"
STORE dsn1 ON "host1" COMPRESS TRAFFIC ON
STORE dsn2 ON "host2" COMPRESS TRAFFIC ON;

例4-30 クラシック・レプリケーション・スキームで1つのデータベースからの通信量の圧縮

データベースdsn1からのレプリケートの通信量は圧縮し、dsn2からのレプリケートの通信量は圧縮しない場合、CREATE REPLICATION文は次のようになります。

CREATE REPLICATION repscheme
ELEMENT d1 DATASTORE
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT d2 DATASTORE
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 COMPRESS TRAFFIC ON;

例4-31 クラシック・レプリケーション・スキームで両方のデータベース間の通信量の圧縮

dsn1とdsn2のデータベース間でのレプリケートの通信量を圧縮するには、次のように入力します。

CREATE REPLICATION scheme
ELEMENT d1 DATASTORE
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT d2 DATASTORE
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 COMPRESS TRAFFIC ON
STORE dsn2 ON host2 COMPRESS TRAFFIC ON;

ポート割当て

CREATE ACTIVE STANDBY PAIR文およびCREATE REPLICATION文のSTORE属性に対するPORTパラメータは、別のデータベースから更新をリスニングするためにデータベースにより使用されるポート番号を設定します。

- アクティブ・スタンバイ・ペアでは、スタンバイ・データベースは、アクティブ・データベースからの更新をリスニングします。読取り専用サブスクライバは、スタンバイ・データベースからの更新をリスニングします。

- クラシック・レプリケーション・スキームでは、サブスクライバは、マスター・データベースからの更新をリスニングします。1つのクラシック・レプリケーション・スキームにPORT属性を設定すると、すべてのクラシック・レプリケーション・スキームにその設定が適用されます。

静的ポートの割当てをお薦めします。PORT属性を設定しない場合、TimesTenデーモンが動的にポートを選択します。ポートがレプリケーション・エージェントに動的に割り当てられる場合は、TimesTenデーモンのポートも一致させる必要があります。

注意:
オンラインによるアップグレードを行う場合は、静的ポートを割り当てる必要があります。

ポートを静的に割り当てる場合は、STORE属性に完全なホスト名、DSNおよびポートを指定する必要があります。

例4-32 アクティブ・スタンバイ・ペアに対する静的ポートの割当て

CREATE ACTIVE STANDBY PAIR dsn1 ON "host1", dsn2 ON "host2"
SUBSCRIBER dsn3 ON "host3"
STORE dsn1 ON "host1" PORT 16080
STORE dsn2 ON "host2" PORT 16083
STORE dsn3 ON "host3" PORT 16084;

例4-33 クラシック・レプリケーション・スキームに対する静的ポートの割当て

CREATE REPLICATION repscheme
ELEMENT el1 TABLE ttuser.tab
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT el2 TABLE ttuser.tab
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
STORE dsn1 ON host1 PORT 16080
STORE dsn2 ON host2 PORT 16083;

リモート・レプリケーション・エージェントからの応答の待機タイムアウトの設定

TIMEOUT STORE属性は、レプリケーション・エージェントがリモート・レプリケーション・エージェントからの応答を待機する最大秒数を設定します。

大規模なトランザクションがある場合は、デフォルトのタイムアウト(120秒)を使用することをお薦めします。レプリケーション・エージェントは、リモート・レプリケーション・エージェントからの応答の遅延の原因となる可能性のある大規模なトランザクションに対応するために、トランザクションのサイズに基づいてタイムアウトをスケーリングします。ユーザーがTIMEOUTを60秒以下に設定している場合、レプリケーション・エージェントによる自動スケーリングは無効になっています。

注意:
何度もタイムアウトが発生し、エラー・ログに多数のトランスミッタおよびレシーバ・スレッドの再開始が記録されていた場合は、レプリケーション・エージェントが現在のタイムアウト値でスケーリングできるよりもトランザクションが大きい可能性があります。トランザクションに対してレプリケーションを進行できるようになるまで、タイムアウト値を増やしてください。

次の例では、マスター・データベースがrep1およびrep2であるアクティブ・スタンバイ・ペアを作成します。サブスクライバrep3が1つあります。レプリケーションのタイプはRETURN RECEIPTです。また、この文では、PORTおよびTIMEOUT属性をマスター・データベースに対して設定します。アクティブ・マスターとスタンバイ・マスターの両方で、TIMEOUT属性は80秒に設定されます。

CREATE ACTIVE STANDBY PAIR rep1, rep2 RETURN RECEIPT
SUBSCRIBER rep3
STORE rep1 PORT 21000 TIMEOUT 80
STORE rep2 PORT 22000 TIMEOUT 80;

トランザクション・ログ障害しきい値の設定

しきい値を設定することができ、この値を超えると、次に示すように、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なデータベースがfailed状態に設定されます。

- アクティブ・スタンバイ・ペアでは、トランザクション・ログのしきい値を超えると、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なスタンバイ・データベースまたは読取り専用サブスクライバがfailed状態に設定されます。CREATE ACTIVE STANDBY PAIR文またはALTER ACTIVE STANDBY PAIR文のSTORE句にFAILTHRESHOLD値を指定して、トランザクション・ログのしきい値を設定します。
アクティブ・データベースは、スタンバイ・データベースまたは読取り専用サブスクライバ・データベースをfailed状態に設定すると、障害が発生したデータベースのすべてのデータをトランザクション・ログから削除し、障害が発生したデータベースにメッセージを送信します。アクティブ・レプリケーション・エージェントが障害の発生したデータベースのレプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。

- クラシック・レプリケーション・スキームでは、トランザクション・ログのしきい値を超えると、使用可能なトランザクション・ログ領域を使い果たす前に、使用不可能なサブスクライバがfailed状態に設定されます。CREATE REPLICATION文またはALTER REPLICATION文のSTORE句にFAILTHRESHOLD値を指定して、トランザクション・ログのしきい値を設定します。例は、例9-5を参照してください。
マスター・データベースは、サブスクライバ・データベースをfailed状態に設定すると、障害が発生したサブスクライバのすべてのデータをトランザクション・ログから削除し、障害が発生したサブスクライバ・データベースにメッセージを送信します。マスター・レプリケーション・エージェントでサブスクライバ・レプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。

ただし、サブスクライバは、双方向レプリケーションの場合または他のサブスクライバに更新を伝播するように構成されている場合、マスターからメッセージを受信すると、レプリケーションの状態が損なわれたために、それ以上更新を送信しません。

デフォルトのしきい値は0(ゼロ)で、「制限なし」を意味します。トランザクション・ログ障害のしきい値の詳細は、「ロギングの接続属性の設定」を参照してください。

障害が発生したデータベースに接続中のアプリケーションは、データベースがレプリケーション・ピアによってfailedとマークされたことを示すtt_ErrReplicationInvalid(8025)警告を受信します。データベースにその障害状態が通知されると、アクティブ・データベースまたはマスター・データベースでのその状態はfailedからstopに変更されます。

注意:
データベースの状態の詳細は、表11-1「データベースの状態」を参照してください。

アプリケーションでは、ODBCのSQLGetInfo関数を使用して、アプリケーションが接続しているデータベースがfailed状態に設定されているかどうかを確認できます(「サブスクライバの障害」を参照)。

競合への対応としてのクラシック・レプリケーションの一時停止と再開

クラシック・レプリケーションでは、CONFLICT REPORTING SUSPEND属性を使用して、1秒当たりのレプリケーション競合数を表レベルで指定できます。競合数がこの数に到達すると、競合レポート処理が一時停止されます。また、CONFLICT REPORTING RESUME属性を使用して、競合レポート処理が再開する1秒当たりのレプリケーション競合数を指定できます。完全な説明は、第13章「レプリケーション競合の解消」を参照してください。

ネットワークの構成

次の各項ではネットワークを介してTimesTenデータをレプリケートする際に考慮すべきいくつかの問題について説明します。

- ネットワーク帯域幅要件

- WAN環境でのレプリケーション

- ROUTE句を使用したネットワーク・インタフェースの構成

- ROUTE句を使用しない場合のネットワーク・インタフェースの構成

- レプリケート・データベースのローカル・ホストの識別

ネットワーク帯域幅要件

TimesTenレプリケーションに必要なネットワーク帯域幅は、レプリケートしているデータの量および頻度によって異なります。ここでは、データ範囲の上位と下位、およびTimesTenデータベース間でデータをレプリケートするために必要なネットワーク帯域幅を特徴付けるトランザクションのタイプについて説明します。

表4-1は、レプリケート・レコードのサイズを計算するためのガイドラインを示しています。

表4-1 レプリケート・レコードのサイズ

レコード・タイプ

サイズ

開始トランザクション

48バイト

更新

116バイト

＋18バイト(更新された列ごとに)

＋古い列値のサイズ

＋新しい列値のサイズ

＋主キーまたは一意キーのサイズ

削除

104バイト

＋主キーまたは一意キーのサイズ

挿入

104バイト

＋主キーまたは一意キーのサイズ

＋挿入された行のサイズ

トランザクションはレプリケート対象のデータベース間をバッチで送信されます。マスター・データベースのトランザクション・ログ・バッファにデータがなくなった場合、または現在のバッチがほぼ256KBである場合にバッチが作成されます。詳細は、「データベース間の更新のコピー」を参照してください。

WAN環境でのレプリケーション

TimesTenレプリケーションでは、TCP/IPプロトコルを使用していますが、このプロトコルはWAN環境用には最適化されていません。WANでのレプリケーションのパフォーマンスは、サードパーティのTCPスタック製品を使用して向上できます。TCPスタックの交換を実行できない場合は、CREATE ACTIVE STANDBY PAIR文またはCREATE REPLICATION文にCOMPRESS TRAFFIC属性を設定して、TCP/IPプロトコルで処理する必要があるネットワーク通信量を削減します。詳細は、「レプリケートの通信量の圧縮」を参照してください。

パフォーマンスを向上させるためにTCP/IPカーネル・パラメータを変更する方法の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のAIXの前提条件に関する説明またはLinuxの前提条件に関する説明で、AIXプラットフォームまたはLinuxプラットフォームについてのインストール情報を参照してください。

ROUTE句を使用したネットワーク・インタフェースの構成

レプリケーション・スキームでは、データベースが存在するホストの名前を指定する必要があります。そのホスト名は、オペレーティング・システムによって1つ以上のIPアドレスに変換されます。

レプリケーション要素でデータベースのホストを指定する場合は、hostnameコマンドによって返される名前を常に使用する必要があります(レプリケーションでは、それと同じホスト名を使用して、現在のホストがレプリケーション・スキームに含まれていることを確認するためです)。現在のホストが含まれないレプリケーション・スキームは作成できません。

データベース名を指定するときに、オペレーティング・システムのhostnameコマンドが返すホスト名を指定する必要はありますが、ROUTE句を使用することで、別のインタフェース(デフォルト以外)でトラフィックを送受信するようにレプリケーションを構成できます。

ホストに(IPアドレスが異なる)複数のネットワーク・インタフェースがある場合は、レプリケーションでデフォルトのインタフェースを使用しないかぎり、使用するインタフェースをROUTE句で指定する必要があります。また、各インタフェースに対して優先順位を指定する必要もあります。レプリケーションでは、まず優先順位が最も高いアドレスを使用して接続が試行され、その接続を確立できなかった場合は、接続が確立されるまで優先順に残りのアドレスが試されます。あるIPアドレスを使用しているときにホストへの接続が失敗すると、ROUTE句で複数のアドレスが指定されている場合は、別のIPアドレスへの再接続(フォールバック)が試行されます。

ROUTE句の構文は次のようになります。

ROUTE MASTER FullDatabaseName SUBSCRIBER FullDatabaseName
{{MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost}
PRIORITY Priority} [...]

注意:
ROUTE句のアドレスは、ホスト名またはIPアドレスのいずれかとして指定できます。ただし、あるホスト名に対して複数のIPアドレスが構成されているホストの場合は、意図したIPアドレスのみをレプリケーションで確実に使用するために、IPアドレスを使用してROUTE句を構成する必要があります。

- アクティブ・スタンバイ・ペアでROUTE句を使用する場合、各マスター・データベースは他のマスター・データベースのサブスクライバであり、各読取り専用サブスクライバは両方のマスター・データベースのサブスクライバです。これは、両方のディレクトリに1つのルートを指定するには、CREATE ACTIVE STANDBY PAIR文に2の倍数でROUTE句が含まれている必要があることを意味します。

- 二重のマスターを定義するクラシック・レプリケーション・スキームでROUTE句を使用する場合、各マスター・データベースはもう1つのマスター・データベースのサブスクライバになります。これは、両方のディレクトリに1つのルートを指定するには、CREATE REPLICATION文に2の倍数でROUTE句が含まれている必要があることを意味します。

例4-34 アクティブ・スタンバイ・ペアに対する複数ネットワーク・インタフェースの構成

ホストhost1にはホスト名host1fastでアクセス可能な2つ目のインタフェースが構成されており、host2にはIPアドレス192.168.1.100でアクセス可能な2つ目のインタフェースが構成されている場合、次のようにすると、2つ目のインタフェースをレプリケーション・スキームで使用するように指定できます。

CREATE ACTIVE STANDBY PAIR dns1, dsn2
ROUTE MASTER dsn1 ON "host1" SUBSCRIBER dsn2 ON "host2"
MASTERIP "host1fast" PRIORITY 1
SUBSCRIBERIP "192.168.1.100" PRIORITY 1
ROUTE MASTER dsn2 ON "host2" SUBSCRIBER dsn1 ON "host1"
MASTERIP "192.168.1.100" PRIORITY 1
SUBSCRIBERIP "host1fast" PRIORITY 1;

例4-35 クラシック・レプリケーション・スキームに対する複数ネットワーク・インタフェースの構成

ホストhost1にはホスト名host1fastでアクセス可能な2つ目のインタフェースが構成されており、host2にはIPアドレス192.168.1.100でアクセス可能な2つ目のインタフェースが構成されている場合、次のようにすると、2つ目のインタフェースをレプリケーション・スキームで使用するように指定できます。

CREATE REPLICATION repscheme
ELEMENT e1 TABLE ttuser.tab
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ELEMENT e2 TABLE ttuser.tab
MASTER dsn2 ON host2
SUBSCRIBER dsn1 ON host1
ROUTE MASTER dsn1 ON host1 SUBSCRIBER dsn2 ON host2
MASTERIP host1fast PRIORITY 1
SUBSCRIBERIP "192.168.1.100" PRIORITY 1
ROUTE MASTER dsn2 ON host2 SUBSCRIBER dsn1 ON host1
MASTERIP "192.168.1.100" PRIORITY 1
SUBSCRIBERIP host1fast PRIORITY 1;

また、インタフェースが複数あるレプリケーション・ホストでは、プライマリ・インタフェースに障害が発生したり、そのインタフェースと受信ホストとの間の接続が切断した場合に備えて、1つ以上のインタフェースをバックアップとして使用するようにレプリケーションを構成できます。ROUTE句を使用すると、それぞれのマスターおよびサブスクライバに対して複数のインタフェースを指定し、優先順位に従ってレプリケーションで使用することができます。

マスター・ホストのレプリケーションが、優先順位の最も高いMASTERIPにバインドできなかった場合は、次の優先順位のMASTERIPアドレスを使用して接続が試行されます。ただし、サブスクライバへの接続がなんらかの理由で失敗した場合は、次に優先順位の高いMASTERIPアドレスを試す前に、それぞれのSUBSCRIBERIPアドレスを優先順に使用して接続が試行されます。

例4-36 アクティブ・スタンバイ・ペアに対するネットワーク優先順位の構成

ホストhost1に2つのネットワーク・インタフェース(IPアドレスは192.168.1.100と192.168.1.101)が構成され、ホストhost2に2つのインタフェース(IPアドレスは192.168.1.200と192.168.1.201)が構成されている場合は、まずIPアドレス192.168.1.100と192.168.1.200を使用してトラフィックの送受信を行い、その接続に障害が発生したときにIPアドレス192.168.1.101または192.168.1.201を試行するようにレプリケーションを設定できます。

CREATE ACTIVE STANDBY PAIR dns1, dns2
ROUTE MASTER dsn1 ON "host1" SUBSCRIBER dsn2 ON "host2"
MASTERIP "192.168.1.100" PRIORITY 1
MASTERIP "192.168.1.101" PRIORITY 2
SUBSCRIBERIP "192.168.1.200" PRIORITY 1
SUBSCRIBERIP "192.168.1.201" PRIORITY 2;

例4-37 クラシック・レプリケーション・スキームに対するネットワーク優先順位の構成

ホストhost1に2つのネットワーク・インタフェース(IPアドレスは192.168.1.100と192.168.1.101)が構成され、ホストhost2に2つのインタフェース(IPアドレスは192.168.1.200と192.168.1.201)が構成されている場合は、まずIPアドレス192.168.1.100と192.168.1.200を使用してトラフィックの送受信を行い、その接続に障害が発生したときにIPアドレス192.168.1.101または192.168.1.201を試行するようにレプリケーションを設定できます。

CREATE REPLICATION repscheme
ELEMENT e TABLE ttuser.tab
MASTER dsn1 ON host1
SUBSCRIBER dsn2 ON host2
ROUTE MASTER dsn1 ON host1 SUBSCRIBER dsn2 ON host2
MASTERIP "192.168.1.100" PRIORITY 1
MASTERIP "192.168.1.101" PRIORITY 2
SUBSCRIBERIP "192.168.1.200" PRIORITY 1
SUBSCRIBERIP "192.168.1.201" PRIORITY 2;

ROUTE句を使用しない場合のネットワーク・インタフェースの構成

次の各項では、ROUTE句を使用しない場合に、各ホストについて正しいホスト名とIPアドレスを使用するようにレプリケーションを構成する方法について説明します。

- UNIX上にあるデータベース・ホストのROUTE句を使用しない指定

- Windowsでのホスト名の解決

- TimesTenデーモンおよびサブデーモンのユーザー指定アドレス

UNIX上にあるデータベース・ホストのROUTE句を使用しない指定

データベース・ホストと、レプリケーションに使用するネットワーク・インタフェースを指定するには、可能な場合は、レプリケーション・スキームのROUTE句を使用する必要があります。ただし、この項では、ROUTE句を使用しないレプリケーション・スキームがある場合に、複数のネットワーク・インタフェースを持つレプリケーション・ホストのオペレーティング・システムおよびDNSファイルを構成する方法について説明します。

ホストに(IPアドレスが異なる)複数のネットワーク・インタフェースがあり、レプリケーションがROUTE句で構成されていない場合、TimesTenレプリケーションでは、gethostbynameコールによって返される順序と同じ順序でIPアドレスへの接続が試行されます。最初のアドレスを使用して接続が試行され、その接続を確立できなかった場合は、接続が確立されるまで順番に残りのアドレスが試行されます。TimesTenレプリケーションでは、ホストへの新しい接続を確立するたびに、この同じ順序が使用されます。あるIPアドレスでホストへの接続が失敗すると、前述の方法と同じ方法でホストの別のIPアドレスへの再接続(フォールバック)が試行されます。

UNIXプラットフォームで複数のIPアドレスを使用するようにホストを構成する方法には、DNSまたは/etc/hostsファイルの2つの基本的な方法があります。

注意:
ネットワーク・インタフェース・カード(NIC)が複数ある場合は、/etc/host.confファイルでmulti onを指定してください。指定しないと、gethostbynameは複数のアドレスを返すことができません。

たとえば、マシンに2つのNICがある場合は、/etc/hostsファイルに次の構文を使用します。

127.0.0.1  localhost
IP_address_for_NIC_1  official_hostname optional_alias
IP_address_for_NIC_2  official_hostname optional_alias

ホスト名official_hostnameは、hostnameコマンドによって返される名前です。

/etc/hostsファイルを編集する場合は、次のことに注意してください。

- /etc/hostsファイルを変更するには、rootとしてログインする必要があります。

- 1つのIPアドレスにつき使用できるのは1行のみです。

- 各行には複数の別名を含めることができます。

- 同じホスト名に対して複数のIPアドレスがある場合、IPアドレスは連続した行に入力する必要があります。

- ホスト名は最大30文字です。

たとえば、UNIXプラットフォームにある/etc/hostsファイルの次のエントリは、2つのIPアドレスがあるHost1というサーバーを示します。

127.0.0.1        localhost
10.10.98.102     Host1
192.168.1.102    Host1

DNSに同じ構成を指定する場合、ドメイン・ゾーン・ファイルに次のように入力します。

Host1     IN     A     10.10.98.102
IN     A     192.168.1.102

いずれの場合も、レプリケーション・スキームでホスト名としてHost1を指定するだけで、レプリケーションでは接続の確立時に最初の使用可能なIPアドレスが使用されます。

複数のIPアドレスが使用される環境では、レプリケーション接続を特定のIPアドレスに制限するために、1つのIPアドレスに複数のホスト名を割り当てることもできます。たとえば、/etc/hostsファイルに次のように入力できます。

127.0.0.1        localhost
10.10.98.102     Host1
192.168.1.102    Host1 RepHost1

または、DNSゾーン・ファイルに次のように入力できます。

Host1     IN     A     10.10.98.102
IN     A     192.168.1.102
RepHost1  IN     A     192.168.1.102

レプリケーション接続をこのホストのIPアドレス192.168.1.102に制限する場合は、レプリケーション・スキームにホスト名としてRepHost1を指定できます。別の方法として、レプリケーション・スキームの構成に使用するCREATE ACTIVE STANDBY PAIR文またはCREATE REPLICATION文で、ホスト名として単にIPアドレスを指定する方法をあげることができます。

Windowsでのホスト名の解決

レプリケーション構成がIPアドレスではなくホスト名で指定されている場合、レプリケーションではピアのホスト名をIPアドレスに変換できる必要があります。Windowsでこれを効率的に行うには、ネットワーク上のホストに関する正確な情報を持つ有効なWINSサーバーまたは有効なDNSサーバーのいずれかを問い合せるようにWindowsマシンを設定する必要があります。このようなサーバーがない場合、次のいずれかの方法で静的なhost-to-IPエントリを入力できます。

%windir%\system32\drivers\etc\hosts

または、

%windir%\system32\drivers\etc\lmhosts

これらのオプションを指定しなかった場合、Windowsマシンはブロードキャスト(非常に低速)を実行してピア・ノードを検出します。

また、Windowsマシンで定義済のWINSサーバーまたはDNSサーバーと通信できない場合、またはホスト名の解決がこれらのサーバーで正しく設定されていない場合は、ホスト名の解決に非常に時間がかかる場合があります。pingコマンドを使用して、ホストを効率的に検出できるかどうかをテストします。pingコマンドのレスポンスは、ホスト名の解決が適切に設定されている場合はすぐに返されます。

注意:
レプリケーション・スキームでのデータベース・ホストの指定は一貫している必要があります。あるデータベースにIPアドレスを使用してホストを指定した後、同じデータベースまたは別のデータベースにそのホスト名は使用しないでください。

TimesTenデーモンおよびサブデーモンのユーザー指定アドレス

デフォルトでは、TimesTenのメイン・デーモン、すべてのサブデーモン、およびすべてのエージェントは、使用可能な任意のアドレスを使用してソケット上でリクエストをリスニングします。ttendaemon.optionsファイルを変更して-listenaddrオプションを設定すると、エージェントとデーモン間の通信用アドレスを指定できます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモン・オプションの管理に関する説明を参照してください。

マシンに2つのNICがあり、NICのアドレスがそれぞれ10.10.10.100と10.10.11.200であるとします。ループバック・アドレスは127.0.0.1です。ループバック・アドレスをレプリケーション・エージェントに適用する場合は次のことに注意してください。

- ttendaemon.optionsファイルに-listenaddrオプションを設定しない場合は、すべてのプロセスでデーモンおよびエージェントと対話できます。

- -listenaddrを10.10.10.100に設定した場合、ローカル・ホストのすべてのプロセスまたは10.10.10ネットで、10.10.10.100のデーモンおよびエージェントと対話できます。10.10.11ネット上のプロセスでは、10.10.10.100のデーモンおよびエージェントと対話できません。

- -listenaddrを127.0.0.1に設定した場合、ローカル・ホストのプロセスのみでデーモンおよびエージェントと対話できます。他のホストのプロセスでは、デーモンおよびエージェントと対話できません。

レプリケート・データベースのローカル・ホストの識別

通常、TimesTenレプリケーションでは、レプリケーション構成に含まれるホストは、オペレーティング・システムの一般的なホスト名の解決方法で識別できます。ただし、ホスト名の構成が一般的でない場合、レプリケーション・スキームに指定されたホスト名とローカル・ホストが一致しているかどうかをTimesTenで判別できないことがまれにあります。このような状態でttRepStartまたはttAdmin -repStartを使用してレプリケーションを開始しようとすると、エラー8191「This store is not involved in a replication scheme」を受信することになります。この場合は、ttHostNameSet組込みプロシージャを使用して、現在のデータベースが、レプリケーション・スキームで指定されているデータベースであることをTimesTenに明示的に示すことができます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttHostNameSetに関する説明を参照してください。

5 キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの管理

この章では、キャッシュ・グループをレプリケートしないアクティブ・スタンバイ・ペアを管理する方法について説明します。キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアの管理については、第6章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

フェイルオーバーとリカバリの自動管理については、第8章「Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理」を参照してください。

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

- キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定

- アクティブ・データベースの障害からのリカバリ

- スタンバイ・データベースの障害からのリカバリ

- アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ

- サブスクライバ・データベースの障害からのリカバリ

- アクティブ・データベースとスタンバイ・データベースの役割の入替え

- 二重のアクティブ・データベースの検出

キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定

アクティブ・スタンバイ・ペアを設定するには、この項のタスクを実行します。例については、「1つのサブスクライバを持つアクティブ・スタンバイ・ペアの構成」を参照してください。

注意:
読取り専用キャッシュ・グループまたはASYNCHRONOUS WRITETHROUGH (AWT)キャッシュ・グループをレプリケートする場合は、第6章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

データベースを作成する前に、次の項の情報を参照してください。

- 「ネットワークの構成」

- 「レプリケート・データベースの接続属性」

- 「レプリケート・データベースでのトランザクション・ログの管理」

1. データベースを作成します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明を参照してください。

2. CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション・スキームを作成します。第3章「アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義」を参照してください。

3. アクティブ・データベースでttRepStateSet('ACTIVE')をコールします。

4. レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

5. アクティブ・データベースでユーザーを作成し、そのユーザーにADMIN権限を付与します。

6. アクティブ・データベースをスタンバイ・データベースに複製します。

7. スタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

8. スタンバイ・データベースがSTANDBY状態になるまで待機します。ttRepStateGet組込みプロシージャを使用して、スタンバイ・データベースの状態を確認します。

9. スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。

10. レプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

アクティブ・データベースの障害からのリカバリ

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

- スタンバイ・データベースが使用可能な場合のリカバリ

- 元のノードへのフェイルバック

スタンバイ・データベースが使用可能な場合のリカバリ

この項では、スタンバイ・データベースが使用可能で、アクティブ・データベースと同期されている場合にアクティブ・データベースをリカバリする方法について説明します。次のトピックが含まれています。

- レプリケーションがRETURN RECEIPTまたは非同期の場合

- レプリケーションがRETURN TWOSAFEの場合

レプリケーションがRETURN RECEIPTまたは非同期の場合

次のタスクを実行します。

1. 障害が発生したデータベースで、レプリケーション・エージェントがまだ停止されていない場合は停止します。

2. スタンバイ・データベースでttRepStateSet('ACTIVE')をコールします。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。

3. 新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')をコールします(ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです)。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。

4. 障害が発生したデータベースを破棄します。

5. 新しいアクティブ・データベースを新しいスタンバイ・データベースに複製します。

6. レプリケーション・エージェント・ポリシーを設定し、新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

スタンバイ・データベースは、アクティブ・データベースに通信します。アクティブ・データベースは、サブスクライバへの更新の送信を停止します。スタンバイ・データベースがアクティブ・データベースと完全に同期している場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。

注意:
スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。

レプリケーションがRETURN TWOSAFEの場合

次のタスクを実行します。

1. スタンバイ・データベースでttRepStateSet('ACTIVE')をコールします。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。

2. 新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')をコールします(ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです)。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。

3. 障害が発生したデータベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。データベースのリカバリが正常に行われなかったときは、レプリケーションがRETURN RECEIPTまたは非同期の場合のリカバリ方法の手順5から処理を続けてください。詳細は、「レプリケーションがRETURN RECEIPTまたは非同期の場合」を参照してください。

4. 障害が発生したデータベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

スタンバイ・データベースと完全に同期されているとアクティブ・データベースで判断された場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。

注意:
スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateSet組込みプロシージャを使用して確認できます。

元のノードへのフェイルバック

フェイルオーバーに成功した後、アクティブ・データベースおよびスタンバイ・データベースが元のノードに存在するようにフェイルバックする必要がある場合があります。詳細は、「アクティブ・データベースとスタンバイ・データベースの役割の入替え」を参照してください。

スタンバイ・データベースの障害からのリカバリ

スタンバイ・データベースの障害からリカバリするには、次のタスクを実行します。

1. スタンバイ・データベースの障害を検出します。

2. RETURN TWOSAFEサービスが有効になっている場合にスタンバイ・データベースで障害が発生すると、処理中のトランザクションはアクティブ・データベースでコミットされなくなり、エラー8170「Receipt or commit acknowledgement not returned in the specified timeout interval」が発生します。その場合は、localActionパラメータを2 (COMMIT)に設定してttRepSyncSet組込みプロシージャをコールし、トランザクションを再度コミットします。次に例を示します。

Command> call ttRepSyncSet( null, null, 2);
Command> commit;

3. アクティブ・データベースで、ttRepStateSave('FAILED','standby_database','host_name')をコールします。それ以後、スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。サブスクライバ・データベースは、アクティブから直接複製することもできます。

4. スタンバイ・データベースのレプリケーション・エージェントが自動的に再起動された場合は、レプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。

5. 次のいずれかの方法で、スタンバイ・データベースをリカバリします。

- スタンバイ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。

- アクティブ・データベースからスタンバイ・データベースを複製します。

スタンバイ・データベースが停止していた時間、およびアクティブ・データベースから適用する必要があるトランザクション・ログの量によって、使用するリカバリの方法が決まります。

6. レプリケーション・エージェント・ポリシーを設定し、新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

アクティブ・データベースで2つのマスター・データベースが同期していると判断し、サブスクライバへの更新の送信を停止すると、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。

注意:
スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。

アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ

次の例を考えてみます。

- スタンバイ・データベースで障害が発生しました。次に、スタンバイが再起動する前、またはスタンバイがアクティブ・データベースと同期される前に、アクティブ・データベースで障害が発生しました。

- アクティブ・データベースで障害が発生しました。スタンバイ・データベースがACTIVEになり、リカバリ・プロセスの残りが開始されます。(「アクティブ・データベースの障害からのリカバリ」を参照してください。)新しいスタンバイ・データベースが新しいアクティブ・データベースと完全に同期される前に、そのアクティブ・データベースで障害が発生しました。

両方の例で、スタンバイ・データベースの場合より多くの変更がサブスクライバに適用されている可能性があります。

アクティブ・データベースで障害が発生し、アクティブ・データベースから最後に送信された変更の一部のみがスタンバイ・データベースで適用された場合、リカバリの方法として次の2つの方法があります。

- ローカル・トランザクション・ログからアクティブ・データベースをリカバリする方法。

- ローカル・トランザクション・ログからスタンバイ・データベースをリカバリする方法。

いずれのデータベースが使用可能かまたはいずれのデータベースがより新しいかに応じて、使用する方法を選択します。

アクティブ・データベースのリカバリ

1. 障害が発生したアクティブ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。

2. 障害が発生したアクティブ・データベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

3. 新しくリカバリされたデータベースで、ttRepStateSet('ACTIVE')をコールします。

4. 「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定」の手順6を実行します。

スタンバイ・データベースのリカバリ

1. 障害が発生したスタンバイ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。

2. スタンバイ・データベースのレプリケーション・エージェントが自動的に再起動された場合は、そのレプリケーション・エージェントを停止する必要があります。「レプリケーション・エージェントの起動および停止」を参照してください。

3. DROP ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を削除します。

4. CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。

5. マスター・データベースで、ttRepStateSet('ACTIVE')をコールして、そのデータベースにACTIVEの役割を割り当てます。

6. レプリケーション・エージェント・ポリシーを設定し、新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

7. 「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定」の手順6から実行します。

サブスクライバ・データベースの障害からのリカバリ

サブスクライバ・データベースで障害が発生した場合は、次のいずれかの方法を使用してリカバリすることができます。

- 障害が発生したサブスクライバに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。レプリケーション・エージェントを起動し、サブスクライバによるキャッチアップを可能にします。

- スタンバイ・データベースからサブスクライバを複製します。

スタンバイ・データベースが停止しているか、またはリカバリ中の場合は、アクティブ・データベースからサブスクライバを複製します。

サブスクライバ・データベースがリカバリされた後、レプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

アクティブ・データベースとスタンバイ・データベースの役割の入替え

アクティブ・データベースの役割をスタンバイ・データベースに変更する場合、およびその逆の変更を実行する場合は、次の手順を実行します。

1. 現行のアクティブ・データベースで更新を生成しているすべてのアプリケーションを一時停止します。

2. 現行のスタンバイ・データベースのDSNおよびホストを入力パラメータとして使用して、アクティブ・データベースでttRepSubscriberWaitをコールします。成功すると<00>が返されます。これによって、すべての更新が現行のスタンバイ・データベースに送信されます。

3. 現行のアクティブ・データベースでレプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。

4. 現在のアクティブ・データベースでttRepDeactivateをコールします。これによって、このデータベースはIDLE状態になります。

5. 現在のスタンバイ・データベースで、ttRepStateSet('ACTIVE')をコールします。これによって、このデータベースがアクティブ・スタンバイ・ペアのアクティブ・データベースとして機能するようになります。

6. レプリケーション・エージェント・ポリシーを設定し、元のアクティブ・データベースでレプリケーション・エージェントを起動します。

7. ttRepStateGet組込みプロシージャを使用して、データベースの状態がIDLEからSTANDBYに変更されたタイミングを確認します。これによって、このデータベースがアクティブ・スタンバイ・ペアのスタンバイ・データベースとして機能するようになります。

8. 手順1で一時停止したアプリケーションを再開します。

二重のアクティブ・データベースの検出

通常、アクティブ・スタンバイ・ペアのアクティブ・データベースおよびスタンバイ・データベースの指定は、ユーザーによって明示的に制御されます。ただし、状況によっては、スタンバイ・データベースの役割をアクティブ・データベースに変更するときに、ユーザーがアクティブ・データベースとスタンバイ・データベースの両方を変更できない場合があります。

たとえば、アクティブ・データベースのサイトへのネットワーク通信が中断された場合、異なるサイトのスタンバイ・データベースがアクティブ・データベースの役割を引き継ぐ必要があるが、現行のアクティブ・データベースでのレプリケーションの停止やその役割の手動での変更ができないことがあります。最初にアクティブ・データベースでレプリケーションを停止せずにスタンバイ・データベースをアクティブに変更すると、両方のマスター・データベースがACTIVE状態となり、トランザクションを受け入れる状況となります。このような例では、TimesTenは、データベース間のネットワーク通信がリストアされたときに、マスター・データベースのアクティブ/スタンバイの役割を自動的に決定できます。

データベース間の初期ハンドシェイク中に、TimesTenでアクティブ・スタンバイ・ペアのレプリケーション・スキームのマスター・データベースが両方ともACTIVE状態であると判別された場合、自動的に次の処理が実行されます。

- ACTIVE状態に最後に設定されたデータベースはACTIVE状態のままにされ、アプリケーションへの接続状態が続き、アプリケーションによる更新も継続されます。

- 最初にACTIVE状態にされたデータベースは、無効化されます。すべてのアプリケーションの接続が切断されます。

- 無効化されたデータベースが再起動されると、TimesTenでは、他のマスター・データベースにレプリケートされていないトランザクションがデータベースで発生したかどうかが判別されます。このようなトランザクションが発生していた場合、それらのトランザクションはトラップされ、データベースはIDLE状態のままにされます。データベースをスタンバイ・データベースにするには、アクティブ・データベースから複製する必要があります。トラップされたトランザクションがない場合、データベースはスタンバイ・データベースとして使用でき、自動的にSTANDBY状態に設定されます。

6 キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理

表がアクティブ・スタンバイ・ペアで構成されている場合は、それらの表を読取り専用キャッシュ・グループまたはASYNCHRONOUS WRITETHROUGH (AWT)キャッシュ・グループのいずれかでレプリケートできます。

注意:
フェイルオーバーとリカバリの自動管理については、第8章「Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理」を参照してください。

次の項では、キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアの管理方法を説明します。

- キャッシュ・グループが構成されたアクティブ・スタンバイ・ペア

- 読取り専用キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定

- AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定

- レプリケーションで使用されるユーザー名またはパスワードの変更

- アクティブ・データベースの障害からのリカバリ

- スタンバイ・データベースの障害からのリカバリ

- アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ

- サブスクライバ・データベースの障害からのリカバリ

- アクティブ・データベースとスタンバイ・データベースの役割の入替え

- 二重のアクティブ・データベースの検出

- アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用

キャッシュ・グループが構成されたアクティブ・スタンバイ・ペア

読取り専用キャッシュ・グループまたはASYNCHRONOUS WRITETHROUGH (AWT)キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアでは、フェイルオーバーおよびリカバリの一環としてキャッシュ・グループの役割を自動的に変更できます。これにより、データの損失を最小限に抑えてキャッシュ・インスタンスの高可用性を実現できます。「AWTキャッシュ・グループのレプリケート」および「読取り専用キャッシュ・グループのレプリケート」を参照してください。

注意:
TimesTenでは、アクティブ・スタンバイ・ペアでのユーザー管理キャッシュ・グループまたはSYNCHRONOUS WRITETHROUGH (SWT)キャッシュ・グループのレプリケーションはサポートしていません。

AWTキャッシュ・グループのアクティブ・スタンバイ・レプリケーションを設定するときに、特別な障害時リカバリ読取り専用サブスクライバを作成することもできます。この特別なサブスクライバはリモートの障害時リカバリ・サイトに配置されており、(同様に障害時リカバリ・サイトに配置されている)2番目のOracle Databaseに更新を伝播できます。「アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用」を参照してください。

読取り専用キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定

この項では、読取り専用キャッシュ・グループ内のキャッシュ表をレプリケートするアクティブ・スタンバイ・ペアを設定する方法について説明します。この項で例として使用するアクティブ・スタンバイ・ペアは、キャッシュ・グリッド・メンバーではありません。

データベースを作成する前に、次の項の情報を参照してください。

- 「ネットワークの構成」

- 「レプリケート・データベースの接続属性」

- 「レプリケート・データベースでのトランザクション・ログの管理」

ローカルの読取り専用キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアを設定するには、次の手順を実行します。

1. Oracle Databaseでキャッシュ管理ユーザーを作成します。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseでのユーザーの作成に関する説明を参照してください。

2. データベースを作成します。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenデータベースでのDSNの作成に関する説明を参照してください。

3. ttCacheUidPwdSet組込みプロシージャをコールして、キャッシュ管理ユーザーのIDおよびパスワードを設定します。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenデータベースでのキャッシュ管理ユーザー名およびパスワードの設定に関する説明を参照してください。次に例を示します。

Command> call ttCacheUidPwdSet('orauser','orapwd');

4. データベースでキャッシュ・エージェントを起動します。ttCacheStart組込みプロシージャまたはttAdmin -cachestartユーティリティを使用します。

Command> call ttCacheStart;

5. CREATE CACHE GROUP文を使用して、読取り専用キャッシュ・グループを作成します。次に例を示します。

Command> CREATE READONLY CACHE GROUP readcache
> AUTOREFRESH INTERVAL 5 SECONDS
> FROM oratt.readtab
> (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));

6. AUTOREFRESH STATEがPAUSEDに設定されていることを確認します。キャッシュ・グループの作成後、デフォルトではAUTOREFRESH STATEはPAUSEDになっています。AUTOREFRESH STATEは、ttIsql cachegroupsコマンドを実行して確認できます。

Command> cachegroups;

7. CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション・スキームを作成します。
たとえば、master1およびmaster2がマスター・データベースとして定義され、sub1およびsub2がサブスクライバ・データベースとして定義されているとします。これらのデータベースは、node1、node2、node3およびnode4に存在しています。RETURNサービスはRETURN RECEIPTです。レプリケーション・スキームは、次のように指定できます。

Command> CREATE ACTIVE STANDBY PAIR master1 ON "node1", master2 ON "node2"
> RETURN RECEIPT
> SUBSCRIBER sub1 ON "node3", sub2 ON "node4"
> STORE master1 ON "node1" PORT 21000 TIMEOUT 30
> STORE master2 ON "node2" PORT 20000 TIMEOUT 30;

8. ttRepStateSet組込みプロシージャをアクティブ・データベース(master1)でコールして、レプリケーション状態をACTIVEに設定します。次に例を示します。

Command> call ttRepStateSet('ACTIVE');

9. master1にレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

10. LOAD CACHE GROUP文を使用してキャッシュ・グループをロードします。これにより、自動リフレッシュ・プロセスが開始されます。次に例を示します。

Command> LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS;

11. インスタンス管理者として、アクティブ・データベース(master1)をスタンバイ・データベース(master2)に複製します。-keepCGオプションを指定してttRepAdmin -duplicateユーティリティを使用し、キャッシュ・グループを保持します。ttRepDuplicateEx C関数を使用してデータベースを複製することもできます。「データベースの複製」を参照してください。ttRepAdminによって-uid、-pwd、-cacheuidおよび-cachepwdの値を入力するよう要求されます。

ttRepAdmin -duplicate -from master1 -host node1 -keepCG
-connStr "DSN=master2;UID=;PWD="

12. master2にレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

13. スタンバイ・データベースは自動的にSTANDBY状態になります。master2がSTANDBY状態になるまで待機します。master2の状態を確認するには、ttRepStateGet組込みプロシージャをコールします。次に例を示します。

Command> call ttRepStateGet;

14. ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、master2のキャッシュ・エージェントを起動します。次に例を示します。

Command> call ttCacheStart;

15. インスタンス管理者として、サブスクライバ(sub1およびsub2)をスタンバイ・データベース(master2)から複製します。ttRepAdmin -duplicateで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ表を通常のTimesTen表に変換します。ttRepAdminによって-uidおよび-pwdの値を入力するよう要求されます。「データベースの複製」を参照してください。次に例を示します。

ttRepAdmin -duplicate -from master2 -host node2 -nokeepCG
-connStr "DSN=sub1;UID=;PWD="

16. サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースのレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定

グローバルAWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定方法については、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ表のレプリケートに関する説明を参照してください。その説明でのアクティブ・スタンバイ・ペアは、キャッシュ・グリッド・メンバーになっています。

レプリケーションで使用されるユーザー名またはパスワードの変更

アクティブ・スタンバイ・ペアでは、TimesTenのユーザー名やパスワード、または(アクティブ・スタンバイ・ペアにキャッシュ・グループが構成されている場合は)TimesTenキャッシュ・マネージャ・ユーザー、そのコンパニオンOracleユーザー、またはキャッシュ管理ユーザーのユーザー名とパスワードのいずれかを変更できます。

DDLReplicationLevel接続属性が2以上の場合は、アクティブ・マスターで行われたユーザー名やパスワードの変更がスタンバイ・マスターおよびすべてのサブスクライバに自動的にレプリケートされます。DDLReplicationLevel接続属性が1の場合、アクティブ・マスターで行われたユーザー名やパスワードの変更はスタンバイ・マスターおよびすべてのサブスクライバに自動的にレプリケートされません。この場合、アクティブ・マスター、スタンバイ・マスター、そしてすべてのサブスクライバで各SQL文を手動で実行する必要があります。

注意:
DDLReplicationLevel接続属性の他の値についてどのDDL文が自動的にレプリケートされるかの詳細は、「アクティブ・スタンバイ・ペアのDDLの変更」を参照してください。

TimesTenユーザーのユーザー名やパスワード、またはアクティブ・スタンバイ・ペアにキャッシュ・グループが構成されている場合はTimesTenキャッシュ・マネージャ・ユーザー、そのコンパニオンOracleユーザー、またはキャッシュ管理ユーザーのユーザー名やパスワードを変更するには、次の手順を実行します。

1. TimesTenユーザーのパスワードを変更する場合は、アクティブ・マスター・データベースでALTER USER文を使用します。TimesTenユーザー名を変更する場合は、ユーザー名を削除して新しいユーザーを作成する前に、まずTimesTenユーザーが所有しているすべてのオブジェクトを削除する必要があります。
orattユーザーのパスワードを変更するには、次のコマンドを実行します。

注意:
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースでのユーザーの作成または指定に関する説明を参照してください。

Command> ALTER USER oratt IDENTIFIED BY newpwd;

2. キャッシュ処理に使用されるユーザー(キャッシュ管理ユーザー、キャッシュ・マネージャ・ユーザー、そのコンパニオンOracleユーザーなど)の名前やパスワードを変更する場合は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・ユーザーの名前またはパスワードの変更で説明されている手順を実行してください。

アクティブ・データベースの障害からのリカバリ

次の各項では、アクティブ・マスターに障害が発生したが、スタンバイ・データベースには障害が発生しなかったか、障害発生後にリカバリした場合に、スタンバイ・マスターを新しいアクティブ・マスターにしてアクティブ・スタンバイ・ペアをリカバリする方法について説明しています。さらに、その後アクティブ・マスターとスタンバイ・マスターを再度入れ替えて、元のノードに戻すことができます。

- スタンバイ・データベースが使用可能な場合のリカバリ

- 元のノードへのフェイルバック

注意:
アクティブ・マスターとスタンバイ・マスターの両方に障害が発生した場合のリカバリ方法については、「アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ」を参照してください。

スタンバイ・データベースが使用可能な場合のリカバリ

最初の2つの項では、スタンバイ・データベースが使用可能で、アクティブ・データベースと同期されている場合にアクティブ・データベースをリカバリする方法について説明します。最後の項では、最初の2つの項のいずれの説明に従っても失敗し、スタンバイ・データベースは使用可能だがデータは完全に同期されていない場合の対処方法を説明します。

- レプリケーションがRETURN RECEIPTまたは非同期の場合

- レプリケーションがRETURN TWOSAFEの場合

- 非同期のデータがキャッシュ・グループにある場合

レプリケーションがRETURN RECEIPTまたは非同期の場合

次のタスクを実行します。

1. スタンバイ・データベースで、レプリケーション・エージェントがまだ停止していない場合は、これを停止します。

2. スタンバイ・データベースでttRepStateSet('ACTIVE')をコールします。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。

3. 新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')をコールします(ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです)。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。

4. 新しいアクティブ・データベースで、レプリケーション・エージェントとキャッシュ・エージェントを起動します。

5. ttDestroyユーティリティを使用して、障害が発生したデータベース(古いアクティブ・マスター)を破棄します。

6. 新しいアクティブ・データベースを新しいスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。-keepCG -recoveringNodeオプションをttRepAdminとともに使用して、アクティブ・マスターの障害からキャッシュ・グループをリカバリし、保存します。「データベースの複製」を参照してください。

7. 新しいスタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

8. 新しいスタンバイ・データベースでキャッシュ・エージェントを起動します。

注意:
これらのいずれかの手順に失敗した場合は、「非同期のデータがキャッシュ・グループにある場合」の説明に従ってください。

スタンバイ・データベースは、アクティブ・データベースに通信します。アクティブ・データベースは、サブスクライバへの更新の送信を停止します。スタンバイ・データベースがアクティブ・データベースと完全に同期している場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。AWTキャッシュ・グループをレプリケートしている場合、新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。

注意:
スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。

レプリケーションがRETURN TWOSAFEの場合

次のタスクを実行します。

1. スタンバイ・データベースで、レプリケーション・エージェントがまだ停止されていない場合は停止します。

2. スタンバイ・データベースでttRepStateSet('ACTIVE')をコールします。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。

3. 新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')をコールします(ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです)。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。

4. 新しいアクティブ・データベースで、レプリケーション・エージェントとキャッシュ・エージェントを起動します。

5. 障害が発生したデータベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。データベースのリカバリが正常に行われなかったときは、レプリケーションがRETURN RECEIPTまたは非同期の場合のリカバリ方法の手順5から処理を続けてください。詳細は、「レプリケーションがRETURN RECEIPTまたは非同期の場合」を参照してください。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。

6. 障害が発生したデータベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

7. 障害が発生したデータベースのキャッシュ・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。

注意:
これらのいずれかの手順に失敗した場合は、「非同期のデータがキャッシュ・グループにある場合」の説明に従ってください。

スタンバイ・データベースと完全に同期されているとアクティブ・データベースで判断された場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。AWTキャッシュ・グループをレプリケートしている場合、新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。

注意:
スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateSet組込みプロシージャを使用して確認できます。

非同期のデータがキャッシュ・グループにある場合

「レプリケーションがRETURN RECEIPTまたは非同期の場合」または「レプリケーションがRETURN TWOSAFEの場合」のいずれかの手順が失敗した場合は、Oracle Databaseにまだ伝播していない、非同期のデータがAWTキャッシュ・グループに存在する可能性があります。さらに、アクティブ・スタンバイ・ペアのレプリケーション・スキームに含まれているいずれの読取り専用キャッシュ・グループにもアップロードされていない非同期データがOracle Databaseに存在する可能性があります。

アクティブ・データベースに障害が発生したときにまだ伝播されていなかったデータがスタンバイ・マスターのいずれかのAWTキャッシュにある場合は、スタンバイ・データベースを新しいアクティブ・データベースとして単純にリカバリするオプションを選択することはできません。この場合、次の手順を実行します。

1. スタンバイ・データベースでレプリケーション・エージェントを停止し、DROP ACTIVE STANDBY PAIR文を使用してレプリケーション構成を削除します。

2. キャッシュ・エージェントを停止し、このリカバリ処理の実行中にこれ以上の更新がAWTキャッシュ・グループに適用されないようにし、レプリケーション・スキームに含まれていたすべての読取り専用キャッシュ・グループが更新されるときを制御できるようにします。

3. レプリケーション・スキームに含まれているすべての読取り専用キャッシュ・グループについて、ALTER CACHE GROUP ... SET AUTOREFRESH STATE PAUSED文を使用して、自動リフレッシュ状態をpauseに設定します。

4. スタンバイ・データベースで、すべてのAWTキャッシュ・グループのTimesTenキャッシュ表にある伝播されていないコミット済挿入または更新を、次のようにキャッシュ済Oracle Database表にフラッシュします。

1. 自動コミットをオフに設定します。

2. パラメータを1に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールします。この組込みプロシージャにより、AWTキャッシュ・グループに対してFLUSH CACHE GROUP文を実行できます(このプロシージャはこのリカバリ・シナリオでのみ使用します)。

Command> call ttCacheAllowFlushAwtSet(1);

3. 各AWTキャッシュ・グループに対してFLUSH CACHE GROUP SQL文を実行し、すべてのデータがOracle Databaseに伝播あれることを確認します。

注意:
こうした条件下でAWTキャッシュ・グループに対してFLUSH CACHE GROUP文を実行すると、AWTキャッシュ・グループの表の内容のみ(つまり、挿入または更新されたデータのみ)がフラッシュされます。この際に削除処理は考慮されません。つまり、AWTキャッシュ・グループから削除された行がOracle Databaseに存在している可能性があります。削除処理をリカバリするかどうかは、ユーザーにゆだねられます。

4. パラメータを0に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールすると、AWTキャッシュ・グループに対してこれ以上のFLUSH CACHE GROUP文を実行することができなくなります。

Command> call ttCacheAllowFlushAwtSet(0);

5. パラメータを0に設定してttCacheAllowFlushAwtSet組込みプロシージャをコールした後にコミットします。自動コミットはttCacheAllowFlushAwtSet組込みプロシージャの間のみオフにする必要があるので、これをオンにリセットすることもできます。

5. DROP CACHE GROUPおよびCREATE CACHE GROUP文を使用して、すべてのAWTキャッシュ・グループを削除および再作成します。

6. 読取り専用キャッシュ・グループをリフレッシュするためにはキャッシュ・エージェントはアクティブになっている必要があり、また、AWTキャッシュ・グループをロードするためにはレプリケーション・エージェントとキャッシュ・エージェントの両方がアクティブになっている必要があるため、レプリケーション・エージェントとキャッシュ・エージェントを起動します。

7. REFRESH CACHE GROUP文を使用して読取り専用キャッシュ・グループをリフレッシュし、最新のコミット済データをキャッシュ済Oracle Database表からアップロードします。REFRESH CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。

8. LOAD CACHE GROUP文を使用してすべてのAWTキャッシュ・グループをロードし、自動リフレッシュ・プロセスを開始します。LOAD CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。

9. レプリケーション・エージェントとキャッシュ・エージェントの両方を停止し、アクティブ・スタンバイ・ペアの再作成に備えます。

10. スタンバイ・データベースでCREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。

11. 古いスタンバイ・データベースを新しいアクティブ・データベースとして設定し、障害が発生した古いアクティブ・データベースを破棄し、アクティブ・データベースを複製して新しいスタンバイ・データベースを再作成してから、スタンバイでキャッシュ・エージェントとレプリケーション・エージェントを起動します(「レプリケーションがRETURN RECEIPTまたは非同期の場合」にリストした手順を参照)。

元のノードへのフェイルバック

フェイルオーバーに成功した後、アクティブ・データベースおよびスタンバイ・データベースが元のノードに存在するようにフェイルバックする必要がある場合があります。詳細は、「アクティブ・データベースとスタンバイ・データベースの役割の入替え」を参照してください。

スタンバイ・データベースの障害からのリカバリ

スタンバイ・データベースの障害からリカバリするには、次のタスクを実行します。

1. RETURN TWOSAFEサービスが有効になっている場合にスタンバイ・データベースで障害が発生すると、処理中のトランザクションはアクティブ・データベースでコミットされなくなり、エラー8170「Receipt or commit acknowledgement not returned in the specified timeout interval」が発生します。その場合は、localActionパラメータを2 (COMMIT)に設定してttRepSyncSet組込みプロシージャをコールし、トランザクションを再度コミットします。次に例を示します。

Command> call ttRepSyncSet( null, null, 2);
Command> commit;

2. アクティブ・データベースで、ttRepStateSave('FAILED','standby_database','host_name')をコールします。このとき、スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。追加のサブスクライバ・データベースは、アクティブから直接複製することもできます。

3. 次のいずれかの方法で、スタンバイ・データベースをリカバリします。

1. スタンバイ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。スタンバイ・データベースがリカバリされたら、手順4に進みますが、それ以外の場合は手順3bを続けます。

2. ttDestroyユーティリティを使用してスタンバイ・データベースの現行バージョンを破棄します。

3. アクティブ・データベースから新しいスタンバイ・データベースを複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。-keepCG -recoveringNodeオプションをttRepAdminとともに使用して、スタンバイ・マスターの障害からキャッシュ・グループをリカバリし、保存します。「データベースの複製」を参照してください。

4. レプリケーション・エージェント・ポリシーを設定し、スタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

5. スタンバイ・データベースでキャッシュ・エージェントを起動します。

アクティブ・データベースで2つのマスター・データベースが同期していると判断し、サブスクライバへの更新の送信を停止すると、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。

注意:
スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。

アクティブ・データベースおよびスタンバイ・データベースの二重の障害からのリカバリ

アクティブ・データベースとスタンバイ・データベースの両方でほぼ同じ時間に障害が発生し、ほとんど即時に両方のデータベースに再接続できた場合は、レプリケーション・エージェント(と、使用可能な場合はキャッシュ・エージェント)を再起動し、続行します。

1. 障害が発生したアクティブ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。

2. 障害が発生したアクティブ・データベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

3. 新しくリカバリされたデータベースで、ttRepStateSet('ACTIVE')をコールします。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。

4. 障害が発生したデータベースのキャッシュ・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。

5. 障害が発生したスタンバイ・マスター・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。

6. 障害が発生したスタンバイ・データベースのレプリケーション・エージェントが再起動したことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

7. 障害が発生したスタンバイ・データベースのキャッシュ・エージェントが再起動したことを確認します。再起動されていない場合は起動します。

または、アクティブ・マスターとスタンバイ・マスター・データベースの両方に障害が発生した場合の、次のシナリオを考えてみます。

- スタンバイ・データベースで障害が発生しました。スタンバイが再起動する前、またはスタンバイがアクティブ・データベースと同期される前に、アクティブ・データベースで障害が発生しました。

- アクティブ・データベースで障害が発生しました。スタンバイ・データベースがACTIVEになり、リカバリ・プロセスの残りが開始されます。(「アクティブ・データベースの障害からのリカバリ」を参照してください。)新しいスタンバイ・データベースが新しいアクティブ・データベースと完全に同期される前に、そのアクティブ・データベースで障害が発生しました。

これらのシナリオでは、スタンバイ・データベースの場合より多くの変更がサブスクライバに適用されている可能性があります。

この場合、次のいずれかのオプションを実行できる可能性があります。

- アクティブ・データベースをリカバリし、新しいスタンバイ・データベースを複製する

- スタンバイ・データベースをリカバリして新しいアクティブ・マスターにする

- バックアップからアクティブ・マスターをリストアする

アクティブ・データベースをリカバリし、新しいスタンバイ・データベースを複製する

1. 障害が発生したアクティブ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。

注意:
これに失敗した場合は、「バックアップからアクティブ・マスターをリストアする」の手順を実行してください。

2. 障害が発生したアクティブ・データベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

3. 新しくリカバリされたデータベースで、ttRepStateSet('ACTIVE')をコールします。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。

4. 障害が発生したデータベースのキャッシュ・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。

5. アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。

6. スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

7. スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。

8. ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。

9. スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。

10. サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

スタンバイ・データベースをリカバリして新しいアクティブ・マスターにする

1. 障害が発生したスタンバイ・マスター・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。読取り専用キャッシュ・グループをレプリケートしている場合は、AUTOREFRESH STATEがPAUSEDに自動的に設定されます。

注意:
これに失敗した場合は、「バックアップからアクティブ・マスターをリストアする」の手順を実行してください。

2. 障害が発生したスタンバイ・マスターのレプリケーション・エージェントが自動的に再起動された場合は、レプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。

3. キャッシュ・エージェントが自動的に再起動された場合は、そのキャッシュ・エージェントを停止します。

4. DROP ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を削除します。

5. DROP CACHE GROUPおよびCREATE CACHE GROUP文を使用して、すべてのキャッシュ・グループを削除および再作成します。

6. CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。

7. マスター・データベースで、ttRepStateSet('ACTIVE')をコールして、そのデータベースにACTIVEの役割を割り当てます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。

8. レプリケーション・エージェント・ポリシーを設定し、新しいアクティブ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

9. 新しいアクティブ・データベースでキャッシュ・エージェントを起動します。

10. アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。

11. スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

12. スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。

13. ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。

14. スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。

15. サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

バックアップからアクティブ・マスターをリストアする

アクティブ・マスターとスタンバイ・マスターの両方で障害が発生し、どちらも停止したがバックアップがあった場合は、次の手順を実行します。

1. バックアップからアクティブ・マスターをリストアします(『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・グループによるデータベースのバックアップとリストアに関する説明を参照)。

2. DROP ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を削除します。

3. DROP CACHE GROUPおよびCREATE CACHE GROUP文を使用して、すべてのAWTキャッシュ・グループを削除および再作成します。

4. 読取り専用キャッシュ・グループをリフレッシュするためにはキャッシュ・エージェントはアクティブになっている必要があり、また、AWTキャッシュ・グループをロードするためにはレプリケーション・エージェントとキャッシュ・エージェントの両方がアクティブになっている必要があるため、レプリケーション・エージェントとキャッシュ・エージェントを起動します。

5. REFRESH CACHE GROUP文を使用して読取り専用キャッシュ・グループをリフレッシュし、最新のコミット済データをキャッシュ済Oracle Database表からアップロードします。REFRESH CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。

6. LOAD CACHE GROUP文を使用してすべてのAWTキャッシュ・グループをロードし、自動リフレッシュ・プロセスを開始します。LOAD CACHE GROUP ... PARALLEL n句を使用して、これらのキャッシュ済グループを複数のスレッドを介して同時にロードします。

7. レプリケーション・エージェントとキャッシュ・エージェントの両方を停止し、アクティブ・スタンバイ・ペアの再作成に備えます。

8. CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。

9. アクティブ・マスター・データベースで、ttRepStateSet('ACTIVE')をコールして、そのデータベースにACTIVEの役割を割り当てます。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。

10. レプリケーション・エージェント・ポリシーを設定し、アクティブ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

11. アクティブ・データベースでキャッシュ・エージェントを起動します。

12. アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。

13. スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

14. スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。

15. ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。

16. スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。

17. サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

サブスクライバ・データベースの障害からのリカバリ

サブスクライバ・データベースで障害が発生した場合は、次のいずれかの方法を使用してリカバリすることができます。

- 障害が発生したサブスクライバに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。レプリケーション・エージェントを起動し、サブスクライバによるキャッチアップを可能にします。

- スタンバイ・データベースからサブスクライバを複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。

スタンバイ・データベースが停止しているか、またはリカバリ中の場合は、アクティブ・データベースからサブスクライバを複製します。

サブスクライバ・データベースがリカバリされた後、レプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

アクティブ・データベースとスタンバイ・データベースの役割の入替え

アクティブ・データベースの役割をスタンバイ・データベースに変更する場合、およびその逆の変更を実行する場合は、次の手順を実行します。

1. 現行のアクティブ・データベースで更新を生成しているすべてのアプリケーションを一時停止します。

2. 現行のスタンバイ・データベースのDSNおよびホストを入力パラメータとして使用して、アクティブ・データベースでttRepSubscriberWaitをコールします。成功すると<00>が返されます。これによって、すべての更新が現行のスタンバイ・データベースに送信されます。

3. 現行のアクティブ・データベースでレプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。

4. グローバル・キャッシュ・グループが存在しない場合は、現在のアクティブ・データベースでキャッシュ・エージェントを停止します。グローバル・キャッシュ・グループが存在する場合、自動リフレッシュの状態をPAUSEDに設定します。

5. 現在のアクティブ・データベースでttRepDeactivateをコールします。これによって、このデータベースはIDLE状態になります。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがONからPAUSEDに自動的に変更されます。

6. 現在のスタンバイ・データベースで、ttRepStateSet('ACTIVE')をコールします。これによって、このデータベースがアクティブ・スタンバイ・ペアのアクティブ・データベースとして機能するようになります。読取り専用キャッシュ・グループをレプリケートしている場合にこの手順を実行すると、このデータベースのAUTOREFRESH STATEがPAUSEDからONに自動的に変更されます。

7. 元のマスター・データベースでレプリケーション・エージェントを起動します。

8. 必要に応じて、レプリケーション・エージェント・ポリシーを構成し、元のアクティブ・データベースでレプリケーション・エージェントを起動します。ttRepStateGet組込みプロシージャを使用して、データベースの状態がIDLEからSTANDBYに変更されたタイミングを確認します。これによって、このデータベースがアクティブ・スタンバイ・ペアのスタンバイ・データベースとして機能するようになります。

9. キャッシュ・エージェントが実行されていない場合は、元のアクティブ・データベースで起動します。

10. 手順1で一時停止したアプリケーションを再開します。

二重のアクティブ・データベースの検出

「二重のアクティブ・データベースの検出」を参照してください。キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアの場合、違いはありません。

アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用

TimesTenアクティブ・スタンバイ・ペアのレプリケーションでは、データ・センター内のデータベース間の高速な切替えを可能にすることにより、高可用性が実現されます。これには、AWTキャッシュ・グループを使用してOracle Databaseに変更を伝播するデータベースを自動的に変更する機能が含まれます。ただし、データ・センター全体でのさらなる高可用性を実現するには、サイト全体の障害からリカバリ可能である必要があり、サイト全体の障害には、アクティブ・スタンバイ・ペアのTimesTenマスター・データベースおよびキャッシュ・グループに使用されるOracle Databaseの両方の障害が含まれる場合があります。

サイト全体の障害からリカバリするには、アクティブ・スタンバイ・ペアのレプリケーション・スキームの一部として、特別な障害時リカバリ読取り専用サブスクライバを作成します。スタンバイ・データベースは、読取り専用サブスクライバのキャッシュ・グループ表に更新を送信します。この特別なサブスクライバはリモートの障害時リカバリ・サイトに配置されており、(同様に障害時リカバリ・サイトに配置されている)2番目のOracle Databaseに更新を伝播できます。この障害時リカバリ・サブスクライバは、プライマリ・サイトで全体の障害が発生した場合、障害時リカバリ・サイトで新しいアクティブ・スタンバイ・ペアのアクティブとしての役割を引き継ぐことができます。この場合、すべてのアプリケーションが障害時リカバリ・サイトに接続して処理を続行でき、サービスの中断を最小限に抑えることができます。

アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用に関する要件

障害時リカバリ・サブスクライバを使用する場合の要件は、次のとおりです。

- プライマリ・サイトで、AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペア構成を使用していること。アクティブ・スタンバイ・ペアのレプリケーション・スキームには、読取り専用キャッシュ・グループを含めることもできます。読取り専用キャッシュ・グループは、障害時リカバリ・サブスクライバで通常の表に変換されます。AWTキャッシュ・グループ表は、障害時リカバリ・サブスクライバでAWTキャッシュ・グループ表のまま保持されます。

- プライマリ・サイトから障害時リカバリ・サイトへの継続的なWAN接続があること。この接続には、少なくとも、通常量のトランザクションを障害時リカバリ・サブスクライバに適切な速度でレプリケートできる十分な帯域幅が必要です。

- 障害時リカバリ・サイトで、プライマリ・サイトのデータベースと同じスキーマを持つ表を含めるようにOracle Databaseが構成されていること。このデータベースは、レプリケートされた更新をプライマリ・サイトから取得することのみを目的としており、障害時リカバリ・サブスクライバの作成時にキャッシュ・グループによって書き込まれた表になんらかのデータが存在する場合、そのデータは削除されることに注意してください。

- プライマリ・サイトと障害時リカバリ・サイトの両方に同じキャッシュ・グループ管理者ユーザーIDおよびパスワードがあること。

必須ではありませんが、障害時リカバリ・サイトに2番目のTimesTenデータベースを構成することをお薦めします。このデータベースは、プライマリ・サイトに障害が発生した後、障害時リカバリ・サブスクライバがアクティブ・データベースに昇格した場合、スタンバイ・データベースの役割を引き継ぐことができます。

障害時リカバリ・サブスクライバのローリング・アウト

障害時リカバリ・サブスクライバを作成するには、次の手順を実行します。

1. AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアをプライマリ・サイトで作成します。アクティブ・スタンバイ・ペアには、読取り専用キャッシュ・グループを含めることもできます。読取り専用キャッシュ・グループは、障害時リカバリ・サブスクライバがロール・アウトされるときに通常の表に変換されます。

2. -duplicateおよび-initCacheDRオプションを指定したttRepAdminユーティリティを使用し、障害時リカバリ・サイトで障害時リカバリ・サブスクライバを作成します。また、-cacheUidおよび-cachePwdオプションを使用して、障害時リカバリ・サイトでOracle Databaseのキャッシュ・グループ管理者およびパスワードを指定する必要もあります。
データベースに複数のキャッシュ・グループが含まれている場合、-nThreadsオプションを使用して、キャッシュ・グループを並行してフラッシュするために生成されるスレッドの数を指定することにより、複製処理の効率を向上させることができます。各スレッドはキャッシュ・グループ全体をOracle Databaseにフラッシュし、フラッシュするキャッシュ・グループが残っている場合は、次のキャッシュ・グループに進みます。-nThreadの値が指定されていない場合は、1つのフラッシュ・スレッドのみが生成されます。

たとえば、ホスト名primary、キャッシュ・ユーザーID system、パスワードmanagerのシステムで、スタンバイ・データベースmast2を障害時リカバリ・サブスクライバdrsubに複製し、2つのキャッシュ・グループ・フラッシュ・スレッドを使用するとします。ttRepAdminによって-uid、-pwd、-cacheUidおよび-cachePwdの値を入力するよう要求されます。

ttRepAdmin -duplicate -from mast2 -host primary -initCacheDR -nThreads 2
-connStr "DSN=drsub;UID=;PWD=;"

CでttRepDuplicateEx関数を使用する場合は、ttRepDuplicateExArg.flagsにTT_REPDUP_INITCACHEDRフラグを設定する必要があり、オプションで、ttRepDuplicateExArg.nThreads4InitDRの値を指定できます。

int                 rc;
ttUtilHandle        utilHandle;
ttRepDuplicateExArg arg;
memset( &arg, 0, sizeof( arg ) );
arg.size = sizeof( ttRepDuplicateExArg );
arg.flags = TT_REPDUP_INITCACHEDR;
arg.nThreads4InitDR = 2;
arg.uid="ttuser"
arg.pwd="ttuser"
arg.cacheuid = "system";
arg.cachepwd = "manager";
arg.localHost = "disaster";
rc = ttRepDuplicateEx( utilHandle, "DSN=drsub",
"mast2", "primary", &arg );

サブスクライバが複製されると、TimesTenでは、AWTキャッシュ・グループからOracle Databaseに更新を伝播し、TimesTenのキャッシュ・グループに対応するOracle Databaseの表を切り捨て、キャッシュ・グループのすべてのデータをOracle Databaseにフラッシュするレプリケーション・スキームが自動的に構成されます。

3. 障害時リカバリ・サブスクライバに障害しきい値を設定する場合は、ttCacheAWTThresholdSet組込みプロシージャをコールし、障害時リカバリ・サブスクライバが停止しているか、またはキャッチアップに時間がかかりすぎているとみなされる前に累積可能なトランザクション・ログ・ファイルの数を指定します。
障害時リカバリ・サブスクライバが作成される前に、一方または両方のマスター・データベースに障害しきい値が構成されている場合、障害時リカバリ・サブスクライバはttRepAdmin -duplicate -initCacheDRコマンドで作成されたときに障害しきい値の値を引き継ぎます。これらのマスター・データベースの障害しきい値が異なる場合は、大きい方の値が障害時リカバリ・サブスクライバに使用されます。

障害しきい値の詳細は、「トランザクション・ログ障害しきい値の設定」を参照してください。

4. 障害時リカバリ・サブスクライバのレプリケーション・エージェントを起動するには、ttRepStart組込みプロシージャまたは-repstartオプションを指定したttAdminユーティリティを使用します。次に例を示します。

ttAdmin -repstart drsub

スタンバイ・データベースから障害時リカバリ・サブスクライバに更新がレプリケートされます。この後、これらの更新は、障害時リカバリ・サブスクライバによって障害時リカバリ・サイトのOracle Databaseに伝播されます。

障害時リカバリ・サイトへの切替え

プライマリ・サイトに障害が発生した場合は、2つのうちいずれかの方法で障害時リカバリ・サイトに切り替えることができます。障害時リカバリ・サイトでのデータ損失を最小限に抑えることが目的である場合は、障害時リカバリ・サブスクライバをアクティブ・データベースとして使用し、新しいアクティブ・スタンバイ・ペアをロール・アウトします。障害時リカバリ・データベースに後で障害が発生してデータが失われる可能性があっても、アプリケーションの停止時間を最小限に抑えることが目的である場合は、障害時リカバリ・サブスクライバからレプリケーション・スキームを削除し、単一の非レプリケート・データベースとして使用することを選択できます。後でアクティブ・スタンバイ・ペアを障害時リカバリ・サイトにデプロイできます。

障害時リカバリ・サイトへの切替え後の新しいアクティブ・スタンバイ・ペアの作成

1. 読取り専用アプリケーションは、障害時リカバリ・サブスクライバにすぐにリダイレクトできます。データベースに対して更新を行うアプリケーションのリダイレクトは、手順7で実行します。

2. ttRepSubscriberWait組込みプロシージャまたは-waitオプションを指定したttRepAdminコマンドを使用して、キャッシュ・グループへの新しい更新がすべてOracle Databaseに伝播されていることを確認します。

Command> call ttRepSubscriberWait( null, null, '_ORACLE', null, 600 );

成功すると<00>が返されます。ttRepSubscriberWaitでタイムアウトを示す0x01が返されたら、手順3に進む前に、キャッシュ・グループによる伝播が完了していない原因を調べて特定します。

3. 障害時リカバリ・サブスクライバのレプリケーション・エージェントを停止するには、ttRepStop組込みプロシージャまたは-repstopオプションを指定したttAdminコマンドを使用します。たとえば、サブスクライバdrsubのレプリケーション・エージェントを停止するには、次のように入力します。

Command> call ttRepStop;

4. DROP ACTIVE STANDBY PAIR文を使用して、サブスクライバのアクティブ・スタンバイ・ペアのレプリケーション・スキームを削除します。次に例を示します。

Command> DROP ACTIVE STANDBY PAIR;

5. 障害時リカバリ・サブスクライバ上に、アクティブ・データベースの読取り専用キャッシュ・グループ表から変換された表が存在する場合、障害時リカバリ・サブスクライバでそれらの表を削除します。

6. 障害時リカバリ・サブスクライバで読取り専用キャッシュ・グループを作成します。AUTOREFRESH STATEがPAUSEDに設定されていることを確認します。

7. CREATE ACTIVE STANDBY PAIR文を使用し、新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成し、障害時リカバリ・サブスクライバをアクティブ・データベースとして指定します。たとえば、前のサブスクライバdrsubをアクティブ・データベースとして使用し、新しいデータベースdrstandbyをスタンバイ・データベースとして使用する新しいアクティブ・スタンバイ・ペアを作成し、RETURN TWOSAFE戻りサービスを使用するには、次のように入力します。

Command> CREATE ACTIVE STANDBY PAIR drsub, drstandby RETURN TWOSAFE;

8. ttRepStateSet組込みプロシージャを使用して、新しいアクティブ・スタンバイ・データベースを、ACTIVEステータスに設定します。たとえば、この例のデータベースdrsubで次のようにコールします。

Command> call ttRepStateSet( 'ACTIVE' );

9. TimesTenデータベースへの書込みを必要とするすべてのアプリケーションが、新しいアクティブ・データベースにリダイレクトされるようになりました。

10. 読取り専用キャッシュ・グループをレプリケートしている場合は、LOAD CACHE GROUP文を使用してキャッシュ・グループをロードし、自動リフレッシュ・プロセスを開始します。AWTキャッシュ・グループをレプリケートしている場合も、キャッシュ・グループをロードできます(必須ではありません)。

11. アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。

12. スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

13. スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。

14. ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを開始します。

15. スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。

16. サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

1つのデータベースへの切替え

1. 読取り専用アプリケーションは、障害時リカバリ・サブスクライバにすぐにリダイレクトできます。データベースに対して更新を行うアプリケーションのリダイレクトは、手順5で実行します。

2. 障害時リカバリ・サブスクライバのレプリケーション・エージェントを停止するには、ttRepStop組込みプロシージャまたは-repstopオプションを指定したttAdminコマンドを使用します。たとえば、サブスクライバdrsubのレプリケーション・エージェントを停止するには、次のように入力します。

Command> call ttRepStop;

3. DROP ACTIVE STANDBY PAIR文を使用して、サブスクライバのアクティブ・スタンバイ・ペアのレプリケーション・スキームを削除します。次に例を示します。

Command> DROP ACTIVE STANDBY PAIR;

4. 障害時リカバリ・サブスクライバ上に、アクティブ・データベースの読取り専用キャッシュ・グループ表から変換された表が存在する場合、障害時リカバリ・サブスクライバでそれらの表を削除します。

5. 障害時リカバリ・サブスクライバで読取り専用キャッシュ・グループを作成します。

6. 構成済のアクティブ・スタンバイ・ペアはなくなりましたが、AWTキャッシュ・グループでは、レプリケーション・エージェントの起動を必要とします。ttRepStart組込みプロシージャまたは-repstartオプションを指定したttAdminコマンドを使用して、データベースでレプリケーション・エージェントを起動します。たとえば、データベースdrsubのレプリケーション・エージェントを起動するには、次のように入力します。

Command> call ttRepStart;

7. TimesTenデータベースへの書込みを必要とするすべてのアプリケーションが、このデータベースにリダイレクトされるようになりました。

注意:
アクティブ・スタンバイ・ペアは、後から障害時リカバリ・サイトでロール・アウトできます。これを行うには、「障害時リカバリ・サイトへの切替え後の新しいアクティブ・スタンバイ・ペアの作成」の手順に従い、手順2から開始し、手順4は省略してください。

プライマリ・サイトでの元の構成への復元

プライマリ・サイトが再び使用可能になったときに、稼働中のアクティブ・スタンバイ・ペアを障害時リカバリ・サイトからプライマリ・サイトに戻す場合があります。元の障害時リカバリ・サイトの作成および切替えに使用したプロセスを逆順で行うと、サービスの中断を最小限に抑えながらこの処理を行うことができます。次の手順を実行します。

1. 必要に応じてttDestroyユーティリティを使用して、プライマリ・サイトで元のアクティブ・データベースを破棄します。たとえば、mast1というデータベースを破棄するには、次のように入力します。

ttDestroy mast1

2. 「障害時リカバリ・サブスクライバのローリング・アウト」の手順に従って、プライマリ・サイトで障害時リカバリ・サブスクライバを作成します。元のアクティブ・データベースを新しい障害時リカバリ・サブスクライバに対して使用します。

3. 「障害時リカバリ・サイトへの切替え」の説明に従って、プライマリ・サイトで新しい障害時リカバリ・サブスクライバに切り替えます。スタンバイ・データベースもロール・アウトします。

4. 「障害時リカバリ・サブスクライバのローリング・アウト」の説明に従って、障害時リカバリ・サイトで新しい障害時リカバリ・サブスクライバをロール・アウトします。

7 アクティブ・スタンバイ・ペアの変更

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

- アクティブ・スタンバイ・ペアのDDLの変更

- アクティブ・スタンバイ・ペアへのその他の変更

アクティブ・スタンバイ・ペアのDDLの変更

次の各項では、特定のDDL文の自動レプリケーションを構成する方法について説明します。つまり、サポートされているDDL文をアクティブ・マスターで実行すると、アクティブ・スタンバイ・ペアのレプリケーション・スキーム内のすべてのデータベースに、そのDDL文が自動的にレプリケートされます。

- アクティブ・スタンバイ・ペアのすべてのデータベースへのオブジェクト・レプリケーションの制御

- 自動的にレプリケートできるDDL文

- 既存のアクティブ・スタンバイ・ペアでの新しいPL/SQLオブジェクトの作成

- アクティブ・スタンバイ・ペアのDDLの変更に関する制限

- 例: アクティブ・スタンバイ・ペアのDDLの変更

- 例: アクティブ・スタンバイ・ペアの変更

アクティブ・スタンバイ・ペアのすべてのデータベースへのオブジェクト・レプリケーションの制御

DDLReplicationLevelおよびDDLReplicationAction接続属性を使用して、DDL文によって作成または削除されるオブジェクトの、どれをアクティブ・スタンバイ・ペアのレプリケーション・スキームに含まれるデータベースにレプリケートするかを制御します。これらの接続属性の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースを識別するためのデータソース名の指定に関する説明を参照してください。

DDLReplicationLevel接続属性によって、レプリケートされるDDL文を制御します。

- DDLReplicationLevel=1。表、索引またはシノニムのCREATE文またはDROP文はスタンバイ・データベースにレプリケートされません。ただし、レプリケート表に対して列の追加または削除を行うことで、それらのアクションがスタンバイ・データベースにレプリケートされます。

- DDLReplicationLevel=2 (デフォルト)では、表、索引およびシノニムの作成および削除のレプリケーションが有効になります。
表をレプリケーション・スキームに含めるには、表を作成する前に、DDLReplicationAction接続属性を'INCLUDE' (デフォルト)に設定する必要があります。DDLReplicationAction='EXCLUDE'の場合、表はレプリケーション・スキームに含まれません。表がレプリケーション・スキームから除外された場合、表を作成または削除するためのDDL文はスタンバイ・マスターにレプリケートされますが、表に対して実行されるDML文はレプリケートされません。

注意:
次の場合にはレプリケーション・スキームから表を除外することが考えられます。

- NULLを指定できない列に主キーも一意索引もないレプリケーション・スキームに表を作成する場合。

- データをローカルでのみ使用し、表の更新はレプリケートしない一時表を作成する場合。

アクティブ・スタンバイ・ペアに既存の表を追加するには、ALTER ACTIVE STANDBY PAIR INCLUDE TABLE文を使用します。表は空である必要があります。

ただし、ALTER TABLE ... ADD COLUMN NOT NULL DEFAULT文を使用してNOT NULL列をレプリケーション・スキームの一部である表に追加して表を修正することはできません。表にNOT NULL列を追加する前に、まず、レプリケーション・スキームから表を削除する必要があります。

- DDLReplicationLevel=3では次のことが可能です。

- DDLReplicationLevel=2を指定した場合にレプリケートされる同じオブジェクトの、レプリケーション・スキームのすべてのデータベースへのレプリケーション。

- レプリケーション・スキームのすべてのデータベースへのビューの作成と削除のレプリケーション。

- レプリケーション・スキームのすべてのデータベースへの作成および削除の順序のレプリケーション(作成前にDDLReplicationAction='INCLUDE' (デフォルト)の場合)。DDLReplicationAction='EXCLUDE'の場合、順序はレプリケーション・スキームに含まれません。順序がレプリケーション・スキームから除外される場合は、順序の作成と削除のためのDDL文はスタンバイ・マスターにレプリケートされますが、アクティブ・マスターとスタンバイ・マスターのそれぞれの順序は別々のオブジェクトとなります。

- キャッシュ管理ユーザーの名前とパスワードをttCacheUidPwdSet組込みプロシージャを使用してアクティブ・マスターに設定するときに、結果をスタンバイ・マスターにレプリケーション。アクティブ・マスターに対してttCacheUidPwdSet組込みプロシージャを実行するために、キャッシュ・エージェントまたはレプリケーション・エージェントを停止し、再起動する必要はありません。詳細は、「レプリケーションで使用されるユーザー名またはパスワードの変更」を参照してください。

- このレベルを使用すると、ALTER TABLE ... ADD COLUMN NOT NULL DEFAULT文を使用して、NOT NULL列をレプリケーション・スキームの一部である表に追加するように表を変更できます。

DDLReplicationLevel属性は接続ストリングの一部として設定でき、また、接続開始後にALTER SESSION文を使用して変更できます。

ALTER SESSION SET DDL_REPLICATION_LEVEL=3;

DDLReplicationAction属性は接続ストリングの一部として設定でき、また、接続開始後にALTER SESSION文を使用して変更できます。

ALTER SESSION SET ddl_replication_action='EXCLUDE';

詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のALTER SESSION文に関する説明およびALTER ACTIVE STANDBY PAIR文に関する説明を参照してください。

注意:
DDLCommitBehavior=0(デフォルト)の場合、DDL操作は自動的にコミットされます。RETURN TWOSAFEが指定されている場合、「RETURN TWOSAFE」で説明されているように、エラーおよびタイムアウトが発生する可能性があります。RETURN TWOSAFEタイムアウトが発生すると、指定されているLOCAL COMMIT ACTIONに関係なく、DDLトランザクションはローカルでコミットされます。

自動的にレプリケートできるDDL文

レプリケーション・エージェントを停止せずに、アクティブ・スタンバイ・ペアで次のDDL文を実行できます。また、これらの文はレプリケーション・スキームのすべてのデータベースにレプリケートされます。DDLReplicationLevelが2または3の場合(デフォルトは2)、次の文は自動的にレプリケートされます。

- ユーザーを作成、変更、削除する際のCREATE USER文、ALTER USER文、DROP USER文。

- ユーザーに権限を付与する、または権限を取り消す際のGRANT文またはREVOKE文。

- ALTER TABLE ... ADD COLUMN文またはALTER TABLE ... DROP COLUMN文を使用して、列を追加または削除して表を変更します。これらはレプリケートされる唯一のALTER TABLE句です。ただし、DDLReplicationLevel=2の場合は、ALTER TABLE ... ADD COLUMN NOT NULL DEFAULT文を使用してNOT NULL列をレプリケーション・スキームの一部である表に追加して表を修正することができません。この文はDDLReplicationLevel=3の場合に実行できます。

- CREATE TABLE文またはDROP TABLE文を使用して、表(グローバル一時表を含む)を作成または削除します。また、新しい表をアクティブ・スタンバイ・ペアにも含められます。

- CREATE SYNONYM文またはDROP SYNONYM文を使用して、シノニムを作成または削除します。

- CREATE INDEX文またはDROP INDEX文を使用して、索引を作成または削除します。

レプリケーション・エージェントを停止せずに、アクティブ・スタンバイ・ペアで次のタスクを実行できます。また、これらの文はレプリケーション・スキームのすべてのデータベースにレプリケートされます。DDLReplicationLevelが3に設定されている場合、次の文は自動的にレプリケートされます。

- ビューを作成または削除する際のCREATE VIEW文またはDROP VIEW文。

- 順序を作成または削除する際のCREATE SEQUENCE文またはDROP SEQUENCE文。順序の作成前にDDLReplicationAction接続属性がINCLUDE (デフォルト)に設定されている場合、これらの文はレプリケーション・スキーム内のすべてのデータベースに自動的にレプリケートされ、アクティブ・スタンバイ・ペアに含まれますが、DDLReplicationAction接続属性がEXCLUDEに設定されている場合、順序はレプリケーション・スキームに含まれません。

ttCacheUidPwdSet組込みプロシージャを使用して、キャッシュ管理ユーザーのユーザー名とパスワードをアクティブ・マスターに設定するときに、キャッシュ・エージェントやレプリケーション・エージェントを停止する必要はありません。DDLReplicationLevel=3の場合、この情報はスタンバイ・マスターに自動的にレプリケートされます。詳細は、「レプリケーションで使用されるユーザー名またはパスワードの変更」を参照してください。

レプリケーション・エージェントを停止した後にのみ、アクティブ・スタンバイ・ペアで次のタスクを実行できます。これらの文はスタンバイ・マスターにレプリケートされないため、これらの文のレプリケーションを実行するか、レプリケーション・エージェントの停止後にレプリケーション・スキーム内のすべてのノードに対してこれらの文を実行することにより、スタンバイ・マスターおよびすべてのサブスクライバに変更が伝播されたことを確認する必要があります。実行後にすべてのノードでレプリケーション・エージェントを再起動します。

- マテリアライズド・ビューを作成、削除または変更するためのDDL文。

- ALTER CACHE GROUP ... SET AUTOREFRESH MODE文またはALTER CACHE GROUP ... SET AUTOREFRESH INTERVAL文を使用した自動リフレッシュ・モードまたは自動リフレッシュ間隔の変更。

レプリケーション・エージェントを停止せずに、アクティブ・スタンバイ・ペアで次のタスクを実行できます。ただし、これらの文はスタンバイ・マスターにレプリケートされないため、これらの文のレプリケーションを実行するか、レプリケーション・エージェントの停止後にレプリケーション・スキーム内のすべてのノードに対してこれらの文を実行することにより、スタンバイ・マスターおよびすべてのサブスクライバに変更が伝播されたことを確認する必要があります。

- ALTER CACHE GROUP ... SET AUTOREFRESH STATE文を使用してキャッシュ・グループの自動リフレッシュ状態を変更。ただし、アクティブ・マスターでキャッシュ・グループの自動リフレッシュ状態をOFFに設定することはできません。

- PL/SQLファンクション、PL/SQLプロシージャ、PL/SQLパッケージまたはPL/SQLパッケージ本体の作成または削除。これらのオブジェクトのレプリケーション・エージェントを停止する必要はありません。PL/SQLオブジェクトの詳細は、「既存のアクティブ・スタンバイ・ペアでの新しいPL/SQLオブジェクトの作成」を参照してください。

- レプリケートされない他のすべてのDDL文(マテリアライズド・ビューは除く)。

既存のアクティブ・スタンバイ・ペアでの新しいPL/SQLオブジェクトの作成

既存のアクティブ・スタンバイ・ペアに新しいPL/SQLプロシージャ、パッケージ、パッケージ本体またはファンクションを追加するには、次のタスクを実行します。

1. アクティブ・データベースでPL/SQLオブジェクトを作成します。CREATE文はスタンバイ・データベースにレプリケートされません。

2. スタンバイ・データベースおよびすべてのサブスクライバでのPL/SQLオブジェクトの作成。

3. アクティブ・データベースの新しいPL/SQLオブジェクトに権限を付与します。GRANT文はスタンバイ・データベースおよびすべてのサブスクライバにレプリケートされます。

アクティブ・スタンバイ・ペアのDDLの変更に関する制限

DDLReplicationLevelが2または3の場合

- CREATE TABLE ... AS SELECT文、ALTER TABLE ... ADD CONSTRAINT文、ALTER TABLE ... ADD UNIQUE文およびALTER TABLE ... MODIFY文は、レプリケートされません。

- 索引が空の表に作成される場合にのみ、CREATE INDEX文はレプリケートされます。移入済の表に新規の索引を作成するには、DDLReplicationLevelを2未満の値に設定し、アクティブとスタンバイの両方に手動で索引を作成します。

- DDLReplicationLevelが2または3の場合、次の文はスタンバイ・データベースで実行することはできません。

- CREATE USER、ALTER USER、DROP USER

- CREATE TABLE、DROP TABLE

- CREATE INDEX、DROP INDEX

- GRANT、REVOKE

- CREATE SYNONYM、DROP SYNONYM

DDLReplicationLevelが3の場合

- CREATE SEQUENCE ... CYCLE文はレプリケートされません。

- DDLReplicationLevel=3の場合、次の文はスタンバイ・データベースで実行することはできません。

- CREATE INDEX、DROP INDEX

- DDLReplicationAction='INCLUDE'の場合、CREATE SEQUENCE、DROP SEQUENCE。

注意:
ただし、DDLReplicationAction='EXCLUDE'でDDLReplicationLevel=3の場合は、スタンバイ・マスターで順序を作成または削除できます。

例: アクティブ・スタンバイ・ペアのDDLの変更

例7-1 表を作成し、アクティブ・スタンバイ・ペアに含める

アクティブ・データベースで、DDLReplicationLevelを2に、DDLReplicationActionを'INCLUDE'に設定します。

Command > ALTER SESSION SET ddl_replication_level=2;
Session altered.
Command > ALTER SESSION SET ddl_replication_action='INCLUDE';
Session altered.

表を作成します。表には主キーまたは索引が含まれている必要があります。

Command > CREATE TABLE tabinclude (col1 NUMBER NOT NULL PRIMARY KEY);
Table created.

tabincludeに1行挿入します。

Command > INSERT INTO tabinclude VALUES (55);
1 row inserted.

スタンバイ・データベースで、INSERT文がレプリケートされていることを確認します。これは、tabinclude表がアクティブ・スタンバイ・ペアに含まれていることを示します。

Command > SELECT * FROM tabinclude;
< 55 >
1 row found.

または、ttIsql repschemesコマンドを使用して、どの表がアクティブ・スタンバイ・ペアに含まれているかを確認します。

例7-2 表を作成し、後からアクティブ・スタンバイ・ペアに追加する

アクティブ・データベースで、DDLReplicationLevelを2に、DDLReplicationActionを'EXCLUDE'に設定します。

Command> ALTER SESSION SET ddl_replication_level=2;
Session altered.
Command> ALTER SESSION SET ddl_replication_action='exclude';
Session altered.

主キーまたは索引を含まない表を作成します。その表をアクティブ・スタンバイ・ペアに含めてみます。

Command> CREATE TABLE newtab (a NUMBER NOT NULL);
Command> ALTER ACTIVE STANDBY PAIR INCLUDE TABLE newtab;
8000: No primary or unique index on non-nullable column found for replicated
table TERRY.NEWTAB
The command failed.

表に索引を作成します。その表をアクティブ・スタンバイ・ペアに含めます。

Command> CREATE UNIQUE INDEX ixnewtab ON newtab(a);
Command> ALTER ACTIVE STANDBY PAIR INCLUDE TABLE newtab;

表に1行挿入します。

Command> INSERT INTO newtab VALUES (5);
1 row inserted.

スタンバイ・データベースで、行が挿入されていることを確認します。

Command> SELECT * FROM newtab;
< 5 >
1 row found.

この例では、表をアクティブ・スタンバイ・ペアに含めるのに主キーを必要としない場合について示しています。

例7-3 CREATE INDEXがレプリケートされる

アクティブ・データベースで、DDLReplicationLevel=2およびDDLReplicationAction='INCLUDE'を設定します。

Command> ALTER SESSION SET ddl_replication_level=2;
Session altered.
Command> ALTER SESSION SET ddl_replication_action='include';
Session altered.

主キーを含む表を作成します。表は自動的にアクティブ・スタンバイ・ペアに含められます。

Command> CREATE TABLE tab2 (a NUMBER NOT NULL, b NUMBER NOT NULL,
> PRIMARY KEY (a));

表に索引を作成します。

Command> CREATE UNIQUE INDEX ixtab2 ON tab2 (b);

スタンバイ・データベースで、CREATE INDEX文がレプリケートされていることを確認します。

Command> indexes;

Indexes on table TERRY.TAB2:
IXTAB2: unique T-tree index on columns:
B
TAB2: unique T-tree index on columns:
A
2 indexes found.

Indexes on table TERRY.NEWTAB:
NEWTAB: unique T-tree index on columns:
A
1 index found.

Indexes on table TERRY.TABINCLUDE:
TABINCLUDE: unique T-tree index on columns:
A
1 index found.
4 indexes found on 3 tables.

例7-4 CREATE SYNONYMがレプリケートされる

DDLReplicationLevelはデフォルトの2に設定されています。tabincludeのシノニムを作成します。

Command> CREATE SYNONYM syntabinclude FOR tabinclude;
Synonym created.

スタンバイ・データベースで、ttIsql synonymsコマンドを使用して、CREATE SYNONYM文がレプリケートされていることを確認します。

Command> synonyms;
TERRY.SYNTABINCLUDE
1 synonym found.

アクティブ・スタンバイ・ペアへのその他の変更

アクティブ・スタンバイ・ペアに次の変更を加えるには、レプリケーション・エージェントを停止する必要があります。

- キャッシュ・グループを含めるまたは除外する。

- サブスクライバを追加または削除する。

- STORE句の値を変更する。

- ネットワーク操作を変更する(ADD ROUTE句またはDROP ROUTE句)。

上記のリストに従ってアクティブ・スタンバイ・ペアを変更するには、次のタスクを実行します。

1. アクティブ・データベースでレプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。

2. アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれている場合、アクティブ・データベースでキャッシュ・エージェントを停止します。

3. ALTER ACTIVE STANDBY PAIR文を使用して、レプリケーション・スキームを変更します。「例: アクティブ・スタンバイ・ペアの変更」を参照してください。

4. アクティブ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

5. アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれている場合、アクティブ・データベースでキャッシュ・エージェントを起動します。

6. スタンバイ・データベースおよびサブスクライバを破棄します。

7. アクティブ・データベースをスタンバイ・データベースに複製します。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれている場合、キャッシュ・グループを保持するには、ttRepAdminで-keepCGコマンドライン・オプションを使用します。「データベースの複製」を参照してください。

8. スタンバイ・データベースでレプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

9. スタンバイ・データベースがSTANDBY状態になるまで待機します。状態を確認するには、ttRepStateGet組込みプロシージャを使用します。

10. アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれている場合、ttCacheStart組込みプロシージャまたはttAdmin -cacheStartユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを起動します。

11. スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれている場合、ttRepAdminで-noKeepCGコマンドライン・オプションを使用し、サブスクライバでキャッシュ・グループを通常のTimesTen表に変換します。「データベースの複製」を参照してください。

12. サブスクライバでレプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでエージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

例: アクティブ・スタンバイ・ペアの変更

例7-5 アクティブ・スタンバイ・ペアへのサブスクライバの追加

アクティブ・スタンバイ・ペアにサブスクライバ・データベースを追加します。

ALTER ACTIVE STANDBY PAIR
ADD SUBSCRIBER sub1;

例7-6 アクティブ・スタンバイ・ペアからのサブスクライバの削除

アクティブ・スタンバイ・ペアからサブスクライバ・データベースを削除します。

ALTER ACTIVE STANDBY PAIR
DROP SUBSCRIBER sub1
DROP SUBSCRIBER sub2;

例7-7 サブスクライバのPORTおよびTIMEOUT設定の変更

サブスクライバsub1およびsub2のPORTおよびTIMEOUT設定を変更します。

ALTER ACTIVE STANDBY PAIR
ALTER STORE sub1 SET PORT 23000 TIMEOUT 180
ALTER STORE sub2 SET PORT 23000 TIMEOUT 180;

例7-8 アクティブ・スタンバイ・ペアへのキャッシュ・グループの追加

アクティブ・スタンバイ・ペアに1つのキャッシュ・グループを追加します。

ALTER ACTIVE STANDBY PAIR
INCLUDE CACHE GROUP cg0;

8 Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理

Oracle Clusterwareは、アプリケーションを監視および制御して高可用性を実現します。次の項では、Oracle Clusterwareを使用して、TimesTenアクティブ・スタンバイ・ペアの可用性を管理する方法を説明します。

注意:
Oracle Clusterwareの詳細は、Oracle Databaseドキュメントの『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- Oracle ClusterwareがTimesTenを管理する方法の概要

- cluster.oracle.iniファイルによるOracle Clusterware管理の構成

- クラスタの作成および初期化

- TimesTenキャッシュ・グリッドとOracle Clusterwareの併用

- 障害からのリカバリ

- Clusterwareによる管理

- クラスタ・ステータスの監視

Oracle ClusterwareがTimesTenを管理する方法の概要

Oracle Clusterwareを使用して管理できるのは次の構成です。

- 読取り専用サブスクライバを持つ(または持たない)アクティブ・スタンバイ・ペア

- AWTキャッシュ・グループ、読取り専用キャッシュ・グループおよびグローバル・キャッシュ・グループが構成された(読取り専用サブスクライバを持つ(または持たない))アクティブ・スタンバイ・ペア

図8-1に、同じローカル・ネットワークに1つの読取り専用サブスクライバを持つアクティブ・スタンバイ・ペアを示します。アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバは異なるノードにあります。TimesTenを実行しているがアクティブ・スタンバイ・ペアの一部ではないノードが2つあります。アクティブ・データベースの更新は、アプリケーションによって行われます。スタンバイおよびサブスクライバからの読取りもアプリケーションによって行われます。すべてのノードは共有記憶域に接続されています。

図8-1 1つのサブスクライバを持つアクティブ・スタンバイ・ペア

Oracle Clusterwareを使用すると、ノード障害およびその他のイベントに対応して、TimesTenデータベースおよびアプリケーションの起動、監視および自動フェイルオーバーを行うことができます。詳細は、「Clusterwareによる管理」および「障害からのリカバリ」を参照してください。

Oracle Clusterwareは、TimesTenの2つの可用性レベルで実装できます。

- 基本的な可用性レベルでは、クラスタ内の2つのマスター・ノードおよび最大127の読取り専用サブスクライバ・ノードが管理されます。アクティブ・スタンバイ・ペアは、ローカル・ホスト名またはIPアドレスを使用して定義されます。両方のマスター・ノードに障害が発生すると、ユーザーが介入してアクティブ・スタンバイ・スキームを新しいホストに移行する必要があります。両方のマスター・ノードに障害が発生すると、Oracle Clusterwareによってユーザーへの通知が行われます。

- 高度な可用性レベルでは、アクティブ、スタンバイおよび読取り専用サブスクライバ・データベースの仮想IPアドレスが使用されます。初期アクティブ・スタンバイ・ペアの一部ではない追加のノードをクラスタに含めることもできます。障害が発生した場合、仮想IPアドレスを使用することで、追加のノードの1つが、障害の発生したノードの役割を自動的に引き継ぐことができます。

注意:
アプリケーションがクライアント/サーバー構成のTimesTenに接続している場合、自動クライアント・フェイルオーバーによって、クライアントは、障害が発生した後にアクティブな役割を持つマスター・データベースに自動的に再接続できます。『Oracle TimesTen In-Memory Databaseリファレンス』のアクティブ・スタンバイ・ペアに対するクライアント・フェイルオーバーの使用に関する説明およびTTC_FailoverPortRangeの説明を参照してください。

ttCWAdminユーティリティを使用して、Oracle Clusterwareで管理されているクラスタ内のTimesTenアクティブ・スタンバイ・ペアを管理します。各アクティブ・スタンバイ・ペアの構成は、cluster.oracle.iniという初期化ファイルに手動で作成されます。このファイルの情報は、Oracle Clusterwareのリソースを作成する場合に使用されます。リソースは、TimesTenデーモン、TimesTenデータベース、TimesTenプロセス、ユーザー・アプリケーションおよび仮想IPアドレスの管理に使用されます。クラスタ内のホストからcluster.oracle.iniファイルへのアクセスおよび読取りが可能な間は、ttCWAdminユーティリティをこのホストから実行できます。ttCWAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCWAdminに関する説明を参照してください。cluster.oracle.iniファイルの詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。

必要な権限

ttCWAdminコマンドの実行に必要な権限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCWAdminに関する説明を参照してください。

ハードウェアおよびソフトウェアの要件

TimesTenでは、WindowsプラットフォームにおけるClusterwareはサポートされていません。

TimesTenは、TimesTenアクティブ・スタンバイ・ペア・レプリケーションを備えたOracle Clusterwareリリース11.2.0.2および11.2.0.3をサポートします。ネットワークと記憶域の要件およびOracle Clusterware構成ファイルの情報は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Oracle ClusterwareおよびTimesTenは、すべてのノードで同じ場所にインストールされている必要があります。TimesTenインスタンス管理者は、同じUNIXプライマリ・グループにOracle Clusterwareインストール所有者として属している必要があります。

注意:
/tmpディレクトリには、必須のTimesTen Oracle Clusterwareディレクトリが含まれています。それらの名前には、接頭辞crsTTが付いています。削除しないでください。

各ホストのクロックの誤差が250ミリ秒以内であるように、すべてのホストがネットワーク・タイム・プロトコル(NTP)または同様のシステムを使用する必要があります。各ノードのシステム・クロックの同期がとられるように調整する場合は、時間をさかのぼって設定しないでください。

制限されたコマンドおよびSQL文

Oracle ClusterwareをTimesTenと組み合せて使用すると、アクティブ・マスター上で、アクティブ・スタンバイ・ペア・レプリケーション・スキームが作成(ttCWAdmin -createコマンドを使用)、および削除(ttCWAdmin -dropコマンドを使用)されます。ttCWAdmin -createコマンドとttCWAdmin -dropコマンドの間では、次のコマンドまたはSQL文のいずれも実行できません。ただし、これらのコマンドまたはSQLステートメントは、ttCWAdmin -beginAlterSchemaコマンドとttCWAdmin -endAlterSchemaコマンドを使用する場合に実行できます(「スキーマの変更」を参照)。

- CREATE ACTIVE STANDBY PAIR、ALTER ACTIVE STANDBY PAIRおよびDROP ACTIVE STANDBY PAIRのSQL文によるアクティブ・スタンバイ・ペアの作成、変更または削除。

- ttAdminユーティリティの-repStartオプションおよび-repStopオプション、またはttRepStartまたはttRepStopの組込みプロシージャのいずれかによる、レプリケーション・エージェントの起動または停止。

- ttAdminユーティリティの-cacheStartオプションおよび-cacheStopオプション、またはttCacheStartおよびttCacheStopの組込みプロシージャのいずれかによる、アクティブ・スタンバイ・ペア作成後のキャッシュ・エージェントの起動または停止。

- ttRepAdminユーティリティの-duplicateオプションによるデータベースの複製。

- クラスタ内のアクティブ・スタンバイ・ペアがグリッドのメンバーである場合の、キャッシュ・グリッドを管理するための組込みプロシージャの実行。

また、ttCWAdmin -shutdownをコールする前にttDaemonAdmin -stopをコールしないでください。

Oracle Clusterwareと統合されたTimesTenでは、このような操作は、ttCWAdminユーティリティおよびcluster.oracle.iniファイルで指定された属性によって行われます。

組込みやユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。SQL文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。

cluster.oracle.iniファイルによるOracle Clusterware管理の構成

cluster.oracle.iniファイルの情報は、TimesTenデータベース、TimesTenプロセス、ユーザー・アプリケーションおよび仮想IPアドレスを管理するOracle Clusterwareリソースの作成に使用されます。cluster.oracle.iniという初期化ファイルをテキスト・ファイルとして作成します。

注意:
cluster.oracle.iniファイルで使用できるすべての属性の詳細は、付録A「Oracle ClusterwareのTimesTen構成属性」を参照してください。

ttCWAdmin -createコマンドはこのファイルの構成情報を読り取るため、テキスト・ファイルの場所はttCWAdminからアクセス可能かつ読取り可能である必要があります。ttCWAdminユーティリティを使用して、Oracle Clusterwareで管理されているクラスタ内のTimesTenアクティブ・スタンバイ・ペアを管理します。

このファイルは、アクティブ・データベースのホストにあるTimesTenデーモン・ホーム・ディレクトリに置くことをお薦めします。ただし、ttCWAdmin -createコマンドを実行するホストと同じホストにある任意のディレクトリまたは共有ドライブにこのファイルを置くこともできます。

このファイルのデフォルトの場所は、install_dir/infoディレクトリです。このファイルを別の場所に置く場合は、-ttclusteriniオプションを指定して場所のパスを識別します。

cluster.oracle.iniファイルのエントリ名は、sys.odbc.iniファイルの既存のシステムDSNと同じである必要があります。たとえば、[basicDSN]は、「基本的な可用性の構成」で説明されているcluster.oracle.iniファイル内のエントリ名です。また、[basicDSN]は、各ホストのsys.odbc.iniファイル内のDataStoreおよびData Source Nameデータ・ストア属性である必要があります。たとえば、host1にあるDSN basicDSNのsys.odbc.iniファイルは次のようになります。

[basicDSN]
DataStore=/path1/basicDSN
LogDir=/path1/log
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

host2にあるbasicDSNのsys.odbc.iniファイルには異なるパスを指定できますが、その他すべての属性は同じである必要があります。

[basicDSN]
DataStore=/path2/basicDSN
LogDir=/path2/log
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

次の項では、cluster.oracle.iniファイルのサンプル構成を示します。

- 基本的な可用性の構成

- 高度な可用性の構成

- アクティブ・スタンバイ・ペアへのキャッシュ・グループの挿入

- キャッシュ・グリッドへのアクティブ・スタンバイ・ペアの挿入

- アプリケーション・フェイルオーバーの実装

- 両方のマスター・ノードの永続的な障害からのリカバリ

- RepDDL属性の使用

基本的な可用性の構成

この例では、サブスクライバを持たないアクティブ・スタンバイ・ペアを示します。アクティブ・データベースのホストは、リストの最初のMasterHost (host1)で、スタンバイ・データベースのホストは、2つ目のMasterHost (host2)です。リスト内の各ホストはカンマで区切ります。必要に応じて、読みやすくするために空白を含めることができます。

[basicDSN]
MasterHosts=host1,host2

次の例では、host3にある、1つのサブスクライバを持つアクティブ・スタンバイ・ペアのcluster.oracle.iniファイルを示します。

[basicSubscriberDSN]
MasterHosts=host1,host2
SubscriberHosts=host3

高度な可用性の構成

高度な可用性を実現するには、予備のマスター・ホストまたはサブスクライバ・ホストを構成します。これらのホストは、アクティブ・スタンバイ・ペア・レプリケーション・スキームで使用されるマスター・ホストまたはサブスクライバ・ホストが予期しないシャットダウンやリカバリ不能なエラーの発生により置換えが必要になるまで、アイドル状態に維持されます。

「基本的な可用性の構成」で説明されているように、cluster.oracle.iniファイルのMasterHosts属性は、マスター・ノードとして使用されるホストを構成します。アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、2つのマスター・ノードのみ必要です。障害が発生すると、停止していないホストがアクティブ・データベースとなり(すでにアクティブ・データベースでない場合)、停止したホストはリカバリ後にスタンバイ・マスターとなります。ただし、停止したホストをリカバリできず、cluster.oracle.iniファイルで3つ以上のホストをマスター・ホストとして指定している場合、リスト内の次のマスター・ホストがリカバリ不能なマスター・ポストを置き換えるようにインスタンス化されます。

たとえば、次の例は複数マスター・ホストの構成を示します。最初の2つのマスター・ホスト(host1およびhost2)はアクティブ・マスターおよびスタンバイ・マスターとして使用され、後半の2つのマスター・ホスト(host3およびhost4)はリカバリ不能な障害が発生した場合にhost1またはhost2のいずれかを置き換えるために使用されます。

MasterHosts=host1,host2,host3,host4

3つ以上のホストを構成する場合、TimesTenリソースを管理するOracle Clusterwareリソースのみで使用される2つの仮想IP (VIP)アドレスも構成する必要があります。これらのVIPアドレスを使用することにより、レプリケーションを管理するTimesTen内部プロセスは、リカバリ不能なホスト・エラーにより発生するいずれのマスター・ホスト変更の影響も受けなくなります。

注意:
高度な可用性で使用されるこれらのVIPアドレスを管理するOracle Clusterwareリソースは、ttCWAdmin -createVIPsコマンドを使用して作成されます(「仮想IPアドレスを管理するためのOracle Clusterwareリソースを作成する」を参照)。

これらのVIPアドレスは、Oracle Clusterwareで使用するために定義されている他のいずれのVIPアドレスまたはユーザー・アプリケーションにより使用されるいずれのVIPアドレスとも異なる必要があります。さらに、アプリケーションがこれらのVIPアドレスを使用すると、マスター・ホストで障害(リカバリ可能またはリカバリ不可能)が発生したときにアプリケーションでエラーが発生することがあります。ユーザー・アプリケーションは、クライアント・フェイルオーバーの方法として、またはアクティブ・データベースとスタンバイ・マスターが切り替わったときに自身を隔離するための方法として、これらのVIPアドレスを使用することはできません。

2つのVIPアドレスをMasterVIPパラメータに指定します。アクティブ・スタンバイ・ペアのレプリケーション・スキームの各マスター・ホストに1つずつです。TimesTenクラスタに指定されたVIPアドレスは、Oracle Clusterwareですでに定義および使用されているVIPアドレスとは異なる必要があります。特に、Oracle Clusterwareのインストール時に指定されたVIPアドレスをTimesTenで使用することはできません。

MasterVIP=192.168.1.1, 192.168.1.2

次のパラメータも、cluster.oracle.iniファイル内で高度な可用性に関連付けられます。

- MasterHostsに類似するSubscriberHostsは、サブスクライバ・データベースを含むことができるホストの名前をリストします。

- MasterVIPに類似するSubscriberVIPは、サブスクライバ・ノードを管理するためにTimesTenが内部で使用できるVIPアドレスを提供します。

- VIPInterfaceは、パブリック・ネットワーク・アダプタの名前です。

- VIPNetMaskは、仮想IPアドレスのネットマスクを定義します。

次の例では、アクティブ・データベースおよびスタンバイ・データベースのホストは、それぞれhost1およびhost2です。リカバリ不能なエラーが発生した場合にインスタンス化できるホストは、host3およびhost4です。サブスクライバ・ノードはありません。VIPInterfaceは、パブリック・ネットワーク・アダプタの名前です。VIPNetMaskは、仮想IPアドレスのネットマスクを定義します。

[advancedDSN]
MasterHosts=host1,host2,host3,host4
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0

次の例では、単一のサブスクライバがhost4上に構成されます。SubscriberHostsには、マスター・データベースのフェイルオーバーに使用できる追加のホストが1つと、サブスクライバ・データベースのフェイルオーバーに使用できる追加のノードが1つ定義されます。MasterVIPおよびSubscriberVIPは、マスター・データベースおよびサブスクライバ・ホストに対して定義されている仮想IPアドレスを指定します。

[advancedSubscriberDSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4,host5
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0

追加のマスター・ノードが次のようになっていることを確認します。

- TimesTenがインストールされている。

- ダイレクト・リンクのアプリケーションがインストールされている(構成の一部である場合)。「アプリケーション・フェイルオーバーの実装」を参照してください。

アクティブ・スタンバイ・ペアへのキャッシュ・グループの挿入

アクティブ・スタンバイ・ペアが1つ以上のAWTまたは読取り専用キャッシュ・グループをレプリケートする場合、CacheConnect属性をyに設定します。

この例では、高度な可用性構成で1つのサブスクライバを持つアクティブ・スタンバイ・ペアを指定します。アクティブ・スタンバイ・ペアによって、1つ以上のキャッシュ・グループがレプリケートされます。

[advancedCacheDSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4, host5
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0
CacheConnect=y

キャッシュ・グリッドへのアクティブ・スタンバイ・ペアの挿入

アクティブ・スタンバイ・ペアがキャッシュ・グリッドのメンバーになっている場合、GridPort属性を設定して、アクティブ・データベースとスタンバイ・データベースにポート番号を割り当てます。

この例では、高度な可用性構成でサブスクライバを持たないアクティブ・スタンバイ・ペアを指定します。そのアクティブ・スタンバイ・ペアは、キャッシュ・グリッドのメンバーになっています。

[advancedGridDSN]
MasterHosts=host1,host2,host3
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
CacheConnect=y
GridPort=16101, 16102

キャッシュ・グリッドとOracle Clusterwareの併用の詳細は、「TimesTenキャッシュ・グリッドとOracle Clusterwareの併用」を参照してください。

アプリケーション・フェイルオーバーの実装

Oracle Clusterwareと統合されたTimesTenでは、アクティブ・スタンバイ・ペアの任意のデータベースにリンクされたTimesTenアプリケーションのフェイルオーバーを簡素化できます。TimesTenでは、ダイレクト・リンクのアプリケーションと、Oracle ClusterwareおよびTimesTenと同じホストにあるクライアント/サーバー・アプリケーションの両方を管理できます。

TimesTenアプリケーションのフェイルオーバーに必要なcluster.oracle.iniファイルの属性は、次のとおりです。

- AppName: Oracle Clusterwareで管理されるアプリケーションの名前。

- AppStartCmd: アプリケーションを起動するコマンドライン。

- AppStopCmd: アプリケーションを停止するコマンドライン。

- AppCheckCmd: AppNameで指定されたアプリケーションのステータスを確認するアプリケーションを実行するためのコマンドライン。

- AppType: アプリケーションのリンク先となるデータベースを定義します。使用可能な値は、Active、Standby、DualMaster、Subscriber(すべて)およびSubscriber[index]です。

AppFailureThreshold、DatabaseFailoverDelay、AppScriptTimeoutなど、構成可能なオプションの属性が複数あります。すべてのオプションの属性(およびそのデフォルト値)については、表A-3「オプションの属性」を参照してください。

TimesTenアプリケーション・モニター・プロセスは、ユーザー指定のスクリプトまたはAppCheckCmdで指定されたプログラムを使用して、アプリケーションを監視します。アプリケーションのステータスを確認するスクリプトは、成功の場合は0を返し、失敗の場合は0以外を返すように記述されている必要があります。0(ゼロ)以外の値が検出されると、Oracle Clusterwareは、障害が発生したアプリケーションをリカバリするためのアクションを実行します。

この例では、サブスクライバを持たないアクティブ・スタンバイ・ペアに対して構成されている高度な可用性を示します。readerアプリケーションは、スタンバイ・データベースのデータを問い合せるアプリケーションです。AppStartCmd、AppStopCmdおよびAppCheckCmdには、start、stopおよびcheckコマンドなどの引数を含めることができます。

注意:
AppStartCmd、AppStopCmdおよびAppCheckCmdの値に引用符を使用しないでください。

[appDSN]
MasterHosts=host1,host2,host3,host4
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
AppName=reader
AppType=Standby
AppStartCmd=/mycluster/reader/app_start.sh start
AppStopCmd=/mycluster/reader/app_stop.sh stop
AppCheckCmd=/mycluster/reader/app_check.sh check

2つ以上のアプリケーションのフェイルオーバーを構成できます。AppNameを使用してアプリケーションを指定し、AppName属性のすぐ後に続くAppType、AppStartCmd、AppStopCmdおよびAppCheckCmdの値を指定します。読みやすくするために空白行を含めることができます。次に例を示します。

[app2DSN]
MasterHosts=host1,host2,host3,host4
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0

AppName=reader
AppType=Standby
AppStartCmd=/mycluster/reader/app_start.sh
AppStopCmd=/mycluster/reader/app_stop.sh
AppCheckCmd=/mycluster/reader/app_check.sh

AppName=update
AppType=Active
AppStartCmd=/mycluster/update/app2_start.sh
AppStopCmd=/mycluster/update/app2_stop.sh
AppCheckCmd=/mycluster/update/app2_check.sh

AppTypeをDualMasterに設定すると、アプリケーションはアクティブ・ホストとスタンバイ・ホストの両方で起動します。アクティブ・ホストでアプリケーションが停止すると、そのホスト上のアクティブ・データベースおよびその他すべてのアプリケーションがスタンバイ・ホストにフェイルオーバーします。AppFailureInterval、AppRestartAttemptsおよびAppUptimeThreshold属性を設定することによって、障害間隔、再起動の試行回数および稼働時間のしきい値を構成できます。これらの属性にはデフォルト値があります。次に例を示します。

[appDualDSN]
MasterHosts=host1,host2,host3,host4
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
AppName=update
AppType=DualMaster
AppStartCmd=/mycluster/update/app2_start.sh
AppStopCmd=/mycluster/update/app2_stop.sh
AppCheckCmd=/mycluster/update/app2_check.sh
AppRestartAttempts=5
AppUptimeThreshold=300
AppFailureInterval=30

注意:
すべての構成属性の詳細は、付録A「Oracle ClusterwareのTimesTen構成属性」を参照してください。

両方のマスター・ノードの永続的な障害からのリカバリ

両方のマスター・ノードに障害が発生し、その後復旧した場合、Oracle Clusterwareは、自動的にマスター・データベースをリカバリできます。一時的な二重の障害から自動リカバリするには、次の条件が満たされている必要があります。

- アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。

- AutoRecoverがyに設定されている。

- RepBackupDirが共有記憶域のディレクトリを指定している。

- RepBackupPeriodが0より大きい値に設定されている。

両方のマスター・ノードに永続的な障害が発生した場合、Oracle Clusterwareは、自動的にマスター・データベースを2つの新しいノードにリカバリできます。次の条件が満たされている必要があります。

- 高度な可用性(仮想IPアドレスおよび少なくとも4つのホスト)が構成されている。

- アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートしていない。

- キャッシュ・グリッドが構成されていない。

- RETURN TWOSAFEが指定されていない。

- AutoRecoverがyに設定されている。

- RepBackupDirが共有記憶域のディレクトリを指定している。

- RepBackupPeriodが0より大きい値に設定されている。

TimesTenは最初にアクティブ・データベースの全体バックアップを実行し、次に増分バックアップを実行します。オプションの属性RepFullBackupCycleを指定すると、TimesTenがその後の全体バックアップを実行するタイミングを管理できます。デフォルトでは、TimesTenは、増分バックアップを5回実行するたびに完全バックアップを1回実行します。

RepBackupDirおよびRepBackupPeriodをバックアップに構成している場合、TimesTenは、アクティブになるすべてのマスター・データベースのバックアップを実行します。データベースが再度アクティブにならないかぎり、アクティブからスタンバイになったデータベースに対して実行されたバックアップは削除されません。2つの完全なデータベース・バックアップ用に十分な共有記憶域が必要です。ttCWAdmin -restoreコマンドによって、正しいバックアップ・ファイルが自動的に選択されます。

増分バックアップでは、トランザクション・ログ・ファイルのログ・レコードの量が増えます。RepBackupPeriodおよびRepFullBackupCycleの値を十分に小さくし、トランザクション・ログ・ファイルのログ・レコードが大量にならないようにします。

この例では、自動リカバリの属性設定を示します。

[autorecoveryDSN]
MasterHosts=host1,host2,host3,host4
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
AutoRecover=y
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600

アクティブ・スタンバイ・ペアにキャッシュ・グループがある場合、または両方のマスター・ホストの障害から手動でリカバリする場合は、AutoRecoverがn(デフォルト)に設定されていることを確認します。手動リカバリでは、次のこと必要です。

- RepBackupDirが共有記憶域のディレクトリを指定している。

- RepBackupPeriodが0より大きい値に設定されている。

この例では、手動リカバリの属性設定を示します。AutoRecoverのデフォルト値はnであるため、このファイルには含まれていません。

[manrecoveryDSN]
MasterHosts=host1,host2,host3
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600

RepDDL属性の使用

RepDDL属性は、アクティブ・スタンバイ・ペアを作成するSQL文を表します。RepDDL属性はオプションです。これは、アクティブ・スタンバイ・ペアから表、キャッシュ・グループおよび順序を除外する場合に使用できます。

RepDDLをcluster.oracle.iniファイルに含める場合は、ReturnServiceAttribute、MasterStoreAttributeまたはSubscriberStoreAttributeをcluster.oracle.iniファイルに指定しないでください。これらのレプリケーション設定は、RepDDL属性に含めるようにしてください。

RepDDLの値を指定する場合、データベース・ファイル名の接頭辞に<DSN>マクロを使用します。マスター・ホスト名を指定するには、<MASTERHOST[1]>および<MASTERHOST[2]>マクロを使用します。TimesTenは、構成で仮想IPアドレスが使用されているかどうに応じて、MasterHostsまたはMasterVIP属性の正しい値に置換します。同様に、サブスクライバ・ホスト名を指定するには、<SUBSCRIBERHOST[n]>マクロを使用します(ここで、nは、1からSubscriberHosts属性値の合計数までの数値、仮想IPアドレスが使用されている場合は1からSubscriberVIP属性値の合計数までの数値です)。

RepDDL属性を使用して、アクティブ・スタンバイ・ペアから表、キャッシュ・グループおよび順序を除外します。

[excludeDSN]
MasterHosts=host1,host2,host3,host4
SubscriberHosts=host5,host6
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0
RepDDL=CREATE ACTIVE STANDBY PAIR \
<DSN> ON <MASTERHOST[1]>, <DSN> ON <MASTERHOST[2]>
SUBSCRIBER <DSN> ON <SUBSCRIBERHOST[1]>\
EXCLUDE TABLE pat.salaries, \
EXCLUDE CACHE GROUP terry.salupdate, \
EXCLUDE SEQUENCE ttuser.empcount

レプリケーション・エージェントのトランスミッタは、次の方法でルート情報を取得します(優先順に示します)。

1. RepDDL設定のROUTE句から(ROUTE句が指定されている場合)。高度な可用性を構成している場合は、ROUTE句を指定しないでください。

2. ローカル・ホストとリモート・ホストのプライベート・ホスト名およびパブリック・ホスト名を提供するとともに、リモート・デーモンのポート番号を提供するOracle Clusterwareから。プライベート・ホスト名は、パブリック・ホスト名より優先されます。レプリケーション・エージェントのトランスミッタがIPCソケットに接続できない場合、Oracle Clusterwareがレプリケーション・スキームに関して保持している情報を使用してリモート・デーモンへの接続を試行します。

3. アクティブ・ホストおよびスタンバイ・ホストから。失敗した場合、レプリケーション・エージェントはホスト名に基づいた接続方法を選択します。

この例では、RepDDLにROUTE句を指定します。

[routeDSN]
MasterHosts=host1,host2,host3,host4
RepDDL=CREATE ACTIVE STANDBY PAIR \
<DSN> ON <MASTERHOST[1]>, <DSN> ON <MASTERHOST[2]>\
ROUTE MASTER <DSN> ON <MASTERHOST[1]>  SUBSCRIBER <DSN> ON <MASTERHOST[2]>\
MASTERIP "192.168.1.2" PRIORITY 1\
SUBSCRIBERIP "192.168.1.3" PRIORITY 1\
MASTERIP "10.0.0.1" PRIORITY 2\
SUBSCRIBERIP "10.0.0.2" PRIORITY 2\
MASTERIP "140.87.11.203" PRIORITY 3\
SUBSCRIBERIP "140.87.11.204" PRIORITY 3\
ROUTE MASTER <DSN> ON <MASTERHOST[2]>  SUBSCRIBER <DSN> ON <MASTERHOST[1]>\
MASTERIP "192.168.1.3" PRIORITY 1\
SUBSCRIBERIP "192.168.1.2" PRIORITY 1\
MASTERIP "10.0.0.2" PRIORITY 2\
SUBSCRIBERIP "10.0.0.1" PRIORITY 2\
MASTERIP "140.87.11.204" PRIORITY 3\
SUBSCRIBERIP "140.87.11.203" PRIORITY 3\

クラスタの作成および初期化

クラスタを作成および初期化するには、次の手順を実行します。

- Oracle Clusterwareのインストール

- 各ホストへのTimesTenのインストール

- TimesTenクラスタ情報の登録

- TimesTenクラスタ・エージェントの起動

- 1つのホストでのTimesTenデータベースの作成および移入

- その他のホストでのシステムDSNファイルの作成

- cluster.oracle.iniファイルの作成

- 仮想IPアドレスを管理するためのOracle Clusterwareリソースの作成

- アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成

- アクティブ・スタンバイ・ペアおよびアプリケーションの起動

- キャッシュ・グループのロード

- クラスタへの複数のアクティブ・スタンバイ・ペアの挿入

- 障害時リカバリ・サブスクライバとしてのOracle Databaseの構成

- Oracle Clusterwareによって管理されていない読取り専用サブスクライバの構成

クラスタで複数のアクティブ・スタンバイ・ペアを使用する予定の場合は、「クラスタへの複数のアクティブ・スタンバイ・ペアの挿入」を参照してください。

リモート障害時リカバリ・サブスクライバとしてOracle Databaseを構成する場合は、「障害時リカバリ・サブスクライバとしてのOracle Databaseの構成」を参照してください。

Oracle Clusterwareによって管理されていない読取り専用サブスクライバを設定する場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの構成」を参照してください。

Oracle Clusterwareのインストール

Oracle Clusterwareをインストールします。デフォルトでは、すべてのホストで同時にインストールが実行されます。ご使用のプラットフォーム用のOracle Clusterwareのインストール・ドキュメントを参照してください。

インストールが正常に完了すると、Oracle Clusterwareは自動的に起動します。

注意:
次を実行すると、Oracle Clusterwareがクラスタ内のすべてのホストで実行されているかどうかを確認できます。

crsctl check crs -all

各ホストへのTimesTenのインストール

TimesTenをクラスタ内の各ホスト(追加のホストを含む)の同じ場所にインストールします。インスタンス名は各ホストで同じである必要があります。インスタンス管理者のユーザー名は、すべてのホストで同じである必要があります。TimesTenインスタンス管理者は、同じUNIXプライマリ・グループにOracle Clusterwareインストール所有者として属している必要があります。

インストーラによって次の値の入力を求められ、それぞれの値はttcrsagent.optionsファイルに格納されます。

- TimesTenクラスタ・エージェントに関連付けられているTCP/IPポート番号。ポート番号は、クラスタ内のすべてのノードで同じである必要があります。ポート番号を指定しない場合、TimesTenはデフォルトのTimesTenデーモンのポート番号に6を加えて、TimesTenクラスタ・エージェントに関連付けられたTCP/IPポート番号にします。したがって、TimesTenクラスタ・エージェントに関連付けられたデフォルトのデーモンのポート番号は、32ビット・システムでは53398に、64ビット・システムでは53402になります。

- Oracle Clusterwareの場所。場所は各ホストで同じである必要があります。

- スペア・ホストを含むクラスタ内のホスト(ホスト名はカンマで区切ります)。このリストは各ホストで同じである必要があります。

ttCWAdmin –initコマンドおよびttCWAdmin –shutdownコマンドでは、TimesTenクラスタを開始および停止するために、ttcrsagent.optionsファイルが使用されます。ttcrsagent.optionsファイルは、TimesTenデーモンのホーム・ディレクトリにあります。

ttcrsagent.optionsファイルを手動で変更しないでください。かわりに、TimesTenクラスタの開始後にttmodinstall -crsコマンドを使用して、このファイル内の情報を作成または変更します。また、setup.shに-recordオプションおよび-batchオプションを使用して、追加ホストに同じインストールを実行できます。

Oracle Clusterwareの現在のホーム・ロケーションはCRS_HOME環境変数に設定されています。また、ttmodinstall -crsコマンドは、プロンプトの一部としてOracle Clusterwareホームの現在の場所を示します。

注意:
ttcrsagent.optionsファイルの詳細は、「TimesTenクラスタ・エージェントの起動」を参照してください。ttmodinstallの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttmodinstallに関する説明を参照してください。

次の例は、ttcrsagent.optionsファイルの各項目を変更するときに表示されるttmodinstall -crsプロンプトを示しています。

% ttmodinstall -crs

Cannot find instance_info file : /etc/TimesTen/instance_info

Would you like to modify the existing TimesTen Replication with Oracle
Clusterware configuration? [ no ] yes

This TimesTen instance is configured to use an Oracle Clusterware installation
located in : /mydir/oracle/crs/app/11.2.0/grid
Would you like to change this value? [ no ] no

The TimesTen Clusterware agent is configured to use port 54504
Would you like to change this value? [ no ] no

The TimesTen Clusterware agent is currently configured with these nodes :

node1
node2
node3
node4

Would you like to change these values? [ no ]

Overwrite the existing TimesTen Clusterware options file? [ no ] no

TimesTenクラスタ情報の登録

TimesTenクラスタ情報は、Oracle Cluster Registry(OCR)に保存されます。rootユーザーとして、このコマンドを入力します。

ttCWAdmin -ocrConfig

Oracle ClusterwareおよびTimesTenがホストにインストールされている場合、この手順を繰り返す必要はありません。

TimesTenクラスタ・エージェントの起動

ttCWAdmin -initコマンドを実行して、クラスタ内のすべてのホストで、TimesTenクラスタ・エージェントおよびTimesTenクラスタ・デーモン・モニターを起動します。このコマンドは、ttcrsagent.optionsファイルで定義された、クラスタ内のどのホストででも実行できます。

次に例を示します。

ttCWAdmin -init

ttCWAdmin -initコマンドによって、次の操作が実行されます。

- ttcrsagent.optionsファイルを読み取り、このファイルに定義されている各ホストでTimesTenメイン・デーモンを起動します。

- クラスタ内のすべてのホストで、TimesTenクラスタ・エージェント(ttCRSAgent)およびTimesTenクラスタ・デーモン・モニター(ttCRSDaemon)が開始および登録されます。各ホストには、TimesTenのインストールのために1つのTimesTenクラスタ・エージェントと1つのTimesTenクラスタ・デーモン・モニターがあります。TimesTenクラスタ・エージェントが起動すると、Oracle Clusterwareによって各ホストでのTimesTenデーモンの監視が開始され、障害が発生するとTimesTenデーモンが再起動されます。

TimesTenクラスタ・エージェント(ttCRSAgent)およびTimesTenクラスタ・デーモン・モニター(ttCRSDaemon)をクラスタ内の特定のホストで起動および登録するには、-hostsコマンドを使用して、クラスタ内の希望のホストを指定し、起動します。

ttCWAdmin -init -hosts "host1, host2"

注意:
ttDaemonAdmin -stopコマンドを実行する前に、ttCWAdmin -shutdownを使用して、ローカル・ホストでTimesTenクラスタ・エージェントを停止する必要があります。停止しないと、クラスタ・エージェントがTimesTenデーモンを再起動します。

1つのホストでのTimesTenデータベースの作成および移入

アクティブ・データベースを配置するホストにデータベースを作成します。DSNはデータベース・ファイル名と同じである必要があります。

表、AWTキャッシュ・グループおよび読取り専用キャッシュ・グループなどのスキーマ・オブジェクトを作成し、適切なデータを使用して設定します。ただし、キャッシュ・グループを作成する前に、まず、キャッシャ・グループをロードするタイミングを決定する必要があります。

- 最高のパフォーマンスを達成するには、ttCWAdmin -createコマンドを実行する前に、キャッシュ・グループ表をOracle Database表からロードします。複製がアクティブ・マスター上で実行されてスタンバイ・マスター(およびサブスクライバ)が作成される前に初期データを使用してキャッシュ・グループをロードすると、パフォーマンスのオーバーヘッドがより小さくなります。
このオプションでは、次の手順を実行します。

1. キャッシュ・エージェントを次のように起動します。

Command> call ttCacheStart;

注意:
この時点では、ttCWAdmin -startコマンドは実行されていないため、キャッシュ・エージェントを起動できます。ttCWAdmin -startコマンドを実行すると、キャッシュ・エージェントはすでに起動されており、処理を継続することを示すメッセージが表示されます。

2. LOAD CACHE GROUP文を使用し、Oracle Database表からキャッシュ・グループ表をロードします。

3. 自動リフレッシュ・キャッシュ・グループを使用している場合、ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED文を使用して、自動リフレッシュ状態をPAUSEDに設定します。自動リフレッシュの状態は、ttCWAdmin -startコマンドの処理の一環として、ONに設定されます。

次の例は、読取り専用自動リフレッシュ・キャッシュ・グループを作成してデータをロードし、その後に自動リフレッシュの状態をpauseに設定する方法を示します。

Command> call ttCacheStart;
Command> CREATE READONLY CACHE GROUP my_cg
AUTOREFRESH MODE INCREMENTAL INTERVAL 60 SECONDS
FROM t1 (c1 NUMBER(22) NOT NULL PRIMARY KEY, c2 DATE, c3 VARCHAR(30));

Command> LOAD CACHE GROUP my_cg COMMIT EVERY 100 ROWS PARALLEL 4;
Command> ALTER CACHE GROUP my_cg SET AUTOREFRESH STATE PAUSED;

- または、ttCWAdmin -startが実行されるまで、キャッシュ・グループ表のロードを待機します(「キャッシュ・グループのロード」を参照)。データは、スタンバイ・マスターおよびすべてのサブスクライバにレプリケートされます。

その他のホストでのシステムDSNファイルの作成

クラスタに含められるすべてのホストで、システムDSN (sys.odbc.ini)ファイルを作成します。DataStore属性とData Source Nameは、cluster.oracle.iniファイルのエントリ名として同じである必要があります。sys.odbc.iniファイルの内容の詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。

cluster.oracle.iniファイルの作成

cluster.oracle.iniファイルをテキスト・ファイルとして作成します。ファイルの内容と許容可能な場所の詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。

仮想IPアドレスを管理するためのOracle Clusterwareリソースの作成

高度な可用性を実現するには、予備のマスター・ホストまたはサブスクライバ・ホストを構成します。これらのホストは、アクティブ・スタンバイ・ペア・レプリケーション・スキームで使用されるマスター・ホストまたはサブスクライバ・ホストが予期しないシャットダウンやリカバリ不能なエラーの発生により置換えが必要になるまで、アイドル状態に維持されます。これはオプションの手順で、高度な可用性を構成することを決定した場合のみ実行する必要があります。

高度な可用性を実装するために追加のマスター・ホストまたはサブスクライバ・ホストを提供することを計画している場合、仮想IPアドレスを構成する必要があります(アクティブ・スタンバイ・ペアでアクティブに使用されている各マスター・ホストおよび各サブスクライバに1つずつ)。作成する必要のある仮想IPアドレスの数は、「高度な可用性の構成」を参照してください。

この場合、次の手順を実行します。

1. Oracle Clusterwareにより管理されているTimesTenレプリケーション環境の複数のホストを管理するためのみに使用される、ネットワーク上の新しい仮想IPアドレスを指定(または作成)します。

2. 高度な可用性を構成する複数のホストを管理するために使用されるこれらのVIPアドレスを、cluster.oracle.iniファイルで構成します(「高度な可用性の構成」を参照)。

3. これらのVIPアドレスを管理するOracle Clusterwareリソースを、クラスタ内の任意のホストでrootユーザーとしてttCWAdmin -createVIPsコマンドを実行して作成します。
次に例を示します。

ttCWAdmin -createVIPs -dsn myDSN

このコマンドで作成されるVIPアドレスの名前は、network_で始まり、その後に、TimesTenインスタンス名、TimesTenインスタンス管理者およびDSNが続きます。一方、Oracle Clusterwareによる使用のために作成されるVIPアドレスは、oraで始まります。

注意:
ttCWAdmin -createVIPsコマンドを実行した後に、ttCWAdmin -createコマンドを実行する必要があります。ttCWAdmin -createコマンドの実行後に、VIPアドレスを高度な可用性のために使用することを決定した場合、次の手順を実行する必要があります。

1. ttCWadmin -dropを実行して、アクティブ・スタンバイ・ペアのレプリケーション・スキームを削除します。

2. VIPアドレスをcluster.oracle.iniファイルに追加します。

3. ttCWadmin -createVIPsを実行して、VIPアドレスを管理するためのリソースを作成します。

4. ttCWAdmin -createを実行し、Oracle Clusterwareにより管理されるアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

VIPアドレスを管理するOracle Clusterwareリソースを作成すると、これを削除するための唯一の方法は、ttCWAdmin -dropVIPsコマンドを実行することです。最初にttCWAdmin -dropコマンドを実行してから、仮想IPアドレスを削除します。

次に、仮想IPアドレスを削除する方法の例を示します。

ttCWAdmin -dropVIPs -dsn myDSN

ttCWAdmin -dropVIPsコマンドを使用する状況の例は、「クラスタからのアクティブ・スタンバイ・ペアの削除」を参照してください。

アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成

クラスタ内の任意のホストでttCWAdmin -createコマンドを実行し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

注意:
cluster.oracle.iniファイルには、ttCWAdmin -createコマンドの実行に必要な構成がふくまれているため、ttCWAdmin実行可能ファイルによってアクセス可能である必要があります。詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。

次に例を示します。

ttCWAdmin -create -dsn myDSN

ttCWAdmin -createコマンドにより、次のプロンプトが表示されます。

- ADMIN権限を持つTimesTenユーザーの名前を求めるプロンプト。キャッシュ・グループがOracle Clusterwareにより管理されている場合は、TimesTenキャッシュ・マネージャ・ユーザー名を入力します。

- 前の手順で入力したユーザー名のTimesTenパスワードを求めるプロンプト。

- キャッシュ・グループが使用されている場合は、キャッシュ・マネージャ・ユーザーと同じ名前のOracleユーザーのパスワードが求められます。このパスワードは、キャッシュ・マネージャ・ユーザーが接続したときにOraclePWD接続属性で指定されます。

- 前の手順の情報を暗号化するために使用するランダム文字列を求めるプロンプト。

cluster.oracle.iniファイルとして使用するファイルのパスと名前を指定する場合は、-ttclusteriniコマンドを使用します。

ttCWAdmin -create -dsn myDSN -ttclusterini path/to/cluster/mycluster.ini

アクティブ・スタンバイ・ペアを削除するには、ttCWAdmin -dropコマンドを次のように使用します。

ttCWAdmin -drop -dsn myDSN

注意:
アプリケーションが仮想IPアドレスを使用してTimesTenデータベースに接続する場合、仮想IPアドレスはOracle Clusterwareにより管理されるため、この接続はttCWAdmin -dropコマンドを使用して削除できます。ただし、アプリケーションがホスト名を使用してTimesTenデータベースに接続する場合、接続は削除されません。

ttCWAdmin -createコマンドとttCWAdmin -dropコマンドを使用する順序を示す例は、「クラスタでのアクティブ・スタンバイ・ペアの管理」および「アクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理」を参照してください。

アクティブ・スタンバイ・ペアおよびアプリケーションの起動

ttCWAdmin -startコマンドを任意のホストで実行し、アクティブ・スタンバイ・ペアのレプリケーション・スキームでクラスタを起動します。これによって、アクティブ･データベースでキャッシュ・エージェント(すでに起動していない場合)およびレプリケーション・エージェントが起動され、複製を実行してスタンバイ・マスター(および任意のサブスクライバ)が作成され、スタンバイ・マスター(および任意のサブスクライバ)でキャッシュ・エージェントおよびレプリケーション・エージェントが起動されます。

-noAppを指定しないと、アプリケーションも起動されます。-noAppを指定しない場合にアプリケーションを起動および停止するには、それぞれ-startAppsおよび-stopAppsコマンドを使用します。

次に例を示します。

ttCWAdmin -start -dsn myDSN

このコマンドは、アクティブ・スタンバイ・ペアの次のプロセスを開始します。

- ttCRSMaster

- ttCRSActiveService

- ttCRSsubservice

- アプリケーションAppNameの監視

次の例では、キャッシュ・エージェントおよびレプリケーション・エージェントを起動しますが、-noappコマンドが含まれているため、アプリケーションは起動しません。

ttCWAdmin -start -noapp -dsn myDSN

アプリケーションを起動および停止するには、次に示すとおり、-startAppsおよび-stopAppsコマンドを使用します。

ttCWAdmin -startapps -dsn myDSN
...
ttCWAdmin -stopapps -dsn myDSN

キャッシュ・エージェントとレプリケーション・エージェントを停止し、アプリケーションを両方のデータベースから切断するには、ttCWAdmin -stopコマンドを実行します。

ttCWAdmin -stop -dsn myDSN

注意:
アプリケーションが仮想IPアドレスを使用してTimesTenデータベースに接続する場合、仮想IPアドレスはOracle Clusterwareにより管理されるため、この接続はttCWAdmin -stopコマンドを使用して削除できます。ただし、アプリケーションがホスト名を使用してTimesTenデータベースに接続する場合、接続は削除されません。しかも、スタンバイ・マスターへのレプリケーションも発生しません。

ttCWAdmin -startコマンドとttCWAdmin -stopコマンドを使用する順序を示す例は、「クラスタでのアクティブ・スタンバイ・ペアの管理」および「アクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理」を参照してください。

キャッシュ・グループのロード

アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれており、キャッシュ・グループがすでにロードされていない場合(「1つのホストでのTimesTenデータベースの作成および移入」を参照)、LOAD CACHE GROUP文を使用し、Oracle Database表からキャッシュ・グループ表をロードします。

キャッシュ・グループをロードする状況の詳細は、「1つのホストでのTimesTenデータベースの作成および移入」を参照してください。

クラスタへの複数のアクティブ・スタンバイ・ペアの挿入

Oracle Clusterwareを使用してクラスタ内の複数のアクティブ・スタンバイ・ペアを管理する場合、cluster.oracle.iniファイルに追加の構成を含めます。すべてのTimesTenデータベースが単一ホストの同じTimesTenインスタンスに含まれる場合のみ、Oracle Clusterwareはクラスタ内の1つ以上のアクティブ・スタンバイ・ペアを管理できます。

たとえば、次のcluster.oracle.iniファイルには、同一ホストの2つのアクティブ・スタンバイ・ペアのレプリケーション・スキームの構成情報が含まれます。

注意:
cluster.oracle.iniファイルの構成属性については、付録A「Oracle ClusterwareのTimesTen構成属性」を参照してください。

[advancedSubscriberDSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4, host5
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0

[advSub2DSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4, host5
MasterVIP=192.168.1.4, 192.168.1.5
SubscriberVIP=192.168.1.6
VIPInterface=eth0
VIPNetMask=255.255.255.0

追加のレプリケーション・スキームに対して次の手順を実行します。

1. データベースを作成および移入します。

2. 仮想IPアドレスを作成します。ttCWAdmin -createVIPsコマンドを使用します。

3. アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。ttCWAdmin -createコマンドを使用します。

4. アクティブ・スタンバイ・ペアを開始します。ttCWAdmin -startコマンドを使用します。

障害時リカバリ・サブスクライバとしてのOracle Databaseの構成

プライマリ・サイトにリモート障害時リカバリ・サブスクライバとしてOracle Databaseを持つアクティブ・スタンバイ・ペアを作成できます。「アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用」を参照してください。Oracle Clusterwareは、アクティブ・スタンバイ・ペアは管理しますが、障害時リカバリ・サブスクライバは管理しません。プライマリ・サイトに障害が発生した場合、ユーザーが切替えを実行する必要があります。

Oracle Clusterwareを使用してリモート障害時リカバリ・サブスクライバを持つアクティブ・スタンバイ・ペアを管理するには、次の手順を実行します。

1. RepDDLまたはRemoteSubscriberHosts Clusterware属性を使用し、リモート障害時リカバリ・サブスクライバに関する情報を提供します。次に例を示します。

[advancedDRsubDSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4, host5
RemoteSubscriberHosts=host6
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0
CacheConnect=y

2. ttCWAdmin -createを使用し、プライマリ・サイトにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。この操作では障害時リカバリ・サブスクライバは作成されません。

3. ttCWAdmin -startを使用し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

4. アクティブ・スタンバイ・ペアによってレプリケートされるキャッシュ・グループをロードします。

5. 「障害時リカバリ・サブスクライバのローリング・アウト」の手順に従って、障害時リカバリ・サブスクライバを設定します。

Oracle Clusterwareによって管理されていない読取り専用サブスクライバの構成

Oracle Clusterwareによって管理されていない読取り専用のTimesTenサブスクライバ・データベースを含めることができます。次のタスクを実行します。

1. cluster.oracle.iniファイルにRemoteSubscriberHosts Clusterware属性を含めます。次に例を示します。

[advancedROsubDSN]
MasterHosts=host1,host2,host3
RemoteSubscriberHosts=host6
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0

2. ttCWAdmin -createを使用し、プライマリ・サイトにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

3. ttCWAdmin -startを使用し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。これによって、読取り専用サブスクライバは作成されません。

4. ttRepStateGet組込みプロシージャを使用して、スタンバイ・データベースの状態がSTANDBYであることを確認します。

5. サブスクライバ・ホストで、ttRepAdmin -duplicateオプションを使用して、スタンバイ・データベースを読取り専用サブスクライバに複製します。「データベースの複製」を参照してください。

6. サブスクライバ・ホストでレプリケーション・エージェントを起動します。

既存の構成に読取り専用サブスクライバを追加または削除する場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの追加または削除」を参照してください。

読取り専用サブスクライバを再作成する場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの再作成」を参照してください。

TimesTenキャッシュ・グリッドとOracle Clusterwareの併用

各グリッド・メンバーがアクティブ・スタンバイ・ペアである場合にキャッシュ・グリッドを管理するために、Oracle ClusterwareのTimesTen実装を使用できます。TimesTenでは、Oracle Clusterwareを使用したスタンドアロンのグリッド・メンバーの管理をサポートしていません。

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

- キャッシュ・グリッド・メンバーのクラスタの作成および初期化

- アクティブ・スタンバイ・ペア・グリッド・メンバーの障害およびリカバリ

- グリッド内のアクティブ・スタンバイ・ペアのスキーマの変更

キャッシュ・グリッド・メンバーのクラスタの作成および初期化

インストール要件については、「各ホストでのTimesTenのインストール」を参照してください。また、各グリッド・メンバーには、キャッシュ・グリッド内で一意のDSNが設定されている必要があります。

各グリッド・メンバーに対して、「クラスタの作成および初期化」で説明されているタスクを実行します。「キャッシュ・グリッドにアクティブ・スタンバイ・ペアを含める」で説明されているように、cluster.oracle.iniファイルにGridPort Clusterware属性を含めます。指定したポート番号が使用されていないことを確認します。

ttCWAdmin -startコマンドによって、キャッシュ・グリッドにグリッド・メンバーが自動的にアタッチされます。ttCWAdmin -stopコマンドによって、キャッシュ・グリッドからグリッド・メンバーが自動的にデタッチされます。

アクティブ・スタンバイ・ペア・グリッド・メンバーの障害およびリカバリ

アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードで障害が発生すると、グリッド・メンバーに障害が発生します。Oracle Clusterwareは障害が発生したグリッド・メンバーを自動的にグリッドから削除します。ただし、キャッシュ・グリッドが構成されている場合は、二重障害が発生した後、一時的であっても永続的であっても、それ以上の自動リカバリを実行することはできません。この場合、手動でのリカバリのみ許可されます。詳細は、「アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードの手動リカバリ」を参照してください。

グリッド内のアクティブ・スタンバイ・ペアのスキーマの変更

アクティブ・マスター・データベースがグリッドにアタッチされている間に、キャッシュ・グループを追加、削除または変更できます。

ttCWAdmin -beginAlterSchemaコマンドを使用して、これらのスキーマを変更します。このコマンドにより、アクティブとスタンバイの両方のマスター・ノードでレプリケーションは停止されますが、アクティブ・マスター・データベースはグリッドにアタッチされたままにすることができます。ttCWAdmin -endAlterSchemaコマンドは特定の変更をスタンバイ・マスター・データベース(およびすべてのサブスクライバ)に伝播するための複製を開始し、変更されたレプリケーション・スキームを登録し、両方のレプリケーション・エージェントを再起動し、Oracle Clustewareの制御を再び使用できるようにします。

注意:
キャッシュ・グループがレプリケーション・スキーマに含まれているため、ttCWadmin -endAlterSchemaコマンドはこの場合に複製を開始しますが、キャッシュ・グループのDDL文はレプリケートされません。詳細は、「スキーマの変更」を参照してください。

アクティブ・スタンバイ・ペアにレプリケートされた表を追加または削除する場合は、「アクティブ・スタンバイ・ペアのDDLの変更」を参照してください。

キャッシュ・グループの追加

各アクティブ・スタンバイ・ペア・グリッド・メンバーのアクティブ・データベースで、次の手順を実行します。

注意:
これらの手順は、アクティブ・スタンバイ・ペアがキャッシュ・グリッドに含まれているかどうかにかかわらず同じです。

1. ttCWAdmin -beginAlterSchemaコマンドを使用して一時的にOracle Clusterwareの管理を停止し、レプリケーション・エージェントを停止することにより、キャッシュ・グループをアクティブ・スタンバイ・ペアに追加できるようにします。

ttCWAdmin -beginAlterSchema -dsn advancedDSN

2. キャッシュ・グループを作成します。

3. キャッシュ・グループが読取り専用の場合は、読取り専用キャッシュ・グループを含めるようにアクティブ・スタンバイ・ペアを変更します。

ALTER ACTIVE STANDBY PAIR INCLUDE CACHE GROUP samplecachegroup;

4. ttCWAdmin -endAlterSchemaコマンドを実行して変更を完了します。キャッシュ・グループ・オブジェクトを追加したため、これらのスキーマの変更をスタンバイ・マスター・データベースへ伝播するためのレプリケーションが発生します。

ttCWAdmin -endAlterSchema -dsn advancedDSN

キャッシュ・グループを作成すると、いつでもそのキャッシュ・グループをロードすることができます。

キャッシュ・グループの削除

キャッシュ・グループを削除するには、次の手順を実行します。

注意:
これらの手順は、アクティブ・スタンバイ・ペアがキャッシュ・グリッドに含まれているかどうかにかかわらず同じです。

1. キャッシュ・グループをアンロードします。キャッシュ・グリッドを使用する場合は、キャッシュ・グリッドのすべてのメンバーでキャッシュ・グループをアンロードする必要があります。

CALL ttOptSetFlag('GlobalProcessing', 1);
UNLOAD CACHE GROUP samplecachegroup;

2. アクティブ・スタンバイ・ペアのアクティブ・データベースで、キャッシュ・グループの削除を有効にします。

ttCWAdmin -beginAlterSchema -dsn advancedDSN

3. キャッシュ・グループが読取り専用の場合は、読取り専用キャッシュ・グループを除外するようにアクティブ・スタンバイ・ペアを変更します。

ALTER ACTIVE STANDBY PAIR EXCLUDE CACHE GROUP samplecachegroup;

4. キャッシュ・グループが読取り専用の場合は、自動リフレッシュの状態をPAUSEDに設定します。

ALTER CACHE GROUP samplecachegroup SET AUTOREFRESH STATE PAUSED;

5. キャッシュ・グループを削除します。

DROP CACHE GROUP samplecachegroup;

6. キャッシュ・グループが読取り専用の場合は、Oracle Databaseでキャッシュ管理ユーザーとしてSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/cacheCleanUp.sqlを実行し、自動リフレッシュ操作を実装するために使用するOracle Databaseオブジェクトを削除します。

7. ttCWAdmin -endAlterSchemaコマンドを実行して変更を完了します。キャッシュ・グループ・オブジェクトを削除したため、これらのスキーマの変更をスタンバイ・マスター・データベースへ伝播するためのレプリケーションが発生します。

ttCWAdmin -endAlterSchema -dsn advancedDSN

8. 各アクティブ・スタンバイ・ペア・グリッド・メンバーのアクティブ・データベースで、手順2から7までを繰り返します。

既存のキャッシュ・グループの変更

既存のキャッシュ・グループを変更するには、「キャッシュ・グループの削除」で説明されているように、まず既存のキャッシュ・グループを削除します。その後、「キャッシュ・グループの追加」で説明されているように、キャッシュ・グループに目的の変更を追加します。

障害からのリカバリ

Oracle Clusterwareは、様々な種類の障害から自動的にリカバリできます。次の項では、いくつかの障害の例と、Oracle Clusterwareによる障害の管理方法を示します。

- Oracle Clusterwareが構成されている場合にTimesTenでリカバリを実行する方法

- アクティブ・データベースまたはそのホストで障害が発生した場合

- スタンバイ・データベースまたはそのホストで障害が発生した場合

- 読取り専用サブスクライバまたはそのホストで障害が発生した場合

- 両方のマスター・ノードで障害が発生した場合

- 3つ以上のマスター・ホストで障害が発生した場合

- アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行

Oracle Clusterwareが構成されている場合にTimesTenでリカバリを実行する方法

TimesTenデータベース・モニター(ttCRSmasterプロセス)でリカバリを実行します。forceconnectオプションを使用せずに、障害の発生したデータベースへの接続を試行します。エラー994(Data store connection terminated)で接続に失敗した場合は、データベース・モニターは10回接続を試行します。エラー707(Attempt to connect to a data store that has been manually unloaded from RAM)で接続に失敗した場合には、データベース・モニターはRAMポリシーを変更して接続を再試行します。データベース・モニターが接続できないと、接続障害エラーを返します。

データベース・モニターがデータベースに接続できた場合、次のタスクが実行されます。

- TTREP.REPLICATIONSレプリケーション表のCHECKSUM列を問い合せます。

- CHECKSUM列の値がOracle Cluster Registryに保存されているチェックサムと一致する場合は、データベース・モニターはデータベースのロールを確認します。ロールが'ACTIVE'の場合、リカバリは完了です。
ロールが'ACTIVE'でない場合は、データベース・モニターは、ローカル・データベースのレプリケーションのコミット・チケット番号(CTN)とアクティブ・データベースのCTNを問い合せて、レプリケートされていないトランザクションがあるかどうかを確認します。すべてのトランザクションがレプリケートされていれば、リカバリは完了です。

- チェックサムが一致しなかった場合、または一部のトランザクションがレプリケートされていない場合には、データベース・モニターはリモート・データベースから複製操作を実行し、ローカル・データベースを再作成します。

エラー8110または8111(マスター・キャッチアップが必要またはマスター・キャッチアップを実行中)により、データベース・モニターがデータベースへの接続に失敗した場合、forceconnect=1オプションを使用して接続を行い、マスター・キャッチアップを開始します。マスター・キャッチアップが完了すると、リカバリは完了です。エラー8112(Operation not permitted)によりマスター・キャッチアップが失敗した場合は、データベース・モニターはリモート・データベースから複製操作を実行します。マスター・キャッチアップの詳細は、「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。

その他のエラーにより接続に失敗した場合には、データベース・モニターはリモート・データベースから複製操作の実行を試みます。

複製操作では、次のことを確認します。

- リモート・データベースが使用できる。

- レプリケーション・エージェントが稼働している。

- リモート・データベースに適切なロールが設定されている。スタンバイ・データベースの作成のために複製操作が試行される場合は、ロールは'ACTIVE'に設定されている必要があります。読取り専用サブスクライバの作成のために複製操作が試行される場合には、ロールは'STANDBY'または'ACTIVE'に設定されている必要があります。

複製操作の条件が満たされている場合は、障害が発生した既存のデータベースは破棄され、複製操作が開始されます。

アクティブ・データベースまたはそのホストで障害が発生した場合

アクティブ・データベースが存在するノードで障害が発生した場合、Oracle Clusterwareでは、スタンバイ・データベースの状態が自動的にACTIVEに変更されます。アプリケーション・フェイルオーバーが構成されている場合は、アプリケーションによって新しいアクティブ・データベースの更新が開始されます。

図8-2では、スタンバイ・データベースの状態がACTIVEに変更され、アプリケーションによって新しいアクティブ・データベースが更新されています。

図8-2 スタンバイ・データベースがアクティブ状態になった場合

Oracle Clusterwareによって、障害が発生したデータベースまたはホストの再起動が試行されます。成功すると、そのデータベースがスタンバイ・データベースになります。

図8-3に、前のアクティブ・ノードがスタンバイ・ノードになったクラスタを示します。

図8-3 前のアクティブ・ホストで起動したスタンバイ・データベース

前のアクティブ・ノードの障害が永続的であり、高度な可用性が構成されている場合は、追加のノードの1つでスタンバイ・データベースが起動されます。

図8-4に、追加のノードの1つでスタンバイ・データベースが起動されたクラスタを示します。

図8-4 追加のホストで起動されたスタンバイ・データベース

これらのアクションが自動で実行されるまで待機しない場合は、「アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行」を参照してください。

スタンバイ・データベースまたはそのホストで障害が発生した場合

スタンバイ・ノードで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。スタンバイ・データベースを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでスタンバイ・データベースが起動されます。

図8-5に、追加のノードの1つでスタンバイ・データベースが起動されたクラスタを示します。

図8-5 新しいホストのスタンバイ・データベース

読取り専用サブスクライバまたはそのホストで障害が発生した場合

サブスクライバ・ノードで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。データベースを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでサブスクライバ・データベースが起動されます。

両方のマスター・ノードで障害が発生した場合

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

- グリッドに接続していない場合の自動リカバリ

- アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードの手動リカバリ

- 高度な可用性の場合の手動リカバリ

- 基本的な可用性の場合の手動リカバリ

- データベースが破損した場合の同じマスター・ノードへの手動リカバリ

- RETURN TWOSAFEが構成されている場合の手動リカバリ

グリッドに接続していない場合の自動リカバリ

Oracle Clusterwareでは、次のような場合に、両方のマスター・ノードで一時的な障害が発生し、その後ノードが復旧した後に自動リカバリを実行できます。

- アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。

- AutoRecoverがyに設定されている。

- RepBackupDirが共有記憶域のディレクトリを指定している。

- RepBackupPeriodが0より大きい値に設定されている。

Oracle Clusterwareでは、次のような場合に、両方のマスター・ノードで発生した永続的な障害からの自動リカバリを実行できます。

- 高度な可用性(仮想IPアドレスおよび少なくとも4つのホスト)が構成されている。

- アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートしていない。

- キャッシュ・グリッドが構成されていない。

- アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。

- AutoRecoverがyに設定されている。

- RepBackupDirが共有記憶域のディレクトリを指定している。

- RepBackupPeriodが0より大きい値に設定されている。

cluster.oracle.iniファイルの例は、「両方のマスター・ノードの永続的な障害からのリカバリ」を参照してください。

アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードの手動リカバリ

アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードで障害が発生すると、グリッド・メンバーに障害が発生します。Oracle Clusterwareは障害が発生したグリッド・メンバーを自動的にグリッドから削除します。障害が発生したグリッド・メンバーがグリッドから削除されると、そのメンバーを手動でリカバリできます。ただし、キャッシュ・グリッドが構成されている場合は、二重障害が発生した後、一時的であっても永続的であっても、それ以上の自動リカバリを実行することはできません。

アクティブ・スタンバイ・ペア・グリッド・メンバーが非同期レプリケーション・スキーム内にある場合、グリッド・メンバーは自動的にリカバリされ、グリッドに再アタッチされます。アクティブ・スタンバイ・ペア・グリッド・メンバーがRETURN TWOSAFEで構成されたレプリケーション・スキーム内にある場合は、次の手順を実行して、グリッド・メンバーをリカバリし、グリッドに再アタッチします。

1. レプリケーション・エージェントとキャッシュ・エージェントを停止し、アプリケーションを両方のデータベースから切断します。この手順により、グリッド・メンバーがグリッドからデタッチされます。

ttCWAdmin -stop advancedGridDSN

2. アクティブ・スタンバイ・ペアを削除します。

ttCWAdmin -drop advancedGridDSN

3. アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

ttCWAdmin -create advancedGridDSN

4. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。この手順により、グリッド・メンバーがグリッドにアタッチされます。

ttCWAdmin -start advancedGridDSN

高度な可用性の場合の手動リカバリ

この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。次の手順では、例としてmanrecoveryDSNデータベースおよびcluster.oracle.iniファイルを使用します。

高度な可用性構成で手動リカバリを実行するには、次の手順を実行します。

1. TimesTenクラスタ・エージェントがローカル・ホストで実行されていることを確認します。

ttCWAdmin -init -hosts localhost

2. バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。

ttCWAdmin -restore -dsn manrecoveryDSN

3. データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。

4. 新しいホストがcluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsで指定されていない場合、新しいホストが含まれるようにファイルを変更します。
この手順では、manrecoveryDSNを使用します。cluster.oracle.iniファイルにはすでに追加のホストが指定されているため、manrecoveryDSNにはこの手順は必要はありません。

5. アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。

ttCWAdmin -create -dsn manrecoveryDSN

6. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn manrecoveryDSN

基本的な可用性の場合の手動リカバリ

この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。次の手順では、例としてbasicDSNデータベースおよびcluster.oracle.iniファイルを使用します。

基本的な可用性構成で手動リカバリを実行するには、次の手順を実行します。

1. アクティブ・スタンバイ・ペアのデータベース用に新しいホストを取得します。

2. TimesTenクラスタ・エージェントがローカル・ホストで実行されていることを確認します。

ttCWAdmin -init -hosts localhost

3. バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。

ttCWAdmin -restore -dsn basicDSN

4. データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。

5. cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。この例では、basicDSNデータベースを使用します。MasterHostsエントリはhost1からhost10に変更されます。SubscriberHostsエントリはhost2からhost20に変更されます。

[basicDSN]
MasterHosts=host10,host20

6. アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。

ttCWAdmin -create -dsn basicDSN

7. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn basicDSN

データベースが破損した場合の同じマスター・ノードへの手動リカバリ

両方のマスター・ノードで障害が発生し、データベースが破損する場合があります。同じマスター・ノードにリカバリするには、次の手順を実行します。

1. レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。この例では、basicDSNデータベースを使用します。

ttCWAdmin -stop -dsn basicDSN

2. ttDestroyユーティリティを使用し、新しいアクティブ・データベースを配置するノードでデータベースを破棄します。

ttDestroy basicDSN

3. バックアップ・データベースをリストアします。

ttCWAdmin -restore -dsn basicDSN

4. データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。

5. アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。

ttCWAdmin -create -dsn basicDSN

6. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn basicDSN

RETURN TWOSAFEが構成されている場合の手動リカバリ

cluster.oracle.iniファイルでReturnServiceAttribute Clusterware属性を使用し、RETURNサービスRETURN TWOSAFEを利用できるようにアクティブ・スタンバイ・ペアを構成できます。RETURN TWOSAFEが構成されている場合、両方のノードで障害が発生した後、いずれかまたは両方のノードでデータベース・ログを利用できることがあります。

次のcluster.oracle.iniの例では、データベース・ログを利用できなかった場合のバックアップ構成を示します。

[basicTwosafeDSN]
MasterHosts=host1,host2
ReturnServiceAttribute=RETURN TWOSAFE
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600

次のリカバリ手順を実行します。

1. レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。

ttCWAdmin -stop -dsn basicTwosafeDSN

2. アクティブ・スタンバイ・ペアを削除します。

ttCWAdmin -drop -dsn basicTwosafeDSN

3. 前のアクティブ・データベースまたはスタンバイ・データベースのどちらがより新しいかを判断し、新しい方のデータベースを使用してアクティブ・スタンバイ・ペアを再度作成します。アクティブ・データベースを配置するホストを選択するように要求されます。

ttCWAdmin -create -dsn basicTwosafeDSN

どちらのデータベースも使用できない場合、バックアップからデータベースをリストアします。

ttCWAdmin -restore -dsn basicTwosafeDSN

4. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn basicTwosafeDSN

3つ以上のマスター・ホストで障害が発生した場合

二重のホスト障害のより極端なケースとして、3つ以上のマスター・ホストの障害対応について説明します。次のガイドラインを使用します。

- 停電やネットワーク障害などの場合は、障害の根本原因に対処します。

- アクティブ・データベースおよびスタンバイ・データベース用の少なくとも2つの正常なホストを識別または取得します。

- cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。

- その後実行するアクションのガイドラインは、「高度な可用性の場合の手動リカバリ」および「基本的な可用性の場合の手動リカバリ」を参照してください。

アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行

TimesTenおよびOracle Clusterwareによって自動リカバリが実行されるまで待機せずに、スタンバイ・データベースに強制的にスイッチオーバーする場合は、Oracle Clusterwareコマンドを使用してアプリケーションを作成します。

次のことを行います。

1. アクティブ・データベースでttCRSmasterリソースを停止するには、crsctl stop resourceコマンドを使用します。これにより、スタンバイ・データベースのロールがアクティブに変更されます。

2. 以前のアクティブ・データベースでttCRSmasterリソースを再起動するには、crsctl start resourceコマンドを使用します。これにより、データベースがリカバリされ、スタンバイ・データベースになります。

次の例は、host1のアクティブ・データベースからhost2のスタンバイ・データベースへの強制スイッチオーバーを示しています。

1. crsctl status resourceコマンドを使用して、すべてのTimesTenリソースを検索します。

% crsctl status resource | grep TT
NAME=TT_Activeservice_tt1122_ttadmin_REP1
NAME=TT_Agent_tt1122_ttadmin_HOST1
NAME=TT_Agent_tt1122_ttadmin_HOST2
NAME=TT_App_tt1122_ttadmin_REP1_updateemp
NAME=TT_Daemon_tt1122_ttadmin_HOST1
NAME=TT_Daemon_tt1122_ttadmin_HOST2
NAME=TT_Master_tt1122_ttadmin_REP1_0
NAME=TT_Master_tt1122_ttadmin_REP1_1
NAME=TT_Subservice_tt1122_ttadmin_REP1

2. ttCRSActiveServiceリソースのステータスを取得して、アクティブ・データベースが存在するホストを検索します。

% crsctl status resource TT_Activeservice_tt1122_ttadmin_REP1
NAME=TT_Activeservice_tt1122_ttadmin_REP1
TYPE=application
TARGET=ONLINE
STATE=ONLINE on host1

3. 初期ステータス・レポートには2つのttCRSmasterリソースがリストされています。どのttCRSmasterリソースがアクティブ・データベースと同じホストにあるかを確認します。

% crsctl status resource TT_Master_tt1122_ttadmin_REP1_0
NAME=TT_Master_tt1122_ttadmin_REP1_0
TYPE=application
TARGET=ONLINE
STATE=ONLINE on host1

% crsctl status resource TT_Master_tt1122_ttadmin_REP1_1
NAME=TT_Master_tt1122_ttadmin_REP1_1
TYPE=application
TARGET=ONLINE
STATE=ONLINE on host2

4. アクティブ・データベースが存在するホストのttCRSmasterリソースを停止します。

% crsctl stop resource TT_Master_tt1122_ttadmin_REP1_0
CRS-2673: Attempting to stop 'TT_Master_tt1122_ttadmin_REP1_0'
on 'host1'
CRS-2677: Stop of 'TT_Master_tt1122_ttadmin_REP1_0' on
'host1' succeeded

5. 最初のアクティブ・データベースでttCRSmasterリソースを再起動します。

% crsctl start resource TT_Master_tt1122_ttadmin_REP1_0
CRS-2672: Attempting to start 'TT_Master_tt1122_ttadmin_REP1_0'
on 'host1'
CRS-2676: Start of 'TT_Master_tt1122_ttadmin_REP1_0' on
'host1' succeeded

6. ttCRSActiveServiceおよびttCRSsubserviceリソースがある場所を確認して、強制スイッチオーバーが成功していることを確認します。

% crsctl status resource TT_Activeservice_tt1122_ttadmin_REP1
NAME=TT_Activeservice_tt1122_ttadmin_REP1
TYPE=application
TARGET=ONLINE
STATE=ONLINE on host2

% crsctl status resource TT_Subservice_tt1122_ttadmin_REP1
NAME=TT_Subservice_tt1122_ttadmin_REP1
TYPE=application
TARGET=ONLINE
STATE=ONLINE on host1

crsctl start resourceおよびcrsctl stop resourceコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Clusterwareによる管理

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

- Oracle Clusterwareソフトウェアのローリング・アップグレードの実行

- TimesTenのアップグレード

- クラスタでのホストの管理

- クラスタでのアクティブ・スタンバイ・ペアの管理

- アクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理

- スキーマの変更

- マスター・データベースの役割の入替え

- 異なるホストへのデータベースの移動

- ホスト・メンテナンスまたはネットワーク・メンテナンスの実行

- クラスタ全体でのメンテナンスの実行

- Oracle Clusterware使用時のユーザー名やパスワードの変更

Oracle Clusterwareソフトウェアのローリング・アップグレードの実行

『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

TimesTenのアップグレード

『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のOracle Clusterware使用時のTimesTenオンライン・アップグレードの実行に関する説明を参照してください。

クラスタでのホストの管理

次の項では、クラスタ使用時のホストの追加または削除方法を説明します。

- クラスタへのホストの追加

- クラスタからのホストの削除

クラスタへのホストの追加

ホストを追加するには、クラスタが高度な可用性用に構成されている必要があります。この項の例では、advancedSubscriberDSNを使用しています。

クラスタに2つのスペア・マスター・ホストを追加するには、次のようなコマンドを入力します。

ttCWAdmin -addMasterHosts -hosts "host8,host9" -dsn advancedSubscriberDSN

クラスタに1つのスペア・サブスクライバ・ホストを追加するには、次のようなコマンドを入力します。

ttCWAdmin -addSubscriberHosts -hosts "subhost1" -dsn advancedSubscriberDSN

クラスタからのホストの削除

ホストをクラスタから削除するには、クラスタが高度な可用性用に構成されている必要があります。マスター・ホストの1つを削除するには、MasterHostsに3つ以上のホストがリストされている必要があります。サブスクライバ・ホストの1つを削除するには、サブスクライバ・データベースの数よりも少なくとも1つ多いホストがSubscriberHostsにリストされている必要があります。

この項の例では、advancedSubscriberDSNを使用しています。

クラスタから2つのスペア・マスター・ホストを削除するには、次のようなコマンドを入力します。

ttCWAdmin -delMasterHosts "host8,host9" -dsn advancedSubscriberDSN

クラスタから1つのスペア・サブスクライバ・ホストを削除するには、次のようなコマンドを入力します。

ttCWAdmin -delSubscriberHosts "subhost1" -dsn advancedSubscriberDSN

クラスタでのアクティブ・スタンバイ・ペアの管理

次の項では、クラスタに対するアクティブ・スタンバイ・ペアの追加または削除方法を説明します。

- クラスタへのアクティブ・スタンバイ・ペアの追加

- クラスタからのアクティブ・スタンバイ・ペアの削除

クラスタへのアクティブ・スタンバイ・ペアの追加

すでにアクティブ・スタンバイ・ペアを管理しているクラスタに(サブスクライバを持つ(または持たない))アクティブ・スタンバイ・ペアを追加するには、次の手順を実行します。

1. 最初にアクティブ・データベースを配置するホストに、データベースを作成して移入を行います。「1つのホストでのTimesTenデータベースの作成および移入」を参照してください。

2. cluster.oracle.iniファイルを変更します。この例では、advancedSubscriberDSNの構成がすでに含まれたcluster.oracle.iniファイルに、advSub2DSNを追加します。新しいアクティブ・スタンバイ・ペアは、元のアクティブ・スタンバイ・ペアとは異なるホストにあります。

[advancedSubscriberDSN]
MasterHosts=host1,host2,host3
SubscriberHosts=host4, host5
MasterVIP=192.168.1.1, 192.168.1.2
SubscriberVIP=192.168.1.3
VIPInterface=eth0
VIPNetMask=255.255.255.0

[advSub2DSN]
MasterHosts=host6,host7,host8
SubscriberHosts=host9, host10
MasterVIP=192.168.1.4, 192.168.1.5
SubscriberVIP=192.168.1.6
VIPInterface=eth0
VIPNetMask=255.255.255.0

3. rootユーザーとして、新しい仮想IPアドレスを作成します。

ttCWAdmin -createVIPs -dsn advSub2DSN

4. 新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

ttCWAdmin -create -dsn advSub2DSN

5. 新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn advSub2DSN

クラスタからのアクティブ・スタンバイ・ペアの削除

(サブスクライバを持つ(または持たない))アクティブ・スタンバイ・ペアをクラスタから削除するには、次の手順を実行します。

1. アクティブ・スタンバイ・ペアのすべてのデータベースで、レプリケーション・エージェントを停止します。この例では、「クラスタへのアクティブ・スタンバイ・ペアの追加」で追加されたadvSub2DSNを使用します。

ttCWAdmin -stop -dsn advSub2DSN

2. アクティブ・スタンバイのレプリケーション・スキームを削除します。

ttCWAdmin -drop -dsn advSub2DSN

3. アクティブ・スタンバイ・ペアの仮想IPアドレスを削除します。

ttCWAdmin -dropVIPs -dsn advSub2DSN

4. cluster.oracle.iniファイルを変更します(オプション)。advSub2DSNのエントリを削除します。

5. データベースを破棄する場合、このアクティブ・スタンバイ・ペアの構成に含まれる各ホストにログオンし、ttDestroyユーティリティを使用します。

ttDestroy advSub2DSN

ttDestroyの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDestroyに関する説明を参照してください。

アクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理

次の項では、Oracle Clusterwareが管理するアクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理方法を説明します。

- Oracle Clusterwareによって管理される読取り専用サブスクライバの追加

- Oracle Clusterwareによって管理される読取り専用サブスクライバの削除

- Oracle Clusterwareによって管理されていない読取り専用サブスクライバの追加または削除

- Oracle Clusterwareによって管理されていない読取り専用サブスクライバの再作成

Oracle Clusterwareによって管理される読取り専用サブスクライバの追加

Oracle Clusterwareによって管理される読取り専用サブスクライバをアクティブ・スタンバイ・ペアのレプリケーション・スキームに追加するには、次の手順を実行します。

1. すべてのデータベースでレプリケーション・エージェントを停止します。この例では、すでにサブスクライバが含まれており、高度な可用性が構成されているadvancedSubscriberDSNを使用します。

ttCWAdmin -stop -dsn advancedSubscriberDSN

2. アクティブ・スタンバイ・ペアを削除します。

ttCWAdmin -drop -dsn advancedSubscriberDSN

3. cluster.oracle.iniファイルを変更します。

- SubscriberHosts属性にサブスクライバを追加します。

- クラスタが高度な可用性用に構成されている場合、仮想IPアドレスをSubscriberVIP属性に追加します。

これらの属性を使用する例については、「高度な可用性の構成」を参照してください。

4. アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

ttCWAdmin -create -dsn advancedSubscriberDSN

5. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn advancedSubscriberDSN

Oracle Clusterwareによって管理される読取り専用サブスクライバの削除

Oracle Clusterwareによって管理される読取り専用サブスクライバをアクティブ・スタンバイ・ペアから削除するには、次の手順を実行します。

1. すべてのデータベースでレプリケーション・エージェントを停止します。この例では、サブスクライバが含まれており、高度な可用性が構成されているadvancedSubscriberDSNを使用します。

ttCWAdmin -stop -dsn advancedSubscriberDSN

2. アクティブ・スタンバイ・ペアを削除します。

ttCWAdmin -drop -dsn advancedSubscriberDSN

3. cluster.oracle.iniファイルを変更します。

- SubscriberHosts属性からサブスクライバを削除するか、アクティブ・スタンバイ・ペアにサブスクライバが残っていない場合は属性全体を削除します。

- SubscriberVIP属性から仮想IPアドレスを削除するか、アクティブ・スタンバイ・ペアにサブスクライバが残っていない場合は属性全体を削除します。

4. アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

ttCWAdmin -create -dsn advancedSubscriberDSN

5. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn advancedSubscriberDSN

Oracle Clusterwareによって管理されていない読取り専用サブスクライバの追加または削除

Oracle Clusterwareによって管理されている既存のアクティブ・スタンバイ・ペアのレプリケーション・スキームに、Oracle Clusterwareによって管理されていない読取り専用サブスクライバを追加または削除できます。ttCWAdmin -beginAlterSchemaコマンドを使用すると、レプリケーション・スキームを削除および再作成せずに、サブスクライバを追加できます。サブスクライバはOracle Clusterware管理用に設定された構成の一部ではないため、Oracle Clusterwareでは管理されません。

次の手順を実行します。

1. ttCWAdmin -beginAlterSchemaコマンドを実行し、アクティブ・データベースとスタンバイ・データベースでレプリケーション・エージェントを停止します。

2. ttIsqlを使用してアクティブ・データベースに接続し、ALTER ACTIVE STANDBY PAIR文を使用して、レプリケーション・スキームにサブスクライバを追加、または削除します。たとえば、サブスクライバを追加するには次のコマンドを実行します。

ALTER ACTIVE STANDBY PAIR ADD SUBSCRIBER ROsubDSN ON host6;

サブスクライバを削除するには、次のコマンドを実行します。

ALTER ACTIVE STANDBY PAIR DROP SUBSCRIBER ROsubDSN ON host6;

3. 変更したレプリケーション・スキームを登録するttCWAdmin -endAlterSchemaコマンドを実行して、レプリケーションを開始します。サブスクライバを追加する場合は、これにより、スタンバイ・マスター・データベースへの複製も開始されます。

4. ttIsql repschemesコマンドを入力して、読取り専用サブスクライバがレプリケーション・スキームに追加、または削除されていることを確認します。

5. ttRepStateGet組込みプロシージャを使用して、スタンバイ・データベースの状態がSTANDBYであることを確認します。

6. サブスクライバを追加した場合は、サブスクライバ・ホストでttRepAdmin -duplicateを実行し、スタンバイ・データベースを読取り専用サブスクライバに複製します。「データベースの複製」を参照してください。

7. サブスクライバを追加した場合は、サブスクライバ・エージェントでレプリケーション・エージェントを起動します。

サブスクライバを追加した場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの構成」の手順1の説明に従って、cluster.oracle.iniファイルの読取り専用サブスクライバにRemoteSubscriberHosts Clusterware属性を追加し、クラスタが削除されて再作成された場合に、読取り専用サブスクライバを確実に含むようにします。また、サブスクライバを削除した場合は、cluster.oracle.iniファイル内の、削除されたサブスクライバのRemoteSubscriberHosts Clusterware属性を削除します(構成されている場合)。

Oracle Clusterwareによって管理されていない読取り専用サブスクライバの再作成

次のタスクを実行して、Oracle Clusterwareによって管理されない読取り専用サブスクライバを破棄および再作成します。

1. サブスクライバ・ホストでレプリケーション・エージェントを停止します。

2. ttDestroyユーティリティを使用して、サブスクライバ・データベースを破棄します。

3. サブスクライバ・ホストで、ttRepAdmin -duplicateを使用して、スタンバイ・データベースを読取り専用サブスクライバに複製します。「データベースの複製」を参照してください。

スキーマの変更

Oracle Clusterwareを使用してアクティブ・スタンバイ・ペアを管理する場合は、Oracle Clusterwareですべてのレプリケーション・エージェントを起動および停止する必要があることを除いて、通常のレプリケーション環境と同様に必要に応じてDDL文を実行しスキーマを変更できます。

したがって、スキーマを変更する際には次のことに気をつけてください。

- 自動的にレプリケートされるオブジェクトに対するDDL文については、レプリケーション・エージェントを停止する必要はありません。この場合、DDLステートメントが自動的に伝播され、スタンバイ・マスターとすべてのサブスクライバに適用されるため、これ以上のアクションは必要ありません。DDLReplicationLevel接続属性によって、レプリケートされるDDL文を制御します。

- レプリケーション・スキームの一部であるが、DDL文が実行されないオブジェクト(「アクティブ・スタンバイ・ペアへのその他の変更」でリストされているオブジェクト)については、アクティブ・マスターでOracle Clusterware ttCWAdmin -beginAlterSchemaコマンドを実行すると、レプリケーション・スキームの各ノード上のレプリケーション・エージェントが停止します。その後、レプリケーション・スキームのアクティブ・マスターでDDL文を実行します。最後に、アクティブ・マスターでOracle Clusterware ttCWAdmin -endAlterSchemaコマンドを実行して、レプリケーション・エージェントを再起動します。
これらのオブジェクトはレプリケーション・スキームの一部ですが、DDL文がレプリケートされないため、ttCWAdmin -endAlterSchemaコマンドの後に複製が発生して、これらのスキーマの変更がマスターおよびすべてのサブスクライバに伝播されます。これは、複製がスキーマの変更を伝播するために使用される唯一のシナリオです。

手順については、「Oracle Clusterwareのスキーマ変更の簡素化」を参照してください。

- 自動的にレプリケートされず、レプリケーション・スキームの一部ではないオブジェクトに対するDDL文については、アクティブ・マスターでOracle Clusterware ttCWAdmin -beginAlterSchemaコマンドを実行すると、すべてのノード上のレプリケーション・エージェントが停止されます。次に、「アクティブ・スタンバイ・ペアのDDLの変更」での指示に従って、手動でこれらのDDL文を実行して、すべてのノードを同期できます。最後に、アクティブ・マスターでOracle Clusterware ttCWAdmin -endAlterSchemaコマンドを実行し、すべてのレプリケーション・エージェントを再起動します。
手順については、「Oracle Clusterwareのスキーマ変更の簡素化」を参照してください。

注意:
「アクティブ・スタンバイ・ペアのDDLの変更」および「アクティブ・スタンバイ・ペアへのその他の変更」という項では、どのDDL文がアクティブ・スタンバイ・ペア用に自動的にレプリケートされるか、どの文がレプリケートされないかを説明しています。これらの項では、どのオブジェクトがレプリケーション・スキームの一部かも説明しています。

Oracle Clusterwareのスキーマ変更の簡素化

ttCWAdmin -beginAlterSchemaおよび-endAlterSchemaコマンドを使用して、レプリケーション・エージェントを停止する必要のあるアクティブおよびスタンバイのマスター・データベースでのスキーマ変更を簡素化します。

- ttCWAdmin -beginAlterSchemaコマンドは、スキーマ変更の準備として、アクティブおよびスタンバイの両方のマスター・ノードでレプリケーション・エージェントを停止することによって、スキーマ変更に備えます。

- すべてのスキーマ変更が完了した後、ttCWAdmin -endAlterSchemaコマンドを実行します。レプリケーション・スキームの一部であるオブジェクトで、これらのオブジェクトに対して実行されるDDL文が自動的にレプリケートされない場合は、ttCWAdmin -endAlterSchemaコマンドの後に複製が発生して、これらのスキーマの変更のみがマスターおよびすべてのサブスクライバに伝播されます。このコマンドは変更されたレプリケーション・スキームを登録し、アクティブおよびスタンバイ・マスター・ノードのレプリケーション・エージェントを再起動し、Oracle Clustewareの制御を再び使用できるようにします。

Oracle Clusterwareの使用時にアクティブ・スタンバイ・ペアのスキーマを変更するには、次のタスクを実行します。

1. アクティブおよびスタンバイの両方のマスターでレプリケーション・エージェントを停止して、アクティブ・スタンバイ・ペアのスキーマへの変更を有効にします。

ttCWAdmin -beginAlterSchema -dsn advancedDSN

2. 必要なスキーマ変更を行います。
オブジェクトのDDL文がレプリケートされないオブジェクトを作成、変更または削除する場合は、レプリケーション・エージェントが無効な状態でその同じオブジェクトがレプリケーション・スキームのすべてのデータベースに存在することを確認し、同じオブジェクトをスタンバイ・マスターおよびサブスクライバで手動で作成、変更または削除する必要もあります。たとえば、アクティブ・データベースでマテリアライズド・ビューを作成する場合は、スタンバイ・マスターのデータベースとサブスクライバ・ノードでも同時にマテリアライズド・ビューを作成します。

3. レプリケーション・スキームの一部であるが、自動的にはレプリケートされないオブジェクト(順序など)をアクティブ・スタンバイ・ペアのレプリケーション・スキームに含める場合は、アクティブ・スタンバイ・ペアを変更します。

ALTER ACTIVE STANDBY PAIR INCLUDE samplesequence;

4. オブジェクトがキャッシュ・グループの場合は、「グリッドのアクティブ・スタンバイ・ペアへのスキーマ変更」のキャッシュ・グループの作成、変更または削除の手順を参照してください。

5. ttCWAdmin -endAlterSchemaコマンドを実行して、アクティブおよびスタンバイのマスター・ノードでレプリケーション・エージェントを再起動します。レプリケーション・スキームの一部であるオブジェクトを変更したが、これらのオブジェクトに対して実行されるDDL文が自動的にレプリケーションされない場合は、ttCWAdmin -endAlterSchemaコマンドの後に複製が発生して、これらのスキーマの変更のみがマスターおよびすべてのサブスクライバに伝播されます。

ttCWAdmin -endAlterSchema -dsn advancedDSN

サブスクライバおよびデータベース属性の管理

サブスクライバ・データベースを追加または削除したり、データベース属性を変更するには、次のタスクを実行します。

1. アクティブ・スタンバイ・ペアのデータベースでレプリケーション・エージェントを停止します。これらのコマンドでは、例としてadvancedCacheDSNを使用します。

ttCWAdmin -stop -dsn advancedCacheDSN

2. アクティブ・スタンバイ・ペアを削除します。

ttCWAdmin -drop  -dsn advancedCacheDSN

3. 必要に応じて、スキーマを変更します。

4. アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。

ttCWAdmin -create -dsn advancedCacheDSN

5. アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。

ttCWAdmin -start -dsn advancedCacheDSN

マスター・データベースの役割の入替え

フェイルオーバー後、アクティブ・データベースおよびスタンバイ・データベースはフェイルオーバー前とは異なるホストに配置されます。元の構成をリストアするには、ttCWAdminユーティリティの-switchオプションを使用します。オプションで、-timeoutオプションと-switchオプションを使用して、アクティブおよびスタンバイのデータベースの切替えが完了するまで待機するタイムアウト(秒)を設定できます。

次に例を示します。

ttCWAdmin -switch -dsn basicDSN

-switchオプションを使用する前に、オープン・トランザクションが存在しないことを確認してください。オープン・トランザクションが存在する場合、コマンドは失敗します。

注意:
-switchおよび-timeoutオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttCWAdmin」を参照してください。

図8-6に、アクティブ・スタンバイ・ペアのホストを示します。アクティブ・データベースはホストAに存在し、スタンバイ・データベースはホストBに存在します。

図8-6 アクティブ・スタンバイ・ペアのホスト

ttCWAdmin -switchコマンドによって次のタスクが実行されます。

- ホストA (アクティブ・ノード)でTimesTenクラスタ・エージェント(ttCRSAgent)を解除する。

- ホストAでデータベース・モニター(ttCRSmaster)を無効にする。

- ホストAで組込みプロシージャttRepSubscriberWait、ttRepStopおよびttRepDeactivateをコールする。

- ホストAでアクティブ・サービス(ttCRSActiveService)を停止し、Oracle ClusterwareのCRSDプロセスに失敗イベントをレポートする。

- ホストAで監視を有効にし、アクティブ・サービスをホストBに移動する。

- ホストAでレプリケーション・エージェントを開始し、ホストBでスタンバイ・サービス(ttCRSsubservice)を停止して、ホストBでOracle ClusterwareのCRSDプロセスに失敗イベントをレポートする。

- ホストAでスタンバイ・サービス(ttCRSsubservice)を開始する。

異なるホストへのデータベースの移動

クラスタが高度な可用性用に構成されている場合、ttCWAdminユーティリティの-relocateオプションを使用して、ローカル・ホストから、cluster.oracle.iniファイルのMasterHosts属性で指定されている次に利用可能なスペア・ホストに、データベースを移動できます。ローカル・ホストのデータベースがアクティブな役割を持っている場合、-relocateオプションでは、まず役割の入替えが行われます。したがって、新しく移行されたアクティブ・データベースはスタンバイに、スタンバイ・データベースはアクティブになります。

-relocateオプションは、ホストをオフラインにする場合にデータベースを移動するために有効です。このコマンドを使用する前に、オープン・トランザクションが存在しないことを確認してください。

-relocateオプションにロール・スイッチが必要な場合は、オプションで-timeoutオプションと-relocateオプションを使用して、役割の切替えが完了するまで待機するタイムアウト(秒)を設定することもできます。

次に例を示します。

ttCWAdmin -relocate -dsn advancedDSN

注意:
-relocateおよび-timeoutオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttCWAdmin」を参照してください。

ホスト・メンテナンスまたはネットワーク・メンテナンスの実行

ホストのオペレーティング・システムまたはハードウェアをアップグレードしたり、ネットワーク・メンテナンスを実行する場合は、Oracle Clusterwareを停止して自動スタートアップを無効にします。rootまたはOS管理者として、次のOracle Clusterwareコマンドを実行します。

# crsctl stop crs

# crsctl disable crs

TimesTenを停止します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenアプリケーションの停止に関する説明を参照してください。

ホストのメンテナンスを実行します。その後、自動スタートアップを有効にしてOracle Clusterwareを開始します。

# crsctl enable crs

# crsctl start crs

これらのコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

クラスタ全体でのメンテナンスの実行

クラスタ内のすべてのホストを停止する必要がある場合、各ホストでOracle Clusterwareを個々に停止します。rootまたはOS管理者として、次のOracle Clusterwareコマンドを実行します。

# crsctl stop crs

# crsctl disable crs

TimesTenを停止します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenアプリケーションの停止に関する説明を参照してください。

メンテナンスを実行します。その後、自動スタートアップを有効にしてOracle Clusterwareを開始します。

# crsctl enable crs

# crsctl start crs

これらのコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Oracle Clusterware使用時のユーザー名やパスワードの変更

ttCWAdmin -createコマンドでアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成する場合、TimesTen環境を管理するために必要なユーザー名とパスワードを求めるプロンプトがOracle Clusterwareで表示されます。Oracle Clusterwareはこれらのユーザー名とパスワードを保存します。ユーザー名やパスワードを変更した後には、ttCWAdmin -reauthenticateコマンドを実行して、これらの新しいユーザー名とパスワードをOracle Clusterwareが保存できるようにする必要があります。

1. DDLReplicationLevel接続属性が3に設定されていることを確認します。この値であれば、アクティブ・マスター上のユーザー名やパスワードへの変更がスタンバイ・マスターにレプリケートされます。

2. 同じ方法(および同じ制限)を使用して、ユーザー名やパスワードを変更します(「レプリケーションで使用されるユーザー名またはパスワードの変更」を参照)。

3. アクティブ・マスター・データベースで、スタンバイ・マスター・データベースのDSNおよびホストを使用してttRepSubscriberWait組込みプロシージャ(またはttRepAdmin -waitコマンド)をコールし、すべてのパスワード変更がスタンバイ・マスターにレプリケートされていることを確認します。たとえば、すべてのトランザクションがホストhost2のスタンバイ・マスターmaster2にレプリケートされるようにするには、次のようにします。

Command> CALL ttRepSubscriberWait(NULL, NULL, 'master2', 'host2', -1);

4. ttCWAdmin -reauthenticateコマンドを実行して、Oracle Clusterwareに新しいパスワードを保存します。

ttCWAdmin -reauthenticate -dsn myDSN

このコマンドを実行すると、ttCWAdmin -createコマンドで要求される情報と同じ情報を求めるプロンプトが表示されます(「アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成」を参照)。

TimesTenデータベースのRAMポリシーの管理

Oracle ClusterwareによりTimesTenデータベースを管理する際には、TimesTenデータベースのRAMポリシーはデフォルトで「Always」に設定されています。ただし、Oracle Clusterware管理を停止する場合、TimesTenデータベースのRAMポリシーは「In Use」に設定されます。

TimesTenの管理にOracle Clusterwareをもう使用しない場合は、ご使用の環境に適切なTimesTen RAMポリシーに設定する必要があります。一般的に推奨される設定は「Manual」です。

TimesTenデータベースのRAMポリシーの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。

クラスタ・ステータスの監視

次の項では、クラスタのステータスの取得方法を説明します。

- クラスタ・ステータスの取得

- メッセージ・ログ・ファイル

クラスタ・ステータスの取得

ttCWAdminユーティリティの-statusオプションでは、同じインスタンス管理者によって管理されているインスタンスのすべてのアクティブ・スタンバイ・ペアに関する情報がレポートされます。DSNを指定すると、ユーティリティによってそのDSNとアクティブ・スタンバイ・ペアに関する情報がレポートされます。

例8-1 アクティブ・スタンバイ・ペアの作成後のステータス

アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成しても、レプリケーションを開始していない場合は、ttCWAdmin -statusによって次のような情報が返されます。キャッシュ・グリッドがあるかどうかに関係なく、レプリケーションが開始される前にこれらのグリッドの状態が表示されることに注意してください。

$ ttCWAdmin -status
TimesTen Cluster status report as of Thu Nov 11 13:54:35 2010

====================================================================
TimesTen daemon monitors:
Host:HOST1 Status: online
Host:HOST2 Status: online

====================================================================
====================================================================
TimesTen Cluster agents
Host:HOST1 Status: online
Host:HOST2 Status: online

====================================================================

Status of Cluster related to DSN MYDSN:
====================================================================
1. Status of Cluster monitoring components:
Monitor Process for Active datastore:NOT RUNNING
Monitor Process for Standby datastore:NOT RUNNING
Monitor Process for Master Datastore 1 on Host host1: NOT RUNNING
Monitor Process for Master Datastore 2 on Host host2: NOT RUNNING

2.Status of  Datastores comprising the cluster
Master Datastore 1:
Host:host1
Status:AVAILABLE
State:ACTIVE
Grid:NO GRID
Master Datastore 2:
Host:host2
Status:UNAVAILABLE
State:UNKNOWN
Grid:UNKNOWN
====================================================================
The cluster containing the replicated DSN is offline

例8-2 アクティブ・データベースが稼働している場合のステータス

レプリケーション・スキームを開始した後、アクティブ・データベースが稼働していてもスタンバイ・データベースが稼働していない場合、キャッシュ・グリッドが構成されていないと、ttCWAdmin -statusによって次のような情報が返されます。

$ ttcwadmin -status
TimesTen Cluster status report as of Thu Nov 11 13:58:25 2010

====================================================================
TimesTen daemon monitors:
Host:HOST1 Status: online
Host:HOST2 Status: online

====================================================================
====================================================================
TimesTen Cluster agents
Host:HOST1 Status: online
Host:HOST2 Status: online

====================================================================

Status of Cluster related to DSN MYDSN:
====================================================================
1. Status of Cluster monitoring components:
Monitor Process for Active datastore:RUNNING on Host host1
Monitor Process for Standby datastore:RUNNING on Host host1
Monitor Process for Master Datastore 1 on Host host1: RUNNING
Monitor Process for Master Datastore 2 on Host host2: RUNNING

2.Status of  Datastores comprising the cluster
Master Datastore 1:
Host:host1
Status:AVAILABLE
State:ACTIVE
Grid:NO GRID
Master Datastore 2:
Host:host2
Status:AVAILABLE
State:IDLE
Grid:NO GRID
====================================================================
The cluster containing the replicated DSN is online

キャッシュ・グリッドが構成されている場合は、最後のセクションは次のように表示されます。

2.Status of  Datastores comprising the cluster
Master Datastore 1:
Host:host1
Status:AVAILABLE
State:ACTIVE
Grid:AVAILABLE
Master Datastore 2:
Host:host2
Status:AVAILABLE
State:IDLE
Grid:NO GRID

例8-3 アクティブ・データベースとスタンバイ・データベースが稼働している場合のステータス

レプリケーション・スキームを開始した後、アクティブ・データベースとスタンバイ・データベースの両方が稼働している場合に、キャッシュ・グリッドが構成されていないと、ttCWAdmin -statusによって次のような情報が返されます。

$ ttcwadmin -status
TimesTen Cluster status report as of Thu Nov 11 13:59:20 2010

====================================================================
TimesTen daemon monitors:
Host:HOST1 Status: online
Host:HOST2 Status: online

====================================================================
====================================================================
TimesTen Cluster agents
Host:HOST1 Status: online
Host:HOST2 Status: online

====================================================================

Status of Cluster related to DSN MYDSN:
====================================================================
1. Status of Cluster monitoring components:
Monitor Process for Active datastore:RUNNING on Host host1
Monitor Process for Standby datastore:RUNNING on Host host2
Monitor Process for Master Datastore 1 on Host host1: RUNNING
Monitor Process for Master Datastore 2 on Host host2: RUNNING

2.Status of  Datastores comprising the cluster
Master Datastore 1:
Host:host1
Status:AVAILABLE
State:ACTIVE
Grid:NO GRID
Master Datastore 2:
Host:host2
Status:AVAILABLE
State:STANDBY
Grid:NO GRID
====================================================================
The cluster containing the replicated DSN is online

キャッシュ・グリッドが構成されている場合は、最後のセクションは次のように表示されます。

2.Status of  Datastores comprising the cluster
Master Datastore 1:
Host:host1
Status:AVAILABLE
State:ACTIVE
Grid:AVAILABLE
Master Datastore 2:
Host:host2
Status:AVAILABLE
State:STANDBY
Grid:AVAILABLE

メッセージ・ログ・ファイル

監視プロセスでは、ttcwerrors.logおよびttcwmsg.logファイルにイベントとエラーがレポートされます。これらのファイルはdaemon_home/infoディレクトリにあります。これらのファイルのデフォルト・サイズはユーザー・ログのデフォルトの最大サイズと同じです。ログ・ファイルの最大数はユーザー・ログのデフォルトのファイル数と同じです。ファイルの最大数が書き込まれると、その他のエラーおよびメッセージによってファイルが上書きされ、最も古いファイルで開始されます。

ログ・ファイル数およびログ・ファイル・サイズのデフォルト値は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の情報メッセージの変更に関する説明を参照してください。

9 クラシック・レプリケーション・スキームの定義

この章では、クラシック・レプリケーション・スキームを構成する方法について説明します。

注意:
アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義の詳細は、第3章「アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義」を参照してください。キャッシュ・グループがあるデータベースをレプリケートする場合は、第6章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

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

- 高可用性システムの設計

- クラシック・レプリケーション・スキームの定義

- クラシック・レプリケーション・スキームの表要件および制限

- 複数のマスターが関与するクラシック・レプリケーション・スキームの制限

- レプリケーション要素の定義

- 表要素に対するレプリケーション競合の確認

- DATASTORE要素に対する送信永続性の設定

- クラシック・レプリケーション・スキームでのRETURNサービスの使用

- クラシック・レプリケーション・スキームでのSTORE属性の設定

- クラシック・レプリケーション・スキームに対するネットワーク操作の構成

- クラシック・レプリケーション・スキームの構文の例

- データベースへのクラシック・レプリケーション・スキームの適用

- スクリプトによるクラシック・レプリケーション・スキームの作成

注意:
レプリケーションに必要な帯域幅の量を減らす方法については、「レプリケートの通信量の圧縮」を参照してください。
列が異なる位置にある表やパーティションの数が異なる表をレプリケートする方法については、「レプリケート表の列定義オプション」を参照してください。

高可用性システムの設計

すべてのレプリケーション・スキームの主要な目的は、次のとおりです。

- データをアプリケーションで常に使用できるように1つ以上のバックアップ・データベースを提供すること

- 障害が発生したデータベースをそれらのバックアップ・データベースからリカバリするための方法を提供すること

- 可能なかぎり最速でデータにアクセスできるアプリケーションを提供するために、ワークロードを効率的に分散すること

- ユーザーへのサービスを中断せずに、ソフトウェアのアップグレードおよびメンテナンスを実行できるようにすること

高可用性システムでは、マスター・データベースに影響を与える可能性がある障害が発生しても、サブスクライバ・データベースは影響を受けないようにする必要があります。少なくとも、マスターとサブスクライバは別々のホストに配置する必要があります。一部のアプリケーションでは、個別の電源を供給できる環境にサブスクライバを配置する必要がある場合もあります。場合によっては、完全に別のサイトにサブスクライバを配置する必要もあります。

次のクラシック・レプリケーション・スキームを構成できます(「レプリケーション・スキームのタイプ」を参照)。

- 単方向

- 双方向の分割ワークロード

- 双方向の分散ワークロード

- 伝播

データベース全体をレプリケートするか、データベースの要素を選択してレプリケートするかについても検討してください。また、レプリケーション・スキームにおけるサブスクライバの数についても検討してください。単方向および伝播レプリケーション・スキームでは、サブスクライバの数を選択できます。

この項の後半では、次の内容について説明します。

- フェイルオーバーおよびリカバリの使用例の検討

- パフォーマンスとリカバリのトレードオフについての判断

- ワークロードの分散

クラシック・レプリケーションを使用したオンラインによるアップグレードの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のレプリケーションを使用したオンラインによるアップグレードの実行に関する説明を参照してください。

フェイルオーバーおよびリカバリの使用例の検討

レプリケーション・スキームを計画する場合は、すべてのフェイルオーバーおよびリカバリの使用例を検討してください。たとえば、通常、サブスクライバで発生した障害は、マスター・データベースに接続しているアプリケーションには影響ありません。そのため、ユーザー・サービスを中断せずにリカバリできます。マスター・データベースで障害が発生した場合は、アプリケーションのロードをサブスクライバにリダイレクトし、中断なしに、または最小限の中断でサービスを続行するための方法が必要です。通常、この処理は、障害を検出し、障害が発生したデータベースからそのサブスクライバの1つにユーザーまたはアプリケーションをリダイレクトして、障害が発生したデータベースのリカバリを管理するように設計されている、クラスタ・マネージャまたはカスタム・ソフトウェアによって行われます。第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照してください。

フェイルオーバー方法を計画する場合は、マスターの役割を引き受けるサブスクライバおよび対象ユーザーまたはアプリケーションについて検討してください。リカバリの要件についても検討してください。たとえば、障害が発生したマスターがそのデータベースを最新のサブスクライバからリカバリできる必要があること、すべてのサブスクライバをそのマスターからリカバリできる必要があること、などです。データベース全体をレプリケートする双方向スキームでは、障害が発生したマスターの自動リストアを利用できます。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。

図9-1に示す、単方向にレプリケートされるデータベースの障害例について考えてみます。マスターで障害が発生した場合、アプリケーションは、サブスクライバからリカバリされるまでデータベースにアクセスできません。ALTER REPLICATION文を使用してサブスクライバ・データベースをマスターとして再定義しないかぎり、アプリケーションの接続またはユーザー・ロードをサブスクライバに切り替えることはできません。「クラシック・レプリケーション・スキームでのマスター・データベースの交換」を参照してください。

図9-1 単方向スキームでのマスターのリカバリ

図9-2に、データベース全体がレプリケートされる双方向の分散ワークロード・スキームを示します。このタイプのレプリケーション・スキームでフェイルオーバーが発生した場合、障害が発生したデータベース上のアプリケーションを使用していたユーザーは、影響を受けなかったデータベース上のアプリケーションに移動されます。リカバリが完了すると、リカバリしたデータベース上のアプリケーションにワークロードを再分散できます。

図9-2 分散ワークロード・スキームでのマスターのリカバリ

同様に、分割ワークロード・スキームのユーザーは、障害が発生したデータベースから影響を受けなかったデータベースに移動する必要があります。分割ワークロード・スキームではデータベース・レベルでレプリケーションが行われないため、ALTER REPLICATION文を使用して新しいマスター・データベースを設定する必要があります。「クラシック・レプリケーション・スキームでのマスター・データベースの交換」を参照してください。リカバリが完了すると、リカバリしたマスター・データベースにユーザーを戻すことができます。

伝播レプリケーション・スキームでも、マスターまたはプロパゲータで障害が発生した場合は、ALTER REPLICATION文を使用して新しいマスターまたは新しいプロパゲータを設定する必要があります。レプリケーション・スキームで2つのプロパゲータが定義されていると、高可用性が実現されます。2つのプロパゲータが構成された伝播レプリケーション・スキームの例は、図1-11を参照してください。

パフォーマンスとリカバリのトレードオフについての判断

レプリケーション・スキームの設計時に、フェイルオーバーおよびリカバリの複雑さとパフォーマンスの効率を比較してください。フェイルオーバーおよびリカバリを複雑にする要因には、マスターをそのサブスクライバと接続するネットワーク・トポロジ、レプリケーション・スキームの複雑さなどがあります。たとえば、選択した要素が異なるサブスクライバにレプリケートされるマスターをリカバリするより、1つのサブスクライバに完全にレプリケートされるマスターをリカバリする方がより簡単です。

レプリケーションは、非同期(デフォルト)、RETURN RECEIPTサービスによる半同期、またはRETURN TWOSAFEサービスによる完全同期で動作するように構成できます。データがマスターおよびサブスクライバの両方のデータベースで一貫していることをより高いレベルの信頼性を持って保証するには、RETURNサービスを選択します。非同期モード(デフォルト)を使用するか、RETURN RECEIPTモードまたはRETURN TWOSAFEモードを構成するかは、必要とする信頼性の程度および許容できるパフォーマンスのトレードオフによって決まります。

表9-1に、非同期のレプリケーション、RETURN RECEIPTサービスおよびRETURN TWOSAFEサービスにおけるパフォーマンスおよびリカバリのトレードオフの概要を示します。

表9-1 パフォーマンスとリカバリのトレードオフ

動作のタイプ

非同期のレプリケーション(デフォルト)

RETURN RECEIPT

RETURN TWOSAFE

コミット順序

各トランザクションは最初にマスター・データベースでコミットされます。

各トランザクションは最初にマスター・データベースでコミットされます。

各トランザクションは最初にサブスクライバ・データベースでコミットされます。

マスターでのパフォーマンス

トランザクション間の待機時間またはマスターでコミットされるまでの待機時間がないため、レスポンス時間が最も短く、スループットも最適になります。

非同期と比較すると、レスポンス時間は長くなり、スループットは低くなります。

コミット後のネットワークのラウンドトリップ中にアプリケーションはブロックされます。レプリケート対象のトランザクションがシリアライズされる程度は、非同期レプリケーションでの場合より大きいため、結果としてスループットが低くなります。

レスポンス時間が最も長く、スループットも最も低くなります。

マスターでのコミットに先立って行われるネットワークのラウンドトリップおよびサブスクライバでのリモート・コミットの期間中に、アプリケーションがブロックされます。トランザクションは完全にシリアライズされ、結果としてスループットが最も低くなります。

実行時エラーの影響

トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。

トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。

トランザクションは最初にサブスクライバ・データベースでコミットされるため、マスターでのコミット時にエラーが発生した場合は、マスターを手動で修正するか、または破棄してからサブスクライバ・データベースからリカバリする必要があります。

マスターでの障害発生後のフェイルオーバー

マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。

マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。

マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバは少なくともマスターの最新の状態になります。また、サブスクライバにレプリケートされたトランザクションをマスターでコミットする前にマスターで障害が発生した場合は、サブスクライバをマスターより先行させることもできます。

2つのRETURNサービス間のパフォーマンスとリカバリのトレードオフに加えて、次のことも検討する必要があります。

- RETURN RECEIPTは多くの構成で使用できますが、RETURN TWOSAFEは双方向構成またはアクティブ・スタンバイ・ペアでのみ使用できます。

- RETURN TWOSAFEでは、サブスクライバ・データベースへのトランザクションのレプリケート時にタイムアウトなどのエラーが発生した場合にマスター・データベースで実行されるローカル・アクションを指定できます。

アプリケーションでRETURN RECEIPTまたはRETURN TWOSAFEのいずれかに構成された表を更新する場合、トランザクションはRETURN RECEIPTまたはRETURN TWOSAFEとして分類されます。RETURN RECEIPTまたはRETURN TWOSAFEとして分類されたトランザクションは、終了前にレプリケーション・スキームが変更された場合でも、そのままの状態が維持されます。

RETURNサービスの詳細は、「クラシック・レプリケーション・スキームでのRETURNサービスの使用」を参照してください。

ワークロードの分散

アプリケーションのワークロードを分散し、限られた数のサーバーを最大限利用できるようにデータベースを構成することを検討してください。たとえば、各サーバーが個別にマスター・データベースおよびサブスクライバ・データベースとして機能するのではなく、マスターおよびサブスクライバの両方として機能するように双方向の分散ワークロード・レプリケーション・スキームでデータベースを構成する方が、より効率的で経済的です。ただし、分散ワークロード・スキームは、主にデータベースから読取りを行うアプリケーションで最も効率的に機能します。データベースの同じ要素に頻繁に書込みを行うアプリケーションに対して分散ワークロード・スキームを実装すると、パフォーマンスが低下し、更新競合を回避または管理するための解決方法を実装する必要がある可能性があります(第13章「レプリケーション競合の解消」を参照)。

クラシック・レプリケーション・スキームの定義

クラシック・レプリケーション・スキームを設計した後、SQL文CREATE REPLICATIONを使用してそのスキームをデータベースに適用できます。CREATE REPLICATION文を使用するには、ADMIN権限が必要です。

表9-2に、レプリケーション・スキームのコンポーネントおよびこの章の内容に関連する句を示します。CREATE REPLICATION文の完全な構文は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。

表9-2 レプリケーション・スキームのコンポーネント

コンポーネント

参照先

CREATE REPLICATION Owner.SchemeName

「レプリケーション・スキームおよびレプリケート・オブジェクトの所有者」

ELEMENT ElementName ElementType

「レプリケーション要素の定義」

[CheckConflicts]

「表要素に対するレプリケーション競合の確認」

{MASTER|PROPAGATOR} DatabaseName ON "HostName"

「データベース名」

[TRANSMIT {NONDURABLE|DURABLE}]

「DATASTORE要素に対する送信永続性の設定」

SUBSCRIBER DatabaseName ON "HostName"

「データベース名」

[ReturnServiceAttribute]

「クラシック・レプリケーション・スキームでのRETURNサービスの使用」

INCLUDE|EXCLUDE

「DATASTORE要素の定義」

STORE DatabaseName DataStoreAttributes

「クラシック・レプリケーション・スキームでのSTORE属性の設定」

[NetworkOperation]

「クラシック・レプリケーション・スキームに対するネットワーク操作の構成」

注意:
CREATE REPLICATION文でのネーミング・エラーは、多くの場合、解決が困難であるため、要素名、データベース名、ホスト名に間違いがないよう時間をかけて十分に確認してください。

データベースで使用されるレプリケーション・スキームは、システムを再起動しても有効です。レプリケーション・スキームを変更するには、ALTER REPLICATION文を使用します。第10章「クラシック・レプリケーション・スキームの変更」を参照してください。

レプリケーション・スキームおよびレプリケート・オブジェクトの所有者

レプリケーション・スキームとレプリケート・オブジェクトは、レプリケーション・スキームのすべてのデータベースで、同じユーザーによって所有されている必要があります。すべてのデータベースで所有者を共通にするには、CREATE REPLICATION文にユーザーとレプリケーション・スキームを明示的に指定する必要があります。

たとえば、ユーザーreplによって所有されているrepschemeという名前のレプリケーション・スキームを作成します。repschemeのCREATE REPLICATION文の先頭行は次のようになります。

CREATE REPLICATION rep1.repscheme

データベース名

レプリケーション・スキームにおけるデータベースの役割は、次のとおりです。

- マスター: アプリケーションは、マスター・データベースを更新します。マスターは、更新をプロパゲータに送信するか、またはサブスクライバに直接送信します。

- プロパゲータ: プロパゲータ・データベースは、マスター・データベースから更新を受信し、受信した更新をサブスクライバ・データベースに送信します。

- サブスクライバ: サブスクライバは、プロパゲータまたはマスターから更新を受信します。

レプリケーション・スキームを定義する前に、そのレプリケーション・スキームのデータベースのデータ・ソース名(DSN)を定義する必要があります。UNIXプラットフォームの場合は、odbc.iniファイルを作成します。Windowsの場合は、ODBCアドミニストレータを使用し、データベースを指定して接続属性を設定します。例については、「手順1: マスターおよびサブスクライバのDSNの作成」を参照してください。

レプリケーション・スキームで指定された各データベースの名前は、DSN定義内のDataStoreデータ・ストア属性で指定された、パスを除くデータベース・ファイル名の接頭辞と一致する必要があります。各DSN定義内のDataStoreデータ・ストア属性とData Source Nameデータ・ストア属性に同じ名前を使用します。データベースのパスがdirectory/subdirectory/foo.ds0の場合、使用するデータベース名はfooになります。たとえば、odbc.iniファイルのこのエントリはmasterdsのData Source Name(DSN)を示す一方で、DataStore値はmasterdsのパスを示します。

[masterds]
DataStore=/tmp/masterds
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8

クラシック・レプリケーション・スキームの表要件および制限

レプリケーション・スキームに含まれるレプリケート表の名前および所有者は、マスター・データベースとサブスクライバ・データベースで同一である必要があります。ただし、レプリケーション・スキームに含まれるレプリケート表の列の定義は、必ずしも同一である必要はありません。列定義オプションの詳細は、「レプリケート表の列定義オプション」を参照してください。

レプリケート表には、次のいずれかが必要です。

- 主キー

- NOT NULL列に定義された一意索引

レプリケーションでは、主キーまたは一意索引を使用して、レプリケート表の各行を一意に識別します。レプリケーションでは、表の索引配列の順次確認で検出された最初の使用可能な索引を常に選択します。主キーがない場合、レプリケーションでは、NULL列が含まれていない最初の一意索引を選択します。また、マスター・データベース内のレプリケート表に対して選択された索引は、サブスクライバ内の対応する表にも存在している必要があります。

注意:
レプリケート表のキーは、各更新レコードでサブスクライバに転送されます。キーが小さいほど、より効率的に転送されます。

レプリケート表には、次のようなデータ型の制限があります。

- レプリケート表のVARCHAR2、NVARCHAR2、VARBINARYおよびTT_VARCHAR列のサイズは、4MBに制限されます。VARCHAR2列の場合、文字長セマンティクスを使用する際の最大長は、特定のデータベース・キャラクタ・セットを使用する際に1文字が占めるバイト数によって異なります。たとえば、1文字に4バイトが必要なキャラクタ・セットでは、最大長は100万文字になります。NVARCHAR2の列の場合、1文字に2バイトが必要なため、文字長セマンティクスを使用する際の最大長は、200万文字になります。

- レプリケート表のBLOBデータ型を含む列のサイズは、16MBに制限されます。レプリケート表のCLOBデータ型またはNCLOBデータ型を含む列のサイズは、4MBに制限されます。

- 主キー列にはLOBデータ型を設定できません。

圧縮された列を含む表はレプリケートできません。

これらの要件および制限に問題がある場合は、トランザクション・ログAPI(XLA)をレプリケーション・メカニズムとして使用することを検討できます。『Oracle TimesTen In-Memory Database C開発者ガイド』のレプリケーション・メカニズムとしてのXLAの使用に関する説明を参照してください。

複数のマスターが関与するクラシック・レプリケーション・スキームの制限

双方向レプリケーション・スキームの設計は、クラシック・レプリケーションで一般的に使用される設計です。双方向レプリケーションの元々の設計では、2つのマスターのみが含まれるものでした。しかし、双方向レプリケーション設計のマスターの数が2つという制限はありません。

3つ以上のマスター(マルチマスター・トポロジ)を使用することと、ttRepAdmin -duplicateを使用して別のストアに複製することを決定した場合、ttRepSubscriberStateSet組込みプロシージャを使用して複製ストアのサブスクライバのレプリケーション状態をリセットし、すべてのサブスクライバを適切な状態に設定する必要があります。

表9-3で示されているように、3つのマスター(master1、master2およびmaster3)があり、それぞれが相互の双方向レプリケーション・スキームを使用するように構成されています。master1でttRepAdmin -duplicateを実行してmaster1からmaster2を再作成する場合は、master2でttRepSubscriberStateSet組込みプロシージャをコールして、master3のレプリケーション状態を設定する必要があります。

図9-3 双方向レプリケーション・スキームでの複数マスターの関与

レプリケーション要素の定義

クラシック・レプリケーション・スキームは、1つ以上のELEMENT記述で構成されます。ELEMENT記述には、要素の名前、そのタイプ(DATASTORE、TABLEまたはSEQUENCE)、更新が行われるマスター・データベース、更新がレプリケートされるサブスクライバ・データベースが含まれます。

注意:
キャッシュ・グループがあるデータベースをレプリケートする場合は、第6章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

要素の制限は、次のとおりです。

- 特定のオブジェクト(表、順序またはデータベース)を複数の要素記述に含めないでください。

- マスターおよびプロパゲータの両方の役割に同じ要素を定義しないでください。

- 要素には、現在のホスト上のデータベースがマスター、サブスクライバまたはプロパゲータのいずれかとして含まれている必要があります。

- 要素名は、レプリケーション・スキーム内で一意である必要があります。

複数のサブスクライバ・スキームに要素を定義する正しい方法については、「RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム」を参照してください。要素を伝播する正しい方法については、「伝播スキーム」を参照してください。

後でALTER REPLICATION文を使用して要素の削除または変更を行う場合は、スキーム内の各要素の名前を使用して要素を識別できます。

既存のレプリケーション・スキームに表、順序およびデータベースを追加できます。「クラシック・レプリケーション・スキームの変更」を参照してください。レプリケーション・スキームから表または順序を除外した後に、そのレプリケーション・スキームの一部であるデータベースから表または順序を削除できます。「クラシック・レプリケーション・スキームからの表または順序の削除」を参照してください。

この項の後半では、次の内容について説明します。

- DATASTORE要素の定義

- 表要素の定義

- クラシック・レプリケーション・スキーム内の外部キーで関連付けられている表のレプリケーション

- 順序のレプリケート

- レプリケートされたデータベースでのビューおよびマテリアライズド・ビュー

DATASTORE要素の定義

マスター・データベース(masterds)のすべての内容をサブスクライバ・データベース(subscriberds)にレプリケートする場合、ELEMENT記述(ds1)は次のようになります。

ELEMENT ds1 DATASTORE
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"

データベース・ホストは、hostnameオペレーティング・システム・コマンドから返されるホスト名で識別してください。ホスト名は二重引用符で囲むことをお薦めします。

注意:
一時データベースはレプリケートできません。

CREATE REPLICATION文のEXCLUDE TABLE句およびEXCLUDE SEQUENCE句を使用すると、DATASTORE要素からの特定の表および順序の除外を選択できます。EXCLUDE句を使用すると、EXCLUDE句で指定されたオブジェクトを除くデータベース全体が、要素内のすべてのサブスクライバにレプリケートされます。1つの要素記述で使用できるEXCLUDE TABLE句およびEXCLUDE SEQUENCE句はそれぞれ1つのみです。たとえば、この要素記述では2つの表および1つの順序が除外されます。

ELEMENT ds1 DATASTORE
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
EXCLUDE TABLE ttuser.tab1, ttuser.tab2
EXCLUDE SEQUENCE ttuser.seq1

CREATE REPLICATION文のINCLUDE TABLE句およびINCLUDE SEQUENCE句を使用すると、データベースへの特定の表および順序のみの挿入を選択できます。INCLUDE句を使用すると、INCLUDE句で指定されたオブジェクトのみが、要素内の各サブスクライバにレプリケートされます。1つの要素記述で使用できるINCLUDE TABLE句およびINCLUDE SEQUENCE句はそれぞれ1つのみです。たとえば、この要素記述では1つの表および2つの順序が挿入されます。

ELEMENT ds1 DATASTORE
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
INCLUDE TABLE ttuser.tab3
INCLUDE SEQUENCE ttuser.seq2, ttuser.seq3

表要素の定義

表ttuser.tab1およびttuser.tab2を(masterdsという名前でホストsystem1に配置されている)マスター・データベースから(subscriberdsという名前でホストsystem2に配置されている)サブスクライバ・データベースにレプリケートする場合、ELEMENT記述(aおよびb)は次のようになります。

ELEMENT a TABLE ttuser.tab1
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
ELEMENT b TABLE ttuser.tab2
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"

クラシック・レプリケーション・スキームの表の要件については、「クラシック・レプリケーション・スキームの表要件および制限」を参照してください。

クラシック・レプリケーション・スキーム内の外部キーで関連付けられている表のレプリケーション

クラシック・レプリケーション・スキームでは、外部キーで互いに関連付けられている表は、すべての表をレプリケートするか一部の表のみをレプリケートするかを選択できます。これを行うには、各マスターおよびサブスクライバに、表および外部キー関係を作成します。その後、各マスターおよびサブスクライバでALTER REPLICATION ADD ELEMENT文を使用して、表をレプリケーション・スキームに追加します。

ただし、外部キー関係がON DELETE CASCADEを使用して構成されている場合は、すべての表をレプリケーション・スキームを作成する前に作成する必要があります。その後、CREATE REPLICATION文を使用してすべての表を含むようにレプリケーション・スキームを構成しますが、その際、DATASTORE要素(どの表も除外しない)、または関連付けられているすべての表に対してTABLE要素のいずれかを使用します。

ALTER REPLICATION文を使用してレプリケーション・スキームを作成した後に、ON DELETE CASCADEで構成された外部キーで関連付けられている表をレプリケーション・スキームに追加することはできません。かわりに、レプリケーション・スキームを削除し、ON DELETE CASCADEで構成された外部キーで関連付けられている新しい表を作成してから、関連するすべての表を含む新しいレプリケーション・スキームを作成します。

ON DELETE CASCADEで構成された外部キーを持つ表をレプリケートする場合は、サブスクライバ上の対応する外部キーもON DELETE CASCADEで構成されている必要があります。また、その表に対して外部キーで関連付けられている他のすべての表もレプリケートする必要があります。この要件によって、マスター・データベースでカスケード削除を実行した場合にサブスクライバ表で競合が発生しなくなります。

TimesTenでは、カスケード削除が1つの操作としてレプリケートされ、親表で行が削除された場合に子表で発生する個々の行削除はサブスクライバにレプリケートされません。そのため、親表で削除された外部キーの値を含む行がサブスクライバ・データベースの子表に存在する場合は、その行がマスター・データベースの子表に存在していなかった場合でも削除されます。

順序のレプリケート

順序は、レプリケーション・スキームから除外したり、CYCLE属性が指定されていないかぎり、レプリケートされます。順序のレプリケーションは、アクティブ・データベースで順序が更新されるたびに、スタンバイ・データベースで順序番号の範囲を予約することによって最適化されます。順序番号の範囲を予約すると、トランザクション・ログの更新回数を減らすことができます。順序番号の範囲はキャッシュと呼ばれます。アクティブ・データベースでの順序の更新のレプリケートは、順序の更新後にレプリケート・トランザクションが実行される場合、または順序の更新がレプリケート・トランザクションで使用される場合にのみ実行されます。

MINVALUEが1で、INCREMENTが1、デフォルトのCacheが20の順序my.seqについて考えてみます。my.seq.NEXTVALを初めて使用すると、マスター・データベースの順序の現在値は2に変更され、新しい現在値21(20+1)がサブスクライバにレプリケートされます。マスター・データベースのmy.seq.NEXTVALへの次の19回の参照では、サブスクライバ・データベースの現在値21がマスターの現在値より大きいため、新しい現在値のレプリケートは行われません。my.seq.NEXTVALへの21回目の参照では、前回レプリケートされたサブスクライバの現在値21が、この時点でマスターの現在値22より小さくなるため、新しい現在値41(21+20)がサブスクライバ・データベースに送信されます。

順序のレプリケーションには、次の制限があります。

- CYCLE属性が指定された順序はレプリケートできません。

- レプリケートされる順序の定義は、各ピア・データベースで同じである必要があります。

- 順序では、競合の検出は実行されません。RETURN TWOSAFEサービスを使用せずに、双方向レプリケーション構成で両方のデータベースの順序を更新すると、両方の順序によって同じNEXTVALが返される可能性があります。

いずれかのピアで更新が行われる双方向レプリケーション・スキームで順序を使用する必要がある場合は、競合を回避するために、各データベースで、異なるMINVALUEおよびMAXVALUE属性が指定された、レプリケートされない順序をかわりに使用できます。たとえば、MINVALUEが1で、MAXVALUEが100の順序my.seqをデータベースDS1に作成し、MINVALUEが101で、MAXVALUEが200の同じ順序をDS2に作成するとします。この場合、DS1およびDS2を双方向レプリケーション・スキームで構成すると、順序my.seqを使用して、いずれのデータベースに対しても順序値が競合しないことを保証して更新を行うことができます。この構成でttRepAdmin -duplicateを使用して障害からリカバリする場合は、複製操作を実行した後で順序を削除し、新しいMINVALUEおよびMAXVALUEを指定して順序を再作成する必要があることに注意してください。

SELECT my.seq.NEXTVAL FROM sys.dualなどの順序に対する操作では、順序値は増加しますが、レプリケートされる表でのトランザクションをその後に行うまでレプリケートは実行されません。この動作には、レプリケートされる表でのトランザクションをその後に行うまでこれらの順序の更新がログからパージされないという副作用があります。このため、これらの順序の更新のみがログの末尾に存在する場合は、ttRepSubscriberWaitおよびttRepAdmin -waitで障害が発生します。

順序ttuser.seqを(masterdsという名前でホストsystem1に配置されている)マスター・データベースから(subscriberdsという名前でホストsystem2に配置されている)サブスクライバ・データベースにレプリケートする場合、要素記述(a)は次のようになります。

ELEMENT a SEQUENCE ttuser.seq
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"

レプリケートされたデータベースでのビューおよびマテリアライズド・ビュー

マテリアライズド・ビューは、ディテール表と呼ばれる1つ以上のTimesTen表から選択されたデータのサマリーです。マテリアライズド・ビューは直接レプリケートできませんが、マテリアライズド・ビューの基礎となるディテール表は通常のTimesTen表の場合と同じ方法でレプリケートできます。

マスター・データベースおよびサブスクライバ・データベースのディテール表は、マテリアライズド・ビューで参照できます。ただし、TimesTenレプリケーションでは、レプリケート対象のディテール表の構造がマスターおよびサブスクライバの両方で同じであることのみが検証されます。マテリアライズド・ビューが各データベースで同じである必要はありません。

マテリアライズド・ビューまたは非マテリアライズド・ビューがDATASTORE要素として含まれているデータベース全体をレプリケートする場合は、ビューに関連付けられているディテール表のみがレプリケートされます。ビュー自体はレプリケートされません。一致するビューは、サブスクライバ・データベースで定義できますが、必須ではありません。ディテール表がレプリケートされると、TimesTenはそれに対応するビューを自動的に更新します。

マテリアライズド・ビューが更新されたときに、オーバーフローまたはアンダーフロー状態が発生するように指定されている場合、レプリケート対象の表に定義されたマテリアライズド・ビューで、レプリケーション障害または非一貫性が発生する場合があります。

表要素に対するレプリケーション競合の確認

データベースが双方向レプリケーションに構成されている場合、複数のデータベースの同一表行が個別に同時に更新されると、レプリケーション競合が発生する可能性があります。

このような競合は、レプリケート表にタイムスタンプを含め、各表の要素記述にオプションのCHECK CONFLICTS句を指定してレプリケーション・スキームを構成することによって、表単位で検出および解消できます。

レプリケーション競合、およびCREATE REPLICATION文のCHECK CONFLICTS句の構成方法の詳細は、第13章「レプリケーション競合の解消」を参照してください。

DATASTORE要素に対する送信永続性の設定

非同期またはRETURN RECEIPTのレプリケーションで構成されたマスター・データベースは、デフォルトでは永続的になります。そのため、トランザクションのコミットと同時にログ・レコードはディスクにコミットされます。要素記述にTRANSMIT NONDURABLE句を使用して、マスター・データベースを非永続的に設定することもできます。

デフォルトでは、マスター・データベースのログ・バッファ内のトランザクション・レコードは、サブスクライバに転送される前にディスクにフラッシュされます。マスター・データベース全体をレプリケートする(ELEMENTのタイプがDATASTOREである)場合、マスターのログをディスクにフラッシュする処理をレプリケーション・サイクルから除くことによって、レプリケーション・パフォーマンスを向上できます。これを実現するには、要素記述にTRANSMIT NONDURABLE句を含めます。TRANSMITを設定しても、サブスクライバに影響はありません。サブスクライバ・データベースのトランザクション・レコードは、常にディスクにフラッシュされます。

RETURN TWOSAFEレプリケーションで構成されたマスター・データベースはデフォルトでは非永続的になり、永続的にすることはできません。RETURN TWOSAFEレプリケーションで構成されたデータベースにTRANSMIT DURABLEを設定しても、RETURN TWOSAFEトランザクションに影響はありません。

例9-1 TRANSMIT NONDURABLEが設定されたマスター・データベース全体のレプリケーション

マスター・データベース(masterds)のすべての内容をサブスクライバ・データベース(subscriberds)にレプリケートする場合およびログをディスクにフラッシュする処理を除く場合、要素記述(a)は次のようになります。

ELEMENT a DATASTORE
MASTER masterds ON "system1"
TRANSMIT NONDURABLE
SUBSCRIBER subscriberds ON "system2"

通常、マスター・データベースで障害が発生した場合は、ttRepAdmin -duplicate処理(「障害が発生したデータベースのリカバリ」を参照)を開始して、障害が発生したマスターをサブスクライバ・データベースからリカバリする必要があります。これは、マスター・データベースがTRANSMIT DURABLEで構成されている場合は常に適用されます。

TRANSMIT NONDURABLEとして構成されたデータベースは、特定のタイプの双方向スキームで構成されている場合、サブスクライバ・レプリケーション・エージェントによって自動的にリカバリされます(「障害が発生したマスター・データベースの自動キャッチアップ」を参照)。そうでない場合は、「非永続的データベースのリカバリ」の手順に従って、障害が発生した非永続的データベースをリカバリする必要があります。

クラシック・レプリケーション・スキームでのRETURNサービスの使用

RETURNサービスを指定してレプリケーション・スキームを構成すると、レプリケーション・データが、マスターおよびサブスクライバ両方のデータベースで一貫していることをより高いレベルの信頼性を持って保証できます。この項では、RETURN RECEIPTおよびRETURN TWOSAFEサービスの構成方法および管理方法について説明します。

CREATE REPLICATIONまたはALTER REPLICATION文で定義されるいずれのサブスクライバの表要素およびデータベース要素に対してもRETURNサービスを指定できます。

マスターおよびサブスクライバ用にRETURNサービスを構成する方法の完全な詳細は、「RETURNサービスの使用」を参照してください。

クラシック・レプリケーション・スキームでのSTORE属性の設定

CREATE REPLICATION文およびALTER REPLICATION文のSTORE属性句は、RETURNサービス、圧縮、タイムアウト、永続コミット動作、競合レポートおよび表定義チェックのオプション動作を設定するために使用されます。クラシック・レプリケーション・スキーム用にSTORE属性を構成および使用する方法の完全な詳細は、「STORE属性の設定」を参照してください。STORE属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE ACTIVE STANDBY PAIRに関する説明を参照してください。

クラシック・レプリケーション・スキームに対するネットワーク操作の構成

レプリケーション・ホストにネットワーク・インタフェースが複数ある場合は、デフォルト以外のインタフェースを使用するようにレプリケーションを構成することもできます。クラシック・レプリケーション・スキーム用に2つ以上のネットワーク・インタフェースを構成する方法の詳細は、「ROUTE句を使用したネットワーク・インタフェースの構成」を参照してください。

クラシック・レプリケーション・スキームの構文の例

この項で説明する次の例では、様々なクラシック・レプリケーション・スキームの構成方法を示します。

- 単一クラシック・サブスクライバ・スキーム

- RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム

- 異なるサブスクライバへの表のレプリケーション

- 伝播スキーム

- 双方向の分割ワークロード・スキーム

- 双方向の分散ワークロード・スキーム

単一クラシック・サブスクライバ・スキーム

例9-2のクラシック・レプリケーション・スキームは、単一のマスターおよびサブスクライバの単方向レプリケーション・スキームです。2つのデータベースが別々のホストsystem1およびsystem2に配置されています。RETURN RECEIPTサービスを使用して、マスター・データベースのttuser.tab表に対してコミットしたすべてのトランザクションがサブスクライバで受信されることを確認します。

例9-2 1つの表のレプリケーション

CREATE REPLICATION repscheme
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT;

例9-3のスキームは、単一のマスターおよびサブスクライバの単方向レプリケーション・スキームです。2つのデータベースが別々のホストserver1およびserver2に配置されています。マスター・データベースmasterdsは、そのすべての内容をサブスクライバ・データベースsubscriberdsにレプリケートします。

例9-3 データベース全体のレプリケーション

CREATE REPLICATION repscheme
ELEMENT e DATASTORE
MASTER masterds ON "server1"
SUBSCRIBER subscriberds ON "server2";

RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム

最大128のサブスクライバ・データベースを含むクラシック・レプリケーション・スキームを作成できます。プロパゲータ・データベースを構成する場合は、最大128のプロパゲータを構成できます。各プロパゲータには最大128のサブスクライバ・データベースを構成できます。プロパゲータ・データベースを使用するクラシック・レプリケーション・スキームの例は、「伝播スキーム」を参照してください。

例9-4 2つのサブスクライバへのレプリケーション

この例では、server2にあるsubscriber1dsおよびserver3にあるsubscriber2dsという2つのサブスクライバ・データベースにttuser.tab表をレプリケートするマスター・データベースmasterdsを設定します。クラシック・レプリケーション・スキームの名前はtwosubscribersです。レプリケーション要素の名前はeです。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1ds ON "server2",
subscriber2ds ON "server3";

例9-5 RETURN RECEIPTを指定した2つのサブスクライバへのレプリケーション

この例では、例9-4の基本的な例を使用し、それにRETURN RECEIPT属性およびSTOREパラメータを追加します。RETURN RECEIPTで、両方のデータベースに対するRETURN RECEIPTサービスを有効にします。STOREパラメータで、FAILTHRESHOLD値を10に設定し、サブスクライバで障害が発生したとみなされるまでmasterdsに累積可能な、サブスクライバに対するトランザクション・ログ・ファイルの最大数を指定します。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1ds ON "server2",
subscriber2ds ON "server3"
RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;

例9-6 1つのみのサブスクライバに対するRETURN RECEIPTの有効化

この例では、subscriber2dsに対してのみRETURN RECEIPTを有効にする方法を示します。subscriber1ds定義の末尾のカンマは不要です。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1ds ON "server2"
SUBSCRIBER subscriber2ds ON "server3" RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;

例9-7 サブスクライバで異なるRETURNサービスの有効化

この例では、RETURN RECEIPT BY REQUESTをsubscriber1dsに、RETURN RECEIPTをsubscriber2dsに適用する方法を示します。このクラシック・レプリケーション・スキームでは、subscriber1dsにアクセスするアプリケーションは、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURNサービスを有効にする必要があります。一方、subscriber2dsは無条件に、すべてのトランザクションに対してRETURNサービスを提供します。

CREATE REPLICATION twosubscribers
ELEMENT e TABLE ttuser.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriberds1 ON "server2" RETURN RECEIPT BY REQUEST
SUBSCRIBER subscriber2ds ON "server3" RETURN RECEIPT
STORE masterds FAILTHRESHOLD 10;

異なるサブスクライバへの表のレプリケーション

例9-8に示されるクラシック・レプリケーション・スキームは、4つの表をレプリケートするcentraldsという名前のマスター・データベースを設定します。ttuser.tab1とttuser.tab2は、サブスクライバbackup1dsにレプリケートされます。ttuser.tab3とttuser.tab4は、backup2dsにレプリケートされます。マスター・データベースはfinanceサーバーにあります。両方のサブスクライバがサーバーbackupsystemに配置されています。

例9-8 異なるサブスクライバへの表のレプリケーション

CREATE REPLICATION twobackups
ELEMENT a TABLE ttuser.tab1
MASTER centralds ON "finance"
SUBSCRIBER backup1ds ON "backupsystem"
ELEMENT b TABLE ttuser.tab2
MASTER centralds ON "finance"
SUBSCRIBER backup1ds ON "backupsystem"
ELEMENT d TABLE ttuser.tab3
MASTER centralds ON "finance"
SUBSCRIBER backup2ds ON "backupsystem"
ELEMENT d TABLE ttuser.tab4
MASTER centralds ON "finance"
SUBSCRIBER backup2ds ON "backupsystem";

伝播スキーム

例9-9では、マスター・データベースからプロパゲータに表の更新が送信され、プロパゲータは、2つのサブスクライバに変更を転送します。マスター・データベースはホストfinanceのcentraldsです。プロパゲータ・データベースはホストnethandlerのpropdsです。サブスクライバは、backupsystem1のbackup1dsおよびbackupsystem2のbackup2dsです。

クラシック・レプリケーション・スキームには2つの要素があります。要素aでは、centraldsのtab表に対する変更がプロパゲータ・データベースpropdsにレプリケートされます。要素bでは、propdsで受信したtab表への変更が2つのサブスクライバbackup1dsおよびbackup2dsにレプリケートされます。

例9-9 伝播

CREATE REPLICATION propagator
ELEMENT a TABLE ttuser.tab
MASTER centralds ON "finance"
SUBSCRIBER propds ON "nethandler"
ELEMENT b TABLE ttuser.tab
PROPAGATOR propds ON "nethandler"
SUBSCRIBER backup1ds ON "backupsystem1",
backup2ds ON "backupsystem2";

双方向の分割ワークロード・スキーム

例9-10では、ホストwestcoastのwestdsおよびホストeastcoastのeastdsという2つのデータベースがあります。顧客は2つの表で表され、西地区の顧客のデータはwaccounts、東地区の顧客のデータはeaccountsに収められます。westdsデータベースは、waccounts表を更新してeastdsデータベースにレプリケートします。eaccounts表は、eastdsデータベースによって所有され、westdsデータベースにレプリケートされます。RETURN RECEIPT属性は、RETURN RECEIPTサービスを有効にして、いずれのマスター表のトランザクションもそれらのサブスクライバによって受信されることを保証します。

例9-10 双方向の分割ワークロード

CREATE REPLICATION r1
ELEMENT elem_waccounts TABLE ttuser.waccounts
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast" RETURN RECEIPT
ELEMENT elem_eaccounts TABLE ttuser.eaccounts
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast" RETURN RECEIPT;

双方向の分散ワークロード・スキーム

例9-11に、eastdsまたはwestdsのいずれかのデータベースでttuser.accounts表を更新できる一般ワークロードの双方向クラシック・レプリケーション・スキームを示します。各データベースは、accounts表に対してマスターおよびサブスクライバの両方になります。

注意:
RETURN TWOSAFE戻りサービスを構成して双方向の分散ワークロード・レプリケーション・スキームを使用しないでください。

例9-11 双方向の分散ワークロード・スキーム

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE ttuser.accounts
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE ttuser.accounts
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast";

要素をこの手法でレプリケートする場合、アプリケーションでは、各データベースへの書込みを調整して、同じデータに同時に更新が行われないようにする必要があります。更新競合を管理するには、BINARY(8)型のタイムスタンプ列をレプリケート表に含め、CREATE REPLICATION文にCHECK CONFLICTS句を含めてタイムスタンプ比較を有効にします。更新競合の管理方法の詳細は、第13章「レプリケーション競合の解消」を参照してください。

例9-12では、ttuser.accounts表にtstampタイムスタンプ列が含まれています。CREATE REPLICATION文は、CHECK CONFLICTS句が含まれるように変更されています。

例9-12 更新競合の管理

CREATE TABLE ttuser.accounts (custname VARCHAR2(30) NOT NULL,
address VARCHAR2(80),
curbalance DEC(15,2),
tstamp BINARY(8),
PRIMARY KEY (custname));

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE ttuser.accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE ttuser.accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast";

データベースへのクラシック・レプリケーション・スキームの適用

クラシック・レプリケーション・スキームを定義する際、CREATE REPLICATION文をSQLファイルに保存します。SQLファイルにクラシック・レプリケーション・スキームを記述した後、-fオプションを指定してttIsqlユーティリティ使用すると、データベースに対してSQLを実行できます。構文は次のとおりです。

ttIsql -f schemefile.sql -connstr "dsn=DSN"

例9-13 SQLファイルの実行によるクラシック・レプリケーション・スキームの作成

クラシック・レプリケーション・スキームをファイルrepscheme.sqlに記述した後、次のように入力して、masterDSNというDSNに対してファイルを実行できます。

> ttIsql -f repscheme.sql -connstr "dsn=masterDSN"

ほとんどの場合、すべてのレプリケート・データベースに対して同じスキームを適用する必要があります。ホストごとに個別のttIsqlコマンドを実行してクラシック・レプリケーション・スキームを適用する必要があります。

例9-14 ホストごとのSQLファイルの実行

クラシック・レプリケーション・スキームが、ホストS1上にmasterDSN、ホストS2上にsubscriber1DSN、ホストS3上のsubscriber2DSNの各データベースを含んでいる場合は、次のようにします。

ホストS1では、次のように入力します。

> ttIsql -f repscheme.sql -connstr "dsn=masterDSN"

ホストS2では、次のように入力します。

> ttIsql -f repscheme.sql -connstr "dsn=subscriber1DSN"

ホストS3では、次のように入力します。

> ttIsql -f repscheme.sql -connstr "dsn=subscriber2DSN"

クラシック・レプリケーション・スキームが含まれているSQLファイルは、データベースへの接続後に、ttIsqlコマンドラインからも実行できます。次に例を示します。

Command> run repscheme.sql;

スクリプトによるクラシック・レプリケーション・スキームの作成

クラシック・レプリケーション・スキームをスクリプトで作成すると、時間の節約および誤りの回避に有効です。この項では、Perlを使用してレプリケーション・スキームの作成を自動化する場合の推奨事項をいくつか示します。

例9-15に示す一般的なワークロードの双方向スキームについて考えてみます。5つの表ttuser.accounts、ttuser.sales、ttuser.orders、ttuser.inventoryおよびttuser.customersへの要素記述への入力を手動で行うと、時間がかかり、エラーも発生しやすくなります。

例9-15 一般ワークロードの双方向レプリケーション・スキーム

CREATE REPLICATION bigscheme
ELEMENT elem_accounts_1 TABLE ttuser.accounts
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE ttuser.accounts
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast"
ELEMENT elem_sales_1 TABLE ttuser.sales
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_sales_2 TABLE ttuser.sales
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast"
ELEMENT elem_orders_1 TABLE ttuser.orders
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_orders_2 TABLE ttuser.orders
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast"
ELEMENT elem_inventory_1 TABLE ttuser.inventory
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_inventory_2 TABLE ttuser.inventory
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast"
ELEMENT elem_customers_1 TABLE ttuser.customers
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_customers_2 TABLE ttuser.customers
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast";

多くの場合、スクリプトを使用してクラシック・レプリケーション・スキームの作成プロセスを自動化するとより効率的です。たとえば、例9-16に示すPerlスクリプトを使用して、例9-15に示したスキームを作成できます。

例9-16 レプリケーション・スキーム作成でのPerlスクリプトの使用

@tables = qw(
ttuser.accounts
ttuser.sales
ttuser.orders
ttuser.inventory
ttuser.customers
);

print "CREATE REPLICATION bigscheme";

foreach $table (@tables) {
$element = $table;
$element =~ s/repl\./elem\_/;

print "\n";
print " ELEMENT $element\_1 TABLE $table\n";
print " MASTER westds ON \"westcoast\"\n";
print " SUBSCRIBER eastds ON \"eastcoast\"\n";
print " ELEMENT $element\_2 TABLE $table\n";
print " MASTER eastds ON \"eastcoast\"\n";
print " SUBSCRIBER westds ON \"westcoast\"";
}
print ";\n";

例9-16の@tables配列は、データベースなどの他の一部のソースから取得できます。たとえば、Perl文でttIsqlおよびfを使用して、所有者名がreplのWestDSNデータベース内のすべての表に対して@tables配列を生成できます。

@tables = 'ttIsql -e "tables; quit" WestDSN
| grep " REPL\."';

例9-17に、WestDSNデータベース内のすべてのrepl表に対してクラシック・レプリケーション・スキームを作成する例9-16のスクリプトの変更バージョンを示します。grep出力から余分な空白および改行を削除するには、置換を行う必要があります。

例9-17 WestDSNにあるすべての表に対するレプリケーション・スキーム作成のためのPerlスクリプト

@tables = 'ttIsql -e "tables; quit" WestDSN
| grep " REPL\."';

print "CREATE REPLICATION bigscheme";

foreach $table (@tables) {
$table =~ s/^\s*//; # Remove extra spaces
$table =~ s/\n//; # Remove line feeds
$element = $table;
$element =~ s/repl\./elem\_/;

print "\n";
print " ELEMENT $element\_1 TABLE $table\n";
print " MASTER westds ON \"westcoast\"\n";
print " SUBSCRIBER eastds ON \"eastcoast\"\n";
print " ELEMENT $element\_2 TABLE $table\n";
print " MASTER eastds ON \"eastcoast\"\n";
print " SUBSCRIBER westds ON \"westcoast\"";
}
print ";\n";

10 クラシック・レプリケーション・スキームの変更

この章では、既存のクラシック・レプリケーション・システムを変更する方法について説明します。

- クラシック・レプリケーション・スキームの変更

- クラシック・レプリケーション・スキームでレプリケートされた表の変更

- クラシック・レプリケーション・スキームでレプリケートされた表の切捨て

- クラシック・レプリケーション・スキームの削除

表10-1に、既存のクラシック・レプリケート・システムに対してよく実行するタスクを示します。

表10-1 既存のクラシック・レプリケート・システムに対して実行するタスク

タスク

説明

クラシック・レプリケーション・スキームの変更または削除

「クラシック・レプリケーション・スキームの変更」および「クラシック・レプリケーション・スキームの削除」を参照してください。

レプリケーション・スキームで使用されている表の変更

「クラシック・レプリケーション・スキームでレプリケートされた表の変更」を参照してください。

レプリケーション・スキームで使用されている表の切捨て

「クラシック・レプリケーション・スキームでレプリケートされた表の切捨て」を参照してください。

サブスクライバ・データベースのレプリケーション状態の変更

「サブスクライバのレプリケーション状態の設定」を参照してください。

更新競合の解消

第13章「レプリケーション競合の解消」を参照してください。

障害からのリカバリ

第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照してください。

データベースのアップグレード

ttMigrateおよびttRepAdminユーティリティを使用します(『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のデータベースのアップグレードに関する説明を参照)。

クラシック・レプリケーション・スキームの変更

レプリケーション・エージェントを停止せずに、次のタスクを実行できます。

- ユーザーの作成、変更または削除。これらの文はレプリケートされます。

- ユーザーに対する権限の付与または取消し。これらの文はレプリケートされます。

- サブスクライバをレプリケーション・スキームに追加します。「サブスクライバ・データベースの作成とクラシック・レプリケーション・スキームへの追加」を参照してください。

- マスター・データベースへのPL/SQLオブジェクトの追加およびサブスクライバでのレプリケーションの実行。「既存のクラシック・レプリケーション・スキームへのPL/SQLオブジェクトの追加」を参照してください。

ALTER REPLICATIONを使用すると、マスターおよびサブスクライバのデータベースのクラシック・レプリケーション・スキームを変更できます。また、マスター・データベースに対する変更は、そのサブスクライバに対しても行う必要があります。

注意:
ALTER REPLICATION文を使用するには、ADMIN権限が必要です。

ほとんどのALTER REPLICATION処理は、レプリケーション・エージェントが停止している場合(ttAdmin -repStop)にのみサポートされます。レプリケーション・エージェントを停止する必要があるALTER REPLICATION処理の手順は、次のとおりです。

1. 組込みのttRepStopプロシージャまたはttAdmin -repStopを使用して、マスターおよびサブスクライバのデータベースのレプリケーション・エージェントを停止します。レプリケーション・エージェントの停止中、マスター・データベースへの変更はログに格納されます。

2. マスターとサブスクライバの両方のデータベースで、同じALTER REPLICATION文を発行します。

3. 組込みのttRepStartプロシージャまたはttAdmin -repStartを使用して、マスターおよびサブスクライバのデータベースのレプリケーション・エージェントを再起動します。マスター・データベースのログに格納されている変更がサブスクライバ・データベースに送信されます。

ALTER REPLICATIONを使用してDATASTORE要素を指定するクラシック・レプリケーション・スキームを変更する場合は、次のことに注意してください。

- SET NAMEを使用して、DATASTORE要素の名前を変更することはできません。

- SET CHECK CONFLICTSを使用して、競合解消を有効にすることはできません。

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

- 既存のクラシック・レプリケーション・スキームへの表または順序の追加

- 既存のクラシック・レプリケーション・スキームへのPL/SQLオブジェクトの追加

- 既存のクラシック・レプリケーション・スキームへのDATASTORE要素の追加

- クラシック・レプリケーション・スキームからの表または順序の削除

- サブスクライバ・データベースの作成とクラシック・レプリケーション・スキームへの追加

- クラシック・レプリケーション・スキームからのサブスクライバ・データベースの削除

- クラシック・レプリケーション・スキームでのTABLEまたはSEQUENCE要素名の変更

- クラシック・レプリケーション・スキームでのマスター・データベースの交換

- クラシック・レプリケーション・スキームでの競合検出の無効化

- クラシック・レプリケーション・スキームでのRETURN RECEIPTサービスの無効化

- クラシック・レプリケーション・スキームのポート番号の変更

- レプリケーション・ルートの変更

- ログ障害しきい値の変更

既存のクラシック・レプリケーション・スキームへの表または順序の追加

既存のクラシック・レプリケーション・スキームに表または順序を追加するには、次の2つの方法があります。

- クラシック・レプリケーション・スキームの要素レベルがTABLEまたはSEQUENCEの場合は、ADD ELEMENT句を指定してALTER REPLICATION文を使用し、表または順序を追加します。例10-1を参照してください。

- クラシック・レプリケーション・スキームの要素レベルがDATASTOREの場合は、ALTER ELEMENT句を指定してALTER REPLICATION文を使用し、表または順序を含めます。例10-2を参照してください。

例10-1 レプリケーション・スキームへの順序および表の追加

この例では、例9-10で定義したクラシック・レプリケーション・スキームr1を使用します。レプリケーション・スキームr1を変更して、順序seqおよび表westleadsを追加すると、それらはデータベースwestdsで更新され、データベースeastdsにレプリケートされます。

ALTER REPLICATION r1
ADD ELEMENT elem_seq SEQUENCE seq
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ADD ELEMENT elem_westleads TABLE westleads
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast";

例10-2 DATASTORE要素への順序および表の追加

順序my.seqおよび表my.tab1をmy.rep1レプリケーション・スキームのds1 DATASTORE要素に追加します。

ALTER REPLICATION my.rep1
ALTER ELEMENT ds1 DATASTORE
INCLUDE SEQUENCE my.seq
ALTER ELEMENT ds1 DATASTORE
INCLUDE TABLE my.tab1;

既存のクラシック・レプリケーション・スキームへのPL/SQLオブジェクトの追加

既存のレプリケーション・スキームに新しいPL/SQLプロシージャ、パッケージ、パッケージ本体またはファンクションを追加するには、次のタスクを実行します。

1. マスター・データベースでPL/SQLオブジェクトを作成します。CREATE文はサブスクライバにレプリケートされません。

2. サブスクライバでPL/SQLオブジェクトを作成します。

3. マスター・データベースの新しいPL/SQLオブジェクトに権限を付与します。GRANT文はサブスクライバにレプリケートされます。

既存のクラシック・レプリケーション・スキームへのDATASTORE要素の追加

ADD ELEMENT句を指定してALTER REPLICATION文を使用すると、既存のクラシック・レプリケーション・スキームにDATASTORE要素を追加できます。INCLUDE句またはEXCLUDE句を使用しない場合、一時表を除くすべての表、マテリアライズド・ビューおよび非マテリアライズド・ビューがレプリケーション・スキームに含まれます。「DATASTORE要素追加時の表または順序の挿入」および「DATASTORE要素追加時の表または順序の除外」を参照してください。

例10-3 クラシック・レプリケーション・スキームへのDATASTORE要素の追加

既存のクラシック・レプリケーション・スキームにDATASTORE要素を追加します。

ALTER REPLICATION my.rep1
ADD ELEMENT ds1 DATASTORE
MASTER rep2
SUBSCRIBER rep1, rep3;

DATASTORE要素追加時の表または順序の挿入

既存のクラシック・レプリケーション・スキームにデータベースを追加する場合、レプリケーションを特定の表または順序に制限できます。ADD ELEMENT句と、INCLUDE TABLE句またはINCLUDE SEQUENCE句を指定してALTER REPLICATION文を使用します。同じALTER REPLICATION文の表または順序ごとに1つのINCLUDE句を使用できます。

例10-4 DATASTORE要素への表および順序の挿入

ds1 DATASTORE要素をmy.rep1レプリケーション・スキームに追加します。DATASTORE要素に表my.tab2および順序my.seqを挿入します。

ALTER REPLICATION my.rep1
ADD ELEMENT ds1 DATASTORE
MASTER rep2
SUBSCRIBER rep1, rep3
INCLUDE TABLE my.tab2
INCLUDE SEQUENCE my.seq;

DATASTORE要素追加時の表または順序の除外

既存のクラシック・レプリケーション・スキームにDATASTORE要素を追加する場合、表または順序を除外できます。ADD ELEMENT句と、EXCLUDE TABLE句またはEXCLUDE SEQUENCE句を指定してALTER REPLICATION文を使用します。同じALTER REPLICATION文の表または順序ごとに1つのEXCLUDE句を使用できます。

例10-5 DATASTORE要素からの表または順序の除外

ds2 DATASTORE要素をレプリケーション・スキームに追加しますが、表my.tab1および順序my.seqを除外します。

ALTER REPLICATION my.rep1
ADD ELEMENT ds2 DATASTORE
MASTER rep2
SUBSCRIBER rep1
EXCLUDE TABLE my.tab1
EXCLUDE SEQUENCE my.seq;

クラシック・レプリケーション・スキームからの表または順序の削除

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

- DATASTORE要素の一部としてレプリケートされる表または順序の削除

- TABLEまたはSEQUENCE要素としてレプリケートされる表または順序の削除

DATASTORE要素の一部としてレプリケートされる表または順序の削除

DATASTOREレベルでクラシック・レプリケーション・スキームに含まれている表または順序を削除するには、次のタスクを実行します。

1. レプリケーション・エージェントを停止します。

2. クラシック・レプリケーション・スキームのDATASTORE要素から表または順序を除外します。

3. 表または順序を削除します。

その表または順序が含まれているDATASTORE要素が複数存在する場合は、それを削除する前に各要素からその表または順序を除外する必要があります。

例10-6 DATASTORE要素からの表の除外およびその後の表の削除

my.rep1レプリケーション・スキームのds1 DATASTORE要素から表my.tab1を除外します。その後、その表を削除します。

ALTER REPLICATION my.rep1
ALTER ELEMENT ds1 DATASTORE
EXCLUDE TABLE my.tab1;
DROP TABLE my.tab1;

TABLEまたはSEQUENCE要素としてレプリケートされる表または順序の削除

TABLEまたはSEQUENCEレベルでクラシック・レプリケーション・スキームに含まれている表を削除するには、次のタスクを実行します。

1. レプリケーション・エージェントを停止します。

2. 要素をクラシック・レプリケーション・スキームから削除します。

3. 表または順序を削除します。

例10-7 レプリケーション・スキームからの要素の削除およびその後の順序の削除

SEQUENCEの要素elem_seqをクラシック・レプリケーション・スキームr1から削除します。その後、順序seqを削除します。

ALTER REPLICATION r1
DROP ELEMENT elem_seq;
DROP SEQUENCE seq;

サブスクライバ・データベースの作成とクラシック・レプリケーション・スキームへの追加

レプリケーション・エージェントの実行中は、新しいサブスクライバ・データベースを追加できます。クラシック・レプリケーション・スキームにデータベースを追加するには、次の手順を実行します。

1. 新しいサブスクライバ・データベースが存在しないことを確認します。

2. 関連するすべてのデータベースに適切な文を適用します。

ALTER REPLICATION ...
ALTER ELEMENT ...
ADD SUBSCRIBER ...

3. ソース(マスター)・データベースで、次のように入力してユーザーを作成し、そのユーザーにADMIN権限を付与します。

CREATE USER ttuser IDENTIFIED BY ttuser;
User created.

GRANT admin TO ttuser;

4. インスタンス管理者としてログインして、ttRepAdmin -duplicateコマンドを実行し、新しく作成したサブスクライバにマスター・データベースの内容をコピーします。-setMasterRepStartオプションを使用すると、複製処理後にマスターに対して行われた更新もサブスクライバにコピーできます。

5. 新しく作成したデータベースでレプリケーション・エージェントを起動します(ttAdmin -repStart)。

例10-8 レプリケート表へのサブスクライバの追加

この例では、r1レプリケーション・スキームを変更して、サブスクライバ(backup3)をwestleads表に追加します(前述の手順2)。

ALTER REPLICATION r1
ALTER ELEMENT elem_westleads
ADD SUBSCRIBER backup3 ON "backupserver";

クラシック・レプリケーション・スキームからのサブスクライバ・データベースの削除

サブスクライバ・データベースを削除する前に、レプリケーション・エージェントを停止します。

この例では、r1レプリケーション・スキームを変更して、westleads表のbackup3サブスクライバを削除します。

例10-9 レプリケート表のサブスクライバの削除

ALTER REPLICATION r1
ALTER ELEMENT elem_westleads
DROP SUBSCRIBER backup3 ON "backupserver";

クラシック・レプリケーション・スキームでのTABLEまたはSEQUENCE要素名の変更

クラシック・レプリケーション・スキームでTABLEまたはSEQUENCE要素名を変更する前に、レプリケーション・エージェントを停止します。

westleads表の要素名をelem_westleadsからnewelnameに変更します。

例10-10 表名の変更

ALTER REPLICATION r1
ALTER ELEMENT Eelem_westleads
SET NAME newelname;

注意:
SET NAME句を使用して、DATASTORE要素の名前を変更することはできません。

クラシック・レプリケーション・スキームでのマスター・データベースの交換

クラシック・レプリケーション・スキームでマスター・データベースを交換する前に、レプリケーション・エージェントを停止します。

この例では、現在はマスターとしてwestdsが構成されているすべての要素に新しいマスターnewwestdsを構成します。

例10-11 クラシック・レプリケーション・スキームでのマスター・データベースの交換

ALTER REPLICATION r1
ALTER ELEMENT * IN westds
SET MASTER newwestds;

クラシック・レプリケーション・スキームでの競合検出の無効化

この例では、例13-2に示されているクラシック・レプリケーション・スキームのCHECK CONFLICTS句で構成した競合検出を、elem_accounts_1表に対して無効にします。

例10-12 表の競合検出の無効化

ALTER REPLICATION r1
ALTER ELEMENT elem_accounts_1
SET NO CHECK;

競合検出の詳細は、第13章「レプリケーション競合の解消」を参照してください。

クラシック・レプリケーション・スキームでのRETURN RECEIPTサービスの無効化

この例では、例9-10に示されているクラシック・レプリケーション・スキームの最初のサブスクライバに対してRETURN RECEIPTサービスを無効にします。

例10-13 サブスクライバのRETURN RECEIPTサービスの無効化

ALTER REPLICATION r1
ALTER ELEMENT elem_waccounts
ALTER SUBSCRIBER eastds ON "eastcoast"
SET NO RETURN;

クラシック・レプリケーション・スキームのポート番号の変更

ポート番号とは、サブスクライバ・データベースのレプリケーション・エージェントがマスター・レプリケーション・エージェントからの接続リクエストを受け入れるTCP/IPポート番号のことです。レプリケーション・エージェントへのポートの割当て方法の詳細は、「ポート割当て」を参照してください。

この例では、r1レプリケーション・スキームを変更して、eastdsのポート番号を22251に変更します。

例10-14 データベースのポート番号の変更

ALTER REPLICATION r1
ALTER STORE eastds ON "eastcoast"
SET PORT 22251;

レプリケーション・ルートの変更

レプリケーション・ホストにネットワーク・インタフェースが複数ある場合は、レプリケーション・トラフィックに使用するインタフェースをROUTE句で指定できます。レプリケーションで使用するインタフェースの変更が必要な場合は、ROUTE句のIPアドレスを削除または追加して変更できます。詳細は、「ROUTE句を使用したネットワーク・インタフェースの構成」を参照してください。

ログ障害しきい値の変更

STOREパラメータのFAILTHRESHOLD属性を使用すると、ログ障害しきい値を再設定できます。レプリケーション・エージェントを停止してから、ALTER REPLICATIONを使用して新しいしきい値を定義し、その後、レプリケーション・エージェントを再起動します。

ログ障害しきい値の詳細は、「トランザクション・ログ障害しきい値の設定」を参照してください。

クラシック・レプリケーション・スキームでレプリケートされた表の変更

ALTER TABLE ... ADD COLUMN文またはALTER TABLE ... DROP COLUMN文を使用すると、クラシック・レプリケーション・スキームのマスター・データベースで列を追加または削除できます。ALTER TABLE処理をレプリケートすると、サブスクライバ・データベースが変更されます。クラシック・レプリケーション・スキームでレプリケートされるALTER TABLE句は、これだけです。

双方向レプリケーションに構成されているデータベースでALTER TABLEを使用する場合は、まず、すべてのレプリケーション・データベース上にある表への更新を停止し、表へのすべてのレプリケート対象の更新がデータベースによって受信されていることを確認してから、ALTER TABLE文を発行します。ALTER TABLE処理がすべてのデータベースにレプリケートされるまで、更新は再開しないでください。これは、すべてのデータベースで表が変更された後まで書込み処理が行われないようにするために必要です。

注意:
データベースで更新が受信およびコミットされたことを確認するには、第12章「レプリケーションの監視」で説明されているttRepSubscriberWait組込みプロシージャまたはモニタリング・ツールを使用できます。

また、データベース上で連続した多数のALTER TABLE処理を実行する場合は、前のALTER TABLEがすべてのサブスクライバに到達したことを確認してから、次のALTER TABLEに進む必要があります。

注意:
ALTER TABLE文を使用してデフォルトの列値を変更することはできますが、ALTER TABLE文はレプリケートされません。したがって、すべてのノードでデフォルトの列値を同じにする必要はありません。

クラシック・レプリケーション・スキームでレプリケートされた表の切捨て

TRUNCATE TABLEを使用すると、表自身を削除せずに表のすべての行を削除できます。表の切捨ての処理は、DELETE FROM Table文よりも高速です。

レプリケート表の切捨て処理がレプリケートされると、結果としてサブスクライバ・データベースの表が切り捨てられます。ただし、削除処理とは異なり、個々の行は削除されません。切捨て処理時に表の内容が一致していない場合でも、サブスクライバ・データベースの行は削除されます。

TRUNCATE文を使用すると、処理対象の行が存在しない場合でも、サブスクライバにレプリケートされます。

タイムスタンプ競合検出が有効な状態で表をレプリケートすると、競合はレポートされません。

クラシック・レプリケーション・スキームの削除

DROP REPLICATION文を使用して、データベースからレプリケーション・スキームを削除できます。クラシック・レプリケーション・スキームがデータベース内の唯一のレプリケーション・スキームでないかぎり、マスター・キャッチアップが必要な場合はクラシック・レプリケーション・スキームを削除できません。

注意:
DROP REPLICATION文を使用するには、ADMIN権限が必要です。

クラシック・レプリケーション・スキームを削除する前に、レプリケーション・エージェントを停止する必要があります。

例10-15 レプリケーション・スキームの削除

データベースからrepschemeレプリケーション・スキームを削除するには、次のように入力します。

DROP REPLICATION repscheme;

レプリケート表を削除する場合は、レプリケート表を削除する前にクラシック・レプリケーション・スキームを削除する必要があります。そうしない場合、レプリケート表または索引を削除しようとしたことを示すエラーを受信します。

例10-16 データベースからの表およびクラシック・レプリケーション・スキームの削除

データベースからtab表およびrepschemeレプリケーション・スキームを削除するには、次のように入力します。

DROP REPLICATION repscheme;
DROP TABLE tab;

11 レプリケート・システムの設定

この章では、レプリケーションの設定方法および開始方法について説明します。

- レプリケーション環境の設定

- サブスクライバへのマスター・データベースの複製

- 多数のサブスクライバの構成

- 異なるリリース間でのデータベースのレプリケート

- レプリケーション・エージェントの起動および停止

- サブスクライバのレプリケーション状態の設定

レプリケーション環境の設定

次の各項ではレプリケーション環境を設定する方法について説明します。

- データベースの設定

- レプリケート・データベースの接続属性

- パラレル・レプリケーションの構成

- レプリケート・データベースでのトランザクション・ログの管理

データベースの設定

既存のデータベースの1つ以上の表をレプリケーションできます。レプリケートする必要があるデータベースが存在しない場合は、まず『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明に従って、そのデータベースを作成する必要があります。

マスター・データベースを指定または作成した後、ターゲット・ホストでサブスクライバ・データベースのDSN定義を作成します。マスターおよびサブスクライバのデータベースの接続属性を設定します(「レプリケート・データベースの接続属性」を参照)。

サブスクライバのDSNを設定した後、次の2つの方法のいずれかの方法で、マスターからレプリケートする表をサブスクライバ・データベースに移入できます。

- データベースに接続し、SQL文を使用して、マスターからレプリケートする表と一致する新しい表をサブスクライバ・データベースに作成します。

- ttRepAdmin -duplicateユーティリティを使用して、マスター・データベースの内容全体をサブスクライバにコピーします。詳細は、「サブスクライバへのマスター・データベースの複製」を参照してください。

レプリケート・データベースの接続属性

相互にレプリケーションを行うデータベースで、DatabaseCharacterSetデータ・ストア属性が同じである必要があります。TimesTenでは、レプリケート・データベース間のキャラクタ・セット変換は実行されません。

パラレル・レプリケーションを構成する場合、ReplicationParallelismデータ・ストア属性およびReplicationApplyOrderingデータ・ストア属性の設定の詳細は、「パラレル・レプリケーションの構成」を参照してください。

レプリケーション・ログ・ファイルを管理するための推奨事項については、「ロギングの接続属性の設定」を参照してください。

TypeModeデータ・ストア属性の設定が異なるデータベース間でもレプリケーションは実行できます。ただし、各レプリケーション列の基礎となるデータ型は各ノードで同じにする必要があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTypeModeに関する説明を参照してください。

アクティブ・スタンバイ・ペアで、アクティブ・データベースからスタンバイ・データベースへ変更を適用するスレッドの数を1から2に増やすには、ReceiverThreads初期接続属性を使用します。フェイルオーバーが発生した場合にスループットの向上を維持するためには、スタンバイ・データベースでReceiverThreadsを2に設定した場合、アクティブ・データベースでも2に設定する必要があります。

アクティブ・スタンバイ・ペアの1つ以上の読取り専用サブスクライバでReceiverThreadsを2に設定して、スタンバイ・データベースからのレプリケーション・スループットを向上させることもできます。

この属性を2に設定したことによる効果を得るには、データベースが2つ以上のCPUを持つシステムでホストされている必要があります。

パラレル・レプリケーションの構成

デフォルトでは、レプリケーションは、レプリケーション・スキーム内のノードに、1つのログ・リーダー(ソース・データベースでのトランスミッタ・スレッド)と1つのアプライヤ(ターゲット・データベースでのレシーバ・スレッド)が含まれるシングル・スレッドで実行されます。ソース・データベースからターゲット・データベースに更新を送信し、その更新をターゲット・データベースで適用するための複数のスレッドを構成するパラレル・レプリケーションを構成することによって、パフォーマンスを向上させることができます。これらのスレッドは、レプリケーションと、レプリケーション・スキーム内のノードへのトランザクションの変更の適用を並行して行います。デフォルトでは、パラレル・レプリケーションは、トランザクションの依存性を強制し、コミット順に変更を適用しますが、コミット順の強制は無効化できます。

注意:
パラレル・レプリケーションを有効にした場合、同じトランザクション内でDDL文とDML文の両方を実行することはできません。

パラレル・レプリケーションのオプション

- 自動パラレル・レプリケーション: トランザクションの依存性と、コミット順に適用されたすべての変更を自動的に適用する、複数のスレッドにおけるパラレル・レプリケーション。これはデフォルトです。

- コミット依存性を無効にした自動パラレル・レプリケーション: トランザクションの依存性を自動的に強制するが、サブスクライバ・データベース上でマスター・データベース上と同じ順序でコミットされるトランザクションは強制しない、複数スレッドでのパラレル・レプリケーション。

- ユーザー定義のパラレル・レプリケーション: クラシック・レプリケーション・スキームを使用し、トランザクションの依存性の予測性が高く、レシーバでのコミット順序が元のデータベース上のコミット順序と同じである必要がないアプリケーションの場合。トランザクションの追跡数を指定し、各追跡に特定のトランザクションを適用できます。すべての追跡の読取り、送信および適用はパラレルに行われます。

これらのオプションは、ReplicationApplyOrderingおよびReplicationParallelismのデータ・ストア作成属性で構成され、これはデータベースの作成時に設定する必要があります。

注意:
パラレル・レプリケーションを使用したレプリケーション・スキーム内のすべてのデータベースは、同じタイプのパラレル・レプリケーションおよび同じ数のスレッドまたはトラックを使用して同一に構成する必要があります。
パラレル・レプリケーションの属性に異なる値を設定できるのは、アップグレード中のみです。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のパラレル・レプリケーション使用時のアップグレードに関する説明を参照してください。

次の項では、パラレル・レプリケーションのオプションについて説明します。

- 自動パラレル・レプリケーションの構成

- コミット依存性を無効にした自動パラレル・レプリケーションの構成

- クラシック・レプリケーション・スキームに対するユーザー定義のパラレル・レプリケーションの構成

自動パラレル・レプリケーションの構成

自動パラレル・レプリケーションを使用すると、レプリケーションと、クラシックまたはスタンバイ・ペアのレプリケーション・スキーム内のノードへのトランザクションの変更の適用を並行して行う複数のスレッドを構成できます。自動パラレル・レプリケーションでは、トランザクションの依存性が強制され、変更がコミット順に適用されます。

自動パラレル・レプリケーションを有効にするには、データベース作成時に、次のようにデータ・ストア属性を設定します。

- ReplicationApplyOrdering=0に設定します。これはデフォルトでもあります。

- ReplicationParallelismを2から32の数値に設定します。この数値は、LogBufParallelismの半分の値を超えることはできません。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。ただし、シングル・スレッド・レプリケーションを使用している場合、ReplicationParallelismを1 (デフォルト)に設定します。

注意:
ReplicationParallelismが1より大きい場合は、LogBufParallelism初期接続属性はReplicationParallelismの整数倍である必要があります。

レプリケーション・スキームがAWTキャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアである場合は、データ・ストア属性ReplicationApplyOrdering、ReplicationParallelismおよびCacheAWTParallelismの設定によって、TimesTenキャッシュ表の変更を対応するOracle Database表に適用するのに使用されるスレッド数が決定されます。詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Database表へのパラレル伝播の構成に関する説明を参照してください。

これらのデータ・ストア属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationParallelism、ReplicationApplyOrderingおよびLogBufParallelismに関する説明を参照してください。

コミット依存性を無効にした自動パラレル・レプリケーションの構成

トランザクションの依存性を強制し、変更をコミット順に適用するために、自動パラレル・レプリケーションは通常、次のものを追跡します。

- 開始の依存性: 行を挿入してから同じ行を削除するなど、あるトランザクションを強制的に他のトランザクションより前に実行させる操作。

- コミットの依存性: トランザクションをマスター・データベース上と同じ順序でサブスクライバ上でコミットするときの順序。

パラレル・レプリケーションでは、複数のスレッドを使用することによってパフォーマンスが向上しますが、トランザクションでコミットの依存性を強制する必要がない場合には、自動パラレル・レプリケーションを使用するとスループット・パフォーマンスがさらに向上します。つまり、アプリケーションでトランザクションの依存性が予測可能で、ターゲット・データベースでのコミット順序がソース・データベースでの順序と同じである必要がない場合には、コミットの依存性の強制をゆるめても、正しいトランザクションを維持できるということです。たとえば、別個のトランザクションを別個の表に対して実行する場合、コミットの依存性を強制する必要はありません。

コミットの依存性を追跡する必要性をゆるめると、自動パラレル・レプリケーションのパフォーマンスが向上します。コミットの依存性を強制しない場合、非DDLトランザクションがサブスクライバでコミットされる順序は、マスターで実行される元々の順序と異なることがあります。開始の依存性は、不正な順序が適用されないように、常に強制されます。

自動パラレル・レプリケーションのコミットの依存性を無効にできるのは、非同期レプリケーションを使用し、キャッシュ・グループを含まないアクティブなスタンバイ・ペアのみです。データベースの作成時には、次のデータ・ストア属性を設定できます。

- TimesTenデータベースを作成する前に、ReplicationApplyOrdering=2を設定します。

- ReplicationParallelismを2から32の数値に設定します。この数値は、LogBufParallelismの半分の値を超えることはできません。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。ただし、シングル・スレッド・レプリケーションを使用している場合、ReplicationParallelismを1 (デフォルト)に設定します。

注意:
ReplicationParallelismが1より大きい場合は、LogBufParallelism初期接続属性はReplicationParallelismの整数倍である必要があります。

ただし、パフォーマンスが向上する反面、このオプションでは一時領域に16MBの追加領域と、構成済の各レプリケーション・トラックに16MBの追加領域が必要になります(ReplicationParallelism接続属性の設定)。たとえば、ReplicationParallism接続属性を10に設定した場合、この機能には16MB + 160MB = 176MBの一時領域が追加で必要です。

自動パラレル・レプリケーションを使用し、コミットの依存性を無効にすると、トラックの一部が他の前に移動する場合があります。これは、パラレル・レプリケーション・トラック間のドリフトとして知られています。レプリケーション・トラック間のドリフトの量は、ttDbConfig組込みプロシージャ内でParReplMaxDrift構成パラメータを設定して制限することができます。

Call ttDbConfig("ParReplMaxDrift", "30");

この例では、レプリケーション・トラック間で許容されるドリフトを30秒に設定しており、それが過ぎるとすべてのレプリケーション・トラックが相互に追いつきます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。

自動パラレル・レプリケーション環境でのレプリケーション・トラックの指定

一般的に、マスターからサブスクライバに各トランザクションをレプリケートするときのスレッド(トラック)は自動パラレル・レプリケーションによって決まります。したがって、複数のトラック間における処理の分割方法を手動で決めることはできません。

ただし、依存トランザクションの場合は、手動で同じトラックにトランザクションを割り当ててパフォーマンスの向上を達成することができます。したがってアプリケーションには、ソース・データベースでトランザクションが開始されるとき、ReplicationTrack接続属性か、ALTER SESSION SET REPLICATION_TRACK文を使用して、トランザクションがどのトラックに属するかを指定するオプションがあります。その後、この接続のトランザクションはすべて、このトラックを使用します。このトラックのトランザクションは、ターゲット・データベースで受信された順に適用されますが、異なるトラック間のトランザクションではコミット順序は保持されません。トランザクションにトラックを指定する場合は、トラック間でワークロードが均等に分散するようにしてください。

受信側で順番に適用される必要のある更新は、同じトラックを使用する必要があります。1つの表に対する操作を、キー値に基づいて別個のトラック間に分散することができます。たとえば、通信会社の請求処理アプリケーションがあるとすると、口座番号のハッシュを使用してトラックを設定し、各講座のすべてのトランザクションを異なるトラックで送ることができます。

TimesTenは引き続き依存性を計算して強制し、依存トランザクションが受信側でも正しい順序で適用されるようにします。

アプリケーションは、次のいずれかの方法でトランザクションをトラックに割り当てます。

- ReplicationTrack一般接続属性をゼロ以外の数値に設定します。接続によって発行されたすべてのトランザクションは、このトラックに割り当てられます。値は任意の数値です。TimesTenは、この接続のReplicationTrack数をパラレル・レプリケーションの使用可能なスレッドのいずれかにマップします。これにより、アプリケーションで任意の数を使用して、順番に適用する必要のあるトランザクションをグループ化できます。『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationTrackに関する説明を参照してください。

- ALTER SESSION SQL文を使用して、現在の接続のレプリケーション・トラック数を設定します。『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER SESSION」を参照してください。

- SQLSetConnectOption ODBC関数のTT_REPLICATION_TRACK ODBC接続オプションを使用します。『Oracle TimesTen In-Memory Database C開発者ガイド』のレプリケーションで使用するための機能に関する説明を参照してください。

- TimesTenConnection JDBCクラスのsetReplicationTrack()メソッドを使用します。『Oracle TimesTen In-Memory Database Java開発者ガイド』のレプリケーションで使用するための機能に関する説明を参照してください。

ttConfiguration組込みプロシージャを使用すると、現在の接続のレプリケーション・トラック数が返されます。ttLogHolds組込みプロシージャを使用すると、複数のトラックが使用されているかどうかを確認できます。

クラシック・レプリケーション・スキームに対するユーザー定義のパラレル・レプリケーションの構成

アプリケーションにクラシック・レプリケーション・スキームがあり、予測可能なトランザクションの依存性が存在し、ターゲット・データベースとソース・データベースでコミット順序が同じである必要がない場合、ユーザー定義のパラレル・レプリケーションを使用することで、ユーザーが異なるトラック間の処理を手動で割り当てることができ、レプリケーション・スループットを向上できます。

ユーザー定義のパラレル・レプリケーションでは、ソース・データベースからターゲット・データベースに更新を送信し、その更新をターゲット・データベースで適用するための複数のスレッドを構成します。トランザクションは常に、アプリケーションによってトラックに割り当てられます。また、トランザクションが属するトラックは、ソース・データベースでトランザクションが開始されたときにアプリケーションによって指定されます。各トラックのトランザクションは、ターゲット・データベースで受信された順に適用されますが、異なるトラック間のトランザクションではコミット順序は保持されません。

注意:
外部キーで関連付けられている表に影響を与えるトランザクションをトラックに割り当てる場合は、注意する必要があります。関連付けられている表に対するトランザクションが別々のトラックに割り当てられた場合、トランザクションのコミット順序が変更され、いずれかのトランザクションが失われてしまう可能性があります。

通常、同じ表を変更するトランザクションは、同じレプリケーション・トラックに割り当てる必要があります。また、受信側で順番に適用される必要のある更新は、同じトラックを使用する必要があります。ただし、すべてのトランザクションが同じ表への挿入処理である場合、トランザクションを異なるトラックに割り当ててレプリケーション・スループットを向上できます。行を同じトラックに関連付けるキーを使用して、複数のトラック間で表のワークロードを分割できます。

ユーザー定義パラレル・レプリケーションは、クラシック・レプリケーション・スキームでのみ使用できます。

ユーザー定義のパラレル・レプリケーションを有効にするには、データベース作成時に、次のようにデータ・ストア属性を設定します。

- ReplicationApplyOrderingを1に設定します。

- ReplicationParallelismを1から64の数値に設定します。この数値は、ソース・データベースでのTRANSMITTERスレッド数およびターゲット・データベースでのRECEIVERスレッド数を示します。シングル・スレッド・レプリケーションでは、1 (デフォルト)に設定します。パラレル・レプリケーションを使用するためには、2から64の数値に設定します。

また、アプリケーションは「自動パラレル・レプリケーション環境でのレプリケーション・トラックの指定」で説明されているのと同じ方法で、トランザクションをトラックに割り当てる必要があります。唯一の違いは、ユーザー定義のパラレル・レプリケーション・スキームでは常に、接続のトランザクションに使用されるトラックが指定されることです。

ユーザー定義のパラレル・レプリケーションの制限

- エージング・ポリシーが定義されている表に対して、ユーザー定義のパラレル・レプリケーションを構成しないでください。

- ユーザー定義のパラレル・レプリケーションが構成されているデータベースには、キャッシュ・グループを含めることはできません。

- ユーザー定義のパラレル・レプリケーションを構成している場合、データベースをプロパゲータとして定義できません。

- ユーザー定義のパラレル・レプリケーションをアクティブ・スタンバイ・ペアのレプリケーション・スキーム内で使用することはサポートされていません。

- ユーザー定義のパラレル・レプリケーションは、同期レプリケーション(RETURN RECEIPT属性およびRETURN TWOSAFE属性が構成されたデータベースを含む)ではサポートされていません。

- ユーザー定義のパラレル・レプリケーションが有効でないデータベースからユーザー定義のパラレル・レプリケーションが有効なデータベースへの、リリース間のレプリケーションおよび移行は、リリース11.2.1.6.0から11.2.1.8.0まではサポートされません。11.2.1.6.0より前と、11.2.1.8.0以降のリリースではサポートされています。11.2.1.6.0から11.2.1.8.0のユーザーは、まず11.2.1.8.0のインプレース・パッチ・リリース・アップグレードを適用してから、アップグレードを実行できます。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のパラレル・レプリケーション使用時のアップグレードに関する説明を参照してください。

レプリケート・データベースでのトランザクション・ログの管理

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

- ログ・バッファのフラッシュについて

- マスター・データベースでのトランザクション・ログの増大について

- ロギングの接続属性の設定

ログ・バッファのフラッシュについて

専用のサブデーモン・スレッドはログ・バッファの内容を定期的にディスクに書き込みます。これらの書込みは同期化またはバッファリングできます。サブデーモン・スレッドは、ログ・バッファに同期化することなく、システムI/OバッファがLogFileSize初期接続属性の値を超えるトランザクション・ログ・データで一杯にならないようにします。

データベースがLogFlushMethod=2で構成されている場合は、ディスクへの書込みはすべて同期書込みで、書込みコールが返される前にデータはディスクに永続的に書き込まれます。データベースがLogFlushMethod=1で構成されている場合には、アプリケーションから同期書込みの特定のリクエストがないかぎり、書込みはバッファリングされます。

定期的な書込みに加えて、アプリケーションはサブデーモン・スレッドをトリガーして、バッファの内容をディスクに書き込むこともできます。次に、アプリケーションがディスクへの同期書込みをトリガーする場合を示します。

- 永続コミットをリクエストしたトランザクションがコミットされた場合。ttDurableCommit組込みプロシージャをコールするか、DurableCommits接続属性を1に設定することによって、トランザクションは永続コミットをリクエストできます。

- レプリケーション・エージェントがサブスクライバにトランザクションのバッチを送信する際に、マスターがレプリケーションに対してTRANSMIT DURABLE属性(デフォルト)で構成されている場合。

- マスター・データベースがTRANSMIT DURABLEで構成されているかどうかに関係なく、レプリケーション・エージェントが定期的に永続コミットを実行する場合。

また、永続コミットが戻りサービス失敗ポリシーの一部として構成されており、障害が発生した場合にも、トランザクションは永続的にディスクに書き込まれます。

前述の場合、ログ・バッファのサイズは、TimesTenによるディスクへのデータの書込みに影響しません。

マスター・データベースでのトランザクション・ログの増大について

レプリケーション、トランザクション・ログAPI(XLA)、キャッシュ・グループまたは増分バックアップを使用しないデータベースでは、自動バックグラウンド・チェックポイント・スレッドあるいはアプリケーションのttCkptまたはttCkptBlocking組込みプロシージャのコールのいずれかによってチェックポイントが開始されるたびに、ログ・バッファ内の不要なレコードおよび不要なトランザクション・ログ・ファイルがパージされます。レプリケート・データベースでは、トランザクションがサブスクライバで完全に処理されたことをマスター・レプリケーション・エージェントが確認するまで、トランザクションはログ・バッファおよびトランザクション・ログ・ファイルに保持されます。マスターは、これを確認した時点でのみ、ログ・バッファおよびトランザクション・ログ・ファイルからのパージが必要であると認識します。

サブスクライバの状態が変わると、マスター・データベースのトランザクション・ログが、レプリケートされていないデータベースのログより大幅に大きくなる可能性があります。サブスクライバがstart状態の場合、マスターはサブスクライバからの情報の受信確認を受信した後、ログされているデータをパージできます。ただし、サブスクライバが使用不能またはpause状態になると、マスター・データベースのログはフラッシュできず、ログに使用する領域が使い果たされる可能性があります。ログ領域を使い果たすと、マスター・データベースでの後続の更新が強制終了されます。ttLogHolds組込みプロシージャを使用して、レプリケーション・ログに関する情報を取得します。

注意:
トランザクション・ログの増大の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの蓄積の監視に関する説明を参照してください。ttLogHolds組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttLogHolds組込みプロシージャによるレプリケーションの監視に関する説明またはttLogHoldsに関する説明を参照してください。

ロギングの接続属性の設定

LogBufMBでは、インメモリー・ログ・バッファの最大サイズを指定します(MB単位)。このバッファは、一杯になると、ディスク上のトランザクション・ログ・ファイルにフラッシュされます。LogBufMBの最小サイズは、LogBufParallelismの値の8倍です。

トランザクション・ログ・ファイルのために十分なディスク領域を確保する必要があります。ログで使用されるディスク領域の量を管理する場合、次の2つの設定があります。

- DSNのLogFileSize設定では、トランザクション・ログ・ファイルの最大サイズを指定します。ロギング要件がこの値を超えると、同じ最大サイズを持つ追加のトランザクション・ログ・ファイルが作成されます。最適なパフォーマンスを実現するには、LogBufMBおよびLogFileSizeを最大値に設定します。

- ログの障害しきい値の設定では、マスターがサブスクライバで障害が発生したと想定するまでに累積できるトランザクション・ログ・ファイルの最大数を指定します。このしきい値は、最後に書き込まれたトランザクション・ログ・ファイルと、サブスクライバ用に最初に保存されたトランザクション・ログ・ファイルの間のトランザクション・ログ・ファイルの数です。たとえば、すべてのサブスクライバが受信に成功した最後のレコードがログ・ファイル1にあり、ディスクに書き込まれた最後のログ・レコードがログ・ファイル4の先頭にある場合は、2つ以上のトランザクション・ログ・ファイル(ログ・ファイル2および3の内容)がレプリケートされていません。しきい値が2の場合、マスターは、しきい値を超えたことを検出した後にサブスクライバをfailed状態に設定します。これには10秒かかる場合があります。詳細は、「トランザクション・ログ障害しきい値の設定」を参照してください。

トランザクションはディスクにロギングされるため、ブックマークを使用して、サブスクライバにレプリケートされた更新レコードおよびディスクに書き込まれた更新レコードのログ・レコード識別子を検出できます。masterDSNに関連付けられているサブスクライバのブックマークの位置を表示するには、ttBookmark組込みプロシージャを使用します(「レプリケート・ログ・レコードの表示」を参照)。

サブスクライバが停止して、しきい値に達する前に再起動した場合、ブックマークの後に続くトランザクション・ログ・ファイル内のコミット済トランザクションが自動的に送信されるため、レプリケーションは自動的にキャッチアップします。ただし、しきい値を超えると、マスターはサブスクライバをfailed状態に設定します。障害が発生したサブスクライバは、ttRepAdmin -duplicateを使用してマスター・データベースをコピーし、処理を最初から再実行します(第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照)。

TimesTenの接続属性、組込みプロシージャおよびユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。

サブスクライバへのマスター・データベースの複製

サブスクライバ・データベースに内容を移入する最も簡単な方法は、マスター・データベースの内容を複製する方法です。また、障害が発生したデータベースのリカバリ時にも、この方法でデータベースを複製する必要があります(第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照)。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。

データベースを複製する場合は、次の条件を満たす必要があります。

- インスタンス管理者が複製操作を実行します。

- インスタンス管理者のユーザー名は、複製に含まれる両方のインスタンスで同じである必要があります。

- ソース・データベースで、ADMIN権限があるユーザーのユーザー名とパスワードを入力する必要があります。

- ターゲットDSNにクライアント属性およびサーバー属性を含めることはできません。

マスター・データベースの内容をサブスクライバ・データベースに複製するには、次のタスクを実行します。

1. レプリケーション・スキームを作成または変更して、新しいサブスクライバ・データベースおよびそのホストを指定します。「クラシック・レプリケーション・スキームの定義」または「サブスクライバ・データベースの作成とクラシック・レプリケーション・スキームへの追加」を参照してください。

2. レプリケーション・スキームをマスター・データベースに適用します。「データベースへのクラシック・レプリケーション・スキームの適用」を参照してください。

3. マスター・データベースのレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

4. ソース(マスター)・データベースで、次のように入力してユーザーを作成し、そのユーザーにADMIN権限を付与します。

CREATE USER ttuser IDENTIFIED BY ttuser;
User created.

GRANT admin TO ttuser;

5. インスタンス管理者のユーザー名がtimestenであるとします。ターゲット・ホスト(サブスクライバ)でtimestenとしてログインし、次のようにhost1のデータベースmasterDSNをsubscriber1DSNに複製します。

ttRepAdmin -duplicate -from masterDSN -host host1 subscriber1DSN

Enter internal UID at the remote datastore with ADMIN privileges: ttuser
Enter password of the internal Uid at the remote datastore:

リモート・データベースの内部ユーザーのパスワードを入力するよう要求されたら、ttuserと入力します。

注意:
ホスト・エントリは、リモート・ホストの名前またはTCP/IPアドレスのいずれかで指定できます。TCP/IPアドレスを使用してホストを指定する場合は、-localhostオプションを使用してローカル・ホスト(この例ではhost1)のアドレスを指定する必要があります。
ソース・ホストとターゲット・ホストのローカルおよびリモートのネットワーク・インタフェースを指定するには、ttRepAdmin -duplicateの-localIPオプションと-remoteIPオプションを使用します。一方または両方のネットワーク・インタフェースが指定されていない場合は、TimesTenによって選択されます。

詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepAdminに関する説明を参照してください。

6. サブスクライバ・データベースでレプリケーション・エージェントを起動します。

多数のサブスクライバの構成

レプリケーション・スキームには最大128のサブスクライバを含めることができます。プロパゲータ・データベースを使用するレプリケーション・スキームには最大128のプロパゲータを含めることができ、各プロパゲータには最大128のサブスクライバを構成できます。アクティブ・スタンバイ・ペアのレプリケーション・スキームには、最大127の読取り専用サブスクライバを含めることができます。多数のサブスクライバが含まれるレプリケーション・スキームを計画する場合は、次のことを実行する必要があります。

- ログ・バッファのサイズは、SYS.MONITOR表のLOG_FS_READSの値が0(ゼロ)または0(ゼロ)に近い値になるようにすること。これによって、レプリケーション・エージェントでディスクからログ・レコードを読み取る必要がなくなります。LOG_FS_READSの値が増大する場合は、ログ・バッファのサイズを大きくします。

- CPUリソースが十分にあること。マスター・データベースのレプリケーション・エージェントは、各サブスクライバ・データベースに対してスレッドを生成します。各スレッドでログの読取りおよび処理が個別に行われるため、サブスクライバ・データベースに送信するには適切なCPUリソースが必要です。

異なるリリース間でのデータベースのレプリケート

異なるリリース間でのレプリケーションは、新しいバージョンのTimesTenのデータベースが古いバージョンのTimesTenのデータベースからttMigrateを使用してアップグレードされた場合にのみ機能します。最新のバージョンのTimesTenで作成したデータベースでは、それより古いバージョンでの正常なレプリケートは保証されていません。

たとえば、TimesTenリリース6.0で作成されたデータベースとTimesTenリリース11.2.1で作成されたデータベース間のレプリケーションはサポートされていません。ただし、一方のデータベースがTimesTenリリース6.0で作成され、そのピア・データベースがTimesTenリリース6.0で作成された後でTimesTenリリース11.2.1にアップグレードされた場合、これらの間のレプリケーションはサポートされます。

『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の「TimesTenのアップグレード」を参照してください。

レプリケーション・エージェントの起動および停止

レプリケーション・スキームを定義した後、レプリケーション・スキームに含まれている各データベースのレプリケーション・エージェントを起動できます。レプリケーション・エージェントを起動および停止するには、ADMIN権限が必要です。

レプリケーション・エージェントは、ttAdminユーティリティに-repStartまたは-repStopオプションを指定して、起動および停止できます。また、ttRepStartおよびttRepStop組込みプロシージャを使用して、ttIsqlコマンドラインからレプリケーション・エージェントを起動および停止することもできます。

例11-1 ttAdminによるレプリケーション・エージェントの起動および停止

masterDSNおよびsubscriberDSNというDSNのレプリケーション・エージェントを起動するには、次のように入力します。

ttAdmin -repStart masterDSN
ttAdmin -repStart subscriberDSN

レプリケーション・エージェントを停止するには、次のように入力します。

ttAdmin -repStop masterDSN
ttAdmin -repStop subscriberDSN

例11-2 ttIsqlからのレプリケーション・エージェントの起動および停止

masterDSNというDSNのレプリケーション・エージェントを起動および停止するには、次のように入力します。

> ttIsql masterDSN
Command> call ttRepStart;
Command> call ttRepStop;

また、ttAdminユーティリティを使用してレプリケーション再起動ポリシーを設定することもできます。デフォルトでは、このポリシーはmanualで、これによって、前述のようにレプリケーション・エージェントを起動および停止できます。データベースのレプリケーション再起動ポリシーは、alwaysまたはnorestartに設定することもできます。

再起動ポリシー

TimesTenデーモンの起動時にレプリケーション・エージェントを起動

エラー発生時または無効化が行われた場合にレプリケーション・エージェントを再起動

always

する

する

manual

しない

する

norestart

しない

しない

注意:
レプリケーション・エージェントはTimesTenデーモンによって管理されます。レプリケーション・エージェントを起動または停止するには、これが実行されている必要があります。

再起動ポリシーがalwaysの場合、データベースがメモリーにロードされるとレプリケーション・エージェントが自動的に起動されます。データベースがメモリーにロードされるタイミングを指定する方法については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。

例11-3 ttAdminを使用した再起動ポリシーの設定

ttAdminを使用して、レプリケーション再起動ポリシーをalwaysに設定するには、次のように入力します。

ttAdmin -repPolicy always DSN

ポリシーをmanualに再設定するには、次のように入力します。

ttAdmin -repPolicy manual DSN

データベースの無効化の後、manualおよびalwaysの両方のポリシーによってレプリケーション・エージェントが自動的に再起動されます。レプリケーション・エージェントが自動的に再起動されると、多くの場合、データベースへの初期接続になります。たとえば、これは、すべてのアプリケーションの接続を切断する必要がある致命的なエラーが発生した後に行われます。通常、データベースへの初期接続では、最新のチェックポイント・ファイルをロードする必要があり、また、多くの場合リカバリを実行する必要があります。非常に大容量のデータベースの場合、このプロセスに数分かかる場合があります。この間、新しい接続が行われず、古い接続の切断が終了されないように、データベースでのすべてのアクティビティがブロックされます。また、この結果、すべてのアプリケーションの接続が切断されるまで古いデータベースが存続するため、データベースの2つのコピーが同時に存在する場合もあります。初期接続時が重要な非常に大容量のデータベースの場合、新しいデータベースを起動する前にまず古いデータベースが非アクティブになるまで待機する必要がある場合があります。これは、再起動ポリシーnorestartに設定してレプリケーション・エージェントが自動的に再起動されないように指定することで実現できます。データベースがメモリーにロードされるタイミングを判断するために、データベースがリロードされないようにする設定ポリシーについて、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。

サブスクライバのレプリケーション状態の設定

サブスクライバ・レプリケーション・エージェントの状態は、そのマスター・データベースによって記述されます。障害が発生したサブスクライバ・データベースをリカバリする場合は、レプリケーション・スキームで通信するマスター・データベースに対するサブスクライバ・データベースのレプリケーション状態を再設定する必要があります。サブスクライバ・データベースの状態は、コマンドラインまたはプログラムから再設定できます。

- コマンドラインから、ttRepAdmin -stateを使用して、いずれかのサブスクライバ・データベースのレプリケーション状態を再設定するようにマスター・データベースに指示します。

- ttIsqlから、ttRepSubscriberStateSet組込みプロシージャをコールして、いずれかまたはすべてのサブスクライバ・データベースのレプリケーション状態を再設定するようにマスター・データベースに指示します。

データベースの状態の問合せについては、第12章「レプリケーションの監視」を参照してください。

マスター・データベースは、サブスクライバ・データベースをstart、pauseまたはstopのいずれかの状態に設定できます。データベースの状態は、表11-1に示すとおり、TTREP.REPPEERS表のSTATE列に整数値として示されます。

表11-1 データベースの状態

状態

説明

start

STATE値: 0

レプリケーション更新が収集され、できるかぎり早くサブスクライバ・データベースに送信されます。サブスクライバ・データベースのレプリケーションが動作していない場合、更新は、送信可能になるまでトランザクション・ログ・ファイルに保存されます。

pause

STATE値: 1

レプリケーション更新は、送信を試行されずにログに保存されます。状態がstartに変更されると、送信が開始します。

stop

STATE値: 2

レプリケーション更新は、サブスクライバ・データベースに送信されずに破棄されます。サブスクライバ・データベースをstop状態にすると、マスターのトランザクション・ログに保留されている更新がすべて破棄されます。

警告: このサブスクライバの再起動を計画している場合、停止と再起動の間、更新は格納されません。このため、サブスクライバを再起動すると、サブスクライバには、マスターからの更新はすべて含まれません。再起動を計画している場合、サブスクライバを停止するかわりに、一時停止します。

failed

STATE値: 4

しきい値(ログ・データ)を超えているため、サブスクライバへのレプリケーションは失敗したとみなされます。この状態は、システムによって設定され、システムが状態をstopに設定する前の遷移状態です。failed状態のデータベースに接続するアプリケーションは警告を受信します。詳細は、「一般的なフェイルオーバーおよびリカバリの手順」を参照してください。

マスター・データベースがそのサブスクライバの1つをstart状態に設定すると、そのサブスクライバに対する更新がマスターのログに保存されます。サブスクライバがstop状態の場合、サブスクライバに対する更新は破棄されます。

サブスクライバがpause状態の場合、サブスクライバに対する更新はマスターのログに保存されますが、サブスクライバ・データベースには送信されません。マスターがサブスクライバをpauseからstartに変更すると、マスターのログに保存された更新のバックログがサブスクライバに送信されます。(これには例外があります。第15章「データベースのフェイルオーバーおよびリカバリの管理」を参照してください。)マスター・データベースは、状態が示されたサブスクライバに接続を確立できない場合、成功するまで接続の確立を定期的に試行します。

例11-4 ttRepAdminを使用したサブスクライバの状態の設定

コマンドラインからttRepAdminを使用して、subscriberdsサブスクライバ・データベースの状態をstopに設定するようにmasterdsマスター・データベースに指示するには、次のように入力します。

ttRepAdmin -dsn masterds -receiver -name subscriberds -state stop

注意:
異なるホストに同じ名前のサブスクライバが複数ある場合は、ttRepAdminユーティリティの-hostオプションで変更対象のサブスクライバのホストを識別します。

例11-5 ttRepSubscriberStateSetを使用したサブスクライバの状態の設定

マスター・データベースで、ttRepSubscriberStateSet組込みプロシージャをコールして、repschemeレプリケーション・スキームのサブスクライバ・データベース(subscriberds ON system1)の状態をstopに設定します。

Command> CALL ttRepSubscriberStateSet('repscheme', 'repl',
'subscriberds', 'system1', 2);

マスターのすべてのサブスクライバを特定の状態に設定する場合は、ttRepSubscriberStateSetのみを使用できます。ttRepAdminユーティリティに同等の機能はありません。

12 レプリケーションの監視

この章では、データベースのレプリケーション状態の監視に使用できるTimesTenユーティリティおよび組込みプロシージャの一部について説明します。

レプリケーションは、コマンドラインおよびプログラムの両方から監視できます。この章で説明するttStatusおよびttRepAdminユーティリティは、コマンドラインでの問合せに有効です。レプリケーションをプログラムによって監視するには、TimesTen組込みプロシージャ(『Oracle TimesTen In-Memory Databaseリファレンス』を参照)を使用するか、または独自のSQL SELECT文を作成してレプリケーション表(『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』を参照)を問い合せます。

注意:
TimesTen SYSおよびTTREP表には問合せのためにのみアクセスできます。これらの表の内容を変更しようとしないでください。

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

- レプリケーション・エージェントの状態の表示

- マスター・データベース情報の表示

- サブスクライバ・データベース情報の表示

- レプリケート・データベースの構成の表示

- レプリケート・ログ・レコードの表示

- ttRepAdminを使用したレプリケーション・ステータスの表示

- RETURNサービス・トランザクションのステータスの確認

- レプリケーション・ログの未処理トランザクションの分析

レプリケーション・エージェントの状態の表示

レプリケーション・エージェントの現在の状態についての情報を表示できます。

- ttStatusを使用したレプリケーション・エージェントのステータスの取得

- ttAdmin -queryを使用したポリシー設定の確認

- ttDataStoreStatusを使用したレプリケーション・エージェントのステータスの取得

また、特定のレプリケーション・データベースの状態も取得できます(「サブスクライバ・データベース情報の表示」および「レプリケーション・データベースの構成の表示」を参照)。

ttStatusを使用したレプリケーション・エージェントのステータスの取得

マスター・データベースのレプリケーション・エージェントが起動されていることを確認するには、ttStatusユーティリティを使用します。

例12-1 ttStatusを使用したレプリケーション・エージェントのステータスの取得

> ttStatus
TimesTen status report as of Thu Aug 11 17:05:23 2011
Daemon pid 18373 port 4134 instance ttuser
TimesTen server pid 18381 started on port 4136
------------------------------------------------------------------------
Data store /tmp/masterds
There are 16 connections to the data store
Shared Memory KEY 0x0201ab43 ID 5242889
PL/SQL Memory KEY 0x0301ab43 ID 5275658 Address 0x10000000
Type            PID     Context     Connection Name              ConnID
Process         20564   0x081338c0  masterds                          1
Replication     20676   0x08996738  LOGFORCE                          5
Replication     20676   0x089b69a0  REPHOLD                           2
Replication     20676   0x08a11a58  FAILOVER                          3
Replication     20676   0x08a7cd70  REPLISTENER                       4
Replication     20676   0x08ad7e28  TRANSMITTER                       6
Subdaemon       18379   0x080a11f0  Manager                        2032
Subdaemon       18379   0x080fe258  Rollback                       2033
Subdaemon       18379   0x081cb818  Checkpoint                     2036
Subdaemon       18379   0x081e6940  Log Marker                     2035
Subdaemon       18379   0x08261e70  Deadlock Detector              2038
Subdaemon       18379   0xae100470  AsyncMV                        2040
Subdaemon       18379   0xae11b508  HistGC                         2041
Subdaemon       18379   0xae300470  Aging                          2039
Subdaemon       18379   0xae500470  Flusher                        2034
Subdaemon       18379   0xae55b738  Monitor                        2037
Replication policy  : Manual
Replication agent is running.
Cache Agent policy  : Manual
PL/SQL enabled.

ttAdmin -queryを使用したポリシー設定の確認

データベースに対するポリシー設定(「レプリケーション・エージェントの起動および停止」で説明されているレプリケーション再起動ポリシーを含む)を確認するには、-queryオプションを指定してttAdminユーティリティを使用します。

例12-2 ttAdminを使用したポリシー設定の確認

> ttAdmin -query masterDSN
RAM Residence Policy : inUse
Manually Loaded In Ram : False
Replication Agent Policy : manual
Replication Manually Started : True
Cache Agent Policy : manual
Cache Agent Manually Started : False

ttDataStoreStatusを使用したレプリケーション・エージェントのステータスの取得

レプリケーション・エージェントの状態をプログラムから取得するには、ttDataStoreStatus組込みプロシージャを使用します。

例12-3 ttDataStoreStatusのコール

masterdsデータベースのレプリケーション・エージェントの状態を取得するには、ttDataStoreStatus組込みプロシージャをコールします。

> ttIsql masterds
Command> CALL ttDataStoreStatus('/tmp/masterds');
< /tmp/masterds, 964, 00000000005D8150, subdaemon, Global\DBI3b3234c0.0.SHM.35 >
< /tmp/masterds, 1712, 00000000016A72E0, replication, Global\DBI3b3234c0.0.SHM.35 >
< /tmp/masterds, 1712, 0000000001683DE8, replication, Global\DBI3b3234c0.0.SHM.35 >
< /tmp/masterds, 1620, 0000000000608128, application, Global\DBI3b3234c0.0.SHM.35 >
4 rows found.

ttDataStoreStatusの出力は、「ttStatusを使用したレプリケーション・エージェントのステータスの取得」のttStatusユーティリティの出力に類似しています。

マスター・データベース情報の表示

マスター・データベースに関する情報を表示できます。

- ttRepAdminを使用したマスター・データベースに関する情報の表示

- レプリケーション表の問合せによるマスター・データベースに関する情報の取得

ttRepAdminを使用したマスター・データベースに関する情報の表示

マスター・データベースに関する情報を表示するには、-self -listオプションを指定してttRepAdminユーティリティを使用します。

ttRepAdmin -dsn masterDSN -self -list

例12-4 ttRepAdminを使用したマスター・データベースに関する情報の表示

この例では、「RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム」で説明されているマスター・データベースの出力を示します。

> ttRepAdmin -dsn masterds -self -list
Self host "server1", port auto, name "masterds", LSN 0/2114272

次の表に、フィールドの説明を示します。

フィールド

説明

host

データベースのホストの名前。

port

このデータベースからの更新を受信する別のデータベースのレプリケーション・エージェントで使用されるTCP/IPポート。値が0(ゼロ)の場合は、レプリケーションでポートが自動的に割り当てられたことを示します。

name

データベースの名前。

Log file / Replication hold LSN

サブスクライバに送信するために保持されているトランザクション・ログ内の最も古い場所を示します。値が-1/-1の場合は、レプリケーションがすべてのサブスクライバに対してstop状態であることを示します。

レプリケーション表の問合せによるマスター・データベースに関する情報の取得

マスター・データベースに関する情報を取得するには、次のSELECT文を使用して、TTREP.TTSTORESおよびTTREP.REPSTORESレプリケーション表を問い合せます。

SELECT t.host_name, t.rep_port_number, t.tt_store_name
FROM ttrep.ttstores t, ttrep.repstores s
WHERE t.is_local_store = 0x01
AND t.tt_store_id = s.tt_store_id;

次に、マスター・データベースに対するSELECT文(「RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム」を参照)の結果を示します。フィールドは、ホスト名、レプリケーション・ポート番号およびデータベース名です。

< server1, 0, masterds>

サブスクライバ・データベース情報の表示

レプリケーションはTimesTenトランザクション・ログを使用して、サブスクライバ・サイトに送信する必要がある情報を保持します。サブスクライバ・データベースとの通信が中断された場合、またはサブスクライバ・サイトが停止した場合、トランザクション・ログ・データが累積します。この項で説明する問合せの出力の一部から、各サブスクライバ・データベースのために累積されたトランザクション・ログ・データの量、各サブスクライバ・データベースとの通信に最後に成功してから経過した時間を確認できます。

次の方法を使用して、サブスクライバ・データベースに関する情報を表示します。

- ttRepAdminユーティリティによるサブスクライバ・ステータスの表示

- ttReplicationStatus組込みプロシージャによるサブスクライバ・ステータスの表示

- レプリケーション表の問合せによるサブスクライバに関する情報の表示

ttRepAdminユーティリティによるサブスクライバ・ステータスの表示

サブスクライバに関する情報を表示するには、-receiver -listオプションを指定してttRepAdminユーティリティを使用します。

ttRepAdmin -dsn masterDSN -receiver -list

例12-5 ttRepAdminを使用したサブスクライバに関する情報の表示

この例では、「RETURNサービスとログ障害しきい値を使用する複数サブスクライバ・クラシック・レプリケーション・スキーム」で説明されているサブスクライバの出力を示します。

> ttRepAdmin -dsn masterds -receiver -list
Peer name        Host name                Port   State   Proto
---------------- ------------------------ ------ ------- -----
subscriber1ds    server2                  Auto   Start      10

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
0:01:12       -             19.41 5       5        52    2

Peer name        Host name                Port   State   Proto
---------------- ------------------------ ------ ------- -----
subscriber2ds    server3                  Auto   Start      10

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
0:01:04       -             20.94         4        48    2

最初の行には、サブスクライバの定義が表示されます。その次の行には、このサブスクライバのために保持されているトランザクション・ログ・ファイルの数とともに、待機時間および速度の情報が表示されます。subscriber1dsの待機時間は19.41秒で、マスターよりログ2つ分遅れています。この待機時間は高い値で、待機時間の値が高いままでログの数が増え続ける場合、問題が発生していることを示します。

注意:
表示されるサブスクライバ情報の詳細は、「サブスクライバ情報」を参照してください。

TTREP.REPLICATIONS表に指定したスキームが複数ある場合は、-schemeオプションを使用して、リストするスキームを指定する必要があります。そうしない場合、次のエラーを受信します。

Must specify -scheme to identify which replication scheme to use

詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttRepAdmin」を参照してください。

ttReplicationStatus組込みプロシージャによるサブスクライバ・ステータスの表示

ttIsql内でttReplicationStatus組込みプロシージャを使用することにより、1つ以上のサブスクライバ・データベースのステータスを表示できます(レポートされるのは、この組込みプロシージャがコールされたマスター・データベースのサブスクライバのステータスのみです)。

例12-6 このマスターの単一サブスクライバに関するステータスの表示

次の例は、host1に配置されているサブスクライバmaster2のステータスを取得します。ホスト名が除外されている場合、サブスクライバは、その名前のホストのみに配置されています。

Command> call ttReplicationStatus('master2', 'host1');
< MASTER2, HOST1, 0, start, 1, 26, _ACTIVESTANDBY , TTREP >
1 row found.

表示される情報は、host1に配置されており、自動的に割り当てられたポートでリスニングしているサブスクライバmaster2に関するステータスです。TCP/IPポートは、マスターからの更新を受信するサブスクライバ・エージェントで使用されます。ただし、値が0 (ゼロ)の場合は、レプリケーションでポートが自動的に割り当てられたことを示します。

このサブスクライバは、起動状態です。このピアに対しては1つのトランザクション・ログのみが保持されており、最後のレプリケーションから26秒が経過しています。レプリケーション・スキームの名前は_ACTIVESTANDBY、所有者はTTREPです。

例12-7 このマスターのすべてのサブスクライバに関するステータスの表示

サブスクライバまたはサブスクライバのホスト名のいずれも提供しない場合、このマスターのすべてのサブスクライバに関するステータスが返されます。次の例では、このマスターに対してサブスクライバが1つのみ設定されているので、前述と同じステータスが示されます。

Command> call ttReplicationStatus();
< MASTER2, HOST1, 0, start, 1, 26, _ACTIVESTANDBY , TTREP >
1 row found.

詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttReplicationStatusに関する説明を参照してください。

レプリケーション表の問合せによるサブスクライバに関する情報の表示

次のSELECT文を使用してTTREP.REPPEERS表、TTREP.TTSTORES表およびSYS.MONITOR表を問い合せることにより、マスターのサブスクライバに関する同じ情報をプログラムから取得できます。

SELECT t1.tt_store_name, t1.host_name, t1.rep_port_number,
p.state, p.protocol, p.timesend, p.timerecv, p.latency,
p.tps, p.recspersec, t3.last_log_file - p.sendlsnhigh + 1
FROM ttrep.reppeers p, ttrep.ttstores t1, ttrep.ttstores t2, sys.monitor t3
WHERE p.tt_store_id = t1.tt_store_id
AND t2.is_local_store = 0X01
AND p.subscriber_id = t2.tt_store_id
AND p.replication_name = 'repscheme'
AND p.replication_owner = 'repl'
AND (p.state = 0 OR p.state = 1);

次に、前述の3つの文の出力例を示します。

< subscriber1ds, server2, 0, 0, 7, 1003941635, 0, -1.00000000000000, -1, -1, 1 >
< subscriber2ds, server3, 0, 0, 7, 1003941635, 0, -1.00000000000000, -1, -1, 1 >

表示されるサブスクライバ情報の詳細は、「サブスクライバ情報」を参照してください。

サブスクライバ情報

ttRepAdminユーティリティまたはSELECT文の出力には、次のフィールドが含まれます。

フィールド

説明

Peer name

サブスクライバ・データベースの名前

Host name

サブスクライバをホスティングするマシンの名前

Port

マスターからの更新を受信するサブスクライバ・エージェントで使用されるTCP/IPポート。値が0(ゼロ)の場合は、レプリケーションでポートが自動的に割り当てられたことを示します。

State

マスター・データベースに対するサブスクライバの現在のレプリケーション状態(詳細は、「サブスクライバ・データベース情報の表示」を参照)。

Protocol

このマスターとマスターに対応するサブスクライバ間で通信するレプリケーションで使用される内部プロトコル。この値は無視できます。

Last message sent

マスターがサブスクライバに最後にメッセージを送信してから経過した時間(秒)。このようなメッセージには、データベース間で送信されたハートビート・メッセージが含まれます。

Last message received

このサブスクライバがマスターから最後のメッセージを受信してから経過した時間(秒)。

Latency

マスターがメッセージを送信してからサブスクライバから最後の確認応答を受信するまでの平均待機時間(秒)。(「注意」を参照。)

Transactions per second

マスターでコミットされ、サブスクライバで処理される、1秒当たりの平均トランザクション数。(「注意」を参照。)

Records per second

1秒当たりに送信される平均レコード数。(「注意」を参照。)

Logs

マスター・データベースがサブスクライバのために保持しているトランザクション・ログ・ファイルの数。

注意:
Latency、TPSおよびRecordsPSは、レコードのバッチのレプリケート中に検出された平均値をレポートします。これらの値は、ワークロードが比較的一定でない場合、不安定になる可能性があります。値が-1の場合は、マスターのレプリケーション・エージェントがそのサブスクライバ・レプリケーション・エージェントとの通信を確立していないか、またはデータをサブスクライバ・レプリケーション・エージェントに送信していないことを示します。

レプリケート・データベースの構成の表示

レプリケート・データベースの構成を表示できます。

- ttIsql repschemesコマンドによる構成情報の表示

- ttRepAdminユーティリティによる構成情報の表示

- レプリケーション表の問合せによる構成情報の表示

ttIsql repschemesコマンドによる構成情報の表示

レプリケート・データベースの構成をttIsqlプロンプトから表示するには、repschemesコマンドを使用します。

Command> repschemes;

例12-8に、「伝播スキーム」で説明されているレプリケーション・スキームからの構成出力を示します。

例12-8 ttIsql repschemesコマンドからの出力

Replication Scheme PROPAGATOR:

Element: A
Type: Table TAB
Master Store: CENTRALDS on FINANCE Transmit Durable
Subscriber Store: PROPDS on NETHANDLER

Element: B
Type: Table TAB
Propagator Store: PROPDS on NETHANDLER Transmit Durable
Subscriber Store: BACKUP1DS on BACKUPSYSTEM1
Subscriber Store: BACKUP2DS on BACKUPSYSTEM2

Store: BACKUP1DS on BACKUPSYSTEM1
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled

Store: BACKUP2DS on BACKUPSYSTEM2
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled

Store: CENTRALDS on FINANCE
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled

Store: PROPDS on NETHANDLER
Port: (auto)
Log Fail Threshold: (none)
Retry Timeout: 120 seconds
Compress Traffic: Disabled

ttRepAdminユーティリティによる構成情報の表示

レプリケート・データベースの構成を表示するには、-showconfigオプションを指定してttRepAdminユーティリティを使用します。

ttRepAdmin -showconfig -dsn masterDSN

例12-9に、「伝播スキーム」で説明されているレプリケーション・スキームによって構成された伝播済データベースからの構成出力を示します。propdsプロパゲータの待機時間は19.41秒で、マスターよりログ2つ分遅れています。

例12-9 ttRepAdmin出力

> ttRepAdmin -showconfig -dsn centralds
Self host "finance", port auto, name "centralds", LSN 0/155656, timeout 120,
threshold 0

List of subscribers
-----------------
Peer name        Host name                Port   State   Proto
---------------- ------------------------ ------ ------- -----
propds           nethandler               Auto   Start      10

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
0:01:12       -             19.41         5        52    2

List of tables and subscriptions
--------------------------------
Table details
-------------
Table : tab          Timestamp updates : -

Master Name                 Subscriber Name
-----------                 -------------
centralds                   propds

Table details
-------------
Table : tab          Timestamp updates : -

Master Name                 Subscriber name
-----------                 -------------
propds                      backup1ds
propds                      backup2ds

「List of subscribers」フィールドの意味は、「レプリケーション表の問合せによるサブスクライバに関する情報の表示」を参照してください。Table detailsフィールドには、表およびそのマスター(送信者)とサブスクライバのデータベースの名前が表示されます。

レプリケーション表の問合せによる構成情報の表示

構成情報を表示するには、次のSELECT文を使用して、TTREP.TTSTORES、TTREP.REPSTORES、TTREP.REPPEERS、SYS.MONITOR、TTREP.REPELEMENTSおよびTTREP.REPSUBSCRIPTIONS表を問い合せます。

SELECT t.host_name, t.rep_port_number, t.tt_store_name, s.peer_timeout,
s.fail_threshold
FROM ttrep.ttstores t, ttrep.repstores s
WHERE t.is_local_store = 0X01
AND t.tt_store_id = s.tt_store_id;

SELECT t1.tt_store_name, t1.host_name, t1.rep_port_number,
p.state, p.protocol, p.timesend, p.timerecv, p.latency,
p.tps, p.recspersec, t3.last_log_file - p.sendlsnhigh + 1
FROM ttrep.reppeers p, ttrep.ttstores t1, ttrep.ttstores t2, sys.monitor t3
WHERE p.tt_store_id = t2.tt_store_id
AND t2.is_local_store = 0X01
AND p.subscriber_id = t1.tt_store_id
AND (p.state = 0 OR p.states = 1);

SELECT ds_obj_owner, DS_OBJ_NAME, t1.tt_store_name,t2.tt_store_name
FROM ttrep.repelements e, ttrep.repsubscriptions s,
ttrep.ttstores t1, ttrep.ttstores t2
WHERE s.element_name = e.element_name
AND e.master_id = t1.tt_store_id
AND s.subscriber_id = t2.tt_store_id
ORDER BY ds_obj_owner, ds_obj_name;

例12-10 問合せの出力

問合せの出力例は、「伝播スキーム」で説明されているレプリケーション・スキームによって構成されたデータベースに対するものです。

最初の問合せの出力は次のようになります。

< finance, 0, centralds, 120, 0 >

これには、ホスト名、ポート番号およびデータベース名が表示されます。4番目の値(120)は、データベースがメッセージを送信する前に別のデータベースからのレスポンスを待機する時間を定義するTIMEOUT値です。最後の値(0)は、ログ障害しきい値(「トランザクション・ログ障害しきい値の設定」を参照)です。

2番目の問合せの出力は次のようになります。

< propds, nethandler, 0, 0, 7, 1004378953, 0, -1.00000000000000, -1, -1, 1 >

フィールドの説明は、「レプリケーション表の問合せによるサブスクライバに関する情報の表示」を参照してください。

最後の問合せの出力は次のようになります。

< repl, tab, centralds, propds >
< repl, tab, propds, backup1ds >
< repl, tab, propds, backup2ds >

これらの行には、レプリケート表およびそのマスター(送信者)とサブスクライバ(受信者)のデータベースの名前が表示されます。

レプリケート・ログ・レコードの表示

レプリケート・データベースでは、トランザクションがサブスクライバで完全に処理されたことをマスター・レプリケーション・エージェントが確認するまで、トランザクションはトランザクション・ログ・バッファおよびトランザクション・ログ・ファイルに保持されます。サブスクライバが含まれるアクティブ・スタンバイ・ペアのレプリケーション・スキームでは、トランザクションがスタンバイ・マスターとすべてのサブスクライバの両方で処理されたとアクティブ・マスターにより確認されるまで、トランザクションはトランザクション・ログに残ります。アクティブ・マスターは、これを確認した時点でのみ、ログ・バッファおよびトランザクション・ログ・ファイルからのパージが必要であると認識します。ログ領域を使い果たすと、マスター・データベースでの後続の更新が強制終了されます。

注意:
トランザクション・ログの増大の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの蓄積の監視に関する説明を参照してください。

トランザクションは、ログ・レコードの形式でログに保存されます。ブックマークを使用して、マスター・データベースがレプリケートしたログ・レコードまたはレプリケートしていないログ・レコードを検出できます。ブックマークは、ログ順序番号(LSN)で構成されており、この番号は、レプリケーションのパフォーマンスを測定するために使用可能なトランザクション・ログ内の特定のレコードの位置を識別できます。ブックマークに関連付けられているLSNは、hold LSN、last written LSNおよびlast LSN forced to diskです。hold LSNは、サブスクライバに送信できるようにログ内に保持されている最下位(最も古い)レコードの場所を示します。hold LSNとlast written LSNを比較することによって、サブスクライバに送信されていないトランザクション・ログ内のデータの量を確認できます。last LSN forced to diskは、ディスク上のトランザクション・ログ・ファイルに保存された最後のレコードを示します。

ユーザーは次のツールを使って、ブックマークとログの順序番号でレプリケーションを監視できます。

- TTREP.REPPEERS表を使ったレプリケーションの監視

- ttLogHolds組込みプロシージャを使ったレプリケーションの監視

- ttRepAdminユーティリティを使ったレプリケーションの監視

- ttBookMark組込みプロシージャを使ったレプリケーションの監視

TTREP.REPPEERS表を使ったレプリケーションの監視

特定のサブスクライバへのレプリケーションを正確に監視する方法として、サブスクライバのsend LSNを監視するという方法があり、send LSNは、TTREP.REPPEERS表のSENDLSNHIGHおよびSENDLSNLOWフィールドで構成されています。send LSN値とは対照的に、ブックマーク内に返されるhold LSNは、すべてのサブスクライバの最小のsend LSNを示すために10秒ごとに計算されるため、hold LSNは、レプリケーションの進行状況の概要を示し、個々のサブスクライバへのレプリケーションの進行状況は明示されません。レプリケーションの確認応答はパフォーマンスを向上させるために非同期であるため、send LSNは少し遅れる可能性もあります。ただし、サブスクライバのsend LSNは、使用できる最も正確な値であり、常にhold LSNに先行しています。

ttLogHolds組込みプロシージャを使ったレプリケーションの監視

ttLogHolds組込みプロシージャを使用して、レプリケーション・ログに関する情報を保持します。

次の例は、アクティブ・スタンバイ・ペアのレプリケーション・スキームに対するttLogHolds組込みプロシージャの出力を示しています(アクティブ・マスターはmaster1、スタンバイ・マスターはmaster2、単一のサブスクライバはsubscriber1)。すべてのトランザクションはまずアクティブ・マスターからスタンバイ・マスターにレプリケートされ、それからスタンバイ・マスターによりトランザクションがサブスクライバに伝播されます。したがって、サブスクライバの進捗状況はスタンバイ・マスターの進捗状況から少し遅れます。

アクティブ・マスターはスタンバイ・マスターとサブスクライバの進捗状況の両方を監視するので、スタンバイ・マスターがなんらかの理由で停止した場合は、サブスクライバへのレプリケーションをアクティブ・マスターが引き受けます。アクティブ・マスターは、トランザクションがサブスクライバに適用されると確認を受け取るので、アクティブ・マスターはスタンバイ・マスターに障害が発生した場合に必要となる可能性がある関連のログ・レコードをいつリリースできるかがわかります(スタンバイ・マスターに障害が発生すると、アクティブ・マスターが直接サブスクライバにレプリケートするように切り替えられます)。トランザクションはスタンバイ・マスターとサブスクライバの両方で処理されるまで、トランザクション・ログに残ります。

Command> call ttLogHolds;
< 0, 3569664, Checkpoint                    , master1.ds0 >
< 0, 15742976, Checkpoint                    , master1.ds1 >
< 0, 16351496, Replication                   , ADC6160529:SUBSCRIBER1 >
< 0, 16351640, Replication                   , ADC6160529:MASTER2 >
4 rows found.

AWTキャッシュ・グループを使用している場合は、レプリケーション・エージェントを使用してトランザクションをOracle Databaseに非同期で伝播します。ttLogHolds組込みプロシージャをコールすると、説明フィールドに「_ORACLE」と表示され、AWTキャッシュ・グループの伝播のためにトランザクション・ログが保留されていることが示されます。

Command> call ttLogHolds();
< 0, 18958336, Checkpoint                    , cachealone1.ds0 >
< 0, 19048448, Checkpoint                    , cachealone1.ds1 >
< 0, 19050904, Replication                   , ADC6160529:_ORACLE >
3 rows found.

ttLogHolds組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttLogHolds」を参照してください。

ttRepAdminユーティリティを使ったレプリケーションの監視

ブックマークの位置を表示するには、-bookmarkオプションを指定してttRepAdminユーティリティを使用します。

> ttRepAdmin -dsn masterds -bookmark
Replication hold LSN ...... 10/927692
Last written LSN .......... 10/928908
Last LSN forced to disk ... 10/280540
Each LSN is defined by two values:
Log file number / Offset in log file

ttRepAdmin -bookmarkのLSN出力は次のようになります。

行

説明

Replication hold LSN

サブスクライバに送信できるようにログ内に保持されている最下位(最も古い)レコードの場所。値が-1/-1の場合は、レプリケーションがすべてのサブスクライバに対してstop状態であること(または問い合されたデータベースがマスター・データベースではないこと)を示します。
1つ以上のサブスクライバを持つアクティブ・スタンバイ・ペアを監視している場合は、この値がレプリケーション・スキームに含まれるすべてのノードに対して保管されている、最も古いレコードを示します。たとえば、サブスクライバを持つアクティブ・スタンバイ・ペアでは、最も古いレコードがスタンバイ・マスターまたはいずれかのサブスクライバ用のログに保管される可能性があります。

Last written LSN

データベースに対して最後に生成されたトランザクション・ログ・レコードの場所。

Last LSN forced to disk

ディスクに最後に書き込まれたトランザクション・ログ・レコードの場所。

ttBookMark組込みプロシージャを使ったレプリケーションの監視

ブックマークの位置を表示するには、ttBookmark組込みプロシージャを使用します。

例12-11 ttBookmarkを使用したブックマーク位置の表示

> ttIsql masterds

Command> call ttBookMark();
< 10, 928908, 10, 280540, 10, 927692 >
1 row found.

返された行内の最初の2列で、Last written LSNが、次の2列でLast LSN forced to diskが、最後の2列でReplication hold LSNが定義されます。

1つ以上のサブスクライバを持つアクティブ・スタンバイ・ペアを監視している場合は、「Replication hold LSN」がレプリケーション・スキームに含まれるすべてのノードに対して保管されている、最も古いレコードを示します。たとえば、サブスクライバを持つアクティブ・スタンバイ・ペアでは、最も古いレコードがスタンバイ・マスターまたはいずれかのサブスクライバ用のログに保管される可能性があります。

ttRepAdminを使用したレプリケーション・ステータスの表示

-showstatusオプションを指定してttRepAdminユーティリティを使用すると、レプリケーション・エージェントの現在のステータスを表示できます。ステータス出力には、問い合されたデータベースのレプリケーション・エージェントで使用されるブックマークの位置、ポート番号および通信プロトコルが含まれます。

ttRepAdmin -showstatusの出力には、レプリケーション・エージェントで使用されるメイン・スレッド、TRANSMITTERスレッドおよびRECEIVERスレッドのステータスが含まれます。マスター・データベースにはTRANSMITTERスレッド、サブスクライバ・データベースにはRECEIVERスレッドがあります。双方向レプリケーション・スキームでマスター/サブスクライバとしての機能するデータベースには、TRANSMITTERスレッドおよびRECEIVERスレッドの両方があります。

各レプリケーション・エージェントには、ポートでピア接続をリスニングする単一のREPLISTENERスレッドがあります。マスター・データベースでは、REPLISTENERスレッドがサブスクライバ・データベースごとに個別のTRANSMITTERスレッドを開始します。サブスクライバ・データベースでは、REPLISTENERスレッドがマスターからの接続のたびに個別のRECEIVERスレッドを開始します。

TimesTenデーモンがレプリケーション・エージェントの停止を要求した場合、またはレプリケーション・エージェントで使用されている他のいずれかのスレッドで致命的なエラーが発生した場合、メイン・スレッドは他のすべてのスレッドが正常に終了するまで待機します。TimesTenデーモンは、致命的なエラーの種類に応じて、レプリケーション・エージェントを再起動する場合もしない場合もあります。REPLISTENERスレッドは、レプリケーション・エージェントの存続期間中には終了しません。TRANSMITTERまたはRECEIVERスレッドは停止する場合がありますが、レプリケーション・エージェントによって再起動されます。RECEIVERスレッドは、リカバリ不可能なエラーが発生した場合、またはマスターが接続を切断した場合に終了します。

例12-11に、rep1データベースがマスターで、rep2データベースがサブスクライバである単方向レプリケーション・スキームのttRepAdmin -showstatus出力を示します。最初のttRepAdmin -showstatus出力は、rep1データベースおよびそのTRANSMITTERスレッドのステータスを示します。2つ目の出力はrep2データベースおよびそのRECEIVERスレッドのステータスを示します。

例の後の項では、ttRepAdmin -showstatus出力の各フィールドの意味について説明します。

- MAINスレッド・ステータス・フィールド

- レプリケーション・ピア・ステータス・フィールド

- TRANSMITTERスレッド・ステータス・フィールド

- RECEIVERスレッド・ステータス・フィールド

例12-12 単方向レプリケーション・スキーム

rep1データベースからrep2データベースへの単方向レプリケーション・スキームについて考えてみます。

CREATE REPLICATION r
ELEMENT e1 TABLE t
MASTER rep1
SUBSCRIBER rep2;

rep1データベースのレプリケーション・ステータスは、次のようになります。

> ttRepAdmin -showstatus rep1

DSN                      : rep1
Process ID               : 1980
Replication Agent Policy : MANUAL
Host                     : MYHOST
RepListener Port         : 1113 (AUTO)
Last write LSN           : 0.1487928
Last LSN forced to disk  : 0.1487928
Replication hold LSN     : 0.1486640

Replication Peers:
Name                   : rep2
Host                   : MYHOST
Port                   : 1154 (AUTO)
Replication State      : STARTED
Communication Protocol : 12

TRANSMITTER thread(s):
For                     : rep2
Start/Restart count   : 2
Send LSN              : 0.1485960
Transactions sent     : 3
Total packets sent    : 10
Tick packets sent     : 3
MIN sent packet size  : 48
MAX sent packet size  : 460
AVG sent packet size  : 167
Last packet sent at   : 17:41:05
Total Packets received: 9
MIN rcvd packet size  : 48
MAX rcvd packet size  : 68
AVG rcvd packet size  : 59
Last packet rcvd'd at : 17:41:05
Earlier errors (max 5):
TT16060 in transmitter.c (line 3590) at 17:40:41 on 08-25-2004
TT16122 in transmitter.c (line 2424) at 17:40:41 on 08-25-2004

Replication hold LSN、Last write LSNおよびLast LSN forced to diskが非常に近いため、レプリケーションは適切に実行されていることがわかります。Replication hold LSNがLast write LSNおよびLast LSNより遅れる場合、レプリケーションはマスターの更新に追い付いていません。

rep2データベースのレプリケーション・ステータスは、次のようになります。

> ttRepAdmin -showstatus rep2

DSN                      : rep2
Process ID               : 2192
Replication Agent Policy : MANUAL
Host                     : MYHOST
RepListener Port         : 1154 (AUTO)
Last write LSN           : 0.416464
Last LSN forced to disk  : 0.416464
Replication hold LSN     : -1.-1

Replication Peers:
Name              : rep1
Host              : MYHOST
Port              : 0 (AUTO)
Replication State : STARTED
Communication Protocol : 12

RECEIVER thread(s):
For                   : rep1
Start/Restart count   : 1
Transactions received : 0
Total packets sent    : 20
Tick packets sent     : 0
MIN sent packet size  : 48
MAX sent packet size  : 68
AVG sent packet size  : 66
Last packet sent at   : 17:49:51
Total Packets received: 20
MIN rcvd packet size  : 48
MAX rcvd packet size  : 125
AVG rcvd packet size  : 52
Last packet rcvd'd at : 17:49:51

MAINスレッド・ステータス・フィールド

次のフィールドは、問い合されたデータベースのレプリケーション・エージェント内のMAINスレッドの出力です。

MAINスレッド

説明

DSN

問合せ対象のデータベースの名前。

Process ID

レプリケーション・エージェントのプロセスID。

Replication Agent Policy

再起動ポリシー(「レプリケーション・エージェントの起動および停止」を参照)。

Host

このデータベースをホスティングするマシンの名前。

RepListener Port

レプリケーション・エージェントがリモート・レプリケーション・エージェントのTRANSMITTERスレッドからの接続をリスニングするために使用するTCP/IPポート。値が0(ゼロ)の場合は、このポートがレプリケーション・スキームの一部として指定されているのでなく、レプリケーション・エージェントに自動的に割り当てられている(デフォルト)ことを示します。

Last write LSN

データベースに対して最後に生成されたトランザクション・ログ・レコードの場所。詳細は、「レプリケート・ログ・レコードの表示」を参照してください。

Last LSN forced to disk

ディスクに最後に書き込まれたトランザクション・ログ・レコードの場所。詳細は、「レプリケート・ログ・レコードの表示」を参照してください。

Replication hold LSN

サブスクライバに送信できるようにログ内に保持されている最下位(最も古い)レコードの場所。値が-1/-1の場合は、レプリケーションがすべてのサブスクライバに対してstop状態であることを示します。詳細は、「レプリケート・ログ・レコードの表示」を参照してください。

レプリケーション・ピア・ステータス・フィールド

次のフィールドは、問い合されたデータベースのレプリケーション・スキームに関連している各レプリケーション・ピアの出力です。ピアは、マスター、サブスクライバ、プロパゲータ、または双方向レプリケーション・スキームではマスターとサブスクライバの両方の役割を果たすことができます。

レプリケーション・ピア

説明

Name

このデータベースのレプリケーション・ピアであるデータベースの名前。

Host

ピア・データベースのホスト。

Port

ピア・データベースのレプリケーション・エージェントが使用するTCP/IPポート。値が0(ゼロ)の場合は、このポートがレプリケーション・スキームの一部として指定されているのでなく、レプリケーション・エージェントに自動的に割り当てられている(デフォルト)ことを示します。

Replication State

問い合されたデータベースに対するレプリケーション・ピアの現在のレプリケーション状態(詳細は、「サブスクライバ・データベース情報の表示」を参照)。

Communication Protocol

レプリケーションがピア間で通信を行うために使用する内部プロトコル。(内部使用専用。)

TRANSMITTERスレッド・ステータス・フィールド

次のフィールドは、マスター・レプリケーション・エージェントがトランザクション更新をサブスクライバに送信するために使用する各TRANSMITTERスレッドの出力です。対応する複数のサブスクライバがあるマスターは、複数のTRANSMITTERスレッドを持つことになります。

注意:
TRANSMITTER出力のカウントは、レプリケーション・エージェントを起動すると、累積し始めます。これらのカウントは、レプリケーション・エージェントを起動または再起動した場合にのみ0(ゼロ)にリセットされます。

TRANSMITTERスレッド

説明

For

レプリケート・データをこのデータベースから受信するサブスクライバ・データベースの名前。

Start/Restart count

処理のタイムアウトやネットワーク障害などの一時エラーが発生したため、レプリケーション・エージェントによってこのTRANSMITTERスレッドが起動または再起動された回数。

Send LSN

このピアに最後に送信されたLSN。詳細は、「レプリケート・ログ・レコードの表示」を参照してください。

Transactions sent

サブスクライバに送信されたトランザクションの合計数。

Total packets sent

サブスクライバに送信されたパケットの合計数(ティック・パケットを含む)。

Tick packets sent

送信されたティック・パケットの合計数。ティック・パケットは、マスターとサブスクライバの間のハートビートを維持するために使用されます。この値を使用すると、レプリケート・データと関連していない「Total packets sent」パケットの数を確認できます。

MIN sent packet size

サブスクライバに送信された最小パケットのサイズ。

MAX sent packet size

サブスクライバに送信された最大パケットのサイズ。

AVG sent packet size

サブスクライバに送信されたパケットの平均サイズ。

Last packet sent at

パケットが最後に送信された時刻(24時間制の時刻)。

Total packets received

サブスクライバから受信したパケットの合計数(ティック・パケットおよび確認応答データ)。

MIN rcvd packet size

受信した最小パケットのサイズ。

MAX rcvd packet size

受信した最大パケットのサイズ。

AVG rcvd packet size

受信したパケットの平均サイズ。

Last packet rcvd at

パケットを最後に受信した時刻(24時間制の時刻)。

Earlier errors (max 5)

このスレッドによって最後に生成された5つのエラー。

RECEIVERスレッド・ステータス・フィールド

次のフィールドは、サブスクライバ・レプリケーション・エージェントがマスターからトランザクション更新を受信するために使用する各RECEIVERスレッドの出力です。複数のマスターによって更新されるサブスクライバは、複数のRECEIVERスレッドを持つことになります。

注意:
RECEIVER出力のカウントは、レプリケーション・エージェントを起動すると、累積し始めます。これらのカウントは、レプリケーション・エージェントを起動または再起動した場合にのみ0(ゼロ)にリセットされます。

RECEIVERスレッド

説明

For

レプリケート・データをこのデータベースから送信するマスター・データベースの名前。

Start/Restart count

処理のタイムアウトやネットワーク障害などの一時エラーが発生したため、レプリケーション・エージェントによってこのRECEIVERスレッドが起動または再起動された回数。

Transactions received

マスターから受信したトランザクションの合計数。

Total packets sent

マスターに送信されたパケットの合計数(ティック・パケットおよび確認応答データ)。

Tick packets sent

マスターに送信されたティック・パケットの合計数。ティック・パケットは、マスターとサブスクライバの間のハートビートを維持するために使用されます。この値を使用すると、確認応答データと関連していない「Total packets sent」パケットの数を確認できます。

MIN sent packet size

マスターに送信された最小パケットのサイズ。

MAX sent packet size

マスターに送信された最大パケットのサイズ。

AVG sent packet size

マスターに送信されたパケットの平均サイズ。

Last packet sent at

パケットがマスターに最後に送信された時刻(24時間制の時刻)。

Total packets received

マスターから受信した確認応答データのパケットの合計数。

MIN rcvd packet size

受信した最小パケットのサイズ。

MAX rcvd packet size

受信した最大パケットのサイズ。

AVG rcvd packet size

受信したパケットの平均サイズ。

Last packet rcvd at

パケットを最後に受信した時刻(24時間制の時刻)。

RETURNサービス・トランザクションのステータスの確認

次の項では、RETURNサービスのステータスを確認する方法および最後に返されたステータスを確認する方法を説明します。

- RETURNサービスが無効にされているかどうかの確認

- RETURNサービスの最後に返されたステータスの確認

RETURNサービスが無効にされているかどうかの確認

特定のサブスクライバに対するRETURNサービスがDISABLE RETURN障害ポリシーによって無効にされているかどうかを確認するには、ttRepSyncSubscriberStatus組込みプロシージャをコールするか、またはSNMPトラップであるttRepReturnTransitionTrapを使用します。ttRepSyncSubscriberStatus組込みプロシージャで返される値が1の場合は、RETURNサービスがサブスクライバに対して無効になっていることを示し、0(ゼロ)の場合は、RETURNサービスが有効であることを示します。

例12-13 ttRepSyncSubscriberStatusを使用したRETURN RECEIPTのステータスの取得

ttRepSyncSubscriberStatusを使用して、マスター・データベースmasterDSNに対するデータベースsubscriberdsのRETURN RECEIPTのステータスを取得するには、次のように入力します。

> ttIsql masterDSN

Command> CALL ttRepSyncSubscriberStatus ('subscriberds');
< 0 >
1 row found.

この結果は、RETURNサービスが有効であることを示しています。

RETURNサービスを有効化または無効化する方法の詳細は、「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。

RETURNサービスの最後に返されたステータスの確認

接続ハンドルで最後に実行されたRETURN RECEIPTトランザクションまたはRETURN TWOSAFEトランザクションのステータスは、ttRepXactTokenGetおよびttRepXactStatusプロシージャをコールして確認できます。

まず、ttRepXactTokenGet組込みプロシージャをコールして、最後のRETURNサービス・トランザクションの固有トークンを取得します。RETURN RECEIPTを使用している場合は、マスター・データベースで最後にコミットされたRETURN RECEIPTトランザクションがトークンによって識別されます。RETURN TWOSAFEを使用している場合は、サブスクライバでのコミットが成功した場合に、マスターのレプリケーション・エージェントによってコミットされる、マスター上の最後のRETURN TWOSAFEトランザクションがトークンによって識別されます。ただし、タイムアウトなどのエラーが発生した場合、トークンによって識別されたTWOSAFEトランザクションはマスターのレプリケーション・エージェントによってはコミットされません。

次に、ttRepXactTokenGetによって返されたトークンをttRepXactStatus組込みプロシージャに渡して、RETURNサービスのステータスを取得します。ttRepXactStatus組込みプロシージャの出力は、レプリケート・データを受信するように構成されているサブスクライバ、および各サブスクライバに対してトランザクションの現在のステータス(未送信、受信済、コミット済)をレポートします。サブスクライバ・レプリケーション・エージェントがサブスクライバ・データベースへのトランザクションの適用時に問題を検出した場合、ttRepXactStatus組込みプロシージャにはエラー文字列も含まれます。RETURN TWOSAFEの使用時にタイムアウトなどのエラーを受信した場合は、無条件にコミットするか、コミットを再試行するかを決定できます。これは、「RETURNサービスの使用」で説明されます。

注意:
ttRepXactTokenGetで取得したトークンを使用せずにttRepXactStatusをコールすると、接続上でRETURN RECEIPTまたはRETURN TWOSAFEレプリケーション・サービスによって最後にコミットされたトランザクションの状態が返されます。

ttRepXactStatus組込みプロシージャは、各サブスクライバのRETURNサービスのステータスを、次のように書式設定された行セットとして返します。

subscriberName, status, error

例12-14 各サブスクライバのステータスのレポート

GetRSXactStatus関数でttRepXactTokenGetおよびttRepXactStatus組込みプロシージャをコールすると、レプリケート・システムの各サブスクライバのステータスをレポートできます。

SQLRETURN GetRSXactStatus (HDBC hdbc)
{
SQLRETURN rc = SQL_SUCCESS;
HSTMT hstmt = SQL_NULL_HSTMT;
char xactId [4001] = "";
char subscriber [62] = "";
char state [3] = "";

/* get the last RS xact id executed on this connection */
SQLAllocStmt (hdbc, &hstmt);
SQLExecDirect (hstmt, "CALL ttRepXactTokenGet ('R2')", SQL_NTS);

/* bind the xact id result as a null terminated hex string */
SQLBindCol (hstmt, 1, SQL_C_CHAR, (SQLPOINTER) xactId,
sizeof (xactId), NULL);

/* fetch the first and only row */
rc = SQLFetch (hstmt);

/* close the cursor */
SQLFreeStmt (hstmt, SQL_CLOSE);

if (rc != SQL_ERROR && rc != SQL_NO_DATA_FOUND)
{
/* display the xact id */
printf ("\nRS Xact ID: 0x%s\n\n", xactId);

/* get the status of this xact id for every subscriber */
SQLBindParameter (hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR,
SQL_VARBINARY, 0, 0,
(SQLPOINTER) xactId, strlen (xactId), NULL);

/* execute */
SQLExecDirect (hstmt, "CALL ttRepXactStatus (?)", SQL_NTS);

/* bind the result columns */
SQLBindCol (hstmt, 1, SQL_C_CHAR, (SQLPOINTER) subscriber,
sizeof (subscriber), NULL);

SQLBindCol (hstmt, 2, SQL_C_CHAR, (SQLPOINTER) state,
sizeof (state), NULL);

/* fetch the first row */
rc = SQLFetch (hstmt);

while (rc != SQL_ERROR && rc != SQL_NO_DATA_FOUND)
{
/* report the status of this subscriber */
printf ("\n\nSubscriber: %s", subscriber);
printf ("\nState: %s", state);

/* are there more rows to fetch? */
rc = SQLFetch (hstmt);
}
}

/* close the statement */
SQLFreeStmt (hstmt, SQL_DROP);

return rc;
}

レプリケーション・ログの未処理トランザクションの分析

ttXactLogユーティリティで-logAnalyzeコマンドを使用すると、レプリケーション・ログを分析し、次のことを確認できます。

- 現時点でどれだけマスターからサブスクライバにレプリケートされずに残っているか。レプリケーションにかかっている時間が想定以上に長い場合は、レプリケートするトランザクションがどれだけ残っているか、またはレプリケーションが長時間実行トランザクションを実行しているかどうかを確認できます。

- 現在の構成で、パラレル・レプリケーション用に手動トラックおよび自動トラック全体に適切に負荷を分散させられるか。

特定のデータ・ストアにログ分析コマンドを実行し、次の情報を生成します。

- レプリケートされるのを待機しているトランザクションの数。レプリケートされていないトランザクションごとに、収集された情報には、各トランザクションの操作の数、各トランザクションの合計サイズ(部分ロールバックを含む)が含まれます。

- 特定のタイプ(DDLまたはDML)を含む各トランザクションに残されている操作の量、および各トランザクションの各文タイプの数。ツールでも、レプリケートされずに残っているすべての操作の合計サイズが生成されます。

- ワークロードがどのようにトラック全体に分散されるかに関する情報を取得します。手動パラレル・レプリケーションを使用する場合は、-logAnalyzeを使用して、アプリケーションがレプリケーション・トラック全体に均等に作業を分散しているかどうかを監視できます。

- レプリケートされずに残っている最も大きいトランザクションを返します。

- 開始および終了のLSNを返します。開始LSNは、トランザクション・ログでトランスミッタが読取りを開始する箇所であり、終了LSNは、トランザクション・ログの末尾です。

注意:
トランザクション・ログの分析出力では、トランザクションはコミット順に表示されます。

冗長コマンドで表示される情報の量を指定できます。たとえば、冗長を1に設定すると、次のように表示されます。

$ ttXactLog -v1 -logAnalyze rep1
Summary:
Total transactions left to replicate: 4
Total rows left to replicate: 4
Size of transactions left to replicate: 1.86 KiB
Size of rows left to replicate: 488.00 B
Total inserts remaining: 4
Total partial rollbacks: 5
Total rollbacks: 3

Start LSN = 0.3793736
End LSN = 0.18769920

サブスクライバを指定すると、そのサブスクライバのサマリーのみが表示されます。ただし、デフォルトではすべてのサブスクライバのサマリーが表示されます。

冗長を2に設定すると、全体のサマリー情報に加え、各パラレル・トラックのサマリーが表示されます。

$ ttXactLog -v2 -logAnalyze rep1

Track analysis for track number: 0
Transactions left to replicate: 2
Rows left to replicate: 2
Size of transactions left to replicate: 880.00 B
Size of rows left to replicate: 312.00 B
Total inserts remaining: 1
Total partial rollbacks: 4

Track analysis for track number: 1
Transactions left to replicate: 2
Rows left to replicate: 2
Size of transactions left to replicate: 1.14 KiB
Size of rows left to replicate: 244.00 B
Total inserts remaining: 2
Total partial rollbacks: 1
Total rollbacks: 3

Summary:
Total transactions left to replicate: 4
Total rows left to replicate: 4
Size of transactions left to replicate: 2.00 KiB
Size of rows left to replicate: 556.00 B
Total inserts remaining: 3
Total partial rollbacks: 5
Total rollbacks: 3

Start LSN = 0.3793736
End LSN = 0.20506624

冗長レベル3を指定すると、生成される情報には、すべてのトラックにおけるすべてのトランザクションの内容に関する説明を含むトランザクション分析が含まれるようになります。

$ ttXactLog -v3 -logAnalyze rep1

Transaction id:    3.10
Track for this xid: 1
Logmarker before this xid: 275
Rows left to replicate: 1
Transaction size: 800.00 B
Size of rows left: 122.00 B
Total inserts remaining: 1

Transaction id:    2.1
Track for this xid: 0
Logmarker before this xid: 276
Rows left to replicate: 1
Transaction size: 368.00 B
Size of rows left: 122.00 B
Total inserts remaining: 1

Transaction id:    2.19
Track for this xid: 1
Logmarker before this xid: 823
Rows left to replicate: 1
Transaction size: 368.00 B
Size of rows left: 122.00 B
Total inserts remaining: 1

Transaction id:    3.2
Track for this xid: 0
Logmarker before this xid: 842
Rows left to replicate: 1
Transaction size: 368.00 B
Size of rows left: 122.00 B
Total inserts remaining: 1

Track analysis for track number: 0
Transactions left to replicate: 2
Rows left to replicate: 2
Size of transactions left to replicate: 736.00 B
Size of rows left to replicate: 244.00 B
Total inserts remaining: 2
Total partial rollbacks: 4

Track analysis for track number: 1
Transactions left to replicate: 2
Rows left to replicate: 2
Size of transactions left to replicate: 1.14 KiB
Size of rows left to replicate: 244.00 B
Total inserts remaining: 2
Total partial rollbacks: 1
Total rollbacks: 3

Summary:
Total transactions left to replicate: 4
Total rows left to replicate: 4
Size of transactions left to replicate: 1.86 KiB
Size of rows left to replicate: 488.00 B
Total inserts remaining: 4
Total partial rollbacks: 5
Total rollbacks: 3

Start LSN = 0.3793736
End LSN = 0.21444608

XIDを指定すると、トランザクション分析がXIDに基づく冗長レベル3の出力が表示されます。2つの別々のトランザクションで1つのXIDが使用されると、レポートには、LogMarkerエントリとともに、各トランザクションの開始直前のトランザクション・ログ内で最も近い箇所が表示されます。

$ ttXactLog -logAnalyze -xid 2.19 rep1;

Transaction id:    2.19
Track for this xid: 1
Logmarker before this xid: 823
Rows left to replicate: 1
Transaction size: 368.00 B
Size of rows left: 122.00 B
Total inserts remaining: 1

Track analysis for track number: 0
Transactions left to replicate: 0
Rows left to replicate: 0
Size of transactions left to replicate: 0.00 B
Size of rows left to replicate: 0.00 B

Track analysis for track number: 1
Transactions left to replicate: 1
Rows left to replicate: 1
Size of transactions left to replicate: 368.00 B
Size of rows left to replicate: 122.00 B
Total inserts remaining: 1

Summary:
Total transactions left to replicate: 1
Total rows left to replicate: 1
Size of transactions left to replicate: 368.00 B
Size of rows left to replicate: 122.00 B
Total inserts remaining: 1

Start LSN = 0.3793736
End LSN = 0.20514816

注意:
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttXactLogに関する説明を参照してください。

13 レプリケーション競合の解消

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

- レプリケーション競合が発生する理由

- タイムスタンプを使用した競合の解消

- タイムスタンプ比較の構成

- 競合のレポート

- 競合レポートのXML Document Type Definition(DTD)

レプリケーション競合が発生する理由

双方向レプリケーション・スキームで構成されたデータベースの表では、レプリケーション競合が発生する可能性があります。レプリケーション競合は、双方向レプリケーション・データベースでアプリケーションが同じデータ項目に対して同時に更新、挿入または削除処理を開始した場合に発生します。特別な手順を実行しなかった場合、各データベースが他方のデータベースで最後に行われた更新と一致しなくなる可能性があります。

次のタイプのレプリケーション競合が発生する可能性があります。

- 更新競合: このタイプの競合は、異なるデータベースで同時実行中のトランザクションが同じ表の同じ行に対して同時に更新リクエストを行い、1つ以上の列に異なる値をインストールした場合に発生します。

- 一意競合: このタイプの競合は、異なるデータベースで同時実行中のトランザクションが、主キーまたは一意キーは同じでも、他の1つ以上の列の値が異なる同じ表の行に対して同時に挿入リクエストを行った場合に発生します。

- 削除競合: このタイプの競合は、あるデータベースのトランザクションが行を削除し、別のデータベースの同時実行トランザクションが同時に同じ行を更新または挿入した場合に発生します。現在、TimesTenでは削除/更新競合は検出できますが、削除/挿入競合は検出できません。TimesTenはいずれのタイプの削除競合も解消できません。

更新、一意、削除競合の検出時にTimesTenで作成されるレポートの例は、「競合のレポート」を参照してください。

注意:
TimesTenでは、TRUNCATE TABLE文に関連する競合は検出されません。

更新競合および挿入競合

図13-1に、次の表に示す状況で値Xに対して発生する更新競合の結果を示します。

ステップ

データベースA

データベースB

初期状態

Xは1です。

Xは1です。

各データベースのアプリケーションが同時にXを更新。

X=2を設定します。

X=100を設定します。

各データベースのレプリケーション・エージェントが他方のデータベースに更新を送信。

XをデータベースBにレプリケートします。

XをデータベースAにレプリケートします。

各データベースが他方のデータベースの更新を受信。

レプリケーションがX=100に設定するように指示します。

レプリケーションがX=2に設定するように指示します。

注意:
挿入の競合から発生する一意競合は、更新競合に類似したパターンになります。ただし、競合は行全体に影響します。

図13-1 更新競合

更新競合または挿入競合を確認しないでそのままにしておくと、マスターとサブスクライバのデータベースは互いに同期しなくなります。正しいデータベースを判断することが困難、または不可能になる場合さえあります。

更新競合では、トランザクションで多数のデータ項目が更新された場合でも、一部の項目で競合が発生する可能性があります。トランザクションの結果は、レプリケーションによって少し上書きされるのみで、ほとんどが競合の影響を受けません。このような競合を無視すると、アプリケーション・データのトランザクションの一貫性が損なわれます。

更新競合が発生した場合、および行のバージョンごとに更新された列が異なる場合は、行に対する主キー以外のフィールドがレプリケート表間で異なる場合があります。

注意:
1つのデータベース内では、ロック・プロトコルで更新競合が防止されるため、一度に1つのトランザクションのみがデータベースの特定の行を更新できます。ただし、レプリケーション・システムでは、各データベースで独立して処理を行うことができるため、更新競合が発生する可能性があります。

TimesTenレプリケーションでは、同時更新または挿入に対処するためにタイムスタンプ・ベースの競合解消が使用されます。タイムスタンプ・ベースの競合解消を使用することで、レプリケート・データベースの同期およびトランザクションの一貫性を維持できます。

削除/更新競合

図13-2に、次の表に示す状況でRow 4に対して発生する削除/更新競合の結果を示します。

ステップ

データベースA

データベースB

初期状態。

Row 4が存在します。

Row 4が存在します。

各アプリケーションで、Row 4に対して競合する更新および削除を同時に発行。

Row 4を更新します。

Row 4を削除します。

各データベースのレプリケーション・エージェントが他方のデータベースに削除または更新を送信。

更新をデータベースBにレプリケートします。

削除をデータベースAにレプリケートします。

各データベースが他方のデータベースから削除または更新を受信。

レプリケーションがRow 4を削除するように指示します。

レプリケーションがRow 4を更新するように指示します。

図13-2 削除/更新競合

TimesTenは削除/更新競合を検出およびレポートすることはできますが、解消することはできません。このような状況では、マスターとサブスクライバのデータベースは互いに同期しなくなります。

TimesTenでは、このような競合が発生した後のデータベース間の同期は保証できませんが、最新のトランザクションが各データベースに適用されることは保証されます。削除のタイムスタンプが更新のタイムスタンプより新しい場合は、各データベースで行が削除されます。更新のタイムスタンプが削除のタイムスタンプより新しい場合は、ローカル・データベースで行が更新されます。ただし、その行は他方のデータベースでは削除されているため、レプリケート対象の更新は破棄されます。レポートの例は、「削除/更新競合のレポート」を参照してください。

注意:
UPDATE BY USERが使用されている表でタイムスタンプの比較が有効になっている場合は、この動作の例外となります。詳細は、「ユーザー・タイムスタンプ列のメンテナンスの有効化」を参照してください。

タイムスタンプを使用した競合の解消

競合が発生する可能性があるレプリケート表の場合は、BINARY(8)型の特別な列を持つ表を作成して、行を挿入または最後に更新した時刻を示すタイムスタンプ値を保持します。特定の行を変更するたびにこの列にタイムスタンプ値が自動的に挿入されるようにTimesTenを構成できます(「タイムスタンプ比較の設定」を参照)。

注意:
TimesTenでは、キャッシュ・グループにキャッシュされた表とOracle Database間の競合解消はサポートしていません。

レプリケーションでのタイムスタンプ列の計算方法は、システムによって異なります。

- UNIXシステムでは、gettimeofdayシステム・コールによって返される構造体timevalからタイムスタンプ値が導出されます。この構造体は、粒度が1マイクロ秒の時刻を4バイトの単語の組合せでレポートします。実際の粒度はシステムによって異なります。

- Windowsシステムでは、Win32コールGetSystemTimeAsFileTimeからタイムスタンプ値が導出されます。Windowsファイル時刻は0.1マイクロ秒の単位でレポートされますが、有効な粒度として最大10ミリ秒を指定できます。

TimesTenでは、トランザクションが各レコードを適用するときにシステムによって返される時間値が、レコードの挿入または更新時間として使用されます。そのため、単一のトランザクションによって挿入または更新された行が、異なるタイムスタンプ値を受信する場合があります。

マスターから受信したトランザクションを適用する場合、サブスクライバ・データベースのレプリケーション・エージェントは、挿入処理、更新処理、削除処理について次の方法でタイムスタンプによる解消を実行します。

- レプリケートされたINSERT処理を適用する場合:

- 適用されるトランザクションのタイムスタンプが既存の行のタイムスタンプよりも新しい場合、既存行が上書きされます。

- トランザクション・レコードと保存されているレコードのタイムスタンプが同じである場合、挿入処理は破棄されます。

- トランザクション・レコードのタイムスタンプが保存されているレコードのタイムスタンプよりも古い場合、トランザクションの挿入処理は破棄されます。

- 保存されている行が削除されていた場合、比較に使用できるタイムスタンプがありません。以前に削除された行へのレプリケートされた挿入処理が、挿入として適用されます。

- レプリケートされたUPDATE処理を適用する場合:

- 適用されるトランザクション・レコードのタイムスタンプが保存されているレコードのタイムスタンプよりも新しい場合、TimesTenは行に対して更新処理を適用します。

- トランザクション・レコードと保存されているレコードのタイムスタンプが同じである場合、更新処理は破棄されます。

- トランザクション・レコードのタイムスタンプが保存されているレコードのタイムスタンプよりも古い場合、トランザクションの更新処理は破棄されます。

- 保存されている行が削除されていた場合、比較に使用できるタイムスタンプがありません。削除された行に対して指定された、レプリケートされたすべての更新処理は破棄されます。

- 更新された行を検出できない更新処理は削除競合とみなされ、レポートされますが、解消はできません。

- レプリケートされたDELETE処理を適用する場合:

- レプリケートされた削除処理のタイムスタンプが既存行のタイムスタンプよりも新しい場合、既存行は削除されます。

- レプリケートされた削除処理のタイムスタンプが保存されたレコードよりも古い場合(行が最近変更された場合)、削除処理は拒否されます。

注意:
表にON EXCEPTION NO ACTION句が指定されている場合、タイムスタンプ比較に失敗した更新、挿入、削除処理は拒否されます。このため、レプリケーションでトランザクションの処理の(すべてではなく)一部が適用された場合、トランザクションの一貫性が損なわれる可能性があります。表にON EXCEPTION ROLLBACK WORK句が指定されている場合(デフォルト)は、タイムスタンプ比較に失敗すると、更新のトランザクション全体が拒否されます。

ローカル更新のタイムスタンプ比較

レプリケーション・サイト間で表の同期をメンテナンスするには、TimesTenでローカル・トランザクションが実行する更新に対してもタイムスタンプ比較を行います。更新された表に自動タイムスタンプ・メンテナンスが宣言されている場合、現在のシステム時間を超えるタイムスタンプを持つレコードへの更新は禁止されます。

通常、レプリケート・システムのクロックは、他のシステムに保存されているレコードのタイムスタンプより後のタイムスタンプがローカルで更新された同じレコードに指定されるように十分に同期されています。完全に同期させることは不可能ですが、レプリケーションでは、レコードのタイムスタンプが過去にさかのぼらないようにすることによって、レプリケート・システムの表を同期されたままにできます。

タイムスタンプ比較の構成

タイムスタンプ比較を構成するには、次の手順を実行します。

- タイムスタンプ値を保持する列をレプリケート表に挿入します。「レプリケート表へのタイムスタンプ列の挿入」を参照してください。

- CREATE REPLICATION文のTABLE要素ごとにCHECK CONFLICTS句を含めて、タイムスタンプ列、タイムスタンプの生成方法、競合発生時の対処および競合のレポート方法を指定します。「CHECK CONFLICTS句の構成」を参照してください。

レプリケート表へのタイムスタンプ列の挿入

レプリケートされた表でタイムスタンプ比較を使用するには、NULL値可能なBINARY(8)型の列を指定して、タイムスタンプ値を保持する必要があります。タイムスタンプ列は、CREATE TABLE文の一部として表とともに作成する必要があります。後でALTER TABLE文の一部として追加することはできません。また、タイムスタンプ列を主キーまたは索引に含めることはできません。例13-1に、タイムスタンプ値を保持するBINARY(8)型の列tstampを含むrep.tab表を示します。

例13-1 表作成時のタイムスタンプ列の挿入

CREATE TABLE rep.tab (col1 NUMBER NOT NULL,
col2 NUMBER NOT NULL,
tstamp BINARY(8),
PRIMARY KEY (col1));

レプリケート表にタイムスタンプ値が定義されていない場合は、タイムスタンプ比較を実行して競合を検出できません。かわりに、各サイトのデータベース内の行の値に、ローカル・アプリケーションまたはレプリケーションによって行に最後に適用された更新が反映されます。

CHECK CONFLICTS句の構成

レプリケーション・スキームの構成時に、CREATE REPLICATION文の表の要素記述にCHECK CONFLICTS句を含めることによって、TABLE要素にタイムスタンプ比較を設定できます。

注意:
CHECK CONFLICT句はDATASTORE要素には指定できません。

構文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の「CREATE REPLICATION」文と「CHECK CONFLICTS」句を参照してください。例13-2に、レプリケーション・スキームの構成時にCHECK CONFLICTSを使用する方法を示します。

例13-2 自動タイムスタンプ比較

この例では、例9-10の双方向レプリケーション・スキームに自動タイムスタンプ比較を設定します。west_dsnおよびeast_dsnというDSNで、タイムスタンプ表tstampを含む表repl.accountsをレプリケートするwestdsデータベースおよびeastdsデータベースを定義します。比較に失敗した場合は、タイムスタンプが古い方の更新を含むトランザクションを破棄します。

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast";

競合解消でデータベースを双方向にレプリケートした場合、各データベースのレプリケート表は、同じCHECK CONFLICTS属性で設定されている必要があります。レプリケート表のCHECK CONFLICTS設定を無効化または変更する必要がある場合は、「クラシック・レプリケーション・スキームでの競合検出の無効化」の説明に従ってALTER REPLICATION文を使用し、各レプリケート・データベースに適用します。

システム・タイムスタンプ列のメンテナンスの有効化

システム・タイムスタンプ比較を有効にするには、次の構文を使用します。

CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN ColumnName
UPDATE BY SYSTEM

TimesTenでは、基礎となるオペレーティング・システムによって返される現在の時間を使用してタイムスタンプ列の値が自動的にメンテナンスされます。これがデフォルトの設定です。

UPDATE BY SYSTEMを指定すると、TimesTenは次の処理を実行します。

- 新しいレコードが表に挿入されると、タイムスタンプ列を現在の時間に初期設定します。

- 既存のレコードが変更されると、タイムスタンプ列を現在の時刻に更新します。

初期ロード時、タイムスタンプ列の値はNULLのままにしておく必要があります。また、行の挿入時または更新時に、アプリケーションでタイムスタンプ列に値を指定しないでください。

ttBulkCpまたはttMigrateユーティリティを使用してTimesTen表を保存した場合、保存された行にそれらの現在のタイムスタンプ値が保持されます。その後、表がTimesTenにコピーまたは移行された場合は、コピー・ファイルまたは移行ファイルが作成された時点でタイムスタンプ列に含まれていた値が保持されます。

注意:
ttBulkCpまたはttMigrateを使用して表をコピーまたは移行した後にタイムスタンプ比較を行うようにTimesTenを構成した場合、タイムスタンプ列の初期値はNULLのままになります。レプリケーションでは、この値が設定可能な最も早い時間とみなされます。

ユーザー・タイムスタンプ列のメンテナンスの有効化

表でユーザー・タイムスタンプ列のメンテナンスを有効にするには、次の構文を使用します。

CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN ColumnName
UPDATE BY USER

UPDATE BY USERを構成する場合、アプリケーションでタイムスタンプ値をメンテナンスする必要があります。アプリケーションで使用されるタイムスタンプ値は任意に設定できますが、時間値は小さくできません。ユーザーがタイムスタンプ列を明示的に設定または更新した場合、アプリケーション指定の値が現在の時間のかわりに使用されます。

レプリケート対象の削除操作には、常にシステム生成タイムスタンプが含まれます。レプリケーションがUPDATE BY USERで構成されている場合に更新/削除競合が発生すると、2つのタイムスタンプ値が比較されて競合が解消され、タイムスタンプが新しい方の操作が優先されます。ユーザー・タイムスタンプの基準がシステム生成タイムスタンプの基準と異なると、予期しない結果になる場合があります。このため、削除競合の発生が予想される場合は、システム生成タイムスタンプを使用します。

競合のレポート

TimesTenの競合検出では、判読可能なプレーン・テキスト・ファイル、またはユーザー・アプリケーションで使用されるXMLファイルに競合がレポートされるように構成できます。この項の内容は次のとおりです。

- テキスト・ファイルへの競合のレポート

- XMLファイルへの競合のレポート

- 一意競合のレポート

- 更新競合のレポート

- 削除/更新競合のレポート

- 競合のレポートの一時停止と再開

テキスト・ファイルへの競合のレポート

判読可能なテキスト・ファイルに競合がレポートされるようにレプリケーションを構成する(デフォルト)には、次の構文を使用します。

CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN ColumnName
...
REPORT TO 'FileName' FORMAT STANDARD

各競合について記述するレポート・ファイルFileNameにエントリが追加されます。標準のレポート形式がデフォルトのため、FORMAT STANDARDという語はオプション(省略可能)です。

障害が発生した各処理は、ヘッダーで始まるエントリの後に、競合している処理に固有の情報が続く構成でレポートにロギングされています。レポート内の各エントリは、多数の空白行で区切られています。

ヘッダーには次の情報が含まれます。

- 競合が検出された時間。

- 競合する更新を送受信したデータベース。

- 競合が発生した表。

ヘッダーの書式は次のとおりです。

Conflict detected at time on date
Datastore : subscriber_database
Transmitting name : master_database
Table : username.tablename

次に例を示します。

Conflict detected at 20:08:37 on 05-17-2004
Datastore : /tmp/subscriberds
Transmitting name : MASTERDS
Table : USER1.T1

ヘッダーの後には、競合に固有の情報が続きます。データ値はASCII形式で表示されます。バイナリ・データは表示前に16進形式に変換され、浮動小数点値が適切な精度およびスケールで表示されます。

競合レポート・ファイルの詳細は、「一意競合のレポート」、「更新競合のレポート」および「削除/更新競合のレポート」を参照してください。

XMLファイルへの競合のレポート

XMLファイルに競合がレポートされるようにレプリケーションを構成するには、次の構文を使用します。

CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN ColumnName
...
REPORT TO 'FileName' FORMAT XML

レプリケーションでは、基本ファイル名FileNameを使用して2つのファイルが作成されます。FileName.xmlは、<ttrepconflictreport>として定義されたヘッダー・ファイルで、ルート要素および競合レポート構造のXML Document Type Definition(DTD)を含んでいます。ルート要素の内部には、ファイルFileName.includeをインクルードするためのXMLディレクティブが存在し、すべての競合がこのファイルに書き込まれます。各競合は、<conflict>タイプの一要素として書き込まれます。

競合レポート・ファイルのXML要素の詳細は、「競合レポートのXML Document Type Definition(DTD)」を参照してください。

注意:
XML競合レポート・ファイルでログ・メンテナンスを実行する場合は、ファイルFileName.includeのみを切り捨てるか、または移動する必要があります。競合レポートを継続して正常に機能させるには、ファイルFileName.xmlは変更せずにそのままの状態にしておく必要があります。

一意競合のレポート

競合が原因でレプリケート対象の挿入が失敗した場合、一意競合レコードが発行されます。

レポート・ファイルの一意競合レコードには、次の情報が含まれます。

- 既存のタプル(競合しているタプルの競合相手)のタイムスタンプおよび値。

- 競合している挿入タプル(失敗した挿入のタプル)のタイムスタンプおよび値。

- レコードの識別に使用されたキー列値。

- 競合の検出時に行った処理(単一行挿入またはトランザクション全体の破棄)。

注意:
トランザクションが破棄された場合は、トランザクション全体の内容がレポート・ファイルに記録されます。

一意競合レコードの書式は、次のとおりです。

Conflicting insert tuple timestamp : <timestamp in binary format>
Existing tuple timestamp : <timestamp in binary format>
The existing tuple :
<<column value> [,<column value>. ..]>
The conflicting tuple :
<<column value> [,<column value> ...]>
The key columns for the tuple:
<<key column name> : <key column value>>
Transaction containing this insert skipped
Failed transaction:
Insert into table <user>.<table> <<columnvalue> [,<columnvalue>...]>
End of failed transaction

例13-3に、主キー値2で識別される行に対する一意競合の出力を示します。subscriberdsからレプリケートされた古い挿入がmasterds内の新しい挿入と競合しているため、レプリケート対象の挿入は破棄されます。

例13-3 一意競合の出力

Conflict detected at 13:36:00 on 03-25-2002
Datastore : /tmp/masterds
Transmitting name : SUBSCRIBERDS
Table : TAB
Conflicting insert tuple timestamp : 3C9F983D00031128
Existing tuple timestamp : 3C9F983E000251C0
The existing tuple :
< 2, 2, 3C9F983E000251C0>
The conflicting tuple :
< 2, 100, 3C9F983D00031128>
The key columns for the tuple:
<COL1 : 2>
Transaction containing this insert skipped
Failed transaction:
Insert into table TAB < 2, 100, 3C9F983D00031128>
End of failed transaction

更新競合のレポート

競合が原因でレプリケート対象の更新が失敗した場合、更新競合レコードが発行されます。このレコードでは、次の情報がレポートされます。

- 既存のタプル(競合しているタプルの競合相手)のタイムスタンプおよび値。

- 競合している更新タプル(失敗した更新のタプル)のタイムスタンプおよび値。

- 古い値。この値は、競合しているタプルの元の値(更新に失敗する前の値)です。

- レコードの識別に使用されたキー列値。

- 競合の検出時に行った処理(単一行更新またはトランザクション全体の破棄)。

注意:
トランザクションが破棄された場合は、トランザクション全体の内容がレポート・ファイルに記録されます。

更新競合レコードの書式は、次のとおりです。

Conflicting update tuple timestamp : <timestamp in binary format>
Existing tuple timestamp : <timestamp in binary format>
The existing tuple :
<<column value> [,<column value>. ..]>
The conflicting update tuple :
TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
The old values in the conflicting update:
TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
The key columns for the tuple:
<<key column name> : <key column value>>
Transaction containing this update skipped
Failed transaction:
Update table <user>.<table> with keys:
<<key column name> : <key column value>>
New tuple value:
<TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
End of failed transaction

例13-4に、主キー値6で識別される行のcol2値に対する更新競合の出力を示します。masterdsデータベースからレプリケートされた古い更新がsubscriberds内の新しい更新と競合しているため、レプリケート対象の更新は破棄されます。

例13-4 更新競合の出力

Conflict detected at 15:03:18 on 03-25-2002
Datastore : /tmp/subscriberds
Transmitting name : MASTERDS
Table : TAB
Conflicting update tuple timestamp : 3C9FACB6000612B0
Existing tuple timestamp : 3C9FACB600085CA0
The existing tuple :
< 6, 99, 3C9FACB600085CA0>
The conflicting update tuple :
<TSTAMP :3C9FACB6000612B0, COL2 : 50>
The old values in the conflicting update:
<TSTAMP :3C9FAC85000E01F0, COL2 : 2>
The key columns for the tuple:
<COL1 : 6>
Transaction containing this update skipped
Failed transaction:
Update table TAB with keys:
<COL1 : 6>
New tuple value: <TSTAMP :3C9FACB6000612B0, COL2 : 50>
End of failed transaction

削除/更新競合のレポート

最近削除された行に対して更新を行おうとすると、削除/更新競合レコードが発行されます。このレコードでは、次の情報がレポートされます。

- 競合している更新タプルまたは競合している削除タプル(失敗した方のタプル)のタイムスタンプおよび値。

- 削除タプルが失敗した場合、レポートには既存のタプル(削除タプルと競合していたが、その競合の影響を受けなかった更新タプル)のタイムスタンプおよび値も含まれます。

- レコードの識別に使用されたキー列値。

- 競合の検出時に行った処理(単一行更新またはトランザクション全体の破棄)。

注意:
トランザクションが破棄された場合は、トランザクション全体の内容がレポート・ファイルに記録されます。TimesTenでは、削除/挿入競合は検出できません。

失敗した更新との削除競合を示すレコードの書式は、次のとおりです。

Conflicting update tuple timestamp : <timestamp in binary format>
The conflicting update tuple :
TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
This transaction skipped
The tuple does not exist
Transaction containing this update skipped
Update table <user>.<table> with keys:
<<key column name> : <key column value>>
New tuple value:
<TSTAMP :<timestamp> :<<column value> [,<column value>. ..]>
End of failed transaction

例13-5に、最近削除された行に対する更新で発生した削除/更新競合の出力を示します。更新する行がないため、SUBSCRIBERDSからの更新は破棄されます。

例13-5 削除/更新競合の出力: 削除が最近である場合

Conflict detected at 15:27:05 on 03-25-2002
Datastore : /tmp/masterds
Transmitting name : SUBSCRIBERDS
Table : TAB
Conflicting update tuple timestamp : 3C9FB2460000AFC8
The conflicting update tuple :
<TSTAMP :3C9FB2460000AFC8, COL2 : 99>
The tuple does not exist
Transaction containing this update skipped
Failed transaction:
Update table TAB with keys:
<COL1 : 2>
New tuple value: <TSTAMP :3C9FB2460000AFC8,
COL2 : 99>
End of failed transaction

失敗した削除との更新競合を示すレコードの書式は、次のとおりです。

Conflicting binary delete tuple timestamp : <timestamp in binary format>
Existing binary tuple timestamp : <timestamp in binary format>
The existing tuple :
<<column value> [,<column value>. ..]>
The key columns for the tuple:
<<key column name> : <key column value>>
Transaction containing this delete skipped
Failed transaction:
Delete table <user>.<table> with keys:
<<key column name> : <key column value>>
End of failed transaction

例13-6に、最近更新された行に対する削除で発生した削除/更新競合の出力を示します。削除より後に更新された行があるため、masterdsからの削除は破棄されます。

例13-6 削除/更新競合の出力: 更新が最近である場合

Conflict detected at 15:27:20 on 03-25-2002
Datastore : /tmp/subscriberds
Transmitting name : MASTERDS
Table : TAB
Conflicting binary delete tuple timestamp : 3C9FB258000708C8
Existing binary tuple timestamp : 3C9FB25800086858
The existing tuple :
< 147, 99, 3C9FB25800086858>
The key columns for the tuple:
<COL1 : 147>
Transaction containing this delete skipped
Failed transaction:
Delete table TAB with keys:
<COL1 : 147>

競合のレポートの一時停止と再開

アプリケーションが正しく動作している場合は、レプリケーションで競合が発生してレポートされることは通常ほとんどありません。ただし、負荷が高い場合に、短時間で競合が一時的に発生することがあり、特にアプリケーションの開発中は、そのようなエラーが発生する可能性があります。このような状況では、競合レポート・ファイルへの書込みが過度に発生し、大量のSNMPトラップが生成されることがあるため、ホストのパフォーマンスが低下する可能性があります。

レプリケーションの競合がホストに悪影響を与えることを避けるために、1秒当たりの競合数がユーザーが指定するしきい値を超えたときに競合のレポートを一時停止するようにレプリケーションを構成できます。また、1秒当たりの競合数がユーザーが指定するしきい値を下回ったときに競合のレポートを再開するように構成することもできます。

競合レポートの一時停止と再開が行われたことは、それぞれSNMPトラップのttRepConflictReportStoppingTrapとttRepConflictReportStartingTrapを捕捉することによって、アプリケーションで検出できます。詳細は、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップによる診断に関する説明を参照してください。

競合レポートを1秒当たりの競合数に基づいて一時停止および再開するように構成するには、レプリケーション・スキームのSTORE句に対してCONFLICT REPORTING SUSPEND ATおよびCONFLICT REPORTING RESUME AT属性を使用します。

競合のレポートが一時停止しているときにレプリケーション・エージェントが停止した場合、そのレプリケーション・エージェントが再起動すると競合のレポートも有効になります。その場合、SNMPトラップttRepConflictReportingStartingTrapは送信されません。そのため、競合レポートの一時停止のトラップを監視するアプリケーションでは、レプリケーション・エージェントの停止と起動に関連するトラップも監視する必要があります。

CONFLICT REPORTING RESUME ATを0に設定した場合、レプリケーション・エージェントが再起動するまでレポートは再開されません。

例13-7に、1秒当たりの競合数が20を超えたときに競合レポートを一時停止し、競合数が10未満に下がったときに再開するレプリケーション・スキームの構成を示します。

例13-7 競合レポートのしきい値の構成

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
REPORT TO 'conflicts' FORMAT XML
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE accounts
CHECK CONFLICTS BY ROW TIMESTAMP
COLUMN tstamp
UPDATE BY SYSTEM
ON EXCEPTION ROLLBACK WORK
REPORT TO 'conflicts' FORMAT XML
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast"
STORE westds ON "westcoast"
CONFLICT REPORTING SUSPEND AT 20
CONFLICT REPORTING RESUME AT 10
STORE eastds ON "eastcoast"
CONFLICT REPORTING SUSPEND AT 20
CONFLICT REPORTING RESUME AT 10;

競合レポートのXML Document Type Definition(DTD)

TimesTenのXML形式の競合レポートは、XML 1.0仕様(http://www.w3.org/TR/REC-xml)に基づきます。レプリケーション競合レポートのXML Document Type Definition(DTD)は、レプリケーション競合のログを含む有効なXMLファイルの要素および構造を記述した一連のマークアップ宣言です。このDTDは、競合がXMLファイルにレポートされるようにレプリケーションを構成したときに作成されるXMLヘッダー・ファイル(拡張子.xmlで識別される)に含まれます。XMLを認識するユーザー・アプリケーションでは、DTDを使用してXMLレプリケーション競合レポートの残りの部分が解析されます。XML Document Type Definition(DTD)を判読および理解する方法の詳細は、http://www.w3.org/TR/REC-xmlを参照してください。

<?xml version="1.0"?>
<!DOCTYPE ttreperrorlog [
<!ELEMENT ttrepconflictreport(conflict*) >
<!ELEMENT repconflict        (header, conflict, scope, failedtransaction) >
<!ELEMENT header             (time, datastore, transmitter, table) >
<!ELEMENT time               (hour, min, sec, year, month, day) >
<!ELEMENT hour               (#PCDATA) >
<!ELEMENT min                (#PCDATA) >
<!ELEMENT sec                (#PCDATA) >
<!ELEMENT year               (#PCDATA) >
<!ELEMENT month              (#PCDATA) >
<!ELEMENT day                (#PCDATA) >
<!ELEMENT datastore          (#PCDATA) >
<!ELEMENT transmitter        (#PCDATA) >
<!ELEMENT table              (tableowner, tablename) >
<!ELEMENT tableowner          (#PCDATA) >
<!ELEMENT tablename          (#PCDATA) >
<!ELEMENT scope              (#PCDATA) >
<!ELEMENT failedtransaction  ((insert | update | delete)+) >
<!ELEMENT insert             (sql) >
<!ELEMENT update             (sql, keyinfo, newtuple) >
<!ELEMENT delete             (sql, keyinfo) >
<!ELEMENT sql                (#PCDATA) >
<!ELEMENT keyinfo            (column+) >
<!ELEMENT newtuple           (column+) >
<!ELEMENT column             (columnname, columntype, columnvalue) >
<!ATTLIST column
pos CDATA #REQUIRED >
<!ELEMENT columnname         (#PCDATA) >
<!ELEMENT columnvalue        (#PCDATA) >
<!ATTLIST columnvalue
isnull (true | false) "false">
<!ELEMENT existingtuple       (column+) >
<!ELEMENT conflictingtuple    (column+) >
<!ELEMENT conflictingtimestamp(#PCDATA) >
<!ELEMENT existingtimestamp   (#PCDATA) >
<!ELEMENT oldtuple            (column+) >
<!ELEMENT conflict            (conflictingtimestamp, existingtimestamp*,
existingtuple*, conflictingtuple*,
oldtuple*, keyinfo*) >
<!ATTLIST conflict
type (insert | update | deletedupdate | updatedeleted) #REQUIRED>
<!ENTITY logFile                  SYSTEM "Filename.include">
]>
<ttrepconflictreport>
&logFile;
</ttrepconflictreport>

ドキュメントの本文

XML形式のレプリケーション競合レポート用の.xmlファイルは、レポートの形式を記述し、拡張子が.includeのファイルにリンクするXML Document Type Definitionを含む単なるヘッダーです。このインクルード・ファイルは、レポートの本文であり、各レプリケーション競合を個別の要素として含んでいます。これらの要素には、挿入競合、更新競合、削除/更新競合の3つのタイプがあります。競合タイプごとに、少し異なる要素構造が必要です。

一意競合の要素

一意競合は、同じキー列を持つ行が最近挿入されたため、挿入のレプリケートが正常に実行されなかった場合に発生します。一意競合の競合レポートに書き込まれる情報については、「一意競合のレポート」を参照してください。

例13-8に、例13-3の値を使用して、一意競合のXML要素の書式を示します。

例13-8 一意競合の要素

<repconflict>
<header>
<time>
<hour>13</hour>
<min>36</min>
<sec>00</sec>
<year>2002</year> <month>03</month>
<day>25</day>
</time>
<datastore>/tmp/masterds</datastore>
<transmitter>SUBSCRIBERDS</transmitter>
<table>
<tableowner>REPL</tableowner>
<tablename>TAB</tablename>
</table>
</header>
<conflict type="insert">
<conflictingtimestamp>3C9F983D00031128</conflictingtimestamp>
<existingtimestamp>3C9F983E000251C0</existingtimestamp>
<existingtuple>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9F983E000251C0</columnvalue>
</column>
</existingtuple>
<conflictingtuple>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>100</columnvalue>
</column>
<column pos="3">
<columname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9F983D00031128</columnvalue>
</column>
</conflictingtuple>
<keyinfo>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
</keyinfo>
</conflict>
<scope>TRANSACTION</scope>
<failedtransaction>
<insert>
<sql>Insert into table TAB </sql>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>100</columnvalue>
</column>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>3C9F983D00031128</columnvalue>
</column>
</insert>
</failedtransaction>
</repconflict>

更新競合の要素

更新競合は、行が最近更新されたため、更新のレプリケートが正常に実行されなかった場合に発生します。更新競合の競合レポートに書き込まれる情報については、「更新競合のレポート」を参照してください。

例13-9に、例13-4の値を使用して、更新競合のXML要素の書式を示します。

例13-9 更新競合の要素

<repconflict>
<header>
<time>
<hour>15</hour>
<min>03</min>
<sec>18</sec>
<year>2002</year>
<month>03</month>
<day>25</day>
</time>
<datastore>/tmp/subscriberds</datastore>
<transmitter>MASTERDS</transmitter>
<table>
<tableowner>REPL</tableowner>
<tablename>TAB</tablename>
</table>
</header>
<conflict type="update">
<conflictingtimestamp>
3C9FACB6000612B0
</conflictingtimestamp>
<existingtimestamp>3C9FACB600085CA0</existingtimestamp>
<existingtuple>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>6</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columname>
<columntype>NUMBER(38)</columntype>
<columnvalue>99</columnvalue>
</column>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9FACB600085CA0></columnvalue>
</column>
</existingtuple>
<conflictingtuple>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9FACB6000612B0</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>50</columnvalue>
</column>
</conflictingtuple>
<oldtuple>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9FAC85000E01F0</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
</oldtuple>
<keyinfo>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>6</columnvalue>
</column>
</keyinfo>
</conflict>
<scope>TRANSACTION</scope>
<failedtransaction>
<update>
<<sql>Update table TAB</sql>
<<keyinfo>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>6</columnvalue>
</column>
</keyinfo>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9FACB6000612B0</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>50</columnvalue>
</column>
</update>
</failedtransaction>
</repconflict>

削除/更新競合の要素

削除/更新競合は、更新対象の行が更新を受信するデータベースですでに削除されているため、更新のレプリケートが正常に実行されなかった場合、または行が最近更新されたため、削除のレプリケートが正常に実行されなかった場合に発生します。削除/更新競合の競合レポートに書き込まれる情報については、「削除/更新競合のレポート」を参照してください。

例13-10に、例13-5の値を使用して、行が最近削除されたため、更新が正常に実行されなかった削除/更新競合のXML要素の書式を示します。

例13-10 削除/更新競合の要素: 削除が最近である場合

<repconflict>
<header>
<time>
<hour>15</hour>
<min>27</min>
<sec>05</sec>
<year>2002</year>
<month>03</month>
<day>25</day>
</time>
<datastore>/tmp/masterds</datastore>
<transmitter>SUBSCRIBERDS</transmitter>
<table>
<tableowner>REPL</tableowner>
<tablename>TAB</tablename>
</table>
</header>
<conflict type="update">
<conflictingtimestamp>
3C9FB2460000AFC8
</conflictingtimestamp>
<conflictingtuple>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9FB2460000AFC8</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>99/columnvalue>
</column>
</conflictingtuple>
<keyinfo>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
</keyinfo>
</conflict>
<scope>TRANSACTION</scope>
<failedtransaction>
<update>
<sql>Update table TAB</sql>
<keyinfo>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>2</columnvalue>
</column>
</keyinfo>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9FB2460000AFC8</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>99</columnvalue>
</column>
</update>
</failedtransaction>
</repconflict>

例13-11に、例13-6の値を使用して、行が最近更新されたため、削除が正常に実行されなかった削除/更新競合のXML要素の書式を示します。

例13-11 削除/更新競合の要素: 更新が最近である場合

<repconflict>
<header>
<time>
<hour>15</hour>
<min>27</min>
<sec>20</sec>
<year>2002</year>
<month>03</month>
<day>25</day>
</time>
<datastore>/tmp/masterds</datastore>
<transmitter>MASTERDS</transmitter>
<table>
<tableowner>REPL</tableowner>
<tablename>TAB</tablename>
</table>
</header>
<conflict type="delete">
<conflictingtimestamp>
3C9FB258000708C8
</conflictingtimestamp>
<existingtimestamp>3C9FB25800086858</existingtimestamp>
<existingtuple>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>147</columnvalue>
</column>
<column pos="2">
<columnname>COL2</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>99</columnvalue>
</column>
<column pos="3">
<columnname>TSTAMP</columnname>
<columntype>BINARY(8)</columntype>
<columnvalue>3C9FB25800086858</columnvalue>
</column>
</existingtuple>
<keyinfo>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>147</columnvalue>
</column>
</keyinfo>
</conflict>
<scope>TRANSACTION</scope>
<failedtransaction>
<delete>
<sql>Delete from table TAB</sql>
<keyinfo>
<column pos="1">
<columnname>COL1</columnname>
<columntype>NUMBER(38)</columntype>
<columnvalue>147</columnvalue>
</column>
</keyinfo>
</delete>
</failedtransaction>
</repconflict>

14 レプリケーション・パフォーマンスの向上

レプリケーション・パフォーマンスを向上させる方法を次に説明します。

- パラレル・レプリケーションを構成します。「パラレル・レプリケーションの構成」を参照してください。

- デフォルトの非同期のレプリケーションを使用します。詳細は、「パフォーマンスとリカバリのトレードオフについての判断」を参照してください。ただし、アクティブ・スタンバイ・ペアを使用している場合、RETURN RECEIPT(半同期レプリケーション)よりもRETURN TWOSAFE(同期レプリケーション)のパフォーマンスの方が優れています。

- LogFileSizeおよびLogBufMB初期接続属性を最大値に設定します。詳細は、「ロギングの接続属性の設定」を参照してください。

- ワークロードが高く、レプリケーションが遅延することがある場合、インメモリー・ログ・バッファからではなく、ディスク上のトランザクション・ログからレプリケート対象の変更を取得する必要があります。できるだけ高速の記憶域をTimesTenトランザクション・ログ用に使用することで、トランザクション・ログのフラッシュとレプリケーションの取得によるI/Oの競合が緩和し、ワークロードが少ない時間帯にレプリケーションが遅れをすばやく取り戻せるようになります。複数の高速ディスクまたはソリッド・ステート・ストレージにRAID 0ストライプを構成した高性能のキャッシュ・ディスク・アレイを使用することを検討してください。

- 更新が適用されるデータベースへの様々な接続数を試してみてください。同時接続数が65以上必要な場合、Connections初期接続属性の設定値を高くします。『Oracle TimesTen In-Memory Databaseリファレンス』のConnectionsに関する説明を参照してください。

- トランザクション・ログ・バッファ・サイズ、CPU性能およびリソースを調整します。「トランザクション・ログ・バッファ・サイズおよびCPU」を参照してください。

- 複数のパーティションと余分な領域のある表を変更した後、パフォーマンスの問題が発生する可能性があります。詳細は、「レプリケートされる表を変更するときのパフォーマンスの考慮事項」を参照してください。

- RecoveryThreadsという最初の接続属性を変更して、アクティブ・マスター・データベースからスタンバイ・マスター・データベースに変更を適用するスレッドの数を増やします。詳細は、「アクティブ・スタンバイ・ペアのレプリケーション・スループットの向上」を参照してください。

- レプリケーションおよびXLA操作では、トランザクション・ロギングで大量のオーバーヘッドが発生します。レプリケーションのスケーラビリティは、トランスミッタまたはレシーバの数が制限されている場合に最も高くなります。詳細は、「レプリケーションのトランスミッタとレシーバおよびXLAリーダーの制限」を参照してください。

注意:
追加の推奨事項については、『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』のレプリケーションまたはXLAのパフォーマンスの低下に関する説明を参照してください。

トランザクション・ログ・バッファ・サイズおよびCPUの調整

レプリケーション・スキームを計画する場合は、次の項目を確認してください。

- LogBufMBのトランザクション・ログ設定によって、SYS.MONITOR表のLOG_FS_READSの値が0またはほとんど0になっていること。これで、レプリケーション・エージェントがディスクからトランザクション・ログ・レコードを読み取る必要がなくなります。LOG_FS_READSの値が大きくなる場合は、トランザクション・ログ・バッファ・サイズも大きくしてください。

- CPUリソースが十分にあること。マスター・データベースのレプリケーション・エージェントは、各サブスクライバ・データベースに対してスレッドを生成します。各スレッドでは、トランザクション・ログの読取りと処理が独立して行われるので、この処理には十分なCPUリソースが必要です。

- レプリケーション・スキームの送信側と受信側でCPUの能力が一致していない場合は、レプリケーションの受信側を高速な方のシステムに配置すること。

レプリケートされる表を変更するときのパフォーマンスの考慮事項

列を追加または削除するために表を変更すると、パフォーマンスや領域使用率が低下する場合があります。

- 1つ以上の列を追加するために表を変更すると、その列用に新しいパーティションが割り当てられます。パーティションの追加によって、データの取得時に追加の処理が発生するため、パフォーマンスが低下します。ALTER TABLEを使用したときにどのようにパーティションが追加されるかを理解するには、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER TABLE」を参照してください。

- 列を削除するために表を変更しても、領域が解放されるわけではないため、領域使用率が低下します。

TABLE DEFINITION CHECKING EXACT属性で定義されたレプリケーション・スキームでは、両方のマスター・データベース間で操作をレプリケートできるようにするために、それらのマスター・データベース上に同じ物理構造の表が必要です。EXACT表定義チェック属性を使用している場合、列の削除によって発生した余分な領域を解放したり、列の追加によって発生した余分なパーティションを排除するための唯一の方法は、表を削除して再作成した後、その表にデータをリロードすることです。

ただし、TABLE DEFINITION CHECKING RELAXED属性で表を作成した場合は、(表のキー定義、列数、列のデータ型は同じですが、)両方のマスター・データベースで物理構造が同じである必要はありません。TABLE DEFINITION CHECKING RELAXED属性によってパフォーマンスはわずかに低下しますが、これは両方のマスター上の表が同じでない場合です。パフォーマンスの変化は、ワークロードおよび表のパーティションおよび列の数に応じて異なります。

RELAXEDが設定されたデータベースのパフォーマンスを向上させるには、ttMigrate -r -relaxedUpgradeを使用して表を結合し、列の削除によって発生した余分な領域または列の追加によって作成された複数のパーティションを排除します。これを行うことができるのは1つのデータベースのみであり、その間、もう一方のデータベースは稼働を続け、アプリケーションにかわってリクエストを受け付けています。レプリケーションに含まれる両方のデータベースを同時に停止する必要はなく、1つずつ順番にttMigrate -r -relaxedUpgradeを実行できます。これは、表が頻繁に変更されるデータベースの場合、およびデータベースがオンライン・アップグレードのみを行う場合に最適です。

表定義チェックがRELAXEDの場合、レプリケートされた表に対するttMigrate -r -relaxedUpgradeでできるのは、パーティションを結合し、余分な領域を排除することのみです。ただし、表でEXACT属性が使用されている場合は、表定義チェックを一時的にRELAXEDに設定し、表のパーティションと領域を連結した後、EXACTにリセットできます。

TABLE DEFINITION CHECKING RELAXED属性の詳細は、「レプリケート表の列定義オプション」を参照してください。

注意:
表に複数のパーティションがあるかどうかを確認できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の「ALTER TABLE」のALTER TABLE使用時のパーティションに関する説明、および『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』の表のパーティション数の確認に関する説明を参照してください。

アクティブ・スタンバイ・ペアのレプリケーション・スループットの向上

パラレル・レプリケーションを構成することで、アクティブ・スタンバイ・ペアのレプリケーションのスループットを向上できます。デフォルトでは、レプリケーションは、レプリケーション・スキーム内のノードに、1つのログ・リーダー(ソース・データベースでのトランスミッタ・スレッド)と1つのアプライヤ(ターゲット・データベースでのレシーバ・スレッド)が含まれるシングル・スレッドで実行されます。パラレル・レプリケーションでは、ソース・データベースからターゲット・データベースに更新を送信し、その更新をターゲット・データベースで適用するための複数のスレッドをインスタンス化します。詳細は、「パラレル・レプリケーションの構成」を参照してください。

または、ReceiverThreads初期接続属性を使用して、アクティブ・マスター・データベースの変更をスタンバイ・マスター・データベースに適用するスレッドの数を、1から2に増やすことができます。フェイルオーバーが発生した場合にスループットの向上を維持するためには、スタンバイ・データベースでReceiverThreadsを2に設定した場合、アクティブ・データベースでも2に設定する必要があります。

また、アクティブ・スタンバイ・ペアの1つ以上の読取り専用サブスクライバでReceiverThreadsを2に設定しても、スタンバイ・マスター・データベースからのレプリケーション・スループットを向上できます。

この属性を2に設定することによるメリットを利用するには、データベースが双方向以上のシステムでホストされている必要があります。

注意:
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のReceiverThreadsに関する説明を参照してください。

レプリケーションのトランスミッタとレシーバおよびXLAリーダーの制限

レプリケーションおよびXLA操作では、トランザクション・ロギングで大量のオーバーヘッドが発生します。レプリケーションのスケーラビリティは、トランスミッタまたはレシーバの数が制限されている場合に最も高くなります。レプリケーションのトポロジを調べ、簡略化できるかどうか確認します。通常、XLAのスケーラビリティは、リーダーの数が制限されている場合に最も高くなります。アプリケーションのリーダー数が多い場合は、その数を削減できるかどうかを確認します。

XLAおよびレプリケーションを監視して、読取りがディスクからではなく、トランザクション・ログ・バッファから行われていることを確認してください。同時実行される更新が多いと、レプリケーションが処理されない場合があります。サブスクライバでは、更新はシングルスレッドです。確認の頻度が減少すると、XLAのスループットを向上できます。

SYS.MONITOR表のLOG_FS_READS列およびLOG_BUFFER_WAITS列の値を確認して、必要なリーダーおよびトランスミッタの数を見積もります。この情報は、接続が確立または解放されるたび、およびトランザクションがコミットまたはロールバックされるたびにシステムによって更新されます。

LogFlushMethod=2を設定すると、RETURN TWOSAFEレプリケーション処理、およびDURABLE TRANSMITが指定されたRETURN RECEIPT処理のパフォーマンスを向上できます。

15 データベースのフェイルオーバーおよびリカバリの管理

この章の説明は、アクティブ・スタンバイ・ペアを含むすべてのレプリケーション・スキームに適用されます。ただし、アクティブ・スタンバイ・ペアの監視には、Oracle Clusterwareと統合されたTimesTenが最適です。第8章「Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理」を参照してください。

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

- データベースのフェイルオーバーおよびリカバリの概要

- 一般的なフェイルオーバーおよびリカバリの手順

- 障害が発生したデータベースのリカバリ

- 非永続的データベースのリカバリ

- 障害リカバリ・スクリプトの作成

データベースのフェイルオーバーおよびリカバリの概要

高可用性システムの設計での基本的な要素は、障害からすぐにリカバリできる機能です。障害は、システムの障害やネットワークの障害など、ハードウェアの問題に関連している場合があります。ソフトウェアの障害には、オペレーティング・システムの障害、アプリケーションの障害、データベースの障害およびオペレータのエラーが含まれます。

レプリケート・システムでは、クラスタ・マネージャまたはカスタム・ソフトウェアを使用してこのような障害を検出し、マスター・データベースに関連する障害が発生した場合は、ユーザー負荷をいずれかのサブスクライバにリダイレクトする必要があります。ここでは、アプリケーションまたはクラスタ・マネージャで障害のリカバリに使用できるTimesTenメカニズムについて説明します。

レプリケーション・スキームがRETURN TWOSAFEを使用するように構成されていないかぎり、TimesTenでは、元のトランザクションがマスター・データベースにコミットした後にのみ、更新がレプリケートされます。サブスクライバ・データベースが稼働できない場合、またはサブスクライバ・データベースへの通信で障害が発生した場合でも、マスターでの更新は妨げられません。サブスクライバ・システムの停止中、サブスクライバへの更新はTimesTenトランザクション・ログに保存されます。

注意:
この章の手順を実行するには、ADMIN権限が必要です。

一般的なフェイルオーバーおよびリカバリの手順

フェイルオーバーおよびリカバリを管理するための手順は、主に次の内容に依存します。

- レプリケーション・スキーム

- 障害がマスターまたはサブスクライバのデータベースのいずれで発生したか。

- 問題が解決され、データベースを再接続する前に、マスターのトランザクション・ログのしきい値を超えてしまったかどうか。

サブスクライバの障害

デフォルトの非同期のレプリケーション・スキームでは、サブスクライバ・データベースが稼働できない場合、またはサブスクライバ・データベースへの通信で障害が発生した場合でも、マスターでの更新は妨げられないため、クラスタ・マネージャですぐに処理を行う必要はありません。

注意:
障害が発生したサブスクライバがRETURNサービスを使用するように構成されている場合は、まず、RETURNサービス・ブロッキングを無効にする必要があります(「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照)。

サブスクライバ・システムの停止中、サブスクライバへの更新はマスターのトランザクション・ログに保存されます。マスターがFAILTHRESHOLDに達する前にサブスクライバ・エージェントがマスターとの通信を再開した場合、ログに保存されていた更新はサブスクライバに自動的に送信されるため、これ以上の処理は必要ありません。マスター・データベースのFAILTHRESHOLD値の設定方法の詳細は、「トランザクション・ログ障害しきい値の設定」を参照してください。

FAILTHRESHOLDを超えた場合、マスターはサブスクライバをfailed状態に設定するため、このサブスクライバは、「障害が発生したデータベースのリカバリ」の説明に従ってリカバリする必要があります。障害が発生したサブスクライバに接続中のアプリケーションは、データベースがレプリケーション・ピアによってfailedとマークされたことを示すtt_ErrReplicationInvalid(8025)警告を受信します。

アプリケーションでは、ODBCのSQLGetInfo関数を使用して、接続中のサブスクライバ・データベースがfailed状態に設定されているかどうかを確認できます。SQLGetInfo関数には、TimesTen固有の情報タイプTT_REPLICATION_INVALIDが含まれていて、データベースで障害が発生した場合は32ビットの整数値1、障害が発生しなかった場合は0(ゼロ)を返します。

注意:
情報タイプTT_REPLICATION_INVALIDはTimesTenに固有であるため、これを使用するすべてのアプリケーションでは、ODBCの他のincludeファイルに加えて、timesten.hファイルをインクルードする必要があります。

ただし、各データベースがマスターとサブスクライバの両方として動作する双方向のレプリケーション・スキームを使用している場合に、一方のサブスクライバが失敗すると、エラーが発生します。たとえば、双方向のレプリケーション・スキームのマスターおよびサブスクライバが次のように定義されているとします。

CREATE REPLICATION r1
ELEMENT elem_accounts_1 TABLE ttuser.accounts
MASTER westds ON "westcoast"
SUBSCRIBER eastds ON "eastcoast"
ELEMENT elem_accounts_2 TABLE ttuser.accounts
MASTER eastds ON "eastcoast"
SUBSCRIBER westds ON "westcoast";

- eastdsサブスクライバが失敗すると、westdsマスターは失敗を受信するため、このサブスクライバへの更新の蓄積を停止します。

- eastdsサブスクライバが失敗すると、eastdsのレプリケーション・エージェントは停止します。ただし、eastdsマスターはレプリケーション・エージェントが停止されていることを認識せず、更新の蓄積を続行し、westdsのサブスクライバに伝播します。レプリケーション・エージェント(レコードをサブスクライバに伝播し、FAILTHRESHOLDを監視する)が停止しているため、これらの更新は、定義済のFAILTHRESHOLDを超えて蓄積され続けます。

双方向のレプリケーション・スキームを使用している場合に、失敗したデータベースでTT_REPLICATION_INVALIDが1に設定されている場合は、次の手順を実行します。

1. 失敗したデータベースを破棄します(この例ではeastdsデータベース)。

2. 双方向のレプリケーション・スキームのもう一方のマスターからttRepAdmin -duplicate操作を実行して、失敗したデータベースを再作成します(この例ではwestdsのマスター)。

例15-1 データベースがfailed状態に設定されているかどうかの確認

hdbcハンドルで識別されたデータベースがfailed状態に設定されているかどうかを確認します。

SQLINTEGER retStatus;

SQLGetInfo(hdbc, TT_REPLICATION_INVALID,
(PTR)&retStatus, NULL, NULL);

マスターの障害

クラスタ・マネージャは、障害がマスター・データベースに関連している場合により中心的な役割を果たします。マスター・データベースで障害が発生すると、クラスタ・マネージャはこの障害を検出し、影響を受けなかったいずれかのデータベースにユーザー・ロードをリダイレクトする必要があります。影響を受けなかったこのサブスクライバが新しいマスターとなり、トランザクションを処理して、障害を受けなかった他のサブスクライバ・データベースにレプリケートします。障害が発生したマスターと障害の影響を受けなかったサブスクライバを双方向方式で構成していた場合、障害が発生したマスターからサブスクライバへのユーザー・ロードの転送でレプリケーション・スキームを変更する必要はありません。ただし、単方向レプリケーションまたはプロパゲータが関連するスキームなどの複雑なスキームを使用している場合は、1つ以上のALTER REPLICATION文を発行して、障害の影響を受けなかったサブスクライバを新しいマスターとしてスキームに再構成する必要があります。詳細は、「クラシック・レプリケーション・スキームでのマスター・データベースの交換」を参照してください。

問題の解決時に、「障害が発生したマスター・データベースの自動キャッチアップ」で説明されている双方向構成またはアクティブ・スタンバイ・ペアを使用していない場合は、「障害が発生したデータベースのリカバリ」の説明に従ってマスター・データベースをリカバリする必要があります。

データベースがオンラインに戻った後、クラスタ・マネージャは、ユーザー・ロードを元のマスターに戻すか、または元のマスターを代理マスターのサブスクライバとして再設定することもできます。

障害が発生したマスター・データベースの自動キャッチアップ

マスター・キャッチアップ機能は、ttRepAdmin -duplicate処理(「障害が発生したデータベースのリカバリ」を参照)を実行する必要がなく、サブスクライバ・データベースから障害のあったマスター・データベースを自動的にリストアします。

マスター・キャッチアップ機能は、構成の必要はありませんが、次のタイプの構成でのみ使用できます。

- 1つのサブスクライバに双方向方式でレプリケートされる1つのマスター

- RETURN TWOSAFEを使用して構成されているアクティブ・スタンバイ・ペア

アクティブ・スタンバイ・ペアではないレプリケーション・スキームの場合、次の要件を満たす必要があります。

- ELEMENTタイプがDATASTOREである。

- TRANSMIT NONDURABLEまたはRETURN TWOSAFEが有効である必要がある。

- すべてのレプリケート対象のトランザクションが非永続的にコミットされる必要がある。ローカル・データベースでコミットされる前にリモート・データベースに送信される必要があります。たとえば、レプリケーション・スキームがRETURN TWOSAFE BY REQUESTで構成され、最初にRETURN TWOSAFEを有効にせずにトランザクションがコミットされた場合、マスターに障害が発生した後にマスター・キャッチアップが発生しないことがあります。

クラッシュまたは無効化の後にマスター・レプリケーション・エージェントを再起動すると、マスターで消失したトランザクションがサブスクライバからマスターに(アクティブ・スタンバイ・ペアの場合はスタンバイからアクティブに)自動的にレプリケートされます。マスター・データベースがサブスクライバと完全に同等となるまで、マスター・データベースに接続することはできません。キャッチアップ・フェーズでデータベースへの接続を試行したアプリケーションは、キャッチアップ中であることを示すエラーを受信します。例外は、DSNにForceConnect初期接続属性が設定されているデータベースに接続する場合のみです。

キャッチアップ・フェーズが終了すると、アプリケーションでデータベースに接続できます。キャッチアップ・フェーズの終了は、システム・ログへのSNMPトラップおよびメッセージで示されます。

キャッチアップ・プロセスでいずれかのデータベースが無効にされたか、またはクラッシュした場合、キャッチアップ・フェーズは、データベースが再起動されると再開します。

次のような状況では、マスター・キャッチアップは失敗する場合があります。

- 障害が発生したデータベースが長時間オフラインになり、サブスクライバ・データベース(アクティブ・スタンバイ・ペアのスタンバイ・データベース)で障害しきい値を超えた。

- 障害発生時に、アクティブ・スタンバイ・ペアのアクティブ・データベースで動的なロード処理が実行されていた。RETURN TWOSAFEは、アクティブ・データベースに対して有効になっていても、動的なロード処理では有効になりません。データベースの障害によって動的なロードのトランザクションがトラップされ、RETURN TWOSAFEで障害が発生します。

アクティブ・スタンバイ・ペアにマスター・キャッチアップが必要な場合

TimesTenエラー8110(Connection not permitted. This store requires Master Catchup.)は、スタンバイ・データベースがアクティブ・データベースより先行し、レプリケーションが再開するにはマスター・キャッチアップが必要であることを示します。

アクティブ・スタンバイ・ペアでマスター・キャッチアップを使用している場合、スタンバイ・データベースがフェイルオーバーにより新しいアクティブ・データベースになる必要があります。古いアクティブ・データベースのリカバリができると、そのデータベースが新しいスタンバイ・データベースになります。リカバリができない場合は、古いアクティブ・データベースを破棄し、新しいアクティブ・データベースを複製することによって新しいスタンバイ・データベースを作成する必要があります。RETURN TWOSAFEが構成されている(マスター・キャッチアップに必要)場合の、アクティブ・データベースの障害からのリカバリの詳細は、「レプリケーションがRETURN TWOSAFEの場合」を参照してください。

RETURN TWOSAFEを使用して構成されているアクティブ・スタンバイ・ペアでは、トラップされたトランザクションが含まれる可能性があります。フェイルオーバー後新しいアクティブ・データベースに存在しないトランザクションが新しいスタンバイ・データベースに存在する場合に、トラップされたトランザクションが発生します。エラー16227(Standby store has replicated transactions not present on the active)はトラップされたトランザクションを示す一例です。トラップされたトランザクションの数は、手動リカバリ処理中に各データベースでレプリケート表のレコード数をチェックすることによって確認できます。たとえば、次のように文を入力します。

SELECT COUNT(*) FROM reptable;

トラップされたトランザクションがある場合、次のタスクを実行してリカバリを行います。

1. ttRepStateSet組込みプロシージャを使用して、スタンバイ・データベースの状態を'ACTIVE'に変更します。

2. 古いアクティブ・データベースを破棄します。

3. ttRepAdmin -duplicateを使用して、すべてのトランザクションを含む新しいアクティブ・データベースから新しいスタンバイ・データベースを作成します。「データベースの複製」を参照してください。

双方向の分散ワークロード・スキームの障害

それぞれがマスターおよびサブスクライバの両方として機能する、双方向にレプリケートされた複数のデータベースにワークロードを分散できます。マスター/サブスクライバ・データベースをリカバリする場合、レプリケーションの再起動時に、障害が発生したデータベースのログに問題が示される可能性があります。「双方向の分散ワークロード・スキーム」を参照してください。

分散ワークロード・スキームのデータベースで障害が発生し、影響を受けなかったデータベースに作業を切り替えた場合、影響を受けなかったデータベースには障害が発生したデータベースより新しい情報が反映されます。影響を受けなかったデータベースでログ障害しきい値に達する前に、障害が発生したシステムでレプリケーションが再起動された場合、両方のデータベースは、トランザクション・ログの内容を使用して互いの更新を試行します。この場合、障害が発生したデータベースのトランザクション・ログの古い更新が、影響を受けなかったシステムの新しいデータを上書きする可能性があります。

このような状況でリカバリするには、次の2つの方法があります。

- タイムスタンプによる競合解消ルール(第13章「レプリケーション競合の解消」を参照)がアプリケーションの一貫性の保証に十分な場合は、障害が発生したシステムを再起動し、障害が発生したデータベースの更新を影響を受けなかったデータベースに伝播することができます。この競合解消ルールによって、新しい更新が上書きされなくなります。

- 「障害が発生したデータベースのリカバリ」の説明に従って、障害が発生したデータベースを再作成します。データベースを再作成する必要がある場合、障害が発生したデータベースのログに保存されていた更新のうち、障害が発生していないデータベースで受信していない更新を識別またはリストアすることはできません。障害が発生していないデータベースが複数ある場合は、どのデータベースを使用して障害が発生したデータベースを再作成するかを選択する必要があります。障害が発生したデータベースを再作成する時点で、選択したデータベースが、障害が発生していない他のデータベースからの更新のすべてを受信していないこともあります。この場合、データベース間で相違が発生します。このような状況を避ける唯一の方法として、選択したデータベースから、障害が発生していない他のデータベースすべてを再作成する方法があります。

ネットワークの障害

一時的なネットワークの障害が発生した場合、レプリケーションを続行するために特定の処理を実行する必要はありません。通信中だったレプリケーション・エージェントは、数秒ごとに再接続を試行します。マスター・データベースがログ領域を使い果たす前にエージェントが再接続すると、レプリケーション・プロトコルによって、レプリケーション更新の見落しも重複もないことが確認されます。ネットワークを長期間使用できず、マスター・ログの障害しきい値を超えた場合は、「障害が発生したデータベースのリカバリ」の説明に従って、サブスクライバをリカバリする必要があります。

順序に関連した障害

キューされたログを再生してレプリケーションをリカバリできる場合、ネットワーク・リンクで障害が発生した後に処理を行う必要はありません。

ただし、障害が発生したホストが長時間にわたって停止した場合は、順序は障害のリカバリ中にロールバックされないため、ttRepAdmin -duplicateコマンドを使用して、障害の影響を受けなかったホストから障害が発生したホストのデータベースにトランザクションを再移入する必要があります。この場合、ttRepAdmin -duplicateコマンドによって、データベース間の順序定義のコピーが実行されます。

障害が発生したデータベースのリカバリ

データベースが双方向レプリケーション・スキームで構成されている場合、障害が発生したマスター・データベースはサブスクライバから自動的に最新の状態にされます。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。また、自動キャッチアップがアクティブ・スタンバイ・ペアのマスター・データベースのリカバリに適用されます。

再起動したデータベースをマスターのトランザクション・ログからリカバリして、レプリケーション・システムの他のデータベースとの一貫性を保つことができない場合、そのレプリケーション・ピアの1つからデータベースを再作成する必要があります。コマンドライン・ユーティリティまたはTimesTenユーティリティのC関数を使用します。「コマンドラインからの障害が発生したデータベースのリカバリ」および「Cプログラムからの障害が発生したデータベースのリカバリ」を参照してください。

注意:
障害が発生したデータベースのDSNを再作成する必要はありません。

サブスクライバで障害が発生した場合、RETURNサービスで構成された表に対するマスター・データベースでのコミットは、RETURNサービス・タイムアウト時間に達するまで実行されません。これを回避するには、RETURNサービスの障害およびリカバリ・ポリシーをレプリケーション・スキームに設定します(「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照)。RETURN RECEIPTサービスを使用している場合は、ALTER REPLICATIONを使用してNO RETURN属性を設定し、サブスクライバがリストアされ、最新情報を反映するまでRETURN RECEIPTを無効にすることもできます。反映した時点で、別のALTER REPLICATION文を実行してRETURN RECEIPTを再設定できます。

コマンドラインからの障害が発生したデータベースのリカバリ

データベースを完全にレプリケートする場合は、ttDestroyユーティリティを使用して、障害が発生したデータベースをメモリーから削除し、ttRepAdmin -duplicateを使用して、影響を受けなかったデータベースから再作成することができます。データベースにキャッシュ・グループが含まれている場合は、ttRepAdminの-keepCGオプションも使用する必要があります。「データベースの複製」を参照してください。

例15-2 障害が発生したデータベースのリカバリ

障害が発生したデータベースsubscriberdsをホストsystem1のマスターmasterdsからリカバリするには、次のように入力します。

> ttdestroy /tmp/subscriberds

> ttrepadmin -dsn subscriberds -duplicate -from masterds -host "system1" -uid ttuser

ttuserのパスワードを入力するよう求められます。

注意:
ttRepAdmin -duplicateは、同一のTimesTenリリースおよびパッチ・リリース間でのみサポートされます。メジャーおよびマイナーのリリース番号が同じである必要があります。

ttRepAdmin -duplicateを使用してデータベースを再作成した後、データベースに最初に接続すると、データベースがメモリーにリロードされます。大容量のデータベースの複製時にパフォーマンスを向上させるには、ttRepAdmin -ramloadオプションを使用して複製処理後もデータベースをメモリー内に保持して、リロード・ステップを回避します。

例15-3 データベースのリカバリ時におけるデータベースのメモリー内への保持

障害のあったデータベースsubscriberdsをホストsystem1のマスターmasterdsからリカバリし、データベースをメモリー内に保持して、複製処理の後でレプリケーションを再起動するには、次のように入力します。

> ttdestroy /tmp/subscriberds

> ttrepadmin -dsn subscriberds -duplicate -ramload -from masterds -host "system1"
-uid ttuser -setmasterrepstart

ttuserのパスワードを入力するよう求められます。

注意:
ttRepAdmin -duplicate -ramLoadオプションを使用してデータベースを複製した後、データベースのRAMポリシーは、ttAdmin -ramPolicyまたはttRamPolicy関数で明示的に再設定されるまでmanualとなります。

Cプログラムからの障害が発生したデータベースのリカバリ

TimesTenユーティリティ・ライブラリで提供されるC関数を使用して、障害が発生したデータベースをプログラムでリカバリできます。

データベースを完全にレプリケートする場合は、ttDestroyDataStore関数を使用して、障害が発生したデータベースを削除し、ttRepDuplicateEx関数を使用して、影響を受けなかったデータベースから再作成することができます。

例15-4 障害が発生したデータベースのリカバリおよび起動

ホストsystem1のマスターmasterdsから、ホストsystem2の障害が発生したデータベースsubscriberdsをリカバリおよび起動するには、次のように入力します。

int          rc;
ttutilhandle utilhandle;
ttrepduplicateexarg arg;
memset( &arg, 0, sizeof( arg ) );
arg.size = sizeof( ttrepduplicateexarg );
arg.flags = tt_repdup_repstart | tt_repdup_ramload;
arg.uid=ttuser;
arg.pwd=ttuser;
arg.localhost = "system2";
rc = ttdestroydatastore( utilhandle, "subscriberds", 30 );
rc = ttrepduplicateex( utilhandle, "dsn=subscriberds",
"masterds", "system1", &arg );

この例では、ttDestroyDataStore処理のタイムアウト時間は30秒です。ttRepDuplicateEx関数の最後のパラメータは、次の2つのフラグを含む引数構造になっています。

- 複製処理の完了後にsubscriberdsデータベースをstart状態に設定するTT_REPDUP_RESTART

- RAMポリシーをmanualに設定してメモリーにデータベースを保持するTT_REPDUP_RAMLOAD

注意:
ttRepDuplicateExでTT_REPDUP_RAMLOADフラグを使用すると、複製データベースのRAMポリシーは、ttRamPolicy関数またはttAdmin -ramPolicyで明示的に再設定されるまでmanualとなります。

TimesTen C言語ユーティリティ・ライブラリで提供される関数の完全なリストについては、『Oracle TimesTen In-Memory Database C開発者ガイド』のTimesTenユーティリティAPIに関する説明を参照してください。

非永続的データベースのリカバリ

双方向構成でTRANSMIT NONDURABLEオプションを指定してデータベースを構成する場合は、障害が発生したマスター・データベースをリカバリするために処理を行う必要はありません。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。

他のタイプの構成では、TRANSMIT NONDURABLEオプションで構成されたマスター・データベースで障害が発生した場合、ttRepAdmin -duplicateまたはttRepDuplicateExを使用して、最新のサブスクライバ・データベースからマスター・データベースを再作成する必要があります。アプリケーションで最初に複製処理を行わずに、マスター・データベースに再接続しようとすると、レプリケーション・エージェントによってデータベースはリカバリされますが、複製処理を行うように忠告するエラーが返されます。このエラーが発生しないようにするには、アプリケーションでForceConnect初期接続属性を1に設定して再接続する必要があります。

障害リカバリ・スクリプトの作成

障害を検出した後、クラスタ・マネージャは、例15-5の擬似コードで示されたプロシージャを効果的に実行するスクリプトを実行する必要があります。

例15-5 障害リカバリ擬似コード

Detect problem {
if (Master == unavailable) {
FailedDataDatabase = Master
FailedDSN = Master_DSN
SurvivorDatabase = Subscriber
switch users to SurvivorDatabase
}
else {
FailedDatabase = Subscriber
FailedDSN = Subscriber_DSN
SurvivorDatabase = Master
}
}
Fix problem....
If (Problem resolved) {
Get state for FailedDatabase
if (state == "failed") {
ttDestroy FailedDatabase
ttRepAdmin -dsn FailedDSN -duplicate
-from SurvivorDatabase -host SurvivorHost
-setMasterRepStart
-uid ttuser
-pwd ttuser
}
else {
ttAdmin -repStart FailedDSN
}
while (backlog != 0) {
wait
}
}

Switch users back to Master.

これは、マスターまたはサブスクライバのいずれかのデータベースに適用します。マスターで障害が発生すると、一部のトランザクションが失われる場合があります。

A Oracle ClusterwareのTimesTen構成属性

Oracle Clusterwareで管理されるTimesTenアクティブ・スタンバイ・ペアを設定するには、この章で説明する属性を使用します。これらの属性は、cluster.oracle.iniファイルに指定します。ttCWAdminユーティリティは、cluster.oracle.iniファイルの情報に基づいて、アクティブ・スタンバイ・ペアを作成および管理します。

属性のリスト

この項では、次の各表にOracle ClusterwareのTimesTen構成属性を示します。

- 表A-1「必要な属性」

- 表A-2「場合によって必要な属性」

- 表A-3「オプションの属性」

表A-1 必要な属性

名前

説明

デフォルト

MasterHosts

アクティブ・スタンバイ・ペアのスキームでマスター・データベースを配置できるホスト名のリストを指定します。

なし

表A-2 場合によって必要な属性

名前

説明

デフォルト

AppCheckCmd

Oracle Clusterwareで管理されるTimesTenアプリケーションのステータスを確認するためのコマンドライン。

なし

AppName

Oracle Clusterwareで管理されるTimesTenアプリケーションの名前。

なし

AppStartCmd

Oracle Clusterwareで管理されるTimesTenアプリケーションを起動するためのコマンドライン。

なし

AppStopCmd

Oracle Clusterwareで管理されるTimesTenアプリケーションを停止するためのコマンドライン。

なし

AppType

アプリケーションのリンク先となるデータベース。

なし

CacheConnect

アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートするかどうかを指定します。

N

GridPort

キャッシュ・グリッドのメンバーになっているアクティブ・スタンバイ・ペアのアクティブ・データベース用およびスタンバイ・データベース用に、キャッシュ・グリッド・エージェントが使用するポート番号のリストを指定します。

なし

MasterVIP

マスター・データベースに関連付けることができる2つの仮想IPアドレスのリスト。

なし

RemoteSubscriberHosts

クラスタに含まれないサブスクライバ・ホストのリスト。

なし

RepBackupDir

アクティブ・データベースのバックアップ先となるディレクトリ。

なし

SubscriberHosts

サブスクライバ・データベースを配置できるホスト名のリスト。

なし

SubscriberVIP

サブスクライバ・データベースに関連付けることができる仮想IPアドレスのリスト。

なし

VIPInterface

各ホストで仮想IPアドレスに対して使用されるパブリック・ネットワーク・アダプタの名前。

なし

VIPNetMask

仮想IPアドレスのネットマスク。

なし

表A-3 オプションの属性

名前

説明

デフォルト

AppFailoverDelay

障害が検出された後で、アプリケーションを監視するOracle Clusterwareリソースがフェイルオーバーを実行する前に待機する時間(秒)。

0

AppFailureInterval

TimesTenアプリケーションがOracle ClusterwareのFAILURE_THRESHOLDリソース属性で指定された障害の数を超えた場合に、Oracle Clusterwareがアプリケーションを停止するまでの間隔(秒)。

60

AppFailureThreshold

Oracle Clusterwareがアプリケーションのアクション・スクリプトに許容する、10×AppScriptTimeout間隔でのOracle Clusterwareの連続リソース障害の数。デフォルトは2です。

2

AppRestartAttempts

Oracle Clusterwareが、TimesTenアプリケーションを移動する前に、現在のホスト上でアプリケーションの再起動を試行する回数。

100

AppScriptTimeout

TimesTenアプリケーション・コンテナが特定のアプリケーションに対するアクション・スクリプトの完了を待機する時間(秒)。

60

AppUptimeThreshold

Oracle ClusterwareがTimesTenアプリケーションをステーブルとみなすための、アプリケーションの稼働時間の長さ(秒)。

アプリケーションがこのしきい値内に失敗した場合は、正常な起動に失敗したとみなされ、別のホスト上で再起動されます。アプリケーションがこのしきい値を超えてアクティブな場合は、安定した状態であるとみなされます。安定した状態の後で停止すると、アプリケーションは同じホストで再起動されます。

600

AutoRecover

両方のマスター・データベースで障害が発生した場合にアクティブ・データベースをバックアップから自動的にリカバリするかどうかを指定します。

しない

ClusterType

デフォルトの「Active」にします。TimesTenではこれが唯一の有効な値です。

Active

DatabaseFailoverDelay

障害の発生後、データベースを新しいホストに移行する前にOracle Clusterwareが待機する時間(秒)。

60

FailureThreshold

アクティブ・スタンバイ・ペアで障害が発生したとみなされ、自動バックアップを使用してスペア・ホストで新しいアクティブ・スタンバイ・ペアが作成されるまでに10秒間許容される、Oracle Clusterwareで管理される連続リソース障害の数。

2

GridIPConf

グリッドに使用するIPアドレスを識別します。

- Private: これはTimesTenで推奨されるデフォルト値です。Oracle Clusterwareクラスタ構成で構成されるプライベートIPアドレスを使用します。

- Public: Oracle Clusterwareクラスタ構成で構成されるパブリックIPアドレスを使用します。

Private

MasterStoreAttribute

レプリケーション・スキームのマスター・データベースに関するすべてのSTORE属性のリスト。

なし

RepBackupPeriod

アクティブ・データベースのバックアップ間隔(秒)。

0(無効)

RepDDL

アクティブ・スタンバイ・ペアのスキームを表すSQL文。

なし

RepFullBackupCycle

次の全体バックアップまでに実行される増分バックアップの回数。

5

ReturnServiceAttribute

アクティブ・スタンバイ・ペアのスキームのRETURNサービス属性。

なし

SubscriberStoreAttribute

レプリケーション・スキームのサブスクライバ・データベースに関するすべてのSTORE属性のリスト。

なし

TimesTenScriptTimeout

障害が発生したとみなされてモニター・プロセスが起動される前にOracle Clusterwareが待機する時間(秒)。

1209600秒(14日間)

必要な属性

この属性は、cluster.oracle.iniファイルで各DSNに対して指定する必要があります。デフォルト値はありません。

必要な属性のリストは、表A-1「必要な属性」を参照してください。属性の詳細は、この項を参照してください。

MasterHosts

この属性は、アクティブ・スタンバイ・ペアのマスター・データベースを配置できるホスト名のリストを指定します。クラスタの初期起動時のアクティブ・マスター・データベースおよびスタンバイ・マスター・データベースはそれぞれ、リストに最初に指定されているホストおよび2番目に指定されているホストに配置されます。この指定順序には次の例外があります。

- クラスタが停止したときにアクティブ・マスター・データベースおよびスタンバイ・マスター・データベースが特定のノードにすでに存在していた場合、クラスタを再起動すると、アクティブ・マスター・データベースおよびスタンバイ・マスター・データベースはそのままそのホストに配置されます。

- クラスタを起動したとき、既存の唯一のデータベースがMasterHostsに最初に指定されていないホスト上に存在していた場合、アクティブ・マスター・データベースはそのホスト上に構成されます。MasterHostsにリストされている最初のホストは、スタンバイ・マスター・データベースになります。

3つ以上のホストを高度な可用性のマスター・ホストとして指定できます。詳細は、「高度な可用性の構成」を参照してください。

2つのマスター・ホストのみが構成されている場合、いずれの仮想IPアドレスも定義しないでください。3つ以上のマスター・ホストがリストされている場合、TimesTenの内部処理用に仮想IPアドレスを定義して、アクティブ・データベースまたはスタンバイ・データベースが配置されているホストの1つでリカバリ不能な障害が発生した場合に、レプリケーションを管理できるようにする必要があります。詳細は、「高度な可用性の構成」を参照してください。

設定

MasterHostsは次のように設定します。

属性の表記方法

設定

MasterHosts

ホスト名のカンマ区切りのリスト。指定する最初のホストは、アクティブ・スタンバイ・ペアの初期アクティブ・マスターになります。指定する2つ目のホストは、アクティブ・スタンバイ・ペアの初期スタンバイ・マスターになります。
定義されるホストは、SubscriberHosts属性で定義されているホストとは異なるホストにする必要があります。

場合によって必要な属性

これらの属性は、Oracle Clusterwareの構成に応じて必要となる場合があります。デフォルト値はありません。場合によって必要な属性のリストは、表A-2「場合によって必要な属性」を参照し、属性の詳細は、この項を参照してください。

AppCheckCmd

この属性は、AppNameで指定されたTimesTenアプリケーションのステータスを確認するユーザー指定のスクリプトまたはプログラムを実行するためのコマンドライン全体を指定します。実行可能ファイルのフルパス名を含める必要があります。パス名に空白が含まれている場合、パス名を二重引用符で囲みます。

コマンドは、アプリケーションが実行されている場合は0(ゼロ)、アプリケーションが実行されていない場合はゼロ以外の数値を返すように記述する必要があります。0(ゼロ)以外の値が検出されると、Oracle Clusterwareは、障害が発生したアプリケーションをリカバリするためのアクションを実行します。

設定

AppCheckCmdは次のように設定します。

属性の表記方法

設定

AppCheckCmd

AppNameで指定されたアプリケーションのステータスを確認するアプリケーションを実行するためのコマンドラインを表す文字列。

例

AppCheckCmd=/mycluster/reader/app_check.sh check

AppFailureInterval

この属性は、TimesTenアプリケーションがOracle ClusterwareのFAILURE_THRESHOLDリソース属性で指定された障害の数を超えた場合に、Oracle Clusterwareがアプリケーションを停止するまでの間隔(秒)を設定します。値が0(ゼロ)の場合、障害の追跡は無効になります。

Oracle ClusterwareのFAILURE_THRESHOLDリソース属性の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

設定

AppFailureIntervalは次のように設定します。

属性の表記方法

設定

AppFailureInterval

Oracle Clusterwareがアプリケーションを停止するまでの間隔(秒)。デフォルトは60です。次に例を示します。
AppFailureInterval=120

AppName

この属性は、Oracle Clusterwareで管理されるTimesTenアプリケーションの名前を指定します。Oracle Clusterwareでは、このアプリケーション名を使用して、対応するリソースを指定します。cluster.oracle.iniファイルでアプリケーションについて記述する場合、この属性から始める必要があります。

設定

AppNameは次のように設定します。

属性の表記方法

設定

AppName

アプリケーションの名前を表す文字列。たとえば、testAppなどです。

AppRestartAttempts

この属性は、Oracle Clusterwareが、TimesTenアプリケーションを別のホストに移動する前に、現在のホスト上でアプリケーションの再起動を試行する回数を指定します。

設定

AppRestartAttemptsは次のように設定します。

属性の表記方法

設定

AppRestartAttempts

再起動回数。デフォルトは100です。次に例を示します。

AppRestartAttempts=30

AppStartCmd

この属性は、AppNameで指定されたTimesTenアプリケーションを起動するコマンドラインを指定します。実行可能ファイルのフルパス名を含める必要があります。パス名に空白が含まれている場合、パス名を二重引用符で囲みます。

設定

AppStartCmdは次のように設定します。

属性の表記方法

設定

AppStartCmd

AppNameで指定されたアプリケーションを起動するためのコマンドラインを表す文字列。

例

AppCheckCmd=/mycluster/reader/app_start.sh start

AppStopCmd

この属性は、AppNameで指定されたTimesTenアプリケーションを停止するコマンドラインを指定します。実行可能ファイルのフルパス名を含める必要があります。パス名に空白が含まれている場合、パス名を二重引用符で囲みます。

設定

AppStopCmdは次のように設定します。

属性の表記方法

設定

AppStopCmd

AppNameで指定されたアプリケーションを停止するためのコマンドラインを表す文字列。

例

AppCheckCmd=/mycluster/reader/app_stop.sh stop

AppType

この属性は、TimesTenアプリケーションを起動する必要のあるホストを決定します。

設定

AppTypeは次のように設定します。

属性の表記方法

設定

AppType

Active: アプリケーションは、アクティブ・スタンバイ・ペアのアクティブ・データベースで起動します。
Standby: アプリケーションは、アクティブ・スタンバイ・ペアのスタンバイ・データベースで起動します。スタンバイ・データベースが停止している場合、そのデータベースをリンク先とするアプリケーションは、新しいスタンバイ・データベースが稼働するまでアクティブ・データベースに移行します。

DualMaster: アプリケーションは、アクティブ・ホストとスタンバイ・ホストの両方で起動します。アクティブ・ホストでアプリケーションが停止すると、そのホスト上のアクティブ・データベースおよびその他すべてのアプリケーションがスタンバイ・ホストにフェイルオーバーします。

Subscriber: アプリケーションはすべてのサブスクライバ・データベースで起動します。

Subscriber[index]: アプリケーションは、いずれかのサブスクライバ・データベースで起動します。使用されるサブスクライバ・ホストは、SubscriberHosts属性またはSubscriberVIP属性(仮想IPアドレスが使用されているかどうかによる)でindexの位置に指定されているホストです。サブスクライバが1つの場合、Subscriber[1]を使用します。indexが指定されていない場合、TimesTenでは、アプリケーションはすべてのサブスクライバにリンクするとみなされます。

AppUptimeThreshold

この属性は、Oracle ClusterwareのUPTIME_THRESHOLDリソース属性の値を指定します。この値は、Oracle ClusterwareがTimesTenアプリケーションをステーブルとみなすための、アプリケーションの稼働時間の長さ(秒)を表します。

UPTIME_THRESHOLDの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

属性の表記方法

設定

AppUptimeThreshold

秒数です。デフォルトは600です。次に例を示します。

AppUptimeThreshold=60

CacheConnect

アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートする場合、この属性をYに設定します。Yを指定すると、Oracle ClusterwareではTimesTenがOracle Databaseに接続しているとみなされ、Oracleパスワードを入力するよう求められます。

設定

CacheConnectは次のように設定します。

属性の表記方法

設定

CacheConnect

値はY(はい)またはN(いいえ)です。デフォルトはNです。

GridPort

この属性は、キャッシュ・グリッドのメンバーになっているアクティブ・スタンバイ・ペアのアクティブ・データベース用およびスタンバイ・データベース用に、キャッシュ・グリッド・エージェントが使用するポート番号のリストを指定します。ポート番号はカンマで区切ります。グローバル・キャッシュ・グループが存在する場合、この属性は必須パラメータです。

設定

GridPortは次のように設定します。

属性の表記方法

設定

GridPort

2つのポート番号をカンマで区切ります。次に例を示します。
GridPort=16101,16102

MasterVIP

この属性は、アクティブ・スタンバイ・ペアで使用される2つのマスター・ホストに関連付けられる2つの仮想IP (VIP)アドレスを定義します。高度な可用性用に3つ以上のマスター・ホストを構成する場合、2つのVIPアドレスも定義する必要があります。ただし、これらのVIPアドレスは、マスター・ホストの1つでリカバリ不能な障害が発生した場合にアクティブ・スタンバイ・ペアを管理するためにのみ、TimesTenの内部処理で使用される必要があります。これらのVIPアドレスがいずれかのユーザーまたはアプリケーションにより使用されると、エラーが発生することがあります。詳細は、「高度な可用性の構成」を参照してください。

設定

MasterVIPは次のように設定します。

属性の表記方法

設定

MasterVIP

マスター・ホストの2つの仮想IPアドレスを指定するカンマ区切りのリスト。

RemoteSubscriberHosts

この属性は、アクティブ・スタンバイ・ペアのレプリケーション・スキームに含まれていながらOracle Clusterwareでは管理されないサブスクライバ・ホストのリストを指定します。

設定

RemoteSubscriberHostsは次のように設定します。

属性の表記方法

設定

RemoteSubscriberHosts

Oracle Clusterwareで管理されないサブスクライバ・ホストを指定するカンマ区切りのリスト。

RepBackupDir

この属性は、アクティブ・データベースのバックアップが保存されるディレクトリを示します。クラスタのすべてのノードがアクセスできる、共有ファイル・システム内のディレクトリを指定する必要があります。この属性は、RepBackupPeriodが0(ゼロ)以外の値に設定されている場合のみ必要です。

このディレクトリは、クラスタのすべてのホストによって共有されている必要があります。共有ストレージは、NFSまたはOCFS (Oracle Cluster File System)である必要があります。

バックアップを有効にする場合、Oracle Clusterwareのインストール・プロセスで共有記憶域にOCFSをインストールします。この共有記憶域をアクティブ・スタンバイ・ペアのバックアップに使用できます。

バックアップの制限については、「両方のマスター・ノードの永続的な障害からのリカバリ」と「アクティブ・スタンバイ・ペア・グリッド・メンバーの障害およびリカバリ」を参照してください。

設定

RepBackupDirは次のように設定します。

属性の表記方法

設定

RepbackupDir

レプリケーション・バックアップ・ディレクトリのフルパス名。

SubscriberHosts

サブスクライバ・データベースを配置できるホスト名のリストを指定します。サブスクライバを持つアクティブ・スタンバイ・ペアが構成されている場合、この属性が必要です。デフォルト値はありません。定義されているサブスクライバの数以上のホスト名を指定する必要があります。

サブスクライバ用に高度な可用性を使用している場合、リカバリ不能なエラーが発生する可能性のある任意のサブスクライバ・ホストを置き換えるためにインスタンス化できる追加ホストを定義します。また、高度な可用性を使用している場合、現在使用されているすべてのサブスクライバ用にVIPアドレスを構成します。たとえば、3つのサブスクライバと高度な可用性用に使用できる2つの追加ホストが存在する場合、3つのVIPアドレスを定義する必要があります。詳細は、「SubscriberVIP」を参照してください。

設定

SubscriberHostsは次のように設定します。

属性の表記方法

設定

SubscriberHosts

ホスト名のカンマ区切りのリスト。
定義されるホストは、MasterHosts属性で定義されているホストとは異なるホストにする必要があります。

高度な可用性を使用していない場合、定義されているホストの順序を使用して、AppTypeがSubscriber[index]のアプリケーションのうちで、どのアプリケーションが特定のホストのサブスクライバ・データベースに接続するかが決定されます。また、指定するサブスクライバ・ホストの数は、アクティブ・スタンバイ・ペアに含まれるサブスクライバの数になります。1つのサブスクライバ・ホストに対して1つのサブスクライバが起動されます。

高度な可用性を使用している場合、リストされている最初のホストは、サブスクライバ・ホスト用に使用されます。後半で定義されているホストは、高度な可用性用に使用されます。

SubscriberVIP

この属性は、高度な可用性用に使用されるサブスクライバ・ホストに関連付けられる仮想IP (VIP)アドレスのリストを構成します。高度な可用性用にサブスクライバの数よりも多くのホストを構成する場合、サブスクライバごとに1つのVIPアドレスも定義する必要があります。ただし、これらのVIPアドレスは、サブスクライバ・ホストの1つでリカバリ不能な障害が発生した場合にレプリケーションを管理するためにのみ、TimesTenの内部処理で使用される必要があります。これらのVIPアドレスがいずれかのユーザーまたはアプリケーションにより使用されると、エラーが発生することがあります。詳細は、「高度な可用性の構成」を参照してください。

設定

SubscriberVIPは次のように設定します。

属性の表記方法

設定

SubscriberVIP

1つ以上の仮想IPアドレス。サブスクライバの数と同じ数のVIPアドレスを定義する必要があります。
サブスクライバの仮想IPアドレスの順序を使用して、AppTypeがSubscriber[index]のアプリケーションのうちで、どのアプリケーションが特定のサブスクライバのデータベースに接続するかが決定されます。

VIPInterface

この属性は、各ホストで仮想IPアドレスに対して使用されるパブリック・ネットワーク・アダプタの名前です。仮想IPアドレスを使用する場合、この属性が必要です。

設定

VIPInterfaceは次のように設定します。

属性の表記方法

設定

VIPInterface

ネットワーク・アダプタを表す文字列。

VIPNetMask

この属性は、仮想IPアドレスのネットマスクです。仮想IPアドレスを使用する場合、この属性が必要です。

設定

VIPNetMaskは次のように設定します。

属性の表記方法

設定

VIPNetMask

IPのネットマスク。

オプションの属性

これらの属性はオプションで、デフォルト値はありません。オプションの属性のリストは、表A-3「オプションの属性」を参照し、属性の詳細は、この項を参照してください。

AppFailoverDelay

この属性は、障害が検出された後で、アプリケーションを監視しているプロセスがフェイルオーバーを実行する前に待機する時間(秒)を指定します。デフォルトは0(ゼロ)です。

設定

AppFailoverDelayは次のように設定します。

属性の表記方法

設定

AppFailoverDelay

障害が検出された後で、アプリケーションを監視しているプロセスがフェイルオーバーを実行する前に待機する時間を表す整数(秒)。デフォルトは0(ゼロ)です。

AppFailureThreshold

この属性は、Oracle Clusterwareで許容される、アプリケーションのアクション・スクリプトで10×AppScriptTimeoutの時間内に発生した同時障害の数を指定します。デフォルトは2です。

設定

AppFailureThresholdは次のように設定します。

属性の表記方法

設定

AppFailureThreshold

Oracle Clusterwareで許容される、アプリケーションのアクション・スクリプトで発生した同時障害の数を示す整数。デフォルトは2です。

AppScriptTimeout

この属性は、TimesTenアプリケーション・モニター・プロセスが特定のアプリケーションに対する起動アクション・スクリプトおよび停止アクション・スクリプトの完了を待機する時間(秒)を示します。チェック・アクション・スクリプトには構成不可の5秒間のタイムアウト値が適用されるため、この属性の影響を受けません。

設定

AppScriptTimeoutは次のように設定します。

属性の表記方法

設定

AppScriptTimeout

TimesTenアプリケーション・コンテナが特定のアプリケーションに対する起動アクション・スクリプトおよび停止アクション・スクリプトの完了を待機する時間を表す整数(秒)。デフォルトは60です。

AutoRecover

両方のマスター・データベースで障害が発生した場合にOracle Clusterwareによってアクティブ・データベースがバックアップから自動的にリカバリされるかどうかを指定します。

リカバリを自動化しない場合(AutoRecover=N)、ttCWAdmin -restoreコマンドを使用してデータベースをリカバリできます。

構成でキャッシュ・グループを使用している場合、またはキャッシュ・グリッドが構成されている場合、AutoRecoverは使用できません。

設定

AutoRecoverは次のように設定します。

属性の表記方法

設定

AutoRecover

Y: 両方のマスター・データベースで障害が発生した場合、アクティブ・データベースは、Oracle Clusterwareによってバックアップから自動的にリカバリされます。
N: 両方のマスター・データベースで障害が発生した場合、手動でリカバリを行う必要があります。これはデフォルトです。

DatabaseFailoverDelay

この属性は、障害の発生後、データベースを新しいホストに移行する前にOracle Clusterwareが待機する時間(秒)を指定します。待機時間中にデータベースが起動した場合、データベースは再配置されません。この属性は、高度な可用性が構成されている場合に使用されます。デフォルトは60秒です。

設定

DatabaseFailoverDelayは次のように設定します。

属性の表記方法

設定

DatabaseFailoverDelay

障害の発生後、データベースを新しいホストに移行する前にOracle Clusterwareが待機する時間を表す整数(秒)。デフォルトは60です。

FailureThreshold

この属性は、アクティブ・スタンバイ・ペアで障害が発生したとみなされ、自動バックアップを使用してスペア・ホストで新しいアクティブ・スタンバイ・ペアが作成されるまでに10秒間許容される、Oracle Clusterwareで管理される連続リソース障害の数を指定します。スペア・ノードは、仮想IPアドレスを使用する場合のみオプションです。

Oracle Clusterwareは、単一の障害が発生すると、アクティブ・スタンバイ・ペアの複製を実行しようとし、複数の障害が発生した場合は、リストアを実行しようとします。

1つ以上の仮想IPアドレスが構成されている場合のみスペア・ノードが構成されるため、この値は基本的な可用性では無視されます。また、高度な可用性(1つ以上の仮想IPアドレスの構成を含む)の使用時にRepBackupPeriodが0に設定されているときも無視されます。

注意:
この属性の設定に関係なく、TimesTenで許容されるバックアップ・リソースの障害は1つのみです。

設定

FailureThresholdは次のように設定します。

属性の表記方法

設定

FailureThreshold

アクティブ・スタンバイ・ペアで障害が発生したとみなされ、自動バックアップを使用してスペア・ホストで新しいアクティブ・スタンバイ・ペアが作成されるまでに10秒間許容される、Oracle Clusterwareで管理される連続リソース障害の数を表す整数。デフォルトは2です。

MasterStoreAttribute

この属性は、レプリケーション・スキームのマスター・データベースに関するSTORE属性を示します。STORE属性は、アクティブとスタンバイの両方のデータベースに適用されます。STORE属性の詳細は、「STORE属性の設定」を参照してください。

RepDDLが構成されている場合、この属性は必要ありません。

この属性が設定されていない場合、STORE属性はデフォルト値になります。

設定

MasterStoreAttributeは次のように設定します。

属性の表記方法

設定

MasterStoreAttribute

レプリケーション・スキームのマスター・データベースに関するSTORE属性。PORT 20000 TIMEOUT 60など。

RepBackupPeriod

この属性は、アクティブ・データベースのバックアップ間隔(秒)を示します。この属性を0(ゼロ)より大きい値に設定する場合、RepBackupDirでバックアップ・ディレクトリも指定する必要があります。

バックアップの制限については、「両方のマスター・ノードの永続的な障害からのリカバリ」と「アクティブ・スタンバイ・ペア・グリッド・メンバーの障害およびリカバリ」を参照してください。

設定

RepBackupPeriodは次のように設定します。

属性の表記方法

設定

RepBackupPeriod

アクティブ・データベースのバックアップ間隔を表す整数(秒)。値が0(ゼロ)の場合は、バックアップ・プロセスが無効になります。デフォルトは0(ゼロ)です。

RepDDL

この属性は、アクティブ・スタンバイ・ペアを作成するSQL文を表します。この属性は、特殊な状況でのみ使用します。たとえば、アクティブ・スタンバイ・ペアから表および順序を除外する必要がある場合、RepDDLを指定する必要があります。

RepDDLを設定する場合、次の属性は設定しません。

- ReturnServiceAttribute

- MasterStoreAttribute

- SubscriberStoreAttribute

このSQL文では、データベース・ファイル名の接頭辞は、<DSN>マクロに置き換えます。また、ホスト名のかわりに、<MASTERHOST[1]>、<MASTERHOST[2]>および<SUBSCRIBERHOST[n]>マクロを使用します。

RepDDLのデフォルト値はありません。

この例では、RepDDLで2つのマスター・データベースが設定されます。

RepDDL=CREATE ACTIVE STANDBY PAIR <DSN> ON <MASTERHOST[1]>, <DSN> ON <MASTERHOST[2]>

他の例は、「RepDDL属性の使用」を参照してください。

レプリケーション・エージェントのトランスミッタはOracle Clusterwareによって使用されるプライベート・ネットワーク・インタフェースおよびパブリック・ネットワーク・インタフェースを自動的に取得するため、通常はRepDDLにROUTE句を設定する必要はありません。ただし、Oracle Clusterwareで管理されていないレプリケーション・スキームのネットワーク接続がホストに存在する場合は、RepDDLにROUTE句を含める必要があります。

この属性が使用されている場合、各STORE句の後に、次のような疑似ホスト名を続ける必要があります。

- ActiveHost

- ActiveVIP

- StandbyHost

- StandbyVIP

- SubscriberHost

- SubscriberVIP

設定

RepDDLは次のように設定します。

属性の表記方法

設定

RepDDL

CREATE ACTIVE STANDBY PAIR文を発行して、アクティブ・スタンバイ・ペアを作成します。デフォルト値はありません。

RepFullBackupCycle

この属性は、次の全体バックアップまでに実行される増分バックアップの回数を指定します。増分バックアップの数は、共有記憶域の容量によって異なります。

この属性を設定すると、パフォーマンスが低下することがあります。記憶域の容量とバックアップの所要時間の間にはトレードオフがあります。増分バックアップは、全体バックアップよりもはるかに高速に実行できます。ただし、全体バックアップが実行されるまで記憶域の消費量は増え続けます。

バックアップの制限については、「両方のマスター・ノードの永続的な障害からのリカバリ」と「アクティブ・スタンバイ・ペア・グリッド・メンバーの障害およびリカバリ」を参照してください。

設定

RepFullBackupCycleは次のように設定します。

属性の表記方法

設定

RepFullBackupCycle

次の全体バックアップまでに実行される増分バックアップの回数を表す整数値。デフォルトは5です。

ReturnServiceAttribute

この属性は、アクティブ・スタンバイ・ペアのレプリケーション・スキームにRETURNサービスを指定します。「RETURNサービスの使用」を参照してください。

この属性に値が指定されていない場合、アクティブ・スタンバイ・ペアはRETURNサービスなしで構成されます。

設定

ReturnServiceAttributeは次のように設定します。

属性の表記方法

設定

ReturnServiceAttribute

RETURNサービスのタイプ。RETURN RECEIPTなど。デフォルト値はありません。

SubscriberStoreAttribute

この属性は、レプリケーション・スキームのサブスクライバ・データベースに関するSTORE属性を示します。STORE属性は、すべてのサブスクライバに適用されます。STORE属性の詳細は、「STORE属性の設定」を参照してください。

RepDDLが存在する場合、この属性は必要ありません。

この属性が設定されていない場合、STORE属性はデフォルト値になります。

設定

SubscriberStoreAttributeは次のように設定します。

属性の表記方法

設定

SubscriberStoreAttribute

サブスクライバ・データベースのSTORE属性とその値のリスト。
PORT 20000 TIMEOUT 60など。

TimesTenScriptTimeout

この属性は、障害が発生したとみなされてモニター・プロセスが起動される前にOracle Clusterwareが待機する時間(秒)を指定します。

アクション・スクリプトによってアクティブ・データベースが複製されるまでに長時間かかる場合があるため、値を数時間に設定することをお薦めします。デフォルトは1209600秒(14日)です。

設定

TimesTenScriptTimeoutは次のように設定します。

属性の表記方法

設定

TimesTenScriptTimeout

障害が発生したとみなされてモニター・プロセスが起動される前にOracle Clusterwareが待機する時間を表す整数(秒)。デフォルトは1209600秒(14日)です。

索引
A B C D E F G H I L M N O P R S T U V W

A

アクティブ・マスター

スタンバイへの変更, 5.6

二重のアクティブ・マスターの検出, 5.7

二重の障害からのリカバリ, 5.4

アクティブ・スタンバイ・ペア, 3.13, 7.1

表の列の追加または削除, 7.1

クラスタへのホストの追加, 8.6.3.1

サブスクライバの追加または削除, 7.2

キャッシュ・グループの追加または削除, 7.2

順序およびキャッシュ・グループの追加, 7.2

変更, 7.2

PORTまたはTIMEOUT接続属性の変更, 7.2

ネットワーク・インタフェースの構成, 3.10, 4.3.3

索引の作成または削除, 7.1

シノニムの作成または削除, 7.1

定義, 1.5.1

二重のアクティブ・マスターの検出, 5.7

障害時リカバリ, 6.11

順序およびキャッシュ・グループの削除, 7.2

DSN, 3.4

変更例, 7.2.1

フェイルバック, 5.2.2, 6.5.2

概要, 1.5.1

マスターでの二重の障害後のリカバリ, 5.4

アクティブ・マスターのリカバリ, 5.2

グローバルAWTキャッシュ・グループのレプリケート, 6.3

ローカルの読取り専用キャッシュ・グループのレプリケート, 6.2

マテリアライズド・ビューのレプリケート, 3.14

順序のレプリケート, 3.15

制限, 3.3

RETURNサービス, 3.8, 4.1

役割の入替え, 5.6

設定, 5.1

状態, 3.1

SUBSCRIBER句, 3.7

サブスクライバの障害, 5.5

キャッシュ・グループが構成されたアクティブ・スタンバイ・ペア

二重の障害からのリカバリ, 6.7

アクティブ・マスターのリカバリ, 6.5

サブスクライバの障害, 6.8

ADD ELEMENT句

DATASTORE, 10.1.3

ADMIN権限, 3.6, 9.2 エージング

レプリケーション, 1.9

ALTER ELEMENT句, 10.1.1 ALTER REPLICATION文

使用, 10.1

ALTER REPLICATION文, 9.5.3 ALTER TABLE文

レプリケーション, 10.2

ALTER USER文, 10.1 AppCheckCmd Clusterware属性, A.1 AppFailoverDelay Clusterware属性, A.1 AppFailureInterval属性

Oracle Clusterware, A.1

AppFailureThreshold Clusterware属性, A.1 アプリケーション・フェイルオーバー

Oracle Clusterware, 8.2.5

AppName Clusterware属性, A.1 AppRestartAttempts属性

Oracle Clusterware, A.1

AppScriptTimeout Clusterware属性, A.1 AppStartCmd Clusterware属性, A.1 AppStopCmd Clusterware属性, A.1 AppType Clusterware属性, A.1 AppUptimeThreshold属性

Oracle Clusterware, A.1

ASYNCHRONOUS WRITETHROUGHキャッシュ・グループ

Oracle Databaseへの伝播, 1.6.2

レプリケーション, 1.6.1

属性, 接続

必須, 11.1.2

自動コミット・モード

RETURN RECEIPT BY REQUEST, 4.1.3

RETURN TWOSAFE, 4.1.4

RETURN TWOSAFE BY REQUEST, 4.1.5

自動キャッチアップ, 15.2.3 自動クライアント・フェイルオーバー, 3.11, 8.1 AutoRecover Clusterware属性, A.1 AWTキャッシュ・グループ

Oracle Databaseへの伝播, 1.6.2

レプリケーション, 1.6.1, 6.3

AWTキャッシュ・グループ

パラレル・スレッド, 11.1.3.1

B

双方向の一般ワークロード

構文の例, 9.11.6

更新の競合, 9.11.6

双方向レプリケーション・スキーム

リカバリ, 9.1.1

RETURN TWOSAFEサービス, 4.1.4

双方向の分割ワークロード

構文の例, 9.11.5

ログ内のブックマーク, 11.1.4.3, 12.5

C

キャッシュ

キャッシュ管理ユーザー名またはパスワードの変更, 6.4

ユーザー名またはパスワードの変更, 6.4

キャッシュ・グリッド

アクティブ・スタンバイ・ペア, 6.3

Oracle Clusterwareを使用したキャッシュ・グループの追加, 8.4.3.1

クラスタの作成, 8.4.1

Oracle Clusterwareを使用したキャッシュ・グループの削除, 8.4.3.2

Oracle Clusterwareを使用した管理, 8.4

Oracle Clusterwareを使用したリカバリ, 8.4.2, 8.5.5.2

Oracle Clusterwareを使用したスキーマの変更, 8.4.3

キャッシュ・グループ

レプリケート, 1.6

グローバルAWTキャッシュ・グループのレプリケート, 6.3

読取り専用キャッシュ・グループのレプリケート, 6.2

ユーザー管理キャッシュ・グループのレプリケート, 6.1

CacheAWTParallelism接続属性, 11.1.3.1 CacheConnect Clusterware属性, 8.2.3, A.1 キャッチアップ機能

レプリケーション, 15.2.3

CHECK CONFLICTS句

例, 13.3.2

CREATE REPLICATION文, 9.6

クラシック・レプリケーション

高可用性, 9.1

クラシック・レプリケーション・スキーム, 9 クライアント・フェイルオーバー, 8.1

自動クライアント・フェイルオーバー, 3.11

クラスタ

仮想IPアドレス, 8.1

クラスタ・エージェント, 8.3.2 クラスタ・マネージャ

役割, 9.1.1

クラスタ・ステータス, 8.7 cluster.oracle.iniファイル, 8.1

高度な可用性, 8.2.2

高度な可用性, 1つのサブスクライバ, 8.2.2

sys.odbc.iniファイル, 8.2

アプリケーション・フェイルオーバー, 8.2.5, 8.2.5

属性の説明, A

両方のマスター・ノードの障害からの自動リカバリ, 8.2.6

基本的な可用性, 8.2.1

基本的な可用性, 1つのサブスクライバ, 8.2.1

キャッシュ・グリッド, 8.2.4

キャッシュ・グループ, 8.2.3

例, 8.2

表, キャッシュ・グループおよび順序の除外, 8.2.7

場所, 8.2

両方のマスター・ノードの障害からの手動リカバリ, 8.2.6

ルートの指定, 8.2.7

Clusterware, Oracle Clusterwareを参照 列

圧縮, 3.5, 9.3

COMPRESS TRAFFIC句

CREATE ACTIVE STANDBY PAIR文, 4.2.3

CREATE REPLICATION文, 4.2.3

圧縮

表の列, 3.5, 9.3

競合

レポーティング, 13.4

XMLドキュメント・タイプ定義, 13.5

解決方法, 13.1

更新ルール, 13.2

タイプ, 13.1 CONFLICT REPORTING句

CREATE REPLICATION文, 4.2.7, 4.2.7

データベースのコピー

権限, 3.2

マスター・データベースのコピー, 11.2 CREATE ACTIVE STANDBY PAIR文, 5.1, 6.2

構文, 3.6

表の作成または削除, 7.1 CREATE REPLICATION文, 9.5.3

DATASTORE要素の定義, 9.5.1

表要素の定義, 9.5.2

使用, 9.2

CREATE USER文, 10.1 crsctlコマンド

check crsコマンド, 8.3.1

Oracle Clusterwareステータスの検証, 8.3.1

crsTTディレクトリ, 8.1.2

D

データソース名, 9.2.2

データ型

サイズ制限, 3.5, 9.3

データベース

接続障害, 4.2.6

複製, 11.2

障害発生, 4.2.6

ForceConnect接続属性, 15.2.3

名前, 9.2.2

オブジェクト

アクティブ・スタンバイ・ペアからの除外, 3.12

一時, 3.3, 9.5.1 DatabaseCharacterSetデータ・ストア属性, 11.1.2 DatabaseFailoverDelay Clusterware属性, A.1 データベース

設定, 11.1.1

ログの管理, 11.1.4

リカバリ, 9.1.1

レプリケーションに必要な接続属性, 11.1.2

状態の設定, 11.6

DATASTORE要素, 9.5, 9.5.1

レプリケーション・スキームの追加, 10.1.3

マテリアライズド・ビュー, 9.5.5

非マテリアライズド・ビュー, 9.5.5

DDL文

レプリケーション, 7.1.1

DDLReplicationAction接続属性, はじめに, 7.1.1 DDLReplicationLevel接続属性, はじめに, 7.1.1 デフォルトの列値

変更, 10.2

DISABLE RETURN句

CREATE ACTIVE STANDBY PAIR文, 4.2.1.1.4

DISABLE RETURNポリシー, 4.2.1.1.4

アクティブ・スタンバイ・ペア, 4.2.1.1.4, 4.2.1.1.6

障害時リカバリ

AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペア, 6.11

障害時リカバリ・サブスクライバ

Oracle Clusterware, 8.3.13

分散ワークロード構成

リカバリの問題, 9.1.1

分散ワークロード・レプリケーション, 1.5.2.2.2 DNSサーバー

Windows, 4.3.4.2

DROP REPLICATION文, 2.2.6, 10.4 DROP USER文, 10.1 レプリケーション・スキームの削除, 2.2.6, 10.4 DSN

作成, 2.2.1, 11.1.1

アクティブ・スタンバイ・ペアの定義, 3.4

定義, 9.2.2

DualMaster

Oracle Clusterware, 8.2.5

データベースの複製

権限, 3.2

キャッシュ・グループ, 3.2

マスター・データベースの複製, 11.2 DURABLE COMMIT句

CREATE ACTIVE STANDBY PAIR文, 4.2.1.1.6

CREATE REPLICATION文, 4.2.1.1.6

DURABLE COMMITポリシー, 4.2.1.1.6

E

要素

DATASTORE, 9.5.1

定義, 1.1

ELEMENTの説明, 9.5 EXACT

表定義, 4.2.2

例

異なるサブスクライバへの表のレプリケーション, 9.11.3

EXCLUDE句

CREATE ACTIVE STANDBY PAIR文, 3.12

EXCLUDE SEQUENCE句

ALTER REPLICATION文, 10.1.3.2

CREATE REPLICATION文, 9.5.1

EXCLUDE TABLE句

ALTER REPLICATION文, 10.1.3.2

CREATE REPLICATION文, 9.5.1

F

フェイルバック, 5.2.2

アクティブ・スタンバイ・ペア, 6.5.2

障害が発生したデータベース

接続, 4.2.6

失敗の状態

レプリケーション, 11.6

フェイルオーバー, 3.11 フェイルオーバーおよびリカバリ

問題, 9.1.1

FAILTHRESHOLD属性, 15.2.1 FAILTHRESHOLD句

アクティブ・スタンバイ・ペア, 4.2.1.1.3

変更, 10.1.13

例, 9.11.2

CREATE ACTIVE STANDBY PAIR文, 4.2.6, 4.2.6

CREATE REPLICATION文, 4.2.1.1.3, 4.2.1.1.3, 4.2.6

サブスクライバの障害, 15.2.1

障害

RETURNサービス, 4.2.1.1.2

サブスクライバ, 5.5, 15.2.1

障害リカバリ・スクリプト, 15.5 障害しきい値

説明, 11.1.4.3

表示, 12.4.1

例, 9.11.2

サブスクライバの障害, 15.2.1

FailureThreshold Clusterware属性, A.1 ForceConnect接続属性, 15.2.3, 15.2.3, 15.4 外部キー

アクティブ・スタンバイ・ペア・レプリケーション, 3.13

クラシック・レプリケーション, 9.5.3

ON DELETE CASCADE

クラシック・レプリケーション, 9.5.3

レプリケーション, 1.8 全体レプリケーション, 1.5.2.1 完全なストア名

アクティブ・スタンバイ・ペア, 3.7

G

一般ワークロード

構文の例, 9.11.6

GRANT文, 10.1 GridPort Clusterware属性, 8.2.4, A.1

H

高可用性

クラシック・レプリケーション

設計, 9.1

ホスト

IPアドレス, 4.3

IPアドレス, 4.3.4

ローカル, 4.3

ホスト名

識別, 4.3.4, 9.5.1

hostnameコマンド, 9.5.1

I

INCLUDE句

CREATE ACTIVE STANDBY PAIR文, 3.12

INCLUDE SEQUENCE句

ALTER REPLICATION文, 10.1.3.1

CREATE REPLICATION文, 9.5.1

INCLUDE TABLE句

ALTER REPLICATION文, 10.1.3.1

CREATE REPLICATION文, 9.5.1

IPアドレス

レプリケーション, 4.3.4

L

LOB列

サイズ制限, 3.5, 9.3

LOCAL COMMIT ACTION句

アクティブ・スタンバイ・ペア, 4.2.1.1.7

LOCAL COMMIT ACTIONポリシー, 4.2.1.1.7 ログ

ブックマークの検出, 11.1.4.3, 12.5

管理, 11.1.4

サイズおよび永続性, 11.1.4.1

しきい値, 11.1.4.3

ログ順序番号, 12.5 LogBufMB接続属性, 11.1.4.3, 11.1.4.3 LogBufParallelism初期接続属性, 11.1.3.1, 11.1.3.2 LogFileSize接続属性, 11.1.4.3 ロギング, 11.1.4.3 ログ

サイズの設定, 11.1.4.3

LSN, 12.5

M

マスター・キャッチアップ, 15.2.3

マスター・データベース

定義, 9.2.2

MasterHosts Clusterware属性, A.1 MasterStoreAttribute Clusterware属性, A.1 MasterVIP Clusterware属性, A.1 マテリアライズド・ビュー

アクティブ・スタンバイ・ペア, 3.14

レプリケーション, 9.5.5

レプリケーションの監視, 12

N

ネットワーク

帯域幅, 4.3

構成, 4.3

WAN環境, 4.3, 4.3.2

ネットワーク構成

インタフェース, 4.3.3

レプリケーション, 4.3

ネットワーク・タイム・プロトコル, 「NTP」を参照 NO RETURN句

CREATE ACTIVE STANDBY PAIR文, 4.1.6

CREATE REPLICATION文, 4.1.6

NTP

クロック管理, 8.1.2

-xオプション, 8.1.2

NVARCHAR列

サイズ制限, 3.5, 9.3

NVARCHAR2列

サイズ制限, 3.5, 9.3

O

ocrConfigオプション, 8.3.3

ON DELETE CASCADE

クラシック・レプリケーション, 9.5.3

外部キー

アクティブ・スタンバイ・ペア, 3.13

ON DELETE CASCADE句

レプリケーション, 1.8

Oracle Cluster Registry

TimesTenクラスタでの構成, 8.3.3

Oracle Clusterware, 8

キャッシュ・グリッドへのキャッシュ・グループの追加, 8.4.3.1

Oracle Clusterwareによって管理されていないサブスクライバの追加, 8.6.5.3

クラスタへのアクティブ・スタンバイ・ペアの追加, 8.6.4.1

アクティブ・スタンバイ・ペアへのサブスクライバの追加, 8.6.5.1

表およびキャッシュ・グループの変更, 8.6.6

AppFailureInterval属性, A.1

アプリケーション障害, A.1

AppRestartAttempts, A.1

AppType=DualMaster, 8.2.5

AppUptimeThreshold, A.1

AppUptimeThreshold属性, A.1

自動リカバリ, 8.2.6

二重の障害からの自動リカバリ, 8.5.5.1

キャッシュ・グリッド, 8.2.4

キャッシュ・グリッドのリカバリ, 8.4.2, 8.5.5.2

キャッシュ管理ユーザー名またはパスワードの変更, 8.6.11

内部ユーザー名またはパスワードの変更, 8.6.11

cluster.oracle.iniおよびsys.odbc.iniファイル, 8.2

キャッシュ・グリッド・メンバーのクラスタの作成, 8.4.1

表およびキャッシュ・グループの作成または削除, 8.6.6

crsctl startコマンド, 8.5.7

crsctl stopコマンド, 8.5.7

crsTTディレクトリ, 8.1.2

キャッシュ・グリッドからのキャッシュ・グループの削除, 8.4.3.2

両方のマスター・ノードの障害, 8.2.6

3つ以上のマスター・ホストの障害, 8.5.6

強制的なスイッチオーバー, 8.5.7

GridPort属性, 8.2.4

ホストのメンテナンス, 8.6.9

マシン・ルームのメンテナンス, 8.6.10

高度な可用性の場合の手動リカバリ, 8.5.5.3

基本的な可用性の場合の手動リカバリ, 8.5.5.4

メッセージ・ログ・ファイル, 8.7.2

別のホストへのデータベースの移動, 8.6.8

ネットワークのメンテナンス, 8.6.9

RAMポリシー, 8.6.12

Oracle Clusterwareによって管理されていないサブスクライバの再作成, 8.6.5.4

リカバリ・プロセス, 8.5.1

RETURN TWOSAFEでのリカバリ, 8.5.5.6

リモート障害時リカバリ・サブスクライバ, 8.3.13

クラスタからのアクティブ・スタンバイ・ペアの削除, 8.6.4.2

クラスタからのホストの削除, 8.6.3.2

アクティブ・スタンバイ・ペアからのサブスクライバの削除, 8.6.5.2

必要な権限, 8.1.1

制限されたコマンド, 8.1.3

ローリング・アップグレード, 8.6.1

ルーティング, 8.2.7

キャッシュ・グリッドでのスキーマの変更, 8.4.3

状態, 8.7

TimesTenデーモンの停止, 8.3.4

バックアップの記憶域, 8.2.6

Oracle Clusterwareによって管理されていないサブスクライバ, 8.3.14

アクティブとスタンバイの切替え, 8.6.7

TimesTenの高度なレベル, 8.1

TimesTenの基本的なレベル, 8.1

TimesTenクラスタ・エージェント, 8.3.4, 8.3.4

TimesTenデーモン・モニター, 8.3.4, 8.3.4

tmpディレクトリ, 8.1.2

ttDaemonAdmin, 8.3.4

TimesTenのアップグレード, 8.6.2

RepDDL属性の使用, 8.2.7

キャッシュ・グリッドの使用, 8.4

仮想IPアドレス, 8.1

Oracle Clusterware属性

AppCheckCmd, A.1

AppFailoverDelay, A.1

AppFailureThreshold, A.1

AppName, A.1

AppScriptTimeout, A.1

AppStartCmd, A.1

AppStopCmd, A.1

AppType, A.1

AutoRecover, A.1

CacheConnect, A.1

条件次第, A.1

DatabaseFailoverDelay, A.1

FailureThreshold, A.1

GridPort, A.1

MasterHosts, A.1

MasterStoreAttribute, A.1

MasterVIP, A.1

オプション, A.1, A.1

RemoteSubscriberHosts, A.1

RepBackupDir, A.1

RepBackupPeriod, A.1

RepDDL, 8.2.7, A.1

RepFullBackupCycle, A.1

必須, A.1, A.1

ReturnServiceAttribute, A.1

SubscriberHosts, A.1

SubscriberStoreAttribute, A.1

SubscriberVIP, A.1

TimesTenScriptTimeout, A.1

VIPInterface, A.1

VIPNetMask, A.1

所有者

レプリケーション・スキーム, 9.2.1

P

パラレル・レプリケーション, 11.1.3

属性, 11.1.2

自動, 11.1.3, 11.1.3.1

AWT, 11.1.3.1

DDL文, 11.1.3

DML文, 11.1.3

パーティション

表, 4.2.2

PassThrough接続属性

RETURN TWOSAFE, 4.1.4

RETURN TWOSAFE BY REQUEST, 4.1.5

pause状態

レプリケーション, 11.6

パフォーマンス

変更済の表, 14.2

評価ツール, 12.8

ロギングの属性, 11.1.4.3

レプリケーション, 14, 14.2

レプリケーション・スループット, 14.3

PL/SQLオブジェクト

アクティブ・スタンバイ・ペアでのレプリケート, 7.1.3

PL/SQLオブジェクト

レプリケーション, 10.1.2

PORT割当て

アクティブ・スタンバイ・ペア, 4.2.4

PORT属性

CREATE ACTIVE STANDBY PAIR文, 4.2.4

CREATE REPLICATION文, 4.2.4

ポート

動的, 4.2.4

静的, 4.2.4

権限

レプリケーション・スキームの作成, 9.2

アクティブ・スタンバイ・ペアの作成, 3.6

伝播

例, 9.11.4

PROPAGATOR句

例, 9.11.4

プロパゲータ・データベース

定義, 9.2.2

R

RAMポリシー

Oracle Clusterware, 8.6.12

読取り専用キャッシュ・グループ

レプリケーション, 1.6.3

ReceiverThreads初期接続属性, 11.1.2 障害が発生したデータベースのリカバリ, 9.1.1 リカバリ

RETURNサービス, 4.2.1.1.2

RecoveryThreads属性, 14.3 RELAXED

表チェック, 14.2

表定義, 4.2.2, 4.2.2

RemoteSubscriberHosts Clusterware属性, A.1 RepBackupDir Clusterware属性, A.1 RepBackupPeriod Clusterware属性, A.1 RepDDL Clusterware属性, 8.2.7, A.1

例, 8.2.7

RepFullBackupCycle Clusterware属性, A.1 レプリケート表

要件, 9.3

ネットワークを介したレプリケート, 4.3 レプリケーション

リリース間, 11.4

エージング, 1.9

ttAdmin, 11.5

AWTキャッシュ・グループ, 1.6.1

キャッシュ・グループ, 1.6

クラシック, 1.5.2

双方向レプリケーション・スキーム, 1.5.2.2

直接, 1.5.2.3

分散ワークロード構成, 1.5.2.2.2

外部キー, 9.5.3

全体レプリケーション, 1.5.2.1

伝播1.5.2.3

選択レプリケーション, 1.5.2.1

分割ワークロード, 1.5.2.2.1

単方向レプリケーション, 1.5.2.2

タイムスタンプ比較の構成, 13.3 競合のレポート, 13.4 競合解消, 13.1 制御, 11.6, 11.6 DDL文, 7.1.1 説明, 1.1 設計の判断, 9.1 要素, 1.1, 9.5 failed状態, 11.6 CREATE ACTIVE STANDBY PAIR文のFAILTHRESHOLD句, 4.2.1.1.3 CREATE REPLICATION文のFAILTHRESHOLD句, 4.2.1.1.3 外部キー, 1.8

アクティブ・スタンバイ・ペア, 3.13

ON DELETE CASCADE, 3.13

パフォーマンスの測定, 12.5 ホストIPアドレス, 4.3.4 監視, 12 マテリアライズド・ビュー, 9.5.5 順序, 9.5.4 ON DELETE CASCADE句, 1.8 ネットワーク経由, 1.5.2.3 パラレル, 「パラレル・レプリケーション」を参照 pause状態, 11.6 パフォーマンス, 14.2 プロパゲータ・データベース

定義, 1.5.2.3

relaxedチェック, 4.2.2 再起動ポリシー, 11.5 RETURN RECEIPT, 1.4.2 start状態, 11.6 起動, 11.5 状態, 11.6 stop状態, 11.6 停止

RETURNサービス・ポリシー, 4.2.1.1.3

停止, 11.5, 11.5 様々な定義を持つ表, 4.2.2 タイムスタンプ列のメンテナンス, 13.3.2.1 単方向, 1.5.2.2 WAN環境, 4.3.2 レプリケーション・エージェント

定義, 1.3

起動, 2.2.4, 11.5

停止, 2.2.6, 11.5

レプリケーション・デーモン, 「レプリケーション・エージェント」を参照 レプリケーションのパフォーマンス, 14.3 レプリケーション・スキーム

アクティブ・スタンバイ・ペア, 1.5.1

DSNへの適用, 9.12

構成, 9.1

定義, 9.2

例, 9.11

キャッシュ・グループ, 1.6

名前, 9.2.1

所有者, 9.2.1

タイプ, 1.5

ReplicationApplyOrdering接続属性, 11.1.3.1 ReplicationApplyOrderingデータ・ストア属性, 11.1.2, 11.1.3.1 ReplicationParallelism接続属性, 11.1.3.1 ReplicationParallelismデータ・ストア属性, 11.1.2, 11.1.3.1, 11.1.3.2 repschemes

ttIsqlコマンド, 12.4.1

リソース

定義, 8.1

再起動ポリシー, 11.5 制限

アクティブ・スタンバイ・ペア, 3.3

RESUME RETURN句

CREATE ACTIVE STANDBY PAIR文, 4.2.1.1.5

RESUME RETURNポリシー, 4.2.1.1.5

アクティブ・スタンバイ・ペア, 4.2.1.1.5, 4.2.1.1.5

RETURN RECEIPT

定義, 1.4

RETURN RECEIPT BY REQUEST句

例, 9.11.2

CREATE ACTIVE STANDBY PAIR文, 4.1.3

CREATE REPLICATION文, 4.1.3

RETURN RECEIPT句

アクティブ・スタンバイ・ペア, 4.1.2

CREATE REPLICATION文, 4.1.2

例, 9.11.1, 9.11.2, 9.11.2

RETURN RECEIPT障害ポリシー

レポート設定, 12.4.1

RETURN RECEIPTレプリケーション, 1.4.2 RETURN RECEPTタイムアウト・エラー, 1.4.2 RETURNサービス

アクティブ・スタンバイ・ペア, 3.8, 4.1

ブロック

無効, 4.2.1.1.2

CREATE REPLICATION文, 4.1 障害ポリシー, 4.2.1.1, 4.2.1.1.2 CREATE REPLICATION文, 9.8 パフォーマンスとリカバリのトレードオフ, 9.1.2 リカバリ・ポリシー, 4.2.1.1.2 タイムアウト・エラー, 4.2.1.1 RETURNサービス

ポリシー

レプリケーション停止時, 4.2.1.1.3

RETURN SERVICES句

CREATE ACTIVE STANDBY PAIR文, 4.2.1.1.3

RETURN TWOSAFE

双方向レプリケーション・スキーム, 4.1.4, 4.1.4

定義, 1.4

Oracle Clusterwareのリカバリ, 8.5.5.6

RETURN TWOSAFE BY REQUEST句

CREATE ACTIVE STANDBY PAIR文, 4.1.5

CREATE REPLICATION文, 4.1.5

RETURN TWOSAFE句

CREATE ACTIVE STANDBY PAIR文, 4.1.4

CREATE REPLICATION文, 4.1.4

ReturnServiceAttribute Clusterware属性, A.1

例, 8.5.5.6

REVOKE文, 10.1 役割

入替え, 5.6

ROUTE句

CREATE ACTIVE STANDBY PAIR文, 4.3.3

CREATE REPLICATION文, 4.3.3

CREATE ACTIVE STANDBY PAIR文, 3.10

レプリケーション・スキーム, 9.10

S

選択レプリケーション, 1.5.2.1

SEQUENCE要素, 9.5

順序

レプリケーション・スキームの追加, 10.1.1

要素名の変更, 10.1.7

レプリケーション・スキームからの削除, 10.1.4

レプリケーション, 1.7, 9.5.4

アクティブ・スタンバイ・ペアでのレプリケート, 3.15

分割ワークロード, 1.5.2.2.1

レプリケーション・スキーム

リカバリ, 9.1.1

構文の例, 9.11.5 SQLGetInfo関数

データベースの状態の確認, 4.2.6

サブスクライバの監視, 15.2.1

スタンバイ・マスター

アクティブへの変更, 5.6

二重の障害からのリカバリ, 5.4

障害からのリカバリ, 5.3, 6.6

start状態

レプリケーション, 11.6

レプリケーション・エージェントの起動, 2.2.4, 11.5 状態

クラスタ, 8.7

Oracle Clusterware, 8.7

stop状態

レプリケーション, 11.6

レプリケーション・エージェントの停止, 2.2.6, 11.5 STORE属性

CREATE ACTIVE STANDBY PAIR文, 3.9, 4.2

CREATE REPLICATION文, 4.2, 9.9

サブスクライバ

レプリケーション・スキームの追加, 10.1.5

ステータスの表示, 12.3

レプリケーション・スキームからの削除, 10.1.6

トランザクション・ログの蓄積, 12.3

SUBSCRIBER句

RETURNサービス, 9.8

CREATE ACTIVE STANDBY PAIR文, 3.7

RETURNサービス, 4.1

サブスクライバ・データベース

定義, 9.2.2

サブスクライバの障害, 5.5, 15.2.1

キャッシュ・グループが構成されたアクティブ・スタンバイ・ペア, 6.8

SubscriberHosts Clusterware属性, A.1 サブスクライバ

最大数, 9.11.2

SubscriberStoreAttribute Clusterware属性, A.1 SubscriberVIP Clusterware属性, A.1

T

表

レプリケーション・スキームの追加, 10.1.1

変更

パフォーマンス, 14.2

要素名の変更, 10.1.7 定義, 4.2.2 レプリケーション・スキームからの削除, 10.1.4 データベースからの除外, 10.1.3.2 データベースへの挿入, 10.1.3.1 パーティション, 4.2.2 relaxedチェック, 4.2.2, 14.2 TABLE DEFINITION CHECKING句

例, 4.2.2

TABLE要素, 9.5, 9.5.2 表要件

アクティブ・スタンバイ・ペア, 3.5

レプリケーション・スキーム, 9.3

表

変更およびレプリケーション, 10.2

しきい値ログの設定, 11.1.4.3 時刻

クロック管理

NTP, 8.1.2

タイムアウト

アクティブ・スタンバイ・ペアのRETURNサービス, 4.2.1

タイムスタンプ

オペレーティング・システム, 13.2

タイムスタンプ列のメンテナンス

ユーザーによる実行, 13.3.2.2

システム, 13.3.2.1

タイムスタンプ比較

構成, 13.3

ローカル・トランザクション, 13.2.1

TimesTenクラスタ・エージェント, 8.3.2, 8.3.4, 8.3.4 TimesTenデーモン・モニター, 8.3.4, 8.3.4 TimesTenScriptTimeout Clusterware属性, A.1 トラック

パラレル・レプリケーション, 11.1.3.2.1, 11.1.3.3

トランザクション・ログ

しきい値, 4.2.6, 4.2.6

失敗の状態, 4.2.6

トランザクション・ログ

分析, 12.8

TRANSMIT DURABLE句

CREATE REPLICATION文, 9.7

TRANSMIT NONDURABLE句

リカバリ, 15.4

CREATE REPLICATION文, 9.7

トラップされたトランザクション, 15.2.3.1 TRUNCATE TABLE文, 10.3 レプリケーション表の切捨て, 10.3 TT_VARCHAR列

サイズ制限, 3.5, 9.3

ttAdminユーティリティ

-ramPolicyオプション, 15.3.1, 15.3.2

-repPolicyオプション, 11.5

-repStartオプション, 11.5, 11.5

-repStopオプション, 11.5

ttCkpt組込みプロシージャ, 11.1.4.2 ttCkptBlocking組込みプロシージャ, 11.1.4.2 ttCRSActiveServiceプロセス, 8.3.10 ttCRSAgentプロセス, 8.3.4, 8.3.4 ttcrsagent.optionsファイル, 8.3.2, 8.3.2 ttCRSDaemonプロセス, 8.3.4, 8.3.4 ttCRSMasterプロセス, 8.3.10 ttCRSsubserviceプロセス, 8.3.10 ttCWAdmin

-beginAlterSchemaオプション, 8.4.3, 8.6.6.1, 8.6.6.1

ttCWAdmin -beginAlterSchemaコマンド, 8.4.3, 8.6.6.1, 8.6.6.1 ttCWAdmin -endAlterSchemaコマンド, 8.4.3, 8.6.6.1 ttCWAdminユーティリティ, 8.1, 8.2

-endAlterSchemaオプション, 8.4.3, 8.6.6.1

ocrConfigオプション, 8.3.3

-relocateオプション, 8.6.8

必要な権限, 8.1.1

-statusオプション, 8.7

-switchオプション, 8.6.7

ttcwerrors.logファイル, 8.7.2 ttcwmsg.logファイル, 8.7.2 ttDestroyユーティリティ, 15.3.1 ttDestroyDataStore組込みプロシージャ, 15.3.2 ttDurableCommit組込みプロシージャ, 4.2.1.1.1 ttIsqlユーティリティ

-fオプション, 9.12

ttMigrateユーティリティ

relaxedUpgradeオプション, 14.2, 14.2

ttRepAdminユーティリティ

-bookmarkオプション, 12.5.3

サブスクライバ情報の表示, 12.3.1

-duplicateオプション, 4.2.2, 9.7, 11.2, 15.2.3, 15.3.1, 15.3.1, 15.4

-duplicateオプションの権限, 3.2

-ramLoadオプション, 15.3.1, 15.3.1

-receiver -listオプション, 12.3.1

-self -listオプション, 12.2.1

-showconfigオプション, 12.4.2

-stateオプション, 11.6

ttRepDuplicate組込みプロシージャ, 15.3.2 ttRepDuplicateEx C関数

権限, 3.2

ttReplicationStatus組込みプロシージャ, 12.3.2 ttRepReturnTransitionTrap SNMPトラップ, 4.2.1.1.4 ttRepStart組込みプロシージャ, 10.1, 11.5 ttRepStop組込みプロシージャ, 10.1, 11.5 ttRepSubscriberStateSet組込みプロシージャ, 11.6 ttRepSubscriberWait組込みプロシージャ

順序のレプリケート3.15, 9.5.4

ttRepSyncGet組込みプロシージャ, 4.1.3, 4.1.5, 4.1.5 ttRepSyncSet組込みプロシージャ, 4.1.3, 4.1.3, 4.1.5, 4.2.1, 4.2.1, 4.2.1.1.7

異なるRETURNサービス, 9.11.2

LOCAL ACTIONポリシー, 4.2.1.1.7

RETURN RECEIPT BY REQUEST, 4.1.3

RETURNサービス・タイムアウトの設定, 4.2.1

ttRepSyncSubscriberStatus組込みプロシージャ, 4.2.1.1, 12.7.1

DISABLE RETURN句, 4.2.1.1.4

ttRepXactStatus組込みプロシージャ, 4.1, 4.2.1.1.7, 4.2.1.1.7, 12.7.2 ttRepXactTokenGet組込みプロシージャ, 12.7.2 ttXactLogユーティリティ

logAnalyzeコマンド, 12.8

TypeModeデータ・ストア属性, 11.1.2

U

単方向レプリケーション, 1.5.2.2

更新競合

例, 9.11.6

構文の例, 9.11.6

V

VARBINARY列

サイズ制限, 3.5, 3.5, 9.3, 9.3

VARCHAR2列

サイズ制限, 3.5, 9.3

ビュー

アクティブ・スタンバイ・ペア, 3.14

VIPInterface Clusterware属性, A.1 VIPNetMask Clusterware属性, A.1 仮想IPアドレス

Oracle Clusterware, 8.1

W

WAN環境, 4.3.2

レプリケーション, 4.3

WINSサーバー

Windows, 4.3.4.2

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。