对复制表上 alter 操作的支持
Nagaraju Inturi
IBM Informix 软件工程师, IBM
2005 年 7 月 7 日
本文描述 Enterprise Replication 环境中的模式演变（对复制表上的 alter table 操作的支持）。Enterprise Replication 中的模式演变支持是 IBM® Informix® Dynamic Server Version 10.00 的一个新特性。这个特性使您可以在 Enterprise Replication 全天候运行时执行某些任务，而不会导致任何客户机应用程序停工。
简介
与之前的版本相比，IBM Informix Dynamic Server Version 10.00 支持更多对复制表的 alter 操作。大多数 alter 操作都可以在 Enterprise Replication 运行的同时执行。所有受支持的新 alter 操作都要求复制是主复制。在执行某些 alter 操作后，可能需要 remaster 该复制。
注意，本文不提供 DDL 复制信息。
受支持的 alter 操作
当 Enterprise Replication 在运行，并且正在进行数据复制时，对复制表的以下 alter 操作是受支持的：
- 添加或删除分段。
- 附加或分离分段。
- 将非分段的表从一个 dbspace 移动到另一个 dbspace。
- 将分段的表转换成非分段的表。
- 将非分段的表转换成分段的表。
- 从一种分段策略转换成另一种分段策略。
- 更改现有 dbspace 上已有的分段表达式
- 将分段表达式从一个 dbspace 转移到另一个 dbspace
- 添加、删除或修改列
- 创建集群索引
- 重新集群已有的索引。
以下是除了 Version 10.00 之前版本所支持的 alter 操作之外的新支持的 alter 操作：
- 添加或删除默认值，以及 SQL 检查。
- 添加或删除惟一、独特或外键约束。
- 修改锁粒度。
- 修改下一个盘区大小。
主复制是必需的
当只为表定义主复制时，可以修改复制表。如果为表定义了从复制，那么对复制表的修改是不允许的。
主复制从主服务器（在 cdr define repl 命令中以 -M 选项指定）提取复制表的字典信息，并将之存储在 syscdr 数据库中。这种字典信息被称作主字典（master dictionary）。当添加一个新的参与者到主复制定义中时，主字典要与参与表的字典进行比较。如果主字典信息与参与表的字典信息相匹配，则会添加这个新的参与者。主复制的复制数据总是以主字典的格式进行传输。在将复制数据放入到发送队列之前，源服务器首先将数据从本地表字典格式转换为主复制字典格式。类似地，在应用复制数据之前，目标服务器首先将主字典格式的复制数据转换为本地表字典格式。
下面的 Enterprise Replication 命令创建一个名为 rep1 的主复制。主字典从主服务器 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"
|
修改复制表
有两种方法可以用来修改复制表：
- 直接对复制表发出 alter 语句。例如：
dbaccess test - <<EOF
Alter table tab add col3 int;
EOF
|
- 使用 CDR 命令行界面：
- 使一个或多个复制表处于 alter 模式。
- 修改复制表。
- 关闭复制表上的 alter 模式。
何时使用 CDR 命令行
为了将一个分段加到一个复制表上，必须使用 CDR 命令行界面，并使表处于 alter 模式。
通常，为了附加一个新的分段，可以执行以下三个步骤：
- 删除主键。
- 发出 ATTACH FRAGMENT alter 语句。
- 重建主键。
在一个复制表上，使用 alter 模式为 alter 操作准备 Enterprise Replication：
- 使用
cdr alter --on 命令使复制表处于 alter 模式。
- 通过前面给出的三个步骤，将新的分段附加到复制表上。
- 使用
cdr alter --off 命令关闭复制表的 alter 模式。
下面的例子说明了如何将一个分段附加到一个复制表上：
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
|
如果需要在一个或多个表上执行多个 alter 操作，那么使用上述多步过程可以避免 Enterprise Replication 中的一些开销。例如，可以避免为每个 alter 操作推进重放位置。重放位置是必须被所有目标服务器完全公认的最老的事务。如果正在执行一个 in-place alter 操作，或者正在修改一个只读的服务器，则不会推进重放位置。
下面的例子说明了如何使用 alter 模式来执行多个 alter 操作:
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 模式
alter 模式 是复制表的一种新的状态。为了判断表是否处于 alter 模式，可以使用 oncheck -pt[T] 命令。在内部，在对一个复制表执行 alter 操作之前，服务器使表处于 alter 模式（如果表还没有处于这个状态）。在完成 alter 操作事务之后，服务器关闭 alter 模式（如果在同一个事务中打开了 alter 模式）。
在 alter 模式下，只有 DDL 和 select 操作受允许。对于 alter 模式下的表，DML 操作是不允许的。如果尝试对 alter 模式下的表执行 DML 操作，则会产生 SQL 错误码 -19992。
下面的例子展示了对 alter 模式下的一个名为 "tab" 的复制表执行 oncheck -pt 时的部分输出：
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
... ...
... ...
|
复制表上的 alter 操作的处理
当对一个复制表发出一个 alter 操作时，将发生以下动作：
- 对于 slow alter、alter fragment 或集群索引创建操作，在执行 alter 操作之前， alter 操作的重放位置被移动到当前的日志位置。
在执行 alter 操作之前，客户机会话等待 Enterprise Replication 处理所有日志记录，一直到当前日志记录位置，计算直到当前日志位置的所有复制事务，并将它们放入发送队列，将内存中发送队列的数据转移到磁盘，然后推进重放位置。这个操作会一直重复，直到重放日志位置到达当前日志位置。取决于重放位置与当前日志位置之间的距离，以及发送队列中未假脱机的数据的大小，这个操作可能会延缓 alter 操作。
重要： 您必须为 CDR 队列 smartblob 空间配置足够的磁盘空间，以便容纳内存中所有未假脱机的复制事务，以及逻辑日志文件中仍待处理的复制事务。
重放位置的推进是必需的，因为 slow alter、alter fragment 和集群索引创建操作会改变表分区号。这些操作过后，Enterprise Replication 不认识与初始分区号相关的逻辑日志记录。在执行一个 slow alter 操作之后，Enterprise Replication 不会将表行从初始格式转换为新的格式。
-
如果 alter 操作是一个 in-place alter，或者被修改复制表的参与者模式被设为只读，那么重放位置不会移动。in-place alter 不会改变表分区号。此外，在执行一个 in-place alter 操作后，Enterprise Replication 仍然可以处理初始的日志记录，并将初始表格式下的行转换为新的表格式。
-
Datasync （apply 组件）挂起被修改复制表以及相关表（例如有主键-外键关系的表）上的复制事务，直到 alter 操作完成。
-
修改了复制表之后，Enterprise Replication 修改与复制表相关的 delete table 操作，并将删除表模式与复制表模式匹配。删除表是与复制表相关的一个影子表。它用于解决针对时间戳和存储过程冲突解决的复制冲突。
当修改删除表时，Enterprise Replication 执行以下四步：
- 重命名旧的删除表。
- 基于被修改复制表的新模式创建一个新的删除表。
- 将初始删除表中的行复制到新的删除表。
- 删除初始删除表。
在 alter 操作中，Enterprise Replication 不会执行以下动作：
- 处理在将旧分区中的行转移到新表分区时因 alter 操作而生成的 DML 日志记录。
- 在
attach fragment 操作后复制附加到复制表上的新行。
- 当一个已有的分段从源服务器上的一个复制表上分离出去时，删除复制参与者中的行。
- 在对一个复制表执行
detach fragment 操作后，复制在被分离分段上执行的 DML 操作。被分离的分段不再是复制表的一部分。
对 alter 操作的考虑
在尝试对一个复制表执行 alter 操作时，考虑以下方面：
- 如果您使用时间戳或存储过程冲突解决：
- 为 CDR 队列 smartblob 空间分配足够的磁盘空间。它需要足够的空间来容纳内存中所有未假脱机的复制事务，以及逻辑日志文件中仍待处理的复制事务。如果 alter 操作是 in-place alter，或者服务器对于被修改复制表是一个只读参与者，那么这样的配置不是必需的。
- 确信包含复制表的 dbspace 有足够的磁盘空间。它需要足够的空间来执行对相关的删除表的 alter 操作，以及对复制表的 alter 操作。
- 确信服务器有足够的锁资源数，用以修改相关的删除表和复制表。
remastering 复制定义
在 remastering 过程中：
- 主复制的主目录可以重新定义。
- 复制定义的 SELECT 语句可以重新定义。
- 从复制定义可以转换成主复制定义。
在 remastering 过程中，Enterprise Replication:
- 使用已有的主复制属性，加上新的主目录和新的 SELECT 语句，创建一个影子复制。影子复制是作为主复制镜像的复制。在 remastering 和同步期间，Enterprise Replication 要使用影子复制。
- 交换主复制和新创建的影子复制，使影子复制变为主复制，旧的主复制变为影子复制。
- 为影子复制（旧的主复制）应用未决数据，然后自动删除影子复制定义。
remastering 方法
您可以自动或手动执行 remastering。
如果自动 remaster：
如果手动 remaster：
何时使用手动 remastering
虽然自动 remastering 只要求使用一个命令，但由于以下原因，仍建议使用手动 remastering（有更多需求）。
自动 remastering （cdr remaster 命令）只有在复制 SELECT 语句中的列名和表名所有复制参与者匹配时才适用：
cdr remaster 命令只接受一个 SELECT 语句。这个 SELECT 语句被应用于影子复制定义中的所有参与者。 cdr remaster 命令用于启用了列名检验的主复制。当您创建一个主复制定义时，默认情况下这个属性是开启的。
下面的例子用一个命令 remaster 一个复制：
cdr remaster -c g_serv1 -M g_serv1 rep1 "select * from tab"
|
下面来自 cdr list repl 的例子输出显示了由自动 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
|
如果复制 SELECT 语句中的列名和表名不是与所有复制参与者都匹配，那么就需要执行手动 remastering。在这个场景中，需要在关闭列名检验属性的情况下创建主复制定义。默认情况下，主复制检验列名和它们的数据类型。
下面的例子展示了手动 remastering 过程：
#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
|
在上面的例子中，655362 是 Repl2 的复制 ID，是 Repl2Shadow 的复制 ID。复制 ID 信息可以通过发出 onstat -g cat repls 命令或者查询 sysmaster 视图 syscdrrepl 获得。
删除一个复制列
为删除一个复制列：
- remaster 复制，并从复制定义中删除被删除的列。
- 等待影子复制（在 remastering 操作中创建）被自动删除。
- 从复制表删除列。
注意：当一个或多个复制定义引用被删除的列时，Enterprise Replication 不允许从一个复制表中删除一列。
下面的例子说明了这个过程。
初始表定义：
create table tab (col1 integer, col2 integer, col3 integer, primary key(col1))
with crcols lock mode row;
|
复制定义：
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 并删除来自复制定义 rep1 的 col3：
cdr remaster -c g_serv1 -M g_serv1 rep1 "select col1, col2 from tab"
|
remastering 之后的 cdr list repl 输出是：
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 在为影子复制应用所有未决数据之后删除影子复制。在影子复制定义（Shadow_4_rep1_GMT1109569307_GID100_PID29368）被删除之后，从复制表（tab）删除列（col3）。
添加一个列到复制定义
为添加一个列到复制定义：
- 添加该列到所有复制参与者上的复制表中。
- remaster 复制定义，修改复制 SELECT 语句，以便为新添加的列复制数据。
下面的例子说明了如何添加一个列到复制定义。
初始表定义：
create table tab (col1 integer, col2 integer, primary key(col1))
with crcols lock mode row;
|
复制定义:
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"
|
现在将列（col3）添加到两个复制参与者（g_serv1 和 g_serv2）上的复制表（tab）：
dbaccess test@g_serv1 - <<EOF
alter table tab add col3 integer;
EOF
dbaccess test@g_serv2 - <<EOF
alter table tab add col3 integer;
EOF
|
对 rep1 进行 remaster，以添加 col3 到复制定义:
cdr remaster -c g_serv1 -M g_serv1 rep1 "select col1, col2, col3 from tab"
|
remastering 之后的 cdr list repl 输出：
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 自动删除这个复制定义（Shadow_4_rep1_GMT1109570388_GID100_PID29417）。
修改复制列
当修改一个复制列时，用户小心不要将数据插入不符合旧的列定义的被修改列中，因为数据可能被截取，或者从主字典格式到本地字典格式之间的来回数据转换可能失败。
如果在将复制数据放入发送队列时，Enterprise Replication 不能在源服务器上将复制数据转换成主字典格式，那么复制定义将不能用于本地参与者。如果发生这种情况，必须更正这个问题，然后用 --sync (-S) 选项为本地参与者重新启动复制定义。如果更正措施是删除有问题的行数据，那么使用 BEGIN WORK WITHOUT REPLICATION 语句删除行。否则，被删除的行将被从复制表转移到相关的删除表，这样会给随后对复制表的 alter 操作带来问题。
如果在收到复制数据之后，Enterprise Replication 不能在目标服务器上将主字典格式下的行数据转换为本地字典格式，那么复制事务将被脱机到 ATS 和 RIS 文件。例如，如果将一个 smallint 列修改成 integer 列，那么应确保不插入对于 smallint 数据类型来说过大的数据，直到在所有复制参与者上执行 alter 操作，并执行 remastering，使得主字典反映 integer 数据类型。
为修改一个复制列：
- 发出 alter 命令修改复制列。
- 在所有复制参与者上执行 alter 操作。
- remaster 复制定义，以便修改主字典，进而更改被修改的列。
执行 remastering 之后，当把数据放入发送队列时，源服务器将行数据转换成主字典格式。目标服务器在应用数据之前，将行数据从主字典格式转换为本地表字典格式。
下面的例子说明了如何修改一个复制列。
初始表定义：
create table tab (col1 integer, col2 smallint, primary key(col1))
with crcols lock mode row;
|
复制定义:
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"
|
在服务器 g_serv1 上将该列（co12）的数据类型从 smallint 改为 integer：
dbaccess test@g_serv1 - <<EOF
alter table tab modify col2 integer;
EOF
|
为了确保不将不符合 smallint 数据类型的数据插入 co12，请修改表（tab），并在服务器 g_serv2 上将 co12 的数据类型从 smallint 改为 integer：
dbaccess test@g_serv2 - <<EOF
alter table tab modify col2 integer;
EOF
|
为了避免从本地表字典到主字典格式的数据转换，以及从主字典到本地字典格式的数据转换，请对 rep1 的复制定义进行 remaster，以修改主字典，同时将 co12 的数据类型从 smallint 改为 integer。
对 rep1 进行 remaster 以修改主字典：
cdr remaster -c g_serv1 -M g_serv1 rep1 "select * from tab"
|
将一个分段附加到一个复制表上
为了将一个分段附加到一个复制表上：
- 使用 CDR 命令行界面，将复制表设为 alter 模式。
- 删除主键。
- 附加一个分段。
- 重新创建主键。
- 使用 CDR 命令行界面，关闭复制表的 alter 模式。
下面的例子说明了如何将一个分段附加到一个复制表上：
#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
|
注意：通过使用 SQL alter 语句，可以直接对复制表执行所有其他类型的 alter 操作。
故障分析与解决技巧
问题 1: 收到关于复制表名的一个错误。
cdr alter -o test:tab
Error:Replicate(s) not defined on table test:.tab
|
问题： 表名 test:tab 中缺少所有者名。
解决办法： 包括表所有者名，例如： cdr alter -o test:nagaraju.tab。
问题 2: 收到错误说复制表处于 alter 模式。
> 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
>
|
问题： 表（tab）处于 alter 模式。当表处于 alger 模式时，不能执行 DML 操作。
解决办法：等这个表被修改，然后发出 DML 操作。如果当前没有对这个表的 alter 语句，那么使用 cdr alter --off 命令关闭表上的 alter 模式。例如：cdr alter --off test:nagaraju.tab
可以使用 oncheck -pt test:nagaraju.tab 命令检查 alter 模式状态。
问题 3: 如何分辨一个复制是不是主复制？
当执行 cdr list repl 命令时，它显示 REPLTYPE 是主复制的 Master：
$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
|
在上面的输出中，rep1 被定义为从复制，rep2 被定义为主复制。
问题 4: 复制表上的 alter 操作失败。
$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
>
|
消息日志输出为：
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.
|
上面的消息表明，在表（tab）上定义了一个普通复制 rep1。如果这个表上只定义了主复制，那么添加一个列到复制表中是允许的。
为执行上述 alter 操作，首先将普通复制转换成主复制。
可以通过发出以下命令将 rep1 的复制定义转换为主复制：
cdr remaster -M g_delhi rep1 "select * from tab"
|
现在来看 cdr list repl 输出：
$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
|
可以看到，repl1 已经被转换成主复制。
还可以看到，在表（tab1）上还创建了一个新的复制定义，Shadow_4_rep1_GMT1112381058_GID100_PID29935。注意 Shadow_4_rep1_GMT1112381058_GID100_PID29935 输出的最后两个字段：
REPLTYPE: Shadow
PARENT REPLICATE: rep1
|
Shadow 属性表明该复制是一个影子复制，PARENT REPLICATE: rep1 表明这是主复制 rep1 的一个影子复制。注意对于这个复制定义没有给出 Master 属性。这个影子复制实际上是旧的从复制。cdr remaster 命令为表 rep1 创建一个新的主复制，并将旧的从复制（rep1）转换成新的主复制的一个影子复制。
这个表还不能被修改。这是因为表 tab 上仍然存在从复制 Shadow_4_rep1_GMT1112381058_GID100_PID29935 的定义。您必须等到在所有复制参与者上应用了用于这个影子复制的所有队列中的数据之后，由 Enterprise Replication 自动删除 Shadow_4_rep1_GMT1112381058_GID100_PID29935。这个过程可能要花费一些时间。或者，如果您确信对于旧的从复制没有未决数据，那么可以对 Shadow_4_rep1_GMT1112381058_GID100_PID29935 发出 cdr delete repl 命令。
在确保 Shadow_4_rep1_GMT1112381058_GID100_PID29935 不再存在之后，可以尝试对这个表执行 alter table tab add col4 int; 语句。 |
