SQL Anywhereのインストールと概要
（SQL Anywhere 11対応版）

SQL Anywhereの魅力を探る 2 改訂版

2.3 SQL Anywhereのアーキテクチャ

2.3.1 データベースのファイル構成

　データベースを構成するファイルには、(1)データベースファイル、(2)トランザクションログファイル、(3)テンポラリファイルの3種類がある（図2.7）。

図2.7 : データベースのファイル構成

データベースファイル（*.db）

　データベースファイルには、スキーマ、データ、インデックスなど、すべてのデータベース情報が記録される。デフォルトではデータベースファイルは1つだけだが、テーブルやインデックス単位でデータベースファイルを増やせる（上限は合計12ファイル）。次のような場合に複数のデータベースファイルを持つとよい。

1. ディスクI/Oの分散によるパフォーマンスの向上

　複数のディスク（HDD）があるとき、複数のデータベースファイルを用意して別々のディスクに配置すれば、データベースファイルへのディスクI/O（入出力）が分散されるので、パフォーマンスが向上する。

2. OSによるファイルサイズの制限

　通常、データベースファイルのサイズは、データが増えるに従って自動的に拡張されるので、日々監視するような必要はない。しかし、データ量が増えてデータベースファイルのサイズが大きくなり、OSのファイルサイズ制限にひっかかりそうなときは、データベースファイルを複数に分けてその制限を回避するとよい。

　なお、保存するデータ量があらかじめ把握できる場合は、データベースファイル作成時にファイルサイズを確保しておくことで、ファイルのフラグメンテーションの発生を抑制できる。

　SQL Anywhereのデータベースファイルやトランザクションログファイルの形式はOSによらず共通なので、ファイルをコピーするだけでデータベースを移行できる。たとえば、Windows CE上のデータベースファイルをWindowsにコピーしたり、Windows上のデータベースファイルをLinuxにコピーしたりすれば、移行先でそのデータベースを利用できる。

　それぞれのデータベースファイルは、1：1に対応するDBSPACE名で論理的に区別される。

データベース内のオブジェクトの種類

　データベースのオブジェクトには次のようなものがあり、これらすべてがデータベースファイルに保存される。

• テーブル
• 主キー、外部キー
• インデックス
• ビュー
• ストアドプロシージャ、トリガ
• ユーザ、グループ
• Javaオブジェクト

トランザクションログファイル（.log）

　トランザクションログとは、データがコミット（COMMIT）されるごとに記録されるログのことで、トランザクションログファイルに保存される。デフォルトでは、1つのトランザクションログファイルがある。設定により、トランザクションログなしで運用したり、（1つ増やして）2つのトランザクションログファイルを利用したりすることも可能だ。

　2つのトランザクションログファイルを利用したものを、トランザクションログミラー機能と呼ぶ。2つのファイルに対して同じログを同時に書き込み、冗長化することで耐障害性を高めている（トランザクションログミラーファイルの拡張子は.mlg）。

　一方、トランザクションログファイルを使わずにデータベースを運用することも可能だが、パフォーマンスや耐障害性の点から、トランザクションログファイルの利用を推奨する。

テンポラリファイル（.tmp）

　テンポラリファイルは自動的に作成・削除され、SQLによるデータのソートや結合処理でキャッシュが足りないときなどに利用される。テンポラリファイルが作成される場所は次の環境変数で指定できる。

1. SATMP
2. TMP
3. TMPDIR
4. TEMP

　これらの環境変数を順番に調べ、最初に定義されている場所が選ばれる。いずれも定義されていなければ、データベースサーバのカレントディレクトリが選ばれる。

　データベースやトランザクションログファイルと別のディスクにテンポラリファイルを配置すれば、ディスクI/Oが分散され、パフォーマンスの向上が期待できる。

2.3.2 データベースサーバの構成

　データベースサーバは、1つ以上のデータベースを管理できる（上限は255）。データベースサーバは1つのプロセスであり、クライアントからの接続処理、SQL文の解析や最適化、ファイルアクセスなどのすべての処理をマルチスレッドで実行する。マルチCPUに対応しているので、CPUの数を増やすことでパフォーマンスを向上させることができる（図2.8）。

図2.8 : データベースサーバの構成

SQL Anywhereのプロセスモデル

　SQL Anywhereのプロセスモデルは、1プロセス/マルチスレッドだが、さらにファイバと呼ばれる仕組みが利用されている。ファイバとは、カーネルスレッド内につくられたユーザレベルでの「軽量スレッド」である。ファイバ間でのコンテキストスイッチは、カーネルスレッドよりも軽いのが特徴で、SQL Anywhereの「軽さ」がこのような点からもみてとれる。

　データベースサーバには、次の2種類がある。

1. ネットワークサーバ
2. パーソナルサーバ

　ネットワークサーバは全機能を搭載している。一方、ネットワーク接続など一部の機能を制限したのがパーソナルサーバで、次のような制限がある。

• 同一マシンからの接続のみを受け付ける（ネットワーク接続不可）
• 同時接続は10台まで
• 1CPUのみ利用可能（マルチCPU機能には対応しない）

　このような制限があるため、パーソナルサーバはソフトウェア組み込み時や開発時などで使用されることが多い。

SQL AnywhereでのCPUの数え方

　SQL AnywhereでのCPUの数え方はいわゆるソケット単位であり、コア単位ではない。たとえば、デュアル・コアCPUやクワッド・コアCPUであっても1CPUである。

2.3.3 キャッシュ割り当て

　SQL Anywhereのプロセスは1つなので、考慮すべきキャッシュ領域も1つだけだ。デフォルトでは、SQL Anywhereのキャッシュサイズは自動的に増減する。データベース処理にもっとキャッシュが必要であれば増やし、必要なければ減らす。上限下限のサイズを指定することもできるので、その範囲内でサイズが調節される。なお、デフォルトの上限サイズは、Windowsでは256MBである。大量のメモリを使用可能なときは、データベースサーバの起動時に上限サイズを大きく設定するとよい。自動調整機能を使わずに、キャッシュサイズを固定することも可能だ。設定方法などについては、次回の「2.5 動的キャッシュ割り当て」で解説する。

次回

　次回は、データベースの作成・起動の方法や、ユーザ作成の方法について紹介する。社内評価や開発を目的としたSQL Anywhereの利用であれば、無償のDeveloper Editionを利用できるので、ぜひ一度、実際に試していただきたい。