Процесс импорта максимизирует память SQL

Question

У меня есть процесс импорта, который работает как служба Windows (режим отладки как приложение), и он обрабатывает различные XML-документы и CSV-файлы и импортирует их в базу данных SQL. Все было хорошо, пока мне не пришлось обрабатывать большой объем данных (120 тыс. Строк) из другой таблицы (как я это делаю с документами xml).

Теперь я обнаружил, что использование памяти сервером SQL достигает точки, в которой он просто зависает. Мое приложение никогда не получает тайм-аут с сервера, и все просто останавливается.

Я все еще могу делать вызовы на сервер базы данных отдельно, но этот поток приложения просто застрял без очевидного потока в SQL Activity Monitor и без активности в Profiler.

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

Базовая архитектура - c # 2.0, использующая NHibernate, поскольку данные ORM извлекаются в реальную логику c # и обрабатываются, а затем направляются обратно в ту же базу данных вместе с журналами в другие таблицы.

---

Единственная другая проблема, которая иногда возникает вместо этого, заключается в том, что по какой-то причине курсор открывается на этой массивной таблице, и я могу только предположить, что он генерирует из ADO.net оператор, такой как exec sp_cursorfetch 180153005,16,113602,100 в соответствии с Profiler

вызывается тысячи раз

Answer 1

Когда вы COMMIT получаете данные? Есть ли блокировки или тупики (sp_who)? Если 120000 строк считается большим, то сколько оперативной памяти использует SQL Server? Когда приложение зависает, есть ли что-то в точке его зависания (INSERT, поиск SELECT или что?)?

Мне кажется, что размер коммита слишком мал. Обычно в задачах SSIS ETL я буду использовать размер пакета 100 000 для узких рядов с количеством источников более 1 000 000, но я никогда не опускаюсь ниже 10 000 даже для очень широких рядов.

Я бы не использовал ORM для больших ETL, если преобразования не являются чрезвычайно сложными с большим количеством бизнес-правил. Тем не менее, учитывая большое количество относительно простых бизнес-преобразований, я бы рассмотрел возможность загрузки данных в простые промежуточные таблицы и использования T-SQL для выполнения всех операций вставки, поиска и т. Д.

Answer 2

Поскольку вы переписываете его в любом случае, вы можете не знать, что вы можете вызывать BCP напрямую из .NET через класс System.Data.SqlClient.SqlBulkCopy. См. эту статью для получения некоторой интересной информации о перфорации.

Answer 3

Я обнаружил, что nHibernate создает курсор на большой таблице. Я еще не понимаю, почему, но в то же время я заменил модель доступа к большим таблицам с прямыми вызовами ado.net

Answer 4

Добавление к ответу StingyJack ...

Если вы не можете использовать прямой BCP из-за требований к обработке, рассматривали ли вы возможность выполнения импорта на отдельный SQL Server (отдельный блок), используя инструмент, а затем запустите BCP?

Ключом к выполнению этой работы будет поддержание чистоты промежуточной машины, то есть никаких данных, кроме текущего рабочего набора. Это должно снизить использование оперативной памяти до уровня, достаточного для работы импорта, поскольку вы не работаете с таблицами - я полагаю - с миллионами записей. Конечным результатом будет одно представление или таблица во второй базе данных, которую можно легко перевести на BCP в реальную после завершения всей обработки.

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

Мне приходилось делать это с каким-то очень большим и сложным собственным импортом, и в прошлом это работало хорошо. Дорого, но эффективно.

Answer 5

Вы запускаете это в SQL с помощью BCP? Если нет, журналы транзакций могут не поспевать за вашим вводом. На тестовом компьютере попробуйте переключить режим восстановления в Простой (без регистрации) или использовать методы BCP для ввода данных (они обходят регистрацию Т)