| need help migrating data [message #64111] |
Thu, 16 December 2004 11:51  |
ct_oracle
Messages: 1
Registered: December 2004
|
Junior Member |
|
|
I'm trying to migrate data from an 8.1.7.0 machine to an 8.1.7.4 machine.
I initially "cloned" oracle with a unix ufsdump/ufsrestore, followed by manually upgrading to 8.1.7.4. Since the manual upgrade is so time consuming and prone to human errors/typos, I'd like to just copy my data. I've tried imp/exp, but the imp fails because most (but not all, since the production server is used frequently) of the data already exists in the destination server. I'd like the entire process to be as scripted as possible. The database is small, and time is not an issue.
What I'd really like is something like MSSQL's "backup/restore" or Sybase's dump/load, both of which save the entire database to a single file, and load it to the destination server (even if servers are running slightly different versions).
Even a script that first truncates all of the "user" tables on the destination server before the imp would be great (however all tables are owned by "SYS" and I'm afraid to truncate system tables).
Any help for this seemingly common, simple task would be greatly appreciated.
|
|
|
|
|
|
| Re: need help migrating data [message #64126 is a reply to message #64111] |
Sat, 18 December 2004 06:32  |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
Hi,
Firstly, an 8174 patch from 8170 is not time consuming, secondly it's normal to perform the work on the production database before tested backups of the databases and Oracle home. Applying the 8174 release to the host then running the 8174 patch scripts takes only an hour or so.
However, if you still intend to move the 8170 database to another computer with 8174 already installed, I would perform this work approximately as follows:
1. build the 8174 database
2. put 8170 database in restricted mode
3. export 8170 database
4. shutdown the 8170
5. import the "8170 export" into the 8174
6. modify your tnsnames.ora, ldap, oracle names etc
All the above should be tested before attempting to move the users to the 8174 database, testing should include the users, their applications and any other batch processes. Nothing less than a full UAT should be acceptable.
Unless the 8170 database is 24*7 business critical there is no reason for not having restricted access to the database when performing the work. If you're a dba you should get used to working during the late evening or night for upgrades and migrations.
Also, don't forget to do as much work as possible before the finall production move, like building a fresh installation of the 8174 database, ensuring you have enough disk space on both machines for the export files.
The essence of a migration of any kind is rigour and cooperation with the users - who after all own the database.
Michael Hartley
http://www.openfieldsolutions.co.uk
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
