關於提高Oracle數據庫性能的四個誤區

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