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 Thursday, May 9, 2013 11:03 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: Yesterday @ 2:10 PM
Points: 889, Visits: 2,460
JamesK1 (5/9/2013)
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?



Think of RecoverPoint's presented LUNs as a removeable platter or floppy or USB thumb drive or USB/Firewire/eSATA external drive - whatever you're comfortable with. It's storage that you assign a drive letter to.

Think of the drives/virtual disks/partitions/logical drives/etc. on your system the same way - it's harder to move them, but they're still storage you assign a drive letter to.

Think of SQL as something that just looks for drive letters - it really doesn't care what storage is attached, it's going to blindly look for what it expects.
First SQL looks for the Master database and the ERRORLOG file - that's why those command line parameters are set in SQL Server Configuration Manager, under the properties of the service, Advanced tab.
Then SQL reads from the Master database to find everything else.
Thus, the trick with Recoverpoint is, ideally, to have 100% identical drive letters and paths for all .mdf and .ldf files on Primary and DR (including tempdb! We just don't both replicating it, since it's "fresh" on each startup) before we start SQL Services.


Realize that you can always change drive letter assignments in diskmgmt.msc!

X: is whatever drive letter and path your production database has its system database datafiles (and maybe the logs)
Y: is whatever drive letter and path your production database has its system database logs (if they're in a different location from the datafiles)
A: is some unused letter on DR
B: is some other unused letter on DR (if Y: is in use)


So, what you do (OPTIONAL separation of Master log and database files, X: for data and possible logs, Y: for possible logs) [EXAMPLE NOT TO SCALE - this is pseudocode]:

1) Take some local or external storage, and assign it to X: (and Y:), where your Master database (and Master log) will go.
2) You install SQL such that your system DB's are on X: (and their logs on Y:).
2a) Alternately, move your system DB's to X: (and their logs to Y:) using the normal methods for moving system DB's.
2b) make sure ERRORLOG is on the same drive letter and path on Primary and DR, too; replicate or not at your option (I would, to track errors that happened during or prior to disasters!).
3) That's your "local install" - useful for doing patching, trivial function checks, and so on.
4) Stop SQL on DR
5) Now, change X: to A:, and if need be, Y: to B:, by changing the drive letter
6) Mount Recoverpoint LUNs from primary to DR, making sure on DR they get the same drive letters.
7) Start SQL (NOTE: the fine details may not be quite right, particularly the order - if anyone knows the internals and would like to correct this, that would be great! The general process, however, must look a lot like this)
7a) SQL looks for ERRORLOG, and finds it where it expects, because both Primary and DR are set up with identical paths and filenames ERRORLOG
7b) SQL looks for Master on X:
7c) SQL finds Master where it expects, because both Primary and DR are set up with identical paths and filenames for Master .mdf and .ldf files
7d) SQL reads Master to see where other databases are
7e) SQL starts tempdb in the path specified; which is can, since that path exists on both Primary and DR
7f) SQL looks for other database locations from Master
7g) SQL finds the other databases where it expects, because both Primary and DR are set up with identical paths and filenames for other database.mdf and .ldf files!

WARNING: ALL YOUR JOBS ARE PRESENT AND READY!!! ALL YOUR LINKED SERVERS ARE PRESENT AND READY!!! DO NOT START SQL SERVER AGENT UNLESS YOU REALLY, REALLY NEED TO!!!! If you start SQL Server Agent right off, then if you have a job that does production work like outputting a file or deleting backups or sending an email to a client, it's going to try to do that, because it thinks it is production!!! This could be a serious, serious problem if you're running tests!

Post #1451270
Posted Thursday, May 9, 2013 11:35 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
It sounds like we do the same things as you Aashini but with less scripting.

I'm interested in how Nadrek has his setup as it would be great to not have to do all the extra work of configuring the security and jobs.
Post #1451278
Posted Thursday, May 9, 2013 11:45 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
Thanks for the info Nadrek. I figured it might be a drive remapping trick. It does sound like a very good setup except for the last part about the SQL Agent for we do use our DR for testing on occasion and wouldn't want production processing going on from DR.

It's good to know for sure. Thanks!
Post #1451280
Posted Tuesday, July 15, 2014 5:40 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, August 21, 2014 8:38 AM
Points: 2, Visits: 15
Can you elaborate on the SQL Server installation at the DR Site please. I'm still not sure how to install SQL Server at the DR site before presenting the recoverpoint LUNs to the DR Database Server. Thank You!

"We installed standalone sql servers with system dbs "
Post #1592860
Posted Friday, July 18, 2014 8:22 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: Yesterday @ 2:10 PM
Points: 889, Visits: 2,460
Shawn Scoville (7/15/2014)
Can you elaborate on the SQL Server installation at the DR Site please. I'm still not sure how to install SQL Server at the DR site before presenting the recoverpoint LUNs to the DR Database Server. Thank You!

"We installed standalone sql servers with system dbs "


That's steps 1-4 in my post; essentially, you just install SQL Server at DR with the same options you chose at the main site, and then patch it to exactly the same level as your main site.

Make sure the system database and log files (and error files) are all installed to drive letters that you can reassign to the Recoverpoint LUNs
Post #1594082
Posted Friday, July 18, 2014 9:01 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, August 21, 2014 8:38 AM
Points: 2, Visits: 15
Its working perfectly so far. Recoverpoint with AppSync is nice!
Post #1594106
Posted Friday, July 18, 2014 9:32 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
Last year when we tried to do DR testing first time, it was bad ( see my previous posts ). We learnt our lessons, perfected our methods, RP is working out excellent for DR.

We now have DR releases followed by regular release. At that time, we present the drive images at DR site. Once the drives are available, we attach the databases, apply permission scripts, add new jobs ( we are not syncing system dbs ). We initialize replication as part of attach script. After taht we follow regular release steps and then testing. We have to watch to make sure that this is done in adequate time before journals get full. Most of the times, we are done well within time. Sometimes with some unknown issue, we detach dbs as journals are almost full, let the sync catch up with prod drives and present drives again at DR and attach dbs again.

Feels good to have nailed down DR process..

For the issues we had with integrity, we learnt that we can go back few seconds earlier image if there is an issue. However, it has been going smoothly and dont recall going back to older images ( even within second ) during last several runs.
Post #1594127
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse