与任何性能问题一样，关键是查看有问题的会话的基于等待的历史数据。您可以使用OEM，某些自己进行等待轮询的第三方工具，或通过DBA运行ASH报告（?/rdbms/admin/ashrpt.sql），SQL监视器报告（dbms_sql_monitor包）或直接查询ASH数据（这是上述大多数实际使用的）来实现这一点。最近的活动在v$active_session_history中（每行1秒），较旧的活动在dba_hist_active_sess_history中（每行10秒）。或者，您可以在问题发生时重复查询v$session，并大致了解发生了什么，尽管这不是很准确。
在上述所有步骤中，一旦您确定了有问题的会话，您就可以查找报告的主要等待event以及sql_id。您的会话很可能被库缓存锁或其他一些并发机制卡住，或者字典统计数据可能不好，该包的内部查询可能会出错。如果是锁或pin或互斥类型的情况，则需要找到阻塞器，或者如果没有报告阻塞器，则在解析中查找会话，而不是在并发等待中查找会话。挂起分析也可能有所帮助。如果您有DBA，请与他/她联系以获得帮助，因为这些工具中的大多数都只有在提升权限后才可用。