SQL*NET MORE data to client

今天发现Etl 程序向数据库插入数据时，产生以下事件:

通过网上查找资料如下:

SQL*NET MORE data to client等待事件：

意味着server process服务进程正在发送更多数据/信息给client, wait time代表SEND发送这个操作实际完成的时间。

driver id
In Oracle8i onwards P1RAW can be decoded into ASCII characters to give a clue as to which Net driver is used.
Eg: P1RAW=0×62657100 = ‘beq\0′ , P1RAW=0×54435000 = ‘TCP\0′ etc.
In earlier releases the value here is the value of the disconnect function of the Net driver being used (which is not much use).

#bytes
The number of bytes expected to be sent by the server process to the client. Note that in some cases the bytes value may be misleading and may not reflect the actual number of bytes sent.

对该等待时间的一般建议是检查和调整网络或数据库连接

与相关的bug:

NB	Bug	Fixed	Description
	14249402	12.1.0.1	Poor RAT replay performance with LOBS – “SQL*Net more data to client” waits
	8477973	11.2.0.2, 12.1.0.1	Multiple open DB links / ORA-2020 / distributed deadlock / ORA-600 possible using DB Links

以下解释没看太明白:

Wait Time:

This wait blocks until the message is sent (or until an abnormal end of file condition occurs on the underlying Net transport layer). There is not usually an Oracle timeout on the wait, although the Oracle Net layer can be configured to time out if required.
Finding Blockers:

The blocker is generally due to any network delay.
Systemwide Waits:

This event normally denotes time outside of the server waiting to send more data to the client so is treated as a “Network” wait when looking at systemwide timings.
Reducing Waits / Wait times:

This is a normal wait but if the times are excessive one should look at the Net transport to the client process and determine if the time is due to:
Is there an excessive amount of data being sent from server to client
time in the network between the server and the client
(SQL*Net trace (with TIMESTAMPS) can be helpful to check out the time in the network between the client and server. See Note:16658.1 for details of Net tracing).

For the ‘SQL*Net more data to client’ event wait, Oracle uses SDU (Session Data Unit) to write to the SDU buffer which is written to the TCP socket buffer. If data is larger than the the initial size of Session Data Unit then multiple chunks of data need to be sent. If there is more data to send then after each batch sent the session will wait on the ‘SQL*Net more data to client’ wait event.

The following note describes SDU:

Document 44694.1 SQL*Net Packet Sizes (SDU & TDU Parameters)
How to Diagnose Waits for the ‘SQL*Net message to client’ and ‘SQL*Net more data to client’ events

The best way to diagnose the wait is by running 10046 trace. A process or a single sql can be traced using 10046 trace:

Document 376442.1 How To Collect 10046 Trace (SQL_TRACE) Diagnostics for Performance Issues
For example, in the following we are running a select from from SQL*Plus:

SELECT * FROM emp;

call     count       cpu    elapsed       disk      query    current        rows
——- —— ——– ———- ———- ———- ———- ———-
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.00       0.02          0          3          0           0
Fetch        2      0.00       0.06          0          0          0          14
——- —— ——– ———- ———- ———- ———- ———-
total        4      0.00       0.10          0          3          0          14

Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
—————————————-   Waited ———- ————
SQL*Net message to client                       2        0.00          0.00
PX Deq: Execute Reply                          13        0.01          0.01
SQL*Net message from client                     2       26.06         26.06
PX Deq: Signal ACK RSG                          8        0.01          0.01
PX Deq: Signal ACK EXT                          8        0.02          0.02
PX Deq: Slave Session Stats                     8        0.00          0.00
*****************************************************************************
Once the trace is obtained, you can TKProf it to see the timings and waits. Individual waits for ‘SQL*Net message to client’ are usually of very short duration (in this case the total wait is < 1 microsecond). The wait is recorded but since it has taken ‘zero’ time, the wait is not necessarily a performance issue or cause for concern.

If you notice unusually high waits for these events, for example as a top wait in statspack or AWR, then start the tuning process by tracing the process or the sql.

Potential Solutions

1. SDU size

Remember that ‘SQL*net message to client’ is normally not a network issue, as the throughput is based on the TCP packet. The first session is sent the contents of the SDU buffer which is written to TCP buffer then the session waits for the ‘SQL*net message to client’ event. The wait is associated with the following factors:

Oracle SDU size
Amount of data returned to the client
One solution is to increase the SDU size. The following document can help with that:

Document 44694.1 SQL*Net Packet Sizes (SDU & TDU Parameters)
2. Arraysize

If the application is using large amount of data, consider increasing the arraysize in the application. If small arraysize is used to fetch the data, then the query will use multiple fetch calls, each of these will wait for the ‘SQL*net message to client’ event. With a small arraysize and a large amount of data, the number of waits can become significant.

If running SQL from sqlplus, the arraysize can be increased using the sqlplus “set” command:

set arraysize 1000
From the raw 10046 tracefile, the fetch buffer size or the arraysize can be seen from the r (rows) of the fetch line:

FETCH #18446744071490060104:c=0,e=17086,p=2,cr=3,cu=0,mis=0,r=1,dep=1,og=4,plh=872636971,tim=28473178755694
Here the r=1 is indicating arraysize of 1. 1 may be too low; so try increasing it if the wait for ‘SQL*net message to client’ events is large.

There is more information on arraysize and how to increase it in different applications in the following document:

Document 1419023.1 Row Prefetching and its impact on logical reads and fetch calls
3. TCP

Tune TCP connections and make sure the TCP is configured correctly. The following note may help:

Document 1037210.1 How to tune TCP parameters for better performance
Tuning TCP is outside the scope of Oracle Support. If you have difficulties please consult with your network team.

文章来自:http://www.askmaclean.com/archives/sqlnet-more-data-to-client.html

SQL*NET MORE data to client相关推荐

Wait Event SQL*Net more data to client
oracle 官方给的说法是 C.3.152 SQL*Net more data to client The server process is sending more data/messages ...
[转载]SQL Server 2005 Data Mining简介
简介企业均在尝试分析其数据时都面临若干问题.通常,并不缺乏数据.事实上,很多企业感觉到他们被数据淹没了:他们没有办法完全利用所有的数据,将其变成信息.为了处理这方面的问题,开发了数据仓库技术, ...
Azure SQL 数据库仓库Data Warehouse (3) DWU
<Windows Azure Platform 系列文章目录> 在笔者的上一篇文章中:Azure SQL 数据库仓库Data Warehouse (2) 架构介绍了SQL DW的工作节点 ...
SQL Server Parallel Data Warehouse (PDW) 介绍
最近大数据概念非常火热,各个厂家都讲大数据视为未来IT的一个重要方向,因此各个厂家都想在这个领域有所作为.前几天参加了IBM大数据研讨会,会上IBM推出了他们针对于大数据的解决方案,三种一体机(Pur ...
关于Installshield中Ie8\Ie9\SQL Server 2008 R2 Native Client等Prq文件在线下载地址
InstallShield中安装包的几篇文章: Installshield2010实现web部署和数据库安装示例 InstallShield 2010集成.net Framework 4的安装包制作 ...
Azure SQL Database (23) Azure SQL Database Dynamic Data Masking动态数据掩码
<Windows Azure Platform 系列文章目录> 我们在使用关系型数据的时候,有时候希望: - 管理员admin,可以查看到所有的数据 - 普通用户,某些敏感字段,比如信用卡 ...
oracle数据库同步工具Dell,|SQL Maestro Oracle Data Sync(数据库同步工具)下载v16.4.0.6免费版 - 欧普软件下载...
Oracle Data Sync是一款好用的Oracle数据库同步软件,软件可以自动创建无错误的同步脚本,可实现数据库中各项数据的快速同步,还有自定义比较键和自动映射工具,提高同步数据的准确性.支持命 ...
android 手机查看sql数据库以及data文件夹为空
之前在测试一个关于sqlite的数据库的demo中,为了查看数据库的结果,于是去data文件夹找,但是没找到为空,查阅资料后发现问题还不是一下子就能解决的,以下是我的解决经历,都是在网上大神的帮助下 ...
解决pycharm sql语句 No data sources are configured to run this SQL and provide advanced的问题
其实这个提示,并不影响你敲代码,也不影响这些sql语句的执行.但是对于强迫症如我的这样子,并不能容忍~于是: 如果你的IDEA没有出现右侧这个菜单,可以通过:File–>setting–> ...

SQL*NET MORE data to client

SQL*NET MORE data to client相关推荐

最新文章

热门文章