次の項では、TimesTenデータベースの使用時に発生する問題のいくつかについて、その診断や解決に役立つ情報を説明します。
ノート: この章に示すトラブルシューティングを実行した後もデータベースの問題が解決しない場合は、TimesTenカスタマ・サポートに連絡してください。 |
この項では、TimesTenのメイン・デーモンを起動または停止できないときに確認する事項を説明します。
考えられる原因 | 対処 |
---|---|
権限が不適切である。 | TimesTenデーモンを起動または停止するには、ADMIN 権限が必要です。デーモンを起動するためにttDaemonAdmin ユーティリティを使用していることを確認します。ttDaemonAdmin の出力には、適切な権限があるかどうかが表示されます。 |
別のプロセスがTimesTenデーモン・ポートを使用している。 | ttVersion ユーティリティを使用して、TimesTenデーモンが使用するポート番号を確認します。netstat のようなオペレーティング・システム・コマンドを使用して、別のプロセスがそのポートをリスニングしているかどうかを確認します。競合している場合は、他のプロセスで使用するポート番号を変更します。 |
TimesTenデーモンがすでに稼働している | デーモンを起動するためにttDaemonAdmin ユーティリティを使用していることを確認します。ttDaemonAdmin の出力には、デーモンがすでに稼働しているかどうかが表示されます。 |
その他の問題がある。 | デーモンによって作成されるユーザー・エラー・ログを調べます。 |
次の項では、1つ以上のTimesTenプロセスが利用できないように思われる場合の対処方法について説明します。
TimesTenサブデーモンが停止したことを示すエラーを受信した場合、ユーザー・エラー・ログを調べます。
TimesTenデーモンがクラッシュした場合、そのTimesTenデーモンからユーザー・エラー・ログに送信を行うことはできませんが、サブデーモンでは、メイン・デーモンがクラッシュしたことを示すメッセージをログに送信してから終了します。
09:24:13 Err : 4375 ------------------: Main daemon has vanished
デーモンを再起動します。次に各データベースに接続すると、TimesTenはチェックポイントおよびトランザクション・ログ・ファイルからリカバリを実行します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデーモンの処理に関する項を参照してください。
LinuxまたはUNIXシステムでいずれかのTimesTenプロセスによってクラッシュが発生し、すべての診断方法を試しても問題が解決しない場合は、TimesTenがコア・ファイルを生成していないかを確認します。ttVersion
ユーティリティを使用してコア・ファイルを検索します。出力でデーモン・ホーム・ディレクトリのパスを示す行を検索します。
TimesTen Release (ttuser:40732) 2011-04-04T17:53:04Z Instance admin: ttuser Instance home directory: /node1/ttuser/ttcur/TTBuild/linux8664_dbg/install Daemon home directory: /node1/ttuser/ttcur/TTBuild/linux8664_dbg/install/info
コア・ファイルが見つかった場合は、システムのデバッガにアタッチし、コア・ファイルからスタック・トレースを抽出して、その結果を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またはUNIXの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 Classicのアップグレードを参照してください。
ユーザーは、データベースに接続するには、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
属性に正しいパス名が指定されていることを確認します。また、パス名は相対パス名ではなく、絶対パス名であることも確認します。絶対パス名を指定しないと、パス名は、アプリケーションが起動されたディレクトリに対する相対パスになります。
接続または作成しようとする共有データベースのサイズが、システムに構成された共有メモリー・セグメントの最大サイズより大きいと、エラーが返されます。また、システムが共有メモリー・セグメントをそれ以上割り当てることができない場合もエラーが返されます。
Linuxおよび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
の値を現在の値より大きくして、データベースに再接続します。
共有メモリーの構成方法の詳細は、Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのオペレーティング・システムの前提条件を参照してください。
共有メモリーをバックアップするのに十分なスワップ領域が必要です。
LinuxおよびUNIXシステムの場合は、swapコマンドを使用して仮想メモリーを確認し、システムに追加できます。
TimesTenデータベースに接続されている各プロセスは、1つ以上のオペレーティング・システム・ファイル記述子をオープンしたままにします。接続によってトランザクションがコミットまたはロールバックされる場合、接続に対してさらにファイル記述子をオープンすることができます。データベースに接続しようとしたときに、ファイル記述子がすべて使用中であるというエラーを受信した場合は、ファイル記述子の許容数を増やします。ファイル記述子の制限およびファイル記述子の数の変更については、オペレーティング・システムのドキュメントを参照してください。『Oracle TimesTen In-Memory Databaseリファレンス』のオープン・ファイルの数の制限に関する項も参照してください。
この項の内容は次のとおりです。
「アプリケーションがダイレクト・モードでデータベースに接続できない」の項に記載のトピックについても検討してください。
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オペレーション・ガイドで、この問題の識別方法の詳細について接続のテストを参照してください。
Linuxおよび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オペレーション・ガイド』の接続のテストに関する説明を参照してください。
サーバーのログ・ファイルを確認します。TimesTenデーモン構成ファイルの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のLinuxおよびUNIXでのクライアントDSNの作成および構成に関する項およびTimesTenデーモン属性の管理に関する項を参照してください。
特定のTimesTenインスタンスのサーバーに対する同時IPC接続の最大数は24,999です。ただし、単一のDSNへの接続数(直接またはクライアント/サーバー)は2043に制限されます。
クライアント/サーバーのユーザーは、ファイル記述子の制限を変更してより多くの接続数に対応できます。
LinuxおよびUNIXの場合、TimesTen Serverが稼働しているシステム上のsys.odbc.ini
ファイルでサーバーDSNが正しく定義されていることを確認します。
Windowsの場合、TimesTen Serverが稼働しているシステムのODBCデータソース・アドミニストレータでサーバーDSNがシステムDSNとして定義されていることを確認します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のWindows上での論理サーバー名の作成および構成に関する説明を参照してください。
このエラーは、LinuxまたはUNIXシステムでのみ発生します。TimesTen Serverが稼働しているシステムでsys.odbc.ini
ファイルを開き、接続しようとしているサーバーDSNの場所を確認します。サーバーDSNのDRIVER
属性に指定した動的ライブラリが存在し、実行可能であることを確認します。
デフォルトのTimeOut
時間は、60秒です。
LinuxまたはUNIXでこの間隔を長くするには、odbc.ini
ファイルのTTC_Timeout
属性の値を変更します。
エラーの原因がクライアントのタイムアウトかどうかを確認します。TimesTen Serverのログを確認して、サーバーがクライアントとの接続を切断した原因を調べます。pingを使用してネットワークが機能しているかどうかを確認するか、またはtelnet
を使用してTimesTen Serverのポート番号に接続を試行します。
共有メモリー・セグメント(SHM)をIPCとして使用している際に、TimesTen Client ODBCドライバからの次のエラー・メッセージがアプリケーションに表示される場合があります(アプリケーションがシステムに定義されているプロセス当たりのファイル記述子の制限に達した場合)。
SQLState = S1000, Native Error = 0, Message = [TimesTen][TimesTen 18.1 CLIENT]Failed to attach to shared memory segment for IPC. System error: 24
これは、クライアントDSNへの接続処理中、システムに定義されているプロセス当たりのファイル記述子の制限を超えるオープン・ファイル記述子がアプリケーションに含まれていることが原因でshmat
システム・コールが失敗した場合に発生する可能性があります。この問題を修正するには、プロセス当たりのファイル記述子の制限を増加する必要があります。ファイル記述子の制限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のシステムの制限に関する説明を参照してください。
スレッド・スタックのオーバーフローの可能性を示すセグメンテーション障害についてのメッセージが表示される場合があります。
これらのメッセージが表示された場合は、次のいずれかの方法で、サーバー・スタックのサイズを大きくします。
/conf/timesten.conf
ファイルでserver_stack_size
オプションを指定します。
特定のDSNのServerStackSize
接続属性を指定します。この設定は、/conf/timesten.conf
ファイルの値より優先されます。
サーバー・スタックのサイズを大きくすると、スワップ領域を使い果たす前に確立可能な同時接続数が減ります。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen ClientおよびTimesTen Serverの使用に関する項を参照してください。
複数のクライアント接続を持つシステムでは、DSNを変更して新しいデータベースを指定する際に、元のデータベースへの接続が確立されたままの場合に、領域不足であることを示すメッセージが表示されることがあります。
元のデータベースへのすべての接続をクローズします。これにより、現在DSNで指定されているデータベースへの接続に対し、新しいサーバー・プロセスが作成されます。ttStatus
ユーティリティを使用すると、古いデータベースへの接続を表示できます。または、-restartServer
オプションを指定してttDaemonAdmin
ユーティリティを使用すると、サーバーを再起動して、インスタンス内のすべてのDSNですべてのクライアント接続をリセットできます。
この項では、データベースとの接続や切断に時間がかかるときに確認する事項を説明します。まず、ramPolicy
設定を確認します。ramPolicy
設定がinUse
で、他にユーザーがいない場合、最初の接続で、データベース全体がメモリーにロードされます。ramPolicy
を、always
またはmanual
のいずれかに変更してください。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する項を参照してください。
考えられる原因 | 参照先 |
---|---|
データベースがリカバリ中である | 後述の「データベースがリカバリ中であるかどうかを確認する」 |
ODBCトレースが有効になっている | 後述の「ODBCトレースの確認」 |
その他の考えられる原因。 | 「APIトレース」 |
接続に時間がかかるということは、TimesTenデータベースがリカバリ中であることを示している可能性があります。これは初期接続時にのみ発生します。
Windowsプラットフォームでは、ODBCトレースが有効になっていると、接続および切断の処理速度が遅くなる可能性があります。コントロール・パネルの「ODBC」をダブルクリックして、ODBCデータソース・アドミニストレータを開きます。「トレース」タブを選択して、トレースが無効になっていることを確認します。「ODBCトレースの使用」を参照してください。
アプリケーションがTimesTenデータベースから切断される場合は、次のイベントのいずれかが発生します。
未解決のトランザクションがなかった場合、その接続はTimesTenデーモンによって完全に削除されます。その他の既存の接続は、問題が発生しなかったように、処理を継続します。
未解決のトランザクションがある場合、トランザクションはロールバックされ、接続はTimesTenデーモンによって完全に削除されます。その他の既存の接続は、問題が発生しなかったように、処理を継続します。
この項では、アプリケーションがデータベースとの接続を予期せず切断したときに確認する事項を説明します。
考えられる原因 | 参照先 |
---|---|
内部アプリケーション・エラーが発生した。 | 後述の「ODBC、JDBC、OCI、Pro*CおよびPL/SQLアプリケーション・エラーの確認」 |
アプリケーションの同時処理スレッドで障害が発生した。 | 後述の「ODBC、JDBC、OCI、Pro*CおよびPL/SQLアプリケーション・エラーの確認」 |
クライアント/サーバー接続を使用している場合に、クライアントがアプリケーションから切断された | 「クライアント/サーバーの問題のトラブルシューティング」 |
TimesTenライブラリでエラーが発生した。 | Oracleサポート・サービスに連絡してください。 |
次のタイプのエラーを確認します。
SQLError
ファンクションによって返されるODBCエラー
SQLException
クラスによって返されるJDBCエラー
TimesTen OCIおよびPro*Cアプリケーションと、PL/SQLを使用するアプリケーションでは、TimesTenエラー・コードではなくOracle Databaseエラー・コードを使用してエラーがレポートされます。エラー・コードに付随するエラー・メッセージは、TimesTenエラー・カタログから取得される場合とOracle Databaseエラー・カタログから取得される場合があります。
デフォルトで、TimesTenメッセージおよび診断情報は、次のように格納されます。
エラー・メッセージ情報を含むユーザー・エラー・ログ。通常、これらのメッセージには、必要な処置に関する情報が含まれています。デフォルトのファイルは、timesten_home
/diag/tterrors.log
です。ユーザー・エラー・ログの場所の変更の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のエラー、警告および情報のメッセージに関する説明を参照してください。
ユーザー・エラー・ログに含まれるすべての情報に加えて、TimesTenカスタマ・サポートによって使用される情報が含まれるサポート・ログ。デフォルトのファイルは、timesten_home
/diag/ttmesg.log
です。ユーザー・エラー・ログの場所の変更の詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のエラー、警告および情報のメッセージに関する説明を参照してください。
TimesTenがデータベースを無効化した場合の無効化ファイルの診断情報。このファイルには、TimesTenカスタマ・サポートで役に立つトラブルシューティング情報が含まれます。無効化ファイルは、DataStore
接続属性により指定される値に基づいて作成され、名づけられます。接続属性はファイル名ではありません。たとえば、LinuxおよびUNIXシステムでは、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オペレーション・ガイド』のインライン列とアウトライン列に関する説明。 |
マテリアライズド・ビューが適切に構成されていない。 | 『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コンポーネントのアクティビティを検出することもできます。
すべてのアプリケーションで、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に指定したパス名が相対的である | 後述の「データベースへのパス名を確認する」 |
一時データベース(DSN属性: Temporary
=1)は、データベースとの接続がすべて削除されるまで存続します。一時データベースの表にアクセスしようとしたときに、その表が存在しない場合、その表が存在したデータベースは削除されてしまっている可能性があります。
DSN属性のOverwrite
およびAutoCreate
が有効な場合にすでにデータベースが存在していると、TimesTenはそのデータベースを削除して、新しいデータベースを作成します。古いデータベースで作成された表は削除されます。
特定のDSNに接続する場合に、常に同じデータベースにアクセスするようにするには、データベースの相対パス名ではなく、絶対パス名を使用します。たとえば、demoデータベースがdatastore
ディレクトリにある場合は、次のように指定します。
DataStore=/datastore/demo
次のようには指定しません。
DataStore=demo
後者の場合、データベースのパス名は、アプリケーションが起動されたディレクトリに対する相対パス名です。表を検索できず、またデータベースの相対パス名を使用している場合は、その表が存在するデータベースは存在せず、データベース(チェックポイントおよびログ)ファイルは、アクセスしているディレクトリとは別のディレクトリに存在する可能性があります。
『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenデータベースを識別するためのデータ・ソース名の識別方法に関する説明を参照してください。
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
オプションを使用してデータを外部に移行し、データベースを廃棄、再生成してから元に戻すと、より効果的です。
最後に、プロセスにより多くの量の共有メモリーが割り当てられるように、オペレーティング・システムを構成する必要がある場合があります。また、仮想メモリーにより多くのスワップ領域を割り当てる必要があることもあります。
統計が古いために、いくつかのコマンドで割り当てている領域が多すぎる可能性があります。詳細は、次の項で説明する「問合せオプティマイザの統計を更新する」を参照してください。
統計を更新しても一時メモリー領域が減らない場合は、すべての接続を切断してから、再接続します。すべての接続が切断されたかどうかは、ttStatus
ユーティリティで確認します。これですべての一時領域が解放されますが、コマンドを再準備する必要はあります。
問合せのメモリー使用量を診断します。後述の「問合せで使用されるメモリーを確認する」を参照してください。
ttOptUpdateStats
またはttOptEstimateStats
プロシージャを使用して、最適化統計を更新していることを確認してください。問合せの中には、実行時に一時領域の割当てが必要なものがあります。必要な一時領域の量は、問合せに使用する表の統計から見積もられます。正しい統計データがないと、必要な一時領域が少なく見積もられることがあります。
詳細は、「問合せオプティマイザの使用」を参照してください。
一時メモリー使用量の最高水位標を確認すると、問合せで使用されるメモリーを確認できます。最高水位標は、この水位標が初期化またはリセットされた後で使用された、使用中の一時領域の最大量を表します。
次のタスクを実行します。
ttIsql
dssize
コマンドを使用して、TEMP_IN_USE_SIZE
およびTEMP_IN_USE_HIGH_WATER
を確認します。これらの値はSYS.SYSTEMSTATS
表またはSYS.MONITOR
表で問い合せることもできます。
ttMonitorHighWaterReset
プロシージャをコールして、TEMP_IN_USE_HIGH_WATER
をTEMP_IN_USE_SIZE
の現在の値にリセットします。
問合せを実行します。
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インストレーション、移行およびアップグレード・ガイドのTimesTen Classicでのデータのバックアップ、リストアおよびリカバリを参照してください。
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
文によって選択される行が、表内の行の合計数より多くなったり、少なくなります。これは、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を受信する場合があります。
ユーザーが割り当てたメモリーでそのアドレスがすでに使用されている。
一部の共有メモリーでそのアドレスがすでに使用されている。
共有ライブラリでそのアドレスがすでに使用されている。
アプリケーションが2つ以上のTimesTenデータベースに同時に接続する場合、デフォルト設定では、PL/SQLメモリー・アドレスをすべてのTimesTenデータベースに対して同じアドレスにマッピングするため、いずれか1つを除くすべてのTimesTenデータベースのPLSQL_MEMORY_ADDRESS
属性のデフォルト設定を変更する必要があります。