CompressionテーブルにUpdateした時のテーブルのサイズが拡張した原因について調査し、行移行が関係していることがわかりました。行移行先のブロックには、2048bytesのうち1129bytesしか格納されておらず、残りの919bytesに何が格納されているのかわからないまま前回は終わりました。今週は、この919bytesに何が格納されているかについて確認します。Compressionまとめ1.919bytesの正体それでは早速、919bytesに何が格納されているかについて調査していくことにしましょう。いうものの、ダンプに出力されていた行情報には何か余計に情報が格納されているような記述は見当たりません。いうことは、ヘッダーに何か格納されているのでしょうか?っと、ブロックダンプのヘッダー部分を眺めていると、不自然な箇所を発見しました。0x0000.00000000Itlが「0x01」から「0x24」まで合計36行取得されています。Listの略で、トランザクションがブロック内のデータを更新する際に更新情報を格納する為に必要な領域のことを言います。トランザクションごとに確保される領域なのですが、何故か36行もあります。この環境にアクセスしているのはクリープ以外いません。試しに別テーブルを作成し、1行ずつ行移行を発生させてダンプを取得してみた所、Itlが1つずつ増加していくのが確認できました。:このことから、行移行が1つ発生するごとにItlが1つ確保されるようです。このItlが、サイズ拡張に影響してそうです。Itlの情報1行に対してどれぐらいの領域を確保しているのでしょうか?Itlについて調査してみると、以下マニュアルにItlのサイズに関する記載がありました。概要(11gリリース1)より======================================================================トランザクション・エントリに必要な領域は、オペレーティング・システムによって異なります。======================================================================ここでいうトランザクション・エントリがItlのことで、Itlが1つにつき約23bytes確保されるということになります。ちなみに、マニュアルにはオペレーティング・システムで異なる、とありますが、今回検証しているLinux環境では24bytesになります。この値は、ブロックヘッダーに関する以下情報から確認することができます。14ここに「KTBIT」という項目があり、この24bytesがトランザクション・エントリで確保される領域になります。864で、このブロックには864bytesがItlの領域として確保されている、ということがわかりました。行移行するだけで1行あたり24bytesも無駄に領域を使用してしまう、ということになり、このことがテーブルサイズを3倍以上に拡張した要因といえます。ちなみに、不明だった919bytesのうち864bytesについてはわかりましたが、残りの55bytesは何が格納されているのでしょうか?これについては、おそらく、Itlに関連する情報が格納されていると類推してますが、残念ながら確認することができませんでした。Compressionに対するUpdate処理によりサイズが拡張してしまった原因は大きく以下3つによることがわかりました。Compressionテーブルに対してUpdate処理は実行しない方がよい、ということが言えます。Compressionテーブルに対するUpdate処理で圧縮が実行されなかったのでしょうか?Oracleのサポート情報をみると、Update処理で圧縮されないのはOracle11.1.0.6の仕様(もしくは不具合)とありました。Update処理では現行の最新バージョンである11.1.0.6では圧縮されません。仕様ということであれば、トランザクション処理などでこの圧縮テーブルを利用するようなケースは激減してしまいます。仕様ではなく不具合ということで次バージョンで改善されることを祈りましょう。同様圧縮処理が実行されるようなことはないのでしょうか?念のため検証で確認してみることにしましょう。4.Update処理でも圧縮される?それでは、検証してみることにしましょう。今回の検証は、PCTFREE以外の空き領域を残した状態でデータをInsertします。その後で、空きがなくなるようなUpdate処理を実行してデータが圧縮されるかどうかを確認してみることにします。それでは、ブロックを空き領域がなくなる直前の状態にしてみましょう。縮処理が実行されました。域がなくなる直前の状態ということになります。域を更新して、圧縮処理が実行されるかどうかを確認してみましょう。operations;ちなみに、上記テーブルではmsgカラムのサイズが10bytesです。今回Insertしたデータも10bytesなのでUpdateでサイズを大きくすることができません。msgのサイズを10bytesから20bytesに変更してUpdateでサイズが拡張するようなテーブルで作成しましょう。completed.テーブルが作成されました。データも90行挿入しています。ブロックダンプを取得してブロックの空きを見てみましょう。tosp=0xd8ダンプファイルを見ると13行目にavspが0xd8とあります。avspは空き領域のサイズなので、10進数に変換すると216bytesの空きがあることになり、当メルマガ第7回の圧縮直前のサイズと同じになります。行して20bytes拡張させます。圧縮処理が実行されるかもしれません。いうことで確認してみることにしましょう。tosp=0xc4avspをみると、0xc4と10進数で196bytesになってしまいました。1」が存在していないことから、圧縮されなかったようです。end_of_block_dumpやはりUpdateでは圧縮されないのでしょうか?もう少し多くの行をUpdateしてみたら圧縮されたりして!?さらに、追加で10行をUpdateしてみることにします。tosp=0x60avspが0x60、10進数で96bytesまで小さくなってしまいました。圧縮されないようです。ついでに96bytesの空きがなくなるようにさらに10行をUpdateしてみましょう。@0x549nridという行の出力から行移行が発生してしまい、圧縮は実行されませんでした。仕様!?によりUpdateでは圧縮されないようです。Compressionの検証を行ってきました。効ですが、Updateで圧縮されないのでは、使用されるシーンが大幅に限られてしまいます。Compressionの検証を終わりにします。11.1.0.7はいつリリースされるのでしょうか。reserved.トップページ企業概要プライバシーポリシ。