Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

EMC RecoverPoint and SQL Server Expand / Collapse
Author
Message
Posted Tuesday, July 17, 2012 4:16 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, September 11, 2012 3:26 AM
Points: 55, 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.
Post #1330627
Posted Tuesday, July 17, 2012 12:05 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Friday, August 15, 2014 5:01 PM
Points: 1,613, Visits: 1,539
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
Twitter: @SQLSoldier
My book: Pro SQL Server 2008 Mirroring
Microsoft Certified Master: SQL Server 2008
Principal DBA: Outerwall, Inc.
Also available for consulting: SQL DBA Master
Post #1330957
Posted Wednesday, July 18, 2012 2:17 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, September 11, 2012 3:26 AM
Points: 55, Visits: 228
After some more research it seems the suggested way is to manually detach the databases then reattach manually in a DR scenario.
Post #1331289
Posted Thursday, July 19, 2012 10:53 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 10:35 AM
Points: 866, Visits: 2,377
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).
Post #1332377
Posted Thursday, September 6, 2012 2:48 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, August 15, 2014 1:39 PM
Points: 26, Visits: 321
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.
Post #1355622
Posted Tuesday, October 30, 2012 10:18 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, July 18, 2014 9:23 AM
Points: 43, Visits: 227
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?
Post #1378876
Posted Thursday, May 9, 2013 9:05 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 4, 2013 11:16 AM
Points: 5, 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?
Post #1451178
Posted Thursday, May 9, 2013 9:27 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 10:35 AM
Points: 866, Visits: 2,377
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.
Post #1451192
Posted Thursday, May 9, 2013 10:22 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 4, 2013 11:16 AM
Points: 5, 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?

Post #1451252
Posted Thursday, May 9, 2013 10:36 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, July 18, 2014 9:23 AM
Points: 43, Visits: 227
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.



Post #1451261
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse