Манические таблицы MS SQL

[Dmitry67]

типа sysprocesses...
Вопросов собственно два, они связанные

1. Я стал обращать внимание на то что ингода бывают записи
select * from sysprocesses where spid=blocked
То есть процесс блокировал самого себя
Что это ?

2. Какая вообще consistency у этих таблиц ?
Как я понимаю на самом деле это список в памяти который все время меняется
Когда делается select то... делается копия списка или "по живому" ?
Можно тогда объяснить страныне значения изменениями на ходу ?

[chepackav]

Обратите внимание, что кроме spid в sysprocesses есть еще колонка kpid - т.е. один процесс SQL Server'а может быть расщеплен на несколько threads операционной системы (обычно это многопроцессорных серверах происходит) и при неправильной оптимизации эти threads могут друг-друга блокировать. Я с этим сталкивался года полтора назад, но это был откровенный глюк в SQL Server, который был позже исправлен.

[tengiz]

1. Как уже написал chepackav, при выполнении параллельного плана такие вещи могут наблюдаться. Но только это не глюк, а вполне ожидаемое явление. При параллельном выполнении запроса один поток является диспетчером и ему нужно ждать пока другие выполнят свою работу, отсюда и blocked==spid для потока-диспетчера.

2. псевдотаблицы типа sysprocesses читают внутренние стуктуры данных "по живому", поэтому для минимального ущерба дла производительности, синхронизация при доступе к таким структурам во время сканирования с целью диагостики сведена к абсолютному минимуму. Поэтому никакой row-to-row consistency не гарантируется.

[chepackav]

1. Как уже написал chepackav, при выполнении параллельного плана такие вещи могут наблюдаться. Но только это не глюк, а вполне ожидаемое явление. При параллельном выполнении запроса один поток является диспетчером и ему нужно ждать пока другие выполнят свою работу, отсюда и blocked==spid для потока-диспетчера.

2. псевдотаблицы типа sysprocesses читают внутренние стуктуры данных "по живому", поэтому для минимального ущерба дла производительности, синхронизация при доступе к таким структурам во время сканирования с целью диагостики сведена к абсолютному минимуму. Поэтому никакой row-to-row consistency не гарантируется.

В моем случае это был глюк, т.к. процесс приходилось убивать - возникал deadlock, который самим SQL Server'ом не обнаруживался - проблему исправили в каком-то сервис-паке.

[tengiz]

В моем случае это был глюк, т.к. процесс приходилось убивать - возникал deadlock, который самим SQL Server'ом не обнаруживался - проблему исправили в каком-то сервис-паке.

А Вы не помните номер билда? Такой баг действительно был, но не в релизе, а в одной из бет и был исправлен до выхода продукта. Я что-то не помню, чтобы после релиза нечто подобное ещё раз фиксалось. Хотя могу и ошибаться - прошло уже почти четыре года. Если, конечно, речь идёт о SQL 2000.

[Dmitry67]

thanks et merci
tengiz
Вас видно редко но еще спасибо что отвечате
и друим тоже спасибо

[tengiz]

Вас видно редко но еще спасибо что отвечате

Будут хорошие вопросы, на которые сложно найти ответы в документации - как тот, что начал эту тему - с удовольствием буду отвечать чаще .

[YellowMan]

А вот такой вопрос - как сервер работает с временными таблицами ?
На sql.ru нашли интересную особенность - если в одной сессии создать временную таблицу, а потом в другой сессии в sysobjects поменять ее имя на какое-то другое, таблица становится видна в обоих сессиях. Что происходит в этом случае ?

[Dmitry67]

В смысле, update tempdb..sysobjects set name=... ?

[chepackav]

А вот такой вопрос - как сервер работает с временными таблицами ?
На sql.ru нашли интересную особенность - если в одной сессии создать временную таблицу, а потом в другой сессии в sysobjects поменять ее имя на какое-то другое, таблица становится видна в обоих сессиях. Что происходит в этом случае ?

Я вот с гораздо более неприятной проблемой, связанной с временными таблицами, воюю - у меня периодически пользователи делают достаточно большие выборки во временные таблицы (10 - 100 000 записей), потом с использованием этих данных выполняют запросы к другим таблицам - для ускорения запросов по временным таблицам строятся индексы - вот тут-то и появляется узкое место - у каждого пользователя своя временная таблица, но вот таблица sysindexes в tempdb - одна на всех и при создании индексов пользователи отчаянно блокируют эту таблицу. Как с этим бороться - непонятно.

[Dmitry67]

Сделать постоянную таблицу с колонкой u=@@spid
Эта таблица заменит все временные

[Merle]

Сделать постоянную таблицу с колонкой u=@@spid

И сделать эту колонку первой в кластерном индексе..

[YellowMan]

В смысле, update tempdb..sysobjects set name=... ?

Именно так - попробуйте Только не = а like. Понятно что в реальном проекте такое не попользуешь - слишком рискованно. Просто такой вот занимательный факт.

Насчет sysindexes в tempdb - никак не поборешься Вариант с постоянной таблицей и SPID тоже не всегда проходит - в основном что ты не можешь управлять раздачей SPID и не можешь всегда отследить когда коннект отвалился. Плюс накладные расходы на то чтобы проверить на и удалить старые записи - что само по себе тоже не быстро.

[tengiz]

Вариант с постоянной таблицей и SPID тоже не всегда проходит - в основном что ты не можешь управлять раздачей SPID и не можешь всегда отследить когда коннект отвалился. Плюс накладные расходы на то чтобы проверить на и удалить старые записи - что само по себе тоже не быстро.

Это делается слегка сложнее: в таблице появляется две дополнительные колонки - spid и login_time из соответствующей строки из sysprocesses. Эта комбинация гарантированно уникальна при переиспользовании spid, поэтому никаких проблем из-за невозможности отследить момент отключения нет. Техника работы нехитрая, но, насколько я знаю, довольно популярная.

[Dmitry67]

А я все у tengiz хотел спросить
Если SQL упрямо выбирает full table scan по соображениям эффективности, орять таки япрямо игнорируя индекс (и часто оказывается прав) то не приводит ли это к засаде с блокировками ?

Это какой то очень неприятный момент
Спасибо