Question:  I see high "SQL*Net message to client" messages in my AWR report.

What are "SQL*Net message to client" waits and how do I tune SQL*Net message to client waits?   Is this a TCP issue?

Answer:  The SQL*Net message to client  may indicate a network-related issue that causes clients too long to get data from the database server.  Thus, it can be a TCP issue, but it is not limited to that.

Common causes of a high SQL*Net message to client might include TCP/IP bottlenecks or TNS parameter issues:

High network latency:  Check with netstat to ensure that your TCP/IP does not have bottlenecks.
Incorrect TNS parameters:  Setting such as tcp.nodelay can impact the time for SQL message to client waits.  See these tips on Oracle TNS network tuning .
The SQL*Net message to client Oracle metric indicates the server (foreground process) is sending a message to the client.  Network bottlenecks are very common in distributed systems and those with high network traffic. They are manifested as SQL*Net wait events:

Top 5 Wait Events
                                                            % Total
Event                                    Waits    Time (cs) Wt Time
--------------------------------- ------------ ------------ -------
SQL*Net more data to client          3,914,935    9,475,372   99.76
db file sequential read              1,367,659        6,129     .06
db file parallel write                   7,582        5,001     .05
rdbms ipc reply                             26        4,612     .05
db file scattered read                  16,886        2,446     .03
Also see my notes on “SQL*Net message to client” and network throughput.

Tanel Poder has a great note that explains why “SQL*Message from client” is a good indicator of throughput (e.g. by TCP/IP based database links), but that “SQL*Net Message” wait events cannot be used to measure network latency because of the architecture of the Transparent Network Substrate (TNS):

“So, if you’re sending loads of data over a slow link or mis-configured TCP connection, the “SQL*Net message to client” wait time can be used as a low-confidence indicator of your SQL*Net throughput (in conjunction with “bytes sent via SQL*Net to client”), but never a measure of network latency!”

Question:  I see high "SQL*Net message to client" messages in my AWR report.

What are "SQL*Net message to client" waits and how do I tune SQL*Net message to client waits?   Is this a TCP issue?

Answer:  The SQL*Net message to client  may indicate a network-related issue that causes clients too long to get data from the database server.  Thus, it can be a TCP issue, but it is not limited to that.

Common causes of a high SQL*Net message to client might include TCP/IP bottlenecks or TNS parameter issues:

High network latency:  Check with netstat to ensure that your TCP/IP does not have bottlenecks.
Incorrect TNS parameters:  Setting such as tcp.nodelay can impact the time for SQL message to client waits.  See these tips on Oracle TNS network tuning .
The SQL*Net message to client Oracle metric indicates the server (foreground process) is sending a message to the client.  Network bottlenecks are very common in distributed systems and those with high network traffic. They are manifested as SQL*Net wait events:

Top 5 Wait Events
                                                            % Total
Event                                    Waits    Time (cs) Wt Time
--------------------------------- ------------ ------------ -------
SQL*Net more data to client          3,914,935    9,475,372   99.76
db file sequential read              1,367,659        6,129     .06
db file parallel write                   7,582        5,001     .05
rdbms ipc reply                             26        4,612     .05
db file scattered read                  16,886        2,446     .03
Also see my notes on “SQL*Net message to client” and network throughput.

Tanel Poder has a great note that explains why “SQL*Message from client” is a good indicator of throughput (e.g. by TCP/IP based database links), but that “SQL*Net Message” wait events cannot be used to measure network latency because of the architecture of the Transparent Network Substrate (TNS):

“So, if you’re sending loads of data over a slow link or mis-configured TCP connection, the “SQL*Net message to client” wait time can be used as a low-confidence indicator of your SQL*Net throughput (in conjunction with “bytes sent via SQL*Net to client”), but never a measure of network latency!”