cleaning tables before import

for testing/debugging I am importing some percentage of the real data and importing it from the production system as and when needed.
(we do have a development which is too stale for testing some specific data related problems as it is the prev weeks data).

assuming that i have all the datafiles/tablespaces and after importing for the first time, do I have to truncate all the tables and import again or drop the schema/user and import, I do it by dropping the schema now.

Which would benefit?

TIA
-dharma

Since you are importing a small(?) subset of your data, try NOT truncating or dropping the user cascade when importing. What happens?

Make an image of your test database. Shutdown, copy the files to a holding area, then startup. If you trash the database, and when you are done, you can delete the bad version and cp/mv the original files back.

So what you are looking at is three test cases, all should and can be run somewhat quickly.

1) Leave your data in place and try importing on top of it.
2) After restoring your database "image" (if needed), truncate all the tables of the schema owner and try importing on top of the empty tables.
3) After restoring your database "image" (if needed), drop user cascade, then import that user's objects into the database with the same tablespace names. Bonus question: does it really matter if the datafiles have the same name or not?

shouldnt have started testing things on a easter weekend..well ended up playing with other things and stuck now. well let me try and get back in this thread.

the datafile..I knew if I can assign a single default tablespace to the user and import i dont have to worry about the actual structure. I think that is the ans to the bonus ;)

thanks steve