Discussion :

[Sergejack]

Bonjour,

Est-ce qu'un l'un d'entre vous saurais me dire, si en SQL Server 2005 lorsqu'on définit une transacton (BEGIN jusqu'au COMMIT/ROLLBACK), le server fait une prélécture de l'ensemble du query pour obtenir les accès (paratagés, exclussifs,....) nécessaire avant de commencer l'opération ou si les accès sont obtenus en cours de route (ce qui serait plus dangereux, niveau deadlock) ?

Merci.

[SQLpro]

Cela dépend du niveau d'isolation que vous choisissez pour la transaction que vous opérez.
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/isolation-transaction/
Un SGBDR n'étant pas un OS, c'est lui qui choisit le type et la granularité des verrous on the fly en fonction de la concurrence et des opérations à réaliser... C'est le rôle du moniteur de verrouillage. Bien entendu vous pouvez forcer les verrous manuellement, mais c'est généralement source des pires contention, puisque le verrouillage n'est plus dynamique !

A +

[Sergejack]

Concrètement, cela veut dire qu'aujourd'hui, il ne faut absolument plus se soucier des deadlocks soi-même ?

[SQLpro]

La possibilité d'obtenir des verrous mortels est lié à trois choses :
1) le modèle de données
2) la consistance transactionnelle
3) la concurrence d'accès

L'obtention d'un deadlock résulte forcément d'une opération concurrentielle lancée sur des objets identiques dont la séquence de verrouillage n'est pas la même. C'est une probabilité au sens mathématique du terme qui résulte des facteurs exposés ci dessus et pour lequel tout repose sur la durée transactionnelle. Plus une transaction dure, plus la probabilité de survenance d'un deadlock augmente.

1) modèle :
Si votre modèle de données respecte à la lettre les formes normale, alors cela signifie qu'aucune anomalie de mise à jour est possible et que le nombre de tuple mis à jour est minimal.
Moins il y a de données à mettre à jour, plus rapide est la transaction.

2) consistance
La durée du traitement augmente en fonction du nombre d'objet présent dans la transaction, de l'étendue des mises à jour à faire et de la nature des mises à jour.

3) concurrence
Plus grand est le nombre d'utilisateur voulant mettre à jour la même ressource, plus probable sera le deadlock.

SQL Server, comme tout ses compatriote analyse en permanence les verrous posés et détecte automatiquement les interblocage. Dès qu'une étreinte fatale survient, il déclenche un ROLLBACK sur le process dont le coût de requête est la plus faible.

A +

[Sergejack]

Le ROLLBACK dont tu parles, est suivit après délais d'une nouvelle tentative ?

[SQLpro]

Absolument pas. C'est à vous de détecter l'erreur et de réagir.

A +

[Sergejack]

Et comment la détecte t'on ?

Par ailleurs qu'appelles-tu les formes normales ?

[SQLpro]

1) détecter une erreur consiste à lire le résultat de la variable globale @@ERROR dans SQL Server ou dans votre gestionnaire d'exception pour votre code client.

2) forme normale : c'est la base de toute modélisation des données d'une base...
Peut être feriez vous bien de vous former aux bases de données, parce que si je dois vous faire un cours sur le formes normales, on est pas sortit de l'auberge. Notez que je le donne au cnam (Arts & Métier), référence NFE113
http://formation.cnam.fr/pdf/ueNFE113.pdf

A +

[Sergejack]

1) Et comment peux-tu savoir que @ERROR provient bien d'une opération ayant eu lieu dans ta transaction (plutôt qu'une autre), puisque cette récupération de @ERROR est forcément extérieur à la transaction échouée ?

2) Je voulais simplement m'assurer de ta terminologie, je pense très bien connaître ce concept auquel tu fais allusion et qui, suivit sans exception, finit parfois par la conclusion "Holala !! Ça m'en fait des jointures dont je pouvais me passer.".

Il va de soi, que ce qui m'importe est, si tu en as l'aimabilité, la réponse à 1) et pas un débat sur 2).

[SQLpro]

@@ERROR est remis à zéro à chaque opération valide. Il faut donc le tester après chaque ordre SQL.
De plus il n'existe jamais qu'une seule transaction. Pas de transaction interne ou externe, cela n'existe pas.

"Holala !! Ça m'en fait des jointures dont je pouvais me passer.".

Une base de données relationnelles est spécialement conçue pour faire des relations d'où son nom. pas des fichier Cobol. Cela conduit effectivement à de nombreuses jointures qui ne posent aucun problème de performances si elle sont bien faites (utilisation systématique de clef autoincrémentées par exemple).
Sachez que la jointures de 20 tables contenant 100 millions de lignes par le biais d'un autoincrément unique ne représente pas plus de 180 IO ce qui somme toute est assez faible.
De plus dans une base de données relationnelles on cherche à minimiser le cout des opérations d'écriture, car :

• elles sont les plus nombreuses
• elles sont les plus bloquantes.

C'est pourquoi la normalisation des relations est absolument essentielle contrairement à une idée stupide largement répandue qui voudrait que faire des jointures c'est pas bon !

A +

[Sergejack]

@@ERROR est remis à zéro à chaque opération valide. Il faut donc le tester après chaque ordre SQL.
De plus il n'existe jamais qu'une seule transaction. Pas de transaction interne ou externe, cela n'existe pas.

Je n'ai jamais employé les mots internes et externes et ce que tu dis m'interpelle fort.
Il n'existe jamais qu'une seule transaction ?
Donc pour toi, deux opérations ne peuvent pas être réalisées en parallèlle en SGDB (ici sql server 2005) ?!

Pour toi, à la fin d'une transaction A il n'est pas possible qu'une autre opération échoue ailleurs avant d'atteindre la ligne de vérification de @ERROR même si celle-ci suit directement la fin de la transaction A ?

[SQLpro]

Dans une même session, il n'y a jamais qu'une seule transaction, même si l'imbrication de transactions est effectué, par exemple dans une procédure qui en appelle une autre, qui en appelle une autre... chaque procédure ayant sa propre transaction.
En effet la nature même d'une transaction, à savoir l'atomicité serait violée par un transactionnement partiel...
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...ns-imbriquees/

Donc pour toi, deux opérations ne peuvent pas être réalisées en parallèlle en SGDB (ici sql server 2005) ?!

Ceci n'a rien à voir avec la notion de transaction. Une transaction, c'est au moins une requête, mais plus généralement n requêtes. Chaque requête est découpée en plusieurs opérations conduisant à un arbre opérationnel (plan de requête). Chaque branche de l'arbre opérationnel peut être exécutée en // de même que certaines opérations dans l'arbre (par exemple la lecture séquentielle d'une table (SCAN)) peut être opérées en //.
De la même façon, deux transactions peuvent parfaitement opérées en // a condition que les verrous soient compatible. Par exemple que les transactions ne soient pas susceptible de poser des verrous incompatibles sur les mêmes ressources en même temps, ou encore que l'on opère en mode SERIALIZABLE.

Encore une fois, un sérieux cours sur les SGBDR est à envisager avant de commencer à vous jeter dedans à l'aveuglette !

A +

[Sergejack]

Je m'y connais.

Par contre la documentation de sql server est vague (microsoft oblige) et vu ta confiance, et bien que tu n'en fasse pas mention, je conclu que @@ERROR est propre à chaque session et non global.

Alors je pose la question est-ce que tu aurais mieux fait de me dire...

@@ERROR est propre à chaque session et comme deux transactions effectuées en parallèlles le sont forcément dans des sessions distinctes, il n'y a pas de conflit possible.

?
Ou cela est-il erroné ?

[SQLpro]

Effectivement @@ERROR, est une variable globale dont la portée est limitée à la session. Par défaut toutes ces variables @@ le sont, sauf mention contraire (par exemple @@CPU_BUSY, @@CONNECTIONS, @@IDLE).

A +

[Sergejack]

Effectivement @@ERROR, est une variable globale dont la portée est limitée à la session. Par défaut toutes ces variables @@ le sont, sauf mention contraire (par exemple @@CPU_BUSY, @@CONNECTIONS, @@IDLE).

A +

Cool, cette fois je peux avancer.

Merci.

[elsuket]

Bonjour,

la documentation de sql server est vague (microsoft oblige)

Extrait de la documentation :

@@ERROR étant effacé et réinitialisé à chaque exécution d'une instruction, vérifiez cette valeur immédiatement après la vérification de l'instruction ou enregistrez-la dans une variable locale de façon à pouvoir la consulter ultérieurement.

@++

[Sergejack]

Oui, c'est bien de cette documentation que je parle.

Et comme il a été dit, ceci est faux.
@@ERROR n'est pas réinitialisé à chaque exécution d'une instruction mais bien à chaque exécution d'une instruction dans la session courrante.

Et, non, cela n'est pas implicite, cela devrait être dit clairement et à cette endroit de la documentation au minimum (donc, peut-être aussi ailleurs).

[elsuket]

Il n'existe tout simplement pas d'instruction multi-sessions en SQL.
Donc je ne vois pas ce qui est faux

@++

[Sergejack]

Il existe des sessions, il existe des instructions.
C'est tout ce qui entre en ligne de compte.

L'existance d'une instruction multisession ou d'une instruction pour faire le café relèverait d'autres considérations.

[elsuket]

Vous le dites vous-même.

@++