oracle data guard 知识点

http://www.5ienet.com/note/html/dg/dataguard-basic-how-dataguard-work.shtml

 Data Guard 操作安装配置方式

　　做为oracle环境中一项非常重要的特性，oracle提供了多种方式搭建、操作、管理、维护Data Guard配置，比如：

OEM(Oracle Enterprise Manager)
Orcale EM 提供了一个窗口化的管理方式，基本上你只需要点点鼠标就能完全dg的配置管理维护等操作(当然三思仍然坚持一步一步学rman中的观点，在可能的情况下，尽可能不依赖视窗化的功能，所以这种操作方式不做详细介绍)，其实质是调用oracle为dg专门提供的一个管理器：Data Guard Broker来实施管理操作。

Sqlplus 命令行方式
命令行方式的管理，本系列文章中主要采用的方式。不要一听到命令行就被吓倒，data guard的管理命令并不多，你只需要在脑袋瓜里稍微挪出那么一小点地方用来记忆就可以了。

DGMGRL(Data Guard broker 命令行方式)
就是Data Guard Broker，不过是命令行方式的操作。


初始化参数文件
我感觉不能把参数化参数视为一种操作方式，应该说，在这里，通过初始化参数，更多是提供更灵活的Data Guard配置。

• 2、 软件需求
  
  
  Data Guard 是Oracle企业版的一个特性，明白了吧，标准版是不支持地。
  通过Data Guard的SQL应用，可以实现滚动升级服务器数据库版本(要求升级前数据库版本不低于10.1.0.3)。
  同一个Data Guard配置中所有数据库初始化参数：COMPATIBLE的值必须相同。
  Primary 数据库必须运行于归档模式 ，并且务必确保在primary数据库上打开FORCE LOGGING，以避免用户通过nologging等方式避免写redo造成对应的操作无法传输到standby数据库。
  Primary 和standby数据库均可应用于单实例或RAC架构下 ，并且同一个data guard配置可以混合使用逻辑standby和物理standby 。
  Primary 和standby数据库可以在同一台服务器，但需要注意各自的数据文件存放目录，避免重写或覆盖。
  使用具有sysdba系统权限的用户管理primary和standby数据库。
  建议数据库必须采用相同的存储架构。比如存储采用ASM/OMF的话，那不分primarty或是standby也都需要采用ASM/OMF。
  另外还有很重要一点，注意各服务器的时间设置，不要因为时区/时间设置的不一置造成同步上的 问题。
  

一、 Data Guard 配置(Data Guard Configurations)

　　Data Guard 是一个集合，由一个primary数据库(生产数据库)及一个或多个standby数据库(最多9个)组成。组成Data Guard的数据库通过Oracle Net连接，并且有可能分布于不同地域。只要各库之间可以相互通信，它们的物理位置并没有什么限制，至于操作系统就更无所谓了(某些情况下)，只要支持oracle就行了。


　　你即可以通过命令行方式管理primary数据库或standby数据库，也可以通过Data Guard broker提供的专用命令行界面(DGMGRL)，或者通过OEM图形化界面管理。


1. Primary  数据库


前面提到，Data Guard包含一个primary数据库即被大部分应用访问的生产数据库，该库即可以是单实例数据库，也可以是RAC。


2. Standby  数据库


Standby 数据库是primary数据库的复制(事务上一致)。在同一个Data Guard中你可以最多创建9个standby数据库。一旦创建完成，Data Guard通过应用primary数据库的redo自动维护每一个standby数据库。Standby数据库同样即可以是单实例数据库，也可以是RAC结构。关于standby数据库，通常分两类：逻辑standby和物理standby，如何区分，两类各有什么特点，如何搭建，这方面内容就是后面的章节主要介绍的，在这里呢三思先简单白话一下：


逻辑standby
就像你请人帮你素描画像，基本器官是都会有的，这点你放心，但是各器官位置啦大小啦肤色啦就不一定跟你本人一致了。


物理standby
就像拿相机拍照，你长什么样出来的照片就是什么样，眼睛绝对在鼻子上头。或者说就像你去照镜子，里外都是你，哇哈哈。具体到数据库就是不仅文件的物理结构相同，甚至连块在磁盘上的存储位置都是一模一样的(默认情况下)。


为什么会这样呢？这事就得从同步的机制说起了。逻辑standby是通过接收primary数据库的redo log并转换成sql语句，然后在standby数据库上执行SQL语句(SQL Apply)实现同步，物理standby是通过接收并应用primary数据库的redo log以介质恢复的方式(Redo Apply)实现同步。


另外，不知道大家是否注意到形容词上的细节：对于相机拍照而言，有种傻瓜相机功能强大而操作简便，而对于素描，即使是最简单的画法，也需要相当多的练习才能掌握。这个细节是不是也说明逻辑standby相比物理standby需要操作者拥有更多的操作技能呢？


二、 Data Guard 服务(Data Guard Services)


REDO 传输服务(Redo Transport Services)
控制redo数据的传输到一个或多个归档目的地。


Log 应用服务(Log Apply Services)
应用redo数据到standby数据库，以保持与primary数据库的事务一致。redo数据即可以从standby数据库的归档文件读取，也可直接应用standby redo log文件(如果实时应用打开了的话)。


角色转换服务(Role Transitions)
Dg 中只有两种角色：primary和standby。所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：switchover和failover


switchover ：转换primary数据库与standby数据库。switchover可以确保不会丢失数据。


failover ：当primary数据库出现故障并且不能被及时恢复时，会调用failover将一个standby数据库转换为新的primary数据库。在最大保护模式或最高可用性模式下，failover可以保证不会丢失数据。


注：上述各概念简要了解即可，这里写的太简单，不要咬文嚼字，不然你会越看越糊涂，相关服务在后面章节将会有详细介绍，不仅有直白的描述，还会有示例，再加上浅显的图片，就算你一看不懂，再看肯定懂：）
三、 Data Guard 保护模式(Data Guard Protection Modes)


对于Data Guard而言，其生存逻辑非常简单，好好活，做有意义的事，做黑多黑多有意义的事：）


由于它提供了三种数据保护的模式，我们又亲切的叫它：有三模：


最大保护(Maximum protection)：
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby数据库的standby redo log，并确认redo数据至少在一个standby数据库可用(如果有多个的话)，然后才会在primary数据库上提交。如果出现了什么故障导致standby数据库不可用的话，primary数据库会被shutdown。


最高性能(Maximum performance)：
这种模式提供在不影响primary数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前primary数据库的redo数据也需要至少写入一个standby数据库，不过这种写入可以是不同步的。


如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响。


最高可用性(Maximum availability)：
这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障redo数据至少在一个standby数据库可用，不过与之不同的是，如果出现故障导入无法同时写入standby数据库redo log，primary数据库并不会shutdown，而是自动转为最高性能模式，等standby数据库恢复正常之后，它又会再自动转换成最高可用性模式。


最大保护及最高可用性需要至少一个standby数据库redo数据被同步写入。三种模式都需要指定LOG_ARCHIVE_DEST_n初始化参数。LOG_ARCHIVE_DEST_n很重要，你看着很眼熟是吧，我保证，如果你完完整整学完dataguard，你会对它更熟。


四、 Data Guard 优点总结


灾难恢复及高可用性
全面的数据保护
有效利用系统资源
在高可用及高性能之间更加灵活的平衡机制
故障自动检查及解决方案
集中的易用的管理模式
自动化的角色转换