Re: Import performance wierdness dicovered!?!
Date: 11 Oct 94 09:19:21 +1000
Message-ID: <1994Oct11.091921.1_at_cbr.hhcs.gov.au>
In article <Cx9zJB.3MD_at_freenet.carleton.ca>, ag831_at_FreeNet.Carleton.CA (Denis Langlais) writes:
> > In a previous article, pape_at_plato.chemietechnik.uni-dortmund.de (David Pape) says: >
>>Hi all,
>>
>>I've been fooling around with the import program to find out if we can
>>do imports more efficiently than at present, and have found the following
>>to be true:
>>
>>When I import a single table of 3440 rows from an import file that is
>>~21MB big (approx. 60 other tables data in the import file) and time it
>>using /bin/time (Unix command, sorry DOSers), i get:
>>
>>81.3 real 38.2 user 11.3 sys
>>
>>i.e. 1.3 minutes real time to import the table.
>>
>>WHEN I export JUST the table of 3440 rows, and THEN import THAT file
>>(now only 240 KBytes big), it took a mere 7.3 seconds of real time
>>to import the table!!!!!
>>
>>What's up with that, eh?? Can this be explained by anyone out there?
>>
>>Does import have to search the entire file for extra extents? (I exported
>>both files with compress=Y, so I wouldn't think this could be true.)
> > import has to scan the file to find the table you want to import. > It then proceeds to import the table you want. > (This scanning can take even longer if your file is on tape.) > > The funny thing is that once your table has been imported > it continues to scan the rest of the file until it reaches the end. > I would guess that it may be looking for other tables of the > same name (belonging to another user)
IMP is getting very old. They've tagged on a few new features like BULK loads but the product is still very much the same as the one in Oracle v5.
I did hear rumours that they were going to give it a 'nice and friendly menu interface and more functionality' but that was a year and a half ago and if Oracle doesn't provide something within 6 months you can usually forget about ever seeing it within 3 years.
I think IMP has to read through all the data (formatting as it goes) and they need to check right to the end for indexes and grants and views and other stuff OR the designer was lazy and couldn't be bothered putting in a test for completion other than end-of-file.
-- Bruce... pihlab_at_cbr.hhcs.gov.au ******************************************************************* * Bruce Pihlamae -- Database Administration * * Commonwealth Department of Human Services and Health * * Canberra, ACT, Australia (W) 06-289-7056 * *=================================================================* * These are my own thoughts and opinions, few that I have. * ******************************************************************* "The more complex the argument gets, the easier it is to refute." "Killing is wrong!" -- Trent 'The Uncatchable' CastanaverasReceived on Tue Oct 11 1994 - 00:19:21 CET