Openedge 24/7 capability

M

mattk

Member
Hi there,

We have an Openedge 10.0b database which is used in conjunction with a 3rd Party application. The databases are clustered between two boxes on a Windows Server 2003 environment.
The needs of our business is forcing our company to go 24/7 at present meaning that the databases are not able to be stopped and started on a scheduled basis.
Recently we have had some issues involving our Apps Server which has caused our databases to shutdown randomly. The vendor of the application have stated that Progress databases should be restarted once a week to clear down temp tables and truncate the BI file.
This clearly indicates that the databases are not capable of a 24/7 infrastructure. However we have another application that uses Progress 9.1D databases and is operational 24/7 without issues.
We do an online backup daily which to my knowledge should truncate the BI file.
Do you know if there are any issues regarding 24/7 OpenEdge environments and the Apps Server? Should Progress databases need restarting weekly? Does this specification point to anything within the coding of the application to you guys? Does an online backup always automatically truncate the BI file?

Any help given would be much appreciated.

Thanks and regards,
 
With all due respect whoever said that is misinformed. Or has, perhaps, been misquoted.

The database does not need to be routinely restarted and the bi file does not need to be routinely truncated.

You might choose to truncate the bi file if it has grown exceptionally large. Of course that usually only happens as a result of some foul bit of code being run that has no proper concept of transaction scope. Not that any vendors would ever release such things to prey on poor innocent customers :eek:

Temp-tables are, of course, a client side issue and only require the restart of the relevant client session to clear. Again they would generally only become unreasonably large due to poor programming. (Perhaps the vendor meant temp files -- the SRT, DBI, LBI etc files? But the same is true of those as well.)

Unfortunately it is true that it is a good idea to restart app servers and the app server broker on a regular basis. There seem to be persistent memory leaks in that code. But that's usually just a quick up & down and you should be able to do it without anyone noticing if the application has been reasonably well designed and implemented. There is no need to restart the database in order to accomplish that.

Personally I'd want to focus on investigating the app server issues that result in the database going down. That sounds like somebody is over-reacting to a problem that they do not understand. But there isn't enough information really to say for sure. Is a specific error is occurring? Or is it just that someone decides that rebooting everything will cure the problem? Or is something else happening?
 
Thanks for the reply Tom.
It seems to me that the explanation given to us from the vendor has been a simple 'powercycle and that should solve all your problems'. I believe that there are underlying issues with the way the App Server functions in regards to this application.
Can you advise how often the App Server should be restarted? Do you know if it is possible to have the App Server as a clustered resource?
 
App servers are complex beasts and a lot depends on how your vendor coded it and which app server mode they're using.

But ideally you would be using a name server and have redundant app servers setup. In theory they could be on different nodes of a cluster and brought up and down independently.

Most of my customers are cycling them nightly and are working with, ummm, "less than ideal" architectures from their vendors.

It's hard to get any more specific without a 4 hour presentation ;) (There were at least 4 hours of presentations on this stuff at Exchange in Paris last week...)
 
You must log in or register to reply here.
Back
Top