我们有一个设计得很糟糕的日志表，我们想向其中添加功能。问题在于，这已经是可扩展性的噩梦，我们想在添加设计之前对其进行修复，但我们只有每晚的升级窗口才能完成。
我看过很多有关SQL Server各种批量复制选项的文章，声称“我们可以在10分钟内移动8000万行！”但是到目前为止，我的测试还远远不够，我想就如何改善所见所闻提出建议。
在升级之前，总是有完整的备份。我只对最终结果感兴趣，并且不需要大量的事务日志。我也不想花太长时间，也不想用事务日志或临时文件浪费磁盘空间。
表已经存在了一段时间，因此在我们更大的客户数据库中，该表已经超过5000万行。每行大约为350-400字节。列是这样的
IdentityColID int, [type] int, [subtype] int,
created datetime, author nvarchar(100), Message nvarchar(max)
设计的问题是
主集群密钥为(type, subtype, created, identitycolid)，因此这是一场噩梦。到处都是方块拆分。甚至进行SELECT COUNT(*)也要花费8分钟。
没有好的索引来支持所需的查询类型
我想创建一个新的表，该表的主要聚集索引为IdentityColId，并添加索引以支持必要的查询类型，然后将现有数据复制并拖放到旧表上。
到目前为止，我尝试将数据bcping出来，然后导入
bcp的出口大约需要25分钟，而进口的全部大约需要1.3小时-大约1.5小时。使用Recovery Model Simple，事务日志没有增长，但是大多数时候CPU消耗在60-65％的范围内。
我尝试仅使用T-SQL INSERT INTO NewTable SELECT * FROM OldTable，但是即使使用Recovery Model Simple，事务日志也会达到100 gig。
我尝试将SSIS数据导入包与from / to模型一起使用，并且净时间约为1小时20分钟。使用简单的恢复模型，事务日志保持很小。
然后，我尝试了一个SSIS执行Sql任务包，以有效地在SSIS中执行INSERT INTO NewTable ...行。这样可以将执行时间降低到大约1:15，但是无论采用哪种恢复模式，尽管cpu消耗保持适度，事务日志最终还是达到了约100 gig。
我希望最终结果是一个新表，所以我读过的一些文章中建议将其并行化为多个结果表，这似乎不是一条有益的道路。但是到目前为止，我似乎无法从我已阅读的文章中获得这些统计数据。
有人对我该如何做一点建议？