App perdre connexion db

Question

Je rencontre un problème étrange avec une ancienne application Delphi perdre sa connexion de base de données. En fait, je pense que c'est perdre quelque chose d'autre qui fait alors tomber la connexion ou être inutilisable. L'application est écrite en Delphi 6 et utilise le composant Direct Oracle Access (v4.0.7.1) pour se connecter à une base de données Oracle 9i. L'application s'exécute en tant que service et interroge périodiquement la base de données à l'aide d'un objet TOracleQuery (qryAlarmList). La méthode qui est appelée à faire cela ressemble à ceci:

procedure TdmMain.RefreshAlarmList; 
begin 
    try 
    qryAlarmList.Execute; 
    except 
    on E: Exception do 
    begin 
     FStatus := ssError; 
     EventLog.LogError(-1, 'TdmMain.RefreshAlarmList', 'Message: ' + E.Message); 
    end; 
    end; 
end; 

Il avait été en cours d'exécution bien pendant des années, jusqu'à ce qu'un couple de scripts Perl ont été ajoutés à cette machine. Ces scripts s'exécutent toutes les 15 minutes et recherchent des fichiers de données à importer dans la base de données, puis ils effectuent quelques calculs et un tas de lectures/écritures vers/depuis la base de données. Pour une raison quelconque, lorsqu'ils traitent de grandes quantités de données et que l'application Delphi tente d'interroger la base de données, l'application Delphi lève une exception sur la ligne "qryAlarmList.Execute" dans la liste de code ci-dessus. L'exception est toujours:

Access violation at address 00000000. read of address 00000000 

COMMENT quelque chose que les scripts Perl font peut-être provoquer? Il y a d'autres scripts Perl sur cette machine qui chargent des données en utilisant les mêmes modules et appels de méthodes et nous n'avons pas eu de problèmes. Pour le rendre encore plus bizarre, il y a deux autres applications qui perdront soudainement leur capacité à parler à la base de données en même temps que les choses Perl sont en cours d'exécution. Aucune de ces applications n'est exécutée sur cette machine, mais les deux sont des applications Delphi 6 qui utilisent le même composant DOA pour se connecter à la même base de données. Nous avons d'autres applications qui se connectent à la même base de données, écrites en Java ou en C# et qui ne semblent pas avoir de problèmes.

J'ai essayé d'ajouter le code avant que la méthode '.Execute' est appelé à:

• vérifier la connexion de la session (session.CheckConnection (true); revient toujours comme 'ccOK') .

• voir si je peux accéder à un champ de l'objet qryAlarmList pour voir si peut-être devenir nul; peut y accéder bien.

• vérifier l'état de la liste qryAlarmList; dit toujours que c'est qsIdle.

Quelqu'un a des suggestions de quelque chose à essayer? Ça me rend dingue!

Dave

Answer 1

Si d'autres applications sur d'autres machines ne perdent aussi leur connexion à la DB, j'enquête sur le côté DB et regarder là-bas (retirer perf stats, journaux, ...).
Peut-être que les scripts Perl entraînent un certain colmatage des ressources sur le serveur de base de données, bloquant les autres tentatives d'accès.
Et cela pourrait être lié à la façon dont les applications D6 se connectent, laissant l'autre C#, Java ... capable de fonctionner?

Mon raisonnement est que je ne vois la DB comme lien commun dans MachineA/D6 perdre la connexion et MachineB/D6 perte de connexion ...

Hope it helps

Answer 2

On dirait que quelque chose est remise à zéro du auditeur. Demandez à dba de vérifier les différents journaux pour voir si l'écouteur rebondit lorsque ces tâches Perl sont exécutées.Ou vérifiez si le PID (ID du processus) de l'écouteur reste le même toute la journée, ou s'il saute lorsque ces tâches Perl sont exécutées.

Answer 3

"Violation d'accès à l'adresse 00000000. La lecture de l'adresse 00000000" a une signification très particulière. Cela signifie presque certainement que quelque chose tente d'appeler une méthode virtuelle sur une référence d'objet nil. Si ce n'est pas quelque chose d'évident, essayez de reconstruire avec Debug DCU sur et exécutez sous le débogueur. Il devrait casser et vous montrer exactement où le problème est.

En outre, vous avez mentionné que vous êtes en Delphi 6 et que cela se produit uniquement avec de grands ensembles de données. Dans ce cas, vous pourriez vouloir regarder FastMM4, un gestionnaire de mémoire de remplacement. L'ancien gestionnaire de mémoire de BorlandMM avait quelques problèmes qui pourraient donner des violations d'accès lorsque vous travaillez avec de grandes quantités de données, et FastMM les corrige.

Answer 4

DOA v 4.0.7.1 a 5 ans. Pourquoi ne pas simplement essayer de mettre à niveau votre DOA vers la dernière version?

Answer 5

Dave, J'ai le même problème, mais pas perl ou un autre processus en cours d'exécution. J'ai vu que mon oracle db était avec SGA_MAX_SIZE ci-dessous nécessaire, mais je ne peux pas arrêter en ce moment parce que la production db et ont cet avertissement très utilisateurs.

S'il vous plaît, regarde/modifier vos paramètres de base de données et nous donner une rétroaction

Bonne chance. Allisson

Ps: désolé mon mauvais anglais