システムとデータベースのチューニング

システムとデータベースをチューニングするためのヒントを示します。

• 十分なメモリーの用意

• データベースに使用されるメモリーのページングの回避

• データベースの適切なサイズ設定

• PL/SQLランタイム用の共有メモリー・サイズの計算

• オープン・ファイル数の適切な制限の設定

• ログ・バッファおよびログ・ファイル・サイズのパラメータの構成

• TimesTen Classicデータベースの接続オーバーヘッドの回避

• 複製時のRAMへのデータベースのロード

• 自動リカバリ失敗後のデータベースのリロードの防止

• 競合の軽減

• メンテナンス用の特別なオプションの検討

• 使用するドライバの確認

• トレース機能の有効化(必要な場合のみ)

• メトリックの使用によるパフォーマンスの評価

• 文字セット変換を伴うデータの移行

• TimesTenのネイティブ整数データ型の使用(必要な場合)

• チェックポイント・ファイルとトランザクション・ログ・ファイルを別の物理デバイスに格納するように構成

十分なメモリーの用意

パフォーマンスへの影響: 大

データベース全体がメイン・メモリーに収まるように、システムを構成してください。仮想メモリーを使用すると、パフォーマンスが大幅に低下します。

パフォーマンス監視ツールによって、過度のページングや仮想メモリー・アクティビティが示される場合は、データベース(作業セット)のサイズは適切ではありません。大容量の共有メモリーをプロセスに割り当てるには、物理メモリーの追加やシステム・ソフトウェアの設定が必要な場合もあります。

Linuxシステムの場合、共有メモリー・セグメントの最大サイズが、データベースの共有メモリー・セグメントの合計サイズを格納するのに十分な大きさになるように、Linux共有メモリーを構成する必要があります。

TimesTen Classicでは、データベース全体が単一の共有メモリー・セグメントに保持されます。TimesTen Scaleoutでは、各ホストの共有メモリー・セグメントの設定を行います。shmmax、shmall、memlockおよびHugePagesに、適切なオペレーティング・システムのカーネル・パラメータを設定します。『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』のオペレーティング・システムの前提条件、および『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のLinuxカーネル・パラメータの構成を参照してください。

データベース内の表のサイズ見積りには、TimesTenのttSizeユーティリティを使用できます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttSizeを参照してください。

データベースに使用されるメモリーのページングの回避

パフォーマンスへの影響: 不定

Linuxでは、データベースがメモリーにロードされている間に、データベースによって使用される実際のメモリーをロックするかどうかをMemoryLock接続属性で指定します。

データベースによって使用されるメモリーのページングを回避するには、MemoryLockを4に設定します。MemoryLockを4に設定しないと、データベースで使用される共有メモリー・セグメントの一部がスワップ領域にページアウトされ、データベースのパフォーマンスが低下する可能性があります。『Oracle TimesTen In-Memory Databaseリファレンス』のMemoryLockを参照してください。

データベースの適切なサイズ設定

パフォーマンスへの影響: 不定

データベースの作成時には、そのサイズを指定する必要があります。具体的には、データベースの永続メモリー領域および一時パーティションのサイズを指定します。

データベースと共有メモリーのサイズを指定する方法の詳細は、このマニュアル内の「データベースのメモリー領域サイズの指定」、および『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』のshmmaxとshmallの構成を参照してください。

PL/SQLランタイム用の共有メモリー・サイズの計算

パフォーマンスへの影響: 不定

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のデフォルト値は、LinuxおよびUNIXシステムでは128 MBです。この値は、適度に複雑な数百個のPL/SQLプログラム・ユニットの実行に十分なサイズです。本番のワークロードでしばらく実行した後、PinHitRatioの値を確認します。値が0.90より小さい場合は、PLSQL_MEMORY_SIZEを増やすことを検討してください。

オープン・ファイル数の適切な制限の設定

パフォーマンスへの影響: 不定

TimesTenデータベースへの多数の同時接続を保持するマルチスレッド・アプリケーションでは、オペレーティング・システムが各プロセスに許可しているデフォルトのオープン・ファイル数が少なすぎる場合があります。

『Oracle TimesTen In-Memory Databaseリファレンス』のオープン・ファイルの数の制限を参照してください。

ログ・バッファおよびログ・ファイル・サイズのパラメータの構成

パフォーマンスへの影響: 大

LogBufMBおよびLogFileSizeの値を大きくすると、パフォーマンスが大幅に向上する可能性があります。

LogBufMBは、LogFileSize接続属性に関連しており、最適なパフォーマンスのために、LogBufMBの同じ値または倍数に設定する必要があります。

トランザクション・ログ・バッファ待機は、アプリケーション処理が、トランザクション・データをトランザクション・ログ・バッファに挿入できず、停止してトランザクション・ログ・バッファ領域が解放されるのを待機する必要があるときに発生します。通常この理由は、ログ・フラッシャ・スレッドが十分な速さでデータをクリアしていなかったためです。これは、トランザクション・ログ・バッファ領域が不十分、ファイル・システムの転送速度が不十分、ファイル・システムへの書込みに時間がかかりすぎる、またはログ・フラッシャがCPUの能力に依存していることを示していることが考えられます。

• 小さいLogBufMBは、これらのトランザクションがredoロギング用の領域を確保するためにログ・フラッシュ処理を待機する必要がある場合に、トランザクションの書込みを遅らせる可能性があります。オーバーサイズのログ・バッファは、余分なメモリーを消費すること以外には影響しません。LOG_BUFFER_WAITSの値は、ログ・バッファが一杯であったために、トランザクション・ログ・レコードをログ・バッファに挿入しようとしている間にスレッドが遅延した回数を示します。通常、この値が増大している場合は、ログ・バッファが小さすぎることを示します。

• LogFileSize属性では、各トランザクション・ログ・ファイルの最大サイズをMB単位で指定します。LogFileSizeが小さすぎると、TimesTenはトランザクション・ログのフラッシュ処理で複数のログ・ファイルを作成する必要があります。ファイル作成のオーバーヘッドによって、LOG_BUF_WAITSイベントが発生し、パフォーマンスが大きく影響を受けることがあります。

ワークロードの実行中にLOG_BUFFER_WAITSメトリックが増加したかどうかを確認するには、(SYS.MONITOR表またはttIsql monitorコマンドを使用して)このメトリックの値を調べます。その後、LogBufMBの値を増やして、データベースのパフォーマンスを向上させることができます。

LogBufMBの値を大きくすることで生じるデメリットは、メモリーにバッファされるトランザクションが増え、プロセスがクラッシュしたときに失われるトランザクションが多くなる可能性があることです。DurableCommitsが有効になっている場合は、LogBufMB値を大きくしてもパフォーマンスは改善されません。

LogBufMBおよびLogFileSizeの値を大きくした後もログ・バッファ待機が続いている場合、前述のその他の起こり得る可能性のある問題を確認してください。

LogBufParallelism接続属性は、トランザクション・ログ・バッファ・ストランドの数を指定します。この属性によって、複数の接続が書込みトランザクションを同時に実行する場合のトランザクション・スループットが向上します。これを、システム上のCPUコア数と書込みトランザクションを実行する同時接続数のうちの小さいほうの値に構成します。

『Oracle TimesTen In-Memory Databaseリファレンス』のLogBufMB、LogFileSizeおよびLogBufParallelismを参照してください。

TimesTen Classicデータベースの接続オーバーヘッドの回避

パフォーマンスへの影響: 大

アイドル状態のデータベースは、接続のないデータベースです。デフォルトでは、最初の接続が確立されると、TimesTenによってアイドル状態のデータベースがメモリーにロードされます。最後のアプリケーションのデータベースへの接続が切断されると、ファイル・システムへのデータベースの書込み時に遅延が発生します。

アプリケーションとデータベース間の接続と切断が連続して行われる場合は、メモリーへのデータベースのロードとアンロードも連続して行われる可能性があるため、過度のファイル・システムI/Oおよびパフォーマンスの低下が発生します。同様に、使用するデータベースが非常に大きい場合は、アプリケーションでデータベースが使用される前に、メモリーにデータベースをロードしておくようにしてください。

データベースがメモリーにロードされるまでの待機時間を回避するために、TimesTen ClassicデータベースのRAMポリシーを変更して、データベースが常にメモリーに残るようにできます。この方法のデメリットは、TimesTen Classicデータベースがメモリーからアンロードされないため、最後の接続を切断してもチェックポイントが発生しないことです。そのため、アプリケーションでは、ttCkptConfig組込みプロシージャを使用して、頻繁にチェックポイントを構成する必要があります。『Oracle TimesTen In-Memory Databaseリファレンス』のttCkptConfigを参照してください。

また、一定期間だけTimesTen Classicデータベースをメモリーに常駐させ、新しい接続を受け入れるように指定することもできます。この期間に新しい接続が確立されなかった場合、データベースはメモリーからアンロードされ、チェックポイント処理が実行されます。また、システム管理者がデータベースを手動でメモリーからのロードとアンロードを実行できるようにも設定できます。

TimesTen ClassicデータベースのRAMポリシーを変更するには、ttAdminユーティリティを使用します。RAMポリシーおよびttAdminユーティリティの詳細は、このマニュアル内の「RAMポリシーの指定」、および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminの項を参照してください。

複製時のRAMへのデータベースのロード

パフォーマンスへの影響: 大

ttRepAdmin -duplicateユーティリティを使用してこのデータベースを複製する前に、ttAdmin -ramLoadコマンドを使用してTimesTen Classicデータベースをメモリーにロードします。これにより、データベースは、ブロッキング・チェックポイントでアンロードされるのではなく、接続可能な状態でメモリーに配置されます。

このマニュアル内の「TimesTen Classicデータベースの接続オーバーヘッドの回避」、および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminおよびttRepAdminの項を参照してください。

自動リカバリ失敗後のデータベースのリロードの防止

パフォーマンスへの影響: 大

データベースが無効化された後TimesTen Classicが復旧すると、新しいデータベースがリロードされます。ただし、無効化されたデータベースはそのデータベースへの接続がすべて閉じられるまでアンロードされません。したがって、無効化されたデータベースとリカバリ後のデータベースの両方が同時に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時間が多少長くなります。結果として、データベースに大部分の時間を使う同時実行性の低いアプリケーションのパフォーマンスが向上します。

メンテナンス用の特別なオプションの検討

パフォーマンスへの影響: 中

最初のロードなど、特別な処理を実行する場合は、標準の処理とは異なる別のオプションを選択できます。

特に、バルク・ロードを行う場合はttBulkCpまたはttMigrateなどを使用し、データベース・レベル・ロックを使用することを検討してください。これらの設定により、ロード時のパフォーマンスを2倍にすることも可能です。

データベース・レベル・ロックに代わる方法として、同時実行性を利用する方法があります。-notblLockオプションを使用すると、ttBulkCp -iのコピーを複数実行できます。ttBulkCpの最適なバッチ処理は、-xp 256オプションを追加することで行われます。

『Oracle TimesTen In-Memory Databaseリファレンス』のttBulkCpおよびttMigrateを参照してください。

使用するドライバの確認

パフォーマンスへの影響: 大

TimesTenダイレクト・ドライバ: 直接接続のみを使用し、同じアプリケーション・プロセスから直接接続とクライアント/サーバー接続の両方を使用する必要がない場合は、パフォーマンスを最大化するためにTimesTenダイレクト・ドライバと直接リンクします。

Windows上のTimesTenクライアント・ドライバ: Windows ODBCドライバ・マネージャを使用する場合は、DSNでTimesTenクライアント・ドライバを使用します。Windows ODBCドライバ・マネージャの機能が必要ない場合は、パフォーマンスを向上させるためにTimesTenクライアント・ドライバと直接リンクします。

LinuxおよびUNIXプラットフォーム上のTimesTen Data Managerドライバ: LinuxおよびUNIXプラットフォーム用のTimesTen Data Managerドライバには、デバッグ・バージョンと本番バージョンという2つのバージョンがあります。デバッグを実行しないときは、本番バージョンを使用してください。デバッグ・ライブラリを使用すると、処理がかなり遅くなることがあります。

LinuxおよびUNIXプラットフォーム上のTimesTenドライバ・マネージャ: 同じアプリケーション・プロセスからTimesTenデータベースへの直接接続およびクライアント/サーバー接続を使用する必要がある場合は、(汎用ODBCドライバ・マネージャではなく) TimesTenドライバ・マネージャを使用して、パフォーマンスへの影響を最小限に抑える必要があります。TimesTenドライバ・マネージャを使用しない場合は、オープン・ソースまたは商用ドライバ・マネージャ(unixODBCやiODBCなど)を使用できます。ただし、汎用ドライバ・マネージャは、パフォーマンスが大幅に低下し、機能が制限される可能性があります。

「LinuxおよびUNIXでのTimesTen ClassicのDSNの作成」および「ODBCドライバおよびJDBCドライバを使用したTimesTenへの接続」を参照してください。

トレース機能の有効化(必要な場合のみ)

パフォーマンスへの影響: 大

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接続属性に関するメトリックが含められます。

ttStatsConfig組込みプロシージャをコールして、ttStatusユーティリティに影響を与える統計収集パラメータを変更します。Oracle TimesTen In-Memory DatabaseリファレンスのttStatsConfigを参照してください。

『Oracle TimesTen In-Memory Databaseリファレンス』のttStatsを参照してください。『Oracle TimesTen In-Memory Database PL/SQLパッケージ・リファレンス』のTT_STATSを参照してください。

文字セット変換を伴うデータの移行

パフォーマンスへの影響: 不定

データベースの移行時に文字セット変換がリクエストされた場合は、文字セット変換がリクエストされない場合よりパフォーマンスが低下します。

TimesTenのネイティブ整数データ型の使用(必要な場合)

パフォーマンスへの影響: 不定

領域を節約して計算のパフォーマンスを高めるために、TimesTenのネイティブ整数データ型(NUMBERデータ型ではなく、TT_TINYINT、TT_SMALLINT、TT_INTEGERまたはTT_BIGINT)を指定して表の列タイプを宣言します。

TimesTenでは、内部的にSMALLINT、INTEGER、INT、DECIMAL、NUMERICおよびNUMBERデータ型をNUMBERデータ型にマップします。表の列タイプを定義するときには、列のオーバーフローを回避するために、必ず、適切なネイティブ整数データ型を選択してください。ネイティブ整数データ型とNUMBERデータ型の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の数値データ型を参照してください。

Oracle Databaseの読取りおよび書込みを行うTimesTenキャッシュ・グループを作成するとき、TimesTenのネイティブ整数データ型を使用する場合は、TimesTenキャッシュ・グループおよびOracle Databaseの列のデータ型に互換性があることを確認してください。Oracle Databaseデータ型とTimesTenデータ型の間のマッピングの詳細は、『Oracle TimesTen In-Memory Databaseキャッシュ・ガイド』のOracle Databaseデータ型とTimesTenデータ型の間のマッピングを参照してください。

チェックポイント・ファイルとトランザクション・ログ・ファイルを別の物理デバイスに格納するように構成

パフォーマンスへの影響: 大

TimesTenでは、パフォーマンスを最適にするため、LogDir接続属性を使用して、トランザクション・ログ・ファイルをチェックポイント・ファイルとは別の物理デバイスに格納することをお薦めします。これは、アプリケーションで一貫したレスポンス時間とスループットが必要な場合に重要です。

TimesTenでは、DataStore接続属性で指定された場所にチェックポイント・ファイルを格納します。これは、データベースのフルパス名およびファイル名の接頭辞です。トランザクション・ログ・ファイルとチェックポイント・ファイルが別の物理デバイス上にある場合、チェックポイントのI/O操作とトランザクション・ログに対するI/O操作が相互にブロックすることがなくなります。トランザクションのロギングの詳細は、「トランザクションのロギング」を参照してください。

『Oracle TimesTen In-Memory Databaseリファレンス』のLogDirおよびDataStoreを参照してください。

ノート:

データベースがすでにRAMにロードされており、データベースのトランザクション・ログ・ファイルとチェックポイント・ファイルが同じ物理デバイス上にある場合、TimesTenはデーモン・ログ・ファイルにメッセージを書き込みます。