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的資源而做的.而事務進行中,往往有很多并發使用者,他們争用共用資源,是以你想辦法讓一個使用者占用所有的資源是适得其反