Oracle® TimesTen Application-Tier Database Cache

ユーザーズ・ガイド

11g リリース2(11.2.2)

B66442-07(原本部品番号:E21634-12)

2014年10月

Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド 11g リリース2 (11.2.2)

B66442-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.7.0の新機能

- リリース11.2.2.6.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 Application-Tier Database Cacheの概念

- データ管理の設計

- キャッシュ・グリッドの概要

- キャッシュ・グループの概要

- キャッシュ・インスタンス

- キャッシュ・グループ・タイプ

- TimesTenデータベースとOracle Database間での更新の送信

- キャッシュ・グループへのデータのロード: 明示的にロードされるキャッシュ・グループおよび動的キャッシュ・グループ

- キャッシュ・グリッド間でのデータの共有: ローカル・キャッシュ・グループおよびグローバル・キャッシュ・グループ

- キャッシュ・グループ・タイプの概要

- キャッシュの高可用性ソリューション

2 スタート・ガイド

- Oracle DatabaseシステムおよびTimesTenシステムの設定

- Oracle Databaseでのユーザーの作成

- TimesTenデータベースのDSNの作成

- TimesTenデータベースでのユーザーの作成

- TimesTenデータベースでのキャッシュ管理ユーザーの名前およびパスワードの設定

- キャッシュ・グリッドの作成

- キャッシュ・グループの作成

- キャッシュされるOracle Database表の作成

- キャッシュ・エージェントの起動

- キャッシュ・グループの作成

- AWTキャッシュ・グループのレプリケーション・エージェントの起動

- キャッシュ・グリッドへのTimesTenデータベースのアタッチ

- 読取り専用キャッシュ・グループに対する処理の実行

- キャッシュ・グループの手動によるロード

- キャッシュされたOracle Database表の更新

- 動的な更新可能グローバル・キャッシュ・グループに対する処理の実行

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

- TimesTenキャッシュ表の更新

- TimesTenシステムおよびOracle Databaseシステムのクリーンアップ

- キャッシュ・グリッドからのTimesTenデータベースのデタッチ

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

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

- キャッシュ・グリッドの破棄

- キャッシュ・エージェントの停止およびTimesTenデータベースの破棄

- Oracle Databaseのユーザーおよびオブジェクトの削除

3 キャッシュ・インフラストラクチャの設定

- TimesTenにOracle Databaseデータをキャッシュするためのシステムの構成

- TimesTen Application-Tier Database Cacheの環境変数(UNIX)

- TimesTen Application-Tier Database Cacheの環境変数(Microsoft Windows)

- TimesTenにデータをキャッシュするためのOracle Databaseの構成

- Oracle Databaseユーザーの作成

- Oracle Databaseユーザーへの権限の付与

- Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成

- Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成

- Oracle DatabaseデータをキャッシュするためのTimesTenデータベースの構成

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

- TimesTenユーザーの作成

- TimesTenユーザーへの権限の付与

- キャッシュ管理ユーザーの名前およびパスワードの設定

- データ管理の構成

- ローカルでのデータの管理

- キャッシュ・グリッドの構成

- 10個以上のグリッド・ノードに対するPROCESSESシステム・パラメータの変更

- キャッシュ・グリッドの作成

- TimesTenデータベースとキャッシュ・グリッドの関連付け

- TimesTenデータベースとOracle Database間での接続テスト

- キャッシュ・エージェントの管理

- キャッシュ・エージェント起動ポリシーの設定

4 キャッシュ・グループの定義

- キャッシュ・グループおよびキャッシュ表

- 単一表のキャッシュ・グループ

- 複数表のキャッシュ・グループ

- キャッシュ・グループの作成

- 読取り専用キャッシュ・グループ

- 読取り専用キャッシュ・グループの使用の制限

- ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ

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

- Oracle Database表へのパラレル伝播の構成

- AWTキャッシュ・グループによって保証されることおよび保証されないこと

- AWTキャッシュ・グループの使用の制限

- AWTキャッシュ・グループでのOracle Database永続エラーのレポート

- SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ

- SWTキャッシュ・グループの使用の制限

- ユーザー管理キャッシュ・グループ

- READONLYキャッシュ表属性

- PROPAGATEキャッシュ表属性

- ユーザー管理キャッシュ・グループの例

- AUTOREFRESHキャッシュ・グループ属性

- キャッシュ・グループの変更によるAUTOREFRESHのモード、間隔または状態の変更

- 自動リフレッシュ・キャッシュ・グループ用のOracle Databaseオブジェクトの手動による作成

- WHERE句の使用

- CREATE CACHE GROUP文でのWHERE句の適切な配置

- WHERE句でのOracle Database PL/SQLファンクションの参照

- ON DELETE CASCADEキャッシュ表属性

- UNIQUE HASH ONキャッシュ表属性

- Oracle Databaseシノニムのキャッシュ

- Oracle Database LOBデータのキャッシュ

- キャッシュ・グループでのエージングの実装

- LRUエージング

- 時間ベースのエージング

- エージング・プロセスの手動によるスケジューリング

- スライド期間の構成

- 動的キャッシュ・グループ

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

- 動的グローバル・キャッシュ・グループ

- 明示的にロードされるグローバル・キャッシュ・グループ

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

- キャッシュ・グリッドへのTimesTenデータベースのアタッチ

5 キャッシュ・グループの処理

- TimesTenデータベースとOracle Database間での更新の送信

- キャッシュ・グループのロードおよびリフレッシュ

- 自動リフレッシュを使用する明示的にロードされるキャッシュ・グループのロードおよびリフレッシュ

- 自動リフレッシュを使用する動的キャッシュ・グループのロードおよびリフレッシュ

- WITH ID句を使用したキャッシュ・グループのロードおよびリフレッシュ

- 即時自動リフレッシュの開始

- 複数表のキャッシュ・グループのロードおよびリフレッシュ

- 数多くのキャッシュ・インスタンスのロードおよびリフレッシュにおけるパフォーマンスの向上

- 明示的にロードされるキャッシュ・グループの手動によるロードおよびリフレッシュの例

- 動的キャッシュ・グループの手動によるロードおよびリフレッシュの例

- キャッシュ・インスタンスの動的ロード

- 動的ロード構成

- 動的ロードのガイドライン

- キャッシュ・インスタンスの動的ロードの例

- 動的ロード・エラーが返る

- ユーザー管理キャッシュ・グループのフラッシュ

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

- すべてのグリッド・メンバーのキャッシュ・グループのアンロード

- 処理の影響を受けるキャッシュ・インスタンス数の判別

- パススルー・レベルの設定

- PassThrough=0

- PassThrough=1

- PassThrough=2

- PassThrough=3

- PassThrough=4

- PassThrough=5

- パススルーを使用する場合の注意事項

- 接続またはトランザクションのパススルー・レベルの変更

6 他のキャッシュ・グリッド・メンバーの作成

- 後続のスタンドアロンTimesTenデータベースの作成および構成

- キャッシュ表のレプリケート

- アクティブ・データベースの作成および構成

- スタンバイ・データベースの作成および構成

- 読取り専用サブスクライバ・データベースの作成および構成

- グリッド・メンバー間のデータ共有の例

- キャッシュ・グリッドに対するグローバル問合せの実行

- ローカル結合を使用するグローバル問合せの実行

- キャッシュ・グリッド内のデータの場所に関する情報の取得

- キャッシュ・グリッドまたはグリッド・メンバーへの他の要素の追加

7 キャッシュ環境の管理

- キャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

- キャッシュ・エージェントおよびレプリケーションの接続

- キャッシュ・グループおよびキャッシュ・グリッドの監視

- ttIsqlユーティリティのcachegroupsコマンドの使用

- キャッシュ・グループでの自動リフレッシュ処理の監視

- AWTキャッシュ・グループの監視

- AWTキャッシュ・グループのトランザクション・ログ・ファイルのしきい値の設定

- キャッシュ・グリッド情報の取得

- グローバルAWTキャッシュ・グループの処理の一時停止

- キャッシュされたOracle Database表に対して発行されたDDL文の追跡

- Oracle Databaseオブジェクトによるキャッシュ環境の管理

- TimesTenデータベースでの自動リフレッシュ処理の失敗による影響

- 自動リフレッシュ・キャッシュ・グループで使用されているOracle Databaseオブジェクトの削除

- キャッシュ管理ユーザーの表領域の監視

- 表領域の変更ログ表の最適化

- 自動リフレッシュ・キャッシュ・グループ用の変更ログ表の手動による最適化

- 表領域使用量通知の受信

- 一杯になった表領域のリカバリ

- グリッド・ノードの障害後のリカバリ

- キャッシュ・グループを持つデータベースのバックアップおよびリストア

- ttBackupおよびttRestoreユーティリティを使用したバックアップおよびリストア

- ttMigrateユーティリティを使用したバックアップおよびリストア

- キャッシュ・ユーザー名およびパスワードの変更

8 キャッシュ・パフォーマンス

- 動的ロードのパフォーマンス

- AWTのスループットの向上

- パラレル伝播を使用したAWTスループットの向上

- SQL配列実行を使用したAWTスループットの向上

- 増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際のパフォーマンスの向上

- 増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の大規模なトランザクションの実行の向上

- ttCacheAutorefreshXactLimitの使用

- 発生する可能性のあるトランザクションの非一貫性の例

- トランザクション制限を設定する際のパフォーマンスを評価する統計の取得

- 増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の選択制限の構成

- 特定の選択制限に対するキャッシュ・グループ名を決定する方法

- 選択制限を使用する際のパフォーマンスを評価する統計の取得

- 自動リフレッシュ処理時にメモリーを再利用する際のパフォーマンスの向上

- 自動リフレッシュ・トランザクションに関する統計情報の取得

- 2つ以上のTimesTenデータベースにおける同じOracle表のキャッシュ

9 キャッシュ環境のクリーンアップ

- キャッシュ・グリッドからのTimesTenデータベースのデタッチ

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

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

- キャッシュ・グリッドの破棄

- キャッシュ・エージェントの停止

- TimesTenデータベースの破棄

- Oracle Databaseのユーザーおよびオブジェクトの削除

- AWTキャッシュ・グループとともにアクティブ・スタンバイ・ペアをスケジュールして停止する場合に推奨される手法

10 キャッシュ・アドバイザの使用

- キャッシュ・アドバイザの概要

- Oracle DatabaseおよびTimesTenホスト・システムの設定

- ターゲットOracle Databaseの構成

- リポジトリOracle Databaseの構成

- TimesTenデータベースの構成

- キャッシュ・アドバイザの構成オプションと使用法のガイドライン

- ホストおよびデータベースのサポートされている構成オプション

- 制限と前提

- SQLワークロード・アプリケーションの実行

- キャッシュ・アドバイザの実行

- データ転送にNFSまたはFTPを使用することによるパフォーマンスの向上

- キャッシュ・アドバイザ・レポートの表示

- OracleおよびTimesTenのデータベースおよびホスト・システムのクリーンアップ

- ターゲットOracle Databaseおよびホスト・システムのクリーンアップ

- リポジトリOracle Databaseおよびホスト・システムのクリーンアップ

- TimesTenデータベースおよびホスト・システムのクリーンアップ

11 Oracle RAC環境でのTimesTen Application-Tier Database Cacheの使用

- Oracle RAC環境でのTimesTen Cacheの動作

- Oracle RAC環境でのTimesTen Cacheの使用の制限

- Oracle RAC環境でのTimesTen Cacheの設定

12 Data Guardと連携したTimesTen Application-Tier Database Cacheの使用

- TimesTen Application-Tier Database CacheのMAAのコンポーネント

- Data Guardと連携したTimesTen Cacheの動作

- Oracle Databaseの構成

- TimesTenデータベースの構成

A TimesTenでOracle Databaseデータをキャッシュするためのプロシージャおよび権限

- TimesTenでOracle Databaseデータをキャッシュするためのクイック・リファレンス

- キャッシュ管理ユーザーおよびキャッシュ・マネージャ・ユーザーに必要な権限

B TimesTen Application-Tier Database CacheのSQL*Plusスクリプト

- インストールされるSQL*Plusスクリプト

C TimesTenデータベースとOracle Databaseの互換性

- 互換性の問題の概要

- トランザクション・セマンティクス

- APIの互換性

- SQLの互換性

- スキーマ・オブジェクト

- Oracle Databaseパーティション表のキャッシュ

- 非スキーマ・オブジェクト

- Oracle DatabaseとTimesTenの表の相違

- データ型のサポート

- SQL演算子

- SELECT文

- SQL副問合せ

- SQL関数

- SQL式

- INSERT/DELETE/UPDATE/MERGE文

- TimesTenのみのSQLおよび組込みプロシージャ

- PL/SQLコンストラクト

- Oracle Databaseデータ型とTimesTenデータ型の間のマッピング

用語集

索引

はじめに

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

TimesTen Application-Tier Database Cacheは、Oracle Databaseの製品オプションであり、アプリケーション層におけるレスポンス時間を向上させる目的で、パフォーマンス重視のOracle DatabaseのサブセットをTimesTenデータベース内のキャッシュ表へキャッシュするために役立ちます。キャッシュ表は、読取り専用または更新可能にすることができます。アプリケーションでは、標準のSQL(Structured Query Language)を使用してキャッシュ表の読取りおよび更新を行い、TimesTenデータベースとOracle Database間のデータの同期が自動的に実行されます。

TimesTen Application-Tier Database Cacheによって、リレーショナル・データベースの完全な汎用性と機能性、Oracle Databaseとのキャッシュ一貫性の透過的な保持およびインメモリー・データベースのリアルタイム・パフォーマンスがアプリケーションに提供されます。

対象読者

このマニュアルは、TimesTenを使用および管理するアプリケーション開発者、およびOracle DatabaseからデータをキャッシュするTimesTenデータベースを構成および管理するシステム管理者を対象として記述されています。このマニュアルを使用するには、リレーショナル・データベース・システムの動作についての理解が必要です。また、SQLおよびODBC(Open Database Connectivity)、JDBC(Java Database Connectivity)またはOCI(Oracle Call Interface)のいずれかに関する知識も必要です。

関連ドキュメント

TimesTenのドキュメントは、製品配布メディアおよび次のURLのOracle Technology Network(OTN)で入手できます。

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=TimesTen_install_dir/lib/libtten.so

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

[ ]

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

{ }

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

|

縦線は、選択項目の引数を区切ります。

. . .

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

%

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

#

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

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

規則

意味

TimesTen_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

1桁または2桁の数字は、JDK(Java Development Kit)リリースのメジャー・バージョン番号を表します。たとえば、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)を参照してください。

新機能

この項では、このマニュアルで説明するTimesTen Application-Tier Database Cacheリリース11.2.2の新機能を説明し、詳細情報へのリンクを示します。

リリース11.2.2.7.0の新機能

- Oracle In-Memory Database Cacheは、Oracle TimesTen Application-Tier Database Cacheという名前になりました。以前のIMDB Cacheへの参照は、現在はTimesTen Cacheとして参照されます。

リリース11.2.2.6.0の新機能

- 自動リフレッシュの処理に使用するキャッシュ・エージェントに対する再利用バッファのサイズを管理できます。自動リフレッシュ・キャッシュ・グループを含むアクティブ・スタンバイ・ペア・レプリケーション・スキームを使用する場合、レプリケーション・エージェントに対する再利用バッファのサイズも管理できます。「自動リフレッシュ処理時にメモリーを再利用する際のパフォーマンスの向上」を参照してください。

リリース11.2.2.5.0の新機能

- コミット頻度を指定するために、UNLOAD CACHE GROUPでCOMMIT EVERY n ROWS句がサポートされています。「キャッシュ・グループのアンロード」を参照してください。ただし、この句を使用する場合、グリッド・メンバーのアンロード処理は実行されません。詳細は、「すべてのグリッド・メンバーのキャッシュ・グループのアンロード」を参照してください。

- AWTキャッシュ・グループでパラレル伝播を使用している場合は、キャッシュされたOracle Database表の列に対する欠落している一意索引、一意制約または外部キー制約により、シリアライズされたトランザクションがOracle Databaseに伝播されます。「AWTキャッシュ・グループでパラレル伝播を使用する場合の表に関する制約事項」を参照してください。

- 変更ログ表を長期間にわたって使用したり過度なワークロードを与えたりすると、表領域が断片化する場合があります。表領域が劣化して変更ログ表が断片化するのを防ぐために、TimesTenは、変更ログ表の断片化の比率を計算して表領域を最適化する方法を提供し、領域を再生します。詳細は、「表領域の変更ログ表の最適化」を参照してください。

- awterrsテキスト・ファイルにログ記録されたOracle Database永続エラーがXML書式でも記述できます。詳細は、「AWTキャッシュ・グループでのOracle Database永続エラーのレポート」を参照してください。

- ある期間において、月末、四半期末、年末のトランザクションなどのように大規模なトランザクションを実行する必要が生じる場合があります。また、短期間のうちにOracle Database内にある大量のデータを変更したり追加したりする状況が生じる場合もあります。読取り専用自動リフレッシュ・キャッシュ・グループの場合、TimesTenは、自動リフレッシュ処理がこれらのいずれかのケースに適用されたときに、永続領域を使い切ってしまう可能性があります。このため、このような状況においては、自動リフレッシュ・トランザクション制限を構成して、大量のデータを複数の小規模なトランザクションに分割して適用し、コミットするようにできます。詳細は、「増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の大規模なトランザクションの実行の向上」を参照してください。

- ttDBConfig組込みプロシージャにより、CacheAWTMethod初期接続属性の値を設定できます。「AWTのスループットの向上」を参照してください。

- AWTキャッシュ・グループを使用する際に、バックエンドOracle Databaseに対してパラレルに適用される1つ以上のトランザクションをバッチ処理するAWTキャッシュ・グループにおいてパラレル伝播を使用できます。CacheParAwtBatchSizeパラメータにより、1度のバッチ処理に含まれる行数に対してしきい値を設定します。「AWTキャッシュ・グループのパラレル伝播におけるバッチ・サイズの構成」を参照してください。

- AWTキャッシュ・グループとともにアクティブ・スタンバイ・レプリケーション・ペアをスケジュールして停止する場合に推奨される一連の手順が導入されています。詳細は、「AWTキャッシュ・グループとともにアクティブ・スタンバイ・ペアをスケジュールして停止する場合に推奨される手法」を参照してください。

- 主キーのすべての列に対する等価条件、一意索引のすべての列に対する等価条件または一意索引のすべての列に対する等価またはIS NULL条件の組合せによる問合せで動的ロードを実行できます(最低1つの等価条件が使用されている場合)。詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

- ttCacheCheck組込みプロシージャにより、AWTキャッシュ・グループに対する制約の欠落のチェックを手動で開始できます。Oracle Databaseでスキーマが変更された後には、TimesTenデータベースでttCacheCheckを実行することにより、制約の欠落のチェックを手動で実行する必要があります。「制約の欠落チェックの手動開始」を参照してください。

リリース11.2.2.4.0の新機能

- 1つ以上のキャッシュ・グループが含まれるTimesTenデータベースをバックアップおよびリストアする方法について、新しい説明が追加されました。詳細は「キャッシュ・グループを持つデータベースのバックアップおよびリストア」を参照してください。

- 新しいツールであるTimesTenキャッシュ・アドバイザを使用することで、Oracle Databaseの顧客が、TimesTen Cacheを使用した場合にその既存のOracle Databaseアプリケーションのパフォーマンスを向上できるかどうかを判断できます。キャッシュ・アドバイザは、Oracle DatabaseアプリケーションのSQL使用率に基づき、TimesTenキャッシュ・グループの定義の推奨値を生成します。詳細は、第10章「キャッシュ・アドバイザの使用」を参照してください。

リリース11.2.2.2.0の新機能

- ReplicationParallelismまたはCacheAWTParallelismデータ・ストア属性を使用して、AWTキャッシュ表の変更を対応するOracle Database表へ伝播するパラレル伝播を構成できます。「Oracle Database表へのパラレル伝播の構成」を参照してください。

- パラレル伝播を使用している場合は、AWTキャッシュ・グループのキャッシュ表に、キャッシュされたOracle Database表の列に対する一意索引、一意制約または外部キー制約も作成する必要があります。「Oracle Database表へのパラレル伝播の構成」を参照してください。

リリース11.2.2.1.0の新機能

- AWTキャッシュ表の変更を対応するOracle Database表へ伝播するパラレル伝播を構成できます。「Oracle Database表へのパラレル伝播の構成」を参照してください。

- CacheAWTMethod初期接続属性のデフォルト値は変更されています。「AWTのスループットの向上」を参照してください。

リリース11.2.2.0.0の新機能

- グローバル問合せが実行されているグリッド・ノードに関する情報を取得できます。「キャッシュ・グリッド内のデータの場所に関する情報の取得」を参照してください。

- グローバル問合せの実行時に、ローカル結合を実行できます。「ローカル結合を使用するグローバル問合せの実行」を参照してください。

1 TimesTen Application-Tier Database Cacheの概念

TimesTen Application-Tier Database CacheはOracle Database製品オプションで、Oracle TimesTen In-Memory Databaseが含まれます。これはアプリケーション層でデータベース・キャッシュとして使用され、Oracle DatabaseデータをキャッシュしてOracle Databaseでのワークロードを削減します。また、Oracle DatabaseとTimesTenデータベース間の接続とデータ転送を可能にし、TimesTenデータベースに流れる大量のイベントの取得と処理、および後続データのOracle Databaseへの転送も簡単になります。

キャッシュ・グループ内でTimesTenデータベースにOracle Databaseデータをキャッシュできます。TimesTenデータベースのキャッシュ・グループでは、単一のOracle Database表または関連する一連のOracle Database表をキャッシュできます。また、グローバル・キャッシュ・グループ(キャッシュ・グリッドのメンバーである必要があります)を使用して、Oracle Databaseデータを複数のTimesTenデータベースにわたってグローバルに共有できます。

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

- データ管理の設計

- キャッシュ・グループの概要

- キャッシュの高可用性ソリューション

データ管理の設計

TimesTenインメモリー・データベースの使用方法を設計する場合は、最初に次のいずれかを選択する必要があります。

- データをローカルで管理します(この場合、各TimesTenインメモリー・データベースは他のTimesTenインメモリー・データベースとは別個に動作します)。このオプションは、グローバル・データを管理するよりは簡単ですが、TimesTenでは、TimesTenインメモリー・データベースすべてにわたるデータの一貫性が管理されません。詳細は、「ローカルでのデータの管理」を参照してください。

- キャッシュ・グリッドを使用し、複数のTimesTenインメモリー・データベースにわたってデータをグローバルに管理します。これはデフォルトの方法です。キャッシュ・グリッドとは、グローバル・キャッシュ・グループ内にあるアプリケーション・データをまとめて管理するTimesTen Cacheデータベースの集合のことです。キャッシュ・グリッドには一連の分散TimesTenインメモリー・データベースがあり、Oracle Databaseからデータをキャッシュし、このTimesTenデータベースにあるグローバル・キャッシュ・グループのキャッシュ一貫性を確保するために連携します。詳細は、「キャッシュ・グリッドの概要」を参照してください。

キャッシュ・グリッドの概要

キャッシュ・グリッドとは、Oracle Databaseからデータをキャッシュし、TimesTenデータベース内のグローバル・キャッシュ・グループのキャッシュ一貫性を確保するために連携する一連の分散TimesTenインメモリー・データベースのことです。キャッシュ・グリッドは、グローバル・キャッシュ・グループを使用する予定がある場合にのみ使用します。

グリッドは、リレーショナル・データ・モデルを使用してアプリケーション・データをまとめて管理する1つ以上のインメモリー・データベース・グリッド・メンバーで構成されています。グリッドのメンバーは、単一のOracle Databaseからデータをキャッシュします。スタンドアロンのTimesTenデータベースまたはアクティブ・スタンバイ・ペアのいずれかをグリッド・メンバーにすることができます。

グリッド・ノードとは、グリッド・メンバーのデータベースのことです。ノードは次のいずれかになります。

- スタンドアロンTimesTenデータベース

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

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

したがって、スタンドアロン・データベースであるグリッド・メンバーは、1つのノードで構成されます。アクティブ・スタンバイ・ペアであるグリッド・メンバーは、2つのノードで構成されます。

図1-1に、3つのメンバー(2つのスタンドアロンTimesTenデータベースと1つのアクティブ・スタンバイ・ペア)からなるキャッシュ・グリッドを示します。グリッドには4つのノードがあり、それらは、2つのスタンドアロンTimesTenデータベース、アクティブ・スタンバイ・ペアのアクティブ・マスター・データベースおよびスタンバイ・マスター・データベースです。読取り専用サブスクライバ・データベースは、Oracle Databaseとの接続性がないため、キャッシュ・グリッドに含まれません。読取り専用サブスクライバでは、スタンバイ・マスター・データベースからレプリケートされた更新を受け取ります。

図1-1 3つのグリッド・メンバーがOracle Databaseからデータをキャッシュするキャッシュ・グリッド

キャッシュ・グリッドでは、グローバル・キャッシュ・データが共有記憶域のない複数のグリッド・メンバーに動的に分散されます。このアーキテクチャによって、キャッシュ・グリッドの容量は、アプリケーションの処理ニーズに応じて拡張できます。ワークロードの増減に応じて、新しいグリッド・メンバーがグリッドにアタッチされたり、既存のグリッド・メンバーがグリッドからデタッチされます。グリッドへのアタッチまたはグリッドからのデタッチはオンラインで処理され、他のグリッド・メンバーに対する処理に割り込みません。

リクエストがグリッド・メンバーに送信されると、キャッシュ・グリッドでは、アプリケーション・アクセス・パターンに基づいて自動的にデータが再分散されます。データの場所はアプリケーションに対して透過的ですが、キャッシュ・グリッドでは、アクセス時間を最小限に抑えるために動的にデータを再分散します。キャッシュ・グリッドによって、グリッド・メンバー間で自動的にキャッシュ一貫性およびトランザクション一貫性が維持されます。また、データの再分散を行わずにグローバル問合せを実行するようにキャッシュ・グリッドを構成することもできます。「キャッシュ・グリッドに対するグローバル問合せの実行」を参照してください。

キャッシュ・グリッド内のTimesTenデータベースには、明示的にロードされるキャッシュ・グループおよび動的キャッシュ・グループだけでなく、様々なキャッシュ・グループ分類およびカテゴリでサポートされているキャッシュ・グループ・タイプのローカル・キャッシュ・グループおよびグローバル・キャッシュ・グループも含めることができます。ただし、キャッシュの一貫性は、グローバル・キャッシュ・グループに対してのみ管理されます。

キャッシュ・グループの様々なタイプの詳細は、「キャッシュ・グループ・タイプ」を参照してください。

明示的にロードされるキャッシュ・グループと動的キャッシュ・グループ間の相違の詳細は、「キャッシュ・グループへのデータのロード: 明示的にロードされるキャッシュ・グループおよび動的キャッシュ・グループ」を参照してください。

ローカル・キャッシュ・グループおよびグローバル・キャッシュ・グループ間の相違の詳細は、「キャッシュ・グリッド全体でのデータの共有: ローカル・キャッシュ・グループおよびグローバル・キャッシュ・グループ」を参照してください。

キャッシュ・グリッドの作成およびTimesTenデータベースのキャッシュ・グリッドへの関連付けの詳細は、「キャッシュ・グリッドの構成」を参照してください。

キャッシュ・グループの概要

キャッシュ・グループでは、TimesTenデータベースにキャッシュするOracle Databaseデータを定義します。キャッシュ・グループを定義して、単一のOracle Database表のすべてかその一部または一連の関連付けられたOracle Database表をキャッシュできます。

図1-2に、単一のOracle Database表customerのサブセットをキャッシュするtarget_customersというキャッシュ・グループを示します。

図1-2 単一の表のキャッシュ・グループ

1つのルート表および1つ以上の子表を定義すると、複数のOracle Database表を同じキャッシュ・グループにキャッシュできます。キャッシュ・グループには、ルート表を1つのみ含めることができます。

複数の表を持つキャッシュ・グループでは、各子表が外部キー制約を使用して同じキャッシュ・グループ内のルート表または別の子表を参照する必要があります。複数表のキャッシュ・グループ内の表は外部キー制約を介してTimesTenデータベースで互いに関連している必要がありますが、対応する表が必ずしもOracle Databaseで互いに関連している必要はありません。ルート表は外部キー制約のある表を参照しません。複数表のキャッシュ・グループの特性の詳細は、「複数表のキャッシュ・グループ」を参照してください。

キャッシュ・インスタンス

データは、キャッシュ・インスタンスと呼ばれる単位でOracle DatabaseからTimesTenデータベース内のキャッシュ・グループにロードされます。キャッシュ・インスタンスは、子表の関連行のセットとともにキャッシュ・グループのルート表の単一行として定義されます。

図1-3に、customer_ordersキャッシュ・グループの表を3つ示します。ルート表はcustomerで、ordersおよびorder_itemは子表です。customer表のcust_num主キー列の値が122の行で識別されるキャッシュ・インスタンスには、次の行が含まれています。

- orders表のcust_num列の値が122の行2つ(ord_num主キー列の値は44325または65432)

- order_item表のord_num列の値が44325または65432の行3つ

図1-3 複数表のキャッシュ・グループ

キャッシュ・グループ・タイプ

よく使用されるキャッシュ・グループのタイプは、次のとおりです。

- 読取り専用キャッシュ・グループ
読取り専用キャッシュ・グループでは、Oracle Databaseのキャッシュ表にコミットされた更新がTimesTenデータベースのキャッシュ表に自動的にリフレッシュされるキャッシュ動作が実行されます。読取り専用キャッシュ・グループの使用が適しているのは、参照データがアプリケーションから頻繁にアクセスされる場合です。

読取り専用キャッシュ・グループの詳細は、「読取り専用キャッシュ・グループ」を参照してください。

- ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ
AWTキャッシュ・グループでは、TimesTenデータベースのキャッシュ表にコミットされた更新が自動的にOracle Databaseのキャッシュ表に非同期に伝播されるキャッシュ動作が実行されます。AWTキャッシュ・グループの使用が適しているのは、高速データ取得およびオンライン・トランザクション処理です。

AWTキャッシュ・グループの詳細は、「ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ」を参照してください。

キャッシュ・グループには、この他に次のタイプがあります。

- SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ
SWTキャッシュ・グループでは、TimesTenデータベースのキャッシュ表にコミットされた更新が自動的にOracle Databaseのキャッシュ表に同期して伝播されるキャッシュ動作が実行されます。

SWTキャッシュ・グループの詳細は、「SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ」を参照してください。

- ユーザー管理キャッシュ・グループ
ユーザー管理キャッシュ・グループでは、キャッシュ動作のカスタマイズを定義します。

たとえば、自動リフレッシュまたは自動伝播を使用しないキャッシュ・グループを定義することもできますが、その場合キャッシュ表にコミットされた更新は、キャッシュされたOracle Database表に手動で伝播またはフラッシュします。

また、すべての表を対象とした同期的な自動伝播と自動リフレッシュの両方を使用するキャッシュ・グループを定義することもできます。

ユーザー管理キャッシュ・グループの詳細は、「ユーザー管理キャッシュ・グループ」を参照してください。

TimesTenデータベースとOracle Database間での更新の送信

TimesTenキャッシュ表とキャッシュされたOracle Database表との間でコミットされた更新を転送すると、2つのデータベースでこれらの表の同期が確保されます。

図1-4に示すように、伝播およびフラッシュとは、TimesTenデータベースのキャッシュ表にコミットされた更新をOracle Databaseのキャッシュ表に送信する処理のことです。フラッシュは手動での処理であり、伝播は自動での処理です。

ロード、リフレッシュおよび自動リフレッシュとは、Oracle Databaseのキャッシュ表にコミットされた更新をTimesTenデータベースのキャッシュ表に送信する処理のことです。ロードおよびリフレッシュは手動での処理となり、自動リフレッシュは自動での処理となります。

ユーザー管理キャッシュ・グループに対してのみ発行可能なFLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

AWTキャッシュ・グループおよびSWTキャッシュ・グループに対する伝播操作の処理方法の詳細は、「ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ」および「SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ」をそれぞれ参照してください。

LOAD CACHE GROUP文およびREFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

自動リフレッシュ処理の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

図1-4 TimesTenデータベースとOracle Database間でのコミットされた更新の送信

キャッシュ・グループへのデータのロード: 明示的にロードされるキャッシュ・グループおよび動的キャッシュ・グループ

キャッシュ・グループは、明示的にロードされるキャッシュ・グループまたは動的キャッシュ・グループのいずれかにカテゴリ化されます。

明示的にロードされるキャッシュ・グループでは、キャッシュ・インスタンスはOracle DatabaseからTimesTenキャッシュ表にロード処理またはリフレッシュ処理によって手動でロードするか、または自動リフレッシュ処理を使用して自動的にロードします。キャッシュ表に対して問合せなどの処理を実行すると、事前に該当するキャッシュ表がロードされます。明示的にロードされるキャッシュ・グループが適しているのは、キャッシュするデータ・セットが静的であり、アプリケーションがキャッシュ表に対して処理を実行する前にそのデータ・セットを定義しておくことができる場合です。デフォルトでは、キャッシュ・グループは動的であると定義しないかぎり、明示的にロードされます。

動的キャッシュ・グループでは、キャッシュ・インスタンスはOracle DatabaseからTimesTenキャッシュ表に動的ロード処理を使用してリクエストに応じてロードするか、またはロード処理を使用して手動でロードします。動的キャッシュ・グループに対して手動リフレッシュ処理または自動リフレッシュ処理を実行すると、既存のキャッシュ・インスタンスを更新または削除できますが、キャッシュされていないOracle Databaseデータに対して更新をコミットしても新しいキャッシュ・インスタンスはキャッシュ表にロードされません。動的キャッシュ・グループが適しているのは、キャッシュするデータ・セットが少量であり、アプリケーションがキャッシュ表に対して処理を実行する前にOracle Databaseからそのデータ・セットを事前ロードしておく必要がない場合です。

キャッシュ・グループのロード処理とリフレッシュ処理の詳細は、「TimesTenデータベースとOracle Database間での更新の送信」を参照してください。

明示的にロードされるキャッシュ・グループに対してロード処理およびリフレッシュ処理を実行する場合と、同じ処理を動的キャッシュ・グループに対して実行する場合の相違の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

動的ロード処理の詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

どのキャッシュ・グループ・タイプ(読取り専用、AWT、SWT、ユーザー管理)も、明示的にロードされるキャッシュ・グループとして定義できます。AUTOREFRESHキャッシュ・グループ属性とPROPAGATEキャッシュ表属性の両方を使用するユーザー管理キャッシュ・グループを除いて、すべてのキャッシュ・グループ・タイプを動的キャッシュ・グループとして定義できます。

動的キャッシュ・グループの詳細は、「動的キャッシュ・グループ」を参照してください。

キャッシュ・グリッド間でのデータの共有: ローカル・キャッシュ・グループおよびグローバル・キャッシュ・グループ

キャッシュ・グループは、明示的にロードされるか動的かの他に、ローカルかグローバルかのいずれかに分類されます。

ローカル・キャッシュ・グループでは、キャッシュ表のデータは、TimesTenデータベースが同じキャッシュ・グリッドのメンバーであってもTimesTenデータベース間で共有されません。したがって、キャッシュ・インスタンスは特定のグリッド・メンバーにローカルであるため、データベースに重複しているデータがあってもかまいません。TimesTenキャッシュ表にコミットされた更新は、他のグリッド・メンバーとの調整がないまま、キャッシュされたOracle Database表に伝播されます。いずれのキャッシュ・グループ・タイプも、ローカル・キャッシュ・グループとして定義できます。ローカル・キャッシュ・グループは、明示的にロードされるキャッシュ・グループまたは動的キャッシュ・グループのいずれかに定義できます。ローカル・キャッシュ・グループの使用が適しているのは、参照データが頻繁に読み込まれ、すべてのグリッド・メンバーに存在可能である場合、および最適な同時実行性およびスループットを実現するために非結合データが論理的にパーティション化されている場合です。デフォルトでは、キャッシュ・グループはグローバルであると定義しないかぎり、ローカルとなります。

グローバル・キャッシュ・グループでは、キャッシュ表のデータが、同じキャッシュ・グリッドのメンバーであるTimesTenデータベース間で共有されます。複数のグリッド・メンバーの同じデータに更新をコミットした場合は、グリッドのメンバー間で読取り/書込みデータ一貫性を確保するために、更新内容がグリッド内での発行順にOracle Databaseに伝播されます。

動的なAWTキャッシュ・グループおよび明示的にロードされたAWTキャッシュ・グループは、グローバル・キャッシュ・グループとして定義できます。新しいキャッシュ・インスタンスは、リクエストに応じて、グローバル・キャッシュ・グループのキャッシュ表にロードされます。動的なAWTグローバル・キャッシュ・グループに対する問合せには、問合せが行われたローカル・グリッド・メンバー、リモート・グリッド・メンバーまたはOracle Databaseからのデータで対応できます。明示的にロードされたAWTキャッシュ・グループに対する問合せには、ローカル・グリッド・メンバーまたはリモート・グリッド・メンバーからのデータで対応できます。グローバル・キャッシュ・グループの使用が適しているのは、グリッドのメンバーとOracle Databaseとの間でデータの一貫性を確保するために、更新可能なデータにアクセスしたり、更新可能なデータが存在できるグリッド・メンバーが一度に1つにかぎられる場合です。

グローバル・キャッシュ・グループの作成と使用の詳細は、「グローバル・キャッシュ・グループ」を参照してください。

キャッシュ・グループ・タイプの概要

図1-5の表に、キャッシュ・グループの作成時にユーザーが使用できるキャッシュ・グループのタイプ、カテゴリおよび分類の有効な組合せの概要を示します。キャッシュ・グループ・カテゴリによって、キャッシュ・グループへのデータのロード方法が決まります。キャッシュ・グループ分類によって、キャッシュ・グループのデータがキャッシュ・グリッド間で共有できるかどうかが決まります。

どのキャッシュ・グループ・タイプにも、明示的にロードされるローカル・キャッシュ・グループまたは動的なローカル・キャッシュ・グループを作成できます。グローバル・キャッシュ・グループは、カテゴリおよびタイプが動的AWTまたは明示的にロードされたAWTであるキャッシュ・グループにのみ作成できます。

図1-5 キャッシュ・グループのタイプおよびカテゴリの概要

キャッシュの高可用性ソリューション

Oracle Databaseへの接続性を維持しつつ、キャッシュ表の高可用性を実現し、フェイルオーバーおよびリカバリが容易になるように、TimesTen Application-Tier Database Cacheを構成できます。TimesTenデータベースをアクティブ・スタンバイ・ペアのレプリケーション・スキームに参加させると、読取り専用キャッシュ・グループまたはAWTキャッシュ・グループでキャッシュ表の高可用性を実現できます。

アクティブ・スタンバイ・ペアを構成すると、TimesTenデータベースの高可用性を実現できます。グリッド・メンバーを複数配置すると、TimesTenキャッシュ・グリッドの高可用性を実現できます。Oracle Real Application Clusters(Oracle RAC)およびData Guardを構成すると、Oracle Databaseの高可用性を実現できます。

キャッシュ表のレプリケーションの構成の詳細は、「キャッシュ表のレプリケート」を参照してください。

TimesTen Application-Tier Database CacheおよびOracle RACの詳細は、「Oracle RAC環境でのTimesTen Application-Tier Database Cacheの使用」を参照してください。

TimesTen Application-Tier Database CacheおよびData Guardの詳細は、「Data Guardと連携したTimesTen Application-Tier Database Cacheの使用」を参照してください。

2 スタート・ガイド

この章では、明示的にロードされる読取り専用のローカル・キャッシュ・グループおよび動的な更新可能グローバル・キャッシュ・グループを作成する方法を示して、キャッシュ・グループの作成および使用について説明します。また、この例ではグローバル・キャッシュ・グループを作成するため、この章では、グリッドを作成する方法を説明します。さらに、キャッシュ表に移入する方法、およびTimesTenデータベースのキャッシュ表とOracle Databaseのキャッシュされた表の間で更新の転送を監視する方法についても説明します。

- Oracle DatabaseシステムおよびTimesTenシステムの設定

- キャッシュ・グリッドの作成

- キャッシュ・グループの作成

- キャッシュ・グリッドへのTimesTenデータベースのアタッチ

- 読取り専用キャッシュ・グループに対する処理の実行

- 動的な更新可能グローバル・キャッシュ・グループに対する処理の実行

- TimesTenシステムおよびOracle Databaseシステムのクリーンアップ

Oracle DatabaseシステムおよびTimesTenシステムの設定

キャッシュ・グリッドまたはキャッシュ・グループを作成するには、最初にTimesTenをインストールし、Oracle DatabaseシステムおよびTimesTenシステムを構成しておく必要があります。TimesTenのインストールの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』を参照してください。

次のタスクを実行します。

1. Oracle Databaseでのユーザーを作成します。

2. TimesTenデータベースのDSNを作成します。

3. TimesTenデータベースでのユーザーを作成します。

4. TimesTenデータベースでのキャッシュ管理ユーザーの名前およびパスワードを設定します。

Oracle Databaseでのユーザーの作成

TimesTen Application-Tier Database Cacheを使用するには、Oracle Databaseで次のユーザーを作成する必要があります。

- ユーザーtimestenは、キャッシュ環境に関する情報を格納するOracle Database表を所有します。

- 1人以上のスキーマ・ユーザーは、TimesTenデータベースにキャッシュされるOracle Database表を所有します。既存ユーザーまたは新規ユーザーをスキーマ・ユーザーにすることができます。

- キャッシュ管理ユーザーは、Oracle Databaseオブジェクトを作成して保持し、これらのOracle Databaseオブジェクトには、キャッシュ環境を管理し、特定のキャッシュ・グループ・タイプの定義済動作を実行するための情報が格納されます。

オペレーティング・システム・シェルまたはコマンド・プロンプトからOracle DatabaseシステムでSQL*Plusを起動し、sysユーザーとしてOracle Databaseインスタンスに接続します。

% cd TimesTen_install_dir/oraclescripts
% sqlplus sys as sysdba
Enter password: password

SQL*Plusを使用して、他のアプリケーションと共有しないTimesTen Application-Tier Database Cache管理オブジェクトの格納に使用するデフォルトの表領域を作成します。TimesTenでキャッシュしたOracle実表も格納できますが、キャッシュ管理のために、この表領域をTimesTenのみで使用することを強く推奨します。

SQL*Plusを使用して、SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/initCacheGlobalSchema.sqlを実行して、次の要素を作成します。

- timestenユーザー

- キャッシュ・グリッド(構成されている場合)を含むキャッシュ環境に関する情報を格納するためにtimestenユーザーが所有するOracle Database表

- Oracle Database表に対する権限を定義するTT_CACHE_ADMIN_ROLEロール

デフォルトの表領域を引数としてinitCacheGlobalSchema.sqlスクリプトに渡します。次の例では、デフォルトの表領域の名前をcachetblspとしています。

SQL> CREATE TABLESPACE cachetblsp DATAFILE 'datfttuser.dbf' SIZE 100M;
SQL> @initCacheGlobalSchema "cachetblsp"

次に、SQL*Plusを使用してスキーマ・ユーザーを作成します。このユーザーに、TimesTenデータベースにキャッシュされるOracle Databaseの表を作成するために必要な最小限の権限セットを付与します。次の例では、スキーマ・ユーザーをorattとしています。

SQL> CREATE USER oratt IDENTIFIED BY oracle;
SQL> GRANT CREATE SESSION, RESOURCE TO oratt;

次に、SQL*Plusを使用して、次の処理を実行します。

- キャッシュ管理ユーザーを作成します。

- SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/grantCacheAdminPrivileges.sqlを実行して、キャッシュ・グリッド処理およびキャッシュ・グループ処理を実行するために必要な最小限の権限セットをキャッシュ管理ユーザーに付与します。

キャッシュ管理ユーザー名を引数としてgrantCacheAdminPrivileges.sqlスクリプトに渡します。次の例では、キャッシュ管理ユーザー名をcacheuserとし、そのデフォルトの表領域の名前をcachetblspとしています。

注意:
grantCacheAdminPrivileges.sqlスクリプトを実行するユーザーが必要な権限と、このユーザーがキャッシュ管理ユーザーに付与する権限については、このスクリプト内のコメントを参照してください。

SQL> CREATE USER cacheuser IDENTIFIED BY oracle
2  DEFAULT TABLESPACE cachetblsp QUOTA UNLIMITED ON cachetblsp;
SQL> @grantCacheAdminPrivileges "cacheuser"
SQL> exit

キャッシュ管理ユーザーが必要とする権限は、作成するキャッシュ・グループおよびそのキャッシュ・グループに対して実行する処理のタイプによって異なります。

timestenユーザー、スキーマ・ユーザーおよびキャッシュ管理ユーザーの詳細は、「Oracle Databaseユーザーの作成」を参照してください。

TimesTenデータベースのDSNの作成

SQL> SELECT value FROM nls_database_parameters WHERE parameter='NLS_CHARACTERSET';

UNIXでは、ホーム・ディレクトリにある.odbc.iniファイルまたはTimesTen_install_dir/info/sys.odbc.iniファイルで、TimesTen DSN cachealone1を作成し、次の接続属性を設定します。

[cachealone1]
DataStore=/users/OracleCache/alone1
PermSize=64
OracleNetServiceName=oracledb
DatabaseCharacterSet=AL32UTF8
CacheGridEnable=1

Windowsでは、TimesTenユーザーDSNまたはシステムDSN cachealone1を作成し、次の接続属性を設定します。

- データ・ストア・パスおよび名前: c:\temp\alone1

- 永続データのサイズ: 64

- Oracleネット・サービス名: oracledb

- データベース・キャラクタ・セット: AL32UTF8

- キャッシュ・グリッドを作成できるようにキャッシュ・グリッドは有効化されます。

これ以外の接続属性にはデフォルト設定を使用します。

Oracle DatabaseからデータをキャッシュするTimesTenデータベースのDSNを定義する方法の詳細は、「TimesTenデータベースのDSNの定義」を参照してください。

TimesTen DSNの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明を参照してください。

注意:
データ・ストアという用語は、TimesTenデータベースと同義で使用されます。

TimesTenデータベースでのユーザーの作成

TimesTen Application-Tier Database Cacheを使用するには、Oracle Databaseユーザーの他に、次のTimesTenユーザーを作成する必要があります。

- キャッシュ・マネージャ・ユーザーは、キャッシュ・グリッド処理およびキャッシュ・グループ処理を実行します。TimesTenキャッシュ管理ユーザーは、キャッシュされたOracle Database表にアクセスできるコンパニオンOracle Databaseユーザーと同じ名前である必要があります。コンパニオンOracle Databaseユーザーは、キャッシュ管理ユーザー、スキーマ・ユーザーまたはその他の既存ユーザーにすることができます。使いやすくするために、キャッシュ管理ユーザーをキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーにすることをお薦めします。キャッシュ・マネージャ・ユーザーのパスワードは、同じ名前を持つコンパニオンOracle Databaseユーザーとは別のパスワードにすることができます。

注意:
キャッシュ・マネージャ・ユーザーおよびコンパニオンOracle Databaseユーザーの詳細は、「TimesTenユーザーの作成」を参照してください。

キャッシュ・マネージャ・ユーザーは、キャッシュ・グリッドを作成および構成し(構成されている場合)、キャッシュ・グループを作成する必要があります。また、グリッド自体、およびキャッシュ・グループに対して実行される様々な処理を監視することもできます。

- 1人以上のキャッシュ表ユーザーが、キャッシュ表を所有します。TimesTenデータベースにキャッシュされるOracle Database表を現在所有しているか、または今後所有することになるスキーマ・ユーザーごとに、Oracle Databaseスキーマ・ユーザーと同じ名前でTimesTenキャッシュ表ユーザーを作成する必要があります。キャッシュ表ユーザーのパスワードは、同じ名前を持つOracle Databaseスキーマ・ユーザーとは別のパスワードにすることができます。
TimesTenキャッシュ表の所有者および名前は、対応するキャッシュされたOracle Database表の所有者および名前と同じです。

インスタンス管理者として、オペレーティング・システム・シェルまたはコマンド・ラインからTimesTenシステムでttIsqlユーティリティを起動し、cachealone1 DSNに接続して、Oracle Databaseのデータをキャッシュするために使用するTimesTenデータベースを作成します。

% ttIsql cachealone1

ttIsqlを使用して、キャッシュ・マネージャ・ユーザーを作成します。このユーザーに、キャッシュ・グリッドを作成し(構成されている場合)、キャッシュ・グループを作成し、そのキャッシュ・グループに対して操作を実行するために必要な最小限の権限セットを付与します。次の例では、キャッシュ・マネージャ・ユーザー名をcacheuserとしていますが、この名前は前に作成したキャッシュ管理ユーザーと同じ名前です。

Command> CREATE USER cacheuser IDENTIFIED BY timesten;
Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE TO cacheuser;

次に、ttIsqlを使用して、キャッシュ表ユーザーを作成します。次の例では、キャッシュ表ユーザー名をorattとしていますが、この名前は以前に作成したOracle Databaseスキーマ・ユーザーと同じ名前です。

Command> CREATE USER oratt IDENTIFIED BY timesten;
Command> exit

キャッシュ・マネージャ・ユーザーが必要とする権限は、作成するキャッシュ・グループおよびそのキャッシュ・グループに対して実行する処理のタイプによって異なります。キャッシュ・マネージャ・ユーザーおよびキャッシュ表ユーザーの詳細は、「TimesTenユーザーの作成」を参照してください。

TimesTenユーザーおよび権限の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のアクセス制御の管理に関する説明を参照してください。

TimesTenデータベースでのキャッシュ管理ユーザーの名前およびパスワードの設定

ttIsqlユーティリティを起動して、cachealone1 DSNにキャッシュ・マネージャ・ユーザーとして接続します。接続文字列で、UID接続属性にキャッシュ・マネージャ・ユーザー名を指定します。キャッシュ・マネージャ・ユーザーのパスワードをPWD接続属性に指定します。そのコンパニオンOracleユーザー(キャッシュ・マネージャのコンパニオン・ユーザーと同じ名前で作成済)のパスワードを、接続文字列内のOraclePWD接続属性に指定します。この例では、キャッシュ管理ユーザーはキャッシュ・マネージャ・ユーザーのコンパニオン・ユーザーであるため、パスワードが指定されています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"

ttIsqlを使用して、ttCacheUidPwdSet組込みプロシージャをコールし、キャッシュ管理ユーザーの名前およびパスワードを設定します。

Command> call ttCacheUidPwdSet('cacheuser','oracle');

キャッシュ管理ユーザーの名前とパスワードは、TimesTenデータベースに1回のみ設定する必要があります。TimesTenデータベースがこの設定を使用する方法の詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。

キャッシュ・グリッドの作成

この例ではグローバル・キャッシュ・グループを使用するため、キャッシュ・グリッドを作成して、Oracle DatabaseからデータをキャッシュするTimesTenデータベース内でグローバル・キャッシュ・データの管理に使用するフレームワークを定義する必要があります。Oracle Databaseユーザー、TimesTenデータベースおよびTimesTenユーザーを作成した後に、キャッシュ・グリッドを作成し、キャッシュ管理ユーザーの名前とパスワードをそのTimesTenデータベースに設定します。

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してttGridCreate組込みプロシージャをコールし、キャッシュ・グリッドmyGridを作成します。

Command> call ttGridCreate('myGrid');

次に、ttIsqlを使用してttGridNameSet組込みプロシージャをコールし、TimesTenデータベースをmyGridキャッシュ・グリッドに関連付けます。

Command> call ttGridNameSet('myGrid');

キャッシュ・グリッドの内容および機能の詳細は、「キャッシュ・グリッドの構成」を参照してください。

キャッシュ・グループの作成

この項では、読取り専用のキャッシュ・グループ(図2-1を参照)、および非同期ライトスルー(AWT)キャッシュ・グループ(図2-2を参照)を作成します。

図2-1 単一表の読取り専用キャッシュ・グループ

図2-2 単一表のライトスルー・キャッシュ・グループ

次のタスクを完了して、読取り専用キャッシュ・グループおよびAWTキャッシュ・グループを作成します。

1. キャッシュされるOracle Database表を作成します。

2. キャッシュ・エージェントを起動します。

3. キャッシュ・グループを作成します。

4. AWTキャッシュ・グループのレプリケーション・エージェントを起動します。

キャッシュされるOracle Database表の作成

SQL*Plusを起動し、スキーマ・ユーザーとしてOracle Databaseに接続します。

% sqlplus oratt/oracle

SQL*Plusを使用して、表readtab(図2-3を参照)および表writetab(図2-4を参照)を作成します。

SQL> CREATE TABLE readtab (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));
SQL> CREATE TABLE writetab (pk NUMBER NOT NULL PRIMARY KEY, attr VARCHAR2(40));

図2-3 読取り専用キャッシュ・グループにキャッシュされるOracle Database表の作成

図2-4 AWTキャッシュ・グループにキャッシュされるOracle Database表の作成

次に、SQL*Plusを使用して、数行をreadtab表およびwritetab表に挿入し、変更をコミットします。

SQL> INSERT INTO readtab VALUES (1, 'Hello');
SQL> INSERT INTO readtab VALUES (2, 'World');

SQL> INSERT INTO writetab VALUES (100, 'TimesTen');
SQL> INSERT INTO writetab VALUES (101, 'CACHE');
SQL> COMMIT;

次に、SQL*Plusを使用して、readtab表に対するSELECT権限およびwritetab表に対するSELECT、INSERT、UPDATE、DELETEの各権限をキャッシュ管理ユーザーに付与します。

SQL> GRANT SELECT ON readtab TO cacheuser;

SQL> GRANT SELECT ON writetab TO cacheuser;
SQL> GRANT INSERT ON writetab TO cacheuser;
SQL> GRANT UPDATE ON writetab TO cacheuser;
SQL> GRANT DELETE ON writetab TO cacheuser;

readtab表に対するSELECT権限は、この表をキャッシュする読取り専用キャッシュ・グループを作成し、キャッシュされたOracle Database表からTimesTenキャッシュ表への自動リフレッシュ処理を実行するために必要です。

writetab表に対するSELECT権限は、この表をキャッシュするAWTキャッシュ・グループを作成するために必要です。writetab表に対するINSERT、UPDATEおよびDELETEの各権限は、TimesTenキャッシュ表からキャッシュされたOracle Database表にライトスルー処理を実行するために必要です。

キャッシュ管理ユーザーが読取り専用キャッシュ・グループおよびAWTキャッシュ・グループを作成し、それぞれのグループに対して処理を実行するために必要な権限の詳細は、「Oracle Databaseユーザーへの権限の付与」を参照してください。

キャッシュ・エージェントの起動

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してttCacheStart組込みプロシージャをコールし、TimesTenデータベースでキャッシュ・エージェントを起動します。

Command> call ttCacheStart;

キャッシュ・エージェントの起動方法の詳細は、「キャッシュ・エージェントの管理」を参照してください。

キャッシュ・グループの作成

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用して、Oracle Database表oratt.readtabをキャッシュする読取り専用キャッシュ・グループreadcacheおよびOracle Database表oratt.writetabをキャッシュする動的AWTグローバル・キャッシュ・グループwritecacheを作成します。

Command> CREATE READONLY CACHE GROUP readcache
> AUTOREFRESH INTERVAL 5 SECONDS
> FROM oratt.readtab
> (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));

Command> CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP writecache
> FROM oratt.writetab
> (pk NUMBER NOT NULL PRIMARY KEY, attr VARCHAR2(40));

キャッシュ・グループreadcacheおよびwritecacheに加えて、それぞれのキャッシュ表oratt.readtabおよびoratt.writetabが、TimesTenデータベースに作成されます。キャッシュ表の所有者および名前は、キャッシュされたOracle Database表と同じものとなります。図2-5に、oratt.writetab表をキャッシュするwritecacheキャッシュ・グループを示します。

図2-5 ASYNCHRONOUS WRITETHROUGHキャッシュ・グループの作成

ttIsql cachegroupsコマンドを使用して、readcacheキャッシュ・グループおよびwritecacheキャッシュ・グループの定義を表示します。

Command> cachegroups;

Cache Group CACHEUSER.READCACHE:

Cache Group Type: Read Only
Autorefresh: Yes
Autorefresh Mode: Incremental
Autorefresh State: Paused
Autorefresh Interval: 5 Seconds
Autorefresh Status: ok
Aging: No aging defined

Root Table: ORATT.READTAB
Table Type: Read Only

Cache Group CACHEUSER.WRITECACHE:

Cache Group Type: Asynchronous Writethrough global (Dynamic)
Autorefresh: No
Aging: LRU on

Root Table: ORATT.WRITETAB
Table Type: Propagate

2 cache groups found.

読取り専用キャッシュ・グループの詳細は、「読取り専用キャッシュ・グループ」を参照してください。

AWTキャッシュ・グループの詳細は、「ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ」を参照してください。

動的キャッシュ・グループの詳細は、「動的キャッシュ・グループ」を参照してください。

グローバル・キャッシュ・グループの詳細は、「グローバル・キャッシュ・グループ」を参照してください。

AWTキャッシュ・グループのレプリケーション・エージェントの起動

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してttRepStart組込みプロシージャをコールし、TimesTenデータベースでレプリケーション・エージェントを起動します。

Command> call ttRepStart;

レプリケーション・エージェントは、AWTキャッシュ・グループのTimesTenキャッシュ表にコミットされた更新を、キャッシュされたOracle Database表に伝播します。

レプリケーション・エージェントの起動方法の詳細は、「レプリケーション・エージェントの管理」を参照してください。

キャッシュ・グリッドへのTimesTenデータベースのアタッチ

ローカルのキャッシュ・グループのみを作成している場合は、TimesTenデータベースをキャッシュ・グリッドにアタッチする必要はありません。ただし、グローバル・キャッシュ・グループまたはそのキャッシュ表に対して処理を実行するには、グローバル・キャッシュ・グループが関連付けられているキャッシュ・グリッドにTimesTenデータベースをアタッチする必要があります。

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してttGridAttach組込みプロシージャをコールし、myGridキャッシュ・グリッドにTimesTenデータベースをアタッチします。

Command> call ttGridAttach(1,'alone1','mysys',5001);

この例で、alone1はグリッド・メンバーを一意に識別する名前を、mysysはTimesTenシステムのホスト名を、5001はキャッシュ・エージェントのTCP/IPポートを示しています。ttGridAttach組込みプロシージャをコールすると、キャッシュ・エージェントがまだ実行中でない場合に、エージェントが自動的に起動されます。

この章の例には、唯一のグリッド・メンバーとしてスタンドアロンTimesTenデータベースが1つのみ含まれていますが、アクティブ・スタンバイ・ペアや他のスタンドアロンTimesTenデータベースなどをグリッド・メンバーとして追加することもできます。既存のキャッシュ・グリッドに他のメンバーを作成および追加する方法、およびグリッド・メンバー間でグローバル・キャッシュ・グループのデータを共有する方法の詳細は、第6章「他のキャッシュ・グリッド・メンバーの作成」を参照してください。

読取り専用キャッシュ・グループに対する処理の実行

この項では、読取り専用キャッシュ・グループを手動でロードする方法について説明します。次に、TimesTenキャッシュ表にコミットされた更新を、キャッシュされたOracle Database表に自動的に伝播する方法について説明します。

次のタスクを完了して、読取り専用キャッシュ・グループに対して処理を実行します。

1. キャッシュ・グループを手動でロードします。

2. キャッシュされたOracle Database表を更新します。

キャッシュ・グループの手動によるロード

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用して、readcacheキャッシュ・グループのTimesTenキャッシュ表oratt.readtabにOracle Database表oratt.readtabの内容をロードします。

Command> LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS;
2 cache instances affected.
Command> exit

図2-6に、Oracle Databaseデータがoratt.readtabキャッシュ表にロードされる方法を示します。

図2-6 読取り専用キャッシュ・グループのロード

ttIsqlユーティリティを開始して、cachealone1 DSNにインスタンス管理者として接続します。ttIsqlを使用して、oratt.readtabキャッシュ表に対するSELECT権限をキャッシュ・マネージャ・ユーザーに付与して、このユーザーがこの表に対してSELECT問合せを発行できるようにします。

% ttIsql cachealone1
Command> GRANT SELECT ON oratt.readtab TO cacheuser;
Command> exit

ttIsqlユーティリティを起動し、キャッシュ・マネージャ・ユーザーとしてcachealone1 DSNに接続します(キャッシュ・マネージャ・ユーザーのパスワードおよびそのコンパニオンOracleユーザーのパスワードを指定します)。ttIsqlを使用して、oratt.readtabキャッシュ表の内容を問い合せます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> SELECT * FROM oratt.readtab;
< 1, Hello >
< 2, World >
2 rows found.

キャッシュ・グループを手動でロードする方法の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

キャッシュされたOracle Database表の更新

Oracle Databaseスキーマ・ユーザーとしてSQL*Plusを使用して、Oracle Database表readtabを対象に、新規行の挿入、既存行の削除および既存行の更新を実行し、これらの変更をコミットします。

SQL> INSERT INTO readtab VALUES (3, 'Welcome');
SQL> DELETE FROM readtab WHERE keyval=2;
SQL> UPDATE readtab SET str='Hi' WHERE keyval=1;
SQL> COMMIT;

読取り専用キャッシュ・グループが5秒間隔の自動リフレッシュを指定して作成されたため、readcacheキャッシュ・グループのoratt.readtabキャッシュ表は、図2-7に示すように、キャッシュされたOracle Databaseのoratt.readtab表にコミットされた更新で、5秒後に自動的にリフレッシュされます。

図2-7 Oracle Database更新でのTimesTenキャッシュ表の自動リフレッシュ

キャッシュされたOracle Database表にコミットされた更新によってreadcacheキャッシュ・グループが自動的にリフレッシュされた後、キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してoratt.readtabキャッシュ表の内容を問い合せます。

Command> SELECT * FROM oratt.readtab;
< 1, Hi >
< 3, Welcome >
2 rows found.
Command> exit

キャッシュ・グループの自動リフレッシュの詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

動的な更新可能グローバル・キャッシュ・グループに対する処理の実行

この項では、AWTキャッシュ・グループを動的にロードする方法について説明します。次に、TimesTenキャッシュ表にコミットされた更新を、キャッシュされたOracle Database表に自動的に伝播する方法について説明します。

次のタスクを完了して、AWTキャッシュ・グループに対して処理を実行します。

1. キャッシュ・グループを動的にロードします。

2. TimesTenキャッシュ表を更新します。

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

ttIsqlユーティリティを開始して、cachealone1 DSNにインスタンス管理者として接続します。ttIsqlを使用して、oratt.writetabキャッシュ表に対するSELECT権限をキャッシュ・マネージャ・ユーザーに付与し、このユーザーがこの表に対して動的ロードSELECT文を発行できるようにします。

% ttIsql cachealone1
Command> GRANT SELECT ON oratt.writetab TO cacheuser;
Command> exit

ttIsqlユーティリティを起動し、キャッシュ・マネージャ・ユーザーとしてcachealone1 DSNに接続します(キャッシュ・マネージャ・ユーザーのパスワードおよびそのコンパニオンOracleユーザーのパスワードを指定します)。ttIsqlを使用して、Oracle Database表oratt.writetabからwritecacheキャッシュ・グループのTimesTenキャッシュ表oratt.writetabに、リクエストに応じてキャッシュ・インスタンスをロードします。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> SELECT * FROM oratt.writetab WHERE pk=100;
< 100, TimesTen >
1 row found.
Command> exit

動的キャッシュ・グループでは、動的ロード文でリクエストに応じてキャッシュ・インスタンスをキャッシュ表にロードできます。キャッシュ・インスタンスを一意に識別するTimesTenキャッシュ表にSELECT、UPDATE、DELETEまたはINSERTのいずれかの文を発行すると、キャッシュ表でデータが見つからない場合に、キャッシュされたOracle Database表からキャッシュ・インスタンスが自動的にロードされます。動的にロードされるキャッシュ・インスタンスは、キャッシュ・グループのルート表の単一行と子表のすべての関連行で構成されています。

動的ロード処理の詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

LOAD CACHE GROUP文を使用すると、動的キャッシュ・グループのキャッシュ表にデータを手動でロードすることもできます。

TimesTenキャッシュ表の更新

ttIsqlユーティリティを開始して、cachealone1 DSNにインスタンス管理者として接続します。ttIsqlを使用して、oratt.writetabキャッシュ表に対するINSERT、DELETEおよびUPDATEの各権限をキャッシュ・マネージャ・ユーザーに付与して、このユーザーがこの表に対して更新を実行できるようにします。

% ttIsql cachealone1
Command> GRANT INSERT ON oratt.writetab TO cacheuser;
Command> GRANT DELETE ON oratt.writetab TO cacheuser;
Command> GRANT UPDATE ON oratt.writetab TO cacheuser;
Command> exit

ttIsqlユーティリティを起動して、cachealone1 DSNにキャッシュ・マネージャ・ユーザーとして接続します。ttIsqlを使用して、oratt.writetabキャッシュ表を対象に、新規行の挿入、既存行の削除および既存行の更新を実行し、これらの変更をコミットします。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> INSERT INTO oratt.writetab VALUES (102, 'Cache');
Command> DELETE FROM oratt.writetab WHERE pk=101;
Command> UPDATE oratt.writetab SET attr='Oracle' WHERE pk=100;
Command> COMMIT;
Command> exit

writecacheキャッシュ・グループのoratt.writetabキャッシュ表にコミットされた更新は、図2-8に示すように、Oracle Database表oratt.writetabに自動的に伝播されます。

図2-8 TimesTenキャッシュ表に対する更新のOracle Databaseへの自動伝播

Oracle Databaseスキーマ・ユーザーとして、SQL*Plusを使用してwritetab表の内容を問い合せます。

SQL> SELECT * FROM writetab;

PK ATTR
---------- -------------------------------
100 Oracle
102 Cache

SQL> exit

TimesTenシステムおよびOracle Databaseシステムのクリーンアップ

キャッシュ・グリッドおよびキャッシュ・グループを作成する前に、次のタスクを完了して、TimesTenシステムおよびOracle Databaseシステムを元の状態にリストアします。

1. キャッシュ・グリッドからTimesTenデータベースをデタッチします。

2. レプリケーション・エージェントを停止します。

3. キャッシュ・グループを削除します。

4. キャッシュ・グリッドを破棄します。

5. キャッシュ・エージェントを停止し、TimesTenデータベースを破棄します。

6. Oracle Databaseのユーザーおよびオブジェクトの削除。

キャッシュ・グリッドからのTimesTenデータベースのデタッチ

ttIsqlユーティリティを起動して、cachealone1 DSNにキャッシュ・マネージャ・ユーザーとして接続します。グリッドにアタッチしたため、ttIsqlを使用してttGridDetach組込みプロシージャをコールし、TimesTenデータベースをmyGridキャッシュ・グリッドからデタッチします。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttGridDetach;

TimesTenデータベースをキャッシュ・グリッドからデタッチした場合の影響の詳細は、「キャッシュ・グリッドからのTimesTenデータベースのデタッチ」を参照してください。

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

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してttRepStop組込みプロシージャをコールし、TimesTenデータベースでレプリケーション・エージェントを停止します。

Command> call ttRepStop;
Command> exit

レプリケーション・エージェントの停止方法の詳細は、「レプリケーション・エージェントの管理」を参照してください。

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

ttIsqlユーティリティを開始して、cachealone1 DSNにインスタンス管理者として接続します。ttIsqlを使用して、DROP ANY TABLE権限をキャッシュ・マネージャ・ユーザーに付与し、このユーザーがキャッシュ・グループを削除するときに基礎となるキャッシュ表を削除できるようにします。

% ttIsql cachealone1
Command> GRANT DROP ANY TABLE TO cacheuser;
Command> exit

ttIsqlユーティリティを起動して、cachealone1 DSNにキャッシュ・マネージャ・ユーザーとして接続します。ttIsqlを使用して、readcache読取り専用キャッシュ・グループおよびwritecache AWTキャッシュ・グループを削除します。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> DROP CACHE GROUP readcache;
Command> DROP CACHE GROUP writecache;

キャッシュ・グループreadcacheおよびwritecacheに加えて、それぞれのキャッシュ表oratt.readtabおよびoratt.writetabが、TimesTenデータベースから削除されます。

キャッシュ・グループの削除の詳細は、「キャッシュ・グループの削除」を参照してください。

キャッシュ・グリッドの破棄

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してttGridDestroy組込みプロシージャをコールし、myGridキャッシュ・グリッドを破棄します。

Command> call ttGridDestroy('myGrid');

キャッシュ・グリッドの破棄の詳細は、「キャッシュ・グリッドの破棄」を参照してください。

キャッシュ・エージェントの停止およびTimesTenデータベースの破棄

キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティを使用してttCacheStop組込みプロシージャをコールし、TimesTenデータベースでキャッシュ・エージェントを停止します。

Command> call ttCacheStop;
Command> exit

キャッシュ・エージェントの停止方法の詳細は、「キャッシュ・エージェントの管理」を参照してください。

次に、ttDestroyユーティリティを使用して、cachealone1 DSNに接続し、TimesTenデータベースを破棄します。

% ttDestroy cachealone1

Oracle Databaseのユーザーおよびオブジェクトの削除

SQL*Plusを起動し、sysユーザーとしてOracle Databaseに接続します。SQL*Plusを使用して、timestenユーザー、スキーマ・ユーザーorattおよびキャッシュ管理ユーザーcacheuserを削除します。

% sqlplus sys as sysdba
Enter password: password
SQL> DROP USER timesten CASCADE;
SQL> DROP USER oratt CASCADE;
SQL> DROP USER cacheuser CASCADE;

DROP USER文のCASCADEを指定すると、ユーザーそのものが削除される前に、そのユーザーが所有するすべてのオブジェクト(表やトリガーなど)が削除されます。

次に、SQL*Plusを使用して、TT_CACHE_ADMIN_ROLEロールを削除します。

SQL> DROP ROLE TT_CACHE_ADMIN_ROLE;

次に、SQL*Plusを使用して、timestenユーザーおよびキャッシュ管理ユーザーによって使用され、表領域およびそのデータ・ファイルの内容などを含むデフォルトの表領域cachetblspを削除します。

SQL> DROP TABLESPACE cachetblsp INCLUDING CONTENTS AND DATAFILES;
SQL> exit

3 キャッシュ・インフラストラクチャの設定

次の各項では、TimesTenデータベースへのOracle Databaseデータのキャッシュを開始するために、TimesTenシステムおよびOracle Databaseシステムを設定するためのタスクについて説明します。

- TimesTenにOracle Databaseデータをキャッシュするためのシステムの構成

- TimesTenにデータをキャッシュするためのOracle Databaseの構成

- Oracle DatabaseデータをキャッシュするためのTimesTenデータベースの構成

- データ管理の構成

- TimesTenデータベースとOracle Database間での接続テスト

- キャッシュ・エージェントの管理

TimesTenにOracle Databaseデータをキャッシュするためのシステムの構成

TimesTen Application-Tier Database Cacheでは、次のリリースのOracle Databaseサーバーがサポートされています。

- Oracle 11gリリース2(11.2.0.2.0以上)

- Oracle 11g リリース1(11.1.0.7.0以上)

- Oracle 10gリリース2(10.2.0.5.0以上)

「TimesTen Application-Tier Database Cacheの環境変数(UNIX)」または「TimesTen Application-Tier Database Cacheの環境変数(Microsoft Windows)」の説明に従って、特定のオペレーティング・システム用に環境変数を設定します。

次に、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の説明に従って、TimesTenをインストールします。

注意:
製品の観点からは、Oracle TimesTen In-Memory DatabaseがTimesTen Application-Tier Database Cache製品オプションに含まれるため、TimesTen Application-Tier Database CacheはTimesTenと同じ意味で使用されます。

TimesTenでは、WindowsクライアントのOracle Name Serverはサポートされていません。

TimesTen Application-Tier Database Cacheの環境変数(UNIX)

LD_LIBRARY_PATH、SHLIB_PATHなどの共有ライブラリ検索パスの環境変数に、TimesTen_install_dir/libディレクトリが含まれている必要があります。

詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の共有ライブラリ・パス環境変数に関する説明を参照してください。

PATH環境変数に、TimesTen_install_dir/binディレクトリが含まれている必要があります。

次の例では、TimesTenは/timesten/myinstanceディレクトリにインストールされています。

LD_LIBRARY_PATH=/timesten/myinstance/lib
PATH=/timesten/myinstance/bin

TimesTen Application-Tier Database Cacheの環境変数(Microsoft Windows)

PATHシステム環境変数に、次のディレクトリが含まれている必要があります。

- Oracle_install_dir\bin

- TimesTen_install_dir\lib

- TimesTen_install_dir\bin

次の例では、Oracle DatabaseはC:\oracle\ora112ディレクトリに、TimesTenはC:\timesten\myinstanceディレクトリにインストールされています。

PATH=C:\oracle\ora112\bin;C:\timesten\myinstance\lib;C:\timesten\myinstance\bin

TimesTenにデータをキャッシュするためのOracle Databaseの構成

次の各項では、sysユーザーがOracle Databaseに対して実行する必要があるタスクについて説明します。

- Oracle Databaseユーザーの作成

- Oracle Databaseユーザーへの権限の付与

- Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成

- Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成

Oracle Databaseユーザーの作成

デフォルトの表領域およびキャッシュ操作に関する情報を格納するOracle Database表の所有者となるユーザーtimestenを作成する必要があります。

timestenユーザーのデフォルトの表領域を作成または指定しますが、この表領域が、引数としてinitCacheGlobalSchema.sqlスクリプトに渡されます。この表領域は、他のアプリケーションと共有しないTimesTen Application-Tier Database Cache管理オブジェクトの格納に使用されます。TimesTenでキャッシュしたOracle実表も格納できますが、キャッシュ管理のために、この表領域をTimesTenのみで使用することを強く推奨します。

次を作成するSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/initCacheGlobalSchema.sqlを実行します。

- timestenユーザー

- キャッシュ・グリッド(構成されている場合)を含むキャッシュ環境に関する情報を格納するためにtimestenユーザーが所有するOracle Database表

- Oracle Database表に対する権限を定義するTT_CACHE_ADMIN_ROLEロール

timestenユーザーが所有するOracle Database表のリストについては、「Oracle Databaseオブジェクトによるキャッシュ環境の管理」を参照してください。

例3-1 timestenユーザーおよびその表の作成

次のSQL*Plusの例では、timestenユーザー用に作成されるデフォルトの表領域はcachetblspです。

% cd TimesTen_install_dir/oraclescripts
% sqlplus sys as sysdba
Enter password: password
SQL> CREATE TABLESPACE cachetblsp DATAFILE 'datfttuser.dbf' SIZE 100M;
SQL> @initCacheGlobalSchema "cachetblsp"

TimesTenデータベースにキャッシュされるOracle Database表の所有者となる、1人以上のユーザーを作成または指定します。これらのユーザーはスキーマ・ユーザーです。既存ユーザーまたは新規ユーザーをスキーマ・ユーザーにすることができます。キャッシュされる表は、新規でも既存でもかまいません。

例3-2 スキーマ・ユーザーの作成

sysユーザーとして、次のSQL*Plusの例では、スキーマ・ユーザーorattを作成します。

SQL> CREATE USER oratt IDENTIFIED BY oracle;

次に、TimesTenデータベースのキャッシュ環境(構成されている場合はキャッシュ・グリッドを含みます)を管理するために使用される情報を格納するOracle Databaseオブジェクトを作成、所有および保持するユーザーを作成し、特定のキャッシュ・グリッド・タイプの定義済動作を実行する必要があります。このようなユーザーは、キャッシュ管理ユーザーと呼ばれます。

注意:
各TimesTenデータベースは、Oracle Databaseの1人のキャッシュ管理ユーザーによってのみ管理が可能です。ただし、1人のキャッシュ管理ユーザーは、複数のTimesTenデータベースを管理できます。1人以上のキャッシュ管理ユーザーを指定できますが、その場合は、それぞれが1つ以上のTimesTenデータベースを管理します。
詳細は、「2つ以上のTimesTenデータベースにおける同じOracle表のキャッシュ」を参照してください。

キャッシュ管理ユーザー用のデフォルトの表領域として、timestenユーザー用に作成した表領域を指定します。このユーザーは、この表領域にキャッシュ環境およびそのキャッシュ・グループの情報を格納するために使用される表を作成します。自動リフレッシュ・キャッシュ・グループおよびAWTキャッシュ・グループの定義済動作の実行に使用されるその他のOracle Databaseオブジェクト(変更ログ表、レプリケーション・メタデータ表、トリガーなど)は、同じ表領域に作成されます。これらのオブジェクトを作成および管理するには、キャッシュ管理ユーザーが高レベルの権限を持っている必要があります。

注意:
複数のキャッシュ管理ユーザーを作成する場合は、各キャッシュ管理ユーザーは、デフォルトの表領域として同じまたは別の表領域を使用できます。

キャッシュ管理ユーザーが所有するOracle Database表およびトリガーのリストについては、「Oracle Databaseオブジェクトによるキャッシュ環境の管理」を参照してください。

注意:
自動リフレッシュ・キャッシュ・グループとは、AUTOREFRESH MODE INCREMENTALキャッシュ・グループ属性を使用する読取り専用キャッシュ・グループまたはユーザー管理キャッシュ・グループのことです。

例3-3 キャッシュ管理ユーザーの作成

sysユーザーとして、キャッシュ管理ユーザーcacheuserを作成します。次の例では、cacheuserユーザーのデフォルトの表領域はcachetblspです。

SQL*Plusを使用してキャッシュ管理ユーザーを作成します。

SQL> CREATE USER cacheuser IDENTIFIED BY oracle
2  DEFAULT TABLESPACE cachetblsp QUOTA UNLIMITED ON cachetblsp;

Oracle Databaseユーザーへの権限の付与

キャッシュ管理ユーザーには、作成したキャッシュ・グループ・タイプおよびそのキャッシュ・グループで実行する操作に応じて、高レベルの権限を付与する必要があります。SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/grantCacheAdminPrivileges.sqlをsysユーザーで実行して、キャッシュ・グリッド処理およびキャッシュ・グループ処理を実行するために必要な最小限の権限セットをキャッシュ管理ユーザーに付与できます。このSQLスクリプトの詳細は、「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成」を参照してください。

このユーザーの各キャッシュ操作に必要な権限のリスト全体は、表A-1の最初の列にリストされています(詳細は「キャッシュ管理ユーザーおよびキャッシュ・マネージャ・ユーザーに必要な権限」を参照)。

Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成

TimesTenでは、特定のキャッシュ環境処理、キャッシュ・グループ処理およびキャッシュ・グリッド処理が実行されるときに、キャッシュ管理ユーザーによって所有されるOracle Databaseオブジェクト(キャッシュおよびレプリケーション・メタデータ表、変更ログ表、トリガーなど)を自動的に作成できます。これらのオブジェクトの一部は、特定のキャッシュ・グリッドに関連付けられたTimesTenデータベースの情報を格納するために使用されます。その他のオブジェクトは、自動リフレッシュ・キャッシュ・グループおよびAWTキャッシュ・グループの定義済動作を実行するために使用されます。

sysユーザーとしてSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/grantCacheAdminPrivileges.sqlを実行することによって、必要な権限がキャッシュ管理ユーザーに付与されている場合、これらのOracle Databaseオブジェクトは自動的に作成されます。必要な権限セットには、CREATE SESSION、RESOURCE、CREATE ANY TRIGGERおよびTT_CACHE_ADMIN_ROLEロールが含まれます。キャッシュ管理ユーザー名は、引数としてgrantCacheAdminPrivileges.sqlスクリプトに渡されます。

注意:
また、セキュリティを確保するために、これらの表およびトリガーの自動作成に必要なRESOURCEおよびCREATE ANY TRIGGER権限をキャッシュ管理ユーザーに付与しない場合は、キャッシュ・グリッド処理またはキャッシュ・グループ処理を実行する前に、これらのオブジェクトを手動で作成することもできます(「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」を参照)。

作成するキャッシュ・グループのタイプおよびキャッシュ・グループやキャッシュ表に対して実行する処理によっては、grantCacheAdminPrivileges.sqlスクリプトの実行によってキャッシュ管理ユーザーに付与される権限の他に、キャッシュされたOracle Database表に対するSELECTやINSERTなどの権限も必要になる場合があります。特定のキャッシュ・グリッド処理、キャッシュ・グループ処理およびキャッシュ表処理を実行するために、キャッシュ管理ユーザーに付与する必要のある権限の完全なリストについては、表A-1を参照してください。

例3-4 Oracle Databaseオブジェクトを自動作成する権限の付与

sysユーザーとしてgrantCacheAdminPrivileges.sqlスクリプトを実行し、キャッシュ管理ユーザーに対して、TimesTenデータベースでOracle Databaseデータのキャッシュを管理するためのOracle Databaseオブジェクトを自動作成する権限を付与します。次の例では、キャッシュ管理ユーザー名はcacheuserです。

SQL*Plusを使用して、grantCacheAdminPrivileges.sqlスクリプトを実行します。

SQL> @grantCacheAdminPrivileges "cacheuser"
SQL> exit

たとえば、自動リフレッシュ・キャッシュ・グループでは、キャッシュ・グループ・タイプの定義済動作の実行に必要なOracle Databaseオブジェクトがまだ存在しておらず、次のいずれかの状況が発生している場合、これらのオブジェクトが自動的に作成されます。

- 自動リフレッシュ状態がPAUSEDまたはONに設定されたキャッシュ・グループが作成されている。

- 自動リフレッシュ状態がOFFに設定されたキャッシュ・グループが作成され、その後、状態はPAUSEDまたはONに変更されている。

Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成

次の目的で使用されるOracle Databaseオブジェクトを自動作成するには、キャッシュ管理ユーザーにRESOURCE権限が必要です。

- 特定のキャッシュ環境(構成されている場合はキャッシュ・グリッドを含む)に関連付けられたTimesTenデータベースの情報の格納。

- 自動リフレッシュ・キャッシュ・グループの定義済動作を実行します。この場合、Oracle Databaseオブジェクトを自動作成するには、キャッシュ管理ユーザーにCREATE ANY TRIGGER権限も必要です。

- AWTキャッシュ・グループの定義済動作の実行。

セキュリティ上の理由から、Oracle Databaseオブジェクトの自動作成に必要なRESOURCE権限およびCREATE ANY TRIGGER権限をキャッシュ管理ユーザーに付与しない場合は、これらのオブジェクトを手動で作成できます。

特定のキャッシュ・グループ・タイプの定義済動作を実行するために使用されるOracle Database表およびトリガーを手動で作成するには、sysユーザーとして、SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/initCacheAdminSchema.sqlを実行します。これらのオブジェクトは、自動リフレッシュ・キャッシュ・グループおよびAWTキャッシュ・グループを作成する前に作成する必要があります。キャッシュ管理ユーザー名は、引数としてinitCacheAdminSchema.sqlスクリプトに渡されます。

また、initCacheAdminSchema.sqlスクリプトによって、CREATE SESSIONおよびTT_CACHE_ADMIN_ROLEロールを含む必要な最小限の権限セットもキャッシュ管理ユーザーに付与されます。作成するキャッシュ・グループのタイプおよびキャッシュ・グループやキャッシュ表に対して実行する処理によっては、initCacheAdminSchema.sqlスクリプトの実行によってキャッシュ管理ユーザーに付与される権限の他に、キャッシュされたOracle Database表に対するSELECTやINSERTなどの権限も必要になる場合があります。特定のキャッシュ・グリッド処理、キャッシュ・グループ処理およびキャッシュ表処理を実行するために、キャッシュ管理ユーザーに付与する必要のある権限の完全なリストについては、表A-1を参照してください。

特定のキャッシュ・グリッドと関連付けられたTimesTenデータベースの情報を格納するために使用されるOracle Database表を手動で作成するには、sysユーザーとして、SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/initCacheGridSchema.sqlを実行します。これらの表は、キャッシュ・グリッドを作成する前に作成する必要があります。キャッシュ管理ユーザー名および作成するキャッシュ・グリッド名は、引数としてinitCacheGridSchema.sqlスクリプトに渡されます。

例3-5 Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成

sysユーザーとしてinitCacheAdminSchema.sqlスクリプトを実行し、自動リフレッシュ・キャッシュ・グループおよびAWTキャッシュ・グループの定義済動作を実行するために使用されるOracle Databaseオブジェクトを手動で作成し、キャッシュ管理ユーザーに対して制限された権限セットを付与します。次に、initCacheGridSchema.sqlスクリプトを実行して、特定のキャッシュ・グリッドに関連付けられたTimesTenデータベースの情報を格納するために使用されるOracle Databaseオブジェクトを手動で作成します。次の例では、キャッシュ管理ユーザー名はcacheuser、キャッシュ・グリッド名はttGridです。

SQL*Plusを使用して、initCacheAdminSchema.sqlおよびinitCacheGridSchema.sqlスクリプトを実行します。

SQL> @initCacheAdminSchema "cacheuser"
SQL> @initCacheGridSchema "cacheuser" "ttGrid"
SQL> exit

自動リフレッシュ・キャッシュ・グループにキャッシュされるOracle Database表に関連付けられたその他のOracle Databaseオブジェクトは、これらのキャッシュ・グループ・タイプの定義済動作を実行するために必要になります。キャッシュ・グループを作成した後にこれらの追加オブジェクトを作成する方法の詳細は、「自動リフレッシュ・キャッシュ・グループ用のOracle Databaseオブジェクトの手動による作成」を参照してください。

Oracle Databaseデータのキャッシュを管理するためにTimesTenが作成して使用するOracle Databaseオブジェクトのリストを表示するには、sysユーザーとしてSQL*Plusで次の問合せを実行します。

SQL> SELECT owner, object_name, object_type FROM all_objects WHERE object_name
2  LIKE 'TT\___%' ESCAPE '\';

この問合せによって、timestenユーザーまたはキャッシュ管理ユーザーが所有している表、索引およびトリガーのリストが返されます。

Oracle DatabaseデータをキャッシュするためのTimesTenデータベースの構成

次の各項では、インスタンス管理者またはキャッシュ・マネージャ・ユーザーがTimesTenデータベースで実行する必要がある処理について説明します。

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

- TimesTenユーザーの作成

- TimesTenユーザーへの権限の付与

- キャッシュ管理ユーザーの名前およびパスワードの設定

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

Oracle DatabaseのデータをキャッシュするTimesTenデータベースは、システムDSNまたはユーザーDSNのいずれかによって参照できます。TimesTen DSNの作成の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明を参照してください。

Oracle DatabaseのデータをキャッシュするTimesTenデータベースのDSNを作成する場合は、次の接続属性の設定に特に注意します。これらの接続属性は、他に示されていないかぎり、すべてデータ・マネージャDSNまたは接続文字列で設定できます。

- PermSizeには、データベースの永続領域の割当てサイズをMBで指定します。この値は32MB以上に設定します。

- OracleNetServiceNameは、Oracle Databaseインスタンスのネット・サービス名に設定する必要があります。
Microsoft Windowsシステムの場合、Oracle Databaseインスタンスのネット・サービス名は、「TimesTen ODBC Setup」ダイアログ・ボックスにある「TimesTen Cache」タブの「Oracle Net Service Name」フィールドで指定します。

- DatabaseCharacterSetは、Oracle Databaseキャラクタ・セットに設定する必要があります。
任意のユーザーとしてSQL*Plusで次の問合せを実行すると、Oracle Databaseキャラクタ・セットを確認できます。

SQL> SELECT value FROM nls_database_parameters
2 WHERE parameter='NLS_CHARACTERSET';

- UIDには、キャッシュされたOracle Database表にアクセスできるコンパニオンOracle Databaseユーザーと同じ名前のキャッシュ・ユーザー(キャッシュ・マネージャ・ユーザーなど)の名前を指定します。UID接続属性は、データ・マネージャDSN、クライアントDSNまたは接続文字列で指定できます。

- PWDには、UID接続属性で指定したTimesTenユーザーのパスワードを指定します。PWD接続属性は、データ・マネージャDSN、クライアントDSNまたは接続文字列で指定できます。

- OraclePWDには、UID接続属性で指定したTimesTenユーザーと同じ名前で、キャッシュされたOracle Database表にアクセスできる、コンパニオンOracle Databaseユーザーのパスワードを指定します。

注意:
キャッシュ・マネージャ・ユーザーおよびコンパニオンOracle Databaseユーザーの詳細は、「TimesTenユーザーの作成」を参照してください。

- PassThroughには、文をTimesTenデータベースで実行するかOracle Databaseにパススルーして実行するかの制御を設定できます。「パススルー・レベルの設定」を参照してください。

- LockLevelは、TimesTen Application-Tier Database Cacheではデータベース・レベル・ロックがサポートされていないため、デフォルトの0(行レベル・ロック)に設定する必要があります。

- TypeModeは、デフォルトの0に設定する必要があります(Oracle Databaseタイプ・モード)。

- ReplicationApplyOrderingおよびCacheAWTParallelismでは、AWTキャッシュ・グループのTimesTenキャッシュ表に対して行われた変更を対応するOracle Database表へ伝播するパラレル伝播を制御します。「Oracle Database表へのパラレル伝播の構成」を参照してください。

- CacheGridEnableでは、グローバル・キャッシュ・グループを管理するためにキャッシュ・グリッドを作成するかどうかを構成します。キャッシュ・グリッドを使用する予定がない場合は0を、キャッシュ・グリッドを使用する予定がある場合は1を設定します。

例3-6 Oracle DatabaseのデータをキャッシュするTimesTenデータベースのDSN

次に、ttGridキャッシュ・グリッドのメンバーになる最初のスタンドアロンTimesTenデータベースを参照する、cachealone1 DSNの定義例を示します。

[cachealone1]
DataStore=/users/OracleCache/alone1
PermSize=64
OracleNetServiceName=orcl
DatabaseCharacterSet=WE8ISO8859P1
CacheGridEnable=1

TimesTenユーザーの作成

最初に、キャッシュ・グリッド処理(構成されている場合)およびキャッシュ・グループ処理を実行するユーザーを作成する必要があります。このようなユーザーは、キャッシュ・マネージャ・ユーザーと呼ばれます。TimesTenキャッシュ管理ユーザーは、キャッシュされたOracle Database表にアクセスできるコンパニオンOracle Databaseユーザーと同じ名前である必要があります。たとえば、コンパニオンOracle Databaseユーザーは、キャッシュされたOracle Database表から選択して更新する権限を持っている必要があります。コンパニオンOracle Databaseユーザーは、キャッシュ管理ユーザー、スキーマ・ユーザーまたはその他の既存ユーザーにすることができます。使いやすくするために、キャッシュ管理ユーザーをキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーにすることをお薦めしますが、キャッシュ管理ユーザーに割り当てられる高レベルの権限が心配な場合は、コンパニオンOracleユーザーには別のOracle Databaseユーザーを選択してください。キャッシュ・マネージャ・ユーザーのパスワードは、同じ名前を持つコンパニオンOracle Databaseユーザーとは別のパスワードにすることができます。

注意:
TimesTenデータベースには複数のキャッシュ・マネージャ・ユーザー(各TimesTen DBAごとに1人など)を作成できます。ただし、この特定のTimesTenデータベースのOracle Databaseには1人のキャッシュ管理ユーザーのみを定義できます。(Oracle Databaseに接続するすべてのTimesTenデータベースに同じキャッシュ管理ユーザーを使用するか、TimesTenデータベースごとに別のキャッシュ管理ユーザーを定義できます。)複数のキャッシュ・マネージャ・ユーザーを作成する場合、このうちの1人以上のユーザーは、キャッシュ管理ユーザーをコンパニオンOracleユーザーとして使用できます。

キャッシュ・マネージャ・ユーザーは、キャッシュ・グリッド(構成されている場合)を作成および構成し、キャッシュ・グループを作成します。キャッシュ・マネージャ・ユーザーは、キャッシュ・グループのロードやリフレッシュなどの処理を実行できますが、これらの処理は十分な権限を持つTimesTenユーザーも実行できます。また、キャッシュ・マネージャ・ユーザーは、グリッド自体や、キャッシュ・グループに対して実行される非同期処理(例: 自動リフレッシュ)など、キャッシュ環境の様々な側面を監視することもできます。

次に、TimesTenデータベースにキャッシュされるOracle Database表を現在所有しているか、または今後所有することになるスキーマ・ユーザーごとに、Oracle Databaseスキーマ・ユーザーと同じ名前のユーザーを作成する必要があります。これらのユーザーは、TimesTenキャッシュ表を所有するユーザーとなるため、キャッシュ表ユーザーと呼ばれます。つまり、TimesTenキャッシュ表の所有者および名前は、対応するキャッシュされたOracle Database表の所有者および名前と同じになります。キャッシュ表ユーザーのパスワードは、同じ名前を持つOracle Databaseスキーマ・ユーザーとは別のパスワードにすることができます。

キャッシュ・グループまたはキャッシュ表に対する処理(キャッシュ・グループのロードやキャッシュ表の更新など)は、十分な権限を持ついずれのTimesTenユーザーでも実行できます。このマニュアルの例では、キャッシュ・マネージャ・ユーザーがこれらのタイプの処理を実行していますが、必要な権限を持つ別のユーザー(キャッシュ表ユーザーなど)でもこれらの処理を実行できます。これらの処理がキャッシュ・マネージャ・ユーザー以外のTimesTenユーザーによって実行される場合、その他のユーザーは、キャッシュされたOracle Database表を選択して更新できるコンパニオンOracle Databaseユーザーと同じ名前にする必要があります。UID接続属性にそのユーザーの名前を指定してTimesTenデータベースに接続し、PWD接続属性およびOraclePWD接続属性に、対応するTimesTenパスワードおよびOracle Databaseパスワードをそれぞれ入力して、キャッシュ・グループまたはキャッシュ表に対する処理を実行します。

例3-7 TimesTenユーザーの作成

次のttIsqlユーティリティの例では、cachealone1 DSNにインスタンス管理者として接続してTimesTenデータベースを作成します。次に、キャッシュ・マネージャ・ユーザーcacheuserを作成しますが、この例では、このユーザーの名前はキャッシュ管理ユーザーと同じであり、このユーザーはキャッシュ・マネージャのコンパニオンOracleユーザーとして機能します。さらに、TimesTenデータベースにキャッシュされるOracle Database表の所有者となる、Oracle Databaseスキーマ・ユーザーと同じ名前でキャッシュ表ユーザーorattを作成します。

% ttIsql cachealone1
Command> CREATE USER cacheuser IDENTIFIED BY timesten;
Command> CREATE USER oratt IDENTIFIED BY timesten;

TimesTenユーザーへの権限の付与

TimesTenユーザーに必要な権限は、作成するキャッシュ・グループのタイプおよびキャッシュ・グループに対して実行する処理によって異なります。各キャッシュ処理のためにTimesTenのキャッシュ・マネージャ・ユーザーに必要なすべての権限は、表A-1の2番目の列にリストされています。

例3-8 キャッシュ・マネージャ・ユーザーに対する権限の付与

キャッシュ・マネージャ・ユーザーcacheuserには、次の処理を実行する権限が必要です。

- キャッシュ管理ユーザーおよびパスワードの設定(CACHE_MANAGER)。

- TimesTenデータベースの作成およびキャッシュ・グリッドとの関連付け(CACHE_MANAGER)。

- TimesTenデータベースでのキャッシュ・エージェント・プロセスおよびレプリケーション・エージェント・プロセスの開始(CACHE_MANAGER)。

- キャッシュ・グリッドへのTimesTenデータベースのアタッチ(CACHE_MANAGER)。

- キャッシュ・マネージャ・ユーザーによって所有されるキャッシュ・グループの作成(CACHE_MANAGER権限で継承されるCREATE CACHE GROUP、orattキャッシュ表ユーザーが所有する基本となるキャッシュ表を作成するためのCREATE ANY TABLE)。

インスタンス管理者として、ttIsqlユーティリティを使用して、キャッシュ・マネージャ・ユーザーcacheuserに必要な権限を付与します。

Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE TO cacheuser;
Command> exit

キャッシュ管理ユーザーの名前およびパスワードの設定

ttCacheUidPwdSet組込みプロシージャでキャッシュ・グリッド処理またはキャッシュ・グループ処理を発行するには、TimesTenデータベースにキャッシュ管理ユーザーの名前およびパスワードを設定する必要があります。キャッシュ・エージェントはこのユーザーとしてOracle Databaseに接続して、キャッシュ・グリッドの管理に使用される情報を格納したり、特定のキャッシュ・グループ・タイプの定義済動作を実行するために使用されるOracle Databaseオブジェクトを作成および保持します。さらに、キャッシュ・エージェントおよびレプリケーション・エージェントはどちらも、Oracle Database操作を管理するために、ttCacheUidPwdSet組込みプロシージャを使用して設定した資格証明を使用してOracle Databaseに接続します。

注意:
AWTまたは読取り専用グループと連携するためにTimesTenデータベースを接続する場合は、TimesTenでは、これらのキャッシュ・グループにかわってOracle Databaseに接続する際にttCacheUidPwdSet組込みプロシージャで設定した資格証明が使用されます。
SWTまたはユーザー管理のキャッシュ・グループ処理やパススルー処理と連携するためにTimesTenデータベースに接続する場合、TimesTenは、ユーザーの現在の資格証明をユーザー名に、OraclePwd接続属性をOracleパスワードに使用してOracle Databaseに接続します。そのため、Oracle Databaseへの接続に使用される正しいユーザー名およびOracle Databaseのパスワードは、接続文字列または接続属性を使用して正しく設定する必要があります。

キャッシュ管理ユーザーの名前およびパスワードは、変更する必要がないかぎり、Oracle DatabaseデータをキャッシュするTimesTenデータベースごとに1回のみ設定する必要があります。たとえば、キャッシュ管理ユーザーのパスワードを変更した場合、TimesTenデータベースが破棄されて再作成された場合またはキャッシュ管理ユーザーの名前がOracle Databaseで削除されて再作成された場合は、キャッシュ管理ユーザーの名前およびパスワードをもう一度設定する必要があります。

データベースにキャッシュ・グループが存在する場合は、キャッシュ管理ユーザーの名前は変更できません。キャッシュ管理ユーザーを削除して再作成する前に、キャッシュ・グループを削除する必要があります。詳細は、「キャッシュ・ユーザー名およびパスワードの変更」を参照してください。

例3-9 キャッシュ管理ユーザーの名前およびパスワードの設定

キャッシュ管理ユーザーの名前およびパスワードは、キャッシュ・マネージャ・ユーザーとして接続した後に、ttCacheUidPwdSet組込みプロシージャをコールすることによって、プログラムで設定できます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttCacheUidPwdSet('cacheuser','oracle');

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -cacheUidPwdSetユーティリティ・コマンドを実行することによって、コマンドラインから実行することもできます。

% ttAdmin -cacheUidPwdSet -cacheUid cacheuser -cachePwd oracle cachealone1

-cachePwdオプションを指定しなかった場合、ttAdminユーティリティによってキャッシュ管理ユーザーのパスワードを入力するように求められます。

このユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

データ管理の構成

キャッシュされたデータをTimesTenが管理する方法は、1つのTimesTenデータベースでのローカルに管理するか、複数のTimesTenインメモリー・データベースでグローバルに管理するかのいずれかで構成できます。

- データをローカルで管理します(この場合、各TimesTenインメモリー・データベースは他のTimesTenインメモリー・データベースとは別個に動作します)。このオプションは簡単ですが、TimesTenでは、TimesTenインメモリー・データベースすべてにわたるデータの一貫性が管理されません。詳細は、「ローカルでのデータの管理」を参照してください。

- キャッシュ・グリッドを使用し、複数のTimesTenインメモリー・データベースにわたってデータをグローバルに管理します。これはデフォルトの方法です。キャッシュ・グリッドとは、グローバル・キャッシュ・グループ内にあるアプリケーション・データをまとめて管理するTimesTen Cacheデータベースの集合のことです。キャッシュ・グリッドには一連の分散TimesTenインメモリー・データベースがあり、Oracle Databaseからデータをキャッシュし、このTimesTenデータベースにあるグローバル・キャッシュ・グループのキャッシュ一貫性を確保するために連携します。詳細は、「キャッシュ・グリッドの構成」を参照してください。

ローカルでのデータの管理

グローバル・キャッシュ・グループを使用する場合は、キャッシュ・グリッドを作成する必要はありません。この場合は、CacheGridEnable接続属性を0に設定します(「TimesTenデータベースのDSNの定義」に説明するとおり、DSNで構成できます)。

この接続属性では、グローバル・キャッシュ・グループを使用しないことが指定されています。一度設定したら、TimesTenでは、データベース内にキャッシュ・グループを作成する前に、キャッシュ・グリッドを作成したり、そのグリッドにTimesTenデータベースを関連付ける必要はありません。

注意:
同じOracle Databaseと対話する複数のTimesTenインメモリー・データベースを作成できますが、それぞれが独立して動作します。そのため、別個のTimesTenデータベースにキャッシュされたデータは、Oracle Databaseと個別に対話します。
読取りおよび書込みデータの一貫性とデータベース・トランザクションの予測可能な待機時間を保持しながら、複数のTimesTenデータベースにまたがってデータを拡大する必要がある場合は、キャッシュ・グリッドを使用してください。

このオプションを使用すると、そのデータベース内にグローバル・キャッシュ・グループは作成できません。将来のある時点で、キャッシュ・グリッド内でグローバル・キャッシュ・グループを使用する場合は、次の手順を実行してください。

1. 既存のキャッシュ・グループをすべて削除します。

2. キャッシュ・グリッドを作成し、TimesTenインメモリー・データベースをメンバーとして関連付けます(「キャッシュ・グリッドの概要」を参照)。

3. 既存のキャッシュ・グループをすべて再作成します。

グローバル・キャッシュ・グループの詳細は、「グローバル・キャッシュ・グループ」を参照してください。

キャッシュ・グリッドの構成

1つのOracle Database表を、同じTimesTenデータベースにある別々のキャッシュ・グループにキャッシュすることはできません。ただし、異なるTimesTenデータベースにある別々のキャッシュ・グループにキャッシュすることは可能です。

TimesTenのキャッシュ・グリッドを使用すると、Oracle Databaseを使用するユーザーが、TimesTenデータベース全体での読取り/書込みデータの一貫性、および予測可能なデータベース・トランザクション待機時間を維持しながら、複数のシステムまたがって横方向にキャッシュ・グループを拡大できます。キャッシュ・グリッドは、リレーショナル・データ・モデルを使用してアプリケーション・データをまとめて管理する1つ以上のグリッド・メンバーで構成されています。グリッド・メンバーは、スタンドアロンのTimesTenデータベースであるか、またはレプリケートされた2つ以上のTimesTenデータベースで構成されるアクティブ・スタンバイ・ペアであるかのいずれかです。

グリッド・メンバーの各データベースは、グリッド・ノードと呼ばれます。ノードは、スタンドアロン・データベースか、アクティブ・スタンバイ・ペアのアクティブ・データベースまたはスタンバイ・データベースのいずれかである単一のTimesTenデータベースです。つまり、グリッド・メンバーは1つまたは2つのノードで構成されます。

注意:
キャッシュ表のレプリケートの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のキャッシュ・グループを含むアクティブ・スタンバイ・ペアの管理に関する説明を参照してください。

グリッド・メンバーは同じシステムまたは異なるシステムに存在できます。グリッド・メンバーが異なるシステムに存在する場合、システムは互いにTCP/IPプライベート・ネットワークで接続されている必要があります。各システムのマシン・アーキテクチャ、オペレーティング・システム・バージョン、プラットフォームおよびビット・バージョンは、同じである必要があります。すべてのグリッド・メンバーで、TimesTenメジャー・リリース番号が同じである必要があります。

グリッド・メンバーであるTimesTenデータベースまたはグリッド・メンバーに含まれるTimesTenデータベースには、ローカルおよびグローバルのキャッシュ・グループと、明示的にロードされるキャッシュ・グループおよび動的キャッシュ・グループを含めることができます。

注意:
動的キャッシュ・グループの詳細は、「動的キャッシュ・グループ」を参照してください。
グローバル・キャッシュ・グループの詳細は、「グローバル・キャッシュ・グループ」を参照してください。

キャッシュ・グリッドは、1つのOracle Databaseにのみ関連付けることができます。TimesTenデータベースは、1つのキャッシュ・グリッドのメンバーにのみすることができます。Oracle Databaseは2つ以上のキャッシュ・グリッドに関連付けることができ、各グリッドは異なるキャッシュ管理ユーザーで管理できます。キャッシュ・グリッドには、他のキャッシュ・グリッドとの関連付けはありません。

次の各項では、キャッシュ・マネージャ・ユーザーがTimesTenデータベースに対して実行する必要がある操作について説明します。

- 10個以上のグリッド・ノードに対するPROCESSESシステム・パラメータの変更

- キャッシュ・グリッドの作成

- TimesTenデータベースとキャッシュ・グリッドの関連付け

10個以上のグリッド・ノードに対するPROCESSESシステム・パラメータの変更

10個以上のノードを持つグリッドを作成する場合は、PROCESSES Oracle Databaseシステム・パラメータを変更します。次のガイドラインを使用します。

PROCESSES >= 10*GridMembers + DLConnections + OraBackgroundProcesses

各パラメータの意味は次のとおりです。

- GridMembers = グリッド・メンバーの数

- DLConnections = 動的ロード接続の数

- OraBackgroundProcesses = Oracle Databaseバックグラウンド・プロセスの数

動的ロード接続の数は、動的キャッシュ・グループ処理を行うセッションの数によって決定されます。

Oracle Databaseシステム・パラメータの変更の詳細は、Oracle Databaseリファレンスのパラメータ・ファイルのパラメータ値の変更に関する説明を参照してください。Oracle Databaseバックグラウンド・プロセスの詳細は、Oracle Databaseリファレンスのバックグラウンド・プロセスに関する説明を参照してください。

キャッシュ・グリッドの作成

このマニュアルの後半で使用されている例では、3つのグリッド・メンバー(2つのスタンドアロンTimesTenデータベースと、3つのTimesTenデータベースで構成される1つのアクティブ・スタンバイ・ペア)で構成されるキャッシュ・グリッドttGridを作成します。この章では、1つのスタンドアロン・データベースをキャッシュ・グリッドに関連付ける方法を示します。後続の章では、もう1つのスタンドアロン・データベースおよびアクティブ・スタンバイ・ペアの作成方法と、これらのメンバーをグリッドに関連付ける方法を示します。

最初のスタンドアロンTimesTenデータベースのDSN定義については、例3-6を参照してください。

任意のスタンドアロン・データベースか、アクティブ・スタンバイ・ペアのアクティブ・データベースまたはスタンバイ・データベースのいずれかからキャッシュ・グリッドを作成できます。キャッシュ・グリッドは、いずれか1つのグリッド・メンバーから1回のみ作成されます。

例3-10 キャッシュ・グリッドの作成

キャッシュ・マネージャ・ユーザーとしてttGridCreate組込みプロシージャをコールすることによって、最初のスタンドアロン・データベースからttGridキャッシュ・グリッドを作成します。

Command> call ttGridCreate('ttGrid');

アクティブ・スタンバイ・ペアの読取り専用サブスクライバ・データベースを除いて、これらの例のデータベースはすべてttGridキャッシュ・グリッドと関連付けられます。

「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」の説明に従って、特定のキャッシュ・グリッドに関連付けられたTimesTenデータベースの情報を格納するためのOracle Databaseオブジェクトを手動で作成している場合、initCacheGridSchema.sqlスクリプトの実行によってグリッドが作成されているため、ttGridCreateをコールする必要はありません。

データベースでキャッシュ・グループを作成する前に、TimesTenデータベースをキャッシュ・グリッドに関連付けることができます。キャッシュ・グリッドを使用しない場合は、CacheGridEnable接続属性を0に設定すると、キャッシュ・グリッドを作成してTimesTenデータベースをそのグリッドに関連付けることなく、そのデータベース内にキャッシュ・グループを作成できます。

グローバル・キャッシュ・グループの詳細は、「グローバル・キャッシュ・グループ」を参照してください。

CacheGridEnableは、デフォルトで1に設定されます。

TimesTenデータベースとキャッシュ・グリッドの関連付け

すべてのスタンドアロン・データベースと、アクティブ・スタンバイ・ペアのアクティブ・データベースおよびスタンバイ・データベースは、これらのデータベースでキャッシュ・グループを作成する前に、キャッシュ・グリッドと関連付ける必要があります。

例3-11 TimesTenデータベースとキャッシュ・グリッドの関連付け

キャッシュ・マネージャ・ユーザーとしてttGridNameSet組込みプロシージャをコールすることによって、最初のスタンドアロン・データベースをttGridキャッシュ・グリッドに関連付けます。

Command> call ttGridNameSet('ttGrid');

TimesTenデータベースとOracle Database間での接続テスト

TimesTenデータベースとOracle Database間の接続をテストするには、パススルー・レベルを3に設定して、Oracle Databaseで処理される次の問合せをキャッシュ・マネージャ・ユーザーとして実行します。

Command> passthrough 3;
Command> SELECT * FROM V$VERSION;
Command> passthrough 0;

接続が正しく確立されている場合は、問合せによってOracle Databaseのバージョンが返されます。バージョンが返されなかった場合は、次の設定が正しいかどうかを確認します。

- OracleNetServiceName接続属性のOracleネット・サービス名の設定およびOracle Databaseサーバーの状態

- LD_LIBRARY_PATH、SHLIB_PATHなどの共有ライブラリ検索パスの環境変数の設定

- TimesTenデータベースのキャッシュ管理ユーザー名の設定

例3-12 キャッシュ管理ユーザー名の設定の確認

キャッシュ管理ユーザー名の設定は、キャッシュ・マネージャ・ユーザーとしてttCacheUidGet組込みプロシージャをコールすることによって、プログラムで返すことができます。

Command> call ttCacheUidGet;

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -cacheUidGetユーティリティ・コマンドを実行することによって、コマンドラインから返すこともできます。

% ttAdmin -cacheUidGet cachealone1

キャッシュ・エージェントの管理

キャッシュ・エージェントは、キャッシュ・グループのロードや自動リフレッシュなどのキャッシュ処理を実行したり、特定のキャッシュ・グループ・タイプの定義済動作を実行するために使用するOracle Databaseオブジェクトを管理するTimesTenプロセスです。

例3-13 キャッシュ・エージェントの起動

キャッシュ・エージェントは、キャッシュ・マネージャ・ユーザーとしてttCacheStart組込みプロシージャをコールすることによって、プログラムから手動で起動できます。

Command> call ttCacheStart;

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -cacheStartユーティリティ・コマンドを実行することによって、コマンドラインから起動することもできます。

% ttAdmin -cacheStart cachealone1

例3-14 キャッシュ・エージェントの停止

キャッシュ・エージェントは、キャッシュ・マネージャ・ユーザーとしてttCacheStop組込みプロシージャをコールすることによって、プログラムから手動で停止できます。

Command> call ttCacheStop;

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -cacheStopユーティリティ・コマンドを実行することによって、コマンドラインから停止することもできます。

% ttAdmin -cacheStop cachealone1

ttCacheStop組込みプロシージャにはオプションのパラメータが、またttAdmin -cacheStopユーティリティ・コマンドにはオプション-stopTimeoutがあり、これらのオプションによってキャッシュ・エージェントが停止するまでTimesTenメイン・デーモン・プロセスが待機する時間を指定します。指定したタイムアウト時間内にキャッシュ・エージェントが停止しなかった場合、そのキャッシュ・エージェントはTimesTenデーモンによって停止されます。キャッシュ・エージェントのデフォルトの停止タイムアウトは100秒です。値0(ゼロ)は、永久に待機することを示します。

自動リフレッシュ・キャッシュ・グループを削除または変更した直後にキャッシュ・エージェントを停止しないでください。キャッシュ・グループを管理するために作成および使用されたOracle Databaseオブジェクト(変更ログ表やトリガーなど)をキャッシュ・エージェントがクリーンアップできるように、最低でも2分は待機してください。

注意:
TimesTen X/Open XAおよびJava Transaction API (JTA)の実装は、TimesTen Application-Tier Database Cacheでは動作しません。キャッシュ・エージェントを実行している場合、XAまたはJTAトランザクションは開始できません。

キャッシュ・エージェント起動ポリシーの設定

キャッシュ・エージェント起動ポリシーは、TimesTenデータベースでキャッシュ・エージェント・プロセスを起動する方法およびタイミングを決定します。キャッシュ・エージェント起動ポリシーは次に設定できます。

- manual

- always

- norestart

デフォルトの起動ポリシーはmanualであり、これはttCacheStart組込みプロシージャをコールするかttAdmin -cacheStartユーティリティ・コマンドを実行することによって、手動でキャッシュ・エージェントを起動する必要があることを意味します。実行しているキャッシュ・エージェント・プロセスを手動で停止するには、ttCacheStop組込みプロシージャをコールするかttAdmin -cacheStopユーティリティ・コマンドを実行します。

起動ポリシーをalwaysに設定すると、TimesTenメイン・デーモン・プロセスの起動時にキャッシュ・エージェントを自動的に起動できます。always起動ポリシーを使用しているときは、メイン・デーモンが実行している間、キャッシュ・エージェントを停止できませんが、停止する必要がある場合は、まず起動ポリシーをmanualまたはnorestartに変更します。次に、ttCacheStop組込みプロシージャをコールするかttAdmin -cacheStopユーティリティ・コマンドを実行して手動停止を発行します。

manualおよびalways起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後、データベースがリカバリされると、キャッシュ・エージェントは自動的に再起動します。障害発生時にデータベースがキャッシュ・グリッドにアタッチされていた場合は、データベースのリカバリ時に自動的にそのグリッドに再アタッチされます。

キャッシュ・エージェントの起動ポリシーをnorestartに設定した場合、キャッシュ・エージェントの起動はttCacheStart組込みプロシージャのコールまたはttAdmin -cacheStartユーティリティ・コマンドの実行により手動で行い、停止はttCacheStop組込みプロシージャのコールまたはttAdmin -cacheStopユーティリティ・コマンドの実行により手動で行う必要があります。

norestart起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後、データベースがリカバリされても、キャッシュ・エージェントは自動的に再起動されません。ttCacheStart組込みプロシージャをコールするか、ttAdmin -cacheStartユーティリティ・コマンドを実行して、キャッシュ・エージェントを手動で再起動する必要があります。障害発生時にデータベースがキャッシュ・グリッドにアタッチされていた場合も、データベースのリカバリ時に自動的にそのグリッドに再アタッチされることはありません。ttGridAttach組込みプロシージャをコールして、データベースをグリッドに再アタッチする必要があります。

注意:
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdmin、ttCachePolicySet、ttCacheStart、ttCachestopおよびttGridAttachに関する説明を参照してください。

例3-15 キャッシュ・エージェント起動ポリシーの設定

キャッシュ・エージェント起動ポリシーは、キャッシュ・マネージャ・ユーザーとしてttCachePolicySet組込みプロシージャをコールすることによって、プログラムで設定できます。

Command> call ttCachePolicySet('always');

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -cachePolicyユーティリティ・コマンドを実行することによって、コマンドラインから設定することもできます。

% ttAdmin -cachePolicy norestart cachealone1

4 キャッシュ・グループの定義

次の各項では様々なタイプのキャッシュ・グループとそれを定義する方法について説明します。

- キャッシュ・グループおよびキャッシュ表

- キャッシュ・グループの作成

- Oracle Databaseシノニムのキャッシュ

- Oracle Database LOBデータのキャッシュ

- キャッシュ・グループでのエージングの実装

- 動的キャッシュ・グループ

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

キャッシュ・グループおよびキャッシュ表

TimesTenデータベースにキャッシュするOracle Databaseデータは、キャッシュ・グループによって定義されます。キャッシュ・グループを作成すると、キャッシュされたOracle Database表に対応するキャッシュ表がTimesTenデータベースに作成されます。

キャッシュ・グループ定義には、キャッシュされるOracle Database表ごとに個別の表定義を指定する必要があります。TimesTenキャッシュ表の所有者、表名およびキャッシュされる列の名前は、対応するキャッシュ対象のOracle Database表の所有者、表名および列名と一致している必要があります。キャッシュ表に、キャッシュされたOracle Database表のすべての行と列または行と列のサブセットを格納できます。各TimesTenキャッシュ表には主キーが必要です。

キャッシュ・グループ表を定義する前に、キャッシュされるOracle Database表を作成します。各表は次のいずれかである必要があります。

- NULLを指定できない列に主キーがあるOracle Database表。TimesTenキャッシュ表の主キーは、全Oracle Database表の主キーで定義する必要があります。たとえば、キャッシュされたOracle Database表の列c1、c2およびc3に複合主キーがある場合、TimesTenキャッシュ表の列c1、c2およびc3にも複合主キーが必要です。
次の例では、複合主キーがあるOracle Database表からキャッシュ・グループを作成する方法を示します。Oracle Databaseに、複合キーを持つjob_history表を作成します。

SQL> CREATE TABLE job_history
(employee_id NUMBER(6) NOT NULL,
start_date DATE NOT NULL,
end_date DATE NOT NULL,
job_id VARCHAR2(10) NOT NULL,
department_id NUMBER(4),
PRIMARY KEY(employee_id, start_date));
Table created.

すべての列が複合主キーのTimesTenにキャッシュ・グループを作成します。

Command> CREATE WRITETHROUGH CACHE GROUP job_hist_cg
> FROM oratt.job_history
> (employee_id NUMBER(6) NOT NULL,
> start_date DATE NOT NULL,
> end_date DATE NOT NULL,
> job_id VARCHAR2(10) NOT NULL,
> department_id NUMBER(4),
> PRIMARY KEY(employee_id, start_date));

- NULLを指定できない列を持つOracle Database表。この表内の1つ以上のNULLを指定できない列に一意索引が指定されています。TimesTenキャッシュ表の主キーは、一意索引のすべての列に定義されている必要があります。たとえば、Oracle Database表の一意索引が複数の列c1、c2およびc3で構成されている場合、TimesTenキャッシュ表の列c1、c2およびc3には複合主キーが必要です。
次の例では、NULLを指定できない列を持つ表に定義するOracle Database一意索引を作成します。

SQL> CREATE TABLE regions(
region_id NUMBER NOT NULL,
region_name VARCHAR2(25));
Table created.
SQL> CREATE UNIQUE INDEX region_idx
ON regions(region_id);
Index created.

SQL> CREATE TABLE sales(
prod_id INT NOT NULL,
cust_id INT NOT NULL,
quantity_sold INT NOT NULL,
time_id DATE NOT NULL);
Table created.
SQL> CREATE UNIQUE INDEX sales_index ON sales(prod_id, cust_id);
Index created.

Oracle Database表と一意索引を作成した後に、次に示すように一意索引列を主キー定義として使用することにより、これらの表についてTimesTen上にキャッシュ・グループを作成できます。

Command> CREATE WRITETHROUGH CACHE GROUP region_cg
> FROM oratt.regions
> (region_id NUMBER NOT NULL PRIMARY KEY,
>  region_name VARCHAR2(25));

Command> CREATE WRITETHROUGH CACHE GROUP sales_cg
> FROM oratt.sales
> (prod_id INT NOT NULL, cust_id INT NOT NULL,
>  quantity_sold INT NOT NULL, time_id DATE NOT NULL,
>  PRIMARY KEY(prod_id, cust_id));

TimesTenデータベースには、複数のキャッシュ・グループを含めることができます。キャッシュ・グループには、1つ以上のキャッシュ表を含めることができます。Oracle Database表は、同じTimesTenデータベースにある複数のキャッシュ・グループにキャッシュすることはできません。

TimesTenのキャッシュ表に索引を作成すると、TimesTenの通常の表の場合と同様に、表に対して発行された特定の問合せを高速化できます。TimesTenキャッシュ表に対して非一意索引を作成できます。キャッシュ表には、キャッシュされたOracle Database表の一意索引と一致しない一意索引を作成しないでください。このような一意索引を作成すると、キャッシュされたOracle Database表では発生しない一意制約による障害がキャッシュ表で発生する可能性があり、その結果、自動リフレッシュ処理が実行されたときに、2つのデータベース内でこれらの表が互いに同期化されなくなります。

単一表のキャッシュ・グループ

最も単純なキャッシュ・グループは、単一のOracle Database表をキャッシュするキャッシュ・グループです。単一表のキャッシュ・グループには、ルート表はありますが子表はありません。

図4-1に、customer表をキャッシュする単一表キャッシュ・グループtarget_customersを示します。

図4-1 単一表のキャッシュ・グループ

複数表のキャッシュ・グループ

複数表のキャッシュ・グループは、1つのルート表および1つ以上の子表を定義するキャッシュ・グループです。キャッシュ・グループに含めることのできるルート表は、1つのみです。各子表は、外部キー制約を使用して、キャッシュ・グループ内のルート表または別の子表について、主キーまたは一意索引を参照する必要があります。複数表のキャッシュ・グループ内の表は、TimesTenデータベース内で外部キー制約によって相互に関連付けられている必要がありますが、Oracle Database内で相互に関連付けられている必要はありません。ルート表は、外部キー制約を使用してキャッシュ・グループ内の表を参照することはありません。

図4-2に、customer、ordersおよびorder_itemの各表をキャッシュする複数表のキャッシュ・グループcustomer_ordersを示します。customer_ordersキャッシュ・グループ内の各親表が持つ主キーは、外部キー制約を介して子表によって参照されます。customer表は外部キー制約を使用してキャッシュ・グループ内の表を参照していないため、この表がキャッシュ・グループのルート表です。ルート表の主キーは、キャッシュ・グループの主キーとみなされます。orders表は、customerルート表の子表です。order_item表は、orders子表の子表です。

図4-2 複数表のキャッシュ・グループ

複数表のキャッシュ・グループ内の表階層で、子表を他の子表の親に指定できます。子表は2つ以上の親表を参照できません。ただし、親表は2つ以上の子表から参照されることがあります。

図4-3に、不適切なキャッシュ表階層を示します。customer表およびproduct表は、どちらも外部キー制約を介してキャッシュ・グループ内の表を参照していません。これにより、キャッシュ・グループは2つのルート表を持つことになるため無効です。

図4-3 問題: 2つのルート表を含むキャッシュ・グループ

この問題を解決してすべての表をキャッシュするには、図4-4に示すように、customer、ordersおよびorder_itemの各表を含むキャッシュ・グループと、productおよびinventoryの各表を含む2つ目のキャッシュ・グループを作成します。

図4-4 解決策: 2つのキャッシュ・グループの作成

キャッシュ・グループの作成

キャッシュ・グループを作成するには、CREATE CACHE GROUP SQL文を使用するか、グラフィカル・ツールであるOracle SQL Developerを使用します。SQL Developerの詳細は、『Oracle SQL Developer TimesTen In-Memory Databaseサポート・ユーザーズ・ガイド』を参照してください。

キャッシュ・グループは、システム管理またはユーザー管理のいずれかとして識別されます。システム管理キャッシュ・グループでは特定の動作が実行されますが、ユーザー管理キャッシュ・グループの動作はカスタマイズできます。システム管理キャッシュ・グループには、次のタイプがあります。

- 読取り専用キャッシュ・グループ

- ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ

- SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ

ユーザー管理キャッシュ・グループの詳細は、「ユーザー管理キャッシュ・グループ」を参照してください。

キャッシュ・グループの作成には、次の内容も適用されます。

- AUTOREFRESHキャッシュ・グループ属性

- WHERE句の使用

- ON DELETE CASCADEキャッシュ表属性

- UNIQUE HASH ONキャッシュ表属性

キャッシュ・グループは、キャッシュ・マネージャ・ユーザーが作成して所有する必要があります。

Oracle Databaseデータを一時データベースにキャッシュすることはできません。

読取り専用キャッシュ・グループ

読取り専用キャッシュ・グループでは、図4-5に示すように、TimesTenキャッシュ表を直接更新できない場合、キャッシュ動作が実行されて、キャッシュされたOracle Database表でコミットされた更新をキャッシュ表に自動的にリフレッシュします。

図4-5 読取り専用キャッシュ・グループ

なんらかの理由でTimesTenデータベースを利用できない場合でも、読取り専用キャッシュ・グループにキャッシュされているOracle Database表は更新できます。TimesTenデータベースが処理を再開すると、TimesTenデータベースが利用できなかった間にキャッシュされたOracle Database表でコミットされた更新が、TimesTenキャッシュ表に自動的にリフレッシュされます。

注意:
TimesTenで読取り専用キャッシュ・グループの操作を管理する場合、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続します。ttCacheUidPwdSetの詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。

例4-1、例4-12、例4-13、例4-21および例4-22に定義された読取り専用キャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。

CREATE TABLE customer
(cust_num NUMBER(6) NOT NULL PRIMARY KEY,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100));

CREATE TABLE orders
(ord_num      NUMBER(10) NOT NULL PRIMARY KEY,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL);

キャッシュ・マネージャ・ユーザーがoratt.customer表およびoratt.orders表をキャッシュする読取り専用キャッシュ・グループを作成できるようにし、キャッシュされたOracle Database表からTimesTenキャッシュ表への自動リフレッシュ処理が実行されるようにするには、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のコンパニオンOracle Databaseユーザーに、これらの表に対するSELECT権限を付与する必要があります。

読取り専用キャッシュ・グループを作成するには、CREATE READONLY CACHE GROUP文を使用します。

例4-1 読取り専用キャッシュ・グループの作成

次の文では、oratt.customer表(ルート表)およびoratt.orders表(子表)をキャッシュする読取り専用キャッシュ・グループcustomer_ordersが作成されます。

CREATE READONLY CACHE GROUP customer_orders
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num)),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));

読取り専用キャッシュ・グループ内のキャッシュ表は直接更新できません。ただし、パススルー・レベルを2に設定すると、TimesTenキャッシュ表に対して発行されたコミット済の更新処理をパススルーし、キャッシュされたOracle Database表上で処理してから、更新を自動的にキャッシュ表にリフレッシュできます。「パススルー・レベルの設定」を参照してください。

読取り専用キャッシュ・グループ内のキャッシュ表に対する、パススルーされた文の影響は、更新処理が発行されたトランザクションでは発生しません。かわりに、この影響は、パススルーされた更新処理がOracle Databaseにコミットされ、キャッシュ・グループの次の自動リフレッシュが実行された後に発生します。パススルーされた更新処理をキャッシュされたOracle Database表で実行するには、読取り専用キャッシュ・グループにキャッシュされるOracle Database表において、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、INSERT、UPDATEおよびDELETE権限が付与されている必要があります。

「データのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」の説明に従って、自動リフレッシュ・キャッシュ・グループの定義済動作を実行するためにOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。

次に、ttIsqlユーティリティのcachesqlgetコマンドを実行して、読取り専用キャッシュ・グループにキャッシュされるOracle Database表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトを生成する必要があります。これらのオブジェクトの作成方法の詳細は、「自動リフレッシュ・キャッシュ・グループ用のOracle Databaseオブジェクトの手動による作成」を参照してください。

読取り専用キャッシュ・グループの使用の制限

読取り専用キャッシュ・グループを使用する場合は、次の制限が適用されます。

- TimesTenのキャッシュ表は直接更新できません。

- キャッシュ表定義では、ON DELETE CASCADEおよびUNIQUE HASH ONキャッシュ表属性のみを使用できます。
ON DELETE CASCADEキャッシュ表属性の詳細は、「ON DELETE CASCADEキャッシュ表属性」を参照してください。

UNIQUE HASH ONキャッシュ表属性の詳細は、「UNIQUE HASH ONキャッシュ表属性」を参照してください。

- キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- キャッシュされたOracle Database表に対して発行されたTRUNCATE TABLE文は、TimesTenキャッシュ表に自動的にリフレッシュされません。

- キャッシュ・グループが動的である場合を除いて、キャッシュ・グループにLOAD CACHE GROUP文を発行できるのはキャッシュ表が空の場合のみです。
LOAD CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

動的キャッシュ・グループの詳細は、「動的キャッシュ・グループ」を参照してください。

- キャッシュ・グループが動的でないかぎ、キャッシュ・グループに対してLOAD CACHE GROUP文を発行する前の自動リフレッシュ状態はPAUSEDである必要があります。キャッシュ・グループが動的である場合は、自動リフレッシュ状態はPAUSEDまたはONであることが必要です。キャッシュ・グループが動的な場合を除いて、LOAD CACHE GROUP文にWHERE句を含めることはできず、キャッシュ・グループが動的な場合は、WHERE句の後にCOMMIT EVERY n ROWS句を続ける必要があります。
自動リフレッシュ状態の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。

- REFRESH CACHE GROUP文をキャッシュ・グループに対して発行するには、自動リフレッシュ状態がPAUSEDになっている必要があります。REFRESH CACHE GROUP文にWHERE句を含めることはできません。
REFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

- キャッシュ・グループの作成、ロードまたはアンロード時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name

- 最低使用頻度(LRU)エージングがデフォルトで定義されている、キャッシュ・グループが動的である場合を除いて、キャッシュ・グループにLRUエージングを指定できません。
LRUエージングの詳細は、「LRUエージング」を参照してください。

- 読取り専用キャッシュ・グループでは、Oracle Databaseビューまたはマテリアライズド・ビューをキャッシュできません。

ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ

ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループでは、図4-6に示すように、TimesTenキャッシュ表でコミット済の更新が、キャッシュされたOracle Database表に非同期で自動的に伝播されるというキャッシュ動作が実行されます。

注意:
AWTキャッシュ・グループにキャッシュされているOracle Database表では、DML文を実行することは避けてください。実行すると、エラー状態になる場合があります。詳細は、「AWTキャッシュ・グループの使用の制限」を参照してください。

図4-6 ASYNCHRONOUS WRITETHROUGHキャッシュ・グループ

AWTキャッシュ・グループはTimesTenデータベースからOracle Databaseにデータを伝播するため、Oracle Databaseのキャッシュ表でユーザーが変更したデータは、Oracle DatabaseからTimesTenデータベースに自動的にはアップロードされません。この場合は、TimesTenにおいてAWTキャッシュ・グループを明示的にアンロードしてからリロードする必要があります。

TimesTenデータベースでのトランザクションのコミットは、Oracle Databaseでのコミットとは非同期に実行されます。これにより、アプリケーションはOracle Databaseトランザクションの完了を待機することなく、継続してTimesTenデータベースに対してトランザクションを発行できます。ただし、アプリケーションでは、Oracle Database上でトランザクションが完了するタイミングを確認できません。

AWTキャッシュ・グループに対するUNLOAD CACHE GROUP文の実行は、行に対する更新がOracle Databaseに伝播されるまで待機します。

AWTキャッシュ・グループ内のキャッシュ表は、Oracle Databaseが利用できない場合も更新できます。Oracle Databaseが処理を再開すると、Oracle Databaseが利用できなかった間にキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に伝播されます。

Oracle Databaseに伝播しないDML文からの更新が存在する場合は、ttCachePropagateFlagSet組込みプロシージャでフラグを0 (ゼロ)に設定することによって、Oracle Databaseに対する現在のトランザクション内でコミットされた更新の伝播を無効(DML文の実行によって)にできます。このフラグを0 (ゼロ)に設定した後、DML文の実行の影響はバックエンドのOracle Databaseに伝播されることはありません。そのため、これらの更新はTimesTenデータベース上にのみ存在します。後で、ttCachePropagateFlagSet組込みプロシージャでこのフラグを1に再設定することによって、伝播を再有効化できます。このフラグの設定を1に戻した後は、Oracle Databaseに対してすべてのコミットされた更新の伝播が再開されます。伝播フラグは、トランザクションのコミット後またはロールバック後に自動的に1に再設定されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCachePropagateFlagSetに関する説明を参照してください。

注意:
TimesTenでAWTキャッシュ・グループの操作を管理する場合、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続します。ttCacheUidPwdSetの詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。

例4-2、例4-14および例4-16に定義されたAWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。

CREATE TABLE customer
(cust_num NUMBER(6) NOT NULL PRIMARY KEY,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100));

キャッシュ・マネージャ・ユーザーが、oratt.customer表をキャッシュするAWTキャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。Oracle Databaseに対して非同期ライトスルー処理を行うには、oratt.customer表においてキャッシュ管理ユーザーに、INSERT、UPDATEおよびDELETEのOracle Database権限が付与されている必要があります。

AWTキャッシュ・グループを作成するには、CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用します。

例4-2 AWTキャッシュ・グループの作成

次の文では、oratt.customer表をキャッシュするASYNCHRONOUS WRITETHROUGHキャッシュ・グループnew_customersが作成されます。

CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num));

次の各項では、AWTキャッシュ・グループの構成、動作および管理について説明します。

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

- Oracle Database表へのパラレル伝播の構成

- AWTキャッシュ・グループによって保証されることおよび保証されないこと

- AWTキャッシュ・グループの使用の制限

- AWTキャッシュ・グループでのOracle Database永続エラーのレポート

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

非同期ライトスルー処理を実行するには、AWTキャッシュ・グループを含むTimesTenデータベース上でレプリケーション・エージェントが実行されている必要があります。CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文を実行すると、TimesTenキャッシュ表上でコミットされた更新を、キャッシュされたOracle Database表に非同期に伝播できるレプリケーション・スキームが作成されます。

AWTキャッシュ・グループを作成した後、TimesTenデータベース上でレプリケーション・エージェントを起動します。

例4-3 レプリケーション・エージェントの起動

キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、レプリケーション・エージェントをプログラムから手動で起動できます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttRepStart;

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -repStartユーティリティ・コマンドを実行することによって、コマンドラインから起動することもできます。

% ttAdmin -repStart cachealone1

TimesTenデータベースに1つ以上のAWTキャッシュ・グループまたはレプリケーション・スキームがない場合、レプリケーション・エージェントは起動しません。

レプリケーション・エージェントが実行されている場合は、AWTキャッシュ・グループに対して別のCREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP文またはDROP CACHE GROUP文を発行する前にエージェントを停止する必要があります。

例4-4 レプリケーション・エージェントの停止

キャッシュ・マネージャ・ユーザーとしてttRepStop組込みプロシージャをコールすることによって、レプリケーション・エージェントをプログラムから手動で停止できます。

Command> call ttRepStop;

また、CACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -repStopユーティリティ・コマンドを実行することによって、コマンドラインから停止することもできます。

% ttAdmin -repStop cachealone1

レプリケーション・エージェント起動ポリシーを設定して、TimesTenデータベースでレプリケーション・エージェント・プロセスを起動する方法およびタイミングを決定できます。

デフォルトの起動ポリシーはmanualであり、これはttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行することによって、手動でレプリケーション・エージェントを起動する必要があることを意味します。実行しているレプリケーション・エージェント・プロセスを手動で停止するには、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行します。

TimesTenメイン・デーモン・プロセスの起動時にレプリケーション・エージェントを自動的に起動できるように、起動ポリシーをalwaysに設定することもできます。always起動ポリシーを使用しているときは、メイン・デーモンを実行している間、レプリケーション・エージェントを停止できませんが、起動ポリシーをmanualまたはnorestartに変更した後、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行して手動停止を発行すると、レプリケーション・エージェントを停止できます。

manualおよびalways起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後、レプリケーション・エージェントは自動的に再起動されます。

起動ポリシーをnorestartに設定することもできます。この場合、レプリケーション・エージェントを手動で起動するには、ttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行する必要があります。また、手動で停止するには、ttRepStop組込みプロシージャをコールするか、ttAdmin -repStopユーティリティ・コマンドを実行する必要があります。

norestart起動ポリシーを使用しているときは、データベースの無効化などの障害が発生した後でも、レプリケーション・エージェントは自動的に再起動されません。ttRepStart組込みプロシージャをコールするか、ttAdmin -repStartユーティリティ・コマンドを実行して、レプリケーション・エージェントを手動で再起動する必要があります。

例4-5 レプリケーション・エージェント起動ポリシーの設定

インスタンス管理者として、キャッシュ・マネージャ・ユーザーにADMIN権限を付与します。

% ttIsql cachealone1
Command> GRANT ADMIN TO cacheuser;
Command> exit

レプリケーション・エージェント起動ポリシーは、キャッシュ・マネージャ・ユーザーとしてttRepPolicySet組込みプロシージャをコールすることによって、プログラムで設定できます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttRepPolicySet('manual');
Command> exit

また、ADMIN権限を持つTimesTen外部ユーザーとしてttAdmin -repPolicyユーティリティ・コマンドを実行することによって、コマンドラインから設定することもできます。

% ttAdmin -repPolicy always cachealone1

AWTキャッシュ・グループでは、レプリケーション・エージェントを使用してOracle Databaseにトランザクションを非同期に伝播するため、これらのトランザクションがOracle Databaseで完全に処理されたことをレプリケーション・エージェントが確認するまで、トランザクションはトランザクション・ログ・バッファおよびトランザクション・ログ・ファイルに保持されます。ttLogholds組込みプロシージャを使用して、これらのトランザクションの伝播を監視できます。ttLogHolds組込みプロシージャをコールすると、AWTキャッシュ・グループの伝播用に保持されているトランザクション・ログを区別するために、説明フィールドには_ORACLEと記されます。

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開発者および管理者ガイド』のレプリケートされたログの保持の表示に関する説明を参照してください。

Oracle Database表へのパラレル伝播の構成

AWTキャッシュ・グループのスループットを向上させるために、パラレル動作でトランザクションの変更をOracle Databaseに伝播および適用する複数のスレッドを構成できます。パラレル伝播では、トランザクションの依存性に従って、AWTキャッシュ表の変更をコミット順にOracle Database表に適用します。

パラレル伝播は、AWTキャッシュ・グループにおいて次の構成でサポートされます。

- キャッシュ・グリッド内のAWTキャッシュ・グループ

- アクティブ・スタンバイ・ペア・レプリケーション・スキームに関連するAWTキャッシュ・グループ

- 単一のTimesTenデータベース内のAWTキャッシュ・グループ(レプリケーション・スキーム構成なし)

- いずれかのエージング・ポリシーで構成されたAWTキャッシュ・グループ

次のデータ・ストア属性を使用すると、パラレル伝播を有効化し、パラレル動作で変更をAWTキャッシュ表から対応するOracle Database表に伝播するスレッドの数を制御できます。

- ReplicationApplyOrderingを使用すると、デフォルトでパラレル伝播が有効になります。

- ReplicationParallelismは、レプリケーション・スキームでパラレル・レプリケーションを行う場合のソース・データベースでの送信側スレッド数およびターゲット・データベースでの受信側スレッド数を定義します。パラレル・レプリケーションのためだけに使用される場合、この値は2から32の間で指定できます。デフォルトは1です。また、ReplicationParellelismの値は、LogBufParallelismの値の半分を超えてはなりません。

- CacheAWTParallelism(設定時)では、AWTキャッシュ表からOracle Database表への変更のパラレル伝播で使用されるスレッド数を決定します。この属性は2から31の間で設定します。デフォルトは1です。

AWTキャッシュ・グループのパラレル伝播は、次のシナリオのうちいずれかを使用して構成されます。

- ReplicationApplyOrderingを0に、ReplicationParallelismを1より大きな値に設定します。
CacheAWTParallelismを設定しない場合、Oracle Databaseに変更を適用するスレッドの数は、ReplicationParallelismの設定の2倍になります。たとえば、ReplicationParallelism=3の場合、Oracle Database表に変更を適用するスレッドの数は6です。この場合、ReplicationParallelismは2から16の間でのみ設定可能で、それ以外の値を使用すると、2倍になった値がパラレル伝播の最大スレッド数である31を超えてしまいます。この値を16に設定すると、最大スレッド数のデフォルト値は31になります。

- ReplicationApplyOrderingを0に、ReplicationParallelismを1以上の値に、CacheAWTParallelismを1より大きな値に設定します。CacheAWTParallelismには、ReplicationParallelismで設定された値以上の値で、かつ31以下の値を指定する必要があります。
CacheAWTParallelismを指定しない場合、Oracle Databaseへのパラレル伝播に使用するスレッド数はReplicationParallelismを使用して決定されます。ただし、この値はパラレル伝播のスレッドに使用すると2倍になるため、ReplicationParallelismに設定できるのは2から16の間の数のみです。この値を16に設定すると、最大スレッド数のデフォルト値は31になります。

ReplicationParallelism属性とCacheAWTParallelism属性を両方とも設定すると、CacheAWTParallelismに設定した値がパラレル伝播に使用されるスレッドの数になります。CacheAWTParallelismの設定によって、パラレル伝播に適用されるスレッドの数が決まり、またReplicationParallelismの設定によって、パラレル・レプリケーションのスレッド数が決まります。これからわかるように、ReplicationParallelismを4に、CacheAWTParallelismを6に設定すると、Oracle Database表に変更を適用するスレッドの数は6になります。これにより、Oracle Database表へのパラレル・レプリケーションとパラレル伝播に使用するスレッド数を異ならせることができます。

注意:
パラレル・レプリケーションの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のパラレル・レプリケーションの構成に関する説明を参照してください。
これらのデータ・ストア属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のReplicationApplyOrderingに関する説明、ReplicationParallelismに関する説明およびCacheAWTParallelismに関する説明を参照してください。

これらのデータ・ストア属性は、相互に関連性があります。表4-1に、使用可能な各種属性値の組合せ結果を示します。

表4-1 パラレル伝播のデータ・ストア属性関係の結果

ReplicationApply Ordering

ReplicationParallelism

CacheAWTParallelism

パラレル伝播のスレッド数

0に設定(パラレル伝播を有効化)

複数のトラックを使用するために1より大きい16以下の値を設定します。

指定しません。

ReplicationParallelismの2倍の値を設定します。

0に設定(パラレル伝播を有効化)

複数のトラックを使用するために16より大きい32以下の値を設定します。

指定しません。

エラーがスローされます。CacheAWTParallelismが設定されていない場合、ReplicationParallelismで設定されている値の2倍の値をスレッド数として指定します。したがって、この場合、ReplicationParallelismには16より大きな値を指定できません。

0に設定(パラレル伝播を有効化)

複数のトラックを使用するために1より大きい32以下の値を設定します。

ReplicationParallelismの値以上の値を設定します。

CacheAWTParallelismで指定された数を設定します。

0に設定(パラレル伝播を有効化)

複数のトラックを使用するために1より大きい32以下の値を設定します。

ReplicationParallelismの値より小さい値を設定します。

データベース作成時にエラーがスローされます。CacheAWTParallelismには、ReplicationParallelismの値以上の値を設定する必要があります。

0に設定(パラレル伝播を有効化)

1を設定するかまたは指定しません。シングル・トラック。

1より大きな値を設定します。

CacheAWTParallelismで指定された数を設定します。

1に設定(パラレル伝播を無効化)。

N/A

1より大きな値を設定します。

パラレル化が無効になっているのに、パラレル伝播が有効化されることを見込んでCacheAWTParallelismに値が設定されているため、データベースの作成時にエラーがスローされます。

キャッシュされるOracle Database表の外部キーには、その外部キーに対する索引を作成する必要があります。次のOracle Database表について考えてみます。

CREATE TABLE parent (c1 NUMBER PRIMARY KEY NOT NULL);
CREATE TABLE child (c1 NUMBER PRIMARY KEY NOT NULL,
c2 NUMBER REFERENCES parent(c1));
CREATE TABLE grchild (c1 NUMBER PRIMARY KEY NOT NULL,
c2 NUMBER REFERENCES parent(c1),
c3 NUMBER REFERENCES parent(c1));

次の索引を作成する必要があります。

CREATE INDEX idx_1 ON child(c2);
CREATE INDEX idx_2 ON grchild(c2);
CREATE INDEX idx_3 ON grchild(c3);

AWTキャッシュ・グループでパラレル伝播を使用する場合の表に関する制約事項

AWTキャッシュ・グループでパラレル伝播を使用する場合は、データの整合性を手動で維持する必要があります。キャッシュされるOracle Database表の列に対する任意の一意索引、一意制約または外部キー制約は、TimesTen内のAWTキャッシュ表でも作成する必要があります。AWTキャッシュ表でこれらの制約を作成できずにパラレル伝播用に構成すると、TimesTenは制約が欠落している表に対してDML処理によりすべてのトランザクションをシリアライズします。たとえば、Oracle Databaseの表に対して作成された一意索引がTimesTenの対応するキャッシュ表に対して作成できない場合、この表に関するすべてのトランザクションがシリアライズされます。

TimesTenは、次のSQL文のいずれかが発行された場合に、TimesTenでキャッシュされていないOracle Databaseにおいて制約の欠落を自動的にチェックします。

- AWTキャッシュ・グループをCREATE ASYNCHRONOUS CACHE GROUP文で作成する場合

- AWTキャッシュ表に対してCREATE UNIQUE INDEX文で一意索引を作成する場合

- AWTキャッシュ表に対してDROP INDEX文で一意索引を削除する場合

注意:
ttCacheCheck組込みプロシージャにより、制約の欠落のチェックを手動で開始できます。たとえば、TimesTenは、キャッシュされたOracle Database表でスキーマが変更された後は、制約の欠落を自動的にはチェックしません。Oracle Databaseでスキーマが変更された後には、TimesTenデータベースでttCacheCheckを実行することにより、制約の欠落のチェックを手動で実行する必要があります。
制約の欠落を手動でチェックする必要があるその他の条件については、「制約の欠落チェックの手動開始」を参照してください。

チェックによりキャッシュ表で制約が欠落していることが判明した場合、TimesTenは欠落している各制約に関する警告を発行します。

次のシナリオでは、DML処理を含むトランザクションがOracle Databaseに伝播された際にシリアライズされるように、キャッシュ表がマークされます。

- 一意索引または一意制約が欠落しているAWTキャッシュ表にDML処理を適用するトランザクション。

- 単一のAWTキャッシュ・グループ内の表に対して外部キー制約が欠落している。

- 外部キー関係の参照元表と参照先表の両方が同じAWTキャッシュ・グループ内にあり、外部キー関係が定義されていない場合は、両方の表に対してトランザクションのシリアライズを行うようにマークされます。

- 参照元表はAWTキャッシュ・グループ内にあるが、参照先表はAWTキャッシュ・グループ内にない場合、キャッシュ・グループ内の表に対してはトランザクションのシリアライズを行うようマークはされません。ユーザーに対して、制約が欠落していることを通知する警告が発行されるだけです。

- 参照先表はAWTキャッシュ・グループ内にあるが、参照元表はAWTキャッシュ・グループ内にない場合、キャッシュ・グループ内の表に対してはトランザクションのシリアライズを行うようマークはされません。ユーザーに対して、制約が欠落していることを通知する警告が発行されるだけです。

- キャッシュ・グループ間で外部キー制約が欠落している。外部キー制約が欠落している個別のAWTキャッシュ・グループで表を定義した場合、両方の表に対してトランザクションのシリアライズを行うようにマークされます。

- 外部キー制約が欠落していることにより、2つのAWTキャッシュ・グループ間の外部キー制約のチェーンが破損した場合は、両方のAWTキャッシュ・グループ内のすべての表に対するトランザクションがシリアライズされます。

注意:
Oracle Databaseトリガーにより、TimesTenが認識できない処理上の依存性が発生する場合があります。この場合、AWTキャッシュ・グループでのパラレル伝播を使用不可にするか、またはトリガーが作成されたAWTキャッシュ・グループで表をキャッシュしないようにする必要があります。

例4-6 AWTキャッシュ・グループの作成時に制約が欠落している例

次の例では、Oracle Databaseのorattスキーマに2つの表を作成します。active_customer表とordertab表の間には外部キー関係が存在します。この例ではパラレル伝播でこれらの表を使用するため、ordertab表の外部キーに対して索引が作成されます。

SQL> CREATE TABLE active_customer
(custid NUMBER(6) NOT NULL PRIMARY KEY,
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12),
region VARCHAR2(12) DEFAULT 'Unknown');
Table created.

SQL> CREATE TABLE ordertab
(orderid NUMBER(10) NOT NULL PRIMARY KEY,
custid NUMBER(6) NOT NULL);
Table created.

SQL> ALTER TABLE ordertab
ADD CONSTRAINT cust_fk
FOREIGN KEY (custid) REFERENCES active_customer(custid);
Table altered.

SQL> CREATE INDEX order_idx on ordertab (custid);

TimesTenは、CREATE CACHE GROUPが発行されるたびに、制約の欠落を自動的にチェックします。次の例では、active_customer表を含む単一のキャッシュ・グループを作成します。active_customerは参照先表であり、参照元表ordertabはAWTキャッシュ・グループ内にないため、警告が発行されるだけです。active_customer表に対しては、トランザクションのシリアライズを行うようマークはされません。

CREATE WRITETHROUGH CACHE GROUP update_cust
FROM oratt.active_customer
(custid NUMBER(6) NOT NULL PRIMARY KEY,
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12));
Warning  5297: The following Oracle foreign key constraints on AWT cache table
ORATT.ACTIVE_CUSTOMER contain cached columns that do not have corresponding
foreign key constraints on TimesTen: ORATT.CUST_FK [Outside of CG].

次の例ではTimeTenで2つのAWTキャッシュ・グループを作成しますが、1つにはactive_customer表が含まれており、もう1つにはordertab表が含まれています。キャッシュ・グループ間では外部キー制約が欠落しています。この場合、両方の表に対して警告が発行されますが、ordertab表が参照元表で外部キーを含んでいる必要があるため、この表に対してのみトランザクションのシリアライズを行うようにマークされます。

CREATE WRITETHROUGH CACHE GROUP update_cust
FROM oratt.active_customer
(custid NUMBER(6) NOT NULL PRIMARY KEY,
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12);
Warning  5297: The following Oracle foreign key constraints on AWT cache table
oratt.update_customer contain cached columns that do not have corresponding
foreign key constraints on TimesTen: ordertab.cust_fk [Outside of CG].

CREATE WRITETHROUGH CACHE GROUP update_orders
FROM oratt.ordertab
(orderid NUMBER(10) NOT NULL PRIMARY KEY,
custid NUMBER(6) NOT NULL);
Warning  5295: Propagation will be serialized on AWT cache table
ORATT.ORDERTAB because the following Oracle foreign key constraints on this
table contain cached columns that do not have corresponding foreign key
constraints on TimesTen: ORDERTAB.CUST_FK [Across AWT cache groups].

制約の欠落チェックの手動開始

ttCacheCheck組込みプロシージャは、TimesTenが自動的に実行するのと同じ制約の欠落チェックを、Oracle Databaseのキャッシュ表に対して実行します。ttCacheCheckは、伝播のシリアライズを行うようにマークされた表と制約の欠落に関して該当するメッセージを提供します。ttCacheCheck組込みプロシージャを使用すると、TimesTen内の指定されたキャッシュ・グループまたはすべてのキャッシュ・グループに対して制約の欠落のチェックを行い、すべてのキャッシュ・グループにおいて制約が欠落していない状態にできます。

注意:
ttCacheCheckはシステム表を更新して、1つの表に対して実行されたDMLをシリアライズする必要があるかないかを示すため、ttCacheCheck組込み処理の完了後にコミットまたはロールバックを行う必要があります。
ttCacheCheck組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheCheckに関する説明を参照してください。

次のシナリオのいずれかの後に、ttCacheCheck組込みプロシージャを手動でコールし、既知の依存性を更新する必要があります。

- DROP CACHE GROUP文によりTimesTenで一連のAWTキャッシュ・グループを削除した後。

- AWTキャッシュ・グループにキャッシュされているOracle Databaseにおいて一意索引、一意制約または外部キーを追加または削除した後。制約の追加後にttCacheCheck組込みプロシージャをコールしない場合、AWTキャッシュ・グループでランタイム・エラーが発生する可能性があります。制約を削除すると、TimesTenは必要がない場合でもトランザクションをシリアライズすることがあります。ttCacheCheck組込みプロシージャをコールすると、シリアライズが必要かどうかが確認されます。

- この組込みプロシージャを使用すると、いくつかのトランザクションがシリアライズされている理由を判別できます。

注意:
ttCacheCheck組込みプロシージャは、レプリケーション・エージェントの実行中にはコールできません。
ttCacheCheckのコール時にAWTキャッシュ・グループでDDL文を実行すると、ttCacheCheckは、文が完了するか、タイムアウト時間に達するまで待機します。

複数のキャッシュ・グループでCacheAwtParallelismデータ・ストア属性を定義していないか、または指定したキャッシュ・グループがAWTキャッシュ・グループではない場合、ttCacheCheck組込みプロシージャは空の結果セットを返します。

例4-7 ttCacheCheckの手動実行による欠落している依存性の更新

次に、ユーザーがttCacheCheck組込みプロシージャを手動で実行し、cacheuserが所有しているAWTキャッシュ・グループupdate_ordersで制約が欠落しているかどうかを判別する例を示します。エラー・メッセージを含む結果セットが返されています。update_ordersキャッシュ・グループのordertab表に対して、トランザクションをシリアルに伝播するようにマークされています。

Command> call ttCacheCheck(NULL, 'cacheuser', 'update_orders');

< CACHEUSER, UPDATE_ORDERS, CACHEUSER, ORDERTAB, Foreign Key, CACHEUSER,
CUST_FK, 1, Transactions updating this table will be serialized to Oracle
because: The missing foreign key connects two AWT cache groups.,
table CACHEUSER.ORDERTAB constraint CACHEUSER.CUST_FK foreign key(CUSTID)
references CACHEUSER.ACTIVE_CUSTOMER(CUSTID) >
1 row found.

TimesTenデータベースまたはOracle Databaseでキャッシュ・グループ・スキーマが変更されるたびに、すべてのAWTキャッシュ・グループに対してttCacheCheckをコールすることにより、すべての制約を確認できます。次に、ユーザーがttCacheCheck組込みプロシージャを手動で実行し、すべての入力パラメータに対してNULL値を指定することにより、全TimesTenデータベース内のAWTキャッシュ・グループで制約が欠落しているかどうかを判別する例を示します。エラー・メッセージを含む結果セットが返されています。

Command> call ttCacheCheck(NULL, NULL, NULL);

< CACHEUSER, UPDATE_ORDERS, CACHEUSER, ORDERTAB, Foreign Key, CACHEUSER,
CUST_FK, 1, Transactions updating this table will be serialized to Oracle
because: The missing foreign key connects two AWT cache groups.,
table CACHEUSER.ORDERTAB constraint CACHEUSER.CUST_FK foreign key(CUSTID)
references CACHEUSER.ACTIVE_CUSTOMER(CUSTID) >
1 row found.

AWTキャッシュ・グループのパラレル伝播におけるバッチ・サイズの構成

AWTキャッシュ・グループを使用する際に、TimesTenはバックエンドOracle Databaseに対してパラレルに適用される1つ以上のトランザクションをバッチ処理します。CacheParAwtBatchSizeパラメータにより、1度のバッチ処理に含まれる行数に対してしきい値を設定します。行数が最大値に到達すると、TimesTenはトランザクションに残りの行を含めますが(TimesTenはトランザクションを分割はしません)、バッチ処理にこれ以上のトランザクションは追加しません。

たとえば、ユーザーがCacheParAwtBatchSizeを200に設定したとします。次のAWT伝播では、それぞれ120行を持つ3つのトランザクションが存在し、それらを伝播してOracle Databaseに適用する必要があります。TimesTenは、1回目のバッチ処理に最初の2つのトランザクション(合計240行)を組み込みます。3つ目のトランザクションは2回目のバッチ処理に組み込まれます。

CacheParAwtBatchSizeパラメータのデフォルト値は125行です。最小値は1です。ttDBConfig組込みプロシージャのCacheParAwtBatchSizeパラメータの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。

CacheParAwtBatchSizeの現在の値を取得するには、次のようにします。

call ttDBConfig('CacheParAwtBatchSize');
< CACHEPARAWTBATCHSIZE, 125 >
1 row found.

CacheParAwtBatchSizeパラメータを200に設定するには、次のようにします。

call ttDBConfig('CacheParAwtBatchSize','200');
< CACHEPARAWTBATCHSIZE, 200 >
1 row found

Oracleサポートがワークロードとそのワークロード内のすべての依存性を分析し、CacheParAwtBatchSizeを別の値にした方がパフォーマンスが向上する可能性があるかどうかを判別しますので、指示があった場合にのみCacheParAwtBatchSizeパラメータを設定してください。複数のトランザクションが同じデータを同時に変更している場合は、依存性が存在します。ワークロード内にあまりにも多数の依存性が存在する場合には、Oracleサポートからこの値を小さくするように提案させていただく場合があります。

AWTキャッシュ・グループによって保証されることおよび保証されないこと

AWTキャッシュ・グループでは、次のことが保証されます。

- TimesTenデータベースとOracle Databaseの間の通信障害が原因でトランザクションが失われないこと。

- レプリケーション・エージェントが実行されていない場合またはOracle Databaseへの接続を失った場合は、エージェントの再起動後またはOracle Databaseに再接続後に、TimesTenキャッシュ表に対してコミットされた更新を、キャッシュされたOracle Database表に自動伝播する処理が再開されること。

- トランザクションが、TimesTenデータベースでコミットされた順序と同じ順序で、Oracle Databaseでもコミットされること。

AWTキャッシュ・グループでは、次のことが保証されません。

- TimesTenデータベースでコミットが成功したすべてのトランザクションが、Oracle Databaseに正しく伝播され、コミットされること。Oracle Databaseで実行エラーが発生すると、Oracle Databaseのトランザクションがロールバックされます。たとえば、一意制約違反のためにOracle Databaseでの更新が失敗する可能性があります。実行エラーが発生したトランザクションは再試行されません。
実行エラーは永続エラーであるとみなされ、TimesTenデータベースのチェックポイント・ファイルと同じディレクトリに存在するTimesTenDatabaseFileName.awterrsファイルにレポートされます。詳細は、「AWTキャッシュ・グループでのOracle Database永続エラーのレポート」を参照してください。

- Oracle Database更新の絶対順序が保存されること(TimesTenは更新競合を解決しないため)。次に例を示します。

- 2つの異なるTimesTenデータベース(DB1およびDB2)で、異なるAWTキャッシュ・グループが同じOracle Database表をキャッシュしています。DB1内のキャッシュ表で、更新がコミットされます。次に、DB2内のキャッシュ表で、更新がコミットされます。2つのキャッシュ表は異なるTimesTenデータベースに存在し、同じOracle Database表をキャッシュしています。ライトスルー処理は非同期であるため、DB2の更新がOracle Databaseに伝播されてから、DB1の更新が伝播される場合があり、この結果、DB1の更新によって、DB2の更新が上書きされます。
動的AWTグローバル・キャッシュ・グループを使用すると、このような書込みの非一貫性が解決されます。グローバル・キャッシュ・グループの詳細は、「グローバル・キャッシュ・グループ」を参照してください。

- AWTキャッシュ・グループ内のキャッシュ表で更新がコミットされます。この同じ更新が、パススルー処理を使用して、キャッシュされたOracle Database表でコミットされます。キャッシュ表の更新は、Oracle Databaseに自動的に非同期で伝播されますが、伝播された更新とパススルーされた更新をOracle Databaseで処理するタイミングによっては、キャッシュされたOracle Database表で直接処理される、パススルーされた更新を上書きする場合があります。この状態と他に発生する可能性がある状態に備えて、TimesTenでは、AWTキャッシュ・グループにキャッシュされているOracle Database表に対して、直接DML文を実行しないことをお薦めします。詳細は、「AWTキャッシュ・グループの使用の制限」を参照してください。

AWTキャッシュ・グループの使用の制限

AWTキャッシュ・グループを使用する場合は、次の制限が適用されます。

- キャッシュ表定義では、ON DELETE CASCADEおよびUNIQUE HASH ONキャッシュ表属性のみを使用できます。
ON DELETE CASCADEキャッシュ表属性の詳細は、「ON DELETE CASCADEキャッシュ表属性」を参照してください。

UNIQUE HASH ONキャッシュ表属性の詳細は、「UNIQUE HASH ONキャッシュ表属性」を参照してください。

- キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- キャッシュ表定義にWHERE句を含めることはできません。
キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。

- キャッシュ表に対してTRUNCATE TABLE文を発行できません。

- AWTキャッシュ・グループでは、Oracle Databaseビューまたはマテリアライズド・ビューをキャッシュできません。

- AWTキャッシュ・グループを作成または削除する前にレプリケーション・エージェントを停止する必要があります。
レプリケーション・エージェントの停止方法および起動方法の詳細は、「レプリケーション・エージェントの管理」を参照してください。

- レプリケーション・エージェントが実行されていない場合、TimesTenキャッシュ表でコミットされた更新は、キャッシュされたOracle Database表に伝播されません。

- AWTキャッシュ・グループを作成するには、TimesTenデータベースの絶対パス名の長さを248文字以内にする必要があります。

- AWTキャッシュ・グループにキャッシュされているOracle Database表では、DML文を実行することは避けてください。これにより、エラー状態になる場合があります。キャッシュされたOracle Database表で挿入、更新または削除処理のいずれかを行うと、処理対象の行に対してTimesTenで実行される処理に不適切な影響を与える場合があります。TimesTenでは、Oracle Databaseで発生する更新競合は検出または解決されません。キャッシュされたOracle Database表で直接コミットされた更新は、キャッシュ表の更新がOracle Databaseに伝播されたときに、TimesTenキャッシュ表でコミットされた更新によって上書きされる場合があります。さらに、キャッシュされたOracle Database表で行を削除すると、TimesTenがすでに存在しない行に対して更新を試みたときに、更新が適用されなくなる場合があります。
Oracle DatabaseですべてのデータがDML文から制限を受けることがないようにするために、Oracle Databaseでデータを分割して、AWTキャッシュ・グループに含まれているデータとAWTキャッシュ・グループから除外されるデータとを分けることができます。

- TimesTenでは、単一のSQL文によって一意索引の制約違反が発生するかどうかを判別するときに、遅延チェックを実行します。
たとえば、キャッシュされたOracle Database表のNUMBER列に一意索引があり、TimesTenキャッシュ表の同じNUMBER列にも一意索引があるとします。キャッシュされたOracle Database表には5つの行があり、キャッシュ表にも同じ5つの行があります。NUMBER列の値の範囲は1から5です。

キャッシュ表に対してUPDATE文を発行し、すべての行のNUMBER列の値を1増分します。この処理は、キャッシュ表では成功しますが、キャッシュされたOracle Database表に伝播されると失敗します。

これは、TimesTenでは、一意索引の制約のチェックが、すべての行が更新された後、文の実行の最後に行われるために発生します。ただし、Oracle Databaseでは、1行更新されるたびに制約のチェックが実行されます。

したがって、NUMBER列の値が1であるキャッシュ表の行が2に変更され、この更新がOracle Databaseに伝播されると、キャッシュされたOracle Database表のNUMBER列の値が2となった行で一意制約違反が発生します。

AWTキャッシュ・グループでのOracle Database永続エラーのレポート

トランザクションが正常に伝播されず、Oracle Databaseにコミットされない場合は、こうした永続エラーによりOracle Databaseのトランザクションがロール・バックされます。たとえば、一意制約違反のためにOracle Databaseでの更新が失敗する可能性があります。永続エラーが発生したトランザクションは再試行されません。

永続エラーは常に、TimesTenデータベースのチェックポイント・ファイルと同じディレクトリに存在するTimesTenDatabaseFileName.awterrsテキスト・ファイルにレポートされます。このファイルの内容の詳細は、『Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド』のTimesTen for AWTによって報告されるOracle Databaseエラーに関する説明を参照してください。

ttCacheConfig組込みプロシージャにより、ASCIIおよびXMLの両方の書式でこれらのエラーをレポートするようにTimesTenを構成できます。

注意:
エラー・ファイルの書式の設定にはttCacheConfigのtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

- TimesTenDatabaseFileName.awterrsテキスト・ファイルのみに永続エラーをレポートするようにTimesTenを構成するには、ASCIIパラメータを指定してttCacheConfig組込みプロシージャをコールします。これがデフォルトです。

Command> call ttCacheConfig('AwtErrorXmlOutput',,,'ASCII');

- TimesTenDatabaseFileName.awterrsテキスト・ファイルとTimesTenDatabaseFileName.awterrs.xmlという名前のXMLファイルの両方に永続エラーをレポートするようにTimesTenを構成するには、XMLパラメータを指定してttCacheConfig組込みプロシージャをコールします。

Command> call ttCacheConfig('AwtErrorXmlOutput',,,'XML');

注意:
永続エラーをXMLファイルにレポートするためにttCacheConfigをコールする前に、まずレプリケーション・エージェントを停止する必要があります。次に、組込みプロシージャの完了後に、レプリケーション・エージェントを再起動します。
この組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する説明を参照してください。

エラーをXML書式でレポートするように構成すると、Oracle Database永続エラーが発生したときに、次の2つのファイルが生成されます。

- TimesTenDatabaseFileName.awterrs.xml。このファイルには、Oracle Database永続エラー・メッセージがXML書式で記載されています。

- TimesTenDatabaseFileName.awterrs.dtd。このファイルにはXML Document Type Definition (DTD)が記載されており、これはTimesTenDatabaseFileName.awterrs.xmlファイルの解析に使用します。
XML DTDは、エラーのログを含む有効なXMLファイルの要素および構造を記述した一連のマークアップ宣言であり、XML 1.0仕様に基づいています。XMLファイルはUTF-8を使用してエンコードされます。次に、XML書式で記述された要素を示します。

注意:
XML Document Type Definition(DTD)を判読および理解する方法の詳細は、http://www.w3.org/TR/REC-xmlを参照してください。

<!ELEMENT ttawterrorreport (awterrentry*) >
<!ELEMENT awterrentry(header, (failedop)?, failedtxn) >
<!ELEMENT header (time, datastore, oracleid, transmittingagent, errorstr,
(ctn)?, (batchid)?, (depbatchid)?) >
<!ELEMENT failedop (sql) >
<!ELEMENT failedtxn ((sql)+) >
<!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 oracleid (#PCDATA) >
<!ELEMENT transmittingagent (transmitingname, pid, threadid) >
<!ELEMENT pid (#PCDATA) >
<!ELEMENT threadid (#PCDATA) >
<!ELEMENT transmittingname (#PCDATA) >
<!ELEMENT errorstr (#PCDATA) >
<!ELEMENT ctn (timestamp, seqnum) >
<!ELEMENT timestamp(#PCDATA) >
<!ELEMENT seqnum(#PCDATA) >
<!ELEMENT batchid(#PCDATA) >
<!ELEMENT depbatchid(#PCDATA) >
<!ELEMENT sql(#PCDATA) >

SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ

同期ライトスルー(SWT)キャッシュ・グループでは、図4-7に示すように、TimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に同期して伝播されるというキャッシュ動作が実行されます。

注意:
SWTキャッシュ・グループにキャッシュされているOracle Database表では、DML文を実行することは避けてください。実行すると、エラー状態になる場合があります。詳細は、「SWTキャッシュ・グループの使用の制限」を参照してください。

図4-7 SYNCHRONOUS WRITETHROUGHキャッシュ・グループ

TimesTenデータベースでのトランザクションのコミットは、Oracle Databaseでのコミットと同期して実行されます。アプリケーションによってTimesTenデータベースでトランザクションがコミットされると、このトランザクションは、TimesTenで処理される前にOracle Databaseで処理されます。Oracle DatabaseとTimesTenデータベースの両方でトランザクションが完了するまで、アプリケーションはブロックされます。

トランザクションがOracle Databaseでのコミットに失敗した場合、アプリケーションはTimesTenでトランザクションをロールバックする必要があります。Oracle Databaseトランザクションのコミットが成功し、TimesTenトランザクションのコミットが失敗した場合、SWTキャッシュ・グループ内のキャッシュ表は、キャッシュされたOracle Database表と同期化されなくなります。

注意:
伝播された更新をコミットする際に、TimesTenデータベースとOracle Databaseの両方でコミットが発生する仕組みにおける動作およびエラー状態は、「PROPAGATEキャッシュ表属性」で説明されているPROPAGATEキャッシュ属性を持つユーザー管理キャッシュ・グループに対するのと同じコミット・プロセスです。

キャッシュされたOracle Database表とキャッシュ表を手動で再同期化するには、ttCachePropagateFlagSet組込みプロシージャをコールして更新の伝播を無効にしてから、TimesTenでトランザクションのコミットが失敗した原因となった問題を修正した後、TimesTenデータベースでトランザクションを再発行します。次に、ttCachePropagateFlagSet組込みプロシージャをコールして、更新の伝播を再度有効化します。また、付随するキャッシュ・グループをリロードすることによって、キャッシュされたOracle Database表とキャッシュ表を再同期化することもできます。

例4-8に定義されたSWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。

CREATE TABLE product
(prod_num    VARCHAR2(6) NOT NULL PRIMARY KEY,
name        VARCHAR2(30),
price       NUMBER(8,2),
ship_weight NUMBER(4,1));

キャッシュ・マネージャ・ユーザーが、oratt.product表をキャッシュするSWTキャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。TimesTenキャッシュ表からキャッシュされたOracle Database表に同期ライトスルー処理が実行されるようにするには、このOracle Databaseユーザーにoratt.product表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

SWTキャッシュ・グループを作成するには、CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP文を使用します。

例4-8 SWTキャッシュ・グループの作成

次の文では、oratt.product表をキャッシュするSYNCHRONOUS WRITETHROUGHキャッシュ・グループtop_productsが作成されます。

CREATE SYNCHRONOUS WRITETHROUGH CACHE GROUP top_products
FROM oratt.product
(prod_num    VARCHAR2(6) NOT NULL,
name        VARCHAR2(30),
price       NUMBER(8,2),
ship_weight NUMBER(4,1),
PRIMARY KEY(prod_num));

TimesTenでSWTキャッシュ・グループの操作を管理する場合、TimesTenは、ユーザーの現在の資格証明をユーザー名に、OraclePwd接続属性をOracleパスワードに使用してOracle Databaseに接続します。SWTキャッシュ・グループの操作を管理する場合、TimesTenでは、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続しません。詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。

SWTキャッシュ・グループの使用の制限

SWTキャッシュ・グループを使用する場合は、次の制限が適用されます。

- キャッシュ表定義では、ON DELETE CASCADEおよびUNIQUE HASH ONキャッシュ表属性のみを使用できます。
ON DELETE CASCADEキャッシュ表属性の詳細は、「ON DELETE CASCADEキャッシュ表属性」を参照してください。

UNIQUE HASH ONキャッシュ表属性の詳細は、「UNIQUE HASH ONキャッシュ表属性」を参照してください。

- キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- キャッシュ表定義にWHERE句を含めることはできません。
キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。

- キャッシュ表に対してTRUNCATE TABLE文を発行できません。

- SWTキャッシュ・グループでは、Oracle Databaseビューまたはマテリアライズド・ビューをキャッシュできません。

- SWTキャッシュ・グループにキャッシュされているOracle Database表では、直接DML文を実行することは避けてください。これにより、エラー状態になる場合があります。キャッシュされたOracle Database表で挿入、更新または削除処理のいずれかを行うと、処理対象の行に対してTimesTenで実行される処理に不適切な影響を与える場合があります。TimesTenでは、Oracle Databaseで発生する更新競合は検出または解決されません。キャッシュされたOracle Database表で直接コミットされた更新は、キャッシュ表の更新がOracle Databaseに伝播されたときに、TimesTenキャッシュ表でコミットされた更新によって上書きされる場合があります。さらに、キャッシュされたOracle Database表で行を削除すると、TimesTenがすでに存在しない行に対して更新を試みたときに、更新が適用されなくなる場合があります。
Oracle DatabaseですべてのデータがDML文から制限を受けることがないようにするために、Oracle Databaseでデータを分割して、SWTキャッシュ・グループに含まれているデータとSWTキャッシュ・グループから除外されるデータとを分けることができます。

ユーザー管理キャッシュ・グループ

システム管理キャッシュ・グループ(読取り専用、AWT、SWT)がアプリケーションの要件を満たさない場合は、次のキャッシュ表属性の1つ以上を持つ、カスタマイズされたキャッシュ動作を定義するユーザー管理キャッシュ・グループを作成できます。

注意:
TimesTenでユーザー管理キャッシュ・グループの操作を管理する場合、TimesTenは、ユーザーの現在の資格証明をユーザー名に、OraclePwd接続属性をOracleパスワードに使用してOracle Databaseに接続します。ユーザー管理キャッシュ・グループの操作では、TimesTenは、ttCacheUidPwdSet組込みプロシージャで設定されているキャッシュ管理ユーザーの名前およびパスワードを使用してOracle Databaseに接続しません。詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。

- ユーザー管理キャッシュ・グループ内の各キャッシュ表に対してREADONLYキャッシュ表属性を指定すると、TimesTenでデータがOracle Databaseから表レベルでリフレッシュされる読取り専用の動作を定義できます。

- ユーザー管理キャッシュ・グループ内の各キャッシュ表に対してPROPAGATEキャッシュ表属性を指定すると、表レベルで同期ライトスルーの動作を定義できます。PROPAGATEキャッシュ表属性は、キャッシュ表に対してコミットされた更新が、キャッシュされたOracle Database表に自動的に同期して伝播されるように指定します。

- ユーザー管理キャッシュ・グループは、AUTOREFRESHキャッシュ・グループ属性およびPROPAGATEキャッシュ表属性を使用することによって、コミットされた更新をOracle DatabaseとTimesTenデータベースの間で自動的にリフレッシュおよび伝播するように定義できます。両方の属性を使用すると、双方向送信が可能になるため、TimesTenキャッシュ表またはキャッシュされたOracle Database表に対してコミットされた更新が、相互に伝播またはリフレッシュされます。
自動リフレッシュのモード、間隔および状態の定義の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

- LOAD CACHE GROUP文、REFRESH CACHE GROUP文およびFLUSH CACHE GROUP文を使用して、Oracle DatabaseとTimesTenデータベースの間でのコミットされた更新の送信を手動で制御できます。
LOAD CACHE GROUP文およびREFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- PROPAGATEキャッシュ・グループ属性またはAUTOREFRESHキャッシュ・グループ属性を使用しないユーザー管理キャッシュ・グループに、Oracle Databaseマテリアライズド・ビューをキャッシュできます。キャッシュ・グループは、手動でロードおよびフラッシュする必要があります。Oracle Databaseビューはキャッシュできません。

ユーザー管理キャッシュ・グループの詳細は、次の各項を参照してください。

- READONLYキャッシュ表属性

- PROPAGATEキャッシュ表属性

- ユーザー管理キャッシュ・グループの例

READONLYキャッシュ表属性

READONLYキャッシュ表属性は、ユーザー管理キャッシュ・グループ内のキャッシュ表に対してのみ指定できます。READONLYは、キャッシュ表が直接更新されないように指定します。デフォルトでは、ユーザー管理キャッシュ・グループ内のキャッシュ表は更新可能です。

すべてのキャッシュ表が読取り専用である読取り専用キャッシュ・グループとは異なり、ユーザー管理キャッシュ・グループでは、READONLYキャッシュ表属性を使用して、個々のキャッシュ表を読取り専用に指定できます。

例4-10では、oratt.cust_interestsキャッシュ表のREADONLYキャッシュ表属性を示します。

READONLYキャッシュ表属性を使用する場合は、次の制限が適用されます。

- キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、すべてのキャッシュ表でREADONLYキャッシュ表属性を指定するか、またはいずれのキャッシュ表にもREADONLYキャッシュ表属性を指定しないようにする必要があります。
AUTOREFRESHキャッシュ・グループ属性の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

- READONLYとPROPAGATEキャッシュ表属性の両方を同じキャッシュ表で使用することはできません。
PROPAGATEキャッシュ表属性の詳細は、「PROPAGATEキャッシュ表属性」を参照してください。

- 1つ以上のキャッシュ表でREADONLYキャッシュ表属性もPROPAGATEキャッシュ表属性も使用していない場合を除いて、キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- キャッシュ表にREADONLYキャッシュ表属性が指定されると、キャッシュ・グループを削除して再度作成する場合を除いて、この属性を変更できません。

PROPAGATEキャッシュ表属性

PROPAGATEキャッシュ表属性は、ユーザー管理キャッシュ・グループ内のキャッシュ表に対してのみ指定できます。PROPAGATEは、TimesTenトランザクションの一部としてTimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に同期して伝播されるように指定します。PROPAGATEキャッシュ表属性を指定しない場合、ユーザー管理キャッシュ・グループ内のキャッシュ表のデフォルトの設定は、NOT PROPAGATEキャッシュ表属性になります(キャッシュ表でコミットされた更新は、キャッシュされたOracle表に伝播されません)。

キャッシュ表でアプリケーションによって実行されるSQL文はすべて、キャッシュ表に即座に適用されます。これはの処理はすべて、トランザクションがコミットされるまで、またはメモリーの上限に達するまでバッファされます。この時点で、すべての処理がOracle Database内の表に伝播されます。

注意:
TimesTenデータベースまたはそのデーモンが予期せずに失敗した場合、TimesTenデータベースまたはOracle Databaseでのトランザクションの結果は保証されません。

トランザクションでの処理はTimesTenデータベースとOracle Databaseの両方の表に適用されるため、コミットのプロセスは次のようになります。

1. 処理がOracle Databaseに伝播されると、Oracle Databaseではまずコミットが試行されます。

- Oracle Databaseの表で処理が適用されたときにエラーが発生した場合は、Oracle Databaseの表ですべての処理がロールバックされます。Oracle Databaseでコミットが失敗すると、TimesTenデータベースではコミットが試行されず、アプリケーションはTimesTenトランザクションをロールバックする必要があります。ユーザーが別の文を実行しようとすると、ロールバックが必要であることを示すエラーが表示されます。このため、Oracle DatabaseはTimesTenでコミットされた更新を見落とすことがなくなります。

2. Oracle Databaseでコミットが成功すると、TimesTenデータベースでコミットが試行されます。

- Oracle Databaseでトランザクションが正常にコミットされると、TimesTenでユーザーのトランザクションがコミットされ(トランザクション・ログのコミット・ログ・レコードにより示されます)、アプリケーションに通知されます。TimesTenがローカル・コミットに成功したことを通知する前にアプリケーションが突然終了した場合でも、TimesTenは、トランザクション・ログに保存されている内容を基にして、TimesTenでトランザクションのコミットをファイナライズできます。

- Oracle Databaseでトランザクションが正常にコミットされた一方、TimesTenではコミットのステータスを返す前に障害が発生した場合、成功したコミットのレコードはトランザクション・ログには書き込まれず、トランザクションはロールバックされます。

- TimesTenでコミットが失敗すると、失敗の原因を示すエラー・メッセージがTimesTenから返されます。この場合は、手動でキャッシュ表をOracle Database表と再同期化する必要があります。

注意:
キャッシュ表をOracle Database表と再同期化する方法の詳細は、「SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ」を参照してください。

ttCachePropagateFlagSet組込みプロシージャを使用して、TimesTenキャッシュ表でコミットされた更新をOracle Databaseに伝播することを無効化できます。この組込みプロシージャを使用すると、現在のトランザクションでTimesTenのキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に伝播されないようにするために、自動伝播を有効または無効にできます。後で、ttCachePropagateFlagSet組込みプロシージャでこのフラグを1に再設定することによって、DML文の伝播を再有効化できます。このフラグの設定を1に戻した後は、Oracle Databaseに対してコミットされた更新の伝播が再開されます。伝播フラグは、トランザクションのコミット後またはロールバック後に自動的に1に再設定されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCachePropagateFlagSetに関する説明を参照してください。

例4-9では、oratt.active_customerキャッシュ表のPROPAGATEキャッシュ表属性の使用方法を示します。

PROPAGATEキャッシュ属性の使用の制限

PROPAGATEキャッシュ表属性を使用する場合は、次の制限が適用されます。

- キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、すべてのキャッシュ表でPROPAGATEキャッシュ表属性を指定するか、またはいずれのキャッシュ表にもPROPAGATEキャッシュ表属性を指定しないようにする必要があります。
AUTOREFRESHキャッシュ・グループ属性の詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

- キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用する場合は、いずれのキャッシュ表に対してもNOT PROPAGATEキャッシュ表属性を明示的に指定できません。

- PROPAGATEとREADONLYキャッシュ表属性の両方を同じキャッシュ表で使用することはできません。
READONLYキャッシュ表属性の詳細は、「READONLYキャッシュ表属性」を参照してください。

- 1つ以上のキャッシュ表でPROPAGATEキャッシュ表属性もREADONLYキャッシュ表属性も使用していない場合を除いて、キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- キャッシュ表にPROPAGATEキャッシュ表属性が指定されると、キャッシュ・グループを削除して再度作成する場合を除いて、この属性を変更できません。

- Oracle Databaseマテリアライズド・ビューをキャッシュする場合は、PROPAGATEキャッシュ表属性を使用できません。

- TimesTenでは、キャッシュされたOracle Database表で直接更新されたデータが、伝播処理によって上書きされないようにするための競合チェックを実行しません。したがって、TimesTenキャッシュ表またはキャッシュされたOracle Database表で更新を直接実行し、両方の表では更新を実行しないようにしてください。

ユーザー管理キャッシュ・グループの例

例4-9および例4-10に定義されたユーザー管理キャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。

CREATE TABLE active_customer
(custid NUMBER(6) NOT NULL PRIMARY KEY,
name   VARCHAR2(50),
addr   VARCHAR2(100),
zip    VARCHAR2(12),
region VARCHAR2(12) DEFAULT 'Unknown');

CREATE TABLE ordertab
(orderid NUMBER(10) NOT NULL PRIMARY KEY,
custid  NUMBER(6) NOT NULL);

CREATE TABLE cust_interests
(custid   NUMBER(6) NOT NULL,
interest VARCHAR2(10) NOT NULL,
PRIMARY KEY (custid, interest));

CREATE TABLE orderdetails
(orderid  NUMBER(10) NOT NULL,
itemid   NUMBER(8) NOT NULL,
quantity NUMBER(4) NOT NULL,
PRIMARY KEY (orderid, itemid));

ユーザー管理キャッシュ・グループを作成するには、CREATE USERMANAGED CACHE GROUP文を使用します。

例4-9 単一表のユーザー管理キャッシュ・グループの作成

次の文では、図4-8に示すように、oratt.active_customer表をキャッシュするユーザー管理キャッシュ・グループupdate_anywhere_customersが作成されます。

CREATE USERMANAGED CACHE GROUP update_anywhere_customers
AUTOREFRESH MODE INCREMENTAL INTERVAL 30 SECONDS
FROM oratt.active_customer
(custid NUMBER(6) NOT NULL,
name   VARCHAR2(50),
addr   VARCHAR2(100),
zip    VARCHAR2(12),
PRIMARY KEY(custid),
PROPAGATE);

例4-8 単一表のユーザー管理キャッシュ・グループ

この例では、oratt.active_customer表のregion以外の列はすべてTimesTenにキャッシュされます。これはPROPAGATEキャッシュ表属性で定義されるため、TimesTenのキャッシュ表oratt.active_customerでコミットされた更新は、キャッシュされたOracle Database表oratt.active_customerに転送されます。ユーザー管理キャッシュ表もAUTOREFRESHキャッシュ属性で定義されるため、Oracle Database表oratt.active_customerでコミットされた更新はすべて、キャッシュ表update_anywhere_customersに転送されます。

キャッシュ・マネージャ・ユーザーが、oratt.active_customer表をキャッシュするユーザー管理キャッシュ・グループを作成できるようにし、キャッシュされたOracle Database表からTimesTenキャッシュ表への自動リフレッシュ処理が実行されるようにするには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。TimesTenキャッシュ表からキャッシュされたOracle Database表に同期ライトスルー処理が実行されるようにするには、コンパニオンOracle Databaseユーザーにoratt.active_customer表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

この例で、AUTOREFRESHキャッシュ・グループ属性は、キャッシュされたOracle Database表oratt.active_customerに対してコミットされた更新が、TimesTenのoratt.active_customer cache表に30秒ごとに自動的にリフレッシュされるように指定します。

「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」の説明に従って、AUTOREFRESH MODE INCREMENTALキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループの定義済動作を実行するためにOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。

次に、ttIsqlユーティリティのcachesqlgetコマンドを実行して、ユーザー管理キャッシュ・グループにキャッシュされるOracle Database表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトを生成する必要があります。

詳細は、「自動リフレッシュ・キャッシュ・グループ用のOracle Databaseオブジェクトの手動による作成」を参照してください。

例4-10 複数表のユーザー管理キャッシュ・グループの作成

次の文では、図4-9に示すように、oratt.active_customer、oratt.ordertab、oratt.cust_interestsおよびoratt.orderdetailsの各表をキャッシュするユーザー管理キャッシュ・グループwestern_customersが作成されます。

CREATE USERMANAGED CACHE GROUP western_customers
FROM oratt.active_customer
(custid NUMBER(6) NOT NULL,
name   VARCHAR2(50),
addr   VARCHAR2(100),
zip    VARCHAR2(12),
region VARCHAR2(12),
PRIMARY KEY(custid),
PROPAGATE)
WHERE (oratt.active_customer.region = 'West'),
oratt.ordertab
(orderid NUMBER(10) NOT NULL,
custid  NUMBER(6) NOT NULL,
PRIMARY KEY(orderid),
FOREIGN KEY(custid) REFERENCES oratt.active_customer(custid),
PROPAGATE),
oratt.cust_interests
(custid   NUMBER(6) NOT NULL,
interest VARCHAR2(10) NOT NULL,
PRIMARY KEY(custid, interest),
FOREIGN KEY(custid) REFERENCES oratt.active_customer(custid),
READONLY),
oratt.orderdetails
(orderid  NUMBER(10) NOT NULL,
itemid   NUMBER(8) NOT NULL,
quantity NUMBER(4) NOT NULL,
PRIMARY KEY(orderid, itemid),
FOREIGN KEY(orderid) REFERENCES oratt.ordertab(orderid))
WHERE (oratt.orderdetails.quantity >= 5);

例4-9 複数表のユーザー管理キャッシュ・グループ

同じ品目を5つ以上注文したWest地域の顧客のみがキャッシュされます。

キャッシュ・マネージャ・ユーザーが、oratt.active_customer、oratt.ordertab、oratt.cust_interestsおよびoratt.orderdetailsの各表すべてをキャッシュするユーザー管理キャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、これらの表に対するSELECT権限が付与されている必要があります。また、これらのTimesTenキャッシュ表からキャッシュされたOracle Database表に同期ライトスルー処理が実行されるようにするには、コンパニオンOracle Databaseユーザーにoratt.active_customer表およびoratt.ordertab表に対するINSERT、UPDATEおよびDELETE権限が付与されている必要があります。

western_customersキャッシュ・グループ内の各キャッシュ表には主キーがあります。各子表は、外部キー制約を使用して親表を参照します。oratt.active_customerルート表およびoratt.orderdetails子表には、それぞれキャッシュされる行を制限するWHERE句が含まれます。oratt.active_customerルート表とoratt.ordertab子表の両方でPROPAGATEキャッシュ表属性を使用しているため、これらのキャッシュ表でコミットされた更新は、キャッシュされたOracle Database表に自動的に伝播されます。oratt.cust_interests子表ではREADONLYキャッシュ表属性を使用しているため、この表は直接更新できません。

AUTOREFRESHキャッシュ・グループ属性

AUTOREFRESHキャッシュ・グループ属性は、CREATE CACHE GROUP文を使用して読取り専用キャッシュ・グループまたはユーザー管理キャッシュ・グループを作成する場合に指定できます。AUTOREFRESHは、キャッシュされたOracle Database表でコミットされた更新が、TimesTenキャッシュ表に自動的にリフレッシュされるように指定します。読取り専用キャッシュ・グループには、デフォルトで自動リフレッシュが定義されます。

自動リフレッシュ属性のデフォルト設定は、次のとおりです。

- 自動リフレッシュ・モードはINCREMENTALです。

- 自動リフレッシュの間隔は5分です。

- 自動リフレッシュの状態はPAUSEDです。

TimesTenでは、2つの自動リフレッシュ・モードがサポートされています。

- INCREMENTAL: キャッシュ・グループの自動リフレッシュ間隔に基づいて、キャッシュされたOracle Database表でコミットされた更新がTimesTenキャッシュ表に自動的にリフレッシュされます。増分自動リフレッシュ・モードでは、Oracle Databaseオブジェクトを使用して、キャッシュされたOracle Database表でコミットされた更新を追跡します。これらのオブジェクトの詳細は、「Oracle Databaseオブジェクトによるキャッシュ環境の管理」を参照してください。

- FULL: キャッシュ・グループの自動リフレッシュ間隔に基づいて、すべての行をアンロードした後、キャッシュされたOracle Database表からリロードすることによって、すべてのキャッシュ表が自動的にリフレッシュされます。

増分自動リフレッシュ・モードを使用すると、キャッシュされたOracle Database表でコミットされた更新ごとにキャッシュ・グループをリフレッシュするためのオーバーヘッドが発生します。完全自動リフレッシュ・モードを使用すると、オーバーヘッドは発生しません。

増分自動リフレッシュ・モードを使用すると、キャッシュされたOracle Database表でコミットされた更新は、Oracle Database内の変更ログ表で追跡されます。特定の環境下では、変更ログ・レコードの一部が、TimesTenキャッシュ表に自動的にリフレッシュされる前に変更ログ表から削除される可能性があります。このような状況が発生すると、TimesTenはキャッシュ・グループの完全自動リフレッシュを開始します。変更ログ表が存在する表領域が一杯になった場合に実行するアクションを構成する方法の詳細は、「キャッシュ管理ユーザーの表領域の監視」を参照してください。

Oracle Database内の変更ログ表では、パフォーマンス上の理由から、列レベルの解決を行いません。したがって、自動リフレッシュ処理により、行内のすべての列が更新されます。たとえ実際に各列でデータが変更されていなくても、XLAにより、行内のすべての列が変更されたことが報告されます。

自動リフレッシュ間隔では、自動リフレッシュ処理の実行頻度を分、秒またはミリ秒の単位で指定します。自動リフレッシュ間隔が同じキャッシュ・グループは、同じトランザクション内でリフレッシュされます。ttCacheAutorefresh組込みプロシージャを使用すると、即時自動リフレッシュ処理を開始できます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAutorefreshに関する説明を参照してください。

自動リフレッシュ状態はON、PAUSEDまたはOFFに設定できます。自動リフレッシュ処理はキャッシュ・グループの自動リフレッシュ状態がONの場合に、TimesTenによりスケジュールされます。

キャッシュ・グループの自動リフレッシュ状態がOFFの場合、キャッシュされたOracle Database表でコミットされた更新は追跡されません。

キャッシュ・グループの自動リフレッシュ状態がPAUSEDの場合、キャッシュされたOracle Database表でコミットされた更新はOracle Database内で追跡されますが、状態がONに変更されるまでTimesTenキャッシュ表には自動的にリフレッシュされません。

AUTOREFRESHキャッシュ・グループ属性を使用する場合は、次の制限が適用されます。

- キャッシュ・グループに対してFLUSH CACHE GROUP文を発行できません。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- キャッシュされたOracle Database表に対して発行されたTRUNCATE TABLE文は、TimesTenキャッシュ表に自動的にリフレッシュされません。キャッシュされたOracle Database表に対してTRUNCATE TABLE文を発行する前に、ALTER CACHE GROUP文を使用して、キャッシュ表を含むキャッシュ・グループの自動リフレッシュ状態をPAUSEDに変更してください。
ALTER CACHE GROUP文の詳細は、「キャッシュ・グループの変更によるAUTOREFRESHのモード、間隔または状態の変更」を参照してください。

キャッシュされたOracle Database表に対してTRUNCATE TABLE文を発行した後、REFRESH CACHE GROUP文を使用してキャッシュ・グループを手動でリフレッシュします。

- キャッシュ・グループが動的である場合を除いて、LOAD CACHE GROUP文を発行できるのはキャッシュ表が空の場合のみです。
LOAD CACHE GROUP文およびREFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

動的キャッシュ・グループの詳細は、「動的キャッシュ・グループ」を参照してください。

- キャッシュ・グループが動的でないかぎ、キャッシュ・グループに対してLOAD CACHE GROUP文を発行する前の自動リフレッシュ状態はPAUSEDである必要があります。キャッシュ・グループが動的である場合は、自動リフレッシュ状態はPAUSEDまたはONであることが必要です。キャッシュ・グループが動的な場合を除いて、LOAD CACHE GROUP文にWHERE句を含めることはできず、キャッシュ・グループが動的な場合は、WHERE句の後にCOMMIT EVERY n ROWS句を続ける必要があります。
キャッシュ・グループの定義および処理でのWHERE句の詳細は、「WHERE句の使用」を参照してください。

- REFRESH CACHE GROUP文をキャッシュ・グループに対して発行するには、自動リフレッシュ状態がPAUSEDになっている必要があります。REFRESH CACHE GROUP文にWHERE句を含めることはできません。

- キャッシュ・グループの作成、ロードまたはアンロード時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name

- ユーザー管理キャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用するには、すべてのキャッシュ表にPROPAGATEキャッシュ表属性が指定されているか、またはすべてのキャッシュ表にREADONLYキャッシュ表属性が指定されている必要があります。

- NOT PROPAGATEキャッシュ表属性を明示的に使用するキャッシュ表を含むユーザー管理キャッシュ・グループでは、AUTOREFRESHキャッシュ・グループ属性を指定できません。

- ユーザー管理キャッシュ・グループにOracle Databaseマテリアライズド・ビューをキャッシュする場合は、AUTOREFRESHキャッシュ表属性を使用できません。

- LRUエージングがデフォルトで定義されている、キャッシュ・グループが動的である場合を除いて、キャッシュ・グループにLRUエージングを指定できません。
LRUエージングの詳細は、「LRUエージング」を参照してください。

AUTOREFRESHキャッシュ・グループ属性を使用するキャッシュ・グループに対して一意索引を作成する場合は、制約違反を回避するために索引が非一意索引に変更されます。Oracle Database表に対して同じ文を実行すると更新競合が発生する可能性があるため、一意索引によって制約違反が発生する可能性がありますが、TimesTenでは各行の更新が個別に実行されます。キャッシュされているOracle Database表に一意索引が存在する場合は、Oracle Database表で一意性が確保されるため、TimesTenで再度確認する必要はありません。

例4-9では、update_anywhere_customersキャッシュ・グループでAUTOREFRESHキャッシュ・グループ属性を使用しています。

キャッシュ・グループの変更によるAUTOREFRESHのモード、間隔または状態の変更

自動リフレッシュ・キャッシュ・グループを作成した後、ALTER CACHE GROUP文を使用すると、キャッシュ・グループの自動リフレッシュのモード、間隔または状態を変更できます。最初から自動リフレッシュを定義せずに作成されたキャッシュ・グループに対しては、ALTER CACHE GROUPを使用して自動リフレッシュをインスタンス化することはできません。

キャッシュ・グループの自動リフレッシュ状態をOFFに変更したり、自動リフレッシュ処理を実行中のキャッシュ・グループを削除した場合の動作は、次のとおりです。

- LockWait接続属性設定が0(ゼロ)より大きな値である場合、自動リフレッシュ処理は停止します。ALTER CACHE GROUP文またはDROP CACHE GROUP文が自動リフレッシュ処理より優先して使用されます。

- LockWait接続属性が0(ゼロ)に設定されている場合、自動リフレッシュ処理は続行します。自動リフレッシュ処理が完了するか、またロック・タイムアウト・エラーが発生して文が失敗するまで、ALTER CACHE GROUP文またはDROP CACHE GROUP文はブロックされます。

例4-11 キャッシュ・グループの自動リフレッシュ属性の変更

次の文では、customer_ordersキャッシュ・グループの自動リフレッシュのモード、間隔および状態が変更されます。

ALTER CACHE GROUP customer_orders SET AUTOREFRESH MODE FULL;
ALTER CACHE GROUP customer_orders SET AUTOREFRESH INTERVAL 30 SECONDS;
ALTER CACHE GROUP customer_orders SET AUTOREFRESH STATE ON;

自動リフレッシュ・キャッシュ・グループ用のOracle Databaseオブジェクトの手動による作成

「データのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」の説明に従って、自動リフレッシュ・キャッシュ・グループの定義済動作を実行するためにOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・グループを作成するときに、自動リフレッシュ状態をOFFに設定する必要があります。

次に、キャッシュ・マネージャ・ユーザーとして、INCREMENTAL_AUTOREFRESHオプションおよびINSTALLフラグを指定してttIsqlユーティリティのcachesqlgetコマンドを実行する必要があります。このコマンドを実行すると、自動リフレッシュ・キャッシュ・グループにキャッシュされたOracle Database表ごとに、Oracle Database内にログ表およびトリガーを作成するSQL*Plusスクリプトが生成されます。これらのOracle Databaseオブジェクトは、キャッシュされたOracle Database表の更新を追跡するため、キャッシュ表に対して更新を自動的にリフレッシュできます。

次に、SQL*Plusを使用して、ttIsqlユーティリティのcachesqlgetコマンドで生成されたスクリプトをsysユーザーとして実行します。その後、ALTER CACHE GROUP文を使用して、キャッシュ・グループの自動リフレッシュ状態をPAUSEDに変更します。

例4-12 Oracle Databaseオブジェクトを手動で作成した場合の読取り専用キャッシュ・グループの作成

最初の文で、自動リフレッシュ状態がOFFに設定された読取り専用キャッシュ・グループcustomer_ordersが作成されます。ttIsqlユーティリティのcachesqlgetコマンドで生成されたSQL*Plusスクリプトは、/tmp/obj.sqlファイルに保存されます。最後の文によって、キャッシュ・グループの自動リフレッシュ状態がPAUSEDに変更されます。

CREATE READONLY CACHE GROUP customer_orders
AUTOREFRESH STATE OFF
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num)),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> cachesqlget INCREMENTAL_AUTOREFRESH customer_orders INSTALL /tmp/obj.sql;
Command> exit

% sqlplus sys as sysdba
Enter password: password
SQL> @/tmp/obj
SQL> exit

ALTER CACHE GROUP customer_orders SET AUTOREFRESH STATE PAUSED;

WHERE句の使用

CREATE CACHE GROUP文内のキャッシュ表定義には、特定のキャッシュ・グループ・タイプについて、TimesTenデータベースにキャッシュする行を制限するWHERE句を含めることができます。

また、特定のキャッシュ・グループ・タイプの場合、LOAD CACHE GROUP文、UNLOAD CACHE GROUP文、REFRESH CACHE GROUP文またはFLUSH CACHE GROUP文にWHERE句を指定することもできます。LOAD CACHE GROUP文やREFRESH CACHE GROUP文などのいくつかの文では、キャッシュ表定義のWHERE句がLOAD CACHE GROUP文またはREFRESH CACHE GROUP文のWHERE句より前に評価される連結WHERE句が発生する場合があります。

キャッシュ表定義およびキャッシュ・グループ処理で使用されるWHERE句には、次の制限が適用されます。

- CREATE CACHE GROUP文のキャッシュ表定義にWHERE句を指定できるのは、読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループの場合のみです。

- 明示的にロードされる自動リフレッシュ・キャッシュ・グループ以外では、LOAD CACHE GROUP文にWHERE句を指定できます。
LOAD CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

- 自動リフレッシュ・キャッシュ・グループ以外では、REFRESH CACHE GROUP文にWHERE句を指定できます。
REFRESH CACHE GROUP文の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

- TimesTenキャッシュ表でコミットされた更新を、キャッシュされたOracle Database表にフラッシュできるユーザー管理キャッシュ・グループでは、FLUSH CACHE GROUP文にWHERE句を指定できます。
FLUSH CACHE GROUP文の詳細は、「ユーザー管理キャッシュ・グループのフラッシュ」を参照してください。

- CREATE CACHE GROUP文のWHERE句には、副問合せを使用できません。したがって、各WHERE句では、キャッシュ表定義内にある表以外の表を参照できません。ただし、LOAD CACHE GROUP文、UNLOAD CACHE GROUP文、REFRESH CACHE GROUP文またはFLUSH CACHE GROUP文のWHERE句には、副問合せが含まれる場合があります。

- WHERE句に副問合せが含まれる場合を除いて、LOAD CACHE GROUP文、REFRESH CACHE GROUP文またはFLUSH CACHE GROUP文のWHERE句で参照できるのは、キャッシュ・グループのルート表のみです。

- キャッシュ表定義内のWHERE句が実行されるのは、キャッシュ・グループが手動でロードまたはリフレッシュされた場合、あるいはキャッシュ表が動的にロードされた場合のみです。キャッシュ表が更新可能な場合は、行を挿入または更新すると、その行のキャッシュ表定義内のWHERE句の条件が満たされなくなります。

- キャッシュ・グループの作成、ロード、リフレッシュ、アンロードまたはフラッシュ時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name

例4-10では、oratt.active_customer表とoratt.orderdetails表の両方にWHERE句が含まれます。

CREATE CACHE GROUP文でのWHERE句の適切な配置

複数表のキャッシュ・グループでは、特定の表定義内のWHERE句で、キャッシュ・グループ内のその表以外の表を参照することはできません。たとえば、次のCREATE CACHE GROUP文は有効です。

CREATE READONLY CACHE GROUP customer_orders
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num))
WHERE (oratt.customer.cust_num < 100),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));

CREATE READONLY CACHE GROUP customer_orders
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num)),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));
WHERE (oratt.orders.cust_num < 100)

次の文は、子表の定義内のWHERE句が親表を参照しているため無効です。

CREATE READONLY CACHE GROUP customer_orders
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num)),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num))
WHERE (oratt.customer.cust_num < 100);

同様に、次の文は、親表の定義内のWHERE句が子表を参照しているため無効です。

CREATE READONLY CACHE GROUP customer_orders
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num))
WHERE (oratt.orders.cust_num < 100),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num));

WHERE句でのOracle Database PL/SQLファンクションの参照

Oracle Databaseのユーザー定義PL/SQLファンクションは、CREATE CACHE GROUP文、LOAD CACHE GROUP文またはREFRESH CACHE GROUP文のWHERE句で(動的キャッシュ・グループの場合のみ)、間接的に起動できます。ファンクションを作成した後、そのファンクションのパブリック・シノニムを作成します。次に、ファンクションのEXECUTE権限をPUBLICに付与します。

たとえば、Oracle Databaseでは、次のとおりです。

CREATE OR REPLACE FUNCTION get_customer_name
(c_num oratt.customer.cust_num%TYPE) RETURN VARCHAR2 IS
c_name oratt.customer.name%TYPE;
BEGIN
SELECT name INTO c_name FROM oratt.customer WHERE cust_num = c_num;
RETURN c_name;
END get_customer_name;

CREATE PUBLIC SYNONYM retname FOR get_customer_name;
GRANT EXECUTE ON get_customer_name TO PUBLIC;

次に、TimesTenデータベースでは、たとえば、このファンクション用に作成されたOracle Databaseパブリック・シノニムを参照するWHERE句を指定して、キャッシュ・グループを作成できます。

CREATE READONLY CACHE GROUP top_customer
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num))
WHERE name = retname(100);

LOAD CACHE GROUP文またはREFRESH CACHE GROUP文にWHERE句を使用できるキャッシュ・グループ・タイプの場合は、ファンクション用に作成されたパブリック・シノニムを参照することによって、そのファンクションを間接的に起動できます。たとえば、次のLOAD CACHE GROUP文を使用して、AWTキャッシュ・グループnew_customersをロードできます。

LOAD CACHE GROUP new_customers WHERE name = retname(101) COMMIT EVERY 0 ROWS;

ON DELETE CASCADEキャッシュ表属性

ON DELETE CASCADEキャッシュ表属性は、いずれのキャッシュ・グループ・タイプのキャッシュ表にも指定できます。ON DELETE CASCADEは、参照されるキー値を含む行が親表から削除されると、依存する外部キーを持つ子表の行も削除されるように指定します。

例4-13 ON DELETE CASCADEキャッシュ表属性の使用

次の文では、子表の外部キー定義でON DELETE CASCADEキャッシュ表属性が使用されます。

CREATE READONLY CACHE GROUP customer_orders
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num)),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num) ON DELETE CASCADE);

親表から子表へのすべてのパスは、削除パスまたは削除不可パスのいずれかである必要があります。1つの親表から1つの子表に対し、複数の削除パスおよび複数の削除不可パスは存在できません。ON DELETE CASCADEキャッシュ表属性は、削除パス上の子表に対して指定します。

ON DELETE CASCADEキャッシュ表属性を使用する場合は、次の制限が適用されます。

- AWTおよびSWTキャッシュ・グループの場合およびPROPAGATEキャッシュ表属性を使用するユーザー管理キャッシュ・グループ内のTimesTenキャッシュ表の場合、ON DELETE CASCADEキャッシュ表属性を使用するキャッシュ表の外部キーは、ON DELETE CASCADE属性を使用するキャッシュされたOracle Database表の外部キーの適切なサブセットである必要があります。キャッシュされたOracle Database表に対するON DELETE CASCADEアクションは、個々の削除としてTimesTenキャッシュ表に適用されます。キャッシュ表に対するON DELETE CASCADEアクションは、カスケード処理としてキャッシュされたOracle Database表に適用されます。

- TimesTenキャッシュ表とキャッシュされたOracle Database表間の外部キーの照合は、キャッシュ・グループの作成時にのみ実行されます。キャッシュされたOracle Database表の外部キーがキャッシュ・グループの作成後に変更された場合は、カスケード削除処理が機能しないことがあります。

ON DELETE CASCADEキャッシュ表属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE CACHE GROUP文に関する説明を参照してください。

UNIQUE HASH ONキャッシュ表属性

UNIQUE HASH ONキャッシュ表属性は、いずれのキャッシュ・グループ・タイプのキャッシュ表にも指定できます。UNIQUE HASH ONは、キャッシュ表の主キー列に、範囲索引ではなくハッシュ索引が作成されるように指定します。ハッシュ索引で指定される列は、主キーの列と同じである必要があります。また、UNIQUE HASH ONキャッシュ表属性は、ハッシュ索引のサイズの指定にも使用されます。

例4-14 UNIQUE HASH ONキャッシュ表属性の使用

次の文では、キャッシュ表の定義でUNIQUE HASH ONキャッシュ表属性が使用されます。

CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num))
UNIQUE HASH ON (cust_num) PAGES = 100;

UNIQUE HASH ONキャッシュ表属性の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE CACHE GROUP文に関する説明を参照してください。

Oracle Databaseシノニムのキャッシュ

AUTOREFRESHキャッシュ・グループ属性を使用しないAWT、SWTまたはユーザー管理キャッシュ・グループでは、プライベート・シノニムをキャッシュできます。プライベート・シノニムは、パブリック・シノニムまたはプライベート・シノニムを参照できますが、実際にキャッシュされるのは表であるため、最終的には表を参照する必要があります。

キャッシュされたシノニムによって直接的または間接的に参照される表は、シノニムをキャッシュするキャッシュ・グループの所有者と同じ名前を持つOracle Databaseユーザー以外のユーザーによって所有されます。表は、シノニムと同じOracle Databaseに存在する必要があります。キャッシュされたシノニム自体は、シノニムをキャッシュするキャッシュ・グループの所有者と同じ名前のOracle Databaseユーザーによって所有されます。

Oracle Database LOBデータのキャッシュ

Oracle Databaseラージ・オブジェクト(LOB)データをTimesTenキャッシュ・グループにキャッシュできます。TimesTenでは、次のようにデータをキャッシュします。

- Oracle Database CLOBデータは、TimesTen CLOBデータとしてキャッシュされます。

- Oracle Database BLOBデータは、TimesTen BLOBデータとしてキャッシュされます。

- Oracle Database NCLOBデータは、TimesTen NCLOBデータとしてキャッシュされます。

例4-15 Oracle Database LOBデータのキャッシュ

LOBフィールドを持つOracle Databaseに表を作成します。

CREATE TABLE t (
i INT NOT NULL PRIMARY KEY
, c CLOB
, b BLOB
, nc NCLOB);

Oracle Database表に値を挿入します。値は暗黙的にLOBデータ型に変換されます。

INSERT INTO t VALUES (1
, RPAD('abcdefg8', 2048, 'abcdefg8')
, HEXTORAW(RPAD('123456789ABCDEF8', 4000, '123456789ABCDEF8'))
, RPAD('abcdefg8', 2048, 'abcdefg8')
);

1 row inserted.

動的AWTキャッシュ・グループを作成し、レプリケーション・エージェントを起動します。

CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP cg1
FROM t
(i INT NOT NULL PRIMARY KEY
, c CLOB
, b BLOB
, nc NCLOB);

CALL ttrepstart;

TimesTenキャッシュ・グループに動的にデータをロードします。

SELECT * FROM t WHERE i = 1;

I:    1
C:    abcdefg8abcdefg8abcdefg8...
B:    123456789ABCDEF8123456789...
NC:   abcdefg8abcdefg8abcdefg8...

1 row found.

Oracle Database LOBデータのキャッシュに対する制約

Oracle Database LOBデータをTimesTenキャッシュ・グループにキャッシュする場合は、次の制限が適用されます。

- キャッシュ・グループの作成時に列サイズが適用されます。VARBINARY、VARCHAR2およびNVARCHAR2データ型のサイズ制限は4MBです。ユーザー定義の列のサイズを超える値は、通知なしに実行時に切り捨てられます。

- CLOBおよびBLOBデータ型のフィールド内にある空の値は、初期化されますがデータは入力されません。空のCLOBフィールドおよびBLOBフィールドは次のように処理されます。

- Oracle Databaseの空のLOBフィールドは、NULL値として返されます。

- 空のBLOBフィールドは、TimesTenのキャッシュにNULL値としてロードされます。

- TimesTenのキャッシュ内の空のVARCHAR2フィールドおよびVARBINARYフィールドは、NULL値として伝播されます。

また、自動リフレッシュ処理を行うように構成されたキャッシュ・グループでは、LOBデータのキャッシュに対して次の制限が適用されます。

- OCI関数またはDBMS_LOB PL/SQLパッケージによってOracle DatabaseでLOBデータが更新された場合、データはTimesTenキャッシュ・グループに自動的にはリフレッシュされません。これは、TimesTenのキャッシュがOracle Databaseトリガーに依存しているのに、Oracle Databaseトリガーはこのようなタイプの更新が発生しても実行されないためです。TimesTenは、更新が発生したもののTimesTenへのリフレッシュが行われなかったことをユーザーに通知しません。SQL文によってLOBが更新された場合は、トリガーが起動され、自動リフレッシュによってその変更が反映されます。

- 自動リフレッシュ処理を行うと、TimesTenのキャッシュ内のすべての行が更新されます。したがって、Oracle DatabaseのLOBデータに変更が発生しなくても、キャッシュされたLOBデータがTimesTenで更新されるように見える場合があります。

キャッシュ・グループでのエージングの実装

キャッシュ・グループに対して、エージング・タイプ、エージング属性およびエージング状態を指定するエージング・ポリシーを定義できます。TimesTenでは、最低使用頻度(LRU)エージングおよび時間ベースのエージングの2つのエージング・タイプがサポートされています。

LRUエージングでは、指定されたデータベースの使用状況の範囲に基づいて、最低使用頻度または最低参照頻度のデータが削除されます。時間ベースのエージングでは、指定されたデータ存続期間およびエージング・プロセスの頻度に基づいてデータが削除されます。同じTimesTenデータベース内でLRUエージングと時間ベースのエージングの両方を使用できますが、特定のキャッシュ・グループに対して定義できるエージング・ポリシーは1つのみです。

エージングはキャッシュ・インスタンス・レベルで実行されるため、エージング・ポリシーはCREATE CACHE GROUP文内のルート表のキャッシュ表定義で指定され、キャッシュ・グループ内のすべてのキャッシュ表に適用されます。エージ・アウトによってキャッシュ表から行が削除されたとき、キャッシュされたOracle Database表の行は削除されません。

キャッシュ・グループにエージング・ポリシーを追加するには、ルート表に対してALTER TABLE文を使用します。キャッシュ・グループのエージング・ポリシーを変更するには、ルート表に対してALTER TABLE文を使用して既存のエージング・ポリシーを削除した後、新しいエージング・ポリシーを追加します。

この項では、エージング・ポリシーを含むキャッシュ・グループ定義について説明します。内容は次のとおりです。

- LRUエージング

- 時間ベースのエージング

- エージング・プロセスの手動によるスケジューリング

- スライド期間の構成

LRUエージング

LRUエージングを使用すると、最低使用頻度のデータを削除することによって、TimesTenデータベースで使用するメモリーの量を、指定されたしきい値の範囲内に維持できます。LRUエージングは、明示的にロードされる自動リフレッシュ・キャッシュ・グループを除いて、すべてのキャッシュ・グループ・タイプに対して定義できます。動的キャッシュ・グループには、デフォルトでLRUエージングが定義されます。

キャッシュ・グループに対してLRUエージング・ポリシーを定義するには、CREATE CACHE GROUP文のキャッシュ表定義でAGING LRU句を使用します。エージング状態がデフォルトのONに設定されている場合、エージングは自動的に発生します。

例4-16 キャッシュ・グループに対するLRUエージング・ポリシーの定義

次の文では、AWTキャッシュ・グループnew_customersに対してLRUエージング・ポリシーが定義されます。

CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num))
AGING LRU ON;

ADMIN権限を持つユーザーとしてLRUエージング属性を設定するには、ttAgingLRUConfig組込みプロシージャを使用します。属性の設定は、TimesTenデータベース内でLRUエージング・ポリシーが定義されており、エージング状態がONであるすべての表に適用されます。

LRUエージング属性は、次のとおりです。

- LowUsageThreshold: TimesTenデータベースの領域使用状況(領域の割当て済サイズに対する永続領域の使用サイズの割合)がこの値以下になると、LRUエージングが無効になります。デフォルトの下限しきい値は0.8(80パーセント)です。

- HighUsageThreshold: TimesTenデータベースの領域使用状況がこの値を超えると、LRUエージングが有効になります。デフォルトの上限しきい値は0.9(90パーセント)です。

- AgingCycle: エージングが発生する頻度(分)。デフォルトのエージング・サイクルは1分です。

例4-17 LRUエージング属性の設定

次の組込みプロシージャ・コールは、エージング・プロセスによって5分ごとにチェックが行われ、TimesTenデータベースの永続領域の領域使用量が95パーセントを超えているかどうかが確認されるように指定します。超えている場合は、領域使用状況が75パーセント以下になるまで、最低使用頻度のデータが自動的にエージ・アウトまたは削除されます。

Command> CALL ttAgingLRUConfig(.75, .95, 5);

キャッシュ・グループにLRUエージング・ポリシーを定義した後に、AgingCycleに新しい値を設定すると、次回のエージングは現在のシステム時刻と新しいエージング・サイクルに基づいて発生します。たとえば、元のエージング・サイクルが15分で10分前にLRUエージングが発生した場合、5分後に再度エージングが発生します。ただし、エージング・サイクルを30分に変更すると、新しいエージング・サイクル設定を指定してttAgingLRUConfig組込みプロシージャをコールしてから30分後に次のエージングが発生します。

最後のエージング・サイクル以降に行がアクセスされたり、参照された場合、その行は現在のエージング・サイクルではLRUエージングの対象になりません。次のいずれかの場合に、行がアクセスされた、または参照されたとみなされます。

- 行がSELECT文またはINSERT ... SELECT文の結果セットを作成するために使用された。

- 保留中のトランザクションで更新または削除の対象としてマークされている。

複数表のキャッシュ・グループでは、最後のエージング・サイクル以降に子表内の行がアクセスされたり参照された場合、現在のエージング・サイクルでは、親表の関連行も子表の行もLRUエージングの対象になりません。

ALTER TABLE文を使用すると、キャッシュ・グループのLRUエージング・ポリシーの変更または定義に関連する次のタスクを実行できます。

- ルート表を指定し、SET AGING句を使用して、キャッシュ・グループのエージング状態を変更します。

- ルート表を指定し、ADD AGING LRU句を使用して、エージング・ポリシーが定義されていないキャッシュ・グループにLRUエージング・ポリシーを追加します。

- ルート表を指定し、DROP AGING句を使用して、キャッシュ・グループのLRUエージング・ポリシーを削除します。

キャッシュ・グループのエージング・ポリシーをLRUから時間ベースに変更するには、ルート表に対してALTER TABLE文とDROP AGING句を使用して、LRUエージング・ポリシーを削除します。次に、ルート表に対してALTER TABLE文とADD AGING USE句を使用して、時間ベースのエージング・ポリシーを追加します。

自動リフレッシュ・キャッシュ・グループでエージング・ポリシーを追加、変更または削除する前に、キャッシュ・エージェントを停止する必要があります。

時間ベースのエージング

時間ベースのエージングでは、エージング・ポリシーの指定されたデータ存続期間および頻度に基づいて、キャッシュ・グループからデータが削除されます。時間ベースのエージングは、すべてのキャッシュ・グループ・タイプに対して定義できます。

キャッシュ・グループに対して時間ベースのエージング・ポリシーを定義するには、CREATE CACHE GROUP文のキャッシュ表定義でAGING USE句を使用します。エージング状態がデフォルトのONに設定されている場合、エージングは自動的に発生します。

例4-19に定義されたAWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、例4-18で定義されています。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。

例4-18 Oracle Database表の定義

CREATE TABLE orders
(ord_num      NUMBER(10) NOT NULL PRIMARY KEY,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL);

CREATE TABLE order_item
(orditem_id NUMBER(12) NOT NULL PRIMARY KEY,
ord_num    NUMBER(10),
prod_num   VARCHAR2(6),
quantity   NUMBER(3));

キャッシュ・マネージャ・ユーザーが、oratt.orders表およびoratt.order_item表をキャッシュするAWTキャッシュ・グループを作成するには、TimesTenキャッシュ・マネージャ・ユーザーのコンパニオンOracle Databaseユーザーに、これらの表に対するSELECT権限が付与されている必要があります。Oracle Databaseに対して非同期ライトスルー処理を行うには、oratt.orders表およびoratt.order_item表においてキャッシュ管理ユーザーに、INSERT、UPDATEおよびDELETEのOracle Database権限が付与されている必要があります。

例4-19 キャッシュ・グループに対する時間ベースのエージング・ポリシーの定義

次の文では、AWTキャッシュ・グループordered_itemsに対して時間ベースのエージング・ポリシーが定義されます。

CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP ordered_items
FROM oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num))
AGING USE when_placed LIFETIME 45 DAYS CYCLE 60 MINUTES ON,
oratt.order_item
(orditem_id NUMBER(12) NOT NULL,
ord_num    NUMBER(10),
prod_num   VARCHAR2(6),
quantity   NUMBER(3),
PRIMARY KEY(orditem_id),
FOREIGN KEY(ord_num) REFERENCES oratt.orders(ord_num));

現在のシステム・タイムスタンプとoratt.orders表のwhen_placed列のタイムスタンプの差が45日を超えるキャッシュ・インスタンスは、エージングの対象となります。エージング・プロセスによって60分ごとにチェックが行われ、キャッシュ表から自動的にエージ・アウトまたは削除できるキャッシュ・インスタンスがあるかどうかが確認されます。

AGING USE句には、時間ベースのエージングに使用される、NULLを指定できないTIMESTAMP列またはDATE列の名前が必要です。この列は、タイムスタンプ列と呼ばれます。

各行のタイムスタンプ列の値には、その行が最後に挿入または更新された日付と時刻が保存されます。タイムスタンプ列の値は、アプリケーションによって保持されます。この列の値が不明な特定の行があり、それらの行を表からエージ・アウトしないときは、デフォルト値を大きくしてタイムスタンプ列を定義します。

タイムスタンプ列に索引を作成すると、エージング・プロセスのパフォーマンスを最適化できます。

追加された列はNULLを指定できない列として定義できないため、既存の表に列を追加して、その列をタイムスタンプ列として使用することはできません。定義された時間ベースのエージング・ポリシーが含まれている表からタイムスタンプ列を破棄することはできません。

存続期間は、AGING USE句のLIFETIMEキーワードの後に日、時間、分または秒の単位で指定します。

タイムスタンプ列の値は、現在のシステム・タイムスタンプから差し引かれます。結果は指定した存続期間の単位(日、時間、分、秒)まで切り捨てられ、指定した存続期間の値との比較が行われます。その結果が存続期間の値より大きい場合、行はエージングの対象となります。

CYCLEキーワードの後に、エージングが発生する頻度を日、時間、分または秒の単位で指定します。デフォルトのエージング・サイクルは5分です。エージング・サイクルに0(ゼロ)を指定した場合、連続的にエージングが行われます。

ALTER TABLE文を使用すると、キャッシュ・グループの時間ベースのエージング・ポリシーの変更または定義に関連する次のタスクを実行できます。

- ルート表を指定し、SET AGING句を使用して、キャッシュ・グループのエージング状態を変更します。

- ルート表を指定し、SET AGING LIFETIME句を使用して、存続期間を変更します。

- ルート表を指定し、SET AGING CYCLE句を使用して、エージング・サイクルを変更します。

- ルート表を指定し、ADD AGING USE句を使用して、エージング・ポリシーが定義されていないキャッシュ・グループに時間ベースのエージング・ポリシーを追加します。

- ルート表を指定し、DROP AGING句を使用して、キャッシュ・グループの時間ベースのエージング・ポリシーを削除します。

キャッシュ・グループのエージング・ポリシーを時間ベースからLRUに変更するには、ルート表に対してALTER TABLE文とDROP AGING句を使用して、時間ベースのエージング・ポリシーを削除します。次に、ルート表に対してALTER TABLE文とADD AGING LRU句を使用して、LRUエージング・ポリシーを追加します。

自動リフレッシュ・キャッシュ・グループでエージング・ポリシーを追加、変更または削除する前に、キャッシュ・エージェントを停止する必要があります。

エージング・プロセスの手動によるスケジューリング

指定された表またはエージング・ポリシーが定義されているすべての表でワンタイム・エージング・プロセスを手動で開始するには、ttAgingScheduleNow組込みプロシージャを使用します。進行中のエージング・プロセスが存在する場合を除いて、組込みプロシージャをコールするとすぐにエージング・プロセスが開始されます。エージング・プロセスが進行中の場合、手動で開始したエージング・プロセスは、進行中のエージング・プロセスが完了したときに開始されます。手動で開始したエージング・プロセスが完了した後、表のエージング状態がONの場合は、その表の次のエージング・サイクルの開始がttAgingScheduleNowがコールされた時点に設定されます。

例4-20 ワンタイム・エージング・プロセスの開始

次の組込みプロシージャ・コールでは、ttAgingScheduleNowがコールされるタイミングに基づいて、oratt.orders表のワンタイム・エージング・プロセスが開始されます。

Command> CALL ttAgingScheduleNow('oratt.orders');

oratt.ordersルート表内でエージングの対象となる行は、oratt.order_item子表内の関連行と同様に削除されます。

ttAgingScheduleNow組込みプロシージャをコールすると、表のエージング状態がONかOFFかにかかわらず、エージング処理が開始されます。特定のキャッシュ・グループでエージング・プロセスを開始する場合は、組込みプロシージャをコールするとき、キャッシュ・グループのルート表の名前を指定します。パラメータを指定しないで組込みプロシージャttAgingScheduleNowがコールされた場合、エージング・プロセスが開始された後、TimesTenデータベース内のエージング・ポリシーが定義されたすべての表で、次のエージング・サイクルの開始がリセットされます。

ttAgingScheduleNow組込みプロシージャをコールしても、表のエージング状態は変わりません。組込みプロシージャをコールしたときに表のエージング状態がOFFの場合、エージング・プロセスは開始されますが、そのプロセスが完了した後にプロセスの実行が再度スケジュールされることはありません。エージング状態がOFFである表のエージングを続行するには、ttAgingScheduleNowを再度コールするか、または表のエージング状態をONに変更する必要があります。

キャッシュ・グループのエージングを手動で制御するには、ALTER TABLE文でSET AGING OFF句を指定して、ルート表のエージングを無効にします。次に、ttAgingScheduleNowをコールして、キャッシュ・グループに対してエージング・プロセスを開始します。

スライド期間の構成

時間ベースのエージングを使用すると、キャッシュ・グループにスライド期間が実装されます。スライド期間構成では、表に特定の時間間隔を満たすデータのみが含まれるように、定期的に新しい行がキャッシュ表に挿入され、古い行がキャッシュ表から削除されます。

キャッシュ・グループにスライド期間を構成するには、増分自動リフレッシュ・モードを使用し、時間ベースのエージング・ポリシーを定義します。自動リフレッシュ処理では、キャッシュされたOracle Database表にある行のタイムスタンプをチェックして、TimesTenキャッシュ表に新しいデータをリフレッシュする必要があるかどうかが決定されます。システム時刻およびタイムゾーンは、Oracle DatabaseとTimesTenの各システムで同じである必要があります。

キャッシュ・グループで増分自動リフレッシュ・モードを使用しない場合、スライド期間を構成するには、LOAD CACHE GROUP文、REFRESH CACHE GROUP文またはINSERT文を使用するか、動的ロード処理を使用して、新しいデータをキャッシュ表に挿入します。

例4-21 スライド期間のプロパティを持つキャッシュ・グループの定義

次の文では、読取り専用キャッシュ・グループrecent_shipped_ordersに対してスライド期間が構成されます。

CREATE READONLY CACHE GROUP recent_shipped_orders
AUTOREFRESH MODE INCREMENTAL INTERVAL 1440 MINUTES STATE ON
FROM oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num))
AGING USE when_shipped LIFETIME 30 DAYS CYCLE 24 HOURS ON;

キャッシュされたOracle Database表oratt.ordersの新しいデータは、1440分ごとにTimesTenキャッシュ表oratt.ordersに自動的にリフレッシュされます。現在のシステム・タイムスタンプとwhen_shipped列のタイムスタンプの差が30日を超えるキャッシュ・インスタンスは、エージングの対象となります。エージング・プロセスによって24時間ごとにチェックが行われ、キャッシュ表からエージ・アウトできるキャッシュ・インスタンスがあるかどうかが確認されます。したがって、このキャッシュ・グループには、過去30日以内に送信された注文が保存されます。

エージングに使用される自動リフレッシュ間隔および存続期間によって、特定の行がキャッシュ表内に保持される期間が決定します。キャッシュ表で存続期間が経過するのを待たずにデータがキャッシュ表からエージ・アウトされる可能性があります。たとえば、読取り専用キャッシュ・グループでは、自動リフレッシュ間隔が3日で存続期間が30日である場合、キャッシュ表にリフレッシュされたときにすでに3日経過しているデータは27日後に削除されますが、これはエージングがキャッシュ表にデータがリフレッシュされたときではなく、TimesTenキャッシュ表にロードされるキャッシュされたOracle Database表の行に保存されたタイムスタンプに基づいているためです。

動的キャッシュ・グループ

動的キャッシュ・グループ内のデータは、リクエストに応じてロードされます。たとえば、コール・センター・アプリケーションでは、顧客の情報が非常に多い場合があるため、すべての顧客の情報をTimesTenに事前ロードしないことがあります。かわりに、動的キャッシュ・グループを使用すると、顧客から問合せがあった場合または顧客がシステムにログオンした場合など、必要な場合にのみ特定の顧客の情報をロードできます。

どのシステム管理キャッシュ・グループ・タイプ(読取り専用、AWT、SWT)も、動的キャッシュ・グループとして定義できます。ユーザー管理キャッシュ・グループは、AUTOREFRESHキャッシュ・グループ属性とPROPAGATEキャッシュ表属性の両方を使用している場合を除いて、動的キャッシュ・グループとして定義できます。

動的キャッシュ・グループを作成するには、CREATE DYNAMIC CACHE GROUP文を使用します。

例4-22 動的読取り専用キャッシュ・グループ

次の文では、oratt.customer表をキャッシュする動的読取り専用キャッシュ・グループonline_customersが作成されます。

CREATE DYNAMIC READONLY CACHE GROUP online_customers
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num));

明示的にロードされるキャッシュ・グループの場合は、まず、LOAD CACHE GROUP文を使用して、キャッシュされたOracle Database表からキャッシュ表にデータがロードされます。動的キャッシュ・グループの場合も、LOAD CACHE GROUP文を使用してデータをキャッシュ表にロードできます。ただし、動的キャッシュ・グループでは、通常、SELECT文、INSERT文またはUPDATE文でキャッシュ表が参照された場合に、表にデータが存在しないためにキャッシュ・ミスになると、データが自動的にロードされます。詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

明示的にロードされるキャッシュ・グループと動的キャッシュ・グループの両方で、LOAD CACHE GROUP文は、キャッシュされたOracle Database表に存在してTimesTenキャッシュ表には存在しない対象データをキャッシュ表にロードします。ただし、キャッシュ表に行が存在する場合に、キャッシュされたOracle Database表にその行より新しいバージョンが存在すると、その行はLOAD CACHE GROUP文の条件を満たしていてもキャッシュ表にロードされません。

これに対して、REFRESH CACHE GROUP文では、キャッシュ表に存在する対象行をリロードし、キャッシュの内容を効率的にリフレッシュします。明示的にロードされるキャッシュ・グループの場合、リフレッシュされる行は、REFRESH CACHE GROUP文の条件を満たすすべての行です。ただし、動的キャッシュ・グループの場合、リフレッシュされる行は、条件を満たし、キャッシュ表にすでに存在する行です。つまり、最終的にリフレッシュされる行は、キャッシュされたOracle Database表で更新または削除された行であり、挿入された行ではありません。したがって、リフレッシュ処理では、キャッシュ表にすでに存在する行のみが処理されます。リフレッシュが行われても、動的キャッシュ・グループのキャッシュ表に新しい行はロードされません。

動的読取り専用キャッシュ・グループのキャッシュ・インスタンス内にあるデータは、Oracle Database表の対応する行内にあるデータと一貫性があります。自動リフレッシュの状態と間隔設定を考慮すると、明示的にロードされるキャッシュ・グループのキャッシュ・インスタンス内にあるデータは、Oracle Database表の対応する行内にあるデータと常に一貫性があります。

LRUエージングがデフォルトで定義されているため、動的キャッシュ・グループ内にあるデータはエージングの対象です。ttAgingLRUConfig組込みプロシージャを使用すると、エージング・サイクルおよびTimesTenデータベースの領域使用状況のしきい値に対するデフォルトまたは現在のLRUエージング属性設定を上書きできます。また、動的キャッシュ・グループに対して時間ベースのエージングを定義して、LRUエージングを上書きすることもできます。動的AWTキャッシュ・グループ内の行は、エージングの対象となる前に、Oracle Databaseに伝播される必要があります。

グローバル・キャッシュ・グループ

Oracle Database表は、同じTimesTenデータベースにある複数のキャッシュ・グループにキャッシュすることはできません。ただし、異なるTimesTenデータベースにある別々のキャッシュ・グループにキャッシュすることは可能です。別々のAWTキャッシュ・グループに表がキャッシュされており、同じキャッシュ・インスタンスが複数のTimesTenデータベースで同時に更新された場合、キャッシュされたOracle Database表にこの更新が伝播される順序は保証されません。また、TimesTenデータベース間で、更新されたキャッシュ表の内容に一貫性がなくなります。

TimesTenのキャッシュ・グリッドを使用すると、Oracle Databaseを使用するユーザーが、TimesTenデータベース全体で読取り/書込みデータの一貫性を保持しながら、複数のシステムにまたがって横方向にグローバル・キャッシュ・グループを拡大できるようになり、この問題が回避されます。キャッシュ・グリッドは、グローバル・キャッシュ・グループでキャッシュされたアプリケーション・データをまとめて管理する一連のTimesTenデータベースです。

グローバル・キャッシュ・グループのキャッシュ表で更新がコミットされたときに、キャッシュ・グリッドでグリッド・メンバー全体のキャッシュ・インスタンスの一貫性を管理するには、異なるTimesTenデータベース内の別々のキャッシュ・グループにキャッシュされる表をグローバル・キャッシュ・グループにキャッシュする必要があります。キャッシュ・グリッドでは、一度に存在できるキャッシュ・インスタンスのコピーは全グリッド内でいつでも1つのみです。グローバル・キャッシュ・グループの各キャッシュ・インスタンスは、現在存在している場所のグリッド・メンバーにより所有されます。キャッシュ・インスタンスを所有しているキャッシュ・グリッド・メンバーのみがデータを更新する権限を持ちます。TimesTenキャッシュ・グリッドは各キャッシュ・インスタンスの所有権を追跡し、各キャッシュ・インスタンスが現在存在している場所のグリッド・メンバーを素早く見つけて、同じキャッシュ・インスタンスが同時に複数のグリッド・メンバーに存在しないようにします。ただし、別のグリッド・メンバーは現在の所有者からキャッシュ・インスタンスの所有権を取得することができます。

グローバル・キャッシュ・グループは、動的AWTキャッシュ・グループまたは明示的にロードされるAWTキャッシュ・グループとして定義できます。

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

- 動的グローバル・キャッシュ・グループ

- 明示的にロードされるグローバル・キャッシュ・グループ

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

- キャッシュ・グリッドへのTimesTenデータベースのアタッチ

動的グローバル・キャッシュ・グループ

次の文は、例4-23で作成される動的AWTグローバル・キャッシュ・グループにキャッシュされるOracle Database表の定義です。Oracle Database表は、スキーマ・ユーザーorattが所有しています。表を作成するには、orattユーザーにCREATE SESSIONおよびRESOURCE権限が付与されている必要があります。

CREATE TABLE subscriber
(subscriberid       NUMBER(10) NOT NULL PRIMARY KEY,
name               VARCHAR2(100) NOT NULL,
minutes_balance    NUMBER(5) NOT NULL,
last_call_duration NUMBER(4) NOT NULL);

キャッシュ・マネージャ・ユーザーが、oratt.subscriber表をキャッシュするAWTキャッシュ・グループを作成できるように、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のOracle Databaseユーザーに、この表に対するSELECT権限が付与されている必要があります。Oracle Databaseに対して非同期ライトスルー処理を行うには、oratt.subscriber表においてキャッシュ管理ユーザーに、INSERT、UPDATEおよびDELETEのOracle Database権限が付与されている必要があります。

動的AWTグローバル・キャッシュ・グループを作成するには、CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP文を使用します。

例4-23 動的グローバル・キャッシュ・グループ

次の文では、oratt.subscriber表をキャッシュする動的AWTグローバル・キャッシュ・グループsubscriber_accountsが作成されます。

CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP subscriber_accounts
FROM oratt.subscriber
(subscriberid       NUMBER(10) NOT NULL PRIMARY KEY,
name               VARCHAR2(100) NOT NULL,
minutes_balance    NUMBER(5) NOT NULL,
last_call_duration NUMBER(4) NOT NULL);

プリペイド電話アカウントのサブスクライバが電話をかけると、そのサブスクライバのアカウント残高を含むキャッシュ・インスタンスが、キャッシュ・グリッド・メンバーのいずれかにあるsubscriber_accountsグローバル・キャッシュ・グループのoratt.subscriberキャッシュ表にロードされます。アカウント残高情報の問合せでは、問合せが発行されたグリッド・メンバーが最初に検索されます。ローカルのグリッド・メンバー上のキャッシュ表に問合せを満たすデータが含まれていない場合、キャッシュ・インスタンスは、グリッド・データ転送操作内の他のグリッド・メンバーからローカルのグリッド・メンバーに転送されます。グリッドに問合せを満たすキャッシュ・インスタンスが含まれていない場合、データはOracle Database表からロードされます。データがOracle Database表からローカルのグリッド・メンバーにロードされると、この処理は動的ロードと呼ばれます。キャッシュ・インスタンスのロード先となるグリッド・メンバーは、そのキャッシュ・インスタンスの所有者となります。所有者が残り時間および最後の通話の長さを更新して、コミットされた更新がキャッシュされたOracle Database表に伝播されるまで、他のグリッド・メンバーはキャッシュ・インスタンスにアクセスできません。

グリッド・メンバー間の一貫性を確保するため、TimesTenデータベースのグローバル・キャッシュ・グループにキャッシュされるOracle Database表は、同じキャッシュ・グリッド内にある別のTimesTenデータベースのローカル・キャッシュ・グループにキャッシュしないでください。また、異なるキャッシュ・グリッド内にある別のTimesTenデータベースのグローバル・キャッシュ・グループに、Oracle Database表をキャッシュしないでください。

動的グローバル・キャッシュ・グループのキャッシュ表の場合、特定のキャッシュ・インスタンスの読取りまたは更新を行うことができるのは、一度に1つのグリッド・メンバーのみです。このグリッド・メンバーをキャッシュ・インスタンスの所有者と呼びます。この所有者に、キャッシュ・インスタンスの行に対する保留中のトランザクションがなくなると、別のグリッド・メンバーがそのインスタンスを読み取るか更新して所有権を得ることができます。所有者は、次の結果によってグリッド・メンバーからこのインスタンスが削除されると、キャッシュ・インスタンスの所有権を放棄します。

- エージング

- キャッシュ表に対して発行されたDELETE文

- キャッシュ・グループに対して発行されたUNLOAD CACHE GROUP文

- そのインスタンスの所有権を得るための別のグリッド・メンバーからのリクエスト

このグリッド・メンバーがキャッシュ・グリッドからデタッチされた場合、所有者はすべてのキャッシュ・インスタンスの所有権を放棄します。

キャッシュ・インスタンスが読み取られるノードでシリアライズ可能な分離レベルを使用する場合のみ、キャッシュ・グリッドのノード間における読取りデータ一貫性が保証されます。デフォルトのコミット読取り分離レベルを使用する場合、キャッシュ・インスタンスを読み取るグリッド・ノードに対する接続では、同じノードまたは異なるノードの別の接続によって、データ値が後で新しい値に更新されていることがあります。

動的グローバル・キャッシュ・グループ内のキャッシュ表は、次のいずれかの処理を使用して移入できます。

- 動的ロード処理

- グリッド・データ転送処理

- キャッシュ表に対するINSERT文(INSERT INTO ... SELECT FROM文を除く)

- LOAD CACHE GROUP ... COMMIT EVERY n ROWS文(他のすべてのグリッド・メンバーが、ロードされるキャッシュ・インスタンスのいずれも所有していない場合にのみ使用可能)

動的ロード処理の詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

グリッド・メンバーは、次のいずれかの処理を使用して、現在別のグリッド・メンバーに所有されているキャッシュ・インスタンスの所有権を得ることができます。

- グリッド・データ転送処理

- 動的ロード処理

- LOAD CACHE GROUP ... WITH ID文

動的グローバル・キャッシュ・グループに対してREFRESH CACHE GROUP文を発行できるのは、WITH ID句が含まれている場合のみです。

CacheGridMsgWait接続属性は、グリッド・メンバーが、所有者がインスタンスを放棄するのを待機する最大秒数に設定できます。いずれかの行に対して保留中のトランザクションがあるキャッシュ・インスタンスの場合、所有者はそのキャッシュ・インスタンスの所有権を放棄できません。デフォルトの最大待機時間は60秒です。

挿入された行の一意のキー値が、キャッシュされたOracle Database表内にすでに存在する場合、動的グローバル・キャッシュ・グループ内のキャッシュ表に対して発行されたINSERT文は失敗します。

LOAD CACHE GROUP ... COMMIT EVERY n ROWS文を使用する場合は、トランザクション内でロードされるキャッシュ・インスタンスのいずれかが別のグリッド・メンバーに所有されていると、エラーが返されます。この場合、トランザクションはロールバックされ、失敗したトランザクション内でキャッシュ・インスタンスはロードされません。

TimesTenキャッシュ表とキャッシュされたOracle Database表で同じ行を同時に更新することによる競合が発生しないようにするには、キャッシュ表のみを更新します。キャッシュされたOracle Database表は直接更新しないでください。

キャッシュ・グリッドのメンバーであるTimesTenデータベースには、ローカルおよびグローバルのキャッシュ・グループを含めることができます。グリッド・メンバー間で一貫性が保証されるのは、グローバル・キャッシュ・グループ内のキャッシュ表のみです。

明示的にロードされるグローバル・キャッシュ・グループ

明示的にロードされるグローバル・キャッシュ・グループ内のキャッシュ・インスタンスは、最初にOracle Databaseからロードされます。キャッシュ・インスタンスをリロードするには、別のLOAD CACHE GROUP文を発行するか、またはREFRESH CACHE GROUP...WITH ID文を使用して単一のキャッシュ・インスタンスをリロードします。

ローカルのグリッド・メンバー上のキャッシュ表に問合せを満たすデータが含まれていない場合、キャッシュ・インスタンスは、グリッド・データ転送操作内の他のグリッド・メンバーからローカルのグリッド・メンバーに転送されます。グリッドに問合せを満たすキャッシュ・インスタンスが含まれていない場合、データはOracle Database表からロードされません。問合せでは結果が返されません。

明示的にロードされるグローバル・キャッシュ・グループを作成するには、CREATE ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP文を使用します。このSQL文は、DYNAMICキーワードが省略されている点を除き、動的グローバル・キャッシュ・グループを作成するSQL文と同じです。

例4-24 明示的にロードされるグローバル・キャッシュ・グループの作成

次の文では、oratt.subscriber表をキャッシュする、明示的にロードされるAWTグローバル・キャッシュ・グループsubscriber_accountsが作成されます。

CREATE ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP subscriber_accounts
FROM oratt.subscriber
(subscriberid       NUMBER(10) NOT NULL PRIMARY KEY,
name               VARCHAR2(100) NOT NULL,
minutes_balance    NUMBER(5) NOT NULL,
last_call_duration NUMBER(4) NOT NULL);

明示的にロードされるグローバル・キャッシュ・グループ内のキャッシュ表は、次のいずれかの処理を使用していつでも移入できます。

- グリッド・データ転送処理

- キャッシュ表に対するINSERT文(INSERT INTO ... SELECT FROM文を除く)

- LOAD CACHE GROUP文。この文は、他のグリッド・メンバーが、ローカルのグリッド・メンバーにロードされるキャッシュ・インスタンスのいずれも所有していない場合にのみ使用できます。

- REFRESH CACHE GROUP ... WITH ID文。

エージングは、明示的にロードされるグローバル・キャッシュ・グループに対してはデフォルトで無効化されます。

CacheGridMsgWait接続属性は、グリッド・メンバーが、所有者がインスタンスを放棄するのを待機する最大秒数に設定します。いずれかの行に対して保留中のトランザクションがあるキャッシュ・インスタンスの場合、所有者はそのキャッシュ・インスタンスの所有権を放棄できません。デフォルトの最大待機時間は60秒です。

キャッシュ表に対して主キーまたは外部キーを指定する問合せが発行され、その表に問合せを満たす行が存在しない場合、キャッシュ・インスタンスはキャッシュ表に転送されません。

子表に行が挿入され、その子表の親表がキャッシュ・グリッドに存在している場合、キャッシュ・インスタンスはその子表を含むメンバーに転送されます。親がキャッシュ・グリッドに存在しない子表への挿入はできません。

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

グローバル・キャッシュ・グループを作成した後、レプリケーション・エージェントがまだ実行されていない場合は、キャッシュ・マネージャ・ユーザーとしてTimesTenデータベースでレプリケーション・エージェントを起動します。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttRepStart;
Command> exit

キャッシュ・グリッドへのTimesTenデータベースのアタッチ

グローバル・キャッシュ・グループのキャッシュ表を更新するには、すべてのスタンドアロンTimesTenデータベースと、グローバル・キャッシュ・グループを含む、アクティブ・スタンバイ・ペアのアクティブ・データベースおよびスタンバイ・データベースが、関連付けられているキャッシュ・グリッドにアタッチされている必要があります。データベースをグリッドにアタッチすると、データベースをグリッド・メンバーにすることができ、その結果、グリッド内のデータベース間で、グローバル・キャッシュ・グループのキャッシュ表内にあるキャッシュ・インスタンスの一貫性を保持できます。

例4-25 キャッシュ・グリッドへのTimesTenデータベースのアタッチ

最初のスタンドアロン・データベースを、関連付けられているttGridキャッシュ・グリッドにアタッチするには、キャッシュ・マネージャ・ユーザーとしてttGridAttach組込みプロシージャをコールします。スタンドアロンのTimesTenデータベースのノード番号は1です。ttGridAttach組込みプロシージャをコールすると、TimesTenデータベースでキャッシュ・エージェントがまだ起動されていない場合に、エージェントが自動的に起動されます。

次の例で、alone1はグリッド・メンバーを一意に識別する名前を、sys1は最初のスタンドアロン・データベースが存在するTimesTenシステムのホスト名を、5001は最初のスタンドアロン・データベースのキャッシュ・エージェント・プロセスのTCP/IPポートを示しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttGridAttach(1,'alone1','sys1',5001);
Command> exit

グリッドにアタッチされる各TimesTenデータベースのキャッシュ・エージェントに、ポートを指定します。デフォルトのポート番号はありません。一般的なグリッドでは、グリッドのメンバー各メンバーに対して同じポートを使用しますが、必要に応じて異なるポートを使用することもできます。ポート割当ては、グリッド・メンバーのプロパティです。グリッド・メンバーのプロパティをグリッドへのアタッチ後に変更する唯一の方法は、グリッドを破棄してから再作成することです。グリッドのメンバーとこれらメンバーのポートを決定するには、ttGridNodeStatus組込みプロシージャを使用します。

キャッシュ・グリッドの詳細は、「キャッシュ・グリッドの構成」を参照してください。

5 キャッシュ・グループの処理

次の各項では、キャッシュ・グループに対して実行できる処理について説明します。

- TimesTenデータベースとOracle Database間での更新の送信

- キャッシュ・グループのロードおよびリフレッシュ

- キャッシュ・インスタンスの動的ロード

- ユーザー管理キャッシュ・グループのフラッシュ

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

- パススルー・レベルの設定

注意:
SQL文またはSQL Developerを使用すると、この章のほとんどの処理を実行できます。SQL Developerの詳細は、『Oracle SQL Developer TimesTen In-Memory Databaseサポート・ユーザーズ・ガイド』を参照してください。

TimesTenデータベースとOracle Database間での更新の送信

TimesTenキャッシュ表とキャッシュされたOracle Database表間でコミットされた更新を手動で送信するには、次のSQL文を使用します。

SQL文

説明

LOAD CACHE GROUP

TimesTenキャッシュ表に存在しないキャッシュ・インスタンスをキャッシュされたOracle Database表からロードします。

REFRESH CACHE GROUP

TimesTenキャッシュ表内のキャッシュ・インスタンスをキャッシュされたOracle Database表からの最新データに置き換えます。

FLUSH CACHE GROUP

TimesTenキャッシュ表にコミットされた更新をキャッシュされたOracle Database表に伝播します。ユーザー管理キャッシュ・グループにのみ適用可能です。

AWTキャッシュ・グループ、SWTキャッシュ・グループおよびPROPAGATEキャッシュ表属性を使用するユーザー管理キャッシュ・グループの場合、TimesTenキャッシュ表にコミットされた更新はキャッシュされたOracle Database表に自動的に伝播されます。

AWTキャッシュ・グループの詳細は、「ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ」を参照してください。

SWTキャッシュ・グループの詳細は、「SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ」を参照してください。

ユーザー管理キャッシュ・グループのキャッシュ表にPROPAGATEキャッシュ表属性を使用する方法の詳細は、「PROPAGATEキャッシュ表属性」を参照してください。

読取り専用キャッシュ・グループまたはユーザー管理キャッシュ・グループにAUTOREFRESHキャッシュ・グループ属性を使用すると、キャッシュされたOracle Database表にコミットされた更新をTimesTenキャッシュ表に自動的にリフレッシュできます。自動リフレッシュは、明示的にロードされるキャッシュ・グループまたは動的キャッシュ・グループに対して定義できます。

キャッシュ・グループの自動リフレッシュの詳細は、「AUTOREFRESHキャッシュ・グループ属性」を参照してください。

明示的にロードされるキャッシュ・グループのキャッシュ表にはデータを手動で事前ロードします。動的キャッシュ・グループの場合、データはリクエストに応じてキャッシュ表にロードされます。特定の文がキャッシュ表でデータを検出できないと、キャッシュされたOracle Database表からキャッシュ・インスタンスが自動的にロードされます。

動的ロード処理の詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

動的キャッシュ・グループは通常、使用されなくなったデータをキャッシュ表から自動的にエージ・アウトするように構成されます。

キャッシュ・グループのロードおよびリフレッシュ

キャッシュされたOracle Database表からTimesTenキャッシュ表にキャッシュ・インスタンスを手動で挿入または更新するには、LOAD CACHE GROUP文またはREFRESH CACHE GROUP文を使用します。キャッシュ・グループのロードとリフレッシュの違いは次のとおりです。

- LOAD CACHE GROUPは、キャッシュされたOracle Database表にコミットされた挿入のみをTimesTenキャッシュ表にロードします。新規キャッシュ・インスタンスはキャッシュ表にロードされますが、キャッシュ表にすでに存在するキャッシュ・インスタンスは、キャッシュされたOracle Database表にある対応する行が更新または削除されても、更新または削除されません。ロード処理は、主に、キャッシュ・グループに最初にデータを移入するために使用します。

- REFRESH CACHE GROUPは、キャッシュ表にすでに存在するキャッシュ・インスタンスを含め、TimesTenキャッシュ表のキャッシュ・インスタンスをキャッシュされたOracle Database表の最新のデータに置き換えます。リフレッシュ処理は、主に、キャッシュ・グループに最初にデータを移入した後、キャッシュされたOracle Database表にコミットされた更新でキャッシュ・グループの内容を更新するために使用します。
明示的にロードされるキャッシュ・グループの場合、リフレッシュ処理はキャッシュ・グループに対してUNLOAD CACHE GROUP文を発行し、続いてLOAD CACHE GROUP文を発行することと同じです。事実上、キャッシュされたOracle Database表にコミットされたすべての挿入、更新および削除がキャッシュ表にリフレッシュされます。新しいキャッシュ・インスタンスがキャッシュ表にロードされる場合があります。キャッシュ表にすでに存在するキャッシュ・インスタンスは、キャッシュされたOracle Database表にある対応する行が更新または削除されると、更新または削除されます。UNLOAD CACHE GROUP文の詳細は、「キャッシュ・グループのアンロード」を参照してください。

動的キャッシュ・グループの場合、キャッシュ表の既存のキャッシュ・インスタンスのみがリフレッシュされるため、リフレッシュ処理はキャッシュされたOracle Database表にコミットされた更新および削除のみをキャッシュ表にリフレッシュします。新規キャッシュ・インスタンスがキャッシュ表にロードされないため、リフレッシュ処理が完了すると、キャッシュ表に含まれるキャッシュ・インスタンスの数は以前と同じか少なくなります。新しいキャッシュ・インスタンスを動的キャッシュ・グループのキャッシュ表にロードするには、LOAD CACHE GROUP文を使用するか、または動的ロード処理を実行します。動的ロード処理の詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

ほとんどのキャッシュ・グループ・タイプで、LOAD CACHE GROUP文またはREFRESH CACHE GROUP文のWHERE句を使用して、キャッシュ表にロードまたはリフレッシュされる行を限定できます。

キャッシュ表定義にWHERE句が使用されていると、LOAD CACHE GROUP文またはREFRESH CACHE GROUP文でWHERE句が使用されていなくても、WHERE句の条件を満たす行のみがキャッシュ表にロードまたはリフレッシュされます。

グローバル・キャッシュ・グループに対してREFRESH CACHE GROUP文を発行できるのは、WITH ID句が含まれている場合のみです。

キャッシュ・グループに時間ベースのエージング・ポリシーが定義されている場合、ルート表の行のタイムスタンプがエージング・ポリシーの存続期間内にあるキャッシュ・インスタンスのみがキャッシュ表にロードまたはリフレッシュされます。

ロード処理またはリフレッシュ処理が単一のトランザクション内で多数のキャッシュ・インスタンスを処理すると同時実行性およびスループットが大幅に低下するため、これを避けるには、COMMIT EVERY n ROWS句を使用して、コミット頻度を指定します(WITH ID句を使用していない場合に限る)。COMMIT EVERY 0 ROWSを指定すると、ロード処理またはリフレッシュ処理は単一のトランザクションで処理されます。

COMMIT EVERY n ROWS句を使用するLOAD CACHE GROUP文またはREFRESH CACHE GROUP文は、独自のトランザクションで実行する必要があり、同じトランザクション内で他の処理を実行しないようにします。

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

次の文では、キャッシュされたOracle Database表からcustomer_ordersキャッシュ・グループのTimesTenキャッシュ表に新しいキャッシュ・インスタンスをロードします。

LOAD CACHE GROUP customer_orders COMMIT EVERY 256 ROWS;

例5-2 WHERE句を使用したキャッシュ・グループのロード

次の文では、キャッシュされたOracle Database表からnew_customersキャッシュ・グループのTimesTenキャッシュ表に、顧客番号が5000以上の顧客の新しいキャッシュ・インスタンスをロードします。

LOAD CACHE GROUP new_customers WHERE (oratt.customer.cust_num >= 5000)
COMMIT EVERY 256 ROWS;

例5-3 キャッシュ・グループのリフレッシュ

次の文では、キャッシュされたOracle Database表からtop_productsキャッシュ・グループ内のTimesTenキャッシュ表にキャッシュ・インスタンスをリフレッシュします。

REFRESH CACHE GROUP top_products COMMIT EVERY 256 ROWS;

例5-4 WHERE句を使用したキャッシュ・グループのリフレッシュ

次の文では、キャッシュされたOracle Database表からupdate_anywhere_customersキャッシュ・グループ内のTimesTenキャッシュ表に、zipコードが60610である顧客のキャッシュ・インスタンスをリフレッシュします。

REFRESH CACHE GROUP update_anywhere_customers
WHERE (oratt.customer.zip = '60610') COMMIT EVERY 256 ROWS;

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

この項の後半では、次の内容について説明します。

- 自動リフレッシュを使用する明示的にロードされるキャッシュ・グループのロードおよびリフレッシュ

- 自動リフレッシュを使用する動的キャッシュ・グループのロードおよびリフレッシュ

- WITH ID句を使用したキャッシュ・グループのロードおよびリフレッシュ

- 即時自動リフレッシュの開始

- 複数表のキャッシュ・グループのロードおよびリフレッシュ

- 数多くのキャッシュ・インスタンスのロードおよびリフレッシュにおけるパフォーマンスの向上

- 明示的にロードされるキャッシュ・グループの手動によるロードおよびリフレッシュの例

- 動的キャッシュ・グループの手動によるロードおよびリフレッシュの例

自動リフレッシュを使用する明示的にロードされるキャッシュ・グループのロードおよびリフレッシュ

明示的にロードされたキャッシュ・グループの自動リフレッシュ状態がPAUSEDの場合、キャッシュ・グループに対して発行されたLOAD CACHE GROUPまたはREFRESH CACHE GROUP文が完了した後に自動リフレッシュ状態はONに変更されます。

自動リフレッシュを使用する明示的にロードされるキャッシュ・グループを手動でロードまたはリフレッシュする場合は、次の制限が適用されます。

- LOAD CACHE GROUP文を発行できるのはキャッシュ表が空の場合のみです。

- LOAD CACHE GROUP文を発行するには、自動リフレッシュ状態がPAUSEDになっている必要があります。

- REFRESH CACHE GROUP文を発行するには、自動リフレッシュ状態がPAUSEDになっている必要があります。

- LOAD CACHE GROUP文にWHERE句を含めることはできません。

- LOAD CACHE GROUP文またはREFRESH CACHE GROUP文にWITH ID句を含めることはできません。

- REFRESH CACHE GROUP文にWHERE句を含めることはできません。

- キャッシュ・グループのロード時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name

明示的にロードされるキャッシュ・グループに対して自動リフレッシュ処理が発生すると、前回の自動リフレッシュ・サイクル以降に、キャッシュされたOracle Database表にコミットされたすべての挿入、更新および削除がキャッシュ表にリフレッシュされます。新しいキャッシュ・インスタンスがキャッシュ表にロードされる場合があります。キャッシュ表にすでに存在するキャッシュ・インスタンスは、キャッシュされたOracle Database表にある対応する行が更新または削除されると、更新または削除されます。

自動リフレッシュを使用する動的キャッシュ・グループのロードおよびリフレッシュ

動的キャッシュ・グループの自動リフレッシュ状態がPAUSEDである場合、次のイベントのいずれかが発生すると、自動リフレッシュ状態はONに変更されます。

- そのキャッシュ表は当初空であり、その後、キャッシュ・グループに対して発行された動的ロード、LOAD CACHE GROUP文または無条件のREFRESH CACHE GROUP文が完了します。

- そのキャッシュ表は空ではなく、その後、キャッシュ・グループに対して発行された無条件のREFRESH CACHE GROUP文が完了します。

動的キャッシュ・グループの自動リフレッシュ状態がPAUSEDである場合、次のイベントのいずれかが発生すると、自動リフレッシュ状態はPAUSEDのままとなります。

- そのキャッシュ表は当初空であり、その後、キャッシュ・グループに対して発行されたREFRESH CACHE GROUP ... WITH ID文が完了します。

- そのキャッシュ表は空ではなく、その後、キャッシュ・グループに対して発行された動的ロード、REFRESH CACHE GROUP ... WITH ID文またはLOAD CACHE GROUP文が完了します。

動的キャッシュ・グループの場合、キャッシュ表の既存のキャッシュ・インスタンスのみがリフレッシュされるため、自動リフレッシュ処理は前回の自動リフレッシュ・サイクル以降にキャッシュされたOracle Database表にコミットされた更新および削除のみをキャッシュ表にリフレッシュします。新しいキャッシュ・インスタンスはキャッシュ表にロードされません。新しいキャッシュ・インスタンスを動的キャッシュ・グループのキャッシュ表にロードするには、LOAD CACHE GROUP文を使用するか、または動的ロード処理を実行します。動的ロード処理の詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

自動リフレッシュを使用する動的キャッシュ・グループを手動でロードまたはリフレッシュする場合は、次の制限が適用されます。

- LOAD CACHE GROUP文を発行するには、自動リフレッシュ状態がPAUSEDまたはONになっている必要があります。

- REFRESH CACHE GROUP文を発行するには、自動リフレッシュ状態がPAUSEDになっている必要があります。

- WHERE句を含むLOAD CACHE GROUP文には、WHERE句の後にCOMMIT EVERY n ROWS句が含まれている必要があります。

- REFRESH CACHE GROUP文にWHERE句を含めることはできません。

- キャッシュ・グループのロード時にWHERE句で参照されるすべての表および列は、完全修飾されている必要があります。例:
user_name.table_nameおよびuser_name.table_name.column_name

WITH ID句を使用したキャッシュ・グループのロードおよびリフレッシュ

LOAD CACHE GROUP文またはREFRESH CACHE GROUP文のWITH ID句を使用すると、WHERE句を使用しなくても、主キー列の値に基づいてキャッシュ・グループをロードまたはリフレッシュできます。主キーに複数の列が含まれている場合は、WITH ID句の方が同等のWHERE句よりも便利です。WITH ID句を使用すると、キャッシュ・インスタンスを一度に1つずつロードできます。また、必要に応じて、ロード処理またはリフレッシュ処理を含むトランザクションをロールバックできますが、WHERE句を使用する同等の文では、WHERE句を使用するにはCOMMIT EVERY n ROWS句も指定する必要があるため、このようなロールバックができません。

例5-5 WITH ID句を使用したキャッシュ・グループのロード

キャッシュ・グループrecent_ordersには、(orderid, itemid)を主キーとするキャッシュ表oratt.orderdetailsが1つ含まれています。顧客が特定の注文の品目に関して問い合せる場合、指定された注文番号および品目番号のキャッシュ・インスタンスをロードすることでその情報を取得できます。

キャッシュされたOracle Database表oratt.orderdetailsのorderid列の値が1756で、itemid列の値が573である行を含む、recent_ordersキャッシュ・グループのoratt.orderdetailsキャッシュ表をロードします。

LOAD CACHE GROUP recent_orders WITH ID (1756,573);

WHERE句を使用する同等のLOAD CACHE GROUP文は、次のとおりです。

LOAD CACHE GROUP recent_orders WHERE orderid = 1756 and itemid = 573
COMMIT EVERY 256 ROWS;

キャッシュ・グループが動的でないかぎり、自動リフレッシュ・キャッシュ・グループに対して発行されるLOAD CACHE GROUP文またはREFRESH CACHE GROUP文にWITH ID句を含めることはできません。

WITH ID句とCOMMIT EVERY n ROWS句を併用することはできません。

即時自動リフレッシュの開始

次の自動リフレッシュ処理を待機することなく、キャッシュ表に適用する必要のあるデータを使用してOracle Database表が更新されている場合は、ttCacheAutorefresh組込みプロシージャをコールできます。ttCacheAutorefresh組込みプロシージャにより、即時リフレッシュ処理が開始され、ttCacheAutorefreshの起動時に開始されるように自動リフレッシュ・サイクルがリセットされます。キャッシュ・グループの構成方法に基づいて、完全リフレッシュ処理または増分リフレッシュ処理が行われます。ttCacheAutorefreshをコールする場合は、自動リフレッシュの状態がONである必要があります。

通常、自動リフレッシュ処理では、同じリフレッシュ間隔を共有するすべてのキャッシュ・グループのリフレッシュを、これらのキャッシュ・グループ間のトランザクション一貫性を維持するために、1つのトランザクションで行います。したがって、ttCacheAutorefreshをコールするときに特定のキャッシュ・グループを指定しても、自動リフレッシュ処理は、指定したキャッシュ・グループと自動リフレッシュ間隔を共有するすべてのキャッシュ・グループに対して1つのトランザクションで発生します。既存のトランザクションに表ロックされているオブジェクトがあり、それらのオブジェクトが対象となるキャッシュ・グループに属している場合、ttCacheAutofreshは何もアクションを行わずにエラーを返します。

ttCacheAutorefreshの実行は、非同期(デフォルト)または同期を選択できます。同期モードでは、リフレッシュ処理が失敗すると、ttCacheAutorefreshはエラーを返します。

ttCacheAutorefreshのコール後は、トランザクションをコミットまたはロールバックしてから、後続の作業を実行する必要があります。

例5-6 ttCacheAutorefreshのコール

この例では、ttuser.western_customersキャッシュ・グループに対して非同期モードを使用してttCacheAutorefreshをコールします。

Command> call ttCacheAutorefresh('ttuser', 'western_customers');

複数表のキャッシュ・グループのロードおよびリフレッシュ

キャッシュされたOracle Database表が同時に更新されている間に、複数表のキャッシュ・グループをロードまたはリフレッシュする場合は、LOAD CACHE GROUP文またはREFRESH CACHE GROUP文を発行する前に、TimesTenデータベースの分離レベルをシリアライズ可能に設定します。これにより、TimesTenはロード処理またはリフレッシュ処理中、キャッシュされたOracle Database表にシリアライズ可能な方法で問い合せるため、キャッシュ表にロードまたはリフレッシュされたキャッシュ・インスタンスはキャッシュされたOracle Database表の対応する行とトランザクション一貫性が確保されます。キャッシュ・グループをロードまたはリフレッシュした後、TimesTenデータベースの要素にアクセスする際の同時実行性を高めるため、分離レベルをコミット読取りに設定しなおします。

数多くのキャッシュ・インスタンスのロードおよびリフレッシュにおけるパフォーマンスの向上

LOAD CACHE GROUP文またはREFRESH CACHE GROUP文でPARALLEL句を使用すると、多数のキャッシュ・インスタンスをキャッシュ・グループにロードまたはリフレッシュするときのパフォーマンスを向上できます。ロード処理またはリフレッシュ処理を行う場合に使用するスレッド数を指定します。1から10のスレッドを指定できます。1つのスレッドがキャッシュされたOracle Database表から行をフェッチし、他のスレッドがTimesTenキャッシュ表に行を挿入します。システムで使用可能なCPU数を超えるスレッドを指定すると、PARALLEL句を使用しなかった場合よりもパフォーマンスが低下することがありますので、このような指定を行わないでください。

注意:
WITH ID句をPARALLEL句と併用することはできません。COMMIT EVERY n ROWS句は、nが0より大きな値であるかぎり、PARALLEL句と併用できます。また、データベース・レベルのロックが有効になっている場合や読取り専用動的キャッシュ・グループに対してはPARALLEL句を使用できません。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の「REFRESH CACHE GROUP」を参照してください。

例5-7 PARALLEL句を使用したキャッシュ・グループのリフレッシュ

次の文では、キャッシュされたOracle Database表からwestern_customersキャッシュ・グループ内のTimesTenキャッシュ表にキャッシュ・インスタンスをリフレッシュします。このことを行うために、1つのスレッドを使用してキャッシュされたOracle Database表から行をフェッチし、3つのスレッドを使用してその行をキャッシュ表に挿入しています。

REFRESH CACHE GROUP western_customers COMMIT EVERY 256 ROWS PARALLEL 4;

明示的にロードされるキャッシュ・グループの手動によるロードおよびリフレッシュの例

明示的にロードされるAWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。

CREATE TABLE customer
(cust_num NUMBER(6) NOT NULL PRIMARY KEY,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100));

次に、キャッシュされたOracle Database表oratt.customerのデータを示します。

CUST_NUM   REGION    NAME              ADDRESS
--------   -------   ---------------   ---------------------------
1   West      Frank Edwards     100 Pine St. Portland OR
2   East      Angela Wilkins    356 Olive St. Boston MA
3   Midwest   Stephen Johnson   7638 Walker Dr. Chicago IL

次の文では、oratt.customer表をキャッシュする、明示的にロードされるAWTキャッシュ・グループnew_customersが作成されます。

CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num));

TimesTenキャッシュ表oratt.customerは、最初は空になっています。

Command> SELECT * FROM oratt.customer;
0 rows found.

次のLOAD CACHE GROUP文では、キャッシュされたOracle Database表からTimesTenキャッシュ表に3つのキャッシュ・インスタンスがロードされます。

Command> LOAD CACHE GROUP new_customers COMMIT EVERY 256 ROWS;
3 cache instances affected.
Command> SELECT * FROM oratt.customer;
< 1, West, Frank Edwards, 100 Pine St. Portland OR >
< 2, East, Angela Wilkins, 356 Olive St. Boston MA >
< 3, Midwest, Stephen Johnson, 7638 Walker Dr. Chicago IL >

新しい行の挿入、既存の行の更新および既存の行の削除によって、キャッシュされたOracle Database表を更新します。

SQL> INSERT INTO customer
2  VALUES (4, 'East', 'Roberta Simon', '3667 Park Ave. New York NY');
SQL> UPDATE customer SET name = 'Angela Peterson' WHERE cust_num = 2;
SQL> DELETE FROM customer WHERE cust_num = 3;
SQL> COMMIT;
SQL> SELECT * FROM customer;
CUST_NUM   REGION    NAME              ADDRESS
--------   -------   ---------------   ---------------------------
1   West      Frank Edwards     100 Pine St. Portland OR
2   East      Angela Peterson   356 Olive St. Boston MA
4   East      Roberta Simon     3667 Park Ave. New York NY

明示的にロードされるキャッシュ・グループに対して発行されたREFRESH CACHE GROUP文は、キャッシュ・グループをアンロードしてからリロードすることによって処理されます。この結果、キャッシュ表のキャッシュ・インスタンスはキャッシュされたOracle Database表の行に一致します。

Command> REFRESH CACHE GROUP new_customers COMMIT EVERY 256 ROWS;
3 cache instance affected.
Command> SELECT * FROM oratt.customer;
< 1, West, Frank Edwards, 100 Pine St. Portland OR >
< 2, East, Angela Peterson, 356 Olive St. Boston MA >
< 4, East, Roberta Simon, 3667 Park Ave. New York NY >

動的キャッシュ・グループの手動によるロードおよびリフレッシュの例

動的AWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。

CREATE TABLE customer
(cust_num NUMBER(6) NOT NULL PRIMARY KEY,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100));

次に、キャッシュされたOracle Database表oratt.customerのデータを示します。

CUST_NUM   REGION    NAME              ADDRESS
--------   -------   ---------------   ---------------------------
1   West      Frank Edwards     100 Pine St. Portland OR
2   East      Angela Wilkins    356 Olive St. Boston MA
3   Midwest   Stephen Johnson   7638 Walker Dr. Chicago IL

次の文では、oratt.customer表をキャッシュする動的AWTキャッシュ・グループnew_customersが作成されます。

CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num));

TimesTenキャッシュ表oratt.customerは、最初は空になっています。

Command> SELECT * FROM oratt.customer;
0 rows found.

次のLOAD CACHE GROUP文では、キャッシュされたOracle Database表からTimesTenキャッシュ表に3つのキャッシュ・インスタンスがロードされます。

Command> LOAD CACHE GROUP new_customers COMMIT EVERY 256 ROWS;
3 cache instances affected.
Command> SELECT * FROM oratt.customer;
< 1, West, Frank Edwards, 100 Pine St. Portland OR >
< 2, East, Angela Wilkins, 356 Olive St. Boston MA >
< 3, Midwest, Stephen Johnson, 7638 Walker Dr. Chicago IL >

新しい行の挿入、既存の行の更新および既存の行の削除によって、キャッシュされたOracle Database表を更新します。

SQL> INSERT INTO customer
2  VALUES (4, 'East', 'Roberta Simon', '3667 Park Ave. New York NY');
SQL> UPDATE customer SET name = 'Angela Peterson' WHERE cust_num = 2;
SQL> DELETE FROM customer WHERE cust_num = 3;
SQL> COMMIT;
SQL> SELECT * FROM customer;
CUST_NUM   REGION    NAME              ADDRESS
--------   -------   ---------------   ---------------------------
1   West      Frank Edwards     100 Pine St. Portland OR
2   East      Angela Peterson   356 Olive St. Boston MA
4   East      Roberta Simon     3667 Park Ave. New York NY

動的キャッシュ・グループに対して発行されたREFRESH CACHE GROUP文では、キャッシュされたOracle Database表にコミットされた更新および削除のみをキャッシュ表にリフレッシュします。新しいキャッシュ・インスタンスはキャッシュ表にロードされません。このため、既存のキャッシュ・インスタンスのみがリフレッシュされます。その結果、キャッシュ表のキャッシュ・インスタンスの数は、キャッシュされたOracle Database表の行数より少ないか同じになります。

Command> REFRESH CACHE GROUP new_customers COMMIT EVERY 256 ROWS;
2 cache instances affected.
Command> SELECT * FROM oratt.customer;
< 1, West, Frank Edwards, 100 Pine St. Portland OR >
< 2, East, Angela Peterson, 356 Olive St. Boston MA >

キャッシュ表にはコミットされた挿入のみがロードされるため、後続のLOAD CACHE GROUP文では、キャッシュされたOracle Database表からTimesTenキャッシュ表に1つのキャッシュ・インスタンスがロードされます。このため、新規キャッシュ・インスタンスのみがロードされます。LOAD CACHE GROUP文によって、すでにキャッシュ表に存在するキャッシュ・インスタンスは変更されません(これは、キャッシュされたOracle Database表の対応する行が更新または削除された場合でも同じです)。

Command> LOAD CACHE GROUP new_customers COMMIT EVERY 256 ROWS;
1 cache instance affected.
Command> SELECT * FROM oratt.customer;
< 1, West, Frank Edwards, 100 Pine St. Portland OR >
< 2, East, Angela Peterson, 356 Olive St. Boston MA >
< 4, East, Roberta Simon, 3667 Park Ave. New York NY >

キャッシュ・インスタンスの動的ロード

動的キャッシュ・グループでは、対象となるSELECT文、INSERT文、UPDATE文またはDELETE文がTimesTenキャッシュ表のいずれかに対して発行され、目的のデータがそのキャッシュ表には存在しないもののキャッシュされたOracle Database表には存在すると、そのデータはキャッシュされたOracle Database表からTimesTenキャッシュ表に自動的にロードされます。

注意:
ただし、Oracle Databaseが停止している場合は、次のエラーが返されます。

5219: Temporary Oracle connection failure error in OCISessionBegin():
ORA-01034: ORACLE not available

注意:
動的キャッシュ・グループに対する動的ロードは、DynamicLoadEnable接続属性が有効になっている場合にのみ実行できます。詳細は「動的ロード構成」を参照してください。

動的ロードは単一のキャッシュ・インスタンスを取得します。このインスタンスはOracle DatabaseからTimesTenデータベースへ自動的にロードされるか、または動的グローバル・キャッシュ・グループの場合はインスタンスを所有するグリッド・メンバーから要求元のグリッド・メンバーに転送されます。キャッシュ・インスタンスは任意のキャッシュ・グループのルート表の行(主キーまたは一意索引によりルート表で一意に識別されます)および外部キー関係で関連付けられた子表のすべての関連行で構成されます。

キャッシュされたOracle Database表の行が文のWHERE句の条件を満たす場合は、親表および子表の主キーと外部キー間に定義されたリレーションシップを維持するために、関連するキャッシュ・インスタンス全体がロードされます。動的ロード処理では、どのキャッシュ・グループのルート表にも複数の行をロードできません。キャッシュ表定義のWHERE句の条件を満たす行が含まれているキャッシュ・インスタンスのみがロードされます。

WHERE句は、動的ロードを発生させるために次のいずれかを指定する必要があります。

- キャッシュ・グループのいずれかの表に関する主キーまたは外部キーのすべての列に対して定数またはパラメータ、あるいはその両方を持つ等価条件。複数のキャッシュ・グループの表を参照する場合、各表は主キーおよび外部キーの関係について等価条件で接続される必要があります。

- 一意索引のすべての列に対する等価条件またはIS NULL条件の組合せ(最低1つの等価条件を使用する場合)。つまり、一意索引の一部の列がNULLである動的ロードを実行できます。一意索引は、キャッシュ・グループのルート表で作成する必要があります。

注意:
ルート表の主キー検索に基づいた動的ロードの方が、子表に対する主キー検索または子表に対する外部キー検索よりも、パフォーマンスが速くなります。

動的ロードは、動的ロードをトリガーするユーザー・トランザクションとは別のトランザクションで実行されます。動的ロード・トランザクションは、動的ロードをトリガーするSQL文が実行を終了する前にコミットされます。したがって、ユーザー・トランザクションがロールバックされる場合、動的にロードされたデータはキャッシュ・グループに残ったままになります。

グローバル・キャッシュ・グループの場合、これらのキャッシュ・グループで動的ロードが可能になるには、TimesTenデータベースがキャッシュ・グリッドへアタッチされている必要があります。グローバル・キャッシュ・グループの詳細およびTimesTenデータベースのキャッシュ・グリッドへのアタッチの詳細は、「グローバル・キャッシュ・グループ」を参照してください。

次の各項ではキャッシュ・グループの動的ロードについて説明します。

- 動的ロード構成

- 動的ロードのガイドライン

- キャッシュ・インスタンスの動的ロードの例

- 動的ロード・エラーが返る

動的ロード構成

動的ロードは、次のようにして、DynamicLoadEnable接続属性で構成できます。

- 0: 現在の接続について、TimesTenの動的キャッシュ・グループへのOracle Databaseデータの動的ロードを無効にします。

- 1 (デフォルト): 現在の接続について、TimesTenの動的キャッシュ・グループへのOracle Databaseデータの動的ロードを1文ごとに有効にします。文は1つの動的キャッシュ・グループの表のみを参照する必要があり、その表は主問合せのみで参照される必要があります。文はキャッシュ表以外の表を参照することもできます。ロードできるキャッシュ・インスタンスは1つだけです。

- 2: 現在の接続について、1文に対して1つ以上のTimesTen動的キャッシュ・グループへのOracle Databaseデータの動的ロードを有効にします。参照される表は複数のキャッシュ・グループ内に存在することが可能です。主問合せで参照されるすべてのキャッシュ・グループは動的にロードされます。副問合せのみで参照されるいずれのキャッシュ・グループも動的ロードについては無視されます。文はキャッシュ表以外の表を参照することもできます。ロードできるキャッシュ・インスタンスは1つだけです。

DynamicLoadEnable接続属性に適切な値を設定して、特定の接続内でアクセスされる動的キャッシュ・グループ内のすべてのキャッシュ表の動的ロードのタイプを構成します。

特定のトランザクションについて動的ロードを有効化または無効化するには、DynamicLoadEnableオプティマイザ・ヒントを設定できます。ただし、DynamicLoadEnable接続属性はどのタイプの動的ロードを有効にするかを構成する唯一の方法です。

次のいずれかの方法によりDynamicLoadEnableオプティマイザ・ヒントを設定します。

- ttIsqlユーティリティのset dynamicloadenableコマンドを使用します。

- DynamicLoadEnableフラグを希望の値に設定し、ttOptSetFlag組込みプロシージャをコールします。次の例では動的ロードを1に設定しています。

call ttOptSetFlag('DynamicLoadEnable', 1)

注意:
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のDynamicLoadEnableに関する説明"、ttIsqlに関する説明またはttOptSetFlagに関する説明を参照してください。
属性は、SQLSetConnectOption ODBC関数を使用して設定することもできます。詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』の「SQLSetConnectOptionおよびSQLGetConnectOptionのオプションのサポート」を参照してください。

動的ロードのガイドライン

動的ロードは主問合せで参照される各キャッシュ・グループについて、最大1つのキャッシュ・インスタンスを取得します。この項では動的ロードが発生する状態のガイドラインの詳細を説明します。

注意:
これらのガイドラインの例は「キャッシュ・インスタンスの動的ロードの例」で説明されています。

動的ロードは、動的キャッシュ・グループのキャッシュ表に対して発行された次のタイプの文にのみ使用できます。

- INSERT文が、現在TimesTenの表には存在していないキャッシュ・インスタンスのいずれかの子表に値を挿入する場合、新しい行が所属するキャッシュ・インスタンスは動的にロードされます。新しい子の行に対するこの挿入処理は、キャッシュされたOracle Database表に伝播されます。

- SELECT文、UPDATE文またはDELETE文では、WHERE句に「キャッシュ・インスタンスの動的ロード」で説明されている条件が存在する必要があります。

動的ロードを使用できるSELECT文、UPDATE文またはDELETE文では、次の条件が満たされている必要があります。

- 文に副問合せが含まれていた場合、主問合せで参照される表を持つキャッシュ・グループのみが動的ロードの対象とみなされます。

- 文がキャッシュ・グループの複数の表を参照する場合、その文にはすべての親子関係の主キーと外部キーの間の等結合条件が含まれている必要があります。

- 文には、UNION、INTERSECTまたはMINUS集合演算子を含めることはできません。

- 文はキャッシュ表以外の表を参照することができます。

- デフォルトで、文が参照できるキャッシュ表は1つの動的キャッシュ・グループに限られます。この動作はDynamicLoadEnableが1に設定されている場合に有効になります。ただし、DynamicLoadEnableが2に設定されている場合、文は複数の動的キャッシュ・グループのキャッシュ表を参照できます。詳細は「動的ロード構成」を参照してください。

動的ロードの動作はDynamicLoadEnableの設定により異なります。次に、動的ロードが発生するかどうかを判別するために評価されるルールを説明します。これらのルールはDynamicLoadEnableが1または2に設定されている場合に守られます。

- キャッシュ・グループに対する動的ロードは、キャッシュ・グループの任意の表がいずれかのFROM句で複数回指定されている場合には発生しません。

- 問合せで明示的に指定された条件のみが動的ロードの対象とみなされ、これにはいずれの派生条件も含まれません。

- 任意のキャッシュ・グループが副問合せでのみ参照される場合、動的ロードの対象とはみなされません。

- キャッシュ・グループに時間ベースのエージング・ポリシーが定義されている場合、キャッシュ・インスタンスをロードするには、ルート表の行のタイムスタンプがエージング・ポリシーの存続期間内にある必要があります。キャッシュ・グループにエージング・ポリシーを定義する方法の詳細は、「キャッシュ・グループでのエージングの実装」を参照してください。

- アクティブ・スタンバイ・ペア・レプリケーション・スキームを使用するときには、動的ロードはどのサブスクライバでも発生することができません。

DynamicLoadEnableが2に設定されて動的ロードが有効になっている場合、文に複数の動的キャッシュ・グループを含めることができます。動的ロードが発生するかどうかを決定するこの条件のルールは次のとおりです。

- ある問合せ内に複数のキャッシュ・グループが存在している場合、動的ロードの必要条件を満たすキャッシュ・グループが動的ロードの対象とみなされます。動的ロード条件を満たしていないキャッシュ・グループは動的ロードの対象とはみなされません。

- いずれかの動的キャッシュ・グループの表が主問合せで参照される場合、それらの表は、副問合せで任意のキャッシュ・グループの他の表が参照されても動的ロードの対象とみなされます。

次の考慮事項は動的ロードに影響を与える可能性があります。

- 複数のキャッシュ・グループ内の表またはキャッシュ・グループ以外の表が主問合せで指定された場合は、キャッシュ・インスタンスがロードされるかどうかは結合順序により影響を受けます。問合せの実行中に動的ロードが可能で問合せの結果を出すことが必要な場合、動的ロードが発生します。ただし、返される行がない場合、一部またはすべてのキャッシュ・インスタンスが動的にロードされません。

- 文がキャッシュ・グループの表に対して複数の動的ロード条件を指定した場合、追加条件がその文に適格ではない場合もキャッシュ・インスタンスが動的にロードされる場合があります。

キャッシュ・インスタンスの動的ロードの例

動的AWTキャッシュ・グループにキャッシュされるOracle Database表の定義は、次のとおりです。Oracle Database表は、スキーマ・ユーザーorattが所有しています。

CREATE TABLE customer
(cust_num NUMBER(6) NOT NULL PRIMARY KEY,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100));

CREATE TABLE orders
(ord_num      NUMBER(10) NOT NULL PRIMARY KEY,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL);

CREATE TABLE orderdetails
(orderid  NUMBER(10) NOT NULL,
itemid   NUMBER(8) NOT NULL,
quantity NUMBER(4) NOT NULL,
PRIMARY KEY (orderid, itemid));

たとえば、次に、キャッシュされたOracle Database表oratt.customerのデータを示します。

CUST_NUM   REGION    NAME              ADDRESS
--------   -------   ---------------   ---------------------------
1   West      Frank Edwards     100 Pine St., Portland OR
2   East      Angela Wilkins    356 Olive St., Boston MA
3   Midwest   Stephen Johnson   7638 Walker Dr., Chicago IL

次の文では、oratt.customer、oratt.orders、およびoratt.orderdetails表をキャッシュする動的AWTキャッシュ・グループnew_customersが作成されます。

CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP new_customers
FROM oratt.customer
(cust_num NUMBER(6) NOT NULL,
region   VARCHAR2(10),
name     VARCHAR2(50),
address  VARCHAR2(100),
PRIMARY KEY(cust_num)),
oratt.orders
(ord_num      NUMBER(10) NOT NULL,
cust_num     NUMBER(6) NOT NULL,
when_placed  DATE NOT NULL,
when_shipped DATE NOT NULL,
PRIMARY KEY(ord_num),
FOREIGN KEY(cust_num) REFERENCES oratt.customer(cust_num)),
oratt.orderdetails
(orderid  NUMBER(10) NOT NULL,
itemid   NUMBER(8) NOT NULL,
quantity NUMBER(4) NOT NULL,
PRIMARY KEY(orderid, itemid),
FOREIGN KEY(orderid) REFERENCES oratt.orders(order_num));

DynamicLoadEnableが1に設定されている場合は、次の例を使用できます。

TimesTenキャッシュ表oratt.customerは、最初は空になっています。

Command> SELECT * FROM oratt.customer;
0 rows found.

oratt.customer表の主キーに対して等価条件を持つ、次のSELECT文では動的ロードが発生します。

Command> SELECT * FROM oratt.customer WHERE cust_num = 1;
< 1, West, Frank Edwards, 100 Pine St., Portland OR >

ただし、主キーに対して等価条件を使用しない場合、動的ロードは発生しません。

Command> SELECT * FROM oratt.customer WHERE cust_num IN (1,2);

次の例では、複合主キーのすべての主キー列に等価式が含まれています。orderdetails表にはorderidとitemidの複合主キーがあります。

UPDATE oratt.orderdetails SET quantity = 5 WHERE orderid=2280 AND itemid=663;

次の例はorders子表へのINSERTを示しており、これにより動的ロードが開始されます。ただし、親表であるcustomerへの挿入を試行した場合、動的ロードは発生しません。

INSERT INTO orders VALUES(1,1, DATE '2012-01-25', DATE '2012-01-30');

次のUPDATE文では、キャッシュされたOracle Database表からTimesTenキャッシュ表に1つのキャッシュ・インスタンスを動的にロードし、キャッシュ表のインスタンスを更新して、その更新をキャッシュされたOracle Database表に自動的に伝播します。

Command> UPDATE oratt.customer SET name = 'Angela Peterson' WHERE cust_num = 2;
Command> SELECT * FROM oratt.customer;
< 1, West, Frank Edwards, 100 Pine St., Portland OR >
< 2, East, Angela Peterson, 356 Olive St., Boston MA >

キャッシュされたOracle Database表oratt.customerの更新データは、次のとおりです。

CUST_NUM   REGION    NAME              ADDRESS
--------   -------   ---------------   ---------------------------
1   West      Frank Edwards     100 Pine St., Portland OR
2   East      Angela Peterson   356 Olive St., Boston MA
3   Midwest   Stephen Johnson   7638 Walker Dr., Chicago IL

次のDELETE文では、キャッシュされたOracle Database表からTimesTenキャッシュ表に1つのキャッシュ・インスタンスを動的にロードし、キャッシュ表のインスタンスを削除し、その削除をキャッシュされたOracle Database表に自動的に伝播します。

Command> DELETE FROM oratt.customer WHERE cust_num = 3;
Command> SELECT * FROM oratt.customer;
< 1, West, Frank Edwards, 100 Pine St., Portland OR >
< 2, East, Angela Peterson, 356 Olive St., Boston MA >

キャッシュされたOracle Database表oratt.customerの更新データは、次のとおりです。

CUST_NUM   REGION    NAME              ADDRESS
--------   -------   ---------------   ---------------------------
1   West      Frank Edwards     100 Pine St., Portland OR
2   East      Angela Peterson   356 Olive St., Boston MA

次に、ルート表で一意索引のすべての列を使用して実行される動的ロードの例を示します。departments表は、動的AWTキャッシュ・グループで定義されます。manager_idおよびlocation_idで構成されるこのキャッシュ・グループで一意索引が作成されます。

次のようにして、Oracle Databaseでdepartments表を作成します。

Command> CREATE TABLE departments(
> department_id INT NOT NULL PRIMARY KEY,
> department_name VARCHAR(10) NOT NULL,
> technical_lead INT NOT NULL,
> manager_id INT,
> location_id INT NOT NULL);

次のようにして、dept_cgルート表で動的AWTキャッシュ・グループおよび一意索引を作成します。

Command> CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH CACHE GROUP dept_cg
> FROM departments
> (department_id INT NOT NULL PRIMARY KEY,
>  department_name VARCHAR(10) NOT NULL,
>  technical_lead INT NOT NULL,
>  manager_id INT, location_id INT NOT NULL);

Command> CREATE UNIQUE INDEX dept_idx ON departments(manager_id, location_id);

次のようにして、Oracle Databaseでdepartments表に3つのレコードを挿入します。

Command> insert into departments values (1, 'acct', 1, 1, 100);
1 row inserted.
Command> insert into departments values (2, 'legal', 2, 2, 200);
1 row inserted.
Command> insert into departments values (3, 'owner', 3, NULL, 300);
1 row inserted.
Command> commit;

TimesTenで、一意索引に基づいてキャッシュ・インスタンスを動的にロードします。

Command> SELECT * FROM departments;
0 rows found.
Command> SELECT * FROM departments WHERE manager_id IS NULL AND location_id=300;
< 3, owner, 3, <NULL>, 300 >
1 row found.
Command> SELECT * FROM departments;
< 3, owner, 3, <NULL>, 300 >
1 row found.
Command> SELECT * FROM departments WHERE manager_id=2 AND location_id=200;
< 2, legal, 2, 2, 200 >
1 row found.
Command> SELECT * FROM departments;
< 2, legal, 2, 2, 200 >
< 3, owner, 3, <NULL>, 300 >
2 rows found.

以降の例は、複数のキャッシュ・グループにわたって表を参照する場合の動的ロードの使用方法を示しています(動的ロードはDynamicLoadEnableが2に設定されている場合に有効になります)。

次の文では、それぞれのグループがOracle Databaseからキャッシュされる1つ以上の表を持つ、複数の動的AWTキャッシュ・グループが作成されます。

CREATE DYNAMIC CACHE GROUP cachegrp
FROM table1(x1 INT PRIMARY KEY, y1 INT);

CREATE DYNAMIC CACHE GROUP cachegrp2
FROM table2(x2 INT PRIMARY KEY, y2 INT),
table3(x3 INT PRIMARY KEY, y3 INT,
FOREIGN KEY(y3) REFERENCES table2(x2);

CREATE DYNAMIC CACHE GROUP cachegrp3
FROM table4(x4 INT PRIMARY KEY, y4 INT);

CREATE TABLE table5
(x5 INT PRIMAY KEY,y5 INT);

次の例は、オプティマイザがx1が1と等しくなる必要がある結果を導出する可能性がある場合でも、動的ロードが発生しないことを示しています。

SELECT * FROM table1, table5 WHERE x5=1 AND x5=x1;

cachegrp2内のtable2のキャッシュ・インスタンスに対しては、table2が主問合せで参照されるため、動的ロードが検討されます。

SELECT * FROM table5, table2
WHERE x5 IN (SELECT y2 FROM table2, table3 where x2=1 and x2=y3);

cachegrp2キャッシュ・グループのキャッシュ・インスタンスは、そのすべての表が副問合せで参照されるため、動的ロードの対象とみなされません。

SELECT * FROM table5
WHERE x5 IN
(SELECT y3 FROM table2, table3 WHERE x2=1 AND x2=y3);

次の例で、x1=1のtable1から取得される行がまだキャッシュされていなかった場合、table1のキャッシュ・インスタンスがロードされるかどうかは結合順序に依存します。結合順序が「table5 table1」である場合、table1のキャッシュ・インスタンスはx5=1であるtable5に行が存在する場合、そしてその場合にのみロードされます。結合順序が「table1 table5」であれば、table1のキャッシュ・インスタンスは常にロードされます。

SELECT * FROM table1, table5 WHERE x1=1 AND x5=1;

行(1,1)はtable1に対してロードされる場合がありますが、SELECTはどの行も返しません。

SELECT * FROM table1 WHERE x1=1 AND y1>1;

動的ロード・エラーを返します。

SELECT文、UPDATE文またはDELETE文で「動的ロードのガイドライン」に示した要件が満たされていない場合はエラーを返すようにTimesTenを構成できます。DynamicLoadErrorMode接続属性は、アプリケーションが動的キャッシュ・グループに対してSQL処理を実行する場合、およびSQL処理で動的ロードが使用できない場合の動作を制御します。

- DynamicLoadErrorModeが値0に設定されている場合、問合せで参照される、動的ロードに適格なすべてのキャッシュ・グループに動的ロードが発生します。適格ではないキャッシュ・グループは動的にロードされず、エラーは返されません。DynamicLoadEnable=1のとき、問合せが複数のキャッシュ・グループを参照する場合は動的ロードが発生しません。

- DynamicLoadErrorModeが値1に設定されているとき、問合せで参照されるどの動的キャッシュ・グループも動的ロードに適格ではない場合、その問合せは失敗します。このエラーは、動的ロードが発生できない理由を示します。

この接続属性を特定のトランザクションにのみ設定するには、次のいずれかを使用します。

- ttIsqlユーティリティのset dynamicloaderrormode 1コマンドを使用します。

- DynamicLoadErrorModeフラグを設定し、オプティマイザ値を1に設定したttOptSetFlag組込みプロシージャをコールします。

call ttOptSetFlag('DynamicLoadErrorMode', 1)

文が動的ロード要件に準拠していなくてもエラーを報告しないようにするには、DynamicLoadErrorModeフラグを設定し、オプティマイザ値を0に設定したttOptSetFlag組込みプロシージャをコールします。

ユーザー管理キャッシュ・グループのフラッシュ

FLUSH CACHE GROUP文では、ユーザー管理キャッシュ・グループのTimesTenキャッシュ表にコミットされた挿入および更新をキャッシュされたOracle Database表に手動で伝播します。削除はフラッシュされず、手動で伝播されません。PROPAGATEキャッシュ表属性を使用するキャッシュ表にコミットされた挿入および更新は、すでにOracle Databaseに自動的に伝播されているため、キャッシュされたOracle Database表にフラッシュできません。

自動伝播では、コミットされた挿入、更新および削除が、TimesTenにコミットされた順にOracle Databaseに伝播されます。フラッシュ処理では、キャッシュ表にコミットされた複数のトランザクションをキャッシュされたOracle Database表に手動で伝播できます。

AUTOREFRESHキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループはフラッシュできません。

キャッシュ表の少なくとも1つがPROPAGATEとREADONLYのいずれのキャッシュ表属性も使用していない場合には、ユーザー管理キャッシュ・グループをフラッシュできます。

キャッシュされたOracle Database表にフラッシュされる行を限定するには、FLUSH CACHE GROUP文でWHERE句またはWITH ID句を使用します。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のFLUSH CACHE GROUP文に関する説明を参照してください。

例5-8 キャッシュ・グループのフラッシュ

次の文では、western_customersキャッシュ・グループのTimesTenキャッシュ表にコミットされた挿入処理および更新処理をキャッシュされたOracle Database表に手動で伝播します。

FLUSH CACHE GROUP western_customers;

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

UNLOAD CACHE GROUP文を使用すると、一部またはすべてのキャッシュ・インスタンスをキャッシュ・グループのキャッシュ表から削除できます。DROP CACHE GROUP文とは異なり、キャッシュ・グループをアンロードしてもキャッシュ表自体は削除されません。

自動リフレッシュ・キャッシュ・グループでUNLOAD CACHE GROUP文を使用する場合は注意が必要です。アンロードした行またはその関連する親行または子行をキャッシュされたOracle Database表で更新した場合、自動リフレッシュ処理の結果、その行がキャッシュ表に再表示されることがあります。

AWTキャッシュ・グループに対するUNLOAD CACHE GROUP文の実行は、行に対する更新がOracle Databaseに伝播されるまで待機します。

アンロード処理が単一のトランザクション内で多数のキャッシュ・インスタンスを処理すると同時実行性およびスループットが大幅に低下するため、これを避けるには、COMMIT EVERY n ROWS句を使用して、コミット頻度を指定します。

注意:
詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のUNLOAD CACHE GROUPに関する説明を参照してください。

例5-9 キャッシュ・グループのアンロード

次の文では、customer_ordersキャッシュ・グループのすべてのキャッシュ表からすべてのキャッシュ・インスタンスをアンロードします。コミット頻度が指定されているため、256行ごとにコミットすることにより、複数のトランザクションにわたって処理が実行されます。

UNLOAD CACHE GROUP customer_orders COMMIT EVERY 256 ROWS;

次の文では、単一のトランザクションでcustomer_ordersキャッシュ・グループのすべてのキャッシュ表からすべてのキャッシュ・インスタンスをアンロードします。単一のトランザクションは、customer_orders内のデータが小さい場合にのみ使用する必要があります。

UNLOAD CACHE GROUP customer_orders;

次の同等の文では、new_customersキャッシュ・グループのキャッシュ表から顧客番号227のキャッシュ・インスタンスを削除します。

UNLOAD CACHE GROUP new_customers WITH ID (227);
UNLOAD CACHE GROUP new_customers WHERE (oratt.customer.cust_num = 227);

すべてのグリッド・メンバーのキャッシュ・グループのアンロード

キャッシュ・グリッド内にあるすべてのメンバーのキャッシュ・グループをアンロードするには、オプティマイザ・フラグを設定します。UNLOAD CACHE GROUP文を実行する前に、ttOptSetFlag組込みプロシージャをコールし、GlobalProcessingオプティマイザ・フラグを1に設定します。

注意:
GlobalProcessingオプティマイザ・フラグの状態には関係なく、COMMIT EVERY n ROWS句を使用した場合、複数のグリッド・ノード間でアンロード処理は実行されません。

CALL ttOptSetFlag('GlobalProcessing', 1);

次の文について考えてみます。

UNLOAD CACHE GROUP customer WHERE customer_id=54321;

ローカル・アンロード処理では、文が実行されるノードに顧客レコードが存在する場合のみ、レコードを削除します。グローバル・アンロード処理では、顧客レコードが含まれているノードに関係なく、レコードを削除します。

処理の影響を受けるキャッシュ・インスタンス数の判別

LOAD CACHE GROUP文によってロードされたキャッシュ・インスタンス、REFRESH CACHE GROUP文によってリフレッシュされたキャッシュ・インスタンス、FLUSH CACHE GROUP文によってフラッシュされたキャッシュ・インスタンスまたはUNLOAD CACHE GROUP文によってアンロードされたキャッシュ・インスタンスの数を判別するには、次のメカニズムを使用します。

- ODBC関数SQLRowCount()をコールします。

- JDBCメソッドStatement.getUpdateCount()を起動します。

- OCI_ATTR_ROW_COUNTオプションを指定したOCI関数OCIAttrGet()をコールします。

パススルー・レベルの設定

アプリケーションがTimesTen接続に対して文を発行すると、その文をTimesTenデータベースで実行したり、Oracle Databaseにパススルーして実行できます。文をTimesTenデータベースまたはOracle Databaseのいずれで実行するかは、文の構成およびPassThrough接続属性の設定によって決まります。PassThrough接続属性を設定して、TimesTenでローカルに実行される文およびOracle Databaseにリダイレクトして実行される文を定義できます。

パススルー・レベル1から5で適切な場合、TimesTenは、ユーザーの現在の資格証明をユーザー名に、OraclePwd接続属性をOracleパスワードに使用してOracle Databaseに接続します。

注意:
RETURN TWOSAFEを使用してレプリケートされる処理を含むトランザクションでは、0より大きなPassThrough設定を使用できません。PassThroughが0より大きい場合は、エラーが返され、トランザクションをロールバックする必要があります。
PassThroughが0、1、または2に設定されているとき、動的ロードの条件が存在している場合は次の動作が発生します。

- 任意の動的キャッシュ・グループ・タイプのキャッシュ表に対してSELECT処理のための動的ロードの発生が可能です。

- INSERT処理、UPDATE処理、またはDELETE処理のための動的ロードは、動的AWTまたはSWTキャッシュ・グループを持つキャッシュ表に対してのみ発生が可能です。

動的ロードの詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

PassThrough=0

PassThrough= 0はデフォルト設定であり、すべての文がTimesTenデータベースで実行されることになります。図5-1に、TimesTenデータベースで更新される表Aを示します。表Fは、TimesTen内に存在しないため更新できません。

図5-1 PassThrough=0

PassThrough=1

PassThrough= 1を設定して、TimesTenデータベースに存在しない表を参照している文はOracle Databaseにパススルーされて実行されるように指定します。DDL文はOracle Databaseにパススルーされません。

SELECT文にTimesTen SQLで存在しないキーワードが含まれていることまたは構文エラーが含まれていることが原因でTimesTenにより文を解析できない場合、この文はOracle Databaseに渡されます。TimesTenによりINSERT文、UPDATE文またはDELETE文を解析できない場合は、TimesTenによりエラーが返され、文はOracle Databaseにパススルーされません。

図5-2に、TimesTenデータベースで更新される表Aを示します(表GはTimesTenデータベースに存在しないため、表GはOracle Databaseで更新されます)。

図5-2 PassThrough=1

PassThrough=2

PassThrough=2は、読取り専用キャッシュ・グループおよびREADONLYキャッシュ表属性を使用するユーザー管理キャッシュ・グループに対するINSERT文、UPDATE文およびDELETE文がOracle Databaseにパススルーされるように指定します。それ以外の場合は、Passthrough=1の動作が適用されます。

注意:
別のユーザーがキャッシュされたOracle Database表で更新したのと同じ行をTimesTenキャッシュ表で同時に更新することによる競合が発生しないようにする必要があります。

図5-3に、Oracle Databaseにパススルーされる、読取り専用キャッシュ・グループ内の表Aおよび表Gに対する更新を示します。

図5-3 PassThrough=2

PassThrough=3

PassThrough=3は、TimesTenエラーとなる動的AWTグローバル・キャッシュ・グループのキャッシュ表に対して発行されるINSERT、UPDATEおよびDELETE文を除いて、すべての文がOracle Databaseにパススルーされて実行されるように指定します。

図5-4に、読取り専用キャッシュ・グループまたは更新可能キャッシュ・グループに対してOracle Databaseで更新される表Aを示します。表Gを参照するSELECT文も、Oracle Databaseにパススルーされます。動的AWTグローバル・キャッシュ・グループ内の表Cを参照するSELECT文は、Oracle Databaseにパススルーされます。

図5-4 PassThrough=3

PassThrough=4

PassThrough=4は、動的ロードの問合せの基準を満たさない動的AWTグローバル・キャッシュ・グループのキャッシュ表に対して発行されたSELECT文がOracle Databaseにパススルーされて実行されるように指定します。これ以外の場合、文はTimesTenデータベースで実行されます。動的ロードSELECT文の基準の詳細は、「動的ロードのガイドライン」を参照してください。

図5-5に、TimesTenデータベースで更新される更新可能キャッシュ・グループ内の表Aを示します。また、この図には、動的ロードSELECT文の基準を満たさない動的AWTグローバル・キャッシュ・グループに対して発行され、Oracle Databaseにパススルーされて実行されるSELECT文も示します。

図5-5 PassThrough=4

PassThrough=5

PassThrough=5は、接続中の以前のトランザクションによって、動的AWTグローバル・キャッシュ・グループのキャッシュ表でコミットされたすべての更新がOracle Databaseに伝播されるときに、動的ロード問合せの基準を満たさない動的AWTグローバル・キャッシュ・グループのキャッシュ表に対して発行されたSELECT文がOracle Databaseにパススルーされて実行されるように指定します。これ以外の場合、文はTimesTenデータベースで実行されます。動的ロードSELECT文の基準の詳細は、「動的ロードのガイドライン」を参照してください。

図5-6に、TimesTenデータベースで更新される更新可能キャッシュ・グループ内の表Aを示します。また、この図には、接続中の以前のトランザクションによって、動的AWTグローバル・キャッシュ・グループのキャッシュ表でコミットされたすべての更新がOracle Databaseに伝播された後に、動的ロードSELECT文の基準を満たさない動的AWTグローバル・キャッシュ・グループに対して発行され、Oracle Databaseにパススルーされて実行されるSELECT文も示します。

図5-6 PassThrough=5

パススルーを使用する場合の注意事項

AWTまたはSWTキャッシュ・グループのキャッシュ表に対して発行する場合は、更新処理をOracle Databaseにパススルーして実行することはお薦めしません。

- AWTキャッシュ・グループのキャッシュ表にコミットされた更新は、キャッシュされたOracle Database表に自動的に非同期で伝播されます。一方、AWTキャッシュ・グループのキャッシュ表に対する更新と同じトランザクション内で更新処理をOracle Databaseにパススルーして実行すると、キャッシュ表の更新が同期して伝播され、不適切な結果が発生する場合があります。

- 同じトランザクション内で、同じ表に対する更新がOracle Databaseにパススルーされて実行された場合、SWTキャッシュ・グループのキャッシュ表にコミットされた更新によって自己デッドロックが発生することがあります。

PL/SQLブロックをOracle Databaseにパススルーして実行することはできません。また、Oracle Databaseには定義されているものの、TimesTenデータベースには定義されていないストアド・プロシージャまたは関数への参照をOracle Databaseにパススルーして実行することもできません。

PassThrough接続属性の設定によって、どの状況で、どの文がTimesTenデータベースで実行され、どの文がOracle Databaseにパススルーされて実行されるのかを決定する方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のパススルーに関する説明を参照してください。

注意:
パススルー機能では、Oracle Databaseとの通信にOCIを使用します。OCI診断フレームワークではシグナル・ハンドラをインストールしますが、このハンドラはアプリケーションで使用するシグナル処理に影響を与える可能性があります。OCIシグナル処理を無効化するには、sqlnet.oraファイルでDIAG_SIGHANDLER_ENABLED=FALSEを設定します。詳細は、Oracle Call Interfaceプログラマーズ・ガイドのOCIでの障害診断に関する説明を参照してください。

接続またはトランザクションのパススルー・レベルの変更

現在のパススルー・レベルを上書きするには、現在のトランザクションに適用されるttIsqlユーティリティのset passthroughコマンドを使用します。

また、PassThroughフラグを指定したttOptSetFlag組込みプロシージャをコールすることによって、特定のトランザクションの設定を上書きすることもできます。次のプロシージャ・コールは、パススルー・レベルを3に設定します。

CALL ttOptSetFlag('PassThrough', 3);

PassThroughフラグの設定は文の準備時に有効になり、文を準備してから文を実行するまでの間に設定を変更しても、文の実行時に使用されるのは準備時の設定です。トランザクションがコミットまたはロールバックされると、元の接続設定が後続のすべてのプリコンパイルされたSQL文で有効になります。

6 他のキャッシュ・グリッド・メンバーの作成

次の各項では、2つ目のスタンドアロンTimesTenデータベースおよびアクティブ・スタンバイ・ペアを作成し、第3章「キャッシュ・インフラストラクチャの設定」で作成したキャッシュ・グリッドにこれらのメンバーをアタッチする場合のタスクについて説明します。

- 後続のスタンドアロンTimesTenデータベースの作成および構成

- キャッシュ表のレプリケート

- グリッド・メンバー間のデータ共有の例

- キャッシュ・グリッドに対するグローバル問合せの実行

- キャッシュ・グリッドまたはグリッド・メンバーへの他の要素の追加

注意:
Oracle Clusterwareを使用してキャッシュ・グリッドのアクティブ・スタンバイ・ペアを管理する計画を立てている場合は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のTimesTenキャッシュ・グリッドでのOracle Clusterwareの使用に関する説明を参照してください。
また、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の制限されたコマンドおよびSQL文に関する説明も参照してください。アクティブ・スタンバイ・ペア・グリッド・メンバーを管理するには、この章で説明する組込みプロシージャではなく、ttCWAdminユーティリティを使用します。

後続のスタンドアロンTimesTenデータベースの作成および構成

次に、ttGridキャッシュ・グリッドのメンバーになる2つ目のスタンドアロンTimesTenデータベースのcachealone2 DSNの定義を示します。

[cachealone2]
DataStore=/users/OracleCache/alone2
PermSize=64
OracleNetServiceName=orcl
DatabaseCharacterSet=WE8ISO8859P1
CacheGridEnable=1

ttIsqlユーティリティを開始して、cachealone2 DSNにインスタンス管理者として接続し、データベースを作成します。次に、キャッシュ・マネージャ・ユーザーcacheuserを作成しますが、このユーザーの名前はコンパニオンOracle Databaseユーザーと同じである必要があります。この例では、キャッシュ管理ユーザーは、キャッシュ・マネージャ・ユーザーに対するコンパニオンOracle Databaseユーザーとして機能します。

さらに、TimesTenデータベースにキャッシュされるOracle Database表を所有するOracle Databaseスキーマ・ユーザーと同じ名前でキャッシュ表ユーザーorattを作成します。

% ttIsql cachealone2
Command> CREATE USER cacheuser IDENTIFIED BY timesten;
Command> CREATE USER oratt IDENTIFIED BY timesten;

インスタンス管理者としてttIsqlユーティリティを使用して、例3-8に示されている処理を実行するために必要な権限をキャッシュ・マネージャ・ユーザーcacheuserに付与します。

Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE TO cacheuser;
Command> exit

ttIsqlユーティリティを起動して、cachealone2 DSNにキャッシュ・マネージャ・ユーザーとして接続します。ttCacheUidPwdSet組込みプロシージャをコールして、キャッシュ管理ユーザーの名前およびパスワードを設定します。

% ttIsql "DSN=cachealone2;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheUidPwdSet('cacheuser','oracle');

キャッシュ・マネージャ・ユーザーとしてttGridNameSet組込みプロシージャをコールすることによって、2つ目のスタンドアロン・データベースをttGridキャッシュ・グリッドに関連付けます。

Command> CALL ttGridNameSet('ttGrid');

ttGridキャッシュ・グリッドは、最初のスタンドアロンTimesTenデータベースから作成されました。グリッドはすでに存在するため、再度作成する必要はありません。

必要に応じて、「TimesTenデータベースとOracle Database間での接続テスト」に示した手順を使用して、2つ目のスタンドアロンTimesTenデータベースとOracle Database間の接続性をテストできます。

キャッシュ・マネージャ・ユーザーとしてttCacheStart組込みプロシージャをコールすることによって、2つ目のスタンドアロン・データベースでキャッシュ・エージェントを起動します。

Command> CALL ttCacheStart;

次に、キャッシュ・マネージャ・ユーザーとしてデータベースにキャッシュ・グループを作成します。たとえば、次の文では、oratt.subscriber表をキャッシュする動的AWTグローバル・キャッシュ・グループsubscriber_accountsが作成されます。

CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP subscriber_accounts
FROM oratt.subscriber
(subscriberid       NUMBER(10) NOT NULL PRIMARY KEY,
name               VARCHAR2(100) NOT NULL,
minutes_balance    NUMBER(5) NOT NULL,
last_call_duration NUMBER(4) NOT NULL);

キャッシュされたOracle Database表oratt.subscriberの定義の詳細は、「グローバル・キャッシュ・グループ」を参照してください。

AWTキャッシュ・グループが作成されている場合は、キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、TimesTenデータベースでレプリケーション・エージェントを起動します。

Command> CALL ttRepStart;

グローバル・キャッシュ・グループが作成されている場合、グローバル・キャッシュ・グループのキャッシュ表を更新するには、関連付けられているキャッシュ・グリッドにデータベースをアタッチする必要があります。データベースをグリッドにアタッチすると、データベースをグリッド・メンバーにすることができ、その結果、グリッド内のデータベース間で、グローバル・キャッシュ・グループのキャッシュ表内にあるキャッシュ・インスタンスの一貫性を保持できます。

関連付けられているttGridキャッシュ・グリッドに2つ目のスタンドアロン・データベースをアタッチするには、キャッシュ・マネージャ・ユーザーとしてttGridAttach組込みプロシージャをコールします。スタンドアロンのTimesTenデータベースのノード番号は1です。

次の例で、alone2はグリッド・メンバーを一意に識別する名前を、sys2は2つ目のスタンドアロン・データベースが存在するTimesTenシステムのホスト名を、5002は2つ目のスタンドアロン・データベースのキャッシュ・エージェント・プロセスのTCP/IPポートを示しています。

Command> CALL ttGridAttach(1,'alone2','sys2',5002);
Command> exit

キャッシュ表のレプリケート

高可用性を実現するために、読取り専用キャッシュ・グループまたはAWTキャッシュ・グループのキャッシュ表に対してアクティブ・スタンバイ・ペアのレプリケーション・スキームを構成します。

これらのキャッシュ・グループ・タイプのいずれかからキャッシュ表をレプリケートするアクティブ・スタンバイ・ペアを使用すると、フェイルオーバーおよびリカバリの一部として、データ損失の可能性を最小限に抑えて、TimesTenデータベースのロールを自動的に変更できます。キャッシュ・グループ自体は、Oracle Databaseの停止からのリジリエンスを提供するため、システムの可用性がさらに強化されます。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のキャッシュ・グループを含むアクティブ・スタンバイ・ペアの管理に関する説明を参照してください。

アクティブ・スタンバイ・ペアのレプリケーション・スキームを構成すると、TimesTenデータベースの高可用性を実現できます。グリッド・メンバーを複数配置すると、TimesTenキャッシュ・グリッドの高可用性を実現できます。Oracle Real Application Clusters(Oracle RAC)を構成すると、Oracle Databaseの高可用性を実現できます。Oracle RAC環境でTimesTen Application-Tier Database Cacheを使用する方法の詳細は、「Oracle RAC環境でのTimesTen Application-Tier Database Cacheの使用」を参照してください。

Oracle Database表をキャッシュするTimesTenデータベースに対してアクティブ・スタンバイ・ペアを構成するには、次のタスクを実行します。

- アクティブ・データベースの作成および構成

- スタンバイ・データベースの作成および構成

- 読取り専用サブスクライバ・データベースの作成および構成

アクティブ・データベースの作成および構成

次に、ttGridキャッシュ・グリッドのメンバーになるアクティブ・スタンバイ・ペアのアクティブ・データベースのcacheactive DSNの定義を示します。

[cacheactive]
DataStore=/users/OracleCache/cacheact
PermSize=64
OracleNetServiceName=orcl
DatabaseCharacterSet=WE8ISO8859P1
CacheGridEnable=1

ttIsqlユーティリティを開始して、cacheactive DSNにインスタンス管理者として接続し、データベースを作成します。次に、キャッシュ・マネージャ・ユーザーcacheuserを作成しますが、このユーザーの名前はコンパニオンOracle Databaseユーザーと同じです。この例では、キャッシュ管理ユーザーは、コンパニオンOracle Databaseユーザーとして機能します。

さらに、TimesTenデータベースにキャッシュされるOracle Database表を所有するOracle Databaseスキーマ・ユーザーと同じ名前でキャッシュ表ユーザーorattを作成します。

% ttIsql cacheactive
Command> CREATE USER cacheuser IDENTIFIED BY timesten;
Command> CREATE USER oratt IDENTIFIED BY timesten;

インスタンス管理者としてttIsqlユーティリティを使用して、例3-8に示されている処理を実行し、ADMIN権限を必要とするアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成するために必要な権限をキャッシュ・マネージャ・ユーザーcacheuserに付与します。

Command> GRANT CREATE SESSION, CACHE_MANAGER,
> CREATE ANY TABLE, ADMIN TO cacheuser;
Command> exit

ttIsqlユーティリティを起動して、cacheactive DSNにキャッシュ・マネージャ・ユーザーとして接続します。ttCacheUidPwdSet組込みプロシージャをコールして、キャッシュ管理ユーザーの名前およびパスワードを設定します。

% ttIsql "DSN=cacheactive;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheUidPwdSet('cacheuser','oracle');

キャッシュ・マネージャ・ユーザーとしてttGridNameSet組込みプロシージャをコールすることによって、アクティブ・データベースをttGridキャッシュ・グリッドに関連付けます。

Command> CALL ttGridNameSet('ttGrid');

ttGridキャッシュ・グリッドは、最初のスタンドアロンTimesTenデータベースから作成されました。グリッドはすでに存在するため、再度作成する必要はありません。

必要に応じて、「TimesTenデータベースとOracle Database間での接続テスト」に示した手順を使用して、アクティブ・データベースとOracle Database間の接続性をテストできます。

キャッシュ・マネージャ・ユーザーとしてttCacheStart組込みプロシージャをコールすることによって、アクティブ・データベースでキャッシュ・エージェントを起動します。

Command> CALL ttCacheStart;

次に、キャッシュ・マネージャ・ユーザーとしてデータベースにキャッシュ・グループを作成します。たとえば、次の文では、oratt.subscriber表をキャッシュする動的AWTグローバル・キャッシュ・グループsubscriber_accountsが作成されます。

CREATE DYNAMIC ASYNCHRONOUS WRITETHROUGH GLOBAL CACHE GROUP subscriber_accounts
FROM oratt.subscriber
(subscriberid       NUMBER(10) NOT NULL PRIMARY KEY,
name               VARCHAR2(100) NOT NULL,
minutes_balance    NUMBER(5) NOT NULL,
last_call_duration NUMBER(4) NOT NULL);

キャッシュされたOracle Database表oratt.subscriberの定義の詳細は、「グローバル・キャッシュ・グループ」を参照してください。

キャッシュ・マネージャ・ユーザーとして、CREATE ACTIVE STANDBY PAIR文を使用して、アクティブ・データベースにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

次の例では、cacheact、cachestandおよびsubscrはそれぞれ、アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバ・データベースのチェックポイント・ファイルおよびトランザクション・ログ・ファイルのファイル名接頭辞です。また、sys3、sys4およびsys5はそれぞれ、アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバ・データベースが存在するTimesTenシステムのホスト名です。

Command> CREATE ACTIVE STANDBY PAIR cacheact ON "sys3", cachestand ON "sys4"
> SUBSCRIBER subscr ON "sys5";

キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、アクティブ・データベースでレプリケーション・エージェントを起動します。次に、ttRepStateSet組込みプロシージャをコールすることによって、データベースをアクティブとして宣言します。

Command> CALL ttRepStart;
Command> CALL ttRepStateSet('active');

グローバル・キャッシュ・グループが作成されている場合、グローバル・キャッシュ・グループのキャッシュ表を更新するには、関連付けられているキャッシュ・グリッドにデータベースをアタッチする必要があります。データベースをグリッドにアタッチすると、データベースをグリッド・メンバーにすることができ、その結果、グリッド内のデータベース間で、グローバル・キャッシュ・グループのキャッシュ表内にあるキャッシュ・インスタンスの一貫性を保持できます。

関連付けられているttGridキャッシュ・グリッドにアクティブ・データベースをアタッチするには、キャッシュ・マネージャ・ユーザーとしてttGridAttach組込みプロシージャをコールします。アクティブ・データベースのノード番号は1です。

例で使用される各要素の意味は、次のとおりです。

- cacheactは、アクティブ・データベースのグリッド・ノードを一意に識別する名前です。

- cachestandは、スタンバイ・データベースのグリッド・ノードを一意に識別する名前です。

- sys3は、アクティブ・データベースが存在するTimesTenシステムのホスト名です。

- sys4は、スタンバイ・データベースが存在するTimesTenシステムのホスト名です。

- 5003は、アクティブ・データベースのキャッシュ・エージェント・プロセス用のTCP/IPポートです。

- 5004は、スタンバイ・データベースのキャッシュ・エージェント・プロセス用のTCP/IPポートです。

Command> CALL ttGridAttach(1,'cacheact','sys3',5003,'cachestand','sys4',5004);
Command> exit

スタンバイ・データベースの作成および構成

次に、ttGridキャッシュ・グリッドのメンバーになるアクティブ・スタンバイ・ペアのスタンバイ・データベースのcachestandby DSNの定義を示します。

[cachestandby]
DataStore=/users/OracleCache/cachestand
PermSize=64
OracleNetServiceName=orcl
DatabaseCharacterSet=WE8ISO8859P1
CacheGridEnable=1

インスタンス管理者として、スタンバイ・データベース・システムからttRepAdmin -duplicateユーティリティ・コマンドを実行することによって、スタンバイ・データベースをアクティブ・データベースの複製として作成します。アクティブ・データベースのインスタンスとスタンバイ・データベースのインスタンスのインスタンス管理者ユーザー名は同じである必要があります。

スタンバイ・データベースにはOracle Databaseとの接続性があるため、アクティブ・データベースのキャッシュ表がスタンバイ・データベースのキャッシュ表として複製されるように、-keepCGオプションを使用します。

例で使用される各要素の意味は、次のとおりです。

- -fromオプションには、アクティブ・データベースのチェックポイント・ファイルおよびトランザクション・ログ・ファイルのファイル名接頭辞を指定します。

- -hostオプションには、アクティブ・データベースが存在するTimesTenシステムのホスト名を指定します。

- -uidオプションおよび-pwdオプションには、アクティブ・データベースに定義され、ADMIN権限が付与されているTimesTen内部ユーザーのユーザー名およびパスワードを指定します。

- -cacheuidオプションおよび-cachepwdオプションには、キャッシュ管理ユーザーの名前およびパスワードを指定します。

- cachestandbyは、スタンバイ・データベースのDSNです。

% ttRepAdmin -duplicate -from cacheact -host "sys3" -uid cacheuser -pwd timesten
-cacheuid cacheuser -cachepwd oracle -keepCG cachestandby

ttIsqlユーティリティを起動して、cachestandby DSNにキャッシュ・マネージャ・ユーザーとして接続します。ttCacheUidPwdSet組込みプロシージャをコールして、キャッシュ管理ユーザーの名前およびパスワードを設定します。

% ttIsql "DSN=cachestandby;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheUidPwdSet('cacheuser','oracle');

ttGridキャッシュ・グリッドは、最初のスタンドアロンTimesTenデータベースから作成されました。グリッドはすでに存在するため、再度作成する必要はありません。

ttRepAdmin -duplicate -keepCGユーティリティ・コマンドによってスタンバイ・データベースがttGridキャッシュ・グリッドに関連付けられるため、この関連付けを明示的に行う必要はありません。

必要に応じて、「TimesTenデータベースとOracle Database間での接続テスト」に示した手順を使用して、スタンバイ・データベースとOracle Database間の接続性をテストできます。

キャッシュ・マネージャ・ユーザーとしてttCacheStart組込みプロシージャをコールすることによって、スタンバイ・データベースでキャッシュ・エージェントを起動します。

Command> CALL ttCacheStart;

キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、スタンバイ・データベースでレプリケーション・エージェントを起動します。

Command> CALL ttRepStart;

グローバル・キャッシュ・グループが作成されている場合、グローバル・キャッシュ・グループのキャッシュ表を更新するには、関連付けられているキャッシュ・グリッドにデータベースをアタッチする必要があります。データベースをグリッドにアタッチすると、データベースをグリッド・メンバーにすることができ、その結果、グリッド内のデータベース間で、グローバル・キャッシュ・グループのキャッシュ表内にあるキャッシュ・インスタンスの一貫性を保持できます。

関連付けられているttGridキャッシュ・グリッドにスタンバイ・データベースをアタッチするには、キャッシュ・マネージャ・ユーザーとしてttGridAttach組込みプロシージャをコールします。スタンバイ・データベースのノード番号は2です。アクティブ・データベースおよびスタンバイ・データベースのキャッシュ・エージェントには、アクティブ・データベースの構成時に指定したTCP/IPポートと同じTCP/IPポートを使用します。

例で使用される各要素の意味は、次のとおりです。

- cacheactは、アクティブ・データベースのグリッド・ノードを一意に識別する名前です。

- cachestandは、スタンバイ・データベースのグリッド・ノードを一意に識別する名前です。

- sys3は、アクティブ・データベースが存在するTimesTenシステムのホスト名です。

- sys4は、スタンバイ・データベースが存在するTimesTenシステムのホスト名です。

- 5003は、アクティブ・データベースのキャッシュ・エージェント・プロセス用のTCP/IPポートです。

- 5004は、スタンバイ・データベースのキャッシュ・エージェント・プロセス用のTCP/IPポートです。

Command> CALL ttGridAttach(2,'cacheact','sys3',5003,'cachestand','sys4',5004);
Command> exit

読取り専用サブスクライバ・データベースの作成および構成

次に、アクティブ・スタンバイ・ペアの読取り専用サブスクライバ・データベースのrosubscriber DSNの定義を示します。

[rosubscriber]
DataStore=/users/OracleCache/subscr
PermSize=64
DatabaseCharacterSet=WE8ISO8859P1

インスタンス管理者として、読取り専用サブスクライバ・データベース・システムからttRepAdmin -duplicateユーティリティ・コマンドを実行することによって、読取り専用サブスクライバ・データベースをスタンバイ・データベースの複製として作成します。スタンバイ・データベースのインスタンスと読取り専用サブスクライバ・データベースのインスタンスのインスタンス管理者ユーザー名は同じである必要があります。

読取り専用サブスクライバ・データベースにはOracle Databaseとの接続性がないため、スタンバイ・データベースのキャッシュ表が読取り専用サブスクライバ・データベースの通常の表として複製されるように、-noKeepCGオプションを使用します。この結果、読取り専用サブスクライバ・データベースはキャッシュ・グリッドに関連付けられなくなります。

例で使用される各要素の意味は、次のとおりです。

- -fromオプションには、スタンバイ・データベースのチェックポイント・ファイルおよびトランザクション・ログ・ファイルのファイル名接頭辞を指定します。

- -hostオプションには、スタンバイ・データベースが存在するTimesTenシステムのホスト名を指定します。

- -uidオプションおよび-pwdオプションには、スタンバイ・データベースに定義され、ADMIN権限が付与されているTimesTen内部ユーザーのユーザー名およびパスワードを指定します。

- rosubscriberは、読取り専用サブスクライバ・データベースのDSNです。

% ttRepAdmin -duplicate -from cachestand -host "sys4" -uid cacheuser -pwd timesten
-noKeepCG rosubscriber

キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールすることによって、読取り専用サブスクライバ・データベースでレプリケーション・エージェントを起動します。

% ttIsql "DSN=rosubscriber;UID=cacheuser;PWD=timesten"
Command> CALL ttRepStart;
Command> exit

グリッド・メンバー間のデータ共有の例

キャッシュされたOracle Database表oratt.subscriberの定義の詳細は、「グローバル・キャッシュ・グループ」を参照してください。

次に、キャッシュされたOracle Database表oratt.subscriberのデータを示します。

SUBSCRIBERID  NAME              MINUTES_BALANCE   LAST_CALL_DURATION
------------  ----------------  ---------------   ------------------
1001  Jane Anderson                  75                   15
1004  Robert Phillips                60                   20
1005  William Ackerman               40                   10
1009  Sandy Little                   90                   30

グローバル・キャッシュ・グループsubscriber_accountsのTimesTenキャッシュ表oratt.subscriberは、5つすべてのTimesTenデータベース(cachealone1、cachealone2、cacheactive、cachestandby、rosubscriber)で最初は空になっています。

Command> SELECT * FROM oratt.subscriber;
0 rows found.

TimesTenデータベースcachealone1で次のSELECT文を発行して、キャッシュされたOracle Database表からTimesTenキャッシュ表に1つのキャッシュ・インスタンスを動的にロードします。

Command> SELECT * FROM oratt.subscriber WHERE subscriberid = 1004;
< 1004, Robert Phillips, 60, 20 >

この結果、スタンドアロン・データベース・グリッド・メンバーcachealone1は、サブスクライバIDが1004のキャッシュ・インスタンスの所有権を持ちます。このキャッシュ・インスタンスは、他のいずれのグリッド・メンバーにも存在しません。

次に、TimesTenデータベースcachealone2で次のSELECT文を発行して、キャッシュされたOracle Database表からTimesTenキャッシュ表にキャッシュ・インスタンスを1つ動的にロードします。

Command> SELECT * FROM oratt.subscriber WHERE subscriberid = 1004;
< 1004, Robert Phillips, 60, 20 >

この結果、スタンドアロン・データベース・グリッド・メンバーcachealone2は、サブスクライバIDが1004のキャッシュ・インスタンスの所有権をグリッド・メンバーcachealone1から取得します。これで、このキャッシュ・インスタンスはcachealone1には存在しなくなり、他のいずれのグリッド・メンバーにも存在しなくなります。

次に、TimesTenデータベースcacheactiveで次のINSERT文を発行して、新しいキャッシュ・インスタンスをTimesTenキャッシュ表に挿入します。

Command> INSERT INTO oratt.subscriber VALUES (1012, 'Charles Hill', 80, 16);

この結果、アクティブ・データベース・グリッド・ノードcacheactiveは、サブスクライバIDが1012のキャッシュ・インスタンスの所有権を持ちます。このキャッシュ・インスタンスは、スタンバイ・データベースcachestandbyおよび読取り専用サブスクライバ・データベースrosubscriberにレプリケートされます。このキャッシュ・インスタンスは、他のいずれのグリッド・メンバーにも存在しません。また、この挿入処理は、キャッシュされたOracle Database表oratt.subscriberにも自動的に伝播されます。

スタンバイ・データベースまたは読取り専用サブスクライバ・データベースでは、キャッシュ・インスタンスの所有権を直接取得できません。これらのデータベースは読取り専用であるため、動的ロード処理にも手動ロード処理にも、動的ロードを実行するSELECT文を含めることができません。

グリッド・メンバー間のローカル・キャッシュ・グループのキャッシュ表では、データは共有されません。グリッド・メンバーごとに、ローカル・キャッシュ・グループの数が異なることがあります。ある2つのグリッド・メンバーでローカル・キャッシュ・グループの定義が同じである場合、一方のグリッド・メンバー内のキャッシュ表のデータが他方のグリッド・メンバー内のキャッシュ表のデータと重複することがあります。ローカル・キャッシュ・グループでは、キャッシュ・インスタンスがキャッシュ表を所有するという概念がありません。

キャッシュ・グリッドに対するグローバル問合せの実行

キャッシュ・グリッド内にあるすべてのノードのデータにアクセスする場合は、グローバル問合せを実行します。たとえば、次の文を考えてみます。

SELECT MAX(salary) FROM employees;

グローバル問合せ処理が有効ではない場合、この文では、ローカル・ノードに存在する行での最大給与を返します。グローバル問合せ処理が有効である場合は、キャッシュ・グリッド内のすべての従業員レコードでの最大給与を返します。

グローバル問合せでは、アタッチされているすべてのグリッド・メンバーのキャッシュ表または非キャッシュ表を参照できます。参照対象となる表は、ローカル表、キャッシュ表、ビュー、マテリアライズド・ビューおよび表のシノニムの任意の組合せです。これらの表は、グローバル問合せによって影響を受ける列に対して同じ定義を持つ必要があります。

オプティマイザ・フラグを設定して、グローバル問合せ処理を有効化します。グローバル問合せを実行する前に、自動コミットをオフにし、ttOptSetFlag組込みプロシージャをコールしてGlobalProcessingオプティマイザ・フラグを1に設定します。

autocommit 0;
CALL ttOptSetFlag('GlobalProcessing', 1);

ローカル結合を使用するグローバル問合せを実行するには、GlobalProcessingオプティマイザ・フラグではなく、GlobalLocalJoinオプティマイザ・フラグを使用します。「ローカル結合を使用するグローバル問合せの実行」を参照してください。

GlobalProcessingオプティマイザ・フラグよって有効化されるグローバル問合せには、次の制限があります。

- 問合せは厳密に1つの表を参照する必要があります。

- 問合せに自己結合、導出表または副問合せを含めることはできません。

- 問合せではグローバル一時表を参照できません。

- 問合せをアクティブ・スタンバイ・グリッド・メンバーのスタンバイ・データベースに対して実行することはできません。

- ROWNUM句およびGROUP BY句を同じ問合せで使用することはできません。

- 問合せは、GROUPING SETS、CUBE、ROLLUP、GROUPING、GROUPING_IDまたはGROUP_IDと一緒には使用できません。

- 問合せにはWITH句を含めることはできません。

- 問合せには分析SQL関数を含めることはできません。

- PassThrough接続属性は0に設定する必要があります。

ローカル結合を使用するグローバル問合せの実行

ローカル結合を使用するグローバル問合せを実行できます。これは、SELECT文はグローバルだが(すべてのグリッド・メンバーから選択するが)、結合結果はローカルである(結合はローカル・ノードに存在する)ことを意味します。これは、ファクト表とディメンション表の結合、結合キーに基づいてデータが分散されている同じぐらいのサイズの表の結合または主キーや外部キーの関係に基づいたグローバル・キャッシュ・グループの表の結合に役立つ場合があります。ローカル結合を使用するグローバル問合せを有効にするには、GlobalLocalJoinオプティマイザ・フラグを使用します。

ローカル結合を使用するグローバル問合せでは、キャッシュ表、グローバル・キャッシュ表、同じ定義を持つ非キャッシュ表、ビューおよびマテリアライズド・ビューを結合できます。ローカル結合を使用するグローバル問合せには、順序を含めることができます。

シリアライズ可能な分離で実行されるグローバル問合せは、SELECT文のグローバル・トランザクションに属しています。コミット読取り分離で実行されるグローバル問合せは、リモート・ノード上の独自のトランザクションで実行されます。

グローバル問合せの次の処理は、各グリッド・メンバーでローカルに実行されます。

- 結合

- 導出表

- ビュー

- 副問合せのGROUP BY句、HAVING句、ORDER BY句およびDISTINCT句

グローバル問合せの主問合せで行う次の処理は、グローバルに実行されます。

- GROUP BY句および集計。

- ORDER BY句。

- DISTINCT句。

- HAVING句。この句には結合を含めることはできません。

シノニムは問合せの発行元であるノードで解決されます。

ローカル結合を使用するグローバル問合せを実行する前に、自動コミットをオフにし、ttOptSetFlag組込みプロシージャをコールしてGlobalLocalJoinオプティマイザ・フラグを1に設定します。

autocommit off;
CALL ttOptSetFlag('GlobalLocalJoin', 1)

ローカル結合を使用するグローバル問合せには、次の制限があります。

- 問合せにはROWNUM式を含めることはできません。

- 問合せには集合演算子を含めることはできません。

- 問合せにはWITH句を含めることはできません。

- 問合せは、GROUPING SETS、CUBE、ROLLUP、GROUPING、GROUPING_IDまたはGROUP_IDと一緒には使用できません。

- 問合せには分析SQL関数を含めることはできません。

- PassThrough接続属性は0に設定する必要があります。

- 問合せをアクティブ・スタンバイ・グリッド・メンバーのスタンバイ・データベースに対して実行することはできません。

キャッシュ・グリッド内のデータの場所に関する情報の取得

データの場所を変更せずにグローバル問合せを実行できます。SQL関数を使用して情報を含むグリッド・ノードを判断してから、そのノードのデータに対する問合せを実行できます。

キャッシュ・グリッド内のデータの場所に関する情報を取得するには、グローバル問合せで次のSQL関数を使用します。

- TTGRIDMEMBERID() - 問合せが実行されるノードのノードIDを返します。

- TTGRIDNODENAME() - 問合せが実行されるノードの名前を返します。

- TTGRIDUSERASSIGNEDNAME() - 問合せが実行されるノードのユーザー割当て名を返します。ユーザーは、ttGridAttach組込みプロシージャのコール時に名前を割り当てます。Oracle Clusterwareを使用している場合は、ttGridAttachを直接コールすることはなく、ユーザー割当て名はTimesTenにより生成されます。

これらの関数はSELECT文およびSELECT文の次の句で使用できます。

- WHERE句

- GROUP BY句

- ORDER BY句

図6-1に、ユーザー割当て名alone1およびalone2を持つメンバーと、cacheactおよびcachestandのノードからなるアクティブ・スタンバイ・ペアで構成されたキャッシュ・グリッドを示します。問合せではスタンバイ・データベースからはデータを取得しません。スタンバイ・データベースには、アクティブ・データベースと同じデータが格納されています。

図6-1 キャッシュ・グリッド内のデータの場所

次の例では、グリッド・メンバーのemployee表からemployee_id、ユーザー割当てノード名およびメンバーIDを取得するグローバル問合せを示します。

autocommit off;
CALL ttOptSetFlag('GlobalProcessing', 1);
SELECT employee_id, TTGRIDUSERASSIGNEDNAME(), TTGRIDMEMBERID() FROM employees;
COMMIT;
< 100, alone1, 1>
< 101, alone2, 2>
< 102, cacheact, 3>
< 103, alone1, 1>
< 104, cacheact, 3>
...

返された行には、キャッシュ・インスタンスの各行を所有するグリッド・ノードおよびメンバーが示されます。以降の問合せでは、データの所有権を変更しなくても、適切なノードにアクセスできます。たとえば、この問合せ(TTGRIDUSERASSIGNEDNAME()を含む)をグリッド・メンバーcacheactに対して実行し、cacheactが問合せの実行されるグリッドであることを確認します。

SELECT employee_id, last_name, hire_date , TTGRIDUSERASSIGNEDNAME()
FROM employees
WHERE employee_id=104;
< 104, Ernst, 1991-05-21 00:00:00, cacheact >

TTGRIDMEMBERID()、TTGRIDNODENAME()およびTTGRIDUSERASSIGNEDNAME()の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の "キャッシュ・グリッドの関数に関する説明を参照してください。

キャッシュ・グリッドまたはグリッド・メンバーへの他の要素の追加

グローバル・キャッシュ・グループを含むデータベースがキャッシュ・グリッドにアタッチされている場合、後続のデータベースを同じグリッドにアタッチし、グリッド・メンバーにすることができるのは、そのデータベースに含まれているグローバル・キャッシュ・グループの定義が、グリッドにアタッチされているデータベースのグローバル・キャッシュ・グループの定義と同じときのみです。後続のデータベースに含まれているグローバル・キャッシュ・グループの数が、グリッドにアタッチされているデータベースより多いかまたは少ない場合、後続のデータベースを同じグリッドにアタッチすることはできません。データベースごとに、ローカル・キャッシュ・グループの数が異なり、データベース間で定義が一致しない場合があります。

キャッシュ・グリッドにアタッチされているTimesTenデータベースに動的AWTグローバル・キャッシュ・グループを新しく作成する場合は、データベースでレプリケーション・エージェントを停止しておきます。次に、グローバル・キャッシュ・グループを作成してから、レプリケーション・エージェントを再起動します。新しいグローバル・キャッシュ・グループは手動でロードすることも動的にロードすることもできず、また、そのキャッシュ表はすべてのグリッド・メンバーで同じ定義を使用してキャッシュ・グループが作成されるまで更新できません。スタンドアロン・データベースおよびアクティブ・データベースに、その新しいグローバル・キャッシュ・グループを手動で作成します。スタンバイ・データベースおよび読取り専用サブスクライバ・データベースの場合は、ttDestroyユーティリティを使用してデータベースを削除し、ttRepAdmin -duplicateユーティリティ・コマンドを使用してデータベースを再作成して、これらのデータベースに新しいグローバル・キャッシュ・グループが含まれるようにします。

7 キャッシュ環境の管理

次の各項では、キャッシュ・グリッド、キャッシュ・グループ、キャッシュ・エージェント・プロセスなどのキャッシュ・システムの様々な情報を管理して監視する方法について説明します。

- キャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

- キャッシュ・グループおよびキャッシュ・グリッドの監視

- Oracle Databaseオブジェクトによるキャッシュ環境の管理

- TimesTenデータベースでの自動リフレッシュ処理の失敗による影響

- 自動リフレッシュ・キャッシュ・グループで使用されているOracle Databaseオブジェクトの削除

- キャッシュ管理ユーザーの表領域の監視

- グリッド・ノードの障害後のリカバリ

- キャッシュ・グループを持つデータベースのバックアップおよびリストア

- キャッシュ・ユーザー名およびパスワードの変更

キャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

ttAdminユーティリティまたはttStatusユーティリティを使用すると、TimesTenキャッシュ・エージェント・プロセスおよびレプリケーション・エージェント・プロセスが実行されているかどうかをチェックできる以外に、各エージェントの起動ポリシーを確認できます。

例7-1 ttAdminによるキャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

ttAdmin -queryユーティリティ・コマンドを使用すると、キャッシュ・エージェントおよびレプリケーション・エージェントが実行されているかどうか、およびTimesTenデータベース用のキャッシュ・エージェントとレプリケーション・エージェントの起動ポリシーを確認できます。

% ttAdmin -query cachealone1
RAM Residence Policy            : inUse
Replication Agent Policy        : manual
Replication Manually Started    : True
Cache Agent Policy              : always
Cache Agent Manually Started    : True

ttAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

例7-2 ttStatusによるキャッシュ・エージェントおよびレプリケーション・エージェントのステータスの確認

ttStatusユーティリティを使用すると、キャッシュ・エージェントおよびレプリケーション・エージェントが実行されているかどうか、およびインストール済インスタンスにおける、すべてのTimesTenデータベース用のキャッシュ・エージェントとレプリケーション・エージェントの起動ポリシーを確認できます。

% ttStatus
TimesTen status report as of Thu May  7 13:42:01 2009

Daemon pid 9818 port 4173 instance myinst
TimesTen server pid 9826 started on port 4175
------------------------------------------------------------------------
Data store /users/OracleCache/alone1
There are 38 connections to the data store
Shared Memory KEY 0x02011c82 ID 895844354
PL/SQL Memory KEY 0x03011c82 ID 895877123 Address 0x10000000
Type            PID     Context     Connection Name              ConnID
Cache Agent     1019    0x0828f840  Handler                           2
Cache Agent     1019    0x083a3d40  Timer                             3
Cache Agent     1019    0x0842d820  Aging                             4
Cache Agent     1019    0x08664fd8  Garbage Collector(-1580741728)    5
Cache Agent     1019    0x084d6ef8  Marker(-1580213344)               6
Cache Agent     1019    0xa5bb8058  DeadDsMonitor(-1579684960)        7
Cache Agent     1019    0x088b49a0  CacheGridEnv                     14
Cache Agent     1019    0x0896b9d0  CacheGridSend                    15
Cache Agent     1019    0x089fb020  CacheGridSend                    16
Cache Agent     1019    0x08a619f8  CacheGridSend                    17
Cache Agent     1019    0x08ace538  CacheGridRec                     18
Cache Agent     1019    0x08b42e88  CacheGridRec                     19
Cache Agent     1019    0x08bb77d8  CacheGridRec                     20
Cache Agent     1019    0x08c2c128  CacheGridRec                     21
Cache Agent     1019    0x08ca0a78  CacheGridRec                     22
Cache Agent     1019    0x08d153c8  CacheGridRec                     23
Cache Agent     1019    0x08d89d18  CacheGridRec                     24
Cache Agent     1019    0x08dfe668  CacheGridRec                     25
Cache Agent     1019    0x08e72fb8  CacheGridRec                     26
Cache Agent     1019    0x08ee8020  CacheGridRec                     27
Cache Agent     1019    0x08f5d088  CacheGridRec                     28
Cache Agent     1019    0x08fd23f8  CacheGridRec                     29
Cache Agent     1019    0x09047768  CacheGridRec                     30
Replication     18051   0x08c3d900  RECEIVER                          8
Replication     18051   0x08b53298  REPHOLD                           9
Replication     18051   0x08af8138  REPLISTENER                      10
Replication     18051   0x08a82f20  LOGFORCE                         11
Replication     18051   0x08bce660  TRANSMITTER                      12
Subdaemon       9822    0x080a2180  Manager                        2032
Subdaemon       9822    0x080ff260  Rollback                       2033
Subdaemon       9822    0x08548c38  Flusher                        2034
Subdaemon       9822    0x085e3b00  Monitor                        2035
Subdaemon       9822    0x0828fc10  Deadlock Detector              2036
Subdaemon       9822    0x082ead70  Checkpoint                     2037
Subdaemon       9822    0x08345ed0  Aging                          2038
Subdaemon       9822    0x083a1030  Log Marker                     2039
Subdaemon       9822    0x083fc190  AsyncMV                        2040
Subdaemon       9822    0x084572f0  HistGC                         2041
Replication policy  : Manual
Replication agent is running.
Cache Agent policy  : Always
TimesTen's Cache agent is running for this data store
PL/SQL enabled.
------------------------------------------------------------------------

ttStatusユーティリティによって表示される情報には、インストール済インスタンスのTimesTenデータベースごとに用意されるTimesTen Cacheに関する次のような情報が含まれます。

- TimesTenデータベースに接続されているキャッシュ・エージェント・プロセス・スレッドの名前

- TimesTenデータベースに接続されているレプリケーション・エージェント・プロセス・スレッドの名前

- キャッシュ・エージェントが実行されているかどうかに関するステータス

- レプリケーション・エージェントが実行されているかどうかに関するステータス

- キャッシュ・エージェント起動ポリシー

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

ttStatusユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatusに関する説明を参照してください。

キャッシュ・エージェントおよびレプリケーションの接続

キャッシュ・エージェントからOracle Databaseへの接続が失敗すると、キャッシュ・エージェントが10秒ごとに接続を試行します。キャッシュ・エージェントがOracle Databaseに接続できない場合は、10分後にキャッシュ・エージェントが再起動します。この動作は永久に繰り返されます。

レプリケーション・エージェントからOracle Databaseへの接続が失敗すると、レプリケーション・エージェントが120秒後にOracle Databaseへの再接続を試行します。120秒後に再接続できない場合、レプリケーション・エージェントは停止し、再起動しません。

Oracle DatabaseでFast Application Notification(FAN)が有効化されている場合、キャッシュ・エージェントおよびレプリケーション・エージェントは、接続が失敗したことを知らせる通知を即座に受け取ります。FANが有効化されていない場合、これらのエージェントは、接続の失敗に気付かずに、TCPタイムアウト発生まで待機してしまう可能性があります。

Oracle DatabaseでFANおよびTransparent Application Failover (TAF)とともにOracle Real Application Clusters (Oracle RAC)が有効化されている場合は、TAFによって新規Oracle Databaseインスタンスへの接続が管理されます。第11章「Oracle RAC環境でのTimesTen Application-Tier Database Cacheの使用」を参照してください。

キャッシュ・グループおよびキャッシュ・グリッドの監視

次の項では、キャッシュ・グリッドおよびキャッシュ・グループに関する情報を取得する方法およびキャッシュ・グループ処理のステータスを監視する方法について説明します。

- ttIsqlユーティリティのcachegroupsコマンドの使用

- キャッシュ・グループでの自動リフレッシュ処理の監視

- AWTキャッシュ・グループの監視

- キャッシュ・グリッド情報の取得

- キャッシュされたOracle Database表に対して発行されたDDL文の追跡

ttIsqlユーティリティのcachegroupsコマンドの使用

TimesTenデータベースのキャッシュ・グループに関する情報を取得するには、ttIsqlユーティリティのcachegroupsコマンドを使用します。

例7-3 ttIsqlユーティリティのcachegroupsコマンド

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> cachegroups;

Cache Group CACHEUSER.RECENT_SHIPPED_ORDERS:

Cache Group Type: Read Only
Autorefresh: Yes
Autorefresh Mode: Incremental
Autorefresh State: On
Autorefresh Interval: 1440 Minutes
Autorefresh Status: ok
Aging: Timestamp based uses column WHEN_SHIPPED lifetime 30 days cycle 24 hours on

Root Table: ORATT.ORDERS
Table Type: Read Only

Cache Group CACHEUSER.SUBSCRIBER_ACCOUNTS:

Cache Group Type: Asynchronous Writethrough global (Dynamic)
Autorefresh: No
Aging: LRU on

Root Table: ORATT.SUBSCRIBER
Table Type: Propagate

Cache Group CACHEUSER.WESTERN_CUSTOMERS:

Cache Group Type: User Managed
Autorefresh: No
Aging: No aging defined

Root Table: ORATT.ACTIVE_CUSTOMER
Where Clause: (oratt.active_customer.region = 'West')
Table Type: Propagate

Child Table: ORATT.ORDERTAB
Table Type: Propagate

Child Table: ORATT.ORDERDETAILS
Where Clause: (oratt.orderdetails.quantity >= 5)
Table Type: Not Propagate

Child Table: ORATT.CUST_INTERESTS
Table Type: Read Only

3 cache groups found.

ttIsqlユーティリティのcachegroupsコマンドによって表示される情報は、次のとおりです。

- キャッシュ・グループが動的であるかグローバルであるかを含むキャッシュ・グループ・タイプ

- 自動リフレッシュ属性(モード、状態、間隔)およびステータス(適用可能な場合)

- エージング・ポリシー(適用可能な場合)

- ルート表の名前および(適用可能な場合は)子表の名前

- キャッシュ表のWHERE句(適用可能な場合)

- キャッシュ表属性(読取り専用、伝播、伝播なし)

ttIsqlユーティリティのcachegroupsコマンドの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttIsqlに関する説明を参照してください。

キャッシュ・グループでの自動リフレッシュ処理の監視

キャッシュ・グループの自動リフレッシュ処理に関する情報および統計を取得するために、TimesTenではいくつかのメカニズムを用意しています。Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドの自動リフレッシュ・キャッシュ・グループの監視に関する説明を参照してください。

AWTキャッシュ・グループの監視

AWTキャッシュ・グループの処理に関する情報および統計を取得するために、TimesTenではいくつかのメカニズムを用意しています。Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドのAWTパフォーマンスの監視に関する説明を参照してください。

AWTキャッシュ・グループのトランザクション・ログ・ファイルのしきい値の設定

レプリケーション・エージェントは、トランザクション・ログを使用して、AWTキャッシュ・グループのキャッシュ表に対するどの更新がキャッシュされたOracle Database表に伝播され、どの更新が伝播されていないかを判別します。障害が原因で更新がOracle Databaseに自動的に伝播されていない場合は、トランザクション・ログ・ファイルがディスクに蓄積されます。伝播を妨げる障害の例としては、レプリケーション・エージェントが実行されていない場合、Oracle Databaseサーバーが使用不可能である場合などがあります。トランザクション・ログ・ファイルの蓄積の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの蓄積の監視に関する説明を参照してください。

キャッシュ・マネージャ・ユーザーとしてttCacheAWTThresholdSet組込みプロシージャをコールして、TimesTenがAWTキャッシュ・グループのキャッシュ表に対する更新の追跡を停止する前に蓄積できるトランザクション・ログ・ファイルの数のしきい値を設定します。デフォルトのしきい値は0です。この組込みプロシージャをコールできるのは、TimesTenデータベースにAWTキャッシュ・グループが含まれている場合のみです。

このしきい値を超えた後は、UNLOAD CACHE GROUP文の後にLOAD CACHE GROUP文を続けて使用することによって、キャッシュ表を、キャッシュされたOracle Database表と手動で同期化する必要があります。トランザクション・ログ・ファイルに、キャッシュされたOracle Database表に伝播されなかった更新が含まれている場合も、TimesTenによってそのファイルが消去されることがあります。

例7-4 AWTキャッシュ・グループのトランザクション・ログ・ファイルのしきい値の設定

この例では、AWTキャッシュ・グループのキャッシュ表に対する更新を含むトランザクション・ログ・ファイルの数が5を超えると、更新の追跡が停止され、伝播されない更新が含まれている可能性のあるトランザクション・ログ・ファイルが消去されることがあります。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheAWTThresholdSet(5);

現在のトランザクション・ログ・ファイルのしきい値設定を確認するには、ttCacheAWTThresholdGet組込みプロシージャをコールします。

Command> CALL ttCacheAWTThresholdGet;
< 5 >
Command> exit

キャッシュ・グリッド情報の取得

次のメカニズムを使用して、任意のキャッシュ・グリッドおよびそのグリッド・メンバーに関する情報を表示できます。

- 指定のキャッシュ・グリッドまたはすべての既存のキャッシュ・グリッドについて、グリッド名、キャッシュ管理ユーザー名、オペレーティング・システム・プラットフォームおよびTimesTenメジャー・リリース番号を戻すには、キャッシュ・マネージャ・ユーザーとしてttGridInfo組込みプロシージャをコールします。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttGridInfo('ttGrid');
< TTGRID, CACHEUSER, Linux Intel x86, 32-bit, 11, 2, 1 >

ttGridInfo組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttGridInfoに関する説明を参照してください。

- 指定のキャッシュ・グリッドまたはすべての既存のキャッシュ・グリッドのすべてのメンバーについて、グリッド名、メンバーID、ノード番号、ノードがグリッドにアタッチされているかどうかの表示、ホスト名、ノード名、IPアドレスおよびキャッシュ・エージェントTCP/IPポート番号を戻すには、キャッシュ・マネージャ・ユーザーとしてttGridNodeStatus組込みプロシージャをコールします。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttGridNodeStatus;
< TTGRID, 1, 1, T, sys1, TTGRID_alone1_1, 140.87.0.201, 5001, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL> >
< TTGRID, 2, 1, T, sys2, TTGRID_alone2_2, 140.87.0.202, 5002, <NULL>, <NULL>,
<NULL>, <NULL>, <NULL> >
< TTGRID, 3, 1, T, sys3, TTGRID_cacheact_3A, 140.87.0.203, 5003, T, sys4,
TTGRID_cachestand_3B, 140.87.0.204, 5004 >

ttGridNodeStatus組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttGridNodeStatusに関する説明を参照してください。

グローバルAWTキャッシュ・グループの処理の一時停止

グローバルAWTキャッシュ・グループの次の処理を一時的にブロックするには、ttGridGlobalCGSuspend組込みプロシージャを使用します。

- 動的ロード

- キャッシュ・インスタンスの削除

これらの処理を再度有効化するには、ttGridGlobalCGResume組込みプロシージャを使用します。

キャッシュされたOracle Database表に対して発行されたDDL文の追跡

キャッシュされたOracle Database表にDDL文が発行された場合、Oracle Database表に行を挿入するためにOracle Database TT_version_schema-ID_DDL_Tトリガー(versionはTimesTenの内部バージョン番号、schema-IDはキャッシュされたOracle Database表を所有するユーザーのID)が起動されたとき、そのDDL文をOracle Database TT_version_DDL_L表で追跡できます。トリガーは、キャッシュされたOracle Database表を所有するOracle Databaseユーザーごとに作成されます。DDL追跡表が1つ作成され、キャッシュされたすべてのOracle Database表に対して発行されたDDL文が格納されます。キャッシュ管理ユーザーは、TT_version_DDL_L表およびTT_version_schema-ID_DDL_Tトリガーを所有します。

キャッシュされたOracle Database表に対して発行されたDDL文を追跡できるようにするには、キャッシュ・マネージャ・ユーザーとしてttCacheDDLTrackingConfig組込みプロシージャをコールします。デフォルトでは、DDL文は追跡されません。

ttCacheDDLTrackingConfig組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheDDLTrackingConfigに関する説明を参照してください。

例7-5 キャッシュされたOracle Database表に対して発行されたDDL文の追跡の有効化

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheDDLTrackingConfig('enable');

キャッシュ管理ユーザーにRESOURCEやCREATE ANY TRIGGERなどの必要な権限のセットが付与されている場合は、TT_version_DDL_L表およびTT_version_schema-ID_DDL_Tトリガーが自動的に作成されます。DDL文の追跡が有効化されている場合、キャッシュ・グループを作成したとき、これらのOracle Databaseオブジェクトが作成されます。

Oracle Databaseデータのキャッシュを管理するために使用するOracle Databaseオブジェクトを手動で作成した場合は、キャッシュ・マネージャ・ユーザーとして、ttIsqlユーティリティのcachesqlgetコマンドにORACLE_DDL_TRACKINGオプションおよびINSTALLフラグを指定して実行する必要があります。このコマンドは、DDL文を追跡する対象のキャッシュされたOracle Database表を所有するOracle Databaseユーザーごとに実行する必要があります。このコマンドを実行すると、TT_version_DDL_L表およびTT_version_schema-ID_DDL_Tトリガーを作成するために使用するSQL*Plusスクリプトが生成されます。

スクリプトの生成後、SQL*Plusを使用してsysユーザーとしてスクリプトを実行します。

例7-6 Oracle Databaseオブジェクトを手動で作成した場合のDDL追跡表およびトリガーの作成

この例では、ttIsqlユーティリティのcachesqlgetコマンドによって生成されるSQL*Plusスクリプトは、/tmp/trackddl.sqlファイルに保存されます。キャッシュされたOracle Database表orattの所有者が、引数としてこのコマンドに渡されます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> cachesqlget ORACLE_DDL_TRACKING oratt INSTALL /tmp/trackddl.sql;
Command> exit

% sqlplus sys as sysdba
Enter password: password
SQL> @/tmp/trackddl
SQL> exit

Oracle Databaseスキーマに変更を加えるために、キャッシュされたOracle Database表に対してCREATE、DROP、ALTERなどのDDL文を発行する必要がある場合は、Oracle Databaseスキーマを変更する前に、処理対象のキャッシュ・グループを削除します。削除しないと、自動リフレッシュなどの処理が失敗する場合があります。列を追加するためにOracle Database表を変更する場合は、キャッシュ・グループを削除する必要はありません。Oracle Database表で他のDDL文を発行するには、最初に次のタスクを実行します。

1. DROP CACHE GROUP文を使用して、処理対象のOracle Database表をキャッシュするすべてのキャッシュ・グループを削除します。AWTキャッシュ・グループを削除する場合は、そのキャッシュ・グループを削除する前に、ttRepSubscriberWait組込みプロシージャを使用して、そのグループのキャッシュ表にコミットされたすべての更新をキャッシュされたOracle Database表に伝播します。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttRepSubscriberWait('_AWTREPSCHEME','TTREP','_ORACLE','sys1',-1);

2. キャッシュ・エージェントを停止します。

3. Oracle Databaseスキーマに必要な変更を加えます。

4. CREATE CACHE GROUP文を使用してキャッシュ・グループを再作成します(可能な場合)。

自動リフレッシュ・キャッシュ・グループにキャッシュされるOracle Database表を切り捨てる場合は、次のタスクを実行します。

1. ALTER CACHE GROUP文を使用して、キャッシュ・グループの自動リフレッシュ状態をPAUSEDに設定します。

2. Oracle Database表を切り捨てます。

3. WHERE句またはWITH ID句を指定せずにREFRESH CACHE GROUP文を使用して、キャッシュ・グループを手動でリフレッシュします。

キャッシュ・グループをリフレッシュすると、自動リフレッシュ処理が再開されます。

キャッシュ管理ユーザーとしてSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/cacheInfo.sqlを実行し、キャッシュされたOracle Database表で発行されたDDL文を追跡するのに使用するOracle Databaseオブジェクトに関する情報を表示します。

% cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheInfo
*************DDL Tracking Object Information  ***************
Common DDL Log Table Name: TT_05_DDL_L
DDL Trigger Name: TT_05_315_DDL_T
Schema for which DDL Trigger is tracking: ORATT
Number of cache groups using the DDL Trigger: 10
****************************

キャッシュされたOracle Database表を所有するOracle Databaseユーザーごとに戻される情報には、DDL追跡表の名前、その対応するDDLトリガーの名前、DDLトリガーが関連付けられているユーザーの名前、DDLトリガーに関連付けられているユーザーが所有する表をキャッシュするキャッシュ・グループの数などがあります。

特定の表が複数のグリッド・メンバーにキャッシュされる場合、各グリッド・メンバーがキャッシュ・グループの数にカウントされます。アクティブ・スタンバイ・ペアは、1つのグリッド・メンバーとしてカウントされます。1つのキャッシュ・グループに複数のキャッシュ表が含まれている場合、DDLトリガーに関連付けられているユーザーが所有する各キャッシュ表がキャッシュ・グループの数にカウントされます。

Oracle Databaseオブジェクトによるキャッシュ環境の管理

自動リフレッシュ・キャッシュ・グループの場合、TimesTenはキャッシュ・グループの各キャッシュ表についてOracle Database内に変更ログ表とトリガーを作成します。トリガーは、キャッシュされたOracle Database表で挿入、更新または削除の各処理がコミットされるたびに起動されます。そのトリガーは、更新行の主キーを変更ログ表に記録します。キャッシュ・エージェントは、定期的に変更ログ表で更新キーをスキャンし、変更ログ表をキャッシュされたOracle Database表と結合して最新の更新のスナップショットを取得します。

注意:
2つ以上のTimesTenデータベースで同じOracle表をキャッシュしている場合のパフォーマンス考慮事項については、「2つ以上のTimesTenデータベースにおける同じOracle表のキャッシュ」を参照してください。

「データのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成」の説明に従って、AUTOREFRESH MODE INCREMENTALキャッシュ・グループ属性でキャッシュ・グループを作成するときは、自動リフレッシュ・ライトスルー処理に使用するOracle Databaseオブジェクトを、TimesTenが自動的に作成できます。また、セキュリティを確保するために、これらのオブジェクトの自動作成に必要なRESOURCEおよびCREATE ANY TRIGGER権限をキャッシュ管理ユーザーに付与しない場合は、キャッシュ・グリッド処理またはキャッシュ・グループ処理を実行する前に、これらのオブジェクトを手動で作成することもできます(「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」を参照)。

Oracle Databaseオブジェクトを自動または手動で作成するには、次の処理を実行する必要があります。

- 「Oracle Databaseユーザーの作成」の説明に従って、Oracle Databaseにキャッシュ管理ユーザーを作成します。

- 「キャッシュ管理ユーザーの名前およびパスワードの設定」の説明に従って、TimesTenデータベースにキャッシュ管理ユーザーの名前およびパスワードを設定します。

- 「キャッシュ・エージェントの管理」の説明に従って、キャッシュ・エージェントを起動します。

TimesTenは、キャッシュ管理ユーザーごとに次のOracle Database表を作成します(ここで、versionはTimesTenの内部バージョン番号、object-IDはキャッシュされたOracle Database表のIDです)。

表名

説明

TT_version_AGENT_STATUS

最初のキャッシュ・グループの作成時に作成されます。自動リフレッシュ・キャッシュ・グループにキャッシュされた各Oracle Database表に関する情報を保存します。

TT_version_AR_PARAMS

キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュ管理ユーザーの表領域が一杯になったときに実行するアクションを保存します。

TT_version_CACHE_STATS

キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。

TT_version_DATABASES

キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。Oracle DatabaseからデータをキャッシュするすべてのTimesTenデータベースの自動リフレッシュ・ステータスを保存します。

TT_version_DB_PARAMS

キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュ・エージェント・タイムアウト、使用不可能なキャッシュ・グループのリカバリ方法およびキャッシュ管理ユーザーの表領域使用量しきい値を保存します。

TT_version_DBSPECIFIC_PARAMS

内部使用。

TT_version_DDL_L

キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュされたOracle Database表に対して発行されたDDL文を追跡します。

TT_version_DDL_TRACKING

キャッシュ管理ユーザーの名前およびパスワードが設定されたときに作成されます。キャッシュされたOracle Database表に対するDDL文の追跡が有効であるか無効であるかを示すフラグを保存します。

TT_version_REPACTIVESTANDBY

最初のAWTキャッシュ・グループの作成時に作成されます。アクティブ・スタンバイ・ペアのレプリケーション・スキームでレプリケートされるAWTキャッシュ・グループのキャッシュ表を含むTimesTenデータベースの状態およびロールを追跡します。

TT_version_REPPEERS

最初のAWTキャッシュ・グループの作成時に作成されます。キャッシュされたOracle Database表に非同期に伝播されたキャッシュ表に対する最終更新の時間およびコミット順序番号を追跡します。

TT_version_SYNC_OBJS

最初のキャッシュ・グループの作成時に作成されます。

TT_version_USER_COUNT

最初のキャッシュ・グループの作成時に作成されます。各キャッシュされたOracle Database表に関する情報を保存します。

TT_version_object-ID_L

自動リフレッシュ・キャッシュ・グループを作成すると、そのキャッシュ・グループにキャッシュされるOracle Database表ごとに変更ログ表が1つ作成されます。キャッシュされたOracle Database表に対する更新を追跡します。

TimesTenは、キャッシュ管理ユーザーごとに次のOracleトリガーを作成します(ここで、versionはTimesTenの内部バージョン番号、object-IDはキャッシュされたOracle Database表のID、schema-IDはキャッシュされたOracle Database表を所有するユーザーのIDです)。

トリガー名

説明

TT_version_REPACTIVESTANDBY_T

最初のAWTキャッシュ・グループの作成時に作成されます。起動されると、TT_version_REPACTIVESTANDBY表に行を挿入します。

TT_version_object-ID_T

自動リフレッシュ・キャッシュ・グループを作成すると、そのキャッシュ・グループにキャッシュされるOracle Database表ごとにトリガーが1つ作成されます。キャッシュされたOracle Database表に対して挿入、削除または更新処理が発行されるたびに起動され、TT_version_object-ID_L変更ログ表で処理を追跡します。

TT_version_schema-ID_DDL_T

キャッシュされたOracle Database表を所有するユーザーごとに1つ存在します。DDL文の追跡を有効にした後、キャッシュ・グループを作成すると作成されます。キャッシュされたOracle Database表に対してDDL文が発行されるたびに起動され、TT_version_DDL_L表で処理を追跡します。

TimesTenは、timestenユーザー用に次のOracle Database表を作成します。

表名

説明

TT_GRIDID

SQL*PlusスクリプトinitCacheGlobalSchema.sqlを実行すると作成されます。最近作成したキャッシュ・グリッドに割り当てられているID番号を保存します。

TT_GRIDINFO

SQL*PlusスクリプトinitCacheGlobalSchema.sqlを実行すると作成されます。すべての既存のキャッシュ・グリッドのグリッド名、グリッドIDおよびキャッシュ管理ユーザー名を保存します。

TimesTenは、キャッシュ管理ユーザーごとに次のOracle Database表を作成します(ここで、versionはTimesTenの内部バージョン番号、grid-IDはキャッシュ・グリッドのID番号です)。

表名

説明

TT_version_grid-name_grid-IDCGNODEID

グリッドが作成されると、キャッシュ・グリッドごとに1つの表が作成されます。オペレーティング・システムの名前、そのバージョンおよびTimesTenリリース番号を保存します。

TT_version_grid-name_grid-IDCGNODEINFO

グリッドが作成されると、キャッシュ・グリッドごとに1つの表が作成されます。すべてのアタッチ済グリッド・メンバーのホスト名、メンバー名、IPアドレスおよびキャッシュ・エージェントTCP/IPポートを保存します。

TT_version_grid-name_grid-IDCGGROUPDEFS

グリッドが作成されると、キャッシュ・グリッドごとに1つの表が作成されます。キャッシュ・グリッドに関連付けられているスタンドアロンTimesTenデータベースまたはアクティブ・スタンバイ・ペアのすべてのグローバル・キャッシュ・グループのキャッシュ・グループ名、所有者、参照カウントおよびSQLテキストを保存します。

TimesTenデータベースでの自動リフレッシュ処理の失敗による影響

変更ログ表は、自動リフレッシュ・キャッシュ・グループにキャッシュされるOracle Database表ごとに、キャッシュ管理ユーザーの表領域に作成されます。これらのキャッシュされたOracle Database表に対して更新処理が発行されるたびに、対応する変更ログ表に行が1つ挿入され、これにより、次回の増分自動リフレッシュ・サイクルにおいて、TimesTenキャッシュ表に適用する必要がある更新を常時監視できるようになります。TimesTenは、キャッシュ表に適用された変更ログ表の行を定期的に削除します。

1つのOracle Database表をTimesTenデータベース内の複数のキャッシュ・グループに、キャッシュすることはできません。ただし、1つのOracle Database表を複数のTimesTenデータベースにキャッシュすることはできます。これによって、1つのOracle Database表が複数のTimesTenキャッシュ表に対応することになります。Oracle Database表がキャッシュされる1つ以上のTimesTenデータベースでキャッシュ・エージェントが実行されていないために、キャッシュされたOracle Database表に対する更新が対応するすべてのキャッシュ表に自動的にリフレッシュされない場合、それぞれの変更ログ表の行はデフォルトでは削除されません。キャッシュ・エージェントが明示的に停止されたか、または起動されていなかったため、あるいはデータベースが破棄されたか、データベースがあるインストール済インスタンスが停止しているために、キャッシュ・エージェントが特定のTimesTenデータベースで実行されない場合があります。この結果、変更ログ表に行が蓄積し、キャッシュ・エージェントが実行されているTimesTenデータベースのキャッシュ表に対する自動リフレッシュ処理のパフォーマンスが低下します。また、キャッシュ管理ユーザーの表領域が一杯になる場合もあります。

キャッシュ・エージェント・タイムアウトを設定すると、行が変更ログ表に蓄積されて削除されない状態を回避できます。TimesTenデータベースでキャッシュ・エージェントが実行されておらず、キャッシュ・エージェント・タイムアウトを設定している場合、変更ログ表の行を削除するには、次の基準が満たされている必要があります。

- Oracle Database表は、複数のTimesTenデータベース内の自動リフレッシュ・キャッシュ・グループにキャッシュされています。

- キャッシュ・エージェントは、TimesTenデータベースの少なくとも1つで実行されていますが、別のデータベースでは実行されていません。

- 変更ログ表の行が、キャッシュ・エージェントが実行されているすべてのTimesTenデータベースのキャッシュ表に適用されています。

- キャッシュ・エージェントが実行されていないデータベースで、エージェント・プロセスが停止したままとなり、その期間がキャッシュ・エージェント・タイムアウトを超えています。

Oracle Databaseからのデータをキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。AgentTimeout文字列をParamパラメータに渡し、タイムアウト設定を数値文字列としてValueパラメータに渡します。キャッシュ・エージェント・タイムアウトの設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

例7-7 キャッシュ・エージェント・タイムアウトの設定

次の例では、キャッシュ・エージェント・タイムアウトを900秒(15分)に設定しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('AgentTimeout',,,'900');

現在のキャッシュ・エージェント・タイムアウト設定を確認するには、AgentTimeout文字列のみをParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('AgentTimeout');
< AgentTimeout, <NULL>, <NULL>, 900 >

デフォルトのキャッシュ・エージェント・タイムアウトは0秒であり、変更ログ表の行はすべてのキャッシュ表に適用されるまで削除されません。キャッシュ・エージェント・タイムアウトを1から600秒のいずれかの値に設定すると、タイムアウトは600秒に設定されます。キャッシュ・エージェント・タイムアウトは、同じOracle Databaseからデータをキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースに適用されます。

適切なキャッシュ・エージェント・タイムアウト設定を決定するときは、TimesTenデータベースをメモリーにロードするために要する時間、キャッシュ・エージェント・プロセスを開始するための時間、ネットワーク停止の可能性がある期間および計画メンテナンス作業の所要見積時間を考慮してください。

各TimesTenデータベースおよびそのすべての自動リフレッシュ・キャッシュ・グループには自動リフレッシュ・ステータスがあり、変更ログ表から削除された行がキャッシュ・グループのキャッシュ表に適用されたかどうかを判別できるようになっています。変更ログ表から行が削除されたものの、データベース上のキャッシュ・エージェントがキャッシュ・エージェント・タイムアウトを超える期間停止していたために、それがキャッシュ表に適用されなかった場合、そのキャッシュ表はキャッシュされたOracle Database表と同期化されなくなります。キャッシュされたOracle Database表に対する以後の更新は、付随するキャッシュ・グループがリカバリされるまで、キャッシュ表に自動的にはリフレッシュされません。

自動リフレッシュ・キャッシュ・グループの有効なステータスは、次のとおりです。

- ok: 変更ログ表から削除されたすべての行がキャッシュ表に適用されました。増分自動リフレッシュ処理が引き続きキャッシュ・グループに対して実行されます。

- dead: 変更ログ表から削除された行の一部がキャッシュ表に適用されなかったため、キャッシュ表はキャッシュされたOracle Database表と同期化されません。キャッシュ・グループに対する自動リフレッシュ処理は停止し、キャッシュ・グループがリカバリするまで再開されません。

- recovering: キャッシュ・グループはリカバリ中です。リカバリが完了すると、キャッシュ表がキャッシュされたOracle Database表と同期化され、キャッシュ・グループの自動リフレッシュ・ステータスがokに設定され、増分自動リフレッシュ処理がキャッシュ・グループで再開されます。

TimesTenデータベースの有効な自動リフレッシュ・ステータスは、次のとおりです。

- alive: すべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがOKに設定されています。

- dead: すべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがdeadに設定されています。

- recovering: 自動リフレッシュ・キャッシュ・グループの少なくとも1つの自動リフレッシュ・ステータスがrecoveringに設定されています。

TimesTenデータベース上のキャッシュ・エージェントがキャッシュ・エージェント・タイムアウトを超える期間停止していると、そのTimesTenデータベースの自動リフレッシュ・ステータスはdeadに設定されます。また、そのデータベース内のすべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがdeadに設定されます。

SNMPトラップを有効にしている場合、データベースの自動リフレッシュ・ステータスがdeadに設定されると、トラップがスローされます。

キャッシュ・グループおよびその付随するTimesTenデータベースの自動リフレッシュ・ステータスを確認するには、キャッシュ・マネージャ・ユーザーとしてttCacheDbCgStatus組込みプロシージャをコールします。キャッシュ・グループの所有者をcgOwnerパラメータに、キャッシュ・グループの名前をcgNameパラメータにそれぞれ渡します。

例7-8 キャッシュ・グループおよびTimesTenデータベースの自動リフレッシュ・ステータスの確認

次の例では、データベースの自動リフレッシュ・ステータスはaliveとなっており、cacheuser.customer_orders読取り専用キャッシュ・グループの自動リフレッシュ・ステータスはokとなっています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheDbCgStatus('cacheuser','customer_orders');
< alive, ok >

データベースの自動リフレッシュ・ステータスのみを表示し、特定のキャッシュ・グループの自動リフレッシュ・ステータスは表示しないようにするには、パラメータを指定せずにttCacheDbCgStatusをコールします。

Command> CALL ttCacheDbCgStatus;
< dead, <NULL> >

キャッシュ・グループの自動リフレッシュ・ステータスがokである場合、そのキャッシュ表は自動リフレッシュ間隔に基づいて自動的にリフレッシュされます。データベースの自動リフレッシュ・ステータスがaliveである場合、そのデータベースのすべての自動リフレッシュ・キャッシュ・グループの自動リフレッシュ・ステータスがokとなります。

キャッシュ・グループの自動リフレッシュ・ステータスがdeadである場合、そのキャッシュ表はキャッシュされたOracle Database表に対する更新がコミットされても、自動的にはリフレッシュされません。キャッシュ表をキャッシュされたOracle Database表と再同期化するには、キャッシュ・グループをリカバリする必要があります。

自動リフレッシュ・ステータスがdeadになっているキャッシュ・グループ用にリカバリ方法を構成できます。

Oracle Databaseからのデータをキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。DeadDbRecovery文字列をParamパラメータに渡し、リカバリ方法を文字列としてValueパラメータに渡します。deadとなっているキャッシュ・グループのリカバリ方法の設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

有効なリカバリ方法は次のとおりです。

- Normal: キャッシュ・エージェントを起動すると、自動リフレッシュ・ステータスがdeadであるキャッシュ・グループに対して完全自動リフレッシュ処理が実行され、キャッシュ・グループがリカバリされます。これがデフォルトのリカバリ方法です。

- Manual: 自動リフレッシュ・ステータスがdeadとなっている明示的にロードされる各キャッシュ・グループをリカバリするには、キャッシュ・エージェントの起動後に、REFRESH CACHE GROUP文を発行する必要があります。
自動リフレッシュ・ステータスがdeadとなっている各動的キャッシュ・グループをリカバリするには、キャッシュ・エージェントの起動後、REFRESH CACHE GROUP文またはUNLOAD CACHE GROUP文を発行する必要があります。

- None: 自動リフレッシュ・ステータスがdeadとなっているキャッシュ・グループをリカバリするには、キャッシュ・エージェントの起動後、そのグループを削除してから再作成する必要があります。

例7-9 deadとなっているキャッシュ・グループのリカバリ方法の構成

次の例では、自動リフレッシュ・ステータスがdeadとなっているキャッシュ・グループのリカバリ方法をManualに設定しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('DeadDbRecovery',,,'Manual');

deadとなっているキャッシュ・グループの現在のリカバリ方法を確認するには、DeadDbRecovery文字列のみをParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('DeadDbRecovery');
< DeadDbRecovery, <NULL>, <NULL>, manual >

このリカバリ方法は、同じOracle Databaseからデータをキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースのすべての自動リフレッシュ・キャッシュ・グループに適用されます。

SNMPトラップを有効にしている場合、キャッシュ・エージェントが起動し、リカバリ方法をManualまたはNoneに設定すると、トラップがスローされ、REFRESH CACHE GROUPやDROP CACHE GROUPなどの文を手動で発行して、データベース内で自動リフレッシュ・ステータスがdeadとなっているキャッシュ・グループをリカバリするよう警告されます。

キャッシュ・グループがリカバリ・プロセスを開始すると、その自動リフレッシュ・ステータスがdeadからrecoveringに変更され、付随するTimesTenデータベースのステータスが現在deadである場合にはrecoveringに変更されます。

キャッシュ・グループのリカバリが完了すると、その自動リフレッシュ・ステータスがrecoveringからokに変更されます。すべてのキャッシュ・グループがリカバリされ、それらの自動リフレッシュ・ステータスがokであると、付随するTimesTenデータベースのステータスがrecoveringからaliveに変更されます。

リフレッシュする更新が少量で、かつキャッシュ表に多数の行が存在する場合、完全自動リフレッシュ処理には増分自動リフレッシュ処理よりも多くのシステム・リソースが必要となります。メンテナンス作業のためにTimesTenデータベースを停止する必要があり、その停止中、自動リフレッシュ・キャッシュ・グループにキャッシュされるOracle Database表に対して実行される更新の量が少ないと予測される場合は、一時的にキャッシュ・エージェント・タイムアウトを0に設定してみることをお薦めします。データベースが稼働状態に戻り、キャッシュ・エージェントが再起動すると、増分自動リフレッシュ処理が自動リフレッシュ・キャッシュ・グループのキャッシュ表で再開されます。付随するキャッシュ・グループの自動リフレッシュ・ステータスがokからdeadに変更されなかったため、完全自動リフレッシュ処理が回避されますので、付随するキャッシュ・グループのリカバリ・プロセスは必要ありません。データベースが稼働状態に戻り、キャッシュ・エージェントが起動された後、キャッシュ・エージェント・タイムアウトを元の値に戻します。

自動リフレッシュ・キャッシュ・グループで使用されているOracle Databaseオブジェクトの削除

自動リフレッシュ・キャッシュ・グループを含むTimesTenデータベースが使用できなくなっても、自動リフレッシュ処理の実装に使用される変更ログ表やトリガーなどのOracle Databaseオブジェクトは引き続きOracle Databaseに存在します。TimesTenデータベースは、たとえば、TimesTenシステムがオフラインになったり、自動リフレッシュ・キャッシュ・グループを削除せずにデータベースを破棄すると使用不可能になります。

TimesTenデータベースが使用されなくなっても、自動リフレッシュ・キャッシュ・グループを含んでいる場合は、自動リフレッシュ処理の実装に使用されるOracle DatabaseオブジェクトもOracle Databaseに引き続き存在します。行が引き続き変更ログ表に蓄積されます。これは、他のTimesTenデータベースに対する自動リフレッシュのパフォーマンスに影響を与えます。このため、使用不可能になったり破棄されたTimesTenデータベースに関連付けられているこれらのOracle Databaseオブジェクトを削除することをお薦めします。

自動リフレッシュ処理の実装に使用されるOracle Databaseオブジェクトを削除するには、キャッシュ管理ユーザーとしてSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/cacheCleanUp.sqlを実行します。TimesTenシステムのホスト名およびTimesTenデータベースのパス名を引数としてcacheCleanUp.sqlスクリプトに渡します。TimesTenシステムのホスト名およびデータベース・パス名を確認するには、キャッシュ管理ユーザーとしてcacheInfo.sqlスクリプトを実行します。また、cacheInfo.sqlスクリプトは、自動リフレッシュ処理の実装に使用されるオブジェクトがOracle Databaseに存在するかどうかを確認する場合にも使用できます。

例7-10 自動リフレッシュ・キャッシュ・グループのOracle Databaseオブジェクトの削除

次の例では、TimesTenデータベースを削除した後も、TimesTenデータベースにキャッシュ表oratt.customerおよびoratt.ordersを含む読取り専用キャッシュ・グループcustomer_ordersが1つ存在しています。cacheCleanUp.sqlスクリプトは、この2つのキャッシュ表に関連付けられている変更ログ表およびトリガーを削除します。

% cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheCleanUp "sys1" "/users/OracleCache/alone1"

*****************************OUTPUT**************************************
Performing cleanup for object_id: 69959 which belongs to table : CUSTOMER
Executing: delete from tt_05_agent_status where host = sys1 and datastore =
/users/OracleCache/alone1 and object_id = 69959
Executing: drop table tt_05_69959_L
Executing: drop trigger tt_05_69959_T
Executing: delete from tt_05_user_count where object_id = object_id1
Performing cleanup for object_id: 69966 which belongs to table : ORDERS
Executing: delete from tt_05_agent_status where host = sys1 and datastore =
/users/OracleCache/alone1 and object_id = 69966
Executing: drop table tt_05_69966_L
Executing: drop trigger tt_05_69966_T
Executing: delete from tt_05_user_count where object_id = object_id1
**************************************************************************

キャッシュ管理ユーザーの表領域の監視

次の各項ではキャッシュ管理ユーザーの表領域を管理する方法を説明します。

- 表領域の変更ログ表の最適化

- 表領域使用量通知の受信

- 一杯になった表領域のリカバリ

表領域の変更ログ表の最適化

自動リフレッシュ・キャッシュ・グループの変更ログ表を長期間にわたって使用したり過度なワークロードを与えたりすると、表領域が断片化する場合があります。表領域が劣化して変更ログ表が断片化するのを防ぐために、TimesTenは、領域の合計サイズに対する使用済の領域の割合として、変更ログ表の断片化の比率を計算します。この割合が定義されたしきい値を下回ると、TimesTenは、メッセージをログに記録して変更ログ表の最適化が必要であることを示すアラートを通知し、SNMPトラップが有効である場合は、SNMPトラップttCacheAutorefreshLogSpaceDeFragDetectedTrapをスローします。デフォルトでは、このしきい値は40%に設定されています。ttCacheConfig組込みプロシージャにより設定する断片化しきい値を構成できます。

注意:
メッセージは、ユーザーおよびサポート・エラー・ログに記録されます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の情報メッセージの変更に関する説明を参照してください。

断片化しきい値を設定するには、Oracle DatabaseのデータをキャッシュするいずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。AutoRefreshLogFragmentationWarningPCT文字列をParamパラメータに渡し、しきい値設定を数値文字列としてValueパラメータに渡します。

注意:
断片化しきい値の設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

例7-11 断片化しきい値の設定

次の例では、断片化しきい値が50%に設定されています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('AutoRefreshLogFragmentationWarningPCT',,,'50');
< AutoRefreshLogFragmentationWarningPCT, <NULL>, <NULL>, 50 >
1 row found.

現在の断片化しきい値の設定を確認するには、AutoRefreshLogFragmentationWarningPCT文字列をParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('AutoRefreshLogFragmentationWarningPCT');
< AutoRefreshLogFragmentationWarningPCT, <NULL>, <NULL>, 50 >

最適化を自動で実行するかまたは手動で開始するかのいずれかにTimesTenを構成できます。前述の割合が断片化しきい値を下回ったときに実行するアクションを構成するには、次のようにして、AutoRefreshLogDeFragmentAction文字列をParamパラメータに渡し、該当するアクションをValueパラメータで指定してttCacheConfig組込みプロシージャをコールします。

注意:
最適化アクションの設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

- 手動:これがデフォルトです。変更ログ表を最適化するためのアクションは実行されません。ttCacheAutoRefreshLogDeFrag組込みプロシージャを実行して、手動で最適化を行う必要があります。詳細は、「自動リフレッシュ・キャッシュ・グループ用の変更ログ表の手動による最適化」を参照してください。

- Compact: TimesTenが変更ログ表をデフラグします。

- CompactAndReclaim: TimesTenが変更ログ表を最適化し、領域を再生します。

注意:
領域を再生すると変更ログ表が短時間ロックされ、実表への書込みが一時的に停止されます。

例7-12 断片化のときに実行するアクションの構成

次の例では、アクションがCompactAndReclaimに設定されているため、断片化の割合がしきい値を下回ったときに、TimesTenは変更ログ表を最適化して領域を再生します。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('AutoRefreshLogDeFragmentAction',,,'CompactAndReclaim');
< AutoRefreshLogDeFragmentAction, <NULL>, <NULL>, compactandreclaim >
1 row found.

現在の断片化しきい値の設定を確認するには、AutoRefreshLogDeFragmentAction文字列をParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('AutoRefreshLogDeFragmentAction');
< AutoRefreshLogDeFragmentAction , <NULL>, <NULL>, compactandreclaim >

表領域の断片化の比率およびttCacheAutorefreshStatsGet組込みプロシージャから次の列が返される最適化処理が最後に実行されたタイミングを確認できます。

- AutoRefreshLogFragmentationPCT: 表領域の現在の断片化の比率。

- AutoRefreshLogFragmentationTS: 断片化の比率が最後に計算されたときのタイムスタンプ。

- autorefLogDeFragCnt: この特定のキャッシュ・グループの表が最適化された回数。

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

自動リフレッシュ・キャッシュ・グループ用の変更ログ表の手動による最適化

変更ログ表の最適化を手動で開始するには、Oracle DatabaseのデータをキャッシュするいずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheAutoRefreshLogDeFrag組込みプロシージャをコールします。パラメータとして次の文字列のいずれかを渡します。

- Compact: 変更ログ表をデフラグします。

- CompactAndReclaim: 変更ログ表を最適化して、領域を再生します。

注意:
領域を再生すると変更ログ表が短時間ロックされ、実表への書込みが一時的に停止されます。

例7-13 変更ログ表の手動による最適化

次の例では、ユーザーがttCacheAutoRefreshLogDeFrag組込みプロシージャにCompactAndReclaimオプションを指定してコールしています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheAutoRefreshLogDeFrag('CompactAndReclaim');

表領域使用量通知の受信

表領域が一杯になるのを防ぐため、UPDATE文、INSERT文またはDELETE文などの更新処理をキャッシュされたOracle Database表に対して発行したために、キャッシュ管理ユーザーの表領域の使用量が指定のしきい値を超えた場合に、アプリケーションに警告が返されるようにTimesTenを構成できます。

Oracle Databaseからのキャッシュ表をキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。AutoRefreshLogTblSpaceUsagePCT文字列をParamパラメータに渡し、しきい値を数値文字列としてValueパラメータに渡します。しきい値はキャッシュ管理ユーザーの表領域に使用されている領域の比率であり、この値に達すると、キャッシュされたOracle Database表に更新処理を発行したときにアプリケーションに警告が返されます。キャッシュ管理ユーザーの表領域使用量警告しきい値の設定にはtblOwnerパラメータおよびtblNameパラメータを適用できないため、これらのパラメータには値を渡さないでください。

キャッシュ・マネージャ・ユーザーがキャッシュ管理ユーザーの表領域使用量警告しきい値を設定し、キャッシュ管理ユーザーがその表領域を監視して構成済のしきい値を超えたかどうかを確認できるようにするには、キャッシュ管理ユーザーにOracle Database表SYS.DBA_DATA_FILESに対するSELECT権限を付与する必要があります。

例7-14 キャッシュ管理ユーザーの表領域使用量警告しきい値の設定

次の例では、キャッシュされたOracle Database表に更新処理を発行した結果、キャッシュ管理ユーザーの表領域の使用量が80%を超えた場合には、発行元のアプリケーションに警告を返すように構成しています。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('AutoRefreshLogTblSpaceUsagePCT',,,'80');

キャッシュ管理ユーザーの表領域使用量警告しきい値の現在の設定を確認するには、AutoRefreshLogTblSpaceUsagePCT文字列のみをParamパラメータに渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('AutoRefreshLogTblSpaceUsagePCT');
< AutoRefreshLogTblSpaceUsagePCT, <NULL>, <NULL>, 80 >

キャッシュ管理ユーザーのデフォルトの表領域使用量警告しきい値は0%であるため、表領域使用量に関係なく、アプリケーションには警告が返されません。キャッシュ管理ユーザーの表領域使用量警告しきい値は、同じOracle Databaseから表をキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースに適用されます。

SNMPトラップを有効にしている場合、キャッシュ管理ユーザーの表領域使用量が構成済のしきい値を超えると、トラップがスローされます。

一杯になった表領域のリカバリ

デフォルトでは、キャッシュ管理ユーザーの表領域が一杯になったときに、特定のキャッシュされたOracle Database表に対してUPDATE文、INSERT文またはDELETE文などのDML処理を試行すると、Oracle Databaseアプリケーションにエラーが返されます。

キャッシュ管理ユーザーの表領域が一杯になったときにTimesTenがOracle Databaseアプリケーションにエラーを返すのではなく、更新処理が特定のキャッシュされたOracle Database表に発行されたときに変更ログ表から既存の行を削除して、新規行のための領域を確保するようにTimesTenを構成できます。変更ログ表から削除した行の一部がTimesTenキャッシュ表に適用されなかった場合、次回の自動リフレッシュ・サイクルにおいて、そのキャッシュ表を含む各TimesTenデータベースのキャッシュ表に完全自動リフレッシュ処理が実行されます。

Oracle Databaseからのキャッシュ表をキャッシュする任意のTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttCacheConfig組込みプロシージャをコールします。TblSpaceFullRecovery文字列をParamパラメータに渡し、キャッシュ管理ユーザーの表領域が一杯になった場合に実行するアクションを構成するキャッシュされたOracle Database表の所有者および名前をtblOwnerパラメータおよびtblNameパラメータにそれぞれ渡し、さらに、そのアクション自体を文字列としてValueパラメータに渡します。

有効なアクションは次のとおりです。

- None: キャッシュされたOracle Database表に更新処理が発行されたときに、アプリケーションにOracle Databaseエラーを返します。これがデフォルトのアクションです。

- Reload: キャッシュされたOracle Database表に更新処理が発行されると、次回の自動リフレッシュ・サイクルにおいて、変更ログ表から行を削除し、キャッシュ表に対して完全自動リフレッシュ処理を実行します。

例7-15 キャッシュ管理ユーザーの表領域が一杯になった場合のアクションの構成

次の例では、キャッシュされたOracle Database表oratt.customerに更新処理が発行されたときにキャッシュ管理ユーザーの表領域が一杯である場合、次回の自動リフレッシュ・サイクルにおいて、変更ログ表から行が削除され、キャッシュ表に対して完全自動リフレッシュ処理が実行されます。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttCacheConfig('TblSpaceFullRecovery','oratt','customer','Reload');

キャッシュ管理ユーザーの表領域が一杯である場合に、特定のキャッシュされたOracle Database表に対して更新処理を発行すると実行される現在のアクションを確認するには、TblSpaceFullRecovery文字列のみをParamパラメータに、キャッシュされたOracle Database表の所有者および名前をtblOwnerパラメータおよびtblNameパラメータにそれぞれ渡してttCacheConfigをコールします。

Command> CALL ttCacheConfig('TblSpaceFullRecovery','oratt','customer');
< TblSpaceFullRecovery, ORATT, CUSTOMER, reload >

キャッシュ管理ユーザーの表領域が一杯である場合に、キャッシュされたOracle Database表に対して更新処理を発行すると実行されるアクションは、同じOracle Databaseから表をキャッシュし、かつ同じキャッシュ管理ユーザー名が設定されているすべてのTimesTenデータベースに適用されます。

SNMPトラップを有効にしている場合、キャッシュされたOracle Database表に対して更新処理を発行し、キャッシュ管理ユーザーの表領域が一杯であると、トラップがスローされます。

グリッド・ノードの障害後のリカバリ

スタンドアロン・データベース・グリッド・メンバーに障害が発生した場合、キャッシュ・エージェント起動ポリシーがmanualまたはalwaysであれば、キャッシュ・エージェントは自動的に再起動されます。グリッド・メンバーは、データベースのリカバリ時に自動的にグリッドに再アタッチされます。キャッシュ・エージェント起動ポリシーがnorestartである場合は、キャッシュ・エージェントを再起動してから、ttGridAttach組込みプロシージャをコールしてメンバーをグリッドに再アタッチする必要があります。「キャッシュ・エージェント起動ポリシーの設定」を参照してください。

スタンドアロン・データベース・グリッド・メンバーがグリッドにアタッチされていることを確認するには、ttRepStateGet組込みプロシージャをコールします。アタッチされている場合は、次の出力が表示されます。

Command> CALL ttRepStateGet;
< IDLE, AVAILABLE >
1 row found.

Oracle Clusterwareによりグリッド内のノードが管理されているときに、アクティブ・スタンバイ・ペア・グリッド・メンバーのアクティブ・データベース・ノードまたはスタンバイ・データベース・ノードに障害が発生した場合は、キャッシュ・エージェントの再起動時にグリッド・ノードが自動的にグリッドに再アタッチされます。Oracle Clusterwareによる障害の処理方法の詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の障害からのリカバリに関する説明を参照してください。

アクティブ・スタンバイ・ペア・グリッド・メンバーがOracle Clusterwareによって管理されていない場合は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のアクティブ・データベースの障害からのリカバリに関する説明またはスタンバイ・データベースの障害からのリカバリに関する説明の手順を実行します。キャッシュ・エージェント起動ポリシーがmanualまたはalwaysである場合は、データベースのリカバリ後、グリッド・ノードが自動的にグリッドに再アタッチされます。キャッシュ・エージェント起動ポリシーがnorestartである場合は、ttGridAttach組込みプロシージャをコールしてメンバーをグリッドに再アタッチします。

アクティブ・データベースが使用可能で、アクティブ・スタンバイ・ペアがグリッドにアタッチされていることを確認するには、アクティブ・データベースからttRepStateGet組込みプロシージャをコールします。

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

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

たとえば、ハードウェアの障害またはネットワークの障害が原因で、複数ノード障害が発生する場合があります。複数ノード障害の発生後、再アタッチが必要なメンバーごとに、ttGridAttach組込みプロシージャをコールします。この組込みプロシージャを、再アタッチする最後のグリッド・メンバーに対してコールするまで、各グリッド・メンバーに対する処理は失敗します。まだアタッチされていないグリッド・メンバーに対して再度ttGridAttachをコールすれば、処理が成功します。互いの状態を認識していないグリッド・メンバーでスプリットブレイン状況が発生するのを回避するためには、この順序が必須です。

キャッシュ・グループを持つデータベースのバックアップおよびリストア

キャッシュ・グループを含むデータベースは、ttBackupまたはttMigrateのいずれかのユーティリティを使用して、バックアップまたはリストアできます。

- リストア済データベースが同じバックエンドOracle Databaseに接続する場合は、ttBackupユーティリティおよびttRestoreユーティリティを使用した後に、リストア済TimesTenデータベース内のすべてのキャッシュ・グループを削除して再作成します。これらが静的キャッシュ・グループの場合は再ロードを要求される場合があります。動的キャッシュ・グループの場合は、再ロードはオプションとなります。これは、データは参照されるときにOracle Databaseからプルされるためです。

注意:
元のバックエンドOracle Databaseに接続するために別のTimesTenデータベースを使用し(これ以降は接続しません)、そのTimesTenデータベース内のすべてのキャッシュ・グループが完全に削除されなかった場合は、元のOracle Databaseに対してcacheCleanUp.sql SQL*Plusスクリプトを実行して残存オブジェクトをすべて削除します。元のTimesTenデータベースのホストとパスを指定します。

- リストア済データベースが元々接続していたデータベースとは別のバックエンドOracle Databaseに接続する場合は、次のいずれかの手順を実行します。

- ttBackupおよびttRestoreユーティリティを使用したバックアップおよびリストア

- ttMigrateユーティリティを使用したバックアップおよびリストア

ttBackupおよびttRestoreユーティリティを使用したバックアップおよびリストア

ttBackupユーティリティを使用すると、特定の時間のデータをすべて含むTimesTenデータベースがバックアップされます。そのため、これらのキャッシュ・グループを再度使用する場合、このバックアップのリストアでは、キャッシュ・グループ内のリストア済データは古く、バックエンドOracle Databaseのデータと同期しないために、追加のアクションが必要です。

注意:
これらのツールの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の移行、バックアップおよびリストアに関する説明および『Oracle TimesTen In-Memory Databaseリファレンス』のttBackupに関する説明およびttRestoreに関する説明を参照してください。

リストア済データベースが元々接続していたデータベースとは別のバックエンドOracle Databaseに接続する場合で、データベースのバックアップおよびリストアにttBackupユーティリティおよびttRestoreユーティリティを使用する場合は、次の手順を実行します。

1. ttBackupユーティリティ・コマンドを実行して、データベースおよびそのオブジェクトをバイナリ・ファイルにバックアップします。たとえば、一時記憶域として/tmp/dumpディレクトリを使用してcachealone1データベースをバックアップするには、次のように指定します。

$ ttBackup -dir /tmp/dump -connstr "DSN=cachealone1"

2. すべてのキャッシュ・グループを削除して、データベースを破棄します。データベースはキャッシュ・グループにまだ存在するため、同じまたは別の場所にリストアする前に、キャッシュ・グループを削除してデータベースを破棄します。

$ ttIsql -connstr "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttCacheStop;
Command> DROP CACHE GROUP readcache;
Command> exit;
Disconnecting...
Done.

$ ttDestroy cachealone1

3. ttRestoreユーティリティを使用してデータベースをリストアした後に、一時ディレクトリを削除します。

$ ttRestore -dir /tmp/dump -connstr "DSN=cachealone1"
Restore started ...
Restore complete

$ rm -r /tmp/dump

4. キャッシュ・グループ内でデータを再同期化するために、次の手順でキャッシュ・グループを削除して再作成する必要があります。

1. TimesTenデータベースに接続します。

2. ttRestoreユーティリティを使用してリストアされたキャッシュ・グループを削除します。データが同期していないため、エラーが表示される場合があります。

3. ttCacheUidPwdSet組込みプロシージャを使用してキャッシュ管理者ユーザー名およびパスワードを指定します。

4. キャッシュ・エージェントを起動します。

5. キャッシュ・グループを再作成し、必要があれば再ロードします。

$ ttIsql -connstr "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"

Command> DROP CACHE GROUP readcache;
Command> call ttCacheUidPwdSet('cacheuser','oracle');
Command> call ttCacheStart;
Command> CREATE READONLY CACHE GROUP readcache
> AUTOREFRESH INTERVAL 5 SECONDS
> FROM oratt.readtab
> (keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR2(32));
Command> LOAD CACHE GROUP readcache COMMIT EVERY 256 ROWS;
2 cache instances affected.

注意:
リストア済TimesTenデータベースがどのバックエンドOracle Databaseとも接続できない場合、TimesTenは読取り専用キャッシュ・グループのデータを自動リフレッシュできません。

ttMigrateユーティリティを使用したバックアップおよびリストア

ttMigrateユーティリティは、TimesTenデータベースの表および索引をバイナリ・ファイルに保存します。キャッシュ・グループが移行されてバイナリ・ファイルに含まれている場合、キャッシュ・グループの定義およびスキーマは含まれていますが、キャッシュ・グループのデータは移行されていません。

注意:
これらのツールの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の移行、バックアップおよびリストアに関する説明および『Oracle TimesTen In-Memory Databaseリファレンス』のttMigrateに関する説明を参照してください。

リストア済データベースが元々接続していたデータベースとは別のバックエンドOracle Databaseに接続する場合で、データベースのバックアップおよびリストアにttMigrateユーティリティを使用する場合は、次の手順を実行します。

1. ttMigrate -cユーティリティ・コマンドを実行して、データベースおよびそのオブジェクトをバイナリ・ファイルに保存します。

$ ttMigrate -c "DSN=cachealone1" cachealone1.ttm
...
Saving user CACHEUSER
User successfully saved.

Saving user ORATT
User successfully saved.

Saving table CACHEUSER.READTAB
Saving rows...
2/2 rows saved.
Table successfully saved.

Saving cache group CACHEUSER.READCACHE
Saving cached table ORATT.READTAB
Cache group successfully saved.

2. すべてのキャッシュ・グループを削除して、TimesTenデータベースを破棄します。

1. キャッシュ・エージェントを停止します。

2. すべてのキャッシュ・グループを削除します。エラーが報告される場合もありますが、これは無視しても差し支えありません。TimesTenデータベースを破棄する前にすべてのキャッシュ・グループを削除すると、Oracle Databaseにあるそのキャッシュ・グループのメタデータがすべて削除されます。

3. TimesTenデータベースを破棄します。

Command> call ttCacheStop;
Command> DROP CACHE GROUP readcache;
Command> exit
Disconnecting...
Done.
$ ttDestroy cachealone1

3. データベースを作成してリストアします。

1. 最初の接続リクエストでTimesTenデータベースを作成します。

2. TimesTenキャッシュ表ユーザーおよびTimesTenキャッシュ・マネージャ・ユーザーを作成します。これらのユーザーに適切な権限を付与します。

注意:
移行元のTimesTenリリースによっては、ユーザーおよび権限が移行されない場合があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttMigrateに関する説明を参照してください。

3. ttMigrate -rユーティリティ・コマンドを使用して、保存したバイナリ・ファイルからデータベースをリストアします。

$ ttIsql cachealone1
Command> CREATE USER cacheuser IDENTIFIED BY timesten;
User created.

Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE TO cacheuser;
Command> CREATE USER oratt IDENTIFIED BY timesten;
User created.

Command> exit
Disconnecting...
Done.

$ ttMigrate -r -relaxedUpgrade -cacheuid cacheuser -cachepwd oracle
-connstr "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
cachealone1.ttm
...
Restoring table CACHEUSER.READTAB
Restoring rows...
2/2 rows restored.
Table successfully restored.

Restoring cache group CACHEUSER.READCACHE
Restoring cached table ORATT.READTAB
1/1 cached table restored.
Cache group successfully restored.

4. リストアされたデータベースに接続し、キャッシュの自動リフレッシュ状態をリセットします。

1. ttIsqlを使用してTimesTenデータベースに接続します。

2. ttCacheUidPwdSet組込みプロシージャを使用してキャッシュ管理者ユーザー名およびパスワードを指定します。

3. キャッシュ・エージェントを起動します。

4. 自動リフレッシュの状態をONに設定するようキャッシュ・グループを変更します。

$ ttIsql -connstr "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> call ttCacheUidPwdSet('cacheuser','oracle');
Command> call ttCacheStart;
Command> ALTER CACHE GROUP readcache SET AUTOREFRESH STATE ON;

注意:
リストア済TimesTenデータベースがどのバックエンドOracle Databaseとも接続できない場合、TimesTenは読取り専用キャッシュ・グループのデータを自動リフレッシュできません。

キャッシュ・ユーザー名およびパスワードの変更

次の手順を実行して、TimesTenキャッシュ・マネージャ・ユーザー、コンパニオンOracleユーザーまたはキャッシュ管理ユーザーのユーザー名またはパスワードを変更します。

1. キャッシュ・マネージャ・ユーザーまたはパスワードを変更する場合は、次の手順を実行します。

注意:
TimesTenキャッシュ・マネージャ・ユーザーおよびそのコンパニオンOracleユーザーのパスワードは、いつでも変更できます。
TimesTenのキャッシュ・マネージャ・ユーザーの名前は、そのコンパニオンOracleユーザーと同じにする必要がありますが、パスワードは異なってもかまいません。キャッシュ・マネージャ・ユーザーおよびそのコンパニオンOracleユーザーの詳細は、「TimesTenユーザーの作成」を参照してください。

1. TimesTenデータベースで、キャッシュ・マネージャ・ユーザーのパスワードを変更する場合は、アクティブ・マスターでALTER USER文を使用します。

Command> ALTER USER cacheuser IDENTIFIED BY newpwd;

2. バックエンドOracle Databaseで、ALTER USER文を使用してキャッシュ・マネージャのコンパニオンOracleパスワードを変更できます。TimesTenを操作している場合、Passthrough 3を使用してこれを直接Oracle Database上で実行できます。

Command> passthrough 3;
Command> ALTER USER cacheuser IDENTIFIED BY newpwd;

注意:
コンパニオンOracleユーザーのパスワードを変更した場合は、キャッシュ・マネージャ・ユーザーとしてTimesTenデータベースに再接続して、キャッシュ・マネージャ・ユーザーおよびそのコンパニオンOracleユーザーのパスワードを指定します。

3. キャッシュ・マネージャ・ユーザーを変更する場合は、そのキャッシュ・マネージャ・ユーザーが所有するすべてのキャッシュ・グループを削除してから、既存のユーザーを削除して新しいユーザーを作成する必要があります。

注意:
または、別のユーザーをキャッシュ・マネージャ・ユーザーとして使用する場合は、そのユーザーに適切な権限があり、適切な権限を持つコンパニオンOracleユーザーがいることを確認してください。

さらに、キャッシュ・マネージャ・ユーザーには、同じ名前を持つコンパニオンOracleユーザーが必要なため、次のいずれかを実行する必要があります。

- コンパニオンOracleユーザーが所有するすべての表を削除し、ユーザーを削除してから、新しいキャッシュ・マネージャ・ユーザーと同じ名前でコンパニオンOracleユーザーを再作成します。現在のコンパニオンOracleユーザーがキャッシュ管理ユーザーの場合は、手順3に進みます。

- キャッシュ・マネージャ・ユーザーと同じ名前を持ち、同じ機能を提供する別のOracleユーザーを選択します。

キャッシュ・マネージャ・ユーザーおよびそのコンパニオンOracleユーザーの作成方法の詳細は、「TimesTenユーザーの作成」を参照してください。

4. TimesTenキャッシュ・マネージャ・ユーザーの名前またはパスワードがsys.odbc.ini (またはodbc.ini)ファイルで定義されている場合、アクティブ・マスターとスタンバイ・マスターの両方でsys.odbc.ini (またはodbc.ini)ファイルのキャッシュ・マネージャ・ユーザーの新しい名前またはパスワードを更新します。

2. キャッシュ管理ユーザーまたはそのパスワードを変更する場合は、次の手順を実行します。

1. バックエンドOracle Databaseで、ALTER USER文を使用してキャッシュ管理パスワードを変更できます。キャッシュ管理ユーザーのパスワードはいつでも変更できます。
TimesTenを操作している場合、Passthrough 3を使用してこれを直接Oracle Database上で実行できます。

Command> passthrough 3;
Command> ALTER USER cacheuser IDENTIFIED BY newpwd;

2. キャッシュ管理ユーザーを変更する場合は、Oracle Databaseでキャッシュ管理ユーザーを削除して新しいユーザーを作成する前に、そのキャッシュ管理ユーザーが管理するTimesTenデータベース上のすべてのキャッシュ・グループを最初に削除する必要があります。TimesTenでキャッシュ・グループを削除すると、そのキャッシュ・グループに関連付けられているすべてのメタデータが削除されます。
Oracle Databaseで新しいキャッシュ管理ユーザーを作成する場合、「Oracle Databaseユーザーの作成」に記載されているキャッシュ管理ユーザーの作成手順と同じ手順を実行する必要があります。

3. ttCacheUidPwdSet組込みプロシージャをアクティブ・マスター・データベースで実行することで、キャッシュ管理ユーザーの新しいユーザー名またはパスワードを設定します。

注意:
「キャッシュ管理ユーザーの名前およびパスワードを設定する」を参照してください。

Command> call ttCacheUidPwdSet('cacheuser','newpwd');

8 キャッシュ・パフォーマンス

次の各項では、キャッシュ・パフォーマンスに関する情報について説明します。

注意:

自動リフレッシュ処理の監視および自動リフレッシュ・パフォーマンスの向上の詳細は、Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドを参照してください。自動リフレッシュ・キャッシュ・グループの監視に関する説明および自動リフレッシュのパフォーマンスが悪い場合に関する説明を参照してください。

Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイドには、AWTキャッシュ・グループのパフォーマンスに関する情報も記載されています。AWTのパフォーマンスの監視に関する説明およびAWTのパフォーマンスが悪い場合に考えられる原因に関する説明を参照してください。

- 動的ロードのパフォーマンス

- AWTのスループットの向上

- 増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際のパフォーマンスの向上

- 自動リフレッシュ処理時にメモリーを再利用する際のパフォーマンスの向上

- 自動リフレッシュ・トランザクションに関する統計情報の取得

- 2つ以上のTimesTenデータベースにおける同じOracle表のキャッシュ

動的ロードのパフォーマンス

ルート表の主キー検索に基づいた動的ロードの方が、子表に対する主キー検索または子表に対する外部キー検索よりも、パフォーマンスが速くなります。詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

AWTのスループットの向上

次の方法を使用して、AWTキャッシュ・グループのスループットを向上させます。

- パラレル伝播を使用したAWTスループットの向上

- SQL配列実行を使用したAWTスループットの向上

パラレル伝播を使用したAWTスループットの向上

AWTキャッシュ・グループのスループットを向上させるために、パラレル動作でトランザクションの変更をOracle Databaseに伝播および適用する複数のスレッドを構成できます。パラレル伝播では、トランザクションの依存性に従って、AWTキャッシュ表の変更をコミット順にOracle Database表に適用します。詳細は、「Oracle Database表へのパラレル伝播の構成」を参照してください。

SQL配列実行を使用したAWTスループットの向上

デフォルトでは、AWTキャッシュ・グループは、TimesTenでの変更をOracle Databaseに適用する際にPL/SQL実行メソッドを使用します。AWTでは、すべての保留中の処理を単一のPL/SQLコレクションにまとめ、Oracle Databaseサーバーに送信して実行します。この実行メソッドは、TimesTenとOracle Databaseサーバー間で混合トランザクションおよびネットワーク待機時間が存在する場合に適しています。

TimesTenでの変更をOracle Databaseに適用するためにSQL配列実行を指定するには、CacheAWTMethod初期接続属性を使用します。このメソッドは、同じタイプの処理を繰り返す場合に適しています。たとえば、表の複数の行に影響する更新をユーザーが行う場合にSQL配列実行は非常に効果的です。更新はグループにまとめられ、一度のバッチ処理でOracle Databaseサーバーに送信されます。

次のいずれかの場合に、PL/SQL実行メソッドは、ユーザーに意識させることなく一時的にSQL配列実行モードになります。

- 長さが32761バイトを超える文。

- BINARY FLOAT、BINARY DOUBLEおよび4000バイトを超える長さのVARCHAR/VARBINARYの各データ型の列を参照する文。

注意:
ttDBConfig組込みプロシージャでCacheAwtMethodパラメータを指定して、この値を設定することもできます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDBConfigに関する説明を参照してください。

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

増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際のパフォーマンスの向上

次の各項では、大規模なトランザクションがある場合、または増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際に大規模な表に参加する場合にパフォーマンスを向上させる方法について説明します。

- 増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の大規模なトランザクションの実行の向上

- 増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の選択制限の構成

増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の大規模なトランザクションの実行の向上

ある期間において、月末、四半期末、年末のトランザクションなどのように大規模なトランザクションを実行する必要が生じる場合があります。また、短期間のうちにOracle Database内にある大量のデータを変更したり追加したりする状況が生じる場合もあります。増分自動リフレッシュ読取り専用キャッシュ・グループの場合、TimesTenは、自動リフレッシュ処理がこれらのいずれかのケースに適用されたときに、永続領域を使い切ってしまう可能性があります。このため、このような状況においては、自動リフレッシュ・トランザクション制限を構成して、大量のデータを複数の小規模なトランザクションに分割して適用し、コミットするようにできます。

ttCacheAutorefreshXactLimit組込みプロシージャを使用すると、特定の数の処理の実行後に自動リフレッシュをコミットするように指定できます。このオプションは、同じ自動リフレッシュ間隔で構成されるすべての増分自動リフレッシュ読取り専用キャッシュ・グループに適用されます。

単一のトランザクションが複数の小規模なトランザクションに分割されるため、自動リフレッシュの進行中はトランザクションの一貫性が確保できません。自動リフレッシュ・サイクルが完了すると、データに関するトランザクションの一貫性が確保されます。インスタンスの一貫性を確保するために、単一の表を持つキャッシュ・グループのみで自動リフレッシュ・トランザクション制限を設定することをお薦めします。これは、親表と子表の間のインスタンスの一貫性が保証されないためです。自動リフレッシュ・トランザクション制限の設定をオンにすると、TimesTenはインスタンスの一貫性を確保する外部キー関係を指定しません。増分自動リフレッシュ読取り専用キャッシュ・グループに対する自動リフレッシュ・トランザクション制限の設定をオフにすると、インスタンスの一貫性とトランザクションの一貫性の両方が再度確保されます。

注意:
アクティブ・スタンバイ・ペアを使用している場合は、アクティブ・マスターとスタンバイ・マスターの両方で同じ値でttCacheAutorefreshXactLimit組込みプロシージャをコールする必要があります。

ttCacheAutorefreshXactLimitの使用

注意:
構文、返される結果などの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のttCacheAutorefreshXactLimitに関する説明を参照してください。

月末の処理の場合、自動リフレッシュ・キャッシュ・グループにキャッシュされているOracle表の単一のトランザクションに大量の更新が存在することがあります。大規模なトランザクションにより永続メモリーが一杯にならないようにするために、ttCacheAutorefreshXactLimit組込みプロシージャにより、256個(またはユーザー指定の他の値)の処理が終了するごとに自動リフレッシュをコミットするようにできます。

ttCacheAutorefreshXactLimit組込みプロシージャでvalueをONまたは特定の処理数に設定して大規模なトランザクションを実行する前に、増分自動リフレッシュ読取り専用キャッシュ・グループに対する自動リフレッシュ・トランザクション制限の設定をオンにします。次に、自動リフレッシュによるTimesTen内のキャッシュ表の更新が終了したら、ttCacheAutorefreshXactLimit組込みプロシージャにより、増分自動リフレッシュ読取り専用キャッシュ・グループに対する自動リフレッシュ・トランザクション制限の設定をオフにします。

次の例では、間隔の値が10秒として定義されているすべての増分自動リフレッシュ読取り専用キャッシュ・グループに対して、256個の処理が終了するごとにトランザクション制限をコミットするように設定しています。

call ttCacheAutorefreshXactLimit('10000', 'ON');

月末の処理が完了し、増分自動リフレッシュ読取り専用キャッシュ・グループがリフレッシュされた後、間隔の値が10秒として定義されている増分自動リフレッシュ読取り専用キャッシュ・グループに対するトランザクション制限の設定を無効にします。

call ttCacheAutorefreshXactLimit('10000', 'OFF');

1024個の処理が終了するごとに増分自動リフレッシュ読取り専用キャッシュ・グループに対するトランザクション制限をコミットするように設定するには、次のように値として1024を指定します。

call ttCacheAutorefreshXactLimit('10000', '1024');

発生する可能性のあるトランザクションの非一貫性の例

次の例では、employee表およびdepartment表を使用しますが、ここでdepartment表のdepartment idは外部キーで、employee表のdepartment idを示しています。

次の例では、2つの増分自動リフレッシュ読取り専用キャッシュ・グループを作成しますが、それぞれのキャッシュ・グループは独自のキャッシュ・グループ内にあります。大規模なトランザクションの前にttCacheAutorefreshXactLimitにより自動リフレッシュ・トランザクション制限の設定を有効にし、トランザクションの完了後に設定を無効にします。

1. 大規模なトランザクションを開始する前に、ttCacheAutorefreshXactLimitを起動して、間隔の値およびその間隔で自動的にコミットする処理数を設定します。次の例では、間隔が2秒に設定されているすべての増分自動リフレッシュ読取り専用キャッシュ・グループに対して、処理数を3 (例を簡単にするために意図的に小さな値にしています)に設定しています。

CALL ttCacheAutorefreshXactLimit('2000', '3');
< 2000, 3 >
1 row found.

2. 間隔を2秒に設定して、増分自動リフレッシュ読取り専用キャッシュ・グループを作成します。この例では、2つの静的(動的ではない)読取り専用キャッシュ・グループを作成しますが、それぞれのキャッシュ・グループに表が1つ含まれています。

CREATE READONLY CACHE GROUP cgDepts AUTOREFRESH MODE INCREMENTAL
INTERVAL 2 SECONDS
FROM departments
( department_id    NUMBER(4) PRIMARY KEY
, department_name  VARCHAR2(30) NOT NULL
, manager_id       NUMBER(6)
, location_id      NUMBER(4)
);

CREATE READONLY CACHE GROUP cgEmpls AUTOREFRESH MODE INCREMENTAL
INTERVAL 2 SECONDS
FROM 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. 両方の自動リフレッシュ・キャッシュ・グループに対して、手動でLOAD CACHE GROUPを実行します。

LOAD CACHE GROUP cgDepts COMMIT EVERY 256 ROWS;
27 cache instances affected.

LOAD CACHE GROUP cgEmpls COMMIT EVERY 256 ROWS;
107 cache instances affected.

employees表で示されているように、自動リフレッシュ中は表内に非一貫性が発生する場合があります。

1. TimesTenで、すべての従業員の給与の最大値と最小値を選択します。

SELECT MIN(salary), MAX(salary) FROM employees;
< 2100, 24000 >
1 row found.

2. Oracle Databaseで、全員の給与に100,000を追加します。

UPDATE employees SET salary = salary + 100000;
107 rows updated.

3. TimesTenで、再度SELECTを実行すると(自動リフレッシュ・トランザクションは3レコードごとにコミットされています)、給与の最大値は更新されていますが、最小値は元の値のままです。

SELECT MIN(salary), MAX(salary) FROM employees;
< 2100, 124000 >
1 row found.

4. ただし、自動リフレッシュが完了すると、トランザクションの一貫性が確保されます。この例では、自動リフレッシュ・プロセスが完了すると、すべての従業員の給与が100,000だけ増加しています。

SELECT MIN(salary), MAX(salary) FROM employees;
< 102100, 124000 >
1 row found.

5. 大規模なトランザクションが完了したため、間隔が2秒に設定されている自動リフレッシュ・キャッシュ・グループに対するトランザクション制限の設定を無効にします。

call ttCacheAutorefreshXactLimit('2000', 'OFF');

自動リフレッシュ・プロセスの進行中にSQL文を実行すると、キャッシュ・グループ間でトランザクションの非一貫性が発生する可能性があります。次の例では、cgDepts自動リフレッシュ・グループ内のemployees表およびdepartments表に対してSELECT文を実行しています。この例では、TimesTenで外部キーが指定されておらず、自動リフレッシュ・プロセスが複数のトランザクションに適用されているため、departmentの更新の前にemployee表の更新が挿入される場合があります。

さらに、キャッシュ・グループ内の両方の表に対するすべての更新は、自動リフレッシュ・サイクルが完了するまでは適用されません。次の例では、自動リフレッシュ・プロセスが完了する前にSELECT文が実行されています。このように、結果には必要なデータがすべて表示されているわけではなく、部門名や複数の従業員(法務部1000の弁護士の一部)が欠落しています。

SELECT e.department_id, d.DEPARTMENT_NAME, e.FIRST_NAME, e.LAST_NAME
FROM employees e, departments d
WHERE e.DEPARTMENT_ID  = d.DEPARTMENT_ID (+)
AND e.department_id >= 1000 ORDER BY 1,2,3,4;
< 1000, <NULL>, Alan, Dershowitz >
< 1000, <NULL>, F. Lee, Bailey >
< 1000, <NULL>, Johnnie, Cochran >
3 rows found.

ただし、自動リフレッシュ・プロセスが完了すると、トランザクションの一貫性が確保されます。次の例では、自動リフレッシュの完了後に同じSELECT文が実行されています。この場合、部門情報や新しいすべての弁護士などの必要なデータがすべて更新されています。

SELECT e.department_id, d.DEPARTMENT_NAME, e.FIRST_NAME, e.LAST_NAME
FROM employees e, departments d
WHERE e.DEPARTMENT_ID  = d.DEPARTMENT_ID (+)
AND e.department_id >= 1000 ORDER BY 1,2,3,4;
< 1000, Legal, Alan, Dershowitz >
< 1000, Legal, Barry, Scheck >
< 1000, Legal, F. Lee, Bailey >
< 1000, Legal, Johnnie, Cochran >
< 1000, Legal, Robert, Kardashian >
< 1000, Legal, Robert, Shapiro >
6 rows found.

複数の表を持つ自動リフレッシュ・キャッシュ・グループの場合も、自動リフレッシュ・プロセスの進行中にSQL文を実行すると、トランザクションの非一貫性が発生することがあります。

1. ttCacheAutorefreshXactLimit組込みプロシージャにより、2秒間隔の増分自動リフレッシュ・キャッシュ・グループに対してトランザクション制限の設定を開始し、employeesおよびdepartmentsの2つの表を持つ単一の自動リフレッシュ・キャッシュ・グループを作成します。

CALL ttCacheAutorefreshXactLimit('2000', '3');
< 2000, 3 >
1 row found.

CREATE READONLY CACHE GROUP cgDeptEmpls AUTOREFRESH MODE INCREMENTAL
INTERVAL 2 SECONDS
FROM departments
( department_id    NUMBER(4) PRIMARY KEY
, department_name  VARCHAR2(30) NOT NULL
, manager_id       NUMBER(6)
, location_id      NUMBER(4)
)
, 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)
, foreign key(department_id) references departments(department_id)
);

2. キャッシュ・グループを手動でロードします。

LOAD CACHE GROUP cgDeptEmpls COMMIT EVERY 256 ROWS;
27 cache instances affected.

3. TimesTenでSELECT文を実行し、法務部のデータをすべてアップロードします。

SELECT e.department_id, d.department_name, count(*)
FROM employees e, departments d
WHERE e.department_id  = d.department_id (+)
GROUP BY e.department_id, d.department_name
ORDER BY 1 desc;
< 110, Accounting, 2 >
< 100, Finance, 6 >
< 90, Executive, 3 >
< 80, Sales, 34 >
< 70, Public Relations, 1 >
< 60, IT, 5 >
< 50, Shipping, 45 >
< 40, Human Resources, 1 >
< 30, Purchasing, 6 >
< 20, Marketing, 2 >
< 10, Administration, 1 >
11 rows found.

4. Oracleでemployeeおよびdepartmentの両方の表に、6人の新しい弁護士が所属する新しい法務部(番号1000)を挿入します。

5. 自動リフレッシュ・プロセス時にTimesTenでSELECT文を実行すると、部門1000の2人の弁護士に関するデータのみがTimesTenにアップロードされます。

SELECT e.department_id, d.department_name, count(*)
FROM employees e, departments d
WHERE e.department_id  = d.department_id (+)
GROUP BY e.department_id, d.department_name
ORDER BY 1 desc;
< 1000, Legal, 2 >
< 110, Accounting, 2 >
< 100, Finance, 6 >
< 90, Executive, 3 >
< 80, Sales, 34 >
< 70, Public Relations, 1 >
< 60, IT, 5 >
< 50, Shipping, 45 >
< 40, Human Resources, 1 >
< 30, Purchasing, 6 >
< 20, Marketing, 2 >
< 10, Administration, 1 >
12 rows found.

6. ただし、自動リフレッシュ・プロセスが完了すると、法務部に所属する6人の従業員(弁護士)すべてのデータがTimesTenにアップロードされます。これにより、現時点においてトランザクションの一貫性が確保されます。

SELECT e.department_id, d.department_name, COUNT(*)
FROM employees e, departments d
WHERE e.department_id  = d.department_id (+)
GROUP BY e.department_id, d.department_name
ORDER BY 1 desc;
< 1000, Legal, 6 >
< 110, Accounting, 2 >
< 100, Finance, 6 >
< 90, Executive, 3 >
< 80, Sales, 34 >
< 70, Public Relations, 1 >
< 60, IT, 5 >
< 50, Shipping, 45 >
< 40, Human Resources, 1 >
< 30, Purchasing, 6 >
< 20, Marketing, 2 >
< 10, Administration, 1 >
12 rows found.

7. 大規模なトランザクションが完了したため、間隔が2秒に設定されている自動リフレッシュ・キャッシュ・グループに対するトランザクション制限の設定を無効にします。

call ttCacheAutorefreshXactLimit('2000', 'OFF');

トランザクション制限を設定する際のパフォーマンスを評価する統計の取得

特定の自動リフレッシュ間隔に対して自動リフレッシュ・トランザクション制限が実行されることを確認するために、ttCacheAutorefIntervalStatsGet組込みプロシージャを使用して自動リフレッシュ間隔に対する最後の10回の増分自動リフレッシュ・トランザクションの統計を取得できます。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。

増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の選択制限の構成

読取り専用キャッシュ・グループの増分自動リフレッシュを容易にするために、TimesTenはOracle Databaseの実表とその対応する変更ログ表の両方に表の結合問合せを実行して、増分の変化を取得します。ただし、両方の表が非常に大きい場合は、結合問合せが遅くなる可能性があります。また、結合問合せの実行中にOracle Databaseの実表が常に更新されている場合、長期実行自動リフレッシュ問合せからORA-01555「Snapshot too old」エラーを受信する可能性があります。

この状況を回避するために、選択制限を使用して増分自動リフレッシュを構成できます。選択制限はOracle Databaseの実表を自動リフレッシュ変更ログ表の制限された行数と結合します。ttCacheAutorefreshSelectLimit組込みプロシージャを使用して選択制限を構成できます。

自動リフレッシュは自動リフレッシュ変更ログ表のすべての行が適用されるまで、キャッシュ表に対する変更を適用し続けます。適用する行がなくなった場合、自動リフレッシュ・スレッドは残りの時間間隔内で休止状態になります。

注意:
構文、パラメータ、結果セット、および制限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAutorefreshSelectLimitに関する説明を参照してください。

たとえば、大規模なトランザクションの前にttCacheAutorefreshSelectLimit組込みプロシージャをコールして、間隔の値が10秒の増分自動リフレッシュ・キャッシュ・グループの選択制限を1000行に設定します。次の例では、valueがONに設定されています。

Command> call ttCacheAutorefreshSelectLimit('10000', 'ON');
< 10000, ON >
1 row found.

次の例では間隔値が7秒の増分自動リフレッシュ・キャッシュ・グループに対して選択制限を2000行に設定しています。

Command> call ttCacheAutorefreshSelectLimit('7000', '2000');
< 7000, 2000 >
1 row found.

valueをOFFに設定することで、間隔の値が10秒の増分自動リフレッシュ・キャッシュ・グループの選択制限を無効にできます。

Command> call ttCacheAutorefreshSelectLimit('10000', 'OFF');
< 10000, OFF >
1 row found.

特定の自動リフレッシュ間隔に対する選択制限がどのように実行されるかを確認するために、この自動リフレッシュ間隔に対する増分自動リフレッシュ・トランザクションの統計を取得できます。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。

特定の選択制限に対するキャッシュ・グループ名を決定する方法

キャッシュ・グループの間隔を決定するには、ttIsqlを使用してcachegroupsコマンドを実行します。

> cachegroups cgowner.cgname;

これにより、間隔を含むcgowner.cgnameキャッシュ・グループのすべての属性が返されます。

どの間隔に選択制限があるか確認するために、Oracle Databaseで次の問合せを実行できます(このOracle Databaseでは<cacheAdminUser>はキャッシュ管理者、<hostName>はTimesTenデータベースがあるマシンのホスト名、<databaseFileName>はDataStore属性から引き継いだデータベース・パスとなっており、バージョン番号(06など)がxxに置き換えてあります)。

SELECT * FROM <cacheAdminUser>.tt_xx_arinterval_params
WHERE param='AutorefreshSelectEveryN'
AND host='<hostName>'
AND database like '%<databaseFileName>%'
ORDER BY arinterval;

たとえば、キャッシュ管理者のユーザー名はpat、ホスト名はmyhost、データベース・ファイル名はmyTtDb、06をTimesTenのマイナー・リリース番号のxxに置き換えると、次のようになります。

SELECT * FROM pat.tt_06_arinterval_params
WHERE param='AutorefreshSelectEveryN'
AND host='myhost'
AND database like '%myTtDb%'
ORDER BY arinterval;

間隔はミリ秒単位で保存されます。

選択制限を使用する際のパフォーマンスを評価する統計の取得

特定の自動リフレッシュ間隔に対して選択制限が実行されることを確認するために、ttCacheAutorefIntervalStatsGet組込みプロシージャを使用してこの自動リフレッシュ間隔に対する増分自動リフレッシュ・トランザクションの統計を取得できます。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。

自動リフレッシュ処理時にメモリーを再利用する際のパフォーマンスの向上

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクションの再要求処理に関する説明にあるように、トランザクションのコミットの再利用フェーズ時にTimesTenリソースのクリーンアップが実行されます。パフォーマンス向上のため、数件のトランザクション・ログ・レコードをメモリーにキャッシュしてコミット・バッファのディスク上のトランザクション・ログへのアクセスを減らします。ただし、トランザクションが再利用バッファより大きい場合、TimesTenはディスク上のトランザクション・ログにアクセスする必要があります。

キャッシュ・グループに自動リフレッシュを使用する場合、キャッシュ・エージェントは独自の再利用バッファを使用して、自動リフレッシュ処理内でコミットされたトランザクションを管理します。キャッシュ・エージェントの再利用バッファが小さすぎる場合、自動リフレッシュ時のコミット処理は、ディスク上のトランザクション・ログにアクセスする必要があるため、予想よりも長くなる可能性があります。パフォーマンス問題を回避するには、キャッシュ・エージェントに大きな再利用バッファを構成し、再利用時にこのキャッシュ・エージェントがメモリー内で大規模なトランザクションを処理できるようにします。

アクティブ・スタンバイ・ペア・レプリケーション・スキームを使用して自動リフレッシュ処理をレプリケートする場合、レプリケーション・エージェントがレプリケーションの一部として同じ自動リフレッシュ処理を適用します。このため、アクティブおよびスタンバイ・ノードのレプリケーション・エージェントにはそれぞれの再利用バッファがあります。これらはキャッシュ・エージェントの再利用バッファと同じまたは大きいサイズで構成する必要があります。

ttDbConfig組込みプロシージャにより、キャッシュ・エージェントおよびレプリケーション・エージェント両方の再利用バッファの最大サイズを設定する次のパラメータが提供されます。(再利用バッファのメモリーは一時メモリーから割り当てられます。)

- CacheAgentCommitBufSizeはキャッシュ・エージェントの再利用バッファの最大サイズを設定します。

- RepAgentCommitBufSizeは、レプリケーション・エージェントの再利用バッファの最大サイズを設定します。アクティブおよびスタンバイ・ノードの両方で再利用バッファの最大サイズを構成する必要があります。再利用バッファのサイズは両方のノードに同じ値を設定することをお薦めしますが、必要ではありません。

注意:
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDbConfigに関する説明を参照してください。

キャッシュ・エージェントの再利用バッファのサイズを増分する必要があるかを判断するには、ttCacheAutorefIntervalStatsGet組込みプロシージャにより提供されるCommitBufMaxReachedおよびCommitBufNumOverflows統計を評価します。詳細は、「自動リフレッシュ・トランザクションに関する統計情報の取得」を参照してください。

自動リフレッシュ・トランザクションに関する統計情報の取得

ttCacheAutorefIntervalStatsGet組込みプロシージャをコールして、増分自動リフレッシュ読取り専用キャッシュ・グループに定義された特定の自動リフレッシュ間隔による最後の10回の自動リフレッシュ・サイクルに関する統計情報を取得します。

注意:
この組込みプロシージャの構文および返される結果セットの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAutorefIntervalStatsGetに関する説明を参照してください。
この組込みプロシージャはトランザクション制限または選択制限を増分、自動リフレッシュ読取り専用キャッシュ・グループに設定する場合に役立ちます。詳細は、「増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の大規模なトランザクションの実行の向上」および「増分自動リフレッシュ読取り専用キャッシュ・グループを使用する際の選択制限の構成」を参照してください。

次の例では、ttCacheAutorefIntervalStatsGet組込みプロシージャをコールして、静的に定義され、間隔が2秒の増分自動リフレッシュ読取り専用キャッシュ・グループの統計を取得する方法を示します。

Command> call ttCacheAutorefIntervalStatsGet(2000, 1);

< 2000, 1, 21, 2013-04-30 06:05:38.000000, 100, 3761, 3761, 822, 1048576,
1280, 0, 58825, 63825, 13590, 0, 0, 0, 0, 0 >
< 2000, 1, 20, 2013-04-30 06:05:37.000000, 100, 85, 85, 18, 1048576, 1280,
0, 55064, 60064, 12768, 0, 0, 0, 0, 0 >
< 2000, 1, 19, 2013-04-30 06:05:32.000000, 100, 3043, 3043, 666, 1048576,
1280, 0, 54979, 59979, 12750, 0, 0, 0, 0, 0 >
< 2000, 1, 18, 2013-04-30 06:05:30.000000, 100, 344, 344, 74, 1048576,
1280, 0, 51936, 56936, 12084, 0, 0, 0, 0, 0 >
< 2000, 1, 17, 2013-04-30 06:05:28.000000, 100, 1826, 1826, 382, 1048576,
1280, 0, 51592, 56592, 12010, 0, 0, 0, 0, 0 >
< 2000, 1, 16, 2013-04-30 06:05:26.000000, 100, 55, 55, 12, 1048576,
1280, 0, 49766, 54766, 11628, 0, 0, 0, 0, 0 >
< 2000, 1, 15, 2013-04-30 06:05:22.000000, 100, 2901, 2901, 634, 1048576,
1280, 0, 49711, 54711, 11616, 0, 0, 0, 0, 0 >
< 2000, 1, 14, 2013-04-30 06:05:21.000000, 100, 55, 55, 12, 1048576,
1280, 0, 46810, 51810, 10982, 0, 0, 0, 0, 0 >
< 2000, 1, 13, 2013-04-30 06:05:10.000000, 100, 5844, 5844, 1263, 1048576,
1280, 0, 46755, 51755, 10970, 0, 0, 0, 0, 0 >
< 2000, 1, 12, 2013-04-30 06:05:08.000000, 100, 607, 607, 132, 1048576,
1280, 0, 40911, 45911, 9707, 0, 0, 0, 0, 0 >

10 rows found.

2つ以上のTimesTenデータベースにおける同じOracle表のキャッシュ

TimesTenは、キャッシュ管理ユーザーごとにキャッシュ・グループの各キャッシュ表について、Oracle Database内に変更ログ表とトリガーを作成します(キャッシュを管理するために作成する項目の一部として)。トリガーは、キャッシュされたOracle Database表で挿入、更新または削除処理がコミットされるたびに起動され、アクションが変更ログ表に記録されます。

2つの異なるTimesTenデータベース上で1つのキャッシュ・グループに同じOracle Database表をキャッシュする場合は、それぞれのTimesTenデータベースでのキャッシュ表の所有者と同じキャッシュ管理ユーザー名を、両方のTimesTenデータベースで使用することをお薦めします。同じキャッシュ管理ユーザーを使用すると、1つのトリガーと変更ログ表のみが作成され、実表への変更内容が管理されます。これは効率的な方法であり、アプリケーションの速度も低下しません。

それぞれのTimesTenデータベースで個別にキャッシュ管理ユーザーを作成して、同じOracle表をキャッシュするキャッシュ・グループを所有する場合は、Oracle Databaseの同じ表にキャッシュ管理ユーザーごとに別々のトリガーと変更ログ表が存在します。たとえば、2つの別のTimesTenデータベースが存在して、それぞれに独自のキャッシュ管理ユーザーが指定されている場合、実表では各DML処理に対して2つのトリガーが起動され、それぞれは別の変更ログ表に保存されます。2つのトリガーが起動されて変更ログ表を個別に管理すると、アプリケーションの速度が低下することがあります。

キャッシュ管理ユーザーを個別に作成する唯一の理由は、同じ表をキャッシュする複数のTimesTenデータベースのいずれかで自動リフレッシュのレートが低下しているか、またはOracle Databaseへの接続速度が低下しているためです。この場合、両方のTimesTenデータベースで単一のキャッシュ管理ユーザーを指定すると、速度が低下しているデータベースに更新が伝播されるのを待機するため、高速の接続状態でのアプリケーションの速度が低下します。

9 キャッシュ環境のクリーンアップ

次の各項では、キャッシュ・グリッドを破棄してキャッシュ・グループを削除するために、TimesTenデータベースおよびOracle Databaseで実行する必要がある様々なタスクについて説明します。また、AWTキャッシュ・グループを使用する際に、すべてのコンポーネントを停止するための推奨事項についても説明します。

- キャッシュ・グリッドからのTimesTenデータベースのデタッチ

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

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

- キャッシュ・グリッドの破棄

- キャッシュ・エージェントの停止

- TimesTenデータベースの破棄

- Oracle Databaseのユーザーおよびオブジェクトの削除

- AWTキャッシュ・グループとともにアクティブ・スタンバイ・ペアをスケジュールして停止する場合に推奨される手法

注意:
Oracle Clusterwareを使用してキャッシュ・グリッドのアクティブ・スタンバイ・ペアを管理する計画を立てている場合は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のTimesTenキャッシュ・グリッドでのOracle Clusterwareの使用に関する説明を参照してください。
また、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の制限されたコマンドおよびSQL文に関する説明も参照してください。アクティブ・スタンバイ・ペア・グリッド・メンバーを管理するには、この章で説明する組込みプロシージャではなく、ttCWAdminユーティリティを使用します。

キャッシュ・グリッドからのTimesTenデータベースのデタッチ

アタッチされているキャッシュ・グリッドからグリッド・メンバーをデタッチするには、ttGridDetach組込みプロシージャをコールします。グリッド・メンバーがアクティブ・スタンバイ・ペアである場合は、アクティブ・データベースとスタンバイ・データベースの両方を個別にデタッチする必要があります。グリッド・メンバーをデタッチすると、そのグローバル・キャッシュ・グループにもキャッシュ表にも処理を実行できなくなります。また、グリッド・メンバーは、所有していたすべてのキャッシュ・インスタンスの所有権を放棄します。キャッシュ・エージェント・プロセスおよびレプリケーション・エージェント・プロセスは、データベースがキャッシュ・グリッドからデタッチされるまで停止できません。

ttGridキャッシュ・グリッドからメンバーをデタッチするには、cachealone1データベースから、キャッシュ・マネージャ・ユーザーとしてttGridDetach組込みプロシージャをコールします。例:

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttGridDetach;

TimesTenデータベースをキャッシュ・グリッドからデタッチする前に、cachealone1内のグローバル・キャッシュ・グループのキャッシュ表にコミットされたすべての更新が、キャッシュされたOracle Database表に伝播されていることを確認するには、デタッチを実行する前に待機する秒数を指定します。この例では、待機時間は60秒です。

Command> CALL ttGridDetach(,,60);

グリッドからデータベースがデタッチされた後、そのデータベースで動作するレプリケーション・エージェントを停止できます。

使用不可能になったにも関わらず引き続きグリッドにアタッチされているグリッド・メンバーに対し、デタッチを強制できます。グリッド・メンバーの基本となるTimesTenデータベースは、たとえば、TimesTenシステムがオフラインになったり、データベースが破棄されると使用不可能になります。読取り専用サブスクライバ・データベースを除く、使用可能ないずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttGridDetach組込みプロシージャをコールし、その際に値1をforceパラメータに渡します。

Command> CALL ttGridDetach('TTGRID_alone2_2',1);

アタッチしたすべてのグリッド・メンバーの名前を確認するには、ttGridNodeStatus組込みプロシージャをコールします。

使用不可能になったにも関わらず引き続きグリッドにアタッチされているグリッド・メンバーをまとめて強制的にデタッチするには、読取り専用サブスクライバ・データベースを除く使用可能ないずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttGridDetachList組込みプロシージャをコールします。その際、値1をforceパラメータに渡します。

Command> CALL ttGridDetachList('TTGRID_cacheact_3A TTGRID_cachestand_3B',1);

すべてのグリッド・メンバーをデタッチするには、ttGridDetachAll組込みプロシージャをコールします。この例では、デタッチ処理は60秒待機します。

Command> CALL ttGridDetachAll(60);

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

レプリケーション・エージェントを停止するには、ttRepStop組込みプロシージャをコールします。この処理は、読取り専用サブスクライバ・データベース、およびAWTキャッシュ・グループのあるスタンドアロンTimesTenデータベースを含め、アクティブ・スタンバイ・ペアの各TimesTenデータベースで実行する必要があります。

cachealone1、cachealone2、cacheactive、cachestandby、rosubscriberの各データベースから、キャッシュ・マネージャ・ユーザーとしてttRepStop組込みプロシージャをコールして、データベースのレプリケーション・エージェントを停止します。

Command> CALL ttRepStop;

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

キャッシュ・グループおよびそのキャッシュ表を削除するには、DROP CACHE GROUP文を使用します。DROP CACHE GROUP文を使用してキャッシュ・グループを削除したり、ALTER CACHE GROUP文を使用して自動リフレッシュ・キャッシュ・グループの自動リフレッシュ状態をOFFに設定すると、Oracle Databaseデータのキャッシュ管理に使用されているOracle Databaseオブジェクトが自動的に削除されます。

自動リフレッシュ処理を実行中のキャッシュ・グループに対してDROP CACHE GROUP文を発行すると、次のようになります。

- LockWait接続属性設定が0(ゼロ)より大きな値である場合、自動リフレッシュ処理は停止します。DROP CACHE GROUP文が自動リフレッシュ処理より優先して使用されます。

- LockWait接続属性設定が0(ゼロ)である場合、自動リフレッシュ処理は続行します。DROP CACHE GROUP文は、自動リフレッシュ処理が完了するか、またはこの文自体がロック・タイムアウト・エラーで失敗するまでブロックされます。

キャッシュ表がアクティブ・スタンバイ・ペアにレプリケート中であり、そのキャッシュ表がレプリケートされている唯一の要素である場合は、キャッシュ・グループを削除する前に、DROP ACTIVE STANDBY PAIR文を使用してアクティブ・スタンバイ・ペアを削除する必要があります。アクティブ・スタンバイ・ペアがグリッド・メンバーである場合は、アクティブ・スタンバイ・ペアを削除する前に、グリッド・メンバーをグリッドからデタッチする必要があります。

アクティブ・スタンバイ・ペアのレプリケーション・スキームを削除するには、キャッシュ・マネージャ・ユーザーとしてcacheactive、cachestandbyおよびrosubscriberの各データベースで次の文を実行します。

Command> DROP ACTIVE STANDBY PAIR;
Command> exit

キャッシュ・グループを削除する前に、すべてのグリッド・メンバーのグローバル・キャッシュ・グループ内のデータをアンロードする必要があります。GlobalProcessingオプティマイザ・フラグを1に設定し、キャッシュ・グループをアンロードします。

CALL ttOptSetFlag('GlobalProcessing', 1);
UNLOAD CACHE GROUP subscriber_accounts;

キャッシュ・グループを削除するには、DROP ANY TABLE権限をキャッシュ・マネージャ・ユーザーに付与する必要があります。DROP ANY TABLE権限をキャッシュ・マネージャ・ユーザーに付与するには、インスタンス管理者としてcachealone1、cachealone2、cacheactiveおよびcachestandbyの各データベースで次の文を実行します。cachealone1データベースから発行されたSQL文の例は、次のとおりです。

% ttIsql cachealone1
Command> GRANT DROP ANY TABLE TO cacheuser;
Command> exit

AWTキャッシュ・グループを削除する場合は、そのキャッシュ・グループを削除する前に、ttRepSubscriberWait組込みプロシージャを使用して、そのグループのキャッシュ表にコミットされたすべての更新をキャッシュされたOracle Database表に伝播します。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> CALL ttRepSubscriberWait('_AWTREPSCHEME','TTREP','_ORACLE','sys1',-1);

AWTキャッシュ・グループを削除すると、キャッシュ表にコミットされた更新をキャッシュされたOracle表に非同期に伝播するためにAWTキャッシュ・グループに作成したレプリケーション・スキームが自動的に削除されます。

スタンドアロンTimesTenデータベース、アクティブ・データベースおよびスタンバイ・データベースからキャッシュ・グループを削除するには、DROP CACHE GROUP文を使用します。

subscriber_accountsグローバル・キャッシュ・グループを削除するには、キャッシュ・マネージャ・ユーザーとしてcachealone1、cachealone2、cacheactiveおよびcachestandbyの各データベースで次の文を実行します。cachealone1データベースから発行されたSQL文の例は、次のとおりです。

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
Command> DROP CACHE GROUP subscriber_accounts;

注意:
キャッシュ・グループを削除した後またはキャッシュ・グループの自動リフレッシュ状態をOFFに変更した後、すぐにキャッシュ・エージェントを停止させる場合は、Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトは削除されません。キャッシュ・エージェントを再起動すると、削除または変更したキャッシュ・グループ用に作成されたOracle Databaseオブジェクトが削除されます。

キャッシュ・グリッドの破棄

キャッシュ・グリッドを破棄するには、ttGridDestroy組込みプロシージャをコールします。デフォルトでは、既存のキャッシュ・グループまたはアタッチ済グリッド・メンバーが存在する場合、キャッシュ・グリッドを破棄できません。

ttGridキャッシュ・グリッドを破棄するには、読取り専用サブスクライバ・データベースを除くいずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttGridDestroy組込みプロシージャをコールします。

Command> CALL ttGridDestroy('ttGrid');

TimesTenデータベースが使用不可能になったにも関わらずキャッシュ・グループを含むグリッド・メンバーやグリッドにアタッチされているグリッド・メンバーについても、キャッシュ・グリッドを強制的に破棄できます。TimesTenデータベースは、たとえば、TimesTenシステムがオフラインになったり、データベースが破棄されると使用不可能になります。読取り専用サブスクライバ・データベースを除くいずれかのTimesTenデータベースから、キャッシュ・マネージャ・ユーザーとしてttGridDestroy組込みプロシージャをコールし、その際に値1をforceパラメータに渡します。

Command> CALL ttGridDestroy('ttGrid',1);

キャッシュ・グリッドは、不要になった場合または再びそのグリッドにアタッチすることがない場合にのみ破棄してください。

キャッシュ・エージェントの停止

キャッシュ・エージェントを停止するには、ttCacheStop組込みプロシージャをコールします。この処理は、アクティブ・スタンバイ・ペアのアクティブ・データベースおよびスタンバイ・データベースに加えて、すべてのスタンドアロンTimesTenデータベースで実行する必要があります。

cachealone1、cachealone2、cacheactiveおよびcachestandbyの各データベースから、次の組込みプロシージャ・コールを発行してデータベースのキャッシュ・エージェントを停止します。

Command> CALL ttCacheStop;
Command> exit

TimesTenデータベースがまだキャッシュ・グリッドにアタッチされている場合は、キャッシュ・エージェントを停止できません。

TimesTenデータベースの破棄

TimesTenデータベースが不要になった場合は、ttDestroyユーティリティを使用してそのデータベースを破棄できます。

注意:
RAMポリシーで、データベースをメモリーに残すように指定した場合、データベースが破損する場合があります。たとえば、RAMポリシーがalwaysに指定されている場合には、データベースを破棄する前に、RAMポリシーをmanualに変更し、ttAdmin -ramunloadコマンドを実行してデータベースをアンロードする必要があります。RAMポリシー設定の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの設定に関する説明を参照してください。

次の例では、cachealone1データベースに接続してから破棄するttDestroyユーティリティを示しています。

% ttDestroy cachealone1

Oracle Databaseのユーザーおよびオブジェクトの削除

timestenユーザー、スキーマ・ユーザーorattおよびキャッシュ管理ユーザーcacheuserに加えて、これらのユーザーが所有するすべてのオブジェクト(表やトリガーなど)を削除するには、sysユーザーとしてSQL*Plusを使用します。次に、TT_CACHE_ADMIN_ROLEロールを削除し、さらにtimestenユーザーおよびキャッシュ管理ユーザーによって使用され、表領域やそのデータ・ファイルの内容などが含まれているデフォルトの表領域cachetblspを削除します。

% sqlplus sys as sysdba
Enter password: password
SQL> DROP USER timesten CASCADE;
SQL> DROP USER oratt CASCADE;
SQL> DROP USER cacheuser CASCADE;
SQL> DROP ROLE tt_cache_admin_role;
SQL> DROP TABLESPACE cachetblsp INCLUDING CONTENTS AND DATAFILES;
SQL> exit

AWTキャッシュ・グループとともにアクティブ・スタンバイ・ペアをスケジュールして停止する場合に推奨される手法

AWTキャッシュ・グループとアクティブ・スタンバイ・ペアを使用している場合、その環境には、アクティブおよびスタンバイ状態のマスター、おそらく1つ以上のサブスクライバおよび最低1つのOracle Databaseが存在しています。次に示すのは、この環境において未処理のトランザクションのスケジュールされた停止を開始する際に推奨される手法です。この順序でイベントが行われると、停止の前に未処理のトランザクションの適用を終了するのに必要な時間が与えられ、すべてのコンポーネントを再起動するのに必要な時間が最低限になります。

1. すべてのアプリケーションを停止します。

2. すべてのトランザクションがOracle Databaseに伝播されていることを確認します。

3. TimesTenを停止します。

4. Oracle Databaseを停止します。

すべてのコンポーネントを再起動する準備ができたら、次の処理を行います。

1. Oracle Databaseを再起動します。

2. TimesTenを再起動します。

3. すべてのアプリケーションを再起動します。

これらの製品はすべて、任意の順序で正常に停止できます。順序が重要になるのは、パフォーマンスを最大限にするために、未適用のトランザクションを保存する必要がない場合のみです。たとえば、アクティブ・スタンバイ・ペアにおいてAWTキャッシュ・グループを使用しており、TimesTenより先にOracle Databaseを停止する場合は、未適用のトランザクションがすべてTimesTenのトランザクション・ログに蓄積されます。このように、TimesTenおよびOracleを再起動する場合、保留中のトランザクションがOracle Databaseに適用されますが、スループットが低下する可能性があります。Oracle Databaseより先にTimesTenを停止することは、スケジュールされた停止と再起動を行う際の最も効率的な手法です。さらに、TimesTenより先にアプリケーションを停止すると、使用不可のTimesTenデータベースに対して余分な要求が送信されなくなります。

10 キャッシュ・アドバイザの使用

次の各項では、TimesTen Application-Tier Database (TimesTen)キャッシュ・アドバイザの使用方法について説明します。

- キャッシュ・アドバイザの概要

- Oracle DatabaseおよびTimesTenホスト・システムの設定

- SQLワークロード・アプリケーションの実行

- キャッシュ・アドバイザの実行

- キャッシュ・アドバイザ・レポートの表示

- OracleおよびTimesTenのデータベースおよびホスト・システムのクリーンアップ

キャッシュ・アドバイザの概要

TimesTenキャッシュ・アドバイザを使用することで、Oracle Databaseの顧客が、TimesTen Cache (TimesTenデータベースとも呼ばれます)を使用した場合にその既存のOracle Databaseアプリケーションのパフォーマンスを向上できるかどうかを判断できます。

キャッシュ・アドバイザは、Oracle DatabaseアプリケーションのSQL使用率に基づき、TimesTenキャッシュ・グループの定義の推奨値を生成します。これは、アプリケーションから取り込んだSQLワークロードまたは既存のSQLチューニング・セットを評価することにより、実行されます。キャッシュ・アドバイザは、この情報とOracle Databaseオブジェクトのスキーマ定義を分析して、表および列の使用パターンを決定します。また、キャッシュ・アドバイザは、指定されたTimesTenキャッシュ・サイズにおけるアプリケーションのパフォーマンスを分析するため、指定されたキャッシュのサイズに応じてキャッシュ・グループの推奨事項が異なる場合があります。SQLチューニング・セットの詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』のSQLチューニング・セットの管理に関する項を参照してください。

取得したSQLアプリケーション・ワークロードまたはSQLチューニング・セットを評価する場合、キャッシュ・アドバイザでは、TimesTenアプリケーションの非同期ライトスルー(AWT)キャッシュ・グループまたは読取り専用キャッシュ・グループのいずれかを使用することが推奨されています。使用するキャッシュ・グループのタイプは、SQL SELECT文の実行数と比較した、データ値を変更するOracle DatabaseアプリケーションのSQL文実行数に基づいて決定します。

注意:
キャッシュ・アドバイザは、実行ポート問題に関してDML文(SELECT、INSERT、UPDATEおよびDELETE)を評価しますが、TimesTenとOracle Databaseの両方でパフォーマンスを比較する際にはSELECT文のみを評価します。
キャッシュ・アドバイザは、各SQL文を他の文から分離して評価します。必要な場合は、各文の完了後にROLLBACKを実行してデータを保存します。キャッシュ・アドバイザがすべてのDML変更をコミットした場合はデータが変更され、それによって以降のキャッシュ・アドバイザの評価の動作が変わってきます。たとえば、キャッシュ・アドバイザがOracle DatabaseでDELETE文を評価してコミットした場合、キャッシュ・アドバイザがその評価を再度行うときには削除する行がありません。

アプリケーション・ワークロードまたはSQLチューニング・セットを分析し、Oracle DatabaseとTimesTen Cacheとの間のパフォーマンスを比較した後に、キャッシュ・アドバイザはHTMLレポートを生成し、このレポートには、Oracle DatabaseとTimesTen Cacheを比較したパフォーマンス統計、アプリケーションがアクセスするTimesTenキャッシュ・グループの推奨キャッシュ表の定義およびそのキャッシュ表を参照するSQL文が含まれます。また、このレポートは、ワークロードまたはSQLチューニング・セットで変更なしでTimesTen Cacheで実行できる文、および実行前に変更が必要な文も示します。発生する可能性のある違いの詳細は、付録C「TimesTenデータベースとOracle Databaseの互換性」を参照してください。

キャッシュ・アドバイザはさらに、推奨するキャッシュ・グループ定義に使用できるttIsqlスクリプトも生成します。この、ユーザーによる編集な可能なスクリプトには、CREATE CACHE GROUP、LOAD CACHE GROUP、CREATE INDEX、CREATE SYNONYM、およびCREATE VIEWなどのSQL文が含まれています。

キャッシュ・アドバイザでは最大次の3つのデータベースを使用する必要があります。

- ユーザー・アプリケーションが実行され、アプリケーション・スキーマが存在するターゲットのOracle Database。SQLワークロードはここで取得します。このデータベースで実行されるワークロードは、本番データベースのワークロードとできるだけ近いものである必要があります。さらにキャッシュ・アドバイザは、TimesTenの表サイズを計算するために、ターゲットのOracle Databaseの統計を使用します。ユーザーはターゲットのOracle Databaseで統計が収集されており、それが最新のものであることを確認する必要があります。

- リポジトリOracle Database。キャッシュ・アドバイザはここでターゲットのOracle Databaseで実行されるSQL文のワークロードの分析を行います。

注意:
ターゲット・データベースが本番システムの一部である場合は、キャッシュ・アドバイザ・リポジトリを別の非本番データベースに置きます。ターゲット・データベースがテスト・システムの一部である場合は、設定および処理を簡略化するために、キャッシュ・アドバイザ・リポジトリをターゲットと同じデータベースに置きます。

- TimesTenデータベース(TimesTen Cacheとも呼ばれます)では、推奨されるキャッシュ・グループをキャッシュ・アドバイザが定義して評価しますが、このキャッシュ・グループのキャッシュ表は、アプリケーション・ワークロードがアクセスするターゲットOracle Databaseのテーブルに対応しています。

図10-1 キャッシュ・アドバイザにより使用される3つのデータベース

Oracle DatabaseおよびTimesTenホスト・システムの設定

キャッシュ・アドバイザを使用するには、まずTimesTenをインストールしてから、Oracle DatabaseおよびTimesTenシステムを構成する必要があります。

注意:
TimesTenのインストールの詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』を参照してください。

次の各項では、キャッシュ・アドバイザを実行するための各データベースおよびホストの構成方法を例示しながら説明します。この例では、SQLワークロードを実行するアプリケーションの実例としてQuick Startのサンプルを使用しています。

Oracle DatabaseおよびTimesTenのホストおよびデータベースを設定するには、次のタスクを実行します。

1. ターゲットOracle Databaseの構成

2. リポジトリOracle Databaseの構成

3. TimesTenデータベースの構成

キャッシュ・アドバイザ環境に含まれる各ホストおよびデータベースをインストールおよび構成する際の構成オプションと使用法のガイドラインの詳細は、「キャッシュ・アドバイザの構成オプションと使用法のガイドライン」に関する項を参照してください。

ターゲットOracle Databaseの構成

ターゲットOracle Databaseでは、アプリケーション・スキーマが定義されます。これは、ユーザー・アプリケーションがアクセスするデータベースです。キャッシュ・アドバイザを使用する場合は、ターゲットのデータベースがOracle Database Enterprise Edition 10gリリース2 (10.2.0.4)以上である必要があります。

TimesTen Cacheが使用するターゲット・データベースを設定するには、TimesTenデータベース・システムのオペレーティング・システム・シェルからSQL*Plusを起動し、Oracle Databaseのsysユーザーとしてターゲット・データベースに接続します。この例では、ターゲット・データベースのサービス名をtargetdbとしています。

% cd TimesTen_install_dir/oraclescripts
% sqlplus sys@targetdb as sysdba
Enter password: password

SQL*Plusを使用して、Oracle Database timestenユーザーとキャッシュ管理ユーザーの両方に使用されるデフォルトの表領域を作成します。この表領域は、TimesTen Cacheのオブジェクトを保存するためにのみ使用し、他のアプリケーションと共有しないでください。この例では、デフォルトの表領域の名前をcachetblspとしています。timestenユーザーの詳細は、「Oracle Databaseでのユーザーの作成」を参照してください。

SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/initCacheGlobalSchema.sqlを実行して、timestenユーザーとそのメタデータ表、およびこのユーザーに付与する権限を定義するTT_CACHE_ADMIN_ROLEロールを作成します。デフォルトの表領域を引数としてinitCacheGlobalSchema.sqlスクリプトに渡します。

SQL> CREATE TABLESPACE cachetblsp DATAFILE 'datfttuser.dbf' SIZE 100M;
SQL> @initCacheGlobalSchema "cachetblsp"

次に、SQL*Plusを使用してターゲットOracle Databaseユーザーを作成します(ターゲットOracle Databaseユーザーがまだ存在していない場合)。

注意:
この例ではQuick Startサンプル・プログラムを使用しているため、スキーマ所有者としてorattが作成されます。

ターゲットOracle Databaseユーザーは、SQLワークロード・アプリケーションにより使用される予定で、TimesTenデータベースでのキャッシュ対象であるOracle Databaseオブジェクトを所有します。ターゲットOracle Databaseユーザーは、「Oracle Databaseでのユーザーの作成」で説明されるスキーマ・ユーザーと同じです。

このユーザーに対して、TimesTenデータベースでキャッシュされる表をOracle Databaseに作成するために必要な、少なくとも最小限の権限セットを付与します。この例では、ターゲットOracle Databaseユーザーはorattです。

SQL> CREATE USER oratt IDENTIFIED BY oracle;
SQL> GRANT CREATE SESSION, RESOURCE TO oratt;

次に、SQL*Plusを使用してキャッシュ管理ユーザーを作成します。SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/grantCacheAdminPrivileges.sqlを実行して、キャッシュ・グループ操作を処理するために必要な最小限の権限セットをキャッシュ管理ユーザーに付与します。キャッシュ・グループの詳細は、「キャッシュ・グループおよびキャッシュ表」を参照してください。

注意:
ターゲットOracle Databaseユーザーおよびキャッシュ管理ユーザーは、別のユーザーである必要があります。また、リポジトリ・キャッシュ・アドバイザ・ユーザーを作成する際には、このユーザーも別のユーザーである必要があります。

キャッシュ管理ユーザー名を引数としてgrantCacheAdminPrivileges.sqlスクリプトに渡します。この例では、キャッシュ管理ユーザーをcacheuserとし、そのデフォルトの表領域の名前をcachetblspとしています。キャッシュ管理ユーザーの詳細は、「Oracle Databaseでのユーザーの作成」を参照してください。

SQL> CREATE USER cacheuser IDENTIFIED BY oracache
DEFAULT TABLESPACE cachetblsp QUOTA UNLIMITED ON cachetblsp;
SQL> GRANT SELECT ANY TABLE, DELETE ANY TABLE,
INSERT ANY TABLE, UPDATE ANY TABLE TO cacheuser;
SQL> @grantCacheAdminPrivileges "cacheuser"

SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/ttca_setupTarget.sqlを実行して、次の操作を実行します。

- ターゲットOracle Databaseユーザーに付与する権限を定義するTTCA_TARGET_ROLEロールを作成します。

- ターゲット・データベースでのファイル処理に使用するTTCA_DIRECTORYという名前のOracleディレクトリ・オブジェクトを作成します。ttca_setupTarget.sqlスクリプトは、ターゲット・キャッシュ・アドバイザ・ユーザーが前に作成したローカル・ディレクトリにTTCA_DIRECTORYディレクトリ・オブジェクトを関連付けます。Oracle Databaseディレクトリ・オブジェクトの詳細は、『Oracle Database SQL言語リファレンス』のCREATE DIRECTORYに関する説明を参照してください。

ttca_setupTarget.sqlスクリプトを実行した後に、SQL*Plusセッションを終了します。

次の例では、TTCA_DIRECTORYオブジェクトがまだ作成されていない場合の出力を示します。

SQL> @ttca_setupTarget

This script sets up your target Oracle database for use with the TimesTen
Cache Advisor.

The target Oracle database is the application database that you wish to cache
using TimesTen Application-Tier Database Cache.

This script performs the following actions:
1. Create the TTCA_TARGET_ROLE role, if it does not already exist
2. Create a new directory object on the target Oracle database,
if directed by you to do so
3. Grant read and write access on a new or existing target Oracle database
directory object to the TTCA_TARGET_ROLE role
4. Grant the TTCA_TARGET_ROLE role to the target Oracle database user

Run this script as SYSDBA on the target database.

(You will also need to configure a repository Oracle database that you set up
with the ttca_setupRepository.sql script.)

Please enter a target Oracle database user name to access the target database:
oratt

The TimesTen Cache Advisor requires the use of a directory object on the
target Oracle database for DataPump and file operations.

An Oracle directory object is created with the CREATE DIRECTORY Oracle Data
Definition Language (DDL) statement. A directory object is identified by an
Oracle object name (up to 30 alphanumeric characters) and is associated with
a host-platform-specific directory path (up to 4000 characters).

********************************************************************************
*** Enter the directory path on the target system to use in the definition
*** of TTCA_DIRECTORY
********************************************************************************
? /mysystem/mydirectory/ttca_directory

Create TTCA_DIRECTORY directory object succeeded.

Grant READ and WRITE on TTCA_DIRECTORY directory object to TTCA_TARGET_ROLE role
succeeded.

Grant READ and WRITE on TTCA_DIRECTORY directory object to scott role succeeded.
To revoke privileges granted by this script:
REVOKE ttca_target_role FROM oratt;
DROP ROLE ttca_target_role;
REVOKE READ, WRITE ON DIRECTORY TTCA_DIRECTORY FROM oratt;
No errors.

*******************
**** All done! ****
*******************

TTCA_DIRECTORYオブジェクトがすでに作成されている場合は、次のスクリプトにより、オブジェクトがすでに存在していることが通知および確認されます。

*** The directory object used by cache Advisor (TTCA_DIRECTORY) already exists.
*** Please press ENTER to continue
********************************************************************************
?

リポジトリOracle Databaseの構成

リポジトリOracle Databaseは、ターゲットOracle Databaseで実行されるSQLワークロードの分析をキャッシュ・アドバイザが行う場所です。キャッシュ・アドバイザはリポジトリ・データベースにタスクを保管すると同時に、リポジトリ・データベースでレポートを作成し、スクリプトを生成します。タスクとは、ワークロード、パフォーマンス結果、およびユーザーが指定したキャッシュ・アドバイザ・オプションに関する情報が含まれているオブジェクトです。

- ターゲット・データベースが本番システムの一部である場合は、キャッシュ・アドバイザ・リポジトリを別の非本番データベースに置きます。まずOracle Database Enterprise Edition 10gリリース2 (10.2.0.4)以上のリポジトリ・データベースをインストールして構成します。リポジトリ・データベースのバージョンが、ターゲットOracle Databaseのバージョン以上である必要があります。別のターゲットおよびリポジトリ・データベースを使用する際には、キャッシュ・アドバイザがターゲット・データベースからリポジトリ・データベースにスキーマ定義をコピーするため、別のリポジトリ・データベースをキャッシュ・アドバイザに割り当てる必要があります。キャッシュ・アドバイザ・リポジトリをクリーンアップする際には、データベースを削除します。

- ターゲット・データベースがテスト・システムの一部である場合は、設定および処理を簡略化するために、キャッシュ・アドバイザ・リポジトリをターゲットと同じデータベースに置きます。キャッシュ・アドバイザ・リポジトリをクリーンアップする際には、DROP USER TTCACHEADVISOR CASCADE文を実行します。

TimesTenデータベース・システムのオペレーティング・システム・シェルからSQL*Plusを起動し、Oracle Database sysユーザーとしてリポジトリ・データベースに接続します。この例では、リポジトリ・データベースのサービス名をrepositorydbとしています。

% cd TimesTen_install_dir/oraclescripts
% sqlplus sys@repositorydb as sysdba
Enter password: password

リポジトリ・データベースにSYSDBA権限で接続する必要があります。

SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/ttca_setupRepository.sqlを実行して、次の操作を実行します。

- ターゲットOracle Database上で実行されるSQLワークロード分析に使用されるリポジトリ・データベースに、オブジェクトを所有するユーザーを作成し、これらのオブジェクトを保管するために使用するttca_ts表スペースを作成します。

- リポジトリ・データベースでのファイル処理に使用するOracle Databaseディレクトリ・オブジェクトを作成または指定します。ttca_setupRepository.sqlスクリプトは、リポジトリ・キャッシュ・アドバイザ・ユーザーが前に作成したローカル・ディレクトリにディレクトリ・オブジェクトを関連付けます。Oracle Databaseディレクトリ・オブジェクトの詳細は、『Oracle Database SQL言語リファレンス』のCREATE DIRECTORYに関する説明を参照してください。

ttca_setupRepository.sqlスクリプトを実行した後に、SQL*Plusセッションを終了します。

SQL> @ttca_setupRepository

This script sets up your repository Oracle database for use with the TimesTen
Cache Advisor.

The repository Oracle database is used by the TimesTen Cache Advisor as
an analytical workspace.

This script performs the following actions:
1. Create repository Oracle database user TTCACHEADVISOR (or other user name
that you specify)
2. Grant read and write access on a new or existing repository Oracle database
directory object to the repository database user
3. Create tablespace TTCA_TS, if it does not exist
4. Grant required privileges to the repository database user
5. Create required tables and views owned by the repository database user

Run this script as SYSDBA on the repository database.

(You will also be using a target Oracle database that you set up
with the ttca_setupTarget.sql script.)

Press ENTER to create the repository Oracle database user with
user name TTCACHEADVISOR, or enter an alternative user name for
the repository database user:
Please enter a password for the TTCACHEADVISOR user:
Please confirm the password for the TTCACHEADVISOR user:

The TimesTen Cache Advisor requires the use of a directory object on the
repository Oracle database for DataPump and file operations.

An Oracle directory object is created with the CREATE DIRECTORY Oracle Data
Definition Language (DDL) statement. A directory object is identified by an
Oracle object name (up to 30 alphanumeric characters) and is associated with
a host-platform-specific directory path (up to 4000 characters).

********************************************************************************
*** Enter the directory path on the repository system to use in the definition
*** of TTCA_DIRECTORY
********************************************************************************
? /mysystem/mydirectory/ttca_directory

Create TTCA_TS tablespace succeeded.

Create TTCACHEADVISOR user succeeded.

Create TTCA_DIRECTORY directory object succeeded.

*******************
**** All done! ****
*******************

To employ other directories as directory objects on the repository
database, grant READ,WRITE ON DIRECTORY <directory_name> TO TTCACHEADVISOR

TTCA_DIRECTORYオブジェクトがすでに作成されている場合は、次のスクリプトにより、オブジェクトがすでに存在していることが通知および確認されます。

*** The directory object used by cache Advisor (TTCA_DIRECTORY) already exists.
*** Please press ENTER to continue
********************************************************************************
?

TT_CS表領域がすでに作成されている場合、出力には次の文は表示されません。

Create TTCA_TS tablespace succeeded.

TimesTenデータベースの構成

TimesTenデータベースでは、キャッシュ・アドバイザが、アプリケーション・ワークロードがアクセスするターゲットOracle Databaseの表に対応するキャッシュ表を持つ推奨キャッシュ・グループを定義し、評価します。TimesTenデータベースはキャッシュ・アドバイザのみに使用されるテスト・データベースであり、他のアプリケーションと共有しないでください。

次のデータ・ソース名(DSN)の例では、ターゲットOracle Databaseのネット・サービス名をtargetdbとし、そのデータベース・キャラクタ・セットをAL32UTF8としています。TimesTenのデータベース・キャラクタ・セットは、ターゲットOracle Databaseのデータベース・キャラクタ・セットに一致する必要があります。SQL*Plusで任意のユーザーとして次の問合せを実行することにより、Oracle Databaseのデータベース・キャラクタ・セットを決定できます。

SQL> SELECT value FROM nls_database_parameters
WHERE parameter='NLS_CHARACTERSET';

ホーム・ディレクトリに存在する.odbc.iniファイルまたはTimesTen_install_dir/info/sys.odbc.iniファイルにTimesTen DSN cacheadvを作成し、次の接続属性を設定します。

注意:
この例では、キャッシュ・アドバイザがCacheGridEnable属性を「0」に設定したため、ユーザーはグリッドを作成する必要がありません。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCacheGridEnableに関する説明を参照してください。

[cacheadv]
DataStore=/users/OracleCache/cacheadv
PermSize=64
OracleNetServiceName=targetdb
DatabaseCharacterSet=AL32UTF8
CacheGridEnable=0

注意:

Oracle DatabaseからデータをキャッシュするTimesTenデータベースのDSNを定義する方法の詳細は、「TimesTenデータベースのDSNの定義」を参照してください。

TimesTen DSNの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースの管理に関する説明を参照してください。

TimesTen Cacheが使用するTimesTenデータベースをセットアップします。TimesTenインスタンス管理者ユーザーとして、オペレーティング・システム・シェルからTimesTenシステムでttIsqlユーティリティを起動し、cacheadv DSNに接続して、ターゲットOracle Databaseのデータをキャッシュするために使用するTimesTenデータベースを作成します。

% ttIsql cacheadv

ttIsqlを使用してキャッシュ・マネージャ・ユーザーを作成しますが、このユーザーには、同じ名前を持つコンパニオンOracle Databaseユーザーがいます。このユーザーに、キャッシュ・グループに対する操作を作成、実行するために必要な最小限の権限セットを付与します。次の例では、キャッシュ・マネージャ・ユーザー名はcacheuserで、キャッシュ管理ユーザーは、そのコンパニオンOracle Databaseユーザーとして機能します。

Command> CREATE USER cacheuser IDENTIFIED BY ttcache;
Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE TO cacheuser;

注意:

キャッシュ・マネージャ・ユーザーの詳細は、「TimesTenユーザーの作成」を参照してください。

次に、ttIsqlを使用して、ttCacheUidPwdSet組込みプロシージャをコールし、キャッシュ管理ユーザーの名前およびパスワードを設定します。その後、ttIsqlセッションを終了します。

Command> call ttCacheUidPwdSet('cacheuser','oracache');
Command> exit

キャッシュ管理ユーザーの名前とパスワードは、TimesTenデータベースに1回のみ設定する必要があります。TimesTenデータベースでこの設定が使用される仕組みの詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。

キャッシュ・アドバイザの構成オプションと使用法のガイドライン

次の各項ではサポートされている構成オプションおよびキャッシュ・アドバイザを使用するためのガイドラインを説明します。

- ホストおよびデータベースのサポートされている構成オプション

- 制限と前提

ホストおよびデータベースのサポートされている構成オプション

キャッシュ・アドバイザは、キャッシュ・アドバイザ環境に含まれるホストおよびデータベースについて次の構成オプションをサポートしています。

- 単一のOracle Database(Oracle Database Enterprise Edition 10gリリース2 (10.2.0.4)以上である必要がある)は、ターゲット・データベースおよびリポジトリ・データベースの両方として機能します。ターゲットOracle Databaseはテスト・データベースである必要があり、本番データベースであることはできません。
TimesTenデータベースは、より正確なパフォーマンス分析を行うために別のホスト・システムに常駐させるか、またはデモンストレーションの目的でOracle Databaseと同じホストに常駐させることができます。

これは優先される構成であり、設定および処理が最も簡単になります。

- 単一のOracle Database(Oracle Database Enterprise Edition 10gリリース2 (10.2.0.4)以上である必要がある)は、リポジトリまたはTimesTenデータベースなしでターゲット・データベースとして機能します。
ターゲット・データベースは、稼働中の本番データベースの一部またはテスト・システムの一部にすることができます。この構成は、-exportコマンド・ライン・オプションでのみサポートされています。

この構成では、遅延分析でのアプリケーションSQLワークロードおよびスキーマ定義を取得できます。-importオプションを他のサポートされている構成のいずれかとともに使用して、遅延分析を実行します。

- Oracle Database Enterprise Edition 10gリリース2 (10.2.0.4)以上のターゲットOracle Database、Oracle Database Enterprise Edition 10gリリース2 (10.2.0.4)以上のリポジトリOracle DatabaseおよびTimesTenデータベースはすべて、同じまたは別のホスト・システムに存在する別のデータベースです。
ターゲットOracle DatabaseはリポジトリOracle Databaseよりも新しいバージョンであることはできません。-evalSqlPerfコマンド・ライン・オプションを使用してパフォーマンス分析を行う場合、TimesTenデータベースは別のホストに存在して、ターゲットOracle Databaseはテスト・システムの一部である必要があり、稼働中の本番システムであることはできません。クリーンアップを使用可能にするためには、リポジトリ・データベースをキャッシュ・アドバイザに割り当てる必要があります。

この構成では、リソースを柔軟に割り当てることができます。

制限と前提

キャッシュ・アドバイザで推奨されるキャッシュ・スキーマの設計では、ユーザー・アプリケーションがTimesTenデータベースへの接続とは別に、ターゲットOracle Databaseへの接続を確立することを前提としています。

キャッシュ・アドバイザはほとんどのTimesTen DSN属性設定をサポートしています。ただし、キャッシュ・アドバイザは次の属性設定をサポートしていません。

- Temporary=1 (TimesTen一時データベースまたはTimesTen非永続データベース)

- TypeMode=1 (TimesTenデータ型)

- DDLCommitBehavior=1 (DDL文を自動的にコミットしない)

- DuplicateBindMode=1 (同じ名前を持つパラメータを同一とみなす)

- PLSQL=0 (TimesTen PL/SQLの使用を無効にする)

- DynamicLoadEnable=0 (Oracle Database表からTimesTenキャッシュ表へのデータの動的なロードを無効にする)

SQLワークロード・アプリケーションの実行

この例では、ターゲットOracle DatabaseでSQLワークロードを生成するのにスループット・ベンチマークのOCIバージョン(tptbmOCI)を使用しています。

TimesTenシステム上の任意のオペレーティング・システム・ユーザーとしてデモ・プログラムをビルドし、実行します。ターゲット・データベースのネット・サービス名はtargetdbです。ターゲットOracle Databaseユーザーはorattです。orattユーザーのパスワードはoracleです。アプリケーション表には25^2 = 625行のデータが投入され、1トランザクション当たりのSQL文の最大数は1000です。

% cd TimesTen_install_dir/quickstart/sample_code/oci
% make tptbmOCI
% tptbmOCI -service targetdb -user oratt -key 25 -max 1000
Enter password for oratt : password
...
Load the oratt.vpn_users table with 625 rows of data
Run 10000 txns with 1 process: 80% read, 20% update, 0% insert, 0% delete

キャッシュ・アドバイザの実行

tptbmOCIワークロード・アプリケーションがターゲットOracle Databaseで実行中に、別のウィンドウでインスタンス管理者ユーザーとしてオペレーティング・システム・シェルからTimesTenシステムに対してttCacheAdvisorユーティリティを実行します。評価に含めるターゲットOracle Database、リポジトリOracle Database、およびTimesTenデータベースを指定します。

% ttCacheAdvisor -oraTarget -oraConn "oratt@targetdb" \
-oraRepository -oraConn "ttcacheadvisor@repositorydb" \
-ttConn "DSN=cacheadv;UID=cacheuser" \
-report /home/ttuser/CAreport -task sampletask -captureCursorCache 10 \
-evalSqlPerf

Enter password for Oracle user oratt@targetdb: password
31.16:21:03 Info: beginning Oracle batch operation checkAuthorization on
oratt@targetdb
31.16:21:03 Info: Oracle batch operation checkAuthorization completed
Enter password for Oracle user ttcacheadvisor@repositorydb: password
31.16:21:05 Info: beginning Oracle batch operation checkAuthorization on
ttcacheadvisor@repositorydb
31.16:21:06 Info: Oracle batch operation checkAuthorization completed
31.16:21:06 Info: beginning Oracle batch operation checkOraUser on
oratt@targetdb
31.16:21:06 Info: Oracle batch operation checkOraUser completed
31.16:21:06 Info: beginning TimesTen batch operation checkUserExists on
"dsn=cacheadv;uid=cacheuser"
31.16:21:07 Info: TimesTen batch operation checkUserExists completed

Enter password for TimesTen user cacheuser (dsn=cacheadv): password
31.16:21:10 Info: beginning TimesTen batch operation checkTTuserAuthorization
on "dsn=cacheadv;uid=cacheuser"
31.16:21:11 Info: TimesTen batch operation checkTTuserAuthorization completed
Enter password for Oracle user cacheuser@targetdb: password
31.16:21:14 Info: beginning Oracle batch operation checkTToraclepwdAttribute
on cacheuser@targetdb
31.16:21:14 Info: Oracle batch operation checkTToraclepwdAttribute completed
31.16:21:14 Info: beginning Oracle batch operation verifyTargetConfig on
oratt@targetdb
31.16:21:25 Info: Oracle batch operation verifyTargetConfig completed
...

前の例では、次のようにttCacheAdvisorユーティリティを使用していました。

- -oraTargetオプションはターゲットOracle Databaseを識別します。-oraTargetの-oraConnオプションは、ターゲット・データベースのターゲットOracle Databaseユーザーとネット・サービス名を接続文字列で指定します。

- -oraRepositoryオプションはリポジトリOracle Databaseを識別します。-oraRepositoryの-oraConnオプションは、ターゲットOracle Databaseに対して実行されるSQLワークロード分析に使用されるリポジトリ・データベース内のオブジェクトを所有しているユーザーと、リポジトリ・データベースのネット・サービス名を接続文字列で指定します。

- -ttConnオプションはTimesTenデータベースを識別します。DSNおよびキャッシュ・マネージャ・ユーザーを接続文字列で指定します。

- -reportオプションは、レポート・ファイルが存在するデフォルト・ディレクトリの場所をオーバーライドします。

- -taskオプションはデフォルトのタスク名をオーバーライドします。

- -captureCursorCacheオプションは、10分の取得ウィンドウ期間にターゲット・データベースで実行されるSQLワークロードをttCacheAdvisorユーティリティが取得するように指定します。SQL文の一部で取得できないことがある場合は、取得期間を長くしてください。

- -evalSqlPerfオプションは、ターゲットOracle DatabaseとTimesTenデータベース上で実行されているワークロード間のパフォーマンス比較を生成するために指定されます。

各データベースについて接続文字列でパスワードが指定されていない場合、ttCacheAdvisorユーティリティは、キャッシュ・アドバイザの評価で使用されるTimesTenデータベースとOracle Databaseに接続している各ユーザーのパスワードを求めるプロンプトを出します。

この例では、次のユーザー・パスワードが要求されます。

- ターゲットOracle Databaseユーザーのパスワード。この例では、oratt@targetdbのパスワードはoracleです。

- ターゲットOracle Databaseに対して実行されるSQLワークロード分析に使用されるリポジトリOracle Databaseで、複数のオブジェクトを所有しているユーザーのパスワード。この例では、ttcacheadvisor@repositorydbのパスワードはttcaです。

- TimesTenキャッシュ・マネージャ・ユーザーのパスワード。この例では、cacheuserのパスワードはttcacheです。

- キャッシュ管理ユーザーのパスワード。この例では、cacheuser@targetdbのパスワードはoracacheです。このパスワードが要求されるのは、ターゲットOracle DatabaseとTimesTenデータベース上で実行されるワークロード間のパフォーマンス比較を生成するために、-evalSqlPerfオプションが指定されているからです。

ttCacheAdvisorユーティリティは、ターゲット・データベースで実行中のアプリケーション・ワークロードを分析する際、定期的にステータス・メッセージを生成します。

ttCacheAdvisorが完了すると、パフォーマンス統計および、ワークロードのどのSQL文がTimesTenで実行できるか、または実行できないかなどの情報を示すHTMLレポートが作成されます。デフォルトで、レポートを構成する各ファイルは、このユーティリティが起動されたtask-nameディレクトリに存在します。この例では、-reportオプションを使用してこのディレクトリが指定されます。レポートを表示するには、レポート・ファイルのディレクトリにあるindex.htmファイルをWebブラウザから開きます。デフォルトで、タスク名はuserName_hostName_timestampです。この例では、タスク名が-taskオプションによってオーバーライドされます。

また、ttCacheAdvisorユーティリティは、-reportオプションで指定されたディレクトリにttCacheAdvisor_taskName_timestamp.sqlという名前の実装スクリプト・ファイルも生成します。このスクリプトは、アプリケーションがアクセスしたOracle Databaseオブジェクトのキャッシュを実装するために使用されるTimesTenデータベースにオブジェクトを作成するために、ttIsqlユーティリティにより実行できます。

% ttIsql -f ttCacheAdvisor_sampletask_20120531164101.sql
"DSN=cacheadv;UID=cacheuser;OraclePWD=oracache"

レポートと実装スクリプトの詳細は、「キャッシュ・アドバイザ・レポートの表示」を参照してください。

ttCacheAdvisorの構文については、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAdvisorに関する説明を参照してください。

データ転送にNFSまたはFTPを使用することによるパフォーマンスの向上

注意:
この項で説明されているオプションについては、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheAdvisorに関する説明を参照してください。

キャッシュ・アドバイザは、DataPumpを使用してデータベースとの間でデータを移動します。DataPumpでは、ネットワークに接続されていないローカルな関連ディレクトリ・パスを持つOracleディレクトリ・オブジェクトが必要になります。キャッシュ・アドバイザは、デフォルトで、設定スクリプトにより作成されるTTCA_DIRECTORY Oracleディレクトリ・オブジェクトを-exportおよび-importオプションを指定して使用することにより、DataPumpを使用して情報のエクスポートおよびインポートを行います。さらにキャッシュ・アドバイザは、デフォルトで、OCI接続を-oraConnオプションを指定して使用することにより、ファイルの転送を行います。さらに便利に簡単に使用するために、OCI接続を介してファイルを転送するためにキャッシュ・アドバイザが使用するメカニズムでは、NFSまたはftpより速度を約3倍遅くすることができます。ファイル転送のパフォーマンスは、ターゲットおよびリポジトリが別のデータベースに存在する場合は、-export、-importまたは-captureCursorCacheの各オプションのみに影響を受けます。

注意:
必要に応じて、データ・ファイル転送オプションを-oraDirNfsまたは-ftpとして構成できますが、これが関係するのはファイル転送のパフォーマンスを向上させる場合のみです。

ファイル転送のパフォーマンスを向上させるために、必要に応じて-oraDirNfsまたは-ftpオプションを使用できます。TTCA_DIRECTORYディレクトリ・オブジェクトを使用する際は、-oraDirNfsまたは-ftpオプションでは構成しません。このため、-oraDirNfsまたは-ftpオプションを使用する際には、別のディレクトリ・オブジェクトを-oraDirObjectオプションで指定して構成する必要があります。

ディレクトリを構成するには、次の手順を実行します。

1. Oracle Databaseにログオンして、新しいディレクトリ・オブジェクトを作成します。ディレクトリ・オブジェクトを作成するには、次のコマンドを実行します。

CREATE DIRECTORY dir_name AS /local_dir_path/subdir_path;

指定するディレクトリ・パスはローカル・ディレクトリにする必要があり、ネットワークに接続することはできません。

2. ターゲットまたはリポジトリOracle Databaseが存在するホスト・システムにログオンし、Oracleディレクトリ・オブジェクトに関連付けられているディレクトリ・パスを持つディレクトリを作成します。このディレクトリは、ターゲット・システム上のどのオペレーティング・システム・ユーザーでも作成できます。このディレクトリは、ホスト・システムに対してローカルで、ネットワークに接続されていないデバイス上に作成する必要があります。
このディレクトリの所有者を、キャッシュ・アドバイザ・ユーザーと呼びます。次の例では、ターゲット・キャッシュ・アドバイザ・ユーザーはca_usrで、ディレクトリは/local/ca_usr/ca_dirです。

% mkdir /local/ca_usr/ca_dir

3. ディレクトリが存在するファイル・システムを決定します。Linuxシステムでは、dfオペレーティング・システム・コマンドを実行してこの情報を取得できます。この例では、/local/ca_usr/ca_dirディレクトリが存在するファイル・システムを/dev/sda1としています。

4. キャッシュ・アドバイザがホスト・システムのDataPumpダンプ・ファイルを分析するためには、その内容にアクセスできる必要があります。ただし、それらのファイルにはDataPumpにより権限が設定されているため、NFSはファイルにアクセスしたりftpを使用してファイルをリポジトリに転送することはできません。リポジトリ・システムからダンプ・ファイルにアクセスするには、ターゲット・システム上のファイルが存在する予定のディレクトリに、アクセス・コントロール・リスト(ACL)を設定します。
オペレーティング・システム・ルート・ユーザーとして、ファイル・システムに対するACLの設定を有効化します。

# mount -o remount,acl /dev/sda1

5. キャッシュ・アドバイザ・ユーザーのみがそのディレクトリの読取りおよび書込みができるように、ディレクトリに対する権限を変更します。次に、キャッシュ・アドバイザ・ユーザーおよびホスト・システム上のOracle Databaseサーバーを実行しているオペレーティング・システム・ユーザー(通常はoracleユーザー)に対して、読取り、書込みおよび実行を行うために、そのディレクトリおよびディレクトリに作成されるすべてのファイルに対してACLを設定します。Linuxシステムでは、オペレーティング・システムのsetfaclコマンドを実行してACLを設定できます。

% chmod 700 /local/ca_usr/ca_dir
% setfacl -m u:ca_usr:rwx /local/ca_usr/ca_dir
% setfacl -m d:u:ca_usr:rwx /local/ca_usr/ca_dir
% setfacl -m u:oracle:rwx /local/ca_usr/ca_dir
% setfacl -m d:u:oracle:rwx /local/ca_usr/ca_dir

キャッシュ・アドバイザ・レポートの表示

この項では、キャッシュ・アドバイザにより生成されるレポート・ページの例を示します。レポートは次のWebブラウザを使用して表示できます。

- Firefox 3.6以上

- Chrome 7以上

- Safari 4以上

レポートを表示するには、レポート・ファイルのディレクトリにあるindex.htmファイルをWebブラウザから開きます。

ttCacheAdvisorユーティリティが実行されたときに-evalSqlPerfオプションが指定されていた場合、レポートはターゲットOracle Databaseで実行されたSQL SELECT文の平均応答時間を示します。また、ユーザーが指定したキャッシュ・サイズを持つTimesTenデータベースでこれらの文が実行されたときの平均応答時間も示します。TimesTenの完全なキャッシュ・サイズは、SQLワークロードによってアクセスされたすべてのオブジェクトをキャッシュするために必要であり、TimesTenがサポートできるTimesTenデータベースの最小サイズです。

図10-2 キャッシュ・アドバイザ・レポートのホーム・ページ

図10-3 キャッシュ・アドバイザの結果と推奨

ワークロードで実行されたSQL文は、ホーム・ページ上にあるワークロード内の文の数を示すSQL文列の下のリンクをクリックすることにより、表示できます。この場合は、「2/2」という意味の最初の2のリンクをクリックします。

図10-4 ワークロードで実行されたSQL文の数の表示

個々のSQL文をクリックすれば、その文の応答時間やその他の統計値を表示できます。この例では、2番目の文のリンクをクリックしたときにSELECT文に関する次の情報が表示されます。

図10-5 キャッシュ・アドバイザの評価中に実行された特定のSQL文の情報

キャッシュ・グループの名前をクリックすると、キャッシュ・グループとキャッシュ表の定義およびそのキャッシュ・グループを参照したSQL文を表示できます。この例では、CG1_USERSPECCACHEリンクをクリックしたときに次のレポート・ページが表示されます。

図10-6 キャッシュ・グループの詳細

図10-7 キャッシュ・グループに使用されるSQL文

ホーム・ページから「Configure an TimesTen Cache for your application」リンクをクリックすることで、実装スクリプトのテキストにアクセスできます。その後、次のページから「Implementation Script」リンクをクリックします。

注意:
実装スクリプトの詳細は、「キャッシュ・アドバイザの実行」を参照してください。

次に、実装スクリプトの例を示します。

SHOW ERRORS;
SET ECHO OFF;
SET DEFINE ON;
SET SERVEROUTPUT ON;
PROMPT Welcome to the TimesTen CacheAdvisor (ttCacheAdvisor).
PROMPT
PROMPT ttCacheAdvisor generated this script to implement its recommendations.
PROMPT The first step is to create the necessary TimesTen user accounts to
PROMPT receive the recommended cache groups and associated indexes, views,
PROMPT materialized views and sequences. This script will now prompt you for
PROMPT the password for each account to be created. Be sure to use the same
PROMPT password for each TimesTen user account as on Oracle.
PROMPT
PROMPT NOTE: If an error occurs or for any reason, you can abort this script at
PROMPT any time by pressing the control and C keys (^C) simultaneously.
PROMPT Sometimes it is necessary to press ^C multiple times followed by
PROMPT pressing ENTER.
ACCEPT ORAUSER_pwd CHAR PROMPT 'Enter user ORAUSER password (use same password
as on Oracle)? 'HIDE
ACCEPT ORAUSER_pwd2 CHAR PROMPT 'Confirm user ORAUSER password? ' HIDE
COMMIT;
EXEC createUser ('ORAUSER','&&ORAUSER_pwd','&&ORAUSER_pwd2');
COMMIT;
DROP PROCEDURE createUser;
ACCEPT answer CHAR PROMPT 'Press ENTER to continue, ^C to abort:'
EXEC execImmediate ('CALL ttCacheStart');
EXEC execImmediate ('CALL ttRepStop');
EXEC execImmediate ('DROP CACHE GROUP CG1_USERSPECCACHE');
COMMIT;
COMMIT;
CREATE ASYNCHRONOUS WRITETHROUGH CACHE GROUP CG1_USERSPECCACHE
FROM ORAUSER.VPN_USERS
( VPN_ID NUMBER(5,0) NOT NULL,
VPN_NB NUMBER(5,0) NOT NULL,
DIRECTORY_NB CHAR(10 BYTE) NOT NULL,
LAST_CALLING_PARTY CHAR(10 BYTE) NOT NULL,
DESCR CHAR(100 BYTE) NOT NULL,
PRIMARY KEY (VPN_ID, VPN_NB)
);
COMMIT;
LOAD CACHE GROUP CG1_USERSPECCACHE COMMIT EVERY 256 ROWS;
COMMIT;
CALL ttOptUpdateStats ('ORAUSER.VPN_USERS',1);
COMMIT;
COMMIT;
COMMIT;
EXEC execImmediate ('CALL ttRepStart');
COMMIT;

スクリプトの名前はttCacheAdvisor_task-name_timestamp.sqlであり、ttCacheAdvisorユーティリティが起動されたディレクトリに存在します。このスクリプトは、アプリケーションがアクセスしたOracle Databaseオブジェクトのキャッシュを実装するために使用されるTimesTenデータベースにオブジェクトを作成するために、ttIsqlユーティリティにより実行できます。

% ttIsql -f ttCacheAdvisor_sampletask_20120531164101.sql
"DSN=cacheadv;UID=cacheuser;OraclePWD=oracache"

ターゲットOracle Database (ワークロード収集)、リポジトリOracle DatabaseおよびTimesTenデータベース(クライアント)に関するデータベース情報およびシステム情報を取得するには、ホーム・ページから「Click here for information about the configuration that was used to generate this report」リンクをクリックします。

図10-8 構成の概要ページ

図10-9 リポジトリおよびクライアント構成情報

OracleおよびTimesTenのデータベースおよびホスト・システムのクリーンアップ

次の各タスクを実行して、ターゲットOracle Databaseに対して実行されたアプリケーション・ワークロードの評価が完了した後に、Oracle DatabaseおよびTimesTenシステムを元の状態に復元します。

1. ターゲットOracle Databaseおよびホスト・システムのクリーンアップ

2. リポジトリOracle Databaseおよびホスト・システムのクリーンアップ

3. TimesTenデータベースおよびホスト・システムのクリーンアップ

ターゲットOracle Databaseおよびホスト・システムのクリーンアップ

TimesTenデータベース・システムのオペレーティング・システム・シェルからSQL*Plusを起動し、sysユーザーとしてターゲットOracle Databaseに接続します。その後で、SQL*Plusを使用して次のようにターゲットOracle Databaseおよびそのホスト・システムをクリーンアップします。

1. timestenユーザー、orattターゲットOracle Databaseユーザー(ターゲット・データベースの構成前にこのユーザーが存在しなかったため、作成した場合)およびcacheuserキャッシュ管理ユーザーを削除します。

% sqlplus sys@targetdb as sysdba
Enter password: password
SQL> DROP USER timesten CASCADE;
SQL> DROP USER oratt CASCADE;
SQL> DROP USER cacheuser CASCADE;

注意:
DROP USER文のCASCADEを指定すると、ユーザーそのものが削除される前にすべてのオブジェクト(そのユーザーが所有する表など)が削除されます。

2. TT_CACHE_ADMIN_ROLEロール、TTCA_TARGET_ROLEロールおよびTTCA_DIRECTORYディレクトリ・オブジェクトを削除します。

SQL> DROP ROLE TT_CACHE_ADMIN_ROLE;
SQL> DROP ROLE TTCA_TARGET_ROLE;
SQL> DROP DIRECTORY TTCA_DIRECTORY;
SQL> exit

3. timestenユーザーおよびキャッシュ管理ユーザーが使用するcachetblspデフォルト表領域(表領域の内容およびそのデータ・ファイルを含む)を削除します。SQL*Plusセッションを終了します。

SQL> DROP TABLESPACE cachetblsp INCLUDING CONTENTS AND DATAFILES;
SQL> exit

注意:
前述の手順では、キャッシュ・アドバイザによりワークロード用に作成されたスキーマは削除されません。このスキーマを別のアプリケーション・ワークロードで使用できるように保持して、同じスキーマを使用する場合、またはユーザーおよび表領域の再作成後に同じワークロードを再実行する場合に使用できます。保持しない場合は、作成されたスキーマを手動で削除するか、またはそのデータベースを破棄する(ターゲット・データベースがテスト・データベースの場合)ことができます。

リポジトリOracle Databaseおよびホスト・システムのクリーンアップ

リポジトリが別の割当て済Oracle Databaseに存在する場合は、リポジトリ・データベースを削除します。

リポジトリがターゲットと同じOracle Databaseに存在する場合は、TimesTenデータベース・システムのオペレーティング・システム・シェルからSQL*Plusを起動し、sysユーザーとしてリポジトリOracle Databaseに接続します。SQL*Plusを次のように使用して、リポジトリOracle Databaseおよびそのホスト・システムをクリーンアップします。

1. ttcacheadvisorユーザーを削除します(ターゲットOracle Databaseで実行されるSQLワークロードの分析に使用されるリポジトリ・データベース内のオブジェクトの所有者です)。

% sqlplus sys@repositorydb as sysdba
Enter password: password
SQL> DROP USER ttcacheadvisor CASCADE;

2. TTCA_DIRECTORYディレクトリ・オブジェクトを削除します。

SQL> DROP DIRECTORY TTCA_DIRECTORY;

3. ttCacheAdvisorユーザーが使用したttca_ts表領域を、その表領域の内容と、そのデータ・ファイルを含めて削除します。SQL*Plusセッションを終了します。

SQL> DROP TABLESPACE ttca_ts INCLUDING CONTENTS AND DATAFILES;
SQL> exit

TimesTenデータベースおよびホスト・システムのクリーンアップ

ttIsqlユーティリティを開始して、cacheadv DSNに、TimesTenインスタンス管理者ユーザーとして接続します。TimesTenデータベースをクリーンアップするには、次の手順を実行します。

1. ttIsqlを使用して、DROP ANY TABLE権限をキャッシュ・マネージャ・ユーザーに付与し、このユーザーがキャッシュ・グループを削除するときに基礎となるキャッシュ表を削除できるようにします。その後、ttIsqlセッションを終了します。

% ttIsql cacheadv
Command> GRANT DROP ANY TABLE TO cacheuser;
Command> exit

2. ttIsqlユーティリティを起動して、cacheadv DSNにキャッシュ・マネージャ・ユーザーとして接続します。TimesTenキャッシュ・マネージャ・ユーザーcacheuserのパスワードはttcacheです。ttIsqlを使用してttRepStop組込みプロシージャをコールし、TimesTenデータベースのレプリケーション・エージェントを停止します。cg1_userspeccache AWTキャッシュ・グループを削除します。ttCacheStop組込みプロシージャをコールして、TimesTenデータベースのキャッシュ・エージェントを停止します。このttIsqlセッションを終了します。

% ttIsql "DSN=cacheadv;UID=cacheuser;OraclePWD=oracache"
Enter password for 'cacheuser': password
Command> call ttRepStop;
Command> DROP CACHE GROUP cg1_userspeccache;
Command> call ttCacheStop;
Command> exit

3. ttDestroyユーティリティを使用してcacheadv DSNに接続し、TimesTenデータベースを破棄します。

% ttDestroy cacheadv

11 Oracle RAC環境でのTimesTen Application-Tier Database Cacheの使用

次の各項では、Oracle Real Application Clusters (Oracle RAC)環境でのTimesTen Application-Tier Database Cache (TimesTen Cache)の使用方法について説明します。

- Oracle RAC環境でのTimesTen Cacheの動作

- Oracle RAC環境でのTimesTen Cacheの使用の制限

- Oracle RAC環境でのTimesTen Cacheの設定

Oracle RAC環境でのTimesTen Cacheの動作

Oracle RACでは、共有リソース(クラスタウェア共有ディスクに存在するすべてのデータファイル、制御ファイル、PFILEおよびREDOログ・ファイルを含む)を持つ1つのOracle Databaseに複数のOracle Databaseインスタンスでアクセスできます。Oracle RACでは、高可用性が提供されるとともに、読取り/書込み一貫性およびロード・バランシングが処理されます。

Fast Application Notification(FAN)は、Oracle Database 10g リリース2でOracle Call Interface(OCI)に統合されたOracle RAC機能です。FANによって、FANイベントをサブスクライブするアプリケーションにクラスタ内の変更がパブリッシュされます。FANによって、次に示す不要な処理が実行されなくなります。

- サービスが停止した場合の接続の試行

- サービスがダウンした場合のトランザクション処理終了の試行

- TCP/IPタイムアウトの待機

Oracle RACおよびFANの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

TimesTen Cacheでは、FANと統合されたOCIを使用してOracle Databaseイベントの通知を受信します。FANがある場合、TimesTen Cacheでは1分以内に接続障害が検出されます。TimesTen Cacheでは、FANがない場合、Oracle Database障害の通知の受信に数分かかる可能性があります。FANがない場合にTimesTen Cacheで接続障害を検出するのは、次回にその接続が使用されるとき、またはTCP/IPタイムアウトが発生したときになります。TimesTen Cacheを使用すると、ユーザーの介入なしでOracle Database障害から迅速にリカバリできます。

TimesTen Cacheでは、透過的アプリケーション・フェイルオーバー(TAF)も使用されますが、これは障害発生後にアプリケーションを再接続する方法を指定できるOracle Net Servicesの機能です。TAFの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。TAFでは、Oracle Databaseへの再接続を4分間試行します。再接続が成功しない場合は、キャッシュ・エージェントが再起動され、1分ごとにOracle Databaseへの再接続が試行されます。

注意:
AgentFailoverTimeoutパラメータを指定して接続を確立する際に、TAFが再試行する時間を構成できます。詳細は、「Oracle RAC環境でのTimesTen Cacheの設定」を参照してください。

OCIアプリケーションでは、次のいずれかのタイプのOracle Netフェイルオーバー機能を使用できます。

- NONE: フェイルオーバー機能は使用されません。このタイプでは、フェイルオーバーが発生しないように明示的に指定することもできます。これがデフォルトのフェイルオーバー機能です。

- SESSION: アプリケーションの接続が失われると、そのアプリケーション用の新しい接続が自動的に作成されます。このタイプのフェイルオーバーでは、選択した項目のリカバリは試行されません。

- SELECT: このタイプのフェイルオーバーでは、フェイルオーバー前にカーソルから行のフェッチを開始していたアプリケーションは、フェイルオーバー後に行のフェッチを続行できます。

TimesTen Cacheの動作は、TAFのアクションおよびTAFの構成方法によって異なります。デフォルトでは、Oracle RAC環境でTimesTen Cacheを使用している場合、TAFおよびFANのコールバックがインストールされます。TAFおよびFANの機能が不要な場合は、RACCallback接続属性を0に設定します。

表11-1に、様々なTAFフェイルオーバー・タイプが指定されたOracle RAC環境でのTimesTen Cache処理の動作を示します。

表11-1 Oracle RAC環境でのTimesTen Cache処理の動作

処理

TAFフェイルオーバー・タイプ

Oracle Databaseで接続障害が発生した後の動作

自動リフレッシュ

NONE

キャッシュ・エージェントが自動的に停止して再起動し、Oracle Databaseで接続が確立できるようになるまで待機します。この動作は、Oracle RAC以外の環境の場合と同様です。

ユーザーが介入する必要はありません。

自動リフレッシュ

SESSION

次のいずれかが発生します。

- 障害が発生したすべての接続がリカバリされます。実行中だった自動リフレッシュ処理がロールバックされ、再試行されます。

- TAFがタイムアウトになるか、または接続をリカバリできない場合は、キャッシュ・エージェントが自動的に停止して再起動し、Oracle Databaseで接続が確立できるようになるまで待機します。

- いずれの場合も、ユーザーが介入する必要はありません。

自動リフレッシュ

SELECT

次のいずれかが発生します。

- 接続障害が発生した時点から自動リフレッシュ処理が再開されます。

- 実行中だった自動リフレッシュ処理がロールバックされ、再試行されます。

- TAFがタイムアウトになるか、または接続をリカバリできない場合は、キャッシュ・エージェントが自動的に停止して再起動し、Oracle Databaseで接続が確立できるようになるまで待機します。

- いずれの場合も、ユーザーが介入する必要はありません。

AWT

NONE

AWTキャッシュ・グループのレプリケーション・エージェントのレシーバ・スレッドが終了します。新しいスレッドが作成され、そのスレッドによってOracle Databaseへの接続が試行されます。

ユーザーが介入する必要はありません。

AWT

Session、Select

次のいずれかが発生します。

- 接続がリカバリされ、コミットされていないDML処理がトランザクションに存在する場合、そのトランザクションはロールバックされた後で再発行されます。

- 接続がリカバリされ、コミットされていないDML処理が存在しない場合は、ロールバックせずに新しい処理を発行できます。

いずれの場合も、ユーザーが介入する必要はありません。

SWT、伝播、フラッシュおよびパススルー

NONE

接続が失われたことがアプリケーションに通知されます。キャッシュ・エージェントがOracle Databaseから切断され、現在のトランザクションがロールバックされます。変更されたすべてのセッション属性が失われます。

次のパススルー処理中に、キャッシュ・エージェントによってOracle Databaseへの再接続が試行されます。この動作は、Oracle RAC以外の環境の場合と同様です。

ユーザーが介入する必要はありません。

SWT、伝播、フラッシュおよびパススルー

SWT、伝播およびフラッシュ

SESSION

SELECT

次のいずれかが発生します。

- Oracle Databaseへの接続がリカバリされます。失われた接続でオープン・カーソルがあったり、DML処理またはロック処理が行われていた場合は、エラーが返されるため、ユーザーは続行する前にトランザクションをロールバックする必要があります。前述の状態でなかった場合は、ロールバックせずに続行できます。

- TAFがタイムアウトになるか、または接続をリカバリできない場合は、接続が失われたことがアプリケーションに通知されます。キャッシュ・エージェントがOracle Databaseから切断され、現在のトランザクションがロールバックされます。変更されたすべてのセッション属性が失われます。
次のパススルー処理中に、キャッシュ・エージェントによってOracle Databaseへの再接続が試行されます。

この場合、ユーザーが介入する必要はありません。

パススルー

SELECT

Oracle Databaseへの接続がリカバリされます。失われた接続でDML処理またはロック処理が行われていた場合は、エラーが返されるため、ユーザーは続行する前にトランザクションをロールバックする必要があります。前述の状態でなかった場合は、ロールバックせずに続行できます。

ロードおよびリフレッシュ

NONE

接続が失われたことを示すエラーがアプリケーションに通知されます。

ロードおよびリフレッシュ

SESSION

次のいずれかが発生します。

- ロードまたはリフレッシュ処理が正常に行われます。

- Oracle Databaseでフェッチ処理が実行できないことを示すエラーが返されます。

ロードおよびリフレッシュ

SELECT

次のいずれかが発生します。

- Oracle Databaseカーソルがオープンしていてそのカーソルがリカバリされている場合、またはOracle Databaseカーソルがオープンしていない場合は、ロードまたはリフレッシュ処理が正常に行われます。

- TAFがセッションまたはオープンしているOracle Databaseカーソルをリカバリできなかった場合は、エラーが返されます。

注意: TAFフェイルオーバー・タイプがSESSIONの場合より、エラーが返される可能性は低くなります。

Oracle RAC環境でのTimesTen Cacheの使用の制限

Oracle RACでのTimesTen Cacheのサポートには、次の制限があります。

- TimesTen Cacheの動作は、Oracle RAC、FANおよびTAFの機能に制限されます。たとえば、サービスのすべてのノードが正常に実行されなかった場合、そのサービスは再起動されません。TimesTen Cacheは、ユーザーがサービスを再起動するまで待機します。

- TAFでは、ALTER SESSION処理はリカバリされません。障害発生後に変更されたセッション属性のリストアは、ユーザーが行う必要があります。

- TimesTen Cacheでは、FANと統合されたOCIが使用されます。このインタフェースは、スレッドを自動的に作成し、Oracle Databaseイベントが発生するまで待機します。TimesTen直リンクのアプリケーションでスレッドを作成するTimesTen Cacheの機能は、この機能のみです。このスレッド作成が行われるようにアプリケーションを調整します。追加スレッドが不要な場合は、RACCallback接続属性を0に設定すると、TAFおよびFANが使用されなくなります。

Oracle RAC環境でのTimesTen Cacheの設定

Oracle RACおよびTimesTen Cacheをインストールしたら、次の手順を実行してTimesTen CacheをOracle RAC環境用に設定します。

1. TimesTenで、ttCacheConfig AgentFailoverTimeoutパラメータを指定してTAFタイムアウトを分単位で設定します。AgentFailoverTimeoutパラメータでは、接続を確立する際にTAFが再試行する時間を構成します。TAFは、このタイムアウトの期間Oracle Databaseへの再接続を試行します。デフォルトは4分間です。再接続が成功しない場合は、キャッシュ・エージェントが再起動されて、1分ごとにOracle Databaseへの再接続が試行され、レプリケーション・エージェントがOracle Databaseに接続できないスレッドをすべて再起動します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する説明を参照してください。

2. TimesTenデーモン、キャッシュ・エージェントおよび次のOracle Databaseコンポーネントが開始されていることを確認します。

- Oracle Databaseインスタンス

- Oracle Databaseリスナー

- TimesTen Application-Tier Database Cacheで使用されるOracle Databaseサービス

3. TimesTen RACCallback接続属性が1(デフォルト)に設定されていることを確認します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のRACCallbackに関する説明を参照してください。

4. DBMS_SERVICE.MODIFY_SERVICEファンクションまたはOracle Enterprise Managerを使用してFANイベントのパブリッシュを有効にします。これにより、Oracle Database ALL_SERVICESビューのAQ_HA_NOTIFICATIONS列の値がYESに変更されます。
DBMS_SERVICE Oracle Database PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

5. 次のいずれかの方法で、TimesTen Cacheで使用されるOracle Databaseサービスに対してTAFを有効にします。

- 次の設定を指定して、Oracle Database tnsnames.oraファイルにTimesTen用のサービスを作成します。

- LOAD_BALANCE=ON(オプション)

- FAILOVER_MODE=(TYPE=SELECT)またはFAILOVER_MODE=(TYPE=SESSION)

- DBMS_SERVICE.MODIFY_SERVICEファンクションを使用して、TAFフェイルオーバー・タイプを設定します。
TAFの有効化の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

6. TimesTen直リンク・アプリケーションの場合は、FAN通知を受信できるようにアプリケーションをスレッド・ライブラリにリンクします。FANによって、障害を監視するスレッドが作成されます。

12 Data Guardと連携したTimesTen Application-Tier Database Cacheの使用

この章では、予定されたメンテナンス中に使用される同期Data GuardまたはData Guardと連携するようにTimesTen Application-Tier Database Cache (TimesTen Cache)を構成する方法について説明します。内容は次のとおりです。

- TimesTen Application-Tier Database CacheのMAAのコンポーネント

- Data Guardと連携したTimesTen Cacheの動作

TimesTen Application-Tier Database CacheのMAAのコンポーネント

Oracle最大可用性アーキテクチャ(MAA)は、Oracle Databaseのベスト・プラクティスのブループリントであり、実績のあるOracle Database高可用性(HA)テクノロジと推奨事項を基礎としています。MAAの目的は、コストおよび複雑さを最小限に抑えて最適な高可用性アーキテクチャを実現することです。

MAAに準拠するために、TimesTen Cacheでは、独自のHA機能が備えられているのみでなく、Oracle Real Application Clusters (Oracle RAC)およびOracle Data Guardがサポートされている必要があります。TimesTen Cacheでは、読取り専用キャッシュ・グループおよびAWTキャッシュ・グループでのキャッシュ表のアクティブ・スタンバイ・ペア・レプリケーションによって独自のHA機能が提供されています。TimesTen CacheおよびOracle RACの詳細は、「Oracle RAC環境でのTimesTen Application-Tier Database Cacheの使用」を参照してください。

Oracle Data Guardは、管理、監視および自動化のソフトウェア・インフラストラクチャを備えており、1つ以上の同期化されたスタンバイ・データベースを作成および保持して障害、災害、エラーおよび破損からデータを保護します。計画停止または計画外停止のためプライマリ・データベースを使用できなくなった場合、Data Guardはスタンバイ・データベースをプライマリ・ロールに切り替えて、停止時間を最小限に抑え、データの損失を防ぐことができます。Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください。

TimesTen CacheのMAAフレームワークでは、明示的にロードされる読取り専用キャッシュ・グループおよびAWTキャッシュ・グループのキャッシュ表がサポートされます。任意のキャッシュ・グループ・タイプの動的キャッシュ・グループ、SWTキャッシュ・グループおよびAUTOREFRESHキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループのキャッシュ表の場合、キャッシュ・アプリケーションがフェイルオーバーおよびスイッチオーバーが完了するまで待機する必要があるため、TimesTen Cacheではフェイルオーバーおよびスイッチオーバー中にOracle Databaseにアクセスできません。

ただし、一般的に、予定されたメンテナンス時には、すべてのキャッシュ・グループ・タイプが同期Data GuardまたはData Guardでサポートされます。

Data Guardと連携したTimesTen Cacheの動作

キャッシュされたOracle Database表のオブジェクトIDがプライマリ・データベースとスタンバイ・データベースで同じままであるかぎり、TimesTen Cacheは同期フィジカル・スタンバイのフェイルオーバーとスイッチオーバー、およびロジカル・スタンバイのスイッチオーバーと連携します。Oracle表を削除してから再作成した場合、Oracle表に変更を加えた場合または切捨てフラッシュバック処理やオンライン・セグメント縮小を実行した場合は、オブジェクトIDが変更される可能性があります。

一時アップグレード中に、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースに変換されます。スタンバイ・データベースがロジカルである間、ユーザーは、キャッシュされたOracle Database表のオブジェクトIDが変更されないようにする必要があります。特に、キャッシュされた表に対しては、削除、再作成、切捨て、変更、フラッシュバック、オンライン・セグメント縮小は実行しないでください。

Oracle Databaseの構成

TimesTen Cacheでフェイルオーバーおよびスイッチオーバーを適切に実行するには、次の手順を使用して、Oracleプライマリ・データベースおよびスタンバイ・データベースを構成します。

1. TimesTen Cacheデーモン・プロセスおよびアプリケーション・クライアントがフェイルオーバー・イベントおよびスイッチオーバー・イベントにより速く応答するように、Data Guard BrokerでData Guard構成を管理する必要があります。

2. Oracle RACデータベースを構成している場合は、Oracle Enterprise Managerの「Cluster Managed Database Services」ページを使用して、TimesTen Cacheおよびそのクライアント・アプリケーションがOracleプライマリ・データベースに接続するために使用するデータベース・サービスを作成します。データベース・サービスの作成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』の自動ワークロード管理の概要に関する説明を参照してください。

3. 手順2でデータベース・サービスを作成した場合は、DBMS_SERVICE PL/SQLパッケージのMODIFY_SERVICEファンクションを使用し、aq_ha_notifications属性をTRUEに設定することによって、アドバンスト・キューイング(AQ)を介して高可用性通知を送信できるようにそのサービスを変更します。サーバー側のTAF設定を構成するには、次の例に示すように、フェイルオーバー属性を設定します。

BEGIN
DBMS_SERVICE.MODIFY_SERVICE
(service_name => 'DBSERV',
goal => DBMS_SERVICE.GOAL_NONE,
dtp => false,
aq_ha_notifications => true,
failover_method => 'BASIC',
failover_type => 'SELECT',
failover_retries => 180,
failover_delay => 1);
END;

4. 手順2でデータベース・サービスを作成しなかった場合は、DBMS_SERVICE PL/SQLパッケージのCREATE_SERVICEファンクションを使用してデータベース・サービスを作成し、高可用性通知を有効にして、サーバー側のTAF設定を構成します。

BEGIN
DBMS_SERVICE.CREATE_SERVICE
(service_name => 'DBSERV',
network_name => 'DBSERV',
goal => DBMS_SERVICE.GOAL_NONE,
dtp => false,
aq_ha_notifications => true,
failover_method => 'BASIC',
failover_type => 'SELECT',
failover_retries => 180,
failover_delay => 1);
END;

5. Data Guardスタンバイ・データベース(Oracle RACまたはOracle RAC以外)がプライマリ・ロールに切り替わった後、データベース・サービスをそのデータベースに再配置するためにトリガーを2つ作成します。1つ目のトリガーは、システム起動イベントで起動され、DBSERVサービスを開始します。

CREATE OR REPLACE TRIGGER manage_service
AFTER STARTUP ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
SELECT database_role INTO role FROM v$database;
IF role = 'PRIMARY' THEN
dbms_service.start_service('DBSERV');
END IF;
END;

2つ目のトリガーは、フェイルオーバーおよびスイッチオーバー時にデータベース・ロールが変更されてスタンバイ・データベースが開いたままになったときに起動されます。このトリガーは、古いプライマリ・データベースから新しいプライマリ・データベースにDBSERVサービスを再配置し、古いプライマリ・データベース上のDBSERVサービスへの接続を切断して、TimesTen Cacheおよびそのクライアント・アプリケーションが新しいプライマリ・データベースに再接続できるようにします。

CREATE OR REPLACE TRIGGER relocate_service
AFTER DB_ROLE_CHANGE ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
SELECT database_role INTO role FROM v$database;
IF role = 'PRIMARY' THEN
dbms_service.start_service('DBSERV');
ELSE
dbms_service.stop_service('DBSERV');
dbms_lock.sleep(2);
FOR x IN (SELECT s.sid, s.serial#
FROM v$session s, v$process p
WHERE s.service_name='DBSERV' AND s.paddr=p.addr)
LOOP
BEGIN
EXECUTE IMMEDIATE
'ALTER SYSTEM DISCONNECT SESSION
''' || x.sid || ','|| x.serial# || ''' IMMEDIATE';
EXCEPTION WHEN OTHERS THEN
BEGIN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
END;
END LOOP;
END IF;
END;

6. オプションとして、TimesTen Cacheアプリケーションに及ぼすパフォーマンスの影響を軽減し、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースのスイッチオーバー中の停止時間を最小限に抑えるために、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースへのData Guardスイッチオーバーを開始する直前に、次のプロシージャを実行します。

DECLARE
role varchar(30);
BEGIN
SELECT database_role INTO role FROM v$database;
IF role = 'PRIMARY' THEN
dbms_service.stop_service('DBSERV');
dbms_lock.sleep(2);
FOR x IN (SELECT s.sid, s.serial#
FROM v$session s, v$process p
WHERE s.service_name='DBSERV' AND s.paddr=p.addr)
LOOP
BEGIN
EXECUTE IMMEDIATE
'ALTER SYSTEM DISCONNECT SESSION
''' || x.sid || ',' || x.serial# || ''' IMMEDIATE';
EXCEPTION WHEN OTHERS THEN
BEGIN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
END;
END LOOP;
ELSE
dbms_service.start_service('DBSERV');
END IF;
END;

このプロシージャは、スイッチオーバー・プロセスの直前に、まずフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースで実行し、次にプライマリ・データベースで実行します。フィジカル・スタンバイ・データベースへのスイッチオーバーにこのプロシージャを実行するには、そのフィジカル・スタンバイ・データベースでActive Data Guardを有効にしておく必要があります。

ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、プライマリ・データベースでTimesTen用のOracle Databaseサービスを停止し、そのサービスに接続されているすべてのセッションを切断しておきます。その後、ロジカル・スタンバイ・データベースでサービスを開始します。

この時点で、キャッシュ・アプリケーションによってスタンバイ・データベースへの再接続が試行されます。スイッチオーバーが発生しても、プライマリ・データベースからスタンバイ・データベースに接続を移行するために待機する必要はありません。このため、TimesTen Cacheおよびそのアプリケーションのパフォーマンスが影響を受けなくなります。

詳細は、ホワイト・ペーパー『Maximum Availability Architecture, Oracle Best Practices for High Availability』を参照してください。

TimesTenデータベースの構成

FAN HAイベントの通知を受信して、障害が発生したOracle Databaseインスタンスへの再接続を回避するように、TimesTenを構成します。TimesTen Cacheに付属のOracleクライアントを使用します。

1. すべてのプライマリ・ホストおよびスタンバイ・ホストを含むOracleネット・サービス名をADDRESS_LISTに作成します。例:

DBSERV =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = PRIMARYDB)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = STANDBYDB)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA= (SERVICE_NAME=DBSERV))
)

2. クライアントのsqlnet.oraファイルで、障害発生時にクライアントが迅速にアドレス・リストを横断できるようにSQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータを設定します。たとえば、使用できなくなったホストへの接続をクライアントが試行すると、その接続試行はSQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータに指定した時間に制限され、その時間が経過すると、クライアントはアドレス・リストの次のホストへの接続を試行します。接続が確立されるまで、アドレス・リストの各ホストに対して接続試行が継続されます。
ほとんどの環境では、SQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータの値を3秒に設定すれば十分です。たとえば、sqlnet.oraファイルに次のエントリを追加します。

SQLNET.OUTBOUND_CONNECT_TIMEOUT=3

A TimesTenでOracle Databaseデータをキャッシュするためのプロシージャおよび権限

次の各項では、キャッシュ環境の作成のための手順およびそれを実行するために必要な権限について簡単に説明しています。

- TimesTenでOracle Databaseデータをキャッシュするためのクイック・リファレンス

- キャッシュ管理ユーザーおよびキャッシュ・マネージャ・ユーザーに必要な権限

TimesTenでOracle Databaseデータをキャッシュするためのクイック・リファレンス

次の項では、TimesTenインメモリー・データベースでOracle Databaseデータをキャッシュする環境を設定する際に必要な手順を簡単に説明しています。各手順の詳細な説明および例については、第2章「スタート・ガイド」、第3章「キャッシュ・インフラストラクチャの設定」および第4章「キャッシュ・グループの定義」を参照してください。

Oracle Databaseで次の手順を実行します。

1. TimesTen Application-Tier Database Cache管理オブジェクトの格納に使用するデフォルトの表領域を作成します。

2. SQL*PlusスクリプトTimesTen_install_dir/oraclescripts/initCacheGlobalSchema.sqlをsysユーザーで実行することで、timestenユーザー、timestenユーザーが所有するOracle Database表領域およびこれらのOracle Database表に権限を定義するTT_CACHE_ADMIN_ROLEロールを作成します。

3. sysユーザーで、キャッシュされたOracle Database表を所有する1人以上のスキーマ・ユーザーを作成します(既存のユーザーも可能です)。

4. sysユーザーで、Oracle Databaseオブジェクトを作成、所有および保持するキャッシュ管理ユーザーを作成しますが、これらのOracle Databaseオブジェクトには、特定のキャッシュ・グリッド(定義されている場合)を管理し、特定のキャッシュ・グループ・タイプの定義済動作を実行するための情報が格納されます。キャッシュ管理ユーザーのCREATE USER文で、キャッシュ管理ユーザー用のデフォルトの表領域として、timestenユーザー用に作成した表領域を指定します。
Oracle Databaseユーザーの詳細は、「Oracle Databaseユーザーの作成」を参照してください。

5. sysユーザーでTimesTen_install_dir/oraclescripts/grantCacheAdminPrivileges.sqlスクリプトを実行して、キャッシュ管理ユーザーに、キャッシュ・グリッド処理(定義されている場合)を実行し、目的のタイプのキャッシュ・グループを作成して、そのキャッシュ・グループに対して処理を実行するために必要な権限を付与します。または、それぞれのOracle Databaseオブジェクトを手動で作成できます。
実行対象のスクリプトを確認するには、「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成」または「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」を参照してください。

Oracle Databaseオブジェクトを手動で作成している場合は、さらにTimesTen_install_dir/oraclescripts/initCacheGridSchema.sqlスクリプトを実行して、特定のキャッシュ・グリッドに関連付けられているTimesTenデータベースに関する情報を保存するためのOracle Database表を作成する必要があります。

6. 一部の権限は、キャッシュされたOracle Database表を作成するまで付与できません。これらの権限を付与するには、sysユーザーとしてGRANT文を実行します。
特定のキャッシュ処理を実行するためにキャッシュ管理ユーザーに付与する必要のある権限の詳細は、「キャッシュ管理ユーザーおよびキャッシュ・マネージャ・ユーザーに必要な権限」を参照してください。

TimesTenデータベースで次の手順を実行します。

1. Oracle Databaseからデータをキャッシュするために使用するTimesTenデータベースを参照するDSNを定義します。

1. Oracle Databaseインスタンスを参照するOracleネット・サービス名をOracleNetServiceName接続属性に設定します。

2. Oracle Databaseキャラクタ・セットをDatabaseCharacterSet接続属性に設定します。TimesTenデータベース・キャラクタ・セットは、Oracle Databaseキャラクタ・セットに一致する必要があります。

3. 次に、データベースがスタンドアロン・データベースであるか、またはアクティブ・スタンバイ・ペアのアクティブ・データベースである場合は、DSNに接続してデータベースを作成します。

Oracle Databaseからデータをキャッシュするために使用するTimesTenデータベースのDSNを定義する方法の詳細は、「TimesTenデータベースのDSNの定義」を参照してください。

2. TimesTenデータベースに、次のユーザーを作成します。

- キャッシュ・マネージャ・ユーザー
このユーザーは、キャッシュされたOracle Database表にアクセスできるコンパニオンOracle Databaseユーザーと同じ名前である必要があります。コンパニオンOracle Databaseユーザーは、キャッシュ管理ユーザー、スキーマ・ユーザーまたはその他の既存ユーザーにすることができます。キャッシュ・マネージャ・ユーザーのパスワードは、同じ名前を持つOracle Databaseユーザーとは別のパスワードにすることができます。

- TimesTenキャッシュ表を所有する1人以上のキャッシュ表ユーザー
これらのユーザーは、キャッシュされたOracle Database表を所有するOracle Databaseスキーマ・ユーザーと同じ名前にする必要があります。キャッシュ表ユーザーのパスワードは、同じ名前を持つOracle Databaseユーザーとは別のパスワードにすることができます。

インスタンス管理者としてCREATE USER文を実行します。

TimesTenユーザーの詳細は、「TimesTenユーザーの作成」を参照してください。

3. キャッシュ・マネージャ・ユーザーに、キャッシュ・グリッド処理を実行し、目的のタイプのキャッシュ・グループを作成して、そのキャッシュ・グループに対して処理を実行するのに必要な権限を付与します。インスタンス管理者としてGRANT文を実行します。
特定のキャッシュ処理を実行するためにキャッシュ・マネージャ・ユーザーに付与する必要のある権限の詳細は、「キャッシュ管理ユーザーおよびキャッシュ・マネージャ・ユーザーに必要な権限」を参照してください。

4. TimesTenデータベースにキャッシュ管理ユーザーの名前とパスワードを設定するには、キャッシュ・マネージャ・ユーザーとしてttCacheUidPwdSet組込みプロシージャをコールするか、またはCACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -cacheUidPwdSetユーティリティ・コマンドを実行します。
TimesTenデータベースにキャッシュ管理ユーザーの名前およびパスワードを設定する方法の詳細は、「キャッシュ管理ユーザーの名前およびパスワードの設定」を参照してください。

5. キャッシュ・グリッドをグローバル・キャッシュ・グループで使用する場合は、次の手順を実行します。

1. キャッシュ・グリッドを作成するには、キャッシュ・マネージャ・ユーザーとしてTimesTenデータベースでttGridCreate組込みプロシージャをコールします。
キャッシュ・グリッドの作成の詳細は、「キャッシュ・グリッドの作成」を参照してください。

2. TimesTenデータベースをキャッシュ・グリッドに関連付けるには、キャッシュ・マネージャ・ユーザーとしてTimesTenデータベースでttGridNameSet組込みプロシージャをコールします。
TimesTenデータベースをキャッシュ・グリッドに関連付ける方法の詳細は、「TimesTenデータベースとキャッシュ・グリッドの関連付け」を参照してください。

6. TimesTenデータベースでキャッシュ・エージェントを起動するには、キャッシュ・マネージャ・ユーザーとしてttCacheStart組込みプロシージャをコールするか、またはCACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -cacheStartユーティリティ・コマンドを実行します。
TimesTenデータベースでのキャッシュ・エージェントの起動方法の詳細は、「キャッシュ・エージェントの管理」を参照してください。

7. キャッシュ・グループのスキーマを設計するには、どのOracle Database表をキャッシュし、そのOracle Database表内でどの列とどの行をキャッシュするかを決定します。複数表キャッシュ・グループの場合、表間の関係を決定するには、どの表がルート表であり、どの表がルート表の直接の子表であり、どの表が他の子表の子表であるかを定義します。キャッシュされた列ごとに、Oracle Databaseデータ型をマップする必要があるTimesTenデータ型を決定します。
Oracle DatabaseとTimesTenデータベース間の有効なデータ型マッピングのリストの詳細は、「Oracle DatabaseおよびTimesTenのデータ型のマッピング」を参照してください。

キャッシュ・グループごとに、アプリケーションの要件および目的に基づいて、どのタイプ(読取り専用、SWT、AWT、ユーザー管理)を作成するかを決定します。また、各キャッシュ・グループが明示的にロードされるか、動的であるか、ローカルであるか、グローバルであるかを決定します。

次に、キャッシュ・グループを作成します。

キャッシュ・グループの作成の詳細は、「キャッシュ・グループの作成」を参照してください。

8. このTimesTenデータベースをアクティブ・スタンバイ・ペアのアクティブ・データベースとする場合は、データベースにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。

9. TimesTenデータベースにアクティブ・スタンバイ・ペアのレプリケーション・スキームまたは1つ以上のAWTキャッシュ・グループが含まれる場合、データベースでレプリケーション・エージェントを起動するには、キャッシュ・マネージャ・ユーザーとしてttRepStart組込みプロシージャをコールするか、またはCACHE_MANAGER権限を持つTimesTen外部ユーザーとしてttAdmin -repStartユーティリティ・コマンドを実行します。
TimesTenデータベースでのレプリケーション・エージェントの起動方法の詳細は、「レプリケーション・エージェントの管理」を参照してください。

10. TimesTenデータベースに1つ以上のグローバル・キャッシュ・グループが含まれる場合、TimesTenデータベースを関連付け先のキャッシュ・グリッドにアタッチするには、キャッシュ・マネージャ・ユーザーとしてttGridAttach組込みプロシージャをコールします。
TimesTenデータベースをキャッシュ・グリッドにアタッチする方法の詳細は、「キャッシュ・グリッドへのTimesTenデータベースのアタッチ」を参照してください。

11. 明示的にロードされるキャッシュ・グループのキャッシュ表を手動でロードするにはLOAD CACHE GROUP文を使用し、動的キャッシュ・グループのキャッシュ表をロードするには適切なSELECT文、UPDATE文またはINSERT文を使用します。
キャッシュ・グループのキャッシュ表を手動でロードする方法の詳細は、「キャッシュ・グループのロードおよびリフレッシュ」を参照してください。

動的キャッシュ・グループのキャッシュ表を動的にロードする方法の詳細は、「キャッシュ・インスタンスの動的ロード」を参照してください。

12. キャッシュ・グリッドを使用する場合は、後続のスタンドアロンTimesTenデータベースを既存のキャッシュ・グリッドにメンバーとして追加できます。
別のスタンドアロンTimesTenデータベースを作成し、そのデータベースを既存のキャッシュ・グリッドに追加する方法の詳細は、「後続のスタンドアロンTimesTenデータベースの作成および構成」を参照してください。

13. キャッシュ表を別のTimesTenデータベースにレプリケートして高可用性を実現するために、アクティブ・スタンバイ・ペアを既存のキャッシュ・グリッドにメンバーとして追加できます。
アクティブ・データベースを作成し、そのデータベースを既存のキャッシュ・グリッドに追加する方法の詳細は、「アクティブ・データベースの作成および構成」を参照してください。

アクティブ・データベースからスタンバイ・データベースを作成するには、スタンバイ・データベース用のDSNを作成した後に、ADMIN権限を持つTimesTen外部ユーザーとして、スタンバイ・データベース・システムでttRepAdmin -duplicateユーティリティ・コマンドを実行します。このコマンドを正常に完了するには、アクティブ・データベースのキャッシュ・マネージャ・ユーザーにADMIN権限を付与する必要があります。次に、データベースを構成し、グリッドにそのデータベースをメンバーとして追加します。

スタンバイ・データベースを作成し、そのデータベースを既存のキャッシュ・グリッドに追加する方法の詳細は、「スタンバイ・データベースの作成および構成」を参照してください。

スタンバイ・データベースからオプションの読取り専用サブスクライバ・データベースを作成するには、サブスクライバ・データベース用のDSNを作成します。次に、ADMIN権限を持つTimesTen外部ユーザーとして、サブスクライバ・データベース・システムでttRepAdmin -duplicateユーティリティ・コマンドを実行します。このコマンドを正常に完了するには、スタンバイ・データベースのキャッシュ・マネージャ・ユーザーにADMIN権限を付与する必要があります。次に、データベースでレプリケーション・エージェントを起動します。

アクティブ・スタンバイ・ペアの読取り専用サブスクライバ・データベースを作成する方法の詳細は、「読取り専用サブスクライバ・データベースの作成および構成」を参照してください。

キャッシュ管理ユーザーおよびキャッシュ・マネージャ・ユーザーに必要な権限

Oracle Databaseユーザーに必要な権限は、作成するキャッシュ・グループのタイプおよびキャッシュ・グループに対して実行する処理によって異なります。表A-1で、キャッシュ管理ユーザーに必要な権限は最初の列に、各キャッシュ処理についてTimesTenのキャッシュ・マネージャ・ユーザーに必要な権限は、2番目の列にリストされています。

表A-1 キャッシュ処理に必要なOracle DatabaseおよびTimesTenのユーザー権限

キャッシュ処理

Oracle Databaseキャッシュ管理ユーザーに必要な権限 [1]

TimesTenのキャッシュ・マネージャ・ユーザーに必要な権限[2]

キャッシュ管理ユーザーを初期化します。grantCacheAdminPrivileges.sqlスクリプトはこれらの権限をキャッシュ管理ユーザーに付与します。

CREATE SESSION

TT_CACHE_ADMIN_ROLE

EXECUTE ON SYS.DBMS_LOCK

RESOURCE [4]

CREATE PROCEDURE

CREATE ANY TRIGGER [4]

EXECUTE ON SYS.DBMS_LOB

SELECT ON SYS.ALL_OBJECTS

SELECT ON SYS.ALL_SYNONYMS

CREATE TYPE

SELECT ON SYS.GV_$LOCK

SELECT ON SYS.GV_$SESSION

SELECT ON SYS.DBA_DATA_FILES

SELECT ON SYS.USER_USERS

SELECT ON SYS.USER_FREE_SPACE

SELECT ON SYS.USER_TS_QUOTAS

SELECT ON SYS.USER_SYS_PRIVS

デフォルトの表領域に必要な権限

次のいずれかの方法でのキャッシュ管理ユーザーの名前およびパスワードの設定

- ttCacheUidPwdSet組込みプロシージャのコール。

- ttAdmin -cacheUidPwdSetユーティリティ・コマンドの実行。

- CREATE SESSION

- RESOURCE [4]

CACHE_MANAGER

次のいずれかの方法でのキャッシュ管理ユーザーの名前の取得

- ttCacheUidGet組込みプロシージャのコール

- ttAdmin -cacheUidGetユーティリティ・コマンドの実行

NONE

CACHE_MANAGER

キャッシュ・グリッドの作成

- ttGridCreate組込みプロシージャのコール。

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

- RESOURCE [4]

CACHE_MANAGER

TimesTenデータベースとキャッシュ・グリッドの関連付け

- ttGridNameSet組込みプロシージャのコール。

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

CACHE_MANAGER

キャッシュ・グリッドへのTimesTenデータベースのアタッチ

- ttGridAttach組込みプロシージャのコール。

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

CACHE_MANAGER

キャッシュ・グリッドからのTimesTenデータベースのデタッチ

- ttGridDetach組込みプロシージャのコール。

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

CACHE_MANAGER

キャッシュ・グリッドからのノード・リストのデタッチ

- ttGridDetachList組込みプロシージャのコール。

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

CACHE_MANAGER

キャッシュ・グリッドの破棄

- ttGridDestroy組込みプロシージャのコール。

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

CACHE_MANAGER

次のいずれかの方法でのキャッシュ・エージェントの起動

- ttCacheStart組込みプロシージャのコール。

- ttAdmin -cacheStartユーティリティ・コマンドの実行。

CREATE SESSION

CACHE_MANAGER

キャッシュ・エージェントの停止

- ttCacheStop組込みプロシージャのコール

- ttAdmin -cacheStopユーティリティ・コマンドの実行

NONE

CACHE_MANAGER

次のいずれかの方法でのキャッシュ・エージェント起動ポリシーの設定

- ttCachePolicySet組込みプロシージャのコール。

- ttAdmin -cachePolicyユーティリティ・コマンドの実行。

CREATE SESSION [5]

CACHE_MANAGER

キャッシュ・エージェント起動ポリシー設定を返す

- ttCachePolicyGet組込みプロシージャのコール。

CREATE SESSION

NONE

次のいずれかの方法でのレプリケーション・エージェントの起動

- ttRepStart組込みプロシージャのコール。

- ttAdmin -repStartユーティリティ・コマンドの実行。

NONE

CACHE_MANAGER

次のいずれかの方法でのレプリケーション・エージェントの停止

- ttRepStop組込みプロシージャのコール。

- ttAdmin -repStopユーティリティ・コマンドの実行。

NONE

CACHE_MANAGER

レプリケーション・エージェント起動ポリシーの設定

- ttRepPolicySet組込みプロシージャのコール

- ttAdmin -repPolicyユーティリティ・コマンドの実行

NONE

ADMIN

CREATE ACTIVE STANDBY PAIR (INCLUDE CACHE GROUPを指定)

作成したキャッシュ・グループがAWTキャッシュ・グループである場合

CREATE TRIGGER

アクティブ・スタンバイ・レプリケーション・スキーム内でAWTキャッシュ・グループを使用する際のttRepAdmin -duplicateによるデータベースの複製

CREATE TRIGGER

CREATE [DYNAMIC] READONLY CACHE GROUP(AUTOREFRESH MODE INCREMENTALを指定)

- CREATE SESSION

- SELECT ON table_name [6]

- RESOURCE [4]

- CREATE ANY TRIGGER [4]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] READONLY CACHE GROUP(AUTOREFRESH MODE FULLを指定)

- CREATE SESSION

- SELECT ON table_name [6]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] ASYNCHRONOUS WRITETHROUGH [GLOBAL] CACHE GROUP

- CREATE SESSION

- SELECT ON table_name [6]

- RESOURCE [4]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] SYNCHRONOUS WRITETHROUGH CACHE GROUP

- CREATE SESSION

- SELECT ON table_name [6]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] USERMANAGED CACHE GROUP

(後続の行に示す異なる処理を参照)

- CREATE SESSION

- SELECT ON table_name [6]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] USERMANAGED CACHE GROUP(AUTOREFRESH MODE INCREMENTALを指定)

- CREATE SESSION

- SELECT ON table_name [6]

- RESOURCE [4]

- CREATE ANY TRIGGER [4]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] USERMANAGED CACHE GROUP(AUTOREFRESH MODE FULLを指定)

- CREATE SESSION

- SELECT ON table_name [6]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] USERMANAGED CACHE GROUP(READONLYを指定)

- CREATE SESSION

- SELECT ON table_name [6]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

CREATE [DYNAMIC] USERMANAGED CACHE GROUP(PROPAGATEを指定)

- CREATE SESSION

- SELECT ON table_name [6]

- CREATE [ANY] CACHE GROUP [7]

- CREATE [ANY] TABLE [8]

ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED

- CREATE SESSION

- SELECT ON table_name [9]

- RESOURCE [9]

- CREATE ANY TRIGGER [9]

ALTER ANY CACHE GROUP [10]

ALTER CACHE GROUP SET AUTOREFRESH STATE ON

- CREATE SESSION

- SELECT ON table_name [9]

- RESOURCE [9]

- CREATE ANY TRIGGER [9]

ALTER ANY CACHE GROUP [10]

ALTER CACHE GROUP SET AUTOREFRESH STATE OFF

CREATE SESSION

ALTER ANY CACHE GROUP [10]

ALTER CACHE GROUP SET AUTOREFRESH MODE FULL

CREATE SESSION

ALTER ANY CACHE GROUP [10]

ALTER CACHE GROUP SET AUTOREFRESH MODE INCREMENTAL

- CREATE SESSION

- SELECT ON table_name [6]

- RESOURCE [4]

- CREATE ANY TRIGGER [4]

ALTER ANY CACHE GROUP [10]

ALTER CACHE GROUP SET AUTOREFRESH INTERVAL

- CREATE SESSION

- SELECT ON table_name [11]

ALTER ANY CACHE GROUP [10]

LOAD CACHE GROUP

- CREATE SESSION

- SELECT ON table_name [6]

LOAD {ANY CACHE GROUP | ON cache_group_name) [10]

REFRESH CACHE GROUP

- CREATE SESSION

- SELECT ON table_name [6]

REFRESH {ANY CACHE GROUP | ON cache_group_name) [10]

FLUSH CACHE GROUP

- CREATE SESSION

- UPDATE ON table_name [6]

- INSERT ON table_name [6]

FLUSH {ANY CACHE GROUP | ON cache_group_name) [10]

UNLOAD CACHE GROUP

NONE

UNLOAD {ANY CACHE GROUP | ON cache_group_name) [10]

DROP CACHE GROUP

CREATE SESSION

- DROP ANY CACHE GROUP [10]

- DROP ANY TABLE [12]

同期ライトスルーまたは伝播

- CREATE SESSION

- INSERT ON table_name [13]

- UPDATE ON table_name [13]

- DELETE ON table_name [13]

- INSERT ON table_name [14]

- UPDATE ON table_name [14]

- DELETE ON table_name [14]

非同期ライトスルー

- CREATE SESSION

- INSERT ON table_name [6]

- UPDATE ON table_name [6]

- DELETE ON table_name [6]

- INSERT ON table_name [14]

- UPDATE ON table_name [14]

- DELETE ON table_name [14]

CacheAWTMethod接続属性が1に設定されている場合の非同期ライトスルー

CREATE PROCEDURE

注意: この権限は、非同期ライトスルー・キャッシュ・グループに必要な権限の1つです。

追加する権限なし

CacheAWTMethod接続属性が1に設定されている場合のOracle Database CLOB、BLOBおよびNCLOBフィールドの非同期ライトスルー

Oracle Database DBMS_LOB PL/SQLパッケージに対するEXECUTE権限

注意: この権限は、非同期ライトスルー・キャッシュ・グループに必要な権限の1つです。

追加する権限なし

増分自動リフレッシュ

SELECT ON table_name [6]

NONE

完全自動リフレッシュ

SELECT ON table_name [6]

NONE

動的ロード

- CREATE SESSION

- SELECT ON table_name [6]

- SELECT ON table_name [14]

- UPDATE ON table_name [14]

- DELETE ON table_name [14]

- INSERT ON table_name [14]

エージング

NONE

DELETE {ANY TABLE | ON table_name) [14]

LRUエージング属性の設定

- ttAgingLRUConfig組込みプロシージャのコール

NONE

ADMIN

Oracle Database SQL文を生成することによるOracle Databaseオブジェクトの手動によるインストールまたはアンインストール

- ttIsqlユーティリティのcachesqlgetコマンドの実行

- ttCacheSQLGet組込みプロシージャのコール

CREATE SESSION

CACHE_MANAGER

コミットされたキャッシュ表更新のOracle Databaseへの伝播の無効化または有効化

- ttCachePropagateFlagSet組込みプロシージャのコール

NONE

CACHE_MANAGER

自動リフレッシュ・キャッシュ・グループに対する、キャッシュ・エージェントのタイムアウトおよびリカバリ方法の構成

- ttCacheConfig組込みプロシージャのコール

CREATE SESSION

CACHE_MANAGER

AWTトランザクション・ログ・ファイルのしきい値の設定

- ttCacheAWTThresholdSet組込みプロシージャのコール

NONE

CACHE_MANAGER

AWTキャッシュ・グループの監視の有効化または無効化

- ttCacheAWTMonitorConfig組込みプロシージャのコール

NONE

CACHE_MANAGER

キャッシュされたOracle Database表に対して発行されたDDL文の追跡の有効化または無効化

- ttCacheDDLTrackingConfig組込みプロシージャのコール

CREATE SESSION

CACHE_MANAGER

キャッシュ・グリッド情報を返す

- ttGridInfo組込みプロシージャのコール

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

CACHE_MANAGER

キャッシュ・グリッド・ノード情報を返す

- ttGridNodeStatus組込みプロシージャのコール

- CREATE SESSION

- TT_CACHE_ADMIN_ROLEロール

CACHE_MANAGER

1 キャッシュ管理ユーザーには、少なくともCREATE TYPE権限が必要です。

2 キャッシュ・マネージャ・ユーザーには、少なくともCREATE SESSION権限が必要です。

3 キャッシュ管理ユーザーが自動リフレッシュ・キャッシュ・グループを作成しない場合は、CREATE ANY TRIGGER権限のかわりに、CREATE TRIGGER権限を付与できます。

4 Oracle Databaseデータのキャッシュ管理に使用されるOracle DatabaseオブジェクトがinitCacheAdminSchema.sqlスクリプトにより手動で作成されている場合は必要ありません。

5 キャッシュ・エージェント起動ポリシーがalwaysまたはnorestartに設定されている場合に必要です。

6 TimesTenキャッシュ・グループにキャッシュされる表のうち、キャッシュ管理ユーザーが所有している表を除くすべてのOracle Database表に必要です。

7 CACHE_MANAGER権限には、CREATE [ANY] CACHE GROUP権限が含まれます。キャッシュ・マネージャ・ユーザーが、キャッシュ・マネージャ・ユーザー以外のユーザーが所有するキャッシュ・グループを作成する場合は、ANYが必要です。

8 キャッシュ表のいずれかが、キャッシュ・マネージャ・ユーザー以外のユーザーによって所有される場合は、ANYが必要です。

9 キャッシュ・グループの自動リフレッシュ・モードが増分に設定されており、初期の自動リフレッシュ状態がOFFであり、Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトが自動で作成されている場合に必要です。

10 キャッシュ・グループにアクセスするTimesTenユーザーが、そのキャッシュ・グループを所有していない場合に必要です。

11 キャッシュ・グループの自動リフレッシュ・モードが増分になっている場合に必要です。

12 キャッシュ・グループにアクセスするTimesTenユーザーが、そのキャッシュ表の一部を所有していない場合に必要です。

13 Oracle Databaseユーザーがキャッシュ管理ユーザーではない場合は、TimesTenキャッシュ・マネージャ・ユーザーと同じ名前のOracle Databaseユーザーにこの権限が付与されている必要があります。

14 キャッシュ表にアクセスするTimesTenユーザーがその表を所有していない場合に必要です。

B TimesTen Application-Tier Database CacheのSQL*Plusスクリプト

この付録では、TimesTen Application-Tier Database Cacheとともにインストールされ、様々な構成タスク、管理タスクおよび監視タスクの実行に使用されるSQL*Plusスクリプトについてリストし、例を含む詳細情報へのリンクを示します。すべてのスクリプトはTimesTen_install_dir/oraclescriptsディレクトリにインストールされます。

インストールされるSQL*Plusスクリプト

- cacheCleanUp.sql: 自動リフレッシュ処理の実装に使用される変更ログ表やトリガーなどのOracle Databaseオブジェクトを削除します。TimesTenシステムがオフラインであったり自動リフレッシュ・キャッシュ・グループを削除せずにデータベースが破棄されたために自動リフレッシュ・キャッシュ・グループを含むTimesTenデータベースが使用不可能になった場合に使用します。このスクリプトは、キャッシュ管理ユーザーとして実行します。詳細は、「自動リフレッシュ・キャッシュ・グループで使用されているOracle Databaseオブジェクトの削除」を参照してください。

- cacheInfo.sql: 自動リフレッシュ・キャッシュ・グループにキャッシュされているすべてのOracle Database表の変更ログ表情報、およびキャッシュされたOracle Database表に対して発行されたDDL文を追跡するのに使用されるOracle Databaseオブジェクトに関する情報を返します。キャッシュ・グループでの自動リフレッシュ処理およびキャッシュされたOracle Database表に対して発行されたDDL文の監視に使用します。このスクリプトは、キャッシュ管理ユーザーとして実行します。詳細は、「キャッシュ・グループでの自動リフレッシュ処理の監視」および「キャッシュされたOracle Database表に対して発行されたDDL文の追跡」を参照してください。

- grantCacheAdminPrivileges.sql: 特定のキャッシュ・グリッド処理およびキャッシュ・グループ処理が実行されたときに、Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトを自動的に作成するのに必要な権限をキャッシュ管理ユーザーに付与します。このスクリプトは、sysユーザーとして実行します。詳細は、「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの自動作成」を参照してください。

- initCacheAdminSchema.sql: キャッシュ管理ユーザーに最小限のセットの権限を付与し、Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトを手動で作成します。このスクリプトは、sysユーザーとして実行します。詳細は、「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」を参照してください。

- initCacheGlobalSchema.sql: Oracle Database timestenユーザー、キャッシュ・グリッドに関する情報を保存するためにtimestenユーザーが所有するOracle Database表およびこのOracle Database表に対する権限を定義するTT_CACHE_ADMIN_ROLEロールを作成します。Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトを自動的に作成しているか手動で作成しているかに関係なく、実行する必要があります。このスクリプトは、sysユーザーとして実行します。詳細は、「Oracle Databaseユーザーの作成」を参照してください。

- initCacheGridSchema.sql: 特定のキャッシュ・グリッドに関連付けられたTimesTenデータベースの情報を格納するために使用するOracle Database表を手動で作成します。このスクリプトは、sysユーザーとして実行します。詳細は、「Oracle Databaseデータのキャッシュ管理に使用されるOracle Databaseオブジェクトの手動による作成」を参照してください。

- README: TimesTen Application-Tier Database CacheとともにインストールされるSQL*Plusスクリプトの説明が含まれています。

C TimesTenデータベースとOracle Databaseの互換性

次の各項では、TimesTenデータベースとOracle Databaseの互換性の問題を示します。リストは完全なものではなく、特に注意が必要な領域を示すものです。

- 互換性の問題の概要

- トランザクション・セマンティクス

- APIの互換性

- SQLの互換性

- Oracle Databaseデータ型とTimesTenデータ型の間のマッピング

互換性の問題の概要

TimesTenデータベースとOracle Database間の次の相違について考慮します。

- TimesTenとOracleのデータベース・メタデータは別々に保存されます。詳細は、「APIの互換性」を参照してください。

- TimesTenデータベースとOracle Databaseには異なるトランザクションの分離モデルがあります。詳細は、「トランザクション・セマンティクス」を参照してください。

- TimesTenデータベースとOracle Databaseには異なる接続および文のプロパティがあります。たとえば、TimesTenでは、カタログ名、スクロール可能なカーソル、更新可能なカーソルはサポートされていません。

- 順序は、キャッシュされず、TimesTenデータベースと対応するOracle Database間で同期化されません。詳細は、「SQL式」を参照してください。

- Oracle Databaseトリガーおよびストアド・プロシージャの副作用は、自動リフレッシュ処理または手動リフレッシュ処理が完了して初めてTimesTenデータベースに反映されます。

トランザクション・セマンティクス

TimesTenとOracle Databaseのトランザクション・セマンティクスの相違は、次のとおりです。

- Oracle Databaseシリアライズ可能トランザクションは、トランザクションをシリアライズできないため、コミット時に失敗する可能性があります。TimesTenはロックを使用してシリアライズ可能性を実現します。

- Oracle Databaseは、マルチバージョン一貫性モデルを使用することによって、文レベルの一貫性およびトランザクション・レベルの一貫性の両方を提供できます。TimesTenは、文レベルの一貫性を提供しません。TimesTenは、シリアライズ可能な分離を使用することによって、トランザクション・レベルの一貫性を提供します。

- Oracle Databaseユーザーは、SQLを介して明示的に表をロックできます。このロック機能は、TimesTenではサポートされていません。

- Oracle Databaseではセーブポイントがサポートされていますが、TimesTenではサポートされていません。

- Oracle Databaseでは、トランザクションを読取り専用または読取り/書込みに設定できます。これはTimesTenではサポートされていません。

TimesTenの分離レベルおよびトランザクション・セマンティクスの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクションの管理に関する説明を参照してください。

APIの互換性

TimesTenでサポートされているJDBC APIクラスおよびインタフェースの完全なリストおよびメソッドの互換性の問題に関する注意事項については、『Oracle TimesTen In-Memory Database Java開発者ガイド』の重要なJDBCクラスおよびインタフェースに関する説明を参照してください。

TimesTenでサポートされているODBC API関数の完全なリストおよび関数の互換性の問題に関する注意事項については、『Oracle TimesTen In-Memory Database C開発者ガイド』のTimesTen ODBC関数およびオプションに関する説明を参照してください。

TimesTenでサポートされているOracle Databaseリリース11.2.0.2用のOCI関数の完全なリストについては、『Oracle TimesTen In-Memory Database C開発者ガイド』の「TimesTen OCIサポート」を参照してください。

TimesTenでのPro*C/C++のサポートの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』の「TimesTenでのOracle Pro*C/C++プリコンパイラのサポート」を参照してください。

TimesTenでのODP.NETのサポートの詳細は、『Oracle Data Provider for .NET Oracle TimesTen In-Memory Databaseサポート・ユーザーズ・ガイド』を参照してください。

TimesTenでのPL/SQLのサポートの詳細は、『Oracle TimesTen In-Memory Database PL/SQL開発者ガイド』を参照してください。

TimesTen C++インタフェース・クラス(TTClasses)ライブラリでは、使いやすくパフォーマンスの高いTimesTenへのインタフェースが提供されます。このC++クラス・ライブラリでは、最も一般的なODBC機能が含まれているラッパーが提供されます。このAPIは、Oracle Databaseには使用できません。Oracle TimesTen In-Memory Database TTClassesガイドを参照してください。

SQLの互換性

この項では、TimesTenとOracle DatabaseのSQL実装を比較します。TimesTenでサポートされていないか、または別のセマンティクスでサポートされているOracle Database SQL機能のリストを提供することが目的です。

スキーマ・オブジェクト

TimesTenでは、Oracle Databaseでサポートされているスキーマ・オブジェクトの一部が認識されません。文でこれらのオブジェクトが処理または使用されると、TimesTenは構文エラーを返します。TimesTenは文をOracle Databaseに渡します。サポートされていないオブジェクトは、次のとおりです。

クラスタ
CREATE DATABASE文により作成されたオブジェクト
CREATE JAVA文により作成されたオブジェクト
データベース・リンク
データベース・トリガー
ディメンション
拡張機能
外部プロシージャ・ライブラリ
索引構成表
マイニング・モデル
パーティション
オブジェクト表、オブジェクト・タイプおよびオブジェクト・ビュー
演算子

TimesTenではビューおよびマテリアライズド・ビューがサポートされていますが、Oracle Databaseビューはキャッシュできません。TimesTenでは、AUTOREFRESHキャッシュ・グループ属性およびPROPAGATEキャッシュ表属性を使用しないユーザー管理キャッシュ・グループに、Oracle Databaseマテリアライズド・ビューをキャッシュできます。キャッシュ・グループは、手動でロードおよびフラッシュする必要があります。

Oracle Databaseパーティション表のキャッシュ

TimesTenは表レベルでOracle Databaseパーティション表をキャッシュできますが、個々のパーティションはキャッシュできません。次に、パーティション表に対する処理がキャッシュ・グループにどう影響するかを示します。

- パーティションを持つ表に対するDDL操作は、データ・ロスがないかぎりキャッシュ・グループに影響しません。たとえば、データのあるパーティションが切り捨てられた場合、AUTOREFRESH処理は対応するキャッシュ対象の表からデータを削除しません。

- すべてのキャッシュ・グループ操作で、WHERE句は個々のパーティションまたはサブパーティションを参照できません。表の単一パーティションを定義しようとすると、エラーが返されます。

非スキーマ・オブジェクト

TimesTenでは、Oracle Databaseでサポートされているスキーマ・オブジェクトの一部が認識されません。文でこれらのオブジェクトが処理または使用されると、TimesTenは構文エラーを返します。TimesTenは文をOracle Databaseに渡します。サポートされていないオブジェクトは、次のとおりです。

コンテキスト
ディレクトリ
エディション
リストア・ポイント
ロール
ロールバック・セグメント
表領域

Oracle DatabaseとTimesTenの表の相違

TimesTenではサポートされていないOracle Database表の機能は、次のとおりです。

- ON DELETE SET NULL

- チェック制約

- 外部キー自身が定義されている表を参照する外部キー

データ型のサポート

次のOracle Databaseデータ型はTimesTenではサポートされていません。

TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
UROWID
BFILE
Oracle Databaseが提供する型
ユーザー定義の型

次のTimesTenデータ型はOracle Databaseではサポートされていません。

TT_CHAR
TT_VARCHAR
TT_NCHAR
TT_NVARCHAR
TT_BINARY
TT_VARBINARY
TINYINTおよびTT_TINYINT
TT_SMALLINT
TT_INTEGER
TT_BIGINT
TT_DECIMAL
TT_DATE
TIMEおよびTT_TIME
TT_TIMESTAMP

注意:
TimesTen NCHARデータ型およびNVARCHAR2データ型はUTF-16としてエンコードされます。Oracle Database NCHARデータ型およびNVARCHAR2データ型は、UTF-16またはUTF-8としてエンコードされます。
Oracle Database NCHAR列またはNVARCHAR2列をキャッシュするには、Oracle Database NLS_NCHAR_CHARACTERSETエンコーディングがAL32UTF8ではなくAL16UTF16である必要があります。

SQL演算子

TimesTenでは、Oracle Databaseでサポートされている次の演算子および条件がサポートされています。

-(単項)
+, -, *, /
=, <, >, <=, >=, <>, !=
||
IS NULL、IS NOT NULL
LIKE(Oracle DatabaseのLIKE演算子は後続の空白を無視しますが、TimesTenの場合は無視しません)
BETWEEN
IN
NOT IN(リスト)
AND
OR
+(外部結合)
ANY、SOME
ALL(リスト)
EXISTS
UNION
MINUS
INTERSECT

2つのビット・ベクトル式のビット単位AND演算を実行する場合、TimesTenでは2つの式間にアンパサンド文字(&)が使用され、Oracle Databaseでは2つの式が引数として指定されたBITAND関数が使用されます。

SELECT文

TimesTenでは、Oracle DatabaseでサポートされているSELECT文の次の句がサポートされています。

- FOR UPDATE

- ORDER BY(NULLS FIRSTおよびNULLS LASTを含む)

- GROUP BY(ROLLUP、GROUPING_SETSおよびグループ化式リストを含む)

- 表の別名

- 列の別名

- コンストラクタを使用する副問合せのファクタリング句

Oracle Databaseでは、過去のある時点でのデータベースに対する問合せ(昨日の時点での表に対する問合せなど)を行う、フラッシュバック問合せがサポートされています。TimesTenでは、フラッシュバック問合せをサポートしていません。

TimesTenでは、CONNECT BY句がサポートされていません。

SQL副問合せ

TimesTenでは、Oracle Databaseでサポートされている次の副問合せがサポートされています。

IN(副問合せ)
>,<,= ANY(副問合せ)
>,=,< SOME(副問合せ)
EXISTS(副問合せ)
>,=,<(スカラー副問合せ)
DELETE/UPDATEのWHERE句内の副問合せ
FROM句内の副問合せ
副問合せのファクタリング句(WITHコンストラクタ)

注意:
検証不能スカラー副問合せとは、実行時までその単一行結果セット・プロパティを決定できないスカラー副問合せのことです。TimesTenでは、問合せ全体で1つ以下の検証不能スカラー副問合せを許容できますが、この副問合せはOR式には指定できません。

SQL関数

TimesTenでは、Oracle Databaseでサポートされている次の関数がサポートされています。

ABS
ADD_MONTHS
ASCIISTR
AVG
CAST
CEIL
COALESCE
CONCAT
COUNT
CHR
DECODE
DENSE_RANK
EMPTY_BLOB
EMPTY_CLOB
EXTRACT
FIRST_VALUE
FLOOR
GREATEST
GROUP_ID
GROUPING
GROUPING_ID
INSTR
LAST_VALUE
LEAST
LENGTH
LOWER
LPAD
LTRIM
MAX
MIN
MOD
MONTHS_BETWEEN
NCHR
NLS_CHARSET
NLS_CHARSET_NAME
NLSSORT
NULLIF
NUMTOYMINTERVAL
NUMTODSINTERVAL
NVL
POWER
RANK
REPLACE
ROUND
ROW_NUMBER
RPAD
RTRIM
SIGN
SQRT
SUBSTR
SUM
SYS_CONTEXT
SYSDATE
TO_BLOB
TO_CLOB
TO_CHAR
TO_DATE
TO_LOB
TO_NCLOB
TO_NUMBER
TRIM
TRUNC
UID
UNISTR
UPPER
USER

次のTimesTen関数はOracle Databaseではサポートされていません。

CURRENT_USER
GETDATE
ORA_SYSDATE
SESSION_USER
SYSTEM_USER
TIMESTAMPADD
TIMESTAMPDIFF
TT_HASH
TT_SYSDATE
TTGRIDNODENAME
TTGRIDMEMBERID
TTGRIDUSERASSIGNEDNAME

TimesTenおよびOracle Databaseでは、リテラルN'\UNNNN'に関して異なる解釈をします。TimesTenでは、N'\unnnn'(ここでは、nnnnは数値)は、コードnnnnを使用する各国語キャラクタ・セットの文字として解釈されます。Oracle Databaseでは、N'\unnnn'は、6つのリテラル文字として解釈されます。\uは、エスケープとして処理されません。この違いにより予想外の動作が発生します。たとえば、リテラルを含むWHERE句を使用したキャッシュ・グループのロードは失敗する可能性があります。また、これは、動的ロードおよびキャッシュ・グリッド処理に影響を与える可能性もあります。アプリケーションでは、リテラルではなく、UNISTR SQL関数を使用する必要があります。

SQL式

TimesTenでは、Oracle Databaseでサポートされている次の式がサポートされています。

列参照
順序
NULL
()
バインディング・パラメータ
CASE式
ROWID疑似列
ROWNUM疑似列

TimesTenおよびOracle Databaseでは、リテラルに関して異なる解釈をします。『Oracle TimesTen In-Memory Database SQLリファレンス』の定数に関する説明のHexadecimalLiteralを参照してください。

INSERT/DELETE/UPDATE/MERGE文

TimesTenでは、Oracle Databaseでサポートされている次のDML文がサポートされています。

- INSERT INTO ... VALUES

- INSERT INTO ... SELECT

- UPDATE WHERE式(副問合せが含まれる場合があります)

- DELETE WHERE式(副問合せが含まれる場合があります)

TimesTenでは、新しい値が古い値と同じ場合を除き、主キー値の更新はサポートされません。

TimesTenのみのSQLおよび組込みプロシージャ

この項では、Oracle DatabaseではサポートされていないTimesTenのSQL文とSQL関数および組込みプロシージャを示します。PassThrough= 3を設定すると、次の文はOracle Databaseに渡されて実行され、エラーが発生します。

- すべてのTimesTenキャッシュ・グループのDDLおよびDML文(CREATE CACHE GROUP、DROP CACHE GROUP、ALTER CACHE GROUP、LOAD CACHE GROUP、UNLOAD CACHE GROUP、REFRESH CACHE GROUPおよびFLUSH CACHE GROUPを含む)。

- すべてのTimesTenレプリケーション管理DDL文(CREATE REPLICATION、DROP REPLICATION、ALTER REPLICATION、CREATE ACTIVE STANDBY PAIR、ALTER ACTIVE STANDBY PAIRおよびDROP ACTIVE STANDBY PAIRを含む)。

- FIRST n句。

- ROWS m TO n句。

- すべてのTimesTen組込みプロシージャ。『Oracle TimesTen In-Memory Databaseリファレンス』の組込みプロシージャに関する説明を参照してください。

PL/SQLコンストラクト

TimesTenでは、Oracle Databaseでサポートされているストアド・プロシージャ・コンストラクト、関数、データ型、パッケージおよびパッケージ本体のサブセットがサポートされています。詳細は、『Oracle TimesTen In-Memory Database PL/SQL開発者ガイド』を参照してください。

Oracle Databaseデータ型とTimesTenデータ型の間のマッピング

TimesTenキャッシュ表の列に対してデータ型を選択する場合は、Oracle Database表の列のデータ型を考慮し、キャッシュ表の列に対して同等または互換性のあるデータ型を選択してください。

注意:
パススルーを含め、TimeTenのキャッシュはOracle Database ROWIDデータ型をサポートしません。ただし、SQL問合せのSELECTリストで指定されている場合は、ROWIDデータ型をCHAR(18)データ型にキャストできます。
次の例では、ROWIDデータ型をキャストしないときに返されるエラーを示します。次に、この例では、ROWIDデータ型をCHAR(18)データ型に正しくキャストする方法を示します。

Command> SET PASSTHROUGH 3;
Passthrough command has set autocommit off.
Command> SELECT ROWID FROM dual;
5115: Unsupported type mapping for column ROWID
The command failed.
Command> SELECT CAST (ROWID AS CHAR(18)) FROM DUAL;
< AAAAB0AABAAAAEoAAA >
1 row found.

主キーおよび外部キーの列は、キー以外の列と区別されます。キャッシュ表のキー列で使用可能なデータ型マッピングを表C-1に示します。

表C-1 キー列で使用可能なデータ型マッピング

Oracle Databaseデータ型

TimesTenデータ型

NUMBER(p,s)

NUMBER(p,s)

注意: DECIMAL(p,s)またはNUMERIC(p,s)も使用できます。これらはNUMBER(p,s)の別名です。

NUMBER(p,0)

INTEGER

TT_TINYINT

TT_SMALLINT

TT_INTEGER

TT_BIGINT

NUMBER(p,0)

NUMBER

TT_TINYINT

TT_SMALLINT

TT_INTEGER

TT_BIGINT

NUMBER

CHAR(m)

CHAR(m)

VARCHAR2(m)

VARCHAR2(m)

RAW(m)

VARBINARY(m)

DATE

DATE

TIMESTAMP(m)

TIMESTAMP(m)

NCHAR(m)

NCHAR(m)

NVARCHAR2(m)

NVARCHAR2(m)

表C-2に、キャッシュ表のキー以外の列のデータ型マッピングを示します。

表C-2 キー以外の列で使用可能なデータ型マッピング

Oracle Databaseデータ型

TimesTenデータ型

NUMBER(p,s)

NUMBER(p,s)

REAL

FLOAT

BINARY_FLOAT

DOUBLE

BINARY_DOUBLE

NUMBER(p,0)

INTEGER

TT_TINYINT

TT_SMALLINT

TT_INTEGER

TT_BIGINT

NUMBER(p,0)

FLOAT

BINARY_FLOAT

DOUBLE

BINARY_DOUBLE

NUMBER

TT_TINYINT

TT_SMALLINT

TT_INTEGER

TT_BIGINT

NUMBER

REAL

FLOAT

BINARY_FLOAT

DOUBLE

BINARY_DOUBLE

CHAR(m)

CHAR(m)

VARCHAR2(m)

VARCHAR2(m)

RAW(m)

VARBINARY(m)

LONG

VARCHAR2(m)

注意: mは、VARCHAR2データ型に対して定義された範囲内の任意の有効な値に設定できます。

LONG RAW

VARBINARY(m)

注意: mは、VARBINARYデータ型に対して定義された範囲内の任意の有効な値に設定できます。

DATE

DATE

TIMESTAMP(0)

TIMESTAMP(m)

TIMESTAMP(m)

FLOAT(n)

注意: DOUBLEおよびFLOATが含まれ、いずれもFLOAT(126)に相当します。REALも含まれますが、これはFLOAT(63)に相当します。

FLOAT(n)

BINARY_DOUBLE

注意: FLOAT(126)は、DOUBLEとして宣言できます。FLOAT(63)は、REALとして宣言できます。

BINARY_FLOAT

BINARY_FLOAT

BINARY_DOUBLE

BINARY_DOUBLE

NCHAR(m)

NCHAR(m)

NVARCHAR2(m)

NVARCHAR2(m)

CLOB

VARCHAR2(n)

注意: 1 <= m <= 4MB。

BLOB

VARBINARY(m)

注意: 1 <= m <= 16MB。

NCLOB

NVARCHAR2(m)

注意: 1 <= m <= 4MB。

用語集

エージング

指定時間後(時間ベース)または指定されたデータベース使用状況のレベルに達したとき(LRU)に、キャッシュ・グループのキャッシュ表からキャッシュ・インスタンスを削除することです。

ASYNCHRONOUS WRITETHROUGH(AWT)キャッシュ・グループ

TimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に非同期で伝播されるキャッシュ・グループ。TimesTenデータベースでのコミットは、Oracle Databaseのコミットとは非同期に発生します。

自動リフレッシュ

キャッシュされたOracle Database表でコミットされた更新が、TimesTenキャッシュ表に自動的にリフレッシュされること。

自動リフレッシュ・キャッシュ・グループ

読取り専用キャッシュ・グループまたはAUTOREFRESH MODE INCREMENTALキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループ。

双方向送信

TimesTenキャッシュ表でコミットされた更新をキャッシュされたOracle Database表に伝播し、キャッシュされたOracle Database表でコミットされた更新をTimesTenキャッシュ表にリフレッシュすることです。

キャッシュ管理ユーザー

キャッシュ・グリッドを管理し、特定のキャッシュ・グループ・タイプの定義済動作を実行するための情報が保存されるOracle Databaseオブジェクトを作成し、保持するOracle Databaseユーザー。

キャッシュ・エージェント

キャッシュ・グループ処理(自動リフレッシュ、キャッシュ・グループのロードおよびOracle Databaseへの文のパススルーおよび実行)を行うTimesTenプロセス。

キャッシュ・グループ

TimesTenデータベースにキャッシュするOracle Database表のデータを定義します。キャッシュ・グループは、単一のOracle Database表のすべてかその一部または一連の関連付けられたOracle Database表をキャッシュできます。複数のOracle Database表がキャッシュされる場合、各キャッシュ表(ルート表を除きます)は、外部キー制約によってキャッシュ・グループ内の別のキャッシュ表を参照する必要があります。

キャッシュ・グリッド

単一のOracle DatabaseからTimesTenデータベースにデータをキャッシュし、キャッシュ一貫性を確保するために連携する、TimesTenインメモリー・データベースで構成される一連の分散グリッド・メンバー。

キャッシュ・グループ主キー

キャッシュ・グループのルート表の主キー。

キャッシュ・インスタンス

キャッシュ・グループのルート表の主キーによって識別される特定のデータ行。キャッシュ・グループに複数の表がある場合、キャッシュ・インスタンスは、外部キー関係を介してルート表の行と関連付けられている子表の行のセットで構成されます。

キャッシュ・マネージャ・ユーザー

キャッシュ・グリッドの作成と構成、キャッシュ・グループの作成など、キャッシュ・グリッドおよびキャッシュ・グループの処理を実行するTimesTenユーザー。

キャッシュ表

キャッシュ・グループ内のルート表または子表。

キャッシュ表ユーザー

キャッシュ表を所有するTimesTenユーザー。

子表

ルート表の主キーへの外部キー参照、またはルート表を直接または間接的に参照する別の子表の主キーへの外部キー参照を持つキャッシュ表。キャッシュ・グループ内の表階層で、子表を他の子表の親に指定できます。キャッシュ・グループ内では、キャッシュ表を複数の親の子にすることはできません。

動的キャッシュ・グループ

キャッシュ表にあるデータを、リクエストに応じて、あるいは手動または自動でロードできるキャッシュ・グループ・カテゴリ。

動的ロード

問合せに対してキャッシュ・グリッド・メンバーのデータで対応できない場合に行われる、Oracle Database表からローカル・グリッド・メンバーへのデータの転送。

明示的にロードされるキャッシュ・グループ

キャッシュ表にあるデータを手動または自動でロードできるキャッシュ・グループ・カテゴリ。

フラッシュ

ユーザー管理キャッシュ・グループのTimesTenキャッシュ表でコミットされた挿入または更新をキャッシュされたOracle Database表に手動で伝播することです。

グローバル・キャッシュ・グループ

キャッシュ表のデータが、1つのキャッシュ・グリッド内の複数のTimesTenデータベース間で共有されるキャッシュ・グループの分類。

グリッド・データ転送

ローカル・グリッド・メンバー上のキャッシュ表のデータにより対応できない問合せに応答して行う、リモート・グリッド・メンバーからローカル・グリッド・メンバーへのキャッシュ・インスタンスの転送。

グリッド・メンバー

スタンドアロンTimesTenデータベースまたはアクティブ・スタンバイ・ペアのいずれかで構成されるキャッシュ・グリッドのコンポーネント。

グリッド・ノード

スタンドアロン・データベースか、アクティブ・スタンバイ・ペアのアクティブ・データベースまたはスタンバイ・データベースのいずれかであるグリッド・メンバーのTimesTenデータベース。

ロード

キャッシュされたOracle Database表からTimesTenキャッシュ表に、新しいキャッシュ・インスタンスをコピーすることです。キャッシュ表にある既存のキャッシュ・インスタンスは更新または削除されません。

ローカル・キャッシュ・グループ

データベースが同じキャッシュ・グリッドのメンバーであっても、キャッシュ表内のデータが複数のTimesTenデータベース間で共有されていないキャッシュ・グループの分類。

Oracle Databaseスキーマ・ユーザー

TimesTenデータベースにキャッシュされるOracle Database表を所有するOracle Databaseユーザー。

Oracle Database timestenユーザー

キャッシュ・グリッドに関する情報が保存されているOracle Database表を所有するOracle Databaseユーザー。

伝播

TimesTenキャッシュ表でコミットされた更新をキャッシュされたOracle Database表に送信することです。

読取り専用キャッシュ・グループ

キャッシュされたOracle Database表でコミットされた更新がTimesTenキャッシュ表に自動的にリフレッシュされるキャッシュ・グループ。読取り専用キャッシュ・グループ内のキャッシュ表は直接更新できません。

リフレッシュ

明示的にロードされるキャッシュ・グループの場合、キャッシュ・グループをアンロードしてからロードすることです。

動的キャッシュ・グループの場合、キャッシュ表内の既存のキャッシュ・インスタンスをキャッシュされたOracle Database表からの最新データに置き換えること。

レプリケーション

複数のデータベースでデータの重複コピーを保持するプロセス。

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

各マスター・データベースおよびサブスクライバTimesTenデータベースでのレプリケーションは、レプリケーション・エージェント・プロセスで制御されます。マスター・データベースのレプリケーション・エージェントは、トランザクション・ログ・レコードを読み取り、レプリケートされた要素でコミットされた更新をサブスクライバ・データベースのレプリケーション・エージェントに送信します。その後、サブスクライバ・データベースのレプリケーション・エージェントによって、更新がサブスクライバ・データベースに適用されます。

AWTキャッシュ・グループでは、レプリケーション・エージェントがキャッシュ表でコミットされた更新をキャッシュされたOracle Database表に送信します。

ルート表

外部キー制約によってキャッシュ・グループ内の他の表を参照しないキャッシュ・グループ内の親表。ルート表の主キーは、キャッシュ・グループの主キーです。

SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ

TimesTenキャッシュ表でコミットされた更新が、キャッシュされたOracle Database表に自動的に同期して伝播されるキャッシュ・グループ。アプリケーションでトランザクションがコミットされる場合は、TimesTenでコミットされる前にOracle Databaseでコミットされます。

システム管理キャッシュ・グループ

システム管理キャッシュ・グループでは、定義済動作が実行されます。システム管理キャッシュ・グループのタイプには、読取り専用、同期ライトスルーおよび非同期ライトスルーがあります。

TT_CACHE_ADMIN_ROLEロール

キャッシュ管理ユーザーに付与されるロール。このロールでは、キャッシュ・グリッドの情報を保存する、timestenユーザーによって所有されているOracle Database表の権限が定義されます。

ユーザー管理キャッシュ・グループ

カスタマイズされた動作(双方向送信など)を実装するキャッシュ・グループ。

アンロード

キャッシュ表からキャッシュ・インスタンスを削除することです。キャッシュされたOracle Database表の行に影響はありません。

索引
A  B  C  D  E  F  G  H  I  L  M  N  O  P  Q  R  S  T  U  V  W

A

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

アクティブ・データベース, 6.2.1

作成, 6.2.1

定義, 6.2

読取り専用サブスクライバ・データベース, 6.2.3

スタンバイ・データベース, 6.2.2

AgentFailoverTimeoutパラメータ, 11.3 エージング・ポリシー

キャッシュ・グループ, 4.5

LRUエージング, 4.5.1

時間ベースのエージング, 4.5.2

非同期WRITETHROUGHキャッシュ・グループ, 「AWT キャッシュ・グループ」を参照 自動コミット

グローバル問合せ, 6.4, 6.4.1

自動リフレッシュ

クリーンアップ

Oracle Databaseオブジェクトの削除, 7.5

定義, 1.2.3 例, 2.5.2 増分

トランザクションの非一貫性の回避, 8.3.1.2

開始, 4.2.5, 5.2.4 間隔, 4.2.5 モード, 4.2.5 選択制限, 8.3.2 状態, 4.2.5 統計, 8.5 ステータス, 7.4 自動リフレッシュ・キャッシュ・グループ

変更ログ表, 7.4

最適化, 7.6.1

定義, 3.2.1 ロードおよびリフレッシュ, 5.2.1 Oracle Databaseオブジェクトの手動による作成, 4.2.5.2 監視, 7.2.2 読取り専用

パフォーマンス, 8.3.1, 8.3.2

リカバリ方法, 7.4 ステータス, 7.4 トランザクションの再要求パフォーマンス, 8.4 AUTOREFRESHキャッシュ・グループ属性, 4.2.5 AWTキャッシュ・グループ

作成, 2.3.3, 4.2.2

定義, 1.2.2, 4.2.2

エラー・レポート, 4.2.2.3, 4.2.2.5

監視, 7.2.3

パラレル伝播, 4.2.2.2, 8.2.1

バッチ・サイズ, 4.2.2.2.3

制限, 4.2.2.4 awterrsファイル, 4.2.2.3, 4.2.2.5

XML書式のDTD, 4.2.2.5

XML書式, 4.2.2.5

B

BLOBデータ

TimesTenでのキャッシュ, 4.4

組込みプロシージャ

ttAgingLRUConfig, 4.5.1

ttAgingScheduleNow, 4.5.3

ttCacheAWTMonitorConfig, 7.2.3

ttCacheAWTThresholdSet, 7.2.4

ttCacheConfig, 7.4

AgentTimeoutパラメータ, 7.4

AutoRefreshLogTblSpaceUsagePCTパラメータ, 7.6.2

TblSpaceFullRecoveryパラメータ, 7.6.3

ttCacheDbCgStatus, 7.4 ttCacheDDLTrackingConfig, 7.2.7, 7.2.7 ttCachePolicySet, 3.6.1 ttCacheStart, 2.3.2, 3.6 ttCacheStop, 2.7.5, 3.6, 9.5 ttCacheUidGet, 3.5 ttCacheUidPwdSet, 2.1.4, 3.3.4 ttGridAttach, 2.4, 3.6.1, 4.7.4 ttGridCreate, 2.2, 3.4.2.2 ttGridDestroy, 2.7.4, 9.4 ttGridDetach, 2.7.1, 9.1 ttGridDetachList, 9.1 ttGridInfo, 7.2.5 ttGridNameSet, 2.2, 3.4.2.3 ttGridNodeStatus, 7.2.5 ttRepPolicySet, 4.2.2.1 ttRepStart, 2.3.4, 4.2.2.1 ttRepStateGet, 7.7 ttRepStateSet, 6.2.1 ttRepStop, 2.7.2, 4.2.2.1, 9.2, 9.2 ttRepSubscriberWait, 7.2.7, 9.3

C

キャッシュ

管理, 3.2.3, 3.2.4

Oracle Databaseオブジェクト全体の管理, 3.2.4

パフォーマンス評価, 10.1

キャッシュ管理ユーザー

複数のTimesTenデータベースでの表のキャッシュ, 8.6

作成, 2.1.1, 3.2.1, 10.2.1

デフォルトの表領域

作成, 2.1.1, 3.2.1, 10.2.1

削除, 2.7.6, 9.7, 10.6.1, 10.6.2

監視, 7.6

一杯になった場合のリカバリ, 7.6.3

使用量警告しきい値, 7.6.2

定義, 2.1.1, 3.2.1 判別, 3.5 TimesTenデータベースでの設定, 2.1.4, 3.3.4 キャッシュ・アドバイザ

構成, 10.2

リポジトリ・データベースの構成, 10.2.2

ターゲットOracle Databaseの構成, 10.2.1

TimesTenデータベースの構成, 10.2.3

DataPump, 10.4.1

実行, 10.4

-exportオプション, 10.4.1

-ftpオプション, 10.4.1

ターゲットOracle Databaseの識別, 10.4

-importオプション, 10.4.1

-OraDirNfsオプション, 10.4.1

概要, 10

performanceオプション, 10.4.1

後処理クリーンアップ, 10.6

キャッシュ・グループ定義の推奨, 10.1

リポジトリsetupスクリプト, 10.2.2

サポートされる構成, 10.2.4

ターゲット

setupスクリプト, 10.2.1

使用のガイドライン, 10.2.4 キャッシュ・エージェント

接続障害, 7.1.1

Oracle Databaseとの再接続, 11.1

起動, 2.3.2, 3.6

起動ポリシー

およびキャッシュ・グリッド, 3.6.1

定義, 3.6.1

設定, 3.6.1

ステータス, 7.1, 7.1 停止, 2.7.5, 3.6, 9.5 タイムアウト, 7.4 キャッシュ・グリッド

TimesTenデータベースの関連付け, 2.2, 3.4.2.3

TimesTenデータベースのアタッチ, 2.4, 4.7.4

キャッシュ・エージェント

起動ポリシー, 3.6.1, 3.6.1

キャッシュ・エージェント起動ポリシー, 7.7 作成, 2.2, 3.4.2.2 データ転送, 4.7.1, 4.7.2 定義, 1.1, 1.1.1, 3.4, 3.4.2 破棄, 2.7.4, 9.4 デタッチ

一連のTimesTenデータベース, 9.1

TimesTenデータベース, 2.7.1, 9.1

障害, 7.7 ローカル結合を使用するグローバル問合せ, 6.4.1 インスタンスの所有者, 4.7.1 データの場所, 6.4.2 メンバー

アタッチ, 7.7

定義, 1.1.1, 3.4.2

すべてデタッチ, 9.1

ポート, 4.7.4

データの共有, 6.3

メンバーの障害, 3.6.1 ノード

定義, 1.1.1, 3.4.2

Oracle Databaseシステム・パラメータ, 3.4.2.1 リカバリ, 7.7 10個以上のノード, 3.4.2.1 ttRepStateGetの使用, 7.7, 7.7 キャッシュ・グループ

自動リフレッシュ

定義, 1.2.3, 3.2.1

大規模なトランザクション, 8.3.1

トランザクションの再要求パフォーマンス, 8.4

作成, 2.3 dead

リカバリ, 7.4

定義, 1.2, 4.1 動的ロード, 5.3 フラッシュ

定義, 1.2.3

ロード, 1.2.3 読取り専用

自動リフレッシュ, 8.3.2

自動リフレッシュの向上, 8.3.1, 8.3.2

推奨事項

キャッシュ・アドバイザ, 10.1

リフレッシュ, 1.2.3 表階層, 4.1.2 表のパーティション, C.4.1.1 キャッシュ・インスタンス

定義, 1.2.1, 5.3

所有者, 4.7.1

所有権, 4.7, 4.7.1

伝播

定義, 1.2.3

キャッシュ・マネージャ・ユーザー

作成, 2.1.3, 3.3.2, 10.2.3

定義済, 3.3.2

定義, 2.1.3, 2.1.3, 3.3.2

最小限の権限, 2.1.3, 3.3.3, 10.2.3

キャッシュ表

複数のTimesTenデータベースのキャッシュ, 8.6

ON DELETE CASCADE属性, 4.2.7

PROPAGATE属性, 4.2.4.2

READONLY属性, 4.2.4.1

UNIQUE HASH ON属性, 4.2.8

ユーザー

作成, 2.1.3, 3.3.2

定義済, 3.3.2

定義, 2.1.3, 3.3.2

CacheAWTMethod初期接続属性, 8.2 CacheAWTParallelismデータ・ストア属性, 3.3.1, 4.2.2.2 cacheCleanUp.sql SQL*Plusスクリプト, 7.5, B.1 CacheGridEnable接続属性, 3.3.1, 3.4.1, 3.4.2.2 CacheGridMsgWait接続属性, 4.7.1, 4.7.2 cachegroups ttIsqlコマンド, 2.3.3, 7.2.1 cacheInfo.sql SQL*Plusスクリプト, B.1 CacheParAwtBatchSizeパラメータ, 4.2.2.2.3 cachesqlget ttIsqlコマンド, 4.2.5.2, 7.2.7 変更ログ表

最適化, 7.6.1

キャラクタ・セット(character set)

Oracle Database, 10.2.3

子表

定義, 1.2, 4.1.2

CLOBデータ

TimesTenでのキャッシュ, 4.4

CONNECT BY句, C.4.6 接続

TimesTenおよびOracle Database間, 3.5

障害

キャッシュ・エージェント, 7.1.1

Oracle Database, 11.1

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

接続属性

CacheGridEnable, 3.4.1, 3.4.2.2

CacheGridMsgWait, 4.7.1, 4.7.2

DatabaseCharacterSet, 3.3.1

DynamicLoadEnable, 5.3.1

DynamicLoadErrorMode, 5.3.4

LockLevel, 3.3.1

OracleNetServiceName, 3.3.1

OraclePWD, 3.3.1

PassThrough, 3.3.1, 5.7

PermSize, 3.3.1

PWD, 3.3.1

RACCallback, 11.3

TypeMode, 3.3.1

UID, 3.3.1

CREATE ACTIVE STANDBY PAIR文, 6.2.1

D

Data Guard, 12.1

データ・ストア属性

CacheAWTParallelism, 3.3.1

ReplicationApplyOrdering, 3.3.1

データ型

Oracle DatabaseとTimesTenの相違点, C.4.4

Oracle DatabaseとTimesTenの間のマッピング, C.5

キー列のマッピング, C.5

キー以外の列のマッピング, C.5

データベース

キャラクタ・セット, 10.2.3

複製, 6.2.2

一時, 4.2

DatabaseCharacterSet接続属性, 3.3.1 DDL文

追跡, 7.2.7

DeadDbRecoveryパラメータ, 7.4, 7.4 DROP ACTIVE STANDBY PAIR文

例, 9.3

DROP CACHE GROUP文

例, 2.7.3, 9.3

DSN

キャッシュ・アドバイザ

TimesTenデータベース, 10.2.3

TimesTenデータベース

例, 2.1.2

TimesTenデータベースのDSN

例, 3.3.1

データベースの複製, 6.2.2 動的キャッシュ・グループ

作成, 4.6

定義, 1.2.4, 4.6

動的グローバル・キャッシュ・グループ

動的ロード, 4.7.1

動的ロード

構成, 5.3.1

定義, 4.7.1, 5.3

無効, 5.3.1

エラーの表示, 5.3.4

例, 2.6.1, 5.3.3

ガイドライン, 5.3.2

ルール, 5.3.2

DynamicLoadEnable接続属性, 5.3.1, 5.3.1 DynamicLoadErrorMode接続属性, 5.3.4

E

環境変数

Microsoft Windows, 3.1.2

UNIX, 3.1.1

明示的にロードされるキャッシュ・グループ

定義, 1.2.4

F

障害

キャッシュ・グリッド・メンバー, 7.7

Fast Application Notification(FAN), 11.1 FLUSH CACHE GROUP文

定義, 5.4

例, 5.4

外部キー

索引, 4.2.2.2

制限, 4.2.2.2

G

グローバル・キャッシュ・グループ

定義, 1.2.5, 4.7

動的, 4.7.1

動的ロード, 5.3

例, 動的, 4.7.1

例, 明示的にロードされる, 4.7.2

明示的にロードされる, 4.7.2

所有権の変更, 7.2.6

グリッド・メンバー間のデータの共有, 6.3

グローバル問合せ, 6.4

自動コミット, 6.4, 6.4.1

ローカル結合, 6.4.1

グローバル・アンロード処理, 5.5.1 GlobalLocalJoinオプティマイザ・フラグ, 6.4.1 GlobalProcessingオプティマイザ・フラグ, 6.4 GlobalProcessingオプティマイザ・ヒント

アンロード処理, 5.5.1

grantCacheAdminPrivileges.sqlスクリプト, 10.2.1, 10.2.1 grantCacheAdminPrivileges.sql SQL*Plusスクリプト, 2.1.1, 3.2.3, B.1 グリッド, 「キャッシュ・グリッド」を参照

H

高可用性

アクティブ・スタンバイ・ペア, 1.3

キャッシュ・グリッド, 1.3

Data Guard, 1.3

Oracle Real Application Clusters(Oracle RAC), 1.3

I

索引

外部キー, 4.2.2.2

initCacheAdminSchema.sql SQL*Plusスクリプト, 3.2.4, B.1 initCacheGlobalSchema.sqlスクリプト, 10.2.1 initCacheGlobalSchema.sql SQL*Plusスクリプト, 2.1.1, 3.2.1, 10.2.1, 10.2.2, B.1 initCacheGridSchema.sql SQL*Plusスクリプト, 3.2.4, B.1 インスタンス管理者, 2.1.3

L

LOAD CACHE GROUP文

定義, 5.2

例, 2.5.1, 5.2, 5.2.8

PARALLEL句, 5.2.6

WITH ID句, 5.2.3

LOBデータ

キャッシュ管理ユーザーの権限, A.2

TimesTenでのキャッシュ, 4.4

キャッシュに対する制限, 4.4

ローカル・キャッシュ・グループ

定義, 1.2.5

LockLevel接続属性, 3.3.1 LRUエージング・ポリシー, 4.5.1

M

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

Oracle Database, 4.2.4, C.4.1

最大可用性アーキテクチャ(MAA), 12.1 複数表のキャッシュ・グループ, 4.1.2

N

NCLOBデータ

TimesTenでのキャッシュ, 4.4

O

OCIAttrGet() OCI関数

OCI_ATTR_ROW_COUNTオプション, 5.6

ON DELETE CASCADEキャッシュ表属性, 4.2.7 Oracle Database

自動リフレッシュ

クリーンアップ, 7.5

AWTエラー, 4.2.2.5 キャラクタ・セット(character set)

判別, 3.3.1

接続障害, 11.1 キャッシュ管理のためのオブジェクトの作成, 3.2.3 データベース・キャラクタ・セット

判別, 10.2.3

TimesTenとの違い, C.1 実行エラー, 4.2.2.5 キャッシュの手動管理, 3.2.4 キャッシュ管理のためのオブジェクト

判別, 3.2.4

表およびトリガー, 7.3

パーティション表, C.4.1.1 スキーマ・ユーザー

作成, 2.1.1, 3.2.1, 10.2.1

定義, 3.2.1

サーバー・リリース

サポート対象, 3.1

シノニム

キャッシュ, 4.3

ユーザー

キャッシュ管理ユーザー, 2.1.1

定義, 2.1.1

削除, 2.7.6, 9.7

権限, 3.2.2, A.2

スキーマ・ユーザー, 2.1.1

ユーザー

timestenユーザー, 3.2.1

Oracle RAC

TimesTen Cacheの使用, 11.3

TimesTen Cacheの使用, 11.1

Oracle Real Application Clusters(Oracle RAC) Oracle SQL*Plusスクリプト

cacheCleanUp.sql, 7.5, B.1

cacheInfo.sql, B.1

grantCacheAdminPrivileges.sql, 2.1.1, 3.2.3, B.1

initCacheAdminSchema.sql, 3.2.4, B.1

initCacheGlobalSchema.sql, 2.1.1, 3.2.1, 10.2.1, 10.2.2, B.1

initCacheGridSchema.sql, 3.2.4, B.1

OracleNetServiceName接続属性, 3.3.1 OraclePWD接続属性, 3.3.1 所有者

キャッシュ・インスタンス, 4.7.1

所有権

キャッシュ・インスタンス, 4.7, 4.7.1

P

パラレル伝播

AWTキャッシュ・グループ, 4.2.2.2, 8.2.1

外部キー

制限, 4.2.2.2

制限, 4.2.2.2.1 パーティション, C.4.1.1 PassThrough接続属性, 3.3.1, 5.7

およびRETURN TWOSAFE, 5.7

パススルー・レベル

変更, 5.7.8

設定, 5.7

パフォーマンス

キャッシュ・アドバイザ, 10.1

Oracle DatabaseとTimesTenの比較, 10.1

読取り専用キャッシュ・グループ

増分自動リフレッシュ, 8.3.2

大規模なトランザクション, 8.3.1

トランザクションの再要求, 8.4 PermSize接続属性, 3.3.1 ポート

キャッシュ・グリッド・メンバー, 4.7.4

権限

Oracle Databaseユーザー, 3.2.2, A.2

伝播

キャッシュ・インスタンス

定義, 1.2.3

エラー・レポート, 4.2.2.5 例, 2.6.2 パラレル, 4.2.2.2, 8.2.1 PROPAGATEキャッシュ表属性, 4.2.4.2 PWD接続属性, 3.3.1

Q

問合せ

キャッシュ・グリッド, 6.4

グローバル, 6.4

R

RACCallback接続属性, 11.3

読取り専用キャッシュ・グループ

自動リフレッシュ

パフォーマンス, 8.3.1, 8.3.2

作成, 2.3.3, 4.2.1 定義, 1.2.2, 4.2.1 増分自動リフレッシュ

統計, 8.5

大規模なトランザクション, 8.3.1 制限, 4.2.1.1 READONLYキャッシュ表属性, 4.2.4.1 リフレッシュ

自動リフレッシュ, 4.2.5

キャッシュ・グループ, 1.2.3

開始, 5.2.4

REFRESH CACHE GROUP文

定義, 5.2

例, 5.2, 5.2.8

PARALLEL句, 5.2.6

WITH ID句, 5.2.3

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

接続障害, 7.1.1

開始, 2.3.4, 4.2.2.1

起動ポリシー

定義, 4.2.2.1

設定, 4.2.2.1

ステータス, 7.1, 7.1 停止, 2.7.2, 4.2.2.1, 9.2, 9.2 ReplicationApplyOrderingデータ・ストア属性, 3.3.1, 4.2.2.2 ReplicationParallelismデータ・ストア属性, 4.2.2.2 ルート表

定義, 1.2, 4.1.2

S

スキーマ・ユーザー

作成, 2.1.1

定義, 2.1.1

スクリプト

SQL*Plus, B

TimesTen Cache, B

選択制限, 8.3.2 SELECT文

キャッシュ・グリッド, 6.4

グローバル, 6.4

セマンティクス

Oracle DatabaseとTimesTenの相違点, C.2

単一表のキャッシュ・グループ, 4.1.1 スライド期間

キャッシュ・グループ, 4.5.4

SQL

TimesTenとOracle間の相違, C.4

SQLRowCount() ODBC関数, 5.6 Statement.getUpdateCount() JDBCメソッド, 5.6 SYNCHRONOUS WRITETHROUGH(SWT)キャッシュ・グループ

作成, 4.2.3

定義, 1.2.2, 4.2.3

制限, 4.2.3.1

sys.odbc.ini

キャッシュ・アドバイザ

例, 10.2.3

システム管理キャッシュ・グループ, 4.2

T

表

複数のTimesTenデータベースのキャッシュ, 8.6

Oracle Database, 7.3

パーティション, C.4.1.1

表領域

デフォルトの作成, 2.1.1, 3.2.1, 10.2.1

最適化, 7.6.1

デフォルトの削除, 2.7.6, 9.7, 10.6.1, 10.6.2

一杯になった, 7.6.3

デフォルトの監視, 7.6

一杯になった場合のリカバリ, 7.6.3, 7.6.3

しきい値, 7.6.2, 7.6.2

使用量の通知, 7.6.2

稼働率, 7.6.1

TAF

概要, 11.1

タイムアウト, 11.3

TblSpaceFullRecoveryパラメータ, 7.6.3 時間ベースのエージング・ポリシー, 4.5.2 TimesTenユーザー

キャッシュ・マネージャ・ユーザー, 2.1.3, 2.1.3, 3.3.2

キャッシュ表ユーザー, 2.1.3, 3.3.2

トランザクション

増分自動リフレッシュ

パフォーマンス, 8.3.1

大規模

増分コミット, 8.3.1

パフォーマンス, 8.3.1

再要求操作

パフォーマンス, 8.4, 8.4

セマンティクス

Oracle DatabaseとTimesTenの相違点, C.2

AWTキャッシュ・グループのトランザクション・ログ・ファイルのしきい値

設定, 7.2.4

Transparent Application Failover (TAF), 「TAF」を参照。 トリガー

Oracle Database, 7.3

TT_CACHE_ADMIN_ROLEロール

定義, 2.1.1, 3.2.1

削除, 2.7.6, 9.7, 10.6.1, 10.6.1

ttAdminユーティリティ

-cachePolicyコマンド, 3.6.1

-cacheStartコマンド, 3.6

-cacheStopコマンド, 3.6

-cacheUidGetコマンド, 3.5

-cacheUidPwdSetコマンド, 3.3.4

-queryコマンド, 7.1

-repPolicyコマンド, 4.2.2.1

-repStartコマンド, 4.2.2.1

-repStopコマンド, 4.2.2.1

ttAgingLRUConfig組込みプロシージャ, 4.5.1 ttAgingScheduleNow組込みプロシージャ, 4.5.3 ttca_setupRepostoryスクリプト, 10.2.2 ttCacheAdvisorユーティリティ

-oraConnオプション, 10.4

-oraDirObjectオプション, 10.4

-oraTargetオプション, 10.4

使用方法, 10.4

ttCacheAutorefIntervalStatsGet組込みプロシージャ, 8.5 ttCacheAutorefresh組込みプロシージャ, 4.2.5, 5.2.4 ttCacheAutoRefreshLogDefrag組込みプロシージャ

表領域の最適化, 7.6.1.1

ttCacheAutorefreshSelectLimit組込みプロシージャ, 8.3.2 ttCacheAutorefreshStatsGet組込みプロシージャ

表領域

稼働率, 7.6.1

ttCacheAutorefreshXactLimit組込みプロシージャ, 8.3.1 ttCacheAWTMonitorConfig組込みプロシージャ, 7.2.3 ttCacheAWTThresholdSet組込みプロシージャ, 7.2.4 ttCacheConfig

使用量の通知, 7.6.2

ttCacheConfig組込みプロシージャ

AgentFailoverTimeoutパラメータ, 11.3

AgentTimeoutパラメータ, 7.4

AutoRefreshLogTblSpaceUsagePCTパラメータ, 7.6.2

AwtErrrorXmlOutput, 4.2.2.5

DeadDbRecoveryパラメータ, 7.4

表領域の最適化, 7.6.1

一杯になった表領域, 7.6.3

TblSpaceFullRecoveryパラメータ, 7.6.3

ttCacheDbCgStatus組込みプロシージャ, 7.4 ttCacheDDLTrackingConfig組込みプロシージャ, 7.2.7, 7.2.7 ttCachePolicySet組込みプロシージャ, 3.6.1 ttCacheStart組込みプロシージャ, 2.3.2, 3.6 ttCacheStop組込みプロシージャ, 2.7.5, 3.6, 9.5 ttCacheUidGet組込みプロシージャ, 3.5 ttCacheUidPwdSet組込みプロシージャ, 2.1.4, 3.3.4, 10.2.3 ttDBConfig, 4.2.2.2.3 ttDbConfig組込みプロシージャ, 8.4 ttDestroyユーティリティ, 9.6 ttGridAttach組込みプロシージャ, 2.4, 4.7.4, 7.7

データベース障害後のコール, 3.6.1

ttGridCreate組込みプロシージャ, 2.2, 3.4.2.2 ttGridDestroy組込みプロシージャ, 2.7.4, 9.4 ttGridDetach組込みプロシージャ, 2.7.1, 9.1 ttGridDetachAll組込みプロシージャ, 9.1 ttGridDetachList組込みプロシージャ, 9.1 ttGridGlobalCGResume組込みプロシージャ, 7.2.6 ttGridGlobalCGSuspend組込みプロシージャ, 7.2.6 ttGridInfo組込みプロシージャ, 7.2.5 TTGRIDMEMBERID() SQL関数, 6.4.2 ttGridNameSet組込みプロシージャ, 2.2, 3.4.2.3 TTGRIDNODENAME() SQL関数, 6.4.2 ttGridNodeStatus組込みプロシージャ, 7.2.5 TTGRIDUSERASSIGNEDNAME() SQL関数, 6.4.2 ttIsql set dynamicloadenableコマンド, 5.3.1 ttIsql set dynamicloaderrormodeコマンド, 5.3.4 ttIsqlユーティリティ, 2.1.3, 10.2.3

cachegroupsコマンド, 2.3.3, 7.2.1

cachesqlgetコマンド

INCREMENTAL AUTOREFRESHオプション, 4.2.5.2

ORACLE_DDL_TRACKINGオプション, 7.2.7

set passthroughコマンド, 5.7.8 ttOptSetFlag組込みプロシージャ

DynamicLoadEnableフラグ, 5.3.1

DynamicLoadErrorModeフラグ, 5.3.4

PassThroughフラグ, 5.7.8

ttRepAdmin -duplicateユーティリティ, 6.2.2

-keepCGオプション, 6.2.2

-noKeepCGオプション, 6.2.3

ttRepPolicySet組込みプロシージャ, 4.2.2.1 ttRepStart組込みプロシージャ, 2.3.4, 4.2.2.1 ttRepStateGet組込みプロシージャ, 7.7 ttRepStateSet組込みプロシージャ, 6.2.1 ttRepStop組込みプロシージャ, 2.7.2, 4.2.2.1, 9.2, 9.2 ttRepSubscriberWait組込みプロシージャ, 7.2.7, 9.3 ttStatusユーティリティ, 7.1 TypeMode接続属性, 3.3.1

U

UID接続属性, 3.3.1

UNIQUE HASH ONキャッシュ表属性, 4.2.8

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

グローバル, 5.5.1

UNLOAD CACHE GROUP文

定義, 5.5

例, 5.5

ユーザー

作成, 2.1.1

定義, 2.1.1

Oracle Database

作成, 10.2.1

削除, 9.7

ユーザー管理キャッシュ・グループ

双方向送信, 4.2.4

作成, 4.2.4.3, 4.2.4.3

定義, 1.2.2, 4.2.4

V

ビュー

Oracle Database, 4.2.4, C.4.1

W

WHERE句, 4.2.6

Oracle Database PL/SQLファンクションの参照, 4.2.6.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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。