ORACLE數(shù)據(jù)庫變得非常慢解決方案一例

1、ORACLE 數(shù)據(jù)庫變得非常慢解決方案一例數(shù)據(jù)庫變得非常慢 /b/b接到客戶報告最近數(shù)據(jù)庫速度慢了好多 , 同樣的應(yīng)用慢了 4,5 倍. 我做了個 statspack, 沒發(fā)現(xiàn)什么問題 , 主要信息 :Cache Sizes (end)Buffer Cache: 3,104M Std Block Size: 8KShared Pool Size: 400M Log Buffer: 3,072KLoad ProfilePer Second Per TransactionRedo size: 394,918.91 68,578.62Logical reads: 40,718.26 7,070.82

2、Block changes: 3,516.66 610.68Physical reads: 1,673.37 290.59Physical writes: 63.58 11.04User calls: 122.83 21.33Parses: 22.04 3.83Hard parses: 2.23 0.39Sorts: 10.36 1.80Logons: 0.38 0.07Executes: 54.35 9.44Transactions: 5.76% Blocks changed per Read: 8.64 Recursive Call %: 46.61 Rollback per transa

3、ction %: 0.00 Rows per Sort: 1601.81 Instance Efficiency Percentages (Target 100%)Buffer Nowait %: 99.99 Redo NoWait %: 100.00Buffer Hit %: 95.91 In-memory Sort %: 99.99Library Hit %: 98.08 Soft Parse %: 89.90Execute to Parse %: 59.45 Latch Hit %: 99.88Parse CPU to Parse Elapsd %: % Non-Parse CPU:Sh

4、ared Pool Statistics Begin EndMemory Usage %: 86.59 86.84% SQL with executions>1: 88.19 88.59% Memory for SQL w/exec>1: 94.34 94.96Top 5 Timed Events % Total Event Waits Time (s) Ela Time db file scattered read 585,373 5,110 36.24 latch free 38,146 3,331 23.63db file sequential read 328,881 2,

5、096 14.87 PX Deq: Txn Recovery Start 645 1,124 7.97 db file parallel write 3,840 754 5.35*AIX 系統(tǒng) :*#iostat 5 5tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 2.5 16.4 2.8 69.7 11.1Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 20.9 141.9 33.0 1176852937 1037907344 hdisk1 20.4 136.6 31.3 1136

6、554209 996356546 hdisk2 12.6 140.3 56.6 702195893 1487895240 hdisk3 10.6 249.1 39.5 1887071251 2001871356 cd0 0.0 0.0 0.0 0 0tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 339.4 22.1 6.6 19.0 52.4Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 95.6 615.2 152.0 2112 964 hdisk1 96.0 612.0 150.

7、8 2156 904 hdisk2 83.0 2470.4 226.4 11524 828 hdisk3 7.0 60.0 12.6 300 0 cd0 0.0 0.0 0.0 0 0tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 460.4 31.3 7.7 13.1 47.9Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 95.4 648.0 158.4 1844 1396 hdisk1 98.4 679.2 163.4 1896 1500 hdisk2 89.6 2595.2 2

8、60.2 12088 888 hdisk3 5.8 44.8 10.2 212 12 cd0 0.0 0.0 0.0 0 0tty: tin tout avg-cpu: % user % sys % idle % iowait0.0 364.5 21.9 7.4 14.9 55.9Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 96.6 750.9 177.9 1152 2604hdisk1 95.2 773.3 177.7 1176 2692 hdisk2 70.2 2002.5 205.1 9740 276 hdisk3 5.0 132.8

9、8.4 152 512 cd0 0.0 0.0 0.0 0 0*FZYC1/#sar 5 5 AIX FZYC1 3 4 000177DF4C00 06/06/06 10:15:40 %usr %sys %wio %idle 10:15:45 15 2 63 19 10:15:50 19 3 56 22 10:15:55 22 5 54 20 10:16:00 20 10 51 20 10:16:05 25 9 51 15 Average 20 6 55 19*FZYC1/#ps - ef |pg UID PID PPID C STIME TTY TIME CMD root 1 0 0 Dec

10、 07 - 29:33 /etc/init root 4158 1 0 Dec 07 - 0:00 /usr/lib/methods/ssa_daemon -l ssa0root 4446 11096 0 Dec 07 - 182:03 /usr/dt/bin/dtsession root 5014 1 0 Dec 07 - 1577:46 /usr/sbin/syncd 10 root 5958 10322 0 Dec 07 - 24:57 /usr/lpp/X11/bin/X -x abx -x db e -x GLX -D /usr/lib/X11/rgb -T -force :0 -a

11、uth /var/dt/A:0-aWkfia root 10322 1 0 Dec 07 - 0:01 /usr/dt/bin/dtlogin -daemon root 10610 1 0 Dec 07 - 0:00 /usr/lib/errdemon root 10926 4446 0 Dec 07 - 0:00 /usr/dt/bin/dtterm root 11096 10322 0 Dec 07 - 0:00 dtlogin -daemon root 11364 17626 0 Dec 07 pts/0 0:00 /bin/kshroot 11620 1 0 Dec 07 - 0:00

12、 imqsmdem imqsrv.ini /etc/IMNSea rch/dbcshelp/我發(fā)現(xiàn) iowait 太高了 , 懷疑是這個系統(tǒng)同步進程 root 5014 1 0 Dec 07 - 1577:46 /usr/sbin/syncd 10 照成的 ,aix 系統(tǒng)不怎么熟 , 會不會是這個照成數(shù)據(jù)庫變慢呢 ? 要不要喀嚓掉它 ? 我懷疑不是數(shù)據(jù)庫的問題 ,因為應(yīng)用沒什么變化 , 定期維護也有做 .問題情況簡要敘述 :客戶報告數(shù)據(jù)庫越來越慢 ,業(yè)務(wù)快無法進行了 , 近期并沒有上什么新的應(yīng)用和大的改變 收集信息 :statspack 發(fā)現(xiàn) top5 等待首位為 db scatter rea

13、daix topas 和 iostat 發(fā)現(xiàn) iowait 嚴重，超過 50% busy 保持 90%分析：查詢 top sql,v$sesstat+v$statname 發(fā)現(xiàn) awm s 應(yīng)用進程 db session logical reads 等磁盤讀寫嚴重awms應(yīng)用為實時查詢（很頻繁）,查詢sql的執(zhí)行路徑為，主要sql為對一些基表進行全表掃描.基表數(shù)據(jù) 量不大（5-8w）左右，理論上查詢io并不應(yīng)該太髙進一步查發(fā)現(xiàn)，該表dml較多,照成表不斷擴大，碎片增多， 對該表的full scan 代價越來越大.僅僅憑112m的大小并不會照成太嚴重的 io,但是該表被用于實查詢，并 且由于是f

14、ull scan,在查詢完成后會被至到 LRU列表的least used 端.因此照成頻繁的讀寫.內(nèi)存不夠用， 引起了過多的swap.（這里為推測的原因，并不能肯定是正確的）解決：把表重建（truncate掉重插數(shù)據(jù)，或者move表然后重建索引）,這些基表不大，并且頻繁使用，由于這些特性，所以將其keep到buffer中-alter table table_namestorage (buffer_pool keep) 觀察了些時間，數(shù)據(jù)性能恢復(fù)了小記：不明原因的解決了ORACLE慢的問題近來發(fā)現(xiàn)ORACLE服務(wù)器超級慢，而且慢并不是由應(yīng)用程序性能導(dǎo)致的，就連運行proc預(yù)編譯程序都很慢，可見問

15、題還是出在ORACLE服務(wù)器本身。首先查看了一下ORACLE的主要內(nèi)存參數(shù)：SELECT "NUM","NAME","TYPE","VALUE" /1024 AS "KB", "ISDEFAULT","ISSES_MODIFIABLE","ISSYS_MODIFIABLE", "ISMODIFIED","ISADJUSTED","DESCRIPTION","UPDAT

16、E_COMMENT"FROM v$parameterWHERE NAME IN ('db_block_size'，db_cache_size','java_pool_size' , 'large_pool_size' , 'pga_aggregate_target','shared_pool_size' , 'sort_area_size')除了大池（large_pool_size）為16MB以外，每項內(nèi)存都配置得不小。于是懷疑是共享池滿造成的，在網(wǎng)上找了篇文章查了查共享池的占用情

17、況:如何計算oracle共享池的大小 http:/blog.si .c n/s/blog_3ebdf8ad010006bk.html執(zhí)行了一下，共享池竟然占用了113%。居然溢出了！ ！搞不懂！于是嘗試著修改參數(shù)：1. 在 linux 下：su - oracle2. sqlplus "/as sysdba"3. CREATE PFILE='ahfu.ora' FROM SPFILE;4. 在 LINUX 下：cd /oracle/ora9/product/9.2/dbs/5. vi ahfu.ora6. 修改參數(shù)如下：db_cache_size （數(shù)據(jù)緩存）

18、256MB-> 512MBjava_pool_size （java 池）84MB -> 0MBlarge_pool_size （大池） 16MB -> 64MB query_rewrite_enabled （ 查詢重寫）FALSE -> TRUE7. 保存，關(guān)閉數(shù)據(jù)庫： shutdown immediate;8. 從新的 pfile 啟動：startup pfile='/oracle/ora9/product/9.2/dbs/ahfu.ora'9. 重新連接數(shù)據(jù)庫，發(fā)現(xiàn)連接和查詢都變得很快了。反復(fù)重啟數(shù)據(jù)庫多次，仍然很快。猜測一方面是因為共享池滿導(dǎo)致了數(shù)據(jù)庫慢，另一方面是大池設(shè)置得過小。但是重啟后 變快并不能說明真正解決了問題，要多運行一段時間才知道。附1:對共享池的分析共享池緩存了系統(tǒng)中執(zhí)行過的SQL。如果出現(xiàn)大量的不同的 SQL，就可能導(dǎo)致共享池滿。共享池滿后，每次執(zhí)行 SQL都會掃描共享池，尋找相同的SQL，找不到后又掃描整個共享池將長時間為執(zhí)行的SQL設(shè)置為