I have some stored procs that reference a few linked servers in a distributed transaction. This works OK in live, but in my DR location I have fewer actual machines, and they contain databases that reside on separate machines in live.
Under the circumstances, i would have to use loop-back linked server names in DR, which would kill the distributed trans, or I would have to have two versions of the code - for DR and Live, that reference actual machine names - which pretty much defeats the purpose of disaster recovery.
I have tried solving the issue by adding conditions like
IF @@SERVERNAME = 'SQLPROD1' EXEC SQLPROD2.MyDB.dbo.mySPELSE EXEC SQLDR2.MyDB.dbo.mySP
Problem with that is - if either SQLPROD2 or SQLDR2 is offline - the SP fails, because referential integrity is validated at "prepare", and an inaccessible server throws an error, even though it would not be actually referenced at all at execution.
Is there a way of adding conditional statements that would be evaluated at "prepare" stage?
Or perhaps someone could suggest a different way of achieving what I am after?
The fundamental problem you are facing here is that you are trying to solve applicatively an architecture problem. As a dirty hack you can eventually want to try something like this to fool the compiler (in pseudo code).
if exists( linked server (SQLPROD2) or linked server (SQLDR2))drop linked server SQLPROD2drop linked server SQLDR2IF @@SERVERNAME = 'SQLPROD1'begin create linked server SQLPROD2...EXEC SQLPROD2.MyDB.dbo.mySPdrop linked server SQLPROD2...endELSE begincreate linked server SQLDR2...EXEC SQLDR2.MyDB.dbo.mySPdrop linked server SQLDR2...end
<<I'm guessing you can get around this by using dynamic SQL:>>
Definitely a more elegant solution. You just me realize I have a bias onto not mixing up dynamic SQL and multi server distributed transactions for security purposes and error feed backing reasons. Thanks (I do mean it) :)
Both viable ideas, guys. thanks... I have to say that dropping and recreating linked servers sounds a bit clumsy to me, though, and dynamic SQL introduces its own complications because my stored procs have output parameters. Besides, isn't there a performance hit with dynamic SQL because it has to re-generate the execution plan? Or is that a moot point, because SPs (and their execution plans) are atomic, anyway, even when sub-called?
Actually, there is yet another complication to this - I also have a QA environment where server names are yet again different, but there I also have the added complication of database names being different (MyDB_QA1, MyDB_QA2, MyDB_Dev, etc) I do not think that problem can be resolved by architectural changes, as originally pointed out - I have to have these multiple copies of the databases. I guess I will have to go the dynamic SQL route... Thanks again.
0
Featured Post
There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.
When trying to connect from SSMS v17.x to a SQL Server Integration Services 2016 instance or previous version, you get the error “Connecting to the Integration Services service on the computer failed with the following error: 'The specified service …
Using examples as well as descriptions, and references to Books Online, show the different Recovery Models available in SQL Server and explain, as well as show how full, differential and transaction log backups are performed