SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


EMC RecoverPoint and SQL Server


EMC RecoverPoint and SQL Server

Author
Message
hindle.steve
hindle.steve
SSC Eights!
SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)

Group: General Forum Members
Points: 833 Visits: 228
We are trying to implement EMC RecoverPoint with SQL clustering.

What we had to do at the DR side after syncing the databases was detach the databases and take the clustered disk resources off-line so replication could happen at the block-level. However when we brought the DR side back on-line we had to manually attach the databases.

My question is - is this the right way of doing it as ideally we want to have this automated and not have to manually attach the databases t the DR side.

Thanks.
Robert Davis
Robert Davis
SSChampion
SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)

Group: General Forum Members
Points: 11939 Visits: 1666
You should engage EMC for that. They should have some guidelines on the best way to do this with their product.


My blog: SQL Soldier
SQL Server Best Practices: SQL Server Best Practices
Twitter: @SQLSoldier
My book: Pro SQL Server 2008 Mirroring
Microsoft Certified Master: SQL Server, Data Platform MVP
Database Engineer at BlueMountain Capital Management
hindle.steve
hindle.steve
SSC Eights!
SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)SSC Eights! (833 reputation)

Group: General Forum Members
Points: 833 Visits: 228
After some more research it seems the suggested way is to manually detach the databases then reattach manually in a DR scenario.
Nadrek
Nadrek
SSCrazy Eights
SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)

Group: General Forum Members
Points: 8016 Visits: 2741
Can you provide some more information on your Recoverpoint automation? We're starting to work with RecoverPoint as well, though without clustering, so our scenario is a little simpler (mount to a point in time with Recoverpoint, then bring up SQL at the remote site).
speja01
speja01
SSC-Addicted
SSC-Addicted (408 reputation)SSC-Addicted (408 reputation)SSC-Addicted (408 reputation)SSC-Addicted (408 reputation)SSC-Addicted (408 reputation)SSC-Addicted (408 reputation)SSC-Addicted (408 reputation)SSC-Addicted (408 reputation)

Group: General Forum Members
Points: 408 Visits: 364
I'll definitely be interested in hearing about your experience with RecoverPoint. We started using it a few months back to replicate data to our remote DR site. Our first DR test worked fine but the second one not so much. We had a few databases come up in suspect mode as well as some table errors in other databases (DBCC reported). We are still trying to figure out what went wrong.
Aashini Shah
Aashini Shah
SSC-Addicted
SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)

Group: General Forum Members
Points: 425 Visits: 235
Guys,

We tested our DR strategy using RecoverPoint.

It was a disaster. Most critical databases did not attach.

Msg 1813, Level 16, State 2, Line 2
Could not open new database 'DRTest'. CREATE DATABASE is aborted.
Msg 823, Level 24, State 2, Line 2
The operating system returned error 38(Reached the end of the file.) to SQL Server during a read at offset 0x00001b8ccf4000 in file 'O:\SQLDATA\DRTest.mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Msg 3313, Level 21, State 2, Line 2
During redoing of a logged operation in database 'DRTest', an error occurred at log record ID (378200:49915:21). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.


Are there any pointers or suggestions for doing recoverpoint DR strategy right?
JamesK1
JamesK1
Valued Member
Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)

Group: General Forum Members
Points: 69 Visits: 64
Hi. I realize this thread is someone old but I was wondering if anyone had better experiences with using RP?

My own experience has been spotty. I have been able to attach databases to our DR SQL Server (2008 R2) using a snapshot from RP. I've had success in some instances but other times, there were failures due to one of the storage becoming inaccessible. EMC did not have any real solution to our problem except to upgrade to a more recent version of RP - which we plan on doing.

Furthermore, they do not go beyond the storage aspect and into the required steps for within SQL Server. So, I've had to discover on my own the required steps needed to use RP on our DR server.

So what we have come up with so far are the following for mounting/unmounting RP storage on DR. I can't say it's perfect but it seems to work for the most part.

Mount RP storage:
1. Disable replication and mount snapshot from RP to the DR host
2. Online the disks in Disk Management
3. Start SQL services and attach databases
4. Create and/or fix orphaned or missing db logins.

Unmount RP storage (to reenable replication):
1. Detach databases from SQL Server in DR and stop SQL Services.
2. Offline the disks used in Disk Management.
3. Unmount RP Storage and enable replication in RP.


Something I have yet to test is to see what happens if we do NOT detach the databases and return the disks back to RP. Would I be able to take another snapshot and mount the storage and start sql services without issues? OR will it cause problems because I didn't detach during the unmount steps?
Nadrek
Nadrek
SSCrazy Eights
SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)SSCrazy Eights (8K reputation)

Group: General Forum Members
Points: 8016 Visits: 2741
Which database and log files are being replicated?
Was the replication up to date on all of them, or was it behind on some of the LUNs?

In our testing, we put every .mdf and .ldf except for tempdb on to SAN luns - including master, model, and msdb.

We carefully set up SQL Server on the DR site to point to where those would be mounted, and left SQL shut down on the DR side.
Thus, we first mount with Recoverpoint and make sure the LUNs are attached, online the LUNs, rescan them, make sure the drive letters are what's expected and are all presenting, and only then do we try starting SQL Server.

It's a little more complex than that, but that's the basics. It's critical to make sure every drive is mounted properly and is available at the expected drive letter before starting SQL Server.

ETA: Using the above technique, there's no reason whatsoever to detach or attach databases within SQL Server; they come as a complete set, from Master on down (except TempDB, which you simply need to have storage at the correct drive letter/mount point for). Remember, RecoverPoint is a very simplistic block level replication; it knows nothing about databases, nothing about files, not even anything about file systems.
JamesK1
JamesK1
Valued Member
Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)Valued Member (69 reputation)

Group: General Forum Members
Points: 69 Visits: 64
Hmm.. we only have the user databases and logs on RP. How did you install SQL Server on your DR without creating the system databases?
Aashini Shah
Aashini Shah
SSC-Addicted
SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)SSC-Addicted (425 reputation)

Group: General Forum Members
Points: 425 Visits: 235
We installed standalone sql servers with system dbs at DR.

We created jobs on Prod servers to script logins, permissions, jobs etc and robocopy scripts to the relevent sql servers at DR.

Data and log drives are repliacted to DR real time.

We have created a schedule fo DR now and every 1 months we sync up all releases and changes.
During that time, we ask out storage team to present images at DR servers. Once the replicated drives are available, we attach the dbs and run the latest permissions, jobs scripts.

Middleware team deploy all the releases, QA does spot testing and we declare 'all is well' at teh end of the day feeling good that we have some plan. :-)

We had some bumpy start with Recovery Point. See my previous message on this thread. Basically, when we get that message questioning integrity, we go contunue going back to previous images until we find the one that works. We communicated to Complianec team at work that even though target is to have no data loss in case of disaster, this situation could cause some data loss - not major since image is taken almost every few seconds.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search