SolarWinds DPA or OEM? The DBA Says Both!

Did you know 90% of SolarWinds® Database Performance Analyzer (DPA) Oracle customers use both Oracle Enterprise Manager (OEM) and DPA to solve performance issues? Based on my personal experience as a DBA in a large financial services transaction environment, this is not surprising. The combination of the OEM and DPA provides the kind of help I needed to better understand database performance issues and save time, money, and frustration. Here are the three key reasons why you should consider using DPA alongside OEM, and why I think it is necessary if you are serious about improving your performance as a DBA:

• Quickly gets you directly to the source of the problem
• Simple enough for everyone to use, without impacting my production instances
• Provides charts and graphs that managers and developers understand, so I can make my case about the source of the problem

How are DPA and OEM different? Comparing apples and oranges

There are some very distinct differences between OEM and DPA. OEM was created to help manage the Oracle database environment. Citing Oracle documentation, “Enterprise manager is a system management software that delivers centralized monitoring, administration, and life cycle management functionality for the complete Oracle IT infrastructure, including systems running Oracle and non-Oracle technologies.”

In contrast, DPA is a tool that is focused on database performance monitoring using wait time analysis. “Solarwinds DPA tool is a comprehensive database performance analysis and monitoring solution for DBAs, IT managers, and application developers. DPA identifies performance bottlenecks, improves application service, and reduces overall cost of Oracle database operations.”

DPA is easy-to-use tool for root cause analysis

Because DPA is dedicated to solving performance issues, DPA fills a niche that OEM does not. If a DBA is looking for the root cause of a performance issue, they can use DPA to identify the root cause in 3 to 4 clicks. Seriously.

If you don’t believe me, install, and see for yourself. DPA is a great collaboration tool. It’s is completely agentless and puts a negligible load on the databases being monitored and their hosts. Since there is a very light load put on the monitored server from DPA, there is no worry about granting read only access (or more where appropriate) to developers and even management. This enables DBAs and developers to fight problems, not each other.

The tool is easy to read and easy to use, so everyone can see the same the same information from the database thus helping to break down those not-so-invisible barriers — otherwise known as communication “silos” — between departments, management, and worker bees. This is especially useful when I needed to articulate technical issues to management. With DPA’s graphing capabilities, even the less technical people can better understand the impact of performance related issues.

Another place where DPA fills a void is when a company has a combination of Oracle Enterprise Edition (EE) and Standard Edition (SE). You get OEM with both versions; however the diagnostic and performance tuning packs are not available for the SE version. Using DPA with SE can be a lifesaver because DPA doesn’t need the tuning pack tables so the monitoring will be the same for EE as it is for SE. DPA allows you to follow alarms to see problem queries, server resources, trends and sessions.

Sample scenarios: DPA complements OEM

Below are three scenarios that help illustrate how DPA complements OEM and vice versa.

Scenario 1: User receives an alert from DPA. The alert stats that the tablespace is 97% full for a particular database. You log into OEM and add a datafile to the tablespace to get the percent full to go under 75%.

Scenario 2 : DBA receives an alert from OEM. The alert states that the I/O is running very high. The DBA logs into OEM and confirms the I/O is high, the performance tab shows there are several SQL statements running but you can’t pin point exactly where the problem is. The DBA opens DPA and sees there is one query that is causing 90% of all the wait. After drilling into the SQL statement, it is found that this is new code that was put in the previous night, and it is returning 10 times the amount of data due to a mistake in the code migration. You notify the developer and the code is reverted, fixing the problem.

Scenerio 3: Every Monday morning, a user has a report sent from DPA that lists the top 15 SQL statements across their databases. This morning there is a spike on the report for a particular database from Saturday evening. The DBA goes into DPA to find out more about what caused the spike and drills into the Saturday incident and sees that, because it’s of end of month, the Accounting department was working over the weekend and ran a customized report that caused the spike. You can then email the graph that points this spike out with the SQL associated with it to management for your daily OPS meeting to explain what caused the performance incident. Since DPA is easy to read, it is easy to share this information among all the groups.

Final thoughts

In conclusion, some Oracle OEM users might assume they would use either tool but not both. I don’t think this is correct. The vast majority of Oracle DBAs using DPA use OEM for database management (resource usage monitoring, user management, storage management, etc.) and DPA for end-user performance analysis, monitoring, and problem resolution. This is reduces time consuming tasks a DBA has to perform in their day to day job making them faster and more efficient; saving money for the company. All DBAs are being asked to take on more tasks and management of more databases in their organization. DPA is a critical tool in a DBA’s toolbox.