informix.LO_hdr_partn
Posted in 2014
Topics: High Availability & Replication, Storage & Space Management, Platform-Specific Issues
Hi experts,
anybody had this before ? We have a big central system with sblob data, IDS
11.70FC5, Linux 64bit
Informix gave a message:
11:26:29 partition 'sblobdbs:informix.LO_hdr_partn': no more pages
oncheck -cs
Validating space 'sblobdbs' ...
sbspace Metadata Partition Partnum Used Free
sblobdbs:'informix'.TBLSpace 0x200001 14 36
sblobdbs:'informix'.sbspace_desc 0x200002 2 2
sblobdbs:'informix'.chunk_adjunc 0x200003 6 2
sblobdbs:'informix'.LO_ud_free 0x200004 447 537473
sblobdbs:'informix'.LO_hdr_partn 0x200005 16777215 0
sblobdbs:'informix'.LO_ud_free 0x200006 3 603218
sblobdbs:'informix'.LO_hdr_partn 0x200007 16777215 0
sblobdbs:'informix'.LO_ud_free 0x200008 2624 645082
sblobdbs:'informix'.LO_hdr_partn 0x200009 6574002 512659
sblobdbs:'informix'.LO_ud_free 0x20000a 2324 583936
sblobdbs:'informix'.LO_hdr_partn 0x20000b 3310646 0
sblobdbs:'informix'.LO_ud_free 0x20000c 616 647090
sblobdbs:'informix'.LO_hdr_partn 0x20000d 892734 2764897
Seems to me there are some L0_hdr_partn, not all full.
We have 4 databases containing Blob columns.
Does anybody know why there are multiple L0_hdr_partn (not all full) and why
this error occurs.
We seem to get errors on all databases when inserting blob data. (no more
extents)
What can we do ? Is there a way to enhance the L0_hdr_partn ? It seems the
mechanism is not documented .
Thanks in advance,
Marcus Haarmann
Additional information:
It seems the LO_hdr_partn is per Chunk. This makes sense, since we have 5
chunks.
Dbspaces
address number flags fchunk nchunks pgsize flags owner name
53904028 1 0x40001 1 2 2048 N BA informix rootdbs
55a52028 2 0x48001 2 5 2048 N SBA informix sblobdbs
2 active, 2047 maximum
Chunks
address chunk/dbs offset size free bpages flags pathname
539041d0 1 1 0 25000000 1209068 PO-B-- /opt/dbs/doc1/rootdbs
55a521d0 2 2 0 207625000 0 193650947 POSB-- /opt/dbs/doc1/sblobdbs
Metadata 13974000 0 13974000
55a523d0 3 2 0 232830000 0 217159599 POSB-- /opt/dbs/doc1/sblobdbs1
Metadata 15670398 92213 15670398
55a525d0 4 2 0 250000000 0 233173990 POSB-- /opt/dbs/doc1/sblobdbs2
Metadata 16826007 51336 16826007
57671d40 5 2 0 226283520 0 211053722 POSB-- /opt/dbs/doc1/sblobdbs3
Metadata 15229795 10924458 15229795
575fd440 6 2 0 250000000 176124729 233173990 POSB-- /opt/dbs/doc1/sblobdbs4
Metadata 16826007 16826007 16826007
56bf9c78 7 1 0 25000000 23930328 PO-B-- /opt/dbs/doc1/data1
7 active, 32766 maximum
Only the last chunk is being used for new values, all others are full.
What I do not understand is that the LO_hdr_partn
a) has different sizes (first two 16m pages, next 7m pages, last only 3.5m
pages).
b) last partn should be for last chunk and is not filled completely, so why
are we getting errors ?
Hope anybody knows a way to escape this situation, since we would have about
2TB data to copy in a new instance
when the extent problem cannot be solved.
We have also addressed our distributor for help, but maybe anybody here can
give an advice more quickly.
Thanks in advance for your opinion,
Marcus Haarmann
----- Ursprüngliche Mail -----
Von: "Marcus Haarmann" <marcus.haarmann@midoco.de>
An: ids@iiug.org
Gesendet: Donnerstag, 10. April 2014 12:03:35
Betreff: informix.LO_hdr_partn [32894]
Hi experts,
anybody had this before ? We have a big central system with sblob data, IDS
11.70FC5, Linux 64bit
Informix gave a message:
11:26:29 partition 'sblobdbs:informix.LO_hdr_partn': no more pages
oncheck -cs
Validating space 'sblobdbs' ...
sbspace Metadata Partition Partnum Used Free
sblobdbs:'informix'.TBLSpace 0x200001 14 36
sblobdbs:'informix'.sbspace_desc 0x200002 2 2
sblobdbs:'informix'.chunk_adjunc 0x200003 6 2
sblobdbs:'informix'.LO_ud_free 0x200004 447 537473
sblobdbs:'informix'.LO_hdr_partn 0x200005 16777215 0
sblobdbs:'informix'.LO_ud_free 0x200006 3 603218
sblobdbs:'informix'.LO_hdr_partn 0x200007 16777215 0
sblobdbs:'informix'.LO_ud_free 0x200008 2624 645082
sblobdbs:'informix'.LO_hdr_partn 0x200009 6574002 512659
sblobdbs:'informix'.LO_ud_free 0x20000a 2324 583936
sblobdbs:'informix'.LO_hdr_partn 0x20000b 3310646 0
sblobdbs:'informix'.LO_ud_free 0x20000c 616 647090
sblobdbs:'informix'.LO_hdr_partn 0x20000d 892734 2764897
Seems to me there are some L0_hdr_partn, not all full.
We have 4 databases containing Blob columns.
Does anybody know why there are multiple L0_hdr_partn (not all full) and why
this error occurs.
We seem to get errors on all databases when inserting blob data. (no more
extents)
What can we do ? Is there a way to enhance the L0_hdr_partn ? It seems the
mechanism is not documented .
Thanks in advance,
Marcus Haarmann
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Hi Marcus,
We had the same problem a few months ago with Informix 11.50.FC9 on HP-UX with
4 chunks in sbspace 1TB of data.
We did not have a time to open PMR(Case) because our system is 24x7. We find
workaround to rename the tables with BLOB-CLOB column and recreate new
tables in a new sbspace with big Metadata partition and AVG_LO_SIZE=2K(Lowest
value).
We are lucky, because developer agreed to change the application and recreate
the part of application with select in old and new tables.
But Im sure that after a year well have the same problem.
This is a part of your onstat cs output:
sblobdbs:'informix'.LO_hdr_partn 0x200005 16777215 0
sblobdbs:'informix'.LO_hdr_partn 0x200007 16777215 0
sblobdbs:'informix'.LO_hdr_partn 0x20000b 3310646 0
sblobdbs:'informix'.LO_hdr_partn 0x20000d 892734 2764897
In the 0x200005 and 0x200007 I suppose that Informix reach the pseudo-table
limit of 32GB.
For the others
its strange. In our case the amount of all free pages were 0.
We had a lot of space for User Data and Meta Data, but in LO_hdr_parth we had
0 Free for all chunks.
Regards,
Hi,
thank you for your input, sad that your problem has not really been solved yet.
You are right, two of our chunks have the maximum pages used.
And I suspect the answer lies there somewhere.
According to our logfiles, we had a temporary problem, which occured only
twice, but when
the error occurred, no inserts did work (error -136, no more extents was
thrown in the application).
After some tries (about 100, according to our logfiles), inserts succeeded
again.
This situation was recurring after 20 minutes, when we decided to move traffic
to a new instance temporarily.
At the moment, the instance is running but we are not inserting data.
(we modified the application, to look in two databases, one active for write,
one archive instance,
only for reading old data, which has some benefits, but I cannot be sure that
archiving data from the
active instance in the archive will not provoke the error again. At least,
customers would not be affected
at this stage.).
I have the idea that somebody deleted a record in a full chunk and the system
had a problem re-using the space, wanted to add a page, which was not possible
due to
reached max pages. We are trying to reproduce that.
We have to find the problem, cause otherwise we would never know if the error
comes up again, which leads to ugly problems for our customers.
Maybe it takes a moment, but I do not want to copy 2.5TB data to a new
instance, not knowing
if the same error could occur there, too.
Marcus Haarmann
----- Ursprüngliche Mail -----
Von: "BOYCHO VELKOV" <bobi@ndb.bg>
An: ids@iiug.org
Gesendet: Freitag, 11. April 2014 17:49:13
Betreff: Re: informix.LO_hdr_partn [32904]
Hi Marcus,
We had the same problem a few months ago with Informix 11.50.FC9 on HP-UX with
4 chunks in sbspace 1TB of data.
We did not have a time to open PMR(Case) because our system is 24x7. We find
workaround to rename the tables with BLOB-CLOB column and recreate new
tables in a new sbspace with big Metadata partition and AVG_LO_SIZE=2K(Lowest
value).
We are lucky, because developer agreed to change the application and recreate
the part of application with select in old and new tables.
But Im sure that after a year well have the same problem.
This is a part of your onstat cs output:
sblobdbs:'informix'.LO_hdr_partn 0x200005 16777215 0
sblobdbs:'informix'.LO_hdr_partn 0x200007 16777215 0
sblobdbs:'informix'.LO_hdr_partn 0x20000b 3310646 0
sblobdbs:'informix'.LO_hdr_partn 0x20000d 892734 2764897
In the 0x200005 and 0x200007 I suppose that Informix reach the pseudo-table
limit of 32GB.
For the others its strange. In our case the amount of all free pages were
0.
We had a lot of space for User Data and Meta Data, but in LO_hdr_parth we had
0 Free for all chunks.
Regards,
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.