When you say, "the error is only with SQL Server," do you mean that you've determined that applications accessing SQL Server are the only ones affected by the resets? From your first post, I assume the frequency of resets increases as the load on SQL Server increases.
What you need right now is analysis to determine the causes of the SQL slowdown. Things to look for[ol][li]Locks - run sp_lock, sp_who2 or use Enterprise Manager (EM) to view locks. Locks cause processes to wait for the lock to be freed. (Read faq183-714 and faq183-767.)
[li]Long running queries - Poor design is usually the culprit but locking, poor indexing, inadequate hardware.
Look for queries that create Temporary tables. Improper use of temp tables can really slow things down. Read
Look for queries that use cursors. Cursors are very inefficient. Usually, cursors are ysed to step through data, one row at a time. SQL is designed to deal with sets of data. Therefore, procedures using cursors can often be rewritten to use relationships and avoid the overhead of cursors.
[li]Proper indexing on tables - you can have too few or too many indexes! Poor indexing can lead to locking and slow running queries.
[li]Use performance monitor to view cache hit ratio, processor usage, disk usage, disk latency, ... There are lots of factors involved.[/ol]I've only touched on a few items. There are many articles available from Microsoft and others that discuss performance. I've listed a few below. Good luck.
faq183-768
Terry
"I shall try to correct errors when shown to be errors, and I shall adopt new views so fast as they shall appear to be true views." - Abraham Lincoln