DataGuard搭建过程中的一些总结

DataGuard搭建过程中的一些总结

Oracle Data Guard从宏观上来说，主要提供以下两个服务：
1）日志传输：主库把生成的Redo日志传输至备库；
2）日志应用：备库应用从主库传输过来的Redo日志。
*关于DG的知识，这里我就不多讲了，很多大神都已经做过细致的说明了。我觉得这篇博客就讲的很不错，可以看看：
参考博客http://blog.csdn.net/dbanote/article/details/9091357

下面我主要讲我在搭建DG过程中的一些心得与记录，主要有以下8点：

1. 搭建DG时的前期准备
2. 前期环境确认
3. 配置主库和备库的tnsnames.ora
4. 对主库进行配置
5. 对备库进行配置
6. 数据库复制，将主库复制到备库
7. 启动备库
8. DG搭建完之后可以尝试的一些事

---

#######以下就是搭建DG的过程了：###############################

1 搭建DG时的前期准备

• 目标数据库，可以正常使用且能正常访问的。充当主库
• 与主库数据库版本一致，装有同样实例的数据库，两者的数据库目录一致。可以正常使用且能正常访问的。充当备库

我的主库：192.168.198.10 SID=orcl db_unique_name=orcl 数据库版本： Oracle 11g
我的备库：192.168.198.20 SID=orcl db_unique_name=standby 数据库版本： Oracle 11g

2 前期环境确认

首先对主库进行一系列环境的检查与配置：
1.判断主库的DG是否已经安装：
SQL>select * from v$option where parameter = ‘Oracle Data Guard’;
如果是true表示已经安装可以配置，否则需要安装相应组件。不过一般Oracle默认都是安装了的

2.判断主库是否已经为归档模式：
SQL>archive log list;
如果是，就继续下一步，如果不是，得开启归档模式：

SQL>shutdown immediate;
SQL>startup mount;
SQL>alter database archivelog;
SQL>alter database open;

3.判断主库为强制记录日志：

SQL>select name,force_logging from v$database;
SQL>alter database force logging;

根据sql命令，确认环境是否正常 ：select name,log_mode,force_logging from v$database;

3 配置主库和备库的tnsnames.ora

主库和备库的tnsnames.ora是一样的，这是例子：

STANDBY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST =standby)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

ORCL =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST =orcl)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

其中的HOST得在 /etc/hosts中去配置。

配置完之后，检查配置是否生效：可以使用tnsping orcl 命令尝试tnsnames.ora是否配置成功。

4 对主库进行配置

配置DG有很多种方式：有alter system set …….，也可以修改pfile，也可以通过OEM图形化界面来配置等等，此处我图方便，就采用了通过修改pfile来配置DG（此种方式的参考博客http://blog.csdn.net/wuweilong/article/details/46549415）。如果你是生产库上搭建DG，最好采用alter system set……这种方式修改参数（此种方式的参考博客http://blog.csdn.net/dbanote/article/details/9090517），一个可以避免主库反复重启，另一个还可以及时验证参数是否配置正确了。
1) 创建standby log files(备用日志文件）
建立standby如要注意以下几点：

• standby log files的大小和redo log files一样。查询redo log files文件大小（默认50M,3个）：SQL>select group#,bytes/1024/1024 as M from v$log
• 一般而言， standbyredo 日志文件组数要比 primary 数据库的 online redo 日志文件组数至少多一个。

有一个推荐的公式可以做参考：(每线程的日志组数+1)*最大线程数
假设现在节点是1个，则=(3+1)*1=4
如果是双节点 则=(3+1)*2=8
这里我们创建4个standby logfile:
另：不建议组号group#紧挨着redo，因为后续redo有可能调整，这里我们从建立从11到14的standby logfile：

SQL>alter database add standby logfile group  11 '/db/oracle/oradata/orcl/standbylog/ standby11.log' size 50M;
SQL>alter database add standby logfile group  12 '/db/oracle/oradata/orcl/standbylog/ standby12.log' size 50M;
SQL>alter database add standby logfile group  13 '/db/oracle/oradata/orcl/standbylog/ standby13.log' size 50M;
SQL>alter database add standby logfile group  14 '/db/oracle/oradata/orcl/standbylog/ standby14.log' size 50M;

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG; 来查看standbylog的添加情况。

2) 创建密码文件（密码文件是创建DG不可缺少的一部分）
orapwd file=/db/oracle/product/11.2.0/db_1/dbs/orapworcl password=manager force=y
这里的密码为SYS用户的密码
通过v$pwfile_users再次确认sys用户在密码文件中：

SQL>select * from v$pwfile_users;

确认参数remote_login_passwordfile为EXCLUSIVE（默认值）：
如果不是，则执行：SQL>alter system set remote_login_passwordfile=exclusive;

3) 设置主库的日志传输和应用

SQL>create pfile from spfile;

修改 /db/oracle/product/11.2.0/db_1/dbs/initorcl.ora 文件。
增加以下部分：

*.db_unique_name='orcl'
*.log_archive_config='DG_CONFIG=(orcl,standby)'
*.log_archive_dest_1='LOCATION=/db/oracle/flash_recovery_area/ORCL/archivelog/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl'
*.log_archive_dest_2='SERVICE=standby LGWR ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) COMPRESSION=ENABLE DB_UNIQUE_NAME=standby'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='DEFER'
*.fal_client='orcl'
*.fal_server='standby'
*.standby_file_management='AUTO'

验证一下是否配置成功，
SQL>shutdown immediate;
SQL> startup pfile=/db/oracle/product/11.2.0/db_1/dbs/initorcl.ora
如果没有报错，那就是配置成功了。

然后将更改应用到spfile中：
SQL>shutdown immediate;
SQL>create spfile from pfile;
SQL> startup

5 对备库进行配置

1) 复制主库的密码文件：
scp /db/oracle/product/11.2.0/db_1/dbs/orapworcloracle@standby:/db/oracle/product/11.2.0/db_1/dbs/

2) 设置备库的日志应用和作为主库时的日志传输：
SQL>create pfile from spfile;
修改 /db/oracle/product/11.2.0/db_1/dbs/initorcl.ora 文件。
增加以下部分：

*.db_unique_name='standby'
*.log_archive_config='DG_CONFIG=(orcl,standby)'
*.log_archive_dest_1='LOCATION=/db/oracle/flash_recovery_area/ORCL/archivelog/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME= standby '
*.log_archive_dest_2='SERVICE=orcl LGWR ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) COMPRESSION=ENABLE DB_UNIQUE_NAME=orcl'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.fal_client='standby'
*.fal_server='orcl'
*.standby_file_management='AUTO'

尝试一下是否配置成功，
SQL>shutdown immediate;
SQL> startup pfile=/db/oracle/product/11.2.0/db_1/dbs/initorcl.ora
如果没有报错，那就是配置成功了。

然后将更改应用到spfile中：
SQL>shutdown immediate;
SQL>create spfile from pfile;
SQL> startup

6 数据库复制，将主库复制到备库

执行库的复制之前，需要开启备库到nomount状态。
SQL>shutdown immediate;
SQL>startup nomount;

在主库上利用RMAN进行库的复制：
rman target sys/manager@orcl auxiliary sys/manager@standby nocatalog
登录进去RMAN后，再执行：
duplicate target database for standby from active database nofilenamecheck;
执行这一步后，我发现standby.log没有拷贝过来，导致DG启动后，主备库数据只有当主库执行alter system switch logfile 备库数据才能同步，找了半天，我以为是我DG配置错了，最后一看备库的alert.log，才发现，file not exist 错误;囧。。。最后还是手动将 /db/oracle/oradata/orcl/standbylog/*.log 拷贝过去。才解决主备库数据老是不同步的问题。

---

创建备库的方式有很多，其原理都基本相同，就是把主库的数据文件和归档文件复制到备库，然后作为standby来启动。
试了好几种方式，最终发现还是此种方法比较方便。建完备库后，此种方式并不能为备库创建standby controlfile，得我们手动去添加：

1. 在主库上手动生成备库controlfile文件：
   SQL>alter database create standby controlfile as '/db/standby_control01.ctl';
2. 先关闭备库：SQL>shutdown immediate
3. scp /db/standby_control01.ctl oracle@standby:/db/oracle/oradata/orcl/control01.ctl
4. scp /db/standby_control01.ctl oracle@standby:/db/oracle/flash_recovery_area/orcl/control02.ctl

同时你会发现在你的/db/oracle/flash_recovery_area/目录下有一个 STANDBY目录，这个是因为采取RMAN duplicate 生成备库时，创建的log目录，创建完备库的standby controlfile后，可以删掉它。

7 启动备库

备库启动之前一定要做recover，也就是开启MRP服务，不然无法启动成功。这个是我在多次尝试，练就了一头铁头功之后，终于弄明白了的一件事：
alter database recover managed standby database disconnect from session;是用来开启MRP的，同时你这么干，意味着你的备库得处于mount状态的，
那有人肯定会反对：我执行完这个之后，我再执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; （这句其实就是关闭了MRP）,再 alter database open不行啊。小伙子，不能倔，知道不：你这样是可以打开数据库了，但是你还是得执行recover managed standby database using current logfile disconnect from session; 来开启MRP服务，同时整个DG变成ADG了。这样备库才能正常同步主库的数据。
所以备库建立完之后，有2种开启方式：
启动备库：
1. SQL>shutdown immediate;
2. SQL>startup nomount;
3. SQL>alter database mount standby database;
4. SQL>alter database recover managed standby database disconnect from session;
或者：
1. SQL>shutdown immediate;
2. SQL>startup nomount;
3. SQL>alter database mount standby database;
4. SQL>alter database open read only;
5. SQL>recover managed standby database using current logfile disconnect from session;

好了，到此DG就搭建完了。
可以通过sql命令查看DG的状态：
比如查看主备之间日志传输正常否：
SELECT DESTINATION,STATUS,ARCHIVED_THREAD#,ARCHIVED_SEQ#
FROM V$ARCHIVE_DEST_STATUS WHERE STATUS <> ‘DEFERRED’ AND STATUS <> ‘INACTIVE’;

——————————————————-备库监控————————————–
（1）备库：查看进程状态
SELECT PROCESS,CLIENT_PROCESS,SEQUENCE#,STATUS FROM V$MANAGED_STANDBY;

查询结果说明：
CLIENT_PROCESS 对应 Primary 数据库中的进程如 ARCH\LGWR等
SEQUENCE#：归档序号
STATUS 当前进程状态：
CONNECTED :已连接至 PRIMARY 数据库
ALLOCATED: 正在准备连接PRIMARY数据库
ATTACHED:正在连接PRIMARY数据库
IDLE：空闲中
RECEIVING:正在接收归档文件
OPENNING ：正在处理归档文件
CLOSING: 归档文件已处理完，收尾中
WRITING: 正在向归档文件中写入redo数据
WAIT_FOR_LOG ：正在等待新的REDO数据
WAIT_FOR_GAP：归档发生中断，正在等待新的REDO 数据
APPLYING_LOG：正在应用REDO数据

（2）查看REDO应用进度
SELECT DEST_NAME,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#,DB_UNIQUE_NAME,STATUS FROM V$ARCHIVE_DEST_STATUS WHERE STATUS=’VALID’；

（3） 查看归档文件的路径及创建信息
SELECT NAME,CREATOR,THREAD#,SEQUENCE#,APPLIED,ARCHIVED,COMPLETION_TIME FROM V$ARCHIVED_LOG;

（4） 查看归档历史
SELECT FIRST_TIME,FIRST_CHANGE#,NEXT_CHANGE#,SEQUENCE# FROM V$LOG_HISTORY;

（5） 查看物理STANDBY数据库未接收的日志文件
SELECT LOCAL.THREAD#,LOCAL.SEQUENCE# FROM
(SELECT THREAD#,SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL
WHERE LOCAL.SEQUENCE# NOT IN
(SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND THREAD# = LOCAL.THREAD#);
—-从primary 数据库获取

（6） 查询当前数据的基本信息（V$DATABASE) 数据库角色、保护模式、保护级别

SELECT DATABASE_ROLE,DB_UNIQUE_NAME,OPEN_MODE,PROTECTION_MODE,PROTECTION_LEVEL,SWITCHOVER_STATUS FROM V$DATABASE;

（7）查询failover后快速启动的信息：

SELECT FS_FAILOVER_STATUS,FS_FAILOVER_CURRENT_TARGET,FS_FAILOVER_THRESHOLD,FS_FAILOVER_OBSERVER_PRESENT FROM V$DATABASE;

（8） 查询REDO应用和REDO传输服务的活动状态
SELECT PROCESS,STATUS,THREAD#,SEQUENCE#,BLOCK#,BLOCKS FROM V$MANAGED_STANDBY;

（9） 查看REDO应用模式（物理STANDBY数据库）
SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
—–如果开启了实时应用，此处显示的状态应该为 MANAGED REAL TIME APPLY

8 DG搭建完之后可以尝试的一些事

主备库的切换主要在两种情况下切换，Switchover和Failover ，这两种切换都需要手工执行完成。
一是Switchover（计划中的切换，不会丢失数据）
二是Failover（当主库出现故障的时候需要主备库切换角色）

1)Switchover的切换方法
主库端：
select switchover_status from v$database;
如果是to standby 表可以正常切换.
直接执行 alter database commit to switchover to physical standby;
否则执行:alter database commit to switchover to physical standby with session shutdown;
shutdown immediate;
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;

备库端：
select switchover_status from v$database;
如果是to_primary 表可以正常切换.
执行: alter database commit to switchover to primary;
否则执行: alter database commit to switchover to primary with session shutdown;
shutdown immediate;
startup;

2)Failover切换方法
(1) 判断主数据库确实出现严重的硬件故障或其他原因导致主数据库无法启动。
(2) 在物理备用数据库上检查是否有archive redo log gaps
SQL>SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
(3) 消除archive redo log gaps
从主数据库上或其他备份的地方把没有传到物理备用数据库的archive redo log传到物理备用数据库上，并注册到物理备用数据库的controlfile中。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE ‘archive redo log文件名称’;
重复2,3步骤直到V$ARCHIVE_GAP 视图无记录存在。

详细步骤：
1）从主库刷新未发送的日志至备库
如果主库还可以mount，我们就有可能把未发送的日志刷新至备库，这样就不会导致数据丢失。
当主库mount之后，执行如下语句：
SQL> ALTER SYSTEM FLUSH REDO TO standby_db_unique_name;
如果上述语句成功执行，说明已把所有的日志发送至备库，可以直接跳到第5步，否则从第2步开始。

2）确认备库拥有最新的归档日志
查询备库归档日志的最高序号：
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

手动把缺失的归档日志拷贝至备库，并在备库中注册：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

3）解决归档日志GAP
查询v$archive_gap视图就能知道是否有GAP
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

上例表示备库缺失90,91,92归档日志，手动把它们从主库拷贝过来并在备库注册：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE ‘filespec1’;

4）重复第2、3步，直至没有GAP为止，否则会有数据丢失

5）备库停止日志应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

(4）在物理备用数据库上发起failover操作
SQL > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;

(5) 把物理备用数据库转化成主用角色
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

(6) 把新的主用数据库重新启动
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;

(7) 对新的主用数据库做全备份.

---

这就是我本次的记录，如果有什么地方讲错了，请大伙儿见谅啊，欢迎补充指正。thanks~_~