I was truncating, then dropping because I understood that dropping can
take too long in done alone because it generates redo/rollback.
-Roger
joel-garry_at_home.com (Joel Garry) wrote in message
> What he means is, you don't have to both drop and truncate the table.
> Dropping the table and not recreating it before the import means it
> will be created by the import, using the settings of the exporting
> instance, or in some cases, default settings.
>
> What you probably want to do if you can is pre-create the tables empty
> before importing them, so you can be sure they are where and how you
> want them to be. Once loaded, you truncate them before reloading so
> as not to change the settings.
>
> You also want to have proper defaults on users and tablespaces, so you
> don't wind up accidentally importing into the system tablespace or
> with strange settings.
>
> Another gotcha is that you want the tables to be reasonably sized for
> the data you are importing. If your originating table has had lots of
> deleted records, you don't want to use the "compress=y" option on the
> export and then have the export create the table, as all that deleted
> space will migrate. If you don't have that issue, compress=y can be a
> handy way to find out how big the tables will be.
>
> >
> >
> > "magpies" <-_-> wrote in message news:<ata089$pmv1_at_imsp212.netvigator.com>...
> > > You can just to truncate the tables but to drop it out. Otherwise, import
> > > will create a new table based on its original setting.
> > > Now you can truncate the tables again, set the table at apporiate value
> > > using 'alter table' command. Lastly, import the tables using 'import table'
> > > option instead of 'full import'.
> > >
>
>
> jg
Received on Fri Dec 13 2002 - 09:21:33 CST
