Re: LOAD FROM... stmt is very slow

Further info about my previous message: Now I am using dbload instead of dbaccess and I still get problems (but now it loads 500 rows first before it slows down.) The problem is that the oninit process is using about 99.5% of the CPU time. This is usually an indicator of something big being wrong, I would think. It is still running, but verrrryyyyy slooowwwwwly. -- [----------------------------------------------------------------------] [ Steven L. Mading at BioMagneticResonanceBank (BMRB). UW-Madison ] [ Programmer/Analyst/(acting SysAdmin) mailto:madings@bmrb.wisc.edu ] [ Room B1108C, 'Old' Biochemistry Bldg, (410 Henry Mall) ]

Try the same process after disabling your indexes and constraints on the table and see what happens set indexes, constraints for <table> disabled; If you see a dramatic change, its possible that your indexes have become inefficient or even corrupt through constant inserts and deletes. Solution : Disable and enable them (or drop and recreate them). Still doesn't explain the ESQL/C performance, though. Rudy Steve Mading wrote: > Further info about my previous message: Now I am using > dbload instead of dbaccess and I still get problems (but now it > loads 500 rows first before it slows down.) The problem is > that the oninit process is using about 99.5% of the CPU time. > This is usually an indicator of something big being wrong, > I would think. It is still running, but verrrryyyyy slooowwwwwly. > > -- > [----------------------------------------------------------------------] > [ Steven L. Mading at BioMagneticResonanceBank (BMRB). UW-Madison ] > [ Programmer/Analyst/(acting SysAdmin) mailto:madings@bmrb.wisc.edu ] > [ Room B1108C, 'Old' Biochemistry Bldg, (410 Henry Mall) ]

Steve Mading <madings@baladi.nmrfam.wisc.edu> wrote: > > Further info about my previous message: Now I am using > dbload instead of dbaccess and I still get problems (but now it > loads 500 rows first before it slows down.) The problem is > that the oninit process is using about 99.5% of the CPU time. > This is usually an indicator of something big being wrong, > I would think. It is still running, but verrrryyyyy slooowwwwwly. > Turn logging off for the database, remove the indexes from the table in question and put back after the load (and anything else that you can think of that makes extra work for the engine ...) /j\\ -- "I managed to take her completely by surprise" - Prince Edward

Hi! Any messages in the log or on the console? Can you create a new table with the same layout and load it with better performance? Michael Steve Mading wrote: > Further info about my previous message: Now I am using > dbload instead of dbaccess and I still get problems (but now it > loads 500 rows first before it slows down.) The problem is > that the oninit process is using about 99.5% of the CPU time. > This is usually an indicator of something big being wrong, > I would think. It is still running, but verrrryyyyy slooowwwwwly. > > -- > [----------------------------------------------------------------------] > [ Steven L. Mading at BioMagneticResonanceBank (BMRB). UW-Madison ] > [ Programmer/Analyst/(acting SysAdmin) mailto:madings@bmrb.wisc.edu ] > [ Room B1108C, 'Old' Biochemistry Bldg, (410 Henry Mall) ]

Rudy Fernandes <rferdy@americasm01.nt.com> wrote: : Try the same process after disabling your indexes and constraints on the : table and see what happens : set indexes, constraints for <table> disabled; : If you see a dramatic change, its possible that your indexes have become : inefficient or even corrupt through constant inserts and deletes. Solution : Disable and enable them (or drop and recreate them). Still doesn't : explain the ESQL/C performance, though. Thank you. That did make a gigantic difference. Now I know what to look for (check my indeces.) I think the reason that ESQL/C worked so much faster was that I was only inserting a few rows with it. dbload was also fast up until the 500th row or so.