达梦数据实时同步工具DMHS常见故障处理
1.启动失败
DMHS在同步故障或是重启时，如果启动失败，则有可能是下面几个原因：
1)EXEC或CPT模块加载失败EXEC和CPT模块由于需要和数据库进行交互，那么它在启动时需要依赖数据库的ODBC和OCI驱动，如果它加载失败则说明它依赖的驱动程序未能加载成功。
- ORACLE数据库时，要保证使用oracle用户来启动DMHS，不能使用root等用户，如果需要使用其它用户，则要设置好ORACLE的环境变量，以便执行模块能够访问ORACLE的驱动。
- DM数据库时，要保证DM的ODBC和OCI驱动依赖的动态库都能访问到。
2)无法获取LSN
在源端执行START CPT命令的常见错误就是无法获取LSN，有下面几种可能：
- CPT中send的配置中目标端DMHS的IP或端口号有误。
- 目标端DMHS的EXEC模块没有被加载，没有执行START EXEC。
- 存在网闸，但是CPT中send没有配置net_turns为1。
- 源端和目标端网络不通。
- 目标端DMHS使用了HA搭建了主备，由于主备之间的配置不一样，例如：user_name或db_name，导致DMHS_TRXID_TABLE表在目标库中存在多份，切机以后使用了不同的DMHS_TRXID_TABLE表来作恢复。
3)LSN定位失败
一般出现这种问题，都是由于源端数据库的归档文件被第三方删除导致，需要定位删除的原因，是否是因为同步性能跟不上或是源端有长事务等原因导致源端的最小事务的LSN无法推进，归档达到了最长的保留时间而被第三方清除。针对这种问题，常用的办法就是把执行端DMHS_TRXID_TABLE中TID为0的记录中SEQID的值（多对一的环境注意匹配记录的SITEID值）修改为源端对应归档文件的最小LSN，重启目标端和源端的DMHS，同步会从源端第一个归档开始重新同步。
注意：
通过修改源端dmhs.conf文件中的起始LSN值也可以达到调整日志分析位置的目的，但是操作会比较复杂。
4)CPT启动无响应
出现这种问题的可能性有很多，下面几种最常见：
- 目标端中存在大量待执行的事务，需要等它们执行完。
- 目标端的DMHS_TRXID_TABLE中存在大量的记录。
- 源端数据库存在大量的归档文件，CPT启动会收集这些归档。
- 源端DICT目录下存在大量的离线字典文件，CPT启动会预加载字典文件。
- 源端的归档或在线单个日志文件过大，CPT定位时会扫描定位到的日志文件。
- 归档文件不连续，CPT日志分析需要按归档的生成顺序来分析，当出现某个归档文件丢失的情况下，CPT在定位LSN或是解析日志过程中就会被阻塞。
5)CPT报错退出
- 在数据库没提供服务的情况下启动DMHS，2017.12.19号以前的版本会因为获取不到归档目录而报错，该种错误通过分析源端日志可以很明确的做出判断，待数据库提供服务以后，重启源端DMHS服务就能解决。
- 未装载离线字典？CPT启动分析需要离线字典的支持，在启动CPT之前需要使用COPY命令装载同步表的字典信息。
- 没有开启逻辑或是全日志的情况下，启动CPT会通不过检查而退出。
2.运行报错
DMHS在运行过程中需要关注源端和目标端的日志输出，运行错误日志会标有[ERROR]标签，CPT的运行出错一般是由于内部的BUG或是外部数据库的影响，请根据错误信息判断如何做相应的处理。
EXEC模块数据入库出错是数据同步过程中最常见的错误，INSERT操作插入报错、UPDATE和DELETE影响的行数和预期的不一致等等这些问题，都需要人工分析方可定位问题。DMHS提供了PRINT命令以及EXEC模块的save_mask参数来帮助分析这些问题。
3.字符集乱码
同步数据的编码问题往往发生在LINUX环境的数据库同步上，一般分为数据库对像名乱码和VARCHAR数据类型列的值乱码。
数据库对像名的乱码最常见的是LINUX下ODBC驱动BUG导致，先确认当前目标端的ODBC驱动版本是否低于2.3.0，如果低于该版本，首先尝试升级ODBC驱动。如果问题依旧存在，则需要设置当前窗口的字符集或dmhs_serverd启动脚本中的字符集为源端数据库的字符集。
VARCHAR数据类型乱码则需要设置当前窗口的字符集或dmhs_serverd启动脚本中的字符集为源端数据库的字符集。
需要注意，每种数据库客户端驱动设置字符集的方法不同。
4.检查点阻塞
检查点阻塞的原因有很多，常见的有以下几种：
1)源端数据库有长时间未提交的事务。这种问题需要通过查询源端数库当前活动的事务信息，通过事务ID和目标端检查等待的事务ID进行对比，如果一致则说明该事务执行时间过长，这种情况下需要多方判断该事务是否是正常事务，然后采取相应的措施。
2)目标端数据库资源被其它应用上锁，导致EXEC模块入库时阻塞。这种问题需要通过查询目标端数据库，看看DMHS执行的SQL存不存在阻塞的情况，如果没有阻塞，则需要确认同步的SQL执行效率是否低下，比如在没有索引的表上做更新或删除，但是表的记录数又非常多。
3)DMHS同步过程中存在事务泄露的BUG，在同步过程中某些事务的提交或回滚的操作丢失，导致EXEC模块一直缓存着该事务。在排除了上现几种情况以后，基本上可以确认是事务泄露，可以通过控制台的ROLLBACK或COMMIT命令来回滚相应的事务。
5.同步阻塞
该问题在数据同步的时候比较常见，最基本的现像是统计长时间没有变化，执行端检查点不更新。在这种情况下，需要根据统信息展示的信息来判断故障点发生在哪个模块。
1)目标端EXEC模块阻塞，当发生这种问题时，目标端往往会堆积有大量等待执行的事务，NET模块的发送端队列长度达到了100%。在这种情况下，需要结合目标端的运行日志做进一步的判断，下面列出可能的几种情况。
- 入库效率低下导致，目标库某个表存在大量的记录，表上没有索引或主键，却需要同步该表的UPDATE或DELETE操作。这种问题可以通过控制台的THR命令来定位发生问题的表，检查EXEC模块每个工作线程的当前状态，如果状态是执行状态，则需要重点关注该线程正在操作的表是否存在上述现像。如果存在，停目目标端的DMSH服务后，在相关的表上创建索引或是主键，然后重启目标端的DMHS服务。
- 入库事务被阻塞，EXEC模块的工作线程在入库操作过程中，需要要上锁的表或行被其它第三方应用占用，通过在目标数据库查询相应的锁等待信息便可以确认该问题，如果是EXEC模块工作线程之间引发的互锁，则可能需要更改提交策略(commit_policy)参数，看看该参数是否为1？改为1以后重启。注意，当多对一同步的环境中发生该问题，则有可能是源端多个站点操作的数据在目标端存在冲突，可以尝试先停目某个冲突站点的同步来解决冲突的数据更新。
- 目标端数据库异常，该问题通过观查目标端的运行日志是否有相关的报错便可作用判断。
- 大事务缓存，由于EXEC模块默认采用内存来缓存未提交的事务，当某个事务缓存耗尽内存时，EXEC模块将会把该事务缓存到本地磁盘以便释放内存，在这期间它不会接收任何新的数据，看起来像是卡住一般。这种状态可以通过判断EXEC模块的运行日志来确认，适当放大exec_sql数可以缓解该现像，但是依然不能完全避免该问题发生。
2)网络中断或是网络阻塞，一般表现为目标端无等待入库的事务，当前的状态也是空闲状态，而源端的发送模块队列却是满载。
- 网络断开的问题比较好判断，只需要查看源端DMHS的运行日志基本上就可以得出结论。
- 网络阻塞一般发生在带网闸的环境中，源端的NET模块投递消息到目标端的NET模块过程中，源端NET模块收不到目标端接收成功的握手消息便会被阻塞在网络套接字上。该问题只需要在源端通过判断统计中NET发送的状态是否为“等待回执”，而目标端统计信息中的NET接收的状态是“等待接收日志”来判断，一般可以通过重启源端的DMHS服务来解决，或者使用SEND配置项中的TIMEOUT属性自动关闭接收超时的连接。
3)日志分析阻塞，该问题的表现比较难判断，需要结合源端的运行日志和控制台的CP命令，多方位获取有用的线索得出结论。
- 归档不连续导致日志读取阻塞，表现为统计信息中EXEC模块以前NET模块都无事务堆积，CPT模块本身的统计信息中也无待分析的日志堆积，源端DMHS的运行日志则停表现出CPT停留在某个归档文件上不推进。在这种情况下，再使用CP命令查看当前CPT读线程的状态是否总是停留在当前归档文件的某个偏移上。这种问题需要补齐缺失的归档或是删除不连续的归档后重新同步。
- DDL缓存引起源端CPT长时间的缓存操作，表现为源端DMHS的IO吞吐量很高，有大量的读和写操作，并且DDL目录下有文件持缓的增涨，一个大的查询建表就会引发这种暂时性的同步阻塞，这种阻塞不用手工恢复，它会自己恢复。
- 在线日志读取阻塞，CPT在读取在线日志时会对读取的日志内容进行校验操作，如果日志页的CRC校验不通过则会不断的重复读取，这种问题表现为源端DMHS的CPU使用率不高，但是IO读却比较高，这种问题可以尝试重启源端DMHS服务，如果重启无效，那么可以通过源端数据库执行切换的命令，把在线日志进行归档后再试，依然不能解决则需要联系更专业的人员进一步的分析定位。
6.DDL未同步
在普通的单向同步环境中如果发现DDL未能同步，往往是下面几点原因：
1)目前CPT对DDL的捕获有两种方式，一种是通过事件触发器来捕获DDL的SQL；另一种则是通过解析源端数据库的系统表来猜测DDL的操作。前者需要在源端数据库建立事件触发器，在这种情况下，如果发现DDL没有同步，首先要检查源端数据库的辅助表DMHS_DDL_SQL是否记录了事件触发器捕获到的DDLSQL，如果没有，则可能是数据库层面禁用了事件触发器，例如DM数据库可以禁用事件触发器；源端数据库为ORACLE时，需要确认_system_trig_enabled参数是否生效。最重要的一点是要保证DMHS_DDL_SQL表的字典已经被装载，如果该表被重建过，则需要重新装载。
2)源端和目标端的SITEID相同，在这种情况下DDL操作在同步时会被丢弃。
3)当源端数据库为DM6时，CPT和EXEC模块不能放在同一个DMHS服务下，需要使用独立的DMHS服务加载它们。
4)当CPT和EXEC模块在同一个DMHS服务下时，如果EXEC配置的参数level的值为65535时，EXEC模块会抛弃CPT发过来的所有DDL操作，因为在level参数为65535的情况下，EXEC模块会认为是级联模式，会校验CPT所属于SITEID和EXEC模块是否相同，如果相同则直接丢弃，防止同步成环。
7.进程异常
在普通的同步环境下，DMHS进程分为源端和目标端两个，这两个进程相互独立，可能由于程序的BUG或是其它外部原因导致同步服务进程异常CORE掉，下面列出几种常见的异常和解决办法供维护人员参考：
1)源端最常见的是分析异常，由于源端日志分析需要依据离线字典记录的数据类型进行转换操作，如果离线字典的版本和当前日志不匹配，那就会发生使用错误的数据类型对日志进行解析的问题，导致异常。在这种情况下，如果生成有CORE文件，可以使用check_core命令来获取CORE文件中当前正在分析的表ID，通过重装该表的字典来尝试解决该问题。
2)当EXEC模块的exec_policy参数配置为1时，工作线程入库出错便会主动终止DMHS进程，这种情况下需要结合PRINT命令来分析出错的原因，修复现有的数据后便可重新启动同步。
3)其它异常则需要更专业的研发人员来判断故障原因。
8.双向死循环
双向同步最主要的问题就是防止数据来来回回的重复复制，出现死循环式的同步，一般造成这个问题的原因多数是由于DMHS_TRXID_TABLE表的字典没有装载。搭建双向同步应该先把两个节点的EXEC模块起动，然后在两个节点上装载字典，这样子可以保证EXEC模块初始化建的辅助表的字典能够被装载。
双向同步如果在某个CPT模块过滤规则中过滤了DMHS_TRXID_TABLE表的同步也会造成复制的死循环，请注意检查过滤规则。
当同步的源和目标数据库都是DM6时，EXEC模块则需要配置trxid_table_depots参数为1才行，由于DM6是多库的，如果没有配置该参数，那么事务的信息只会登记在配置文件指向的库上，导致同步库上的事务无法识别是否来自DMHS。
9.级联丢数或数据重复
级联环境，最常见的故障是在搭建后起动同步时发生某个节点没有预期收到同步的数据，针对这个问题，主要是由于某个中间节点EXEC模块的LEVEL设置不正确或是整个级联链路里面节点之间有重复的SITEID导致。
排查该问题，首先要确保每个EXEC模块的LEVEL参数值配置为65535，如果在配置中没有找到该参数，则需要添加
数据重复，主要源于某个站点的DMHS_TRXID_TABLE表数据操作未同步，而影响该表操作同步的主有要两点：
1)该表在所属CPT下的离线字典未装载，导致该表没有被CPT捕获分析，重新装载该表字典即可。
2)该表在所属CPT的SEND过滤条件中被过滤，导致该表的操作未能投递出去，需要在过滤条件中显示的增加对该表的同步。
10.数据不同步
这种现像一般表现为源端CPT日志分析状态正常，目标端查看统计信息中影响的行数和提交的事务数都为0，并且日志中没有源端站点的检查点信息。这种现像一般是由下面原因导致，请参考。
1）源库被还原的场景，源端还原以后，由于源端的LSN被重置为以前很小的值，而目标端的事务检查点信息未作清理，还是保留了先前较大的LSN，导致源端根据该LSN过滤掉了日志。
2）源端配置文件中的站点号修改为其它值，而目标端刚好有对应该值的事务信息，这种现像一般比较容易发生在同步源为DM6的环境。导致源端根据新的站点号取到了跟它不匹配的LSN，导致日志被过滤。