資源簡介
常見問題及處理方案
CPU使用率高的問題
通過操作系統命令top topas glance等查看top進程號,確認是系統進程還是oracle應用進程,查詢當前top進程執行的操作和sql語句進行分析。
根據進程號獲取正在執行的sql
SELECT a.osuser, a.username,b.address,b.hash_value, b.sql_text from v$session a, v$sqltext b, v$process p
where p.spid = &spid
and p.addr = a.paddr
and a.STATUS = 'ACTIVE'
and a.sql_address =b.address
order by address, piece;
數據庫無法連接
數據庫無法連接,一般可能是如下原因造成:
(1)數據庫宕了
(2)監聽異常
(3)數據庫掛起
(4)歸檔目錄滿
(5)數據庫或應用主機的網卡出現問題不能正常工作
(6)應用主機到數據庫主機的網絡出現問題。
1、數據庫宕了
立即啟動數據庫。
Startup
2、監聽異常
此時一般體現為:
監聽進程占用CPU資源大;d
監聽日志異常。
此時,立即重啟監聽,監聽重啟一般能在1分鐘之內完成。
Lsnrctl restart
3、數據庫掛起
立即重啟數據庫。
Startup
4、歸檔目錄滿
(1)在沒有部署OGG數據同步的情況下,立即清理歸檔日志文件。
(2)如果部署了OGG數據同步,查看OGG正在讀取的歸檔日志文件,立即
清理OGG不再需要的日志文件。
5、數據庫或應用主機的網卡出現問題不能正常工作。
立即聯系主機工程師處理。
6、應用主機到數據庫主機的網絡出現問題。
立即聯系網絡維護人員查看。
CRS/GI無法啟動
對于10g及11gR1版本的CRS問題
1、進入/tmp目錄下,看是否產生了crsctl.xxxxx文件
如果有的話,看文件內容,一般會提示OCR無法訪問,或者心跳IP無法
正常綁定等信息。
2、如果/tmp目錄下沒有crsctl.xxxxx文件
此時查看ocssd.log文件,看是否能從中得到有價值的信息。
可能的問題:網絡心跳不通。
3、/tmp目錄無crsctl.xxxxx且日志中沒有報錯信息,只有停CRS時的日志信
息。
此時可能是RAC兩個節點對并發裸設備的訪問有問題,此時考慮:
(1)停掉兩個節點的CRS。
(2)兩個節點先同時去激活并發VG,然后再激活VG。
(3)重新啟動CRS。
對于11gR2的GI問題
分析$GRID_HOME/log/nodename目錄下的日志文件,看是否能從中找出無法啟動的原因。
常見問題:
1、心跳IP不同。
2、ASM實例無法啟動。
對CRS的故障診斷和分析,參加本文檔中RAC部分的MOS文檔.
數據庫響應慢
應急處理步驟:
(1)找到占用CPU資源大的sql或者模塊,然后停掉此應用模塊。
(2)如果屬于由于種種原因引起的數據庫hang住情況,立即重啟數據
庫,此時重啟需要約15分鐘時間。
重要說明:
如果重啟數據庫的話,會有如下負面影響:
(1)要kill掉所有連接到數據庫中的會話,所有會話都會回滾。
(2)立即重啟的話,不能獲取并保留分析數據庫掛起原因的信息,在后續分析問題時,沒有足夠信息用于分析問題產生的根本原因。
一般正常重啟的話,都需要手動獲取用于分析數據庫重啟原因的信息,以便編寫分析報告,但是在最長情況下,獲取日志信息可能就要40分鐘時間。此時一般做systemstate dump,且如果是rac情況的話,需要2個節點都做,且需要做2次或以上。
常規處理步驟,分如下幾種情況處理:
(1)所有業務模塊都慢。
(2)部分業務模塊慢。
(3)數據庫hang住。
所有業務模塊都慢
此時首先查看系統資源,看是否屬于CPU資源使用率100%的問題,如果是,參考本章“CPU使用率高的問題”解決辦法。如果系統資源正常,那很可能是數據庫hang住了,此時參考數據庫Hang部分。
部分業務模塊慢
分析運行慢的模塊的sql語句:
(1)看是否是新上的sql。
(2)看執行計劃是否高效。
(3)優化運行慢的模塊的sql語句。
數據庫hang住
應急處理方式:重啟數據庫。
常規處理方式:
(1)分析alert日志,看是否能從alert日志中,可以很快找到引起問題的原
因。
(2)做3級別的hanganalyze,先做一次,然后隔一分鐘以后再做一次。
并分析
CPU使用率高的問題
通過操作系統命令top topas glance等查看top進程號,確認是系統進程還是oracle應用進程,查詢當前top進程執行的操作和sql語句進行分析。
根據進程號獲取正在執行的sql
SELECT a.osuser, a.username,b.address,b.hash_value, b.sql_text from v$session a, v$sqltext b, v$process p
where p.spid = &spid
and p.addr = a.paddr
and a.STATUS = 'ACTIVE'
and a.sql_address =b.address
order by address, piece;
數據庫無法連接
數據庫無法連接,一般可能是如下原因造成:
(1)數據庫宕了
(2)監聽異常
(3)數據庫掛起
(4)歸檔目錄滿
(5)數據庫或應用主機的網卡出現問題不能正常工作
(6)應用主機到數據庫主機的網絡出現問題。
1、數據庫宕了
立即啟動數據庫。
Startup
2、監聽異常
此時一般體現為:
監聽進程占用CPU資源大;d
監聽日志異常。
此時,立即重啟監聽,監聽重啟一般能在1分鐘之內完成。
Lsnrctl restart
3、數據庫掛起
立即重啟數據庫。
Startup
4、歸檔目錄滿
(1)在沒有部署OGG數據同步的情況下,立即清理歸檔日志文件。
(2)如果部署了OGG數據同步,查看OGG正在讀取的歸檔日志文件,立即
清理OGG不再需要的日志文件。
5、數據庫或應用主機的網卡出現問題不能正常工作。
立即聯系主機工程師處理。
6、應用主機到數據庫主機的網絡出現問題。
立即聯系網絡維護人員查看。
CRS/GI無法啟動
對于10g及11gR1版本的CRS問題
1、進入/tmp目錄下,看是否產生了crsctl.xxxxx文件
如果有的話,看文件內容,一般會提示OCR無法訪問,或者心跳IP無法
正常綁定等信息。
2、如果/tmp目錄下沒有crsctl.xxxxx文件
此時查看ocssd.log文件,看是否能從中得到有價值的信息。
可能的問題:網絡心跳不通。
3、/tmp目錄無crsctl.xxxxx且日志中沒有報錯信息,只有停CRS時的日志信
息。
此時可能是RAC兩個節點對并發裸設備的訪問有問題,此時考慮:
(1)停掉兩個節點的CRS。
(2)兩個節點先同時去激活并發VG,然后再激活VG。
(3)重新啟動CRS。
對于11gR2的GI問題
分析$GRID_HOME/log/nodename目錄下的日志文件,看是否能從中找出無法啟動的原因。
常見問題:
1、心跳IP不同。
2、ASM實例無法啟動。
對CRS的故障診斷和分析,參加本文檔中RAC部分的MOS文檔.
數據庫響應慢
應急處理步驟:
(1)找到占用CPU資源大的sql或者模塊,然后停掉此應用模塊。
(2)如果屬于由于種種原因引起的數據庫hang住情況,立即重啟數據
庫,此時重啟需要約15分鐘時間。
重要說明:
如果重啟數據庫的話,會有如下負面影響:
(1)要kill掉所有連接到數據庫中的會話,所有會話都會回滾。
(2)立即重啟的話,不能獲取并保留分析數據庫掛起原因的信息,在后續分析問題時,沒有足夠信息用于分析問題產生的根本原因。
一般正常重啟的話,都需要手動獲取用于分析數據庫重啟原因的信息,以便編寫分析報告,但是在最長情況下,獲取日志信息可能就要40分鐘時間。此時一般做systemstate dump,且如果是rac情況的話,需要2個節點都做,且需要做2次或以上。
常規處理步驟,分如下幾種情況處理:
(1)所有業務模塊都慢。
(2)部分業務模塊慢。
(3)數據庫hang住。
所有業務模塊都慢
此時首先查看系統資源,看是否屬于CPU資源使用率100%的問題,如果是,參考本章“CPU使用率高的問題”解決辦法。如果系統資源正常,那很可能是數據庫hang住了,此時參考數據庫Hang部分。
部分業務模塊慢
分析運行慢的模塊的sql語句:
(1)看是否是新上的sql。
(2)看執行計劃是否高效。
(3)優化運行慢的模塊的sql語句。
數據庫hang住
應急處理方式:重啟數據庫。
常規處理方式:
(1)分析alert日志,看是否能從alert日志中,可以很快找到引起問題的原
因。
(2)做3級別的hanganalyze,先做一次,然后隔一分鐘以后再做一次。
并分析
代碼片段和文件信息
- 上一篇:經典數據庫置疑修復工具
- 下一篇:Web超市在線管理系統
評論
共有 條評論