模糊搜索資料庫響應慢如何優化

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

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

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

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

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

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

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

select rowid from lui_user_base t where t.user_name like '%cs%' 這條sql執行很快，那是相當的快，但是放到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內部機制不是很懂，只是對結果做了一個說明。

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

http://sandish.itpub.net/post/4899/464369

對cmng_custominfo 表中的address欄位做全文檢索：

1，在oracle9201中需要創建一個拆緩銷分詞的東西：

BEGIN

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

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

end;

2，創建全文檢索：

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，需要定期進行同步和優化：

同步：根據新增記錄的文本內容更新全文搜索的索引。

begin

ctx_ddl.sync_index('INX_CUSTOMINFO_ADDR_DOCS');

end;

優化：根據被刪除記錄清除全文搜索索引中的垃圾

begin

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

end;

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

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

因為oracle9I默認不啟用JOB功能，所以首先需要增加ORACLE資料庫實例的JOB配置參數:

job_queue_processes=5

重新啟動oracle資料庫服務和listener服務。

2)同步 和 優化

--同步 sync:

variable jobno number;

BEGIN

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

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

commit;

END;

--優化

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天做一次全優化。具體的時間間隔，可以根據應用的需要而定。

6，索引重建

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

重建索引語法如下：

ALTER INDEX INX_CUSTOMINFO_ADDR_DOCS REBUILD;

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

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

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

Ⅱ 我用php做一個模糊搜索引擎,但是一旦mysql數據表數據多了,查詢速度就慢了,怎麼辦

1.避免使用!=或＜＞、IS NULL或IS NOT NULL、IN ，NOT IN等這樣的隱絕操作符。
2.優化SQL語句（讓SQL語句更合理一些）。
3.優化資料庫欄位類型。（能用其他凳旦的盡量不要用VCHAR）
4.建立儲存過程棗攜擾。

Ⅲ 資料庫變慢的情況及處理方法

資料庫慢一般有三種情況

逐漸變慢

突然變慢

不定時變慢

第一種情況 逐漸變慢 要建立一個長期的監控機制 比如 寫個shell腳本每天的忙時(通常 ~ etc )定時收集os neork db的信息 每個星期出report對收集到的信息進行分析 這些數據的積累 可以決定後期的優化決策 並且可以是DBA說服manager採用自己決策的重要數據 DBA的價值 就在每個星期的report中體現

第二種情況 突然變慢 也是最容易解決的 先從業務的角度看是DB的使用跟以前有何不同 然後做進一步判斷 硬體/網路故障蘆納衫通常也會引起DB性能的突然下降

第一步: 察看DB/OS/NEORK的系統log 排除硬體/網路問題

第二步 察看資料庫的等待事件 根據等待事件來判斷可能出問題的環節 如果 沒有等待事件 可以排除資料庫的問題 如果有等待時間 根據不同的等待事件 來找引起這些事件的根源

比如latch free等跟SQL parse有關系的等待事件 OS的表現是CPU 的佔用率高

db file scattered read等跟SQL disk read有關系的等待時間 OS的表現是iostat可以看到磁碟讀寫量增加

第三步: 察看os的信息 CPU/IO/MEMORY等

a Cpu 的佔用率

CPU佔用率與資料庫性能不成反比 CPU佔用率高 不能說明資料庫性能慢 通常情況 一個優化很好 而且業務量確實很大的資料庫 CPU的佔用率都會高 而且會平均分布在每個進程上 反過來 CPU的佔用率都會高也不代表資料庫性能就好 要結合資料庫的等待事件來判斷CPU佔用率高是否合理

如果某個進程的cpu佔用高 肯定是這個進程有問題 如果 不是oracle的進程 可以讓application察看是否程序有死循環等漏洞 如果 是oracle的進程 可以根據pid查找oracle數據字典看看這個進程的發起程序 正在執行的sql語句 以及等待事件 然後 不同情況使用不同的方法來解決

b IO

排除硬體的IO問題 資料庫突然變慢 一般來說 都是一個或幾個SQL語句引起的

如果IO很頻繁 可以通過優化disk reads高的TOP SQL來解決 當然這也是解決IO問題的最笨也是最有效的辦法

OS以及存儲的配置也是影響IO的一個重要的原因

比如 最常見的HP unix下非同步IO的問題 如果DBA GROUP沒有MLOCK的許可權 ORACLE是不使用AIO的 偏偏OS與DB的兩方的admin如果配合不夠好地話 這個配置就很容易給漏掉了

c Memory

第二種情況與memory的關系比較小 只要SGA區配置合理沒有變化 一般來說 只要不是Application Memory leak 不會引起突然變慢的現象

第三種情況 不定時變慢 是最難解決的 現場出現的問題原因也是五花八門千奇百怪 最重要的是 出現慢的現象時 以最快的速度抓取到最多的信息以供分析 先寫好抓取數據的shell 腳本 並在現象發生時及時按下回車鍵

一個例子

資料庫突然變慢

背景: 一個新應用上線後 數陪腔據庫突然變慢

第一步 調查新應用

據開發人員講新應用訪問的都是新建立的表 表的數據量很小 沒有復雜的SQL查詢

查詢 v$sqlarea 分別按照disk_reads / buffer_gets / executions 排序 TOP SQL 中沒有新應用的SQL 排除新應用資料庫訪問照成的性能問題

第二步 察看資料庫log/ OS log

資料庫log中可以看到大量的ORA 錯誤 以及大量的mp文件 分析mp文件(時間久了 沒有mp文件可參考 具體細節沒法描述下來 ) 發現是新應用通過dblink訪問remote DB時生成的mp文件 應用開發人說沒法修改 Oracle也沒有相應茄彎的patch解決

OS log中沒有錯誤信息

第三步 察看statspack report

從wait events中看到 Top event是 buffer busy waits db file parallel write 等於IO相關的等待事件

從buffer busy waits 的統計信息來看 是等待data block

還有些physical reads等信息與從前比沒有太多的異常

Tablespace 的IO reads/writes也沒有異常 但是wait明顯增加

初步確定是IO問題

第四步 察看OS的信息

top 命令(輸出為實驗室數據 僅作格式參考)

load averages: : :

processes: sleeping zombie stopped on cpu

CPU states: % idle % user % kernel % iowait % swap

Memory: M real M free M swap in use M swap free

PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU MAND

a K K cpu/ : % top

mpgj M K sleep : % view_server

當時現場數據顯示 iowait 值與以前相比大很多 沒有異常進程

sar –d (輸出為實驗室數據 僅作格式參考)

SunOS sc Generic_ sun u / /

: : device %busy avque r+w/s blks/s avwait avserv

sd

sd a

sd b

sd c

sd g

當時現場數據顯示 放數據文件的設備 avwait avque blks/s值偏大

第五步 察看資料庫的等待事件

一個大業務量的資料庫如果性能不好的話 一般來說都會有大量的等待事件 上百個等待事件很常見 我通常會按照EVENT進行group

Select count(*) event from v$session_wait where event not in ( *** on timer pmon timer rdbms ipc message SQL*Net message from client ) group by event order by desc;

輸出結果顯示最多的等待事件是buffer busy waits

進一步分析 找出等待的原因

Select count(*) p p p from v$session_wait where event = buffer busy waits group by p p p ;

在buffer busy waits等待事件中

P = file#

P = block#

P = id ( 此id對應為等待的原因)

按照p p p group是為了明確buffer busy waits的等待集中在哪些對象上

Metalink對buffer busy waits等待事件的描述有如下一段話

If P shows that the buffer busy wait is waiting for a block read to plete then the blocking session is likely to be waiting on an IO wait (eg: db file sequential read or db file scattered read for the same file# and block#

輸出結果顯示 等待分布在多個不同的對象上 等待原因為 waiting for a block read to plete 進一步分析為IO的問題

如果 buffer busy waits等待集中在某個對象上 說明有hot block 通過重新rebuild這個對象增加freelist來解決 RAC環境增加freelist group

通過以下SQL可以找到具體的object

Select owner segment_name segment_type from dba_extents where file_id=P and P beeen block_id and block_id+blocks;

P P 是上面v$session_wait查出的具體的值

第六步 明確原因 找出解決步驟

分析

磁碟的IO流量增加

磁碟的IO等待增加

DB的IO流量沒有增加

DB的IO等待增加

由 可以推出 有資料庫以外的IO訪問磁碟

察看磁碟配置 該VG只存放了資料庫數據文件和資料庫系統文件 排除數據文件 產生IO的是資料庫系統文件

資料庫系統文件一般來說不會產生IO 有IO讀寫的地方只有log和mp文件

結論 ora 產生的大量core mp文件堵塞IO

解決辦法

消除ora (應用不改的情況下 無法解決)

把mp目錄指向別的VG

讓oracle盡量少的去寫core mp文件

background_core_mp = partial

lishixin/Article/program/Oracle/201311/18969

Ⅳ 當查詢資料庫時，由於數據不斷增加，查詢變得越來越慢，請問有什麼方法可以優化，使查詢變快

在資料庫表中加欄位，將數據分類，比如插入時間、數據類別、包含伏罩和什麼特悶姿殊文字的字元串，都可以分類。然後可以將分類後的數據，放缺盯入其他不同的表中，這樣就可以將大數據變成小數據進行查詢了。之後加索引，加分區可能會更快。

Ⅳ 如何對資料庫性能進行優化

1.資料庫I/O方面硬體性能

最有可能影響性能的是磁碟和網路吞吐量。解決辦法：

• 擴大虛擬內存，並保證有足夠可以擴充的空間

• 把資料庫伺服器上的不必要服務關閉掉

• 把SQL資料庫伺服器的吞吐量調為最大

2.調整資料庫

• 若對該表的查詢頻率比較高，則建立索引。

• 分區（如MySQL，按時間分區）

• 盡量使用固定長度欄位和限制欄位長度（如 varchar(10)）優勢：
  降低物理存儲空間
  提高資料庫處理速度
  附帶校驗資料庫是否合法功能

3.使用存儲過程

應用程序的實現過程中，能夠採用存儲過程實現的對資料庫的操作盡量通過存儲過程來實現。

因為存儲過程是存放在資料庫伺服器上的一次性被設計、編碼、測試，並被再次使用，需要執行該任務的應用可以簡單地執行存儲過程，並且只返回結果集或者數值。

這樣不僅可以使程序模塊化，同時提高響應速度，減少網路流量，並且通過輸入參數接受輸入，使得在應用中完成邏輯的一致性實現。

4.SQL語句方面

建立查詢條件索引僅僅是提高速度的前提條件，響應速度的提高還依賴於對索引的使用。不良的SQL往往來自於不恰當的索引設計、不充份的連接條件和不可優化的where子句。

• 優化sql語句，減少比較次數

• 限制返回條目數(mysql中使用limit)

5.Java方面

• 盡可能的少創造對象

• 合理擺正系統設計的位置。大量數據操作，和少量數據操作一定是分開的。

• 合理利用內存，有的數據要緩存。讓數據流起來，而不是全部讀到內存再處理，而是邊讀取邊處理。

Ⅵ 資料庫性能優化有哪些措施

1、調整數據結構的設計

這一部分在開發信息系統之前完成，程序員需要考慮是否使用ORACLE資料庫的分區功能，對於經常訪問的資料庫表是否需要建立索引等。

2、調整應用程序結構設計

這一部分也是在開發信息系統之前完成，程序員在這一步需要考慮應用程序使用什麼樣的體系結構，是使用傳統的Client/Server兩層體系結構，還是使用Browser/Web/Database的三層體系結構。不同的應用程序體系結構要求的資料庫資源是不同的。

3、調整資料庫SQL語句

應用程序的執行最終將歸結為資料庫中的SQL語句執行，因此SQL語句的執行效率最終決定了ORACLE資料庫的性能。ORACLE公司推薦使用ORACLE語句優化器(OracleOptimizer)和行鎖管理器(row-levelmanager)來調整優化SQL語句。

4、調整伺服器內存分配

內存分配是在信息系統運行過程中優化配置的，資料庫管理員可以根據資料庫運行狀況調整資料庫系統全局區(SGA區)的數據緩沖區、日誌緩沖區和共享池的大小;還可以調整程序全局區(PGA區)的大小。需要注意的是，SGA區不是越大越好，SGA區過大會佔用操作系統使用的內存而引起虛擬內存的頁面交換，這樣反而會降低系統。

5、調整硬碟I/O

這一步是在信息系統開發之前完成的。資料庫管理員可以將組成同一個表空間的數據文件放在不同的硬碟上，做到硬碟之間I/O負載均衡。

6、調整操作系統參數

例如：運行在UNIX操作系統上的ORACLE資料庫，可以調整UNIX數據緩沖池的大小，每個進程所能使用的內存大小等參數。

實際上，上述資料庫優化措施之間是相互聯系的。ORACLE資料庫性能惡化表現基本上都是用戶響應時間比較長，需要用戶長時間的等待。但性能惡化的原因卻是多種多樣的，有時是多個因素共同造成了性能惡化的結果，這就需要資料庫管理員有比較全面的計算機知識，能夠敏感地察覺到影響資料庫性能的主要原因所在。另外，良好的資料庫管理工具對於優化資料庫性能也是很重要的。

一、ORACLE資料庫性能優化工具

常用的資料庫性能優化工具有：

ORACLE資料庫在線數據字典，ORACLE在線數據字典能夠反映出ORACLE動態運行情況，對於調整資料庫性能是很有幫助的。

操作系統工具，例如UNIX操作系統的vmstat，iostat等命令可以查看到系統系統級內存和硬碟I/O的使用情況，這些工具對於管理員弄清出系統瓶頸出現在什麼地方有時候很有用。

SQL語言跟蹤工具(SQLTRACEFACILITY)，SQL語言跟蹤工具可以記錄SQL語句的執行情況，管理員可以使用虛擬表來調整實例，使用SQL語句跟蹤文件調整應用程序性能。SQL語言跟蹤工具將結果輸出成一個操作系統的文件，管理員可以使用TKPROF工具查看這些文件。

ORACLEEnterpriseManager(OEM)，這是一個圖形的用戶管理界面，用戶可以使用它方便地進行資料庫管理而不必記住復雜的ORACLE資料庫管理的命令。

EXPLAINPLAN——SQL語言優化命令，使用這個命令可以幫助程序員寫出高效的SQL語言。

二、ORACLE資料庫的系統性能評估

信息系統的類型不同，需要關注的資料庫參數也是不同的。資料庫管理員需要根據自己的信息系統的類型著重考慮不同的資料庫參數。

1、在線事務處理信息系統(OLTP)，這種類型的信息系統一般需要有大量的Insert、Update操作，典型的系統包括民航機票發售系統、銀行儲蓄系統等。OLTP系統需要保證資料庫的並發性、可靠性和最終用戶的速度，這類系統使用的ORACLE資料庫需要主要考慮下述參數：

資料庫回滾段是否足夠?

是否需要建立ORACLE資料庫索引、聚集、散列?

系統全局區(SGA)大小是否足夠?

SQL語句是否高效?

2、數據倉庫系統(DataWarehousing)，這種信息系統的主要任務是從ORACLE的海量數據中進行查詢，得到數據之間的某些規律。資料庫管理員需要為這種類型的ORACLE資料庫著重考慮下述參數：

是否採用B*-索引或者bitmap索引?

是否採用並行SQL查詢以提高查詢效率?

是否採用PL/SQL函數編寫存儲過程?

有必要的話，需要建立並行資料庫提高資料庫的查詢效率

三、SQL語句的調整原則

SQL語言是一種靈活的語言，相同的功能可以使用不同的語句來實現，但是語句的執行效率是很不相同的。程序員可以使用EXPLAINPLAN語句來比較各種實現方案，並選出最優的實現方案。總得來講，程序員寫SQL語句需要滿足考慮如下規則：

1、盡量使用索引。試比較下面兩條SQL語句：

語句A：SELECTdname,

(SELECTdeptnoFROMemp);

語句B：SELECTdname,deptnoFROMdeptWHERENOTEXISTS

(SELECTdeptnoFROMempWHEREdept.deptno=emp.deptno);

這兩條查詢語句實現的結果是相同的，但是執行語句A的時候，ORACLE會對整個emp表進行掃描，沒有使用建立在emp表上的deptno索引，執行語句B的時候，由於在子查詢中使用了聯合查詢，ORACLE只是對emp表進行的部分數據掃描，並利用了deptno列的索引，所以語句B的效率要比語句A的效率高一些。

2、選擇聯合查詢的聯合次序。考慮下面的例子：

SELECTstuffFROMtabaa,tabbb,tabcc

WHEREa.acolbetween:alowand:ahigh

ANDb.bcolbetween:blowand:bhigh

ANDc.ccolbetween:clowand:chigh

ANDa.key1=b.key1

AMDa.key2=c.key2;

這個SQL例子中，程序員首先需要選擇要查詢的主表，因為主表要進行整個表數據的掃描，所以主表應該數據量最小，所以例子中表A的acol列的范圍應該比表B和表C相應列的范圍小。

3、在子查詢中慎重使用IN或者NOTIN語句，使用where(NOT)exists的效果要好的多。

4、慎重使用視圖的聯合查詢，尤其是比較復雜的視圖之間的聯合查詢。一般對視圖的查詢最好都分解為對數據表的直接查詢效果要好一些。

5、可以在參數文件中設置SHARED_POOL_RESERVED_SIZE參數，這個參數在SGA共享池中保留一個連續的內存空間，連續的內存空間有益於存放大的SQL程序包。

6、ORACLE公司提供的DBMS_SHARED_POOL程序可以幫助程序員將某些經常使用的存儲過程「釘」在SQL區中而不被換出內存，程序員對於經常使用並且佔用內存很多的存儲過程「釘」到內存中有利於提高最終用戶的響應時間。

四、CPU參數的調整

CPU是伺服器的一項重要資源，伺服器良好的工作狀態是在工作高峰時CPU的使用率在90%以上。如果空閑時間CPU使用率就在90%以上，說明伺服器缺乏CPU資源，如果工作高峰時CPU使用率仍然很低，說明伺服器CPU資源還比較富餘。

使用操作相同命令可以看到CPU的使用情況，一般UNIX操作系統的伺服器，可以使用sar_u命令查看CPU的使用率，NT操作系統的伺服器，可以使用NT的性能管理器來查看CPU的使用率。

資料庫管理員可以通過查看v$sysstat數據字典中「CPUusedbythissession」統計項得知ORACLE資料庫使用的CPU時間，查看「OSUserlevelCPUtime」統計項得知操作系統用戶態下的CPU時間，查看「OSSystemcallCPUtime」統計項得知操作系統系統態下的CPU時間，操作系統總的CPU時間就是用戶態和系統態時間之和，如果ORACLE資料庫使用的CPU時間占操作系統總的CPU時間90%以上，說明伺服器CPU基本上被ORACLE資料庫使用著，這是合理，反之，說明伺服器CPU被其它程序佔用過多，ORACLE資料庫無法得到更多的CPU時間。

資料庫管理員還可以通過查看v$sesstat數據字典來獲得當前連接ORACLE資料庫各個會話佔用的CPU時間，從而得知什麼會話耗用伺服器CPU比較多。

出現CPU資源不足的情況是很多的：SQL語句的重解析、低效率的SQL語句、鎖沖突都會引起CPU資源不足。

1、資料庫管理員可以執行下述語句來查看SQL語句的解析情況：

SELECT*FROMV$SYSSTATWHERENAMEIN

('parsetimecpu','parsetimeelapsed','parsecount(hard)');

這里parsetimecpu是系統服務時間，parsetimeelapsed是響應時間，用戶等待時間，waitetime=parsetimeelapsed_parsetimecpu

由此可以得到用戶SQL語句平均解析等待時間=waitetime/parsecount。這個平均等待時間應該接近於0，如果平均解析等待時間過長，資料庫管理員可以通過下述語句

SELECTSQL_TEXT,PARSE_CALLS,EXECUTIONSFROMV$SQLAREA

ORDERBYPARSE_CALLS;

來發現是什麼SQL語句解析效率比較低。程序員可以優化這些語句，或者增加ORACLE參數SESSION_CACHED_CURSORS的值。

2、資料庫管理員還可以通過下述語句：

SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA;

查看低效率的SQL語句，優化這些語句也有助於提高CPU的利用率。

3、資料庫管理員可以通過v$system_event數據字典中的「latchfree」統計項查看ORACLE資料庫的沖突情況，如果沒有沖突的話，latchfree查詢出來沒有結果。如果沖突太大的話，資料庫管理員可以降低spin_count參數值，來消除高的CPU使用率。

五、內存參數的調整

內存參數的調整主要是指ORACLE資料庫的系統全局區(SGA)的調整。SGA主要由三部分構成：共享池、數據緩沖區、日誌緩沖區。

1、共享池由兩部分構成：共享SQL區和數據字典緩沖區，共享SQL區是存放用戶SQL命令的區域，數據字典緩沖區存放資料庫運行的動態信息。資料庫管理員通過執行下述語句：

select(sum(pins-reloads))/sum(pins)"LibCache"fromv$librarycache;

來查看共享SQL區的使用率。這個使用率應該在90%以上，否則需要增加共享池的大小。資料庫管理員還可以執行下述語句：

select(sum(gets-getmisses-usage-fixed))/sum(gets)"RowCache"fromv$rowcache;

查看數據字典緩沖區的使用率，這個使用率也應該在90%以上，否則需要增加共享池的大小。

2、數據緩沖區。資料庫管理員可以通過下述語句：

SELECTname,valueFROMv$sysstatWHEREnameIN('dbblockgets','consistentgets','physicalreads');

來查看資料庫數據緩沖區的使用情況。查詢出來的結果可以計算出來數據緩沖區的使用命中率=1-(physicalreads/(dbblockgets+consistentgets))。

這個命中率應該在90%以上，否則需要增加數據緩沖區的大小。

3、日誌緩沖區。資料庫管理員可以通過執行下述語句：

selectname,valuefromv$sysstatwherenamein('redoentries','redologspacerequests');

查看日誌緩沖區的使用情況。查詢出的結果可以計算出日誌緩沖區的申請失敗率：

申請失敗率=requests/entries，申請失敗率應該接近於0，否則說明日誌緩沖區開設太小，需要增加ORACLE資料庫的日誌緩沖區。

昆明北大青鳥java培訓班轉載自網路如有侵權請聯系我們感謝您的關注謝謝支持

Ⅶ 當資料庫變慢時的解決方法有哪些

我們使用電腦和手機時候最不能忍受就是設備又卡又慢了,嚴重影響我們工作或者游戲體驗。當資料庫變慢時，我們應如何入手，下面的解決方法。

方法步驟

第一章 檢查系統的狀態

1.1 使用sar來檢查操作系統是否存在IO問題

1.2 關注內存vmstat

1.3 找到使用沖賀握資源特別大的Oracle的session及其執行的語句

1.4 查找前十條性能差的sql語句

散慶當資料庫變慢時，我們應如何入手

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

第一章 檢查系統的狀態

通過操作系統的一些工具檢查系統的狀態，比如CPU、內存、交換、磁碟的利用率，根據經驗或與系統正常時的狀態相比對，有時系統表面上看起來看空閑，這也可能不是一個正常的狀態，因為cpu可能正等待IO的完成。除此之外，還應觀注那些佔用系統資源(cpu、內存)的進程。

1.1 使用sar來檢查操作系統是否存在IO問題

#sar -u 2 10 -- 即每隔2秒檢察一次，共執行20次。

結果示例：

註：在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

其中：

Ø %usr指的是用戶進程使用的cpu資源的百分比;

Ø %sys指的是系統資源使用cpu資源的百分比;

Ø %wio指的是等待io完成的百分比，這是值得觀注的一項;

Ø %idle即空閑的百分比。

如果wio列的值很大，如在35%以上，說明系統的IO存在瓶頸，CPU花費了很大的時間去等待I/O的完成。Idle很小說明系統CPU很忙。像以上的示例，可以看到wio平均值為11，說明I/O沒什麼特別的問題，而idle值為零，說明cpu已經滿負荷運行了。

當系統存在IO問題時，可以從以下幾個方面解決：

Ø 聯系相應的操作系統的技術支持對這方面進行優化，比如hp-ux在劃定卷組時的條帶化等方面。

Ø 查找Oracle中不合理的sql語句，對其進行優化;

Ø 對Oracle中訪問量頻繁的表除合理建索引外，再就是把這些表分表空間存放以免訪問上產生熱點，再有就是對表合理分區。

1.2 關注內存

拍含常用的工具便是vmstat，對於hp-unix來說，可以用glance。Aix來說可以用topas。當發現vmstat中pi列非零，memory中的free列的值很小，glance、topas中內存的利用率多於80%時，這時說明內存方面應該調節一下。方法大體有以下幾項：

Ø 劃給Oracle使用的內存不要超過系統內存的1/2，一般保在系統內存的40%為益。

Ø 為系統增加內存;

Ø 如果你的連接特別多，可以使用MTS的方式;

Ø 打全補丁，防止內存漏洞。

1.3 找到使用資源特別大的Oracle的session及其執行的語句

Hp-unix可以用glance或top。IBM AIX可以用topas。此外可以使用ps的命令。

通過這些程序可以找到點用系統資源特別大的這些進程的進程號，就可以通過以下的sql語句發現這個pid正在執行哪個sql，這個sql最好在pl/sql developer、toad等軟體中執行：

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等待，從而加快語句的執行速度。

提示：在做優化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 'x' FROM table2 b WHERE a.col1=b.col1)

1.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。以下是參考腳本：

-- 腳本說明：查看佔I/O較大的正在運行的session：

SELECT se.sid, se.serial#, pr.spid, se.username, se.status, se.terminal,

se.program, se.mole, 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已經發生的物理讀排的序，因為它與實際的I/O相關。

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做以簡要的說明：

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

Ø 增加寫進程，同時要調整db_block_lru_latches參數：

示例：修改或添加如下兩個參數

db_writer_processes=4

db_block_lru_latches=8

Ø 開非同步IO。IBM這方面簡單得多，hp則麻煩一些，可以與Hp工程師聯系。

2) db file sequential read，指的是順序讀，即全表掃描，這也是應盡量減少的部分，解決方法就是使用索引、sql調優，同時可以增大db_file_multiblock_read_count這個參數。

3) db file scattered read參數指的是通過索引來讀取，同樣可以通過增加db_file_multiblock_read_count這個參數來提高性能。

4) latch free與栓相關，需要專門調節。

5) 其他參數可以不特別觀注

補充：解決系統變慢的常用技巧方法

1、在我的電腦窗口，右擊要清理的盤符―“屬性”―“清理磁碟”--勾選要刪除的文件--確定--是。

2、右鍵瀏覽器e――屬性――點2個刪除1個清除(都要逐一確定)――確定 。

3、把C:WINDOWSPrefetch(預讀文件)把裡面的文件全部刪除

4、用優化大師或超級兔子清理注冊表和垃圾文件。

5、“開始”――運行中輸入msconfig――確定――啟動――除了輸入法ctfmon以外的勾全去掉。

6、右鍵我的電腦”――屬性――點高級――點啟動和故障恢復中的設置――去掉所有的勾――寫入調試信息選擇“無”――確定――點高級下面錯誤報告――點禁用――2次確定。

7、“開始”..打開控制面板中的文件夾選項..點查看..點去末項自動搜索文件夾前面的勾..確定。

8、右鍵我的電腦――屬性――硬體――設備管理器――雙擊IDE控制器――次要通道――高級設置――傳送模式都選DMA――設備類型選無――確定――主要通道也同樣設置――確定。

9、右鍵C盤進行磁碟清理和其它選項中的系統還原清理。