当然以上只是一张概念图，以下是Apple使用Active Dataguard Reader Farm的一张架构图：
简单地对以上架构图做一些阐述：
1. Primary Database通常还会连接另外一个最大可用性模式的的Standby Database作为DR，以同步的方式应用Primary的变更。一旦Primary Database发生故障就可以切换到Standby Database而不会丢失任何数据。
2. Active Dataguard Reader Farm一般采用异步实时的模式应用日志，防止对Primary Database造成负面影响。在11.2还可以通过Query SLA的来监控和控制。通过V$DATAGUARD_STATS和V$STANDBY_EVENT_HISTOGRAM来监控其延迟，以及通过session级别设置STANDBY_MAX_DATA_DELAY来控制其延迟的行为。
3. 在应用服务器层面进行负载均衡，将多个应用服务器发送过来的请求通过一个硬件的load balancer （例如BigIP F5或者Citrix NetScaler ADC）均衡分布到Active Dataguard Reader Farm的各个节点。
4. 另外注意到有一个细节就是，在Standby Database上还可以级联一个或者多个Active Dataguard作为Reader Farm中的节点。这个主要因为在11.1中，1个Primary Database只能有9个Standby Database的限制导致的。在11.2中不存在这个限制。
这样，应用所有的查询操作就均衡的分布到Active Dataguard Reader Farm节点，但是如果是变更操作应该如何处理呢？通常有两种处理手段： 第一种手段就是在应用层面做严格的区分，使得连接到Active Dataguard Reader Farm节点都是查询操作，连接到Primary Database的都是DML操作，当然这只是一种比较理想的模式。另外一种方式是在应用层面不进行区分，应用不直接连接到Primary Database，而是通过建立从Active Dataguard Reader Farm节点到Primary Database的dblink来做DML。
而如果需要了解Active Dataguard Reader Farm节点本身的负载情况，可以收集statspack或者ASH报告进行分析。
综上，Active Dataguard Reader Farm架构至少存在以下优势：
1. 管理维护简单，DBA只要熟悉Dataguard的管理即可，无需再额外学习其他方面的新知识；
2. Active Dataguard Reader Farm节点是灵活可扩展的，可以在线添加或者删除节点，并且可以线性扩展而不对生产系统造成影响；
3. 可以真正做到实时查询，不会应为大事务造成同步阻塞，性能有保障；
4. 没有数据类型的限制；
5. 高可用性， 节点的宕机都不会影响到数据库的可用性。
但是同时也需要注意：
1. Active Dataguard是11g数据库单独的一个option，需要单独付费的。
2. 无法在Active Dataguard Reader Farm节点单独创建索引进行查询优化。
3. 在所有Active Dataguard Reader Farm节点上sql的执行计划最好保持一致。
以上仅仅只是对Active Dataguard和Active Dataguard Reader Farm做一个简单的介绍，不可能涵盖到所有的方面。稍后我会上传Active Dataguard Best Practices以及如何Active Dataguard 的Hands on Lab到评论中，请自行查阅。