|
Below is the latest content available from this feed:
RES: IDS V11.50FC6 and Compression
Posted by: ccoimbra@cleartech.com.br (Celso Cabral Coimbra) - Fri, 12 Mar 2010 09:21:30 EST
Rick,
I have experienced the compress in IDS 11.50.FC4 like yours 740 million rows
(row size 196 bytes) it has taken 11:20 hours to finish. The compress is I/o
Intensive and the engine updates all rows of your table generating lots of
logical logs.
I really discourage you to disable the logical log, because probably your
database is doing other activities as well.
The repack will take more time, if you run the repack online it will take 3 to
10 times longer and will lock the table and the related tables linked by
foreign keys. And if those tables are intensively used the compress can be
aborted. If you have maintenance window, you should drop the indexes, primary
keys and foreign keys and run the repack offline.
Best regards,
Celso Cabral Coimbra
Administrador de Banco de Dados
ClearTech Ltda
"Trust at the heart of Communications"
Tel. (11) 3576-4509
-----Mensagem original-----
De: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Em nome de RICK HILL
Enviada em: quinta-feira, 11 de março de 2010 04:59
Para: ids@iiug.org
Assunto: IDS V11.50FC6 and Compression [19310]
Hi All,
I am just looking at the possibility of using IDS compression.
I just wanted to know if anyone has experience with this and what your
feelings are.
Also i have a table that has 800+ million rows, so far it has taken about 10
hours and it is still not finished...
I expect it would be quicker to unload the table, set compression on and
reload, but will have to test this as well.
The main issue i am facing is that compressing a table is very very log
intensive, our TSM server can not keep up with the logs being filled.
For now i have turned this off and the logs backup to /dev/null, but for
obvious reasons this can not be done in a production environment.
Has anyone encountered this and if so did you manage to get around it.
Any information around this would be really appreciated.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19324]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: eromero@sitrack.com (Emiliano Romero) - Fri, 12 Mar 2010 06:41:58 EST
Art, Dave, Bob. Thanks everyone for your help, I'm going to fragment my
table.
Thanks and Regards
Art Kagel escribió:
> The problem isn't the number of extents but the number of pages. A single
> table or index partition can't have more than 16777215 pages and that's
> exactly the number of pages you have. You will have to fragment the table
> in to multiple partitions. Since you are using IDS 10.00 you will have to
> fragment the table into two or more dbspaces.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (art@iiug.org)
>
> See you at the 2010 IIUG Informix Conference
> April 25-28, 2010
> Overland Park (Kansas City), KS
> www.iiug.org/conf
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Thu, Mar 11, 2010 at 1:02 PM, Emiliano Romero <eromero@sitrack.com>wrote:
>
>
>> Hi list, I'm having a problem with my database. When I try to insert a
>> row in my biggest table i get:
>> 271: Could not insert new row into the table.
>> 136: ISAM error: no more extents
>>
>> oncheck -pt shows:
>>
>> Physical Address 4:527
>>
>> Creation date 01/24/2010 13:19:43
>>
>> TBLspace Flags 802 Row Locking
>>
>> TBLspace use 4 bit bit-maps
>>
>> Maximum row size 24
>>
>> Number of special columns 0
>>
>> Number of keys 0
>>
>> Number of extents 7
>>
>> Current serial value 1
>>
>> Pagesize (k) 2
>>
>> First extent size 5000000
>>
>> Next extent size 750000
>>
>> Number of pages allocated 16777215
>>
>> Number of pages used 16777215
>>
>> Number of data pages 16773053
>>
>> Number of rows 1207659816
>>
>> Partition partnum 4194396
>>
>> Partition lockid 4194396
>>
>> Extents
>>
>> Logical Page Physical Page Size Physical Pages
>>
>> 0 4:5095236 5750000 5750000
>>
>> 5750000 4:42968656 7500000 7500000
>>
>> 13250000 4:32405955 750000 750000
>>
>> 14000000 4:36380420 750000 750000
>>
>> 14750000 4:39023045 750000 750000
>>
>> 15500000 4:54801988 750000 750000
>>
>> 16250000 4:56145738 527215 527215
>> Indexes are very similar 5-7 extents.
>> onstat -d shows:
>> IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
>> days 16:37:13 -- 1684560 Kbytes
>>
>> Dbspaces
>> address number flags fchunk nchunks pgsize flags
>> owner name
>> 8674ee78 1 0x40001 1 1 2048 N B
>> informix rootdbs
>> 879599e8 2 0x40001 2 1 2048 N B
>> informix physdbs
>> 87959b80 3 0x42001 3 1 2048 N TB
>> informix tempdbs
>> 87959d18 4 0x40001 4 1 2048 N B
>> informix datadbs
>> 4 active, 2047 maximum
>>
>> Chunks
>> address chunk/dbs offset size free bpages
>> flags pathname
>> 8674f028 1 1 0 2560000 807158
>> PO-B /opt/informix/IFMXDATA/rootdbs
>> 8674fd10 2 2 0 1000000 499947
>> PO-B /opt/informix/IFMXDATA/physdbs
>> 87959028 3 3 0 1000000 995996
>> PO-B /opt/informix/IFMXDATA/tempdbs
>> 879591c8 4 4 0 286346500 230360798
>> PO-B /opt/informix/IFMXDATA/datadbs
>>
>> and at the end of oncheck -pe I can see:
>> FREE 58091703
>> 228254797
>>
>> Total Used: 55985702
>> Total Free: 230360798
>>
>> Even with free space, and really far of getting my extent limit, I'm
>> getting this error. The last extent is a little smaller than what I set
>> in next extent size. I dont think i get out of contiguous space because
>> oncheck -pe shows that I have 230360798 pages free.
>>
>> Any help should be great.
>>
>> Thanks and regards
>>
>> Emiliano Romero
>>
>>
>>
>>
>>
>
>
>>
>>
>>
>>
>
> --000e0ce07a9c640c9204818cdf05
>
>
>
>
>
>
>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19323]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: BACKUP_FILTER in onconfig
Posted by: ivan.zavis@mi-system.co.rs (Ivan Zavis DBA) - Fri, 12 Mar 2010 03:38:36 EST
Yes, it's true ...
"Note also that 11.10 "ontape" logical log backup ignores BACKUP_FILTER,
and 11.50 "ontape" logical log backup uses TAPEBLK not LTAPEBLK :-)
Regards, Doug Lawry "
More about this on:
http://www.eggheadcafe.com/software/aspnet/35676695/encryption-in-ontape-for.aspx
On 05.03.2010 20:31, IVAN ZAVIS wrote:
> Hello,
>
> when I using BACKUP_FILTER in $ONCONFIG, parameter for "The tape block size,
> in KB, for backing up logical logs" is NOT LTAPEBLK, but it is TAPEBLK.
>
> Everything work fine (LTAPEBKL for logical log) when I turn off
BACKUP_FILTER
> ....
>
> This is happening with ontape, with BACKUPLOGS="Y" in alarmprogs, and
TAPEDEV
> and LTAPEDEV is some directory in file system.
>
> Is it a BUG or?
>
> My Box is on Informix 11.50.UC5WE, OS is Linux SuSe 11.1.
>
> BTW. I figured this out when my restore logical log with RESTORE_FILTER did
> not success ... It's happenings on test Box :)
>
>
>
>
>
>
--
Ivan Zaviç
System& DB Administrator
Mobile:+381-64-846-99-08
mail: ivan.zavis@mi-system.co.rs
_________________________________________________________
M&I SYSTEMS CO.
Cirila i Metodija 13/a, 21000 Novi Sad, Serbia
Tel/Fax: +381-(0)21-68-98-600
Mail: info@mi-system.co.rs, URL: http://www.mi-system.co.rs
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19322]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RE: 4GL run-time error number -4339
Posted by: mosserp@wellsfargo.com (mosserp@wellsfargo.com) - Thu, 11 Mar 2010 18:43:36 EST
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> LARRY SORENSEN
> Sent: Wednesday, March 10, 2010 2:54 PM
> To: ids@iiug.org
> Subject: RE: 4GL run-time error number -4339 [19306]
>
> The load is handled by a separate process; each record is entered by a
> program
> one at a time and committed each time. Once the claim is in, the
> Traffic Cop
> moves the record along a series of Java programs; it is the final step
> in the
> services that spawns out the thread to a 4ge program.
>
> The 4ge program reads data from the Informix database and creates a 4GL
> report
> (that is later printed and sent out. It updates one record in the one
> table
> which indicates that the report has been completed and saves a
> compressed copy
> of the report to the another table.
>
> Each set of programs handles one record at a time and begins and
> commits work
> as appropriate. I believe that the problem arises when the process that
> calls
> the 4ge program continues on to the next record while the 4ge is still
> running. As a result we get a situation where multiple 4ge threads are
> running
> for different record reports and a wall might be hit; I don't know if
> the wall
> relates to just the Shared Memory limits or if it has to do with the
> number of
> open files being written to or some other limiting factor but once that
> wall
> is hit no more reports are created for a while. Then "magically" the
> reports
> start up again until the wall is again hit. So when you look at the
> first
> record table you see a number of entries where the record_id is set
> (indicating the report was created and saved to the correct table).
> Then there
> will be a series of records that don't have a record_id, then some with
> record_ids, and so one. So it appears that the original process
> continues to
> spawn out the threads but they are killed during or just before the 4ge
> program is run.
>
Larry,
This is a bit of a long shot, but... Do you see any long transaction rollbacks
in the message log when things come to a halt?? What is your "set lock mode to
wait ..." set to?
HTH,
Paul M.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19321]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: art.kagel@gmail.com (Art Kagel) - Thu, 11 Mar 2010 16:17:16 EST
It will get you more rows as long as the rowsize is wider than 4 bytes which
is the ONLY row size that can fit 255 rows on a 2K page! Now if you have an
8byte row you will waste half of each page when using 8K pages, but a 4K
pagesize WILL double the number of rows per page versus a 2K pagesize and
therefore halve the number of pages required.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Thu, Mar 11, 2010 at 3:57 PM, Richard Snoke <dsnoke@us.ibm.com> wrote:
> Be careful. The limit of 255 rows per page has not changed. Larger page
> sizes do not raise the limit of rows per fragement. Larger page sizes get
> you larger rows on a page without any remainder pages, but not more rows.
>
> Cheers,
> Dick Snoke
> Executive IT Specialist
> IBM Software Group - ChannelWorks
>
> Tel: (404) 487-1595
> Email: dsnoke@us.ibm.com
>
> From:
> "Informix DBA" <in4mixdba@gmail.com>
> To:
> ids@iiug.org
> Date:
> 03/11/10 02:02 PM
> Subject:
> Re: 136: ISAM error: no more extents even with.... [19316]
> Sent by:
> ids-bounces@iiug.org
>
> You can also move the table to a DBSPACE with a larger page size like 4k
> or
> 8k that way you will fit more rows on a page and thus use fewer pages for
> the same number of records.
>
> --Dave
>
> On Thu, Mar 11, 2010 at 1:41 PM, Emiliano Romero
> <eromero@sitrack.com>wrote:
>
> > My problem is that I reached the max number of pages, so the only
> > solution seems to be fragmentation.
> >
> > Regards!
> >
> > Emiliano Romero escribió:
> > > Hi list, I'm having a problem with my database. When I try to insert a
>
> > > row in my biggest table i get:
> > > 271: Could not insert new row into the table.
> > > 136: ISAM error: no more extents
> > >
> > > oncheck -pt shows:
> > > Physical Address 4:527
> > > Creation date 01/24/2010 13:19:43
> > > TBLspace Flags 802 Row Locking
> > > TBLspace use 4 bit bit-maps
> > > Maximum row size 24 Number of special
> > > columns 0 Number of keys 0
> > > Number of extents 7 Current serial
> > > value 1 Pagesize (k) 2
> > > First extent size 5000000 Next extent
> > > size 750000 Number of pages allocated 16777215
> > > Number of pages used 16777215 Number of data
> > > pages 16773053 Number of rows 1207659816
> > > Partition partnum 4194396 Partition
> > > lockid 4194396
> > > Extents Logical Page Physical
> > > Page Size Physical Pages
> > > 0 4:5095236 5750000 5750000
> > > 5750000 4:42968656 7500000 7500000
> > > 13250000 4:32405955 750000 750000
> > > 14000000 4:36380420 750000 750000
> > > 14750000 4:39023045 750000 750000
> > > 15500000 4:54801988 750000 750000
> > > 16250000 4:56145738 527215 527215
> > > Indexes are very similar 5-7 extents.
> > > onstat -d shows:
> > > IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
> > > days 16:37:13 -- 1684560 Kbytes
> > >
> > > Dbspaces
> > > address number flags fchunk nchunks pgsize
> > > flags owner name
> > > 8674ee78 1 0x40001 1 1 2048 N
> > > B informix rootdbs
> > > 879599e8 2 0x40001 2 1 2048 N
> > > B informix physdbs
> > > 87959b80 3 0x42001 3 1 2048 N
> > > TB informix tempdbs
> > > 87959d18 4 0x40001 4 1 2048 N
> > > B informix datadbs
> > > 4 active, 2047 maximum
> > >
> > > Chunks
> > > address chunk/dbs offset size free
> > > bpages flags pathname
> > > 8674f028 1 1 0 2560000
> > > 807158 PO-B /opt/informix/IFMXDATA/rootdbs
> > > 8674fd10 2 2 0 1000000
> > > 499947 PO-B /opt/informix/IFMXDATA/physdbs
> > > 87959028 3 3 0 1000000
> > > 995996 PO-B /opt/informix/IFMXDATA/tempdbs
> > > 879591c8 4 4 0 286346500
> > > 230360798 PO-B /opt/informix/IFMXDATA/datadbs
> > >
> > > and at the end of oncheck -pe I can see:
> > > FREE 58091703
> > > 228254797
> > >
> > > Total Used: 55985702
> > > Total Free: 230360798
> > >
> > > Even with free space, and really far of getting my extent limit, I'm
> > > getting this error. The last extent is a little smaller than what I
> > > set in next extent size. I dont think i get out of contiguous space
> > > because oncheck -pe shows that I have 230360798 pages free.
> > >
> > > Any help should be great.
> > >
> > > Thanks and regards
> > >
> > >
> > > Emiliano Romero
> > >
> >
> >
> >
> >
>
>
>
>
> >
> >
> >
>
> --00163641661d3d333704818b0918
>
>
>
>
>
>
>
>
>
>
>
>
>
--0015173fe48429d8c404818ced6a
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19320]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: art.kagel@gmail.com (Art Kagel) - Thu, 11 Mar 2010 16:13:01 EST
The problem isn't the number of extents but the number of pages. A single
table or index partition can't have more than 16777215 pages and that's
exactly the number of pages you have. You will have to fragment the table
in to multiple partitions. Since you are using IDS 10.00 you will have to
fragment the table into two or more dbspaces.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Thu, Mar 11, 2010 at 1:02 PM, Emiliano Romero <eromero@sitrack.com>wrote:
> Hi list, I'm having a problem with my database. When I try to insert a
> row in my biggest table i get:
> 271: Could not insert new row into the table.
> 136: ISAM error: no more extents
>
> oncheck -pt shows:
>
> Physical Address 4:527
>
> Creation date 01/24/2010 13:19:43
>
> TBLspace Flags 802 Row Locking
>
> TBLspace use 4 bit bit-maps
>
> Maximum row size 24
>
> Number of special columns 0
>
> Number of keys 0
>
> Number of extents 7
>
> Current serial value 1
>
> Pagesize (k) 2
>
> First extent size 5000000
>
> Next extent size 750000
>
> Number of pages allocated 16777215
>
> Number of pages used 16777215
>
> Number of data pages 16773053
>
> Number of rows 1207659816
>
> Partition partnum 4194396
>
> Partition lockid 4194396
>
> Extents
>
> Logical Page Physical Page Size Physical Pages
>
> 0 4:5095236 5750000 5750000
>
> 5750000 4:42968656 7500000 7500000
>
> 13250000 4:32405955 750000 750000
>
> 14000000 4:36380420 750000 750000
>
> 14750000 4:39023045 750000 750000
>
> 15500000 4:54801988 750000 750000
>
> 16250000 4:56145738 527215 527215
> Indexes are very similar 5-7 extents.
> onstat -d shows:
> IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
> days 16:37:13 -- 1684560 Kbytes
>
> Dbspaces
> address number flags fchunk nchunks pgsize flags
> owner name
> 8674ee78 1 0x40001 1 1 2048 N B
> informix rootdbs
> 879599e8 2 0x40001 2 1 2048 N B
> informix physdbs
> 87959b80 3 0x42001 3 1 2048 N TB
> informix tempdbs
> 87959d18 4 0x40001 4 1 2048 N B
> informix datadbs
> 4 active, 2047 maximum
>
> Chunks
> address chunk/dbs offset size free bpages
> flags pathname
> 8674f028 1 1 0 2560000 807158
> PO-B /opt/informix/IFMXDATA/rootdbs
> 8674fd10 2 2 0 1000000 499947
> PO-B /opt/informix/IFMXDATA/physdbs
> 87959028 3 3 0 1000000 995996
> PO-B /opt/informix/IFMXDATA/tempdbs
> 879591c8 4 4 0 286346500 230360798
> PO-B /opt/informix/IFMXDATA/datadbs
>
> and at the end of oncheck -pe I can see:
> FREE 58091703
> 228254797
>
> Total Used: 55985702
> Total Free: 230360798
>
> Even with free space, and really far of getting my extent limit, I'm
> getting this error. The last extent is a little smaller than what I set
> in next extent size. I dont think i get out of contiguous space because
> oncheck -pe shows that I have 230360798 pages free.
>
> Any help should be great.
>
> Thanks and regards
>
> Emiliano Romero
>
>
>
>
>
>
>
--000e0ce07a9c640c9204818cdf05
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19319]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 4GL run-time error number -4339
Posted by: art.kagel@gmail.com (Art Kagel) - Thu, 11 Mar 2010 16:12:31 EST
It's unlikely that this is a configuration problem. Most likely has always
been a problem, but it is expressing itself on the new server because of the
differences in the memory handling and memory layout between the two
systems.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Thu, Mar 11, 2010 at 12:26 PM, LARRY SORENSEN <lsorensen25@msn.com>wrote:
> I am checking on the flow of the program, but in the meantime, the same
> program was working on our previous server before the migration. Which
> configuration parameters, whether Informix or kernel, should I be looking
> at
> to possibly fix this problem.
>
> Thanks
>
> > To: ids@iiug.org
> > From: art.kagel@gmail.com
> > Subject: Re: 4GL run-time error number -4339 [19309]
> > Date: Wed, 10 Mar 2010 19:48:54 -0500
> >
> > Jonathan's point is this:
> >
> > - When you fork a child process, whether the parent process is written in
> >
> > C, C4GL, R4GL (ie run by the 4Gl p-machine), or Java (ie is run by the
> JRE)
> >
> > the child inherits shared memory, network connections, and file handles
> from
> >
> > its parent.
> >
> > - If you did not disconnect the child process or thread from the parent's
> >
> > connection to the database before execing the new process the new process
> is
> >
> > using the parent's connection and the two processes may be interfering
> with
> >
> > each other. IDS does not expect to be receiving instructions from two
> >
> > processes on a single connection.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > IIUG Board of Directors (art@iiug.org)
> >
> > See you at the 2010 IIUG Informix Conference
> > April 25-28, 2010
> > Overland Park (Kansas City), KS
> > www.iiug.org/conf
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other
> > organization with which I am associated either explicitly, implicitly, or
> by
> > inference. Neither do those opinions reflect those of other individuals
> > affiliated with any entity with which I am affiliated nor those of the
> > entities themselves.
> >
> > On Wed, Mar 10, 2010 at 4:53 PM, LARRY SORENSEN <lsorensen25@msn.com>
> wrote:
> >
> > > The load is handled by a separate process; each record is entered by a
> > > program
> > > one at a time and committed each time. Once the claim is in, the
> Traffic
> > > Cop
> > > moves the record along a series of Java programs; it is the final step
> in
> > > the
> > > services that spawns out the thread to a 4ge program.
> > >
> > > The 4ge program reads data from the Informix database and creates a 4GL
> > > report
> > > (that is later printed and sent out. It updates one record in the one
> table
> > > which indicates that the report has been completed and saves a
> compressed
> > > copy
> > > of the report to the another table.
> > >
> > > Each set of programs handles one record at a time and begins and
> commits
> > > work
> > > as appropriate. I believe that the problem arises when the process that
> > > calls
> > > the 4ge program continues on to the next record while the 4ge is still
> > > running. As a result we get a situation where multiple 4ge threads are
> > > running
> > > for different record reports and a wall might be hit; I don't know if
> the
> > > wall
> > > relates to just the Shared Memory limits or if it has to do with the
> number
> > > of
> > > open files being written to or some other limiting factor but once that
> > > wall
> > > is hit no more reports are created for a while. Then "magically" the
> > > reports
> > > start up again until the wall is again hit. So when you look at the
> first
> > > record table you see a number of entries where the record_id is set
> > > (indicating the report was created and saved to the correct table).
> Then
> > > there
> > > will be a series of records that don't have a record_id, then some with
> > > record_ids, and so one. So it appears that the original process
> continues
> > > to
> > > spawn out the threads but they are killed during or just before the 4ge
> > > program is run.
> > >
> > > Any clearer? I know that was involved. I tried to leave it a little
> generic
> > > on
> > > purpose leaving off program and table names.
> > >
> > > > To: ids@iiug.org
> > > > From: jleffler.iiug@gmail.com
> > > > Subject: Re: 4GL run-time error number -4339 [19304]
> > > > Date: Wed, 10 Mar 2010 16:20:03 -0500
> > > >
> > > > On Wed, Mar 10, 2010 at 09:49, LARRY SORENSEN <lsorensen25@msn.com>
> > > wrote:
> > > >
> > > > > Another bit of information -
> > > > >
> > > > > The 4gl program inserts data into tables and calls and forks off a
> call
> > > to
> > > > > another program that does further processing. It is usually quick,
> but
> > > if
> > > > > the
> > > > > data is too large, there may be a number of forked processes out
> there.
> > > > > First,
> > > > > could this result in the error message, and second, what parameters
> > > might
> > > I
> > > > > need to adjust to overcome this limitation?
> > > > >
> > > >
> > > > What form does the 'further processing' take?
> > > >
> > > > Specifically, does the forked process try to use the database?
> > > >
> > > > If so, you are going to have problems; connections are not for
> sharing
> > > > between processes, and if you have two processes trying to use 'the
> same
> > > > connection' then you run into problems which could easily include the
> > > error
> > > > you are seeing.
> > > >
> > > > > Larry
> > > > >
> > > > > > To: ids@iiug.org
> > > > > > From: lsorensen25@msn.com
> > > > > > Subject: RE: 4GL run-time error number -4339 [19299]
> > > > > > Date: Wed, 10 Mar 2010 11:54:47 -0500
> > > > > >
> > > > > > This is code that has been compiled. It ran just fine on the
> Solaris
> > > 5.6,
> > > > > IDS
> > > > > > 7.32 platform before we migrated. Apparently, parameters, etc.
> were
> > > set
> > > > > > corrrectly and somehow missed during the migration. Now I am
> looking
> > > for
> > > > > > something to tweak so that it will run as it did before the
> > > migration.
> > > > > >
> > > > > > Larry
> > > > > >
> > > > > > > To: ids@iiug.org
> > > > > > > From: art.kagel@gmail.com
> > > > > > > Subject: Re: 4GL run-time error number -4339 [19298]
> > > > > > > Date: Wed, 10 Mar 2010 08:42:24 -0500
> > > > > > >
> > > > > > > There are suggestions in the output from "finderr -4339" for
> how
> to
> > > > > help
> > > > > > > resolve this problem. I also would look though at the code for
> this
> > > > > module
> > > > > > > to see if there are statements, forms, windows, etc. that have
> been
> > > > > opened
> > > > > > > and are no longer needed but have not been closed and freed.
> > > > > > >
> > > > > > > Is this Compiled 4GL (C4GL) or pcode 4GL (R4GL)?
> > > > > > >
> > > > >
> > > > >
> > > >
> > > > > > >
> > > > > > > On Tue, Mar 9, 2010 at 10:26 AM, LARRY SORENSEN <
> > > lsorensen25@msn.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > I am running on Solaris 5.10 and IDs 11.50. I have I4GL 7.32
> > > > > > > >
> > > > > > > > I would like some direction on what parameters that can be
> > > changed
> > > to
> > > > > > > > alleviate this problem. There is plenty of memory on the
> server.
> > > I
> > > am
> > > > > > > > currently checking into what program changes may have taken
> > > place,
> > > > > but I
> > > > > > > > need
> > > > > > > > direction in the mean time.
> > > > > > > >
> > > > > > > > Error
> > > > > > > >
> > > > > > > > Program error at "eob.4gl", line number 192.
> > > > > > > > SQL statement error number -406. --- Similar -406 errors are
> > > reported
> > > > > > after
> > > > > > > > this one in different lines of the application.
> > > > > > > > Memory allocation failed.Date: Time: 22:36:55Date: Time:
> 22:36:55
> > > --
> > > > > at
> > > > > > > > this
> > > > > > > > point the errors start getting jumbled
> > > > > > > > Program error at "eob.4gl", line number 192 Program error at
> > > > > "eob.4gl",
> > > > > > > > line
> > > > > > > > number 192.
> > > > > > > > SQL statement er.
> > > > > > > > ror number -406.SQL statement error number -406.
> > > > > > > > Memory allocation failed.
> > > > > > > >
> > > > > > > > Date: Time: 22:37:03
> > > > > > > > 4GL run-time error number -4339.
> > > > > > > > 4GL has run out of data space memory.
> > > > > > > > Date: Time: 22:37:05
> > > > > > > > 4GL run-time error number -4339.
> > > > > > > > 4GL has run out of data space memory.
> > > > >
> > > >
> > > > --
> > > > Jonathan Leffler #include <disclaimer.h>
> > > > Email: jleffler@earthlink.net, jleffler@us.ibm.com
> > > > Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
> > > > "Blessed are we who can laugh at ourselves, for we shall never cease
> to
> > > be
> > > > amused."
> > > > NB: Please do not use this email for correspondence.
> > > > I don't necessarily read it every week, even.
> > > >
> > > > --001636b2b0304f2adb048178dc13
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
> > >
> > >
> > >
> >
> > --0015174c0f3e3eaff104817a5015
> >
> >
> >
>
>
> >
> >
>
>
>
>
>
>
>
--00151748dd32755a8a04818cc6c1
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19318]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: dsnoke@us.ibm.com (Richard Snoke) - Thu, 11 Mar 2010 15:57:44 EST
Be careful. The limit of 255 rows per page has not changed. Larger page
sizes do not raise the limit of rows per fragement. Larger page sizes get
you larger rows on a page without any remainder pages, but not more rows.
Cheers,
Dick Snoke
Executive IT Specialist
IBM Software Group - ChannelWorks
Tel: (404) 487-1595
Email: dsnoke@us.ibm.com
From:
"Informix DBA" <in4mixdba@gmail.com>
To:
ids@iiug.org
Date:
03/11/10 02:02 PM
Subject:
Re: 136: ISAM error: no more extents even with.... [19316]
Sent by:
ids-bounces@iiug.org
You can also move the table to a DBSPACE with a larger page size like 4k
or
8k that way you will fit more rows on a page and thus use fewer pages for
the same number of records.
--Dave
On Thu, Mar 11, 2010 at 1:41 PM, Emiliano Romero
<eromero@sitrack.com>wrote:
> My problem is that I reached the max number of pages, so the only
> solution seems to be fragmentation.
>
> Regards!
>
> Emiliano Romero escribió:
> > Hi list, I'm having a problem with my database. When I try to insert a
> > row in my biggest table i get:
> > 271: Could not insert new row into the table.
> > 136: ISAM error: no more extents
> >
> > oncheck -pt shows:
> > Physical Address 4:527
> > Creation date 01/24/2010 13:19:43
> > TBLspace Flags 802 Row Locking
> > TBLspace use 4 bit bit-maps
> > Maximum row size 24 Number of special
> > columns 0 Number of keys 0
> > Number of extents 7 Current serial
> > value 1 Pagesize (k) 2
> > First extent size 5000000 Next extent
> > size 750000 Number of pages allocated 16777215
> > Number of pages used 16777215 Number of data
> > pages 16773053 Number of rows 1207659816
> > Partition partnum 4194396 Partition
> > lockid 4194396
> > Extents Logical Page Physical
> > Page Size Physical Pages
> > 0 4:5095236 5750000 5750000
> > 5750000 4:42968656 7500000 7500000
> > 13250000 4:32405955 750000 750000
> > 14000000 4:36380420 750000 750000
> > 14750000 4:39023045 750000 750000
> > 15500000 4:54801988 750000 750000
> > 16250000 4:56145738 527215 527215
> > Indexes are very similar 5-7 extents.
> > onstat -d shows:
> > IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
> > days 16:37:13 -- 1684560 Kbytes
> >
> > Dbspaces
> > address number flags fchunk nchunks pgsize
> > flags owner name
> > 8674ee78 1 0x40001 1 1 2048 N
> > B informix rootdbs
> > 879599e8 2 0x40001 2 1 2048 N
> > B informix physdbs
> > 87959b80 3 0x42001 3 1 2048 N
> > TB informix tempdbs
> > 87959d18 4 0x40001 4 1 2048 N
> > B informix datadbs
> > 4 active, 2047 maximum
> >
> > Chunks
> > address chunk/dbs offset size free
> > bpages flags pathname
> > 8674f028 1 1 0 2560000
> > 807158 PO-B /opt/informix/IFMXDATA/rootdbs
> > 8674fd10 2 2 0 1000000
> > 499947 PO-B /opt/informix/IFMXDATA/physdbs
> > 87959028 3 3 0 1000000
> > 995996 PO-B /opt/informix/IFMXDATA/tempdbs
> > 879591c8 4 4 0 286346500
> > 230360798 PO-B /opt/informix/IFMXDATA/datadbs
> >
> > and at the end of oncheck -pe I can see:
> > FREE 58091703
> > 228254797
> >
> > Total Used: 55985702
> > Total Free: 230360798
> >
> > Even with free space, and really far of getting my extent limit, I'm
> > getting this error. The last extent is a little smaller than what I
> > set in next extent size. I dont think i get out of contiguous space
> > because oncheck -pe shows that I have 230360798 pages free.
> >
> > Any help should be great.
> >
> > Thanks and regards
> >
> >
> > Emiliano Romero
> >
>
>
>
>
>
>
>
--00163641661d3d333704818b0918
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19317]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: in4mixdba@gmail.com (Informix DBA) - Thu, 11 Mar 2010 14:01:15 EST
You can also move the table to a DBSPACE with a larger page size like 4k or
8k that way you will fit more rows on a page and thus use fewer pages for
the same number of records.
--Dave
On Thu, Mar 11, 2010 at 1:41 PM, Emiliano Romero <eromero@sitrack.com>wrote:
> My problem is that I reached the max number of pages, so the only
> solution seems to be fragmentation.
>
> Regards!
>
> Emiliano Romero escribió:
> > Hi list, I'm having a problem with my database. When I try to insert a
> > row in my biggest table i get:
> > 271: Could not insert new row into the table.
> > 136: ISAM error: no more extents
> >
> > oncheck -pt shows:
> > Physical Address 4:527
> > Creation date 01/24/2010 13:19:43
> > TBLspace Flags 802 Row Locking
> > TBLspace use 4 bit bit-maps
> > Maximum row size 24 Number of special
> > columns 0 Number of keys 0
> > Number of extents 7 Current serial
> > value 1 Pagesize (k) 2
> > First extent size 5000000 Next extent
> > size 750000 Number of pages allocated 16777215
> > Number of pages used 16777215 Number of data
> > pages 16773053 Number of rows 1207659816
> > Partition partnum 4194396 Partition
> > lockid 4194396
> > Extents Logical Page Physical
> > Page Size Physical Pages
> > 0 4:5095236 5750000 5750000
> > 5750000 4:42968656 7500000 7500000
> > 13250000 4:32405955 750000 750000
> > 14000000 4:36380420 750000 750000
> > 14750000 4:39023045 750000 750000
> > 15500000 4:54801988 750000 750000
> > 16250000 4:56145738 527215 527215
> > Indexes are very similar 5-7 extents.
> > onstat -d shows:
> > IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
> > days 16:37:13 -- 1684560 Kbytes
> >
> > Dbspaces
> > address number flags fchunk nchunks pgsize
> > flags owner name
> > 8674ee78 1 0x40001 1 1 2048 N
> > B informix rootdbs
> > 879599e8 2 0x40001 2 1 2048 N
> > B informix physdbs
> > 87959b80 3 0x42001 3 1 2048 N
> > TB informix tempdbs
> > 87959d18 4 0x40001 4 1 2048 N
> > B informix datadbs
> > 4 active, 2047 maximum
> >
> > Chunks
> > address chunk/dbs offset size free
> > bpages flags pathname
> > 8674f028 1 1 0 2560000
> > 807158 PO-B /opt/informix/IFMXDATA/rootdbs
> > 8674fd10 2 2 0 1000000
> > 499947 PO-B /opt/informix/IFMXDATA/physdbs
> > 87959028 3 3 0 1000000
> > 995996 PO-B /opt/informix/IFMXDATA/tempdbs
> > 879591c8 4 4 0 286346500
> > 230360798 PO-B /opt/informix/IFMXDATA/datadbs
> >
> > and at the end of oncheck -pe I can see:
> > FREE 58091703
> > 228254797
> >
> > Total Used: 55985702
> > Total Free: 230360798
> >
> > Even with free space, and really far of getting my extent limit, I'm
> > getting this error. The last extent is a little smaller than what I
> > set in next extent size. I dont think i get out of contiguous space
> > because oncheck -pe shows that I have 230360798 pages free.
> >
> > Any help should be great.
> >
> > Thanks and regards
> >
> >
> > Emiliano Romero
> >
>
>
>
>
>
>
>
--00163641661d3d333704818b0918
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19316]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: frank@lafr.de (Frank Langelage) - Thu, 11 Mar 2010 13:56:03 EST
On 11.03.10 19:02, Emiliano Romero wrote:
> Hi list, I'm having a problem with my database. When I try to insert a
> row in my biggest table i get:
> 271: Could not insert new row into the table.
> 136: ISAM error: no more extents
>
> oncheck -pt shows:
>
> Physical Address 4:527
>
> Creation date 01/24/2010 13:19:43
>
> TBLspace Flags 802 Row Locking
>
> TBLspace use 4 bit bit-maps
>
> Maximum row size 24
>
> Number of special columns 0
>
> Number of keys 0
>
> Number of extents 7
>
> Current serial value 1
>
> Pagesize (k) 2
>
> First extent size 5000000
>
> Next extent size 750000
>
> Number of pages allocated 16777215
>
> Number of pages used 16777215
>
> Number of data pages 16773053
>
see
http://www-01.ibm.com/support/docview.wss?rs=630&context=SSGU8G&dc=DB560&dc=DB520&uid=swg21377993&loc=en_US&cs=UTF-8&lang=en&rss=ct630db2
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19315]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: eromero@sitrack.com (Emiliano Romero) - Thu, 11 Mar 2010 13:42:20 EST
My problem is that I reached the max number of pages, so the only
solution seems to be fragmentation.
Regards!
Emiliano Romero escribió:
> Hi list, I'm having a problem with my database. When I try to insert a
> row in my biggest table i get:
> 271: Could not insert new row into the table.
> 136: ISAM error: no more extents
>
> oncheck -pt shows:
> Physical Address 4:527
> Creation date 01/24/2010 13:19:43
> TBLspace Flags 802 Row Locking
> TBLspace use 4 bit bit-maps
> Maximum row size 24 Number of special
> columns 0 Number of keys 0
> Number of extents 7 Current serial
> value 1 Pagesize (k) 2
> First extent size 5000000 Next extent
> size 750000 Number of pages allocated 16777215
> Number of pages used 16777215 Number of data
> pages 16773053 Number of rows 1207659816
> Partition partnum 4194396 Partition
> lockid 4194396
> Extents Logical Page Physical
> Page Size Physical Pages
> 0 4:5095236 5750000 5750000
> 5750000 4:42968656 7500000 7500000
> 13250000 4:32405955 750000 750000
> 14000000 4:36380420 750000 750000
> 14750000 4:39023045 750000 750000
> 15500000 4:54801988 750000 750000
> 16250000 4:56145738 527215 527215
> Indexes are very similar 5-7 extents.
> onstat -d shows:
> IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
> days 16:37:13 -- 1684560 Kbytes
>
> Dbspaces
> address number flags fchunk nchunks pgsize
> flags owner name
> 8674ee78 1 0x40001 1 1 2048 N
> B informix rootdbs
> 879599e8 2 0x40001 2 1 2048 N
> B informix physdbs
> 87959b80 3 0x42001 3 1 2048 N
> TB informix tempdbs
> 87959d18 4 0x40001 4 1 2048 N
> B informix datadbs
> 4 active, 2047 maximum
>
> Chunks
> address chunk/dbs offset size free
> bpages flags pathname
> 8674f028 1 1 0 2560000
> 807158 PO-B /opt/informix/IFMXDATA/rootdbs
> 8674fd10 2 2 0 1000000
> 499947 PO-B /opt/informix/IFMXDATA/physdbs
> 87959028 3 3 0 1000000
> 995996 PO-B /opt/informix/IFMXDATA/tempdbs
> 879591c8 4 4 0 286346500
> 230360798 PO-B /opt/informix/IFMXDATA/datadbs
>
> and at the end of oncheck -pe I can see:
> FREE 58091703
> 228254797
>
> Total Used: 55985702
> Total Free: 230360798
>
> Even with free space, and really far of getting my extent limit, I'm
> getting this error. The last extent is a little smaller than what I
> set in next extent size. I dont think i get out of contiguous space
> because oncheck -pe shows that I have 230360798 pages free.
>
> Any help should be great.
>
> Thanks and regards
>
>
> Emiliano Romero
>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19314]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 136: ISAM error: no more extents even with....
Posted by: rroussey@comcast.net (rroussey@comcast.net) - Thu, 11 Mar 2010 13:34:22 EST
You've hit the max # of pages for IDS (32-bit?) for a table. That's all the
bitmap pages can keep track of. If you have IDS 10 or greater, you could
recreate the table in a new dbspace with 16k pages or another option is to
recreate the table as a fragmented table.
Bob
----- Original Message -----
From: "Emiliano Romero" <eromero@sitrack.com>
To: ids@iiug.org
Sent: Thursday, March 11, 2010 1:02:48 PM GMT -05:00 US/Canada Eastern
Subject: 136: ISAM error: no more extents even with 7 e.... [19312]
Hi list, I'm having a problem with my database. When I try to insert a
row in my biggest table i get:
271: Could not insert new row into the table.
136: ISAM error: no more extents
oncheck -pt shows:
Physical Address 4:527
Creation date 01/24/2010 13:19:43
TBLspace Flags 802 Row Locking
TBLspace use 4 bit bit-maps
Maximum row size 24
Number of special columns 0
Number of keys 0
Number of extents 7
Current serial value 1
Pagesize (k) 2
First extent size 5000000
Next extent size 750000
Number of pages allocated 16777215
Number of pages used 16777215
Number of data pages 16773053
Number of rows 1207659816
Partition partnum 4194396
Partition lockid 4194396
Extents
Logical Page Physical Page Size Physical Pages
0 4:5095236 5750000 5750000
5750000 4:42968656 7500000 7500000
13250000 4:32405955 750000 750000
14000000 4:36380420 750000 750000
14750000 4:39023045 750000 750000
15500000 4:54801988 750000 750000
16250000 4:56145738 527215 527215
Indexes are very similar 5-7 extents.
onstat -d shows:
IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
days 16:37:13 -- 1684560 Kbytes
Dbspaces
address number flags fchunk nchunks pgsize flags
owner name
8674ee78 1 0x40001 1 1 2048 N B
informix rootdbs
879599e8 2 0x40001 2 1 2048 N B
informix physdbs
87959b80 3 0x42001 3 1 2048 N TB
informix tempdbs
87959d18 4 0x40001 4 1 2048 N B
informix datadbs
4 active, 2047 maximum
Chunks
address chunk/dbs offset size free bpages
flags pathname
8674f028 1 1 0 2560000 807158
PO-B /opt/informix/IFMXDATA/rootdbs
8674fd10 2 2 0 1000000 499947
PO-B /opt/informix/IFMXDATA/physdbs
87959028 3 3 0 1000000 995996
PO-B /opt/informix/IFMXDATA/tempdbs
879591c8 4 4 0 286346500 230360798
PO-B /opt/informix/IFMXDATA/datadbs
and at the end of oncheck -pe I can see:
FREE 58091703
228254797
Total Used: 55985702
Total Free: 230360798
Even with free space, and really far of getting my extent limit, I'm
getting this error. The last extent is a little smaller than what I set
in next extent size. I dont think i get out of contiguous space because
oncheck -pe shows that I have 230360798 pages free.
Any help should be great.
Thanks and regards
Emiliano Romero
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19313]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
136: ISAM error: no more extents even with 7 e....
Posted by: eromero@sitrack.com (Emiliano Romero) - Thu, 11 Mar 2010 13:03:12 EST
Hi list, I'm having a problem with my database. When I try to insert a
row in my biggest table i get:
271: Could not insert new row into the table.
136: ISAM error: no more extents
oncheck -pt shows:
Physical Address 4:527
Creation date 01/24/2010 13:19:43
TBLspace Flags 802 Row Locking
TBLspace use 4 bit bit-maps
Maximum row size 24
Number of special columns 0
Number of keys 0
Number of extents 7
Current serial value 1
Pagesize (k) 2
First extent size 5000000
Next extent size 750000
Number of pages allocated 16777215
Number of pages used 16777215
Number of data pages 16773053
Number of rows 1207659816
Partition partnum 4194396
Partition lockid 4194396
Extents
Logical Page Physical Page Size Physical Pages
0 4:5095236 5750000 5750000
5750000 4:42968656 7500000 7500000
13250000 4:32405955 750000 750000
14000000 4:36380420 750000 750000
14750000 4:39023045 750000 750000
15500000 4:54801988 750000 750000
16250000 4:56145738 527215 527215
Indexes are very similar 5-7 extents.
onstat -d shows:
IBM Informix Dynamic Server Version 10.00.FC6 -- On-Line -- Up 44
days 16:37:13 -- 1684560 Kbytes
Dbspaces
address number flags fchunk nchunks pgsize flags
owner name
8674ee78 1 0x40001 1 1 2048 N B
informix rootdbs
879599e8 2 0x40001 2 1 2048 N B
informix physdbs
87959b80 3 0x42001 3 1 2048 N TB
informix tempdbs
87959d18 4 0x40001 4 1 2048 N B
informix datadbs
4 active, 2047 maximum
Chunks
address chunk/dbs offset size free bpages
flags pathname
8674f028 1 1 0 2560000 807158
PO-B /opt/informix/IFMXDATA/rootdbs
8674fd10 2 2 0 1000000 499947
PO-B /opt/informix/IFMXDATA/physdbs
87959028 3 3 0 1000000 995996
PO-B /opt/informix/IFMXDATA/tempdbs
879591c8 4 4 0 286346500 230360798
PO-B /opt/informix/IFMXDATA/datadbs
and at the end of oncheck -pe I can see:
FREE 58091703
228254797
Total Used: 55985702
Total Free: 230360798
Even with free space, and really far of getting my extent limit, I'm
getting this error. The last extent is a little smaller than what I set
in next extent size. I dont think i get out of contiguous space because
oncheck -pe shows that I have 230360798 pages free.
Any help should be great.
Thanks and regards
Emiliano Romero
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19312]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RE: 4GL run-time error number -4339
Posted by: lsorensen25@msn.com (LARRY SORENSEN) - Thu, 11 Mar 2010 12:26:55 EST
I am checking on the flow of the program, but in the meantime, the same
program was working on our previous server before the migration. Which
configuration parameters, whether Informix or kernel, should I be looking at
to possibly fix this problem.
Thanks
> To: ids@iiug.org
> From: art.kagel@gmail.com
> Subject: Re: 4GL run-time error number -4339 [19309]
> Date: Wed, 10 Mar 2010 19:48:54 -0500
>
> Jonathan's point is this:
>
> - When you fork a child process, whether the parent process is written in
>
> C, C4GL, R4GL (ie run by the 4Gl p-machine), or Java (ie is run by the JRE)
>
> the child inherits shared memory, network connections, and file handles from
>
> its parent.
>
> - If you did not disconnect the child process or thread from the parent's
>
> connection to the database before execing the new process the new process is
>
> using the parent's connection and the two processes may be interfering with
>
> each other. IDS does not expect to be receiving instructions from two
>
> processes on a single connection.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (art@iiug.org)
>
> See you at the 2010 IIUG Informix Conference
> April 25-28, 2010
> Overland Park (Kansas City), KS
> www.iiug.org/conf
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions and
> do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
> organization with which I am associated either explicitly, implicitly, or by
> inference. Neither do those opinions reflect those of other individuals
> affiliated with any entity with which I am affiliated nor those of the
> entities themselves.
>
> On Wed, Mar 10, 2010 at 4:53 PM, LARRY SORENSEN <lsorensen25@msn.com> wrote:
>
> > The load is handled by a separate process; each record is entered by a
> > program
> > one at a time and committed each time. Once the claim is in, the Traffic
> > Cop
> > moves the record along a series of Java programs; it is the final step in
> > the
> > services that spawns out the thread to a 4ge program.
> >
> > The 4ge program reads data from the Informix database and creates a 4GL
> > report
> > (that is later printed and sent out. It updates one record in the one
table
> > which indicates that the report has been completed and saves a compressed
> > copy
> > of the report to the another table.
> >
> > Each set of programs handles one record at a time and begins and commits
> > work
> > as appropriate. I believe that the problem arises when the process that
> > calls
> > the 4ge program continues on to the next record while the 4ge is still
> > running. As a result we get a situation where multiple 4ge threads are
> > running
> > for different record reports and a wall might be hit; I don't know if the
> > wall
> > relates to just the Shared Memory limits or if it has to do with the
number
> > of
> > open files being written to or some other limiting factor but once that
> > wall
> > is hit no more reports are created for a while. Then "magically" the
> > reports
> > start up again until the wall is again hit. So when you look at the first
> > record table you see a number of entries where the record_id is set
> > (indicating the report was created and saved to the correct table). Then
> > there
> > will be a series of records that don't have a record_id, then some with
> > record_ids, and so one. So it appears that the original process continues
> > to
> > spawn out the threads but they are killed during or just before the 4ge
> > program is run.
> >
> > Any clearer? I know that was involved. I tried to leave it a little
generic
> > on
> > purpose leaving off program and table names.
> >
> > > To: ids@iiug.org
> > > From: jleffler.iiug@gmail.com
> > > Subject: Re: 4GL run-time error number -4339 [19304]
> > > Date: Wed, 10 Mar 2010 16:20:03 -0500
> > >
> > > On Wed, Mar 10, 2010 at 09:49, LARRY SORENSEN <lsorensen25@msn.com>
> > wrote:
> > >
> > > > Another bit of information -
> > > >
> > > > The 4gl program inserts data into tables and calls and forks off a
call
> > to
> > > > another program that does further processing. It is usually quick, but
> > if
> > > > the
> > > > data is too large, there may be a number of forked processes out
there.
> > > > First,
> > > > could this result in the error message, and second, what parameters
> > might
> > I
> > > > need to adjust to overcome this limitation?
> > > >
> > >
> > > What form does the 'further processing' take?
> > >
> > > Specifically, does the forked process try to use the database?
> > >
> > > If so, you are going to have problems; connections are not for sharing
> > > between processes, and if you have two processes trying to use 'the same
> > > connection' then you run into problems which could easily include the
> > error
> > > you are seeing.
> > >
> > > > Larry
> > > >
> > > > > To: ids@iiug.org
> > > > > From: lsorensen25@msn.com
> > > > > Subject: RE: 4GL run-time error number -4339 [19299]
> > > > > Date: Wed, 10 Mar 2010 11:54:47 -0500
> > > > >
> > > > > This is code that has been compiled. It ran just fine on the Solaris
> > 5.6,
> > > > IDS
> > > > > 7.32 platform before we migrated. Apparently, parameters, etc. were
> > set
> > > > > corrrectly and somehow missed during the migration. Now I am looking
> > for
> > > > > something to tweak so that it will run as it did before the
> > migration.
> > > > >
> > > > > Larry
> > > > >
> > > > > > To: ids@iiug.org
> > > > > > From: art.kagel@gmail.com
> > > > > > Subject: Re: 4GL run-time error number -4339 [19298]
> > > > > > Date: Wed, 10 Mar 2010 08:42:24 -0500
> > > > > >
> > > > > > There are suggestions in the output from "finderr -4339" for how
to
> > > > help
> > > > > > resolve this problem. I also would look though at the code for
this
> > > > module
> > > > > > to see if there are statements, forms, windows, etc. that have
been
> > > > opened
> > > > > > and are no longer needed but have not been closed and freed.
> > > > > >
> > > > > > Is this Compiled 4GL (C4GL) or pcode 4GL (R4GL)?
> > > > > >
> > > >
> > > >
> > >
> > > > > >
> > > > > > On Tue, Mar 9, 2010 at 10:26 AM, LARRY SORENSEN <
> > lsorensen25@msn.com>
> > > > wrote:
> > > > > >
> > > > > > > I am running on Solaris 5.10 and IDs 11.50. I have I4GL 7.32
> > > > > > >
> > > > > > > I would like some direction on what parameters that can be
> > changed
> > to
> > > > > > > alleviate this problem. There is plenty of memory on the server.
> > I
> > am
> > > > > > > currently checking into what program changes may have taken
> > place,
> > > > but I
> > > > > > > need
> > > > > > > direction in the mean time.
> > > > > > >
> > > > > > > Error
> > > > > > >
> > > > > > > Program error at "eob.4gl", line number 192.
> > > > > > > SQL statement error number -406. --- Similar -406 errors are
> > reported
> > > > > after
> > > > > > > this one in different lines of the application.
> > > > > > > Memory allocation failed.Date: Time: 22:36:55Date: Time:
22:36:55
> > --
> > > > at
> > > > > > > this
> > > > > > > point the errors start getting jumbled
> > > > > > > Program error at "eob.4gl", line number 192 Program error at
> > > > "eob.4gl",
> > > > > > > line
> > > > > > > number 192.
> > > > > > > SQL statement er.
> > > > > > > ror number -406.SQL statement error number -406.
> > > > > > > Memory allocation failed.
> > > > > > >
> > > > > > > Date: Time: 22:37:03
> > > > > > > 4GL run-time error number -4339.
> > > > > > > 4GL has run out of data space memory.
> > > > > > > Date: Time: 22:37:05
> > > > > > > 4GL run-time error number -4339.
> > > > > > > 4GL has run out of data space memory.
> > > >
> > >
> > > --
> > > Jonathan Leffler #include <disclaimer.h>
> > > Email: jleffler@earthlink.net, jleffler@us.ibm.com
> > > Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
> > > "Blessed are we who can laugh at ourselves, for we shall never cease to
> > be
> > > amused."
> > > NB: Please do not use this email for correspondence.
> > > I don't necessarily read it every week, even.
> > >
> > > --001636b2b0304f2adb048178dc13
> > >
> > >
> > >
> >
> >
>
> > >
> > >
> >
> >
> >
> >
>
> >
> >
> >
>
> --0015174c0f3e3eaff104817a5015
>
>
>
>
>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19311]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
IDS V11.50FC6 and Compression
Posted by: rick.hill@barclaycard.co.uk (RICK HILL) - Thu, 11 Mar 2010 02:58:56 EST
Hi All,
I am just looking at the possibility of using IDS compression.
I just wanted to know if anyone has experience with this and what your
feelings are.
Also i have a table that has 800+ million rows, so far it has taken about 10
hours and it is still not finished...
I expect it would be quicker to unload the table, set compression on and
reload, but will have to test this as well.
The main issue i am facing is that compressing a table is very very log
intensive, our TSM server can not keep up with the logs being filled.
For now i have turned this off and the logs backup to /dev/null, but for
obvious reasons this can not be done in a production environment.
Has anyone encountered this and if so did you manage to get around it.
Any information around this would be really appreciated.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19310]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 4GL run-time error number -4339
Posted by: art.kagel@gmail.com (Art Kagel) - Wed, 10 Mar 2010 19:49:00 EST
Jonathan's point is this:
- When you fork a child process, whether the parent process is written in
C, C4GL, R4GL (ie run by the 4Gl p-machine), or Java (ie is run by the JRE)
the child inherits shared memory, network connections, and file handles from
its parent.
- If you did not disconnect the child process or thread from the parent's
connection to the database before execing the new process the new process is
using the parent's connection and the two processes may be interfering with
each other. IDS does not expect to be receiving instructions from two
processes on a single connection.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Wed, Mar 10, 2010 at 4:53 PM, LARRY SORENSEN <lsorensen25@msn.com> wrote:
> The load is handled by a separate process; each record is entered by a
> program
> one at a time and committed each time. Once the claim is in, the Traffic
> Cop
> moves the record along a series of Java programs; it is the final step in
> the
> services that spawns out the thread to a 4ge program.
>
> The 4ge program reads data from the Informix database and creates a 4GL
> report
> (that is later printed and sent out. It updates one record in the one table
> which indicates that the report has been completed and saves a compressed
> copy
> of the report to the another table.
>
> Each set of programs handles one record at a time and begins and commits
> work
> as appropriate. I believe that the problem arises when the process that
> calls
> the 4ge program continues on to the next record while the 4ge is still
> running. As a result we get a situation where multiple 4ge threads are
> running
> for different record reports and a wall might be hit; I don't know if the
> wall
> relates to just the Shared Memory limits or if it has to do with the number
> of
> open files being written to or some other limiting factor but once that
> wall
> is hit no more reports are created for a while. Then "magically" the
> reports
> start up again until the wall is again hit. So when you look at the first
> record table you see a number of entries where the record_id is set
> (indicating the report was created and saved to the correct table). Then
> there
> will be a series of records that don't have a record_id, then some with
> record_ids, and so one. So it appears that the original process continues
> to
> spawn out the threads but they are killed during or just before the 4ge
> program is run.
>
> Any clearer? I know that was involved. I tried to leave it a little generic
> on
> purpose leaving off program and table names.
>
> > To: ids@iiug.org
> > From: jleffler.iiug@gmail.com
> > Subject: Re: 4GL run-time error number -4339 [19304]
> > Date: Wed, 10 Mar 2010 16:20:03 -0500
> >
> > On Wed, Mar 10, 2010 at 09:49, LARRY SORENSEN <lsorensen25@msn.com>
> wrote:
> >
> > > Another bit of information -
> > >
> > > The 4gl program inserts data into tables and calls and forks off a call
> to
> > > another program that does further processing. It is usually quick, but
> if
> > > the
> > > data is too large, there may be a number of forked processes out there.
> > > First,
> > > could this result in the error message, and second, what parameters
> might
> I
> > > need to adjust to overcome this limitation?
> > >
> >
> > What form does the 'further processing' take?
> >
> > Specifically, does the forked process try to use the database?
> >
> > If so, you are going to have problems; connections are not for sharing
> > between processes, and if you have two processes trying to use 'the same
> > connection' then you run into problems which could easily include the
> error
> > you are seeing.
> >
> > > Larry
> > >
> > > > To: ids@iiug.org
> > > > From: lsorensen25@msn.com
> > > > Subject: RE: 4GL run-time error number -4339 [19299]
> > > > Date: Wed, 10 Mar 2010 11:54:47 -0500
> > > >
> > > > This is code that has been compiled. It ran just fine on the Solaris
> 5.6,
> > > IDS
> > > > 7.32 platform before we migrated. Apparently, parameters, etc. were
> set
> > > > corrrectly and somehow missed during the migration. Now I am looking
> for
> > > > something to tweak so that it will run as it did before the
> migration.
> > > >
> > > > Larry
> > > >
> > > > > To: ids@iiug.org
> > > > > From: art.kagel@gmail.com
> > > > > Subject: Re: 4GL run-time error number -4339 [19298]
> > > > > Date: Wed, 10 Mar 2010 08:42:24 -0500
> > > > >
> > > > > There are suggestions in the output from "finderr -4339" for how to
> > > help
> > > > > resolve this problem. I also would look though at the code for this
> > > module
> > > > > to see if there are statements, forms, windows, etc. that have been
> > > opened
> > > > > and are no longer needed but have not been closed and freed.
> > > > >
> > > > > Is this Compiled 4GL (C4GL) or pcode 4GL (R4GL)?
> > > > >
> > >
> > >
> >
> > > > >
> > > > > On Tue, Mar 9, 2010 at 10:26 AM, LARRY SORENSEN <
> lsorensen25@msn.com>
> > > wrote:
> > > > >
> > > > > > I am running on Solaris 5.10 and IDs 11.50. I have I4GL 7.32
> > > > > >
> > > > > > I would like some direction on what parameters that can be
> changed
> to
> > > > > > alleviate this problem. There is plenty of memory on the server.
> I
> am
> > > > > > currently checking into what program changes may have taken
> place,
> > > but I
> > > > > > need
> > > > > > direction in the mean time.
> > > > > >
> > > > > > Error
> > > > > >
> > > > > > Program error at "eob.4gl", line number 192.
> > > > > > SQL statement error number -406. --- Similar -406 errors are
> reported
> > > > after
> > > > > > this one in different lines of the application.
> > > > > > Memory allocation failed.Date: Time: 22:36:55Date: Time: 22:36:55
> --
> > > at
> > > > > > this
> > > > > > point the errors start getting jumbled
> > > > > > Program error at "eob.4gl", line number 192 Program error at
> > > "eob.4gl",
> > > > > > line
> > > > > > number 192.
> > > > > > SQL statement er.
> > > > > > ror number -406.SQL statement error number -406.
> > > > > > Memory allocation failed.
> > > > > >
> > > > > > Date: Time: 22:37:03
> > > > > > 4GL run-time error number -4339.
> > > > > > 4GL has run out of data space memory.
> > > > > > Date: Time: 22:37:05
> > > > > > 4GL run-time error number -4339.
> > > > > > 4GL has run out of data space memory.
> > >
> >
> > --
> > Jonathan Leffler #include <disclaimer.h>
> > Email: jleffler@earthlink.net, jleffler@us.ibm.com
> > Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
> > "Blessed are we who can laugh at ourselves, for we shall never cease to
> be
> > amused."
> > NB: Please do not use this email for correspondence.
> > I don't necessarily read it every week, even.
> >
> > --001636b2b0304f2adb048178dc13
> >
> >
> >
>
>
> >
> >
>
>
>
>
>
>
>
--0015174c0f3e3eaff104817a5015
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19309]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: 4GL run-time error number -4339
Posted by: art.kagel@gmail.com (Art Kagel) - Wed, 10 Mar 2010 17:47:41 EST
Maybe the comment about recursion isn't so off base or my suggestion that
there are things being allocated but not freed later.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Wed, Mar 10, 2010 at 3:59 PM, LARRY SORENSEN <lsorensen25@msn.com> wrote:
> Yes, everything has been recompiled. We moved from Solary 5.6 32-bit to
> Solaris 5.10 64-bit along with the latest versions of IDS and 4gl. The
> program
> works under normal workloads 3 days per week. On the other 2 heavier days
> with
> more entries, the program fails with the below listed message.
>
> Larry
>
> > To: ids@iiug.org
> > From: art.kagel@gmail.com
> > Subject: Re: 4GL run-time error number -4339 [19301]
> > Date: Wed, 10 Mar 2010 13:54:45 -0500
> >
> > Have you recompiled the code under Solaris 10? The shared libraries are
> > likely changed enough to cause some problems without crashing your apps.
> A
> > recompile using the new libraries may help.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > IIUG Board of Directors (art@iiug.org)
> >
> > See you at the 2010 IIUG Informix Conference
> > April 25-28, 2010
> > Overland Park (Kansas City), KS
> > www.iiug.org/conf
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> other
> > organization with which I am associated either explicitly, implicitly, or
> by
> > inference. Neither do those opinions reflect those of other individuals
> > affiliated with any entity with which I am affiliated nor those of the
> > entities themselves.
> >
> > On Wed, Mar 10, 2010 at 11:54 AM, LARRY SORENSEN <lsorensen25@msn.com
> >wrote:
> >
> > > This is code that has been compiled. It ran just fine on the Solaris
> 5.6,
> > > IDS
> > > 7.32 platform before we migrated. Apparently, parameters, etc. were set
> > > corrrectly and somehow missed during the migration. Now I am looking
> for
> > > something to tweak so that it will run as it did before the migration.
> > >
> > > Larry
> > >
> > > > To: ids@iiug.org
> > > > From: art.kagel@gmail.com
> > > > Subject: Re: 4GL run-time error number -4339 [19298]
> > > > Date: Wed, 10 Mar 2010 08:42:24 -0500
> > > >
> > > > There are suggestions in the output from "finderr -4339" for how to
> help
> > > > resolve this problem. I also would look though at the code for this
> > > module
> > > > to see if there are statements, forms, windows, etc. that have been
> > > opened
> > > > and are no longer needed but have not been closed and freed.
> > > >
> > > > Is this Compiled 4GL (C4GL) or pcode 4GL (R4GL)?
> > > >
> > > > Art
> > > >
> > > > Art S. Kagel
> > > > Advanced DataTools (www.advancedatatools.com)
> > > > IIUG Board of Directors (art@iiug.org)
> > > >
> > > > See you at the 2010 IIUG Informix Conference
> > > > April 25-28, 2010
> > > > Overland Park (Kansas City), KS
> > > > www.iiug.org/conf
> > > >
> > > > Disclaimer: Please keep in mind that my own opinions are my own
> opinions
> > > and
> > > > do not reflect on my employer, Advanced DataTools, the IIUG, nor any
> > > other
> > > > organization with which I am associated either explicitly,
> implicitly,
> or
> > > by
> > > > inference. Neither do those opinions reflect those of other
> individuals
> > > > affiliated with any entity with which I am affiliated nor those of
> the
> > > > entities themselves.
> > > >
> > > > On Tue, Mar 9, 2010 at 10:26 AM, LARRY SORENSEN <lsorensen25@msn.com
> >
> > > wrote:
> > > >
> > > > > I am running on Solaris 5.10 and IDs 11.50. I have I4GL 7.32
> > > > >
> > > > > I would like some direction on what parameters that can be changed
> to
> > > > > alleviate this problem. There is plenty of memory on the server. I
> am
> > > > > currently checking into what program changes may have taken place,
> but
> > > I
> > > > > need
> > > > > direction in the mean time.
> > > > >
> > > > > Error
> > > > >
> > > > > Program error at "eob.4gl", line number 192.
> > > > > SQL statement error number -406. --- Similar -406 errors are
> reported
> > > after
> > > > > this one in different lines of the application.
> > > > > Memory allocation failed.Date: Time: 22:36:55Date: Time: 22:36:55
> --
> at
> > > > > this
> > > > > point the errors start getting jumbled
> > > > > Program error at "eob.4gl", line number 192 Program error at
> "eob.4gl",
> > > > > line
> > > > > number 192.
> > > > > SQL statement er.
> > > > > ror number -406.SQL statement error number -406.
> > > > > Memory allocation failed.
> > > > >
> > > > > Date: Time: 22:37:03
> > > > > 4GL run-time error number -4339.
> > > > > 4GL has run out of data space memory.
> > > > > Date: Time: 22:37:05
> > > > > 4GL run-time error number -4339.
> > > > > 4GL has run out of data space memory.
> > > > >
> > > > > Larry
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
> > > > >
> > > > >
> > > > >
> > > >
> > > > --000e0cd1ff3e909bc004817277c4
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
> > >
> > >
> > >
> >
> > --0015174027a6542b41048176d465
> >
> >
> >
>
>
> >
> >
>
>
>
>
>
>
>
--0015174754aa4c3fa304817a15f9
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19308]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: dbload and load
Posted by: art.kagel@gmail.com (Art Kagel) - Wed, 10 Mar 2010 17:35:41 EST
It would be interesting to see how fast my dbcopy utility can transfer the
data from the external table to the real one. Like dbload it uses partial
transactions and big buffers so it is lightening fast on normal tables and
uses as few locks as you configure it to (10,000 by default).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Wed, Mar 10, 2010 at 2:18 PM, Plugge, Joe R. <JRPlugge@west.com> wrote:
> John, your method as described below chews up a ton of row locks, I had to
> alter my base table type(raw) and then issue the insert statement. Am I
> missing something?
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John
> Miller iii
> Sent: Tuesday, March 09, 2010 1:44 PM
> To: ids@iiug.org
> Subject: Re: dbload and load [19290]
>
> Frank:
>
> I am not sure if you are aware but in version 11.50.xC6
> there was a new loading mechanism that I find very easy
> to use, which I believe is faster than both dbload and load.
> It is called external tables and to do the load you simple
> do the following.
>
> In addition, you can combine the external table feature and the newly
> add MERGE statement to insert new rows and update existing
> rows (or various combinations).
>
> CREATE EXTERNAL TABLE t1_ext SAMEAS t1
> USING
> (
> DATAFILES('DISK:/tmp/t1.unl'),
> FORMAT 'DELIMITED',
> DELIMITER '|',
> RECORDEND '',
> Deluxe,
> NUMROWS 50,
> MAXERRORS 50,
> REJECTFILE ''
> );
>
> INSERT INTO t1 SELECT * FROM t1_ext;
> DROP TABLE t1_ext;
>
> John F. Miller III
> STSM, Support Architect
> miller3@us.ibm.com
> 503-578-5645
> IBM Informix Dynamic Server (IDS)
>
> ids-bounces@iiug.org wrote on 03/09/2010 10:40:31 AM:
>
> > [image removed]
> >
> > Re: dbload and load [19289]
> >
> > FRANK
> >
> > to:
> >
> > ids
> >
> > 03/09/2010 10:42 AM
> >
> > Sent by:
> >
> > ids-bounces@iiug.org
> >
> > Please respond to ids
> >
> > Another interesting result observation I like to share.
> >
> > For a regular table and default configuration, We just change the number
> > of rows to be committed( a parameter of dbload) You can see the total
> > loading time changing. It is a curve. You may find the Point there.
> >
> > Rows Time
> > =================================
> > 5 rows 46 minutes 31 seconds
> > 20 rows 26 minutes 7 seconds
> > 40 row 23 minutes 15 seconds
> > 100 rows 24 minutes 11 seconds
> > 300 rows 22 minutes 53 seconds
> > 650 rows 22 minutes 44 seconds
> > 1250 rows 22 minutes 33 seconds
> > 2500 rows 22 minutes 46 seconds
> > 5000 rows 21 minutes 16 seconds
> > 10000 rows 20 minutes 15 seconds
> > 25000 rows 19 minutes 28 seconds
> > 50000 rows 20 minutes 16 seconds
> > 75000 rows 20 minutes 33 seconds
> > 100000 rows 20 minutes 18 seconds
> > 200000 rows 22 minutes 14 seconds
> > 400000 rows 28 minutes 34 seconds
> > 800000 rows 29 minutes 3 seconds
> > 1600000 rows 39 minutes 35 seconds
> >
> > Want to know what Fast Informix DBAs like to do?
> >
> > Frank
> >
> > On Tue, Mar 9, 2010 at 7:27 AM, Obnoxio The Clown
> > <obnoxio@serendipita.com>wrote:
> >
> > > CHUAN LU wrote:
> > > > Hello,
> > > >
> > > > when a parnter loading a whole file into the table, they find the
> > > performance
> > > > of dbload is better than SQL load, who know the internal reason? Any
> > > reply
> > > > will be appreciated.
> > >
> > > If you are committing dbload every couple of thousand rows, the
> > > transaction logging is much more efficient. SQL LOAD doesn't offer the
> > > option. You probably won't see it on small tables.
> > >
> > > --
> > > Cheers,
> > > Obnoxio The Clown
> > >
> > > http://obotheclown.blogspot.com
> > > I will now proceed to pleasure myself with this fish.
> > >
> > > --
> > > This message has been scanned for viruses and
> > > dangerous content by OpenProtect(http://www.openprotect.com), and is
> > > believed to be clean.
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
> > >
> > >
> > >
> >
> > --0016e6407c9ee4b01a048162838c
> >
> >
> >
>
>
>
>
>
> >
> >
>
>
>
>
>
>
>
>
>
>
>
>
--0015174027a627a64d048179ea6d
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19307]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RE: 4GL run-time error number -4339
Posted by: lsorensen25@msn.com (LARRY SORENSEN) - Wed, 10 Mar 2010 16:53:36 EST
The load is handled by a separate process; each record is entered by a program
one at a time and committed each time. Once the claim is in, the Traffic Cop
moves the record along a series of Java programs; it is the final step in the
services that spawns out the thread to a 4ge program.
The 4ge program reads data from the Informix database and creates a 4GL report
(that is later printed and sent out. It updates one record in the one table
which indicates that the report has been completed and saves a compressed copy
of the report to the another table.
Each set of programs handles one record at a time and begins and commits work
as appropriate. I believe that the problem arises when the process that calls
the 4ge program continues on to the next record while the 4ge is still
running. As a result we get a situation where multiple 4ge threads are running
for different record reports and a wall might be hit; I don't know if the wall
relates to just the Shared Memory limits or if it has to do with the number of
open files being written to or some other limiting factor but once that wall
is hit no more reports are created for a while. Then "magically" the reports
start up again until the wall is again hit. So when you look at the first
record table you see a number of entries where the record_id is set
(indicating the report was created and saved to the correct table). Then there
will be a series of records that don't have a record_id, then some with
record_ids, and so one. So it appears that the original process continues to
spawn out the threads but they are killed during or just before the 4ge
program is run.
Any clearer? I know that was involved. I tried to leave it a little generic on
purpose leaving off program and table names.
> To: ids@iiug.org
> From: jleffler.iiug@gmail.com
> Subject: Re: 4GL run-time error number -4339 [19304]
> Date: Wed, 10 Mar 2010 16:20:03 -0500
>
> On Wed, Mar 10, 2010 at 09:49, LARRY SORENSEN <lsorensen25@msn.com> wrote:
>
> > Another bit of information -
> >
> > The 4gl program inserts data into tables and calls and forks off a call to
> > another program that does further processing. It is usually quick, but if
> > the
> > data is too large, there may be a number of forked processes out there.
> > First,
> > could this result in the error message, and second, what parameters might
I
> > need to adjust to overcome this limitation?
> >
>
> What form does the 'further processing' take?
>
> Specifically, does the forked process try to use the database?
>
> If so, you are going to have problems; connections are not for sharing
> between processes, and if you have two processes trying to use 'the same
> connection' then you run into problems which could easily include the error
> you are seeing.
>
> > Larry
> >
> > > To: ids@iiug.org
> > > From: lsorensen25@msn.com
> > > Subject: RE: 4GL run-time error number -4339 [19299]
> > > Date: Wed, 10 Mar 2010 11:54:47 -0500
> > >
> > > This is code that has been compiled. It ran just fine on the Solaris
5.6,
> > IDS
> > > 7.32 platform before we migrated. Apparently, parameters, etc. were set
> > > corrrectly and somehow missed during the migration. Now I am looking for
> > > something to tweak so that it will run as it did before the migration.
> > >
> > > Larry
> > >
> > > > To: ids@iiug.org
> > > > From: art.kagel@gmail.com
> > > > Subject: Re: 4GL run-time error number -4339 [19298]
> > > > Date: Wed, 10 Mar 2010 08:42:24 -0500
> > > >
> > > > There are suggestions in the output from "finderr -4339" for how to
> > help
> > > > resolve this problem. I also would look though at the code for this
> > module
> > > > to see if there are statements, forms, windows, etc. that have been
> > opened
> > > > and are no longer needed but have not been closed and freed.
> > > >
> > > > Is this Compiled 4GL (C4GL) or pcode 4GL (R4GL)?
> > > >
> >
> >
>
> > > >
> > > > On Tue, Mar 9, 2010 at 10:26 AM, LARRY SORENSEN <lsorensen25@msn.com>
> > wrote:
> > > >
> > > > > I am running on Solaris 5.10 and IDs 11.50. I have I4GL 7.32
> > > > >
> > > > > I would like some direction on what parameters that can be changed
to
> > > > > alleviate this problem. There is plenty of memory on the server. I
am
> > > > > currently checking into what program changes may have taken place,
> > but I
> > > > > need
> > > > > direction in the mean time.
> > > > >
> > > > > Error
> > > > >
> > > > > Program error at "eob.4gl", line number 192.
> > > > > SQL statement error number -406. --- Similar -406 errors are
reported
> > > after
> > > > > this one in different lines of the application.
> > > > > Memory allocation failed.Date: Time: 22:36:55Date: Time: 22:36:55 --
> > at
> > > > > this
> > > > > point the errors start getting jumbled
> > > > > Program error at "eob.4gl", line number 192 Program error at
> > "eob.4gl",
> > > > > line
> > > > > number 192.
> > > > > SQL statement er.
> > > > > ror number -406.SQL statement error number -406.
> > > > > Memory allocation failed.
> > > > >
> > > > > Date: Time: 22:37:03
> > > > > 4GL run-time error number -4339.
> > > > > 4GL has run out of data space memory.
> > > > > Date: Time: 22:37:05
> > > > > 4GL run-time error number -4339.
> > > > > 4GL has run out of data space memory.
> >
>
> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
> "Blessed are we who can laugh at ourselves, for we shall never cease to be
> amused."
> NB: Please do not use this email for correspondence.
> I don't necessarily read it every week, even.
>
> --001636b2b0304f2adb048178dc13
>
>
>
>
>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19306]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: ulimit setting
Posted by: jleffler.iiug@gmail.com (Jonathan Leffler) - Wed, 10 Mar 2010 16:24:39 EST
I've not seen any answer to this...
On Tue, Feb 23, 2010 at 15:57, ALI SHAHNAZI <ali@datasync.com.au> wrote:
>
> I had an IDS 11.5 FC4 on AIX6100 and following setting for 'informix' user,
> Please let me know your comments about these setting especially about
> memory
> setting.Is this setting ideal for IDS?
>
> ctp001:/infx> ulimit -a
>
> time(seconds) unlimited
> file(blocks) unlimited
> data(kbytes) 131072
> stack(kbytes) 32768
> memory(kbytes) 32768
> coredump(blocks) 2097151
> nofiles(descriptors) 2000
> threads(per process) unlimited
> processes(per user) unlimited
>
I would wonder about the data and memory sizes - they may be too small for
comfort.
For IDS itself (oninit), there is probably not an issue; it runs with root
privileges and can exceed those limits if it needs to. For less privileged
programs, there might be problems connecting to shared memory. It is
unlikely that other programs would run into issues with the number of file
descriptors.
It can also be relevant to distinguish between the soft limits (shown) and
the hard limits (ulimit -a -H, usually).
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
NB: Please do not use this email for correspondence.
I don't necessarily read it every week, even.
--000e0cd113b41a6c8d048178ec89
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19305]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
I've not seen any answer to this...
On Tue, Feb 23, 2010 at 15:57, ALI SHAHNAZI <ali@datasync.com.au> wrote:
>
> I had an IDS 11.5 FC4 on AIX6100 and following setting for 'informix' user,
> Please let me know your comments about these setting especially about
> memory
> setting.Is this setting ideal for IDS?
>
> ctp001:/infx> ulimit -a
>
> time(seconds) unlimited
> file(blocks) unlimited
> data(kbytes) 131072
> stack(kbytes) 32768
> memory(kbytes) 32768
> coredump(blocks) 2097151
> nofiles(descriptors) 2000
> threads(per process) unlimited
> processes(per user) unlimited
>
I would wonder about the data and memory sizes - they may be too small for
comfort.
For IDS itself (oninit), there is probably not an issue; it runs with root
privileges and can exceed those limits if it needs to. For less privileged
programs, there might be problems connecting to shared memory. It is
unlikely that other programs would run into issues with the number of file
descriptors.
It can also be relevant to distinguish between the soft limits (shown) and
the hard limits (ulimit -a -H, usually).
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
NB: Please do not use this email for correspondence.
I don't necessarily read it every week, even.
--000e0cd113b41a6c8d048178ec89
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
To post a response via email (IIUG members only):
1. Address it to ids@iiug.org
2. Include the bracketed message number in the subject line: [19305]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
|
|
|
Subscribe to this feed
|
| You can subscribe to this RSS feed in a number of ways, including the following:
Drag the orange RSS button into your News Reader
Drag the URL of the RSS feed into your News Reader
Cut and paste the URL of the RSS feed into your News Reader
v
|
|
