Goldengate进行异构数据库同步时，初始化通常是一个比较困难的问题，OGG自带的Initial Load功能不能进行在线初始化，也就是不能保证数据是读一致性的。也不能与后续的增量数据进行无缝衔接。
从SQLServer向Oracle进行数据初始化时我们可以借助中间库来实现。先用SQLServer的备份恢复功能，恢复一个中间库，再用OGG Intial Load功能从中间库中进行数据初始化。
中间库是静态数据，这个数据的状态是某个LSN时间点的状态。
OGG的CSN其实与SQLServer的LSN是同一个值。然后我们可以在Oracle目标端使用aftercsn功能从中间库LSN时间点开始应用数据。实现无缝初始化。
其他异构数据库的在线初始化也可以参考本文中的方法。
OGG CSN
对于 SQLServer的trail来说它的取值为：
从解释中来看当源端为SQL Server时 Goldengate的CSN取值是从数据库中取的。并且该值会为三段，第一个值代表虚拟日志文件号，第二段为虚拟日志中的段号，第三段为日志记录号：
虚拟日志文件号：日志文件中的段号：日志记录号
例如：
0X00000d7e:0000036b:01bd
0000003454:0000000875:00445
0Xd7e:36b:1bd
3454:875:445
3454000000087500445
不同的SQL Server版本可能返回给OGG的CSN值不同，大体会为上面几种。
SQL Server LSN号
SQL Server LSN(Log Sequence Number)，这个LSN也是会为三段。
the first part is the VLF sequence number.
the middle part is the offset to the log block
the last part is the slot number inside the log block
LSN与CSN的关系
OGG官方文档中并没有说明SQLServer LSN与CSN有什么关系。但从这他们两个的结构来看像是同一个值。
分析OGG trail文件中的trail并用APEX SQL分析SQL Server 的日志，分析同一条数据变化进行对比：
OGG trail中LOGCSN:
SQLServer中LSN:
提取CSN和LSN:
CSN: 00000025:0000013d:0003
LSN: 00000025:0000013D:0002
LSN中的字母是大写的，而CSN中的值为小写。（该值为16进制值，可以忽略大小写）
最后一段CSN要比LSN大1个值。(实际测试中可以实验一下看看取哪个值作为aftercsn值比较合适)
在MOS文章中也说到了LSN和CSN是一样的值。
Oracle GoldenGate Best Practices: Instantiation from a SQL Server Source Database (Doc ID 1310946.1)
SQLServer在线初始化
使用OGG把SQLServer的数据同步到Oracle时面临的一个问题就是数据如何在线初始化。如果可以停业务那么可以使用initial Load的方式，采用离线初始化的方式。如果业务不能停，那么在线初始化就是个问题。
我们可以结合SQLServer 备份创建一个中间库，然后使用这个静止的中间库中进行数据库初始化。这样初始化到目标端的数据是状态一致的。然后在目标端启动应用进程时通过aftercsn的方式启动。 其中csn的值就是中间库恢复时的lsn。
参考：
https://docs.oracle.com/goldengate/1212/gg-winux/GWUAD/wu_csn.htm#GWUAD752
http://rusanu.com/2012/01/17/what-is-an-lsn-log-sequence-number/
Oracle GoldenGate Best Practices: Instantiation from a SQL Server Source Database (Doc ID 1310946.1)