DPOS系统问题报告&解决
有关DPOS系统使用过程中遇到的问题，请全部跟贴到这篇文章。汇总统一解决。部分重要日志将在本章建立索引。
1 、Myjob状态正常但实际却不作为之问题分析日志
2、调拨单审批操作被堵塞之问题分析解决日志
关于作者:
| 昵称:商云方 档案信息:顾问, HAND张江技术中心 联系方式:你可以通过yunfang.shang@hand-china.com联系作者 点击查看商云方发表过的所有文章... 本文永久链接： http://blog.retailsolution.cn/archives/371 |
对本文的评价:
Myjob状态正常但实际却不作为之问题分析
/**************************************
2008-5-4
yunfang.shang
**************************************/
–现象1：2008年5月4日，用户反应费用单审批以后门店收不到
–现象2：另有用户反应调拨单审批后门店也收不到
–查myjob表，发现正常。
–看myjobserver的日志，正常。
–可不管怎么试，相关单据就是不能被发布。
–试用proposmanager.exe 手工发布单据，报错：
–“多步操作错误。。。。” ，查google得知是数据有问题，究竟是那些数据有问题？
–试用排除法，先关掉所有单据的发布开关，然后再逐个打开，以发现究竟是哪种单据的数据有问题。
–结果发现是销售日报和销售小票有问题。
–再按照时间段分别更改销售日报的已发布标志，最后确定是2008-4-26日以前从方程POS迁移过来的数据有问题。
–处理方法，把2008-4-26日以前从方程POS迁移过来的数据全部更改成已导出，以免发布程序再次使用这些数据，然后再发布，成功。
–POS小票的处理方法类同。
–小结：
— 1 myjob 表及myjobsvr.exe 的日志没有问题并不能说发布没有问题，因为myjobsvr.exe只要把projobcom调起来即认为自己成功。而projobcom本身可能失败。所以发布还是会失败。
— 2 要检验projobcom是否能成功发布，一个简单的方法就是运行proposmanager.exe 的 每日更新档案+单据 ，如果有问题那么一定会报错。只有解决了这个报错，才能真正解决问题。
备注：每日更新档案+单据 针对的是所有门店的所有未发布数据，不受界面上任何参数影响。
–感谢
–此问题非常隐蔽，问题排查过程花费了很大精力，直至5.4晚上22:30,才查出问题的根源，在此要感谢Anny在问题追查过程中给予的大力协助。
SELECT * FROM selldaily WHERE selldailyid = ‘RBSH9390804000165’ –selldate > SYSDATE -1
DELETE FROM selldaily WHERE selldailyid = ‘RBSH9390804000165’ ORDER BY selldate DESC
SELECT * FROM selldailyst WHERE selldailyid = ‘RBSH9390804000165′
SELECT * FROM selldaily
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND senddata =’Y’
AND selldate > to_date (‘2008-04-27′,’YYYY-MM-DD’)
–28日以后没有成功发布的。
–把28日以后的全部改成已发布
UPDATE selldaily SET senddata=’Y’,alreadysend=’Y’
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND selldate > to_date (‘2008-04-27′,’YYYY-MM-DD’)
SELECT * FROM selldaily
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND senddata =’N’
AND selldate >= to_date (‘2008-04-27′,’YYYY-MM-DD’)
–小于27日没有发布的
SELECT * FROM selldaily
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND senddata =’N’
AND selldate < to_date (‘2008-04-27′,’YYYY-MM-DD’)
–把小于4月26日的销售日报全部更新成已发布。
UPDATE selldaily SET senddata =’Y’,alreadysend=’Y’
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND senddata =’N’
AND selldate to_date (‘2008-04-27′,’YYYY-MM-DD’)
–再运行发布程序 成功；
–再次查找未发布的
SELECT * FROM selldaily
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND senddata =’N’
–存在数据
SELECT DISTINCT shoppeid FROM selldaily
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND senddata =’N’
–这些门店在usercenter中未注册。
SELECT * FROM usercenter WHERE userid IN
(SELECT DISTINCT shoppeid FROM selldaily
WHERE (SELLDAILYSTATE in (’02’ ,’04’)) and POSInputSign=’N’
AND senddata =’N’)
–打开销售小票的发布开关
SELECT * FROM XYDATAINTERFACE WHERE sendtag=’Y’
UPDATE XYDATAINTERFACE SET sendtag =’Y’ WHERE modulecode =’SHOPPESELL’
–把小于4月26日的销售小票全部更新成已发布。
SELECT * FROM shopsell
WHERE (SELLSTATEID=’02’ OR SELLSTATEID=’04’ )
AND senddata =’N’
AND selldate < to_date (‘2008-04-26′,’YYYY-MM-DD’)
–261条
SELECT * FROM hand_test
UPDATE shopsell SET senddata =’Y’,alreadysend=’Y’
WHERE (SELLSTATEID=’02’ OR SELLSTATEID=’04’ ) — and POSInputSign=’N’
AND senddata =’N’
AND selldate < to_date (‘2008-04-26′,’YYYY-MM-DD’)
–再次运行 proposmanager 发布每日单据。 成功。
–把所有应该发布的单据发布开关打开：
UPDATE XYDATAINTERFACE SET sendtag =’Y’ WHERE modulecode IN (
‘OUTGOODS05’,
‘PYPK01D’,
‘SALES101’,
‘OUTGOODS01’,
‘SHOPPESELL’,
‘CS0030D’,
‘CS0031D’,
‘CHANGEGOODS03’,
‘ASKORDER003’,
‘CHANGEGOODS02’);
–再次运行每日单据发布，成功。
调拨单审批操作被堵塞之问题分析解决日志
现象1：调拨单审批界面，按审批按钮后界面就不动了。感觉就像死机了，每个分公司的人做这个操作都是这个现象。 这种现象并不是每次都出现，具有相对的偶发性。
现象2：数据导入程序PoracleImp.exe被堵塞，所有门店的数据都进不了后台。
现象3: 几十个Session 一直在等待，最长的等了有６小时。
分析：
–查所有锁调拨单的Session:
Select c.*
From gv$locked_object a, all_objects b, gv$session c
Where a.object_id = b.object_id
And b.object_name = ‘SHOPPECHANGEGOODS’
And a.session_id = c.sid
And a.inst_id = c.inst_id
结果放入：：
调拨单被锁Session20080506-1.xls，
锁这张表的有Poracleimp.exe ,调拨单审批Form,并发程序。
Proposmanager.exe中发现有很多未导入的数据文件。手工导入也会死在那里。
对session 按照wait_in_second倒排序，发现等待时间最长的session是 1425 和 1561 ,等待时间都是16669秒
查出其锁定的行ID:
select dbms_rowid.rowid_create(1, c.row_wait_obj#,c.row_wait_file#,c.row_wait_block#,c.row_wait_row#) from dual
———————
–session 1425:
———————
select object_name from all_objects where object_id =768747
–结果：BILLRULESERIES
select dbms_rowid.rowid_create(1,768747,572,9952,0) from dual;
–结果：AAC7rrAI8AAACbgAAA
select * from BILLRULESERIES where rowid =’AAC7rrAI8AAACbgAAA’
–结果: 1 78 SHOPPECHANGEGOODS 23 4 ZH Y Y Y N N N N N N BBJ 200805
select * from BILLRULESERIES where rowid =’AAC7rrAI8AAACbgAAA’ for update nowait
–结果：可以锁定
———————
–session 1561:
———————
select object_name from all_objects where object_id =771335
–结果：SHOPPECHANGEGOODS
select dbms_rowid.rowid_create(1,771335,572,199102,0) from dual;
–结果：AAC8UHAI8AAAwm+AAA
select * from SHOPPECHANGEGOODS where rowid =’AAC8UHAI8AAAwm+AAA’
–结果：1 138435 SCSH905080430011 BSH SH905 SH768 SH905 SH768 2008-5-5 2008-4-30 2008-5-5 051013001 060531001 070613001 02 02 N FSH90520080505132626830 2008-4-30 01 01 N N N N Y Y Y 03 0 N N Y N N Y N N
SELECT * FROM shoppechangegoods WHERE changegoodsid =’SCSH905080430011′ FOR UPDATE NOWAIT
–结果：可以锁定。
–既然可以锁定，那为什么这个Session 一直在等待这个行呢？
–唯一的解释是：这个session 被其他Session 堵塞了。
–查找锁之间的等待关系
select a.sid holdsid,b.sid waitsid,a.type,a.id1,a.id2,a.ctime from gv$lock a,gv$lock b
where a.id1=b.id1 and a.id2=b.id2 and a.block=1 and b.block=0;
–发现 session 1425，1561 被1344 和1378堵塞了；
而1378也在等1344,这可以用如下Sql 察看：
SELECT decode(request,
0,
‘Holder: ‘,
‘Waiter: ‘) || sid sess,
id1,
id2,
lmode,
request,
TYPE
FROM gv$lock
WHERE (id1, id2, TYPE) IN (SELECT id1,
id2,
TYPE
FROM gv$lock
WHERE request > 0
AND TYPE != ‘HW’)
ORDER BY id1,
request
;
–在1344所在的数据库节点上运行Oracle的标准脚本,也可以清晰地看出session被堵塞的树型结构。
@$ORACLE_HOME/rdbms/admin/utllockt.sql ;
所以，1344是罪魁祸首。那么1344在干什么？
SELECT * FROM gv$session WHERE sid =1344 AND inst_id =3
–结果：1 3 00000003F968DC80 1344 38568 53144674 00000003F844EA10 173 APPS 0 2147483644 00000003E2DDF330 INACTIVE DEDICATED 173 APPS applprd 20129 erpapp1.daphne.com.cn USER 00 0 00000003ADFE1B28 3174209965 326up1aym56dd 1 DPOSSPCG 1566034542 FRM::DPSY沈阳DPOS普通用户 2060704412 1771 0 69015451 771346 572 214743 0 2008-5-6 10:37:13 24964 NO NONE NONE NO DISABLED ENABLED ENABLED 0 NO HOLDER 3219 257 SQL*Net message from client driver id 1952673792 0000000074637000 #bytes 1 0000000000000001 0 00 2723168908 6 Idle -1 25006 WAITED SHORT TIME PRD DISABLED FALSE FALSE
–该session 的状态是inactive的，而且是来自app1这个应用节点的，该节点的FormServer 在当日中午发生过异常。
–查该Session 对应的应用服务器的进程ID
SELECT process FROM gv$session WHERE sid =1344 AND inst_id =3
–结果：21029
–查该进程对应的数据库进程：
Select a.spid, a.TERMINAL, a.PROGRAM, a.username, b.OSUSER, b.PROCESS,
b.username, b.machine, b.SID, b.MODULE, b.action, b.CLIENT_INFO,
b.logon_time, b.sid, b.serial#, c.SQL_TEXT
From v$process a, v$session b, v$sql c
Where a.ADDR = b.PADDR
And b.sql_address = c.address(+)
And b.process = ‘20129’
–结果: SPID=15261
–在数据库节点上查该数据库进程
[oraprd@erpdb3 ~]$ ps -ef | grep 15261
oraprd 6493 7902 0 18:02 pts/2 00:00:00 grep 15261
oraprd 15261 1 0 10:36 ? 00:00:01 oraclePRD3 (LOCAL=NO)
结论：session 1344 对应的数据库操作系统进程一直存在，导致session 1344一直存在。
而session 1344 堵塞了其他很多session. 导致用户的很多操作无法进行。
解决：把 15261 kill掉。２分钟以后再次查询：
select a.inst_id,a.sid holdsid,b.sid waitsid,a.type,a.id1,a.id2,a.ctime from gv$lock a,gv$lock b
where a.id1=b.id1 and a.id2=b.id2 and a.block=1 and b.block=0;
–结果：被1344 和1378堵塞的Session全部没了。
–再查看等待导入的门店数据，全部都已经导入成功。
–再次进入调拨单审批界面，可以顺利审批。
关于昨天通讯唯一健报错的问题
Hi 姚经理： 你好！
前天和昨天，POS门店数据库在通讯导入促销单时，发生了表SPRDSHOPPELIST 唯一键重复的错误。
今天，经过江南的协助调查，发现POS后台该表的PK（组合健 SALESPROMOTIONID,SHOPPEID,SERIES）的字段比POS门店数据库中该表的PK（组合健 SALESPROMOTIONID,SERIES）多了字段。
因此，在通讯时生成脚本时，根据后台的PK生成的删除脚本并没有删除掉POS门店已经存在的数据，然后又导入了相同主键(DASH080603,1)的记录。
（通讯生成脚本如下：）
delete from SPRDSHOPPELIST where 1=1 And SALESPROMOTIONID=’DASH080603′ And SHOPPEID=’SH699′ And SERIES=’1′
Insert into SPRDSHOPPELIST(SERIES,SALESPROMOTIONID,SHOPPEID,ITEMSERIES,CANCELSIGN,INSERTDATA,UPDATEDATA,DELETEDATA,SENDDATA,ALREADYSEND,POSUPDATESIGN,POSSENDSIGN) Values(1,’DASH080603′,’SH699′,0,’N’,’N’,’N’,’N’,’N’,’N’,’N’,’N’)
delete from SPRDSHOPPELIST where 1=1 And SALESPROMOTIONID=’DASH080603′ And SHOPPEID=’SH714′ And SERIES=’2′
Insert into SPRDSHOPPELIST(SERIES,SALESPROMOTIONID,SHOPPEID,ITEMSERIES,CANCELSIGN,INSERTDATA,UPDATEDATA,DELETEDATA,SENDDATA,ALREADYSEND,POSUPDATESIGN,POSSENDSIGN) Values(2,’DASH080603′,’SH714′,0,’N’,’N’,’N’,’N’,’N’,’N’,’N’,’N’)
delete from SPRDSHOPPELIST where 1=1 And SALESPROMOTIONID=’DASH080603′ And SHOPPEID=’SH731′ And SERIES=’3′
Insert into SPRDSHOPPELIST(SERIES,SALESPROMOTIONID,SHOPPEID,ITEMSERIES,CANCELSIGN,INSERTDATA,UPDATEDATA,DELETEDATA,SENDDATA,ALREADYSEND,POSUPDATESIGN,POSSENDSIGN) Values(3,’DASH080603′,’SH731′,0,’N’,’N’,’N’,’N’,’N’,’N’,’N’,’N’)
delete from SPRDSHOPPELIST where 1=1 And SALESPROMOTIONID=’DASH080603′ And SHOPPEID=’SH914′ And SERIES=’4′
Insert into SPRDSHOPPELIST(SERIES,SALESPROMOTIONID,SHOPPEID,ITEMSERIES,CANCELSIGN,INSERTDATA,UPDATEDATA,DELETEDATA,SENDDATA,ALREADYSEND,POSUPDATESIGN,POSSENDSIGN) Values(4,’DASH080603′,’SH914′,0,’N’,’N’,’N’,’N’,’N’,’N’,’N’,’N’)
delete from SPRDSHOPPELIST where 1=1 And SALESPROMOTIONID=’DASH080603′ And SHOPPEID=’SH992′ And SERIES=’5′
Insert into SPRDSHOPPELIST(SERIES,SALESPROMOTIONID,SHOPPEID,ITEMSERIES,CANCELSIGN,INSERTDATA,UPDATEDATA,DELETEDATA,SENDDATA,ALREADYSEND,POSUPDATESIGN,POSSENDSIGN) Values(5,’DASH080603′,’SH992′,0,’N’,’N’,’N’,’N’,’N’,’N’,’N’,’N’)
门店已经存在数据如下：
1,DASH080603,SH708,…
2,DASH080603,SH706,…
解决方案： 修改后台表 SPRDSHOPPELIST PK 为 （组合健 SALESPROMOTIONID,SERIES）
修改通讯配置中对应表的主键为 （组合健 SALESPROMOTIONID,SERIES）
2008.07.15 POS通讯问题解决步骤
–客户发现： 所有促销单无法通过MYJOB发布
–经检查后发现： 促销单发布属于基础数据发布，在配置表possendtablerst中配置。
— 进一步发现所有possendtablerst中涉及到的表中数据都无法通过MYJOB发布
–解决步骤：
–1.备份基础数据通讯表possendtablerst
/*CREATE TABLE possendtablerst_bk080715 AS
SELECT *
FROM possendtablerst;*/
–2.更新配置表possendtablerst中所有记录的字段SENDSQLSIGN为’N’，
— 这步是将所有possendtablerst中所有通过MYJOB发布的配置屏蔽。
/*UPDATE possendtablerst t
SET t.sendsqlsign = ‘N’
WHERE t.sendsql IS NOT NULL; */
–3.更新配置表possendtablerst中促销单涉及到的3条记录的SENDSQLSIGN为’Y’
–4.备份需要发布的所有促销单数据。
/*CREATE TABLE sprdiscountordep_bk080715 AS
SELECT *
FROM SPRDISCOUNTORDEP
WHERE SCSTATEID = ’02’
AND ((TRUNC(SYSDATE) BETWEEN BEGINDAY AND ENDDAY) OR
(BEGINDAY >= TRUNC(SYSDATE)))
AND SENDDATA = ‘N’;*/
–5.发现促销单行中数据超过10W条，POS通讯无法一次发布这么多数据，需要根据分公司来切成几个部分.
—将所有需要发布数据SENDDATA更新成 Y
/*UPDATE SPRDISCOUNTORDEP T
SET T.SENDDATA=’Y’
,T.ALREADYSEND = ‘Y’
WHERE EXISTS (SELECT 1
FROM sprdiscountordep_bk080715 BK
WHERE BK.SALESPROMOTIONID = T.SALESPROMOTIONID
AND BK.CONSTITUTECOMPANYID ‘BBJ’)
UPDATE SPRDISCOUNTORDEPST TS
SET TS.SENDDATA=’Y’
,TS.ALREADYSEND = ‘Y’
WHERE EXISTS (SELECT 1
FROM sprdiscountordep_bk080715 BK
WHERE BK.SALESPROMOTIONID = TS.SALESPROMOTIONID
AND BK.CONSTITUTECOMPANYID ‘BBJ’)
UPDATE SPRDSHOPPELIST TTT
SET TTT.SENDDATA=’Y’
,TTT.ALREADYSEND = ‘Y’
WHERE EXISTS (SELECT 1
FROM sprdiscountordep_bk080715 BK
WHERE BK.SALESPROMOTIONID = TTT.SALESPROMOTIONID
AND BK.CONSTITUTECOMPANYID ‘BBJ’)
*/
–按分公司 把SENDDATA更新成 N 然后发布
/*UPDATE SPRDISCOUNTORDEP T
SET T.SENDDATA=’N’
,T.ALREADYSEND = ‘N’
WHERE EXISTS (SELECT 1
FROM sprdiscountordep_bk080715 BK
WHERE BK.SALESPROMOTIONID = T.SALESPROMOTIONID
AND BK.CONSTITUTECOMPANYID IN (‘BSD’,’BSH’))
UPDATE SPRDISCOUNTORDEPST TS
SET TS.SENDDATA=’N’
,TS.ALREADYSEND = ‘N’
WHERE EXISTS (SELECT 1
FROM sprdiscountordep_bk080715 BK
WHERE BK.SALESPROMOTIONID = TS.SALESPROMOTIONID
AND BK.CONSTITUTECOMPANYID IN (‘BSD’,’BSH’))
UPDATE SPRDSHOPPELIST TTT
SET TTT.SENDDATA=’N’
,TTT.ALREADYSEND = ‘N’
WHERE EXISTS (SELECT 1
FROM sprdiscountordep_bk080715 BK
WHERE BK.SALESPROMOTIONID = TTT.SALESPROMOTIONID
AND BK.CONSTITUTECOMPANYID IN (‘BSD’,’BSH’)) */
— 各部分分别都发布成功。
–6.怀疑别的需要MYJOB发布的数据中有非法数据，因此将配置表possendtablerst中SENDSQLSIGN局部按备份表还原为’Y’,
— 并在每次还原后，启动MYJOB看是否能发布成功，终于在恢复到 ARCHIVES02 时发现MYJOB不能正常发布，对ARCHIVES02
— 下所属需要MYJOB发布的所有表进行逐一查询，发现PRODUCTMAINDOSSIER中有超过12W的滞留数据，怀疑这就是问题症结
— 所在，将PRODUCTMAINDOSSIER分成2个部分通过MYJOB发布后，MYJOB终于能正常发布数据。
–结论：由于机房服务器的当机导致了数据库中大量需要MYJOB发布数据滞留，未能通过POS通讯程序及时发布。
— 最终会导致MYJOB程序无法正常发布。（MYJOB对每张表的发布数据的上限在10W左右）
费用审批时与通讯服务器出现拥堵的现象描述：
条件：
（1）分公司财务正在进行费用申请单的审核；
（2）通讯服务器正在进行门店费用申请单的导入；
出现的状况：
（1）。分公司费用申请单的审核一直出现漏斗现象；
（2）。通讯服务导入进程出现死循环现象，必须手工删除进程，删除以后，分公司费用审批才能正常；
（3）问题产生时，DBA那里发现有一个SQL语句一直在运转，详细画面见王帆给你的附件
烦请商顾问尽快予以解决，需要帮助或是连线的请直接与我联系。
王帆 发来的SQL 如下:
UPDATE EXPENDITUREFORM
SET SERIES = NVL(:b1, 0),
EXPENDITUREFORMID = :b2,
BARGAINORCOMPANYID = NVL(:b3, ‘ ‘),
CHANGEOUTCOMPANYID = :b4,
CHANGEOUTSHOPPEID = :b4,
FORMDATE = :b6,
CURRENTDATE = :b7,
CHANGETYPEID = NVL(:b8, ‘ ‘),
CHANGEOUTPERSON = NVL(:b9, ‘ ‘),
AUDITINGPERSON = NVL(:b10, ‘ ‘),
CHANGESTATEID = NVL(:b11, ’01’),
ZBSTATE = NVL(:b12, ’02’),
REMARK = NVL(:b13, ‘ ‘),
FILENO = NVL(:b14, ‘ ‘),
CANCELSIGN = NVL(:b15, ‘N’),
INSERTDATA = NVL(:b16, ‘N’),
UPDATEDATA = NVL(:b17, ‘N’),
DELETEDATA = NVL(:b18, ‘N’),
SENDDATA = NVL(:b19, ‘N’),
ALREADYSEND = NVL(:b20, ‘N’),
POSINPUTSIGN = :b21,
HEAD_ID = NVL(:b22, 0),
EXPORTSIGN = NVL(:b23, ‘N’),
CLOSEDATE = TRUNC(:b24),
PAY_DATE = TRUNC(:b25)
WHERE ROWID = :b26
请红阳通过VPN接入并解决这个问题.
我们按照红阳的要求更改了费用申请单的程式以后，与通讯服务器的拥堵情况依然存在，请你们立刻派人来我公司解决这个问题。谢谢。
@老姚, 红阳本周四(后天) 会到现场来,请提前作好准备,尽量能在周四重现这个问题.
All, 早上11：00接到用户反馈数据库响应时间很长，经查数据库日志发现，由于应用程序问题，使数据库死锁发生,从而导致数据库响应时间很长。
数据库做了相关解锁处理后，数据库恢复正常，但是此问题是由于应用程序产生的数据库锁，所以希望能彻底从应用层解决问题，不然应用程序运行，问题依旧会产生。
另外数据库锁报警，我会在这几天部署上去。
详细见附件
Thanks,
Eleanor
All,
同样的情况在今天下午又发生多次，虽然我已经解开这些锁了，但是新的锁还在继续发生。。。，所以我想知道是否最近有调整过和这些表有关的新的程序，数据库锁的问题是应用程序引发的，如果不解决，数据库锁会一直发生，数据库性能会很差，响应速度很慢。
Fri Nov 14 14:17:07 2008
Global Enqueue Services Deadlock detected. More info in file
/u03/prd/prddb/10.2.0/admin/PRD_erpdb1/bdump/prd1_lmd0_26307.trc.
Fri Nov 14 14:25:54 2008
Global Enqueue Services Deadlock detected. More info in file
/u03/prd/prddb/10.2.0/admin/PRD_erpdb1/bdump/prd1_lmd0_26307.trc.
Fri Nov 14 14:44:02 2008
Fri Nov 14 14:47:42 2008
Global Enqueue Services Deadlock detected. More info in file
/u03/prd/prddb/10.2.0/admin/PRD_erpdb1/bdump/prd1_lmd0_26307.trc.
Fri Nov 14 14:47:45 2008
Global Enqueue Services Deadlock detected. More info in file
/u03/prd/prddb/10.2.0/admin/PRD_erpdb1/bdump/prd1_lmd0_26307.trc.
Fri Nov 14 14:47:50 2008
Global Enqueue Services Deadlock detected. More info in file
/u03/prd/prddb/10.2.0/admin/PRD_erpdb1/bdump/prd1_lmd0_26307.trc.
Global Enqueue Services Deadlock detected. More info in file
/u03/prd/prddb/10.2.0/admin/PRD_erpdb1/bdump/prd1_lmd0_26307.trc.
Fri Nov 14 14:56:42 2008
Global Enqueue Services Deadlock detected. More info in file
/u03/prd/prddb/10.2.0/admin/PRD_erpdb1/bdump/prd1_lmd0_26307.trc.
–Eleanor