Oracle Data Guard简介
甲骨文Data Guard确保企业数据的高可用性,数据保护和灾难恢复。Data Guard提供了一套全面的服务,这些服务可以创建,维护,管理和监视一个或多个备用数据库以启用生产Oracle数据库以应对灾难和数据损坏。Data Guard会将这些备用数据库维护为生产数据库的副本。然后,如果由于计划内或计划外的停机而使生产数据库不可用,则Data Guard可以将任何备用数据库切换为生产角色,从而最大程度地减少与停机相关的停机时间。Data Guard可以与传统的备份,还原和群集技术一起使用,以提供高水平的数据保护和数据可用性。
主库
Data Guard配置包含一个生产数据库,也称为主数据库,该数据库在 主要作用。这是大多数应用程序访问的数据库。
主数据库可以是单实例Oracle数据库或Oracle R应用程序群集(Oracle RAC)数据库。
从库
从库是主数据库的事务一致性的副本。通过主库backup副本使创建从库,最多可以创建30个备用数据库并将其合并到Data Guard配置中。创建后,Data Guard会自动维护备份数据库,从主库传送重做数据到备库然后在备库上应用。
与主数据库类似,备用数据库可以是单实例Oracle数据库,也可以是 Oracle RAC数据库。
备用数据库的类型如下:
- 物理备用数据库
提供基本相同的主数据库副本,其中包括 在磁盘数据库结构上与主数据库完全相同(逐块)。数据库架构(包括索引)是相同的。物理备用数据库通过“重做应用”与主数据库保持同步,该应用恢复从主数据库接收的重做数据,并将重做应用于物理备用数据库。
从Oracle Database 11 g第 1版(11.1)开始,物理备用数据库在为只读访问而打开时可以接收并应用重做。因此,物理备用数据库可以同时用于数据保护和报告。
Data Guard保护模式
- 逻辑备用数据库
尽管数据的物理组织和结构可能不同,但包含与生产数据库相同的逻辑信息。逻辑备用数据库通过SQL与主数据库保持同步,该SQL将重做中从主数据库接收的数据转换为SQL语句,然后在备用数据库上执行SQL语句。
逻辑备用数据库除灾难恢复要求外,还可用于其他业务目的。这使用户可以访问逻辑备用数据库以进行查询和随时报告目的。另外,使用逻辑备用数据库,您几乎可以在不停机的情况下升级Oracle数据库软件和补丁集。因此,逻辑备用数据库可以同时用于数据保护,报告和数据库升级。
- 快照备用数据库
快照备用数据库是完全可更新的备用数据库。
类似于物理或逻辑备用数据库,快照备用数据库从主数据库接收并存档重做数据。与物理或逻辑备用数据库不同,快照备用数据库不应用其接收的重做数据。
Data Guard保护模式
- 最大可用性
这种保护模式可提供最高级别的数据保护,而不会影响主数据库的可用性。在至少一个同步的备用数据库上,将恢复这些事务所需的所有重做数据写入在线重做日志和备用重做日志之前,事务不会提交。如果主数据库无法将其重做流写入至少一个同步的备用数据库,则它将在最大性能模式下运行以保留主数据库的可用性,直到它再次能够将其重做流写入同步的备用数据库。
此模式确保在主数据库发生故障时不会发生任何数据丢失,而仅在第二次故障不能阻止将完整的重做数据集从主数据库发送到至少一个备用数据库时才会发生数据丢失。
- 最高性能
这种保护模式提供了可能的最高级别的数据保护,而不会影响主数据库的性能。这是通过允许事务在这些事务生成的所有重做数据已写入在线日志后立即提交来实现的。重做数据也被写入一个或多个备用数据库,但这是相对于事务承诺异步完成的,因此主数据库性能不受重做数据写入备用数据库延迟的影响。
与最大可用性模式相比,此保护模式提供的数据保护略少,并且对主数据库性能的影响最小。
这是默认的保护模式。
- 最大保护
此保护模式可确保在主数据库发生故障时不会发生数据丢失。为了提供这种级别的保护,必须在事务提交之前将恢复事务所需的重做数据写入至少一个同步备用数据库上的联机重做日志和备用重做日志中。为了确保不会发生数据丢失,如果主数据库无法将其重做流写入至少一个同步备用数据库,则它将关闭而不是继续处理事务。
环境准备
主库信息
- 安装选项:创建和配置数据库
- db_name: orcl
- db_unique_name:orcl_pd
- sid: orcl
从库信息
- 安装选项:只安装基础软件
- db_name: orcl
- db_unique_name:orcl_st
- sid: orcl
主库配置步骤
官网上步骤说明
配置准备
# 开启强制日志模式
alter database force logging;
# 开启归档模式
alter database archivelog;
# 开启闪回
alter database flashback on;
# 校验force_logging是否开启
select force_logging from v$database;
注意:归档模式如果没有开启,需要停止数据以mount模式启动后然后修改归档模式
# 校验归档模式是否开启
archive log list;
# 如果没有启用归档模式需要停止数据库实例
shutdown immediate
# 以mount mount 模式启动数据库(不加载数据文件),还有nomount模式启动
startup mount
# 修改database配置启用archivelog 归档模式
alter database archivelog;
为从库创建日志文件
按照官网的说明,备库重做日志文件组大小要和主库最大的日志大小一致。备用重做日志必须比主库中的重做日志至少多一个重做日志组
select group#,BYTES/1024/1024 || 'M' from v$log;
alter database add standby logfile group 4 ('C:\APP\ADMINISTRATOR\ORADATA\ORCL\redo04.log') size 50m;
alter database add standby logfile group 5 ('C:\APP\ADMINISTRATOR\ORADATA\ORCL\redo05.log') size 50m;
alter database add standby logfile group 6 ('C:\APP\ADMINISTRATOR\ORADATA\ORCL\redo06.log') size 50m;
alter database add standby logfile group 7 ('C:\APP\ADMINISTRATOR\ORADATA\ORCL\redo07.log') size 50m;
注意sql语句中的日志组路径要改成自己的日志如路径,创建完成后检查下重做日志组。
select group#,thread#,sequence#,archived,status from V$STANDBY_LOG;
主库配置文件修改
以下内容是官网提供的。
DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=boston ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
alter system set db_unique_name='primary' scope=spfile;
alter system set log_archive_config='DG_CONFIG=(primary,standby)' scope=spfile;
/** 这里修改的是归档日志文件存储目录**/
alter system set log_archive_dest_1='location=C:\app\Administrator\oradata\flash\orcl\ARCHIVELOG\ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=primary' scope=spfile;
alter system set log_archive_dest_2='SERVICE=standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby' scope=spfile;
alter system set log_archive_dest_state_1 = 'enable' scope=spfile;
alter system set log_archive_dest_state_2 = 'enable' scope=spfile;
alter system set fal_server='standby' scope=spfile;
alter system set fal_client='primary' scope=spfile;
alter system set archive_lag_target=1800 scope=spfile;
alter system set log_archive_format='%t_%s_%r.arc' scope=spfile;
alter system set standby_file_management=auto scope=spfile;
alter system set db_file_name_convert='standby','primary' scope=spfile;
alter system set log_file_name_convert='standby','primary' scope=spfile;
注意 以上如果修改数据库参数过程中参数配置错误,会导致oracle数据库无法启动。我们需要还原下数据库的参数配置文件,
# 可以利用下面的文件还原 C:\app\Administrator\product\11.2.0\dbhome_1\database\SPFILEORCL.ORA
C:\app\Administrator\admin\orcl\pfile\init.ora.3152020114615
# 还原命令如下
create spfile='C:\app\Administrator\product\11.2.0\dbhome_1\database\SPFILEORCL.ORA' from pfile='C:\app\Administrator\admin\orcl\pfile\init.ora.3152020114615';
-
pfile: 初始化参数文件(Initialization Parameters Files),Oracle 9i之前,ORACLE一直采用pfile方式存储初始化参数,pfile 默认的名称为“init+例程名.ora”文件路径:/data/app/oracle/product/12.1.0/dbhome_1/dbs,这是一个文本文件,可以用任何文本编辑工具打开。
-
spfile:服务器参数文件(Server Parameter Files),从Oracle 9i开始,Oracle引入了Spfile文件,spfile 默认的名称为“spfile+例程名.ora”文件路径:/data/app/oracle/product/12.1.0/dbhome_1/dbs 以二进制文本形式存在,不能用vi编辑器对其中参数进行修改,只能通过SQL命令在线修改。
-
小技巧,创建 pfile 参数文件,用于复制到从库中。
为啥要创建pfile 文件呢,上面我们通过sql直接修改了spfile 文件,spfile是二进制的无法通过文本编辑器修改,而这些参数在从库中也需要配置,而我们不想在从库中在执行sql了(当然也可以执行sql来修改了)。所以我们生通过spfile生成 pfile(注意生成的目录就在spfile文件目录中)。然后我们copy pfile 文件到从库中,直接修改pfile文件,然后通过pfile生成 从库的spfile就好了啊。
Create pfile from spfile;
创建 listener 监听服务
-
如果是window操作系统推荐使用 net manager界面化添加配置。
-
添加过程中需要输入数据库的实例名称,我们通过sql语句查询下
show parameter name
!
- 生效listener 监听服务配置
lsnrctl reload
- 查看下lsnrctl status
配置数据库的服务别名
- 服务别名就是tnsnames.ora,这里和oracle的连接方式有关。
- 注意地址和别名名称
- 测试配置文件的格式语法有没有错误
tnsping orcl_pd
tnsping orcl_st
创建密码文件
一般密码文件是存在的不需要穿件的。
如果不存在,则需要创建,创建过程如下:
Orapwd file=D:\app\Administrator\product\11.2.0\dbhome_1\database\PWDorcl.ora password=123 entries=5
- 注意以上命令的file参数路径以及password值。
从库操作步骤
先将主库中的一些基础文件复制到从库相同目录中
- flash 文件
- 密码文件
- listener.ora 和 tnsnames.ora
注意修改 listener.or 中 IP 地址为备机 IP
从机上新建orcl 数据库实例
Oradim -new -sid orcl
从库启动监听
lsnrctl start
从库参数文件修改
- 将主库中的INITorcl.ora配置文件复制到从库相同的目录中
- 修改其中的关键信息,参考下图红框中修改
启动数据库实例
- 注意启动过程中,可能会报错,如下图。
- 根据错误信息,我们漏掉了一个归档文件目录,所以这里需要新建一个文件目录
复制主库的备份数据
通过以上步骤主从库的配置基本完成,但是我们需要先同步一次主从的数据库。我们这里采用rman备份主库数据然后同步到从库中
备份主库
- 备份
rman target orcl/orcl@orcl
Backup full database format='C:\app\Administrator\oradata\tmp\FOR_STANDBY_%u%p%s.RMN' include current controlfile for standby;
- 将当前 archivelog 归档
输入命令
sql'alter system archive log current';
恢复从库
- 将主库的备份数据集复制到从库相同的目录中
- 通过auxiliary辅助通道连接standby从库
connect auxiliary orcl/orcl@standby
如果遇到连接超时连接问题,把防火墙关掉或者开放端口
- 恢复从库
duplicate target database for standby nofilenamecheck;
- 这里还原的时候遇到几个坑,参考资料没有说明清楚,主要是恢复的时候从库中部分文件夹不存在,一直报文件无法创建。
- 第一个错误是备份数据集没有copy到从库对于位置
- 第二个错是无法创建CONTROL01.CTL文件 因为C:\app\Administrator\oradata\orcl 这个目录不存在所以无法创建
-
第三问题是,重新备份了一份数据,还原时没有copy数据集到从库,所以出现故障转移到上一个备份,当时依然报错,无法创建CONTROL02.CTL文件,是因为C:\app\Administrator\flash_recovery_area\orcl 这个文件夹不存在,所以无法创建
-
最后一次,我把从库的数据清掉了,创建好文件夹,重新执行还原命令就好了。所以这里提醒下,遇到问题认证看日志分析问题。
启动从库
Alter database mount standby database;
Alter database recover managed standby database disconnect from session;
验证
- 主库从库执行sql查询语句,只要sequence是一致的说明就ok了。这里的一直不是数据量一致哦,是指的sequence最大的一个值同步。
Select sequence#,applied,completion_time from v$archived_log order by completion_time desc,sequence# desc;
主库的日志sequence:
从库的日志sequence:
本文中 sequence 一开始都是23
- 任意修改主库的一个sql
Alter system switch logfile;
主库:
从库:
主库执行alter 语句之后,从库的sequence也会跟着同步,都变成25说明准备数据同步配置成功了。
dg的使用
客户端实现
url: jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=Dong1)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=Dong2)(PORT=1521)))(LOAD_BALANCE=OFF)(FAILOVER=ON)(CONNECT_DATA=(SERVICE_NAME=CALLDB)(SERVER=DEDICATED)))
服务端实现
- Fast-Start Failover是建立在broker基础上的一个快速故障转换的机制,通过fast-start failover可以自动检测primary的故障,然后自动的failover到预先指定的standby上面,这样可以最大化的减少故障时间,提高数据库的可用性。
- Fast-Start Failover是在broker的基础上再增加了一个单独的observer,用来监控primary和standby数据库的状态,一旦primary不可用,observer就会自动的切换到指定的standby上面。
- FAST-START FAILOVER是ORACLE10G的一项新功能。这个功能可以实现当主库宕机时,预定的从库自动快速可靠地进行失败切(FAILOVER)。切换完成之后,原来的主库恢复正常之后,将会自动地配置为从库。这的确是一项令DBA心动的功能,大大减少了DBA的维护和管理工作。尤其是减少了在出现突然问题时的心慌意乱和手忙脚乱。
具体请参考https://blog.csdn.net/lihuarongaini/article/details/48811539