1.逐漸減速
突然放慢速度
3.時不時地放慢腳步
第壹種情況是“逐漸放緩”，要建立長效監控機制。例如，在每個繁忙的日子(通常
9~10
等等。)定期收集os、網絡、db和DB的信息，
每周發布壹份報告來分析收集到的信息。這些數據的積累可以決定以後的優化決策，並且
對於DBA來說，說服經理采納自己的決策可能是很重要的數據。DBA的價值體現在周報上。
第二種情況
“突然減速”也是最容易解決的。先從業務的角度，DB的使用和之前有什麽區別，然後把它做成壹個
步判斷。硬件/網絡故障通常會導致數據庫性能突然下降。
第壹步:檢查DB/OS/NETWORK的系統日誌，排除硬件/網絡問題。
第二步:查看數據庫中的等待事件，根據等待事件判斷可能出錯的環節。如果沒有等待事件，
您可以對數據庫進行故障排除。如果有等待時間，
根據不同的等待事件，找到這些事件的根本原因。
比如閂鎖釋放等與SQL解析相關的等待事件，OS的表現就是CPU利用率高。
與SQL磁盤讀取相關的等待時間，比如db文件散讀，說明iostat可以看到磁性。
磁盤讀寫的增加
第三步:檢查os、CPU/IO/內存等信息。
A.Cpu占用
CPU使用率與數據庫性能並不成反比。CPU使用率高並不意味著數據庫性能低。通常，優化
很好，而且業務量真的很大，
CPU占用率會很高，而且會平均分布在各個進程上。反之，CPU占用率會高，不代表數據。
圖書館的表現很好，
需要結合數據庫的等待事件來判斷高CPU利用率是否合理。
如果壹個進程的cpu使用率很高，那壹定是有問題。如果它不是oracle進程，您可以讓它運行
應用程序檢查程序是否有無限循環等漏洞。
如果是壹個oracle進程，可以根據pid查找oracle數據字典，查看這個進程的發起者，這個進程正在被執行
Sql語句，並等待事件。然後，
不同的情況用不同的方法解決。
b.超正析象管(Image Orthicon)
排除硬件的IO問題，數據庫突然變慢，壹般是壹條或幾條SQL語句造成的。
如果IO頻繁，可以通過優化磁盤讀取量高的TOP SQL來解決。當然，這也是解決IO問題最笨的方法。
最有效的方法。
OS和存儲的配置也是影響IO的壹個重要原因。
比如HP-unix下異步IO最常見的問題，如果DBA組沒有MLOCK權限，ORACLE就不使用AIO。
是的。
不幸的是，如果操作系統和數據庫的管理沒有很好地協調，這個配置將很容易被忽略。
c.記憶
第二種情況跟內存關系不大，只要SGA地區配置合理不變，壹般來說，只要不是
應用程序內存泄漏，
不會造成突然減速。
第三種情況是“不合時宜的減速”，這是最難解決的。現場出現問題的原因也是多方面的，也是最嚴重的。
重要的是，當出現緩慢現象時，
以最快的速度抓取最多的信息進行分析。先寫壹個shell腳本抓取數據，出現現象時及時處理。
按下回車鍵
壹個例子
數據庫突然變慢
背景:新應用上線後，數據庫突然變慢。
第壹步是研究新的應用。
據開發者介紹，所有的新應用都是訪問新建立的表，表的數據量很小，所以沒有復雜的SQL查詢。
查詢v＄SQL area分別按disk _ reads/buffer _ gets/executions和TOP SQL排序。
中沒有新應用的SQL。消除因訪問新應用的數據庫而導致的性能問題。
步驟2，檢查數據庫日誌/操作系統日誌。
您可以在數據庫日誌中看到許多ORA-7445錯誤和許多轉儲文件。分析轉儲文件(很久了，沒有。
可以引用轉儲文件。
具體細節無法描述。)，發現新應用程序通過dblink訪問遠程DB時生成轉儲文件，應用程序打開。
據說這是無法修改的，
Oracle也沒有相應的補丁解決方案。
操作系統日誌中沒有錯誤消息。
第三步，檢查statspack報告。
從等待事件來看，頂級事件是“緩沖區忙等待”和“數據庫文件並行寫入”
等於IO相關的等待事件。
根據緩沖區忙等待的統計，它正在等待數據塊。
還有壹些物理讀數等信息和之前相比並沒有太大異常。
表空間的iread/Writes也是正常的，但是wait明顯增加了。
初步確定是IO問題。
第四步，檢查操作系統的信息。
1.top命令(輸出為實驗室數據，僅供格式參考)
平均負載:0.05，0.10，0.09 10:18:32
307個進程:304個在睡覺，1個僵屍，1個停止，1個在cpu上
CPU狀態:96.0%空閑，0.3%用戶，2.6%內核，1.1% iowait，0.0%交換
內存:4096兆實數，2660兆空閑內存，1396兆正在使用的交換內存，3013兆空閑交換內存
PID用戶名THR優先級大小分辨率狀態時間CPU命令
11928 a 21562 1 0 3008k 2496k CPU/1 0:02 1.12% top
14965 mpgj 76 4 59 0 10M 3696k睡眠3:09 0.18% view_server
當時現場數據顯示iowait值比之前大很多，沒有出現異常過程。
2.SAR–D(輸出為實驗室數據，僅供格式參考)
SunOS sc 19 5.7 Generic _ 106541-42 sun4u 03/20/08
00:00:00設備%忙avque r+w/s blks/s avwait avserv
SD 410 17 0.4 50 1628 0.1 7.1
sd410，a 0 0.0 0 0.0 0.0
sd410，b 0 0.0 0 0 0.0 0.0
sd410，c 0 0 0.0 0 0.0 0.0 0.0
sd410，g 17 0.4 50 1628 0.1 7.1
當時現場數據顯示放數據文件的設備avwait，avque，blks/s值過高。
步驟5，檢查數據庫中的等待事件。
如果壹個大容量的數據庫性能不好，壹般來說會有大量的等待事件，幾百個非常
平時我壹般都是按照事件分組的。
Select count(*)，來自v＄session _ wait的事件，其中事件不在(' smon
計時器'，' pmon計時器'，' rdbms ipc消息'，'來自客戶端的SQL*Net消息')
按事件順序分組按1 desc；
輸出中顯示最多的等待事件是緩沖區忙等待。
進壹步分析，找出等待的原因。
Select count(*)，p1，p2，P3 from v＄session _ wait where event = ' buffer busy
按p1，p2，p3分組；
在緩沖區忙等待等待事件中。
P1 =文件編號
P2 =街區#
P3 = id(這個id對應等待的原因)
根據p1，p2，p3分組，目的是明確緩沖區忙等待集中在哪些對象上。
Metalink將緩沖區忙等待等待事件描述為以下段落:
如果P3顯示“緩沖區忙等待”正在等待塊讀取
完成，那麽阻塞會話可能會等待IO等待
(例如:“數據庫文件順序讀取”或“數據庫文件分散讀取”同樣適用
文件號和塊號。"
輸出結果顯示，等待分布在幾個不同的對象上，等待原因是“等待塊讀取”
完成”，對IO問題的進壹步分析。
如果，buffer busy waits正在等待關註壹個對象，這意味著有壹個熱塊。
通過添加freelist來重建該對象，並將freelist組添加到RAC環境中，可以解決這個問題。
您可以通過下面的SQL找到特定的對象。
Select owner，segment_name，segment_type from dba_extents其中file_id=P1
和block _ id+塊之間的P2；
P1，P2是上面v$session_wait找到的特定值。
第六步，明確原因，找出解決步驟。
分析:
1.磁盤的IO流量增加。
2.磁盤的IO等待增加。
3.IO流量為3。DB沒有增加。
4.4的IO等待。分貝增加。
從1，2，3，4可以推斷出，數據庫外的IO訪問磁盤。
查看磁盤配置，這個VG只存儲數據庫數據文件和數據庫系統文件。不包括數據文件，產生IO的數就是數。
根據數據庫系統文件。
壹般來說，數據庫系統文件不產生IO，只有日誌和轉儲文件可供IO讀寫。
結論:ora-7445產生的大量核心轉儲文件阻塞IO。
解決方案:
1.消除ora-7445。(如果不改變應用，就無法解決。)
2.將轉儲目錄指向另壹個VG。
3.讓oracle盡可能少地編寫核心轉儲文件。
後臺核心轉儲=部分
影子核心轉儲=部分