tar oracle db

[Pieter_5]

Hi,

I wonder if the following trick works for migrating an oracle-db. Tar the install-dir to a tar-file and unpack it at another machine. Try the same trick for the other oracle stuff (datafiles etc). I think if I unpack it in the same dirs on the targetmachine it should all work.

[twang]

It sounds like you are trying to clone your production database into another server.
Yes, you can do so. A physical backup comes in two forms: hot or cold. A cold backup is the safest and most reliable, but it requires the database to be shut down, not an option for everyone. A hot backup can be taken while the database is up and available and in archive log mode.

Some cautions:
1) The cold backup must be "good", executed after a shutdown normal or immediate
2)the scripts must be created again if the database structure is changed
3) Avoid to consider this method as a backup strategy for a production database, this is just a way to create a copy of the original database, possibly in another location. For example you would like to create a test environment on another machine that is an exact copy of your production database.
4) Test this procedure in a safe way before trust it!!!!

Recently I have clone a database at same machine, some steps I do for your reference. In this case only a control file creation is needed.
The steps is as follows:
1) connect to database using svrmgrl or sqlplus and execute the command 'alter database backup controlfile to trace;'
2) go into user dump destination and edit the trace file generated
3) remove any line before 'STARTUP MOUNT'
4) replace REUSE DATABASE "SID" NORESETLOGS with SET DATABASE "SID" RESETLOGS
5) at the end of file remove the line "RECOVER DATABASE" and append the option RESETLOGS at the end of line ALTER DATABASE OPEN
6) If You want, you can rename the redologs or datafiles, but in this case I restore the datafiles in the new location.
7) save and close the file renaming it to createctrl.sql
8) shutdown database and backup it.
9) now you can simply restore the backed up files (datafiles,init.ora) without controlfile and redologs, connecting to svrmgrl with internal user and executing the script.

[A. Clay Stephenson]

You can certainly clone a database that way as long as your are careful to reproduce the filesystem mountpoints exactly so that the absolute pathnames are identical (or at least they are identical through the use of symbolic links). Porting your Oracle executables may be more problematic depending upon the shared libraries in use on each machine. You may get lucky or you may have to relink the Oracle executables after copying the files. If you have kept the two boxes patches to the same levels then no relink should be needed.

[A. Clay Stephenson]

One more point, you mentioned using tar. Note that the "vanilla" tar has 2GB file size limit so that could be a "gotcha". Gnu tar (or HP's patched version) will get you up to 8GB/file.

[Jean-Luc Oudart]

Hi,

this type of question has been asked in the past follow thread
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x5ed1d7d96cbad711900a0090279cd0f9,00.html
or this one
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x9edaa848deccd61190050090279cd0f9,00.html

Rgds,
Jean-Luc

[Volker Borowski]

Hi,

as Twang describes, this works well for the database files, and if you do not change path names and both boxes are binary compatible, you can copy the database offline even without creating new controlfiles -> simply copy the binary controlfiles (When DB offline during copy !!! [Been there, done that])

1) If the machines are the same it might even work to copy the executables, but there might be some problems. The numeric ID of the dba-group is linked into the binaries. If the dba-group on both machines is not the same a relink is required.

2) If the machines are the same, but not identically patched, you might get really funny results, because parts of oracle are linked staticly and parts are linked dynamicly. With a copy, you'll get the static part from source-box and the dynamic part from destination box..... Well this suggests to re-link the binaries in any case and shoot down number 1) with the same gun.

3) If you plan to use RMAN to backup both source and target db into the sam catalog you are busted. Both databases have the same DB_ID. You would need to re-incarnate the copy through RMAN..

4) Since it is quite easy to install the software, I'd go this way and copy the database files as described before.

Hope this helps
Volker

[Paul Sperry]

I would install oracle on the new machine

export the DB on the old machine
then
import the DB on the new machine

[R. Allan Hicks]

In addition to what the others have already said, you need back up the files created by root.sh in the install

used by dbstart and dbshut
/etc/oratab

used by oracle apps to set up environment
/usr/local/bin/oraenv
/usr/local/bin/coraenv
/usr/local/bin/dbhome

location of oracle inventory files
/var/opt/oracle

scripts that stop and start the server and the netservices
/sbin/init.d/oracle
/sbin/init.d/oracle_netservices

There should be symbolic links to the two files in the rc. (rc.2 and rc.3) directories in the form of Kxxxoracle and Sxxxoracle, Kxxxoracle_netservices and Sxxxoracle_netservices.

[Indira Aramandla]

Hi,

Yes you can do that.

As long as your

1. Target server is of the same OS version. Because the oracle RDBMS is different for different OS versions and flavours

2. You file system mount pints are the same and the directory structure is the same. Because Oracle has the datafile name and path definitions stored ints dictionary views. When you try to startup the database it looks for the data files (.dbf), control files (.ctl and redologs).

3. Your ORACLE_HOME directory path is the same as the source.

4. Your init.ora file should be brought across. And verify the control file name and path as specified in the init.ora file exists in the physical location.

5. The symbolic in $ORACLE_HOME/dbs pointing to your init.ora has to be redefined.

6. Copy the /etc/oratab across

7. Copy the files in /etc/rc.config.d/oracle, and the files in (rc2.d and rc3.d )to start/ stop oracle automatically when systen re-boots.

6. And copy the tnanames.ora and listener.ora files across and make sure to modify the host name to the terget host name.

Then startup the database and it should be up.


I hope this helps.

[Andreas D. Skjervold]

Hi

DO not forget to pump up the kernel parameters needed for Oracle on the new box.

rgds
Andreas