關於提高Oracle資料庫效能的四個誤區

為了提高效能,我們針對Oracle資料庫本身提供了的方法或方案進行過不少的嘗試，主要包括:

共享伺服器模式(MTS)；

叢集技術(Clustering)RAC；

分割槽；

並行處理(主要是並行查詢)。

[@more@]

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無疑是你應該選擇的。

3、分割槽

Oracle的分割槽用途在於把大的表或索引分成小的片段,以便更容易管理。我們以前可能錯誤的認為分割槽就是fast=true,可以提高速度,也在腫瘤和兒科做過這方面的試驗。實際上,在事務處理系統中,分割槽一般不能加快查詢速度(某些情況下可能會減少對共享資源的爭用)。Oracle的分割槽特性,主要是針對資料倉儲來設計的,也就是說你的某張表如果有100G的大小,最好使用分割槽,好處有以下三個方面:

1、提高可用性

分割槽的原理就是分而治之,如果一張表劃分為多個分割槽,其中一個分割槽所在的介質出了問題,不影響整個表的其它分割槽資料的訪問。

2、易於管理

在資料倉儲下,表分成小的片斷,更容易批次的刪除,碎片整理,以及一些並行處理。

3、提高效能

這方面,透過分割槽來達到是最困難的,必須經過周密的計算來安排分割槽資料。

分割槽的規劃是複雜的,拿我們產品應用來說,一般查詢涉及到多個表,多個索引,假設我們把病人費用記錄,藥品收發記錄,病人醫囑記錄這類大表建立分割槽。顯然,範圍分割槽對我們提升效能用處不大,雜湊分割槽才是我們查詢需求的,但大多數資料的雜湊又不夠集中。再加上,這些表上的索引這麼多,常用的ID,時間類索引就不少,很少有人能做到把它們全部進行全域性分割槽或準確的進行範圍分割槽(實際上可能根本無法按需求進行多個索引的範圍分割槽)。如果查詢經常涉及多個索引,如何保證用到的每個索引都在一個分割槽上,如果不是,必然掃描多個分割槽,增加邏輯I/O和CPU時間,從而增加查詢時間。(資料分佈在不同物理儲存介質的情況,在下面的並行處理中再討論)

再來看一下,某些情況下可能會減少對共享資源的爭用是指什麼,是指並行修改和更新會更快。仔細分析,我們分割槽的原則是什麼?一般最常用的可能是按時間段進行範圍分割槽,這樣,修改和更新絕大多數還是在同一個分割槽上進行,所以對減少共享資源的爭用這方面,基本沒有什麼效果。(有按科室ID進行雜湊分割槽的對應的唯一應用需求嗎?有基於列表分割槽(典型特徵值)的對應的唯一應用需求嗎?基本上沒有。)分割槽主要從並行的角度來提高效能,但事務處理系統本身應用特性決定了它不適合這種技術。也就是說,針對我們產品的事務處理應用特點,根本沒有必要採用分割槽技術。

4、並行處理

根據我們的應用特點,主要分析並行查詢。一般要求配合分割槽特性,多CPU硬體。自Oracle 8。1。6起,增加了一個自動調節並行查詢的選項:PARALLEL_AUTOMATIC_TUNING=TRUE在相應的表上設定PARALLEL引數,Oracle就會在適當的時候自動並行化該表上的操作。並行查詢對事務處理系統基本上沒有用。因為並行查詢的設計是針對資料倉儲中的單使用者完全消耗100的資源而做的。而事務處理中,往往有很多併發使用者,他們爭用共用資源,所以你想辦法讓一個使用者佔用所有的資源是適得其反。

詳細出處參考：

詳細出處參考：