logmnr在使用数据字典后分析结果依然有16进制

今天在帮助研发挖日志的时候，遇到个问题，使用的方式是将数据字典放到redo中在异机分析归档日志。
但是总是有一些16进制的sql，感觉是数据字典有问题，但是在生产环境上分析归档也是一样，查看官方文档发现下面的描述。
在线的catalog只能重构表最近的版本，表在修改后，在线的catalog就不能反映之前版本的sql，也就是不能重构正常的sql语句。只能构建包含hextoraw这种的语句
Remember, however, that the online catalog can only reconstruct SQL statements that are executed on the latest version of a table. As soon as a table is altered, the online catalog no longer reflects the previous version of the table. This means that LogMiner will not be able to reconstruct any SQL statements that were executed on the previous version of the table. Instead, LogMiner generates nonexecutable SQL (including hexadecimal-to-raw formatting of binary values) in the SQL_REDO column of the V$LOGMNR_CONTENTS view similar to the following example:

insert into HR.EMPLOYEES(col#1, col#2) values (hextoraw(‘4a6f686e20446f65’),
hextoraw(‘c306’));”
这种情况下如果想要去看具体的字段，可以去查看select * from all_tab_cols;视图找到对应的字段名称，字段值的话只能自己讲十六进制转换成10进制了
所以说logmnr在跟踪分析问题的时候也不是一定很方便的。