【正文】 常見(jiàn)問(wèn)題及處理方案CPU使用率高的問(wèn)題通過(guò)操作系統(tǒng)命令top topas glance等查看top進(jìn)程號(hào)，確認(rèn)是系統(tǒng)進(jìn)程還是oracle應(yīng)用進(jìn)程，查詢(xún)當(dāng)前top進(jìn)程執(zhí)行的操作和sql語(yǔ)句進(jìn)行分析。根據(jù)進(jìn)程號(hào)獲取正在執(zhí)行的sqlSELECT , , from v$session a, v$sqltext b, v$process pwhere = amp。spid and = and = 39。ACTIVE39。 and = order by address, piece。數(shù)據(jù)庫(kù)無(wú)法連接數(shù)據(jù)庫(kù)無(wú)法連接，一般可能是如下原因造成：（1）數(shù)據(jù)庫(kù)宕了（2）監(jiān)聽(tīng)異常（3）數(shù)據(jù)庫(kù)掛起（4）歸檔目錄滿(mǎn)（5）數(shù)據(jù)庫(kù)或應(yīng)用主機(jī)的網(wǎng)卡出現(xiàn)問(wèn)題不能正常工作（6）應(yīng)用主機(jī)到數(shù)據(jù)庫(kù)主機(jī)的網(wǎng)絡(luò)出現(xiàn)問(wèn)題。數(shù)據(jù)庫(kù)宕了立即啟動(dòng)數(shù)據(jù)庫(kù)。監(jiān)聽(tīng)異常此時(shí)一般體現(xiàn)為：監(jiān)聽(tīng)進(jìn)程占用CPU資源大；監(jiān)聽(tīng)日志異常。此時(shí)，立即重啟監(jiān)聽(tīng)，監(jiān)聽(tīng)重啟一般能在1分鐘之內(nèi)完成。數(shù)據(jù)庫(kù)掛起立即重啟數(shù)據(jù)庫(kù)。歸檔目錄滿(mǎn)（1）在沒(méi)有部署OGG數(shù)據(jù)同步的情況下，立即清理歸檔日志文件。（2）如果部署了OGG數(shù)據(jù)同步，查看OGG正在讀取的歸檔日志文件，立即清理OGG不再需要的日志文件。數(shù)據(jù)庫(kù)或應(yīng)用主機(jī)的網(wǎng)卡出現(xiàn)問(wèn)題不能正常工作。立即聯(lián)系主機(jī)工程師處理。應(yīng)用主機(jī)到數(shù)據(jù)庫(kù)主機(jī)的網(wǎng)絡(luò)出現(xiàn)問(wèn)題。立即聯(lián)系網(wǎng)絡(luò)維護(hù)人員查看。CRS/GI無(wú)法啟動(dòng)對(duì)于10g及11gR1版本的CRS問(wèn)題進(jìn)入/tmp目錄下，如果有的話(huà)，看文件內(nèi)容，一般會(huì)提示OCR無(wú)法訪(fǎng)問(wèn)，或者心跳IP無(wú)法正常綁定等信息。如果/，看是否能從中得到有價(jià)值的信息?？赡艿膯?wèn)題：網(wǎng)絡(luò)心跳不通。/，只有停CRS時(shí)的日志信息。此時(shí)可能是RAC兩個(gè)節(jié)點(diǎn)對(duì)并發(fā)裸設(shè)備的訪(fǎng)問(wèn)有問(wèn)題，此時(shí)考慮：（1）停掉兩個(gè)節(jié)點(diǎn)的CRS。（2）兩個(gè)節(jié)點(diǎn)先同時(shí)去激活并發(fā)VG，然后再激活VG。（3）重新啟動(dòng)CRS。對(duì)于11gR2的GI問(wèn)題分析$GRID_HOME/log/nodename目錄下的日志文件，看是否能從中找出無(wú)法啟動(dòng)的原因。常見(jiàn)問(wèn)題：心跳IP不同。ASM實(shí)例無(wú)法啟動(dòng)。對(duì)CRS的故障診斷和分析,參加本文檔中RAC部分的MOS文檔.數(shù)據(jù)庫(kù)響應(yīng)慢應(yīng)急處理步驟：（1）找到占用CPU資源大的sql或者模塊，然后停掉此應(yīng)用模塊。（2）如果屬于由于種種原因引起的數(shù)據(jù)庫(kù)hang住情況，立即重啟數(shù)據(jù)庫(kù)，此時(shí)重啟需要約15分鐘時(shí)間。重要說(shuō)明：如果重啟數(shù)據(jù)庫(kù)的話(huà)，會(huì)有如下負(fù)面影響：（1）要kill掉所有連接到數(shù)據(jù)庫(kù)中的會(huì)話(huà)，所有會(huì)話(huà)都會(huì)回滾。（2）立即重啟的話(huà)，不能獲取并保留分析數(shù)據(jù)庫(kù)掛起原因的信息，在后續(xù)分析問(wèn)題時(shí)，沒(méi)有足夠信息用于分析問(wèn)題產(chǎn)生的根本原因。 一般正常重啟的話(huà)，都需要手動(dòng)獲取用于分析數(shù)據(jù)庫(kù)重啟原因的信息，以便編寫(xiě)分析報(bào)告，但是在最長(zhǎng)情況下，獲取日志信息可能就要40分鐘時(shí)間。此時(shí)一般做systemstate dump，且如果是rac情況的話(huà)，需要2個(gè)節(jié)點(diǎn)都做，且需要做2次或以上。常規(guī)處理步驟，分如下幾種情況處理：（1）所有業(yè)務(wù)模塊都慢。（2）部分業(yè)務(wù)模塊慢。（3）數(shù)據(jù)庫(kù)hang住。所有業(yè)務(wù)模塊都慢此時(shí)首先查看系統(tǒng)資源，看是否屬于CPU資源使用率100%的問(wèn)題，如果是，參考本章“CPU使用率高的問(wèn)題”解決辦法。如果系統(tǒng)資源正常，那很可能是數(shù)據(jù)庫(kù)hang住了，此時(shí)參考數(shù)據(jù)庫(kù)Hang部分。部分業(yè)務(wù)模塊慢分析運(yùn)行慢的模塊的sql語(yǔ)句：（1）看是否是新上的sql。（2）看執(zhí)行計(jì)劃是否高效。（3）優(yōu)化運(yùn)行慢的模塊的sql語(yǔ)句。數(shù)據(jù)庫(kù)hang住應(yīng)急處理方式：重啟數(shù)據(jù)庫(kù)。常規(guī)處理方式：（1）分析alert日志，看是否能從alert日志中，可以很快找到引起問(wèn)題的原因。（2）做3級(jí)別的hanganalyze，先做一次，然后隔一分鐘以后再做一次。并分析hanganalyze 生成的trace文件，看是否可以找到引起數(shù)據(jù)庫(kù)hang住的會(huì)話(huà)的信息。（3）做systemstate dump此時(shí)生成systemstate dump的時(shí)間會(huì)比較長(zhǎng)，尤其是在會(huì)話(huà)數(shù)量較多的情況下。且生成dump文件的大小較大，在G級(jí)別以上。在生成一次以后，過(guò)一分鐘再收集一次，另外如果是RAC，那么兩個(gè)節(jié)點(diǎn)都需要收集。對(duì)hang做dump請(qǐng)參考“對(duì)數(shù)據(jù)庫(kù)HANG做DUMP一章”。數(shù)據(jù)誤刪除此問(wèn)題，沒(méi)有應(yīng)急辦法，只能按如下步驟處理：對(duì)于10g及以上版本，看是否可以通過(guò)閃回進(jìn)行恢復(fù)。查看測(cè)試環(huán)境數(shù)據(jù)庫(kù)，看其中是否有需要的數(shù)據(jù)。使用備份進(jìn)行恢復(fù)，此方法一般花費(fèi)時(shí)間較長(zhǎng)?？焖賡hutdown數(shù)據(jù)庫(kù)1. 停止監(jiān)聽(tīng)2. 做一個(gè)檢查點(diǎn)操作SQL alter system checkpoint。3. 殺掉所有LOCAL=NO的操作系統(tǒng)進(jìn)程AIX、HPUX、Linux、Solaris：$ ps ef|grep $ORACLE_SID| grep LOCAL=NO | grep v grep |awk 39。{print $2}39。|xargs i kill 9 {}Windows：SQL select 39。orakill 39。 ||(select value from v$parameter where name = 39。instance_name39。) || 39。 39。 ||from v$process p, v$bgprocess bpwhere = (+)and is nulland is not null。在命令行執(zhí)行：C:\ orakill db1 7642C:\ orakill db1 76444. 停止數(shù)據(jù)庫(kù)SQL shutdown immediate清理分布式事務(wù) 9i需要設(shè)置_sum_debug_modeSQL alter session set _smu_debug_mode = 4。 alter session set nls_date_format=39。YYYYMMDD HH24:MI:SS39。column local_trna_id format a20column global_tran_id format a25SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, FAIL_TIME,STATE, MIXED FROM DBA_2PC_PENDING。LOCAL_TRAN_ID GLOBAL_TRAN_ID FAIL_TIME STATE MIX 30aug2011 10:09:11 collecting noSQL mit force 39。39。 Commit plete.SQL EXECUTE (39。39。)。PL/SQL procedure successfully pleted.SQL mit。 清理每個(gè)分布式事務(wù)都需要mit。數(shù)據(jù)泵1. 相關(guān)參數(shù)PARALLEL參數(shù)考慮可以設(shè)置成物理CPU（不是邏輯CPU）數(shù)的兩倍數(shù)目，然后調(diào)整對(duì)于Data Pump Export，PARALLEL參數(shù)必須要小于等于dump files數(shù)對(duì)于Data Pump Import，PARALLEL不要比dump文件數(shù)大很多，可以大一些。這個(gè)參數(shù)也指定了導(dǎo)入時(shí)創(chuàng)建索引的并行度。PARALLEL只允許在企業(yè)版使用。nohup expdp system/manager schemas=kdjm DIRECTORY=DUMP_FILES PARALLEL=3 dumpfile=expCASES_% logfile= amp。通配符 %U,它指示文件將按需要?jiǎng)?chuàng)建,其中nn 從 01 開(kāi)始,然后按需要向上增加相關(guān)監(jiān)控 監(jiān)控長(zhǎng)事務(wù)set linesize 120column opname heading 39。Operation39。 format a25column target heading 39。Target39。 format a15column pct heading 39。Percent39。 format 999column es heading 39。Elapsed|Seconds39。 format 999999column tr heading 39。Time|Remaining|Seconds39。 format 99999column program format a30column machine format a16select ssid, substr(opname,1,25) opname, target, trunc((sofar/totalwork)*100) pct, to_char(60*sofar*8192/(24*60*(last_update_timestart_time))/1024/1024/60, 39。39。) Rate, round(elapsed_seconds/60, 2) es, round(time_remaining/60, 2) tr, program, machine from v$session_longops L, v$session s where time_remaining 0 and = order by start_time。壞塊恢復(fù)在遇到壞塊的時(shí)，一般應(yīng)按以下的流程來(lái)處理：1 如果壞塊的對(duì)象是索引，重建索引2 使用備份來(lái)進(jìn)行恢復(fù)3 使用10231事件，讓oracle跳過(guò)壞塊，然后用exp導(dǎo)出表和使用CREATE TABLE AS創(chuàng)建新表。4 嘗試使用SQL腳本將完好的數(shù)據(jù)復(fù)制到一個(gè)新表中，或者用EXP配合QUERY參數(shù)導(dǎo)出完好的數(shù)據(jù)。5 手工修改壞塊。：1 硬件問(wèn)題造成OS層不能讀取數(shù)據(jù)。2 表中的非數(shù)據(jù)塊，或者說(shuō)是元數(shù)據(jù)塊。比如段頭，Extent Map塊。這種壞塊是不能跳過(guò)的。3 在表中存在有其他異常的塊，從單個(gè)塊來(lái)看都沒(méi)有損壞，checksum值也是正確的，但是有的塊在段內(nèi)卻是有問(wèn)題的。比如在段的高水位下存在未格式化的塊，查詢(xún)這樣的表時(shí)，會(huì)報(bào)ORA8103錯(cuò)誤；如果塊的object id與段在數(shù)據(jù)字典里的data object id不相符，則會(huì)報(bào)ORA1401錯(cuò)誤。Oracle數(shù)據(jù)文件的壞塊，可分為物理壞塊和邏輯壞塊。物理壞塊（也稱(chēng)為介質(zhì)壞塊），指的是塊格式本身是壞的，塊內(nèi)的數(shù)據(jù)沒(méi)有任何意義。而邏輯壞塊，指的是塊內(nèi)的數(shù)據(jù)在邏輯上存在問(wèn)題。比如說(shuō)索引塊的索引值沒(méi)有按從小到大排列。物理壞塊一般是由于內(nèi)存問(wèn)題、OS問(wèn)題、IO子系統(tǒng)問(wèn)題和硬件問(wèn)題，邏輯壞塊是由于ORACLE BUG等原因引起。對(duì)數(shù)據(jù)庫(kù)中的壞塊進(jìn)行驗(yàn)證。RMAN backup validate database。恢復(fù)一個(gè)數(shù)據(jù)文件上的多個(gè)壞塊RMAN blockrecover datafile 14 block 56,107,276,517。檢驗(yàn)后我們查 V$DATABASE_BLOCK_CORRUPTIONSQL select * from v$database_block_corruption。 FILE BLOCK BLOCKS CORRUPTION_CHANGE CORRUPTIO 14 276 1 0 CHECKSUM 14 517 1 0 CHECKSUM 14 107 1 0 CHECKSUM 14 56 1 0 CHECKSUM還可以通過(guò)blockrecover corruption list進(jìn)行塊的恢復(fù)，這是在大量塊損壞時(shí)或全部塊損壞時(shí)使用，前提是先執(zhí)行backup validate database,在V$DATABASE_BLOCK_CORRUPTION里有對(duì)應(yīng)的壞塊的列表。RMAN blockrecover corruption list。SQL TUNINGSQL PROFILE創(chuàng)建PROFILEdeclare v_hhint 。 cl_sql_text clob。begin select SQL_TEXT into cl_sql_text from v$sql where sql_id = 39。1304vvhkfctzq39。 and rownum 2。 v_hhint := (39。BEGIN_OUTLINE_DATA39。, 39。IGNORE_OPTIM_EMBEDDED_HINTS39。, 39。OPTIMIZER_FEATURES_ENABLE(39。39。39。39。)39。, 39。ALL_ROWS39。, 39。OUTLINE_LEAF(@SEL$1)39。, 39。