ページ」にも特定の順序はない。ページ)」ではポインタとして行識別子(ファイルID、ページID、行ID)を格納しており、その行識別子を使って「ヒープ」へジャンプし、検索対象データを探し出す。ページ」であるが、「ポインタ」として「行識別子」ではなく「クラスタ化キー」の値を格納している。ページ」で取得した「クラスタ化キー」の値を使用して「クラスタ化インデックス」を検索する。「非クラスタ化インデックス」のキーを使用して「クラスタ化インデックス」のキーのみ取得する場合は、非常に高速。インデックス」は、以下により性能の向上が期待できる。LookUp?をせずに処理が可能となる。インデックス」が作成できる。下記DDLで、「付加列インデックス」が作成できる。ページにのみ含められる。BY句を使用した集計処理で指定されるキーの選択度が高い(若しくは一意の)場合は、性能向上は期待できない。更新処理が頻繁なビューに対して「インデックス付きビュー」を作成すると余計にコストがかかる場合があるので注意する。「インデックス付きビュー」の更新が行われた場合、基テーブルも更新される。「インデックス付きビュー」は、FROM句で「インデックス付きビュー」を直接指定していないクエリからも、オプティマイザにより、使用されることがある。テーブル」とすると、さらにクエリ速度、効率を高められる可能性がある。選択度が高い項目を検索条件に使用する場合に有用である。これとは逆に、選択度の低い項目では不利になることが多い。キーなど)選択度が低い=重複が多い。「非クラスタ化インデックス」は、選択度の低い項目に対しては不利である。スキャン」した場合を考える。ページ」に対して、最大で1000回ものI/Oが発生する可能性がある。「クラスタ化インデックス」は、選択度の低い項目に対して"も"有効である。スキャン」した場合を考える。「クラスタ化キー」の値(この場合、"男性"、"女性")毎にデータがまとまっているため、"男性"社員情報を読み込むページ数は最小化され、I/O回数も最小化される。ページ」を直接スキャンすることができる。最小で13回のI/Oで読み取りが完了する。ディスクI/Oを、ディスク上管理単位である「エクステント」単位で処理する。†なお、選択度の低いデータでは、どちらのインデックスでも、データの挿入時に、「ページ分割」が発生しやすくなり、不利である。「「インデックスの断片化」の管理」で説明する。アクセス」)の効率データ更新時の「ページ分割」のオーバーヘッドのトレードオフを考慮する形になる。物理的な「エクステント」から構成される。「セグメント」とは、テーブル、インデックスといった、オブジェクトを意味する。ディスクI/Oを、ディスク上管理単位である64KBの「エクステント」単位で処理する。「エクステント」は、メモリ上の管理単位である8KBの「ページ」から構成される。「ページ分割」が発生し、一部の「ページ」が、別の「エクステント」に格納されることがある。「ページ分割」により新しい行を挿入する余裕を作り出す。この作業にはコストがかかるため、DBサーバ全体のパフォーマンスを低下させる。ページ」の「ページ分割」が進んだ状態を指す。別の「エクステント」から断片化した「ページ」を取得するという余分なI/Oが発生する。一般的に、この状態はセグメント(テーブル、インデックス)を「再構築」することで解消できる。「インデックスの断片化」による余分なI/Oの発生に繋がる。このため、なるべく「ページ分割」が発生しないようにする必要がある。更新と挿入が頻繁に行われる予定のテーブルや、インデックスには「ページ密度」を低く設定し、データの増加に対応する空き領域を残しておく。「ページ密度」は、テーブル、インデックスの生成時に設定することができる。以下のトレードオフを考慮し、「ページ密度」を決定する必要がある。読み取りページ(エクステント)数を減らすことができる。「ページ密度」は、「FILLFACTOR」オプションで設定することができる。INDEXDEFRAG」ステートメントのオプションで指定できる。ページ」の「ページ密度」を制御する。場合によっては「FILLFACTOR」を変更することでさらにパフォーマンスが高まる。INDEX」のステートメントのオプションで指定できる。ページ」の「ページ密度」を制御する。「PAD_INDEX」は「FILLFACTOR」が指定されている場合にのみ有効になる。