2

We have a massive MS SQL Server production environment with thousands of tables in dire need of index tuning & pruning. Any suggestions on the best ways to test proposed changes outside of production?

Obviously, we can (and do) stand up a DEV database server where we can make changes, but that DEV copy won't reflect the real-world demands being made on the tables. We also have a production mirror that uses transaction log shipping, but mirrors are always read-only (unless you fail them over to primary), so we cannot test index changes there.

Is there any way to ship transaction logs to an instance that isn't a read-only mirror? Obviously that could encounter problems, especially if schema changes are made in the test environment. Even with only index changes, you could have query timeouts and other inconsistent behavior.

But that's exactly what we are looking to do: Given a set of index changes, how do real-world queries, under real-world load, perform? Are they faster? Do they fail?

A few test queries won't suffice. We run all kinds of nightly, weekly, and monthly processing jobs that hit the database hard. We also have a lot of external scripts and services that query and update the database in ways we don't always anticipate.

Given the scope of the changes that are needed, I am very hesitant to make any live production index changes without verification.

Neil Laslett
  • 177
  • 1
  • 1
  • 7

3 Answers3

2

You can take a trace of traffic on the production server and replay the traffic on a backup restored to a test server. If you only use read-only queries, these don't need to be extremely coordinated.

Check out the Database Experimentation Assistant, or the older RML Utilities to help you capture the trace, turn it into a replay, and restore a coordinated backup of the production database at the correct point-in-time.

David Browne - Microsoft
  • 49,000
  • 3
  • 53
  • 102
0

Log shipping won't help you. As soon as you do RECOVERY to make the database read/write, you won't be able to restore any new log backups.

Unless... you can time it so that after doing your tests (however you define that time-span), you re-start the log shipping from a full backup.

Another option would be transactional replication. Since that work on a (basically) logical level it allow you to have different index schemes. But, I really really don't like replication from a management viewpoint, so this would be my very last resort.

IMO, you should present to management the need for a performance test environment. Either re-work your current log shipping so that it allow for periodic full restore or add a new environment (hence present to mgmt) for this purpose.

Tibor Karaszi
  • 18,269
  • 2
  • 17
  • 30
0

I think instead of shipping logs to dev server you should save and reproduce workload of production on dev copy and compare executions.

SergeyA
  • 1,522
  • 1
  • 5
  • 9