| Oracle® Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニング 12c (12.2.1.1.0) E77269-02 |
|
 前 |
 次 |
この章には次の項が含まれます:
この項では、データベースのチューニングに関する全般的な推奨事項を示します。
優れたデータベース設計 - データベースの負荷を複数のディスクに分散して、ディスクへの過負荷ができるだけ発生しないようにします。また、表、索引、およびログのサイズや構成を適切に設定することも重要です。
ディスクのI/Oの最適化 - ディスクのI/Oの最適化は、スループットとスケーラビリティに直接影響します。最高速のディスクへのアクセスでも、メモリーへのアクセスに比べると大幅に時間がかかります。ディスクへのアクセス数は、可能なかぎり最適化する必要があります。通常は、I/Oに使用するブロックやバッファのサイズを大きくするとディスクへのアクセス数が減り、負荷の大きい本番環境でのスループットがかなり改善します。
チェックポイント - チェックポイント・メカニズムでは、すべての不要なキャッシュ・データを定期的にディスクにフラッシュ(クリーン・アップ)することで、チェックポイントの期間のI/Oアクティビティおよびシステム・リソースの利用状況を改善します。チェックポイントの間隔を狭めると、ディスク上のデータの一貫性は保持されますが、データベースのパフォーマンスは低下します。チェックポイント・メカニズムはほとんどのデータベース・システムに備わっていますが、ユーザー・レベルの制御が許可されていないデータベース・システムもあります。たとえば、Oracleの場合、管理者はチェックポイントの間隔を設定できますが、ユーザーがSQLServer 7.xチェックポイントを制御することはできません。推奨設定については、使用しているデータベースの製品ドキュメントを参照してください。
ディスクおよびデータベースのオーバーヘッドは、複数の処理をバッチとしてまとめるか、並列で実行される処理の数を増やす(並行性を高める)ことによって、大幅に削減できる場合もあります。次に例を示します。
メッセージング・ブリッジのBatchSize、またはストア・アンド・フォワードのWindowSizeの値を増やすと、パフォーマンスが向上する場合があります。これは、バッチ・サイズを大きくすると、I/Oの数は減ますが、サイズが増えるためです。
プログラム的にJDBCのバッチAPIを利用します。
MDBトランザクション・バッチ機能を使用します。「メッセージドリブンBeanのチューニング」を参照してください
max-beans-in-free-poolおよびMDBのスレッド・プール・サイズを増やす(またはバッチを利用できる場合は減らす)ことによって、並行性を高めます。
この項では、Oracle、SQL Server、およびSybaseのチューニングに関する基本的な推奨事項を示します。
注意:
各データベースのベンダーが提供するドキュメントのチューニング・ガイドラインも必ず確認してください。
この項では、Oracleのパフォーマンスのチューニングについて説明します。
プロセス数 - ほとんどのオペレーティング・システムでは、Oracleサーバーへの接続ごとにシャドウ・プロセスを生成して接続をサービスします。したがって、Oracleで使用できるプロセスの最大数は、同時に処理できるユーザーの数と、Oracleサーバーが使用するバックグラウンド・プロセスの数をカバーできる値に設定しなければなりません。通常、デフォルトの最大数では、並行処理するオペレーションの数が多いシステムには対応できません。プラットフォーム固有の問題については、Oracleの管理者ガイドを参照してください。このパラメータの現在の設定値は、次の問合せを使用して取得できます。
SELECT name, value FROM v$parameter WHERE name = 'processes';
バッファ・プール・サイズ - バッファ・プールは、OracleサーバーのSGA (system global area)の最も大きな部分です。これは、Oracleサーバーがディスクから読み込んだデータをキャッシュする場所です。read-mostlyアプリケーションの場合、データベースのパフォーマンスに影響する最も重要な統計は、バッファ・キャッシュ・ヒット率です。バッファ・プールのサイズは、キャッシュ・ヒット率が95%以上になる程度に大きくする必要があります。バッファ・プールのサイズは、init.oraファイルのdb_cache_sizeパラメータの値(データベース・ブロック数)を変更して設定します。
共有プール・サイズ - 共有プールは、OracleサーバーのSGA (system global area)の重要な部分です。SGAは、Oracleデータベース・インスタンスのデータおよび制御情報を格納する共有メモリーのグループです。複数のユーザーが同時に同じインスタンスに接続した場合、これらのユーザーはそのインスタンスのSGAのデータを共有します。SGAの共有プール部分には、2つの主な領域(ライブラリ・キャッシュとディクショナリ・キャッシュ)のデータがキャッシュされます。ライブラリ・キャッシュには、SQL関連の情報と制御構造(解析済のSQL文、ロックなど)が格納されます。ディクショナリ・キャッシュには、SQLの処理に必要なメタデータが格納されます。
ほとんどのアプリケーションでは、共有プール・サイズがOracleのパフォーマンスに対して重要です。共有プールが小さすぎると、限られた大きさの空間を管理するためだけにサーバーのリソースが消費されてしまいます。これによりCPUリソースが消費され、複数のキャッシュの並列管理に制限のあるOracleでは競合が発生する原因となります。トリガーやストアド・プロシージャを数多く使用すると、より大きな共有プールが必要となります。SHARED_POOL_SIZE初期化パラメータを使用して、共有プールのサイズをバイト単位で指定できます。
次の問合せを使用すると、共有プール内の空きメモリー量をモニターできます。
SELECT * FROM v$sgastat WHERE name = 'free memory' AND pool = 'shared pool';
最大オープン・カーソル数 - Oracleサーバーのすべてのリソースが1つの接続によって消費されないようにするには、OPEN_CURSORS初期化パラメータを使用して接続ごとのオープン・カーソルの最大数を制限します。残念ながら、このパラメータのデフォルト値はWebLogic Serverのようなシステムには小さすぎます。カーソル情報は、次の問合せを使用してモニターできます。
SELECT name, value FROM v$sysstat WHERE name LIKE 'opened cursor%';
データベース・ブロック・サイズ - ブロックは、Oracleにおけるデータ格納の基本単位で、I/Oの最小単位でもあります。1つのデータ・ブロックは、ディスク上の物理データベースの特定のバイト数に相当します。このブロックという概念はOracle RDBMSに固有のものですので、基底のオペレーティング・システムのブロック・サイズと混同しないようにしてください。ブロック・サイズは物理的なストレージに影響するため、この値を設定できるのはデータベースの作成時に限られ、データベース作成後は変更できません。このパラメータの現在の設定値は、次の問合せを使用して取得できます。
SELECT name, value FROM v$parameter WHERE name = 'db_block_size';
ソート領域のサイズ - ソート領域を大きくすると、問合せの処理中にメモリー内でソートを実行できるため、大規模なソートのパフォーマンスが向上します。ソート領域は接続ごとに1つしか確保できないため、このサイズの設定は重要になります。通常、このinit.oraパラメータのデフォルト値は6 - 8データ・ブロックです。この値は通常のOLTP処理には十分ですが、意思決定支援処理、大規模なバルク処理、大規模な索引関連の処理などを行う場合は、より大きな値を設定しておく必要があります。この種の処理を実行する場合は、init.oraパラメータを次のようにチューニングします(デフォルトの設定値は8Kデータ・ブロック)。
sort_area_size = 65536 sort_area_retained_size = 65536
次に、Microsoft SQL Serverデータベースのパフォーマンス・チューニング・パラメータに関するガイドラインを示します。これらのパラメータの詳細については、Microsoft SQL Serverのドキュメントを参照してください。
高速I/Oデバイスにはtempdbを格納します。
perfmonがI/Oの増加を示す場合はリカバリ間隔を広くします。
2KB以上のI/Oブロック・サイズを使用します。
