為了提高性能,我們針對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後問題就會更大,
