Level: Introductory Nagaraju Inturi (nagaraju@us.ibm.com), IBM Informix Software Engineer, IBM
09 Jun 2005 This article describes schema evolution (the support of alter table operations for replicated tables) in the Enterprise Replication environment. Schema evolution support in Enterprise Replication is a new feature for IBM® Informix® Dynamic Server Version 10.00. This feature lets you perform certain tasks while Enterprise Replication is running 24x7, without any downtime for the client applications.
Introduction
IBM Informix Dynamic Server Version 10.00 supports many more alter operations on replicated tables than previous releases did. Most of these alter operations can be performed while Enterprise Replication is running. All the newly supported alter operations require the replicates to be master replicates. After performing certain alter operations, you may need to remaster the replicate.
Note that this article does not provide DDL replication information.
Supported alter operations
When Enterprise Replication is active and data replication is in progress, the following alter operations are supported for replicated tables:
- Adding or dropping fragments
- Attaching or detaching fragments
- Moving a non-fragmented table from one dbspace to another dbspace
- Converting a fragmented table to a non-fragmented table
- Converting a non-fragmented table to a fragmented table
- Converting from one fragmentation strategy to another fragmentation strategy
- Changing an existing fragment expression on an existing dbspace
- Moving a fragment expression from one dbspace to a different dbspace
- Adding, dropping, or modifying columns
- Creating a clustered index
- Reclustering an existing index
These are in addition to the alter operations supported in releases prior to Version 10.00:
- Adding or dropping default values, and SQL checks
- Adding or dropping unique, distinct, or foreign key constraints
- Altering the locking granularity
- Altering the next extent size
Master replicates are required
A replicated table can be altered when only mastered replicates are defined for the table. If any non-mastered replicates are defined for the table, altering the replicated table is not allowed.
A master replicate extracts replicated table dictionary information from the master server (specified with the -M option in cdr define repl command) and stores it in the syscdr database. This dictionary information is called a master dictionary. When you add a new participant to the master replicate definition, the master dictionary is compared to the participant table's dictionary. If the master dictionary information matches the participant table's dictionary information, the new participant is added. Replication data for a master replicate is always transmitted in the master dictionary format. Before putting replication data into the send queue, the source server first converts the data from the local table dictionary format to the master replicate dictionary format. Similarly, before applying replication data, a target server first converts replication data that is in mastered dictionary format to the local table dictionary format.
The following Enterprise Replication command creates a master replicate named rep1. The master dictionary is taken from the master server g_serv1:
cdr define repl rep1 -M g_serv1 -C "timestamp" -S transaction -A -R
"test@g_serv1:nagaraju.tab" "select * from tab" "test@g_serv2:nagaraju.tab"
"select * from tab"
|
Altering a replicated table
There are two ways to alter a replication table:
- Directly issue the alter statement against the replication table. For example:
dbaccess test - <<EOF
Alter table tab add col3 int;
EOF |
- Use the CDR command line interface:
- Set alter mode on one or more replicated tables.
- Alter the replicated table.
- Unset alter mode on the replicated tables.
When to use the CDR command line
In order to attach a fragment on a replicated table, you must use the CDR command line interface, and place the table in alter mode.
Normally, to attach a new fragment, you perform these three steps:
- Drop the primary key.
- Issue the ATTACH FRAGMENT alter statement.
- Recreate the primary key.
On a replicated table, use alter mode to prepare Enterprise Replication for the alter operation:
- Use the
cdr alter --on command to place the replicated table in alter mode.
- Attach the new fragment to the replicated table, using the three-step process shown above.
- Use the
cdr alter --off command to unset alter mode on the replicated table.
The following example illustrates attaching a fragment to a replicated table:
cdr alter -c g_serv1 -on test:nagaraju.tab12 ## Set alter mode
Dbaccess test - <<EOF
Alter table tab12 drop constraint pk1;
alter fragment on table tab12 attach tab12_1;
alter table tab12 add CONSTRAINT primary key (col1) CONSTRAINT pk1;
EOF
cdr alter -c g_serv1 -off test:nagaraju.tab12 ## Unset alter mode
|
If you need to perform multiple alter operations on one or more replicated tables, using this multi-step process can avoid some overhead in Enterprise Replication. For example, you avoid the need to advance the replay position for each alter operation. The replay position is the oldest transaction that has not been fully acknowledged by all target servers. If you are performing an in-place alter operation or altering a read-only server, replay position advancement is not performed.
The following example illustrates using alter mode to perform multiple alter operations:
cdr alter -c g_serv1 -on test:nagaraju.tab test:nagaraju.tab12 ### Set alter mode
Dbaccess test - <<EOF ### Alter tab and tab12
Alter table tab add col3 int;
Alter table tab12 add col3 int;
EOF
cdr alter -c g_serv1 -off test:nagaraju.tab test:nagaraju.tab12 ### Unset alter mode
|
Alter mode
Alter mode is a new state for a replicated table. To determine whether the table is in alter mode, use the oncheck -pt[T] command. Internally, before performing the alter operation on a replicated table, the server places the table in alter mode (if it's not already in that state). After completing the alter operation transaction, the server unsets the alter mode (if alter mode was set as part of the same transaction).
Only DDL and select operations are allowed on a table in alter mode. DML operations are not allowed on a table in alter mode. Attempting a DML operation on a table that is in alter mode results in SQL error code -19992.
The following example shows an excerpt of the oncheck -pt output for a replicated table named "tab" in alter mode:
TBLspace Report for test:nagaraju.tab
Physical Address 1:34801
Creation date 02/27/2005 03:03:44
TBLspace Flags c0080a Row Locking
TBLspace flagged for replication
TBLspace flagged for CDR alter mode
TBLspace use 4 bit bit-maps
Maximum row size 20
Number of special columns 0
Number of keys 0
... ...
... ...
|
The processing of an alter operation on a replicated table
When an alter operation is issued against a replicated table, the following actions occur:
- For the slow alter, alter fragment, or clustered index creation operations, the alter operation replay position is moved to the current log position before performing the operation.
Before performing the alter operation, the client session waits for Enterprise Replication to process all the log records up to the current log position, evaluate and queue all replicated transactions up to the current log position into the send queue, flush the in-memory send queue data to disk, and advance the replay position. This operation is repeated until the replay log position reaches the current log position. Depending upon the distance between the replay position and the current log position and the size of the unspooled data in send queue, this operation might delay the alter operation.
Important: You must configure enough disk space for the CDR queue smartblob space to hold all in-memory unspooled replicated transactions and the replicated transactions yet to be processed from the logical log files.
The replay position advancement is necessary because the slow alter, alter fragment, and clustered index creation operations change the table partition numbers. After those operations, Enterprise Replication does not recognize the logical log records related to the original partition numbers. After a slow alter operation, Enterprise Replication does not convert the table rows from the original to the new format.
If the alter operation is an in-place alter, or if the participant mode is set to read-only for the replicated table being altered, the replay position is not moved. An in-place alter does not change the table partition numbers. In addition, after an in-place alter operation, Enterprise Replication can still process the original log records and convert the rows in the original table format to the new table format. Datasync (the apply component) suspends the replicated transactions for the replicated table being altered and the related tables (for example, primary key-foreign key relationship tables), until the alter operation completes. After altering the replicated table, Enterprise Replication alters the delete table operation associated with the replicated table, and matches the delete table schema with the replication table schema. The delete table is a shadow table associated with the replicated table. It is used to resolve replication conflicts for timestamp and stored procedure conflict resolution.
When altering the delete table, Enterprise Replication performs these four steps:
- Renames the old delete table.
- Creates a new delete table based on the new schema of the altered replicated table.
- Copies rows from the original delete table to the new delete table.
- Drops the original delete table.
Enterprise Replication does not perform the following actions during an alter operation:
- Process DML log records generated due to an alter operation while moving the rows from the old partition to the new table partition.
- Replicate new rows attached to the replicated table after an
attach fragment operation.
- Remove rows from target replicate participants when an existing fragment was detached from a replicated table at the source server.
- Replicate DML operations performed on the detached fragment after a
detach fragment operation on a replicated table. The detached fragment is no longer part of the replicated table.
Alter operation considerations
Before attempting an alter operation against a replication table, consider the following:
- If you are using timestamp or stored procedure conflict resolution:
- Assign sufficient disk space to the CDR queue smartblob space. It needs enough space to hold all in-memory unspooled replicated transactions, and the replicated transactions yet to be processed from the logical log files. This configuration is not required when the type of alter operation is in-place alter, or when the server is a read-only participant for the replicated table being altered.
- Confirm that the dbspace containing the replicated table has enough disk space. It needs enough space to perform the alter operation on the associated delete table, along with the alter operation on the replicated table.
- Confirm that the server has a sufficient number of lock resources to alter the associated
delete table along with the replication table.
Remastering a replicate definition
During the remastering process:
- The master dictionary of a master replicate can be redefined.
- The SELECT statement of a replicate definition can be redefined.
- A non-master replicate definition can be converted into a master replicate definition.
As part of the remastering process, Enterprise Replication:
- Creates a shadow replicate using the attributes of the existing mastered replicate attributes, with the new master dictionary, and the new SELECT statement. Shadow replicates are replicates that are mirrors for primary replicates. They are used by Enterprise Replication during remastering and synchronization.
- Swaps the master replicate and the newly created shadow replicate, so that the shadow replicate becomes the new master replicate and old master replicate becomes the shadow replicate.
- Applies pending data for the shadow replicate (the former master replicate), then automatically removes the shadow replicate definition.
Remastering Methods
You can remaster automatically or manually.
To remaster automatically:
To remaster manually:
When to use manual remastering
Although automatic remastering requires the use of only one command, manual remastering (which has more requirements) is recommended for the following reasons.
Auto remastering (cdr remaster command) only works when the replicate SELECT statement column names and table names match across all the replicate participants:
- The
cdr remaster command accepts only one SELECT statement. This SELECT statement is applied to all the participants in the shadow replicate definition.
- The
cdr remaster command works on the mastered replicates that have column name verification turned on. This attribute is turned on by default when you create a mastered replicate definition.
The following example remasters a replicate with one command:
cdr remaster -c g_serv1 -M g_serv1 rep1 "select * from tab"
|
The following example output from cdr list repl shows the format of a shadow replicate name generated by automatic remastering:
CURRENTLY DEFINED REPLICATES
-------------------------------
REPLICATE: Shadow_4_rep1_GMT1109497231_GID100_PID28857
STATE: Active ON:serv1
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master,Shadow
PARENT REPLICATE: rep1
REPLICATE: rep1
STATE: Active ON:serv1
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master
|
When column names and table names in replicate SELECT statements do not match across all the replicate participants, you need to perform manual remastering. In this scenario, the master replicate definition needs to be created with the column name verification attribute turned off. By default, the mastered replicate verifies column names and their data types.
The following example shows the manual remastering process:
#Define primary replicate "Repl2"
cdr define repl -c g_cdr_ol_1 -C "ignore" -S tran -M g_cdr_ol_1 -A -R -F
name n Repl2 "P bank@g_cdr_ol_1:testadm.account" "select acctid, branch_name,
acct_addr from 'testadm'.account" "R bank@g_cdr_ol_2:testadm.account"
"select acctid, branch_name, address from 'testadm'.account"
"R bank@g_cdr_ol_3:testadm.account"
"select acctid, branch_name, address from 'testadm'.account"
# Define shadow replicate "Repl2Shadow" for primary replicate "Repl2"
cdr define repl -c g_cdr_ol_1 -C "ignore" -S tran -m Repl2 -M g_cdr_ol_1 -A -R -F
name n Repl2Shadow "P bank@g_cdr_ol_1:testadm.account" "select acctid,
branch_name, acct_addr, acct_balance from 'testadm'.account"
"R bank@g_cdr_ol_2:testadm.account" "select acctid, branch_name, address,
balance from 'testadm'.account" "R bank@g_cdr_ol_3:testadm.account"
"select acctid, branch_name, address, balance from 'testadm'.account"
#Swap primary replicate Repl2 and shadow replicate Repl2Shadow.
cdr swap shadow -c cdr_ol_1 -p Repl2 -P 655362 -s Repl2Shadow -S 655364
|
In the example above, 655362 is the replicate ID for Repl2 and 655364 is the replicate ID for Repl2Shadow. Replicate ID information can be obtained by issuing the onstat -g cat repls command or by querying the sysmaster view syscdrrepl.
Dropping a replicated column
To drop a replicated column:
- Remaster the replicate and remove the column being dropped from the replicate definition.
- Wait for the shadow replicate (created as part of the remastering operation) to be deleted automatically.
- Drop the column from the replication table.
Note: Enterprise Replication does not allow dropping a column from a replicated table when one or more replicate definitions refer to the column being dropped.
The following example illustrates this process.
Original table definition:
create table tab (col1 integer, col2 integer, col3 integer, primary key(col1))
with crcols lock mode row;
|
Replicate definition:
cdr define repl rep1 -M g_serv1 -C "timestamp" -S transaction -A -R
"test@g_serv1:nagaraju.tab" "select * from tab" "test@g_serv2:nagaraju.tab"
"select * from tab"
|
Remaster and remove col3 from the replicate definition rep1:
cdr remaster -c g_serv1 -M g_serv1 rep1 "select col1, col2 from tab"
|
The cdr list repl output after remastering:
CURRENTLY DEFINED REPLICATES
-------------------------------
REPLICATE: rep1
STATE: Active ON:serv1
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master
REPLICATE: Shadow_4_rep1_GMT1109569307_GID100_PID29368
STATE: Active ON:serv1
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master,Shadow
PARENT REPLICATE: rep1
|
Enterprise Replication deletes the shadow replicate after it applies all pending data for the shadow replicate. Drop the column (col3) from the replication table (tab) after the shadow replicate definition (Shadow_4_rep1_GMT1109569307_GID100_PID29368) is deleted.
Adding a column to a replicate definition
To add a column to a replicate definition:
- Add the column to the replicated table on all the replicate participants.
- Remaster the replicate definition and modify the replicate SELECT statement to replicate data for the newly-added column.
The following example illustrates adding a column to a replicate definition.
Original table definition:
create table tab (col1 integer, col2 integer, primary key(col1))
with crcols lock mode row;
|
Replicate definition:
cdr define repl rep1 -M g_serv1 -C "timestamp" -S transaction -A -R
"test@g_serv1:nagaraju.tab" "select * from tab" "test@g_serv2:nagaraju.tab"
"select * from tab"
|
Now add the column (col3) to the replicated table (tab) at both replicate participants (g_serv1 and g_serv2):
dbaccess test@g_serv1 - <<EOF
alter table tab add col3 integer;
EOF
dbaccess test@g_serv2 - <<EOF
alter table tab add col3 integer;
EOF
|
Remaster rep1 to add col3 to the replicate definition:
cdr remaster -c g_serv1 -M g_serv1 rep1 "select col1, col2, col3 from tab"
|
The cdr list repl output after remastering:
CURRENTLY DEFINED REPLICATES
-------------------------------
REPLICATE: Shadow_4_rep1_GMT1109570388_GID100_PID29417
STATE: Active ON:serv1
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master,Shadow
PARENT REPLICATE: rep1
REPLICATE: rep1
STATE: Active ON:serv1
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master
|
Enterprise Replication deletes the shadow replicate definition (Shadow_4_rep1_GMT1109570388_GID100_PID29417) automatically when this replicate definition is no longer necessary.
Modifying a replicated column
When you modify a replicated column, user care not to insert data into the modified column that will not fit into the old column definition, because the data might be truncated or data conversion to and from mastered dictionary format to the local dictionary format might fail.
If Enterprise Replication cannot convert replication data into the master dictionary format at the source server while queuing replication data into the send queue, the replicate definition is stopped for the local participant. If this occurs, you must correct the problem and then restart the replicate definition for the local replicate participant with the --sync (-S) option. If the correction is to delete the problematic row data, delete the row using the BEGIN WORK WITHOUT REPLICATION statement. Otherwise, the deleted row is moved from replication table to the associated delete table, which might cause problems for the subsequent alter operation on the replicated table.
If Enterprise Replication cannot convert row data from the master dictionary format to local table dictionary format at the target server after receiving replication data, the replicated transaction is spooled to ATS and RIS files. For example, if you modify a smallint column to an integer column, make sure that you do not insert data that is too large for the smallint data type until the alter operation is performed at all replicate participants, and remastering is performed so that the master dictionary reflects the integer data type.
To modify a replicated column:
- Issue the alter command to modify the replicated column.
- Perform the alter operation at all the replicate participants.
- Remaster the replicate definition to modify the master dictionary to change the modified column.
After remastering, the source server converts the row data into the master dictionary format while queuing the data into the send queue. The target server converts the row data from the master dictionary format to the local table dictionary format before applying the data.
The following example illustrates modifying a replicated column.
Original table definition:
create table tab (col1 integer, col2 smallint, primary key(col1))
with crcols lock mode row;
|
Replicate definition:
cdr define repl rep1 -M g_serv1 -C "timestamp" -S transaction -A -R
"test@g_serv1:nagaraju.tab" "select * from tab" "test@g_serv2:nagaraju.tab"
"select * from tab"
|
Modify the data type of the column (col2) from smallint to integer on the server g_serv1:
dbaccess test@g_serv1 - <<EOF
alter table tab modify col2 integer;
EOF
|
To ensure that you do not insert data for col2 that cannot fit into the smallint data type, alter the table (tab), and modify the data type of col2 from smallint to integer on the server g_serv2:
dbaccess test@g_serv2 - <<EOF
alter table tab modify col2 integer;
EOF
|
To avoid data conversion from the local table dictionary format to the master dictionary format, and from the master dictionary format to the local dictionary format, remaster the replicate definition of rep1 to modify the master dictionary, changing the data type of col2 from smallint to integer.
Remaster rep1 to modify the master dictionary:
cdr remaster -c g_serv1 -M g_serv1 rep1 "select * from tab"
|
Attaching a fragment to a replication table
To attach a fragment to a replication table:
- Using the CDR command line interface, set the replication table to alter mode.
- Drop the primary key.
- Attach a fragment.
- Recreate the primary key.
- Using the CDR command line interface, unset the replication table from alter mode.
The following example illustrates attaching a fragment to a replicated table:
#Set alter mode on replication table "tab"
cdr alter -c g_serv1 -on test:nagaraju.tab
#Then attach a new fragment to "tab"
Dbaccess test - <<EOF
Alter table tab drop constraint pk1;
alter fragment on table tab attach tab_1;
alter table tab add CONSTRAINT primary key (col1) CONSTRAINT pk1;
EOF
#Then unset alter mode on "tab"
cdr alter -c g_serv1 -off test:nagaraju.tab
|
Note: All other types of alter operations can be executed directly against a replication table using a SQL ALTER statement.
Troubleshooting tips
Problem 1: You receive an error about the replicated table name.
cdr alter -o test:tab
Error:Replicate(s) not defined on table test:.tab
|
Problem: The owner name is missing from the table name, test:tab.
Solution: Include the table owner name, for example: cdr alter -o test:nagaraju.tab.
Problem 2: You receive an error that the replicated table is in alter mode.
> insert into tab values(1,1);
19992: Cannot perform insert/delete/update operations on a replicated table
while the table is in alter mode
Error in line 1 Near character position 27
>
|
Problem: The table (tab) is in alter mode. DML operations cannot be performed while the table is in alter mode.
Solution: Wait for the table to be altered and then issue the DML operation. If no alter statement is in progress against the table, then unset alter mode on the table using the cdr alter --off command. For example: cdr alter --off test:nagaraju.tab
You can check the alter mode status using the oncheck -pt test:nagaraju.tab command.
Problem 3: How can you tell if a replicate is a mastered replicate?
When you execute the cdr list repl command, it shows that the REPLTYPE is Master for master replicates:
$cdr list repl
CURRENTLY DEFINED REPLICATES
-------------------------------
REPLICATE: rep2
STATE: Active ON:delhi
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab12
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master
REPLICATE: rep1
STATE: Active ON:delhi
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
|
In the above output, rep1 is defined as a non-master replicate and rep2 is defined as master replicate.
Problem 4: An alter operation on a replicated table fails.
$dbaccess test -
Database selected.
> alter table tab add col4 int;
19995: Enterprise Replication error encountered while setting alter mode. See
message log file to get the Enterprise Replication error code
Error in line 1Near character position 27
>
|
The message log output is:
12:36:09 CDRGC: Classic replicate rep1 found on the table test:nagaraju.tab
12:36:09 CDRGC:Set alter mode for replicate rep1
12:36:09 GC operation alter mode set operation on a replicated table failed:
Classic replicate(s) (no mastered dictionary) found on the table.
|
The above message shows that there is a classic replicate, rep1, defined on the table (tab). Adding a new column to a replicated table is allowed when only master replicates are defined for the table.
To perform the above alter operation, first convert the classic replicate to a master replicate.
You can convert the replicate definition of rep1 to a master replicate by issuing the following command:
cdr remaster -M g_delhi rep1 "select * from tab"
|
Now look at the cdr list repl output:
$cdr list repl
CURRENTLY DEFINED REPLICATES
-------------------------------
REPLICATE: rep1
STATE: Active ON:delhi
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master
REPLICATE: rep2
STATE: Active ON:delhi
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab12
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Master
REPLICATE: Shadow_4_rep1_GMT1112381058_GID100_PID29935
STATE: Active ON:delhi
CONFLICT: Timestamp
FREQUENCY: immediate
QUEUE SIZE: 0
PARTICIPANT: test:nagaraju.tab
OPTIONS: transaction,ris,ats,fullrow
REPLTYPE: Shadow
PARENT REPLICATE: rep1
|
You can see that repl1 has been converted to a master replicate.
You can also see that a new replicate definition, Shadow_4_rep1_GMT1112381058_GID100_PID29935, also got created against the table (tab1). Notice the last two fields of the output for Shadow_4_rep1_GMT1112381058_GID100_PID29935:
REPLTYPE: Shadow
PARENT REPLICATE: rep1
|
The Shadow attribute indicates that this replicate is a shadow replicate, and PARENT REPLICATE: rep1 shows that this is a shadow replicate for the primary replicate rep1. Notice that the Master attribute is not present for this replicate definition. This shadow replicate is actually the old non-master replicate. The cdr remaster command created a new master replicate, rep1, for the table tab and converted the old non-master replicate (rep1) to a shadow replicate for the new master replicate.
This table is not yet ready to be altered. This is because there is still a non-master replicate, Shadow_4_rep1_GMT1112381058_GID100_PID29935, defined for the table, tab. You must wait for Shadow_4_rep1_GMT1112381058_GID100_PID29935 to be deleted automatically by Enterprise Replication after all the data queued for this shadow replicate is applied at all the replicate participants. This process can take some time. Alternatively, if you are sure that there is no data pending for this old non-master replicate, then you can issue cdr delete repl command against Shadow_4_rep1_GMT1112381058_GID100_PID29935.
After making sure that Shadow_4_rep1_GMT1112381058_GID100_PID29935 no longer exists, you can attempt the alter table tab add col4 int; statement against the table.
Resources
About the author  | | | Nagaraju Inturi has been working on Informix Dynamic Server Enterprise Replication for the past 6 years. He is an IBM Certified Solutions Expert (Informix Dynamic Server V9, System Administrator). |
Rate this page
| 
