ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング
11gリリース1 (10.3.6)
B61002-04
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストヘ移動
製品
目次へ移動
目次

前
 
次
 

9 データベースのチューニング

この章では、エンタープライズレベルの主なボトルネックにならないようにデータベースをチューニングする方法について説明します。データベースの最適なパフォーマンスを実現するには、この章のチューニング・ガイドラインと、使用しているデータベースの製品マニュアルのチューニング・ガイドラインに従ってください。

一般的な推奨事項

この項では、データベースのチューニングに関する全般的な推奨事項を示します。

データベース固有のチューニング

この項では、Oracle、SQL Server、およびSybaseのチューニングに関する基本的な推奨事項を示します。


注意:

各データベースのベンダーが提供するドキュメントのチューニング・ガイドラインも必ず確認してください。

Oracle

この項では、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データベースのパフォーマンス・チューニング・パラメータに関するガイドラインを示します。これらのパラメータの詳細については、Microsoft SQL Serverのドキュメントを参照してください。

  • 高速I/Oデバイスにはtempdbを格納します。

  • perfmonがI/Oの増加を示す場合はリカバリ間隔を広くします。

  • 2KB以上のI/Oブロック・サイズを使用します。

Sybase

次に、Sybaseデータベースのパフォーマンス・チューニング・パラメータに関するガイドラインを示します。これらのパラメータの詳細については、Sybaseのドキュメントを参照してください。

  • リカバリ間隔を狭めると、チェックポイント処理がより頻繁に発生するためI/O処理が増加します。

  • 2KB以上のI/Oブロック・サイズを使用します。

  • Sybaseは、対称型マルチプロセッサ(SMP)環境内のエンジン数を制御します。この設定は「CPU数マイナス1」に等しくなるように構成することが推奨されます。