TTA — when you believe

Cascaded Destinations/Cascaded Standby Databases

      Cascaded Destinations，简单的讲，就是为了避免主库的压力和干扰，将主库产生的redo通过一个standby传送到另外一个standby上，而不是直接通过primary到另外一个standby。在Oracle各版本的在线文档上，对此界定也并不一致。比如这样一个组合方式：Primary Database > Logical Standby Database  > Physical Standby Database，因为最后一层的standby并不和第一层的priamry database有直接关系，1-2和2-3分别自成体系，这并不是一个真正意义上的Cascaded Destination。但在10g和9i在线文档中，依然将这种模式列为cascaded destinations，而在11g中已经将这种情形排除。严格意义上的cascaded destination 支持如下组合场景：

1. Primary Database > Physical Standby Database with cascaded destination > Physical Standby Database
2. Primary Database > Physical Standby Database with cascaded destination > Logical Standby Database

     Cascaded Destinations的用处还是比较多的，例如使用dataguard做远程容灾的场景，使用Cascaded Destinations就远比local primary和romote standby直接做dataguard可靠。基于WAN上的dataguard的一个致命问题就是主备端的网络质量问题，这将对主端产生严重的影响，尽管可以通过async的方式来进行redo或者archive的传送，但在一个繁忙的系统中，这仍然是个极大的性能和稳定性隐患。通过Cascaded Destinations，redo/archive log的同步放到了local physical standby端上进行，主库产生的日志先传送到local standby，然后由local standby负责传送日志到remote standby。

 

       对于10g版本以上的该模型，通过日志传输参数VALID_FOR的功能，通过角色控制priamry/standby向remote database的日志传送，这样日常中local dataguard的switchover并不影响remote standby的同步且操作上更加平滑，另外，remote standby端配合Flashback Database，这样也避免了因为WAN上带宽有限，local database的Failover造成的remote standby的重建带来的数据传输问题。

       需要特别提出的是cascaded standby databases中的FAL的配置问题，正常情况下最后一级standby的日志是从上级standby上取得，并非直接从primary上传输，但特别情况下可直接由Primary向最后一级standby传送。如果最后一级standby的fal_server配置对应primary database和上级standby database，那么可能出现这么一种情况需要注意：上级standby database的对应的归档日志已经apply但已经不存在(比如被删除)，因为下级 standby database存在一系列问题，恢复进度并没有赶上日志的传送速度，当正好需要上级standby上这部分log的时候，发现从上级standby上已经无法获得，这时候通过fal_server的配置可直接从primary向最后一级standby上传输，而不需要中转。

      Metalink doc上也相关记录如下：

If primary receives a FAL request from the remote standby in the above case then It ships the archive logs directly to the remote standby without going via cascaded standby.