logminer进阶用法

logminer进阶用法

实在不好意思，托更了好几天，是因为一直在准备这个实验给大家，希望大家谅解，也同时感谢大家的支持。

今天我们说下logminer的一个特殊用法——logminer进阶用法（其中包括异机分析），这个是问题是我的一个美女粉丝（ @杨筱煦儿）提出来的，我觉的特别好，顺便我也给大家展示一下整个实验的过程。

pick you @杨筱煦儿，谢谢你的支持，我也希望大家有问题能够主动问我，我们一起学习和进步。

我们在前面说过一种logmnr的使用方法，就是通过更改数据库的utl_file_dir，创建一个dictionary的文件，通过包dbms_logmnr.start进行分析。这个方法我们都知道需要重新启动数据库，使得参数utl_file_dir生效，但是我们在生产上如果是单库，没有防止单点故障的机制的话，那么这种方法很显然不适用。所以今天我讲一讲另外两种进阶方法。

oracle官方给出的logminer的dictionary的方法有三种：

1.通过设置utl_file_dir，给定一个路径，使用dbms_logmnr_d.build将字典文件生成到utl_file_dir指定的路径下。缺点就是我们上面说的这样的话对于一个新的数据库我们需要重启才能让设置的参数生效。

2.通过将dictionary文件加入到日志文件（其实是归档）日志文件当中，这样就避免了停机的现象，方便使用。

3.通过 online catalog当中的字典进行分析，这个其实是最方便的，可以分析到当前数据库的归档日志，和redo日志

我这里只说第二个和第三个，想学第一个的朋友看一下我之前的文章。-------欢迎大家推荐和关注我的公众号“最帅dba工作笔记”

第三种online catalog分析redo日志：

案例一：分析redo日志。这个时候误操作发现的早，日志还没有归档。

现在先查一下现在的归档日志;

select * from v$log;

我们发现现在使用的是第6组日志，大家不要介意我的环境，我的日志组修改过，所以是从4开始的，1，2，3都删掉了。

为了导出来的日志数据量显示少一点，我手动切一个日志。

alter system archive log current;

现在自然开始使用第4组日志了

我现在登陆我的用户cui，里面有一张‘niangpao’。我们进行一些数据修改。

这个时候我们要将我们的redo日志添加到logmnr分析包当中。在执行添加分析之前我们一定要保证用户具有执行logmnr执行权限。否则会抛出报错

我们这个时候进行日志添加

exec dbms_logmnr.add_logfile(logfilename=>'/oradata/orcl/redo04.log',options=>dbms_logmnr.new);

这个时候可以通过logminer提供的视图进行查看将那个日志文件添加到了包里。

现在我们发现redo04已经在里面了，我们进行日志分析：

exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_Catalog);

因为logmnr提供的视图都是当前会话存在，所以我们可以创建一个表将他的信息放到里面方便我们的查阅。

之后通过plsql查一下。

很清晰，没有unkown和16进制的数。

案例二：这个日志归档了，试试可不可以分析归档。

现在我手动将这个日志切过去，用生成的归档进行挖掘。

步骤是一样的，我们查一下目前的日志是那个

是193号归档我们同样将生成的视图数据放到一个表里。再去看看。

查看结果

和谐和谐。。。。。。。。

我们说完了这一个方法，说说第二种将dictionary添加到日志文件当中的方法，这个方法一般是用在担心分析库的日志太大，导致一些压力，所以把这个放在另外一台库上执行分析

先描述一下环境：

服务器ip=>172.16.3.27 hostname=> master 源数据库。 sid=orcl

服务器ip=> 172.16.3.4 hostname=> slave 分析数据库。 sid=test

我们先从orcl数据库上进行一段操作。

建了一张“大腿表”然后对他操作。

现在我们下一步是将字典放入到日志文件当中。

现在我们查一下归档的信息：

select name ,dictionary_begin,dictionary_end from v$archived_log;

目前最新的归档是195，而后面的两个字段表达的意思是目前的归档是不是存在字典开始的信息和结束的信息。

这里一定一定一定一定一定要注意啊：当执行了上面那个添加字典到日志当中的命令之后，他会同一时间切两个归档！！！！！！我们看下对应的文件：

从时间上我们看的出，这是一对归档，198是你的数据归档，199是你的字典归档，我们在分析的时候，一定要将这两个归档都拷到另个数据库上，如果只有198那么显示的东西就是16进制+UNKOWN的，如果之后199那么就得不到你想要的数据！！！！！

现在我们将这个文件传到另一台服务器上

现在的操作在另一台服务器进行：

添加日志文件到logminer：

这里要注意，因为字典在日志文件当中所以分析的时候要用另一种方法。

将v$logmnr_contents 复制到一张表里。

通过plsql看一下：

就酱紫！！！！！！！！

实验做完了，说几点注意事项：

1.如果将数据拷到对端的时候报了这个错，把版本号改了就行。

2.dbms_logmnr.start_logmnr(options=>)

options有很多的选项：我随便提几个。。。。

dbms_logmnr.dict_from_online_catalog 在使用catalog数据字典的时候，解析用这个

dbms_logmnr.dict_from_redo_logs 在使用数据字典在日志里的时候，解析用这个

dbms_logmnr.committed_data_only 得到的结果只显示commit的

dbms_logmnr.print_pretty_sql 格式化输出sql

如果想组合使用就用+连起来就行：

dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_form_online_catalog + dbms_logmnr.committed_data_only);

3.logminer会产生几个有用的视图

v$logmnr_dictionary 目前使用的是那个字典，这个只有第一种指定utl_file_dir的时候会显示。

v$lgomnr_logs 目前使用的哪个日志

v$logmnr_parameter 目前设定logminer的参数

v$logmnr_comntents 分析结果

THAT'S ALL

BY CUI PEACE !!!!!!!