開放平臺應(yīng)急方案場景v

1、文檔版本日期文檔版本號說明作者2011-12-18初稿隋志勛2012-9-131.1IBM 團隊新增、修訂部分內(nèi)容劉輝數(shù)據(jù)庫黃遠邦2013-2-22增加子游標(biāo)竟?fàn)幪幚?場境十二)黃遠邦HP 應(yīng)急場景涂星華2013-4-271.2應(yīng)用系統(tǒng)應(yīng)急方案: 場景一:個人識別系統(tǒng)出現(xiàn)故障影響B(tài)ancsLink 系統(tǒng)子場景：負載均橫器操作隋志勛、洪柳、劉玉第2013-4-271.2場景十五 SAN 網(wǎng)絡(luò)出現(xiàn)問題，系統(tǒng)中關(guān)閉 HDLM 自動恢復(fù)開關(guān)場景十六 操作系統(tǒng)夯，做系統(tǒng)轉(zhuǎn)儲隋志勛2013-4-271.2場景二:簽名服務(wù)器出現(xiàn)故障楊濤2013-6-261.3新增場景十三、十四，對場景 1 做部分修改黃遠邦

2、2013-7-51.4新增系統(tǒng)類場景十七、十八、十九、二十崔增順2013-8-211.5完善“系統(tǒng)類、硬件類”應(yīng)急場境隋志勛、崔增順2013-8-221.5完善“中間件類”應(yīng)急場境鄭金橋、張鵬升、曾宇2013-11-052.0增加 MQ 類場景十一，恢復(fù)死信隊列消息隋志勛、海鵬2013-12-092.1增加 MQ 類場景十二，MQ 對象文件損壞隋志勛、海鵬2014-3-252.2完善“場景十六 操作系統(tǒng)內(nèi)置硬盤故障” 增加若故障盤上存在“系統(tǒng) dump郭杰、隋志勛、曾海設(shè)備”的處理2014-3-252.2完善“場景十 一塊 HBA 光纖卡故障”隋志勛、何士華2014-3-252.2增加“WMQ

3、 類場景十三 MQ 集群的一個集群節(jié)點從 MQ 集群中”隋志勛2014-3-262.3增加“WAS 應(yīng)急場景八 應(yīng)用服務(wù)器啟動失敗，停留在“初始化狀態(tài)”處長時間不動“丁華目錄數(shù)據(jù)庫類應(yīng)急方案8場景一:數(shù)據(jù)庫的兩個節(jié)點中的一個 instance 異常宕掉8場景二: 數(shù)據(jù)庫壞塊恢復(fù)9場景三: 數(shù)據(jù)庫掛起導(dǎo)致所有用戶無法登陸數(shù)據(jù)庫12場景四內(nèi)存泄漏但系統(tǒng)可 telnet 登陸13場景五內(nèi)存泄漏且系統(tǒng)無法 telnet15場景六數(shù)據(jù)庫出現(xiàn)大量異常等待. 16場景七系統(tǒng)整體 CPU 使用率高17個別 CPU 使用率高18數(shù)據(jù)庫報 ORA-403119場景八場景九場景十ASM 磁盤被賦 PVID21場景十

4、一大對象字段導(dǎo)致性能問題27場景十二子游標(biāo)競爭29場景十三SQL(聯(lián)機或批量)執(zhí)行時間變長31場景十四掛起處理步驟33ORACLE XA中間件類應(yīng)急方案35CICS 場景一：COR REGION 無法正常處理，但接受負載均衡器的分發(fā)35CICS 場景二：AOR REGION 無法正常處理，能接受 WLM 的分發(fā)37CICS 場景三：部分長. 39CICS 場景四：SFS SERVER 宕機40CICS 場景五：CICS XA 與 MQ 的連接報錯42CICS 場景六：CICS XA 與 ORACLE 的連接報錯43CICS 場景七：WLM 出現(xiàn)異常44CICS 場景八：繁忙，有排隊，當(dāng)前最大并

5、發(fā)不夠45CICS 場景九： REGION 內(nèi)存不夠，REGION POOL 達到閥值46CTG 場景一：CTG 掛起，不可用47CTG 場景二：CTG 到 COR/AOR 連接中斷，無法啟動47WAS 類場景一WAS 應(yīng)用服務(wù)器掛起48WAS 類場景二WAS 應(yīng)用服務(wù)器 Crash49WAS 類場景三 WAS 應(yīng)用服務(wù)器內(nèi)存溢出51WAS 類場景四應(yīng)用服務(wù)器 java 進程高 CPU52WAS 類場景五WAS 類場景六WAS 類場景七WAS 類場景八WAS過期，導(dǎo)致在管理臺中看到節(jié)點狀態(tài)異常54應(yīng)用服務(wù)器由于 HA 問題啟動失敗65應(yīng)用服務(wù)器啟動緩慢，掛起在在 ZipFile.open 方法

6、65應(yīng)用服務(wù)器啟動失敗，停留在“初始化狀態(tài)”處長時間不動66HTTP Server 類場景一WEB 服務(wù)器不可用或者 httpd 進程不存在67HTTP Server 類場景二WEB 服務(wù)器高 CPU68HTTP Server 類場景三WEB 服務(wù)器 80 端口被占用69HTTP Server 類場景四WEB 服務(wù)器 access_log 日志中報大量 400，500 錯誤69HTTP Server 類場景五應(yīng)用緩慢，存在大量半連接71Plug-in 類場景一 通過 IHS 端口無法WAS 上的動態(tài)頁面，但通過 WAS 端口直接訪問 WAS 上的頁面，正常72Plug-in 類場景二 通過 I

7、HS 端口無法WAS 上的動態(tài)頁面，但通過 WAS 端口直接訪問 WAS 上的頁面，正常，重啟 IHS 后問題依然存在（即 Plugin 場景一未能解決問題），httpd.conf 指定錯誤的 plugin 路徑73Plug-in 類場景三 通過 IHS 端口無法WAS 上的動態(tài)頁面，但通過 WAS 端口直接訪問 WAS 上的頁面，正常，重啟 IHS 后問題依然存在（即 Plugin 場景一、二均未能解決問題），未將應(yīng)用到 IHS 和 WAS 服務(wù)器。73WMQ 類場景一WMQ 類場景二WMQ 類場景三WMQ 類場景四WMQ 類場景五隊列管理器掛起75隊列管理器異常終止76集群內(nèi)單個隊列管理器

8、集群信息錯誤77隊列管理器啟動失敗并且報錯日志損壞或不可用77通道狀態(tài) not running78WMQ 類場景六傳輸隊列隊列深度持續(xù)增長79WMQ 類場景七本地隊列隊列深度持續(xù)增長80WMQ 類場景八通道序列號不一致導(dǎo)致通道停止81WMQ 類場景九通道連接數(shù)達到最大值81WMQ 類場景十隊列深度達到最大值82WMQ 類場景十一 恢復(fù)死信隊列中的消息83WMQ 類場景十二 對象文件損壞85WMQ 類場景十三 MQ 集群的一個集群節(jié)點從 MQ 集群中. 85系統(tǒng)、硬件環(huán)境類應(yīng)急方案86場景一整臺物理故障86場景二AIX 操作系統(tǒng)自動重啟88AIX 操作系統(tǒng)夯89操作系統(tǒng)徹底損壞無法啟動91維護模

9、式進行操作系統(tǒng)恢復(fù)92場景三場景四場景五場景六一臺以太網(wǎng)交換機故障95場景七一塊以太網(wǎng)卡出現(xiàn)故障96場景八小型機 IO 背板損壞導(dǎo)致 etherchannel 異常，IO 背板損壞無法恢復(fù)99場景九一臺 SAN 交換機故障100場景十一塊 HBA 光纖卡故障100場景十一AIX 文件系統(tǒng)異常101場景十二進程不響應(yīng)101場景十三系統(tǒng)內(nèi)存使用率高102場景十四系統(tǒng) CPU 使用率高102場景十五SAN 網(wǎng)絡(luò)出現(xiàn)問題，系統(tǒng)中關(guān)閉 HDLM 自動恢復(fù)開關(guān)103場景十六操作系統(tǒng)內(nèi)置硬盤故障103場景十七網(wǎng)絡(luò)故障，收集 iptrace105恢復(fù)誤刪除的 LV105GPFS 文件系統(tǒng) remount106

10、GPFS 文件系統(tǒng) I/O 性能慢106工修改 VIO 虛擬化 NPIV 環(huán)境下的 wwpn107場景十八場景十九場景二十場景二十場景二十二 HMC 上的 LPAR profile 丟失108HP 系統(tǒng)環(huán)境類應(yīng)急方案110場景一HP 操作系統(tǒng)啟動不. 110場景二系統(tǒng)網(wǎng)絡(luò)不通時110場景三系統(tǒng)集群狀態(tài)不正常時；111應(yīng)用系統(tǒng)應(yīng)急方案112場景一:個人識別系統(tǒng)出現(xiàn)故障影響 BancsLink 系統(tǒng)112場景二:簽名服務(wù)器出現(xiàn)故障116數(shù)據(jù)庫類應(yīng)急方案場景一:數(shù)據(jù)庫的兩個節(jié)點中的一個 instance 異常宕掉場景一及描述: 數(shù)據(jù)庫的兩個節(jié)點中的一個 instance 異常宕掉，操作系統(tǒng)也被crs

11、d 異常宕掉；數(shù)據(jù)庫有兩個節(jié)點，為 RAC 架構(gòu)，oracle 會將故障節(jié)點的 oracle VIP 會切換到另一節(jié)點，因此其中任意一個數(shù)據(jù)庫節(jié)點故障不影響應(yīng)用，保證業(yè)務(wù)不受影響。應(yīng)急措施:由于實例或節(jié)點 crash,會導(dǎo)致該實例上的連接斷開，事務(wù)回滾。因此作為應(yīng)急措施，必須：1）請應(yīng)用團隊確認是否有正在運行的批量被回滾導(dǎo)致批量異常，是否有必要重提批量請應(yīng)用團隊確認應(yīng)用程序是否支持自動重連（中間件都支持）,如果不支持，之前連到該節(jié)點上的應(yīng)用程序需要重啟才可以連到存活節(jié)點。如果是節(jié)點宕機，則需要通過 netstat -in 確保 VIP 已經(jīng)在漂移到其他存活節(jié)點。VIP 信息可以從/etc/ho

12、sts 中獲取。2）3）另外，需根據(jù)實例宕的具體情況分析，并進行實例恢復(fù)?；謴?fù)過程如下： 檢查系統(tǒng)環(huán)境、硬件環(huán)境，確定異常宕機的1)在故障節(jié)點上檢查操作系統(tǒng)使用情況（使用 topas、nmon 或者 oswatcher,部署在/install/oswatcher/oswbb/archive 下），包括 CPU、內(nèi)存和文件系統(tǒng)使用率2) 檢查操作系統(tǒng)層次報錯信息，對 errpt 中的 fscsi 和 hdisk 報錯信息進行檢查和分析3) 檢查系統(tǒng)磁盤識別完全，無 defined 狀態(tài)信息出現(xiàn)，同時檢查 vg 可識別，兩個節(jié)點 LV 的屬主和權(quán)限均正確。4) 檢查 rac 節(jié)點之間的網(wǎng)絡(luò)通信，包

13、括對外 IP 和私網(wǎng) IP，測試網(wǎng)絡(luò)通信正常（可ping 通，且無丟包情況發(fā)生）5) 檢查數(shù)據(jù)庫兩個節(jié)點的數(shù)據(jù)庫 alert 日志文件6) 檢查 HACMP 日志文件確定異常宕機的，把導(dǎo)致異常宕機的問題排除后，啟動異常宕機的節(jié)點1) 啟動 hacmp，僅啟動故障節(jié)點的 hacmp 服務(wù)，啟動后觀察 hacmp.out 日志正常， 檢查共享 vg 已被掛起，且為 concurrent 狀態(tài)2) 檢查 crs 進程是否被自動啟動，在沒有被 hacmp 自動拉起的情況下，執(zhí)行crsctl start crs 命令啟動3) 檢查 crs_stat t 查看 rac 各相關(guān)服務(wù)均為 running 狀態(tài)

14、4)檢查數(shù)據(jù)庫啟動日志無 ORA-異常行，使用 sqlplus 登陸數(shù)據(jù)庫實例，可進5)再次檢查系統(tǒng)使用狀態(tài)，包括 CPU、內(nèi)存和 IO 狀態(tài)6)通知應(yīng)用團隊檢查應(yīng)用運行狀態(tài)場景二: 數(shù)據(jù)庫壞塊恢復(fù)場景二及描述:當(dāng)出現(xiàn)磁盤損壞、鏈路問題或操作系統(tǒng)問題導(dǎo)致 IO 丟失、數(shù)據(jù)庫 BUG 導(dǎo)致塊格式錯亂不可識別等情況下，oracle 數(shù)據(jù)庫出現(xiàn)壞塊，導(dǎo)致應(yīng)用程序需要該壞塊中的數(shù)據(jù)錯 ORA-01578 或 ORA-600。根據(jù)壞塊出現(xiàn)的數(shù)量和位置,業(yè)務(wù)受影響程度不盡相同。u磁盤物理損壞，導(dǎo)致大量壞塊，則業(yè)務(wù)基本不可用，需要做數(shù)據(jù)文件級或者數(shù)據(jù)庫全庫級別的恢復(fù)。u出現(xiàn)個別壞塊，但屬于表 segment

15、 header block，該塊是導(dǎo)航塊，則對該表的訪問將無法進行。根據(jù)該表在業(yè)務(wù)中的關(guān)鍵程度，業(yè)務(wù)受影響程度可小可大。u壞塊是普通的數(shù)據(jù)塊，并只損壞小量的則只是在需要該塊壞的數(shù)據(jù)才受到影響，一般一個塊涉及幾十到幾百條應(yīng)急措施:1）壞塊成因。對業(yè)務(wù)影響很小或可忽略。操作系統(tǒng)、導(dǎo)致出現(xiàn)壞塊的、數(shù)據(jù)庫相關(guān)技術(shù)檢查操作系統(tǒng)環(huán)境、硬件環(huán)境，確定和影響范圍，應(yīng)用維護確認業(yè)務(wù)受影響范圍。1、檢查操作系統(tǒng)層次報錯信息，對 errpt 中的 fscsi 和 hdisk 報錯信息進行檢查和分析2、檢查系統(tǒng)磁盤識別完全，無 defined 狀態(tài)信息出現(xiàn)，同時檢查 vg 可識別ü 如果是磁盤損壞造成的壞塊

16、，則需要進行更換硬盤等修復(fù)動作，等硬件修復(fù)后檢查壞塊是否已經(jīng)修復(fù)，如果已修復(fù)則無需處理。如果問題依然存在，可以進入下面的修復(fù)環(huán)節(jié)。ü 如果無法進行更換磁盤操作，則新分配復(fù)環(huán)節(jié)?？臻g后在新的硬盤上進入恢2) 確定壞塊的數(shù)量和影響范圍選擇不同的恢復(fù)方式1、根據(jù) oracle alert 日志中的報錯信息，確定壞塊的個數(shù)和壞塊所處的文件號和塊號。2、通過 dbv file='/dev/rFile_name' blocksize= 命令檢查壞塊所在數(shù)據(jù)文件，通過檢測結(jié)果可知是否還存在其他未被發(fā)現(xiàn)的壞塊。3)確定塊壞所屬的對象和類型數(shù)據(jù)庫 alert 日志或者界面會有具體壞塊的

17、文件號和塊號，通過以下查詢即可知道壞塊所屬的對象和類型。DBV 檢測結(jié)果中可能包含其他未被發(fā)現(xiàn)的含塊的地址 RDBA（不包含文件和塊號），需要使用以下 SQL 轉(zhuǎn)換為文件號和塊號，再使用上面的 SQL 語句的對象和類型。屬于4)根據(jù)步驟 2 和 3 的檢查結(jié)果，選擇其中合適的一種或者幾種方法結(jié)合的恢復(fù)方式。選擇不同的恢復(fù)方式，將影響業(yè)務(wù)的可用性。ØØ如果壞塊屬于索引塊，則重建索引即可完成處理。無需進入恢復(fù)環(huán)節(jié)。如果壞塊屬于數(shù)據(jù)塊，且只有有限的幾個，則進入 4.1 步驟，進行壞塊修復(fù)。該恢復(fù)方式為，不影響壞塊以外的業(yè)務(wù)進行，影響最小。Ø如果只是個別數(shù)據(jù)文件出現(xiàn)大量壞

18、塊，則進入 4.2 的步驟，采用 rman 做數(shù)據(jù)文件級的恢復(fù)。該恢復(fù)方式數(shù)據(jù)庫處于打開狀態(tài)，但需要將個別數(shù)據(jù)文件離線再進行恢復(fù)，業(yè)務(wù)影響取決于該數(shù)據(jù)文件中的表的重要程度。如果 dbv 檢查結(jié)果顯示，不同的數(shù)據(jù)文件中均出現(xiàn)大量壞塊，則進入 4.3 的步驟，采用 rman 做數(shù)據(jù)庫全庫恢復(fù)或者數(shù)據(jù)文件級的恢復(fù)。全庫恢復(fù)方式下數(shù)據(jù)庫需要停止，業(yè)務(wù)處于不可用的狀態(tài)。Ø4.1 ）使用 rman blockrecover做壞塊修復(fù)如果使用GPFS 文件系統(tǒng)存放歸檔日志，則跳過下面的兩個步驟u 使用 NFS 方式將節(jié)點 2 的歸檔文件系統(tǒng)掛載到節(jié)點 1 當(dāng)中。其中節(jié)點 1 上/etc/files

19、ystems 中必須有/arch2（NFS）的文件系統(tǒng)定義，options 參數(shù)如下所示/arch2:dev= "/arch2"vfs= nfsselectDBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE('&block_addr_in_DBV') file_number,DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK('&block_addr_in_DBV ') block_numberfrom dual;SELECT tablespace_name, segment_ty

20、pe, owner, segment_name, partition_nameFROM dba_extentsWHERE file_id = &file_idand &block_id between block_id AND block_id + blocks - 1;u 節(jié)點 1 上 mount /arch2mount 時必須顯式或隱式的使用如下 mount 參數(shù)如果使用GPFS 文件系統(tǒng)存放歸檔日志，則跳過上面的兩個步驟u 開始執(zhí)行 rman blockrecover 塊級別的修復(fù)u 修復(fù)后的驗證完成修復(fù)后，進行業(yè)務(wù)測試確保之前出錯的過 dbv 再次檢測，確認塊壞已經(jīng)修復(fù)

21、。語句已恢復(fù)正常；或執(zhí)行通4.2）使用 rman 做數(shù)據(jù)文件級修復(fù)u使用 NFS 方式將節(jié)點 2 的歸檔文件系統(tǒng)掛載到節(jié)點 1 當(dāng)中。其中節(jié)點 1 上/etc/filesystems 中必須有/arch2（NFS）的文件系統(tǒng)定義，options 參數(shù)如下所示u節(jié)點 1 上 mount /arch2mount 時必須顯式或隱式的使用如下 mount 參數(shù)u開始執(zhí)行 rman 全庫級別的修復(fù)$rman target /RMAN>alter database datafile &datafile_path offline; RMAN>restore datafile &d

22、atafile_path; RMAN>recover datafile &datafile_path;RMAN>alter database datafile &datafile_path online;“rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600”/arch2:dev= "/arch2"vfs= nfsnodename =node2 mount= trueoptions= rw,bg,hard,nointr,rsize=32768,wsize=3276

23、8,proto=tcp,vers=3,timeo=600 account= false$rman target /RMAN> blockrecover datafile &file_nameblock&block_number“rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600”nodename =node1 mount= trueoptions= rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600 a

24、ccount= falseu 修復(fù)后的驗證完成修復(fù)后，進行業(yè)務(wù)測試確保之前出錯的過 dbv 再次檢測，確認塊壞已經(jīng)修復(fù)。語句已恢復(fù)正常；或執(zhí)行通4.3）使用 rman 做全庫修復(fù)u使用 NFS 方式將節(jié)點 2 的歸檔文件系統(tǒng)掛載到節(jié)點 1 當(dāng)中。其中節(jié)點 1 上/etc/filesystems 中必須有/arch2（NFS）的文件系統(tǒng)定義，options 參數(shù)如下所示u節(jié)點 1 上 mount /arch2mount 時必須顯式或隱式的使用如下 mount 參數(shù)u開始執(zhí)行 rman 全庫級別的修復(fù)u修復(fù)后的驗證完成修復(fù)后，進行業(yè)務(wù)測試確保之前出錯的語句已恢復(fù)正常；或執(zhí)行通過 dbv 再次檢測，

25、確認塊壞已經(jīng)修復(fù)。場景三: 數(shù)據(jù)庫掛起導(dǎo)致所有用戶無法登陸數(shù)據(jù)庫場景三及描述: 數(shù)據(jù)庫掛起導(dǎo)致所有用戶無法登陸數(shù)據(jù)庫,可以 telnet,但是數(shù)據(jù)庫普通用戶和 sysdba 用戶在 DB 服務(wù)器本機通過 sqlplus 登陸均掛起、無響應(yīng)時適用該場景。該場景不適合歸檔文件系統(tǒng)滿導(dǎo)致數(shù)據(jù)庫掛起的簡單場景。應(yīng)急措施:1)信息收集$df g 確保 oracle 軟件所在文件系統(tǒng)有 5G 左右的剩余空間,時間緊急的情況下可以只做一次 hanganglyze 和$rman target /RMAN> shutdown immediate RMAN>startup mount RMAN>

26、restore database RMAN>recover dtabase; RMAN>alter database open;“rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600”/arch2:dev= "/arch2"vfs= nfsnodename =node1 mount= trueoptions= rw,bg,hard,nointr,rsize=32768,wsize=32768,proto=tcp,vers=3,timeo=600 account= false2)信

27、息收集完成后如果短期內(nèi)無法分析問題重啟數(shù)據(jù)庫,無需通過重啟操作系統(tǒng)的方式。，則殺掉 oracle進程即可場景四 內(nèi)存泄漏但系統(tǒng)可 telnet 登陸場景四及描述:操作系統(tǒng)可以 telnet 但系統(tǒng)出現(xiàn)內(nèi)存大量換頁時，paging space利用率持續(xù)增長，此時可能出現(xiàn)可以登陸數(shù)據(jù)庫和無法登陸數(shù)據(jù)庫兩種情況,此時適用該場景。應(yīng)急措施:1)信息收集Ø 無法登陸數(shù)據(jù)庫時由于數(shù)據(jù)庫掛起，因此需要分兩步走，先按照場景 2 收集造成掛起的信息， 再按照下列步驟收集導(dǎo)致內(nèi)存泄漏的關(guān)鍵信息。root 用戶登陸，從操作系統(tǒng)命令出消耗大量內(nèi)存的進程號#svmon -Pg -t 20 #svmon -Pt

28、 -t 20#ps aux|head -1;ps aux|grep -v grep|sort -n +4ps ef|grep ora_pmonkill -9 “pmon 進程的操作系統(tǒng)進程“systemstate dump.$sqlplus prelim “/as sysdba” SQL>oradebug setmypid SQL>oradebug hanganalyze 3 SQL>oradebug dump systemstate 266-此處等待 30 秒鐘SQL>oradebug hanganalyze 3 SQL>oradebug dump system

29、state 266 SQL>oradebug tracefile_name也可以通過調(diào)用下列兩個 SQL 來抓取系統(tǒng)異常狀態(tài)下的運行信息/tmp/lirl/Script/GatherHangAnglyze.sql /tmp/lirl/Script/GatherSysInfo.sqlØ 可以登陸數(shù)據(jù)庫時oracle 用戶，登陸數(shù)據(jù)庫收集前 3 個最占用內(nèi)存的操作系統(tǒng)進程號$sqlplus "/as sysdba" select * from gv$pgastat; seleid,a.serial#, a.status, b.spid, a.username,

30、a.sql_id, a.last_call_et,round(b.PGA_USED_MEM/1024/1024,0) PGA_USED_MEM_M , round(b.PGA_ALLOC_MEM/1024/1024,0) PGA_ALLOC_MEM_M, round(b.PGA_MAX_MEM/1024/1024,0) PGA_MAX_MEM_Mfrom v$session a, v$process b wherea.paddr = b.addrand PGA_ALLOC_MEM / 1024 / 1024 > 200order by b.PGA_ALLOC_MEM;-此處顯示的結(jié)果為進

31、程占用內(nèi)存從小到大的排序，查看第三列 spid 即可獲得操作系統(tǒng)進程號-下面的SQL 語句出了這些進程正在執(zhí)行的SQL 語句，即可找到泄seleid, a.serial#, a.status,然后 oracle 用戶登陸使用-prelim 參數(shù)繞過無法登陸數(shù)據(jù)庫的問題，收集前 3 個最占用內(nèi)存的進程$sqlplus -prelim "/as sysdba"SQL>oradebug setospid XX -> XX 為操作系統(tǒng)進程號SQL>oradebug dump heapdump 536870917 SQL>oradebug dump proce

32、ssstate 10 SQL>oradebug tracefile_name SQL>oradebug short_stackSQL>oradebug short_stack說明：上述命令中的 536870917 和 10 為固定的關(guān)鍵字，不需要修改同時收集操作系統(tǒng)信息（可選，時間情況下進行）root 用戶登陸，從操作系統(tǒng)命令出消耗大量內(nèi)存的進程號#svmon -Pg -t 20 #svmon -Pt -t 20#ps aux|head -1;ps aux|grep -v grep|sort -n +4#truss p XX -XX 為進程號2)殺掉個別前臺進程或者重新啟動實

33、例場景五 內(nèi)存泄漏且系統(tǒng)無法 telnet場景五及描述:操作系統(tǒng)可以telnet,但是數(shù)據(jù)庫普通用戶和sysdba 用戶在 DB 服務(wù)器本機通過 sqlplus 登陸均掛起、無響應(yīng)時適用該場景。如果是個別前臺進程占用大量內(nèi)存導(dǎo)致，則殺掉該進程否則登陸數(shù)據(jù)庫時使用下面方法正常重啟實例$sqlplus “/as sysdba” SQL>shutdown immediate; SQL>startup;無法登陸使用上述方法重啟時則ps ef|grep ora_pmonkill -9 “pmon 進程的操作系統(tǒng)進程“b.spid, a.username, a.last_call_et,rou

34、nd(b.PGA_USED_MEM/1024/1024,0) PGA_USED_MEM_M , round(b.PGA_ALLOC_MEM/1024/1024,0) PGA_ALLOC_MEM_M, round(b.PGA_MAX_MEM/1024/1024,0) PGA_MAX_MEM_M,gram,a.machine,a.username c.sql_textfrom v$session a, v$process b, v$sqltext c where a.paddr = b.addrand a.sql_id = c.sql_idand b.PGA_ALLOC_MEM / 10

35、24 / 1024 > 200order by a.sid,a.serial#,c.piece;SQL>oradebug setospid XX -> XX 為操作系統(tǒng)進程號,依次收集最占用內(nèi)存的前幾個進程SQL>oradebug dump heapdump 536870917 SQL>oradebug dump processstate 10 SQL>oradebug tracefile_name SQL>oradebug short_stackSQL>oradebug short_stack說明：上述命令中的 536870917 和 10 為

36、固定的關(guān)鍵字，不需要修改同時收集操作系統(tǒng)信息（可選，時間情況下進行）root 用戶登陸，從操作系統(tǒng)命令出消耗大量內(nèi)存的進程號#svmon -Pt -t 20#ps aux|head -1;ps aux|grep -v grep|sort -n +4#truss p XX -XX 為進程號,收集 10 秒即可 ctrl+c 取消應(yīng)急措施:1)信息收集:信息收集方法見場景 4。情況下通過 hmc 臨時添加內(nèi)存，登陸后擴充 Paging Space,然后進2)入信息收集、診斷以及環(huán)節(jié)即可,否則需要通過 hmc 重啟操作系統(tǒng)所在分區(qū)，應(yīng)該建立機制以便有充足時間收集信息和問題，避免出現(xiàn)這樣連收集信息都不

37、可能的情況場景六 數(shù)據(jù)庫出現(xiàn)大量異常等待場景六及描述:操作系統(tǒng)和數(shù)據(jù)庫均可正常登陸，操作系統(tǒng)性能正常，但業(yè)務(wù)處理緩慢，檢查 v$session 發(fā)現(xiàn)大量異常等待應(yīng)急措施:時適合該場景。1)信息收集$sqlplus “/as sysdba”SQL>-先抓取一個AWR 快照SQL>exec dbms_workload_repository.create_snapshot;SQL>set markup html on SQL>spool ./WaitEvent.htmlSQL> select event,count(*) from v$session group by

38、event order by 2; SQL> select * from gv$session;SQL> select * from gv$lock order by type; SQL> select * from gv$transaction;SQL> select * from gv$latchholder;-此處等待 10 秒SQL> select event,count(*) from v$session group by event order by 2; SQL> select * from gv$session;SQL> select

39、* from gv$lock order by type; SQL> select * from gv$transaction;SQL> select * from gv$latchholder; SQL>spool offSQL>set markup html off SQL>quit$sqlplus “/as sysdba” SQL>oradebug setmypid SQL>oradebug hanganalyze 3 SQL>oradebug dump systemstate 266-此處等待 30 秒鐘SQL>oradebug h

40、anganalyze 32)信息收集完成后如果短時間無法則可使用重啟數(shù)據(jù)庫的方式恢復(fù)生產(chǎn)。場景七 系統(tǒng)整體 CPU 使用率高場景七及描述: CPU 整體使用率高并且為 ORACLE 進程造成時適用該場景應(yīng)急措施:1)信息收集$sqlplus “/as sysdba”SQL>-先抓取一個AWR 快照SQL>exec dbms_workload_repository.create_snapshot;-然后出最近一段時間的awr 報告SQL>?/rdbms/admin/awrrpt.sql-然后對awr 中的最消耗的SQL 語句出 awrsq 報告SQL>?/rdbms/ad

41、min/awrsqrpt.sqlSQL>select * from table(dbms_xplan.display_cursor(&sql_id,0,ADVANCED); SQL>select * from table(dbms_xplan.display_awr(&sql_id);-然后找到正在執(zhí)行最消耗的SQL 語句并做數(shù)據(jù)庫進程狀態(tài)的收取即可,將awr 中的top sql 的sql_id 輸入下面的SQL 語句即可獲得正在執(zhí)行最消耗的SQL 語句所在操作系統(tǒng)的進程號SQL>select b.spid from v$session a,v$process

42、 b where a.paddr=b.addr and a.sql_id=&sql_id;-根據(jù)上述進程$sqlplus “/as sysdba”SQL>oradebug setospid XX此處XX 為操作系統(tǒng)進程號SQL>oradebug dump processstate 10 SQL>oradebug short_stack; SQL>oradebug short_stack;$sqlplus “/as sysdba” SQL>shutdown immediate; SQL>startup;SQL>oradebug dump syst

43、emstate 266 SQL>oradebug tracefile_name-對個別幾個異常的進程抓取進程級的信息$sqlplus “/as sysdba”SQL>oradebug setospid XX此處XX 為操作系統(tǒng)進程號SQL>oradebug dump processstate 10 SQL>oradebug short_stack; SQL>oradebug short_stack;然后root 用戶登陸對個別幾個異常的進程使用 truss p XX 抓取操作系統(tǒng)的調(diào)用信息2）一般來說，CPU 突然變高除了業(yè)務(wù)、某個業(yè)務(wù)模塊的推廣等正常業(yè)務(wù)場景外，

44、最常見的為執(zhí)行計劃走錯，比如缺少合適索引、統(tǒng)計信息不正常或者綁定變量導(dǎo)致。需要具體問題做分析。場景八 個別 CPU 使用率高場景八及描述: topas 觀察到個別 oracle 進程 CPU 使用率高,該進程高 CPU 使用率可能影響到整體性能應(yīng)急措施:1)信息收集2）信息收集完成后可以進入診斷確認進程作用后殺掉該進程。環(huán)節(jié)，如果短時間無法并解決則可在$sqlplus “/as sysdba”-此處填入操作系統(tǒng)進程號即可獲得該 SQL 語句的 sid 和 serial#以及其正在執(zhí)行的 SQL,根據(jù)sid 和 seral#即可殺掉該會話$sqlplus “/as sysdba”SQL>-

45、先抓取一個AWR 快照SQL>exec dbms_workload_repository.create_snapshot;-然后對該進程進程抓取數(shù)據(jù)庫進程狀態(tài)的信息$sqlplus “/as sysdba”SQL>oradebug setospid XX此處XX 為操作系統(tǒng)進程號SQL>oradebug dump processstate 10 SQL>oradebug short_stack; SQL>oradebug short_stack;最后root 用戶登陸對個別幾個異常的進程使用 truss p XX 命令來抓取操作系統(tǒng)的系統(tǒng)調(diào)用信息即可（xx 為操作

46、系統(tǒng)進程號）缺少索引的解決辦法create index &index_name on &table_name(&column_name) tablespace &tablespace;統(tǒng)計信息確的解決辦法exec dbms_stats.gather_table_stats(&owner,&tb_name,no_invalidate => false,estimate_percent => 3,degree => &degree );綁定變量的解決辦法選擇SQL 中的任意一張較小的表對其做 DDL 即可 alter tab

47、le &tb_name noparalle;最后root 用戶登陸對個別幾個異常的進程使用 truss p XX 命令來抓取操作系統(tǒng)的系統(tǒng)調(diào)用信息即可（xx 為操作系統(tǒng)進程號）場景九 數(shù)據(jù)庫報 ORA-4031場景九及描述:alert 日志報 ORA-4031 錯誤或系統(tǒng)前端報 ORA-4031 無法分配shared pool 的錯誤錯誤.該錯誤表示無法從 shared pool 中申請指定大小的連續(xù)內(nèi)存，導(dǎo)致 SQL 語句錯誤，會話。一般與 shared pool 大小設(shè)置過小或者系統(tǒng)綁定變量使用不合理導(dǎo)致實例運行時間長后碎片嚴重有關(guān)系。出現(xiàn)該錯誤時，不需要硬的 SQL 語句可以繼續(xù)

48、進行，但需要硬。的 SQL 語句將報錯應(yīng)急措施:1)信息收集2） 數(shù)據(jù)庫可以登陸時有 3 種方案u 臨時減少 db_cache_size,將較少的比如 500M 增加到 shared pool 當(dāng)中，可以保$sqlplus “/as sysdba” SQL>set markup html on SQL>spool ./Ora4031.htmlSQL> select * from V$SHARED_POOL_; SQL> select * from v$sgastat;SQL> select * from v$sga_resize_ops; SQL>spool

49、 offSQL>set markup html off這里，上述 SQL 語句可能執(zhí)行也同樣報 ORA-4031 錯誤，不管是否報錯，均執(zhí)行以下信息收集，以下命令當(dāng) SQL 觸發(fā) ORA-4031 錯誤時會收集其 heapdump 和 callStack 信息SQL> alter session set events '4031 trace name errorstack level 3'SQL> alter session set events '4031 trace name HEAPDUMP level 536870915'-此處執(zhí)行出錯

50、的任意一個報錯的 SQL 語句包括sysdba 執(zhí)行數(shù)據(jù)庫字段報 ORA-4031 錯誤的那個 SQL 語句SQL> alter session set events '4031 trace name errorstack off' SQL> alter session set events '4031 trace name HEAPDUMP level 0' SQL> oradebug setmypidSQL> oradebug tracefile_name-此處顯示的文件名就是收集到的 trace 名字SQL>selecta.s

51、id,a.serial#,b.sql_textfromv$sessiona,v$sqltextb,v$processcwhere a.paddr=c.addr and a.sql_id=c.sql_id and c.spid=&os_process_id order by a.sid,b.piece;SQL>alter system kill session &sid,&serial;如果在數(shù)據(jù)庫內(nèi)無法終止會話，則再到操作系統(tǒng)使用 kill -9證系統(tǒng)恢復(fù)正常。為問題核查和信息收集、贏得時間u 清空 shared pool,系統(tǒng)可恢復(fù)正常u 重新啟動實例3） 數(shù)據(jù)

52、庫無法登陸時kill 掉早期登陸的 LOCAL=NO 的幾個進程，以便部分空間使得使用sqlplus “/as sysdba”可以登陸，登陸后的處理步驟如下u臨時減少 db_cache_size,將較少的比如 500M 增加到 shared pool 當(dāng)中，可以保證系統(tǒng)恢復(fù)正常。為問題核查和信息收集、贏得時間u清空 shared pool,系統(tǒng)可恢復(fù)正常u重新啟動實例$sqlplus “/as sysdba” SQL>shutdown immediate; SQL>startup;或者ps ef|grep ora_pmonkill -9 “pmon 進程的操作系統(tǒng)進程“$sqlpl

53、us “/as sysdba”SQL>alter system flush shared_pool;$sqlplus “/as sysdba”SQL>alter system set db_cache_size= &a_value_smaller; SQL>alter system setshared_pool_size=&a_value_bigger ;$sqlplus “/as sysdba” SQL>shutdown immediate; SQL>startup;或者ps ef|grep ora_pmonkill -9 “pmon 進程的操作

54、系統(tǒng)進程“$sqlplus “/as sysdba”SQL>alter system flush shared_pool;$sqlplus “/as sysdba”SQL>alter system set db_cache_size= &a_value_smaller; SQL>alter system setshared_pool_size=&a_value_bigger ;如果 kill 掉早期登陸的 LOCAL=NO 的幾個進程，仍然無法使用 sqlplus “/assysdba”可以登陸，則重新啟動實例以恢復(fù)生產(chǎn)，步驟如下場景十 ASM 磁盤被賦 PVID場景十及描述：當(dāng) ASM 磁盤組中有磁盤被本機或能認到該硬盤的其他 Lpar 通過chdev l hdiskX-a pv=yes 命令賦 PVID 后，將導(dǎo)致 ASM 磁盤頭被破壞，磁盤組無法 mount， 進而導(dǎo)致數(shù)據(jù)庫無法 open。應(yīng)急措施：(1)檢查 asm alert 日志手工掛載 ASM 磁盤組:alter diskgroup data_dg mount觀察 asm alert 日志，報錯如下:可以看到，由于無法認到磁盤組 data_dg 中 disk_number 為 10 的磁盤，