Pregunta

Yo no soy muy experimentado con SQL Server, así que tal vez me estoy perdiendo algo

Mi situación es la siguiente:

  • Sesión 1 se ejecuta CREAR una TABLA (o de otras instrucciones CREATE) con confirmación automática de apagado y el de CREAR no es ser realizadas.
  • Sesión 2 se ejecuta un sp_table declaración pero se cuelga como el tiempo de la sesión 1 es no cometer el DDL

El escenario en el que esto sucede es que los desarrolladores que trabajan en la base de datos.Algunos de ellos exploración de las tablas, algunos de ellos haciendo DDL.Si un usuario se olvida de cometer el DDL todas las demás sesiones que desee de la lista de las tablas están bloqueados.Tenga en cuenta que el sp_tables es emitida por ejemplo,por el cliente de SQL (a través del controlador JDBC API), así que no es algo que se puede cambiar.

La base de datos con la que estoy trabajando tiene snapshot_isolation habilitado y establecer el nivel de aislamiento para leer cometido (SET ALLOW_SNAPSHOT_ISOLATION ON y SET READ_COMMITTED_SNAPSHOT ON)

Mi hipótesis es que estos ajustes deben hacer que SQL Server se comportan mejor con respecto a la de cierre en las sesiones simultáneas (por ejemplo,como PostgreSQL y Oracle donde Selecciona nunca son bloqueados por cualquier escritor) - pero al parecer este no es el caso.

Así que, ¿hay alguna manera de hacer de SQL Server más amistoso contra simultáneas de lectura/escritura de situaciones con respecto a los DDL?(aparte de la presentación de DDL sólo en el modo auto-commit).

¿Fue útil?

Solución

No hay ningún modo de configuración de SQL Server para hacer lo que quieres hacer.

En el aislamiento de instantánea de la llamada a sp_tables se bloquea a la espera de una clave compartida bloqueo en una de las tablas base del sistema (sysschobjs) cuando se realiza una SELECT de sys.all_objects

El Con Versiones de Fila basado en los Niveles de Aislamiento tema en el BOL dice:

SQL Server no mantener múltiples versiones de los metadatos del sistema.Datos DDL (lenguaje de definición) declaraciones en las mesas y otras bases de datos objetos (índices, vistas, tipos de datos, procedimientos almacenados, y común lenguaje de funciones de tiempo de ejecución) cambio de metadatos.

Incluso bajo TRANSACTION ISOLATION LEVEL READ UNCOMMITTED la llamada a sp_tables termina el bloqueo sin embargo, mientras que la recta hacia adelante SELECT ... FROM sys.all_objects ya no se bloquea la misma consulta hace referencia a la HAS_PERMS_BY_NAME función en el WHERE la cláusula.Este aparece para iniciar un sistema de transacción (CMetadataAccessor::CMetadataAcce) en un mayor nivel de aislamiento y termina recibiendo bloquea en espera de una clave compartida de bloqueo en sysschobjs de nuevo.

Otros consejos

Una idea: Programe un trabajo cada 15 segundos para buscar DDL no comunicados inactivos y terminar las sesiones y recurrirlas.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a dba.stackexchange
scroll top