Pro*C 过程调用无限期挂起
我有一个多线程 Pro*C 程序,它在单独的连接和运行时上下文上的每个线程中调用匿名存储过程。
我的匿名过程调用需要不同的时间范围才能从过程返回,有时甚至会无限期挂起。正如 AWR 日志中所示,我的 Oracle 过程只需要 0.05 秒即可返回,但令人惊讶的是 Pro*C 调用需要 5 秒才能从过程返回。
Pro*C 过程调用和实际 Oracle 过程执行之间涉及哪些处理活动?是否有任何锁或其他阻塞问题?
I have a multithreaded Pro*C program which calls anonymous stored procedures in each thread on separate connections and runtime contexts.
My anonymous procedure calls takes different time frames to return from the procedure and sometimes it even hangs indefinitely. My Oracle procedure takes just 0.05 seconds to return as it is shown in AWR logs but surprisingly the Pro*C call takes 5 seconds to return from procedure.
What is the processing activity involved between the Pro*C procedure call and actual Oracle procedure execution? Are any locks or other blocking issues?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果它无限期地挂起,那么是的,涉及某种类型的阻塞(或轮询等......函数中发生了某些事情导致它无法返回)。
从您就此事发布的其他问题来看,如果您只想终止已挂起的特定线程,那么您可以查看的是将您的线程 ID 设置为其中包含“完成”标志的结构。
现在,当您设置超时警报时,只需滚动
thread_id
数组,即可查看哪些已完成。对于完成的,您可以调用pthread_join
,否则您可以使用pthread_kill
或pthread_cancel
向线程发送信号来停止线程。If it's hanging indefinitely, then yes, there is some type of blocking involved (or polling, etc. ... something is happening in the function causing it not to return).
From your other question you posted on this matter, if you want to just kill a specific thread that has hanged, then on thing you can look at is to setup your thread ID's as a struct that has a "finished" flag in it.
Now when you set your timeout alarm, simply scroll through the array of
thread_id
, and see which ones are finished. The ones that are finsihed, you can callpthread_join
on, otherwise you can send a signal to the thread usingpthread_kill
orpthread_cancel
to stop the thread.您可以尝试 Oracle 跟踪 (DBMS_MONITOR) 并查看跟踪文件中的最后一个活动。我能想到的唯一可以正确解释时间的事情是,如果过程返回一个大值(BLOB、CLOB、XML),则需要时间通过网络返回到客户端(或者客户端在网络上阻塞)接收数据的大小)。
You could try an Oracle trace (DBMS_MONITOR) and see what the last activity is in the trace file. The only thing I can think of that might properly account for the time is if the procedure returns a large value (BLOB, CLOB, XML) which is taking time to return back to the client over the network (or where the client chokes on the size of received data).