Article ID: 253738
Article Last Modified on 10/7/2005
APPLIES TO
- Microsoft SQL Server 7.0 Standard Edition
This article was previously published under Q253738
BUG #: 56553 (SQLBUG_70)
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:
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.
STATUS
Microsoft has confirmed this to be a problem in SQL Server 7.0.
Keywords: kbbug kbfix KB253738
