并行恢复standby数据库 提高恢复速度

数据库
standby数据库是对主库数据文件的复制,物理standby是通过对主库数据文件的copy不断应用主库传输过来的redo重做日志来保持和主库的物理结构一致。恢复standby数据库可以提高恢复速度。下面就为大家介绍并行恢复standby数据库 .

有一个数据库,standby库恢复时经常赶不上主库的进度,用iostat -x 3查看磁盘利用率的时候,发现三个放数据文件的盘(每个盘是由6个物理盘做的raid10)的读iops在80以内,磁盘利用率在30%以内。所以初步分析恢复的慢应该跟io利用率不高有关。所以考虑使用并行恢复提高恢复速度。这样就大大加快了工作效率,下面就来学习学习吧。 

开始尝试并行恢复时,有时并行恢复起不来,alert.log里提示如下信息:

Tue Oct 12 18:09:28 2010

ALTER DATABASE RECOVER managed standby database parallel 8 disconnect from session Exti+%g
Attempt to start background Managed Standby Recovery process

MRP0 started with pid=8

MRP0: Background Managed Standby Recovery process started

attempting to start a parallel recovery with 8 processes

parallel recovery failed to get any processes VUvh8wun
non-parallel recovery will be done Sb'a@ ]`cn
Media Recovery Log /data3/arch/hzbops/hzbops1_347246.arc

有时又可以起来,但最多能够启动5个并行进程。分析发现并行启动不了是因为nofile值设置过小导致,而并行最多启动5个,原因是parallel_max_servers 参数值设置为5。

对这个数据库做了如下调整:

1. 参数 parallel_max_servers

这个参数限制了实际可以起的并行进程数,要在初始化参数里设置。参数文件里默认没有,oracle会给出一个默认值。这个默认值可能过小,需要调大一些。

这个数据数据库从5改成16。

2. /etc/security/limits.conf 中的nofile 值调大,默认是1024,改成5000。

* soft nofile 65536 2u7

nofile指定了每个用户打开的文件数,oracle目前有数据文件500个,开8个进程并行恢复的话就需要4000个文件句柄。所以之前设置的有点小。调整完后,需要关闭数据库,然后退出oracle用户后,再进入oracle用户,让这个设置生效。前面的那个并行启动不了的原因就是这个参数设置的过小。

这里再检查IO,看到io利用率上去了,恢复进度也比以前快了很多:

avg-cpu: %user %nice %sys %iowait %idle @}

1.04 0.00 0.71 27.54 70.71

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sda 0.00 12.67 0.33 5.67 2.67 146.67 1.33 73.33 24.89 0.00 0.28 0.28 0.17

sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sda2 0.00 5.33 0.33 1.00 2.67 50.67 1.33 25.33 40.00 0.00 1.25 1.25 0.17

sda3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sda5 0.00 1.33 0.00 1.33 0.00 21.33 0.00 10.67 16.00 0.00 0.00 0.00 0.00

sda6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sda7 0.00 3.67 0.00 1.67 0.00 42.67 0.00 21.33 25.60 0.00 0.00 0.00 0.00

sda8 0.00 2.00 0.00 1.00 0.00 24.00 0.00 12.00 24.00 0.00 0.00 0.00 0.00

sda9 0.00 0.33 0.00 0.67 0.00 8.00 0.00 4.00 12.00 0.00 0.00 0.00 0.00

sda10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sdc 0.67 0.00 22.00 0.00 5466.67 0.00 2733.33 0.00 248.48 0.02 0.91 0.91 2.00

sdc1 0.67 0.00 22.00 0.00 5466.67 0.00 2733.33 0.00 248.48 0.02 0.91 0.91 2.00

sdd 0.00 0.67 365.33 0.67 5634.67 10.67 2817.33 5.33 15.42 1.76 4.81 2.13 77.97

sdd1 0.00 0.67 365.33 0.67 5634.67 10.67 2817.33 5.33 15.42 1.76 4.81 2.13 77.97

sde 0.00 0.33 356.33 0.33 5528.00 5.33 2764.00 2.67 15.51 1.49 4.19 2.08 74.07

sde1 0.00 0.33 356.33 0.33 5528.00 5.33 2764.00 2.67 15.51 1.49 4.19 2.08 74.07

sdf 0.00 0.00 290.00 0.00 4533.33 0.00 2266.67 0.00 15.63 1.37 4.72 2.37 68.73

sdf1 0.00 0.00 290.00 0.00 4533.33 0.00 2266.67 0.00 15.63 1.37 4.72 2.37 68.73

这就是我要为大家介绍的并行恢复standby数据库,这些代码之类的可能对初学者比较难理解,凡事开头难,只要您肯下功夫学习,没有不成的事。好好学习这篇文章中介绍的,希望能对大家又帮助。

【编辑推荐】

  1. 专利数据库的作用
  2. 数据库优化设计注意事项
  3. 企业数据库安全四大策略
责任编辑:迎迎 来源: 比特博客
相关推荐

2011-05-13 13:26:52

master数据库恢复

2011-03-24 17:49:47

数据库恢复

2011-05-18 10:49:53

Oralce数据库

2011-02-28 13:31:17

Oracle数据库

2009-11-20 13:29:59

Oracle数据库恢复

2011-05-26 09:36:07

Oracle数据库Redo故障

2011-03-24 09:45:34

SQL Server数恢复

2010-08-27 13:27:50

DB2备份恢复

2011-03-04 14:59:16

Raidoracle数据库

2011-08-29 16:41:14

OracleRMAN恢复数据文件的恢复

2010-08-31 13:35:53

DB2备份恢复

2011-08-23 11:09:36

Oraclerman恢复system表空间恢复

2011-05-19 11:33:38

数据库访问速度

2009-04-03 10:54:49

Oracle备份恢复

2011-05-13 13:15:52

SYBASE ASA数

2011-03-24 17:21:42

Oracle数据库Redo故障

2023-12-27 22:08:39

vivo数据库

2011-03-22 15:55:26

数据库内容恢复

2019-08-20 14:02:07

MongoDB数据库恢复数据

2011-08-30 09:35:10

OracleRMAN不完全恢复基于时间恢复
点赞
收藏

51CTO技术栈公众号