Title of Invention: Support for schema evolution in a multi-node peer-to-peer replication environment Abstract: A method, system and article of manufacture of replication are provided. A first replicate comprises a plurality of participants. The first replicate replicates one or more columns of a table. Replication data is transformed between a first local dictionary format and a first common dictionary format at a first participant of the plurality of participants. The replication data is transported in the first common dictionary format among the plurality of participants of the first replicate. The replication data is applied to a table on at least one other participant. Detailed Description: CROSS-REFERENCE TO RELATED APPLICATIONS Co-pending U.S. application Ser. No. ______, entitled “Simulating Multi-User Activity While Maintaining Original Linear Request Order for Asynchronous Transactional Events,” filed concurrently herewith, by Clarence Madison Pruet III, International Business Machines Corporation (IBM) Docket No. SVL920040058US1, assigned to the assignee of the present invention, is incorporated herein by reference in its entirety. Co-pending U.S. application Ser. No. ______, entitled “Replication-Only Triggers,” filed concurrently herewith, by Clarence Madison Pruet III, International Business Machines Corporation (IBM) Docket No. SVL920040058US1, assigned to the assignee of the present invention, is incorporated herein by reference in its entirety. Co-pending U.S. application Ser. No. ______, entitled “Online Repair of a Replicated Table,” filed concurrently herewith, by Rajesh Govind Naicken, Clarence Madison Pruet III, and Konduru Israel Rajakumar, International Business Machines Corporation (IBM) Docket No. SVL920040060US1, assigned to the assignee of the present invention, is incorporated herein by reference in its entirety. BACKGROUND OF THE INVENTION 1.0 Field of the Invention This invention relates to a database management system; and in particular, this invention relates to support for schema evolution in multi-node peer-to-peer replication environment. 2.0 Description of the Related Art Database management systems allow large volumes of data to be stored and accessed efficiently and conveniently in a computer system. In a database management system, data is stored in database tables which organize the data into rows and columns. FIG. 1 depicts an exemplary database table 24 which has rows 26 and columns 28. To more quickly access the data in a database table, an index may be generated based on one or more specified columns of the database table. In relational database management systems, specified columns are used to associate tables with each other. The database management system responds to user commands to store and access the data. The commands are typically Structured Query Language (SQL) statements such as SELECT, INSERT, UPDATE and DELETE, to select, insert, update and delete, respectively, the data in the rows and columns. The SQL statements typically conform to a SQL standard as published by the American National Standards Institute (ANSI) or the International Standards Organization (ISO). Departments within an enterprise may have their own database management systems, typically at different sites. An enterprise typically wants to share data throughout the enterprise. A technique called replication is used to share data among multiple database management systems. A replication system manages multiple copies of data at one or more sites, which allows the data to be shared among multiple database management systems. Data may be replicated synchronously or asynchronously. In synchronous data replication, a two-phase commit technique is used. In a two-phase commit, a transaction is applied only if all interconnected distributed sites agree to accept the transaction. Typically all hardware components and networks in the replication system must be available at all times in for synchronous replication. Asynchronous data replication allows data to be replicated, at least on a limited basis, and thus allows for system and network failures. In one type of asynchronous replication system, referred to as primary-target, all database changes originate at the primary database and are replicated to the target databases. In another type of replication system, referred to as update-anywhere, updates to each database are applied at all other databases of the replication system. An insert, update or delete to the tables of a database is a transactional event. A transaction comprises one or more transactional events that are treated as a unit. A commit is another type of transactional event which indicates the end of a transaction and causes the database to be changed in accordance with any inserts, updates or deletes associated with the transaction. In some database management systems, a log writer updates a log as transactional events occur. Each transactional event is associated with an entry in the log. When a replication system is used, a user typically specifies the types of transactional events which cause data to be replicated. In addition, the user typically specifies the data which will be replicated, such as certain columns or an entire row. In some embodiments, the log writer of the database management system marks certain transactional events for replication in accordance with the specified types of transactional events. The replication system reads the log, retrieves the marked transactional events, and transmits the transactional events to one or more specified target servers. The target server applies the transactional events to the replication table(s) on the target server. A schema is a data structure that describes the columns of a table. A schema specifies the number of columns in a table and the type of data to be stored in the columns of the table. For example, a schema may specify that column one contains integer data, column two contains character data and column three contains floating point data. The schema is changed in order to change the number of columns and/or type of data stored in the columns of the table. If the schema for a table needs to be altered or if the fragmentation strategy needs to be changed then replication is typically stopped, the table is altered, and replication is restarted. However, stopping replication may cause the client applications to shut down. Some database management systems operate in a non-stop environment and stopping replication may cause client applications to stop. In addition, when a schema of a table is altered, one participant of a replicate may be using the new schema which has a new format for a row of a replicated table, while other participants of the replicate may be using an older format of the row. Because the row formats are different, replication may stop. Therefore there is a need for technique to allow the schema of a replicated table to be changed without causing the client applications to stop. SUMMARY OF THE INVENTION To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, various embodiments of a method, system and article of manufacture to replicate data are provided. A first replicate comprises a plurality of participants. The first replicate replicates one or more columns of a table. Replication data is transformed between a first local dictionary format and a first common dictionary format at a first participant of the plurality of participants. The replication data is transported in the first common dictionary format among the plurality of participants of the first replicate. The replication data is applied to a table on at least one other participant. In this way, the schema of a table can be changed without causing client applications to stop. BRIEF DESCRIPTION OF THE DRAWINGS The teachings of the present invention can be readily understood by considering the following description in conjunction with the accompanying drawings, in which: FIG. 1 depicts a block diagram of an illustrative table of a database management system; FIG. 2 depicts a diagram of an embodiment of a replication environment suitable for use with the present invention; FIG. 3 depicts a block diagram of two exemplary replication servers; FIG. 4 depicts a diagram illustrating the normal mode state, that is, a non-alter mode state; FIG. 5 depicts a diagram illustrating the alter mode state; FIG. 6 depicts a high-level flowchart of an embodiment of altering a table; FIG. 7 depicts a flowchart of an embodiment of the processing performed in an alter mode set operation; FIG. 8 depicts a flowchart of an embodiment of advancing the replay position; FIG. 9 depicts a flowchart of an embodiment of the processing of the apply component or thread while one or more replication tables are in alter mode; FIG. 10 depicts a flowchart of an embodiment of the processing performed as part of an alter mode unset operation; FIG. 11 depicts a flowchart of an embodiment of performing replicate reactivation; FIG. 12 comprises FIGS. 12A, 12B and 12C which collectively depict a flowchart of an embodiment of the alter mode set and alter mode unset operations in conjunction with a SQL alter statement; FIG. 13 depicts a flowchart of an embodiment of the alter mode set and unset operation in conjunction with a command line interface; FIG. 14 comprises FIGS. 14A and 14B which collectively depict a flowchart of an embodiment of replicate reactivation of the alter mode unset operation; FIG. 15 depicts a flowchart of an embodiment of the operation of the replication application command line interface in response to a define replicate command; FIG. 16 comprises FIGS. 16A and 16B which collectively depict a flowchart of an embodiment of the option processing of FIG. 15; FIG. 17 depicts a flowchart of an embodiment of the verification of the dictionary information of a participant when the participant is restarted; FIG. 18 depicts a diagram of an embodiment of transmitting a row in the mastered replicate dictionary format; FIG. 19 depicts a flowchart of an embodiment of column conversion performed by the grouper of FIG. 18; FIG. 20 depicts a flowchart of an embodiment of column conversion in connection with the apply component of FIG. 19; FIG. 21 depicts a flowchart of an embodiment of remastering a replicate; FIG. 22 depicts a flowchart of an embodiment of the step of verifying all participants of FIG. 21; and FIG. 23 depicts an illustrative computer system which uses various embodiments of the present invention. To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to some of the figures. DETAILED DESCRIPTION After considering the following description, those skilled in the art will clearly realize that the teachings of the various embodiments of the present invention can be utilized to allow the schema of a table to be changed in a multi-node peer-to-peer replication environment without stopping client applications. A method, system and article of manufacture to replicate data are provided. A first replicate comprises a plurality of participants. The first replicate replicates one or more columns of a table. Replication data is transformed between a first local dictionary format and a first common dictionary format at a first participant of the plurality of participants. The replication data is transported in the first common dictionary format among the plurality of participants of the first replicate. The replication data is applied to a table on at least one other participant. In some embodiments, the replication data is transformed between the first common dictionary format and a second local dictionary format by at least one other participant of the first replicate, and applied to the table on that other participant based on the second local dictionary format. In various embodiments, the first local dictionary format is the same as the second local dictionary format. In other embodiments, the first local dictionary format is different from the second local dictionary format. A database server is a software application which implements a database management system. A replication server is a database server that participates in data replication. Multiple database servers can execute on the same physical server computer, and each database server can participate in replication. A database or replication server that participates in a replicate may also be referred to as a node. In replication, changes to one or more tables of a database on a source replication server are collected, transported and applied to one or more corresponding tables on replication target servers. A replication application implements the replication server functionality. To replicate data, a user defines a replicate, that is, the user provides a replicate definition. A replicate is associated with one or more replication servers, also referred to as participants or nodes, a table to replicate among the participants, and the columns of the table that will be replicated. The replicate is also associated with various attributes which describe how to replicate the data among the participants, such as conflict resolution rules. The replication server maintains replication information in a replicate definition that comprises one or more tables in the global catalog. The replicate definition comprises information specifying the replicate configuration and environment, data transportation format, information specifying what data is to be replicated, for example, whether to replicate particular columns or an entire row, and information specifying the conditions under which the data should be replicated. The replicate definition also specifies various attributes of the replicate such as a description of how to handle any conflicts during replication. For example, the replication definition comprises a replicate identifier, the name of the replicate, the table(s) of the replicate, the columns to replicate, the SQL select statement which created the replicate, and various flags. The flags comprise a replicate-alter-mode flag, a table-alter-mode flag and a data-conversion flag. The replication application creates the global catalog when the replication application is initialized. In embodiments which use the IBM Informix Dynamic Server, the global catalog is called the syscdr database. Each replication server typically has its own local copy of the global catalog and maintains one or more tables in the global catalog to keep track of the replicate definition and state. The global catalog is created when a database server is defined as a replication server. The tables in a global catalog on one replication server are typically automatically replicated to the global catalogs of the other replication servers. FIG. 2 depicts a diagram of an embodiment of a replication environment suitable for use with the present invention. A source replication server 30 and a target replication server 32 are participants in a replicate. The source replication server 30 and the target replication server 32 will be referred to as a source server and a target server. The source server 30 and the target server typically execute on different computer systems. In the source server 30, one or more user applications 34 are accessing and changing the tables of a database 36. The changes to the database 36 are stored in a log 38. The changes to the data are transactional events, and the transactional events are stored in the log. The replication application comprises a snooper 40 and a grouper 42. The snooper 40 reads the log 38 and captures various changes to the database in accordance with the replicate definition. The grouper 42 assembles the captured changes in accordance with their associated transactions to provide transaction replication data 43 and places the transaction replication data 43 in a queue 44 to send to the target server 32 via the network interface (NIF) 50. As indicated by arrows 45, the queue 44 can be used to send and receive data. The queue 44 comprises a send queue to send data to the target server 32, and a receive queue to receive data from the target server 32. In the target server 32, the transaction replication data 51 is received in a queue 52. An apply component 54 retrieves the transaction replication data 51 from the queue 52 and applies the replication data 51 to the appropriate table and column(s) in the database 56. The source and target servers, 30 and 32, have global catalogs, 62 and 64, and a replication application command line interface, 66 and 68, respectively. The replication application command line interface 66 and 68 receives commands for the replication application, and executes those commands. The replication application command line interface 66 and 68 is also used to update the global catalogs 62 and 64, respectively. In various embodiments, the replication application on a replication server typically comprises a snooper, a grouper and an apply component. In this way, data can be replicated both to and from the replication server. In some embodiments, a computer system executing the replication application comprises multiple central processing units or processors, and various portions of the replication operation are executed concurrently. For example, the apply component may execute on one or more processors and each portion of the apply component that executes on one processor is referred to as an apply thread. A table of a database has one or more columns. A schema contains a definition of the table such as the name of the columns, the number of columns, the position of the columns in the table and the type of data stored in the columns. In other words, the schema specifies the format of the table. The schema may also be referred to as a local dictionary of the table. The term, replication table, refers to a table that is replicated. In a multi-node peer-to-peer replication environment, the schema for a replication table may be changed on one node while the schema on the other nodes remains unchanged. In database management systems which use replication, when the schema of a replication table is changed, it is desirable that the replication application dynamically detect the schema change and adjust its internal structures in accordance with the new format specified by the changed schema. It is also desirable that client applications be able to change the underlying replication table's schema without having any knowledge of the replication application. A row image refers to row data of a particular table version, that is, a particular schema. After each “alter” operation, a table version is incremented by one. It is desirable that the replication application understand any version of the row image. It is also desirable that any version of a row image be converted to the current version of the table. In various embodiments, the replication application sends and receives data in a common format that both the sender and receiver understand. A local table dictionary contains metadata which describes the storage characteristics of the table, that is, the schema. In other words, the local table dictionary is the schema of the table. In the global database, catalog tables contain internal data such as the replication topology and information describing the underlying replication table(s). In some embodiments, the replication application stores a replication table dictionary in catalog tables. The replication table dictionary provides a common dictionary format that both the sender and receiver recognize for a replicate. Data of a replicate is transported using the common dictionary format. The replication application converts any version of the row image between the local dictionary format and the common dictionary format. The common dictionary format is referred to as a mastered dictionary format. The mastered dictionary format is achieved through a technique referred to as mastered replicates, which will be described in further detail below. The replication application typically depends on the underlying database server to convert the row data from an older version format to a current version format. In response to receiving a SQL command to alter a table, the database server notifies the replication application before altering the replication table, that is, changing the schema, which is referred to as pre-alter event notification. The database server also notifies the replication application after performing altering the table, that is, changing the schema, which is referred to as post-alter event notification. In response to pre-alter event notification, the replication application prepares for the schema change to the underlying replication table. For example, a shadow table is a mirror image of the replication table which is used to store deleted rows from the replication table. A conflict resolution component of the replication application utilizes the shadow table to resolve conflicts while applying replicated data to the replication table. In response to a post-alter event notification event, the replication application changes its internal structures, such as data structures and the schema of the shadow table, in accordance with the new table schema format. In some embodiments, an “alter mode set” operation provides pre-alter event notification and an “alter mode unset” operation provides the post-alter event notification. In various embodiments, a user issues a SQL alter statement to alter a table. As part of performing the SQL alter statement, the database server issues the alter mode set and alter mode unset operations. In other embodiments, a user explicitly issues an alter mode set request, alters one or more tables, and then issues an alter mode unset request. The alter mode set request causes the alter mode set operation to be performed. The alter mode unset request causes the alter mode unset operation to be performed. In some embodiments, a user issues the alter mode set and unset requests when attaching a fragment to a table. To attach a fragment to a table, a user issues an alter mode set command, drops the primary key, attaches the fragment, recreates the primary key and issues an alter mode unset command. The term “replication domain” refers to the participants or nodes of a replicate. When a table of a replicate is altered, it is sometimes desirable to seamlessly switch the replicate definitions. It is difficult to alter a table on all nodes within the replication domain and ensure that there are no pending transactions queued when the alter occurs. This is especially a problem when the replicates are “update anywhere” because the table which was altered may be receiving data in the older format. For example, consider a bi-directional replication in which a table, called Tab1, is replicated between database server-A and database server-B. At any point in time, changes for Tab1 may exist in a send queue on database server-A and additional changes for Tab1 may exist in a send queue on database server-B. In some replication applications, Tab1 is altered at a point of singularity in which all queues are emptied of pending changes and the alter is issued on all participants of the replicate at the same point. In various embodiments, a staging approach is used to alter a replication table on the participants of a replicate, rather than using a point of singularity. In the staging approach, multiple replicates which are associated with each other are used. Using the staging approach, a single apply component or thread can support data arriving from multiple sources. The apply component or thread at the target server considers the different associated replicates to be equivalent, but the snooper at the source server uses a specific version of the table. By using this approach, the changes to the table's schema can be staged. FIG. 3 depicts a block diagram of two exemplary replication servers, Server-A 70 and Server-B 72. Server-A 70 has a table named Table1 74 and Server-B also has a table named Table1 76. A first replicate comprising Server-A 70 and Server-B 72 for Table1 uses a first version of Table1, Table1v1 80. On Server-A 70, the schema for Table1 74 has been changed. A second replicate comprises Server-A 70 and Server-B 72 uses a second version of Table1, Table1v2 82. The second replicate is associated with the first replicate. In the send queue 78, data for the two replicates of Table1, called Table1v1 80 and Table2v2 82, is being sent to Server-B 72. In the send queue 84 on Server-B 72, data is being sent for a single version of Table1, Table1v1 86, to Server-A 70. The apply component or thread on Server-B 72 considers the first and second replicates to be equivalent. The apply component or thread treats the replicated data from the first and second replicates as though the replicated data were received from a single replicate. In some embodiments, a technique called versioned replicates is used to associate the first and second replicates with each other. In another embodiment, a technique called shadow replicates is used to associate the first and second replicates with each other. Various embodiments of the invention will be described with reference to shadow replicates. However, the invention is not meant to be limited to shadow replicates and versioned replicates, and other techniques may be used. A shadow replicate is a replicate which is defined to be used in conjunction with another replicate which is referred to as a primary replicate. The shadow replicate can have some differences from the primary replicate. For instance, the shadow replicate may include different columns from the primary replicate, or may involve a subset of less than all of the servers or nodes used by the primary replicate. In addition, the shadow replicate may have different conflict resolution rules from the primary replicate. The source replication server will typically transmit replicated data using the primary replicate. The apply component or thread on the replication target server considers the shadow and primary replicates as equivalent. By having the apply component or thread consider the first and second replicates as equivalent, the shadow replicate is used to maintain proper ordering, and the rules for parallelism can be common for the two replicates. The rules for parallelism refer to the rules for processing replicated data concurrently, that is, in parallel. This helps to maintain proper ordering for any common row within the two replicates. Co-pending U.S. application Ser. No. ______, entitled “Simulating Multi-User Activity While Maintaining Original Linear Request Order for Asynchronous Transactional Events,” filed concurrently herewith, by Clarence Madison Pruet III, International Business Machines Corporation (IBM) Docket No. SVL920040058US1, describes various embodiments of processing replicated data concurrently. In addition, a primary replicate may be associated with more than one shadow replicate. Shadow replicates are described in further detail in U.S. application Ser. No. ______, entitled “Online Repair of a Replicated Table,” filed concurrently herewith, by Rajesh Govind Naicken, Clarence Madison Pruet III, and Konduru Israel Rajakumar, International Business Machines Corporation (IBM) Docket No. SVL920040060US1. In various embodiments, the replication application sustains schema changes to the underlying replication table(s) without any interruption to the replication traffic and client applications. In some embodiments, the following techniques are used to support schema evolution during replication: mastered replicates, alter mode set and unset operations, shadow replicates and a remastering process. A mastered replicate is a replicate which contains additional dictionary information that describes the replicate table definition and the data transportation format. In various embodiments, a replicate, including a mastered replicate, is defined by using a query statement against the table being replicated, much like a conventional SQL select statement. The query statement specifies one or more columns of a table to replicate. When defining a mastered replicate, by referencing a node or replication server which has a description of the specified columns of the query which is used to define the replicate, dictionary information which is used to describe the replicate transport format is obtained. This dictionary information is stored in one or more tables in the global catalog to provide a mastered dictionary. The mastered dictionary is used as the common transport format for the replicate, which is referred to as a mastered replicate. As nodes are added to the mastered replicate, the description of the replicated columns of a table in a local dictionary on the node is compared to the corresponding description in columns in the mastered dictionary. If the description of any column of the local dictionary is not compatible, or alternately, does not match, with the description of the corresponding column in the mastered dictionary, the addition of the node to the replicate is rejected. In various embodiments, the description of the columns in the mastered dictionary of the mastered replicate is also compared with the description of the corresponding columns in the local table dictionary as replication is started on each node of the replicate. If the description in the mastered dictionary matches, or is compatible with, the description in the local table dictionary, replicated data is moved to and from the queue without any conversion to and from the mastered dictionary format, respectively. If the description of any column in the mastered dictionary does not match, or is not compatible with, the description of the corresponding column in the local table dictionary, column conversion will be performed as data is moved to and from the queue. Remastering is a process in which a new mastered primary replicate is created based on the existing mastered primary replicate and the new schema definition. The new mastered replicate uses the new schema definition of the table. After remastering, the original mastered primary replicate becomes a mastered shadow replicate of the new mastered primary replicate. The new mastered primary replicate propagates replicated data in the new mastered dictionary format which is based on the new schema. The user typically alters the schema of the replicated table on the other nodes which participate in the replicate, and remasters the replicate after altering the schema of the table at all the replication participants. The remastering process will be described in further detail below in the description of mastered replicates. In various embodiments, to create a new replicate definition, the definition in the schema or dictionary of the columns of the replicate matches at all the participants of the replicate, otherwise the creation of the new replicate definition will fail. The definition of a column is determined to match if it has the same data type at all the participants. In various embodiments, the definition of a column is determined to match if it has a compatible data type at all the participants. In another embodiment, in response to a name verification replicate attribute being set, the definition of a column is determined to match if the column name is the same at all participants in addition to the data type being compatible. In some embodiments, certain data types are considered to be equivalent and are therefore compatible. In various embodiments, within a database server and the replication application, all large object types (LOBS) are considered to be equivalent. There are additional data types which are considered to be equivalent if they represent distinct variables of the same fundamental data type. In some embodiments, if a serial column on one node is fundamentally an integer type, that serial column can successfully replicate to an integer column on a target node. In other embodiments, a column having a data type of money can successfully replicate to a column having a data type of decimal. For example, after an alter which adds a column to a replicated table is performed at all the replicate participants, the user can “remaster the replicate” to add the new column to the replicate definition. As part of the remastering process, a shadow replicate is created which comprises the new column. The shadow replicate is swapped with the original replicate. Since the apply component treats the primary and shadow replicates as equivalent, the apply component can process data from either replicate while sending data in the new replicate. If remastering is not performed, data for the newly added column will be discarded at the source server itself while converting data from the local table dictionary format to the mastered dictionary format for transportation. In various embodiments, the alter mode set operation provides pre-alter event notification to the replication application, and the alter mode unset operation provides the post-alter notification to the replication application. Alter mode is a state of a replicated table. The alter mode state may be indicated by a flag which is associated with the table. In response to an alter mode set operation on one or more tables, the replication application sets those tables to alter mode. While in alter mode, typically only data definition language (DDL) and select operations are allowed on a table. Data manipulation language (DML) operations comprise insert, update and delete operations. DML operations are typically disallowed on the table in alter mode, except that internal threads of the replication application can perform DML operations on the table. FIG. 4 depicts a diagram illustrating the normal mode state, that is, a non-alter mode state. Client applications, Client-A 90 and Client-B 92, are generating transactions which affect a replication table 94. The replication table 94 has two columns named A and B. The client applications, Client-A 90 and Client-B 92, are performing DML operations 96 on the replication table 94. The client applications, Client-A 90 and Client-B 92, cannot perform DDL operations 98 on the replicated table 94 as indicated by the “x” 100. FIG. 5 depicts a diagram illustrating the alter mode state. Because the replication table 94 is in the alter mode state. The client applications, Client-A 90 and Client-B 92, are performing DDL operations 98 on the replication table 94. The client applications, Client-A 90 and Client-B 92, cannot perform DML operations 98 on the replication table 94 as indicated by the “x” 102. FIG. 6 depicts a high-level flowchart of an embodiment of altering a table. In step 102, a command to alter a replication table is received. In step 104, alter mode is set. In step 106, the schema of the table is changed in accordance with the alter command. In step 107, the replication table is altered. Typically the database engine alters the replication table. In step 108, alter mode is unset. In step 109, internal data of the replication application is updated in accordance with the new schema. In some embodiments, in step 110, after the table on each node of the replicate has been altered, a user remasters the replicate based on the new schema. A replay position is the point where replication would have to begin re-snooping the data in the log in case the database server fails. The current log position refers to the database server's log writer's current position in the log. The log writer of the database server writes the next log record at the current position in the log. Replay position advancement to the current log position is not triggered if the alter operation type is an in-place alter or if the local server is a receive-only participant. FIG. 7 depicts a flowchart of an embodiment of the processing performed in an alter mode set operation. In various embodiments, the flowchart of FIG. 7 is performed by the replication application. In step 112, alter mode is set on the affected replicates. In some embodiments, alter mode is set on the affected replicates by setting a replicate-alter-mode flag for each affected replicate. The affected replicates are those which replicate one or more columns of the replication table being altered. In some embodiments, the affected replicates comprise a primary replicate for the replication table and any associated shadow replicates. In some embodiments, alter mode is set on the affected replicates which are in the cache. In step 114, the apply component or thread is notified of alter mode on the replication table. In some embodiments, the setting of the replicate-alter-mode flag notifies the apply component or thread. In step 116, the replication table is exclusively locked. The replication table is exclusively locked to block user threads from accessing the replication table. In step 118, a table-alter-mode flag is set on the replication table's partition header(s). Setting the table-alter-mode flag on the replication table's partition header prevents any other user from opening the replication table. Thus, a point of singularity is provided for the table so that no other user can access the table. In step 120, the replication table is unlocked. In step 122, the current log position is stored. The database server writes the next log record at the current log position. Step 124 determines whether the alter algorithm is an in-place alter algorithm or if the local replication server is a read-only participant. An in-place alter algorithm allows a table to be altered in-place instead of creating a new table with the new schema and copying rows from the old table to the new table. If step 124 determines that the alter algorithm is an in-place alter algorithm or if the local replication server is a read-only participant, step 124 proceeds to step 126 and the flowchart ends. If step 124 determines that the alter algorithm is not an in-place alter algorithm and that if the local replication server is a not read-only participant, in step 128, the data in the send queue is spooled to stable storage, such as disk storage, until the replay position reaches the current log position. Step 128 proceeds to step 126. FIG. 8 depicts a flowchart of an embodiment of advancing the replay position. The flowchart of FIG. 8 implements step 128 of FIG. 7. Step 132 determines whether the snooper is down. For example, the snooper is down when the snooper is not being executed; and the snooper is not down when the snooper is being executed. If step 132 determines that the snooper is down, in step 134, the flowchart ends. If step 132 determines that the snooper is not down, in step 136, the current log position is retrieved. Step 138 determines whether the replay position is less than the current log position. If not, in step 134, the flowchart ends. If step 138 determines that the replay position is less than the current log position, step 140 determines whether the grouper and snooper are idle and whether the send queue is empty. If so, in step 142, a dummy log record is inserted into the log to advance the replay position, and step 142 proceeds to step 444. If step 140 determines that the grouper and snooper are not idle or that the send queue is not empty, in step 144, the data in the send queue data is spooled to the disk and the replay position is advanced. The replay position is advanced in accordance with the log position of the log data in the send queue that was spooled. Step 144 proceeds to step 138. FIG. 9 depicts a flowchart of an embodiment of the processing of the apply component or thread while one or more replication tables are in alter mode. In step 152, the replicated data for a next transaction is retrieved from the receive queue. Step 154 determines whether the transaction is touching any of the tables which are in alter mode or whether the transaction is touching tables which have a parent/child relationship with the tables that are in alter mode. If so, in step 156, the processing mode is switched to the next database server, and step 156 proceeds to step 154. If step 154 determines that the transaction is not touching any of the tables which are in alter mode and that the transaction is not touching tables which have a parent/child relationship with the tables that are in alter mode, in step 158, the transaction is applied, that is, the replicated transactional events of the transaction are applied. In step 160, an acknowledgment is sent. The acknowledgment is sent to the source database server of the transaction to indicate that the transaction was applied. In some embodiments, the acknowledgment is a post-commit success trigger. Co-pending U.S. application Ser. No. ______, entitled “Replication-Only Triggers,” filed concurrently herewith, by Clarence Madison Pruet III, International Business Machines Corporation (IBM) Docket No. SVL920040058US1, describes various embodiments of a post-commit success trigger. In step 162, the transaction is purged from the receive queue. Step 164 determines whether there are more transactions in the receive queue. If not, the flowchart ends in step 166. If step 164 determines that there are more transactions in the receive queue, step 164 proceeds to step 152. FIG. 10 depicts a flowchart of an embodiment of the processing performed as part of the alter mode unset operation. In some embodiments, the flowchart of FIG. 10 is performed in step 108 of FIG. 6. In step 172, alter mode is unset on the affected replication tables. In various embodiments, the table-alter-mode flag is unset in the affected partition headers of the replicated table(s). In step 174, for each affected replicate, replicate reactivation is performed. In step 176, the flowchart ends. FIG. 11 depicts a flowchart of an embodiment of performing replicate reactivation. A delete table contains the contents of rows that have been deleted from an associated table. Step 178 determines whether a delete table which is associated with an altered table has been altered. If not, in step 180, the delete table is altered according to the new replication table format specified in the schema. Step 180 proceeds to step 182. If step 478 determines that the delete table has been altered, step 178 proceeds to step 182. In some embodiments, the replicate-alter-mode flag of the replicate is unset as part of replicate reactivation. Step 182 determines whether there are more replicates. If not, in step 184, the flowchart exits. If step 182 determines that there are more replicates, in step 186, the information for the next replicate is retrieved and step 186 proceeds to step 178. FIG. 12 comprises FIGS. 12A, 12B and 12C which collectively depict a flowchart of an embodiment of the alter mode set and alter mode unset operation in conjunction with a SQL alter statement. In step 192, a SQL transaction is received. In step 194, the SQL statement is parsed. In step 196, the type of SQL operation of the SQL statement is detected. Step 198 determines whether the SQL operation is a DDL operation. For example, a DDL operation may be an alter table or alter fragment operation, or a clustered index creation. If not, step 200 determines whether the SQL operation is an insert, delete or update operation. If not, in step 202, the SQL statement is executed. Step 204 determines whether alter mode was set in the same transaction. The same transaction refers to the transaction associated with the SQL operation. If not, the transaction is committed/rolledback. If the transaction was explicitly started by the user, then the user will explicitly commit or rollback the transaction using the “commit work” or “rollback work” SQL statement. If the transaction is implicitly started by the database server, then the database server implicitly commits the transaction if the operation succeeded, otherwise it will rollback the transaction. If step 204 determines that alter mode was set in the same transaction, in step 206, alter mode is unset, and step 206 proceeds to step 208. If step 204 determines that alter mode was not set in the same transaction, step 204 proceeds to step 208. If step 198 determines that the SQL operation is a DDL operation, step 212 determines whether a replicate is defined on the table. If not, step 212 proceeds to step 202 to execute the SQL statement. If step 212 determines that a replicate is defined on the table, step 212 proceeds via Continuator A to step 214 of FIG. 12B. In step 214, the type of alter operation is found. Step 216 determines whether the alter is a fast alter. A fast alter may be an alter that adds SQL constraints, adds default values, drops SQL constraints and drops default values. A SQL constraint places a limit on the values that may be inserted into a column or table. If not, step 218 determines whether the table is already in alter mode. If not, in step 220, alter mode is set. Step 220 proceeds via Continuator D to step 202 of FIG. 12A. If step 200 determines that the SQL operation is an insert, delete or update, step 200 proceeds via Continuator B to step 222 of FIG. 12C. Step 222 of FIG. 12C determines whether the table in alter mode. If so, step 224 determines whether the current thread is a replication thread. If not, in step 226, an error is returned. If step 222 determines that the table is in alter mode, step 222 proceeds via Continuator D to step 202 of FIG. 12A. If step 224 determines that the current thread is a replication thread, step 224 proceeds via Continuator D to step 202 of FIG. 12A. If step 216 of FIG. 12B determines that the alter is a fast alter, step 216 proceeds via Continuator D to step 202 of FIG. 12A. If step 218 determines that the table is already in alter mode, step 218 proceeds via Continuator D to step 202 of FIG. 12A. In some embodiments, users can explicitly set and unset the alter mode state on one or more replicated tables through a command line interface module instead of implicitly setting alter mode through a SQL alter statement which uses the pre-event notification and post event notification. Using the command line interface, users can issue an alter mode set request before attempting alter operation(s) for one or more replicated table(s) and an alter mode unset request after completing alter operation(s) for one or more replicated tables. Using this approach for certain kinds of alter operations, users can reduce the amount of time for performing multiple alter mode set and unset operations for each alter operation. If the alter mode is set through the command line interface, the database engine will not invoke an alter mode set operation and alter mode unset operation as part of the SQL alter statement execution. For example, to attach a new fragment to a replicated table the user manually sets and unsets alter mode through the command line interface. First the user will set alter mode on the replicated table, after that the user will drop the primary key on the replicated table, attach the new fragment to the replicated table and recreate the primary key on the replicated table. The user will then unset alter mode on the replicated table using the command line interface. FIG. 13 depicts a flowchart of an embodiment of the alter mode set and unset operation in conjunction with a command line interface. When a user issues an alter mode set and an alter mode unset command using the command line interface, the user also specifies one or more tables that are to be placed in alter mode. In step 232, the options of the alter mode command are parsed. In step 234, a table list is built. The tables are those specified by the user in the alter mode set or unset command. Step 236 connects to a specified server. In some embodiments, the specified server name follows the “-connect” option. Step 238 determines whether an alter mode set request was received. If not, the alter mode request is an alter mode unset operation request and, in step 240, the alter mode request is formatted to an alter mode message. If the alter mode request is to set alter mode, the alter mode message is to set alter mode. If the alter mode request is to unset alter mode, the alter mode message is to unset alter mode. In step 242, the message is sent to the specified server. In step 244, the execution status of the alter mode message is retrieved from the server. If step 238 determines that the alter mode request is an alter mode set request, step 248 determines whether classic replicates are used. Classic replicates do not have a mastered dictionary defined on any of the tables in the replicate. If not, mastered replicates are being used and step 248 proceeds to step 240 to format an alter mode message which sets alter mode. If step 248 determines that classic replicates are being used, in step 250, an error is returned. FIG. 14 comprises FIGS. 14A and 14B which collectively depict a flowchart of an embodiment of replicate reactivation of the alter mode unset operation. In replicate reactivation for an alter mode unset operation, the replicate definition is recycled to reflect the new schema changes to the replicate table definition. In various embodiments, the flowchart of FIG. 14 is implemented in the replication application. In step 262, replicate map information is retrieved. Typically the replicate map is stored in a cache. The replicate map typically comprises information about the replicate definition specific to the local participant such as a reference to the replicate table dictionary information, a reference to the replicate mastered dictionary information, an attribute, for example, the data-conversion flag, which describes whether data conversion is to be performed between the local table dictionary format to the mastered dictionary format for transporting data and replicate column mapping information. Column mapping is used when the order of columns selected by the user in the replicate select statement and the physical order of the columns in the replicated table are different. In step 264, the replicate definition is deleted from the grouper of the replication application. In step 266, the old SQL dictionary information is freed. In step 268, the replicate select statement which was used to create the replicate is parsed and the SQL dictionary information is recreated. The dictionary information recreated from the replicate select statement is in the local dictionary. In step 270, the newly created local SQL dictionary information for the table is verified with the mastered replicate dictionary information for the table. Step 272 determines whether the primary key
{'app_number': None, 'application_number': '<application-reference appl-type="utility">\n<document-id>\n<country>US</country>\n<doc-number>11060986</doc-number>\n<date>20050218</date>\n</document-id>\n</application-reference>', 'doc_number': None, 'publication_number': '<publication-reference>\n<document-id>\n<country>US</country>\n<doc-number>20060190497</doc-number>\n<kind>A1</kind>\n<date>20060824</date>\n</document-id>\n</publication-reference>', 'source_file': './application/2006/ipa060824.xml', 'source_data': 'USPTO-Application'}