NBU4.5+ATL帶庫相結(jié)合來備份數(shù)據(jù)庫及數(shù)據(jù)庫歸檔日志延時(shí)問題。

007linxx

media server提交相關(guān)的備份job后在master server的狀態(tài)為queued，但是此時(shí)ATL帶庫中的driver都是可用的，并且從media server的備份日志中可以看到Veritas還沒有reserve相關(guān)的driver，也就是還沒有mount磁帶。\r\n延時(shí)一段時(shí)間后（可能是30分鐘，也可能是2個(gè)小時(shí)），該job才能開始被執(zhí)行。\r\n您碰到過這種情況嗎？

yddll

做一個(gè)數(shù)據(jù)庫備份的日志，監(jiān)控一下是rman的問題還是nbu的問題還是帶庫的問題

dooza

nbu調(diào)度程序的檢查頻率應(yīng)該不會(huì)這么長(zhǎng)，默認(rèn)為10分鐘，最小為1分鐘，這個(gè)設(shè)置在主機(jī)屬性的global屬性里的wakeup interval，就是算調(diào)度程序會(huì)每隔10分鐘檢查一次作業(yè)列表。如果你正好在這次檢查剛過時(shí)，提交了作業(yè)，那么要等到下次檢查，才會(huì)發(fā)現(xiàn)有這個(gè)作業(yè)。\r\n\r\n但的情況時(shí)間太長(zhǎng)了，可能是其他原因。不知道你的media server和master server的機(jī)器時(shí)間是否沒有問題。

TKD

我也碰到過這種問題，不過沒30分鐘這么長(zhǎng)。3、4分鐘吧。時(shí)長(zhǎng)時(shí)短的。搞不懂。

007linxx

是其中的一個(gè)用來測(cè)試的media server搗的鬼。該media server的ip地址變了，master server總是找該media server的schedul.

yddll

問題解決就好\r\n其實(shí)在腳本里加檢查點(diǎn)，然后tail一下日志，最好檢查這類問題。判斷到底是在哪兒耽誤了時(shí)間