System Copy - Cloned

[Former Member]

Hi there,

We are running on a virtual Linux landscape. I want to create a sandpit environment

based on our current ECC 6.0 Dev system for now.

We have created a new virtual server and cloned the DEV system onto this.

Now before I start SAP are there any do's and don't's that anyone knows about.

e.g. I know I need to rename the hostname in the instance/startup profiles and in /etc/hosts

I also need to remove the links to the transport domain controller.

Just wondering if anyone has gone through this procedure and offer any advice

on the subject

Many thanks

Andy

[Reagan · Accepted solution]

Hello

It depends on how you cloned the system.

If you have cloned a running database then the database wont start. Instead you can restore an online backup and apply all the redologs.

Else stop the SAP system and the database and take a copy of the system and then start database on the new location.

If there will be a new SID for the cloned system then you need modify the file system names and also the environment variables else forget this part.

Install new License (if required)

If you have an Oracle database then you need to reconfigure the listener and tnsnames.ora files

Disable the background process before you start SAP for the first time.

Regards

RB

[Former Member · Accepted solution]

We clone running databases all the time (Oracle DB). On first start the DB will do a recovery and so will take a while longer, but it should be fine afterwards. It is no different really than a forced shutdown (power failure, etc.) - an Enterprise DB should cope fine. I wouldn't do this for a system I wanted to be 100% sure about, but for building sandpit systems I have no problem with it.

I have our storage system take a snapshot every night, while the system is up and running, and clone from the snapshot when needed.

Steve.

[Reagan · Accepted solution]

Hello

We clone running databases all the time (Oracle DB)

Yes It is possible and the same logic is used on online backups. RMAN does a good job here.

The database is put in backup mode. You recover the database using the archived logs created during the backup time.

Without putting the database in backup mode and if you clone an Oracle database then there will be problems starting the database.

if there was no need to put a DB in backup mode then most of the backup solutions (online) wouldnt trigger the alter database begin backup statement when the backup is started.

Regards

RB

[Reagan · Accepted solution]

Additionally here is what Oracle says:

Mark the beginning of the online tablespace backup. For example, the following statement marks the start of an online backup for the tablespace users:

SQL> ALTER TABLESPACE users BEGIN BACKUP;

Caution:

If you do not use BEGIN BACKUP to mark the beginning of an online tablespace backup and wait for that statement to complete before starting your copies of online tablespaces, or then the datafile copies produced are not usable for subsequent recovery operations. Attempting to recover such a backup is risky and can return errors that result in inconsistent data. For example, the attempted recovery operation can issue a "fuzzy files" warning, and can lead to an inconsistent database that you cannot open.

Source:

http://docs.oracle.com/cd/B13789_01/server.101/b10734/osbackup.htm

Lastly, What I have suggested is based on my experience. If you take a snapshot of the system when the database is running and NOT in backup mode then starting the database will most probably fail even after a recovery.

Regards

RB

[Former Member · Accepted solution]

That is interesting. My experience is exactly the opposite - I have done this a lot (dozens of times) and never had a database fail to restart. But, as I said, if I wanted a 100% reliable result I still wouldn't do it this way. I would go for a proper online backup as you describe, or more likely an offline backup (actually shutdown, snapshot, startup, clone from snapshot - no need for an actual backup). For a temporary sandpit, though, given my so far 100% record with this technique, I'm prepared to risk it for the convenience and time savings.

Steve.

[Former Member]

Many thanks guys for taking the timeout to reply to my questions. It is

much appreciated.

I now know what needs to be done.

Thanks again

Andy

[Former Member]

We do a very similar thing in a Solaris environment. For very temporary sandpit systems we don't bother changing the SID - if the clone isn't going to interact with any other SAP systems there's no need. Just changing the hostname in the profile files should be good enough. And whatever you need to do to your DB to work on the new host.

The remaining things you need to think about are the same as if you'd done a traditional system copy - background jobs, printing, etc. If this is just a temporary system there's no need to spend a lot of time getting it right, though. And if you haven't changed the SID you don't need to run BDLS.

About the only thing you really need to get right first is background jobs. They'll start running as soon as the system comes up, obviously. If there are any scheduled that might do unfortunate things - communicate with other systems while pretending to be the source ERP system, for example - you need to avoid that. The simple way is to edit the instance profile (you have to do that anyway) to set the number of background work processes to 0. Then you can start it up, cancel the jobs you don't want, shut it down again and give yourself some Bs back!

Steve.

[Former Member]

Many thanks Steve for your reply.

And whatever you need to do to your DB to work on the new host.

Could you just explain a bit further i.e. statement above. We are running

Oracle 11g. Is there anything specific because it is a cloned system??

Thanks again

Andy

[Nibu]

OK...If you keep the same SID , and for a temp purpose , its fine to go ahead  with such cloning . No DB relevant activities are required exept the listerner,tnsname files changes  as of I know, you may just try open the Db , and check if any recovery is required . Once opened , it would be fine .

Just take care of below 

1) Check the custom jobs (Zjobs) , that will start running as soon as you start system, follow as Steve explained

2) I would recommend to disable SCOT  to prevent the system from sending any unwanted mails

3) Change the login screen if its set for DEV

4)Check if any integrations are there in your source system(eg.  BI  or any third party), disable it here ..

[Former Member]

For Oracle I think you just need to change the hostname in the listener.ora file. Otherwise it should just work if the SID hasn't changed.

Steve.

[Former Member]

Oh, yes, SCOT. I always forget that. When cloning a DEV system that's unlikely to cause any issues but if you clone a production system best make sure SCOT is disabled also. If you disable background wps for the first start then nothing will get sent out - change the SCOT config at the same time as cancelling background jobs.

Steve.

[Nibu]

Hi Andy,

What about the DB part? Which DB you are using ? Cloning is fine for OS level file system stuffs, still you have to perform rename based on your SID . Again, what you will do for DB , you need to perform your DB specific steps for system copy , or else there is no point of such a cloning .