Did this article resolve your question/issue?



What happens when a PROQUIET is requested

« Go Back


TitleWhat happens when a PROQUIET is requested
URL NameP99512
Article Number000154051
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x, 12.x
OS: All supported platforms
Question/Problem Description
What happens when a PROQUIET is requested?
What happens when a PROQUIET is enabled?
What does quiescing the database mean?
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 Number
Enhancement Number
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 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/2/2020 4:36 PM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.