MORE INFORMATION
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may
require you to reinstall your operating system. Microsoft cannot guarantee that you can solve
problems that result from using Registry Editor incorrectly. Use Registry Editor at your own
risk.
The SMS\Logs\Dataldr.log and the Windows NT Application Event Log on both the Microsoft SQL Server-based computer and the Systems Management Server (SMS) site server provide information about possible causes. Also check the SQL Server error log.
MIF Files
If a backlog of MIF files accumulates at the site server because MIF files are not being processed:
- The Inventory Data Loader might be busy trying to send MIF files to Replication Manager to be sent to a parent site. The Inventory Data Loader may be trying to parse damaged MIF files. The Inventory Data Loader may slowed by antivirus scans that are running on the files. These scans may cause file lock contention. To determine whether Inventory Data Loader successfully parsed the MIF files that were placed in the SMS\Inboxes\Dataldr.box\Process folder, examine the Badmifs folder. If there are a large number of recent files in the Badmifs folder, the clients are generating bad MIF files, and Inventory Data Loader is busy trying to parse them.
- The Inventory Data Loader might be receiving MIF files from clients whose discovery data records (DDRs) are not yet in the SMS site database. To determine whether the clients that are sending the MIF files have been discovered by this site server and have been reported to the Systems Management Server site database, examine the Orphans folder. Inventory Data Loader moves a MIF file to the Orphans folder if the client that sent the file is not yet in the SMS site database. Inventory Data Loader creates a DDR and moves it to the SMS\Inboxes\Ddm.box for Discovery Data Manager to process. This occurs so that the discovery data can be added to the SMS site database. If there are many files in the Orphans folder, Inventory Data Loader might be busy creating DDRs. Inventory Data Loader tries to process MIF files in the Orphans folder every 10 minutes.
- Examine the Inventory Data Loader status messages or the Dataldr.log file to determine if the Inventory Data Loader has been able to connect to the SMS site database server. Inventory Data Loader might not be able to write a discovered client's MIF to the database. If the Inventory Data Loader cannot connect to the SMS site database server, it holds the MIF file in a queue, and then tries again after 10 minutes. If there are many MIF files waiting to be processed, this queue can grow quickly.
If the MIF files are not being processed on the site server:
- Verify that Inventory Data Loader successfully parsed the MIF file by checking Inventory Data Loader status messages or the Dataldr.log file. If the MIF file cannot be processed, it is transferred to the Badmifs folder.
- Verify that the MIF file is not larger than the "Maximum MIF Size" setting. By default, this is 5,000,000 bytes, or about 4.7 megabytes. If the MIF file is larger than the size that is indicated in the site server's registry key, it is rejected and placed in the Badmifs folder.
- You can increase the maximum MIF size by editing the following registry key on the site server:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components
\SMS_Inventory_Dataloader\Max MIF Size
Inventory Frequency
You may have to reduce the inventory frequency. For example, you may have a problem if you have six child sites of 2,000 to 4,000 computers, plus clients that run an inventory every time they log on. If these clients all report to a central site, a backlog occurs. You may want to change the inventory frequency, or reduce the number of classes in the Sms_def.mof file for which inventory information is being collected.
Larger MIFs such as MIFs that contain custom information, are processed more slowly.
For additional information about MIF files, click the article number below
to view the article in the Microsoft Knowledge Base:
198766 SMS: How MIF Files Are Processed in Version 2.0
SQL Server Configuration
If the Open Objects setting is less than 5,000, Dataloader may become backed up. Tempdb should be 20 to 30 percent of the largest database on the SQL Server-based computer. User connections must be set correctly. In SQL Server versions 7.0 and 2000, set the user connections to "0" so that SQL Server manages the connections automatically.
For information about memory management in SQL Server 7.0 and 2000, see the
Microsoft SQL 7.0 Resource Guide,
Microsoft SQL 2000 Resource Guide, or the SQL Books online.
Use Performance Monitor to check the cache-hit ratio. Make sure that the database is in cache and not paging out. Note that it should be above 99 percent. You may have to add RAM, dedicated memory, or both to your SQL Server-based computer.
Database and Transaction Log Size
Verify that the Systems Management Server database and its transaction log are not full, and that the transaction log is at least 20 percent of the Systems Management Server database size. If the database is less than 20 percent free, slow performance because of too much paging may occur.
SQL Server Service Pack
Apply or re-apply the latest SQL Server service pack. For information about how to do so, visit the following Microsoft Web site:
SQL Server Tracing
You can include SQL statements in the Dataldr.log by setting the following registry value to
1:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Tracing\SQL Enabled
To turn off SQL tracing, set the value to
0. You must stop and then restart the SMS SMS_Executive service for the change to take effect. When SQL tracing is turned on, you may have to increase the maximum size setting of the Dataldr.log file on the server.
NOTE: Turn off SQL tracing when you are not troubleshooting. While it is on, the Dataloader slows down, and the log fills up more quickly.
Database Maintenance
SMS 2.0 uses features not in earlier versions of SMS to maintain the SQL database. The Database Maintenance folder in the SMS Administrator's console is used to schedule periodic maintenance on the SQL server. The tasks on the
Tasks tab in the Database Maintenance folder are useful. You can use these tasks to keep the SMS database in SQL performing optimally. Schedule these tasks to run during off-hours when users or administrators are not using the SMS database. For additional information about database maintenance and related tasks, see the
SMS Administrators Guide.
DBCC Checks
Run the SQL Server database consistency checker DBCC CHECKDB and DBCC NEWALLOC statements on the SMS database in Single User mode. For more information about DBCC and the available options, see the SQL Books online. Search for "DBCC Validation Statements".
Services
Verify that the SMS SMS_Executive service is running on the site server.
Client Re-Synchronizations
Check the Microsoft Windows NT event log for a high number of client re-synchronizations (Event 186). This may occur if duplicate GUIDs are assigned.
For additional information about how to clean up duplicate computer IDs, click the article number below
to view the article in the Microsoft Knowledge Base:
254735 SMS: How to Clean Up Duplicate Computer IDs