January 27, 2009 at 8:39 am
I've been trying to do some research on this topic and I'm having a hard time finding any information on the subject. My question is I have a Sql Server mirrored environment and I'm setting up CLR on my primary server. Will this cause issues with my secondary server? Is it possible to run CLR in a Sql Server mirrored environment?
Thanks,
January 27, 2009 at 11:08 am
What safety level are your assemblies? That is what determines the level of headache you will have at failover and during deployments.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
January 27, 2009 at 12:28 pm
My .dll file is set to "WITH PERMISSION_SET = EXTERNAL_ACCESS;"
and my XmlSerializers.dll is set to "WITH PERMISSION_SET = SAFE;"
I'm assuming the 2nd one will cause issues?
January 27, 2009 at 12:48 pm
Nope. SAFE Assemblies work just fine. How much trouble you have with the EXTERNAL_ACCESS one depends on how you deployed it. IF you used a key to sign the assembly, then you should be ok in a failover so long as the Login on both the Principle and the Mirror have the same SID. You can accomplish this by scripting the Assymetric Key from the principle, and then scripting the Login from the Principle using the scripter on this link:
http://support.microsoft.com/kb/918992
When you do this the SID's match between the Logins on the Servers, so when the failover happens, the Database User in the SQLCLR database maps directly to the Login by SID and it all comes up nicely.
If you used TRUSTWORTHY = ON, you will be manually intervening in the event of a failover, and there is no work around for that. You will have to remap the dbo and then retrust the database because TRUSTWORTY is set OFF when recovery happens to the mirror. See the following blog post:
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
January 27, 2009 at 8:48 pm
What would be even more interesting is finding out what the CLR actually does.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 27, 2009 at 8:54 pm
Based on External_Access and a Serializer assembly, it would most likely be a webservice call, which are becoming more and more normal place.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
January 28, 2009 at 12:04 am
I was hoping the op would tell me... but Ok... what does the CLR actually do? Remember, I'm not much into GUI's or WebServices.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 28, 2009 at 5:55 am
Jeff Moden (1/28/2009)
I was hoping the op would tell me... but Ok... what does the CLR actually do? Remember, I'm not much into GUI's or WebServices.
Not that your personal preference for CLR has much to do with the question being asked, or anything you might add the actual answer to the question being asked will sway the OP one way or another, but more and more, the use of a webservice to enforce constraints or validate data on load in the database engine, is taking root. Of course that could probably open a different argument about where is data integrity supposed to be controlled in the app or in the database. If you say the database, the a CLR function making a webservice call to enforce data integrity can be an acceptable thing.
Like it or not, this is becoming considered by a number of people to be a valid use for CLR.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
January 28, 2009 at 5:59 am
Heh... and we still don't know what the CLR does, do we? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 28, 2009 at 6:00 am
jzelenda,
What does the CLR actually do, please?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 28, 2009 at 6:05 am
Does it really matter for the context of the question posed in this thread?
Your aversion to CLR takes every thread in this forum completely off topic and clutters the workspace at times. I can definately see making a post where something is obviously not correctly being implemented or where it is obviously prone to problems, but just chasing every CLR question like you do isn't very helpful to people who search for actual solutions to questions like this one.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
January 28, 2009 at 7:27 am
Sorry it took so long to reply. The CLR actually calls a Webservice that in return based on what's being passed to it can execute various stored procedures. The reasoning for going through a webservice is because the process that is executing is within an transaction statements. So this allows us to load error log tables without the transactions be rolled back when there is an error. Hopefully that makes sense.
January 28, 2009 at 7:59 am
Actually, that does. Thank you for taking the time to explain.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 29, 2009 at 9:44 pm
Jonathan Kehayias (1/28/2009)
Does it really matter for the context of the question posed in this thread?Your aversion to CLR takes every thread in this forum completely off topic and clutters the workspace at times. I can definately see making a post where something is obviously not correctly being implemented or where it is obviously prone to problems, but just chasing every CLR question like you do isn't very helpful to people who search for actual solutions to questions like this one.
As a matter of fact, it does, Jonathan. People who don't know how to use SQL Server are writing CLR's to make up for their ignorance of T-SQL. Most CLR's are a lot slower and tougher on resources than T-SQL to do the same job. My aim is not "chasing" CLR's... it's trying to educate people. I do the same thing with people who use Cursors for the very same reason... it's usually a mistake to use them. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply