none
SQL2005 Service Broker on 64bit active/passive cluster & .Net Framework 3.5sp1 RRS feed

  • Question

  • Hi
    We are currently running Service Broker on one of our SQL2005 64bit Enterprise servers. We recently upgraded some 3rd party software which has s SQL backend database and one of the requirements was for .Net Framework 3.5sp1 to be installed on both nodes of the SQL cluster.  Being cautious about what impact this would have, we installed it on our passive node and failed over.  However over a 12 hour period we then hit some problems with messages queues on our Service Broker application.  We assumed these were related to the .Net Framework 3.5sp1 install, so failed back to our node without this and all has been working well for 72hours. 

    So I'm trying to establish if there are any known issues installing .Net Framework 3.5sp1 on a SQL2005 bit cluster. Or if anyone has experience similair problems.  It could just be a coincidence we had issues, or there is something else on the passive node that was causing the problem.

    Many Thanks in advance.
    Darren
    Tuesday, October 27, 2009 1:19 PM

Answers

All replies

  • Can you post any error messages from the problems with message queues on the service broker application, if any ?  Messages may be helpful to understand the issue.

    Jang
    Tuesday, November 3, 2009 7:52 PM
    Moderator
  • Hi
    We didn't get any errors, when an activating CLR stored proc was firing on a service broker queue, the queue kept being disabled. However since raising this post we have identified that.

    When .Net Framework 3.5sp1 was installed on the passive node it upgraded the .Net Framework V2.0sp1 to sp2.  We have an assembly created from the system.messaging.dll that sits in the .Net Framework.

    create assembly [System.Messaging] authorization dbo
    from 'c:\windows\Microsoft.NET\Framework\v2.0.50727\System.Messaging.dll'
    with permission_set=unsafe
    go


    This dll has been updated with the .Net Framework V2.0sp2, so we think we probably need to drop our assemblies and clr procs which depend on this  dll and recreate again on the passive node when we failover again. Then install the sp update on the other node so both nodes are the same.

    We are currently trying to recreate the problem in a test environment.

    If this problem sounds familiar would be interested to know.

    Thanks
    Darren

    Wednesday, November 4, 2009 6:37 PM
  • This was our problem as we thought.

    http://support.microsoft.com/kb/949080
    Wednesday, November 4, 2009 10:28 PM