Login or Sign Up to become a member!
LessThanDot Sit Logo

LessThanDot

Data Management

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Lessthandot twitter Lessthandot Linkedin Lessthandot friendfeed Lessthandot facebook Lessthandot rss

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Your profile

    Search

    XML Feeds

    Google Ads

    « SQL University Women In Technology (WIT) Week: My Name Is Jes, and I'm a WITNew Collection of SQL Server Videos on Channel 9 »
    comments

    Some of us work extensively with SSIS and multi-instance SQL clusters. One of the headaches with SSIS in this type of set up, is that SSIS is not cluster aware. This includes where packages are saved when you upload them through SSMS.

     

    Now to give you the ability to save and manage SSIS packages on specific MSDB databases for a SQL cluster, we need to edited a file. The file can be found at this path:

     

     

    You can now either scroll down or order the document type in descending order and you will find see this file:

     

     

    This is the configuration document for the SSIS engine where it provides the connection to MSDB. When you open this, you will see something similar to this:

     

     

    We are interested in the following node, which we will also edit:

     

     

    The highlighted lines will be changed according to the respective settings in your environment. In my example I have a two node active/active cluster, therefor my configuration file will be edited as below:

     

     

    I changed the names from MSDB to Instance1 and 2 to make it easier. This file should be changed on all of the nodes in the cluster and after the change, the SSIS service should be stopped and started through SQL Configuration Manager for the changes to take affect.

    For the ServerName value, the value should be changed to sqlvirtualname\sqlinstancename. After the all the changes have been made and the service has been restarted we can log into the SSIS engine through Management Studio. Again, because SSIS is not cluster aware, we have to use our SQL virtual name to gain access.

    Now we will see the following:

     

    Thanks to this handy configuration, all of your SSIS packages can be saved to their respective instance MSDBs' and management will be easier due to a centralized access point and no need of guessing where your packages are being saved.

    About the Author

    Stephan specializes in MS SQL Server technology stack with the main focus on the database engine component as well as high availability, automation, troubleshooting and optimization. Currently he holds a position at Microsoft South Africa (EMEA) as a Premier Field Engineer for MS SQL Server.
    Social SitingsTwitterLinkedInLTD RSS Feed
    761 views
    Instapaper

    3 comments

    Comment from: Ted Krueger (onpnt) [Member]
    Ted Krueger (onpnt) Great tip! It also still frustrating that the services are not cluster aware. Easy to say it isn't needed since the services don't really have a functional impact on "uptime" but a nuisance nonetheless. It is just another thing that is an extra step in HA that probably doesn't need to be.

    The official word on that: http://msdn.microsoft.com/en-us/library/ms345193.aspx
    03/07/11 @ 06:31
    Comment from: Michael Robey [Visitor] Email
    Michael Robey I have mine seet up this way but how do I use the expression for my connection manager to know which databases to hit. With one instance as the default only I can check the server name and know to connect to that server but with multi instances on a server I don't know which one to execute.

    If I have DEV and UAT as instances I will have the same package on both instances and I don't want to have to recode the package as it moves up the tier from DEV to UAT and want the package to figure out which tier it is on.
    09/22/11 @ 13:37
    Comment from: SQLArcher [Member] Email
    SQLArcher This is only to make management and uploading of SSIS packages easier for the DBA who is responsible for managing it.

    When you create any connections like a SQL job for instance, it will still have to reference the server where the msdb is located instead of the server where you added the XML entries.

    One way to view this XML configuration is to see it as a "central Management Server" for SSIS packages, just a central point of management.
    09/23/11 @ 05:39

    Leave a comment


    Your email address will not be revealed on this site.

    Your URL will be displayed.
    (Line breaks become <br />)
    (Name, email & website)
    (Allow users to contact you through a message form (your email will not be revealed.)