Как SQL Server знает, как заблокировать объекты просмотра?

В SQL Server 2008 у меня есть представление V над столами A а также B это выглядит примерно как

create view V as
    select * from A
    union all
    select * from B

Чтение из V заставляет запрос принимать намеренные общие блокировки для базовых таблиц, но также принимает намеренную общую блокировку для самого объекта представления.

Понятно, зачем нам нужны блокировки IS для таблиц, и мы видим, что блокировка IS в представлении предотвращает одновременное изменение таблиц, лежащих в основе представления. Все в порядке.

План запроса не содержит упоминания о представлении. Он полностью скомпилирован, и в этом случае полученный план представляет собой простую конкатенацию строк из двух базовых таблиц. Действительно, единственное упоминание о представлении в плане запроса XML содержится в тексте оператора.

Если вы добавите второй вид U за столами, чтение из V не вызывает блокировку U, Это исключает, что двигатель просто берет блокировку IS на все просмотры A а также B,

Как ядро ​​базы данных узнает, как заблокировать представление?

  • Текст заявления снова анализируется?
  • Есть ли какой-то другой канал информации между планировщиком запросов и базовым исполнением для передачи этой информации?

Смотрите соответствующий вопрос наdba.stackexchange для дальнейших деталей.

Источник

3 ответа

Копирование из моего ответа на dba.stackexchange:

От Конора Каннингема, основного источника всего, что связано с движком или оптимизатором:

Мы отслеживаем вещи во время компиляции, чтобы проверить во время выполнения. Мы не разбираем вещи при исполнении для этой цели.

Примечание: внутренняя часть того, что мы делаем из одного выпуска в другой, не гарантируется. Это ниже официально поддерживаемой площади поверхности.

Я считаю, что двоичная версия плана выполнения (не та, которая доступна для чтения и предоставляется нам через XML, которая является лишь подмножеством двоичной версии), должна содержать некоторый указатель на представления, на которые ссылается исходный запрос текст (и это было упомянуто выше). Очевидно, он не разбирает текст запроса каждый раз. Conor подразумевает то же, что и выше, но старается не раскрывать какие-либо подробности о том, где и как это хранится, поскольку это может потенциально меняться от выпуска к выпуску или даже с пакетом обновления или накопительным обновлением. Он, вероятно, также не хочет поощрять какую-либо детективную работу.:-)

Источник

Если вы посмотрите на sys.dm_exec_query_optimizer_info В представлении, возвращающем сведения об оптимизаторе запросов SQL Server, одним из возвращаемых сведений является следующее поле:

ссылка на представление - количество обращений к представлению в запросе.

Казалось бы, сколько раз ссылка на представление отслеживается где-то, возможно, как часть плана выполнения... я предполагаю, что даже если представление расширяется, план выполнения все еще содержит детали того, какие представления использовались в запрос и выдает соответствующие IS блокирует эти ссылочные взгляды.

Источник

По умолчанию представления расширяются, как макрос, в запросы, которые на них ссылаются.

Это можно отключить или изменить, если они материализованы и т. Д., Но макроподобное inline-расширение является нормой. Это означает, что блокировка и т. Д. Ведет себя так, как будто вы сделали следующее...

SELECT
  *
FROM
  blah
INNER JOIN
(
  yourViewCode
)
  AS aView
    ON aView.id = blh.id
Источник
Другие вопросы по тегам