SQL Server 2000 Memory issue

  • Dear all,

    We're having some memory issues with our SQL Server 2000 installation and were wondering if anybody has experienced anything similar/has any advice.

    Our installation is as follows –

    SQL Server 2000 Enterprise Edition SP4 Build 8.00.2187

    Windows Server 2003 Standard Edition SP2 Build 3790

    3743MB of RAM

    SQL Server has been configured to use 2314MB (fixed)

    We have 7 logged shipped databases

    Average connections – 450 – 600 at any one time during the day.

    The problem tends to manifest when the transaction log backups for the above logged shipped databases start to fail. Even then they may recover for a time and then start to fail again. The error in the SQL Server error log is as follows –

    BACKUP failed to complete the command BACKUP LOG [abc] TO DISK = N'G:\TLOGS\abc\abc_tlog_200712031340.TRN' WITH INIT , NOUNLOAD , NOSKIP , STATS = 10, NOFORMAT

    The error message we get in the Database Maintenance Plan History for the log shipper in question is –

    [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 701: [Microsoft][ODBC SQL Server Driver][SQL Server]There is insufficient system memory to run this query.

    [Microsoft][ODBC SQL Server Driver][SQL Server]BACKUP LOG is terminating abnormally.

    The error message in the SQL Agent job history for the Transaction Log backup job is

    Executed as user: Domain\xxxxxxxxxx. sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed.

    Once we start to get the above messages normal back up jobs and SQL Agent jobs start to also fail.

    We currently resolve the problem by stopping and starting SQL Server. The problem may then not occur for another 3 weeks or it may occur within 2 days.

    Has anybody experienced a similar situation or have any advice?

    Thanks,

    A.

  • Alan,

    the reason for the "insufficient memory" messages is very likely that the largest available contingous memory block is smaller than the maxtransfer size for the backup. The default blocksize is 4 Mb, but if your on SP3 or higher you can define a smaller blocksize in you backup statement.

    See: http://msdn2.microsoft.com/en-us/library/ms186865.aspx

    and http://support.microsoft.com/default.aspx/kb/904804

    But even though changing the maxtransfersize might solve your problem in the short term, the real problem is not enough memory. If you can't add additional RAM I've seen instances there even the lowest value for maxtransfersize was too high. We ended up running dbcc freeproccache to free up memory. Yes it will hit your performance, but so does restarting the service.

    [font="Verdana"]Markus Bohse[/font]

  • Markus,

    Many thanks. We have been running dbcc freeproccache regularly since the latest incident and whilst it has only been a week ago we haven't had the issue since. This may just be coincidence becasue the period between failures is variable.

    I'm inclined to continue with this until the next failure while investigating your suggested 'maxtransfer size' solution with a view to implementing it after the next failure. I guess I'm intrigued to see if it happens again whilst continuing to free up the cache.

    Much appreciated. I'll keep you updated.

    Best Regards,

    Alan.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply