當資料庫變慢時，我們應如何入手
第一章 檢查系統的狀態
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的方式；
ø 打全補丁，防止記憶體漏洞。
可以換成：
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.module, 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） 其他引數可以不特別觀注。
當資料庫發生災難時
當資料庫發生災難時 sql server 資料庫當發生災難時，需要立即檢查資料庫還留下什麼檔案，並且根據留下的檔案制定出恢復計畫 留下的檔案 無日誌檔案 日誌檔案受損 日誌檔案完整 無資料檔案 1 使用以前的資料備份恢復到最後乙個備份時 2 同 1 3 首先進行尾日誌備份 並結合以前的備份，可將資料...
當忘記mysql資料庫密碼時如何進行修改
因為長時間沒有使用資料庫了，或者把密碼改完之後就忘了資料庫密碼，不能正常進入資料庫，也無法修改密碼，有乙個簡單的常用修改密碼方式 1.首先找到和開啟mysql.exe和mysqld.exe所在的資料夾 在你所安裝的mysql的bin資料夾下 複製路徑位址。2.windows r開啟cmd命令提示符，...
如何對資料庫響應變慢進行優化
1 show status show session status like 字串 來檢視最近伺服器都在處理什麼內容，是以查詢還是以更新為主 得到資訊包括 訪問最多的資料 執行的最多的查詢種類 停留時間最長的狀態 用來執行查詢使用的最頻繁的子系統 查詢過程中訪問的資料種類 執行了多少種不同型別的活動...