Db2 for iのオブジェクト構成
IBM i のデータベース機能は、Db2 for i と命名されているように、IBMが各プラットフォーム向けに提供しているRDBMSであるDb2ファミリーの一員として位置付けられている。ただしPart1で触れたとおり、LUW （Linux、UNIX、Windows）向けのDb2とは異なる特徴がある。
まずはDb2 for i とDb2 for LUWを比較しながら、Db2 for i のオブジェクト構成について解説しよう。
図表1は、Db2 for LUWとDb2 for i のソフトウェア構成である。
Db2 for LUWでは、OS上にミドルウェアとして導入・構成する必要がある。一方、IBM i のデータベース機能はマイクロコードおよびIBM i OS提供の機能として組み込まれており、IBM i を導入・構成した時点でデータベース機能を利用できる。
Db2 for LUWでデータベース・サーバーを構築する場合はDb2を導入後、最初にインスタンスを構成する。インスタンスとはDb2における最大の論理単位で、1つのデータベース・マネージャー構成ファイルを使用して稼働するデータベース・マネージャー環境を指す。
このインスタンスが、Db2 for LUWで起動・停止を実行する単位となる。インスタンスは1つのOS環境に複数構成でき、運用管理性や可用性を考慮してインスタンスの分割を検討することもある。
インスタンスにはデータベースを構成する。データベースはDb2としてデータの論理的な整合性を保証する単位であり、Db2 for LUWではバックアップ／リストアの最大単位となる。アプリケーションからこのデータベースに接続し、データベース内のテーブルやビューなどを操作対象とする。
データベースには表スペースと呼ばれる、テーブルのデータを格納するための論理的な領域を構成する。この表スペースはあくまで論理的な領域であり、物理領域としてどのようにストレージ領域に配置させるかを指定する必要がある。
表スペースへのストレージ領域の配置方式には以下の2種類があり、表スペースの用途 （ユーザー・テーブルを配置するため、あるいは一時表やカタログ表を配置するため、など） によって選択する。
SMS （System Management Storage）
DMS （Database Management Storage）
SMSはOSのファイル・マネージャーがファイル管理を行う方式で、OSのディレクトリを表スペースに紐づけるコンテナ （物理的なデータ配置領域） として利用する。
一方のDMSはデータベース・マネージャーがファイル管理を行う方式で、ファイルもしくはデバイスをコンテナとして利用する。
さらにV10.1以降は、AMS （AutoMatic Storage） と呼ばれるシステムが自動的に、表スペースの用途に応じてSMS、DMSを選択するようになった。表スペース構成時には、ページ・サイズも指定する必要がある。指定するサイズによってレコードの最大長や最大列数、最大容量が決まり、I/O効率も変わる。
また表スペース内のテーブルや索引のデータがストレージ領域から読み取られる際に、それらをキャッシュしておく領域としてバッファ・プールを用意する必要がある。表スペースに対しては、どのバッファ・プールを使用するかを構成時に指定する。
テーブルや索引は表スペースに配置されるので、当然ながら表スペースとして定めたサイズ以上のテーブルや索引を配置することはできない。また、表スペースはあらかじめバッファ・プールも紐づける形になるので、テーブルのサイズやテーブル内のデータの参照方法 （ランダムアクセスなのか、特定レコードが頻繁にアクセスされるのか）によって、適切な表スペースやバッファ・プールを構成・設定させる必要がある（図表2）。
以上、簡単にDb2 for LUWでのオブジェクト構成を見てきた。ここからはDb2 for iでのオブジェクト構成を見ていこう。
まず、Db2 for iにはインスタンスの概念がない。IBM i をデータベース・マネージャーとして捉えるなら、IBM i OS環境は1つのインスタンスとして考えられるが、そもそもインスタンスの概念がないので、インスタンスの分割検討は不要となる。
運用管理性や可用性については、IBM i OS環境のレベルで担保する。Db2 for LUWでは1つのインスタンスに対して明示的にデータベースを作成するが、Db2 for i ではIASP （独立補助記憶域プール） と呼ばれる、IBM i の稼働中に構成をオフ・オンできる補助記憶域プール（ストレージ領域の論理的なグループ）を構成しない限り、1つのIBM i には1つのデータベースが構成される。IASPを構成した場合には、IASP自体がDb2 for i での1つのデータベースとして振る舞う（図表3）。
つまりDb2 for i では、インスタンスやデータベースは設計要素とはならない。基本的には、1システム＝1インスタンス＝1データベース （IASPを構成する場合を除く）という形態で利用する。
Db2 for i でテーブルや索引のデータをストレージ領域のどこに配置し、どのメモリ上に展開するのかは、Part1のとおり、すべてIBM i の記憶域管理手法であるSLS （シングル・レベル・ストレージ：単一レベル記憶） によって一元管理される。
SLSはIBM i の特徴的な記憶域管理アーキテクチャであり、メモリ領域とストレージ領域を1つのアドレス空間としてマッピングし、領域を4KBのページ単位で管理する。Db2 for LUWで存在する表スペース、バッファ・プールといった概念はDb2 for i には存在しない。
Db2 for LUWに表スペースが存在することはすなわち、OSの容量管理として、ストレージ容量だけでなく表スペースの容量も把握する必要があることを意味する。
一方、Db2 for i ではストレージ容量のみを把握しておけばよいので、Db2 for LUWに比べてシンプルな運用管理が実現できる。
Db2 for iのオブジェクト操作インターフェース
ここまでDb2 for LUWと比較しつつ、Db2 for i のオブジェクト構成を見てきた。次に、操作インターフェースについて見ていこう。
主なインターフェースとして、以下の2つが存在する。
システム・インターフェース
SQLインターフェース
システム・インターフェースは、5250エミュレータ画面からデータベース・オブジェクトを操作するインターフェースである。SQLインターフェースは、リレーショナル・データベース言語であるSQLを用いてデータベースを操作するインターフェースを指す。それぞれのインターフェースで操作する際に用いる用語を図表4にまとめた。
たとえば表を作成する場合、システム・インターフェースではDDS（Data Description Specification: データ記述仕様）、SQLではDDL （Data Definition Language）を使用する。DDSから生成したオブジェクト、DDLから生成したオブジェクトはどちらも、もう一方のインターフェースで操作することが可能だ。
システム・インターフェースでオブジェクトを操作する場合には、5250エミュレータを使用すればよい。SQLでオブジェクトを操作する場合には、ACS（IBM i Access Client Solutions）のデータベース機能を利用できる（図表5）。
そのほか、無償で利用できるデータベース開発管理統合環境であるIBM Data Studioも使用可能である（図表6）。
IBM Data StudioはEclipseベースなので、IBM i アプリケーション開発クライアントであるRational Developer for i と統合し、パースペクティブの切り替えで容易に使い分けることができる。
Db2 for i のデータ・アクセス・インターフェース
Db2 for iのオブジェクト操作インターフェースとしてシステム・インターフェースとSQLの2つがあるように、Db2 for i のデータにアクセスする方式として以下の2つが実装されている。
RLA
SQL
RLA（Record Level Access: レコード・レベル・アクセス）はテーブルのレコード単位でデータを操作するインターフェースで、例としてREAD、CHAIN、WRITEといったRPGのレコード操作命令によるデータ・アクセスがRLAに該当する。
2つ目がSQLアクセスである。図表7にあるとおり、SQLにはJDBCやODBC、OLE DB、DRDAなどさまざまな接続形態がある。これらでSQLアクセスした際には、IBM i 側ではホスト・サーバーに接続され、ホスト・サーバー・ジョブによってリクエストされたデータ処理が行われる。
以下にJDBC、ODBC、DRDAについてそれぞれ簡単に見ていこう。
JDBC
JDBC （Java DataBase Connectivity）ドライバーは、Javaアプリケーションがリレーショナル･データベースへアクセスするためのAPIを提供する。Db2 for i にJDBCでアクセスする際には、IBM i で提供するType2ネイティブ・ブリッジ・ドライバー、もしくはType4ネイティブ・プロトコル・ドライバーを用いる。
Type2ドライバーはOS固有のライブラリー （共有ライブラリー）を使って、RDBMSと通信する。この場合、アプリケーションはJDBCドライバーをロードし、JDBCドライバーは共有ライブラリーを使ってDb2 for i と通信する。そのため、Type2ドライバーはIBM i 同士の接続に利用できる。
一方のType4ドライバーは、データベース・サーバーに直接接続するJavaのみで実装されているので、OSに依存しない。そのため、異なるプラットフォーム間でのJDBCアクセスに利用できる。
IBM i ではType2ドライバーとして「IBM Developer Kit for Java JDBCドライバー」、Type4ドライバーとして「IBM Toolbox for Java JDBCドライバー」が提供されている。また、IBM Toolbox for Javaのオープンソース版であるJTOpenのType4ドライバーも利用できる。
図表8は、JDBCドライバーでDb2 for i に接続するイメージである。Db2 for i に接続するアプリケーションがIBM i以外のOSで稼働する場合には、IBM Toolbox for JavaもしくはJTOpenのType4ドライバー経由で接続され、Db2 for i 側としてはホスト・サーバー・ジョブQZDASOINITに処理が割り当てられる。
一方、アプリケーションがIBM i OSで稼働する場合で、IBM Developer Kit for JavaのType2ドライバーを利用するケースでは、Db2 for i 側ではホスト・サーバー・ジョブQRWTSRVRが割り当てられる。
Db2 for i 上にアプリケーションが同居し、ローカルでIBM Developer Kit for JavaのType2ドライバーでアクセスする場合には、QSQSRVRが割り当てられる。
ODBC
ODBC（Open DataBase Connectivity）は、マイクロソフトが制定したリレーショナル・データベースへのアクセス標準仕様で、Db2 for iに対するODBCドライバーは「IBM i Access Client Solutions Windows Application Package」に同梱されている。
またLinux用のODBCドライバーは同様に、「IBM i Access Client Solutions Linux Application Package」に同梱されている。図表9は、ODBC接続のイメージである。Db2 for i 側には、ホスト・サーバー・ジョブQZDASOINITが割り当てられる。
DRDA
DRDA（Distributed Relational Database Architecture）は、IBMが制定した異なるプラットフォーム上のアプリケーションとデータベース・サーバー間の通信を定義するアーキテクチャで、Db2 for i をはじめとするDb2ファミリーに実装されている。
DRDAでDb2 for i に接続するには、アプリケーション （データベース・サーバーから見るとクライアントになる）が稼働するプラットフォーム上に、Db2のクライアント・パッケージであるDb2 Connectを導入し、利用する。
DRDAで接続された処理は、Db2 for i 側ではホスト・サーバー・ジョブQRWTSRVRが割り当てられて処理される。
Db2 for iの運用管理
データベース・サーバーの運用管理項目の1つとして、バックアップ運用とログ管理がある。ここでは、Db2 for i でのバックアップ運用、ログ管理についてDb2 for LUWと比較しながら見てみよう。
バックアップ運用
Db2 for LUWでバックアップ運用の対象となるのはデータベース、表スペース、ログの3種類である。
データベース・バックアップは文字どおり、データベース全体のバックアップを取得する。表スペース・バックアップは個々の表スペース単位でのバックアップ、リストア、ロール・フォワードが可能となる。
一方、Db2 for i ではオブジェクト単位もしくはライブラリー （Db2 for LUWにおけるスキーマに相当）でのバックアップが可能であり、取得にはOS提供のSAVLIB、SAVOBJといった保管コマンドを使用する。
Db2 for LUWではデータベース・バックアップを取得することで、テーブル単位でのリストアが可能になるが、表スペース・バックアップからのテーブル単位でのリストアはできない。Db2 for i はバックアップの時点でオブジェクト単位に取得でき、テーブル単位でのリストアも可能である。
ログ管理
リレーショナル・データベースでのロギングは、データのロールバックやロール・フォワードに必要なデータの更新内容を保持するので、データの保全性を確保する際に重要となる。
Db2 for LUWのロギングの仕組みには、「データベース・ログ」と呼ばれるデータベース単位で開始するロギング機能がある。Db2 for LUWではログ領域のサイズをユーザー側で設定するが、余裕のあるサイズにしておく必要がある。短時間に大量の未コミットのトランザクションが集中した場合など、ログ領域が満杯になってログが書き込めないことに起因して、それ以上のトランザクションを処理できなくなるような事態を避けるためである。
一方、Db2 for i のロギング機能にジャーナルがある。Db2 for LUWのデータベース・ログはデータベース単位でロギングを実行するが、ジャーナルはテーブル単位でログ取得の有無を設定することが可能であり、データベース機能としてログ取得が必須ではない点もDb2 for LUWとは大きく異なる。
以上、Db2 for i のオブジェクト構成から運用管理、とくに回復管理項目であるバックアップ、ログ運用までを見てきた。Db2 for LUWと比較し、データベース・サーバーとしてアプリケーションのデータソースとなる機能については、当然ではあるが大きく異なる点は見られない。
ただし、構成や運用管理の面では大きな違いがある。この点が、OSと完全統合されたDb2 for i だけが備える特徴と言えるだろう。
著者
中村 陽一氏
日本アイ・ビー・エム
システムズ・エンジニアリング株式会社
AIソリューション
シニアITスペシャリスト
日本アイ・ビー・エム システムズ・エンジニアリング （ISE） 入社後、IBM i を主たる技術エリアとして活動。2010年に日本IBMへ出向中は提案局面における技術支援を担当。2013年にISEへ帰任後は、主としてプロジェクト実施局面における技術支援を担当、現在に至る。
［i Magazine 2020 Summer掲載］
特集｜あらためて知るDb2 for i
