ロックに関する検証　その９

～ロックに関する検証　その９最終回～
ペンネーム　ちゃむ

前回は、ビットマップ・インデックスの構造を理解した上で、ビットマップ・
インデックスが作成してあるテーブルの、ロックの範囲に関して検証した。
気持ち的には、ビットマップ・インデックスの構造や特徴を、もっと掘り下げ
て解説したいところであるが、それはまたの機会にしよう。

今回は、PCTFREEとトランザクションエントリの関係を探ってみよう。
以下に、1000行のテーブルをPCTFREE 0を指定して作成するスクリプトを用意し
た。このテーブルの、インサート処理によって行がフルに詰まっているブロッ
クに対して、UPDATE処理を行ってみよう。

SQL> UPDATE EMP_F0 SET ENAME = 'OSAMU' WHERE EMPNO = 1 ;

1行が更新されました。

セッションBより次の行を更新

SQL> UPDATE EMP_F0 SET ENAME = 'OSAMU' WHERE EMPNO = 2 ;

1行が更新されました。

セッションCより次の行を更新

SQL> UPDATE EMP_F0 SET ENAME = 'OSAMU' WHERE EMPNO = 3 ;

「待たされているよ～～～～～～～～～～」

1行当たりのバイト数にも依存するが、以下のように、2行更新しただけでロッ
ク待ちしてしまうオブジェクトもある。これは、更新するバイト数にも依存す
るが、PCTFREEを 0 に設定した場合は、殆どが同一ブロック内で取得できる行
ロックの数が、1行か2行であった。

SQL> UPDATE DEPT_F0 SET DNAME = 'OSAMUBU' WHERE DEPTNO = 1 ;

1行が更新されました。

SQL> UPDATE DEPT_F0 SET DNAME = 'OSAMUBU' WHERE DEPTNO = 2 ;

「待たされているよ～～～～～～～～～～」

以前、initransに関して検証を行ったが、initransで指定した数は、事前にト
ランザクションエントリの領域を固定的に確保するためのものである。initrans 4
と指定すれば、ブロックの中の行の密度がどうであれ、同一ブロックの行に対
して、最低でも、同時に4つのトランザクション処理が行えることを意味する。

PCTFREEとは、トランザクションエントリのためだけの領域でなく、行を更新し
たときに、カラム（レコード）長が更新前より長くなってしまうような場合、
行移行（1行が複数のブロックにまたがってしまうこと）しないように、ある程
度ブロック内の空領域を確保しておくためにも使用される。

maxtransは、トランザクションの上限を決めるだけで、実際には、トランザク
ションエントリがいくつまで確保されるかは、PCTFREE、INITRANS、ブロック中
の行の密度、更新後の行データの拡張される度合いなどに依存する。

しばらくの間「ちゃむ」は、メルマガをお休み（充電期間）させていただきま
す。次回からは、久々に「つけまい」がREDOログについて熱く語る予定です。
引き続き、「おら！オラ！ Oracle – どっぷり検証生活 – 」を、何卒、何卒、
よろしくお願いいたします。

以上茅ヶ崎にて

ロックに関する検証 その９