Status: Verified
GOAL:
How Database Quiet Points Work?
GOAL:
What is Proquiet used for?
GOAL:
How proquiet is used when splitting a mirror?
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
If OS disk mirroring or Volume snapshot utilities are used to provide data redundancy as part of a backup and recovery strategy, the database quiet points feature needs to be used on the running database. This feature was introduced starting with Progress Version 8.2 to present to maintain database consistency during an OS mirror fracture or split operation on an active online database.
The quiet utility command (quiet points) with two options was added to the PROSHUT command in order to maintain database consistency during an operation that either fractures or splits an OS mirror. The quiet utility allows a quiet processing point in the database. A quiet processing point is a point in time where all writes to the database file cease and are guaranteed to remain quiet until the quiet point is lifted.
When the quiet command is issued with the enable option, all file write activity to the database ceases until the quiet point has been disabled. Any processes that connect and attempt to start transactions also wait for the quiet point to be lifted. The database broker is responsible for enabling and disabling the quiet point. It notifies the quiet utility when that action has occurred.
The syntax of the quiet command is as follows:
proquiet <dbname> -C enable
This command requests that the broker run a quiet point for the database. 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. Progress Solution P41028, "What are the return codes for proquiet" discusses these in more detail.
NOTE: The quiet utility requires that after image extents be in use if after imaging is enabled. The enabling of the a quiet point causes an after image extent switch. 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. Please refer to Progress Solution P112492, "What is Proquiet nolock?" for further details and considerations of implementing this feature.
The database broker ends a quiet point when the quiet point is released:
proquiet <dbname> -C disable
The quiet utility is unaware of the OS fracture process, so caution must be exercised when performing a mirror splitting or fracturing operation to not start the fracture before the quiet point has been realized or to release the quiet point before the fracture has completed. In addition to the quiet disable command, any shutdown request (normal or abnormal) gracefully disables the quiet point. Otherwise the utility returns a non-zero return code that indicates the command was unsuccessful. The PROQUIET command is available only with the Enterprise database license.
To repair the copy of the database that is on the split mirror, use the following:
prostrct repair <dbname> <dbname.st>
Single and multi-volume databases are supported during mirror fracture operations. When a mirror fracture occurs, the fractured disk contains a copy of the online databases. As a consequence of making this copy, the database must be altered to understand that the copy is no longer active or online.
Two actions might be necessary to fix fractured versions of the database:
- Alter the database file list.
If the database is multi-volume, the .st file must be altered to describe the physical location of the fractured copy of the database.
The OS mirroring facility references the active database by its logical location. A fracturing of the mirror makes it necessary to change the logical location reference in the .st file for the physic.al location reference (site of the fractured mirror).
It is not necessary to change the logical location reference for single volume databases because a single volume database does not contain a file list.
- Use PROSTRCT Repair to change the logical names to their physical equivalents, the physical file list, the databases shared memory, and semaphore identification information.
On multi-volume databases, the PROSTRCT Repair Utility changes the file list information to reflect any changes made in the .st file on both types of databases.
The utility also updates the shared memory and semaphore information that previously indicated that the database was active and online.
To backup a fractured database with PROBKUP, type the following:
probkup <dbname> device name -norecover
The probkup command supports the backing up of the fractured databases by the user of the -norecover option. This option does not put the database through recovery and does not cause any after-image extent switches.
It is extremely important that fractured databases are backed up with the -norecover option this ensures that once the database is restored, it is capable of serving as a foundation for future roll forward operations.
When the fractured database is backed up with the -norecover option, an entry that notifies Progress that the option is in effect is written to the database log (.lg) file.
The following is an example of a multi-volume database using disk mirroring to mirror the .db file, the .dn file, and the .bn file.
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 db's .st file look like:
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>
b /disk1/primary/site <variable length bi 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, issue the following command:
proquiet <primary dbname> enable
When this command is completed, 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, you must make a change to a copy of the .st description file of the primary database. If a copy of the .st file does not exist on the fractured disk, you can obtain a copy of the .st file by running PROSTRCT with the list option as follows:
prostrct list <dbname> .st file
You can also use an OS copy of the .st file. This 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:
d /mirror/1 f 1024 <fixed length data extent>
d /mirror1 f 1024 <fixed leng.th data extent>
d /mirror1 <variable length data extent>
b /mirror1 <variable length bi extent>
Once the .st file is updated, use it to repair the fractured DB by running the following command:
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
NOTE: The use of the -norecover option assures that the database does not go through crash recovery or cause an after image extent switch. When the -norecover option is used, an entry is made in the dbname.lg file to reflect its use.
Once the PROBKUP is complete, the secondary database can be restored with this backup. Subsequent updates can be achieved by following the aforementioned sequence of commands..