oracle如何提高性能 oracle性能參數(shù)優(yōu)化

Oracle數(shù)據(jù)庫系統(tǒng)性能優(yōu)化策略

一個數(shù)據(jù)庫系統(tǒng)的生命周期可以分成設計 開發(fā)和成品三個階段 在設計階段進行數(shù)據(jù)庫性能優(yōu)化的成本最低 收益最大 在成品階段進行數(shù)據(jù)庫性能優(yōu)化的成本最高 收益最小 數(shù)據(jù)庫的優(yōu)化可以通過對網(wǎng)絡 硬件 操作系統(tǒng) 數(shù)據(jù)庫參數(shù)和應用程序的優(yōu)化來進行 最常見的優(yōu)化手段就是對硬件的升級 據(jù)統(tǒng)計 對網(wǎng)絡 硬件 操作系統(tǒng) 數(shù)據(jù)庫參數(shù)進行優(yōu)化所獲得的性能提升 全部加起來只占數(shù)據(jù)庫系統(tǒng)性能提升的 %左右 其余的 %系統(tǒng)性能提升來自對應用程序的優(yōu)化 許多優(yōu)化專家認為 對應用程序的優(yōu)化可以得到 %的系統(tǒng)性能的提升

10年積累的網(wǎng)站設計制作、做網(wǎng)站經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有蘇仙免費網(wǎng)站建設讓你可以放心的選擇與我們合作。

一 數(shù)據(jù)庫性能的優(yōu)化

數(shù)據(jù)庫設計是應用程序設計的基礎 其性能直接影響應用程序的性能 數(shù)據(jù)庫性能包括存儲空間需求量的大小和查詢響應時間的長短兩個方面 為了優(yōu)化數(shù)據(jù)庫性能 需要對數(shù)據(jù)庫中的表進行規(guī)范化 規(guī)范化的范式可分為第一范式 第二范式 第三范式 BCNF范式 第四范式和第五范式 一般來說 邏輯數(shù)據(jù)庫設計會滿足規(guī)范化的前 級標準 但由于滿足第三范式的表結構容易維護且基本滿足實際應用的要求 因此 實際應用中一般都按照第三范式的標準進行規(guī)范化 但是 規(guī)范化也有缺點 由于將一個表拆分成為多個表 在查詢時需要多表連接 降低了查詢速度

由于規(guī)范化有可能導致查詢速度慢的缺點 考慮到一些應用需要較快的響應速度 在設計表時應同時考慮對某些表進行反規(guī)范化 反規(guī)范化可以采用以下幾種方法

分割表

分割表包括水平分割和垂直分割

水平分割是按照行將一個表分割為多個表 這可以提高每個表的查詢速度 但查詢 更新時要選擇不同的表 統(tǒng)計時要匯總多個表 因此應用程序會更復雜

垂直分割是對于一個列很多的表 若某些列的訪問頻率遠遠高于其它列 就可以將主鍵和這些列作為一個表 將主鍵和其它列作為另外一個表 通過減少列的寬度 增加了每個數(shù)據(jù)頁的行數(shù) 一次I/O就可以掃描更多的行 從而提高了訪問每一個表的速度 但是由于造成了多表連接 所以應該在同時查詢或更新不同分割表中的列的情況比較少的情況下使用

保留冗余列

當兩個或多個表在查詢中經(jīng)常需要連接時 可以在其中一個表上增加若干冗余的列 以避免表之間的連接過于頻繁 由于對冗余列的更新操作必須對多個表同步進行 所以一般在冗余列的數(shù)據(jù)不經(jīng)常變動的情況下使用

增加派生列

派生列是由表中的其它多個列計算所得 增加派生列可以減少統(tǒng)計運算 在數(shù)據(jù)匯總時可以大大縮短運算時間

二 應用程序性能的優(yōu)化

應用程序的優(yōu)化通?？煞譃閮蓚€方面 源代碼和SQL語句 由于涉及到對程序邏輯的改變 源代碼的優(yōu)化在時間成本和風險上代價很高 而對數(shù)據(jù)庫系統(tǒng)性能的提升收效有限 因此應用程序的優(yōu)化應著重在SQL語句的優(yōu)化 對于海量數(shù)據(jù) 劣質(zhì)SQL語句和優(yōu)質(zhì)SQL語句之間的速度差別可以達到上百倍 可見對于一個系統(tǒng)不是簡單地能實現(xiàn)其功能就行 而是要寫出高質(zhì)量的SQL語句 提高系統(tǒng)的可用性

下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹 在這些where子句中 即使某些列存在索引 但是由于編寫了劣質(zhì)的SQL 系統(tǒng)在運行該SQL語句時也不能使用該索引 而同樣使用全表掃描 這就造成了響應速度的極大降低

IS NULL 與 IS NOT NULL

不能用null作索引 任何包含null值的列都將不會被包含在索引中 即使索引有多列的情況下 只要這些列中有一列含有null 該列就會從索引中排除 也就是說如果某列存在空值 即使對該列建索引也不會提高性能

任何在where子句中使用is null或is not null的語句優(yōu)化器是不允許使用索引的

聯(lián)接列

對于有聯(lián)接的列 即使最后的聯(lián)接值為一個靜態(tài)值 優(yōu)化器不會使用索引的 例如 假定有一個職工表（employee） 對于一個職工的姓和名分成兩列存放（FIRST_NAME和LAST_NAME） 現(xiàn)在要查詢一個叫喬治？布什（Gee Bush）的職工 下面是一個采用聯(lián)接查詢的SQL語句

select * from employee where first_name|| ||last_name = Gee Bush

上面這條語句完全可以查詢出是否有Gee Bush這個員工 但是這里需要注意 系統(tǒng)優(yōu)化器對基于last_name創(chuàng)建的索引沒有使用

當采用下面這種SQL語句的編寫 Oracle系統(tǒng)就可以采用基于last_name創(chuàng)建的索引

Select * From employee where first_name = Gee and last_name = Bush

遇到下面這種情況又如何處理呢？如果一個變量（name）中存放著Gee Bush這個員工的姓名 對于這種情況我們又如何避免全程遍歷使用索引呢？可以使用一個函數(shù) 將變量name中的姓和名分開就可以了 但是有一點需要注意 這個函數(shù)是不能作用在索引列上 下面是SQL查詢腳本

select * from employee where first_name = SUBSTR（ name INSTR（ name ） ）

and last_name = SUBSTR（ name INSTR（ name ）+ ）

帶通配符（%）的like語句

同樣以上面的例子來看這種情況 目前的需求是這樣的 要求在職工表中查詢名字中包含Bush的人 可以采用如下的查詢SQL語句

select * from employee where last_name like %Bush%

這里由于通配符（%）在搜尋詞首出現(xiàn) 所以Oracle系統(tǒng)不使用last_name的索引 在很多情況下可能無法避免這種情況 但是一定要心中有底 通配符如此使用會降低查詢速度 然而當通配符出現(xiàn)在字符串其他位置時 優(yōu)化器就能利用索引 例如 在下面的查詢中索引得到了使用

select * from employee where last_name like c%

Order by語句

Order by語句決定了Oracle如何將返回的查詢結果排序 Order by語句對要排序的列沒有什么特別的限制 也可以將函數(shù)加入列中（象聯(lián)接或者附加等） 任何在Order by語句的非索引項或者有計算表達式都將降低查詢速度

仔細檢查order by語句以找出非索引項或者表達式 它們會降低性能 解決這個問題的辦法就是重寫order by語句以使用索引 也可以為所使用的列建立另外一個索引 同時應絕對避免在order by子句中使用表達式

NOT

我們在查詢時經(jīng)常在where子句使用一些邏輯表達式 如大于 小于 等于以及不等于等等 也可以使用and（與） or（或）以及not（非） NOT可用來對任何邏輯運算符號取反 下面是一個NOT子句的例子

…… where not （status = VALID ）

如果要使用NOT 則應在取反的短語前面加上括號 并在短語前面加上NOT運算符 NOT運算符包含在另外一個邏輯運算符中 這就是不等于（）運算符 換句話說 即使不在查詢where子句中顯式地加入NOT詞 NOT仍在運算符中 見下例

…… where status INVALID

再看下面這個例子

select * from employee where　salary

對這個查詢 可以改寫為不使用NOT的語句

select * from employee where　salary or salary

雖然這兩種查詢的結果一樣 但是第二種查詢方案會比第一種查詢方案更快些 第二種查詢允許Oracle對salary列使用索引 而第一種查詢則不能使用索引

IN和EXISTS

有時候會將一列和一系列值相比較 最簡單的辦法就是在where子句中使用子查詢 在where子句中可以使用兩種格式的子查詢

第一種格式是使用IN操作符 …… where column in（select * from …… where ……）

第二種格式是使用EXIST操作符 …… where exists （select X from ……where ……）

絕大多數(shù)人會使用第一種格式 因為它比較容易編寫 而實際上第二種格式要遠比第一種格式的效率高 在Oracle中可以將幾乎所有的IN操作符子查詢改寫為使用EXISTS的子查詢

第二種格式中 子查詢以 select X 開始 運用EXISTS子句不管子查詢從表中抽取什么數(shù)據(jù)它只查看where子句 這樣優(yōu)化器就不必遍歷整個表而僅根據(jù)索引就可完成工作（這里假定在where語句中使用的列存在索引） 相對于IN子句來說 EXISTS使用相連子查詢 構造起來要比IN子查詢困難一些

通過使用EXISTS Oracle系統(tǒng)會首先檢查主查詢 然后運行子查詢直到找到第一個匹配項 這就節(jié)省了時間 Oracle系統(tǒng)在執(zhí)行IN子查詢時 首先執(zhí)行子查詢 并將獲得的結果列表存放在一個加了索引的臨時表中 在執(zhí)行子查詢之前 系統(tǒng)先將主查詢掛起 待子查詢執(zhí)行完畢 存放在臨時表中以后再執(zhí)行主查詢 這也就是使用EXISTS比使用IN通常查詢速度快的原因

同時應盡可能使用NOT EXISTS來代替NOT IN 盡管二者都使用了NOT（不能使用索引而降低速度） 但NOT EXISTS要比NOT IN查詢效率更高

lishixinzhi/Article/program/Oracle/201311/17060

如何提高oracle數(shù)據(jù)庫的性能

在公路建設中，通過建立多條車道可以提高道路的流量。其實這個道理在Oracle數(shù)據(jù)庫中也行得通。即可以將關鍵數(shù)據(jù)文件存儲在多塊硬盤上，以提高Oracle數(shù)據(jù)庫的性能?？上У氖?，不少數(shù)據(jù)庫管理員沒有意識到這一點。在這篇文章中筆者就以Oracle11G為例，說明如何通過在硬盤之間分布關鍵數(shù)據(jù)文件來提高性能。 一、在硬盤之間分布關鍵數(shù)據(jù)文件的基本原則。

在傳統(tǒng)的文件系統(tǒng)上(即不是在裸機上)部署Oracle數(shù)據(jù)庫，可以通過將關鍵的數(shù)據(jù)文件分布到多個可用的文件系統(tǒng)上或者不同的硬盤上來提高數(shù)據(jù)庫的性能。具體的來說，需要遵循如下幾個原則。

一是對于表來說，往往包含兩個部分，即基本表與索引表。只要為基本表中的字段創(chuàng)建了索引，其對應的就有一張索引表。當用戶訪問表中的數(shù)據(jù)時，應用系統(tǒng)需要同時訪問到索引表與數(shù)據(jù)表。此時我們可以將這兩張表比喻成兩輛車。如果現(xiàn)在只有一個車道(即將他們同時存放在一個硬盤或者文件系統(tǒng)中)，那么兩輛車必須前后行使。而如果現(xiàn)在有兩個車道(即將基本表與其相對應的索引表存放在不同的硬盤或者文件系統(tǒng)中)，那么這兩輛車就可以并排行使。顯然，后者的效率更高。為此筆者建議，可將經(jīng)常需要訪問的表和與之對應的索引表分開來存放。

二是可以將日志文件也分開來存放。不光光是數(shù)據(jù)表與索引表存在著這種狀況。其實在日志文件管理中也是如此。只要條件允許，那么最好能夠?qū)⒙?lián)機重做日志和歸檔日志與其它數(shù)據(jù)文件存放在不同的硬盤或者文件系統(tǒng)上。因為當用戶往數(shù)據(jù)庫中寫入數(shù)據(jù)時，需要同時往數(shù)據(jù)文件與重做日志文件中寫入數(shù)據(jù)。此時如果將它們分開來存放，那么就相當于有了多條車道，分別往不同的文件中寫入數(shù)據(jù)。這無疑就可以提高數(shù)據(jù)寫入的效率，從而提高數(shù)據(jù)庫的性能。

二、哪些文件最好能夠分開存放?

在講到硬盤之間分布關鍵數(shù)據(jù)文件的基本原則的時候，筆者舉了幾個需要分開存放的幾個案例。但是在實際工作中，并不僅僅局限于上面提到的這些文件。筆者認為，如果條件允許的話，那么可以考慮將如下文件放置在不同的硬盤上。

一是表空間，如臨時表空間、系統(tǒng)表空間、UNDO表空間等等。這三個表空間可能系統(tǒng)會同時進行訪問。為此需要將其分開來存放。二是數(shù)據(jù)文件和索引文件。上面提到過，需要將經(jīng)常訪問的數(shù)據(jù)文件與其對應的索引文件存放在不同的硬盤上。因為這兩類文件在訪問數(shù)據(jù)時也可能會同時訪問到。三是操作系統(tǒng)盤與數(shù)據(jù)庫文件單獨存放。顯然Oracle系統(tǒng)肯定是與操作系統(tǒng)同時運行的。為了避免他們之間的I/Q沖突，就需要將Oracle部署在操作系統(tǒng)盤以外的磁盤上。四是聯(lián)機重做日志文件。這個文件比較復雜，不但要將其與其他文件分開來存放。而且還需要注意的是，最好能夠?qū)⑵浯娣旁谛阅茏罴训挠脖P上。

最后需要說明的一點是，增加磁盤也會增加成本。這不光光是購買磁盤所需要的花費，還包括管理的成本。所以這之間也會涉及到成本與性能之間的一個均衡問題。如果企業(yè)的數(shù)據(jù)不是很多，或者主要是涉及到查詢操作，那么這么設計的話，就可能不怎么合理。因為投入要大于回報。

三、如何確定是否需要將文件分開來存放?

在實際工作中，企業(yè)的數(shù)據(jù)是一個從少到多的過程。也就是說，剛開始使用數(shù)據(jù)庫的時候，可能數(shù)據(jù)量比較少，此時出于成本的考慮，沒有將相關文件存放在不同的磁盤上。但是隨著工作的深入，用戶會發(fā)現(xiàn)數(shù)據(jù)庫的性能在逐漸的降低。此時管理員就需要考慮，能夠采取這種多建車道的措施，來提高數(shù)據(jù)庫性能。當然在采取這個措施之前，管理員需要先進性評估。此時評估所需要用到的一個指標就是磁盤的I/O爭用。

磁盤爭用通常發(fā)生在有多個進程試圖同時訪問一個物理磁盤的情況下。如現(xiàn)在用戶需要訪問某個數(shù)據(jù)表中的數(shù)據(jù)，此時系統(tǒng)需要訪問索引文件與數(shù)據(jù)表文件。如果將它們放置在同一磁盤上，那么在訪問時就會發(fā)生I/O沖突。所以評估I/O沖突的嚴重程度，可以幫我們來確定是否需要將關鍵文件存放在不同的磁盤上。

將I/O平均的分布到多個可用的磁盤上，這可以有效的減少磁盤之間的爭用情況，提高數(shù)據(jù)存儲與讀取的性能。從而提高Oracle等應用程序的效率。在實際工作中，數(shù)據(jù)庫控制文件中有兩個參數(shù)可以用來幫助我們評估這個指標。這兩個參數(shù)是文件平均讀取時間和文件平均寫入時間。不過在使用這兩個參數(shù)的時候，其只評估所有與數(shù)據(jù)庫相關聯(lián)的文件。管理員如果有需要的話，也可以通過下面的查詢語句來查詢數(shù)據(jù)文件是否存在I/O問題。查詢的語法與結果如下圖所示：

從如上的查詢結果中可以看出某個數(shù)據(jù)文件是否繁忙，數(shù)據(jù)文件之間是否存在著/I/O沖突文件。這里需要注意的是，這個結果是一個動態(tài)的結果。在不同的時刻、用戶進行不同的操作時往往會得出不同的結論。為此筆者建議，在使用這個數(shù)據(jù)的時候，最好能夠多跟蹤幾次。然后分析多次運行的結果。只有如此，才能夠得到比較合乎情理的判斷。 通常情況下，管理員根據(jù)上面的結果可以得出三種結論。

第一種結論是上面這些數(shù)據(jù)文件都不是很忙。即文件的平均讀取時間與寫入時間都比較短，表示這兩個文件都是比較空閑的。此時正常情況下，數(shù)據(jù)庫的性能應該是不錯的。也就是說，如果此時數(shù)據(jù)庫的性能不理想的話，那么就不是磁盤的I/O所造成的。管理員應該從其他角度來改善數(shù)據(jù)庫的性能。

第二種結論是每個數(shù)據(jù)庫文件都非常的繁忙。此時有可能是讀取時間或者寫入時間比較長，或者說兩個時間都比較長。當多個數(shù)據(jù)文件同時比較繁忙并且他們處于同一磁盤的話，那么管理員就需要考慮購買新的磁盤，然后將上面提到的這些關鍵文件重新整理，讓他們部署在不同的磁盤上。

第三種結論是某幾個特定的數(shù)據(jù)文件比較繁忙，而其他數(shù)據(jù)文件還可以。此時管理員如果成本受到限制，那么也不需要重新購買硬盤。在磁盤上的物理寫入和讀取次數(shù)上如果出現(xiàn)比較大的差異，就表明某個磁盤負載過大，即有很嚴重的I/O沖突。此時最好能夠?qū)⑦@個磁盤中的文件進行調(diào)整，如將某些文件移動到另外的一塊I/O相對不怎么嚴重的磁盤上。不過在采取這個操作的時候，需要注意一點。對于聯(lián)機重做日志文件來說，即使其所在的磁盤I/O沖突比較低，或者訪問這個文件的時間比較短，但是也不建議將其他數(shù)據(jù)文件轉移到其所在的磁盤上來。因為通常情況下，為了保障數(shù)據(jù)庫的性能，我們都建議將聯(lián)機重做日志文件單獨存放，并且還需要講起放置在性能比較高的硬盤上。

總之，將關鍵的Oracle數(shù)據(jù)庫文件分開放置。如此的話可以有效避免磁盤爭用成為Oracle數(shù)據(jù)庫系統(tǒng)的性能瓶頸。

Oracle設置系統(tǒng)參數(shù)進行性能優(yōu)化

一 SGA

Shared pool tunning

Shared pool的優(yōu)化應該放在優(yōu)先考慮 因為一個cache miss在shared pool中發(fā)生比在data buffer中發(fā)生導致的成本更高 由于dictionary數(shù)據(jù)一般比library cache中的數(shù)據(jù)在內(nèi)存中保存的時間長 所以關鍵是library cache的優(yōu)化

Gets （parse）在namespace中查找對象的次數(shù)

Pins （execution）在namespace中讀取或執(zhí)行對象的次數(shù)

Reloads (reparse)在執(zhí)行階段library cache misses的次數(shù) 導致sql需要重新解析

） 檢查v$librarycache中sql area的gethitratio是否超過 ％ 如果未超過 ％ 應該檢查應用代碼 提高應用代碼的效率

Select gethitratio from v$librarycache where namespace= sql area ;

) v$librarycache中reloads/pins的比率應該小于 ％ 如果大于 ％ 應該增加參數(shù)shared_pool_size的值

Select sum(pins) executions sum(reloads) cache misses sum(reloads)/sum(pins) from v$librarycache;

reloads/pins %有兩種可能 一種是library cache空間不足 一種是sql中引用的對象不合法

）shared pool reserved size一般是shared pool size的 ％ 不能超過 ％ V$shared_pool_reserved中的request misses＝ 或沒有持續(xù)增長 或者free_memory大于shared pool reserved size的 % 表明shared pool reserved size過大 可以壓縮

）將大的匿名pl/sql代碼塊轉換成小的匿名pl/sql代碼塊調(diào)用存儲過程

）從 i開始 可以將execution plan與sql語句一起保存在library cache中 方便進行性能診斷 從v$sql_plan中可以看到execution plans

）保留大的對象在shared pool中 大的對象是造成內(nèi)存碎片的主要原因 為了騰出空間許多小對象需要移出內(nèi)存 從而影響了用戶的性能 因此需要將一些常用的大的對象保留在shared pool中 下列對象需要保留在shared pool中

a 經(jīng)常使用的存儲過程

b 經(jīng)常操作的表上的已編譯的觸發(fā)器

c Sequence 因為Sequence移出shared pool后可能產(chǎn)生號碼丟失

查找沒有保存在library cache中的大對象

Select * from v$db_object_cache where sharable_mem and

type in ( PACKAGE PROCEDURE FUNCTION PACKAGE BODY ) and kept= NO ;

將這些對象保存在library cache中

Execute dbms_shared_pool keep( package_name );

對應腳本 dbmspool sql

)查找是否存在過大的匿名pl/sql代碼塊 兩種解決方案

A．轉換成小的匿名塊調(diào)用存儲過程

B．將其保留在shared pool中

查找是否存在過大的匿名pl/sql塊

Select sql_text from v$sqlarea where mand_type= and length(sql_text) ;

）Dictionary cache的優(yōu)化

避免出現(xiàn)Dictionary cache的misses 或者misses的數(shù)量保持穩(wěn)定 只能通過調(diào)整shared_pool_size來間接調(diào)整dictionary cache的大小

Percent misses應該很低 大部分應該低于 ％ 合計應該低于 ％

Select sum(getmisses)/sum(gets) from v$rowcache;

若超過 ％ 增加shared_pool_size的值

Buffer Cache

）granule大小的設置 db_cache_size以字節(jié)為單位定義了default buffer pool的大小

如果SGA M granule= M 否則granule＝ M 即需要調(diào)整sga的時候以granule為單位增加大小 并且sga的大小應該是granule的整數(shù)倍

) 根據(jù)v$db_cache_advice調(diào)整buffer cache的大小

SELECT size_for_estimate buffers_for_estimate estd_physical_read_factor estd_physical_reads

FROM v$db_cache_advice WHERE NAME= DEFAULT AND advice_status= ON

AND block_size=(SELECT Value FROM v$parameter WHERE NAME= db_block_size );

estd_physical_read_factor=

) 統(tǒng)計buffer cache的cache hit ratio % 如果低于 ％ 可以用下列方案解決

◆增加buffer cache的值

◆使用多個buffer pool

◆Cache table

◆為 sorting and parallel reads 建獨立的buffer cache

SELECT NAME value FROM v$sysstat WHERE NAME IN ( session logical reads

physical reads physical reads direct physical reads direct(lob) );

Cache hit ratio= (physical reads physical reads direct physical reads direct (lob))/session logical reads;Select (phy value dir value lob value)/log value from v$sysstat log v$sysstat phy v$sysstat dir v$sysstat LOB where log name= session logical reads and phy name= physical reads and dir name= physical reads direct and lob name= physical reads direct (lob) ;

影響cache hit ratio的因素 全表掃描 應用設計 大表的隨機訪問 cache hits的不均衡分布

）表空間使用自動空間管理 消除了自由空間列表的需求 可以減少數(shù)據(jù)庫的競爭

其他SGA對象

）redo log buffer

對應的參數(shù)是log_buffer 缺省值與 OS相關 一般是 K 檢查v$session_wait中是否存在log buffer wait v$sysstat中是否存在redo buffer allocation retries

A 檢查是否存在log buffer wait

Select * from v$session_wait where event= log buffer wait ;

如果出現(xiàn)等待 一是可以增加log buffer的大小 也可以通過將log 文件移到訪問速度更快的磁盤來解決

B

Select name value from v$sysstat where name in

( redo buffer allocation retries redo entries )

Redo buffer allocation retries接近 小于redo entries 的 ％ 如果一直在增長 表明進程已經(jīng)不得不等待redo buffer的空間 如果Redo buffer allocation retries過大 增加log_buffer的值

C 檢查日志文件上是否存在磁盤IO競爭現(xiàn)象

Select event total_waits time_waited average_wait from v$system_event

where event like log file switch pletion% ;

如果存在競爭 可以考慮將log文件轉移到獨立的 更快的存儲設備上或增大log文件

D 檢查點的設置是否合理

檢查alert log文件中 是否存在 checkpoint not plete

Select event total_waits time_waited average_wait from v$system_event

where event like log file switch (check% ;

如果存在等待 調(diào)整log_checkpoint_interval log_checkpoint_timeout的設置

E 檢查log archiver的工作

Select event total_waits time_waited average_wait from v$system_event

where event like log file switch (arch% ;

如果存在等待 檢查保存歸檔日志的存儲設備是否已滿 增加日志文件組 調(diào)整log_archiver_max_processes

F DB_block_checksum=true 因此增加了性能負擔 （為了保證數(shù)據(jù)的一致性 oracle的寫數(shù)據(jù)的時候加一個checksum在block上 在讀數(shù)據(jù)的時候?qū)hecksum進行驗證）

）java pool

對于大的應用 java_pool_size應= M 對于一般的java存儲過程 缺省的 M已經(jīng)夠用了

）檢查是否需要調(diào)整DBWn

lishixinzhi/Article/program/Oracle/201311/17744

優(yōu)化數(shù)據(jù)庫的三板斧 大幅提高Oracle性能

幾個簡單的步驟大幅提高Oracle性能 我優(yōu)化數(shù)據(jù)庫的三板斧數(shù)據(jù)庫優(yōu)化的討論可以說是一個永恒的主題 資深的Oracle優(yōu)化人員通常會要求提出性能問題的人對數(shù)據(jù)庫做一個statspack 貼出數(shù)據(jù)庫配置等等 還有的人認為要抓出執(zhí)行最慢的語句來進行優(yōu)化 但實際情況是 提出疑問的人很可能根本不懂執(zhí)行計劃 更不要說statspack了 而我認為 數(shù)據(jù)庫優(yōu)化 應該首先從大的方面考慮 網(wǎng)絡 服務器硬件配置 操作系統(tǒng)配置 Oracle服務器配置 數(shù)據(jù)結構組織 然后才是具體的調(diào)整 實際上網(wǎng)絡 硬件等往往無法決定更換 應用程序一般也無法修改 因此應該著重從數(shù)據(jù)庫配置 數(shù)據(jù)結構上來下手 首先讓數(shù)據(jù)庫有一個良好的配置 然后再考慮具體優(yōu)化某些過慢的語句 我在給我的用戶系統(tǒng)進行優(yōu)化的過程中 總結了一些基本的 簡單易行的辦法來優(yōu)化數(shù)據(jù)庫 算是我的三板斧 呵呵 不過請注意 這些不一定普遍使用 甚至有的會有副作用 但是對OLTP系統(tǒng) 基于成本的數(shù)據(jù)庫往往行之有效 不妨試試 （注 附件是Burleson寫的用來報告數(shù)據(jù)庫性能等信息的腳本 本文用到） 一．設置合適的SGA 常常有人抱怨服務器硬件很好 但是Oracle就是很慢 很可能是內(nèi)存分配不合理造成的 ( )假設內(nèi)存有 M 這通常是小型應用 建議Oracle的SGA大約 M 其中 共享池（SHARED_POOL_SIZE）可以設置 M到 M 根據(jù)實際的用戶數(shù) 查詢等來定 數(shù)據(jù)塊緩沖區(qū)可以大致分配 M M i下需要設置DB_BLOCK_BUFFERS DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于數(shù)據(jù)塊緩沖區(qū)大小 i 下的數(shù)據(jù)緩沖區(qū)可以用db_cache_size來直接分配 ( )假設內(nèi)存有 G Oracle 的SGA可以考慮分配 M 共享池分配 M到 M 數(shù)據(jù)緩沖區(qū)分配 M到 M ( )內(nèi)存 G SGA可以考慮分配 G 共享池 M到 M 剩下的給數(shù)據(jù)塊緩沖區(qū) ( )內(nèi)存 G以上 共享池 M到 M就足夠啦 再多也沒有太大幫助 (Biti_rainy有專述)數(shù)據(jù)緩沖區(qū)是盡可能的大 但是一定要注意兩個問題 一是要給操作系統(tǒng)和其他應用留夠內(nèi)存 二是對于 位的操作系統(tǒng) Oracle的SGA有 G的限制 有的 位操作系統(tǒng)上可以突破這個限制 方法還請看Biti的大作吧 二．分析表和索引 更改優(yōu)化模式 Oracle默認優(yōu)化模式是CHOOSE 在這種情況下 如果表沒有經(jīng)過分析 經(jīng)常導致查詢使用全表掃描 而不使用索引 這通常導致磁盤I/O太多 而導致查詢很慢 如果沒有使用執(zhí)行計劃穩(wěn)定性 則應該把表和索引都分析一下 這樣可能直接會使查詢速度大幅提升 分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令 對于少于 萬的表 可以考慮分析整個表 對于很大的表 可以按百分比來分析 但是百分比不能過低 否則生成的統(tǒng)計信息可能不準確 可以通過DBA_TABLES的LAST_ANALYZED列來查看表是否經(jīng)過分析或分析時間 索引可以通過DBA_INDEXES的LAST_ANALYZED列 下面通過例子來說明分析前后的速度對比 （表CASE_GA_AJZLZ大約有 萬數(shù)據(jù) 有主鍵）首先在SQLPLUS中打開自動查詢執(zhí)行計劃功能 (第一次要執(zhí)行\(zhòng)RDBMS\ADMIN\utlxplan sql來創(chuàng)建PLAN_TABLE這個表)SQL SET AUTOTRACE ONSQLSET TIMING ON通過SET AUTOTRACE ON 來查看語句的執(zhí)行計劃 通過SET TIMING ON 來查看語句運行時間 SQL select count(*) from CASE_GA_AJZLZ;COUNT(*) 已用時間: : : Execution Plan SELECT STATEMENT Optimizer=CHOOSE SORT (AGGREGATE) TABLE ACCESS (FULL) OF CASE_GA_AJZLZ ……………………請注意上面分析中的TABLE ACCESS(FULL) 這說明該語句執(zhí)行了全表掃描 而且查詢使用了 秒 這時表還沒有經(jīng)過分析 下面我們來對該表進行分析 SQL *** yze table CASE_GA_AJZLZ pute statistics;表已分析 已用時間: : : 然后再來查詢 SQL select count(*) from CASE_GA_AJZLZ;COUNT(*) 已用時間: : : Execution Plan SELECT STATEMENT Optimizer=FIRST_ROWS (Cost= Card= ) SORT (AGGREGATE) INDEX (FAST FULL SCAN) OF PK_AJZLZ (UNIQUE) (Cost= Card= )…………………………請注意 這次時間僅僅用了 秒！這要歸功于INDEX(FAST FULL SCAN) 通過分析表 查詢使用了PK_AJZLZ索引 磁盤I/O大幅減少 速度也大幅提升！下面的實用語句可以用來生成分析某個用戶的所有表和索引 假設用戶是GAXZUSR SQL set pagesize SQL spool d:\ *** yze_tables sql;SQL select *** yze table ||owner|| ||table_name|| pute statistics; from dba_tables where owner= GAXZUSR ;SQL spool offSQL spool spool d:\ *** yze_indexes sql;SQL select *** yze index ||owner|| ||index_name|| pute statistics; from dba_indexes where owner= GAXZUSR ;SQL spool offSQL @d:\ *** yze_tables sqlSQL @d:\ *** yze_indexes sql解釋 上面的語句生成了兩個sql文件 分別分析全部的GAXZUSR的表和索引 如果需要按照百分比來分析表 可以修改一下腳本 通過上面的步驟 我們就完成了對表和索引的分析 可以測試一下速度的改進啦 建議定期運行上面的語句 尤其是數(shù)據(jù)經(jīng)過大量更新 當然 也可以通過dbms_stats來分析表和索引 更方便一些 但是我仍然習慣上面的方法 因為成功與否會直接提示出來 另外 我們可以將優(yōu)化模式進行修改 optimizer_mode值可以是RULE CHOOSE FIRST_ROWS和ALL_ROWS 對于OLTP系統(tǒng) 可以改成FIRST_ROWS 來要求查詢盡快返回結果 這樣即使不用分析 在一般情況下也可以提高查詢性能 但是表和索引經(jīng)過分析后有助于找到最合適的執(zhí)行計劃 三．設置cursor_sharing=FORCE 或SIMILAR 這種方法是 i才開始有的 oracle 不支持 通過設置該參數(shù) 可以強制共享只有文字不同的語句解釋計劃 例如下面兩條語句可以共享 SQL SELECT * FROM MYTABLE WHERE NAME= tom SQL SELECT * FROM MYTABLE WHERE NAME= turner 這個方法可以大幅降低緩沖區(qū)利用率低的問題 避免語句重新解釋 通過這個功能 可以很大程度上解決硬解析帶來的性能下降的問題 個人感覺可根據(jù)系統(tǒng)的實際情況 決定是否將該參數(shù)改成FORCE 該參數(shù)默認是exact 不過一定要注意 修改之前 必須先給ORACLE打補丁 否則改之后oracle會占用 %的CPU 無法使用 對于ORACLE i 可以設置成SIMILAR 這個設置綜合了FORCE和EXACT的優(yōu)點 不過請慎用這個功能 這個參數(shù)也可能帶來很大的負面影響！ 四．將常用的小表 索引釘在數(shù)據(jù)緩存KEEP池中 內(nèi)存上數(shù)據(jù)讀取速度遠遠比硬盤中讀取要快 據(jù)稱 內(nèi)存中數(shù)據(jù)讀的速度是硬盤的 倍！如果資源比較豐富 把常用的小的 而且經(jīng)常進行全表掃描的表給釘內(nèi)存中 當然是在好不過了 可以簡單的通過ALTER TABLE tablename CACHE來實現(xiàn) 在ORACLE i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP) 一般來說 可以考慮把 數(shù)據(jù)塊之內(nèi)的表放在keep池中 當然要根據(jù)內(nèi)存大小等因素來定 關于如何查出那些表或索引符合條件 可以使用本文提供的access sql和access_report sql 這兩個腳本是著名的Oracle專家 Burleson寫的 你也可以在讀懂了情況下根據(jù)實際情況調(diào)整一下腳本 對于索引 可以通過ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)來釘在KEEP池中 將表定在KEEP池中需要做一些準備工作 對于ORACLE i 需要設置DB_KEEP_CACHE_SIZE 對于 i 需要設置buffer_pool_keep 在 i中 還要修改db_block_lru_latches 該參數(shù)默認是 無法使用buffer_pool_keep 該參數(shù)應該比 * *CPU數(shù)量少 但是要大于 才能設置DB_KEEP_CACHE_BUFFER buffer_pool_keep從db_block_buffers中分配 因此也要小于db_block_buffers 設置好這些參數(shù)后 就可以把常用對象永久釘在內(nèi)存里 五．設置optimizer_max_permutations 對于多表連接查詢 如果采用基于成本優(yōu)化(CBO) ORACLE會計算出很多種運行方案 從中選擇出最優(yōu)方案 這個參數(shù)就是設置oracle究竟從多少種方案來選擇最優(yōu) 如果設置太大 那么計算最優(yōu)方案過程也是時間比較長的 Oracle 和 i默認是 建議改成 對于 i 已經(jīng)默認是 了 六．調(diào)整排序參數(shù) ( ) SORT_AREA_SIZE:默認的用來排序的SORT_AREA_SIZE大小是 K 通常顯得有點小 一般可以考慮設置成 M（ ） 這個參數(shù)不能設置過大 因為每個連接都要分配同樣的排序內(nèi)存 ( ) SORT_MULTIBLOCK_READ_COUNT:增大這個參數(shù)可以提高臨時表空間排序性能 該參數(shù)默認是 可以改成 來對比一下排序查詢時間變化 注意 這個參數(shù)的最大值與平臺有關系 七．調(diào)整其它幾個關鍵的性能參數(shù) 很多人認為使用oracle數(shù)據(jù)庫 系統(tǒng)的默認參數(shù)就是最好的 其實不是這樣 lishixinzhi/Article/program/Oracle/201311/16704

Oracle性能調(diào)優(yōu)思路

問 oracle進程內(nèi)存占用一直增加 達到 G左右的時候就會連接失敗 監(jiān)聽進程死掉 或者CPU達到 % 如何解決?

Peak Wong

Oracle性能調(diào)優(yōu)一直是一個很有意思的命題 增強硬件配置是一種方法 但我們平時遇到的最多的問題是如何在沒辦法增強硬件配置的情況下 將數(shù)據(jù)庫性能優(yōu)化 這里給出一個思維流程 希望對各位有益

PATCH是否都打了 ORACLE系統(tǒng)內(nèi)存參數(shù)是否太大 超出OS的MEMORY

查查是不是程序沒有關閉連接導致連接數(shù)不斷上升引起的 你是什么操作系統(tǒng)?

服務器都作了什么設置呢?比如sga的分配 是什么情況呢?

要進行調(diào)優(yōu) 及參數(shù)設置

啟動 Enterprise Management Console 以SYS/**** as SYSDBA身份進入系統(tǒng)

ORACLE i調(diào)優(yōu)只涉及如下幾個參數(shù)

a) processes = ;

b) open_links = ;

c)open_cursors = ;

d)sessions= ;

e) parallel_automatic_tuning=true

f) undo_retention=

g) undo_management=AUTO

請確保在 SPFILE 中保存 在Oracle i缺省的啟動參數(shù)是spfile 不要用pfile文件啟動數(shù)據(jù)庫

物理內(nèi)存大于 G以上的通用設置:

啟動 Enterprise Management Console 以SYS/**** as SYSDBA身份進入系統(tǒng)

配置SGA和PGA大小方法如下

物理內(nèi)存大于 G以上的通用設置

中文名 參數(shù)名 參數(shù)值 設置方法

SGA的最大大小 Sga_max_size M 例程 配置 內(nèi)存項卡

日志緩沖區(qū) Log_buffer 例程 配置 一般信息選項卡 所有初始化參數(shù)

大型池 Large_pool_size M 例程 配置 內(nèi)存項卡

Java池 Java_pool_size M 例程 配置 一般信息選項卡 所有初始化參數(shù)

共享池 Shared_pool_size M 例程 配置 內(nèi)存項卡

數(shù)據(jù)緩沖區(qū)高速緩存 Db_cache_size M 例程 配置 內(nèi)存項卡

Keep池 Db_keep_cache_size M 例程 配置 一般信息選項卡 所有初始化參數(shù)

Pga自動管理 workarea_size_policy AUTO 例程 配置 一般信息選項卡 所有初始化參數(shù)

總計pga目標 pga_aggregate_target M 例程 配置 內(nèi)存項卡

說明:

此內(nèi)存設置不包含在數(shù)據(jù)庫服務器上的其它應用程序的物理內(nèi)存的大小 如果有其它的應用程序 可以參照下面的計算: sga_max_size+ pga_aggregate_target+應用程序物理內(nèi)存+OS物理內(nèi)存 = 系統(tǒng)物理內(nèi)存* % 如果服務器上只有Oracle服務器 在 G以上物理內(nèi)存的服務器上Oracle內(nèi)存參數(shù)都可以參照上面的設置 如果服務器上有其它的應用 而服務器總的物理內(nèi)存大于 請自己計算后再選擇的方案

sga_max_size+ pga_aggregate_target = G 在 bit操作系統(tǒng)上有這個限制

lishixinzhi/Article/program/Oracle/201311/17386

如何提高oracle模糊查詢的性能？

1、使用兩邊加‘%’號的查詢，Oracle是不通過索引的，所以查詢效率很低。

例如：select count(*) from lui_user_base t where t.user_name like '%cs%';

2、like '...%'和 like'%...'雖然走了索引，但是效率依然很低。

3、有人說使用如下sql，他的效率提高了10倍，但是數(shù)據(jù)量小的時候

select count(*) from lui_user_base where rowid in (select rowid from lui_user_base t where t.user_name like '%cs%')

我拿100w跳數(shù)據(jù)做了測試，效果一般，依然很慢，原因：

select rowid from lui_user_base t where t.user_name like '%cs%' ? 這條sql執(zhí)行很快，那是相當?shù)目?，但是放到select count(*) from lui_user_base where rowid in（）里后，效率就會變的很慢了。

4、select count(*) from lui_user_base t where instr(t.user_name,'cs') 0

這種查詢效果很好，速度很快，推薦使用這種。因為我對oracle內(nèi)部機制不是很懂，只是對結果做了一個說明。

5、有人說了用全文索引，我看了，步驟挺麻煩，但是是個不錯的方法，留著備用：

對cmng_custominfo 表中的address字段做全文檢索：

1，在oracle9201中需要創(chuàng)建一個分詞的東西：

BEGIN

ctx_ddl.create_preference ('SMS_ADDRESS_LEXER', 'CHINESE_LEXER');

--ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer'); 不用

end;

2，創(chuàng)建全文檢索：

CREATE INDEX INX_CUSTOMINFO_ADDR_DOCS ON cmng_custominfo(address) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('LEXER SMS_ADDRESS_LEXER');

3，查詢時候，使用：

select * from cmng_custominfo where contains (address, '金色新城')1;

4，需要定期進行同步和優(yōu)化：

同步：根據(jù)新增記錄的文本內(nèi)容更新全文搜索的索引。

begin

ctx_ddl.sync_index('INX_CUSTOMINFO_ADDR_DOCS');

end;

優(yōu)化：根據(jù)被刪除記錄清除全文搜索索引中的垃圾

begin

ctx_ddl.optimize_index('INX_CUSTOMINFO_ADDR_DOCS', 'FAST');

end;

5，采用job做步驟4中的工作：

1)該功能需要利用oracle的JOB功能來完成

因為oracle9I默認不啟用JOB功能，所以首先需要增加ORACLE數(shù)據(jù)庫實例的JOB配置參數(shù):

job_queue_processes=5

重新啟動oracle數(shù)據(jù)庫服務和listener服務。

2)同步 和 優(yōu)化

--同步 sync:

variable jobno number;

BEGIN

DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.sync_index(''INX_CUSTOMINFO_ADDR_DOCS'');',

SYSDATE, 'SYSDATE + (1/24/4)');

commit;

END;

--優(yōu)化

variable jobno number;

begin

DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.optimize_index(''INX_CUSTOMINFO_ADDR_DOCS'',''FULL'');', SYSDATE, 'SYSDATE + 1');

commit;

END;

其中， 第一個job的SYSDATE + (1/24/4)是指每隔15分鐘同步一次，第二個job的SYSDATE + 1是每隔1天做一次全優(yōu)化。具體的時間間隔，可以根據(jù)應用的需要而定。

6，索引重建

重建索引會刪除原來的索引，重新生成索引，需要較長的時間。

重建索引語法如下：

ALTER INDEX INX_CUSTOMINFO_ADDR_DOCS REBUILD;

據(jù)網(wǎng)上一些用家的體會，oracle重建索引的速度也是比較快的，有一用家這樣描述：

Oracle 的全文檢索建立和維護索引要比ms sql server都要快得多，筆者的65萬記錄的一個表建立索引只需要20分鐘，同步一次只需要1分鐘。

因此，也可以考慮用job的辦法定期重建索引。

網(wǎng)站欄目：oracle如何提高性能 oracle性能參數(shù)優(yōu)化
地址分享：http://muchs.cn/article38/hjddsp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、商城網(wǎng)站、品牌網(wǎng)站建設、做網(wǎng)站、定制網(wǎng)站、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)