проблема тупика сервера sql на одной таблице - PullRequest
0 голосов
/ 08 апреля 2010

У меня есть одна таблица, скажем, "ххх" в SQL Server 2000. Один .exe вставляет данные в эту таблицу "xxx" через задание sql. Но как только данные вставлены, одна хранимая процедура считывает данные из этой «таблицы xxx» и вставляет / обновляет в две другие таблицы, а также обновляет статус в той же самой таблице «xxx». Теперь клиент говорит, что в этой таблице «ххх» происходят множественные взаимоблокировки. Пожалуйста, любезно кто-нибудь sdvice мне шаги решения, которые должны быть предприняты, чтобы решить эту проблему тупика и как идентифицировать это шаг за шагом .............

Спасибо заранее ..... XXX

Ответы [ 3 ]

5 голосов
/ 08 апреля 2010

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

Так что применяйте общие правила Сокращение тупиков SQL Server :

  • Убедитесь, что структура базы данных правильно нормализована.
  • Каждый раз иметь доступ к объектам сервера приложений в одном и том же порядке.
  • Во время транзакций не разрешать ввод данных пользователем. Соберите его до начала транзакции.
  • Избегайте курсоров.
  • Сделайте транзакции как можно короче. Одним из способов решения этой проблемы является сокращение количества циклов между вашим приложением и SQL Server за счет использования хранимых процедур или хранения транзакций в одном пакете. Другой способ сократить время, необходимое для завершения транзакции, - убедиться, что вы не выполняете одни и те же операции чтения снова и снова. Если вашему приложению необходимо считывать одни и те же данные более одного раза, кэшируйте их, сохраняя их в переменной или массиве, а затем перечитывайте их оттуда, а не с SQL Server.
  • Сократить время блокировки. Постарайтесь разработать свое приложение так, чтобы оно захватывало блокировки в самое позднее возможное время, а затем снимало их в самое ближайшее время.
  • Если необходимо, уменьшите эскалацию блокировки, используя ROWLOCK или PAGLOCK.
  • Рекомендуется использовать подсказку NOLOCK, чтобы предотвратить блокировку, если блокируемые данные изменяются не часто.
  • При необходимости используйте как можно более низкий уровень изоляции для подключения пользователя, выполняющего транзакцию.
  • Рассмотрите возможность использования связанных соединений.
0 голосов
/ 09 апреля 2010

Из моего опыта работы с Sql Server 2000 лучший способ избежать тупиковых ситуаций - это ограничить параллелизм внутри запроса. Это можно сделать, добавив оба запроса (вставка и SP) или просто добавив параметр подсказки (Maxdop 1) в конце запроса

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

0 голосов
/ 09 апреля 2010

Вы можете попытаться применить подсказку к запросу, который читает строки: с (updlock, holdlock). Попробуйте создать кластерный индекс, который будет использоваться на этапе выбора, если у вас его нет. Если возможно, попытайтесь сузить количество строк, обрабатываемых в транзакциях.

Можно ли сначала обновить строки в таблице, а затем заполнить другие таблицы? В случае ошибки вы можете откатить транзакцию.

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

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