Findings – Step 1 (Cursor Cache: Recent Executions)



  1. Plan stability
    • Both p011aor and p012aor used the same plan hash (517933086).
    • Confirms this is not a plan regression issue.

  2. Execution volume
    • p011aor: ~6.2K executions.
    • p012aor: ~13.9K executions (2× higher).
    • Suggests heavier workload routed here (possibly service routing) or repeated runs.

  3. Elapsed time profile
    • p011aor: elapsed ~6,210s, dominated by CPU time (65%), very low IO waits.
    • p012aor: elapsed ~13,860s, dominated by IO waits (94%), very little CPU work.
    • Clear shift: p012aor performance is IO-bound, not CPU-bound.

  4. Rows processed
    • p011aor: ~18.7M rows.
    • p012aor: ~32.6M rows (~75% more).
    • Indicates either different bind values or different data distribution leading to more row access.

  5. Logical & physical IO
    • Buffer gets: 293M vs 421M (+43%).
    • Disk reads: 5.6M vs 11.9M (2× higher).
    • Reinforces that p012aor is performing heavier IO work.






✅ Step 1 Conclusion



  • Not a plan issue (same hash).
  • p012aor slowness is tied to IO: more rows processed, more disk reads, longer elapsed dominated by IO waits.
  • Likely next culprits:
    • Bind values (Step 2).
    • Object/data skew (Step 9).
    • Storage/TEMP IO latency (Steps 10–11).


Popular posts from this blog