Y②③④ Windowsの
II. DB2 V9.1の機能のみ使用可能
z
詳細は、下記のDB2オンラインマニュアルをご参照ください。¾ [クライアントとサーバーのバージョンのサポートされている組み合わせ]
¾ http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.clien t.doc/doc/r0009731.html
¾ [クライアントのマイグレーションに関する重要事項]
¾ http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/topic/com.ibm.db2.luw.qb.migration.doc/
doc/c0022579.html
データベース作成の考慮点
データベースの分割の目安
z アプリケーション構成（業務内容）
z 同時に処理する要件があるか
¾ パフォーマンスの観点から一つにすることも検討
¾ 分割されていると２フェーズ・コミット必要
¾ JOIN不可(連合DBを使用の場合は可能）
z 運用管理（バックアップ／リストア）の面から検討
¾ 処理時間
¾ 運用時間帯 z 可用性
z テスト環境ではフェーズやチーム単位で分割
z コード・セット別
¾ Unicodeデータベース
– V9 XMLデータタイプを使用する場合、UTF-8のデータベースでなければならない – V9.5のデフォルトでは、UTF-8のデータベースとして作成される。
z 分割する場合、レプリケーション機能の検討も必要か
z デフォルトのページ・サイズはどのサイズにするか
z 自動ストレージ・データベースとして作成するか（V8.2.2以降）
¾ V9でのデフォルトでは、自動ストレージ・データベースとして作成される
作成時のCOLLATE USING句指定
z 日本語環境でデータを五十音順に照合したい場合はIDENTITYを指定
¾ デフォルトはSYSTEM（辞書順）
z 作成後は変更不可
V9.5
解説
データベースの分け方
z まずアプリケーションの構成から決定します。業務が全く異なる場合は、別データベースにするべきですが、それぞれに属す る表同士に何らかの関連があって同時に処理する必要がある場合は、パフォーマンスの観点からも同じデータベースにして しまうことも検討します。
z バックアップ/リストアといった運用管理の面からも検討します。
z 複数に分けた場合、１つがダウンしても別のデータベースは使用可能ですので、可用性という点では優位です。
z このほかに、データベースを分ける例としては以下の様な場合があります。
z 開発用と本番用
z 共用する表を持たない異なるシステムの場合（表をJOINしたい場合は通常分けない）
z
Unicodeデータベースなど、コードセットの異なるDBが必要･･･ など
CHAR、VARCHAR、LONG VARCHARの照合(ソート、比較など)においては、値の重み付けを考 慮する必要があります。
重み付けは、CREATE DATABASEのCOLLATE USING句で指定する事ができます。
z
SYSTEM(デフォルト)：現行のテリトリーに基づいた照合順序 (辞書順)
¾ 例：a(X'61')、A(X'41')、b(X'62')、B(X'42')、c(X'63')、C(X'43')、・・・
z
COMPATIBIRITY：DB2 V2の照合順序に同じ (電話帳順)
¾ 例：A、a、B、b、C、c・・・
z
IDENTITY：バイト単位で比較 (文字コード順)
¾ 例：A、B、C、・・・、a、b、c・・・
日本語などのダブルバイトの文字については、1バイトずつに分割して照合が行われます。
z
SYSTEMの場合の日本語例：
¾ ヂ(X'8361')、ア(X'8341')、ッ(X'8362')、ィ(X'8342')、ツ(X'8363')、イ(X'8343')、・・・
z
COMPATIBIRITYの場合の日本語例：
¾ ア(X'8341')、ヂ(X'8361')、ィ(X'8342')、ッ(X'8362')イ(X'8343')、ツ(X'8363')、・・・
z
IDENTITYの場合の日本語例：
¾ ァ(X'8340')、ア(X'8341')、ィ(X'8342')、イ(X'8343')、・・・、チ(X'8360')、ヂ(X'8361')、ッ(X'8362')、ツ(X'8363')、ヅ(X'8364')、・・・
日本語環境では五十音順にデータを照合したい場合には、COLLATE USING句にIDENTITYを 指定してデータベースを作成する事をお薦めします。
COLLATE USINGに指定した値は、一旦データベースを作成した後に変更する事はできません
ので注意して下さい。
④表の分類と表スペースの構成
表スペースとは
表スペースの種類と選択
z DMS表スペースとSMS表スペース
複数表スペースの検討
一時表スペースの定義
検討すべき表スペース属性
表スペースとは
表スペース
z 表のデータを格納するための論理的な領域媒体
z 実際にデータを格納する物理的な媒体をコンテナーという
¾ コンテナーの実体はファイルシステムのディレクトリ、ファイル、または論理ボリュームなどの ローデバイス
z 一つの表スペースを１つ以上のコンテナーで構成
z データベース内に作成される表スペース
¾ システム・カタログ表スペース，システム/ユーザー一時表スペース，ユーザーデータ用表ス ペース
z 表スペースはバックアップの最小単位
コンテナー ０
コンテナー １
コンテナー ２
コンテナー
３ コンテナー
４
表
表スペース データベース
表スペース
バッファープール バッファープール
索引 表
解説
表スペースは、表のデータを記憶するための論理的な領域媒体です。
実際に表のデータが物理的に格納されるのは、表スペースに紐付けされたコンテナーになります。
コンテナーは、表スペースのタイプにより、ディレクトリーやファイル、デバイスといった形態を取ります。
一つの表スペースに複数のコンテナーを割り当てることができます。
z データはコンテナー間で平均的に割り振られます。
一つのコンテナーは、一つの表スペースにしか属することはできません。
表スペースへのデータの書き出しは、エクステントと呼ばれる割り当て単位に行われます。(デフォル トは32ページ) (詳細は後述)
create databaseを実行すると、デフォルトでは３つの表スペースが自動的に生成されます。
z
SYSCATSPACE：システム・カタログ表スペース
¾ システム・カタログ表、およびその索引が入っている表スペースです。
¾ データベース作成時に作られ、一旦作られた後は、変更や削除することができません。
z
TEMPSPACE1：システム一時表スペース
¾ JoinやSort時に一時的にデータが入る表スペースです。
z
USERSPACE1：ユーザー・データ用表スペース
¾ ユーザーのデータや索引が入れられる表スペースです。
¾ 表スペースを指定せずにcreate tableを実行すると、他のユーザー・データ用表スペースが無い場合は、デフォルトで、この表スペースが使わ れます。
¾ 既に他のユーザー・データ用表スペースが作られている場合には、最初に作られた表スペースが使われます。
表スペース単位でバックアップ/リストアを行うことも可能です。
ロールフォワード回復不可能な場合(循環式ロギング)は、データベース単位のバックアップのみ可能 です。
z 循環ロギングの設定
¾ LOGRETAIN（DB構成パラメーター）=NO
¾ USEREXIT（DB構成パラメーター）= NO
¾ LOGARCHMETH1/LOGARCHMETH2 （DB構成パラメーター）=OFF