以下简称Active Data Guard为ADG，Data Guard为DG。
在以上的7项功能中，DG只能有限的支持Real-Time Query，即指当standby数据库打开时，并不能进行日志的redo apply，这其实是对数据同步有影响的。
另外Far Sync，Global Database Services和Application Continuity是DB 12c支持的功能。
Where ADG offers more is that you can have the database open for read-only (eg reports) whilst it is still being kept in sync with your primary database. With normal DG, if you want it open read-only, you must pause the sync process.
ADG maintains a physical copy of your primary database (that can be read by queries). You are 100% positive that it and the primary are the same.
问：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.
这里说的是，如果standby确实需要写一些数据，可以将写通过DBLink导向primary数据库或本服务器上的其它数据库，如果是12c，还可以使用global temporary table特性写入本库的临时表，不过这个临时表需要再primary DB上创建。
There are also reporting applications that could use a read-only database except for the requirement that they write to global temporary tables and/or access unique sequences. Active Data Guard includes new capabilities with Oracle Database 12c to allow writes to global temp tables and access to unique sequences at an active standby, further expanding the number of reporting applications that can be offloaded from a production database
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 © 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 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.