SQL Server вставляет производительность

Есть несколько вещей, которые вы можете сделать:

1) Disable any triggers on this table
2) Drop all indexes
3) Drop all foreign keys
4) Disable any check constraints

Выполнение отдельных операций INSERT всегда будет самым медленным вариантом. Кроме того, в чем дело с @@ IDENTITY - не похоже, что вам нужно отслеживать тех, кто находится между ними.

Если вы не хотите использовать BULK INSERT из файла или SSIS, в ADO.NET есть функция SqlBulkCopy, которая, вероятно, будет вашим лучшим выбором, если вам абсолютно необходимо сделать это изнутри Программа .NET.

Хм, дайте поработать, проверьте счетчики производительности. что ты видишь? Какая у вас раскладка диска? Я могу вставить несколько миллионов строк за 30 минут - точнее, почти сто миллионов строк (финансовая информация в реальном времени, ссылки на 3 другие таблицы). Я уверен, что у вас плохая схема ввода-вывода (т.е. плохая структура диска, плохое распределение файлов)

Выполняете ли вы эти запросы по одному от клиента .Net (т. Е. Отправляете 110000 отдельных запросов на SQL Server)?

В этом случае, вероятно, это задержка в сети и другие накладные расходы на отправку этих INSERT к SQL Server без их пакетной обработки, а не к самому SQL Server.

Обратите внимание на BULK INSERT.

Скорее всего, это ожидание сброса фиксации. Если вы не оборачиваете наборы INSERT в явно управляемую транзакцию, тогда каждая INSERT будет собственной автоматически фиксируемой транзакцией. Это означает, что каждый INSERT автоматически выдает фиксацию, и фиксация должна ждать, пока журнал не станет долговечным (т. Е. Записан на диск). Промывка бревна после каждой вставки происходит очень медленно.

Например, попытка вставить 100 тыс. Строк, подобных вашей, в стиле фиксации одной строки:

set nocount on; 
declare @start datetime = getutcdate();  

declare @i int = 0;
while @i < 100000
begin
INSERT INTO InvoiceDetail (
  LegacyId,InvoiceId,DetailTypeId,Fee,
  FeeTax,Investigatorid,SalespersonId,
  CreateDate,CreatedById,IsChargeBack,
  Expense,RepoAgentId,PayeeName,ExpensePaymentId,
  AdjustDetailId) 
  VALUES(1,1,2,1500.0000,0.0000,163,1002,
    '11/30/2001 12:00:00 AM',
    1116,0,550.0000,850,NULL,1,NULL); 
  set @i = @i+1;
end

select datediff(ms, @start, getutcdate());

На моем сервере это выполняется примерно за 12 секунд. Но при добавлении управления транзакциями и фиксации каждых 1000 строк вставка 100 тыс. Строк длится всего около 4 с:

set nocount on;  
declare @start datetime = getutcdate();  

declare @i int = 0;
begin transaction
while @i < 100000
begin
INSERT INTO InvoiceDetail (
  LegacyId,InvoiceId,DetailTypeId,
  Fee,FeeTax,Investigatorid,
  SalespersonId,CreateDate,CreatedById,
  IsChargeBack,Expense,RepoAgentId,
  PayeeName,ExpensePaymentId,AdjustDetailId) 
  VALUES(1,1,2,1500.0000,0.0000,163,1002,
    '11/30/2001 12:00:00 AM',
    1116,0,550.0000,850,NULL,1,NULL); 
  set @i = @i+1;
  if (@i%1000 = 0)
  begin
    commit
    begin transaction
  end  
end
commit;
select datediff(ms, @start, getutcdate());

Также с учетом того, что я могу вставить 100 тыс. Строк за 12 секунд даже без пакетной фиксации, в то время как вам нужно 30 минут, это стоит изучить 1) скорость вашей подсистемы ввода-вывода (например, сколько Avg. Sec per Transaction вы видите на дисках) и 2) что еще делает код клиента между получением идентификатора @@ из одного вызова и вызовом следующая вставка. Возможно, большая часть времени находится на стороне клиента стека. Одним из простых решений может быть параллельный запуск нескольких вставок (BeginExecuteNonQuery), чтобы вы постоянно подавали вставки SQL Server.

Вы отметили этот вопрос как «bulkinsert». Так почему бы не использовать команду BULK INSERT ?

Если вам нужны обновления прогресса, вы можете разделить массовую вставку на более мелкие части и обновлять прогресс после завершения каждой части.