How to use a QA system as a Production backup?

[Former Member]

We have two MS clusters at different sites that are identical hardware setups. Both are running Window 2003 R2 Enterprise Ed and MS SQL 2005 Enterprise Ed. One of the clusters is running our ERP SID system and the other is running our ERQ SID.

What we want to do is be able to have our ERQ system at our DR site become on the ERP system in the event of a disaster at the ERP system site. We are using a software product called DoubleTake to replicate data in real time from the ERP to the ERQ site.

But we need some guidance on how to “mount the ERP data on the ERQ system.”

Has anyone had experience using a QA system as a PRD system backup? Does anyone have any documents/resources that may get us looking in the right direction on how to do this?

[Former Member · Accepted solution]

We have our QA system hardware available for production failover, but not automatically. In order for it to be true failover, you would have to keep the QA system as read only. That would effectively end it's QA functionality, since you would no longer be able to apply transports to it until it is opened for changes. For a real failover system, you would have to have dedicated hardware for it.

In our scenario, we ship backup tapes to our QA site regularly and transmit logs electronically. In the event of catastrophic failure at the PRD site, we use backup tape plus logs to restore the PRD data onto the QA hardware, and point users to that hardware until we can get the PRD site hardware back up and running, then restore the PRD data back onto the PRD hardware with the logs generated by QA (temporary PRD) system. This is by no means automatic, but has been a very effective model for us in the past, such as when a tornado hit our data center several years ago.

If you want automatic failover, which would be much faster than my scenario, you will need to pony up the resources for dedicated hardware.

[Former Member · Accepted solution]

Thanks for your response. I am aware that for a true failover we would need dedicated hardware. I am not opposed to doing a manual failover and pointing the clients to the new system, but I just am not sure of the steps to mount the a PRD database and executables on a QA box.

But how I envision it is something like this: DoubleTake will replicate all of the data to the spare drives on the QA cluster. Ten in a disaster, we would mount the PRD database on the QA box. But I am not sure how to manage the registry entries, exe's (because they are all under usr/sap_sid), services (sid based), and any other things. So I am wanting to know if anyone knows of a procedure or document on how to manually "mount" one SID on top of another (PRD on QA) ?

[Former Member]

You can install another instance on the QA server and just disable the SID_00 service. You probably do not want to run both instances simultaneously, but theoretically you could. The only problem would be the configuration problems with the server name being different than the original production server, but that is the same issues dealt with every time you do a refresh of QA from production.

What version of SAP are you running? I have done something similar to this with 4.6c, but have never tried it with ERP 2004/2005.

[Former Member]

Keep in mind the Java server ID, it may be sensitive to the hostname. If you do not use Java engine then it is a moot point.

RSB

[Former Member]

We are running mySAP ERP 2005, ECC 6.0.

Is there anything I should be aware of when installing a separate instance on a server? I would obviously have to setup a named instance of SQL (since the other SID would be running on the default).

I think that installing another instance on the QA box same and PRD would allow us to failover in a disaster. But I just am curious if anyone knows of anything to watch out for when installing multiple instances on the same box.

[Former Member]

I am not sure about ERP 2005, but in the past SAP has advised against using a named instance.

Does your failover software require you to run a separate instance?

You can have your production-failover database in the same default SQL instance as your QA, and you won't have to worry about the added overhead of a named server on top of it.

I think adding a named instance would only add an unnecessary level of complexity here than what you need. Just point the SAP install to the correct database and you should be fine.