AppDynamics Database Visibility User manual

AppDynamics App iQ Platform Documentation:

Database Visibility

Version 4.3.x

Page 1

Database Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Overview of Database Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Database Visibility Requirements and Supported Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Administer the Database Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Prepare to Install the Database Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Install the Database Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Verify the Database Agent Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Upgrade the Database Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Uninstall the Database Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Configure the Database Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Database Agent Configuration Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Enable SSL and SSH for Database Agent Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Monitor SSL-enabled PostgreSQL on Amazon RDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Install the Database Agent as a Windows Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Enable Snapshot Correlation for Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Increasing JVM Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Configure Controller Settings for Database Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Start and Stop the Database Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Start the Database Agent Automatically on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Start the Database Agent Automatically on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Add Database Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Add Database Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Configure IBM DB2 Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Configure Microsoft SQL Server Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Microsoft SQL Server on AWS RDS Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Configure Microsoft Azure Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Configure MongoDB Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Configure MySQL Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Troubleshooting MySQL Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Configure Oracle Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Configure PostgreSQL Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Configure Sybase Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Configure Sybase IQ Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Use the Database Visibility API to Configure Collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Monitor Sybase Databases Using Kerberos Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Configure the Database Agent to Monitor Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Required Monitored Host Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Configure WMI Permissions and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Monitor Databases and Database Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Access Database Visibility from Application Monitoring Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Discover Normal Database and Server Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Monitor Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

View Overall Database and Server Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Database Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Database Topology Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Database Live View Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Database Activity Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Database Queries Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Database Query Details Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Database Query Execution Plan Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Database Clients Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Database Sessions Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Database Schemas and Databases Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Database Modules Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Database Programs Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Database Object Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Monitor Database Server Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Database Health Rules and Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Database Monitoring Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Database Agent Events Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Configure Query Literals Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Configuring Custom Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Page 2

Database Visibility

AppDynamics Database Visibility gives you end-to-end visibility on the performance of your database. Database Visibility helps you troubleshoot problems such as slow response times and excessive load. Database

Visibility provides metrics on database activity, such as:

Which SQL statements or stored procedures are consuming the most system resources

Statistics on procedures, SQL statements, and SQL query plans

How much time is spent fetching, sorting, or waiting on a lock

Activity from the previous day, week, or month

Installation and Administration

Install the Database Agent

Start and Stop the Database Agent

Upgrade the Database Agent

Configuration

Configure the Database Agent

Add Database Collectors

Using Database Visibility

Overview of Database Visibility

Monitor Database Performance

Monitor Database Server Hardware

Reference

Database Agent Configuration Properties

Database Agent Events Reference

Database Monitoring Metrics

Wa tch the

Vid eo

Quick

Overvi ew:

Datab ase

Monito ring

Dashb oards and

Metric s

Copyright © AppDynamics 2012-2017 Page 3

Overview of Database Visibility

Components of Database Visibility

AppDynamics Database Visibility consists of four main components:

1. Database Agent

2. Collector

3. Controller

4. Events Service (on-premises only)

Database Agent

The AppDynamics Database Agent is a standalone Java program that collects performance metrics about your database instances and database servers. One Database Agent can monitor 100 - 200 database instances. To monitor 100+ database instances,

increase the initially allocated heap size for the Database Agent JVM.

You can deploy the Database Agent on any machine running Java 1.7 or higher. The machine must also have network access to the

AppDynamics Controller and the database instance that you want to be monitored.

Collector

The Database Agent Collector is the process that runs within the Database Agent to collect performance metrics about your database instances and database servers. One Collector collects metrics for one database instance. Multiple collectors can run in one Database

Agent.

Each database server that you monitor requires one license. For SQL Server, you can monitor many database instances with one license.

AppDynamics Database Visibility detects when a database backend has matching credentials with a database server being monitored by a Collector. Database Visibility automatically associates the backend with the collector, so you can view its performance with the

Application Flow Map, Tier Flow Map, or Node Flow Map.

Controller

The Controller is the central interface where you can see all your database instance and database server performance metrics.

The following types of information are sent to the Controller:

Database-level metrics, such as number of queries processed and other database statistics

Names and attributes of all sessions, clients, queries, and other objects on the monitored system

Events Service

If you are using the on-premises version of Database Visibility, you must install the Events Service , which stores high volumes of metric data.

The following types of information are sent to the Events Service:

The time each query spends in each wait state

Individual query statistics for databases that support it

Information about individual execution plans in databases that support it

Copyright © AppDynamics 2012-2017 Page 4

Copyright © AppDynamics 2012-2017 Page 5

Database Visibility Requirements and Supported Environments

On this page:

Systems that AppDynamics Database Visibility Supports

AppDynamics Pro Controller Sizing Requirements

Software Requirements

Network Requirements

Related pages:

Add Database Collectors

Database Visibility

Systems that AppDynamics Database Visibility Supports

Once Database Visibility is available, you can create collectors that run on the Database Agent to monitor any of the following systems:

System

Category

System

Type

Databases

MongoDB,

MongoDB cluster

MySQL

Microsoft

SQL Server yes yes

Supported via

Amazon

RDS

Version

2.2 and higher all versions including Percona and MariaDB

2005, 2008, 2012, 2014, 2016 and SQL Azure

SQL Server on Linux is currently available as a public preview, and is not recommended for production use. Database Visibility works correctly with this preview release, but until a stable version of SQL Server on Linux is available, monitoring results may vary.

10g, 11g, and 12c

Microsoft

SQL Server on Linux

Oracle,

Oracle RAC yes

PostgreSQL yes

IBM DB2

LUW

Sybase

ASE

Hardware

Monitoring

Sybase IQ

Windows

Linux

Solaris

AIX

Amazon

RDS all versions

9.x, 10.x, 11.x

15+

32-bit (will also work on 64-bit systems)

32-bit and 64-bit all versions

To avoid metric value errors, use a 64-bit JRE with the 64-bit operating system.

Copyright © AppDynamics 2012-2017 Page 6

If you use a third-party application along with Database Visibility to monitor Sybase, the data displayed in the controller may not display correctly. For accurate metrics, it is recommended that you do not use both a third-party application and Database

Visibility to monitor Sybase.

Agent Hardware Requirements

Hardware requirements vary depending on database activity. If your database activity increases, you may need to adjust your initial hardware configuration.

The machine running the Database Agent should meet following hardware requirements:

1 GB of heap space and an additional 256 MB of heap space for each collector. When monitoring production databases, the heap usage per collector may reach 512 MB.

500 MB of disk space per collector per day

500 MB of disk space for the Events Service per day. By default, the Events Service retains data for 10 days.

2 GHz or higher CPU

Examples of heap space allocation:

Monitoring 5 databases instances requires ( 5 x 256 MB ) + 1024 MB = 2,304 MB

Monitoring 20 database instances requires ( 20 x 256 MB ) + 1024 MB = 6,144 MB

Monitoring 100 database instances requires ( 100 x 256 MB ) + 1024 MB = 26,624 MB

AppDynamics Pro Controller Sizing Requirements

For information on additional hardware requirements for the AppDynamics Controller to support Database Visibility, see Controller

System Requirements .

Start the Controller Events Service

The Database Agent requires the Controller Events Service , which must be started before starting the agent.

Software Requirements

The Database Agent runs on a Java Virtual Machine. You must have Java 1.7 or 1.8.

The operating systems Linux and Windows are supported

Network Requirements

The machine on which the database is running or the machine you want to monitor must be accessible from the machine where the Database Agent is installed and running. This machine must have a network connection, internet or intranet.

If your databases are behind a firewall, you must configure the firewall to permit the machine running the Database Agent program access to the databases. The database listener port (and optionally the SSH or WMI port) must be open.

The network bandwidth used between the agent and the controller is approximately 300kb/min per collector for a large database with 200 clients using 50 schemas, processing about 10,000 queries a minute. The actual numbers depend on the type of database server, the number of individual schemas on the server, and the number of unique queries executed daily, and will therefore vary.

Copyright © AppDynamics 2012-2017 Page 7

Administer the Database Agent

On this page:

Using Multiple Agents

Related pages:

Database Visibility

Database Agent Configuration Properties

Add Database Collectors

Start the Database Agent Automatically on Linux

Start the Database Agent Automatically on Windows

To start monitoring your database, you must first install the Database Agent. The Database Agent is a standalone Java program that collects performance metrics about your database instances and database servers. You can then view these metrics in the Metric

Browser of the AppDynamics Controller UI.

Using Multiple Agents

You may want to install multiple agents for the following reasons:

You have databases on multiple networks that are not accessible by one machine.

You have multiple SQL Server instances that each require different credentials, and you want to connect to them via Windows

Authentication.

You want one or more agents to back up a primary agent. Backup agents ensure that your database instances are continually monitored during agent failure or machine downtime.

Copyright © AppDynamics 2012-2017 Page 8

Prepare to Install the Database Agent

On this page:

Prerequisites for Installing the Agent

Controller Communication Information

Watch the Video

Related pages:

Database Visibility

Database Agent Configuration Properties

Add Database Collectors

Start the Database Agent Automatically on Linux

Start the Database Agent Automatically on Windows

Prerequisites for Installing the Agent

Ensure that your environment meets the following requirements

Java 1.7 or 1.8

The machine that you install the agent on has network access to the databases that you want to monitor.

Controller Communication Information

If you are installing using the Database Agent downloaded from the Getting Started Wizard, the Controller communications information is already configured for you in the agent controller-info.xml file.

To complete the Getting Started Wizard - Databases , you need the following information:

Controller Host Name

Controller Port Number

If you are installing using the agent installation zip file downloaded from the AppDynamics portal, you need the following information:

Controller Host Name

Controller Port Number

Account Access Key

See Agent-to-Controller Connections .

Watch the Video

Start Monitoring Databases

Copyright © AppDynamics 2012-2017 Page 9

Install the Database Agent

On this page:

Install the Agent Software

License the Agent (on premise only)

Configure the Agent

Start the Controller Events Service (on-prem only)

Launch the Database Agent using System Properties

Related pages:

Database Visibility

Database Agent Configuration Properties

Add Database Collectors

Enable SSL and SSH for Database Agent Communications

Start the Database Agent Automatically on Linux

Start the Database Agent Automatically on Windows

Follow the procedure below to manually install the Database Agent. You can alternatively follow the steps in the Download & Install

Wizard, which simplifies this process.

To avoid permission issues, you should install the agent as the same user who owns the Database Agent or as an administrator on the host machine. To run the Database Agent, you must have write privileges to the logging output directory and to the conf directory, which is located in the agent installation directory.

Install the Agent Software

1. Download the version of the installation package that is appropriate for your OS environment from the AppDynamics

Download Center ( http://download.appdynamics.com

).'

2. Extract the zip file to the destination directory. Do not use spaces in the agent installation destination directory.

3. Log on as an administrator to the machine where you will be installing the Database Agent.

Windows

Double-click the dbagent-x.x.x.zip > you extract it as follows: Right-click on the zip file, select Properties , and choose unblock .

Linux

Enter the following on the command line: unzip dbagent-x.x.x.zip -d <db_agent_home>

Running Multiple Database Agents

You can have multiple Database Agents concurrently running the agent jar in the <db_agent_home> directory on the same machine. Some system properties may be required depending on how you'll be using the agents.

License the Agent (on premise only)

Obtain a license.lic file with Database Monitoring licensing from your sales or support representative and put the license file in the directory where you installed the Controller. After placing the license in the directory, the Controller may take a minute or two to detect the new license. Restarting the Controller forces it to detect new licenses.

Copyright © AppDynamics 2012-2017 Page 10

Configure the Agent

You can configure properties

for the Controller host name, port number, and account access key using either the

<db_agent_home>/conf/controller-info.xml file or by adding system properties to the Database Agent startup script.

Controller Host Name

Configure using controller-info.xml: <controller_host>

Configure using System Properties : -Dappdynamics.controller.hostName

Required : Yes

Default : None

Controller Port

Configure using controller-info.xml: <controller_port>

Configure using System Properties : -Dappdynamics.controller.port

Required : Yes

Default : For On-premise Controller installations: Port 8090 for HTTP and 8181 for HTTPS communication.

For SaaS Controller service: Port 80 for HTTP and port 443 for HTTPS communication.

Account Access Key

Configure using controller-info.xml: <account_access_key>

Configure using System Properties : -Dappdynamics.agent.accountAccessKey

Required : Yes

Default : None

Optional Configurations:

Configure the agent to use SSL, see

Enable SSL for Communicating with the Controller .

Configure the agent to use Proxy Settings, see Proxy Settings for the Controller

.

Configure the agent to run automatically when the Machine starts on

Linux or

Windows .

Configure the agent to uniquely identify itself to the Controller, such as when you require multiple agents. See

Multiple Agent

Environment Properties

.

Configure the agent to act as a backup to another Database Agent. See

Multiple Agent Environment Properties

.

Configure the logging level of the Database Agent running on the agent JVM. The attached log file shows an example of the agent log file when the agent logging is set to INFO level. This is the default. The log files are in <db_agent_home>\logs.

Start the Controller Events Service (on-prem only)

Linux

% <controller_home>/bin/controller.sh start-events-service

Windows

C:\<controller_home>\bin\controller.bat start-events-service

Launch the Database Agent using System Properties

The following assumes that all the necessary parameters have been specified in the controller-info.xml.

Launch Command Examples

Linux

% java -Ddbagent.name='Scarborough Network Database Agent' -jar <db_agent_home>/db-agent.jar

Copyright © AppDynamics 2012-2017 Page 11

Windows 64-bit

C:\java -Djava.library.path="<db_agent_home>\auth\x64" -Ddbagent.name="Scarborough Network Database

Agent" -jar <db_agent_home>\db-agent.jar

Systems Properties

Database Agent Name

Configure using System Properties -Ddbagent.name=<db_a gent_name >

Type: ASCII string, including spaces. If <db_agent_name> contains spaces, you must enclose the entire name in double quotes (" ")

for Windows and single quotes (' ') for Linux.

Required : Yes, when you have multiple agents reporting to the same controller.

Default : Default Database Agent

Java Library Path

: -Djava.library.path=<db_agent_home>\auth\x64

Type: ASCII string, including spaces. If <db_agent_home> contains spaces, you must enclose the entire name in double quotes (" ").

Required : Yes, for Windows only

Specify :

For 64-bit systems: <db_agent_home>\auth\x64

For 32-bit systems: <db_agent_home>\auth\x86

Increase the JVM Memory

To monitor 100 or more databases, you may need to increase the JVM memory allocation size. Increased activity on the databases you are monitoring results in increased memory usage.

On Linux, use this command to start the agent, and to initially allocate 256 MB to the agent instead of the default of 64 MB.

For Windows 64-bit

C:\java -Xmx256m -Djava.library.path="<db_agent_home>\auth\x64" -jar

<db_agent_home>\db-agent.jar

Copyright © AppDynamics 2012-2017 Page 12

Verify the Database Agent Installation

On this page:

Check the Agent Logs

Verify that the Agent is Reporting to the Controller

Verify that the Agent is Running

Related pages:

Database Agent Configuration Properties

Agent and Controller Compatibility

Check the Agent Logs

After a successful install, your agent logs, located at <db_agent_home>/logs, should contain the following message:

Started AppDynamics Database Agent Successfully

If the agent log file is not present, the Database Agent may not be accessing the Database Agent command properties. To troubleshoot, check the application server log file where STDOUT is logged. It will have the fallback log messages, useful for troubleshooting the agent.

Verify that the Agent is Reporting to the Controller

1. Click Settings > AppDynamics Agents .

2. Click the Database Agents tab.

Here, you should see a listing for each Database Agent reporting to the Controller. An agent can have one of the following statuses:

Active: The agent is running

Passive: The agent is used as a backup for active agents

If you don't see the Database Agent, check your controller-info.xml properties to ensure they have specified the correct host properties.

Verify that the Agent is Running

Use the following command to verify that the agent process is running:

Linux:

ps -ef | grep DBAgent

Windows:

1. Open a command line console.

2. Start the Task Manager and click the Processes tab.

3. The agent process should be running. If it is not running, stop and restart the agent.

Copyright © AppDynamics 2012-2017 Page 13

Upgrade the Database Agent

On this page:

Important Upgrade Notes

Stop the Agent

Back up the Existing Agent Directory

Install the Agent

Copy the controller-info.xml File

Start the New Agent

Verify the Database Agent Installation

Related pages:

Database Agent Configuration Properties

Agent and Controller Compatibility

Important Upgrade Notes

If you are upgrading the Controller and agents, first upgrade the Controller and then upgrade the Database Agents.

Shut down the Database Agent process before you install the new agent.

All Database Agents that are running from the same install location need to be shut down when updating that install location.

Download the installation package that is appropriate for your OS environment from the AppDynamics Download Center

(https://appdynamics.com/download) .

Back up the <db_agent_home> directory so you can revert to the previous installation if required. To maintain the same configuration information, you will also need the <db_agent_home>\conf\controller-info.xml file.

If both the old and new agents are 4.2 or newer, you can keep the old agent running while installing the new agent, allowing you to upgrade the agent with no downtime. Once you see the new agent showing up as "ACTIVE" in the agents page in the controller, stop the old agent.

Stop the Agent

Stop the agent as described f or your specific installation in

Start and Stop the Database Agent .

Back up the Existing Agent Directory

Make a copy of the existing agent directory, <db_agent_home>. Backing up allows you to revert to the previous agent installation if you need to. You can also copy over the controller-info.xml configuration file to the new installation to ensure the agent configuration is maintained.

Install the Agent

Install the Database Agent as described f or your specific installation in

Administer the Database Agent

.

Copy the controller-info.xml File

To ensure the agent configuration is maintained, copy the <backup_db_agent_home>\conf\controller-info.xml file to the new installation directory, <db_agent_home>\conf.

Start the New Agent

See

Start and Stop the Database Agent .

Verify the Database Agent Installation

Copyright © AppDynamics 2012-2017 Page 14

See

Verify the Database Agent Installation

.

Copyright © AppDynamics 2012-2017 Page 15

Uninstall the Database Agent

Related pages:

Administer the Database Agent

Database Agent Configuration Properties

Manage App Agents

If you delete a Database Agent from the Controller UI, but do not shut down the JVM that the Database Agent runs on, the Database

Agent will reappear in the UI the next time the Controller polls the agent.

To prevent a Database Agent from connecting to the Controller, ensure it doesn't start up. This frees the license associated with the agent in the Controller and makes it available for use by another Database Agent.

In most cases, uninstalling the Database Agent simply requires deleting the installation directory. However, if you have installed the agent as a service, you must also remove the service as described below.

In all cases you must first

stop the Database Agent service.

After removing the service, delete the agent installation directory.

Copyright © AppDynamics 2012-2017 Page 16

Configure the Database Agent

Once you have installed and launched the Database Agent, you can further customize the agent.

Database Agent Configuration Properties

Enable SSL and SSH for Database Agent Communications

Install the Database Agent as a Windows Service

Enable Snapshot Correlation for Oracle

Increasing JVM Memory

Copyright © AppDynamics 2012-2017 Page 17

Database Agent Configuration Properties

On this page:

Where to Configure Database Agent Properties

Example Database Agent controller-info.xml File

Example Startup Configuration Using System Properties

Database Agent Properties

Required System Properties

Optional System Properties

Agent-Controller Communication Properties

Multiple Agent Environment Properties

Proxy Properties for the Controller

Other Properties

Related pages:

Administer the Database Agent

Where to Configure Database Agent Properties

You can configure agent properties in the following locations:

The controller-info.xml file located in the <db_agent_home> /conf directory

The system properties (-D options) section in the JVM start-up script: java -D<db_agent_system_properties> -jar <db_agent_home>/db-agent.jar

You can only configure agent properties related to naming agents or designating them as backup partners on the command line or in the JVM start-up script. However, you can specify the Controller/Agent connection details in the controller-info.xml file.

The system properties override the settings in the controller-info.xml file. System properties are case-sensitive.

Example Database Agent controller-info.xml File

<?xml version="1.0" encoding="UTF-8"?>

<controller-info>

<controller-host>192.10.10.10</controller-host>

<controller-port>8090</controller-port>

<account-access-key>165e65645-95c1-40e3-9576-6a1424de9625</account-a ccess-key>

<!-- The following attribute enables or disables SSL communications between the agent and the Controller.-->

<controller-ssl-enabled>false</controller-ssl-enabled>

<!-- The following account-related parameters are necessary only for

SaaS installations-->

<!--account-name></account-name-->

</controller-info>

Copyright © AppDynamics 2012-2017 Page 18

Example Startup Configuration Using System Properties

A bash example. Note that the system properties are case-sensitive.

-Dappdynamics.controller.hostName=192.168.1.20

-Dappdynamics.controller.port=8090

Database Agent Properties

This section describes the Database Agent configuration properties, including their controller-info-xml elements and their system property options.

Required System Properties

Path to the Agent jar File

Description : Provides the absolute path to sqlijdbc_auth.dll.

System Property: -jar

Value: <db_agent_home>db-agent-jar

Type: If <db_agent_name> contains spaces, you must enclose the entire name in double quotes (" ") on Windows and single quotes ('

') on Linux .

Required: Yes

Example : -jar="D:\AppDynamics\Database Agent\db-agent.jar"

Path to the Java Library

Description : Provides the absolute path to sqlijdbc_auth.dll.

System Property: -Djava.library.path

Value:

For 64-bit systems: <agent_home>\auth\x64

For 32-bit systems: <agent_home>\auth\x32

Type: If <db_agent_name> contains spaces, you must enclose the entire name in double quotes (" ") on Windows and single quotes ('

') on Linux.

Required : Recommended. Required for SQL Server Windows Authentication on Windows 64-bit systems.

Example : -Djava.library.path="D:\AppDynamics\Database Agent\auth\x64"

Optional System Properties

Disable Retry on Auth Failure

Description : Stops retrying to establish JDBC connection when JDBC authentication fails.

System Property: -Dretry.on.auth.failure=false

Default: The system property is set to true.

Type: String

Supported Locales for Parsing Numbers

Copyright © AppDynamics 2012-2017 Page 19

Description : Specifies which locale to use for parsing numbers. See Java 7 Supported Locales or Java 8 Supported Locales for valid values. Use the values for the Java version that you are running in your environment.

System Property : -Ddbagent.language

Default: The system property is set to en-US or en_US.

Type: String

Agent-Controller Communication Properties

Controller Host Property

Description: This is the host name or the IP address of the AppDynamics Controller, e.g. 192.168.1.22 or myhost or myhost.abc.com.

This is the same host that you use to access the AppDynamics Controller UI.

Element in controller-info.xml: <controller-host>

System Property: -Dappdynamics.controller.hostName

Type: String

Default: None

Required: Yes

Controller Port Property

Description: This is the HTTP(S) port of the AppDynamics Controller. This is the same port that you use to access the AppDynamics browser-based user interface. If the Controller SSL Enabled property is set to true, specify the HTTPS port of the Controller; otherwise specify the HTTP port. See Controller SSL Enabled Property .

Element in controller-info.xml: <controller-port>

System Property: -Dappdynamics.controller.port

Type: Positive Integer

Default: For on premises installations, port 8090 for HTTP and port 8181 for HTTPS are the default ports the Controller listens to.

For the SaaS Controller Service, port 80 for HTTP and port 443 for HTTPS are the default ports the Controller listens to.

Required: Yes

Account Access Key Property

Description: This is the account access key used to authenticate with the Controller.

Element in controller-info.xml: <account-access-key>

System Property: -Dappdynamics.agent.accountAccessKey

Type: String

Default: None

Required: Yes. Prior to version 4.1, this property was required only for SaaS and multi-tenant Controllers. The account access key property is now required to authenticate all agent to Controller communications.

Example: -Dappdynamics.agent.accountAccessKey=165e65645-95c1-40e3-9576-6a1424de9625

Multiple Agent Environment Properties

The following properties are useful when you are configuring your system to include more than one Database Agent.

Database Agent Name Property

Description: This property uniquely identifies the Database Agent to the Controller.

System Property: -Ddbagent.name=<db_agent_name>

Type: ASCII string, including spaces. If <agent_name> contains spaces, you must enclose the entire name in double quotes (" ").

Copyright © AppDynamics 2012-2017 Page 20

Default: Default Database Agent

Required: Required when you have more than one Database Agent reporting to the Controller.

You may want to run multiple Database Agents under the following conditions:

When you have databases spread across multiple networks, and one machine cannot access all the databases on all the networks. In this case you can have a uniquely named Database Agent in each network that monitors the databases only visible on that network.

If you have multiple SQL Server instances that each require different credentials, and you want to connect to them via

Windows Authentication. When using Windows Authentication, the Database Agent will use the credentials of the currently logged in user.

When you want one or more agents to back up a primary agent. The database agent names for your backup agents must match the database agent name of your primary agent. The last agent you launch will be the primary agent.

Example: -Ddbagent.name="Scarborough Network Database Agent"

Multi-Tenant Mode Properties

If the AppDynamics Controller is running in multi-tenant mode or if you are using the AppDynamics SaaS Controller, specify the account name and account access key for this agent to authenticate with the Controller.

If the Controller is running in single-tenant mode (the default) there is no need to configure these values.

Account Name Property

Description: This is the account name used to authenticate with the Controller.

If you are using the AppDynamics SaaS Controller, the Account Name is in the Welcome email AppDynamics sent to you.

Element in controller-info.xml: <account-name>

System Property: -Dappdynamics.agent.accountName

Type: String

Default: None

Required:

Yes for AppDynamics SaaS Controller and other multi-tenant users

No for single-tenant users.

Proxy Properties for the Controller

These properties route data to the Controller through a proxy.

Proxy Host Property

Description: This is the proxy host name or IP address.

Element in controller-info.xml: Not applicable

System Property: -Dappdynamics.http.proxyHost

Type: String

Default: None

Required No

Proxy Port Property

Description: This is the proxy HTTP(S) port.

Element in controller-info.xml: Not applicable

System Property: -Dappdynamics.http.proxyPort

Type: Positive Integer

Copyright © AppDynamics 2012-2017 Page 21

Default: None

Required: No

Other Properties

Controller SSL Enabled Property

Description: This property specifies whether the agent should use SSL (HTTPS) to connect to the Controller. If SSL Enabled is true, set the Controller Port property to the HTTPS port of the Controller. See Controller Port Property .

Element in controller-info.xml: <controller-ssl-enabled>

System Property: -Dappdynamics.controller.ssl.enabled

Type: Boolean

Default: False

Required: No

Sybase Disabled Property

Description: This property specifies whether the agent should disable Sybase. You may want to disable Sybase monitoring with

Database Visibility if you are already using other tools to monitor Sybase. Refer to

Sybase Database Permissions

for information on configuring Sybase permissions.

Element in controller-info.xml: Not applicable

System Property: -Ddbagent.disable.sybase.ase.system.monitoring

Type: Boolean

Default: False

Required: No

Copyright © AppDynamics 2012-2017 Page 22

Enable SSL and SSH for Database Agent Communications

On this page:

Enable SSL for the Database Agent

Enable SSH for the Database Agent

Enable SSL for the Database Agent

This topic covers how to configure the Database Agent to connect to the Controller using SSL. It assumes that you use a SaaS

Controller or have configured the on premise Controller to use SSL.

The Database Agent supports extending and enforcing the SSL trust chain when in SSL mode.

Requirements

Gather the following information:

The Controller SSL port.

For SaaS Controllers the SSL port is 443.

For on premises Controllers the default SSL port is 8181, but you may configure the Controller to listen for SSL on another port.

The signature method for the Controller's SSL certificate:

A publicly known certificate authority (CA) signed the certificate. This applies for DigiCert, Verisign, Thawte, and other commercial CAs.

A CA internal to your organization signed the certificate. Some companies maintain internal certificate authorities to manage trust and encryption within their domain.

The Controller uses a self-signed certificate.

Establish Trust for the Controller's SSL Certificate

To establish trust between the Database Agent and the AppDynamics Controller, you must create an agent truststore that contains the root certificate for the authority that signed the Controller's certificate.

If you secured your on premises Controller with a self-signed certificate, see

Keystore Certificate Extractor Utility

for instructions to create the agent keystore.

1. Obtain one of the following root certificates:

DigiCert Global Root CA for the AppDynamics SaaS Controller the root certificate for the publicly known certificate authority (CA) that signed the certificate for your on premises

Controller the root certificate for the internal CA that signed the Controller certificate for your on premises Controller

2. Run the Java keytool command to create the Database Agent truststore:

keytool -import -alias rootCA -file <root_certificate_file_name>

-keystore cacerts.jks -storepass <truststore_password>

For example:

Copyright © AppDynamics 2012-2017 Page 23

2.

keytool -import -alias rootCA -file

/usr/home/appdynamics/DigicertGlobalRootCA.pem -keystore cacerts.jks -storepass MySecurePassword

Make note of the truststore password, you need it to configure the Database Agent.

3. Install the agent truststore to the Database Agent configuration directory:

<db_agent_home>/conf/

Secure the Database Agent Truststore

AppDynamics recommends you take the following security measures to prevent tampering with the Database Agent truststore:

Secure the truststore file through file system permissions:

Make the Database Agent truststore readable by any user.

Make the truststore owned by a privileged user.

Make the truststore writable only by the specified privileged user.

Secure the Database Agent configuration files so that they are only readable by the agent runtime user and only writable by a privileged user:

Global configuration file: <db_agent_home>/conf/controller-info.xml.

Configure SSL System Properties for the Database Agent

1. Configure the following system properties in the versioned controller-info.xml: <db_agent_home>/<version_number>/conf/controller-info.xml. See "SSL Configuration Properties" on

Data base Agent Configuration Properties

for full details on each property.

Controller Port: the SSL port for the controller. 443 for AppDynamics SaaS.

<controller-port>443</controller-port>

Controller SSL Enabled: true.

<controller-ssl-enabled>true</controller-ssl-enabled>

Controller Keystore Password: the plain text password for the Database Agent truststore.

<controller-keystore-password>MySecurePassword</controller-keystore-password>

Controller Keystore Filename: path of the Database Agent truststore relative to <db_agent home>/<version>/conf.

Required if you use a truststore other than the default <db_agent_home>/<version_number>/conf/cacerts.jks.

<controller-keystore-filename> ../../conf/cacerts.jks

</controller-keystore-filename>

You can specify the Controller port and enable SSL for the Controller in the JVM startup script, but you must specify the truststore password and filename in the controller-info.xml file.

2. Save your change to the controller-info.xml file and restart the Database Agent.

Sample SSL controller-info.xml configuration

Copyright © AppDynamics 2012-2017 Page 24

<?xml version="1.0" encoding="UTF-8"?>

<controller-info>

<controller-host>mycompany.saas.appdynamics.com</controller-host>

<controller-port>443</controller-port>

<controller-ssl-enabled>true</controller-ssl-enabled>

<controller-keystore-password>MySecurePassword</controller-keystore-pass word>

<controller-keystore-filename>../../conf/cacerts.jks</controller-keystor e-filename>

...

</controller-info>

Keystore Certificate Extractor Utility

The Keystore Certificate Extractor Utility exports certificates from the Controller's Java keystore for the Database Agent truststore. It installs to the following location:

<agent_home>/utils/keystorereader/kr.jar

To avoid copying the Controller keystore to a Database Agent machine, you can run this utility from the Controller server. Access the agent distribution on the Controller at the following location:

1. Run the Keystore Certificate Extractor Utility from the Controller as follows:

% java - jar

<controller_home>/appserver/glassfish/domains/domain1/appagent/<cont roller_version>/utils/keystorereader/kr.jar

2. Enter the following when prompted:

The full path to the Controller's keystore:

Enter input keystore:

<controller_home>/appserver/glassfish/domains/domain1/config/ke ystore.jks

The truststore output file name. By default the Database Agent looks for cacerts.jks.

Copyright © AppDynamics 2012-2017 Page 25

2.

Enter output agent truststore file name:

<controller_home>/appserver/glassfish/domains/domain1/config/ke ystore.jks

The password for the Controller's certificate, which defaults to "changeit". If you don't include a password, the extractor applies the password "changeit" to the output truststore.

Example command to execute kr.jar

java -jar kr.jar

<controller_home>/appserver/glassfish/domains/domain1/config/ke ystore.jks cacerts.jks <controller_certificate_password>

3. Install the agent trust store to the agent configuration directory:

<db_agent_home>/conf/

Enable SSH for the Database Agent

For Linux hosts only

Applies only when Database Agent is running on a Linux host.

When the Database Agent is running on Linux and you want to monitor hardware, except to monitor the local host, authentication is required and a password is passed between the Database Agent and the database server.

SSH port option

The SSH port option does not appear unless the Database Agent is running on Linux.

1. Generate the rsa or dsa key as follows:

Copyright © AppDynamics 2012-2017 Page 26

1.

Generate rsa key

% ssh-keygen -b 1024 -f id_rsa -t rsa

or

Generate dsa key

% ssh-keygen -b 1024 -f id_dsa -t dsa

This will create a rsa or dsa, 1024-bit key and put the keys into /home/<user_name>/.ssh/id_rsa and

/home/<user_name>/.ssh/id_rsa.pub or /home/<user_name>/.ssh/id_dsa' and /home/<user_name>/.ssh/ida_dsa.pub' files. Do not change the names of these files.

2. Copy the private key, /home/<user_name>/.ssh/id_rsa or /home/<user_name>/.ssh/id_id_dsa into the <db-agent_home>/keys directory.

3. Verify that you have the correct permissions on the .ssh directory, or set them as follows:

.ssh directory permissions

% cd /home/<user_name>

% chmod 755 .ssh

4. Verify that you have a /home/<user_name>/.ssh/authorized_keys file. If you do not have this file, create the authorized_keys file as follows:

Copyright © AppDynamics 2012-2017 Page 27

4.

Create authorized_keys file

% cd /home/<user_name>/.ssh

% touch .ssh/authorized_keys

5. Verify that you have the correct permissions to the /home/<user_name>/.ssh/authorized_keys file, or change the permissions as follows:

authorized_keys file permissions

% cd /home/<user_name>/.ssh

% chmod 644 authorized_keys

6. Append (do not copy) the file 'id_rsa.pub' or the file 'id_dsa.pub' to the file, /home/<user_name>/.ssh/authorized_keys, such as follows:

Append rsa public key to authorized key

% echo /home/<user_name>/.ssh/id_rsa.pub

>> /home/<user_name>/.ssh/authorized_keys

or

Copyright © AppDynamics 2012-2017 Page 28

6.

Append dsa public key to authorized key

% echo /home/<user_name>/.ssh/id_dsa.pub

>> /home/<user_name>/.ssh/authorized_keys

7. If you are using a dsa key, append the contents of /home/<user_name>/.ssh/id_dsa.pub to the ~/.ssh/authorized_keys file on the machine running AppDynamics Pro.

8. The SSH port of the database Collector is set to 22 by default. You can change it by navigating to the Monitoring Hardware section of the Collector configuration dialog. In the dialog, set the SSH port to the port your require.

9. Save your change to the Collector configuration and restart the Database Agent.

Enable SSH via PEM certificate

For Linux, AppDynamics also supports certificate-based authentication via Privacy Enhanced Mail (PEM). To implement certificate-based authentication:

1. Enable the Use certificate option in the Monitoring hardware section of the Collector configuration dialog.

2. Copy the PEM file to the <db_agent_home>/keys directory. Note, if the home/<user_home>/.ssh directory exists, the agent will use the certificate found there.

3. Restart the agent.

Copyright © AppDynamics 2012-2017 Page 29

Monitor SSL-enabled PostgreSQL on Amazon RDS

If your PostgreSQL instance uses SSL connections, you must complete the following steps to monitor it.

1. Download PEM file from Amazon and copy to a local directory.

2. Convert the PEM file to a DER file using the following openssl command:

openssl x509 -outform der -in rds-combined-ca-bundle.pem -out rds-combined-ca-bundle.der

3. Add the certificate to the Java keystore using the following command:

sudo keytool -import -noprompt -trustcacerts -alias AmazonRDS -file rds-combined-ca-bundle.der -keystore

$JAVA_HOME\jre\lib\security\cacerts -storepass changeit

You can verify that the certificate was added by running the following command:

keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts

-storepass changeit

4. Re-start the dbagent process to register the certificate you added.

5. In the Controller, create a new collector for PostgreSQL. In the Custom JDBC Connection String field, enter the following JDBC string: jdbc:postgresql://<RDS-Hostname>:<RDS-Port>/postgres?ssl=true

Copyright © AppDynamics 2012-2017 Page 30

Install the Database Agent as a Windows Service

On this page:

Install the Database Agent as a Windows Service - Pre Windows 2008

Install the Database Agent as a Windows Service - Windows 2008 and 2012

Uninstall the Database Agent as a Service

Known Issues

Running the Agent on Windows Using the Task Scheduler

Related pages:

Administer the Database Agent

Database Agent Configuration Properties

Database Visibility

Most Windows server software runs as a service when the machine boots up. To secure your environment and ensure Database

Agent availability, you can install the Database Agent as a Windows service using the SRVANY.EXE and SC.EXE utilities that are part of the Microsoft Resource Kit for Windows 2003 Server . The SRVANY.EXE

tool creates a Windows service that launches the JVM processes for the agent in non-GUI mode using parameters specified in the registry of the service. The SC.EXE command is used to install and uninstall the agent service.

Install the Database Agent as a Windows Service - Pre Windows 2008

The following procedure involves editing the registry. Before proceeding, know how to backup and restore the registry as described in the WIndows Registry Editor online help.

1.

Install the agent as usual, described in Install the Database Agent

.

2. Obtain the INSTSRV.EXE and SC.EXE utilities.

Download the Windows Server 2003 Resource Kit Tools , at http://www.microsoft.com/en-us/download/details.aspx?id=17657 .

The required utilities are included in this resource kit

3. Prepare registry and batch command files.

To simplify service creation and deregistration, we have attached two batch command files, InstallService.cmd and

UninstallService.cmd to this page. InstallService.cmd requires the information in the DatabaseAgent.reg file to set the registry key for the service.

DatabaseAgent.reg

to set the registry key values for the service

InstallDBService.cmd

to install the service

UninstallDBService.cmd

to uninstall the service

Download these files and edit them as indicated below. Specify the same service name in all three files.

a. Customize DatabaseAgent.reg.

Edit the service name, Application, AppParameters, and AppDirectory values of this file for your environment.

Specify the service name is specified on the first line of this file.

AppDynamics Database Agent Service in the sample attached.

Application is the path to the JDK you use for Database Agent.

<db_agent_home> \\jre7\\bin\\java.exe

in the sample attached. The Database Agent is compatible with JRE 1.7 and 1.8

AppParameters is everything you want to pass to the JVM as arguments.

For a 32-bit system, set java.library.path="<db_agent_home>\auth\x32", the absolute path

For a 64-bit system, set java.library.path="<db_agent_home>\auth\x64", the absolute path

If your agent will be monitoring more than 100 databases, increase the size of the initial memory allocation specified in the code example below as follows:

change -Xmx32m to -Xmx256m

Copyright © AppDynamics 2012-2017 Page 31

3. a.

For 64-bit systems, allocating 32 MB of initial heap size java -Djava.library.path="<db_agent_home>\auth\x64"

-Xms32m -jar "<agent_home>\db-agent.jar"

AppDirectory points to the agent working directory, the location where you installed the Database

Agent.

<agent_home> .

b. Customize InstallDBService.cmd.

Edit the create and binPath values in this file for your environment.

Specify the service name in quotes in the sc command create option as follows: sc create "AppDynamics Database Agent Service" in the sample attached.

Specify binPath as the path to the SRVANY.EXE Windows Resource

<agent_home>\srvany.exe in the sample attached

The service installed runs with the permissions of the user logged in when service is created. To change the user running the installed process, modify InstallService.cmd by inserting the following anywhere before "pause" at the end of the file.

sc config <service> obj= <username> password= <password>

Note: There is a required space between obj= and <username> .

c. Customize UninstallDBService.cmd

UninstallDBService.cmd - Uninstalls the Database Agent Service

@echo off rem UnInstall AppDynamics Database Agent Service echo "Stopping AppDynamics Database Agent Service - may be running" sc stop "AppDynamics Database Agent Service" echo "Uninstalling AppDynamics Database Agent Service from the

Service Manager" sc delete "AppDynamics Database Agent Service" echo "done." pause

d. Specify the name of the service in quotes after the sc stop or delete options.

"AppDynamics Database Agent Service" in the sample file attached.

4. From the Windows Explorer, right-click InstallDBService.cmd and click Run as Administrator .

Copyright © AppDynamics 2012-2017 Page 32

Install the Database Agent as a Windows Service - Windows 2008 and 2012

Download NSSM - the Non-Sucking Service Manager .

Create a start.bat file containing your agent startup script, such as: java -Djava.library.path="<agent_home>\auth\x64" -jar "<agent_home>db-agent.jar" where <agent_home> is where you installed the Database Agent.

Note that if the agent configuration property values contain spaces, you must enclose the entire name in double quotes (" "). For example,

Windows, 64-bit system with 256 MB initial memory allocation

java -Djava.library.path="<db_agent_home>\auth\x64" -Ddbagent.name="Scarb orough Network Database Agent"

-Dappdynamics.agent.uniqueHostId="Scarborough Network Database Agent

Host" -jar "<db_agent_home>\db-agent.jar"

For a 32-bit system, set java.library.path="<db_agent_home>\auth\x32" as the absolute path

For a 64-bit system, set java.library.path="<db_agent_home>\auth\x64" as the absolute path

If your agent will be monitoring more than 100 databases, increase the size of the initial memory allocation specified in the code example below as follows:

change -Xmx32m to -Xmx256m

Add the path to nssm.exe to your Path environment variable.

Start a command shell and enter the following: nssm.exe install <service name> where <service name> is the name of the agent service.

In the NSSM service installer dialog, enter the full path to the agent startup script in the Path field of the Application tab. Enter any other details appropriate for your environment. For information on the various options, see the NSSM documentation .

Click Install service .

A service is created named <service name>, that starts up automatically when the machine is started and that is also restarted if the process stops for any reason.

Uninstall the Database Agent as a Service

If you used INSTSRV.EXE and SC.EXE utilities:

From the Windows Explorer, right-click UninstallService.cmd and click Run as Administrator . This stops and removes the service from

Windows.

If you used NSSM:

From a command shell, enter nssm.exe remove <service name> where <service name> is the name of the agent service.

Known Issues

In Windows Server 2003 you must install and start or stop the service from the console window. If you do a normal RDP connection to

Copyright © AppDynamics 2012-2017 Page 33

the 2003s Terminal Services the service will be stopped when you log-out. Therefore issue the command "mstsc /console

<machinename>" to connect to the console session of Windows Server 2003.

Running the Agent on Windows Using the Task Scheduler

It is recommended to run the Database Agent as a Windows service. However, if you choose to run the agent using Task Scheduler, ensure the agent runs with the highest privileges available. When using Task Scheduler, if the host is restarted, the agent will not start automatically.

Copyright © AppDynamics 2012-2017 Page 34

Enable Snapshot Correlation for Oracle

In order for the Oracle Collector AppDynamics Database Visibility to collect database queries, sessions, clients, and schemas information that occurred during snapshots captured by the Java Agent, you need to set the jdbc-dbcam-integration-enabled App Agent property for the Java Agent.

For information on the jdbc-dbcam-integration-enabled property, see App Agent Node Properties Reference .

For information on snapshot correlation between the Oracle database Collector and a Java business transaction, see

Access Database

Visibility from Application Monitoring Views

Copyright © AppDynamics 2012-2017 Page 35

Increasing JVM Memory

To monitor 100 or more databases, you may need to increase the JVM memory allocation size. Increased activity on the databases you are monitoring results in increased memory usage.

On Linux, use this command to start the agent, and to initially allocate 256 MB to the agent instead of the default of 64 MB.

For Windows 64-bit

C:\java -Xmx256m -Djava.library.path="<db_agent_home>\auth\x64" -jar

<db_agent_home>\db-agent.jar

Copyright © AppDynamics 2012-2017 Page 36

Configure Controller Settings for Database Agents

You can configure parameters for the controller, such as the number of events sent to the Events Service at a time.

To Change the Controller Settings for Database Agents

1. Log in to the Administration Console .

2. Click Controller Settings .

3. Change the settings as needed and Save .

Controller Settings Reference for Database Agents

Property Name About the property dbmon.event.publisher.esclient.batch.size

Batch size for each Event Service client used by Database Monitoring.

dbmon.event.publisher.queue.size

Default

1500

Minimum value

200

Maximum measurement queue size maintained by Database Monitoring.

100000 100000

Copyright © AppDynamics 2012-2017 Page 37

Start and Stop the Database Agent

On this page:

Start the Agent

Stop the Agent

Start the Agent

If you are using an on-premises version of Database Visibility, you must start the Events Service before you start the Database Agent.

Before starting the agent, you must

configure the properties in this file

. You must specify these properties: Controller Host

Property, Controller Port Property, and Account Access Key Property.

Start the Agent in a Command Shell

The following assumes that all the necessary parameters have been specified in the controller-info.xml. The controller-info.xml file describes the properties of agent to Controller communications. Note that <db_agent_home> is the absolute path to the location where the Database Agent is installed. Setting the heap size is recommended as shown below.

Windows

cd <db_agent_home> start-dbagent.bat -Xms<min_heap_size> -Xmx<max_heap_size>

Linux

cd <db_agent_home>

./start-dbagent -Xms<min_heap_size> -Xmx<max_heap_size> &

Start the Agent as a Service

See

,

, and Start the Database

Agent Automatically on Linux .

Stop the Agent

Stop the Agent in a Command Shell

If the Database Agent process is running in the background, you can stop it by simply entering the kill command with the process ID as the argument. If it is running in the foreground in a console, you can press Ctrl+C to shut down the agent.

Stop the Agent Service in Windows

In the Windows Services application, select AppDynamics Database Agent and click Stop .

Copyright © AppDynamics 2012-2017 Page 38

Start the Database Agent Automatically on Linux

Related pages:

Install the Database Agent

Database Agent Configuration Properties

1. Create an initialization script that starts the agent, as in the sample initialization script that is an attachment to this page.

In your script, set the JAVA and AGENT_HOME values to the paths for your system. Also configure agent options, as needed.

2. Enable execution permissions for the script. For example, given an initialization script named db-agent, enter:

sudo chmod 775 db-agent

3.

Place the script in the initialization directory on your system, typically /etc/init.d. Alternatively, create a symbolic link to the script from the init.d directory to the script if you want to keep it in another location.

4. Add the script as a service as follows:

On Red Hat and most Linux Operating Systems, run these commands, replacing " db-agent " with the name of your file or symbolic link:

chkconfig --add db-agent chkconfig --level 2345 db-agent on

On Ubuntu and Debian Operating Systems, run this command, replacing "appdcontroller" with the name of your file or symbolic link:

update-rc.d -f db-agent start 99 2 3 4 5 .

In the command: start is the argument given to the script (start, stop).

99 is the start order of the script (1 = first one, 99 = last one)

2 3 4 5 are the runlevels to start

Be sure to include the dot (.) at the end of the command .

The Database Agent now starts automatically upon machine startup. When setting the agent to automatically start up using Task

Scheduler when the machine starts or restarts, ensure the agent runs with the highest privileges available.

Copyright © AppDynamics 2012-2017 Page 39

Start the Database Agent Automatically on Windows

Related pages:

Administer the Database Agent

Database Agent Configuration Properties

1. Create a batch file containing the following line:

For 64-bit systems, allocating 32 MB of initial heap size java -Xmx2048m -Djava.library.path="<adb_gent_home>\auth\x64" -jar

<db_agent_home>\db-agent.jar

For a 32-bit system, the set java.library.path="<db_agent_home>\auth\x32"

If your agent will be monitoring more than 100 databases, you may need to increase the size of the initial memory allocation specified in the code above as follows: change -Xmx2048m to -Xmx26624m

2. Click Control panel > Scheduled Tasks .

3. Select the batch file to execute. This is the file created in step 2.

4. Create a new task.

5. Select

When my computer starts

. When setting the agent to automatically start up using Task Scheduler when the machine starts or restarts, ensure the agent runs with the highest privileges available.

6. Enter the administrator's credentials to run the Database Agent as that user.

7. Click

Finish

.

8. To start the Database Agent for the first time, right-click on the scheduled task, and click Run .

Copyright © AppDynamics 2012-2017 Page 40

Add Database Licenses

On this page:

Add New Licenses

Transfer a License Between Databases

Related pages:

Add Database Collectors

License Management

The Controller requires a license for the total number of databases to monitor concurrently. One database agent can monitor 100+ databases.

Add New Licenses

1. Obtain a license.lic file with your existing AppDynamics licenses plus the new licenses from AppDynamics support.

2. Copy the license file in the Controller home directory. The Controller may take a few minutes to detect the new license. Restart the Controller to force immediate license detection.

Settings (gear icon) > License displays license information. The Application Performance Management and Database Server

Monitoring section shows the number of database license units provisioned and the maximum number allowed. In general one license unit is required for each database instance.

For Oracle or IBM DB2, if an instance comprises more than eight cores, then an additional license unit is required for each set of

8 cores. For MongoDB, each primary node requires one license.

If you disable a collector, it still consumes a license.

Transfer a License Between Databases

A database license is allocated to the first agents that register with the Controller up to the licensed limit.

To transfer a license for the Database Agent to another database, you simply remove the Collector for the old database and then add a new Collector for the database you want to monitor instead. See

Add Database Collectors

.

Copyright © AppDynamics 2012-2017 Page 41

Add Database Collectors

On this page:

Prepare for Collector Configuration

Add a Database Collector

Edit a Database Collector

Delete a Database Collector

Troubleshooting Collector Problems

Watch the Video

To enable the Database Agent to collect data, you must add and configure a Database Collector for each database instance that you want to monitor. The Database Collector is the process that runs within the Database Agent to collect performance metrics about your database instances and database servers.

Prepare for Collector Configuration

You must have the required permissions to monitor your databases. See

Database Visibility Requirements and Supported

Environments

.

For required roles and permissions required to add, edit, and create collectors, see Roles and Permissions .

Add a Database Collector

1. Click the Configuration tab in the left panel menu.

2. Click the Collectors option.

3. In the Collectors window, click the Add ( + ) option.

4. Complete each field of the Create New Collector dialog and then click OK . Your database administrator can provide you with the necessary details.

After you have added a collector, you can configure the collector for your database. You can also

link a database on the application flow

maps to a database instance monitored by Database Visibility.

Hardware Monitoring

For information on the fields you must complete in order for the Database Agent to monitor the database server in addition to the

database server, see Configure the Database Agent to Monitor Server Hardware

.

Verify Collector Setup

Once the Collector is up and running, in just a short time you can start viewing the historical activity data.

The Collector configuration window now has a collector icon you can click to edit the details of the collector if required. The Collector will also appear in the list of Databases shown in the left navigation menu. It might take a few minutes before the Collector and its metrics are reported.

From the left navigation menu, click Databases to see a high-level view of the activity of all the configured Collectors.

Click the name of the database to see more details of the metrics AppDynamics Database Monitoring has captured.

For information on using and interpreting the Collector windows, see Monitor Databases and Database Servers

.

Copyright © AppDynamics 2012-2017 Page 42

Edit a Database Collector

From the Collectors window, you can edit any of the details of the collector except the type of database platform to monitor.

For more information on collector fields, see the collector configuration page for your database.

Configure IBM DB2 Collectors

Configure Microsoft SQL Server Collectors

Configure Microsoft Azure Collectors

Configure MongoDB Collectors

Configure MySQL Collectors

Configure Oracle Collectors

Configure PostgreSQL Collectors

Configure Sybase Collectors

Configure Sybase IQ Collectors

Delete a Database Collector

From the Collectors window, you can delete a database Collector.

Troubleshooting Collector Problems

Collectors that have not been configured correctly, or that cannot connect to the database for any reason, will show an error on the

Databases overview page and individual database dashboards. Hovering over the error icon displays the potential reason for the error.

If your Collector isn't reporting any metrics after a few minutes, and you know the database is up and running with activity, check the

Events window.

Agent Diagnostic Events

can appear if the password is incorrect or communication errors have occurred. The message summaries on the Events window can help you diagnose and troubleshoot Collector problems.

Check the collector configuration to ensure all the values you entered are correct.

Ensure that your Database Agent has network connection to the databases you want to monitor along with the required permissions.

See

Database Monitoring Requirements and Supported Environments

.

Watch the Video

Creating Database Collectors

Copyright © AppDynamics 2012-2017 Page 43

Configure IBM DB2 Collectors

On this page:

Connection Details

User Permissions for IBM DB2 LUW

Generate Execution Plans

To monitor IBM DB2 with Database Visibility, you must be running DB2 9.x or newer.

Connection Details

Field

Database

Type

Database

Agent

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

Name

Hostname or IP

Address

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

Database

Listener

Port

The name of the database instance that you want to monitor.

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom

JDBC

Connection

String

The JDBC connection string generated by the database agent, for example, jdbc:db2:// . You can also specify a custom connection string, which is useful for setting custom authentication options.

Username The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for IBM DB2 LUW

.

Password The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database

Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Logging

Enabled

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located

User Permissions for IBM DB2 LUW

The monitoring user needs SYSMON authority and connect privileges to monitor. In general, this user must be a part of the sysmon_group.

To generate an execution plan, you must create the associated EXPLAIN tables in the schema.

DB2 version 9.7 and greater

Copyright © AppDynamics 2012-2017 Page 44

For complete Database Visibility functionality, the following monitoring switches of the DB2 server need to be enabled: "TIMESTAMP".

You can enable the "TIMESTAMP" monitoring switch by the following commands:

update dbm cfg using dft_mon_timestamp on;

Privileges

grant select on SYSIBMADM.MON_CURRENT_SQL to user DBMon_Agent_User grant select on SYSIBMADM.MON_LOCKWAITS to user DBMon_Agent_User grant execute on function SYSPROC.MON_GET_CONNECTION to user

DBMon_Agent_User grant select on SYSIBMADM.SNAPAPPL_INFO to user DBMon_Agent_User grant EXECUTE on function SYSPROC.MON_GET_PKG_CACHE_STMT to user

DBMon_Agent_User

(version 10.5 and above) grant execute on function

SYSPROC.MON_GET_TRANSACTION_LOG to DBAgent_User

(version 10.5 and above) grant execute on function

SYSPROC.MON_GET_DATABASE to DBAgent_User

Replace DBMon_Agent_User with the user name under which you run the Database Visibility Agent.

DB2 version 9.5

For complete Database Visibility functionality, the following monitoring switches of the DB2 server need to be enabled: "STATEMENT", and "TIMESTAMP".

You can enable these monitoring switches by the following commands:

update dbm cfg using dft_mon_stmt on; update dbm cfg using dft_mon_timestamp on;

Privileges

Copyright © AppDynamics 2012-2017 Page 45

grant select on SYSIBMADM.SNAPSTMT to user DBMon_Agent_User grant select on SYSIBMADM.SNAPAPPL_INFO to user DBMon_Agent_User grant select on table SYSIBMADM.ENV_PROD_INFO to user DBMon_Agent_User

where DBMon_Agent_User is the user name under which you run the Database Visibility Agent.

Generate Execution Plans

To generate an execution plan in DB2 10.1 or later, you must create the associated EXPLAIN tables in the schema.

1. Create a separate file system.

2. Create a separate tablespace.

db2 "CREATE STOGROUP DBMon_Agent_User ON

'/srv/db2/username1/$\{INSTANCENAME\}'" db2 "CREATE TABLESPACE

DBMon_Agent_User MANAGED BY AUTOMATIC STORAGE USING STOGROUP

DBMon_Agent_User"

3. Create a schema.

db2 "CREATE SCHEMA DBMon_Agent_User"

4. Grant the following privileges:

db2 "GRANT USE OF TABLESPACE DBMon_Agent_User to user

DBMon_Agent_User" db2 "CREATEIN ON SCHEMA DBMon_Agent_User TO USER

DBMon_Agent_User"

5. Call the SYSPROC.SYSINSTALLOBJECTS procedure:

Copyright © AppDynamics 2012-2017 Page 46

5.

db2 "CALL SYSPROC.SYSINSTALLOBJECTS('EXPLAIN', 'C',

'tablespace-name', 'schema-name' ) "

Copyright © AppDynamics 2012-2017 Page 47

Configure Microsoft SQL Server Collectors

On this page:

Connection Details

User Permissions for Microsoft SQL Server

To monitor Microsoft SQL Server with Database Visibility, you must be running the 2005 version or newer.

Connection Details

Field

Database

Type

Database

Agent

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

Name

Hostname or

IP Address

Failover

Partner

Listener Port

Logging

Enabled

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

The hostname or IP address of the failover partner.

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom JDBC

Connection

String

The JDBC connection string generated by the database agent, for example, jdbc:sqlserver:// . You can also specify a custom connection string, which is useful for setting custom authentication options.

Window

Authentication

Click to enable Windows authentication when connecting to the database.

Username

Password

The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for Microsoft SQL Server

.

The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with

Database Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector.

Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located in the <db_agent_home>\agent directory and have the format <CollectorName>_out.log and

User Permissions for Microsoft SQL Server

The user account used for monitoring can be a Windows authenticated account (if the Database Agent is running on Windows) or SQL

Server authenticated (if AppDynamics Database Visibility is running on Windows or Linux).

Required Permissions to See Execution Plans

Copyright © AppDynamics 2012-2017 Page 48

The SQL Server user, specified in the Create Collector > Connection Details section must be a SQL Server Authenticated user that is a member of the sysadmin server role or a Windows Authenticated Account with SHOWPLAN access on each database.

For more information, see Showplan Security and SHOWPLAN Permission and Transact-SQL Batches in the SQL Server documentation.

Minimum Permissions Required for SQL Server Logon

You can use the procedure below to create a SQL Server user with the minimum permissions required.

Use the following to create a SQL Server logon user that provides the minimal level of permissions required in order to gain full

AppDynamics Database Visibility/SQL Server functionality.

1. Using SQL Server Management Studio, create a new login for the AppDynamics SQL Server Database Collector, such as

DBMon_Agent_User.

2. From the User Mapping tab, map the new user to the master and msdb databases.

Viewing Object Information

To view object information on the Database > Objects Browser, map the monitoring user to the databases of interest.

3. Once you have created the login, give the following privileges to the user, substituting DBMon_Agent_User with the name you specified on the Login - New window:

Note: You can execute the following as a batch from a query window in Management Studio. The example shows grants to

DBMon_Agent_User; remember to change this if you have set up a different login.

use master

GRANT VIEW ANY DATABASE TO DBMon_Agent_User;

GRANT VIEW ANY definition to DBMon_Agent_User;

GRANT VIEW server state to DBMon_Agent_User;

GRANT SELECT ON [sys].[sysaltfiles] TO DBMon_Agent_User

GRANT execute on sp_helplogins to DBMon_Agent_User

GRANT execute on sp_readErrorLog to DBMon_Agent_User use msdb

GRANT SELECT on dbo.sysjobsteps TO DBMon_Agent_User

GRANT SELECT on dbo.sysjobs TO DBMon_Agent_User

GRANT SELECT on dbo.sysjobhistory TO DBMon_Agent_User

where DBMon_Agent_User is the name of the SQL Server user account specified in Create New Collector, Connection Details,

Username field.

SQL Server Authentication

If you are running AppDynamics Database Visibility on Linux then you must use SQL Server authentication.

Copyright © AppDynamics 2012-2017 Page 49

If your SQL Server database allows mixed-mode authentication, then the SQL Server AppDynamics Database Visibility uses to monitor the SQL Server database can use a SQL Server username/password authenticated account. If you would like to lock the role/permissions for the account down, then the account running AppDynamics Database Visibility requires:

View any database

View any definition

View server state

One additional requirement for I/O monitoring is to give permissions on a System view called sys.sysaltfiles. To do this you need to select the master database > Views > System Views > Properties for sys.sysaltfiles and then give select permissions on the object to the Public role.

Windows Authentication

If you would like to use a Windows authenticated account to connect to the SQL Server database, the following is required:

When creating the collector from the Create New Collector dialog, do not specify Username and Password in the database

Connection Details.

Also, the agent must be started with the path to its authentication library. For more information see,

Windows Authentication for

Microsoft SQL Server .

Access Rights

The following Select privileges are required: xp_msver sys.dm_exec_requests

sys.dm_exec_sessions

sys.dm_os_performance_counters

sys.dm_exec_query_stats

::fn_virtualfilestats sys.sysaltfiles

sys.configurations

sys.dm_exec_sql_text

sys.sysperfinfo

sys.sysprocesses

sys.syscurconfigs

::fn_get_sql

Copyright © AppDynamics 2012-2017 Page 50

Microsoft SQL Server on AWS RDS Permissions

The user account used for monitoring can be a Windows authenticated account (if the Database Agent is running on Windows) or SQL

Server authenticated (if AppDynamics Database Visibility is running on Windows or Linux).

Minimum Permissions Required for SQL Server Logon

You can use the procedure below to create a SQL Server user with the minimum permissions required.

Use the following to create a SQL Server logon user that provides the minimal level of permissions required in order to gain full

AppDynamics Database Visibility/SQL Server functionality.

1. Using SQL Server Management Studio, create a new login for the AppDynamics SQL Server Database Collector, such as

DBMon_Agent_User.

2. From the User Mapping tab, map the new user to the master and msdb databases.

Viewing Object Information

To view object information on the Database > Objects Browser, map the monitoring user to the databases of interest.

3. Once you have created the login, give the following privileges to the user, substituting DBMon_Agent_User with the name you specified on the Login - New window:

Note: You can execute the following as a batch from a query window in Management Studio. The example shows grants to

DBMon_Agent_User; remember to change this if you have set up a different login.

use master

ALTER SERVER ROLE processadmin ADD MEMBER DBMon_Agent_User;

GRANT VIEW ANY DATABASE TO DBMon_Agent_User;

GRANT VIEW ANY definition to DBMon_Agent_User;

GRANT VIEW server state to DBMon_Agent_User;

where DBMon_Agent_User is the name of the SQL Server user account specified in Create New Collector, Connection Details,

Username field.

To generate an execution plan on AWS RDS, you need additional permissions. The SHOWPLAN permission must be provided explicitly for each database:

USE <DB NAME> go

GRANT SHOWPLAN to DBMon_Agent_User; go

Copyright © AppDynamics 2012-2017 Page 51

Configure Microsoft Azure Collectors

On this page:

Connection Details

User Permissions for Microsoft Azure

To monitor Microsoft Azure with Database Visibility, you must be running version 2008 or newer.

Connection Details

Field

Database

Type

Database

Agent

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

Name

Hostname or IP

Address

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

Database

Failover

Partner

The name of the database instance that you want to monitor.

The hostname or IP address of the failover partner.

Listener

Port

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom

JDBC

Connection

String

The JDBC connection string generated by the database agent. You can also specify a custom connection string, which is useful for setting custom authentication options.

Username The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for Microsoft Azure .

Password The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database

Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Logging

Enabled

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located

User Permissions for Microsoft Azure

The user account used for monitoring can be a Windows authenticated account (if the Database Agent is running on Windows) or an

SQL Server authenticated account (if AppDynamics Database Visibility is running on Windows or Linux).

Copyright © AppDynamics 2012-2017 Page 52

Minimum Permissions Required for SQL Server Logon

You can create a SQL Server logon user that can access the database with the minimal level of permissions required. To create a SQL

Server logon user, you must be connected to the master database.

1. Run the command below to create a login. Specify a secure password in the command.

CREATE LOGIN DBMon_Agent_User WITH PASSWORD = 'Password123'

2. Run the following command in both the master database and your SQL Server database to create a user account for the newly created login:

CREATE USER DBMon_Agent_User FOR LOGIN DBMon_Agent_User WITH

DEFAULT_SCHEMA = dbo

3. From the User Mapping tab, map the new user to the master and msdb databases. Mapping the monitoring user to the monitored databases allows you to view object information in the Objects Browser.

grant VIEW DATABASE STATE to DBMon_Agent_User

You can execute the command as a batch from a query window in Management Studio.

4. While connected to your SQL Server database, run the command below to grant the roles and privileges. Substitute DBMon_Ag ent_User with the name of the SQL Server user account you specified when creating a new collector for this database.

grant VIEW DATABASE STATE to DBMon_Agent_User

Copyright © AppDynamics 2012-2017 Page 53

Configure MongoDB Collectors

On this page:

Connection Details

User Permissions for MongoDB

To monitor MongoDB with Database Visibility, you must be running version 2.2 or newer.

If you are configuring a collector for a MongoDB cluster, you only need to configure one collector for the entire cluster. You can choose any node in the cluster to connect to, and the entire cluster will automatically be detected.

Connection Details

Field

Database

Type

Database

Agent

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

Name

Hostname or IP

Address

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

Listener

Port

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom

Connection

String

The connection string generated by the database agent. You can also specify a custom connection string, which is useful for setting custom authentication options.

Username The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for MongoDB .

Password The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk

Logging

Enabled

Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database

Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located

User Permissions for MongoDB

For MongoDB versions prior to 2.6.X, the readAnyDatabase and ClusterAdmin built-in roles are required in order to monitor using

AppDynamics Database Visibility. For MongoDB sharded clusters, the monitoring user must have access to all shards.

For MongoDB 2.6 and later, the new clusterMonitor built-in role in addition to readAnyDatabase is required.

If you choose to create a new user to monitor MongoDB, the user must be created in the admin database.

You can configure user roles as shown in the sample query below:

Copyright © AppDynamics 2012-2017 Page 54

use admin db.createUser({ user: "tanujaAdmin", pwd: "tanuja123",

roles: [

{ role: "clusterAdmin", db: "admin" },

{ role: "readAnyDatabase", db: "admin" },

]

})

Copyright © AppDynamics 2012-2017 Page 55

Configure MySQL Collectors

On this page:

Connection Details

User Permissions for MySQL

To monitor MySQL with Database Visibility, you must be running version 2.2 or newer.

Connection Details

Field

Database

Type

Database

Agent

Name

Hostname or IP

Address

Listener

Port

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom

JDBC

Connection

String

The JDBC connection string generated by the database agent, for example, jdbc:mysql:// . You can also specify a custom connection string, which is useful for setting custom authentication options.

Username The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for MySQL .

Password The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk

Logging

Enabled

Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database

Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located

User Permissions for MySQL

The MySQL user the Database Agent uses to monitor the MySQL database must have "SELECT", "PROCESS", and "SHOW

DATABASES" privileges on all databases.

If you do not have a suitable existing user, you can use the command below to create a new user.

Copyright © AppDynamics 2012-2017 Page 56

GRANT SELECT,PROCESS,SHOW DATABASES on *.* to 'DBMon_Agent_User'@'host' identified by 'password';

FLUSH privileges;

Substitute DBMon_Agent_User with the username under which you run the Database Visibility Agent. Substitute host with the hostname or IP address of the machine running the AppDynamics Database Agent, and substitute password with a secure password.

Set the secure_file_priv parameter to NULL. After you do this, you must restart MySQL.

Set the max_allowed_packet parameter to 1073741824 on the server.

Copyright © AppDynamics 2012-2017 Page 57

Troubleshooting MySQL Permissions

Viewing MySQL Error Logs

To see the error log file, the following conditions must be met: secure_file_priv is either empty or the name of folder containing the error log file. You must restart MySQL for changes in the secure_file_priv variable to take effect.

The error log file is readable to all users max_allowed_packet is larger than the error log file size

The user has FILE privileges

Copyright © AppDynamics 2012-2017 Page 58

Configure Oracle Collectors

On this page:

Connection Details

User Permissions for Oracle

User Permissions for Oracle RAC

To monitor Oracle with Database Visibility, you must be running Oracle 10g or newer.

If you are configuring a collector for Oracle RAC, you only need to configure one collector for the entire cluster. You can choose any node in the cluster to connect to, and the entire cluster will automatically be detected.

Connection Details

Field

Database Type

Database Agent

Name

Hostname or IP

Address

Listener Port

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom JDBC

Connection

String

The JDBC connection string generated by the database agent, for example, jdbc:oracle:thin:@(DESCRIPT

ION=(ADDRESS=(PROTOCOL= . You can also specify a custom connection string, which is useful for setting custom authentication options.

Select if the field that follows is the service name.

Use Service

Name

SID or

SERVICE_NAME

The SID or service name of the database you want to monitor.

Connect as a sysdba

Username

Password

Click if you want to connect to the database as a sysdba user and enable password files. Running the collector with a sysdba account allows the collector to monitor an Oracle instance that is on standby.

The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for Oracle .

The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk Click to enable CyberArk for database username and password. When CyberArk is enabled, information about

Safe, Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Copyright © AppDynamics 2012-2017 Page 59

Oracle Wallet Click to enable Oracle Wallet.

Truststore Location: location of the e-wallet file on the DB Agent host

Truststore Type: type of Oracle Wallet. There are two truststore types:

PKCS12 (default)

SSO : enables auto-login. If you use SSO, you only need to provide the truststore location and truststore type.

Truststore Password: password for Oracle Wallet

If the SSL_CLIENT_AUTHENTICATION parameter is set to true in listener.ora and sqlnet.ora, then click the

Enable SSL Client Authentication box.

Keystore Location: location of the e-wallet file on the DB Agent host

Keystore Type: type of Oracle Wallet

Keystore Password: password for Oracle Wallet

Logging Enabled Click to enable verbose mode logging, which logs all communications between the Controller and the Collector.

Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located in the <db_agent_home>\agent directory and have the format <CollectorName>_out.log and

User Permissions for Oracle

For versions of Oracle prior to 10g

The permissions required for the Oracle user are:

CONNECT

SELECT ANY DICTIONARY

To create a user with these permissions, you can run the following SQL. In this SQL, change "password" to a safe and secure password, and change the tablespace names, "users" and "temp" to those available in your Oracle instance.

CREATE user DBMon_Agent_User IDENTIFIED BY password default tablespace users temporary tablespace temp;

GRANT CONNECT, SELECT ANY DICTIONARY to DBMon_Agent_User;

where DBMon_Agent_User is the user name under which you run the Database Visibility Agent.

For versions of Oracle 10g and later

The permissions required for the Oracle user are :

CREATE SESSION

SELECT_CATALOG_ROLE

To create a user with these permissions, you can run the following SQL. In this SQL, change "password" to a safe and secure password, and change the tablespace names, "users" and "temp" to those available in your Oracle instance.

Copyright © AppDynamics 2012-2017 Page 60

CREATE USER DBMon_Agent_User IDENTIFIED BY password default tablespace users temporary tablespace temp;

GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO DBMon_Agent_User;

where DBMon_Agent_User is the user name under which you run the Database Visibility Agent.

For versions of Oracle 12c and later with Multitenant Container Database Option enabled

The permissions required for the Oracle user are :

CREATE SESSION

SELECT_CATALOG_ROLE

To create a user with these permissions, you can run the following SQL. In this SQL, change "password" to a safe and secure password, and change the tablespace names, "users" and "temp" to those available in your Oracle instance.

CREATE USER C##DBMon_Agent_User IDENTIFIED BY password default tablespace users temporary tablespace temp CONTAINER=ALL;

GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO C##DBMon_Agent_User

CONTAINER=ALL;

ALTER USER C##DBMon_Agent_User QUOTA 100M ON USERS; alter user C##DBMON_AGENT_USER set container_data=all container=current;

Permissions Required for Oracle Explain Plans

To generate an execution plan for a specified query, click Explain New Plan . You must provide a plan table in the AppDynamics monitoring user's schema. You can find a sample output table named PLAN_TABLE in the UTLXPLAN.SQL script. To update or view the plan table, you need INSERT and SELECT privileges. To explain a query, you need access privileges for the tables and views included in that query.

Copyright © AppDynamics 2012-2017 Page 61

AppDynamics Database Visibility can generate explain plans within its SQL drilldown window. To enable this functionality, you must have a plan table accessible to the AppDynamics Database Visibility schema user. You can create this plan table with the following command from sqlplus when logged on as the AppDynamics Database Visibility user:

Windows:

@?\rdbms\admin\utlxplan.sql

Linux:

@?/rdbms/admin/utlxplan.sql

Permissions for individual views and tables

You can grant permission to individual views and tables even if the SELECT_CATALOG_ROLE permission is not available to your organization.

1. Execute permissions on dbms_application_info.set_module.

2. Select permissions on the following privileges: dba_data_files dba_ind_columns dba_indexes dba_objects dba_segments dba_sequences dba_synonyms dba_tab_columns dba_tables dba_users dba_views gv$instance v$archive_dest v$database v$datafile v$event_name v$instance v$license v$log v$parameter v$process v$session v$sesstat v$session_wait v$sga v$sql v$sql_plan v$sqlstats v$sqltext v$statname v$sysmetric v$sysstat v$system_event

Copyright © AppDynamics 2012-2017 Page 62

User Permissions for Oracle RAC

When you upgrade to 4.3, you may encounter the following error: Network access denied by access control list (ACL). You can resolve the error by enabling ACLs for the monitoring user.

begin dbms_network_acl_admin.create_acl ( acl => 'Resolve_Access.xml', description => 'Resolve Network Access using UTL_INADDR', principal => '<DBMON USER>', is_grant => TRUE, privilege => 'resolve', start_date => null, end_date => null

); commit; end;

/ begin dbms_network_acl_admin.assign_acl ( acl => 'Resolve_Access.xml', host => '*', lower_port => null, upper_port => null); commit; end;

/

Copyright © AppDynamics 2012-2017 Page 63

Configure PostgreSQL Collectors

On this page:

Connection Details

User Permissions for PostgreSQL

You can monitor any version of PostgreSQL with Database Visibility.

Connection Details

Field

Database

Type

Database

Agent

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

Name The name you want to identify the collector by.

Hostname or

IP Address

The hostname or IP address of the machine that your database is running on.

EnterpriseDB Click if your PostrgreSQL database installation is an EnterpriseDB distribution.

Listener Port The TCP/IP address of the port on which your database communicates with the Database Agent

Custom

JDBC

Connection

String

Username

The JDBC connection string generated by the database agent, for example, jdbc:postgresql:// specify a custom connection string, which is useful for setting custom authentication options.

. You can also

Password

The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in User Permissions for PostgreSQL .

The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk

Logging

Enabled

Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with

Database Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector.

Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located in the <db_agent_home>\agent directory and have the format <CollectorName>_out.log and

User Permissions for PostgreSQL

The monitoring user must either have a role of superuser or be granted access to the pg_stat_activity table using the technique described below.

The following script allows you to create a SECURITY DEFINER function that is owned by the superuser, and runs the query you want, thus allowing non-superusers to see the contents of pg_stat_activity by calling the get_sa() function.

Copyright © AppDynamics 2012-2017 Page 64

CREATE FUNCTION get_sa() RETURNS SETOF pg_stat_activity AS

$$ SELECT * FROM pg_catalog.pg_stat_activity; $$

LANGUAGE sql

VOLATILE

SECURITY DEFINER;

CREATE VIEW pg_stat_activity_allusers AS SELECT * FROM get_sa();

GRANT SELECT ON pg_stat_activity_allusers TO public;

The monitoring user must also be able to connect remotely to the PostgreSQL instance from the AppDynamics for Databases machine.

Copyright © AppDynamics 2012-2017 Page 65

Configure Sybase Collectors

On this page:

Connection Details

User Permissions for Sybase

To monitor Sybase with Database Visibility, you must be running version 15 or newer.

Connection Details

Field

Database

Type

Database

Agent

Name

Hostname or IP

Address

Listener

Port

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom

JDBC

Connection

String

The JDBC connection string generated by the database agent, for example, jdbc:sybase:Tds: . You can also specify a custom connection string, which is useful for setting custom authentication options.

Username The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for Sybase .

Password The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk

Logging

Enabled

Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database

Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located

User Permissions for Sybase

For complete AppDynamics Database Visibility functionality, the monitoring user requires the sa_role and mon_role privilege.

To create a new dedicated user for AppDynamics Database Visibility, you can use following sample user creation script. Before running the script, change "password" to a more secure value.

Copyright © AppDynamics 2012-2017 Page 66

exec sp_addlogin 'DBMon_Agent_User', 'password', @defdb='master',

@deflanguage='us_english', @fullname='DBMon_Agent_User monitoring account', @auth_mech = 'ANY' go exec sp_locklogin 'DBMon_Agent_User', 'unlock' go exec sp_role 'grant', 'sa_role', 'DBMon_Agent_User' go exec sp_role 'grant', 'mon_role', 'DBMon_Agent_User' go

where DBMon_Agent_User is the user name under which you run the Database Visibility Agent.

Also, the following configuration parameters must be set to 1 (true) in order to monitor the Sybase ASE database with AppDynamics

Database Visibility: "enable monitoring", "wait event timing", "SQL batch capture", and "object lockwait timing". You should also set

"max SQL text monitored" to at least 8192 (8kB).

Here is an example of the commands required to configure these settings:

sp_configure "enable monitoring", 1 go sp_configure "wait event timing", 1 go sp_configure "SQL batch capture", 1 go sp_configure "object lockwait timing", 1 go sp_configure "max SQL text monitored", 8192 go

If the value for "max SQL text monitored" was previously less than 4096, then increasing this setting will require that you restart the

Sybase ASE instance.

Copyright © AppDynamics 2012-2017 Page 67

Configure Sybase IQ Collectors

On this page:

Connection Details

User Permissions for Sybase IQ

You can monitor any version of Sybase IQ with Database Visibility.

Connection Details

Field

Database

Type

Database

Agent

Name

Hostname or IP

Address

Listener

Port

Description

The database type that you want to monitor.

The Database Agent that manages the collector.

The name you want to identify the collector by.

The hostname or IP address of the machine that your database is running on.

The TCP/IP address of the port on which your database communicates with the Database Agent

Custom

JDBC

Connection

String

The JDBC connection string generated by the database agent. You can also specify a custom connection string, which is useful for setting custom authentication options.

Username The name of the user who is connecting to and monitoring the database through the Database Agent. The user should have the permissions described in

User Permissions for Sybase IQ .

Password The password of the user who is connecting to and monitoring the database through the Database Agent.

CyberArk

Logging

Enabled

Click to enable CyberArk for database username and password. When CyberArk is enabled, information about Safe,

Folder, and Object is required to fetch the username and password for your database. To use CyberArk with Database

Visibility, you must download the JavaPasswordSDK.jar file from the CyberArk web site and rename the file to cyberark-sdk-9.5.jar. Then, you must copy the JAR file to the lib directory of the database agent zip file.

Click to enable verbose mode logging, which logs all communications between the Controller and the Collector. Enable only during troubleshooting because logging consumes a lot of disk space. If you have enabled logging, you can click the logging icon in the Log column of the Collector Administration window to view the log file. The log files are located

User Permissions for Sybase IQ

To monitor with a non-DBA account, you need the following:

User account with SERVER OPERATOR system privilege.

Execution privileges on several procedures which can be granted as follows:

Copyright © AppDynamics 2012-2017 Page 68

grant execute on sp_iqconnection to DBMon_Agent_User grant execute on sp_iqtransaction to DBMon_Agent_User grant execute on sp_iqcontext to DBMon_Agent_User grant execute on sp_iqstatus to DBMon_Agent_User grant execute on sp_iqcolumn to DBMon_Agent_User grant execute on sp_iqindex to DBMon_Agent_User

where DBMon_Agent_User is the user name under which you run the Database Visibility Agent.

Grant DBA authority to DBMon_Agent_User as follow:

grant DBA to DBMon_Agent_User

Copyright © AppDynamics 2012-2017 Page 69

Use the Database Visibility API to Configure Collectors

On this page:

Supported API Calls

Example Request and Response

UI Collector versus JSON Collector Configuration Field Names

Related pages:

Add Database Collectors

Configure the Database Agent to Monitor Server Hardware

AppDynamics APIs

The Database Visibility API allows you to get, create, update, and delete Database Visibility Collectors.

Include the following headers for all Database Visibility API requests:

Accept: application/json; Content-type: application/json

JSON is currently the only supported format.

Supported API Calls

Get all Collectors

GET /controller/rest/databases/collectors

Get a Specific Collector

GET /controller/rest/databases/collectors/{configurationId}

Create Collector

Copyright © AppDynamics 2012-2017 Page 70

POST /controller/rest/databases/collectors/create

The JSON you send must contain the relevant Collector information. The required fields describing the Collector vary based on the type of database. See the table in the "UI Collector versus JSON Collector Configuration Field Names" section that follows for more information.

Update a Collector

POST /controller/rest/databases/collectors/update

The JSON you send must contain all the details of the existing collector with only the fields that you want to modify changed. To ensure you have all the fields, use the Get a Specific Collector call.

Delete a Specific Collector

DELETE /controller/rest/databases/collectors/{configurationId}

Batch Delete Multiple Collectors

POST /controller/rest/databases/collectors/batchDelete

Send an array of the configuration Ids of the Collectors.

Example request to batch delete curl --user user1@customer1:password -H "Accept: application/json" -H

"Content-type: application/json" -X POST -d

“[1,2,3]” http://demo.appdynamics.com/controller/rest/databases/collector s/batchDelete

Copyright © AppDynamics 2012-2017 Page 71

Example Request and Response

Example Request curl --user user1@customer1:password http://demo.appdynamics.com/controller/rest/databases/collectors

Example Response

Copyright © AppDynamics 2012-2017 Page 72

[

{

"performanceState": null,

"collectorStatus": "COLLECTING_DATA",

"eventSummary": null,

"config": {

"id": 1,

"version": 0,

"name": "test",

"nameUnique": true,

"builtIn": false,

"createdBy": "user1",

"createdOn": 1453317194781,

"modifiedBy": "user1",

"modifiedOn": 1453317194781,

"type": "MYSQL",

"hostname": "localhost",

"useWindowsAuth": false,

"username": "root",

"password": "appdynamics_redacted_password",

"port": 8080,

"loggingEnabled": false,

"databaseName": null,

"failoverPartner": null,

"connectAsSysdba": false,

"useServiceName": false,

"sid": null,

"customConnectionString": null,

"enterpriseDB": false,

"useSSL": false,

"enableOSMonitor": false,

"hostOS": null,

"useLocalWMI": false,

"hostDomain": null,

"hostUsername": null,

"hostPassword": "",

"certificateAuth": false,

"removeLiterals": true,

"sshPort": 0,

"agentName": "Default Database Agent"

}

}

]

Copyright © AppDynamics 2012-2017 Page 73

Hardware

Monitoring

UI Collector versus JSON Collector Configuration Field Names

Use the table below to ensure you use the correct field names for your API calls. The Collector configuration field names are described in

Configure the Database Agent to Monitor Server Hardware and

Add Database Collectors .

Section UI Collector

Configuration Field

Name

JSON Collector Configuration Field Name

Connection

Details

Database Type

Database Agent

Database

Hostname/IP Address id (AppDynamics assigns this ID to the Collector when you configure the Collector.

You need this ID when doing a batch delete.) type agentName name hostname

EnterpriseDB

Failover Partner

Listener Port

Custom JDBC Connection

String enterpriseDB failoverPartner port customConnectionString

Use Service Name

SID or SERVICE_NAME

Connect as a sysdba useServiceName sid connectAsSysdba

Username

Password hostUsername hostPassword

Logging Enabled

Monitor Operating System enableOSMonitor

Operating System

Use Local WMI

Domain

SSH Port

Use certificate

Username

Password hostOS useLocalWMI hostDomain sshPort certificateAuth hostUsername hostPassword

SSL field

In addition to JSON Configuration Fields listed above, there is also the ssl field. SSL is a configurable property for the

Database Agent. If the Database Agent has been configured to use SSL, then you must also provide the ssl field and its value in your Database Visibility API calls.

Copyright © AppDynamics 2012-2017 Page 74

Copyright © AppDynamics 2012-2017 Page 75

Monitor Sybase Databases Using Kerberos Authentication

In order to for the Database Agent to connect to and monitor Sybase databases using Kerberos authentication, the following are required:

In the Connection Details section of the Collector configuration dialog, specify the following JDBC connection string:

jdbc:sybase:Tds:<hostname>:<portnum>?REQUEST_KERBEROS_SESSION=true&SERVIC

E_PRINCIPAL_NAME=<myserver>

Start the Database Agent using the -Djavax.security.auth.useSubjectCredsOnly=false option such as the following:

nohup java -Djavax.security.auth.useSubjectCredsOnly=false

/<db_agent_home>/db-agent.jar &

Copyright © AppDynamics 2012-2017 Page 76

Configure the Database Agent to Monitor Server Hardware

On this page:

Complete the Hardware Monitoring Section

Resolve Metric Reporter Type Mismatch Problem

Related pages:

Add Database Collectors

Monitor Database Server Hardware

In addition to monitoring the database server, the Database Agent can also monitor the hardware that hosts the database server. To configure the Database Agent to monitor the database server hardware, complete the Hardware Monitoring section of the

Collector configuration dialog.

Click Databases > Configuration > Collectors and then choose an existing collector to monitor the hardware for that database server and click Edit , or click Add to setup a new collector to monitor a different database server and the hardware hosting that server.

Complete the Hardware Monitoring Section

The following describes the fields in the Collector Configuration dialog that you must complete if you want to monitor the database server host hardware, in addition to the database server.

Monitor Operating System: Select if you want CPU consumption metrics collected from the monitored host.

Operating System: Specify the operating system of the monitored host: Windows, Linux, Solaris, AIX, or RDS.

Use Local WMI: Check this box if you want to monitor the machine the Database agent is running on, i.e. localhost. When selected, the authorization fields are not used because no authorization is required.

Domain: For Windows only, specify the the name of the domain in which the hardware resides.

SSH Port: For Linux, AIX, and Solaris only, specify the Secure Shell (SSH) port number the Controller should use for encrypted communications with the monitored host. The default port number of 22 will be used if you do not specify a different port number here.

Use certificate: For Linux, AIX, and Solaris only, AppDynamics also supports certificate-based authentication via Privacy Enhanced

Mail (PEM). To implement certificate-based authentication, enable the Use certificate option and copy the PEM file to the

<db_agent_home>\keys directory. Note, if the $HOME/.ssh directory exists, the agent will use the certificate found there. This option appears only if the agent is running on a machine running Linux, AIX or Solaris.

Username: Specify the name of the user the Database Agent uses to log on to the monitored host. To collect OS metrics from a

Windows host, the configured user (or Collector Service user if using Windows Authentication) must be able to establish a WMI connection to the target host and collect Windows Performance Counters.

Password: Specify the password of the user the Database Agent uses to log on to the monitored host. The number of echo characters shown in the password text field should not be interpreted to imply the number of characters stored for the (encrypted) user password.

Resolve Metric Reporter Type Mismatch Problem

Switch from the Java Hardware Monitor to the Hardware Monitor if you see messages similar to the following in the logs:

Copyright © AppDynamics 2012-2017 Page 77

[Worker-7] 12 Sep 2014 07:27:49,449 WARN MonitorOutputHandler - Metric

Reporter type mismatch for metric [Hardware Resources|Network|Incoming packets/sec] com.singularity.ee.agent.commonservices.metricgeneration.metrics.MetricRe

porterTypeMismatchException: Aggregator of OBSERVATION already exists for metric Metric Identifier[Hardware Resources|Network|Incoming packets/sec]

ID[0]

Copyright © AppDynamics 2012-2017 Page 78

Required Monitored Host Permissions

On this page:

Required SSH Permissions

Related pages:

Configure a Controller SSH Key

Database Agent User Permissions

Database Visibility collects the stats from common commands like vmstat/iostat or gathering metrics from the file system such as /proc and as such the user that runs the Database Agent requires no special permissions, just the ability to run those common commands and write to files in the Database Agent directory.

Database Agent Collector Authentication

When monitoring the database host, Database Visibility must log in to the host system to gather system information. There are three ways to authenticate the Database Collector to access the monitored host:

Specify a username and password in the Collector configuration dialog

Place a PEM file or an id_rsa file in the <agent home>/keys directory

If the Database Agent is running on LINUX, Solaris or AIX, place SSH keys in the <home>.ssh directory of the user running the agent. You can create an SSH key using the same procedure as described for the Controller, Configure a Controller SSH Key .

Required SSH Permissions

When monitoring the database host, Database Visibility uses SSH on Linux and Windows systems to gather system information. SSH access can be through either an authenticated username/password or a private key.

You can create an SSH key using the same procedure as described for the Controller, Configure a Controller SSH Key .

Copyright © AppDynamics 2012-2017 Page 79

Configure WMI Permissions and Security

On this page:

Requirements to Monitor Windows 7 and Higher Systems (agent running on

Unix-like platform)

Additional Requirements to Monitor Windows 2012 and Higher

Systems (agent running on Unix-like platform)

General Considerations for all Platforms

Related pages:

WMI and the Database Agent on the AppDynamics Community

To monitor Windows-based machine hardware with AppDynamics Database Visibility, AppDynamics uses Windows Management

Instrumentation (WMI) to remotely gather the metrics. WMI is often complicated to troubleshoot when the Database Agent is running on a Linux or Unix-like machine. This topic identifies requirements for the target machine configuration that can help you avoid some problems and pitfalls. It also provide some additional considerations regarding using WMI to monitor a SQL Server database agent and preventing unauthorized remote access to WMI.

Named Windows Account:

The user specified in the collector configuration that the AppDynamics Database Agent uses to connect to the target machine is referred to as "named Windows account."

The following are required when the Database Agent is hosted on AIX, Linux or Solaris platforms to monitor Windows 7 and higher systems.

Ensure that the named Windows account is a member of the local Administrators group.

Ensure User Account Meets Minimum Security Requirements When Using WMI

Enable Remote Registry Access

Grant access to WBEM scripting locator

The following are required when the Database Agent is hosted on AIX, Linux or Solaris platforms to monitor Windows 2012 and higher systems.

Grant full control permissions to select registry keys

Requirements to Monitor Windows 7 and Higher Systems (agent running on Unix-like platform)

The following are required when the Database Agent is hosted on AIX, Linux or Solaris platforms to monitor Windows 7 and higher systems.

Ensure User Account Meets Minimum Security Requirements When Using WMI

Enable Security Options for Windows Systems that are part of a Domain

Ensure the named Windows account has the correct permissions for WMI Control.

1. Run the wmimgmt.msc program.

2. Right click the WMI Control icon on the left and click Properties .

3. Click the Security tab.

4. Click the root node of the tree, and click Security .

5. Ensure that the named user account running the Database Agent has the relevant permissions.

The minimum permissions that your remote Windows account needs for the Database Agent are:

Execute Methods

Enable Account

Remote Enable

If the named Windows account does not have all of these permissions, you might see an access denied error or the following error:

Error=800706BA The RPC server is unavailable. SWbemLocator

Copyright © AppDynamics 2012-2017 Page 80

or

Error=80070005 Access is denied SWbemLocator

Enable Classic Security Options for Local (non-domain) Windows Systems

Applies to Windows computers that are not part of a domain.

1. Open the Control panel, and go to Administrative Tools > Local Security Policy .

The Local Security Settings window appears.

2. Go to Local Policies > Security Options.

3. Change the value of "Network access: Sharing and security model for local accounts." to Classic .

Enable Remote Registry Access

The Remote Registry service must be running on the target machine. If the Remote register service is off, you will see the following error:

Message not found for errorCode: 0xC0000034 or

Access is denied

By default Windows 7 and above systems will still deny remote access to the registry, even if the Remote Registry service is started.

To test this, try to connect to the slave registry via regedit on another machine. If you get a error similar to Access is denied , run powershell as an administrator on the slave, and execute Enable-PSRemoting. Restart the machine and try launching the slave again.

Grant Access to WBEM Scripting Locator

The Database Agent requires full access to the WBEM Scripting Locator. On the target system allow full access to the WBEM Scripting

Locator as follows:

1. As an Administrator on the target machine, launch regedit.

2. Locate the registry key:

76A64158-CB41-11D1-8B02-00600806D9B6 in HKEY_CLASSES_ROOT\CLSID

3. Right click the key and click Permissions .

4. Click Advanced , and then on the Owner tab change the owner to the Administrators group. Click Apply .

5. On the Permissions tab change the permissions for the Administrators group to Full Control . Click Apply .

6. Close regedit.

7. Restart the Remote Registry Service, using Administrative Tools > Services .

Configure the Firewall

WMI uses RPC which listens on port 135 but then allocates a dynamic port for subsequent communication. Configure your Firewall to always allow the TCP port 135 exception and follow the dynamic RPC ports. If there is a problem with the firewall, port 135 then you will probably see this error:

ERROR: Message not found for errorCode: 0xC0000001

For more information, see How to configure RPC dynamic port allocation to work with firewalls .

Additional Requirements to Monitor Windows 2012 and Higher Systems (agent running on Unix-like platform)

In addition to the requirements described in Requirements to Monitor Windows 7 and Higher Systems , the following are also required when the Database Agent is hosted on AIX, Linux or Solaris platforms to monitor Windows 2012 and higher systems.

Grant Full Control Permissions to Select Registry Keys

For the Database Agent running on AIX, Linux or Solaris to monitor Windows 2012 (64-bit) and above systems, complete the following changes on the target system.

1. As an Administrator on the target machine, launch regedit.

2. Change the permissions for both of the following registry keys to Full Control :

72C24DD5-D70A-438B-8A42-98424B88AFB8 in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID

76A64158-CB41-11D1-8B02-00600806D9B6 in HKEY_CLASSES_ROOT\CLSID

3.

Copyright © AppDynamics 2012-2017 Page 81

3. Find the following registry key:

72C24DD5-D70A-438B-8A42-98424B88AFB8 in HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID

4. Right click and click Permissions .

5. Change the owner to the Administrators group.

6. Change the permissions for the Administrators group to Full Control .

7. Change owner back to TrustedInstaller. User is "NT Service\Trusted Installer" on local machine.

8. Repeat steps 4 to 6 above for the following registry key:

76A64158-CB41-11D1-8B02-00600806D9B6 in HKEY_CLASSES_ROOT\CLSID.

9. Close regedit.

10. Restart the Remote Registry service, using Administrative Tools > Services .

General Considerations for all Platforms

These topics apply to the Database Agent running on Windows systems.

Use Windows Authentication for Microsoft SQL Server

To use Windows Authentication for the Database Agent to connect to a Microsoft SQL Server database instance, you must use a command similar to following to start the Database Agent; specifying the path to the Database Agent authentication library.

Windows 64-bit java -Djava.library.path="C:\dbagent404\auth\x64" -jar db-agent.jar

Windows 32-bit java -Djava.library.path="C:\dbagent404\auth\x86" -jar db-agent.jar

Also, the Windows account used to start the Database Agent must be a Windows user who can authenticate with the database server.

Prevent Unauthorized Remote Access to WMI

For Windows 2003 R2 SP2

You may want to setup extra security in the Windows Distributed Component Object Model (DCOM) to prevent unauthorized users from accessing WMI remotely. The following prevents users other than those configured as follows from remotely accessing the WMI. You can configure the named Windows account as follows:

1. On the target machine, add the named Windows account to the Performance Monitor Users group

2. In Services and Applications, bring up the properties dialog of WMI Control. On the Security tab, highlight Root/CIMV2, click S ecurity > Add Performance Monitor Users and enable the options: Enable Account and Remote Enable .

3. Run dcomcnfg. Click Component Services > Computers > My Computer > Properties > COM Security , and then click E dit Limits for both Access Permissions and Launch and Activation Permissions. Add Performance Monitor Users and allow remote access, remote launch, and remote activation permissions.

4. In Component Services > Computers > My Computer > DCOM Config > Windows Management Instrumentation , give R emote Launch and Remote Activation privileges to the Performance Users Group.

Copyright © AppDynamics 2012-2017 Page 82

Monitor Databases and Database Servers

Related pages:

Overview of Database Visibility

Database Visibility

Roles and Permissions

Top 6 Database Performance Metrics to Monitor in Enterprise Applications

The topics in this section show you how to use the features of AppDynamics to monitor and troubleshoot your database environments.

Access Database Visibility from Application Monitoring Views

Discover Normal Database and Server Activity

Monitor Database Performance

Monitor Database Server Hardware

Database Health Rules and Alerts

Database Monitoring Metrics

Database Agent Events Reference

Configure Query Literals Security

Configuring Custom Metrics

For roles and permissions required to view Database Monitoring windows, see Roles and Permissions .

Watch the Video

Quick Overview: Database Monitoring Dashboards

Copyright © AppDynamics 2012-2017 Page 83

Access Database Visibility from Application Monitoring Views

On this page:

View Database Activity in Database Visibility

View Business Transaction Snapshot Correlated Database Details

Related pages:

Monitor Database Performance

App Agent Node Properties Reference

View Database Activity in Database Visibility

Once you have

configured a database Collector

in AppDynamics Monitoring, you can access Database Visibility either from the

AppDynamics Home page or you can link to the Database Visibility database instance Dashboard by right-clicking the database and selecting View in Database Visibility on the Application Flow Map, Tier Flow Map or Node Flow Map.

Database backends with the same hostname, port number, and database type as a database server already configured in a database

Collector are automatically matched with the Collector, and drill downs from the Application Flow Map, Tier Flow Map or Node Flow

Map to Database Visibility are enabled.

Copyright © AppDynamics 2012-2017 Page 84

The AppDynamics Database Visibility section in the Application Database Dashboard displays which database Collector is associated with the database. To change this association, click Configure mapping and choose another database collector.

View Business Transaction Snapshot Correlated Database Details

Available for Java applications and their Oracle database backends, Snapshot correlation shows the details of queries, clients, sessions, and schemas around the time when the business transaction snapshot was captured.

To see the correlated database details

1. From a list of business transactions with snapshots, choose a longer running business transaction that accesses the database, one that takes a few seconds or more. These are more likely to have captured database details.

2. Double-click Drill Down above the database icon. The correlated database details window appears.

3. Click the , when the snapshot was captured.

, and Schema tabs to view details of database activity that occurred around the time

Copyright © AppDynamics 2012-2017 Page 85

To enable snapshot correlation, you must enable the jdbc-dbcam-integration-enabled node property for the Java Agent.

Copyright © AppDynamics 2012-2017 Page 86

Discover Normal Database and Server Activity

On this page:

View Performance Metrics on the Metrics Browser

Related pages:

Dynamic Baselines

Health Rules

AppDynamics Database Visibility automatically learns to detect performance anomalies using baselines that are specific to your database and database server environments.

AppDynamics creates baselines by collecting metrics from your monitored databases and servers over defined periods of time. This establishes what is normal for your environment. You can also create your own baselines .

View Performance Metrics on the Metrics Browser

On the Metric Browser for Database Visibility, you can visualize performance metrics and see how they deviate from expected behaviors established by the baseline.

Copyright © AppDynamics 2012-2017 Page 87

Monitor Database Performance

Related pages:

Access Database Visibility from Application Monitoring Views

Monitor Databases and Database Servers

The subtabs for each database provide detailed information about your database. This section describes the various windows for the database instance and how to interpret the displayed information.

From most of these subtabs you can drill down to the

Queries view .

View Overall Database and Server Performance

Database Dashboard

Database Topology Window

Database Live View Window

Database Activity Window

Database Queries Window

Database Clients Window

Database Sessions Window

Database Schemas and Databases Windows

Database Modules Window

Database Programs Window

Database Object Browser Window

Important information

Garbage collection affects all monitored entities, including database queries, sessions, clients, and schemas. Entities that are garbage collected will be displayed as unavailable.

Watch the video:

Copyright © AppDynamics 2012-2017 Page 88

View Overall Database and Server Performance

On this page:

Access the Databases Window

Features of the Databases Window

Related pages:

Access Database Visibility from Application Monitoring Views

Database Visibility provides overall views of your databases that show key performance indicators.

Access the Databases Window

From AppDynamics Home, click Databases .

Features of the Databases Window

On the views of the Databases window you can:

Show only databases meeting certain criteria by enter search criteria in the search box on the top right of the page.

Click Filters to show only databases meeting certain search criteria, such as criteria that describes Health, Load, Time in database, or Type.

Click the + symbol to add a new database Collector.

Click Actions to export the data on this window in a .csv formatted file that is automatically downloaded to your specified downloads directory.

Click View to switch between card and list view.

See the overall performance of your databases and if there are any critical issues with them. The server health or status indicates whether critieria has been met for normal, warning or critical health rules. The green check mark indicates that the database is operating within normal conditions, the red exclamation mark indicates that at least one critical health rule has been violated.

Click the name of the database to switch to the Database Dashboard for that specific database.

Databases Card View

From the Databases card view, you can see:

The Total Executions graph that provides insight into the total number of queries monitored for the database over the selected time period. This metric is expressed in millions of queries.

The Time in Database graph that indicates the total time spent executing those queries during the selected time period. This metric is expressed in hours, minutes, and seconds.

CPU Usage metrics that when enabled shows the percentage of CPU capacity consumed by the database.

Copyright © AppDynamics 2012-2017 Page 89

Databases List View

From the Databases list view, you can:

Click Options to turn the spark charts on and off.

Get to the databases you want to see quickly If you are monitoring many databases.

Click on any point in the spark charts to see a metric for that point in time. For example, clicking on a point in the Queries Trend shows how many queries were monitored at that time.

Click on a column name to sort the list on that key.

Copyright © AppDynamics 2012-2017 Page 90

Database Dashboard

On this page:

Access the Database Dashboard

Features of the Database Dashboard

Watch the Video

Related pages:

Access Database Visibility from Application Monitoring Views

View Overall Database and Server Performance

Discover Normal Database and Server Activity

Database Health Rules and Alerts

Monitor Database Performance

The dashboard for each individual database provides the most detailed information about your database.

Access the Database Dashboard

You can access the Database Dashboard in one of the following ways:

From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

From the Databases overview window, click the name of the database you want to see in detail on the Database Dashboard.

Features of the Database Dashboard

On the Database Dashboard you can:

Click the dropdown arrow next to the database Collector name at the top of the page to choose a database that you want to see the dashboard for.

Click the status icon below SERVERS in the top section of the dashboard to go directly to Events where you can see any recent events..

On the Database Dashboard you can see the following information:

Server Health: Server Health at the top of this window indicates the extent to which health rules are being violated:

Green - Healthy server

Yellow/orange - server with warning-level violations

Red - server with critical-level violations

Type: The database type.

Load and Time Spent in Database:

Load - At a glance you can see the total number of calls during the specified time period and the number of calls for any point in time. The number of calls to the database directly correlates with database performance; the more calls there are, the longer it takes to respond to each call.

Time spent in Database - The total time spent executing SQL statements during the specified time period.

Top 10 SQL Wait States: Activities that contribute to the time it takes the database to service the request. The wait states consuming the most time may point to performance bottlenecks. For example, a db file sequential read wait state may be caused by segment header contention on indexes or by disk contention. See your database platform documentation for descriptions of the SQL wait states. For example, the following was developed from information in a Microsoft Customer

Service blog for SQL Server :

Wait State - CHECKPOINT_QUEUE

Description - Used by background worker that waits on events on queue to process checkpoint requests.

Recommended Action - You should be able to safely ignore this one as it is just indicates the checkpoint background worker is waiting for work to do. I suppose if you thought you had issues with checkpoints not working or log truncation you might see if this worker ever "wakes up". Expect higher wait times as this will only wake up when there is work to do.

Average number of active connections : The average number of connections established with the database at any point in time during the selected time period. A connection is a session established between a database client and a server.

Copyright © AppDynamics 2012-2017 Page 91

The CPU, Memory, Disk I/O, and Network I/O graphs display when the Database Agent has been configured to also monitor the database host hardware.

See, " Configure the Database Agent to Monitor Server Hardware" on

Add Database Collectors

.

CPU: The CPU graph shows the relative percentages of CPU processing time used for handling system and users processes.

Memory: The Memory graph shows the percentage of total memory in use at any point in time.

Disk I/O: The Disk I/O graph shows disk usage, volume of data read and written.

Network I/O: The Network I/O graph shows network activity, volume of data sent and received.

Copyright © AppDynamics 2012-2017 Page 92

Accessing Metric Brower

To see more information about a specific metric, double click any point on the graph and the Metric Browser opens displaying that metric. You can then hover over a point on the graph in the Metric Browser for more information about the metric. This feature is available for all the graphs except the SQL wait states graph.

Watch the Video

Quick Overview: Database Monitoring Dashboards

Copyright © AppDynamics 2012-2017 Page 93

Database Topology Window

The Topology view displays current activity for the routing service and shards of a MongoDB database or Oracle RAC server. The

Topology view shows key performance metrics for the routing service and shards of the database.

Access the Database Topology Window

To access the Database Topology Window

1. From AppDynamics Home, double-click the name of the MongoDB database or Oracle RAC that you want to see in detail on the Database Dashboard.

2. Click the Topology tab.

Features of the Database Topology Window

On the Database Topology Window you can:

Select the Auto Refresh box. From the Every list, you can choose how often the system updates the live view.

Click the dropdown arrow next to the database Collector name at the top of the page to choose a node or cluster that you want to see the metric views for. You can either select the database Collector name from the list, or search for the database

Collector by entering text in the search bar and then clicking the refresh icon to show only database Collectors that meet that search criteria.

Hover over the sections of the trends to see their details.

Click a column title on the Topology name list to sort the topologies using that column as the sort key.

On the MongoDB and Oracle RAC Topology window you can see the following information:

Health: Indicates whether any health rules for the MongoDB or Oracle RAC routing service or shards of the replica set have been violated.

Role: The role performed by the shard. The routing service routes the queries to the shards to balance the load. The members or shards of the replica sets can have either primary or secondary shard role.

Num Queries: The number of queries handled.

Queries Trend: The trend of queries handled over time.

Time in Database: The time required for the database to respond to the queries.

Time Spent in Database Trend: The trend of time spent in the database over time.

Copyright © AppDynamics 2012-2017 Page 94

Database Live View Window

On this page:

Access the Database Live Window

Features of the Database Live Window

Related pages:

Access Database Visibility from Application Monitoring Views

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

The Live view displays current activity for the database server. The live view shows key performance metrics for the last time period, which can be refreshed in a specified time interval between 10 seconds and 5 minutes.

Access the Database Live Window

To access the Database Live Window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Live View tab.

Features of the Database Live Window

On the Database Live Window you can:

Select the Auto Refresh box and then from the Every list, choose how often you want the system to update the live view.

Click the down arrow next to the database Collector name at the top of the page to choose to view the live view of a different database Collector by either selecting the database Collector name from the list or by searching for the database Collector by entering text in the search bar and then clicking the refresh icon to show only database Collectors that meet that search criteria.

Hover over the sections of the charts to see their details.

Click the View list to view All Active Sessions or All Sessions.

Click a column title on the Session List to sort the Session List using the clicked column as the sort key.

On the Database Live window you can see the following information:

CPU Usage: If you have enabled Hardware Monitoring for the server the chart shows the percentage of available CPU resources consumed by users and the system and a break down of how the CPU is being used.

IO - Disk input and output.

System - Database operating system activities.

User - User interaction with the database.

Memory Usage : Displays how much memory is in use and how much is available.

the most time may point to performance bottlenecks. For example, db file sequential reads may be caused by segment header contention on indexes or by disk contention.

Session List: A table describing database usage instances and their properties. The database session is the application interaction with the database, a new session is started for each request. The columns displayed are database dependent.

Copyright © AppDynamics 2012-2017 Page 95

In the Live View for database clusters, you must select a node from the dropdown menu to view that node's activity.

Copyright © AppDynamics 2012-2017 Page 96

Database Activity Window

On this page:

Access the Database Activity Window

Features of the Database Activity Windows

Wait State

Top Activity

Time Comparison

I/O

Top Query

Related pages:

Access Database Visibility from Application Monitoring Views

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

The following describes the reports available in Database Visibility on the Database Activity Window. The reports available depend on the database platform being monitored. The reports are listed in alphabetical order and indicate which database platform supports them.

Access the Database Activity Window

To access the Database Activity window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Activity tab.

Features of the Database Activity Windows

To view the database reports of different databases, click the down arrow next to the database name at the top of the page. From the list, select the database you want to view, or search for the database in the search bar. Click the refresh icon to show only databases that meet that search criteria.

The activity reports available are described below. The reports available are database-dependent. The reports are listed in alphabetical order and indicate which database platform supports them. The reports will only show 10 days of data, which is the Events Service limit.

Wait State

Description : This report displays time-series data on Wait Events (states) within the database. Each distinct wait is color-coded, and the Y-axis displays time in seconds. This report also displays data in a table and highlights the time spent in each wait state for each

SQL statement.

Relevance: The wait states consuming the most time may point to performance bottlenecks. For example, db file sequential reads may be caused by segment header contention on indexes or by disk contention.

Platform: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase and Sybase IQ

Top Activity

Description: Display the top time in database SQL statements in a time-series view. This report also displays data in a table and highlights the time spent in the database for each of 10 top SQL statements.

Relevance: Use this report to see which SQL statements are using the most database time. This helps to determine the impact of specific SQL statements on overall system performance allowing you to focus your tuning efforts on the statements that have the most impact on database performance.

Platform: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase and Sybase IQ

Time Comparison

Description: This report allows compares the performance of two databases during the same time period based on a specific statistic

Copyright © AppDynamics 2012-2017 Page 97

type.

Relevance: You may want to compare the performance of your development and production databases before and after you tune the

SQL queries or add an index or join. This report can help you determine the effectiveness of any performance tuning procedures you have implemented.

Platform: IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase and Sybase IQ

I/O

Description: This report gives information on physical I/O performed by the database instance.

Relevance: Your physical disk I/O may be affecting database performance.

Poor response times may mean one of the following:

You're doing too much physical I/O and need to adjust your I/O capacity

You're scanning tables or indexes when you should be doing seeks

Your database tables are missing indexes

Your SQL needs to be tuned

Platform: Microsoft SQL Server, Oracle

Top Query

Description: This report displays the top 10 SQL statements for the specified statistic in a time-series view.

Relevance: Use this report to see which SQL statements are using the most database resources. This helps to determine the impact of specific SQL statements on overall system performance allowing you to focus your tuning efforts on the statements that have the most impact on database performance. You can choose one of many statistics to base the report on.

Platform: IBM DB2, Microsoft SQL Server, Oracle

Copyright © AppDynamics 2012-2017 Page 98

Database Queries Window

On this page:

Access the Database Queries Window

Features of the Database Queries Window

Related pages:

Access Database Visibility from Application Monitoring Views

Add Database Collectors

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

The Queries window displays the SQL statements and stored procedures that consume the most time in the database. You can compare the query weights to other metrics such as SQL wait times to determine SQL that requires tuning.

Access the Database Queries Window

To access the Database Queries Window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Queries tab.

Features of the Database Queries Window

On the Database Queries window you can:

View the top N queries. These are the queries that consumed the greatest amount of database time to complete.

Choose to display the top 5, 10, 100 or 200 queries.

Click the name of a column to sort the Query list using that key.

Click Filter by Wait States to choose wait states to filter the Query list by. The filtered list only displays queries that caused the selected wait states.

Search for a specific query, by entering text in the Search bar that may appear in the Query. This is useful if you found a slow query in the Slow Database calls window of AppDynamics Application monitoring.

Double-click a query or select a query and click View Query Details to dive into the Query Details for more detailed information about that specific query.

Click the down arrow next to the database Collector name at the top of the page to choose to view the database queries of a different database Collector by either selecting the database Collector from the list or by searching for the database Collector by entering text in the search bar and then clicking the refresh icon to show only database Collectors that meet that search criteria.

Click Actions to export the data on this window in a .csv formatted file that is automatically downloaded to your specified downloads directory.

On the Database Queries window you can see the following information:

Query Id : This is the unique ID assigned to the query internally by the database.

Query : The text of the query, or, in the case of a stored procedure invocation, the name of the stored procedure. If the user does not have the ANY permission to view the the stored procedure name, the definition of the stored procedure is shown instead of the stored procedure name.

For SQL Server, Azure, Oracle, and DB2 the metrics Number of Executions, Average Response TIme and Elapsed Time are inferred from the query index. For databases such as MySQL and MongoDB which don't have a query index, no data will appear in the Number of Executions and Average Response Time columns. However, Elapsed Time can be inferred for MySQL and MongoDB databases using the wait state index. Elapsed Time can also be inferred using the wait state index when query statistics for a query run on an SQL

Server, Azure, Oracle or DB2 database are otherwise not available.

Elapsed Time : The total time consumed by all executions of this query. Query statistics such as Number of Executions,

Average Response Time and Elapsed time are available for databases supporting the query index, such as SQL Server,

Azure, Oracle, and DB2. For databases where the query index is not available, elapsed time is inferred from the wait state index.

The query sampling frequency is once every second. If a query takes less than 1 second and happens to occur in the time between sampling instances, its elapsed time is reported as 0 seconds.

Copyright © AppDynamics 2012-2017 Page 99

Number of Executions: (supported for SQL Server, Azure, Oracle, DB2) The number of times the query ran during the specified time period.

Average Response Time (hh:mm:ss): (supported for SQL Server, Azure, Oracle, DB2) The average time required during the specified time period to respond to the query.

Weight (%): The percentage of the total time consumed by the query.

Once you have identified the statements that are consuming the most resources, you can dig down deeper for details that can help you tune the SQL statement. For indepth query details, click a SQL statement and then click View Query Details . See

Database Query

Details Window .

Copyright © AppDynamics 2012-2017 Page 100

Database Query Details Window

On this page:

Access the Database Query Details Window

Features of the Database Query Details Window

Related pages:

Access Database Visibilityisbility from Application Monitoring Views

Add Database Collectors

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

Once you have identified the statements on the

Database Queries Window window

that are spending the most amount of time in the database, you can dig down deeper for details that can help you tune those SQL statements. The database instance Query Details

window displays details about the query selected on the Database Queries Window window.

Access the Database Query Details Window

To access the Database Query Details Window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Queries tab.

3. Select a query and click View Query Details .

Features of the Database Query Details Window

On the Database Query Details window you can:

Click Execution Plan to view an explanation plan for the query you selected on the Queries window if it was a SELECT query.

Click on the graphs to see metrics for that specific point in time.

Click the down arrow next to the database Collector name at the top of the page to choose to view the query details of a different database Collector.

On the Database Query Details window you can see the following information: query spent in the database using resources, the number of executions, and the amount of CPU time consumed. Query statistics are only available for the aforementioned database platforms.

Disk and buffer usage : Displays data when hardware monitoring is enabled for this database Collector. This graph shows at a glance how effectively the database buffer is used. SQL that runs frequently is best kept in the buffer as physical disk reads are much more time consuming. You may need to optimize your buffer manager if you see that the ratio of physical reads to buffer

Copyright © AppDynamics 2012-2017 Page 101

gets is too high.QueryD

Query Executed By : Shows the machines that executed the selected SQL statement and the percentage of the total time required to execute the statement performed by each machine. The table also shows the applications, nodes, and tiers of the machines.

<database_type> wait states : Activities that contribute to the time it takes the database to service the selected SQL statement. The wait states consuming the most time may point to performance bottlenecks. For example, a db file sequential read wait state may be caused by segment header contention on indexes or by disk contention. See your database platform documentation for descriptions of the SQL wait states and recommended actions .

Query Active in Database/Schema: Shows the schemas that have been accessed by this SQL.

Query ID (Oracle) SQL Handle (SQL Server): A unique ID that allows the database server to more quickly locate this SQL statement in cache.

Query : The entire syntax of the selected SQL statement.

To see how the SQL was executed internally within the database, click the Execution Plan tab. The statement execution plan is the sequence of operations the database performs to run the statement.

Oracle Explain Plan Limitations

For Oracle, AppDynamics Database Visibility displays execution plans for only SELECT, UPDATE, INSERT, and DELETE statements because Database Visibility relies on the Oracle EXPLAIN PLAN statement to obtain the execution plans and the

Oracle EXPLAIN PLAN statement only provides the Oracle optimizer's execution plans for SELECT, UPDATE, INSERT, and

DELETE statements. See also, User Permissions for Oracle

.

If you have a poorly performing piece of SQL that you are trying to tune, the obvious place to start it to look at the most costly step of the execution plan.

Tuning SQL is of course a vast topic, but a couple of things to look out for include:

Index or table scans: May indicate a need for better or additional indexes.

Bookmark Lookups: Consider changing the current clustered index, using a covering index and limiting the number of columns in the SELECT statement.

Copyright © AppDynamics 2012-2017 Page 102

Filter: Remove any functions in the WHERE clause, don't include views in your Transact-SQL code, may need additional indexes.

Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently?

Copyright © AppDynamics 2012-2017 Page 103

Database Query Execution Plan Window

On this page:

Access the Database Query Execution Plan Window

Features of the Database Query Execution Plan Window

Related pages:

Access Database Visibility from Application Monitoring Views

Add Database Collectors

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

The Database Query Execution Plan window can help you to determine the most efficient execution plan for your queries. Once you've discovered a potentially problematic query, you can explain the statement to check the execution plan that the database created. This execution plan may reveal that the query is not using the relevant indexes, or indexes to support the query are missing, resulting in a

SQL query that executes slowly.

Access the Database Query Execution Plan Window

To access the Database Query Execution Plan Window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Queries tab.

3. Click a SELECT statement you want to examine and click View Query Details .

4. Click Execution Plan .

Features of the Database Query Execution Plan Window

On the Database Query Execution Plan window, you can take the following actions:

Choose a database from the Explain list and then click Explain to choose a different database on which to explain the selected query.

Click Schema to choose a different schema and then explain the execution plan based on that schema.

Enter text in the Explain another query box to explain another query instead of the one you previously selected on the Queries window.

Click the down arrow next to the database Collector name at the top of the page to choose to view queries and query execution plans of a different database Collector. You can either select the database Collector name from the list or search for the database Collector in the search bar. Click the refresh icon to show only database Collectors that meet your search criteria.

If you are using Oracle, you can also take the following actions:

Select a cached execution plan to explain.

Click Explain New Plan to request a new explain plan from the agent.

Double-click a cached execution plan or select the plan and then click View Cached Plan to view the plan details.

If you are using MySQL, you can also take the following actions:

Choose to explain the query on another schema. In Plan Details , from the list on the right, choose the schema name and then click EXPLAIN .

Copy the text in the Parsed SQL output box and paste it into the Explain another query box where you can edit it and then explain the edited version of the query.

On the Database Query Execution Plan window you can see the following information:

Cached Execution Plan(s) : identifying details of the cached execution plan, which vary from one database to another.

Plan Details : execution plan details, showing the step by step procedure the database followed to process the selected query.

Referenced Objects : the database objects accessed by the execution plan.

Copyright © AppDynamics 2012-2017 Page 104

Copyright © AppDynamics 2012-2017 Page 105

Database Clients Window

On this page:

Access the Database Clients Window

Features of the Database Clients Window

Related pages:

Access Database Visibility from Application Monitoring Views

Database Queries Window

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

The database Clients window shows you the hostname or IP addresses of the Top N clients using the database. A database client is any host that accesses the database instance. To see the Top N Queries run by the client, click a Client name and then click View Top

Queries . From the Client top queries page, to see more details about a query you can double-click a query to open the

Query Details

wi ndow.

Access the Database Clients Window

To access the Database Clients window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Clients tab.

Features of the Database Clients Window

On the Database Clients window you can:

Choose to view information for the top 10, 50, 100 or 200 clients sorted by total time spent in the database.

Choose to view information for one client in particular.

Click the down arrow next to the database name at the top of the page to choose to view the database clients of a different database by either selecting the database from the list or by searching for the database by entering text in the search bar and then clicking the refresh icon to show only databases that meet that search criteria.

Click Actions to export the data on this window in a .csv formatted file that is automatically downloaded to your specified downloads directory.

On the Database Clients window you can see the following information:

Client: The names of the machines that have connected to the database.

Application: The application used on the machine. Click on individual applications to see data on the application.

Tier: The tiers in the application.

Node: The nodes in the tier.

Weight (%): The percentage of time the client was connected to the database in comparison with connection times of other clients.

Copyright © AppDynamics 2012-2017 Page 106

Database Sessions Window

On this page:

Access the Database Sessions Window

Features of the Database Sessions Window

Related pages:

Access Database Visibility from Application Monitoring Views

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

The database Sessions window shows you the Session ID of the Top N sessions using the database sorted by time spent. To see the

Top N SQL run by a session, click the Session ID and then click View Top Queries. From the Client top queries page, to see more details about a query, double-click a query to open the Query Details window and from there see the Execution Plan of the query.

Access the Database Sessions Window

To access the Database Sessions Window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Sessions tab.

Features of the Database Sessions Window

On the Database Sessions window you can:

Choose to view information for the top 10, 50, 100 or 200 sessions consuming database resources.

Double click a session ID to view the queries run in that particular session.

Click the down arrow next to the database name at the top of the page to choose to view the database sessions of a different database by either selecting the database from the list or by searching for the database by entering text in the search bar and then clicking the refresh icon to show only databases that meet that search criteria.

Click Actions to export the data on this window in a .csv formatted file that is automatically downloaded to your specified downloads directory.

On the Database Sessions window you can see the following information:

Session ID : the Session ID of each database instance usage.

Weight (%): the percentage of time that instance was using the database in comparison with the database usage of other sessions.

Copyright © AppDynamics 2012-2017 Page 107

Copyright © AppDynamics 2012-2017 Page 108

Database Schemas and Databases Windows

The Database Schemas window is available only for Oracle database servers.

The Database Databases window is available for other database servers.

The database Schemas or Databases window shows you the names of the Top N busiest schemas or databases on the database server. To see the Top N Queries run on a specific Database or Schema, click a name and then click View Top Queries . From the

Schema or Database top queries page, to see more details about a query you can double-click a query to open the

Query Details

windo w.

Access the Database Schemas or Databases Window

To access the Database Schemas or Database window

1. From AppDynamics Home, double-click the name of an database you want to see in detail on the Database Dashboard.

2. Depending on the platform, click either the Schemas or Databases tab.

Features of the Database Schemas or Databases Window

On the Database Schemas and Databases window you can:

Choose to view information for the top 10, 50, 100 or 200 schemas or databases containing the most time spent executing queries by the database server.

Double click the name of a schema or database to view the top queries for one schema database in particular, or select the schema or database and click View Top Queries .

Click the down arrow next to the Database Collector name at the top of the page to choose to view the database schemas or databases of a different database Collector by either selecting the database Collector from the list or by searching for the database Collector by entering text in the search bar and then clicking the refresh icon to show only database Collectors that meet that search criteria.

Click Actions to export the data on this window in a .csv formatted file that is automatically downloaded to your specified downloads directory.

On the Database Schemas or Databases window you can see the following information:

Schema or database: The names of the schemas or database on the database server.

Weight (%): The percentage of time the schema or database was used by the database server in comparison with usage percentage of other schemas or databases.

Copyright © AppDynamics 2012-2017 Page 109

Database Modules Window

The Database Modules window is available only for Oracle database servers. The Module field is often identical to the Program field unless it has been programmatically set with a call to DBMS_APPLICATION_INFO. Some packaged applications, such as Oracle

E-Business Suite, automatically set the Module field with relevant identifiers.

The database Modules window shows you the names of the Top N busiest modules on the Oracle database server. To see the Top N

Queries run on the database by a module, click a module name and then click View Top Queries . From the Modules top queries page, to see more details about a query you can double-click a query to open the

Query Details window.

Access the Database Modules Window

To access the Database Modules window

1. From AppDynamics Home, double-click the name of a database you want to see in detail on the Database Dashboard.

2. Click the Modules tab.

Features of the Database Modules Window

On the Database Modules window you can:

Choose to view information for the top 10, 50, 100 or 200 modules most frequently accessing the database server.

Double click the name of a module to view the top queries for one module in particular, or select the module and click View

Top Queries .

Click the down arrow next to the Database Collector name at the top of the page to choose to view the modules of a different

Oracle database Collector by either selecting the database Collector from the list or by searching for the database Collector by entering text in the search bar and then clicking the refresh icon to show only database Collectors that meet that search criteria.

Click Actions to export the data on this window in a .csv formatted file that is automatically downloaded to your specified downloads directory.

On the Database Modules window you can see the following information:

Module: The name of the module run by the active sessions in the database.

Weight (%): The percentage of time the module was consuming the database resources in comparison with usage percentage of other modules.

Copyright © AppDynamics 2012-2017 Page 110

Database Programs Window

The Database Programs window is available for Oracle and SQL Server.

The Programs window shows you the names of the Top N programs on the database instance based on time. To see the Top N

Queries run on the database by a program, click a program name and then click View Top Queries . From the Programs top queries

page, to see more details about a query you can double-click a query to open the Query Details window.

Access the Database Programs Window

To access the Database Programs window

1. From AppDynamics Home, double-click the name of a database you want to see in detail on the Database Dashboard.

2. Click the Programs tab.

Features of the Database Programs Window

On the Database Programs window you can:

Choose to view information for the top 10, 50, 100 or 200 programs most frequently accessing the database server.

Double click the name of a program to view the top queries for one program in particular, or select the program and click View

Top Queries .

Click the down arrow next to the Database Collector name at the top of the page to choose to view the programs of a different

Oracle database Collector by either selecting the database Collector from the list or by searching for the database Collector by entering text in the search bar and then clicking the refresh icon to show only database Collectors that meet that search criteria.

Click Actions to export the data on this window in a .csv formatted file that is automatically downloaded to your specified downloads directory.

On the Database Programs window you can see the following information:

Program: The name of the program run by an active session in the database.

Weight (%): The percentage of time the program was consuming the database resources in comparison with usage percentage of other programs.

Copyright © AppDynamics 2012-2017 Page 111

Database Object Browser Window

On this page:

Access the Database Objects Window

Features of the Database Objects Window

Related pages:

Access Database Visibility from Application Monitoring Views

Database Visibility

Monitor Databases and Database Servers

Monitor Database Performance

When you detect a problem with database performance, you may be able to correct the problem by adding an index, refusing access to certain users, or creating a new index on a table. You can browse through the database objects to find ways to tune the database, including the indexes that are currently available on the various tables. The contents of the Database Object Browser are updated when you access them or click Refresh.

Note: The objects available for browsing are database dependent.

Access the Database Objects Window

To access the Database Objects window

1. From AppDynamics Home, double-click the name of the database you want to see in detail on the Database Dashboard.

2. Click the Objects tab.

Features of the Database Objects Window

On the Database Objects window you can:

Click an object type in the tree to see more information about it.

For Oracle, search for a specific database item.

Click the down arrow next to the database name at the top of the page to choose to view the database objects of a different database by either selecting the database from the list or by searching for the database by entering text in the search bar and then clicking the refresh icon to show only databases that meet that search criteria.

Copyright © AppDynamics 2012-2017 Page 112

The following are some examples of browsable content.

Database uptime and version for all platforms

Users: who has access to the database for all platforms

Supported for Oracle, MySQL

Job Status: status of SQL agent job

Supported for SQL Server

Parameters: database initialization parameters

Supported for Oracle

Copyright © AppDynamics 2012-2017 Page 113

Variables: system variables indicating how the database was configured.

Current Statistics: the current value of statistics collected. The various statistics available are database dependent and are a superset of those shown in the Database Monitoring - Metric Browser page.

System Waits: SQL waits experienced by the database

Database Objects: search for specific objects, and browse through database schemas, tables, columns and indices.

Search

Copyright © AppDynamics 2012-2017 Page 114

Monitor Database Server Hardware

On this page:

Access the Database Server Hardware Metrics Window

Features of the Hardware Metrics graphs

Comparing Server and Database Metrics

Watch the video:

Access the Database Server Hardware Metrics Window

To access the Hardware Metrics

Hardware metrics are reported on:

The

Database Dashboard

window.

The

Database Live window.

The Metric Browser

Features of the Hardware Metrics graphs

On the hardware metrics graphs you can:

Click anywhere on the graphs to get details about activity at that point in time.

Double-click on KPI points in the graph to display the Metric Browser showing the selected metric. Metrics are collected by the agent and reported once a minute.

Comparing Server and Database Metrics

You can view and compare hardware and database metrics in the Metric Browser . This can help you visualize the effect of server performance on database performance.

Copyright © AppDynamics 2012-2017 Page 115

Copyright © AppDynamics 2012-2017 Page 116

Database Health Rules and Alerts

Related pages:

Alert and Respond

Policies

Health Rules

Actions

You can configure AppDynamics Database Visibility to alert you when certain conditions are met or exceeded for monitored databases, operating systems, and server hardware. Use the Getting Started Wizard to help you through the process if you're new to using

AppDynamics Pro.

You configure Health Rules, Actions, Policies, and Email Digests for monitoring databases almost exactly the same as you would configure these for monitored applications. The Affects tab of the Create Health Rule dialog is specific to Database Health Rules. In the

Affects tab, you can apply a Database Health Rule to all databases, all databases of a specific database type, or to select instances of a specific database type being monitored. You select the metrics on which to base the Database Health rule. The Health Rule is violated when specified critical or warning conditions are met.

Database Policy Actions are limited to email or SMS message notifications and custom actions that have been uploaded to the

Controller.

Once you have defined Health Rules and Actions, you can create a Policy based on a Health Rule to send you an email or an SMS message when a Health rule is violated.

Copyright © AppDynamics 2012-2017 Page 117

Database Monitoring Metrics

On this page:

Key Performance Indicators (KPI)

DB2 Server Statistics

MongoDB Server Metrics

Microsoft SQL Server Metrics

Microsoft SQL Azure Metrics

MySQL Server Metrics

Oracle Server Metrics

PostgreSQL Server Metrics

Sybase ASE and IQ Server Metrics

Related page:

Metric Browser

This document describes metrics collected by the Database Agent. It shows the path to the metric from the main AppDynamics menu down to the relevant branch of the Metric Browser tree. Some of these metrics are displayed in the Database Visibility user interface and so are also documented with the name of the window, column, section, and metric name.

The Metric Browser window name uses the following format:

Metric Browser - : When you access the Metric Browser from Applications.

Metric Browser - Database Monitoring : When you access the Metric Browser from Infrastructure.

For most types of metrics in the browser, you can click any of the points in the graph to view more information about the metric observed at that point in time. The information shown includes the metric identifier, date and time of the observation, along with any of the following values relevant to the metric:

Obs (observed value): the average of all data points seen for that interval. For a cluster or a time rollup, this represents the weighted average across nodes or over time.

Min : the minimum data point value seen for that interval

Max : the maximum data point value seen for that interval

Sum : the sum of all data point values seen for that interval.

Count : number of observations aggregated in that one point. For example, a count of 5 indicates that there were 5 1-minute data points aggregated into one point.

Key Performance Indicators (KPI)

These metrics are available for all database platforms supported.

Calls per Minute : The number of SQL calls to the database per minute.

Number of Connections: The number of connections established with the database at any point during the selected time period. A connection is a session established between a database client and a server. Since the value displayed is the average number of connections over a time range, it is common to see a very low number or 0 for this metric.

Time Spent in Execution (s): The current amount of time the database spent executing SQL statements.

DB2 Server Statistics

ACTIVE_SORTS: The number of sorts in the database that currently have a sort heap allocated.

AGENTS_TOP: At the database level, it is the maximum number of agents for all applications.

APPLS_CUR_CONS: The number of applications that are currently connected to the database.

APPLS_IN_DB2: The number of applications that are currently connected to the database, and for which the database manager is currently processing a request.

BINDS_PRECOMPILES: The number of binds and pre-compiles attempted. You can use this element to gain insight into the current

Copyright © AppDynamics 2012-2017 Page 118

level of activity within the database manager. This value does not include the count of int_auto_rebinds, but it does include binds that occur as a result of the REBIND PACKAGE command.

COMMIT_SQL_STMTS: The number of SQL COMMIT statements that have been attempted.

CONNECTIONS_TOP: The highest number of simultaneous connections to the database since the database was activated.

COORD_AGENTS_TOP: The highest number of coordinating agents. If the peak number of coordinating agents represents too high a workload for this node, you can reduce this upper boundary by changing the max_coordagents configuration parameter.

DDL_SQL_STMTS: The number of SQL Data Definition Language (DDL) statements that were executed.

DEADLOCKS: The number of deadlocks that have occurred.

DIRECT_READ_REQS: Use the following formula to calculate the average number of sectors that are read by a direct read: direct_reads / direct_read_reqs.

DIRECT_READ_TIME: Time spent doing direct read operations.

DIRECT_READS: Direct reads are performed in units, the smallest being a 512-byte sector. They are used when: Reading LONG

VARCHAR columns, Reading LOB (large object) columns, Performing a backup.

DIRECT_WRITE_REQS: Use the following formula to calculate the average number of sectors that are written by a direct write: direct_writes / direct_write_reqs.

DIRECT_WRITE_TIME: Time spent doing direct write operations.

DIRECT_WRITES: Direct writes are performed in units, the smallest being a 512-byte sector. They are used when: Writing LONG

VARCHAR columns, Writing LOB (large object) columns, Performing a restore, Performing a load, Allocating new extents for SMS table space if MPFA is enabled (which is the default).

DYNAMIC_SQL_STMTS: The number of dynamic SQL statements that were attempted.

ELAPSED_EXEC_TIME_MS: The total time (in milliseconds) required to execute all the statements for a particular application during the specified time period.

ELAPSED_EXEC_TIME_S: The total time (in seconds) required to execute all the statements for a particular application during the specified time period.

FAILED_SQL_STMTS: The number of SQL statements that were attempted, but failed.

INT_AUTO_REBINDS: The number of commits initiated internally by the database manager.

INT_COMMITS: The number of commits initiated internally by the database manager.

INT_DEADLOCK_ROLLBACKS: The number of forced rollbacks initiated by the database manager due to a deadlock. A rollback is performed on the current unit of work in an application selected by the database manager to resolve the deadlock.

INT_ROLLBACKS: The number of rollbacks initiated internally by the database manager.

INT_ROWS_DELETED: The number of rows deleted from the database as a result of internal activity.

INT_ROWS_INSERTED: The number of rows inserted into the database as a result of internal activity caused by triggers.

INT_ROWS_UPDATED: The number of rows updated from the database as a result of internal activity.

LOCK_LIST_IN_USE: The total number of bytes of lock list memory in use.

LOCK_TIMEOUTS: The number of times that a request to lock an object timed-out instead of being granted.

LOCK_WAIT_TIME: The total elapsed time (in milliseconds) spent waiting for locks.

LOCK_WAITS: The number of times that applications or connections waited for locks.

LOCKS_HELD: The number of locks currently held.

LOCKS_WAITING: The number of agents waiting on a lock.

LOG_HELD_BY_DIRTY_PAGES: The amount of log (in bytes) corresponding to the difference between the oldest dirty page in the database and the top of the active log.

Copyright © AppDynamics 2012-2017 Page 119

tables, the value of this element is given in microseconds by using the BIGINT data type.

LOG_READ_TIME_S: At the database level, this is the number of subagents for all applications.

LOG_READS: The number of log pages read from disk by the logger.

LOG_TO_REDO_FOR_RECOVERY: The size of the log (in bytes) that will have to be redone for crash recovery.

LOG_WRITE_TIME_NS: The total elapsed time spent by the logger writing log data to the disk. For event monitors that write to tables, the value of this element is given in microseconds by using the BIGINT data type.

LOG_WRITE_TIME_S: At the database level, this is the number of subagents for all applications.

LOG_WRITES: The number of log pages written to disk by the logger.

NUM_ASSOC_AGENTS: At the database level, this is the number of subagents for all applications.

NUM_INDOUBT_TRANS: The number of outstanding indoubt transactions in the database. Indoubt transactions hold log space for uncommitted transactions, which can cause the logs to become full. When the logs are full, further transactions cannot be completed.

The resolution of this problem involves a manual process of heuristically resolving the indoubt transactions. This monitor element provides a count of the number of currently outstanding indoubt transactions that must be heuristically resolved.

NUM_LOG_BUFFER_FULL: The number of times agents had to wait for log data to write to disk while copying log records into the log buffer.

NUM_LOG_DATA_FOUND_IN_BUFFER: The number of times log data was read from buffer instead of from disk, which is slower.

NUM_LOG_PART_PAGE_IO: Number of I/O requests issued by the logger for writing partial log data to disk. To determine if the current disk is adequate for logging, use this metric in conjunction with log_writes, log_write_time, and num_log_write_io.

NUM_LOG_READ_IO: Number of I/O requests issued by the logger to read log data from disk. To determine if the current disk is adequate for logging, use this metric in conjunction with log_reads and log_read_time.

NUM_LOG_WRITE_IO: Number of I/O requests issued by the logger to write log data to disk. To determine if the current disk is adequate for logging, use this metric in conjunction with log_writes and log_write_time.

POOL_ASYNC_DATA_READ_REQS : Number of asynchronous read requests by the prefetcher to the operating system. These requests are usually large block I/Os of multiple pages.

POOL_ASYNC_DATA_READS: Number of data pages read in from the table space physical containers by asynchronous engine dispatchable units for all types of table spaces. To determine the number of physical read that were performed synchronously, use this metric along with the pool_data_p_reads metrics.

POOL_ASYNC_DATA_WRITES: Number of times a buffer pool data page was physically written to disk by either an asynchronous page cleaner or prefetcher. To determine how well the buffer page cleaners are performing, use this metric in conjunction with pool_data_writes and pool_async_data_writes.

POOL_ASYNC_INDEX_READS: Number of index pages read in from the physical table space containers by asynchronous engine dispatchable units for all types of table spaces. To determine how well the prefetchers are working, company the ratio of asynchronous reads to total physical reads. Use this information to tune the num_ioservers configuration parameter.

POOL_ASYNC_INDEX_WRITES: Number of times a buffer pool index page was physically written to disk by either an asynchronous page cleaner or prefetcher.

POOL_ASYNC_READ_TIME: Total number of milliseconds spent reading in data and index pages from physical table space containers by asynchronous engine dispatchable units for all types of table spaces. Use this metric to analyze the I/O work being performed.

POOL_ASYNC_WRITE_TIME: Total number of milliseconds spent writing data or index pages from the buffer pool to disk by database manager page cleaners. Use this metric to analyze the I/O work being performed.

POOL_DATA_FROM_ESTORE: Number of buffer pool data pages read from the extended storage monitor.

POOL_DATA_L_READS: Number of data pages which have been requested from the buffer pool (logical) for regular and large table spaces. The functionality to record buffer pool information at the statement level is supported for API and CLP snapshot requests.

POOL_DATA_P_READS: Number of data pages read in from the table space containers (physical) for regular and large table spaces.

The functionality to record buffer pool information at the statement 7 level is supported for API and CLP snapshot requests.

POOL_DATA_WRITES: Number of times a buffer pool data page was physically written to disk.

Copyright © AppDynamics 2012-2017 Page 120

POOL_DRTY_PG_STEAL_CLNS: Number of times a page cleaner was invoked because a synchronous write was needed during the victim buffer replacement for the database.

POOL_DRTY_PG_THRSH_CLNS: Number of times a page cleaner was invoked because a buffer pool had reached the dirty page threshold criterion for the database.

POOL_INDEX_L_READS: Number of index pages which have been requested from the buffer pool (logical) for 9 regular and large table spaces. The functionality to record buffer pool information at the statement level is supported for API and CLP snapshot requests.

POOL_INDEX_P_READS: Number of index pages read in from the table space containers (physical) for regular and large table spaces. The functionality to record buffer pool information at the statement level is supported for API and CLP snapshot requests.

POOL_INDEX_WRITES: Number of times a buffer pool index page was physically written to disk.

POOL_LSN_GAP_CLNS: Number of times a page cleaner was invoked because the logging space used had reached a predefined criterion for the database.

POOL_NO_VICTIM_BUFFER: Number of times an agent did not have a preselected victim buffer available.

POOL_READ_TIME: Number of milliseconds spent reading in data and index pages from the physical table space for all types of table spaces.

POOL_TEMP_DATA_L_READS: Number of data pages which have been requested from the logical buffer pool for temporary table spaces.

POOL_TEMP_DATA_P_READS: Number of data pages read in from the physical table space containers for temporary table spaces.

POOL_TEMP_INDEX_L_READS: Number of index pages which were requested from the logical buffer pool for temporary table spaces.

POOL_TEMP_INDEX_P_READS: Number of index pages read in from the physical table space containers for temporary table spaces.

POOL_WRITE_TIME: Number of milliseconds spent physically writing data or index pages from the buffer pool to disk.

PREFETCH_WAIT_TIME: Number of milliseconds spent waiting for an I/O prefetcher server to finish loading pages into the buffer pool.

ROLLBACK_SQL_STMTS: The number of SQL ROLLBACK statements that have been attempted.

ROWS_DELETED: Number of row deletions attempted.

ROWS_INSERTED: Number of row insertions attempted.

ROWS_READ: Number of rows read from tables.

ROWS_SELECTED: Number of rows that have been selected and returned to the application.

ROWS_UPDATED: Number of row updates attempted.

SEC_LOG_USED_TOP: The maximum number of bytes of secondary log space used.

SEC_LOGS_ALLOCATED: Number of secondary log files currently being used for the database.

SELECT_SQL_STMTS: The number of SQL SELECT statements that were executed.

SORT_HEAP_ALLOCATED: The number of allocated pages of sort heap space for all sorts at the level chosen and at the current time.

SORT_OVERFLOWS: The number of sorts that ran out of sort heap and may have required disk space for temporary storage.

SORT_SHRHEAP_ALLOCATED: The total amount of shared sort memory allocated in the database.

SORT_SHRHEAP_TOP: Database-wide shared sort memory high-water mark in 4k pages.

STATIC_SQL_STMTS: The number of static SQL statements that were attempted.

TOT_LOG_USED_TOP: The maximum number of bytes used for log space.

TOTAL_CONS: Number of newly opened connections to the database.

TOTAL_LOG_AVAILABLE: Number of bytes of active log space in the database that is not being used by uncommitted transactions.

TOTAL_LOG_USED: Number of bytes of active log space currently used in the database.

TOTAL_SEC_CONS: The number of connections made by a subagent to the database at the node.

Copyright © AppDynamics 2012-2017 Page 121

TOTAL_SORT_TIME: The total elapsed time (in milliseconds) for all sorts that have been executed.

TOTAL_SORTS: The number of sorts that have been executed.

TOT_LOG_USED_TOP: The maximum amount of total log space used (in bytes).

UID_SQL_STMTS: Number of SQL UPDATE, INSERT, and DELETE statements that were executed.

UNREAD_PREFETCH_PAGES: Number of pages that the prefetcher read in that were never used.

MongoDB Server Metrics

asserts_msg: The number of message asserts. These are internal server errors that have a well defined text string. Stack traces are logged for these.

asserts_regular: The number of regular asserts raised since this process started.

asserts_user: The number of user asserts. These are errors that can be generated by a user such as out of disk space or duplicate key.

asserts_warning: The number of warnings raised since this process started.

BackgroundFlushing_flushes: The number of times the database has flushed all writes to disk.

BackgroundFlushing_total_ms: The number of milliseconds (ms) that the mongod processes have spent writing (i.e. flushing) data to disk.

Connections_available: The number of unused available connections that the database can provide. Consider this value in combination with the value of current to understand the connection load on the database, and the UNIX ulimit Settings document for more information about system thresholds on available connections.

Connections_current: The number of connections to the database server from clients. This number includes the current shell session.

Consider the value of available to add more context to this datum. This figure will include the current shell connection as well as any inter-node connections to support a replica set or sharded cluster.

Cursor_timedOut: The number of cursors that have timed out since the server process started. If this number is large or growing at a regular rate, this may indicate an application error.

Cursor_totalOpen: The number of cursors that MongoDB is maintaining for clients. Because MongoDB exhausts unused cursors, typically this value small or zero. However, if there is a queue, stale tailable cursors, or a large number of operations this value may rise.

globalLock_ActiveClients: The number of connected clients.

globalLock_CurrentQueue: The number of operations queued waiting for the lock. A consistently small queue, particularly of shorter operations should cause no concern. Also, consider this value in light of the size of queue waiting for the read lock (e.g. readers) and write lock (e.g. writers) individually.

Mem_mapped: The number of megabytes of memory mapped by the database. Because MongoDB uses memory-mapped files, this value will be roughly equivalent to the total size of your databases.

Mem_resident: The amount of RAM, in megabytes (MB), currently used by the database process. In normal use this value tends to grow. In dedicated database servers this number tends to approach the total amount of system memory.

Mem_virtual: The quantity, in megabytes (MB), of virtual memory used by the mongod process. With journaling enabled, the value of virtual is at least twice the value of mapped. If virtual value is significantly larger than mapped (e.g. 3 or more times), this may indicate a memory leak.

Network_bytesIn: The amount of network traffic, in bytes, received by this database. Use this value to ensure that network traffic sent to the mongod process is consistent with expectations and overall inter-application traffic.

Network_bytesOut: The amount of network traffic, in bytes, sent from this database. Use this value to ensure that network traffic sent by the mongod process is consistent with expectations and overall inter-application traffic.

Network_numRequests: The number of distinct requests that the server has received. Use this value to provide context for the bytesIn and bytesOut values to ensure that MongoDB network utilization is consistent with expectations and application use.

OpCounters_command: The number of commands sent to MongoDB.

OpCounters_delete: The number of Delete operations.

OpCounters_getmore: The number of GetMore operations.

Copyright © AppDynamics 2012-2017 Page 122

OpCounters_insert: The number of Insert operations.

OpCounters_query: The number of Query operations.

OpCounters_update: The number of Update operations.

Repl_command: The number of Replicated Commands issued to the database.

Repl_delete: The number of Replicated Delete operations.

Repl_getmore: The number of GetMore operations. This counter can be high even if the query count is low. Secondary nodes send getMore operations as part of the replication process.

Repl_insert: The number of replicated insert operations.

Repl_query: The number of Replicated Queries.

Repl_update: The number of Replicated Update Operations.

Index_missRatio: Ratio of index hits to misses. If there are a lot of index misses then you should look at your queries to see if they are optimally using your indexes. You may need to add new indexes to make the queries run faster. You can explain the query to see see which index queries are hitting and the total execution time so you can compare query performance before and after adding the new indexes.

Microsoft SQL Server Metrics

Active cursors: The number of active cursors.

Active Temp Tables: The number of temporary tables/table variables in use.

Active Transactions: The number of active transactions for the database. AU cleanup batches/sec The number of batches per second that were completed successfully by the background task that cleans up deferred dropped allocation units.

AU cleanup batches/sec: The number of batches per second that were completed successfully by the background task that cleans up deferred dropped allocation units.

AU cleanups/sec: The number of allocation units per second that were successfully dropped the background task that cleans up deferred dropped allocation units. Each allocation unit drop requires multiple batches.

Auto-Param Attempts/sec: The number of auto-parameterization attempts per second. Total should be the sum of the failed, safe, and unsafe auto-parameterizations. Auto-parameterization occurs when an instance of SQL Server tries to parameterize a Transact-SQL request by replacing some literals with parameters so that reuse of the resulting cached execution plan across multiple similar-looking requests is possible. Note that auto-parameterizations are also known as simple parameterizations in newer versions of SQL Server.

This counter does not include forced parameterizations.

Average Latch Wait Time (ms): Average latch wait time (in milliseconds) for latch requests that had to wait.

Average Wait Time (ms): Average amount of wait time (in milliseconds) for each lock request that resulted in a wait.

Backup/Restore Throughput/sec: Read/write throughput for backup and restore operations of a database per second. For example, you can measure how the performance of the database backup operation changes when more backup devices are used in parallel or when faster devices are used. Throughput of a database backup or restore operation allows you to determine the progress and performance of your backup and restore operations.

Batch Requests/sec: The number of Transact-SQL command batches received per second. This statistic is affected by all constraints

(such as I/O, number of users, cache size, complexity of requests, and so on). High batch requests mean good throughput.

Buffer cache hit ratio: Percentage of pages found in the buffer cache without having to read from disk. The ratio is the total number of cache hits divided by the total number of cache lookups over the last few thousand page accesses. The ratio is displayed as a percentage. After a long period of time, the ratio moves very little. 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 SQL Server.

Bulk Copy Rows/sec: The number of rows bulk copied per second.

Bulk Copy Throughput/sec: Amount of data bulk copied (in kilobytes) per second.

By-reference Lob Create Count: Count of large object (lob) values that were passed by reference. By-reference lobs are used in certain bulk operations to avoid the cost of passing them by value.

By-reference Lob Use Count: Count of by-reference lob values that were used. By-reference lobs are used in certain bulk operations

Copyright © AppDynamics 2012-2017 Page 123

to avoid the cost of passing them by-value.

Cache Hit Ratio: Ratio between cache hits and lookups. The ratio is displayed as a percentage.

Cache Object Counts: The number of cache objects in the cache.

Cache Objects in use: The number of cache objects in use.

Cache Pages: The number of 8-kilobyte (KB) pages used by cache objects.

Cached Cursor Counts: The number of cursors of a given type in the cache.

Checkpoint pages/sec: The number of pages flushed to disk per second by a checkpoint or other operation that require all dirty pages to be flushed.

CLR Execution: Total execution time in CLR (microseconds)

Connection Memory (KB): Total amount of dynamic memory the server is using for maintaining connections.

Count Lob Readahead: Count of lob pages on which readahead was issued.

Count Pull In Row: Count of column values that were pulled in-row from off-row. For more information about row overflow, see

Count Push Off Row: Count of column values that were pushed from in-row to off-row. For more information about row overflow, see

Cursor memory usage: Amount of memory consumed by cursors in kilobytes (KB).

Count/sec: Times each type of cached cursor has been used. Cursor memory usage Amount of memory consumed by cursors in kilobytes (KB).

Cursor Requests/sec: The number of SQL cursor requests received by server. Cursor worktable usage Number of worktables used by cursors. Data File(s) Size (KB) Cumulative size (in kilobytes) of all the data files in the database including any automatic growth.

Monitoring this counter is useful, for example, for determining the correct size of Database pages Number of pages in the buffer pool with database content.

Cursor worktable usage: Number of worktables in use by cursors.

Data File(s) Size(KB): Cumulative size (Kb) of all data files in the database including any automatic growth. Monitoring this counter to determine the correct size of tempdb .

Database pages: Number of database pages in use.

DBCC Logical Scan Bytes/sec: The number of logical read scan bytes per second for database console commands (DBCC).

Deferred Dropped rowsets: The number of rowsets created as a result of aborted online index build operations that are waiting to be dropped by the background task that cleans up deferred dropped rowsets.

Dropped rowset cleanups/sec: The number of rowsets per second created as a result of aborted online index build operations that were successfully dropped by the background task that cleans up deferred dropped rowsets.

Dropped rowsets skipped/sec: The number of rowsets per second created as a result of aborted online index build operations that were skipped by the background task that cleans up deferred dropped rowsets created.

Errors/sec: The number of errors/sec.

Event Notifications Delayed Drop: The number of event notifications waiting to be dropped by a system thread.

Extent Deallocations/sec: The number of extents deallocated per second in all databases in this instance of SQL Server.

Extents Allocated/sec: The number of extents allocated per second in all databases in this instance of SQL Server.

Failed AU cleanup batches/sec: The number of batches per second that failed and required retry, by the background task that cleans up deferred dropped allocation units. Failure could be due to lack of memory or disk space, hardware failure and other reasons.

Failed Auto-Params/sec: The number of failed auto-parameterization attempts per second. This should be small. Note that auto-parameterizations are also known as simple parameterizations in later versions of SQL Server.

Failed leaf page cookie: The number of times that a leaf page cookie could not be used during an index search since changes happened on the leaf page. The cookie is used to speed up index search.

Failed tree page cookie: The number of times that a tree page cookie could not be used during an index search since changes happened on the parent pages of those tree pages. The cookie is used to speed up index search.

Forced Parameterizations/sec: The number of successful forced parameterizations per second.

Copyright © AppDynamics 2012-2017 Page 124

Forwarded Records/sec: The number of records per second fetched through forwarded record pointers.

Free list stalls/sec: The number of requests per second that had to wait for a free page.

Free Space in tempdb (KB): The amount of space (in kilobytes) available in FreeSpace Page.

FreeSpace Page Fetches/sec: Number of pages fetched/second by free space scans. These scans search for free space within pages already allocated to an allocation unit, to address requests to insert or modify record fragments.

FreeSpace Scans/sec: The number of scans per second that were initiated to search for free space within pages already allocated to an allocation unit to insert or modify record fragment. Each scan may find multiple pages.

Full Scans/sec: The number of unrestricted full scans per second. These can be either base-table or full-index scans.

Granted Workspace Memory (KB): Total amount of memory currently granted to executing processes such as hash, sort, bulk copy, and index creation operations.

Guided Plan Executions/sec: The number of plan executions per second in which the query plan has been generated by using a plan guide.

HTTP Authenticated Requests: The number of authenticated HTTP requests started per second. Index Searches/sec Number of index searches per second. These are used to start a range scan, reposition a range scan, revalidate a scan point, fetch a single index record, and search down the index to locate where to insert a new row.

Index Searches/sec: Number of index searches per second. These are used to start a range scan, reposition a range scan, revalidate a scan point, fetch a single index record, and search down the index to locate where to insert a new row.

Latch Waits/sec: The number of latch requests that could not be granted immediately.

Lazy writes/sec: The number of buffers written per second by the buffer manager's lazy writer. The lazy writer is a system process that flushes out batches of dirty, aged buffers (buffers that contain changes that must be written back to disk before the buffer can be reused for a different page) and makes them available to user processes. The lazy writer eliminates the need to perform frequent checkpoints in order to create available buffers.

LobHandle Create Count: Count of temporary lobs created.

LobHandle Destroy Count: Count of temporary lobs destroyed.

LobSS Provider Create Count: Count of LOB Storage Service Providers (LobSSP) created. One worktable created per LobSSP.

LobSS Provider Destroy Count: Count of LobSSP destroyed.

LobSS Provider Truncation Count: Count of LobSSP truncated.

Lock Blocks: Current number of lock blocks in use on the server (refreshed periodically). A lock block represents an individual locked resource, such as a table, page, or row.

Lock Blocks Allocated: Current number of allocated lock blocks. At server startup, the number of allocated lock blocks plus the number of allocated lock owner blocks depends on the SQL Server

Lock Memory (KB): Total amount of dynamic memory the server is using for locks.

Lock Owner Blocks: The number of lock owner blocks currently in use on the server (refreshed periodically). A lock owner block represents the ownership of a lock on an object by an individual thread. Therefore, if three threads each have a shared (S) lock on a page, there will be three lock owner blocks.

Lock Owner Blocks Allocated: Current number of allocated lock owner blocks. At server startup, the number of allocated lock owner blocks and the number of allocated lock blocks depend on the SQL

Lock Requests/sec: The number of new locks and lock conversions per second requested from the lock manager.

Lock Timeouts (timeout > 0)/sec: The number of lock requests per second that timed out, but excluding requests for NOWAIT locks.

Lock Timeouts/sec: The number of lock requests per second that timed out, including requests for NOWAIT locks.

Lock Wait Time (ms): Total wait time (in milliseconds) for locks in the last second.

Lock Waits/sec: The number of lock requests per second that required the caller to wait.

Log Bytes Flushed/sec: Total number of log bytes flushed.

Log Cache Hit Ratio: Percentage of log cache reads satisfied from the log cache.

Log Cache Reads/sec: Reads performed per second through the log manager cache.

Copyright © AppDynamics 2012-2017 Page 125

Log File(s) Size (KB): Cumulative size (in kilobytes) of all the transaction log files in the database.

Log File(s) Used Size (KB): The cumulative used size of all the log files in the database.

Log Flush Wait Time Total wait time (in milliseconds) to flush the log.

Log Flush Waits/sec: The number of commits per second waiting for the log flush.

Log Flushes/sec: The number of log flushes per second.

Log Growths: Total number of times the transaction log for the database has been expanded.

Log Shrinks: Total number of times the transaction log for the database has been shrunk.

Log Truncations: Total number of times the transaction log for the database has been truncated.

Logical Connections: The number of logical connections to the system.

Logins/sec: Total number of logins started per second. This does not include pooled connections.

Logouts/sec: Total number of logout operations started per second.

Longest Transaction Running Time: The length of time (in seconds) since the start of the transaction that has been active longer than any other current transaction.

Mars Deadlocks: The number of Mars Deadlocks detected.

Maximum Workspace Memory (KB): Maximum amount of memory available for executing processes such as hash, sort, bulk copy, and index creation operations.

Memory Grants Outstanding: Total number of processes that have successfully acquired a workspace memory grant.

Memory Grants Pending: Total number of processes waiting for a workspace memory grant.

Mixed page allocations/sec: The number of pages allocated per second from mixed extents. These could be used for storing the IAM pages and the first eight pages that are allocated to an allocation unit.

Non-atomic yield rate: The number of non-atomic yields per second.

NonSnapshot Version Transactions: The number of currently active transactions that are not using snapshot isolation level and have made data modifications that have generated row versions in the Number of active cursor plans Number of cursor plans.

Number of active cursor plans: Number of cursor plans.

Number of Deadlocks/sec: The number of lock requests per second that resulted in a deadlock.

Number of SuperLatches: The number of latches that are currently SuperLatches.

Optimizer Memory (KB) : Total amount of dynamic memory the server is using for query optimization.

Page compression attempts/sec: The number of pages evaluated for page-level compression. Includes pages that were not compressed because significant savings could be achieved. Includes all objects in the instance of SQL Server. For information about specific objects, see sys.dm_db_index_operational_stats (Transact-SQL).

Page Deallocations/sec: The number of pages deallocated per second in all databases in this instance of SQL Server. These include pages from mixed extents and uniform extents.

Page life expectancy: The number of seconds a page will stay in the buffer pool without references.

Page lookups/sec: The number of requests per second to find a page in the buffer pool.

Page reads/sec: The number of physical database page reads that are issued per second. This statistic displays the total number of physical page reads across all databases. Because physical I/O is expensive, you may be able to minimize the cost, either by using a larger data cache, intelligent indexes, and more efficient queries, or by changing the database design.

Page Splits/sec: The number of page splits per second that occur as the result of overflowing index pages.

Page writes/sec: The number of physical database page writes issued per second.

Pages Allocated/sec: The number of pages allocated per second in all databases in this instance of SQL Server. These include pages allocations from both mixed extents and uniform extents.

Pages compressed/sec: The number of data pages that are compressed by using PAGE compression. Includes all objects in the instance of SQL Server. For information about specific objects, see sys.dm_db_index_operational_stats (Transact-SQL).

Copyright © AppDynamics 2012-2017 Page 126

Percent Log Used: Percentage of space in the log that is in use.

Probe Scans/sec: The number of probe scans per second that are used to find at most one single qualified row in an index or base table directly.

Processes blocked: The number of currently blocked processes.

Range Scans/sec: The number of qualified range scans through indexes per second.

Readahead pages/sec: The number of pages read per second in anticipation of use.

Repl. Trans. Rate: The number of transactions per second read out of the transaction log of the publication database and delivered to the distribution database.

Safe Auto-Params/sec: The number of safe auto-parameterization attempts per second. Safe refers to a determination that a cached execution plan can be shared between different similar-looking Transact-SQL statements. SQL Server makes many auto-parameterization attempts some of which turn out to be safe and others fail. Note that auto-parameterizations are also known as simple parameterizations in later versions of SQL Server. This does not include forced parameterizations.

Scan Point Revalidations/sec: The number of times per second that the scan point had to be revalidated to continue the scan.

Skipped Ghosted Records/sec: The number of ghosted records per second skipped during scans.

Snapshot Transactions: The number of currently active transactions using the snapshot isolation level. N.B. The SOAP Empty

Requests Number of empty SOAP requests started per second.

SOAP Empty Requests: The number of SOAP method invocations passed to the stored procedure (or template) with an empty string as its value (not a NULL value) in order to provide an included input parameter with no value assigned to it.

SOAP Method Invocations: The number of SOAP method invocations started per second.

SOAP Session Initiate Requests: The number of SOAP Session initiate requests started per second.

SOAP Session Terminate Requests: The number of SOAP Session terminate requests started per second.

SOAP SQL Requests: The number of SOAP SQL requests started per second.

SOAP WSDL Requests: The number of SOAP Web Service Description Language requests started per second.

SQL Attention rate: The number of attentions per second. An attention is a request by the client to end the currently running request.

SQL Cache Memory (KB): Total amount of dynamic memory the server is using for the dynamic SQL cache.

SQL Compilations/sec: The number of SQL compilations per second. Indicates the number of times the compile code path is entered.

Includes compiles caused by statement-level recompilations in SQL Server. After SQL Server user activity is stable, this value reaches a steady state.

SQL Re-Compilations/sec: The number of statement recompiles per second. Counts the number of times statement recompiles are triggered. Generally, you want the recompiles to be low. In later versions of SQL Server, recompilations are statement-scoped instead of batch-scoped recompilations in Microsoft SQL Server 2000. Therefore, direct comparison of values of this counter between SQL

Server and earlier versions is not possible.

Stored Procedures Invoked/sec: This counter reports the total number of activation stored procedures invoked by all queue monitors in the instance per second.

SuperLatch Demotions/sec: The number of SuperLatches that have been demoted to regular latches in the last second.

SuperLatch Promotions/sec: The number of latches that have been promoted to SuperLatches in the last second.

Table Lock Escalations/sec: The number of times locks on a table were escalated to the TABLE or HoBT granularity. Target pages

Ideal number of pages in the buffer pool.

Target pages: Ideal number of pages in the buffer pool.

Target Server Memory (KB): Total amount of dynamic memory the server can consume.

Task Limit Reached: The number of times that a queue monitor would have started a new task, but did not because the maximum number of tasks for the queue is already running.

Task Limit Reached/sec: The number of times per second that a queue monitor would have started a new task, but did not because the maximum number of tasks for the queue is already running.

Tasks Aborted/sec: The number of activation stored procedure tasks that end with an error, or are aborted by a queue monitor for failing to receive messages.

Copyright © AppDynamics 2012-2017 Page 127

Tasks Running: The number of activation stored procedures that are currently running.

Tasks Started/sec: The number of activation stored procedures started per second by all queue monitors in the instance.

Temp Tables Creation Rate: The number of temporary tables/table variables created per second.

Temp Tables For Destruction: The number of temporary tables/table variables waiting to be destroyed by the cleanup system thread.

Total Latch Wait Time (ms): Total latch wait time (in milliseconds) for latch requests in the last second.

Total Server Memory (KB): The committed memory from the buffer pool (in kilobytes).

Transactions/sec: The number of transactions started for the database per second.

Unsafe Auto-Params/sec: The number of unsafe auto-parameterization attempts per second. For example, the query has some characteristics that prevent the cached plan from being shared. These are designated as unsafe. This does not count the number of forced parameterizations.

Update conflict ratio: The percentage of those transactions using the snapshot isolation level that have encountered update conflicts within the last second. An update conflict occurs when a snapshot isolation level transaction attempts to modify a row that last was modified by another transaction that was not committed when the snapshot isolation level transaction started.

Update Snapshot Transactions: The number of currently active transactions using the snapshot isolation level and have modified data.

Used leaf page cookie: The number of times a leaf page cookie is used successfully during an index search since no change happened on the leaf page. The cookie is used to speed up index search.

Used tree page cookie: The number of times a tree page cookie is used successfully during an index search since no change happened on the parent page of the tree page. The cookie is used to speed up index search.

User Connections: The number of users currently connected to SQL Server.

Version Cleanup rate (KB/s): The rate (in kilobytes per second) at which row versions are removed from the snapshot isolation version store.

Version Generation rate (KB/s): The rate (in kilobytes per second) at which new row versions are added to the snapshot isolation version store.

Version Store Size (KB): The amount of space (in kilobytes) in Version Store unit count The number of active allocation units in the snapshot isolation version store.

Version Store unit creation: The number of allocation units that have been created in the snapshot isolation store since the instance of the Database Engine was started.

Version Store unit truncation: The number of allocation units that have been removed from the snapshot isolation store since the instance of the Database Engine was started.

Workfiles Created/sec: The number of work files created per second. For example, work files could be used to store temporary results for hash joins and hash aggregates.

Worktables Created/sec: The number of work tables created per second. For example, work tables could be used to store temporary results for query spool, lob variables, XML variables, and cursors.

Worktables From Cache Ratio: Percentage of work tables created where the initial two pages of the work table were not allocated but were immediately available from the work table cache. (When a work table is dropped, two pages may remain allocated and they are returned to the work table cache. This increases performance.)

Write Transactions/sec: The number of transactions that wrote to the database and committed, in the last second.

Microsoft SQL Azure Metrics

avg_cpu_percent: Average compute utilization in percentage of the limit of the service tier.

avg_data_io_percent: Average data I/O utilization in percentage based on the limit of the service tier.

avg_log_write_percent: Average write resource utilization in percentage of the limit of the service tier.

avg_memory_percent: Average memory utilization in percentage of the limit of the service tier.

Copyright © AppDynamics 2012-2017 Page 128

MySQL Server Metrics

Aborted_clients: The number of clients that were aborted (because they did not properly close the connection to the MySQL server).

For some applications this can be OK, but for some other applications you might want to track the value, as aborted connects may indicate some sort of application failure.

Aborted_connects: The number of failed attempts to connect to the MySQL server.

Bytes_received: The number of bytes received from all clients.

Bytes_sent: The number of bytes sent to all clients.

Com_alter_table: The number of times each ALTERTABLE statement has been executed.

Com_create_index: The number of times each CREATE INDEX statement has been executed.

Com_create_table: The number of times each CREATE TABLE statement has been executed.

Com_delete: The number of times each DELETE statement has been executed.

Com_insert: The number of times each INSERT statement has been executed.

Com_optimize: The number of times each OPTIMIZE statement has been executed.

Com_select: The number of times each SELECT statement has been executed.

Com_update: The number of times each UPDATE statement has been executed.

Connections: The number of connection attempts (successful or not) to the MySQL server.

Created_tmp_disk_tables: The number of temporary tables on disk created automatically by the server while executing statements.

Created_tmp_files: How many temporary files mysqld has created.

Created_tmp_tables: The number of in-memory temporary tables created automatically by the server while executing statements. If

Created_tmp_disk_tables is large, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.

Handler_delete: The number of times that rows have been deleted from tables.

Innodb_buffer_pool_pages_data: The number of pages containing data (dirty or clean).

Innodb_buffer_pool_pages_dirty: The number of pages currently dirty.

Innodb_buffer_pool_pages_flushed: The number of buffer pool page-flush requests.

Innodb_buffer_pool_pages_free: The number of free pages.

Innodb_buffer_pool_pages_misc: The number of pages that are busy because they have been allocated for administrative overhead such as row locks or the adaptive hash index. This value can also be calculated as Innodb_buffer_pool_pages_total.

Innodb_buffer_pool_pages_total: The total size of the buffer pool, in pages.

Innodb_buffer_pool_read_ahead_rnd: The number of random read-aheads initiated by InnoDB. This happens when a query scans a large portion of a table but in random order.

Innodb_buffer_pool_read_requests: The number of logical read requests InnoDB has done.

Innodb_buffer_pool_reads: The number of logical reads that InnoDB could not satisfy from the buffer pool and had to do a single-page read.

Innodb_buffer_pool_wait_free: Normally, writes to the InnoDB buffer pool happen in the background. However, if it is necessary to read or create a page and no clean pages are available, it is also necessary to wait for pages to be flushed first. This counter counts instances of these waits. If the buffer pool size has been set properly, this value should be small.

Innodb_buffer_pool_write_requests: The number writes done to the InnoDB buffer pool.

Innodb_data_fsyncs: The number of fsync() operations so far.

Innodb_data_pending_fsyncs: The current number of pending fsync() operations.

Innodb_data_pending_reads: The current number of pending reads.

Copyright © AppDynamics 2012-2017 Page 129

Innodb_data_pending_writes: The current number of pending writes.

Innodb_data_read: The amount of data read so far, in bytes.

Innodb_data_reads: The total number of data reads.

Innodb_data_writes: The total number of data writes.

Innodb_data_written: The amount of data written so far, in bytes.

Innodb_dblwr_pages_written: The number of doublewrite operations that have been performed.

Innodb_dblwr_writes: The number of pages that have been written for doublewrite operations.

Innodb_log_waits: The number of times that the log buffer was too small and a wait was required for it to be flushed before continuing.

Innodb_log_write_requests: The number of log write requests.

Innodb_log_writes: The number of physical writes to the log file.

Innodb_pages_created: The number of pages created.

Innodb_pages_read: The number of pages read.

Innodb_pages_written: The number of pages written.

Innodb_row_lock_current_waits: The number of row locks currently being waited for.

Innodb_row_lock_time: The total time spent in acquiring row locks, in milliseconds.

Innodb_row_lock_time_avg: The average time to acquire a row lock, in milliseconds.

Innodb_row_lock_time_max: The maximum time to acquire a row lock, in milliseconds.

Innodb_row_lock_waits: The number of times a row lock had to be waited for.

Innodb_rows_deleted: The number of rows deleted from InnoDB tables.

Innodb_rows_inserted: The number of rows inserted into InnoDB tables.

Innodb_rows_read: The number of rows read from InnoDB tables.

Innodb_rows_updated: The number of rows updated in InnoDB tables.

Key_blocks_used: The number of used blocks in the key cache. This value is a high-water mark that indicates the maximum number of blocks that have ever been in use at one time.

Key_read_requests: The number of requests to read a key block from the cache. Key_writes The number of physical writes of a key block to disk.

Key_reads: The number of physical reads of a key block from disk. If Key_reads is large, then your key_buffer_size value is probably too small. The cache miss rate can be calculated as Key_reads/Key_read_requests.

Key_write_requests: The number of requests to write a key block to the cache.

Key_writes: The number of physical writes of a key block from the MyISAM key cache to the physical disk.

Open_files: The number of files that are open. Open_streams The number of streams that are open (used mainly for logging).

Open_tables: The number of table cache misses. If the value is large, you probably need to increase table_cache. Typically you would want this to be less than 1 or 2 opened tables per second.

Opened_tables: The number of tables that have been opened. The number of tables that have been opened. If Opened_tables is big, your table_cache value is probably too small.

Qcache_free_blocks: The number of free memory blocks in the query cache.

Qcache_free_memory: The amount of free memory for the query cache.

Qcache_hits: The number of query cache hits.

Qcache_inserts: The number of queries added to the query cache.

Qcache_lowmem_prunes: The number of queries that were deleted from the query cache because of low memory.

Copyright © AppDynamics 2012-2017 Page 130

Qcache_not_cached: The number of non-cached queries (not cacheable, or not cached due to the query_cache_type setting).

Qcache_queries_in_cache: The number of queries registered in the query cache.

Qcache_total_blocks: The total number of blocks in the query cache.

Questions: The number of statements that clients have sent to the server.

Select_full_join: Joins performed without keys. This should be zero. This is a good way to catch development errors, as just a few such queries can degrease the system's performance.

Select_full_range_join: The number of joins that used a range search on a reference table.

Select_range: The number of joins that used ranges on the first table. This is normally not a critical issue even if the value is quite large.

Select_range_check: The number of joins without keys that check for key usage after each row. If this is not 0, you should carefully check the indexes of your tables.

Select_scan: Number of queries that performed a full table scan. In some cases these are OK but their ratio to all queries should be constant. if you have the value growing it can be a problem with the optimizer, lack of indexes or some other problem.

Slave_open_temp_tables: The number of temporary tables that the slave SQL thread currently has open.

Slow_launch_threads: The number of threads that have taken more than slow_launch_time seconds to create.

Slow_queries: The number of queries longer than --long-query-time or that are not using indexes. These should be a small fraction of all queries. If it grows, the system will have performance problems.

Sort_merge_passes: The number of merge passes that the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable.

Sort_range: The number of sorts that were done using ranges.

Threads_cached: The number of threads in the thread cache.

Threads_connected: The number of currently open connections.

Threads_created: This should be low. Higher values may mean that you need to increase the value of thread_cache or you have the amount of connections increasing, which also indicates a potential problem.

Threads_running: The number of threads that are not sleeping.

Oracle Server Metrics

bytes received via SQL*Net from client: Total number of bytes received from the client over Oracle Net Services

bytes received via SQL*Net from dblink: Total number of bytes received from a database link over Oracle Net Services

bytes sent via SQL*Net to client: Total number of bytes sent to the client from the foreground processes

bytes sent via SQL*Net to dblink: Total number of bytes sent over a database link

cluster key scan block gets: The number of blocks obtained in a cluster scan

cluster key scans: The number of cluster scans that were started

commit cleanouts: Total number of times the cleanout block at commit function was performed

commit cleanouts successfully completed: The number of times the cleanout block at commit function completed successfully

Commit SCN cached: The number of times the system change number of a commit operation was cached

consistent changes: The number of times a user process has applied rollback entries to perform a consistent read on the blockWork loads that produce a great deal of consistent changes can consume a great deal of resources. The value of this statistic should be small in relation to the consistent gets statistic.

consistent gets: The number of times a consistent read was requested for a block.See Also: consistent changes and session logical reads statistics

consistent gets direct: The number of times a consistent read was requested for a block bypassing the buffer cache (for example, direct load operation). This is a subset of consistent gets statistics value.

Copyright © AppDynamics 2012-2017 Page 131

consistent gets from cache: The number of times a consistent read was requested for a block from buffer cache. This is a subset of consistent gets statistics value.

CPU used by this session: Amount of CPU time (in 10s of milliseconds) used by a session from the time a user call starts until it ends.

If a user call completes within 10 milliseconds, the start and end user-call time are the same for purposes of this statistics, and 0 milliseconds are added.

CPU used when call started: The CPU time used when the call is started. See Also: CPU used by this session

CR blocks created: The number of CURRENT blocks cloned to create CR (consistent read) blocks. The most common reason for cloning is that the buffer is held in a incompatible mode.

current blocks converted for CR: The number CURRENT blocks converted to CR state

cursor authentications: The number of privilege checks conducted during execution of an operation

data blocks consistent reads - undo records applied: The number of undo records applied to data blocks that have been rolled back for consistent read purposes

db block changes: Closely related to consistent changes, this statistic counts the total number of changes that were part of an update or delete operation that were made to all blocks in the SGA. Such changes generate redo log entries and hence become permanent changes to the database if the transaction is committed.This approximates total database work. It statistic indicates the rate at which buffers are being dirtied (on a per-transaction or per-second basis, for example).

db block gets: The number of times a CURRENT block was requestedSee Also: consistent gets

db block gets direct: The number of times a CURRENT block was requested bypassing the buffer cache (for example, a direct load operation). This is a subset of db block gets statistics value.

db block gets from cache: The number of times a CURRENT block was requested from the buffer cache. This is a subset of db block gets statistics value.

DBWR checkpoint buffers written: The number of buffers that were written for checkpoints

DBWR checkpoints: The number of times the DBWR was asked to scan the cache and write all blocks marked for a checkpoint or the end of recovery. This statistic is always larger than background checkpoints completed.

DBWR lru scans: The number of times that DBWR scans the LRU queue looking for buffers to write. This count includes scans to fill a batch being written for another purpose (such as a checkpoint). This statistic is always greater than or equal to DBWR make free requests.

DBWR revisited being-written buffer: The number of times that DBWR tried to save a buffer for writing and found that it was already in the write batch. This statistic measures the amount of useless work that DBWR had to do in trying to fill the batch.Many sources contribute to a write batch. If the same buffer from different sources is considered for adding to the write batch, then all but the first attempt will be useless because the buffer is already marked as being written.

DBWR transaction table writes: The number of rollback segment headers written by DBWR. This statistic indicates how many hot buffers were written, causing a user process to wait while the write completed.

DBWR undo block writes: The number of rollback segment blocks written by DBWR.

DDL statements parallelized: The number of DDL statements that were executed in parallel.

deferred (CURRENT) block cleanout applications: The number of times cleanout records are deferred, piggyback with changes, always current get.

DFO trees parallelized: The number of times a serial execution plan was converted to a parallel plan.

dirty buffers inspected: The number of dirty buffers found by the user process while the it is looking for a buffer to reuse.

DML statements parallelized: The number of DML statements that were executed in parallel.

enqueue conversions: Total number of conversions of the state of table or row lock.

enqueue deadlocks: Total number of deadlocks between table or row locks in different sessions.

enqueue releases: Total number of table or row locks released.

enqueue requests: Total number of table or row locks acquired.

enqueue timeouts: Total number of table and row locks (acquired and converted) that timed out before they could complete.

enqueue waits: Total number of waits that occurred during an enqueue convert or get because the enqueue get was deferred

Copyright © AppDynamics 2012-2017 Page 132

exchange deadlocks: The number of times that a process detected a potential deadlock when exchanging two buffers and raised an internal, restartable error. Index scans are the only operations that perform exchanges.

execute count: Total number of calls (user and recursive) that executed SQL statements.

free buffer inspected: The number of buffers skipped over from the end of an LRU queue in order to find a reusable buffer. The difference between this statistic and dirty buffers inspected is the number of buffers that could not be used because they had a user, a waiter, or were being read or written, or because they were busy or needed to be written after rapid aging out.

free buffer requested: The number of times a reusable buffer or a free buffer was requested to create or load a block.

gc current block receive time: The total time required for consistent read requests to complete. It records the round-trip time for all requests for consistent read blocks.

gc current block send time: The time it takes to send the current block to the requesting instance over the interconnect.

gcs messages sent: Global Cache Services (GCS) Messages Sent.

ges messages sent: Global Enqueue Services (GES) Messages Sent.

hot buffers moved to head of LRU: When a hot buffer reaches the tail of its replacement list, Oracle moves it back to the head of the list to keep it from being reused. This statistic counts such moves.

immediate (CR) block cleanout applications: The number of times cleanout records are applied immediately during consistent-read requests.

immediate (CURRENT) block cleanout applications: The number of times cleanout records are applied immediately during current gets. Compare this statistic with deferred (CURRENT) block cleanout applications.

index fast full scans (direct read): The number of fast full scans initiated using direct read.

index fast full scans (full): The number of fast full scans initiated for full segments.

index fast full scans (rowid ranges): The number of fast full scans initiated with rowid endpoints specified.

leaf node splits: The number of times an index leaf node was split because of the insertion of an additional value.

lob reads: The number of LOB API read operations performed in the session/system. A single LOB API read may correspond to multiple physical/logical disk block reads.

lob writes: The number of LOB API write operations performed in the session/system. A single LOB API write may correspond to multiple physical/logical disk block writes.

lob writes unaligned: The number of LOB API write operations whose start offset or buffer size is not aligned to the internal chunk size of the LOB. Writes aligned to chunk boundaries are the most efficient write operations. The internal chunk size of a LOB is available through the LOB API (for example, DBMS_LOB.GETCHUNKSIZE()).

logons cumulative: Total number of logons since the instance started. Useful only in V$SYSSTAT. It gives an instance overview of all processes that logged on.

logons current: Total number of current logons. Useful only in V$SYSSTAT.

messages received: The number of messages sent and received between background processes.

messages sent: The number of messages sent and received between background processes native hash arithmetic execute Number of hash operations performed using native arithmetic rather than Oracle NUMBERs.

no buffer to keep pinned count: The number of times a visit to a buffer attempted, but the buffer was not found where expected. Like buffer is not pinned count and buffer is pinned count, this statistic is useful only for internal debugging purposes.

no work - consistent read gets: The number consistent gets that require neither block cleanouts nor rollbacks.See Also: consistent gets.

Number of Small Reads: The total number of physical reads less the number of physical read total multi block requests .

Number of Small Writes: The total number of physical writes less the number of physical write total multi block requests .

opened cursors cumulative: Total number of cursors opened since the instance started. In V$SESSTAT: Total number of cursors opened since the start of the session.

opened cursors current: Total number of current open cursors.

Parallel operations downgraded 1 to 25 pct: The number of times parallel execution was requested and the degree of parallelism

Copyright © AppDynamics 2012-2017 Page 133

was reduced because of insufficient parallel execution servers.

Parallel operations downgraded 25 to 50 pct: The number of times parallel execution was requested and the degree of parallelism was reduced because of insufficient parallel execution servers.

Parallel operations downgraded 50 to 75 pct: The number of times parallel execution was requested and the degree of parallelism was reduced because of insufficient parallel execution servers.

Parallel operations downgraded 75 to 99 pct: The number of times parallel execution was requested and the degree of parallelism was reduced because of insufficient parallel execution servers.

Parallel operations downgraded to serial: The number of times parallel execution was requested but execution was serial because of insufficient parallel execution servers.

Parallel operations not downgraded: The number of times parallel execution was executed at the requested degree of parallelism.

parse count (hard): Total number of parse calls (real parses). A hard parse is a very expensive operation in terms of memory use, because it requires Oracle to allocate a workheap and other memory structures and then build a parse tree.

parse count (total): Total number of parse calls (hard and soft). A soft parse is a check on an object already in the shared pool, to verify that the permissions on the underlying object have not changed.

parse time cpu: Total CPU time used for parsing (hard and soft) in 10s of milliseconds.

parse time elapsed: Total elapsed time for parsing, in 10s of milliseconds. Subtract parse time cpu from the this statistic to determine the total waiting time for parse resources.

physical read bytes: Total size in bytes of all disk reads by application activity (and not other instance activity) only.

physical read IO requests: The number of read requests for application activity (mainly buffer cache and direct load operation) which read one or more database blocks per request. This is a subset of physical read total IO requests statistic.

physical read total bytes: Total size in bytes of disk reads by all database instance activity including application reads, backup and recovery, and other utilities. The difference between this value and physical read bytes gives the total read size in bytes by non-application workload.

physical read total IO requests: The number of read requests which read one or more database blocks for all instance activity including application, backup and recovery, and other utilities. The difference between this value and physical read total multi block requests gives the total number of single block read requests.

physical read total multi block requests: Total number of Oracle instance read requests which read in two or more database blocks per request for all instance activity including application, backup and recovery, and other utilities.

physical reads: Total number of data blocks read from disk. This value can be greater than the value of physical reads direct plus physical reads cache as reads into process private buffers also included in this statistic.

physical reads cache: Total number of data blocks read from disk into the buffer cache. This is a subset of physical reads statistic.

physical reads direct: The number of reads directly from disk, bypassing the buffer cache. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.

physical reads prefetch warmup: The number of data blocks that were read from the disk during the automatic prewarming of the buffer cache.

physical write bytes: Total size in bytes of all disk writes from the database application activity (and not other kinds of instance activity).

physical write IO requests: The number of write requests for application activity (mainly buffer cache and direct load operation) which wrote one or more database blocks per request.

physical write total bytes: Total size in bytes of all disk writes for the database instance including application activity, backup and recovery, and other utilities. The difference between this value and physical write bytes gives the total write size in bytes by non-application workload.

physical write total IO requests: The number of write requests which wrote one or more database blocks from all instance activity including application activity, backup and recovery, and other utilities. The difference between this stat and physical write total multi block requests gives the number of single block write requests.

physical write total multi block requests: Total number of Oracle instance write requests which wrote two or more blocks per request to the disk for all instance activity including application activity, recovery and backup, and other utilities.

physical writes: Total number of data blocks written to disk. This statistics value equals the sum of physical writes direct and physical

Copyright © AppDynamics 2012-2017 Page 134

writes from cache values.

physical writes direct: The number of writes directly to disk, bypassing the buffer cache (as in a direct load operation).

physical writes from cache: Total number of data blocks written to disk from the buffer cache. This is a subset of physical writes statistic.

physical writes non checkpoint: The number of times a buffer is written for reasons other than advancement of the checkpoint. Used as a metric for determining the I/O overhead imposed by setting the FAST_START_IO_TARGET parameter to limit recovery I/Os. (Note that FAST_START_IO_TARGET is a deprecated parameter.) Essentially this statistic measures the number of writes that would have occurred had there been no checkpointing. Subtracting this value from physical writes gives the extra I/O for checkpointing.

pinned buffers inspected: The number of times a user process, when scanning the tail of the replacement list looking for a buffer to reuse, encountered a cold buffer that was pinned or had a waiter that was about to pin it. This occurrence is uncommon, because a cold buffer should not be pinned very often.

prefetched blocks aged out before use: The number of contiguous and noncontiguous blocks that were prefetched but aged out before use.

process last non-idle time: The last time this process executed.

PX local messages recv'd: The number of local messages received for parallel execution within the instance local to the current session.

PX local messages sent: The number of local messages sent for parallel execution within the instance local to the current session.

PX remote messages recv'd: The number of remote messages received for parallel execution within the instance local to the current session.

PX remote messages sent: The number of remote messages sent for parallel execution within the instance local to the current session.

queries parallelized: The number of SELECT statements executed in parallel.

Read Percent:

recovery array read time: Elapsed time of I/O during recovery.

recovery array reads: The number of reads performed during recovery.

recovery blocks read: The number of blocks read during recovery.

recursive calls: The number of recursive calls generated at both the user and system level. Oracle maintains tables used for internal processing. When Oracle needs to make a change to these tables, it internally generates an internal SQL statement, which in turn generates a recursive call.

recursive cpu usage: Total CPU time used by non-user calls (recursive calls). Subtract this value from CPU used by this session to determine how much CPU time was used by the user calls.

redo blocks checksummed by FG (exclusive): The number of exclusive redo blocks that were checksummed by the generating foreground processes. An exclusive redo block is the one whose entire redo content belongs to a single redo entry.

redo blocks checksummed by LGWR The number of redo blocks that were checksummed by the LGWR. redo blocks written Total number of redo blocks written. This statistic divided by redo writes equals number of blocks per write.

redo blocks written: This is t he total number of redo blocks written. This statistic divided by "redo writes" equals the number of blocks per write.

redo buffer allocation retries: Total number of retries necessary to allocate space in the redo buffer. Retries are needed either because the redo writer has fallen behind or because an event such as a log switch is occurring.

redo entries: The number of times a redo entry is copied into the redo log buffer redo entries for lost write detection Number of times a

Block Read Record is copied into the log buffer.

redo entries for lost write detections: Number of times a Block Read Record is copied into the log buffer.

redo log space requests: The number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch.

redo log space wait time: Total elapsed waiting time for redo log space requests in 10s of milliseconds.

redo ordering marks: The number of times that a system change number was allocated to force a redo record to have a higher SCN than a record generated in another thread using the same block.

Copyright © AppDynamics 2012-2017 Page 135

redo size: Total amount of redo generated in bytes.

redo size for lost write detection: Total amount of Block Read Records generated in bytes.

redo synch time: Elapsed time of all redo synch writes calls in 10s of milliseconds

redo synch writes: The number of times a change being applied to the log buffer must be written out to disk due to a commit. The log buffer is a circular buffer that LGWR periodically flushes. Usually, redo that is generated and copied into the log buffer need not be flushed out to disk immediately.

redo wastage: The number of bytes wasted because redo blocks needed to be written before they are completely full. Early writing may be needed to commit transactions, to be able to write a database buffer, or to switch logs.

redo write time: Total elapsed time of the write from the redo log buffer to the current redo log file in microseconds.

redo writes: Total number of writes by LGWR to the redo log files. redo blocks written divided by this statistic equals the number of blocks per write.

rollback changes - undo records applied: The number of undo records applied to user-requested.

rollbacks only - consistent read gets: The number of consistent gets that require only block rollbacks, no block cleanouts. See Also: consistent gets.

rows fetched via callback: Rows fetched via callback. Useful primarily for internal debugging purposes.

serializable aborts: The number of times a SQL statement in a serializable isolation level had to abort.

session cursor cache count: Total number of cursors cached. This statistic is incremented only if SESSION_CACHED_CURSORS >

0. This statistic is the most useful in V$SESSTAT. If the value for this statistic in V$SESSTAT is close to the setting of the

SESSION_CACHED_CURSORS parameter, the value of the parameter should be increased.

session cursor cache hits: The number of hits in the session cursor cache. A hit means that the SQL statement did not have to be reparsed. Subtract this statistic from parse count (total) to determine the real number of parses that occurred.

session logical reads: The sum of db block gets plus consistent gets. This includes logical reads of database blocks from either the buffer cache or process private memory.

session stored procedure space: Amount of memory this session is using for stored procedures.

Small IO Percent:

sorts (disk): The number of sort operations that required at least one disk write.

sorts (memory): The number of sort operations that were performed completely in memory and did not require any disk writes.

sorts (rows): Total number of rows sorted.

SQL*Net roundtrips to/from client: Total number of Oracle Net Services messages sent to and received from the client.

SQL*Net roundtrips to/from dblink: Total number of Oracle Net Services messages sent over and received from a database link.

summed dirty queue length: The sum of the dirty LRU queue length after every write request. Divide by write requests to get the average queue length after write completion.

switch current to new buffer: Number of times the CURRENT block moved to a different buffer, leaving a CR block in the original buffer table fetch by rowid Number of rows that are fetched using a ROWID (usually recovered from an index).

table fetch by rowid: Number of rows fetched using a ROWID (usually recovered from an index). Table scans by rowid usually indicate either non-optimal queries or tables without indexes. Therefore, this statistic should increase as you optimize queries and provide indexes in the application.

table fetch continued row: Number of times a chained or migrated row is encountered during a fetch.

table scan blocks gotten: During scanning operations, each row is retrieved sequentially by Oracle. This statistic counts the number of blocks encountered during the scan.

table scan rows gotten: The number of rows that are processed during scanning operations.

table scans (cache partitions): The number of range scans performed on tables that have the CACHE option enabled.

table scans (direct read): The number of table scans performed with direct read (bypassing the buffer cache).

Copyright © AppDynamics 2012-2017 Page 136

table scans (long tables): Long (or conversely short) tables can be defined as tables that do not meet the short table criteria as described in table scans (short tables).

table scans (rowid ranges): During parallel query, the number of table scans conducted with specified ROWID ranges.

table scans (short tables): Long (or conversely short) tables can be defined by optimizer hints coming down into the row source access layer of Oracle. The table must have the CACHE option set.

transaction lock background get time: Useful only for internal debugging purposes.

transaction lock background gets: Useful only for internal debugging purposes.

transaction lock foreground requests: Useful only for internal debugging purposes.

transaction lock foreground wait time: Useful only for internal debugging purposes.

transaction rollbacks: The number of transactions being successfully rolled back.

transaction tables consistent read rollbacks: The number of times rollback segment headers are rolled back to create consistent read blocks.

transaction tables consistent reads - undo records applied: The number of undo records applied to transaction tables that have been rolled back for consistent read purposes.

user calls: The number of user calls such as login, parse, fetch, or execute

user commits: The number of user commits. When a user commits a transaction, the redo generated that reflects the changes made to database blocks must be written to disk. Commits often represent the closest thing to a user transaction rate.

user rollbacks: The number of times users manually issue the ROLLBACK statement or an error occurs during a user's transactions.

write clones created in background: The number of times a background or foreground process clones a CURRENT buffer that is being written. The clone becomes the new, accessible CURRENT buffer, leaving the original buffer (now the clone) to complete writing.

write clones created in foreground: The number of times a background or foreground process clones a CURRENT buffer that is being written. The clone becomes the new, accessible CURRENT buffer, leaving the original buffer (now the clone) to complete writing.

PostgreSQL Server Metrics

blks_hit: Number of times disk blocks were found already in the buffer cache, so that a physical disk read was not necessary. This only includes hits in the PostgreSQL buffer cache, does not include the operating system's file system .cache).

blks_read: Number of disk blocks read from the database.

confl_bufferpin: Number of queries in the database that were canceled because of pinned buffers.

confl_deadlock: Number of queries in the database that were canceled because of deadlocks

confl_lock: Number of queries in the database that were canceled due because of timeouts.

confl_snapshot: Number of queries in the database that were canceled because of old snapshots.

confl_tablespace: Number of queries in the database that were canceled because of dropped tablespaces.

numbackends: Number of backends currently connected to the database.

size_mb:

tup_deleted: Number of rows deleted by queries in the database.

tup_fetched: Number of rows fetched by queries in the database.

tup_inserted: Number of rows inserted by queries in the database.

tup_returned: Number of rows returned by queries in the database.

tup_updated: Number of rows updated by queries in the database.

Copyright © AppDynamics 2012-2017 Page 137

xact_commit: Number of transactions in the database that have been committed.

xact_rollback: Number of transactions in the database that have been rolled back.

Sybase ASE and IQ Server Metrics

active_connections: The number of users currently connected to the database

ActiveReq: Returns the number of server threads that are currently handling a request.

ActiveVersionsCount: Count of Active Transaction Versions.

ActiveVersionsCreateMB: Size in Mb of versions for active transaction.

ActiveVersionsDeleteMB: Size in Mb of versions for active transactions.

AIOs_delayed_due_to_engine_limit :

AIOs_delayed_due_to_os_limit :

AIOs_delayed_due_to_server_limit :

BytesReceived: Returns the number of bytes received during client/server communications. This value is updated for HTTP and

HTTPS connections.

BytesReceivedUncomp: Returns the number of bytes that would have been received during client/server communications if compression was disabled. (This value is the same as the value for BytesReceived if compression is disabled.)

BytesSent: Returns the number of bytes sent during client/server communications. This value is updated for HTTP and HTTPS connections.

BytesSentUncomp: Returns the number of bytes that would have been sent during client/server communications if compression was disabled. (This value is the same as the value for BytesSent if compression is disabled.)

CacheFileDirty: Returns the number of cache pages that are dirty (needing a write).

CacheFree: Returns the number of cache pages not being used.

CacheHits: Returns the number of database page lookups.

CachePanics: Returns the number of times the cache manager has failed to find a page to allocate.

CachePinned: Returns the number of pinned cache pages.

CacheRead: Returns the number of cache reads.

CacheReplacements: Returns the number of pages in the cache that have been replaced.

CacheScavenges: Returns the number of times the cache manager has scavenged for a page to allocate.

DiskRead: Returns the number of disk reads.

mempages_alloced: The number of memory pages that have been allocated.

mempages_freed: The number of memory pages that have been de-allocated.

OtherVersionsCount: Shows count of other db versions. These versions will eventually be dropped when they are no longer referenced or referencable by active transactions.

OtherVersionsMB: Shows space usage in MB of other db versions. These versions will eventually be dropped when they are no longer referenced or referencable by active transactions.

ProcessCPU: Returns CPU usage for the database server process. Values are in seconds. This property is supported on Windows and

Unix. This property is not supported on Windows Mobile.

ProcessCPUSystem: Returns system CPU usage for the database server process CPU. This is the amount of CPU time that the database server spent inside the operating system kernel. Values are in seconds. This property is supported on Windows and Unix.

Copyright © AppDynamics 2012-2017 Page 138

This property is not supported on Windows Mobile.

ProcessCPUUser: Returns user CPU usage for the database server process. Values are in seconds. This excludes the amount of

CPU time that the database server spent inside the operating system kernel. This property is supported on Windows and Unix. This property is not supported on Windows Mobile.

RequestsReceived: Requests received by server

TempBufferCapacityCount: Capacity count of Temporary Buffers.

TempBufferCapacityMB: Capacity in Mb of Temporary Buffers.

TempBufferLockedCount: The number of Temporary Buffers that are locked.

TempBufferUsedCount: The number of Temporary Buffers in use.

total_bytes_received: The number of bytes received during client/server communications. This value is updated for HTTP and HTTPS connections.

total_bytes_sent: Returns the number of bytes setn during client/server communications. This value is updated for HTTP and HTTPS connections.

xacts: The number of transactions.

yields:

Copyright © AppDynamics 2012-2017 Page 139

Database Agent Events Reference

On this page:

Agent Diagnostic Events

JDBC Driver-related Agent Diagnostic Events

Related pages:

Monitor Events

You can see Database Agent events on the Database Monitoring > Events window and in the <agent_home>/logs/db-agent#.log files.

Database Agent events are of type Agent Diagnostic Event, with case-specific messages attached.

Agent Diagnostic Events

Initialize/re-initialize the DB collector

Summary: Initialize/re-initialize the DB collector

Description: Sent when database collector has successfully started. This happens when you configure a new collector, start/restart the agent process (in which case you'll see this event once for each collector), or when the collector recovers from a failure to communicate with the monitored database (for example, when the database goes down for a while, then comes back).

Severity: Info

Initialize/re-intialize the hardware metric collector

Summary: Initialize/re-intialize the hardware metric collector

Description: Same as the above, but refers to a hardware collector, not a database collector.

This is sent when hardware collector has successfully started. This happens when you configure a new collector, start/restart the agent process (in which case you'll see this event once for each collector), or when the collector recovers from a failure to communicate with the monitored hardware (for example, when the system goes down for a while, then comes back).

Severity: Info

Server parameter [?] has been changed from [?] to [?]

Summary: Server parameter [?] has been changed from [?] to [?]

Description: The Database Agent constantly monitors database configuration parameters. When a parameter changes, which generally means a database administrator made a deliberate change, the agent sends this event . AppDynamics Database Visibility users can use these events to track configuration changes in their databases.

Severity: Info

JDBC Driver-related Agent Diagnostic Events

Summary: The text of the message is the error from the vendor's JDBC driver.

Description: When the agent fails to collect data from a monitored database, it sends this event , and goes into sleep mode for one minute. It will then retry contacting the database every minute, until it succeeds. Once it succeeds, it will send an Agent Event

"initialize/re-initialize" message, as described above. This happens when the database goes down, or when you add a collector with a wrong password, or wrong hostname, etc.

When the Collector is in sleep mode because of an error, you'll see a indicator next to the database on the Infrastructure and

Infrastructure > Databases, on Configure > Collectors window. You will also see the full text of the error in the Infrastructure > Events window.

Copyright © AppDynamics 2012-2017 Page 140

Severity: Error

Copyright © AppDynamics 2012-2017 Page 141

Configure Query Literals Security

By default, literals are removed from SQL queries, as they can contain sensitive user data, social security numbers, CC numbers, etc.

If you want to show literals in the queries, you can disable the Remove literals from the queries option.

1. Click Databases .

2. Click Configuration .

3. In the Security section, uncheck Remove literals from the queries .

Once you uncheck the option, literals will always be displayed in the queries. You can revert to hiding the literals by checking the option.

Copyright © AppDynamics 2012-2017 Page 142

Configuring Custom Metrics

You can specify SQL queries that you want to run on the monitored database every minute. The results of each query will be collected in a custom metric.

To specify custom queries to run, click Configuration > Custom Metrics > New . Enter the following details:

Name: The name you want to name your custom metric.

Database: The database that you want to run the metrics on.

Query Text: The query that you want to execute. This query must return a positive integer number.

Copyright © AppDynamics 2012-2017 Page 143