Convert managed database to scripted

MarkW

New Member
Hi,
I have tried and failed to find the answer to this in the official documentation and my limited understanding of Progress means I need some hand holding on this.

All of our Progress DBs are scripted apart from one set on our test server. To manage startup / shutdown of the scripted DBs we obviously use scripts, this is quick, easy and familiar to all concerned. I've always assumed that using scripts to startup / shutdown managed DBs was not recommended but I now have no idea where that came from. The first question is, am I right? Secondly, if I am, why is it a bad idea?

To make life more straightforward in future and as part of my handover (I'm retiring soon) I'd like to convert those managed DBs to scripted ones. Is that possible and how would I go about doing it?

Regards,
Mark.
 
I would think that mostly you just want to review conmgr.properties and ensure that your script uses the same (or better) values for startup parameters and things like the number of APWs started etc. Then just stop using OEE...

That is especially straight-forward if you are running on UNIX.

The one advantage to "managed" is that, on Windows, the database and it's support processes are run "as a service". That's actually quite useful because Windows is not very friendly to background processes started by interactive users or scheduled tasks. If you do have the misfortune of having to run a Windows based db server you can have a hybrid scripted/managed approach using "dbman" in your scripts and putting most of your startup parameters into a pf file specified by the conmgr.properties "otherargs". That will preserve the "runs as a service" characteristic while allowing you to script administrative stuff instead of goofing around with the OEE UI (which is notoriously fickle...) You do have to futz around with conmgr.properties to define BIW, AIW, and APWs and to get secondary servers launched correctly though. If you just "probiw dbname" from a proenv (or a script or a scheduled task) that process will be killed when you logout.
 
Further to Tom's message above, all of the DB startup parameters are dumped to the logfile when you start it up. It wouldn't be too hard a job to scrape these and add them to a .pf file and then just start the db using that pf file. What's a bit harder is deciding what to ignore as it's just default values.

I'm sure if you posted the extract from the logfiles we could collectively advise. Look for the last (333) in the log and it'll be the next 100-150 lines. Ish.
 
Wouldn't it be easy to get the non-default startup parameters using _DbParams VST (since v11.5)?

BTW, it’s easy to write a program-watchdog that would persistently monitor the online changes of the startup parameters. I’m not sure if DBAs are often changing the parameters online. But if they do then we need to know when it happens (to interpret the changes of performance) and we need to apply the new values after database restart.
 
Relying on logged startup parameters and their values is very hit-and-miss, especially with secondary brokers. The older the release, the worse it is (i.e. they just don't log much at all).

Any database running under 11.5 - 11.7 should have an _DbParams VST, and the __SrvParam-* arrays in the _Servers VST. You can confirm this by checking that feature 23 (New VST Tables) is enabled in proutil dbname -C describe.

All databases running under 12.x and later do have these VST enhancements. Writing code to use these tables is the best way to get a comprehensive list of the current values of the parameters. I have issues with the way these tables were implemented, but they are much easier and more reliable than scraping the .lg or promon screens.

If you're on 12.8 or later, you can have promon generate broker .pf files for you. See the docs for the details:
https://docs.progress.com/bundle/openedge-startup-and-parameter-reference/page/Generate-parameter-files.html
 
In my opinion, PSC got the schema right for _DbParams, and the content wrong. IMHO, it should only contain primary broker parameters, not the client/server parameters of the primary broker when it also happen to be a login broker.

Ideally, I would have liked to see an _LoginBroker VST with one record per login broker, and an _LoginBrokerParam VST, with fields very much like those in _DbParams, with one record per client/server parameter per broker.

Alas, we don't live in an ideal world. Instead we get the mess of _Servers being overloaded with data and fields for both servers and brokers, which are different entities.
 
Back
Top