【问题标题】:SSIS Deployment StrategiesSSIS 部署策略
【发布时间】:2011-03-04 14:03:34
【问题描述】:

我一直在研究 SSIS 的几种部署策略,想知道哪一种最容易维护。我一直倾向于使用 SQL Server 配置来容纳连接字符串,然后在我从开发服务器导入包以更改连接字符串后运行 proc。但是,我有 75 个包,这似乎有点乏味。谁能提出一个好的部署策略?

我有一个 Dev、Stage 和几个实时服务器要部署到。

【问题讨论】:

  • 这不能通过 dtutil 和 dtexec 来实现吗?

标签: sql-server-2008 deployment ssis etl


【解决方案1】:

我们为我的团队构建的大多数包使用 SQL 配置。我们为解决迁移问题所做的是添加基于环境变量的第二个配置,该环境变量告诉包要使用哪个配置数据库。这对每个人来说可能不是一个好的选择,但它对我们的设置很有效。

详情:

  • 我们的包始终从代理作业运行。
  • 我们的每个环境都位于单独的计算机上(除了沙盒,我们不使用命名实例。)
  • 我们在每台机器的默认 SQL 实例中都有一个配置数据库副本,它在每个环境中使用相同的数据库名称和架构。
  • 包查看机器名称环境变量以判断哪台机器正在执行包。
  • 该包然后在执行机器上查找配置数据库以获取要完成的实际工作的连接字符串。

当我们构建一个新包时,我们必须将 SQL 配置迁移到每个环境并根据需要进行调整。但是从那时起,如果我们更改包使用的连接或执行它的服务器,我们只需要担心它们。

这样做,包总是知道哪个服务器正在执行它,并且总是使用与该服务器关联的配置。因此,单个包的持续维护和部署通常是直截了当的。我们通常只需要担心移动包本身以及与更新相关的任何底层架构更改。

【讨论】:

  • 我们也这样做,并且倾向于将我们的脚本用于将数据输入到 SSISConfig 表中,这样它们就会根据运行脚本的服务器自动更改值。
【解决方案2】:

我通常发现在包含所有必需数据库连接的 XML 文件中包含包配置更容易。当包部署到每个环境时,这会根据需要进行修改(这可能作为部署清单安装的一部分发生)。您的 75 个包中的每一个都可以共享相同的配置文件,这使得它的管理非常简单。

【讨论】:

  • 这更多来自个人经验,但我快速浏览并发现这篇文章可能有用。 vyaskn.tripod.com/…
【解决方案3】:

我们在每台机器上都有一个指向目录的环境变量。在该目录中,我们有一个 SSIS 配置文件。配置文件有一个条目——它配置了我们所有包中的连接管理器的连接字符串属性——称为 SSIS_CONFIG。此连接字符串指向具有该环境的配置表的数据库。

配置表包含连接管理器的配置,以及各种其他配置。连接管理器行的 ConfigurationFilter 设置为数据库名称,并且 ConfiguredValue 具有该数据库的连接字符串。

每个包都有 SSIS_CONFIG 连接管理器。所有其他连接管理器都被命名为它们连接到的数据库的名称(而不是服务器和数据库的 SSIS 默认命名)。

SSIS_CONFIG 连接管理器由包配置配置,配置类型为间接 XML,其中配置位置存储在环境变量中。每个其他连接管理器都使用配置类型 SQL Server、连接 SSIS_CONFIG 以及它们连接到的数据库名称的配置过滤器。

如果一个新包需要连接到数据库,很可能另一个包也必须连接,因此该连接管理器所需的配置已经在配置表中,因此我们在构建该包时重用该值包配置。

每个环境都有环境变量和自己的数据库版本和配置表。环境之间配置表中的唯一区别是 ConfiguredValue 列中的连接字符串。例如,DEV 环境中的连接字符串指向数据库的 DEV 版本,QA 环境条目指向数据库的 QA 版本。

在环境之间推广软件包时编辑软件包会使测试无效。这种方法允许我们在不接触它们的情况下推广包。该设计还非常灵活,这使得开发和测试变得更加容易。

我们可以将此方法用于在同一台机器上运行的多个实例,并以此为指导: http://www.sqlservercentral.com/articles/Integration+Services+(SSIS)/69739/

【讨论】: