use the IGNORE=Y option on the import. IGNORE=Y tells import to ignore errors that occur due to objects already existing.

beware -- you can end up with duplicate constraints and such if you are not careful this way. For example consider:

ops$tkyte@8i> create table t ( x int check ( x > 0 ) );
Table created.

ops$tkyte@8i> select CONSTRAINT_NAME , SEARCH_CONDITION from user_constraints;

CONSTRAINT_NAME SEARCH_CON
--------------- ----------
SYS_C0025825 x > 0

Ok, so table T has one constraint on it -- the one we put there. Lets export the table:

ops$tkyte@8i> host exp userid=/ tables=t

Export: Release 8.1.5.0.0 - Production on Fri Jun 23 09:15:14 2000

(c) Copyright 1999 Oracle Corporation. All rights reserved.


Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
Export done in US7ASCII character set and US7ASCII NCHAR character set

About to export specified tables via Conventional Path ...
. . exporting table T 0 rows exported
Export terminated successfully without warnings.

And now, to pretend we are in another database, we'll recreate it
ops$tkyte@8i> drop table t;
Table dropped.

ops$tkyte@8i> create table t ( x int check ( x > 0 ) );
Table created.

And now import it with ignore=y. Note that the constrant SYS_C0025825 no longer exists in this database -- when we dropped T, we dropped that constraint. When we created T, we recreated that constrain but with a new default name!

ops$tkyte@8i> host imp userid=/ full=y ignore=y

Import: Release 8.1.5.0.0 - Production on Fri Jun 23 09:15:15 2000

(c) Copyright 1999 Oracle Corporation. All rights reserved.


Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production

Export file created by EXPORT:V08.01.05 via conventional path
import done in US7ASCII character set and US7ASCII NCHAR character set
. importing OPS$TKYTE's objects into OPS$TKYTE
. . importing table "T" 0 rows imported
Import terminated successfully without warnings.

ops$tkyte@8i> select CONSTRAINT_NAME , SEARCH_CONDITION from user_constraints;

CONSTRAINT_NAME SEARCH_CON
--------------- ----------
SYS_C0025826 x > 0
SYS_C0025827 x > 0

Note that after the import we have the constraint 2 times on the table -- once from the create table and once because import brought back the originally named constraint.


So -- this points out why you might want to name all constraints, if we had named that constraint ourself, this would not happen.