January 15, 2014 at 11:27 am
We have a SQL Cluster in our PRIMARY Philly data center.
We have a SQL Cluster in our D/R Pittsburgh data center.
We have DB Mirror setup to mirror the data from Philly to Pittsburgh for D/R. Working great.
We realize that if we failover to the D/R data center, our SQL server name in our connection strings will need to change.
Ques: How does an SRDF implementation change this? If we used SRDF instead of SQL DB Mirror, would we still need to change our connection strings to point to a different SQL Server? In other words, does SRDF depend on a "2nd" SQL server in the D/R location?
January 16, 2014 at 4:41 am
SRDF is a storage level replication technology. SQL server is separate so yes you still have to change instance connection strings
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 16, 2014 at 4:59 am
thanks for this reply. yes, I'm familiar w/ SRDF to some degree and how LUNs are pre-defined to capture mirror images of the data (EMC Timefinder Clone, etc)
Our issue is this. Our vendor lists SRDF as their recommended D/R solution. We opted to use SQL 2008 R2 Database Mirroring. The SQL DB mirror is setup and working just fine. Our vendor complained that SQL Server Database Mirroring is not a viable solution, is not working for them, and that we need to go spend 10's of K's on an SRDF solution.
I "thinK" (we have yet to have a discussion w/ the vendor on this) they are attempting to access the MIRROR DB's w/out failing over and of course, these are unavailable until we failover with either a 'soft' or 'hard' failover --- or thru the Mirror GUI:
SOFT: ALTER DATABASE <dbname> SET PARTNER FAILOVER
HARD: ALTER DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
In any event, once we failover - we are moving off our Primary SQLServer_ABC and pointing to our D/R SQLServer_XYZ which requires chg's to connection strings.
Our question - is SRDF different in this respect. Can you failover from primary SQLServer_ABC to an exact named D/R SQLServer_ABC -- thus avoiding connection string changes ??
January 16, 2014 at 5:00 am
Express12 (1/15/2014)
We realize that if we failover to the D/R data center, our SQL server name in our connection strings will need to change.
Not necessarily. You can add the failover partner to the connection string and applications can automatically failover.
It would need testing but is possible.
January 16, 2014 at 5:13 am
MysteryJimbo (1/16/2014)
Express12 (1/15/2014)
We realize that if we failover to the D/R data center, our SQL server name in our connection strings will need to change.
Not necessarily. You can add the failover partner to the connection string and applications can automatically failover.
It would need testing but is possible.
which, unfortunately, is an option lost if they move away from mirroring
---------------------------------------------------------------------
January 16, 2014 at 5:20 am
Express12 (1/16/2014)
Our issue is this. Our vendor lists SRDF as their recommended D/R solution. We opted to use SQL 2008 R2 Database Mirroring. The SQL DB mirror is setup and working just fine. Our vendor complained that SQL Server Database Mirroring is not a viable solution, is not working for them, and that we need to go spend 10's of K's on an SRDF solution.
this is replication at the database level and totally independent of any application so strange they would say that. All I can think of is the throughput is so high that without a very good network the latency becomes an issue. Maybe this is a problem they have seen before so now fight shy of mirroring. you can always run in high performance mode if you have enterprise edition
I "thinK" (we have yet to have a discussion w/ the vendor on this) they are attempting to access the MIRROR DB's w/out failing over and of course, these are unavailable until we failover with either a 'soft' or 'hard' failover --- or thru the Mirror GUI:
with SRDF the disks on the failover are not usable either
In any event, once we failover - we are moving off our Primary SQLServer_ABC and pointing to our D/R SQLServer_XYZ which requires chg's to connection strings.
Our question - is SRDF different in this respect. Can you failover from primary SQLServer_ABC to an exact named D/R SQLServer_ABC -- thus avoiding connection string changes ??
in our implementation of SRDF this was only possible if you boot from SAN, and ALL drives including C are replicated
---------------------------------------------------------------------
January 16, 2014 at 7:27 am
:Whistling: another totally useless option in respect of sql server that storage vendors plug to the nines claiming all sorts of benefits for sql server. Their detail in their plug document has the information on log shipping totally wrong, it's the biggest load of rubbish i've had the misfortune to read so far this year 😀
http://www.emc.com/collateral/software/solution-overview/h2203-ms-sql-svr-symm-ldv.pdf
SRDF documentation
Log shipping limitationslog shipping only transfers those changes recorded to the t-log which are subsequently save to an incrememntal log
waffle waffle blah blah
Log shipping is a database centric strategy. It is completely agnostic and does not address changes which occur outside of the database. These changes include, but are not limited to:
- application and binary files(service packs)
- database config changes
- database binaries
- OS changes
- external flat files
- addition of new data files on new luns
To sustain a working environment at the DR site, procedures must be executed to keep those objects up to date.
Also the information regarding re instantiating the database is designed to knock the process and make their glossy solution much more attractive, pity its inaccurate 😉
I have a log shipping test system which has the primary and secondary on the same instance so the databases have different names. When adding a new file to my Secondary database, the LS restore job understandably fails as follows
Log shipping backup agent job history]
Job step error
*** Error: Could not apply log backup file 'H:\somepath\somefolder\LSPRIMARY_20140116125635.trn' to secondary database 'LSSECONDARY'.
(Microsoft.SqlServer.Management.LogShipping) ***
2014-01-16 12:57:21.22*** Error: The file 'H:\somepath\somefolder\LSPrimary2.ndf' cannot be overwritten.
It is being used by database 'LSPRIMARY'.
File 'LSPRIMARY_2' cannot be restored to 'H:\somepath\somefolder\LSPrimary2.ndf'.
Use WITH MOVE to identify a valid location for the file.
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) ***
If the paths between the PRIMARY and SECONDARY match and the databases have the same name, file creation operations will be seamless. To correct this i had to use
restore log LSSECONDARY from disk = 'H:\somepath\somefolder\LSPRIMARY_20140116125635.trn'
with standby = 'H:\somepath\somefolder\LSSECONDARY_20140116125421.tuf',
move 'LSPRIMARY_2' TO 'H:\somepath\somefolder\LSSECONDARY_2.ndf'
This produced the following output
Processed 0 pages for database 'LSSECONDARY', file 'LSPRIMARY' on file 1.
Processed 0 pages for database 'LSSECONDARY', file 'LSPRIMARY2' on file 1.
Processed 7 pages for database 'LSSECONDARY', file 'LSPRIMARY_log' on file 1.
RESTORE LOG successfully processed 7 pages in 0.006 seconds (9.033 MB/sec).
Checking the system catalogs now shows
select name, physical_name from LSSECONDARY.sys.database_files
Logical namePhysical Name
LSPRIMARYH:\somepath\somefolder\LSSECONDARY.mdf
LSPRIMARY_log H:\somepath\somefolder\LSSECONDARY_Log.ldf
LSPRIMARY2 H:\somepath\somefolder\LSSECONDARY2.ndf
Changing the database compatability level on the PRIMARY from 100 to 90 and running the LS jobs produces the expected result.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply