Oracle LogMiner 里头那些重做日志到底咋分析和用法分享

说到Oracle数据库，我们经常会遇到需要知道“数据到底是怎么变的”这种需求，不小心误删了一张很重要的表，或者发现某个关键数据被莫名其妙地修改了，你想知道是谁在什么时候干的，又或者，你想把数据库里的变化同步到另一个地方去，这时候，Oracle自带的一个神器就能派上用场了,它就是LogMiner。

你可以把Oracle数据库想象成一个不停在写日记的人，它做的每一件重要的事情，比如新增一条记录、修改一个字段、删除一行数据，都会老老实实地记录在“日记本”上，这个“日记本”就是Oracle的重做日志文件，而LogMiner，就是给你的一副“神奇的眼镜”，戴上它，你就能读懂这本天书一样的日记，把里面记录的所有操作（像INSERT, UPDATE, DELETE这些）,用我们能看懂的SQL语句的形式展示出来。

根据Oracle官方文档的介绍，LogMiner的主要用途包括好几块，第一块是跟踪变化，你可以用它来跟踪对特定表或者特定用户所做的数据变更，相当于一个高级的审计工具，第二块是用来做数据同步的，比如把生产数据库的变化同步到数据仓库里，第三块就是最常用的，数据恢复，当发生误操作时，你可以通过分析日志，精确地找到错误的操作，并生成对应的SQL语句来恢复数据，第四块是性能分析,看看数据库的负载和事务模式。

这副“神奇的眼镜”具体该怎么用呢？过程其实不复杂,主要分三步走。

第一步，你得先准备好要分析的“日记本”，也就是日志文件，LogMiner不能直接去读数据库正在写的那个当前日志文件，你得告诉它去分析哪些已经写满了的、归档好的历史日志文件，根据Oracle官方文档的说明，你需要先确认数据库是否已经开启了归档模式，因为只有在这个模式下，日志文件才会被完整地保存下来，你可以查询一个叫V$ARCHIVED_LOG的视图，像在图书馆查目录一样，找到你需要分析的那个时间段的日志文件列表,记下它们的完整路径和名字。

第二步，就是启动LogMiner这个“分析引擎”了，这里有个关键概念叫“数据字典”，日志里记录的数据变化可不是直接写着“把张三的年龄从20改成21”，它里面存的都是一些内部编码，比如对象ID、数据类型编码之类的，人是看不懂的，我们需要一个“翻译官”，就是数据字典，根据Oracle官方文档，你有两种选择，一种是在开始分析前，先提取一次当前数据库的字典快照，存到一个文件中，然后让LogMiner用这个文件来翻译，另一种更简单的方法是，直接让LogMiner使用当前数据库在线字典来翻译，这对于分析最新的日志比较方便，准备好字典后，就用DBMS_LOGMNR.ADD_LOGFILE这个过程，把你第一步找到的那些日志文件一个一个地添加进去，用DBMS_LOGMNR.START_LOGMNR这个过程启动分析,并指定使用哪种字典翻译方式。

第三步，也是最激动人心的一步，就是查看分析结果了，引擎启动后，所有的分析结果都放在一个叫V$LOGMNR_CONTENTS的视图里，你可以像查询普通表一样去查它，这个视图里的信息非常丰富，根据Oracle官方文档，最重要的几列包括：SCN（一个唯一标识操作顺序的号码）、时间戳、操作的类型（是INSERT还是UPDATE等）、执行操作的用户名、涉及的表名，以及最关键的，重建这个操作的SQL语句（SQL_REDO）和撤销这个操作的SQL语句（SQL_UNDO），你可以写一个SQL查询，比如SELECT sql_redo FROM v$logmnr_contents WHERE table_name = 'EMPLOYEES';，这样就能把对EMPLOYEES表做的所有修改操作都列出来了，如果你要恢复误删除，重点看的就是SQL_UNDO那一列,它生成的语句能把你删除的数据再插回去。

用完别忘了打扫战场，用DBMS_LOGMNR.END_LOGMNR过程停止分析,释放资源。

这副“眼镜”也不是万能的，根据实际使用经验，有几点需要注意，它只能分析已经归档的日志，如果需要的操作还在当前活动的日志里，你得先手动切换日志让它归档才行，分析大量日志可能会比较耗时，最好能精确指定时间范围或SCN范围，如果表结构在分析期间发生过变化,可能会给翻译带来一些麻烦。

Oracle LogMiner是一个非常强大且实用的工具，它直接把数据库最底层的操作日志翻了个底朝天，给我们做数据追溯、故障恢复提供了最根本的解决方案，虽然刚开始接触那些视图和过程可能觉得有点绕，但一旦掌握了基本流程,它就成为了DBA和开发人员工具箱里一件应对棘手问题的法宝。