oracle優化心得

2021-06-15 21:36:14 字數 4653 閱讀 2087

資料庫優化oracle9i

很多的時侯,做oracle dba的我們,當應用管理員向我們通告現在應用很慢、資料庫很慢的時侯,我們到資料庫時做幾個示例的select也發現同樣的問題時,有些時侯我們會無從下手,因為我們認為資料庫的各種命種率都是滿足oracle文件的建議。實際上如今的優化己經向優化等待(waits)轉型了,實際中效能優化最根本的出現點也都集中在io,這是影響效能最主要的方面,由系統中的等待去發現oracle庫中的不足、作業系統某些資源利用的不合理是乙個比較好的辦法,下面把我的一點實踐經驗與大家分享一下,本文測重於unix環境。

一、通過作業系統的一些工具檢查系統的狀態,比如cpu、記憶體、交換、磁碟的利用率,根據經驗或與系統正常時的狀態相比對,有時系統表面上看起來看空閒這也可能不是乙個正常的狀態,因為cpu可能正等待io的完成。除此之外我們還應觀注那些占用系統資源(cpu、記憶體)的程序。

1、如何檢查作業系統是否存在io的問題?使用的工具有sar,這是乙個比較通用的工具。

rp1#sar -u 2 10

即每隔2秒檢察一次,共執行20次,當然這些都由你決定了。

示例返回:

hp-ux hpn2 b.11.00 u 9000/800 08/05/03

18:26:32 %usr %sys %wio %idle

注:我在redhat下檢視是這種結果,不知%system就是所謂的%wio

linux 2.4.21-20.elsmp (yy075)   05/19/2005

10:36:07 am       cpu     %user     %nice   %system     %idle

10:36:09 am       all      0.00      0.00      0.13     99.87

10:36:11 am       all      0.00      0.00      0.00    100.00

10:36:13 am       all      0.25      0.00      0.25     99.49

10:36:15 am       all      0.13      0.00      0.13     99.75

10:36:17 am       all      0.00      0.00      0.00    100.00

10:36:17 am       cpu     %user     %nice   %system     %idle

10:36:19 am       all      0.00      0.00      0.00    100.00

10:36:21 am       all      0.00      0.00      0.00    100.00

10:36:23 am       all      0.00      0.00      0.00    100.00

10:36:25 am       all      0.00      0.00      0.00    100.00

其中的%usr指的是使用者程序使用的cpu資源的百分比,%sys指的是系統資源使用cpu資源的百分比,%wio指的是等待io完成的百分比,這是值得我們觀注的一項,%idle即空閒的百分比。如果wio列的值很大,如在35%以上,說明你的系統的io存在瓶頸,你的cpu花費了很大的時間去等待io的完成。idle很**明系統cpu很忙。像我的這個示例,可以看到wio平均值為11說明io沒什麼特別的問題,而我的idle值為零,說明我的cpu已經滿負荷執行了。

當你的系統存在io的問題,可以從以下幾個方面解決

*聯絡相應的作業系統的技術支援對這方面進行優化,比如hp-ux在劃定卷組時的條帶化等方面。

*查詢oracle中不合理的sql語句,對其進行優化

*對oracle中訪問量頻繁的表除合理建索引外,再就是把這些表分表空間存放以免訪問上產生熱點,再有就是對錶合理分割槽。

2、關注一下記憶體。

常用的工具便是vmstat,對於hp-unix來說可以用glance,aix來說可以用topas,當你發現vmstat中pi列非零,memory中的free列的值很小,glance,topas中記憶體的利用率多於80%時,這時說明你的記憶體方面應該調節一下了,方法大體有以下幾項。

*劃給oracle使用的記憶體不要超過系統記憶體的1/2,一般保在系統記憶體的40%為益。

為系統增加記憶體

*如果你的連線特別多,可以使用mts的方式

*打全補丁,防止記憶體漏洞。

3、如何找到點用係用資源特別大的oracle的session及其執行的語句。

hp-unix可以用glance,top

ibm aix可以用topas

此外可以使用ps的命令。

通過這些程式我們可以找到點用系統資源特別大的這些程序的程序號,我們就可以通過以下的sql語句發現這個pid正在執行哪個sql,這個sql最好在pl/sql developer,toad等軟體中執行, 把<>中的spid換成你的spid就可以了。

select a.username,a.machine,a.program,a.sid,a.serial#,a.status,c.piece,c.sql_text from v$session a,v$process b,v$sqltext c where b.spid='orcl' and b.addr=a.paddr and a.sql_address=c.address(+)order by c.piece

我們就可以把得到的這個sql分析一下,看一下它的執行計畫是否走索引,對其優化避免全表掃瞄,以減少io等待,從而加快語句的執行速度。

比如:select col1,col2,col3 from table1 a

where a.col1 not in (select col1 from table2)

可以換成:

select col1,col2,col3 from table1 a

where not exists

(select 'x' from table2 b

where a.col1=b.col1)

4、另乙個有用的指令碼:查詢前十條效能差的sql.

select * from (select parsing_user_id,executions,sorts,command_type,disk_reads,sql_text from v$sqlarea

order by disk_reads desc )where rownum<10 ;

指令碼說明:檢視佔io較大的正在執行的session

select se.sid,se.serial#,pr.spid,se.username,se.status,se.terminal,se.program,se.module,

se.sql_address,st.event,st.p1text,si.physical_reads,si.block_changes from v$session se,

v$session_wait st,v$sess_io si,v$process pr

where st.sid=se.sid and st.sid=si.sid

and se.paddr=pr.addr

and se.sid>6

and st.wait_time=0

and st.event not like '%sql%'

order by physical_reads desc

對檢索出的結果的幾點說明:

1、我是按每個正在等待的session已經發生的物理讀排的序,因為它與實際的io相關。

2、你可以看一下這些等待的程序都在忙什麼,語句是否合理?

select sql_address from v$session where sid=;

select * from v$sqltext where address=;

執行以上兩個語句便可以得到這個session的語句。

你也以用alter system kill session 'sid,serial#';把這個session殺掉。

3、應觀注一下event這列,這是我們調優的關鍵一列,下面對常出現的event做以簡要的說明:

a、buffer busy waits,free buffer waits這兩個引數所標識是dbwr是否夠用的問題,與io很大相關的,當v$session_wait中的free buffer wait的條目很小或沒有的時侯,說明你的系統的dbwr程序決對夠用,不用調整;free buffer wait的條目很多,你的系統感覺起來一定很慢,這時說明你的dbwr已經不夠用了,它產生的wio已經成為你的資料庫效能的瓶頸,這時的解決辦法如下:

a.1增加寫程序,同時要調整db_block_lru_latches引數

示例:修改或新增如下兩個引數

db_writer_processes=4

db_block_lru_latches=8

a、2開非同步io,ibm這方面簡單得多,hp則麻煩一些,可以與hp工程師聯絡。

b、db file sequential read,指的是順序讀,即全表掃瞄,這也是我們應該儘量減少的部分,解決方法就是使用索引、sql調優,同時可以增大db_file_multiblock_read_count這個引數。

c、db file scattered read,這個引數指的是通過索引來讀取,同樣可以通過增加db_file_multiblock_read_count這個引數來提高效能。

d、latch free,與栓相關的了,需要專門調節。

e、其他引數可以不特別觀注。

Oracle 資料庫優化實戰心得總結

1.優化應用程式和業務邏輯,這個是最重要的。2.資料庫設計階段正規化和反正規化的靈活應用。一般情況下,對於頻繁訪問但是不頻繁修改的資料,內部設計應當物理不規範化 對於頻繁修改但並不頻繁訪問的資料,內部設計應當物理規範化。3.充分利用記憶體,優化sga pga等 11g已經實現了sga pga自動化,...

mysql 優化心得

mysql的優花其實是個艱難的工作,要搞的東西太多了,之前在 中摘了一些原則,最近對乙個100多萬條資料的表做優花時,有如下心得 1 取必須要用的資料 這裡對於select 語句中只選有用的字段,這樣的原則就肯定人人都知道的了。但關鍵的是,要從全域性考慮問題,比如我的這個應用 是每個新聞網頁的跟帖,...

hive優化心得

limit 限制調整 因為使用 limit 語句時候,是先執行整個查詢語句,然後再返回部分結果的 set hive.limit.optimize.enable true set hive.limit.row.max.size 10000 set hive.limit.optimize.limit.f...