連載
リーフ分割検証:意外と増えていたリーフブロック!:おら! オラ! Oracle再検証 @IT出張所(2)(1/4 ページ)
サイジングに頭を悩ませている技術者の皆さん、 インデックスのリーフ分割はどうして発生するのか、知りたくありませんか? 今回はリーフ分割の増え方を徹底的に検証します(編集部)
第1回「パフォーマンス劣化はインデックスのせいなのか!?」では、インデックスのリーフ分割について実際のデータを使用しながら解説しました。今回からはOracle Database 11gを使用して、インデックスのパフォーマンス劣化について再検証していきたいと思います。まずはパフォーマンスを検証するための検証環境を作成しましょう。
【環境】
Red Hat Enterprise Linux ES4 Update 5
Oracle Database 11g Enterprise Edition Release 11.1.0.6 - Production
Red Hat Enterprise Linux ES4 Update 5
Oracle Database 11g Enterprise Edition Release 11.1.0.6 - Production
検証環境作成の手順
では、早速環境を作成します。本記事では、以下のような手順でインデックス検索によるパフォーマンス劣化の環境を作成しています。
- 手順1:
10000010から10単位で増加させ、11000000までの計10万件を格納(末尾がすべて0) - 手順2:
10000001〜10999991までの末尾が1の値を10万件(増分10)を挿入し、以後、末尾が2〜9までの各10万件(増分10)を順に挿入し合計100万件のテーブルに拡張 - 手順3:
末尾0〜9のデータを削除(末尾9のみ10万件に対して、挿入した順に9万件削除)
手順1と2はリーフ分割を発生させるための手順で、手順3は空き領域を大量に発生させるための手順です。
表領域、テーブル、インデックス作成
それでは、実際に手順に沿って環境を作成しましょう。データ作成の前に表領域とオブジェクトを作成します。表領域はI/Oの負荷を計測するため、テーブルとインデックスをそれぞれ別に作成しています。
SQL> create tablespace ts_table datafile '/opt/app/oracle/oradata/ora11g/ts_table.dbf' size 200M; Tablespace created. SQL> create tablespace ts_index datafile '/opt/app/oracle/oradata/ora11g/ts_index.dbf' size 200M; Tablespace created.
表領域作成
SQL> CREATE TABLE INDEX_TEST 2 (EMPNO1 NUMBER(8), 3 EMPNO2 NUMBER(8), 4 ENAME VARCHAR2(10), 5 JOB VARCHAR2(9), 6 MGR NUMBER(4), 7 HIREDATE DATE, 8 SAL NUMBER(7,2), 9 COMM NUMBER(7,2)) 10 TABLESPACE TS_TABLE;
テーブル作成
SQL> CREATE INDEX IDX_INDEX_TEST ON INDEX_TEST(EMPNO1) 2 TABLESPACE TS_INDEX; Index created.
インデックス作成
Copyright © ITmedia, Inc. All Rights Reserved.