添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
){outline:none;box-shadow:none;}select::-ms-expand{;}:root,:host{--chakra-vh:100vh;}@supports (height: -webkit-fill-available){:root,:host{--chakra-vh:-webkit-fill-available;}}@supports (height: -moz-fill-available){:root,:host{--chakra-vh:-moz-fill-available;}}@supports (height: 100dvh){:root,:host{--chakra-vh:100dvh;}}
Link to home
Create Account Log in
Avatar of crishna1
crishna1 Flag for United States of America

asked on

All pipe instances are busy

the exporter - about once every two to three weeks - the exporter just dies and gives us this error message:
Connecting to XXX*Master
getConnection failed (\\.\pipe\mssql$gmrprod\sq l\query (All pipe instances are busy))
Connection to XXX*Master Failed
any idea what it's doing when it times out? and is there a way to increase the exporter time out?
Any suggestions to fix the above issue will be greatly appreciated.
Thanks.
I'm not certain this is a timout issue, is it?  There is a small chance that this could be a DOS attack, or other malware... which actually could be running on that server.
This looks like MS SQL.  Have you applied all the patches?  You could be getting hit by the Slammer virus every few weeks.
Check here for more information: http://www.microsoft.com/security/slammer.asp
At a minimum, make certain you have this patch applied to the server:
http://www.microsoft.com/technet/security/bulletin/MS02-061.mspx
All slammer takes to clear out is a reboot... but it will be infected again a few days or weeks later if it isn't patched...
You are right , this is MS Sql.
Also,FYI :we are using it for fail over and disaster recovery - Our product normally runs 100% on the same node.
my dumb question , is there anything like increasing the number of pipes?
please advice
Thanks.
Ohhh.  I wish elsewhere right now so that I could test this, but it looks like the maximum number of named pipes are automatically determined by the operating system based on the resources available.  When the error occurs, take a look at "Computer Management", and I think it's sessions to see the pipes currently in use.  (I don't think that is IPC$ traffic, but I could be wrong.  I'll have to get back to my system tomorrow to check...)
(Anyone else want to jump on that one before tomorrow for an assist?)
In any event, I suspect if the system is working correctly for weeks at a time, without problems, and they SQL Server isn't patched, that you are getting infected every few weeks by the Slammer virus.  You can look here: http://isc.sans.org at the volume of port 1434 traffic to see that Slammer and it's ilk are still alive and well on the net.  :-(  )
ASKER CERTIFIED SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
any further information on this??
Have you been able to confirm whether you have the Slammer virus?  Is the SQL Server patched to at least SP3?
The number of pipes is fluid based on available resources.
I am currently located in a different location from where the server is, i need to check with the folks there.
let me get back with you on those, is there anyother information  i need to ask for?
Appreciate your help!
Thanks.
When the problem occurs, does the CPU utilization on the SQL server spike up to around 100%?
They can check the patch level by running Query Analyzer and entering "SELECT @@VERSION"
Which will return a line which starts with: "Microsoft SQL Server  2000 - 8.00.818 (Intel X86)   [...]"
Per http://www.tacktech.com/display.cfm?ttid=60
8.00.818 is the current version.  If they are running a version before 8.00.760, you have reason to be concerned.
The following is the info i got from my folks, please advice!
Thanks.
Answers :
All SQL Servers have been updated with the SLAMMR virus fix.
SP3 has been installed for sometime now.
The problem has only happened twice this year and we weren't
monitoring the CPU.
We don't run SQL Servers here on port 1433. The SQL Servers are all named
instances clustered via Veritas software. Which is the reason we had to use
the Named Pipe name in the connection string of the exporter. The Net Bios
name or the ip address will not work connecting to this SQL database, at
least we haven't been able to get it to work since moving off MS Cluster to
Veritas.