When I read all about importing, it seems as though it would be relatively easy to import this full database so that we can have it locally. Not too much DBA tasks once it is loaded, right?
I haven't really tried importing with the gui wizard. I have tried with the command prompt. Successfully. I just can't find it once it is imported. I get errors that say: 'user does not exist' and 'object already exists'
I am wondering if my parameters are correct. Basically, I need to do a full import. Is this possible?
Do I need to create a db to import into with no parameters? An empty db with no tablespaces or anything? I currently import to a db that I created with the gui...it might be a "typical" db?
Sorry for rambling and not knowing much of anything, really. I simply need to import this database. I have read so much on importing. I think what I am trying to do should be simple. I am missing something, can you help?
11-08-2000, 09:09 AM
if you do full=y, in your new database you dont need anything other than tablespace system, full will import all users, tablespaces, objects privileges etc etc.
11-08-2000, 09:12 AM
That is what I thought...so, do I create a db with no tablespace or users or anything to import into???
11-08-2000, 09:15 AM
yeap right, make sure itīs empty with only tablespace system and data dictionary
11-08-2000, 09:22 AM
While creation a db, a system t'space and system rollback seg will automatically be created.
Rest of the things will be taken care by ur IMP statement. The full=y will create all the other
11-08-2000, 09:43 AM
But, shouldn't I be creating a db with no tablespace parameters? When I import, I get errors of objects that already exist.
Also, can I do this without using the gui? I don't feel comfortable with the gui. Or, should I just use the gui and do a custom creation with no parameters?
I haven't done this before.
11-08-2000, 09:46 AM
Pao's right, the full import will create tablespaces for you, but only if those tablespaces can be created in the same directory as the source database. If you know for sure that the tablespaces can be created in the same directories as the original database, then I would create System, rollback segment and temp tablespaces and let the import do the rest.
However, if you're not sure if the tablespaces should be created in the same directories as the source database, or if you know for sure that they will be different, then I would create all the target tablespaces in the directories I want them to be in first, grant quota to the tablespaces for the user doing the import, then do a full import. If the import sees that the tablespaces already exist, it will create the objects in the correct tablespaces. In this case, add the parameter, ignore=y. This will skip over errors, "object already exists."
In the past, I have had to create users and roles in the database before the import to avoid the "user does not exist" errors. But there where other times this was not necessary.