検索
連載

DB2のデータベース・オブジェクトと物理設計：DB2マイスター養成講座（2）（2/2 ページ）

今回は、物理設計時の前提知識として各データベース･オブジェクトを紹介し、次に物理設計におけるポイントを解説する。（編集局）

Share
Tweet
LINE
Hatena
前のページへ | 　　　　　　

データベース作成時の検討事項

　それでは、実際のプロジェクトの進行に応じて物理設計とキャパシティ・プランニングについて、前回と同様に考慮点と検討事項を解説します。

　データベースを作成する際は、以下の点を考慮する必要があります。

■データベースの場所（データベース・ディレクトリ）

　データベースを格納する物理的な場所（データベース・ディレクトリ）を決めます。ここには、デフォルトでデータベースを構成するすべてのオブジェクトが格納されます。デフォルトの表スペースもこのディレクトリ以下に格納されます。I/Oの速度が速く、運用しやすい（注）ディレクトリを指定します。

注：例えば、OSと異なるドライブ／パーティションを使うことで、OSを再インストールしなければならない事態になっても、データベースを残すことができます。


■言語（コードセット、テリトリ）

　データベースが使用する文字コードと国を指定します。データベース作成後には変更できないので、注意が必要です。

　Linuxでは、デフォルトでシェルの環境変数LANGを参照して文字コードが決められるので、日本語のLinux環境ではコードセットが「IBM-eucJP」、テリトリが「JP」というデータベースが作成されます。日本語であれば、IBM-eucJP、IBM-943（シフトJIS）、UTF-8が一般的です。コードセットの違いはDB2のクライアントが変換することで吸収されるので、IBM-eucJPで問題ありません。

　ただし、XMLやWebサービス関連の関数を使用する場合は、IBM-eucJPでは不具合のあるものもあるので、IBM-943かUTF-8をお勧めします（FixPak3時点）。また、日本語を格納するbyte数にも若干の違いがあるので注意が必要です。

コラム　JDBCドライバとSun JDK

　DB2 UDB V8.1からJDBCドライバが新しくなっています。このJDBCドライバを使う際にも、データベースのコードセットに注意が必要です。SunのJDKを使うと、IBM-943が変換できずエラーになります（Linuxの場合、SunのJDKはDB2ではサポート外）。Tomcatなどでは、特に要注意です。DB2に付属するIBMのJDKを使う場合は問題ありません。


■ソート順

　前述のコードセットと同様、データベース作成後には変更できないので注意が必要です。デフォルトでは、テリトリ（国）に基づくソート順序「SYSTEM」が適用されます。これ以外に、byte単位で比較ソートする「IDENTITY」やDB2 V2の方式の「COMPATIBILITY」が選択できます。特別な理由がない限り、通常はデフォルトのSYSTEMを使用します。

$ db2 create database test on /db2data using codeset UTF-8 territory JP collate using SYSTEM
例：データベース・ディレクトリを/db2data、コードセットをUTF-8、ソート順をSYSTEMとしてデータベースを作成

■バッファー・プール

　デフォルトでは約100Mbytes（4Kbytes×1000ページ）割り振られますが、これでは小さいのでデータベース作成後に必ず増やします。

$ db2 'select substr(bpname, 1, 20) as bpname, npages, pagesize from syscat.bufferpools'
 
BPNAME               NPAGES      PAGESIZE
-------------------- ----------- -----------
IBMDEFAULTBP                1000        4096
例：現在のバッファー・プールを確認
$ db2 ALTER BUFFERPOOL IBMDEFAULTBP IMMEDIATE SIZE 2000
例：バッファー・プールを増やす
$ db2 CREATE BUFFERPOOL BUFFERPOOL8 SIZE 500 PAGESIZE 8K
例：バッファー・プールのページサイズを8Kbytesに変更

　複数のバッファー・プールを持つことができる点も考慮しましょう。

専用のバッファー・プールを選択する例

　また、以下の場合は専用のバッファー・プールを作成することも選択肢の1つになります。

  • 4Kbyets以外のページサイズのバッファー・プールを使いたい
  • 頻繁にアクセスするマスター・テーブルがある
  • データ容量が巨大なので、大きなバッファー・プールは確保できないが、インデックスはメモリに常駐させたい

　バッファー・プールの構成はパフォーマンスに影響を与える部分なので、構成には注意が必要です。ただし、バッファー・プールは後で変更することも可能なので、初めは大まかに構成し、パフォーマンス・テストの段階で詳細なチューニングを行うことも可能です。

　第1回でも紹介しましたが、メモリは以下の式で見積もることができます。

メモリ＝DB2エンジン（256MBbytes）＋バッファプール＋エージェント用メモリ＋DB2以外のソフトウェアが使用するメモリ


　バッファー・プールの説明をしたので、この式をもう少し詳しく解説しましょう。

　バッファー・プールは、以下を参考にしてください。

バッファー・プール＝デフォルト・バッファープール（1）＋特定テーブル用バッファー・プール（2）＋大容量テーブルの索引用バッファー・プール（3）

（1）全データの数％を目安に見積もる。10Gbytesのデータであれば500Mbytes程度
（2）マスター・テーブルのように、頻繁に使用するテーブル用。テーブルのデータ量に合わせて見積もる
（3）索引は、（平均索引キー・サイズ＋8）×レコード数×2で見積もる

　エージェント用のメモリは、1接続当たり5Mbytesを目安に見積もります。同時接続数が50であれば、250Mbytes程度をエージェント用メモリとして確保します。

表スペース作成時の検討事項

■SMS表スペースかDMS表スペースか

　表スペースは、まず物理的なタイプを決める必要があります。以下を参考に、SMS表スペースかDMS表スペースかを選択します。

  • SMS表スペースのメリット
    • ディレクトリ単位で指定するため、余分なスペースが割り振られることがない
    • コンテナの事前定義が不要なため、初期作業が少ない
  • DMS表スペースのメリット
    • 表スペースのサイズは、コンテナの追加・削除によって変更可能
    • 格納するデータタイプによって、表スペースを分割可能（LONGデータ、ログデータ、索引など）

　一般的には、DMS表スペースの方がパフォーマンスに優れるため、ユーザー表スペースにはDMS表スペースを使用します。

■コンテナの配置

　SMS表スペースの場合はディレクトリを指定するので難しく考える必要はありませんが、DMS表スペースの場合は物理ディスクに合わせたコンテナの配置が必要です。

　コンテナの数を増やすことでディスクへのI/Oが分散されるので、パフォーマンスを向上させることもできます。

■エクステント・サイズ

　データベース・マネージャから表スペースへのデータの書き出しは、エクステントと呼ばれる割当単位（ページ）に行われます。エクステント・サイズは表スペース作成時に指定するもので、後で変更することはできません。

　DMS表スペースでは、エクステント・サイズを一度に割り振り、いっぱいになった時点で（コンテナが複数あれば）次のコンテナでアロケートして書き込みを行います。SMS表スペースの場合は、1ページずつ割り振ります（注）。エクステント・サイズを決める際は、以下の点に注意することが必要です。

  • 急に大きくなる表に対しては、エクステントの割り振りのオーバヘッドを避けるためエクステント・サイズを大きくしておく
  • 1つの表スペース内に多くの小さな表が存在する場合、少ないデータに対して大きなスペースを割り振るオーバーヘッドを避けるため、DMS表スペースであればエクステント・サイズを小さくするか、SMS表スペースを使用する

注：db2empfaユーティリティを使えば、SMS表スペースでもエクステント・サイズを一度に割り振ることが可能です。


■バッファー・プール

　表スペースは、特定の1つのバッファー・プールを使用します。デフォルトのバッファー・プール（IBMDEFAULTBP）以外のバッファー・プールを使用する場合は、必要なバッファー・プールを作成し、表スペース作成時にそのバッファー・プールに関連付けます。

$ db2 "CREATE TABLESPACE USERSPACE8 PAGESIZE 8K \
MANAGED BY DATABASE \
USING (FILE '/db2data/db2inst1/NODE0000/SQL00001/TS8.TS' 10000) \
BUFFERPOOL BUFFERPOOL8"
例：表スペースの作成

データベース・ロギングの構成

■循環ログ方式か保存ログ方式か

　更新のない、参照だけのデータベースであればログを保存する必要もないので循環ログ方式で十分です。しかし、ほとんどの場合は更新を伴うためログを保存し、データベースが壊れた際は、バックアップイメージと保存したログ（アーカイブ・ログ）を使ってデータベースをリカバリしなければなりません。

　デフォルトでは循環ログ方式なので、必要に応じてデータベース構成パラメータを変更します。

$ db2 update database config for test using LOGRETAIN ON
例：保存ログ方式に変更

■ログの配置

　データベース構成パラメータのNEWLOGPATHを使って、アクティブ・ログの場所を変更することができます。デフォルトではデータベース・ディレクトリ以下に作成されますが、ディスクI/Oなどを考慮して、別のパーティションに移すことも可能です。

$ db2 update database config for test using NEWLOGPATH /db2log
例：ログパスの変更

■アーカイブ・ログの保存場所

　クローズされたアーカイブ・ログを、アクティブ・ログとは別の場所に保存することができます。可用性の観点から、アーカイブ・ログの保存場所を変えることでDB2の状態にかかわらずアーカイブ・ログのバックアップを可能にします。

$ db2 update database config for test using USEREXIT ON
例：USEREXITプログラムの使用

コラム　USEREXITプログラム

　USEREXITプログラムを使えばアーカイブ・ログを移動できますが、USEREXITプログラムはサンプルしか提供されていないので、コンパイルする必要があります。

　$INSTANCE_HOME/sqllib/samples/c以下に、4つのサンプルが用意されています。ディスクに保存する場合はdb2uext2.cdiskを使います。

1. 適当な場所にコピーして、230行目から236行目を環境に合わせて変更
$ cp ~/sqllib/samples/c/db2uext2.cdisk ./tmp/db2uext2.c
$ cd tmp
$ chmod +w db2uext2.c
$ vi db2uext2.c
2. コンパイルしてバイナリをコピー
$ gcc -D_INCLUDE_POSIX_SOURCE db2uext2.c -o db2uext2
$ cp db2uext2 ~/sqllib/adm/

　これでUSEREXITプログラムが利用可能になります。


　以上、データベースの物理構成を行う際に考慮すべき点を検討しました。次回は、アプリケーションの開発について、特にWebアプリケーションの開発を中心に解説します。

「次回」へ


「DB2マイスター養成講座」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 　　　　　　
ページトップに戻る