Did this article resolve your question/issue?


Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025



What happens when a PROQUIET is requested


Article Number000022666
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Question/Problem Description
What happens when a PROQUIET is requested?
What happens when a PROQUIET is enabled?
Why is there sometimes a delay in a PROQUIET being granted ?
What are the differences between PROQUIET and PROQUIET no lock?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
PROQUIET is a feature of the Enterprise Database License. It is typically used to quiescent the database prior to adjusting the bi threshold or when 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 point
This 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


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 normal
5.  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.
Last Modified Date12/6/2018 8:58 AM