lock table aléatoire

Bonjour à tous,

le principe de ma requête est de remplir une table de "stockage" avec les nouvelles données récoltées et uniquement les nouvelles:

je précise que les tables ma_tmp_table et ma_table ont une structure identique.

Code:

---

1 2 3 4 5

insert into ma_table (....) select .... from ma_tmp_table a (nolock) left outer join ma_table b (nolock) on a.id=b.id where b.id is null

---

il arrive parfois que cette requête s'auto locke, et le verrou ne saute jamais.

si je fais une table temporaire (#tmp) intermédiaire avec la même structure:

Code:

---

1 2 3 4 5 6 7 8 9

insert into #tmp (....) select .... from ma_tmp_table a (nolock) left outer join ma_table b (nolock) on a.id=b.id where b.id is null;   -- puis   insert into ma_table (....) select .... from #tmp

---

je n'ai jamais de pb

une idée :calim2:

Votre requête est stupide... En effet mettre du NOLOCK alors que vous faites une mise à jour ne sert à rien, sinon qu'a retarder le serveur !!!!

L'utilisation inconsidéré des tags de requête est généralement mauvais.

Si vous faites une mise à jour, alors le NOLOCK (qui signifie est ignoré, mais le temps de passer du SELECT à l'UPDATE vous pouvez vous auto bloquer.

je constate hélas que beaucoup de développeurs sont fan du NOLOCK et ils en mettent partout sans comprendre à quoi ça sert. or c'est d'une parfaite stupidité.

Mieux vaut piloter une transaction au niveau d’isolation READ UNCOMMITTED, ce sera nettement plus cohérent !

A +

Citation:

---

Votre requête est stupide...

---

il faudra le dire à microsoft car c'est une requête écrite par un expert must VIP très fort et le meilleur de microsoft SARL France (et oui MS est une SARL en France..), facturé a 2000 euros la journée et qui est sorti il y a tout juste un an de l'EPITA avec mention honneur du jury :mrgreen:

mis a part cela, si je me souviens de mes cours sur sysbase (l'ancêtre de SQL server) à dallas il y a 20 ans presque, le code:

Code:

---

1 2 3 4

INSERT INTO ma_table (....) SELECT .... FROM ma_tmp_table a (nolock) LEFT OUTER JOIN ma_table b (nolock) ON a.id=b.id WHERE b.id IS NULL

---

normalement, créé une table temporaire dans la tempDB avec le select puis reprend en faisant l'insert dans la table de destination a partir de cette table ?
donc si une MAJ a eu lieu sur la table de destination entre temps on peut avoir un lock si on mets un nolock

d'où, au final, il faut faire le insert select sans les nolock et en readuncommited ?

Citation:

---

Envoyé par serge0934

il faudra le dire à microsoft car c'est une requête écrite par un expert must VIP très fort et le meilleur de microsoft SARL France (et oui MS est une SARL en France..), facturé a 2000 euros la journée et qui est sorti il y a tout juste un an de l'EPITA avec mention honneur du jury :mrgreen:

---

vous voulez sans doute parler de la SSII créée par Microsoft et non de MS France... car MS France, ne fait aucune prestation !
Cette SSII a les mêmes problème que n'importe quelle autre SSII : trouvez des petit jeunes sorti de l'école pour éviter de les payer cher et vendre le plus cher possible un service pas toujours à la hauteur.

Et le fait d'être sortit de l'EPITA ne veut rien dire, car la formation en matière de SGBDR est loin d'être au top dans la plupart des écoles d'ingé... je sais de quoi je parle car hélas j'enseigne dans deux écoles et mes audits me montre sans arrêt les bétises que de tels intervenants soit-disant compétent vous mettent en place sans réfléchir !!!

Citation:

---

Envoyé par serge0934

mis a part cela, si je me souviens de mes cours sur sysbase (l'ancêtre de SQL server) à dallas il y a 20 ans presque, le code:

Code:

---

1 2 3 4

INSERT INTO ma_table (....) SELECT .... FROM ma_tmp_table a (nolock) LEFT OUTER JOIN ma_table b (nolock) ON a.id=b.id WHERE b.id IS NULL

---

normalement, créé une table temporaire dans la tempDB avec le select puis reprend en faisant l'insert dans la table de destination a partir de cette table ?
donc si une MAJ a eu lieu sur la table de destination entre temps on peut avoir un lock si on mets un nolock

d'où, au final, il faut faire le insert select sans les nolock et en readuncommited ?

---

Entre Sybase et SQL Server il y a eu au moins trois récritures complètes du moteur... Donc vos cours Sybase...

READ UNCOMMITTED ne servira non plus à rien car votre requête fait de la mise à jour.
Dès qu'une requête fait der la mise à jour il est impossible de ne pas mettre de verrou... Au contraire il est indispensable d'en mettre un exclusif !

Or en faisant cette action stupide de vouloir descendre au niveau le moins bloquant, vous vous auto bloquez !!!! Les lectures sans verrous étant inconsistante, lorsqu'il constate qu'il doit finalement faire une mise à jour sur la même table qu'il lit il pose un verrou de lecture. Mais si l'update a déjà placé un verrou exclusif, alors il y a échec par auto blocage !

Conclusion supprimez tout ce genre de merde, évitez d'utiliser des tags (quel qu'ils soient) dans vos requêtes et s'il le faut commencez vos transactions par un :
SET TRANSACTION ISOLATION LEVEL
avec le niveau souhaité.
Lisez l'article que j'ai écrit à ce sujet pour comprendre ce que vous devez faire :
http://sqlpro.developpez.com/isolation-transaction/

En tout cas, je suis ravi d'apprendre qu'un mec nul est payé aussi cher, parce qu'en général je suis entre 900 et 1200 € HT jour.. Donc je vais augmenter mes tarifs...
Et je lui souhaite longue vie à ce type, parce qu'il plus il fera de conneries, plus il va m'en donner du boulot !!!
Moi il m'a fallu plus de 5 ans pour devenir bon (je suis MVP SQL Server depuis 8 ans maintenant, c'est à dire expert reconnu par MS Corp...)
Alors vous pensez un p'tit rigolo qui sort de l'école. C'est sûr qu'il maitrise SQL Server en un claquement de doigt !!!

A +

merci spq pro,

Citation:

---

En tout cas, je suis ravi d'apprendre qu'un mec nul est payé aussi cher, parce qu'en général je suis entre 900 et 1200 € HT jour.. Donc je vais augmenter mes tarifs...
Et je lui souhaite longue vie à ce type, parce qu'il plus il fera de conneries, plus il va m'en donner du boulot !!!
Moi il m'a fallu plus de 5 ans pour devenir bon (je suis MVP SQL Server depuis 8 ans maintenant, c'est à dire expert reconnu par MS Corp...)
Alors vous pensez un p'tit rigolo qui sort de l'école. C'est sûr qu'il maitrise SQL Server en un claquement de doigt !!!

---

tout a fait d'accord :ccool:

pour l'anecdote, j'ai déjà vu une SSII noius envoyer un jeune DBA qui ne connaissait que le monde microsoft et donc pas le monde IBM, pour gérer une base HRaccess sur DB2 sur AS400 :lol: