One comment

  1. Dear Colleagues, I’m in big trouble for the unexpected SQL1042C in my shop DB2 LUW V11.1 running on CentOS 6.
    My analysis is shortly described by these sentences:
    S1
    [db2inst1@db2 ~]$ db2 “create stogroup SG_4 on ‘/data/new_path1’,’/data5/new_path2′”
    DB20000I The SQL command completed successfully.
    S2
    db2inst1@db2 ~]$ db2pd -d DBPRE -storagegroups
    Database Member 0 — Database DBPRE — Active — Up 0 days 01:26:45 — Date 2018-06-28-18.39.25.396340
    Storage Group Configuration:
    Address SGID Default DataTag Name
    0x00007FA597840D60 0 Yes 0 IBMSTOGROUP
    0x00007FA5A6052000 2 No 0 SG_4
    Storage Group Statistics:
    Address SGID State Numpaths NumDropPen
    0x00007FA597840D60 0 0x00000000 2 0
    0x00007FA5A6052000 2 0x00000000 2 0
    Storage Group Paths:
    Address SGID PathID PathState PathName
    0x00007FA597874000 0 0 InUse /home/db2inst1
    0x00007FA597872000 0 1 InUse /data/sg2
    0x00007FA5A6053000 2 2048 NotInUse /data/new_path1
    0x00007FA5A561A000 2 2049 NotInUse /data5/new_path2
    Some days working without any negative behavior, therefore we decided to replicate in production (without backup, else too simple) and withot following “https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.5.0/com.ibm.db2.luw.admin.sec.doc/doc/c0050516.html” (else too easy).
    Therefore we assume that the reason of SQL1042C be clear (but not 100% sure). Any way, the problem is to recover data, of course. Could you please try to help us before being hanged ?
    Thanks and regards, carlo

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.