This article has been archived. It is offered "as is" and will no longer be updated.
Bug #: 469995 (Shiloh_bugs)
The memory that SQL Server uses during sorting and hashing operations is allocated from the buffer pool as a stolen buffer. Stolen buffers must always remain in the virtual address space. They cannot be unmapped to a Microsoft Windows 2000 Address Windowing Extensions (AWE) location. SQL Server uses a throttle to limit how much memory can be used for sorting and for hashing. SQL Server limits the memory for these reasons:
So that the whole buffer pool will not be consumed by stolen buffers.
So that the buffer pool can continue to serve as a data cache.
On systems with AWE enabled, the computation of how much memory can be used as workspace memory for sorting and for hashing is sometimes higher than it is on a non-AWE system. Because stolen buffers must always remain in the address space, the additional AWE memory should be irrelevant to this computation. The fix that is discussed in this article corrects the problem so that the computation of the workspace available for sorting and for hashing is consistent across both configurations.
Because of the miscalculation, sort and hash operations may try to use more memory from the buffer pool than can remain mapped. As a result, a BPool::Map error that is similar to the following is written to the SQL Server error log followed by the output of the DBCC MEMORYSTATUS command:
In the output that is shown earlier, you can see that SQL Server will allow multiple queries that are requesting a total of 140712 buffers to run concurrently. In the earlier example, there are six queries that are executing with sorts or with hashes. These six queries have been granted the use of 130303 buffers (140712 - 10409 = 130303).
Service pack information
To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
290211 How to obtain the latest SQL Server 2000 service pack
The English version of this fix 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.