SQL Diagnostic Manager allows you to enable either OLE automation or direct Windows Management Interface (WMI) procedures for monitoring OS metrics.
If your SQL Server instance includes enabled Lightweight Pooling, SQL Diagnostic Manager cannot collect OS metrics information.
If SQL Diagnostic Manager cannot provide OS metrics, a message displays on the Dashboard and Services Summary views providing more information.
When SQL Diagnostic Manager cannot collect OS Metrics due to the disabled collection, a bar displays a link to enable OS metric collection procedures for your SQL Server version.
CPU UsageSQL Diagnostic Manager collects metrics that track the performance of the computers that host your monitored SQL Server instances. These metrics are the following:
- Processor Queue Length
- Memory Paging
- Total Memory Usage
- SQL Server Memory Usage
- Disk Queue Length
OS Metrics tab
You can access the OS Metrics tab of the Monitor SQL Server Properties window by right-clicking the appropriate monitored SQL Server instance and selecting Properties. When SQL Diagnostic Manager displays the monitored SQL Server Properties window, click OS Metrics option from the left side tab options.
Once the right-side Properties window displays the OS Metrics configuration options, you find the following options of how the OS metrics are being collected:
- Do not collect Operating System metrics: OS metrics collection is not required in SQL Diagnostic Manager. However, if you disable this feature, SQL Diagnostic Manager ceases to collect OS metrics and does not raise any previously-associated alerts. You can easily re-enable OS metric collection at any time if you decide that you want to continue collecting these metrics.
- Collect Operating System metrics using OLE automation: Change your OS metrics collection to use OLE automation if you want OS and disk statistics, plus the auto discovery of mount points.
Advantages of using OLE automation
The advantages of using OLE automation are the following:
- You do not require any additional ports to be opened, since the standard SQL communication port is sufficient.
- SQL Diagnostic Manager uses the SQL Server service account permissions to capture WMI metrics.
- And, uses SQL Authentication.
- Collect Operating System metrics using direct WMI: Select to collect your OS Metrics using WMI.
Advantages of using direct WMI
The advantages of using WMI are the following:
- You do not require additional SQL Server configuration adjustments.
- You do not require SQL Server to gather the performance data because the collection service reaches directly to WMI.
When using direct WMI you must have RPC port 135 opened for WMI request initiation access. You must have permissions configured on each SQL instance to allow for remote access to WMI, using a Windows account. Other high-end ports opened may be required in firewall to allow WMI to communicate. The following article explains how to set a fixed port for WMI: Setting Up a Fixed Port for WMI
- Required permissions for direct WMI collection
It is preferred that the WMI user is a local administrator on the monitored SQL Server instance. However, if you do not want to grant administrator access, use the following steps to configure remote WMI access in Microsoft Windows:
- Add the user account to the Performance Log Users and distributed COM users groups.
- Grant privileges to WMI.
You also may need to add the WMI user account to the following policies:
- Act as part of the operating system
- Log on as a batch job
- Log on as a service
- Replace a process level token
For more information about using a direct WMI connection, see the Microsoft document, Securing a Remote WMI Connection.
- Configure WMI to run out-of-process
Edit your specific registry settings to allow WMI to run out-of-process. To edit these registry settings, perform the following steps:
- In the cd image of the SQL Diagnostic Manager install, open Scripts folder.
- Copy the SQLdmoutofprocoleautomation.reg file onto each of your monitored SQL Server instances.
- Run this file on each of your monitored SQL Server instances.
- Configure WMI timeouts
SQL Diagnostic Manager allows you to configure the WMI timeout value. In some environments, customers may experience WMI timeouts when their machine is too busy to respond in a timely manner. Although WMI timeouts should not be ignored and often point to an environmental issue, you can control this value when the behavior displayed is normal in your environment. The default WMI timeout value in SQL Diagnostic Manager is of 90 seconds to reduce the number of intermittent errors.
To configure the WMI timeout value:
- Navigate to the SQL Diagnostic Manager install directory
- Open SQLdmCollectionService.exe.Config
- Modify the <CollectionService> node under the <Services> node
- Add wmiQueryTimeOut="300" as a parameter to this node
- Save and close file
- Restart the collection service
Sample configuration entry:
<Services>
<CollectionService instanceName="Default" servicePort="5167"
managementServiceAddress="Server" managementServicePort="5166"
heartbeatIntervalSeconds="180" wmiQueryTimeOut="300"/>
</Services>
Issues you may encounter before SQL Diagnostic Manager begins collecting OS Metrics:
The following issues require user action before SQL Diagnostic Manager can begin collecting OS metrics:
- OLE Automation Procedures Disabled: Select the Collect Operating System data using OLE Automation option to enable OLE Automation procedures.
- OLE Automation Procedures Unavailable: The stored procedures associated with OLE Automation are missing on the SQL Server instance. SQL Diagnostic Manager cannot capture OS metrics until these stored procedures are available on the SQL Server instance.
- WMI Service Not Running: The WMI Service on the monitored SQL Server instance may not be running. SQL Diagnostic Manager cannot collect OS metrics until this service is started.
- Lightweight Pooling Enabled: This is an advanced feature used in symmetric multiprocessing environments in SQL Server. SQL Diagnostic Manager cannot collect OS metrics until this option is disabled on your monitored SQL Server instances.