在我们的报告中，我们首先谈到的是再也不能用元数据服务来保存SQL Server包了。这些包应该在你升级之前被移动到SQL Server存储区(在msdb数据库中)或者结构化存储文件中。我们将DTS包保存在SQL Server的msdb数据库中。
SQL Server 2000 DTS设计组件
当你想要修改新移植的可能包含SQL Server 2000 DTS遗留组件的综合服务包的时候就会碰到这个问题。记住：不是所有的DTS组件都可以映射到SSIS组件。假如你在升级还是卸载最新的SQL Server 2000，丢失了2000 DTS开发环境的时候会发生什么情况?你可以在升级或者卸载SQL Server 2000之前或者之后，通过安装从微软的下载中心通过网络下载的“SQL Server 2000 DTS 设计组件”来保留或者重新存储这些组件。
Active X脚本代码 / DTS 对象模型
升级顾问提醒说，假如有一个或者多个含有访问DTS对象模型的Active X脚本代码。SQL Server 2005综合服务(SSIS)包移植想到不会将访问DTS对象模型的ActiveX脚本代码移植过去。在移植之后，我们必须手工修改SSIS包来重新存储先前的包行为。
传统的DTS包移植策略
基于升级向导生成的报告，我选择了通过包移植向导将传统的DTS包进行移植。即使这个包被移植，并且在2005下面作为SSIS的包来进行使用，在最终产品中仍然存在几个问题，如下所示：
步骤1：调用包移植向导
包移植向导可以通过几种方式来调用。我选择从商务智能开发套件中启动移植向导，这个套件将在本文其它部分涉及。从BIDS启动向导可以让我们将DTS包移植到SSIS包文件中。这个文件可以在BIDS中打开，进行测试，假如必要的话还要重新构建，最后被部署。我使用Project Migrate DTS 2000 Package菜单选项打开了移植向导。在第一个菜单中让我提供包含了我想要移植的DTS包的SQL 2000 实例。下面是移植向导的屏幕截图：
选择包含了我们想要移植的2000 DTS包的数据库实例环境?
新移植过来的 SSIS (.dtsx) 文件放在哪里?
选择要移植的 DTS 包
步骤2：重新构建传统的SSIS包
即使是DTS包已经完成移植了，我们仍然无法利用SSIS的特性，也无法遵循SSIS内嵌的设计理念。既然SSIS支持如此庞大数量的预制转换，为什么不试试避免外部调用存储过程呢?例如，包可以重新设计一下，利用查找任务来替代调用存储过程来完成任务。还有，Slowly Changing Dimension 向导可以用来替代对存储过程的调用。
评论加载中…
 |