- SQL*Net message from client
サーバー・プロセス(フォアグラウンド・プロセス)は、クライアント ・プロセスからのメッセージが到着するまで待機します。
待機時間: クライアントに最新のメッセージを送信してから、クライアントからメッセージが到着するまでに必要な時間
- SQL*Net more data from client
サーバーは、すでに開始されている操作で、そのクライアントのシャドウ・プロセスに追加データを送信するためにクライアントで待機中です。
待機時間: データの受信に必要な時間(待機中の時間を含む)によって異なります。
- SQL*Net message to client
サーバー(フォアグラウンド・プロセス)はクライアントにメッセージを送信しています。
待機時間: 送信に必要な実時間
- SQL*Net more data to client
サーバー・プロセスは、クライアントへの追加データまたはメッセージを送信しています。クライアントに対する前回の動作も送信でした。
待機時間: 送信が完了するまでに必要な実時間
- SQL*Net roundtrips to/from client
クライアントとの間で送受信した、Oracle Net Servicesのメッセージの合計数
- bytes received via SQL*Net from client
Oracle Net Servicesを介してクライアントから受信したバイトの合計数
- bytes sent via SQL*Net to client
フォアグラウンド・プロセスからクライアントへ送信したバイトの合計数
参考
"SQL*Net message to client" does NOT measure network latency! It merely measures how long it took to putthe response message into TCP send buffer on the server!
Once the response packet is put into TCP send buffer, Oracle server process continues on and starts waiting for "SQL*Net message FROM client" again. It’s up to TCP stack to deliver this packet from this point and Oracle server process has no way for measuring directly when did the packet arrive (it would have to start intercepting TCP ACK packets at kernel level for that).
This behaviour also explains, why the "SQL*Net message TO client" waits are usually unbelievably short – like 1 microsecond etc.
...
Note that you can see longer times spent waiting for “SQL*Net message to client” when sending large amounts of data. This happens when your TCP send buffer gets full, thus TCP stack can not accept further packets. Sending will be blocked until the remote site sends back further ACK packets which state up to which byte in the TCP transmission stream it has received the data.
So, if you’re sending loads of data over a slow link or misconfigured TCP connection, the “SQL*Net message to client” wait time can be used as a low-confidence indicator of your SQL*Net throughput (in conjuction with “bytes sent via SQL*Net to client”), but never a measure of network latency!
SQL*Net message to client wait isn’t really what it’s thought to be | Tanel Poder: SQL Performance Tuning, System Troubleshooting and Training
I’ll reiterate that both SQL*Net message to client and SQL*Net more data to client waits only record the time it took to write the return data from Oracle’s userland SDU buffer to OS kernel-land TCP socket buffer. Thus the wait times of only microseconds. Thanks to that, all of the time a TCP packet spent “flying” towards the client is actually accounted in SQL*Net message from client wait statistic. The problem here is though, that we don’t know how much of this time was spent on the wire and how much of it was application think time.
SQL*Net message to client vs SQL*Net more data to client | Tanel Poder: SQL Performance Tuning, System Troubleshooting and Training
Anyway, as I said in my Oracle-L reply, these breaks are caused by bad application design which allows too many unhandled exceptions to be propagated all the way up to the client.
The solutions would be to reduce or eliminate the number of errors occurring, or at least put that code into PL/SQL blocks where errors would be handled and not propagated back to client every time.
SQL*Net break/reset to client | Tanel Poder: SQL Performance Tuning, System Troubleshooting and Training
What is happening is that an attempt is made to insert a row, most of the time a duplicate error results, the code catches this exception and does an update.
SQL*Net break/reset to client | Tanel Poder: SQL Performance Tuning, System Troubleshooting and Training
I was wondering if its the duplicate error and the exception handling which results in this wait event showing up.
My answer to that was following:
Yes, a SQL*Net break/reset happens when an error/unhandled exception is raised during a call (which means that the call executed didn’t complete normally, thus the call state must be reset).
たとえば、アプリケーションで送受信される大半のメッセージが8KB未満の場合は、70バイトをオーバーヘッドと考慮して、SDUを8KBに設定すれば問題ありません。利用可能なメモリーが十分にある場合は、SDUの最大値を使用すると、システム・コール数やOracle Net Servicesのオーバーヘッドを最小限に抑えることができます。
パフォーマンスの最適化
