コネクションの亡霊を切断！

開発中のプログラムで間違って無限ループを作ってしまったりすると、プログラムを停止した後も、データベースへのコネクションが「亡霊」のように残ってしまいます。これを放置すると、コネクションが大量に残ったり、データがロックされたままになったりと、やっかいなものです。この問題はOracleでもSQL Serverでも同じです。

Oracleでコネクションを切る場合には、V$SESSIONで確認した後に、ALTER SYSTEM KILL SESSIONで切断します。SQLServerの場合は、システムプロシージャの「SP_WHO」コマンドで接続中ユーザーの一覧を表示します。こうすると、たとえば「59番のコネクションが残っている」というような具体的な情報がわかるので、「Kill 59」と入力してコネクションを強制切断すればよいのです。

亡霊セッションがロックしていたから動かなかった、なんてことがないようにSP_WHOとKILLを覚えておきましょう。

■ 「SP_WHO」コマンドで接続中ユーザーの一覧を表示

1レコード8060バイトの壁

SQL Serverでは、一行のデータサイズは8060バイトを超えることができません。この制限に気づかないで、考え込んでしまう初心者はよくいるもの。文章を登録するプログラムでは、１レコードが8060バイトを超えることもありがちです。

気をつけるべきところは、「8060バイトを超えるレコードを定義することはできる」という点です。たとえば以下のようなテーブルは作成できます。

このテーブルに対して小さい論文をたくさん登録するような場合に、「あるレコードにINSERTはできるが、追記していったら突然エラーになった」という形で初めてこの制限を知るケースがあるようです。

このテーブルはNVARCHARで4260文字ですから、合計8520バイトのレコードができるわけです。NVARCHARは可変長ですから、本文が短ければ何も問題はありません。しかし、全列に最大文字数を入れることはできません。入れようとすると以下のエラーが出ます。

「1 行のサイズ 8335 が許容最大値 8060 を超えているので作成できません。」

TEXT型などの大容量データタイプを使えば、この制限は越えられますが、TEXT型はWHERE句の条件に指定できないなどの制限がありますから、全文検索を利用することはできません。この制限を十分に考慮して設計すべきでしょう。

ロックエスカレーション機能

Oracleは行単位のロックが確保されています。どれだけロックが増えても行単位でロックが確保される分、ロックが多いときにはリソースを消費します。SQL Serverも基本は行ロックですが、システムのリソースが少なくなると、複数の行ロックを1つのテーブルロックに切り替えることで、メモリを開放しようとします。これは、「ロックエスカレーション機能」と呼ばれています。

SQL Serverでは、ロックの単位は、行、テーブル、インデックスのページ単位と、粒度の違うロック方式を選んで使えるようになっています。SQLヒントを指定して明示的にロックを選択できます。

ロックがエスカレーションすると、１ユーザーのロック範囲が広がるために、アプリケーションの同時実効性が失われていきます。とはいえ、よほどリソース不足にならない限りエスカレーションはおきませんから、同時ロック数の少ないアプリケーション設計を心がけるべきでしょう。