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可以同時支援共用伺服器和專用伺服器模式,可以指定一個會話使用專用伺服器,另一個會話使用共用伺服器.

    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的資源而做的.而交易處理中,往往有很多並發使用者,他們爭用共用資源,所以你想辦法讓一個使用者佔用所有的資源是適得其反