eygle曾在"ORA-00600 kcratr_nab_less_than_odr案例一则"中指出：
其实，很多时候在处理问题时，我们可能都无法找到针对性的参考，这时候，猜测就很重要了。
当学习到一定阶段：猜测将成为一种重要的学习能力。
深以为然，我们来看一下近期我碰到的靠猜测定位问题的两个实例中的一个：
我负责的一个库里出现极为明显的pipe put等待：
|
Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
|
pipe put |
592 |
2,880 |
4,865 |
39.2 |
Concurrency |
|
CPU time |
|
2,039 |
|
27.8 |
|
|
library cache pin |
468 |
1,306 |
2,790 |
17.8 |
Concurrency |
|
db file sequential read |
66,578 |
253 |
4 |
3.4 |
User I/O |
|
db file scattered read |
15,310 |
222 |
14 |
3.0 |
User I/O |
这里以pipe put为关键字去查询metalink和google，你会发现找不到什么有价值的参考信息。
接下来我们去SQL ordered by Elapsed Time里去看一下耗时最长的SQL是什么：
|
Elapsed Time (s) |
CPU Time (s) |
Executions |
Elap per Exec (s) |
% Total DB Time |
SQL Module |
SQL Text |
|
3,691 |
578 |
3 |
1230.46 |
50.27 |
PL/SQL Developer |
begin -- Call the procedure p_sal_... |
|
3,077 |
1 |
1,400 |
2.20 |
41.90 |
PL/SQL Developer |
declare ret binary_integer; begin ret := PBSDE.DEBUG_LOOP; end;... |
从结果里我们可以看到耗时最长的是一个存储过程p_sal_...，它占用了50.27%的DB Time，同时仅次于它的是一个叫PBSDE.DEBUG_LOOP的东东，注意到里面有关键字DEBUG和LOOP。
我们知道，oracle里的pipe是用于session或进程间的通信，而当你用PL/SQL Developer debug的时候，如果你用鼠标点在某个变量上，PL/SQL Developer里会显示这个变量的值，这里为什么能显示这个变量的值就是利用到了oracle里的pipe机制，把这个变量的值从运行session里通过pipe传到了PL/SQL Developer里并显示了出来。
所以综合上述因素，我们猜测：
我的某位同事在PL/SQL Developer端对p_sal_...做调试（debug），然后当其debug到一个循环中时，他/她用鼠标点了一下循环中的某个变量想查看一下这个变量的值，结果这时候死掉了，于是他/她就强制退出了。但这个session还没有死，oracle还在这个session里不停的想把这个变量的值通过pipe显示（put）出来，但是因为他/她已经把pipe put的客户端（即PL/SQL Developer的调试窗口）强制退出了，这个时候oracle找不到pipe put的目的地了，所以oracle就只能等待咯。
当我找到调试上述存储过程的大姐，然后我把我的上述猜测跟她说了一遍，她说是的，实际情况正如我猜测的那样。
最后她问我：你怎么知道的这么清楚？
我回答说：我猜的。
写得真是通俗易读，清清楚楚！
谢谢 分享
深有同感！dba哪能事事了如指掌。有时猜猜感觉挺好！