Tuesday, February 21, 2012

REPLY : Network I/O error in SQL 2000 ?

It relates to spid85 where I saw the network I/O ERROR.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> Are you refering to DBCC SQLPERF? Changes were made regarding some of the
> reporting such as latch waits but I don't know of anything that changed wi
th
> network I/O
> John
> "DGreg" wrote:
>Hi
This will be a user connection, you may want to check the machine that is
was trying to connect.
John
"DGreg" wrote:
[vbcol=seagreen]
> It relates to spid85 where I saw the network I/O ERROR.
>
> "John Bell" wrote:
>|||Thanks John for the responses back, I'll have to look deeper into this.
Greg
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> This will be a user connection, you may want to check the machine that is
> was trying to connect.
> John
> "DGreg" wrote:
>|||John,
What I'm experiencing is locked transactions. Intermittently, we experience
a transaction/process which will not complete. The process info display in
enterprise manager displays a "Wait Type" of Network I/O. Although, we do
expect to receive this type of message from time to time because of the
application not responding in a timely fashion, network collision, etc., the
process wait will usually either finish or remove itself from the list. The
problem comes forward when the "waiting" process never quits or otherwise
removes itself after any period of time (wait time continues to grow). This
results in subsequent transactions/processes waiting on this particular
error. Consequently, we experience a system wide data outage on the table
with the lock on it as no other processes can access it. We were under the
impression that this type of "latch" or "hang" was corrected in SP4, but
since it's raised it's head again with SP4 applied to the SQL instance, we
are worried about potential outages in the future. Please let me know if we
have any work arounds for these type of process "latches".
Sincerely,
DGreg
"DGreg" wrote:
[vbcol=seagreen]
> Thanks John for the responses back, I'll have to look deeper into this.
> Greg
>
> "John Bell" wrote:
>|||Hi
It is my understanding that SP4 improved the reporting of such problems
rather than curing them see http://support.microsoft.com/kb/906344 although
I
believe that it is more to do with accessing data pages
http://support.microsoft.com/kb/822101/. Assuming that your lastwaittype is
NETWORKIO then you are waiting on the client to process your data. You may
want to look at what is happening on the client such as the specification of
the machine, also you may want to check if you are returning unnecessary
information such as result sets that are too wide, or procedures that should
be consolidated into one. Check out the scope of your transactions to see if
they can be made shorter and if there are unnecessary transactions, tuning
long running queries will also help. You also mentioned that you are seeing
network collissions, therefore this should be addressed.
John
"DGreg" wrote:
[vbcol=seagreen]
> John,
> What I'm experiencing is locked transactions. Intermittently, we experien
ce
> a transaction/process which will not complete. The process info display i
n
> enterprise manager displays a "Wait Type" of Network I/O. Although, we do
> expect to receive this type of message from time to time because of the
> application not responding in a timely fashion, network collision, etc., t
he
> process wait will usually either finish or remove itself from the list. T
he
> problem comes forward when the "waiting" process never quits or otherwise
> removes itself after any period of time (wait time continues to grow). Th
is
> results in subsequent transactions/processes waiting on this particular
> error. Consequently, we experience a system wide data outage on the table
> with the lock on it as no other processes can access it. We were under th
e
> impression that this type of "latch" or "hang" was corrected in SP4, but
> since it's raised it's head again with SP4 applied to the SQL instance, we
> are worried about potential outages in the future. Please let me know if
we
> have any work arounds for these type of process "latches".
> Sincerely,
> DGreg
> "DGreg" wrote:
>

No comments:

Post a Comment