Oninit cdi / Archive
Talk to an expert →

Emergency, Error 271

Posted in 2013

Summary

User experienced Informix error 271 on IDS 11.50 FC 9 with 20 parallel instances querying the same table. Space, temp dbspace, and locks were adequate. Art Kagel noted error 271 occurs when a table reaches 16,777,216 pages in a single partition. The issue was resolved by unloading, dropping, recreating, and reloading the table, though the root cause remained unexplained.

Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.

Topics: Storage & Space Management, Stored Procedures & SPL, Error Codes & Troubleshooting

SMITH JOHN — — source: IIUG Forums & Mailing Lists

IDS 11.50 FC 9 (ultimate) I have a program that runs in parallel, multiple instances at the same time (20 instances), this program is launching the same queries on the same table, and after a few instances the error code 271 is displayed. I checked the space and dbspace is not saturated I checked the temporary dbspaces and they are not saturated I checked the number of locks (5 000 000) and is sufficient, the table contains 1.5 million records where the problem may lie in your opinion ? thank you in advance

↪ replying to SMITH JOHN
SMITH JOHN — — source: IIUG Forums & Mailing Lists

Hi, i'm made some search on the forum and MARK COLLINS post is very interesting. i have to tell that all the tables are a 32k (8 pages) as size for the first extent and also 32 k for the next extent

↪ replying to SMITH JOHN
Art Kagel — — source: IIUG Forums & Mailing Lists

How many pages does the table have? You will get that error if the table reaches 16,777,216 pages in a single partition/fragment. Art On May 7, 2013 5:18 PM, "SMITH JOHN" <daylight@webmails.com> wrote: > IDS 11.50 FC 9 (ultimate) > > I have a program that runs in parallel, multiple instances at the same time > (20 instances), this program is launching the same queries on the same > table, > and after a few instances the error code 271 is displayed. > I checked the space and dbspace is not saturated > I checked the temporary dbspaces and they are not saturated > I checked the number of locks (5 000 000) and is sufficient, the table > contains 1.5 million records > > where the problem may lie in your opinion ? > > thank you in advance > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93d9708dc567104dc284f60

↪ replying to SMITH JOHN
Art Kagel — — source: IIUG Forums & Mailing Lists

How many extents? Art On May 7, 2013 5:48 PM, "SMITH JOHN" <daylight@webmails.com> wrote: > Hi, > i'm made some search on the forum and MARK COLLINS post is very > interesting. > > i have to tell that all the tables are a 32k (8 pages) as size for the > first > extent and also 32 k for the next extent > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93d97084db40704dc285cd3

↪ replying to Art Kagel
marions — — source: IIUG Forums & Mailing Lists

And another question: What is the ISAM error code? If you don't get the ISAM code from your application you can run "onstat -g sql -r 1" for some time. It shows both: SQL and ISAM error. The other possibility is to trap the error with "onmode -I 271" This will write an AF when the error occurs. Check the online.log for related messages. Switch off error trapping with "onmode -I" after the first AF was written. You should not use this method on production systems and when the error occurs very often. It might keep the server busy writing AFs and shm dumps. Marion Am 08.05.2013 00:30, schrieb Art Kagel: > How many extents? > > Art > On May 7, 2013 5:48 PM, "SMITH JOHN" <daylight@webmails.com> wrote: > >> Hi, >> i'm made some search on the forum and MARK COLLINS post is very >> interesting. >> >> i have to tell that all the tables are a 32k (8 pages) as size for the >> first >> extent and also 32 k for the next extent >> >> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > --14dae93d97084db40704dc285cd3 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > >

↪ replying to Art Kagel
SMITH JOHN — — source: IIUG Forums & Mailing Lists

the problem has been solved by unloading/dropping/recreating/loading the table. weird isn't it ?

Related threads

Glossary