>> from zhuhaiqing.info
确认主库处于归档模式下
SQL>archive log list; Database log mode Archive Mode Automatic archival Enable Archive destination /oradata/archivelog Oldest online log sequence 3 Next log sequence to archive 5 Current log sequence 5
如果主库没有处在归档模式下,则:
1、修改10g为归档模式:
SQL> alter system set log_archive_dest_1='location=/oradata/archivelog’; SQL> shutdown immediate; SQL> startup mount SQL> alter database archivelog; SQL> alter database open;
2、设置强制记录:
SQL> alter database force logging;
3、检查参数control_file_record_keep_time,设置为7即可
SQL> show parameter control_file_record_keep_time; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time integer 7
在备库创建必要的目录
备库只安装oracle软件即可,并在备库上创建和主库一样的目录。
如果规划备库与主库目录不一致,则我们只需要在备库软件安装后,修改备库的spfile相应路径参数并加载,最后duplicate创建备库的时候,即可恢复相应数据到新的目录。
#oracle转储目录 mkdir -p /opt/ora10/product/admin/starboss/adump mkdir -p /opt/ora10/product/admin/starboss/bdump mkdir -p /opt/ora10/product/admin/starboss/cdump mkdir -p /opt/ora10/product/admin/starboss/dpump mkdir -p /opt/ora10/product/admin/starboss/udump mkdir -p /opt/ora10/product/admin/starboss/pfile #数据文件目录 mkdir -p /opt/ora10/product/oradata/starboss #主库上的rman备份目录,备库恢复的时候,我们把主库的备份集复制到备库的这个目录。 mkdir -p /rmanbackup
如果2边OS的版本完全一样,最方便的办法,便是将主库的oracle安装目录全部复制到备机的相同路径下。前提是备机具备oracle运行条件,如内核参数,相关用户和组,必要的软件包,用户环境变量等等。
配置TNS
分别配置2台机器的tnsname,达到的效果是主机和备机,分别都能用sys用户登录本机和对方机器。
主机tnsname.ora
[root@db01 opt]# cat /opt/ora10/product/10.2.0/network/admin/tnsnames.ora # tnsnames.ora Network Configuration File: /opt/ora10/product/10.2.0/network/admin/tnsnames.ora # Generated by Oracle configuration tools. STARBOSS = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.102.100)(PORT = 1521)) ) (CONNECT_DATA = (SID = starboss) #默认是service_name,如果出现无法从对方机器登陆的情况,可以改用SID试试 (UR=A) ) ) STARBOSSSTBY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.102.101)(PORT = 1521)) ) (CONNECT_DATA = (SID = starboss) #默认是service_name,如果出现无法从对方机器登陆的情况,可以改用SID试试 (UR=A) ) )
主机listener.ora
[root@db01 opt]# more /opt/ora10/product/10.2.0/network/admin/listener.ora # listener.ora Network Configuration File: /opt/ora10/product/10.2.0/network/admin/listener.ora # Generated by Oracle configuration tools. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /opt/ora10/product/10.2.0) (SID_NAME = starboss) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.102.100)(PORT = 1521)) ) )
将这2个文件复制到备机,并修改相应的ip地址。
测试两边的通信,保证在分别每台机器上执行如下tnsping都能成功,且保证2台主机分别能用SYS用户sqlplus登陆对方主机。
-bash-3.2$ tnsping starboss TNS Ping Utility for Solaris: Version 10.2.0.5.0 - Production on 26-8月 -2014 17:57:50 Copyright (c) 1997, 2010, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.253)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = starboss))) OK (0 msec) -bash-3.2$ tnsping starbossstby TNS Ping Utility for Solaris: Version 10.2.0.5.0 - Production on 26-8月 -2014 17:57:52 Copyright (c) 1997, 2010, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.244)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = starboss))) OK (10 msec)
配置Data Guard参数
注意2个主机的数据库SID可以一样,但是必须用不同的DB_UNIQUE_NAME,方便起见,红色字体全都取主备库各自的tnsname。
确定好参数后,就可以登录主备数据库,分别开始对参数进行设置(有些参数不是oracle动态参数,可以先加scope=spfile将参数写入spfile,然后再重启数据库进行加载):
#主机配置
alter system set DB_UNIQUE_NAME='starboss' alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(starboss,starbossstby)' #罗列所有DG成员的DB_UNIQUE_NAME,无顺序要求 alter system set LOG_ARCHIVE_DEST_1='LOCATION=/stardb_archiv/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=starboss' alter system set LOG_ARCHIVE_DEST_2='SERVICE=starbossstby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=starbossstby' #如果要启用max availability mode, max protection mode,则使用OPTIONAL LGWR SYNC AFFIRM选项,并启用standby redo logs,但是系统会有额外的性能消耗 alter system set LOG_ARCHIVE_DEST_STATE_1='ENABLE' alter system set LOG_ARCHIVE_DEST_STATE_2='ENABLE' alter system set LOG_ARCHIVE_FORMAT=%t_%s_%r.arc alter system set REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE alter system set LOG_ARCHIVE_MAX_PROCESSES=30
#备机配置
alter system set DB_UNIQUE_NAME='starbossstby' alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(starbossstby,starboss)' alter system set LOG_ARCHIVE_DEST_1='LOCATION=/stardb_archiv/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=starbossstby' alter system set LOG_ARCHIVE_DEST_2='SERVICE=starboss LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=starboss' alter system set LOG_ARCHIVE_DEST_STATE_1='ENABLE' alter system set LOG_ARCHIVE_DEST_STATE_2='ENABLE' alter system set LOG_ARCHIVE_FORMAT=%t_%s_%r.arc alter system set REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE #以下为备机使用参数,如果需要配置主备切换,则这些参数也需要配置到主机上。 alter system set FAL_SERVER='starboss' alter system set FAL_CLIENT='starbossstby' alter system set STANDBY_FILE_MANAGEMENT='AUTO' alter system set LOG_FILE_NAME_CONVERT='/stardb_log1/starboss','/stardb_log1/starboss' #日志路径:主库1,备库1,主库2,备库2…… alter system set DB_FILE_NAME_CONVERT='/opt/ora10/oradata/starboss/','/opt/ora10/oradata/starboss/' #数据文件路径:主库1,备库1,主库2,备库2……
如果备库部分目录和主库目录结构不一样,我们需要将数据文件、重做日志或者控制文件存储到备机的不同目录,则在备库上将相关路修改为新的路径,这样后面再做duplicate复制的时候,oracle就会知道新的文件应该存储到什么地方:
AUDIT_FILE_DEST='/oracle/app/oracle/admin/dbaux/adump' BACKGROUND_DUMP_DEST='/oracle/app/oracle/admin/dbaux/bdump' CORE_DUMP_DEST='/oracle/app/oracle/admin/dbaux/cdump' USER_DUMP_DEST='/oracle/app/oracle/admin/dbaux/udump' CONTROL_FILES='/oradata/starboss/control01.ctl','/oradata/starboss/control02.ctl' DB_FILE_NAME_CONVERT='/opt/ora10/oradata/starboss/','/opt/ora10/oradata/starboss/' LOG_FILE_NAME_CONVERT='/opt/app/oracle/oradata/starboss/', '/oradata/starboss/'
生成oracle远程登录密码文件
修改参数remote_login_passwordfile:
alter system set remote_login_passwordfile = EXCLUSIVE
分别在主备机器生成SYS用户远程登录密码文件,注意password后面的密码要完全一样,否则无法归档。
orapwd file=/opt/ora10/product/10.2.0/dbs/orapw$SID password=sys
也可以在主库生成密码文件,然后复制到备份机。
恢复备库
备份主库
恢复主库前,先给主库做一次全备,并同时创建standby控制文件备份。
-bash-3.2$ rman target / Recovery Manager: Release 10.2.0.5.0 - Production on 星期二 8月 26 13:26:28 2014 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: STARBOSS (DBID=2784594064) RMAN> BACKUP DATABASE FORMAT '/rmanbackup/data_%U' INCLUDE CURRENT CONTROLFILE FOR STANDBY PLUS ARCHIVELOG FORMAT '/rmanbackup/arc_%U'
本例中的%U为系统自动生成的一个唯一文件名,具体rman有如下格式的通配符,实施的时候可以灵活运用:
%c 备份片的拷贝数
%d 数据库名称
%D 位于该月中的第几天(DD)
%M 位于该年中的第几月(MM)
%F 一个基于DBID 唯一的名称,这个格式的形式为c-xxxxxx-YYYYMMDD-QQ,其中xxxxxx为该数据库的DBID,YYYYMMDD 为日期,QQ 是一个1-256 的序列,%F只用于rman的控制文件自动备份,无法手动调用。
%n 数据库名称,向右填补到最大八个字符
%u 一个八个字符的名称代表备份集与创建时间
%p 该备份集中的备份片号,从1 开始到创建的文件数
%U 一个唯一的文件名,代表%u_%p_%c
%s 备份集的号
%t 备份集时间戳
%T 年月日格式(YYYYMMDD)
恢复备机
这一步开始用主库的备份去恢复备机。
将主库的rman备份目录通过NFS挂载到备机的相同路径。
登陆到备机,先将备机启动到nomount模式下:
SQL> startup nomount;
从备机rman到主库,用主库的备份集来恢复备库:
-bash-3.00$ rman target sys/sys@starboss auxiliary / Recovery Manager: Release 10.2.0.5.0 - Production on星期二 1月 20 17:38:58 2015 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: dgprm (DBID=879780823) connected to auxiliary database: dgstd (not mounted) RMAN> duplicate target database for standby nofilenamecheck dorecover; #for standby告诉rman复制为一个备机,如果是to dgstd,则为复制数据库
执行完毕后,数据库自动进入mount状态
手动启动数据库到管理恢复模式下:
SQL> alter database recover managed standby database disconnect from session';
观察备库的alert_starboss.log
如果备库正常,能看到类似如下信息:
RFS[2]: Archived Log: '/star_db/arch_log/1_2122_856225689.dbf' --接受主库归档2122 Primary database is in MAXIMUM PERFORMANCE mode Tue Aug 26 16:59:49 EAT 2014 Media Recovery Log /star_db/arch_log/1_2122_856225689.dbf --应用主库归档日志2122到备库 Media Recovery Waiting for thread 1 sequence 2123 (in transit) --等待下一个归档日志2123
如果碰到如下错误:
Completed: alter database recover managed standby database disconnect from session Tue Aug 26 01:04:27 EAT 2014 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 1484-1583 DBID 2784594064 branch 856225689 FAL[client]: All defined FAL servers have been attempted. ------------------------------------------------------------- Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that is sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps. -------------------------------------------------------------
归档日志出现gap,这说明,恢复的备库还有归档日志缺失,备库无法恢复到最新状态,所以需要恢复日志中提示的缺失归档日志。
这种问题的处理方法是:
从备库登陆主库,利用主库的备份信息,恢复备库的归档日志,执行如下命令:
$ rman target sys/system@starboss auxiliary / rman>restore archivelog sequence between 1484 and 1583
备库切换为主库(failover)
(1) 判断主数据库确实出现严重的硬件故障或其他原因导致主数据库无法启动。
(2) 确保备库没有ARCHIVELOG GAP:
SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;
如果有记录,需要将确实的归档记录手动复制到备机能访问到的路径,并执行注册,filespec1为文件的绝对路径:
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
再查看v$archive_gap视图,如此反复,直到没有记录。
(3) 在物理备用数据库上发起failover操作
SQL> alter database recover managed standby database cancel; SQL> alter database recover managed standby database finish force;
(3) 把物理备用数据库转化成主用角色
SQL> select database_role from v$database; DATABASE_ROLE ---------------- PHYSICAL STANDBY SQL> alter database commit to switchover to primary; SQL> select database_role from v$database; DATABASE_ROLE ---------------- PRIMARY
(4) 把新的主用数据库重新启动
SQL> shutdown immediate; SQL> startup;
最后立即给新的主库做一次全备,防止数据再次丢失
主机故障恢复后,DG环境需要重新配置一遍,在主机上重新做一遍duplicate,并将主机配置为新的备库,方案有3:
1、 如果宕机的主库事先已经配置了闪回(flashback)功能,使用闪回恢复主库到制定时间点。
2、 重新将主机手动重新创建为新的备机。
3、 使用DGMGRL(Data Guard Broker)工具里面的REINSTATE DATABASE命令将主机重新配置为新的备机。但是这种方案要求先前数据库已经开启了数据库闪回功能。
切换的操作必须先从主库发起切换操作,最后在备库完成切换操作。切换前,务必断开oracle的一切外部用户和应用的连接。
主备互切(switchover)
在主库端
关闭所有主库连接,直到switchover_status由session active变为to standby
SQL> select switchover_status from v$database;
如果是to standby,表可以直接切换.
SQL> alter database commit to switchover to physical standby;
如果是sessions active,说明系统有session连接,确认所有连接已经断开,可以尝试执行:
SQL> alter database commit to switchover to physical standby with session shutdown; SQL> shutdown immediate; SQL> startup mount
此时,再次检查目前的主库的状态,因为它现在已经被切换为备机,所以应该显示为TO PRIMARY:
SQL> select switchover_status from v$database;
在备库端
上一步将主库切换成备库后,原先的备库会收到原先的主库发出的switchover通知,以前的切换状态应该变为to primary:
SQL> select switchover_status from v$database;
执行切换,将老的备库切换成新的主库
SQL> alter database commit to switchover to primary; SQL> alter database open;
检查切换后的状态
SQL> select switchover_status from v$database;
standby数据库切换成主库后,检查是否需要对临时表空间增加临时文件
SQL> col file_name format a60 SQL> select file_name,tablespace_name from dba_temp_files;
把结果前面原主库上的临时文件进行对比,如有丢失则使用如下命令增加:
alter tablespace temp add tempfile '/data/oradata/alihr/temp02.dbf' size 2048M reuse;
在新的备库上
alter database recover managed standby database disconnect from session;
最后在新的主库上切换日志,查看2边反应
SQL> alter system switch logfile;
Real-Time apply
前面搭建的Physical Standby不能做到实时同步主库数据,只当主库online redo 归档后,才会将这个归档日志传到备机并applied 到备库,这个延迟时间较长,如果主库业务不繁忙,可能好几天才产生一个归档文件,这时备库数据和主库数据相差就好几天了。
启用real-time apply后,只要主库事务提交,备库这边即开始应用。
1、将备机先退出恢复管理模式
SQL> alter database recover managed standby database cancel;
2、在备机添加standby redo log,先确定备机有几组正常的重做日志,standb重做日志组的数量要比正常重做日志多1组。
standby redo log数量计算方法为:(每个thread的redo logfile数 + 1) * thread总数。具体可以执行select * from v$log 去查看。
alter database add standby logfile thread 1 group 4 ('/opt/app/oracle/oradata/starboss/stdlog01.log') size 50m reuse; alter database add standby logfile thread 1 group 5 ('/opt/app/oracle/oradata/starboss/stdlog02.log') size 50m reuse; alter database add standby logfile thread 1 group 6 ('/opt/app/oracle/oradata/starboss/stdlog03.log') size 50m reuse; alter database add standby logfile thread 1 group 7 ('/opt/app/oracle/oradata/starboss/stdlog04.log') size 50m reuse;
3、在备机启动实时恢复模式
SQL> alter database recover managed standby database using current logfile disconnect from session;
4、观察备机日志
Tue Jan 13 17:49:27 EAT 2015 alter database recover managed standby database using current logfile disconnect from session Tue Jan 13 17:49:27 EAT 2015 Attempt to start background Managed Standby Recovery process (starboss) MRP0 started with pid=25, OS id=1397 Tue Jan 13 17:49:27 EAT 2015 MRP0: Background Managed Standby Recovery process started (starboss) Managed Standby Recovery starting Real Time Apply parallel recovery started with 16 processes Tue Jan 13 17:49:32 EAT 2015 Waiting for all non-current ORLs to be archived... Media Recovery Waiting for thread 1 sequence 49431 (in transit) Tue Jan 13 17:49:33 EAT 2015 Completed: alter database recover managed standby database using current logfile disconnect from session …… Recovery of Online Redo Log: Thread 1 Group 8 Seq 49433 Reading mem 0 Mem# 0: /stardb_log2/starboss/stdlog02.log
同时,主库上会有如下的日志:
LNS: Standby redo logfile selected for thread 1 sequence 49433 for destination LOG_ARCHIVE_DEST_2
关于保护级别
MAXIMUM PROTECTION
特点:
1、数据0丢失
2、最高级别保护
3、主备必须采用OPTIONAL LGWR SYNC AFFIRM的传输方式
4、备机必须启用standby redo log
5、如果备机不可用(如断网、宕机),主机数据库也会shutdown,所以这种模式下,备机数量最好是2台或者以上
主机操作
SQL> STARTUP MOUNT SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION; SQL> ALTER DATABASE OPEN;
MAXIMUM AVAILABILITY
特点:
1、数据0丢失
2、第二高级别的数据保护
3、主备必须使用OPTIONAL LGWR SYNC AFFIRM传输方式
4、备机必须启用standby redo log
5、如果备机shutdown,主机不会跟着shutdown,备机崩溃后,主机自动切换到MAXIMUM PERFORMANCE
主机操作
SQL> STARTUP MOUNT SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY; SQL> ALTER DATABASE OPEN;
MAXIMUM PERFORMANCE
默认保护级别。
如果不考虑上述配置,默认保护级别就是最大性能
这种模式下,必须主库重做日志归档后,才会提交到备库
主机操作
SQL> STARTUP MOUNT SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE; SQL> ALTER DATABASE OPEN;
查看当前保护模式
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;
关于DGMGRL(Data Guard Broker)
安装完整的oracle client,或者完整的oracle enterprise edition/personal edition都会安装这个工具。
oracle官方推荐将这个工具安装到独立于主备机器的第三台主机,特别是需要使用fast-start failover功能的时候。
启动DataGuard的命令行接口:
SQL> alter system set DG_BROKER_START=TRUE; bash-3.2$ dgmgrl sys/sys DGMGRL for Solaris: Version 10.2.0.5.0 - 64bit Production Copyright (c) 2000, 2005, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected.
创建配置并添加主库:
DGMGRL > create configuration 'DGkenya' as > primary database is starboss > connect identifier is starboss;
添加备库:
DGMGRL> add database starbossstby as > connect identifier is starbossstby > maintained as physical; DGMGRL> show configuration
启用配置:
DGMGRL> enable configuration;
启用节点数据库:
DGMGRL> enable database starboss; DGMGRL> enable database starbossstby;
错误检查:
DGMGRL> show database starbossstby statusreport; #打印状态报告 DGMGRL> show database starbossstby 'InconsistentProperties'; #查看是否有不符合配置的属性 DGMGRL> edit database starbossstby set property 'PropertiesName' = 'Value'; #修改属性
重启ARCH进程
主要针对如网络连接失败,需要重新启动归档日志传送连接,又不希望重启数据库的情况
重启log_archive_dest_state_2参数,让arch进程重启,再主库上执行:
SQL> ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; SQL> ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
观察主库的alert_sid.log,会发现LGWR进程重新启动了:
Tue Jan 13 16:49:35 2015 ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; Tue Jan 13 16:49:45 2015 ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH; Tue Jan 13 16:49:47 2015 ****************************************************************** LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2 ******************************************************************
切换归档日志,并查看2边日志是否正常:
SQL> alter system switch logfile;
Data Guard备机的启停
1.启动备机到备份模式
SQL> startup nomount SQL> alter database mount standby database; SQL> alter database recover managed standby database disconnect from session; --启动非实时应用 SQL> alter database recover managed standby database using current logfile disconnect from session; --启动实时应用,前提是备机已经创建standby redo log
2.关闭备机
SQL> select process, status from v$managed_standby; --查看备库是否在应用日志进行恢复 SQL> alter database recover managed standby database cancel; --备机退出日志接收 SQL> shutdown immediate;
DataGuard状态视图
--主机视图,当前已归档重做日志的状态和配置信息 select * from v$archive_dest_status; --主备机视图,记录在控制文件中的归档信息,通过它,可以获取当前主备已经归档的重做日志序号 select max(sequence#) from v$loghist;