The simplest way to use quiesce database is to make a full copy of an entire installation. This ensures that system mappings are consistent. These mappings are carried to the secondary installation when the system databases, that contain them are physically copied as part of quiesce database hold’s set of databases. These mappings are fulfilled when all user databases in the source installation are copied as part of the same set. quiesce database allows for eight database names during a single operation. If a source installation has more than eight databases, you can issue multiple instances of quiesce database hold to create multiple concurrent quiescent states for multiple sets of databases.
To create the source installation from scratch, you can use almost identical scripts to create both the primary and secondary installations. The script for the secondary installation might vary in the physical device names passed to the disk init command. This approach requires that updates to system devices on the primary server be reflected by identical changes to the secondary server. For example, if you perform an alter database command on the primary server, you must also perform the same command on the secondary server using identical parameters. This approach requires that the database devices be supported by a volume manager, which can present to both the primary and secondary servers the same physical device names for devices that are physically distinct and separate.
Your site may develop its own procedures for making external copies of database devices. However, Sybase recommends the following:
You include the master database in quiesce database’s list of databases.
You name devices using identical strings on both the primary and secondary servers.
You make the environments for the master, model, and sybsystemprocs system databases in the primary and secondary installations identical. In particular, sysusages mappings and database IDs for the copied databases must be identical on the primary and secondary servers, and database IDs for both servers must be reflected identically in sysdatabases.
The mapping between syslogins.suid and sysusers.suid must remain consistent in the secondary server.
If the primary server and the secondary server share a copy of master, and if the sysdevices entry for each copied device uses identical strings, the physname values in both servers must be physically distinct and separate.
Making external copies of a database has the following restrictions:
The copy process can begin only after quiesce database hold has completed.
Every device for every database in quiesce database’s list of databases must be copied.
The external copy must finish before you invoke quiesce database release.
During the interval that quiesce database provides for the external copy operation, updates are prevented on any disk space belonging to any database in quiesce database’s list of databases. This space is defined in sysusages. However, if space on a device is shared between a database in quiesce database’s list of databases and a database not in the list, updates to the shared device may occur while the external copy is made. When you are deciding where to locate databases in a system in which you plan to make external copies, you can either:
Segregate databases so they do not share devices in an environment where you will use quiesce database, or
Plan to copy all the databases on the device (this follows the recommendation above that you make a copy of the entire installation).
Use quiesce database only when there is little update activity on the databases (preferably during a moment of read-only activity). When you quiesce the database during a quiet time, not only are fewer users inconvenienced, but, depending on the third-party I/O subsystem that is to perform the external copy, there may also be less time spent synchronizing devices involved in the copy operation.
