dbload - memory fault
Posted in 2001
A user on Informix OnLine 7.10 under SCO OpenServer 5.0.4 found dbload crashing with "Memory fault - core dumped" depending on the -n (commit interval) value and the size of the input file (~45,000 rows of ~85 bytes). The only advice given was that 7.10 is an old, unstable release and that upgrading to 7.31UD1 or later would be faster and more reliable. The thread then drifted into a warning that 7.31UD1 breaks retrieval of generated SERIAL values via sqlca.sqlerrd[2]. No actual fix or diagnosis of the dbload crash is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: General Discussion
Hi,
we have trouble with dbload utility (Informix ODS 7.10 on SCO
OpenServer 5.0.4).
Execution of dbload is abnormally terminated with some values of -n key
(and with default value). We've seen the message "Memory fault - core
dumped". Execution of dbload is finished successfully with other values
of this key. Moreover this "successfully" values is depended from size
of loading file. Average size of this file is 45000 row and average
size of row is 85 bytes. Any ideas?
TIA.
Igor.
Sent via Deja.com
http://www.deja.com/
OL7.10 had LOTS of problems. NOT A STABLE version. Upgrade to 7.31UD1 or
later this is about 50% faster and far more stable.
Art S. Kagel
iig@mail.ru wrote:
>
> Hi,
>
> we have trouble with dbload utility (Informix ODS 7.10 on SCO
> OpenServer 5.0.4).
>
> Execution of dbload is abnormally terminated with some values of -n key
> (and with default value). We've seen the message "Memory fault - core
> dumped". Execution of dbload is finished successfully with other values
> of this key. Moreover this "successfully" values is depended from size
> of loading file. Average size of this file is 45000 row and average
> size of row is 85 bytes. Any ideas?
>
> TIA.
> Igor.
>
> Sent via Deja.com
> http://www.deja.com/
In the year of Our Lord Mon, 12 Feb 2001 18:26:30 -0500, "Art S. Kagel"
<kagel@bloomberg.net> spake, saying:
>OL7.10 had LOTS of problems. NOT A STABLE version. Upgrade to 7.31UD1 or
>later this is about 50% faster and far more stable.
Hint: don't go to UD1 if your app uses serials.
>iig@mail.ru wrote:
>>
>> Hi,
>>
>> we have trouble with dbload utility (Informix ODS 7.10 on SCO
>> OpenServer 5.0.4).
>>
>> Execution of dbload is abnormally terminated with some values of -n key
>> (and with default value). We've seen the message "Memory fault - core
>> dumped". Execution of dbload is finished successfully with other values
>> of this key. Moreover this "successfully" values is depended from size
>> of loading file. Average size of this file is 45000 row and average
>> size of row is 85 bytes. Any ideas?
>>
>> TIA.
>> Igor.
>>
>> Sent via Deja.com
>> http://www.deja.com/
>>>>> "Clown" == Obnoxio The Clown <obnoxio@hotmail.com> writes: >> OL7.10 had LOTS of problems. NOT A STABLE version. Upgrade to >> 7.31UD1 or later this is about 50% faster and far more stable. Clown> Hint: don't go to UD1 if your app uses serials. Hmm. We are planning to upgrade to UD1 as well Clown. Can you be more helpful and tell us the problem with serial columns? Its is a "showstopper"? Did you have to roll back to 7.31-UCX? I did check Google (DejaNews is gone) and searched the newsgroup postings and found nothing related to 7.31-UD1 and serial columns. Mark -- "Sure, it's going to kill a lot of people, but they may be dying of something else anyway." -- Othal Brand, member of a Texas pesticide review board, on chlordane.
In the year of Our Lord 13 Feb 2001 08:51:56 -0500, Mark Oberfield <oberfiel@eclipse.nws.noaa.gov> spake, saying: >>>>>> "Clown" == Obnoxio The Clown <obnoxio@hotmail.com> writes: > > >> OL7.10 had LOTS of problems. NOT A STABLE version. Upgrade to > >> 7.31UD1 or later this is about 50% faster and far more stable. > > Clown> Hint: don't go to UD1 if your app uses serials. > >Hmm. We are planning to upgrade to UD1 as well Clown. Can you be >more helpful and tell us the problem with serial columns? Its is >a "showstopper"? Did you have to roll back to 7.31-UCX? You can't retrieve the generated value from sqlca.sqlerrd[2] >I did check Google (DejaNews is gone) and searched the newsgroup >postings and found nothing related to 7.31-UD1 and serial columns. >"Sure, it's going to kill a lot of people, but they may be dying of >something else anyway." > -- Othal Brand, member of a Texas pesticide review board, > on chlordane. Nice...
Obnoxio The Clown wrote in message <3a892bd9.10124578@130.133.1.4>... >In the year of Our Lord Mon, 12 Feb 2001 18:26:30 -0500, "Art S. Kagel" ><kagel@bloomberg.net> spake, saying: > >>OL7.10 had LOTS of problems. NOT A STABLE version. Upgrade to 7.31UD1 or >>later this is about 50% faster and far more stable. > >Hint: don't go to UD1 if your app uses serials. > YOU WOT?!?!?!??! is there ANY acceptable versions around 7.31 ??? What's the problem? When will it be fixed? *sigh*
In the year of Our Lord Wed, 14 Feb 2001 09:36:21 +1100, "Andrew Hamm" <ahamm@sanderson.net.au> spake, saying: >Obnoxio The Clown wrote in message <3a892bd9.10124578@130.133.1.4>... >>In the year of Our Lord Mon, 12 Feb 2001 18:26:30 -0500, "Art S. Kagel" >><kagel@bloomberg.net> spake, saying: >> >>>OL7.10 had LOTS of problems. NOT A STABLE version. Upgrade to 7.31UD1 or >>>later this is about 50% faster and far more stable. >> >>Hint: don't go to UD1 if your app uses serials. > >YOU WOT?!?!?!??! > >is there ANY acceptable versions around 7.31 ??? What's the problem? When >will it be fixed? *sigh* I dunno, what's the take on UC7? SQLCA.SQLERRD[2] returns 0, not the last inserted serial value. UD2? (Just a guess)