パフォーマンス劣化はインデックスのせいなのか!? をみっちり検証
リーフブロックの中に格納されている値とは？ それでは、実際にリーフブロック-1と0にはどのような値が格納されているのか、ブロックの中身を確認してみることにしましょう。 ブロックの中身は、以下コマンドで確認できます。 SQL> SELECT DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(16831123) as "FILE_ID(LEAFBLOCK-1)", 2 DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(16831123) as "BLOCK_ID(LEAFBLOCK-1)", 3 DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(16831262) as "FILE_ID(LEAFBLOCK0)", 4 DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(16831262) as
Oracleパフォーマンス障害の克服（3）Bツリーインデックスに最高のパフォーマンスを―@IT
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。（編集局） SQL処理（インデックス）にかかわる確認 前回「ロックをつぶせ！最初に疑うべき原因」では、SQLにかかわる問題の解決方法としてロックの確認方法を説明しました。データ更新には必ずオブジェクトの処理が行われていることを理解できたと思います。 SQL文をきっかけに更新されるOracleサーバ内のオブジェクトとして、今回はインデックスを取り上げます。SQL文発行時、直接データとのかかわりを意識しづらいオブジェクトなので、データの更新頻度やインデックスの作り方によ
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 を運用管理しているのですが、パフォーマンスチューニング、障害監視な
Oracle の B*Tree インデックスの内部構造についてお勉強中（その１）
お仕事のデータベース一式のリース切れ間近ということで、リース延長で耐えることができるのか、それともシステム更改が必要なのかを見極めるため、最近はデータベース周りのチューニングばかりやってます。 当初設計時に、５年間持つ設計をしたのですが、流石に５年目にもなると予定とはそれなりに乖離が発生するものです。テーブル＆インデックス設計をユーザ向けの処理をとにかく高速に処理できるように設計したので、ユーザ向けの処理は速度的に全然大丈夫なのですが、データの肥大化によるバッチ処理のパフォーマンス劣化が顕著です。単純にストレージと CPU パワーが足りていないのでしょう。 しかしながらチューニングの余地はまだまだ十分にありそうです。バッチ向けの最適化を図ることにしました。うまくいけば来年度どころか、後数年はリース延長で延命できるかもしれません。 今回実施したチューニングの１つのポイントとして、バッチ処理向
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
