Setting up a capture is a simple four- or five-step process. You typically restart the database, set up options for the capture (which parts of the workload to include or exclude), create the directory to save the capture files, and set the capture start time and duration or manually start it and stop it. If you don't want to capture the system-level activity such as background processes or indexing operations, you can easily filter them out. Or if you want to limit the capture to just a specific application or a specific piece of code you were having a problem with, you can isolate them to make it easier to look at the deltas. The GUI makes configuring exclusion or inclusion filters easy to do.
You can replay the workload on the host system itself (as I did) or from one or more clients. If you capture a large workload, Database Replay has a calibration tool that will tell you how many replay clients you will need.
The reports produced are replete with result numbers comparing the capture workload and the replay workload. You can get literally hundreds of different calculations, but while all of these different metrics are available, they're not very pretty. In fact, they're just one table of numbers after another. It would be nice to have some high-level graphs and such to point you in the right direction. You can export the data, however, so you should be able to do something else with it if you wish.
Another way to go about analyzing your workload, complete with graphs, is to simply record the data in SQL Performance Analyzer as you run your replay workloads. The database doesn't know the difference between a workload being fed by 100 users or by a generator hitting it with 100 virtual users, so you can simply capture the live data in Performance Analyzer while you're doing your replay tests.
The easiest way to get bang for your Real Application Testing buck is to use Database Replay in conjunction with Data Guard's Snapshot Standby feature, discussed above, which saves the state of your standby database and allows you to restore it later (along with logs that have been shipped in the meantime). The combination of Database Replay and Snapshot Standby gives you a powerful and flexible way to test changes to your applications. You simply capture the workload on the primary using Database Replay, set your standby in read/write mode, make the changes you need to make, and then replay the workload on the standby. When you've finished testing, you can record your results and put the standby back into a consistent state with the primary.
Figuring out how to accurately test changes in your own real-world environment without doing it in production is one of the biggest problems in database management. Database Replay solves this problem in an easy and elegant way.
Advanced Compression
Another separately licensed option is Advanced Compression. A way of writing data to disk so that it takes up less space,
Advanced Compression can reduce storage costs, reduce memory and network bandwidth requirements, and even improve query performance.
Advanced Compression saves storage space by replacing duplicate values (like the date in orders placed throughout a given day) in a data block with symbols for those values. In other words, Advanced Compression doesn't actually compress the values, but normalizes the data just like database design does. The more repetitive your data is, the more success you're going to have with Advanced Compression. Also, because Advanced Compression works at the block level, the compression ratio will depend on how you order the data in your tables.
Sean McCown is a contributing editor of the InfoWorld Test Center. He also writes the Database Underground blog.
Talkback
E-mail
Printer Friendly
Reprints



