- 浏览: 117118 次
- 性别:
- 来自: 重庆
文章分类
最新评论
一.系统环境:
ORACLE:9IR2
OS:WINDOWS 2003 SERVER
二.问题描述:
现场人员报怨报表数据不准确,查明为韩国方面数据回传中断,联系韩国相关人员后,给我发了个他那边回传程式报的一个错:ORA-02049:timeout:distributed transaction waiting for lock.
三.问题分析:
找了下有关ORA-02049错误的简短说明如下:
ORA-02049:timeout:distributed transaction waiting for lock
cause:exceeded INIT.ORA distributed_lock_timeout seconds waiting for lock.
action:treat as a deadlock.
以为系统哪做了改变,造成了死锁了,导致系统内部将回传程式所作的修改回滚了.
查看了下alert.log文件,没有发现死锁的信息.
再查看了下当前系统的锁情况:
SELECT /*+ rule */
lpad(' ', decode(l.xidusn, 0, 3, 0)) || l.oracle_username User_name,
o.owner,
o.object_name,
o.object_type,
s.sid,
s.serial#
FROM v$locked_object l, dba_objects o, v$session s
WHERE l.object_id = o.object_id
AND l.session_id = s.sid
ORDER BY o.object_id, xidusn DESC;
OWNER OBJECT_NAME OBJECT_TYPE SID SERIAL#
------ -------------- ------------ ---- --------
SEC CONSUMABLESPEC TABLE 50 3558
SEC PROCESSGROUP TABLE 41 796
SEC PROCESSGROUPHISTORY TABLE 16 2535
SEC NCDEFECTHISTORY TABLE 34 46603
对比了一下报表,上面的涉及到的4张表正好是回传中断的表.
查看了下50,41,16,34这4个session的信息,状态均为ACTIVE,LOGON_TIME却是昨天中午11点多,这与4张表里记录的最大时间相差无几.难道这4个session执行了将近半天了.
查看下v$session_wait是否有异常的等待事件,却也没有发现可疑的等待事件.
再次联系韩国方面,要求回传一下数据,以便做个跟踪.这时再查看v$session_wait,出现了eqeue等待事件.
详细查看一下系统的锁等待情况:
SELECT DECODE(request,0,'Holder: ','Waiter: ')|| sid sess, id1, id2, lmode,
request, type
FROM V$LOCK
WHERE (id1, id2, type) IN (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
ORDER BY id1, request;
这时就可以看到回传程式在等待以上4个session持有的锁.
问题的原因总算有个大概了,可能是因为某些原因,昨天中午11点的那次回传程式意外中断了.但是他们所持有的表锁并没有正常释放,造成后面的回传数据发生锁等待.等待时间超出
参数distributed_lock_timeout定义的大小,ORA-02049错误也由此产生.顺便查看一下此参数在系统中的定义.
SQL> show parameter distribut
NAME TYPE VALUE
------------------------------------ ----------- ------------------
distributed_lock_timeout integer 60
呵呵...60秒.
四.问题解决:
简单有效的办法当然就是KILL这4个session了.让它们释放出所持有的表锁.
SQL> alter system kill session '50,3558';
alter system kill session '50,3558'
ORA-00031: session marked for kill
SQL> alter system kill session '41,796';
alter system kill session '41,796'
ORA-00031: session marked for kill
SQL> alter system kill session '16,2535';
alter system kill session '16,2535'
ORA-00031: session marked for kill
SQL> alter system kill session '34,46603';
alter system kill session '34,46603'
ORA-00031: session marked for kill
执行的结果并不是system altered.只是标记为KILL状态.重新查看系统的表锁情况,并没有释放.
WINDOWS平台下那就用ORAKILL吧....
先查看一下50,41,16,34这4个session在WINDOWS下对应的线程号:
select s.sid, p.spid from v$session s, v$process p where s.sid in ('50','41','16','34') and s.paddr=p.addr;
SID SPID
---- -----
50 4496
41 1436
16 6140
34 4360
利用ORAKILL工具将其KILL:
E:\>orakill samsung 4496
Kill of thread id 4496 in instance wiptest successfully signalled.
E:\>orakill samsung 1436
Kill of thread id 1436 in instance wiptest successfully signalled.
E:\>orakill samsung 6140
Kill of thread id 6140 in instance wiptest successfully signalled.
E:\>orakill samsung 4360
Kill of thread id 4360 in instance wiptest successfully signalled.
此时再查看系统的表锁信息,可以发现没有session持有这4张表的锁了.至此,问题解决.
转载至:http://space.itpub.net/12045182/viewspace-614267
ORACLE:9IR2
OS:WINDOWS 2003 SERVER
二.问题描述:
现场人员报怨报表数据不准确,查明为韩国方面数据回传中断,联系韩国相关人员后,给我发了个他那边回传程式报的一个错:ORA-02049:timeout:distributed transaction waiting for lock.
三.问题分析:
找了下有关ORA-02049错误的简短说明如下:
ORA-02049:timeout:distributed transaction waiting for lock
cause:exceeded INIT.ORA distributed_lock_timeout seconds waiting for lock.
action:treat as a deadlock.
以为系统哪做了改变,造成了死锁了,导致系统内部将回传程式所作的修改回滚了.
查看了下alert.log文件,没有发现死锁的信息.
再查看了下当前系统的锁情况:
SELECT /*+ rule */
lpad(' ', decode(l.xidusn, 0, 3, 0)) || l.oracle_username User_name,
o.owner,
o.object_name,
o.object_type,
s.sid,
s.serial#
FROM v$locked_object l, dba_objects o, v$session s
WHERE l.object_id = o.object_id
AND l.session_id = s.sid
ORDER BY o.object_id, xidusn DESC;
OWNER OBJECT_NAME OBJECT_TYPE SID SERIAL#
------ -------------- ------------ ---- --------
SEC CONSUMABLESPEC TABLE 50 3558
SEC PROCESSGROUP TABLE 41 796
SEC PROCESSGROUPHISTORY TABLE 16 2535
SEC NCDEFECTHISTORY TABLE 34 46603
对比了一下报表,上面的涉及到的4张表正好是回传中断的表.
查看了下50,41,16,34这4个session的信息,状态均为ACTIVE,LOGON_TIME却是昨天中午11点多,这与4张表里记录的最大时间相差无几.难道这4个session执行了将近半天了.
查看下v$session_wait是否有异常的等待事件,却也没有发现可疑的等待事件.
再次联系韩国方面,要求回传一下数据,以便做个跟踪.这时再查看v$session_wait,出现了eqeue等待事件.
详细查看一下系统的锁等待情况:
SELECT DECODE(request,0,'Holder: ','Waiter: ')|| sid sess, id1, id2, lmode,
request, type
FROM V$LOCK
WHERE (id1, id2, type) IN (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
ORDER BY id1, request;
这时就可以看到回传程式在等待以上4个session持有的锁.
问题的原因总算有个大概了,可能是因为某些原因,昨天中午11点的那次回传程式意外中断了.但是他们所持有的表锁并没有正常释放,造成后面的回传数据发生锁等待.等待时间超出
参数distributed_lock_timeout定义的大小,ORA-02049错误也由此产生.顺便查看一下此参数在系统中的定义.
SQL> show parameter distribut
NAME TYPE VALUE
------------------------------------ ----------- ------------------
distributed_lock_timeout integer 60
呵呵...60秒.
四.问题解决:
简单有效的办法当然就是KILL这4个session了.让它们释放出所持有的表锁.
SQL> alter system kill session '50,3558';
alter system kill session '50,3558'
ORA-00031: session marked for kill
SQL> alter system kill session '41,796';
alter system kill session '41,796'
ORA-00031: session marked for kill
SQL> alter system kill session '16,2535';
alter system kill session '16,2535'
ORA-00031: session marked for kill
SQL> alter system kill session '34,46603';
alter system kill session '34,46603'
ORA-00031: session marked for kill
执行的结果并不是system altered.只是标记为KILL状态.重新查看系统的表锁情况,并没有释放.
WINDOWS平台下那就用ORAKILL吧....
先查看一下50,41,16,34这4个session在WINDOWS下对应的线程号:
select s.sid, p.spid from v$session s, v$process p where s.sid in ('50','41','16','34') and s.paddr=p.addr;
SID SPID
---- -----
50 4496
41 1436
16 6140
34 4360
利用ORAKILL工具将其KILL:
E:\>orakill samsung 4496
Kill of thread id 4496 in instance wiptest successfully signalled.
E:\>orakill samsung 1436
Kill of thread id 1436 in instance wiptest successfully signalled.
E:\>orakill samsung 6140
Kill of thread id 6140 in instance wiptest successfully signalled.
E:\>orakill samsung 4360
Kill of thread id 4360 in instance wiptest successfully signalled.
此时再查看系统的表锁信息,可以发现没有session持有这4张表的锁了.至此,问题解决.
转载至:http://space.itpub.net/12045182/viewspace-614267
发表评论
-
Oracle Delete误删除数据恢复
2019-02-19 11:11 474获得chamber_move给定时间点时数据内容 select ... -
ORA-02391问题的解决方法
2016-07-27 10:28 3223ORA问题的分析和解决其实是一个很好的学习思路,抓住一个每一个 ... -
Oracle 操作
2016-07-19 09:25 545删除表空间及对应磁盘文件; drop tablespace R ... -
oracle recyclebin
2016-07-13 14:06 0oracle 回收站recyclebin是10g才有的新特性, ... -
Oracle数据库远程导入(EXP)、导出(IMP)
2016-04-25 16:20 2126用exp/imp远程(本地)操作 ... -
EXP-00091错误的说明和解决方法
2016-04-25 15:33 1043对于一个经常用oracle的 ... -
查看表空间使用情况
2016-03-10 11:46 671查看表空间使用情况 方法一: SELECT a.tablesp ... -
oracle 在删除表,表空间,用户时 如何释放磁盘空间
2016-03-10 11:30 1166一、drop表 执行drop table xx 语句 dr ... -
oracle 查看用户表数目,表大小,视图数目等
2016-03-10 11:01 1661oracle 查看用户表数目,表大小,视图数目等 查看当前用 ... -
小数处理函数(trun(),round(),ceil()和floor())
2015-07-28 16:49 1318trun()round()函数 trunc截取 ... -
关于Oracle取整的函数
2015-07-06 15:09 917关于Oracle取整的函数分别有以下几种: 1.取整( ... -
权限分配
2015-06-18 17:01 662view 权限分配 grant select on vw_mf ... -
Oracle回闪空间不足引起的ORA-03113问题排解
2015-04-03 13:44 4453Oracle回闪空间不足引起的ORA-03113问题排解 现 ... -
function
2014-09-02 16:03 486create or replace function getS ... -
oracle中替换字符串中回车换行符
2014-04-29 18:24 2144select trim(replace(a.ctimer_pi ... -
Oracle字符串处理函数
2014-01-08 17:09 722项目中有涉及存储过程对字符串的处理,所以就将在网上查找到的资料 ... -
oracle translate() 详解+实例
2014-01-08 17:05 738oracle translate() 详解+实 ... -
ITPUB网址
2013-12-24 09:34 909ITPUB网址: http://blog.itpub.net/ ... -
oracle常用系统表
2013-09-10 13:26 671dba_开头..... dba_users 数据库用户信息 ... -
ORACLE 异常错误处理
2013-07-26 09:44 701ORACLE 异常错误处理 本篇主要内容如下: 5.1 异常 ...
相关推荐
Oracle数据库发生ORA-04031错误原因浅析及处理 Oracle数据库是甲骨文公司提供的...本文通过对ORA-04031错误的分析和解决方法的介绍,旨在帮助读者更好地理解Oracle数据库中的ORA-04031错误,并提供了实用的解决方法。
这可能是因为PL/SQL代码中的语法错误、运行时错误或其他编程错误。 #### ORA-00035: LICENSE_MAX_USERS Exceeded 当用户数量超过了LICENSE_MAX_USERS设置的最大值时触发。这通常意味着需要增加许可用户数或调整许可...
ORA-2072错误通常与数据库的分布式事务处理有关,它提示“分布式事务中的一个或多个操作失败”。这可能是由于网络问题、数据库连接断开或者分布式事务的资源管理不当所导致。而ORA-2063错误则表示“远程数据库操作...
Oracle数据库在运行过程中可能会遇到各种错误,其中,ORA-07445错误是一个与内核相关的严重异常,通常表示数据库遇到了未预期的内部错误,可能导致数据库实例的崩溃。在这个特定的问题中,XX网的Oracle 9.2.0.6版本...
然而,在使用Oracle进行SQL操作时,可能会遇到各种错误代码,这些错误通常提供了关于问题的详细信息,帮助数据库管理员和开发人员识别并解决问题。以下是一些常见的Oracle错误代码及其含义: 1. ORA-00001: 这个...
22. ORA-00037: 无法转换到属于不同服务器组的会话,这涉及到数据库的分布式特性。 23. ORA-00038: 无法创建会话:服务器组属于其他用户,权限问题。 24. ORA-00050: 获取入队时操作系统出错,这可能是由于系统...
最后,从ORA-00090到ORA-00106,这部分错误涉及到数据库参数设置错误、内存分配问题、SQL特性不兼容和网络协议配置错误。这些错误通常需要检查和调整数据库实例的初始化参数文件(init.ora或spfile.ora),确保参数...
除了上述错误外,文章还提到了其他常见的ORA错误,如ORA-01545、ORA-0165x、ORA-01555、ORA-04031、ORA-04091、ORA-01242和ORA-01113,涵盖了从空间管理、性能瓶颈、到内存不足等各种数据库操作场景中可能遇到的问题...
60. **ORA-00087**: 命令无法在远程例程上执行,可能是分布式数据库或网络问题。 61. **ORA-00088**: 共享服务器无法执行命令,可能与服务器模式或资源限制有关。 62. **ORA-00089**: ORADEBUG命令中的例程号无效...
在处理Oracle数据库时,遇到错误是在所难免的,了解并掌握常见的错误代码及其含义,对于快速定位问题、解决问题至关重要。本文将详细介绍部分Oracle错误代码的含义及可能的原因,帮助数据库管理员和开发人员更好地...
- 检查`init<sid>.ora`配置文件中的`COMMIT_POINT_STRENGTH`参数,确保其值足够大,以支持分布式事务的强一致性。 3. **检查事务状态**: - 若状态为`commit`,本地事务已提交,无需额外操作。 - 若状态为`not ...
综上所述,Oracle数据库在运行过程中可能会遇到各种各样的问题,这些问题的解决通常需要根据具体的错误代码和场景来分析。在实际操作中,除了上述提到的方法外,还需要结合具体情况灵活应对,同时不断学习最新的技术...
这个补丁主要目的是解决与物化视图相关的ORA-04052错误。在深入了解这些概念之前,让我们先了解一下Oracle数据库和物化视图。 Oracle数据库是一个关系型数据库管理系统,由甲骨文公司开发。它提供了一整套强大的...
本合集聚焦于Oracle9i版本的错误代码,对于理解并解决与该版本相关的数据库问题具有极高的价值。Oracle9i是Oracle数据库的第9个主要版本,发布于2001年,它在性能、可扩展性和安全性方面都有显著提升,同时也引入了...
以上步骤详细介绍了在分布式环境中安装和配置ArcSDE for Oracle的过程,以及解决可能出现的问题。理解这些步骤对于管理和维护GIS系统至关重要,确保数据的高效、安全和可靠的存储与访问。在实际应用中,还应考虑备份...
通过`cat /u01/app/oracle/admin/orcl/bdump/alert_ORCL.log|grep -i ora-`或`grep -i err`、`grep -i fail`等命令,可以检查`alert_SID.log`文件中的错误信息,帮助定位和解决问题。例如,`ORA-1126`和`ORA-01157`...
1. 数据库的日志文件(alert.log)中出现SCN警告或ORA-00600错误,表明数据库内部出现了严重问题,无法处理事务。 2. SCN异常增长的报警信息会显示在alert.log中,例如通过DBLINK进行分布式事务时,SCN超出限制,...