In 2008R2, I would always using BIDS to deploy packages to MSDB. All permissions were then controlled through SQL Server.
In 2014, I see that you can still save to the file system or MSDB, but that there is now the SSISDB that you create as an Integration Services Catalog. This method clearly allows a lot more flexibility with the addition of easy variable access and even environment variables.
Yes SSISDB is Best Practice. Packages can be deployed to SSISDB. Packages keep a deployment history (like a very basic version control) so you can even rollback some revisions of your package.
Main Advantage of the new model is the configuration. You don’t need XML or dedicated SQL tables to save your configurations. You can use input parameters and map them with enviroments defined on sql server.
You can manage security through SQL Server because now everything can be handled via SQL Server Security.
Another cool feature is the Integration Services Dashboard, a report automatically built with report services template. Just click Integration Service Catalog and right click your packages to view “All Executions”.
You can see very detailled Information about your packages including execution time.
Long Answer: In my opinion the main advantage are the project parameters. Imagine this like Parameters you can pass to the SSIS Package. You can parametrize your Connection Manager or just parts of it.
Example: You can parametrize the server name and in your ssisdb you can create two enviroments (or more) called “development” and “production”. Then you can add variables to both of them and map them to the input parameter of your package. The main advantage is that you can deploy a package to SSISDB and link to an environment and you don’t have to handle the connection strings by yourself.
Sources:
https://stackoverflow.com/questions/27969960/sql-server-2014-ssisdb-vs-msdb-for-package-deployment
Comments