- PR -

oracle8i INDEXについて

1
投稿者投稿内容
未記入
ベテラン
会議室デビュー日: 2004/09/27
投稿数: 71
投稿日時: 2007-01-30 12:34
現在、INDEX表領域としてINDXが用意されています。
でも、なぜか全index（200個×スキーマ数）の格納表領域がUSERSになっています。
そのため、USERS表領域がかなりの容量を食っています。
また、実務では、UPDATEに時間がかかっているのでINDEXをDROPしたら、余計に更新の処理時間がかかってしまいました。（where句にindexが使われなくなったからかな？）

このまま、USERS表領域に格納していていいのでしょうか？
それともINDEX表領域に移動させたほうがいいのでしょうか？
INDEX表領域のメリットとデメリットを教えてください。
もしもし
ぬし
会議室デビュー日: 2004/10/15
投稿数: 280
投稿日時: 2007-01-30 13:21
"INDEX" だの "USERS" だの、表領域の名前は単に管理しやすくするための
記号に過ぎませんから。

もちろん、"INDEX" と名付けた表領域のデータファイルを物理的に "USERS"
表領域と異なるディスクに格納していて索引と表データを分けていれば、
索引スキャンを実行するときに I/O がバッティングしないですむ、という
メリットは考えられます。

で、

> また、実務では、UPDATEに時間がかかっているのでINDEXをDROPしたら、

果たして索引の更新で遅くなっていたんでしょうかね。バッファが不足していた
だけかもしれませんよ。

_________________
もしもし＠RMAN 友の会
未記入
ベテラン
会議室デビュー日: 2004/09/27
投稿数: 71
投稿日時: 2007-01-30 13:38
＞表領域の名前は単に管理しやすくするため
＞索引スキャンを実行するときに I/O がバッティングしない
分かりました。ありがとうございます。

＞バッファが不足していただけかもしれませんよ。
INDEXを再作成すると更新処理時間は変わらない。でも、また削除すると５倍の処理時間がかかります。どちらも何度か繰り返しましたが、同じ結果でした。
INDEXを削除して更新処理をすると、なぜバッファが不足するのですか？全検索が走ってしまうからですか？
もしもし
ぬし
会議室デビュー日: 2004/10/15
投稿数: 280
投稿日時: 2007-01-30 13:46
引用:

未記入さんの書き込み (2007-01-30 13:38) より:

＞バッファが不足していただけかもしれませんよ。
INDEXを再作成すると更新処理時間は変わらない。でも、また削除すると５倍の処理時間がかかります。どちらも何度か繰り返しましたが、同じ結果でした。
INDEXを削除して更新処理をすると、なぜバッファが不足するのですか？全検索が走ってしまうからですか？


バッファが云々は「UPDATEに時間がかかっているのでINDEXをDROPしたら」の
索引を drop する前の話なんですが．．．。

アクセス対象の表にデータが大量にあれば、全件検索して遅くなるのは
しょうがないかと。

_________________
もしもし＠RMAN 友の会
未記入
ベテラン
会議室デビュー日: 2004/09/27
投稿数: 71
投稿日時: 2007-01-30 15:02
＞バッファが云々は「UPDATEに時間がかかっているのでINDEXをDROPしたら」の索引を drop する前の話なんですが．．．。
なるほど。早速バッファ関係を調べました。
select name, value from v$sysstat where name in ('redo blocks written','redo size','redo wastage','redo entries','redo log space requests','redo buffer allocation retries');

redo entries 43104264
redo size 21198324496
redo buffer allocation retries 195590
redo wastage 417481200
redo blocks written 29966544
redo log space requests 722

これってやばいんでしょうか？ネットで調べたら、'redo buffer allocation retries'を0に近づけて'redo entries'の1％以下にしろと書いてありました。
対策として、LOG_BUFFERパラメータの値を大きくするしかないのでしょうか？

[ メッセージ編集済み 編集者: 未記入 編集日時 2007-01-30 15:11 ]
もしもし
ぬし
会議室デビュー日: 2004/10/15
投稿数: 280
投稿日時: 2007-01-30 15:54
v$sysstat はインスタンス起動時からの累積情報ですから、一回
取っただけでは判断できません。普通は作業前後の差分を確認します。
（statspack の snapshot も差分をレポートしてますよね？）
あと、想定してたのは REDO バッファじゃなくてデータベース・バッファ・
キャッシュの方だったんですけどね．．．。

ま、SQL が分かっていれば SQL トレースの方が早いかもしれませんけど。
（event 10046 level 8 の内容は @IT にも記事になっています）


_________________
もしもし＠RMAN 友の会

[ メッセージ編集済み 編集者: もしもし 編集日時 2007-01-30 15:56 ]
もしもし
ぬし
会議室デビュー日: 2004/10/15
投稿数: 280
投稿日時: 2007-01-30 16:06
ってか、だんだん本題から離れてしまってますね。
ま、そうなるような記事を書いたのは私ですが．．．。

たしかに索引列の値を更新するのであれば遅くなる可能性は
否定できませんが、よっぽど大量の更新をしない限り、更新処理で
問題になることはありません。
索引を削除すれば当然全件検索しなければなりませんから、
遅くなるのはしょうがないとして、索引がある状態で遅い
（この『遅い』ってのも何かと比較したわけでないですから、
一概に遅いと判断することもできないでしょうが）
のであれば、何がパフォーマンスのでない原因であるか、
SQL トレースを取ったり待機イベントを確認したりして
調査を行う必要があるでしょう、と。

で、表領域を分けて索引と表を保存するのは、管理上どっちが
やりやすいか、とかディスク I/O がぶつからないようにする
とかそういう要件で判断するかと。

ちなみに、表と索引が同じ表領域にあるってのは、おそらく
create index にそう書いたか、あるいは create index に
tablespace 句を付けなかったんで、実行ユーザのデフォルト
表領域に作成された、ってことでしょう。

_________________
もしもし＠RMAN 友の会
未記入
ベテラン
会議室デビュー日: 2004/09/27
投稿数: 71
投稿日時: 2007-01-30 16:59
select to_char((1 - (a.value / ( b.value + c.value))) * 100, '99.99') || '%'
"db_block_buffer hit ratio"
from v$sysstat a, v$sysstat b, v$sysstat c
where a.name = 'physical reads'
and b.name = 'db block gets'
and c.name = 'consistent gets';

データベースキャッシュの調査結果。キャッシュヒット率＝93.64%でした。
90％以上なら問題ないとネットで書かれていたので、問題ないみたいです。
更新処理に時間がかかる件に関しては、またいろいろと調べてみます。


＞表領域を分けて索引と表を保存
本題のメリットはおかげさまで理解できました。ありがとうございます。
1

スキルアップ／キャリアアップ（JOB@IT）