Under certain conditions, it is desirable to store copies of a particular body of data, such as a relational table, at multiple sites. If users are allowed to update the body of data at one site, the updates must be propagated to the copies at the other sites in order for the copies to remain consistent. The process of propagating the changes is generally referred to as replication. Various mechanisms have been developed for performing replication. Once such mechanism is described in U. S. patent application Ser. No. 08/126,586 abandoned entitled "Method and Apparatus for Data Replication", filed on Sep. 24, 1993 by Sandeep Jain and Dean Daniels, the contents of which are incorporated by reference.
One problem with prior methods of replication pertains to performing administrative operations relating to data replication. Administrative operations differ from a simple modification of a body of data because they affect "metadata," information about the body of data that is separately stored by the database system. Examples of administrative operations include adding a new table to a database, adding a column to a table, deleting a column from a table, and changing the type of a column in a table. Although there are various kinds of administrative operations, all of them are characterized by the fact that they require an update to metadata, which is separately stored by the database.
It is important to ensure that changes due to administrative operations are propagated to all sites where a body of data is replicated to avoid inconsistent updates. For example, a table may be replicated with copies at three sites. At one site, a user may perform an administrative operation to add a column to a table. Shortly thereafter, that change is propagated to another site, where another user subsequently updates a value in the new column. With asynchronous replication, it is possible for these transactions to be replicated to the third site in an order that does not reflect the order in which the transactions actually occurred. Consequently, the third site may receive the administrative operation after the receiving the replication request for updating a value in column that does not yet exist at the third site.
In addition, it is important to ensure that changes due to other kinds of administrative operations, such as replication administration, be propagated consistently. For instance, a user may add a new replication site, modify conflict resolution rules, change the method of propagation (i.e., asynchronous or synchronous) between sites, or other configuration changes. All of these scenarios require a consistent application across replication sites.
Consequently, before any administrative operations are performed at one site for a particular body of data, any activities requiring replication for that body of data must be suspended, or "quiesced," at all sites. Quiescence allows all previously made replication activities to complete, so that all replicated modifications may be performed consistently with respect to the administrative environment at each site. Thus, replication is quiesced at all sites to prevent inconsistent modifications to replicated data.
In conventional methods, quiescence is performed at the database level. In other words, if an administrative task is to be performed for a particular body of data, the entire database is quiesced, even if that administrative task does not affect the validity of transactions performed on other bodies of data. Thus, a single body of data requiring quiescence is sufficient to suspend system replication activities for the entire database system.
On a large database system with many groups of unrelated bodies of data, quiescing the entire database system can substantially affect system availability. System-wide quiescence effectively places the entire system off-line, even though most of the transactions being performed may be unaffected by the administrative task. For these systems, database administrators have found it necessary to schedule their administrative tasks in advance or during the middle of the night.
Consequently, conventional methods of quiescence limit the usability and availability of database systems. In particular, database level quiescence is inefficient because replication activities are suspended for data objects unrelated or unaffected by the need to perform a particular administrative task. Accordingly, it is desirable to have a method and mechanism for performing quiescence that does not cause the entire database system to become unavailable.