¿cómo sabe SQL Server para bloquear objetos de vista?

Question

En SQL Server 2008 tengo una visión V sobre tablas A y B que se ve más o menos así

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

lectura de V hace que una consulta a tomar bloqueos compartidos de intención en las tablas base, sino que también tiene un bloqueo compartido de intención en el objeto de vista.

Está claro por qué necesitamos los bloqueos de IS en las tablas, y podemos ver que el bloqueo de IS en la vista impide la modificación simultánea de las tablas subyacentes a la vista. Esta bien.

El plan de consulta no contiene ninguna mención de la vista. Está completamente compilado, y el plan resultante en este caso es una concatenación simple de filas de las dos tablas base. De hecho, la única mención de la vista en el plan de consulta XML está en el texto de la declaración.

Si agrega una segunda vista U sobre las tablas, la lectura de V no causa ningún bloqueo en U. Esto descarta que el motor solo tome un bloqueo IS en todas las vistas sobre A y B.

¿Cómo sabe el motor de la base de datos bloquear la vista?

• ¿El texto de la declaración se analiza de nuevo?
• ¿Hay algún otro canal de información entre el planificador de consultas y la ejecución subyacente para pasar esta información?

---

Véase el corresponding question on dba.stackexchange para más detalles.

Answer 1

De forma predeterminada, las vistas se expanden, como una macro, en las consultas que hacen referencia a ellas.

Esto se puede desactivar, o variar si están materializados, etc., pero la expansión en línea macro es la norma. Esto significa que el bloqueo, etc., se comporta como si se hizo lo siguiente ...

SELECT 
    * 
FROM 
    blah 
INNER JOIN 
(
    yourViewCode 
) 
    AS aView 
    ON aView.id = blh.id 

Answer 2

Si nos fijamos en la vista sys.dm_exec_query_optimizer_info, que devuelve detalles del optimizador de consultas de SQL Server, uno de los detalles devuelto es el siguiente campo:

vista de referencia - Número de veces que un punto de vista ha sido referenciados en una consulta.

Al parecer el número de veces que una visión se hace referencia alguna parte se realiza un seguimiento , posiblemente como parte del plan de ejecución ... mi suposición es que incluso si se amplía la vista, el plan de ejecución contiene todavía detalles de las vistas que se usaron en la consulta y emite los bloqueos apropiados IS con respecto a estas vistas a las que se hace referencia.

Answer 3

Copia desde my answer on dba.stackexchange:

De Conor Cunningham, la fuente última de nada motor-o relacionados con el optimizador:

Hacemos un seguimiento de las cosas durante la compilación en tiempo de ejecución para comprobar. No analizamos cosas en la ejecución para este fin.

Nota: las partes internas de lo que hacemos de una versión a otra no son garantizados. Esto está debajo del área de superficie oficialmente compatible.

Mi creencia es que la versión binaria del plan de ejecución (no el que se puede leer y expuestos a nosotros a través de XML, que es sólo un subconjunto de la versión binaria) debe contener algo de puntero a la vista (s) referenciado en el texto de consulta original (y esto fue aludido arriba). Obviamente, no está analizando el texto de la consulta todo el tiempo. Conor implica todo lo anterior, pero tiene cuidado de no revelar ningún detalle sobre dónde o cómo se almacena, ya que esto podría cambiar de una versión a otra o incluso con un service pack o una actualización acumulativa. Probablemente tampoco quiera alentar ningún trabajo de detective. :-)