一次Oracle故障处理过程

news/2024/7/11 1:39:13 标签: oracle, session, application, system, 数据库, class
class="baidu_pl">
class="article_content clearfix">
class="htmledit_views">

中午接到报警,tomcat连接class="tags" href="/tags/ORACLE.html" title=oracle>oracle并发数超过阀值,首先怀疑是否刚更新了程序,但询问一番后答案都是否。然后怀疑是有人进行大的操作。

登录到class="tags" href="/tags/ShuJuKu.html" title=数据库>数据库机器,用top查看,是否有消耗资源的进程。发现所有的进程资源消耗比较平均,应该没有人在进程大查询或者大的操作。

使用ASH,查看class="tags" href="/tags/ShuJuKu.html" title=数据库>数据库近15分钟发生了什么。

SYS@sg>@?/rdbms/admin/ashrpt

 
Defaults TO -15 mins
Enter VALUE FOR begin_time: -15
Report BEGIN TIME specified: -15
打开报告,发现可疑的sql。

       SQL ID    Planhash % Activity Event                             % Event
------------- ----------- ---------- ------------------------------ ----------
2ghd19kmj1m1t  2931439336      97.04 enq: TX - ROW LOCK contention       96.89
 
UPDATE tb_name WHERE ......
 
          -------------------------------------------------------------
这条语句,产生的enq: TX - row lock contention事件,占了整个的96.89%,确认问题就好解决了。

SELECT a.sid, b.SERIAL#,a.state, a.wait_time
FROM v$class="tags" href="/tags/SESSION.html" title=session>session_wait a,v$class="tags" href="/tags/SESSION.html" title=session>session b
WHERE a.wait_class='Application' AND a.event='enq: TX - row lock contention'
AND a.sid=b.sid ORDER BY a.wait_class, a.event, a.sid;
 
       SID    SERIAL# STATE     WAIT_TIME
---------- ---------- ------------------- ----------
      1817 42155 WAITING      0
      1819 38267 WAITING      0
      1824 43045 WAITING      0
      1827 29392 WAITING      0
      1831 56038 WAITING      0
      1833 16463 WAITING      0
      1836 13558 WAITING      0
 
7 rows selected.
 
SYS@sg>alter class="tags" href="/tags/SYSTEM.html" title=system>system kill class="tags" href="/tags/SESSION.html" title=session>session '1817,42155';
System altered.
杀掉相关进程,OK问题解决。在找开发人员,修改相关的应用。

这里只是提供一个思路,发生问题的时候,一定需要冷静思考问题可能出现的地方,先找出问题的所在,再根据问题去解决。

 

 


http://www.niftyadmin.cn/n/1552492.html

相关文章

Oracle redolog 丢失的故障处理

Oracle的重做日志文件(Online redo logfile)循环记录了数据库所有的事务。它的大小、个数和存储位置对数据库性能和恢复有重要影响。它一般由大小相同的几组文件构成。我们可以查看数据库视图v$logfile知道redo logfile的个数和存储位置。对每一个Oracle数据库都要求至少具有两…

常见latch闩锁等待

常见latch闩锁等待 参考《oracle性能优化实务》 与共享池有关的latch闩锁等待(共享池不足或碎片化问题导致) shared pool library cache library cache pin row cache objects row cache enqueue latch和LRU CHAINS或者HASH CHAINS相关的闩锁 cache buff…

ORA-01591故障处理

早晨到办公室听同事说表被锁了,一试,发现表中某字段为1111111的行都被锁了,SELECT都不行。报错误ORA-01591,打开TOAD的KnowledgeeXpert,描述很少,只是说由于分布式事务错误而造成锁定。询问同事&#xff0c…

一次web 服务器无法连接上oracle 数据库的故障处理

今天早上维护人员打来电话说某移动的114 web server 无法连接到数据库,web server 报一大堆jdbc 的错误,最后报 sql error,但是并没有明显的ORA- 的错误,第一反映应该不是oracle 数据库的问题,估计是web server 与数据库连接出现了…

分析共享池脚本

分析共享池脚本 参考《oracle性能优化实务》 SQL> col "avg size" format a30 truncate; SQL> col siz format 999999999999 SQL> SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ) SIZ,2 To_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),999…

oracle数据库常见故障处理

一、定位数据库故障原因。定位原因大概可以分三步走:1、如果有oracle错误号或者alert日志中有详细的出错信息,则可以根据这些去定位数据库故障原因;2、如果没有,则可以运行awr工具或者statspack工具生成报告,根据报告去…

共享池碎片化分析脚本

共享池逐渐碎片化是正常现象,oracle有自动合并内存的机制来解决碎片化,如果这个机制解决不了问题,那么考虑业务少的时候刷新共享池(alter system flush shared_pool;)或重启实例。 SQL> set line 200 SQL> col s…

drop user cascade出现ORA-04043问题的解决

问题: SQL> drop user hbylinit cascade;drop user hbylinit cascadeORA-00604: 递归 SQL 级别 1 出现错误ORA-04043: 对象 SYS_YOID0000104160$ 不存在分析:ora-4043就是提示对象不存在,一般在写错对象名的时候都会报这个错误。推测出…