quiesce database hold allows you to block updates to one or more databases while you perform a disk unmirroring or external copy of each database device. Because no writes are performed during this time, the external copy (the secondary image) of the database is identical to the primary image. While the database is in the quiescent state, read-only queries to operations on the database are allowed. To resume updates to the database, issue quiesce database release when the external copy operation has completed. You can load the external copy of the database onto a secondary server, ensuring that you have a transactionally consistent copy of your primary image. You can issue quiesce database hold from one isql connection and then log in with another isql connection and issue quiesce database release. See the Reference Manual: Commands.
tag_name must conform
to the rules for identifiers. You must use the same tag_name for
both quiesce database...hold and quiesce database...release.
For example, to suspend updates to the pubs2 database, enter:
quiesce database pubs_tag hold pubs2
Adaptive Server writes messages similar to the following to the error log:
QUIESCE DATABASE command with tag pubs_tag is being executed by process 9. Process 9 successfully executed QUIESCE DATABASE with HOLD option for tag pubs_tag. Processes trying to issue IO operation on the quiesced database(s) will be suspended until user executes Quiesce Database command with RELEASE option.
Any updates to the pubs2 database are delayed until the database is released, at which time the updates complete. To release the pubs2 database, enter:
quiesce database pubs_tag release
After releasing the database, you can bring up the secondary server with the -q parameter if you used the for external dump clause. Recovery makes the databases transactionally consistent, or you can wait to bring the database online and then apply the transaction log.
