Consultor Eletrônico

Solution ID: P14628

GOAL:

How to tune database startup timing parameters for the AdminServer.

FACT(s) (Environment):

Progress 9.1C
Progress 9.1D

FIX:

When there are several databases with the option 'autostart' with the
AdminServer set, it may happen that database registration with the AdminServer fails. If that happens, errors 9149 and 8845 will be reported.

In general, the timing variables described below should not need to be
modified. If, however, a need arises to tune these variables, it can
be done by specifying these timing variables in a file (name=value format)
and changing the AdminServer startup command to include the Java property
setting "-DConfigToolTimings=<filename>" where <filename> is the name
of the file where the <timingVar>=<valueInSeconds> settings are saved.

If AdminServer is being started by the "PROADSV" command, the Java property
may be set by setting the JVMARGS environment variable i.e.:
JVMARGS="-DConfigToolTimings=<filename> $JVMARGS"; export JVMARGS

Timing Variables
----------------

Below are the names of the timing variables, their defined defaults,
and a description of what the timing variables control.

DbStartupDelayMin=10
DbStartupDelay=5

It is possible at AdminServer start time/database plugin start time, that
some database brokers (previously started through the Progress Explorer)
are already running. At database plugin start time, Progress waits for these
database brokers to re-register with the AdminServer's database plugin.

These parameters control how long the database plugin will wait before
checking if any more registrations between database objects and their _mprosrv
processes have occurred. At a minimum, the database plugin will wait the number of DbStartupDelayMin seconds for any registrations to occur. If no
registrations have occurred, no more waits for subsequent registrations are done.
If any registrations have occurred, then the database plugin polls every
DbStartupDelay seconds until no more registrations are received between
polls.

WTCStartingMin=300
WTCStarting=120

Before a database starts, it is in the Idle state. During database
starts, databases transition from the idle state -> starting state ->
the initializing state -> the running state.

These parameters control how long the database plugin will wait for
a database object to transition from the idle state to the start state.
A successful transition to the start state means that the database
object has established initial communication between itself
and the _mprosrv process it controls. The starting state timers
are terminated upon successful state transition, or in worse case,
upon the timer expiration. If the timer expires, the
database remains in the idle state.

At minimum, the database will wait up to WTCStartingMin seconds for a
successful state transition. If multiple databases are being autostarted
(numberOfAutostarts) at database plugin startup, the time required to make
the state transition can be longer. As a result, the individual databases
will wait WTCStarting*numberOfAutostarts or WTCStartingMin seconds,
which ever is greater.

WTCInitializingMin=300
WTCInitializing=120

Once a database object has established communication between itself
and its _mprosrv process, some validation must occur before the database
object can transition from the starting state -> initializing state.
These timers control how long this validation process can take.

Timers are terminated immediately upon successful state transition,
or in worse case, when the timer expires. If the timer expires, the
database object is forced back to the idle state.

At minimum, the database object will wait up to WTCInitializingMin seconds
for a successful state transition. If multiple databases are being
autostarted (numberOfAutostarts) at database plugin startup, the time
required to make the state transition can be longer. As a result, the
individual databases will wait WTCInitialing*numberOfAutostarts or
WTCInitialingMin seconds, which ever is greater.

WTCShuttingDownMin=30.0
WTCShuttingDown=120

Before a database is shut down, it is in the running state. During database
shut down, databases transition from the running state -> shutting down state
-> idle state. These timers control how long the shutdown process can take before the database is assumed crashed.

Timers are terminated immediately upon successful state transition,
or in worse case, when the timer expires. If the timer expires, the
database is assumed crashed and the database object is forced back to the
idle state.

At minimum, the database object will wait up to WTCShuttingDownMin seconds
for a successful state transition. If multiple databases are being
autostarted (numberOfAutostarts) at database plugin startup, the time
required to make the state transition can be longer. As a result, the
individual databases will wait WTCShuttingDown*numberOfAutostarts or
WTCShuttingDownMin seconds, which ever is greater.

PollServerGroup=11

Database objects may be configured to start auxiliary processes such as
after image processes, before image processes, watch dogs, and after
page writers, and may be configured to start secondary brokers.

This timer dictates the poll interval in seconds that the auxiliary
and secondary broker processes will be polled to determine when they
are running. Polling ends when the processes are either running are
when they have failed to start..