待機中のイベント行キャッシュロック
Waiting Event Row Cache Lock
見つける方法:-クエリ行キャッシュロック待機select event、p1 from v $ session where event = 'row cache lock' and status = 'ACTIVE'-クエリrowcachename select * from v $ rowcache where cache#= p1
名前 | P1 | P2 | P3 | 原因 | 処理 |
行キャッシュロック | 辞書キャッシュ数値、値はV $ ROWCACHE.CACHE# | モード:モード開催 | リクエスト:要求されたモード | 行キャッシュロック待機イベントは、ディクショナリバッファへのアクセスによって引き起こされる共有プール関連の待機イベントです。各行バッファーのキューロックは、特定のデータディクショナリオブジェクトに対応します。これは、キューロックタイプと呼ばれ、次のようになります。V $ ROWCACHEビューで見つかりました。 AWRでは、問題を特定するために[ディクショナリキャッシュ統計]セクションを確認する必要があります。一般的な理由は次のとおりです。 1シーケンスが設定されていませんキャッシュ属性、シーケンスの競合を引き起こします 2テーブルスペースが不足しています 表スペースの待機速度は、表スペースの速度に追いつくことができません。 ③共有プール不十分、共有プールを増やす必要がある 4ユーザーパスワードが正しくないか、空白のパスワードが指定されており、ログインが頻繁に発生する | によるP1値クエリV $ ROWCACHE見る(V $ ROWCACHEからA.PARAMETERを選択AWHERE CACHE#= P1)キュータイプを決定します。場合DC_SEQUENCESシーケンスを増やすキャッシュ次の場合の値DC_USERSユーザーのパスワードが間違っているか、パスワードが空の場合、ユーザーは頻繁にログインし、クエリを照会して((SELECT * FROM DBA_AUDIT_TRAIL WHERE RETURNCODE IN(1017、1005)。1017間違ったパスワードに代わって、1005空白のパスワードを表します)他のタイプは共有プールリードするには小さすぎます。 |
実行DDL行バッファロックを要求する必要があります(行キャッシュロック)データディクショナリをロックする(データディクショナリ)情報。共有プール共有プール)データディクショナリからのラインバッファが含まれています。できるディスクを減らすI / O行にアクセスしてロックできるようにします。データディクショナリの行ロックは、行バッファキューロック(行キャッシュエンキューロック)。このキューロック構造は、これらの要求が待機してタイムアウトしたときに、共有プールからオンデマンドで割り当てられます会議行バッファキューロックを参照してください。行キャッシュロック待機イベントは、ディクショナリバッファへのアクセスによって引き起こされる共有プール関連の待機イベントです。各行バッファキューロックは、特定のデータディクショナリオブジェクトに対応します、これはキューロックタイプと呼ばれ、V $ ROWCACHEビューで見つかりました。
SELECT * FROM V $ EVENT_NAME D WHERE D.NAME = '行キャッシュロック'
選択する *
FROM DBA_HIST_ROWCACHE_SUMMARY D
1と3014の間のD.SNAP_IDの場所
AND D.GETS> 0
SELECT * FROM V $ ROWCACHE WHERE CACHE#IN( '7'、 '10')
V $ ROWCACHEからA.PARAMETERを選択AWHERE CACHE#= P1
SELECT * FROM DBA_AUDIT_TRAIL d WHERE / * RETURNCODE IN(1017)AND * / d.action_name = 'LOGON' AND D.returncode> 0 AND D.returncode1017
[root @ xxxxx〜] #oerr ora 1005
01005、00000、 'ログオンが拒否された場合のnullパスワード'
// *原因:
// *アクション:
[root @ xxxxx〜] #oerr ora 1017
01017、00000、「無効なユーザー名/パスワードのログオンが拒否されました」
// *原因:
// *アクション:
[root @ xxxxx〜]#
に時間表示する必要があります辞書キャッシュ統計問題を特定するために部分的に使用されます。
一般的なキューロックタイプ
行バッファのキューロック待機の調整は、各キューロックタイプの動作に基づいており、一般的なものは次のとおりです。
1 DC_SEQUENCES:この行バッファキューロックは、シーケンスが使用されるときに発生します。調整方法は、シーケンスでバッファリングオプションが指定されているかどうかを確認し、バッファ値が予想される同時挿入操作に耐えられるかどうかを判断することです。アプリケーション要件に応じて、シーケンスが適切にキャッシュされているかどうかを確認してください。
2 DC_USED_EXTENTSおよびDC_FREE_EXTENTS:この行バッファーのキュー・ロックは、スペース管理で表スペースの分割が発生した場合、または十分な領域サイズがない場合に発生する可能性があります。調整方法は、表スペースが分割されているかどうか、領域サイズが小さすぎるかどうか、または表スペースが手動で管理されているかどうかを確認することです。
3 DC_TABLESPACES:このラインバッファキューロックは、新しいゾーンを割り当てるときに発生します。ゾーンサイズの設定が小さすぎると、プログラムが新しいゾーンを頻繁に申請するため、競合が発生します。調整方法は、ゾーンの数をすばやく増やすことです。おそらく最も可能性の高い原因は、新しいエクステントの割り当てです。エクステントサイズが低く設定されている場合、アプリケーションは常に新しいエクステントを要求し、競合を引き起こしている可能性があります。成長している小さなエクステントサイズのオブジェクトはありますか? (エクステントの数が多いオブジェクトを探すことで、これらを見つけることができる場合があります)。トレースで挿入/更新アクティビティを確認し、挿入されたオブジェクトのエクステント数を確認します。
4 DC_OBJECTS:この行バッファキューロックは、オブジェクトが再コンパイルされるときに発生します。オブジェクトがコンパイルされると、他の動作をブロックするために排他ロックが適用されます。不正なオブジェクトと依存関係をチェックして調整します。
5 DC_SEGMENTS:この行バッファーのキューロックは、セグメントが割り当てられたときに発生し、キューロックを保持しているセッションが何をしているかを監視します。これは、セグメントの割り当てに起因する可能性があります。エンキューを保持しているセッションが実行していることを識別し、エラースタックを使用して診断します。
6 DC_USERS:デッドロックとその結果の「行キャッシュエンキューロックが長すぎます!」セッションがユーザーにGRANTを発行し、そのユーザーがデータベースにログオンしている場合に発生する可能性があります。dc_usersはユーザーのエラーです。11gでは、失敗したログオン試行の再試行を許可する間に意図的な遅延があります。一部の特定のアプリケーションタイプでは、遅延の間行キャッシュエントリがロックされるため、これにより問題が発生する可能性があります。ロックは、特定のユーザー/スキーマのDC_USERSを待機します。
..。
3回連続して障害が発生した後、スリープ遅延が3秒から始まり、最大10秒まで延長されます。各遅延の間、ユーザーXの行キャッシュロックは排他モードで保持され、ユーザーXとしての同時ログオン試行を防止します(また、ユーザーXの行キャッシュロックを必要とするその他の操作を防止します)。
ێDB_ROLLBACK_SEGMENTS:これはロールバックセグメントの割り当てによるものです。 dc_segmentsと同様に、エンキューを保持しているものを特定し、エラースタックも生成します。マルチノードシステム(RAC)では、ホルダーが別のノードにある可能性があるため、各ノードからの複数のシステム状態が必要になることに注意してください。
⑧DC_AWR_CONTROL:このエンキューは、自動ワークロードリポジトリの制御に関連しています。そのため、リポジトリを操作する操作はこれを保持する可能性があるため、これらをブロックしているプロセスを探してください。
DC_SEQUENCES
DC_SEQUENCESの場合、キャッシュオプションを使用してシーケンスをキャッシュすることを検討してください。
DC_OBJECTS
排他ロックを必要とし、他のアクティビティをブロックする可能性のあるオブジェクトコンパイルアクティビティを探します
DC_SEGMENTS
ここでの競合は、セグメントの割り当てが原因である可能性が最も高いです。その時点で作成されているセグメントを調査します。
DC_USERS
これは、セッションがユーザーにGRANTを発行し、そのユーザーがデータベースにログオンしているときに発生する可能性があります。ユーザーがアクティブなときに助成金が支払われる理由を調査します。
DC_TABLESPACES
最も可能性の高い原因は、新しいエクステントの割り当てです。エクステントサイズが低く設定されている場合、アプリケーションは常に新しいエクステントを要求し、競合を引き起こしている可能性があります。急速に成長している小さなエクステントサイズのオブジェクトがありますか? (エクステントの数が多いオブジェクトを探すことで、これらを見つけることができる場合があります)。トレースで挿入/更新アクティビティを確認し、挿入されたオブジェクトのエクステント数を確認します。
「行キャッシュロック」待機が発生する問題の解決(ドキュメントID 1476670.1)
このドキュメントでは
目的 |
トラブルシューティングの手順 |
問題の確認: |
行キャッシュロック |
待ち時間の削減 |
既知の問題点 |
参考文献 |
に適用されます:
OracleDatabase-StandardEdition-バージョン10.2.0.1以降Oracle Database-EnterpriseEdition-バージョン10.2.0.1以降
Oracle Database-PersonalEdition-バージョン10.2.0.1以降
このドキュメントの情報は、すべてのプラットフォームに適用されます。
目的
免責事項:このメモは、パフォーマンスガイド付き解決ツールが使用され、この記事を推奨したという文脈で書かれています。スタンドアロンで読んだり、他の読者が読んだりすると、あまり意味がない場合があります。
トラブルシューティングの手順
簡単な定義:
共有プールには、データディクショナリテーブルの物理I / Oを削減するのに役立つデータディクショナリの行のキャッシュが含まれています。行キャッシュロックは、主にデータディクショナリへの変更をシリアル化するために使用され、データディクショナリキャッシュのロックが必要になると待機します。このイベントの待機は通常、何らかの形式のDDLが発生していること、またはストレージ管理やシーケンス番号の増分などの再帰的な操作を示している可能性があります。
問題の確認:
- ラッチの大幅な待機:行キャッシュオブジェクト
- 行キャッシュロックによる全体的なパフォーマンスの低下
- 高いCPU使用率
行キャッシュロック
DDLが実行されると、データディクショナリ情報にアクセスして変更するために、行キャッシュのロックを取得する必要があります。ロックが取得されると、データディクショナリの個々の行を変更できるようになります。
待ち時間の削減
1.データディクショナリは共有プールにあります。共有プールのサイズが正しくない場合、データディクショナリが完全にキャッシュされていない可能性があります。これは、自動共有メモリ調整機能を使用して自動的に処理する必要があります。次のドキュメントに詳細が記載されています。
文書270935.1 共有プールのサイズ設定
2.待機しているキャッシュを見つけます。
SQL> select p1text、p1、p2text、p2、p3text、p3 from v $ session where event = 'row cache lock'
P1TEXT P1 P2TEXT P2 P3TEXT P3
キャッシュID8モード0リクエスト3
SQL> select parameter、count、gets、getmisses、modifications from v $ rowcache where cache#= 8
パラメータ数がGETMISSESの変更を取得
DC_SEQUENCES869 76843 508432 4500
この例では、キャッシュは「DC_SEQUENCES」キャッシュです。
3.キャッシュに依存するアクションを実行します。
DC_SEQUENCES
DC_SEQUENCESの場合、キャッシュオプションを使用してシーケンスをキャッシュすることを検討してください。
DC_OBJECTS
排他ロックを必要とし、他のアクティビティをブロックする可能性のあるオブジェクトコンパイルアクティビティを探します
DC_SEGMENTS
ここでの競合は、セグメントの割り当てが原因である可能性が最も高いです。その時点で作成されているセグメントを調査します。
DC_USERS
これは、セッションがユーザーにGRANTを発行し、そのユーザーがデータベースにログオンしているときに発生する可能性があります。ユーザーがアクティブなときに助成金が支払われる理由を調査します。
DC_TABLESPACES
最も可能性の高い原因は、新しいエクステントの割り当てです。エクステントサイズが低く設定されている場合、アプリケーションは常に新しいエクステントを要求し、競合を引き起こしている可能性があります。急速に成長している小さなエクステントサイズのオブジェクトがありますか? (エクステントの数が多いオブジェクトを探すことで、これらを見つけることができる場合があります)。トレースで挿入/更新アクティビティを確認し、挿入されたオブジェクトのエクステント数を確認します。
4.行キャッシュの問題の詳細については、以下を確認してください。
文書278316.1 トラブルシューティング「行キャッシュエンキューロックが長すぎます!」成功の測定
見つけた問題を解決するために変更を適用したら、最新のAWRを、ガイド付き解決を介してここに導いたAWRと比較します(AWRがベースラインになります)。このイベントの合計待機時間の減少率を確認してください。それでも問題が解決しない場合は、問題を再評価し、特定の症状に応じて対処してください。
既知の問題点
文書1417373.1 VPD使用中のDC_USERSの行キャッシュラッチの競合文書2372926.8 DC_USERS行キャッシュでの「行キャッシュオブジェクト」ラッチの競合
文書1466896.1 11.2.0.3にアップグレードした後、パイプライン化された関数で「行キャッシュロック」の待機時間が長くなる
文書13502860.8 バグ13502860-PIPELINED関数を使用したSYS_PLSQL_xxオブジェクトでの「行キャッシュロック」の競合
参考文献
注:34609.1 --WAITEVENT: '行キャッシュロック'リファレンスノート
WAITEVENT: '行キャッシュロック'リファレンスノート(ドキュメントID 34609.1)
「行キャッシュロック」リファレンスノート
これは待機イベントのリファレンスノートです 「行キャッシュロック」 これには、次のサブセクションが含まれます。- 簡単な定義
- 個別待機詳細 (例:で見られる待機の場合 V $ SESSION_WAIT )。
- システム全体の待機の詳細 (例:で見られる待機の場合 V $ SYSTEM_EVENT )。
- 待ち時間/待ち時間の短縮
- トラブルシューティング
- 既知のバグ
定義:
バージョン: 7.3-12.1ドキュメンテーション: 12.1 11.2 11.1 10.2 10.1
このイベントは、「キャッシュID」(P1)で指定されたデータディクショナリキャッシュのロックを待機するために使用されます。
Real Application Clusters(RAC)を実行している場合、LCK0は、このイベントを待機しているフォアグラウンドの行キャッシュロックを取得するように通知されます。 LCK0プロセスは、非同期でロックを取得します。排他モードでは、フォアグラウンドプロセスがロックを取得しようとします。
個別の待機:
パラメーター:
P1 = キャッシュ -辞書キャッシュのID P2 = モード -モード保持 P3 = リクエスト -要求されたモード- キャッシュ -辞書キャッシュのID
待っている行キャッシュロック。実際のCACHE#値はOracleのバージョン間で異なることに注意してください。キャッシュは、この選択を使用して見つけることができます-'PARAMETER 'はキャッシュ名です:
SELECT cache#, type, parameter FROM v$rowcache WHERE cache# = &P1
RAC環境では、行キャッシュロックはタイプ 'のグローバルエンキューを使用します Q [A-Z] 'ロックIDはハッシュされたオブジェクト名です。
- モード -モード保持
ロックが現在保持されているモード:
KQRMNULL 0 null mode - not locked KQRMS 3 share mode KQRMX 5 exclusive mode KQRMFAIL 10 fail to acquire instance lock
- リクエスト -要求されたモード
ロックが要求されるモード:
KQRMNULL 0 null mode - not locked KQRMS 3 share mode KQRMX 5 exclusive mode KQRMFAIL 10 fail to acquire instance lock
待ち時間:
排他モードでは、PMON以外のプロセスは8時間後にタイムアウトします(3秒の10000待機)RACでは、フォアグラウンドはLCK0がロックを取得するまで60秒間待機し、フォアグラウンドはロックが付与されるまで無限ループで待機します(LCK0はフォアグラウンドに通知します)。
いずれの場合も、PMONは5秒間だけ待機します。
行キャッシュロックを待機しているときにセッションがタイムアウトすると、次のようなメッセージでアラートログとトレースファイルに報告されます。
WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK
ブロッカーの検索:
ホルダーとリクエスターは、親オブジェクトの場合はビューX $ KQRFPに、従属オブジェクトの場合はX $ KQRFSに表示されます。
例:次の選択では、親行キャッシュオブジェクトのすべてのホルダーが表示されるため、ブロッキングセッションの検索に使用できます。SELECT * FROM x$kqrfp WHERE kqrfpmod!=0(KQRFPSESは、開催セッションV $ SESSION.SADDRのアドレスです)
システム全体の待機:
どのキャッシュが待機されているかを判別することが重要です。 V $ ROWCACHEビューには、最も使用されているキャッシュの概要が表示されますが、待機は必ずしも最も使用されているキャッシュで行われるとは限りません。 V $ ACTIVE_SESSION_HISTORYビューを使用して、待機に関係しているキャッシュID(P1)を把握できます。 問題がさまざまなキャッシュ(異なるキャッシュID)に共通している場合は、より多くのディクショナリ情報をキャッシュできるように、共有プールのサイズを増やす必要がある場合があります。 問題が特定のキャッシュIDに焦点を当てている場合、オプションは通常、関連するキャッシュによって異なります。 トラブルシューティング 以下のセクション。
待機時間の短縮/待機時間:
待機を減らすオプションは、競合がある特定のキャッシュによって異なります。さまざまなキャッシュに関するアドバイスについては、以下のトラブルシューティングセクションのドキュメントを参照してください。
トラブルシューティング
「行キャッシュロック」待機に関連する問題のトラブルシューティングについては、次のドキュメントを参照してください。 文書:1476670.1 「行キャッシュロック」待機が発生する問題の解決
文書:278316.1 トラブルシューティング「行キャッシュエンキューロックが長すぎます!」
既知の問題/バグ:
関連するボタンをクリックすると、以下のリストを次のバージョンのいずれかに影響を与える可能性のある問題に制限できます。
'*'その問題に対するアラートが存在することを示します。'+'特に注目すべき問題/バグを示します。 見る 注:1944526.1 使用されている他の記号の詳細については
NB 確率 バグ 修繕 説明 - 17828499 12.1.0.1.4、12.1.0.2、12.2.0.1 PDBを開くと、開いているアップグレードで行キャッシュロックを待機してハングします - 16921340 12.1.0.1.1、12.1.0.2、12.2.0.1 非CDBからPDBへのプラグインがハングする イル 13884774 12.1.0.2、12.2.0.1 query_rewrite_enabledがtrue / forceに設定されている場合、同時選択/ ALTERSUMMARYおよびALTERTABLEからのデッドロック-置き換えられました イル 16994952 12.1.0.1 CJQの自己デッドロック/ハングが原因で伝播のスケジュールを解除できません イル 14117976 11.2.0.3.BP14、11.2.0.4、12.1.0.1 複数のMVDDLを並行して実行すると、データベースがハングする III 13496395 11.2.0.4、12.1.0.1 LOGONとALTERUSERを同時に実行するためのACCOUNT_STATUSオブジェクトに関連するハング/デッドロック III 7715339 11.2.0.1 ログオンに失敗すると、「行キャッシュロック」が待機します-ログオン遅延の無効化を許可します III 21153142 12.2.0.1 シードPDBにアクセスする行キャッシュロックの自己デッドロック イル 21091431 12.1.0.2.160419、12.1.0.2.DBBP13、12.2.0.1 エディションを使用したトリガー作成中の行キャッシュロック イル 19907473 12.2.0.1 データベースのハングを引き起こすGEN0プロセス III 15850031 11.2.0.4、12.1.0.2、12.2.0.1 まれなインスタンスのハング:「行キャッシュロック」と「カーソル:ピンSがXを待機」の間のデッドロック イル 13622515 11.2.0.4、12.1.0.2、12.2.0.1 ライブラリキャッシュ行キャッシュデッドロック/ MVが関係する制約を変更するとハングする-置き換えられました イル 13869467 12.1.0.2 制約付きのテーブルを多数作成している間、RACで「行キャッシュロック」を待機する人が多い イル 13979519 11.2.0.3.BP11、11.2.0.4、12.1.0.1 dc_usersのロックが長すぎます イル 13916228 11.2.0.4、12.1.0.1 制約を有効/無効にすると、RACでDMLタイムアウトが発生します-置き換えられました イル 13502860 11.2.0.4、12.1.0.1 PIPELINED関数を使用したSYS_PLSQL_xxオブジェクトでの「行キャッシュロック」の競合 - 13387978 11.2.0.4、12.1.0.1 制約が無効になっている場合でも、TRUNCATEを実行しているセッションがデッドロックを引き起こしている - 12953743 11.2.0.3.BP13、11.2.0.4、12.1.0.1 Securefileを使用したテーブルの並列CTASは、並列IAS / PIDLよりも低速です。 私 12889054 11.2.0.2.BP16、11.2.0.3.BP05、11.2.0.4、12.1.0.1 AWRスナップショットがctasジョブによって保持されているdc_objectsrow_cache_lockでハングする D - 12792862 11.2.0.4、12.1.0.1 バイナリxmlを使用したINSERTのパフォーマンスは、RAC環境の「行キャッシュロック」のために非常に遅くなります-置き換えられました イル 12351027 11.2.0.4、12.1.0.1 「行キャッシュロック」と「ライブラリキャッシュロック」の間にデッドロックを引き起こす再定義 イル 11693365 11.2.0.3、12.1.0.1 同時ドロップテーブルと参照オン参照制約テーブルがハングします(デッドロック) 私 10382754 11.2.0.2.BP17、11.2.0.3、12.1.0.1 オブジェクトの無効化によるパーティショニングを伴う11gでのパフォーマンスの低下/行キャッシュの競合 IIII 10204505 11.2.0.3、12.1.0.1 SGAの自動調整により、行キャッシュのミス、ライブラリキャッシュの再読み込み、解析が発生する可能性があります イル 10126219 11.2.0.1.BP08、11.2.0.2.BP02、11.2.0.3、12.1.0.1 未検出のデッドロック 'ライブラリキャッシュロック' / '行キャッシュロック'とパーティションテーブルの同時DDL。 イル 9952554 11.2.0.2.8、11.2.0.2.BP18、11.2.0.3、12.1.0.1 制約を変更するセッションでの未検出のデッドロック 'ライブラリキャッシュロック' / '行キャッシュロック' イル 9866045 11.2.0.3、12.1.0.1 LCKで「マスターscnを待機」を長時間待機すると、長い行のキャッシュロック待機が発生します III 9776608 11.2.0.2、12.1.0.1 間違ったパスワードで同じアカウントに同時ログインからハングアップする イル 9278979 11.2.0.2、12.1.0.1 インスタンスのハング/ OPTIMIZER_USE_PENDING_STATISTICS = trueのORA-4021 私 8268775 11.1.0.7.4、11.2.0.1.2、11.2.0.1.BP07、11.2.0.2、12.1.0.1 ログインストームまたはセッションフェイルオーバー中の米国の高いエンキュー競合 - 8364676 11.1.0.7.2、11.2.0.1 行キャッシュロックは、バックグラウンドスペースの事前割り当てから待機します III 7529174 10.2.0.5、11.1.0.7.3、11.2.0.1 SMONとフォアグラウンドプロセス間のデッドロック/ハング - 7416901 11.1.0.7.1、11.2.0.1 CELL_PARTITION_LARGE_EXTENTS = ALWAYSの場合、QCスレーブとPQスレーブ間のデッドロック イル 7313166 10.2.0.5、11.2.0.1 dc_rollback_segmentsでセルフデッドロックが発生してスタートアップがハングする イル 6870994 10.2.0.5、11.1.0.7.3、11.2.0.1 新しい元に戻すセグメントをオンラインにしようとしているときに、米国のエンキュー/行キャッシュロックが高い III 6027068 10.2.0.5、11.2.0.1 ORA_TQ_BASE $シーケンスでの競合 - 5756769 10.2.0.4.1、10.2.0.5、11.1.0.7、11.2.0.1 CreateMVIEWとDMLの間のデッドロック III 6143420 10.2.0.5、11.1.0.6 dc_usersの「ROWCACHELOCK」と「CURSOR:PIN S WAIT ONX」に関連するデッドロック III 6004916 10.2.0.5、11.1.0.6 RACの行キャッシュエンキューを含むハング(ORA-4021) イル 5883112 10.2.0.4、11.1.0.6 RACでの誤ったデッドロック イル 5138741 10.2.0.4、11.1.0.6 RACでマテリアライズド・ビューを使用する場合、「行キャッシュ・ロック」の待機時間が長くなります イル 4604972 11.1.0.6 同時付与/取り消しによるdc_usersのデッドロック - 4579381 10.1.0.5、10.2.0.2、11.1.0.6 RACのDC_USERSでのデッドロック(ORA-4020) - 4446011 9.2.0.8、10.1.0.5、10.2.0.2、11.1.0.6 同時ALTERUSER / TRUNCATEからの行キャッシュロックデッドロックでハングする イル 4390868 10.1.0.5、10.2.0.3、11.1.0.6 SYS.AUDSES $のキャッシュサイズが小さいため、DC_SEGMENTSで競合が発生します - 4313246 9.2.0.8、10.1.0.5、10.2.0.2、11.1.0.6 PLSQLの実行により、dc_users行のキャッシュロックが保持され、ハング/デッドロックが発生する可能性があります 私 4153150 9.2.0.8、10.2.0.2、11.1.0.6 並行ロードと元に戻すセグメントの作成の同時実行によるdc_rollback_segmentsのデッドロック 私 6051177 10.2.0.4.1、10.2.0.5 合体とDBMS_STATS.gather_table_stats間のハング/デッドロック - 5983020 10.2.0.4 ALTERUSERを実行しているユーザーセッションでのMMONデッドロック - 4275733 9.2.0.8、10.1.0.5、10.2.0.1 同時名前変更パーティションからのライブラリキャッシュロックと行キャッシュロック間のデッドロック 私 5641198 10.2.0.1 RACでは、待機時間が必要以上に長くなる場合があります(「行キャッシュロック」)。 - 4137000 10.1.0.5、10.2.0.1 同時SPLITPARTITIONは、デッドロック/ハングする可能性があります - 3627263 9.2.0.6、10.1.0.4、10.2.0.1 RACインスタンスの起動中にデッドロック/ハングが発生する イル 3424721 9.2.0.6、10.1.0.3、10.2.0.1 並行SQLを使用するパーティションでのALTERINDEXREBUILDからのハング/デッドロック - 2615271 9.2.0.6、10.1.0.2 GRANTとログオンの同時実行によるデッドロック
関連:
文書:1628089.1 データベースのパフォーマンスの問題を診断するためのAWRレポート解釈チェックリスト
文書:1359094.1 AWRレポートを使用してデータベースのパフォーマンスの問題を診断する方法
文書:1274511.1 一般的なSQL_TRACE / 10046トレース収集の例
トラブルシューティング: '行キャッシュエンキューロックが長すぎます! '(ドキュメントID 278316.1)
トラブルシューティング:「行キャッシュエンキューロックが長すぎます!」 (ドキュメントID 2016422.1)
ドキュメントの内容
使用する |
トラブルシューティングの手順 |
行キャッシュエンキューロック(行キャッシュエンキューロック)とは何ですか? |
「行キャッシュエンキューロックが長すぎます!」警告はどういう意味ですか? |
「行キャッシュエンキューロックが長すぎます!」考えられる原因 |
SGAの縮小/サイズ変更操作(サイズ変更) |
行キャッシュエンキュータイプ |
DC_TABLESPACES |
DC_SEQUENCES |
DC_USERS |
DC_OBJECT_IDS |
DC_SEGMENTS |
DC_ROLLBACK_SEGMENTS |
DC_TABLE_SCNS |
DC_AWR_CONTROL |
原因を特定するためにどのような情報を収集できますか? |
システム状態ダンプ |
AWR、ADDM、およびASHレポート |
収集した診断情報を分析する方法は? |
システム状態ダンプ |
例1: |
例2: |
時間レポート |
以前のバージョンの10gで発生する可能性のある問題 |
その他の問題のトラブルシューティング |
参照 |
に適用されます:
Oracle Database-PersonalEdition-バージョン8.0.6.0以降Oracle Database-EnterpriseEdition-バージョン8.0.6.0以降
Oracle Database-StandardEdition-バージョン8.0.6.0以降
このドキュメントに含まれる情報は、すべてのプラットフォームに適用されます
使用する
このドキュメントの目的は、原因のトラブルシューティングを支援することです。 '
トラブルシューティングの手順
行キャッシュエンキューロック(行キャッシュエンキューロック)とは何ですか?
行キャッシュまたはデータディクショナリキャッシュは、データディクショナリ情報を保持する共有プールのメモリ領域です。行キャッシュは、データをデータブロックの形式ではなく、行の形式で保存します。行キャッシュエンキューロックは、データディクショナリ行のロックです。このエンキューは、特定のデータディクショナリオブジェクトに関するものです。これはいわゆるエンキュータイプであり、ビューV $ rowcacheにあります。
各バージョンの行キャッシュタイプのリストについては、以下を参照してください。
「行キャッシュエンキューロックが長すぎます!」警告メッセージはどういう意味ですか?
行キャッシュロックを取得しようとすると、この待機イベントが使用されます。
行キャッシュの競合が発生した場合、所定の期間内にエンキューを取得できないと、ユーザーまたはバックグラウンドプロセスのどちらが作成したかに応じて、トレースファイルがUSER_DUMP_DESTまたはbackground_dump_destディレクトリに生成されます。ファイルを追跡します。 alert.logは通常、警告メッセージとトレースファイルの場所を適宜更新します。
データベースは、コアリソースが長期間保持されていることを検出し、この状況を解決できることを管理者に通知します。これには、データベースのハングまたは速度低下が伴う場合もあります。
alert.logメッセージと生成されたトレースファイルには、次のメッセージが含まれる傾向があります。
行キャッシュエントリロックをすぐに取得できない場合は、ループに入り、最初に行キャッシュオブジェクトのラッチを解放し、待機して(上記の待機イベントを待機)、ラッチを取り戻し、行キャッシュロックの取得を再試行します。シングルインスタンスモードでは、プロセスが「WAITED TOO LONG FOR A ROW CACHEENQUEUELOCK」と報告するまで1000回繰り返されます。 RAC環境は、インスタンスロックが使用できなくなるか、中断されるまで繰り返されます。
Systemstateダンプは、競合の原因を診断するためのいくつかの有用な情報を提供できます。
「行キャッシュエンキューロックが長すぎます!」考えられる原因
SGAの縮小/サイズ変更操作(サイズ変更)
SGAが動的にサイズを変更する場合は、操作が完了するまで他のプロセスが同時に操作されないように、さまざまなラッチを保持する必要があります。サイズ変更に時間がかかる場合、または頻繁に発生する場合は、「WAITED TOO LONG FOR A ROW CACHE ENQUEUELOCK!」が表示されます。この状況を特定する方法は、「SGA:割り当て強制コンポーネントの増加」待機イベントが多数あるか、AWRのTOPリストに同様の待機があり、セッションが「WAITED TOO LONG FOR A ROW CACHE ENQUEUELOCK!」を待機していることです。 「SGA:コンポーネントの拡張を強制する割り当て」(または同様のもの)を待機しています。利用可能なコード修正がいくつかあります。以下を参照してください。
文書7189722.8 バグ7189722-頻繁なSGAサイズ変更操作の拡大/縮小文書9267837.8 バグ9267837-Auto-SGAポリシーで、必要以上に大きなサイズ変更が表示される場合があります
行キャッシュエンキュータイプ
エンキュータイプごとに、そのようなエンキューを必要とする操作がいくつかあります。操作によって引き起こされる可能性のある問題を示す可能性のあるキューのタイプ。一般的な理由は次のとおりです。
DC_TABLESPACES最も可能性の高い原因は、新しいエクステントの割り当てです。エクステントサイズの設定が小さすぎると、アプリケーションが継続的に新しいエクステントを要求する可能性があり、その結果、競合が発生する可能性があります。あなたは小さなエクステントサイズ、急速に成長しているオブジェクトを持っていますか? (エクステントの数が多いオブジェクトを探すことで、それらを見つけることができます)。挿入/更新アクティビティのトレースを調べて、多くのエクステントを持つオブジェクトを見つけます。
DC_SEQUENCESアプリケーションが使用するシーケンスのキャッシュのサイズを確認します。
文書853652.1 RACとシーケンス文書395314.1 SYS.AUDSES $のキャッシュサイズが小さいためにRACがハングする-10.2.0.3で修正済み
文書6027068.8 バグ6027068-10.2.0.5および11.2.0.1で修正されたORA_TQ_BASEシーケンスの競合 DC_USERS
ユーザーがデータベースにログインしているときに、セッションがユーザーに対してGRANTを実行しています。その時点で、デッドロックが発生したり、「WAITED TOO LONG FOR A ROW CACHE ENQUEUELOCK!」が発生したりする可能性があります。 '。
文書4604972.8 バグ4604972-同時付与/取り消しによるdc_usersのデッドロック-11.1.0.6で修正文書6143420.8 バグ6143420-10.2.0.5および11.1.0.6DC_OBJECTSで修正されたdc_usersおよび 'CURSOR:PIN S WAIT ONX'の 'ROW CACHELOCK'に関連するデッドロック
文書12772404.8 バグ12772404-VPDを使用する場合の重要な「行キャッシュオブジェクト」ラッチの競合 DC_OBJECT_IDS 文書11693365.8 バグ11693365-コンカレントドロップテーブルとSelecton Reference制約テーブルがハングする(デッドロック)-12.1で修正されました DC_SEGMENTS
これは、セグメントの割り当てが原因である可能性があります。ロックを保持しているユーザーが何をしているかを判別し、診断にエラースタックを使用します。
DC_ROLLBACK_SEGMENTSこれは、ロールバックセグメントの割り当てが原因である可能性があります。 dc_segmentsと同様に、誰がロックを保持しているかを判別し、診断のためにエラースタックを収集します。マルチノードシステム(RAC)では、ホルダーが別のノードにある可能性があるため、すべてのノードのシステム状態が必要であることに注意してください。
DC_TABLE_SCNS 文書5756769.8 バグ5756796-CreateMVIEWとDML間のデッドロック-10.2.0.5、11.1.07、および11.2.0.1で修正 DC_AWR_CONTROLこのエンキューは、AWR(自動ワークロードリポジトリ)の制御に関連しています。 AWRリポジトリを操作する操作はすべてそれを保持します。この問題を分析するには、どのプロセスがそれらをブロックしているかを見つける必要があります。
RAC関連のバグ
文書8666117.8 バグ8666117-RACでの高行キャッシュラッチの競合-11.2.0.2および12.1で修正
文書9866045.8 バグ9866045-LCKで「マスターscnを待機」で長時間待機すると、長い行のキャッシュロック待機が発生します-12.1で修正されました
原因を特定するためにどのような情報を収集できますか?
システム状態ダンプ
問題が発生すると、エラーがalert.logに記録され、システム状態ダンプファイルが自動的に生成されます。
2011年9月21日水曜日13:39:19>列キャッシュエンキューロックが長すぎます! pid = 37
システム状態がトレースファイル/oracle/diag/rdbms/..../.trcにダンプされました
AWR、ADDM、およびASHレポート
2つのAWRレポートを収集します。1つは問題のある期間があり、もう1つは問題のない期間があります。これらは、問題が発生したときのデータベースのステータスを理解するのに役立ちます。 AWR、ADDM、ASHレポートは、問題全体をより完全に理解するために相互に補完することができます。
AWRスナップショットが生成される時間間隔に応じて、最小時間間隔のレポートが収集されます。デフォルトのスナップショットは1時間間隔です。
SQL> @ $ ORACLE_HOME / rdbms / admin / addmrpt.sql
SQL> @ $ ORACLE_HOME / rdbms / admin / ashrpt.sql
システム状態の分析は非常に複雑な問題であるため、問題が発生する前後に、サービスリクエストを作成し、alert.log、システム状態ダンプ、およびAWRレポートをアップロードできます。分析するテクニカルサポート。
収集した診断情報を分析するにはどうすればよいですか?
システム状態ダンプ
通常、行キャッシュエンキューは一連のイベントの一部であり、行キャッシュエンキューを要求するプロセスをブロックしているプロセスは、別のプロセスによってブロックされる可能性があります。行キャッシュのエンキューは、多くの場合、問題のように見えます。
Systemstateダンプは、適用されている行キャッシュを見つけるのに役立ち、ブロッキングプロセスを見つけるのに役立つ場合があります。
Unixプロセスpid:10846、イメージ:root @ xxxxx
*** 2011-05-13 08:08:58.775
***サービス名:(ALFCMR_SERVICE)2011-05-13 08:08:58.775
***セッションID:(1076.796)2011-05-13 08:08:58.775
>列キャッシュエンキューロックが長すぎます!<<<
行キャッシュエンキュー:セッション:0x1df57ade8、モード:N、リクエスト:S
トレースタイトルは次のことを示しています。
- 行キャッシュのエンキューロックを待機しているOracleプロセス番号(PID)(この場合はプロセス77)。
- 要求されている行キャッシュエンキューのモード(要求:S)。
したがって、上記の例では、プロセス77は共有モードで行キャッシュ(要求:S)を要求しています。
Systemstateには、データベース内の各プロセスの状態情報が含まれているため、このプロセスはsystemstateで見つけることができます。
----------------------------------------
。
。
----------------------------------------
SO:0x1cdf11958、タイプ:50、所有者:0x17d198288、フラグ:INIT /-/-/ 0x00
行キャッシュエンキュー:count = 1 session = 0x1df57ade8 object = 0x1dc9a5d30、request = S
セーブポイント= 0x87b70d
行キャッシュの親オブジェクト:address = 0x1dc9a5d30 cid = 7(dc_users)
。
。
上記からわかるように、プロセス77は共有モードに行キャッシュdc_usersを取得するように要求します。
プロセス77は待機状態にあります。つまり、他のプロセスによってブロックされています。ここで、systemstateをチェックして、誰がリソースを保持し、プロセスをブロックしているかを判断する必要があります。
参照されているオブジェクト(この場合はobject = 0x1dc9a5d30)を検索します。
これを行った後、プロセス218がこのオブジェクトを排他モードで保持していることがわかりました。
----------------------------------------
。
。
SO:0x1cdf118f8、タイプ:50、所有者:0x1ceb0f178、フラグ:INIT /-/-/ 0x00
行キャッシュエンキュー:count = 1 session = 0x1da54cf68 object = 0x1dc9a5d30、 request = X
savepoint = 0x11e
行キャッシュの親オブジェクト:address = 0x1dc9a5d30 cid = 7(dc_users)
排他モードの要求は、プロセスの排他モードの要求が満たされ、リソースが後で解放されるまで、共有モードの要求をブロックします。したがって、これは他の共有モード要求をブロックします。これは排他的ではなく要求の独占であるため、この要求もブロックする必要があることに注意してください。他のプロセスを見ると、プロセス164がこのオブジェクトを共有モード(mode = s)で保持していることがわかります。
----------------------------------------
。
。
O / S情報:ユーザー:u1m、用語:、ospid:1234、マシン:cpc44711
プログラム:
最後に「クライアントからのSQL * Netメッセージ」を待ちます ブロッキングsess = 0x(nil)seq = 36289 wait_time = 6943待機開始から6943秒= 2539
ドライバーID = 54435000、#bytes = 1、= 0
。
。
SO:0x1cdf11418、タイプ:50、所有者:0x1ccc26120、フラグ:INIT /-/-/ 0x00
行キャッシュエンキュー:count = 2 session = 0x1df578318 object = 0x1dc9a5d30、mode = S
savepoint = 0xb1bd8e
行キャッシュの親オブジェクト:address = 0x1dc9a5d30 cid = 7(dc_users)
hash = fc968070 typ = 11トランザクション=(nil)フラグ= 00000002
own = 0x1dc9a5e00 [0x1cdf11448,0x1cdf11448] wat = 0x1dc9a5e10 [0x1cdf11928,0x17d5192e0] mode = S
したがって、プロセス164は、共有モードで行キャッシュエンキュー(モード= S)を保持し、それにより、プロセス218が排他モードで行キャッシュエンキューを取得することを防止する。さらに、プロセス164がオンCPU上にあることがわかります(systemstateは、最後の待機が「クライアントからのSQL * Netメッセージ」ではなく「クライアントからのSQL * Netメッセージ」であることを示しています)。さらに診断を行うには、テクニカルサポートがスタック呼び出しをチェックして、プロセスがON CPU上にある理由を特定し、キューを長時間保持する必要があります(開始から2539秒が経過しています)。
この例では、プロセス18(MMON)は、共有モードでタイプdc_awr_controlの行キャッシュを取得するのを待機します。
パーティショニング、Oracle Label Security、OLAP、DataMiningを使用
および実際のアプリケーションテストオプション
ORACLE_HOME = /opt/oracle10/product/10.2.0
システム名:SunOS
ノード名:saecopt51
リリース:5.10
バージョン:Generic_144488-04
マシン:sun4v
インスタンス名:PORT_V16
このインスタンスによってマウントされたREDOスレッド:1
Oracleプロセス番号:18
Unixプロセスpid:6196、イメージ:root @ xxxxx(MMON)
。
。
プロセス18:
----------------------------------------
。
。
最後の待機 'ksdxexeotherwait' wait_time = 0.000013秒、待機開始からの秒数= 6
。
。
SO:39bf1f0e8、タイプ:50、所有者:3980783a0、フラグ:INIT /-/-/ 0x00
行キャッシュエンキュー:count = 1 session = 3be37ea80 オブジェクト= 39a79f090、リクエスト= S
savepoint = 0x41f0ae
行キャッシュの親オブジェクト: アドレス= 39a79f090cid = 22(dc_awr_control)
hash = 6f60197e typ = 9トランザクション= 3bc39f560フラグ= 0000002a
独自= 39a79f160 [39bf1f178,39bf1f178]ワット= 39a79f170 [39bf1f118,39bf1f118]モード= X
。
。
オブジェクト(オブジェクト= 39a79f090)の行キャッシュロックは、排他モード(モード= x)でプロセス269によって保持される。プロセスは「SGA:コンポーネントの拡張を強制する割り当て」を待機しています。
----------------------------------------
。
。
「SGA:コンポーネントの成長を強制する割り当て」を待っています wait_time = 0、待機開始からの秒数= 3
。
。
SO:39bf1f148、タイプ:50、所有者:3bc39f560、フラグ:INIT /-/-/ 0x00
行キャッシュエンキュー:count = 1 session = 3be1b7c98 オブジェクト= 39a79f090、モード= X
savepoint = 0x41efe8
行キャッシュの親オブジェクト: アドレス= 39a79f090cid = 22(dc_awr_control)
hash = 6f60197e typ = 9トランザクション= 3bc39f560フラグ= 0000002a
独自= 39a79f160 [39bf1f178,39bf1f178]ワット= 39a79f170 [39bf1f118,39bf1f118]モード= X
。
。
したがって、根本的な原因はSGAのサイズ変更であり、行キャッシュが2次的な結果になるのを待ちます。
この期間のAWRレポートを使用して、関連情報を確認します。
時間レポート
Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time Wait Class ------------------------------ ------------ ----------- ------ ------ ---------- SGA: allocation forcing compon 42,067,317 38,469 1 7.6 Other CPU time 2,796 0.6 db file sequential read 132,906 929 7 0.2 User I/O latch free 4,282,858 704 0 0.1 Other log file switch (checkpoint in 904 560 620 0.1 Configurat -------------------------------------------------------------
トップ5の待機イベントでは、システム全体でこのイベントを大幅に待機しており、「SGA:コンポーネントの拡張を強制する割り当て」がこの時点であることがはっきりとわかります。大きな問題です。 「行キャッシュエンキューロックが長すぎます!」メッセージの根本的な原因はメモリ調整アクティビティであり、TOP5の待機イベントは「行キャッシュ」症状の待機さえ示していません。
メモリサイズがそれほど厳しくない場合は、「行キャッシュエンキューロックが長すぎます!」がない場合があります。メッセージ。 -主に、前述のしきい値に達していないためです。ただし、他の待機中のイベントが表示される場合があります。一般的な例は、次のドキュメントで概説されています。
文書742599.1 高 'カーソル:ピンSがXで待機'および/または 'ライブラリキャッシュロック'頻繁な共有プール/バッファキャッシュのサイズ変更アクティビティによって生成される待機
頻繁なメモリ調整については、いくつかの潜在的な修正が利用可能です。以下を参照してください。
文書7189722.8 バグ7189722-頻繁なSGAサイズ変更操作の拡大/縮小文書9267837.8 バグ9267837-Auto-SGAポリシーで、必要以上に大きなサイズ変更が表示される場合があります
10g以前のバージョンでは問題が発生する可能性があります
10gより前は、行キャッシュレベルのデッドロックを検出する方法が限られていました。デッドロックの可能性を最小限に抑えるために、考えられる解決策は次のとおりです。
- TIMED_STATISTICS = FALSEを設定します
- _row_cache_cursors = 20以上(デフォルトは10)に設定
- トレースを行わないでください
その他の問題のトラブルシューティング
その他のパフォーマンスの問題のトラブルシューティングについては、以下を参照してください。
文書1377446.1 パフォーマンスの問題のトラブルシューティング
バグ12772404-VPDを使用する場合の重大な「行キャッシュオブジェクト」ラッチの競合(ドキュメントID 12772404.8)
参照
バグ:11693365 -GETTING ERROR'WAITED TOOL LONG FOR ROW CACHE ENQUEUELOCK 'バグ:5756769 --ROW CACHE DEADLOCK'ROW CACHE ENQUEUE LOCKには長すぎます! '
注:11693365.8 -バグ11693365-コンカレントドロップテーブルとSelecton Reference制約テーブルがハングする(デッドロック)
注:1377446.1 -*パフォーマンスの問題のトラブルシューティング
注:30802.1 --Init.oraパラメータ 'ROW_CACHE_CURSORS'リファレンスノート
注:395314.1 -SYS.AUDSES $のキャッシュサイズが小さいためにRACがハングする
注:4604972.8 -バグ4604972-同時許可/取り消しによるdc_usersのデッドロック
注:468334.1 -行キャッシュオブジェクトの子ラッチをその行キャッシュに一致させる方法
注:5756769.8 -バグ5756769-CreateMVIEWとDML間のデッドロック
注:6004916.8 -バグ6004916-RACの行キャッシュエンキューに関連するハング(ORA-4021)
注:6027068.8 -バグ6027068-ORA_TQ_BASE $シーケンスでの競合
注:6143420.8 -バグ6143420-dc_usersの「ROWCACHELOCK」と「CURSOR:PIN S WAIT ONX」に関連するデッドロック
注:742599.1 -高 'カーソル:ピンS待機X'、 'ライブラリキャッシュロック'および 'ラッチ:共有プール'共有プール/バッファキャッシュのサイズ変更アクティビティが原因で待機
注:853652.1 -RACとシーケンス
注:8666117.8 -バグ8666117-RACでの高行キャッシュラッチの競合
注:9866045.8 -バグ9866045-LCKで「マスターscnを待機」を長時間待機すると、行キャッシュロックの待機時間が長くなります
バグ:8666117 -「ラッチ:行キャッシュオブジェクト」を待機しているLCK0プロセススタック
awrレポート分析(パスワードエラーによりSQL実行時間が長すぎます)
前提知識:
1)行キャッシュロックイベント
-メモリ共有プールはライブラリキャッシュ、ディクショナリキャッシュに分割され、行キャッシュロックオブジェクトはディクショナリキャッシュに分散されます。これは、ディクショナリバッファへのアクセスによって発生します。
-ラッチクラスに属するこの種のリソース競合は、CPUにかなりの負荷がかかります。並行性の量が多いと、簡単にダウンします。
この待機時間が非常に長い場合は、一般に2つの理由があります。1つは共有プールが小さすぎること、共有プールを増やす必要があること、もう1つはSQL分析の頻度が高すぎること、共有への同時アクセスです。プールが大きすぎます。いずれの場合も、ほとんどの場合、共有プールを増やすと待機時間を減らすことができますが、共有プールを増やす場合にも注意が必要です。すべてのケースで共有プールが増えるわけではなく、大きな影響があります。特に2番目のケースでは、正確な分析が非常に重要です。どのROWCACHEが最も待機しているかを把握するためのさらなる分析は、問題の解決に役立ちます。
行キャッシュロックイベントの調整は、一般的な各キューロックタイプの動作に基づいています。 キューロックタイプ 持ってる:
------- DC_SEQUENCES:この行バッファキューロックは、シーケンスが使用されるときに発生します。調整方法は、シーケンスでバッファリングオプションが指定されているかどうかを確認し、バッファ値が予想される同時挿入操作に耐えられるかどうかを判断することです。
アプリケーション要件に応じて、シーケンスが適切にキャッシュされているかどうかを確認してください。
------- DC_USED_EXTENTSおよびDC_FREE_EXTENTS:この行バッファーのキューのロックは、スペース管理で表スペースの分割が発生した場合、または十分な領域サイズがない場合に発生する可能性があります。調整方法は、表スペースが分割されているかどうか、領域サイズが小さすぎるかどうか、または表スペースが手動で管理されているかどうかを確認することです。
------- DC_TABLESPACES:このラインバッファキューロックは、新しいゾーンを割り当てるときに発生します。ゾーンサイズの設定が小さすぎると、プログラムが新しいゾーンを頻繁に申請するため、競合が発生します。調整方法は、ゾーンの数をすばやく増やすことです。
おそらく最も可能性の高い原因は、新しいエクステントの割り当てです。エクステントサイズが低く設定されている場合、アプリケーションは常に新しいエクステントを要求し、競合を引き起こしている可能性があります。急速に成長している小さなエクステントサイズのオブジェクトがありますか? (エクステントの数が多いオブジェクトを探すことで、これらを見つけることができる場合があります)。トレースで挿入/更新アクティビティを確認し、挿入されたオブジェクトのエクステント数を確認します。
------- DC_OBJECTS:このラインバッファキューロックは、オブジェクトが再コンパイルされるときに発生します。オブジェクトがコンパイルされると、他の動作をブロックするために排他ロックが適用されます。不正なオブジェクトと依存関係をチェックして調整します。
------- DC_SEGMENTS:この行バッファキューロックは、セグメントが割り当てられたときに発生し、キューロックを保持しているセッションが実行していることを監視します。
これは、セグメントの割り当てに起因する可能性があります。エンキューを保持しているセッションが実行していることを識別し、エラースタックを使用して診断します。
------- DC_USERS:デッドロックとその結果の「行キャッシュエンキューロックが長すぎます!」セッションがユーザーにGRANTを発行し、そのユーザーがデータベースにログオンしているときに発生する可能性があります。
------- DB_ROLLBACK_SEGMENTS:これはロールバックセグメントの割り当てによるものです。 dc_segmentsと同様に、エンキューを保持しているものを特定し、エラースタックも生成します。マルチノードシステム(RAC)では、ホルダーが別のノードにある可能性があるため、各ノードからの複数のシステム状態が必要になることに注意してください。
------- DC_AWR_CONTROL:このエンキューは、自動ワークロードリポジトリの制御に関連しています。そのため、リポジトリを操作する操作はこれを保持する可能性があるため、これらをブロックしているプロセスを探してください。
2)関連するビューフィールドの説明:
ROW CACHELOCKの基本的な説明
P1-キャッシュID
P2 –モード開催
P3 –要求されたモード
modeとREQUESTの値:
KQRMNULL 0ヌルモード–ロックされていません
KQRMS3共有モード
KQRMX5専用モード
KQRMFAIL10がインスタンスロックの取得に失敗する
3)SQLクエリ
-----クエリ行キャッシュロック待機
select * from v $ session_wait where wait_class = 'row cache lock'
p1の値を見つける
-----行キャッシュ名をクエリします
p1の値に従ってクエリを実行します
select * from v $ rowcache where cache#=&p1
その他:
v $ session aからevent、p1を選択します。ここで、a.usernameはnullではなく、a.status = 'ACTIVE'です。
4) Dba_hist_active_sess_historyビュー
dba_hist_active_sess_historyビューは、メモリ内のアクティブなセッションの履歴を記録し、動的パフォーマンスビューV $ ACTIVE_SESSION_HISTORYは、現在アクティブなセッション情報を記録します。 dba_hist_active_sess_historyビューを介してv $ sqlareaおよびDBA_HIST_SNAPSHOTにログを記録すると、一定期間SQLを追跡できます。もちろん、追跡できるSQLの量はv $ sqlareaによって異なります。結局のところ、v $ sqlareaに残っているSQLのみを追跡できます。
HOURレポート分析
データベースは8月30日の午後3時から午後4時まで表示されたため、2つのAWRレポートが取得されました。 1つは8月30日の午後3時から4時まで、もう1つは31日の午後3時から4時まででした。 、2つのレポートを比較すると、異なる場所が問題領域であるはずです。
1)トップ5のフォアグラウンドイベントでは、最初のイベントはDBCPUではありません。デフォルトでは、DBCPUが最初にランク付けされます。
2)見続ける 待機イベント統計。最初はDBCPUではなく、接続管理呼び出しの経過時間が見つかりました。名前がデータベース接続に関連していることを確認してください。
3)比較を続けて、ct_users Pct Missが20%より大きいことを確認します。
4)疑わしいSQLステートメントを表示します。
赤いSQLの実行は非常に遅く、いくつかの例外があります。
SQL> select to_char(sample_time、 'YY-MM-DD HH24:MI:SS')sample_time、
2 instance_number、
3 sql_id、
4 P1、
5イベント、
6 wait_class
dba_hist_active_sess_historyから7
8ここでsample_timebetween
9 to_date('16 -08-29 13:00:00 '、' YY-MM-DD HH24:MI:SS ')および
10 to_date('16 -08-29 13:30:00 '、' YY-MM-DD HH24:MI:SS ')
11およびsql_idin( 'bvtu633rnwrwv'、
12 '4a6uhr508t0p6'、
13'fpm2zazkfqhy6 '、
14'bhrcaykh5tzsw '、
15 '9fxv1px768bd5')
16注文1
17
SAMPLE_TIME INSTANCE_NUMBER SQL_ID P1 EVENT WAIT_CLASS
----------------- --------------- ------------- ----- ----- --------------------- ---------------------
16-08-29 13:00:59 1 4a6uhr508t0p610行キャッシュロック同時実行性
16-08-29 13:01:09 1 4a6uhr508t0p610行キャッシュロック同時実行性
16-08-29 13:01:19 1 4a6uhr508t0p610行キャッシュロック同時実行性
16-08-29 13:01:29 1 4a6uhr508t0p67行キャッシュロック同時実行性
16-08-29 13:01:39 1 bvtu633rnwrwv10行キャッシュロック同時実行性
16-08-29 13:01:49 1 bvtu633rnwrwv10行キャッシュロック同時実行性
16-08-29 13:01:59 1 bvtu633rnwrwv10行キャッシュロック同時実行性
16-08-29 13:02:10 1 bvtu633rnwrwv7行キャッシュロック同時実行性
16-08-29 13:02:20 1 fpm2zazkfqhy610行キャッシュロック同時実行性
16-08-29 13:02:30 1 fpm2zazkfqhy610行キャッシュロック同時実行性
16-08-29 13:02:40 1 fpm2zazkfqhy610行キャッシュロック同時実行性
16-08-29 13:02:41 2 bvtu633rnwrwv7行キャッシュロック同時実行性
16-08-29 13:02:50 1 fpm2zazkfqhy67行キャッシュロック同時実行性
16-08-29 13:04:31 1 bhrcaykh5tzsw10行キャッシュロック同時実行性
16-08-29 13:04:41 1 bhrcaykh5tzsw10行キャッシュロック同時実行性
16-08-29 13:04:51 1 bhrcaykh5tzsw7行キャッシュロック同時実行性
16-08-29 13:06:32 1 9fxv1px768bd510行キャッシュロック同時実行性
16-08-29 13:06:42 1 9fxv1px768bd510行キャッシュロック同時実行性
18行が選択されました
上記のSQLによると、SQLによって引き起こされる待機イベントは行キャッシュロックであることがわかります。 P1 = 7または10に従って、待機イベントが発生しているカテゴリを見つけます。
SQL> select cache#、parameter from v $ rowcache where cache#in( '7'、 '10')
CACHE#パラメータ
---------- --------------------------------
10 dc_users
7 dc_users
7 dc_users
7 dc_users
上記のSQLによると、パラメータカテゴリはdc_usersであることがわかります。オンラインによると、dc_usersは、間違ったパスワードでログインしているユーザーに関連しているとのことです。
11gでは、失敗したログオン試行の再試行を許可する間に意図的な遅延があります。一部の特定のアプリケーションタイプでは、遅延の間行キャッシュエントリがロックされるため、これにより問題が発生する可能性があります。これにより、特定のユーザー/スキーマのDC_USERSに対する過剰な行キャッシュロック待機が発生する可能性があります。
..。
3回連続して障害が発生した後、スリープ遅延が3秒から始まり、最大10秒まで延長されます。各遅延の間、ユーザーXの行キャッシュロックは排他モードで保持され、ユーザーXとしての同時ログオン試行を防止します(また、ユーザーXの行キャッシュロックを必要とするその他の操作を防止します)。
行キャッシュのロック中にユーザーのログインに失敗したことを確認します。
SQL>ユーザー名を選択、
2ユーザーホスト、
3 to_char(timestamp、 'YY-MM-DD HH24:MI:SS')タイムスタンプ、
4 action_name
5dba_audit_trailから
6ここで、action_name = 'LOGON'
7およびpriv_usedがnull
8とタイムスタンプの間
9 to_date('16 -08-29 13:00:00 '、' YY-MM-DD HH24:MI:SS ')および
10 to_date('16 -08-29 13:30:00 '、' YY-MM-DD HH24:MI:SS ')
USERNAME USERHOST TIMESTAMP ACTION_NAME
------------------------------ -------------------- ------------------- ----------------------------
MAPP_PLATFORM IDC-APP-02 16-08-2911:03:51ログオン
MAPP_PLATFORM IDC-APP-01 16-08-2911:03:41ログオン
MAPP_PLATFORM IDC-APP-02 16-08-2913:03:31ログオン
MAPP_PLATFORM IDC-APP-01 16-08-2913:03:21ログオン
MAPP_PLATFORM IDC-APP-02 16-08-2913:03:11ログオン
MAPP_PLATFORM IDC-APP-01 16-08-2913:03:01ログオン
MAPP_PLATFORM IDC-APP-02 16-08-2911:02:51ログオン
MAPP_PLATFORM IDC-APP-01 16-08-2913:02:41ログオン
MAPP_PLATFORM IDC-APP-02 16-08-2911:02:31ログオン
。。。。。。
8.14から8.31までのユーザーMAPP_PLATFORMが間違ったパスワードでデータベースにログインしようとしていることがわかりました。間違ったパスワードでログインすると、行キャッシュがロックされ、SQLの実行が遅くなることを確認しました。
ログイン監査情報の詳細:
から*を選択します
((
os_username、userhost、terminal、username、count(*)の失敗を選択します
dba_audit_trailから
ここで、returncode = 1017であり、to_date( '2016-8-29 11:30:00'、 'yyyy-mm-dd hh24:mi:ss')とto_date( '2016-8-29 13:30:00'の間のタイムスタンプ、 'yyyy-mm-dd hh24:mi:ss')
os_username、userhost、username、terminalでグループ化
5descで注文);
Returncode = 1017ここで、1017は、Oracleによって内部的に定義されたエラー戻りコード値です。
実際、ユーザーが提供したパスワードが正しいかどうかに関係なく、Oracleは新しい接続にシャドウプロセスを割り当てます。この場合、サービスプロセスは、ユーザー情報をさらに検証するために少量のリソースを取得する必要があります。これは、正常にログインできない場合でも、短期的にはインスタンスのデッドロックを引き起こす可能性があります。
私について
.................................................。 .................................................。 ...........................。
●著者:小麦の苗木、データベーステクノロジーのみに焦点を当て、テクノロジーの使用にさらに注意を払う
●この記事はitpub( http://blog.itpub.net/26736162 )、ブログガーデン( http://www.cnblogs.com/lhrbest )および個人のWeChat公開番号( xiaomaimiaolhr )同期更新があります
●この記事はitpubのアドレスです。 http://blog.itpub.net/26736162/abstract/1/
●このブログパークのアドレス: http://www.cnblogs.com/lhrbest
●この記事のPDFバージョンと小麦苗クラウドディスクアドレス: http://blog.itpub.net/26736162/viewspace-1624453/
●データベースで書かれたテスト面接の質問と回答: http://blog.itpub.net/26736162/viewspace-2134706/
●QQグループ: 230161599 WeChatグループ:プライベートチャット
●私に連絡してください、追加の理由を示して、QQの友達(646634621)を追加してください
●2017-05-0909:00〜2017-05-3022:00マジックで完了
●記事の内容は、小麦の苗の研究ノートからのものであり、その一部はインターネットから整理されています。侵害や不適切な点がありましたら、ご了承ください。
●著作権、この記事の共有を歓迎します。ソースを保持してください
.................................................。 .................................................。 ...........................。
スマートフォンを手に取る WeChatクライアント 下側をスキャンします 左 WeChatの小麦苗の公開数に注意を払うための写真:Xiaomaimiaolhr、スキャン 正しい QRコードが小麦苗のQQグループに追加されます。最も実用的なデータベース技術を学びましょう。
「ITPUBブログ」から、リンク:http://blog.itpub.net/26736162/viewspace-2139754/、転載する必要がある場合は、出典を示してください。そうでない場合、責任を問われます。