Discussion :

[aieeeuuuuu]

C'est surtout que ça pourrait expliquer la situation : les données que vous voyiez entre 8h et 11h n'étaient pas validées, et ont été annulée. ça expliquerait aussi les timeout : les données non validées maintenant les verrous, cela pouvait bloquer d'autres requêtes.

[stephz]

Oui, j'avais compris.
Je ne m'attendais néanmoins pas à perdre toutes ces données

Merci

[SQLpro]

Je suppose que la plupart de vos requêtes utilisent imbécilement le tag "WITH (NOLOCK)" !

ha pétard, j'avais pas vu les remarques de mes collègues... J'avais ouvert la page il y a plusieurs heures...

A +

[SQLpro]

L’utilisation du NOLOCK (comme du READ UNCOMMITTED ce qui revient au même) et une aberration en production.
Ceux qui prônent cela sont des imbéciles qui n'ont rien compris aux SGBDR et ne savent pas du tout quel sont les conséquence que cela entraine.
En effet NOLOCK ne veut pas dire "je ne verrouille pas les données". NOLOCK signifie, lit moi les données, même s'il y a des verrous. Un SGBDR verrouille toujours même en lecture d'une manière ou d'une autre.
L'utilisation du NOLOCK à 3 conséquences :

1. lire potentiellement plusieurs fois les mêmes informations (ainsi dans un dataset, la même ligne peut revenir plusieurs fois alors même que vous avez une clef primaire !!!)
2. oublier de lire certaines lignes
3. présenter des données qui ne sont pas validées par la transaction et peuvent disparaître en cas de ROLLBACK.

Faire porter un traitement quelconque de données dans ce genre de cas ne peut que conduire à rendre la base de données totalement incohérente, même si vous faites des transactions partout.

Le NOLOCK ne devrait être utilisé que dans certaines cas très particuliers :

• échantillon quelconque de données d'une table
• statistiques grossières sur un volume important de données
• tests divers

Dans tous les autres cas cela peut être catastrophique et celui qui a mis en place cela devrait être lourdé immédiatement !

En général ceux qui préconisent cela, ont rencontré des problèmes de verrouillage et au lieu d'analyser le problème et de le rectifier se sont dit que c'est la faute à SQL Server et que cela irait mieux avec le NOLOCK.

Il existe beaucoup de solution pour minimiser les verrous à commencer par, et dans l'ordre :

• faire un modèle de données normalisé (cela conduit à un grand nombre de table ayant un petit nombre de colonne). À lire : https://blog.developpez.com/sqlpro/p...mances_petites
• mettre en place les index adéquat et retirer les index inutiles
• faire des transactions les plus fines possibles
• utiliser un verrouillage optimiste (niveau d'isolation SNAPSHOT) au lieu du verrouillage pessismiste par défaut de SQL Server
• ...

A +