SQL Server (2012) non bloquante LDD?

Question

Je ne suis pas très expérimenté avec SQL Server, alors peut-être je manque quelque chose

Ma situation est la suivante:

• Session 1 exécute une instruction CREATE TABLE (ou d'autres déclarations CREATE) avec auto-validation et l'CREER n'est pas comitted.
• Session 2 exécute une instruction de sp_table mais se bloque aussi longtemps que la session 1 ne commet pas le DDL

Le scénario où cela se produit est développeurs travaillant sur la base de données. Certains d'entre eux parcourant les tables, certains d'entre eux faisant DDL. Si un utilisateur oublie de commettre les toutes les autres sessions DDL qui veulent lister les tables sont bloquées. Notez que le sp_tables est émis par exemple par le client SQL (via l'API du pilote JDBC), il est donc pas quelque chose qui peut être changé.

La base de données que je travaille avec a snapshot_isolation activé et le niveau d'isolation est en lecture commis (SET ALLOW_SNAPSHOT_ISOLATION ON et SET READ_COMMITTED_SNAPSHOT ON)

Mon hypothèse était que ces paramètres doivent faire SQL Server mieux se comporter en ce qui concerne le verrouillage en sessions simultanées (par exemple comme PostgreSQL et Oracle où SELECTs ne sont jamais bloqués par un écrivain) - mais apparemment ce n'est pas le cas.

Alors, est-il un moyen de rendre plus SQL Server amical contre les situations de lecture / écriture simultanées en ce qui concerne DDL? (À l'exception de soumettre DDL uniquement en mode auto-commit).

Answer 1

Non, il n'y a aucun moyen de configurer SQL Server pour faire ce que vous voulez faire.

Dans l'isolement de l'appel instantané à sp_tables est bloqué en attente d'une serrure à clé partagée sur l'une des tables de base du système (sysschobjs) lorsque vous faites un SELECT de sys.all_objects

Le En utilisant le thème de niveaux d'isolation à base Versioning Row en BOL ne dit:

SQL Server ne conserve pas plusieurs versions de métadonnées du système. Les données déclarations langage de définition (DDL) sur les tables et autres bases de données objets (index, vues, types de données, procédures stockées et communes fonctions d'exécution de la langue) modifier les métadonnées.

Même sous TRANSACTION ISOLATION LEVEL READ UNCOMMITTED l'appel à des fins de sp_tables en bloquant cependant, tandis que le SELECT ... FROM sys.all_objects avant droit n'est bloqué plus les références même requête la fonction de HAS_PERMS_BY_NAME dans la clause WHERE. Cela semble démarrer une transaction système (CMetadataAccessor::CMetadataAcce) à un niveau d'isolation supérieur et finit par être bloqué en attente d'une serrure à clé partagée sur sysschobjs à nouveau.

Answer 2

Une idée: planifier un travail toutes les 15 secondes pour regarder pour DDLs UNCOMMITED ralenti et mettre fin à des sessions et les rool retour

.