One of the most interesting things about the new features list in Oracle 11g is the tacit admission that some of the features in 10g just weren’t very well thought out, so rather than merely upgrading them, or trying to address their shortcomings as bugs, a whole new approach to the problem they purported to solve is taken. Take Active Data Guard as an example. With a physical standby in Oracle 10g, it was always possible to take a standby database out of managed recovery and run read-only queries on it. You could happily create temporary tablespaces so you could do big sorts, or use a restore point, opening the database read-write, then when you were done turning it back into a standby and resuming redo apply and letting it catch up. One approach might be to let it pass midnight (in redo apply), open read-only and run batch jobs, perhaps writing the summaries to a third instance, then when these were complete, go back into managed recovery and catch up ready for the next night’s reporting.

The new Active Data Guard allows you to have the database open read-only while applying archived redo logs. Why is this interesting? Because if you can offload large queries like that, onto up to 30 active standbys, then that takes care of one of the major use cases for RAC, scalability, without the complexity and licensing cost of actual RAC! It even seamlessly offloads queries from your primary node onto the standbys based on how far they lag, so there is no need to even modify the application to take advantage of it! Now, the standby uses separate storage, so there is the cost of the extra disks (and powering, cooling and administering them), but these don’t have to be top-of-the-line HDS, you can make do with cheaper NetApps since mere redo apply is much less stressful than OLTP – and you eliminate both the disk contention and cache coherency waits that RAC inevitably suffers from as you add more nodes. And there is the Observer process for managing failover in a DataGuard Broker environment, similar to the Witness in SQL Server Database Mirroring.

Of course you can only have writes going into one node at a time, but in high volume applications in RAC, as I say, you are typically bottlenecked on storage and cluster interconnect anyway – so it’s not actually a big deal to do it this way. At my current site, the biggest RAC system had been configured on two nodes (prior to my arrival) with one for loading and one for querying. Of course, GC waits were the biggest problem! The “architect” had a very high opinion of his own abilities, so high in fact that he must of slept through CS 101 where they talked about the principle of locality. I did a lot of work to build service+resource groups of incoming feeds, user communities interested in that data and their associated batch jobs to keep as much as possible in the local caches as we added two more RAC nodes… But I digress.

Another example of this is change notification. I have used Oracle AQ for nearly 10 years now, and I have never liked it; it’s slow, badly instrumented, fragile, difficult to administer complex topologies and can’t compete with dedicated message buses like Rendezvous†. A common pattern was for a client to subscribe to an AQ, then a trigger on a table would enqueue a message to notify the client when a table changed, so that client application could take some action, whether it was processing the new data, or updating its cache. This meant the developer overhead of maintaining all these triggers, and the runtime overhead of the additional processing. Now don’t get me wrong, this was an infinitely better approach than polling‡ the table – in theory. But AQ wasn’t a good solution to this problem (and I don’t know of anyone using AQ as their general-purpose message bus – it was only really used for situations like this, meaning an organization would need to operate at least two message buses). Now we have a dedicated mechanism for notification – so that’s the major use case for AQ out of the window. Similarly we have GoldenGate now – we don’t need Streams (or logical Data Guard) anymore – and we might not even need Data Gateways either, at least in some cases.

I am sure there are other examples, but right now I consider these three technologies – RAC, AQ and Streams to be legacy only, and I am looking forwards to getting production apps onto a much better foundation, by which I mean, better suited to the common use cases rather than trying to be all things to all people.

† Ironically I used to work for Reuters, who own Tibco, and we still inexplicably used AQ
‡ My associate Dave Webster has an alternative viewpoint on this.