开放平台应急方案场景v

1、文档版本日期文档版本号说明作者2011-12-18初稿隋志勋2012-9-131.1IBM 团队新增、修订部分内容刘辉数据库黄远邦2013-2-22增加子游标竟争处理(场境十二)黄远邦HP 应急场景涂星华2013-4-271.2应用系统应急方案: 场景一:个人识别系统出现故障影响BancsLink 系统子场景：负载均横器操作隋志勋、洪柳、刘玉第2013-4-271.2场景十五 SAN 网络出现问题，系统中关闭 HDLM 自动恢复开关场景十六 操作系统夯，做系统转储隋志勋2013-4-271.2场景二:签名服务器出现故障杨涛2013-6-261.3新增场景十三、十四，对场景 1 做部分修改黄远邦

2、2013-7-51.4新增系统类场景十七、十八、十九、二十崔增顺2013-8-211.5完善“系统类、硬件类”应急场境隋志勋、崔增顺2013-8-221.5完善“中间件类”应急场境郑金桥、张鹏升、曾宇2013-11-052.0增加 MQ 类场景十一，恢复死信队列消息隋志勋、海鹏2013-12-092.1增加 MQ 类场景十二，MQ 对象文件损坏隋志勋、海鹏2014-3-252.2完善“场景十六 操作系统内置硬盘故障” 增加若故障盘上存在“系统 dump郭杰、隋志勋、曾海设备”的处理2014-3-252.2完善“场景十 一块 HBA 光纤卡故障”隋志勋、何士华2014-3-252.2增加“WMQ

3、 类场景十三 MQ 集群的一个集群节点从 MQ 集群中”隋志勋2014-3-262.3增加“WAS 应急场景八 应用服务器启动失败，停留在“初始化状态”处长时间不动“丁华目录数据库类应急方案8场景一:数据库的两个节点中的一个 instance 异常宕掉8场景二: 数据库坏块恢复9场景三: 数据库挂起导致所有用户无法登陆数据库12场景四内存泄漏但系统可 telnet 登陆13场景五内存泄漏且系统无法 telnet15场景六数据库出现大量异常等待. 16场景七系统整体 CPU 使用率高17个别 CPU 使用率高18数据库报 ORA-403119场景八场景九场景十ASM 磁盘被赋 PVID21场景十

4、一大对象字段导致性能问题27场景十二子游标竞争29场景十三SQL(联机或批量)执行时间变长31场景十四挂起处理步骤33ORACLE XA中间件类应急方案35CICS 场景一：COR REGION 无法正常处理，但接受负载均衡器的分发35CICS 场景二：AOR REGION 无法正常处理，能接受 WLM 的分发37CICS 场景三：部分长. 39CICS 场景四：SFS SERVER 宕机40CICS 场景五：CICS XA 与 MQ 的连接报错42CICS 场景六：CICS XA 与 ORACLE 的连接报错43CICS 场景七：WLM 出现异常44CICS 场景八：繁忙，有排队，当前最大并

5、发不够45CICS 场景九： REGION 内存不够，REGION POOL 达到阀值46CTG 场景一：CTG 挂起，不可用47CTG 场景二：CTG 到 COR/AOR 连接中断，无法启动47WAS 类场景一WAS 应用服务器挂起48WAS 类场景二WAS 应用服务器 Crash49WAS 类场景三 WAS 应用服务器内存溢出51WAS 类场景四应用服务器 java 进程高 CPU52WAS 类场景五WAS 类场景六WAS 类场景七WAS 类场景八WAS过期，导致在管理台中看到节点状态异常54应用服务器由于 HA 问题启动失败65应用服务器启动缓慢，挂起在在 ZipFile.open 方法

6、65应用服务器启动失败，停留在“初始化状态”处长时间不动66HTTP Server 类场景一WEB 服务器不可用或者 httpd 进程不存在67HTTP Server 类场景二WEB 服务器高 CPU68HTTP Server 类场景三WEB 服务器 80 端口被占用69HTTP Server 类场景四WEB 服务器 access_log 日志中报大量 400，500 错误69HTTP Server 类场景五应用缓慢，存在大量半连接71Plug-in 类场景一 通过 IHS 端口无法WAS 上的动态页面，但通过 WAS 端口直接访问 WAS 上的页面，正常72Plug-in 类场景二 通过 I

7、HS 端口无法WAS 上的动态页面，但通过 WAS 端口直接访问 WAS 上的页面，正常，重启 IHS 后问题依然存在（即 Plugin 场景一未能解决问题），httpd.conf 指定错误的 plugin 路径73Plug-in 类场景三 通过 IHS 端口无法WAS 上的动态页面，但通过 WAS 端口直接访问 WAS 上的页面，正常，重启 IHS 后问题依然存在（即 Plugin 场景一、二均未能解决问题），未将应用到 IHS 和 WAS 服务器。73WMQ 类场景一WMQ 类场景二WMQ 类场景三WMQ 类场景四WMQ 类场景五队列管理器挂起75队列管理器异常终止76集群内单个队列管理器

8、集群信息错误77队列管理器启动失败并且报错日志损坏或不可用77通道状态 not running78WMQ 类场景六传输队列队列深度持续增长79WMQ 类场景七本地队列队列深度持续增长80WMQ 类场景八通道序列号不一致导致通道停止81WMQ 类场景九通道连接数达到最大值81WMQ 类场景十队列深度达到最大值82WMQ 类场景十一 恢复死信队列中的消息83WMQ 类场景十二 对象文件损坏85WMQ 类场景十三 MQ 集群的一个集群节点从 MQ 集群中. 85系统、硬件环境类应急方案86场景一整台物理故障86场景二AIX 操作系统自动重启88AIX 操作系统夯89操作系统彻底损坏无法启动91维护模

9、式进行操作系统恢复92场景三场景四场景五场景六一台以太网交换机故障95场景七一块以太网卡出现故障96场景八小型机 IO 背板损坏导致 etherchannel 异常，IO 背板损坏无法恢复99场景九一台 SAN 交换机故障100场景十一块 HBA 光纤卡故障100场景十一AIX 文件系统异常101场景十二进程不响应101场景十三系统内存使用率高102场景十四系统 CPU 使用率高102场景十五SAN 网络出现问题，系统中关闭 HDLM 自动恢复开关103场景十六操作系统内置硬盘故障103场景十七网络故障，收集 iptrace105恢复误删除的 LV105GPFS 文件系统 remount106

10、GPFS 文件系统 I/O 性能慢106工修改 VIO 虚拟化 NPIV 环境下的 wwpn107场景十八场景十九场景二十场景二十场景二十二 HMC 上的 LPAR profile 丢失108HP 系统环境类应急方案110场景一HP 操作系统启动不. 110场景二系统网络不通时110场景三系统集群状态不正常时；111应用系统应急方案112场景一:个人识别系统出现故障影响 BancsLink 系统112场景二:签名服务器出现故障116数据库类应急方案场景一:数据库的两个节点中的一个 instance 异常宕掉场景一及描述: 数据库的两个节点中的一个 instance 异常宕掉，操作系统也被crs

11、d 异常宕掉；数据库有两个节点，为 RAC 架构，oracle 会将故障节点的 oracle VIP 会切换到另一节点，因此其中任意一个数据库节点故障不影响应用，保证业务不受影响。应急措施:由于实例或节点 crash,会导致该实例上的连接断开，事务回滚。因此作为应急措施，必须：1）请应用团队确认是否有正在运行的批量被回滚导致批量异常，是否有必要重提批量请应用团队确认应用程序是否支持自动重连（中间件都支持）,如果不支持，之前连到该节点上的应用程序需要重启才可以连到存活节点。如果是节点宕机，则需要通过 netstat -in 确保 VIP 已经在漂移到其他存活节点。VIP 信息可以从/etc/ho

12、sts 中获取。2）3）另外，需根据实例宕的具体情况分析，并进行实例恢复。恢复过程如下： 检查系统环境、硬件环境，确定异常宕机的1)在故障节点上检查操作系统使用情况（使用 topas、nmon 或者 oswatcher,部署在/install/oswatcher/oswbb/archive 下），包括 CPU、内存和文件系统使用率2) 检查操作系统层次报错信息，对 errpt 中的 fscsi 和 hdisk 报错信息进行检查和分析3) 检查系统磁盘识别完全，无 defined 状态信息出现，同时检查 vg 可识别，两个节点 LV 的属主和权限均正确。4) 检查 rac 节点之间的网络通信，包

13、括对外 IP 和私网 IP，测试网络通信正常（可ping 通，且无丢包情况发生）5) 检查数据库两个节点的数据库 alert 日志文件6) 检查 HACMP 日志文件确定异常宕机的，把导致异常宕机的问题排除后，启动异常宕机的节点1) 启动 hacmp，仅启动故障节点的 hacmp 服务，启动后观察 hacmp.out 日志正常， 检查共享 vg 已被挂起，且为 concurrent 状态2) 检查 crs 进程是否被自动启动，在没有被 hacmp 自动拉起的情况下，执行crsctl start crs 命令启动3) 检查 crs_stat t 查看 rac 各相关服务均为 running 状态

14、4)检查数据库启动日志无 ORA-异常行，使用 sqlplus 登陆数据库实例，可进5)再次检查系统使用状态，包括 CPU、内存和 IO 状态6)通知应用团队检查应用运行状态场景二: 数据库坏块恢复场景二及描述:当出现磁盘损坏、链路问题或操作系统问题导致 IO 丢失、数据库 BUG 导致块格式错乱不可识别等情况下，oracle 数据库出现坏块，导致应用程序需要该坏块中的数据错 ORA-01578 或 ORA-600。根据坏块出现的数量和位置,业务受影响程度不尽相同。u磁盘物理损坏，导致大量坏块，则业务基本不可用，需要做数据文件级或者数据库全库级别的恢复。u出现个别坏块，但属于表 segment

15、 header block，该块是导航块，则对该表的访问将无法进行。根据该表在业务中的关键程度，业务受影响程度可小可大。u坏块是普通的数据块，并只损坏小量的则只是在需要该块坏的数据才受到影响，一般一个块涉及几十到几百条应急措施:1）坏块成因。对业务影响很小或可忽略。操作系统、导致出现坏块的、数据库相关技术检查操作系统环境、硬件环境，确定和影响范围，应用维护确认业务受影响范围。1、检查操作系统层次报错信息，对 errpt 中的 fscsi 和 hdisk 报错信息进行检查和分析2、检查系统磁盘识别完全，无 defined 状态信息出现，同时检查 vg 可识别ü 如果是磁盘损坏造成的坏块

16、，则需要进行更换硬盘等修复动作，等硬件修复后检查坏块是否已经修复，如果已修复则无需处理。如果问题依然存在，可以进入下面的修复环节。ü 如果无法进行更换磁盘操作，则新分配复环节。空间后在新的硬盘上进入恢2) 确定坏块的数量和影响范围选择不同的恢复方式1、根据 oracle alert 日志中的报错信息，确定坏块的个数和坏块所处的文件号和块号。2、通过 dbv file='/dev/rFile_name' blocksize= 命令检查坏块所在数据文件，通过检测结果可知是否还存在其他未被发现的坏块。3)确定块坏所属的对象和类型数据库 alert 日志或者界面会有具体坏块的

17、文件号和块号，通过以下查询即可知道坏块所属的对象和类型。DBV 检测结果中可能包含其他未被发现的含块的地址 RDBA（不包含文件和块号），需要使用以下 SQL 转换为文件号和块号，再使用上面的 SQL 语句的对象和类型。属于4)根据步骤 2 和 3 的检查结果，选择其中合适的一种或者几种方法结合的恢复方式。选择不同的恢复方式，将影响业务的可用性。ØØ如果坏块属于索引块，则重建索引即可完成处理。无需进入恢复环节。如果坏块属于数据块，且只有有限的几个，则进入 4.1 步骤，进行坏块修复。该恢复方式为，不影响坏块以外的业务进行，影响最小。Ø如果只是个别数据文件出现大量坏

18、块，则进入 4.2 的步骤，采用 rman 做数据文件级的恢复。该恢复方式数据库处于打开状态，但需要将个别数据文件离线再进行恢复，业务影响取决于该数据文件中的表的重要程度。如果 dbv 检查结果显示，不同的数据文件中均出现大量坏块，则进入 4.3 的步骤，采用 rman 做数据库全库恢复或者数据文件级的恢复。全库恢复方式下数据库需要停止，业务处于不可用的状态。Ø4.1 ）使用 rman blockrecover做坏块修复如果使用GPFS 文件系统存放归档日志，则跳过下面的两个步骤u 使用 NFS 方式将节点 2 的归档文件系统挂载到节点 1 当中。其中节点 1 上/etc/files

19、ystems 中必须有/arch2（NFS）的文件系统定义，options 参数如下所示/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 节点 1 上 mount /arch2mount 时必须显式或隐式的使用如下 mount 参数如果使用GPFS 文件系统存放归档日志，则跳过上面的两个步骤u 开始执行 rman blockrecover 块级别的修复u 修复后的验证完成修复后，进行业务测试确保之前出错的过 dbv 再次检测，确认块坏已经修复

21、。语句已恢复正常；或执行通4.2）使用 rman 做数据文件级修复u使用 NFS 方式将节点 2 的归档文件系统挂载到节点 1 当中。其中节点 1 上/etc/filesystems 中必须有/arch2（NFS）的文件系统定义，options 参数如下所示u节点 1 上 mount /arch2mount 时必须显式或隐式的使用如下 mount 参数u开始执行 rman 全库级别的修复$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 修复后的验证完成修复后，进行业务测试确保之前出错的过 dbv 再次检测，确认块坏已经修复。语句已恢复正常；或执行通4.3）使用 rman 做全库修复u使用 NFS 方式将节点 2 的归档文件系统挂载到节点 1 当中。其中节点 1 上/etc/filesystems 中必须有/arch2（NFS）的文件系统定义，options 参数如下所示u节点 1 上 mount /arch2mount 时必须显式或隐式的使用如下 mount 参数u开始执行 rman 全库级别的修复u修复后的验证完成修复后，进行业务测试确保之前出错的语句已恢复正常；或执行通过 dbv 再次检测，

25、确认块坏已经修复。场景三: 数据库挂起导致所有用户无法登陆数据库场景三及描述: 数据库挂起导致所有用户无法登陆数据库,可以 telnet,但是数据库普通用户和 sysdba 用户在 DB 服务器本机通过 sqlplus 登陆均挂起、无响应时适用该场景。该场景不适合归档文件系统满导致数据库挂起的简单场景。应急措施:1)信息收集$df g 确保 oracle 软件所在文件系统有 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、息收集完成后如果短期内无法分析问题重启数据库,无需通过重启操作系统的方式。，则杀掉 oracle进程即可场景四 内存泄漏但系统可 telnet 登陆场景四及描述:操作系统可以 telnet 但系统出现内存大量换页时，paging space利用率持续增长，此时可能出现可以登陆数据库和无法登陆数据库两种情况,此时适用该场景。应急措施:1)信息收集Ø 无法登陆数据库时由于数据库挂起，因此需要分两步走，先按照场景 2 收集造成挂起的信息， 再按照下列步骤收集导致内存泄漏的关键信息。root 用户登陆，从操作系统命令出消耗大量内存的进程号#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 进程的操作系统进程“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也可以通过调用下列两个 SQL 来抓取系统异常状态下的运行信息/tmp/lirl/Script/GatherHangAnglyze.sql /tmp/lirl/Script/GatherSysInfo.sqlØ 可以登陆数据库时oracle 用户，登陆数据库收集前 3 个最占用内存的操作系统进程号$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;-此处显示的结果为进

31、程占用内存从小到大的排序，查看第三列 spid 即可获得操作系统进程号-下面的SQL 语句出了这些进程正在执行的SQL 语句，即可找到泄seleid, a.serial#, a.status,然后 oracle 用户登陆使用-prelim 参数绕过无法登陆数据库的问题，收集前 3 个最占用内存的进程$sqlplus -prelim "/as sysdba"SQL>oradebug setospid XX -> XX 为操作系统进程号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 为固定的关键字，不需要修改同时收集操作系统信息（可选，时间情况下进行）root 用户登陆，从操作系统命令出消耗大量内存的进程号#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、例场景五 内存泄漏且系统无法 telnet场景五及描述:操作系统可以telnet,但是数据库普通用户和sysdba 用户在 DB 服务器本机通过 sqlplus 登陆均挂起、无响应时适用该场景。如果是个别前台进程占用大量内存导致，则杀掉该进程否则登陆数据库时使用下面方法正常重启实例$sqlplus “/as sysdba” SQL>shutdown immediate; SQL>startup;无法登陆使用上述方法重启时则ps ef|grep ora_pmonkill -9 “pmon 进程的操作系统进程“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 为操作系统进程号,依次收集最占用内存的前几个进程SQL>oradebug dump heapdump 536870917 SQL>oradebug dump processstate 10 SQL>oradebug tracefile_name SQL>oradebug short_stackSQL>oradebug short_stack说明：上述命令中的 536870917 和 10 为

36、固定的关键字，不需要修改同时收集操作系统信息（可选，时间情况下进行）root 用户登陆，从操作系统命令出消耗大量内存的进程号#svmon -Pt -t 20#ps aux|head -1;ps aux|grep -v grep|sort -n +4#truss p XX -XX 为进程号,收集 10 秒即可 ctrl+c 取消应急措施:1)信息收集:信息收集方法见场景 4。情况下通过 hmc 临时添加内存，登陆后扩充 Paging Space,然后进2)入信息收集、诊断以及环节即可,否则需要通过 hmc 重启操作系统所在分区，应该建立机制以便有充足时间收集信息和问题，避免出现这样连收集信息都不

37、可能的情况场景六 数据库出现大量异常等待场景六及描述:操作系统和数据库均可正常登陆，操作系统性能正常，但业务处理缓慢，检查 v$session 发现大量异常等待应急措施:时适合该场景。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)信息收集完成后如果短时间无法则可使用重启数据库的方式恢复生产。场景七 系统整体 CPU 使用率高场景七及描述: CPU 整体使用率高并且为 ORACLE 进程造成时适用该场景应急措施: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);-然后找到正在执行最消耗的SQL 语句并做数据库进程状态的收取即可,将awr 中的top sql 的sql_id 输入下面的SQL 语句即可获得正在执行最消耗的SQL 语句所在操作系统的进程号SQL>select b.spid from v$session a,v$process

42、 b where a.paddr=b.addr and a.sql_id=&sql_id;-根据上述进程$sqlplus “/as sysdba”SQL>oradebug setospid XX此处XX 为操作系统进程号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 为操作系统进程号SQL>oradebug dump processstate 10 SQL>oradebug short_stack; SQL>oradebug short_stack;然后root 用户登陆对个别几个异常的进程使用 truss p XX 抓取操作系统的调用信息2）一般来说，CPU 突然变高除了业务、某个业务模块的推广等正常业务场景外，

44、最常见的为执行计划走错，比如缺少合适索引、统计信息不正常或者绑定变量导致。需要具体问题做分析。场景八 个别 CPU 使用率高场景八及描述: topas 观察到个别 oracle 进程 CPU 使用率高,该进程高 CPU 使用率可能影响到整体性能应急措施:1)信息收集2）信息收集完成后可以进入诊断确认进程作用后杀掉该进程。环节，如果短时间无法并解决则可在$sqlplus “/as sysdba”-此处填入操作系统进程号即可获得该 SQL 语句的 sid 和 serial#以及其正在执行的 SQL,根据sid 和 seral#即可杀掉该会话$sqlplus “/as sysdba”SQL>-

45、先抓取一个AWR 快照SQL>exec dbms_workload_repository.create_snapshot;-然后对该进程进程抓取数据库进程状态的信息$sqlplus “/as sysdba”SQL>oradebug setospid XX此处XX 为操作系统进程号SQL>oradebug dump processstate 10 SQL>oradebug short_stack; SQL>oradebug short_stack;最后root 用户登陆对个别几个异常的进程使用 truss p XX 命令来抓取操作系统的系统调用信息即可（xx 为操作

46、系统进程号）缺少索引的解决办法create index &index_name on &table_name(&column_name) tablespace &tablespace;统计信息确的解决办法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 命令来抓取操作系统的系统调用信息即可（xx 为操作系统进程号）场景九 数据库报 ORA-4031场景九及描述:alert 日志报 ORA-4031 错误或系统前端报 ORA-4031 无法分配shared pool 的错误错误.该错误表示无法从 shared pool 中申请指定大小的连续内存，导致 SQL 语句错误，会话。一般与 shared pool 大小设置过小或者系统绑定变量使用不合理导致实例运行时间长后碎片严重有关系。出现该错误时，不需要硬的 SQL 语句可以继续

48、进行，但需要硬。的 SQL 语句将报错应急措施:1)信息收集2） 数据库可以登陆时有 3 种方案u 临时减少 db_cache_size,将较少的比如 500M 增加到 shared pool 当中，可以保$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 语句可能执行也同样报 ORA-4031 错误，不管是否报错，均执行以下信息收集，以下命令当 SQL 触发 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'-此处执行出错

50、的任意一个报错的 SQL 语句包括sysdba 执行数据库字段报 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;如果在数据库内无法终止会话，则再到操作系统使用 kill -9证系统恢复正常。为问题核查和信息收集、赢得时间u 清空 shared pool,系统可恢复正常u 重新启动实例3） 数据

52、库无法登陆时kill 掉早期登陆的 LOCAL=NO 的几个进程，以便部分空间使得使用sqlplus “/as sysdba”可以登陆，登陆后的处理步骤如下u临时减少 db_cache_size,将较少的比如 500M 增加到 shared pool 当中，可以保证系统恢复正常。为问题核查和信息收集、赢得时间u清空 shared pool,系统可恢复正常u重新启动实例$sqlplus “/as sysdba” SQL>shutdown immediate; SQL>startup;或者ps ef|grep ora_pmonkill -9 “pmon 进程的操作系统进程“$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、系统进程“$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”可以登陆，则重新启动实例以恢复生产，步骤如下场景十 ASM 磁盘被赋 PVID场景十及描述：当 ASM 磁盘组中有磁盘被本机或能认到该硬盘的其他 Lpar 通过chdev l hdiskX-a pv=yes 命令赋 PVID 后，将导致 ASM 磁盘头被破坏，磁盘组无法 mount， 进而导致数据库无法 open。应急措施：(1)检查 asm alert 日志手工挂载 ASM 磁盘组:alter diskgroup data_dg mount观察 asm alert 日志，报错如下:可以看到，由于无法认到磁盘组 data_dg 中 disk_number 为 10 的磁盘，