為了提高性能,我們針對Oracle數據庫本身提供了的方法或方案進行過不少的嘗試，主要包括:
共用伺服器模式(MTS)；
集群技術(Clustering)RAC；
分區；
並行處理(主要是並行查詢)。
Oracle提供的這些特性確實是用來進行性能改善的,但我們往往忽略了對自身應用特性的分析,它們是否適合於我們。最近,通過對這方面知識的深入了解,發現我們以前存在一些錯誤的認識。我覺得有必要,大家一起來改變這種誤解。
分析之前,先明確一下我們的應用特性。數據庫應用大體可以分為OLAP和OLTP兩大類,即:連線事務分析(數據倉庫)和連線事務處理(事務應用)我們的應用系統,其應用特性主要是連線事務處理,又包含了少量的數據倉庫特性。
1 共用伺服器(MTS)
Oracle缺省用的是專用伺服器模式,也就是說一個用戶連接進程對應一個伺服器的進程。記得某大醫院剛啟用的時候,我們曾經試過MTS。因為聽說MTS在不增加記憶體和CPU的情況下連接更多的客戶端,結果並不是我們預期的那樣。MTS有問題嗎?不是,是因為我們對MTS不了解,並不是它有問題,而是它不是用來在這種情況下做這件事的。
一般情況,只有當併發連接數超過了作業系統的支援時,才建議使用MTS,否則應該使用缺省的專用伺服器模式。也就是說,在專用伺服器模式下,因為多一個連接就要多消耗一個作業系統的進程,只有當併發應用需求超過作業系統的允許連接數時,才有必要考慮MTS。
如果現有系統,物理上支援100個連接的專用伺服器數據庫,改為使用共用伺服器模式,也許支援1000個連接,但同時活動的連接可能只有100個。一般2到4個CPU的伺服器,應對200到400個併發連接是足夠的,如果連接增加了,可以增加CPU和記憶體。
MTS具有以下一些缺點:
1、共用伺服器的代碼路徑比專用伺服器長,所以它天生就比專用伺服器慢。
2、存在人為死鎖的可能,因為它是串列的,所有共用伺服器綁定在一起(一個進程),只要一個連接阻塞,則所有用戶阻塞,並且極可能死鎖。
3、存在獨佔事務的可能,因為如果一個會話的事務運行時間過長,它獨佔共用資源,其他用戶只能等待。(而專用伺服器,每個客戶端是一個會話)
4、共用伺服器模式限制了某些數據庫特性,例如:不能單獨啟動和關閉實例,不能進行介質恢復,不能使用Log Miner,不能使用,並且SQL_TRACE沒有意義(因為是共用而不是當前會話的)。
MTS減少的記憶體實際上是專用伺服器模式下每個用戶連接到作業系統進程所需的記憶體,但它卻使用SGA的Large_Pool來分配UGA,拆東墻補西墻,所減少的記憶體是很少的。如果用戶會話的連接和斷開很頻繁,數據庫進程的創建和刪除的開銷會非常大,這種情況最好採用共用伺服器模式(否則,應該使用連接池技術)。所幸的是,我們產品的設計可能就考慮了這個因素,使用的是一次連接終身使用(會話生命週期內),避免了這種情況。
所以,綜上所述,針對我們產品,建議採用缺省的專用伺服器模式,連接不夠時,通過增加硬體解決,而不是改用MTS。另外,實際上,Oracle可以同時支援共用伺服器和專用伺服器模式,可以指定一個會話使用專用伺服器,另一個會話使用共用伺服器。
2、集群技術(RAC)
Oracle RAC(Real Application Clusters),我們說的雙機容錯就是RAC的一種。 集群技術的優勢在在於橫向擴展性能,並提供高可用性。32位的作業系統有4G記憶體的限制,有些Unix系統(以及非高級版本的Windows)有CPU個數的限制。而集群技術通過集合多台機器協同工作,橫向打破了這種限制。通過RAC,一台伺服器一個實例,多台機器構成一個實例服務集,客戶端連接到它上面。這項技術,我們有時對客戶說是負載均衡,實際上這是片面的,RAC的主要針對的是CPU和記憶體的負載均衡,並沒有實現磁片IO的負載均衡。(當然,磁片IO可以通過Raid或NAS來實現)
RAC還有一個好處是,提高了可用性,也就是說一台伺服器壞掉了(注意:不是數據存儲介質),不影響正常使用。就像負載均衡一樣,它提高了數據層以上的可用性,但不是全部,因為數據壞了,它也沒有辦法。(數據層,那是Oracle Data Guard的事了,或者乾脆說那是存儲硬體的事)
但是,RAC帶來好處的同時,也帶來了性能的影響。因為它要全局協調數據高速緩存,保證每個實例上連接的用戶看到的緩存數據是一致的,所以把以下三方面的矛盾放大:
1、高速緩存爭用。
2、過多的I/O。
3、鎖定。
也就是說,如果這些方面有問題,用了RAC後問題就會更大,例如:由於SQL沒有使用綁定變數導致高速緩存爭用,用了RAC會更嚴重。
總之,如果你的伺服器的CPU插滿了,記憶體也加到極限了,而併發用戶還在不斷增長,或者你對故障停機時間要求非常高,RAC無疑是你應該選擇的。
1
2
下一頁>>
|
