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:
Include the master database in quiesce database’s list of databases.
Any process that is prevented from writing to disk in a quiesced database may be holding a resource that prevents another process from executing. For example, if a process modifies a database page in a transaction but is prevented from flushing the log pages during the commit, this process is probably holding an exclusive page lock, and may block a reader trying to acquire a shared page lock on the same page during the quiesce database operation.
Although this problem is severe when you quiesce system databases (sybsystemprocs, sybsystemdb, or sybsecurity if auditing is enabled), it is most acute when you quiesce the master database since the master database contains many frequently-used system tables. For example, if a process modifies syslogins with sp_addlogin but is prevented from committing the transaction during the quiesce of the master database, the exclusive page lock acquired to modify syslogins block any logins because these logins must acquire a shared-page lock on syslogins.
Name devices using identical strings on both the primary and secondary servers.
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.
Keep the mapping between syslogins.suid and sysusers.suid 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.
Make external copies of a database using these 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.
The mount and unmount commands make it easier to move or copy databases. You can move or copy a database from one Adaptive Server to another without restarting the server. You can move or copy more than one database at a time using the mount and unmount commands.You can also use these commands to physically move the devices and then reactivate the databases.
When you unmount a database, you remove the database and its devices from an Adaptive Server. unmount shuts down the database and drops it from the Adaptive Server; devices are also deactivated and dropped. No changes are made to the database or its pages when unmounted.
