NetIQ AppManager for Microsoft SQL Server Management Guide. October 2017

Transcription

1 NetIQ AppManager for Microsoft SQL Server Management Guide October 2017

2 Legal Notice For information about NetIQ legal notices, disclaimers, warranties, export and other use restrictions, U.S. Government restricted rights, patent policy, and FIPS compliance, see NetIQ Corporation. All Rights Reserved. For information about NetIQ trademarks, see All third-party trademarks are the property of their respective owners.

3 Contents About this Book and the Library 5 About NetIQ Corporation 7 1 Introducing AppManager for Microsoft SQL Server 9 2 Installing AppManager for Microsoft SQL Server System Requirements Installing the Module Deploying the Module with Control Center Silently Installing the Module Discovering SQL Server Resources Discovering AlwaysOn Availability Group Configuring SQL Server User in Security Manager Upgrading Knowledge Script Jobs SQL Server Knowledge Scripts Accessibility AvailabilityGroupHealth BackupJob BlockedProcesses CacheHitRatio ClusterOwner Connectivity CPUUtil DataSpace DBLocks DBMirrorStatus DBStats ErrorLog LogShipping LogSpace MemUtil MonitorJobs NearMaxConnect NearMaxLocks RunSql ServerDown TopResourceUsers UserConnections Recommended Knowledge Script Groups Troubleshooting AppManager for Microsoft SQL Server Enabling dynamic logging for a Knowledge Script job Determining the non-default port for SQL Server or Availability Group Listener Contents 3

4 4

5 About this Book and the Library The NetIQ AppManager product (AppManager) is a comprehensive solution for managing, diagnosing, and analyzing performance, availability, and health for a broad spectrum of operating environments, applications, services, and server hardware. AppManager provides system administrators with a central, easy-to-use console to view critical server and application resources across the enterprise. With AppManager, administrative staff can monitor computer and application resources, check for potential problems, initiate responsive actions, automate routine tasks, and gather performance data for real-time and historical reporting and analysis. Intended Audience This guide provides information for individuals responsible for installing an AppManager module and monitoring specific applications with AppManager. Other Information in the Library The library provides the following information resources: Installation Guide for AppManager Provides complete information about AppManager pre-installation requirements and step-bystep installation procedures for all AppManager components. User Guide for AppManager Control Center Provides complete information about managing groups of computers, including running jobs, responding to events, creating reports, and working with Control Center. A separate guide is available for the AppManager Operator Console. Administrator Guide for AppManager Provides information about maintaining an AppManager management site, managing security, using scripts to handle AppManager tasks, and leveraging advanced configuration options. Upgrade and Migration Guide for AppManager Provides complete information about how to upgrade from a previous version of AppManager. Management guides Provide information about installing and monitoring specific applications with AppManager. Help Provides context-sensitive information and step-by-step guidance for common tasks, as well as definitions for each field on each window. The AppManager library is available in Adobe Acrobat (PDF) format from the AppManager Documentation page of the NetIQ website. About this Book and the Library 5

6 6 About this Book and the Library

7 About NetIQ Corporation We are a global, enterprise software company, with a focus on the three persistent challenges in your environment: Change, complexity and risk and how we can help you control them. Our Viewpoint Adapting to change and managing complexity and risk are nothing new In fact, of all the challenges you face, these are perhaps the most prominent variables that deny you the control you need to securely measure, monitor, and manage your physical, virtual, and cloud computing environments. Enabling critical business services, better and faster We believe that providing as much control as possible to IT organizations is the only way to enable timelier and cost effective delivery of services. Persistent pressures like change and complexity will only continue to increase as organizations continue to change and the technologies needed to manage them become inherently more complex. Our Philosophy Selling intelligent solutions, not just software In order to provide reliable control, we first make sure we understand the real-world scenarios in which IT organizations like yours operate day in and day out. That's the only way we can develop practical, intelligent IT solutions that successfully yield proven, measurable results. And that's so much more rewarding than simply selling software. Driving your success is our passion We place your success at the heart of how we do business. From product inception to deployment, we understand that you need IT solutions that work well and integrate seamlessly with your existing investments; you need ongoing support and training post-deployment; and you need someone that is truly easy to work with for a change. Ultimately, when you succeed, we all succeed. Our Solutions Identity & Access Governance Access Management Security Management Systems & Application Management Workload Management Service Management About NetIQ Corporation 7

8 Contacting Sales Support For questions about products, pricing, and capabilities, contact your local partner. If you cannot contact your partner, contact our Sales Support team. Worldwide: United States and Canada: Web Site: Contacting Technical Support For specific product issues, contact our Technical Support team. Worldwide: North and South America: Europe, Middle East, and Africa: +353 (0) Web Site: Contacting Documentation Support Our goal is to provide documentation that meets your needs. The documentation for this product is available on the NetIQ web site in HTML and PDF formats on a page that does not require you to log in. If you have suggestions for documentation improvements, click comment on this topic at the bottom of any page in the HTML version of the documentation posted at documentation. You can also Documentation-Feedback@netiq.com. We value your input and look forward to hearing from you. Contacting the Online User Community NetIQ Communities, the NetIQ online community, is a collaborative network connecting you to your peers and NetIQ experts. By providing more immediate information, useful links to helpful resources, and access to NetIQ experts, NetIQ Communities helps ensure you are mastering the knowledge you need to realize the full potential of IT investments upon which you rely. For more information, visit 8 About NetIQ Corporation

9 1 1Introducing AppManager for Microsoft SQL Server AppManager for Microsoft SQL Server provides a comprehensive solution for monitoring the performance and availability of your SQL Server environment. With AppManager for Microsoft SQL Server, you can: Quickly identify fault lines or factors that might adversely impact performance and take preventive action Plan and schedule timely upgrades Isolate the causes of server performance problems and address them on time, ensuring better performance for your enterprise Run Knowledge Script jobs on SQL Server components Run Knowledge Script jobs directly on SQL Server virtual servers in a clustered environment AppManager for Microsoft SQL Server provides Knowledge Scripts designed to give you a comprehensive view of how SQL Server performs on your servers. The Knowledge Scripts in the SQL Server category monitor the following: SQL Server accessibility and connectivity Blocked SQL Server processes Frequency at which pages are retrieved from SQL Server cache SQL Server data space and log space Locked databases SQL Server Error logs SQL Server and reports on jobs that have not completed successfully SQL Server services SQL Server user connections Total CPU time used by SQL Server users and their connections Number of read and write operations Total number of locks held by SQL Server users and their connections Number of memory pages allocated to by SQL Server users and their connections Mirrored database status CPU percentage used by SQL Server processes Memory used by SQL Server processes Log shipping status Node ownership of a SQL Server failover cluster instance or Always On Availability Group You can set thresholds that specify the boundaries of optimal performance. You can also configure AppManager to raise events when those thresholds are crossed. Introducing AppManager for Microsoft SQL Server 9

10 In addition to monitoring, you can use SQL Server Knowledge Scripts to collect performance data for use in reports. AppManager lets you generate reports that range in scope from minute-by-minute values to monthly values over a period of years. These reports range in purpose from evaluating a narrow window of performance data to illustrating trends that aid in effective planning. 10 Introducing AppManager for Microsoft SQL Server

11 2 2Installing AppManager for Microsoft SQL Server This chapter provides installation instructions and describes system requirements for AppManager for Microsoft SQL Server. This chapter assumes you have AppManager installed. For more information about installing AppManager or about AppManager system requirements, see the Installation Guide for AppManager, which is available on the AppManager Documentation page. NOTE AppManager for Microsoft SQL Server 8.x cannot be upgraded from AppManager for Microsoft SQL Server module 7.x. This module has a new set of Knowledge Scripts and managed objects. It has a new approach to monitor SQL Server than earlier versions (7.x) of the SQL module. 2.1 System Requirements For the latest information about supported software versions and the availability of module updates, visit the AppManager Supported Products page. Unless noted otherwise, this module supports all updates, hotfixes, and service packs for the releases listed below. AppManager for Microsoft SQL Server has the following system requirements: Software/Hardware NetIQ AppManager installed on the AppManager repository (QDB) computers, on the SQL Server computers you want to monitor (agents), and on all console computers Microsoft Windows operating system on agent computers Version 8.0.3, 8.2, 9.1, or later One of the following AppManager agents are required: AppManager agent with hotfix or later AppManager agent 8.0.3, 8.2, 9.1, or later One of the following: Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Windows Server 2008 (32-bit or 64-bit) Installing AppManager for Microsoft SQL Server 11

12 Software/Hardware Microsoft SQL Server on agent computers Version One of the following: SQL Server 2017 SQL Server 2016 SQL Server 2014 (32-bit or 64-bit) SQL Server 2012 (32-bit or 64-bit) SQL Server 2008 R2 (32-bit or 64-bit) SQL Server 2008 (32-bit or 64-bit) SQL Server 2005 Service Pack 2 (32-bit or 64-bit) Microsoft.NET Framework on the agent computer where you want to install the managed objects of AppManager for Microsoft SQL Server Microsoft.NET Framework on the computer where you want to install the repository, Knowledge Scripts, help files, and console extensions of AppManager for Microsoft SQL Server AppManager for Microsoft Windows module installed on repository and console computers 3.5 and 4.0 or later or later. For more information, see the AppManager Module Upgrades & Trials Web page. NOTE: For clustered SQL Server monitoring on Windows Server 2012 and later, you must ensure that AppManager for Microsoft Windows 7.8 or later is installed on the agent and on all console computers. For more information, see the AppManager Module Upgrades & Trials Web page. 2.2 Installing the Module Run the module installer on the SQL Server computers you want to monitor (agents) to install the agent components, and run the module installer on all console computers to install the Help and console extensions. NOTE Install Microsoft.NET Framework 3.5 and.net Framework 4.0 or later on the agent computer where you want to install the managed objects of AppManager for Microsoft SQL Server. To install.net 4.0 with the Add Roles and Features wizard in Windows Server Manager, refer the Microsoft article. Install Microsoft.NET Framework 3.5 on the computer where you want to install the repository, Knowledge Scripts, help files and console extensions of AppManager for Microsoft SQL Server. Access the AM70-SQLServer-8.x.x.0.msi module installer from the AM70_SQLServer_8.x.x.0. self-extracting installation package on the AppManager Module Upgrades & Trials page. 12 Installing AppManager for Microsoft SQL Server

13 For Windows environments where User Account Control (UAC) is enabled, install the module using an account with administrative privileges. Use one of the following methods: Log in to the server using the account named Administrator. Then run the module installer.msi file from a command prompt or by double-clicking it. Log in to the server as a user with administrative privileges and run the module installer.msi file as an administrator from a command prompt. To open a command-prompt window at the administrative level, right-click a command-prompt icon or a Windows menu item and select Run as administrator. You can install the Knowledge Scripts and the Analysis Center reports into local or remote AppManager repositories (QDBs). The module installer installs Knowledge Scripts for each module directly into the QDB instead of installing the scripts in the \AppManager\qdb\kp folder as in previous releases of AppManager. You can install the module manually, or you can use Control Center to deploy the module on a remote computer where an agent is installed. For more information, see Section 2.3, Deploying the Module with Control Center, on page 14. However, if you do use Control Center to deploy the module, Control Center only installs the agent components of the module. The module installer installs the QDB and console components as well as the agent components on the agent computer. To install the module manually: 1 Double-click the module installer.msi file. 2 Accept the license agreement. 3 Review the results of the pre-installation check. You can expect one of the following three scenarios: No AppManager agent is present: In this scenario, the pre-installation check fails, and the installer does not install agent components. An AppManager agent is present, but some other prerequisite fails: In this scenario, the default is to not install agent components because of one or more missing prerequisites. However, you can override the default by selecting Install agent component locally. A missing application server for this particular module often causes this scenario. For example, installing the AppManager for Microsoft SharePoint module requires the presence of a Microsoft SharePoint server on the selected computer. All prerequisites are met: In this scenario, the installer installs the agent components. 4 To install the Knowledge Scripts into the QDB: 4a Select Install Knowledge Scripts to install the repository components, including the Knowledge Scripts, object types, and SQL stored procedures. 4b Specify the SQL Server name of the server hosting the QDB, as well as the case-sensitive QDB name. NOTE: Microsoft.NET Framework 3.5 is required on the computer where you run the installation program for the QDB portion of the module. For computers running more recent versions of Windows operating systems that use a newer version of.net, install.net 3.5 with the Add Roles and Features wizard in Windows Server Manager, as described in this Microsoft article. 5 (Conditional) If you use Control Center 7.x, run the module installer for each QDB attached to Control Center. 6 (Conditional) If you use Control Center 8.x or later, run the module installer only for the primary QDB. Control Center automatically replicates this module to secondary QDBs. Installing AppManager for Microsoft SQL Server 13

14 7 Run the module installer on all console computers to install the Help and console extensions. 8 Run the module installer on the SQL Server computers you want to monitor (agents) to install agent components. 9 (Conditional) If you have not discovered SQL Server resources, run the Discovery_SQLServer Knowledge Script on all agent computers where you installed the module. For more information, see Section 2.5, Discovering SQL Server Resources, on page To get the updates provided in this release, upgrade any running Knowledge Script jobs. For more information, see Section 2.8, Upgrading Knowledge Script Jobs, on page 24. After the installation has completed, the SQLserver_Install.log file, located in the \NetIQ\Temp\NetIQ_Debug\ServerName folder, lists any problems that occurred. 2.3 Deploying the Module with Control Center You can use Control Center to deploy the module on a remote computer where an agent is installed. This topic briefly describes the steps involved in deploying a module and provides instructions for checking in the module installation package. For more information, see the Control Center User Guide for AppManager, which is available on the AppManager Documentation page Deployment Overview This section describes the tasks required to deploy the module on an agent computer. To deploy the module on an agent computer: 1 Verify the default deployment credentials. 2 Check in an installation package. For more information, see Section 2.3.2, Checking In the Installation Package, on page Configure an address to receive notification of a deployment. 4 Create a deployment rule or modify an out-of-the-box deployment rule. 5 Approve the deployment task. 6 View the results Checking In the Installation Package You must check in the installation package, AM70-SQLServer-8.x.x.0.xml, before you can deploy the module on an agent computer. To check in a module installation package: 1 Log on to Control Center using an account that is a member of a user group with deployment permissions. 2 Navigate to the Deployment tab (for AppManager 8.x or later) or Administration tab (for AppManager 7.x). 3 In the Deployment folder, select Packages. 4 On the Tasks pane, click Check in Deployment Packages (for AppManager 8.x or later) or Check in Packages (for AppManager 7.x). 5 Navigate to the folder where you saved AM70-SQLServer-8.x.x.0.xml and select the file. 14 Installing AppManager for Microsoft SQL Server

15 6 Click Open. The Deployment Package Check in Status dialog box displays the status of the package check in. 7 To get the updates provided in this release, upgrade any running Knowledge Script jobs. For more information, see Section 2.8, Upgrading Knowledge Script Jobs, on page Silently Installing the Module To silently (without user intervention) install the module on a local machine using the default settings, run the following command from the folder in which you saved the module installer: msiexec.exe /i "AM70-SQLServer-8.x.x.0.msi" /qn where x.x is the actual version number of the module installer. NOTE: To perform a silent install on an AppManager agent running Windows 2008 R2, open a command prompt at the administrative level and select Run as administrator before you run the silent install command listed above. To silently install the module on a local machine (on an Agent) and to check in the Knowledge Scripts on a remote AppManager repository, you can use either Windows authentication or SQL authentication. Windows authentication: AM70-SQLServer-8.x.x.0.msi /qn MO_B_QDBINSTALL=1 MO_B_MOINSTALL=1 MO_B_SQLSVR_WINAUTH=1 MO_SQLSVR_NAME=SQL_Server_Name MO_QDBNAME=AM-Repository Name SQL authentication: AM70-SQLServer-8.x.x.0.msi /qn MO_B_QDBINSTALL=1 MO_B_MOINSTALL=1 MO_B_SQLSVR_WINAUTH=0 MO_SQLSVR_USER=SQL login MO_SQLSVR_PWD=SQL Login Password MO_SQLSVR_NAME=SQL Server Name MO_QDBNAME=AM-Repository Name To create a log file that describes the operations of the module installer, add the following flag to the command above: /L* "AM70-SQLServer-8.x.x.0.msi.log" The log file is created in the folder in which you saved the module installer. 2.5 Discovering SQL Server Resources Use the Discovery_SQLServer Knowledge Script to discover SQL Server configurations and resources. This script raises an event if discovery fails or succeeds. By default, this script runs once for each computer. NOTE: To run this Knowledge Script, you need public and read-only SQL Server permission. To discover AlwaysOn availability group databases under SQL Server instance that is on the secondary replica, ensure that the Readable Secondary option is configured as Yes. Installing AppManager for Microsoft SQL Server 15

16 If you delete or add a resource object, or if you make any other kind of change that might affect the monitoring of your resources, run the Discovery_SQLServer Knowledge Script again to update your list of resource objects. In addition, if you are running this module on AppManager 8 or later, you can use the delta discovery feature in Control Center to run discovery on a schedule to more quickly detect changes to your environment. When you run Discovery_SQLServer Knowledge Script, SQL Server Cluster Instances are discovered under SQL Server Virtual folder and SQL Server Instances (non-clustered) are discovered under NT machine folder. Therefore, you can monitor clustered instances only through the SQL Server Virtual folder. Resource Object NT machine Setting Parameter Values Set the Values tab parameters as needed: Description Job Failure Notification Raise event if job fails unexpectedly Event severity when job fails unexpectedly Select Yes to raise an event if discovery job fails unexpectedly. The default is Yes. that is raised when the job fails unexpectedly. The default is 5. Additional Settings Event Details Event detail format Authentication Username Select the format in which you want to display the event detail. You can select from HTML Table or Plain Text. The default is HTML Table. Select the authentication method that you want to use for SQL Server discovery. You can either select Windows Authentication or SQL Server Authentication. The default is Windows Authentication. Specify the Windows or SQL Server user name that you want to use for SQL Server discovery. If you are a Windows user, specify the user name in the DomainName\User format. You can specify multiple users separated by commas. This field is optional. For more information on specifying the user name, see Section 2.7.3, Specifying the User Name in the Knowledge Script, on page 21. Exclude server list (commaseparated list) Specify the list of SQL server instances that you do not want to discover, separated by commas. 16 Installing AppManager for Microsoft SQL Server

17 Description Specify list of databases to exclude (commaseparated) Specify the name of the databases you want to exclude from discovery, separated by commas. You can use standard pattern-matching characters when specifying database names: * matches zero or more instances of a previous character? matches exactly one instance of a previous character \d matches any single digit from 0-9 [ ] matches exactly one instance of any character between the brackets, including ranges Specify file path containing list of databases to exclude Specify the full file path of.csv or.txt format file that contains the name of the databases that you want to exclude from discovery. Exclude discovering availability group databases under SQL Server instance NOTE: Enter each database on a separate line. You can use standard pattern-matching characters when specifying database names: * matches zero or more instances of a previous character? matches exactly one instance of a previous character \d matches any single digit from 0-9 [ ] matches exactly one instance of any character between the brackets, including ranges Select Yes to exclude discovery of availability group databases under SQL Server instance. NOTE: This parameter does not apply when you run this discovery job on a availability group listener node. Exclude discovering the data and log space information for a database if auto growth is enabled? Raise event if discovery succeeds? Event severity when discovery succeeds Event severity when discovery is not applicable Raise event if discovery partially succeeds? Select Yes to exclude discovery of the data space and the log space information for a database if auto growth is enabled. The default is unselected. Select Yes to raise an event if discovery succeeds. The default is Yes. Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery succeeds. The default is 25. Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery is not applicable. The default is 15. Select Yes to raise an event if discovery succeeds partially. The default is Yes. NOTE: The event displays the list of databases that are not discovered. Event severity when discovery partially succeeds Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery partially succeeds. The default is 15. Raise event if discovery fails? Event severity when discovery fails Select Yes to raise an event if discovery fails. The default is Yes Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery fails. The default is 5. Installing AppManager for Microsoft SQL Server 17

18 2.6 Discovering AlwaysOn Availability Group To discover the resources of AlwaysOn availability group, you must run the following Knowledge Scripts: 1. Discovery_SQLServerAlwaysOnCluster: Discovers the availability group listeners on an AlwaysOn cluster. 2. Discovery_SQLServer: Discovers the availability group resources under the listener nodes Discovering Availability Group Listeners AppManager for SQL Server 8.1 or later release includes a new discovery script, Discovery_SQLServerAlwaysOnCluster that you can use to discover the availability group listeners on a cluster. An availability group listener is a virtual network name (VNN) to which clients can connect to the AlwaysOn availability group. This script only discovers the listener nodes. NOTE: The Discovery_SQLServerAlwaysOnCluster Knowledge Script does not discover and monitor cluster shared disks through listener node. You can discover AlwaysOn Availability Groups only on AppManager version 8.0.x or later. In AppManager 8.0.2, NetIQ recommends that you use the Control Center Console to view the objects under the availability group. By default, this script runs once for each computer. Security Rights To correctly discover and monitor a Microsoft AlwaysOn cluster, this Knowledge Script requires local Administrator access to each node of the Microsoft cluster. To do this, run the netiq service as a domain user account and a member of the local Administrator group on each member of the cluster. Without this access, the discovery fails because it relies on the Microsoft Cluster API to properly access cluster resources. Administering a Cluster The Cluster Administrator can be used to administer a cluster, provided the account you are using has the required permissions and group memberships. The local Administrator account and local system account always have access to the cluster. You can use another account to administer a cluster with Cluster Administrator if the following requirements are true: The account has permission to administer the cluster. You must use Cluster Administrator to assign permissions, not Windows Group Administrator. The account is a domain account, which is a member of the local Administrators group. The account is a member of the local Administrators group on each node of the cluster. The account can be a member of other groups, such as global groups, as long as it is a domain account. By default, this Knowledge Script raises an event when discovery fails. 18 Installing AppManager for Microsoft SQL Server

19 NOTE: AlwaysOn availability group does not support delta discovery. If you add or remove a cluster node (availability group replica), you must first delete the listener node objects and run both Discovery_SQLServerAlwaysOnCluster and Discovery_SQLServer Knowledge Scripts again to discover the listener nodes and the resources. Resource Object NT Machine Folder Setting Parameter Values Set the Values tab parameters as needed: Description Job Failure Notification Raise event if job fails unexpectedly Event severity when job fails unexpectedly Select Yes to raise an event if the discovery job fails unexpectedly. The default is Yes. that is raised when the job fails unexpectedly. The default is 5. Additional Settings Event Details Event detail format Raise event if discovery succeeds? Event severity when discovery succeeds Raise event if discovery is not applicable? Select the format in which you want to display the event detail. You can select from HTML Table or Plain Text. The default is HTML Table. Select Yes to raise an event if discovery succeeds. The default is unselected. Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery succeeds. The default is 25. Select Yes to raise an event if discovery is not applicable. For example, if you run this Knowledge Script other than an cluster instance, discovery is not applicable. The default is Yes. Event severity when discovery is not applicable Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery is not applicable. The default is Discovering Availability Group Resources Run the Discovery_SQLServer Knowledge Script on the discovered listener nodes to discover the availability group resources under the listener nodes. NOTE: To run this Knowledge Script on availability group listeners, you need public, read-only, view server state, and view any definition SQL Server permission. You must configure the users in security manager before running this script. For more information about configuring users in security manager, see Section 2.7, Configuring SQL Server User in Security Manager, on page 20. Installing AppManager for Microsoft SQL Server 19

20 For more information on Discovery_SQLServer script, see Section 2.5, Discovering SQL Server Resources, on page Configuring SQL Server User in Security Manager To run the Discovery_SQLServer Knowledge Script with a specific SQL/Windows authentication user, you must configure your user login and password information in the Custom tab of AppManager Security Manager. This is the user that AppManager will use to login to SQL Server instances. You can either configure a default user for all the instances, or a specific user for specific SQL Server instances. You can also use a non-default TCP port for SQL Server instance or Availability Group Listener by configuring the AppManager Security Manager. NOTE: This module does not use the user specifications configured in Security Manager for the earlier versions of SQL module Configuring SQL Server User To use a specific SQL/Windows authentication user account, use the following configuration: Field Label Sub-label Description SQLServer Do one of the following: For SQL Server Instance: UserName or UserName$InstanceName. For example: Type sa, sa$sqlserverinst1, or amdom001\user1$sqlserverinst1 For AlwaysOn Availability Group Listener Node: Specify the availability group listener node name as the instance name, UserName or UserName$AvailabilityGroupListenerNode. For example: Type sa, sa$aglistener1, or amdom001\user1$aglistener1 NOTE: For Windows user, specify the username in the DomainName\UserName format. For example: amdom001\user1$sqlserverinst1 A user without any specific instance is the default user. For Windows Authentication, if you leave this field blank, AppManager uses the NetIQ service account to log in to the SQL Server. Value 1 Value 2 Password for the user. Leave this field blank. NOTE: Type blank in this field if the password in the Value 1 field is left empty, that is, the user account does not have a password. Value 3 Leave this field blank. 20 Installing AppManager for Microsoft SQL Server

21 Field Extended application support Description Required field. Encrypts the user name and password in Security Manager. Do not leave this option unselected Configuring non-default TCP port You can specify the non-default TCP port that is used by a SQL Server or an Availability Group Listener in the AppManager Security Manager. NOTE: This feature is only supported on AppManager for Microsoft SQL Server 8.2 or later. To use a non-default TCP port for the SQL Server or the Availability Group Listener, use the following configuration: Field Label Sub-label Description SQLServer Specify the username in the InstanceName_TCPPort format. For example: sqlserverinst1_tcpport. NOTE: The InstanceName must be the Virtual node name. Value 1 Value 2 Value 3 Extended application support Specify the TCP port. For example: 1469, where 1469 is the TCP port used by the SQL Server or the Availability Group Listener. Leave this field blank. Leave this field blank. Required field. Encrypts the user name and password in Security Manager. Do not leave this option unselected Specifying the User Name in the Knowledge Script To run a SQL Server Knowledge Script with a specific Windows/SQL authentication user, you must specify a user name to access the SQL Server instances. You can specify a default user name (a user without any instance), a user name with specific instances, or a combination of both. You can specify multiple user names separated by a comma. The users that you specify in the Knowledge Script must be configured in Security Manager before running the script. For more information, see Section 2.7.1, Configuring SQL Server User, on page 20. NOTE: When running a Knowledge Script, you can specify only one default user in the User name parameter. The different use cases below provide examples of different types of authentication. All the users in the examples are already configured in Security Manager. Installing AppManager for Microsoft SQL Server 21

22 Windows Authentication Use Case 1 - User Name with Default User Use amdom001\user1 for User name in a Knowledge Script. When you run this script on three instances, SQLServerInst1, SQLServerInst2, and SQLServerInst3, the script runs on all the instances successfully. On all the instances, this script uses the default amdom001\user1 user configuration. The user name without any instance name is used as the default user for all instances. Use Case 2 - User Name with Specific Instances Use amdom001\user2$sqlserverinst1 for User name in a Knowledge Script. When you run this script on two instances, SQLServerInst1 and SQLServerInst2, this script runs successfully on the SQLServerInst1 instance with this amdom001\user2$sqlserverinst1 user configuration. On SQLServerInst2, this script fails, because there is no specific or default user available for this instance. Use Case 3 - User Name with Specific Instances and Default User Use amdom001\user1,amdom001\user2$sqlserverinst1 for User name in a Knowledge Script. When you run this script on three instances, SQLServerInst1, SQLServerInst2, and SQLServerInst3, this script runs on all the instances successfully. On SQLServerInst1 instance, this script uses this amdom001\user2$sqlserverinst1 user configuration and on SQLServerInst2, and SQLServerInst3, this script uses the amdom001\user1 user configuration. The user name without any instance name is used as the default user for all instances. NOTE: User with a specific instance takes precedence over the default user. Use Case 4 - User Name with Specific Instances and Default User in Incorrect Format Use amdom001\user2$sqlserverinst1,user1 for User name in a Knowledge Script. When you run this script on three instances, SQLServerInst1, SQLServerInst2, and SQLServerInst3, this script runs properly on SQLServerInst1 instance. This script fails on SQLServerInst2, and SQLServerInst3, because the user name is not formatted properly in the DomainName\UserName format. Use Case 5 - User Name Field as Blank If you select Windows Authentication in the Authentication field and leave the User name field blank in the Knowledge Script, then the script uses the default NetIQ service account user to login to the SQL Server. SQL Server Authentication Use Case 1 - User Name with Default User Use sa for User name in a Knowledge Script. When you run this script on three instances, SQLServerInst1, SQLServerInst2, and SQLServerInst3, this script runs on all the instances successfully. On all the instances, this script uses the default sa user configuration. 22 Installing AppManager for Microsoft SQL Server

23 The user name without any instance name is used as the default user for all instances. Use Case 2 - User Name with Specific Instances Use sa1$sqlserverinst1 for User name in a Knowledge Script. When you run this script on two instances, SQLServerInst1 and SQLServerInst2, this script runs successfully on SQLServerInst1 instance with this sa1$sqlserverinst1 user configuration. On SQLServerInst2, this script fails, because there is no specific or default user available for this instance. Use Case 3 - User Name with Specific Instances and Default User Use sa,sa1$sqlserverinst1 for User name in a Knowledge Script. When you run this script on three instances, SQLServerInst1, SQLServerInst2, and SQLServerInst3, this script runs on all the instances successfully. On SQLServerInst1 instance, this script uses this sa1$sqlserverinst1 user configuration and on SQLServerInst2, and SQLServerInst3, this script uses the sa user configuration. The user name without any instance name is used as the default user for all instances. NOTE: User with a specific instance takes precedence over the default user. Use Case 4 - User Name Field as Blank If you select SQL Server Authentication and leave the User name field blank in the Knowledge Script, then the script raises an error event. The figure below displays the user specifications that is used by SQL Server instances while running a knowledge script. Knowledge Script User Specifications User Account used on Instances Instance0 Instance1 Instance2 Instance3 username username username$inst1 username$inst1 username$inst2 username$inst1 username$inst2 username username$inst2 username$inst3 username username$inst2 username$inst3 Installing AppManager for Microsoft SQL Server 23

24 2.8 Upgrading Knowledge Script Jobs If you are using AppManager 8.x or later, the module upgrade process now retains any changes you might have made to the parameter settings for the Knowledge Scripts in the previous version of this module. Before AppManager 8.x, the module upgrade process overwrote any settings you might have made, changing the settings back to the module defaults. As a result, if this module includes any changes to the default values for any Knowledge Script parameter, the module upgrade process ignores those changes and retains all parameter values that you updated. Unless you review the management guide or the online Help for that Knowledge Script, you will not know about any changes to default parameter values that came with this release. You can push the changes for updated scripts to running Knowledge Script jobs in one of the following ways: Use the AMAdmin_UpgradeJobs Knowledge Script. Use the Properties Propagation feature Running AMAdmin_UpgradeJobs The AMAdmin_UpgradeJobs Knowledge Script can push changes to running Knowledge Script jobs. Your AppManager repository (QDB) must be at version 7.0 or later. Upgrading jobs to use the most recent script version allows the jobs to take advantage of the latest script logic while maintaining existing parameter values for the job. For more information, see the Help for the AMAdmin_UpgradeJobs Knowledge Script Propagating Knowledge Script Changes You can propagate script changes to jobs that are running and to Knowledge Script Groups, including recommended Knowledge Script Groups and renamed Knowledge Scripts. Before propagating script changes, verify that the script parameters are set to your specifications. You might need to appropriately set new parameters for your environment or application. If you are not using AppManager 8.x or later, customized script parameters might have reverted to default parameters during the installation of the module. You can choose to propagate only properties (specified in the Schedule and Values tabs), only the script (which is the logic of the Knowledge Script), or both. Unless you know specifically that changes affect only the script logic, you should propagate the properties and the script. For more information about propagating Knowledge Script changes, see the Running Monitoring Jobs chapter of the Control Center User Guide for AppManager. 24 Installing AppManager for Microsoft SQL Server

25 2.8.3 Propagating Changes to Ad Hoc Jobs or Knowledge Script Groups You can propagate the properties and the logic (script) of a Knowledge Script to ad hoc jobs started by that Knowledge Script. Corresponding jobs are stopped and restarted with the Knowledge Script changes. You can also propagate the properties and logic of a Knowledge Script to corresponding Knowledge Script Group members. After you propagate script changes to Knowledge Script Group members, you can propagate the updated Knowledge Script Group members to associated running jobs. Any monitoring jobs started by a Knowledge Script Group member are restarted with the job properties of the Knowledge Script Group member. To propagate changes to ad hoc Knowledge Script jobs or Knowledge Script Groups: 1 In the Knowledge Script view, select the Knowledge Script or Knowledge Script Group for which you want to propagate changes. 2 Right-click the script or group and select Properties propagation > Ad Hoc Jobs. 3 Select the components of the Knowledge Script that you want to propagate to associated ad hoc jobs or groups and click OK: Select Script Properties To propagate The logic of the Knowledge Script. Values from the Knowledge Script Schedule and Values tabs, such as schedule, monitoring values, actions, and advanced options. If you are using AppManager 8.x or later, the module upgrade process now retains any changes you might have made to the parameter settings for the Knowledge Scripts in the previous version of this module. Installing AppManager for Microsoft SQL Server 25

26 26 Installing AppManager for Microsoft SQL Server

27 3 3SQL Server Knowledge Scripts AppManager provides the following Knowledge Scripts for monitoring SQL Server version 2005 and later. The SQLServer category of Knowledge Scripts is supported for SQL Server resources installed in clustered and non-clustered environments. When deciding which Knowledge Scripts to run and the appropriate threshold values to use, consider how other applications you manage are dependent on SQL Server. To run these Knowledge Scripts, you must require a minimum of Public and read-only SQL Server permissions. There are few Knowledge Scripts that require specific SQL Server permission. The following graphic displays the permissions required to run the Knowledge Scripts.x SQL Server Knowledge Scripts 27

28 Knowledge Scripts SQL Server Permissions Discovery_SQLServer Accessibility LogSpace DataSpace Public, read-only permissions on all databases to be monitored or discovered DBMirrorStatus DBStats MonitorJobs Select permission on msdb..sysjobs, msdb..sysjobservers Blocked Processes DBLocks NearMaxConnect NearMaxLocks View Server State TopResourceUsers Discovering and Monitoring Through AlwaysOn Listener Discovery_SQLServer Accessibility DataSpace DBLocks DBStats Read-only, View Server State, View Any Definitions permissions on AlwaysOn Availability Group Databases LogSpace 28 SQL Server Knowledge Scripts

29 From the Knowledge Script view of Control Center, you can access more information about any NetIQ-supported Knowledge Script by selecting it and clicking Help. In the Operator Console, click any Knowledge Script in the Knowledge Script pane and press F1. Knowledge Script Accessibility AvailabilityGroupHealth BackupJob BlockedProcesses CacheHitRatio ClusterOwner Connectivity CPUUtil DataSpace DBLocks DBMirrorStatus DBStats ErrorLog LogShipping LogSpace MemUtil MonitorJobs NearMaxConnect NearMaxLocks RunSql ServerDown What It Does Monitors SQL Server database accessibility and raises an event if specified database is not accessible. Monitors the AlwaysOn availability group health status, replica synchronization status, replica failover readiness, and operational status. Monitors SQL Server backup jobs to track data backup activities optimally. Monitors the number of SQL Server processes that have been queued for longer than the period of time you specify. Monitors the percentage at which the requested data page is retrieved from the SQL Server cache without performing physical reads from disk. Determines the node ownership of a SQL Server failover cluster instance or Always On Availability Group. Monitors SQL Server connectivity and raises an event if the server is not available during the monitoring interval. Monitors the percentage of CPU used by SQL Server processes. Monitors the available data space and the percentage of data space used by each database. Monitors the number of locks per SQL Server database and raises an event if the number of locks exceeds the threshold you specify. Monitors the status of each mirrored database. Monitors the percentage of used space for data and log files. Monitors the SQL Server error logs and looks for any error log entries that have appeared since the last monitoring interval. This script also scans the error log entries for any new entries created since the last time it checked. Monitors log shipping status. Monitors the available log space and used log space of a database and raises an event if the available log space falls below the threshold, or if the percentage of log space used exceeds the threshold you specify. Monitors the amount of memory used by SQL Server processes. Reports on any scheduled jobs that have not completed successfully. Monitors the number of used connections compared to the maximum concurrent connections configured for the SQL Server Monitors the used number of locks compared to the maximum available locks configured for the SQL Server. Runs T-SQL statements or stored procedures. Monitors the up or down status of SQL Server and also identifies the downtime of the SQL Server since the server was started. SQL Server Knowledge Scripts 29

30 Knowledge Script TopResourceUsers UserConnections What It Does Monitors the total CPU time used by SQL Server users, the number of IO operations performed, the total number of locks held by all SQL Server users and their connections, and the number of memory pages that can be allocated to all SQL Server users and their connections. Monitors the total number of user connections currently connected to SQL Server and raises an event if the total number of user connections exceeds the threshold you specify. 3.1 Accessibility Use this Knowledge Script to monitor SQL Server database accessibility. This script raises an event if a specified database is not accessible. In addition, this script generates data streams for database accessibility. You can set a timeout to determine how many times the Knowledge Script attempts to connect to a database. NOTE: To run this Knowledge Script, you need public and read-only permission on all the databases that are to be monitored. You can monitor availability group databases on secondary replica only if the Readable Secondary option is configured as Yes for secondary replica. Resource Object SQL Server instance AlwaysOn availability group listener Default Schedule The default interval for this script is Once every hour. Setting Parameter Values Set the following parameters as needed: Description General Settings Job Failure Notification Raise event if job fails unexpectedly? Event severity when job fails unexpectedly Raise event if SQL Server login fails? Event severity when SQL Server login fails Select Yes to raise an event if the SQLServer_Accessibility job fails unexpectedly. The default is Yes. that is raised when the job fails unexpectedly. The default is 5. Select Yes to raise an event if login to SQL sever fails. The default is Yes. that is raised when the login to SQL server fails. The default is SQL Server Knowledge Scripts