ITPub博客

故障说明XX银行数据库二代支付系统业务，在12月13日晚22点出现插入数据卡顿的现象，插入数据的业务表为JHB_IBPS_TXN故障描述工程师分析在22点的数据库等待事件，发现有1000多条的library cache lock等待事件  通过分析22点的历史等待事件发现，所有的会话都被931、以及859的会话锁住，产生了library cache lock的等待事件故障分析当

故障说明在12月19日晚19点半左右，客户收到内部告警信息，二节点集群无法连接服务器，并且通过显示器直连服务器时，任然无法直接连接。故障描述12月19日故障，工程师分析故障时间点集群日志，在17点53分到18点50分之前，都存在大量线程未分配的报错 故障分析查看2022年12月19日2节点的主机日志，发现报大量的内核死锁故障，从而导致后面主机卡死，即使显示器直连服务器也是连接不上。&nb

故障说明在12月27日凌晨5点左右，客户收到业务告警业务无法正常运行，6点半左右将service name服务移到2节点，并且重启1节点主机，恢复业务。故障描述12月27日故障，工程师分析故障时间点数据库alert日志发现大量缓冲区不足的报错，从12月27日00:54分开始一直报错到早上6点半重启数据库。 故障分析12月27日的报错完全匹配上oracle mos上的（Doc ID 204

常用历史语句：dba_hist_active_sess_historyv$active_session_historydba_hist_sqlstat  dba_hist_active_sess_historydba_hist_active_sess_history是v$active_session_history的持久化视图。多个触发条件写入dba视图中。 mmon

汇总：硬解析Hard parses解决方法：1.绑定变量2.看shared pool是否太小或者变小（子游标放在Sga-shared pool-library cache）awr 搜shared pool可以看到大小改变：这时候如果出现大量的硬解析，就会出现这个等待。最终的原因是因为一个全表扫描导致oracle的SGA自动管理把share pool缩小来增大DB CACHE，踢出去了一部分的执行计

按1可以看每个cpu的使用情况第一行当前时间   运行时间   当前登陆用户   负载均衡（1分钟、5分钟、10分钟）load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了第二行总共248个进程    &nbsp

故障描述2023年06月30号，客户应用反馈imagedb数据库无法登录。原因分析检查cpu使用正常；内存耗尽只剩余200M左右的空间。检查会话，大概有800个左右的会话，如下图所示： 检查执行计划： 经过检查，SQL走IDX_SER_CKINVOICE_NUM这个索引是没有问题的，执行计划没有问题。检查活动会话的等待事件：EVENT      &

可能性1：rac参数文件没有*.cluster_database=true可能性2：原因：实例已经关闭，但是共享内存段还存在。oracle认为内存还是锁住的。1.到dbs下，可以看到一个lkabcd(abcd是实例名，=lk实例名)2.mv掉lkabcd3.注意用大小写ps -ef |grep ora_ |grep abcd存在后台进程的话kill掉即可kill -9 xxxxx4.起库即可

ORA-03137: TTC 协议内部错误: [12333] [11] [88] [72] [] [] [] []

大概率删除备份片的时候，想删除过期备份片，报错。但是发现实际备份片的物理文件已经之前被物理rm删掉了。解决方法：检查备份（如果完整检查备份没看到删了的备份，就单独crosscheck备份）crosscheck backup;或者crosscheck backuppiece '/data1/backup/jiangsu/20080814_iljnvkad_1_1';或者crossch

故障描述       2023年09月14号 9:33左右，客户反馈his数据库可能存在问题，当时数据库可以使用，应用比较缓慢。让检查数据库是否存在问题。       排查过程中，业务那边反馈问题从8点左右就开始，应用页面报错如下图所示：原因分析-ORA-30006应用页面报ORA-30006错误，检查早上8:00左右

故障描述2022年7月16号早上9点49左右，客户jsbas生产库。客户反馈应用系统慢并且报超时错误； 后续反馈应用用户无法连接数据库，其他用户登录没问题。这套RAC环境总共6个节点，上面运行5套数据库。  出问题的是jsbas数据库，jsbas数据库实例运行在节点3，4，5，6。其他数据库都正常。临时处理方法检查当前等待事件：检查发现，大部分都是library cache lock等待

故障描述2023年09月29号 10:30左右，应用多次反馈boss1的jsbas数据库应用程序报错，会话断开。原因分析检查会话情况：检查会话执行的sql：从上面可以看出来，JOUR用户的会话等待事件row cache lock，sql文本为“SELECT * FROM OM_LINE WHERE SUBSCRIBER_INS_ID = 108166239 AND ORDER_STATUS = &

方法一、1.先去ssh删除里面全部su - oraclecd .ssh2.配互信（node1，node2改成hostname）node1:[oracle @ node1~]$ ssh-keygen -t rsa                //一路回车[oracle @ node1~]$ ssh-keygen -t

1.先导出expdp system/oracle directory=mydata dumpfile=wlh.dmp logfile=wlh.log full=yCtrl+c 掐断导出，发现并未真正断开expdp2.查看会发现正在执行SQL>  select job_name,state from dba_datapump_jobs;JOB_NAME    &n

查看索引集群因子select OWNER,INDEX_NAME,CLUSTERING_FACTOR from dba_indexes where owner='DEF' and index_name='IDX_XX2';查看总行数select count(*) from def.employee;集群因子约接近总行数（越大），回表的时候会读更多数据块集群因子影响索引

如果先读后写申请一个buffer，数据从undo和老的buffer中克隆到新的里，老的buffer状态从XCUR改成CR，给读用，新的buffer状态从0改成XCUR，成为新的当前读buffer。如果先写后读申请一个buffer，数据从undo和老的buffer中克隆到新的里，新的buffer状态从0改成CR，给读用。如果先读后写，同时又来了个读最后一个读被堵塞，buffer busy waits

可能一、查看select group#, thread#, sequence#, bytes, archived, status from v$standby_log;关mrpalter database recover managed standby database cancel;改standby_file_management状态alter system set standby_file_m

故障描述2023年2月3日早上10点19分客户打电话找到工程师反应pacs数据库系统十分卡顿，事后通过告警日志在9点39分告警平台已经报警cpu使用率已经达到99%趋近饱和：查询数据库当时的运行情况，发现有大量的latch等待：这个等待事件是由热链争用导致，本次问题预估由于大量逻辑读的SQL语句有可能产生非常严重的latch:cache buffers chains等待，因为每次要访问一个bloc

一、背景概述2021-02-10 9:00 工程师接到客户电话，数据库delete数据一直卡住。2021-02-10 10:00 客户提供堡垒机远程方式，美创工程师登录操作系统，发现数据库异常卡顿，后台有大量等待事件，磁盘io已经达到峰值2021-02-11 23:00数据库重新起停时间需要2小时以上，且磁盘io一直处于写满状态，且再最后一次启动数据库后，undo出现坏块，需要