Здравствуйте!

Сразу приношу извинения, если где-то такой вопрос был. Честно искал, но не нашел.

Обновляются данные в поле типа varbinary(max).

Если использовать .WRITE часто происходит зависание запроса.

Примеры запроса

update [dbo].[Contents] set content .WRITE(0x7786515865154786515575894577865158651568,null,null) where .....

На более свежих MS SQL WRITE вроде работает хорошо.

Есть ли возможность сделать нормальную работу WRITE в версиях 2005 и 2008 или это неисправимо?

Заранее спасибо за ответ!

На одно и то же оборудование ставились разные версии и из backup'а поднималась база.
Выполнялся один и тот же запрос.
На 2005-2008 происходили зависания, на версии старше, 2016, нет.

Мне кажется это не такой сложный запрос (без курсоров, CTE и т.п.), который надо мониторить.

Просто update с заменой или конкатенацией или stuff работает тоже хорошо.

Вот что показывает профилёр

Для запроса типа

Content=Content+0x15

CPU 405
Reads 645634
Writes 25073
Duration 1446


Для запроса

Content .WRITE(0x15,null,null)

CPU 13728
Reads 40388114
Writes 1363810
Duration 29898


Причём второй пришлось останавливать, он так и не выполнился

Версии серверов такие

2005 SP2
9.0.3033

2008 SP3
10.50.6000

Сейчас тестирую на 2008
sp_who2 показывает UPDATE

План запроса попробую, т.к. сколько будет висеть и выполниться ли вообще не известно

В общем вот что получается.

В наследство достались две базы с таблицами с BLOB данными.
Одна на 1 тер, вторая поменьше, гигов 300.
В первой данные были типа image, перевели на тип varbinary
Во второй таблицу пришлось переносить в другую файловую группу.
При попытки дозаписи данных в varbinary методом WRITE наблюдалось зависание запроса.
При восстановлении на другом сервере в MS SQL 2005 и 2008 зависание оставалось, при восстановлении в 2016 запрос выполнялся быстро.
Оставили зависший запрос на ожидание (на меньшей базе). Через полчаса он выполнился. И, вроде, после этого WRITE стал корректно отрабатываться и на рабочей базе и на восстановленных копиях в 2005 и 2008 серверах MS SQL.

Т.е. проблема как бы решена, надеюсь, но хотелось бы понять суть происходящего.
Где-то читал про то, как MS SQL сохраняет такие данные в страницах, возможно связано с этим, а в 2016 подкорректировали.
Если кто знает о чём-то подобном, буду благодарен за информацию.

30 минут выделялось место для записи одного байта?

Просто INSERT и UPDATE без WRITE за секунду записывает несколько мегабайт.
Вот нашёл статью такую

http://improve.dk/what-is-the-size-of-the-lob-pointer-for-max-types-like-varchar-varbinary-etc/

Возможно связано с переформированием указателей. Но это просто предположение.

Продолжение истории, если кому интересно...

Ситуация стала повторяться, оказалось что всё это связано с обновлением статистики.
Написано понятно вот здесь

https://switch-case.ru/54269883

У меня почему-то открывается странно этот сайт, вот выдержка

https://switch-case.ru/54269883 На данный момент мы просто отключили автоматическое создание статистики для этой таблицы, но мне интересно, действительно ли это самая лучшая практика.


Согласно комментарию Microsoft на this Connect item , да, это так.


В SQL Server 2012 поведение было изменено таким образом, что UPDATE Table SET x.WRITE больше не запускает создание статистики. Другие типы запросов могут по-прежнему приводить к созданию статистических данных, поэтому отключение автоматической статистики по-прежнему может быть правильным.


Теперь понятно почему в старших версия это не проявлялось, т.е., как и было озвучено в теме, есть прямая зависимость от версии.