Re: Connection failures

Then definitely check your AUTO NEGOTIATE settings on both the switch ports
and the NICs for all players, clients and server, for both link speed and
duplex. This would explain why sometimes you have a problem and sometimes
you don't, for some clients and not others.

Usually these can reset after patching the bios on the switches.

Sincerely,


Anthony Thomas


--

<kristan.mcdonald@xxxxxxxxxxxxxx> wrote in message
news:1166619576.945335.285910@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks for your help and suggestions - SQL error logs don't indicate
anything, and we're running per-processor. No connection limits set,
and I've not applied 2187 but will shortly.

We've got a bit deeper with this now, and it seems like it may be line
related as we've found a few more apps (exchange for one) that seems to
suffer a similar problem.

Connecting via ISQL when the outage is taking place works, however
doing something like select * from sysdatabases (which I guess is
similar to what query analyzer does at login if the object browser is
showing) I get only the first 10-15 databases (same place each time)
and it dies. Looking at packet traces from both ends there's loads of
retransmission and out of sequence arrivals going on, so I'm now 99%
certain it's not SQL related.

Still doesn't explain why I can run the same query on a box on exactly
the switch and it will work, whereas doing in on the cluster will fail.

We're working with the network providers at the moment, but they're
trying to claim if it works on one box then it must be cluster related.

Thanks guys,

Kristan

Anthony Thomas wrote:

What do your SQL error logs say?

What is your configuration? Are you running per Processor Licenses or
CAL-based?

Do you have any concurrent connection limits configured? What does
sp_configure show?

You said the system was SP4. Have you applied the 2187 hotfix yet?

I think you need to start fresh. You say the connections are
intermittent
and only for one branch. Are the lost connections always from this one
branch? If so, it is your physical layer, in the network. Check your
routers from dropped packets. Make sure no one is using AUTO NEGOTIATE
on
the network link and duplex.

Is there anything special about this branch? Is it the furthest away?
Does
it have the slowest connection speed? Does it have the most users?

If an outage is sporadic but affects everyone equally, it is the system
resource, or at least a common point in between. If you can localize a
problem (like it is affecting only one branch or one group of users),
then
it will be somewhere unique to them, but at a common point for them,
like a
router at the branch site.

Hope this helps, but without any additional data, that's about the best
we've got.

Sincerely,


Anthony Thomas


--

<kristan.mcdonald@xxxxxxxxxxxxxx> wrote in message
news:1166013373.732672.101210@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Geoff,

Thanks for the advice, the weird thing about this is other network
connections seem fine, it's just SQL that fails, and even then it's
not
a total block. Name resolution seems to work fine and I can connect to
the shares on the server and copy files off so there's nothing wrong
with the physical layer. If I try to connect using query analyser, it
will reject my password and I'll get a login failed if I enter the
wrong one, or try to open the connection if I use the correct one, so
at least at some level SQL is responding to these requests.

We had an incident yesterday where the remote office lost SQL again,
however when odbcping and isql, I seemed to be able to connect and run
queries. I wouldn't treat this as gospel though as everything was a
bit
rushed and confused trying to get connectivity restored. It also
seemed
that if you turned off the object browser in query analyzer you could
get a connection.

I'm starting to think it might be SQL server itself, but I don't know
enough about how query analyzer connects to verify it, and it still
doesn't explain why the odbc application connections fail... or does
it?

Any help appreciated!

Thanks,

Kristan

Geoff N. Hiten wrote:

Treat this as you would any network communications failure.

Name resolution
IP path resolution (ping)
SQL client connect (Query Analyzer)
application connect.

Somewhere you will find where the glitch is. I would guess DNS
cache
problems on the client, but that is just to impress everyone if it
really is
the problem.

--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP




.

Relevant Pages

  • Re: Connection issues between .Net framwok and SQl Express 2005
    ... You will no longer need the database MDF file name in the connection string. ... simply attach the ASPNETDB.mdf to SQL Server permenantly, ... as USER INSTANCE on existing SQL Server Express, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Performance of ODBC
    ... if you have a software firewall; forward 1433/1434 to your server ... I've now created my own server with SQL Server 2005 Express, ... glitch concerns the Upsizing Wizard. ... I originally set up my ODBC connection via ...
    (microsoft.public.access.adp.sqlserver)
  • SQL 2005 Express and VS .Net 2003 wizard error More options
    ... Open the server explorer panel ... Go to the Provider tab and select SQL NAtive Client (DON'T use oledb ... Go back to the Connection tab and carry on setting up the connection ... I have installed Visual Studio 2005 Professional and then Visual Studio ...
    (microsoft.public.sqlserver)
  • Re: Timeout problem with SS2K, VS03
    ... I noticed calls in sql profiler: ... This is the server side debug stored procedure. ... a timeout issue that I cannot identify the source of. ... transaction is committed and the connection is closed cleanly and all ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Cannot connect to SQL Express on 2003 Machine from XP machine
    ... listening on UDP 1434 using netstat -abn, ... And i double checked the connection string, and i did have it the right ... But I have another 2000 server that I can connect to fine, ... I am trying to connect from an XP SP2 machine remotely to a SQL Express ...
    (microsoft.public.sqlserver.connect)