~今回はデータベース・バッファのヒット率について検証してみる。一般的にデータベース・バッファのヒット率は最低でも90%を維持する必要があると言われている。ちなみに、ヒット率は以下の式で求めることが出来る。getsの値はv$buffer_pool_statisticsやv$sysstatから取得できる。9iの以下の環境で、検索条件を変えてヒット率を見ていこう。今回の検証はすべて、検索するデータをメモリ上に載せるために十分なデータベース・バッファのサイズを事前に設定している。----------------------------------------------------------------1.ブロックサイズが2Kと16Kのテーブルスペースを作成2.各テーブルスペースにテーブル名だけが違うまったく同一のテーブルを作成3.各テーブルに100万件のデータ(1レコード長の平均サイズは100バイト)を挿入----------------------------------------------------------------複数のテーブルスペースでブロックサイズが設定できる9iの新機能、マルチブロック・サイズを使用してブロックサイズが2Kと16Kの2つのケースでデータベース・バッファのヒット率を取得してみる。単純にフル検索を行なってみよう。Oracleを立ち上げて最初の検索なので、データベースバッファ上に検索対象のデータはまったく存在しない状態であり、一般的に考えるとヒット率が0であることが予想される。readsなどの統計情報を取得する。processed上記の結果からバッファのヒット率の状況を見る際には以下の点に注意する必要があると言えよう。getsの値にはデータブロック以外のデータも含まれる。readsの値をはるかに上回っていることが分かる。○ブロックサイズが大きい方がヒット率は一般的高い。readsの値が大きく違う。7815先程の検証結果はデータベースを立ち上げて最初の検索結果である。データベース・バッファ上にはデータは載っていないので、検索対象オブジェクト(short2,short16)のデータ自体のヒット率は0%と考えて間違いない。先程のヒット率を求める式に入れて、ヒット率を求めてみよう。89%ヒット率89%!!すべてのデータをフルスキャンしているにも関わらずヒット率が89%もあるように見えてしまうのである。ブロックサイズを16Kのように大きくしている場合は、データベース・バッファのヒット率を見る際に注意する必要があると言えよう。ブロックサイズが大きい場合にヒット率が著しく高いのであろうか?実はブロックサイズの違った時と同じ現象がブロックサイズ2Kだけの場合でも再現出来る。以下は1レコード長の違いによるヒット率の違いである。ブロックサイズは2Kで検証を行なっている。85.830*************************************************************1ブロックに1レコードしか格納できないレコード長(1621)の場合はヒット率は1%を下回っており、期待通り(?)の結果といえる。1ブロックに格納するレコード数が増加するにしたがってヒット率が高くなっている。先ほどはブロックサイズが16Kの場合で平均レコード長100バイトでヒット率を出したが、ブロックサイズ2Kの場合でも平均レコード長を100バイトの約7分の1にすることによってヒット率は16Kの場合と同じような高い値になることがわかる。的な処理で複数回アクセスした回数がカウントアップされているものと思われる。データベース・バッファのサイズを変更する場合は、単にヒット率を見るだけではなくその他の要因もみて、考える必要があると言えよう。インデックス検索の場合:ブロックサイズが2Kと16Kで、まったく同じインデックス検索を行なった場合のヒット率は以下の様になった。12.0%こちらもOracleを起動して最初の検索である。テーブルの全件検索の場合のヒット率に比べ著しく低い。同一のブロックへのアクセスが、1回のみ(1レコード)の場合が多い為であろうことが分かる。最後に9iからはバッファプールのヒット率の計算をする際に、ブロックサイズごとにヒット率を出すことが可能である。以下の様にv$buffer_pool_statisticsにはブロックサイズごとに、統計情報が格納されている。reserved.トップページ企業概要プライバシーポリシ。