Recoverpoint and SQL failover

Hi there

I have no seen the issue with RecoverPoint as long as both the data and log LUNs are in the same consistency group (or tied with a group set) for write order consistency (crash consistency).

Can you detail what exactly you are doing in relation with platespin?  Are you migrating from a physical to a virtual machine?

Hi Jaysal

I think from the process you noted below it seems like platespin is trying to create a virtual instance of a live physical machine which is in motion.

Can you try this please.

1) Run platespin to create the VM of the physical.

     But do not grab the SQL LUNs.

     Poweron and ensure the SQL VM is good.  Reboot to ensure its persistently ok.  Then shutdown.

2)  Enable image access on the RP bookmark

3) Reboot the ESX host or rescan the SCSI BUS.    

4) Add the LUNs through ESX to the SQL VM and power on.

5) Attach the DB(s) and perform a dbcc checkdb.

Even if you are not using Replication Manager or kutils SqlSnap, RP will create a crash-consistent recoverable image of SQL.

Thanks

James.

HI James,

Thanks for the response. We use Platespin to go from physical to virtual. The logs and data LUNS are in the same consistency group. Here is the process we follow. We have done this same procedure with other SQL servers and it seems to work just fine but this one SQL server is giving us problems.

1) Run the platespin job to convert the physical machine to a virtual machine(this takes about 30 minutes)

2) Enable image access (Physical not Virtual access)…We have chosen multiple images including the latest and still get issues.

3) Attach the LUNS to the virtual machine.

4) Reboot the SQL server.

Sometimes the SQL server will come up in suspect mode and sometimes it will come up normal but our DBA runs a DBCC check against the DB and we see errors. When we run the DBCC check there are always errors on the DR SQL server but in PROD there are no errors.

Would running a full sweep possibly help?

Jaysal Patel | Infrastructure Engineer

Information Technology

Bain Capital, LLC | 111 Huntington Ave | Boston, MA 02199

O. 617-516-2034

C. 603-289-7871

E. jpatel@baincapital.com

Thanks James. The only issue we have here is that platespin will reverse the job if we shut the VM down. It’s an automated process that can’t be changed within Platespin so as soon as we shut the VM down Platespin will execute a reverse job and remove all the changes that have occurred on the VM. Keep in mind we are running this in test mode so this is not a real failover the Production host is still running throughout the test. This just brings up the VM in protected bubble network. We are able to reboot the VM but not shut it down. Generally we will reboot the VM a few times like you stated to do in step 1. We will do one final reboot and during that reboot we will enable image access. One thing we don’t really do is rescan the ESX hosts after enabling image access. We could try that after we enable image access and see how that goes.

Jaysal Patel | Infrastructure Engineer

Information Technology

Bain Capital, LLC | 111 Huntington Ave | Boston, MA 02199

O. 617-516-2034

C. 603-289-7871

E. jpatel@baincapital.com