Db2 for iでの設計
データベース設計は概念設計、論理設計、物理設計と段階を踏んで作業を進める。概念設計、論理設計は使用するデータベースにあまり依存しないが、物理設計は実装するデータベース製品に特化した作業となる。
なぜなら物理設計では、論理設計で決定したテーブルや索引といったオブジェクトについて、対象となるシステム上にどのように実装し、構築していくかを決めていくステップであるからだ。
また物理設計の品質はデータベースのパフォーマンスや可用性に大きく影響を与えるため、IBM i のオペレーティング・システムおよびデータベースの知識をもち、理解したうえで検討を進める必要がある。そこで本稿では物理設計にフォーカスし、Db2 for iの特徴を補足しながら説明していこう。
なおここでは、物理設計を行う前にテーブルの論理設計が完了していること、ディスク構成を含むハードウェア構成がほぼ決定していることを前提とする。
物理設計で検討する項目
図表1は、一般的なデータベースの物理設計で実施する主なステップである。
ただしDb2 for iは前のPartで述べたとおり、インスタンスや表スペースという概念をもたないため、③～⑤のステップは不要である。
Db2 for iの物理設計に必要な残りのステップについて、考慮事項を加えながら解説する。
テーブル・索引定義の作成（①）
テーブル定義の作成では、テーブルや列の名前、テーブルや列を配置するライブラリー（スキーマ)、列のデータ・タイプおよびデータ長、CCSID（テーブル単位、列単位)などを検討する。
システム・インターフェースでは各オブジェクトの名称は最大10桁だが、SQLインターフェースでは128桁となっている。
Db2 for i では、SQLインターフェースから10桁を超える長さの名称を指定してオブジェクトを作成した場合、システム・インターフェースで使用可能となる10桁の短縮名「最初の5文字＋連番5文字」を自動で割り当てる。
たとえば、CUSTOMER_MASTERというテーブルをCREATE TABLEステートメントで生成した場合は、CUSTO00001になる。この短縮名称はオブジェクト生成のタイミングによって、CUSTO00002であったり、CUSTO00003であったりと変わる可能性があるので、SQL DDLで明示指定しておくほうがよいだろう。
テーブルやビューに対する短縮名称にはFOR SYSTEM NAME、カラムに対する短縮名称にはFOR COLUMNを使用すればよい。
図表2は、名称がCUSTOMER_NUMBER、短縮名称がCUSTNUMをはじめとする複数のカラムをもつ、名称がUSTOMER_MASTERでシステム短縮名称がCUSTMSTであるテーブルを作成する場合のDDLの例である。
Db2 for iでは、テーブルや列を配置するライブラリー（スキーマ）の命名にも考慮が必要である。Q または SYS 接頭部で始まるライブラリー名は、規則によりシステムで予約されて使用されるので、ユーザーが定義するライブラリー名には使用しないようにする。
図表3に示すとおり、Db2 for iでサポートする列のデータ・タイプはDB2 for LUWとほぼ同じである。
ただし図表4のとおり、データ・タイプが同じであっても、Db2 for iとDb2 for LUWとで制限値に違いのあるケースがあるので注意したい。
列のデータ長の定義では、IBM iのデータは通常EBCDICと呼ばれる文字コードが使用されるため、DBCS（2バイト文字）を含む場合には、文字列の先頭と末尾に1バイトずつシフト文字が含まれることに注意してほしい。
DBCS混合列の場合には1バイト文字と2バイト文字が混在し、データによってはシフト文字がどの程度含まれてくるか判断が難しい場合もある。このための対応策として、十分な余裕をもって列の長さを何バイト分か長くしておく、シフト文字を心配する必要のないUNICODEに列のCCSIDを変更することなどが考えられる。
CCSIDは、コード化文字セットID（Coded Character Set Identifiers)と呼ばれる文字コードを一意に識別できるIDである。複数システム間でデータ連携を行う場合には、割り振られているCCSIDに基づいて、連携元と連携先で文字コード変換が実行される。
IBM iを日本語環境で利用する場合、CCSID 5026、CCSID 5035、CCSID 1399などが設定される。Db2 for iでは、テーブル単位でCCSIDを設定できるのに加え、列単位での設定も可能である。つまり、1つのテーブルのなかに複数の文字コードをもつデータを混在させて格納できる。
索引の設計では、制約も考慮しながら検討を進めることになる。制約としては、主キー（プライマリー）制約、一意キー（ユニークキー）制約、外部キー制約、[NOT]NULL制約、CHECK制約などがある。さらに一次索引、二次索引についても検討が必要となるが、これらの設計に際してはとくにDb2 for i特有の注意事項はないので、一般的な情報を参考にしながら作業を進める。
データ容量の見積もり（②）
テーブルのレイアウトとレコード数からデータ容量を見積もり、必要となるディスク容量を計算する。Db2 for i ではデータ容量の見積もりに際して、対象となるファイルは物理ファイル （アクセス・パスは除く）、論理ファイル （アクセス・パスは除く）、到着順アクセス・パス、キー順アクセス・パスが該当する。
さらにシステムが保持する内部オブジェクトとして、データベース・ファイル用の内部様式とディレクトリも見積もり対象に含める必要がある。
なお、これらの見積もりの計算式は、IBM i のバージョンやリリースにより異なる可能性がある。本稿ではIBM i 7.4のマニュアルを参照しているが、該当するOSバージョンのマニュアルを個別に確認する必要がある。
ファイルのディスク・サイズは、下記の計算式で見積もることが可能である。
●ヌルが可能なフィールドをもたない物理ファイル（アクセス・パスは除く)
ディスク・サイズ＝ （有効レコードおよび削除済みレコードの数+1）×（レコード長+ 1）＋ 20480 ×（メンバーの数）＋ 8192
●ヌルが可能なフィールドをもつ物理ファイル（アクセス・パスは除く）
ディスク・サイズ＝（有効レコードおよび削除済みレコードの数＋1）×（レコード長＋1）＋20480×（メンバーの数）＋8192＋（（フォーマット内のフィールドの数）÷8） 切り上げる） ×（有効レコードおよび削除済みレコードの数＋1）
●論理ファイル （アクセス・パスは除く）
ディスク・サイズ＝12288×（メンバーの数）＋8192
●到着順アクセス・パス
追加スペースは不要
●キー順アクセス・パス
計算式で使用する定数は、図表5を参照。定数は索引のタイプにより異なる。
内部オブジェクトのサイズは、下記の計算式で見積もることが可能である。
●別のファイルの様式を共用しないファイル
様式サイズ＝（144×フィールド数）＋ 4096
●他のファイルと様式を共用するファイル
様式共用ディレクトリ・サイズ＝（16×様式を共用するファイルの数）＋ 4096
●論理ファイルまたはそれに対して作成された論理ファイル・メンバーをもつ個々の物理ファイルおよび物理ファイル・メンバー
データ共用ディレクトリ・サイズ＝（16×データを共用するファイルまたはメンバーの数）＋ 4096
●アクセス・パスを共用する論理ファイル・メンバーをもつ個々のファイル・メンバー
ディレクトリ・サイズを共用するアクセス・パス＝（16×アクセス・パスを共用するファイルまたはメンバーの数）＋ 4096
最後に、データベース・ファイルを設計して作成する場合には、ファイルの許容最大サイズを知っておく必要がある。最大値を図表6にまとめる。
＜図表6の注意＞
*1：変更順先出し （FCFO） アクセス・パスがファイルに指定されるときの物理および論理ファイルのキーのサイズの最大値は、ACCPTHSIZ（*MAX1TB） の場合は32,763 文字、ACCPTHSIZ（*MAX4GB） の場合は1,995 文字
*2：キー順アクセス・パスをもつファイルの場合、メンバー中のレコードの最大数が変わり、以下の式で概算可能
・ ACCPTHSIZ（*MAX4GB） を指定する場合は、2,867,200,000 / （10 + （.8 * キーの長さ））
・ ACCPTHSIZ（*MAX1TB） を指定する場合、1,356,416,600,000/ （12 + （.8 * キーの長さ））
（ただし、これらは推定値であり、実際のレコードの最大数は、かなり異なる場合あり）
*3：ファイル・メンバーのバイト数とアクセス・パスのバイト数は、システムの最大システム・オブジェクト・サイズに達したことを示すメッセージCPF5272 が送られた時点で、調査が必要
*4：可変長文字またはDBCS フィールドの最大サイズは、32,740 バイト。DBCS グラフィック・フィールド長の最大値は16,383 文字（固定長） および16,370 文字（可変長）
*5：最大サイズ4ギガバイト（GB） つまりACCPTHSIZ（*MAX4GB） でアクセス・パスが作成される場合、最大値は4,294,966,272バイト。上記の数は最大値であり、実際の限界値は条件によって上記の値より小さい場合がある（特定の高水準言語では制限がある、など）
ディスク上へのオブジェクトの配置（⑥）
一般的なデータベースにおいて、ディスク装置へのオブジェクト配置はシステム全体のパフォーマンスに影響を与えるため、十分な検討と考慮が必要である。一方、Db2 for iの場合は、同一ASP内に構成されているディスクに対し、OSがバランスよく最適に物理配置するため、この点についてユーザーが配置を検討する必要はない。
逆にユーザーが配置を決められないので、ディスク障害に備えてミラーリングやRAIDといったディスクのデータ保護、ディスク装置を複数の記憶域のグループ（ASP）に分割した構成にするのか、といった検討が必要である。
そのほかDb2 for iでジャーナルと呼ばれる、他データベースで言うところのログに相当する機能の設計も必要である。詳細を以下に説明する。
IBM i従来のインターフェースのアプリケーションでは、コミット制御を使用しない設定も可能であり、必ずしもIBM iでジャーナル設定は必須ではない。
しかしSQLアプリケーションで正しくトランザクション処理を行うには、ファイルのデータ処理の履歴を保管するジャーナル処理が前提となる。
Db2 for i で検討するジャーナルの設計としては、「ジャーナルを溜めるジャーナル・レシーバーの配置をどうするか」「ジャーナル・レシーバーのサイズはどうするか」「ジャーナル・レシーバーの切り替えを自動化するか」「切り替えた古いジャーナルの削除のタイミングを含め運用はどうするか」などがある。
ジャーナル・レシーバーの配置については、IBM iではテーブル単位でジャーナルをかけることができ、システムに複数のジャーナルをもてる。複数のジャーナル・レシーバーを配置するライブラリーの検討に加えて、配置するASPも検討する必要がある。
HDDディスクによるストレージ構成を組んでいる場合、ジャーナルを別ASPに分散させることで、ディスク・アームのアクセス競合を分散させられるのでパフォーマンスの向上が期待できる。さらにファイルとログを異なるASPに分割した構成は、ディスク障害時にASP単位での回復処理が可能になるため、障害のリスク分散を図ることができる。
また参考情報であるが、ライブラリーを作成する場合、SQLのDDLであるCREATE SCHEMAで作成する方法と、IBM iの従来からあるCRTLIBコマンドで作成する方法がある。
CREATE SCHEMAで作成した場合、同じライブラリー内にジャーナルが自動的に作成され、ライブラリー内に作成されたテーブルは自動的にジャーナル処理される。ライブラリー内にはシステム・カタログも作成され、ライブラリー内に作成されたテーブル、索引、制約、ビュー、パッケージなどに関する情報が書き込まれる。
一方、CRTLIBで作成した場、ジャーナルは自動で作成されないため、作成したテーブルは個別にジャーナル設定する必要がある。一見するとCREATE SCHEMAによる作成のほうが自動でジャーナル処理され、便利そうに見える。しかし本番環境での運用を考慮すると、実際に障害が発生した場合のリカバリー、システムのパフォーマンス、ディスク管理などの観点から、CRTLIBで作成し、ジャーナル設計することが推奨される。
構成パラメータの設定（⑦）
これまでのステップで検討した物理設計を踏まえ、関連する構成パラメータを設定し、構築時に実行するコマンドやスクリプトを整理する。
以上、Db2 for iの物理設計で必要とされる作業を見てきた。Db2 for iはOSやマイクロコードに組み込まれているため、物理設計のステップとして検討不要な項目がある。
その一方で、OSの機能に組み込まれているので、テーブル名やライブラリー名にはIBM iのOSとして共通の注意事項があることを理解いただけたと思う。
［i Magazine 2020 Summer掲載］
著者
松川 真由美氏
日本アイ・ビー・エム
システムズ・エンジニアリング株式会社
クラウド・イノベーション
シニアITスペシャリスト
日本IBMに入社後、IBM iユーザー向けのお客様担当SE、ソフトウェアを提案支援するSEを経て、日本アイ・ビー・エム システムズ・エンジニアリングに異動。IBM iおよび関連のミドルウェアを中心としたプロジェクトへの参画や技術支援を実施し、現在に至る。
特集｜あらためて知るDb2 for i
