Must I purchase Active Data Guard if I am not using Real-time Query or RMAN block change tracking on my standby database?
No. An Oracle Database Enterprise Edition license is the only license required to use Data Guard features other than those explicitly included with the Active Data Guard Option as described in the table above.

I am already using Data Guard 10g, do I need to purchase Active Data Guard when I upgrade to Oracle Database 11g?
No - as long as you do not enable the Real-time Query feature or RMAN block change tracking on your physical standby database. Thus your physical standby database could be open read-only, but it cannot be applying redo at the same time. Similarly, you can perform RMAN incremental backups your physical standby, but you cannot perform fast RMAN incremental backups using RMAN block change tracking.  You must only purchase the Active Data Guard Option if you wish to use either or both of these features.

Separate from Active Data Guard - Oracle states that Data Guard 11g continues to be an included feature of Oracle Enterprise Edition.  What are the new Data Guard features that are included in Data Guard 11g?
Data Guard 11g has many new features that enhance its value for data protection and availability, and just as with previous Data Guard releases, these new features are included with Oracle Database Enterprise Edition at no extra charge.

I thought a Data Guard physical standby could always be opened read-only and/or used for incremental backups - why do I need the Active Data Guard Option?
Previous capabilities did not allow Redo Apply to be active while a physical standby database was open read-only, and did not enable RMAN block change tracking on the standby database.  This resulted in (a) read-only access to data that was frozen as of the time that the standby database was opened read-only, (b) failover and switchover operations that could take longer to complete due to the backlog of redo data that would need to be applied, and (c) incremental backups that could take up to 20x longer to complete - even on a database with a moderate rate of change. Previous capabilities are still included with Oracle Data Guard 11g, no additional license is required to use previous capabilities.

Why would I use Active Data Guard and not just add another node to my primary Oracle RAC cluster to enhance performance?
Oracle RAC offers many advantages for scalability and high availability that are well understood and embraced by thousands of Oracle customers.  Active Data Guard is designed to address a different requirement where customers wish to physically isolate the overhead of processing ad-hoc queries and reports from their OLTP system by using a completely independent, synchronized replica of the production database. If the customer requirement can be addressed using read-only access to an up-to-date replica of the production database, then Active Data Guard is an ideal solution.

Why would I use Active Data Guard and not simply use SQL Apply (logical standby) that is included with Data Guard 11g?
If read-only access satisfies the requirement - Active Data Guard is a closer fit for the requirement, and therefore is much easier to implement than any other approach.  Active Data Guard supports all datatypes and is very simple to implement. An Active Data Guard replica can also easily support additional uses - offloading backups from the primary database, serve as an open read-write test system during off-peak hours (Snapshot Standby), and provide an exact copy of the production database for disaster recovery - fully utilizing standby servers, storage and software while in standby role.

With the availability of Active Data Guard, what role does SQL Apply (logical standby) continue to play?
Use SQL Apply for the following requirements: (a) when you require read-write access to a synchronized standby database but do not modify primary data, (b) when you wish to add local tables to the standby database that can also be updated, or (c) when you wish to create additional indexes to optimize read performance.  The ability to handle local writes makes SQL Apply better suited to packaged reporting applications that often require write access to local tables that exist only at the target database. SQL Apply also provides rolling upgrade capability for patchsets and major database releases.  This rolling upgrade functionality can also be used by physical standby databases beginning with Oracle 11g using Transient Logical Standby.

My reporting application makes some temporary writes which require read-write access to the standby database, even though the writes do not modify primary data. How can I use it with Active Data Guard?
Active Data Guard does not support any writes to the physical standby database. That said, it is possible that limited writes needed by the reporting application can be directed back to the primary database or to a local database that is on the same server as the standby database, using Oracle database links.  For further details, refer to the Active Data Guard best practices paper on the MAA OTN site.