Article ID: 835864 - View products that this article applies to.
This article has been archived. It is offered "as is" and will no longer be updated.
Bug #: 470933 (SHILOH_BUGS)
Microsoft SQL Server 2000 fixes are distributed as one downloadable file. Because the fixes are cumulative, each new release contains all the hotfixes and all the security fixes that were included in the previous SQL Server 2000 fix release.
You have a workload that is running on a multiprocessor computer that forces SQL Server to perform many memory allocation operations and memory free operations each second (several hundred small batches that require compilation each second, for example). You may notice that a query that typically runs in a certain time takes longer to complete, although the query processes the same amount of data, uses the same query plan, and performs the same amount of I/O. The only noticeable difference is an increase in the CPU time and the elapsed time that it takes to run the query. In extreme cases, you may find that simple queries (such as SET ROWCOUNT 0) might take several hundred milliseconds to run and several hundred milliseconds of CPU time.
Service pack informationTo resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/290211/ )How to obtain the latest SQL Server 2000 service pack
Hotfix informationThe English version of this hotfix has the file attributes (or later) that are listed in the following table. The dates and times for these files are listed in coordinated universal time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.
Note Because of file dependencies, the most recent hotfix or feature that contains these files may also contain additional files.
Date Time Version Size File name -------------------------------------------------------------------- 31-May-2003 18:45 2000.80.818.0 78,400 Console.exe 28-Oct-2003 04:21 2000.80.873.0 315,968 Custtask.dll 02-Oct-2003 20:59 2000.80.867.0 33,340 Dbmslpcn.dll 25-Apr-2003 02:12 786,432 Distmdl.ldf 25-Apr-2003 02:12 2,359,296 Distmdl.mdf 30-Jan-2003 01:55 180 Drop_repl_hotfix.sql 12-Sep-2003 03:26 2000.80.859.0 1,905,216 Dtspkg.dll 26-Aug-2003 20:16 2000.80.854.0 528,960 Dtspump.dll 23-Jun-2003 22:40 2000.80.837.0 1,557,052 Dtsui.dll 23-Jun-2003 22:40 2000.80.837.0 639,552 Dtswiz.dll 24-Apr-2003 02:51 747,927 Instdist.sql 10-Oct-2003 18:52 745,961 Instmsdb.sql 03-May-2003 01:56 1,581 Inst_repl_hotfix.sql 08-Feb-2003 06:40 2000.80.765.0 90,692 Msgprox.dll 01-Apr-2003 02:07 1,873 Odsole.sql 05-Apr-2003 01:46 2000.80.800.0 62,024 Odsole70.dll 07-May-2003 20:41 2000.80.819.0 25,144 Opends60.dll 02-Apr-2003 21:48 2000.80.796.0 57,904 Osql.exe 02-Apr-2003 23:15 2000.80.797.0 279,104 Pfutil80.dll 04-Aug-2003 18:17 550,780 Procsyst.sql 12-Sep-2003 00:37 12,305 Qfe469315.sql 22-May-2003 22:57 19,195 Qfe469571.sql 20-Jan-2004 00:45 1,090,380 Replmerg.sql 06-Sep-2003 07:18 2000.80.858.0 221,768 Replprov.dll 16-Jan-2004 01:24 2000.80.908.0 307,784 Replrec.dll 16-Jan-2004 01:13 2000.80.908.0 159,813 Replres.rll 06-Sep-2003 00:00 1,087,150 Replsys.sql 13-Aug-2003 16:28 986,603 Repltran.sql 02-Jan-2004 19:42 2000.80.904.0 287,304 Rinitcom.dll 22-Oct-2003 00:08 2000.80.871.0 57,916 Semnt.dll 29-Jul-2003 20:13 2000.80.819.0 492,096 Semobj.dll 31-May-2003 18:27 2000.80.818.0 172,032 Semobj.rll 02-Jan-2004 19:42 2000.80.904.0 53,832 Snapshot.exe 09-Dec-2003 20:07 117,834 Sp3_serv_uni.sql 16-Jan-2004 01:23 2000.80.908.0 28,672 Sqlagent.dll 16-Jan-2004 01:24 2000.80.908.0 311,872 Sqlagent.exe 07-Jan-2004 22:38 2000.80.905.0 126,976 Sqlakw32.dll 01-Jun-2003 01:01 2000.80.818.0 4,215,360 Sqldmo.dll 07-Apr-2003 17:44 25,172 Sqldumper.exe 19-Mar-2003 18:20 2000.80.789.0 28,672 Sqlevn70.rll 27-Sep-2003 04:42 2000.80.865.0 180,792 Sqlmap70.dll 03-Sep-2003 02:56 2000.80.857.0 188,992 Sqlmmc.dll 02-Sep-2003 23:03 2000.80.857.0 479,232 Sqlmmc.rll 22-Oct-2003 00:08 2000.80.871.0 401,984 Sqlqry.dll 08-Feb-2003 06:40 2000.80.765.0 57,920 Sqlrepss.dll 24-Jan-2004 01:59 2000.80.910.0 7,610,449 Sqlservr.exe 25-Jul-2003 21:44 2000.80.845.0 590,396 Sqlsort.dll 08-Feb-2003 06:40 2000.80.765.0 45,644 Sqlvdi.dll 24-Jan-2004 01:59 2000.80.910.0 106,588 Sqsrvres.dll 02-Oct-2003 20:59 2000.80.867.0 33,340 Ssmslpcn.dll 01-Jun-2003 01:01 2000.80.818.0 82,492 Ssnetlib.dll 01-Jun-2003 01:01 2000.80.818.0 25,148 Ssnmpn70.dll 28-Oct-2003 04:21 2000.80.873.0 123,456 Stardds.dll 01-Jun-2003 01:01 2000.80.818.0 158,240 Svrnetcn.dll 31-May-2003 18:59 2000.80.818.0 76,416 Svrnetcn.exe 30-Apr-2003 23:52 2000.80.816.0 45,132 Ums.dll 02-Jul-2003 00:19 2000.80.834.0 98,816 Xpweb70.dll
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section of this article.
This problem was first corrected in Microsoft SQL Server 2000 Service Pack 4.
For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/824684/ )Description of the Standard Terminology That Is Used to Describe Microsoft Software Updates
Most memory allocation requests in SQL Server are handled by allocating a page from the buffer pool. SQL Server maintains counters to track how many pages have been stolen from the buffer pool to be use as a generic memory buffer instead of a buffer for a database page. The DBCC MEMORYSTATUS command makes part of this information available and is automatically logged in the error log in certain out-of-memory conditions. These numbers are also used to trigger other events in the server, such as the lazywriter process. For additional information about these counters and stolen memory, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/271624/ )INF: Using DBCC MEMORYSTATUS to monitor SQL Server memory usage
On multiprocessor computers, access to these counter values must be serialized. SQL Server serializes the counter values by using a spinlock. With a spinlock, the thread that wants to acquire the spinlock tries to acquire the lock. If the lock is not available, the thread spins in a loop, periodically rechecking the availability of the resource. If the operation that occurs inside the spinlock protection has a very short duration, such as incrementing or decrementing a counter, using a spinlock can be much faster than using a kernel synchronization object and then switching from user mode to kernel mode and back. However, if the spinlock becomes highly contended, a thread may spend more time spinning and trying to acquire the lock than it does performing useful work. Because of this, spinlocks are not a good choice for protecting a heavily-contended data structure.
This hotfix uses a different synchronization mechanism to maintain these counter values. It requires a substantial amount of contention to cause any noticeable delay or increase in CPU time. Typically, you must have a server with 8 or more processors (so that 8 threads are running at the same time) to be able to process a workload that can generate this much contention. This much contention may be more likely to occur if hyperthreading is enabled because it effectively doubles the number of SQL threads that can be running.
Article ID: 835864 - Last Review: January 17, 2015 - Revision: 3.3