10G Data guard配置总结

ORACLE Data guard 分为物理Standby和逻辑Standby两种类型，我做的是10G的物理Standby，在10G中，ORACLE还不支持实时的日志应用，在应用日志时不能提供查询，在查询状态，必须停止应用日志，据说11G中已经可以做到应用日志的同时提供查询。

下面是我多次做10G的物理Standby的一个总结，有些众所周知的细节就省略了，只提供我总结的一些技巧和遇到的一些问题的处理办法。我的生产库主机是HP 11.23的系统，是10G的RAC，Standby库是单实例，也是HP 11.23的系统，在物理Standby中生产库和Standby库系统平台版本必须一致。

1、库名和实例名的配置

生产库为10G RAC双实例, Standby库为单实例。Standby库的库名必须和生产库一致，但实例名可以不一致，如：我的生产库为ORCL,实例为ORCL1和ORCL2，而我的Standby库库名为ORCL，实例名为DGLAB。

2、网络配置

　在Standby库主机上安装好ORACLE SOFTWARE,不建库，在做Date Guard之前，先把Standby库和生产库之间的网络配置好会对以后的操作带来很大的便利。Standby库服务名：dbstabdby,生产库服务名dbprimary，配置好以后，启动Standby库的监听,从Standby库和生产库两端分别进行检测tnsping dbprimary, tnsping dbstandby，通讯正常以后，这时一旦Standby库启动到 mount状态后，后台的相关的归档进程就会开始工作，生产库新产生的归档日志就会同步传送到Standby库主机上，以后在做完Standby库的数据恢复以后，就直接应用日志就可以了，不用做上传生产库归档日志的操作了，带来了很大的便利。

3、在生产库上做数据库备份

  　把rman备份出来的数据文件放在/backup上，并用nfs把/backup共享出来，在Standby库主机上把生产库的这个/backup目录也mount在/backup上。这样在生产库上把库备份出来以后，在Standby库直接使用它来恢复就行了，很方便，唯一的弊端就是速度可能会受到影响，会受网络传输影响，恢复速度慢一些，花的时间长一些。在做备份时记得要在备份脚本里加一句alter system  switch  logfile，否侧可能以后会出问题。Crosscheck  archivelog all这个可以不做。

备份脚本：

connect target /;

run {

allocate channel t1 type disk;

allocate channel t2 type disk;

allocate channel t3 type disk;

allocate channel t4 type disk;

backup full filesperset 6

format '/backup/db_%d_%U/'

(database);

sql 'alter system switch logfile';

release channel t1;

release channel t2;

release channel t3;

release channel t4;

}

备份放在后台进行

在生产库上做备份放在后台进行，这样在备份期间就可以去做别的工作，备份完成情况到时看一下输出的日志文件就可以了。

nohup rman cmdfile '/home/oracle/dgrman.sh' > /home/oracle/rmanjob.out 2>&1 &

监控备份完成的进度

tail  -f  /home/oracle/rmanjob.out

4、Standby库恢复

在生产库上备出控制文件

Sql> alter  database  create  controlfile  as  ‘/backup/ctrl09526.stb’;

在生产库上备出参数文件

Sql>create pfile=’/backup/init.ora’ from spfile;

修改参数文件

dglab.__db_cache_size=2818572288

dglab.__java_pool_size=16777216

dglab.__large_pool_size=16777216

dglab.__shared_pool_size=704643072

dglab.__streams_pool_size=0

*.db_name='orcl'

*.fal_client='DBSTANDBY'

*.fal_server='DBPRIMARY'

*.LOG_ARCHIVE_DEST_1='LOCATION=/oralog/dglab MANDATORY'

*.remote_login_passwordfile='exclusive'

*.standby_archive_dest='/oralog/dglab’

*.standby_file_management='AUTO'

在Standby库上恢复控制文件

rman  target  /;

startup  nomount;

restore controlfile from ‘/backup/ctrl09526.stb’;

alter database  mount;

在Standby库上生成spfile文件

Create spfile from pfile=/backup/init.ora’;

库恢复脚本dgrman.sh如下：

connect target  /

run{

allocate channel t1 type DISK;

allocate channel t2 type DISK;

allocate channel t3 type DISK;

allocate channel t4 type DISK;

allocate channel t5 type DISK;

allocate channel t6 type DISK;

restore database;

release channel t1;

release channel t2;

release channel t3;

release channel t4;

release channel t5;

release channel t6;

}

Standby库上做恢复放在后台进行，这样在恢复期间就可以去做别的工作，恢复完成情况到时看一下输出的日志文件就可以了。

nohup rman cmdfile '/home/oracle/dgrman.sh' > /home/oracle/rmanjob.out 2>&1 &

监控备份完成的进度

tail  -f  /home/oracle/rmanjob.out

5、Standby库恢复完的处理

　　在Standby库上使用rman做完restore database恢复以后，有时直接open会报错，有时在rman下执行recover database来应用日志也会报错，经过多次data guard的配置实践，不管是直接open会报错还是recover database报错，都不用管它，直接把库切换到应用日志模式，应用上几个日志以后在open就一切正常。现在我的做法是在Standby库上使用rman做完restore database恢复以后，直接切换到应用日志模式，通常都不会有什么问题，而不做recover database操作。切换到应用日志模式以后，Standby库开始应用日志，应用日志是从生产库备份时执行alter system  switch  logfile产生的归档日志之后的那个日志开始应用。因为之前的数据都已经在数据文件里了。

6、Standby库恢复完后需要重建临时表空间

在Standby库上使用rman做完restore database恢复，应用完日志切换到open以后一旦执行查询，告警日志里就会出现如下错误代码

ORA-01186: file 201 failed verification tests

ORA-01122: database file 201 failed verification check

ORA-01110: data file 201: '/dev/vg_oracle/rlv_rac_temp'

ORA-01210: data file header is media corrupt

File 201 not verified due to error ORA-01122

Wed Aug 27 09:00:22 2008

Errors in file /home/oracle/admin/dglab/bdump/dglab_dbw0_29479.trc:

执行select  * from tab这样的操作，能执行成功，做其它查询也能成功,但有时检索查询会无法正常执行，这时查询临时表空间数据文件字典视图会无法查询,select * from dba_temp_files出错，报找不到文件;需要对临时表空间的数据文件删除后重建。

使用如下命令删除：

alter   database   tempfile   '/dev/vg_oracle/rlv_rac_temp'   drop

使用如下命令重建：

alter tablespace temp add tempfile '/dev/vg_oracle/temp' size 9999M;

要对所有的临时表空间和所有的临时数据文件都做这样的操作。

7、关于Standby库的维护操作

启动Redo应用：

　　SQL>startup  mount;

SQL>alter database recover managed standby database disconnect from session;

切换到open状态供查询

　　关闭Redo应用：

SQL> alter database recover managed standby database cancel;

SQL>alter  database  open read only;

在备用数据库上，查看是否已经接受到归档日志：

select sequence#, first_time, next_time from v$archived_log order by sequence#;

在备用数据库上，查看归档日志是否被应用：

select sequence#,applied from v$archived_log关闭库再重启 order by sequence#;

　　在open查询模式切换回应用日志模式时，直接执行应用日志的命令即可，不用关闭库再重启，这点我开始有点误解，每次切换回应用日志模式时，我都先关闭库再重启到mount状态。后来才发现不必关库。

其实查看归档日志的应用情况的一种比较好的方式是看alert告警日志，从告警日志里可以看到归档日志当前应用到哪一条，最后接收到哪一条，从生产库上对比归档日志的目录就可以知道Standby库应用归档日志到什么时间点。

tail -f alert*

告警日志里应用日志信息如下：
Media Recovery Log /oralog/dglab/1_2188_643661217.dbf
Wed Feb 11 23:03:05 2009
告警日志里接收归档日志信息如下：
RFS[2]: Archived Log: '/oralog/dglab/1_2891_643661217.dbf'
Mon May 18 14:10:55 2009
RFS[1]: Archived Log: '/oralog/dglab/2_2913_643661217.dbf'
Mon May 18 14:42:34 2009
告警日志里应用日志信息如下：
Media Recovery Log /oralog/dglab/1_2188_643661217.dbf
Wed Feb 11 23:03:05 2009
告警日志里接收归档日志信息如下：
RFS[2]: Archived Log: '/oralog/dglab/1_2891_643661217.dbf'
Mon May 18 14:10:55 2009
RFS[1]: Archived Log: '/oralog/dglab/2_2913_643661217.dbf'
Mon May 18 14:42:34 2009

 

8、关于data guard的归档日志同步

在Standby库因为主机关闭、或网络通信问题、或Standby库监听服务被关闭等等原因而导致生产库和Standby库不能通讯，归档日志没有同步的情况下，一旦生产库和Standby库通讯恢复正常，生产库就会接着从中断时未传的归档日志开始一个不少的把后面产生的归档日志全部传送到Standby库主机。因为电源的原因，我曾经把Standby库主机关了三天，再重启Standby库后，我本来以后要手动去传那三天的归档日志到Standby库上，登陆上去才发现不用我传，Standby库自动开始接收中断的那三天的日志。

9、BUG问题

在Standby库的告警日志里会产生很多下面这样的警告信息，据查是个BUG，在11G中被修复。

ksvcreate: Process(m000) creation failed

Mon Oct  6 22:50:20 2008

ksvcreate: Process(m000) creation failed

Mon Oct  6 22:51:23 2008

ksvcreate: Process(m000) creation failed

Mon Oct  6 22:52:26 2008

ksvcreate: Process(m000) creation failed

Mon Oct  6 22:53:29 2008

ksvcreate: Process(m000) creation failed

Mon Oct  6 22:54:32 2008

ksvcreate: Process(m000) creation failed

Mon Oct  6 22:55:35 2008