如果SQL Server上有正确的过程和技术，那么在数据库之间复制存储过程可以是一项简单的任务。其中将包括本机的复制功能或者日志传输。在没有这些功能的情况下，我们仍然可以使用手动过程来实现相同的操作。事实上，在特定的环境和情况下手动的方法可能效果会更好一些。

　　内置复制功能

　　通过使用 SQL Server 2005 复制，存储过程定义是以一些不同的方式来复制的。快照（Snapshot）复制选项能够移动所有对象和数据，因此，数据库对象的定义能在发布者（Publisher）和订阅者（Subscriber）之间复制。当创建发布（Publication）和定义一个物件（Article）时，事务和整合复制都有相同的功能来移动存储过程的定义。这是通过指定sp_addarticle系统存储过程的@type变量的正确参数来实现的。这些变量的选项是：

　　o proc schema only —— 支持存储过程模式

　　o proc exec——支持存储过程执行

　　o serializable proc exec——支持在一个序列化事务中的存储过程执行

　　o func schema only —— 支持一个只用于模式的用户定义方法

　　其中值得一提的一项是sp_addarticle的@type变量的功能，它是用来在订阅者上复制存储过程的执行的。我们可以通过proc exec或序列化proc exec参数来实现相同的操作。因此，如果我们有一些主要的事务是通过存储过程来执行的，那么，这就是一个通过存储执行复制数据而非直接复制数据的选项。关于更多这个选项的其它信息，可以参考在事务性复制中发布存储过程执行和如何：在事务性发布（SQL Server Management Studio）中发布存储过程的执行。

　　日志传输

　　使用日志传输，通过发布一个全面和事务的日志备份，生产服务器上的所有存储过程代码都会被复制到备份服务器上。这样就确保，即使代码在生产环境发生变化，它也将会与在备份服务器上的代码相同。它的价值在于，没有完成任何其它的任务的情况下——包括安装和监控备份和恢复——不再需要其它的操作来确保代码在环境之间正确的复制。这对于灾难恢复和高可用需求是非常有益的，但是它可能并不支持我们的应用。

　　手动部署

　　当编译代码或者使用SQL Server 2005 Management Studio的本机功能时，我们可以通过修改脚本来在多服务器上执行相同的代码。这样，我们就能够将代码修改进行分组，并通过连接到正确的SQL Server数据库手动复制代码。我们还可以整合一个版本控制系统来扩展这一功能。其中一个这样的系统是Visual SourceSafe，当在QA环境中测试和对产品进行部署时，它支持代码在开发时的编译和在版本控制系统中的取出和提交。

　　自动部署和同步

　　最后一个选项是利用市场上某些第三方产品以便自动化存储过程的部署过程。有些工具支持自动的方式在并行的服务器之间进行打包和部署代码。有些工具可以同步化环境之间的代码。我们可以从供应商中了解这些工具。

　　不要忘记过程和技术

　　本文中所列出的技巧提供了一个在SQL Server环境中复制存储过程的合理技术方法。可惜的是，没有一个存储过程是孤立的，我们也无法将用户和过程分离开来。事实上，代码修改要求前端、中间层和其他DMLDDL的修改。此外，在开发、测试和生产环境之间，变更管理过程必须确定一个固有的过程。一定要为正确解决方案权衡好技术、人员和过程。