Une panne de réseau entraîne l'interruption définitive de la procédure stockée sur une requête stockée dans Link de la base de données

Question

Un certain nombre de procédures stockées que je supporte interroge des bases de données distantes sur un réseau étendu. Le réseau tombe parfois en panne, mais le pire qui se soit passé est que les procédures ont échoué et doivent être redémarrées.

Les deux dernières semaines ont pris une tournure sinistre. Au lieu d'échouer, les procédures sont bloquées dans un état étrangement verrouillé. Ils ne peuvent pas être tués à l'intérieur d'Oracle et tant qu'ils existent, toute tentative d'exécuter d'autres copies de la procédure sera également suspendue. La seule solution que nous avons trouvée consiste à supprimer les procédures incriminées avec un "kill -9". de l'OS. Certaines de ces procédures n'ayant pas changé depuis des mois, voire des années, je suspecte donc une cause fondamentale dans la base de données ou la configuration de la base de données.

Quelqu'un a-t-il une idée de ce que nous pouvons faire pour résoudre le problème? Ou bien PL / SQL a-t-il un mécanisme d'expiration que je peux ajouter au code pour pouvoir créer une exception que je peux gérer par programme?

Answer 1

Nous n'avons jamais été en mesure de déterminer la cause de cette situation. Nous pensons que c'était un défaut du patch cumulatif d'octobre 2008. Peut-être qu'un correctif ultérieur l'a corrigé. Cela ne s'est pas produit depuis quelques mois (et nous avons eu quelques pannes de réseau), alors espérons que le problème a disparu.

Answer 2

Quelle version de la base de données? Sont-ils bloqués sous SQL ou en PL / SQL? Quelqu'un a-t-il récemment ajouté la gestion des exceptions aux routines? Je me souviens que dans 9iR2, on nous avait dit qu'au lieu de lever une exception à la routine d'appel, nous devions intercepter toutes les exceptions et continuer à fonctionner (essayez de lancer tous les éléments du travail, même si certains échouent). Nous avions inévitablement des travaux bloqués dans une boucle infinie avec l'échec des instructions SQL, la capture par le gestionnaire d'exceptions et une nouvelle tentative. Et ils ne pouvaient pas être tués car les WHEN OTHERS ont également attrapé l'exception "votre session a été tuée". Je pense que ce dernier a changé en 10g pour que cette exception ne soit pas interceptée.