統(tǒng)計(jì)下，大家雙機(jī)同步速度

hanyu

我這邊 oms 雙機(jī)同步速度極慢，在備份機(jī)追得速度 不超過 千萬 Trns/Hr ，季度結(jié)息追數(shù)據(jù)要從0點(diǎn)做到17點(diǎn)。
主要慢在 Router 上了，配了3個(gè)apply job,備機(jī)cpu占用不超過 15%

環(huán)境是 i570 4路 ，oms V8.2

大家雙機(jī)同步的速度是多少？

fairyboy

目前公司只有一臺(tái)。

blogliou

暈, OMS速度也這么慢啊?

象Mimix, OMS,這類ISV提供的HA產(chǎn)品都是基于Journal, 需要傳送大量日志, 碰到爆發(fā)性的日志增加(如結(jié)息), 可能難以克服速度的瓶頸

blogliou

IBM提供HA XSM 是基于IASP和Cluster, 機(jī)制不一樣,
有沒有人做過XSM的速度測(cè)試?

[ 本帖最后由 blogliou 于 2009-4-1 11:27 編輯 ]

hanyu

IASP 就一套數(shù)據(jù)，切換其實(shí)更讓人放心些，只要數(shù)據(jù)庫能起來就行了，只是切換速度主要取決于文件的多少和數(shù)據(jù)量大小了。
當(dāng)然我們這個(gè) oms也太慢了，跟以前640機(jī)器差不多。

blogliou

有兩種的solution:

一種是可切換的IASP, 就是一個(gè)IASP在兩個(gè)系統(tǒng)之間切換, 不存在數(shù)據(jù)傳送.這正是Hanyu所說的.

還有一種就是bjtzh實(shí)施的XSM方案, XSM就是Cross-site Mirror, 此類方案需要有兩個(gè)IASP, 也就存在數(shù)據(jù)傳輸, 但是數(shù)據(jù)是直接在IASP之間通過cluster service傳輸?shù)?

qingzhou

如果同步的數(shù)據(jù)處于密集型，比如業(yè)務(wù)處于月結(jié)或數(shù)據(jù)清理，備機(jī)Apply每小時(shí)不超過千萬journal Entries是很正常的。

adversa

OMS沒用過。。偶用的MIMIX。。。4個(gè)DG, 5個(gè)app session，用MIMIX時(shí)間不長(zhǎng)，同步速度還湊合...（同城）
感覺一定要非常熟悉應(yīng)用系統(tǒng) exclude不必要的，還有就是一定要逼著應(yīng)用部門做application的 housekeeping ，不然多大的帶寬都不夠...

oldv

我們每逢月結(jié)季結(jié)oms就追不上，慢。

感覺oms做得還不是很好。有時(shí)候一些生產(chǎn)機(jī)的臨時(shí)目標(biāo)在災(zāi)備機(jī)沒有產(chǎn)生，結(jié)果整個(gè)數(shù)據(jù)都堵在那了。

hanyu

能 exclude的都做了，
請(qǐng)教 application的 housekeeping  是起什么作用
帶寬不是問題。
生產(chǎn)機(jī)的臨時(shí)目標(biāo)在災(zāi)備機(jī)沒有產(chǎn)生，是不是多成員的，根據(jù)經(jīng)驗(yàn)，這類臨時(shí)目標(biāo)是應(yīng)該exclude的。
我看到的現(xiàn)象其實(shí)不是  apply慢了，是route 的分發(fā)慢了。
大家用 oms有這個(gè)問題嗎？