如果运行的代码中包含某种可能的错误,且在调用中触发了的话,服务器端本地的服务进程有义务对远程客户端告知该信息,这个告知的过程中服务进程就处于SQL*Net break/reset to client等待中,直到客户端收到问题信息为止。
大的查询,表的不合理连接也会照成。
SQL> select * from v$mystat where rownum=1;
SID STATISTIC# VALUE
---------- ---------- ----------
135 0 1
SQL> insert into test05 values(1);
1 row inserted
SQL> commit;
Commit complete
SQL> alter session set events '10046 trace name context forever,level 8';
Session altered
查看trace文件
FETCH #1:c=0,e=204594,p=72,cr=129,cu=0,mis=0,r=1,dep=1,og=4,tim=6307709774
EXEC #2:c=0,e=263868,p=72,cr=130,cu=11,mis=0,r=0,dep=0,og=1,tim=6307739186
ERROR #2:err=1 tim=0
WAIT #2: nam='SQL*Net break/reset to client' ela= 3 driver id=1111838976 break?=1 p3=0 obj#=-1 tim=6307747970
WAIT #2: nam='SQL*Net break/reset to client' ela= 100 driver id=1111838976 break?=0 p3=0 obj#=-1 tim=6307748498
由于等待很短,需要查看v$session_wait_history视图来追踪,需要在别的session查看,不然可能查不到。
select event from v$session_wait_history where sid=135
SQL*Net message to client
SQL*Net break/reset to client
SQL*Net break/reset to client
SQL*Net message from client
SQL*Net message to client
SQL*Net message from client
SQL*Net message to client
SQL*Net message from client
SQL*Net message to client
SQL*Net message from client
如果方便大家可以先记录下数据库的v$system_event中的SQL*Net break/reset to client等待次数,然后在单个用户下执行错误的操作,例如查询一个不存在的表,可以发现total_waits数量增加了,或者重新数据库让此类等待事件重新记载,然后执行一个错误的操作,可以观察到v$system_event视图的total_waits的变化。
[@more@]来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25362835/viewspace-1058155/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/25362835/viewspace-1058155/