tag:blogger.com,1999:blog-36801146304502491482024-03-13T08:41:11.556-07:00IndexOfBoundsRSCWhttp://www.blogger.com/profile/02302252893176707740noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3680114630450249148.post-33383084704108516922010-02-27T19:08:00.000-08:002010-03-13T02:24:31.783-08:00System.Data.SqlClient.SqlError: Could not continue scan with NOLOCK due to data movement.<span style="font-weight: bold;"><span style="font-size:130%;">Background</span><br /></span><span style="font-size:100%;">I constantly<span style="font-weight: bold;"> </span>found this exception making occasional appearance in our production server error</span> log, Although i cannot ensure it was connected to a bug we're looking into, I was determined to dig the root cause out<span style="font-weight: bold;">. </span><br /><br />I surfed through the web, but could not find the reasons related to our scenarios<span style="font-weight: bold;">, </span>so I consulted a experienced DBA in our company. <span style="font-weight: bold;"><br /></span><span style="font-weight: bold;"><br /><span style="font-size:130%;">Finding</span><br /></span>Inside the offending SPROC, the author use <a href="http://articles.techrepublic.com.com/5100-10878_11-6185492.html">NOLOCK </a>to avoid lock burdens put on querying many tables. <span>Moreover, these tables are updated/deleted regularly by replication services. In consequence, if the data rows </span><span>retrieved</span><span> - by </span><span>SELECT (NOLOCK) - </span><span>are deleted by replication services during the process, this exception emerges.</span><span style="font-weight: bold;"><br /><br /></span><span>PS: Be aware it's separate from <a href="http://blogs.neudesic.com/blogs/phil_scott/archive/2005/12/05/11.aspx">dirty read</a> that you mostly hear around NOLOCK. </span><span style="font-weight: bold;"><br /><br /><span style="font-size:130%;">Reference<br /></span></span><span style="font-size:100%;">For folks who is interesting in lock levels available in SQL server, refer to</span><span style="font-size:100%;"> <a href="http://blogs.neudesic.com/blogs/phil_scott/archive/2005/12/05/11.aspx">Locking in Microsoft SQL Server</a>.</span><span style="font-weight: bold;"><br /></span>RSCWhttp://www.blogger.com/profile/02302252893176707740noreply@blogger.com0tag:blogger.com,1999:blog-3680114630450249148.post-28118275247936392682010-02-06T05:14:00.000-08:002010-03-13T02:16:15.726-08:00Mysterious Hashtable Exception "Hashtable insert failed. Load factor too high"<span style="font-weight: bold;font-size:130%;" >Background</span><br />Our production servers (.NET 2.0) ran into this exception suddenly a few months ago. It came from a snippet of codes updating <span style="font-weight: bold;">Hashtable</span>. Weird enough, the web sites are running for a long while and, and from SVN logs, no evidence shows anyone modified associated codes recently. More strange, the exception appears merely on a couple of web servers.<br /><br />Even though I've checked with our system administrators that <span style="color:black;"></span><a href="http://support.microsoft.com/kb/968432" target="_blank">http://support.microsoft.com/<wbr>kb/968432</a> is updated on the offending servers, the exception still emerged intermittently (You might search on the web to see somebody declaring this can be resolved by the KB).<br /><br />Let's begin the measure that I adopted to tackle it in our environment.<br /><br /><span style="font-weight: bold;font-size:130%;" >Workaound</span><br />Restart IIS - this bothers pretty much our supporting engineers.<br /><br /><span style="font-weight: bold;font-size:130%;" >Solution</span><br />Referring to this <a href="http://social.msdn.microsoft.com/Forums/en/netfxbcl/thread/172f4f77-601e-4b4f-8d98-582f8f62a98e">thread</a>, a master points out the exception might arise when multiple threads <span style="font-weight: bold;">concurrently </span>modify the Hashtable. True enough, our web sites use the Hashtable as a cache, and around 4 threads will modify it quite frequently. So I warp the updating codes around with <span style="font-weight: bold;">lock</span> keyword as follows:<br /><br /> readonly static object _sync = new object();<br /> ...<br /> lock (_sync)<br />{<br /> // codes modifying Hashtable<br /> }<br /><br />After the fix updates to production servers, the exception disappears for more than two weeks, looking like the solution really works out for our environment!RSCWhttp://www.blogger.com/profile/02302252893176707740noreply@blogger.com0