1」に行データが格納されています。0」に圧縮された値が格納されなくなっている、ということのようです。18」とあり、圧縮前の18bytesで格納されていることからも確認することができます。この行から格納パターンがかわっています。rowidのことで、行移行先のアドレス情報が格納されています。ここにある「0x0100326c」ですが、後ろ4桁がブロックIDを表しており、「.0」はブロックの行番号を表しています。12908となり、ブロックIDが12908の行IDが0にデータが移行した、ということになります。移行先のデータはどのように格納されているのでしょうか?きっとここを見れば、テーブルサイズが3倍以上に拡張した原因がわかるはずです。いうことで、移行先のブロックダンプも取得して中身を確認してみることにしましょう。3.移行先ブロックのダンプ早速、移行先のブロックダンプを取得します。altered.これで、nridに記載されたブロックのダンプファイルが作成されました。出力されたダンプファイルの中身を見てみましょう。1」に非圧縮データが格納されているはずです。いうことは、このブロックは圧縮データが格納される構成になっていない、つまり通常のテーブルの構成、ということになります。行移行先のデータまでは圧縮されないみたいです。24」とあり、1行で24bytes格納されていることがわかります。行移行してない行のサイズは18bytesでしたので(元ブロックのダンプ3行目を参照)、通常時より6bytes余計に格納されていることになります。この6bytesに何が格納されているのでしょうか?参照元のブロック(データが元々格納されていたブロック)では、格納されている行の情報がbindmpに出力されていたのですが、参照先(行移行先)は通常テーブルの構成の為bindmpが出力されていません。この為、どのようなデータが格納されているかを知ることはできませんが、恐らく、1行下にhrid(headrowid)という行があり、参照元の情報が出力されていることから、参照元のブロックIDと行IDが格納されていると類推できます。2343KBとなります。CompressionテーブルのUpdate後のサイズである7006KBとは約2700KB近くの差があることになります。いうことはつまり、サイズが拡張してしまう要因は他にもあると考えられます。33」とあり、このブロックに34行しか格納されていないことがわかります。照)、その格納行数が大幅に少なくなってしまっていることがわかります。いうことは、このことがテーブルサイズが3倍以上にも拡張してしまった大きな要因といえそうです。こんなにブロックに格納される行数が少ないのでしょうか?ブロックの空きを大きめに確保したりしてるのでしょうか?「avsp」の値を確認してみましょう。tosp=0xe3上記をみると、avspの値は「0xe3」となっています。「0xe3」は10進数では227なので、227bytesの空きがあるということになります。227bytesという空きは、PCTFREEで確保された10%の空き領域とほぼ同じであることから、このブロックに新しい行を格納する空き領域はほとんどない状態であるといえます。このブロックには行データが816bytes(1行当たり24bytesの行が34行)、ブロックヘッダーが86bytesで、227bytesの空きと合わせると合計1129bytesになります。1ブロックは2048bytesなので、残りの919bytesに通常のブロックにはない何らかの情報が格納されており、このことがテーブルサイズが3倍以上に拡張した大きな要因になっていると考えられます。この919bytesにはどのような情報が格納されているのでしょうか?疑問を残したままさらに次週に続く。テニスの錦織選手が全米オープンベスト16の快挙!インサイトテニス部もこれに続いて。reserved.トップページ企業概要プライバシーポリシ。