Проблема с вставкой записей с нескольких компьютеров в одной базе данных одновременно в SQL Server 2005

Question

У меня есть веб-портал, разработанный в ASP.NET, в котором мы просим клиентов вводить данные. При нажатии кнопки отправки все, что я сделал, просто прочитал данные и назвал хранимую процедуру, которая вставляет ее в таблицу. В SQL Server 2005 проблема возникает, одновременно вставляя данные с нескольких компьютеров. Мы протестировали в нашей лаборатории три компьютера, в результате мы получили данные, вставленные успешно только на одной машине, а на двух других машинах мы получим ошибку на странице.

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

Спасибо, Манодж

Answer 1

Вы могли бы хотеть рассмотреть тупики. Обычно это происходит, когда несколько пользователей одновременно используют хранимую процедуру. Чтобы избежать взаимоблокировки и убедиться, что каждый запрос от пользователя будет успешным, вам потребуется выполнить некоторую обработку во время сбоев обновления, и для этого вам понадобится попытка улова. Это работает только на сервере Sql Server 2005,2008.

DECLARE @Tries tinyint 

SET @Tries = 1 

WHILE @Tries <= 3 

BEGIN 

    BEGIN TRANSACTION 

    BEGIN TRY 

    -- do your insert statement here 

    COMMIT 

    BREAK 
    END TRY 

    BEGIN CATCH 

    SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_MESSAGE() as ErrorMessage 

    ROLLBACK 

    SET @Tries = @Tries + 1 

    CONTINUE 

END CATCH 

END 

Answer 2

Я думаю, это потому, что вы используете транзакции ...

По here:

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

В вашем случае вы протестировали свое приложение, используя 3pc в одно и то же время. Поскольку вы используете транзакцию, если эти пользователи одновременно используют одни и те же ресурсы в вашем db (ваши SP, таблицы и т. Д.), Этот конкретный ресурс будет заблокирован, а другие пользователи не смогут его использовать , если транзакция первого пользователя не выполнена или не совершена.

Вот хорошая статья, которую я нашел: http://omaralzabir.com/linq_to_sql_solve_transaction_deadlock_and_query_timeout_problem_using_uncommitted_reads/

Answer 3

Выраженное в ответ ответ говорит о тупике. Хотя, не было достаточной информации, чтобы предположить это, так что это может быть просто блокировка ожидания ожидания.

Какие ошибки вы видите:

• 1)
  тупиковый жертва 1205 ошибка
  «Server: Msg 1205, уровень 13, состояние 50, строка 1
  транзакций (Process ID 5) было заторможенный на блокировки ресурсов другим процессом и был выбран в качестве жертвы тупика. Перезапустите транзакцию. "?
• 2)
  ошибка тайм-аут
  «Время ожидания истекло. Время таймаута истекло до завершения операции или сервер не отвечает.»

Поскольку тема стартера написана: «Но таблица просто блокирует и отпускает через 5-6 минут», я считаю, что это период для 2), в то время как жертвы взаимоблокировок 1) выбираются и откатываются за 5 секунд ,

Также было упомянуто, что вставки находятся с разных компьютеров. Запросы, выполняемые транзакционными компонентами COM +, по умолчанию будут иметь сериализуемый уровень tx iso, который исключает блокировку, но увеличивает конфликт блокировки (ожидание).

«Я использовал транзакции в хранимой процедуре, а также попытался установить уровень изоляции для READ_UNCOMMITTED, SERIALIZABLE и SNAPSHOT. Кажется, ничего не работает должным образом»

Это больше, чем, вероятно, означает, что ваш дизайн и индексирование не являются «правильными», но SQL Server просто делает свою работу должным образом.

С предоставленной информацией она угадывает игру, чтобы что-то посоветовать.

Избегайте размещения CL-IX (кластерные индексы) в столбцах DML-ed (обновлено, вставлено, удалено). DML для кластеризованных столбцов столбца индекса потребуют блокировок на CL-IX (для перемещения строки) и всех некластеризованных индексов (поскольку уровень листа некластеризованных индексов указывает строки по значению ключа CL-IX)

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

Read "How to resolve blocking problems that are caused by lock escalation in SQL Server" (примечание: это устаревшая статья Для бывшего, вы должны использовать TOP вместо устаревшого ROWCOUNT посоветовал там.).

В SQL Server 2005 и выше, следует учитывать READ COMMITTED СНАПШОТА ОГО уровня ISO, который возможно, когда используется READ COMMITTED по умолчанию.

Answer 4

Как долго длится этот процесс? Возможно, вам нужна серьезная настройка производительности proc, если она вызывает тайм-ауты для других пользователей, пытающихся вставить. Ни один proc не должен блокировать столы в течение 5-6 минут.

Факс: Факс: