Open for Voting

Ability to use one Database for NPM & New NTA

Dear SolarWinds,

When checking Microsoft licensing for Always On groups, I noticed that now there is a new budget challenge.

Currently, NTA requires additional (second) SQL database, which requires additional costs for SQL HA functionality.

We have two options for Always On:

1. Always On Availability Groups requires SQL Enterprise Edition

2. Basic Availability Group (Always On Failover Clustering) is supported in SQL Standard Edition

Unfortunately SQL Standard Edition only supports one database for above feature.

This means that even with small NPM + NTA installations, customers with AlwaysOn SQL requirement, will need to purchase Enterprise Edition.

Article from Microsoft:

"Support for one availability database."

Basic Availability Groups (Always On Availability Groups) | Microsoft Docs

The difference in price can be even between 7.000$ and 27.000$ per server, depending on discounts or bundles with hardware.

Would it be possible to use one database for NPM as well as NTA? If the environment is not too big with not too many flows per seconds, I think the performance would be fine.

If I missed something (as Microsoft licensing is the most complex of all known IT products), please correct me. Thanks emoticons_happy.png

Kind regards,

Marcin Kazmierczak.

---

IT-Indago Ltd. - Authorized Reseller & SolarWinds Certified SCP Professional

IT-Indago – Let's monitor  |  Follow us on Facebook & LinkedIn

  • I recently migrated seven pollers from 2012 to 2016, and also did a migration from an older SQL version to SQL 2016.  When I upgraded to the current version of NAM after the hardware migration, I then upgraded to the current RC via a guided install.

    I saw the additional database being created and never thought about licensing issues.  I suspect it wasn't an issue in my case because we are running Enterprise SQL licensing.  I never thought to check with our DBA's about licensing costs--especially after we were given a complete UCS environment all our own, dedicated just to the Orion DB.  Sometimes a person doesn't know how good they have it until they see feature requests that make sense.

    I support this request if only from the budgetary concerns of having to license more SQL servers.  How it impacts the back end of Orion performance . . .  well, that's something for the engineers to deal with.  Hopefully SW users won't be stuck at the mercy of MS SQL licensing.