首页 > DPOS技术 > DPOS系统问题报告&解决

DPOS系统问题报告&解决

2008年10月17日 商云方 发表评论 阅读评论

 

有关DPOS系统使用过程中遇到的问题,请全部跟贴到这篇文章。汇总统一解决。部分重要日志将在本章建立索引。

1 、Myjob状态正常但实际却不作为之问题分析日志
2、调拨单审批操作被堵塞之问题分析解决日志

 

 

关于作者:

昵称:商云方
档案信息:顾问, HAND张江技术中心
联系方式:你可以通过yunfang.shang@hand-china.com联系作者
点击查看商云方发表过的所有文章...
本文永久链接: http://blog.retailsolution.cn/archives/371

 

 

对本文的评价:

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading ... Loading ...

 

 

  1. 2008年10月17日23:26 | #1

    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');

    --再次运行每日单据发布,成功。

  2. 2008年10月17日23:31 | #2

    调拨单审批操作被堵塞之问题分析解决日志

    现象1:调拨单审批界面,按审批按钮后界面就不动了。感觉就像死机了,每个分公司的人做这个操作都是这个现象。 这种现象并不是每次都出现,具有相对的偶发性。
    现象2:数据导入程序PoracleImp.exe被堵塞,所有门店的数据都进不了后台。
    现象3: 几十个Session 一直在等待,最长的等了有6小时。

    分析:

    --查所有锁调拨单的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掉。2分钟以后再次查询:
    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全部没了。
    --再查看等待导入的门店数据,全部都已经导入成功。
    --再次进入调拨单审批界面,可以顺利审批。

  3. ben.zhu
    2008年10月17日23:44 | #3

    关于昨天通讯唯一健报错的问题

    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)

  4. ben.zhu
    2008年10月17日23:45 | #4

    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左右)

  5. 姚海峻
    2008年10月22日12:53 | #5

    费用审批时与通讯服务器出现拥堵的现象描述:
    条件:
    (1)分公司财务正在进行费用申请单的审核;
    (2)通讯服务器正在进行门店费用申请单的导入;
    出现的状况:
    (1)。分公司费用申请单的审核一直出现漏斗现象;
    (2)。通讯服务导入进程出现死循环现象,必须手工删除进程,删除以后,分公司费用审批才能正常;
    (3)问题产生时,DBA那里发现有一个SQL语句一直在运转,详细画面见王帆给你的附件

    烦请商顾问尽快予以解决,需要帮助或是连线的请直接与我联系。

  6. yunfang
    2008年10月22日13:03 | #6

    王帆 发来的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接入并解决这个问题.

  7. 姚海峻
    2008年11月4日16:48 | #7

    我们按照红阳的要求更改了费用申请单的程式以后,与通讯服务器的拥堵情况依然存在,请你们立刻派人来我公司解决这个问题。谢谢。

  8. 2008年11月4日19:16 | #8

    @老姚, 红阳本周四(后天) 会到现场来,请提前作好准备,尽量能在周四重现这个问题.

  9. 2008年11月20日15:18 | #9

    姚海峻 :

    费用审批时与通讯服务器出现拥堵的现象描述:
    条件:
    (1)分公司财务正在进行费用申请单的审核;
    (2)通讯服务器正在进行门店费用申请单的导入;
    出现的状况:
    (1)。分公司费用申请单的审核一直出现漏斗现象;
    (2)。通讯服务导入进程出现死循环现象,必须手工删除进程,删除以后,分公司费用审批才能正常;
    (3)问题产生时,DBA那里发现有一个SQL语句一直在运转,详细画面见王帆给你的附件

    烦请商顾问尽快予以解决,需要帮助或是连线的请直接与我联系。

    [回复此评论]

    [删除] |

    All, 早上11:00接到用户反馈数据库响应时间很长,经查数据库日志发现,由于应用程序问题,使数据库死锁发生,从而导致数据库响应时间很长。

    数据库做了相关解锁处理后,数据库恢复正常,但是此问题是由于应用程序产生的数据库锁,所以希望能彻底从应用层解决问题,不然应用程序运行,问题依旧会产生。

    另外数据库锁报警,我会在这几天部署上去。

    详细见附件

    Thanks,

    Eleanor

  10. 2008年11月20日15:19 | #10

    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

  1. 本文目前尚无任何 trackbacks 和 pingbacks.
您必须在 登录 后才能发布评论.