Programa Travando Sistema (Program Crashing System)

[sidival]

Bom dia , (Hi Guys !),

Aqui trabalhamos com o Datasul, ele ( os programas ) e o banco de dados ficam em um servidor e a empresa toda usa os dois, são 90 usuários acessando tanto os programas como a base de dados.
( Here we work with Datasul, it (the programs) and the database are on a server and the whole company uses both, there are 90 users accessing both the programs and the database. )

Existem alguma forma (que não seja o audit trail pois não foi encontrado um programa ou um usuário que gera o problema ), para identificar qual programa exatamente que esta gerando o travamento em nosso sistema ?
( Is there any way (other than the audit trail because a program or a user that generates the problem was not found) to identify which program exactly is generating the crash in our system? )

Atte,
Sidival

 

[TomBascom]

I'm sorry but I do not speak Portuguese (I assume that is your mother tongue since you mention Datasul). (Sinto muito, mas não falo português (presumo que seja sua língua materna já que você mencionou o Datasul).)

That depends greatly on the nature of the crash. You should post the messages in the database .lg file which were generated when the db crashed. Depending on what those messages show there might be ways to track that back to a specific program that caused the crash or you might find out that some other situation caused the crash. (Isso depende muito da natureza do acidente. Você deve postar as mensagens no arquivo .lg do banco de dados que foram geradas quando o banco de dados travou. Dependendo do que essas mensagens mostram, pode haver maneiras de rastrear isso até um programa específico que causou a falha ou você pode descobrir que alguma outra situação causou a falha.)

Generally speaking - database crashes do not occur as a result of running a specific program. It would be unusual to find out that "run program.p" is causing a database to crash. It is more likely that something else is causing that. But without the .lg file we cannot really say. (De modo geral - falhas no banco de dados não ocorrem como resultado da execução de um programa específico. Seria incomum descobrir que "run program.p" está causando falha no banco de dados. É mais provável que algo esteja causando isso. Mas sem o arquivo .lg não podemos dizer.)

It is also very helpful to know what specific version of OpenEdge you are using and what Operating System you are running on as well as some basic information about the configuration of the system. (Também é muito útil saber qual versão específica do OpenEdge você está usando e qual sistema operacional está executando, bem como algumas informações básicas sobre a configuração do sistema.)

 

[sidival]

Hi Bascom ! Thanks a lot for your return, we are lost, looking everything to try resolve this situation, what we imagine, that there is a programm in loop (that only in determined situation ) and this programm starts to slow down the others and finaly crash everthing, we imagine that finding this programm that is consuming more time than others we can stop this problem. I'll try find same track in the LGs files,

 

[sidival]

We work with OE Studio 11.7

 

[TomBascom]

A crashed database is very different from a program that is busily looping.

If you need to find out what code a running program is executing you have two main choices:

1) If you have access to the machine that the program is running on you can run "proGetStack <PID>". This will generate a protrace.<PID> file that contains a 4gl stack trace showing what code is executing. ("<PID>" is the process ID from the operating system.) This might be challenging if the program is running on a remote users desktop that you cannot easily login to. You can only do this for processes that are local and you need command line access.

2) You can use the "client statement cache". This is a database feature that tracks the most recent database access and the code associated with that. You can enable it on the server so it works equally well with either local or remote users. However - it only reports on statements that access the database so if your code is doing some non-database thing you will not get any data. You can use ProTop, PROMON, or custom VST code to enable and view this data.

There is a video on this topic here: Real Time Visibility Using The Client Statement Cache and the slides are here: Real Time CSC Slides