IC90245: ONSPACES IS ABLE TO DROP AN SBSPACE CHUNK THAT CONTAINS SMARTBLOB DATA

APAR status

• Closed as program error.

Error description

• The situation can be described as follows:
  
  An instance with an sbspace exists and that space is
  activated--instance has been bounced with name set in the
  onconfig parameter SBSPACENAME.
  
  While inserting data into a table with a smartblob column and no
  defined storage for that column (relying on the onconfig
  parameter SBSPACENAME) chunks are added to the previously
  defined sbspace.  The smartblob data gets distributed across the
  chunks in the sbspace and into the newest chunks during the
  load.  When the loading is done, onstat -d could look something
  like this:
  
  
  Dbspaces
  address          number   flags      fchunk   nchunks  pgsize
  flags    owner    name
  70000001025b028  1        0x60001    1        1        4096
  N  B     informix rootdbs
  7000000103a0b20  2        0x68001    2        3        4096
  N SB     informix sbspace1
   2 active, 2047 maximum
  
  Chunks
  address          chunk/dbs     offset     size       free
  bpages     flags pathname
  70000001025b1c0  1      1      0          50000      16593
  PO-BD /usr1/chunks/rootdbs.1
  7000000103a0cb8  2      2      0          25600      10216
  23835      POSBD /usr1/chunks/sbspace1_1
                                   Metadata 1712       463
  1712
  700000011713bd8  3      2      0          25600      10232
  23881      POSBD /usr1/chunks/sbspace1_2
                                   Metadata 1716       1144
  1716
  700000011713dc8  4      2      0          25600      13788
  23881      POSBD /usr1/chunks/sbspace1
                                   Metadata 1716       1716
  1716
   4 active, 32766 maximum
  
  
  Chunks 3 and 4 were added during the load.  Notice that both
  chunks 3 and 4 had some data loaded into both of them.
  
  The problem is that onspaces will allow the drop of chunk 4 even
  though it clearly has blobs in it as seen below:
  
   Large Objects
    ID               Ref Size       Allocced       Creat   Last
    Sbs# Chk#  Seq#  Cnt    (Bytes)    Pages Extns Flags
  Modified
    ---- ---- ----- ---- ---------- -------- ----- -----
  ------------------------
       2    4     1    1      27282        7     1 N-N-H Fri Feb
  8 16:32:18 2013
       2    4     2    1     201793       50     1 N-N-H Fri Feb
  8 16:32:18 2013
      ...
  
  Sometimes oncheck -cS will not show any LOs in chunk 4 even when
  data space pages are used in that chunk.  Then when chunk 4 is
  dropped and the rows are deleted from the table, it will report
  assertion failures like:
  
  12:04:58  Assert Warning: ERROR: Smart-large-object deletion
  failed at commit.
  12:04:58   Who: Session(299, informix@machine, 65996740,
  70000001038ab88)
                  Thread(328, sqlexec, 70000001034dbe0, 1)
                  File: sbxlog.c Line: 557
  12:04:58   Results: lo_id=[2 3 341] err=12143; TX committed
  
  In the case above, chunk 3 still exists but it claims (via error
  12143) that chunk 3 does not exist.  What is really happening is
  an extent of this LO made it into chunk 4 and since the first
  extent exists in chunk 3, the error reports chunk 3 as
  non-existent.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * Users of IDS 11.50 and above                                 *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * See Error Description                                        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Update to IDS-11.50.xC10                                     *
  ****************************************************************
  

Problem conclusion

• Problem Fixed In IDS-11.50.xC10
  

Temporary fix

Comments

APAR Information

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

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

Fix information

• Fixed component name

  INFORMIX SERVER

• Fixed component ID

  5725A3900

Applicable component levels

• RB50 PSY

     UP

• RB70 PSY

     UP