Oracle Database 11g shoots the moon
Oracle's enormous 11g release rumbles with an impressive array of performance and management aids, elegant application testing, standbys that earn their keep, and the promise of lower storage requirementsFollow @infoworld
Oracle has implemented Result Cache pretty well, and it does exactly what it's told. In my initial tests, I had no problems seeing results. I tested against just a couple queries to get the feel for it, and I did see vast improvements in my query times. After I bumped up the number of queries and parameterized them, however, I didn't see nearly the same changes as I did the first time. That's not unexpected at all and in no way outlines any kind of shortcoming with the feature. I'm merely pointing out that you need to plan carefully and test thoroughly before you implement it in production.
It should also go without saying that this feature is aimed at improving performance on disk-bound systems and isn't going to do any good on memory-bound systems. If you're already experiencing memory pressure, carving out a buffer in an already constrained system is only going to make things worse. I'd also like to point out that in general, this isn't going to help a great deal with your OLTP workloads. And if you use it on your decision support workloads, be mindful of the query results you're caching. It's easy to forget that even 64-bit systems have memory limits, and that caching a 200-million-row result might not be the best use of your memory resources.
I like Result Cache for what I call nuisance queries, which are lookups you do to satisfy joins or to pull results that rely on table scans -- things of that nature. But Result Cache is a good feature that will let you do pretty much whatever you want to do.
Oracle Database 11g puts just as much effort into monitoring and recovering from corruption as it puts into query performance. Automatic health monitoring is a really big feature in this category because it runs reactive checks or manual checks. Reactive checks get run when a critical error occurs. These checks can examine database structure, data block integrity, redo integrity, and other conditions. When Oracle runs these checks, it creates a report and quite often suggests fixes.
Automatic quarantine of corrupt undo segments is just plain cool. When Oracle discovers a corrupt undo tablespace, it will quarantine the segment and not allow future transactions to use it. This allows Oracle to contain the damage and keep it from spreading.
The Fast Analyze feature will cure a big headache for DBAs of very large databases. Fast Analyze allows you to scan for table-index corruption much faster than before. This is really important because much of this type of maintenance is done during scheduled maintenance windows, and if the analysis operation can't even complete during the window, then neither can the fix.
Data Guard is Oracle's technology for providing a transactionally complete standby database in case of disaster. Data Guard protects against all kinds of system and network failures, and it isn't constrained by location. The standby database can be in the same room or thousands of miles away. But like other fail-over solutions, including remote mirroring and local clustering, the standby is completely idle and unavailable while the primary is online.
A terrific new Data Guard feature, called Snapshot Standby, lets you put the standby database into a temporary read/write mode, allowing you to test database changes while still providing the original HA/DR protection. This feature alone could change the way companies manage best practices around database development, change control, benchmarking, application upgrades, and related tasks.