本ブログでは
本ブログでは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（のエンジン）でも使用する事ができます。これを利用して「データベースエンジンだけのアップグレード」が可能です。
上位互換性に関しては一点注意が必要です。それはVer.9とVer.10の間で互換性が一旦打ち切られています。9と10をまたいたアップグレードの場合は後述の「完全なアップグレード」が必要です。 |
この方法は簡単で、単に上位バージョンのデータベースエンジンで古いバージョンで作成されたデータベースファイルを指定して起動するだけです。現在12を動作させているマシンであれば17をインストールして
dbsrv12 <options> <dbfile>
↓
dbsrv17 <options> <dbfile> |
のようにdbsrvXX/dbengXXをそのバージョンに変更すれば良いだけです。
*同一のマシンに複数のバージョンのSQL Anywhereを導入することは問題ありません。また、ディフォルトではインストール先は「C:\Program Files\SQL Anywhere 17」のようにメジャーバージョンを含んだものになっています。そのため例えば12が入っているマシンに17をインストールしても上書きインストールはされず12と17の併用が可能となっています。
この方法のメリットとデメリットは以下になります。
メリット：
- 新バージョンの機能を一部気軽に利用できる
- バージョンアップが（後述と比べると）短時間で済む
- バージョンの機能の互換性に問題があっても、前のバージョンに戻すことができる
デメリット：
- 新バージョンの機能や恩恵を完全に利用できるわけではない。（後述と比べても一番数が少なくない）
|
データベース（ファイル）のアップグレード
こちらの方法は先のエンジンアップグレードの一つ上位の方法となります。現在のデータベースファイルのシステム部分をアップグレード先のバージョンにアップグレードします。アップグレード方法は「エンジンアップグレードを行った上で」下記の方法で行います。
この作業を行う場合は必ずデータベースのバックアップを取得した上で行ってください。
コマンドライン：
dbupgrad -c "connection-string"
SQL Central/Sybase Central：
データベースアップグレードウィザードを使用
＊データベースアップグレードウィザードが存在しないバージョンがあります。その場合はコマンドラインで行ってください。
|
この方法のメリット・デメリットは以下となります。
メリット：
- 新バージョンの機能を一部利用できる（エンジンアップグレードより多い）
- バージョンアップが（後述と比べると）短時間で済む
デメリット：
- バージョンの機能の互換性に問題があっても、前のバージョンに戻すことができる
- データベースファイルを前のバージョンで動作させることができなくなる（バックアップを使用するしかない）
|
追記：dbupgradユーティリティは一つ前のバージョンのデータベースファイルのみ対応では有りません。前述の9と10の間ではデータベースファイル構造の互換性打ち切りの問題があり使用できませんが、それ以降であれば下位バージョンのデータベースファイルに対して適用できます。例えば、バージョン17のdbupgradユーティリティはバージョン10以降のデータベースファイル全てに対して適用可能です。11→12→16→17と上位バージョンを一つ一つ適用する必要はありません。
完全なアップグレード（データベースの再構築）
完全なアップグレードはデータベースファイル自体を新しいバージョンで作成し、新しいバージョンのエンジンで動作させます。これは一旦データをアンロードし、同一構造のスキーマ（テーブルなど）を構築した空の新しいデータベースに再ロードさせるという手順を取ります。下記の方法で行うことになるでしょう。
この作業を行う場合は必ずデータベースのバックアップを取得した上で行ってください。
コマンドライン：
dbunload -c "connection-string" -an <新しいDBファイル名>
SQL Central/Sybase Central：
データベースアンロードウィザードを使用
|
注意点としてはdbunloadは必ずバージョンアップ先の新しいバージョンで行うようにしてください。「dbunload -?」でヘルプとともにバージョンが表示されます。もし、古いバージョンや違うバージョンが表示されるようでしたら、フルパスをつけてdbunloadを実行するか適切にパス設定をする必要があります。
メリットとデメリットは以下になります。
メリット：
副次的メリット：
- データベースファイルのフラグメントの解消
- インデックスの再構築なども同時に行える
デメリット：
- 大きなデータベースの場合、アンロードと再ロードに時間がかかる
- 一時的とはいえ古いバージョンのデータベースと新しいバージョンのデータベースで2個出来ることになるのでその分のディスクスペースが必要
- データベースファイルを前のバージョンで動作させることができなくなる（バックアップを使用するしかない）
|
データベースの再構築を行うというのは時間がかかる作業です。しかし、再構築でデータがデータベースファイル内でも場所が固まることによりパフォーマンスが改善する事があります。
テクニックの一つとして、SAP SQL Anywhereの特徴の一つであるファイルコピーでデータベースは移動できるという点を利用し、データに更新日時などのカラムが存在している場合、実際のアップグレード日より前に別マシンでバックアップを利用してデータベースの再構築を行い、アップグレード日当日はバックアップ日から当日までの差分のみをアンロードしロードするという方法もあります。これを利用すれば実際の停止時間は少なくすることも出来ます。 |
使用できる機能・出来ない機能
上の説明で「新バージョンの機能を一部利用できる」という説明がありました。これは「新機能」でも
- エンジンのアップグレードだけで使用できる機能
- データベースファイル内のシステム部分が新しいバージョンになっていれば（新しいエンジン上で）使用できる機能
- データベースファイル自体が新しいフォーマットになれば（新しいエンジン上で）使用できる機能
の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ネームスペースに変更になりましたのでソースコード側に変更が必要となります。（殆どの場合文字列置換で可能です。）
