Unofficial oninit blog

以前、Infromix Dynamic Serverが持つロック機能についての詳細な記事を紹介しました。

http://oninit.ti-da.net/e1260696.html

この記事は、onstat によるデッドロックの追跡方法など、実践的な内容になっているのですが、残念ながら現在のところ英語で書かれています。

一方で、1999年頃に公開された、もう少しアプリケーション開発寄りの日本語記事が以前から公開されています。

http://www-06.ibm.com/jp/software/data/informix/support/pdf/tnj99v8i1/chap02.pdf

これを久しぶりに読んで気づいたのですが、トランザクションやロックなどで良く使う、「アイソレーション・レベル」 ( Isolation Level ) の訳語が昔と今で違っていますね。昔のInformix製品の日本語マニュアルでは、「排他レベル」になっていました。一方で、最近の一般的なDBMS解説書では、「分離レベル」になっています。原語の意味に忠実なのは「分離レベル」です。IBMが公開している資料でも、DB2専用のものでは「分離レベル」が使用されています。開発ツール ( IBM Data Studio や Rational SDP など)でも「分離レベル」と呼ばれていることが殆どです。Informixで、SET ISOLATION文やSET TRANSACTION文で設定する「排他レベル」は、これら最近の資料では「分離レベル」と表記されています。

Informix関連の資料でも、今後「分離レベル」という言葉が使用あれることが増えてくると思います。覚えておくと混乱しないで済むと思います。

ちなみに、念のため、Isolation Level とは、あるセッションがデータを参照・更新している間に別のセッションが別のデータを参照・更新しようとした時、何処まで同時の参照や更新を許すか、という設定レベル。できるだけ許してあげた方が複数のアプリケーションの同時実行性が高くなり、ロックリソースなども少なくて済みますが、不正なデータや他方で更新確定前の古いデータが読めてしまう可能性も出てきます。

  

先日、IDS 9から10/11への移行時の注意事項についての記事を書きました。
http://oninit.ti-da.net/e1864915.html
その時、"Built-In UDT"という表記があり、それが何なのか謎でした。マニュアルを始めとする色々な情報源を見ると、IDS 9/10/11では、LVARCHAR, CLOB, BLOGなどのデータ型はユーザー定義データ型と同じような実装方法で実現されていることがわかりました。

そこで、上記の注意事項に戻りますが、この問題は、LVARCHAR, CLOB, BLOB等のデータ型の列にインデックスを作成してあった場合に、IDS9からIDS10へのコンバージョン後その表への更新や挿入などができなくなる、というものです。

IDS 9で、

CREATE DATABASE db;
CREATE TABLE t1 ( col1 INTEGER, col2 LVARCHAR(20) );
CREATE INDEX ix1 ON t1 ( col2 );
INSERT INTO t1 VALUES ( 1, "One" );

した後、このデータベースを含むインスタンスをIDS 10にコンバージョンします。IDSのバージョンが10.00.xC1/xC2の場合には、コンバージョン終了後に、

INSERT INTO t1 VALUES ( 2, "Two" );

などを実行すると失敗します。インデックスを再作成すれば解決できますが、IDS 10.00.xC3以降では、コンバージョン後、このようなデータベースを開いた時に自動的に対策が行われるようコードが追加されたようです。
ただし、この自動的な対策がアプリケーション運用後に動き出すとアプリケーションの運用に問題が出る可能性があります。従って、コンバージョン後クライアントアプリケーションの運用が始まる前に、すべてのデータベースをOpen/Closeしておきましょう、と言うのがリリース・ノートに書いてある注意書きです。
  

Informix Dynamic Server version 11のDevelopers Editionが公開されていますが、インストールや管理の方法を含む、さまざまなトピックについての資料を制作するWikiが公開されています。

http://www.informix-zone.com/idswiki/
  

Seti@homeは、私が知っている限り10年くらいInformixを使い続けています。以前はホームページにInformix社のロゴマークが表示されていたのですが、最近、Seti@HomeがBOINCのクライアントで動く新しい形式になってから、Informixは陰に隠れてしまっていますね。
でも、Technical Newsを見ると、MySQLなどと組み合わせて、現在でもInformixが使われていることがわかります。Informixと比べると、Optimizerへの対応など、MySQLではかなり苦労しているようです。このTechnical Newsの、昔の記事を読むと、かなり早い時代に当時のInformixの表の行数などの制限を超えてしまって対策をした話など、大規模なシステムでInformixを使う上での苦労話などがちらほらと書かれています。
最近の関心はレプリケーションのようです。
  

IDS 11.10.UC2のリリースノートを読んでいて発見したのですが、古いバージョンからIDS 10.00.xC3以降のバージョンに移行する場合、運用前にすべてのデータベースをオープンし、何もせずにクローズしておくことが推奨されているそうです。これは、障害番号172416に関する自動修正を起動させるためのものです。IDS V9でBuilt-in UDTに作成したインデックスが、IDS V10に移行した時に利用できない（AF)、という障害だそうです。IDS V10.00.xC1/xC2ではassertion faultになっていましたが、10.00.xC3以上では、データベースのオープン時に自動修正を起動するようになったとのことです。

運用が始まって、アプリケーションがデータベースを開いた時にこの自動修正が起動されると、並列実行性を損なうため、運用前の、クライアントからの接続が発生しない状態でこの処置をしておいてください、とのことです。多分 IDS 10.00.xC3以上のリリースノートすべてに書かれていると思いますが、気がつきませんでした。