I am working as a consultant on a project to upgrade an Access 2000 db to SQL Server. My client has bought off on everything, and they're ordering a new dedicated box this week. They're getting a rackmount machine running Windows Server and SQL Server 2005.
My expectation was that their IT people would take care of administrative & security issues such as setting the machine up, installing & starting SQL Server and configuring the proper accounts. Suprisingly though, they're going to mount the machine in the rack, turn it on and let me do all of this.
I'm new at SQL Server, but I'm comfortable working with database objects (tables, views, etc...) I'm not so comfortable with the networking or administrative side of things. It took me a couple of hours to be able to connect to the DB on my desktop machine over my home network. You can see why I'm intimidated at the prospect of getting things integrated & running on a pretty large corporate network.
Maybe I'm overblowing this, but this just gives me the willies.
Are my fears justified? Am I going to be ok if I just follow the standard procedures for allowing TCP/IP connections to the server? Am I going to have to deal with firewalls? (I think I know the answer - "it depends on their network.." - that's what I'm scared of.. I don't know anything about their network, and I don't know enough about networking in general to figure things out..)
Are there any other best practices that I should follow for a fresh install?So much depends on their network configuration that only their network people can give you a complete and correct answer to your questions. With that said, the general setup isn't difficult or complicated, the only problems I've ever run into arise when coping with installation specific problems.
Specific points to consider. If you don't know that you or your project need it, don't enable it. This especially applies to network protocols (only enable TCP/IP unless there is compelling reason for another protocol). If you don't need SQL Authentication, only select Windows Authentication.
Their network administrators are giving you a "blank check" to set things up as you'd like. This is idiocy on their part, but you should take advantage of it! Get the box running, in a minimal configuration. Set the box up as a "lone wolf" machine, then only after you are done getting things set up to suit yourself tell them you need a domain administrator login to join the box to their domain (this should put them into an outright panic), then stand back and watch the fun as they backpeddle furiously! At that point, you already have a tested, working configuration... Their only choices are to either a) give you the network equivalent of god-like powers, or b) pick up the ball that you've handed them and very quickly figure out how to run with it.
Note: This is evil, but they have brought it on themselves. The network administrators have already done one of the most stupid things that they are capable of doing, in order to force you to do all of their legwork for them. You are simply doing what they've asked, and will be presenting them with the most awful choice possible, but one that they ought to know is coming because there isn't any alternative.
-PatP|||Sorry I haven't been back for a few days..
I really don't want to do anything to create any friction with them. So far they've been fairly cooperative in allowing an outside consultant (me) to do development work for a department that's under their jurisdiction. They could easily send one email to upper management that would a) make my primary client's life miserable and b) completely cut me out of any work for them in the future.
After talking with one of their network techs yesterday, the server is up & running. It's 2005, running on a Windows Server 2003 Virtual Machine. She's going to be there, so hopefully she can take care of any network issues that arise. From what she said yesterday, they don't have any internal firewalls, so that should simplify things.
I'm going over there in a few hours to establish my login account, create a test database, and verify connectivity between it and an Access installation on an end user's machine.
Any final words of wisdom?
Friday, March 30, 2012
Network I/O error in SQL 2000 with SP4 ?
Can anyone explain this NETWORK I/O error I received using SP4, SQL 2K.
"spid85 Process ID 90 killed by hostname tester, host process ID 23328"It would seem that a user by the name of "tester" issued a KILL command for
your connection. Virtual homicide? Nah... Look up KILL in Books Online.
ML
http://milambda.blogspot.com/sql
"spid85 Process ID 90 killed by hostname tester, host process ID 23328"It would seem that a user by the name of "tester" issued a KILL command for
your connection. Virtual homicide? Nah... Look up KILL in Books Online.
ML
http://milambda.blogspot.com/sql
Network I/O error in SQL 2000 ?
SQL 2000 with SP4 what causes a network I/O error which kept the data from
reaching the workstations?Hi
It is unlikely that this is a specific SP4 issue. You don't say whether this
is an intermitent or constant problem or exacly which error number and
message you are getting. You also don't say if this is happening on all
workstations and or the server.
So things to try: check the protocols that being used on server and client,
check for firewalls/virus checkers stopping the port/pipe, make sure that you
can ping/telnet the server, check the name is resolved correctly, check
timeouts...
John
"DGreg" wrote:
> SQL 2000 with SP4 what causes a network I/O error which kept the data from
> reaching the workstations?
>|||John
The error is related to the wait time and wait request on sql2000.
"John Bell" wrote:
> Hi
> It is unlikely that this is a specific SP4 issue. You don't say whether this
> is an intermitent or constant problem or exacly which error number and
> message you are getting. You also don't say if this is happening on all
> workstations and or the server.
> So things to try: check the protocols that being used on server and client,
> check for firewalls/virus checkers stopping the port/pipe, make sure that you
> can ping/telnet the server, check the name is resolved correctly, check
> timeouts...
> John
> "DGreg" wrote:
> > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > reaching the workstations?
> >|||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 with
network I/O
John
"DGreg" wrote:
> John
> The error is related to the wait time and wait request on sql2000.
> "John Bell" wrote:
> > Hi
> >
> > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > is an intermitent or constant problem or exacly which error number and
> > message you are getting. You also don't say if this is happening on all
> > workstations and or the server.
> >
> > So things to try: check the protocols that being used on server and client,
> > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > can ping/telnet the server, check the name is resolved correctly, check
> > timeouts...
> >
> > John
> >
> > "DGreg" wrote:
> >
> > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > reaching the workstations?
> > >|||It relates to spid85 where I saw the network I/O ERROR.
"John Bell" wrote:
> 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 with
> network I/O
> John
> "DGreg" wrote:
> > John
> >
> > The error is related to the wait time and wait request on sql2000.
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > is an intermitent or constant problem or exacly which error number and
> > > message you are getting. You also don't say if this is happening on all
> > > workstations and or the server.
> > >
> > > So things to try: check the protocols that being used on server and client,
> > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > can ping/telnet the server, check the name is resolved correctly, check
> > > timeouts...
> > >
> > > John
> > >
> > > "DGreg" wrote:
> > >
> > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > reaching the workstations?
> > > >|||Hi
This will be a user connection, you may want to check the machine that is
was trying to connect.
John
"DGreg" wrote:
> It relates to spid85 where I saw the network I/O ERROR.
>
> "John Bell" wrote:
> > 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 with
> > network I/O
> >
> > John
> >
> > "DGreg" wrote:
> >
> > > John
> > >
> > > The error is related to the wait time and wait request on sql2000.
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi
> > > >
> > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > is an intermitent or constant problem or exacly which error number and
> > > > message you are getting. You also don't say if this is happening on all
> > > > workstations and or the server.
> > > >
> > > > So things to try: check the protocols that being used on server and client,
> > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > timeouts...
> > > >
> > > > John
> > > >
> > > > "DGreg" wrote:
> > > >
> > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > reaching the workstations?
> > > > >|||Thanks John for the responses back, I'll have to look deeper into this.
Greg
"John Bell" wrote:
> Hi
> This will be a user connection, you may want to check the machine that is
> was trying to connect.
> John
> "DGreg" wrote:
> > It relates to spid85 where I saw the network I/O ERROR.
> >
> >
> > "John Bell" wrote:
> >
> > > 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 with
> > > network I/O
> > >
> > > John
> > >
> > > "DGreg" wrote:
> > >
> > > > John
> > > >
> > > > The error is related to the wait time and wait request on sql2000.
> > > >
> > > > "John Bell" wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > > is an intermitent or constant problem or exacly which error number and
> > > > > message you are getting. You also don't say if this is happening on all
> > > > > workstations and or the server.
> > > > >
> > > > > So things to try: check the protocols that being used on server and client,
> > > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > > timeouts...
> > > > >
> > > > > John
> > > > >
> > > > > "DGreg" wrote:
> > > > >
> > > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > > reaching the workstations?
> > > > > >|||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:
> Thanks John for the responses back, I'll have to look deeper into this.
> Greg
>
> "John Bell" wrote:
> > Hi
> >
> > This will be a user connection, you may want to check the machine that is
> > was trying to connect.
> >
> > John
> >
> > "DGreg" wrote:
> >
> > > It relates to spid85 where I saw the network I/O ERROR.
> > >
> > >
> > > "John Bell" wrote:
> > >
> > > > 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 with
> > > > network I/O
> > > >
> > > > John
> > > >
> > > > "DGreg" wrote:
> > > >
> > > > > John
> > > > >
> > > > > The error is related to the wait time and wait request on sql2000.
> > > > >
> > > > > "John Bell" wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > > > is an intermitent or constant problem or exacly which error number and
> > > > > > message you are getting. You also don't say if this is happening on all
> > > > > > workstations and or the server.
> > > > > >
> > > > > > So things to try: check the protocols that being used on server and client,
> > > > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > > > timeouts...
> > > > > >
> > > > > > John
> > > > > >
> > > > > > "DGreg" wrote:
> > > > > >
> > > > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > > > reaching the workstations?
> > > > > > >|||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:
> 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:
> > Thanks John for the responses back, I'll have to look deeper into this.
> >
> > Greg
> >
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > This will be a user connection, you may want to check the machine that is
> > > was trying to connect.
> > >
> > > John
> > >
> > > "DGreg" wrote:
> > >
> > > > It relates to spid85 where I saw the network I/O ERROR.
> > > >
> > > >
> > > > "John Bell" wrote:
> > > >
> > > > > 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 with
> > > > > network I/O
> > > > >
> > > > > John
> > > > >
> > > > > "DGreg" wrote:
> > > > >
> > > > > > John
> > > > > >
> > > > > > The error is related to the wait time and wait request on sql2000.
> > > > > >
> > > > > > "John Bell" wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > > > > is an intermitent or constant problem or exacly which error number and
> > > > > > > message you are getting. You also don't say if this is happening on all
> > > > > > > workstations and or the server.
> > > > > > >
> > > > > > > So things to try: check the protocols that being used on server and client,
> > > > > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > > > > timeouts...
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > "DGreg" wrote:
> > > > > > >
> > > > > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > > > > reaching the workstations?
> > > > > > > >
reaching the workstations?Hi
It is unlikely that this is a specific SP4 issue. You don't say whether this
is an intermitent or constant problem or exacly which error number and
message you are getting. You also don't say if this is happening on all
workstations and or the server.
So things to try: check the protocols that being used on server and client,
check for firewalls/virus checkers stopping the port/pipe, make sure that you
can ping/telnet the server, check the name is resolved correctly, check
timeouts...
John
"DGreg" wrote:
> SQL 2000 with SP4 what causes a network I/O error which kept the data from
> reaching the workstations?
>|||John
The error is related to the wait time and wait request on sql2000.
"John Bell" wrote:
> Hi
> It is unlikely that this is a specific SP4 issue. You don't say whether this
> is an intermitent or constant problem or exacly which error number and
> message you are getting. You also don't say if this is happening on all
> workstations and or the server.
> So things to try: check the protocols that being used on server and client,
> check for firewalls/virus checkers stopping the port/pipe, make sure that you
> can ping/telnet the server, check the name is resolved correctly, check
> timeouts...
> John
> "DGreg" wrote:
> > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > reaching the workstations?
> >|||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 with
network I/O
John
"DGreg" wrote:
> John
> The error is related to the wait time and wait request on sql2000.
> "John Bell" wrote:
> > Hi
> >
> > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > is an intermitent or constant problem or exacly which error number and
> > message you are getting. You also don't say if this is happening on all
> > workstations and or the server.
> >
> > So things to try: check the protocols that being used on server and client,
> > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > can ping/telnet the server, check the name is resolved correctly, check
> > timeouts...
> >
> > John
> >
> > "DGreg" wrote:
> >
> > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > reaching the workstations?
> > >|||It relates to spid85 where I saw the network I/O ERROR.
"John Bell" wrote:
> 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 with
> network I/O
> John
> "DGreg" wrote:
> > John
> >
> > The error is related to the wait time and wait request on sql2000.
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > is an intermitent or constant problem or exacly which error number and
> > > message you are getting. You also don't say if this is happening on all
> > > workstations and or the server.
> > >
> > > So things to try: check the protocols that being used on server and client,
> > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > can ping/telnet the server, check the name is resolved correctly, check
> > > timeouts...
> > >
> > > John
> > >
> > > "DGreg" wrote:
> > >
> > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > reaching the workstations?
> > > >|||Hi
This will be a user connection, you may want to check the machine that is
was trying to connect.
John
"DGreg" wrote:
> It relates to spid85 where I saw the network I/O ERROR.
>
> "John Bell" wrote:
> > 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 with
> > network I/O
> >
> > John
> >
> > "DGreg" wrote:
> >
> > > John
> > >
> > > The error is related to the wait time and wait request on sql2000.
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi
> > > >
> > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > is an intermitent or constant problem or exacly which error number and
> > > > message you are getting. You also don't say if this is happening on all
> > > > workstations and or the server.
> > > >
> > > > So things to try: check the protocols that being used on server and client,
> > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > timeouts...
> > > >
> > > > John
> > > >
> > > > "DGreg" wrote:
> > > >
> > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > reaching the workstations?
> > > > >|||Thanks John for the responses back, I'll have to look deeper into this.
Greg
"John Bell" wrote:
> Hi
> This will be a user connection, you may want to check the machine that is
> was trying to connect.
> John
> "DGreg" wrote:
> > It relates to spid85 where I saw the network I/O ERROR.
> >
> >
> > "John Bell" wrote:
> >
> > > 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 with
> > > network I/O
> > >
> > > John
> > >
> > > "DGreg" wrote:
> > >
> > > > John
> > > >
> > > > The error is related to the wait time and wait request on sql2000.
> > > >
> > > > "John Bell" wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > > is an intermitent or constant problem or exacly which error number and
> > > > > message you are getting. You also don't say if this is happening on all
> > > > > workstations and or the server.
> > > > >
> > > > > So things to try: check the protocols that being used on server and client,
> > > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > > timeouts...
> > > > >
> > > > > John
> > > > >
> > > > > "DGreg" wrote:
> > > > >
> > > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > > reaching the workstations?
> > > > > >|||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:
> Thanks John for the responses back, I'll have to look deeper into this.
> Greg
>
> "John Bell" wrote:
> > Hi
> >
> > This will be a user connection, you may want to check the machine that is
> > was trying to connect.
> >
> > John
> >
> > "DGreg" wrote:
> >
> > > It relates to spid85 where I saw the network I/O ERROR.
> > >
> > >
> > > "John Bell" wrote:
> > >
> > > > 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 with
> > > > network I/O
> > > >
> > > > John
> > > >
> > > > "DGreg" wrote:
> > > >
> > > > > John
> > > > >
> > > > > The error is related to the wait time and wait request on sql2000.
> > > > >
> > > > > "John Bell" wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > > > is an intermitent or constant problem or exacly which error number and
> > > > > > message you are getting. You also don't say if this is happening on all
> > > > > > workstations and or the server.
> > > > > >
> > > > > > So things to try: check the protocols that being used on server and client,
> > > > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > > > timeouts...
> > > > > >
> > > > > > John
> > > > > >
> > > > > > "DGreg" wrote:
> > > > > >
> > > > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > > > reaching the workstations?
> > > > > > >|||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:
> 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:
> > Thanks John for the responses back, I'll have to look deeper into this.
> >
> > Greg
> >
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > This will be a user connection, you may want to check the machine that is
> > > was trying to connect.
> > >
> > > John
> > >
> > > "DGreg" wrote:
> > >
> > > > It relates to spid85 where I saw the network I/O ERROR.
> > > >
> > > >
> > > > "John Bell" wrote:
> > > >
> > > > > 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 with
> > > > > network I/O
> > > > >
> > > > > John
> > > > >
> > > > > "DGreg" wrote:
> > > > >
> > > > > > John
> > > > > >
> > > > > > The error is related to the wait time and wait request on sql2000.
> > > > > >
> > > > > > "John Bell" wrote:
> > > > > >
> > > > > > > Hi
> > > > > > >
> > > > > > > It is unlikely that this is a specific SP4 issue. You don't say whether this
> > > > > > > is an intermitent or constant problem or exacly which error number and
> > > > > > > message you are getting. You also don't say if this is happening on all
> > > > > > > workstations and or the server.
> > > > > > >
> > > > > > > So things to try: check the protocols that being used on server and client,
> > > > > > > check for firewalls/virus checkers stopping the port/pipe, make sure that you
> > > > > > > can ping/telnet the server, check the name is resolved correctly, check
> > > > > > > timeouts...
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > "DGreg" wrote:
> > > > > > >
> > > > > > > > SQL 2000 with SP4 what causes a network I/O error which kept the data from
> > > > > > > > reaching the workstations?
> > > > > > > >
Network I/O error in SQL 2000 ?
SQL 2000 with SP4 what causes a network I/O error which kept the data from
reaching the workstations?Hi
It is unlikely that this is a specific SP4 issue. You don't say whether this
is an intermitent or constant problem or exacly which error number and
message you are getting. You also don't say if this is happening on all
workstations and or the server.
So things to try: check the protocols that being used on server and client,
check for firewalls/virus checkers stopping the port/pipe, make sure that yo
u
can ping/telnet the server, check the name is resolved correctly, check
timeouts...
John
"DGreg" wrote:
> SQL 2000 with SP4 what causes a network I/O error which kept the data from
> reaching the workstations?
>|||John
The error is related to the wait time and wait request on sql2000.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> It is unlikely that this is a specific SP4 issue. You don't say whether th
is
> is an intermitent or constant problem or exacly which error number and
> message you are getting. You also don't say if this is happening on all
> workstations and or the server.
> So things to try: check the protocols that being used on server and client
,
> check for firewalls/virus checkers stopping the port/pipe, make sure that
you
> can ping/telnet the server, check the name is resolved correctly, check
> timeouts...
> John
> "DGreg" wrote:
>|||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 with
network I/O
John
"DGreg" wrote:
[vbcol=seagreen]
> John
> The error is related to the wait time and wait request on sql2000.
> "John Bell" wrote:
>
reaching the workstations?Hi
It is unlikely that this is a specific SP4 issue. You don't say whether this
is an intermitent or constant problem or exacly which error number and
message you are getting. You also don't say if this is happening on all
workstations and or the server.
So things to try: check the protocols that being used on server and client,
check for firewalls/virus checkers stopping the port/pipe, make sure that yo
u
can ping/telnet the server, check the name is resolved correctly, check
timeouts...
John
"DGreg" wrote:
> SQL 2000 with SP4 what causes a network I/O error which kept the data from
> reaching the workstations?
>|||John
The error is related to the wait time and wait request on sql2000.
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> It is unlikely that this is a specific SP4 issue. You don't say whether th
is
> is an intermitent or constant problem or exacly which error number and
> message you are getting. You also don't say if this is happening on all
> workstations and or the server.
> So things to try: check the protocols that being used on server and client
,
> check for firewalls/virus checkers stopping the port/pipe, make sure that
you
> can ping/telnet the server, check the name is resolved correctly, check
> timeouts...
> John
> "DGreg" wrote:
>|||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 with
network I/O
John
"DGreg" wrote:
[vbcol=seagreen]
> John
> The error is related to the wait time and wait request on sql2000.
> "John Bell" wrote:
>
Network Error...
Hi All,
I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
installed in it... From past few days I am the schedule jobs are getting
failed... its giving below error...
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
(WrapperRead()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Plz advice how to get rid of this...
Thanks in advance.
-Mohit.Refer this KB Article. This talks about similar error message when restoring
database.
http://support.microsoft.com/default.aspx?scid=kb;en-us;827452
It looks like it is MDAC bug and work around is change the SQL Server to use
TCP/IP
Ravi
"Mohit" wrote:
> Hi All,
> I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
> installed in it... From past few days I am the schedule jobs are getting
> failed... its giving below error...
> [Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
> (WrapperRead()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
>
> Plz advice how to get rid of this...
> Thanks in advance.
> -Mohit.
>
I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
installed in it... From past few days I am the schedule jobs are getting
failed... its giving below error...
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
(WrapperRead()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Plz advice how to get rid of this...
Thanks in advance.
-Mohit.Refer this KB Article. This talks about similar error message when restoring
database.
http://support.microsoft.com/default.aspx?scid=kb;en-us;827452
It looks like it is MDAC bug and work around is change the SQL Server to use
TCP/IP
Ravi
"Mohit" wrote:
> Hi All,
> I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
> installed in it... From past few days I am the schedule jobs are getting
> failed... its giving below error...
> [Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
> (WrapperRead()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
>
> Plz advice how to get rid of this...
> Thanks in advance.
> -Mohit.
>
Network Error...
Hi All,
I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
installed in it... From past few days I am the schedule jobs are getting
failed... its giving below error...
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
(WrapperRead()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Plz advice how to get rid of this...
Thanks in advance.
-Mohit.
Refer this KB Article. This talks about similar error message when restoring
database.
http://support.microsoft.com/default...b;en-us;827452
It looks like it is MDAC bug and work around is change the SQL Server to use
TCP/IP
Ravi
"Mohit" wrote:
> Hi All,
> I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
> installed in it... From past few days I am the schedule jobs are getting
> failed... its giving below error...
> [Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
> (WrapperRead()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
>
> Plz advice how to get rid of this...
> Thanks in advance.
> -Mohit.
>
I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
installed in it... From past few days I am the schedule jobs are getting
failed... its giving below error...
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
(WrapperRead()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Plz advice how to get rid of this...
Thanks in advance.
-Mohit.
Refer this KB Article. This talks about similar error message when restoring
database.
http://support.microsoft.com/default...b;en-us;827452
It looks like it is MDAC bug and work around is change the SQL Server to use
TCP/IP
Ravi
"Mohit" wrote:
> Hi All,
> I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
> installed in it... From past few days I am the schedule jobs are getting
> failed... its giving below error...
> [Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
> (WrapperRead()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
>
> Plz advice how to get rid of this...
> Thanks in advance.
> -Mohit.
>
Network Error...
Hi All,
I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
installed in it... From past few days I am the schedule jobs are getting
failed... its giving below error...
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
(WrapperRead()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Plz advice how to get rid of this...
Thanks in advance.
-Mohit.Refer this KB Article. This talks about similar error message when restoring
database.
http://support.microsoft.com/defaul...kb;en-us;827452
It looks like it is MDAC bug and work around is change the SQL Server to use
TCP/IP
Ravi
"Mohit" wrote:
> Hi All,
> I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
> installed in it... From past few days I am the schedule jobs are getting
> failed... its giving below error...
> [Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRea
d
> (WrapperRead()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
>
> Plz advice how to get rid of this...
> Thanks in advance.
> -Mohit.
>sql
I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
installed in it... From past few days I am the schedule jobs are getting
failed... its giving below error...
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRead
(WrapperRead()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Plz advice how to get rid of this...
Thanks in advance.
-Mohit.Refer this KB Article. This talks about similar error message when restoring
database.
http://support.microsoft.com/defaul...kb;en-us;827452
It looks like it is MDAC bug and work around is change the SQL Server to use
TCP/IP
Ravi
"Mohit" wrote:
> Hi All,
> I have a windows 2003 server and MS SQL Server 2000 Enterprise edtion
> installed in it... From past few days I am the schedule jobs are getting
> failed... its giving below error...
> [Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionRea
d
> (WrapperRead()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
>
> Plz advice how to get rid of this...
> Thanks in advance.
> -Mohit.
>sql
Subscribe to:
Posts (Atom)