Tracing a network communication.
We recently migrated a SQL 2000 database and an accompanying file share from a physical to a virtual machine.
All went well and the physical SQL database and file share were taken offline and the shares removed. No problems so far.
The problem came in that when they physical machine was shut down the client application using the database started to exhibit seizures although on each occasion it would evenutally come back with the right information.
The puzzle is that even with the SQL server service completely disabled on the physical machine the client has no issue, it is only when the server is shut down it somehow brings about a problem.
I realise this problem could have many causes and think that what is needed is a way of detecting what exactly is being accessed on the physical server and by what in order to track down the source of the problem.
Can anybody reccomend a tool I can run on the physical server so I can observe the nature of inbound communications which are being received?
Thanks in advance.
All went well and the physical SQL database and file share were taken offline and the shares removed. No problems so far.
The problem came in that when they physical machine was shut down the client application using the database started to exhibit seizures although on each occasion it would evenutally come back with the right information.
The puzzle is that even with the SQL server service completely disabled on the physical machine the client has no issue, it is only when the server is shut down it somehow brings about a problem.
I realise this problem could have many causes and think that what is needed is a way of detecting what exactly is being accessed on the physical server and by what in order to track down the source of the problem.
Can anybody reccomend a tool I can run on the physical server so I can observe the nature of inbound communications which are being received?
Thanks in advance.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi Icohan,
The problem turned out to be that the database clients used a UNC filepath which was still pointing to the old server. The UNC filepath was for some icons within the client which defaulted to other icons when they could not locate the ICO file on the server they started on.
With the old server on but with the shares disabled the server responded quickly with a denial and so the client defferred after a short delay to the default icons.
With the server off however the server did not respond and caused an even more pronounced delay to the client in trying to resolve the UNC filepath.
I used a script in SQL server to scan every single text field in the database for references to the old server and detected the problem.
Having corrected this not only did it resolve the issue, the client works a darn sight faster than it did in the first place.
Many thanks for your help!
The problem turned out to be that the database clients used a UNC filepath which was still pointing to the old server. The UNC filepath was for some icons within the client which defaulted to other icons when they could not locate the ICO file on the server they started on.
With the old server on but with the shares disabled the server responded quickly with a denial and so the client defferred after a short delay to the default icons.
With the server off however the server did not respond and caused an even more pronounced delay to the client in trying to resolve the UNC filepath.
I used a script in SQL server to scan every single text field in the database for references to the old server and detected the problem.
Having corrected this not only did it resolve the issue, the client works a darn sight faster than it did in the first place.
Many thanks for your help!
ASKER
The problem turned out to be that the database clients used a UNC filepath which was still pointing to the old server. The UNC filepath was for some icons within the client which defaulted to other icons when they could not locate the ICO file on the server they started on.
With the old server on but with the shares disabled the server responded quickly with a denial and so the client defferred after a short delay to the default icons.
With the server off however the server did not respond and caused an even more pronounced delay to the client in trying to resolve the UNC filepath.
I used a script in SQL server to scan every single text field in the database for references to the old server and detected the problem.
Having corrected this not only did it resolve the issue, the client works a darn sight faster than it did in the first place.
Many thanks for your help!