none
Test de connectivité dans une transaction. RRS feed

  • Question

  • Bonjour,

     

    Je me permet de vous contacter concernant une problématique de serveur lié, notamment un test d’accessibilité.

    Mon but étant de pouvoir gérer cette erreur d’inaccessibilité afin qu’elle ne remonte pas aux applications.

     

    Je m’explique :

     

    2  serveur ( A et B ) SQL 2008 sont reliés. Le serveur A veux savoir si le serveur B est accessible. J’ai fouillé et trouvé une procédure se chargeant de cela :  sp_testlinkedserver    

    Je fais un test de cette procédure comme suit :

     

    exec sp_testlinkedserver [PROD-17]   -- réseau ok

    Resultat :

    Commande(s) réussie(s).

     

    exec sp_testlinkedserver [PROD-17]   -- réseau coupé

    Resultat :

    Le fournisseur OLE DB "SQLNCLI10" du serveur lié "PROD-17" a retourné le message "Délai d'attente de connexion expiré".

    Le fournisseur OLE DB "SQLNCLI10" du serveur lié "PROD-17" a retourné le message "Une erreur liée au réseau ou spécifique à l'instance s'est produite lors de l'établissement d'une connexion à SQL Server. Le serveur est introuvable ou n'est pas accessible. Vérifiez si le nom de l'instance est correct et si SQL Server est configuré pour autoriser les connexions distantes. Pour plus d'informations, consultez la documentation en ligne de SQL Server.".

    Msg 1231, Niveau 16, État 1, Ligne 0

    Fournisseur de canaux nommés : Impossible d'ouvrir une connexion à SQL Server [1231].

     

    Dans ce  cas, l’erreur remonte à l’applicatif. Normal. Maintenant si je mets cette procédure dans un try / catch :

     

    begin try

          exec sp_testlinkedserver [PROD-17]

    end try

    begin catch

          print 'test'

    end catch

     

    http://img822.imageshack.us/i/17259668.jpg/

     

     

    On remarque que l’erreur a été attrapée par le catch, SQL Serveur considère que la requête s’est exécuté avec succès.

    Maintenant si je souhaite effectué ce test de connectivité  dans une transaction :

     

    http://img338.imageshack.us/i/10627927.jpg/

     

    Le select XACT_STATE() me renvoie -1, ce qui signifie que le statut de la transaction est uncommittable.

     

    Ma question est la suivante : comment faire en sorte que la procédure sp_testlinkedserver  ne « casse » pas la transaction en cas d’inaccessibilité du serveur distant ?

     

    Merci d’avance pour vos réponses.

    mercredi 23 février 2011 13:43

Réponses

  • Il n'y a aucune solution à ce problème. En effet le COMMIT à deux phases résultant d'une transaction distribuée peut s'avérer inconsistant.

    Rien n'empêche un serveur qui a répondu OUI à la première phase du COMMIT de ne pas être en état de valider la transaction lors de la seconde phase de forçage !

     

    A +


    Frédéric BROUARD, Spécialiste modélisation, SGBR relationnel, optimisation, langage SQL * * * Le site sur le langage SQL et les SGBD relationnels : http://sqlpro.developpez.com/ * * * Expert SQL Server http://www.sqlspot.com : audit, optimisation, tuning, formation * * * Le blog sur SQL / MS SQL Server http://blog.developpez.com/sqlpro * * * Enseignant CNAM PACA, ISEN Toulon, CESI/EXIA Aix En Provence
    • Marqué comme réponse Alex Petrescu lundi 28 février 2011 11:07
    mercredi 23 février 2011 23:21

Toutes les réponses

  • Bonjour,

    Le problème est signalé à Microsoft depuis plus d'un an (voir ici).

    En gros, le doute a été présent, l'aide indiquant un retour de 0/1 et le code lançant une erreur qui casse la transaction, et la décision a été prise ... de mettre à jour l'aide et de laisser le fonctionnement actuel !

    Note : Dans la version CTP1 de SQL 2011, l'aide en ligne n'est toujours pas à jour et le fonctionnement est inchangé ... (http://msdn.microsoft.com/en-us/library/ms189809(v=SQL.110).aspx).

    Dans l'état actuel des choses, je n'ai pas de solution pur SQL à vous proposer, mais je suis preneur si vous en trouvez une...

    JN.


    Jean-Nicolas BERGER
    http://blog.sqlserver.fr
    mercredi 23 février 2011 20:09
  • Il n'y a aucune solution à ce problème. En effet le COMMIT à deux phases résultant d'une transaction distribuée peut s'avérer inconsistant.

    Rien n'empêche un serveur qui a répondu OUI à la première phase du COMMIT de ne pas être en état de valider la transaction lors de la seconde phase de forçage !

     

    A +


    Frédéric BROUARD, Spécialiste modélisation, SGBR relationnel, optimisation, langage SQL * * * Le site sur le langage SQL et les SGBD relationnels : http://sqlpro.developpez.com/ * * * Expert SQL Server http://www.sqlspot.com : audit, optimisation, tuning, formation * * * Le blog sur SQL / MS SQL Server http://blog.developpez.com/sqlpro * * * Enseignant CNAM PACA, ISEN Toulon, CESI/EXIA Aix En Provence
    • Marqué comme réponse Alex Petrescu lundi 28 février 2011 11:07
    mercredi 23 février 2011 23:21
  • Bonjour,

     

    As tu essayé de jouer avec les principes suivants de SSIS :

     

    1. TransactionSupport Option.

    si tu changes le transaction support de ton exec sql task a not supported il ne sera pas inclut dans ta transaction ce qui évitera de la casser

     

    2. Resultset single row

    tu catch le résultat -1 ou 0 selon le résultat de ta proc et tu l'assigne a une variable dont la portée est sur le flux de contrôle.

     

    3. Precedence constraint avec expression et la tu teste la variable afin de faire 2 flux possibles.

     

     


    Ludovic Bouaziz - MCSD .net
    jeudi 24 février 2011 10:05