我有一个每天运行几百次的Oracle过程。也许每隔几天，会话就会挂起一个集群的等待类。我已经看到它挂起了几个小时，我总是必须终止它。
我已经看到信息群集等待导致性能问题，但没有关于它们导致无限期挂起的任何信息。我正在尝试找出我可以运行的任何查询，以找出下次弹出时导致等待的原因，或者可能导致此问题的可能罪魁祸首的任何指针。
调查等待的最佳方法是查看"活动会话历史记录"视图，例如"GV$ACTIVE_SESSION_HISTORY"和"DBA_HIST_ACTIVE_SESS_HISTORY"。无论您使用什么工具来查看数据库性能，都可能已经是这些视图中数据的摘要，因此对于高级故障排除，您需要自己深入研究它们。
GV$视图包含内存中的数据，通常只有几个小时，而DBA_HIST视图通常包含数天的数据。如果可能，请使用GV$视图，因为如果有大量历史数据，DBA_HIST视图可能会很慢。
我无法确切地告诉您要查找哪些列 - 您只是在寻找"奇怪"的东西。但根据我的经验，以下列是解决特定等待问题的最佳选择：
- INST_ID和SESSION_ID- 确定哪个会话。
- SQL_ID- 即使您正在运行一个过程，问题很可能来自其中的一个 SQL 语句。如果语句有问题，您需要查看执行计划，这是一种完全不同的故障排除类型。
- 事件- 这将告诉您它是哪种类型的群集等待。 P1TEXT/P1、P2TEXT/
- P2、P3TEXT/P3- 这些值根据等待事件而变化。例如，如果 P1TEXT 是"file#"，则 P1 将是对应于DBA_DATA_FILES的数字。FILE_ID。如果您有"热块"，即磁盘或 SAN 的某些部分过度使用且性能不佳，它可能会显示在此处。
- CURRENT_OBJ#- 加入DBA_OBJECTS。OBJECT_ID找出正在等待的对象。
(并确保使用的是 IDE 而不是命令行。在 SQL*Plus 中查看如此多的数据几乎是不可能的。