The server is sending a break or reset message to the client. The session running on the server is waiting for a reply from the client.
These waits are caused by an application attempting to:
Select from a closed cursor
Select on a cursor after the last row has already been fetched and no data has been returned
Select on a non-existent table
Insert a duplicate row into a uniquely indexed table
Issuing a query with invalid syntax
If the value, v$session_wait.p2, for this parameter equals 0, it means a reset was sent to the client. A non-zero value means that the break was sent to the client.
The rest of the information in this section is only valid for this metric when it appears in either the Enterprise Manager Grid Control or the Enterprise Manager Database Control (if applicable).
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
|
Target Version |
Evaluation and Collection Frequency |
Upload Frequency |
Operator |
Default Warning Threshold |
Default Critical Threshold |
Consecutive Number of Occurrences Preceding Notification |
Alert Text |
|
pre-10g |
Every Minute |
After Every Sample |
> |
20 |
Not Defined |
3 |
%value%%% of service time is spent waiting on the 'SQL*Net break/reset to client' event. |
(DeltaNetResetToClientTime/DeltaServiceTime)*100 where:
DeltaNetResetToClientTime: difference of 'sum of time waited for sessions of foreground processes on the 'SQL*Net break/reset to client' event' between sample end and start
DeltaServiceTime: difference of 'sum of time waited for sessions of foreground processes on events not in IdleEvents + sum of 'CPU used when call started' for sessions of foreground processes' between sample end and start
Wait time: Up to one second, then loop back and check that buffer is clean.
Parameters:
P1: Absolute file number
P2: Block number
See Idle Events
If these waits are significant, track down the application logic producing these errors to reduce these waits. Check in v$sysstat "parse count (failures)" to see that statements have been parsed where columns or tables are unknown. The statistic "parse count (failures)" does not increase if you send SQL with invalid syntax.
The clearest method to track down the root cause of the error is to run tracing on the users experiencing the wait. Their trace files will contain the SQL statements failing and generating the break/reset wait.
Related Topics
About Alerts
About the Metric Detail Page
Editing Thresholds
Understanding Line Charts
Copyright © 1996, 2009, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.