辰风的专栏--Oracle/ClearCase管理员日记

Welcome to chenfeng's Blog(Oracle,ClearCase and Life)

RMAN备份慢故障处理一例

     今天接到上海TAC电话,报告说最近一周的RMAN备份速度很慢, 数据量很小,但做一次增量备份大概需要3天。

数据库版本:Oracle9204 RAC

操作系统版本:Solaris 9

RMAN备份语句为:
RMAN> run{
allocate channel c1 type disk;
backup incremental level 1 database plus archivelog delete input;
release channel c1;
}

登陆CATALOG数据库所在的服务器,查看备份日志:

allocated channel: c1
channel c1: sid=48 devtype=DISK

allocated channel: c2
channel c2: sid=46 devtype=DISK

Starting backup at 2007-09-18:04:21:08

发现一直停在这一步,不往下进行.....


登陆目标数据库,查看会话有哪些等待事件:

SQL> select event,sid,p1,p2,p3 from v$session_wait where event not like 'SQL*%' AND event not like 'rdbms%';

EVENT                                                                   SID         P1         P2         P3
---------------------------------------------------------------- ---------- ---------- ---------- ----------
pmon timer                                                               1        300          0          0
ges remote message                                                       4         32          0          0
gcs remote message                                                       5         64          0          0
gcs remote message                                                       7         64          0          0
log switch/archive                                                      22          2          0          0
wakeup time manager                                                     15          0          0          0
smon timer                                                              12        300          0          0

7 rows selected.


发现SID为22的会话等待最严重,等待事件为log switch/archive,这个等待事件出现时通常是因为日志组循环写满以后,第一个日志归档尚未完成,出现该等待可能是IO存在问题。
解决办法:
移动归档文件到快速的磁盘;
调整log_archive_max_processes.


查会话22对应的SQL语句:
SQL> select sql_text from v$sqltext a where a.hash_value=(select sql_hash_value from v$session b
2 where b.sid='22') order by piece asc;

SQL_TEXT
----------------------------------------------------------------
alter system archive log current

分别在两节点上手工执行这个命令,果然很慢,等了几个小时都没结果返回。

去掉RMAN备份语句中的plus archivelog delete input命令,做一次测试。
RMAN> run{
allocate channel c1 type disk;
backup incremental level 1 database;
release channel c1;
}

2分钟执行完毕,说明正是由于归档当前日志慢导致的,应该是归档日志所在的磁盘I/O存在问题。

登陆数据库,查看归档路径:
SQL> show parameter archive_dest

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest string
log_archive_dest_1 string LOCATION=/export/home/oracle/dev/MSP/log_archive_dest_1
log_archive_dest_10 string
log_archive_dest_2 string LOCATION=/export/home/oracle/dev/MSP/log_archive_dest_2
log_archive_dest_3 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_dest_6 string
log_archive_dest_7 string
log_archive_dest_8 string
log_archive_dest_9 string
log_archive_dest_state_1 string enable
log_archive_dest_state_10 string enable
log_archive_dest_state_2 string enable
log_archive_dest_state_3 string enable
log_archive_dest_state_4 string enable
log_archive_dest_state_5 string enable
log_archive_dest_state_6 string enable
log_archive_dest_state_7 string enable
log_archive_dest_state_8 string enable
log_archive_dest_state_9 string enable
standby_archive_dest string ?/dbs/arch

SQL> show parameter log_archive_max_processes
log_archive_max_processes integer 1

测试两个归档路径卷的速率,结果显示1秒钟大约写1M左右,这个速度够慢,正常应该写10M左右。

修改初始化参数,将归档日志路径修改到本地磁盘/var/backup下,并增加log_archive_max_processes=2,重启数据库后,手工执行alter system archive log current,很快返回结果; 进行RMAN测试,备份很快。

结论:正是由于归档日志对应的磁盘I/O读写存在问题导致RMAN备份异常的慢。 

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/cn_chenfeng/article/details/1822107
个人分类: oracle技术
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭