Oracle Database...Event Waits Time (s) (ms) Time enq: TX - row lock contention 14,858 3,925 264 26.3...
Transcript of Oracle Database...Event Waits Time (s) (ms) Time enq: TX - row lock contention 14,858 3,925 264 26.3...
1
リスクに備えたログ管理の重要性~DB特権ユーザのモニタリング~
2010年8月25日
株式会社インサイトテクノロジー
エンジニアリング本部
テクノロジーコンサルティング部
松尾 亮
☆おら!オラ!Oracle -どっぷり検証生活-★
Oracle Database現場で役立つパフォーマンスチューニング
3
待機イベントとは?
プロセスがCPUを使用していない時間
User I/O、ロック競合、etc…
バックグラウンドプロセス
サーバプロセス
SQL解析
User I/O
SQL実行 Commit実行
Redo生成
commit
Redoログ書き込み
CPU Time
待機イベント
ロック待ち
4
待機イベントの確認方法
ある期間におけるインスタンス全体の待機イベントを確認したい
→ パフォーマンス統計レポート(STATSPACK or AWR)を確認
- STATSPACK ・・・ Oracle 8.1.6 ~
- AWR ・・・ Oracle 10.1.0 ~、EE のみ利用可
※今回のセミナーでは、Standerd Edition でも利用可能な STATSPACK を
例にして説明します。
ある特定の処理おける待機イベントを確認したい
→ SQLトレース、動的パフォーマンスビュー(V$表)を確認。
5
STATSPACK 概要
snap#1
定期的にスナップショットをDBに保存 (手動)
ある期間(snapshot間)のデータベース処理の統計情報をレポートする
snap#2 snap#3
time
#1~#3間のレポート取得
#2~#3間のレポート取得
Standard Editionで利用可能!
待機イベント統計SGAのヒット率セッション統計etc…
6
STATSPACK の使用方法
SQL> -- STATSPACK 環境のインストールSQL> conn / as sysdbaSQL> @$ORACLE_HOME/rdbms/admin/spcreate.sql
→ STATSPACK管理ユーザ(perfstat)のパスワード、オブジェクト格納表領域、一時表領域を指定
SQL> -- スナップショットの取得SQL> conn perfstat/passwordSQL> exec statspack.snap(i_snap_level=>7);
※スナップショットレベルについては次ページに記載
SQL> -- レポートの取得SQL> conn perfstat/passwordSQL> @$ORACLE_HOME/rdbms/admin/spreport.sql
→ レポートの開始ID、終了ID、レポートファイル名を指定
7
STATSPACK の取得レベル(9iR2~)
level 収集データ
基本統計 アドバイス情報 SQL統計 SQL詳細 セグメント情報 ラッチ詳細
0 ○ ○
5 ○ ○ ○
6 ○ ○ ○ ○
7 ○ ○ ○ ○ ○
10 ○ ○ ○ ○ ○ ○
デフォルトは level 5 だが level 7 の情報が役立つことが多い。Level 10 は情報量が多くスナップショット取得にかかる負荷が高くなる為、サポートから依頼された場合を除き、基本的に使用しない。
8
STATSPACK レポートで最も注目すべきポイント
Top 5 待機イベントが、レポートで最も注目すべきポイント!
Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait CallEvent Waits Time (s) (ms) Time----------------------------------------- ------------ ----------- ------ ------enq: TX - row lock contention 14,858 3,925 264 26.3gc buffer busy acquire 419,613 2,921 7 19.6shared server idle wait 453,775 1,978 4 13.3enq: TX - index contention 32,020 1,757 55 11.8CPU time 1,312 8.8
Waits : イベントのために待機した合計回数Time(s) : 合計待機時間(秒)Avg wait(ms) : 平均待機時間%Total Call Time : 全ての待機時間に対する占有比率
上位の待機イベントの解消 = チューニング効果の期待大
9
STATSPACK での調査ステップ
1. Top 5 待機イベントを確認
2. 上位の待機イベントの意味を確認(マニュアル、KROWN 等)
3. 待機イベントの発生要因に関連するセクションを調査
ex)・ db file scattered read 、db file sequential read 等
→ SQL Ordered By XXX セクションを確認→ SQLチューニング?
・ enqueue→ Enqueue activity、Segments by Row Lock Waits セクションを確認
→ アプリ処理の見直し?・ buffer busy waits
→ Segments by Buffer Busy Waits セクションを確認→ 空きリスト競合?逆キー索引、パーティション化?
10
調査例 ステップ①
待機イベントの上位に以下2つのイベントが出現
db file scattered readマルチブロック読込(Full Scan、Index Fast Full Scan など)
db file sequential read単一ブロック読込(Index Scan)
→ SQL の I/O 関連イベントなので、SQL ordered by Elapsed time、
SQL ordered by Gets 等を確認
SQL ordered by Elapsed time for DB:
Elapsed Elap per CPU OldTime (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value
---------- ------------ ---------- ------ ---------- --------------- ----------4071.23 50 81.4 52.4 500.71 7530123 1234567890
Module: [email protected] (TNS V1-V3)SELECT ・・・ FROM TAB1 WHERE ・・・
11
調査例 ステップ②
SQL> @$ORACLE_HOME/rdbms/admin/sprepsql.sql
Snap SnapInstance DB Name Id Snap Started Level Comment------------ ------------ ----- ----------------- ----- ----------------------orcl orcl 1 23 Aug 2010 19:00 7
2 23 Aug 2010 19:30 73 23 Aug 2010 20:00 74 23 Aug 2010 20:30 7
Specify the Begin and End Snapshot Ids~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~begin_snapに値を入力してください: 1Begin Snapshot Id specified: 1
end_snapに値を入力してください: 2End Snapshot Id specified: 2
Specify the Hash Value~~~~~~~~~~~~~~~~~~~~~~hash_valueに値を入力してください: 1234567890Hash Value specified is: 1234567890
SQL ordered by XXX で確認した SQL 分析レポートを取得
12
調査例 ステップ③
First First Last PlanSnap Id Snap Time Active Time Hash Value Cost
--------- ---------------- ---------------- ------------ ----------21 16-11月-09 23:00 17-11月-09 11:42 1503752779 13022 17-11月-09 10:43 17-11月-09 11:11 4265373922 2
~ 略 ~
--------------------------------------------------------------------------------| Operation | PHV/Object Name | Rows | Bytes| Cost |--------------------------------------------------------------------------------|SELECT STATEMENT |----- 1503752779 ----| | | 130 ||FOR UPDATE | | | | || PARTITION HASH ALL | | 1 | 360 | 130 || TABLE ACCESS BY LOCAL INDEX RO|TAB1 | 1 | 360 | 130 || INDEX RANGE SCAN |TAB1_IDX2 | 1 | | 129 ||SELECT STATEMENT |----- 4265373922 ----| | | 2 ||FOR UPDATE | | | | || PARTITION HASH SINGLE | | 1 | 60 | 2 || TABLE ACCESS BY LOCAL INDEX RO|TAB1 | 1 | 60 | 2 || INDEX RANGE SCAN |TAB1_IDX1 | 1 | | 1 |--------------------------------------------------------------------------------
SQL レポートを確認
実行計画が変更されたタイミングが確認できる
13
STATSPACK での分析に向かないケース
ある特定の処理が遅かった・・・
ある特定の瞬間だけ遅かった・・・
スナップショットの取得間隔が30分間で、- 通常、1秒で終了する処理が1分かかった- ある1分間の間だけ高負荷状態になったetc…
このような場合、STATSPACK でボトルネックを検出することは困難。
14
特定のSQL調査(SQLトレースを取得)
特定のSQLの待機イベント情報を含めたSQLトレースを取得SQL> alter session set events '10046 trace name context forever, level 8';
~ 問題のSQLを実行 ~
SQL> alter session set events '10046 trace name context off';
実行中のセッションに対してSQLトレースを取得
-- v$session 等の情報からセッションを特定alter session set nls_date_format='YYYY/MM/DD HH24:MI:SS';select username,program,server,status,sid,serial#,last_logon_timefrom v$session where username is notnull;
-- 特定した sid、serial# に対して SQLトレースを取得exec sys.dbms_system.set_ev(&sid, &serial, 10046, 8, '');exec sys.dbms_system.set_ev(&sid, &serial, 10046, 0, '');
取得したトレースファイルを整形(初期化パラメータ user_dump_dest or background_dump_dest に出力される)
$ tkprof <トレースファイル名> <整形後ファイル名> sys=no
15
特定のSQL調査(SQLトレースを確認①)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 2 0.59 0.66 0 656 0 0Execute 2 0.00 0.00 0 0 0 0Fetch 2 6.54 48.45 5599 18502 0 1------- ------ -------- ---------- ---------- ---------- ---------- ----------total 6 7.13 49.11 5599 19158 0 1
Elapsed times include waiting on following events:Event waited on Times Max. Wait Total Waited---------------------------------------- Waited ---------- ------------SQL*Net message to client 4 0.00 0.00SQL*Net message from client 4 25.87 56.30row cache lock 2 0.00 0.00ges message buffer allocation 2776 0.00 0.02library cache lock 9 0.00 0.00KJC: Wait for msg sends to complete 5 0.00 0.00library cache pin 9 0.00 0.00SQL*Net break/reset to client 2 0.00 0.00gc cr grant 2-way 4 0.00 0.00Disk file operations I/O 3 0.00 0.00db file sequential read 5599 0.80 41.97
16
特定のSQL調査(SQLトレースを確認②)
~ 略 ~
WAIT #2: nam='db file sequential read' ela= 1211 file#=2 block#=18914 blocks=1 obj#=-1 tim=1282568692243420WAIT #2: nam='ges message buffer allocation' ela= 8 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692244398WAIT #2: nam='gc cr disk read' ela= 226 p1=2 p2=18922 p3=4 obj#=-1 tim=1282568692244717WAIT #2: nam='db file sequential read' ela= 1338 file#=2 block#=18922 blocks=1 obj#=-1 tim=1282568692246167WAIT #2: nam='ges message buffer allocation' ela= 9 pool=0 request=1 allocated=0 obj#=-1 tim=1282568692247118WAIT #2: nam='gc cr disk read' ela= 204 p1=2 p2=18930 p3=4 obj#=-1 tim=1282568692247414WAIT #2: nam='db file sequential read' ela= 6934 file#=2 block#=18930 blocks=1 obj#=-1 tim=1282568692254461WAIT #2: nam='db file sequential read' ela= 2327 file#=2 block#=18946 blocks=1 obj#=-1 tim=1282568692257806WAIT #2: nam='db file sequential read' ela= 5903 file#=2 block#=18954 blocks=1 obj#=-1 tim=1282568692264806WAIT #2: nam='db file sequential read' ela= 507 file#=2 block#=18962 blocks=1 obj#=-1 tim=1282568692266332WAIT #2: nam='db file sequential read' ela= 2536 file#=2 block#=18970 blocks=1 obj#=-1 tim=1282568692270202WAIT #2: nam='db file sequential read' ela= 5483 file#=2 block#=18978 blocks=1 obj#=-1 tim=1282568692276741WAIT #2: nam='db file sequential read' ela= 3660 file#=2 block#=18986 blocks=1 obj#=-1 tim=1282568692281452WAIT #2: nam='db file sequential read' ela= 496 file#=2 block#=18994 blocks=1 obj#=-1 tim=1282568692282994WAIT #2: nam='db file sequential read' ela= 499 file#=2 block#=19002 blocks=1 obj#=-1 tim=1282568692284503WAIT #2: nam='db file sequential read' ela= 504 file#=2 block#=19010 blocks=1 obj#=-1 tim=1282568692286000
~ 略 ~
(参考) TKPROF 整形前のトレース
17
特定のSQL調査(SQL実行計画を確認)
実行計画の確認は、個人的には Explain Plan がお薦め!※SQL を実行せずにPlanを表示する。実際に実行するとPlanが変わることがあるので注意。
Predicate Information に出力される ID による紐付け、索引使用可否の判断、該当の where 句の判断が容易。
-- PLAN_TABLE を作成SQL> @?/rdbms/admin/utlxplan.sql
-- SQL を解析SQL> explain plan for 解析したいSQL文;
Explained.
-- 解析結果を表示SQL> select * from table(dbms_xplan.display());
※別紙にて詳細解説
19
事例1 ~概要~
• システム概要– モバイルコンテンツ配信システムのDB
– Oracle11gR1 2node RAC
• 状況– テスト期間中、アプリの改修に伴い索引を新規追加。
追加後の動作検証(負荷テスト)で遅延が発生。
(追加前:400処理/秒→追加後:200処理/秒)
– 追加した表は、複数セッションから insert (1処理1件)が大量に行われるという特性がある。
• 要望– 索引を追加した状態で追加前と同等のパフォーマンスに
戻したい。
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
20
CPU使用率は減少。(CPUが使えていない)ロック関連の待機イベントが多発!
事例1 ~状況~
索引追加前 索引追加後
待機イベント 待機イベント
CPU使用率 CPU使用率
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
21
事例1 ~状況(STATSPACKでは)~
索引追加後
Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait CallEvent Waits Time (s) (ms) Time----------------------------------------- ------------ ----------- ------ ------enq: TX - row lock contention 14,858 3,925 264 26.3gc buffer busy acquire 419,613 2,921 7 19.6shared server idle wait 453,775 1,978 4 13.3enq: TX - index contention 32,020 1,757 55 11.8CPU time 1,312 8.8
-------------------------------------------------------------
Host CPU (CPUs: 16 Cores: 8 Sockets: 2)~~~~~~~~ Load Average
Begin End User System Idle WIO WCPU------- ------- ------- ------- ------- ------- --------
1.14 3.56 21.34 3.76 73.25 1.48
22
事例1 ~状況~
索引追加前 索引追加後
追加した索引に関連する表、索引に対するロック、buffer busy が多発している!
ロック発生オブジェクト ロック発生オブジェクト
buffer busy発生オブジェクト buffer busy発生オブジェクト
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
23
事例1 ~状況(STATSPACKでは)~
索引追加後
Segments by Row Lock WaitsRow
Subobject Obj. Lock PctOwner Tablespace Object Name Name Type Waits Total---------- ---------- -------------------- ------------ ----- ------------ -----SCOTT TS_INDEX TEST1_PKEY INDEX 10,524 24.8SCOTT TS_INDEX TEST2_PKEY INDEX 8,422 19.8SCOTT TS_INDEX TEST3_PKEY INDEX 7,243 17.1SCOTT TS_INDEX TEST4_IDX1 INDEX 1,420 3.3SCOTT TS_DATA TEST2_TAB TABLE 336 .8
Segments by Buffer Busy WaitsBuffer
Subobject Obj. Busy PctOwner Tablespace Object Name Name Type Waits Total---------- ---------- -------------------- ------------ ----- ------------ -----SCOTT TS_INDEX TEST1_PKEY INDEX 20,117 31.1SCOTT TS_INDEX TEST2_PKEY INDEX 18,626 28.7SCOTT TS_INDEX TEST3_PKEY INDEX 16,787 25.9SCOTT TS_INDEX TEST3_IDX2 INDEX 3,499 5.4SCOTT TS_INDEX TEST4_IDX1 INDEX 3,334 5.1
24
事例1 ~現場の様子~
この時の現場の様子をお届けします・・・
アプリ担当者(以下、アプリ)
「アプリ改修したので、使いそうな索引を追加しました。」
DBA 「分かりました。確認します。
・・・って、めちゃくちゃいっぱいあるじゃないですか!
この索引、全部使うんですか??」
アプリ 「いやー、ちょっと分からないんですけど、使うかもしれ
ないとこには全部作ってみました。
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
25
事例1 ~現場の様子~
DBA 「そ、そうですか・・・
確か、今回索引を追加する表って、どれも insert が
大量に実行されるテーブルですよね?
索引があると insert は遅くなるんですよ。
だから、検索に使われない索引は削除したいですね。」
アプリ 「はー、そうですか・・・」
DBA 「ま、とりあえず負荷テストしてみますか。
そんなに影響出ないかもしれないし。」
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
26
事例1 ~現場の様子~
パフォーマンス50%にDown!
DBA 「あらら・・・ちょっと想像以上に遅くなりましたね。。。
まずは使われてない索引を削除しましょうか。
想定される一連の処理を実行してもらえますか?」
アプリ 「はい、分かりました。」
しばし待ち、実行終了・・・
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
27
事例1 ~現場の様子~
DBA 「使われてない索引がいくつかあったので削除しますね。
これとこれと・・・
これらは削除しても影響なさそうですか?
確実に使う筈、というものがあれば教えて下さい。」
アプリ 「うーん、削除しても大丈夫だと思います。」
DBA 「じゃ、削除しますねー」
そして、再度負荷テスト・・・
10%くらいパフォーマンス回復。まだ、あと40%・・・
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
28
事例1 ~現場の様子~
(ちょっとbreak)
使用されていない索引の確認方法として索引のモニタリング機能
がありますが、v$sql_plan でメモリに存在する実行計画を参照し、
現在、実行計画に使用されていないインデックスを確認するという
方法も可能です。短期間のテスト等ではお手軽に確認できます。
SQL> select object_name,object_type,hash_value
1 from v$sql_plan
2 where object_type like 'INDEX%' and object_name like '%EMP%'
3 group by object_name,object_type,hash_value
4 order by 1,2;
OBJECT_NAME OBJECT_TYPE HASH_VALUE
------------- ---------------- ----------
IDX_EMP_1 INDEX 4000148954
PK_EMP INDEX (UNIQUE) 1933697836
PK_EMP INDEX (UNIQUE) 4074557984
出力されてない→検索に利用されてない
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
29
事例1 ~現場の様子~
DBA 「insert 競合を解消するには・・・
フリーリストを増やす!かな。試してみるか!
と思ったけど、、、
この表がある表領域は自動セグメント領域管理だった。
フリーリストの調整はできないじゃん・・・
えーっと、この表は連番で insert されていくから、
どうしても索引のブロックは競合するんだろうな。。。」
0000100002000030000400005
:
索引ブロックinsert
insert
insert
insert
insert
索引は順番に並んで格納される為、このシステムの処理特性上、同一ブロックへの競合が発生しやすい!
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
30
事例1 ~現場の様子~
(またまた、ちょっとbreak)
フリーリストとは、 insert 可能な空きブロックの情報を管理している
領域。insert 時にはフリーリストの空きブロック情報を参照する為、
insert の多重度が高いとフリーリストへのアクセスが競合する。
その場合、フリーリストを増加させることでパフォーマンスが向上する
可能性がある。自動セグメント領域管理(ASSM)では、ビットマップ
情報で空きブロック情報が管理され、明示的に調整はできない。
insert可能なブロックのリスト
block#1block#5block#7
Insert #1
(空き)#2 #3 #4
#5
(空き)#6 #7
(空き)#8
Insert
Insert
Insert
Insert
フリーリスト
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
31
事例1 ~現場の様子~
DBA 「連番で次々と insert されてくるデータを同一ブロックに
集中させない為には・・・
ハッシュパーティションだな!
逆キー索引も有効か???
でも、逆キー索引は範囲検索できないんだよな、確か。
パーティションオプション持ってるし、パーティショニング
してみるか!」
問題となっていそうな表と索引をハッシュパーティション化・・・
性能改善!更に、以前より20%程度の性能向上!
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
32
事例1 ~解説~
[原因]
連番データの insert が多重実行されるという特性であった為、
同一ブロックへの競合が発生しやすい状況であった。
そのような状況で過剰に索引を追加したことにより、ブロック競合
が多発した。
[対処]
1.丌要な索引の削除。
2.ハッシュパーティショニング。
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
33
事例1 ~解説~
索引がボトルネックになる場合もある。
- 更新系処理では、表データと同様に索引データの
更新も必要となる為、オーバヘッドがかかる。
- 連番データの insert が多重実行されるような場合
索引ブロックの競合が発生しやすい。
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
34
事例2 ~概要~
• システム概要
– 金融系システムのDB
– Oracle10gR1 4node RAC
• 状況
– 取引は月曜午前7時から土曜午前7時まで
– 土曜の日中にメンテナンス作業実施
– 月曜午前7時のオープン直後からDBの負荷が急上昇
– サーバハングによる障害発生
• 要望
– 障害調査を依頼
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
35
事例2 ~状況~
待機イベント
CPU使用率復旧障害
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
enqueue の TS(Temp Segment)、SS(Sort Segment)が増加している。
36
事例2 ~状況~
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
TEMP表領域への物理アクセスが多い。過剰なソートを実行しているSQLがある??
データファイル I/O
37
事例2 ~状況~
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
CPU_TIME と ELAPSED_TIME の差が大きい→ 待機イベント時間が長いということ!
高負荷 SQL
SQL [Hash Value=XXXXXXXXXX]------------------------------------------------------------SELECT ・・・ FROM TAB1 WHERE ・・・
DATE-TIME ROWS DISK_READS BUFFER_GETS CPU_TIME ELAPSED_TIME(YYYY/MM/DD HH24:MI:SS) EXEC /EXEC /EXEC /EXEC /EXEC(Sec) /EXEC(Sec)----------------------- ----- ------ ----------- ------------ ----------- -------------2009/11/02 07:45:15 652 1 20,836 21,654 8.542 38.334
SQL [Hash Value=??????????]--------------------------------------------------SELECT ・・・ FROM TAB2 WHERE ・・・
DATE-TIME ROWS DISK_READS BUFFER_GETS CPU_TIME ELAPSED_TIME(YYYY/MM/DD HH24:MI:SS) EXEC /EXEC /EXEC /EXEC /EXEC(Sec) /EXEC(Sec)----------------------- ----- ------ ----------- ------------ ----------- -------------2009/11/02 07:45:12 42 472 6,302 11,249 4.905 176.225
38
事例2 ~現場の様子~
この時の現場の様子をお届けします・・・
【土曜の日中】
Aさん 「古いデータを大量に削除したからフラグメンテーションを
解消しとかないとな。」
SQL> alter table EMP move;
SQL> alter index PK_EMP rebuild;
SQL> alter index IDX_EMP_1 rebuild;
SQL> alter index IDX_EMP_2 rebuild;
Aさん 「これで良し。さ、帰ろっと。」
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
39
事例2 ~現場の様子~
【月曜7時】
Aさんの携帯に運用監視オペレータから電話が・・・
OP 「Aさんっ!DBサーバのCPUが100%に張り付きっぱなしで
サービスが停まってます!」
Aさん 「えぇ!?すぐ確認します!」
Aさんはリモート接続してすぐに調査を開始。
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
40
事例2 ~現場の様子~
【月曜7時30分頃】
Aさん 「土曜にメンテナンスした表にアクセスしているSQLが
遅いみたいだな。実行計画が変わっちゃったみたい・・・
よし、統計情報を収集しよう!」
SQL> exec dbms_stats.gather_table_stats( -
ownname => 'SCOTT', -
tabname => 'EMP', -
cascade => true);
Aさん 「どうかなぁ・・・。」
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
41
事例2 ~現場の様子~
駄目だ!!
実行計画も変わってないようだ。
Aさん 「統計情報を再収集したから、再解析してる筈なんだ
けどなぁ・・・何で実行計画が変わってくれないんだろ。
ブツブツ・・・」
その後しばらく試行錯誤するも状況は改善せず・・・
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
42
事例2 ~現場の様子~
【月曜8時頃】
Aさん 『どうしよう・・・何か他に手はないかな。。。
あ、実行計画の問題だから共有プールも関係あるか?
とりあえずフラッシュしてみよう。』
SQL> alter system flush shared_pool;
Aさん 『ん?ちょっと負荷が下がってきたか?
おぉー!下がった下がった!よかった~』
これで一安心・・・
でも、かなり大きな損害が。。。
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
43
事例2 ~解説~
[原因]
以下のメンテナンス作業によって、表のオプティマイザ統計情報が
削除された。
1.表の再編成(move処理)
2.索引の再編成(rebuild処理)
その後、統計情報再収集を行わなかった為、デフォルトの統計情報
が利用され、結果的に適切な実行計画が選択されなかった。
(補足)
move処理後は索引が使用丌可(STATUS=UNUSABLE)となる為、
rebuild処理が必須。
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
44
事例2 ~解説~
[統計情報の収集後、実行計画が変わらなかったワケ]
dbms_stats.gather_table_stats の no_invalidate オプションが
auto_invalidate (10gR1以降のデフォルト値) だった為。
この auto_invalidate の場合、新しい統計情報を利用した再解析が
行われるまでにタイムラグがある。
(しばらくの間は既存のカーソルを再利用する)
[対策]
1.no_invalidate を false にして実行する ↓(実行例)
or
2.共有プールをフラッシュする
Copyright © 2010 Insight Technology, Inc. All Rights Reserved.
SQL> exec dbms_stats.gather_table_stats( -ownname => 'SCOTT', -tabname => 'EMP', -cascade => true, -no_invalidate => false);
46
製品のご紹介
データベース監査ツール
• データベースログ管理に必要なすべてを提供
するツール
• 300社、1,800ライセンスを超える販売実績
でJ-SOXおよび情報漏洩対策ツールのシェ
アNo.1
• 大規模顧客、大規模システムへの導入に強
み
• 対応データベース
Oracle Database EE/SE
Microsoft SQL Server(2000_32bit.2005_32bit)
Fujitsu Symfoware Server
パフォーマンス管理ツール
• パフォーマンス管理、パフォーマンスチューニ
ングを実現するツール
• 実績
1995年の販売以来、1,000社、8,000ライ
センスを超える販売実績。オラクルデータ
ベースの6本に1本の割合で導入されるパ
フォーマンスツールのデファクトスタンダード
• 対応データベース
Oracle Database EE/SE/SE1
※オラクルデータベースの6本に1本という数字は、特定パートナー様からの報告内容より引用しております。
Copyright © 2009 Insight Technology, Inc. All Rights Reserved.
47
おら!オラ!Oracle どっぷり検証生活
Oracleを徹底検証した結果を、隔週水曜日に配信しています。
Copyright © 2009 Insight Technology, Inc. All Rights Reserved.
ご登録はこちらから(無料!)http://www.insight-tec.com/mailmagazine/mailmagazine_index.html
本日のセミナーに関するお問い合わせなどご自由に・・・[email protected]