Discussion :

[Drezounet218]

Bonjour,

je me permet de créer ce post car je n'ai pas trouvé de réponse dans ce forum. J'ai bien trouvé ca : http://www.developpez.net/forums/sho...napshot&page=2

Mais ca ne réponds pas bien a ma problématique

Donc voila mon soucis :
J'ai une appli avec plus de 500 utilisateurs, et je suis souvent soumis a des interblocage. J'ai mis la base en isolation level Snapshot.

Tous mes select passent par des procedures stockées. Dans mes storeproc critiques j'ai placé des :

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

Par contre je rencontre un petit soucis :

j'ai une store proc qui va faire un select dans une vue. Mais la vue se bloque et il faudrait mettre l'isolation level au niveau de la vue directement.

J'ai vu qu'il etait possible de spécifier le mode de blocage directement sur le select en faisant un :

select * from t with(NOLOCK)

Mais dans mon cas, ce n'est pas le mode NOLOCK que je souhaite, mais le mode snapshot.

Je dois donc modifier ma vue avec des parametres supplémentaires, mais je ne sais pas lesquels choisir.

Merci d'avance

[SQLpro]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

est un paramétre de session. Inutile donc de le mettre à chaque objet, il suffit de démarrer votre connexion en laçant préalablement cet ordre SQL avant toute chose...

Attention cepandant aux effets pervers :
1) le niveau snapshot consomme beaucoup de ressource notamment dans la tempdb
2) le faite que vous ayez des blocages peut être lié à une mauvaise utilisation des niveaux d'isolation, mais plus surement à un très mauvais style de développement, par exemple l'usage de curseur, des transactions inutiles et longues, le faible recours aux requêtes, une programmation lourde côté client, l'absence de procédures stockées, un usage intensif de curseurs... etc !

A +

[Drezounet218]

Merci d'avoir pris le temps de me répondre

1) le niveau snapshot consomme beaucoup de ressource notamment dans la tempdb

Ca j'en avais une petite idée, mais c'est un risque a prendre. Il y a 2 serveur sql en mirroring (mode haute accessibilité) dédiés. Pour 500 utilisateurs c'est largement suffisent normalement

2) le faite que vous ayez des blocages peut être lié à une mauvaise utilisation des niveaux d'isolation,

Ca c'est fort possible. Actuellement j'utilisais aucun niveau d'isolation. J'ai été confronté a des interblocages donc je me suis dit : Chouette je vais pouvoir tester quelque chose de neuf

mais plus surement à un très mauvais style de développement

,

C'est possible, mais je pense pas que ce soit le probleme

par exemple l'usage de curseur

Je n'utilise les curseurs que tres rarement (dans des procédures stockées complexes uniquement). Par contre, je ne connais pas d'autre moyen pour parcourir une table que les curseurs ( coté base de données)

des transactions inutiles et longues

Le temps de transaction dépends du temps des requetes Je fais enorméméent de traitement coté base de données, ce qui normalement devrait diminuer la durée totale du traitement.

le faible recours aux requêtes

une programmation lourde côté client, l'absence de procédures stockées

Je possede 0 Ligne de SQL dans mon code. Uniquement des appels a des procedure stockées (meme les select)
Le seul temps de latence que ca occasionne est le temps liée a la réflexion pour remplir dynamiquement les parametres des procédures (je développe en C#)