err 566/ ISAM 116 - any clues?
A 4GL program on IDS 9.30 / HP-UX11i intermittently failed with error -566 (cannot initiate sort) plus ISAM -116 (cannot allocate memory) when entering a FOREACH that inserted into a temp table; the code had worked for years, nothing appeared in online.log or OS logs, and a restart cured it. Keith Simmons suggested checking 'onstat -g seg' against the configured virtual memory limits and looking for another session hogging memory or filling temp dbspaces. That revealed ~80 memory segments with a burst of allocations that morning, i.e. the server had exhausted/overextended its shared memory — so the cause was identified, though the poster still had to track down which process was responsible.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi guys
HP-UX11i; IDS9.30HC5; i4GL 7.20UD8 (I know they're old but we're
working on it.... )
Just had this pair of errors (finderr output and the 4gl context
below).
There have been no OS errors reported, temp space was very little used
at the time and there are no messages in online.log. This bit of code
has been running fine for years and has never done this before.
Anyone had this before or can cast light? We've restarted the process
and it's deleriously happy again!
-566 Cannot initiate sort.
This internal error reflects an unexpected condition during a sort.
Check the accompanying ISAM error code for more information. If the
error recurs, please note all circumstances and contact Informix
Technical Support.
-116 ISAM error: cannot allocate memory.
The ISAM processor needed to allocate memory for data storage but was
unable to do so. A problem may exist in the operating system; look for
operating-system error messages that might give more information. One
cause of this error might be selecting a row that contains large BYTE
or TEXT columns into a temporary table or as part of an INSERT or
UPDATE. In some releases, an entire row that includes BLOB values is
buffered in memory. For C-ISAM programs, review the program to look for
ways that it can use less memory. For SQL products, simplify the
program, form, or report if possible.
4GL snippet: (The cursor is on a simple SELECT with fields that match
the temp table definition with no casting, functions etc). It failed on
the entry to the FOREACH.
CREATE TEMP TABLE jobs_togo (
time_to_start DATETIME YEAR TO SECOND,
jobreq_id_ref INTEGER,
jobdef_id_ref INTEGER,
jobs_type CHAR( 1 ),
job_priority SMALLINT,
allow_multp_yn CHAR(1),
lastupd_user CHAR(14)
)
LET li_current = CURRENT
FOREACH cr_jobs USING li_current INTO lr_rep_data.*, lc_user_name
INSERT INTO jobs_togo VALUES ( lr_rep_data.time_to_start,
lr_rep_data.jobreq_id_ref,
lr_rep_data.jobdef_id_ref,
lr_rep_data.jobs_type,
lr_rep_data.job_priority,
lr_rep_data.allow_multp_yn,
lc_user_name )
END FOREACH
Malc
onstat -g segHow much memory assigned, how much total virt memory permitted by
onconfig file? Was someone else doing a large sort at the time which
hogged memory? Do you have tempory dbspaces for sort files? Were these
full with other temp table at the time?
Keith
On 13 Oct 2006 04:43:33 -0700, malc_p@btinternet.com
<malc_p@btinternet.com> wrote:
> Hi guys
> HP-UX11i; IDS9.30HC5; i4GL 7.20UD8 (I know they're old but we're
> working on it.... )
> Just had this pair of errors (finderr output and the 4gl context
> below).
> There have been no OS errors reported, temp space was very little used
> at the time and there are no messages in online.log. This bit of code
> has been running fine for years and has never done this before.
>
> Anyone had this before or can cast light? We've restarted the process
> and it's deleriously happy again!
>
> -566 Cannot initiate sort.
>
>
>
> This internal error reflects an unexpected condition during a sort.
>
> Check the accompanying ISAM error code for more information. If the
>
> error recurs, please note all circumstances and contact Informix
>
> Technical Support.
>
> -116 ISAM error: cannot allocate memory.
>
>
>
> The ISAM processor needed to allocate memory for data storage but was
>
> unable to do so. A problem may exist in the operating system; look for
>
> operating-system error messages that might give more information. One
>
> cause of this error might be selecting a row that contains large BYTE
>
> or TEXT columns into a temporary table or as part of an INSERT or
>
> UPDATE. In some releases, an entire row that includes BLOB values is
>
> buffered in memory. For C-ISAM programs, review the program to look for
>
> ways that it can use less memory. For SQL products, simplify the
>
> program, form, or report if possible.
>
> 4GL snippet: (The cursor is on a simple SELECT with fields that match
> the temp table definition with no casting, functions etc). It failed on
> the entry to the FOREACH.
>
> CREATE TEMP TABLE jobs_togo (>
> time_to_start DATETIME YEAR TO SECOND,
>
> jobreq_id_ref INTEGER,
>
> jobdef_id_ref INTEGER,
>
> jobs_type CHAR( 1 ),
>
> job_priority SMALLINT,
>
> allow_multp_yn CHAR(1),
>
> lastupd_user CHAR(14)
>
> )
>
>
>
> LET li_current = CURRENT
>
> FOREACH cr_jobs USING li_current INTO lr_rep_data.*, lc_user_name
>
> INSERT INTO jobs_togo VALUES ( lr_rep_data.time_to_start,>
> lr_rep_data.jobreq_id_ref,
>
> lr_rep_data.jobdef_id_ref,
>
> lr_rep_data.jobs_type,
>
> lr_rep_data.job_priority,
>
> lr_rep_data.allow_multp_yn,
>
> lc_user_name )
>
> END FOREACH
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
Ah just had a look - I guess 80 segments is too many ain't it?
Missed a whole load of allocations at 8.40 this morning.
That'll be it then!
Keith Simmons wrote:
> Malc
>
> onstat -g seg> How much memory assigned, how much total virt memory permitted by
> onconfig file? Was someone else doing a large sort at the time which
> hogged memory? Do you have tempory dbspaces for sort files? Were these
> full with other temp table at the time?
>
> Keith
>
Guess so, now you just have to find out why !!!
On 13 Oct 2006 05:22:17 -0700, malc_p@btinternet.com
<malc_p@btinternet.com> wrote:
> Ah just had a look - I guess 80 segments is too many ain't it?
> Missed a whole load of allocations at 8.40 this morning.
> That'll be it then!
>
>
> Keith Simmons wrote:
>
> > Malc
> >
> > onstat -g seg> > How much memory assigned, how much total virt memory permitted by
> > onconfig file? Was someone else doing a large sort at the time which
> > hogged memory? Do you have tempory dbspaces for sort files? Were these
> > full with other temp table at the time?
> >
> > Keith
> >
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
Keith Simmons wrote: > Guess so, now you just have to find out why !!! > ... and preferably who, so I can get the fourbytwo out......
malc_p@btinternet.com wrote: > Keith Simmons wrote: > > > Guess so, now you just have to find out why !!! > > > ... and preferably who, so I can get the fourbytwo out...... Hmm HP UX Thats where I would lay the blame! :-)