When we move data between our Oracle databases, we've done it a few different ways: backup and restore, Oracle datapump, copy/paste, and we currently use Oracle database cloning.
The copy/paste method of moving data can work, but realize a lot of stuff will end of changing. Most notably, the Feature ClassIDs and the ObjectIDs on everything because you are essentially recreating the data. If you have nothing that references this type of data, then you won't really care.
For copy/paste, you'll want to do roughly the following as the database or data owner (depending on how you structured your data):
On the "old" database:
On the "new" database, once you get all the data copied over:
- Run the "Create ArcFM Solution Systems Tables" to recreate all the "MM_" tables: ArcFM Tools in ArcCatalog
- Run the "Upgrade ArcFM Solution Database" tool: ArcFM Tools in ArcCatalog
- "Register as Versioned" all the datasets and tables that were previously versioned in the old database, or else you won't be able to edit.
- Run the "ArcFM Solution Object Converter" tool on all the datasets and tables that ArcFM is needed for.
- Run "ArcFM XML Import" and choose the option to "Overwrite": ArcFM Tools in ArcCatalog
- Import your ArcFM Favorites: ArcFM Tools in ArcCatalog
- Reassign user rights/roles as needed.
You'll really want to do this with no users connected to the database, all versions reconciled/posted, and the database compressed...otherwise you could lose some peoples' edits.
David is right, don't copy the "MM" tables from the old database. Use the "Create/Update ArcFM system tables" tool from ArcCatalog for this (just as you said in step #1).
A couple of things - be mindful of the method used to move the data. Copy/Paste is actually recommended. Using ArcCatalog's "Export..." to move some data from one database into another may change objectID's and/or GlobalID's, which will cause problems if these values are saved for use as the basis of a relationship class.
Also, for exporting/importing ArcFM settings (via the ArcFM XML Export/Import) make sure to do this with like versions of ArcFM - e.g., don't export settings from a database at an older ArcFM release, and import them into a database at a newer ArcFM release.
Hey David Miller
One little note: in the new database, after creating the MM system tables (as SDE), be sure to grant permissions to the data owner user against the MM tables. Otherwise, when you try to upgrade (as data owner), you get a message something like the following:
Some or all of the ArcFM Solution System tables have not been created.
The rest of the message asks you to run Create/Update again. The message can send people into a bit of a loop.
Hey Adrienne Judd !
There is a way around what you are talking about. We have our system tables owned by SDE and a different user owns all the data. It makes for a slightly different upgrade process:
1. As user SDE, run the "Create ArcFM Solution Systems Tables" tool
2. As the data owner, make a public version off of SDE.DEFAULT
3. As the data owner, run the "Upgrade ArcFM Solution Database" tool.
4. Reconcile and Post the data owner version and delete.
5. As the data owner against SDE.DEFAULT, run the "ArcFM Solution Object Converter" tool against the entire database.
That method has worked for us for the last 15 years for the ArcFM upgrades.