PROQUIET is a feature of the
Enterprise Database License. It is used to
quiescent the database prior to adjusting the bi threshold when
-bithold is enabled or to prepare the database before using Operating System or 3rd Party utilities that need to access the runtime database files for advanced backup strategies.
Quiet point processing against the database is performed as a co-operative effort between
_mprshut (PROQUIET) and the
Broker processes:
- The _mprshut process requests to enable or to disable a quiet point and the Broker satisfies it.
- Once the PROQUIET is requested, the Broker has a wait of TXX (waiting for TXE exclusive mode lock) until it is enabled.
The execution summaries of the two processes are as follows:A. When the PROQUIET is requested:
$ proquiet dbname -C enable
_MPRSHUT Process:1.
_mprshut accesses the database (logs in) and prints:
QUIET 5: Quiet point request login by x on y. (5569)
2. Makes a quiet point request to the Broker.
3. Loops until the quiet point state changes to quiet point
enabled or
reject.
4. Each loop ensures that the database primary Broker is still running and the database has not been marked for shutdown.
5. When the quiet point state changes to quiet point
enabled:
The _mprshut process then disconnects and only then returns with 0 status.
6. If quiet point state changes to quiet point
reject:
The _mprshut process then disconnects and returns with an error status.
BROKER Process:The broker processes events every 3 seconds
One possible event is to
enable a quiet pointThis occurs when
_mprshut sets the quiet point status to
request.
The quiet point is then enabled by the following processing:
1. Grab exclusive access to shared resources (PROQUIET needs TXE, MTX, BIB, and AIB latches clear).
2. Switches the current After Image extent (if after-imaging is enabled).
3. Flushes the bi buffer pool and master block.
4. Inhibits new writes to the current ai and bi files.
5. Sets quiet point status to enabled.
6. Prints out:
BROKER 0: Quiet point has been enabled by the broker. (5583)
7. Loops on watchdog processing until the quiet point is disabled.
B. When the PROQUIET is released:The execution summary of the BROKER processes is as follows once the PROQUIET is released:
$ proquiet dbname -C disable
BROKER:The broker processes events every 3 seconds
One possible event is to disable a quiet point
This occurs when
_mprshut sets the quiet point status to release.
1. Notices the quiet point status is set to disable (by
_mproshut)
2. Releases held resources
3. Prints out:
BROKER 0: Quiet point has been disabled by the broker. (5584)
4. Sets quiet point status to
normal5. Continues with regular processing.
The above describes the standard PROQUIET functionality. The PROQUIET utility was enhanced beginning in Progress 9.1E02, OpenEdge 10.0B03, and 10.1A to support a quiet point that stops all write activity in the database
within 15 seconds without requiring a latch. For further details and considerations of implementing this feature, refer to Article:
Understanding the above internal processing of the PROQUIET, the reasons that there is sometimes
a delay in between the PROQUIET being requested and granted can therefore be:
- Delays in flushing of the bi buffer pool where the system is experiencing hardware i/o problems. This should take no more time than it takes to complete a checkpoint and the switching of ai extents.
- Switching of ai extents is not a consideration with the enhanced PROQUIET NOLOCK feature.
- Only a short duration conflict is normally expected with other latches acquired as these are not held for a long time:
- The latch on the ai and bi buffer pools and
- The micro transaction latch.
- Waiting on a micro transaction latch is not a consideration with the enhanced PROQUIET NOLOCK feature.
- Although not likely or expected, the broker could be waiting on a exclusive TXE latch, which other processing could be holding the TXE.
For example when there is a very large transaction back out, or many concurrent transaction backouts being processed. This is usually the case when there is evidence of abnormal terminations (HANGUP, KILL signals) in the log file while waiting for the quiet point. Meaning that the broker is busy cleaning these latches up rather than performing its "process event cycle" every 3 seconds. The cleanup is normally done by the server process in the case of client-server connections, if the log file shows that the server has died, this task falls to the broker to cleanup:
BROKER 0: Disconnecting client 24 of dead server 1. (2526)
BROKER 0: Begin transaction back out. (2252)
Please note the sub-text here -
normally, this is not an issue. With the PROQUIET NOLOCK feature, we essentially allow microtransaction processing to the ai file while granting the PROQUIET anyway. This is why, the PROQUIET NOLOCK feature does not switch the ai file, which is different from the standard PROQUIET functionality.
