Discussion :

[Marco46]

Bonjour,

2 petites questions à propos des transactions.

Le contexte :
Je m'occupe d'un module de transferts de données entre 2 systèmes dont l'un utilisant une BDD SQLServer 2008R2 et l'autre est représenté par des fichiers EDIFACT.
Ce module est découpé en 9 services (un pour chaque flux), chaque flux dispose de sa connexion au SGBD.
Donc soit un service intègre un flux EDIFACT dans une BDD SQL Server, soit il génère un flux EDIFACT à partir de la BDD.

Dans le cas des réceptions, j'ai énormément de requêtes pour intégrer (gestion de stock notamment) tous les éléments du flux EDI en BDD et j'intègre la totalité de ces requêtes dans une seule et unique transaction.

Pour donner un ordre d'idée ça peut aller jusqu'à 50 requêtes de tous types (SELECT, UPDATE, INSERT et DELETE) entre le BEGIN et le COMMIT.

Au niveau du code, nous utilisons Windev (pas le choix :'( ). Mon code appelant au niveau le plus haut est encadré par un équivalent de Try Catch. Le BEGIN est appelé au début du Try, le COMMIT juste en dehors et le ROLLBACK est dans le Catch.
Dans les méthodes de niveau inférieur, toute erreur lève ou est propagée en une exception. On finit donc systématiquement par un Rollback en cas d'erreur.

Le code SQL d'initialisation d'une transaction est le suivant :

Code :

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

BEGIN TRANSACTION;

Le code SQL de fin de transaction est le suivant :

Code :

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

COMMIT TRANSACTION;

Le code SQL de rollback est le suivant :

Code :

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

ROLLBACK TRANSACTION;

Les transactions ne sont donc pas nommées, mais comme chaque service a sa propre connexion cela ne devrait pas poser de problème. Si ?

A l'arrivée, je constate que ça ne fonctionne pas. Lors que j'ai une erreur, les requêtes de modification de la BDD précédant l'erreur sont toujours actives après l'exécution du service.

Quelqu'un aurait-il une piste pour localiser le dysfonctionnement ?

Serait-ce du à l'absence de nommage des transactions ?
Au nombre de requêtes dans les transactions ?
A autre chose que je ne connais pas ?

Voilà. Sinon dernière info le niveau d'isolation n'est pas modifié, il est en READ COMMITTED.

Merci.

[sevyc64]

Le BEGIN est appelé au début du Try, le COMMIT juste en dehors et le ROLLBACK est dans le Catch.

LE COMMIT doit être dans le Try, à la fin juste avant le Catch, car lui aussi peut générer une exception qui doit être traitée par le ROLLBACK

Lors que j'ai une erreur, les requêtes de modification de la BDD précédant l'erreur sont toujours actives après l'exécution du service.

Certainement parce qu'un de tes codes sort mal, n'exécutant ni le COMMIT, ni le ROLLBACK. Une transaction étant toujours en cours les requêtes suivantes sont bloquées.

Après avoir fait les modifs et avant de relancer ton service/executable, pense à aller faire un tour dans SQLServer pour supprimer toutes les transactions et verrous encore en attente.

[Marco46]

Merci pour l'aide.

Je les vois où les informations sur les transactions dans SQL Server Manadgement Studio ?

[sevyc64]

Tu peux utiliser la requete suivante pour avoir la liste des transactions actives sur ta base :

Code :

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

1
2
 
SELECT * FROM sys.dm_tran_session_transactions

[SQLpro]

Bonjour,

2 petites questions à propos des transactions.

1) redéveloppez le tout sous forme de proc stock

2) alimentez les fichiers dans une base "tampon" dans laquelle vous avez reproduit des tables brutes équivalente à vos tables de destination, ou mieux des tables in (proche de la structure de vos fichier) et des tables out (proche de la structure de vos tables de destinations

3) faites tout votre nettoyage de données par des requêtes dans ces tables tampon de IN vers OUT

4) un fois nettoyé désactivez tous les index, sauf ceux sémantiques (clef primaire, contrainte d'unicité...) de toutes les tables concernées avant la mise à jour (ALTER INDEX ... DISABLE), insérez les données de table tampon out à table cible dans la base de prod et remettez les après (ALTER INDEX ... REBUILD).

5) au besoin, ne gérez aucune transaction globale, mais prévoyez de loguer les erreurs des commandes finale pour savoir ou vous en êtes...

A +

[Marco46]

Si je vous suis bien, il me faut une BDD contenant un miroir des fichiers textes EDI, une autre BDD contenant un miroir de la BDD de prod et ensuite gérer les imports en BDD de prod via des procédures stockées et le tout sans transactions ?

Une seule base tampon suffit

Le fait d'effectuer toutes les manipulations depuis le SGBD minimisant l'utilité des transactions ?

OUI

Donc en fait tout le code de contrôle des données se ferait en procédures stockées ?

Oui, c'est ce qui va la plus vite, faire de l'ELT et pas de l'ETL

Je ne comprends pas l'intérêt de désactiver les index surtout que comme je le disais au début de ce post il s'agit d'import quotidien au fil de l'eau, c'est à dire pendant que toute une série d'opérateurs (une vingtaine directement connectés à la BDD et une centaine en mode déconnecté) travaille.

A voir, mais cela permet d'aller très notablement plus vite ! a lire : http://sqlpro.developpez.com/cours/s...ivation-index/[quote]

5) au besoin, ne gérez aucune transaction globale, mais prévoyez de loguer les erreurs des commandes finale pour savoir ou vous en êtes...

A +

[SQLpro]

j'ai écrasé votre message en me trompant de bouton !!!!!

Désolé !

[Marco46]

Pas grave.

Pour le reste je ne peux malheureusement pas refaire cette partie pour des raisons de délais mais je prends note de la méthodologie pour un prochain projet.