Plus, configuring Active Data Guard, at least on Windows, is no picnic. I spent weeks in e-mail, on the phone, and in online conference with Oracle reps trying to get Active Data Guard up and running. The directions given online are incomplete, and there's no guidance on troubleshooting at all. Had I been alone trying to set this up, it never would have happened.
That said, there's nothing in the Active Data Guard setup that couldn't be done by a wizard, and in fact a wizard will be coming in Grid Control 11g, according to Oracle. Built-in monitoring and alerts would also be an improvement. As it stands, you have to set up your own scripts and alerts to monitor whether your logs are being shipped and applied.
Caveats aside, Active Data Guard is a huge leap forward, and DBAs will love what it can do. After I got the standby up and running, it seemed to perform very well and did exactly what it's supposed to do. I could hit it with queries, write to it, and it would resync with the primary when I switched back. It's also easy to use. It takes just a single statement at the command line to switch between modes.
Real Application Testing
Real Application Testing, an option comprising Database Replay and SQL Performance Analyzer, is a new feature in Oracle Database 11g that allows you to capture a workload, replay it on the same system or a different one, and then compare the results. Database Replay will replay your workload exactly as it happened complete with concurrency and timing, allowing you to fully test system changes against your actual production workload. Thus, you can see the true impact of changes to the database (index changes, percentage free, table partitioning, and so on) before introducing those changes into production.
In my tests, Database Replay was easy to configure, and it performed exactly as expected. You have to learn just a couple simple concepts related to setting it up -- such as how to create the directory object in the database to capture the workload and how to start the replay from the command line -- but once you get past them, it's smooth sailing.
My test was a 50-user read/write mixed workload. In between tests, I deleted indexes from my tables so that I could see changes in the report numbers. As expected, dropping the indexes did increase the performance of the writes, while decreasing the performance of the reads. I was able to verify that the replay mechanism re-created all my threads and ran them flawlessly.
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.
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.
In addition to storing more data on disk, Advanced Compression can improve I/O performance. Because more data is being squeezed into less space, it's easier for the database to satisfy queries. The database is physically pulling less data from disk for the same information, so it can do it faster. The catch is that these benefits only extend to table scans, not indexed queries.
So Advanced Compression will improve the performance of some queries, but not others. And it will dramatically reduce storage requirements for some kinds of data, but not others. Further, even for the same kinds of data, overall compression ratios will differ depending on how often the data repeats and how you order (index) the data.
Finally, percent free (PCTFREE), the percentage of a page left empty for inserts or updates, will also be a factor. The better the data "compresses," the more of it will fit on a page, and the fewer pages the engine must traverse to satisfy the query. These gains could be seen everywhere from slightly faster queries to reduced blocking.
I tested Advanced Compression against two separate databases. In the first case, the database was generated from the TPC-C order entry benchmark, which simulates a complete environment for online transaction processing. In the second case, the database was the OLTP Table Compression Test Kit provided by Oracle.
You would expect from Advanced Compression that different tables and different data will behave differently, and this is just what my two tests showed. Two tables in the Oracle Test Kit not only compressed to a quarter of their original size, but reaped big gains in query performance and even improvements in write speeds. The TCP-C database tables compressed far less, ranging from 15 to 57 percent savings, and saw no benefit to query or write performance. In fact, performance took a hit. (See details of the two tests and tables of the results.)
Naturally, the results I got in my tests, and the results that Oracle gets in its tests, will not be the same as the results you get in your tests. Expect your compression results to differ from one table to another as well, sometimes dramatically. And be aware that making changes to the base-level table can change your compression ratio. If business or reporting requirements change (as they often do) and you have to order your table differently, you could lose a good deal of your compression. Worst-case scenario, you might suddenly find that you no longer have enough disk space.
Also note that Advanced Compression could impose a cost in system resources. When I set up the read tests for the TCP-C data, I ordered the tables to cluster all the like data together and then queried from that data specifically. I expected that clustering like data would greatly improve scan performance. But that's not what happened. So unless you test thoroughly and with your real production data, you may be surprised by the results.
Advanced Compression can be a huge asset for the smart DBA who manages it correctly and has the forethought to pull it off and maintain it well, but it adds a level of complexity to making changes that you have to be careful about. And even before you implement it, you'll need to do plenty of regression testing to ensure that your apps will work as before.
Overall Score (100%)
|Oracle Database 11g||9.0||9.0||8.0||8.0||9.0|
You may still be better off sticking with Win7 or Win8.1, given the wide range of ongoing Win10...
Now that we're down to the wire, many upgraders report that the installer hangs. If this happens to...
Based on a technique created by a German blogger, here's how to stop wasting hours checking for Windows...
Sponsored by Hewlett Packard Enterprise
The swirl of new enterprise tech settled a bit in 2016, leaving a clear framework for the future -- and...
Picking an Android phone can be difficult, but we're here to help. These are the top Android phones you...
What does the future hold for Python, aside from new versions of the language? Let's check the crystal...
Thanks to stalwarts like MySQL, MongoDB, and Cassandra, the database realm has been a haven for open...