| Oracle TimesTen In-Memory Databaseトラブルシューティング・プロシージャ・ガイド リリース11.2.1 B56056-01 |
|
 戻る |
 次へ |
この章では、TimesTenデータ・ストアの使用時に発生する問題の診断と対処に役立つ情報を提供します。
この章に示すトラブルシューティングを実行した後もデータ・ストアの問題が解決しない場合は、テクニカル・サポートに連絡してください。
内容は次のとおりです。
この項では、TimesTenのメイン・デーモンを起動または停止できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
| 権限が不適切である | TimesTenデーモンを起動または停止するには、ADMIN権限が必要です。 デーモンを起動するためにttDaemonAdminユーティリティを使用していることを確認します。 ttDaemonAdminの出力には、適切な権限があるかどうかが表示されます。 |
| 別のプロセスがTimesTenデーモン・ポートを使用している。 | ttVersionユーティリティを使用して、TimesTenデーモンが使用するポート番号を確認します。 netstatのようなOSコマンドを使用して、別のプロセスがそのポートをリスニングしているかどうかを確認します。 競合している場合は、他のプロセスで使用するポート番号を変更するか、またはttmodinstallを使用してTimesTenで使用するポートを変更します。 |
| TimesTenデーモンがすでに稼働している | デーモンを起動するためにttDaemonAdminユーティリティを使用していることを確認します。 ttDaemonAdminの出力には、デーモンがすでに稼働しているかどうかが表示されます。 |
| その他の問題 | デーモンによって作成されるユーザー・エラー・ログを調べます。 詳細は、「TimesTenデーモンによって生成されるログの使用」を参照してください。 |
この項では、1つ以上のTimesTenプロセスが使用不可能であると考えられるときに実行する事項を説明します。
TimesTenサブデーモンが停止したことを示すエラーを受信した場合、「TimesTenデーモンによって生成されるログの使用」に従って、ユーザー・エラー・ログを調べます。
TimesTenデーモンがクラッシュした場合、そのTimesTenデーモンからユーザー・エラー・ログに送信を行うことはできませんが、サブデーモンでは、メイン・デーモンがクラッシュしたことを示すメッセージをログに送信してから終了します。
09:24:13 Err : 4375 ------------------: Main daemon has vanished
デーモンを再起動します。 次に各データ・ストアに接続すると、TimesTenはチェックポイントおよびトランザクション・ログ・ファイルからリカバリを実行します。 詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のOracle TimesTen Data Managerデーモンでの処理に関する説明を参照してください。
UNIXシステムでいずれかのTimesTenプロセスによってクラッシュが発生し、すべての診断方法を試しても問題が解決しない場合は、TimesTenがコア・ファイルを生成していないかを確認します。 ttVersionユーティリティを使用してコア・ファイルを検索します。出力でデーモン・ホーム・ディレクトリのパスを示す行を検索します。
TimesTen Release (ttuser:40732) 2007-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
コア・ファイルが見つかった場合は、システムのデバッガにアタッチし、コア・ファイルからスタック・トレースを抽出して、その結果をテクニカル・サポートに送付します。
Windowsシステムの場合は、「サービス」メニューでTimesTen Data Managerのプロパティ・ダイアログの「デスクトップとの対話をサービスに許可」オプションを有効にすることで、サービス障害の診断情報を入手できます。TimesTen Data Managerサービスで致命的な障害が発生すると、デバッガを起動するかどうかを尋ねるポップアップが表示されます。 テクニカル・サポートにスタック・トレースを送付してください。
共有セグメントを作成できなかったことを示すエラーを受信する場合があります。
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インストレーション・ガイド』のデータ・ストアのアップグレードに関する説明を参照してください。
ユーザーがデータ・ストアに接続するには、CREATE SESSION権限が必要です。 アクセス権がない場合は、管理者から、GRANT文を使用してCREATE SESSION権限を付与される必要があります。 詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースに接続する権限の付与に関する説明を参照してください。
データ・ストアに接続しようした場合に、チェックポイントまたはトランザクション・ログ・ファイル、あるいはそれらのファイルがあるディレクトリへの適切なアクセス権がないと、権限が拒否されたことを示すエラーが生成されます。 DSNのデータ・ストア属性に指定されているディレクトリに格納されているファイルに対するファイル・システム権限を確認します。
TimesTenデーモンまたはData Managerサービスが稼働していないときにデータ・ストアに接続しようとすると、TimesTenエラー799「Unable to connect to daemon; check daemon status」が生成されます。
ttStatusユーティリティ（「TimesTenユーザー・エラー・ログを確認する」を参照）を使用して、TimesTenデーモンのステータスを確認します。
DSNの記述で次の操作を実行します。
特定の接続オプションまたはDSN属性の設定の組合せに互換性がありません。互換性のない設定を使用してデータ・ストアに接続しようとすると、アプリケーションにエラーが返されます。
DSNのデータ・ストアおよびLogDir属性に正しいパス名が指定されていることを確認します。また、パス名は相対パス名ではなく、絶対パス名であることも確認します。絶対パス名を指定しないと、パス名は、アプリケーションが起動されたディレクトリに対する相対パスになります。
Windowsの場合、ODBCデータソース・アドミニストレータでのユーザーDSNとシステムDSNの違いに注意してください。ユーザーDSNは作成しないでください。ユーザーDSNは、それを定義したユーザーからしか参照できません。システムDSNはすべてのユーザーが参照できます。 特に、WindowsサービスとしてTimesTenアプリケーションを実行する場合、そのアプリケーションはデフォルトでユーザーSYSTEMとして実行され、ユーザーDSNを参照しません。データ・ストアのパス名に、マップされたドライブを使用していないことを確認します。
接続または作成しようとする共有データ・ストアのサイズが、システムに構成された共有メモリー・セグメントの最大サイズより大きいと、エラーが返されます。また、システムが共有メモリー・セグメントをそれ以上割り当てることができない場合もエラーが返されます。
UNIXシステムでは、次のようなコマンドを使用します。
ipcs -maを使用すると、Oracleインスタンスやその他のTimesTenインスタンスなど、メモリーを使い果たすその他の共有メモリー・セグメントがないかどうかを確認できます。
ipcrmを使用すると、メッセージ・キュー、セマフォ・セットまたは共有メモリー・セグメント識別子を削除できます。 障害の発生したTimesTenの停止、インスタンスのクラッシュ、デーモンのクラッシュなどの共有メモリー・セグメントおよびセマフォを使用するアプリケーションの問題の後で、ipcrmを使用して、セマフォまたは共有メモリー・セグメントをクリーンアップします。 共有メモリー・セグメントを削除するには、-mを使用します。 セマフォを削除するには、-sを使用します。
ps -eaflを使用すると、実行中のプロセスによって使用されているメモリーの量を確認できます。
ulimit -aを使用すると、1つのプロセスが処理できるメモリーの最大量、最大ファイル・サイズ、オープン・ファイルの最大数に制限がないかどうかを確認できます。
共有メモリー・セグメントは使用可能であるが、小さすぎてデータ・ストアを保持できない場合は、ttSizeユーティリティを使用して、表に必要なメモリー量を見積もり、PermSizeおよびTempSize属性の値を確認して、データ・ストア用に設定されているメモリー量を検証します。 永続データ・パーティションと一時データ・パーティションのサイズを設定するためのガイドラインについては、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータ・ストアのサイズ変更に関する説明を参照してください。 データ・ストアに対して設定されているメモリー量が多すぎる場合は、PermSizeおよびTempSizeの値を小さくします。 詳細は、「データ・ストアに割り当てられたメモリーの量を確認する」を参照してください。共有メモリー・セグメントのサイズを大きくするその他のオプションについては、次の説明を参照してください。
システム障害またはアプリケーション障害が原因でデータ・ストアが無効になると、後続の接続によってデータ・ストアがリカバリされます。 データ・ストア領域を使い果たしたためにリカバリが失敗した場合は、PermSizeおよびTempSizeの値を現在の値より大きくして、データ・ストアに再接続します。共有メモリーが十分でないためにリカバリが失敗した場合は、システムの共有メモリー・セグメントの最大サイズを大きくする必要があります。
TimesTenの共有メモリーの構成方法の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のインストールの前提条件に関する説明を参照してください。
共有メモリーをバックアップするのに十分なスワップ領域が必要です。
UNIXシステムの場合は、swapコマンドを使用して仮想メモリーを確認し、システムに追加できます。
Windowsシステムの場合は、「Computer Management Properties」ダイアログ・ウィンドウの「Advanced」タブで、仮想メモリーのサイズを確認し、再設定できます。
TimesTenデータ・ストアに接続されている各プロセスは、1つ以上のオペレーティング・システム・ファイル記述子をオープンしたままにします。 チェックポイントが実行される場合、およびトランザクションがコミットまたはロールバックされる場合は、各接続に対してさらにファイル・ディスクリプタをオープンすることができます。データ・ストアに接続しようとしたときに、ファイル記述子がすべて使用中であるというエラーを受信した場合は、ファイル記述子の許容数を増やします。ファイル記述子の制限およびファイル記述子の数の変更については、オペレーティング・システムのドキュメントを参照してください。
この項の内容は次のとおりです。
「アプリケーションがダイレクト・モードでデータ・ストアに接続できない」の説明も確認してください。
TimesTen Serverが稼働しているシステムが正しく識別されていません。
Windowsクライアント・マシンでは、ODBCデータソース・アドミニストレータの一部として表示される「TimesTen Data Source Setup」ダイアログ・ボックスで「TimesTen Server」を選択します。TimesTen Serverを検証するには、次の手順を実行します。
Windowsデスクトップで、「スタート」→「設定」→「コントロール パネル」を選択します。
「管理ツール」→「データソース（ODBC）」をダブルクリックします。 「ODBC データソース アドミニストレータ」が開きます。
「システム DSN」タブをクリックします。「システム データソース」リストが表示されます。
「TimesTen Client data source」を選択します。「TimesTen Client DSN Setup」ダイアログ・ボックスが開きます。
「Servers」をクリックします。「TimesTen Logical Server List」が開きます。
リストから「TimesTen Server」を選択します。「TimesTen Logical Server Name Setup」ダイアログ・ボックスが開きます。
「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サービスの起動および停止に関する説明を参照してください。 また、この問題の識別方法の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の接続のテストに関する説明を参照してください。
UNIXの場合、クライアント・マシン上のodbc.iniファイルのTTC_Server接続属性でTimesTen Serverを指定します。 TTC_Serverに指定する値が実際のホスト名またはIPアドレスの場合、クライアントは、デフォルトのポートを使用してTimesTen Serverに接続を試行します。TimesTenでは、デフォルトのポートはTimesTenのリリース番号と関連付けられています。 TTC_Serverに指定する値が論理ServerNameの場合、この論理ServerNameは、ttconnect.iniファイルで定義する必要があります。 このServerNameをttconnect.iniファイルで定義する場合は、ホスト名、IPアドレス、およびTimesTen Serverがリスニングを行っているポート番号を正しく指定する必要があります。
「Network Address」および「Port Number」の値が正しい場合、TimesTen Serverが稼働していない可能性があります。 サーバーを手動で起動する方法については、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のUNIXでのデーモンの起動および停止に関する説明を参照してください。 また、この問題の識別方法の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の接続のテストに関する説明を参照してください。
サーバーのログ・ファイルを確認します。サーバー・ログ・メッセージはttendaemon.optionsファイル内の-userlogおよび-supportlogオプションで指定したファイルに保存されています。 詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のUNIXでのクライアントDSNの作成および構成に関する説明と、TimesTenデーモン・オプションの管理に関する説明を参照してください。
特定のTimesTenインスタンスのサーバーに対する同時IPC接続の最大数は24,999です。ただし、単一のDSNへの接続数（直接またはクライアント/サーバー）は2043に制限されます。
クライアント/サーバーのユーザーは、ファイル記述子の制限を変更してより多くの接続数に対応できます。 例は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のインストールの前提条件に関する説明を参照してください。
UNIXの場合、TimesTen Serverが稼働しているマシン上のsys.odbc.iniファイルでサーバーDSNが正しく定義されていることを確認します。
Windowsの場合、TimesTen Serverが稼働しているマシンのODBCデータソース・アドミニストレータでサーバーDSNがシステムDSNとして定義されていることを確認します。 詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の論理サーバー名の作成および構成に関する説明を参照してください。
このエラーは、UNIXプラットフォームでのみ発生します。 TimesTen Serverが稼働しているマシンでsys.odbc.iniファイルを開き、接続しようとしているサーバーDSNの場所を確認します。サーバーDSNのDRIVER属性に指定した動的ライブラリが存在し、実行可能であることを確認します。
デフォルトのタイムアウト時間は、60秒です。
UNIXでタイムアウト時間を長くするには、odbc.iniファイルのTTC_Timeout属性の値を変更します。
Windowsでタイムアウト時間を設定するには、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のタイムアウト時間および認証の設定に関する説明を参照してください。
エラーの原因がクライアントのタイムアウトかどうかを確認します。 TimesTen Serverのログを確認して、サーバーがクライアントとの接続を切断した原因を調べます。pingを使用してネットワークが機能しているかどうかを確認するか、またはtelnetを使用してTimesTen Serverのポート番号に接続を試行します。
共有メモリー・セグメント（SHM）をIPCとして使用している際に、TimesTen Client ODBCドライバからの次のエラー・メッセージがアプリケーションに表示される場合があります（アプリケーションがシステムに定義されているプロセス当たりのファイル記述子の制限に達した場合）。
SQLState = S1000, Native Error = 0, Message = [TimesTen][TimesTen 11.2.1 CLIENT]Failed to attach to shared memory segment for IPC. System error: 24
これは、クライアントDSNへの接続処理中、システムに定義されているプロセス当たりのファイル記述子の制限を超えるオープン・ファイル記述子がアプリケーションに含まれていることが原因でshmatシステム・コールが失敗した場合に発生する可能性があります。この問題を修正するには、プロセス当たりのファイル記述子の制限を増加する必要があります。 ファイル記述子の制限の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』のシステムの制限に関する説明を参照してください。
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を変更して新しいデータ・ストアを指定する際に、元のデータ・ストアへの接続が確立されたままの場合に、領域不足であることを示すメッセージが表示されることがあります。この問題は、32-bitプラットフォームでいずれかのデータ・ストアが約2GBの場合に発生する可能性があります。
元のデータ・ストアへのすべての接続をクローズします。これにより、DSNで新しく指定したデータ・ストアへの接続用に、新しいサーバー・プロセスが作成されます。 ttStatusユーティリティを使用すると、古いデータ・ストアへの接続を表示できます。 または、-restartServerオプションを指定してttDaemonAdminユーティリティを使用すると、サーバーを再起動して、インスタンス内のすべてのDSNですべてのクライアント接続をリセットできます。
この項では、データ・ストアとの接続や切断に時間がかかるときに確認する事項を説明します。
| 考えられる原因 | 参照先 |
|---|---|
| データ・ストアがリカバリ中である | 「データ・ストアがリカバリ中であるかどうか確認する」 |
| ODBCトレースが有効になっている | 「ODBCトレースを確認する」 |
| その他の考えられる原因 | 「APIトレース」 |
接続に時間がかかるということは、TimesTenデータ・ストアがリカバリ中であることを示している可能性があります。これは初期接続時にのみ発生します。
Windowsプラットフォームでは、ODBCトレースが有効になっていると、接続および切断の処理速度が遅くなる可能性があります。コントロール・パネルの「ODBC」をダブルクリックして、ODBCデータソース・アドミニストレータを開きます。 「トレース」タブを選択して、トレースが無効になっていることを確認します。 「ODBCトレースの使用」を参照してください。
アプリケーションのTimesTenデータ・ストアとの接続が切断された場合、次のいずれかのイベントが発生します。
未解決のトランザクションがなかった場合、その接続はTimesTenデーモンによって完全に削除されます。その他の既存の接続は、問題が発生しなかったように、処理を継続します。
未解決のトランザクションはあるが、アプリケーションがTimesTenライブラリのコードを実行中でなかった場合、トランザクションはロールバックされ、その接続はTimesTenデーモンによって完全に削除されます。その他の既存の接続は、問題が発生しなかったように、処理を継続します。
この項では、アプリケーションがデータ・ストアとの接続を予期せず切断したときに確認する事項を説明します。
| 考えられる原因 | 参照先 |
|---|---|
| 内部アプリケーション・エラーが発生した | 「ODBCまたはJDBCエラーを確認する」 |
| アプリケーションの同時処理スレッドで障害が発生した | 「ODBCまたはJDBCエラーを確認する」
|
| クライアント/サーバー接続を使用している場合に、クライアントがアプリケーションから切断された | 「クライアント/サーバーの問題のトラブルシューティング」 |
| TimesTenライブラリのエラー | テクニカル・サポートに連絡する。 |
次のタイプのエラーを確認します。
SQLErrorファンクションによって返されるODBCエラー
SQLExceptionクラスによって返されるJDBCエラー
アプリケーションが処理の途中で終了し、他の接続を強制的に切断する問題が発生した可能性があります。ODBCをコールした後に必ずSQLErrorをコールして、エラーまたは警告が初めて発生したときの状態を特定します。 SQLErrorの使用例については、デモ・プログラム、および『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のエラーと警告の取得に関する説明を参照してください。
さらに、ttTraceMonを使用してアプリケーションでレベル4のERRトレースを生成し、TimesTenダイレクト・ドライバにプッシュされたすべてのエラー・メッセージを確認することも有効な場合があります。 詳細は、「ERRトレース」を参照してください。
TimesTenアプリケーションがODBCエラーまたは他の警告を返さずに切断された場合は、ユーザー・エラー・ログを調べます。 詳細は、「TimesTenデーモンによって生成されるログの使用」を参照してください。
アプリケーションとTimesTenデータ・ストアのパフォーマンスを最大にする方法については、次を参照してください。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータ・ストアのパフォーマンス・チューニングに関する説明
『Oracle TimesTen In-Memory Database C開発者ガイド』のアプリケーションのチューニングに関する説明
『Oracle TimesTen In-Memory Database Java開発者ガイド』のアプリケーションのチューニングに関する説明
この項では、パフォーマンスを低下させるいくつかの問題について説明します。
| 考えられる原因 | 参照先 |
|---|---|
| クライアント/サーバー・モードを使用している | 「接続モードを検討する」 |
| データベース統計が古い | 「表の統計を更新する」 |
| トランザクションのコミットの頻度が高すぎる | 『Oracle TimesTen In-Memory Database C開発者ガイド』の自動コミット・モードの無効化に関する説明
『Oracle TimesTen In-Memory Database Java開発者ガイド』の自動コミット・モードの無効化に関する説明 |
| DurableCommits属性が有効になっている | 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の永続コミットの適切な使用に関する説明 |
| 複数回使用するSQL文を準備していない | 『Oracle TimesTen In-Memory Database C開発者ガイド』の事前準備に関する説明
+『Oracle TimesTen In-Memory Database Java開発者ガイド』の事前準備に関する説明 |
| 索引の種類が間違っている、索引が多すぎる、ハッシュ索引のサイズが間違っている | 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のハッシュ索引または範囲索引の適切な選択に関する説明
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のハッシュ索引の適切なサイズ設定に関する説明 |
| ロックの使用方法が効率的でない | 「ロック・レベルと分離レベルを検証する」 |
| マテリアライズド・ビューが適切に構成されていない | 『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のマテリアライズド・ビューのパフォーマンスの改善に関する説明 |
| レプリケーションを使用している場合は、レプリケーション・スキームの構成またはネットワーク環境がアプリケーションに影響を与えている可能性がある | 「レプリケーションまたはXLAのパフォーマンスが悪い」 |
| IMDB Cacheを使用している場合は、IMDB Cacheの構成または環境がアプリケーションに影響を与えている可能性がある | 「自動リフレッシュのパフォーマンスが悪い」 |
| 表のパーティションが多すぎる | 「表のパーティション数を確認する」 |
| 1つ以上のTimesTenコンポーネントに対してトレースが不必要に有効になっている | 「トレースの設定を確認する」 |
クライアント/サーバー接続は、TimesTenデータ・ストアへの直接接続よりも遅くなります。また、ドライバ・マネージャ接続でも、パフォーマンスに影響を与えます。クライアント/サーバー接続の場合は、データ・ストアとのすべての通信にネットワーク待機時間を伴うため、かなりのパフォーマンスのオーバーヘッドが発生する可能性があります。
データ・ストアをホスティングしているマシンとは別のマシンでアプリケーションを実行する必要がある場合は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のクライアント/サーバーのチューニングに関する説明を参照してください。
通常、TimesTen問合せオプティマイザは、最も効率的な問合せ計画の選択に優れています。ただし、最適な計画を選択するためには、複雑な問合せに関連する表の情報が必要になります。表の行数と列値のデータ分布を把握することにより、オプティマイザは、その表にアクセスするための効率的な問合せ計画を選択できるようになります。
TimesTen表にアクセスする問合せを準備する前に、ttOptUpdateStatsプロシージャを使用して、その表の統計を更新できます。 表の統計を更新する場合は、表にデータをロードしてから問合せを準備するまでの間に統計を更新すると、最高の結果が得られます。たとえば、データを移入する前に表の統計を更新すると、表に行がない（または少数の行しかない）ものとして、問合せが最適化されます。その後、数百万行のデータを表に移入してから問合せを実行すると、表にほとんど行がない状況で適切に動作した計画は非常に遅くなります。
統計の更新の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen問合せオプティマイザに関する説明を参照してください。
複数のアプリケーションがどのようにデータ・ストアに同時アクセスするかで、パフォーマンスが大きく影響を受けることがあります。
アプリケーションは、データ・ストア全体、個々の表および個々の行に対してロックを取得できます。それとは別に、トランザクションがコミットまたはロールバックするまで読取りロックや更新ロックを保持するかどうかを決定する分離レベルも設定できます。
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つのみです。
表当たりのパーティション数の制限は255です。この数を超えると8204エラーが生成されます。 新しいパーティションそれぞれに対して追加の読取りが行われるため、新しいパーティションのパフォーマンスがそれぞれ少し低下します。 パーティション数は多くしないようにする必要があります。 複数のパーティションを持つレプリケートされた表では、サブスクライバ側で更新を行うたびにパーティション数に比例して追加の領域が使用されます。 このため、サブスクライバではマスターより少し多くの永続領域が使用される場合があります。
各表のパーティション値は、システム表SYS.TABLESの列SYS16で追跡されます。表のパーティション数は、次の問合せで取得します。
SELECT tblname, sys16 FROM SYS.TABLES;
表に含まれるパーティションが多すぎることが検出された場合は、次のいずれかを行います。
表の再作成
表の保存およびリストア。 ttMigrate -cを使用して、移行ファイルを作成します。 その後、ttMigrate -r -noRepUpgradeを使用して、パーティションを追加せずに表をリストアします。
ALTER TABLE ... DROP COLUMNでは、表からパーティションは削除されません。 レプリケートされたシステムでは、-noRepUpgradeオプションを使用してすべてのマスター・データ・ストアおよびサブスクライバ・データ・ストアを移行する必要があります。 異なるパーティション構造の表では、レプリケーションは発生しません。
この項では、アプリケーションからのレスポンスがなく、ハングしている可能性があるときに確認する事項を説明します。
| 考えられる原因 | 参照先 |
|---|---|
| すべての原因 | 「ログを確認し、トレース情報を収集する」 |
| 内部アプリケーション・エラーが発生した | 「ODBCエラーを確認する」 |
| DSNに設定した接続属性が一貫していない | 「接続モードを検討する」 |
| ロックの競合が過剰である | 「デッドロックとタイムアウトを確認する」 |
アプリケーションがハングした場合、ttXactAdminユーティリティを使用してトランザクション・ログを確認します。 詳細は、「ttXactAdminユーティリティの使用」を参照してください。
また、エラーのユーザー・エラー・ログ（「TimesTenデーモンによって生成されたログの使用」を参照）を確認します。
また、トレース・ログを生成して、様々なTimesTenコンポーネントのアクティビティを検出することもできます。詳細は、「ttTraceMonユーティリティの使用」を参照してください。
すべてのアプリケーションで、SQLErrorファンクションが返したODBCエラーを確認し、それらのいずれかでハングの原因となる問題が発生していないかどうかを確認します。ODBCをコールした後に必ずSQLErrorをコールして、エラーまたは警告が初めて発生したときの状態を特定します。 SQLErrorの使用例については、デモ・プログラム、および『Oracle TimesTen In-Memory Databaseエラー・メッセージおよびSNMPトラップ』のエラーと警告の取得に関する説明を参照してください。
問題が再現可能な場合は、ttTraceMonを使用してSQLをトレースを生成し、アプリケーションがハングしている箇所を特定します。 詳細は、「SQLトレース」を参照してください。さらに極端な場合は、アプリケーションに対して、レベル4のERRトレースを生成し、TimesTenダイレクト・ドライバにプッシュされたすべてのエラー・メッセージを確認します。 詳細は、「ERRトレース」を参照してください。
接続の問題がない場合、デッドロックまたはタイムアウトが問題である可能性もあります。 デッドロックとタイムアウトに関する情報は、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では、ロック・タイムアウトを使用してこれらの競合を解消します。
この項では、データ・ストアに作成済の表、索引、順序、ビューがアプリケーションで見つからないときに確認する事項を説明します。
| 考えられる原因 | 参照先 |
|---|---|
| 所有者を指定していないか、間違って指定している | 「オブジェクトの所有者を指定する」 |
| ユーザーが表に対するSELECT権限を持っていない | 「表へのアクセスに必要な権限を確認する」 |
| データ・ストアが一時的である | 「Temporary DSN属性を確認する」 |
| Overwrite属性が有効になっている | 「Overwrite DSN属性を確認する」 |
| DSNに指定したパス名が相対的である | 「データ・ストアのパス名を確認する」 |
表、索引および順序は、「PARTS」のような単独の名前、または「STAN.PARTS」のような所有者と表名が組み合された修飾名で作成できます。 表または索引にアクセスする際に所有者を指定しないと、TimesTenでは、まず所有者はユーザーのログインID（UID属性の値）であるとみなされます。 TimesTenがユーザーのログインIDを使用して表または索引を検出できない場合は、次に所有者はユーザーSYSであるとみなされます。
別のユーザーとしてアプリケーションでデータ・ストアに接続し、オブジェクトを共有する必要がある場合は、オブジェクトの作成時や参照時に所有者を明示的に指定します。
ユーザーのすべての権限は、指定したユーザーのすべてのシステムレベル権限を含むSYS.USER_SYS_PRIVS表、および指定したユーザーのすべてのオブジェクトレベル権限を含むSYS.USER_TAB_PRIVS表で参照できます。 これらの表を確認して、表に対するSELECT権限があるかどうかを検証します。 表に対するSELECT権限がない場合は、GRANT文を使用してSELECT権限を付与できます。 権限を付与する方法の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のアクセス制御の管理に関する説明を参照してください。
一時データ・ストア（DSN属性: Temporary=1）は、データ・ストアとの接続がすべて削除されるまで存続します。一時データ・ストアの表にアクセスしようとしたときに、その表が存在しない場合、その表が存在したデータ・ストアは削除されてしまっている可能性があります。
DSN属性のOverwriteおよびAutoCreateが有効な場合にすでにデータ・ストアが存在していると、TimesTenはそのデータ・ストアを削除して、新しいデータ・ストアを作成します。古いデータ・ストアで作成された表は削除されます。
特定のDSNに接続する場合に、常に同じデータ・ストアにアクセスするようにするには、データ・ストアの相対パス名ではなく、絶対パス名を使用します。 たとえば、demoデータ・ストアがdatastoreディレクトリにある場合は、次のように指定します。
DataStore=/datastore/demo
次のようには指定しません。
DataStore=demo
後者の場合、データ・ストアのパス名はアプリケーションが起動されたディレクトリに対する相対パスです。表を検索できず、またデータ・ストアの相対パス名を使用している場合は、その表が存在するデータ・ストアは存在せず、データ・ストア（チェックポイントおよびログ）・ファイルは、アクセスしているディレクトリとは別のディレクトリに存在する可能性があります。
詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータ・ストアのパス名の指定に関する説明を参照してください。
Windowsでは、NLS_LANG設定が環境にない場合、レジストリから設定が取得されます。 NLS_LANGがサポートされていない値（NAなど）に設定されている場合、OCI接続失敗エラーまたはORA-12705エラーがスローされます。 OCIまたはPro*C/C++プログラムによるTimesTenへの接続に問題がある場合、HKEY_LOCAL_MACHINE\Software\ORACLE\NLS_LANGの設定が有効であること、およびTimesTenでサポートされているキャラクタ・セットを示していることを確認します。 この問題は、Oracle9iまたはそれ以前のバージョンのOracleが以前インストールされたマシンにのみに発生する可能性があります。
NLS_LANGの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』のOCIに関する章のグローバリゼーションのサポートに関する説明を参照してください。
この項では、メモリー領域、ディスク領域、ファイル記述子、セマフォなどのリソースをTimesTenが使い果たしたときに確認する事項を説明します。
| 状態 | 参照先 |
|---|---|
| メモリー消費量が高い | 「オペレーティング・システム・ツールおよび共有メモリー」 |
| メモリー領域を使い果たす |
|
| ディスク領域を使い果たす | 「トランザクション・ログ・ファイルのディスク領域の使用を確認する」 |
| ログ領域を使い果たす | 「トランザクション・ログ・ファイルのディスク領域の使用を確認する」 |
| ファイル記述子を使い果たす | 「使用可能なファイル・ディスクリプタの数を増やす」 |
| セマフォを使い果たす | 「セマフォの制限を確認する」 |
| CPUを使い果たす | スタック・トレースを取得して、テクニカル・サポートに連絡する |
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ユーティリティを-noRepUpgradeオプションとともに使用し、データを外部へ移行した後、データ・ストアを破棄してから再作成し、データを元に戻すことによって、より効率的に行うことができます。この操作の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のデータ・ストア・サイズの縮小に関する説明を参照してください。
最後に、プロセスにより多くの量の共有メモリーが割り当てられるように、オペレーティング・システムを構成する必要がある場合があります。また、仮想メモリーにより多くのスワップ領域を割り当てる必要があることもあります。 詳細は、「使用可能なスワップ領域（仮想メモリー）を確認する」を参照してください。
統計が古いために、いくつかのコマンドで割り当てている領域が多すぎる可能性があります。 詳細は、「問合せオプティマイザの統計を更新する」を参照してください。
統計を更新しても一時セグメントのメモリーの使用量が減らない場合は、すべての接続を切断してから、再接続します。 すべての接続が切断されたかどうかは、ttStatusユーティリティで確認します。これですべての一時領域が解放されますが、コマンドを再準備する必要はあります。
問合せのメモリー使用量を診断します。 詳細は、「問合せで使用されるメモリーを確認する」を参照してください。
問題が繰り返し発生する場合は、データ・ストアを監視して問題の原因を特定します。 ttWarnOnLowMemoryプロシージャを使用して、データ・ストアが一杯になったかどうかを示すユーザー・ログの警告を有効にします。
データ・ストアには十分な空き領域があるように見えても、問合せを実行するとデータ・ストア領域を使い果たしてしまう場合は、ttOptUpdateStatsまたはttOptEstimateStatsプロシージャを使用して、オプティマイザの統計データが更新されていることを確認します。問合せの中には、実行時に一時領域の割当てが必要なものがあります。必要な一時領域の量は、問合せに使用する表の統計から見積もられます。正しい統計データがないと、必要な一時領域が少なく見積もられることがあります。
詳細は、「問合せオプティマイザの使用」を参照してください。
一時メモリー使用量の最高水位標を確認すると、問合せで使用されるメモリーを確認できます。最高水位標は、この水位標が初期化またはリセットされた後で使用された、使用中の一時領域の最大量を表します。
次のタスクを実行します。
ttIsql dssizeコマンドを使用して、TEMP_IN_USE_SIZEおよびTEMP_IN_USE_HIGH_WATERを確認します。 （これらの値はSYS.MONITOR表で問い合せることもできます。）
ttMonitorHighWaterResetプロシージャをコールして、TEMP_IN_USE_HIGH_WATERをTEMP_IN_USE_SIZEの現在の値にリセットします。
問合せを実行します。
dssizeを使用して、TEMP_IN_USE_HIGH_WATERで問合せのピーク時のメモリー使用量を確認します。
スワップ領域を使い果たしたことを示すエラーを受け取った場合は、使用可能なスワップ領域（仮想メモリー）の量を増やす必要があります。
UNIXシステムの場合は、swapコマンドを使用して、現在システムに対して設定されている仮想メモリーの量を確認し、再設定します。
Windowsシステムの場合は、「コントロール パネル」→「システム」→「詳細」を選択して、仮想メモリーのサイズを確認し、再設定します。
TimesTenは、データ・ストア属性で指定されているディレクトリに格納されている2つのチェックポイント・ファイルのいずれかにデータ・ストアのコピーを保存します。各チェックポイント・ファイルはディスク上で大きくなり、共有メモリー内のデータ・ストアのサイズと同等になる可能性があります。 各永続データ・ストアについて、2つのチェックポイント・ファイルとトランザクション・ログ・ファイルを保存するための十分なディスク領域が必要です。
トランザクション・ログ・ファイルはLogDir属性で指定されたディレクトリに蓄積され、チェックポイントが実行されたときにのみ削除されます。 DSNにLogDir属性が指定されていない場合は、データ・ストア属性で指定されたディレクトリにトランザクション・ログ・ファイルが蓄積されます。 トランザクション・ログ・ファイルの最大サイズは、LogFileSize属性で設定されます。
ディスクがTimesTenデータで一杯になる原因のほとんどは、トランザクション・ログ・ファイルの蓄積です。 TimesTenでは、チェックポイント処理、バックアップ、レプリケーションなどの様々な目的でトランザクション・ログ・ファイルが使用されます。 どの操作がトランザクション・ログ・ファイルを保持するかを特定することが重要であり、これによって、トランザクション・ログ・ファイルを適切にパージできるように適切なアクションをとることができます。 これは、ttLogHolds組込みプロシージャを使用して行います。ログの保持には6つのタイプがあります。次の説明を参照してください。
チェックポイント - TimesTenアプリケーションがクラッシュし、データ・ストアをリカバリする必要がある場合、チェックポイント・ファイルとトランザクション・ログ・ファイルを使用してデータをリカバリします。 使用されるトランザクション・ログ・ファイルは、チェックポイント処理以降に作成された最新のトランザクション・ログ・ファイルです。 トランザクション・ログ・ファイルは、チェックポイントとチェックポイントの間に蓄積されます。 アプリケーションでは、定期的にttCkptまたはttCkptBlockingプロシージャをコールして、データのチェックポイント処理を実行し、ディスク領域を解放する必要があります。 チェックポイント処理の頻度が非常に低い場合、特にチェックポイントとチェックポイントの間で多くの変更がデータ・ストアに加えられると、大量のトランザクション・ログ・ファイルが蓄積される可能性があります。 詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のチェックポイントに関する説明を参照してください。
レプリケーション - TimesTenレプリケーションは、あるデータ・ストアから他の1つ以上のデータ・ストアに変更を送信します。これは、ログを読み込み、関連する変更を送信することで行います。 レプリケーションを一時停止すると、トランザクション・ログ・ファイルが蓄積されます。 ログ・ファイルが蓄積されないようにするには、レプリケーションを長期間一時停止しないでください。サブスクリプションを完全に削除して、適切なところでレプリケーションを再設定します。 レプリケーションの一時停止、再起動または再設定の詳細は、『Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド』のサブスクライバのレプリケーション状態の設定に関する説明を参照してください。
バックアップ - 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）に関する説明を参照してください。
長時間実行のトランザクション - TimesTenでは、トランザクション・ログを使用してトランザクションをロールバックします。トランザクションの存続中はログを保持するように設定されます。 長時間アクティブなトランザクションでは、トランザクションがログ・レコードを1つ以上書き込んだ場合（つまり、読取り専用トランザクションではない場合）、ログ・ファイルが蓄積されます。このため、書込みトランザクションは適切な頻度でコミットし、大量のログ・ファイルが蓄積されないようにします。 トランザクションの長さの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』のトランザクションの適切なサイズ調整に関する説明を参照してください。
ディスクの使用には、次の属性が関係します。
LogPurge属性は、保持する必要がなくなったトランザクション・ログ・ファイルをパージ（ディスクから削除）するか、または単にアーカイブ（名前を変更）するかを示します。 LogPurge属性がデフォルト値の0（ゼロ）に設定されている場合、TimesTenは名前の後ろに文字列.archを付加して、不要になったトランザクション・ログ・ファイルの名前を変更します。 名前を変更した後は、不要になったときに手動でトランザクション・ログ・ファイルを削除する必要があります。 トランザクション・ログ・ファイルをパージしないと、TimesTenで不要になったときも、トランザクション・ログ・ファイルが蓄積され続けて領域を浪費します。
Preallocate属性は、接続時にチェックポイント・ファイル用のディスク領域を確保する必要があるかどうかを示します。これは大きなデータ・ストアに有効で、データ・ストアにデータが追加されても、ディスクにチェックポイント・ファイル用の領域が常に確保されていることを保証します。
IPCとしての共有メモリー・セグメントを許可するように構成されたTimesTenデータ・ストアに対する複数のクライアント/サーバー接続を作成する場合、TimesTenでセマフォを作成できなかったことを示すエラーが発生することがあります。
セマフォの制限はプラットフォームに依存しています。 詳細は、オペレーティング・システムのドキュメントおよび『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のセマフォの数の増加に関する説明を参照してください。
コミット読取り分離レベルを使用すると、結果セットで重複する可能性があります。SELECTによるスキャンの実行範囲内でいくつかの行が追加または削除されてコミットされた場合に、SELECT文によって選択される行が、表内の行の合計数より多くなったり、少なくなります。これは、UPDATE、INSERTまたはDELETE文によって索引に対して値の追加または削除が実行され、SELECTによるスキャンでその索引が使用されている場合に発生する可能性があります。また、INSERTまたはDELETEによって表に対して行の追加または削除が実行され、SELECT操作で全表スキャンが使用されている場合も発生する可能性があります。
索引値は順序付けられています。 索引値に対してUPDATEを実行すると、古い値が削除され、新しい値が別の場所に挿入されます。つまり、UPDATEによって、索引内のある位置から別の位置に行が移動されます。索引スキャンでは、両方の位置に同じ行が検出されると、同じ行が2回戻されます。これは、シリアル・スキャンでは発生しません。表ページが順序付けられておらず、UPDATEに対して行を移動する必要がないためです。したがって、スキャンによって渡された行が再度参照されることはありません。
この問題を回避するには、SELECT文でシリアライズ可能分離レベルを使用します。これによって、INSERT、DELETEまたはUPDATEの同時操作を防止できます。INSERTまたはDELETEはすべての索引に影響を及ぼすため、これらの操作で索引を使用してこの問題を回避する信頼性の高い方法はありません。UPDATEの場合は、更新されていない索引をSELECT文で使用してこの問題を回避することができます。
シリアライズ可能分離レベルの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の並行性制御に関する説明を参照してください。
次のいずれかの理由で、エラー8517「Cannot attach PL/SQL shared memory; PLSQL_MEMORY_ADDRESS not valid or already in use」を受信する場合があります。
ユーザーが割り当てたメモリーでそのアドレスがすでに使用されている。
一部の共有メモリーでそのアドレスがすでに使用されている。
共有ライブラリでそのアドレスがすでに使用されている。
リカバリするには、データベースに接続可能なすべてのプロセスで使用されていない仮想アドレスを指定します。 TimesTenに接続する前に多くのメモリを割り当てる32-bitオペレーティング・システムにプログラムがある場合、そのプログラムによってPL/SQL共有メモリー・セグメントがクラッシュする可能性があります。 その場合は、TimesTenに接続した後でメモリを割り当てるか、または64-bitオペレーティング・システムを使用します。
