NBU升級(jí)761后，DB2備份速度相互影響

rand1985

各位大蝦好：
     請(qǐng)教一個(gè)問(wèn)題：
     環(huán)境：
     當(dāng)前的備份環(huán)境，NBU matser server 是7.6.1版本，media server都是7.1.0.2，client都是7.1.0.2。
     問(wèn)題：
     前段時(shí)間master server是先做遷移，再做升級(jí)（master server換了一臺(tái)服務(wù)器，先以7.1.0.2版本遷移過(guò)來(lái)，再?gòu)?.1.0.2升級(jí)到7.6.1） 。
     升級(jí)完成后，在運(yùn)行期間，發(fā)現(xiàn)有DB2數(shù)據(jù)庫(kù)備份相互影響（目前看到是這樣的情況）：
     當(dāng)前的環(huán)境中有一個(gè)比較大的DB2數(shù)據(jù)庫(kù)，有4.6TB,這個(gè)客戶端使用單獨(dú)的media server（此media server上只有很少的幾臺(tái)client，數(shù)據(jù)量很�。�。在此client執(zhí)行備份的時(shí)候，只要有其他的作業(yè)運(yùn)行，此client的備份速度下降的就很很厲害只有平時(shí)正常速度的三分之一左右，而且其他的DB2數(shù)據(jù)庫(kù)的備份速度也會(huì)受到影響，速度都會(huì)下降（其他的client 使用是不其他的存儲(chǔ)單元）。
     目前的數(shù)據(jù)都是使用虛擬帶庫(kù)備份，備份數(shù)據(jù)落虛擬帶庫(kù)，在白天做vault，將數(shù)據(jù)復(fù)制到物理帶庫(kù)上。但是，又發(fā)現(xiàn)，在做vault的時(shí)候，竟然也影響此client的備份。（vault使用的存儲(chǔ)單元是master server的存儲(chǔ)單元）。
    此客戶端使用的media server和master server只是在相同的一個(gè)網(wǎng)段，而且每個(gè)media server 是用的虛擬帶機(jī)都是獨(dú)占的，非共享的。


      在這里請(qǐng)教各位，這是一個(gè)什么原因？有什么好的解決方法么？


      備注：
       將此client改成media server的方法因?yàn)槠渌�原�?目前沒(méi)法施行。

rtm009

建議升級(jí)到最新版 最新的版本號(hào)是7.7.2了 最好是版本一致 要不然類似的問(wèn)題不可避免！

rand1985

回復(fù) 2# rtm009


    那找個(gè)時(shí)間  將版本統(tǒng)一了！  
     可是只要只有這個(gè)client備份作業(yè)自己運(yùn)行的時(shí)候，備份速度還蠻高的 97MB/s。很是妖異！

rtm009

回復(fù) 3# rand1985


    這個(gè)問(wèn)題不奇怪 帶寬是死的 同時(shí)備份 自然會(huì)協(xié)商帶寬的問(wèn)題！只要單個(gè)任務(wù)沒(méi)事兒 其它就不要太介意了

rand1985

回復(fù) 4# rtm009

  問(wèn)題是以前在7.1.0.2版本的時(shí)候 同時(shí)進(jìn)行沒(méi)關(guān)系。速度都能跑到最高！


   

rtm009

回復(fù) 5# rand1985


    那就只能升級(jí)到統(tǒng)一版本 試試看了

rand1985

問(wèn)題已經(jīng)查清楚了，其實(shí)這個(gè)問(wèn)題也很傻的
1、在原來(lái)的環(huán)境中，NBU的master server和media server是在不同的物理服務(wù)器上。在master server遷移以后，新的master server和media server在同一個(gè)物理服務(wù)器上，這樣，使用的是同一塊網(wǎng)卡。造成現(xiàn)在的網(wǎng)卡流量堵塞。
2、改造計(jì)劃就是講這兩臺(tái)client 改造成media server （本計(jì)劃做成app_cluster）。當(dāng)然了，光纖卡什么的該加的還是要加上的。