Findings – Step 1 (Cursor Cache: Recent Executions)
- Plan stability
- Both p011aor and p012aor used the same plan hash (517933086).
- Confirms this is not a plan regression issue.
- Execution volume
- p011aor: ~6.2K executions.
- p012aor: ~13.9K executions (2× higher).
- Suggests heavier workload routed here (possibly service routing) or repeated runs.
- 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.
- 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.
- 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).