批量插入HEAP与CLUSTERED索引,其中最小日志记录不是一个选项(SQL Server 2008)

JSt*_*ead 5 bulkinsert sql-server-2008 informatica-powercenter

当前使用的工具是Informatica,我们有bookend存储过程,它们删除聚簇索引,然后将它们添加回数据库.在我们添加聚簇索引的存储过程中,我们将索引的DDL硬编码到存储过程中(我们不使用sys表,因为担心Microsoft更改sys表并从那里重新生成会产生错误的索引或失败).这会导致人们创建聚簇索引但未考虑更新存储过程的问题,并且下次批量发生时这些索引消失了.我们之前为所有索引执行了此操作,但将非聚簇索引切换为使用禁用/重建.这不是一个选项,因为如果对聚簇索引执行此操作,我们将无法再插入到表中,因为它本质上是表.

表现很重要但不是一切.良好的性能和易维护性胜过卓越的性能和复杂的可维护性.

在阅读了许多网站之后,几乎普遍认为在执行批量插入时,对与主键无关的数据进行排序,插入堆然后应用pk更快(http://msdn.microsoft.com/en -us/library/ms177445.aspx ,http://msdn.microsoft.com/en-us/library/dd425070 (v = sql.100).aspx).大多数这些网站都假设我无法在我的组织和我的工具集中使用.

目前由于我们当前的标准策略,我们必须使用FULL恢复模型,因此无论我在参考堆与聚簇索引时做出哪些选择,都不会发生最小的日志记录.

根据我们的信息管理员,通过UI无法在bcp上指定tablock或命令提示,并且由于可维护性,我们的组织不利于UI之外的自定义.

所有这一切的问题是上面提到的所有因素,你会建议我们继续使用我们有些不可靠的存储过程,插入聚簇索引或者使用第三个更优越的解决方案.我也意识到还存在类似于这个项目的其他堆栈问题,但它们没有专门解决批量问题和/或在答案中做出类似的假设.

Aar*_*and 6

我的建议是批量加载到临时表(堆或符合文件顺序的CI),(重新)构建与目标表匹配的聚簇索引,然后直接从登台表插入.为了减少阻塞,升级,日志使用等,您可以一次批量处理10000行,每隔一段时间进行提交和/或检查点.

您也可以考虑使用预处理器(可能是C#)获取日志文件并使用正确的排序顺序构建新的日志文件.

另外我认为使用sys.indexes等比使用代码中的索引结构进行硬编码更安全.Microsoft在sys.indexes中更改列名的可能性远远低于您商店中的某个人(没有违反意图)将更改索引但忘记更新过程中的硬编码定义.