The AppD Approach: How to Identify Problematic Database Queries with Business Transactions

It happens all the time: the engineers notice your application is slowing down just as a health rule fires a warning. Now you are in a race to identify and fix the issue before customers feel its impact.

One tried-and-true solution is database query optimization. But how do you know which queries to optimize? And how can you verify that the changes you’ve made have addressed the issue? In this two-part blog series, I’ll cover some methods for optimizing queries that every developer should know about. Today, I’ll focus on using Business Transactions with and without AppDynamics Database Visibility licenses.

The beauty of Business Transactions is that they allow you to examine application performance by function. This allows you to focus on optimizing the important functions of your application and not waste effort on other parts. In addition, the performance of Business Transactions is automatically recorded in dynamic baselines, so you can easily compare response times before and after optimization in order to see what impact your efforts are having.

In the example below, slowness is affecting the Checkout function of an ecommerce application. Let’s start out by investigating the scope of the problem. On the flow map you can see that average response time is slower now. The current response time is over 10 seconds where it had been around 0.5 seconds, the average response time for the last minutes is up to 4.6 seconds already.

The Transaction Performance health rule has been violated too.

You can also see in the Transaction Scorecard that the number of very slow transactions is increasing along with the average response time.

Note: You can see that there are errors, but we have investigated them before and they are not impacting the customer.

All of this is confirming that there is a performance problem here. Let’s find out what part of this transaction we need to fix. Returning to the flow map, we can immediately identify a potential area of trouble: The database call time is dominating the overall transaction time.

Drilling down further into the JDBC calls, we learn that about 40% of calls to this transaction use this particular database, and when they do the queries are taking an average of 8.1 seconds. What this tells us is that 86% of the time spent in the Checkout Business Transaction is being spent in calls to the XE-Oracle Database.

The next step is to determine which queries to optimize. Ideally, we want to focus on the most expensive calls/SQL statements. Finding those with AppDynamics is as simple opening up the snapshots window, selecting a group of non-error transactions, right-clicking to open a pop-up window and choosing “Identify the most the most expensive calls.”

AppDynamics compares all the snapshots and shows the slowest queries and methods for the group. Now you can see what the application was doing when it was waiting on the database.

AppD provides the full text of the query and a set of response times for the slow queries. It shows which queries are repeatedly causing an important function of your application to be slow.

If you have AppDynamics Database Visibility licenses and the DB Agent set up and configured with your database information, then AppD can help you learn more about your query performance from the database point of view. You can go to 1 “Databases” and then the 2 “Queries” tab to see a view of the query performance from the database.

This view is built from metrics gathered directly from the database system tables so it’s not limited to snapshot data. You can see all the calls in the database for this query, including calls from fast transactions that are not saved by the snapshots. You can also drill deeper into the query and see more details.

Finally, you can get to the execution plan by double clicking on the cached plan row in the table. Now you have all the information you need about which exact parts of this query are making it slow.

Some developers like to use the Database Queries screen queries as a starting point for query optimization. While this screen alone doesn’t give you any context about the business impact of a particular query, it does do a good job of reporting what’s impacting the database.

If this is your preferred approach, you should keep in mind that the query performance you see isn’t stored in the Metric Browser. You will need to set the time range to a period before the change was put in place and use the Actions | Export function to get a report about the old behavior of the query. By comparing that export with the performance of the query after changes have been made, you will be able to measure the impact of your optimization efforts.

Even if you don’t have the DB agents configured for your database, you can validate the effect of your efforts by simply watching the BT performance after the fix goes in. If you saw something like this after your fix, it would be a great result. The current response time declined from a range of 6-21 seconds to 0.5 seconds and the average response time dropped 3.3 seconds.

In today’s blog post we started off by analyzing a complex transaction that was slow and progressed to isolating specific sections of a single database query that were affecting the transactions. In my next post, we’ll look at how to use Service Endpoints to monitor mission-critical database queries.

Find out more about AppDynamics’ database monitoring solutions here.

John Aronson is part of AppDynamics Global Services team, which is dedicated to helping enterprises realize the value of business and application performance monitoring. AppDynamics’ Global Services’ consultants, architects, and project managers are experts in unlocking the cross-stack intelligence needed to improve business outcomes and increase organizational efficiency.

Introducing AppDynamics for Databases

The most common cause of application slowdowns today is slow SQL or stored procedures in the database. The reason? Databases store large amounts of data on disk, and disk is super slow relative to data in memory (unless its SSD). As data volumes grow, the need to configure, maintain and optimize a database also grows because you can’t manage everything on one disk or volume. This is why database administrators (DBA’s) exist.

A huge problem is that developers write ad-hoc SQL queries for their applications and have no idea how those queries actually execute and retrieve data from disk in the database. They are blind to the number of records in a table, or which columns in a given table has indexes. This is why developers typically blame the DBA when their SQL queries run slow– they assume slow queries means a slow database, and that the DBA isn’t doing his job properly. This couldn’t be further from the truth.

With AppDynamics for databases we’re now giving DevOps teams visibility of how their application SQL queries actually execute within the database, so when things slow down they can now collaborate with DBA’s instead of blaming them. Thats right, users of AppDynamics will now be able to find the root cause of slow SQL and stored procedures in their application. This is indeed good news because customers can dramatically improve their end user experience, response time and application throughput by tuning their data access layer.

Obviously, SQL executes differently in different databases, thats why we built AppDynamics for databases to provide universal support for all common relational databases like Oracle, SQL Server, DB2, Sybase, MySQL and PostGres. This is a big deal because no monitoring vendor at the moment provides database diagnostics across all type of relational databases, not to mention providing the application and business transaction context.

So let’s show you a few screenshots of what AppDynamics for Databases can give you.

Single Pane of Glass View
How about a single pane of glass view to monitor ALL your databases regardless of platform? done. Application databases these days vary significantly, most use Oracle, some use MySQL and obviously .NET applications are better related to windows-based databases like SQL Server and Sybase. Its therefore important you can get a holistic view of performance across all your databases.

Real-Time Performance Metrics:
Its always good to know exactly what is happening “right now” in a database. Has the database ran out of connections? or is the database experiencing latency from locking on rows? These are just a few answers you can get from the below “Current” workspace which provides a real-time view of database resources and performance.

Screen Shot 2013-03-26 at 4.52.40 AM

Historical Analysis of Database Activity:
Real-time data is good, but its also helpful to have historical data so you can identify trends, spikes and abnormal patterns in performance. For example, a simple application code change can have a dramatic impact on a database and its performance.  We had an agile customer last year who deployed a code release in production and immediately saw a slowdown in application response time. When they drilled into AppDynamics for Java they noticed that one business transaction was now performing 25 SQL queries per execution instead of just 2 queries, this was the difference between 20,000 and 250,000 executions per minute in the database. Obviously when you increase concurrency that much in the database your going to experience contention and wait, being able to visually track database resource, time spent, wait states and number of executions over-time is invaluable.

Screen Shot 2013-03-26 at 4.53.00 AM

Top SQL Statements and Stored Procedures:
Perhaps the most obvious view you’d expect from a database monitoring solution. This is typically what most Application Performance Monitoring (APM) vendors provide by extracting data from the JDBC or ADO.NET protocols. The big difference between those solutions and AppDynamics is that we allow you to drill down into the SQL or stored procedures and understand their execution plans, so you can actually find the root cause of why your queries run slow. This is great data for application support teams and developers who want to collaborate better with their DBA’s, so they can understand the real reason of database latency.

Screen Shot 2013-03-26 at 4.53.09 AM

Explain Plans:
Most databases will automatically parse and refine the execution of SQL queries based on what plan its query optimizer selects. Just because you add an index to a table to try and make a query faster, doesn’t mean the database query optimizer will use it, and when you consider that index’s aren’t for free (they take up disk space) you might want to check exactly how the database is executing your queries. Take a look at the below explain plan and you can see how the SQL is being processed with two simple selects and two different tables. Notice how the SUBQUERY on the iplookup table is using the index ‘ian1’ because that table has over a million rows in it. If this index was accidentally dropped you can be sure this query would run significantly slower given it would be doing a full table scan on over a million records.

Screen Shot 2013-03-26 at 4.53.17 AM

Database Statistics:
How frequently are applications connecting to your database? and what operations are these applications performing? Applications differ by the volume of data they request, process and manage over-time. For example, in a Cable or Telco provider you might have a customer portal application which accesses customer data inside a large Oracle schema. That same Oracle schema may also service queries from reporting applications for marketing, or perhaps batch jobs from billing applications that need to process large volumes of customer data. If you have different applications performing different operations (read, write, update, delete) at the same time on the same database then that can be a recipe for disaster. You can see from the below screenshot that the application connect to this MySQL instance is spending most of its time inserting data, meaning its write intensive versus read intensive. Obviously if the database and application was purely read intensive, you might consider moving that data to a cache in memory closer to the application logic. Remember, database calls are often remote and expensive, ever so more in the cloud where storage is less than stella.

Screen Shot 2013-03-26 at 4.53.25 AM

 Object Properties:
All database schema’s have generic objects that represent users, databases, tables, indexes and so on. These objects are often configured and maintained by DBA’s to ensure that the database is optimally configured for availability and performance. Change is constant within databases because data volumes are always increasing, and application data models are always evolving to support new features. Making a single configuration change can have a dramatic impact on database and application performance. AppDynamics for databases flags and provides a full audit report on all changes made within the database as shown below. This helps DevOps and DBA’s correlate the impact of change with database performance which can be very powerful. If someone dropped an index and performance spikes shortly after then thats worth knowing!

Screen Shot 2013-03-26 at 4.53.35 AM

 I walked through just a few features and capabilities of AppDynamics for Databases, here’s a quick 4 minute overview of the product:

You can get started right now and sign up for our free trial.

Happy database monitoring!