J'utilise LINQ vers SQL et une tierce partie SDK prenant en charge les transactions distribuées. Lorsque je réalise qu'une mise à jour en attente mettra à jour les enregistrements SQL et les enregistrements de la tierce partie SDK, je crée un transaction de transaction avec un délai d'expiration 0 (probablement infini) (bien que j'ai également essayé 12 heures en tant que paramètre Timespan). Ensuite, j'utilise getdtcTransaction sur la transaction ambiante (créée par transactionsCope) pour obtenir une transaction DTC pour créer un lien vers la tierce partie SDK. Les choses fonctionnent bien pendant environ 10 minutes, mais après 10 minutes, la transaction disparaît et une erreur se produit. Comment puis-je déterminer pourquoi la transaction disparaît? Je soupçonne que c'est un délai d'attente car il se produit régulièrement après 10 minutes, même si des degrés de travail légèrement variés ont été effectués à ce moment-là. Mais je suis à perte de la manière de déterminer ce qui a terminé la transaction, pourquoi et comment prolonger sa vie.
J'ai essayé de traçonner les événements suivants avec SQL Profiler: P>
Tout ce que je mets autour du temps de l'erreur sont ces événements: P>
<Event id="19" name="DTCTransaction">
<Column id="3" name="DatabaseID">1</Column>
<Column id="11" name="LoginName">sa</Column>
<Column id="35" name="DatabaseName">master</Column>
<Column id="51" name="EventSequence">167065</Column>
<Column id="12" name="SPID">10</Column>
<Column id="60" name="IsSystem">1</Column>
<Column id="1" name="TextData">{D662BBC4-21EC-436D-991C-DCB061A34782}</Column>
<Column id="21" name="EventSubClass">16</Column>
<Column id="25" name="IntegerData">0</Column>
<Column id="41" name="LoginSid">01</Column>
<Column id="49" name="RequestID">0</Column>
<Column id="2" name="BinaryData">C4BB62D6EC216D43991CDCB061A34782</Column>
<Column id="14" name="StartTime">2009-11-11T13:55:32.82-06:00</Column>
<Column id="26" name="ServerName">.</Column>
<Column id="50" name="XactSequence">0</Column>
</Event>
<Event id="33" name="Exception">
<Column id="3" name="DatabaseID">9</Column>
<Column id="11" name="LoginName">sa</Column>
<Column id="31" name="Error">1222</Column>
<Column id="35" name="DatabaseName">ACS</Column>
<Column id="51" name="EventSequence">167066</Column>
<Column id="12" name="SPID">19</Column>
<Column id="20" name="Severity">16</Column>
<Column id="60" name="IsSystem">1</Column>
<Column id="1" name="TextData">Error: 1222, Severity: 16, State: 18</Column>
<Column id="41" name="LoginSid">01</Column>
<Column id="49" name="RequestID">0</Column>
<Column id="14" name="StartTime">2009-11-11T13:55:34.717-06:00</Column>
<Column id="26" name="ServerName">.</Column>
<Column id="30" name="State">18</Column>
<Column id="50" name="XactSequence">0</Column>
</Event>
<Event id="33" name="Exception">
<Column id="31" name="Error">8525</Column>
<Column id="8" name="HostName">MARTY755</Column>
<Column id="12" name="SPID">55</Column>
<Column id="20" name="Severity">16</Column>
<Column id="64" name="SessionLoginName">fse</Column>
<Column id="1" name="TextData">Error: 8525, Severity: 16, State: 1</Column>
<Column id="9" name="ClientProcessID">2516</Column>
<Column id="41" name="LoginSid">DB2744F54B5CDB4A8B9E5CA9C209A7AC</Column>
<Column id="49" name="RequestID">0</Column>
<Column id="10" name="ApplicationName">.Net SqlClient Data Provider</Column>
<Column id="14" name="StartTime">2009-11-11T13:55:37.54-06:00</Column>
<Column id="26" name="ServerName">.</Column>
<Column id="30" name="State">1</Column>
<Column id="50" name="XactSequence">236223201284</Column>
<Column id="3" name="DatabaseID">9</Column>
<Column id="11" name="LoginName">fse</Column>
<Column id="35" name="DatabaseName">ACS</Column>
<Column id="51" name="EventSequence">167067</Column>
</Event>
<Event id="162" name="User Error Message">
<Column id="31" name="Error">8525</Column>
<Column id="8" name="HostName">MARTY755</Column>
<Column id="12" name="SPID">55</Column>
<Column id="20" name="Severity">16</Column>
<Column id="64" name="SessionLoginName">fse</Column>
<Column id="1" name="TextData">Distributed transaction completed. Either enlist this session in a new transaction or the NULL transaction.</Column>
<Column id="9" name="ClientProcessID">2516</Column>
<Column id="41" name="LoginSid">DB2744F54B5CDB4A8B9E5CA9C209A7AC</Column>
<Column id="49" name="RequestID">0</Column>
<Column id="10" name="ApplicationName">.Net SqlClient Data Provider</Column>
<Column id="14" name="StartTime">2009-11-11T13:55:37.54-06:00</Column>
<Column id="26" name="ServerName">.</Column>
<Column id="30" name="State">1</Column>
<Column id="50" name="XactSequence">236223201284</Column>
<Column id="3" name="DatabaseID">9</Column>
<Column id="11" name="LoginName">fse</Column>
<Column id="35" name="DatabaseName">ACS</Column>
<Column id="51" name="EventSequence">167068</Column>
</Event>
3 Réponses :
pourrait-il être le chronométrage sqlconnection et non la transaction distribuée?
Vous pouvez utiliser le profileur SQL Server pour essayer de surveiller pour une goutte de connexion inattendue. Vous voudrez simplement vous assurer d'arroser votre profil de trace pour inclure uniquement les événements dont vous avez besoin pour surveiller car sa sortie peut être assez verbeuse. Je commencerais avec seulement la surveillance des événements "Login d'audit" et "Connexion d'audit" que l'on peut trouver dans la catégorie d'événements "Audit de sécurité".
Si vous profilez sur autre chose qu'une instance SQL Server SQL-stand-stand-stand-stand-stand-soi / utilisée, vous voudrez probablement appliquer un filtre pour que seuls les événements provenant de votre hôte apparaissent dans la sortie. < / p>
Vous voudrez peut-être explicitement Spécifiez un Valeur du délai d'attente dans votre chaîne de connexion - Définissez-la vraiment bas et voyez si vous obtenez le même comportement beaucoup plus rapidement.
De votre journal de trace, je vois deux exceptions près, dont les détails sont les détails:
Le googling pour l'exception 1222 est allumé http: // www .sqlservercentral.com / forums / topic579864-146-1.aspx # BM645422 , qui indique:
Cette erreur signifie qu'un verrou était demandé à MSDB et a expiré. Habituellement, ça va dire que c'est un grande transaction sur une grande table Temp ou un gros genre ou quelque chose de ce type.
Avez-vous particulièrement requêtes de longue durée qui pourraient être associé avec? Peut-être un lourd rapport de service, ou quelque chose de similaire à ça?
Espérons que cela vous amène un peu plus loin.
Comment puis-je déterminer cela - existe-t-il des tracements que je peux faire pour suivre les délais d'attente?
J'avais déjà essayé d'utiliser le profileur SQL Server pour surveiller les événements et les erreurs de transaction, mais cela ne semblait pas avoir de beaucoup d'aide. Je n'ai vu aucune mention d'un délai d'attente. Peut-être que je voulais simplement surveiller les mauvaises Evetns?
J'ai une longue requête de course ... Ce que j'essaie de comprendre, c'est comment le laisser continuer à courir.
En réalité, ce n'est pas une seule interrogation longue de course, mais une charge de bateau d'actions dans la même transaction.
J'ai saisi des pailles tout ce temps et je suis à peu près dépensé à ce stade ... peut-être placer une prime sur votre question pour essayer d'attirer une meilleure réponse?
Finalement compris. Posté une réponse séparée ci-dessous.
Pour étendre le délai d'attente, qui est par défaut à 10 minutes maximum lorsqu'il n'est pas spécifié, il est nécessaire de mettre à jour C: \ windows \ microsoft.net \ framework \ v2.0.50727 \ config \ machine.config sur le système cible (regarder sous c : \ Windows \ Microsoft.net \ Framework64 \ v2.0.50727 \ config si vous utilisez 64 bits). Ajoutez ceci comme le dernier élément droit sous le niveau de racine: Ceci sera (à titre d'exemple) définir le délai d'attente à 23 heures. La valeur effective est visible dans System.Transactions.TransactionManager.MaximumTimeout
Je me trouve maintenant courir dans ce problème. Ha! Je voulais juste ajouter que ce délai maximum ne peut être défini que dans la machine.Config - vous ne pouvez pas le remplacer dans votre application. Ceci est une véritable limitation si vous n'êtes pas autorisé à modifier la machine de plate-forme de déploiement cible.
Ouais, cela semble être de la conception ... mais d'accord avec vous que ce n'est pas si drôle lorsque vous n'êtes pas autorisé à mettre à jour le serveur ...
Ceci est probablement évident pour tout le monde en train de lire sauf moi, mais je viens de rester coincé sur cette question et je voulais mentionner comment je l'ai réparé. Même si j'ai modifié le fichier à l'emplacement indiqué par Bluemonkmn, je recevais toujours le délai de transaction par défaut de 10 minutes. Depuis que je suis en cours d'exécution Windows 7 64 bits, l'emplacement du fichier machine.config pour .NET est à l'emplacement suivant:
Remarque Le dossier "Framework64" est différent de celui ci-dessus. c: \ windows \ microsoft.net \fray64 \ v2.0.50727 \ config