Re: DBIMPORT and indexes

> Sally Woolrich <Sally@excelsis.demon.co.uk> writes: > In article <3v1r5d$6lk@tattoo.sccsi.com> > goldberg@landata.com "Steve Goldberg" writes: > > > Question: > > When doing a dbimport after a dbexport, and leaving the .sql as is, > > will the dbimport load all the data for a table and then build the > > indexes? Or will it build the indexes as it loads the data? (Which we > > all know is a slow way to do it) > > I'd like to know the answer to this too, though it's a bit > academic since it does what it does. But I do know that it's > much, much, much faster to do the 'dbimport' with transaction logging > turned of and to start it once the import has finished! > > -- >>>> As the commandfile can be edited this is not acedemic. I loaded a 1.5 GB db not so long ago into Online 7.1 At that time I found the load to be much faster if I removed all the create index statements first, and put them into a separate filethey I ran afterwards using dbaccess. From the order of things in the commandfile and this experience it seems like the indexes are created first - bad.... May be it is enough to move the create index statements after the load (insert?) statements in the command file before dbimport is run. I never tried that. And of course you turn transactions off before you start dbimport. The dbexport/import stuff should also have done something intelligent with first/next extent size, but it doesn't. Next year Informix??? I seem to remember having seen a utility that does something with extents, but I don't remember where/which or what it does. It ought to calculate the first extent size based on the size of the table (including indexes) and set a next extent size as some percentage of this as a starting point. With many tables it is a significant job to go through the current command file, calculate and add these things manually. Nils.Myklebust@ccmail.telemax.no NM-data, Dalsbergstien 7, N-0170 Oslo, Norway My opinions are those of my company