インデックス

<続・INDEXに関する検証 その5> ペンネーム モンキーターン 前回までのメルマガで、大量の削除処理によって INDEX内に空の BLOCKが数多 く発生し、空の BLOCKまでもがアクセスの対象となってしまう原因に

<続・INDEXに関する検証 その4> ペンネーム モンキーターン 前回は 10万件のデータの内、9万件削除した際のINDEX・キーが、Leaf_BLOCK 中で flag = Dと管理されている様子を見てきた。 今回は

<続・INDEXに関する検証 その3> ペンネーム モンキーターン 前回までの検証で、INDEXは削除されたデータを、flagを用いて管理している ことが分かった。 では、いつまで管理し続けるのであろうか? 結論から述べ

<続・INDEXに関する検証 その2> ペンネーム モンキーターン — UPDATEとINDEXの関係 — 前回のメルマガで INDEXキーを同一の値で UPDATEすると INDEXにどのような

<続・INDEXに関する検証 その1> ペンネーム つけまい&モンキーターン — UPDATEとINDEXの関係 — 以前、「おら!オラ! Oracle -どっぷり検証生活-」宛に、以下の質問が寄

<インデックスに関する検証 その8> ペンネーム つけまい — インデックス利用の落とし穴 レンジ検索で全件検索よりも性能ダウン — 前回、大量の削除処理によってインデックス内に空のブロックが数多

<インデックスに関する検証 その7> ペンネーム つけまい — インデックス利用の落とし穴 レンジ検索で全件検索よりも性能ダウン — 前回、インデックスに対して大量の削除処理を行った結果、全件検索よりもイ ンデッ

<インデックスに関する検証 その6> ペンネーム つけまい — インデックス利用の落とし穴 レンジ検索で全件検索よりも性能ダウン — ●インデックスが失速する? これまでの検索結果(1万件及び10

<インデックスに関する検証 その5> ペンネーム つけまい — インデックス利用の落とし穴 レンジ検索で全件検索よりも性能ダウン — 前回、TREEDUMPを基に、インデックスに対してどのようにア

<インデックスに関する検証 その4> ペンネーム つけまい — インデックス利用の落とし穴 レンジ検索で全件検索よりも性能ダウン — 前回、1万件のテーブルに対して、1~5000件目(半分)までの