FIX: When you use Transact-SQL cursor variables to perform operations that have large iterations, memory leaks may occur in SQL Server 2000

Article translations Article translations
Article ID: 837957 - View products that this article applies to.
BUG #: 471233 (SQL Server 8.0)


Microsoft distributes SQL Server 2000 fixes as one downloadable file. Because the fixes are cumulative, each new release contains all the hotfixes and all the software updates that were included with the previous SQL Server 2000 software update.
Expand all | Collapse all

On This Page

SYMPTOMS

When you use Transact-SQL cursor variables to perform operations that have large iterations, you may notice the following behavior:
  • The client that performs the operations on the computer that is running SQL Server may return out-of-memory errors that are similar to the following:

    Error message 1

    Msg 701: There is insufficient system memory to run this query.
    Error message 2

    Msg 1204: The SQL Server cannot obtain a LOCK resource at this time. Rerun your statement when there are fewer active users or ask the system administrator to check the SQL Server lock and memory configuration.
    Error message 3

    Msg 17803: Insufficient memory available.
  • The response from the computer that is running SQL Server 2000 may become slower.
  • The DBCC FREEPROCCACHE Transact-SQL statement may not free the memory or may not clear the procedure cache. This behavior may occur even when the client is disconnected from the computer that is running SQL Server.

CAUSE

This behavior occurs because the resources that are used by the cursor variable are not released.

WORKAROUND

To work around this problem, you must release the resources that are allocated to the cursor variables. To do so, you must make sure of the following:
  • If you use a SET Transact-SQL statement to set a cursor variable, you must use a DEALLOCATE Transact-SQL statement to release the resources that are used by the cursor when the cursor is no longer required.
  • If you use an OPEN Transact-SQL statement to open a cursor variable, you must use a CLOSE Transact-SQL statement to release the resources that are used by the cursor when the cursor is no longer required.

RESOLUTION

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

Hotfix information

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.
   Date         Time   Version            Size    File name
   --------------------------------------------------------------------
   31-May-2003  05:15  2000.80.818.0      78,400  Console.exe      
   27-Oct-2003  14:51  2000.80.873.0     315,968  Custtask.dll     
   30-Jan-2004  02:59  2000.80.911.0      33,340  Dbmslpcn.dll     
   24-Apr-2003  12:42                    786,432  Distmdl.ldf
   24-Apr-2003  12:42                  2,359,296  Distmdl.mdf
   29-Jan-2003  12:25                        180  Drop_repl_hotfix.sql
   11-Sep-2003  13:56  2000.80.859.0   1,905,216  Dtspkg.dll       
   26-Aug-2003  06:46  2000.80.854.0     528,960  Dtspump.dll      
   23-Jun-2003  09:10  2000.80.837.0   1,557,052  Dtsui.dll        
   23-Jun-2003  09:10  2000.80.837.0     639,552  Dtswiz.dll       
   23-Apr-2003  13:21                    747,927  Instdist.sql
   02-May-2003  12:26                      1,581  Inst_repl_hotfix.sql
   30-Jan-2004  02:59  2000.80.911.0      90,692  Msgprox.dll      
   31-Mar-2003  12:37                      1,873  Odsole.sql
   30-Jan-2004  02:59  2000.80.911.0      62,024  Odsole70.dll     
   30-Jan-2004  02:59  2000.80.911.0      25,144  Opends60.dll     
   30-Jan-2004  02:59  2000.80.911.0      57,904  Osql.exe         
   02-Apr-2003  09:45  2000.80.797.0     279,104  Pfutil80.dll     
   04-Aug-2003  04:47                    550,780  Procsyst.sql
   11-Sep-2003  11:07                     12,305  Qfe469315.sql
   22-May-2003  09:27                     19,195  Qfe469571.sql
   29-Jan-2004  11:47                  1,090,380  Replmerg.sql
   30-Jan-2004  02:59  2000.80.911.0     221,768  Replprov.dll     
   30-Jan-2004  02:59  2000.80.911.0     307,784  Replrec.dll      
   29-Jan-2004  09:54  2000.80.911.0     159,813  Replres.rll
   05-Sep-2003  10:30                  1,087,150  Replsys.sql
   13-Aug-2003  02:58                    986,603  Repltran.sql
   30-Jan-2004  02:59  2000.80.911.0     287,304  Rinitcom.dll     
   30-Jan-2004  02:59  2000.80.911.0      57,916  Semnt.dll        
   29-Jul-2003  06:43  2000.80.819.0     492,096  Semobj.dll       
   31-May-2003  04:57  2000.80.818.0     172,032  Semobj.rll
   02-Jan-2004  06:12  2000.80.904.0      53,832  Snapshot.exe     
   09-Dec-2003  06:37                    117,834  Sp3_serv_uni.sql
   04-Feb-2004  11:16  2000.80.913.0      28,672  Sqlagent.dll     
   04-Feb-2004  11:17  2000.80.913.0     311,872  Sqlagent.exe     
   19-Feb-2004  04:32  2000.80.916.0     168,001  Sqlakw32.dll     
   30-Jan-2004  02:59  2000.80.911.0   4,215,360  Sqldmo.dll       
   07-Apr-2003  04:14                     25,172  Sqldumper.exe    
   29-Jan-2004  09:47  2000.80.911.0      28,672  Sqlevn70.rll
   30-Jan-2004  02:59  2000.80.911.0     180,792  Sqlmap70.dll     
   02-Sep-2003  13:26  2000.80.857.0     188,992  Sqlmmc.dll       
   02-Sep-2003  09:33  2000.80.857.0     479,232  Sqlmmc.rll
   21-Oct-2003  10:38  2000.80.871.0     401,984  Sqlqry.dll       
   30-Jan-2004  02:59  2000.80.911.0      57,920  Sqlrepss.dll     
   01-Mar-2004  10:33  2000.80.919.0   7,618,641  Sqlservr.exe     
   30-Jan-2004  02:59  2000.80.911.0     590,396  Sqlsort.dll      
   30-Jan-2004  02:59  2000.80.911.0      45,644  Sqlvdi.dll       
   30-Jan-2004  02:59  2000.80.911.0     106,588  Sqsrvres.dll     
   30-Jan-2004  02:59  2000.80.911.0      33,340  Ssmslpcn.dll     
   30-Jan-2004  02:59  2000.80.911.0      82,492  Ssnetlib.dll     
   30-Jan-2004  02:59  2000.80.911.0      25,148  Ssnmpn70.dll     
   27-Oct-2003  14:51  2000.80.873.0     123,456  Stardds.dll      
   30-Jan-2004  02:59  2000.80.911.0     158,240  Svrnetcn.dll     
   30-Jan-2004  02:59  2000.80.911.0      76,416  Svrnetcn.exe     
   30-Apr-2003  10:22  2000.80.816.0      45,132  Ums.dll          
   30-Jan-2004  02:59  2000.80.911.0      98,872  Xpweb70.dll      
Note Because of file dependencies, the most recent hotfix or feature that contains these files may also contain additional files.

STATUS

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.

MORE INFORMATION

The behavior that is mentioned in the "Symptoms" section occurs when you set a cursor variable, and you then re-use the same cursor variable without releasing the resources that are used by the cursor variable. For example, consider the following stored procedure:
CREATE PROCEDURE MYPROC
BEGIN

    DECLARE @CURSOR CURSOR
    SET @CURSOR = CURSOR FOR SELECT * FROM AUTHORS     -- FIRST ASSIGNMENT (THIS ASSIGNMENT LEAKS WHEN A SECOND ASSIGNMENT TAKES PLACE WITHOUT DEALLOCATION)
    
    --Other Transact-SQL statements
    
    SET @CURSOR = CURSOR FOR SELECT * FROM AUTHORS    --  SECOND ASSIGNMENT
    
    --Other Transact-SQL statements

END

If you run this stored procedure, you may receive the out-of-memory error messages. To resolve the problem, you must modify the stored procedure code as follows:
CREATE PROCEDURE MYPROC
BEGIN

    DECLARE @CURSOR CURSOR
    SET @CURSOR = CURSOR FOR SELECT * FROM AUTHORS     -- FIRST ASSIGNMENT

    --Other Transact-SQL statements

    DEALLOCATE @CURSOR --DEALLOCATING THE CURSOR VARIABLE BEFORE A SECOND ASSIGNMENT

    SET @CURSOR = CURSOR FOR SELECT * FROM AUTHORS    --  SECOND ASSIGNMENT

    --Other Transact-SQL statements

    DEALLOCATE @CURSOR --DEALLOCATING THE CURSOR VARIABLE THAT WAS ASSIGNED SECOND

END

REFERENCES

For additional information about software updates, click the following article number to view the article in the Microsoft Knowledge Base:
824684 Description of the standard terminology that is used to describe Microsoft software updates
For additional information about memory related issues, click the following article numbers to view the articles in the Microsoft Knowledge Base:
810052 FIX: A memory leak occurs when cursors are opened during a connection
818095 FIX: Cursor plans are not removed from the cache when virtual memory depleted
820773 FIX: JDBC driver leaks server cursors
271624 INF: Using DBCC MEMORYSTATUS to monitor SQL Server memory usage

Properties

Article ID: 837957 - Last Review: November 2, 2007 - Revision: 3.3
APPLIES TO
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000, Workgroup Edition
  • Microsoft SQL Server 2000 Desktop Engine (Windows)
  • Microsoft SQL Server 2000 Enterprise Edition 64-bit
Keywords: 
kbhotfixserver kbqfe kbqfe kbtsql kbsqlprog kbquery kberrmsg kbmemory kbsqlserv2000presp4fix kbfix kbbug KB837957

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com