In article <EK06p0.HM5@nonexistent.com>, Jacob Salomon <jake@garpac.com>
writes
>Hi Family!
>
>I am trying to run a dbimport and have made sure there is plenty of room
>for the whole database - over 1.8 gig. I logged in as user informix, cd
>to /tmp and ran the following command:
>
>nohup dbimport -i /usr/local/dbexport -d dvgarpac mydatabase \\
> >jakes_import 2>&1 &
>
>It hums along for a while, some tables taking more time than others, as
>I monitor the size of the file jakes_import and onstat -d to watch space
>left. Then I left for the night.
>
>The import aborted after 30 minutes after I left. The error message
>was:
>
>create index "informix".zzostari1 on "informix".zzostari
>(customer,store,division,season,style,color_code,lbl_code,dimension,size_bk,rec_
>type);
>*** execute sqlobj
>212 - Cannot add index.
>
>28 - No space left on device
>
>Looking at the chunks of the target dbspace:
>
>size free
>102400 13
>204800 34066
>629760 629757
>
>I see there was still plenty of room to pack the data into. What
>happened?
>
>According to the system admin person, the /tmp file system filled up
>about the same time the export aborted. I don't believe this is
>coincidence.
>
>The environment variable DBTEMP=/var/tmp, meant to bypass /tmp.
>Unfortunately, the /tmp files were not left over after the abort so we
>could not look at them.
>
>Q1. Does dbimport fill up /tmp with all kindsa stuff?
>Q2. Does dbimport fill the current directory with stuff?
>
>I will be testing for Q2 while I await help from y'all.
>
>Thanks.
Which version of the engine are you running, SE/Online 5/Online 7?
If Online 7 then DBTEMP is no longer used, use DBSPACETEMP instead.
--
David Williams