奇葩的SQL*Net more data from client等待,导致批处理巨慢

<pre name="code" class="sql"><pre name="code" class="sql">UPDATE Business_Duebill
   SET RelativeSerialNo1 = :1,
       RelativeSerialNo2 = :2,
       CustomerID        = :3,
       BusinessType      = :4,
       MFCustomerID      = :5,
       CustomerName      = :6,
       SubjectNo          = :7,
       BusinessSum        = :8,
       BusinessCurrency   = :9,
       ActualBusinessRate = :10,
       Balance            = :11,
       NormalBalance      = :12,
       OverdueBalance     = :13,
       DullBalance      = :14,
       BadBalance       = :15,
       InterestBalance1 = :16,
       InterestBalance2 = :17,
       FineBalance1     = :18,
       FineBalance2     = :19,
       ActualMaturity   = :20,
       FinishDate        = :21,
       TABalance         = :22,
       TAInterestBalance = :23,
       TATimes           = :24,
       LcaTimes          = :25,
       ExtendTimes       = :26,
       AdvanceFlag       = :27,
       PayBackAccount    = :28,
       PayInterestAccount = :29,
       BailAccount        = :30,
       PutOutAccount      = :31,
       OperateOrgID       = :32,
       MfOrgID            = :33,
       UpdateDate         = :34,
       Classify4          = :35,
       ReturnType         = :36,
       BailPercent        = :37,
       PaymentType        = :38,
       TermsFreq          = :39,
       BusinessStatus     = :40,
       OperateUserID      = :41,
       OverdueDate        = :42,
       BillType           = :43,
       RateFloat          = :44,
       RateFloatType  = :45,
       AdjustRateType = :46,
       THIRDPARTYZIP2 = :47,
       FinishType     = :48
 WHERE SerialNo = :49

出现了大量的SQL*Net more data from client

                                                                                    p1         p2
1	24-5?? -14 01.14.34.059 	1571	SQL*Net more data from client	1952673792	5	0	0	-1	0	0
2	24-5?? -14 01.14.33.058 	1571	SQL*Net more data from client	1952673792	4	0	0	-1	0	0
3	24-5?? -14 01.14.32.058 	361	enq: WF - contention	1464205318	70	0	0	-1	0	0
4	24-5?? -14 01.14.32.058 	1571	SQL*Net more data from client	1952673792	1	0	0	-1	0	0
5	24-5?? -14 01.14.31.057 	1571	SQL*Net more data from client	1952673792	1	0	0	-1	0	0
6	24-5?? -14 01.14.30.056 	1571	SQL*Net more data from client	1952673792	4	0	0	-1	0	0
7	24-5?? -14 01.14.29.056 	1571	SQL*Net more data from client	1952673792	3	0	0	-1	0	0
8	24-5?? -14 01.14.28.055 	361	db file sequential read	2	164307	1	0	-1	0	0
9	24-5?? -14 01.14.28.055 	1571	SQL*Net more data from client	1952673792	11	0	0	-1	0	0
10	24-5?? -14 01.14.27.055 	1571	SQL*Net more data from client	1952673792	2	0	0	-1	0	0
11	24-5?? -14 01.14.26.054 	1571	SQL*Net more data from client	1952673792	3	0	0	-1	0	0
12	24-5?? -14 01.14.25.049 	1571	SQL*Net more data from client	1952673792	1	0	0	-1	0	0
13	24-5?? -14 01.14.24.049 	1571	SQL*Net more data from client	1952673792	5	0	0	-1	0	0
14	24-5?? -14 01.14.23.048 	1571	SQL*Net more data from client	1952673792	2	0	0	-1	0	0

当会话等待一个来自客户端的消息的到达时提交的SQL*Net more data from client(来自客户端的SQL*NET的消息)等待事件。一般而言,这意味着会话处于空闲状态。

在不与使用键盘的终端用户进行交互的批处理程序中,若在此事件上的等待事件过多,则表示在应用程序代码中或网络层存在低效率因素。

但是,该事件上的过高的等待事件并不降低数据库的性能,因此该事件清楚地指出可觉察到的数据库性能问题并不是真正的数据库问题。

P1 :Driver id: 服务器端和客户端连接使用的协议信息。

P2: #bytes: 服务器端接收到的来自客户端消息的字节数(通常是1,即使接收到的数据包中包含多余1字节的内容).

SQL*Net more data from client
A while ago, OEM report some alert messages to us:

Wait class "Network" was consuming significant database time.
Wait event "SQL*Net more data from client" in wait class "Network"
     was consuming significant database time.
We also see a 30ms slower to render our web pages.

According to Oracle doc,

SQL*Net more data from client
The server is performing another send to the client. The previous operation was also a send to the client.

It is not of much help.

The OEM gives a more clear indication:

Investigate the cause for high “SQL*Net more data from client” waits in Module “JDBC Thin Client”.

It is telling us that something is wrong with the JDBC drivers.

Chris May find a good article here

The cause of this event was a sequence of parse calls that passed excessively long SQL text strings through SQL*Net from the client to the server (instead of 

using stored procedure calls to accomplish the same thing). The long SQL text strings wouldn’t fit into a single SQL*Net packet, so the Oracle kernel spent 

a considerable amount of time awaiting second and subsequent SQL*Net packets during parse calls.

Hibernate, the ORM tools used by our application, generates long SQLs. Instead of select * from table, it use select col_1, col_2 from table.

After upgrading to latest JDBC driver, the problem fixed.

可以看到光wait就有将近13分钟,占CPU TIME的84%,而且平均等待事件达到177毫秒