MS Sql Server loosing connection over WAN ..

Hello everyone.
We are experiencing a weird MS Sql Server behavior, and so far I have
not been able to identify the problem.. Any pointers will be deeply
appreciated.
Here is the scenario: we have three servers. One of them is running MS
Sql Server 2000, and the other two are application servers connecting
to the SQL Server. One of them is connecting over LAN, the other over
WAN. Every now and then, the one connecting over WAN becomes unable to
communicate with the SQL server. Even the Query Analyzer is not able
to connect (it cannot even get the list of databases to fill the
combo).
At the same time, the server connecting to SQL over LAN can connect
and function without any problems.
When the SQL server machine is rebooted, the server on WAN is able to
connect again...
I was suspenting some intermittent network problems, but at the time
the problem occurs, the SQL server and the problematic server on WAN
can ping each other without any problem and telnet from the server on
WAN to the SQL server port 1433 seems to work fine.
Configuration: All three servers running on Windows Server 2003 SP1,
SQL Server version is 2000 SP3a.
Where should we look into ?
Many thanks in advance,
Arifi Koseogluhttp://vyaskn.tripod.com/watch_your_timeouts.htm
check it out.
You should run a trace with profiler to capture info what happens in the
database when the problems acure.
Cheers
"arifi" wrote:
> Hello everyone.
> We are experiencing a weird MS Sql Server behavior, and so far I have
> not been able to identify the problem.. Any pointers will be deeply
> appreciated.
> Here is the scenario: we have three servers. One of them is running MS
> Sql Server 2000, and the other two are application servers connecting
> to the SQL Server. One of them is connecting over LAN, the other over
> WAN. Every now and then, the one connecting over WAN becomes unable to
> communicate with the SQL server. Even the Query Analyzer is not able
> to connect (it cannot even get the list of databases to fill the
> combo).
> At the same time, the server connecting to SQL over LAN can connect
> and function without any problems.
> When the SQL server machine is rebooted, the server on WAN is able to
> connect again...
> I was suspenting some intermittent network problems, but at the time
> the problem occurs, the SQL server and the problematic server on WAN
> can ping each other without any problem and telnet from the server on
> WAN to the SQL server port 1433 seems to work fine.
> Configuration: All three servers running on Windows Server 2003 SP1,
> SQL Server version is 2000 SP3a.
> Where should we look into ?
> Many thanks in advance,
> Arifi Koseoglu
>|||Sounds like this is a network issue, not a database issue. There could be a
resource limitation somewhere or something maybe happening on a router or
firewall somewhere that could be causing this.
--
MG
"arifi" wrote:
> Hello everyone.
> We are experiencing a weird MS Sql Server behavior, and so far I have
> not been able to identify the problem.. Any pointers will be deeply
> appreciated.
> Here is the scenario: we have three servers. One of them is running MS
> Sql Server 2000, and the other two are application servers connecting
> to the SQL Server. One of them is connecting over LAN, the other over
> WAN. Every now and then, the one connecting over WAN becomes unable to
> communicate with the SQL server. Even the Query Analyzer is not able
> to connect (it cannot even get the list of databases to fill the
> combo).
> At the same time, the server connecting to SQL over LAN can connect
> and function without any problems.
> When the SQL server machine is rebooted, the server on WAN is able to
> connect again...
> I was suspenting some intermittent network problems, but at the time
> the problem occurs, the SQL server and the problematic server on WAN
> can ping each other without any problem and telnet from the server on
> WAN to the SQL server port 1433 seems to work fine.
> Configuration: All three servers running on Windows Server 2003 SP1,
> SQL Server version is 2000 SP3a.
> Where should we look into ?
> Many thanks in advance,
> Arifi Koseoglu
>