本发明涉及计算机数据备份容灾
技术领域：
：，特别是涉及一种对db2数据库建表日志列名解析的方法及装置。
背景技术：
：：db2为ibm开发的一种大型关系型数据库平台，它支持多用户或应用程序在同一条sql语句中查询不同database甚至不同dbms中的数据，是目前使用最广泛的关系数据库系统之一。目前，db2数据库在解析createtable(建表)日志时会依次产生三种类型的日志数据：一种是componentidentifier为11、functionidentifier为4的原始sql日志记录，需要设置数据库属性log_ddl_stmts为yes；一种是componentidentifier为4、functionidentifier为101的建表日志记录；还有一种是componentidentifier为1、functionidentifier为128的初始化表的日志记录，要求在建表或修改表时声明datacapturechanges属性，其中，原始sql日志记录包括输入sql的原文，建表日志的数据均为数据库内部使用，初始化表日志中主要包含表的列属性与列的个数等。在实时解析createtable(建表)操作时，需获取到表名与表结构，其中表结构主要包括列名与列属性，可以从原始sql日志记录分析中获取表名、在初始化表日志中可获取到列属性但没有列名，而在解析完毕将json格式的新建表的基本信息发送至kafka时，需要发送表名、schema名、列名、列属性等信息。为解决上述问题，目前直接方法一般采取从原始sql日志中直接解析sql语句，按照createtable(建表)的语法或其他特征来分解sql语句的各个单词，从而获取列名。但是，以sql语法来解析createtable(建表)语句中的各类信息，基本等同于实现一个用于解析createtable(建表)语句的编译器，这样虽然能保证程序完善，但对开发人员的技术水平要求较高，实现起来过于复杂、费时；用sql语句里的其他特征(如空格、逗号和左右括号等)以字符串匹配的方式来解析createtable(建表)语句中的各类信息，虽然实现起来较为简单，但是难以覆盖使用createtable(建表)操作的各种情形，可能导致createtable(建表)操作解析失败甚至程序崩溃。技术实现要素：为克服上述现有技术存在的不足，本发明之目的在于提供一种对db2数据库建表日志列名解析的方法及装置，以实现在createtable(建表)日志解析中获取列名的目的。为达上述目的，本发明提出一种对db2数据库建表日志列名解析的方法，包括如下步骤：步骤s1，在解析建表日志时，对原始sql日志进行解析，从sql语句中分离出表名和schema名，并存入用于表示表基本信息的一解析结构体中；步骤s2，对初始化表的日志，从中获取表id、表空间id以及表的各列属性信息，存入所述解析结构体中，并构建一个任务结构体，于所述任务结构体设置一个建表操作的标志数，将获取到的表id、表空间id存所述任务结构体中；步骤s3，按照任务队列的顺序读取任务结构体，并判断是否建表操作，对于建表操作，根据所述任务结构体、解析结构体及数据库系统表获取表名、schema名、列名、列属性等信息拼装成json格式的sql操作的基本信息发送到kafka。优选地，于步骤s1中，对于原始sql日志中带括号的建表语句，对其按照首个左括号和其前的空格分离得到表名和schema名。优选地，对于原始sql日志中不带括号的建表语句，根据建表语法分离得到表名和schema名。优选地，于步骤s3中，首先按照任务队列的顺序读取任务结构体，根据步骤s2中设置的标志数确定当前任务结构体的操作是否建表操作，若是建表操作，再根据所述任务结构体中保存的表id和表空间id找到相应的解析结构体；依据所述解析结构体提供的表名以及表的schema名于数据库系统表中查询获得相应的列名，并将列名存入所述解析结构体，使所述解析结构体中的列属性和列名相互对应；最后将所述解析结构体中的表名、schema名、各列列名和列属性等拼装成json格式的建表操作的基本信息，并将其发送至kafka。优选地，在将相应的列名存入所述解析结构体之前，将查询到的信息存入一个新的暂时结构体中，并将其与所述解析结构体进行比较，进行异常处理。优选地，于步骤s3中，在将相应的列名存入所述解析结构体之前，判断所述解析结构体与所述暂时结构体中保存的列个数和列的属性是否均相同，若所述解析结构体与暂时结构体中保存的列个数和列的属性均相同，则可认为是同一张表，则将所述暂时结构体中的列名依次复制到所述解析结构体中，完成建表操作的列名解析。优选地，若所述解析结构体与暂时结构体中保存的列个数和列的属性不均相同，则认为出错，产生提示信息，提示当前表可能已被删除并退出。为达到上述目的，本发明还提供一种对db2数据库建表日志列名解析的装置，包括：原始sql日志解析单元，用于在解析建表日志时，对原始sql日志进行解析，从sql语句中分离出表名和schema名，并存入表示表基本信息的一解析结构体中；初始化表日志解析单元，用于对初始化表的日志，从中获取表id、表空间id以及表的各列属性信息，存入所述解析结构体中，并构建一个任务结构体，于所述任务结构体设置一个建表操作的标志数，把获取到的表id、表空间id存入所述任务结构体中；解析查询单元，用于按照任务队列txn的顺序读取任务结构体，并判断是否建表操作，对于建表操作，根据所述任务结构体、解析结构体及数据库系统表获取表名、schema名、列名、列属性等信息拼装成json格式的sql操作的基本信息发送到kafka。优选地，所述解析查询单元根据所述初始化表日志解析单元设置的标志数确定当前操作是否建表操作，再根据所述任务结构体中保存的表id和表空间id找到相应的解析结构体；依据所述解析结构体提供的表名以及表的schema名于数据库系统表中查询获得相应的列名，并将列名存入所述解析结构体，使所述解析结构体中的列属性和列名相互对应；最后将所述解析结构体中的表名、schema名、各列列名和列属性拼装成json格式的建表操作的基本信息，并将其发送至kafka。优选地，所述装置还包括异常处理单元，用于在将相应的列名存入所述解析结构体之前，判断所述解析结构体与所述暂时结构体中保存的列个数和列的属性是否均相同，若所述解析结构体与暂时结构体中保存的列个数和列的属性均相同，则可认为是同一张表，则将所述暂时结构体中的列名依次复制到所述解析结构体中，完成建表操作的列名解析。与现有技术相比，本发明一种对db2数据库建表日志列名解析的方法及装置通过解析日志时，首先从sql语句中分离出表名和schema名，从初始化表的日志中获取获取表id、表空间id以及表的各列属性信息，并将该些信息统一保存在解析结构体中，同时构建一个任务结构体，于所述任务结构体设置一个建表操作的标志数，把获取到的表id、表空间id存入其中，按照任务队列txn的顺序根据任务结构体、解析结构体及数据库系统表获取表名、schema名、列名、列属性等信息拼装成json格式的sql操作的基本信息发送到kafka，实现了在建表createtable日志解析中获取列名的目的。附图说明图1为本发明一种对db2数据库建表日志列名解析的方法的步骤流程图；图2为本发明一种对db2数据库建表日志列名解析的装置的系统架构图。具体实施方式以下通过特定的具体实例并结合附图说明本发明的实施方式，本领域技术人员可由本说明书所揭示的内容轻易地了解本发明的其它优点与功效。本发明亦可通过其它不同的具体实例加以施行或应用，本说明书中的各项细节亦可基于不同观点与应用，在不背离本发明的精神下进行各种修饰与变更。图1为本发明一种对db2数据库建表日志列名解析的方法的步骤流程图。如图1所示，本发明一种对db2数据库建表日志列名解析的方法，包括如下步骤：步骤s1，在解析建表(createtable)日志时，对原始sql日志进行解析，从sql语句中分离出表名和schema名，并将表名和schema名存入表示表基本信息的解析结构体tab中。具体地说，在解析建表日志时，首先对原始sql日志进行解析，对于带括号的建表语句，通过对sql语句按照首个左括号和首个左括号之前的空格进行分解，即可分离得到表名和schema名，并将表名和schema名存入表示表基本信息的解析结构体tab中，例如一个简单的建表语句：”createtablemyschema.tabname(idint)”，根据建表(createtable)的sql语法，若建表语句中存在左括号，那么首个左括号均紧邻在新建表的表名之后，所以可分解得到字符串”createtablemyschema.tabname”；因为”createtable”是处于固定位置且内容始终不变的字符串，所以可以直接略过”createtable”这13个字符，得到字符串”myschema.tabname”；又因为表名中不可能带有空格，故以此字符串中的第一个空格进行分割，得到字符串”myschema.tabname”；其中有小数点的时候按小数点进行分割，小数点前的是schema名”myschema”，小数点后的是表名”tabname”；对于不带括号的建表语句，如：”createtabletabnameliketabname2”，因为建表语句中不存在左括号，所以直接略过”createtable”，得到字符串”tabnameliketabname2”；又因为表名中不可能带有空格，故以此字符串中的第一个空格进行分割，从此字符串开始到此字符串第一个空格前的子字符串为”schema名.表名”，由于其中没有小数点，故表名为”tabname”，原始sql日志中包含默认schema名，故此处的schema名可从原始sql日志中获取。步骤s2，对初始化表的日志，从中获取表id、表空间id以及表的各列属性等信息，并存入解析结构体tab中，同时构建一个任务结构体txn存入任务队列，将建表(createtable)操作存入任务队列的任务结构体txn中，所述任务队列的任务结构体txn包含一个建表(createtable)操作的标志数和表id、表空间id，具体地，设置一个建表(createtable)操作的标志数，并将获取到的表id、表空间id存入任务结构体txn中，此标志数是通过一个在程序启动时头文件中定义的包括各种sql操作(如插入数据、删除数据、更新数据、新建表、删除表等)的枚举类型得到的，本发明具体实施例中该建表(createtable)操作的标志数可设置为15(即代表建表操作)，枚举类型中枚举常量默认序号一般从0开始，也就是说当前任务结构体对应的操作是第16种操作，需说明的是，步骤s2设置的标志数和步骤s3按照标志数判断是哪种sql操作相互对应。也就是说，任务队列中依次存放了若干个任务结构体；任务结构体则中保存了各种sql操作的基本信息，通过任务队列，保证了发送json格式的sql基本信息到kafka的时候，这些信息的顺序和用户在数据库的操作顺序是一致的。在本发明中，在程序启动时就会产生任务队列并初始化完毕，当一整个事务解析完毕时，会将解析这个事务时所构建的所有任务结构体均存入任务队列中(需注意的是，每个操作都会生成一个任务结构体，但只有建表操作会生成表示表基本信息的解析结构体tab)；当发现任务队列中存放了任务结构体时，则进入步骤s3。步骤s3，按照任务队列的顺序读取任务结构体，并判断是否建表操作，对于建表操作，根据任务结构体txn、tab结构体及数据库系统表获取表名、schema名、列名、列属性等信息拼装成json格式的sql操作的基本信息发送json格式的各种sql操作的基本信息到kafka。具体地，首先按照任务队列的顺序读取任务结构体txn的标志数并进行判断，根据步骤s2中设置的标志数确定当前读取的任务结构体的操作是否为建表操作(例如步骤s2中定义的建表操作的标志数为15，此处则根据读取的任务结构体的标志数判断是否为15以判断是否为建表操作)，再根据txn结构体中保存的表id和表空间id找到相应的tab结构体；依据所述tab结构体提供的表名以及表的schema名到数据库的系统表中进行查询，获得相应的列名，并将列名存入tab结构体，使tab结构体中的列属性和列名相互对应，此时列名已经解析完成，tab结构体中的全部信息已经完整；然后将tab结构体中的表名、schema名、各列列名和列属性等拼装成json格式的建表操作的基本信息，并将其发送至kafka，至此完成了解析建表操作和将json格式的建表操作的基本信息发送至kafka。在本发明具体实施例中，所述数据库为db2数据库，当需要发送建表操作的json数据时，依据txn任务结构体中的表id和表空间id去内存中读取相应的tab解析结构体，并依据tab解析结构体中存放的表名和schema名去数据库的系统表sysibm.syscolumns中查询相应表的列信息，包括列名、列属性等，并将查询到的信息存入一个新的暂时结构体temp中。因为db2数据库存在表id复用的情况、解析和发送均可能慢于数据库的执行速度、用户可能进行建表再删表以及连续建表删表的操作，因此，步骤s3中可能存在出现在数据库中查询到的不是希望查询的表甚至根本查不到这张表的可能性，所以还需要进行异常处理。因此，于步骤s3中，还需进一步判断解析结构体tab与暂时结构体temp中保存的列个数和列的属性是否均相同，若结构体tab与暂时结构体temp中保存的列个数和列的属性均相同，则可认为是同一张表，将暂时结构体temp中的列名依次复制到结构体tab中，完成建表操作的列名解析，否则认为出错，提示此表可能已被删除并退出。图2为本发明一种对db2数据库建表日志列名解析的装置的系统架构图。如图2所示，本发明一种对db2数据库建表日志列名解析的装置，包括：原始sql日志解析单元201，用于在解析建表(createtable)日志时，对原始sql日志进行解析，从sql语句中分离出表名和schema名，并将表名和schema名存入表示表基本信息的解析结构体tab中。具体地说，在解析建表日志时，由原始sql日志解析单元201首先对原始sql日志进行解析，通过对sql原文按照首个左括号和此前的空格即可分离得到表名和schema名，并将表名存入表示表基本信息的解析结构体tab中。初始化表日志解析单元202，用于对初始化表的日志，从中获取表id、表空间id以及表的各列属性等信息，并存入解析结构体tab中，并构建一个任务结构体txn，将建表(createtable)操作存入任务队列的任务结构体txn中，所述任务队列的任务结构体txn包含一个各种sql操作的标志数和表id、表空间id，具体地，设置一个建表(createtable)操作的标志数，并将获取到的表id、表空间id存入任务结构体txn中，此标志数是通过一个在程序启动时头文件中定义的包括各种sql操作(如插入数据、删除数据、更新数据、新建表、删除表等)的枚举类型得到的，本发明具体实施例中该建表(createtable)操作的标志数可设置为15(即代表建表操作)，枚举类型中枚举常量默认序号一般从0开始,也就是说当前任务结构体对应的操作是第16种操作，需说明的是，步骤s2设置的标志数和步骤s3按照标志数判断是哪种sql操作相互对应。。解析查询单元203，用于按照任务队列的顺序读取任务结构体，并判断是否建表操作，对于建表操作，根据任务结构体、结构体tab及数据库系统表获取表名、schema名、列名、列属性等信息拼装成json格式的sql操作的基本信息发送到kafka。具体地，首先按照任务队列的顺序读取任务结构体txn的标志数并进行判断，根据初始化表日志解析单元202中设置的标志数确定当前读取的任务结构体的操作是否为建表操作(例如初始化表日志解析单元202中定义的建表操作的标志数为15，此处则根据读取的任务结构体的标志数判断是否为15以判断是否为建表操作)，再根据txn结构体中保存的表id和表空间id找到相应的tab结构体；依据所述tab结构体提供的表名以及表的schema名到数据库的系统表中进行查询，获得相应的列名，并将列名存入tab结构体，使tab结构体中的列属性和列名相互对应，此时列名已经解析完成，tab结构体中的全部信息已经完整；然后将tab结构体中的表名、schema名、各列列名和列属性等拼装成json格式的建表操作的基本信息，并将其发送至kafka，至此完成了解析建表操作和将json格式的建表操作的基本信息发送至kafka。在本发明具体实施例中，所述数据库为db2数据库，当需要发送建表操作的json数据时，依据任务结构体txn中的表id和表空间id去内存中读取相应的解析结构体tab，并依据解析结构体tab中存放的表名和schema名去数据库的系统表sysibm.syscolumns中查询相应表的列信息，包括列名、列属性等，并将查询到的信息存入一个新的暂时结构体temp中。因为db2数据库存在表id复用的情况、解析和发送均可能慢于数据库的执行速度、用户可能进行建表再删表以及连续建表删表的操作，因此，解析查询单元203在查询时可能存在出现在数据库中查询到的不是希望查询的表甚至根本查不到这张表的可能性，所以还需要进行异常处理。因此，本发明之一种对db2数据库建表日志列名解析的装置还包括异常处理单元204，用于判断解析结构体tab与暂时结构体temp中保存的列个数和列的属性是否均相同，若解析结构体tab与暂时结构体temp中保存的列个数和列的属性均相同，则可认为是同一张表，将暂时结构体temp中的列名依次复制到解析结构体tab中，完成建表操作的列名解析，否则认为出错，提示此表可能已被删除并退出。综上所述，本发明一种对db2数据库建表日志列名解析的方法及装置通过解析日志时，首先从sql语句中分离出表名和schema名，从初始化表的日志中获取获取表id、表空间id以及表的各列属性信息，并将该些信息统一保存在解析结构体中，同时构建一个任务结构体，于所述任务结构体设置一个建表操作的标志数，把获取到的表id、表空间id存入其中，按照任务队列的顺序根据任务结构体、解析结构体及数据库系统表获取表名、schema名、列名、列属性等信息拼装成json格式的sql操作的基本信息发送到kafka，实现了在建表createtable日志解析中获取列名的目的。上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何本领域技术人员均可在不违背本发明的精神及范畴下，对上述实施例进行修饰与改变。因此，本发明的权利保护范围，应如权利要求书所列。当前第1页12当前第1页12