IBM Support

IC72110: SECONDARY CAN SOMETIMES FAIL IN RECOVERY WHEN TRYING TO COME INT O STANDARD MODE WITH ASSERT FAILED ROLLBACK ERROR 0 WHEN RECOVER

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as fixed if next.

Error description

  • The error messages seen in the MSGPATH file:
    
    09:08:49  DR: Turned off on secondary server
    09:09:24  Skipping failover callback.
    09:09:25  Logical Recovery has reached the transaction cleanup
    phase.
    09:09:25  Checkpoint Completed:  duration was 0 seconds.
    09:09:25  Tue Oct 19 - loguniq 5, logpos 0x1018, timestamp:
    0x2a27e Interval: 14
    
    09:09:25  Maximum server connections 0
    09:09:25  Checkpoint Statistics - Avg. Txn Block Time 0.000, #
    Txns blocked 0, Plog used 4, Llog used 1
    
    09:09:25  Assert Failed: Rollback error 0
    09:09:25  IBM Informix Dynamic Server Version 11.50.F
    09:09:25   Who: Session(13, informix@livestrong, 13698,
    111604e90)
            Thread(21, onmode_mon, 1115c7e00, 1)
            File: rstrans.c Line: 2749
    09:09:25   Results: Log record (OLDRSAM:COMMIT) in log 5, offset
    0x208 was not rolled back
    09:09:25   Action: Use 'onlog' to view the transaction and
    repair manually.
    09:09:25  stack trace for pid 13684 written to
    /spare1/work/pmr/porto/dump/af.3fda694
    09:09:25   See Also: /spare1/work/pmr/porto/dump/af.3fda694,
    shmem.3fda694.0
    
    Stack trace of the asserting thread:
    afstack()
    afhandler()
    affail_interface()
    logundo()
    rlogm_undo()
    rollback()
    rsrollback()
    txcleanup()
    rsclose_lgr()
    dr_lgr_end()
    dr_finish_recovery()
    dr_mode()
    onmode_monitor()
    startup()
    
    The onlog output that shows it's part of a distributed
    transaction (i.e. 2 Informix servers are involved)
    addr     len  type     xid      id link
    18       56   BEGIN    18       5  0        10/19/2010 09:04:32
    28       jrenaut
             00000038 00050001 00000000 00000000 ...8.... ........
             00000000 00000000 00000012 00000000 ........ ........
             00029bc6 00000000 00000000 4cbda570 ........ ....L..p
             00006215 0000001c                   ..b.....
    50       48   UNIQID   18       0  18       100182   3
             00000030 00000011 00000010 00000000 ...0.... ........
             00000000 00000000 00000012 00000018 ........ ........
             00029bc6 00100182 00100182 00000003 ........ ........
    80       72   HINSERT  18       0  50       100182   102      8
    
             00000048 00000028 00000112 00000000 ...H...( ........
             00000000 00000000 00000012 00000050 ........ .......P
             00029bc8 00100182 00100182 00000102 ........ ........
             00080004 00000000 00000000 72656e61 ........ ....rena
             00000002 00009e15                   ........
    c8       320  BEGPREP  18       0  80          0    1
             00000140 00000043 00000010 00000000 ...@...C ........
             00000000 00000000 00000012 00000080 ........ ........
    <stuff cut out>
    addr     len  type     xid      id link
    208      56   COMMIT   18       0  c8       10/19/2010 09:04:33
             00000038 00000002 00000010 00000000 ...8.... ........
             00000000 00000000 00000012 000000c8 ........ ........
             00029bc8 00000000 4cbda571 706f7274 ........ L..qport
             00000000 4cbda570                   ....L..p
    
    The BEGPREP log record is what indicates the transaction has a
    distributed piece of work that is on a separate server and that
    this server is the co-ordinate server.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * SDS/HDR/RSS users.                                           *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * SECONDARY CAN SOMETIMES FAIL IN RECOVERY WHEN TRYING TO COME *
    * INTO STANDARD MODE WITH ASSERT FAILED ROLLBACK ERROR 0 WHEN  *
    * RECOVER                                                      *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to Informix 11.50.xC9 or later.                      *
    ****************************************************************
    

Problem conclusion

Temporary fix

Comments

APAR Information

  • APAR number

    IC72110

  • Reported component name

    IBM IDS ENTRP E

  • Reported component ID

    5724L2304

  • Reported release

    B15

  • Status

    CLOSED FIN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-10-21

  • Closed date

    2011-09-27

  • Last modified date

    2011-09-27

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

  • RB15 PSN

       UP

  • RB15 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSGU8G","label":"Informix Servers"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"B15","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
27 September 2011