Forum Discussion
Troubleshooting relocated database
For both your questions, the answer is yes, it's possible.
Out of the two questions, if I were a betting man, I'd wager it's the second scenario of your web services host doing the looking.
As far as actions go, I'd recommend running a network trace on the web services host using something like Wireshark to see if any traffic is passing from that host to the old database host.
When the SQL services on the old host are shut down, you may find a lot of failed connections. Conversely, when the services are started, you may see successful connections to the various SQL services - the database and browser services possibly being the most likely.
A low-tech alternative you can try on the old host if the services are started is checking the active connections through connecting to the old host using something like SQL Server Management Studio with sufficient permissions and running:
SELECT d.name , c.net_transport , c.client_net_address , c.client_tcp_port , c.connect_time , c.last_read FROM sys.dm_exec_sessions AS s INNER JOIN sys.dm_exec_connections AS c ON s.session_id = c.session_id INNER JOIN sys.databases AS d ON s.database_id = d.database_id WHERE c.net_transport <> 'shared memory' ORDER BY d.name , c.client_net_address , c.client_tcp_portWhich produces output similar to the following:
You might then be able to identify the IP address of either the web services host (most likely) or even the new SQL host (I'd say this is highly unlikely, but anything is possible) which in turn might help you further investigate where any additions references may be coming from.
It won't necessarily be easy to locate any references, independent of whether they're in a configuration file or buried somewhere within a table of the database, but there's not much we can offer for finding those.
The options above are only useful in the context of proving/disproving that something is still aware of the old host and trying to talk to it, but all that's going to do is confirm your existing suspicion, not solve the cause.
Cheers,
Lain
For both your questions, the answer is yes, it's possible.
Out of the two questions, if I were a betting man, I'd wager it's the second scenario of your web services host doing the looking.
As far as actions go, I'd recommend running a network trace on the web services host using something like Wireshark to see if any traffic is passing from that host to the old database host.
When the SQL services on the old host are shut down, you may find a lot of failed connections. Conversely, when the services are started, you may see successful connections to the various SQL services - the database and browser services possibly being the most likely.
A low-tech alternative you can try on the old host if the services are started is checking the active connections through connecting to the old host using something like SQL Server Management Studio with sufficient permissions and running:
SELECT
d.name
, c.net_transport
, c.client_net_address
, c.client_tcp_port
, c.connect_time
, c.last_read
FROM
sys.dm_exec_sessions AS s INNER JOIN
sys.dm_exec_connections AS c ON s.session_id = c.session_id INNER JOIN
sys.databases AS d ON s.database_id = d.database_id
WHERE
c.net_transport <> 'shared memory'
ORDER BY
d.name
, c.client_net_address
, c.client_tcp_port
Which produces output similar to the following:
You might then be able to identify the IP address of either the web services host (most likely) or even the new SQL host (I'd say this is highly unlikely, but anything is possible) which in turn might help you further investigate where any additions references may be coming from.
It won't necessarily be easy to locate any references, independent of whether they're in a configuration file or buried somewhere within a table of the database, but there's not much we can offer for finding those.
The options above are only useful in the context of proving/disproving that something is still aware of the old host and trying to talk to it, but all that's going to do is confirm your existing suspicion, not solve the cause.
Cheers,
Lain
LainRobertson thanks for your input. Your suggestions caused me to look even harder at my server-side application services. It turns out that this is where the issue resided. Our server-side services use log4net and there was a datasource in the log4net.config file that was pointing to Host1.
After updating datasource in the log4net.config file to point to Host2, the performance issues being observed on the client-side application were resolved.
Thanks for helping me think more clearly about this!
Good stuff!
Nothing worse than unexplained performance hits you just know shouldn't be there yet you can't quite put your finger on the cause of.
Cheers,
Lain
