| Oracle® TimesTen In-Memory Databaseオペレーション・ガイド リリース11.2.1 B56047-02 |
|
 戻る |
 次へ |
TimesTen Data Managerを使用したアプリケーションは、従来のDBMSを使用したアプリケーションと比較すると、データ・アクセスのパフォーマンスが数倍向上します。ただし、アプリケーションの設計とチューニングが適切でなければ、TimesTenのメリットを活かしきれない場合もあります。この章では、TimesTenアプリケーションのパフォーマンスに影響する要因について説明します。この要因には、データ変換のように影響の少ないものから、実行時のコマンド準備などのように影響が大きいものまで様々な要因があります。
この章では、あらゆる要因を説明します。これらの要因では、次のような設問が重要になります。
どのようにして問題を検出するか
パフォーマンスへの潜在的な影響はどの程度か
パフォーマンスが向上するタイミングはいつか
パフォーマンスの代償は何か
この章で説明するように、パフォーマンス上の問題点の多くはSYS.MONITOR表を調べて確認できます。
この章の内容は次のとおりです。
TimesTen Javaアプリケーションのチューニングの詳細は、『Oracle TimesTen In-Memory Database Java開発者ガイド』の「アプリケーション・チューニング」を参照してください。TimesTen Cアプリケーションのチューニングの詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』の「アプリケーション・チューニング」を参照してください。
次の項では、システムおよびデータベースのチューニングに関するヒントを示します。
パフォーマンスへの影響: 大
データベース全体がメイン・メモリーに収まるように、システムを構成してください。仮想メモリーを使用すると、パフォーマンスが大幅に低下します。パフォーマンス監視ツールによって、過度のページングや仮想メモリー・アクティビティが示される場合は、データベース（作業セット）のサイズは適切ではありません。
大容量の共有メモリーをプロセスに割り当てるには、物理メモリーの追加やシステム・ソフトウェアの設定が必要な場合もあります。データベースのサイズ見積りには、TimesTenのttSizeユーティリティを使用できます。
パフォーマンスへの影響: 不定
データベースの作成時には、そのサイズを指定する必要があります。具体的には、データベースの永続パーティションおよび一時パーティションのサイズを指定します。データベースおよび共有メモリーのサイズを指定する方法の詳細は、「データベースのサイズの指定」を参照してください。
パフォーマンスへの影響: 不定
PL/SQLランタイム・システムでは、TimesTenのPL/SQLオブジェクトに関するメタデータ、および現在実行中のPL/SQLプログラム・ユニットまたは最近実行されたPL/SQLプログラム・ユニットの実行可能コードの保持に、共有メモリーの領域が使用されます。この共有メモリー領域のサイズは、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のデフォルト値は32MBです。この値は、適度に複雑な数百個のPL/SQLプログラム・ユニットの実行に十分なサイズです。本番のワークロードでしばらく実行した後、PinHitRatioの値を確認します。値が0.90より小さい場合は、PLSQL_MEMORY_SIZEを増やすことを検討してください。
パフォーマンスへの影響: 大
LogBufMBの値を大きくすると、パフォーマンスが大幅に向上する可能性があります。LOG_BUFFER_WAITSが大きくなっている場合は、LogBufMBの値を大きくします。
デメリットは、メモリーにバッファされるトランザクションが増え、プロセスがクラッシュしたときに失われるトランザクションが多くなる可能性があることです。DurableCommitsが有効になっている場合は、デフォルトのLogBufMB値を大きくしてもパフォーマンスは改善されません。
パフォーマンスへの影響: 不定
TimesTenには、永続データベースと一時データベースがあります。一時データベースは、最後の接続を解放した場合、あるいはシステムまたはアプリケーションに障害がある場合に破棄されます。
データベースをディスクに保存する必要がない場合は、一時データベースを作成することで、チェックポイントのオーバーヘッドを軽減できます。
トランザクション・ログは定期的にディスクに書き込まれますが、一時データベースは、完全にチェックポイントでディスクに書き込まれることはありません。一時データベースのトランザクション・ログに書き込まれるデータの量は、永続データベースに対して書き込まれるデータの量よりも少ないため、一時データベースの方がパフォーマンスは向上します。永続データベースの場合、データベースのサイズとアクティビティによっては、チェックポイント処理がかなりのオーバーヘッドとなる可能性がありますが、一時データベースの場合は、影響はほとんどありません。トランザクション・ログ・ファイルを削除するには、チェックポイントが必要になります。
パフォーマンスへの影響: 大
デフォルトでは、最初の接続が確立されたときにはアイドル・データベース（接続のないデータベース）がメモリーにロードされます。最後のアプリケーションのデータベースへの接続が切断されると、ディスクへのデータベースの書込み時に遅延が発生します。アプリケーションとデータベース間の接続と切断が連続して行われる場合は、メモリーへのデータベースのロードとアンロードも連続して行われる可能性があるため、過度のディスクI/Oおよびパフォーマンスの低下が発生します。同様に、使用するデータベースが非常に大きい場合は、アプリケーションでデータベースが使用される前に、メモリーにデータベースをロードしておくようにしてください。
データベースをメモリーにロードする際の遅延を回避するには、データベースのRAMポリシーを変更して、データベースがメモリーに常駐できるようにします。この方法のデメリットは、データベースがメモリーからアンロードされないため、最後の接続を切断してもチェックポイントが発生しないことです。このため、トランザクション・ログ・ファイルで占有されているディスク領域を解放するには、データベースのチェックポイント処理をアプリケーションで明示的に実行する必要があります。
また、一定期間だけデータベースをメモリーに常駐させ、新しい接続を受け入れるように指定することもできます。この期間に新しい接続が確立されなかった場合、データベースはメモリーからアンロードされ、チェックポイント処理が実行されます。また、システム管理者がデータベースのメモリーからのロードとアンロードを手動で実行できるように設定することも可能です。
データベースのRAMポリシーを変更するには、ttAdminユーティリティを使用します。
パフォーマンスへの影響: 大
データベースを複製する際は、ttAdminユーティリティの-ramLoadオプションを使用してください。これにより、データベースは、ブロッキング・チェックポイントでアンロードされるのではなく、接続可能な状態でメモリーに配置されます。「接続オーバーヘッドの回避」を参照してください。
データベースで競合が発生すると、アプリケーションのパフォーマンスが大幅に低下する可能性があります。
アプリケーションでの競合を軽減するには、次の手順を実行します。
適切なロック方法を選択します。詳細は、「最適なロック方法の選択」を参照してください。
複数の表またデータベースにデータを効果的に分散します。
ロックの競合および同時実行性の低下が原因でアプリケーションのパフォーマンスが低下している場合は、パフォーマンスを向上させるために、まず競合を軽減する必要があります。
ロックの競合の詳細は、SYS.MONITOR表内のLOCK_GRANTS_IMMED、LOCK_GRANTS_WAITおよびLOCK_DENIALS_COND列を参照してください。
LOCK_GRANTS_IMMEDでは、ロックが使用可能になり、ロック・リクエスト時に即時に付与された回数がカウントされます。
LOCK_GRANTS_WAITでは、ロックが使用可能になるまでリクエストしたユーザーが待機した後でロック・リクエストが付与された回数がカウントされます。
LOCK_DENIALS_CONDでは、ロックが使用可能になるまでユーザーが待機しなかったためロックが付与されなかった回数がカウントされます。
同時実行性が制限されたためスループットが低下している場合またはレスポンス時間が問題となっている場合は、アプリケーションでJDBCコールをシリアライズして競合を回避することができます。これを行うには、単一のスレッドでそれらのすべてのコールを発行します単一のスレッドを使用すると、アプリケーションの側でキューおよびスケジュールを行う必要があります。この場合、競合および待機時間を減らすためにCPU時間が多少長くなります。結果として、データベースに大部分の時間を使う同時実行性の低いアプリケーションのパフォーマンスが向上します。
パフォーマンスへの影響: 中
TimesTenのプラットフォームとなるすべてのオペレーティング・システムでは、メイン・メモリーに動的ファイル・システムのバッファ・プールが作成されます。このバッファ・プールを大きくできる場合は、TimesTenとオペレーティング・システムの両方がファイルのコピーをメモリー内に格納するため、TimesTenの一部の共有セグメントがページ・アウトされます。
実装されたメモリー・サイズの半分よりも小さいデータベースの場合は、この現象が発生しないこともあります。システムによっては、ファイル・システムで使用するメイン・メモリーを制限できます。また、この効果があまりないシステムもあります。HP-UX、SolarisおよびLinuxシステムの場合は、MemoryLock属性を使用してデータベースをメモリー内にロックするかどうかを検討してください。使用した場合は、データベースがページ・アウトされません。
HP-UXの場合は、カーネル・パラメータのdbc_min_pctとdbc_max_pctを設定することを検討してください。これらのパラメータでは、ファイル・システムで使用する実メモリーの最小値と最大値をパーセントで設定できます。最大値のデフォルトは50パーセントです。最大値は、10パーセントに引き下げることをお薦めします。
AIXの場合は、ラージ・ページの構成によって、共有セグメントをページングできないようにメモリー内にロックすると、ページングを回避できます。AIXでラージ・ページを構成する方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。
パフォーマンスへの影響: 中
初期ロード時など、特別な処理を実行する場合は、通常とは異なるオプションを選択できます。特に、バルク・ロードを行う場合はデータベース・レベル・ロックを使用することを検討してください。たとえば、ttBulkCpまたはttMigrateを使用するような場合です。これらの設定により、ロード時のパフォーマンスが2倍になることもあります。
データベース・レベル・ロックに代わる方法として、同時実行性を有効に利用する方法があります。-notblLockオプションを使用すると、ttBulkCp -iの複数のコピーを実行できます。ttBulkCpの最適なバッチ処理を行うには、-xp 256オプションを追加します。ttMigrateに-numThreadsオプションを指定して実行すると、個々の表または複数の表を同時にロードできます。
パフォーマンスへの影響: 大
TimesTen Data Managerドライバには、プラットフォームごとに、デバッグ・バージョンと本番バージョンの2種類があります。実際にデバッグを実行しないときは、本番バージョンを使用してください。デバッグ・ライブラリを使用すると、処理がかなり遅くなることがあります。各種プラットフォームのTimesTen Data Managerドライバについては、「Data Manager DSNの指定」および「ODBCドライバの指定」を参照してください。
Windowsの場合は、ODBC Driver Managerを使用するアプリケーションが、適切なTimesTenドライバにアクセスするDSNを使用していることを確認してください。また、直接リンクされるアプリケーションでは、適切なTimesTenドライバにリンクされていることを確認してください。アプリケーションからは、SQL_DRIVER_NAME引数を指定してODBC SQLGetInfo関数をコールし、使用するドライバを決定できます。
パフォーマンスへの影響: 大
ODBCとJDBCには、その両方にアプリケーションをデバッグするためのトレース機能があります。パフォーマンスを重視している場合は、アプリケーションのデバッグ時を除き、トレース機能を無効に設定してください。
JDBCのトレース機能を有効にするには、次のメソッドを使用します。
DriverManager.setLogStream method: DriverManager.setLogStream(new PrintStream(System.out, true));
デフォルトでは、トレース機能は無効です。このメソッドをコールしてから、JDBCドライバをロードする必要があります。トレース機能を有効にした後、アプリケーションの実行中はトレース機能を無効にできません。
パフォーマンスへの影響: 不定
JRockit、IBMおよびHPでは、Sun JVMより高パフォーマンスのJVMが提供されています。
パフォーマンスへの影響: 大
レプリケーション・スキームを計画する場合は、次の項目を確認してください。
LogBufMBのトランザクション・ログ設定によって、SYS.MONITOR表のLOG_FS_READSの値が0またはほとんど0になっていること。これで、レプリケーション・エージェントがディスクからトランザクション・ログ・レコードを読み取る必要がなくなります。LOG_FS_READSの値が大きくなる場合は、トランザクション・ログ・バッファ・サイズも大きくしてください。
CPUリソースが十分にあること。マスター・データベース上のレプリケーション・エージェントでは、すべてのサブスクライバのデータベースに対してスレッドが起動されます。各スレッドでは、トランザクション・ログの読取りと処理が独立して行われるので、この処理には十分なCPUリソースが必要です。
レプリケーション・スキームの送信側と受信側でCPUの能力が一致していない場合は、レプリケーションの受信側を高速な方のシステムに配置すること。
パフォーマンスへの影響: 中
RecoveryThreads初期接続属性を使用して、アクティブ・マスター・データベースの変更をスタンバイ・マスター・データベースに適用するスレッドの数を、1から2に増やします。スタンバイ側のRecoveryThreadsを2に設定した場合、フェイルオーバー発生時に高いスループットを維持するには、アクティブ側でも2に設定する必要があります。
また、アクティブ・スタンバイ・ペアの1つ以上の読取り専用サブスクライバでRecoveryThreadsを2に設定しても、スタンバイ・マスター・データベースからのレプリケーション・スループットを向上させることができます。
この属性を2に設定することによるメリットを利用するには、データベースが双方向以上のシステムでホストされている必要があります。
パフォーマンスへの影響: 不定
データベースの移行時にキャラクタ・セット変換がリクエストされた場合は、キャラクタ・セット変換がリクエストされない場合よりパフォーマンスが低下します。
次の項では、クライアント/サーバーのチューニングに関するヒントを示します。
パフォーマンスへの影響: 大
TimesTen Clientを使用してリモート・サーバー・マシンにあるデータベースにアクセスする場合、接続に対してネットワーク上のオーバーヘッドが発生します。可能な場合は、TimesTen Data Managerをローカルにアクセスするようにアプリケーションを作成し、アプリケーションをTimesTen Data Managerと直接リンクするようにしてください。
複数の接続で同時にデータベースにアクセスする場合、TimesTenは、ロックを使用して様々なトランザクションが明示的に分離されて処理されるようにします。TimesTenでは、第8章「トランザクション管理およびリカバリ」で説明されている分離レベルがサポートされています。また、データベース・レベル・ロック、表レベル・ロックおよび行レベル・ロックの各ロック・レベルがサポートされています。LockLevel接続属性を使用すると、データベース・レベル・ロックと行レベル・ロックのいずれを使用するかを指定できます。表ロックを使用するかどうかを示すオプティマイザ・ヒントを設定するには、ttOptSetFlagプロシージャを使用します。デフォルトのロック粒度は行レベル・ロックです。
データベースで競合がほとんど発生していない場合は、表レベル・ロックを使用します。これによって、パフォーマンスが改善され、デッドロックの可能性も低くなります。通常、トランザクションが短時間の場合または接続が少ない場合は、データベースで競合はほとんど発生しません。この場合、トランザクションが重複する可能性は低くなります。
また、表レベル・ロックは、文が表のほぼすべての行にアクセスする場合にも有効です。このような文には、1つのトランザクションで実行される問合せ、更新、削除、複数の挿入などがあります。
TimesTenでは、シリアライズ可能分離レベルでのみ表ロックが使用されます。アプリケーションにおいて他の分離レベルで表ロックが指定される場合は、表レベル・ロックが上書きされて行ロックが使用されます。ただし、オプティマイザ計画では、表レベル・ロックのヒントが引き続き表示される可能性があります。
データベース・レベル・ロックでは表レベル・ロックより同時実行性が制限されるため、通常、データ・ストア・レベル・ロックは、同時実行性が必要でない場合にバルク・ロードなどの初期化処理でのみ有効です。データ・ストア・レベル・ロックを使用すると、スループットは低下しますが、行レベル・ロックまたは表レベル・ロックよりレスポンス時間が向上します。
通常、同じ行にアクセスする必要がほとんどない同時トランザクションが多数存在する場合は、行レベル・ロックを使用することを薦めします。
行レベル・ロックを使用している場合、アプリケーションでは、トランザクションをSERIALIZABLEまたはREAD_COMMITTEDの分離レベルで実行できます。デフォルトの分離レベルはREAD_COMMITTEDです。Isolation接続属性を使用すると、これらの分離レベルのいずれかを新しい接続に指定できます。
SERIALIZABLEトランザクション分離レベルで実行すると、トランザクションの処理中、TimesTenですべてのロックが保持されるため、次の処理が実行されます。
行を更新するトランザクションでは、トランザクションがコミットされるまで書込みユーザーがブロックされます。
行を読み込むトランザクションでは、トランザクションがコミットされるまで書込みユーザーがブロックされます。
READ_COMMITTEDトランザクション分離レベルで実行すると、トランザクションの処理中、TimesTenで更新のロックのみが保持されるため、次の処理が実行されます。
行を更新するトランザクションでは、トランザクションがコミットされるまで、この行に対する読取りユーザーおよび書込みユーザーをブロックします。
ファントム行が発生する場合があります。ファントム行とは、同じトランザクション内で、特定の読取りで表示され、別の読取りでは表示されない行、または2つの異なる読取りで異なる形式で表示される行のことです。ファントム行は、トランザクション時に読取りのロックが早く解放されるため発生します。
タイムアウトおよびデッドロックのエラー（エラー番号6001、6002および6003）をチェックすると、システムに競合が過度に存在しているかどうかを確認できます。この情報は、SYS.MONITOR表のLOCK_TIMEOUTSおよび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で文を実行するために使用される計画の表示方法については、第10章「TimesTen問合せオプティマイザ」を参照してください。また、計画は、ttIsql showplanコマンドを使用して表示することもできます。アプリケーションで頻繁に実行される各文の計画を表示します。索引が条件を評価するために使用されていない場合は、索引を使用できるように、新しい索引の作成または文や問合せの再作成を検討してください。たとえば、比較条件（一致および不一致）の一方、またはBETWEEN条件に単一の列が表示される場合に、索引をWHERE句を評価するためにのみ使用できます。
この比較条件が頻繁に評価される場合は、再作成するのが妥当です。
WHERE c1+10 < c2+20
これを次のように書きなおします。
WHERE c1 < c2+10
c1に索引を作成します。
索引が存在することにより、UPDATE、INSERT、DELETE、CREATE VIEWなどの書込み操作の処理速度が遅くなります。アプリケーションでの読取りが少ないものの、表への書込みが多い場合は、その表の索引によってパフォーマンスが向上するのではなく、低下する可能性があります。
FIRSTキーワードは、SQL文の特定の数の行、SELECT、UPDATEおよびDELETEでの操作で使用できます。この属性は、スループットおよびレスポンス時間を改善できます。また、アプリケーションで、問合せに対して最大1行をフェッチすることを計画し、一意の索引が行のフェッチに使用されていない場合、アプリケーションでSQL_MAX_ROW_COUNTを1に設定する必要があります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。
場合によっては、問合せ評価の処理速度を向上するために、システムによって一時索引が作成される場合があります。このような場合が頻繁にある場合は、アプリケーション自体で索引を作成する方が効率的です。MONITOR表のCMD_TEMP_INDEXES列は、問合せ評価時に一時索引が作成された回数を示します。
表またはキャッシュ・グループに対して時間ベースのエージングを実装している場合は、タイムスタンプ列に索引を作成すると、エージングのパフォーマンスが向上します。詳細は、「時間ベースのエージング」を参照してください。
パフォーマンスへの影響: 不定
TimesTen Data Managerでは、ハッシュ索引、範囲索引およびビットマップ索引の各索引がサポートされています。各索引構造には、それぞれの長所があります。
ハッシュ索引は、CREATE TABLE文またはALTER TABLE文にUNIQUE HASH句を指定して作成します。ハッシュ索引を使用するには、表に主キーが必要です。
範囲索引は、デフォルトではCREATE TABLE文で作成します。また、CREATE 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 TABLE文のUNIQUE HASH ON句で指定するPAGESパラメータで決まります。PAGESの値は、表の予想行数を256で割った値にする必要があります。小さい値を指定すると、競合の数が増加してパフォーマンスが低下します。一方、大きい値を指定すると、パフォーマンスが多少向上する場合がありますが、索引で使用する追加の領域が必要になります。
索引付けする値の数が大きく変動する場合は、大きい索引を作成することをお薦めします。表のサイズを正確に予測できない場合は、CREATE INDEXで範囲索引を使用することを検討してください。また、索引付けする列が大きいCHAR値またはバイナリ値の場合、あるいは索引付けする列が多い場合は、一意索引の使用を検討してください。これらの場合は、一意索引の方がハッシュ索引より高速になる場合があります。
表のサイズが大きくなるにつれてレコード挿入のパフォーマンスが低下する場合は、表の予想サイズを小さく見積りすぎていた可能性があります。ALTER TABLE文を使用してUNIQUE HASH ON句のPAGES値を再設定することによって、ハッシュ索引のサイズを変更できます。
パフォーマンスへの影響: 不定
外部キーを宣言しても、SELECT問合せのパフォーマンスには影響ありません。ただし、外部キーが定義された表でINSERTおよびUPDATEを実行する場合、および外部キーで参照される表でUPDATEおよびDELETEを実行する場合は、パフォーマンスが低下します。この低下は、表を参照する外部キーの数または表に定義されている外部キーの数に比例します。
パフォーマンスへの影響: 大
データベース内のデータに関する統計が利用できる場合、TimesTenオプティマイザは、コマンドを準備する際に、それらの統計を使用してデータへの最適なパスを決定します。統計がない場合、TimesTenオプティマイザは、データ配布に関して一般的な予測を行います。パフォーマンス上の理由から、TimesTenでは、統計が計算される際に表または行のロックは保持されません。
文に対して生成された計画を確認し、それが最適ではないと考えられる場合は、文を準備する前に統計を計算し、計画を再度確認することを検討してください。詳細は、第10章「TimesTen問合せオプティマイザ」を参照してください。
計画を確認していない場合は、統計を計算することをお薦めします。この情報によって効率的な計画を生成できる可能性が高くなります。
統計の計算用には、ttOptUpdateStatsおよびttOptEstimateStatsの2つの組込みプロシージャがあります。
ttOptUpdateStats組込みプロシージャは、対象となる表のすべての行を評価し、正確な統計を計算します。
ttOptEstimateStats組込みプロシージャは、対象となる表の一部の行のみを評価し、見積り統計を計算します。
統計の見積りは高速に実行できますが、計算結果は正確性に劣る場合があります。処理時間が問題にならない場合は、通常、ttOptUpdateStatsを使用することをお薦めします。アプリケーション全体のパフォーマンスに影響を及ぼす場合は、見積りの方が有効です。10パーセントのサンプルで統計を計算すると、正確な統計を計算するより処理が約10倍速くなり、通常は同じ実行計画が生成されます。統計の計算には時間がかかるため、データベースをロードした後で（コマンドを準備する前に）1回計算し、それ以降はデータの編成を大きく変更した場合にのみ計算することをお薦めします。データベースをロードした後、および大量の挿入または削除を実行した後は、常に統計を更新することをお薦めします。
パフォーマンスへの影響: 不定
アプリケーションでALTER TABLE文を使用すると、表に対して列の追加および破棄を実行することができます。ALTER TABLE文自体は、ほとんどの場合、非常に高速に実行できますが、表に行った変更が原因で発生する後続の処理に時間がかかることがあります。アプリケーションで発生する実際のパフォーマンスの低下の程度は、表の変更回数および表に対して実行される処理の種類によって異なります。
VARCHAR列およびVARBINARY列の破棄は、他のデータ型の列の破棄より時間がかかります。これは、破棄対象の列内の既存のVARCHAR値および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に関する説明を参照してください。
次の項では、マテリアライズド・ビューのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 不定
結合行の数が多くなると、パフォーマンスが低下します。結合条件を制御することで、結合行の数および結合される表の数を制限できます。たとえば、ある表の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文に指定されているすべての列がビューで選択されているわけではありません。
ビューの行から結合行への１対１マッピングの指示がない場合。
次に例を示します。
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つの手順を実行してコミット時に書込みが行われないようにできます。
トランザクション・サイズを調整します。
トランザクションのコミット時にディスクへの書込みを実行するかどうかを調整します。詳細は、「永続コミットの適切な使用」を参照してください。
長時間のトランザクションでは、短時間のトランザクションと比較して単位時間当たりのディスクへの書込み回数が少なくなります。ただし、長時間のトランザクションによって、同時実行性が低くなる可能性もあります（第8章「トランザクション管理およびリカバリ」を参照）。
デフォルトでは、TimesTenのトランザクションをコミットするたびに、ディスクへの書込みが発生します。これによって、システムまたはアプリケーションで障害が発生した場合でも、コミット済のトランザクションは失われなくなります。アプリケーションで非永続コミットを実行すると、これらのディスクへの書込みの一部またはすべてが行われないようにすることができます。非永続コミットでは、トランザクション・ログをディスクに書き込むことを除き、永続コミットで実行されるすべての処理が実行されます。ロックは解除され、カーソルはクローズされますが、ディスクへの書込みは実行されません。
|
注意: 一部のコントローラまたはドライバは、コントローラのキャッシュ・メモリーにのみデータを書き込むか、または書込みが完了したことがオペレーティング・システムに通知されてしばらくしてからのみディスクにデータを書き込みます。この場合、停電が発生すると、永続コミットしたと思われていた一部の情報が失われる可能性があります。このようなデータの損失を回避するには、完了通知の前に記録メディアに書き込むようにディスクを構成するか、または無停電電源装置を使用します。 |
非永続コミットのメリットは、レスポンス時間を減らし、スループットを向上させることができることです。デメリットは、システムで障害が発生した場合に、一部のトランザクションが失われる可能性があることです。アプリケーションでは、定期的に永続コミットまたはチェックポイントを実行してディスクへのトランザクション・ログの書込みを強制実行することによって、失われる可能性があるデータの量を減らすことができます。また、TimesTen自体でも、内部バッファが一杯になった場合にログをディスクに定期的にフラッシュしているため、失われるデータの量が制限されます。
トランザクションは、接続ごとに永続的にするか、または永続性遅延モードにすることができます。アプリケーションでttDurableCommitプロシージャをコールして、特定のトランザクションの永続コミットを強制実行できます。
非永続コミットを使用しないアプリケーションでは、書込みおよびフラッシュのかわりに同期書込みを使用することをお薦めします。同期書込みを有効にするには、初期接続属性LogFlushMethod=2を設定します。
SYS.MONITOR表のXACT_D_COMMITS列は、永続コミットを実行したトランザクションの数を示します。
データベースに長時間接続されているアプリケーションでは、ディスクがログ・ファイルで一杯にならないように、ttCkpt組込みプロシージャを定期的にコールしてデータベースに対してチェックポイント処理を実行する必要があります。トランザクション一貫性チェックポイントは、データベースへの排他アクセスが必要であるため、パフォーマンスに大きな影響を与える可能性があります。
通常、ttCkptをコールして非ブロッキング（ファジー）・チェックポイントを実行する方が、ttCkptBlockingをコールしてブロッキング・チェックポイントを実行するより効率的です。非ブロッキング・チェックポイントの方が時間がかかる可能性がありますが、他のトランザクションでデータベースに対して同時に処理を実行できるため、全体的なオーバーヘッドを抑えることができます。トランザクション・ログ・ファイルの蓄積に使用するディスク領域の量を増やすことによって、連続するチェックポイント間の時間隔を長くできます。
トランザクション・ログのサイズが大きくなると（チェックポイント間の間隔が長い場合）、リカバリ時間もそれに応じて長くなります。システム・クラッシュまたはアプリケーション障害の後のリカバリ時間を短くする必要がある場合は、チェックポイント処理を頻繁に実行することをお薦めします。SYS.MONITOR表のDS_CHECKPOINTS列は、チェックポイント処理が正常に実行された回数を示します。
AUTOCOMMITモードはデフォルトで有効になっており、文ごとにコミットが実行されます。ただし、文を実行するたびにコミットを実行すると、パフォーマンスが大幅に低下する可能性があります。このため、通常は、プログラム環境に適したAPIを使用して、AUTOCOMMITを無効にすることをお薦めします。
SYS.MONITOR表のXACT_COMMITS列は、トランザクションのコミット数を示します。
|
注意: アプリケーションで明示的なコミットを指定しなかった場合、メモリー、ロックなどの重要なリソースを不必要に使い果たしてしまう可能性があります。すべてのアプリケーションで、定期的なコミットを実行する必要があります。 |
誤ったデータまたはアプリケーション障害のためトランザクションに問題が発生した場合、トランザクションはTimesTenによって自動的にロールバックされます。また、アプリケーションでは、多くの場合、トランザクションのロールバックが明示的に実行され、デッドロックまたはタイムアウトの状態からリカバリされます。パフォーマンスの観点から見ると、これらの処理は望ましくありません。ロールバックはリソースを浪費し、トランザクション全体が無駄になってしまうためです。
アプリケーションでは、不要なロールバックが行われないようにする必要がありますつまり、可能なかぎり、競合が発生しないようにアプリケーションを設計し、アプリケーションまたは入力データを事前にチェックしてエラーを検出する必要があります。SYS.MONITOR表のXACT_ROLLBACKS列は、ロールバックされたトランザクションの数を示します。
次の項では、データベースのシャットダウン後またはシステム障害の発生後に、データベース・リカバリのパフォーマンスを向上させるためのヒントを示します。
パフォーマンスへの影響: 大
RecoveryThreads属性を索引またはCPUの数に設定し、リカバリ・パフォーマンスを向上させます。
パフォーマンスへの影響: 中
HP-UXのVeritasファイル・システムに対してdiscovered_direct_ioszを設定すると、リカバリ・パフォーマンスが向上します。discovered_direct_ioszより大きい書込みは、ファイル・システム・バッファには書き込まれず、直接ディスクに書き込まれます。discovered_direct_ioszは1MB以上に設定します。詳細は、Veritas社のマニュアルを参照してください。
次の項では、複数CPUのパフォーマンスの向上に関するヒントを示します。
パフォーマンスへの影響: 不定
TimesTenで実行される概算スケーリングを確認する方法の1つとして、使用しているシステムでいずれかのスケーラブル・デモ・アプリケーション（tptbmなど）を実行する方法があります。
tptbmアプリケーションでは、マルチユーザーのスループット・ベンチマークが実装されます。また、TimesTen処理、およびSELECT、UPDATE、INSERTなどを組み合せたトランザクションを実行するプロセスの数を変更するオプションを含め、その実行方法を制御できます。tptbm -helpを実行すると、オプションの完全なリストが表示されます。
デフォルトでは、このデモは、トランザクションごとに1つの処理を実行します。トランザクションごとの処理数を増やして、実際のアプリケーションに近づけることができます。トランザクションが大きくなると、アプリケーションのプロファイルによって、スケーラビリティが向上する場合と低下する場合があります。
このデモのマルチプロセッサ・バージョンを実行すると、複数CPUシステムでのアプリケーションのパフォーマンスを予測して評価できます。デモでのスケーラビリティが高く、アプリケーションでのスケーラビリティが低い場合は、アプリケーションを簡略化して問題の箇所を確認します。TimesTenのコールをコメント・アウトしても、アプリケーションに問題があるためスケーリングが不十分なままになる場合があります。
また、たとえば、シミュレートされたアプリケーション・データの一部が正しく生成されていないため、数行の同じ行がすべての処理でアクセスされていることが発見される場合があります。アクセスでデータが変更される場合、そのタイプのローカライズされたアクセスは、スケーラビリティを大幅に阻害することになります。
tptbmおよびその他のデモ・アプリケーションの詳細は、クイック・スタートのホームページ（install_dir/quickstart.html）を参照してください。「Sample Programs」の下のODBCリンクに移動してください。
パフォーマンスへの影響: 不定
SYS.MONITOR表のLOCK_TIMEOUTSまたはLOCK_GRANTS_WAITフィールドを確認します。これらの値が大きい場合は、過度の競合が発生している可能性を示し、スケーリングが不十分になることがあります。
TimesTenはCPU集中型であるため、CPU当たりのデータベース集中型の接続の数を1つのみにすることで、最適なスケーリングが実現されます。4CPUシステムまたはハイパースレッド機能を持つ2CPUシステムを使用する場合、4プロセッサ・アプリケーションのパフォーマンスは良好ですが、8プロセッサ・アプリケーションのパフォーマンスは低くなります。アクティブなスレッド間での競合が多くなりすぎます。多くのトランザクションが永続コミットされる場合にのみ、この状態を回避できます。この場合は、ディスクへのI/O操作が増加するため、接続がCPU集中型になりません。したがって、マシンでより多くの同時接続をサポートできます。
パフォーマンスへの影響: 不定
読取り処理のスケーラビリティは、書込み処理より優れています。読取りと書込みのバランスが、アプリケーションの実際のワークロードを反映していることを確認してください。
パフォーマンスへの影響: 不定
準備にはスケーラビリティがありません。複数回実行されるコマンドは事前に準備するようにしてください。SYS.MONITOR表のCMD_PREPARESおよびCMD_REPREPARES列に、コマンドが準備された回数、または（索引の作成および削除が原因で）コマンドが自動的に再準備された回数が示されます。いずれかの値が大きい場合は、接続プーリングを実行するようにアプリケーションを変更して、接続の確立および切断がほとんど発生しないようにします。
接続にはスケーラビリティがありません。複数回実行されるコマンドは事前に準備するようにしてください。SYS.MONITOR表のDS_CONNECTS列を参照します。このフィールドの値が大きい場合は、接続プーリングを実行するようにアプリケーションを変更して、接続の確立および切断がほとんど発生しないようにします。
パフォーマンスへの影響: 不定
レプリケーション処理およびXLA処理では、大量のロギングのオーバーヘッドが発生します。レプリケーションのスケーラビリティは、トランスミッタまたはレシーバの数が制限されている場合に最も高くなります。レプリケーションのトポロジを調べ、簡略化できるかどうか確認します。通常、XLAのスケーラビリティは、リーダーの数が制限されている場合に最も高くなります。アプリケーションのリーダー数が多い場合は、その数を削減できるかどうかを確認します。
XLAおよびレプリケーションを監視して、読取りがディスクからではなく、トランザクション・ログ・バッファから行われていることを確認してください。同時実行される更新が多いと、レプリケーションが処理されない場合があります。サブスクライバでは、更新はシングルスレッドです。確認の頻度が減少すると、XLAのスループットを向上できます。
SYS.MONITOR表のLOG_FS_READS列およびLOG_BUFFER_WAITS列の値を確認して、必要なリーダーおよびトランスミッタの数を見積もります。この情報は、接続が確立または解放されるたび、およびトランザクションがコミットまたはロールバックされるたびにシステムによって更新されます。
LogFlushMethod=2を設定すると、RETURN TWOSAFEレプリケーション処理、およびDURABLE TRANSMITが指定されたRETURN RECEIPT処理のパフォーマンスを向上できます。
パフォーマンスへの影響: 不定
マルチプロセッサ・システムでは、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の使用、または更新の明示的な確認が可能になります。各メッセージを個々に確認しないことがアプリケーションで許容される場合は、明示的に更新を確認すると、最も高いパフォーマンスを得ることができます。
