Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Блокировки  [new]
Быдло___кодер
Guest
Есть 3 таблички которые одновременно интенсивно и читаются и обновляются пользователями
Запрос, определяющий блокировки показывает что есть длинные цепочки сессий которые ждут друг друга, чтобы что-то поменять. Половина всех сессий ждет другие сессии

Правильно ли я понимаю
1. В MSSQL чтение для уровня изолированности read commited устанавливает блокировку S на считываемые данные и пока запрос на выборку не выполнится, другая транзакция не сможет менять те данные что считывает первая транзакция
2. Если поставить уровень изолированности read uncommited, т.е грязные чтения, блокировки не будет, и по идее это должно помочь с массовыми блокировками?
17 июл 17, 17:43    [20651386]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
Быдло___кодер,

смотрите в сторону RCSI
read uncommited зло :)
17 июл 17, 17:50    [20651421]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
Быдло____кодер
Guest
3. Верно ли, что если я в хранимке сделаю
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
это повлияет только на запросы в хранимке, в целом в сессии все останется по прежнему ?
Опираюсь на эту доку
https://technet.microsoft.com/ru-ru/library/ms173763(v=sql.105).aspx
Если инструкция SET TRANSACTION ISOLATION LEVEL использовалась в хранимой процедуре или триггере, то при возврате управления из них уровень изоляции будет изменен на тот, который действовал на момент их вызова. Например, если уровень изоляции REPEATABLE READ устанавливается в пакете, а пакет затем вызывает хранимую процедуру, которая меняет уровень изоляции на SERIALIZABLE, при возвращении хранимой процедурой управления пакету, настройки уровня изоляции меняются назад на REPEATABLE READ.
17 июл 17, 17:54    [20651440]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
felix_ff
Member

Откуда: Moscow
Сообщений: 1172
Быдло____кодер,

Вам уже ответили. Проблема писателей/читателей в большинстве случаев решается оптимистической моделью управления параллелизмом.

Используя уровень изоляции грязного чтения вы по факту подставляете вторую щеку для шлепка. (причем неожиданного)
17 июл 17, 18:41    [20651634]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
Быдло___кодер
Guest
смотрите в сторону RCSI
read uncommited зло :)


SELECT is_read_committed_snapshot_on, name FROM sys.databases t where t.name='MyDb'

Показывает 1, так что этот режим типа и так включен

Куда вообще копать?
sp_locks выдает 100к блокировок
По коду вроде не видно чтобы кто-то не закоммичивал за собой
17 июл 17, 19:26    [20651764]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
msLex
Member

Откуда:
Сообщений: 7730
Быдло___кодер,

А какие типы блокировок ждут каких?
Если x - x, то ни RCSI ни RU не поможет.
17 июл 17, 19:49    [20651794]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
msLex
Быдло___кодер,

А какие типы блокировок ждут каких?
Если x - x, то ни RCSI ни RU не поможет.

что не поможет? читатели будут читать всегда
18 июл 17, 09:06    [20652401]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
aleksrov
Member

Откуда:
Сообщений: 948
TaPaK,

Я думаю имелось ввиду, что не повлияет на поведение "писателей", которые по прежнему будут пессимистичны при получении U или X
18 июл 17, 09:32    [20652479]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки  [new]
Быдло___кодер
Guest
Решил проблему. Дятел-разработчик написал кривой merge который потихоньку постоянно пересоздавал записи в самой горячей таблице вместо того чтобы их обновлять. В результате вместо апдейта 1 записи был делит 5 и инсерт 5 записей, со скоростью тысячи в минуту
18 июл 17, 19:57    [20655466]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить