英語でOracle!

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　英語で　Oracle！ #037 2007/02/13
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今までの目次です。
http://imoment.blogspot.com/2006/11/toctable-of-contents.html

おはようございます。
マイミクさんから教えてもらったのですが、
you tubeで千手観音という中国の素敵な演舞を見ました。
美輪明宏さんが号泣されたということもうなづける内容でした。
なんとメンバー全員が視聴覚になんらかの障害を持っているとか！
http://www.youtube.com/watch?v=1sh6RzzMrcw
(ご覧になる時は是非音声込みで)

引き続きRichard FooteさんのIndex Rebuildに関するプレゼン資料を
ご紹介します。（今回で最終回です）

前回までの内容は

1.導入、B-tree Indexの基礎、Clustering Factor、Fast Full Scanの説明
2.Indexブロック分割、PCTFREE、PCTUSED、FREELISTの説明
3.Index削除領域の再利用について、遅延ブロッククリーンアウトの説明

でした。各ページはお手数ですが目次経由で表示してください。

※残り２回の予定でしたが、ちょっと無理目に押し込んで今回で最終回にしました。

※Index用語に慣れていない方は、先にoracle解説のコーナー（前号までも含む）で
　知らない用語について確認されるといいかもしれません。


■ askTomでのIndex Rebuildに関するdiscussion
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2913600659112

※今回は引用PDFを紹介している適切なサイトが無いので、
　その資料について触れているaskTomのdiscussionをリンクとして
　ご紹介します。

■ 引用PDFファイル
http://www.actoug.org.au/Downloads/oracle_index_internals.pdf

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記事本文
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Index Height - Rebuild Factor ?

. The simple answer is no
. Most index rebuilds do not result in a height reduction
. If the pct_used is high, rebuild is pointless
. If index creeps over height boundary, rebuild is still
　pointless as:
　- Instead of reading root, now read root + branch resulting in
　- just 1 additional cached I/O
. Index eventually will grow anyways
. Rebuilding an index purely because of its height is yet
　another myth


◆ Conditions for Rebuilds

. Large free space (generally 50%+), which indexes rarely reach, and
. Large selectivity, which most index accesses never reach, and
. Response times are adversely affected, which rarely are.
. Note requirement of some free space anyways to avoid insert and
　subsequent free space issues
. Benefit of rebuild based on various dependencies which include:
. Size of index
. Clustering Factor
. Caching characteristics
. Frequency of index accesses
. Selectivity (cardinality) of index accesses
. Range of selectivity (random or specific range)
. Efficiency of dependent SQL
. Fragmentation characteristics (does it effect portion of index frequently used)
. I/O characteristics of index (serve contention or I/O bottlenecks)
. The list goes on and on ….


◆ Other Rebuild Issues To Consider

. More efficient index structures can reduce stress
　on buffer cache. Harder to formulate but
　requires consideration
. If you have the resources and you have the
　appropriate maintenance window, then the cost
　vs. benefit equation more favorable to rebuild
. Benefit maybe low but perhaps so is the relative cost
. Rebuild or Coalesce ?


◆ Index Coalesce

. More efficient, less resource intensive, less
　locking issues than rebuild option
. Can significantly reduce number of leaf blocks in some scenarios
. Requires sum of free space to exceed 50% +
　pctfree in consecutive leaf blocks
. However, as generally needs excessive 50%+
　freespace for rebuild to be effective
. Does not reduce index height

　alter index bowie_idx coalesce;


◆ Summary

. The vast majority of indexes do not require rebuilding
. Oracle B-tree indexes can become “unbalanced” and
　need to be rebuilt is a myth
. Deleted space in an index is “deadwood” and over time
　requires the index to be rebuilt is a myth
. If an index reaches “x” number of levels, it becomes
　inefficient and requires the index to be rebuilt is a myth
. If an index has a poor clustering factor, the index needs
　to be rebuilt is a myth
. To improve performance, indexes need to be regularly rebuilt is a myth


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語の解釈
※自然な語順で解釈する癖をつけるために敢えて不自然な日本語に
　なっているところがあります。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Index Height - Rebuild Factor ?
　 indexの高さはrebuildの要因になるか？

. The simple answer is no

　シンプルな答えはnoです。

. Most index rebuilds do not result in a height reduction

　ほとんどのindex rebuildはindexの高さを減らしません。

. If the pct_used is high, rebuild is pointless

　もし、pct_usedが高い場合、rebuildは無意味です。

. If index creeps over height boundary, rebuild is still
　pointless as:

　もし、Indexが現在のIndexの高さの限界に近づいている場合、
　rebuildは以下のようにやはり無意味です


　- Instead of reading root, now read root + branch resulting in
　　just 1 additional cached I/O
　　rootブロックを読む代わりに、rootブロックとブランチブロックを
　　読むことになります。結果として１回のキャッシI/Oが追加されるだけです。


　- Index eventually will grow anyways
　　Indexはどちらにしてもいずれ成長します(高さが上がります)。

. Rebuilding an index purely because of its height is yet
　another myth

　単純にIndexの高さに伴ってrebuildを実施することは
　やはり誤った考えです。



◆ Conditions for Rebuilds
　 Rebuildの条件

. Large free space (generally 50%+), which indexes rarely reach, and
　大きな空き領域（通常50%以上）(Indexがこの値に他することはほとんどありません)
　そして。。。

. Large selectivity, which most index accesses never reach, and
　高い選択性(ほとんどのIndexアクセスが決して満たしません)
　そして。。。

. Response times are adversely affected, which rarely are.
　応答時間が悪影響している場合（あまりないですが）

. Note requirement of some free space anyways to avoid insert and
　subsequent free space issues
　心に留めてください、空き領域の要件は
　とにかく挿入や後続する空き領域問題を避けるためであることを（心に留めてください）

. Benefit of rebuild based on various dependencies which include:
　Rebuildの利点は以下を含む様々な依存関係があります

　- Size of index
　　Indexサイズ

　- Clustering Factor
　　クラスタリングファクター

　- Caching characteristics
　　キャッシング特性

　- Frequency of index accesses
　　Indexのアクセス頻度

　- Selectivity (cardinality) of index accesses
　　Indexアクセスの選択性（カーディナリティ)

　- Range of selectivity (random or specific range)
　　選択性の範囲（不規則または特定の範囲）

　- Efficiency of dependent SQL
　　依存SQLの効率

　- Fragmentation characteristics (does it effect portion of index frequently used)
　　フラグメンテーション特性（Indexで頻繁に利用される部分に影響するかどうか？）

　- I/O characteristics of index (serve contention or I/O bottlenecks)
　　IndexのI/O特性（I/O競合またはI/Oボトルネックを助ける）

　- The list goes on and on ….
　　この一覧は延々と続いきます。。。


◆ Other Rebuild Issues To Consider
　 考慮すべきその他のRebuild問題

. More efficient index structures can reduce stress
　on buffer cache. Harder to formulate but
　requires consideration
　より効率の良いIndex構造はバッファキャッシュへの圧迫を軽減します
　明確に説明するのは難しいですが、考慮が要求されます。

. If you have the resources and you have the
　appropriate maintenance window, then the cost
　vs. benefit equation more favorable to rebuild
　もし資源を持っていて、適切なメンテナンス時間を持っているなら、
　費用対利益の定式の結果はよりRebuildしやすい値になるでしょう。

　- Benefit maybe low but perhaps so is the relative cost
　　利益は少ないかもしれませんが、関連するコストも低いかもしれません。

. Rebuild or Coalesce ?
　Rebuild または 結合?


◆ Index Coalesce
　 Indexの結合

. More efficient, less resource intensive, less
　locking issues than rebuild option
　Rebuildに比べ、より効率的で、より少ないリソース集中で、競合問題をより少なくします

. Can significantly reduce number of leaf blocks in some scenarios
　場合によっては多くのリーフブロックを減らすことができます。

. Requires sum of free space to exceed 50% +
　pctfree in consecutive leaf blocks
　隣り合ったリーフブロックのpctfreeの空き領域の合計が
　５０％を超えている必要があります。

. However, as generally needs excessive 50%+
　freespace for rebuild to be effective
　しかしながら、Rebuildが効果的になる為には、
　一般的には５０％を遥かに超える空き領域が必要です。

. Does not reduce index height
　Indexの高さは減少しません。

　alter index bowie_idx coalesce;


◆ Summary
　 まとめ

. The vast majority of indexes do not require rebuilding
　圧倒的大多数のIndexはRebuildが不要です。

. Oracle B-tree indexes can become “unbalanced” and
　need to be rebuilt is a myth
　OracleのB-tree Indexがアンバランスな状態になり、
　Rebuildが必要になるという教えは誤りです。

. Deleted space in an index is “deadwood” and over time
　requires the index to be rebuilt is a myth
　Index内の削除された領域は無用で、
　一定期間毎にRebuildが必要になるという教えは誤りです。

. If an index reaches “x” number of levels, it becomes
　inefficient and requires the index to be rebuilt is a myth
　もし、Indexが一定のレベルに達した場合、非効率になり、
　Rebuildが必要になるという教えは誤りです。

. If an index has a poor clustering factor, the index needs
　to be rebuilt is a myth
　もし、Indexのクラスタリングファクタが悪い場合、
　Rebuildが必要になるという教えは誤りです。

. To improve performance, indexes need to be regularly rebuilt is a myth
　パフォーマンスを向上させるために、定期的なRebuildが必要という教えは誤りです。


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
単語解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

Index Height:第1回のOracle解説のB-Tree欄参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html

pct_used:第2回のOracle解説欄参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index_22.html

creep:(気づかれないように)忍び寄る、忍び寄り(名詞)

root + branch:第1回のOracle解説のB-Tree欄参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html

eventually:ついに、最終的には、ようやく

purely:単純に、純粋に

condition:条件

adversely:ネガティブだったり有害だったりする影響

subsequent:後続の

based on:～に基づいた

Clustering Factor:第1回のOracle解説参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html

selectivity:選択性、全体の行に対してIndexによって特定できる行数の割合
　　　　　　（ある列値の特定で限られた行を特定できる場合、
　　　　　　　その列のselectivityは低いと言えます）

cardinality:集合の中の要素の種類の数。cardinalityが低い時、
　　　　　　selectivityは高くなります。
　　　　　　例えば列の値が男と女の２種類しかない場合、
　　　　　　cardinalityは2です。
　　　　　　通常はcardinalityではなく、cardinality度数（全体行中の要素数の割合）
　　　　　　を参考にします。

specific:特定の

efficiency:効率

portion of:一部分の

serve:役立つ、仕える、給仕する

on and on:(うんざりするほど)延々と、長い間、

formulate:詳細な計画を立てる、（系統立てて）明確に説明する、方式やシステムを考案する

resource:資産、（価値のある）人材や組織

maintenance window:保守をする為の時間枠(windowは窓の他に時間枠の意味も持っている)

cost vs. benefit equation:費用対利益の定式

relative:関連/関係する

coalesce:結合
※発音(kou(e)le's:cぁLe'S)

intensive:集中的な、徹底的な

leaf block:第1回のOracle解説のB-Tree欄参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html

pctfree:第2回のOracle解説欄参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index_22.html

consecutive:連続した

Index height:第1回のOracle解説のB-Tree欄参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html

vast majority:圧倒的多数

Oarcle B-tree Index:第1回のOracle解説のB-Tree欄参照
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html

deadwood:枯れ木、無用な、お荷物な


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
★ 英語ぷちクイズ ★

※答えと思うリンクをぷちっとクリックしてください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

☆「チャック開いてますよ」って言いたい時に一番使わないフレーズは？

◆Your barn door is open
┗ http://clickenquete.com/a/a.php?M0002066Q0019492A16c50
◆XYZ
┗ http://clickenquete.com/a/a.php?M0002066Q0019492A29b75
◆Your fastener is open
┗ http://clickenquete.com/a/a.php?M0002066Q0019492A3c8a3
◆You are flying low
┗ http://clickenquete.com/a/a.php?M0002066Q0019492A4cf8d
◆Your zipper is open
┗ http://clickenquete.com/a/a.php?M0002066Q0019492A51040
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019492C633e

締切：2007年02月18日23時00分
協力：クリックアンケート http://clickenquete.com/

こたえは次回に発表します。


■　前回のこたえ

☆どちらが理想的でしょうか。

◆to study English.
◆to learn English.
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019367C983d

studyはテキストや学校の授業に沿って勉強するというイメージです。
learnは主に実際の経験を伴って、原則として達成も伴う学習を意味します。
どちらが理想と考えるかは人それぞれとは思いますが、
普通に考えるとlearnでしょうか。
学校で勉強しているだけならstudy、それ以上に色々努力しているなら
learnを使用すると良いですね。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
Oracle解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
footeさんが過去の有識者の【うそ】を証明するために様々な角度から
Indexの動作を解説してくれました。

【うそ】

OracleのB-tree Indexは時間が経つとアンバランスになり、Rebuildが必要
Deleteが繰り返されると無駄な領域が増えるのでやがてRebuildが必要
Indexのレベルがあるレベルに達すると、非効率になるのでRebuildが必要
Clustering Factorが悪くなるとRebuildが必要
パフォーマンス向上の為にIndexのRebuildが定期的に必要

以下のような【おすすめ】を参考にしながら、
今後のOracle管理に役立てていきたいですね。

【おすすめ】

Rebuildを検討する前にcoalesceを検討しましょう。
以下のケースに該当する場合、Rebuildを検討する価値があります。

・永続テーブルの収縮
・特定のIndex値を激減させるdeleteまたはupdateの発生
・単調に増加するIndex値および削除
・大規模な同一値のIndexエントリが削除された場合

Index Rebuild編もこれで終了です。
辛抱強くお付き合いいただきありがとうございました。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
編集後記
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今号からご購読いただいた皆様はじめまして。
本日も最後まで読んでいただきありがとうございます。

blog上でAdsenseというgoogleの広告サービスを使用しています。
原則としてそのページに合っている広告が表示されるので、
私のページには主にOracle関連、英語関連が表示されます。

そんな中で時々以下のような異色の広告が表示されるんです。

切れないそば打てますよ！そばアカデミー
http://soba.specialist.co.jp/academy/
=>何故そば？

Oracleのど飴
http://www.oracle.vc/index.html
=>かなり笑いました。


それではまた。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
おわりに
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記述誤りなどのご指摘、
記事に関する疑問点・質問・感想・ご意見・ご感想など
yakusa_oracle@yahoo.co.jpまでお願い致します。

簡単な自己紹介はこちら
http://pr2.cgiboy.com/S/3191274

バックナンバー兼ブログはこちら
http://imoment.blogspot.com/

登録・解除はこちらから
http://www.mag2.com/m/0000200441.htm

Posted by yaksa at 1:09 午前 | Permalink | Comments

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　英語で　Oracle！ #036 2007/02/05
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今までの目次です。
http://imoment.blogspot.com/2006/11/toctable-of-contents.html

おはようございます。
嫁様に頑張ってもらって、光回線が開通しました。
夜中の速度計測で16mbps。。。ピーク時もこの速度なら変えた甲斐がありました。

引き続きRichard FooteさんのIndex Rebuildに関するプレゼン資料を
ご紹介します。（第３回）

前回までの発行はこちら

1.導入、B-tree Indexの基礎、Clustering Factor、Fast Full Scanの説明
http://imoment.blogspot.com/2007/01/oracle-b-tree-index.html

2.Indexブロック分割、PCTFREE、PCTUSED、FREELISTの説明
http://imoment.blogspot.com/2007/01/oracle-b-tree-index_22.html

そして今回は削除済領域の再利用に対する見解が主なテーマです。
遅延ブロッククリーンアウト機能の内部動作も説明していきます。

※今回含めて残りあと３回続きますが、もうしばらくお付き合い下さい。

※index用語に慣れていない方は、先にoracle解説のコーナー（前号までも含む）で
　知らない用語について確認されるといいかもしれません。


■ askTomでのindex rebuildに関するdiscussion
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2913600659112

※今回は引用PDFを紹介している適切なサイトが無いので、
　その資料について触れているaskTomのdiscussionをリンクとして
　ご紹介します。

■ 引用PDFファイル
http://www.actoug.org.au/Downloads/oracle_index_internals.pdf

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記事本文
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Deleted Index Deleted Index Space Is Reused

- The previous example clearly illustrates that any insert to
　a leaf block removes all deleted entries
- In randomly inserted indexes, deleted space is not an issue as it will
　eventually be reused
- But wait, there’s more …

◆ Deleted Deleted Entries: Delayed Block Cleanout

- Long running transactions may result in dirty blocks being flushed
　from memory before a commit;
- When subsequently accessed, delayed block cleanout is performed
- Delayed block cleanout results in all corresponding deleted entries
　being cleaned out

◆ Conclusion: Conclusion: Deleted Space

- Deleted space is cleaned out by subsequent writes
- Deleted space is cleaned out by delayed block cleanout
- Fully emptied blocks are placed on freelist and recycled
　(although remain in the index structure)
- Suggestions that deleted space can never be reused are wrong and yet
　another silly myth

◆ Index Fragmentation

Although deleted index space is generally reusable,
there can be wasted space:

. Bug with 90-10 split algorithm in 9i (previously discussed)
. Too high PCTFREE
. Permanent table shrinkage
. Monotonically increasing index values and deletions
. Deletes or Updates that dramatically reduce occurrence of specific
　index values
. Large volume of identical index entries

◆ Large Volume Large Volume Of Identical Values

There are a number of issues with this behaviour:

1. The only leaf blocks that can be inserted into are:
　 . L3 for values of AAA
　 . L7 for values of BBB or CCC
　 i.e. the last leaf blocks containing a specific value
2. All other leaf blocks are “isolated” in that they cannot be considered
　 by subsequent inserts
　 (assuming only current values)
3. The isolated blocks are empty due to 50-50 block splits

◆ Index Rebuilds

. As discussed, most indexes are efficient at allocating and reusing space
. Randomly inserted indexes operate at average 25% free space
. Monotonically increasing indexes operate at close to 0% free space
. Deleted space is generally reusable
. Only in specific scenarios could unused space be expected to be higher
　and remain unusable
. So when may index rebuilds be necessary ?
. An index rebuild should only be considered under the following
　general guideline:
　“The benefits of rebuilding the index are greater than the overall
　　costs of performing such a rebuild”
. Another way to look at this:
　“If there are no measurable performance benefits of performing
　　an index rebuild, why bother ?”
. Another important point:
　“If after a rebuild, the index soon reverts back to it’s previous
　　state, again why bother ?”
. The basic problem with index rebuilds improving performance is
　that generally, the ratio of index blocks visited to table blocks
　visited is relatively small.


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語の解釈
※自然な語順で解釈する癖をつけるために敢えて不自然な日本語に
　なっているところがあります。 ()書きは後続修飾節の修飾対象です。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
◆ Deleted Index Space Is Reused
　 削除された領域は再利用される

- The previous example clearly illustrates that any insert to
　a leaf block removes all deleted entries
　前述の例では、どのようなリーフブロックへのinsertでも削除済エントリを
　消去することを明確に証明しています。
(前述の例とは引用資料のP35-37の内容です)

- In randomly inserted indexes, deleted space is not an issue as it will
　eventually be reused
　不規則にinsertされたindexでは、削除済領域は最終的に再利用されるので
　問題になりません。

- But wait, there’s more …
　しかし待ってください。まだあります。

◆ Deleted Entries: Delayed Block Cleanout
　 削除済エントリと遅延ブロッククリーンアウト

- Long running transactions may result in dirty blocks being flushed
　from memory before a commit;
　長時間実行されるトランザクションはダーティブロック（更新済のブロック）が
　コミット前にmemoryからフラッシュされてしまう可能性を持っています。

- When subsequently accessed, delayed block cleanout is performed
　その後のアクセスがあったとき、遅延ブロッククリーンアウトが発生します。

- Delayed block cleanout results in all corresponding deleted entries
　being cleaned out
　遅延ブロッククリーンアウトは全ての対応する削除済エントリを一掃します。

◆ Conclusion: Deleted Space
　 削除済領域の結論

- Deleted space is cleaned out by subsequent writes
　削除済領域は後続の書込みによって消去されます。

- Deleted space is cleaned out by delayed block cleanout
　削除済領域は遅延ブロッククリーンアウトによって消去されます。

- Fully emptied blocks are placed on freelist and recycled
　(although remain in the index structure)
　完全な空ブロックはfree listに移動して、再利用されます。
　（しかしindex構造内には残ります）

- Suggestions that deleted space can never be reused are wrong and yet
　another silly myth
　削除済領域が再利用されないという提案は間違っており、
　もうひとつのバカな通説です。

◆ Index Fragmentation
　 indexのフラグメンテーション

Although deleted index space is generally reusable,
there can be wasted space:
削除されたindex領域は通常再利用されますが、
無駄な領域である可能性も残っています。

. Bug with 90-10 split algorithm in 9i (previously discussed)
　(以前討論された)9iの90-10分割アルゴリズムのバグ

. Too high PCTFREE
　あまりにも高いPCTFREE

. Permanent table shrinkage
　永続テーブルの収縮

. Monotonically increasing index values and deletions
　単調に増加するindex値および削除

. Deletes or Updates that dramatically reduce occurrence of specific
　index values
　特定のindex値を激減させるdeleteまたはupdateの発生

. Large volume of identical index entries
　大規模な同一値のindexエントリ

◆ Large Volume Large Volume Of Identical Values
　 大規模な同一値のindexエントリ

※P51の図解ベースにしたP52の解説の引用です

There are a number of issues with this behaviour:
このふるまいには沢山の問題があります。

1. The only leaf blocks that can be inserted into are:
　 insertされうるのは以下のブロックのみです。

　 . L3 for values of AAA
　　 AAA用のリーフ3
　　
　 . L7 for values of BBB or CCC
　　 BBBとCCC用のリーフ7

　 i.e. the last leaf blocks containing a specific value
　 すなわち特定の値の最後のブロックです。

2. All other leaf blocks are “isolated” in that they cannot be considered
　 by subsequent inserts
　 (assuming only current values)
　 この場合、他の全てのブロックが孤立します。後続のinsertでは考慮されません。
　 （現在の例示した値だけで仮定した場合）

3. The isolated blocks are empty due to 50-50 block splits
　 50-50ブロック分割のために孤立したブロックは半分が空です。

◆ Index Rebuilds

. As discussed, most indexes are efficient at allocating and reusing space
　議論したように、ほとんどのindexは領域の割り当てや再利用において効率的です。

. Randomly inserted indexes operate at average 25% free space
　不規則なinsertが起こるindexでは平均25%の空き領域で機能します。

. Monotonically increasing indexes operate at close to 0% free space
　単調に値が増加するindexではほとんど0%の空き領域で機能します。

. Deleted space is generally reusable
　削除された領域は通常再利用されます

. Only in specific scenarios could unused space be expected to be higher
　and remain unusable
　特定のケースに限って、未使用領域が多く残ることが考えられます

. So when may index rebuilds be necessary ?
　というわけで、いつrebuildは必要になるのでしょうか？

. An index rebuild should only be considered under the following
　general guideline:
　index rebuildは以下のガイドラインによってのみ考慮されます

　“The benefits of rebuilding the index are greater than the overall
　　costs of performing such a rebuild”
　 ”index rebuildはrebuildを行う手間やコストを上回る場合において
　　 意味があります”

. Another way to look at this:
　こういった見方もあります。

　“If there are no measurable performance benefits of performing
　　an index rebuild, why bother ?”
　 ”もし計測可能なindex rebuildによるパフォーマンスの利益が無いなら、
　　 何故わざわざ(rebuild)するのでしょうか”
　　
. Another important point:
　もうひとつ重要なポイントです

　“If after a rebuild, the index soon reverts back to it’s previous
　　state, again why bother ?”
　 ”もしindex rebuildをした後に、すぐに元の状態に戻るとしたら、
　　 繰り返しますが、何故わざわざ(rebuild)するのでしょうか”

. The basic problem with index rebuilds improving performance is
　that generally, the ratio of index blocks visited to table blocks
　visited is relatively small.
　index rebuildによるパフォーマンス向上に関する基本的な問題は、
　通常tableブロックのアクセス数に対するindexブロックのアクセス数の
　割合は比較的小さいことです。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
英語解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
- The previous example clearly illustrates that any insert to
　a leaf block removes all deleted entries

illustrate:(主に本や雑誌に)描く、
　　　　　 (より明確に図解や例示によって)意味や真実を示す

　
- In randomly inserted indexes, deleted space is not an issue as it will
　eventually be reused

issue:（雑誌など）発行する、課題、問題
eventually:ついに、最終的に


◆ Deleted Entries: Delayed Block Cleanout

Delayed Block Cleanout:遅延ブロッククリーンアウトと呼ばれるOracleの仕様です。
　　　　　　　　　　　 (Oracle解説参照)


- Long running transactions may result in dirty blocks being flushed
　from memory before a commit;

dirty blocks:メモリ上に存在する更新済み未COMMITデータ
　　　　　　　(Oracle解説のDelayed Block Cleanout参照)
flush:（メモリの内容を）一掃してDISKに反映する。通常はトイレを流すという意味で使用する。


- When subsequently accessed, delayed block cleanout is performed

subsequently:後続して

　
◆ Index Fragmentation
　 indexのフラグメンテーション

Fragmentation:元々大きな１つの何かが細かくバラバラになってしまった状態。
　　　　　　　fragmentは小さくなった破片、または、塊を砕く行為そのもの。

　　　　　　　diskのfragmentationはデータの削除、追加の繰り返しにより、
　　　　　　　連続した空き領域がなくなり、ファイルを細かい断片にして小さな空き領域に
　　　　　　　格納すること、またはそれが発生した状態を指す。（断片化）
　　　　　　　ここではindexのエントリの削除によって、細かい未使用領域が沢山存在した
　　　　　　　状態を指している。


Although deleted index space is generally reusable, there can be wasted space:

generally:一般的に、総じて、通常


. Bug with 90-10 split algorithm in 9i (previously discussed)

Bug with 90-10: 9.2で90-10のsplitアルゴリズムにバグがあり、
　　　　　　　　50-50になってしまっていたというもの。


. Permanent table shrinkage

Permanent:永遠の、永続の
　　　　　Oracleでは一時テーブルと区別する為に、
　　　　　永続テーブルとしてPermanentを使用する。


. Deletes or Updates that dramatically reduce occurrence of specific
　index values

dramatically:劇的に
occurrence:発生
specific:特定の


. Large volume of identical index entries

identical:同一の


There are a number of issues with this behaviour:

behaviour:振舞い


i.e. the last leaf blocks containing a specific value

i.e.:要約、すなわち、（ラテン語のid estの略）


2. All other leaf blocks are “isolated” in that they cannot be considered
　 by subsequent inserts
　 (assuming only current values)

isolated:孤立した、隔離された
assuming ～:～と仮定した場合
　
　
◆ Index Rebuilds

. As discussed, most indexes are efficient at allocating and reusing space

efficient:効率的


. Randomly inserted indexes operate at average 25% free space

randomly:不規則に
operate:動作する、機能する


“If there are no measurable performance benefits of performing
　an index rebuild, why bother ?”

mesurable:計測可能な
bother:邪魔する、わざわざする

　
“If after a rebuild, the index soon reverts back to it’s previous
　state, again why bother ?”

revert:元に戻る


. The basic problem with index rebuilds improving performance is
　that generally, the ratio of index blocks visited to table blocks
　visited is relatively small.

relatively:比較的


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
★ 英語ぷちクイズ ★

※答えと思うリンクをぷちっとクリックしてください。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

☆どちらが理想的でしょうか。

◆to study English.
┗ http://clickenquete.com/a/a.php?M0002066Q0019367A1a2bf
◆to learn English.
┗ http://clickenquete.com/a/a.php?M0002066Q0019367A245c4
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019367C983d

締切：2007年02月10日23時00分
協力：クリックアンケート http://clickenquete.com/

こたえは次回に発表します。


■　前回のこたえ

☆現在完了形は英語でどう言いますか

◆present perfect
◆current complete
◆present finish
◆current perfect
○結果を見る
┗ http://clickenquete.com/a/r.php?Q0019172Ccd12

こたえはpresent perfectです。

その他の英語学習用語です。

時制:tense
現在進行形:continuous
現在:present
過去形:past tense
未来形:future tense
現在完了:present perfect
過去完了:past perfect

主語:subject
述語:predicate
動詞:verb
名詞:noun
前置詞:preposition
形容詞:adjective
副詞:adverb
代名詞:pronoun
不定詞:infinitive
受動態:passive
冠詞:article

発音:pronounce(動詞)/pronunciation(名詞)
母音:vowel
子音:consonant
音節:syllable
アクセント:accent/stress

語順:word order
単数:singular
複数:plural

多少でも英語がわかるのであれば、
英語で書かれた文法テキストでの勉強を強くお勧めします。
日本のそれよりもずっとわかりやすいと思います。

以下は私が使った文法テキストです。小学校低学年向けの内容なので文章も難しくありません。
◆ Amazon.co.jp：Basic Grammar in Use With Answers
http://tinyurl.com/38mpmx

Basic版で物足りなければ、Intermediate版(高学年)、Advanced版(中学生程度)もあります。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
Oracle解説
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今回の用語説明は"Delayed Block Cleanout"のみです。
既にご存知の方は後続の解説にお進みください。

－・ Delayed Block Cleanout ・－・－・－・－・－・－・－・－・－・－・－・

日本語では「遅延ブロッククリーンアウト」と呼ばれる動作について、
削除時の内部動作から理解しましょう。

01.delete発行
02.delete対象のブロックをDISKからバッファキャッシュに読み込む
03.redoログバッファにdelete情報を記録
04.undoエントリをundoセグメントヘッダのトランザクションエントリに作成
05.delete行のコピーを空いているundoブロックに書き込む
06.delete行をバッファキャッシュ上の該当ブロック内から消し去る
07.該当ブロックをdirtyブロックとしてマークし、delete前のデータが存在する
　 undoブロックの宛先を記録
　 (dirtyブロック:メモリ上に存在する更新済みの未COMMITデータ)
08.commit発行
09.SCN(System Change Number)の生成
10.undoセグメントヘッダのトランザクションエントリに該当するundoエントリが
　 commit済であることを記録(SCNを記録)
11.LGWRがlog bufferの該当トランザクションに関連するredoデータを
　 flush(redoログファイルに格納)する。
12.もし該当のデータブロックがバッファキャッシュにまだ残っていた場合、
　 そのブロックヘッダにSCNを記録する。これをfast commitを呼びます。
13.項番12.に該当せず、既にバッファキャッシュからDISKに追い出され、
　 dirtyブロックのままDISKに格納されてしまっていた場合、
　 commit時点ではそのdirtyブロックそのままでほっとかれます。

　 その後、dirtyブロックにアクセスした後続プロセスがdirtyブロック（未COMMIT）
　 という情報を信じてundoセグメントヘッダのトランザクションエントリを参照し、
　 「なんだ既にCOMMIT済みじゃん！」ってことになって、undoセグメントヘッダ
　 トランザクションエントリ上のSCNを取得し、dirtyブロックのブロックヘッダに
　 「やれやれ。。。何で俺がやんなきゃならんの？」という感じで記録してあげます。

この項番13.の動作が「遅延ブロッククリーンアウト」です！
これはcommitの性能を高めるために、dirtyブロックの存在するDISKへの
アクセスを後回した「日本の国債」のような問題先送りシステムです。
そのツケは後からアクセスしたプロセスが背負います。
最悪の場合、大量の行削除後に別の処理で同じテーブルにフルスキャンを
かけた場合、フルスキャン処理はとんでもないとばっちりを食う可能性が
あるということになります。

※ちなみにLGWRプロセスのlog buffer flush動作は上記項番11.を含めて以下のケースが
　あります。

　A.commit発行時
　B.3秒に1回
　C.log bufferの3分の1が使用された場合
　D.DBWnプロセスが修正済みのバッファをDISKに書き込む時

　A.の場合にflushするのはcommitレコードとそのトランザクションに属するredoデータです。
　D.の場合にflushするのはDISKに書き出すバッファに関連するredoデータです。
　B.C.のflush内容はわかりません。その時点の全てのredoデータでしょうか。
　　すみません勉強不足です。(どなたか教えてください)

（flushは主にトイレを流すという意味の動詞として日常では使用されます）

今回の引用文ではこのDelayed Block Cleanoutがindexの削除済み領域をクリアする
要因になることを説明しています。

－・ Delayed Block Cleanout ここまで・－・－・－・－・－・－・－・－・－・

Footeさんの結論としては、indexの削除済みエントリは後続のinsertやupdate時に
使用される予約領域なので、rebuildでクリアするのは馬鹿げていると考えています。

ただし、例外事項としてrebuildが必要なケースもちゃんと説明しています。

・9iの90-10分割アルゴリズムのバグ
・あまりにも高いPCTFREE
・永続テーブルの収縮
・単調に増加するindex値および削除
・特定のindex値を激減させるdeleteまたはupdateの発生
・大規模な同一値のindexエントリ

アンチrebuildのfooteさんが要rebuildのケースと言っているんだから、
考慮する価値がありそうですね。

・9iの90-10分割アルゴリズムのバグ
　→これはパッチをあてるかPSRを上げるかしないとでしょうか。

・あまりにも高いPCTFREE
　→これはあえてそうしているのだから考慮不要では？設定ミスの可能性？
　　これを掲載しているfooteさんの意図がわかりませんでした。

・永続テーブルの収縮
・特定のindex値を激減させるdeleteまたはupdateの発生
　→大規模な支店の統廃合などでindexが激変した場合などでしょうか。

・単調に増加するindex値および削除
　→年月で古いデータから消えていくテーブルなど

・大規模な同一値のindexエントリ
　→複数のindexブロックを跨ってしまうほどの同一値エントリだと
　　連続する同一値ブロックは最後のブロック以外永遠に再利用されることが
　　原則としてありません。（同一値全て削除されれば再利用可）

上記のケースに当てはまりそうで、かつパフォーマンスクリティカルなindexが
あった場合、rebuildを考慮してみてはいかがでしょうか。

一番のrebuild緊急検討ケースはindexが使用されなくなってしまう程、
無駄な削除済領域が増えてしまったった場合でしょうか。


＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
編集後記
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
今号からご購読いただいた皆様はじめまして。
本日も最後まで読んでいただきありがとうございます。

厳しい１月の仕事をなんとか乗り越えることができました。
次は２，３月と怒涛の休日出勤が始まります。
滞らないように頑張りたいと思います。

それではまた。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
おわりに
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
記述誤りなどのご指摘、
記事に関する疑問点・質問・感想・ご意見・ご感想など
yakusa_oracle@yahoo.co.jpまでお願い致します。

簡単な自己紹介はこちら
http://pr2.cgiboy.com/S/3191274

バックナンバー兼ブログはこちら
http://imoment.blogspot.com/

登録・解除はこちらから
http://www.mag2.com/m/0000200441.htm

Posted by yaksa at 10:26 午後 | Permalink | Comments