service:远程备库网络服务名 lgwr或者arch: lgwr或者arch进程传输主库的redo数据 sync或者async:同步或者异步传输 affirm与noaffirm: affirm表示只有当日志写入standby重做日志后才算日志传输成功,noaffirm则没有这个要求; reopen:主数据库重新连接备库的时间 net_timeout:当采用sync传输模式时,超过多少秒则表示网路超时(默认为30s),建议设置改参数; valid_for:定义使用log_archive_dest_n参数归档,控制主备库是否可以归档在线日志文件或者归档备用日志文件,有如下子参数: online_logfile:仅归档联机日志文件 standby_logfile:归档备用日志文件 all_logfiles:归档所有日志文件 primary_role:在主角色起作用 standby_role:在备角色起作用 all_roles:在所有角色起作用 compression:传送中进行压缩, delay:在备库延迟应用redo的时间(秒/单位) |
比较项 |
最大保护 |
最高可用 |
最大性能 |
Redo写或传输进程 |
lgwr |
lgwr |
lgwr或者arch |
网络传输模式 |
sync |
sync |
sync或者async |
是否落盘确认 |
affirm |
affirm |
affirm或者noaffirm |
standby redologs |
需要 |
需要 |
可有可无 |
( 图片来自互联网) @H_301_0@ @H_301_0@ lgwr:primary使用LGWR即时将日志传送到standby的rfs进程,并保存到standby redo logfile中,而不再需要等到归档操作时才传送,保存到standbyredo logfile,然后再归档,然后redo应用。 @H_301_0@
用LGWR传输大致如下: 1)主库:只要有新的重做日志产生,lgwr进程将触发LNSn进程把新生成的日志传输给备库rfs进程。 2)备库:rfs进程接收到日志后,将其写入standby重做日志,如果备库开启了实时应用,就立即做日志应用,如果没有开启,则等standby重做日志归档后再应用。 3)其中,async和sync的区别在于:sync是在redo还在内存时,LNSn进程就开始传输,而async是在redo写到online redo log后,LNSn才开始传输。 同步的实时性来看,lgwr(sync) > lgwr(async)> arch |
@H_301_0@ @H_301_0@ async模式下,主库产生redo时,先写到本地online redo logfile文件中,LNSn进程从online redo logfile文件中取redo数据网络传输给备库RFS进程。
@H_301_0@ @H_301_0@ (3)模式切换 @H_301_0@ 首次performance>>availability>>protection顺序需要在主库执行且主库必须处于mount状态; @H_301_0@ 如果已经由performance>> availability>>protection数据保护级别操作过1次,那么再次操作时可直接操作; protection>>availability>>performance顺序直接操作即可
@H_301_0@
主备库操作:sql>select database_role,protection_mode,protection_level from v$database; 主库更改log_archive_dest_n参数配置,如: sql>alter system set log_archive_dest_2='service=orcldg lgwr sync valid_for=(online_logfiles,primary_role) db_unique_name=orcldg'; 主库操作:sql> shutdown immediate; 备库操作:alter database recover managed standby database cancel; 主库操作:sql>startup mount; 主库操作:sql>alter database set standby database to maximize availability; 主库操作:sql>alter database open 完成。 问题 当切换为alter database set standby database to maximize protection;之后alter database open报错 alter database open * ERROR at line 1: ORA-03113: end-of-file on communication channel Process ID: 10711 Session ID: 1 Serial number: 5 解决:读alert_orcl.log,我这里是备库端监听没有启动,启动了问题就解决了。 Fatal NI connect error 12541,connecting to: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=orcldg)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcldg)(CID=(PROGRAM=oracle)(HOST=orcldg)(USER=oracle)))) VERSION INFORMATION: TNS for Linux: Version 11.2.0.4.0 - Production TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production Time: 08-MAR-2016 21:14:11 Tracing not turned on. Tns error struct: ns main err code: 12541 TNS-12541: TNS:no listener ns secondary err code: 12560 nt main err code: 511 TNS-00511: No listener nt secondary err code: 111 nt OS err code: 0 *********************************************************************** |
备库启动遇到问题 sql> startup ORA-10458: standby database requires recovery ORA-01196: file 1 is inconsistent due to a Failed media recovery session ORA-01110: data file 1: '/u01/app/oracle/oradata/orcl/system01.dbf' 原因是由于某些redo没有传输到备库,可能落后了很多归档文件 处理: 1)备库查询:sql>select process,client_process,sequence#,status from v$managed_standby;//定位正在应用的日志文件 select max(sequence#) from v$archived_log; 2)主库查询:sql> select process,status from v$managed_standby;//查询主库当前写到的日志文件 select max(sequence#) from v$archived_log; 3)对比备库与主库之间的待传输应用日志文件,从主库拷贝到备库归档路径 4)备库注册 ALTER DATABASE REGISTER PHYSICAL LOGFILE '/u01/app/oracle/archivelog/xxx.dbf' ; 5)备库应用redo alter database recover managed standby database disconnect from session; 即可。 |