9月5日,

我们的某个SAP oracle DB的备份平常大概3个半小时就结束,也就是在我上班之前备份应该结束掉.
但是我上班之后发现这个备份还没有结束,已经跑了4个多小时了.
看了看备份日志,发现有一个小时没有打出来结果,可能备份就停在那儿了,但是数据库看起来
并没有异常现象.
于是手动把所有TS一个一个从备份模式改成一般模式,发现有个TS在我敲完end backup命令之后
没有反应,从begin backup到end backup之间产生的archive log也就十几个,不应该这么慢吧.

看了session的信息,发现几个truncate table的操作,但是这些table都不属于这个TS,
找不到原因,只好等待,过了将近半个小时后,备份才结束.

9月6日,
上班之后发现这个DB的备份还是没有结束, 看了备份日志和9月5日是一样的现象,看了session信息,
发现owner为system的end backup session的状态是enqueue.
之外,还发现等待latch的一个进程, 这个进程下有好多session,都在执行以下语句:
select length from fet$ where file#=:1 and block#=:2 and ts#=:3
这个是跟碎片相关的操作,可能和该TS的coalesce操作有关.
看了系统的crontab, 发现这个时间段数据库正在执行DB所有TS的coalesce操作.
再结合这几天的alert log,发现时间上正好是一个巧合阿, 在dp 结束备份之前,
该crontab正好执行这个TS的coalesce操作, 于是end backup就等着coalesce的结束,
昨天什么也没有作,等了一定时间后备份自己结束也是跟这个有关.

现在的解决方法是两个操作避开, 我把DB 备份时间提前了两个小时.

9月7日,
上班之后,发现备份正常结束.