CA Unified Infrastructure Management

Transcription

1 CA Unified Infrastructure Management sqlserver Guide v4.8 series

2 Copyright Notice This online help system (the "System") is for your informational purposes only and is subject to change or withdrawal by CA at any time. This System may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. This System is confidential and proprietary information of CA and protected by the copyright laws of the United States and international treaties. This System may not be disclosed by you or used for any purpose other than as may be permitted in a separate agreement between you and CA governing your use of the CA software to which the System relates (the CA Software ). Such agreement is not modified in any way by the terms of this notice. Notwithstanding the foregoing, if you are a licensed user of the CA Software you may make one copy of the System for internal use by you and your employees, provided that all CA copyright notices and legends are affixed to the reproduced copy. The right to make a copy of the System is limited to the period during which the license for the CA Software remains in full force and effect. Should the license terminate for any reason, it shall be your responsibility to certify in writing to CA that all copies and partial copies of the System have been destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS SYSTEM AS IS WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS SYSTEM, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. The manufacturer of this System is CA. Provided with Restricted Rights. Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections , , and (c)(1) - (2) and DFARS Section (b)(3), as applicable, or their successors. Copyright 2014 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies. Legal information on third-party and public domain software used in this product is documented in the Third-Party Licenses and Terms of Use (

3 Contact CA Contact CA Support For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA Technologies products. At you can access the following resources: Online and telephone contact information for technical assistance and customer services Information about user communities and forums Product and documentation downloads CA Support policies and guidelines Other helpful resources appropriate for your product Providing Feedback about Product Documentation Send comments or questions about CA Technologies product documentation to To provide feedback about general CA Technologies product documentation, complete our short customer survey which is available on the support website at

4

5 Contents Chapter 1: sqlserver sqlserver Overview... 7 Chapter 2: sqlserver Probe Deployment 11 Prerequisites Supported Platforms System Requirements Software Requirements Probe Deployment Information Chapter 3: sqlserver Configuration 13 Probe Configuration Interface Installation for sqlserver Probe Defaults Probe Configuration The Setup Tab The Profiles Tab The Templates Tab The Status Tab The Groups Tab Define New Checkpoint Thresholds for Custom Defined Checkpoints Edit Checkpoint Thresholds Schedules Checkpoints Metrics Single Counter Description Support for SQL Server Versions Chapter 4: SQL Server Monitoring (sqlserver) Metrics 65 QoS Metrics Alert Metrics Chapter 5: SQL Server Monitoring (sqlserver) Known Issues v Known SQL Server 2000 Problem Contents 5

6 Known SQL Server 2005 problem with av_fragmentation Migration Considerations V2 QoS Compatibility Mode Other QoS Issues Permissions Required Map User for Permission Chapter 6: Troubleshooting and FAQs 81 6 sqlserver Guide

7 Chapter 1: sqlserver 4.8 This description applies to sqlserver probe version 4.8x. This section contains the following topics: sqlserver Overview (see page 7) Documentation Changes (see page 8) sqlserver Overview The Nimsoft Monitor SQL Server probe constantly monitors the internal performance and space allocation throughout the SQL Server database. The probe feeds essential information that is based on predefined criteria to the Nimsoft Monitor availability manager for the appropriate alert notification when required. An extensive range of checkpoints can be selected and individually scheduled to meet the needs of specific monitoring requirements. Chapter 1: sqlserver 4.8 7

8 sqlserver Overview Documentation Changes This table describes the version history for this document. Version Date What's New? 4.8 October 2014 Updated the Known Issues topic. Added the Map User for Permission topic. 4.8 June 2014 Updated The General Tab topic. 4.8 March 2014 Updated description of the check_dbalive counter. 4.8 December 2013 Updated description of the agent_job_failure counter. 4.8 March 2013 Added logfile_usage_with_avail_disk counter. Added a note that from April 2013 onwards, Microsoft will discontinue the support for SQL Server 2000 version. 4.7 December 2012 Added fg_freespace_with_avail_disk counter in the Single Counter Description section. 4.6 September 2012 Added Threshold for Custom Defined Checkpoints section. Added Probe Defaults. Added Suppress All Alarm feature in The Set Tab section to suppress all alarms. Added the description of Delay Threshold and Delay Severity in The Profiles Tab. 4.4 June 2012 Added the following checkpoints: agent_job_failure suspect_pages ls_primary_status ls_primary_time_since_last_backup ls_secondary_status ls_secondary_time_since_last_copy ls_secondary_time_since_last_restore ls_secondary_last_restored_latency 8 sqlserver Guide

9 sqlserver Overview 4.3 March 2012 For the two checkpoints logfile_usage and logfile_size wherever the given database is in the recovery or restore mode, no metric values would be reported for given interval of execution. 4.2 August 2011 SOC Support Added. Added support for signed store procedure for standard and custom checkpoints queries. Probe can be run in standard as well as in sign mode. Added new checkpoints mirror_state, mirror_witness_server and mirror_sqlinstance for monitoring Database Mirroring state, status of witness server and status of sql server instance hosting mirroring database. Fixed an issue where sqlusr_cpu store procedure are not deleted after executing queries in case of SQL Server Modified qos_key value for user_cpu checkpoints for avoiding large amount of QoS. Fixed an issue related to subsystemid field where subsystemid shows wrong value. Fixed an issue where long_jobs checkpoint do not send any alarms. Fixed an issue where logic_fragment checkpoint gives Lock request time out error. Fixed Handle leak issue. Added support for configuring unit as minutes, hours and days in backup_status, transaction_backup_status and differential_backup_status checkpoints. Added a new error alarm message that will be send in case of checkpoint query execution failure. 4.1 April 2011 Added support for reading alarm tokens from configuration. Related Documentation Documentation for other versions of the sqlserver probe (../../sqlserver.html) The Release Notes for the sqlserver probe Monitor Metrics Reference Information for CA Unified Infrastructure Management Probes ( Documentation Changes 9

10

11 Chapter 2: sqlserver Probe Deployment This section contains the prerequisites, supported platforms, system requirements, software requirements, and probe deployment information for the sqlserver probe. This section contains the following topics: Prerequisites (see page 11) Supported Platforms (see page 11) System Requirements (see page 11) Software Requirements (see page 12) Probe Deployment Information (see page 12) Prerequisites The SQL Server driver name has been changed from SQLOLEDB to MSDASQL in version Therefore from version 4.30 onwards, you have to install the drivers from: Supported Platforms Refer to the Compatibility Support Matrix for the latest information about supported platforms. See also the Support Matrix for Probes for more specific information about the probe. System Requirements The sqlserver probe should be installed on systems with the following minimum resources: Memory: 2-4GB of RAM. Probe's OOB configuration requires 256MB of RAM' CPU: 3GHz dual-core processor, 32-bit or 64-bit Chapter 2: sqlserver Probe Deployment 11

12 Software Requirements Software Requirements The sqlserver probe requires the following software environment: Nimsoft Monitor Server or later Robot 5.23 or later Java Virtual Machine 1.6 or later (typically installed with NMS 5.0 and above) Note: For SOC functionality, NM Server 5.6 or later and UMP or later is required. Probe Deployment Information There are three ways to distribute archive packages. You can distribute the package within the web-based Admin Console (for supported probes), from within Infrastructure Manager, or use the standalone Distribution application. See Probe Deployment for more information on deploying probes. 12 sqlserver Guide

13 Chapter 3: sqlserver Configuration This section describes the configuration concepts and procedures for setting up the sqlserver probe. The sqlserver probe will run selected SQLs to extract vital information about your SQL Servers. The information is displayed as alarms and/or as a report and is useful to database administrators. The following information is extracted and monitored out of the box: Database uptime Database state/status Number of databases available The data-file size for each database Log-file size for each database File-group size for each database Table size for each database The buffer cache-hit ratio The log-file cache-hit ratio The number of active users The number of users currently logged onto the server Number of deadlocks per second Number of transactions per second Number of database page reads/writes per second Number of flush waits per second Number of latch requests per second Number of full scans (table or index) per seconds The initial configuration of the sqlserver probe is done by using the configuration tool (GUI), setting up one or more database instance profiles. The probe can run locally on the database server or it can be configured to run as a remote client. Chapter 3: sqlserver Configuration 13

14 Probe Configuration Interface Installation for sqlserver The probe is configured by double-clicking the line representing the probe in the Infrastructure Manager. This brings up the configuration tool for the probe. This section contains the following topics: Probe Configuration Interface Installation for sqlserver (see page 14) Probe Defaults (see page 14) Probe Configuration (see page 14) Define New Checkpoint (see page 32) Thresholds for Custom Defined Checkpoints (see page 43) Edit Checkpoint (see page 45) Checkpoints Metrics (see page 53) Probe Configuration Interface Installation for sqlserver The probe configuration interface is automatically downloaded and installed by the Infrastructure Manager when the probe is deployed on a robot. Probe Defaults At the time of deploying a probe for the first time on robot, some default configuration will get deployed automatically. These probe defaults could be Alarms, QoS, Profiles and so on which save time to configure the default settings. These probe defaults will be seen on a fresh install, that is no instance of that probe is already available on that robot in activated or deactivated state. User would need to create a successful connection so that default QOS and alarms are generated. Probe Configuration This section contains specific configuration for the probe. The Setup Tab The Setup tab consists of two tabs: General Message Pool 14 sqlserver Guide

15 Probe Configuration The General Tab This tab allows you to set the general runtime parameters of the sqlserver probe. The fields in the above dialog box are explained below: Suppress All Alarm Suppresses all the alarms, such as checkpoint alarms, profile alarms, SQL timeout alarms, and startup clear alarms. On selecting this check box, the Generate status only check box is selected and becomes disabled. General status only Instructs the probe to only generate status, not to issue an alarm when a threshold is breached. Select the Status tab to see the status for the different checkpoints. Clear Alarm on Restart On selecting this check box, all alarms are cleared when the probe is restarted. Alarm severity filter Sets a filter where severity levels are considered as alarms. The sqlserver probe is capable of checking many areas of the databases. Some events that are generated are vital and key to the performance and availability of the database. As a database administrator, you may want to pass the important events on to the operations center or helpdesk, so the event can trigger pagers, etc. The Alarm severity filter will consider the events matching the selected severity level and higher as alarms and pass these on whenever the Generate status only option is cleared. If you set this to be major, then only messages with severity major and upward are considered as alarms. Chapter 3: sqlserver Configuration 15

16 Probe Configuration Status Auto-Update Activates/deactivates the Status Auto-Update functionality described below: The Status Auto-Update parameter (number of seconds) specifies the automatic refresh interval of the Status Window on the Status tab. Setting this parameter to a value higher than 0 and then selecting a profile on the Status tab, the status will be automatically updated every x seconds. The checkpoints of the selected profile will set the level of details written to the log file. Log as little as possible during normal operation in order to minimize disk consumption, which is displayed before selecting another profile. Note: This parameter is a dialog value, which means it is not saved in the configuration file, but in the machine running the dialog. Log Size Sets the size of the probe s log file to which probe-internal log messages are written. The default size is 100 KB. Note: When this size is reached, the contents of the file are cleared. Log level The Message Pool Tab Sets the level of details written to the log file. Log as little as possible during normal operation, to minimize disk consumption. QoS V2 Compatibility Inserts QoS data of sqlserver version 2.x in the database. Note: This field is valid when you are upgrading the probe from version 2.x to a higher version. Refer to the V2 QoS Compatibility Mode topic for more information. This tab contains a list of all alarm messages available. You select messages from this list when editing the properties for a checkpoint. Right-clicking on the list allows you to add, edit, copy or delete messages. 16 sqlserver Guide

17 Probe Configuration Define Message Using the Message pool tab, you can define a message. Follow these steps: 1. Select the Message pool tab, right-click in the list and select New. 2. Enter a name in the New message dialog, which pops up. Note: Use the name of the checkpoint for which you create the alarm message as name. That makes it easier for you to find the alarm message when selecting an alarm message in the properties dialog for the checkpoint. 3. Select the checkpoint for which you create the alarm message in the drop-down list and all variables available for that checkpoint will be listed in the right part of the dialog. Chapter 3: sqlserver Configuration 17

18 Probe Configuration 4. Enter the message and select the variables you need. 5. Click OK when finished. The new message appears in the message pool. The Connections Tab This list contains the various connections to instances that the sqlserver probe will monitor. You need to specify user name, password, and service name you want to use to connect to the instance. The password information is encrypted and placed into the configuration file. A connection can be used by more than one profile. The list contains one predefined connection that you may modify to your preferences. You can add, edit, delete, and copy connections. 18 sqlserver Guide

19 Probe Configuration Select the connection and choose Edit from the right pop-up menu, the connection property window is displayed for editing. The fields in the above dialog box are explained below: Description Short description of the connection. Authentication Provides the options through which the probe connects to the database server. Valid options are: Encryption User ID SQL Server authentication Windows authentication Encrypts the communication between database and the server. Provides user name for the SQL server in case SQL Server authentication is selected. Provides user name for the domain in case Windows authentication is selected. Password Provides password for the SQL server in case SQL Server authentication is selected. Provides password for the domain in case Windows authentication is selected. Server name The name of the server. Chapter 3: sqlserver Configuration 19

20 Probe Configuration Retry attempts Number of attempts the probe should try to repeat connection in case of failure. "0" means only the initial connection will be done. Retry delay Timeout The time the probe will wait between two connection attempts. Defines how long the probe will wait for answer before it aborts the connection process. Test button Clicking this button will test if the connection can be made. If success, it will return the instance name and its version number. If not, an error message will be returned. Note: In order to automatically append the domain name to the user credentials, select Windows Authentication option from the Authentication drop-down menu and then enable the Detect domain automatically check box. 20 sqlserver Guide

21 Probe Configuration This will auto-append the domain name to the User ID text field. In the Server name field, it is optional to add the sql port number. Chapter 3: sqlserver Configuration 21

22 Probe Configuration The Profiles Tab The list contains a sample profile that you can modify as per your requirements. Every profile will run as a separate thread, and multiple profiles can be used to monitor one instance. This way the probe can be configured to deploy available resources the best way and allows independent monitoring of several instances simultaneously. Icons in the profile list Green icon in the profile line means the profile is active and running. Yellow icon means the profile is active but suspended (the suspend / resume button in the profile properties dialog allows stopping / starting profile monitoring dynamic, without deactivating /activating the probe). Black icon displays that the profile is inactive. You can add, edit, delete and copy profiles. The suspend /resume commands allows stopping/starting profile monitoring dynamic, without deactivating /activating the probe. 22 sqlserver Guide

23 Probe Configuration Select the profile and click Edit from the right pop-up menu displays the profile property window for editing. The upper part of the window displays the general profile properties and defaults. At the bottom, you will find a list of available checkpoints. The fields in the above dialog box are explained below: Description Description of the profile. Heartbeat Defines the interval at which all profile checkpoints schedules will be tested and trigger eventual checkpoint execution. This number should be common denominator to all used check interval values. The higher the value the lower is the profile overhead. Connection Connection used in this profile. It has to be defined in Connections dialog before creating a profile. Chapter 3: sqlserver Configuration 23

24 Probe Configuration Check interval Default value for check interval in the profile. Will be used if nothing else is defined in the checkpoint and overwrites the default checkpoint list setting. Clear message Message name for timeout clear alarm. SQL timeout Every checkpoint query runs asynchronously. In case the query reaches the SQL timeout, the checkpoint processing will be terminated and the next checkpoint will be started. An alarm is issued. Message Message name used for profile timeout alarm. Profile timeout Defines the maximum processing time for all checkpoints in the profile. If this timeout is reached, the interval processing is finished and the probe waits for next heartbeat to evaluate any checkpoint schedules. Alarm message is issued. Message Message name used for SQL timeout alarm. Delay Threshold Timeout threshold for the profile delay alarm. Delay Severity Severity of the alarm that should be raised if the profile is delayed by the threshold. Timeout severity Severity for timeout messages. Use FQDN As QoS Source (as can be seen in above snapshot) You can select this check box to allow the QoS source to be FQDN instead of a simple host name. Suspended/Resumed (indicator) This indicator is green when the profile is activated. The indicator changes to yellow when the profile is suspended and to black when deactivated. Alarm Source This option lets you override the source name of the alarm. 24 sqlserver Guide

25 Probe Configuration Profile checkpoints At the bottom, you will find a list of available checkpoints. When defining a new profile, all checkpoints available (listed under the Checkpoints tab) will be listed here. Select the checkpoints you want for your new profile. The global and default checkpoint settings will be used, unless you modify the settings locally for your profile. Alarm Source Possibility to change the source for issued alarms. If not used, default is assumed (robot IP). Checkpoint types While defining a profile, you can use two different strategies how to handle checkpoints in a profile. You can decide to use checkpoint templates dynamic, which means that the checkpoints are defined globally (under the Templates tab) and represent the default settings. Every time you change the template value, it will reflect on all profiles using dynamic templates strategy. Note: If you want to have specific settings valid just for one profile, right-click the checkpoint in the list and select Change to static. Chapter 3: sqlserver Configuration 25

26 Probe Configuration You can now double-click the checkpoint to modify the properties and the settings will be valid for this profile only. A warning will appear If you attempt to modify a template checkpoint in the Profile dialog without changing it to static: Of course, there can be both "template" and "static" checkpoints mixed in one profile. If a checkpoint is managed as static, the checkpoint name will appear in the list with a blue color, and it will be marked as static in the column Type. Static To manage the properties for a checkpoint locally, "change" the checkpoint to static in your profile before modifying it. When modified, the new settings will be valid for this profile only. Template To edit the properties for a checkpoint template, double-click the checkpoint in the profile list or Templates tab. When modified, the new settings will be valid for all profiles, unless overruled by static settings in the profile. When deciding which checkpoints to activate/deactivate for a profile, see the section Single Counter Description (see page 53) for a description of the different checkpoints. 26 sqlserver Guide

27 Probe Configuration The Templates Tab The list contains the predefined set of checkpoints that you may use in your profiles. These checkpoints can be modified as per your preferences. By default, most checkpoints are active with a reasonable default threshold value. The checkpoint properties may be used in a profile either dynamic, using the template values, or they can be added to the profile and managed static in the profile. Static To edit the properties for a checkpoint locally for a profile, right-click the profile in the Checkpoints list in the Profile dialog and change it to static. Then double-click the checkpoint to modify it. When modified, the new settings will be valid for this profile only. Template To edit the properties for a checkpoint template, double-click the checkpoint in the profile list or Templates tab. When modified, the new settings will be valid for all profiles, unless overruled by static settings in the profile. See the section Single Counter Description (see page 53) for a description of the checkpoint properties. Chapter 3: sqlserver Configuration 27

28 Probe Configuration The Status Tab The status is presented in a hierarchal fashion with profile name nodes and one or more checkpoint nodes (only active checkpoints are considered here). Execution time is the time taken by the checkpoint to fetch the data from the database in the last interval since the probe started. Max.Execution time is the maximum time taken by the checkpoint in any scheduled interval to fetch the data from the database since the probe started. The highest status is propagated. Select the checkpoint in the navigation tree (to your left) to bring up the corresponding events. 28 sqlserver Guide

29 Probe Configuration Change Individual Values for Checkpoints The properties for an individual checkpoint object can also be modified here. Follow these steps: 1. Select a profile and a monitored checkpoint in the left pane. 2. Double-click an object in the right pane. If the object belongs to a template object, a warning appears that a modification will make the checkpoint static for the selected profile. See the section Edit Checkpoint (see page 45) for a description of the checkpoint properties. The Groups Tab This tab lets you create multiple groups, which can be associated with profiles. Chapter 3: sqlserver Configuration 29

30 Probe Configuration Add a Group You can add a group using the Groups tab. Follow these steps: 1. Right-click the Group tab and select New option. The Add New Group dialog appears. 2. Enter a name for the group and click OK. New Group dialog appears. 3. Enter a description for the new group in the Description text box. 4. From the Group Checkpoints section, select the check boxes for the checkpoints that you wish to enable for the new group. 5. Click the OK button. The new group gets added to the list. 30 sqlserver Guide

31 Probe Configuration The new group can now be selected from the Group drop-down in the Edit Profiles dialog. As per the group selected, the profile will now display the checkpoint configurations. Note: As per your requirements, you can also edit, delete, and copy a group. Chapter 3: sqlserver Configuration 31

32 Define New Checkpoint Define New Checkpoint You can define a new checkpoint in the Templates tab. Follow these steps: 1. Select the Templates tab, right-click in the checkpoint list and select Create new. The Add New User Template dialog appears. Note: The difference to regular edit checkpoint dialog is the additional Query tab. SQL query is the data source and therefore the central piece for every checkpoint. It is recommended to test the query first with SQL Server Management Studio (or other tool) before you start to create new checkpoint. 32 sqlserver Guide

33 Define New Checkpoint 2. Enter the name of the new checkpoint. The Edit template checkpoint dialog appears. 3. By default, the General tab opens. Click the Query tab. The query has to return at least one numeric column, which will be used as checked value (all numeric formats are supported). If the query returns more than one row, the probe needs unique identification per row which will be used as part of suppression key and QoS definition. The row key can be created by concatenating several columns in the checkpoint definition. Additional columns can be retrieved to be used in generated messages. Note: Use rtrim and ltrim functions to remove leading and trailing blanks from string variables. Use explicit column names for manipulated values, avoid generated names, such as Col0 and Col1. Queries are stored in separate files, not in the configuration file itself. If you want to create new checkpoint, you either click the button New/Edit, copy & paste the query in the query field and entry the query file name where you want the query to be stored. The query file name can contain full path, otherwise the file will be stored in the probe work directory. Chapter 3: sqlserver Configuration 33

34 Define New Checkpoint Note: In version 4.30 and onwards, multiline custom query must include "SET NOCOUNT ON" as the initial line. For example: SET NOCOUNT ON nvarchar(128) nvarchar(128) = CAST(serverproperty('ProductVersion') AS nvarchar) = SUBSTRING(@ver, 1, - 1) IF = '9' = '10' ) SELECT count (*) suspect_page_count FROM msdb.dbo.suspect_pages (nolock) WHERE (event_type = 1 OR event_type = 2 OR event_type = 3) else select 0 as suspect_page_count 4. If you want to create new checkpoint, perform one of the following: Create a connection using Edit/New button, copy & paste the query in the query field and enter the query file name where you want the query to be stored. The query file name can contain full path, otherwise the file will be stored in the probe work directory. Create the file first, use the button Read and then Create a connection using Edit/New button for change/test of the query. 34 sqlserver Guide

35 Define New Checkpoint 5. The New/Edit button needs to be hit to be able to test the query. For data security reason the probe will force you to entry user-id and password every time you click New/Edit. Note 1: The connection information (i.e. User ID, Password, and Server name) defined in this form must be same as defined in the SQL Server profile. Note 2: If there are multiple profiles using different connections then the custom checkpoints must be converted to static and in each static checkpoint the connection should match to the connection used in the SQL Server profile. Chapter 3: sqlserver Configuration 35

36 Define New Checkpoint 6. Click Test to validate the connection settings. You can either test the query using a new connection or after editing an existing connection you can click the Test button to test the query. Note: The connection information (i.e. User ID, Password, and Server name) defined in this form must be same as defined in the SQL Server profile. You have to run a successful test every time you want to make any change to the query itself. The query test is also necessary for the probe to have all information about retrieved columns to be able to define all checkpoints variables. 36 sqlserver Guide

37 Define New Checkpoint 7. Click the Edit button in the Message variables line to define checkpoints variables by. A new window opens with a list of all available columns and their possible usage. You have to define their use and format. Numeric columns can be used as: Value candidate for checkpoint checking with standard formatting Value size candidate for checking, formatted as file size (B, KB, MB, GB or TB) Value int candidate for checking, formatted as integer number Information no checking, standard formatting (if available 2 digits after comma) Character columns: Row key candidate for row identification, string formatting. Information string formatting. Chapter 3: sqlserver Configuration 37

38 Define New Checkpoint 38 sqlserver Guide

39 Define New Checkpoint 8. If your query returns more than one line, you need to define unique row key. To see which variables you can use you need to type the sign "$" into the Row identification line and a sub-list with all suitable variables will appear. Chapter 3: sqlserver Configuration 39

40 Define New Checkpoint 9. When the Interval modus check box is selected then the column metric type is assumed to be count instead of gauge. 10. Set the Interval modus check box. If you select Interval modus, the probe will always subtract the variable value at the beginning of an interval from the value at the end of the interval and use the result for checking alarms. If you select Interval modus, it will cause a variable $column_interval_value.i to be added to the list of message variables for each column(threshold object) for which threshold will be defined. This list can be viewed in the Edit Threshold dialog box. If you do not select the Interval modus check box, the value of variable as it returned from the query will be used for checking and QoS. 40 sqlserver Guide

41 Define New Checkpoint 11. When the Report Per Second Metric is selected, then the column metric type is assumed to be count/sec. Also, it will only allow count to be used as the threshold object which means your query should have a column name as count whose metric type will be Count/sec. 12. Define the rest of the checkpoint processing settings in the General tab, which are as follows: Interval value Sampling Scheduling Thresholds Messages QoS definitions 13. Create a hint text in the Hint Editor tab, but it is not mandatory. Chapter 3: sqlserver Configuration 41

42 Define New Checkpoint 14. Save the definition and restart the probe to start using this new checkpoint. Note: Stored procedures can be used in custom checkpoints. 42 sqlserver Guide

43 Thresholds for Custom Defined Checkpoints Thresholds for Custom Defined Checkpoints Every checkpoint needs to have at least one threshold but you can also define additional thresholds. The threshold values may be defined by modifying checkpoints in the respective profile. You can also define several schedules per checkpoint and use the Scheduling functionality. Alarms for a checkpoint can be configured in two ways: Key alarms: These are the key specific alarms for any data column that are generated if the alarm condition matches the specified key value. Default alarms: These are the default alarms for any data column that are generated based on the following two conditions: When no key specific alarm is configured for the specified data column. When there is a key specific alarm configured for that data column but it does not match the alarm condition. The threshold identification consists of an object name, such as tablespace name, userid, and a threshold ID, which is numbered from 0. Alarms on threshold value come with respect to first alarm being of top priority. Chapter 3: sqlserver Configuration 43

44 Thresholds for Custom Defined Checkpoints The fields in the above dialog are explained below: Threshold object name Defines the monitoring object name. Condition Specifies the comparison operator used for threshold evaluation. Threshold value Defines the value used for threshold evaluation. Severity Specifies the alarm severity. 44 sqlserver Guide

45 Edit Checkpoint Message Defines the name of message used for threshold alarm. Message text Provides the text of the message, containing variables, which will be replaced in run time. If the message text is changed from a profile list, you will be forced to create new message. Clear Message Specifies the clear message to be sent. Variables Provides the list of variables available in the checkpoint. Key Column Name Specifies the column name for which you can generate a key specific alarm. Key Column Value Defines the key value on which an alarm condition would be compared for the specified column name. If the condition matches, the alarm will be generated. Scheduling Lets you select how to use the Schedules settings, if any. Note: This alarm schedule should be a subset of the schedule(s) used in the checkpoint. rules Selecting rules means to run as per the rules described in the Schedules settings. exceptions Schedules Selecting exceptions means to run except the rules described in the Schedules settings. For more information, see Schedules (see page 52). Edit Checkpoint The checkpoint properties may be used in a profile either dynamic, using the template values, or they can be added to the profile and managed static in the profile. Chapter 3: sqlserver Configuration 45

46 Edit Checkpoint Static For editing the properties of a checkpoint locally for a profile, right-click the profile in the Checkpoints list in the Profile dialog and change it to static. Then double-click the checkpoint to modify it. When modified, the new settings will be valid for this profile only. Template To edit the properties for a checkpoint template, double-click the checkpoint in the profile list or Templates tab. When modified, the new settings will be valid for all profiles, unless overruled by static settings in the profile. The properties for checkpoints are described below: The upper part of the window contains general checkpoint settings. The lower part contains two lists with threshold and schedule settings. 46 sqlserver Guide

47 Edit Checkpoint The fields in the above dialog box are explained below: Description Active Description of the purpose of the checkpoint. Activates the checkpoint. Condition Information, describing how the threshold values are evaluated. Send Quality of Service Activates QoS values being send into the QoS database. If not available in a checkpoint, check box is disabled. QoS List Clicking this button opens the QoS list, showing the current QoS definitions (default is one definition per checkpoint). Right-clicking in the list lets you add new QoS definitions and copy, edit or delete an existing QoS definition. The Edit QoS dialog offers available metrics (numerical variables which could be reported as QoS) and available object variables (if any - to be added to the QoS source). The name of the QoS has to start with the checkpoint name. QoS can be activated/deactivated as usual. Note: Some of the checkpoints have no QoS possibilities from these checkpoints the QoS dialog cannot be activated. Samples The probe will save the number of samples specified here and calculate an average value. This average value will be compared to the alarm threshold specified (see threshold description below the table). Setting "Samples = 1", no sampling is done. Setting "Samples = 3", the average of the 3 last samples will be used. Setting "Samples = 0" (in profile), number of samples will be taken from the template. If not set there, no sampling is done. Initially after start-up, the probe calculates the average value from the number of samples available. Example, Samples=3: In the first interval the first sample value is used In the second interval, the average of sample 1 and 2 will be used etc. Chapter 3: sqlserver Configuration 47

48 Edit Checkpoint Note: Many checkpoints calculate an "interval value", therefore in the first interval there is no value at all (no threshold checking). Use excludes Adds excludes to the "exclude list" to some of the checkpoints (as it does not make sense for all checkpoints). Using excludes, you can define objects that you do NOT want to monitor on the checkpoint. The exclude patterns found if clicking the Excludes list button, is used for the checkpoint. Excludes list Opens the Excludes list. This list shows if excludes are defined for the checkpoint. The exclude found in the list will be used for the checkpoint if the Use excludes option is selected. Right-clicking in the list allows you add the new excludes or edit, copy, or delete existing excludes. When adding (or editing) an exclude pattern, a match expression dialog is opened, letting you edit or define the exclude pattern. Excludes are defined using regular expression patterns. The Test button lets you test the exclude pattern defined. This test is possible only for running active profiles and checkpoints. The test uses the status list (on the status tab) as input: Note that if there already are active excludes, the excluded objects are excluded from the status list BEFORE the test. When clicking the test button, an exclude test list pops up, showing the result of the test: Red text lines show the objects which would be excluded using the tested pattern. The "object thresholds" are functioning as an "include list" - it means, if there are special thresholds defined for a special object, this object will always stay in, even if the exclude pattern would eliminate it normally. This is considered also in the test function. Scheduling Selects how to use the Schedules settings. Clear message Rules: Selecting Rules means to run according the rules described in the Schedules settings. Exceptions: Selecting Exceptions means to run except the rules described in the Schedules settings. Message name used for clear alarm message. 48 sqlserver Guide

49 Edit Checkpoint Clear severity Severity, used for message issued in normal state. Thresholds/Schedules For more information, see Thresholds (see page 49) and Schedules (see page 52). Thresholds The list contains the predefined set of monitoring profiles that you can use in your profiles as well as can modify them as per your preferences. By default, most profiles are active with a reasonable default threshold value. The threshold values can be defined by modifying checkpoints in the respective profile. Every checkpoint has to have at least one threshold, but there can be additional thresholds defined. Chapter 3: sqlserver Configuration 49

50 Edit Checkpoint The threshold identification consists of an object name (if applicable), such as tablespace name, userid, and threshold ID, which is numbered from 0. Threshold values should be descending or ascending, depending on the condition used in a checkpoint, starting with the highest severity threshold condition. The fields in the above dialog box are explained below: Threshold object name Monitoring object name, if applicable or default. Some special checkpoints have a second threshold called count" (e.g. "locked_users"). Threshold value Value used for threshold evaluation. Current value If invoked from the status report, it contains the last measured value. 50 sqlserver Guide

51 Edit Checkpoint Severity Alarm Severity. Message Name of message used for threshold alarm. Message text Text of the message, containing variables, which will be replaced in run time. If the message text is changed from a profile list, you will be forced to create new message. Variables List of variables, which are available in the checkpoint. Scheduling Lets you select how to use the Schedules settings, if any. rules Selecting rules means to run as per the rules described in the Schedules settings. exceptions Schedules Selecting exceptions means to run except the rules described in the Schedules settings. For more information, see Schedules (see page 52). Chapter 3: sqlserver Configuration 51

52 Edit Checkpoint Schedules If the schedules list is empty, the checkpoint will be executed on an interval basis, 24 hours a day. You can define a number of schedules for checkpoints, which can define additional rules to the check interval or exceptions of it. Rules and exceptions cannot be mixed in one checkpoint. In principle, a schedule is a definition of an execution period (or execution break if exceptions used) with specified days, time from/to and date from/to values. Additionally, if only Date from and time from are defined, first execution can be defined. Run once will cause the checkpoint run only once a day in the defined period (unlike multiple times if Run interval used). 52 sqlserver Guide

53 Checkpoints Metrics Checkpoints Metrics The following types of metrics are used: Count Refers to absolute number of events in the interval. In the first interval, counts are not checked because their interval value cannot be calculated. If there is a "total" value in the message, it means "since the start of the server". Count/sec Refers to absolute number of events in the interval per second. It is calculated as delta between count at the beginning of the interval and at the end, divided by length of the interval in seconds. In the first interval, counts are not checked because their interval value cannot be calculated. If there is a "total" value in the message, it means "since the start of the server". Gauge Refers to absolute number, describing the actual state of the system. If it describes size, it will be in KB or MB, depending on actual size. Ratio Refers to calculated percentage, using interval counts. In the first interval, it is calculated from total counts (as the interval count cannot be calculated). Status Refers to absolute value like ONLINE etc. Average Refers to calculated using interval counts. In the starting interval it is calculated from absolute counts. Note: Suspect_pages, ls_primary_status, ls_secondary_status, ls_primary_time_since_last_backup, ls_secondary_time_since_last_copy, ls_secondary_time_since_last_restore, and ls_secondary_last_restored_latency checkpoints are not supported on SQL Server Single Counter Description agent_job_failure Count Monitors failed agent jobs in a defined interval of time. Note: This monitor does not generate a clear alarm, by default. You can change value of the clear_alarms key to 1, using the Raw Configure option, for generating the clear alarm. check_dbalive status This checkpoint tries to connect to a server. In case the connection cannot be established, an alert is generated. This checkpoint cannot be deactivated. This checkpoint returns two values with which threshold comparison is done: 1. Sql Server instance Connection Failure: 0 2. Sql Server instance Connection Success: 1 In case of Alert, check the server connectivity or if the server itself is running. Chapter 3: sqlserver Configuration 53

54 Checkpoints Metrics server_startup gauge This checkpoint monitors number of days the database server is up and running. database_count gauge This checkpoint monitors the change of the number of databases on the server. If the number increases or decreases, an alert is generated. backup_status status This checkpoint monitors number of minutes, since last database backup has been taken. For all databases that have never been backed up, this checkpoint returns -1 value. On double-clicking this checkpoint in the Templates tab, Edit template checkpoint screen appears. 54 sqlserver Guide

55 Checkpoints Metrics The fields in the above dialog box are explained below: Ignore Database Snapshots Allows you to ignore the database snapshots from monitoring that are read-only copy of some database. Ignore Database in Restoring State Allows you to ignore the databases from monitoring that are in restoring state. Ignore Database Created in Last Days Allows you to ignore the databases created in the mentioned days. For example If you mention 3 in the text box, then the databases are ignored from monitoring that were created in last 3 days. buf_cachehit_ratio ratio This checkpoint monitors the percentage of pages found in the buffer cache without having to read from the disk. The ratio is the interval number of cache hits divided by the interval number of cache look-ups. Because reading from the cache is much less expensive than reading from disk, you want this ratio to be high. Generally, you can increase the buffer cache hit ratio by increasing the amount of memory available to the SQL Server. logfile_usage_with_avail_disk percent Monitors free space in the database log files after considering the available disk size. long_jobs count This checkpoint will find all jobs running longer than defined threshold in seconds. long_queries count This checkpoint will find all queries running longer than defined threshold in seconds. log_cachehit_ratio ratio This checkpoint monitors the percentage of pages found in the log cache without having to read from disk. The ratio is the interval number of cache hits divided by the interval number of cache look-ups. Because reading from the cache is much less expensive than reading from disk, you want this ratio to be high. Generally, you can increase the log cache hit ratio by increasing the amount of memory available to the SQL Server. ls_primary_status status This checkpoint monitors collective status of agents for the primary log shipping database(1 = healthy and no-agent failures, 0 = otherwise). This checkpoint has to be run from primary server or monitor server. Chapter 3: sqlserver Configuration 55

56 Checkpoints Metrics ls_primary_time_since_last_backup status This checkpoint monitors the length of time(in minutes), since the last log backup. NULL = The information is not available or is not relevant. This checkpoint has to be run from primary server or monitor server. ls_secondary_last_restored_latency status This checkpoint monitors duration of time(in minutes) from the creation of the last backup to restore of the backup. NULL = The information is not available or is not relevant. This checkpoint has to be run from secondary server or monitor server. ls_secondary_status status This checkpoint monitors collective status of agents for the secondary log shipping database(1 = healthy and no-agent failures, 0 = otherwise). This checkpoint has to be run from secondary server or monitor server. ls_secondary_time_since_last_copy status This checkpoint monitors the length of time(in minutes), since the last log backup was copied. NULL = The information is not available or is not relevant. This checkpoint has to be run from secondary server or monitor server. ls_secondary_time_since_last_restore status This checkpoint monitors the length of time(in minutes), since the last log backup was restored. NULL = The information is not available or is not relevant. This checkpoint has to be run from secondary server or monitor server. active_users gauge This checkpoint monitors the number of users having an active transaction at the moment of snapshot. login_count gauge This checkpoint monitors the number of users having an open connection to the server at the moment of snapshot. deadlocks count/sec This checkpoint monitors the number of deadlocks per second in an interval. As deadlocks can cause severe performance penalty, their number should be close to 0. Use trace 1204 or 1205 to identify the deadlocked resources and involved applications, also sp_lock procedure delivers useful information about locking. lock_timeouts count/sec This checkpoint monitors number of lock-timeouts per second in interval with precision of 0.001sec. lock_requests count/sec This checkpoint monitors number of lock requests per second in interval. 56 sqlserver Guide

57 Checkpoints Metrics lock_waits count/sec This checkpoint monitors number of locks waits per second in interval. transactions count/sec This checkpoint monitors number of transactions per second in interval. page_reads count/sec This checkpoint monitors the number of physical database page-reads that are issued per second in an interval. Since physical I/O is expensive, you may be able to minimize the cost, either by using a larger data cache, intelligent indexes, more efficient queries, or by changing the database design. page_writes count/sec This checkpoint monitors the number of databases page-writes that are issued per second in an interval. Page-writes are generally expensive. Reducing page-write activity is important for optimal tuning. One way to do this is to ensure that you do not run out of free buffers in the free buffer pool. If you do, page-writes occurs while waiting for an unused cache buffer to flush. log_flush_waits count/sec This checkpoint monitors the number of commits per second waiting on the log flush in interval. When commits are waiting for log flushes, the log device is usually the bottleneck. latch_waits count/sec This checkpoint monitors the number of latch requests in interval that could not be granted immediately and had to wait before being granted. If this number is high the system is generally experiencing a low cache hit ratio and is being forced to perform physical I/Os. Add more memory or increase bandwidth of your system. full_scans count/sec This checkpoint monitors the number of full table or index scans per second in interval. If this value is high (2-10) then you need to analyze your queries. log_file_growths count This checkpoint monitors the number of times in an interval the transaction log for the database has been expanded. If this happens more often you should consider resizing your log files. log_file_shrinks count This checkpoint monitors the number of times in an interval the transaction log for the database has been decreased. If this happens more often you should consider resizing your log files. Chapter 3: sqlserver Configuration 57

58 Checkpoints Metrics scan_density ratio This checkpoint monitors the ratio between the best number of extents to the actual number of extents. It should be near 100%, lower number indicates external fragmentation - the object should be reorganized. suspect_pages gauge Monitors suspect pages logged for databases. logic_fragment ratio This checkpoint monitors the number of cluster index pages that are out of order. Any number higher than 10% indicates external fragmentation. The index should be rebuilt. Note: Non-cluster indexes are not monitored because a table can have only one clustering sequence! database_size gauge This checkpoint monitors the space used by the respective database files, data and log files together (in KB/MB). An alert will be issued whenever a particular size is exceeded. Note: This checkpoint should be used as information additional to the checkpoints "free_space" and "logfile_usage". database_status status This checkpoint monitors the database status value. The status value is actually a combination of some configuration options and a status, therefore there can be multiple values set at the same time (like "torn page detection" and "loading"). free_space ratio This checkpoint monitors the amount of free space in database data files in percent. If there is at least one file with "unlimited" growth, the space in the whole database is considered as 100% free. If you are using file groups, this could be misleading; therefore you should deactivate this checkpoint and use only the "fg_free_space" checkpoint. fg_free_space ratio This checkpoint monitors the amount of free space in database file groups in percent. If there is at least one file with "unlimited" growth in a file group, the space in this file group is considered as 100% free. fg_freespace_with_avail_disk ratio This checkpoint monitors the amount of free disk space in database file groups in % free space for file groups (with auto growth enabled) is calculated after considering the available disk size on which the file group is located. 58 sqlserver Guide

59 Checkpoints Metrics logfile_usage ratio This checkpoint monitors the amount of free space in transaction log in percent. If there is at least one transaction log file with "unlimited" growth in a database, the space in its transaction log is considered as 100% free. Note: For this checkpoint wherever the given database is in the recovery or restore mode, no metric values would be reported for given interval of execution. logfile_size gauge This checkpoint monitors the size of transaction log in MB. If there is at least one transaction log file with "unlimited" growth in a database. Note: For this checkpoint wherever the given database is in the recovery or restore mode, no metric values would be reported for given interval of execution. table_space gauge This checkpoint monitors amount of space (in KB/MB) reserved for a particular table in a database. This checkpoint can be used to control the size of fast growing tables. lock_memory gauge This checkpoint monitors amount of allocated lock memory in Kb. locks_used ratio This checkpoint monitors % of used lock and lock owner blocks used. connection_memory gauge This checkpoint monitors amount of memory in Kb used to maintain connections to SQL Server. optimizer_memory gauge This checkpoint monitors amount of memory in Kb used for SQL optimizer. sqlcache_memory gauge This checkpoint monitors amount of memory in Kb used for SQL statement cache. workspace_memory gauge This checkpoint monitors amount of memory in Kb used for executing processes such as hash, sort, bulk copy, and index creation operations. average_waittime average This checkpoint monitors average lock wait time in ms in interval. High wait time will cause performance degradation, consider increase number of locks available or enlarge available computer memory. total_memory gauge This checkpoint monitors total amount of dynamic memory (in kilobytes) the server is using currently. Chapter 3: sqlserver Configuration 59

60 Checkpoints Metrics server_cpu ratio This checkpoint monitors % of CPU usage by SQL Server instance in interval. server_io ratio This checkpoint monitors % of I/O busy for SQL Server instance in interval. free_connections ratio This checkpoint monitors % free connections to SQL Server instance, specified by parameter 'user connections' (max ). user_cpu ratio This checkpoint monitors % of CPU usage by user in interval. Note: The checkpoint user_cpu reports $spid.$hostid in the QoS target. This will result in the creation of new data series for each new $spid or $hostid. Hence, it is recommended that you disable the QoS for this checkpoint. user_waits Monitors time in seconds, session spends waiting for a lock and length of blocking. Note: You can add schedules in the Exclude and Include lists. The match expression, which is added will be executed in the given time period mentioned in the schedule. locked_users count This checkpoint monitors the number of users suspended by locks at the moment of snapshot. Also, the blocked user and its current SQL are displayed. Transaction_backup_status status This checkpoint will send QoS and Alarms for those databases that are running in full or bulk-logged recovery mode. Note: This checkpoint will not send QoS and Alarms for those databases that are running in simple recovery mode. Support for SQL Server Versions The following table describes the checkpoint metrics, which are supported on SQL Server 2005/SQL Server 2008/SQL Server 2012 and SQL Server 2000: Checkpoint Metric SQL Server 2005/SQL Server 2008/SQL Server 2012 SQL Server 2000 active_connection_rat io Yes Yes active_users Yes Yes agent_job_failure Yes Yes alloc_space Yes Yes 60 sqlserver Guide

61 Checkpoints Metrics Checkpoint Metric SQL Server 2005/SQL Server 2008/SQL Server 2012 SQL Server 2000 av_fragmentation Yes No average_waittime Yes Yes backup_status Yes Yes blocked_users Yes Yes buf_cachehit_ratio Yes Yes check_dbalive Yes Yes connection_memory Yes Yes database_count Yes Yes database_size Yes Yes database_state Yes Yes deadlocks Yes Yes differential_backup_st atus Yes Yes fg_free_space Yes Yes free_connections Yes Yes free_space Yes Yes full_scans Yes Yes latch_waits Yes Yes lock_memory Yes Yes lock_requests Yes Yes lock_timeouts Yes Yes lock_waits Yes Yes locked_users Yes Yes locks_used Yes Yes log_cachehit_ratio Yes Yes log_file_growths Yes Yes log_file_shrinks Yes Yes log_flush_waits Yes Yes logfile_size Yes Yes Chapter 3: sqlserver Configuration 61

62 Checkpoints Metrics Checkpoint Metric SQL Server 2005/SQL Server 2008/SQL Server 2012 SQL Server 2000 logfile_usage Yes Yes logic_fragment No Yes login_count Yes Yes long_jobs Yes No long_queries Yes No mirror_sqlinstance Yes No mirror_state Yes No mirror_witness_server Yes optimizer_memory Yes Yes page_reads Yes Yes page_writes Yes Yes scan_density No Yes server_cpu Yes Yes server_io Yes Yes server_startup Yes Yes No suspect_pages Yes No sqlcache_memory Yes Yes table_space Y es total_memory Yes Yes transaction_backup_s tatus Yes Yes transactions Yes Yes user_cpu Yes Yes user_waits Yes Yes workspace_memory Yes Yes ls_primary_status Yes No ls_time_since_last_ba ckup Yes ls_secondary_status Yes No No Yes 62 sqlserver Guide

63 Checkpoints Metrics Checkpoint Metric ls_time_since_last_co py ls_time_since_last_res tore ls_last_restored_laten cy fg_freespace_with_av ail_disk logfile_usage_with_av ail_disk SQL Server 2005/SQL Server 2008/SQL Server 2012 Yes Yes Yes Yes Yes SQL Server 2000 No No No No Yes Note: From April 2013 onwards, Microsoft will discontinue the support for SQL Server 2000 version. Therefore from SQL Server 4.8 version, the new enhancements done in the SQL Server probe, will not be supported in SQL Server 2000 version. Chapter 3: sqlserver Configuration 63

64

65 Chapter 4: SQL Server Monitoring (sqlserver) Metrics Many probes ship with default QoS threshold values set. The default threshold values provide an idea of the type of values to be entered in the fields and are not necessarily recommended best practice values. To aid in tuning thresholds and reducing false-positive alarms, this section describes the QoS metrics and provides the default QoS thresholds. This section contains the following topics: QoS Metrics (see page 65) Alert Metrics (see page 68) QoS Metrics The following table describes the checkpoint metrics that can be configured using the probe. Monitor Name Units Description Version QOS_SQLSERVER_active_connec tion_ratio Percent Active Connection Ratio v4.4 QOS_SQLSERVER_active_users Count Active Users v4.4 QOS_SQLSERVER_alloc_space Percent Free Allocated Space v4.4 QOS_SQLSERVER_av_fragmentat ion QOS_SQLSERVER_average_waitti me Percent Average Fragmentation v4.4 ms Average Lock Wait Time v4.4 QOS_SQLSERVER_backup_status Minutes Minutes Since Last Backup v4.4 QOS_SQLSERVER_blocked_users Count Blocked Users v4.4 QOS_SQLSERVER_buf_cachehit_ ratio Percent Buffer Cachehit Ratio v4.4 QOS_SQLSERVER_check_dbalive State Availability v4.4 QOS_SQLSERVER_connection_m emory Kb Connection Memory Allocated v4.4 Chapter 4: SQL Server Monitoring (sqlserver) Metrics 65

66 QoS Metrics Monitor Name Units Description Version QOS_SQLSERVER_database_cou nt Count Database Count v4.4 QOS_SQLSERVER_database_size Megabytes Database Size v4.4 QOS_SQLSERVER_database_stat e State Database State v4.4 QOS_SQLSERVER_deadlocks Count/s Deadlocks v4.4 QOS_SQLSERVER_differential_ba ckup_status Minutes Minutes Since Last Differential Backup QOS_SQLSERVER_fg_free_space Percent Filegroup Free Space v4.7 QOS_SQLSERVER_free_connecti ons v4.4 Percent Free Connections v4.4 QOS_SQLSERVER_free_space Percent Free Space v4.4 QOS_SQLSERVER_full_scans Count/sec. Full Scans v4.4 QOS_SQLSERVER_latch_waits Requests/Se c Latch Requests v4.4 QOS_SQLSERVER_lock_memory Kb Lock Memory Allocated v4.4 QOS_SQLSERVER_lock_requests Requests/Se c Lock Requests v4.4 QOS_SQLSERVER_lock_timeouts Count/sec Lock Timeouts v4.4 QOS_SQLSERVER_lock_waits Count/sec Lock Waits v4.4 QOS_SQLSERVER_locked_users Count Locked Users v4.4 QOS_SQLSERVER_locks_used Percent Percent Lock Blocks Used v4.4 QOS_SQLSERVER_log_cachehit_r atio QOS_SQLSERVER_log_file_growt hs QOS_SQLSERVER_log_file_shrink s QOS_SQLSERVER_log_flush_wait s Percent Log Cachehit Ratio v4.4 Count Log File Growths v4.4 Count Log File Shrinks v4.4 Count/sec. Log Flush Waits v4.4 OQS_SQLSERVER_logfile_size Count Log-file size v4.4 QOS_SQLSERVER_logfile_usage Percent Log-file Usage v4.4 QOS_SQLSERVER_logic_fragmen t Percent Logical Fragmentation v sqlserver Guide

67 QoS Metrics Monitor Name Units Description Version QOS_SQLSERVER_login_count Count Login Count v4.4 QOS_SQLSERVER_long_queries None Monitors long running queries in seconds. v4.4 QOS_SQLSERVER_mirror_sqlinst ance State Mirror Sqlinstance v4.4 QOS_SQLSERVER_mirror_state State Mirror State v4.4 QOS_SQLSERVER_mirror_witnes s_server QOS_SQLSERVER_optimizer_me mory State Mirror Witness Server v4.4 Kilobyte Optimizer Memory v4.4 QOS_SQLSERVER_page_reads Count/sec. Page Reads v4.4 QOS_SQLSERVER_page_writes Count/sec. Page Writes v4.4 QOS_SQLSERVER_scan_density Percent Object Density v4.4 QOS_SQLSERVER_server_cpu Percent CPU Usage v4.4 QOS_SQLSERVER_server_io Percent I/O busy v4.4 QOS_SQLSERVER_server_startup Days Server Uptime v4.4 QOS_SQLSERVER_sqlcache_mem ory Kb SQL Cache Memory Allocated v4.4 QOS_SQLSERVER_table_space Kb User Table Space Usage v4.4 QOS_SQLSERVER_total_memory Kb Total Dynamic Memory v4.4 QOS_SQLSERVER_transaction_ba ckup_status QOS_SQLSERVER_transactions Minutes Transactions /sec Minutes since last Transaction log backup v4.4 Transactions v4.4 QOS_SQLSERVER_user_cpu Percent CPU Usage v4.4 QOS_SQLSERVER_workspace_m emory QOS_SQLServer_ls_primary_stat us QOS_SQLServer_ls_time_since_l ast_backup QOS_SQL_Server_ls_secondary_ status Percent Workspace Memory Allocated v4.4 Status Primary Status v4.4 Minutes Minutes Since Last Backup v4.4 Status Secondary Status v4.4 Chapter 4: SQL Server Monitoring (sqlserver) Metrics 67

68 Alert Metrics Monitor Name Units Description Version QOS_SQL_Server_ls_time_since_ last_copy QOS_SQL_Server_ls_time_since_ last_restore QOS_SQL_Server_ls_last_restore d_latency Minutes Minutes Since Last Copy v4.4 Minutes Minutes Since Last Restore v4.4 Minutes Minutes Last Restored Latency v4.4 QOS_SQL_Server_fg_freeSpace_ with_avail_disk Percent SQL Server Filegroup Free Space considering Available Disk Size v4.4 QOS_SQL_Server_logfile_usage_ with_avail_disk Percent Monitors free space in the database log files after considering the available disk size. v4.7 Alert Metrics The following table describes the default settings for the alert metrics default threshold. Alarm Metric Warning Threshol d Warnin g Severity Error Threshold Active Connection Ratio Major Active Users Error Severit y Description Version Inform ation Alloc Space Major Monitors ratio of active connections to total allowed connections. v4.4 This checkpoint monitors the number of users having an active transaction at the moment of snapshot. v4.4 Monitors free space in allocated data files regardless of auto-growth v sqlserver Guide

69 Alert Metrics Avg Fragmentation Major Avg Wait Time Inform ation Backup Status Major Blocked Users Cachehit Ratio 95 Inform ation Warnin g 75 Major Availability Major Connection Memory Db Count Db Size Inform ation Inform ation Inform ation Db State Major Deadlocks Major Differential Backup Status Major Fg Space Major Free Connection Major Monitors average fragmentation per allocation unit of an index or table. v4.4 Monitors average lock wait time in ms. v4.4 Monitors number of days since last backup. v4.4 Monitors the number of user blocked. v4.4 Monitors the buffer cache-hit ratio v4.4 Monitors connectivity to the database instance v4.4 Monitors amount of connection memory in Kb. v4.4 Monitors the number of existing databases. v4.4 Monitors space size (in Kb) for each database, log and data files together. v4.4 Monitors database state v4.4 Monitors the number of deadlocks per second v4.4 Monitors number of days since last differential backup v4.4 Monitors free space in file groups v4.7 Monitors % free connections to SQL Server instance. v4.4 Chapter 4: SQL Server Monitoring (sqlserver) Metrics 69

70 Alert Metrics Free Space Major Full Scans Latch Waits Lock Memory Inform ation Inform ation Inform ation Lock Requests Major Lock Timeouts Major Lock Waits Major Locked Users Inform ation Locks Used Major Log Cachehit Ratio Major Log File Growths Log File Shrinks Log Flush Waits Inform ation Inform ation Inform ation Monitors free space in database. v4.4 Monitors the number of full scans (table or index) per second v4.4 Monitors the number of latch requests per second v4.4 Monitors amount of allocated lock memory in Kb v4.4 Monitors the number of lock requests per second v4.4 Monitor the number of lock-timeouts per second v4.4 Monitor the number of lock waits per second v4.4 Monitors the number of users suspended by locks v4.4 Monitors % of lock and lock owner blocks used. v4.4 Monitors the log cache-hit ratio v4.4 Monitors the usage (growth) of the transaction logs v4.4 Monitors the usage (shrinking) of the transaction logs v4.4 Monitors the number of log flush waits per second v4.4 Log File Size Major Monitors log file size v4.4 Log File Usage Major Monitors free space in log files v sqlserver Guide

71 Alert Metrics Logic Fragment Major Login Count Inform ation Long Jobs Major Long Queries Major Optimizer Memory Page Reads Page Writes Inform ation Inform ation inform ation Scan Density Major Server CPU Server IO Startup inform ation Inform ation Inform ation SQL Server 2000 only! Monitors logical fragmentation of an index or table. v4.4 Monitors the number of users currently logged onto the server v4.4 This checkpoint will find all jobs running longer then defined threshold in seconds v4.4 Monitors long running queries (in seconds) v4.4 Monitors amount of optimizer memory in Kb. v4.4 Monitors the number of database page reads per second v4.4 Monitors the number of database page writes per second. v4.4 SQL Server 2000 only! Monitors table/index fragmentation (density) v4.4 Monitors % of CPU usage by SQL Server instance v4.4 Monitors % of I/O busy for SQL Server instance. v4.4 Monitors the uptime (in days) of the database server v4.4 Chapter 4: SQL Server Monitoring (sqlserver) Metrics 71

72 Alert Metrics Cache Memory Table Space Total Memory Inform ation Inform ation Inform ation Transaction Backup Status Major Transactions Major User CPU User Waits Inform ation Inform ation Workspace Memory Major Profile Timeout - - NA Major SQL Error - - NA Major Monitors amount of SQL cache memory in Kb v4.4 Monitors reserved space in user tables. v4.4 Monitors total amount of dynamic server memory in Kb. v4.4 Monitors number of days since last transaction log backup v4.4 Monitors the number of transactions per second v4.4 Monitors % of CPU usage by user. v4.4 Monitors time in seconds, session spends waiting for a lock. v4.4 Monitors % of workspace memory allocated. v4.4 Defines the maximum processing time for all checkpoints in the profile. If this timeout is reached, the interval processing is finished and the probe waits for next heartbeat to evaluate any checkpoint schedules. Alarm message is issued. v4.4 SQL Native client error. v sqlserver Guide

73 Alert Metrics SQL Timeout - - NA Major Every checkpoint query run asynchronously. In case the query reaches the SQL timeout, the checkpoint processing will be terminated and the next checkpoint will be started. Alarm is issued. v4.4 Query Checksum - - NA Major Query manipulated. v4.4 Query Error - - NA Major Suspect Pages Major Agent Job Failure Major Primary Status Major Secondary Status 1 Major Returns data in unsupported format. v4.4 Checks if suspect pages are logged for databases. v4.4 Monitors agent jobs which failed during the defined threshold interval (in minutes). v4.4 Monitors collective status of agents for the primary log shipping database. v4.4 Monitors collective status of agents for the secondary log shipping database. v4.4 Chapter 4: SQL Server Monitoring (sqlserver) Metrics 73

74 Alert Metrics Primary Time Since Last Backup Major Secondary Time Since Last Copy Major Secondary Time Since Last Restore Major Monitors the duration(in minutes), since the last log backup was taken on primary database server in log shipping environment. v4.4 Monitors the duration(in minutes), since the last log backup was copied on secondary database server in log shipping environment. v4.4 Monitors the duration(in minutes), since the last log backup was restored on secondary database server in log shipping environment. v sqlserver Guide

75 Alert Metrics Secondary Last Restored Latency Major Free Space with Available Disk Major Log File Usage with Available Disk Major Monitors duration(in minutes) from the creation of the last backup to restore of the backup in log shipping environment. v4.4 Monitors free space in filegroups after considering the available disk size. v4.4 Monitors free space in the database log files after considering the available disk size. v4.7 Chapter 4: SQL Server Monitoring (sqlserver) Metrics 75

76

77 Chapter 5: SQL Server Monitoring (sqlserver) Known Issues v4.8 Dynamic Population of Message field with the corresponding Message field selected in the drop-down list at runtime is a limitation of the ppm. On creating a checkpoint with the threshold, first select message and then save it. The message text field is updated with the corresponding message text after reload. Known SQL Server 2000 Problem Sometimes SQL Server internal tables are not updated with current size values. This can cause negative size values in checkpoints database_size, free_size, fg_free_size and table_size. Use command DBCC UPDATEUSAGE to correct the values in SQL catalog (Running this command on large databases can take long time). Known SQL Server 2005 problem with av_fragmentation SQL Server 2005 changed SQL syntax for some commands during SP2 maintenance. If you want to run the checkpoint av_fragmentation, you need to apply this maintenance, otherwise checkpoint will return an error 0x80040e14. Migration Considerations Checkpoints "logic_fragment" and "scan_density" are not supported on SQL Server Use "av_fragmentation" instead. The checkpoint "database_status" has been replaced by "database_state". Database status values from SQL Server 2000 (and lower) are mapped to database state as defined in SQL Server Chapter 5: SQL Server Monitoring (sqlserver) Known Issues v4.8 77

78 V2 QoS Compatibility Mode V2 QoS Compatibility Mode In the V3 the has_max flag has been added to following checkpoints: alloc_space fg_free_space free_connections free_space locks_used logic_fragment scan_density server_cpu server_io user_cpu workspace_memory If you have created the QoS definition for any of these checkpoints under V2 sqlserver probe, you will need to enable the checkbox "QoS V2 compatibility" on the general tab of the GUI to make sure all data is inserted correctly into the QoS database. If you want to use the V3 format (has_max), you have to delete the V2 generated QoS definitions for these checkpoints (all the data for these checkpoints will then de deleted). For any questions related to this, please contact tech support. Other QoS Issues For user_cpu checkpoint the qos target definition is corrected in V3. The V2 target (loginname + program name) was not 100% unique, which can cause data inconsistencies in some cases. The target in V3 is changed to 'spid + hostid'. In case you need old target, change QoS definition for this checkpoint and replace current object definitions by $loginname.$programname. Note: The target definition for the checkpoint "fg_free_space" was incorrect in V2 - it was only 'db_name' instead of 'db_name + fg_name'. This is corrected in V3. 78 sqlserver Guide

79 Permissions Required Permissions Required For SQL Server versions 9, 10, and 11 set VIEW SERVER STATE permission on master database. Also, map the user for the following databases: master model msdb ReportServer ReportServerTempDB tempdb User mapping is required for the following tables: master.sys.databases master.dbo.sysperfinfo msdb.dbo.sysjobsteps msdb.dbo.sysjobs msdb.dbo.syscategories msdb.dbo.log_shipping_monitor_secondary msdb.dbo.log_shipping_monitor_primary msdb.dbo.sysjobhistory.sys.database_files.sys.partitions.sys.allocation_units.sys.internal_tables.sys.filegroups For Windows authentication, map the user for access to SQL server, and to the Niscache folder of the file system on which the CA UIM robot is installed. Note: When you grant permission to the user, the checkpoints fg_freespace_with_avail_disk and logfile_usage_with_avail_disk does not work for the non-administrator user. Chapter 5: SQL Server Monitoring (sqlserver) Known Issues v4.8 79

80 Permissions Required Map User for Permission In general, default database roles are used to grant access to users. But in some scenarios, you may want to edit and grant different roles and permissions to different users. User mapping is done to GRANT, REVOKE, and DENY permissions for user in the SQL Server. Follow these steps: 1. Right click on the table and go to Properties > Permissions Tab. 2. Select Add and browse for the user to grant permission. 3. Click OK. 4. Select the permission type under the Grant column. User is mapped for the required permission. 80 sqlserver Guide

81 Chapter 6: Troubleshooting and FAQs This section contains troubleshooting information for the SQL Server Monitoring probe. Cannot map user to the file system containing Niscache folder Valid for Windows Authentication Symptom: The probe cannot create.met files in the Niscache folder due to which, the QoS are not inserted in the database, and are not visible on the USM. Solution: Do the following: Go to the Raw Configure section of the sqlserver probe. Set the value of the flag_reverttoself option as Yes. Restart the probe. Chapter 6: Troubleshooting and FAQs 81