Q3 Release Notes

In Norwegian we have one word: robustifisering. In English that word is a phrase, to make something more robust. With this most recent update, we’ve worked hard with ‘robustifisering,’ with improved reliability across a wider range of system configurations and operating environments. 

Read the full release notes in the dbWatch Wiki.

Improved support across Windows configurations 

First, there’s better support for different Windows configurations. We’ve implemented changes that improve monitoring reliability across a wider range of Windows configurations, including configurations involving accessibility features. Now only the winter weather may freeze you, but your windows configuration won’t freeze in your monitoring view. 

Improved recovery in large virtual environments 
dbWatch now handles temporary Virtual Machines (VM) freezes and connection interruptions more effectively, particularly in large environments where backup processes may affect many systems simultaneously. 

Auditing the Management Layer Beta Version 

There is an important distinction between database auditing and auditing the tool being used to manage the database. Database-native auditing can tell you what happened inside the database: access to objects, changes to data, permission activity and other events supported by the database platform. 

dbWatch is a privileged operational tool. DBAs can use it to monitor systems, investigate problems, and perform management tasks. In larger environments, many people may have access to different parts of the same dbWatch installation. 

That creates another useful audit question:  What did the users of the database management system do? 

The dbWatch audit functionality provides a higher-level record of activity. It shows administrators who has been using dbWatch and tracks actions performed through the product.  

For a small DBA team, that may simply make troubleshooting easier. If something changed, you have another source of information for reconstructing what happened. 

For a large enterprise or MSP, it becomes much more significant. You may have dozens of people working across hundreds or thousands of databases. Different users may have different permissions and responsibilities. In that environment, operational accountability becomes part of running the estate properly. 

Extending Security & Compliance to PostgreSQL 

PostgreSQL support in the Security & Compliance package continues to improve with around 20 checks implemented from an expected set of roughly 45 at the time of writing. The reporting framework and surrounding functionality are already in place, while additional checks still need to be completed.  

That also means we would like more real-world testing. 

If you are running PostgreSQL and already use dbWatch, particularly if security and compliance are important in your environment, this is a good opportunity to try the functionality and tell us what you find. Real database environments are considerably more interesting than test environments. 

Seeing Better in Dark Mode 

dbWatch Control Center now has a dark interface option, giving users another way to work with the client and making long sessions easier on the eyes. 

A More Robust dbWatch

Taken together, these updates are about making dbWatch more reliable and easier to work with across different environments. Or, to borrow the Norwegian word once more: a little more robustifisering.

Take a look

Book a demo and see how dbWatch can help your organization.

Database Benchmarking for Performance

A bench is a word play about benchmarking databases.

It’s not hard to estimate how well your databases perform. You know the hardware or service level, the configuration, the resources available to it, and its normal behavior.    

When you need specific performance measures, like total execution time or logical reads per second estimates, it’s time to start benchmarking. It provides you with measurable answers over time. 

Benchmarking in dbWatch Control Center free as part of a free trial or normal performance tuning. 

When is Database Benchmarking Useful? 

Most people use database benchmarking to compare performance objectively. It helps to confirm that a change delivered the expected result, or detect when performance has shifted over time. Here are some examples of when we use it:  

  • Before moving a database: Benchmark the existing and proposed environments before a migration. This gives you a direct comparison using the same workload, whether you are moving to the cloud, between cloud providers, or to a different service tier.  
  • When evaluating infrastructure: Compare physical and virtual environments, hardware configurations, resource allocations or cloud tiers. Instead of relying only on specifications, you can see which setup actually performs better under the same test.  
  • When checking for performance regressions: Run the same benchmark periodically to create a reference point over time. If performance changes significantly, you have measurements showing when and how much it changed.  
  • When buying infrastructure as a service: Run the benchmarks regularly, and if the service provider changes the setup, you will know and have evidence. 

How to Benchmark Your Databases in dbWatch  

The database benchmarks in dbWatch Control Center are available to existing users and during the free trial, so you can run them against your own databases and compare the results.  

The dbWatch benchmark runs a defined workload against a database so that you can measure performance under the same conditions each time. The benchmark performs a sequence of database operations — including INSERT, SELECT, UPDATE and DELETE — and measures how quickly the database completes them.   

This repeatable test makes it easier to compare performance, as seen in the case study below. 

An Azure Case Study 

We have been using this approach for quite a while. In 2016, we used dbWatch benchmarks to investigate the performance of Microsoft Azure SQL Database. The resulting report was published in February 2017. Note: This report is historical. The results are not valid today; it’s just a relevant use case.  

The report focused on three service tiers: Basic — 5 DTU, Standard S3 — 100 DT, Premium P2 — 250 DTU; in three areas: West Europe, West Japan, and West US.  We applied the same workload each time we measured. The results show that performance could vary by as much as a factor of five. The results are statistically significant and show that, when performance matters, measuring it matters too. 

You can read the original study below or learn how to set it up.

View Azure Case Study

Measure Benchmarks When Needed 

A benchmark gives you statistics of when and by how much a database changes. 

It is a simple tool, but a useful one to keep in the DBA toolbox. Before a migration, infrastructure change, or new service deployment, run the benchmark and keep the results.    

Because when performance matters, it is better to know than to assume.  

See What Your Database Actually Does