I told you I was saving the best for last and here it is!  We're standing database performance analysis on it's ear by presenting it from the perspective of applications using your databases, otherwise referred to as Database Application Performance Monitoring & End User Experience.  Many people have database instances shared by several applications which turns troubleshooting performance into a complicated nightmare.  This release of Database Performance Analyzer (DPA) has features to empower the application owner and liberate DBAs.  I hope you like what I'm about to show you and invite you to consider joining DPA 9.2 Beta which is open to customers with both DPA and Server Application Monitor (SAM) currently on active maintenance.  To try it out, please fill out this short survey.


Oh, and did I mention you could WIN A $50 AMAZON GIFT CARD?

 

betabutton.png

For this 3rd post in my 3 part series, I'm going to tell you about :

  • Part 3 - Database Application Performance Monitoring & End User Experience!
    • See the status of applications querying your databases
    • Application Perspective of End User Experience
    • A new perspective on Blocking


Previous Posts:


NOTICE : This is BETA, so there is no promise that what you see here will be delivered as is.

 

FeaturesDisplay

Applications Using My Databases : After you've mapped applications in SAM to database instances in DPA, you will see a resource on both the Summary View and Instance View that enumerates the applications that depend on your databases.  This can be a handy troubleshooting tool when you suspect a database problem may impact applications.  You'll be able to use this as a quick glance at their status as well as a means to dive into them for a closer look.  When you do, you'll find a new DPA resource was added that helps you understand the database's contribution to Application End User Experience.

 

The Benefit: Easily keep track of application to database dependencies.

AppsUsingDbs.JPG

Application End User Experience : Databases don't exist for the sake of giving DBAs something to do.  They exist to serve applications who are typically created and maintained by someone other than the DBA.  Unfortunately, those somebodies often don't know databases like a DBA.  Another unfortunate reality is that DBAs are typically outnumbered by applications they support and projects developing new applications.  To help with this, we've created a resource you can add to an Application View for applications that use databases.  This resource provides a contextual glimpse into the performance of queries originating from the node your application resides on.  We're not just showing you total resource loads; we're showing you real query execution times for queries from your application server.  It's a beautiful thing, right? Explaining database behavior in multi-tenant environments takes more than a minute but everyone gets waiting and prefers to minimize how much they wait.  And we're showing them how long THEY are waiting.  In other words, we've filtered out what they would perceive as noise.

 

time-sucka-lg.jpg





The Benefits:

  • Empower application development and support staff.
  • Liberate the DBAs from tedious research tasks.
  • Eliminate unproductive blame games!
blame-o-saurus-lg.jpg






DbClientWaitTimeResource.JPG

query-blocker-lg.jpgBlocking : Many people I've spoken to have a lot of interest identifying where blocking occurs.  A quick overview for the non-DBA.  Blocking is not inherently bad, but it can be relatively bad.  Blocking is by-design behavior that results from locks which are used to preserve transactional consistency.  In fact, up until recently, locking & blocking is how all of the big name relational databases have maintained transactional consistency.  So let's say that we don't typically care about very brief blocking.  We only care when it becomes a significant factor in overall query performance.  To help with this, we've created a resource that helps you understand the situation from both the perspective of the blockers & the blockees.  Sometimes they're one in the same i.e. the same update query being executed by 2 different sessions at the same time.  There also are different blocking scenarios.  You can have one session blocking many sessions or you can have a cascading tree of sessions blocking other sessions that block other sessions etc.  In the first scenario, you'll see blocking time and blocked time being equal.  In the second scenario, you'll see more time blocked than time blocking.  This resource also has a bar graph at the bottom to show you when there has been blocking.


The Benefit: This resource provides a visual that helps the user see how many blockers are impacting how many blockees (waiting queries)

BlockersResource.png

betabutton.png

$50 Amazon Gift Cards Details
  • Completing requirements earns you opportunities to win 1 of 5 Amazon Gift Cards!
  • 1 opportunity to win per milestone completed.  Complete them all to maximize your chances of winning.
  • Share via screen shots or videos e.g. camera phone.
  • Send to brian.flynn@solarwinds.com.
  • Milestones
    1. Share your integration experience.
      • Show that you successfully connected SAM to DPA.  The screen should show that Orion has successfully tested a connection or is connected.
      • Show us your database instance mapping screen.  The screen should show some database instances are mapped to Orion nodes.
      • Show us your application mapping screen.  The screen should show that you have discovered applications querying your databases.
    2. Show us your Summary View - Click on the Databases tab.  That is the Summary View.
    3. Show us an Instance View - From the Summary View, click on a database instance then click the DB Performance sub-view.
    4. Show us an Application View - From the Summary View or Instance View, find the Applications Using My Databases resource and click into one of those applications.