6
votes

Sybase ASE: "Votre commande de serveur a rencontré une situation d'impasse"

Lorsque vous exécutez une procédure stockée (à partir d'une application .NET) qui fait une insertion et une mise à jour, j'ai parfois (mais pas cela souvent, vraiment) et obtenez cette erreur de manière aléatoire:

Erreur [40001] [DataDirect] [pilote de protocole de fil de fil ODBC Sybase] [SQL Server] Votre commande Server (ID de famille # 0, ID de processus n ° 46) a rencontré une situation d'impasse. Veuillez réexécuter votre commande.

Comment puis-je résoudre ce problème?

Merci.


4 commentaires

Savez-vous ce qu'est une impasse, pourquoi une impasse peut se produire ... et pourquoi est se passe avec votre code ? Avez-vous essayé Googling pour comme "Sybase" et "Deadlock"?


Oui, je sais ce que c'est, oui j'ai googlé. La chose est que l'impasse se produit très rarement. Comme la requête est simple (une mise à jour et un insert), il devrait au pire être retardé par le serveur si un autre verrou soit le bloquant, non seulement le jeter. En outre, l'erreur ne dit pas ce que l'impasse était sur (quelle table, rangée, etc.) qui rend difficile la résolution du problème. Je ne peux pas empêcher manuellement 2 questions d'arriver sur le serveur en même temps!


Une impasse ne fait jamais retarder d'autres processus qu'elle arrête l'autre processus mort - je lirais plus sur des blocages comme vous n'avez pas montré la compréhension


Eh bien c'est tout le point, marquez. Je dis que cela devrait / devriez / soyez retardé, comme dans, c'est le comportement attendu. Bien sûr, le problème ici est que ce n'est pas le comportement que je reçois, comme au lieu d'être retardé, cela provoque une impasse et être complètement bloqué.


3 Réponses :


0
votes

en supposant que vos tables sont correctement indexées (et que vous utilisez réellement ces index - toujours intéressant de vérifier via le plan de requête) Vous pouvez essayer de casser les parties des composants du SP vers le bas et de les envelopper dans des transactions distinctes afin que chaque unité de Le travail est terminé avant que le prochain ne commence. xxx


1 commentaires

En fait, aujourd'hui, j'ai à nouveau le même problème, avec une procédure stockée qui ne contient qu'une seule déclaration (un insert) ...



8
votes

Votre meilleur pari pour vous résoudre le problème de l'impression est de définir "Informations d'impression d'impression" sur Utiliser

sp_configure "Informations d'impression d'impression", 1

Chaque fois qu'il y ait une impression, cela imprimera des informations sur les processus impliqués et que les SQL qu'ils fonctionnaient à l'époque de la serrure morte.

Si vos tables utilisent les allignages verrouillables. Il peut réduire les impacts pour passer aux datarses ou au verrouillage des données. Si vous faites cela, assurez-vous de recueillir de nouvelles statistiques sur les tableaux et de recréer des index, des vues, des procédures stockées et des déclencheurs qui accèdent aux tables qui sont modifiées. Si vous ne faites pas que vous ne recevrez pas d'erreur ou que vous ne voyez pas tous les avantages du changement en fonction desquels ne sont pas recréés.


0 commentaires

2
votes

J'ai un ensemble d'applications à long terme qui survient occasionnellement à l'accès de la table et à Sybase jetteront cette erreur. Si vous cochez le journal du serveur Sybase, il vous donnera les informations complètes sur la raison pour laquelle c'est arrivé. Comme: le SQL qui a impliqué les deux processus essayant d'obtenir une serrure. Habituellement, on essaie de lire et l'autre faire quelque chose comme une suppression. Dans mon cas, les applications sont en cours d'exécution dans des JVM distinctes, il ne peut donc pas que Sychroniser ne soit pas à nettoyer périodiquement.


0 commentaires