La panne de réseau provoque l'interrogation de la procédure stockée sur la liaison DB pour qu'elle se bloque toujours

Question

Un certain nombre de procédures stockées prennent en charge les bases de données distantes de requête sur un réseau étendu. Le réseau tombe parfois en panne, mais le pire est que les procédures ont échoué et doivent être redémarrées.

Les deux dernières semaines, il a fallu un sinistre virage. Au lieu d'échouer les procédures se bloquer dans un état verrouillé wierd. Ils ne peuvent pas être détruits à l'intérieur d'Oracle et tant qu'ils existent, toute tentative d'exécution d'autres copies de la procédure sera également suspendue. La seule solution que nous avons trouvée est de tuer les procédures incriminées avec un "kill -9" du système d'exploitation. Certaines de ces procédures n'ont pas été modifiées depuis des mois, voire des années, donc je soupçonne une cause première dans la configuration DB ou DB.

Quelqu'un at-il une idée de ce que nous pouvons faire pour résoudre le problème? Ou est-ce que PL/SQL dispose d'un mécanisme de temporisation que je peux ajouter au code pour que je puisse créer une exception que je puisse gérer par programmation?

Answer 1

Nous n'avons jamais été en mesure de déterminer ce qui a causé cela. Nous croyons que c'était un défaut dans le correctif cumulatif d'octobre 2008. Peut-être un patch plus tard comme l'a fixé. Cela ne s'est pas produit depuis quelques mois (et nous avons eu quelques pannes de réseau), alors j'espère que le problème a disparu.

Answer 2

Quelle version de base de données? Sont-ils bloqués en SQL ou en PL/SQL? Est-ce que quelqu'un a récemment ajouté la gestion des exceptions dans les routines? Je me souviens dans 9iR2, on nous a dit que, à la place ou soulevant une exception à la routine d'appel, nous devions attraper toutes les exceptions et continuer à courir (essayer d'exécuter tous les éléments dans le travail même si certains échouent). Nous avons inévitablement eu des jobs coincés dans une boucle infinie avec des SQLs échouant, se faisant attraper par le gestionnaire d'exception et essayant à nouveau. Et ils ne pouvaient pas être tués comme le WHEN OTHERS a également attrapé l'exception «votre session a été tuée». Je pense que ce dernier a changé en 10g pour que l'exception ne soit pas attrapée.