Java Oracle挂起进程故障排除

我试图理解一个挂起的Java进程存在的问题。这个过程已经在生产中运行了大约4个月，本周早些时候它开始挂起。当我查看进程的线程转储时，所有相关线程3都有如下堆栈：

    "TxnParser_1" prio=6 tid=0x69bd3400 nid=0x2534 runnable [0x6aa2f000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at oracle.net.ns.Packet.receive(Unknown Source)
        at oracle.net.ns.DataPacket.receive(Unknown Source)
        at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.net.ns.NetInputStream.read(Unknown Source)
        at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1099)
        at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1070)
        at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:478)
        at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:207)
        at oracle.jdbc.driver.T4CStatement.executeForDescribe(T4CStatement.java:790)
        at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039)
        at oracle.jdbc.driver.T4CStatement.executeMaybeDescribe(T4CStatement.java:830)
        at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1132)
        at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1687)
        at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1653)
        - locked <0x40e22f88> (a oracle.jdbc.driver.T4CStatement)
        - locked <0x28f8d398> (a oracle.jdbc.driver.T4CConnection)
        at com.gcg.data.LogParsingInfo.initFromDB(LogParsingInfo.java:262)
        at com.gcg.om.OmQueueEntry.initParseInfoFromDB(OmQueueEntry.java:104)
        at com.gcg.om.GenericQueueEntry.run(GenericQueueEntry.java:237)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)

我的问题是：

我的分析是否正确，流程只是在等待Oracle的响应时被阻塞？ 我应该在Oracle中寻找什么来理解为什么这个过程会阻塞？ 更新：

基于关于寻找DBA_服务员和DBA_锁的评论

select * from dba_waiters;

no rows selected

select * from dba_locks where BLOCKING_OTHERS <> 'Not Blocking';

no rows selected 

dba_锁中有98行，但由于所有行都“不阻塞”，我不认为这是一个锁定问题？正在讨论的进程已处于此状态超过3小时，因此到目前为止，任何死锁都会被检测到

我支持Oracle实例不健康的理论，但我不知道该看什么。我在中请求重新启动Oracle服务器，但尚未完成

---

后续问题：v$session包含v$sql中不存在的sql\u id是否正常？如果是，在什么条件下？

问题已解决，答案在v$session表中是正确的。显然，Oracle会话会因为锁定以外的原因而阻塞。请注意FINAL_BLOCKING_SESSION列-它标识了阻塞的根本原因是会话。 我们调查了会话845，发现由机器和端口标识的客户端进程不再存在。DBA终止会话845，并全部恢复正常

SID     SERIAL# STATUS    PROGRAM          TYPE SQL_ID        PREV_SQL_ID    BLOCKING_SESSION_STATUS BLOCKING_INSTANCE BLOCKING_SESSION FINAL_BLOCKING_SESSION_STATUS FINAL_BLOCKING_INSTANCE FINAL_BLOCKING_SESSION EVENT
------- ------- --------- ---------------- ---- ------------- -------------- ----------------------- ----------------- ---------------- ----------------------------- ----------------------- ---------------------- ----------------------------
 108    22447   ACTIVE    Gcg log parser 1 USER               fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X
 639    40147   ACTIVE    Gcg log parser 3 USER               fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X
 742    34683   ACTIVE    Gcg log parser 2 USER a16hxxtp5sxyw fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X

---

我最近也遇到了这个问题，并使用以下查询查找Oracle中的锁定/锁定会话：

选择 inst|u id | | | | | | sid | | | | | | | | | | | | | | | |， 用户名， 第三排、第三排、第三排、第三排， 阻塞| | | | | | | |阻塞|实例| | | | | |阻塞|会话blk|U信息， 最终阻塞会话状态“，”最终阻塞实例“，”最终阻塞会话信息， 事件 等待秒数 从…起 gv$会议 哪里 lockwait不是空的 订购人 研究所； 资料来源：

---

没错-我的流程比你的流程大；该过程可能正在进行任何更新，还是只是查询？如果它正在更新，是否有其他东西锁定了它试图执行的任何操作？首先，我要看看DBA_WAITERS或DBA_LOCKS是否有什么有趣的地方；第一个（例如来自另一个会话中未提交的更改）可能会挂起很长时间，但可能会配置为最终超时；第二个应该由Oracle检测并导致错误。但无论如何，这两个问题都不是问题所在。3个小时似乎是JDBC连接或侦听器不抱怨的很长时间。Alex完全同意你的观点。4个多小时过去了，一切都没变。我真的希望有一些具体的东西向DBA小组展示。你能澄清一下你是如何筛选和确定这三个条目是阻塞的根本原因的吗？是什么泄露了他们？我也有同样的问题。谢谢。显示的3个条目不是根本原因-它们是我的应用程序中被阻止的Oracle会话。如果向右滚动并查看BLOCKING_SESSION和FINAL_BLOCKING_SESSION列，您将看到其中有SID值。当我们调查SID 845 FINAL_BLOCKING_会话时，该会话针对的是一个不再存在的客户端-由于某种原因，Oracle无法检测到客户端进程已消失。@sceaj-我们当前遇到了相同的问题。您正确地识别了问题会话，但它不是根本原因。我们也处于这一阶段，解决办法是终止会话，但我们需要了解Oracle和客户端会话为何不同步。我们坚信是网络上的一些小插曲触发了这一事件。网络团队正在调查潜在的沟通问题。我们开发人员决定引入读取超时，这使连接更具弹性。

SID     SERIAL# STATUS    PROGRAM          TYPE SQL_ID        PREV_SQL_ID    BLOCKING_SESSION_STATUS BLOCKING_INSTANCE BLOCKING_SESSION FINAL_BLOCKING_SESSION_STATUS FINAL_BLOCKING_INSTANCE FINAL_BLOCKING_SESSION EVENT
------- ------- --------- ---------------- ---- ------------- -------------- ----------------------- ----------------- ---------------- ----------------------------- ----------------------- ---------------------- ----------------------------
 108    22447   ACTIVE    Gcg log parser 1 USER               fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X
 639    40147   ACTIVE    Gcg log parser 3 USER               fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X
 742    34683   ACTIVE    Gcg log parser 2 USER a16hxxtp5sxyw fqr8pndc6p36h  VALID                   1                 1581             VALID                         1                       845                    library cache: mutex X