Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Грязное чтение... И тут проблемы )  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Сегодня впервый раз увидел такую ошибку

MsSQL Server 2005
Could not continue scan with NOLOCK due to data movement. [SQLSTATE 42000] (Error 50000). The step failed.


Вообще изначально была куча блокировок в ночных джобах. Было много быдло-кода и если честно там чёрт голову сломит, почерк Индусский, но вроде не они.
Куча данных сначала удаляется, потом вставляется. Я начал смотреть логи по deadlock-ам и постепенно избавлятся от них методом "with(nolock)".

Но как решать вновь появившуюся ошибку ???
18 дек 09, 13:55    [8086617]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Glory
Member

Откуда:
Сообщений: 104760
NIIIK

Но как решать вновь появившуюся ошибку ???

Убирать with(nolock)
18 дек 09, 13:56    [8086632]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Glory,

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

Вероятность deadlock была гораздо больше, а эту ошибку я вижу впервые.
Может мне лучше ничего не трограть, а если скажут "Бла-бла.... очень надо...", то объяснить "либо делаем так, либо работать не будет".
18 дек 09, 14:16    [8086846]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Glory
Member

Откуда:
Сообщений: 104760
И что вы хотите ?
Читать грязные данные так, как будто они не грязные ?
И еще ничего не блокировать при этом ?

Сообщение было отредактировано: 18 дек 09, 14:18
18 дек 09, 14:17    [8086859]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74927
NIIIK
MsSQL Server 2005 Возврат к блокировке.


Откройте, наконец, для себя версионность.

Understanding Row Versioning-Based Isolation Levels
18 дек 09, 14:32    [8086983]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31223
NIIIK
Но как решать вновь появившуюся ошибку ???
select @@version ?

Вроде эту ошибку поправили ещё в 2000-ом...

Ещё попробуйте DBCC CHECKDB
18 дек 09, 14:48    [8087144]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Павел-П
Guest
alexeyvg,

Вообще-то конструкция "with nolock" - это всего лишь затычка для решения вопроса с deadlock-ами.
И не совсем правильная. Необходимо разбираться с причинами deadlock-ов, а не просто тупо везде раставлять "with nolock". Понятно, что это тяжелая и кропотливая работа - но рано или поздно ее все равно прийдется делать.
18 дек 09, 14:53    [8087192]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31223
Павел-П
alexeyvg,

Вообще-то конструкция "with nolock" - это всего лишь затычка для решения вопроса с deadlock-ами.
И не совсем правильная. Необходимо разбираться с причинами deadlock-ов, а не просто тупо везде раставлять "with nolock". Понятно, что это тяжелая и кропотливая работа - но рано или поздно ее все равно прийдется делать.
Почему это затычка для решения вопроса с deadlock-ами???

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

Какой смысл ждать окончания блокировок или загружать сервер работой с версиями данных, да и и тратить ресурсы на обслуживание блокировок, если бизнес-логика этого не требует?

И вы не обосновали, почему считаете правильным разбираться с дедлоками, а не тупо везде раставлять "with nolock". Только потому, что это "тяжелая и кропотливая работа"?

С точки зрения теории потребностей в этом нет.

Жалко, что в сиквеле есть этот баг.
18 дек 09, 15:20    [8087471]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Now password
Guest
Одно дело, когда вы решаете проблемы бизнес - логики применяя разные способы изоляции транзакций, другое дело - когда вы пытаетесь исправить чужие ошибку методом, который для этого не предназначен.
18 дек 09, 15:29    [8087537]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Glory
Member

Откуда:
Сообщений: 104760
alexeyvg
NIIIK
Но как решать вновь появившуюся ошибку ???
select @@version ?

Вроде эту ошибку поправили ещё в 2000-ом...

Ещё попробуйте DBCC CHECKDB

С чего это вдруг документированная ошибка 601 стала багом ???
The SQL Server Database Engine cannot continue executing the query because it is trying to read data that was updated or deleted by another transaction. The query is using either the NOLOCK locking hint or the READ UNCOMMITTED transaction isolation level.

Сообщение было отредактировано: 18 дек 09, 15:36
18 дек 09, 15:35    [8087582]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
-=DiM@n=-
Member

Откуда: Москва
Сообщений: 1564
хммм... я думал NOLOCK'у не страшны никакие другие транзакции. На то оно и грязное чтение.
18 дек 09, 15:40    [8087621]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Павел-П
Guest
alexeyvg,

Конечно, в том случае, если бизнес-логика разрешает чтение - то проблем в этом нет.
Просто причина deadlock-а - это не просто блокировка данных при чтении, это взаимная блокировка разными процессами.

Тут я полностью согласен с пользователем "Now password".
Смотрите комментарий выше.
18 дек 09, 15:47    [8087693]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31223
Glory
С чего это вдруг документированная ошибка 601 стала багом ???
Ну, раз есть фикс, значит, была ошибка :-)

Я имел в всду, что сделали трейс-флаг, который позволяет при удалении данных из очереди при грязном чтении игнорировать эти данные: FIX: Query with transaction isolation level set to READ UNCOMMITTED fails with error 601

Павел-П
alexeyvg,

Конечно, в том случае, если бизнес-логика разрешает чтение - то проблем в этом нет.
Просто причина deadlock-а - это не просто блокировка данных при чтении, это взаимная блокировка разными процессами.

Тут я полностью согласен с пользователем "Now password".
Смотрите комментарий выше.
Ну, конкретно про проблему автора я не могу сказать, затыкание ли это дыр или бизнес-логика позволяет...

Я просто хотел сказать, что если разработчики приняли решение о грязном чтении, то, по логике, оно должно быть грязным, т.е. читается то, что смогло, и читается так, как смогло прочитаться.
18 дек 09, 16:17    [8087950]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Glory
Member

Откуда:
Сообщений: 104760
alexeyvg
Glory
С чего это вдруг документированная ошибка 601 стала багом ???
Ну, раз есть фикс, значит, была ошибка :-)

Я имел в всду, что сделали трейс-флаг, который позволяет при удалении данных из очереди при грязном чтении игнорировать эти данные: FIX: Query with transaction isolation level set to READ UNCOMMITTED fails with error 601

Этот фикс только для одного случая

This behavior may occur when a row in a table is deleted between the time SQL Server reads the location of the row from an index and the time SQL Server fetches the row.

Для остальных же случаев
Also, the trace flag does not affect the fact that other errors and data inconsistencies can occur when reading uncommitted data.
18 дек 09, 16:22    [8087999]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Now password
Guest
Не разработчики должны принимать такие решения... Это уровень архитектора и.т.д... В данном конкретном примере человек просто заткнул дыры кода способом для этого непригодным, не разбираясь в особенностях архитектуры системы, бизнес - логике и.т.д. Он просто пытался решить текущую проблему блокировок единственным изветным ему способом, но на самом деле это неправильно.
18 дек 09, 16:23    [8088006]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31223
Now password
Не разработчики должны принимать такие решения... Это уровень архитектора и.т.д...
"Разработчики" - я, конечно, имел в виду команду разработки.

Glory
Этот фикс только для одного случая

This behavior may occur when a row in a table is deleted between the time SQL Server reads the location of the row from an index and the time SQL Server fetches the row.

Для остальных же случаев
Also, the trace flag does not affect the fact that other errors and data inconsistencies can occur when reading uncommitted data.


Я думаю, что "deleted" в описании симптомов указывает и на изменение...

MORE INFORMATION далее
When trace flag 9134 is turned on and a row is deleted or modified between the time SQL Server reads the location of the row and the time it fetches the row through a bookmark lookup, the query will not abort or return Error 601. Instead, SQL Server ignores the row that cannot be located and it continues to scan for additional rows that meet the query criteria. Therefore, the query execution continues; however, the results that SQL Server returns may not include rows that were deleted or moved during the query execution.
18 дек 09, 16:40    [8088170]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
Glory
Member

Откуда:
Сообщений: 104760
alexeyvg

Я думаю, что "deleted" в описании симптомов указывает и на изменение...

Я не про смысл "deleted" а про "between the time SQL Server reads the location of the row from an index and the time SQL Server fetches the row". Т.е. когда сервер использует индекс и по нему извлекает остальные поля. Но такой план выполнения запроса не является единственно возможным
18 дек 09, 16:43    [8088192]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31223
Glory
alexeyvg

Я думаю, что "deleted" в описании симптомов указывает и на изменение...

Я не про смысл "deleted" а про "between the time SQL Server reads the location of the row from an index and the time SQL Server fetches the row". Т.е. когда сервер использует индекс и по нему извлекает остальные поля. Но такой план выполнения запроса не является единственно возможным
А, ну это да, не спорю...
18 дек 09, 16:55    [8088305]     Ответить | Цитировать Сообщить модератору
 Re: Грязное чтение... И тут проблемы )  [new]
хм....
Guest
Дайте-ка я угадаю, ваше бизнес-приложение это Диасофт 5нт?
18 дек 09, 20:54    [8089372]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить