Oracle® TimesTen In-Memory Database

トラブルシューティング・ガイド

11g リリース2 (11.2.2)

B66722-03(原本部品番号:E21636-11)

2014年10月

Oracle TimesTen In-Memory Databaseトラブルシューティング・ガイド, 11g リリース2(11.2.2)

B66722-03

Copyright © 2011, 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.5.0の新機能

- リリース11.2.2.1.0の新機能

- リリース11.2.2.0.0の新機能

1 TimesTenのトラブルシューティング・ツール

- ttCaptureユーティリティの使用

- ttIsqlユーティリティの使用

- ttStatusユーティリティの使用

- TimesTenデーモンによって生成されるログの使用

- ttTraceMonユーティリティの使用

- トレースの開始とトレース・バッファの参照

- SQLトレース

- APIトレース

- DEADLOCKトレース

- LOCKトレース

- ERRトレース

- AGINGトレース

- AUTOREFRESHトレース

- ttXactAdminユーティリティの使用

- ODBCトレースの使用

- SNMPトラップによるイベントの検出

- TimesTen SYSTEM表の監視

- 問合せオプティマイザの使用

2 TimesTenアプリケーションおよびデータベースのトラブルシューティング

- TimesTenデーモンを起動または停止できない

- TimesTenのデーモン、サブデーモンからレスポンスがない

- TimesTenユーザー・エラー・ログを確認する

- コア・ファイルからスタック・トレースを抽出する

- 共有セグメントを作成できない

- アプリケーションがダイレクト・モードでデータベースに接続できない

- データベースのアップグレード

- データベースに接続する権限

- データベースにアクセスするファイル・システム権限を確認する

- TimesTenデーモンが稼働していることを確認する

- DSN定義を確認する

- DSN属性を確認する

- データベースのパス名とトランザクション・ログ・ディレクトリを確認する

- セマフォおよび共有メモリー・セグメントを管理する

- 使用可能なスワップ領域(仮想メモリー)を確認する

- 使用可能なファイル記述子の数を増やす

- クライアント/サーバーの問題のトラブルシューティング

- TimesTen Serverに接続できない

- TimesTen Serverで障害が発生した

- Server DSNが見つからない

- TimesTen ServerがDRIVERのロードに失敗した

- TimesTen Serverへのアクセス時にアプリケーションのタイムアウトが発生した

- TimesTen ClientがTimesTen Serverとの接続を失った

- IPC用の共有メモリー・セグメントとの接続に失敗した

- Windows XPでのサーバーの最大接続数の増加

- 複数のクライアント接続の使用時にスレッド・スタックのオーバーフローが発生した

- DSNによる新しいデータベースの指定で領域が不足する

- アプリケーションでの接続または切断が遅い

- データベースがリカバリ中であるかどうかを確認する

- ODBCトレースを確認する

- アプリケーションが予期せず切断された

- ODBC、JDBC、OCI、Pro*CおよびPL/SQLアプリケーション・エラーの確認

- ユーザー・エラー・ログを確認する

- アプリケーションが遅い

- 接続モードを検討する

- 表の統計を更新する

- ロック・レベルと分離レベルを検証する

- トレースの設定を確認する

- 表のパーティション数を確認する

- アプリケーションからのレスポンスがない、ハングしている可能性がある

- ログを確認し、トレース情報を収集する

- ODBCエラーを確認する

- デッドロックとタイムアウトを確認する

- 作成済の表がアプリケーションで見つからない

- Temporary DSN属性を確認する

- Overwrite DSN属性を確認する

- データベースへのパス名を確認する

- OCIおよびPro*C/C++アプリケーションのトラブルシューティング

- リソースを使い果たす

- オペレーティング・システム・ツールおよび共有メモリー

- データベースに割り当てられたメモリーの量を確認する

- 永続メモリー領域が一杯である

- 一時メモリー領域が一杯である

- 問合せオプティマイザの統計を更新する

- 問合せで使用されるメモリーを確認する

- データベースの致命的なクラッシュ後、メモリーが不足する

- トランザクション・ログ・ファイルのディスク領域の使用を確認する

- トレースが有効になっているかを確認する

- セマフォの制限を確認する

- SELECT文の結果が重複する

- PL/SQL共有メモリーをアタッチできない

3 TimesTen Application-Tier Database Cacheのトラブルシューティング

- キャッシュ・グループを作成できない

- キャッシュ・エージェントを起動または停止できない

- キャッシュ・エージェントのステータスを確認する

- ORACLE_HOME環境変数を確認する

- NLS環境変数を確認する

- 予期しないシステム・シャットダウン後のキャッシュ・グリッドのリカバリ

- キャッシュ・グリッド・ノードの一部が実行中である場合

- すべてのキャッシュ・グリッド・ノードが予期せず終了した場合

- Oracleサービス名を解決できない

- 接続識別子を解決できない

- Oracle Databaseサーバーおよびクライアントのバージョンに互換性がない

- Oracle Databaseユーザー名およびパスワードを有効化できない

- ライブラリ・パス環境変数を確認する

- TNSリスナーおよびOracle Database Serverのステータスを確認する

- Oracle Database権限を確認する

- DSN定義を確認する

- TimesTenマシンを再起動する

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

- ユーザー環境とシステム環境を確認する

- ロードされた動的ライブラリを検証する

- OCIの初期化に失敗する

- サポートされていないデータ型マッピング

- Null制約がOracle Databaseと一致しない

- キャッシュされたOracle表へのDDLのため、キャッシュ・グループ操作が失敗する可能性がある

- キャッシュ・グループ内のオブジェクトの更新後に変更を表示できない

- ロードまたはリフレッシュに失敗する

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

- ttCacheAutorefreshStatsGetプロシージャの使用

- 変更ログ表の情報の表示

- サポート・ログの自動リフレッシュに関するメッセージの理解

- 自動リフレッシュの失敗の診断

- 自動リフレッシュのパフォーマンス問題の診断

- SNMPトラップによる自動リフレッシュの問題のアラート

- TimesTenキャッシュのパフォーマンスを最適化する

- Oracle Database表の大規模なバッチ・ジョブで発生するパフォーマンスおよびメモリーの問題を回避する

- 自動リフレッシュ時に指定した間隔でキャッシュがリフレッシュされない

- 自動リフレッシュ状態をリセットする

- 自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする

- 自動リフレッシュ・モード、状態または間隔の変更時にロック・タイムアウト状態を回避する

- 増分自動リフレッシュが進行中ではない

- 自動リフレッシュOracle Databaseオブジェクトの有効化

- 増分自動リフレッシュが完全自動リフレッシュになる

- 増分自動リフレッシュが完全自動リフレッシュになっている場合の検出

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

- キャッシュ管理ユーザーの表領域が一杯になった場合の診断

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

- キャッシュ管理の表領域が一杯になった場合の考慮事項

- 自動リフレッシュのパフォーマンスが悪い

- レスポンスがないTimesTenデータベースまたは停止したTimesTenデータベースによる自動リフレッシュのパフォーマンスの低下

- キャッシュされたTimesTenデータベースのタイムアウトの設定

- 特定のキャッシュ・グループに対するリカバリ方法の構成

- リソースにおける自動リフレッシュ・キャッシュ・グループ・リフレッシュの待機時間が長すぎる

- 変更ログや実表が異常に大きいと、自動リフレッシュのパフォーマンスが低下する

- 断片化した自動リフレッシュの変更ログ表領域

- 自動リフレッシュ間隔が小さいと、パフォーマンスが低下する

- 制約にNOVALIDATEを宣言すると、キャッシュ・グループの作成に失敗する

- DBMS_LOCKとのロック競合を表示するAWRレポート

4 レプリケーションのトラブルシューティング

- レプリケーション・スキームを作成できない

- レプリケーション・スキームを変更できない

- レプリケーション・エージェントを起動または停止できない

- SNMPトラップを使用してレプリケーション・イベントを通知する

- レプリケーションが正しく機能しない

- TimesTenデーモンとレプリケーション・エージェントのステータスを確認する

- レプリケーション・エージェントが通信していることを確認する

- レプリケーションの状態を確認する

- レプリケーション・スキームの構成を確認する

- ttRepAdmin -showconfigの確認

- TTREP.TTSTORES表の確認

- ホスト名の確認

- 所有者名を確認する

- レプリケーションの所有者の確認

- 表の所有者の確認

- レプリケーション表間の整合性を確認する

- レプリケーションからのレスポンスがない、ハングしている可能性がある

- レプリケーションの状態を確認する

- RETURN RECEIPTタイムアウトの設定を確認する

- レプリケーションまたはXLAのパフォーマンスが悪い

- ネットワーク帯域幅を確認する

- RETURN RECEIPTブロッキングの使用を確認する

- レプリケーションの構成を確認する

- ログ・バッファのサイズを確認する

- 永続性の設定を確認する

- トランザクション・ログ・ファイルからの読取りの有無を確認する

- ttRepAdmin使用時の問題

- レプリケーションの受信側の状態を変更した場合の問題

- ttRepAdmin -duplicate使用時の問題

- 複製前にデータベースを作成した

- 間違ったデータベースまたはホスト名

- 「Must specify -scheme」エラーが返される

- 競合チェック時の問題

- レプリケーションのタイムスタンプに列を使用できない

- タイムスタンプが存在しない

- 競合レポートのためにレプリケーションが遅くなる

- パラレル・レプリケーションの問題

5 AWTキャッシュ・グループのトラブルシューティング

- レプリケーション・エージェントが起動しない

- AWTパフォーマンスの監視

- AWTパフォーマンスの監視の有効化

- ttRepAdminユーティリティを使用したAWTパフォーマンスの表示

- システム表を使用したAWT操作の監視

- AWTのパフォーマンスが悪い場合に考えられる原因

- Oracle Databaseに関する問題

- UNLOAD CACHE GROUPは、伝播の完了に行の更新が必要

- AWTのTimesTenで報告されるOracle Databaseエラー

- TimesTenによって報告される永続的なOracle Databaseエラー

- TimesTenによって報告される一時的なOracle Databaseエラー

索引

はじめに

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

対象読者

このマニュアルには、Oracle TimesTen In-Memory Databaseの使用時に発生するいくつかの問題のトラブルシューティング方法が示されています。

このマニュアルは、データベース・システムの仕組みを理解しているとともに、SQL(Structured Query Language)についての一般的な知識を持っていることを前提としています。

関連ドキュメント

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

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

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

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

表記規則

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

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

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

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

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

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

[ ]

大カッコは、コマンドライン内の項目が任意であることを表します。

{ }

中カッコは、コマンドライン内の縦線(|)で区切られた項目のうち、1つが必須であることを表します。

|

選択項目の引数を区切る縦線(パイプ)。

. . .

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

%

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

#

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

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

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

timesten

TimesTenのインスタンス管理者を示す名前の例です。TimesTenの管理者名に、適切な名前を任意に使用することができます。Windowsの場合は、TimesTenのインスタンス管理者はAdministratorsグループのメンバーである必要があります。すべてのTimesTenインスタンスには、一意のインスタンス管理名があります。

DSN

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

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

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

Oracle Supportへのアクセス

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

新機能

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

リリース11.2.2.7.0の新機能

- ユーザー・エラー・ログ・メッセージの新しいRECOVERY指定は、TimesTen自動リカバリのステータスを報告するメッセージに対応します。これはttDaemonLogユーティリティで制御できるカテゴリではないため、メッセージを無効にすることはできません。

リリース11.2.2.5.0の新機能

- ユーザー定義のパラレル・レプリケーションで問題が発生している場合、「パラレル・レプリケーションの問題」を参照してください。

リリース11.2.2.1.0の新機能

- レプリケーションでセカンダリIPアドレスを使用するように構成されている場合に、レプリケーションの受信側の状態を変更しようとすると、/etc/hostsファイルの不適切な構成が原因で、ttRepAdminがエラーを出力します。詳細は、「レプリケーションの受信側の状態を変更した場合の問題」を参照してください。

- サブスクライバに間違ったホスト名を入力したり、レプリケーション・スキームにサブスクライバ・データベース名やホスト名を間違って入力した場合、エラーが表示されます。詳細は、「間違ったデータベース名またはホスト名」を参照してください。

リリース11.2.2.0.0の新機能

- AWTパフォーマンスでロスが発生する場合の考えられる原因に関する情報が追加されました。詳細は、「AWTパフォーマンスの監視」を参照してください。

- キャッシュ・エージェント・デーモンのエラー・ログ・メッセージは次のように修正されました。

- TimesTen ORAコンポーネントは、Oracle DatabaseメッセージのOracle Database標準であると間違って理解される場合がよくあります。現在、TimesTen ORAコンポーネントは、CACHEに名前が変更され、キャッシュ・エージェント・デーモンにCAC指定があります。

- これまで、TimesTenエラー・メッセージは出力された時にメッセージ番号を記載していませんでした。現在、すべてのメッセージにメッセージ番号が記載されるようになったため、ユーザーはエラー・メッセージ・ガイドを参照して詳細を確認することができます。

これらの変更点の例については、「サポート・ログの自動リフレッシュに関するメッセージの理解」を参照してください。

1 TimesTenのトラブルシューティング・ツール

この章の次の項では、TimesTenデータベースの問題を診断するためのTimesTenユーティリティおよびその他のツールの使用方法について説明します。

- ttCaptureユーティリティの使用

- ttIsqlユーティリティの使用

- ttStatusユーティリティの使用

- TimesTenデーモンによって生成されるログの使用

- ttTraceMonユーティリティの使用

- ttXactAdminユーティリティの使用

- ODBCトレースの使用

- SNMPトラップによるイベントの検出

- TimesTen SYSTEM表の監視

- 問合せオプティマイザの使用

ttCaptureユーティリティの使用

ttCaptureユーティリティは、TimesTenシステムの構成および状態に関する情報をファイルに捕捉し、TimesTenテクニカル・サポートはこのファイルの情報を利用して、ttCapture実行時のシステムのスナップショットを確認することができます。ttCaptureユーティリティは、ttcapture.date.time.logというファイルを生成します。デフォルトでは、ファイルは、ttCaptureユーティリティの呼出し元であるディレクトリに書き込まれます。ttCapture -destオプションを使用すると、出力ファイルを別のディレクトリに書き込むように指示できます。

ttCaptureを再度実行すると、新しいファイルに情報が書き込まれます。

Windowsプラットフォームの場合は、ttCaptureを実行するとttcapture.date.time.nfoというファイルも作成されます。このファイルには、msinfo32ユーティリティからの出力が含まれます。

TimesTenデータベースで問題が発生した場合は、問題が発生しているときまたは発生直後、早急にそのデータベースに対して、DSNオプションを指定してttCaptureを実行します。

注意:
ディレクトリ名およびファイル名に空白が含まれる場合は、必ず二重引用符で囲んでください。

TimesTenテクニカル・サポートにお問合せいただく場合は、ttcapture.date.number.logファイルをサービス・リクエストにアップロードしてください。Windowsをご使用の場合は、ttcapture.date.time.nfoファイルもアップロードする必要があります。

他のオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCaptureに関する項を参照してください。

ttIsqlユーティリティの使用

ttIsqlユーティリティを使用すると、対話形式でSQL文を実行して、TimesTenデータベースに関するステータス情報をレポートできます。

TimesTenのすべてのSQL操作は、ttIsqlのCommand>プロンプトから実行できます。

例1-1 ttIsqlユーティリティの使用

demoデータベースに対してttIsqlユーティリティを起動するには、次のように入力します。

% ttIsql demo

次のような出力が表示されます。

Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.

connect "DSN=demo";
Connection successful: DSN=demo;UID=testuser;DataStore=/scratch/testuser/demo;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=128;
TypeMode=0;
(Default setting AutoCommit=1)

SQL文またはttIsqlコマンドをCommandプロンプトから実行できます。TimesTen組込みプロシージャをコールすることもできます。ここで役立つプロシージャは、ttConfigurationです。ttConfigurationを実行すると、TimesTenの現在のデータベース接続の接続属性の値が表示されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttConfigurationに関する項を参照してください。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のttIsqlユーティリティの使用に関する説明では、最も一般的なttIsqlコマンドの使用方法を説明しています。問題の解決によく使用されるttIsqlコマンドは、次のとおりです。

- monitorは、SYS.MONITOR表の内容をフォーマットします。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベース構造情報の表示に関する説明を参照してください。

- dssizeは、データベースのサイズ情報を出力します。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベース構造情報の表示に関する説明を参照してください。

- showplanは、このトランザクションでの選択、更新および削除のオプティマイザの実行計画を出力します。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の問合せオプティマイザ計画の確認と変更に関する説明を参照してください。

- timingは、問合せのタイミングを出力します。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のtiming ODBC関数コールに関する説明を参照してください。

- optprofileは、現在のオプティマイザ・フラグの設定と結合順序を出力します。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の問合せオプティマイザ計画の確認と変更に関する説明を参照してください。

ttIsql機能の完全なリストについては、『Oracle TimesTen In-Memory Databaseリファレンス』のユーティリティに関する説明にあるttIsqlユーティリティのオプションとコマンドのリストを参照してください。

ttStatusユーティリティの使用

ttStatusユーティリティを使用すると、TimesTenデーモンのステータスと、すべてのTimesTen接続の状態を確認できます。

例1-2 ttStatusによってTimesTenデーモンが稼働していないことが示される

この例のttStatus出力は、TimesTenデーモンが稼働していないことを示しています。デーモンが突然停止したときのトラブルシューティングについては、「TimesTenのデーモン、サブデーモンからレスポンスがない」を参照してください。

Windowsの場合:

C:\>ttStatus
ttStatus: Could not connect to the TimesTen service.
If the TimesTen service is not running, please start it by running
"ttDaemonAdmin -start".

UNIXプラットフォームの場合:

$ ttStatus
ttStatus: Could not connect to the TimesTen daemon.
If the TimesTen daemon is not running, please start it
by running "ttDaemonAdmin -start".

例1-3 ttStatusによってTimesTenデーモンが稼働していることが示される

この例のttStatusの出力は、TimesTenデーモンが稼働していることを示しています。demoという1つのデータベースがあります。

最初の行は、TimesTenインスタンスのmyinstanceに対して、TimesTenデーモンがプロセス4579としてポート4738で稼働していることを示しています。2行目は、TimesTen Serverがプロセス4588としてポート4740で稼働していることを示しています。

現在、データベースには、1ユーザー接続と11サブデーモン接続の合計12つの接続があります。

データベースのキャッシュ・エージェントおよびレプリケーション・エージェントの再起動ポリシーはmanualに設定されています。

$ ttStatus
TimesTen status report as of Wed May  1 16:37:51 2013

Daemon pid 4579 port 4738 instance myinstance
TimesTen server pid 4588 started on port 4740
------------------------------------------------------------------------
Data store /scratch/testuser/demo
There are 12 connections to the data store
Shared Memory KEY 0x02010008 ID 7798789
PL/SQL Memory KEY 0x03010008 ID 7831558 Address 0x7fa0000000
Type            PID     Context             Connection Name              ConnID
Process         4631    0x0000000009b3e800  demo                              1
Subdaemon       4584    0x0000000000616460  Manager                         142
Subdaemon       4584    0x000000000066d210  Rollback                        141
Subdaemon       4584    0x000000000074ea00  Flusher                         140
Subdaemon       4584    0x00000000007a3c90  Monitor                         139
Subdaemon       4584    0x00000000007f8790  Deadlock Detector               138
Subdaemon       4584    0x000000000084f2f0  Aging                           136
Subdaemon       4584    0x0000000000863db0  Log Marker                      135
Subdaemon       4584    0x00000000008fcf70  IndexGC                         132
Subdaemon       4584    0x00002aaabcb008d0  Checkpoint                      137
Subdaemon       4584    0x00002aaabcb555f0  HistGC                          133
Subdaemon       4584    0x00002aaabcc008d0  AsyncMV                         134
Replication policy  : Manual
Cache Agent policy  : Manual
PL/SQL enabled.
------------------------------------------------------------------------
Accessible by group g900
End of report

例1-4 ttStatusによって古いインスタンスへの接続が示される

この例では、データベースの古いインスタンスへの接続を示します。これは、データベースを無効化する際に、一部のユーザーがメモリー内にまだ格納されている無効化の対象となるデータベースのコピーを切断していない場合に発生します。すべてのユーザーが切断した後に、メモリーは自動的に解放されます。

C:\>ttStatus

TimesTen status report as of Mon Aug  6 22:03:04 2012
Daemon pid 5088 port 17000 instance MYINSTANCE
TimesTen server pid 4344 started on port 17002
-----------------------------------------------------------------
Data store c:\temp\sample
There are no connections to the data store
Obsolete or not yet active connection(s):
Process  4696 context 0xd08800 name sample connid 1, obsolete connection, shmKey
'Global\DBI45b94c6f.3.SHM.4'
Replication policy : Manual
Cache agent policy : Manual
-----------------------------------------------------------------
End of report

TimesTenデーモンによって生成されるログの使用

TimesTenデーモンおよびそのサブデーモンとエージェントは、エラー、警告および情報メッセージを生成します。これらのメッセージは、TimesTenのシステム管理およびアプリケーションのデバッグに役立ちます。

デフォルトでは、情報メッセージは次の場所に格納されます。

- 実行が必要になる可能性があるアクションなど、注意する必要がある情報を含むユーザー・エラー・ログ

- ユーザー・エラー・ログ内のすべての情報に加えて、TimesTenカスタマ・サポートが使用する情報を含まれるサポート・ログ。

場所やサイズなど、ログの構成に関する情報については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の情報メッセージの変更に関する説明を参照してください。

すべてのメッセージ・カテゴリは、デフォルトで有効化されますが、ttDaemonLogユーティリティのオプションを使用すると、すべてのデータベースまたは指定したデータベースに対して、次のカテゴリのユーザー・エラー・ログ・メッセージを無効化または明示的に有効化することができます。

- ALL (デフォルト): すべてのメッセージが対象です

- CACHE: CACで指定する、キャッシュ・エージェントからのメッセージが対象です。

- DAEMON: メイン・デーモンおよびサブデーモンからのメッセージが対象です。

- DAEMONDBG: メイン・デーモンおよびサブデーモンからの追加情報が対象です。

- REPLICATION: REPで指定する、レプリケーション・エージェントからのメッセージが対象です。

- SERVER: TimesTen Serverからのメッセージが対象です。

ttDaemonLogオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDaemonLogに関する項を参照してください。

ttTraceMonユーティリティの使用

ttTraceMonユーティリティを使用すると、多数のTimesTenコンポーネントについて様々なトレース情報を記録できます。各TimesTenコンポーネントは、様々な詳細レベルでトレースできます。ttTraceMonをshowサブコマンド付きで指定すると、トレース可能なすべてのTimesTenコンポーネントとそれらの現在のトレース・レベルを表示できます。ttTraceMonのオプションの完全なリストについては、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttTraceMon」の項を参照してください。

トレースの出力をファイルに行うと、TimesTenのトレース処理は、アプリケーションのパフォーマンスに大きく影響し、大量のディスク領域を消費します。また、AWTキャッシュ・グループを使用している場合は、ttTraceMonでORACONコンポーネントのトレースを試行するときに、レプリケーション・エージェントを再起動する必要があります。ttTraceMonユーティリティは、問題を診断するときにのみ使用してください。診断が終了したら、トレースをデフォルト値にリセットしてください。

例1-5 コンポーネントのデフォルトのトレース・レベル

この例は、demoデータベースに対するほとんどのトレース・コンポーネントがレベル0(OFF)に設定されていることを示しています。ERRおよびDEADLOCKコンポーネントのトレースは、どちらもデフォルトでは1に設定されています。詳細は、「ERRトレース」を参照してください。

% ttTraceMon -e show demo
AGING        ... 0
API          ... 0
ASYNCMV      ... 0
AUTOREFRESH  ... 0
CG           ... 0
CGRID        ... 0
CGRIDC       ... 0
CKPT         ... 0
DEADLOCK     ... 1
EE           ... 0
ERR          ... 1
FLOW         ... 0
HEAP         ... 0
LATCH        ... 0
LOCK         ... 0
LOG          ... 0
LOGF         ... 0
OPT          ... 0
ORACON       ... 0
PLOAD        ... 0
PT           ... 0
REPL         ... 0
SM           ... 0
SQL          ... 0
TEST         ... 0
TRACE        ... 0
XA           ... 0
XACT         ... 0

ほとんどのTimesTenコンポーネントの出力は、TimesTenテクニカル・サポートでのみ使用されます。ただし、SQL、API、LOCK、ERR、AGINGおよびAUTOREFRESHコンポーネントの出力は、アプリケーションの問題のトラブルシューティングで役立つ場合があります。

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

- トレースの開始とトレース・バッファの参照

- SQLトレース

- APIトレース

- DEADLOCKトレース

- LOCKトレース

- ERRトレース

- AGINGトレース

- AUTOREFRESHトレース

トレースの開始とトレース・バッファの参照

新しいトレースは、ttTraceMon datastoreを指定して開始します。たとえば、demoデータベースでトレースを開始するには、次のように入力します。

%  ttTraceMon demo
Trace monitor; empty line to exit
Trace >

Traceプロンプトで、トレース・タイプとそのレベルを指定します。たとえば、レベル3でSQLコンポーネントのトレースを開始するには、次のように入力します。

Trace > level sql 3

この時点で、アプリケーションを実行でき、TimesTenのトレース情報がトレース・バッファに書き込まれます。トレース・バッファの内容を読み取るには、次の2つの方法があります。

- Traceプロンプトで、outfileコマンドを使用して、トレース・バッファのデータを出力するファイルを指定します(アプリケーションの実行前に行う必要があります)。これは、アプリケーションを実行する前に行う必要があります。トレース情報がファイルに書き込まれるとき、新しいトレース情報はファイルの既存の内容に連結されます。

- Traceプロンプトで、dumpコマンドを使用してトレース・バッファ・データを画面に表示します。

注意:
トレース・バッファには、新しいトレースごとに内容が累積されます。トレース・バッファを消去するには、ttTraceMonプロンプトでflushコマンドを使用します。flushコマンドを使用してコンポーネントを指定すると、特定のコンポーネントのバッファされたトレース・レコードが消去されます。

トレース・バッファから出力される各レコードの書式は次のとおりです。

timestamp   sequence   component   level   connection   processid
operation

レコードのフィールドは次のように定義されています。

- timestampは、操作が実行された時刻です。

- sequenceは、トレース行を識別する連番です。

- componentは、トレース対象のTimesTenコンポーネント(SQL、API、LOCK、ERRなど)です。

- levelは、そのトレース行に関連付けられたトレース・レベルです。トレース・レベルの範囲はコンポーネントによって異なりますが、すべてのコンポーネントで、最も低いトレース・レベルは冗長度が最低の出力を生成し、最も高いトレース・レベルは冗長度が最高の出力を生成します。たとえば、レベル4でSQLトレースを行うと、出力にはレベル2(prepare)、3(execute)および4(open、close、fetch)の行が含まれます。

注意:
いくつかのコンポーネントのトレース・レベルは、連続した範囲の数値ではありません。コンポーネントでサポートされているレベルに対応しない数値を入力した場合、入力した数値より小さく、最も高いサポート・レベルでトレースが発生します。たとえば、コンポーネントのトレース・レベルが1、2、3、4、6で、5を入力すると、レベル1、2、3、4のトレース・イベントが生成されます。

- connectionは、トレースを生成した接続を識別する内部接続IDです。この数値は、ttStatus出力で表示されるConnIDに対応しています。接続IDは、トランザクションIDの最初の要素としても使用されます。

- processidは、トレースを生成したプロセスのオペレーティング・システム・プロセスIDです。

- operationは、発生した操作(SQL文、API操作、エラー・メッセージなど)です。

たとえば、レベル3のSQLトレース後のトレース・バッファの行は、次のようになります。

10:39:50.231 5281 SQL 2L 1C 3914P Preparing: select cust_num from customer

SQLトレース

ttTraceMonをSQLコンポーネントで使用すると、TimesTenエンジンによって準備または実行されているSQLに関する情報が提供されます。表1-1に、SQLトレース・レベルを示します。「+」サインの付いた各レベルには、該当するレベルで説明されているトレース情報に加え、該当レベルより上のすべてのレベルの情報も含まれます。

表1-1 SQLトレース・レベル

レベル

出力

2

準備されているSQLコマンド

3

+ 実行中のSQLコマンド。

4

+ コマンドをプールする効果(準備されたコマンドはすでにプールに存在するため、準備は行われない)、再準備の必要性(索引が作成されたためなど)、および破棄されるコマンド

このレベルでは、ttTraceMon によって問合せコマンドのオープン、フェッチおよびクローズのタイミングも示されます。

5

+ コマンド番号などの内部データ(通常、ユーザー・レベルでのデバッグには役立ちません)

注意:
SQLのトレースは、レベル3または4で実行することをお薦めします。SQLトレースでは、オプティマイザに関する情報は表示されません。オプティマイザのトレースは、レベル4で別のコンポーネント(OPT)によって管理され、ユーザーが使用するようには設計されていません。

例1-6 SQLトレース

この例では、demoデータベースに対してSQLトレースをレベル4で実行するためにttTraceMonを実行します。SQLトレースの出力は、SQLtrace.txtファイルに書き込みます。その後、トレースで過去のSQL文がレポートされないようにバッファをフラッシュします。

% ttTraceMon demo
Trace monitor; empty line to exit
Trace > outfile SQLtrace.txt
Trace > level sql 4
Trace > flush

この時点で、次のSQL文を含むアプリケーションを実行します。

SELECT * FROM departments WHERE department_id = 10;

トレース情報がSQLtrace.txt ファイルに書き込まれます。

12:19:36.582     269 SQL      2L    3C  29570P Preparing: select * from
departments where department_id = 10
12:19:36.583     270 SQL      4L    3C  29570P sbSqlCmdCompile ()(E): (Found
already compiled version: refCount:01, bucket:28) cmdType:100, cmdNum:1000146.
12:19:36.583     271 SQL      4L    3C  29570P Opening: select * from departments
where department_id = 10;
12:19:36.583     272 SQL      4L    3C  29570P Fetching: select * from
departments where department_id = 10;
12:19:36.583     273 SQL      4L    3C  29570P Closing: select * from departments
where department_id = 10;
5 records dumped

アプリケーションが完了したら、SQLトレースをオフにし、ttTraceMonを終了します。

Trace > level sql 0
Trace > {press ENTER – blank line}

APIトレース

APIトレースは、データベースへの接続、接続属性の変更、トランザクションのコミットなどのデータベース操作のために生成されます。表1-2に、APIトレース・レベルを示します。「+」サインの付いた各レベルには、該当するレベルで説明されているトレース情報に加え、該当レベルより上のすべてのレベルの情報も含まれます。

表1-2 APIトレース・レベル

レベル

出力

1

サブデーモンが実行したロールバックのすべての試行

アプリケーションが異常終了し、サブデーモンがその接続をリカバリする場合に実行されます。

2

+ ある程度の領域不足の状態

3

+ データベースに対する作成、接続、切断、チェックポイント、バックアップおよび圧縮の各操作と、各接続のコミットおよびロールバック、その他のいくつかの操作

4

+ TimesTenの内部APIレベルで処理されるその他のほとんどの操作

ストレージ・マネージャおよび索引に対して実行され、内部で実行される多数の操作は表示されません。

注意:
レベル3でのトレースをお薦めします。

例1-7 APIトレース

この例では、demoデータベースに対してAPIトレースをレベル3で実行するためにttTraceMonを実行します。APIトレースの出力は、APItrace.txtファイルに書き込まれます。APIトレースをバッファに保存する前に、flushコマンドを使用してバッファを空にします。

% ttTraceMon demo
Trace monitor; empty line to exit
Trace> outfile APItrace.txt
Trace> level api 3
Trace > flush

ここでアプリケーションを実行します。アプリケーションが完了したら、APIトレースを無効にし、ttTraceMonを終了します。

Trace > level api 0
Trace > {press ENTER – blank line}

APItrace.txtの内容は、次の出力例に似ています。出力は、データベースへの接続、接続キャラクタ・セットの設定、分離レベルの設定およびトランザクションのコミットを示しています。

11:54:26.796    1016 API      3L    2C   4848P sb_dbConnect()(X)
11:54:26.796    1017 API      3L    2C   4848P sb_dbConnCharsetSet()(E)
11:54:26.796    1018 API      3L    2C   4848P sb_dbConnSetIsoLevel()(E)
11:54:39.795    1019 API      3L    2C   4848P sb_dbConnSetIsoLevel()(E)
11:54:45.253    1020 API      3L    2C   4848P sb_xactCommitQ()(E)

DEADLOCKトレース

DEADLOCKコンポーネントを使用して、すべてのアプリケーションにおけるデッドロックの発生状況をトレースします。

表1-3に、DEADLOCKトレース・レベルを示します。「+」サインの付いた各レベルには、該当するレベルで説明されているトレース情報に加え、該当レベルより上のすべてのレベルの情報も含まれます。

表1-3 DEADLOCKトレース・レベル

レベル

出力

1

検出されたデッドロック・サイクル

4, 6

+ デッドロックの検出方法に関する詳細な情報の説明

例1-8 DEADLOCKトレース

この例では、myDSNデータベースに対して、DEADLOCKトレースをデフォルトのレベル1で実行するために、ttTraceMonを実行します。

myDSNへの2つの接続を作成します。最初の接続では、自動コミットは有効になっています。表testを作成して2行挿入します。次に、自動コミットを無効にして、表testのx1=1行を更新します。自動コミットが無効なため、コミットされるまで表に行は挿入されません。トランザクションがコミットされる、またはロールバックされるまで、ロックは保持されます。

Command> create table test (x1 int unique, y1 int);
Command> insert into test values (1,1);
1 row inserted.
Command> insert into test values (2,2);
1 row inserted.
Command> autocommit 0;
Command> update test set y1=y1 where x1=1;
1 row updated.

myDSNへの2つ目の接続では、自動コミットを無効にします。表testのx1=2行を更新します。

Command> autocommit 0;
Command> update test set y1=y1 where x1=2;1 row updated.

これから、お互いにロックされている行の各接続の更新文を実行してデッドロック状況を作成します。1つ目の接続は、x1=2の行に対して更新を実行します。

Command> update test set y1=y1 where x1=2;
6003: Lock request denied because of time-out
Details: Tran 2.1 (pid 32750) wants Un lock on rowid BMUFVUAAAAaAAAAETk,
table ME.TEST. But tran 3.2 (pid 32731) has it in Xn (request was Xn).
Holder SQL (update t1 set y1=y1 where x1=2)
The command failed.

2つ目の接続は、x1=1の行に対して更新を実行します。

Command> update test set y1=y1 where x1=1;
6002: Lock request denied because of deadlock
Details: Tran 3.2 (pid 32731) wants Un lock on rowid BMUFVUAAAAaAAAADzk,
table ME.TEST. But tran 2.1 (pid 32750) has it in Xn (request was Xn).
Holder SQL (update t1 set y1=y1 where x1=1)
The command failed.

flushコマンドを使用してバッファを空にします。

% ttTraceMon myDSN
Trace monitor; empty line to exit
Trace> flush

トレース・バッファには、「1L」からわかるように、すべてのレベル1デッドロック・トレースを表示する次の情報が含まれています。

Trace> dump
09:50:26.444      13 DEADLOCK 1L 2036C   3484P edge 1: xid 3.2, cid 3,
<Row BMUFVUAAAAaAAAADzk,0x8c5
74(574836)> 0 cnt=1 , Tbl 'T1', SQL='update t1 set y1=y1 where x1=1'
09:50:26.455      14 DEADLOCK 1L 2036C   3484P edge 0: xid 2.1, cid 2,
<Row BMUFVUAAAAaAAAAETk,0x8c5
74(574836)> 0 cnt=1 , Tbl 'T1', SQL='update t1 set y1=y1 where x1=2'
09:50:26.455      15 DEADLOCK 1L 2036C   3484P Victim: xcb:3.2,
SQL='update t1 set y1=y1 where x1=1'

さらに詳しい情報を確認する場合は、DEADLOCKトレースに高い値を設定します。たとえば、次では、ttTraceMonでDEADLOCKトレースをレベル4に設定しています。

Trace > level deadlock 4

LOCKトレース

LOCKコンポーネントを使用すると、アプリケーションのロック動作をトレースして、デッドロックまたはロックの待機による問題を検出できます。LOCKトレースは大量の情報を生成するので、適切なトレース・レベルを選択することが重要です。たとえば、レベル3では、ごく一般的なイベントについてもトレースが作成されるため、大量のトレースが発生します。また、トレース自体が読みにくくなることもあります。必要な情報が見つからない場合は、TimesTenテクニカル・サポートに連絡してください。

表1-4に、LOCKトレース・レベルを示します。「+」サインの付いた各レベルには、該当するレベルで説明されているトレース情報に加え、該当レベルより上のすべてのレベルの情報も含まれます。

表1-4 LOCKトレース・レベル

レベル

出力

1

検出されたデッドロック・サイクル

2

+ なんらかの理由によるロック付与の失敗

3

+ ロックの待機(付与の有無に依存しない)

4

+ すべてのロックの付与/解除、ルーチンのコール、デッドロック検出のメカニズム

6

+ サイクルにおける各ステップ

例1-9 LOCKトレース

この例では、myDSNデータベースに対してLOCKトレースをレベル4で実行するためにttTraceMonを実行します。

myDSNへの2つの接続を作成します。最初の接続では、自動コミットを有効にします。表testを作成して3行挿入します。表testを使用してマテリアライズド・ビューを作成します。

レベル4でトレースを有効にし、flushコマンドを使用してバッファを空にします。

% ttTraceMon myDSN
Trace monitor; empty line to exit
Trace> level lock 4
Trace> flush

myDSNへの2つ目の接続では、自動コミットを無効にします。表testに1行挿入します。自動コミットが無効なため、コミットされるまで表に行は挿入されません。トランザクションがコミットされる、またはロールバックされるまで、ロックは保持されます。

dumpコマンドを使用してトレース・バッファの内容を表示すると、トレース・バッファにレコードがないことがわかります。

Trace> dump
0 records dumped

最初の接続からマテリアライズド・ビューを削除してみます。コミットまたはロールバックされていないトランザクションがあるため、ビューは削除されません。

Command> drop materialized view v;
6003: Lock request denied because of time-out
Details: Tran 3.71 (pid 24524) wants Sn lock on table TTUSER.TEST. But tran 1.42
(pid 24263) has it in IXn (request was IXn). Holder SQL (insert into test
values (100);)
The command failed.

トレース・バッファには次の情報が含まれます。

Trace> dump
20:09:04.789  174759 LOCK     3L    3C  24524P ENQ: xcb:00003 <Tbl 0x9b894,0x0>
0+Sn=>SL activity 0 Sn cnt=0; Holder xcb:00001 IXn
20:09:04.789  174760 LOCK     3L    3C  24524P Connection 3 scheduled for sleep
20:09:04.789  174761 LOCK     3L    3C  24524P Connection 3 sleeping
20:09:14.871  174762 LOCK     3L 2047C  24237P Connection 3 timed out
20:09:14.871  174763 LOCK     3L 2047C  24237P Connection 3 woken up
20:09:14.871  174764 LOCK     3L    3C  24524P Connection 3 awake
20:09:14.871  174765 LOCK     2L    3C  24524P ENQ: xcb:00003 <Tbl 0x9b894,0x0>
0+Sn=>TM activity 0 Sn cnt=1; Holder xcb:00001 IXn
7 records dumped

トレースが終了したら、LOCKトレースをデフォルトの設定(0)に戻し、ttTraceMonを終了します。

Trace > level lock 0
Trace > {press ENTER – blank line}

ERRトレース

ERRコンポーネントのトレースが役立つ場合もあります。たとえば、レベル4のERRトレースでは、TimesTenダイレクト・ドライバにプッシュされるすべてのエラー・メッセージが表示されます(内部的に処理されるため、すべてのエラーがユーザーに出力されるわけではありません)。デフォルトは、レベル1のERRトレースです。レベル2および3のERRトレースでは、出力は作成されません。

表1-5に、ERRトレース・レベルを示します。「+」サインの付いた各レベルには、該当するレベルで説明されているトレース情報に加え、該当レベルより上のすべてのレベルの情報も含まれます。

表1-5 ERRトレース・レベル

レベル

出力

1(デフォルトの設定)

致命的エラー

4

+ 他のすべてのエラー・メッセージ。ほとんどがTimesTenで内部的に処理されます

例1-10 ERRトレース

この例では、myDSNデータベースに対してERRトレースをレベル4で実行するためにttTraceMonを実行します。

最初に、表を作成します。

Command> create table test (id tt_integer);

次に、レベル4でトレースを有効にします。前述の例とは異なり、この例ではトレースをファイルに出力するのではなく、トレース・バッファからその内容を直接参照します。ERRトレースをバッファに保存する前に、flushコマンドを使用してバッファを空にします。

% ttTraceMon myDSN
Trace monitor; empty line to exit
Trace> level err 4
Trace> flush

3つのエラーがあるSQLスクリプトを実行します。エラーは次のとおりです。

- 既存の表と同じ名前で表を作成する。

- 誤った構文を使用して表に値を挿入する。

- CHARデータをTT_INTEGER列に挿入する。

Command> create table test (id tt_integer);
2207: Table TEST already exists
The command failed.
Command> insert into test values 'abcd');
1001: Syntax error in SQL statement before or at: "'abcd'", character position:
25
insert into test values 'abcd');
^^^^^^
The command failed.
Command> insert into test values ('abcd');
2609: Incompatible types found in expression
The command failed.

トレース情報はトレース・バッファに書き込まれます。dumpコマンドを使用して、これを表示します。

Trace> dump
19:28:40.465  174227 ERR      4L    1C  24263P TT2207: Table TEST already exists
-- file "eeDDL.c", lineno 2930, procedure "sbEeCrDtblEval()"
19:28:51.399  174228 ERR      4L    1C  24263P TT1001: Syntax error in SQL
statement before or at: "'abcd'", character position: 25
insert into test values 'abcd');
^^^^^^
-- file "ptSqlY.y", lineno 6273, procedure "reserved_word_or_syntax_error"
19:29:00.725  174229 ERR      4L    1C  24263P TT2609: Incompatible types found
in expression -- file "saCanon.c", lineno 12618, procedure "sbPtAdjustType()"
3 records dumped

ERRトレースをデフォルトの設定(1)に戻し、ttTraceMonを終了します。

Trace > level err 1
Trace > {press ENTER – blank line}

AGINGトレース

ttTraceMonユーティリティを使用して次の情報を取得します。

- エージングの開始と終了のタイミング

- エージング・サブデーモンによって何行が削除されたか

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の表へのエージングの実装に関する説明を参照してください。

表1-6に、AGINGトレース・レベルを示します。「+」サインの付いた各レベルには、該当するレベルで説明されているトレース情報に加え、該当レベルより上のすべてのレベルの情報も含まれます。

表1-6 AGINGトレース・レベル

レベル

説明

1

次のイベントに関するメッセージ。

- エージング・サブデーモンによる、最低使用頻度(LRU)エージングまたは時間ベース・エージングの開始。

- LRUしきい値に満たなかったための、エージング・サブデーモンによるLRUエージングの繰返し。

- エージング・サブデーモンによる、LRUエージングまたは時間ベース・エージングの終了。

2

+ 各表に対する次のイベントに関するメッセージ。

- エージングが開始されたかどうか。

- エージングが終了したかどうか。メッセージには、終了した理由と削除された行の数が含まれます。

3

+ 各エージング・サイクルで何行が削除されたかを示す詳細レポート

4

+ サブデーモンのウェイクアップごとのメッセージ

例1-11 AGINGトレース

この例では、myDSNデータベースに対してAGINGトレースを実行するためにttTraceMonを実行します。データベースには、時間ベース・エージングのポリシーが含まれたTTUSER.MYTAB表が含まれています。表の詳細は次のとおりです。

Command> describe TTUSER.MYTAB;

Table TTUSER.MYTAB:
Columns:
*ID                              TT_INTEGER NOT NULL
TS                              TIMESTAMP (6) NOT NULL
Aging use TS lifetime 3 minutes cycle 1 minute on

1 table found.
(primary key columns are indicated with *)

エージング・サイクルが開始される前、表には次の行が含まれています。

Command> select * from TTUSER.MYTAB;
< 1, 2007-03-21 12:54:06.000000 >
< 3, 2010-03-17 08:00:00.000000 >
< 4, 2007-03-21 12:59:40.000000 >
< 5, 2007-03-21 13:00:10.000000 >
< 6, 2007-03-21 13:01:22.000000 >
5 rows found.

AGINGトレースをレベル3で実行するためにttTraceMonを実行します。トレースをファイルに出力するのではなく、トレース・バッファからその内容を直接参照します。AGINGトレースをバッファに保存する前に、flushコマンドを使用してバッファを空にします。

% ttTraceMon myDSN
Trace monitor; empty line to exit
Trace> level aging 3
Trace> flush

dumpコマンドを使用してバッファ内のトレース情報を表示します。

Trace> dump
13:16:56.802    1247 AGING    1L 2045C  17373P Entering sbAgingTB(): curTime=78
13:16:56.803    1248 AGING    2L 2045C  17373P Entering sbAgingOneTable():
curTime=78, ltblid= 637140
13:16:56.804    1249 AGING    3L 2045C  17373P curTime=78, 4 deleted, 1
remaining, tbl = TTUSER.MYTAB
13:16:56.804    1250 AGING    2L 2045C  17373P Exiting sbAgingOneTable():
curTime=78, reason = 'no more rows', 4 deleted, 1 remaining, tbl = TTUSER.MYTAB
13:16:56.804    1251 AGING    1L 2045C  17373P Exiting sbAgingTB(): curTime=78
5 records dumped

AGINGトレースをデフォルトの設定(0)に戻し、ttTraceMonを終了します。

Trace > level aging 0
Trace > {press ENTER – blank line}

AUTOREFRESHトレース

ttTraceMonユーティリティを使用して、AUTOREFRESHキャッシュ・グループ属性を持つキャッシュ・グループの自動リフレッシュ操作の処理状況に関する情報を取得します。

『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のAUTOREFRESHキャッシュ・グループ属性に関する項を参照してください。

表1-7に、AUTOREFRESHトレース・レベルを示します。「+」サインの付いた各レベルには、該当するレベルで説明されているトレース情報に加え、該当レベルより上のすべてのレベルの情報も含まれます。

表1-7 AUTOREFRESHトレース・レベル

レベル

説明

1

その時間隔の自動リフレッシュのサマリー:

- 自動リフレッシュが開始された時間

- その時間隔で自動リフレッシュされた行数

- その時間隔で自動リフレッシュされたルート表の行数

- キャッシュ・エージェントの起動後に自動リフレッシュされた行の総数

- キャッシュ・エージェントの起動後に自動リフレッシュされたルート表の行の総数

- 自動リフレッシュが終了した時間

注意: 時間およびルート表の行に関する情報は、完全自動リフレッシュの場合にレポートされます。

2

+ キャッシュ・グループ・レベルでの自動リフレッシュのサマリー:

- 各キャッシュ・グループで自動リフレッシュが開始された時間

- 各キャッシュ・グループで自動リフレッシュされた行数

- 各キャッシュ・グループで自動リフレッシュされたルート表の行数

- キャッシュ・エージェントの起動後に各キャッシュ・グループで自動リフレッシュされた行の総数

- キャッシュ・エージェントの起動後に各キャッシュ・グループで自動リフレッシュされたルート表の行の総数

- 各キャッシュ・グループで自動リフレッシュが終了した時間

注意: 時間およびルート表の行に関する情報は、完全自動リフレッシュの場合にレポートされます。

3

+ 表レベルでの自動リフレッシュのサマリー:

- 自動リフレッシュが開始された時間

- 自動リフレッシュされた行数

- キャッシュ・エージェントの起動後に自動リフレッシュされた行の総数

- 自動リフレッシュが終了した時間

4

+ 各表の自動リフレッシュの詳細:

- 各表で自動リフレッシュが開始された時間

- 自動リフレッシュ問合せ

- Oracle Databaseで問合せの実行にかかった時間(ミリ秒)

- Oracle Databaseの問合せでフェッチにかかった時間(ミリ秒)

- TimesTenで問合せの適用にかかった時間(ミリ秒)

- Oracle Databaseで子表に対する問合せの実行にかかった時間(ミリ秒)

- Oracle Databaseで子表に対する問合せでフェッチにかかった時間(ミリ秒)

- TimesTenで子表に対する問合せの適用にかかった時間(ミリ秒)

- 各表で自動リフレッシュが終了した時間

- 自動リフレッシュの完了位置を示す自動リフレッシュ・ブックマーク(logseq)

例1-12 AUTOREFRESHトレース

この例では、ttTraceMonユーティリティを使用して、cgDSNデータベースの自動リフレッシュ操作をトレースします。トレース・レベルを1に設定すると、ttCacheAutorefreshStatsGet組込みプロシージャの出力に似た情報が表示されます。

% tttracemon cgDSN
Trace monitor; empty line to exit
Trace> level autorefresh 1
Trace> dump

08:56:57.445 19398 AUTOREFRESH 1L 5C 32246P Autorefresh number 1415 started
for interval 60000
08:56:57.883 19419 AUTOREFRESH 1L 5C 32246P Duration For Interval 60000ms: 420
08:56:57.883 19420 AUTOREFRESH 1L 5C 32246P Num Rows For Interval 60000ms: 0
08:56:57.883 19421 AUTOREFRESH 1L 5C 32246P Num Root Rows For Interval
60000ms: 0
08:56:57.883 19422 AUTOREFRESH 1L 5C 32246P Cumulative Rows for Interval
60000ms: 11587
08:56:57.883 19423 AUTOREFRESH 1L 5C 32246P Cumulative Root Rows for Interval 60000ms: 1697
08:56:57.883 19424 AUTOREFRESH 1L 5C 32246P Autorefresh number 1415 ended for
interval 60000ms successfully.
7 records dumped

レベル4でトレースすると、自動リフレッシュ操作1415に関する追加情報が生成されます。 testuser.readcacheキャッシュ・グループ、testuser.readtabルート表および自動リフレッシュ間隔に関する自動リフレッシュ情報が提供されます。

Trace> level autorefresh 4
Trace> dump

08:56:57.445 19398 AUTOREFRESH 1L 5C 32246P Autorefresh number 1415 started for
interval 60000
08:56:57.471 19399 AUTOREFRESH 2L 5C 32246P Autorefresh started for cachegroup
TESTUSER.READCACHE
08:56:57.471 19400 AUTOREFRESH 3L 5C 32246P Incremental autorefresh started for
table TESTUSER.READTAB
08:56:57.471 19401 AUTOREFRESH 4L 5C 32246P Autorefresh Query: SELECT L."COL_10",
X."COL_20", X.ft$NotDelete, Z.rowid FROM (SELECT DISTINCT "COL_10" FROM
"TESTUSER"."TT_06_454854_L" WHERE logseq >:logseq AND ft_cacheGroup <>
100000000000*1844259679+-299200618) L,(SELECT "TESTUSER"."READTAB"."COL_10",
"TESTUSER"."READTAB"."COL_20", 1 AS ft$NotDelete  FROM "TESTUSER"."READTAB",
"TESTUSER"."T1" WHERE "TESTUSER"."READTAB"."COL_10" = "TESTUSER"."T1"."COL_10")
X, "TESTUSER"."READTAB" Z WHERE L ."COL_10" = X."COL_10" (+) AND X."COL_10" =
Z."COL_10" (+), logseq: 7
08:56:57.870 19402 AUTOREFRESH 3L 5C 32246P Duration for table
TESTUSER.READTAB: 70
08:56:57.870 19403 AUTOREFRESH 3L 5C 32246P Num Rows for table
TESTUSER.READTAB: 1
08:56:57.870 19404 AUTOREFRESH 3L 5C 32246P Cumulative rows for table
TESTUSER.READTAB: 1559
08:56:57.870 19405 AUTOREFRESH 4L 5C 32246P Autorefresh Query Execute duration
for table TESTUSER.READTAB: 60
08:56:57.870 19406 AUTOREFRESH 4L 5C 32246P Autorefresh Query Fetch duration for
table TESTUSER.READTAB: 0
08:56:57.870 19407 AUTOREFRESH 4L 5C 32246P Autorefresh Query Apply duration for
table TESTUSER.READTAB: 0
08:56:57.870 19408 AUTOREFRESH 4L 5C 32246P Max logseq applied for table
TESTUSER.READTAB: 8
08:56:57.870 19409 AUTOREFRESH 4L 5C 32246P Autorefresh Query Execute duration
for 7 child(ren) table(s): 32
08:56:57.870 19410 AUTOREFRESH 4L 5C 32246P Autorefresh Query Fetch duration for
7 child(ren) table(s): 0
08:56:57.870 19411 AUTOREFRESH 4L 5C 32246P Autorefresh Query Apply duration for
7 child(ren) table(s): 0
08:56:57.870 19412 AUTOREFRESH 3L 5C  32246P Incremental autorefresh ended for
table TESTUSER.READTAB
08:56:57.872 19413 AUTOREFRESH 2L 5C 32246P Duration For Cache Group
TESTUSER.READCACHE: 1020
08:56:57.872 19414 AUTOREFRESH 2L 5C 32246P Num Rows For Cache Group
TESTUSER.READCACHE: 1
08:56:57.872 19415 AUTOREFRESH 2L 5C 32246P Num Root Rows For Cache Group
TESTUSER.READCACHE: 0
08:56:57.872 19416 AUTOREFRESH 2L 5C 32246P Cumulative Rows for Cache Group
TESTUSER.READCACHE: 11776
08:56:57.872 19417 AUTOREFRESH 2L 5C 32246P Cumulative Root Rows for Cache Group
TESTUSER.READCACHE: 1697
08:56:57.872 19418 AUTOREFRESH 2L 5C 32246P Autorefresh ended for cache group
TESTUSER.READCACHE
08:56:57.883 19419 AUTOREFRESH 1L 5C 32246P Duration For Interval 60000ms: 420
08:56:57.883 19420 AUTOREFRESH 1L 5C 32246P Num Rows For Interval 60000ms: 0
08:56:57.883 19421 AUTOREFRESH 1L 5C 32246P Num Root Rows For Interval
60000ms: 0
08:56:57.883 19422 AUTOREFRESH 1L 5C 32246P Cumulative Rows for Interval
60000ms: 11587
08:56:57.883 19423 AUTOREFRESH 1L 5C 32246P Cumulative Root Rows for Interval
60000ms: 1697
08:56:57.883 19424 AUTOREFRESH 1L 5C 32246P Autorefresh number 1415 ended for
interval 60000ms successfully.
27 records dumped

AUTOREFRESHトレースをデフォルトの設定(0)に戻し、ttTraceMonを終了します。

Trace > level autorefresh 0
Trace > {press ENTER – blank line}

ttXactAdminユーティリティの使用

ttXactAdminユーティリティは、未処理の各トランザクションの所有者、ステータス、ログおよびロックの情報を表示します。このユーティリティを使用して、データベースへの現在のすべての接続を表示することもできます。ttXactAdminユーティリティは、レプリケーション、XLAおよび非同期WRITETHROUGHキャッシュ・グループの問題のトラブルシューティングに役立ちます。

例1-13 ttXactAdminを使用してロック・タイムアウトを診断する

ttXactAdminを使用してロック・タイムアウトを診断します。同じ行を更新しようとしている2つの接続について考えてみます。接続1による次のトランザクションが進行中です。

UPDATE table1 SET c1 = 2 WHERE c1 = 1;

接続2では、次の更新を実行しようとします。

UPDATE table1 SET c1 = 3 WHERE c1 = 1;

接続2は、次のエラーを受信します。

6003: Lock request denied because of time-out
Details: Tran 2.3 (pid 2880) wants Un lock on rowid 0x00156bbc, table
TTUSER.TABLE1.
But tran 1.21 (pid 2564) has it in Xn (request was Xn). Holder SQL
(update table1 set c1 = 2 where c1 = 1;)
The command failed.

エラーの詳細によると、トランザクション1.21では行0x00156bbc(トランザクション2.3が更新する行)がロックされていることがわかります。ttXactAdminによって、データベース全体のアクションに関する出力にこの情報が表示されます。

$ ttXactAdmin myDSN
2011-03-07 12:57:41.237
c:\datastore\myDSN
TimesTen Release 11.2.2.0.0

Outstanding locks

PID   Context   TransID  TransStatus  Resource   ResourceID   Mode Name

Program File Name: ttIsql

2564  0xeeb9a8  1.21     Active       Database   0x01312d00   IX
Row        0x00156bbc   Xn   TTUSER.TABLE1
Table      1910868      IXn  TTUSER.TABLE1

Program File Name: ttIsql

2880  0xeeb9a8  2.3      Active        Database   0x01312d00  IX
Table      1910868     IXn  TTUSER.TABLE1
Command    19972120    S

Awaiting locks

PID  Context   TransID Resource ResourceID  RMode HolderTransID HMode Name
2880 0xeeb9a8  2.3     Row      0x00156bbc  Un    1.21          Xn TTUSER.TABLE1

2 outstanding transactions found

詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttXactAdminに関する項を参照してください。

ODBCトレースの使用

Windowsでは、ODBCトレース機能を使用して、コマンドの順序と内容を確認します。アプリケーションがODBC Driver Managerとリンクされている場合のみODBCトレース機能が動作します。トレースを有効にするには、コントロール・パネルで「ODBC」をダブルクリックします。「ODBC データソース アドミニストレータ」が開きます。「トレース」タブを選択します。

UNIXプラットフォームでは、ドライバ・マネージャを使用している場合にのみODBCトレースを使用できます。Traceを有効にするには、TraceおよびTraceFile属性を設定します。

SNMPトラップによるイベントの検出

ネットワーク管理ソフトウェアは、SNMP(Simple Network Management Protocol)を使用して、ルーターやスイッチなどのネットワーク・デバイスの状態を問合せまたは制御します。これらのデバイスは、トラップと呼ばれるアラートを生成し、ネットワーク管理システムに問題を通知できます。

TimesTenは、ユーザーのリカバリ・メカニズムが簡単になるように、特定の重大なイベントのSNMPトラップを送信します。また、これらのイベントはサポート・ログにも記録されます。このようなイベントをSNMPトラップを通じて公開することで、ネットワーク管理ソフトウェアでの迅速な対処が可能となります。

SNMPトラップを生成するためのTimesTenの構成方法やトラップの受信方法については、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップを使用した診断に関する説明を参照してください。

TimesTen SYSTEM表の監視

各TimesTenデータベースには、データベースの現在の状態に関するメタデータを格納するシステム表のグループが含まれています。TimesTenのシステム表については、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のシステム表に関する説明を参照してください。

注意:
システム表に対してSELECT文は実行できますが、INSERT、UPDATE、DELETEなどの文は実行できません。

システム表SYS.SYSTEMSTATSを使用して、データベース・メトリックを表示します。ttStatsユーティリティを使用すると、データベース・メトリックを監視し、メトリックのスナップショットを取得して比較できます。詳細は、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.SYSTEMSTATSに関する項、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsに関する項および『Oracle TimesTen In-Memory Database PL/SQLパッケージ・リファレンス』のTT_STATSに関する項を参照してください。

SYS.MONITOR表を使用すると、データベースに最初に接続して以来発生した特定のイベントに関する統計を表示できます。たとえば、SYS.MONITOR表には、データベースへの接続数、チェックポイントの処理回数、データベースのサイズおよび現在使用中のメモリー量に関する情報が含まれています。列に対してSELECT文を実行するか、ttIsql monitorコマンドを実行してSYS.MONITOR表の内容を確認します。ttIsql monitorコマンドの使用方法の例については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のttIsqlユーティリティの使用に関する説明を参照してください。

問合せオプティマイザの使用

問合せオプティマイザは、パフォーマンス・チューニングのための重要なツールです。

問合せオプティマイザの詳細は、次を参照してください。

- 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen問合せオプティマイザに関する説明

- 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の問合せオプティマイザ計画の確認と変更に関する説明

特定の問合せ速度が予想より遅い場合は、問合せオプティマイザで、問合せに含まれる表の最新の統計が使用されていることを確認します(「問合せオプティマイザの統計を更新する」を参照)。統計を更新しても問合せ速度が遅い場合は、TimesTenオプティマイザが問合せに応答するための最適な問合せ計画を選択していない可能性があります。このような状況では、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の計画作成の変更に関する項で説明されているttOptプロシージャを使用して、オプティマイザが計画を作成する方法を調整することができます。文レベル・オプティマイザ・ヒントを使用すると、文レベルでオプティマイザに指示できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』の文レベル・オプティマイザ・ヒントに関する項を参照してください。

2 TimesTenアプリケーションおよびデータベースのトラブルシューティング

次の項では、TimesTenデータベースの使用時に発生する問題のいくつかについて、その診断や解決に役立つ情報を説明します。

注意:
この章に示すトラブルシューティングを実行した後もデータベースの問題が解決しない場合は、TimesTenテクニカル・サポートに連絡してください。

- TimesTenデーモンを起動または停止できない

- TimesTenのデーモン、サブデーモンからレスポンスがない

- 共有セグメントを作成できない

- アプリケーションがダイレクト・モードでデータベースに接続できない

- クライアント/サーバーの問題のトラブルシューティング

- アプリケーションでの接続または切断が遅い

- アプリケーションが予期せず切断された

- アプリケーションが遅い

- アプリケーションからのレスポンスがない、ハングしている可能性がある

- 作成済の表がアプリケーションで見つからない

- OCIおよびPro*C/C++アプリケーションのトラブルシューティング

- リソースを使い果たす

- SELECT文の結果が重複する

- PL/SQL共有メモリーをアタッチできない

TimesTenデーモンを起動または停止できない

この項では、TimesTenのメイン・デーモンを起動または停止できないときに確認する事項を説明します。

考えられる原因

対処

権限が不適切である。

TimesTenデーモンを起動または停止するには、ADMIN権限が必要です。デーモンを起動するためにttDaemonAdminユーティリティを使用していることを確認します。ttDaemonAdminの出力には、適切な権限があるかどうかが表示されます。

別のプロセスがTimesTenデーモン・ポートを使用している。

ttVersionユーティリティを使用して、TimesTenデーモンが使用するポート番号を確認します。netstatのようなオペレーティング・システム・コマンドを使用して、別のプロセスがそのポートをリスニングしているかどうかを確認します。競合している場合は、他のプロセスで使用するポート番号を変更するか、またはttmodinstallを使用してTimesTenで使用するポートを変更します。

TimesTenデーモンがすでに稼働している

デーモンを起動するためにttDaemonAdminユーティリティを使用していることを確認します。ttDaemonAdminの出力には、デーモンがすでに稼働しているかどうかが表示されます。

その他の問題がある。

デーモンによって作成されるユーザー・エラー・ログを調べます。詳細は、「TimesTenデーモンによって生成されるログの使用」を参照してください。

TimesTenのデーモン、サブデーモンからレスポンスがない

次の項では、1つ以上のTimesTenプロセスが利用できないように思われる場合の対処方法について説明します。

- TimesTenユーザー・エラー・ログを確認する

- コア・ファイルからスタック・トレースを抽出する

TimesTenユーザー・エラー・ログを確認する

TimesTenサブデーモンが停止したことを示すエラーを受信した場合、「TimesTenデーモンによって生成されるログの使用」に従って、ユーザー・エラー・ログを調べます。

TimesTenデーモンがクラッシュした場合、そのTimesTenデーモンからユーザー・エラー・ログに送信を行うことはできませんが、サブデーモンでは、メイン・デーモンがクラッシュしたことを示すメッセージをログに送信してから終了します。

09:24:13 Err : 4375 ------------------: Main daemon has vanished

デーモンを再起動します。次に各データベースに接続すると、TimesTenはチェックポイントおよびトランザクション・ログ・ファイルからリカバリを実行します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen Data Managerデーモンの処理に関する項を参照してください。

コア・ファイルからスタック・トレースを抽出する

UNIXシステムでいずれかのTimesTenプロセスによってクラッシュが発生し、すべての診断方法を試しても問題が解決しない場合は、TimesTenがコア・ファイルを生成していないかを確認します。ttVersionユーティリティを使用してコア・ファイルを検索します。出力でデーモン・ホーム・ディレクトリのパスを示す行を検索します。

TimesTen Release (ttuser:40732)
2011-04-04T17:53:04Z
Instance admin: ttuser
Instance home directory:
/node1/ttuser/ttcur/TTBuild/linux86_dbg/install
Daemon home directory:
/node1/ttuser/ttcur/TTBuild/linux86_dbg/install/info

コア・ファイルが見つかった場合は、システムのデバッガにアタッチし、コア・ファイルからスタック・トレースを抽出して、その結果をTimesTenテクニカル・サポートに送付します。

Windowsシステムの場合は、「サービス」メニューでTimesTen Data Managerのプロパティ・ダイアログの「デスクトップとの対話をサービスに許可」オプションを有効にすることで、サービス障害の診断情報を入手できます。TimesTen Data Managerサービスで回復不能な障害が発生すると、デバッガを起動するかどうかを尋ねるポップアップが表示されます。TimesTenテクニカル・サポートにスタック・トレースを送付してください。

共有セグメントを作成できない

共有セグメントを作成できなかったことを示すエラーを受信する場合があります。

4671: TT14000: TimesTen daemon internal error: Error 28 creating shared segment,
KEY 0x0201f7eb
4671:  -- OS reports too many shared segments in use
4671:  -- Confirm using 'ipcs' and take appropriate action
4671: 18538 ------------------: subdaemon process exited

Linuxのipcsコマンドを使用すると、次のような情報が表示される場合があります。

------ Shared Memory Segments --------
key        shmid      owner     perms      bytes      nattch     status
0x00000000 1098350592 user1     777        10624      2          dest
0x00000000 1084817409 user1     777        2439680    2          dest
0x911fc211 1098383362 user2     666        67108864   1
0x2814afba 170721285  root      666        1048576    1

ステータスに表示されたdestは、メモリー・セグメントが壊れていることを示しています。また、nattchは、メモリー・セグメントにアタッチされているプロセス数を示します。ipcrmコマンドは、プロセスがセグメントからデタッチするか終了するまで、共有メモリーを解放できません。アプリケーションがTimesTenに接続後、無効になる場合、ユーザーがアプリケーションを終了するか停止するまで、共有メモリーは解放されません。

アプリケーションがダイレクト・モードでデータベースに接続できない

この項では、アプリケーションがダイレクト・モードでデータベースに接続できない場合に確認する事項を説明します。

考えられる原因

参照先

TimesTenのリリースとデータベースが一致していない。

「データベースのアップグレード」

ユーザーが、CREATE SESSION権限を持っていない。

「データベースに接続する権限」

ファイル権限が正しくない。

「データベースにアクセスするファイル・システム権限を確認する」

TimesTenデーモンまたはData Managerサービスが稼働していない。

「TimesTenデーモンが稼働していることを確認する」

互換性のない接続属性またはデータベースの不正なパス名がDSNに設定されている。

「DSN定義を確認する」

共有メモリー・セグメントが使用できない、または共有メモリー・セグメントの最大サイズが小さすぎる。

「セマフォおよび共有メモリー・セグメントを管理する」

スワップ領域が不十分である。

「使用可能なスワップ領域(仮想メモリー)を確認する」

ファイル記述子の数が不適切である。

「使用可能なファイル・ディスクリプタの数を増やす」

その他の考えられる原因。

「TimesTenデーモンによって生成されるログの使用」

データベースのアップグレード

データベースの作成に使用したTimesTenのマイナー・リリースのみが、そのデータベースへのアクセスを保証されます。TimesTenソフトウェアをアップグレードし、その新しいリリースを使用して、作成済のデータベースにアクセスする場合は、新しいリリースでデータベースを作成します。その後、ttMigrateユーティリティを使用して、古いデータベースから新しいデータベースに表、索引および表データをコピーします。

詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のTimesTenのアップグレードに関する説明を参照してください。

データベースに接続する権限

ユーザーは、データベースに接続するには、CREATE SESSION権限を持っている必要があります。アクセス権がない場合は、管理者から、GRANT文を使用してCREATE SESSION権限を付与される必要があります。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースに接続する権限の付与に関する説明を参照してください。

データベースにアクセスするファイル・システム権限を確認する

データベースに接続しようとした場合に、チェックポイントまたはトランザクション・ログ・ファイル、あるいはそれらのファイルがあるディレクトリへの適切なアクセス権がないと、権限が拒否されたことを示すエラーが生成されます。DSNのDataStore属性に指定されているディレクトリに格納されているファイルに対するファイル・システム権限を確認します。

TimesTenデーモンが稼働していることを確認する

TimesTenデーモンまたはData Managerサービスが稼働していないときにデータベースに接続しようとすると、TimesTenエラー799「Unable to connect to daemon; check daemon status」が生成されます。

「TimesTenユーザー・エラー・ログを確認する」を参照し、ttStatusユーティリティを使用して、TimesTenデーモンのステータスを確認します。

DSN定義を確認する

DSNを記述する際は、次のことを行ってください。

- DSN属性を確認する

- データベースのパス名とトランザクション・ログ・ディレクトリを確認する

DSN属性を確認する

特定の接続オプションまたはDSN属性の設定の組合せに互換性がありません。互換性のない設定を使用してデータベースに接続しようとすると、アプリケーションにエラーが返されます。

データベースのパス名とトランザクション・ログ・ディレクトリを確認する

DSNのDataStoreおよびLogDir属性に正しいパス名が指定されていることを確認します。また、パス名は相対パス名ではなく、絶対パス名であることも確認します。絶対パス名を指定しないと、パス名は、アプリケーションが起動されたディレクトリに対する相対パスになります。

Windowsの場合、ODBCデータソース・アドミニストレータのユーザーDSNとシステムDSNを区別するよう注意してください。ユーザーDSNは、それを定義したユーザーにしか表示されないため作成しないでください。システムDSNはすべてのユーザーに表示されます。特に、Windowsサービスとして、TimesTenアプリケーションを実行する場合、デフォルトでは、ユーザーSYSTEMとして実行されるため、ユーザーDSNは表示されません。データベースのパス名に、マップされたドライブを使用していないことを確認してください。

セマフォおよび共有メモリー・セグメントを管理する

接続または作成しようとする共有データベースのサイズが、システムに構成された共有メモリー・セグメントの最大サイズより大きいと、エラーが返されます。また、システムが共有メモリー・セグメントをそれ以上割り当てることができない場合もエラーが返されます。

UNIXシステムでは、次のようなコマンドを使用します。

- ipcs -maを使用すると、Oracle Databaseインスタンスやその他のTimesTenインスタンスなど、メモリーを使い果たすその他の共有メモリー・セグメントがないかどうかを確認できます。

- ipcrmを使用すると、メッセージ・キュー、セマフォ・セットまたは共有メモリー・セグメント識別子を削除できます。障害の発生したTimesTenの停止、インスタンスのクラッシュ、デーモンのクラッシュなどの共有メモリー・セグメントおよびセマフォを使用するアプリケーションの問題の後で、ipcrmを使用して、セマフォまたは共有メモリー・セグメントをクリーンアップします。共有メモリー・セグメントを削除するには、-mを使用します。セマフォを削除するには、-sを使用します。

- ps -eaflを使用すると、実行中のプロセスによって使用されているメモリーの量を確認できます。

- ulimit -aを使用すると、1つのプロセスが処理できるメモリーの最大量、最大ファイル・サイズ、オープン・ファイルの最大数に制限がないかどうかを確認できます。

共有メモリー・セグメントは使用可能であるが、小さすぎてデータベースを保持できない場合は、ttSizeユーティリティを使用して、表に必要なメモリー量を見積もり、PermSizeおよびTempSize属性の値を確認して、データベース用に設定されているメモリー量を検証します。永続メモリー領域と一時メモリー領域のサイズを設定するためのガイドラインについては、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のPermSizeおよびTempSize属性の監視に関する説明を参照してください。データベースに対して設定されているメモリー量が多すぎる場合は、PermSizeおよびTempSizeの値を小さくします。詳細は、「データベースに割り当てられたメモリーの量を確認する」を参照してください。共有メモリー・セグメントのサイズを大きくするその他のオプションについては、次の説明を参照してください。

アプリケーションが接続されていて、システム障害またはアプリケーション障害が原因でデータベースが無効になると、データベース共有セグメントがアプリケーションから自動的にデタッチされません。次にアプリケーションがデータベースの使用を試みると、アプリケーションはデータベースから切断され、共有セグメントがデタッチされます。アプリケーションが無効化されたデータベースへの接続を継続し、データベースの使用を試みない場合、アプリケーションはデータベースから切断されず、共有セグメントがデタッチされません。メモリーおよびスワップ領域を解放するためには、無効化されたデータベースに接続されているすべてのアプリケーションを切断または終了する必要があります。

データベースがシステムまたはアプリケーションの障害で無効化され、すべてのアプリケーションをデータベースから切断した場合、次に続するとデータベースはリカバリします。データベース領域を使い果たしたためにリカバリが失敗した場合は、PermSizeおよびTempSizeの値を現在の値より大きくして、データベースに再接続します。

TimesTenの共有メモリーを構成する方法の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のインストールの前提条件に関する説明を参照してください。

使用可能なスワップ領域(仮想メモリー)を確認する

共有メモリーをバックアップするのに十分なスワップ領域が必要です。

UNIXシステムの場合は、swapコマンドを使用して仮想メモリーを確認し、システムに追加できます。

Windowsシステムの場合は、「Computer Management Properties」ダイアログ・ウィンドウの「Advanced」タブで、仮想メモリーのサイズを確認し、再設定できます。

使用可能なファイル記述子の数を増やす

TimesTenデータベースに接続されている各プロセスは、1つ以上のオペレーティング・システム・ファイル記述子をオープンしたままにします。チェックポイントが実行される場合、およびトランザクションがコミットまたはロールバックされる場合は、各接続に対してさらにファイル・ディスクリプタをオープンすることができます。データベースに接続しようとしたときに、ファイル記述子がすべて使用中であるというエラーを受信した場合は、ファイル記述子の許容数を増やします。ファイル記述子の制限およびファイル記述子の数の変更については、オペレーティング・システムのドキュメントを参照してください。

「クライアント/サーバーの問題のトラブルシューティング」を参照

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

- TimesTen Serverに接続できない

- TimesTen Serverで障害が発生した

- Server DSNが見つからない

- TimesTen ServerがDRIVERのロードに失敗した

- TimesTen Serverへのアクセス時にアプリケーションのタイムアウトが発生した

- TimesTen ClientがTimesTen Serverとの接続を失った

- IPC用の共有メモリー・セグメントとの接続に失敗した

- Windows XPでのサーバーの最大接続数の増加

- 複数のクライアント接続の使用時にスレッド・スタックのオーバーフローが発生した

- DSNによる新しいデータベースの指定で領域が不足する

- 「アプリケーションがダイレクト・モードでデータベースに接続できない」の項に記載のトピックについても検討してください。

TimesTen Serverに接続できない

TimesTen Serverが稼働しているシステムが正しく識別されていません。

Windowsクライアントでは、ODBCデータソース・アドミニストレータの一部として表示される「TimesTen Data Source Setup」ダイアログ・ボックスで「TimesTen Server」を選択します。TimesTen Serverを検証するには、次の手順を実行します。

1. Windowsデスクトップで、「スタート」→「設定」→「コントロール パネル」を選択します。

2. 「ODBC」アイコンをクリックします。「ODBC データソース アドミニストレータ」が開きます。

3. 「システム DSN」タブをクリックします。「システム データソース」リストが表示されます。

4. 「TimesTen Client data source」を選択します。「TimesTen Client DSN Setup」ダイアログ・ボックスが開きます。

5. 「Servers」をクリックします。「TimesTen Logical Server List」が開きます。

6. リストから「TimesTen Server」を選択します。「TimesTen Logical Server Name Setup」ダイアログ・ボックスが開きます。

7. 「Network Address」および「Port Number」の値が正しいことを確認します。必要に応じて値を変更します。

注意:
「TimesTen Client DSN Setup」の「Server Name」フィールドにホスト名またはネットワーク・アドレスを直接入力すると、クライアントは、デフォルトのポートを使用してTimesTen Serverへの接続を試行します。

「Network Address」および「Port Number」の値が正しい場合、TimesTen Serverが稼働していない可能性があります。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』で、サーバーを手動で起動する詳細は、WindowsでのOracle TimesTen Data Managerサービスの起動および停止に関する項を、この問題を特定する方法の詳細は、接続のテストに関する項を参照してください。

UNIXの場合、クライアント上のodbc.iniファイルのTTC_Server接続属性でTimesTen Serverを指定します。TTC_Serverに指定する値が実際のホスト名またはIPアドレスの場合、クライアントは、デフォルトのポートを使用してTimesTen Serverに接続を試行します。TimesTenでは、デフォルトのポートはTimesTenのリリース番号と関連付けられています。TTC_Serverに指定する値が論理サーバー名の場合、この論理サーバー名をttconnect.iniファイル内で定義する必要があります。このサーバー名をttconnect.iniファイルで定義する場合は、ホスト名、IPアドレス、およびTimesTen Serverがリスニングを行っているポート番号を正しく指定する必要があります。

「Network Address」および「Port Number」の値が正しい場合、TimesTen Serverが稼働していない可能性があります。サーバーを手動で起動する方法の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のUNIXでのデーモンの起動および停止に関する説明を参照してください。この問題の識別方法の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の接続のテストに関する説明を参照してください。

TimesTen Serverで障害が発生した

サーバーのログ・ファイルを確認します。サーバー・ログ・メッセージはttendaemon.optionsファイル内の-userlogおよび-supportlogオプションで指定したファイルに保存されています。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のUNIX上でのクライアントDSNの作成および構成に関する説明およびTimesTenデーモン・オプションの管理に関する説明を参照してください。

特定のTimesTenインスタンスのサーバーに対する同時IPC接続の最大数は24,999です。ただし、単一のDSNへの接続数(直接またはクライアント/サーバー)は2043に制限されます。

クライアント/サーバーのユーザーは、ファイル記述子の制限を変更してより多くの接続数に対応できます。例については、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のインストールの前提条件に関する説明を参照してください。

Server DSNが見つからない

UNIXの場合、TimesTen Serverが稼働しているシステム上のsys.odbc.iniファイルでサーバーDSNが正しく定義されていることを確認します。

Windowsの場合、TimesTen Serverが稼働しているシステムのODBCデータソース・アドミニストレータでサーバーDSNがシステムDSNとして定義されていることを確認します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のWindows上での論理サーバー名の作成および構成に関する説明を参照してください。

TimesTen ServerがDRIVERのロードに失敗した

このエラーは、UNIXプラットフォームでのみ発生します。TimesTen Serverが稼働しているシステムでsys.odbc.iniファイルを開き、接続しようとしているサーバーDSNの場所を確認します。サーバーDSNのDRIVER属性に指定した動的ライブラリが存在し、実行可能であることを確認します。

TimesTen Serverへのアクセス時にアプリケーションのタイムアウトが発生した

デフォルトのタイムアウト時間は、60秒です。

UNIXでタイムアウト時間を長くするには、odbc.iniファイルのTTC_Timeout属性の値を変更します。

Windowsでタイムアウト間隔を設定するには、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のタイムアウト間隔および認証の設定に関する説明の手順を参照してください。

TimesTen ClientがTimesTen Serverとの接続を失った

エラーの原因がクライアントのタイムアウトかどうかを確認します。TimesTen Serverのログを確認して、サーバーがクライアントとの接続を切断した原因を調べます。pingを使用してネットワークが機能しているかどうかを確認するか、またはtelnetを使用してTimesTen Serverのポート番号に接続を試行します。

IPC用の共有メモリー・セグメントとの接続に失敗した

共有メモリー・セグメント(SHM)をIPCとして使用している際に、TimesTen Client ODBCドライバからの次のエラー・メッセージがアプリケーションに表示される場合があります(アプリケーションがシステムに定義されているプロセス当たりのファイル記述子の制限に達した場合)。

SQLState    = S1000,
Native Error = 0,
Message     = [TimesTen][TimesTen 11.2.2 CLIENT]Failed to attach to shared memory
segment for IPC. System error: 24

これは、クライアントDSNへの接続処理中、システムに定義されているプロセス当たりのファイル記述子の制限を超えるオープン・ファイル記述子がアプリケーションに含まれていることが原因でshmatシステム・コールが失敗した場合に発生する可能性があります。この問題を修正するには、プロセス当たりのファイル記述子の制限を増加する必要があります。ファイル記述子の制限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のシステムの制限に関する説明を参照してください。

Windows XPでのサーバーの最大接続数の増加

Windows XPのデフォルトの設定では、約47の子サーバー・プロセスを使用できます。接続数を増やすには、ttendaemon.optionsファイルまたはDSNのMaxConnsPerServer接続属性を設定します。これによって接続数は、MaxConnsPerServerの値の47倍になります。

複数のクライアント接続の使用時にスレッド・スタックのオーバーフローが発生した

Solarisでは、スレッド・スタックのオーバーフローに関するメッセージが、ユーザー・エラー・ログに表示される場合があります。その他のプラットフォームでは、スレッド・スタックのオーバーフローの可能性を示すセグメンテーション障害についてのメッセージが表示される場合があります。

これらのメッセージが表示された場合は、次のいずれかの方法で、サーバー・スタックのサイズを大きくします。

- ttendaemon.optionsファイルの-ServerStackSizeオプションを指定します。ttendaemon.optionsファイルは、TimesTenインスタンスのすべてのDSNに適用されます。

- 特定のDSNのServerStackSize接続属性を指定します。この設定は、ttendaemon.optionsファイルの値より優先されます。

サーバー・スタックのサイズを大きくすると、スワップ領域を使い果たす前に確立可能な同時接続数が減ります。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen ClientおよびTimesTen Serverの使用に関する項を参照してください。

DSNによる新しいデータベースの指定で領域が不足する

複数のクライアント接続を持つシステムでは、DSNを変更して新しいデータベースを指定する際に、元のデータベースへの接続が確立されたままの場合に、領域不足であることを示すメッセージが表示されることがあります。この問題は、32-bitプラットフォームでいずれかのデータベースが約2GBの場合に発生する可能性があります。

元のデータベースへのすべての接続をクローズします。これにより、現在DSNで指定されているデータベースへの接続に対し、新しいサーバー・プロセスが作成されます。ttStatusユーティリティを使用すると、古いデータベースへの接続を表示できます。または、-restartServerオプションを指定してttDaemonAdminユーティリティを使用すると、サーバーを再起動して、インスタンス内のすべてのDSNですべてのクライアント接続をリセットできます。

アプリケーションでの接続または切断が遅い

この項では、データベースとの接続や切断に時間がかかるときに確認する事項を説明します。まず、ramPolicy設定を確認します。ramPolicy設定がinUseで、他にユーザーがいない場合、最初の接続で、データベース全体がメモリーにロードされます。ramPolicyを、alwaysまたはmanualのいずれかに変更してください。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する項を参照してください。

考えられる原因

参照先

データベースがリカバリ中である

後述の「データベースがリカバリ中であるかどうかを確認する」

ODBCトレースが有効になっている

後述の「ODBCトレースの確認」

その他の考えられる原因。

「APIトレース」

データベースがリカバリ中であるかどうかを確認する

接続に時間がかかるということは、TimesTenデータベースがリカバリ中であることを示している可能性があります。これは初期接続時にのみ発生します。

ODBCトレースを確認する

Windowsプラットフォームでは、ODBCトレースが有効になっていると、接続および切断の処理速度が遅くなる可能性があります。コントロール・パネルの「ODBC」をダブルクリックして、ODBCデータソース・アドミニストレータを開きます。「トレース」タブを選択して、トレースが無効になっていることを確認します。「ODBCトレースの使用」を参照してください。

アプリケーションが予期せず切断された

アプリケーションがTimesTenデータベースから切断される場合は、次のイベントのいずれかが発生します。

- 未解決のトランザクションがなかった場合、その接続はTimesTenデーモンによって完全に削除されます。その他の既存の接続は、問題が発生しなかったように、処理を継続します。

- 未解決のトランザクションがある場合、トランザクションはロールバックされ、接続はTimesTenデーモンによって完全に削除されます。その他の既存の接続は、問題が発生しなかったように、処理を継続します。

この項では、アプリケーションがデータベースとの接続を予期せず切断したときに確認する事項を説明します。

考えられる原因

参照先

内部アプリケーション・エラーが発生した。

後述の「ODBC、JDBC、OCI、Pro*CおよびPL/SQLアプリケーション・エラーの確認」

アプリケーションの同時処理スレッドで障害が発生した。

後述の「ODBC、JDBC、OCI、Pro*CおよびPL/SQLアプリケーション・エラーの確認」
「ユーザー・エラー・ログを確認する」

クライアント/サーバー接続を使用している場合に、クライアントがアプリケーションから切断された

「クライアント/サーバーの問題のトラブルシューティング」

TimesTenライブラリでエラーが発生した。

TimesTenサポート・サービスに連絡してください。

ODBC、JDBC、OCI、Pro*CおよびPL/SQLアプリケーション・エラーの確認

次のタイプのエラーを確認します。

- SQLErrorファンクションによって返されるODBCエラー

- SQLExceptionクラスによって返されるJDBCエラー

TimesTen OCIおよびPro*Cアプリケーションと、PL/SQLを使用するアプリケーションでは、TimesTenエラー・コードではなくOracle Databaseエラー・コードを使用してエラーがレポートされます。エラー・コードに付随するエラー・メッセージは、TimesTenエラー・カタログから取得される場合とOracle Databaseエラー・カタログから取得される場合があります。

デフォルトで、TimesTenメッセージおよび診断情報は、次のように格納されます。

- エラー・メッセージ情報を含むユーザー・エラー・ログ。通常、これらのメッセージには、必要な処置に関する情報が含まれています。デフォルトのファイルはdaemon_home/tterrors.logです。ユーザー・エラー・ログの場所の変更の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の情報メッセージの変更に関する項を参照してください。

- ユーザー・エラー・ログ内のすべての情報に加えて、TimesTenテクニカル・サポートが使用する情報を含むサポート・ログ。デフォルトのファイルはdaemon_home/ttmesg.logです。ユーザー・エラー・ログの場所の変更の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の情報メッセージの変更に関する項を参照してください。

- TimesTenがデータベースを無効化した場合の無効化ファイルの診断情報。このファイルには、TimesTenテクニカル・サポートで役に立つトラブルシューティング情報が含まれます。無効化ファイルは、DataStore接続属性により指定される値に基づいて作成され、名づけられます。接続属性はファイル名ではありません。たとえば、Linuxプラットフォームでは、DataStore接続属性が/home/ttuser/AdminDataの場合、実際の無効化ファイル名には、接尾辞.inval, /home/ttuser/AdminData.invalが付きます。DataStore接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のDataStoreに関する項を参照してください。

ttTraceMonを使用してアプリケーションでレベル4のERRトレースを生成し、TimesTenダイレクト・ドライバにプッシュされたすべてのエラー・メッセージを確認することも有効な場合があります。詳細は、「ERRトレース」を参照してください。

ユーザー・エラー・ログを確認する

TimesTenアプリケーションがODBCエラーまたは他の警告を返さずに切断された場合は、ユーザー・エラー・ログを調べます。詳細は、「TimesTenデーモンによって生成されるログの使用」を参照してください。

アプリケーションが遅い

アプリケーションとTimesTenデータベースのパフォーマンスを最大にする方法については、次を参照してください。

- 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenのデータベースのパフォーマンス・チューニングに関する説明

- 『Oracle TimesTen In-Memory Database C開発者ガイド』のODBCアプリケーションのチューニングに関する項

- 『Oracle TimesTen In-Memory Database Java開発者ガイド』のJavaアプリケーションのチューニングに関する項

この項では、パフォーマンスを低下させるいくつかの問題について説明します。

考えられる原因

参照先

クライアント/サーバー・モードを使用している。

「接続モードを検討する」

データベース統計が古い。

「表の統計を更新する」

トランザクションのコミットの頻度が高すぎる。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の自動コミット・モードの無効化に関する説明

DurableCommits属性が有効化されている。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の永続コミットの適切な使用に関する説明

複数回使用するSQL文を準備していない。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の文の事前準備に関する説明

索引の種類が間違っている、索引が多すぎる、ハッシュ索引のサイズが間違っている。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のハッシュ索引、範囲索引またはビットマップ索引の適切な選択に関する説明
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のハッシュ索引の適切なサイズ設定に関する説明

ロックの使用方法が効率的でない。

「ロック・レベルと分離レベルを検証する」

マテリアライズド・ビューが適切に構成されていない。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のマテリアライズド・ビューにおけるパフォーマンスの影響およびマテリアライズド・ビューのチューニングに関する説明

レプリケーションを使用している場合は、レプリケーション・スキームの構成またはネットワーク環境がアプリケーションに影響を与えている可能性がある

「レプリケーションまたはXLAのパフォーマンスが悪い」

TimesTen Cacheを使用している場合は、TimesTen Cacheの構成または環境がアプリケーションに影響を与えている可能性がある。

「自動リフレッシュのパフォーマンスが悪い」

表のパーティションが多すぎる。

「表のパーティション数を確認する」

1つ以上のTimesTenコンポーネントに対してトレースが不必要に有効になっている

「トレースの設定を確認する」

接続モードを検討する

クライアント/サーバー接続は、TimesTenデータベースへの直接接続よりも遅くなります。また、ドライバ・マネージャ接続でも、パフォーマンスに影響を与えます。クライアント/サーバー接続の場合は、データベースとのすべての通信にネットワーク待機時間を伴うため、かなりのパフォーマンスのオーバーヘッドが発生する可能性があります。

アプリケーションを、データベースをホストしているシステムとは別のマシンで実行する必要がある場合は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のクライアント/サーバーのチューニングに関する説明を参照してください。

表の統計を更新する

通常、TimesTen問合せオプティマイザは、最も効率的な問合せ計画の選択に優れています。ただし、最適な計画を選択するためには、複雑な問合せに関連する表の情報が必要になります。表の行数と列値のデータ分布を把握することにより、オプティマイザは、その表にアクセスするための効率的な問合せ計画を選択できるようになります。

TimesTen表にアクセスする問合せを準備する前に、ttOptUpdateStatsプロシージャを使用して、その表の統計を更新できます。表の統計を更新する場合は、表にデータをロードしてから問合せを準備するまでの間に統計を更新すると、最高の結果が得られます。たとえば、データを移入する前に表の統計を更新すると、表に行がない(または少数の行しかない)ものとして、問合せが最適化されます。その後、数百万行のデータを表に移入してから問合せを実行すると、表にほとんど行がない状況で適切に動作した計画は非常に遅くなります。

統計の更新の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenの問合せオプティマイザに関する説明を参照してください。

ロック・レベルと分離レベルを検証する

複数のアプリケーションがどのようにデータベースに同時アクセスするかで、パフォーマンスが大きく影響を受けることがあります。

アプリケーションは、データベース全体、個々の表および個々の行に対してロックを取得できます。それとは別に、トランザクションがコミットまたはロールバックするまで読取りロックや更新ロックを保持するかどうかを決定する分離レベルも設定できます。

SYS.SYSTEMSTATS表、SYS.MONITOR表を確認するか、またはttXactAdminユーティリティを使用して、アプリケーションがロックの待機に時間を費やしているかどうかを検出できます。詳細は、「デッドロックとタイムアウトを確認する」および「ttXactAdminユーティリティの使用」を参照してください。

ロックの競合が激しい場合は、次のように実装することによって、システム全体のパフォーマンスを改善できる場合があります。

- LockLevel構成属性を設定するか、ttLockLevelプロシージャを使用して、データベース全体ではなく、行をロックします。行ロックはデフォルトです。

- ttOptSetFlagプロシージャを使用して、問合せオプティマイザが表にロックをかけないようにします。特に多くの表に影響を与える更新の場合などで、表ロックはデフォルトになっている場合があります。

- トランザクション・データへのシリアライズ可能アクセスを必要としないアプリケーションに対しては、コミット読取り分離レベル(デフォルトは、Isolation=1)を使用します。

ロックの競合を最小になるように前述のとおり設定しても、多数の競合が発生する場合は、競合がアプリケーション自体に関係している可能性もあります。たとえば、同時実行のスレッドが、繰り返し同じ行にアクセスしているような場合です。このような競合の検出には、ttXactAdminユーティリティが役立つことがあります。また、このような状況では、トレースが有効なこともあります。

ロックおよび分離レベルの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の分離およびロックによる並行性制御に関する説明を参照してください。

トレースの設定を確認する

ttTraceMon -e show(「ttTraceMonユーティリティの使用」を参照)を使用して、すべてのTimesTenコンポーネントに対してトレースが無効(OFF)になっていることを確認します。ERRは1に設定され、他のすべてのコンポーネントは0に設定されている必要があります。データベースが再ロードされてもトレース・レベルは保持されます。

Windowsの場合、ODBCトレースが無効になっていることを確認します。コントロール・パネルの「ODBC」をダブルクリックして、ODBCデータソース・アドミニストレータを開きます。「トレース」タブを選択して、トレースが無効になっていることを確認します。「ODBCトレースの使用」を参照してください。

表のパーティション数を確認する

表の作成時、パーティションは1つです。ALTER TABLE ... ADD COLUMNを使用して新しい列を追加すると、新しいパーティションが表に追加されます。1回のALTER TABLE ... ADD COLUMN文で複数の列を追加した場合、追加されるパーティションは1つのみです。

表当たりのパーティション数の制限は999です。この数を超えるとエラー8204が生成されます。新しいパーティションそれぞれに対して追加の読取りが行われるため、新しいパーティションのパフォーマンスがそれぞれ少し低下します。パーティション数は多くしないようにする必要があります。複数のパーティションを持つレプリケートされた表では、サブスクライバ側で更新を行うたびにパーティション数に比例して追加の領域が使用されます。このため、サブスクライバではマスターより少し多くの永続領域が使用される場合があります。

各表のパーティション値は、システム表SYS.TABLESの列SYS16で追跡されます。表のパーティション数は、次の問合せで取得します。

SELECT tblname, sys16 FROM SYS.TABLES;

表に含まれるパーティションが多すぎることが検出された場合は、次のいずれかを行います。

- 表の再作成。

- 表の保存およびリストア。ttMigrate -cを使用して、移行ファイルを作成します。その後、ttMigrate -r -relaxedUpgradeを使用して、パーティションを追加せずに表をリストアします。

ALTER TABLE ... DROP COLUMNでは、表からパーティションは削除されません。レプリケートされたシステムでは、-relaxedUpgradeオプションを使用してすべてのマスター・データベースおよびサブスクライバ・データベースを移行する必要があります。異なるパーティション構造の表では、レプリケーションは発生しません。

アプリケーションからのレスポンスがない、ハングしている可能性がある

この項では、アプリケーションからのレスポンスがなく、ハングしている可能性があるときに確認する事項を説明します。まず、pstackまたは同等のものを使用して、アプリケーションが時間を費やす場所を決定します。

考えられる原因

参照先

内部アプリケーション・エラーが発生した。

後述の「ODBCエラーの確認」

DSNに設定した接続属性が一貫していない。

「接続モードを検討する」

ロックの競合が過剰である。

後述の「デッドロックとタイムアウトを確認する」

その他の考えられる原因については、次の項、「ログの確認とトレース情報の収集」を参照してください。

ログを確認し、トレース情報を収集する

アプリケーションがハングした場合、ttXactAdminユーティリティを使用してトランザクション・ログを確認します。詳細は、「ttXactAdminユーティリティの使用」を参照してください。

また、エラーのユーザー・エラー・ログ(「TimesTenデーモンによって生成されたログの使用」を参照)を確認します。

また、「ttTraceMonユーティリティの使用」を参照して、トレース・ログを生成して、様々なTimesTenコンポーネントのアクティビティを検出することもできます。

ODBCエラーを確認する

すべてのアプリケーションで、SQLErrorファンクションが返したODBCエラーを確認し、それらのいずれかでハングの原因となる問題が発生していないかどうかを確認します。ODBCをコールした後に必ずSQLErrorをコールして、エラーまたは警告が初めて発生したときの状態を特定します。SQLErrorの使用方法の例については、デモ・プログラム、および『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』ののエラーおよび警告の取得に関する項を参照してください。

問題が再現可能な場合は、ttTraceMonを使用してSQLをトレースを生成し、アプリケーションがハングしている箇所を特定します。詳細は、「SQLトレース」を参照してください。さらに極端な場合は、アプリケーションに対して、レベル4のERRトレースを生成し、TimesTenダイレクト・ドライバにプッシュされたすべてのエラー・メッセージを確認します。詳細は、「ERRトレース」を参照してください。

デッドロックとタイムアウトを確認する

接続の問題がない場合、デッドロックまたはタイムアウトが問題である可能性もあります。デッドロックとタイムアウトに関する情報は、SYS.SYSTEMSTATS表およびSYS.MONITOR表に記録されます。この表の内容については、「TimesTen SYSTEM表の監視」を参照してください。また、ttXactAdminユーティリティを使用して、コミットされていないトランザクションが現在保持しているロックのタイプと、ロックが保持されているリソースを検出することもできます。

デッドロックが発生すると、TimesTenサブデーモンは、デッドロックに関係するアプリケーションにTimesTenエラー6002「Lock request denied because of deadlock」を生成させて問題を排除します。エラー・メッセージには、ロック・ホルダーが実行しているSQLが含まれるため、デッドロックの原因の診断に役立つ可能性があります。アプリケーションでこのエラーが発生した場合は、トランザクションをロールバックしてから、そのトランザクションに文を再発行する必要があります。デッドロックは、アプリケーションが巡回待機に陥る特定の順序で文を発行した場合に発生する可能性があり、これは、文の発行順序を変更することで回避できることがあります。

DSNのLockWait属性またはアプリケーションのttLockWaitプロシージャで設定したロック・タイムアウト時間によって定義される時間内にロックを取得できないと、アプリケーションでTimesTenエラー6003「Lock request denied because of time-out」が発生します。タイムアウト・エラーの発生時に、アプリケーションは文を再発行する可能性があります。トランザクションを短くすると、ロック・タイムアウト・エラーが発生する可能性は低くなります。

マルチ・スレッド・アプリケーションでは、同じデータベースへの様々な接続ハンドルにリクエストを発行するスレッドで、それ自身とのロック競合が発生する可能性があります。TimesTenでは、ロック・タイムアウトを使用してこれらの競合を解消します。

作成済の表がアプリケーションで見つからない

この項では、データベースに作成済の表、索引、順序、ビューがアプリケーションで見つからないときに確認する事項を説明します。

考えられる原因

参照先

データベースが一時的である

後述の「Temporary DSN属性を確認する」

Overwrite属性が有効になっている

後述の「Overwrite DSN属性を確認する」

DSNに指定したパス名が相対的である

後述の「データベースへのパス名を確認する」

Temporary DSN属性を確認する

一時データベース(DSN属性: Temporary=1)は、データベースとの接続がすべて削除されるまで存続します。一時データベースの表にアクセスしようとしたときに、その表が存在しない場合、その表が存在したデータベースは削除されてしまっている可能性があります。

Overwrite DSN属性を確認する

DSN属性のOverwriteおよびAutoCreateが有効な場合にすでにデータベースが存在していると、TimesTenはそのデータベースを削除して、新しいデータベースを作成します。古いデータベースで作成された表は削除されます。

データベースへのパス名を確認する

特定のDSNに接続する場合に、常に同じデータベースにアクセスするようにするには、データベースの相対パス名ではなく、絶対パス名を使用します。たとえば、demoデータベースがdatastoreディレクトリにある場合は、次のように指定します。

DataStore=/datastore/demo

次のようには指定しません。

DataStore=demo

後者の場合、データベースのパス名は、アプリケーションが起動されたディレクトリに対する相対パス名です。表を検索できず、またデータベースの相対パス名を使用している場合は、その表が存在するデータベースは存在せず、データベース(チェックポイントおよびログ)ファイルは、アクセスしているディレクトリとは別のディレクトリに存在する可能性があります。

『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースを識別するためのデータ・ソース名の識別方法に関する説明を参照してください。

OCIおよびPro*C/C++アプリケーションのトラブルシューティング

Windowsでは、NLS_LANGが環境に設定されていない場合、HKEY_LOCAL_MACHINE\Software\ORACLE\NLS_LANGレジストリでNLS_LANG設定が検索されます。NLS_LANGが無効な値に設定されている、またはNLS_LANGにサポートされていないキャラクタ・セットが表示される場合、OCI接続失敗エラーまたはORA-12705エラーがスローされます。サポートされているキャラクタ・セットの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のサポートされているキャラクタ・セットに関する項を参照してください。

NLS_LANGの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』のOCIに関する章のグローバリゼーションのサポートに関する説明を参照してください。

リソースを使い果たす

この項では、メモリー領域、ディスク領域、ファイル記述子、セマフォなどのリソースをTimesTenが使い果たしたときに確認する事項を説明します。

状態

参照先

メモリー消費量が高い

後述の「オペレーティング・システム・ツールおよび共有メモリー」

メモリー領域を使い果たす

- 後述の「オペレーティング・システム・ツールおよび共有メモリー」

- 「データベースに割り当てられたメモリーの量を確認する」

- 「問合せオプティマイザの統計を更新する」

- 「問合せで使用されるメモリーを確認する」

- 「データベースの致命的なクラッシュ後、メモリーが不足する」

ディスク領域を使い果たす。

「トランザクション・ログ・ファイルのディスク領域の使用を確認する」
「トレースが有効になっているかを確認する」

トランザクションのログ領域を使い果たす。

「トランザクション・ログ・ファイルのディスク領域の使用を確認する」

ファイル記述子を使い果たす。

「使用可能なファイル・ディスクリプタの数を増やす」

セマフォを使い果たす。

「セマフォの制限を確認する」

CPUを使い果たす。

スタック・トレースを取得して、TimesTenテクニカル・サポートに連絡する。

オペレーティング・システム・ツールおよび共有メモリー

top、vmstat、sarなどのオペレーティング・システム・ツールによって、プロセスおよびメモリー使用量に関する統計を取得します。これらのツールの出力では、各プロセスの共有メモリー使用量がレポートされますが、共有メモリー使用量の合計値はレポートされないため、TimesTenのメモリー消費量のインジケータとして誤解を招く可能性があります。共有メモリーは共有の定義によって異なるため、TimesTenプロセスのメモリーに関する様々な統計を加算すると、TimesTenで使用されるメモリー量より大きく見積もられます。

データベースに割り当てられたメモリーの量を確認する

TimesTenでは、永続メモリー領域と一時メモリー領域を使用します。これらの領域に割り当てられるメモリーの量は、データベースのDSN定義のPermSizeおよびTempSize属性で設定されます。

TimesTenデータベースが一杯になった場合、永続メモリー領域と一時メモリー領域のどちらが一杯かを判断することが重要です。ttIsql dssizeコマンドを使用して、永続メモリー領域および一時メモリー領域について、割当てサイズ、使用中のサイズおよび最高水位標サイズをリストします。dssizeコマンドを実行すると、SYS.MONITORから次の値が取得されます。

- PERM_ALLOCATED_SIZE

- PERM_IN_USE_SIZE

- PERM_IN_USE_HIGH_WATER

- TEMP_ALLOCATED_SIZE

- TEMP_IN_USE_SIZE

- TEMP_IN_USE_HIGH_WATER

永続メモリー領域は表および索引データで構成され、一時メモリー領域はロック、ソート領域およびコンパイル・コマンドなどの内部構造で構成されます。

トランザクションを短くして、データベースに十分な一時領域が確実にあるようにすることで、ロックによって残りのすべての一時領域が占有されることを回避します。トランザクションによって大量の行ロックが取得される場合は、表ロックを使用することもできます。

データベースのサイズを見積る方法についてのヒントは、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースの適切なサイズ設定に関する説明を参照してください。

永続メモリー領域が一杯である

索引に破棄できるものがないかを検討してください。実際に使用されている索引は、問合せ計画を参照するとわかります。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の問合せオプティマイザ計画の確認と変更に関する説明を参照してください。ttRedundantIndexCheckプロシージャを使用して、冗長な索引を見つけることもできます。このプロシージャでは、破棄する索引に関する提案が返されます。

ttSizeユーティリティを使用すると、データベース内の各表が使用するメモリーの量を見積もることができます。格納する必要のあるデータ量が多すぎる場合は、データベースのPermSize属性を再設定して、永続メモリー領域のサイズを大きくする必要があります。メモリーのサイズに制限があるために、一時メモリー領域を縮小したり、データベースを拡大することができない場合などは、かわりに、データを複数の異なるデータベースに分割する必要があります。

永続メモリー領域が一杯になったときに、データベースからデータをコピーして取り出し、データをすべて削除し、その後データを元に戻すことで、領域を解放することもあります。これは、ttMigrateユーティリティ-relaxedUpgradeオプションを使用してデータを外部に移行し、データベースを廃棄、再生成してから元に戻すと、より効果的です。この操作については、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のデータベースのサイズの縮小に関する説明を参照してください。

最後に、プロセスにより多くの量の共有メモリーが割り当てられるように、オペレーティング・システムを構成する必要がある場合があります。また、仮想メモリーにより多くのスワップ領域を割り当てる必要があることもあります。

一時メモリー領域が一杯である

統計が古いために、いくつかのコマンドで割り当てている領域が多すぎる可能性があります。詳細は、次の項で説明する「問合せオプティマイザの統計を更新する」を参照してください。

統計を更新しても一時メモリー領域が減らない場合は、すべての接続を切断してから、再接続します。すべての接続が切断されたかどうかは、ttStatusユーティリティで確認します。これですべての一時領域が解放されますが、コマンドを再準備する必要はあります。

問合せのメモリー使用量を診断します。後述の「問合せで使用されるメモリーを確認する」を参照してください。

問合せオプティマイザの統計を更新する

ttOptUpdateStatsまたはttOptEstimateStatsプロシージャを使用して、最適化統計を更新していることを確認してください。問合せの中には、実行時に一時領域の割当てが必要なものがあります。必要な一時領域の量は、問合せに使用する表の統計から見積もられます。正しい統計データがないと、必要な一時領域が少なく見積もられることがあります。

詳細は、「問合せオプティマイザの使用」を参照してください。

問合せで使用されるメモリーを確認する

一時メモリー使用量の最高水位標を確認すると、問合せで使用されるメモリーを確認できます。最高水位標は、この水位標が初期化またはリセットされた後で使用された、使用中の一時領域の最大量を表します。

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

1. ttIsql dssizeコマンドを使用して、TEMP_IN_USE_SIZEおよびTEMP_IN_USE_HIGH_WATERを確認します。これらの値はSYS.SYSTEMSTATS表またはSYS.MONITOR表で問い合せることもできます。

2. ttMonitorHighWaterResetプロシージャをコールして、TEMP_IN_USE_HIGH_WATERをTEMP_IN_USE_SIZEの現在の値にリセットします。

3. 問合せを実行します。

4. dssizeを使用して、TEMP_IN_USE_HIGH_WATERで問合せのピーク時のメモリー使用量を確認します。

データベースの致命的なクラッシュ後、メモリーが不足する

エラー846および994などの回復不能なエラーが発生した場合、TimesTenデータベースは無効化されます。ただし、データベースはメモリー内に残り、すべてのユーザーがデータベース切断したときに解放されます。ユーザーが無効化されたデータベースに接続している間にデータベースを再起動した場合、古いインスタンスと新しいインスタンスの両方が同時にメモリーに存在します。この場合、ユーザーは、メモリー不足の状態を知らせる通知を受け取る場合があります。メモリー不足のエラーを防ぐには、回復不能なエラーが発生したときにすべての有効な接続を切断してから再接続します。これらの回復不能なエラーは、通常発生しません。

トランザクション・ログ・ファイルのディスク領域の使用を確認する

TimesTenは、DataStore属性で指定されているディレクトリに格納されている2つのチェックポイント・ファイルにデータベースのコピーを保存します。各チェックポイント・ファイルはディスク上で大きくなり、共有メモリー内のデータベースのサイズと同等になる可能性があります。各永続データベースについて、2つのチェックポイント・ファイルとトランザクション・ログ・ファイルを保存するための十分なディスク領域が必要です。

トランザクション・ログ・ファイルはLogDir属性で指定されたディレクトリに蓄積され、チェックポイントが実行されたときにのみ削除されます。DSNにLogDir属性が指定されていない場合は、DataStore属性で指定されたディレクトリにトランザクション・ログ・ファイルが蓄積されます。トランザクション・ログ・ファイルの最大サイズは、LogFileSize属性で設定されます。

ディスクがTimesTenデータで一杯になる原因のほとんどは、トランザクション・ログ・ファイルの蓄積です。TimesTenのトランザクション・ログ・ファイルは、トランザクション・ロールバック、バックアップおよびレプリケーションなど様々な用途で使用されます。どの操作がトランザクション・ログ・ファイルを保持するかを特定することが重要であり、これによって、トランザクション・ログ・ファイルを適切にパージできるように適切なアクションをとることができます。これは、ttLogHolds組込みプロシージャを使用して行います。ログの保持には6つのタイプがあります。次の説明を参照してください。

- 長時間実行のトランザクション - TimesTenでは、トランザクション・ログを使用してトランザクションをロールバックします。トランザクションの存続中はログを保持するように設定されます。長時間アクティブなトランザクションでは、トランザクションがログ・レコードを1つ以上書き込んだ場合(つまり、読取り専用トランザクションではない場合)、ログ・ファイルが蓄積されます。(つまり、読取り専用トランザクションではありません。)このため、書込みトランザクションは適切な頻度でコミットし、大量のログ・ファイルが蓄積されないようにします。トランザクションの長さの詳細は、Oracle TimesTen In-Memory Databaseオペレーションガイドのトランザクションの適切なサイズ設定に関する説明を参照してください。

- チェックポイント - TimesTenアプリケーションがクラッシュし、データベースをリカバリする必要がある場合、チェックポイント・ファイルとトランザクション・ログ・ファイルを使用してデータをリカバリします。使用されるトランザクション・ログ・ファイルは、チェックポイント処理以降に作成された最新のトランザクション・ログ・ファイルです。トランザクション・ログ・ファイルは、チェックポイントとチェックポイントの間に蓄積されます。チェックポイント処理の頻度が非常に低い場合、特にチェックポイントとチェックポイントの間で多くの変更がデータベースに加えられると、大量のトランザクション・ログ・ファイルが蓄積される可能性があります。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のチェックポイント操作に関する項を参照してください。

- レプリケーション - TimesTenレプリケーションは、あるデータベースから他の1つ以上のデータベースに変更を送信します。これは、トランザクション・ログを読み込み、関連する変更を送信することで行います。レプリケーションを停止すると、トランザクション・ログ・ファイルが蓄積されます。レプリケーションの一時停止、再起動または再設定の詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のサブスクライバのレプリケーション状態の設定に関する説明を参照してください。

- バックアップ - TimesTenでは、トランザクション・ログ・ファイルを使用して、最後のバックアップ以降に加えられた変更をバックアップに追加する増分バックアップ機能をサポートします。増分バックアップと増分バックアップの間にトランザクション・ログ・ファイルが蓄積されます。大規模なログが蓄積されないようにするには、増分バックアップを比較的頻繁に実行します。状況に応じて、増分バックアップを無効にし、かわりに完全バックアップを実行します。『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』の移行、バックアップおよびリストアに関する説明を参照してください。

- XLA - TimesTenの永続的なXLA機能は、トランザクション・ログ・ファイルを使用してデータベースへの変更をレポートします。ttXlaAcknowledge Cファンクションで対応するトランザクションが受け入れられるまで、トランザクション・ログ・ファイルは保持されます。トランザクション・ログ・ファイルが蓄積されないように、頻繁にttXlaAcknowledgeをコールします。『Oracle TimesTen In-Memory Database C開発者ガイド』のトランザクションログからの更新レコードの取得に関する説明を参照してください。

- XA - TimesTenのXAサポートは、トランザクション・ログ・ファイルを使用して分散トランザクションを解決します。これらのトランザクションが適時に解決されないと、トランザクション・ログ・ファイルが蓄積されます。『Oracle TimesTen In-Memory Database C開発者ガイド』のXAの分散トランザクション処理に関する項を参照してください。

ディスクの使用には、次の属性が関係します。

- LogPurge属性は、保持する必要がなくなったトランザクション・ログ・ファイルをパージ(ディスクから削除)するか、または単にアーカイブ(名前を変更)するかを示します。LogPurge属性がデフォルト値の0(ゼロ)に設定されている場合、TimesTenは名前の後ろに文字列.archを付加して、不要になったトランザクション・ログ・ファイルの名前を変更します。名前を変更した後は、不要になったときに手動でトランザクション・ログ・ファイルを削除する必要があります。トランザクション・ログ・ファイルをパージしないと、TimesTenで不要になったときも、トランザクション・ログ・ファイルが蓄積され続けて領域を浪費します。

- Preallocate属性は、接続時にチェックポイント・ファイル用のディスク領域を確保する必要があるかどうかを示します。これは、大規模なデータベースで、データをデータベースに追加するときに、チェックポイントファイルにディスクの空き容量が常にあるかを確認するのに役立ちます。

トレースが有効になっているかを確認する

ファイルへのトレースが有効化されている場合、ファイルが非常に大きくなるため、操作を試みるプロセスがファイル制限を超えてしまう可能性があります。トレースは必ず既存のファイルに追加されます。

セマフォの制限を確認する

IPCとしての共有メモリー・セグメントを許可するように構成されたTimesTenデータベースに対する複数のクライアント/サーバー接続を作成する場合、TimesTenでセマフォを作成できなかったことを示すエラーが発生することがあります。

セマフォの制限はプラットフォームに依存しています。

SELECT文の結果が重複する

コミット読取り分離レベルを使用すると、結果セットで重複する可能性があります。SELECTによるスキャンの実行範囲内でいくつかの行が追加または削除されてコミットされた場合に、SELECT文によって選択される行が、表内の行の合計数より多くなったり、少なくなります。これは、UPDATE、INSERTまたはDELETE文によって索引に対して値の追加または削除が実行され、SELECTによるスキャンでその索引が使用されている場合に発生する可能性があります。また、INSERTまたはDELETEによって表に対して行の追加または削除が実行され、SELECT操作で全表スキャンが使用されている場合も発生する可能性があります。

索引値は順序付けられています。索引値に対してUPDATEすると、古い値が削除され、新しい値が別の場所に挿入される場合があります。つまり、ある場所から別の場所に索引内の行が移動されます。索引スキャンでは、両方の位置に同じ行が検出されると、同じ行が2回返されます。シリアル・スキャンを行う場合、表ページが順序付けられておらず、UPDATEに対して行を移動する必要がないため、このような動作は発生しません。したがって、スキャンによって渡された行が再度参照されることはありません。

この問題を回避するには、SELECT文でシリアライズ可能分離レベルを使用します。これによって、INSERT、DELETEまたはUPDATEの同時操作を防止できます。INSERTまたはDELETEはすべての索引に影響を及ぼすため、これらの操作で索引を使用してこの問題を回避する信頼性の高い方法はありません。UPDATEの場合は、更新されていない索引をSELECT文で使用してこの問題を回避することができます。

シリアライズ可能分離の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の分離およびロックによる並行性制御に関する説明を参照してください。

PL/SQL共有メモリーをアタッチできない

PLSQL_MEMORY_ADDRESS初期接続属性は、PL/SQL共有メモリー・セグメントが、TimesTenダイレクト・ドライバを利用する各プロセスにロードされる仮想アドレスを指定します。アドレス空間のマッピング方法は、オペレーティング・システムのプラットフォームによってそれぞれ異なるため、PLSQL_MEMORY_ADDRESS接続属性で定義されているPL/SQLアドレス空間のデフォルトの値は各プラットフォームで異なり、その結果、アドレス空間がマッピングされたオペレーティング・システムとの競合を回避することができます。

ただし、アプリケーションが、アドレス空間をマッピングしたPL/SQLと重複する場合、エラー8517「Cannot attach PL/SQL shared memory; PLSQL_MEMORY_ADDRESS not valid or already in use.」を受信する場合があります。この場合、PLSQL_MEMORY_ADDRESS接続属性の設定を変更して重複を削除します。次のいずれかの理由で、エラー8517を受信する場合があります。

- ユーザーが割り当てたメモリーでそのアドレスがすでに使用されている。

- 一部の共有メモリーでそのアドレスがすでに使用されている。

- 共有ライブラリでそのアドレスがすでに使用されている。

リカバリするには、データベースに接続可能なすべてのプロセスで使用されていない仮想アドレスを指定します。TimesTenに接続する前に多くのメモリーを割り当てる32-bitプログラムがある場合、そのプログラムによってPL/SQL共有メモリー・セグメントがクラッシュする可能性があります。その場合は、TimesTenに接続した後でメモリーを割り当てるか、または64-bitアプリケーションを使用します。64-bit環境の場合、他のメモリー・アドレスに再割り当てするオプションは、オプションに制限があり、重複が発生する可能性がより高い32-bitオペレーティング・システムのオプションほど複雑ではありません。

アプリケーションが2つ以上のTimesTenデータベースに同時に接続する場合、デフォルト設定では、PL/SQLメモリー・アドレスをすべてのTimesTenデータベースに対して同じアドレスにマッピングするため、いずれか1つを除くすべてのTimesTenデータベースのPLSQL_MEMORY_ADDRESS属性のデフォルト設定を変更する必要があります。

3 TimesTen Application-Tier Database Cacheのトラブルシューティング

この章の次の項は、TimesTen Application-Tier Database Cache (TimesTen Cache)の使用時に発生する可能性があるいくつかの問題の解決方法について説明します。

- キャッシュ・グループを作成できない

- キャッシュ・エージェントを起動または停止できない

- 予期しないシステム・シャットダウン後のキャッシュ・グリッドのリカバリ

- Oracleサービス名を解決できない

- 接続識別子を解決できない

- Oracle Databaseサーバーおよびクライアントのバージョンに互換性がない

- Oracle Databaseユーザー名およびパスワードを有効化できない

- OCIの初期化に失敗する

- サポートされていないデータ型マッピング

- Null制約がOracle Databaseと一致しない

- キャッシュされたOracle表へのDDLのため、キャッシュ・グループ操作が失敗する可能性がある

- キャッシュ・グループ内のオブジェクトの更新後に変更を表示できない

- ロードまたはリフレッシュに失敗する

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

- TimesTenキャッシュのパフォーマンスを最適化する

- Oracle Database表の大規模なバッチ・ジョブで発生するパフォーマンスおよびメモリーの問題を回避する

- 自動リフレッシュ時に指定した間隔でキャッシュがリフレッシュされない

- 増分自動リフレッシュが進行中ではない

- 増分自動リフレッシュが完全自動リフレッシュになる

- 自動リフレッシュのパフォーマンスが悪い

- 制約にNOVALIDATEを宣言すると、キャッシュ・グループの作成に失敗する

- DBMS_LOCKとのロック競合を表示するAWRレポート

AWTキャッシュ・グループで問題が発生している場合は、第5章「AWTキャッシュ・グループのトラブルシューティング」を参照してください。

注意:
この章の例で示すとおり、キャッシュ・エージェント・デーモンからのエラー・ログは、CACでメッセージ内に指定されます。ttDaemonLogユーティリティのCACHEコンポーネントを無効化しないかぎり、これらのメッセージは有効です。WindowsおよびUNIXのttDaemonLogオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDaemonLogに関する説明を参照してください。

キャッシュ・グループを作成できない

この項では、CREATE CACHE GROUP文の実行時に発生する可能性がある問題について説明します。

考えられる原因

対処

ユーザーが、キャッシュ・グループ・タイプを作成するための正しいOracle Database権限を持っていない。

「Oracle Database権限を確認する」を参照してください。

ユーザーがデータベースにアクセスする十分な権限を持っていない。

キャッシュ・グループを作成するには、CACHE_MANAGER権限が必要です。

内部/外部ユーザーがOracle Databaseユーザーと一致しない

TimesTenと、Oracle Databaseは、同一のユーザー名を指定する必要があります。

Oracle Databaseに接続できない

次の項を参照してください。

- 「Oracleサービス名を解決できない」

- 「接続識別子を解決できない」

- 「Oracle Databaseユーザー名およびパスワードを有効化できない」

- 「Oracle Databaseサーバーおよびクライアントのバージョンに互換性がない」

- Oracle Databaseを再起動する必要があるかどうか、確認する。

ネットワーク・ステータスを確認する。

キャッシュ管理ユーザーのIDまたはパスワードが設定されていない(AWTまたは自動リフレッシュ・キャッシュ・グループを作成しようとした場合)

「キャッシュ管理ユーザーの名前およびパスワードを設定する」を参照してください。

データ型マッピングがサポートされていない。

「サポートされていないデータ型マッピング」を参照してください。

Oracle DatabaseでのNULL値可能設定が異なる。

「Null制約がOracle Databaseと一致しない」を参照してください。

ルート表の主キーが指定されていない

キャッシュ・グループのルート表には、主キーが必要です。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・グループの定義に関する説明を参照してください。

キャッシュ・エージェントを起動または停止できない

この項では、キャッシュ・エージェントの起動時または停止時に発生する可能性がある問題について説明します。

考えられる原因

対処

キャッシュ・エージェントがすでに稼働している。

後述の「キャッシュ・エージェントのステータスを確認する」を参照してください。

Oracle Databaseライブラリが見つからない。

- 「TNSリスナーおよびOracle Database Serverのステータスを確認する」を参照してください。

- ライブラリに対する権限を確認します。

ORACLE_HOMEが無効。

後述の「ORACLE_HOME環境変数を確認する」を参照してください。

権限が十分ではない。

キャッシュ・エージェントを起動または停止するには、CACHE_MANAGER権限が必要です。

OracleNetServiceNameが正しくない。

DSN定義に設定したOracleNetServiceNameが、TimesTenでキャッシュする表が含まれるOracle DatabaseインスタンスのOracleサービス名と一致することを確認します。

キャッシュ・エージェントのステータスを確認する

キャッシュ・エージェントのステータスは、ttStatusユーティリティ(「ttStatusユーティリティの使用」を参照)を使用して確認します。

キャッシュ・エージェントが実行されていない場合は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する項を参照して、キャッシュ・エージェントを起動します。キャッシュ・エージェントを起動できない場合は、考えられる原因を調査し、システムを再起動してからキャッシュ・エージェントを起動してください。

ORACLE_HOME環境変数を確認する

UNIXまたはLinuxプラットフォームでは、キャッシュ・エージェントおよびTimesTenデーモンを起動しているシェルにORACLE_HOME環境変数が正しく設定されていることを確認します。ORACLE_HOMEの設定を変更する必要がある場合は、ttmodinstallユーティリティを使用します。

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

NLS環境変数を確認する

NLS環境変数は、TimesTenアプリケーションが稼働している環境に設定されます。TimesTenでNLS環境変数を使用しているかどうか、確認します。

予期しないシステム・シャットダウン後のキャッシュ・グリッドのリカバリ

停電などが起きた場合、サーバーにシステム障害や予期せぬ再起動が発生する可能性があります。このような場合、キャッシュ・グリッドは通常のシャットダウンを行わずに、予期せず終了します。

次の項では、システムが予期せずシャットダウンする2つのシナリオについてのリカバリ方法を説明します。

- キャッシュ・グリッド・ノードの一部が実行中である場合

- すべてのキャッシュ・グリッド・ノードが予期せず終了した場合

キャッシュ・グリッド・ノードの一部が実行中である場合

キャッシュ・グリッド・ノートは、サーバーがシャットダウンすると予期せず終了する場合がありますが、アクティブなままである場合もあります。このような場合、次の手順のように、アタッチされたノードからttGridDetachListを実行して、まず機能していないノードをデタッチする必要があります。

1. アクティブなグリッド・ノードに接続し、ttGridDetachListを実行して、機能していないノードすべてをグリッドからデタッチします。

2. 再起動したサーバーのデータベースに接続します。ttRepStartを起動して、レプリケーション・エージェントを起動します。

3. ttGridAttachを実行して、キャッシュ・グリッド・ノードをアタッチします。

4. 通常のデータベース操作を再開します。

すべてのキャッシュ・グリッド・ノードが予期せず終了した場合

サーバーがシャットダウンした時にすべてのキャッシュ・グリッド・ノードが予期せず終了した場合、次のタスクを実行してキャッシュ・グリッドをリカバリします。

1. 起動したサーバーのデータベースに接続して、各グリッド・ノードにログオンします。ttRepStartを起動して、レプリケーション・エージェントを起動します。ログが現行であれば、レプリケーション・エージェントは既存のログをフラッシュします。

2. 各ノードにttGridAttachをコールすると、他のメンバーと通信できないために通信エラーが発生して失敗します。失敗したアタッチはノード情報をクリーンアップします。

3. ttGridAttachを実行した最後のノードは成功します。この時点で、すべてのノードがクリーンアップされるので、再びすべてのノードにttGridAttachを実行して、各ノードをグリッドにアタッチします。

4. 通常のデータベース操作を再開します。

Oracleサービス名を解決できない

サービス名が解決できなかったことを示すエラーORA-12514を受け取った場合は、次の内容を確認します。

- Oracle Database TNSPINGユーティリティを使用して、サービスが到達可能であることを確認します。

- DSN定義に設定したOracleNetServiceNameが、TimesTenでキャッシュする表が含まれるOracle DatabaseインスタンスのOracleサービス名と一致することを確認します。

- 定義したサービス名が存在することを確認します。Windows Oracleクライアントの場合は、Oracle Net Configuration Assistantを使用してサービス名を構成します。Oracle Net Configuration Assistantで、「Oracle Net Configuration」→「Local」→「Service Naming」に進み、使用するOracle Databaseサーバーを選択して、サーバー名またはOracle Databaseサーバーを特定するSIDが存在するかどうか確認します。サービス名を追加または変更した場合は、再起動する必要があります。
Oracle Databaseのキャッシュ管理ユーザーの名前およびパスワードでSQL*Plusを使用して、サービス名が正しいかどうか確認します。次に例を示します。

%sqlplus cache_admin_user/cache_admin_pwd@OracleHost

ここで、cache_admin_userはキャッシュ管理ユーザーのユーザー名、cache_admin_pwdはキャッシュ管理ユーザーのパスワード、OracleHostはDSN定義で指定されているOracleNetServiceNameです。

注意:
使用するキャッシュ管理ユーザーが、通常のOracle databaseユーザーと異なる場合があります。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseでのユーザーの作成に関する説明を参照してください。

- TimesTenシステムに、単一のtnsnames.oraのコピーのみがあることを確認します。また、tnsnames.oraに対する権限も確認します。

- TimesTenをUNIXシステムで稼働する場合、ORACLE_HOME環境変数が正しく定義されていることを確認します。次に例を示します。

ORACLE_HOME=/products/oracle11g

- Oracle Databaseクライアントおよびサーバーのバージョンを確認します。後述の、「Oracle Databaseサーバーおよびクライアントのバージョンに互換性がない」を参照してください。

接続識別子を解決できない

データベースへの接続試行時に、ORA-12154「TNS: 指定された接続識別子を解決できませんでした。」というエラーを受け取る場合があります。

これは、TimesTen CacheおよびOracle Databaseを同一のシステムで使用し、TNS_ADMIN環境変数がOracle Databaseの正しいtnsnames.oraファイルを指していない場合に発生します。たとえば、ラップトップでOracle Databaseの複数のインスタンスが稼働している場合に、この問題が発生することがあります。

本番環境では、TimesTenとOracle Databaseは、通常、異なるシステム上で稼働させます。この場合、TimesTenが稼働するシステム上のtnsnames.oraファイルを指すようにするために、TNS_ADMIN環境変数をリセットしないでください。Oracle Databaseクライアントは、接続の解決にTNS_ADMIN設定を使用しますが、TimesTenのメイン・デーモン、キャッシュ・エージェント、Webサーバーおよびレプリケーション・エージェントは、TNS_ADMIN設定を認識しません。TimesTen Cacheは、Oracle DatabaseクライアントとTimesTenが異なるtnsnames.oraファイルを使用する場合、正常に動作しません。

Windowsの場合、TNS_ADMIN環境変数は次のように設定します。

1. 「マイ コンピュータ」を右クリックし、「プロパティ」を選択します。

2. 「詳細設定」タブで、「環境変数」を選択します。

3. 使用するtnsnames.oraファイルが格納されているディレクトリを指すようにTNS_ADMINをシステム環境変数として追加または編集します。INAMEコマンドを使用して、tnsnames.oraファイル内に他のtnsnames.oraファイルを組み込むことができます。

Oracle Databaseサーバーおよびクライアントのバージョンに互換性がない

ORA-12170またはORA-12535などの接続タイムアウト・エラー、またはORA-03134 (サーバー・バージョンがサポートされていません)を受け取った場合、互換性のあるOracle DatabaseクライアントとOracle Databaseサーバー・バージョンを使用していることを確認します。

Metalinkのドキュメント・ノート207303.1「Client/Server/Interoperability Support Between Different Oracle Versions」に、Oracleでサポートされているクライアントとサーバーの組合せを示しています。

Oracle DatabaseおよびTimesTenのリリース・ノートを参照し、クライアントおよびサーバーのバージョンの既知の問題を確認してください。

Oracle Databaseユーザー名およびパスワードを有効化できない

この項では、Oracle Databaseユーザー名およびパスワードの使用時に発生する可能性がある問題について説明します。

考えられる原因

参照先

ライブラリ環境変数が正しく設定されていない。

後述の「ライブラリ・パス環境変数を確認する」

Oracle Databaseプロセスが稼働していない。

後述の「TNSリスナーおよびOracle Database Serverのステータスを確認する」

ユーザーが、正しいOracle Database権限を持っていない。

後述の「Oracle Database権限を確認する」

DSNの定義が正しくない。

「DSN定義を確認する」

キャッシュ管理ユーザーのIDまたはパスワードに問題がある。

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

ユーザー環境とシステム環境の整合性がとれていない。

「ユーザー環境とシステム環境を確認する」

動的ライブラリがロードされていない。

「ロードされた動的ライブラリを検証する」

ライブラリ・パス環境変数を確認する

使用しているプラットフォームのライブラリ・パス環境変数を確認します。

プラットフォーム

確認する変数

UNIX

LD_LIBRARY_PATH

Windows

PATH

ライブラリ・パス環境変数には、次の情報が含まれている必要があります。

TimesTenのビットとプラットフォームのビット

設定値

32-bitプラットフォーム上の64-bitまたは32-bitのTimesTen

$ORACLE_HOME/LIBおよび$ORACLE_HOME/NETWORK/LIB

64-bitプラットフォーム上の32-bitのTimesTen

$ORACLE_HOME/LIB32および$ORACLE_HOME/NETWORK/LIB32

TNSリスナーおよびOracle Database Serverのステータスを確認する

SQL*Plusを使用してOracle Databaseに接続するか、またはOracle Enterprise Managerを使用してステータスを確認します。

Oracle Database権限を確認する

次を入力して、付与されている現在のOracle Database権限の一覧を、Oracle SQL*Plusコマンド・プロンプトから表示します。

SELECT * FROM SESSION_ROLES;
SELECT * FROM SESSION_PRIVS;

一覧表示された権限を、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseユーザーへの権限の付与に関する説明の中で指定されている、TimesTen Cache操作に必要な各権限と比較します。追加の権限が必要な場合は、Oracle Database管理者に連絡してください。

DSN定義を確認する

- 『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle DatabaseからデータをキャッシュするTimesTenデータベースのDSNに関する説明の例などを参照して、DSN属性が正しく設定されていることを確認します。

- TimesTen CacheのDSN定義がシステムDSNであることを確認します。

- TimesTen CacheのDSNが1回のみ定義されていることを確認します。

- Oracle Databaseユーザー名およびパスワードを確認します。SQL*Plusを使用し、DSN定義で使用しているものと同じOracleNetServiceNameとOraclePWDを使用してOracle Databaseに接続し、それらが正しいことを確認します。

TimesTenマシンを再起動する

Oracle Databaseクライアントのインストール後に、システムを再起動していない場合、TimesTenデーモンはOracle Databaseクライアントをインストールする前の「古い」環境下で稼働しています。システムを再起動すると、TimesTenは「新しい」環境下で開始されます。

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

キャッシュ管理ユーザーの名前とパスワードは、TimesTenデータベースに1回のみ設定する必要があります。ただし、TimesTenデータベースが破棄されて再作成された場合、またはOracle Databaseでキャッシュ管理ユーザーの名前が削除されて再作成された場合は、変更する必要があります。

TimesTenデータベースでキャッシュ・エージェントを実行している場合、またはデータベース内にキャッシュ・グループが存在する場合は、キャッシュ管理ユーザーの名前およびパスワードを変更できません。キャッシュ管理ユーザーの名前およびパスワードを変更する前に、キャッシュ・グループを削除する必要があります。また、キャッシュ管理ユーザーの名前およびパスワードを変更する前に、キャッシュ・エージェントを停止し、ユーザー名およびパスワードを変更した後でキャッシュ・エージェントを再起動する必要があります。

ttIsqlセッションから、キャッシュ・マネージャ・ユーザーとしてデータベースに接続し、ttCacheUidPwdSet組込みプロシージャをコールして、次のようにOracle Databaseキャッシュ管理ユーザーの名前とパスワードを設定します。

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

エラーが戻される場合、Oracle Database ID、キャッシュ管理ユーザーIDおよびキャッシュ管理パスワードを確認します。加えて、Oracle Databaseインスタンスが稼働しているかどうか確認します。

また、ttAdmin -cacheUidPwdSetユーティリティ・コマンドを、CACHE_MANAGERを持つTimesTen外部ユーザーとして実行して、ユーザー名およびパスワードを設定することもできます。

% ttAdmin -cacheUidPwdSet -cacheUid cacheuser -cachePwd oracle cachealone1

-cachePwdオプションを指定しなかった場合、ttAdminユーティリティによってキャッシュ管理ユーザーのパスワードを入力するように求められます。ユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

ユーザー環境とシステム環境を確認する

問題の原因が、ユーザー環境とシステム環境の相違によるかどうかを確認するテストを行います。この手順では、2つのセッション・ウィンドウ(Windowsのコマンド・プロンプト・ウィンドウまたはUNIXのシェル・ウィンドウ)が必要です。

1. TimesTenデーモンを停止します。

2. 一方のセッション・ウィンドウで、通常のユーザーとしてTimesTenデーモンを起動します。

Windowsの場合:

% install_dir/srv/ttsrv1122.exe -d -verbose

UNIXの場合:

% install_dir/srv/timestend -d verbose

いくつかのメッセージが一瞬表示され、待機状態になります。

3. もう1つのセッション・ウィンドウで、キャッシュ・エージェントを再起動してみます。

4. 手順3が成功したら、手順2で1つ目のセッションで起動したTimesTenデーモンを停止します。Windowsの場合は[Ctrl]+[C]、UNIXの場合はkillコマンドを使用して停止します。

5. ユーザー環境およびシステム環境を比較します。たとえば、ユーザーとシステムはどちらもoci.dllの同じコピーを見ているでしょうか。oci.dllライブラリに対するパス名は、ユーザーとシステム環境の間で違いがあるでしょうか。

6. 相違がある場合は、必要な修正を行います。

7. システムを再起動し、TimesTenデーモンを再起動します。

ロードされた動的ライブラリを検証する

Visual C++がインストールされているWindowsシステムで実行中の場合は、ロードされた動的ライブラリを検証します。次に示す検証は、キャッシュ・エージェントを自動リフレッシュなしで起動できる場合にのみ可能です。

1. TimesTenが起動していることを確認します。

2. 自動リフレッシュなしでキャッシュ・エージェントを起動します。

Command> call ttCacheStart;
Command> create cache group cg1 from t1(c1 int not null primary key);

3. Windowsタスク・マネージャを開いて、プロセスttora1122.exeを見つけたら強調表示します。強調表示したプロセスを右クリックして、「デバッグ」を選択します。これにより、Visual C++が起動し、「Oracleサービス名を解決できない」で説明されているように、デバッグ・ウィンドウにロードされたDLLが表示されます。

4. キャッシュ・グループをロードして、キャッシュ・エージェントとのキャッシュ接続を強制します。

Command> load cache group cg1 commit every 100 rows;

5. デバッグ・ウィンドウにロードされたDLLを、次の例3-1に示す部分的なリストと比較します。

例3-1 ロードされたDLLのリスト

この部分的なリストは、Oracle Databaseクライアントで作成されています。

Loaded 'E:\TimesTen\tt1121_32\bin\timestenorad1121.exe', no matching symbolic
information found.
Loaded 'C:\WINDOWS\SYSTEM32\ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\kernel32.dll', no matching symbolic information
found.
Loaded 'E:\TimesTen\tt1121_32\bin\tten1121.dll', no matching symbolic information
found.
Loaded 'E:\TimesTen\tt1121_32\bin\ttcommon1121.dll', no matching symbolic
information found.
Loaded 'C:\WINDOWS\SYSTEM32\wsock32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\SYSTEM32\ws2_32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\msvcrt.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\SYSTEM32\ws2help.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\SYSTEM32\advapi32.dll', no matching symbolic information
found.
Loaded 'C:\WINDOWS\SYSTEM32\rpcrt4.dll', no matching symbolic information found.
...

OCIの初期化に失敗する

Oracle Databaseへの接続が必要な操作で、エラー5105「OCI initialization failed」が発生することがあります。たとえば、次の状況で発生します。

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

- キャッシュ管理ユーザーのIDまたはパスワードの設定時

- TimesTenでのSQL文の入力時(autocommit=0、PassThrough=3の場合)

エラー5105には、エラーの原因に関する追加情報が含まれています。

- OCIでOracle Databaseライブラリが見つからない。「ライブラリ・パス環境変数を確認する」を参照して、エラー・メッセージに示されたライブラリに対する権限を確認してください。

- ORACLE_HOMEが無効。「ORACLE_HOME環境変数を確認する」を参照してください。

- NLS環境変数は、TimesTenアプリケーションが稼働している環境に設定されます。TimesTenでNLS環境変数を使用しているかどうか、確認します。

サポートされていないデータ型マッピング

キャッシュ・グループを作成しようとすると、次のエラーが表示されることがあります。

5115: Unsupported type mapping for column name

たとえば、Oracle Database上の表tabは、次のように説明されます。

COL1     NUMBER(38) NOT NULL
COL2     NUMBER(38)

次のようにしてキャッシュ・グループを作成します。

CREATE CACHE GROUP cg FROM tab(col1 CHAR(10) NOT NULL PRIMARY KEY);

文はNUMBERデータ型の列をCHARデータ型の列へのマップを試みるため、列エラー5119が表示され、キャッシュ・グループは作成されません。

『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキー列で許可されるデータ型マッピングに関する説明を参照してください。

Null制約がOracle Databaseと一致しない

キャッシュ・グループを作成しようとすると、次の警告が表示されることがあります。

Warning 5119: Column name has different nullability setting in Oracle

たとえば、Oracle Database上の表tabは、次のように説明されます。

COL1     NUMBER(38) NOT NULL
COL2     NUMBER(38)

次のようにしてキャッシュ・グループを作成します。

CREATE CACHE GROUP cg
FROM tab(col1 INTEGER NOT NULL PRIMARY KEY, col2 INTEGER NOT NULL);

Oracle Database上のcol2にはNULL制約を持たず、キャッシュ・グループのcol2はNOT NULLと定義されているため、警告5119が表示されます。

キャッシュされたOracle Database表へのDDLのため、キャッシュ・グループ操作が失敗する可能性がある

TimesTenにキャッシュされたOracle Database表へのDDL操作のため、キャッシュ・グループで障害が発生する可能性があります。たとえば、ユーザーがTimesTenにキャッシュされているOracle Database表上の列を削除する場合です。キャッシュ・グループが伝播またはフラッシュされると、TimesTenはOracle Database表にすでに存在していない列を更新することになります。キャッシュ・グループがロードまたはリフレッシュされると、TimesTenは削除された列からデータの取得を試行することになります。

次のキャッシュ・グループ操作は失敗する可能性があります。

- 自動リフレッシュは発生しません。

- AWTキャッシュ・グループ操作は、Oracle Databaseから伝播またはリフレッシュされることも、Oracle Databaseへ伝播またはリフレッシュされることもありません。

- キャッシュ・グループのロードまたは伝播は失敗します。

Oracle Database実表に対してDDL操作が行われたため、キャッシュ・グループ操作が適切に実行されていない可能性がある場合は、DDL追跡を使用して問題を診断します。DDL追跡では、キャッシュされたすべてのOracle Database表の変更履歴が保存されます。SQL文およびその実行日時は、Oracle Databaseのキャッシュ管理ユーザー・スキーマ内のTimesTen表にそれぞれ書き込まれます。

DDL追跡オブジェクトの作成方法や、Oracle Database内の実表に対してDDL追跡を有効にする方法の詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュされたOracle Database表に対して発行されたDDL文の追跡に関する説明を参照してください。DDL追跡の有効化または無効化に使用される組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheDDLTrackingConfigに関する説明を参照してください。

キャッシュ・グループ内のオブジェクトの更新後に変更を表示できない

キャッシュ・グループ内のオブジェクトを変更した後に変更が後続のSQL文に表示されない場合は、次のいずれかの問題が発生した可能性があります。

- そのオブジェクトが、Oracle Databaseから削除されたか、またはなんらかの原因で破損された。

- Oracle Databaseが、そのオブジェクトの作成時より前の時点までリストアまたはリカバリされた。

- Oracle Databaseが停止した。

- キャッシュ・グループを作成したOracle Database以外のOracle Databaseにポイントするキャッシュ・グループを作成した後に、ユーザーがOracleNetServiceName DSNまたは接続属性を変更した。

たとえば、ユーザーがAWTキャッシュ・グループを作成したとします。その後、このユーザーは表に行を追加しました。このユーザーが表に対してSELECT * FROMを実行すると、それらの行が表示されませんでした。ttmesg.logエラー・ファイルには、Oracle Databaseを使用できないというエラーは表示されていません。かわりに、次のメッセージが表示されています。

12:09:02.10 Err : REP: 29934: CACHE1:meta.c(904): TT5221: TT5221: Oracle syntax
error in OCIStmtExecute(): ORA-00942: table or view does not exist rc = -1 --
file "bdbStmt.c", lineno 1535, procedure "getOraOutTypesNLengths()"
12:09:02.27 Err : REP: 29934: CACHE1:receiver.c(1978): TT5250: Awt Initialization
Failure. Could not compile meta data sql.
12:09:02.27 Warn: REP: 29934: CACHE1:transmitter.c(6505): TT16060: Failed to read
data from the network. select() timed out

リカバリするには、次の手順を実行します。

1. キャッシュ・グループへのすべての更新を停止します。

2. AWTキャッシュ・グループを使用している場合は、キャッシュ・グループをフラッシュします。

3. 削除および作成を行ってキャッシュ・グループを再作成します。

ロードまたはリフレッシュに失敗する

COMMIT EVERY n ROWSでnに0(ゼロ)より大きい値を指定した場合に、LOAD CACHE GROUPまたはREFRESH CACHE GROUP文の実行に失敗すると、ターゲット・キャッシュ・グループの内容が一貫性のない状態になることがあります。キャッシュ・インスタンスの一部だけがロードされる場合もあります。

キャッシュ・グループをアンロードしてから再ロードします。キャッシュ・グループを削除して再作成する方が簡単な場合もあります。

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

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

- ttCacheAutorefreshStatsGetプロシージャの使用

- 変更ログ表の情報の表示

- サポート・ログの自動リフレッシュに関するメッセージの理解

- 自動リフレッシュの失敗の診断

- 自動リフレッシュのパフォーマンス問題の診断

- SNMPトラップによる自動リフレッシュの問題のアラート

ttCacheAutorefreshStatsGetプロシージャの使用

ttCacheAutorefreshStatsGetプロシージャでは、指定したキャッシュ・グループで実行された最近10回の自動リフレッシュ操作に関する情報が返されます。

ttCacheAutorefreshStatsGetプロシージャで情報が返されるのは、キャッシュ・エージェントが実行中で、自動リフレッシュの状態がONまたはPAUSEDになっている場合のみです。キャッシュ・エージェントが再起動されたり、自動リフレッシュの状態がOFFに変更された場合、すべての戻りフィールドは0(ゼロ)に設定されます。

例3-2 ttCacheAutorefreshStatsGetのコール

この例では、testcacheは、1つの表を持ち、増分自動リフレッシュ時間隔が10秒のREADONLYキャッシュ・グループです。

Command> call ttcacheautorefreshstatsget('user1','testcache');

< 1164260, 2007-07-23 15:43:52.000000, 850280, 44, 0, 75464, 528255, 75464, 310, 110, 6800,
1890912, 12439795, 1890912, 160020, InProgress >
< 1164260, 2007-07-23 15:43:33.000000, 831700, 43, 13550, 108544, 759808, 108544, 1030, 230,
12290, 1815448, 11911540, 1815448, 160020, Complete >
< 1164260, 2007-07-23 15:43:12.000000, 810230, 42, 17040, 115712, 809984, 115712, 610, 330,
16090, 1706904, 11151732, 1706904, 146470, Complete >
< 1164260, 2007-07-23 15:42:52.000000, 790190, 41, 14300, 94208, 659456, 94208,560, 320,
13410, 1591192, 10341748, 1591192, 129430, Complete >
< 1164260, 2007-07-23 15:42:32.000000, 770180, 40, 12080, 99328, 695296, 99328,450, 290,
11340, 1496984, 9682292, 1496984, 115130, Complete >
< 1164260, 2007-07-23 15:42:12.000000, 750130, 39, 10380, 86016, 598368, 86016,430, 230,
9720, 1397656, 8986996, 1397656, 103050, Complete >
< 1164260, 2007-07-23 15:41:52.000000, 730130, 38, 13530, 112640, 700768, 112640, 530, 220,
12780, 1311640, 8388628, 1311640, 92670, Complete >
< 1164260, 2007-07-23 15:41:32.000000, 710120, 37, 9370, 56320, 326810, 56320, 310, 160,
8900, 1199000, 7687860, 1199000, 79140, Complete >
< 1164260, 2007-07-23 15:41:22.000000, 700120, 36, 2120, 10240, 50330, 10240, 50, 200, 1870,
1142680, 7361050, 1142680, 69770, Complete >
< 1164260, 2007-07-23 15:41:12.000000, 690110, 35, 0, 0, 0, 0, 0, 0, 0, 1132440, 7310720,
1132440, 67650, Complete >
10 rows found.

表3-1に、最初の行の出力の結果を示します。

表3-1 最後の自動リフレッシュ操作でのttCacheAutorefreshStatsGetの結果

結果

フィールド名

説明

1164260

cgId

キャッシュ・グループID。

2007-07-23 15:43:52.000000

startTimestamp

この時間隔で自動リフレッシュが開始された時間のタイムスタンプ。

850280

cacheAgentUpTime

この時間隔で自動リフレッシュ・トランザクションが開始された時点でのキャッシュ・エージェントの経過時間(ミリ秒)

この値は累積され、キャッシュ・エージェント・プロセスが開始されるとリセットされます。

44

autorefNumber

自動リフレッシュ番号。

0

autorefDuration

この自動リフレッシュ操作にかかった時間(ミリ秒)

操作は現在進行中であるため、値は0(ゼロ)です。

75464

autorefNumRows

この自動リフレッシュ操作で自動リフレッシュされた行数

キャッシュ・グループに子表が存在する場合、ルート表および子表のすべての行が含まれます。

注意: 完全自動リフレッシュの場合、この情報は返されません。

528255

numOracleBytes

この自動リフレッシュ操作でOracle Databaseから転送されたバイト数

注意: 完全自動リフレッシュの場合、この情報は返されません。

75464

autorefNumRootTblRows

この自動リフレッシュ操作で自動リフレッシュされたルート表の行数

310

autorefQueryExecDuration

Oracle Databaseで自動リフレッシュ問合せの実行にかかった時間(ミリ秒)

注意: 完全自動リフレッシュの場合、この情報は返されません。

110

autorefQueryFetchDuration

自動リフレッシュ問合せでOracle Databaseからの行フェッチにかかった時間(ミリ秒)

注意: 完全自動リフレッシュの場合、この情報は返されません。

6800

autorefTtApplyDuration

TimesTenで、更新された行をキャッシュ・グループに適用するのにかかった時間(ミリ秒)

注意: 完全自動リフレッシュの場合、この情報は返されません。

1890912

totalNumRows

キャッシュ・エージェントの起動後に自動リフレッシュされた行の総数

注意: 完全自動リフレッシュの場合、この情報は返されません。

12439795

totalNumOracleBytes

キャッシュ・エージェントの起動後にOracle Databaseから転送された総バイト数

注意: 完全自動リフレッシュの場合、この情報は返されません。

1890912

totalNumRootTblRows

キャッシュ・エージェントの起動後に自動リフレッシュされたルート表の行の総数

160020

totalDuration

キャッシュ・エージェントの起動後の自動リフレッシュの総経過時間(ミリ秒)

InProgress

autorefreshStatus

ステータス

ステータスは、CompleteまたはFailedとなる場合もあります。

この例では子表がないため、自動リフレッシュされた行の総数(1890912)は、自動リフレッシュされたルート表の行の総数と同じになります。

Oracle Databaseで更新される行数が、TimesTenで自動リフレッシュされる行数に反映されるとはかぎりません。Oracle Databaseの更新がTimesTenで複数回適用されたり、Oracle Databaseの同じ行への複数の更新がTimesTenでは1回の更新として適用される場合もあります。

変更ログ表の情報の表示

TimesTenには、Oracle Databaseに存在する変更ログ表から、自動リフレッシュ・キャッシュ・グループの情報を収集するcacheInfo SQLスクリプトが用意されています。変更ログ表の詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseオブジェクトのキャッシュ環境の管理に関する項を参照してください。

SQL*Plusを使用して、Oracle Databaseでキャッシュ管理ユーザーとしてスクリプトを実行します。別のユーザーとしてスクリプトを実行すると、変更ログ表が存在しないことがレポートされます。

スクリプトの場所は次のとおりです。

install_dir/oraclescripts/cacheInfo.sql

cacheInfoスクリプトでは、キャッシュされた各表について次の情報が表示されます。

% cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheInfo
*************Autorefresh Objects Information ***************
Host name: sys1
Timesten datastore name: /users/OracleCache/alone1
Cache table name: ORATT.ORDERS
Change log table name: tt_06_69245_L
Number of rows in change log table: 100000
Maximum logseq on the change log table: 38
Timesten has autorefreshed updates up to logseq: 38
Number of updates waiting to be autorefreshed: 0
Number of updates that has not been marked with a valid logseq: 0
****************************

変更ログ表ごとに戻される情報には、変更ログ表の名前、それに対応するTimesTenキャッシュ表の名前、変更ログ表の行数、変更ログ表内の更新のうちキャッシュ表に自動的にリフレッシュされなかった更新の数などが含まれています。

ログ順序番号(logseq)は、自動リフレッシュ操作のマーカーとして機能します。

サポート・ログの自動リフレッシュに関するメッセージの理解

サポート・ログには、自動リフレッシュの処理状況を示すメッセージが含まれます。たとえば、自動リフレッシュ間隔が10秒(10,000ミリ秒)に設定されたREADONLYキャッシュ・グループtestcacheがあるとします。

自動リフレッシュが開始されると、サポート・ログには次のように表示されます。

15:43:33.96 Info: CAC: 5264: TT47118-5264-5676-refresh03918: Starting autorefresh
number 43 for interval 10000ms

メッセージに含まれる情報は次のとおりです。

- メッセージ番号: TT47118

- タイムスタンプ(15:43:33.96)

- キャッシュ・エージェント・プロセスID(5264)

- スレッドID(5676)

メッセージ番号は、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』で参照できます。たとえば、上記のログ・メッセージで、TT47118のエラー・メッセージ番号は47118です。

自動リフレッシュ番号は特定の時間隔に対してのみ一意であるため、スレッドIDは重要です。特定の自動リフレッシュ操作を追跡する際は、スレッドIDと自動リフレッシュ番号の両方を確認するようにしてください。

サポート・ログには、ttCacheAutorefreshStatsGetプロシージャと同様の情報をレポートする長いメッセージが含まれています。108544行がこの自動リフレッシュ間隔で更新されたこと、およびキャッシュ・エージェントの開始後、1815448行が更新されていることを示しています。キャッシュ・グループには表が1つしかないため、このメッセージ内の行の総数およびルート表の行の総数は同じになります。Numberは、自動リフレッシュ番号を表します。時間はすべてミリ秒単位で表現されます。

15:43:51.81 Info: CAC: 5264: TT47087-5264-5676-refresh04387: Cache agent
refreshed cache group USER1.TESTCACHE: Number - 43, Duration - 13550, NumRows -
108544, NumRootTblRows - 108544, NumOracleBytes - 759808, queryExecDuration -
230, queryFetchDuration - 1030, ttApplyDuration - 12290, totalNumRows - 1815448,
totalNumRootTblRows - 1815448, totalNumOracleBytes - 11911540, totalDuration -
160020

追加メッセージに、自動リフレッシュ操作が正常に完了したことが示されます。

15:43:51.81 Info: CAC: 5264: TT47119-5264-5676-refresh04449: Autorefresh
number 43 finished for interval 10000ms successfully
15:43:51.81 Info: CAC: 5264: TT47119-5264-5676-fresher01619: Autorefresh number
43 succeeded for interval 10000 milliseconds

タイムスタンプを調べ、自動リフレッシュが予想どおり処理されているかどうかを確認します。

サポート・ログの場所の設定に関する情報については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモン・オプションの管理に関する説明を参照してください。

自動リフレッシュの失敗の診断

ttCacheAutorefreshStatsGetで自動リフレッシュ操作のステータスがFailedと表示された場合は、ttCacheAutorefreshStatsGetの出力に表示された番号の自動リフレッシュ操作に関連するメッセージをサポート・ログで確認します。自動リフレッシュ操作の開始後に発生したエラーがないかどうかを探します。

例3-3 ttCacheAutorefreshStatsGet出力に自動リフレッシュの失敗が示されている場合

ttCacheAutorefreshStatsGetの出力の次の行が、失敗した自動リフレッシュ操作を示しています。

< 1164260, 2007-08-01 14:56:36.000000, 959350, 9, 0, 0, 0, 0, 0, 0, 0, 1, 7,
1, 50, Failed >

自動リフレッシュ番号は9です。

サポート・ログに、自動リフレッシュ番号9の開始メッセージが表示されています。

14:56:36.10 Info: CAC: 5988: TT47118-5988-4724-refresh03926: Starting
autorefresh number 9 for interval 15000ms

自動リフレッシュ番号9のスレッドIDは4724です。このスレッドIDを持つエラー・メッセージを検索します。

サポート・ログに次のメッセージが表示されています。

14:56:36.10 Info: CAC: 5988: TT47117-5988-4724-refresh03953: Autorefresh thread
for interval 15000ms is connected to instance inst1 on host host1. Server handle
231976252
14:56:36.12 Err : CAC: 5988: TT40018-5988-4724-refresh07567: TimesTen error
code:5901, msg The Oracle refresh log table, "USER2"."TT_06_81799_L", for base
table, USER2.READTAB2, cannot be found.
14:56:36.12 Info: CAC: 5988: TT47055-5988-4724-refresh05559: Autorefresh rolled
back.
14:56:36.12 Info: CAC: 5988: TT47119-5988-4724-refresh04458: Autorefresh number
9 finished for interval 15000ms with error.
14:56:36.12 Err : CAC: 5988: TT40035-5988-4724-fresher01606: Autorefresh number
9 failed for cache groups with interval 15000 ms after 10 retries.

スレッドID 4724のエラー・メッセージは、変更ログ表TT_06_81799_Lが欠落していることを示しています。この状況での対処方法については、「自動リフレッシュ時に指定した間隔でキャッシュがリフレッシュされない」の表を参照してください。

自動リフレッシュのパフォーマンス問題の診断

ttTraceMonユーティリティを使用すると、自動リフレッシュのパフォーマンス問題を診断できます。詳細は、「AUTOREFRESHトレース」を参照してください。

トレースの出力をファイルに行うと、TimesTenのトレース処理は、アプリケーションのパフォーマンスに大きく影響し、大量のディスク領域を消費します。診断が終了したら、トレースをデフォルト値にリセットしてください。

SNMPトラップによる自動リフレッシュの問題のアラート

SNMPトラップを有効化して、自動リフレッシュに問題が発生した場合にアラートが生成されるようにします。自動リフレッシュに関連するSNMPトラップは次の通りです。

- ttCacheAutoRefQueFullTrap

- ttCacheIncAutoRefFailedTrap

- ttCacheValidationErrorTrap

- ttCacheValidationWarnTrap

- ttCacheValidationAbortedTrap

『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップを使用した診断に関する説明を参照してください。

TimesTenキャッシュのパフォーマンスを最適化する

次の推奨事項を実行すると、TimesTen Cacheのパフォーマンスを最適化できる場合があります。

注意:
これらの推奨事項はどれも、パフォーマンス上のトレードオフがあるため、パフォーマンスを最適化できるとはかぎりません。ユーザー独自の構成環境に応じて、それぞれのパフォーマンス推奨事項を検討し、テストを実施してください。

- ALTER TABLE table_name CACHE文を実行し、Oracle Databaseに対して、TimesTen Cacheメタ表およびキャッシュ・グループ実表がSGAバッファ・キャッシュのKEEP領域に格納される必要があることを示すことで、これらの表をSGAに配置します。SGAにTimesTen Cache表を配置すると、リフレッシュが実行される場合にTimesTen Cacheリフレッシュ操作に必要な任意のデータブロックをSGA内で利用できる可能性が高くなり、ディスク読取りは行われなくなる可能性が高くなります。これによって、TimesTenキャッシュのリフレッシュ操作時に実行される物理ディスク読取りの時間が最小になります。

- dbms_shared_pool.keepプロシージャを使用して、共有プールにTimesTen Cacheトリガーを配置します。キャッシュ・グループ実表を頻繁には更新しないアプリケーションの共有プールにトリガーを配置すると、トリガーが再ロードや再解析の必要性がなくなります。トリガーが頻繁に実行され、常に共有プールに存在しているような揮発性の高い表では、これを行う必要はありません。

- パラレル問合せを有効化します。1000万以上の行を持つ大規模な実表の場合は、Oracle Databaseのパラレル問合せ機能の使用を検討してください。ログ表と実表の間で行う主結合問合せは、Oracle Databaseのパラレル問合せが処理されるように設計された問合せです。パラレル処理が有効な場合、パラレル問合せオプティマイザは、他のパラレル問合せのスレーブ・プロセスで同時に実行できるように元の問合せを分割できる問合せ計画を生成します。パラレル問合せを使用する際、ユーザーは、キャッシュ・グループ実表のデフォルトの並列度である(2*N)を割り当てる必要があります(「N」はシステムのCPUの数です)。次に、ユーザーの環境に最適な並列レベルを確認するための実験を行います。次に示すように様々な表構造の実表で試します。

- 表の作成時またはALTER TABLE PARALLELコマンドを使用して割り当てられるデフォルトの並列度を持つ標準的なヒープ表を使用します。表に対してNパーティションの主キー索引を構築します。

- 表の主キーまたは主キーの上位列(主キーが結合されている場合)のいずれかに基づいたパーティション・レンジ・キーを持つ、N通りにパーティション化された表構造を使用します。パーティションの数は、並列度に設定する必要があります。パーティションの数が同じローカル主キー索引を使用します。

- ハッシュ・キーとして主キーを使用し、ローカルのパーティション化された主キー索引、および並列度と同じ索引パーティションと表パーティションの両方を持つ、N通りにハッシュされたパーティション構造を使用します。ログ表のカーディナリティは、パーティション化されたログ表にパフォーマンス上のメリットがもたらされるほど十分に大きくならないため、ログ表はパーティション化されている必要があります。さらに、ログ表の主キー列の値が増加し続けている場合、レンジ・パーティションは使用できません。

Oracle Database表の大規模なバッチ・ジョブで発生するパフォーマンスおよびメモリーの問題を回避する

お客様は、増分自動リフレッシュを設定した読取り専用のキャッシュ・グループにキャッシュされているOracle Database表に対して、月末または年末に大規模なバッチ・ジョブを実行する場合があります。その場合、事前に予防策を行わないと、自動リフレッシュ操作やレプリケーションにパフォーマンスやメモリーの問題が発生する可能性があります。

この項で説明するタスクは、次のTimesTen Cache構成のコンポーネントではサポートされません。

- キャッシュ・グリッドにない読取り専用キャッシュ・グループまたはアクティブ・スタンドバイ・ペアによってレプリケートされていない読取り専用キャッシュ・グループ

- キャッシュ・グリッド

- アクティブ・スタンドバイ・ペア・レプリケーション

- 戻りサービスが指定されたアクティブ・スタンドバイ・ペア

- 障害時リカバリ・サブスクライバが指定されたアクティブ・スタンドバイ・ペア

- 物理的な同期Oracle Data Guard

- Oracle RAC

キャッシュされたOracle Database表で大規模なバッチ・ジョブを実行する必要がある場合、次のタスクを実行します。

1. バッチ・ジョブの影響を受けるAUTOREFRESH属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSEDに設定します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。

ALTER CACHE GROUP sampecg SET AUTOREFRESH STATE PAUSED;
COMMIT;

2. バッチ・ジョブの影響を直接受けないAUTOREFRESH属性を持つキャッシュ・グループの自動リフレッシュの状態をPAUSEDに設定します。これにより、バッチ処理中のデータは一貫性のあるビューになります。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。

3. キャッシュされたOracle Database表でバッチ・ジョブを実行します。

4. すべての自動リフレッシュ変更ログ記録が有効なログ順序番号(logseq)に割り当てられていることを確認します。cacheInfo.sqlスクリプトをコールします。

% cd TimesTen_install_dir/oraclescripts
% sqlplus cacheuser/oracle
SQL> @cacheInfo

有効なログ順序番号でマークされていない更新の数を確認します。自動リフレッシュが一時停止の状態であるキャッシュ・グルーブのすべての表で、その数が0(ゼロ)または小さい(100未満)のが理想的です。次の例を想定してください。

*************Autorefresh Objects Information  ***************
Host name: host1
Timesten datastore name: /scratch/ttuser/ds/mydsn
Cache table name: TTUSER.NOTAFFECTED
Change log table name: tt_05_460491_L
Number of rows in change log table: 1
Maximum logseq on the change log table: 1
Timesten has autorefreshed updates up to logseq: 1
Number of updates waiting to be autorefreshed: 0
Number of updates that has not been marked with a valid logseq: 0
****************************
Host name: host2
Timesten datastore name: /scratch/ttuser/ds/mydsn
Cache table name: TTUSER.AFFECTED
Change log table name: tt_05_460489_L
Number of rows in change log table: 100
Maximum logseq on the change log table: 213
Timesten has autorefreshed updates up to logseq: 213
Number of updates waiting to be autorefreshed: 10000
Number of updates that has not been marked with a valid logseq: 0
****************************

5. 構成にアクティブ・スタンバイ・ペア・グリッド・メンバーが含まれている場合は、スタンバイの状態が、すべてのスタンバイ・ノードでPAUSEDに設定されていることを確認してください。ttIsql cachegroupsコマンドを使用します。

6. 手順1で変更された各キャッシュ・グループについて、パラレル・モードでキャッシュ・グルーブを手動でリフレッシュします。トランザクション・サイズ(一度にコミットされる行数)および並列度に適切な値を選択します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。

REFRESH CACHE GROUP samplecg
COMMIT EVERY n ROWS PARALLEL m;
COMMIT;

この操作は、自動更新リフレッシュの状態を自動的にONにリセットします。

7. 手順2で変更された各キャッシュ・グループについて、自動リフレッシュの状態をONに設定します。このタスクを、各スタンドアロン・キャッシュ・グリッド・ノードおよびアクティブ・スタンバイ・ペアのグリッド・メンバーに実行します。次に例を示します。

ALTER CACHE GROUP sampecg2 SET AUTOREFRESH ON;
COMMIT;

自動リフレッシュ・ログ表の索引を定期的に結合することをお薦めします。『Oracle Database SQL言語リファレンス』のALTER INDEXに関する説明を参照してください。

自動リフレッシュ時に指定した間隔でキャッシュがリフレッシュされない

自動リフレッシュの問題について、考えられる原因を次の表に示します。

考えられる原因

対処

キャッシュ・エージェントがキャッシュ管理ユーザーによって起動されていない。

『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・エージェントの起動に関する項を参照して、キャッシュ・エージェントの起動時に、キャッシュ管理ユーザーIDおよびパスワードを指定する。『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheStartに関する項および『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のTimesTenデータベースでのキャッシュ管理ユーザー名およびパスワードの設定に関する項も参照。

実表のオブジェクトIDが変更された

後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。

自動リフレッシュ・トリガーが有効でない。

後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。

TT_version_USER_COUNT表に記録されている現在のログ順序番号が、自動リフレッシュ・ログ表の最大ログ順序番号より小さい。

後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。

TT_version_USER_COUNT表に、すべてのアクティブな自動リフレッシュ表に対してusercount > 0である行がない。

後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。

変更ログ表が空である

後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。

ユーザー・カウントが0(ゼロ)未満か、またはTT_version_USER_COUNTログ順序が異常である。

後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。

キャッシュされた表に関連付けられている自動リフレッシュ・ログ表、トリガーまたは順序が存在しないか、有効でない

キャッシュ・エージェントが、正しいキャッシュ管理ユーザーIDで起動されたかどうかを確認する。キャッシュ管理ユーザーIDが正しい場合は、後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」の手順に従う。
ユーザー・エラー・ログで、致命的な異常についてのメッセージを確認する。これには、Oracle Databaseオブジェクトの破損または欠落が示されている。

TT_version_USER_COUNT表がない

キャッシュ・エージェントが、正しいキャッシュ管理ユーザーIDで起動されたかどうかを確認する。キャッシュ管理ユーザーIDが正しい場合は、後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」の手順に従う。
ユーザー・エラー・ログで、致命的な異常についてのメッセージを確認する。これには、Oracle Databaseオブジェクトの破損または欠落が示されている。

TT_version_USER_COUNT表に記録されている現在のログ順序番号が変更され、ブックマークと異なり、関連付けられているキャッシュ表が次にコミットされる自動リフレッシュでリフレッシュされない。

キャッシュ・エージェントを再起動する。問題が解決されない場合は、後述の「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」の手順に従う。

自動リフレッシュのモード、状態または間隔を変更した時に、自動リフレッシュが同時に実行された場合、同一の表がそれぞれのアクションにより変更されるため、ロック・タイムアウトが発生する可能性がある。

自動リフレッシュのモード、状態または間隔を変更する前に、キャッシュ・エージェントを停止する。「自動リフレッシュ・モード、状態または間隔の変更時にロック・タイムアウト状態を回避する」を参照。

リソースに問題がある。

キャッシュ・エージェントを再起動する。

自動リフレッシュ状態をリセットする

増分自動リフレッシュは、Oracle Database実表でTRUNCATE文が使用されている場合は、正しく動作しません。Oracle Database実表でTRUNCATE文が使用されている場合は、ALTER CACHE GROUP文を使用して自動リフレッシュをリセットし、自動リフレッシュの状態をOFFに設定してから、別のALTER CACHE GROUP文で自動リフレッシュの状態をONに戻します。

自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする

自動リフレッシュで使用するOracle Databaseオブジェクトが問題の原因と特定できる、または可能性がある場合、次の手順を実行してOracle Databaseオブジェクトを再作成します。

1. 問題のキャッシュ表があるすべてのデータベース上のすべてのキャッシュ・グループについて、ALTER CACHE GROUPを使用して自動リフレッシュの状態をOFFにリセットします。

ALTER CACHE GROUP cache_group_name SET AUTOREFRESH STATE OFF;

2. 対象となるすべてのデータベース上のすべてのキャッシュ・エージェントを停止します。

3. キャッシュ・グループ内の各表について、ユーザー・カウントが0(ゼロ)かどうかを確認します。
Oracle Databaseで、次の文を実行します。

SELECT usercount FROM autorefresh_id.tt_version_user_count
WHERE tablename ='owner.tablename';

カウントが0(ゼロ)でない場合は、次の文を実行して0(ゼロ)に設定します。

UPDATE autorefresh_id.tt_version_user_count SET usercount = 0
WHERE tablename ='owner.tablename';

4. いずれかのキャッシュ・エージェントを起動します。そのキャッシュ・エージェントによって、クリーンアップ操作が実行されます。クリーンアップが終了すると、次のメッセージがサポート・ログに表示されます。

Cleanup of the Oracle objects completed

5. キャッシュ・エージェントによるクリーンアップが終了したら、ALTER CACHE GROUPを使用して自動リフレッシュの状態をONに戻します。

ALTER CACHE GROUP cache_group_name SET AUTOREFRESH STATE ON;

6. 他のすべてのキャッシュ・エージェントを起動します。

7. すべてのデータベース上の問題のキャッシュ・グループすべてについて、ALTER CACHE GROUPを使用して自動リフレッシュの状態をONにリセットします。

自動リフレッシュ・モード、状態または間隔の変更時にロック・タイムアウト状態を回避する

ALTER CACHE GROUP文を使用して自動リフレッシュのモード、状態または間隔を変更するのと同時に、スケジュール済自動リフレッシュが開始されると(自動リフレッシュ間隔によるスケジュール)、ロック・タイムアウトが発生する場合があります。

- 自動リフレッシュは、キャッシュ表およびSYS.CACHE_GROUP表内の行をロックします。

- ALTER CACHE GROUP SET AUTOREFRESH文が、SYS.CACHE_GROUP表内のキャッシュ・グル・ステートを更新します。

これにより、次のエラーが発生します。

Error TT6003: Lock request denied because of time-out.

次の回避策を実行します。

- ttLockWait組込みプロシージャを使用して、ロック・タイムアウトを増加します。

- ALTER CACHE GROUP SET AUTOREFRESH文を実行して、自動リフレッシュのモード、状態または間隔を変更する前に、キャッシュ・エージェントを停止します。次の例では、自動リフレッシュ状態を停止する設定を説明します。

1. キャッシュ・エージェントを停止します。

Command> call ttCacheStop;

2. 自動リフレッシュ状態を、目的の状態に変更します。この例では、自動リフレッシュ状態を停止するように設定します。

Command> ALTER CACHE GROUP new_customers SET AUTOREFRESH STATE PAUSED;

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

Command> call ttCacheStart;

ALTER CACHE GROUPの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER CACHE GROUPに関する説明を参照してください。ttLockWait組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttLockWaitに関する項を参照してください。

増分自動リフレッシュが進行中ではない

増分自動リフレッシュが進行していない場合は、次のことを確認します。

- 自動リフレッシュの状態がONになっているかどうか。

- キャッシュ・エージェントが稼働しているかどうか。

サポート・ログで、次の表に記載されている状態を調べます。

最初のヘッダー・セルに表の概要が示されています。

状態

対処

Oracle Databaseサーバー接続エラーまたは警告

接続の問題の解決の詳細は、「クライアント/サーバーの問題のトラブルシューティング」を参照。

TimesTenでのロック・タイムアウト・エラーまたは警告

このことは、通常、キャッシュ・グループに対するオープンなDDLトランザクションが原因で発生する。自動リフレッシュが必要なロックを取得できるようにDDLトランザクションをコミットする。

TimesTenの不十分な永続メモリー領域エラー

PermSizeの値を大きくする。

自動リフレッシュOracle Databaseオブジェクトの検証エラーまたは警告

「自動リフレッシュOracle Databaseオブジェクトをリカバリしてリセットする」を参照。

キャッシュ・エージェントの予期せぬ終了

TimesTenサポート・サービスに連絡してください。

メイン・デーモン・ディレクトリ内にコア・ファイルがある

TimesTenサポート・サービスに連絡してください。

増分自動リフレッシュが完全リフレッシュになることに関する警告

「増分自動リフレッシュが完全自動リフレッシュになる」を参照。

自動リフレッシュが長時間経っても完了しないことを示す警告

前回の自動リフレッシュ以降に数多くのトランザクションが発生した場合は、自動リフレッシュ・トランザクションに長時間かかることがある。
注意: 同じ自動リフレッシュ間隔を持つキャッシュ・グループは、1つのトランザクションで自動リフレッシュされる。

自動リフレッシュOracle Databaseオブジェクトの有効化

キャッシュ・エージェントは、自動リフレッシュが進行できるように、Oracle Databaseオブジェクトが存在するかどうか、およびOracleオブジェクトが有効かどうかを自動的に検証します。通常の操作では、ユーザー・エラー・ログにオブジェクトの検証エラーまたは警告が含まれることはありません。次のいずれかの状態が発生した場合を除いて、オブジェクトの検証エラーが見つかったときは、TimesTenテクニカル・サポートに連絡してください。

- DROP CACHE GROUP文を使用せずに、TimesTenデータベースを破棄した。

- カスタマ・アプリケーションによって、直接Oracle Databaseにあるオブジェクトが不注意に変更された。

- Oracle Databaseの実表に対してDDL操作を行う。これにより、自動リフレッシュ操作を制御するトリガーが無効になる。

上記のいずれかの状態が発生した場合は、キャッシュ・グループを再作成する必要があります。

増分自動リフレッシュが完全自動リフレッシュになる

キャッシュ管理ユーザーの表領域が一杯になると、増分自動リフレッシュが完全自動リフレッシュになる場合があります。

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

- 増分自動リフレッシュが完全自動リフレッシュになっている場合の検出

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

- キャッシュ管理ユーザーの表領域が一杯になった場合の診断

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

- キャッシュ管理の表領域が一杯になった場合の考慮事項

増分自動リフレッシュが完全自動リフレッシュになっている場合の検出

増分自動リフレッシュが完全自動リフレッシュになっていないかどうかは、いくつかの方法で検出できます。

- サポート・ログで、完全自動リフレッシュ操作が行われていることを示すメッセージを確認します。次に例を示します。

2007-08-08 08:06:51.35 Warn: CAC: 11384: TT47166-11384-1087179104-lMarker01403:
A full autorefresh will be performed for Incremental autorefresh table
USER1.READTAB because change log table TT_06_55555_L on Oracle has been
truncated.

- ttCacheAutorefreshStatsGetプロシージャを使用します。

- 自動リフレッシュが通常より長い時間InProgressの状態である場合、完全自動リフレッシュが行われている可能性があります。

- 自動リフレッシュされた行数(autoRefNumRows)が通常よりはるかに多い場合、完全自動リフレッシュが行われた可能性があります。

サポート・ログで、完全自動リフレッシュについてのメッセージを確認してください。

- SNMPトラップが有効になっている場合、SNMPトラップttCacheRecoveryAutorefreshTrapによって完全自動リフレッシュが通知されます。

キャッシュ管理ユーザーの表領域の理解

キャッシュ管理ユーザー用に個別の表領域を作成することを強くお薦めします。この表領域は、キャッシュ管理ユーザーのデフォルトの表領域として使用されます。この表領域には、それぞれのOracle Database表に対する自動リフレッシュ・トリガー、それぞれのOracle Database表に対する変更ログ表、およびそれぞれのキャッシュ管理ユーザーでTimesTenが必要とするその他のオブジェクトが含まれます。個別の表領域を指定しない場合、これらのオブジェクトはOracle Databaseのシステム表領域に配置されます。

Oracle Databaseでキャッシュ管理ユーザーを作成する時に、表領域を指定します。また、Oracle DatabaseのALTER USER文のDEFAULT TABLESPACE句を使用してユーザーを作成した後も表領域を指定できます。

キャッシュされた各Oracle Database表の変更ログ表は、キャッシュ管理ユーザーの表領域に存在します。Oracle Database表を更新するたびに、1列(変更ログ・レコード)が該当するOracle Database表の変更ログ表に挿入されます。変更ログ・レコードのサイズ(バイト)は次のようになります。

size of change log record = size of primary key on Oracle table + 250

変更ログ表のレコード数は、Oracle Database表での更新率、およびTimesTenでの自動リフレッシュ間隔によって異なります。関連付けられているOracle Database表をキャッシュしているすべてのデータベースに適用済の変更ログ・レコードは、20秒ごとにTimesTenによって削除されます。

変更ログが削除されると、次のようなメッセージがサポート・ログに表示されます。

16:32:26.73 Info: CAC: 5652: TT47112-5652-4756-ogTblGC01036: Garbage collector
deleted 1 rows from TT_06_383270_L where logseq < 1

キャッシュ管理ユーザーの表領域が一杯になった場合に発生する状況を管理するオプションがあります。「キャッシュ管理の表領域が一杯になった場合の考慮事項」を参照してください。

キャッシュ管理ユーザーの表領域が一杯になった場合の診断

キャッシュ管理ユーザーの表領域が一杯になった場合は、次の状態を確認します。

- 自動リフレッシュの状態がPAUSEDに設定されていないかどうか。状態がPAUSEDの場合、変更ログ・レコードは蓄積されます。

- 作成したキャッシュ・グループをロードしているかどうか。キャッシュ・グループ作成のデフォルトの自動リフレッシュの状態はPAUSEDです。

- キャッシュ・グループを作成中かどうか、またはデータベースをレプリケート中かどうか。これらの両方の処理は、変更ログ表のクリーンアップ処理を一時的に停止します。

- TimesTenデータベース上のすべてのキャッシュ・エージェントが稼働中かどうか。キャッシュ・エージェントが稼働していない場合、変更ログ・レコードは蓄積されます。

- データベース内の自動リフレッシュ・キャッシュ・グループを削除せずにデータベースを破棄していないかどうか。このようなデータベースは、次のような場合に発生します。

- ttDestroy -forceでデータベースを破棄した場合。

- アプリケーションが、1に設定されたOverwrite接続属性を持つデータベースに接続されているが、古いデータベースにあったキャッシュ・グルーブが再生成されていない場合。

データベースがまだ存在している場合は、破棄されたデータベースに接続してキャッシュ・グループを削除してください。

それぞれのキャッシュされたOracle Database表に対してcacheInfo.sqlスクリプトを使用して、変更ログ表の大きさを特定します。出力を調べて、データベースがまだ使用中かどうかを確認します。詳細は、「変更ログ表の情報の表示」を参照してください。

データベースがまだ使用中である場合は、キャッシュ・エージェントが稼働していることを確認します。

TimesTenでの自動リフレッシュの処理状況を、変更ログ表の最大ログ順序番号と比較します。TimesTenの方が遅れている場合は、ttCacheAutorefreshStatsGetプロシージャをコールして、自動リフレッシュ操作が正常に行われているかどうかを確認します。詳細は、「ttCacheAutorefreshStatsGetプロシージャの使用」を参照してください。

ステータスが通常より長い時間InProgressであるように思われる場合は、「自動リフレッシュのパフォーマンスが悪い」を参照してください。

場合によっては、自動リフレッシュ間隔を減らすか、キャッシュ管理ユーザーの表領域のサイズを大きくする必要があります。

キャッシュ管理ユーザーの表領域が一杯になった場合に発生する状況を管理するオプションがあります。後述の「キャッシュ管理の表領域が一杯になった場合の考慮事項」を参照してください。

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

キャッシュ管理ユーザーの表領域を監視するには、Oracle Enterprise Managerアラートを使用するか、またはTimesTen表領域しきい値パラメータを設定します。

キャッシュ・エージェントは、表領域の使用量を定期的に監視し、使用量が指定したしきい値を超えたときに警告を発行するように構成できます。ttCacheConfig組込みプロシージャのTblspaceThresholdパラメータを使用して表領域のしきい値の割合を設定します。たとえば、TblspaceThresholdを80に設定した場合、表領域の使用量が80%を超えると警告が発行されます。

- しきい値が0(ゼロ)に設定されている場合、警告は発行されません。これがデフォルトです。

- しきい値が1から99の間に設定されている場合、表領域のしきい値がその数値を超えると警告が発行されます。

- しきい値が100に設定されている場合、表領域が一杯になると警告が発行されます。

たとえば、表領域の使用量が80%を超えると発行されるように警告を構成するには、次の操作を実行します。

call ttCacheConfig('TblspaceThreshold',,,'80');

ttCacheConfig組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する項を参照してください。

キャッシュ管理の表領域が一杯になった場合の考慮事項

TimesTenデータベースにキャッシュされたOracle Database表を使用する場合は、増分自動リフレッシュを使用するようにOracle Database表を構成できます。これらの表では、キャッシュ管理ユーザーの表領域が一杯になった場合に発生する状況を次のいずれかに指定できます。

- DMLを実行したアプリケーションが失敗する。これがデフォルトです。
表領域の完全リカバリがNoneに設定される。アプリケーションは、表領域が一杯になるとOracle Databaseから「Out of Tablespace」エラーを受信します。その時点で、アプリケーションは、トランザクションをロールバックする必要があります。

ttCacheConfig組込みプロシージャでParamパラメータをTblSpaceFullRecovery、ValueパラメータをNoneに設定すると、表領域の完全リカバリがNoneに設定されます。たとえば、次の例では、terryが所有するemployees表のParamをTblSpaceFullRecovery、ValueをNoneに設定します。

call ttCacheConfig('TblSpaceFullRecovery','terry', 'employees','None');

- 変更ログ表を切り捨てて領域を解放すると、完全自動リフレッシュが実行されます。
キャッシュ管理ユーザーの表領域が一杯になっても、自動リフレッシュによってキャッシュされたOracle Database表でDML文を実行しているすべてのアプリケーションが続行されます。トリガーが実行され、既存の変更ログ・レコードを削除して、新しい変更ログ・レコード用に領域を開放します。これによって、増分自動リフレッシュ・モードが構成されたキャッシュ・グループに対して完全自動リフレッシュを実行できます。ただし、Oracle Database表が増分自動リフレッシュ用に構成されていない場合、トリガーは実行されません。

アプリケーションを続行し、アプリケーションで自動リフレッシュを実行できるようにする操作を設定するには、ttCacheConfigプロシージャでParamパラメータをTblSpaceFullRecovery、ValueパラメータをReloadに設定します。ユーザーには、自動リフレッシュが完了するまで失効データが表示されます。

ただし、ユーザーが値Reloadを指定してキャッシュ構成パラメータTblSpaceFullRecoveryを設定しても、索引が増大している場合はその索引を処理するための十分な空きを表領域に用意できないことがあります。変更ログ表から行を削除することでは、変更ログ表の索引用に十分な領域が開放されない場合があります。索引の増大が急激なため、表領域全体が索引に使用され、変更ログ表をパージしても効果がない状況になると、ユーザーのアプリケーションは次のエラーを受信する可能性があります。

ORA-01654: unable to extend index <index> by 128 in tablespace <tblspace>

ttCacheConfig組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する項を参照してください。

自動リフレッシュのパフォーマンスが悪い

自動リフレッシュのパフォーマンスの悪化は、通常、大規模な自動リフレッシュ操作が原因です。ttCacheAutorefreshStatsGetプロシージャを使用して、自動リフレッシュの経過時間を調べ、ステータスが長時間InProgressのままになっていないかどうかを確認します。

大規模な自動リフレッシュ操作が行われる可能性のある要因は、次のとおりです。

- 増分自動リフレッシュが完全自動リフレッシュになる

- レスポンスがないTimesTenデータベースまたは停止したTimesTenデータベースによる自動リフレッシュのパフォーマンスの低下

- リソースにおける自動リフレッシュ・キャッシュ・グループ・リフレッシュの待機時間が長すぎる

- 変更ログや実表が異常に大きいと、自動リフレッシュのパフォーマンスが低下する

- 断片化した自動リフレッシュの変更ログ表領域

- 自動リフレッシュ間隔が小さいと、パフォーマンスが低下する

- 自動リフレッシュ間隔が大きい

- 同じ時間隔で処理されるキャッシュ・グループの数が多い

- Oracle Database表の変更頻度が高い

- キャッシュ・グループに含まれる子表の世代の数

- キャッシュされたOracle Database表の列の数

- キャッシュされたOracle Database表の列の大きさ

AUTOREFRESHトレースを有効にして、自動リフレッシュのパフォーマンス問題を診断します。詳細は、「AUTOREFRESHトレース」を参照してください。

レスポンスがないTimesTenデータベースまたは停止したTimesTenデータベースによる自動リフレッシュのパフォーマンスの低下

注意:
TimesTenキャッシュ・グループの自動リカバリは、AUTOREFRESHキャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループにのみ適用されます。この項で対象としている自動リフレッシュ・キャッシュ・グループはすべて、AUTOREFRESHキャッシュ・グループ属性を使用する読取り専用キャッシュ・グループおよびユーザー管理キャッシュ・グループを指しています。

自動リフレッシュ・キャッシュ・グループを含んでいるすべてのTimesTenデータベースが破棄されているか、または使用されていない場合でも、TimesTenはキャッシュ・エージェントが実行されていないTimesTenデータベースに対して、Oracle Database表への自動リフレッシュによる変更の追跡を続行します。これによって、アクティブなTimesTenのデータベース内のキャッシュ・グループへの自動リフレッシュが遅くなります。

キャッシュ・エージェントは、データベースからのレスポンスがない状態かどうか、またはデータベースが使用されていない状態かどうかの検出を行います。停止したTimesTenデータベースのリカバリを行うかどうか、および行う場合の方法を指定できます。ただし、すべてのOracle Databaseオブジェクトが削除されている場合、TimesTenデータベースをリカバリすることはできません。

次の項では、アクティブでないTimesTenデータベースで自動リフレッシュのパフォーマンスが低下しないようにする方法について説明します。

- キャッシュされたTimesTenデータベースのタイムアウトの設定

- 特定のキャッシュ・グループに対するリカバリ方法の構成

キャッシュされたTimesTenデータベースのタイムアウトの設定

特定のタイムアウト期間内にキャッシュ・エージェントがOracle Databaseサーバーと通信しなかった場合に、停止中および更新を受け入れないというマークをデータベースに付けるようにTimesTenに指示できます。

ttCacheConfig組込みプロシージャのAgentTimeOutパラメータを使用して、TimesTenデータベースのタイムアウトおよび各自動リフレッシュ・キャッシュ・グループのリカバリ方法を設定します。タイムアウト値は、同じキャッシュ管理ユーザーを使用するすべてのTimesTenデータベースに適用されます。タイムアウト値は、最初の接続時にTimesTenデータベースをメモリーにロードしてキャッシュ・エージェントを開始するためにかかる時間より長く設定する必要があります。そうしないと、TimesTenデータベースは誤って停止中とマークされます。TimesTenインスタンスのすべての計画メンテナンスで、AgentTimeOutの値を一時的に0(ゼロ)に設定して、タイムアウトを無効にすることができます。ttCacheConfig組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheConfigに関する項を参照してください。

たとえば、次の例では、TimesTenデータベースのタイムアウト値を6000秒(100分)に設定します。キャッシュ・エージェントがOracle Databaseサーバーに100分以内に接続しなかった場合、TimesTenデータベースは停止中とマークされます。

ttIsql> call ttCacheConfig('AgentTimeOut',,,'6000');

特定のキャッシュ・グループに対するリカバリ方法の構成

TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループがOracle Databaseと同期化されていない場合は、TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループをリカバリすることができます。同期が存在しない場合、Oracle Database表の更新は、対応するTimesTenキャッシュ表に自動的にはリフレッシュされません。

ttCacheConfig組込みプロシージャのDeadDbRecoveryパラメータを構成して、TimesTenデータベースおよびすべての自動リフレッシュ・キャッシュ・グループの同期のリカバリ方法を指定することができます。DeadDbRecoveryの設定は、同じキャッシュ管理ユーザーを使用するすべてのTimesTenデータベースに適用されます。TimesTenでデータベースおよびすべての自動リフレッシュ・キャッシュ・グループをリカバリする方法を指定するには、DeadDbRecoveryパラメータをNormal、ManualまたはNoneに設定します。DeadDbRecoveryの設定は、同じキャッシュ管理ユーザーを使用するすべてのTimesTenデータベースに適用されます。TimesTenでデータベースおよびその自動リフレッシュ・キャッシュ・グループのリカバリが行われている間、TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループのリカバリ・ステータスを示す、これらの各エンティティの自動リフレッシュのステータスが表示されます。TimesTenデータベースの自動リフレッシュのステータスは、Alive、DeadまたはRecoveringになります。自動リフレッシュ・キャッシュ・グループの自動リフレッシュのステータスは、OK、DeadまたはRecoveringになります。TimesTenデータベースのステータスの変更は、自動リフレッシュ・キャッシュ・グループのステータスの変更に次のようにリンクされています。

- リカバリ方法がNormalに設定されている場合にTimesTenが自動リフレッシュ・キャッシュ・グループに対して完全自動リフレッシュを開始すると、キャッシュ・グループのステータスはRecoveringに設定され、データベースのステータスもRecoveringに設定されます。

- すべての自動リフレッシュ・キャッシュ・グループがOKにリカバリされた場合または削除された場合にのみ、TimesTenデータベースのステータスはAliveに設定されます。

- データベースのステータスがDeadに設定されると、すべての自動リフレッシュ・キャッシュ・グループもDeadに設定されます。

注意:
ttCacheDbCgStatus組込みプロシージャ(『Oracle TimesTen In-Memory Databaseリファレンス』のttCacheDbCgStatusの項を参照)を使用して、TimesTenデータベースおよび自動リフレッシュ・キャッシュ・グループの自動リフレッシュのステータスを確認できます。

キャッシュ・エージェントとOracle Databaseサーバー間の接続が再度確立されるときに、TimesTenは、自動リフレッシュ・キャッシュ・グループのリカバリ方法を決定します。TimesTenは、ttCacheConfig組込みプロシージャのDeadDbRecoveryパラメータに構成されたリカバリ方法に従います。このパラメータは、次のいずれかに設定できます。

- Normal: これがデフォルト設定です。自動キャッシュ・グループは、それぞれ完全自動リフレッシュでリカバリされます。最初の完全リフレッシュの後、キャッシュ・グループはリカバリされ、増分自動リフレッシュが実行されます。
自動リフレッシュ間隔が同じ自動リフレッシュ・キャッシュ・グループではトランザクションの一貫性が保証されます。完全リフレッシュのため、増分リフレッシュほどパフォーマンスはよくありません。

自動リフレッシュを実行すると、ステータスはRecoveringに設定されます。完全自動リフレッシュが正常に完了すると、自動リフレッシュ・キャッシュ・グループのステータスはOKに設定されます。

- Manual: 自動リフレッシュ・キャッシュ・グループを手動でリフレッシュしてリカバリするか、またはキャッシュ・グループが動的な場合はアンロードする必要があります。

- None: 自動リフレッシュ・キャッシュ・グループは、TimesTen自動リフレッシュによってリカバリされることはありません。キャッシュ・グループをリカバリするには、キャッシュ・グループを削除して再作成します。

データベースのステータスは、最初の自動リフレッシュ・キャッシュ・グループのステータスが変更されると変更されます。リカバリ処理中の1つ以上のキャッシュ・グループが存在する場合、データベースのステータスはRecoveringに設定されます。すべてのキャッシュ・グループのリカバリが完了すると、TimesTenデータベースのステータスはAliveとマークされます。

次の例では、すべての自動リフレッシュ・キャッシュ・グループに対してDeadDbRecoveryパラメータをNormalに設定します。完全自動リフレッシュでTimesTenデータベースのすべての自動リフレッシュ・キャッシュ・グループがそれぞれリカバリされたら、停止したTimesTenデータベースがリカバリされます。

ttIsql> call ttCacheConfig('DeadDbRecovery',,,'Normal');

アクティブ・スタンドバイ・ペア・レプリケーション・スキームに関連するTimesTenデータベースにキャッシュ・グループが含まれている場合に、アクティブ・マスター・データベースの自動リフレッシュのステータスがDeadで、スタンドバイ・マスター・データベースの自動リフレッシュのステータスがAliveであると、スタンドバイ・マスターは自動的にはアクティブ・マスターの役割を果たしません。リカバリでは、キャッシュ・エージェントおよびレプリケーション・エージェントが実行されていることを手動で確認する必要があります。各状況の詳細は次のとおりです。

表3-2 アクティブ・スタンドバイ・レプリケーション・ペアに関連するキャッシュ・グループのリカバリ

DeadDbRecoveryの設定

アクティブ・マスター

スタンドバイ・マスター

実行される動作

Normal

Alive

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントがスタンドバイ・マスターで実行されていることを確認します。キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。これによって、データベースがRecoveringに設定されます。単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、スタンドバイ・マスターを失敗させて、新しいスタンドバイ・マスターをロールアウトすることもできます。

Normal

Dead

Alive

キャッシュ・エージェントおよびレプリケーション・エージェントがアクティブ・マスターで実行されていることを確認します。キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。これによって、データベースがRecoveringに設定されます。単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、アクティブ・マスターを失敗させて、スタンドバイ・マスターを新しいアクティブ・マスターとして切り替えてから、新しいスタンドバイ・マスターをロールアウトすることもできます。

Normal

Dead

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントが両方のマスターで実行されていることを確認します。キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。これによって、データベースがRecoveringに設定されます。単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、新しいマスターをロールアウトすることもできます。

手動

Alive

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントがスタンドバイ・マスターで実行されていることを確認します。キャッシュ・エージェントがOracle Databaseに接続できた時点で、すべての自動リフレッシュ・キャッシュ・グループのステータスがRecoveringに設定されます。これによって、データベースがRecoveringに設定されます。単一のキャッシュ・グループが自動リフレッシュを再開するための十分なデータを受信した時点で、ステータスはOKに設定されます。すべてのキャッシュ・グループがOKに設定された後で、データベースがAliveに設定されます。

また、スタンドバイ・マスターを失敗させて、新しいスタンドバイ・マスターをロールアウトすることもできます。

手動

Dead

Alive

キャッシュ・エージェントおよびレプリケーション・エージェントがアクティブ・マスターで実行されていることを確認します。手動リフレッシュを使用して、アクティブ・マスターの自動リフレッシュ・キャッシュ・グループをリカバリします。すべてのキャッシュ・グループがOKに設定されたか、または削除された後で、データベースがAliveに設定されます。

手動

Dead

Dead

キャッシュ・エージェントおよびレプリケーション・エージェントがアクティブ・マスターで実行されていることを確認します。手動リフレッシュを使用して、アクティブ・マスターの自動リフレッシュ・キャッシュ・グループをリカバリします。すべてのキャッシュ・グループがOKに設定されたか、または削除された後で、データベースがAliveに設定されます。その後、スタンドバイ・マスターに変更がレプリケートされます。

None

Alive

Dead

スタンドバイ・マスターをFailedとマークします。スタンドバイ・マスター・データベースに対してttDestroyユーティリティを実行します。アクティブ・マスターからttRepAdmin -duplicateユーティリティを実行して、アクティブ・マスターを複製します。

None

Dead

Alive

ttDestroyユーティリティを使用して、停止したアクティブ・マスターを削除します。ttRepAdmin -duplicateユーティリティでスタンドバイ・マスターを複製して、停止したアクティブ・マスターをリカバリします。

None

Dead

Dead

新しいマスターをロールアウトします。

リソースにおける自動リフレッシュ・キャッシュ・グループ・リフレッシュの待機時間が長すぎる

Oracle Databaseの更新時に、自動リフレッシュ・キャッシュ・グループ・リフレッシュ中のバッファ・ビジー・待機および行ロック待機が非常に長くなったり、デッドロックが発生する場合があり、これが原因でスループット・パフォーマンスが悪影響を受ける場合があります。自動リフレッシュログ表を使用するOracle Databaseの更新時に、複数のデッドロックが発生すると、サポート・ログに次のように表示される場合があります。

Oracle native error code = 60, msg = ORA-00060: deadlock detected while waiting
for resource
An error occurred while preparing or executing the following Oracle sql
statement: <some statement involving <cache admin user>.TT_##_#######_L  where
the # is some number>

INITRANSおよびFREELISTS設定を変更すると、自動リフレッシュ・ログ表への同時挿入および、これらの表の内部管理に影響を与えて、パフォーマンスを向上させることができます。これらの設定が適切に構成されていない場合、自動リフレッシュ中の実表を更新しているアプリケーションのスループット・パフォーマンスが低下します。

これらの設定は、次のように操作すると、自動または手動のいずれかで管理できます。

- FREELISTSを自動で管理するASSM表領域を使用する。

- Oracle Databaseの自動リフレッシュ・ログ表に対して、FREELISTSおよびINITRANSを手動で調整する。

次では、Oracle Databaseの自動リフレッシュ・ログ表のINITRANSおよびFREELISTSを手動で変更する方法の詳細を説明しています。

1. Oracle Databaseにある自動リフレッシュ・ログ表の名前を取得します。
キャッシュ管理ユーザーでログインし、自動リフレッシュの変更ログ表名およびその他のアイテムを表示しているSQL*PlusスクリプトcacheInfo.sqlを実行します。次の例では、太字で示されたtt_06_1216726_Lを、自動リフレッシュの変更ログ表名として表示しているcacheInfo.sqlスクリプトを実行します。

SQL> @cacheInfo.sql
*************Autorefresh Objects Information  ***************
Host name: syst
Timesten datastore name: /users/OracleCache/alone1
Cache table name: ORATT.ORDERS
Change log table name: tt_06_1216726_L
Number of rows in change log table: 1
Maximum logseq on the change log table: 2
Timesten has autorefreshed updates upto logseq: 1
Number of updates waiting to be autorefreshed: 1
Number of updates that has not been marked with a valid logseq: 0
****************************
Host name: consyst
Timesten datastore name: /users/OracleCache/alone1
Cache table name: ORATT.ITEMS
Change log table name: tt_06_1279699_L
Number of rows in change log table: 7
Maximum logseq on the change log table: 0
Timesten has autorefreshed updates upto logseq: 0
Number of updates waiting to be autorefreshed: 5
Number of updates that has not been marked with a valid logseq: 5
****************************

2. Oracle Databaseの表を手動で変更します。次の例では、前回の例の表を使用します。この例では、bar.tt_06_1279699_L表のINITRANSおよびFREELISTS設定を変更します。

注意:
これらの設定を構成するための正しい値については、『Oracle Database SQL言語リファレンス』のINITRANS整数およびFREELISTSに関する説明を参照してください。

ALTER TABLE BAR.TT_06_1279699_L INITRANS 10;
ALTER TABLE BAR.TT_06_1279699_L STORAGE(FREELISTS 5);
or
ALTER TABLE BAR.TT_06_1279699_L MOVE STORAGE(FREELISTS 5);

3. この表の索引のINITRANSおよびFREELISTS設定を変更します(この表の名前は自動リフレッシュ変更ログ表と同じで、末尾に「L」がもう1つ付きます)。たとえば、表bar.tt_06_1279699_Lの索引はbar.tt_06_1279699_LLです。
これらの設定は、自動リフレッシュ変更ログ表に設定した内容と同じである必要があります。

ALTER INDEX BAR.TT_06_1279699_LL INITRANS 10;
ALTER INDEX BAR.TT_06_1279699_LL STORAGE(FREELISTS 5);

変更ログや実表が異常に大きいと、自動リフレッシュのパフォーマンスが低下する

キャッシュ・スレッドSQLリフレッシュは、変更ログおよび実表を結合し、TimesTenにリフレッシュされる必要のある行を特定します。実表および変更ログ表のカーディナリティが大きくなると、この結合の実施に必要な時間が長くなります。変更ログ表または実表のいずれかが異常に大きい場合、パフォーマンスの低下が発生する場合があります。

次では、変更ログ表が異常に大きくなる場合のシナリオについて説明します。

- 変更ログ表が、複数のDSNのキャッシュ・グループすべてが同じ実表を参照している構成でパージされない場合、変更ログ表のサイズは無限に増大します。これらのグループの1つ以上のキャッシュ・エージェントを無効にすると、それらのDSNは適切にキャッシュ・グループをリフレッシュせず、変更ログ表はパージされません。複数のノードのうちのいずれかで自動リフレッシュの状態を一時停止にした場合、他のノードは遅くなる場合があります。

- 変更ログ表は、キャッシュ・エージェントの一部がシャットダウンした場合、異常に大きくなることがあります。この問題を解決するには、キャッシュを再起動して、すべてのキャッシュ・グループのリフレッシュ・サイクルが完了した後、パージされるバックログされたログのすべての行と、同期されるすべてのキャッシュ・グループをパージします。

- 変更ログ表は、変更ログ表に挿入された行がパージされない場合や、通常の処理ではパージできない場合に、異常に大きくなることがあります。これは、1つ以上のDSNが壊れているか、最初にキャッシュ・グループを削除せずに再構築すると発生します。Oracle Databaseのキャッシュ・グループ表には、キャッシュ・グループが壊れているかを示す情報はないため、これによりキャッシュ・グループ全体が破損します。この実表に関連付けられたすべてのキャッシュ・グループを再構築および再初期化してください。また、キャッシュ・グループと一緒にDSNを破壊しないでください。必ずキャッシュ・グループを削除してから、DSNを破壊します。

断片化した自動リフレッシュの変更ログ表領域

たとえば、TimesTenのシャットダウン時に変更ログが構築された結果として最高水位標が発生すると、変更ログ表は断片化される場合があります。変更ログ表が断片化された場合、次の操作を実行できます。

- 索引を結合します。これは、実表へのDMLの変更に影響を与えずに行うことができます。

- オンラインでセグメントの縮小を行います。これは、実表へのDMLの変更に影響を与えずに行うことができます。『Oracle Database管理者ガイド』の未使用領域の再利用に関する項を参照してください。

- 変更ログ表を再構築します。

無駄な領域がないか確認します。

1. Oracle DatabaseにcacheInfo.sqlスクリプトを実行して、変更ログ表の名前を確認します。

2. 変更ログ表のサイズを計算します。結果Aをコールします。この例では、変更ログ表の名前を適合させます。

SELECT table_name, ROUND((BLOCKS*8),2)||'KB' "size"
FROM user_tables
WHERE table_name LIKE 'TT_05_%_L";

3. 変更ログ表のデータのサイズを計算します。結果Bをコールします。この例では、変更ログ表の名前を適合させます。

SELECT table_name, ROUND((num_rows*avg_row_length/1024),2)|| 'KB' "size"
FROM user_tables
WHERE table_name LIKE 'TT_05_%_L';

4. (B/A)*100が50パーセントより大きい場合、少なくとも40パーセントの領域が無駄になっています(PCTFREEストレージ・パラメータが10に設定されていると仮定)。少なくとも40パーセントの領域が無駄になっている場合、変更ログ表の断片化が推奨されます。

変更ログ表を断片化するには、次の手順を実行します。

1. 自動リフレッシュの状態をPAUSEDに設定するようキャッシュ・グループを変更します。

2. 変更ログ表の行を一時表にコピーします。

3. 変更ログ表を切り捨てます。

4. 一時表から変更ログ表に行を挿入します。

5. 自動リフレッシュの状態をONに設定するようキャッシュ・グループを変更します。

自動リフレッシュ間隔が小さいと、パフォーマンスが低下します。

ログ表や実表の大規模なエントリーに対して数百ミリセカンドのような比較的短いリフレッシュ間隔を使用すると、キャッシュ・リフレッシュ操作は、予定されている次のリフレッシュ操作が開始するまでに完了しません。このような場合、現在の自動リフレッシュ・サイクルが終了すると、ログ表のエントリーのマークが解除されます。

このように、行にマークが付けられる時までに、同一の行を実表から次の自動リフレッシュ・サイクルのキャッシュ・グループにリフレッシュすることができます。リフレッシュにかかる時間がリフレッシュ間隔よりも大きくなっているか確認してください。リフレッシュ間隔を、冗長なリフレッシュが起きないような値に設定します。

制約にNOVALIDATEを宣言すると、グループの作成に失敗する

キャッシュ・グループを作成するOracle Database表が、主キー、UNIQUEまたはNOT NULL制約を持つ列にNOVALIDATEを宣言すると、キャッシュ・グループの作成は失敗します。

注意:
これは、外部キー制約にはあてはまりません。ただし、TimesTenは、一致する外部キーを、有効化されたVALIDATE状態にすることを推奨します。外部キー列を、有効化されたVALIDATE状態に変更すると、ワークロード・パフォーマンスに影響する場合があります。

TimesTenは、主キーのNOVALIDATEまたはNOT NULL表の列の定義を、NULLとして認識するため、キャッシュ・グループを作成する列として見なされません。したがって、Oracle Database表からキャッシュ・グループを作成する際に、主キーのすべての列、UNIQUEおよびNOT NULL列制約をVALIDATE状態で有効化する必要があります。

これらのうち1つ以上の制約を持つOracle Database表からキャッシュ・グループを作成すると、次のエラーが発生します。

5124: Autorefresh/propagate are not allowed on restricted cache group
5168: Restricted cache groups are deprecated
5120: No matching unique index with not null columns, unique key constraint
with not null columns, or primary key constraint on table EVENTLOG, cache
operations are restricted.

これらのエラーを受信した場合、SELECT文を実行して、Oracle Database表に既存のNOVALIDATE制約がないかを確認することができます。次のSELECT文を実行すると、MyTable表にある制約がすべて表示されます。

SQL> select constraint_name, constraint_type, validated, status from
all_constraints where table_name = 'MyTable';

CONSTRAINT_NAME                C VALIDATED     STATUS
------------------------------ - ------------- --------
REFID_CONSTRAINT               C VALIDATED     ENABLED
PKEY_CONSTRAINT                P NOT VALIDATED DISABLED

キャッシュ表の主キーとなる表の列がNOVALIDATEとして有効化されている場合、次の手順を実行して、列をVALIDATE状態に有効化します。

1. 主キー列に対してNOVALIDATE状態を有効化します。

SQL> alter table MyTable modify constraint PKEY_CONSTRAINT
enable novalidate;
Table altered.

SQL> select constraint_name, constraint_type, validated, status
from all_constraints where table_name = 'MyTable';

CONSTRAINT_NAME                C VALIDATED     STATUS
------------------------------ - ------------- --------
REFID_CONSTRAINT               C VALIDATED     ENABLED
PKEY_CONSTRAINT                P NOT VALIDATED ENABLED

2. 主キー列に対してVALIDATE状態を有効化します。

SQL> alter table MyTable modify constraint PKEY_CONSTRAINT validate;
Table altered.

SQL> select constraint_name, constraint_type, validated, status
from all_constraints where table_name = 'MyTable';

CONSTRAINT_NAME                C VALIDATED     STATUS
------------------------------ - ------------- --------
REFID_CONSTRAINT               C VALIDATED     ENABLED
PKEY_CONSTRAINT                P VALIDATED     ENABLED

DBMS_LOCKとのロック競合を表示するAWRレポート

Automated Workload Repository(AWR)レポートにDBMS_LOCKが表示された場合、ロック競合に関していくつか問題がある可能性があります。ただし、このDBMS_LOCK待機イベントは、AWRレポートでデータベースの時間消費が大きくなっていても、TimesTenキャッシュ・グリッドのアプリケーション・パフォーマンスには影響しません。この待機イベントは、別のデータベースの別のガベージ・コレクタ・セッションがすでにロックしたリソースを予約待ちしようとしているガベージ・コレクタ・セッションです。そのため、現在のガベージ・コレクタのみが待機します。ガベージ・コレクタ処理の待機は、他のガベージ・コレクタの処理を妨げますが、それ以外の処理を妨げることはありません。

たとえば、次では、AWRレポートの競合イベントを示しています。

AWR

Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
enq: UL - contention                  2,388       6,997   2930   72.0 Application

また、PERF AWRレポートの「SQL ordered by CPU Time」の項に表示されているように、ガベージ・コレクタには、非常に短いCPU時間が使用されています。

SQL ordered by CPU Time              DB/Inst: REM0LNX/REM  Snaps: 14976-14977
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100

CPU      Elapsed                  CPU per  % Total
Time (s)   Time (s)  Executions     Exec (s) DB Time    SQL Id
---------- ---------- ------------ ----------- ------- -------------
0      3,508          120        0.00    36.1 0mt5pk2501gph
Module: timestenorad@etcpro01.oracle.com (TNS V1-V3)
DECLARE v_lockHandle VARCHAR2(200); BEGIN dbms_lock.allocate_unique(
'ORATT$ORA_GC1_CACHEADMIN', v_lockHandle); :retval := dbms_lock.request(
v_lockHandle, dbms_lock.x_mode, 30, FALSE); END;
0      3,499          120        0.00    36.0 bb07h2a1v817x
Module: timestenorad@etcpro01.oracle.com (TNS V1-V3)
DECLARE v_lockHandle VARCHAR2(200); BEGIN dbms_lock.allocate_unique(
'ORATT$ORA_DDSMONITOR1_CACHEADMIN', v_lockHandle); :retval :=
dbms_lock.request(v_lockHandle, dbms_lock.x_mode, 30, FALSE); END;

4 レプリケーションのトラブルシューティング

この章の次の項は、データベースをレプリケートする時に発生する可能性がある問題の解決方法について説明します。

- レプリケーション・スキームを作成できない

- レプリケーション・スキームを変更できない

- レプリケーション・エージェントを起動または停止できない

- SNMPトラップを使用してレプリケーション・イベントを通知する

- レプリケーションが正しく機能しない

- レプリケーションからのレスポンスがない、ハングしている可能性がある

- レプリケーションまたはXLAのパフォーマンスが悪い

- ttRepAdmin使用時の問題

- 競合チェック時の問題

- パラレル・レプリケーションの問題

注意:
この章の例で示すとおり、レプリケーション・エージェント・デーモンからのエラー・ログは、REPでメッセージ内に指定されます。ttDaemonLogユーティリティのREPLICATIONコンポーネントを無効化しないかぎり、これらのメッセージは有効です。WindowsおよびUNIXのttDaemonLogオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDaemonLogに関する説明を参照してください。

レプリケーション・スキームを作成できない

この項では、CREATE REPLICATIONでレプリケーション・スキームを作成できないときに確認する事項を説明します。

考えられる原因

対処

ユーザーが、ADMIN権限を持っていない。

CREATE REPLICATIONまたはDROP REPLICATION文を使用するには、ADMIN権限が必要です。

データベース名、ホスト名または要素名が間違っている。

- CREATE REPLICATION文にタイプミスがないかどうか確認します。

- 「ホスト名の確認」を参照してください。

- 別名ではなく正式なホスト名を使用します。

- ホスト名は、システム上でhostnameコマンドによって返される値と一致している必要があります。また、レプリケーション・スキーム全体で一貫して使用されている必要があります。

ローカル・ホストがレプリケーション・スキームに含まれていない

レプリケーション・スキームに含めるホスト上にレプリケーション・スキームを作成します。

CREATE REPLICATION文で定義されているレプリケーション表が存在しない

レプリケーション・スキームに含まれる表の名前、所有者および列の定義は、マスター・データベースとサブスクライバ・データベースで同一である必要があります。CREATE TABLEを使用してデータベースに表を作成するか、ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx Cファンクションを使用してレプリケート対象のデータベース全体を複製します。

その他の問題がある。

『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のクラシック・レプリケーション・スキームの定義に関する項に記載されているプロシージャおよび要件を確認します。

レプリケーション・スキームを変更できない

この項では、ALTER REPLICATIONでレプリケーション・スキームを変更できないときに確認する事項を説明します。

考えられる原因

対処

ユーザーが、ADMIN権限を持っていない。

ALTER REPLICATION文を使用するには、ADMIN権限が必要です。

レプリケーション・エージェントがStart状態である。

ほとんどのALTER REPLICATION処理は、レプリケーション・エージェントが停止している場合(ttAdmin -repStop)にのみサポートされます。マスターとサブスクライバの両方のデータベースでレプリケーション・エージェントを停止し、マスターとサブスクライバの両方のデータベースでレプリケーション・スキームを変更した後、両方のレプリケーション・エージェントを再起動します。

データベース名、ホスト名または要素名が一致しない。

- ALTER REPLICATION文にタイプミスがないかどうか確認します。

- 「ホスト名の確認」を参照してください。

ALTER REPLICATION文で定義されているレプリケーション表が存在しない。

CREATE TABLEを使用してデータベースに表を作成します。

その他の問題がある。

『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のクラシック・レプリケーション・スキームの変更に関する項に記載されているプロシージャおよび要件を確認します。

レプリケーション・エージェントを起動または停止できない

この項では、レプリケーション・エージェントを起動または停止できないときに確認する事項を説明します。

考えられる原因

対処

ユーザーが、ADMIN権限を持っていない。

ttAdminユーティリティ、ttRepStartプロシージャまたはttRepStopプロシージャを使用してレプリケーション・エージェントを起動または停止するには、ADMIN権限が必要です。

TimesTenデーモンが起動しない。

TimesTenデーモンの状態を確認します(「TimesTenユーザー・エラー・ログを確認する」を参照)。必要に応じて、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen Data Managerデーモンの処理に関する項を参照して、TimesTenデーモンを起動します。

データベースがレプリケーション・スキームに入っていない

レプリケーション・スキームに関連していないデータベースのレプリケーション・エージェントを起動しようとしても失敗します。CREATE REPLICATIONを使用して、データベースのレプリケーション・スキームを作成します。

SNMPトラップを使用してレプリケーション・イベントを通知する

TimesTenでは、特定のレプリケーション・イベントに対してSNMPトラップを送信して、ネットワーク管理ソフトウェアでの迅速な対処を可能にします。TimesTenでは、レプリケーション・イベントに対して次のトラップを送信できます。

- ttRepAgentExitingTrap

- ttRepAgentDiedTrap

- ttRepAgentStartingTrap

- ttRepCatchupStartTrap

- ttRepCatchupStopTrap

- ttRepReturnTransitionTrap

- ttRepSubscriberFailedTrap

- ttRepUpdateFailedTrap

これらのトラップの詳細は、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップを使用した診断に関する説明を参照してください。

レプリケーションが正しく機能しない

マスター・データベースとサブスクライバ・データベースの間でレプリケーションを正しく機能させることができない場合、次のいずれかの問題が該当する可能性があります。

考えられる原因

参照先

TimesTenデーモンまたはレプリケーション・エージェントが稼働していない。

後述の「TimesTenデーモンとレプリケーション・エージェントのステータスを確認する」

マスターとサブスクライバのエージェントが通信していない。

「レプリケーション・エージェントが通信していることを確認する」

レプリケーションがStart状態ではない。

「レプリケーションの状態を確認する」

レプリケーション・スキームでエラーが発生した。

「レプリケーション・スキームの構成を確認する」

レプリケーション・スキームと表の所有者名が一致しない。

「所有者名を確認する」

レプリケーション表に整合性がない。

「レプリケーション表間の整合性を確認する」

TimesTenデーモンとレプリケーション・エージェントのステータスを確認する

ttStatusユーティリティを使用して、メインTimesTenデーモンが稼働していること、およびすべてのマスターおよびサブスクライバのデータベースについてレプリケーション・エージェントが起動していることを確認します。マスターおよびサブスクライバのデータベースが1つしかない単純なレプリケーション・スキームの出力は、例4-1のようになります。

TimesTenデーモンが稼働していても、レプリケーション・エージェントが稼働していない場合、出力は例4-2に示すようになります。この場合、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケーション・エージェントの起動と停止に関する説明に従ってレプリケーション・エージェントを起動します。

TimesTenデーモンとレプリケーション・エージェントがどちらも稼働していない場合、出力は例4-3に示すようになります。この場合、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のTimesTenのインストールに関する説明に記載されたとおりに、TimesTen が正しくインストールされていて、データマネージャ・サービスが起動しているか確認します。

例4-1 1つのマスターおよび1つのサブスクライバに対するttStatus出力

C:\>ttStatus
TimesTen status report as of Mon Aug  6 22:07:53 2012
Daemon pid 5088 port 17000 instance MYINSTANCE
TimesTen server pid 4344 started on port 17002
------------------------------------------------------------------------
Data store c:\temp\subscriber1ds
There are 12 connections to the data store
Data store is in shared mode
Shared Memory KEY Global\DBI45b9471c.2.SHM.2 HANDLE 0x280
Type            PID     Context     Connection Name              ConnID
Process         1244    0x00d08fb0  subscriber1ds                     1
Replication     4548    0x00aed2f8  LOGFORCE                          4
Replication     4548    0x00b03470  TRANSMITTER                       5
Replication     4548    0x00b725a8  RECEIVER                          6
Replication     4548    0x00b82808  REPHOLD                           2
Replication     4548    0x00b98980  REPLISTENER                       3
Subdaemon       2752    0x00526768  Worker                         2042
Subdaemon       2752    0x0072a758  Flusher                        2043
Subdaemon       2752    0x007308c0  Checkpoint                     2044
Subdaemon       2752    0x00736a28  HistGC                         2046
Subdaemon       2752    0x067f02f8  Aging                          2045
Subdaemon       2752    0x068364a0  Monitor                        2047
Replication policy  : Manual
Replication agent is running.
Cache agent policy : Manual
------------------------------------------------------------------------
Data store c:\temp\masterds
There are 12 connections to the data store
Data store is in shared mode
Shared Memory KEY Global\DBI45b945d0.0.SHM.6 HANDLE 0x2bc
Type            PID     Context     Connection Name              ConnID
Process         5880    0x00d09008  masterds                          1
Replication     3728    0x00aed570  LOGFORCE                          4
Replication     3728    0x00b036e8  TRANSMITTER                       5
Replication     3728    0x00b168b8  REPHOLD                           3
Replication     3728    0x00b1ca20  REPLISTENER                       2
Replication     3728    0x00b22b88  RECEIVER                          6
Subdaemon       3220    0x00526768  Worker                         2042
Subdaemon       3220    0x0072e768  Flusher                        2043
Subdaemon       3220    0x007348d0  Checkpoint                     2044
Subdaemon       3220    0x067b0068  Aging                          2045
Subdaemon       3220    0x067c0040  Monitor                        2047
Subdaemon       3220    0x068404c8  HistGC                         2046
Replication policy  : Manual
Replication agent is running.
Cache agent policy : Manual
------------------------------------------------------------------------
Data store c:\temp\demo
There are no connections to the data store
Replication policy : Manual
Cache agent policy : Manual
------------------------------------------------------------------------
End of report

例4-2 レプリケーション・エージェントが稼働していない

> ttStatus
TimesTen status report as of Mon Aug  6 22:07:53 2012

Daemon pid 3396 port 15000 instance MYINSTANCE
TimesTen server pid 3436 started on port 15002
-----------------------------------------------------------------
Data store c:\temp\subscriberds
There are no connections to the data store
cache agent restart policy: manual
-----------------------------------------------------------------
Data store c:\temp\masterds
There are no connections to the data store
cache agent restart policy: manual
-----------------------------------------------------------------
End of report

例4-3 TimesTenデーモンおよびレプリケーション・エージェントが稼働していない

> ttStatus
ttStatus: Could not connect to TimesTen daemon: Connection refused

レプリケーション・エージェントが通信していることを確認する

ttRepAdmin -receiver -listを使用して、レプリケーション・エージェントが互いに通信していることを確認します。masterdsデータベースがsubscriberdsデータベースにレプリケートされる場合、出力は次のようになります。

例4-4 レプリケーション・エージェントが通信していることを確認する

> ttRepAdmin -receiver -list masterDSN
Peer name         Host name                 Port    State  Proto
----------------  ------------------------ ------  ------- -----
SUBSCRIBERDS      MYHOST                    Auto   Start       10

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
0:01:12       -               19.41       5        52    2

レプリケーションの状態を確認する

ttReplicationStatusプロシージャを使用して、マスターに対するサブスクライバ・データベースの状態を確認します。サブスクライバの状態が、Stop、PauseまたはFailedの場合、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のサブスクライバのレプリケーション状態の設定に関する説明に従い、ttReplicationStatusプロシージャを使用してサブスクライバの状態をStartにリセットします。

例4-5 サブスクライバ・データベースのステータスをマスター・データベースから取得する

ttReplicationStatusを使用して、subscriberdsデータベースのステータスをそのマスター・データベースmasterDSNから取得するには、次のように入力します。

> ttIsql masterDSN
Command> CALL ttReplicationStatus ('subscriberds');
< SUBSCRIBERDS, MYHOST, 0, pause, 1, 10, REPSCHEME, REPL >
1 row found.

状態をStartにリセットするには、次のようにttRepSubscriberStateSetプロシージャをコールします。

Command> CALL ttRepSubscriberStateSet('REPSCHEME', 'REPL', 'SUBSCRIBERDS', 'MYHOST', 0)
Command> CALL ttReplicationStatus ('subscriberds');
< SUBSCRIBERDS, MYHOST, 0, start, 1, 152959, REPSCHEME, REPL >
1 row found.

レプリケーション・スキームの構成を確認する

この項では、レプリケートされたシステムで様々なコンポーネントが正しく構成されていることを確認する手順について説明します。基本的な手順は次のようになります。

- ttRepAdmin -showconfigの確認

- TTREP.TTSTORES表の確認

- ホスト名の確認

ttRepAdmin -showconfigの確認

ttRepAdmin -showconfigを使用して、レプリケーション・スキームの構成を確認します。

次の項目を確認します。

- サブスクライバのエージェントがすべて起動され、Start状態であることが報告されているかどうか。起動されていない場合は、そのエージェントをStart状態にリセットします。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のサブスクライバのレプリケーション状態の設定に関する説明を参照してください。

- 返されたPeer nameが、レプリケートするデータベースのDSN定義のDataStore属性で指定された名前と一致しているかどうか。データソースName属性に設定されている名前を指定した場合、レプリケーションは動作しません。

- 「List of subscribers」の下に何か表示されているかどうか。表示されていない場合は、DSN定義で指定したデータベース名が、レプリケーション・スキーム構成ファイルで指定した名前と一致することを確認します。

- Host nameが正しいかどうか。不明確な場合は、「ホスト名の確認」を参照してください。

- 「Table details」の下に表示されている表の名前が正しいかどうか。正しくない場合は、レプリケーション・スキーム構成ファイルで表名を修正します。

例4-6 レプリケーション・スキームの構成を確認する

> ttRepAdmin -showconfig masterDSN
Self host "MYHOST", port auto, name "MASTERDS", LSN 4/2970276, timeout 120, threshold 0
List of subscribers
-----------------
Peer name         Host name                 Port    State  Proto
----------------  ------------------------ ------  ------- -----
SUBSCRIBERDS      MYHOST                    Auto   Start      10
Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
0:01:12       -               19.41       5        52    2
List of tables and subscriptions
--------------------------------
Table details
-------------
Table : REPL.TAB
Master Name               Subscriber Name
-----------               -------------
MASTERDS                  SUBSCRIBERDS

TTREP.TTSTORES表の確認

TTREP.TTSTORES表で、レプリケーションによってレプリケーション・スキームがローカル・データベースに関連付けられていることを確認します。

例4-7では、レプリケーション・スキームがローカル・データベースに関連付けられていることを確認します。

データベースに接続し、次のように入力します。

SELECT * FROM ttrep.ttstores WHERE is_local_store <> 0x0;

Command> select * from ttrep.ttstores where is_local_store <> 0x0;
< -5193371075573733683, MYHOST, MASTERDS, 01, 0, 0, 4, 0 >
1 row found.

1行の結果が返されます。2行以上返される場合は、TimesTenテクニカル・サポートに連絡してください。1行も返されない場合は、次の文によって返されるホストは、TimesTenレプリケーションではローカル・システムとみなされません。

SELECT DISTINCT host_name FROM ttrep.ttstores;

また、レプリケーション・スキームで指定されたデータベース名が、DSNの記述で指定されたデータベース名と一致しない場合もあります。

ホスト名の確認

レプリケーション・スキームで指定されたホストとIPアドレスがレプリケーション・エージェントで解決できない場合、次のような原因が考えられます。

- レプリケーション・スキームに間違ったホスト名またはIPアドレスが指定されているか、あるいはそれらの綴りが間違っている。

- ホスト名またはIPアドレスが解決できない、あるいはDNSまたは/etc/hostsファイルに見つからない。

- /etc/hostsファイルのエントリの記述順序が正しくない。このエラーは、複数のNICを使用している場合によく発生します。/etc/hostsファイルを変更するには、root権限が必要です。

レプリケーションに使用されるホスト・システムのDNSおよび/etc/hostsファイルの構成方法の詳細は、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のネットワークの構成に関する項を参照してください。

レプリケーション・スキームのホスト名とローカル・システムのホスト名が一致していることを確認するには、次のタスクを実行するようにアプリケーションを作成します。

1. gethostname オペレーティング・システム・ファンクション・コールを使用して、実行中のホストのホスト名を確認します。

2. 手順1の出力を使用して、gethostbynameをコールします。

3. レプリケーション・スキームで指定されているホスト名を使用して、gethostbynameをコールします。

4. 手順2と手順3の出力を比較します。一致している場合、実行中のホストはレプリケーションに含まれています。一致していない場合は、レプリケーションに含まれていません。

所有者名を確認する

『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の、クラシック・レプリケーション・スキームの表要件および制限に関する項およびレプリケーション・スキームおよびレプリケートされたオブジェクトの所有者に関する項に記載されているように、レプリケーション・スキームおよびレプリケートされた表の所有者名は関連するすべてデータベース全体で一貫している必要があります。つまり、レプリケーション・スキーム所有者はすべてのデータベースで一致し、それぞれの表はデータベース内の同一のユーザーにより所有されている必要があります。

レプリケーションの所有者の確認

レプリケーション・スキームに割り当てられている所有者名は、ttIsql repschemesコマンドをコールするか、TTREP.REPLICATIONS表の内容をリストして確認します。

例4-8は、SYSTEM1とSYSTEM2の両方で、レプリケーション・スキーム名REPSCHEMEがデータベースに一貫した所有者名(REPL)を持つことを示しています。例4-9は、所有者名が一貫していないスキーム名を示しています。これは、レプリケーション・スキームの定義で所有者名の指定を省略し、システムがそのレプリケーション・スキームの作成者のIDを採用した場合に発生することがあります。

例4-8 レプリケーション・スキームの所有者名が一貫している

SYSTEM1:

> ttIsql masterDSN
Command> select * from ttrep.replications;
< REPSCHEME            , REPL                 , C, 0, 0, -1 >
1 row found.

SYSTEM2:

> ttIsql -connStr "dsn=subscriberDSN"
Command> select * from ttrep.replications;
< REPSCHEME            , REPL                 , C, 0, 0, -1 >
1 row found.

例4-9 レプリケーション・スキームの所有者名が一貫していない

SYSTEM1:

> ttIsql masterDSN
Command> select * from ttrep.replications;
< REPSCHEME            , SYSTEM1               , C, 0, 0, -1 >
1 row found.

SYSTEM2:

> ttIsql -connStr "dsn=subscriberDSN"
Command> select * from ttrep.replications;
< REPSCHEME            , SYSTEM2               , C, 0, 0, -1 >
1 row found.

表の所有者の確認

ttIsql tablesコマンドを使用して、各データベースの表に割り当てられている所有者名を確認します。

例4-10 表所有者名が一貫している

この例は、SYSTEM1とSYSTEM2の両方で、TAB表がデータベースに一貫した所有者名(REPL)を持つことを示しています。

SYSTEM1の出力

SYSTEM2の出力

REPL.TAB

REPL.TAB

例4-11 表所有者名が一貫していない

この例は、所有者名が各ホストに対して自動的に割り当てられ、それらが一貫していないTAB表を示しています。

SYSTEM1の出力

SYSTEM2の出力

SYSTEM1.TAB

SYSTEM2.TAB

レプリケーション表間の整合性を確認する

デフォルトでは、TimesTenのレプリケーション・スキームはTABLE DEFINITION CHECKING RELAXED属性を使用して作成されます。TABLE DEFINITION CHECKING RELAXED属性では、レプリケートされた表の列定義が同じである必要はありません。RELAXED属性には、レプリケートされた表に同じキー定義、列数、列名および列のデータ型のみが必要です。TABLE DEFINITION CHECKING EXACT句を使用してレプリケーション・スキームを定義する場合、レプリケーション・スキームに含まれるレプリケートされた表の列の定義はマスター・データベースとサブスクライバ・データベースで同一である必要があります。TimesTenでは、TABLE DEFINITION CHECKING RELAXEDを使用することをお薦めします。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケート表の列定義オプションに関する項を参照してください。

例4-12 レプリケーション表間の整合性を確認する

このユーザー・エラー・ログの出力は、サブスクライバ表TTUSER.MYDSNの列の数が一致していないことを示しています。

11:37:58.00 Info: REP:  9430: REP1:transmitter.c(4936): TT16136: Sending
definition for table TTUSER.MYDSN (1 column)
11:37:58.00 Info: REP:  9412: REP2:receiver.c(5928): TT16193: Adding definition
for table: TTUSER.MYDSN
11:37:58.00 Info: REP:  9412: REP2:meta.c(5580):TTUSER.MYDSN ptn 0: srcoff 0,
destoff 0, length 8
11:37:58.00 Info: REP:  9412: REP2:meta.c(5580):TTUSER.MYDSN ptn 1: srcoff 8,
destoff 12, length 12
11:37:58.00 Err : REP:  9412: REP2:receiver.c(6203): TT16198: Table definition
mismatch on number of columns for table TTUSER.MYDSN.  Local definition: 2;
transmitting peer: 1
11:37:58.00 Err : REP:  9412: REP2:receiver.c(6380): TT16204: Table TTUSER.MYDSN
marked invalid. Will not apply transactions received for it until a valid
definition is received
11:37:58.00 Err : REP:  9412: REP2:receiver.c(7200): TT16078: Table definition
for ID 637068 is invalid (Original failure 11:37:58
REP2:receiver.c(6203): TT16198: Table definition mismatch on number of columns
for table TTUSER.MYDSN.  Local definition: 2; transmitting peer: 1)
11:37:58.00 Err : REP:  9412: REP2:receiver.c(5002): TT16187: Transaction
1173958671/2; Error: transient 0, permanent 1

レプリケーションからのレスポンスがない、ハングしている可能性がある

最初のヘッダー・セルに表の概要が示されています。

考えられる原因

参照先

サブスクライバに障害が発生した。

後述の「レプリケーションの状態を確認する」

RETURN RECEIPTタイムアウト時間が長すぎる

後述の「RETURN RECEIPTタイムアウトの設定を確認する」

レプリケーションの状態を確認する

ttReplicationStatusプロシージャを使用して、マスターに対するサブスクライバ・データベースの状態を確認します。サブスクライバがFailed状態の場合、失敗したデータベースの対処方法に関する情報は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のデータベースのフェイルオーバーおよびリカバリの管理に関する説明を参照してください。

例4-13 レプリケーションの状態を確認する

ttReplicationStatusを使用して、subscriberdsデータベースのステータスをそのマスター・データベースmasterDSNから取得するには、次のように入力します。

> ttIsql masterDSN
Command> CALL ttReplicationStatus ('subscriberds');
< SUBSCRIBERDS, MYHOST, 0, failed, 1, 10, REPSCHEME, REPL >
1 row found.

RETURN RECEIPTタイムアウトの設定を確認する

ttRepSyncGetプロシージャを使用して、RETURN RECEIPTタイムアウトの設定を確認します。-1は、サブスクライバからの応答を受け取るまでアプリケーションが待機することを示します。サブスクライバの応答の受取りは、ネットワークの待機時間などの問題によって遅延する可能性があります。問題を解決するか、またはttRepSyncGetプロシージャ を使用して、受領通知のタイムアウト時間をリセットします。

詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のRETURNサービス・トランザクション状態の確認に関する項を参照してください。

レプリケーションまたはXLAのパフォーマンスが悪い

この項では、レプリケーションのパフォーマンスに影響する可能性がある問題について説明します。ログ・バッファが小さすぎたり、ディスク上のトランザクション・ログ・ファイルから読み取ると、レプリケーションとXLAアプリケーションの両方のパフォーマンスに影響する可能性があります。

考えられる原因

参照先

ネットワークが遅い。

後述の「ネットワーク帯域幅を確認する」

RETURN RECEIPTが使用されている。

後述の「RETURN RECEIPTブロッキングの使用を確認する」

レプリケーション・スキームに整合性がない。

「レプリケーションの構成を確認する」

ログ・バッファが小さすぎる。

「ログ・バッファのサイズを確認する」

ディスクの書込み頻度が高いか、または効率が悪い。

「永続性の設定を確認する」

ログ・バッファではなくディスク上のトランザクション・ログ・ファイルから読み取られる。

「トランザクション・ログ・ファイルからの読取りの有無を確認する」

競合の頻度が高い。

「競合レポートのためにレプリケーションが遅くなる」

ネットワーク帯域幅を確認する

通常、レプリケーション・エージェントはネットワーク接続を介して通信を行います。1秒あたり10MBより遅いネットワーク上でレプリケートする場合(LANの100 Base-Tイーサネットがその典型例)、トランザクション・ロードが、利用できるネットワーク・バンド幅に一致するよう注意する必要があります。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のネットワーク・バンド幅の要件に関する説明を参照してください。

RETURN RECEIPTブロッキングの使用を確認する

すべてのトランザクションについて受取りの確認を必要とする場合以外は、RETURN RECEIPTブロッキングを無効にしてください。一部のトランザクションについて受取りの確認が必要な場合は、RETURN RECEIPT BY REQUESTを設定して、ttRepSyncSetプロシージャをコールし、特定のトランザクションに対するRETURN RECEIPTサービスを有効にします。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のリクエストによる受領通知に関する説明を参照してください。

注意:
複数のアプリケーション(またはスレッド)でデータベースを更新している場合、RETURN RECEIPTによるパフォーマンスの低下はそれほど問題ではなくなります。トランザクションでRETURN RECEIPTを使用する必要がある場合、複数のスレッドを使用してデータベースを更新することで、アプリケーションのパフォーマンスを改善できます。各スレッドは受取りの確認のためにブロックする必要はありますが、それ以外のスレッドは自由に更新できます。

レプリケーションの構成を確認する

前述のRETURN RECEIPTの設定に加えて、レプリケーション・スキームの構成に関するその他の要因が、レプリケーションのパフォーマンスに影響を与える可能性があります。『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のパフォーマンスおよびリカバリ・トレードオフに関する決定の説明に記載されているとおり、レプリケーション・パフォーマンスに対してデータベースを効果的にフェイルオーバーしたりリカバリする機能を頻繁に重み付けする必要があります。

『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の直接的なレプリケーションまたは伝播に関する説明を参照してください。

ログ・バッファのサイズを確認する

ログ・バッファの設定値が小さすぎると、レプリケーションのパフォーマンスに影響する場合があります。かわりに、LogBufMB DSN属性のサイズを大きく設定します。DSN属性に関する詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のログの接続属性の設定に関する説明を参照してください。

永続性の設定を確認する

レプリケーションのELEMENTに対してTRANSMIT NONDURABLEを設定して、ログをディスクにフラッシュする操作をレプリケーション・サイクルから取り除くことで、レプリケーションのパフォーマンスを改善できます。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のDATASTORE要素に対する送信永続性の設定に関する項を参照してください。

また、レプリケーション・スキームでDURABLE COMMITオプションを有効にしても、パフォーマンスに影響があります。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のDURABLE COMMITに関する説明を参照してください。

トランザクション・ログ・ファイルからの読取りの有無を確認する

状況によっては、マスター・レプリケーション・エージェントのTRANSMITTERスレッドやXLAアプリケーションのttXlaNextUpdateコールなどのログ・リーダーが、アプリケーションによるデータベースへの書込みの更新を処理しきれない場合があります。通常、レプリケーションおよびXLAリーダーは、メモリー内のログ・バッファから更新レコードを取得します。リーダーがアプリケーションの更新を処理しきれない場合、バックログがクリアできるようになるまで、トランザクション・ログ・ファイルがディスクに蓄積されることがあります。この場合、リーダーは、非常に遅いディスク上のトランザクション・ログ・ファイルからトランザクションを読む必要があります。トランザクション・ログ・ファイルからの読取りを検出したら、ログ・リーダーが処理できる速度までアプリケーションの更新速度を下げてください。

アプリケーションでは、SYS.MONITOR表のエントリLOG_FS_READSを追跡することで、ログ・リーダーがメモリー内のログ・バッファではなく、ディスク上のトランザクション・ログ・ファイルから更新レコードを取得していることを監視できます。たとえば、次のttIsqlコマンドを使用すると、データベースMASTERDSNのLOG_FS_READSの値を確認することができます。

% ttIsql -v1 -e "select log_fs_reads from monitor; quit;" -connStr dsn=MASTERDSN

LOG_FS_READSカウンタが増加している場合、ログ・リーダーはトランザクション・ログ・ファイル内のバックログより遅れているか、バックログをクリアしています。

より完全にレプリケーション・プロセスを監視するには、次のような簡単なシェル・スクリプトを作成します。

!/bin/sh
trap exit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
DSN=$1

while [ 1 ] ; do
date
ttRepAdmin -receiver -list -connStr dsn=$DSN
echo -n "Log reads from disk: "
ttIsql -v1 -e "select log_fs_reads from monitor; quit;" -connStr dsn=$DSN
echo
ttRepAdmin -bookmark -connStr dsn=$DSN
sleep 15
done

例4-14 トランザクション・ログのステータスを確認する

たとえば、上記スクリプトにmonitorLogという名前を付け、レプリケーション・スキームでMASTERDSNデータベースからSUBSCRIBER1DSNデータベースにレプリケートします。この場合は、次のように入力して、トランザクションのステータスを確認できます。

$ monitorLog masterdsn

次のような出力が表示されます。

Mon Aug  2 10:44:40  2004
Peer name         Host name                 Port    State  Proto
----------------  ------------------------ ------  ------- -----
SUBSCRIBER1DSN    MYHOST                    Auto    Start   12

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
00:00:05      -               -1.00      -1        -1    1

Log reads from disk: < 0 >

Replication hold LSN ...... 10/2656136
Last written LSN .......... 10/4015824
Last LSN forced to disk ... 10/3970152

[Ctrl]キーを押しながら[C]キーを押して終了するまで、スクリプトによって、更新されたステータスが15秒毎に表示されます。

例4-14の出力では、日付に続いて、サブスクライバやそのホストなどの名前が表示されます。次に、待機時間、レートの情報、およびこのサブスクライバに代わって保持されているトランザクション・ログの数が表示されます。各値の具体的な意味は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のttRepAdminによるサブスクライバ状態の表示に関する項に説明されています。ここで特に注目するのは、'Last Msg Sent'および'Logs'値です。Last Msg Sentの値は、最終メッセージがマスターによってサブスクライバに送信されてからの経過時間を示し、Logsの値は、ライターが使用する現在のログ挿入ポイント(Last written LSN)以降で、レプリケーション・ログ・リーダーより遅れているログ・ファイル数を示します。

例4-14で示すように、通常、Logsの値は1です。Logsの値が一定間隔で増えることは、待機時間が増え、ディスクからログが読み取れることを示します。

注意:
LogBufMBがLogFileSizeよりも大きい場合、Logsの値が増加しても、ログ・リーダーがトランザクション・ログ・ファイルから読取りを行っているとはかぎりません。これは、データをファイル・システムに書き込む前に、未処理のデータが1ログ・ファイル分を超えることをログ・マネージャが許可しないためです。ログ・マネージャがデータを書き込んだ後は、ログ・リーダーから直接読み取れるように、データはログ・バッファ内に残ります。したがって、LogBufMBがLogFileSizeよりも大きい場合、'Logs'の値のみでは、ログ・リーダーがメモリーとディスクのどちらから読取りを行っているかを判断できない場合があります。

次のコマンドの出力では、トランザクション・ログ・ファイルの数、およびログ・マネージャによって設定されるブックマークの場所を表示しています。

ttRepAdmin -bookmark -connStr dsn=$DSN

詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のttRepAdminユーティリティを使用したレプリケーションの監視に関する項を参照してください。Replication hold LSNとlast written LSNとの差異は、サブスクライバに送信されていないトランザクション・ログのレコード数を示します。これらの値の差異が一定間隔で増加する場合は、レプリケーションの待機時間が増え、ログ・ファイルの読取りが発生する可能性があることを示します。

例4-15 ログ・リーダーはトランザクション・ログ・ファイルから読み取る必要がある

この例では、LogBufMBは16MB、LogFileSizeは8MBと想定しています。次の出力は、ログ・リーダーがログ・バッファの容量よりも約1.8MB遅れており、トランザクション・ログ・ファイル14および15からの読取りが必要なことを示しています。

Peer name         Host name                Port    State   Proto
----------------  ------------------------ ------  ------- -----
SUBSCRIBER1DSN    MYHOST                   Auto    Start   12

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
00:00:03      -               -1.00      -1        -1    4

Log reads from disk: <20>

Replication hold LSN ...... 14/7007464
Last written LSN .......... 17/465336
Last LSN forced to disk ... 17/456152

ttRepAdmin使用時の問題

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

- レプリケーションの受信側の状態を変更した場合の問題

- ttRepAdmin -duplicate使用時の問題

- 「Must specify -scheme」エラーが返される

レプリケーションの受信側の状態を変更した場合の問題

レプリケーションでセカンダリIPアドレスを使用するように構成されている場合に、レプリケーションの受信側の状態を変更しようとすると、/etc/hostsファイルの不適切な構成が原因で、ttRepAdminが次のエラーを出力します。

Alter replication with 'ALTER REPLICATION...port 0' failed:
TT0907: Unique constraint (REPSTORESIX) violated.

このエラーはローカル・データベースを認識していないレプリケーションが原因で発生しますが、これは次の問合せを行うことで確認できます。

SELECT * FROM ttrep.ttstores WHERE is_local_store <> 0x0;

この問合せで、行が戻されないか、またはユーザーが指定したホストではなく、hostnameコマンドの結果に設定されているデータベースのメイン・ホスト名を含む行が戻される場合は、/etc/hostsファイルに構成の問題があります。

この問題を解決するには、使用している特別なホスト名が/etc/hostsファイルに定義されていて、特別なホスト名とhostnameコマンドの結果に共通のIPアドレスがあることを確認します。

たとえば、hostnameコマンドによってsoftswitchが戻され、使用しているシステムにはアドレスが10.10.15.136と192.168.15.136の2つのイーサネット・カードが搭載されているとした場合、softswitchに定義するIPアドレスには、両方のIPアドレスが含まれている必要があります。

ttRepAdmin -duplicate使用時の問題

TimesTenは、ソース・システムおよびターゲット・システムの両方に、同一のインスタンス管理者でインストールされていることを確認します。インストールされている場合、次のような他の原因が考えられます。

- 複製前にデータベースを作成した

- 間違ったデータベースまたはホスト名

複製前に作成されたデータベース

ttRepAdmin -duplicateを実行する前に新しいサブスクライバDSNに接続している場合、データベースはすでに作成されています。このような状況では、-duplicateは次のメッセージを返します。

Error : Restore not done : The datastore already exists.
Unable to restore datastore locally

ttStatusを実行し、返されたリストにデータベースがあるかどうかを確認することによって、データベースの有無を確認します。新しいサブスクライバ・データベースがある場合は、それを破棄し、ttRepAdmin -duplicateを再度実行します。

> ttDestroy /tmp/newstore
> ttRepAdmin -dsn newstoreDSN -duplicate -name newstore
-from masterds -host "server1"

間違ったデータベースまたはホスト名

レプリケーション・スキームにサブスクライバ・データベース名やホスト名を間違って入力した場合、次のようなメッセージが表示されます。

Unable to swap datastore locally
No receiver NEWSTORE on SERVER2 found to swap with

サブスクライバに間違ったホスト名を入力した場合は、次のエラーを受け取ります。

Problem: ttRepAdmin -duplicate command returns TimesTen error 12080: No
subscriber found to swap with.

また、TimesTenが見つけようとしているサブスクライバに関する情報も受け取ります。一般的な原因の1つとして、間違ったホスト名の入力が挙げられますが、ホスト名は、CREATE ACTIVE STANDBY PAIR文の発行時に指定したホスト名と完全に一致している必要があります。たとえば、myhost.oracle.comというサブスクライバを作成して、ttRepAdmin -duplicateにmyhostとしか入力しなかった場合、サブスクライバは見つかりません。

注意:
myhostがローカル・ホストである場合は、-localhost引数を使用します。ローカルホスト名が、レプリケーション・スキームの作成時に指定したホスト名と完全に一致しない場合は、一般的に-localhost引数を使用する必要があります。

「Must specify -scheme」エラーが返される

TTREP.REPLICATIONS表に複数のスキームが指定されている場合、一部のttRepAdminコマンドによって次のエラーが返されることがあります。

Must specify -scheme to identify which replication scheme to use

データベースで使用するレプリケーション・スキームの名前を確認するには、ttIsqlユーティリティを使用して接続し、次のコマンドを入力します。

Command> SELECT * from TTREP.REPLICATIONS;

例4-16 データベースに2つのレプリケーション・スキームが割り当てられている

この例は、2つのレプリケーション・スキームREPSCHEME1とREPSCHEME2が、subDSNに関連付けられたデータベースに割り当てられていることを示しています。この場合、ttRepAdmin -schemeオプションを使用する必要があります。

> ttIsql -connStr "dsn=subDSN"
Command> SELECT * from TTREP.REPLICATIONS;
< REPSCHEME1      , REPL                , C, 0, 0, -1 >
< REPSCHEME2      , REPL                , C, 0, 0, -1 >
2 rows found.
Command> exit
> ttRepAdmin -dsn subDSN -receiver -list -scheme REPSCHEME1
Peer name         Host name                 Port    State  Proto
----------------  ------------------------ ------  ------- -----
SUBSCRIBER1        MYHOST                   Auto   Start      10

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
0:01:12       -               19.41       5        52    2

競合チェック時の問題

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

- レプリケーションのタイムスタンプに列を使用できない

- タイムスタンプが存在しない

- 競合レポートのためにレプリケーションが遅くなる

レプリケーションのタイムスタンプに列を使用できない

CREATE REPLICATION文の要素にCHECK CONFLICTSを設定しようとすると、次のようなエラーを受け取ることがあります。

8004: Column REPL.TABS.TS cannot be used for replication timestamp checking if
in an index or added by ALTER TABLE; and must be binary(8) with NULL values allowed.

この場合、次の項目を確認します。

- 指定した表のタイムスタンプ列がタイプBINARY(8)のNULL値可能な列であること。前述の例では、REPL.TAB表のTS列のデータ型がBINARY(8)である必要があります。

- タイムスタンプ列は、ALTER TABLEを使用して後から追加するのではなく、元のCREATE TABLE文で定義されていること。

タイムスタンプが存在しない

次のようなエラーが表示される場合があります。

2208: Column TS does not exist in table.

この場合、CHECK CONFLICTS句のタイムスタンプ列に正しい名前が指定され、それが指定した表にあることを確認します。

また、タイムスタンプ列が主キーまたは索引の一部でないことを確認します。

競合レポートのためにレプリケーションが遅くなる

レプリケーションをCHECK CONFLICTSに構成している場合、TimesTenはローカル・ホストにレポートを送信します。レポート・ファイルを構成することもできます。『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のSNMPトラップを使用した診断に関する説明を参照してください。

短期間に多くの競合が発生すると、レポートの要件によってサブスクライバのパフォーマンスが低下する可能性があります。CREATE REPLICATION文またはALTER REPLICATION文にストア属性を使用して、競合の頻度が指定した値に達した場合に競合レポートを一時停止したり、再開することができます。

- CONFLICT REPORTING SUSPEND AT 頻度

- CONFLICT REPORTING RESUME AT 頻度

レポートの一時停止中に発生した競合についての情報は取得できません。

『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の競合のレポートに関する説明を参照してください。

パラレル・レプリケーションの問題

パラレル・レプリケーションを構成している場合、システムで実行中の別のTimesTenレプリケーション・スレッドが存在します。レプリケーション・スレッドの数が増加しても対応できる十分なCPUコアがあることを確認してください。

ユーザー定義トラックに基づくパラレル・レプリケーション(ReplicationApplyOrdering = 1 and ReplicationParallelism > = 2)を構成していて、制約違反または列検索障害などの永続エラーが受信側で表示される場合、考えられる原因を次に示します。

- アプリケーション定義の依存性が正しくない

- 同一のキーまたは制約関係にある表のキーに対する捜査が、異なるトラックに書き込まれている。

一般接続属性ReplicationTrackの値を確認してください。接続で実行されるすべてのトランザクションは、ReplicationTrack属性設定で定義されるトラックに割り当てられます。トラックのワークロードが適切であることを確認してください。ALTER SESSION文を使用して、レプリケーション・トラックを変更します。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER SESSIONに関する項を参照してください。パラレル・レプリケーションの構成の詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のパラレル・レプリケーションの構成に関する項を参照してください。

5 AWTキャッシュ・グループのトラブルシューティング

非同期WRITETHROUGH(AWT)キャッシュ・グループを作成すると、データベースがOracle Databaseと通信できるようにするレプリケーション・スキームが自動的に作成されます。AWTキャッシュ・グループを作成し、キャッシュ・エージェントを起動する前に、レプリケーション・エージェントを起動する必要があります。詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のAWTキャッシュ・グループの作成に関する説明を参照してください。

この章では、次のトラブルシューティング項目について説明します。

- レプリケーション・エージェントが起動しない

- AWTパフォーマンスの監視

- AWTのパフォーマンスが悪い場合に考えられる原因

- AWTのTimesTenで報告されるOracle Databaseエラー

レプリケーション・エージェントが起動しない

AWTキャッシュ・グループが機能するには、レプリケーション・エージェントを起動する必要があります。レプリケーション・エージェントが起動しない場合は、第4章「レプリケーションのトラブルシューティング 」を使用して、レプリケーション・エージェントのトラブルシューティングを行います。

レプリケーションを正しく機能させることができない場合、次のいずれかの項を参照すると問題を解決できる可能性があります。

考えられる原因

参照先

レプリケーション・エージェントが起動しない。

「レプリケーション・エージェントを起動または停止できない」

レプリケーション・イベントを監視するSNMPトラップが存在する。

「SNMPトラップを使用してレプリケーション・イベントを通知する」

TimesTenデーモンまたはレプリケーション・エージェントが稼働していない。

「TimesTenデーモンとレプリケーション・エージェントのステータスを確認する」

レプリケーション・エージェントが通信していない。

「レプリケーション・エージェントが通信していることを確認する」

レプリケーションがStart状態ではない。

「レプリケーションの状態を確認する」

AWTパフォーマンスの監視

非同期WRITETHROUGH(AWT)キャッシュ・グループのパフォーマンスを監視し、AWTワークフロー内のタスクの実行にかかった時間を確認することができます。

次の項では、監視およびツールを有効化して結果を表示する方法を説明します。

- AWTパフォーマンスの監視の有効化

- ttRepAdminユーティリティを使用したAWTパフォーマンスの表示

- システム表を使用したAWT操作の監視

AWTパフォーマンスの監視の有効化

AWTキャッシュ・グループの監視を有効にするには、ttCacheAWTMonitorConfig組込みプロシージャを使用します。ttCacheAWTMonitorConfigをコールする前に、レプリケーション・エージェントが実行されていることを確認します。

次の例では、監視を有効にして、サンプリング頻度を16に設定します。正確さとパフォーマンスを考慮してサンプリング係数は16にすることをお薦めします。

Command> CALL ttCacheAWTMonitorConfig('ON',16);
< ON, 16 >
1 row found.

ttRepAdminユーティリティを使用したAWTパフォーマンスの表示

監視の結果を表示するには、-awtmoninfoおよび-showstatusコマンドを指定してttRepAdminユーティリティを使用します。AWTの監視の統計情報は、次のとおりです。

- TimesTenの処理時間: 監視が有効になってからAWTトランザクション・データの処理にかかった時間の合計(ミリ秒)。

- Oracle Databaseブックマーク管理時間: 監視が有効になってからOracle DatabaseのAWTメタデータの管理にかかった時間の合計(ミリ秒)。

- Oracle Database実行時間: 監視が有効になってからAWT SQL処理のOCI準備、バインディングおよび実行にかかった合計時間(ミリ秒単位)。この統計には、TimesTenとOracle Databaseの間のネットワーク待機時間が含まれます。

- Oracle Databaseコミット時間: 監視が有効になってからOracle DatabaseのAWT更新のコミットにかかった時間の合計(ミリ秒)。この統計には、TimesTenとOracle Databaseの間のネットワーク待機時間が含まれます。

- 監視の開始以降の時間。

- 行操作の合計数: 監視が有効になってからAWTキャッシュ・グループで更新された行の合計数。

- TimesTenトランザクションの合計数: 監視が有効になってからのAWTキャッシュ・グループ内のトランザクションの合計数。

- Oracle Databaseへのフラッシュの合計数: TimesTenデータがOracle Databaseに送信された回数の合計。

- TimesTen処理、Oracle Databaseブックマーク管理、Oracle Database実行およびOracle Databaseコミットにかかった時間の割合。

次に例を示します。

ttRepAdmin -showstatus -awtmoninfo myDSN

[other -showstatus output]
...
AWT Monitoring statistics
-------------------------
TimesTen processing time : 8443.424000 millisecs (44.064958 )
Oracle execute  (SQL execution) time : 8930.320000 millisecs (46.605994 )
Oracle execute (PL/SQL execution) time : 0.000000 millisecs (0 )
Oracle commit time : 1787.568000 millisecs (9.329048 )
Time since monitoring was started: 21954.410000 millisecs
CacheAwtMethod mode : 0
Cache-connect Operational Stats :
SQL Operations sent to Oracle : 143556
Number of update operations : 58
Number of update batches    : 58
Number of insert operations : 143498
Number of insert batches    : 1146
Number of delete operations : 0
Number of delete batches    : 0
Total number of batches sent: 1204
Number of bytes sent : 4769094
Number of TimesTen Transactions sent to Oracle (includes retries) :
143556
Number of retries on TimesTen due to errors on Oracle : 0
Number of round trips to Oracle (includes executes, commits and
rollbacks) : 2290
Number of commits on Oracle : 1086
Number of rollbacks on Oracle : 0
Number of rxbatches: 244
Number of rxskips: 0

Peer name         Host name                 Port    State  Proto
----------------  ------------------------ ------  ------- -----
_ORACLE           MYHOST                    Auto   Start      27

Last Msg Sent Last Msg Recv Latency TPS     RecordsPS Logs
------------- ------------- ------- ------- --------- ----
00:00:00      -                2.35    6311      6311    1

システム表を使用したAWT操作の監視

非同期WRITETHROUGH処理がAWTキャッシュ・グループのキャッシュ表の更新速度に遅れることなく対応しているかどうかを確認するには、SYS.MONITORシステム表のLAST_LOG_FILE、REPHOLD_LOG_FILE、REPHOLD_LOG_OFFの各列を問い合せます。LAST_LOG_FILE列の値とREPHOLD_LOG_FILE列の値の差が時間の経過とともに増大し、かつREPHOLD_LOG_OFF列の値の増加速度が遅いかまたは変化しない場合は、キャッシュ表の更新速度が更新のレプリケートよりも速くなっています。

次に、ttRepAdmin -receiver -listユーティリティ・コマンドを実行し、_ORACLEが「Peer name」フィールドに存在する行を探します。その同じ行内の「Last Msg Sent」、「Last Msg Recv」、「Latency」、「TPS」の各フィールドの値を参照して、遅れているレプリケーション・アクティビティが非同期WRITETHROUGH処理であるかどうかを確認します。

ログ・ファイルの監視に関する詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の蓄積されたトランザクション・ログ・ファイルの監視に関する説明を参照してください。

SYS.SYSTEMSTATSシステムには、AWTのパフォーマンスに関する様々な統計が含まれています。『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.SYSTEMSTATSに関する説明を参照してください。

AWTのパフォーマンスが悪い場合に考えられる原因

この項では、AWTキャッシュ・グループのパフォーマンスを低下させる可能性のある問題について説明します。

考えられる原因

参照先

ネットワークが遅い。

「ネットワーク帯域幅を確認する」

ログ・バッファが小さすぎる。

「ログ・バッファのサイズを確認する」

ディスクの書込み頻度が高いか、または効率が悪い。

「永続性の設定を確認する」

ログ・バッファではなくディスク上のトランザクション・ログ・ファイルから読み取る。

「トランザクション・ログ・ファイルからの読取りの有無を確認する」

Oracle Databaseに問題がある。

後述の「Oracle Databaseの問題」

レプリケーション・エージェントが停止している。

「レプリケーション・エージェントを起動または停止できない」または「レプリケーションが正しく機能しない」

行の更新がOracle Databaseに伝播されない場合、UNLOAD CACHE GROUPが完了できない。

後述の「UNLOAD CACHE GROUPは、伝播の完了に行の更新が必要」

Oracle Databaseに関する問題

AWTキャッシュ・グループが更新をOracle Databaseに伝播できない原因として、ネットワーク障害、Oracle Database障害、I/Oボトルネック、CPUボトルネックなどの可能性があります。

レプリケーション・エージェントが停止しているために、Oracle DatabaseへのAWT伝播が失敗する可能性もあります。「レプリケーション・エージェントを起動または停止できない」および「レプリケーションが正しく機能しない」を参照してください。

UNLOAD CACHE GROUPは、伝播の完了に行の更新が必要

AWTキャッシュ・グループのUNLOAD CACHE GROUP文は、行の更新がOracle Databaseに伝播された後で実行されます。ただし、Oracle Databaseへのデータの伝播が、ネットワーク障害、Oracle Databaseの停止、レプリケーション・エージェントの停止など、なんらかの理由で停止した場合、UNLOAD CACHE GROUPステートメントは、失敗する可能性があります。

AWTのTimesTenで報告されるOracle Databaseエラー

次の項は、AWTキャッシュ・グループのTimesTenによって報告される場合のある永続的および一時的なOracle Databaseエラーについて説明します。

- TimesTenによって報告される永続的なOracle Databaseエラー

- TimesTenによって報告される一時的なOracle Databaseエラー

TimesTenによって報告される永続的なOracle Databaseエラー

Oracle Databaseに変更を適用している時に発生する挿入、更新または削除エラーは、次の名前のデータベース・ディレクトリにあるエラー・ファイルに保存されます。

DataSourceName.awterrs

このファイルに報告されるエラーは、永続的なエラーです。TimesTenはトランザクションを再試行しません。このエラーは、TimesTenへのコミット後しばらくしてからAWTエラー・ファイルに報告される場合があります。

AWTエラー・ファイルのメッセージの書式は、例5-1に示すように、レプリケーションでの競合およびトランザクション・エラーで生成されるメッセージと似たものになります。サポート・ログおよびユーザー・ログには、Oracle Databaseエラー・メッセージも報告されます。Oracle Databaseエラーには、接頭辞「ORA-」が付きます。TimesTenエラー・メッセージには、接頭辞「TT」が付きます。たとえば、例5-1で、TimesTenエラー5210および5025は、TT5210およびTT5025と表示されます。これらは、『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』で参照できます。

例5-1 更新がOracle Databaseに伝播される際にキャッシュ違反が発生する場合

キャッシュ・グループの更新がOracle Databaseに伝播される際に制約違反が発生した場合、AWTエラー・ファイルのメッセージは次のようになります。

Error occurred 14:48:55 on 03-22-2011
Datastore: c:\temp\cgDSN
Oracle Id: system1
Transmitting name: cgDSN
Error message:
TT5210: Oracle unique constraint violation error in OCIStmtExecute():
ORA-00001: unique constraint (GUSER.SYS_C00357240) violated rc = -1 -- file
"bdbTblH.c", lineno 1205, procedure "ttBDbStmtForce()"
TT5025: Commit failure in Oracle. Transaction must be rolled back in TimesTen.
-- file "bdbConnect.c", lineno 885, procedure "ttBDbXact()"

Operation that caused the error:
Insert into table TESTUSER.T1 <9,1000>

Failed transaction:
Insert into table TESTUSER.T1 <9, 1000>
End of failed transaction

例5-2 TimesTenでOracle Databaseに配置したオブジェクトが削除された場合

TimesTenでOracle Databaseに配置したオブジェクトが削除された場合、AWTエラー・ファイルのメッセージは次のようになります。

May 04 18:12:36 HOST1 TimesTen Replication 11.2[2136]:
[Err ] DEFAULT:meta.c(639):
TT16062: Failed to compile command:
select p.commit_timestamp, p.commit_seqnum, p.protocol from owner1.TT_06_REPPEERS
p where p.replication_name = :rname and p.replication_owner = :rowner and
p.tt_store_id = :oid and p.subscriber_id = :sid

May 04 18:12:36 HOST1 TimesTen Replication 11.2[2136]:
[Err ] DEFAULT:meta.c(639):
TT5221: TT5221: Oracle syntax error in OCIStmtExecute():
ORA-00942: table or view does not exist rc = -1 -- file "bdbStmt.c", lineno 1041,
procedure "getOraOutTypesNLengths()"

この例では、TT_06_REPPEERS表が存在しません。このエラーを解決するには、次のタスクを実行します。

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

2. キャッシュ・グループを削除して再作成します。

3. レプリケーション・エージェントを再起動します。

TimesTenによって報告される一時的なOracle Databaseエラー

レプリケーション・エージェントでOracle Databaseの問題が発生した場合、AWTキャッシュ・グループを持つデータベースのサポート・ログに、Oracle Databaseエラーが含まれることがあります。レプリケーション・エージェントで次のいずれかのOracleエラーが発生すると、AWTはトランザクションをロールバックして再試行します。サポート・ログが一杯になった場合、最も古いメッセージは削除されて新しいメッセージに置き換えられます。

AWTによってトランザクションが再試行されるため、サポート・ログのOracle Databaseエラーは一時的なものとみなされます。

AWT操作を続行するには、元になっているOracle Databaseの問題を解決する必要があることを示す一時エラーもあります。次に例を示します。

ORA-01536: space quota exceeded for tablespace
ORA-01034: ORACLE not available

元になっている問題が解決されると、AWTは操作を再試行します。

一時的なOracle Databaseエラーは、次のとおりです。

ORA-00018: maximum number of sessions exceeded
ORA-00019: maximum number of session licenses exceeded
ORA-00020: maximum number of processes (%s) exceeded
ORA-00025: failed to allocate %s
ORA-00028: your session has been killed
ORA-00038: Cannot create session: server group belongs to another user
ORA-00051: timeout occurred while waiting for a resource
ORA-00052: maximum number of enqueue resources (%s) exceeded
ORA-00053: maximum number of enqueues exceeded
ORA-00054: resource busy and acquire with NOWAIT specified
ORA-00055: maximum number of DML locks exceeded
ORA-00057: maximum number of temporary table locks exceeded
ORA-00058: DB_BLOCK_SIZE must be %s to mount this database (not %s)
ORA-00059: maximum number of DB_FILES exceeded
ORA-00060: deadlock detected while waiting for resource
ORA-00063: maximum number of LOG_FILES exceeded
ORA-00064: object is too large to allocate on this O/S (%s,%s)
ORA-00099: timed out while waiting for resource, potential PDML deadlock
ORA-00104: deadlock detected; all public servers blocked waiting for resources
ORA-00107: failed to connect to ORACLE listener process
ORA-00115: connection refused; dispatcher connection table is full
ORA-00125: connection refused; invalid presentation
ORA-00126: connection refused; invalid duplicity
ORA-00284: recovery session still in progress
ORA-00370: potential deadlock during kcbchange operation
ORA-00371: not enough shared pool memory
ORA-00376: file %s cannot be read at this time
ORA-00379: no free buffers available in buffer pool %s for block size %sK
ORA-00384: Insufficient memory to grow cache
ORA-00568: Maximum number of interrupt handlers exceeded
ORA-00579: osndnt: server received malformed connection request
ORA-00600: internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]
ORA-00603: ORACLE server session terminated by fatal error
ORA-01000: maximum open cursors exceeded
ORA-01012: not logged on
ORA-01014: ORACLE shutdown in progress
ORA-01019: unable to allocate memory in the user side
ORA-01031: insufficient privileges
ORA-01033: ORACLE initialization or shutdown in progress
ORA-01034: ORACLE not available
ORA-01035: ORACLE only available to users with RESTRICTED SESSION privilege
ORA-01037: maximum cursor memory exceeded
ORA-01046: cannot acquire space to extend context area
ORA-01073: fatal connection error: unrecognized call type
ORA-01089: immediate shutdown in progress - no operations are permitted
ORA-01090: shutdown in progress - connection is not permitted
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-01094: ALTER DATABASE CLOSE in progress. Connections not permitted
ORA-01109: database not open
ORA-01147: SYSTEM tablespace file %s is offline
ORA-01154: database busy. Open, close, mount, and dismount not allowed now
ORA-01155: the database is being opened, closed, mounted or dismounted
ORA-01219: database not open: queries allowed on fixed tables/views only
ORA-01237: cannot extend datafile %s
ORA-01456: may not perform insert/delete/update operation inside a READ ONLY transaction
ORA-01536: space quota exceeded for tablespace '%s'
ORA-01539: tablespace '%s' is not online
ORA-01542: tablespace '%s' is offline, cannot allocate space in it
ORA-01562: failed to extend rollback segment number %s
ORA-01573: shutting down instance, no further change allowed
ORA-01628: max # extents (%s) reached for rollback segment %s
ORA-01629: max # extents (%s) reached saving undo for tablespace %s
ORA-01630: max # extents (%s) reached in temp segment in tablespace %s
ORA-01631: max # extents (%s) reached in table %s.%s
ORA-01632: max # extents (%s) reached in index %s.%s
ORA-01650: unable to extend rollback segment %s by %s in tablespace %s
ORA-01651: unable to extend save undo segment by %s for tablespace %s
ORA-01652: unable to extend temp segment by %s in tablespace %s
ORA-01653: unable to extend table %s.%s by %s in tablespace %s
ORA-01654: unable to extend index %s.%s by %s in tablespace %s
ORA-01655: unable to extend cluster %s.%s by %s in tablespace %s
ORA-01656: max # extents (%s) reached in cluster %s.%s
ORA-01658: unable to create INITIAL extent for segment in tablespace %s
ORA-01659: unable to allocate MINEXTENTS beyond %s in tablespace %s
ORA-01680: unable to extend LOB segment by %s in tablespace %s
ORA-01681: max # extents (%s) reached in LOB segment in tablespace %s
ORA-01683: unable to extend index %s.%s partition %s by %s in tablespace %s
ORA-01684: max # extents (%s) reached in table %s.%s partition %s
ORA-01685: max # extents (%s) reached in index %s.%s partition %s
ORA-01686: max # files (%s) reached for the tablespace %s
ORA-01688: unable to extend table %s.%s partition %s by %s in tablespace %s
ORA-01691: unable to extend lob segment %s.%s by %s in tablespace %s
ORA-01692: unable to extend lob segment %s.%s partition %s by %s in tablespace %s
ORA-01693: max # extents (%s) reached in lob segment %s.%s
ORA-01694: max # extents (%s) reached in lob segment %s.%s partition %s
ORA-03113: end-of-file on communication channel
ORA-03114: not connected to ORACLE
ORA-03134: Connections to this server version are no longer supported.
ORA-03135: connection lost contact
ORA-03136: inbound connection timed out
ORA-03232: unable to allocate an extent of %s blocks from tablespace %s
ORA-03233: unable to extend table %s.%s subpartition %s by %s in tablespace %s
ORA-03234: unable to extend index %s.%s subpartition %s by %s in tablespace %s
ORA-03235: max # extents (%s) reached in table %s.%s subpartition %s
ORA-03236: max # extents (%s) reached in index %s.%s subpartition %s
ORA-03237: Initial Extent of specified size cannot be allocated
ORA-03238: unable to extend LOB segment %s.%s subpartition %s by %s in tablespace %s
ORA-03239: maxextents (%s) reached in LOB segment %s.%s subpartition %s
ORA-04020: deadlock detected while trying to lock object %s%s%s%s%s
ORA-06019: NETASY: invalid login (connect) string
ORA-06021: NETASY: connect failed
ORA-06030: NETDNT: connect failed, unrecognized node name
ORA-06031: NETDNT: connect failed, unrecognized object name
ORA-06032: NETDNT: connect failed, access control data rejected
ORA-06033: NETDNT: connect failed, partner rejected connection
ORA-06034: NETDNT: connect failed, partner exited unexpectedly
ORA-06035: NETDNT: connect failed, insufficient resources
ORA-06036: NETDNT: connect failed, no response from object
ORA-06037: NETDNT: connect failed, node unreachable
ORA-06039: NETDNT: connect failed
ORA-06040: NETDNT: invalid login (connect) string
ORA-06108: NETTCP: connect to host failed
ORA-06113: NETTCP: Too many connections
ORA-06114: NETTCP: SID lookup failure
ORA-06143: NETTCP: maximum connections exceeded
ORA-06315: IPA: Invalid connect string
ORA-06316: IPA: Invalid database SID
ORA-06317: IPA: Local maximum number of users exceeded
ORA-06318: IPA: Local maximum number of connections exceeded
ORA-06319: IPA: Remote maximum number of users exceeded
ORA-06320: IPA: Remote maximum number of connections exceeded
ORA-06404: NETCMN: invalid login (connect) string
ORA-06413: Connection not open.
ORA-10435: enable tracing of global enqueue service deadlock detetction
ORA-10626: specify timeout for online index rebuild to wait for DML
ORA-10906: Unable to extend segment after insert direct load
ORA-12150: TNS:unable to send data
ORA-12151: TNS:received bad packet type from network layer
ORA-12152: TNS:unable to send break message
ORA-12153: TNS:not connected
ORA-12154: TNS:could not resolve service name
ORA-12155: TNS:received bad datatype in NSWMARKER packet
ORA-12156: TNS:tried to reset line from incorrect state
ORA-12157: TNS:internal network communication error
ORA-12158: TNS:could not initialize parameter subsystem
ORA-12159: TNS:trace file not writeable
ORA-12160: TNS:internal error: Bad error number
ORA-12161: TNS:internal error: partial data received
ORA-12162: TNS:service name is incorrectly specified
ORA-12163: TNS:connect descriptor is too long
ORA-12166: TNS:Client can not connect to HO agent.
ORA-12168: TNS:Unable to contact Directory Server.
ORA-12169: TNS:Net service name given as connect identifier is too long
ORA-12170: TNS:Connect timeout occurred
ORA-12171: TNS:could not resolve connect identifier: %s
ORA-12196: TNS:received an error from TNS
ORA-12197: TNS:keyword-value resolution error
ORA-12198: TNS:could not find path to destination
ORA-12200: TNS:could not allocate memory
ORA-12201: TNS:encountered too small a connection buffer
ORA-12202: TNS:internal navigation error
ORA-12203: TNS:unable to connect to destination
ORA-12204: TNS:received data refused from an application
ORA-12205: TNS:could not get failed addresses
ORA-12206: TNS:received a TNS error during navigation
ORA-12207: TNS:unable to perform navigation
ORA-12208: TNS:could not find the TNSNAV.ORA file
ORA-12209: TNS:encountered uninitialized global
ORA-12210: TNS:error in finding Navigator data
ORA-12211: TNS:needs PREFERRED_CMANAGERS entry in TNSNAV.ORA
ORA-12212: TNS:incomplete PREFERRED_CMANAGERS binding in TNSNAV.ORA
ORA-12213: TNS:incomplete PREFERRED_CMANAGERS binding in TNSNAV.ORA
ORA-12214: TNS:missing local communities entry in TNSNAV.ORA
ORA-12215: TNS:poorly formed PREFERRED_NAVIGATORS Addresses in TNSNAV.ORA
ORA-12216: TNS:poorly formed PREFERRED_CMANAGERS addresses in TNSNAV.ORA
ORA-12217: TNS:could not contact PREFERRED_CMANAGERS in TNSNAV.ORA
ORA-12218: TNS:unacceptable network configuration data
ORA-12219: TNS:missing community name from address in ADDRESS_LIST
ORA-12221: TNS:illegal ADDRESS parameters
ORA-12222: TNS:no such protocol adapter
ORA-12223: TNS:internal limit restriction exceeded
ORA-12224: TNS:no listener
ORA-12225: TNS:destination host unreachable
ORA-12226: TNS:operating system resource quota exceeded
ORA-12227: TNS:syntax error
ORA-12228: TNS:protocol adapter not loadable
ORA-12229: TNS:Interchange has no more free connections
ORA-12230: TNS:Severe Network error ocurred in making this connection
ORA-12231: TNS:No connection possible to destination
ORA-12232: TNS:No path available to destination
ORA-12233: TNS:Failure to accept a connection
ORA-12235: TNS:Failure to redirect to destination
ORA-12236: TNS:protocol adapter not loaded
ORA-12316: syntax error in database link's connect string
ORA-12326: database %s is closing immediately;  no operations are permitted
ORA-12329: database %s is closed;  no operations are permitted
ORA-12500: TNS:listener failed to start a dedicated server process
ORA-12501: TNS:listener failed to spawn process
ORA-12502: TNS:listener received no CONNECT_DATA from client
ORA-12504: TNS:listener was not given the SID in CONNECT_DATA
ORA-12505: TNS:listener could not resolve SID given in connect descriptor
ORA-12506: TNS:listener was not given the ALIAS in CONNECT_DATA
ORA-12507: TNS:listener could not resolve ALIAS given
ORA-12508: TNS:listener could not resolve the COMMAND given
ORA-12509: TNS:listener failed to redirect client to service handler
ORA-12510: TNS:database temporarily lacks resources to handle the request
ORA-12511: TNS:service handler found but it is not accepting connections
ORA-12512: TNS:service handler found but it has not registered a
redirect address
ORA-12513: TNS:service handler found but it has registered for a
different protocol
ORA-12514: TNS:listener could not resolve SERVICE_NAME given in
connect descriptor
ORA-12515: TNS:listener could not find a handler for this presentation
ORA-12516: TNS:listener could not find available handler with matching
protocol stack
ORA-12517: TNS:listener could not find service handler supporting direct handoff
ORA-12518: TNS:listener could not hand off client connection
ORA-12519: TNS:no appropriate service handler found
ORA-12520: TNS:listener could not find available handler for requested
type of server
ORA-12521: TNS:listener could not resolve INSTANCE_NAME given in
connect descriptor
ORA-12522: TNS:listener could not find available instance with given
INSTANCE_ROLE
ORA-12523: TNS:listener could not find instance appropriate for the
client connection
ORA-12524: TNS:listener could not resolve HANDLER_NAME given in
connect descriptor
ORA-12525: TNS:listener has not received client's request in time allowed
ORA-12526: TNS:listener: all appropriate instances are in restricted mode
ORA-12527: TNS:listener: all instances are in restricted mode or blocking
new connections
ORA-12528: TNS:listener: all appropriate instances are blocking new connections
ORA-12529: TNS:connect request rejected based on current filtering rules
ORA-12531: TNS:cannot allocate memory
ORA-12532: TNS:invalid argument
ORA-12533: TNS:illegal ADDRESS parameters
ORA-12534: TNS:operation not supported
ORA-12535: TNS:operation timed out
ORA-12536: TNS:operation would block
ORA-12537: TNS:connection closed
ORA-12538: TNS:no such protocol adapter
ORA-12539: TNS:buffer over- or under-flow
ORA-12540: TNS:internal limit restriction exceeded
ORA-12541: TNS:no listener
ORA-12542: TNS:address already in use
ORA-12543: TNS:destination host unreachable
ORA-12544: TNS:contexts have different wait/test functions
ORA-12545: Connect failed because target host or object does not exist
ORA-12546: TNS:permission denied
ORA-12547: TNS:lost contact
ORA-12549: TNS:operating system resource quota exceeded
ORA-12550: TNS:syntax error
ORA-12551: TNS:missing keyword
ORA-12552: TNS:operation was interrupted
ORA-12554: TNS:current operation is still in progress
ORA-12555: TNS:permission denied
ORA-12556: TNS:no caller
ORA-12557: TNS:protocol adapter not loadable
ORA-12558: TNS:protocol adapter not loaded
ORA-12560: TNS:protocol adapter error
ORA-12561: TNS:unknown error
ORA-12562: TNS:bad global handle
ORA-12564: TNS:connection refused
ORA-12566: TNS:protocol error
ORA-12569: TNS:packet checksum failure
ORA-12570: TNS:packet reader failure
ORA-12571: TNS:packet writer failure
ORA-12574: TNS:redirection denied
ORA-12582: TNS:invalid operation
ORA-12583: TNS:no reader
ORA-12585: TNS:data truncation
ORA-12589: TNS:connection not bequeathable
ORA-12590: TNS:no I/O buffer
ORA-12591: TNS:event signal failure
ORA-12592: TNS:bad packet
ORA-12593: TNS:no registered connection
ORA-12595: TNS:no confirmation
ORA-12596: TNS:internal inconsistency
ORA-12600: TNS: string open failed
ORA-12602: TNS: Connection Pooling limit reached
ORA-12606: TNS: Application timeout occurred
ORA-12607: TNS: Connect timeout occurred
ORA-12608: TNS: Send timeout occurred
ORA-12609: TNS: Receive timeout occurred
ORA-12612: TNS:connection is busy
ORA-12615: TNS:preempt error
ORA-12623: TNS:operation is illegal in this state
ORA-12624: TNS:connection is already registered
ORA-12636: Packet send failed
ORA-12637: Packet receive failed
ORA-12829: Deadlock - itls occupied by siblings at block %s of file %s
ORA-12993: tablespace '%s' is offline, cannot drop column
ORA-14117: partition resides in offlined tablespace
ORA-14268: subpartition '%s' of the partition resides in offlined tablespace
ORA-16000: database open for read-only access
ORA-16003: standby database is restricted to read-only access
ORA-16403: shutdown in progress - remote connection is not permitted
ORA-16724: the intended state for resource has been set to OFFLINE
ORA-16903: Unable to connect to database
ORA-16914: Missing connect string. Try \"help\"
ORA-18014: deadlock detected while waiting for resource %s
ORA-21521: exceeded maximum number of connections in OCI (object mode only)
ORA-21522: attempted to use an invalid connection in OCI (object mode only)
ORA-23317: a communication failure has occurred
ORA-24401: cannot open further connections
ORA-24418: Cannot open further sessions.
ORA-24778: cannot open connections
ORA-25400: must replay fetch
ORA-25401: can not continue fetches
ORA-25402: transaction must roll back
ORA-25403: could not reconnect
ORA-25405: transaction status unknown
ORA-25407: connection terminated
ORA-25408: can not safely replay call
ORA-25409: failover happened during the network operation,cannot continue
ORA-25425: connection lost during rollback
ORA-29306: datafile %s is not online
ORA-30006: resource busy; acquire with WAIT timeout expired
ORA-30036: unable to extend segment by %s in undo tablespace '%s'
ORA-30040: Undo tablespace is offline
ORA-31443: deadlock detected while acquiring lock on %s
ORA-37013: (XSACQUIRE_DEADLOCK) Cannot wait to acquire object %j since doing so
would cause a deadlock.
ORA-44317: database open read-only

索引
A  B  C  D  E  F  H  I  L  M  N  O  P  Q  R  S  T  U  V  X

A

AgentTimeoutパラメータ, 3.20.1.1

エージング

監視, 1.5.7

レプリケーションの変更

一意制約の違反, 4.8.1

レプリケーションの変更

トラブルシューティング, 4.2

アプリケーション

異常停止, 2.9.1, 2.9.1

マルチスレッドの問題, 2.9.3

非同期WRITETHROUGHキャッシュ・グループ, 「AWT キャッシュ・グループ」を参照 自動リフレッシュ

バッチ・ジョブ, 3.16

診断, 3.20

Failedステータス, 3.14.4

失敗, 3.11

断片化した変更ログ表, 3.20.4

完全, 3.19

増分, 3.19

間隔が小さすぎる, 3.20.5

ロック・タイムアウト, 3.17.3

監視

変更ログ表, 3.14.2, 3.14.2

SQLスクリプト, 3.14.2

サポート・ログ, 3.14.3

パフォーマンス, 3.20, 3.20.2, 3.20.5 FREELISTSの設定, 3.20.2 INITRANSの設定, 3.20.2 トレース, 1.5.8 AUTOREFRESHトレース, 3.20 AWRレポート

DBMS_LOCK, 3.22

AWTキャッシュ・グループ

削除されたオブジェクト, 5.4.1, 5.4.1

エラー・ログ・ファイル, 5.4.1, 5.4.1

操作失敗, 3.11

Oracleエラー, 5.4.1, 5.4.1, 5.4.2, 5.4.2

パフォーマンス, 5.3

監視, 5.2, 5.2.2

レプリケーションの問題, 5, 5.1 AWTパフォーマンス

SYS.SYSTEMSTATS表, 5.2.3

SYS.MONITOR表の使用, 5.2.3

awterrsファイル, 5.4.1

B

実表

パフォーマンス, 3.20.3

バッチ・ジョブ

Oracle Database, 3.16

バッファ・ビジー待機, 3.20.2

C

キャッシュ

DBMS_LOCK, 3.22

トリガー

パフォーマンス, 3.15

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

起動時の問題, 3.2

キャッシュ・グリッド

アタッチ, 3.3

デタッチ, 3.3

リカバリ, 3.3

予期しない失敗, 3.3

キャッシュ・グループ

自動リフレッシュ失敗, 3.11

AWT操作失敗, 3.11

作成失敗, 3.21

DDL追跡, 3.11

ロードの失敗, 3.11

ロードの失敗, 3.13

パフォーマンス, 3.20.3

リフレッシュの失敗, 3.13

cacheInfo.sqlスクリプト, 3.14.2 変更ログ・レコード

サイズ, 3.19.2

変更ログ表, 3.19.2

断片化, 3.20.4

競合の確認

タイムスタンプの問題, 4.9.1, 4.9.2

クライアント/サーバー

領域不足, 2.5.10

問題, 2.5

スレッド・スタック・オーバーフロー, 2.5.9

トラブルシューティング, 2.5, 2.5

競合レポート

一時停止, 4.9.3

接続識別子, 3.5 接続

サーバーの最大同時接続数, 2.5.2

Windows XPでの最大数, 2.5.8

ステータス, 1.3

スレッド・スタック・オーバーフロー, 2.5.9

タイムアウト, 3.6

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

NULL制約, 3.10

サポートされていないデータ型マッピング, 3.9

CREATE SESSION権限, 2.4.2

D

デーモン

サポート・ログ, 1.4

ユーザー・エラー・ログ, 1.4

データブロック

可用性, 3.15

DBMS_LOCK

競合, 3.22

dbms_shared_pool.keepプロシージャ, 3.15 DDL

追跡, 3.11

DeadDbRecoveryパラメータ, 3.20.1.1 DEADLOCKトレース, 1.5.4 デッドロック, 3.20.2

E

エラー

ファイルサイズの制限の超過, 2.12.7

ログ

AWTキャッシュ・グループ, 5.4.1

メモリー不足, 2.12.5 トレース, 1.5.6

F

障害

サーバー, 2.5.2

ファイル・サイズ

制限, 2.12.7

トレース, 2.12.7

ファイルサイズの制限の超過エラー, 2.12.7 FREELISTS

設定, 3.20.2

H

アプリケーションのハング, 2.9.1

I

INITRANS

設定, 3.20.2

ipcrmコマンド, 2.4.6 ipcsコマンド, 2.4.6 分離

レベル, 2.8.3

L

LOAD CACHE GROUP

失敗, 3.13

ロック

レベル, 2.8.3

タイムアウト, 1.6, 3.17.3

トレース, 1.5.5

LockLevel属性, 2.8.3 ログ

daemonサポート・ログ, 1.4

daemonユーザー・エラー・ログ, 1.4

ログ・バッファ

レプリケーション, 4.7.4

ログ表

パフォーマンス, 3.20.3

LogBufMB初期接続属性, 4.7.4

M

メモリー

共有

消費量, 2.12.1

問合せでの使用, 2.12.4 MONITOR表

AWTパフォーマンス, 5.2.3

N

NOVALIDATE状態

キャッシュ・グループの失敗, 3.21

O

OCIの初期化の失敗, 3.8

ODBC

トレース, 1.7, 1.7

オプティマイザ

表の統計の更新, 2.8.2

ORA-12154, 3.5 Oracle

クライアント/サーバーの互換性, 3.6

AWTキャッシュ・グループにレポートされたエラー, 5.4.1

互換性がないクライアント/サーバーのバージョン, 3.6

AWTキャッシュ・グループのサポート・ログ, 5.4.2

表領域, 3.19.2

ORACLE_HOME

変更, 3.2.2

メモリー不足エラー, 2.12.5 領域不足

複数のクライアント/サーバー接続, 2.5.10

P

パラレル問合せ

有効化, 3.15

パラレル・レプリケーション, 4.10 パフォーマンス

自動リフレッシュ・キャッシュ・グループ, 3.20.2

AWTキャッシュ・グループ, 5.3

ビジー待機, 3.20.2

過剰デッドロック, 3.20.2

分離レベル, 2.8.3

大規模な表, 3.20.3

ロック・レベル, 2.8.3

リフレッシュ, 3.20.2

行ロック待機, 3.20.2

UNLOAD CACHE GROUP, 5.3.2

PermSize属性, 2.4.6 主キー

VALIDATE状態, 3.21

psコマンド, 2.4.6

Q

問合せ

使用メモリーの確認, 2.12.4

R

コミット読取り分離レベル

SELECTの結果の重複, 2.13

REFRESH CACHE GROUP

失敗, 3.13

レプリケーション

エージェント

起動または停止できない, 4.3

ログ・バッファ, 4.7.4 パフォーマンス

競合のレポート, 4.9.3

パフォーマンスが悪い, 4.7 トラブルシューティング, 4, 4, 4.5, 5.1 ロールバック

トレース, 1.5.3

行ロック待機, 3.20.2

S

sarレポーティング・ツール, 2.12.1, 2.12.1

SELECT文

結果の重複, 2.13

セマフォ

削除, 2.4.6

サーバー

障害, 2.5.2

トラブルシューティングの失敗, 2.5.2

SGA

データブロック

可用性, 3.15

KEEP領域, 3.15 共有メモリー

サイズの見積り, 2.4.6

最大サイズへの到達, 2.4.6

問合せ制限, 2.4.6

セグメントの削除, 2.4.6

共有セグメント

使用中が多すぎる, 2.3

作成できない, 2.3

SNMPトラップ, 1.8

レプリケーション, 4.4

領域

監視, 1.5.3

領域不足のトラブルシューティング, 1.5.3

SQLトレース, 1.5.2 文の準備

重要性, 2.8.3

サポート・ログ

自動リフレッシュの監視, 3.14.3

Oracleエラー, 5.4.2

SYS表, 1.9 SYS.MONITOR表

AWTパフォーマンス, 5.2.3

SYS.SYSTEMSTATS表

AWTパフォーマンス, 5.2.3

システム表

監視, 1.9

競合のトラブルシューティング, 2.9.3

T

表

異常に大きい, 3.20.3

大規模, 3.15

統計の更新, 2.8.2

表領域

キャッシュ管理ユーザー, 3.19.2

作成, 3.19.2

診断, 3.19.3

一杯, 3.19.3, 3.19.5

管理, 3.19.5

監視, 3.19.4

Oracle, 3.19.2

リカバリ, 3.19.5

しきい値の警告の設定, 3.19.4

TblSpaceFullRecoveryパラメータ, 3.19.5 TblspaceThresholdパラメータ, 3.19.4 TempSize属性, 2.4.6 スレッド

スタック・オーバーフロー, 2.5.9

スレッド・スタック・オーバーフロー

複数のクライアント接続, 2.5.9

tnsnames.ora識別子, 3.5 topレポーティング・ツール

vmstatツール, 2.12.1

トレース

AGINGトレース, 1.5.7

APIトレース, 1.5.3

AUTOREFRESHトレース, 1.5.8

デッドロック, 1.5.4

エラー・トレース, 1.5.6

ファイル・サイズ, 2.12.7

有効にする方法, 1.7

LOCKトレース, 1.5.5

ODBCトレース, 1.7

出力書式, 1.5.1

SQLトレース, 1.5.2

トランザクション

ログ・バッファ, 4.7.4

ログ・ファイル

蓄積, 2.12.6, 2.12.6

トリガー

パフォーマンス, 3.15

トラブルシューティング, 3 ttCacheAutorefreshStatsGetプロシージャ, 3.20

Failedステータス, 3.14.4

ttCacheAwtMonitorConfigビルトイン・プロシージャ, 5.2 ttCacheConfigビルトイン・プロシージャ, 3.19.4, 3.19.5, 3.20.1.1 ttCaptureユーティリティ, 1.1 ttGridAttachユーティリティ, 3.3.1 ttGridDetachListユーティリティ, 3.3.1 ttIsqlユーティリティ

使用, 1.2

ttLockLevelプロシージャ, 2.8.3 ttmodinstallユーティリティ

使用, 3.2.2

ttOptSetFlagプロシージャ, 2.8.3 ttOptUpdateStatsプロシージャ, 2.8.2 ttRepAdminユーティリティ, 5.2.2, 5.2.3

レプリケーションの変更

一意制約の違反, 4.8.1

受信側の状態の変更, 4.8.1, 4.8.1 複製

作成済のデータベース, 4.8.2

トラブルシューティング, 4.8.2

間違ったデータベース名, 4.8.2

間違ったユーザー名, 4.8.2

トラブルシューティング, 4.8 ttRepStartユーティリティ, 3.3.1 ttSizeユーティリティ

メモリーの見積り, 2.4.6

ttStatusユーティリティ

使用, 1.3

ttTraceMonユーティリティ

AGINGトレース, 1.5.7

APIトレース, 1.5.3

AUTOREFRESHトレース, 1.5.8

DEADLOCKトレース, 1.5.4

エラー・トレース, 1.5.6

LOCKトレース, 1.5.5

出力書式, 1.5.1

SQLトレース, 1.5.2

使用, 1.5

ttXactAdminユーティリティ

トラブルシューティングのための使用, 1.6

U

ulimitコマンド, 2.4.6

UNIX

ipcrmコマンド, 2.4.6

ipcsコマンド, 2.4.6

psコマンド, 2.4.6

ulimitコマンド, 2.4.6

UNLOAD CACHE GROUP

パフォーマンス, 5.3.2

V

VALIDATE状態

主キー, 3.21

vmstatレポーティング・ツール, 2.12.1

X

XLA

パフォーマンスが悪い, 4.7

オラクル社の法律上の注意点について

コピーライトについて

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。