找设计师的网站,商洛做网站电话,南宁做网站在哪了,网络科技公司网站制作1.启动失败
DMHS在同步故障或是重启时#xff0c;如果启动失败#xff0c;则有可能是下面几个原因#xff1a;
1)EXEC或CPT模块加载失败EXEC和CPT模块由于需要和数据库进行交互#xff0c;那么它在启动时需要依赖数据库的ODBC和OCI驱动#xff0c;如果它加载失败则说明它…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报错退出
在数据库没提供服务的情况下启动DMHS2017.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如果在配置中没有找到该参数则需要添加level65535/level参数设置然后重启当前节点其次再检查每个节点的SITEID值是否有相同的值应该要保证每个节点的SITEID在整个链路里面唯一最后检查链路里面所有节点的SITEID号必须大于0并小于64在普通的AB同步环境下SITEID的最大值是30000但是在级联的同步环境下SITEID要小于64也就是说整个链路最多只能允许63个节点。
数据重复主要源于某个站点的DMHS_TRXID_TABLE表数据操作未同步而影响该表操作同步的主有要两点
1)该表在所属CPT下的离线字典未装载导致该表没有被CPT捕获分析重新装载该表字典即可。
2)该表在所属CPT的SEND过滤条件中被过滤导致该表的操作未能投递出去需要在过滤条件中显示的增加对该表的同步。
10.数据不同步
这种现像一般表现为源端CPT日志分析状态正常目标端查看统计信息中影响的行数和提交的事务数都为0并且日志中没有源端站点的检查点信息。这种现像一般是由下面原因导致请参考。
1源库被还原的场景源端还原以后由于源端的LSN被重置为以前很小的值而目标端的事务检查点信息未作清理还是保留了先前较大的LSN导致源端根据该LSN过滤掉了日志。
2源端配置文件中的站点号修改为其它值而目标端刚好有对应该值的事务信息这种现像一般比较容易发生在同步源为DM6的环境。导致源端根据新的站点号取到了跟它不匹配的LSN导致日志被过滤。
