oracle 10g RAC的寫性能問題

azzz

前幾天做了一個oracle 10g RAC，測試其擴(kuò)展節(jié)點后的性能變化，發(fā)現(xiàn)讀性能吞吐量從1到3節(jié)點遞增，但是insert和update的性能吞吐量都下降了，誰能幫忙分析一下原因。

環(huán)境：
SUNV20Z x3
公網(wǎng)連接速度100M
私網(wǎng)連接速度1000M
存儲為san環(huán)境，使用sun3510和sanbox5200 switch

用例：
使用insert命令向一個400萬行的表里循環(huán)插入數(shù)據(jù)。


測試策略：
并發(fā)用戶量從1遞增，最大到500，每2秒增加2個用戶。

blue_stone

select沒有鎖操作
insert update都需要對表加鎖， 加鎖需要多個實例配合完成, 相比單個實例，需要更長的時間
沒有做過這方面的分析，僅供參考

numenhuang

原帖由 azzz 于 2006-9-8 16:49 發(fā)表
前幾天做了一個oracle 10g RAC，測試其擴(kuò)展節(jié)點后的性能變化，發(fā)現(xiàn)讀性能吞吐量從1到3節(jié)點遞增，但是insert和update的性能吞吐量都下降了，誰能幫忙分析一下原因。

環(huán)境：
SUNV20Z x3
公網(wǎng)連接速度100M
私網(wǎng) ...

個人認(rèn)為Oracle RAC主要著重點還是High Availability，側(cè)重于failover，對于RAC中通過設(shè)置service，F(xiàn)AN，Cache Fusion機(jī)制來Load Balance，這一點是有一定要求的。前不久有同事參加了Oracle北京的RAC培訓(xùn)，從培訓(xùn)文檔中這一點也提到了，但是很可惜的是，在Oracle的官方文檔中，都沒有提到。對于OLTP應(yīng)用，RAC帶來的性能提升是有限的，特別對于頻繁的insert，update應(yīng)用來說，性能基本沒有提升，而且節(jié)點的增加，反而會帶來鎖的問題，畢竟cache fusion，service在多個節(jié)點上的分布，都會帶來鎖的問題。我們自己也用2臺SUN v240＋SUN 3510FC搭建了一個測試環(huán)境，對于insert，update性能的提升基本不大。但是其High Availability真的不錯，還可以避免采用Advanced Replication帶來的數(shù)據(jù)同步問題。