Discussion :

[Pfeffer]

Bonjour à tous,

J'ai un problème que je n'arrive pas à comprendre et j'espère que vous allez pouvoir m'aider ...
J'ai un SI avec plusieurs tables structurées de la même manière. Dans chacune d'entre elles je stocke plusieurs versions de ma data.

Coté intégration, j'ai un service Windows qui intègre en multithreading la data dans ces tables dites "splittées".
Dès lors que l'intégration est terminée, toujours en multithreading, je lance une procédure stockée qui intègre dans une table consolidée la version la plus à jour de la data en faisant un simple delete / insert.

Tout fonctionne bien sauf lorsque j'intègre trop de ligne d'un coup (plusieurs milliers). J'ai l'impression que SQL Server me met un lock sur ma table consolidée.
Du coup si j'essaie de faire un simple "select" sur la table consolidée pendant l'insertion ça mouline, je n'ai plus la main ...

Plusieurs questions:
1. Comment voir si j'ai un lock sur ma table ?
2. Pourquoi le lock ne s'activerai que sur des grosses insertions ?
3. Du moment ou je fais du delete / insert je ne devrai pas avoir de problème d'intégrité, est-ce propre de consolider avec le mot clé WITH NO LOCK ?
4. Comment faire du NO LOCK sur un DELETE / INSERT ?

Merci pour vos suggestions

[rudib]

Plusieurs questions:
1. Comment voir si j'ai un lock sur ma table ?
2. Pourquoi le lock ne s'activerai que sur des grosses insertions ?
3. Du moment ou je fais du delete / insert je ne devrai pas avoir de problème d'intégrité, est-ce propre de consolider avec le mot clé WITH NO LOCK ?
4. Comment faire du NO LOCK sur un DELETE / INSERT ?

1. https://blog.developpez.com/babaluga...-sur-une-table
2. à cause du mécanisme d'escalade de verrous. https://blog.developpez.com/elsuket/...ade-de-verrous
3. pourquoi pas, tu risques simplement un phénomène de lectures sales. http://rudi.developpez.com/sqlserver...ation/#LII-D-2
4. impossible, la cohérence des données est en jeu. Les modifications verrouilleront toujours. Tu pourrais jouer avec une désactivation de l'escalade des verrous, mais ce n'est pas une bonne idée, SQL Server risque de consommer beaucoup plus de ressources et tu le sentiras sur les performances.

Quelle est ta version et édition de SQL Server ? In-Memory OLTP pourrait être une option pour toi.

[elsuket]

Bonjour,

Quelle est ta version et édition de SQL Server ? In-Memory OLTP pourrait être une option pour toi.

Si pas SQL Server 2014 Enterprise ou SQL Server 2016 SP1, découper l'insertion en plus petits lots :

• se fait en général dans le même temps
• en limitant voire éliminant l'escalade de verrous
• en évitant un gonflement de la taille du fichier du journal des transactions

@++

[hmira]

j'ai un service Windows qui intègre en multithreading la data dans ces tables dites "splittées".

L'ordre des opérations effectuées à l'intérieur de chaque thread a aussi son importance, il est parfois même capital pour éviter les inter-blocages entre les différentes sessions SQL Server chacune rattachée à un thread différent.

Parfois, dans une transaction, si cela est possible, il faut commencer par mettre à jour les données (INSERT, UPDATE) avant de lire les données (SELECT) etc.
Cela peut apparaître de prime abord surprenant, mais cela devient aisément compréhensible si on maitrise le fonctionnement interne des verrous, de bas niveaux, mis en œuvre pour assurer le caractères ACID des transactions, par exemple dans le niveau d'isolation par défaut READ COMMITTED.

Il faut aussi veiller à ce que les transactions soient les plus "brèves", c.à.d. les plus courtes possibles. Cela rejoint l'idée du "découpage en petits lots" suggérée, à juste titre, par elsuket.

Voilà, n'ayant aucune information détaillée sur la nature de vos traitements multithread, je ne peux vous assurer que cela résoudra votre problème (?) Mais c'est une piste à explorer.

A+