独自幸福快乐吃4类食物健康过小暑依依不舍孤独

4:SQL 追踪 用SQL Server Profiler 或者SQL Trace可以捕捉到工作量，并且导出到 SQL 脚本中。脚本可以在从数据库中再次运行。 这个解决方案存在的问题包括： 4.1:执行的命令是有一定顺序的。如果一个事务在一个单独的执行中被打开或者关闭了，而这个操作不是这一系列命令中的一个，那么脚本就无法使其发生关系，因为“会话”无法被Traces识别了。 4.2:如果在两个版本之间，命令语法有区别，那么在从数据库中的执行一定会失败。 5:编程 如果你有一小批数据库要移植，那么你可能会考虑编写一个数据库组件来传输数据的修改。 示例： · 使用触发器——这可能会影响性能，因为触发器是事务的一部分。 · 使用DTS或者BCP来传输数据——这种方法在很大程度上依赖数据量的大小。 6:第三方工具: 你可以使用第三方工具，例如Log Readers来从事务日志、脚本中读取SQL 命令，然后在从数据库中执行它们。还有也无法对他们太多苛责，虽然我无法自己找到这样的一个工具，但是在SQL Server 2005中肯定会有一个工具能够备份事务日志，并且在SQL Server2000中顺利地重新存储它们。 其它 你还可以创新…… 例如，在某些情况下，你可以将日志传送到从SQL Server 2005数据库中，把它的兼容级别改为80，然后备份并重新存储到第三个数据库中去。 结论 对于关键的数据库，保留要升级的数据库的旧的版本，以及最新的数据修改，以便在需要回滚的时候用到，确实是个好主意。 但是……任何事物都没有“最好的解决方法”盲目行走等。你必须分析你的数据库特点和结构，然后决定针对你的需求的最佳解决方法。就我个人来说，我倾向于认为复制是最快最可靠的解决方法。