學習Oracle--Statspack分析

　　~~~~~~~~~~Per Second　　　 Per Transaction
　　
　　Redo size:　　　　 　　　　　
　　很重要的參數表示你數據變更頻率
　　Logical reads:　　　　　　　
　　Block changes:　　　　　　　　
　　Physical reads:　 　　　　
　　Physical writes:　　　　　　　　
　　User calls:　　　　 　　　　　　
　　Parses:　　　　　　　　　　　　
　　軟解析每秒超過次意味著你的應用程序效率不高沒有使用soft soft parse調整session_cursor_cache
　　Hard parses:　　　　　　　　　　　
　　每秒超過次就可能說明你綁定使用的不好
　　Sorts:　　　　　　　 　　　　　　　 　
　　Logons:　　　　　　　　　　　　　
　　Executes:　　　　 　　　　　　
　　Transactions:　　
　　
　　% Blocks changed per Read:　　　　Recursive Call %:　　　　　　
　　如果有很多PLSQL那麼他就會比較高
　　Rollback per transaction %:　　　　　　 Rows per Sort:　 　　　
　　看回滾率是不是很高因為回滾很耗資源
　　　
　　Instance Efficiency Percentages (Target %)　
　　這一部分通過可以提前找出ORACLE潛在將要發生的性能問題（所以很重要哦）
　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
　　Buffer Nowait %:　 　　　 Redo NoWait %:　　　　　
　　Buffer Nowait<%說明有可能是有熱塊(查找x$bh的 tch和v$latch_children的cache buffers chains)
　　Buffer　Hit　 %:　　 　　Inmemory Sort %:　　　　　
　　Buffer　Hit<%重要的參數小於%可能是要加db_cache_size但是大量的非選擇的索引也會造成該值很高（大量的db file sequential read）
　　Library Hit　 %:　 　　　　Soft Parse %:　 　　　　
　　Library Hit<%要考慮加大共享池綁定變量修改cursor_sharing等
　　Execute to Parse %:　　　　　　 Latch Hit %:　 　　　　
　　Soft Parse<%需要考慮到綁定如果低於%那麼就可能sql基本沒有被重用
　　Parse CPU to Parse Elapsd %:　 　　 % NonParse CPU:　 　　　　
　　Latch Hit<%要確保>%否則存在嚴重的性能問題比如綁定等會影響該參數
　　
　　如果一個經常訪問的列上的索引被刪除可能會造成buffer hit 顯著的下降如果增加了索引但是他影響了ORACLE正確的選擇表連接時的驅動順序那麼可能會導致buffer hit 顯著增高如果你的命中率變化幅度很大說明你要改變SQL模式
　　
　　Shared Pool Statistics
　　　　　　　　　　　　　　　 Begin　 End
　　Memory Usage %:　　 　共享內存使用情況 %%都在正常范圍
　　% SQL with executions>:　 　 　
　　% Memory for SQL w/exec>:　 　 　
　　Top Timed Events
　　~~~~~~~~~~~~~~~~~~　　　　　　　　　　　　　　　　　　　　　　　　　　 % Total
　　Event　　　　　　　　　　　　　　　　　　 Waits　　Time (s) Ela Time
　　
　　CPU time　　　　　　　　　　　　　　　　 　　　　
　　db file sequential read　　　　　　　　 　　
　　db file scattered read　　　　　　　　 　　
　　buffer busy waits　　　　　　　　　　　 　　　　
　　log file sync　　　　　　　　　　　　　　　 　　　　　
　　
　　TIMED_STATISTICS = TRUE 那麼等待事件按等待的時間排序
　　= FALSE那麼事件按等待的數量排序
　　
　　常見事件
　　LOG FILE SYNC:　　　　　　　在每次提交時都出現如果這個等待事件影響到數據庫性能那麼就需要修改應用程序的提交頻率
　　
　　db file sequential read:　　 在單個數據塊上大量等待該值過高通常是由於表間連接順序很糟糕或者使用非選擇性的索引
　　
　　DB_CACHE_SIZE:　　　　　 可以決定該事件出現的頻率
　　
　　db file scattered read :　　意味著等待於全表掃描有關系通常全表掃描表數據放入內存中但是被申請到的內存高速緩沖的每個區可能不連續該值過大說明缺少索引或者限制了索引的使用(也可以調整optimizer_index_cost_adj)　 如果經常必須進行全表掃描而且表比較小 把該表存人keep池如果是大表經常進行全表掃描那麼應該是olap系統而不是oltp的
　　
　　buffer busy wait:　　當緩沖區以一種非共享方式或者如正在被讀入到緩沖時就會出現該等待該值不應該大於%確認是不是由於熱點塊造成(如果是可以用反轉索引或者用更小塊大小)
　　　
　　latch free:　　　　　　 常跟應用沒有很好的應用綁定有關
　　
　　Enqueue　 :　　　　　 最有可能是多個用戶同時修改同一個塊如果沒有空閒的ITL空間就會出現數據庫塊級鎖
　　
　　logfile switch:　　　　 通常是因為歸檔速度不夠快需要增大重做日志
　　
　　log buffer space:　　 日志緩沖區寫的速度快於LGWR寫REDOFILE的速度可以增大日志文件大小
　　
　　TOP SQL
　　調整首要的個緩沖區讀操作和首要的個磁盤讀操作做的查詢將可對系統性能產生%到%的增益　
　　
　　Instance Activity Stats for DB: CRMTEMP　Instance: crmtemp　Snaps: 　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　Statistic　　　　　　　　　　　Total　　 per Second　　per Trans　　　　　　　　　　　　　
　　
　　CPU used by this session　　　　　　 　　　　 　　
　　CPU used when call started　　　　 　　　　 　　
　　CR blocks created　　　　　　　　　　　　　　　　　　 　　
　　Cached Commit SCN referenced 　　　　　　　　　　　 　　
　　Commit SCN cached　　　　　　　　 　　　　　　　　　　　 　　
　　DBWR buffers scanned　　 　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　
　　DBWR checkpoint buffers written　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　DBWR checkpoints　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　dirty buffers inspected　　　　　　 　　　　　　　　　　　　髒緩沖的個數　　　　　　　　　　　　　　　　　　　　　　
　　free buffer inspected　　　　　　　　　　　　　　　　　　如果數量很大說明緩沖區過小
　　sorts (disk)　　　　　　　　　　　　　　　　　　　　　　　　　　　　不應當大於%
　　sorts (memory)　　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　
　　sorts (rows)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　summed dirty queue length　　　 　　　　　
From:http://tw.wingwit.com/Article/program/Oracle/201311/18914.html