RACでのASHシーケンスの競合の特定

Oracle RAC Performance Tuningの第3章では、シーケンスの不適切なCACHE値がOracleRACのパフォーマンス低下を引き起こす可能性があることを示しました。また、セッションの待機イベントを確認するときにシーケンスの競合を特定する方法も示しました。

今日、私は新しいシーケンスを作成している開発者と一緒に働いていました。開発者のCACHE値は100でした。そのため、最初は値が低すぎました。コードレビュー中にこの低い設定を見つけました。開発者はCACHE値は問題ないと考えていますが、私は確信していません。これを負荷の下でテストして、CACHE値を調整する必要があるかどうかを確認します。

その間、私は「コードレビュー中にこれを見逃した場合はどうなるか」と考えていました。そして、次の質問、「負荷テスト中に何も気づかなかった場合はどうなりますか？」戻って、どのシーケンスが不適切なCACHE設定の候補になるかを判断できるようにしたいと思います。確かにセッションをトレースしてトレースファイルを分析することはできましたが、それは大変なことです。そこで、アクティブセッション履歴に対して実行できるスクリプトを考案して、候補シーケンスを決定するのに役立てました。

select sh.sql_id,to_char(st.sql_text),count(*)
from dba_hist_active_sess_history sh
join dba_hist_sqltext st
 on sh.sql_id=st.sql_id
where st.sql_text like '%NEXTVAL%'
 and (event='row cache lock' or event like 'gc current block %-way')
group by sh.sql_id,to_char(st.sql_text)
order by count(*) desc;

のようなイベント

ASHコレクションの性質上、これは完全な科学ではありません。競合が発生しているセッションは、DBA_HIST_ACTIVE_SESSION_HISTORYテーブルに入るのにちょうどいいタイミングでキャッチする必要があります。しかし、上記のSQLステートメントは、検討すべきいくつかの候補を私に与えてくれます。返されるSQLステートメントでアクセスされるすべてのシーケンスでCACHE値を調整する必要があるわけではありません。さらなる分析が必要になるでしょう。しかし、これは私に考慮すべきもののリストを与えてくれます。そして、それは私の最初の質問に答えるのに役立ちます。コードレビュー中にシーケンスの作成を見逃した場合、シーケンスがアプリケーションのパフォーマンスに問題があるかどうかを後で見つけることができれば幸いです。