索引と索引構成表
3 索引と索引構成表 この章では、表の行へのアクセスを高速化できるスキーマ・オブジェクトである索引と、索引構造に格納される表である索引構成表について説明します。 この章の内容は、次のとおりです。 索引の概要 索引構成表の概要 索引の概要 索引は、表または表クラスタに関連するオプションの構造であり、索引によってデータ・アクセスを高速化できる場合があります。表の1つ以上の列に索引を作成することによって、場合によって、ランダムに分散している行の小さなセットを表から取得できるようになります。索引は、ディスクI/Oを削減するための様々な手段のうちの1つです。 ヒープ構成表に索引がない場合、そのデータベースでは、値の検索に全表スキャンを実行する必要があります。たとえば、索引がない場合、hr.departments表の位置2700の問合せでは、データベースは、すべての表ブロックのすべての行でこの値を検索
索引構成表 - オラクル・Oracleをマスターするための基本と仕組み
索引構成表（IOT:Index Organized Table） 索引構成表 とは、簡単に説明するとデータ全体を最初から B-Tree インデックス に格納しているものである。表と主キーのインデックスとの共用体（⇔ C言語における構造体）になっているようなものである。 実際は B-Tree インデックスにはキーと ROWID が格納される程度なので、索引に入っているのではない。他のデータも入れることができるように拡張した表のことである。 通常であれば、表＋ 主キー（インデックス）の２つのデータ領域が必要なところを索引構成表のみで実現できるため Index Only Table と書かれたドキュメントもある。 通常表・ヒープ表 索引構成表と対比して、通常の表は「ヒープ表（Heap organized Table）」と呼ばれる形式であり、データの配置（並び順）についての 「しばり」 がないため
Reduce I/O with Oracle cluster tables
Reduce I/O with Oracle cluster tables Oracle Tips by Burleson Consulting Experienced Oracle DBAs know that I/O is often the single greatest component of response time and regularly work to reduce I/O. Disk I/O is expensive because when Oracle retrieves a block from a data file on disk, the reading process must wait for the physical I/O operation to complete. Disk operations are about 10,000 times
Oracle index blocksize tuning
Update: For the latest consensus on using multiple blocksizes in Oracle, see The latest consensus on multiple blocksizes. The benefits of a large blocksize The benefits of large blocksizes are demonstrated on this OTN thread where we see a demo showing 3x faster performance using a larger block size: SQL> r 1 select count(MYFIELD) from table_8K where ttime >to_date('27/09/2006','dd/mm/y 2* and tti
Use a large database block size
Because the database block size is fixed at database creation, this is one decision that is important to get right the first time. For file system based datafiles, without direct I/O, the database block size must match the file system buffer size exactly, as explained here. However, if your database is raw, or if direct I/O is available, then you have the luxury of choosing a larger database block
Oracle の B*Tree インデックスの内部構造についてお勉強中（その３）
このリーフは必ずソートされて状態で管理されているがために、データの挿入、更新でリーフ分割によるインデックスのパフォーマンス劣化が発生するわけです。また、この解析からわかるように同一ブロック内もしくは近くのブロック内には第一キーが同じものがかたまって存在します。それゆえ、複合索引の場合は、第一キーのみによる SELECT 文でも、効率よくアクセスが可能（ INDEX RANGE SCAN ）で、逆に第二キーのみによる SELECT 文では、いくつものブロックを読む（ INDEX SKIP SCAN もしくは TABE FULL SCAN ）必要がでてくるわけです。 見ての通り、同一ブロック内の第一キーの同一値がほぼ全て網羅されています。Oracle はブロック単位で I/O 管理されているため、上記の例だと where ID=1 のように第一キーの等価評価による絞り込みを行う場合、ブロックを
Oracle の B*Tree インデックスの内部構造についてお勉強中（その２）
まずは前エントリで書いた Oracle のインデックス構造図解を再掲から。 本題です。Oracle のインデックスの内容をダンプする TreeDump の使い方と解析方法について説明をします。これも定型文なので、覚えておいて損はないかと思います。特にインデックスに関して深追いするなら必須のテクニックです。参考にしたページは下記の２つです。 Bツリーインデックスに最高のパフォーマンスを（1/4） − ＠IT パフォーマンス劣化はインデックスのせいなのか!? をみっちり検証 − ＠IT 特に株式会社インサイトテクノロジーの記事が秀逸です。この会社の Oracle スキルは尋常じゃぁありませんね。お仕事で見ている DB システムでは、同社が開発している Performance Insight というツールを導入して Oracle を運用管理しているのですが、パフォーマンスチューニング、障害監視な
Bツリーインデックスに最高のパフォーマンスを
Bツリーインデックスの問題 更新が頻繁に起きるとどのようにインデックスが変化していくか、図5で見ていきましょう。 図5 更新が頻繁に起こるときのBツリーインデックスの変化 ※DBAの値として記載している「DBA1…」はアドレスを示す例である ※ROWIDの値として記載している「ROWID1…」はアドレスを示す例である 新規データである「18」は、空きリーフ行が存在していて既存データ「20」が入っているリーフではなく、リーフ分割し新規リーフ内に挿入されます。更新前データ「50」が存在していたリーフは完全に空きリーフとなってしまいます。このような更新が繰り返されると、リーフが散在することになります。前項で削除されたリーフ行の割合を見たとおり、削除されたリーフ行が大量に発生していくことになります。 Bツリーインデックスの問題解決 削除されたリーフ行が大量にあるインデックスを使って、SQLによる検
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
