I was recently involved in a query tuning work where we used synthetic, rather than production data, to validate the results of our query and index tuning work. We faced some issues with the generated data that had quite a severe impact on our testing, and that prompted me into writing this blog post. Lets start by first defining what is synthetic data. In my view synthetic data is data that resembles actual production data, but is artificial/generated. I have seen similar (and also more detailed) definitions elsewhere and I think it is a good one.
I also like to point out that there are plenty of good reasons for using synthetic data in testing, as production data is often strictly regulated and not easily available for testing purposes. However, you need to be certain that the synthetic data you are using is similar to what you have in production.
Distributed Replay is a feature that was first introduced with SQL Server 2012. It allows you to play a set of recorded transactions against a SQL Server database. This can be extremely useful if you’re doing hardware or SQL Server version upgrades and want to test the performance impacts of these changes, or if they’re going to break your application.
Not a long ago I was doing a database cluster delivery to one of our customers and as a part of that process, I scheduled our regular set of test runs for the storage. The results of the tests we ran were bad and none of the changes we did at the SAN weren’t helping. After a while we figured out that the issue was not in the test software or at the SAN but in the scheduled tasks we used to run the different test!
In previous post, Part 1: Creating Azure Network and Storage, we set up your Azure account ready for two virtual machines that’ll be the backbone of your own testing environment. One of these servers will run the Active Directory and the other one will host your SQL Server 2012 instance. The Active Directory server is really optional, you can do a test environment without it but I prefer test environments that mimic the production.
Now that you’ve setup your Azure account we can get started on building the test environment. First thing you should do is to create a Virtual Azure Network, this will be used for connectivity between your servers. Creating a Network is quite straightforward business. Choose Networks and then Create A Virtual Network.
Going back a few years (and then some), creating your own test environments used to be difficult requiring both time and hardware resources. Then came the different virtualization solutions, which made it bit more easier but still requiring decent amount of hardware resources and a little bit of time. With the arrival of Azure and other cloud-based solutions, things finally got considerably easier. Now we finally had the ability to set up a test environments quickly and easily.