【正文】 為了防止與數(shù)據(jù)塊相關(guān)的緩沖忙等待，也可以使用較小的塊：在這種情況下，單個塊中的記錄就較少，所以這個塊就不是那么繁忙；或者可以設(shè)置更大的pctfree,使數(shù)據(jù)擴(kuò)大物理分布，減少記錄間的熱點競爭。 如果等待處于data block，可以考慮將頻繁并發(fā)訪問的表或數(shù)據(jù)移到另一數(shù)據(jù)塊或者進(jìn)行更大范圍的分布（可以增加pctfree 值 ，擴(kuò)大數(shù)據(jù)分布，減少競爭），以避開這個熱點數(shù)據(jù)塊，或者可以考慮增加表中的自由列表或使用本地化管理的表空間（Locally Managed Tablespaces）。 Table altered。也就是當(dāng)進(jìn)程想獲取或者操作某個block的時候卻發(fā)現(xiàn)被別的進(jìn)程在使用而出現(xiàn)等待。 這種情況通常表示正在執(zhí)行相當(dāng)多數(shù)量的DML（插入／更新／刪除），并且可能說明DBWR 寫的速度不夠快，緩沖存儲器可能充滿了相同緩沖器的多個版本，從而導(dǎo)致效率非常低。 Free Buffer Wait: 釋放緩沖區(qū)。檢查索引掃描，以保證每個掃描都是必要的，并檢查多表連接的連接順序。因為根據(jù)索引讀數(shù)據(jù)的話，假設(shè)100條記錄，根據(jù)索引，不算索引本身的讀，而根據(jù)索引每個值去讀一下表數(shù)據(jù)，理論上最多可能產(chǎn)生100 buffer gets，而如果是full table scan，則100條數(shù)據(jù)完全可能在一個block里面，則幾乎一次就讀過這個block了，就會產(chǎn)生這么大的差異。 db file sequential read: DB文件連續(xù)讀取。 通常來說我們可以認(rèn)為是全表掃描類型的讀，因為根據(jù)索引讀表數(shù)據(jù)的話一次只讀一個block，如果這個數(shù)字過大，就表明該表找不到索引，或者只能找到有限的索引，可能是全表掃描過多，需要檢查sql是否合理的利用了索引，或者是否需要建立合理的索引。 1,543 1,560 472 db file parallel write 26,877 Time (cs) % Total Event Wait 空閑事件指Oracle 正等待某種工作,在診斷和優(yōu)化數(shù)據(jù)庫的時候,我們不用過多注意這部分事件。 Oracle 的等待事件是衡量Oracle 運行狀況的重要依據(jù)及指標(biāo)。 有些報告中這個值是負(fù)的，看上去很奇怪。 % NonParse CPU: Latch Hit %: Library Hit Inmemory Sort %: Buffer Redo NoWait %: 還有就是為了維護(hù)internal structure，需要使用latch，latch是一種Oracle低級結(jié)構(gòu),用于保護(hù)內(nèi)存資源，是一種內(nèi)部生命周期很短的lock，大量使用latch將消耗大量的cpu資源。 Parse 和 hard parse通常是很容易出問題的部分，80%的系統(tǒng)的慢都是由于這個原因所導(dǎo)致的。Rollback per transaction %: % Blocks changed per Read: Hard parses: Parses: User calls: Physical writes: Redo size: (mins) Statspack報告首先描述了數(shù)據(jù)庫的基本情況，比如數(shù)據(jù)庫名、實例名、實例個數(shù)、oracle版本號等等；然后是該報告的開始快照和結(jié)束快照的信息，包括 snap id , snap time 等等；最后是該報告經(jīng)過的時間跨度，單位是分鐘(mins)。 38 Begin Snap: Sessions res 1 2749170756 res DB Id 基本信息分析 DB Name 例如： SQLexecute (i_buffer_gets_th=100000,i_disk_reads_th=100000。 因為每一個快照都會收集很多數(shù)據(jù)，每一行都代表獲取快照時數(shù)據(jù)庫中的一個SQL 語句，所以stats$sql_summary 很快就會成為Statspack 中最大的表。 如果你只是想本次改變收集級別，可以忽略i_modify_parameter 參數(shù)。并且還會將附加的子鎖存存入stats$lathc_children 中。 b. level 5: 增加SQL 語句。 一些重要腳本 1．通過導(dǎo)出保存及共享數(shù)據(jù) 在診斷系統(tǒng)問題時，可能需要向?qū)I(yè)人士提供原始數(shù)據(jù)，這時我們可以導(dǎo)出Statspack 表數(shù)據(jù)， 其中我們可能用到： 其內(nèi)容主要為： file= log= press=y grants=y indexes=y rows=y constraints=y owner=PERFSTAT consistent=y 我們可以導(dǎo)出如下： exp userid=perfstat/my_perfstat_password parfile= 2．刪除數(shù)據(jù) 在執(zhí)行時主要調(diào)用兩個腳本: 、 前者刪除表及同義詞等數(shù)據(jù)，后者刪除用戶 3．Oracle92 中新增加的腳本 1） 用于升級statspack 對象的腳本,這些腳本需要以具有SYSDBA 權(quán)限的用戶運行, 升級前請先 備份存在的Schema 數(shù)據(jù): : 版本。 delete from STATS$SNAPSHOT。 truncate table STATS$SQL_SUMMARY。 truncate table STATS$SESSION_EVENT。 truncate table STATS$SGASTAT。 truncate table STATS$BUFFER_POOL_STATISTICS。 truncate table STATS$LATCH_CHILDREN。 143 rows deleted 你可以更改snap_id 的范圍以保留你需要的數(shù)據(jù)。 刪除歷史快照數(shù)據(jù) 前面講過，成功運行一次 就會產(chǎn)生一個 snapshot ，這個 snapshot 的基本信息是存放在 $snapshot 表中的，生成 statspack報告時會查詢該表的數(shù)據(jù)，供用戶選擇準(zhǔn)備分析的 snapshot 。結(jié)束快照ID； RES Snap Started 1 在收集數(shù)據(jù)時， statpack 會將 top10 的 sql 前 31 個字節(jié) 存入數(shù)據(jù)表中,若在SQL 的前31 個字有中文，就會出現(xiàn)此錯誤。 * ERROR at line 1: ORA01401: inserted value too large for column ORA06512: at , line 978 ORA06512: at , line 1612 ORA06512: at , line 71 ORA06512: at line 1 這是Oracle 的一個Bug，Bug 號1940915。 如果一切正常，說明安裝成功。 167。s default 這期間會提示你輸入缺省表空間和臨時表空間的位置,輸入我們?yōu)?perfstat 用戶創(chuàng)建的表空間和你的臨時表空間。 30133 Jun 15 other 2000 rwrr 1 oracle other 2000 rwrr 758 Jun 15 6414 Jun 15 1 oracle other 2000 rwrr other 2000 rwrr 1 oracle 步驟三： 在 sqlplus 中用internal 身份登陸，或者擁有SYSDBA(connect / as sysdba)權(quán)限的用戶登陸。/oracle/oradata/oradata/res/39。 步驟二： 需要單獨為statspack創(chuàng)建一個存儲數(shù)據(jù)的表空間，如果采樣間隔較短，周期較長，打算長期使用，那么可能需要一個大一點的表空間，如果每個半個小時采樣一次，連續(xù)采樣一周，數(shù)據(jù)量是很大的。 該參數(shù)使收集的時間信息存儲在在V$SESSTATS 和V$SYSSTATS 等動態(tài)性能視圖中。 System altered 2.你可以在初試化參數(shù)文件中修改該參數(shù)(使該參數(shù)在重起后以然有效)。 該報表實際上相當(dāng)于statspack 中的兩個采樣點。Statspack除了查找實例中的性能問題外，還可以查找應(yīng)用程序中高負(fù)荷的SQL語句，很容易確定Oracle 數(shù)據(jù)庫的瓶頸所在，并且記錄數(shù)據(jù)庫性能狀態(tài)。這是在不了解應(yīng)用和程序下針對特定session的診斷和調(diào)整過程。假如某個session運行很慢或者某個用戶的某個查詢很慢，那么這個時候我們可以通過trace session的方式來診斷到底是慢在哪里，看究竟執(zhí)行計劃是怎樣的，然后在user_dump_dest下根據(jù)該session的進(jìn)程號或者線程號可以找到一個產(chǎn)生的trace文件。所以在我們不了解一個系統(tǒng)的時候來優(yōu)化數(shù)據(jù)庫應(yīng)用不是一個輕松的容易的事情。 2.但在這里遺憾的是，windows 是無法避免這種情況的。 System altered. SQL alter system set shared_pool_size = 20480000。 SGA_MAX_SIZE 在9i中若設(shè)置了SGA_MAX_SIZE，則在總和小于等于這個值內(nèi)，可以動態(tài)的調(diào)整數(shù)據(jù)緩沖區(qū)和共享池的大小 SQL show parameters sga_max_size NAME PGA 在9i 里面這部分也有了很大的變化。另外9i新增加了db_nk_cache_size，這是為了支持在同一個數(shù)據(jù)庫中使用不同的塊大小而設(shè)置的。關(guān)于內(nèi)存這部分的變化，我們可以考察下面的參數(shù)。 Production TNS for HPUX: Version Production NLSRTL Version – Production 32bit的oracle無論跑在32bit或者64bit的平臺都有SGA的限制的，而對于32bit的平臺只能跑32bit的oracle，但是在特定的操作系統(tǒng)下，可能提供了一定的手段， 的內(nèi)存，達(dá)到2G 以上甚至更多。假如我們安裝64bit的數(shù)據(jù)庫,我們就可以使用很大的內(nèi)存，幾乎不可能達(dá)到上限。 shared_pool_size 應(yīng)該適度 這部分內(nèi)存的作用主要是緩存 DB BLOCK，減少甚至避免從磁盤上獲取數(shù)據(jù)，在8i中通常是由db_block_buffers*db_block_size 來決定大小的。 事實上，可能的話我們甚至要想辦法避免軟分析，這在不同的程序語言中實現(xiàn)方式有差異。 假如把 ’TOM’ 和 ’JERRY’ 換做變量V，那就是使用了bind var，我們可以認(rèn)為是同樣的SQL 從而能很好地共享。 對于一個沒有充分使用或者沒有使用綁定變量系統(tǒng)，這可能給我們帶來一個嚴(yán)重的問題。但是該參數(shù)的增大，卻也有負(fù)面的影響，因為需要維護(hù)共享的結(jié)構(gòu)，內(nèi)存的增大也會使得SQL 的老化的代價更高，帶來大量的管理的開銷，所有這些可能會導(dǎo)致CPU 的嚴(yán)重問題。首先我們要考究一個問題，那就是這部分內(nèi)存的作用，它是為了緩存已經(jīng)被解析過的SQL，而使其能被重用，不再解析。事實上可以更少，甚至最少只需要32k，但具體跟安裝數(shù)據(jù)庫的時候的組件相關(guān)(比如 server)。這部分主要用來保存并行查詢時候的一些信息，還有就是RMAN 在備份的時候可能會使用到。 當(dāng)然我們這里是以默認(rèn)的排序部分內(nèi)存sort_area_size=64k進(jìn)行衡量的，假如我們需要調(diào)大該參數(shù)和hash_area_size等參數(shù)，然后我們應(yīng)該根據(jù)并發(fā)的進(jìn)程的數(shù)量，來衡量考慮這個問題。由于會話并不會經(jīng)常使用create_bitmap_area_size 、bitmap_merge_area_size，所以我們通常不對四個參數(shù)求和。 這四個參數(shù)都是針對會話進(jìn)行設(shè)置的，是單個會話使用的內(nèi)存的大小，而不是整個數(shù)據(jù)庫使用的。由于磁盤排序效率和內(nèi)存排序效率相差好幾個數(shù)量級，所以這個參數(shù)的設(shè)置很重要。 131072 sort_area_size integer bitmap_merge_area_size 事實上這個問題應(yīng)該說還跟OLTP 類型或者OLAP 類型相關(guān)。對于這部分文件緩存，所需要的內(nèi)存可能比較大，作為保守的估計，我們應(yīng)該考慮在 —— 倍內(nèi)存大小。 接下來我們要探討一個重要的問題，那就是關(guān)于文件系統(tǒng)和裸設(shè)備的問題，這往往容易被我們所忽略。 SGA是一塊內(nèi)存區(qū)域，占用的是系統(tǒng)物理內(nèi)存，因此對于一個Oracle應(yīng)用系統(tǒng)來說，SGA決不是越大越好，這就需要尋找一個系統(tǒng)優(yōu)化的平衡點。 172032 172032 – 163840 = 8192 （以上試驗數(shù)據(jù)是在 HP + Oracle 環(huán)境下得到的） 1073741824 Redo Buffers 104936 Variable Size NAME