Discussion :

[cestpasmoinonplus]

Mais en creusant, je me rend compte d'une autre donnée du problème :
Le soft qui écrit les données, écrit dans plusieurs tables chaque seconde.
Je me rend compte qu'en SELECtant l'une de ces tables, je freeze (comme dit précédemment) toutes ces tables avec les mêmes "trous".
Il y a un effet de synchronisation.
Les écritures se faisant toutes via le même thread, le fait de faire un nolock sur le SELECT d'une seule de ces tables le rend peut-être inopérant (ou pas ?).

[cestpasmoinonplus]

Je change d'angle d'attaque :

je me rends compte que les lignes écrites après une période de freeze, ne sont pas les lignes qui auraient dû être écrites s'il n'y avait pas eu de freeze.
Question naïve : N'y a t-il pas de bufferisation par SQLServer des ordres arrivants ? Peut-être une gestion de timeOut ?
Si oui y a t-il possibilité de le paramétrer ?

[cestpasmoinonplus]

Ok, j'ai la confirmation que ma transaction est bien lancée en isolation SNAPSHOT.

Ce qui f... la m...., c'est l'écriture en série dans un certain nombre de tables.
Lorsque le SELECT commence, SQLServer n'écrit plus dans aucune de ces tables.
et les lignes envoyées à l'écriture par mon soft pendant cette période de "freeze" sont perdues. Quand SQLServer se remet à écrire, je me retrouve avec ces trous dans mes écritures.
Reste à savoir si cette perte est due à mon appli ou à SQLServer.

[SQLpro]

C'est votre application qui déconne. Jamais SQL Server ne "perds de l'information" sans renvoyez un message d'erreur, même en cas de crash (message d'erreur du middleware.

+

[cestpasmoinonplus]

Oui, je ça vient peut-être des composants utilisés dans l'appli (ou de la façon de les utiliser).
Je suis en train d'essayer avec d'autres.

Bon ben, après essais :
lorsque je lance le SELECT en SNAPSHOT ou pas en SNAPSHOT, sur l'une des 5 tables qui reçoivent une demande d'écriture chaque seconde et qui contiennent 17 million de lignes,
Les écritures sur les 5 tables sont gelées par blocs de plusieurs secondes jusqu'à la fin du select.

Les écritures étant lancée par une appli, et le select par une deuxième appli.
Quels que soient les composants utilisés, dont les Firedac avec lesquels il facile de manipuler les niveaux d'isolation de chaque transaction. Le résultat est le même.


Alors peut-être une limite matérielle du serveur ?

[cestpasmoinonplus]

Donc en fait, pour finir:
is_read_committed_snapshot_on suffit pour "presque régler" le problème. Pas besoin de mettre la base de données en enable SNAPSHOT.
Ce n'est pas suffisant, mais c'est vrai que la différence de freeze sur les écritures est énorme.

[Kropernic]

Pour réellement tester, je ferais une base de données de tests que je gaverais de données jusqu'à avoir à peu près le même volume que votre db qui pose problème.

Ensuite, en restant dans SSMS (donc en m'affranchissant du paramètre hasardeux qu'est l'application), créer un script qui effectue les insertions chaque seconde (une boucle infinie et on en parle plus).

Ensuite, dans une autre fenêtre de script, le select qui va bien. Là vous saurez.

Car en l'état des explications, ce que je comprends c'est qu'il y a un applicatif tiers qui fait partie du schmilblick. Or vous rejetez la faute du SQL Server mais rien n'est moins sûr