We've devoted a resource to this today, but I have to believe it's something easy that we're overlooking. The scneario is that we have a production Web application that until last weekend had a SQL 2000 back end. This weekend we installed a new instance of SQL 2005 and everything works (we tested in a sandbox environment, but someone must not have load tested enough) and never saw these exceptions.
So, after the upgrade we now receive 100's of thexe SQL excptions per day:
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)
Does anyone know what we've overlooked that's causing this issue?
Thanks for any help!
If such exceptions occur only when machines running Win2K/WinXP, you can take a look at this KB:
http://support.microsoft.com/kb/919710
If the SQL Server is running on Win2003 SP1 and all cilents may encounter such issue, try to use the regedit.exe utility to add a new DWORD value namedSynAttackProtect to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ with value data of 00000000.
|||Joy. We found the problem today. In efforts to improve the performance of the aspnet_xxx sprocs, we added (with nolock) to many of them. This helped tremendously in SQL 2000. It killed us when moving to 2005. Removing this fromaspnet_Profile_GetProperties solved the problem. There were more things we'd found along the way after I posted this, like with health monitoring and analysis of the SQL logs, we saw that MANY of our profiles were not being decoded as they were corrupt - not being fully read from the DB. Anyway, this explains why no one else on the Web is talking about the subject, as recommended--they probably did modify their aspnet_xxx sprocs.
No comments:
Post a Comment