>>Hello, my name is James Davis
and I'm a sales engineer here at SolarWinds.
In this guided product tour,
I will review key aspects
of the SolarWinds Database Performance Analyzer,
also known as DPA.
DPA changes the way teams manage
and improve application and database performance.
By putting the focus on application end-user wait time,
you can quickly deliver performance improvements
that get noticed.
Database performance is a major contributor
to slow application response time.
In this video, you will see how DPA,
in just four clicks, can drill down
to the root cause of performance problems,
see historical trends, and get expert advice.
DPA gives your team 24/7 monitoring,
performance analysis, and alerting of critical issues.
DPA utilizes a unique response time analysis methodology,
which focuses on the time between a query request
and a response from the database.
DPA analyzes wait types and events
to identify key bottlenecks.
Once logged in, we'll start at the home screen.
This page will give you a great overview
of where the major trouble spots are.
You can drill into the summary alarms
to isolate your view of any issues.
Sort and click into any of the resources
to quickly investigate a problem.
Let's start by clicking on a database instance.
Here in the trend dashboard,
the bars represent the total time application users wait
over the course of a month.
By default, we show the top 15 SQL statements
based on the wait time over a 30 day period.
With the reporting feature,
you can access up to five years of history.
Each color seen here represents a unique SQL statement.
You can see more detail by hovering over the bars.
The radio buttons in the upper left corner
display different views of these SQL statements.
Clicking on the average wait button
shows the longest running top 15 SQL statements by day.
Looking at this view,
we can see that September 4th had more wait on average
than other days.
Let's drill into this day to see more detail.
Drilling into September 4th, we can see
that nothing is screaming as the number one issue.
However, looking at the section below the graph,
here we see three additional tabs:
advisors, resources, and SQL text.
If we look at the data in the advisors tab,
you can see there's a query in a critical state
that has higher than normal execution.
Since this is in a critical state, let's look here.
This is an example of how DPA
goes beyond a traditional monitoring tool
that will show everything is healthy.
The advisor section has a wealth of information
about this particular SQL statement,
including the wait events, who was running it,
and the number of executions.
After looking at this detail,
your next question may be, "Is this normal?"
Before going further, let's name the SQL statement
something a little more meaningful
that will help us to track it.
Use the back arrow in your web browser
or click on a link in the breadcrumb trail
to navigate within DPA.
With just one click from the trend dashboard,
you can see the historical performance of the SQL statement.
Next to the historical charts,
there's a new analyze query dropdown
that will invoke the advisors feature
for any SQL statement on the screen.
The historical chart screen provides a deep dive
of information regarding the selected SQL statement.
With these graphs, we can see
something is out of the ordinary.
On September 4th, there were less executions,
but the statement had more wait time.
Another thing we can clearly see
is that one way type dominates the others, PAGEIOLATCH.
By clicking on the legend,
we see this as a disk related wait type
and can get advice on how to reduce the impact.
We can further research disc IO performance
by going to the storage IO dashboard.
In addition to the read tab,
you can also click on the current view or rights tab.
In this 30 day view, the concept,
much like with the trend dashboard
is just to click on the big bars
and drill down to the root cause of the problem.
You can hover over the bars
to see the green color representing this file
has much more time on the fourth than other days.
We can confirm that IO waits dominated the day
by looking at this chart to compare IO waits
to other non IO related waits.
This means we're on the right track.
By clicking into September 4th,
we see the distribution of the waits across the day
don't vary widely.
They all look to have high wait due to IO,
since it is a little higher from 8 pm to 9 pm,
we will take a look at this timeframe.
Once in the hour timeframe, we want to select the file
that seems to be having the highest wait against it.
Selecting the file brings up multiple ways
we can see the data.
When you click on the latency comparison link,
you can see the file,
the average for the top files on the same drive,
and the average for the top files in the same instance.
To drill down further,
click on the compare to files on same drive link.
This breaks out the average latency
that was shown in the previous graph.
With this easy to read graph, it's clear the slowness
is mainly isolated to a single file,
but what is the cause?
One way to know is to click
on the throughput versus latency link
to see if it's high throughput, meaning more data
or a low throughput, which is an indication
of something outside the database.
After isolating this issue, click on the mail icon
to send these graphs to the storage admin.
Or a better yet, give read only access to DPA
so that every user that's on the team
can see the issues for themselves.
Now that we have isolated this issue,
let's go back to the trend dashboard
and continue investigating.
In another scenario, there was a complaint
of slowness starting September 2nd around 11:30 am.
The graph does show that there is a SQL statement
that was taking a lot more time,
or at least was more prominent starting September 2nd.
Let's go ahead and name this SQL statement
and drill into the second to find out more information.
Since the users were concerned starting at 11:30,
we will click on the 11 am to 12 pm time range.
Within the top 50 SQL statements,
we see that some locking wait is present.
Click the blockers tab to find the lead blocking session
and which queries were being blocked.
Send this screen to developers or change management teams
to note where there was blocking.
For even more detail, click the time slice tab
to view performance data down to the second.
By clicking show baselines,
hourly baseline detail is displayed
for each resource metric.
Click here to select additional metrics.
Hovering over the highlighted portion,
you can quickly determine
if a resource metric is normal or not.
Correlating the bars above with the resources,
you can easily get a picture of the health of the database
for a specific granular timeframe.
By clicking through these tabs, you can isolate a dimension.
For example, click on the machines tab
and select the top item.
Now we are seeing the top SQL filtered
by the selected machine.
To quickly pinpoint issues occurring now,
click on the current link
Here we see what is currently running,
the longest running SQL,
and the most executed SQL in the last hour.
Using this in conjunction
with the storage IO Current tab
allows you to get a full picture
of what is contributing right now to slowness.
This demo has only covered a small portion
of the capabilities of DPA.
There are also alerts, metrics, and reports
that you can customize to track what is important
and relevant to your business.
Thousands of database professionals are taking advantage
of DPA to improve application performance
and quickly troubleshoot issues
with multi-dimensional performance analysis.
Whether you are an expert or not,
DPA can help you quickly find the root cause
of your most complex application
and database performance problems and help you fix them.
To learn more about how DPA can help you
become a better database professional,
or to download a free, fully functional trial
of Database Performance Analyzer, visit solarwinds.com.
[light music]