March 31, 2011 at 12:00 am
Comments posted to this topic are about the item Preparing for the Unthinkable - a Disaster/Recovery Implementation
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
March 31, 2011 at 7:12 pm
Perfect timing on your article. I am currently at a start up and we are working furiously to get the database operationally ready. D/R has been in the back of my mind for weeks, and now is the perfect time to move on this before we have actual production data at risk. Thanks. 😀
April 1, 2011 at 7:10 am
I'm glad this is of potential use to you.
Go ahead and download the code, deploy it and please let me know of any bugs or anything I may have missed.
I have tested this code repeatedly, but you never know what I may have missed. 😉
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
April 1, 2011 at 8:04 am
Thanks, I shall.
December 13, 2012 at 11:30 am
This article is useful. However, this approach will not work well for logins if Windows authentication is used for some logins and primary and DR servers are not a member of the same domain. In our case primary server is a member of domain and DR is not in a domain at all.
December 14, 2012 at 4:35 am
JoeSchmoe007 (12/13/2012)
This article is useful. However, this approach will not work well for logins if Windows authentication is used for some logins and primary and DR servers are not a member of the same domain. In our case primary server is a member of domain and DR is not in a domain at all.
Thanks for sharing.
Yes, it's true that if prod and DR are not on the same domain, at least some of this functionality will break.
What are your contingency plans though if you end up having to use the DR in case of a disaster?
You would need to bring the DR into your prod domain, especially if applications are using Windows authentication in the prod environment.
If that is the case, why not include the DR in the production domain from now?
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
December 14, 2012 at 7:30 am
Marios Philippopoulos (12/14/2012)
JoeSchmoe007 (12/13/2012)
This article is useful. However, this approach will not work well for logins if Windows authentication is used for some logins and primary and DR servers are not a member of the same domain. In our case primary server is a member of domain and DR is not in a domain at all.Thanks for sharing.
Yes, it's true that if prod and DR are not on the same domain, at least some of this functionality will break.
What are your contingency plans though if you end up having to use the DR in case of a disaster?
You would need to bring the DR into your prod domain, especially if applications are using Windows authentication in the prod environment.
If that is the case, why not include the DR in the production domain from now?
Ideally we should but we only have one computer in DR location at this time and no permanent VPN connection to primary site, so it is not possible.
December 24, 2012 at 11:28 am
Thanks for sharing!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply