4. 下位互換性が復活
バージョン10で作成したデータベースがある場合は、リビルドしなくても、SQL Anywhere 11でそのデータベースを実行できます。非常に大規模なデータベースでは、この機能が重要です。時間がかかるうえに不可逆のリビルドを行わなくても、バージョン11でデータベースのテストを開始できるからです。
バージョン10の導入時に驚いたのは、それ以前のバージョンで作成されたすべてのデータベースのリビルドを要求されたことです。バージョン9までは、古いデータベースファイルを使用できるのが当たり前で、たとえバージョン5.5で作成したデータベースでもそのまま使用できました。バージョン10でその互換性の道が絶たれたわけですが、それにはもっともな理由がありました。その理由とは、データベースエンジンから大量のレガシーコードを追放すること、コードのメンテナンス作業をなくすこと、それによって生まれた時間をもっと重要な分野（例えばクールな新機能の習得など）に費やすことです。
バージョン11で新しい互換性の道が開かれました。10から11への移行ではリビルドは必要ありません。それより前のバージョン、例えば9から11へ移行する場合などは、相変わらずリビルドが必要です。
もう1つ重要なことがあります。パフォーマンスを重視する場合は、10から11に移行すると決定した後、直ちにリビルドを行った方がよいでしょう。バージョン11で導入された新しいデータベースファイル形式の利点を活かすには、完全なアンロードとリロードを実行するしかありません。
5. Perl、PHP、C#、VBでのストアドプロシージャ
SQL Anywhere 11では、9つの言語でストアドプロシージャを書けるようになりました。Perl、PHP、C#、Visual Basicが追加され、Java、C、C++および2つのSQL言語（ANSI/WatcomとTransact）が引き続きサポートされます。実際、使える言語の数は9より多いかもしれません。例えば、Fortranの.Net 2.0 CLRバージョンも機能するはずです。ただし、Tech Support Languageの担当者が言う「機能するはず」という言葉は、「実際に試すのはあなたが最初かもしれませんが」という意味であると覚えておいた方がいいでしょう。
ストアドプロシージャについてのサポートの詳細は言語によって異なります。例えば、VBは結果セットを返せるのに対して、PerlはLONG VARCHAR文字列しか返せません。
特筆に値するのは、非SQL言語で書かれたプロシージャをデータベースサーバ自体から完全に独立した実行可能環境で実行できるようになったことです。これはつまり、プロシージャがクラッシュしても、その道連れでデータベースがダウンするおそれはないということです。この場合も詳細は言語によって異なります。例えば、Perlでは接続ごとに1つの外部環境が設定されますが、VBではデータベースごとに1つの外部環境しか開始されません。表1はさまざまな言語でのサポートの違いをまとめたものです。
| 1つの外部環境が設定される単位 | プロシージャが返せるもの | |
| Perl | 接続 | LONG VARCHAR |
| PHP | 接続 | LONG VARCHAR |
| C#、VB | データベース | 結果セット |
| Java | データベース | 結果セット |
| C、C++ | 接続 | 結果セット |
| SQL | なし | 結果セット |
さまざまな言語で書かれたプロシージャを安全に呼び出せる機能は、それ自体をトップ10のリストに入れてもいいくらい素晴らしいものです。以前は、CやC++のプロシージャがデータベース内部で実行されており、コードが暴走すると、1つのユーザー接続がダウンするだけでなく、サーバがクラッシュして全員が被害を受けるという壊滅的な結果が生じました。
もう1つの朗報は、非SQL言語で書かれたプロシージャの内部で現在のデータベース接続を使用できるようになったことです。つまり、プロシージャを呼び出したデータベースにSQL文を渡すために新しい接続を開始する必要がなくなったのです。以前のバージョンでは、CまたはC++のストアドプロシージャの内部からSQL文を発行することは一切できず、新しい接続を開始したくても開始できませんでした。現在は、すべての言語で同一接続によるデータベースアクセスが可能です。
これはクールな機能です。例えば筆者は、データをやり取りする際の手間を減らすために、データベースに埋め込みたいコードを山ほど持っています。1つの例はファイル比較ユーティリティ用のAPIです。データベース内にBLOBとして保存されるドキュメントに対して使用する比較ユーティリティ用のAPIをデータベースに埋め込み、SQL Anywhereの組み込みHTTPサーバを使って、ブラウザからのWebサービス呼び出しを介して比較結果を表示できるようにすることを考えています。
6. インメモリサーバモード
インメモリサーバオプションは、耐久性を犠牲にして挿入と更新の速度を向上させるまったく新しい動作モードです。「SQL Anywhere Classic」モードでデータベースを作成してロードした後に、そのデータベースを「Never Write（非書き込み）」または「Checkpoint Only（チェックポイントのみ）」という2つのインメモリモードのどちらかで実行できます。2つのインメモリモードを切り替えたり、Classicモードに戻したりするには、エンジンを停止してから再開します。ソフトウェア自体は同じで、使用するコマンドラインパラメータが異なるだけです。
読者が混乱しないよう先に説明しておきますが、SQL Anywhere 11は、MySQLのMyISAMのような非トランザクション型・自動コミット方式のストレージエンジンのようなものを採用しているわけではありません。SQL Anywhereは完全にリレーショナルなデータベース管理システムであり、完全なトランザクション型で、インメモリモードで動作しているときでさえ、ほとんど完全にACIdを実現しています。
ACIdとは、トランザクションに求められる4大要素であるAtomic（原子性）、Consistent（一貫性）、Isolated（独立性）、Durable（耐久性）を意味しています。耐久性とは、COMMITに永続性があることを意味しています。筆者がACIdの「d」を小文字にしている理由は、Checkpoint Onlyインメモリモードでは、コミットされたすべてのトランザクションが最後のチェックポイントまで保存されますが、そのチェックポイントを超えるフォワードリカバリが不可能だからです。さらに、Never Writeインメモリモードでは、その名のとおり何も保存されず、リカバリも不可能です。
インメモリモードが効果を発揮するのは、データベースのRAMキャッシュがデータベース全体を保存するのに十分なほど大きい場合か、大量の挿入、更新、コミットを実行している場合、あるいは速度を大幅に向上させるために多少の安全性を犠牲にすることを厭わない場合です。筆者の考えでは、このモードが威力を発揮するのは継続的モニタリングのようなアプリケーションです。つまり、短期間に大量のデータを受信し、クラッシュ時にデータの完全復旧を保証することよりも入力のスピードに追いつくことの方が重要であるアプリケーションが最有力候補です。
どちらのインメモリモードでもキャッシュ内のデータを更新できます。つまり、Never Writeモードは読み取り専用を意味しているわけではありません。Checkpoint Onlyモードでは、更新されたデータがCHECKPOINTでデータベースファイルに書き込まれます。Never Writeモードでも、永続性を重視するのであれば、データを保存できます。データの保存を迅速に行うには、データベースバックアップ、データベースアンロードユーティリティ、個別のUNLOAD TABLE文の3つの方法があります。表2はNever WriteモードとCheckpoint Onlyモードの比較、および2つのモードとClassicモードとの比較を示しています。
| -imnw Never Write | -imc Checkpoint Only | Classic | |
| トランザクション型 | ○ | ○ | ○ |
| .dbファイルの更新 | × | ○ | ○ |
| トランザクションログ | × | × | ○ |
| 一時ファイル | × | × | ○ |
| チェックポイントログ | × | ○ | ○ |
| チェックポイント | × | ○ | ○ |
| ダーティページフラッシュ | × | ○（a） | ○ |
| 無制限拡張 | × | ○（b） | ○ |
| リカバリ | × | ○（c） | ○ |
- （a）ダーティページはチェックポイントでのみフラッシュされます。
- （b）一時ファイルがない場合、キャッシュが満杯になるのを防止する手段はチェックポイントに限られます。
- （c）クラッシュ後の再起動では、最後の有効なチェックポイントまでの通常の自動リカバリが実行されますが、トランザクションログがない場合、最後の有効なチェックポイントからコミットされた最後のトランザクションまでのフォワードリカバリを実行することはできません。
