This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Database Performance Analyzer (DPA) - Best Practise

Hey Guys and DPA gurus,

I wonder if you are able to help me with some tips, links, resources - anything really to understand what would be the best way to go with DPA. I never done it before and we only have license for up to 4 instances to monitor, but it can obviously expand later, so, I am looking for something scalable as well to ensure potential future growth

Should I deploy on main poller or deploy on separate server?

Should I use Orion DB or setup separate SQL box for it?

Are there any pitfalls I need to know?

Can I monitor Orion DB itself?

Please, give me some idea based on your personal user experience. I already have an official admin guide, but I was just wondering what community has to say about it

Thanks a million,

Alex Soul

  • Alex, since DPA is a standalone product at this time, best practice would be a separate box for the installation of the DPA server and its repository database. This is especially true if there are plans or potential for expansion.

    No pitfalls that I know of. 8 ) Are you familiar with wait-based analytics? If not, check into that or read through the carousel once you launch the product for a better understanding (also available in the "Learn More" button from our dashboard.

    You can monitor the Orion DB.

    Full disclosure: I work for SolarWinds, so would also love if others in the community would chime in as you request.

  • Nice one, thanks mandevil​, I was actually planning to deploy on Main poller. OK, I take it as a first learning point. Also, with regards to database architecture - has it got its own database? Can I use Orion SQL or better to have dedicated DB? Can DB run on DPA server itself in production setup?

    Thanks emoticons_happy.png

  • Alex,

    We lit up DPA about a year ago, and here are my thoughts on your questions.

    1. It does officially have its own DB (the repository). I placed this DB on the same SQL instance as our Orion DB with no ill effects, but we're a sub-10000-element single-poller setup for now, so if you're scaling up your mileage may vary. On the DPA side, we're collecting data on seven Oracle and two SQL instances. The front end DPA box doesn't break a sweat, and I've noticed no degradation in the instance performance on the SQL side. If you're likely going to scale up, I'd put the repository on a high-powered SQL box out of the gate. You won't regret it.

    2. I suppose the DB could be run on the DPA server itself, but I don't see a whole lot of benefit - I'd have to license a proper DB engine anyway, so why not leverage what I already have?

    3. If you want to, you can certainly monitor the Orion DB itself. We're monitoring a mix of Oracle and SQL instances.

    4. Delving into wait-based metrics was an interesting learning experience for me - and has allowed me to learn to speak more fluently in the language of DBAs and other DB-centric colleagues. Not only do we know what our bottlenecks are, but we know specifically WHY they're bottlenecks. It's good information, even when it's bad news.

  • For future growth, you may end up with multiple DPA servers.  The way we do it is one application and one SQL server pair for each instance of DPA.  The recommendation is that you monitor no more than 250 databases per instance of DPA, which is why we have multiple pairs (currently 9).  So, the question of putting it on the Orion server becomes a non-factor if you think that you may eventually go over the 250 and need to expand to multiple servers in the future.

  • Thank you guys, really appreciate your help. Ok, I now at least know good practice to get rolling by having DPA outside of the main poller + dedicated SQL box for future expansion. Thanks a million ... heading off to update my design emoticons_happy.png

  • One more question guys - how do you go about DR strategy having DPA on a separate box connected to dedicated SQL instance?

  • Good question, keen to see some answers on this one.

  • We use standard backups as our DR strategy.  All of our DPA / SQL servers are virtual, so we have high availability built into the infrastructure, so the only concern we have is the where one of the servers would go down.  We ensure that we have regular backups and will rebuild the box if needed.

  • As we only have one database instance, we keep daily backups. We arent monitoring a huge amount of databases at one time, so a quick full restore is more than sufficient since all the data is stored in the database. If you are monitoring a high volume of databases, mprodbus's HA is a great way to go, have a failover cluster setup for the DPA database.The failover should give you enough time to figure out the issue in an event of a disaster.

  • Hi Guys, one more quick question:

    I am planning to integrate DPA with Orion and found this:

    Requirements for the DPA Integration Module - SolarWinds Worldwide, LLC. Help and Support

    pastedImage_2.png

    the word "requires" doesn't give me a peace. Would someone please be able to elaborate what will happen if I don't have those modules. Will integration be limited or not possible at all? I am specifically after that SRM, which is out of scope for now here