| Oracle® TimesTen In-Memory Databaseトラブルシューティング・ガイド 11g リリース2(11.2.2) B66722-02 |
|
 前 |
 次 |
次の項では、TimesTenデータベースの使用時に発生する問題のいくつかについて、その診断や解決に役立つ情報を説明します。
|
注意: この章に示すトラブルシューティングを実行した後もデータベースの問題が解決しない場合は、テクニカル・サポートに連絡してください。 |
この項では、TimesTenのメイン・デーモンを起動または停止できないときに確認する事項を説明します。
| 考えられる原因 | 対処 |
|---|---|
| 権限が不適切である | TimesTenデーモンを起動または停止するには、ADMIN権限が必要です。デーモンを起動するためにttDaemonAdminユーティリティを使用していることを確認します。ttDaemonAdminの出力には、適切な権限があるかどうかが表示されます。 |
| 別のプロセスがTimesTenデーモン・ポートを使用している。 | ttVersionユーティリティを使用して、TimesTenデーモンが使用するポート番号を確認します。netstatのようなオペレーティング・システム・コマンドを使用して、別のプロセスがそのポートをリスニングしているかどうかを確認します。競合している場合は、他のプロセスで使用するポート番号を変更するか、または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) 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
コア・ファイルが見つかった場合は、システムのデバッガにアタッチし、コア・ファイルからスタック・トレースを抽出して、その結果をテクニカル・サポートに送付します。
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インストレーション・ガイド』のTimesTenのアップグレードに関する説明を参照してください。
ユーザーは、データベースに接続するには、CREATE SESSION権限を持っている必要があります。アクセス権がない場合は、管理者から、GRANT文を使用してCREATE SESSION権限を付与される必要があります。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースに接続する権限の付与に関する説明を参照してください。
データベースに接続しようとした場合に、チェックポイントまたはトランザクション・ログ・ファイル、あるいはそれらのファイルがあるディレクトリへの適切なアクセス権がないと、権限が拒否されたことを示すエラーが生成されます。DSNのDataStore属性に指定されているディレクトリに格納されているファイルに対するファイル・システム権限を確認します。
TimesTenデーモンまたはData Managerサービスが稼働していないときにデータベースに接続しようとすると、TimesTenエラー799「Unable to connect to daemon; check daemon status」が生成されます。
「TimesTenユーザー・エラー・ログを確認する」を参照し、ttStatusユーティリティを使用して、TimesTenデーモンのステータスを確認します。
DSNを記述する際は、次のことを行ってください。
特定の接続オプションまたはDSN属性の設定の組合せに互換性がありません。互換性のない設定を使用してデータベースに接続しようとすると、アプリケーションにエラーが返されます。
DSNのDataStoreおよびLogDir属性に正しいパス名が指定されていることを確認します。また、パス名は相対パス名ではなく、絶対パス名であることも確認します。絶対パス名を指定しないと、パス名は、アプリケーションが起動されたディレクトリに対する相対パスになります。
Windowsの場合、ODBCデータソース・アドミニストレータのユーザー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の値を小さくします。詳細は、「データベースに割り当てられたメモリーの量を確認する」を参照してください。共有メモリー・セグメントのサイズを大きくするその他のオプションについては、次の説明を参照してください。
システム障害またはアプリケーション障害が原因でデータベースが無効になると、後続の接続によってデータベースがリカバリされます。データベース領域を使い果たしたためにリカバリが失敗した場合は、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オペレーション・ガイド』のWindows上での論理サーバー名の作成および構成に関する説明を参照してください。
このエラーは、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.2 CLIENT]Failed to attach to shared memory segment for IPC. System error: 24
これは、クライアントDSNへの接続処理中、システムに定義されているプロセス当たりのファイル記述子の制限を超えるオープン・ファイル記述子がアプリケーションに含まれていることが原因でshmatシステム・コールが失敗した場合に発生する可能性があります。この問題を修正するには、プロセス当たりのファイル記述子の制限を増加する必要があります。ファイル記述子の制限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のシステムの制限に関する説明を参照してください。
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オペレーション・ガイド』のTimesTenのデータベースのパフォーマンス・チューニングに関する説明
『Oracle TimesTen In-Memory Database C開発者ガイド』のアプリケーションのチューニングに関する説明
『Oracle TimesTen In-Memory Database 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のパフォーマンスが悪い」 |
| 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つのみです。
表当たりのパーティション数の制限は999です。この数を超えるとエラー8204が生成されます。新しいパーティションそれぞれに対して追加の読取りが行われるため、新しいパーティションのパフォーマンスがそれぞれ少し低下します。パーティション数は多くしないようにする必要があります。複数のパーティションを持つレプリケートされた表では、サブスクライバ側で更新を行うたびにパーティション数に比例して追加の領域が使用されます。このため、サブスクライバではマスターより少し多くの永続領域が使用される場合があります。
各表のパーティション値は、システム表SYS.TABLESの列SYS16で追跡されます。表のパーティション数は、次の問合せで取得します。
SELECT tblname, sys16 FROM SYS.TABLES;
表に含まれるパーティションが多すぎることが検出された場合は、次のいずれかを行います。
表の再作成
表の保存およびリストア。ttMigrate -cを使用して、移行ファイルを作成します。その後、ttMigrate -r -relaxedUpgradeを使用して、パーティションを追加せずに表をリストアします。
ALTER TABLE ... DROP COLUMNでは、表からパーティションは削除されません。レプリケートされたシステムでは、-relaxedUpgradeオプションを使用してすべてのマスター・データベースおよびサブスクライバ・データベースを移行する必要があります。異なるパーティション構造の表では、レプリケーションは発生しません。
この項では、アプリケーションからのレスポンスがなく、ハングしている可能性があるときに確認する事項を説明します。
| 考えられる原因 | 参照先 |
|---|---|
| すべての原因 | 「ログを確認し、トレース情報を収集する」 |
| 内部アプリケーション・エラーが発生した | 「ODBCエラーを確認する」 |
| DSNに設定した接続属性が一貫していない | 「接続モードを検討する」 |
| ロックの競合が過剰である | 「デッドロックとタイムアウトを確認する」 |
アプリケーションがハングした場合、ttXactAdminユーティリティを使用してトランザクション・ログを確認します。詳細は、「ttXactAdminユーティリティの使用」を参照してください。
また、エラーのユーザー・エラー・ログ(「TimesTenデーモンによって生成されたログの使用」を参照)を確認します。
また、「ttTraceMonユーティリティの使用」を参照して、トレース・ログを生成して、様々なTimesTenコンポーネントのアクティビティを検出することもできます。
すべてのアプリケーションで、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オペレーション・ガイド』のTimesTenデータベースを識別するためのデータ・ソース名の識別方法に関する説明を参照してください。
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ユーティリティ-relaxedUpgradeオプションを使用してデータを外部に移行し、データベースを廃棄、再生成してから元に戻すと、より効果的です。この操作については、『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システムの場合は、「コントロール パネル」→「システム」→「詳細」を選択して、仮想メモリーのサイズを確認し、再設定します。
エラー846および994などの致命的なエラーが発生した場合、TimesTenデータベースは無効化されます。ただし、データベースはメモリー内に残り、すべてのユーザーがデータベース切断したときに解放されます。ユーザーが無効化されたデータベースに接続している間にデータベースを再起動した場合、古いインスタンスと新しいインスタンスの両方が同時にメモリーに存在します。この場合、ユーザーは、メモリー不足の状態を知らせる通知を受け取る場合があります。メモリー不足のエラーを防ぐには、致命的なエラーが発生したときにすべての有効な接続を切断してから再接続します。
TimesTenは、DataStore属性で指定されているディレクトリに格納されている2つのチェックポイント・ファイルのいずれかにデータベースのコピーを保存します。各チェックポイント・ファイルはディスク上で大きくなり、共有メモリー内のデータベースのサイズと同等になる可能性があります。各永続データベースについて、2つのチェックポイント・ファイルとトランザクション・ログ・ファイルを保存するための十分なディスク領域が必要です。
トランザクション・ログ・ファイルはLogDir属性で指定されたディレクトリに蓄積され、チェックポイントが実行されたときにのみ削除されます。DSNにLogDir属性が指定されていない場合は、DataStore属性で指定されたディレクトリにトランザクション・ログ・ファイルが蓄積されます。トランザクション・ログ・ファイルの最大サイズは、LogFileSize属性で設定されます。
ディスクがTimesTenデータで一杯になる原因のほとんどは、トランザクション・ログ・ファイルの蓄積です。TimesTenでは、チェックポイント処理、バックアップ、レプリケーションなどの様々な目的でトランザクション・ログ・ファイルが使用されます。どの操作がトランザクション・ログ・ファイルを保持するかを特定することが重要であり、これによって、トランザクション・ログ・ファイルを適切にパージできるように適切なアクションをとることができます。これは、ttLogHolds組込みプロシージャを使用して行います。ログの保持には6つのタイプがあります。次の説明を参照してください。
チェックポイント - TimesTenアプリケーションがクラッシュし、データベースをリカバリする必要がある場合、チェックポイント・ファイルとトランザクション・ログ・ファイルを使用してデータをリカバリします。使用されるトランザクション・ログ・ファイルは、チェックポイント処理以降に作成された最新のトランザクション・ログ・ファイルです。トランザクション・ログ・ファイルは、チェックポイントとチェックポイントの間に蓄積されます。アプリケーションでは、定期的にttCkptまたはttCkptBlockingプロシージャをコールして、データのチェックポイント処理を実行し、ディスク領域を解放する必要があります。チェックポイント処理の頻度が非常に低い場合、特にチェックポイントとチェックポイントの間で多くの変更がデータベースに加えられると、大量のトランザクション・ログ・ファイルが蓄積される可能性があります。『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の分散トランザクション処理に関する項を参照してください。
長時間実行のトランザクション - TimesTenでは、トランザクション・ログを使用してトランザクションをロールバックします。トランザクションの存続中はログを保持するように設定されます。長時間アクティブなトランザクションでは、トランザクションがログ・レコードを1つ以上書き込んだ場合(つまり、読取り専用トランザクションではない場合)、ログ・ファイルが蓄積されます。(つまり、読取り専用トランザクションではありません。)このため、書込みトランザクションは適切な頻度でコミットし、大量のログ・ファイルが蓄積されないようにします。トランザクションの長さの詳細は、Oracle TimesTen In-Memory Databaseオペレーションガイドのトランザクションの適切なサイズ設定に関する説明を参照してください。
ディスクの使用には、次の属性が関係します。
LogPurge属性は、保持する必要がなくなったトランザクション・ログ・ファイルをパージ(ディスクから削除)するか、または単にアーカイブ(名前を変更)するかを示します。LogPurge属性がデフォルト値の0(ゼロ)に設定されている場合、TimesTenは名前の後ろに文字列.archを付加して、不要になったトランザクション・ログ・ファイルの名前を変更します。名前を変更した後は、不要になったときに手動でトランザクション・ログ・ファイルを削除する必要があります。トランザクション・ログ・ファイルをパージしないと、TimesTenで不要になったときも、トランザクション・ログ・ファイルが蓄積され続けて領域を浪費します。
Preallocate属性は、接続時にチェックポイント・ファイル用のディスク領域を確保する必要があるかどうかを示します。これは、大規模なデータベースで、データをデータベースに追加するときに、チェックポイントファイルにディスクの空き容量が常にあるかを確認するのに役立ちます。
ファイルへのトレースが有効化されている場合、ファイルが非常に大きくなるため、操作を試みるプロセスがファイル制限を超えてしまう可能性があります。トレースは必ず既存のファイルに追加されます。
一部のプラットフォームでは、ファイルサイズは2Gに制限されています。この制限に達した場合、SIGXFSZサインを受け取らないかぎり、プロセスは終了します。「FILESIZE LIMIT EXCEEDED」というエラーが表示されます。ファイルサイズ制限が厳しい環境を使用する場合は、トレースの有効化が必要かどうか確認してください。
IPCとしての共有メモリー・セグメントを許可するように構成されたTimesTenデータベースに対する複数のクライアント/サーバー接続を作成する場合、TimesTenでセマフォを作成できなかったことを示すエラーが発生することがあります。
セマフォの制限はプラットフォームに依存しています。オペレーティング・システムのドキュメントを参照してください。
コミット読取り分離レベルを使用すると、結果セットで重複する可能性があります。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オペレーション・ガイド』の分離およびロックによる並行性制御に関する説明を参照してください。
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属性のデフォルト設定を変更する必要があります。
