FIX: SQL Server Components that Access the Registry in a Cluster Environment May Cause a Memory Leak (253738)

SYMPTOMS

Different SQL Server components that query the registry for information in a cluster environment may cause a memory leak on the server. The problem occurs on both Active/Passive and Active/Active cluster configurations. The different components that have shown this problem include the SQLAgent application, Transactional Replication Agents and the SQLMaint utility.

The SQLAgent application has a memory leak when it performs scheduled jobs in a clustered environment. This is easily observed with a job that is scheduled to run every minute, which causes the "private bytes" perfmon counter to increase continuously.

Transactional replication agents (Logread.exe and Distrib.exe) leak memory when run on a clustered SQL Server. The Distrib.exe file leaks memory at a much greater rate than the Logread.exe file. The Distrib.exe file, on limited hardware, has demonstrated that it can consume 180 MB of virtual memory within an hour. The consumption of virtual memory eventually results in problems that include failover of the virtual server and replication throughput degradation.

The SQLMaint Dump tasks query the registry and looks for a list of tape devices for every run of the backup task. Because the SQLMaint utility uses various extended procs to accomplish this, you see the memory leak in the SQL Server address space.

CAUSE

The leak may occur when an application is run on the cluster that accesses the registry through the Vdvapi32.dll file. The leak occurs at a greater rate when the requested key does not exist.

An example of this is when you try to open the ODBC compatibility keys. Unless the odbccmpt utility has been run these keys will not exist.

HKEY_LOCAL_MACHINE
    SOFTWARE
        Microsoft
            MSSQLServer$VirtualServerName
                Client
                    ODBCAppCompat

-and-

HKEY_LOCAL_MACHINE
    SOFTWARE
        Microsoft
            MSSQLServer$VirtualServerName
                Client
                    ODBCQIBehavior

RESOLUTION

A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. This fix may receive additional testing. Therefore, if you are not severely affected by this problem, Microsoft recommends that you wait for the next SQL Server service pack that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:

http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS

NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

The English version of this fix should have the following file attributes or later:

Version    File name     Platform
----------------------------------
7.00.745   s70745i.exe   x86

NOTE: Due to file dependencies, the most recent hotfix or feature that contains the preceding files may also contain additional files.

Be aware that any time SQL Server is un-clustered for any reason, the hotfix files must be removed.

There are two way to work around this:

After SQL Server is re-clustered, make sure that this hotfix is re-applied as per the Readme.txt file.

-or
Copy the entire contents of the SQL Server Enterprise CD onto a local drive, replace the DLL and EXE in the Cluster directory with the ones from the hotfix and then run the Failover Wizard from the local drive.

WORKAROUND

For Replication, use one of these workarounds:

Set the Transactional Replication Agents to run on a recurring schedule.
Move the Distribution database to a Server that is not clustered.
Monitor the server and intervene manually to stop and restart Transactional Replication agents when memory pressure increases.

For SQLAgent, use this workaround:

Monitor the server and intervene manually to stop and restart SQLAgent when memory pressure increases.

For the SQLMaint utility, use this workaround:

Try not to use the SQLMaint Dump task.