ogg oracle 同步mysql的一个莫名其妙的语法错误排查GG-00768 SQL error (1064)

      最近在测试goldengate 从ORACLE 同步到MYSQL，总是出现某一张表的进程同步会出现异常终止，在开启实时同步之前，已通过ogg初始化将数据迁移到mysql，后开启实时同步，在抽取复制了部分数据后就突然终止，

2018-10-27 17:28:15  ERROR   OGG-00768  DYNSQL: Preparing SQL statement (ID = 0) failed. SQL error (1064). You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%T SET %S WHERE %W' at line 1.

***********************************************************************

*                   ** Run Time Statistics **                         *

***********************************************************************

Reading /data/ogg/dirdat/b1000000177, current RBA 126808413, 6 records, m_file_seqno = 177, m_file_rba = 126808413

Report at 2018-10-27 17:28:15 (activity since 2018-10-27 17:28:14)

No records were replicated.

Last log location read:

     FILE:      /data/ogg/dirdat/b1000000177

     SEQNO:     177

     RBA:       126808413

     TIMESTAMP: 2018-10-27 17:25:31.998288

     EOF:       NO

     READERR:   0

2018-10-27 17:28:15  ERROR   OGG-01668  PROCESS ABENDING.

关于这个错误：

check the manual that corresponds to your MySQL server version for the right syntax to use near '%T SET %S WHERE %W' at line 1.

该错误看起来，是ogg 复制进程在向mysql执行sql时出现了语法错误。

最开始的分析思路是这样的：

1. 为什么会出现语法错误？

  2.并不是所有事务所有语句会同步错误

  3.那是在哪一条语句出现了错误。

关于为什么会出现语法错误？

首先是怀疑是触发了mysql 保留字导致，但如果是这样是否每个事务语句的执行都应该是有问题。

mos上说是bug,但最终报错的位置是不同的。

MySql Replicat Abend With SQL Error 1064 (文档 ID 1500680.1)

On : 11.2.1.0.1 version, REPLICAT executable

When attempting to start the replicat the following error occurs
the following error occurs.

ERROR
-----------------------
"DYNSQL: Preparing SQL statement (ID = 0) failed. SQL error (1064). You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'key,value,`created_at`,`updated_at`) VALUES (?,?,?,?,?"

于是，开始想办法最终是在什么语句执行会出现错误。 从以上报错的信息，使用 logdump 查看相应位置 rba 126808413 数据信息。

./logdump

Oracle GoldenGate Log File Dump Utility for MySQL

Version 12.3.0.1.5 OGGCORE_12.3.0.1.0_PLATFORMS_180501.2124

Copyright (C) 1995, 2018, Oracle and/or its affiliates. All rights reserved.

Logdump 213 >open /data/ogg/dirdat/b1000000177

Current LogTrail is /data/ogg/dirdat/b1000000177 

Logdump 214 >pos 126808413

Reading forward from RBA 126808413 

Logdump 215 >n

2018/10/27 17:25:31.998.288 GGSUnifiedUpdate      Len    36 RBA 126808413 

Name: xxxxxxx  (TDR Index: 11) 

After  Image:                                             Partition 12   G  s   

 1000 0000 0000 0c00 0000 0800 3237 3432 3337 3331 | ............27423731  <<<<<<<报错数据的主键

 0000 0c00 0000 0800 3237 3432 3337 3331           | ........27423731  

   

Logdump 216 >

该条SQL操作的数据是27423731 主键的这行数据，且这是条UPDATE语句。

在复制进程端解析trail 文件中的sql。

edit params xxx

加入以下参数

showsyntax

nodynsql

nobinarychars

执行：

./replicat paramfile  /data/ogg/dirprm/rebpmc3.prm

之后一直回车直到报错。最后执行的SQL如下：

INSERT INTO `xxx`.xxxMATERIAL` (` Materialid `,`Materialname`,`Productid`,`Picsize`,`Piclength_Bak`,`Picwidth_Bak`,`Picheight_Bak`,`M........atus`) VALUES (' 27429245 ','办xxx',NULL,NULL,NULL,NULL,NULL,0,0,'C00000000','00435320','1000353061','2018-10-27 17:25:24.000000',0,NULL,NULL,0,0,21,0,0,0,0,NULL,'cabinet_floor',0,0,'12005458,00658412,08989038,00193428,00658388,02933575,14414950,00294959,00284882,00190795,0012........

(S)top display, (K)eep displaying (default): 

2018-10-27 17:28:15  WARNING OGG-00869  SQLFormatter::ToSQLUpdate invalid statement object, no SETParams.

Source Context :

最后执行的的SQL实际是最后一次正常执行的语句，这是insert语句，在执行完该insert 语句之后，执行下一条语句便报错了。并且结合以上，该报错sql连语法检测都不通过。

在MYSQL端，我想到的是打开通用日志，发现MYSQL 仍然只能看到上一条

mysql> set global general_log=ON

    -> ;

Query OK, 0 rows affected (0.00 sec)

SQL error (1064). You have an error in your SQL syntax;

这个错误，当我们的sql逻辑出现异常时，即mysql检测失败，此时根本不会在数据库中执行，这也是为什么以上无法捕捉报错sql的原因了。

那么，此时就得想办法从源端查找了。

在源端抽取进程配置 formatsql 参数，将抽取数据的SQL打印出来。

GGSCI (mha-datacenter02 as ggs@gjlvdb) 150> edit params exttest

extract exttest

。。。

FORMATSQL ORACLE, NONAMES  <<<<加入这一行

ExtTrail ./dirdat/t1

查看相应语句：

~  less  t1000000001 

                                                               

INSERT INTO xxxx VALUES (' 27429245 ','办公',NULL,NULL,NULL,NULL,NULL,0,'0','C00000000','00435320','1000353061',TO_DATE('2018-10-27:17:25:24','YYYY-MM-DD:HH24:MI:SS'),0,NULL,NULL,0,0,21,0.00,0.00,0.00,0,NULL,'cabinet_floor',0,0,'12005458,00658412,08989038,00193428,00658388,02933575,144149.....L);

COMMIT WORK;

--B,2018-10-27:17:25:32.000000,1540632332,1853

UPDATE xxxx SET MATERIALID='27423731' WHERE MATERIALID='27423731';<<<<<<<

COMMIT WORK;

由此在源端找到了该报错的SQL,发现这是一条更新主键的SQL.在实际应用中产生这样的SQL真的很不应该。

其实，这条sql在执行上也并没有毛病，且不应该会引起语法错误啊。

mysql> UPDATE xxx SET MATERIALID='27423731' WHERE MATERIALID='27423731';

Query OK, 0 rows affected (0.00 sec)

Rows matched: 0  Changed: 0  Warnings: 0

我直接在MYSQL数据库中执行是正常的。

而在OGG 中对主键的更新是否会存在影响。由于是在初始化阶段，我看到我的配置里添加了 HANDLECOLLISIONS 的参数， HANDLECOLLISIONS  的参数本意是在初始化阶段解决一些目标端找不到数据的情况。

Missing updates are ignored.
Missing deletes are ignored.
Duplicate inserts are turned into updates.

很明显和我这种情况不符，但在mos的一篇文章看到这样一句话，让我感觉会有影响。

the PK is not available at target side, then this error is expected, because HANDLECOLLISIONS turns the PK update into an insert as result of no target record to update.

于是将 HANDLECOLLISIONS   参数去除，发现同步正常了。

在未添加 HANDLECOLLISIONS   的情况下，在源端执行UPDATE xxx SET MATERIALID='27423731' WHERE MATERIALID='27423731';发现 复制进行其实可以读到。

Replicating from PMC.CWDTEST11 to pmc.cwdtest11:

*** Total statistics since 2018-10-27 22:18:47 ***

Total inserts                               0.00

Total updates                               7.00

Total deletes                               0.00

Total discards                             0.00

Total operations                           7.00

但是，在MYSQL的通用日志并没有记录相应的sql,很明显ogg并没有将该sql 拿到mysql中执行提交，也对，这本身就是毫无意义的sql，傻子才写出这样的sql逻辑。

2018-10-27T15:19:41.702275Z 4652 Query commit

2018-10-27T15:19:51.705939Z 4652 Query begin

2018-10-27T15:19:51.706025Z 4652 Query commit

2018-10-27T15:19:53.706920Z 4652 Query begin

2018-10-27T15:19:53.707090Z 4652 Query UPDATE `pmc`.`checkpoint`   SET last_update_ts = current_timestamp,   rba = 414723, version=1, seqno = 0, audit_ts = '2018-10-27 23:19:47.986899', log_bsn = NULL, log_csn = '25475087', log_xid = NULL, log_cmplt_csn = '25475087', log_cmplt_xids = '0.9.3.21639' WHERE group_name = 'REPTEST' AND group_key = '3895688168'

2018-10-27T15:19:53.707402Z 4652 Query commit

2018-10-27T15:20:03.712012Z 4652 Query begin

2018-10-27T15:20:03.712207Z 4652 Query UPDATE `pmc`.`checkpoint`   SET last_update_ts = current_timestamp,   rba = 418129, version=1, seqno = 0, audit_ts = '2018-10-27 23:19:57.986800', log_bsn = NULL, log_csn = '25475087', log_xid = NULL, log_cmplt_csn = '25475087', log_cmplt_xids = '0.9.3.21639' WHERE group_name = 'REPTEST' AND group_key = '3895688168'

2018-10-27T15:20:03.712522Z 4652 Query commit

2018-10-27T15:20:13.716284Z 4652 Query begin

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29863023/viewspace-2217771/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29863023/viewspace-2217771/