前言
DG的配置过程,参考了如下两篇文章:
http://www.cnblogs.com/tippoint/archive/2013/04/18/3029019.html
主库IP:10.211.55.6
备库IP:10.211.55.7
安装之前使用如下命令同步主备库的时间
|
|
配置
判断DG是否已安装
|
|
如果是true表示已经安装可以配置,否则需要安装相应组件。
设置主库为强制记录日志
默认情况下数据库操作会记录redo log,但是在一些特定的情况下可以使用nologging来不生成redo信息
- 表的批量INSERT(通过/+APPEND /提示使用“直接路径插入“。或采用SQL*Loader直接路径加载)。表数据不生成redo,但是
所有索引修改会生成redo,但是所有索引修改会生成redo(尽管表不生成日志,但这个表上的索引却会生成redo!)。
- LOB操作(对大对象的更新不必生成日志)。
- 通过CREATE TABLE AS SELECT创建表
- 各种ALTER TABLE操作,如MOVE和SPLIT
- 在一些表迁移和表空间迁移中,可以使用alter table a nologging;或者alter tablespace snk nologging;在操作完成后再修改回logging状态。
这里需要多说一句,如果你使用nologging导入大批量数据,以后对这些数据的修改会在redo或者archive log中,但是基准的数据是没有的,所以一旦介质损坏是无法完全恢复的,必须在使用nologging完成切换回logging后,做一次全备或者0级备份。
强制记录日志
|
|
检查状态(YES为强制)
|
|
如果需要在主库添加或者删除数据文件时,这些文件也会在备份添加或删除,使用如下
|
|
创建standby log files
从库使用standby log files来保存从主库接收到的重做日志。既然主要是从库在使用,那为什么需要在主库上也建立standby log files ? 原因主要由两个:一是主库可能转换为备库,而备库是需要有standby log files的 二是如果主库建立了standby log files那备库会自动建立。
创建standby log files需要注意两点:
- standby log files的大小和redo log files一样
- 一般而言, standbyredo 日志文件组数要比 primary 数据库的 online redo 日志文件组数至少多一个。推荐 standbyredo 日志组数量基于 primary 数据库的线程数(这里的线程数可以理解为 rac 结构中的 rac节点数)。有一个推荐的公式可以做参考:(每线程的日志组数+1)最大线程数
假设现在节点是1个,则=(3+1)1=4
如果是双节点 则=(3+1)*2=8
这里我们创建4个standby logfile:
查询redo日志大小
|
|
这里是100M,三个
创建
不建议组号group#紧挨着redo,因为后续redo有可能调整,这里我们从建立从11到14的standby logfile
|
|
创建密码文件并传输给备库
一般数据库默认就有密码文件,存放在$ORACLE_HOME/dbs/orapwSID 这里为orapwsrmcloud
如果没有
|
|
检查REMOTE_LOGIN_PASSWORDFILE值是否为 EXCLUSIVE:
|
|
如果值不是EXCLUSIVE,则:
|
|
如果存在或者创建完成,将密码文件传输到standby 库的对应目录,并授权
处理控制文件
查看控制文件位置
|
|
生成standby控制文件
|
|
然后在备库建立对应的目录,并授权
|
|
拷贝主库的控制文件到备库
db_name和db_unique_name
默认db_name和db_unique_name和实例名是一致的,这里是srmcloud。需要注意在DG中主库和从库的db_unique_name是不能一致的,需要区分开的。这里我们设置主库的db_unique_name为srmcloud,从库为srmclouddg。
查看db_unique_name
|
|
设置db_unique_name
|
|
注意虽然默认db_unique_name和db_name是一致的,但是需要显式设置,否则在spfile中没有此参数
闪回
略
SQL*NET设置
配置主库监听(listener.ora)
虽然可以通过netca来进行配置,但是除了这个默认的外,我们还需要一个静态注册SID_LIST_LISTENER,如果没有此从参数,而且dataguard启动顺序不正确,主库会报PING[ARC1]:Heartbeat failed to connect to standby ‘*‘.Error is 12514导致归档无法完成
配置如下:
|
|
配置tns
配置如下:
|
|
传输到备库并修改listener.ora
如下:
|
|
日志传输配置
查看是否启用归档
|
|
启用归档并设置归档日志路径
|
|
配置归档日志到备份库
|
|
要注意STANDBY_ARCHIVE_DEST 参数不需要,已经被官方弃用。设置此参数后启动数据库,只会报 ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance 错。
配置FAL_SERVER
这个参数指定当日志传输出现问题时,备库到哪里去找缺少的归档日志。它用在备库接收的到的重做日志间有缺口的时候。这种情况会发生在日志传输出现中断时,比如你需要对备库进行维护操作。在备库维护期间,没有日志传输过来,这时缺口就出现了。设置了这个参数,备库就会主动去寻找那些缺少的日志,并要求主库进行传输。
你是主库,就填写:fal_server=从库
从库上就反过来:fal_server=主库
注意:FAL_CLIENT在11g中已经废弃,虽然可以配置但是已经不起作用了
|
|
Data Guard 配置里的另外一个库的名字
|
|
|
|
手工修改pfile,如下:
|
|
|
|
传输pfile到备库并修改
只需修改如下项即可:
|
|
建立相关目录
|
|
|
|
使用pfile启动备库到nomount
|
|
注意:要启动备库监听
Duplicate复制主库到备库
|
|
关闭,并使用pfile重启数据库,并创建spfile
|
|
关闭数据库,使用spfile重启数据库
|
|
查看日志
|
|
已接收,但未应用
开启备库日志应用
|
|
验证
数据传输验证
在主库创建用户
|
|
在备库查询TEST用户是否存在
|
|
dg数据传输正常
主备切换验证
#####主库切换为备库
|
|
备库切换为主库
|
|
启动原主库(现在为备库)为read only模式,并启用日志自动应用
|
|
至此,DG配置完成
管理
dataguard启动关闭顺序
监听
先启从库再起主库
|
|
启动
先起从库
|
|
再启主库
|
|
关闭(和开启正好相反)
先关主库:
|
|
再关从库:
|
|
后续
介绍一篇dg文章,写的比我好