Re: FW: dbimport slow

I have always had trouble using dbimport, especially with SPL's. I have seen some SPL's cause dbimport to core dump. If I ever have to use dbexport/dbimport (mind you, have to) I drop all SPL's before the export and reload them from the source after import. Remember also that dbexport does not preserve the table extent sizes. SSvolos@ual.com wrote: >The following is an e-mail from on of my team members. >The environment is HP K200 with 4 100MHz CPUs 1Gig RAM, lots of disk. >INFORMIX Version is 7.20 UC2. >Does anyone have any comments on this ? >Thanks, >Spyro Svolos >ssvolos@ual.com >spyro@i-compute.com >847 700 4294 >---------- >From: Tsai, Peter / whq, whqka >Date: Thursday, July 17, 1997 11:26AM >Team, >I've just recently started to use dbexport and dbimport utilities to >set benchmark points so that I don't need to repeat NLS (Nightly Load System) >and TPS (Transaction Processing System) to get to a certain break point. >I want to share some information with you. >Executing dbexport is very fast. For occ1001d with one nightly load >data loaded, it just takes one or two minutes to export. >However, to import the database takes much longer, usually at least one hour. >You probably think most of the time is spent loading data, don't you? >It appears this is not true. According to what is displayed on the screen, >over 80% of the time is spent on loading the SPs (stored procedures). >In addition, the loading speed seems to exponentially decay for each procedure. >In other words, loading a procedure starts out fast, and then slows down >down, and further down. >Intuitively, it seems that the language parser for SP uses a >back-tracking algorithm >which takes exponential time. However, creating an SP is usually very fast. >So I really don't know why dbimport spends so much time on SP's. >-- Peter Tsai