Booting with selectable reserved memory configuration?

[Ronald Sisson]

Is it possible to select different reserved memory configurations at boot time?

I have a production database node with more physical memory than its cold standby node, and want to take advantage of the additional memory for the Oracle SGA during normal usage. However, if I have to bring up the standby node to replace the failed production node, I will have to revert to a smaller SGA. I would like to avoid an additional reboot just to resize the reserved memory. Ideally, I would check a user specific SYSGEN parameter at boot time, and somehow put in place a particular VMS$RESERVED_MEMORY.DATA file during the boot sequence.

[Ian Miller.]

is the standby node booting off the same system disk or a copy of the system disk?

Perhaps you can have a separate root (say SYS1) for the standby node which has some differences in the node specific directories such as [SYS1.SYSEXE] ?

[Ronald Sisson]

The standby node will be booted from the same system root, as I want the host to appear "identical" to the application layer. Other than the total amount of physical memory, the two systems are physically identical. (Management could not fund both memory upgrades in the same fiscal year, so I have to find creative solutions.)

I suppose it would be possible to create a duplicate root with the same node name, but I would rather avoid that if possible, as it means additional maintenance issues.

[Hoff]

I tend to use Ian's approach of multiple roots for this sort of thing (the extra maintenance tends to be slamming the contents of the main root into the secondary root, save for merging your change -- which itself doesn't need to be in the system root). Another approach here might involve a check during the early sections of the bootstrap followed by a startup-controlled reboot, with the environment adjusted. The other approaches here can involve making the primary and the secondary more similar (eg: buy some memory), or to use clustering and run both in parallel and with each tuned appropriately.

Stephen Hoffman
HoffmanLabs LLC

[Jon Pinkley]

There really doesn't need to be much in the sys$specific root, so what extra maintenance were you thinking about?

As long as your applications don't care what system root they are booting from, then that should be quite transparent.

If you don't want to do that, then I would recommend doing a conversational boot, and set for minimum boot. That will take a minimal amount of time and should get you to a state that you can change you settings.

For our system, that makes a difference of over 5 minutes in time till login.

e.g.

>>> b -flags x,1 ! x is system root
...
SYSBOOT> set startup_p1 "MIN"
SYSBOOT> set writesysparams 0
SYSBOOT> continue

Make your changes, then reboot.

When you revert to you other system you will have to repeat the process, specifying the increased memory.

[Robert Gezelter]

Ronald,

I agree wholeheartedly with Ian and Hoff. An alternate system root is the way to go. All of the alternatives are far less safe.

I agree that there should be few files in the SYHS$SPECIFIC tree, and thus having a second system root has very little overhead. Additionally, there should be no references that depend on the actual root that you are booted off of, all references should be to SYS$SYSROOT (or a reference to the F$TRNLNM lexical function and a operation based upon SYS$SYSROOT). Note that this is what the OpenVMS system startup procedures actually do.

If you have a large number of application specific files that are specific to the role, not the node, I often create a Role Specific Logical name table and add it to the basic system search path. Some examples of how to use this approach are in my paper from the OpenVMS Technical Journal, Volume 3. See http://www.rlgsc.com/publications/vmstechjournal/inheritance.html for a reprint.

- Bob Gezelter, http://www.rlgsc.com

[Ronald Sisson]

Thanks for all of the suggestions.