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 number
IC90245
Reported component name
INFORMIX SERVER
Reported component ID
5725A3900
Reported release
B50
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-02-15
Closed date
2017-06-16
Last modified date
2024-09-24
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
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSGU8G","label":"Informix Servers"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"B50","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
24 September 2024