所以我有这张表:
CREATE TABLE [Snapshots].[Crashproof](
[EmoteCountId] [int] IDENTITY(1,1) NOT NULL,
[SnapshotId] [int] NOT NULL,
[Emote] [nvarchar](42) NOT NULL,
[EmoteCountTypeId] [int] NOT NULL,
[Count] [decimal](19, 6) NOT NULL,
CONSTRAINT [PK_SnapshotsCrashproof] PRIMARY KEY CLUSTERED ([EmoteCountId] ASC) ON [PRIMARY],
CONSTRAINT [FK_SnapshotsCrashproof_Snapshots] FOREIGN KEY ([SnapshotId]) REFERENCES [Snapshots].[Snapshots] ([SnapshotId]) ON DELETE CASCADE,
CONSTRAINT [FK_SnapshotsCrashproof_EmoteCountTypes] FOREIGN KEY ([EmoteCountTypeId]) REFERENCES [dbo].[EmoteCountTypes] ([EmoteCountTypeId])
) ON [PRIMARY]
GO
这个代码插入其中:
using (SqlBulkCopy bulkCopy = new SqlBulkCopy(connection, SqlBulkCopyOptions.Default, trans))
{
bulkCopy.DestinationTableName = "Snapshots.Crashproof";
bulkCopy.ColumnMappings.Add(new SqlBulkCopyColumnMapping("SnapshotId", "SnapshotId"));
bulkCopy.ColumnMappings.Add(new SqlBulkCopyColumnMapping("EmoteCountTypeId", "EmoteCountTypeId"));
bulkCopy.ColumnMappings.Add(new SqlBulkCopyColumnMapping("Emote", "Emote"));
bulkCopy.ColumnMappings.Add(new SqlBulkCopyColumnMapping("Count", "Count"));
using (IDataReader reader = ObjectReader.Create(emoteCountTypesToSnapshot))
{
bulkCopy.WriteToServer(reader);
}
}
它在99.99%的时间内运行良好(并且每分钟都进行批量复制),但是我确实遇到过一次异常,它出现在最后一行(bulkCopy.WriteToServer(reader);
):
违反PRIMARY KEY约束...无法在对象“Snapshots. Crashproof”中插入重复的键。重复的键值为(247125)。
我知道不推荐直接在final表中进行批量插入,我将修改代码,将其批量插入到临时表中,然后从那里插入。但这是导致此异常的原因吗?
我真的不明白一个重复的键怎么会出现在一个标识字段上:|
2条答案
按热度按时间yfjy0ee71#
我的建议是使用ETL产品来完成这类任务。他们为你组织一切,只是做这样一个干净的工作。与批量复制和存储过程和制作临时表(我做了多年)周围的混乱对我来说是如此丑陋。
过去几年我一直在使用Pentaho Kettle,并且完全爱上了它。这项任务只需要我几分钟,或者不到一分钟就可以完成,并且完成了所有的繁重工作,从一个地方到另一个地方,在一大堆数据中理智地移动/转换数据。
我知道这不是对你问题的直接回答,但如果有人在工作中问我这个问题,我会立即建议你。
66bbxpm52#
这可能是大容量复制上的争用条件。
如果我没有理解错的话,您每分钟都在运行一次批量复制,是的,大多数情况下它都能正常工作,但根据您尝试插入的批处理大小,它将花费超过一分钟的时间。
因此,假设。它可能发生折叠一个大容量复制到另一个试图在同一时间插入具有相同键的记录,导致违反主键约束。