如何诊断cursorpinswaitonx系列二
如何分析诊断收集信息 1. 查看AWR 报告中high paring 和high version部分内容 具体查看这几个部分的内容:"SQLordered by Parse Calls' or 'SQL ordered by Version Count' SQL ordered by Parse Calls 关于这部分中的sql 解析执行是否过高,或者能否减小来
如何分析诊断收集信息
1. 查看AWR 报告中high paring 和high version部分内容
具体查看这几个部分的内容:"SQLordered by Parse Calls' or 'SQL ordered by Version Count'
SQL ordered by Parse Calls 关于这部分中的sql 解析执行是否过高,或者能否减小来。
SQL ordered by Version Count关于这部分中的high version sql ,需要找出为啥他们不能共享,可以通过 v$sql_shared_cursor 视图查找原因
2. systemstats 和errorstack 的关注点
对于systemstats 和errorstack 时效性非常重要。需要在问题发生时刻进行dump ,否则过时采集的信息是无效的。在一个高速运行的系统中,那些holders and waiter 进程转瞬即逝。
根据AWR 的 load profile 部分内容可以初步判断出 系统 sql 解析情况:
如果看到hard parses 很多,表明系统可能没有使用绑定变量,或者有新的sql 上线。
对于high version counts 也会导致 cursor:ping S wait on X
使用V$SQL_SHARED_CURSOR可以查找出 sql 不能共享的原因
有些bug可能会导致 high version counts:
Document 1057392.8 Bug 10157392 - High version counts forSQL with binds (BIND_MISMATCH)
Document 9689310.8 Bug 9689310 - Excessive child cursors /high VERSION_COUNT / OERI:17059 due to bind mismatch
Bug 可能会导致 cursor pin s wait on x :
NB |
Bug |
Fixed |
Description |
5650841 |
Hang / deadlock from ANALYZE of cluster index |
||
16191248 |
12.1.0.1.1, 12.1.0.2, 12.2.0.0 |
Hang from concurrent drop of on-commit materialized views or using DBMS_REDEFINITION |
|
14295250 |
11.2.0.4, 12.1.0.1 |
Long parse time for large query with many nested views due to much time in epxression analysis code |
|
14191508 |
11.2.0.3.8, 11.2.0.3.BP16, 11.2.0.4, 12.1.0.1 |
Slow row cache load due to SEG$ and INDSUBPART$ queries |
|
14176247 |
11.2.0.4, 12.1.0.1 |
Many child cursors using Adaptive Cursor Sharing with binds (due to BIND_EQUIV_FAILURE) |
|
18292893 |
12.1.0.2, 12.2.0.0 |
Jobs don't execute per schedule with a large number of PDBs |
|
18018515 |
12.2.0.0 |
High CPU in qctHasFakeBind (can cause 'cursor: pin S wait on X' waits) |
|
16448569 |
11.2.0.4, 12.1.0.2, 12.2.0.0 |
PQ hang/deadlock possible - "cursor: pin S wait on X" waits |
|
16400122 |
12.2.0.0 |
Spikes in library cache mutex contention for SQL using SQL Plan Baseline |
|
15850031 |
11.2.0.4, 12.2.0.0 |
Rare instance hang: deadlock between 'row cache lock' and 'cursor: pin S wait for X' |
|
14469756 |
12.2.0.0 |
Partition pruning causes delay in TBL$OR$IDX$PART$NUM |
|
14302813 |
11.2.0.4, 12.2.0.0 |
QC blocked / parse hang for parallel DML executed from remote stored procedure |
|
14029891 |
11.2.0.4, 12.1.0.1 |
mutex deadlock having SQL baselines on recursive dictionary cursor |
|
11927619 |
11.2.0.1.BP11, 11.2.0.2.BP07, 11.2.0.3, 12.1.0.1 |
DBMS_STATS slow on interval composite partitions |
|
11855965 |
11.2.0.3, 12.1.0.1 |
Truncate partition takes long time doing recursive delete on MLOG$ |
|
10213073 |
11.2.0.2.8, 11.2.0.2.BP18, 11.2.0.3, 12.1.0.1 |
CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects |
|
10171273 |
11.2.0.2.8, 11.2.0.2.BP08, 11.2.0.3, 12.1.0.1 |
Long parse time with non-equi subpartitioning under interval partitioning |
|
9944129 |
11.2.0.1.BP12, 11.2.0.2, 12.1.0.1 |
SQL not shared due to INST_DRTLD_MISMATCH with global transaction |
|
9935787 |
11.2.0.3, 12.1.0.1 |
Long parse time for large inlists - can cause 'cursor: pin S wait on X' waits |
|
9694101 |
10.2.0.5.7, 11.2.0.2, 12.1.0.1 |
Hang / deadlock between "cursor: pin S wait on X" and "library cache lock" involving dictionary objects |
|
9499302 |
10.2.0.5.5, 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2, 12.1.0.1 |
Improve concurrent mutex request handling |
|
9472669 |
11.2.0.1.BP12, 11.2.0.2, 12.1.0.1 |
'cursor: pin S wait on X' waits for invalid SQL over DB link |
|
8508078 |
11.2.0.2, 12.1.0.1 |
Contention from many concurrent bad SQLs - superseded |
|
12432089 |
11.2.0.3 |
library cache lock/cursor: pin S wait on X with parallel partition stats gathering |
|
8441239 |
11.2.0.1 |
Library cache lock waits if long running TRUNCATE in progress |
|
8348464 |
11.1.0.7.2, 11.2.0.1 |
CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects |
|
7234778 |
11.2.0.1 |
Unnecessary "cursor: pin S wait on X" waits |
|
5485914 |
10.2.0.4 |
Mutex self deadlock on explain / trace of remote mapped SQL |
|
6143420 |
10.2.0.5, 11.1.0.6 |
Deadlock involving "ROW CACHE LOCK" on dc_users AND "CURSOR: PIN S WAIT ON X" |
|
6011045 |
10.2.0.5.5 |
DBMS_STATS causes deadlock between 'cursor: pin S wait on X' and 'library cache lock' |
|
7462072 |
10.2.0.4.3, 10.2.0.5 |
Unnecessary "cursor: pin S wait on X" waits |
|
5983020 |
10.2.0.4 |
MMON deadlock with user session executing ALTER USER |
|
7226463 |
10.2.0.5 |
EXECUTE IMMEDIATE no releasing mutex or library cache pin |
|
+ |
5907779 |
10.2.0.4 |
Self deadlock hang on "cursor: pin S wait on X" (typically from DBMS_STATS) |

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









PHP 500 エラーの包括的なガイド: 原因、診断、および修正 PHP 開発中に、HTTP ステータス コード 500 のエラーが頻繁に発生します。このエラーは通常「500InternalServerError」と呼ばれ、サーバー側でのリクエストの処理中に不明なエラーが発生したことを意味します。この記事では、PHP500 エラーの一般的な原因、診断方法、修正方法を検討し、参照用の具体的なコード例を示します。 1.500 エラーの一般的な原因 1.

Xiaomi Mi 15シリーズは10月に正式リリースされる予定で、その全シリーズのコードネームが海外メディアのMiCodeコードベースで公開されている。その中でもフラッグシップモデルであるXiaomi Mi 15 Ultraのコードネームは「Xuanyuan」(「玄源」の意味)です。この名前は中国神話に登場する高貴さを象徴する黄帝に由来しています。 Xiaomi 15のコードネームは「Dada」、Xiaomi 15Proのコード名は「Haotian」(「好天」の意味)です。 Xiaomi Mi 15S Proの内部コード名は「dijun」で、「山と海の古典」の創造神である淳皇帝を暗示しています。 Xiaomi 15Ultra シリーズのカバー

昨年Huawei Mate60シリーズが発売されて以来、個人的にはMate60Proをメインで使っています。ほぼ1年の間に、Huawei Mate60Proは複数のOTAアップグレードを受け、全体的なエクスペリエンスが大幅に向上し、人々に常に新しい感覚を与えました。たとえば、最近、Huawei Mate60 シリーズは再びイメージング機能の大幅なアップグレードを受けました。 1 つ目は、新しい AI 除去機能で、通行人やゴミをインテリジェントに除去し、空白領域を自動的に埋めることができます。2 つ目は、メインカメラの色の精度と望遠の鮮明さが大幅に向上しました。新学期シーズンであることを考慮して、Huawei Mate60シリーズは秋のプロモーションも開始しました。携帯電話の購入時に最大800元の割引が受けられ、開始価格は4,999元という低価格です。よく使われる、価値の高い新製品が多い

本日、iPhone15とiPhone15Proが正式に発売されましたが、Proシリーズはハイエンドモデルとして価格が高いだけでなく、独自の機能も多く搭載されており、購入後に問題が発生しないように、消費者は購入前に違いを認識する必要があります。 iPhone15. Proシリーズのみの機能です。これらのモニターには同じ表示パネルが装備されていますが、ProMotion 自動適応更新頻度テクノロジーと常時表示機能は、依然として Pro シリーズ専用です。残りのiPhone 15およびiPhone 15 Proシリーズは、解像度、コントラスト、ピーク輝度などの点で同じです。アクションボタン アクションボタンは現在、iPhone 15 Pro シリーズ専用のデザインとなっており、ユーザーがカスタマイズできます。

多くの友人がコンピュータを起動すると、ブルー スクリーン コード 0X000000ED が表示され、システムに入ることができず、操作することもできません。何が起こっていますか?ハードディスクに障害があり、起動時に通常のロードが妨げられている可能性があります。PE ブート ディスクを使用し、セーフ モードに入ることで、この問題を解決できます。以下の具体的なチュートリアルを見てみましょう。 0x00000ed ブルー スクリーンの対処方法 ブルー スクリーン コード: 0x000000ED ブルー スクリーン 原因: ハード ドライブの障害 ハード ドライブに互換性がない、または不良セクタがあるため、起動時に正常にロードできない可能性があります。説明 ブート ボリュームにロードしようとしたときに、I/0 サブシステムが失敗しました。方法 1: 1. まず、セーフ モードに入ることができるかどうかを確認します。できる場合は、「ファイル名を指定して実行/CMD を入力」を開き、コマンド chkdsk/f/r を入力して Enter キーを押し、ダウンロードします。

ハルビン医科大学の臨床薬学の就職の見通しはどのようなものですか? 全国の雇用情勢は楽観的ではありませんが、薬学部卒業生の就職の見通しは依然として良好です。全体として、薬学部卒業生の供給は需要を下回っており、製薬会社や製薬工場がその卒業生を吸収する主なチャネルとなっており、製薬業界における人材需要も着実に伸びています。報道によると、近年、医薬品製剤や生薬化学などの専攻の大学院生の需給比は1:10に達するケースもあるという。臨床薬学専攻の就職方向:臨床医学専攻の学生は卒業後、医療保健ユニット、医学研究部門等で治療、予防、医学研究等に従事することができます。雇用職種:医薬情報担当者、医薬品営業担当者、営業担当者、営業マネージャー、地域営業マネージャー、投資マネージャー、プロダクトマネージャー、プロダクトスペシャリスト、看護師

Go 言語の Web サイトのアクセス速度の問題を迅速に診断して解決する一般的な手段 概要: インターネットの普及に伴い、Web サイトのアクセス速度はユーザー エクスペリエンスにとって非常に重要です。この記事では、Go 言語の Web サイトのアクセス速度の問題を迅速に診断して解決するための一般的な方法を紹介し、関連するコード例を示します。はじめに: Go 言語は、Web サイトやサービスの構築に一般的に使用される高性能プログラミング言語です。ただし、Go 言語を使用して構築された Web サイトでは、アクセス速度の点でいくつかの問題が発生する可能性があります。この記事では、開発者が迅速に診断して解決できるようにするための一般的な方法をいくつか紹介します。

Windows のメモリ診断はメモリが正常かどうかを確認するのに役立ちますが、多くのユーザーはコントロール パネルのシステム ツールを開くだけで win11 のメモリ診断の使い方を知りません。 win11でのメモリ診断の使い方 1. まず、デスクトップ下部の「スタートメニュー」または「検索」ボタンをクリックします。 2. 上の検索ボックスで、「検索」をクリックし、「コントロール パネル」機能を開きます。 3. コントロール パネルの [システムとセキュリティ] オプションをクリックして開きます。 4. このページの下部にある「Windows ツール」オプションを開きます。 5. オプションをダブルクリックして、「Windows メモリ診断」ツールを実行します。 6. 最後に、「今すぐ再起動して問題を確認する」をクリックします。 (ファイルがある場合、システムは自動的に再起動します)
