Database Reference
In-Depth Information
As you can see, 365 events were captured, but only 244 events were replayed. Of those, only 151 events actually
succeeded. In this case, you might need to establish what information might exist about why some of the events
failed. To do so, simply reconfigure the tests and run them again. The whole idea behind having a repeatable testing
process is that you can run it over and over. The preceding example represents a light load run against my local copy
of
AdventureWorks2012
, captured over about five minutes. However, I configured the limits on idle time, so the replay
completes in only 58 seconds.
From here, you can reconfigure the tests, reset the database, and run the tests over and over again, as needed.
Note that changing the configuration files will require you to restart the associated services to ensure that the changes
are implemented with the next set of tests.
When running these tests, it's a good idea to use the types of performance data collection I talked about in
Chapters 2 through 6. This helps you ensure that you can see exactly how well—or how badly—your tests are
performing.
Conclusion
With the inclusion of the Distributed Replay utilities, SQL Server now gives you the ability to perform load and
function testing against your databases. You accomplish this by capturing your code in a simple manner with a
server-side trace. If you plan to take advantage of this feature, however, be sure to validate that the changes you make
to queries based on the principles put forward in this topic actually work and will help improve the performance of
your system. You should also make sure you reset the database to avoid errors as much as possible.
