同步复制oneway的数据库表研究 通过使用同步复制oneway的数据库表的研究，来更加深入的了解同步复制的原理，数据同步的步骤。
本文以oneway的父到子为例(从子到父只是角色变了，表的变化可以类比一下）。
系统环境 父库：oracle 11.2.0.1 64bit、 arcsde10 sp2 64bit
子库：sql server 2008 64bit、arcsde10 sp2 64bit
两个库里面没有任何版本，state=0
执行操作 1：父库：注册版本、添加globeid。
2：执行复本操作，父库将相关的所有数据都导入到子库中。
父库：versions表中添加一条同步复制版本的记录。使用同步复制产生的版本名称都是以”sync_send_replicaobjectid_”为前缀的，状态为16777216（这个数字还没有具体研究过，好像oneway和twoway是不一样的），一开始没有编辑之前，这两条记录的state_id=0。
gdb_items表中添加一项replica名称，默认为myrelplica，是以xml存储，我们来看一下这个内容：子库的相关的连接参数信息，父库的相关角色等都描述的非常清楚。
子库：导入父库的所有数据（如果不加任何条件的话），导入之后直接就是注册版本状态。我查看了子库一开始的整体数据同步（非编辑父库同步），是不走状态表和增量表的，直接将父库的基表数据导入到子库的基表中。
versions表中无任何新添加的信息。
gdb_items表中添加一项replica名称，默认为myrelplica，是以xml存储，我们来看一下这个内容：父库的相关的连接参数信息，子库的相关角色等都描述的非常清楚。
3：对父库进行编辑
我对父库进行增、删、改三种方式的编辑行为，每做一次保存一下编辑，目的是记录一下相关的编辑状态。
父库的versions表、states表等相关的版本表、增量表肯定发生了变化。如下versions：
4：将父库变化的数据进行同步
父库的versions表中发生了一些变化，首先我们查看一下同步复制的版本名称由原来的sync_send_4177_0变为sync_send_4177_1，这说明这个数字可以记录同步的次数。
gdb_items表中的replica信息也发生了相关的变化
101
gdb_replicalog表里面记录了同步的相关日志信息
子库里面我们可以看到，父库是通过版本表、增量表等信息将变化的数据同步过去的，那么我们在子库里面的相关表也同步过来了。
从上面的a表和states表可以看出，尽管我在父库里面是记录了三个不同状态的操作，但是在同步过程中，子库只记录一个相关的状态，这个状态可以记录同时编辑了n个数据，这样的话势必会提高子库的数据查询分析效率。
gdb_items表中的replica信息也发生了相关的变化
010esrireplicastatesendingacknowledgment
同样也会更新子库中versions表的state_id，将最新的id同步更新。这样一次同步复制就完成了，那么我还是有一个疑问，系统是怎么将父库中关于某个同步要素类的变化的数据区分过去同步的，也就是他是将所有变化的数据给同步过去还是只同步最新变化的数据呢？带着这个问题我再一次做一个同步操作。
5：对父库做第二次编辑
我们可以看到父库里面versions表中
然后我们再看看族系表
其实从上面两个表我已经可以猜到系统肯定是只同步变化的数据，因为根据这两个表就能推出哪些是最新编辑的数据，因为系统记录了第一次同步之后第二次编辑之前的最新的状态值state_id=55，根据这个值可以找到相关的族系名称lineage_name=53，那么顺着这个族系名称找到最大的状态值就是最新编辑的记录的状态，从图上我们可以看到56、57、58都是最新编辑的，那么我们就可以从states表和增量表中将相关的信息记录出来。
5：第二次同步
父库gdb_replicalog表里面记录了同步的相关日志信息
versions表中，果然同步版本名称又增加了1，同时更新了最新的状态值
gdb_items表中的replica信息也发生了相关的变化
202
子库里面的a表和状态表
从上面的图更加坚定我刚才的猜测，系统只同步变化的数据，原来的状态值等于52的仍然没有变化，第二次同步过来的就是53（根据状态序列）。
gdb_items表中的replica信息也发生了相关的变化
010esrireplicastatesendingacknowledgment
结论：通过上面对同步复制oneway操作后数据库表信息的变化，基本上可以将这个编辑同步过程的步骤，或者系统设计的思路弄清楚，系统是根据子库父库存储的replica的xml获取相关的角色、连接、数据描述等相关信息，然后编辑数据根据版本表、增量表将变化的数据读取然后进行相关的操作。