Cloning A Production Server

[subodh_deshpande3]

Hello All,

I have the following scenario.

mySAP 2004(ECC 5.0) on AIX and Oracle 9.2.6.0

<u>Current DB Size is around 150 GB.</u>

<b>SID: PP1, IP: 192.168.1.13</b>

My requirement is to copy this same environment onto another sever (Create a DR instance) with the following options.

mySAP 2004(ECC 5.0) on AIX and Oracle 9.2.6.0

<i><b>SID: PD1, IP: 192.168.1.14</b></i>

I am aware of the fact that i have the following options with me.

1. The SID has to be different (Since both the old server and the new server will co-exist)

2. There will be a change of IP.

3. Points 1 and 2 necessitate a fresh install on the NEW server.

4. The options for "cloning the system" are

a. Homogeneous System Copy

b. Client Export and Import.

I now ask,

1. What is the best possible option for me to perform the "cloning" in the shortest possible time and the method, if possible.

2. What is the downtime i should expect based on the DB size (150 GB).

3. Any other method ?

I would be very grateful for any resolutions that are provided and would reward the same.

Thanks and Regards,

Subodh

[Former Member]

Hi Guys ,

we are planning for DR setup using oracle data guard . In my scenario SID will be same . My setup inclues MySAPERP 2005 , SRM , XI , portal , BI .SLD , solution manager

My Question is -

What about hostname ? , should it be the same ?

As my scenario is integrated and we have given hostnames in lots of RFC and in configurations .Hence I feel it should be same .

Any view guyssss ..........

Cheers

[Former Member]

Hi Rakesh,

From my experience in setting up log shipping enviornments manually (as opposed to using Data Guard), I always used a different hostname for the DR server. At failover time, we'd manually change the hostname to that of he primary server and everything would work as expected - we tested this annually.

I'd expect that Oracle Data Guard (or something like Libelle's DBShadow) automate this for you. Please let me know if this is the case.

Best,

Arwel.

[subodh_deshpande3]

Hello all,

Thank you all those you have taken the effort to go through my question and provide advice/suggestions.

Regards,

Subodh

[subodh_deshpande3]

Hello All,

Thank you all for putting in your thoughts to my questions. If i may summarise the findings.

1. Scenario: <b>Clone the system</b>

<u>The SID has to be different</u> in this case. The procedure for this would be to copy the DB and apply the logs shipped.

2. Scenario: <b>DR</b><u>The SID has to be SAME</u>. The procedure for this too would remain the same as above with the exception that i would need not edit the SID in the scripts. I can use third part tools like Oracle Data Guard for log shipping.

I am expecting further affirmative comments on the above before i set the "answered" status for this message.

Thank you all once again for your valuable input. I have rewarded you with the points.

Regards,

Subodh

[former_member204746]

Clone: you can clone the system and keep the same SID. This is possible but is generally not a good idea. So, better change your SID to make sure people do not post stuff in the wrong system.

DR: yes, keep the same SID

[Former Member]

Hi Guyz, I think Subhodh is looking for cloning the database for systemcopy and client copies not for DR(disaster recovery) if it is for DR recovery then it has to be exactly same as production. If you are looking to clone the database for test with different SID then here is the simple way:

(only database part)

1.take full offline backup of source system(PD1 in your case)

2.just before or after backup take control file back to trace

( SQL>alter database backup controlfile to trace)

3.restore the database&redologs onto the target system with relavant file systems

e.g: if your source datafile paths are /oracle/PD1/sapdata1/....

then on target system it will be like /oracle/TRG/sapdata1...

4.ftp or copy the traced control file from location usertrace .trc file will be created

with time stamp when you run the above command.

5.after you copied trace file on target system name it as cr_db.sql and edit the file

6. when you open the cr_db.sql you will see the two parts of control file when you have online redologs and when you dont have online redologs , remove part two.

7.edit first part from startup nomount and in place of reuse reaplce set, in place of

PD1 replace TRG. keep the script until characterset and delete every thing there after.

8.copy your spfile<SID<.ora OR init<SID>.ora file from source to target

9.after you installed oracle( or copied bineries from source) at SQL prompt

10.SQL>startup nomout

11.run the script cr_db.sql SQL>@<path>/cr_db.sql

12.now your database is at mount stage

13.SQL>alter database open resetlogs

14.create temp tablespace

15.ALL DONE your database is cloned.... now follow other steps from homogenous system copy manual from market place.

Regards

Manohar

[former_member204746]

1. The SID has to be different (Since both the old server and the new server will co-exist)

---> NO... the SID must be the same if you want a DR server

4. The options for "cloning the system" are

--> for real DR, you need to copy your DB to new server and use log shipping and apply those logs on DR server.

[Former Member]

Hi,

I would recommend you use log shipping (as Eric mentioned) to provide a DR environment, We've used this method for many years and it's proved very stable. You also get the added benefits of being able to use the DR system as the source for copying your live database without the need to shutdown the live system (if downtime is an issue for you. Also, when our Production system grew beyond 500Gb, we started to use the DR system as the source for tape backups. This removed the overhead the backups put upon the live system.

There are some applications that make log shipping easier to manage - take a look at Oracle Data Guard, Libelle DBShadow or Steeleye LifeKeeper. Having said that, we've always manually built and managed our DR environment without many problems.

Hope this helps,

Arwel Owen,

SAP Infrastructure Manager,

Princes Ltd.

[Former Member]

Hello,

> 1. The SID has to be different (Since both the old server and the new server will co-exist)

Then it will not be a <b>DR </b>scenario. for a true DR, both systems have the same SID.

How will you keep both systems in sync? or ir is only a "test" to see if your DR is working?

IMHO. The best option would be an homogeneus system copy using backup and restore.