はじめに
昨今、SAP SQL Anywhereの価値が再評価され、旧来のハンディターミナル内や中小規模向けアプリケーションの他にIoTのエッジで使われるという用途が増えてまいりました。SAP SQL Anywhereは旧サイベース（日本ではアイエニウェアソリューションズ株式会社）からの歴史がある製品ですが、本ブログでは初めて触られる方へも開発や運用の上でポイントとなる部分を参考情報へのリンクも交えながら包括的にご紹介し、参考になればと考えています。
この製品は「製品組み込みで使用されていた」という特性上、現在でも古いバージョンを使われている方もいらっしゃるかと思いますので、Ver.9までの古いバージョンに関しても触れたいと思います。上位バージョンであればより簡単にできるようになったというものもありますのでバージョンアップのご参考にしていただければ幸いです。
２つのデータベースエンジン
SAP SQL Anywhereには2つのデータベースエンジンが含まれています。これはプロセス名でいうと
dbengXX
dbsrvXX
（XXにはバージョン名の数値が入ります。Ver.9であればdbsrv9/dbeng9 , Ver.17であれdbsrv17/dbeng17となります。）
となります。これはそれぞれパーソナルエンジンとネットワークエンジンと呼ばれます。
dbengXX：パーソナルエンジン
dbsrvXX：ネットワークエンジン |
この2つのエンジンは機能的に「ネットワーク接続が可能か？」という違いがあります。
パーソナルエンジンはその名称の通りパーソナル、つまり個人的な用途を想定したエンジンのため、「SQL Anywhereデータベースを動作させているマシン上からのみ」接続が可能な仕様です。共有メモリ接続のみサポートしていますので他のマシンから接続を行うことが出来ません。このデータベースエンジンはSQL Anywhereをローカルのデータストアとする用途で使用されます。
ネットワークエンジンはネットワークで使用されることを想定したエンジンです。一般的な「データベースサーバ」と言えばこちらを指します。このエンジンはインストールしたマシン以外からの接続を受け付ける機能が搭載されています。
ネットワークエンジンはネットワーク接続機能をオフにすることが出来ますのでパーソナルエンジンとしても使用することが出来ます。逆にパーソナルエンジンはネットワーク接続機能自体がプログラムに含まれていませんのでネットワーク上のデータベースサーバとして使用することが出来ません。
また、名称の通りで個人用途と多人数用途の違いから、メモリ系や同時実行数などの設定値ディフォルト値が異なっていることも注意が必要です。が、データベースエンジンとしての機能的な違い、ネットワークエンジンで動作させていたあるSQL文がパーソナルエンジンでは動作しないという事はありません。殆どのアプリケーションでは接続方法を変えるだけでパーソナルエンジンでもネットワークエンジンでも動作します。
データファイル
SQL Anywhereデータベースを構成するファイルは最低2つです。これは
です。.dbのファイルはデータが格納されているファイルで一般に「データベースファイル」と呼ばれます。.logのファイルは挿入更新削除のログ,いわゆるトランザクションログが蓄積されるファイルで「ログファイル」と呼ばれます。
データベースファイルは最大13個まで使用可能（つまりは12個追加できる）で、テーブルを作成するときにどのDB領域に配置するかの設定が出来ます。これを利用して違うディスクにアクセス頻度の高いテーブルを配置することによりI/O分散を行い、パフォーマンスを向上させることが出来ます。
なお、データベースを作成するときに生成される最初の1つ目のデータベースファイルは「system」というDB領域名称から「システムDB領域」、あるいは「メインデータベースファイル」と呼ばれ、そのデータベースが持つメタデータなどはこのデータベースファイルに格納されます。このファイルはSQL Anywhereにとって必須のファイルです。
SQL Anywhereの特徴としてこのデータベースファイルとログファイルはOS/プラットフォームに依存しません。例えば手元のWindows PCで作成・使用しているデータベースファイルとログファイルはそのままコピーすることで本番で使用するLinuxサーバで使用することが出来ます。その逆も可能です。この特徴を利用することで、データベースを含んだアプリケーションを配布するときはテーブルなどを作成済みのDBファイルとバックアップを取得し最小化（トランケート）したログファイルをそのままコピーすることで配布が可能です。
バージョンに関しても上位互換性があります。Ver.16のデータベースファイルとログファイルはVer.17でも何もせずそのまま利用できるのです。注意点としては以下があります。
- 下方互換性はない。（例：Ver.17のDBファイル＆ログファイルはVer.16では使用できない）
- 上位バージョンで新規提供される一部の新機能やパフォーマンス向上は上方互換動作では使用・恩恵をうけることができない。
- Ver.9とVer.10の間には上位互換性はない。
- これはVer.10でデータベースファイルとログファイルの構造がこれまでと大幅に変わったためです。Ver.9以前のデータベースをVer.10以降で使用するにはデータベースの再構築が必要になります。
バージョンアップに関しても次回以降のブログで触れたいと思います。
ログファイルの扱い
ログファイルはデータベースに対し挿入更新削除など変更を与える操作のログが蓄積されます。書き込みが多いデータベースの場合、このファイルは頻繁に書かれることになります。書き込み先となるデータベースファイルとログファイルが同じディスクにあることはパフォーマンス上のリスクとなります。このファイルの位置はdblogコマンドで移動することができます。（データベースが停止していることが必要です。）
dblog -t <新しいログファイル> <DBファイル>
例： dblog -t E:\logfile\testdb.log D:\dbfile\testdb.db
|
このファイルはバックアップからのリカバリーにおいても使用されます。データを変更する操作の履歴が書き込まれていますのでバックアップ時点のDBファイルにこのログの内容を適用することで（ログファイルが保有している）最新時点までリカバリすることができます。この考え方からするとログファイルはデータベースファイルと同じ場所に配置することはディスクが破損した場合を考えるとよくありません。可能な限り別のディスクに置いたほうが良いです。また、このファイルはミラーログとしてSQL Anywhere側の機能で２か所に出力することもできます。それを利用すればより強固となります。勿論ハードウェアによるディスクミラーリングを使用してもよいでしょう。
開発や運用においてのトリビア的なものですが、実はトランザクションログファイルから実行したDML（SQL）をテキストで出力することもできます。前述の通り書き込み系の文だけなのですが、dbtranコマンドで行うことが出来ます。
dbtran <ログファイル> <出力先ファイル>
例： dbtran testdb.log testdblog.txt
|
実行したSQLを記録する方法は他にもあり、そちらのほうが便利なのですが、dbtranコマンドを紹介したのは、実は唯一この方法のみが「事前に設定が不要」なためです。ログファイルさえあればデータに影響を与えた書き込み系のコマンドを後から確認することが出来ます。他の方法は事前に記録する事を設定しておく必要があります。但し上記のdbtranでは取得できないSELECT文実行時間の計測などもっと便利な機能がありますので
次回はこの「他の方法」に関しては解説したいと思います。
まとめ
エンジン、データベースファイル、ログファイルがSQL Anywhereデータベースを構成する基本要素となります。特にパーソナルエンジンとネットワークエンジンは混同しやすいので気をつけてください。
