Want to lower the cost of your database operations? You might start by consolidating database servers and loads, reducing the number of servers or standardising software. Even if you’ve settled on a single database engine like Oracle, it’s common to have multiple different versions in use; out of all the organizations using our dbWatch tools, only one managed to converge on a single version of Oracle. But just as you need to see if you’re making the most of your hardware and software environment, you also need to check if you’re using your budget efficiently on what can be complex licensing decisions.
You don’t want to waste money by over licensing or risk an audit that discovers that you’re not paying for the database versions and features you’re using. Efficient licensing means having the correct licenses for the features and the numbers of databases you run, so you need to know whether the licenses you have match the license you really need. The license reports in dbWatch are an excellent way to do that.
Inadvertenly scaling up Oracle
With Oracle licenses, becoming an Enterprise customer inadvertently is as simple as running a command that requires a single Enterprise Edition feature (and the database tracks which features are in use). If you restore a database and turn on compression, you’ve immediately become an Enterprise customer. Partitioning a database is an Enterprise feature; are you turning that on for databases so small you don’t get any performance benefits?
Even performance monitoring and database statistics change the licenses you need (something to beware of if you need to supply performance information as part of a support call). If you look at historical performance, you trigger both the Tuning and Diagnostics Packs, over and above the Enterprise Edition license, even if you’re not using Enterprise Manager, and their per-processor cost is more than a quarter that of an Oracle processor licence. Ironically, the best way to discover your license liability for your Oracle environment is to run monitoring scripts, which themselves trigger features that need extra licenses, and the tables of information they produce can require significant expertise to analyse.
dbWatch can report on what Oracle features you’re using and what license you have so that if there’s a difference between the two, you can take action before an audit happens – whether that’s turning off those enterprise features or allocating budget to cover the licenses. The reports also include a handy list of which Oracle features trigger extra licensing requirements. You can see a sample report of license issues here, section 1.3.
That tracking can also be useful for auditing your audit. Because the dbWatch reports show how many times a feature has been used, and the first and last date it was in use, one customer facing a very large bill was able to prove that the feature that made them liable for an enterprise license was only used by an Oracle consultant on one single day rather than as part of their normal production service.
You also need to consider what hardware you’re running your databases on, and even the virtual environment they’re in. Oracle uses different CPU licensing factors for different versions of VMware, and if you use an Enterprise feature in one database in a virtual environment the licensing applies on all the physical CPUs in that environment. Another dbWatch customer who used a feature that made them liable for an Enterprise license on a single Oracle database running on a 50-core VMware cluster was presented with a seven-figure licensing bill – which they were able to reduce significantly by using the licensing report in their negotiations with Oracle.
For more insight and tuning of your database server farm, start reading aobout SQL monitoring.
The dbWatch engine itself works with Oracle Standard Edition as well as Enterprise Edition, and includes many of the configuration, tuning and management tools you might otherwise need Enterprise Edition and Oracle Grid Control for.
Optimizing and troubleshooting a database server means looking at how well it’s been running, so you need to look back at performance and diagnostics information to get all the relevant information, and that’s even more important in a clustered environment, where the cost of an Enterprise license can be extremely high. If you’re dealing with a complex Oracle installation – and especially if you’re bringing in consultants to tune the system - you need to either budget for an Enterprise license with the extra Tuning and Diagnostics packs, or use a third-party tool like dbWatch (which has a much lower price).
Often, Enterprise features that you didn’t know you were using turn out to have been turned on by consultants – or by someone clicking through the Oracle Grid Control interface to see what features are available, so you’ll want to run these reports regularly. That could be every month or even more often, because you only have ten days to remediate your usage of Enterprise features to avoid being liable for the extra license. If you don’t want to schedule reports, dbWatch can even send you an alert when you make a change to a database that triggers extra cost features.
Scaling down SQL Server
With Microsoft SQL Server, you have the opposite problem. Even though the SQL Server APIs are now unified across the Express, Standard, Enterprise and Developer editions - so the programming interface always looks the same to the database developer - you can’t use any features you haven’t already licensed. That makes it tempting to install Enterprise edition to make sure all the features are available.
Enterprises frequently have large numbers of instances with Microsoft SQL Server Enterprise edition installed by default, even if they’re small and relatively simple departmental databases that don’t need the partitioning, compression, clustering and other high-end features a data warehouse requires, and could run happily on Standard edition. Sometimes that’s because more features have migrated into Standard edition over the years and a database uses a feature that used to require Enterprise edition but no longer does. And database admins who are used to older, less capable server hardware may install Enterprise edition to get performance that new server hardware can deliver with Standard edition.
You can use dbWatch to see if you need to scale up your Microsoft SQL Server environment and take an Enterprise license to utilise more CPUs and cores to improve performance, or if you don’t really need the editions you’re paying for and can scale down. The reports also include resource information like the on-disk size of each database so you can see whether you need Enterprise edition features like compression and partitioning or not, or whether you can even consolidate onto fewer servers, giving you less to monitor and upgrade.
With the sheer number of databases businesses use these days, you need good tools to make sense of the cost of licenses and the level of performance your database environment is delivering. The information you can see through dbWatch lets you consider performance management, consolidation and license management together so you can manage efficiently, analysing the database environment and optimising the licensing costs and hardware provisioning as part of optimising performance for your business needs. Instead of doing that manually (a lengthy process when you have a large number of instances), dbWatch lets you automate collecting and analysing the information about your databases, so you can set up a continuous cycle of monitoring, auditing and optimising your database environment.
Final note: Clouds like Azure SQL changes everything again - you no longer pay for license, but for usage. How does that affect your business? What tools will you need to manage database cost in the cloud?
