1. 程式人生 > >Oracle10g資料庫優化實用心得小結

Oracle10g資料庫優化實用心得小結

  很多的時侯,做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 [email protected]#[email protected]# AND b.addr=a.paddr AND a.sql_address=c.address(+)order BY c.piece

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

  提示:我在做優化sql時,經常碰到使用in的語句,這時我們一定要用exists把它給換掉,因為Oracle在處理In時是按Or的方式做的,即使使用了索引也會很慢。

  比如:

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 @#[email protected]# 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 ;

  二、迅速發現Oracle Server的效能問題的成因,我們可以求助於v$session_wait這個檢視,看系統的這些session在等什麼,使用了多少的IO。以下是我提供的參考指令碼:

  指令碼說明:檢視佔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調優實踐帶來幫助。

相關推薦

Oracle10g資料庫優化實用心得小結

  很多的時侯,做Oracle DBA的我們,當應用管理員向我們通告現在應用很慢、資料庫很慢的時侯,我們到資料庫時做幾個示例的Select也發現同樣的問題時,有些時侯我們會無從 下手,因為我們認為資料庫的各種命種率都是滿足Oracle文件的建議。實際上如今的優化己經向優化等待

mysql資料庫優化總結(心得)

1. 優化你的MySQL查詢快取在MySQL伺服器上進行查詢,可以啟用高速查詢快取。讓資料庫引擎在後臺悄悄的處理是提高效能的最有效方法之一。當同一個查詢被執行多次時,如果結果是從快取中提取,那是相當快的。但主要的問題是,它是那麼容易被隱藏起來以至於我們大多數程式設計師會忽略

mysql資料庫優化小結

一、常見資料庫的優化操作 1、表的設計要符合三正規化。 2、新增適當的索引,索引對查詢速度影響很大,必須新增索引。主鍵索引,唯一索引,普通索引,全文索引 3、新增適當儲存過程,觸發器,事務等。 4、讀寫分離(主從資料庫) 5、對sql語句的一些優化,(查詢執行速度比較慢的sql語

資料庫優化設計(非常實用

一、樹型關係的資料表        不少程式設計師在進行資料庫設計的時候都遇到過樹型關係的資料,例如常見的類別表,即一個大類,下面有若干個子類,某些子類又有子類這樣的情況。當類別不確定,使用者希望可以在任意類別下新增新的子類,或者刪除某個類別和其下的所有子類,而且預計以後其

MySQL資料庫優化心得

       選擇適當的欄位型別,特別是主鍵   選擇欄位的一般原則是保小不保大,能用佔用位元組小的欄位就不用大欄位。比如主鍵, 我們強烈建議用自增型別,不用guid,為什麼?省空間啊?空間是什麼?空間就是效率!按4個位元組和按32個位元組定位一條記錄,誰快誰慢太明顯了。涉及到 幾個表做join時,效果就

資料庫優化策略小結

一、資料型別的優化 (1)MySQL資料型別 整數型別: TinyInt,儲存空間8, 位元組長度1; SmallInt, 儲存空間16, 位元組長度2; MediumInt,儲存空間

前端布局心得小結

樣式 很多 思路 很快 需要 就會 view nbsp 以及 從事前端一年多了,更多的在弄一些布局,寫一些交互, 學一些後臺,時至今日,我已經慢慢有了很多經驗了,接下來主要分享一下自己的布局心得。 布局這個事,其實很簡單,就是簡單的布局以及寫一些交互,當然交互的種類很多

1300多萬條數據30G論壇大數據優化實戰經驗小結

用戶反饋 文章 千萬 身體 分析器 png 監視 重點 border 最近由於某大型網站社區論壇運行效率比較低用戶反饋論壇有些卡需要對系統進行優化,論壇性能影響了公司的形象還有網站的流量,當然這也會影響到公司的收入,而且後期還需要長期維護網站的社區論壇服務。 1:

資料庫優化SQL

sql優化規則: 1.對於查詢,儘量不要使用全表掃描,儘量在where子句以及order by所對應的欄位建立索引。 2.應儘量避免在 where 子句中對欄位進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描。   最好不要給資料庫留NULL,儘可能的使用 NOT NULL填充

mysql資料庫優化大全

資料庫優化 sql語句優化  索引優化  加快取  讀寫分離  分割槽  分散式資料庫(垂直切分)  水平切分  MyISAM和InnoDB的區別:  1. InnoDB支援事務,MyISAM不支援,對於InnoDB

SQL Server 資料庫部分常用語句小結(二)

9. 查詢備份還原資料庫的進度。 select command ,percent_complete ,est_time_to_go=convert(varchar,(estimated_completion_time/3600000))+' hour, ' +convert(varchar,(estimat

JAVA效能優化,架構師,分散式框架,高可用框架,微服務架構,資料庫優化

程式碼優化,一個很重要的課題。可能有些人覺得沒用,一些細小的地方有什麼好修改的,改與不改對於程式碼的執行效率有什麼影響呢?這個問題我是這麼考慮的,就像大海里面的鯨魚一樣,它吃一條小蝦米有用嗎?沒用,但是,吃的小蝦米一多之後,鯨魚就被餵飽了。 程式碼優化也是一樣,如果專案著眼於儘快無BUG上線,那麼此時可以抓

忍者必須死3手遊怎麼玩?分享一下我玩忍者必須死3的實用心得

忍者必須死3算是除了吃雞之外最近比較好玩的手遊了。之前看評價不錯就下載了,越玩越喜歡,給各位萌新或者即將入坑的小夥伴介紹一下忍者必須死3裡面的角色、武器選擇攻略,分享一下我的經驗心得,歡迎參考探討。   1、忍者必須死3遊戲人物角色有哪些? 小黑:新手推薦小黑。操作簡易,

mysql資料庫優化(四)-專案實戰

在flask專案中,防止隨著時間的流逝,資料庫資料越來越多,導致介面訪問資料庫速度變慢。所以自己填充資料進行測試及 mysql優化 1.插入資料: 通過指令碼,使用多程序,每100次提交資料 import multiprocessing import time from fla

資料庫優化查詢方法總結

處理百萬級以上的資料提高查詢速度的方法: 1.應儘量避免在 where 子句中使用!=或<>操作符,否則將引擎放棄使用索引而進行全表掃描。 2.對查詢進行優化,應儘量避免全表掃描,首先應考慮在 where 及 order_by 涉及的列上建立索引。 3.應儘量避免在 wh

關於資料庫優化的一些想法

優化table結構 #1 列資料型別儘量使用數字型別,避免使用字元型別,後者不僅會佔用較多儲存空間而且會降低查詢效率(逐字元比較); #2 優先使用VARCHAR,變長欄位儲存空間小,還可以提升查詢效率; #3 對需要經常作為where條件出現的column新增索引,通過新增constraint設定為u

Django - ORM 資料庫優化

目錄 一、defer 、only 查詢優化 二、事務 transaction - 原子性操作 三、choice -- 簡化不常變化的欄位 - 模型層內建立方式 - 檢視層 使用方式:物件(單).get_欄位名_display() author.get_dd_displa

大資料量高併發的資料庫優化詳解(MSSQL)

轉載自:http://www.jb51.net/article/71041.htm 如果不能設計一個合理的資料庫模型,不僅會增加客戶端和伺服器段程式的程式設計和維護的難度,而且將會影響系統實際執行的效能。所以,在一個系統開始實施之前,完備的資料庫模型的設計是必須的。 一、資料庫結構的設計 在一個系統分析、設計

資料庫優化 ------ 索引的使用問題

  最近,在工作的過程中,會時不時的碰到要不要新增索引的問題,於是結合自己的經歷,忙裡偷閒總結下,希望自已以後忘記了可以快速的記憶起來,同時也希望也可以幫助一些跟我一樣有需求的小夥伴。   一直以來,我總是不自覺的去想,到底什麼是索引?為什麼建立索引可以加快查詢的速度?直

簡單的資料庫優化

    不管用什麼樣的語言,資料庫是必不可少的,因此資料庫優化是必備的。 下面列舉幾條基本的簡單的資料庫優化,環境是php + mysql。 1.合理設定欄位屬性。 大家都知道資料庫中的表越小,在它上面執行的查詢也就會越快。因此合理設定欄位屬性,使資料庫表儘可