This content has been marked as final. Show 15 replies
I'm not a windows guy but you could move the database cold using scp.
Putty has PSCP here :
You can create the scp batch file using SQL
So shutdown the database and move the files. Restart do your RMAN backup and your done.
set heading off set feedback off set pagesize 100 set linesize 400 select 'scp '||a.name ||' server_name:' || a.name as newname from v$datafile a; select 'scp '||a.name ||' server_name:' || a.name as newname from v$controlfile a; select 'scp '||a.member ||' server_name:' || a.member as newname from v$logfile a;
The only issue I can is 2003 server probably does not have an SCP service like Unix.
Here's a couple links to address that :
Thanks for the response. I am trying to minimize the downtime since the database is used by many users in different time zones. Also, I'd like to test certain things on the new server before actually doing this.
In 8i, is there a way of moving/copying the entire database without interrupting the production system? Since the DB edition is standard, I cannot use STANDBY database commands, etc.
You do not have to make image copies. You can use your existing full backup and archive logs to restore database on your new server.
You can use this below link. This will help.
The link does use DATAFILECOPYs, which are created by "*copy datafile to*" command.
Please see Item#9 under title "Testing the Restore of a Database on a New Host"
CATALOG DATAFILECOPY '/oracle/oradata/trgt/system01.dbf', '/oracle/oradata/trgt/undotbs01.dbf', '/oracle/oradata/trgt/cwmlite01.dbf', '/oracle/oradata/trgt/drsys01.dbf', '/oracle/oradata/trgt/example01.dbf', '/oracle/oradata/trgt/indx01.dbf', '/oracle/oradata/trgt/tools01.dbf', '/oracle/oradata/trgt/users01.dbf';
Yes that is one way but you can use the DISASTER RECOVERY steps and can restore a database on a new machine. See this "Recovering the Database After a Disaster" heading in that document I mentioned. There it shows how to use RMAN backup and restore it to new machine.
I'm not sure about TSharma's idea. If it works that's great but you did say
"8.1.7 (Standard Edition)" and he points you to an Oracle 11 document.
The closest I can find to his idea are :
I took the Oracle backup and recovery class for Oracle 8 late in that products life.
We did not spend a lot of time on RMAN.
Good Luck with your move
Oops, I missed that. Thanks msberg for pointing this out. Lot of commands in that document won't work. Sorry about that. This is the new link for 8i almost step by step recovery for full database.
The above doc is exactly for *8.1.7* as OP mentioned. Sorry for the confusion above.
The link you sent to me is actually for one my favorite article. So, I have already reviewed it. But, there it assumes that the recovery catalog database is intact. In my case, I installed a new OS, a new database service with the same name, configured a recovery catalog. Now I just want to be able to catalog the production backups in the new server's recovery catalog, so that I can restore and recover it to the latest production state (using archivelogs from production).
What is the size of this database ?
The reason I ask is if you just move everything cold you avoid catalog issues, data sync issues etc. Yes you have an outage. But the database comes back up right where you left it. If your tnsnames is correct ( I would move them too ) then you can take a full backup a minute after startup. Plus you have the perfect rollback, an exact copy.
Will an RMAN method you still need a test plan to prove the data matches. This and accounting for any data gap will cause an outage anyway. The other thing is with Oracle 8 if you have an RMAN issue at crunch time who can help you?
OK, I will stop now with the hard sell.
The reason I want to use the RMAN method is that I need to test some applications on the new server before I do the actual cut over.
Will you please answer this question for me?
I just do not know the affect of running a "copy datafile" against the production database and whether it will affect my backup/recovery plan (I have always used backup sets) on the production server.
If you have reviwed so many articles then you should start reading some basic RMAN documentation to restore databases. You need to these steps:
1) create a service with the same name
2) copy the backups to the new server on the same location.
3) copy the init.ora file ans using that init.ora file, start the database to the nomount state.
4) Go to RMAN , restore the controlfile from the backup you have.
5) After restoring controlfile, take your backup into the mount stage
6) Because you are not using CATALOG, you might need to use catalog backup pieces and archive logs using 'catalog' command(Search google for this "how to catalog backup pieces).
And than you can use that link I mentioned whcih is your favorite as a help and recover it.
I am using a RMAN catalog database.
You do not need to use catalog database in order to restore the database. You can always register the database in a new catalog after your restore.
I can bet there will be way to move the catalog content to a new database but why do you want to do that if you can do without it.
Sorry for the misunderstanding. You are right, if I can restore the database onto the new server without a catalog database, I am happy. But, the backup records are stored in the recovery catalog database, NOT in the controlfile. So, I do not know how to let the new server know which backups to use and how?