Product Blog

8 Posts authored by: brianflynn

Storage Resource Monitor (SRM) v6.2 Release Candidates is now available in the SolarWinds Customer Portal for customers on Active Maintenance.  Release Candidates can be installed on your production systems and are fully supported. The Product Team is eagerly awaiting your feedback in the Storage RC Forum.


Additional Device Support for Storage Resource Monitor's Orion Module :

This release adds additional device support to the Orion Module, allowing customers to monitor more devices on the Orion Core Platform and take advantage of the AppStack Environment View.

  • EMC® Isilon®
  • Hitachi® Data Systems AMS, USP VM, USPV, VSP G1000, G200/400/600, HUS 100 Block-Side, HUS VM
  • HP® StorageWorks XP
  • IBM® Spectrum™ Virtualize (Vxxx and SVC)


Hierarchical Storage Pools:

In addition to more device support in the Orion Module, we are adding support for Hierarchical Storage Pools.  This allows customers to see multiple pool layers when a storage array has more than one logical storage container (pool) from which a LUN can be created.  This is possible with HP 3PAR and EMC VMAX.  Following are some screenshots showing Hierarchical Storage Pools and a *couple of new arrays supported. 


Srm62RcObjectsTreev2.jpgEMC Isilon - File Share Details - Summary.pngHDS(AMS2100) - Array Details - Summary.png


Devices Supported by SRM Orion Module in Previous Releases of Storage Resource Monitor

  • SRM 6.1
    • EMC VMAX
    • Dell Compellent
    • HP StoreServ 3PAR
    • HP P2xxx/MSA
    • Dot Hill AssuredSAN 4xxx/5xxx
  • SRM 6.0 - first release with the SRM Orion Module
    • EMC VNX / CLARiiON family
    • EMC VNX NAS Stand-alone Gateway / Celerra
    • Dell EqualLogic PS Series
    • NetApp E-Series (LSI)
    • IBM DS 3xxx / 4xxx / 5xxx
    • Dell MD3xxx
    • NetApp Filers running Data OnTAP 8 in:
      • 7-mode
      • Cluster-mode (aka Clustered Data OnTAP)

I'm excited to formally announce that Database Performance Analyzer 9.2 is now Generally Available! 

This release of Database Performance Analyzer (DPA) has a very special feature only available when integrated with Server & Application Monitor (SAM) 6.2.1+.  We developed this feature based on the collective experience of DBAs and SysAdmins who've been caught up in nasty blame games.  Let me tell you a story...

blame-o-saurus-lg.jpgImagine a web site used by your customers that depends upon a database.  Not hard, right? Now imagine the customers have been calling in daily, about an intermittent performance issue that threatens your business.  It's been really irritating because the I.T. Pros just can't pinpoint the cause and it's stressing out executives who are demanding a swift resolution! 

  • The SysAdmins say that the web server looks fine.  No CPU spikes.  Plenty of memory.  No red flag in metrics. 
  • The DBA says the database server looks fine.  No CPU spikes.  Plenty of memory.  Very little storage IO and all queries received results within SLA.  There was a small spike of activity after the time the customers complained, but it was just a momentary spike in concurrent activity and again, all queries received responses within SLA.
  • The Web Developers want to blame the database because it's their primary dependency and it has caused them problems in the past.

So you've got 3 silos denying responsibility for the problem customers reported.  Executive attention focuses on the Developers who begin forming hypotheses they can't prove, like network performance is the issue or that web server and database server clocks may not have been synchronized and that little database spike actually did cause the web site performance problem.  And these are just the reasonable hypothesis.  Soon, you feel like you're on an episode of CSI, looking for a genius mastermind hacker that's broken into your system to steal customer data! 

This is a case where disparate monitoring solutions can leave you hanging... siloed... at each other's throats!  So what do you do?  Calm down!  First you need to clarify to everyone that they don't have a shred of evidence to prove any of these things.  But an integrated monitoring solution can give you a complete picture.  Let me show you how DPA 9.2 integrated with SAM 6.2.1 can help! 

chickenoregg.pngWith SAM 6.2.1, you can monitor an IIS web server with AppInsight for IIS which exposes some ASP.NET metrics that I love! :

  • Request Execution Time - Tells you how long it took IIS to complete the most recent web request.
  • Request Wait Time - Tells you how long IIS held a web request in a queue before it began processing it.
  • Requests Queued - Tells you how many web requests are in the queue because the web server has reached it's limit of worker threads.  Ideally, you keep this at zero!
  • Requests Rejected - Tells you how many web requests IIS has simply rejected because the queue is full.  GAME OVER!  YOU LOSE!

Now, when DPA 9.2 is integrated with SAM 6.2.1+, it adds a Query Response Time resource to your AppInsight for IIS view, which reveals how much *database wait time queries from the web server have incurred.  This enables you to perform a diagnosis of exclusion.  That is to say, if A and not B then C.  If (A) the web server requests are slow, you will see it in those ASP.NET metrics.  If the Query Response Time resource doesn't show (B) a matching spike in database wait time, then the web site performance issue must be caused by (C) something else.

So back to our story for a minute...  You see how the request execution time was high for a bit there, then suddenly dropped?  Do you see how the Query Response Time shows an inverse pattern?  The spike the DBAs mentioned that occurred after the web site problem...

Here's what REALLY happened...  True story from my past, actually.  It is true that historically, the database has caused many web site performance problems, but the Web Developers didn't evaluate every dependency.  As it turns out, the web server also relies upon 3rd party web services.  They've never been a problem before, so they haven't been monitored and were thus were overlooked.  Our web code needs these web services to complete before the web server will query the database and that is why we see the inverse relationship between Request Execution Time and Query Response Time.  When the 3rd party web services cleared their performance problem, the web server sent all the associated database queries to the database server, which responded to that load spectacularly, the DBA adds!

So as you can see, monitoring this web site with AppInsight for IIS and the dependent database with an integrated Database Performance Analyzer enables both teams to see the big picture in a single pane of glass.  Pretty cool, huh?

For more information about Database Performance Analyzer 9.2 features and value, check out the beta blog posts, my recent post on Geek Speak and a video explaining the difference between health and performance monitoring.


*database wait time - The amount of time a database client waited while the database server worked on the client's query.  Time is broken down into discreet steps performed by the database server, how long it spent on those steps.  Fpr more info see

If you haven't noticed, Storage Resource Monitor 6.1 is now GA!  What does this mean?  More array support!  This release adds additional device support to the Orion Module, allowing customers to monitor more devices on the Orion Core Platform and take advantage of the AppStack Environment View.

  • EMC Symmetrix VMAX/VMAXe/DMX-4 Arrays
  • Dell Compellent
  • HP StoreServ 3PAR
  • HP P2xxx/MSA
  • Dot Hill AssuredSAN 4xxx/5xxx

Storage Resource Monitor is more than the average monitor because it does more than simply monitor your storage.  When combined with other AppStack enabled products from Solarwinds, it enables you to identify when storage contention is the root cause of application performance issues.  However, Storage Resource Monitor is great even without AppStack because it provides a single pane of glass into heterogeneous storage environments.

SRM Home.png


Remember that Storage Resource Monitor (SRM) is fairly new.  Having only first come out in February, this is only the second release of this new platform.  Previous blog posts like Storage Dreaming - The Next Chapter for Storage Monitoring with SolarWinds and Dreams Come True - Storage on Orion is now in Release Candidate tell the outstanding AppStack story, but there's more to SRM than just AppStack. In my last blog post on SRM when I announced 6.1 beta, I told you about some of it's features and I continue that here by describing 4 resources found right on the main dashboard.

A Quick Overview of the main Dashboard

The "All Storage Objects" resource can browse your arrays, pools, LUNs and volumes to identify potential root causes at lower levels to impacts at higher levels.  Notice that this browser is browsing multiple storage arrays from multiple vendors.  You don't need multiple products, one for each array.  Storage Resource Monitor can simplify your storage management.

The "Array Raw Disk Capacity" resource helps you stay ahead of your organization's storage consumption by breaking down capacity into spare, used and remaining.

The "Storage Objects by Performance Risk" resource is a great way to look across a large storage environment and quickly identify the performance hot spots like IOPS, latency and throughput.

The "Storage Objects by Capacity Risk" resource reveals when capacity is getting tight for your arrays, pools, LUNs and volumes.  The Last 7 Days trend line reveals sudden growth surges and in the far right column of the Storage Objects by Capacity Risk, Storage Resource Monitor projects when storage objects will run out of capacity.

For more feature content, check out another relatively recent blog post, Monitoring and Alerting Repairs it Entirely!

AllStorageObjects61.png  ArrayDiskCapacity61.JPG
StorageObjectByPerformance61.JPG  StorageObjectByCapacity61.JPG

Hello, I'm Brian Flynn and I'm the Solarwinds Product Manager for Storage Resource Monitor (SRM).  I'm excited to announce that we are gearing up for a beta release of SRM 6.1 and I'm inviting customers with Storage Manager (STM) or Storage Resource Monitor (SRM) in active maintenance to test our beta release on new arrays.  If you are not an STM or SRM customer, but are still interested in participating, go ahead and sign-up as well, and I'll see if there is a way I can at least get you on a feedback call to interact with a SolarWinds-local install.  Click here for sneak peek screen shots

SRM beta button.png


In This Release...

We are primarily working on device support

  • Dell Compellent
  • EMC Symmetrix VMAX
  • Nimble
  • HP P2xxx/MSA
  • Hitachi Data Systems (HDS)
  • HP 3PAR StoreServ
  • EMC Isilon


DISCLAIMER : What we are working on in SRM 6.1 Beta is in no way a promise of what we will deliver in SRM 6.1.


How can I accelerate support for my devices?

The answer is simple:

  1. Check for an existing feature request for your array.
    • If it's there already, vote it up.
    • If it's not there already, create it.
  2. Regardless, you can greatly assist our velocity in delivering more device support by providing recordings of the metadata from your arrays using our Storage Responder Tool (SRT).


SRT is a very simple tool you can use to collect performance data from your arrays.  Simply point SRT at your SMI-S Provider and it will get a snapshot of performance, capacity and configuration data that you can send us for our engineering team to use in our development and testing. The data is safe to share; it does not contain any data from the array’s disks (no data), only the metadata we need for monitoring.  You can check that for yourself because the data is stored in plaintext XML, so you can inspect it before sending it to us.  SRT comes with a PDF document that will guide you through using it but as I've said, don't hesitate to contact me with issues.

Licensing Changes

SRM 6.0 was just released in February 2015 and with that release came some slight licensing changes.  Most notably, if you choose to run both the SRM Orion module and the Profiler module, you will find that you can monitor an array with both modules using the same license.  You do not need a separate license for SRM Orion module and the SRM Profiler module.  This quick video should help clarify that with a couple of use cases.


With SRM 6.0 being so new, we haven't yet written about all of it's features.  Previous blog posts like Storage Dreaming - The Next Chapter for Storage Monitoring with SolarWinds and Dreams Come True - Storage on Orion is now in Release Candidate tell the outstanding AppStack story, but there's more to SRM than just AppStack.

Here's an introduction to some of the features in the currently supported version of SRM:

  • Performance Dashboard
  • Latency Histogram for LUNs
  • IOPS Performance Per LUN

Performance Dashboard

SRM Performance Dashboard.png

Who is this for?

  • Anyone! 
  • Don't you get tired of creating performance summaries for your peers?
  • Wouldn't you like more time to work on pressing matters?
  • Wouldn't you like your help desk and support peers to take care of initial triage?
  • Are you a help desk or support professional tired of being the middle man between users and storage admins?

Then the SRM Performance Dashboard is for you!  Take a look at the example to the left. 

Here's what I can see at a glance:

  • We have performance problems on our CX3-10c array.
  • It took me no time to drill through from array through storage pools to find LUNs experiencing performance problems.
  • The Storage Objects by Performance Risk resource tells me the CX3-10c array has got LUNs with latency problems.
  • Let's take a look at that array by clicking on the CX3-10c array.

Latency Histogram for LUNs

SRM Latency Histogram.png

Who is this for?

  • Storage Admins
  • Users of Storage LUNs
  • Is anyone left?  ;-)

Allow me to demonstrate:

  • Open the Block Storage sub-view
  • Review LUN performance by histogram.
  • Click the 24h zoom.
  • Hover over the histogram bars for more info.
  • I see that 7 LUNs have have an average latency between 101-500 milliseconds in the past 24 hours.
  • That's clearly a significant concern for a Storage Admin and the users of Storage LUNs.

IOPS Performance Per LUN


Who is this for?

  • Are you frequently in the center of blame games between application owners using LUNs in those pools?
  • Are you frequently fetching LUN performance metrics for non-storage admins?

Then the IOPS Performance Per LUN resource is for you!  Take a look at the example to the left. Here's what I can see at a glance:

  • 12 LUNs in this storage pool.
  • 3 LUNs have significantly higher IOPS than the rest.
  • 2 LUNs have experienced the same spike in IOPS. 
  • This makes me wonder why.  Are they both used by the same application?  See AppStack!
  • 1 LUN has typically had very low IOPS but has spiked up just after 9 AM.
  • 1 of the LUNS that typically has higher IOPs experienced a parallel spike.  Again, I say see AppStack!

See AppStack



Keep watching for more blog posts outlining new SRM features and don't forget to sign up for the beta!


SRM beta button.png

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?



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.



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.


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.



The Benefits:

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


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)



$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
  • 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.

In my last post, I told you about some new features that provide a dashboard style summary view of your database environment when you integrate Database Performance Analyzer (DPA) with Server Application Monitor (SAM).  I also explained a little bit about database wait time. I'll expand upon that in this post as I tell you about ways DPA can help you inspect your database instance for performance bottlenecks.  Please note that we have also just made DPA 9.1 Release Candidate available for download.  As you can see, we've been very busy at Solarwinds with back to back releases running in parallel development!  I hope you like what I'm about to show you and invite you to consider joining The Beta which is open to customers with both DPA and SAM currently on active maintenance.  To try it out, please fill out this short survey. 




In this 3 part series, I'm going to tell you about :


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

In the first part of this post I'll describe the integration process.  It's designed to be very automagic but provides flexibility to tweak a configuration to meet the needs of more complex environments.  After you've completed the Integration Wizard, Orion implements your integration as follows :

  • A Databases tab is added to the top row of tabs.
  • A Summary View is populated with SAM health and DPA performance data.
  • Instance Views are set up for database instances monitored by only DPA.
  • Instance Sub-Views are set up for database instances monitored by both DPA and SAM.
  • A special DPA resource is added to application views that monitor database clients.*I'll talk about this more in the next post.



Getting Started: The Integration Wizard is designed to streamline the integration of DPA with Orion. The process of integrating DPA to Orion begins on the DPA Settings screen. *NOTE* that these instructions are assuming you've installed and configured both DPA and SAM to monitor your database instances.  Once that is done, to start the integration :

  1. Click the "Settings" link in the upper right hand of Orion.
  2. Click the "DPA Settings" link in the "Product Specific Settings" section.
  3. Click "Set Up Integration" to begin.


Turning on Integration : For the most part, to integrate, you tell Orion where DPA is, how to log in, and then your job is mostly confirming the mappings we'll suggest but you will have opportunities to manually tweak these mappings. 

To turn on integration you need the following information :

  • Server name or IP address of your DPA repository
  • Port number of DPA's SSL URL i.e. HTTPS://my.domain.local:8124
  • User name of an administrative account
  • Password

Once done, you can test the connection then submit and start the wizard.  When you submit, DPA and SAM will compare notes and present you with the first mapping screen.


Mapping Database Instances : In order to attach DPA functionality to all the right nodes in Orion, during the configuration of DPA integration, we ask you to confirm that we have mapped the right nodes in Orion to the database instances registered in DPA.  This enables us to add functionality to database instances you're already monitoring by adding a sub-view.  If you aren't already monitoring that database instance, the wizard will show no relationship for that database instance and upon completion of the wizard, the same DPA information will be presented in a default view for that database instance.  You can see the sub-view and it's benefits below, where I describe The Database Instance View.

  • Take a moment to review the mappings DPA and SAM found.
  • As long as SAM and DPA know your database instances by the same IP address, you can just click next.
    • Possible Exceptions where SAM and DPA know a database instance by different IP Addresses:
      • DPA or SAM knows a database instance by a Cluster VIP and the other knows that instance by individual node IPs.
      • DPA has registered an Availability Group listener and SAM has registered individual nodes.
      • SAM and DPA are using DNS aliases that each have different IP addresses for the same database instance.
      • A database instance is using DHCP and both SAM and DPA have different DNS servers resolving to different IPs.

  • If you wish to exclude one of DPAs monitored instances, un-check it.

  • When a link exists, the status column will show a chain link.ChainLinkIcon.JPG
  • When a link does not exist, the status column will show a slashed circle.SlashedCircleIcon.JPG
  • If you need to add a mapping, click the add link icon in the actions column.AddLinkIcon.JPG
  • If you need to edit a mapping, click the pencil icon in the actions column.PencilIcon.JPG
  • If you need to remove a mapping, click remove link icon in the actions column.RemoveLinkIcon.JPG
  • Click Next when you are happy with the configuration.

Mapping Database Clients : The next step of configuration is to confirm that we have accurately mapped database clients per DPA to the applications you monitor in SAM.  We do this by mapping the IP of the database clients DPA sees to the IP addresses of nodes where your applications reside.  How do we do this?  Well when an application connects to a database, the database obviously knows which host just connected and DPA keeps track of which queries came from that host.  It is this database client mapping that enables the 2 powerful features I'll talk about in my next post!  Wink, wink... It's pretty cool so check back for my third post.  :-)

  • Take a moment to review the mappings DPA and SAM found.
  • This should automagically discover most use cases.  But possible exceptions include:
    • Your applications don't connect directly to the database instance but rather proxies through something else like a middle tier service.  In this case, DPA knows the proxy or middle tier service as the client of the database.
    • Your applications use DHCP and SAM and DPA are resolving names through different DNS servers.

  • Since you can have multiple applications on a host, you can have multiple rows for a host.

  • Un-check any applications that you don't want a DPA resource added to.

  • If you need to edit a mapping, click the pencil icon in the actions column.PencilIcon.JPG
  • If you want to add an application view to SAM, click the Add Application Views button. AddApplicationViewsButton.JPG
  • After you click Next, you will see a confirmation screen with a "Finish" button.



So now you're ready to find needles in the haystacks!  This is where "the magic" happens.



The Database Instance View provides greater detail of what your database is doing and how that's affecting your resources.  If you use AppInsight for SQL also, DPA creates a sub-view so it's easy to use both tools to analyze the database instance.


  • Advisors : The Instance View has a version of the Advisors resource similar to the one on the Summary View.  However, this one targets the instance as opposed to aggregating several like the one on the Summary View.  We discussed Advisors in my last post.  This one is similar but provides advisors for this instance only.

  • The Spark Line resources are intuitive.  You may be familiar with them from other products like Server Application Monitor (SAM) or Virtualization Manager.  These spark lines show resource metrics obtained by DPA.  Notice that while many of the metrics appear similar as ones you can get in SAM, they are usually not the same.  For the few are also collected by SAM, DPA polls more frequently, often once a minute as opposed to every 5.  So this data is more granular and helps you find needles in the haystack.  For example, your storage admins may typically only review metrics polled at 5 or 10 minute intervals.  Guess what, they won't see needles in the haystack like DPA does.  This is so important for sysadmins responsible for database performance because a 30 second disruption might be devastating to end users and be washed out in a 5 minute poll.

Pivoting Wait Time is one of my favorite troubleshooting techniques.  When you click into a Database Instance, you will see a more detailed and powerful analysis of wait time in the Database Response Time resource. 

This resource provides multidimensional performance analysis:

  • By Individual SQL queries
  • SQL Queries Aggregated by Wait Types
  • SQL Queries Aggregated by Applications

This is useful because sometimes the root cause is an individual query and sometimes it's several queries from an application or a resource constraint affecting all.

In the first pivot (1st image) of wait time, I can see that there is no one SQL that is the cause of most of the wait time because the queries with the most wait time are very small relative to all remaining queries. 

In the second pivot (2nd image), I've pivoted by wait type.  I can see that Memory and CPU are the most significant wait type.  That means real work is happening as opposed to waiting on storage or locks.  Now you may not know all the hundreds of wait types you'll see, but DPA does.

When it comes to wait types, click on the (2nd image) and DPA tells you (3rd image)

  • What the wait type means
  • Who typically resolves this wait type
  • Options for reducing waits of this type


In the third pivot (4th image), I've pivoted by application and see that "Ignite" is the application with the most significant waits and ".NET SQLClient Data Provider" is a distant second.  Note that ".NET SQLClient Data Provider" is the default name you will see if your .NET developer did not specify an application name in the database connection string. 

Now since I want to find something to tune, I pivot back to SQL and exclude "Remaining queries" by un-checking it (5th image).  Now I know the 5 queries causing me the most wait time and that is something we can work on.  Of course none of these examples show a lot of wait time.  I'm only doing this to demonstrate how I would use this resource. What if you wanted to know more about a query?  Click on it and you will see a nice report analyzing historical performance of this one query (6th image).


So with wait time analysis, AKA response time analysis, you can find needles in the haystack:

  • If your most significant wait types are related to storage sub-system performance, don't jump to the conclusion that you need faster storage.  Optimizing queries for storage may resolve performance issues. Or maybe a single database file needs lower latency, but the rest of the files are OK.
  • If a single application is suffering but other applications using the same database instance are not, then maybe your application's database needs special attention, not the whole instance.
  • Maybe a single query is causing grief to everyone but it's application is happy and thus off your radar.  For example, maybe someone has used Excel to query your database instance and allowing it to dominate database resources for an hour.

And just to reiterate, you don't need to know what all of those wait types mean.  When you don't know, click on the icon and DPA will tell you what it means, what can be done about it and who would typically do that.  This is so huge, I had to say it twice.  :-)

And because wait time analysis may be new to you, here's some information on the technique.








Stay tuned!  My favorite features are coming up in the next post.


For about a year now, The Database Performance Analyzer (DPA) team has been planning how we'll integrate DPA into the Orion suite.  One of the first questions was, “where will DPA content be presented in Orion?”  And we felt that since Server Application Monitor (SAM) provides the Applications tab, DPA should add a Databases tab.  But since SAM also monitors databases, we decided the Databases tab should be a home for all things database whether they come from SAM or DPA.  In this post I’ll show you the Databases Summary view.  I hope you like what you see and invite you to consider joining The Beta which is open to customers with both DPA and Orion products, like SAM, in active maintenance. 

To try it out, please fill out this short survey.




In this 3 part series, I'm going to tell you about :


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



DATABASES TAB IN ORION!  Based on conversations I've had with Solarwinds customers showing interest in DPA, those 4 words may be all they wanted to hear. Integrating DPA with Orion will add a "Databases" tab.  And it's not just for DPA!  We're making this a home for all of your database monitoring.  So if you also use SAM to monitor some databases, clicking the Databases tab will take you to the Databases Summary View which provides a dashboard style glance at database performance across your organization.  And if you also use AppInsight for SQL to monitor your databases, you can get to it from here too!


Database Instances : This is one of the most prominent resources on the Databases Summary screen.  The red and yellow boxes summarize the number of critical issues and warnings detected.  They are also buttons that allow you to filter your list of database instances to reveal the instances with critical and/or warning status in either SAM or DPA.  DPA reveals KPIs on the right which indicate potential problems i.e. wait time, query advice, cpu, memory, disk and sessions.  SAM reveals it's status on the icon at the left of each row, and of course you get to see the node status like you are accustomed to in Orion.  So if you monitor a database instance with SAM and DPA, you get a health perspective and a performance perspective.  Clicking on one of the instances takes you to the Database Instance View.  We'll cover that view in my next postClicking on the KPIs from DPA on the right takes you to DPA's Database Instance View, which will be a sub-view if you are also monitoring with AppInsight for SQL.


Advisors : One of the most popular features for people that are new to DPA are the Advisors. Every instance monitored by DPA receives hourly analysis that provides information about queries that DPA thinks you should look at.  So this is a place you can find ideas for improving performance that you might not have noticed.  Advisors are either critical, warning or informational. When you click on an advisor message, it will open a detailed analysis in a new window.

They will tell you things like:

  • The most significant wait type.
  • Performance throughout the day.
  • When a query used a significant share of CPU or memory resources.
  • When a query has accounted for greater execution time in one hour vs another.
  • When an index may help.
  • When a query is being serviced by multiple execution plans. 
    This can cause significant performance issues as seen in the 2nd and 3rd image of this set.
SummaryAdvisors.JPGAdvisor.png AdvisorMultiplePlans.png

Instances With Highest Wait Time : Something that may be new you, is the concept of database wait time analysis AKA response time analysis.  Expert DBAs have used this technique for over a decade to accurately identify why queries are slow and what can be done about it. This isn't a dissertation on wait time so I've provided links to more detail below.  For now, let's just say you can ask a database instance why queries are slow, and it will tell you! DPA continuously polls database instances, recording all of those answers so it can produce this histogram that tells you which of your database instances are causing the most end user wait time over the past 2 weeks.

Information about "Response Time Analysis" AKA "Wait Time Analysis"



In my next post, I'll show you some cool ways you can identify performance bottlenecks at the instance level.  And keeping with tradition, I'm saving the best for the last post!  Stay tuned.


Following up on Kathy's great post, Announcing Beta for Database Performance Analyzer (DPA), which introduced some features in Database Performance Analyzer (DPA) 9.0.  I am writing today to tell you about some more DPA goodness heading your way.  In this post I will tell you about:


Before I get to the new features, I’d like to tell you why I love DPA. I didn’t decide I would become a DBA, go get training and then apply for DBA jobs.  It was quite the other way around.  I was a developer, there were DBA things to do and I won the honors (or lost depending on your perspective).  I still had my development duties so I didn’t have a lot of time to devote to DBA work.  In the early days of my DBA work, I was frequently over my head, combing Google for ways to interpret resource metrics to diagnose problems for development.  This made me what we call an “accidental DBA”.  It’s not a bad thing, it’s just how you come into it.  And for me, it was blessing b/c I discovered something I loved.  I loved the art of performance analysis so much that I made my own tools for it.  And they were so good that I mocked all of the 3rd party tools as being inferior to mine.  Even if my boss offered me budget to buy the tools I didn’t want them.  Then I discovered DPA at a SQL Saturday and was blown away that it did things the way I did them!  OK, maybe a little better…  As proof of how impressed I was, I applied for a DPA Product Management position… and here I am!  Telling you about it’s cool features.  And Basically put... There's no better way investigate database performance problems unless your users start complaining about buffer cache and queue depths instead of saying, "it's slow!"



If you are interested in being a part of the Beta program, please click the link below. The only requirement is that you must be an existing DPA/Ignite product owner under active maintenance.



New Version Support

As you might expect, our new version will advance support for newer versions of database platforms.  DPA 9.0 is being tested on and will support SQL Server 2014, Oracle 12c (single tenant) and DB2 10.5.

SQL Advisor Drop Down

Use CaseDisplay

One of the most popular new features according to a survey of DPA users is the SQL Advisor Drop Down.  DPA 8.3 already has SQL Advisors.  SQL Advisors are our way of offering you expert advice on what you might want to look at to enhance performance.  The way it works, DPA makes choices about what queries to analyze and the Advisors Tab will show you advisors sorted from most recent query to least recent query.  DPA 9.0 still does this, but sometimes you may want to know what DPA has to say about a particular query.  Now you can do this!  There's a drop down menu that lists the queries within the window of time you are analyzing.  When you select one, DPA will do an ad-hoc analysis for you!  This is especially useful for an accidental DBA because if you've got a new query going into production and you haven't the DBA experience to know what to scrutinize about that query, DPA can do it for you!  If you are an experienced DBA, it's a good place to start.  Experienced DBAs might appreciate time savings by deferring first level query analysis to a developer who uses this tool.  So no matter what your level of experience, this is handy!

SQL Advisor1.png

SQL Advisor2.png

SQL Advisor3.png


Resource Metrics Baselines

Use CaseDisplay

People often ask how much is too high or low for particular resource metrics?  The answer is usually, "it depends."  Sometimes "experts" will give you specific values and when pressed, they admit that they sort of knee jerked an answer so it was far from scientific.  That's why the new Resource Metrics Baseline feature enables you to take the default we chose and allows you to override it.  So you get good rules of thumb out of the box and the ability to customize it for your environment.

Imagine you have a new DBA on call who doesn't know what to expect for a particular environment?  Voila!  Now he can.


Manager: "Hey Johnny New Guy, how's the Physical I/O look?" 
Johnny: "Periodically there are bursts significantly over the baseline, but it looks fine."

Manager: "Wow!  That was a quick answer.  This new guy is really working out."



File & Drive Tabs

Use CaseDisplay
What if you have lots of databases on your server and your I/O problems are less of a problem at the database level, but the aggregate I/O problem at the drive level is an issue?  That's why we've added a drive tab.  You can aggregate all of your file access wait time by the drive to see the busiest drives.   DriveTab.PNG

Of course now that you know which drive is getting hammered, what can you do?  Assuming that some volumes have enough IO while others are hammered, you might want to move some database files, but how can you choose?  Well, we've got a file tab where we show you your I/O wait times by file.  Now you can start shuffling which database files live on which drives based on their I/O load.



Alert Blackouts

Use CaseDisplay
You know those times you need to suspend alerting for some window of time?  Perhaps because of maintenance, for example.  Maybe it happens every week at that time?  Maybe you aren't part of the team doing the maintenance and you don't want to have to get up to do some manual work around that temporarily suspends the alerting.  Or maybe doing so would conflict with Saturday morning cartoons or Saturday Night Fever...  :-)  We've got ya covered!  We created an Alert Blackout tab under the Alerts screen.  It's a place to define recurring blackout windows.



Current I/O

Use CaseDisplay
One of the coolest new features in DPA 9.0 is the current tab in the new Storage I/O feature.  This screen provides easily understood indicators of workload & performance.  It will sort the files by the most active files/drives to the least active files/drives.  So if your users are complaining about performance right now and you suspect I/O, this can help you decide if your hunch is spot on or if you can rule it out.CurrentTabUnderStorageIo.PNG


If you are interested in being a part of the Beta program, please click the link below. The only requirement is that you must be an existing DPA/Ignite product owner under active maintenance.


Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.