Discussion :

[JauB]

Bonjour les amis,
J'avoue que j'ai beaucoup lu sur ma problématique, mais je ne sais pas encore quelle démarche suivre ...
Alors, mon problème c'est que j'ai des fichiers textes contenant des requêtes SQL et qui doivent être exécutées en mode transactionnel. Ces fichiers sont déposés au niveau d'un répertoire qu'une application doit lire et quand elle trouve pas exemple 3 fichiers alors elle les ouvrir en même temps et exécuter les requêtes qu'ils contiennent.
Une précision : Les requêtes contenues dans ces fichiers travaillent sur les mêmes tables avec des UPDATE, SELECT, INSERT ... mais sur des lignes différents. Disons par exemple que chaque fichier contient des requêtes sur un client différent des autres clients (des autres fichiers). Compte tenu de la lenteur d'exécution, je me dis que certainement lorsque les requêtes du 1er fichier se lanceent alors toutes les autres requêtes des autres fichiers restent en attente jusqu'à ce que la 1ere transaction, chose que je trouve dommage vu les requêtes en attente n'auront pas à travailler sur les lignes manipulées par la 1er requête !!
Est ce qu'il y a moyen d'utiliser par exemple les niveau d'isolation pour palier à tout ça ?

Merci d'avance

[Babyneedle]

Bonjour,

Les modifications de données n'offrent pas la même flexibilité d'isolation que les lectures. C'est normal puisque la base ne peut accepter de corruption alors qu'une lecture corrompue peut être acceptable pour un certain type de destinataire.

Cela dit, le moteur de MSSQL est suffisamment intelligent (en tous les cas, depuis la version 2000) pour consulter la structure et les statistiques afin d'optimiser les opérations de changement.

Ce qui influence le plus le niveau de parallèlisme c'est l'overlapping (je connais pas le mon français) des index, la finesse de feuilles (leafs) et bien sûr la portée des changements.

Par exemple, prenons deux requêtes.

Code :

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

1
2
UPDATE matable SET status = 666 WHERE type = 1;
UPDATE matable SET status = 777 WHERE type = 2;

En assumant que le serveur possède plusieurs cores ET que l'instance MSSQL soit configurée pour permettre un certain niveau de parallèlisme ET qu'il n'existe qu'un index clustered sur un clé primaire abstraite et un index sur la colonne 'type', ces deux requêtes pourraient rouler en parallèle, à part bien entendu au niveau du IO et du LOG.

D'ailleurs, pour tout apprendre sur ce sujet, je vous suggère ma bible.

Donc, il n'y a pas vraiment de magie qui s'opère.

Je te suggère de faire une trace afin de constater la succession des opérations. Tu pourras y voir si certaines requêtes attendent après d'autres requêtes et combien de temps elles sont attendu.

Aussi, il serait bien de faire une trace des deadlocks. En plus de contrarier le resultat des requêtes, les deadlocks peuvent sérieusement compromettre la performance.

Ou encore, il existe peut-être des index qui sont peu nécessaires.

PS C'est pas un peu dangereux de faire confiance à des requêtes SQL dans des fichiers déposés dans un folder? Pourquoi ne pas utiliser du message queuing?

[SQLpro]

Tout dépend de l'indexation de vos tables. SI vous n'avez ni clef primaire ni index adéquat, la seule manière de faire des mises à jour est de bloquer de manière exclusive la table.
En mettant les bon index dans chaque table, le verrouillage ne s'effectuera que sur les bonnes ligne.
Par exemple si votre fichier traite le client n°140 et un autre le client 128 et que vous avez mis des index sur le n° du client dans chaque tables, alors les deux processus peuvent être lancé en parallèle.

A +