一台linux下oracle DG搭建,
standby:
物理Standby ・・・・・ 与primary 库结构一模一样,提供灾备,减少IO/CPU 占用 (灾难恢复高可用性)
逻辑standby ・・・・・ 与primary 库结构不同(可以创建除primary库存在的索引..) (灾难恢复高可用性/业务需求#ddl/dml)
物理standby 特点
灾难恢复及高可用性:物理standby 提供了一个健全而且极高效的灾难恢复及高可用性的解决方案。更加易于管理的switchover/failover 角色转换及最更短的计划内或计划外停机时间。
数据保护:应用物理standby 数据库,Dg 能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理standby 是基于块对块的复制,因此对象、语句统统无关,primary 数据库上有什么,物理standby 也会有什么。
分担primary 数据库压力:通过将一些备份任务、仅查询的需求转移到物理standby,可以有效节省primary 数据库的cpu以及i/o 资源。
提升性能:物理standby 所使用的redo 应用技术使用最底层的恢复机制,这种机制能够绕过sql 级代码层,因此效率最高。
逻辑standby 的特点:
除了上述物理standby 中提到的类似灾难恢复,高可用性及数据保护等之外,还有下列一些特点:
有效的利用standby 的硬件资源:
除灾难恢复外,逻辑standby 数据库还可用于其它业务需求。比如通过在standby 数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要。又比如创建新的schema(primary 数据库并不存在)然后在这些schema 中执行ddl 或者dml 操作等。
分担primary 数据库压力:
逻辑standby 数据库可以在更新表的时候仍然保持打开状态,此时这些表可同时用于只读访问。这使得逻辑standby 数据库能够同时用于数据保护和报表操作,从而将主数据库从那些报表和查询任务中解脱出来,节约宝贵的CPU 和I/O 资源。
平滑升级:
比如跨版本升级啦,打小补丁啦等等,应该说应用的空间很大,而带来的风险却很小(前提是如果你拥有足够的技术实力。另外虽然物理standby 也能够实现一些升级操作,但如果跨平台的话恐怕就力不从心,所以此项就不做为物理standby 的特点列出了),我个人认为这是一种值的推荐
的在线的滚动的平滑的升级方式
Data Guard保护模式(Data Guard ProtectionModes)
1.最大保护模式:
1).这种模式提供了最高级别的数据保护能力
2).重做日志在至少一个物理从库数据库后,主库的事务才能够提交
3).主库找不到合适的从库写入时,主库会自动关闭,防止无保护的数据出现
4).优点:该模式可以保证从库没有数据丢失
5).缺点:主库的自动关闭会影响到主库的可用性,同时需要从库恢复后才能提交,对网络等客观条件要求非常的高,主库的性能会受到非常大的影响。
2.最大可用性模式:
1).这种模式提供了仅次于“最大保护模式”的数据保护能力