深入分析Oracle数据库日志文件（2）

四 如何利用LogMiner分析Oracle 的日志文件 虽然说LogMiner是Oracle i才推出来 但我们同样可以用它来分析Oracle 的日志文件 只不过稍微麻烦了一点 并且有一定的限制 下面是具体做法 我们首先复制Oracle i的$ORACLE_HOME/rdbms/admin/dbmslmd sql脚本到Oracle 数据库所在主机的同样目录 这个脚本用于创建dbms_logmnr_d包（注意 Oracle i中还将创建dbms_logmnr包） 如果是 脚本名字为dbmslogmnrd sql 然后在Oracle 的数据库上运行这个脚本 之后使用dbms_logmnr_d build过程创建字典信息文件 现在我们就可以把Oracle 的归档日志连同这个字典信息文件复制到Oracle i数据库所在的主机上 之后在Oracle i数据库中从上面分析过程的第三步开始分析Oracle 的日志 不过 dbms_logmnr start_logmnr()中使用的是Oracle 的字典信息文件 按照我前面所说的那样 如果不是字典文件 我们则可以直接将Oracle 的归档日志复制到Oracle i数据库所在主机 然后对它进行分析 其实这里涉及到了一个跨平台使用LogMiner的问题 笔者做过试验 也可以在Oracle i中来分析Oracle i的日志 但这些都是有所限制的 主要表现在 LogMiner所使用的字典文件必须和所分析的日志文件是同一个数据库所产生的 并且该数据库的字符集应和执行LogMiner数据库的相同 这很好理解 如果不是同一个数据库所产生就不存在对应关系了 生成日志的数据库硬件平台和执行LogMiner数据库的硬件平台要求一致 *** 作系统版本可以不一致 笔者做试验时（如果读者有兴趣可以到我网站上下载试验全过程 因为太长就不放在这里了） 所用的两个数据库 *** 作系统都是Tru UNIX 但一个是 V A 另一个则是V F 如果 *** 作系统不一致则会出现下面的错误 ORA : file /data /cyx/logmnr/arch_ _ arc cannot be openedORA : cannot open archived log /data /cyx/logmnr/arch_ _ arc ORA : skgfifi: file header information is invalidORA : at SYS DBMS_LOGMNR line ORA : at line 五 分析v$logmnr_contents 前面我们已经知道了LogMiner的分析结果是放在v$logmnr_contents中 这里面有很多信息 我们可以根据需要追踪我们感兴趣的信息 那么我们通常感兴趣的有哪些呢？ 追踪数据库结构变化情况 即DDL *** 作 如前所述 这个只有Oracle i才支持 SQL> select timestamp sql_redo from v$logmnr_contents where upper(sql_redo) like %CREATE% ;TIMESTAMP SQL_REDO : : create table t (c number); 追踪用户误 *** 作或恶意 *** 作 例如我们现实中有这样需求 有一次我们发现一位员工通过程序修改了业务数据库信息 把部分电话的收费类型改成免费了 现在就要求我们从数据库中查出到底是谁干的这件事？怎么查？LogMiner提供了我们分析日志文件的手段 其中v$logmnr_contents的SESSION_INFO列包含了下面的信息 login_username=NEW_ client_info= OS_username=oracle Machine_name=phoenix OS_terminal=ttyp OS_process_id= OS_program name=sqlplus@phoenix (TNS V V ) 虽然其中信息已经很多了 但在我们的业务数据库中 程序是通过相同的login_username登录数据库的 这样单从上面的信息是很难判断的 不过我们注意到 因为公司应用服务器不是每个人都有权限在上面写程序的 一般恶意程序都是直接通过他自己的PC连到数据库的 这就需要一个准确的定位 IP追踪是我们首先想到的 并且也满足我们的实际要求 因为公司内部IP地址分配是统一管理的 能追踪到IP地址我们就可以准确定位了 但从面的SESSION_INFO中我们并不能直接看到IP 不过我们还是有办法的 因为这个SESSION_INFO里面的内容其实是日志从V$SESSION视图里提取的 我们可以在生产数据库中创建一个追踪客户端IP地址的触发器 create or replace trigger on_logon_triggerafter logon on databasebegin　dbms_application_info set_client_info(sys_context( userenv ip_address ));end;/现在 我们就可以在V$SESSION视图的CLIENT_INFO列中看到新登录的客户端IP地址了 那么上面的提出的问题就可以迎刃而解了 假如被更新的表名为HMLX 我们就可以通过下面的SQL来找到所需信息 SQL > select session_info sql_redo from v$logmnr_contents where upper(operation) = UPDATEand upper(sql_redo) like %HMLX% /SESSION_INFO SQL_REDO login_username=C client_info= OS_username=sz xjs chengyx Machine_name=GDTEL\SZ XJS CHENGYXupdate C HMLX set NAME = free where NAME = and ROWID = AAABhTAAFAAABRaAAE ; lishixinzhi/Article/program/Oracle/201311/17810

何为目录数据库？

目录（Catalog）是以完整的出版单元（如一种图书、一种期刊）为单位，按照一定次序编排的对文献信息进行描述和报道的工具，也称书目。目录对文献的描述比较简单，每条记录的字段主要包括：文献题名、责任者、出版事项、分类号、主题词等。一种出版物经过如此描述后形成一条记录，将所有的记录组织起来就形成了目录。

何为元数据库？

什么是元数据？

元数据（MetaDate），关于数据的数据或者叫做用来描述数据的数据或者叫做信息的信息。

这些定义都很是抽象，我们可以把元数据简单的理解成，最小的数据单位。元数据可以为数据说明其元素或属性（名称、大小、数据类型、等），或其结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。

举几个简单的例子：

使用过数码相机的同学都应该知道，每张数码照片都会存在一个EXIF信息。它就是一种用来描述数码的元数据。根据EXIF标准，这些元数据包括：ImageDescription(图像描述、来源指生成图像的工具)、Artist(作者)、Make(生产者)、Model(型号)、、等等。

生活中我们填写的《个人信息登记表》，包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等这些就是锁定kentzhu这个人的元数据。

通常情况下元数据可以分为以下三类：固有性元数据、管理性元数据、描述性元数据。

固有性元数据；与事物构成有关的元数据。

管理性元数据；与事物处理方式有关的元数据。

描述性元数据；与事物本质有关的元数据。

当然，并不是说所数据总能清晰的划分在以上3类中。比如：一张由kent拍摄的大小为20K的JPG格式的印着一只小狗的圣诞卡照片。

它的固有性元数据包括：20K、JPG；管理性元数据：kent拍摄、圣诞卡；描述性元数据：狗、小狗、圣诞、照片、圣诞节、

但是，圣诞卡则可以放在以上任何一个分类中。与事物构成有关（说明这个东东是什么）、与事物处理方式有关（说明这个东东的用途是什么）、与事物本质有关（可以直接用来描述这个东东）。

元数据之于信息架构的意义

元数据是一种很有效的方法，用以确保网站上各种形式的内容确实都能被查找到。比如我们常常为搜索很久之前看到的一张美女犯愁，而如果一个网站如果信息架构足够好，我们就能凭借我们回忆到的元数据（关于武藤兰的？2000年拍摄的？）清晰的找到。

元数据之于信息架构就像是房子的砖瓦，它可以根据需要摆放成不同的信息检索系统。元数据是所有组织系统的基础，从搜索到电子商务网站上的导航系统都强烈的依赖于元数据。

前面提到，元数据实际上是为产品的可查找性（Findability）服务的。而用户在查找信息的时候不会按照机器思维去找（不会输入该照片的ID），而是直接输入关于信息的描述性信息如：“小狗圣诞卡”。也就意味着在创建关于描述性元数据的时候要尽量的提取出任官关于这个对象所讲述的故事，这些才是人们能记住的和习惯搜索的细节。

我们会发现，机械生成的元数据常常是不靠谱的，如在UCH系统下发布日志的时候系统会自动根据标题进行机械分析生成的一些元数据。

而充分利用手工元数据（handcraftedmetadate）是提高可查找性的一个好方法。最常见的例子就是我们见到的Tag。Tag就是一种用户自创的元数据，其特点是无层次结构、自定义。比如这张Flickr照片下的手工元数据就为在Flickr上查找提供了更多的方便。

Mysql创建数据库时会在如下目录创建以数据库名为名的目录

show variables like "%datadir%";

数据文件日志也就在相应目录下了。

日志大小、看看这些参数是否能达到你的目的：

–log-bin=filename:记录二进制日志文件的位置,尽量指定路径名,如果不指定的话则保存在数据目录;

–log-bin-index=file:记录二进制日志文件索引的位置,保存了日志文件名;

–max_binlog_size:单个文件最大多少;

–binlog-do-db=db_name:哪个数据库使用,只有这个数据库使用;

–binlog-ignore-db=db_name:哪个数据库不使用,只有这个数据库不使用;

系统变量

log_bin:日志的位置;

binlog_cache_size:二进制日志缓存大小,是每一个连接进来的线程分配的大小,不是整个服务器的大小;

max_binlog_cache_size:最大缓存大小;

max_binlog_size:单个文件最大大小,超过此大小则再分配一个文件,但是一个事务必须在一个文件中,所以可能会稍大点;

binlog_cache_use:当前连接使用的binlog缓存的事务的数量,使用show status like ‘binlog_cache_use’查看(show status命令显示了所有连接到mysql服务器的状态值);

binlog_cache_disk_use:如果binlog_cache_use不够用,则在磁盘上缓存,应该尽量避免;

binlog_do_db:设置master-slave时使用;

binlog-ignore-db:设置哪个数据库不记录日志;

sync_binlog:缓存与硬盘的同步频率(commit多少下同步一次,0表示服务器自动控制);

以上就是关于深入分析Oracle数据库日志文件（2）全部的内容，包括:深入分析Oracle数据库日志文件（2）、什么是目录数据库、mysql创建数据库时如何指定数据文件与日志文件的位置和大小等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！