SSIS 包中的"ROW PER BATCH"和"MAX INSERT COMMIT SIZE"是否有任何保留?



我有SSIS软件包,该软件包将包含1000万个记录的2.5 GB数据导出到SQL Server数据库中,该数据库中有10个分区,包括主文件组。

更改默认值之前最大插入提交大小即" 2147483647"和每批次行。使用快速负载选项完成了7分钟的转换。

但是,在用某些公式将其置一些不错的值之后,执行仅在2分钟内完成。

fyi- DefaultMaxBufferrows & DefaultMaxBuffersize 在两个方面(即10000和10 MB)中都是默认值。

要计算最大插入提交大小&每批

使用以下量化。

1)计算出正在传输的源的记录长度。大约在1038字节。

CREATE TABLE [dbo].[Game_DATA2](
    [ID] [int] IDENTITY(1,1) NOT NULL, -- AUTO CALCULATED
    [Number] [varchar](255) NOT NULL, -- 255 bytes
    [AccountTypeId] [int] NOT NULL, -- 4 bytes
    [Amount] [float] NOT NULL,-- 4 bytes
    [CashAccountNumber] [varchar](255) NULL, -- 255 bytes
    [StartDate] [datetime] NULL,-- 8 bytes
    [Status] [varchar](255) NOT NULL,-- 255 bytes
    [ClientCardNumber] [varchar](255) NULL -- 255 bytes
)

2)每批行= packate_size/bytes/record = 32767/1038 = 32 oft。

3)最大插入提交大小=包装尺寸 *交易数= 32767 *100 = 3276700(包装材料的大小和数字交易是可变的)

问题:

  • 每批行和最大插入提交大小的行是否有相关性?由于在存档文章中没有提到用于调整DFT(数据流任务)执行的信息。

  • 这些配置与DefaultBuffermaxzie和
    一起起作用defualtbuffermaxrows?如果是如何?

这些参数仅参考仅具有快速加载模式的DFT OLE DB目标。ole db目标在快速加载中发出 insert bulk命令。这两个参数通过以下方式控制它:

  • 最大插入提交大小 - 控制单个批次中插入多少数据。因此,如果您将麦克风设置为5000,并且有9000行,并且在前5000个结果中遇到了错误,则整个5000批次将回滚。MISC等于批量插入Transact-SQL命令中的批处理参数。
  • 每批行 - 仅是查询优化器的提示。其值应设置为实际预期行数。RPB将rows_per_batch参数等于批量插入transact-sql命令。
    指定麦克风的值将产生一些效果。每个批次都复制到交易日志中,这将导致其快速增长,但具有在每批后备份该事务日志的能力。另外,如果您在目标表上有索引,那么大批批次会对内存产生负面影响,如果您不使用表锁定,则可能会有更多的阻塞。

批量插入(Transact -SQL) - 此命令上的MS文章。

defaultBufferMaxsize defaultBufferMaxrows 控制DFT本身内部的RAM Buffer Management,并且对上述选项没有干扰。

每批次行 - 此设置的默认值为-1,指定所有传入行将被视为单个批次。您可以更改此默认行为,并将所有传入的行分为多批。允许的值仅是正整数,该整数指定批处理中的最大行数。

最大插入提交大小 - 此设置的默认值为'2147483647'(4个字节整数类型的最大值),该值指定一旦成功完成后,都将承诺所有输入行。您可以为此设置指定一个正值,以指示将对这些记录进行提交。您可能想知道,更改此设置的默认值将使数据流引擎上的开销几次提交。是的,这是事实,但与此同时,它将释放交易日志和tempdb的压力,以在大容量数据传输期间特别生长。

以上两个设置对于提高tempdb和事务日志的性能非常重要。例如,如果将"最大插入提交大小"留在默认值中,则交易日志和tempdb将在提取过程中继续增长,如果您要传输大量数据这您的提取将失败。因此,建议根据您的环境将这些值设置为最佳值。

注意:上述建议是根据过去几年与DTS和SSIS合作的经验进行的。但是,正如在还有其他影响性能的因素之前指出的那样,其中之一是基础架构和网络。因此,您应该在将这些更改放入生产环境之前进行彻底的测试。

亲爱的harsimranjeet singh;

根据我的个人经验,rows_per_batch确定OLEDB_DESTINATION必须从DFT组件中收到的每批行计数,而DFT组件确定了DFAULTBUFFERMAXROWS确定DFT的BACTH尺寸,因此DefualtBufferMaxrows依赖于SSIS和Rows_per_batch的规范,每个都必须设置自己的条件。

还会在命中编号时确定记录的数量,然后在日志文件中写入,然后任命;减少这个数字,增加了介于日志的数量,这是不好的,但它导致MSDB(系统db)没有充气,并且非常适合提高性能。

另一点是必须将fefualtbuffermaxrows和Deafultbuffersize之间的关系,必须将其设置在一起。defultbuffermaxrows乘以每个记录的大小必须大致等于deafultbuffersize,如果它更大,则SSIS将其降低到达,如果它较小,并且小于最小的缓冲尺寸,则增加它以触摸最小缓冲区的大小。这些操作严重降低了包装的性能。

祝你好运!

相关内容

  • 没有找到相关文章

最新更新