If you decide to take Jacob's advice to copy the data to a new table with the new column length and partitioned in a 16K dbspace, I would recommend that instead of unloading the data and reloading it that you copy it directly from the current table to the new one. The absolute fastest way to do that is using my dbcopy utility. Dbcopy is included in the open source package utils2_ak which you can download from my own website (free) at My Utilities The packate also includes several other very useful DBA tools.
The IIUG (International Informix Users Group) is an advocate for Informix users worldwide providing a voice for us within IBM and HCL (the company that IBM contracts with the actually maintain the Informix code). You should join as a member (free) which will put you on our mailing list (I am a member of the IIUG Board of Directors) which includes our monthly newsletter The Insider. You can join at the IIUG web site: www.iiug.org.
Note that IBM is running a webinar today at 11:00 AM US Eastern Time. Here is a description of the event and a link to the page on the IIUG site where you can register to attend:
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
Original Message:
Sent: Wed March 27, 2024 10:44 PM
From: chuan lu
Subject: alter table modify lvarchar column length report -136 ' no more extents' error
Hi, Art,Marcus,Jacob:
I make sense about your suggestion, it's do help for me.
I do the double check, the real alter statement is "alter table epcc_paysrl_attach modify ordrdesc lvarchar(2458)", customer double the column size.
Marcus , reorg is a good suggestion , but we want to do the fragment take advantage of this opportunity.
I will suggest the customer to do the fragment , and move the table to 16K dbpspace , and after we summary the data pages used, and will enlarge the first extent size and next extent size also ;
jacob, your suggestion can decrease the outage duration of the system,but both the customer and me don't familiar with IIUG website. I am the support team and I don't do the testing myself.
Thank you very much for your help
------------------------------
chuan lu
Original Message:
Sent: Tue March 26, 2024 07:03 AM
From: Art Kagel
Subject: alter table modify lvarchar column length report -136 ' no more extents' error
Chuan:
You have asked "why?" and no one has given you a complete answer yet. So, here goes:
- With MAX_FILL_DATA_PAGES not set the engine will not place a variable length row on a page that already has data on it unless the maximum length of the new row will fit on that page, even if the actual length of the row is only 33 bytes (the minimum disk footprint of one of this table's rows. So, while a 4K page can hold up to 50 minimum sized rows and still have room for another because that would leave enough room for a full length 2217 byte row (plus its slot table entry), only one row of even 33 bytes will fit on a page when the maximum row length is increased from 2217 bytes to 5084 bytes (assuming it is the ordrdesc column you are actually trying to expand - more if it is another column)! So, with the now 4096 byte length of that column you would need at least 80 million pages (more than 80 million pages if there are actually rows that are physically wider than 4068 bytes since the maximum number of data bytes that will fit on a page). So, it is actually not the number of extents that has maxed out during the table's rebuild/alter but rather the maximum number of pages (2^24 = 16,777,216) that was exceeded. I know that is not the error code you got, but that incorrect error code is a long standing bug in the error reporting code.
- Since your EXTENT SIZE is only 10240 pages and your NEXT SIZE is only 16 pages, it is quite possible that even with MAX_FILL_DATA_PAGES set you will actually exceed the maximum number of extents for the table before extend compression and extent size doubling can make the experienced next size large enough. You need to set EXTENT SIZE and NEXT SIZE both to something closer to 1,000,000 pages something like at least 100,000 each.
- With MAX_FILL_DATA_PAGES the engine will be allowed to place a new row on a page as long as at least 10% of the page will be free to allow the rows on the page to expand if they are updated with longer values without having to be moved to a "forwarding page". That might allow the new copy of the table to occupy nearly the same number of pages that it does now, or possibly many fewer pages.
Art
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
Original Message:
Sent: Mon March 25, 2024 10:35 PM
From: chuan lu
Subject: alter table modify lvarchar column length report -136 ' no more extents' error
Hi,
I check the onconfig, the parameter MAX_FILL_DATA_PAGES exist in version 11.5 also.
below are the table schema.
{ TABLE "epcc".epcc_paysrl_attach row size = 2217 number of columns = 29 index size
= 54 }
create table "epcc".epcc_paysrl_attach
(
instgid varchar(14) not null ,
trxid varchar(31) not null ,
rpflg varchar(1) not null ,
ordrid varchar(40),
ordrdesc lvarchar(1229),
ordrexp varchar(19),
mrchnttpid varchar(4),
mrchntpltfrmnm varchar(20),
trxtrmtp varchar(2),
trxtrmno varchar(32),
trxprps char(4),
ipaddr varchar(45),
mac varchar(12),
imei varchar(15),
imsi varchar(15),
iccid varchar(20),
wifimac varchar(12),
gps varchar(24),
cpext01 varchar(20),
cpext02 varchar(60),
cpext03 varchar(120),
mkinfo1 varchar(20),
mkinfo2 varchar(20),
mkinfo3 varchar(60),
mkinfo4 varchar(60),
mkinfo5 varchar(120),
mkinfo6 varchar(120),
createts varchar(24),
updatets varchar(24),
primary key (instgid,trxid,rpflg) constraint "epcc".pk_epcc_paysrl_attach
) extent size 10240 next size 16 lock mode row;
revoke all on "epcc".epcc_paysrl_attach from "public" as "epcc";
extent size 16K is a small number also, I use 'oncheck -pP' to verified that the table still have 368 free extent , but Why 'alter table X modify column-name' report 'no more extent' error.
we do have plan to do the unload/load using the external table .
------------------------------
chuan lu
Original Message:
Sent: Mon March 25, 2024 01:24 PM
From: Jacob Salomon
Subject: alter table modify lvarchar column length report -136 ' no more extents' error
If you have Perl installed as well as Jonathan Leffler's magnum opus module DBD::Informix:
Here's my $0.02(US), as well as a shameless plug:
- Rather than try to do an in-place alter table, create a new table with the identical schems as the current table, except with that one column typed as your lvarchar(4096). And an initial extent of at least the size of the current table, next size maybe 25% of that.
- Download my fcopy-table.pl from the IIUG repository in SourceForge. (It has a big help page).
- Copy the old table to the new one using fcopy-table. I think the default commit interval is about 10,000 rows but you can check on that.
- Rename the old table to table_orig
- Rename the new table to the original name of the old table.
You will have to recreate the PK and FK constraints manually. Get this information from dbaccess/table/info/constraints before starting this procedure. Might even be a good idea to set those up before you start the copy these will slow down the copy. Besides, that's probably not needed for a mere 80 million rows.
Let us know if you were able to pull this off.
If you don't have Perl or the necessary modules, pout and throw a tantrum at your admins until they give in and install these ultra-useful facilities.. <Wicked grin> If that fails, I believe Art Kagel's table-copy utility will do the job quite nicely.
------------------------------
Jacob Salomon
---
Nobody goes there anymore, it's too crowded. --Attr: Yogi Berra
Original Message:
Sent: Sun March 24, 2024 11:43 PM
From: chuan lu
Subject: alter table modify lvarchar column length report -136 ' no more extents' error
Hi, experts:
I execute the 'alter table table-name modify pexp lvarchar(4096) ' ,the table has about 80M rows, and informix report below errors.
222: cannot write to temporary file for new table
136: ISAM error : no more extents
my IDS version is 11.5, the dbspace page size is 4K;
How to avoid the problem? any suggestion are appreciation
lu chuan
------------------------------
chuan lu
------------------------------