DB2 UDB EEE :チューニングのためのクイック・リファレンス

DB2 UDB EEE :チューニングのためのクイック・リファレンス

Surendra Parlapalli, Developer, IBM

Surendra ParlapalliSurendra Parlapalliは、コンピューター・サイエンスの修士号を取得し、IT業界で8年以上の経験を積んできました。IBM認定のDB2 DBA、アプリケーション開発者、Microsoft認定のWindows NT向けソリューション開発者です。メールアドレスはsparlapalli@us.ibm.comです。



2002年 5月 23日

概要

この記事では、DB2 ユニバーサル・データベース エンタープライズ拡張エディション(EEE)のパフォーマンス・チューニングのテクニックを紹介し、DB2 EEEの基礎、DB2メモリー使用、チューニングのガイドラインなどについて説明します。DB2スナップショット・データの収集、分析を皆さんができるように、また、データベースのパフォーマンスを高める上でのヒントとして、Perlスクリプトを掲載しています。主に、Windows プラットフォームを中心とした例をこの記事では紹介しています。


DB2 EEEとは?

DB2製品ファミリーのエンタープライズ拡張エディション(EEE)は、大量の並列処理を行うコンピューターのクラスター全体のデータ区分化をサポートします。パーティションによって区分されたデータベースは、大量のデータを保持することが可能であるため、新たなアプリケーションのチャンスも拡大します。単一のシステムを複数のパーティションで区切り(論理ノード)、DB2 EEEをインストールすることも、また物理ノードとして複数のシステムに分散させることも可能です。各ノードのデータベース・マネージャーによって、データベースの各部の管理が行われます。このDB2 EEEのアーキテクチャーによって、意思決定支援システムおよびオンライン・トランザクション処理システムのパフォーマンスの向上が可能となります。

シェアード・ナッシングアーキテクチャー

図1.  シェアード・ナッシングアーキテクチャーのDB2 EEEパーティション
図1.  シェアード・ナッシングアーキテクチャーのDB2 EEEパーティション

所有データ、索引、構成ファイル、トランザクション・ログによって構成されるデータベースの部分を「データベース・パーティション」と呼びます。

データベース・パーティションは、DB2 EEEのシェアード・ナッシングアーキテクチャーによって、1つまたは複数のプロセッサーに割り振ることができます。データベース・パーティションはデータの共有を行いませんが、メッセージを介して通信を行います。

並列性

DB2 EEEは、「パーティション間」と「パーティション内」という2つのタイプの並列性をサポートします。

パーティション間並列では、照会に対して最初にDB2がデータのあるパーティションを識別します。次に、照会が発せられているノード(コーディネーター・ノード)が他のパーティション・ノードと連係してすべての適格な行を見つけ出します。各ノードが機能するのは、データの一部に対してのみです。

パーティション内並列では、照会は、スキャン、結合、ソートなどの一連のオペレーションに分割されますが、これらのオペレーターの作業は、すべて異なるプロセスを使用して同時に行われます。

パーティションごとのDB2 EEEプロセス/スレッド・モデル

Windows上のDB2 EEEインスタンスは、db2startコマンドが発行されると、サービスとして開始され、このインスタンスの開始により、ノードのあらゆるパーティションのdb2syscs.exeが開始されます。これらのプロセスは、IPCまたはTCP/IPを使用し、メッセージを介して通信を行います。また、各アプリケーションには、アプリケーションに代わって動作するエージェントが割り当てられます。

データベースをアクティブにすると、アクティビティーを記録するロガー、およびデッドロックを検出するデッドロック・ディテクターが起動されます。DB2のライセンス・マネージャーは別のプロセスとして起動し、ライセンスの使用を監視します。


DB2によるメモリーの使用方法

DB2メモリーは、さまざまな段階で割り振りが行われます。図2は、DB2 EEEのメモリーの割り振りを示しています。

グローバル制御ブロック

データベース・マネージャーの実行に必要なメモリー・スペース。このメモリーは、データベース・マネージャーの起動に伴って割り振りが行われます。Fast Communication Manager(FCM)は、DB2 EEEに通信サポートを提供し、FCMバッファーは、このメモリー領域から割り振りが行われます。

データベース・グローバル・メモリー

データベースの実行に必要なメモリー。このメモリーは、データベースがアクティブな状態になると割り振りが行われます。メモリー・セグメントの数は、numdb(データベースの数)構成パラメーターによって制限され、データベース・グローバル・メモリーの合計サイズは、表1に示すデータベース構成パラメーターによって決まります。

表1. データベース・グローバル・メモリーのサイズに影響するデータベース構成パラメーター
パラメーター説明
buffpageサイズが-1に設定されているバッファー・プールに影響を与える
pckcacheszパッケージのキャッシュ・サイズ
util_heap_szユーティリティー・ヒープ・サイズ
dbheapデータベース・ヒープ
locklistロックの最大記憶域

アプリケーション・グローバル・メモリー

アプリケーション・グローバル・メモリーは、アプリケーションの実行に必要なメモリーです。このメモリーは、アプリケーションから要求を受け取る最初のエージェントの接続要求に伴い、割り振りが行われます。このメモリーは、データベース構成パラメーターapp_ctl_heap_szによって制御され、同じアプリケーションに対して動作しているすべてのエージェント間で共有されます。

エージェント・プライベート・メモリー

各エージェントには、所有プライベート・メモリーがあります。構成パラメーター「maxappls」と「maxagents」の小さいほうの値によって、メモリー・セグメントの数が制限されます。

表2. 「maxappls」「maxagents」の小さいほうの値によって、 メモリー・セグメントの数が制限される
パラメーター説明
maxapplsすべてのアクティブなデータベースに対するアプリケーションの最大合計数
maxagentsエージェントの最大数

最大サイズは、表3に示す各種構成パラメーターによって決まります。

表3. 最大プライベート・メモリーに影響を与える構成パラメーター
パラメーター 説明
agent_stack_sz エージェントのスタック・サイズ
udf_mem_sz UDF共有メモリ・セットのサイズ
applheapsz アプリケーション・ヒープ・サイズ
sortheap ソート・ヒープ・サイズ
stmtheap ステートメント・ヒープ・サイズ
stat_heap_sz 統計ヒープ・サイズ
query_heap_sz 照会ヒープ・サイズ
drda_heap_sz DRDAヒープ・サイズ

エージェント/アプリケーション共有メモリー

このメモリーは、同じアプリケーションに対して動作しているエージェント間で共有されます。

エージェント共有メモリーは、表4に示すデータベースおよびデータベース・マネージャー構成パラメーターの影響を受けます。

表4. エージェント共有メモリーに影響を与える構成パラメーター
パラメーター 説明
aslheapsz アプリケーション・サポート層ヒープ・サイズ
rqrioblk クライアントI/Oブロック・サイズ

エージェント・プライベート・メモリーは、表5に示すデータベース構成パラメーターの影響を受けます。

表5. アプリケーション共有メモリーに影響を与える構成パラメーター
パラメーター 説明
applheapsz アプリケーション・ヒープ・サイズ
agent_stack_sz エージェント・スタック・サイズ
stat_heap_sz 統計ヒープ・サイズ
udf_mem_sz UDFメモリー
sortheap ソート・ヒープ・サイズ
rqrioblk 照会ヒープ・サイズ
query_heap_sz クライアントI/Oブロック
drda_heap_sz DRDAヒープ・サイズ

図2は、DB2がどのようにメモリーを使用するかを示しています。詳細については「Making DB2 Use All the Memory」を参照してください。

図2. DB2のメモリー使用
DB2のメモリー使用

データベースの作成

DB2 EEEでは、DB2コマンド行プロセッサー(CLP)プロンプトから簡単なコマンドを発行することによって、データベースが作成されます。次の例では、mydbというデータベースを作成します。

 
CREATE DATABASE mydb

上記のステートメントが実行されると、データベースmydbがインスタンス・ディレクトリーに表示されます。

表スペース

表スペースは、データベースと実際にデータを保持しているコンテナー・オブジェクトの間の論理層です。DB2 EEEは、システム管理スペース(SMS)とデータベース管理スペース(DMS)という2つのタイプの表スペースをサポートします。SMSでは、オペレーティング・システムのファイル・マネージャーによって、記憶域を割り振りおよび管理が行われます。SMSで使用されるコンテナーは、ディレクトリであることが必要です。また、DMSでは、データベース・マネージャーによって記憶域の制御が行われ、DMSで使用されるコンテナーは事前割振りのファイル、またはハード・ディスク・ドライブなどの物理ドライブであることが必要です。DBAでは、カタログ表スペース、一時表スペース、ユーザー表スペースに必要な表スペースのタイプを選択することができます。

データベースの作成にデフォルトを使用すると、以下のシステム管理表スペースが作成されます。

  • System
    − システム表にカタログ情報を保管します。カタログには、データベース・オブジェクト(表、ビュー、索引、パッケージなど)の定義に関する情報と、これらのオブジェクトに対するユーザーのアクセス・タイプに関する情報が含まれます。
  • Temporary
    − データベース処理中に作成されるシステム一時表を保管します。
  • User
    − ユーザーによって作成された表や索引などのデータベース・オブジェクトを保管します。

以下の例は、データベース管理者がDMS表スペースとSMS表スペースを使ってデータベースを作成する方法を示しています。ここでは、システム管理カタログ表スペース、データベース管理一時表スペース、ユーザー表スペースによってtestedという名前のデータベースを作成します。

 
CREATE DATABASE tested
CATALOG TABLESPACE
PAGESIZE 4096
MANAGED BY DATABASE USING
(FILE 'C:\DATA\CAT1.DAT' 3000,
FILE 'D:\DATA\CAT1.DAT' 3000)
EXTENTSIZE 12
PREFETCHSIZE 16
TEMPORARY TABLESPACE
MANAGED BY SYSTEM USING
('C:\DATA\TEMP1' , 'D:\DATA\TEMP2')
USER TABLESPACE
MANAGED BY DATABASE USING
('\\.\PhysicalDrive1' 4096,
'\\.\PhysicalDrive2' 4096)
  • PAGES:
     表データの行がページと呼ばれるブロックに構成されます。DB2は4 KB、8 KB、16 KB、32 KBのページ・サイズをサポートします。使用するアプリケーションのタイプにしたがい、さまざまな表スペースに対してさまざまなページ・サイズを選択することができます。デフォルトのDB2では、4 KBのページを使用します。
  • PAGESIZE:
     4 KBのページ・サイズがカタログ表スペースに指定されています。
  • EXTENT:
     エクステントと呼ばれる割り振り単位にグループ化されたページのセット。上記の例では、EXTENTSIZEが12 4 KBのページをエクステントにグループ化するよう定義しています。
  • PREFETCH:
     データ検索の間の待ち時間を解消するために、DB2が事前にデータを読み取れるようにする方式です。
  • PREFETCHSIZE:
     プリフェッチ可能なページ数を定義します。

コマンドLIST TABLESPACES SHOW DETAILSによって、上記の情報、ならびに合計ページ、使用可能ページ、使用済みページ、空きページなどの情報を表示することができます。

LIST TABLESPACESコマンドによって表スペースIDを見つけた後、コマンドLIST TABLESPACE CONTAINERS FOR 2 SHOW DETAILを発行することによってコンテナーに関するより詳しい情報を表示することができます。「2」は、表スペースのIDです。このコマンドによって、指定されている表スペースのコンテナーが一覧表示されます。すべてのコンテナーについて、ID、名前、タイプ、合計ページ、使用可能ページ、コンテナーが現在アクセス可能かどうかが表示されます。

DB2では、索引、データを個別の表スペースに置くこともできます。コンテナーごとに別々のハード・ディスク・ドライブを使用することにより、I/Oの競合を軽減することができます。次の例では、表employeeを作成します。通常のデータは表スペースTBS1に置かれ、索引データはTBS2に置かれます。

 
CREATE TABLE employee(
E_NO INT NOT NULL,
E_NAME CHAR(20) NOT NULL )
IN TBS1 INDEX IN TBS2

バッファー・プールの作成

DB2では、バッファー・プールを使用して、ハード・ディスク・ドライブに対して表データと索引データの読み取りまたは書き込みが行われる際に、表データおよび索引データがキャッシュに置かれます。表スペースが作成されると、その表スペースはデフォルトのバッファー・プールIBMDEFAULTBPに割り当てられます。DBAは、表スペースの作成および変更時に、バッファー・プールを表スペースにマッピングすることができます。あらゆるページ・サイズの表スペースに対して、それに一致するページ・サイズのバッファー・プールがあるはずです。

 
CREATE BUFFERPOOL bp1
SIZE 4000
PAGESIZE 4096

上記のSQLステートメントによって、4000 4KBのページ(4000*4K = 16000K)のバッファー・プールbp1が作成されます。

既存の表スペースはここで、バッファー・プールbp1にマッピングするように変更できます。次の例では、emp表スペースをバッファー・プールbp1にマッピングします。

 
ALTER TABLESPACE emp BUFFERPOOL bp1

バッファー・プールは、データベース・サーバー上のいくつかの共有メモリー・セグメントとして割り振られます。データベース・レコードは、メモリーのバッファー・プール領域で読み取られて更新されます。すべてのバッファー・プールは、データベースがアクティブになると割り振りが行われます。アプリケーションが特定の表または索引をデータベースに要求すると、ハード・ディスクからそのデータを含むページが関連付けられたバッファー・プールに転送されます。ページは、以下のいずれかが発生するまでハード・ディスクに書き戻しされません。

  • すべてのアプリケーションがデータベースから切断される
  • バッファー・プールに対して新しいページの読み取りが必要である
  • ページ・クリーナーが利用可能であり、データベース・マネージャーによってアクティブに設定されている

バッファー・プールは、ハード・ディスク・ドライブのアクティビティーを軽減できるよう、必要なデータをメモリーに保持するための十分な大きさが必要です。より大きなバッファー・プールを利用するには、アクセス戦略の決定にあたって最適化プログラムのアプリケーションを再バインドして、バッファー・プール・サイズを検討する必要があります。


データベース・インスタンスの構成

DB2 EEEインスタンスまたはインスタンス・マネージャーは、カタログ・ノード上にあります。この情報が保管されている共有ディレクトリは、インスタンス所有マシン(ノード0)が所有しており、インスタンスに追加されている他のデータベース区分サーバーは、インスタンスに「参加している」状態となります。

  • 物理ノード
    1つのマシンにインスタンス所有データベース区分サーバーをインストールし、区分データベース・システムに参加している他のマシンの各々にデータベース区分サーバーをインストールすることにより、物理ノードを構成することができます。
  • 論理ノード
    同一マシン上に複数のデータベース区分サーバーを置いた状態は、複数論理ノード(Multiple Logical Nodes - MLN)構成と呼ばれます。MLNは、SMPアーキテクチャーを利用しています。MLN構成の作成は、コマンドdb2ncrtを使用し、インスタンスにデータベース区分サーバー・ノード(論理ノード)を追加して行います。次の例では、新しいデータベース区分サーバーをインスタンス所有マシンnode1のインスタンスBENCHに追加します。このコマンドにより、論理ポート1を使用してこの新しいノードがnode1に設定されます。
     
    db2ncrt /n:1 /u:BENCH\db2inst1,bmdb2 /I:BENCH /m:node1 /p:1 /h:node1
  • ノードグループ
    1つまたは複数のデータベース・パーティションの名前付きサブセットは、ノードグループと呼ばれます。複数のパーティションで構成されるサブセットは、マルチパーティション・ノードグループと呼ばれます。マルチパーティション・ノードグループは、同じデータベースに属するデータベース・パーティション内にのみ存在します。
    次の例では、すべてのデータベース・パーティションにノードグループallnodesが作成されます。
     
    CREATE NODEGROUP allnodes ON ALL NODES

    次の例では、ノード0〜3、およびノード5のみにノードグループsnodesが作成されます。
     
    CREATE NODEGROUP snodes ON NODE (0 TO 3, 5)

    ノードグループの作成後、それらのノードグループをノードグループ表スペースに関連付け、データが区分されるノードを指定することが必要です。
     
    CREATE TABLESPACE org
    IN NODEGROUP s_nodes
    MANAGED BY DATABASE
    USING (DEVICE '\\.\PhysicalDrive1' 2000)   ON NODE(0)
    USING (DEVICE '\\.\PhysicalDrive1' 2000)   ON NODE(1)
    USING (DEVICE '\\.\PhysicalDrive1' 2000)   ON NODE(5)

    図3は、パーティションにおけるデータベース・オブジェクト間の関係を表しています。
    図3. DB2におけるデータベース・パーティションのオブジェクト関係図
    図3. DB2におけるデータベース・パーティションのオブジェクト関係図

チューニングのガイドライン

DB2は、データベース・パフォーマンスの問題を監視し、分析するためのツールを備えています。

  • Explainツール
    Explainツールは、パフォーマンスの問題を特定するためのきわめて便利なツールであり、「追加の索引が必要か」、「照会を作成しなおすべきか」、「ロッキング戦略が適切であるか」といった判断に役立ちます。「Explainスナップショット情報」の取り込みは、以下の方法で行うことができます。
  • EXPLAIN SNAPSHOT特殊レジスターを使用可能にする特殊レジスターCURRENT EXPLAIN SNAPSHOTをYESに設定して、動的SQLステートメントのスナップショットを取り込みます。以下のステートメントは、アプリケーション・プログラムに組み込むことも、あるいは、インタラクティブに発行することもできます。特殊レジスターを設定することにより、その後の適格な動的SQLステートメントに対してExplainスナップショットが取得されます。
     
    SET CURRENT EXPLAIN SNAPSHOT YES
  • SQLプロシージャーでExplainスナップショットを収集する
    アクセス・プランを収集するために、ストアード・プロシージャーはEXPLSNAPレジスターをALLまたはYESに設定することが必要です。
     
    db2 PREP  EXPLSNAP {YES / ALL / NO }
                            YES = static SQL
                            ALL = static and dynamic
                            NO = No snapshot

    パッケージをEXPLSNAP YESまたはALLに設定した場合、全パッケージのプランを取得することができます。

    db2explnツールは、システム・カタログ表に保管されているパッケージの静的SQLステートメントに選択されているアクセス・プランを記述し、dynexplnツールは、動的SQLステートメントのアクセス・プランを記述します。

    次の例は、uses db2explnを使用して、ユーザーmyuserによって出力ファイルoutput.fileに作成された、データベースmydbのnewordという名前のパッケージのアクセス・プランを検索します。
     
    db2expln -d mydb -p neword -c myuser -o output.file
  • パフォーマンスに影響を与えるユーティリティー
    DB2は、RUNSTATS、REORG、REORGCHKなど、データベースのパフォーマンスを高めるための各種ユーティリティーを提供しています。

    RUNSTATSは、システム・カタログ内の統計の更新を行うユーティリティーであり、照会最適化プロセスをサポートします。データベース・マネージャーは、このような統計情報をデータベースとして、SQLステートメントのパフォーマンスを向上させるための決定を行うことができます。このユーティリティーは、データに大幅な変更の後、また、REORGを実行した後に使用します。

    REORGによって、表と索引の断片化を解消し、索引の順序に従って表の行を任意に配列することができます。REORGが必要であることが、ユーティリティーREORGCHKによって示され時間の経過に伴ってパフォーマンスが減衰した場合、つまりデータの挿入、更新、削除によってクラスタリングやスペース使用効率の低下が生じるようになった場合に、REORGを使用します。
    REORGCHKは、システム表内のデータをチェックし、表と索引の再構成が必要であるかどうかを判断します。REORGCHKによって、統計をチェックする前にRUNSTATSを起動することもできます。REORGCHKは、定期的にあるいはユーザーがパフォーマンスの減衰に気づいた際に実行します。

  • RUNSTATSの以下の例では、索引に基づき、可能な統計がすべて収集されます。
     
    RUNSTATS ON TABLE bench.neword WITH DISTRIBUTION AND DETAILED INDEXES ALL

    REORGの以下の例では、中間結果を保管する作業領域としてシステム一時表スペースTEMPSAPCE1を使用し、顧客表を再構成します。
     
    REORG TABLE bench.customer USING TEMPSPACE1

    REORGCHKの以下の例では、REORGの必要性をチェックし、さらに表bench.customerの統計を更新します。
     
    REORGCHK UPDATE STATISTICS ON TABLE bench.customer
  • I/Oの最小化
    索引、キャシング、ログ・オーバーヘッドの低減、サマリー表、フェッチの低減により、I/Oを軽減します。
  • 索引の使用
    適切な索引を作成することは、照会のパフォーマンス向上につながります。「DB2索引アドバイザー」は、表の索引の設計をサポートし、以下のような場合に有用です。
    • 問題の照会に最も適した索引を知る
    • 効果的なリソースの制限を用いた照会に対して、最も適した索引を知る
    • 索引を作成せずに、ワークロードに対して索引を使用してみる
    索引を作成することによって、不必要な表のスキャンおよびソートを行わずに済み、頻繁に実行される照会をスピードアップして、一意性を確保することができます。

    索引を作成した後、DB2が索引を使用していることをExplainツールによって確認します。
  • カタログ・キャッシュ、パッケージ・キャッシュ、ログ・バッファー
    カタログ・キャッシュ、パッケージ・キャッシュ、ログ・バッファーを適切なサイズに設定することによって、パフォーマンスを向上させることができます。カタログ・キャッシュは、前のステートメントで、表、ビュー、エイリアスの参照が行われた場合に使用される表記述子情報の保管に使用されます。パッケージ・キャッシュは、パッケージの静的/動的SQLステートメントのキャッシングのためのデータベース・グローバル・メモリーの量を設定します。ログ・バッファーは、ハード・ディスク・ドライブに書き込まれるまでログ・レコードを記憶域に保持します。ログ・レコードは、次のいずれかの発生に伴い、ハード・ディスク・ドライブに対して書き込みが行われます。
    • ログ・バッファーの空き容量なし
    • トランザクションまたはトランザクション・グループによるコミット
    平均的なトランザクションでログ・バッファーが使用するログ・スペースを確保しておくことが重要です。そうでなければ、ログ・バッファーの空き容量がなくなることによって、多量のログの書き込みが行われ、ロギング・パフォーマンスの減衰を招くことになります。

    以下のコマンドは、これらのキャッシング・パラメータの変更に使用します。
     
    db2 update db cfg for mydb using logbufsz 4096
    db2 update db cfg for mydb using catalogcache_sz 1024
    db2 update db cfg for mydb using pckacchesz 4096
  • I/Oの並列性の向上
    I/Oの並列性を高めるためのガイドラインは、次のとおりです。
    • データを複数のハード・ディスク・ドライブに分散させてI/Oの待ち時間を減らす
    • データと索引を別々の表スペースに分割してI/Oの競合を軽減し、OLTPおよびOLAPアプリケーションのパフォーマンスを向上させる
    一般にOLTPアプリケーションでは、DMS表スペースは複数のデバイスで使用します。一時表スペースおよびカタログ表スペースは、SMSに置くことが必要です。
  • ログ・ファイルの配置
    OLTPアプリケーションでは、頻度の高いアクティビティーが同じハード・ディスク・ドライブ上の他の作業にマイナスの影響を与えることのないように、別の物理デバイス上にログ・ファイルを置くことが極めて重要です。
  • DB2並列I/O
    表スペース・コンテナーとの間でデータの読み取り/書き込みを行う場合、データベース内のコンテナーの数が2以上であれば、DB2で並列I/Oを使用することもできます。ただし、単一のコンテナー表スペースに対して並列I/Oを使用可能にしておくことが効果的な場合もあります。ストライプRAIDデバイスでは特にそのような場合があります。
  • パーティション内並列を使用可能にする
    最適化プログラムによるパーティション内並列の選択をするには、intra_parallelデータベース・マネージャー構成パラメーターを次のように設定することが必要です。
     
    db2 update dbm cfg using intra_parallel YES

    intra_prallelのほかにも、dft_degreeデータベース・パラメーターを設定して、並列の度合いを指定することも必要です。この値は、2以上、データベース・パーティションが使用できるプロセッサー数以下で設定します。

    dft_degreeデータベース構成パラメーターは、データベースごとの並列性のデフォルト・レベルを指定します。値「1」は、パーティション内並列が行われないことを示し、値「-1」は、最適化プログラムがプロセッサーの数と照会のタイプに基づいて並列の度合いを決定することを示します。

    データベースがノード全体にわたって区分されると、パーティション間の並列性は自動的に使用可能となります。
  • サマリー表
    サマリー表は、照会の結果に基づき定義されます。したがって、サマリー表には通常、その表あるいはその基となる表(単数/複数)のデータに基づく予測結果が含まれています。基となる表よりもサマリー表の方が動的照会が効率的に行われるとSQLコンパイラーが判断した場合、照会はサマリー表に対して実行され、他の方法よりも速く結果を得ることができます。
  • データの区分方法
    パーティションによって区分されたキーは、特定のデータの行が保管されるパーティションを決めるために使用される、列または列のグループです。表のパーティション・キーは、CREATE TABLEステートメントで定義します。ノードグループの複数のデータベース・パーティションにわたって分割されている表スペース内の表に対して、パーティション・キーが指定されない場合、DB2は、デフォルト設定によってプライマリー・キーの最初の列からパーティション・キーを作成します。プライマリー・キーが指定されていない場合、デフォルトのパーティション・キーは、表で定義されている最初の非ロング・フィールド列となります。
     
    CREATE TABLE customer(
    C_ID INTEGER NOT NULL,
    C_FIRST VARCHAR(20) NOT NULL,
    C_MIDDLE VARCHAR(20) NOT NULL)
    IN CUSTOMER
    INDEX IN CUSTOMER_IDX
    PARTITIONING KEY(C_ID) USING HASHING;
  • データベース・スナップショット・モニターによるチューニング
    データベース・モニターは、データベースおよびデータベースにアクセスしているアプリケーションに関する大量の情報をDBAに提供します。以下のようなモニター・スイッチがあります。
    • SORT − 使用されるヒープ、オーバーフロー、行われるソートの量
    • LOCK − 保持されるロック、デッドロック、ロック待機エスカレーションの数
    • TABLE − アクティビティーの単位(読み取られた行、書き込まれた行)
    • BUFFERPOOL − 物理読み取り、論理読み取り、タイミング情報
    • STATEMENT − コミット、ロールバック、選択、障害の数
    これらのスイッチを以下のコマンドと共に使用することにより、スナップショット・モニターを操作することができます。
     
    GET MONITOR SWITCHES
    UPDATE MONITOR SWITCHES USING <switch-name> ON/ OFF
    RESET MONITOR ALL/ FOR DATABASE <dbname>
  • バッファー・プールのチューニング
    バッファー・ヒット率は、ページ要求に応じるためにデータベース・マネージャーがハード・ディスク・ドライブからページをロードする必要がなかった、つまりページがすでにバッファー・プールにあった回数の割合を示しています。バッファー・プール・ヒット率が大きければ、その分、ハード・ディスク・ドライブI/Oの頻度は低くなります。以下は、バッファー・プール・スナップショット情報からバッファー・プール・ヒット率を計算する式です。
     
    (1- ((pool_data_p_reads + pool_index_p_reads) /
    (pool_data_l_reads + pool_index_l_reads))) * 100

    ヒット率が低い場合には、バッファー・プール・ページの数を増やすことにより、パフォーマンスを高めることができます。
  • ソート・ヒープのチューニング
    スナップショット・データからのソートの平均時間は、total_sort_time / total_sortsとして測定されます。ソート・パフォーマンスが向上すると、この平均値は減少します。ソート・ヒープを増やしてマージ・フェーズをなくすと、ソート時間が改善されます。
  • ソート・ヒープしきい値(sortheapthres)のチューニング
    パイプ・ソートに対するアプリケーション要求が拒否されないのであれば、常に、すべてのアプリケーションによって要求される合計ソート・ヒープに対応するのに十分な高いしきい値を維持します。データベース・マネージャーによって受け入れられたパイプ・ソート要求の割合は、以下の式を使用して計算することができます。
     
    100%*piped_sorts_accepted/piped_sorts_requested

    割合が小さい場合、sortheapthresパラメーターを大きくすることによってパフォーマンスが向上します。
  • パッケージ・キャッシュ(pckcachesz)のチューニング
    パッケージ・キャッシュ・ヒット率は、以下の式によって計算します。
     
    (1 - (Package cache inserts / package cache lookups)) * 100

    ヒット率が小さい場合は、pckcacheszパラメーターを大きくする必要があります。
  • カタログ・キャッシュのチューニング
    カタログ・キャッシュ・ヒット率は、以下の式によって計算します。
     
    (1 - (Catalog cache inserts / catalog cache lookups)) * 100

    ヒット率が小さい場合は、catalogcache_szを大きくする必要があります。
  • 並行アプリケーションの最大数(maxappls)のチューニング
    データベース構成パラメーターmaxapplsは、データベースに接続できる並行アプリケーションの最大数を指定します。maxlocksパラメーターを小さくせずに、あるいは、locklistパラメーターを大きくせずにこのパラメーターの値を増加させると、アプリケーションの限界ではなくデータベースのロックの限界(locklist)に達し、その結果、広範囲なロックの拡大が発生する恐れがあります。アプリケーションに対して十分なエージェントが使用できる(maxagents)ことを確認する必要があります。
  • データベース・マネージャー・エージェントの最大数(maxagents)のチューニング
    maxagentsは、アプリケーション要求の受け入れに常に使用できるデータベース・マネージャー・エージェントの最大数を示します。maxagentsパラメーターの値は、並行してアクセスできる各データベースのmaxapplsの値を合計したものであることが必要です。
  • Fast Communications Manager(FCM)
    DB2は、同じ要求に対して機能するエージェント間での通信にFCMを使用することができます。FCMの構成可能パラメーターは、fcm_num_anchors、fcm_num_buffers、fcm_num_connect、fcm_num_rqbです。パーティション数の増加にしたがい、接続エントリー(fcm_num_connect)とBQS RQB(fcm_num_rqb)の数が増加し、要求ブロックの数が増加すると、FCMバッファーの数(fcm_num_buffers)が増えます。また、サブセクションの数(照会の複雑さ)が増加すると、BDS RQB(fcm_num_rqb)とメッセージ・アンカーの数(fcm_num_anchors)も増加します。
    MLN環境では、DB2_FORCE_FCM_BPをYESに設定します。これによりDB2は、FCMバッファーを個々のメモリー・セグメントに作成できるようになります。FCMバッファーが個々のメモリー・セグメントに作成されると、同じ物理ノード上のさまざまな論理パーティションのFCMデーモン間の通信が共有メモリーを通じて発生します。
  • Windowsのファイル・システム・キャッシングを使用不可にする
    ファイル・システム・キャッシングは、以下のように行われます。
    • DMSファイル・コンテナー(およびすべてのSMSコンテナー)では、オペレーティング・システムがファイル・システム・キャッシュにページをキャッシュします。
    • DMSデバイス・コンテナー表スペースでは、オペレーティング・システムはファイル・システム・キャッシュにページをキャッシュしません。
    Windows NTを使用する場合、NOCACHEオプションによってDB2がデータベース・ファイルを開くかどうかを、レジストリー変数DB2NTNOCACHEによって指定します。DB2NTNOCACHE=ONの場合には、ファイル・システム・キャッシングは解除され、DB2NTNOCACHE=OFFの場合には、オペレーティング・システムによってDB2ファイルがキャッシュされます。これは、LONG FIELDSやLOBSを含むファイル以外のすべてのデータにあてはまります。システム・キャッシングを除去することにより、データベースでより多くのメモリーが利用できるようになるため、バッファー・プールやソート・ヒープを増加させることができます。ファイル・システム・キャッシングを使用不可にするには、DB2NTNOCACHEレジストリー変数をONに設定します。
     
    db2set DB2NTNOCACHE=ON

    システム・キャッシングを除去することにより、データベースでより多くのメモリーが利用できるようになるため、バッファー・プールやソート・ヒープを増加させることができます。

Linux、UNIX、WindowsのDB2をチューニングするためのPerlスクリプト・サンプル

enable_snap.pl − すべてのDB2スナップショット(BUFFERPOOLS、TABLES、LOCKSなど)を使用可能にします。

perl gather_stats.pl <dbname> <time_in_secs> − このスクリプトは、すべてのDB2スナップショット情報をdbrun.snapという名前のファイルに収集します。

perl buffhitratio.pl dbrun.snap − このスクリプトは、すべてのバッファー・プールのデータおよび索引ページのヒット率を示しています。

 
$ perl buffhitratio.pl dbrun.snap
BP Name      Logical Rd Physical Rd  Writes Async Rds Async Wrts Hit Ratio%
------------------------------------------------------------------------------
	     DATA    	1538     133      19     117       0  91.35%
	     INDX    	3084      38       2       0       0  98.77%
 IBMDEFAULTBP DATA   	1538     133      19     117       0  91.35%
 IBMDEFAULTBP INDX    	3084      38       2       0       0  98.77%
 IBMDEFAULTBP DATA    	1538     133      19     117       0  91.35%
 IBMDEFAULTBP INDX    	3084      38       2       0       0  98.77%

HINT :
It is good have high hit ratio; if not increase your bufferpool size.

perl cathitratio.pl dbrun.snap − このスクリプトは、カタログ・キャッシュのヒット率を示しています。

 
$ perl cathitratio.pl dbrun.snap

        Cache Inserts         Cache Lookups          % Hit Ratio  
        -------------------------------------------------------
         10                   20                     50%        
HINT : 
If hit ratio is less than increase catalog cache size

perl packhitratio.pl dbrun.snap − このスクリプトは、パッケージ・キャッシュのヒット率を示しています。

 
$ perl packhitratio.pl dbrun.snap

Package Cache Inserts      Package Cache Lookups      % Hit Ratio  
 --------------------------------------------------------------
         1                 244                         99%

 HINT : 
Increase the catalog cache size if the hit ratio is less

perl sortthresh.pl dbrun.snap − このスクリプトは、応じられたソートの数と拒否されたソートの数を示しています。

 
$ perl sortthresh.pl dbrun.snap

Piped sorts requested      Piped sorts accepted     % Serviced      Num Sorts Rejected 
 --------------------------------------------------------------------------------
         1                   1                      100%                    0
 
 HINT : 
 If % Serviced is low then increase sheapthresh
 If Num Sorts Rejected is higher then increase sortheap or sheapthreash is too small

perl sorttime.pl dbrun.snap − このスクリプトは、ソートあたりの平均時間を示しています。

 
$ perl sorttime.pl dbrun.snap

Total Sort Time (ms)      Total Sorts  Average Elapsed Time per sort 
 -----------------------------------------------------------------
        100                  10         10
HINT : 
As the performance improves, this average will decrease

perl tbs_usage.pl <dbname> − このスクリプトは、データベースのすべての表スペースに関する空きスペースと使用済みスペースを示しています。

 
$ perl tbs_usage.pl tpcd
connect to ebuis

   Database Connection Information

 Database server        = DB2/LINUX 7.2.2
 SQL authorization ID   = EBUIS
 Local database alias   = EBUIS


Ts_Id         Ts_Name         Total   Used     Free  Number_of_files
------------------------------------------------------------------
  0          SYSCATSPACE      10M      10M       0M  1
  1           TEMPSPACE1       0M       0M       0M  1
  2           USERSPACE1       0M       0M       0M  1
  3            BENCHTEMP    1000M       0M     999M  2
  4          ORDERS_DATA    1000M      95M     903M  2
  5         ORDERS_INDEX    1000M      18M     981M  2
  6        LINEITEM_DATA    1000M     398M     600M  2
  7       LINEITEM_INDEX    1000M     138M     861M  2
  8            BENCHINDX    1000M      22M     977M  2
  9            BENCHDATA    1000M      94M     905M  2

perl locklist.pl dbrun.snap <dbname> − このスクリプトは、合計ロック・リスト、使用中の平均ロック・リスト、平均ロック・リスト使用率を示しています。

 
$ perl locklist.pl dbrun.snap ebuis

   Locklist (4K Page)       Lock_list_in_use(4K Page) Lock list utilization 
 --------------------------------------------------------------------------------
       100                   6                        6%               
 
 HINT : 
 If Lock list utilization is low then decresae the locklist 
 If Lock list utilization is more then increase the locklist

perl disable_snap.pl − すべてのDB2スナップショットを使用不可にします。


参考文献


ダウンロード

内容ファイル名サイズ
Code sampledb2_tune.ZIP12KB
Code sampledb2_tune.tar64KB
Code samplereadme.txt2KB

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=322907
ArticleTitle=DB2 UDB EEE :チューニングのためのクイック・リファレンス
publish-date=05232002