進行dp備份的檢查過程中，發現一個備份session出現報錯，示例如下：

[Warning] From:BSM@gd-bak02″gd_rac_arch” Time: 2006-12-30 2:00:06

[61:2013] Some of the backup devices are occupied. Session is waiting

for all the devices to get free.

[Critical] From:BSM@gd-bak02″gd_rac_arch” Time: 2006-12-30 3:00:33

[61:2015] Timeout waiting for the devices to get free.

The session will terminate.

[Critical] From:BSM@gd-bak02″gd_rac_arch” Time: 2006-12-30 3:01:09

None of the Disk Agents completed successfully.

Session has failed.

[Normal] From:BSM@gd-bak02″gd_rac_arch” Time: 2006-12-30 3:01:09

Backup Statistics:

Session Queuing Time (hours) 1.02

—————————————-

Completed Disk Agents …….. 0

Failed Disk Agents ……….. 0

Aborted Disk Agents ………. 0

—————————————-

Disk Agents Total ……….. 0

========================================

Completed Media Agents ……. 0

Failed Media Agents ………. 0

Aborted Media Agents ……… 0

—————————————-

Media Agents Total ………. 0

========================================

Mbytes Total …………….. 0 MB

Used Media Total …………. 0

Disk Agent Errors Total …… 0

報錯的內容不多，但是從report中可以看到從2006-12-30 2:00:06開始該session就在等待，一直到2006-12-30 3:01:09 發生time out。

核查其具體原因，發現這個session是做數據庫的archive備份，從每天凌晨2點開始，每隔4小時做一次備份，做備份時用2個driver進行備份。而恰恰在昨天，也正好是數據庫全備的時間（每周二，五的凌晨0：30開始備份），數據庫全備用4個driver進行。

于是發生了剛剛的報錯情況：2006年12月30日0：30分開始數據庫全備，用MSL6000帶庫的所有driver（4個driver）進行數據庫全備，通過檢查其全備日志發現是耗時3個小時，在3：30分的時候結束，而arch日志在2點進行備份時候，沒有driver可用，因此一直等待，直到1小時后time out。

解決方法：

由于archive備份一般需要10分鐘完成，數據庫全備需要3小時可以完成。為保證數據庫全備的速度，仍保持其使用4個driver，且保持其原來是起始時間不便（0：30開始）。修改archive日志備份的策略，改每天的4點開始，每隔4小時備份一次，最后一次的備份時間為23：30。

注意，假如report內容較多，搜索Critical會發現比較重要的告警信息。