・行連鎖が発生しているとCPUの使用率が高い次にUPDATE処理を行なってみる。処理としては、列(MOJIMOJI)の値([n*3199]→[z*3199])を更新する。5.8(0.3)全体的にselectを行なった結果と同じである。2回目(メモリ上にデータがある)検索では、若干ブロック・サイズ2Kの場合の処理が遅い。目立つのは、行連鎖が発生(ブロックサイズが2K)した場合のCPU使用時間である。行連鎖が発生していない場合の約3倍である。最後にINSERT処理を行なってみる。この処理に関しては実際に10万件のデータを作成した際の処理時間である。458.02(30.98)行連鎖が発生していた場合は、他のブロックサイズに比べて明らかに処理時間が遅く、CPU使用時間が高い事が分かる。大量のインサート処理のパフォーマンスはブロックサイズ16Kの場合が最も良い。○結局?インデックス検索(OLTP系の処理)では以下のことが言えよう。用率から見て最悪である。メモリ上にデータが載っている場合ではパフォーマンスは良い。メモリの容量に十分余裕のある環境では、ブロックサイズは大きめに取っても問題ない様に思える。反対にメモリの容量に余裕の無いシステムではブロックサイズを16Kと大きくした場合に、不必要なデータのディスクI/Oが行なわれ、パフォーマンスが悪いことが予想されるので、行連鎖が発生しない程度にブロックサイズは小さくした方が良いであろう。ブロックサイズ2Kの場合、つまり、行連鎖が発生している場合であるが、これに関しては、予想していたよりも、処理時間は遅くならないという結果であった。ディスクからの読み込みが発生する1回目の処理時間に関しては最も速いという結果である。CPU使用時間は高くシステムに負荷をかけている。・INSERT処理では:ブロックサイズが大きい場合の方がパフォーマンスが良く、ブロックサイズ2K(行連鎖が発生していた場合)で最悪である。○最後に4.)のブロックレベルでの競合であるが、別の機会を設けて検証したい。前回と今回の検証を通して言えることは、一度に大量のデータを処理するDSS系の処理様のオブジェクト(テーブル)では、ブロックサイズは大きい方が良く、一度に処理するデータが少なく、そのほとんどがインデックスを使用したランダムなアクセスが行なわれるオブジェクトはブロックサイズが小さい方が良いということである。Oracle9iからは一度作成したテーブルスペースのブロックサイズを変更するトランスポータブル表領域機能もあるので、オブジェクト(テーブルの)性質よって最適なブロックサイズを決定するべきであろう。次回は、データベース・バッファ上にあるデータについて見ていきたい。reserved.トップページ企業概要プライバシーポリシ。