SAP SQL Anywhere Tips – アップグレードの種類

本ブログでは

本ブログではSAP SQL Anywhere のバージョンアップグレードについて解説します。
一言に「アップグレード」と言ってもSAP SQL Anywhereでは3種類（段階）のアップグレードが存在します。どのアップグレードを現段階で用いるべきか、アップグレードに対してのシステムダウン時間も考慮して選択が必要です。

アップグレードの対象

SAP SQL Anywhereのアップグレードを行う場合、アップグレードの対象は通常下記になります。

• • データベースエンジン（dbsrvXXやdbengXXなどの実行ファイル類）
  • データベースファイル

（その他にMobile Link等もありますが、今回は含めません。Mobile Linkのアップグレードに関しては別のエントリで解説したいと思います。）

このアップグレード対象の組み合わせをSAP SQL Anywhere選択することが出来ます。それに対してのメリット・デメリットの本ブログの主旨となります。

エンジンのアップグレード

まず、SAP SQL Anywhereのデータベースファイルは上位互換性が存在します。古いバージョンで作成されたデータベースファイルは新しいバージョンでも使用することが出来ます。例えばVer.12のデータベースファイルはVer.17（のエンジン）でも使用する事ができます。これを利用して「データベースエンジンだけのアップグレード」が可能です。

この方法は簡単で、単に上位バージョンのデータベースエンジンで古いバージョンで作成されたデータベースファイルを指定して起動するだけです。現在12を動作させているマシンであれば17をインストールして

のようにdbsrvXX/dbengXXをそのバージョンに変更すれば良いだけです。

*同一のマシンに複数のバージョンのSQL Anywhereを導入することは問題ありません。また、ディフォルトではインストール先は「C:\Program Files\SQL Anywhere 17」のようにメジャーバージョンを含んだものになっています。そのため例えば12が入っているマシンに17をインストールしても上書きインストールはされず12と17の併用が可能となっています。

この方法のメリットとデメリットは以下になります。

データベース（ファイル）のアップグレード

こちらの方法は先のエンジンアップグレードの一つ上位の方法となります。現在のデータベースファイルのシステム部分をアップグレード先のバージョンにアップグレードします。アップグレード方法は「エンジンアップグレードを行った上で」下記の方法で行います。

この方法のメリット・デメリットは以下となります。

追記：dbupgradユーティリティは一つ前のバージョンのデータベースファイルのみ対応では有りません。前述の9と10の間ではデータベースファイル構造の互換性打ち切りの問題があり使用できませんが、それ以降であれば下位バージョンのデータベースファイルに対して適用できます。例えば、バージョン17のdbupgradユーティリティはバージョン10以降のデータベースファイル全てに対して適用可能です。11→12→16→17と上位バージョンを一つ一つ適用する必要はありません。

完全なアップグレード（データベースの再構築）

完全なアップグレードはデータベースファイル自体を新しいバージョンで作成し、新しいバージョンのエンジンで動作させます。これは一旦データをアンロードし、同一構造のスキーマ（テーブルなど）を構築した空の新しいデータベースに再ロードさせるという手順を取ります。下記の方法で行うことになるでしょう。

注意点としてはdbunloadは必ずバージョンアップ先の新しいバージョンで行うようにしてください。「dbunload -?」でヘルプとともにバージョンが表示されます。もし、古いバージョンや違うバージョンが表示されるようでしたら、フルパスをつけてdbunloadを実行するか適切にパス設定をする必要があります。

メリットとデメリットは以下になります。

データベースの再構築を行うというのは時間がかかる作業です。しかし、再構築でデータがデータベースファイル内でも場所が固まることによりパフォーマンスが改善する事があります。

使用できる機能・出来ない機能

上の説明で「新バージョンの機能を一部利用できる」という説明がありました。これは「新機能」でも

• • エンジンのアップグレードだけで使用できる機能
  • データベースファイル内のシステム部分が新しいバージョンになっていれば（新しいエンジン上で）使用できる機能
  • データベースファイル自体が新しいフォーマットになれば（新しいエンジン上で）使用できる機能

の3種類が存在します。どの機能がどのアップグレードで使用できるかは、SAP SQL Anywhereのマニュアルの「SQL Anywhere – 変更点とアップグレード」で解説されています。

Ver.17：http://dcx.sap.com/index.html#sqla170/ja/html/6ba43b1c99a141ca92be602eedc6369d.html

Ver.16：http://dcx.sap.com/index.html#sa160/ja/sachanges/sachanges16.html

Ver.12.0.1：http://dcx.sap.com/index.html#1201/ja/sachanges/sachanges12.html

この中で、説明文に「データベースのアップグレードが必要」とあればデータベースアップグレードが必要であり「データベースの再構築が必要」とあれば再構築を行わなければその機能は使用できません。

まとめとアップグレード戦略

3つのアップグレードを表にまとめてみました。

実際お客様はどのアップグレードを利用されているかですが、やはり「完全なアップグレード」が最終的な目標となります。但し、アップグレードの際に作業時間を取れないということで「データベースアップグレード」までを一時的に行い、後ほど時間が取れる時にデータベース再構築を行い完全なアップグレードにするというケースも見られます。

エンジンアップグレードは本番環境においては行われることはほとんど無く、アプリケーション開発者様がアプリケーションの互換性確認のためにエンジンだけをアップグレードしてアプリケーションのテスト工程を通してみるという使われ方をされます。

3種類のアップグレードは段階的に行うことが出来ますので再構築にどのくらい時間がかかるかを考慮し、アップグレード計画を行うようにしてください。

補足：クライアントのアップグレード

クライアントに関してはSQL Anywhereクライアントは上下2（メジャー）バージョンの互換性チェックが行われています。例えば12クライアントは17サーバーに接続可能ですし、17クライアントでも12サーバーに接続可能です。ただし完全な互換性はありません。例えば新しいデータ型は古いクライアントでは使用できないということがあります。

*SAP SQL Anywhereはバージョン13,14,15が忌み数字とマーケティングの理由から欠番です。12の上は16、その上が17となりますので12⇔17は2バージョンの互換性範囲内となります。

一般的な考え方として、クライアントとサーバーのバージョンは合わせるのが良いです。
次点ではサーバーバージョン（新）＞クライアントバージョン（古）とすべきです。
例えばVer.12でアプリケーション使用していた場合、アプリケーション＆クライアントはそのままで、サーバーだけをVer.17にするというのは戦略として有りです。これは動作の互換性の問題は起きにくいでしょう。但し、この際にVer.17前提の機能をアプリに追加するというのは問題が複雑化するので行わないほうが良いです。アプリケーションを更新する際に一緒にクライアントもVer.17に変更するというほうがトラブルは避けられるでしょう。

クライアントのバージョンアップは使用するクライアントの種類によりアプリケーション側は何もしなくて良いときと、コードの修正が必要な場合に分かれます。例えばODBCドライバであればODBCデータソースを作り直しで良いです。C++ライブラリであれば新バージョンのライブラリを使用して再ビルドが必要でしょう。.NETの場合はVer.17でiAnywhere.Data.SQLAnywhereネームスペースからSap.Data.SQLAnywhereネームスペースに変更になりましたのでソースコード側に変更が必要となります。（殆どの場合文字列置換で可能です。）