Предложения о том, как бороться с ошибками запуска приложений из-за длительной транзакции

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

В последнее время мы начинаем получать сообщения от пользователей о том, что процесс передачи данных из мобильного приложения занимает очень много времени.

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

Приложение выполняет множество проверок и поисков при обработке результата перед началом записи в базу данных. Все делается через Entity Framework и обернуто внутри транзакции.

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

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

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

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

2 ответа

  1. Первое, что я бы предложил, чтобы попытаться получить ручку на замки, которые генерируются. начать захват sys.dm_tran_locks etc.

    У вас есть много FKs, индексы и т.д. На вашей БД — вы могли бы рассмотреть вопрос об отключении их, если приложение может быть надежным.

    Или это может быть просто проще к некоторому архивированию — вы можете удалить исторические данные из живых таблиц? чем они меньше, тем лучше.

    В худшем случае-можно создать несколько баз данных (например, 1 на пул приложений) и вручную объединить данные в мастер.

  2. Ваша проблема заключается в том, как клиент использует БД. Из того, что вы сказали мне, клиент блокирует таблицы и предотвращает доступ к ним других вещей.

    Обычно я бы предложил использовать что-то вроде подсказки «with (NOLOCK)» (в зависимости от того, может ли ваше приложение обрабатывать грязное чтение), но поскольку вы используете Entity Framework, я предложу взглянуть на это вместо этого: Get Entity Framework 6 use NOLOCK в своих инструкциях underneath SELECT

    Уровень изоляции на вашей БД будет играть большую роль. Уровни Изоляции

    Я бы предложил вам проверить, как клиент взаимодействует с БД. Операция, которая занимает много времени, это select, insert, update, upsert? Вы его профилировали и видели, в чем проблема? (объясните план etc…)

    Есть ли индекс на таблице. Использует ли запрос индекс?

    Если проблема заключается в проблеме insert / update (upsert), Entity Framework обрабатывает это ужасно. Я предлагаю вам изменить этот код на что-то вроде этого Upsert fast в SQL Server

    Entity framework удобен, но не обеспечивает высокую производительность при обработке больших наборов данных.