For my clients on Windows, we use OEE. As Tom says, you need a way of running a DB as a service so it won't go away when the user who started it logs off. Better to do that with Progress' supported method than with some third-party solution that knows nothing about Progress. On non-Windows platforms, we never use Admin Server/OEE for database management.
I can't see where Ron actually said this was Linux...
My problem was this ... I have a DR server that is configured to be a mirror-image of a prod server. Although we're licenced to allow running programs on the DR server - this one has not until now been used to do that. But now I have to run some very heavy jobs on that server and they're taking an uncomfortably long time to run. So - I wanted to assign all available memory to DB buffers. But I wanted to do it in a way that made it super-simple to revert to the prior configuration in the (unlikely) event that the DR server has to take-over as production.
This confuses me. You have some amount of load on your prod server, and you have such heavy load on DR (reporting, I assume) that you want
more -B buffers than on prod. But you want to be able to revert to the
lower prod -B in the event of a disaster. Why?
In a disaster, your only available system is DR so presumably it runs its existing reporting workload plus whatever currently happens in prod. In that case I'd want -B to be as large as it needs to be to do that extra work, without causing paging/swapping. Which also makes me wonder, if the prod and DR servers have the same amount of memory, why would you want prod -B to be smaller? What's the downside of having the same large -B value on both servers if the available resources allow it?