爲了提高性能,我們針對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的資源而做的.
而事務處理中,往往有很多併發用戶,他們爭用共用資源,所以你想辦法讓一個用戶佔用所有的資源是適得其反.
以上就是我對Oracle性能的一些常見解決方案的學習理解,希望能幫助大家對這些專題形成正確的理解.