Martin P. Davies Ответов: 1

Может ли кто - нибудь помочь ускорить мою массовую вставку SQL? Он замедляется, чем больше становится стол...


Всем Привет,

Мне было интересно, может ли кто-нибудь дать какой-либо совет по использованию класса C# SqlBulkCopy. Я гуглил эту проблему, но думаю, что мои потребности довольно специфичны.

По сути, я выполняю преобразование базы данных из старой базы данных Paradox в SQL Server 2008. Я использую OdbcReader и SqlBulkCopy для передачи данных. Это работает нормально, за исключением того, что чем больше строк вставляется, тем скорость вставки резко снижается. Начнем с того, что процесс загружает 000 строк в секунду, но к тому времени, когда мы достигаем, например, 200 000 строк, он вставляет менее 100 в секунду.

На данном этапе в таблице вообще нет индексов.

Есть ли что-то, что я могу смыть, или есть лучшая техника для достижения этого?

Кодовый блок ниже.

С уважением,
Мартин.

public void BulkLoad(String TableName, OdbcDataReader Reader) {
            System.Data.SqlClient.SqlBulkCopy bulkCopy = new System.Data.SqlClient.SqlBulkCopy(ConnectionString, SqlBulkCopyOptions.TableLock);
            bulkCopy.DestinationTableName = TableName;
            //bulkCopy.SqlRowsCopied += new SqlRowsCopiedEventHandler(OnSqlRowsCopied);
            //bulkCopy.NotifyAfter = 10;
            bulkCopy.BatchSize = 5000;
            bulkCopy.BulkCopyTimeout = 0;

            try {
                bulkCopy.WriteToServer(Reader);
            }
            catch (Exception ex) {
                throw ex;
            }
            finally {
                bulkCopy.Close();
                Reader.Close();
            }
        }

TheyCallMeMrJames

в таблице назначения нет триггеров, не так ли?

Martin P. Davies

Нет, ничего подобного. Таблица буквально создается непосредственно перед вызовом этого метода с помощью только определений столбцов, никаких триггеров, первичных ключей или индексов, применяемых в этот момент.

Martin P. Davies

Кстати, я также играл со свойством BatchSize, но на самом деле это не имеет никакого заметного значения.

DaveAuld

Становятся ли журналы транзакций на целевом сервере настолько большими, что дисковое пространство на машине полностью потребляется, что приводит к остановке операций подкачки на жестком диске и всем целевом сервере? (у меня это было в SQL-ящике, который обрабатывал средство просмотра тревожных событий с тысячами записей в час.)

Martin P. Davies

Привет, даво, спасибо за предложение. Я был бы удивлен, если бы это было так, я сейчас тестирую только одну таблицу за раз, и в ней всего 500 000 строк. Кроме того, если вы остановитесь и перезагрузитесь, он снова ускорится. Хотя спасибо за предложение, я посмотрю на него.

Elina Blank

Вам нужно использовать SqlBulkCopyOptins.TableLock? Можете ли вы попробовать вариант по умолчанию там?

Martin P. Davies

Привет, Элина, спасибо за предложение, я изменил все эти настройки - на самом деле единственная причина, по которой он сейчас установлен в TableLock, заключается в том, что кто-то другой предположил, что это может помочь сделать его быстрее...

1 Ответов

Рейтинг:
0

Martin P. Davies

На самом деле это не ответ, но я думаю, что это может быть как-то связано со скоростью читателя в конце парадокса. Единственный способ, который мне удалось обойти, - это заранее программно разбить таблицы Paradox на 100 000 таблиц строк.

Это, по крайней мере, устраняет экспоненциальное замедление. Таблица с 500 000 строк теперь занимает около 15 минут, а не час, а таблица с миллионом строк теперь занимает 30 минут, а не почти 4 часа.

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

На самом деле это не ответ как таковой, но передача базы данных теперь, по крайней мере, намного быстрее.