SSIS2012错误的数据类型和大小对性能影响以及Unicode与非Unicode转换问题

浏览: 2230

开篇介绍:

 前几天在SSIS2012上操作发现两个问题。

 1.包的数据量过大导致在SSIS做包的修改操作特别慢,打开包的控件操作,等了几十秒才弹出编辑框。对于开发人员来说,这绝对是不能忍的。当时我就差砸电脑了。

 2.源数据是Unicode类型,到目标非Unicode类型转换问题,这个地方是个细节。

下面谈谈如何处理以上两个问题:

 a.问题一的原理以及优化方法        b.问题二示例以及解决方案


详细介绍:

问题一:包的操作界面特别卡。

数据流的任务大多数实在内存中完成,所以非常消耗内存资源。消耗内存这点是无法避免的。可以从在允许的范围内,减少内存的消耗这角度来优化性能。

a.数据流中不要有不用的列数据:SSIS使用内存缓冲区来完成工作的,因此数据行的宽度越小,加载到缓冲区的数据行数也就越多。

b.定义大型输入源的数据类型时,使用最接近的大小和精度来转换:如果不需要多余的安全缓冲垫,则不要为文本文件中的每列使用默认50的字符

c.只在必要的时候进行数据换:有时候数据源的部分数据在数据流会被丢弃,不要对被丢弃的数剧进行转换。

d.使用映射文件,转换为与目标最接近的类型:如果把值转换为不支持目标的类型,映射的时候,SSIS又会额外的转化一次

注:在大批量处理的情况下,数据类型的问题可能成为至关重要的问题。


问题二:Unicode与非Unicode转换问题

典型示例:从Excel导入数据到数据库表中,报错信息如图。

将Excel数据源导入到一个非Unicode字段定义目标表CARRIER_PAY中。因为默认情况下Excel数据会被导入为Unicode(右击Excel源,高级编辑—》输入属性和输出属性 可以看到数据被导成Unicode),而目标是非Unicode。所以目标映射的时候会提示数据不兼容。

    CREATE TABLE [dbo].[CARRIER_PAY](
[Carrier_ID] [varchar](50) NULL,
[Carrier_Name] [varchar](50) NULL,
[Carrier_Amount] [money] NULL
) ON [PRIMARY]

Clipboard Image.png

解决方案:SSIS需要有针对性的转换和强制转换操作。只需要在中间添加一个数据转换控件把DT_WSTR和DT_R8转换成DT_STR和DT_CY即可。如图

Clipboard Image.png

完整展示界面:

Clipboard Image.png


附加:NULL和非Unicode的秘密

           在表达式中代码如下:当保存带有NULL值的非unicode数据时,将会在SSIS报错。

substring([MyColumn], 1, 1)=='A' ?  NULL(DT_STR, 255, 1252):[MyColumn] --DT_STR是非unicode数据类型

解决办法:针对性的强制转换下,文章中间也有提到过。

substring([MyColumn], 1, 1)=='A' ?  (DT_STR, 255, 1252)NULL(DT_STR, 255, 1252):[MyColumn] --DT_STR是非unicode数据类型


原因:表达式函数返回的默认是Unicode数据类型,当然可以重写数据类型。但是如果重写成非Unicode,那么针对以后的每个操作都需要对该字符串进行转化,很不方便。解决上述问题的经验就是保持结果是Unicode类型,值强制转换成非Unicode类型.(可能比较抽象看不明白,上个图说明下)

实例:值强制转换成了非Unicode,但结果还是保持Unicode

Clipboard Image.png


总结:

 这两个问题看似很小,而且往往容易忽略。但是到项目开发结束上线的时候,发现数据量多了或者与业务程序的开发人沟通忽略了定义表结构数据类型细微差异,才发现这些细节导致了不容忽视的问题。可能就是重新修改,延期。细节决定成败啊。




推荐 1
本文由 粽子job 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

1 个评论

实用性很强哇~

要回复文章请先登录注册