為了提高效能,我們針對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可以同時支援共用伺服器和專用伺服器模式,可以指定一個會話使用專用伺服器,另一個會話使用共用伺服器。