| Oracle® TimesTen In-Memory Databaseオペレーション・ガイド 11gリリース2 (11.2.2) B66441-07 |
|
 前 |
 次 |
TimesTen Data Managerを使用したアプリケーションは、従来のDBMSを使用したアプリケーションと比較すると、データ・アクセスのパフォーマンスが数倍向上します。ただし、アプリケーションの設計とチューニングが適切でなければ、TimesTenのメリットを活かしきれない場合もあります。この章では、TimesTenアプリケーションのパフォーマンスに影響する要因について説明します。この要因には、データ変換のように影響の少ないものから、実行時のコマンド準備などのように影響が大きいものまで様々な要因があります。
この章では、あらゆる要因を説明します。これらの要因では、次のような設問が重要になります。
どのようにして問題を検出するか。
パフォーマンスへの潜在的な影響はどの程度か。
パフォーマンスが向上するタイミングはいつか。
パフォーマンスの代償は何か。
次の項では、パフォーマンスの問題をチューニングし特定する方法について説明します。
|
注意: パフォーマンス上の問題は、SYS.SYSTEMSTATS表を調査することによっても特定できます。 |
TimesTen Javaアプリケーションのチューニングの詳細は、『Oracle TimesTen In-Memory Database Java開発者ガイド』の「Javaアプリケーションのチューニング」に関する説明を参照してください。TimesTen Cアプリケーションのチューニングの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』の「ODBCアプリケーションのチューニング」に関する説明を参照してください。
次の項では、システムおよびデータベースのチューニングに関するヒントを示します。
パフォーマンスへの影響: 大
データベース全体がメイン・メモリーに収まるように、システムを構成してください。仮想メモリーを使用すると、パフォーマンスが大幅に低下します。パフォーマンス監視ツールによって、過度のページングや仮想メモリー・アクティビティが示される場合は、データベース(作業セット)のサイズは適切ではありません。
大容量の共有メモリーをプロセスに割り当てるには、物理メモリーの追加やシステム・ソフトウェアの設定が必要な場合もあります。データベース内の表のサイズ見積りには、TimesTenのttSizeユーティリティを使用できます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttSize」を参照してください。
パフォーマンスへの影響: 不定
データベースの作成時には、そのサイズを指定する必要があります。具体的には、データベースの永続メモリー領域および一時パーティションのサイズを指定します。データベースおよび共有メモリーのサイズを指定する方法の詳細は、「データベースのサイズの指定」を参照してください。
パフォーマンスへの影響: 不定
PL/SQLランタイム・システムでは、TimesTenのPL/SQLオブジェクトに関するメタデータ、および現在実行中のPL/SQLプログラム・ユニットまたは最近実行されたPL/SQLプログラム・ユニットの実行可能コードの保持に、共有メモリーの領域が使用されます。この共有メモリー領域のサイズは、PLSQL_MEMORY_SIZE初期接続属性によって制御されます。
|
注意: PL/SQL (PLSQL=1)を有効にすると、PL/SQLを使用しない場合でも、固定オーバーヘッドと接続ごとのオーバーヘッドの両方がPL/SQLセグメントから自動的に割り当てられます。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のPLSQL_MEMORY_SIZEに関する説明を参照してください。 |
新しいPL/SQLプログラム・ユニットは、実行の準備時に共有メモリーにロードされます。共有メモリー領域を使用できない場合は、十分な共有メモリー領域を使用できるようになるまで、キャッシュされている最近実行されたプログラム・ユニットがメモリーから廃棄されます。現在実行中のプログラム・ユニットによってすべてのPL/SQL共有メモリーが使用されている場合、新しい接続でPL/SQLの実行を試行すると、領域不足のエラー(ORA-04031など)が発生する可能性があります。この場合は、PLSQL_MEMORY_SIZEを増やします。
そのような領域不足のエラーが発生しなくても、PLSQL_MEMORY_SIZEが小さすぎる場合があります。共有メモリーにキャッシュされているPL/SQLプロシージャを実行する方が、キャッシュされていないPL/SQLプロシージャを実行するよりCPU時間において低コストになります。本番アプリケーションでは、PLSQL_MEMORY_SIZEの値を十分に大きく設定して、頻繁に実行されるPL/SQLユニットが常にキャッシュされるようにする必要があります。TimesTenの組込みプロシージャttPLSQLMemoryStatsを使用すると、この状況が発生する頻度を判断できます。PinHitRatio値として、0から1の間の実数が返されます。
1.0: すべてのPL/SQLがキャッシュから実行されたことを意味します。
0.0: 実行ごとに、プログラム・ユニットを共有メモリーにロードする必要があったことを意味します。
PLSQL_MEMORY_SIZEの適切な値は、アプリケーションによって異なります。非常に少数のPL/SQLプログラム・ユニットが繰り返し実行される場合、必要なサイズは小さい可能性があります。数百のPL/SQLプログラム・ユニットを使用するアプリケーションの場合、必要なメモリーは大きくなります。
PinHitRatioの値が大きくなると、パフォーマンスは大幅に向上します。アプリケーション・プログラムで多数のPL/SQLストアド・プロシージャを繰り返し実行して、一連の検証を行いました。PLSQL_MEMORY_SIZEに大きい値を設定した場合、このアプリケーションのPinHitRatioは約90%となり、1つのPL/SQLプロシージャの平均実行時間は0.02秒となりました。PLSQL_MEMORY_SIZEに小さい値を設定した場合、キャッシュの競合が増加したため、PinHitRatioは66%となりました。この検証における平均実行時間は、0.26秒でした。
PLSQL_MEMORY_SIZEのデフォルト値は、UNIXシステムは32MBで、Windows 32-bitシステムは32MBです。この値は、適度に複雑な数百個のPL/SQLプログラム・ユニットの実行に十分なサイズです。本番のワークロードでしばらく実行した後、PinHitRatioの値を確認します。値が0.90より小さい場合は、PLSQL_MEMORY_SIZEを増やすことを検討してください。
パフォーマンスへの影響: 大
ログ・バッファ待機は、アプリケーション処理が、トランザクション・データをログ・バッファに挿入できず、停止してログ・バッファ領域が解放されるのを待機する必要があるときに発生します。通常この理由は、ログ・フラッシャ・スレッドが十分な速さでデータをクリアしていなかったためです。これは、ログ・バッファ領域が不十分、ディスク帯域幅が不十分、ディスクへの書込みに時間がかかりすぎる、またはログ・フラッシャがCPUの能力に依存していることを示していることが考えられます。
LogBufMBおよびLogFileSizeの値を大きくすると、パフォーマンスが大幅に向上する可能性があります。LOG_BUFFER_WAITSが大きくなっている場合は、LogBufMBの値を大きくします。LogBufMbおよびLogFileSizeの値を大きくした後もログ・バッファ待機が続いている場合、前述のその他の起こり得る可能性のある問題を確認してください。
LogBufMbの値を大きくすることで生じるデメリットは、メモリーにバッファされるトランザクションが増え、プロセスがクラッシュしたときに失われるトランザクションが多くなる可能性があることです。DurableCommitsが有効になっている場合は、デフォルトのLogBufMB値を大きくしてもパフォーマンスは改善されません。
|
注意: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のLogBufMBおよびLogFileSizeに関する説明を参照してください。 |
パフォーマンスへの影響: 不定
TimesTenデータベースは、永続データベースまたは一時データベースにできます。一時データベースは、最後の接続を解放した場合、あるいはシステムまたはアプリケーションに障害がある場合に破棄されます。一時データベースの詳細は、「データベースの概要」の説明を参照してください。
データベースをディスクに保存する必要がない場合は、一時データベースを作成することで、チェックポイントのオーバーヘッドを軽減できます。
トランザクション・ログは定期的にディスクに書き込まれますが、一時データベースは、完全にチェックポイントでディスクに書き込まれることはありません。一時データベースのトランザクション・ログに書き込まれるデータの量は、永続データベースに対して書き込まれるデータの量よりも少ないため、一時データベースの方がパフォーマンスは向上します。永続データベースの場合、データベースのサイズとアクティビティによっては、チェックポイント処理がかなりのオーバーヘッドとなる可能性がありますが、一時データベースの場合は、影響はほとんどありません。トランザクション・ログ・ファイルを削除するには、チェックポイントが必要になります。
パフォーマンスへの影響: 大
デフォルトでは、最初の接続が確立されたときにはアイドル・データベース(接続のないデータベース)がメモリーにロードされます。最後のアプリケーションのデータベースへの接続が切断されると、ディスクへのデータベースの書込み時に遅延が発生します。アプリケーションとデータベース間の接続と切断が連続して行われる場合は、メモリーへのデータベースのロードとアンロードも連続して行われる可能性があるため、過度のディスクI/Oおよびパフォーマンスの低下が発生します。同様に、使用するデータベースが非常に大きい場合は、アプリケーションでデータベースが使用される前に、メモリーにデータベースをロードしておくようにしてください。
データベースをメモリーにロードする際の遅延を回避するには、データベースのRAMポリシーを変更して、データベースがメモリーに常駐できるようにします。この方法のデメリットは、データベースがメモリーからアンロードされないため、最後の接続を切断してもチェックポイントが発生しないことです。このため、トランザクション・ログ・ファイルで占有されているディスク領域を解放するには、データベースのチェックポイント処理をアプリケーションで明示的に実行する必要があります。
また、一定期間だけデータベースをメモリーに常駐させ、新しい接続を受け入れるように指定することもできます。この期間に新しい接続が確立されなかった場合、データベースはメモリーからアンロードされ、チェックポイント処理が実行されます。また、システム管理者がデータベースを手動でメモリーからのロードとアンロードを実行できるようにも設定できます。
データベースのRAMポリシーを変更するには、ttAdminユーティリティを使用します。RAMポリシーおよびttAdminユーティリティの詳細は、このマニュアルの「RAMポリシーの指定」および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。
パフォーマンスへの影響: 大
データベースを複製する際は、ttAdminユーティリティの-ramLoadオプションを使用してください。これにより、データベースは、ブロッキング・チェックポイントでアンロードされるのではなく、接続可能な状態でメモリーに配置されます。詳細は、本書の「接続オーバーヘッドの回避」と、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。
パフォーマンスへの影響: 大
データベースが無効化された後TimesTenが復旧すると、新しいデータベースがリロードされます。ただし、無効化されたデータベースはそのデータベースへの接続がすべて閉じられるまでアンロードされません。したがって、無効化されたデータベースとリカバリ後のデータベースの両方が同時にRAMに存在することがあります。
無効なデータベースがメモリーにまだ存在している間に大きなデータベースをメモリーにリロードすると、使用可能RAMが一杯になることがあります。データベースの自動リロードを防止する方法の詳細は、「自動リカバリ失敗後のデータベースのリロードを防止する」を参照してください。
パフォーマンスへの影響: 大
データベースで競合が発生すると、アプリケーションのパフォーマンスが大幅に低下する可能性があります。
アプリケーションでの競合を軽減するには、次の手順を実行します。
適切なロック方法を選択します。詳細は、「最適なロック方法の選択」を参照してください。
複数の表またデータベースにデータを効果的に分散します。
ロックの競合および同時実行性の低下が原因でアプリケーションのパフォーマンスが低下している場合は、パフォーマンスを向上させるために、まず競合を軽減する必要があります。
ロックの競合の詳細は、SYS.SYSTEMSTATS表内のlock.locks_granted.immediate列、lock.locks_granted.wait列およびlock.timeouts列を参照してください。
lock.locks_granted.immediateでは、ロックが使用可能になり、ロック・リクエスト時に即時に付与された回数がカウントされます。
lock.locks_granted.waitでは、ロックが使用可能になるまでリクエストしたユーザーが待機した後でロック・リクエストが付与された回数がカウントされます。
lock.timeoutsでは、ロックが使用可能になるまでリクエストしたユーザーが待機しなかったためロックが付与されなかった回数がカウントされます。
同時実行性が制限されたためスループットが低下している場合、またはレスポンス時間が問題となっている場合は、アプリケーションでAPI (JDBC、ODBC、またはOCI)コールを行うスレッドまたはプロセスの数を削減できます。使用するスレッドを減らすには、アプリケーション側でキューイングとスケジューリングが必要であり、この場合、競合および待機時間を減らすためにCPU時間が多少長くなります。結果として、データベースに大部分の時間を使う同時実行性の低いアプリケーションのパフォーマンスが向上します。
パフォーマンスへの影響: 中
TimesTenのプラットフォームとなるすべてのオペレーティング・システムでは、メイン・メモリーに動的ファイル・システムのバッファ・プールが作成されます。このバッファ・プールを大きくできる場合は、TimesTenとオペレーティング・システムの両方がファイルのコピーをメモリー内に格納するため、TimesTenの一部の共有セグメントがページ・アウトされます。
実装されたメモリー・サイズの半分よりも小さいデータベースの場合は、この現象が発生しないこともあります。システムによっては、ファイル・システムで使用するメイン・メモリーを制限できます。また、この効果があまりないシステムもあります。
AIXの場合は、ラージ・ページの構成によって、共有セグメントをページングできないようにメモリー内にロックすると、ページングを回避できます。AIXでラージ・ページを構成する方法の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のラージ・ページ(AIX)に関する説明を参照してください。
Linuxの場合は、ラージ・ページの構成によって、共有セグメントをページングできないようにメモリー内にロックすると、ページングを回避できます。Linuxでラージ・ページを構成する方法の詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のラージ・ページ(Linux)に関する説明を参照してください。
パフォーマンスへの影響: 中
最初のロードなど、特別な処理を実行する場合は、通常とは異なる別のオプションを選択できます。特に、バルク・ロードを行う場合はttBulkCpまたはttMigrateなどを使用し、データベース・レベル・ロックを使用することを検討してください。これらの設定により、ロード時のパフォーマンスを2倍にすることも可能です。
データベース・レベル・ロックに代わる方法として、同時実行性を利用する方法があります。-notblLockオプションを使用すると、ttBulkCp -iのコピーを複数実行できます。ttBulkCpのバッチ処理を最適化するには、-xp 256オプションを追加します。ttMigrateに-numThreadsオプションを指定して実行すると、個々の表または複数の表を同時にロードできます。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttBulkCp」および「ttMigrate」を参照してください。
パフォーマンスへの影響: 大
TimesTen Data Managerドライバには、プラットフォームごとに、デバッグ・バージョンと本番バージョンの2種類があります。デバッグを実行しないときは、本番バージョンを使用してください。デバッグ・ライブラリを使用すると、処理がかなり遅くなることがあります。各種プラットフォームのTimesTen Data Managerドライバについては、「Data Manager DSNの指定」および「ODBCドライバの指定」を参照してください。
Windowsの場合は、ODBC Driver Managerを使用するアプリケーションが、適切なTimesTenドライバにアクセスするDSNを使用していることを確認してください。アプリケーションでは、適切なTimesTenドライバにリンクされていることを確認してください。直接接続アプリケーションの場合、TimesTen Data Managerドライバを使用します。アプリケーションからは、SQL_DRIVER_NAME引数を指定してODBC SQLGetInfo関数をコールし、使用するドライバを決定できます。
パフォーマンスへの影響: 大
ODBCとJDBCには、その両方にアプリケーションをデバッグするためのトレース機能があります。パフォーマンスを重視している場合は、アプリケーションのデバッグ時を除き、トレース機能を無効に設定してください。
JDBCのトレース機能を有効にするには、次のメソッドを使用します。
DriverManager.setLogStream method: DriverManager.setLogStream(new PrintStream(System.out, true));
デフォルトでは、トレース機能は無効です。このメソッドをコールしてから、JDBCドライバをロードする必要があります。トレース機能を有効にした後、アプリケーションの実行中はトレース機能を無効にできません。
パフォーマンスへの影響: 不定
ttStatsユーティリティを使用して、データベース・メトリックを収集および表示できます。ttStatsユーティリティでは、次の機能を実行できます。
パフォーマンス・メトリックをリアルタイムでモニタリングおよび表示し、前のインターバルからの変化率を計算する。
メトリックのスナップショットを収集してデータベースに格納し、値と変更率を記載したレポートを、指定したスナップショットのペアから生成する(これらの機能はTT_STATS PL/SQLパッケージへのコールを介して実行)。
ttStatsユーティリティは、TimesTenシステム表、ビューおよび組込みプロシージャからメトリックを収集します。レポートには、メモリー使用量、接続、ロード・プロファイルの概要などの情報が含まれ、その後に(必要に応じて) SQL文、トランザクション、PL/SQLメモリー、レプリケーション、ログとログの保持、チェックポイント、キャッシュ・グループ、キャッシュ・グリッド、ラッチ、ロック、XLAおよびTimesTen接続属性に関するメトリックが続きます。
ttStatsユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsに関する説明を参照してください。TT_STATS PL/SQLパッケージの詳細は、『Oracle TimesTen In-Memory Database PL/SQLパッケージ・リファレンス』のTT_STATSに関する説明を参照してください。
パフォーマンスへの影響: 不定
JRockitおよびIBMでは、Sun JVMより高パフォーマンスのJVMが提供されています。
パフォーマンスへの影響: 不定
データベースの移行時にキャラクタ・セット変換がリクエストされた場合は、キャラクタ・セット変換がリクエストされない場合よりパフォーマンスが低下します。
次の項では、クライアント/サーバーのチューニングに関するヒントを示します。
パフォーマンスへの影響: 不定
クライアント/サーバーのパフォーマンスは、SYS.SYSTEMSTATS表で追跡される次の統計で分析できます。これはttStatsユーティリティまたはTT_STATS PL/SQLパッケージでも表示できます。
|
注意: SYS.SYSTEMSTATS表の詳細は、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.SYSTEMSTATSに関する説明を参照してください。ttStatsユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsに関する説明を参照してください。TT_STATS PL/SQLパッケージの詳細は、『Oracle TimesTen In-Memory Database PL/SQLパッケージ・リファレンス』のTT_STATSに関する説明を参照してください。 |
クライアント/サーバー・アプリケーションからの総実行回数。
サーバーによるINSERT、UPDATE、DELETE、SELECT、MERGE、ALTER、CREATE、DROP文の総実行回数。
サーバーによるトランザクションのコミットまたはロールバックの総回数。
サーバーによる、表への行の挿入、更新または削除の総回数。
クライアント/サーバーのラウンドトリップの総回数。
サーバーが転送または受信したバイトの総数。
クライアント/サーバーの切断の総回数。
パフォーマンスへの影響: 大
TimesTen Clientを使用してリモート・サーバー・システムにあるデータベースにアクセスする場合、接続に対してネットワーク上のオーバーヘッドが発生します。可能な場合は、TimesTen Data Managerをローカルにアクセスするようにアプリケーションを作成し、アプリケーションをTimesTen Data Managerと直接リンクするようにしてください。
パフォーマンスへの影響: 不定
デフォルトでは、接続は10秒待機してロックを設定します。ロックのタイムアウト時間を変更するには、ttLockWait組込みプロシージャを使用します。
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttLockWait」を参照してください。
パフォーマンスへの影響: 不定
複数の接続で同時にデータベースにアクセスする場合、TimesTenは、ロックを使用して様々なトランザクションが明示的に分離されて処理されるようにします。TimesTenでは、第7章「トランザクション管理」で説明される分離レベルをサポートしています。また、データベース・レベル・ロック、表レベル・ロックおよび行レベル・ロックのロック・レベルをサポートしています。LockLevel接続属性を使用すると、データベース・レベル・ロックと行レベル・ロックのどちらを使用するか指定できます。表ロックを使用するかどうかを示すオプティマイザ・ヒントを設定するには、ttOptSetFlagプロシージャを使用します。デフォルトのロック粒度は行レベル・ロックです。
|
注意: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「LockLevel」および「ttOptSetFlag」を参照してください。 |
データベースで競合がほとんど発生しない場合は、表レベル・ロックを使用します。これによって、パフォーマンスが改善され、デッドロックの可能性も低くなります。通常、トランザクションが短時間の場合または接続が少ない場合は、データベースで競合はほとんど発生しません。この場合、トランザクションが重複する可能性は低くなります。
また、表レベル・ロックは、文が表のほぼすべての行にアクセスする場合にも有効です。このような文には、1つのトランザクションで実行される問合せ、更新、削除、複数の挿入などがあります。
データベース・レベル・ロックは、単一のトランザクションに対するデータベース・アクセスを完全に制限するため、通常の操作には推奨されません。データベース・レベル・ロックを使用して長時間実行されるトランザクションは、データベースへの他のアクセスをすべてブロックし、データベースの監視と保守に必要な各種のバックグラウンド・タスクにさえ影響します。
通常、同じ行にアクセスする必要がほとんどない同時トランザクションが多数存在する場合は、行レベル・ロックを使用することを薦めします。プロセッサ数が十分で、同時実行性能が高い最新のシステム、たとえば複数のttBulkCpプロセスでは、行レベル・ロックのほうがデータベース・レベル・ロックよりパフォーマンスが高いのが普通です。
|
注意: ttBulkCpユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBulkCpに関する説明を参照してください。 |
行レベル・ロックを使用している場合、アプリケーションでは、トランザクションをSERIALIZABLEまたはREAD_COMMITTEDの分離レベルで実行できます。デフォルトの分離レベルはREAD_COMMITTEDです。Isolation接続属性を使用すると、これらの分離レベルのいずれかを新しい接続に指定できます。
SERIALIZABLEトランザクション分離レベルで実行すると、トランザクションの間、TimesTenではすべてのロックが維持されます。
行を更新するトランザクションでは、トランザクションがコミットされるまで書込みユーザーがブロックされます。
行を読み込むトランザクションでは、トランザクションがコミットされるまで書込みユーザーがブロックされます。
READ_COMMITTEDトランザクション分離レベルで実行すると、トランザクションの間、TimesTenでは更新のロックのみが維持されます。
行を更新するトランザクションでは、トランザクションがコミットされるまで、この行に対する書込みユーザーはブロックされます。この行を読み取るユーザーは、この行の以前コミットされたバージョンを受け取ります。
ファントム行が発生する場合があります。ファントム行とは、トランザクション時に読取りのロックが早く解放されたため、同じトランザクションにおいて、その行が、ある読取りでは表示されるが別の読取りでは表示されなかったり、2つの異なる読取りが異なる形式で表示されることが発生することです。
タイムアウトおよびデッドロックのエラー(エラー6001、6002および6003)をチェックすると、システムに競合が過度に存在しているかどうかを確認できます。この情報は、SYS.SYSTEMSTATS表のlock.timeouts列およびlock.deadlocks列でも確認できます。
分離レベルの詳細は、「トランザクションの分離レベル」を参照してください。
パフォーマンスへの影響: 不定
TimesTen Clientは、通常、TCP/IPソケットを使用してTimesTen Serverと通信します。TimesTen ClientとTimesTen Serverの両方が同一システム上にある場合は、プロセス間の通信(IPC)に共有メモリー・セグメントまたはUNIXドメイン・ソケットを使用することで、クライアント・アプリケーションのパフォーマンスが改善されます。
共有メモリー・セグメントをIPCとして使用するには、ttendaemon.optionsファイルでサーバー・オプションを設定する必要があります。サーバー・オプションについては、「TimesTen Serverのオプションの変更」を参照してください。
また、IPCに共有メモリー・セグメントを使用するアプリケーションでは、ネットワーク・アドレスとしてttShmHostを使用して、クライアントDSNに対する論理サーバー名を設定する必要があります。詳細は、「UNIXでのクライアントDSNの作成および構成」を参照してください。
この機能は共有メモリーを大量に必要とする可能性があります。TimesTen Serverは、既存の接続数や全接続内の文の数にかかわりなく、共有メモリー・セグメントを事前に割り当てます。
UNIXシステムでアプリケーションを実行しているときにメモリーの使用量が懸念される場合は、UNIXドメイン・ソケットを通信に使用すると、TimesTen Client ODBCドライバを使用しているアプリケーションのパフォーマンスを改善できる場合があります。UNIXドメイン・ソケットの使用によるパフォーマンスの改善は、ShmIPCを使用した場合ほど大きくありません。
ローカル接続にUNIXドメイン・ソケットを使用するアプリケーションでは、ネットワーク・アドレスとしてttLocalHostを使用して、クライアントDSNに対する論理サーバー名を設定する必要があります。詳細は、「UNIXでのクライアントDSNの作成および構成」を参照してください。また、システム・カーネル・パラメータが、必要な接続数を許容するように設定されていることも確認してください。『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のインストールの前提条件に関する説明を参照してください。
パフォーマンスへの影響: 不定
クライアント/サーバー・アプリケーションで、シリアライズ可能トランザクションのTT_PREFETCH_CLOSEを有効にします。シリアライズ可能分離モードでは、読取り専用トランザクションを含むすべてのトランザクションが実行時にコミットされる必要があります。TT_PREFETCH_CLOSEが有効になっている場合、サーバーでは、結果セット全体が読取り専用の問合せに対してフェッチされた後でカーソルが閉じられ、トランザクションがコミットされます。クライアントでは、SQLFreeStmt(SQL_CLOSE)およびSQLTransact(SQL_COMMIT)がコールされる必要がありますが、これらのコールは、クライアントで実行されるため、クライアントとサーバー間のネットワーク・ラウンドトリップを必要としません。TT_PREFETCH_CLOSEによって、クライアントとサーバー間のネットワーク通信量が削減され、パフォーマンスが向上します。
TT_PREFETCH_CLOSEが有効になっている場合、複数の文ハンドルは使用しないでください。サーバーでは、クライアントが終了する前に、結果セットのすべてがフェッチされ、トランザクションがコミットされて文ハンドルがクローズされる可能性があります。
次の例は、ODBCとJDBCでTT_PREFETCH_CLOSEオプションを使用する方法を示しています。この例では、SQLSetConnectOption ODBC関数を指定してTT_PREFETCH_CLOSEを設定します。SQLSetStmtOption ODBC関数を指定して設定することもできます。
SQLSetConnectOption (hdbc, TT_PREFETCH_CLOSE, TT_PREFETCH_CLOSE_ON);
SQLExecDirect (hstmt, "SELECT * FROM T", SQL_NTS);
while (SQLFetch (hstmt) != SQL_NO_DATA_FOUND)
{
// do the processing
}
SQLFreeStmt (hstmt, SQL_CLOSE);
この例では、JDBCを使用してTT_PREFETCH_CLOSEオプションを有効にする方法が示されています。
con = DriverManager.getConnection ("jdbc:timesten:client:" + DSN);
stmt = con.createStatement();
import com.timesten.sql
...
...
con.setTtPrefetchClose(true);
rs = stmt.executeQuery("select * from t");
while(rs.next())
{
// do the processing
}
import com.timesten.sql
....
try {
((TimesTenConnection)con).setTtPrefetchClose(true);
}
catch (SQLException) {
...
}
rs.close();
con.commit();
パフォーマンスへの影響: 大
アプリケーションは、SQL_NULL_HDBCおよび有効な環境ハンドルを使用してSQLTransactをコールできます。
SQLTransact (ValidHENV, SQL_NULL_HDBC, fType)
または、有効な接続ハンドルを使用してコールすることもできます。
SQLTransact (SQL_NULL_HENV, ValidHDBC, fType).
アプリケーションでは、単一接続でコミットまたはロールバックするのみの場合、SQLTransactのコール時に有効な接続ハンドルを使用する必要があります。
全体のロックおよびI/Oの方針の決定後、個々のSQL文をできるだけ効率的に実行できるようにしてください。次の項では、SQL文を簡素化する方法について説明します。
パフォーマンスへの影響: 大
すべての文が効率的に実行されているかどうかをチェックします。たとえば、使用する問合せは、必要な結果セットを生成するために必要な行のみを参照するようにします。表t1のcol1のみが必要であれば、次の文を使用します。
SELECT col1 FROM t1...
または、次の文を使用します。
SELECT * FROM t1...
TimesTenで文を実行するために使用される計画の表示方法については、第9章「TimesTen問合せオプティマイザ」を参照してください。また、計画は、ttIsql showplanコマンドを使用して表示することもできます。アプリケーションで頻繁に実行される各文の計画を表示します。索引が条件を評価するために使用されていない場合は、索引を使用できるように、新しい索引の作成または文や問合せの再作成を検討してください。たとえば、比較条件(一致および不一致)の一方またはBETWEEN条件に単一の列が表示される場合に、索引をWHERE句を評価するためにのみ使用できます。
この比較条件が頻繁に評価される場合は、再作成するのが妥当です。
WHERE c1+10 < c2+20
これを次のように書きなおします。
WHERE c1 < c2+10
c1に索引を作成します。
索引が存在することにより、UPDATE、INSERT、DELETE、CREATE VIEWなどの書込み操作の処理速度が遅くなります。アプリケーションでの読取りが少ないものの、表への書込みが多い場合は、その表の索引によってパフォーマンスが向上するのではなく、低下する可能性があります。
場合によっては、問合せ評価の処理速度を向上するために、システムによって一時索引が作成される場合があります。このような場合が頻繁にある場合は、アプリケーション自体で索引を作成する方が効率的です。MONITOR表のCMD_TEMP_INDEXES列は、問合せ評価時に一時索引が作成された回数を示します。
表またはキャッシュ・グループに対して時間ベースのエージングを実装している場合は、タイムスタンプ列に索引を作成すると、エージングのパフォーマンスが向上します。詳細は、「時間ベースのエージング」を参照してください。
パフォーマンスへの影響: 不定
TimesTenには、SQL操作の実行時間を測定して表示することでSQL文のパフォーマンスを判断できる組込みプロシージャがあります。追跡のかわりに、組込みプロシージャがSQL文の実行中に実行時間をサンプリングします。この組込みプロシージャは、SQLExecute API内で実行の時間を測定することで、SQL文の実行時間を測定します。
ttStatsConfig組込みプロシージャと次の名前と値のペアを使用して、サンプリング・レートと実行時間の収集方法を構成できます。
|
注意: 詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsConfigに関する説明を参照してください。 |
表10-1 ttStatsConfigパラメータと値の説明
| パラメータ | 説明 |
|---|---|
|
|
SQL文と実行時間タイミングのサンプルを収集する方法を構成します。デフォルトは0です。これはサンプリングをオフにするという意味です。たとえば10に設定すると、TimesTenはSQL文の実行のウォール・クロック時間を、10個の文ごとにキャプチャします。 |
|
|
個々の接続でSQL文のサンプルを収集する頻度を構成します。値は2個のパラメータがカンマで区切られ、引用符で囲まれているため、単一の値のように見えます。1番目の値は接続IDです。2番目の値は |
|
|
0以外の値に設定すると、SQL実行時間のヒストグラム・データがクリアされます。 |
|
|
使用する統計レベルを設定します。値は |
次は、ttStatsConfig組込みプロシージャで名前と値のペアを設定する方法の例です。
|
注意: すべてのトランザクションをサンプリングするかわりに、ttStatsConfig組込みプロシージャのConnSampleFactorパラメータを使用して代表的な接続を選択すると、最良の結果が得られます。小さなサンプリング係数ですべてのトランザクションをサンプリングすると、パフォーマンスが低下するおそれがあります。
意味のある結果を得るには、データベースをメモリーに読み込んだままにする必要があります。データベースのアンロードとリロードを行うと、SQLコマンドキャッシュが空になるためです。 |
接続1で文を5個ごとにサンプリングします。
Command> call ttStatsConfig('ConnSampleFactor', '1,5');
< CONNSAMPLEFACTOR, 1,5 >
1 row found.
接続1のサンプリングをオフにします。
Command> call ttStatsConfig('ConnSampleFactor', '1,0');
< CONNSAMPLEFACTOR, 1,0 >
1 row found.
すべてのコマンドをサンプリングします。
Command> call ttStatsConfig('SqlCmdSampleFactor',1);
< SQLCMDSAMPLEFACTOR, 1 >
1 row found.
サンプリングの設定を確認します。
Command> call ttStatsConfig('SqlCmdSampleFactor');
< SQLCMDSAMPLEFACTOR, 1 >
1 row found.
データベース統計の現在の収集レベルを確認します。
Command> call ttStatsConfig('StatsLevel');
< STATSLEVEL, TYPICAL >
1 row found.
データベース統計収集をNONEに設定してオフにします。
Command> call ttStatsConfig('StatsLevel','None');
< STATSLEVEL, NONE >
1 row found.
収集する統計の構成の完了後、ttSQLCmdCacheInfo組込みプロシージャを使用すると、収集された統計が表示されます。実行時間のヒストグラムをコマンドレベルまたはデータベースレベルで表示するには、ttSQLExecutionTimeHistogram組込みプロシージャを使用します。
ttSQLCmdCacheInfo組込みプロシージャは、SQL実行時間統計に関する次の情報を表示します。
この文のために内部的に行われたフェッチの実行回数です。
文が開始したときのタイムスタンプです。
この文の最大ウォール・クロック実行時間が秒単位で表示されます。
最後に測定された実行時間が秒単位で表示されます。
最小実行時間が秒単位で表示されます。
次の例では、ディスプレイには末尾の5つの値に次の統計が表示されます。
Command> vertical call ttSQLCmdCacheInfo(135680792); SQLCMDID: 146250096 PRIVATE_COMMAND_CONNECTION_ID: 2048 EXECUTIONS: 40 PREPARES: 20 REPREPARES: 1 FREEABLE: 1 SIZE: 3880 OWNER: ORATT QUERYTEXT: select min(unique2) from big1 FETCHCOUNT: 40 STARTTIME: 2012-06-18 13:10:46.808000 MAXEXECUTETIME: .001319 LASTEXECUTETIME: .000018 MINEXECUTETIME: .000017 1 row found.
ttSQLCmdCacheInfo組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttSQLCmdCacheInfoに関する説明を参照してください。
ttSQLExecutionTimeHistogram組込みプロシージャは、SQL実行時間のヒストグラムを、単一のSQLコマンドまたはコマンドキャッシュにあるすべてのSQLコマンドに対して表示します。その際、サンプリングが有効になっていると仮定されます(SQLCmdSampleFactorが0より大きい)。
ヒストグラムには、ヒストグラムのバケットごとに1つの行が表示されます。各行には次の情報が含まれます。
TimesTenデータベースを開始した時点、またはttStatsConfig組込みプロシージャを使用して統計をリセットした時点のいずれか以降に測定された、SQL文の実行時間操作の数。
累積ウォール・クロック実行時間。
各時間フレームを示す実行時間制限。
最後の行は、特定の時間フレーム内に実行されたSQL文の数を示します。
次の例は、ttSQLExecutionTimeHistogram組込みプロシージャの出力を示します。
次のttSQLExecutionTimeHistogram組込みプロシージャの例は、合計1919個の文が実行されたことを示します。1919個の文すべての合計実行時間は1.090751秒でした。この例は、SQL文が次のタイムフレーム内で実行されたことを示します。
0.00001562秒以下のタイムフレーム内で、278個の文が実行されました。
0.00001562秒より大きく0.000125秒以下のタイムフレームで、1484個の文が実行されました。
0.000125秒より大きく0.001秒以下のタイムフレームで、35個の文が実行されました。
0.001秒より大きく0.008秒以下のタイムフレームで、62個の文が実行されました。
0.008秒より大きく0.064秒以下のタイムフレームで、60個の文が実行されました。
Command> call ttSQLExecutionTimeHistogram; < 1919, 1.090751, .00001562, 278 > < 1919, 1.090751, .000125, 1484 > < 1919, 1.090751, .001, 35 > < 1919, 1.090751, .008, 62 > < 1919, 1.090751, .064, 60 > < 1919, 1.090751, .512, 0 > < 1919, 1.090751, 4.096, 0 > < 1919, 1.090751, 32.768, 0 > < 1919, 1.090751, 262.144, 0 > < 1919, 1.090751, 9.999999999E+125, 0 > 10 rows found.
パフォーマンスへの影響: 不定
TimesTenデータベースでは、ハッシュ索引、範囲索引およびビットマップ索引の各索引がサポートされています。次に、それぞれの索引の種類をいつ使用するのが適切か説明します。
ハッシュ索引は、1つ以上の列で完全一致する行を検索する場合に有効です。ハッシュ索引は、一致検索の実行に便利です。ハッシュ索引は次のいずれかの方法で作成されます。
CREATE [UNIQUE] HASH INDEX文を使用すると、ハッシュ索引または一意のハッシュ索引を作成できます。
CREATE TABLE... UNIQUE HASH ON文を使用すると、表の作成時に一意のハッシュ索引を作成できます。一意のハッシュ索引は、表の主キー列に対して指定します。
範囲索引は、デフォルトではCREATE TABLE文で作成します(CREATE [UNIQUE] HASH INDEX文で作成することも可能です)。範囲索引では完全一致のキーの検索を高速化でき、より柔軟性が高く、他の問合せの高速化にも利用できます。問合せにLESS THANまたはGREATER THANの比較がある場合は、範囲索引を選択します。範囲索引は、カーディナリティの高いデータ(CUSTOMER_NAMEまたはPHONE_NUMBERなどの使用可能な値が多数あるデータ)に対して効果的です。範囲索引はインメモリーのデータ管理に最適化されています。
また、範囲索引は、接頭辞問合せの高速化に使用することもできます。接頭辞問合せでは、指定されている最後のキー列以外のすべての列に一致条件を指定できます。接頭辞問合せの最後の列には、一致条件または不一致条件を指定できます。
次の表および索引の定義について考えてみます。
CREATE TABLE T(i1 integer, i2 integer, i3 integer, ...); CREATE INDEX IXT on T(i1, i2, i3);
索引IXTを使用すると、次の問合せを高速化できます。
SELECT * FROM T WHERE i1>12; SELECT * FROM T WHERE i1=12 and i2=75; SELECT * FROM T WHERE i1=12 and i2 BETWEEN 10 and 20; SELECT * FROM T WHERE i1=12 and i2=75 and i3>30;
索引IXTは次の問合せには使用されません。接頭辞プロパティが条件を満たしていないためです。
SELECT * FROM T WHERE i2=12;
i1に一致条件が指定されていません。
次のような問合せの場合、索引IXTは使用されますが、一致検索は最初の2列のみに対して実行されます。
SELECT * FROM T WHERE i1=12 and i2<50 and i3=630;
範囲索引の構造は、表サイズの変更に対応して自動的に調整される動的構造です。範囲索引は、一意にすることも一意にしないこともでき、またNULL値可能列に対して宣言することもできます。また、レコードの挿入後、索引付けされた列の値を変更することもできます。範囲索引は、ほとんどの場合、同等のハッシュ索引より単純です。
ビットマップ索引は、CREATE INDEX文で作成します。ビットマップ索引は、カーディナリティの低い列のデータを検索および取得する場合に効果的です。特に、一致問合せでANDおよびOR演算子を使用している場合に有効です。これらの索引を使用すると、ANDおよびOR演算子で連結した複数の条件を複数の列に対して指定する、複雑な問合せのパフォーマンスが向上します。ビットマップ索引は、データ・ウェアハウス環境で広く使用されています。通常、データ・ウェアハウス環境では、大量のデータおよび非定型の問合せが処理されますが、DMLの同時トランザクションは低レベルです。ビットマップ索引は、圧縮されるため、他の索引方法と比較して必要な記憶域が少なくなります。ビットマップ索引を使用する場合の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE INDEXに関する説明を参照してください。
パフォーマンスへの影響: 不定
TimesTenはハッシュ索引を、主キーの制約として、およびCREATE INDEX文の一部として指定された場合の両方で使用します。ハッシュ索引のサイズは、CREATE TABLEおよびCREATE INDEX文のUNIQUE HASH ON句で指定するPAGESパラメータで決まります。PAGESの値は、表の予想行数を256で割った値にする必要があります。たとえば、256,000行の表の場合、PAGES = 1000とします。小さい値を指定すると、ハッシュ競合の数が増加してパフォーマンスが低下し、大きい値を指定すると、パフォーマンスが多少向上するかわりに索引で追加の領域が必要になります。
表の行数が大幅に変動し、パフォーマンスが主な検討事項である場合、大きな索引を作成するのが最善です。表のサイズを正確に予測できない場合は、範囲索引を使用することを検討してください。また、索引付けする列が大きいCHAR値またはバイナリ値の場合、あるいは索引付けする列が多い場合は、一意索引の使用を検討してください。これらの場合は、一意索引の方がハッシュ索引より高速になる場合があります。
表のサイズが大きくなるにつれてレコード挿入のパフォーマンスが低下する場合は、表の予想サイズを小さく見積りすぎていた可能性があります。ALTER TABLE文を使用してUNIQUE HASH ON句のPAGES値を再設定することによって、ハッシュ索引のサイズを変更できます。SET PAGESの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER TABLEに関する説明を参照してください。
パフォーマンスへの影響: 不定
外部キーを宣言しても、SELECT問合せのパフォーマンスには影響ありませんが、外部キーが定義された表でINSERTおよびUPDATEを実行する場合、および外部キーで参照される表でUPDATEおよびDELETEを実行する場合は、パフォーマンスが低下します。この低下は、表を参照する外部キーの数または表に定義されている外部キーの数に比例します。
パフォーマンスへの影響: 大
データベース内のデータに関する統計が利用できる場合、TimesTenオプティマイザは、コマンドを準備する際に、それらの統計を使用してデータへの最適なパスを決定します。統計がない場合、TimesTenオプティマイザは、データ配布に関して一般的な予測を行います。
情報によって問合せオプティマイザの計画がより効率的になる可能性があるため、文を準備する前に統計を計算する必要があります。パフォーマンスは統計収集プロセスの影響を受けるため、統計を収集する場合は、新しい統計を収集するとき、およびその頻度を決定する必要があります。収集の頻度は、統計収集プロセスで起こるオーバーヘッドの処理に対し、オプティマイザの正確な統計を出すタスクのバランスをとる必要があります。
統計の計算は時間がかかる処理のため、次のガイドラインを使用して統計を計算してください。
データベースのロード後またはアプリケーションのメジャー・アップグレード後に、統計を更新します。
トランザクションのロードが大きいときに統計を更新しないでください。
表、列またはPL/SQLオブジェクトに相当な作成および変更がある場合は、統計を更新します。
データベースで相当数の表、列またはPL/SQLオブジェクトを作成または変更した場合、システム表SYS.TABLES、SYS.COLUMNSおよびSYS.OBJ$に対応したデータ・ディクショナリのオプティマイザ統計を更新する必要があります。
バルク・ロードや一括削除など、バッチ操作で表を大幅に変更する場合、バッチ操作の一環としてこれらの表の統計を収集できます。
表が増分的に変更されるだけの場合は、1週間に1回や1か月に1回程度の頻度で、統計を更新します。
トランザクション負荷が低い時間帯は、定期的に実行されるスクリプトまたはバッチ・ジョブの一環として統計を更新します。
複数の大規模な表の統計を更新する場合は、「大規模な表の表統計のパラレルでの更新」を参照してください。
|
注意: パフォーマンス上の理由から、TimesTenでは、統計が計算される際に表または行のロックは保持されません。 |
統計を計算するために、ttIsql statsupdateコマンド、ttOptUpdateStatsまたはttOptEstimateStatsを使用します。表名として空の文字列を指定すると、現行ユーザーのスキーマ内のすべての表の統計が更新されます。
ttIsql内のstatsupdateコマンドは、対象の表の各行を評価し、正確な統計を計算します。
ttOptUpdateStats組込みプロシージャは、対象となる表のすべての行を評価し、正確な統計を計算します。
ttOptEstimateStats組込みプロシージャは、対象となる表の一部の行のみを評価し、見積り統計を計算します。これは高速に実行できますが、統計の正確性に劣ることがあります。10パーセントのサンプルで統計を計算すると、正確な統計を計算するより処理が約10倍速くなり、通常は同じ実行計画が生成されます。
|
注意: ttIsqlまたは組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の「ttIsql」および「組込みプロシージャ」に関する説明を参照してください。 |
パフォーマンスへの影響: 大
すべてのTimesTen表で表統計を最新の状態に保つことは重要です。ただし、この処理を大規模な表で実行すると、時間がかかり、パフォーマンスに負荷がかかります。複数の大規模な表の統計を更新する場合は、ttOptUpdateStats組込みプロシージャをパラレルでコールすることを検討してください。
|
注意: 100万行より少ない行が含まれている場合、TimesTen表は小規模な表とみなされます。1億行を超える行が含まれている場合、TimesTen表は大規模な表とみなされます。 |
表統計を更新する場合は、すべての大規模な表に対してttOptUpdateStats組込みプロシージャをコールします。それぞれのttOptUpdateStats組込みプロシージャをパラレルでコールしてください。ttOptUpdateStats組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttOptUpdateStatsに関する説明を参照してください。
Command> call ttOptUpdateStats('table1',0,0);
Command> call ttOptUpdateStats('table2',0,0);
...
...
Command> call ttOptUpdateStats('finaltable',0,0);
ttOptUpdateStats組込みプロシージャのコールが完了したら、表統計を更新した大規模なTimesTen表に対するトランザクションのアクセス数を確認します。トランザクション・ロード時間が短い間はttOptCmdCacheInvalidate('',1)組込みプロシージャを実行します。ttOptCmdCacheInvalidate組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttOptCmdCacheInvalidateに関する説明を参照してください。トランザクション・ロード時間が長いときに、次の組込みプロシージャを実行し、各ttOptCmdCacheInvalidate組込みプロシージャはパラレルでコールします。
Command> call ttOptCmdCacheInvalidate('table1',1);
Command> call ttOptCmdCacheInvalidate('table2',1);
...
...
Command> call ttOptCmdCacheInvalidate('finaltable',1);
表の表統計が更新され、SQLコマンド・キャッシュのコンパイルされたコマンドは無効になりました。
パフォーマンスへの影響: 不定
表統計を現在の状態にリストアできるttOptStatsExport組込みプロシージャを使用して、SQLスクリプトを生成できます。これらの文を適用する場合、同じ環境を再作成します。表統計の再作成は、SQLパフォーマンスの診断に使用できます。
ttOptStatsExport組込みプロシージャをコールして、表統計を現在の状態にリストアするために必要な一連の文を返します。表を指定しない場合、ttOptStatsExportは、コール元のユーザーがアクセス権限を持っているすべてのユーザー表についての表統計をリストアするために必要な一連の文を返します。
|
注意: この組込みプロシージャの詳細および構文は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttOptStatsExport」を参照してください。 |
次の例では、employees表の統計をリストアするための実行に必要な一連の組込みプロシージャ・コマンドを返します。
Command> CALL ttOptStatsExport('HR.employees');
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMPLOYEE_ID', 0, (6, 0, 107, 107,
(20, 20, 1 ,100, 120, 101), (20, 20, 1 ,121, 141, 122), (20, 20, 1 ,142, 162,
143), (20, 20, 1 ,163, 183, 164), (20, 20, 1 ,184, 204, 185), (1, 1, 1 ,205, 206,
205))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'FIRST_NAME', 0, (1, 0, 89, 107,
(89, 107, 0, 'Adam', 'Winston', 'Adam'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'LAST_NAME', 0, (1, 0, 97, 107, (97,
107, 0, 'Abel', 'Zlotkey', 'Abel'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'EMAIL', 0, (6, 0, 107, 107, (20,
20, 1, 'ABANDA', 'DGREENE', 'ABULL'), (20, 20, 1, 'DLEE', 'JKING', 'DLORENTZ'),
(20, 20, 1, 'JLANDRY', 'LOZER', 'JLIVINGS'), (20, 20, 1, 'LPOPP', 'RMATOS',
'LSMITH'), (20, 20, 1, 'RPERKINS', 'WGIETZ', 'SANDE'), (1, 1, 1, 'WSMITH',
'WTAYLOR', 'WSMITH'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'PHONE_NUMBER', 0, (1, 0, 103, 107,
(103, 107, 0, '011.44.1343.329268', '650.509.4876', '011.44.1343.329268'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'HIRE_DATE', 0, (1, 0, 90, 107, (90,
107, 0 ,'1987-06-17 00:00:00', '2000-04-21 00:00:00', '1987-06-17 00:00:00'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'JOB_ID', 0, (4, 0, 19, 107, (11,
16, 5, 'AC_ACCOUNT', 'PR_REP', 'FI_ACCOUNT'), (3, 11, 30, 'PU_CLERK', 'SA_REP',
'SA_REP'), (1, 20, 20, 'SH_CLERK', 'ST_CLERK', 'ST_CLERK'), (0, 0, 5, 'ST_MAN',
'ST_MAN', 'ST_MAN'))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'SALARY', 0, (1, 0, 57, 107, (57,
107, 0 ,2100, 24000, 2100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'COMMISSION_PCT', 0, (1, 72, 7, 107,
(7, 35, 0 ,0.1, 0.4, 0.1))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'MANAGER_ID', 0, (1, 1, 18, 107,
(18, 106, 0 ,100, 205, 100))); >
< call ttoptsetcolIntvlstats('HR.EMPLOYEES', 'DEPARTMENT_ID', 0, (3, 1, 11, 107,
(4, 10, 45 ,10, 50, 50), (2, 6, 34 ,60, 80, 80), (2, 5, 6 ,90, 110, 100))); >
< call ttoptsettblstats('HR.EMPLOYEES', 107, 0); >
12 rows found.
パフォーマンスへの影響: 不定
TimesTenは、コンパイルされたコマンドをSQLコマンド・キャッシュにキャッシュします。これらのコマンドは無効化できます。無効になったコマンドは、通常、再実行される直前に再度自動的に準備されます。1つのコマンドが何度も準備されることがあります。
統計を計算するとき、特定の表にある同一のロックについて、コマンドの更新とコンパイルのプロセスが競合することがあります。複数のトランザクションで統計を収集していて、統計の更新ごとにコマンドを無効にしていると、次の問題が発生することがあります。
複数の表を参照する結合問合せが無効化され、2回以上再コンパイルされることがあります。
再コンパイルに必要なロックが統計の更新に差し支え、その結果デッドロックが発生することがあります。
これらの問題を回避するには、コマンドがSQLコマンド・キャッシュで無効化されるタイミングを制御します。さらに、表と索引の基数が今後大幅に変更されることがわかっている場合には、すべてのコマンドの無効化を延期することも考えられます。
コマンドの無効化は次のように制御できます。
SQLコマンド・キャッシュでコマンドを無効化せずに、統計を計算します。ttIsql statsupdateコマンド、ttOptUpdateStats組込みプロシージャまたはttOptEstimateStats組込みプロシージャで、invalidateオプションを0に設定します。
すべての統計がttOptCmdCacheInvalidate組込みプロシージャでコンパイルされたら、SQLコマンド・キャッシュ内でコマンドを手動で無効にします。
ttOptCmdCacheInvalidate組込みプロシージャを使用すると、ある表のみに関連付けられたコマンドや、SQLコマンド・キャッシュ内にあるすべてのコマンドを無効化できます。さらに、無効化したコマンドを再コンパイルするか、使用不可としてマークするかを指定できます。
|
注意: 統計を最適に計算するタイミングの詳細は、「正確な統計または推定統計の計算」を参照してください。また、『Oracle TimesTen In-Memory Databaseリファレンス』のttIsql、ttOptUpdateStats、ttOptEstimateStatsまたはttOptCmdCacheInvalidateに関する説明を参照してください。 |
パフォーマンスへの影響: 不定
アプリケーションでALTER TABLE文を使用すると、表に対して列の追加および破棄を実行することができます。ALTER TABLE文自体は、ほとんどの場合、非常に高速に実行できますが、表に行った変更が原因で発生する後続の処理に時間がかかることがあります。アプリケーションで発生する実際のパフォーマンスの低下の程度は、表の変更回数および表に対して実行される処理の種類によって異なります。
VARCHAR2列およびVARBINARY列の破棄は、破棄対象の列内の既存のVARCHAR2値およびVARBINARY値に割り当てられている領域を解放するために、表をスキャンする必要があるため、他のデータ型の列の破棄より時間がかかります。
パフォーマンスへの影響: 不定
多くの行の実体化が必要な問合せのネストを回避するため、可能でばれば問合せをリライトすることをお薦めします。
次のネストした問合せの例では、実体化が必要になり、多くの行が作成される場合があります。
GROUP BYを使用するネストした集合問合せ
ROWNUMを参照するネストした問合せ
UNION、INTERSECTまたはMINUSを使用するネストした問合せ
ORDER BYを使用するネストした問合せ
たとえば、次のネストした集合問合せによって、パフォーマンスに大きく影響します。
select * from (select sum(x1) sum1 from t1 group by y1), (select sum(x2) sum2 from t2 group by y2) where sum1=sum2;
次に、ROWNUMを参照するネストした問合せの例を示します。
select * from (select rownum rc, x1 from t1 where x1>100), (select rownum rc, x2 from t2 where x2>100) where x1=x2;
次に、UNIONを使用するネストした問合せの例を示します。
select * from (select x1 from t1 union select x2 from t2), (select x3 from t3 group by x3) where x1=x3;
副問合せの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の副問合せに関する説明を参照してください。
パフォーマンスへの影響: 不定
同じ文を複数回生成し、その生成のたびに異なる値を検索するアプリケーションが存在する場合は、パラメータ化した文を準備して、コンパイル時間を短縮します。たとえば、アプリケーションで次のような文が生成されるとします。
SELECT A FROM B WHERE C = 10 SELECT A FROM B WHERE C = 15
これらの文は、次の単一の文に置き換えることができます。
SELECT A FROM B WHERE C = ?
TimesTenでは、準備済の文はコミットされると自動的に共有されます。したがって、文の実行を準備するためのアプリケーションによるリクエストは、その文の準備済バージョンがすでにシステムに存在する場合は非常に高速に処理されます。また、同じ文を実行するリクエストを繰り返し行う場合は、その文の事前準備済バージョンを共有することによって、準備でのオーバーヘッドを回避できます。
TimesTenで準備済の文を共有できる場合でも、パフォーマンス上の理由から、パラメータ化した文を使用することをお薦めします。パラメータ化した文を使用すると、文の共有による軽減に加えて、準備でのオーバーヘッドをさらに軽減することができます。
パフォーマンスへの影響: 大
SQL文の準備は高コストの処理であるため、アプリケーションでは準備APIのコール回数を最小限にする必要があります。ほとんどのアプリケーションでは、接続の開始時に一連の文を準備し、接続中にこれらの文を使用します。この方法は、数百または数千のトランザクションで構成されている長時間の接続に適しています。ただし、接続が比較的短時間の場合でも、すべてのスレッドまたはプロセスのために文を準備して実行する長時間の接続を確立することをお薦めします。この場合、通信でのオーバーヘッドと準備でのオーバーヘッドのバランスを考慮する必要があり、アプリケーションごとに調べることができます。準備済の文は、接続がクローズされると無効になります。
関連情報については、『Oracle TimesTen In-Memory Databaseリファレンス』のttSQLCmdCacheInfoGetに関する説明を参照してください。
パフォーマンスへの影響: 大
TimesTenには、データをより効率的に保存する、列レベルでの表圧縮機能があります。このメカニズムでは、列内に重複する値が冗長的に格納されないようにすることで、表の領域を削減します。
TimesTen表の列を圧縮する場合は、次の点を考慮してください。
国または州の名前などの全体にわたって値が繰り返されている場合は、列を圧縮します。
複数の列に同時に頻繁にアクセスする場合は、列を圧縮します。
TT_TINYINTなどの少量の記憶域を必要とするデータ型を含む列は圧縮しません。
TimesTenはNULL値を圧縮しません。
コラム圧縮の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の表のインメモリー・コラム圧縮に関する説明を参照してください。
圧縮列グループは、表の作成時に追加するか、ALTER TABLE文を使用して後で追加できます。ALTER TABLE文を使用して、圧縮列グループ全体を削除できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のALTER TABLEに関する説明およびCREATE TABLEに関する説明を参照してください。
ttSize組込みプロシージャをコールして、TimesTenが圧縮された表に対して実行した圧縮のレベルを確認できます。ttSize組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttSizeに関する説明を参照してください。
パフォーマンスへの影響: 不定
TimesTenは読取り問合せおよび書込み問合せを同時に最適に処理します。ttOptSetFlag ('tblLock',1)などのトランザクション・レベル・オプティマイザ・ヒントまたは/*+ tt_tbllock(1) tt_rowlock(0) */などの文レベル・オプティマイザ・ヒントを使用すると、読取り専用同時実行性に対して読取り問合せを最適化できます。読取り最適化問合せと同時に処理する書込み問合せは競合する可能性があります。
ttDbWriteConcurrencyModeSet組込みプロシージャにより、同時書込み処理時に読取り最適化を制御できます。この組込みプロシージャにより、標準モードと拡張書込み同時モードを切り替えることができます。標準モードでは、オプティマイザは読取り最適化のヒントを考慮します。拡張書込み同時モードでは、オプティマイザは読取り最適化のヒントを無視し、共有の読込み表ロックまたは書込み表ロックを使用しません。
|
注意: 表ロックの詳細は、「ロックの粒度」を参照してください。文レベル・オプティマイザ・ヒントの詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の文レベル・オプティマイザ・ヒントに関する説明を参照してください。 トランザクション・レベル・オプティマイザ・ヒントの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttOptSetFlagに関する説明を参照してください。 |
ttDbWriteConcurrencyModeSet組込みプロシージャのmodeを1に設定して、拡張書込み同時モードを有効にし、読取り最適化を無効にします。modeを0に設定して、拡張書込み同時モードを無効にし、読取り最適化を再有効化します。
modeを1に設定すると、すべてのトランザクションおよび文の表ロック・オプティマイザ・ヒントが無視されます。これは次に影響します。
SELECT問合せの共有読取り表レベル・ロックおよびオプティマイザ・ヒントでトリガーされる副問合せ。
オプティマイザ・ヒントでトリガーされるDML文の書込み表ロック。
modeの設定にかかわらず、オプティマイザ・ヒントでトリガーされない表ロックは影響を受けません。
ttDbWriteConcurrencyModeSet組込みプロシージャのwaitを0に設定して、通知せずにモード切替えを実行します。ttDbWriteConcurrencyModeSet組込みプロシージャのwaitを1に設定して、モード切替えが完了するまで組込みプロシージャが待機するように強制します。
特定のSQL文を実行するとttdbWriteConcurrencyModeSet組込みプロシージャのモードが移行中のままになります。このようなSQL文は次の2つの条件に一致します。
書込み同時実行モードの影響を受ける場合。
異なる書込み同時実行モードでコンパイルされた場合。
ttdbWriteConcurrencyModeSet組込みプロシージャのモードは、このようなSQL文がすべて完了するまで移行中のままになります。ttDbWriteConcurrencyModeSet組込みプロシージャは、モード移行時にロック取得を使用して待機します。ttDbWriteConcurrencyModeSet組込みプロシージャが現在の接続のタイムアウト時間内にロックを許可されない場合、エラーが返されます。
|
注意: ttDbWriteConcurrencyModeSet、ttLockWait、ttDbWriteConcurrencyModeGet組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDbWriteConcurrencyModeSet、ttLockWait、およびttDbWriteConcurrencyModeGetに関する説明を参照してください。 |
次の項では、マテリアライズド・ビューのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 不定
結合行の数が多くなると、パフォーマンスが低下します。結合条件を制御することで、結合行の数および結合される表の数を制限できます。たとえば、ある表の1行を他の表の1行または最大数行にマップする一致条件のみを使用します。
パフォーマンスへの影響: 不定
結合を作成するSELECT文に指定されているディテール表の列に対して索引を作成します。また、マテリアライズド・ビュー自体に対して索引を作成することも検討します。これによって、マテリアライズド・ビューを継続して更新する場合のパフォーマンスを向上させることができます。
ディテール表でのUPDATEまたはDELETE処理が列に対する条件に基づくことが多い場合、可能であれば、その列でマテリアライズド・ビューの索引の作成を試行します。
たとえば、CustOrderは、2つの表に基づいた顧客注文のマテリアライズド・ビューです。2つの表とは、CustomerおよびbookOrderです。前者には2つの列(custNoおよびcustName)、後者には3つの列(ordNo、bookおよびcustNo)があるとします。特定の注文を変更するために、条件bookOrder.ordNo=constを使用してbookOrder表を更新することが多い場合は、CustOrder.ordNoに対して索引を作成します。また、条件bookOrder.custNo=constに基づいて更新を行うことが多い場合は、CustOrder.custNoに対して索引を作成します。
両方の条件を使用して更新することが多く、両方の索引を作成する十分な領域がない場合は、ビューにbookOrder.rowIdを追加し、これに対して索引を作成します。この場合、TimesTenは、ビュー内のすべての行を直接同時に更新するのではなく、ディテール行の更新ごとにビューを更新します。更新する行を検索するスキャンは行スキャンではなく索引スキャンであるため、結合行を生成する必要はありません。
実行計画でViewUniqueMatchScanが使用されている場合、実行速度が遅くなったり、実行に必要以上の領域が必要になる場合があります。ViewUniqueMatchScanは、マテリアライズド・ビューの直接更新または直接削除に変換できない更新または処理に使用され、結合行とマテリアライズド・ビュー内の関連行間に一意のマッピングは存在しません。これは、更新または削除される各ディテール表に対して一意キーを選択すると修正できます。
パフォーマンスへの影響: 不定
結合列またはGROUP BY列の更新には古い値の削除および新しい値の挿入を実行する必要があるため、結合列の更新は行わないようにしてください。
複数の表を参照する式の更新は行わないようにしてください。この式の中のある値が更新されると、新しい値を取得する別の結合処理がTimesTenによって実行される可能性があるため、ビューを直接更新できなくなる場合があります。
次のいずれかの場合、更新または削除に基づくビュー・メンテナンスにより多くのコストがかかります。
ビューを直接更新できない場合。たとえば、ディテール表のUPDATEまたはDELETE文に指定されているすべての列がビューで選択されているわけではありません。
ビューの行から結合行への1対1マッピングの指示がない場合。
次に例を示します。
CREATE MATERIALIZED VIEW v1 AS SELECT x1 FROM t1, t2 WHERE x1=x2; DELETE FROM t1 WHERE y1=1;
結合行によって1つのビュー行のみが影響を受けるようにするために追加の処理が必要であるため、追加のコストがかかります。
この問題は、x1がUNIQUEであるか、またはt1の一意キーがビューの選択リストに含まれている場合は解決されます。ROWIDは、常に一意キーとして使用できます。
パフォーマンスへの影響: 不定
内部表に対して変更を行うと、外部結合のメンテナンスにより多くのコストがかかるため、外部結合の内部表への変更は行わないようにしてください。可能な場合は、内部表でINSERT処理を実行してから、関連する結合行を外部表に挿入します。同様に、可能な場合は、外部表でDELETE処理を実行してから、内部表での削除を実行してください。これによって、一致しない行を一致する行に変換したり、その逆の処理を行う必要がなくなります。
パフォーマンスへの影響: 不定
ビューSelectListに投影される列の数はパフォーマンスに影響する可能性があります。SelectList内の列の数が増えると、ディテール表に対する処理の準備時間が長くなります。また、ビューのディテール表に対する処理の実行時間も長くなります。必要のない値または式は選択しないでください。
ビューのディテール表に対する処理を準備する際に、オプティマイザは一時索引の使用を検討します。これは、処理およびビューによっては、準備時間を大幅に長くする可能性があります。準備時間が長い場合は、ttOptSetFlagを使用して、一時範囲索引および一時ハッシュ・スキャンを無効にすることを検討してください。
次の項では、トランザクション使用時のパフォーマンスを向上させる方法について説明します。
パフォーマンスへの影響: 大
トランザクション・ログ・レコードを生成する各トランザクション(INSERT、DELETEまたはUPDATEを実行するトランザクションなど)では、コミット時にディスクへの書込みが行われます。ディスクI/Oは、レスポンス時間に影響を及ぼし、グループ・コミットの有効性によっては、スループットに影響を及ぼす可能性があります。
パフォーマンスを重視するアプリケーションの場合は、コミット時に不要なディスクへの書込みが行われないようにする必要があります。パフォーマンス分析ツールを使用して、アプリケーションでディスクへの書込みにかかる時間を(CPU時間と比較して)測定します。I/Oが過剰であると思われる場合は、次の2つの手順を実行してコミット時に書込みが行われないようにできます。
トランザクション・サイズを調整します。
トランザクションのコミット時にディスクへの書込みを実行するかどうかを調整します。詳細は、「永続コミットの適切な使用」を参照してください。
長時間のトランザクションでは、短時間のトランザクションと比較して単位時間当たりのディスクへの書込み回数が少なくなります。ただし、長時間のトランザクションによって、同時実行性が低くなる可能性もあります(第7章「トランザクション管理」を参照)。
パフォーマンスへの影響: 大
デフォルトでは、TimesTenのトランザクションをコミットするたびに、ディスクへの書込みが発生します。これによって、システムまたはアプリケーションで障害が発生した場合でも、コミット済のトランザクションは失われなくなります。アプリケーションで非永続コミットを実行すると、これらのディスクへの書込みの一部またはすべてが行われないようにすることができます。非永続コミットでは、トランザクション・ログをディスクに書き込むことを除き、永続コミットで実行されるすべての処理が実行されます。ロックは解除され、カーソルはクローズされますが、ディスクへの書込みは実行されません。
|
注意: 一部のドライバは、キャッシュ・メモリーへのデータの書込みも、ディスクへの書込みも、オペレーティング・システムが書込み完了通知を受け取って一定時間が経過してから行います。この場合、停電が発生すると、永続コミットしたと思われていた一部の情報が失われる可能性があります。このようなデータの損失を回避するには、完了通知の前に記録メディアに書き込むようにディスクを構成するか、または無停電電源装置を使用します。 |
非永続コミットのメリットは、レスポンス時間を減らし、スループットを向上させることができることです。デメリットは、システムで障害が発生した場合に、一部のトランザクションが失われる可能性があることです。アプリケーションでは、定期的に永続コミットまたはチェックポイントを実行してディスクへのトランザクション・ログの書込みを強制実行することによって、失われる可能性があるデータの量を減らすことができます。また、TimesTen自体でも、内部バッファが一杯になった場合にログをディスクに定期的にフラッシュしているため、失われる可能性があるデータの量が制限されます。
トランザクションは、接続ごとに永続的にするか、または永続性遅延モードにすることができます。アプリケーションでttDurableCommitプロシージャをコールして、特定のトランザクションの永続コミットを強制実行できます。
非永続コミットを使用しないアプリケーションでは、書込みおよびフラッシュのかわりに同期書込みを使用することをお薦めします。同期書込みを有効にするには、初期接続属性LogFlushMethod=2を設定します。
SYS.SYSTEMSTATS表のtxn.commits.durable列は、永続コミットを実行したトランザクションの数を示します。
パフォーマンスへの影響: 大
データベースに長時間接続されているアプリケーションでは、ディスクがログ・ファイルで一杯にならないように、ttCkpt組込みプロシージャを定期的にコールしてデータベースに対してチェックポイント処理を実行する必要があります。トランザクション一貫性チェックポイントは、データベースへの排他アクセスが必要であるため、パフォーマンスに大きな影響を与える可能性があります。
通常、ttCkptをコールして非ブロッキング(ファジー)・チェックポイントを実行する方が、ttCkptBlockingをコールしてブロッキング・チェックポイントを実行するより効率的です。非ブロッキング・チェックポイントの方が時間がかかる可能性がありますが、他のトランザクションでデータベースに対して同時に処理を実行できるため、全体的なオーバーヘッドを抑えることができます。トランザクション・ログ・ファイルの蓄積に使用するディスク領域の量を増やすことによって、連続するチェックポイント間の時間隔を長くできます。
トランザクション・ログのサイズが大きくなると(チェックポイント間の間隔が長い場合)、リカバリ時間もそれに応じて長くなります。システム・クラッシュまたはアプリケーション障害の後のリカバリ時間を短くする必要がある場合は、チェックポイント処理を頻繁に実行することをお薦めします。SYS.SYSTEMSTATS表のckpt.completed列は、チェックポイント処理が正常に実行された回数を示します。
パフォーマンスへの影響: 大
AUTOCOMMITモードはデフォルトで有効になっており、文ごとにコミットが実行されます。ただし、文を実行するたびにコミットを実行すると、パフォーマンスが大幅に低下する可能性があります。このため、通常は、プログラム環境に適したAPIを使用して、AUTOCOMMITを無効にすることをお薦めします。
SYS.SYSTEMSTATS表のtxn.commits.count列は、トランザクションのコミット数を示します。
|
注意: アプリケーションで明示的なコミットを指定しなかった場合、メモリー、ロックなどの重要なリソースを不必要に使い果たしてしまう可能性があります。すべてのアプリケーションで、定期的なコミットを実行する必要があります。 |
パフォーマンスへの影響: 大
誤ったデータまたはアプリケーション障害のためトランザクションに問題が発生した場合、トランザクションはTimesTenによって自動的にロールバックされます。また、アプリケーションでは、多くの場合、トランザクションのロールバックが明示的に実行され、デッドロックまたはタイムアウトの状態からリカバリされます。これは、パフォーマンスの観点から見ると、ロールバックはリソースを浪費し、トランザクション全体が無駄になってしまうため望ましくありません。
アプリケーションでは、不要なロールバックが行われないようにする必要があります。つまり、可能なかぎり、競合が発生しないようにアプリケーションを設計し、アプリケーションまたは入力データを事前にチェックしてエラーを検出する必要があります。SYS.SYSTEMSTATS表のtxn.rollbacks列は、ロールバックされたトランザクションの数を示します。
パフォーマンスへの影響: 大
大量のDELETE文を回避するために次のような方法を考慮します。
1つのSQL文で表から(100,000以上)大量の行を削除しようとすると、処理に時間がかかる場合があります。TimesTenでは、処理でロールバックが必要な場合に備えて削除された各行を記録しますが、これはディスクにバインドされた操作のため、これらのログ・レコードの書込みには非常に時間がかかります。
このような大量のDELETE処理のもう1つの問題は、書込み集中型の削除トランザクションの発生中は他のデータベース操作が遅くなることです。1つのトランザクションで何百万行も削除するには、完了するまでに数分かかります。
何百万もの行を一度に削除することによる別の問題は、この表がレプリケートされるときに発生します。レプリケーションではコミット済のトランザクションのみが転送されるため、単一の、数百MB (またはGB)からなるトランザクションを転送することでレプリケーション・エージェントが遅くなります。TimesTenのレプリケーションは、多数の小規模なトランザクション用に最適化されているため、何百万もの行が1つのトランザクションで削除されるとパフォーマンスが低下します。
DELETE SQL文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のDELETEに関する説明を参照してください。
表からすべての行を削除するかわりに、TRUNCATE TABLE SQL文の使用を検討します。このSQL文には、WHERE句を指定しないDELETE (ロギングを大幅に減少)と同じ効果があります。さらに、レプリケーションを使用する際に、TRUNCATE操作は、削除される各行に対して1つの操作ではなく単一の操作して、別のデータベースにレプリケートされます。
TRUNCATE TABLE SQL文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のTRUNCATE TABLEに関する説明を参照してください。
大量の行を削除する必要があり、TRUNCATE TABLEが適切でない場合は、DELETE FIRST NumRows句を使用して表から行をバッチで削除することを検討します。DELETE FIRST NumRows構文では、「DELETE FROM TableName WHERE ...」を一連の「DELETE FIRST 10000 FROM TableName WHERE ...」操作に変更できます。
大量のDELETE操作をより小さい操作のバッチに分割することで、行ははるかに高速に削除され、システムおよびレプリケーション全体の同時実行性は影響を受けません。
DELETE FIRST句の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のDELETEに関する説明を参照してください。
パフォーマンスへの影響: 大
トランザクションのコミットの再要求段階の間に、TimesTenのリソース・クリーンアップが発生します。再利用要求の間、TimesTenはトランザクションの開始時点からのすべてのトランザクション・ログ記録を再調査し、実行する必要がある再利用要求操作を決定します。
大きなトランザクション・コミットの再利用要求段階では大量の処理が必要になり、リソースを大量に消費します。ただし、コミット・バッファの最大サイズを増やすことでパフォーマンスを向上させることができます。コミット・バッファとは、再利用要求操作で使用されるトランザクション・ログ記録のキャッシュです。
TimesTenのCommitBufferSizeMax接続属性を使用して、コミット・バッファの最大サイズをMB単位で指定できます。この設定のスコープは、現在のセッションです。
詳細は、「コミット・バッファの再利用操作用の構成」を参照してください。
次の項では、データベースのシャットダウン後またはシステム障害の発生後に、データベース・リカバリのパフォーマンスを向上させるためのヒントを示します。
パフォーマンスへの影響: 大
RecoveryThreads属性を索引またはCPUの数に設定し、リカバリ・パフォーマンスを向上させます。
パフォーマンスへの影響: 大
データベースに大量のチェックポイント・ファイル(数GB単位)がある場合、初期接続またはリカバリ操作が十分に機能せず、極端な場合には完了までに数時間もかかることがあります。大量のチェックポイント・ファイルがある場合にリカバリのパフォーマンスを改善するには、CkptReadThreads接続属性を使用して、データベースをメモリーにロードする際にチェックポイント・ファイルの読込みに使用される同時スレッドの数を増やします。
CkptReadThreads接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptReadThreadsに関する説明を参照してください。
次の項では、複数CPUのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 不定
TimesTenで実行される概算スケーリングを確認する方法の1つとして、使用しているシステムでいずれかのスケーラブル・デモ・アプリケーション(tptbmなど)を実行する方法があります。
tptbmアプリケーションには、マルチユーザーのスループット・ベンチマークが実装されています。これでは、TimesTen処理およびSELECT、UPDATE、INSERTなどを組み合せたトランザクションを実行するプロセス数を変更するオプションを含め、その実行方法を制御できます。tptbm -helpを実行すると、オプションの完全なリストが表示されます。
デフォルトでは、このデモは、トランザクションごとに1つの処理を実行します。トランザクションごとの処理数を増やして、実際のアプリケーションに近づけることができます。トランザクションが大きくなると、アプリケーションのプロファイルによって、スケーラビリティが向上する場合と低下する場合があります。
このデモのマルチプロセッサ・バージョンを実行すると、複数CPUシステムでのアプリケーションのパフォーマンスを予測して評価できます。デモでのスケーラビリティが高く、アプリケーションでのスケーラビリティが低い場合は、アプリケーションを簡略化して問題の箇所を確認します。TimesTenのコールをコメント・アウトしても、アプリケーションに問題があるためスケーリングが不十分なままになる場合があります。
また、たとえば、シミュレートされたアプリケーション・データの一部が正しく生成されていないため、数行の同じ行がすべての処理でアクセスされていることが発見される場合があります。アクセスでデータが変更される場合、そのタイプのローカライズされたアクセスは、スケーラビリティを大幅に阻害することになります。
tptbmおよびその他のデモ・アプリケーションの詳細は、クイック・スタートのホームページ(install_dir/quickstart.html)を参照してください。「Sample Programs」の下のODBCリンクに移動してください。
パフォーマンスへの影響: 不定
SYS.SYSTEMSTATS表のlock.timeoutsフィールドまたはlock.locks_granted.waitフィールドを確認します。これらの値が大きい場合は、過度の競合が発生している可能性を示し、スケーリングが不十分になることがあります。
TimesTenはCPU集中型であるため、CPU当たりのデータベース集中型の接続の数を1つのみにすることで、最適なスケーリングが実現されます。4CPUシステムまたはハイパースレッド機能を持つ2CPUシステムを使用する場合、4プロセッサ・アプリケーションのパフォーマンスは良好ですが、8プロセッサ・アプリケーションのパフォーマンスは低くなります。アクティブなスレッド間での競合が多くなりすぎます。ただし、多くのトランザクションが永続的にコミットされる場合、このルールは適用されません。この場合、ディスクへのI/O操作が増加するために接続が極度にCPU集中型にはならず、システムでより多くの同時接続をサポートできるようになります。
パフォーマンスへの影響: 不定
読取り処理のスケーラビリティは、書込み処理より優れています。読取りと書込みのバランスが、アプリケーションの実際のワークロードを反映していることを確認してください。
パフォーマンスへの影響: 不定
準備にはスケーラビリティがありません。複数回実行されるコマンドは事前に準備するようにしてください。SYS.SYSTEMSTATS表のstmt.prepares.count列およびstmt.reprepares.count列に、コマンドが準備された回数、または(索引の作成および削除が原因で)コマンドが自動的に再準備された回数が示されます。いずれかの値が大きい場合は、接続プーリングを実行するようにアプリケーションを変更して、接続の確立および切断がほとんど発生しないようにします。
接続にはスケーラビリティがありません。複数回実行されるコマンドは事前に準備するようにしてください。SYS.SYSTEMSTATS表のconnections.established.count列を参照してください。このフィールドの値が大きい場合は、接続プーリングを実行するようにアプリケーションを変更して、接続の確立および切断がほとんど発生しないようにします。
パフォーマンスへの影響: 不定
マルチプロセッサ・システムでは、RecoveryThreadsを最小値(使用可能なCPUの数、索引の数)に設定すると、リカバリが必要な場合に、索引をパラレルで再構築できるようになります。再構築が必要な場合、進行状況はユーザー・ログで確認できます。RecoveryThreadsを使用可能なCPUの数より大きい値に設定すると、リカバリに必要な時間が、シングルスレッドの場合より長くなります。
パフォーマンスへの影響: 不定
マルチプロセッサ・システムでは、複数のスレッドで同じコマンドを実行する場合、スループットまたはレスポンス時間を向上させるためにPrivateCommands=1を設定します。プライベート・コマンドを使用すると、使用される一時領域の量が増加します。
次の項では、XLAのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 大
XLAを使用する場合は、トランザクション・ログ・バッファのサイズを大きくすることをお薦めします。XLAが有効になっている場合は、XLAに関する追加情報を格納するために追加のトランザクション・ログ・レコードが生成されます。トランザクション・ログ・バッファのサイズが適切かどうかを確認するには、SYS.MONITOR表のエントリLOG_FS_READSおよびLOG_BUFFER_WAITSの変更に注意します。パフォーマンスを最適にするには、この2つの値が0のままである必要があります。これらの値を0のままにするには、トランザクション・ログ・バッファのサイズの増加が必要な場合があります。
パフォーマンスへの影響: 中
複数の更新レコードを一度にプリフェッチする処理は、XLAから各更新レコードを個々に取得する処理より効率的です。AUTO_ACKNOWLEDGEモードを使用すると、更新がプリフェッチされないため、他のモードよりも時間がかかります。可能な場合は、更新を重複して行うことができるようにアプリケーションを設計すると、DUPS_OK_ACKNOWLEDGEの使用、または更新の明示的な確認が可能になります。各メッセージを個々に確認しないことがアプリケーションで許容される場合は、明示的に更新を確認すると、最も高いパフォーマンスを得ることができます。
レプリケーション操作時のパフォーマンス向上に関する推奨事項の詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケーションのパフォーマンス向上に関する説明を参照してください。
キャッシュ・グループ使用時のパフォーマンス向上に関する推奨事項の詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』の「キャッシュ・パフォーマンス」を参照してください。
