Oracle性能優化

一.數據庫優化的方向


1.程序設計（這點最重要，如果程序本身設計有問題，再怎么進行下面的優化都是徒勞的。）
2.操作系統優化
3.硬件優化
4.數據庫優化
5.SQL語句優化


二.硬件優化


這里涉及到的硬件主要有：硬盤，內存。
1.硬盤的讀寫速度：建議增加硬盤的數量，從而增加每秒的并發操作。
2.內存大小。


三.數據庫優化


以上是Oracle 9i的體系結構，關于Oracle數據庫的優化，很大程度上圖有關。


1.根據數據庫的使用方式得出合理的優化策略


（1）OLTP：連機事務處理。


需要實時處理大量請求，而每次處請求的數據量都是很小的。OLTP是傳統的關系型數據庫的主要應用，


主要是基本的、日常的事務處理，例如銀行交易。


性能好壞的重要指標：響應時間與請求處理并發數。


（2）OLAP：聯機分析處理。


可以簡單地理解為在海量數據中得出統計/綜合信息，是數據倉庫的主要應用。做OLAP應用的數據庫，數


據量通常量非常大。和OLTP不同，OLAP應用的并發處理量是很低的，所以基本不用考慮并發問題。而在


處理數據量方面，OLAP每次操作所需要處理的數據量通常都是非常大的，這點也和OLTP相反。


性能好壞的重要指標：查詢大量數據的速度。


由于OLTP和OLAP是兩個不同應用方向，所以在優化數據庫時應采取不同的優化策略。


2.內存分配比例：2:1:1


內存分配的較佳方案：SGA占50%的物理內存，PGA和操作系統各占25%的物理內存，當然這也不是絕對的


，但是SGA占的物理內存不能超過75%，最多只能占70%，否則Oracle可能會出現各種的異常。


3.SGA中各個POOL的內存分配


（1）Shared Pool：要分配多少內存不定，只要滿足以下兩個條件即可：


-Lib Cache的命中率>98%


-Data Dictionary Cache的命中率>85%


（2）Large Pool


-專用服務器：100-200M


-共享服務器：Session * （Sort_area_size + 2）


（3）Java Pool：無需使用，一般不分配空間。


（4）Redo Log Buffer Cache：小于5M，因為它的信息非常重要，應盡快把緩存數據寫到文件中。


（5）DB_Buffer_Cache：盡量大。


4.在Oracle 10g中，如果我們定義了SGA_MAX_SIZE后，其實我們通過SGA_TARGET讓Oracle自動調整SGA的


內存分配。


5.Redo log files，Data files，Archive log files盡量放在不同的磁盤上，以均衡I/O。特別是Redo?


Log files和Archive log files。


6.Undo Segment容量大小要符合實際應用，不能太小。


7.熱點文件特殊處理


（1）分開存放Index Segment和Data Segment。


（2）使用分區表。


8.索引（Index）問題


（1）適當使用BTREE，BITMAP以及反向索引：不同索引適用于不同的表，設置索引之前要考慮這個問題


。


（2）一個表的索引數最多不要超過5個，否則可能影響性能。


（3）定期重構索引。（單邊樹索引重構時可考慮使用反向索引降低索引樹高度）


（4）注意索引是否失效，這一般是比較爛的SQL語句引起的問題。


9.盡量減少“全表掃描操作” & “排序操作”


10.看執行計劃有助于各位DBA找出性能問題。


四.SQL語句優化


1.通過v$librarycache了解命中率，這和3.1中提到的Shared Pool有關系，避免重復解析SQL語句，有助


于提高數據庫性能。
2.使用“物化視圖”提高查詢性能。
========

oracle 性能優化建議小結

平時關注Oracle數據庫的網友都知道，Oracle性能優化保證了Oracle數據庫的健壯性。下面就此提出需


要注意的兩個原則。
..原則一：注意WHERE子句中的連接順序：?
ORACLE采用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前,?


那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾.?
尤其是“主鍵ID=？”這樣的條件。?


原則二： SELECT子句中避免使用 ‘ * ‘：?
ORACLE在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意


味著將耗費更多的時間 。?


簡單地講，語句執行的時間越短越好（尤其對于系統的終端用戶來說）。而對于查詢語句，由于全表掃


描讀取的數據多，尤其是對于大型表不僅查詢速度慢，而且對磁盤IO造成大的壓力，通常都要避免，而


避免的方式通常是使用索引Index。?


使用索引的優勢與代價。
優勢：
1）索引是表的一個概念部分,用來提高檢索數據的效率，ORACLE使用了一個復雜的自平衡B-tree結構.?


通常,通過索引查詢數據比全表掃描要快. 當ORACLE找出執行查詢和Update語句的最佳路徑時, ORACLE優


化器將使用索引. 同樣在聯結多個表時使用索引也可以提高效率.
2） 另一個使用索引的好處是,它提供了主鍵(primary key)的唯一性驗證.。那些LONG或LONG RAW數據類


型, 你可以索引幾乎所有的列. 通常, 在大型表中使用索引特別有效. 當然,你也會發現, 在掃描小表時


,使用索引同樣能提高效率.
代價： 雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價. 索引需要空間來存儲,也


需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改. 這意味著每條記錄的


INSERT , DELETE , UPDATE將為此多付出4 , 5 次的磁盤I/O . 因為索引需要額外的存儲空間和處理,那


些不必要的索引反而會 使查詢反應時間變慢.。而且表越大，影響越嚴重。?


使用索引需要注意的地方：
1、避免在索引列上使用NOT ，　?
我們要避免在索引列上使用NOT, NOT會產生在和在索引列上使用函數相同的影響. 當ORACLE”遇


到”NOT,他就會停止使用索引轉而執行全表掃描.
2、避免在索引列上使用計算．?
WHERE子句中，如果索引列是函數的一部分．優化器將不使用索引而使用全表掃描． 舉例:?


代碼如下:
低效:SELECT … FROM DEPT WHERE SAL * 12 > 25000;?
高效:SELECT … FROM DEPT WHERE SAL > 25000/12;


3、避免在索引列上使用IS NULL和IS NOT NULL?
避免在索引中使用任何可以為空的列，ORACLE性能上將無法使用該索引．對于單列索引，如果列包含空


值，索引中將不存在此記錄. 對于復合索引，如果每個列都為空，索引中同樣不存在此記錄.　如果至少


有一個列不為空，則記錄存在于索引中．舉例: 如果唯一性索引建立在表的A列和B列上, 并且表中存在


一條記錄的A,B值為(123,null) , ORACLE將不接受下一條具有相同A,B值（123,null）的記錄(插入). 然


而如果所有的索引列都為空，ORACLE將認為整個鍵值為空而空不等于空. 因此你可以插入1000 條具有相


同鍵值的記錄,當然它們都是空! 因為空值不存在于索引列中,所以WHERE子句中對索引列進行空值比較將


使ORACLE停用該索引.?


代碼如下:
低效:(索引失效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;?
高效:(索引有效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;?


4、注意通配符%的影響?
使用通配符的情況下Oracle可能會停用該索引。如 :?


代碼如下:
SELECT…FROM DEPARTMENT WHERE DEPT_CODE like ‘%123456%'（無效）。?
SELECT…FROM DEPARTMENT WHERE DEPT_CODE = ‘123456'（有效）?


5、避免改變索引列的類型.:?
當比較不同數據類型的數據時, ORACLE自動對列進行簡單的類型轉換.?
假設 EMPNO是一個數值類型的索引列. SELECT … FROM EMP WHERE EMPNO = ‘123' 實際上,經過ORACLE


類型轉換, 語句轉化為: SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123') 幸運的是,類型轉換


沒有發生在索引列上,索引的用途沒有被改變. 現在,假設EMP_TYPE是一個字符類型的索引列. SELECT …?


FROM EMP WHERE EMP_TYPE = 123 這個語句被ORACLE轉換為: SELECT … FROM EMP WHERETO_NUMBER


(EMP_TYPE)=123 因為內部發生的類型轉換, 這個索引將不會被用到! 為了避免ORACLE對你的SQL進行隱


式的類型轉換, 最好把類型轉換用顯式表現出來. 注意當字符和數值比較時, ORACLE會優先轉換數值類


型到字符類型?


6、索引的一些“脾氣”?
a. 如果檢索數據量超過30%的表中記錄數.使用索引將沒有顯著的效率提高.?
b. 在特定情況下, 使用索引也許會比全表掃描慢, 但這是同一個數量級上的區別. 而通常情況下,使用


索引比全表掃描要塊幾倍乃至幾千倍!?


除了使用索引，我們還有其他能減少資源消耗的方法：


1、用EXISTS替換DISTINCT：?
當提交一個包含一對多表信息(比如部門表和雇員表)的查詢時,避免在SELECT子句中使用DISTINCT. 一般


可以考慮用EXIST替換, EXISTS 使查詢更為迅速,因為RDBMS核心模塊將在子查詢的條件一旦滿足后,立刻


返回結果.?
例子:?


代碼如下:
(低效): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E?
WHERE D.DEPT_NO = E.DEPT_NO?
And E.sex =man?
(高效): SELECT DEPT_NO,DEPT_NAME FROM DEPT D?
WHERE EXISTS?
( SELECT ‘X' FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO?
And E.sex =man?
);?


2、用(UNION)UNION ALL替換OR (適用于索引列)?
通常情況下, 用UNION替換WHERE子句中的OR將會起到較好的效果. 對索引列使用OR將造成全表掃描.?
注意, 以上規則只針對多個索引列有效. 如果有column沒有被索引, 查詢效率可能會因為你沒有選擇OR


而降低. 在下面的例子中, LOC_ID 和REGION上都建有索引.?
如果你堅持要用OR, 那就需要返回記錄最少的索引列寫在最前面.?


代碼如下:
高效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 UNION ALL?
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = “MELBOURNE”?
低效: SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION =?


“MELBOURNE”?


3、用UNION-ALL 替換UNION ( 如果有可能的話)：?
當SQL語句需要UNION兩個查詢結果集合時,這兩個結果集合會以UNION-ALL的方式被合并, 然后在輸出最


終結果前進行排序. 如果用UNION ALL替代UNION, 這樣排序就不是必要了. 效率就會因此得到提高. 需


要注意的是，UNION ALL 將重復輸出兩個結果集合中相同記錄. 因此各位還是要從業務需求分析使用


UNION ALL的可行性. UNION 將對結果集合排序,這個操作會使用到SORT_AREA_SIZE這塊內存. 對于這塊


內存的優化也是相當重要的.?
4、Order By語句加在索引列，最好是主鍵PK上。?


代碼如下:
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE（低效）?
SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_CODE （高效）?


5、避免使用耗費資源的操作:?
帶有DISTINCT,UNION,MINUS,INTERSECT的SQL語句會啟動SQL引擎 執行耗費資源的排序(SORT)功能.?


DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序. 通常, 帶有UNION, MINUS , INTERSECT


的SQL語句都可以用其他方式重寫. 如果你的數據庫的SORT_AREA_SIZE調配得好, 使用UNION , MINUS,?


INTERSECT也是可以考慮的, 畢竟它們的可讀性很強?


6、使用Where替代Having（如果可以的話）?
優化GROUP BY:?
提高GROUP BY 語句的效率, 可以通過將不需要的記錄在GROUP BY 之前過濾掉.下面兩個查詢返回相同結


果但第二個明顯就快了許多.?


代碼如下:
低效:?
SELECT JOB , AVG(SAL)?
FROM EMP GROUP JOB HAVING JOB = ‘PRESIDENT'AND AVG(SAL)>XXX?
高效:?
SELECT JOB , AVG(SAL)?
FROM EMP?
WHERE JOB = ‘PRESIDENT'?
OR JOB = ‘MANAGER' GROUP JOB Having AND AVG(SAL)>XXX?


7、通常來說，如果語句能夠避免子查詢的 使用，就盡量不用子查詢。因為子查詢的開銷是相當昂貴的


。具體的例子在后面的案例“一條SQL的優化過程”中。?
如果你還有什么有關Oracle性能提升的建議可以到網站上的論壇里交流。
========

Oracle 查詢優化的基本準則詳解

1：在進行多表關聯時，多用 Where 語句把單個表的結果集最小化，多用聚合函數匯總結果集后再與其


它表做關聯，以使結果集數據量最小化
2：在兩張表進行關聯時，應考慮可否使用右連接。以提高查詢速度
3：使用 where 而不是 having ，where是用于過濾行的，而having是用來過濾組的，因為行被分組后，


having 才能過濾組，所以盡量用戶 WHERE 過濾
4：使用 exists 而不用 IN 因為 Exists 只檢查行的存在，而 in 檢查實際值。
5：IN操作符
用 IN 寫出來的 SQL 的優點是比較容易寫及清晰易懂，這比較適合現代軟件開發的風格。
但是用 IN 的 SQL 性能總是比較低，原因是：
對于用 IN 的 SQL 語句 ORACLE 總是試圖將其轉換成多個表的連接，如果轉換不成功則先執行 IN
里面的子查詢，再查詢外層的表記錄
如果轉換成功就轉換成多個表的連接。因此 不管理怎么，用 IN 的 SQL 語句總是多了 一個轉換的
過程。一般的 SQL 都可以轉換成功。
但對于含有分組統計等方面的 SQL 就不能轉換了。因此在業務密集的SQL當中盡量不采用IN操作符。
6：NOT IN 操作符
此操作強烈推薦不使用，因為其不能應用表的索引。
如遇這種情況，應該用 EXISTS ，NOT EXISTS 或者（外連接+判斷為空）方案代替。
7：<> 操作符
不等于操作符是永遠不會用到索引的，因此對它的處理只會產生全表掃描。
對于這種情況，可以用其它方式代替，如：
A<>0 -> A>0 OR A<0
A<>'' -> A>''
8：like 操作符
遇到 需要用到 LIKE 過濾的SQL語句，完全可以用 instr 代替。處理速度將顯著提高。
9：union操作符
union在進行表鏈接后會篩選掉重復的記錄，所以在表鏈接后會對所產生的結果集進行排序運算，
刪除重復的記錄再返回結果。實際大部分應用中是不會產生重復的記錄，最常見的是過程表與歷史
表union。如：


代碼如下:
select * from gc_dfys
union
select * from ls_jg_dfys


這個SQL在運行時先取出兩個表的結果，再用排序空間進行排序刪除重復的記錄，最后返回結果集，
如果表數據量大的話可能會導致用磁盤進行排序。
推薦方案：采用union ALL操作符替代union，因為union ALL操作只是簡單的將兩個結果合并后就返回。


代碼如下:
select * from gc_dfys
union all
select * from ls_jg_dfys


10 SQL書寫的影響
同一功能同一性能不同寫法SQL的影響
如一個SQL在A程序員寫的為
select * from zl_yhjbqk
B程序員寫的為
select * from dlyx.zl_yhjbqk（帶表所有者的前綴）
C程序員寫的為
select * from DLYX.ZLYHJBQK（大寫表名）
D程序員寫的為
select * ?from DLYX.ZLYHJBQK（中間多了空格）
以上四個SQL在ORACLE分析整理之后產生的結果及執行的時間是一樣的，但是從ORACLE共享內存SGA的
原理，
可以得出ORACLE對每個SQL都會對其進行一次分析，并且占用共享內存，如果將SQL的字符串及格式寫
得完全相同則ORACLE只會分析一次，
共享內存也只會留下一次的分析結果，這不僅可以減少分析SQL的時間，而且可以減少共享內存重復的
信息，ORACLE也可以準確統計SQL的執行頻率。
11:where后面的條件順序影響
where子句后面的條件順序對大數據量表的查詢會產生直接的影響，如?


代碼如下:
select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
select * from zl_yhjbqk where xh_bz=1 ?and dy_dj = '1KV以下'


以上兩個SQL中dy_dj（電壓等級）及xh_bz（銷戶標志）兩個字段都沒進行索引，所以執行的時候都
是全表掃描，
第一條SQL的dy_dj = '1KV以下'條件在記錄集內比率為99%，而xh_bz=1的比率只為0.5%，
在進行第一條SQL的時候99%條記錄都進行dy_dj及xh_bz的比較，而在進行第二條SQL的時候0.5%條記錄
都進行dy_dj及xh_bz的比較，?
以此可以得出第二條SQL的CPU占用率明顯比第一條低。
12:詢表順序的影響
在FROM后面的表中的列表順序會對SQL執行性能影響，在沒有索引及ORACLE沒有對表進行統計分析的
情況下ORACLE會按表出現的順序進行鏈接，
由此因為表的順序不對會產生十分耗服務器資源的數據交叉。（注：如果對表進行了統計分析，
ORACLE會自動先進小表的鏈接，再進行大表的鏈接）
13:采用函數處理的字段不能利用索引，如：


復制代碼 代碼如下:
substr(hbs_bh,1,4)='5400'，優化處理：hbs_bh like ‘5400%'?
trunc(sk_rq)=trunc(sysdate)，優化處理：
sk_rq>=trunc(sysdate) and sk_rq<trunc(sysdate+1)


進行了顯式或隱式的運算的字段不能進行索引，如：


代碼如下:
ss_df+20>50，優化處理：ss_df>30
‘X'||hbs_bh>'X5400021452'，優化處理：hbs_bh>'5400021542'?
sk_rq+5=sysdate，優化處理：sk_rq=sysdate-5
hbs_bh=5401002554，優化處理：hbs_bh=' 5401002554'，注：此條件對hbs_bh 進行隱式的


to_number轉換，因為hbs_bh字段是字符型。?
條件內包括了多個本表的字段運算時不能進行索引，如：
ys_df>cx_df，無法進行優化?
qc_bh||kh_bh='5400250000'，優化處理：qc_bh='5400' and kh_bh='250000'
14:應用ORACLE的HINT（提示）處理
提示處理是在ORACLE產生的SQL分析執行路徑不滿意的情況下要用到的。它可以對SQL進行以下方
面的提示?
目標方面的提示：?
COST（按成本優化）
RULE（按規則優化）
CHOOSE（缺省）（ORACLE自動選擇成本或規則進行優化）


SELECT EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT';
ALL_ROWS（所有的行盡快返回）
SELECT EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT';
FIRST_ROWS（第一行數據盡快返回）
select *
? from xxx ?
?where xxx;
select *?
? from xxx?
?where xxx?
優化器提示：用它的目的是提高SQL語句的響應時間，快速的先返回 n 行。
訪問路徑的提示
FULL: 執行全表掃描
ROID: 根據ROWID進行掃描
INDEX: 根據某個索引進行掃描
select * from emp where deptno=200 and sal>300;
如果寫了多個，則ORACLE自動選擇最優的哪個
select * from emp where deptno=200 and sal>300;
INDEX_JOIN: 如果所選的字段都是索引字段(是幾個索引的)，那么可以通過索引連接就可訪問到數據，


而不需要訪問
表的數據。


select deptno,sal from emp
where deptno=20;?
INDEX_FFS: 執行快速全索引掃描?


select count(*) from emp;
NO_INDEX: 指定不使用哪些索引


select * from emp where deptno=200
and sal>300;
AND_EQUAL: 指定合并兩個或以上索引檢索的結果(交集)，最多不能超過5個


執行方法的提示：?
USE_NL（使用NESTED LOOPS方式聯合）?
USE_MERGE（使用MERGE join方式聯合）
USE_HASH（使用HASH join方式聯合）


根據表出現在FROM中的順序,ORDERED使ORACLE依此順序對其連接.
例如:
SELECT A.COL1,B.COL2,C.COL3 FROM TABLE1 A,TABLE2 B,TABLE3 C
WHERE A.COL1=B.COL1 AND B.COL1=C.COL1;


將指定表與嵌套的連接的行源進行連接,并把指定表作為內部表.?
例如:
SELECT BSDPTMS.DPT_NO,BSEMPMS.EMP_NO,BSEMPMS.EMP_NAM
FROM BSEMPMS,BSDPTMS WHERE BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;


將指定的表與其他行源通過合并排序連接方式連接起來.
例如:
SELECT * FROM BSEMPMS,BSDPTMS
WHERE BSEMPMS.DPT_NO=BSDPTMS.DPT_NO;


將指定的表與其他行源通過哈希連接方式連接起來.
例如:
SELECT * FROM BSEMPMS,BSDPTMS
WHERE BSEMPMS.DPT_NO=BSDPTMS.DPT_NO; ?
其它高級提示（如并行處理等等）
ORACLE的提示功能是比較強的功能，也是比較復雜的應用，并且提示只是給ORACLE執行的一個建議，?
有時如果出于成本方面的考慮ORACLE也可能不會按提示進行。根據實踐應用，一般不建議開發人員應用


ORACLE提示，
因為各個數據庫及服務器性能情況不一樣，很可能一個地方性能提升了，但另一個地方卻下降了，
ORACLE在SQL執行分析方面已經比較成熟，如果分析執行的路徑不對首先應在數據庫結構（主要是索引）


、
服務器當前性能（共享內存、磁盤文件碎片）、數據庫對象（表、索引）統計信息是否正確這幾方面分


析。


========

Oracle優化專題鏈接

http://sishuok.com/forum/blogPost/list/6413.html
2年資深DBA教你Oracle開發與優化


http://blog.itpub.net/29119536/viewspace-1138006/
oracle優化常用經典參考


http://database.51cto.com/art/201001/181249.htm
Oracle數據庫調試與性能優化 《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的oracle性能优化总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。