2012-08-11 62 views
4

我被要求接管刚刚写过的SSIS包的所有权。看起来有可能进入并修改,编辑和升级这个软件包,但它对于软件包的工作量看起来也非常麻烦。将SSIS包转换为.NET应用程序?

我的任务大致是这样的:遍历包,查找特定表中某些特定列的任何用法,更改它们以匹配最新的数据库变更集,并写出一些额外的日志记录数据以帮助团队诊断任何特定问题。

由于SSIS包含大约3兆字节的文本,SQL语句和非常简单(但冗长)的代码路径,所以对我来说这似乎令人望而生畏。我已经花了我一段时间来双击每个SSIS对象并浏览其设置,以查看我是否能够发现我被要求维护的列,并且SSIS一直在抛出连接错误(正确的是,因为我的开发环境被阻止从生产数据库中删除)。

我真的很想考虑将此SSIS包转换为.NET应用程序,但是我一直无法找到任何可以帮助我实现的工具。

有没有人有建议维护这个SSIS包或将其转换为适当的应用程序?

回答

4

回复那些喜欢谁.NET到SSIS

SSIS并不意味着传输数据量小。它可以,但是当数据传输量大到100到500 GB,并且涉及复杂的业务逻辑时,SSIS比.NET更受欢迎。如果有多个数据文件包含多个数据源,那么SSIS就可以走了。 .Net是首选,如果你有小的进口或出口,几乎没有业务逻辑来增强或转换数据

不幸的是,没有工具可以将ssis包转换为.NET应用程序,但有免费的工具可以帮助您你可以在不打开的情况下提供更多有关你的软件包的信息

BI Documentor是一个工具,它为您提供了SSIS包的完整架构。您只需将应用程序指向dtx pkg即可。如果您有许多sql代码和表达式,需要修改的变量,连接管理器,你可以在这个工具的帮助下做到这一点。有时在BIDS中打开一个复杂的ssis包需要很多时间,所以在这种情况下这可能是有用的。

有一个叫SSIS Log Analyser多了一个工具,它可以帮助您在不打开BIDS

+0

谢谢 - 这看起来像我所能得到的一样近。我将检查BI Documentor,看看是否可以提供帮助。 – 2012-08-13 16:27:13

+0

首选谁?我的偏好恰恰相反。 – 2015-01-06 16:07:44

+0

如果它涉及一个*非常复杂的业务逻辑*,那么它肯定不在SSIS中。业务逻辑不应该遍布各处,我曾经看到人们将业务逻辑放在应用程序,程序中,触发器中,而且我不相信现在有人希望在任何地方都有业务逻辑,所以最好将它隔离到一个地方地点。 – Alisson 2018-01-26 13:06:14

0

我不认为有任何具体的工具。只需要使用一些文本编辑器并查看代码并确定需要处理的更改列即可。

个人而言,我不喜欢SSIS,因为它太多了“可视化工具”,并且可能会使用.NET应用程序,但是由于您已经完成了所有工作,并且您可能不想投入你的职业生涯重新构建你已经获得的数据转换工具,只需在SSIS中进行这些更改,使其工作,然后继续你愉快的编程生活......或者甚至更好,找到一些SQL Server管理员为你的,他们喜欢SSIS。

+0

这是沿着我的建议的线路多,我同意你的看法。 – GrayFox374 2012-08-11 05:13:47

5

只是为了好玩,我写一个SSIS反编译调试包。在查看运行Integration Services的Visual Studio的UI并将其与.DTSX文件中的原始XML数据进行比较后,我能够将DTSX文件转换为C#/ .NET项目。

我将这一点与一小部分剖析数据结合起来,通过追踪出现问题的组件,我能够在SSIS包中获得40%的速度提升。

似乎很适合我使用的SSIS包。也许这会帮助别人。

https://github.com/tspence/csharp-dessist

相关问题