通过

  • 项目

升级数据层应用程序

与使用脚本部署数据库或数据库更改相比，将已部署的数据层应用程序 (DAC) 升级到新版本的过程更简单。数据库开发人员只是需要生成一个描述这个新版本的架构和属性的 DAC 包。该 DAC 升级过程将新的架构与现有的已部署架构进行比较，然后动态执行更改为新架构所需的操作。

升级过程

SQL Server 数据层应用程序升级过程将已部署的 DAC 转换为同一应用程序的不同版本。例如，从 Finance 版本 1.0 升级到 Finance 版本 2.0。下面的步骤说明了一个简单的部署过程：

  • 数据库开发人员完成了 Finance 版本 1.0 DAC 的开发，然后生成一个 FinanceVersion1.dacpac DAC 包。

  • 数据库管理员将该 Finance 1.0 DAC 部署到生产环境。数据库引擎的生产实例现在有一个已部署的 DAC，它具有 Finance 的应用程序名称、1.0 的版本以及名为 Finance 的关联数据库。

  • 数据库开发人员然后开始处理下一版本，并且在开发完成后生成 FinanceVersion2.dacpac。

  • 数据库管理员计划该 DAC 升级过程。他们将备份 Finance 数据库。他们将查看 DAC 包的内容以及升级将执行的操作的报告，以便确保在生产数据库中不会导致问题。

  • 数据库管理员然后执行 DAC 升级，并且指定当前部署的版本 1.0 DAC 和版本 2.0 DAC 包。有两种用于执行升级的选项：

    • 通过使用调用 DAC IncrementalUpgrade() 方法的 Windows PowerShell 脚本，执行就地升级。就地升级将更改现有数据库的架构，以便匹配在新的 DAC 版本中定义的架构。

    • 通过使用 DAC Upgrade() 方法或**“升级数据层应用程序”**向导，执行并行升级。并行升级将创建具有新架构的一个新数据库，并且将来自原始数据库的数据转移到这个新数据库中。

  • 在升级完成后，已升级的 DAC 仍具有 Finance 的应用程序名称以及名为 Finance 的关联数据库，但 DAC 版本现在是 2.0。

部署后更改数据库

如果通过使用并非对 DAC 进行升级的其他某些机制对某一数据库进行了更改，则认为该数据库已偏离其关联的 DAC。有关的示例包括使用 CREATE TRIGGER 语句添加新的触发器，或者使用 ALTER TABLE 语句更改表的结构。某些类型的更改可能会阻止 DAC 升级过程完成，具体情况取决于指定的升级选项。这些更改也将不会在已升级的数据库中出现。

该 DAC 升级操作将检查当前数据库的架构和在 msdb 系统数据库中存储的 DAC 定义之间的差异。如果它发现差异，则会发出列出了这些差异的警告对话框。在您分析了报告的差异并设定了合适的进程或脚本以便传输该升级无法传输、但在新系统中要求的任何对象或数据后，即可继续进行升级。

在升级完成后，这个新数据库中将包含在新版本的 DAC 中定义且采用新 DAC 中指定的格式的所有对象。在大多数情况下，这将是与 DAC 和数据库的新版本相关联的应用程序版本所要求的格式。在分析升级更改报表时一定要小心，并且只传输新系统中所需的对象。例如，如果在当前 DAC 中存在若干对象并且在新 DAC 中缺少数据库，可能并不是错误。它们可能与在使用该 DAC 的应用程序的新版本中已删除或重新设计的功能相关联。

对于就地升级，将不保留已更改的对象。您必须在开始升级前保存对象定义和数据。对于并行升级，对象和数据将保留在已重命名的原始数据库中。所有已更改的对象都必须手动传输到这个新数据库中。

有关如何编写要传输到新数据库的对象的思路的详细信息，请参阅如何生成脚本 (SQL Server Management Studio)。

DAC 项目可以指定部署前和部署后脚本。这些脚本是可以执行任何操作（包括创建在 DAC 中不支持的对象）的 Transact-SQL 脚本。如果原始 DAC 包含了创建在 DAC 中不支持的对象的部署后脚本，则必须使用允许在就地升级过程中删除这些对象的机制来单独升级这些对象，否则，它们将被并行升级保留在原始数据库中。

就地升级

就地升级执行以下操作：

  • 验证已部署的 DAC 和 DAC 包具有相同的应用程序名称（例如，两个名称都设置为 Finance）。它还评估数据库引擎的实例是否满足在新版本的 DAC 的服务器选择策略（如果已定义）中指定的要求，以及现有数据库是否包含 DAC 中不支持的对象。

  • 执行使数据库的架构与在 DAC 的新版本中定义的架构相匹配所需的所有修改，例如 CREATE、ALTER 和 DROP 语句。

如果**“忽略数据丢失”**选项设置为 True，则 DAC 升级可执行删除数据的操作。例如，如果某个表在当前数据库中存在，但在新的 DAC 的架构中不存在，则升级将删除该表。在执行该操作之前，数据库管理员必须将在升级后可能需要的所有数据存档。

SQL Azure 和数据库引擎的实例都支持就地升级。就地升级需要 DAC Framework 1.1 和新的 DAC 升级向导，它们包含在 SQL Server 2008 R2 Service Pack 1 (SP1) 中。

并行升级

在 SQL Azure 上不支持并行升级，下一版本的 SQL Server 也不支持并行升级。建议的升级机制是 SQL Server 2008 R2 SP1 中提供的就地升级。

并行升级执行以下操作：

  • 验证已部署的 DAC 和 DAC 包具有相同的应用程序名称（例如，两个名称都设置为 Finance）。它还评估数据库引擎的实例是否满足在新版本的 DAC 的服务器选择策略（如果已定义）中指定的要求，以及现有数据库是否包含 DAC 中不支持的对象。

  • 从 DAC 包部署新版本的 DAC。这将以一个临时名称创建新的数据库。

  • 如果原始数据库尚未处于只读模式，则将该数据库设置为只读，并且将数据复制到新数据库。

  • 如果原始数据库已处于只读模式下，则新数据库将设置为只读。

  • 通过将一个字符串追加到数据库名称的末尾，重命名原始数据库。

  • 为这个新数据库分配原始数据库名称。

  • 在数据库管理员确认新的数据库运行正常后，可将原始数据库归档。

数据库更改可能会影响表中的数据是否传输到新的数据库。表可以处于与数据库更改有关的以下状态中：

  • 表结构在以下所有三个位置中均相同：msdb 中的当前 DAC 定义、当前数据库和新 DAC。表将出现在新数据库中，并且升级操作将数据传输到新数据库。使用 INSERT 语句基于旧表的 SELECT 完成该传输。

  • 表在当前 DAC 定义或数据库中不存在，但在新的 DAC 中定义。表将出现在新数据库中，但没有数据，因为没有要传输的现有数据。

  • 表在当前 DAC 定义中不存在，但在当前数据库和新的 DAC 中存在。表将出现在新数据库中，但升级操作将不传输数据。在升级完成后手动传输数据。

  • 表在当前 DAC 定义和数据库中存在，但在新的 DAC 中不存在。表将在新数据库中不存在。如果在新系统中需要表，则手动创建表并在升级完成后传输数据。

  • 表在所有三个位置中均存在，但是表在当前 DAC 定义和数据库中的结构与表在新 DAC 中的结构不同。表将出现在新数据库中，且具有在新 DAC 中定义的结构。

    • 如果表和列名称不匹配，则升级操作将报告它尚未传输数据。在升级完成后手动传输数据。

    • 如果表名和列名相同，则升级操作将尝试传输数据。如果一个或多个列的数据类型已更改并且不兼容，则 INSERT 语句将失败，从而导致升级进程回滚。

您可以使用任何机制将数据传输到表的新版本。您可以使用从表的旧版本选择的 INSERT 语句。还可以使用导入和导出大容量数据中论述的大容量插入方法之一。

更改历史记录

更新的内容

介绍了 DAC Framework 1.1 引入的就地升级。删除了其他主题中重复的内容。

SQL Server 2008 R2 SP1 完全支持就地升级，同时包括 DAC Framework 1.1 和一个新升级向导。