Feedback
Did this article resolve your question/issue?

   

Article

What are Database Quiet Points?

« Go Back

Information

 
TitleWhat are Database Quiet Points?
URL Name17553
Article Number000120577
EnvironmentProduct: Progress
Version: 8.2x, 9.x
Product: OpenEdge
Version: 10.x, 11.x, 12.x
OS: All supported platforms
Question/Problem Description
How Database Quiet Points Work
What is PROQUIET used for
How is PROQUIET used when splitting a mirror and the database is online
Why must the database be quiesced with PROQUIET when the database is online before taking a VSS, VEEAM snapshot
How to use PROQUIET when non-Progress Third Party utilities are used to provide data redundancy as part of a backup and recovery strategy
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
PROQUIET is a feature of the Enterprise Database License. An  OpenEdge Replication Plus license is required to run PROQUIET against a target replication enabled database. This PROQUIET feature was first introduced in Progress 8.2 to maintain database consistency during an operation that either fractures or splits an OS mirror on an active online database.

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, OS disk mirroring, VSS, VEEAM, VM snapshot Volume snapshot or any other Third Party Tool utilities are used to that need to access the runtime database files for advanced backup strategies. Without an Enterprise or Advanced RDBMS license, these operations must only take place against an offline database. A quiet processing point is a point in time where the database is quiesced and after first synchronizing database buffers to disk, all writes to the database file cease and are guaranteed to remain quiet until the quiet point is lifted. Quiet point processing against the database is performed as a co-operative effort between _mprshut (PROQUIET) and the Broker processes:

The quiet command requests that the Broker run a quiet point for the database:
$   proquiet <dbname> -C enable

The database Broker ends a quiet point when the quiet point is released:
$   proquiet <dbname> -C disable
In addition to the quiet disable command, any shutdown request (normal or abnormal) gracefully disables the quiet point. 
  • The quiet utility command (quiet points) feature is part of _mprshut which allows a quiet processing point in the database
  • The _mprshut process requests to enable (or to disable) a quiet point and the Broker satisfies it.
  • The database Broker is responsible for enabling (and disabling) the quiet point
  • Once the PROQUIET is requested, the Broker has a wait of TXX (waiting for TXE exclusive mode lock) until it is enabled.
  • Any processes that connect and attempt to start transactions also wait for the quiet point to be lifted. It notifies the quiet utility when that action has occurred.
  • The execution summary is further discussed in Article  What happens when a PROQUIET is requested  
The quiet utility returns a zero-valued return code once the database has become quiet. Otherwise, the command returns a non-zero value return code that indicates the command was unsuccessful. The following Article discusses these in more detail: When the database is enabled for After-Imaging (Replication), the enabling of a quiet point triggers an automatic after image extent switch. The PROQUIET utility was enhanced in Progress 9.1E02, OpenEdge 10.0B03, 10.1A and later 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 Articles: The quiet utility is unaware of the OS fracture, VSS, VM snapshot or any other Third Party Tool process used to backup the database environment. Caution must be exercised to not start the operation before the quiet point has been realized or to release the quiet point before the it has completed.

To access the copy of the database:

As a consequence of making a copy of the online database(s), the database Control Area must be updated. Two actions may be necessary to access this database.

1.   Update the database structure file list

If the copied database needs to be accessed from its current location, the .st file must be altered to fully describe the physical location of the copy of the database.  Then change the logical location reference in the Control Area. This is not necessary for single volume databases because a single volume database does not contain a file list.

Update the structure file:
$   prostrct list <dbname> <dbname.st>
Edit the .st text file to update the physical location on disk of every database extent (including AI files).
 
Then use PROSTRCT REPAIR to update the Control Area:
$   prostrct repair <dbname> <dbname.st>

The PROSTRCT REPAIR operation will change:
  • The logical names to their physical equivalents, 
  • The physical file list, to reflect any changes made in the .st file on either type of databases (single or multi-volume)
  • The databases shared memory, and semaphore identification information that previously indicated that the database was active and online.

2. Backup with PROBKUP -norecover

$   probkup <dbname> <device name> -norecover

Using the -norecover option this ensures that should this backup be restored, it is capable of serving as a foundation for future roll forward operations. This option does not put the database through recovery and does not cause any after-image extent switches. An entry that notifies Progress that the option is in effect is written to the database log (.lg) file. Backing up the copied database also:
  • Ensures another level of redundancy when subsequent copies are made that may overwrite the current copy.
  • Serves as a database block integrity check when it succeeds.

Example:  A multi-volume database using disk mirroring to mirror the .db file, the .dn file, and the .bn file.

While this example is specific to a disk mirror fracture operation, the outline of the steps described above applies to any other copy of the database made with anything other than the Progress PROBKUP utility.

The example sets up a primary and a secondary database. 
  • The primary database is the main production DB and the secondary database is at a remote standby site. The remote hot standby site will be initialized by fracturing a mirror and use it to backup from. 
  • The backup will be restored at the secondary site. 
  • After this initial setup, subsequent updates will be achieved through mirror fractures and backups.
The primary database's structure file (.st):
   
b /disk1/primary/site <variable length bi extent>
d /disk1/primary/site f 1024 <fixed length data extent>
d /disk1/primary/site f 1024 <fixed length data extent>
d /disk1/primary/site <variable length data extent>

The OS in this example is set up to see disk 1 as mirrored to a three-disk disk set. 
  • Each mirror contains a complete copy of the database. 
  • The name disk1 is the OS logical disk name. 
  • Each mirrored disk of the three-disk set has a unique OS physical disk name. 
  • Progress uses the OS logical name as if it were a physical disk name.
To fracture a disk on the primary database, first quiesce the database:
$  proquiet <primary dbname> enable

When the quiet point has been raised, the OS command to fracture the disk can be issued. When the OS fractures a mirror from the three-mirror set, the fractured disk is no longer referenced as the OS logical name. It is referenced instead by the OS physical name. 

After the disk fracture is completed, issue the following command:
$  proquiet <primary dbname> disable

Once this command is successfully completed, the fractured disk that contains a copy of the database can be repaired in preparation for the PROBKUP command.

To repair the fractured copy of the database so it can be used, the database Control Area needs to be updated. If a copy of the .st description file of the primary database does not exist on the fractured disk, run PROSTRCT with the list option:
$  prostrct list <dbname> .st file

This .st file must be updated to reflect the OS physical location of the fractured database and not the OS logical location. The following is an example of the necessary alteration:
 
b /mirror1 <variable length bi extent>
d /mirror/1 f 1024 <fixed length data extent>
d /mirror1 f 1024 <fixed leng.th data extent>
d /mirror1 <variable length data extent>

Once the .st file is updated, use it to repair the fractured DB:
$   prostrct repair <dbname> <updated.st file>

This command alters the file list of the fractured database and updates internal DB information to reflect its online status. The fractured database is now ready to be backed up.

The backup is issued by the following command:
$   probkup <fractured dbname> <backup device name> -norecover

Once the PROBKUP is complete, a secondary database can be restored with this backup. Subsequent updates can be achieved by following the aforementioned sequence of commands.
Workaround
Notes
References to Other Documentation:

OpenEdge Documentation: 

OpenEdge Data Management: Database Administration, Backing Up a Database > Performing an operating system backup

Progress Articles: 

What happens when a PROQUIET is requested   
What is PROQUIET NOLOCK?   
Why is it necessary to run rfutil -C aimage sequence on an OS copy ?   

Does Progress support the use of 3rd party backup or replication utilities?   
Can Third Party tools be used to perform online or offline backups ?   
How to configure Veaam to use PROQUIET   
Is OpenEdge VSS aware?  
Last Modified Date11/20/2020 7:14 AM
Attachment 
Files
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.