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
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:
2. Backup with PROBKUP -norecover
- 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.
$ 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:
Example: A multi-volume database using disk mirroring to mirror the .db file, the .dn file, and the .bn file.
- 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.
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's structure file (.st):
- 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.
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.