Oracle数据库的物理（存储）结构
2008年03月19日星期三上午 00:06
数据结构在计算机中的表示（映像）称为数据的物理（存储）结构。它包括数据元素的表示和关系的表示。
物理结构，即Oracle数据库使用的操作系统文件结构。对于数据库物理结构文件，不同的oracle版本，不同的操作系统平台上有不同的存储目录结构。
数据库的物理结构文件按其作用可以分为三类：
数据文件
日志文件
控制文件
一、数据文件
数据文件用来存储数据库的数据，如表、索引等。读取数据时，系统首先从数据库文件中读取数据，并存储到SGA的数据缓冲区中。这是为了减少I/O，如果读取数据时，缓冲区中已经有要读取的数据，就不需要再从磁盘中读取了。存储数据时也是一样，事务提交时改变的数据先存储到内存缓冲区中，再由oracle后台进程DBWR决定如何将其写入到数据文件中。
1.查询数据文件的信息
一个数据文件只与一个数据库相联系。数据文件的大小是可以改变的。可以通过以下语句查询表空间的空间空闲量
sql>select * from dba_free_space
2.修改数据文件的大小
sql>alter database datafile "d:\...\df1.dbf" resize 800m
3.数据库文件的自动扩展特性。
二、重做日志文件
重做日志文件记录对数据库的所有修改信息。它是三类文件中最复杂的一类文件，也是保证数据库安全与数据库备份与恢复有直接关系的文件。
1.日志文件组与日志成员
在每一个Oracle数据库中，至少有两个重做日志文件组。每组有一个个或多个重做日志文件，即日志成员。同一组中的成员是镜像关系，它们存储的内容是一模一样的。Oracle在写日志时，以一个日志组为逻辑单位写入，只在将日志都写入日志组中的每个成员文件中后，写日志才完成。
2.日志工作原理
Oracle有多个日志文件组，当一个日志文件组中所有的成员所有的成员同时被写满数据时，系统自动转换到下一个日志文件组，这个转换过程称为日志切换。
当日志切换后，会给前一个日志组编一个号，用于归档日志的编号，这个编号称为日志序列号。此编号由1开始，每切换一次，序列号自动加1，最大值受参数MAXLOGHISTORY限制，该参数的最大值为65534。
当oracle把最后一个日志组写满了以后，自动转向第一个日志组，这时,再向第一个日志组写日志的时候，如果数据库运行在非归档模式下，这个日志组中的原有日志信息就会被覆盖。
使用以下语句查询日志文件信息：
sql>select * from v$log
相关字段说明如下：
GROUP#:日志文件组号
THREAD#:日志文件线程号，一般为1,双机容时为2
SEQUENCE#:日志序列号
BYTES:日志文件大小
MEMBERS:该组的日志成员个数
ARC:该组日志信息是否已经完成归档
STATUS:该组状态（CURRENT:表示当前正在使用的组；NACTIVE:表示非活动组；ACTIVE:表示归档未完成）
FIRST_CHANGE#:系统改变号ＳＣＮ，也叫检查点号
FIRST_TIME:系统改变时间
DBA可以使用下列命令进行强制日志切换
sql>alter system switch logfile
3.NOARCHIVELOG/ARCHIVELOG
NOARCHIVELOG是非归档模式，如果数据库运行在这种模式下，当日志切换时，新切换到的日志组中的日志信息会被覆盖。ARCHIVELOG:归档模式，如果数据库运行在这种模式下，日志会被归档存储，产生归档日志，且在未归档之前，日志不允许被覆盖写入。
要确认数据库的归档方式，可以查询数据字典v$database:
sql>select log_mode from v$database
要了解归档日志的信息，可以查询数据字典v$archived_log。
要将数据库改为归档模式：
a.alter database archivelog
b.设置初始化参数LOG_ARCHIVE_START=TRUE
c.设置归档文件目标存储路径 LOG_ARCHIVE_DEST=C:\ORA\ARCHIVE
d.设置归档文件命名格式参数 LOG_ARCHIVE_FORMAT="ORCK%T%S.ARC"。这个格式中的%S表示日志序列号，自动左边补零；%s表示日志序列号，自动左边不补零；%T表示日志线程号，左边补零；%t表示日志线程号不补零。
e.重新启动数据库
4.CKPT进程(检查点进程)
CKPT进程保证有修改过的数据库缓冲区中的数据都被写入到数据文件，日志文件、数据文件、数据库头和控制文件中都有写入检查点标记。数据库在恢复时，只需提供自上一个检查以来所做的修改。检查点完成时系统将更新数据库数据库头和控制文件。
参数LOG_CHECKPOINT_TIMEOUT决定一个检查点发生的时间间隔。
LOG_CHECKPOINT_INTERVAL决定一个检查需要填充的日志文件块的数量。检查点号，也称系统改变号(SCN)，它标识一个检查点。可以通过v$log查询日志文件的检查点信息，通过v$datafile查询数据文件的检查点信息，通过v$database查询数据库头的检查点信息。三个地方的检查点号相同，如果不同，说明发明数据库不同步，此时数据库肯定无法正常启动。
5.增加与删除日志文件组、日志成员(详细语法请参考Oracle文档)
6.清除日志文件数据
三、控制文件
控制文件是一个二进制文件，用来描述数据库的物理结构，一个数据库只需要一个控制文件，控制文件的内容包括：
数据库名及数据库唯一标识
数据文件和日志文件标识
数据库恢复所需的同步信息，即检查点号
控制文件由参数control_files指定，格式如下：
control_files=("home/app/.../control01.ctl","home/app/.../control02.ctl ")
参数中各个文件是镜像关系，也就是说，几个文件中只要有一个文件完好，数据库就可以正常运行。
如果控制文件损坏或丢失，数据库将终止并且无法启动，所以，要对控制文件进行镜象，手工镜像步骤如下：
a.关闭数据库
b.复制控制文件
c.修改参数文件，加入新增的控制文件位置描述
d.重新启动数据库
另外注意，控制文件中还包含几个服务器参数的设置，如果修改这些参数的值，刚需要重新创建控制文件，这些参数是：
MAXLOGFILES:最大日志文件个数
MAXLOGMEMBERS:最大日志成员个数
MAXLOGHISTORY:最大历史日志个数
MAXDATAFILES:最大数据文件个数
MAXINSTANCES:最大实例文件个数
所有修改数据库结构的命令都会引起控制文件的改变。同时出会记录在oracle跟踪文件中，跟踪文件的名称为alter_SID.log，路径如下：
d:\oracle\product\10.1.0\admin\DB_NAME\bdump\SIDALRT.log(Unix是
alter_SID.ora)
也可以在参数文件中指定跟踪文件的存储路径，后台进程跟踪文件目录由参数background_dump_dest指定，用户跟踪文件位置由参数user_bdump_dest指定.
Oracle数据库的物理存储结构之数据文件
2009-11-16 21:43
Oracle数据库主要的物理存储结构包含构成数据库的各种物理文件，包括数据文件，控制文件，重演日志文件，归档重演日志文件，参数文件，警告、跟踪日志文件和备份文件等。
启动一个实例时，Oracle从参数文件中读取控制文件的名字和位置，登陆数据库时，Oracle打开控制文件，控制文件把Oracle引导到数据库文件的其余部分，最终打开数据库时，Oracle从控制文件中读取数据库文件和日志文件的列表并打开其中的每一个文件。
数据文件（Datafile）
每个Oracle数据库都有一个或多个物理数据文件，数据文件包含了所有的数据库数据，数据库的逻辑结构的数据（如表、索引等）都被物理的存储在分给数据库的数据文件中，数据文件包含下列类型的数据：
a.表数据
b.索引数据
c.数据字典定义
d.回滚事务所需的信息
e.存储过程、函数和数据包的代码
f.用来排序的临时数据
一般来说，这些不同类型的数据不混到一起存储，而是同一类型的数据集中到一个或多个文件中存储。
数据文件具有以下特点：
a.一个数据文件只能与一个数据库相关联。
b.可以对数据文件设置一些特性，在数据库空间用完的情况下自动进行扩展。
c.一个或多个数据文件够撑了一个数据库存储的逻辑单元---表空间（tablespace）。
当一个数据文件第一次被创建后，分配的控件就进行了格式化，但不含任何用户数据。Oracle独占的使用数据文件空间来保存数据。随着一个表空间的数据增长，Oracle使用与这个表空间相关联的数据文件的剩余空间。
一个表控件内的模式对象（schema object）的数据物理上可以存储在构成表空间的一个货这多个数据文件上。
注意：一个模式对象并不一定只对应于一个特定的数据文件，一个数据文件可以存储一个特定表空间内的任何模式对象，而一个模式对象也可以存储在其所在表空间的一个活这数据文件中，所以一个模式对象可以跨越一个或多个数据文件。
在正常的数据库操作过程中，一个数据文件中的数据按照需要被读取，存储在Oracle的内存缓存区中，例如：假定一个用户想访问一个数据库的一个表中的某些数据，如果这个数据库的内存缓冲区没有这些数据，那么数据库就会到相应的数据文件中去读取这些信息，然后存储在内存里。
修改过的数据或者新添加的数据不一定立刻写入一个数据文件，为了减少磁盘访问数量，提高性能，数据汇集在内存里，然后一次性全部写入到适当的数据文件中。这个过程是由数据库后台数据库书写进程（DBWR）决定的。
在SQL*Plus中查询一个数据库的所有数据文件的列表：
SELECT status，bytes，name
FROM V$DATAFILE；
Oracle数据库的物理存储结构之控制文件
2009-11-23 22:51
数据库控制文件（control file）是一个很小的二进制文件，它维护者数据库的全局物理结构，用以支持数据库成功的启动和运行。创建数据库时，同时就提供了与之对应的控制文件。在数据库使用过程中，Oracle不断的更新控制文件，所以只要数据库是打开的，控制文件就必须处于可写状态。如果，犹豫某些原因控制文件不能被访问，那么数据库也就不能正常的工作了。
每一个控制文件只能与一个Oracle数据库相关联。
控制文件包含了数据库实例的启动和正常操作时，访问数据库所需的关于数据库的信息。控制文件的内容只有Oralce可以修改，数据库管理员和用户都不能对其进行编辑。
控制文件包含了以下信息：
数据库名称
数据库创建的时间戳
相关的数据文件、重演日志文件的名称和位置
表空间信息
数据文件脱机范围
日志历史
归档日志信息
备份组和备份块信息
备份数据文件和重演日志信息
数据文件拷贝信息
当前日志序列数
检查点（checkpoint）信息
数据库名称和时间戳源自数据库创建之时，数据库名称或是来自DB_NAME初始化从参数，或者来自Cteate Database语句使用的名称。
每当数据文件或重演日志文件被添加内容、重新命名或者直接从数据库删除时，
控制文件都要进行更新以反应物理结构的变化。记录下这些变化后，Oracle就可以：
在数据库启动的时候，能够确定并打开数据文件和重演日子文件。
在必须要恢复数据库的时候，能够确定哪些文件是必须的、哪些文件是可用的。
PS：如果数据库的物理结构发生了改变（使用了Alert Database语句），用户应该立刻备份控制文件。
控制文件还记录了关于检查点的信息。每3秒，检查点进程（CKPT）就会在控制文件里记录重演日志文件的检查点位置信息。这些信息用于数据库的恢复过程，告诉数据库在这一点之前的已经记录下的重演条目不必进行恢复，因为它们已经被写入数据文件了。
由于控制文件对数据库的至关重要，所以联机存储着多个副本。这些文件一般存储在各个不同的磁盘上，以便将因磁盘试下哦引起的潜在危险降至最低程度。Oracle支持对同一个数据库并发的打开、书写多个相同的控制文件。通过为一个数据库在不同的磁盘上保存多个控制文件，可以幼小的降低对于控制文件可能发生的单点失败。例如，包含一个控制文件的磁盘崩溃了，如果Oracle试图访问这个被破坏的文件，当前实例就会失败，但是如果在不同的磁盘上保存了当前控制文件的复件，就可以重启一个实例而无需进行数据库恢复。
如果一个数据库所有的控制文件在操作的时候都丢失了，那么数据库实例就会失败，必须要进行介质恢复（media recover）。但是介质恢复必须要使用一个稍微旧一点的控制文件的备份，因为当前的控制文件备份不可用。所以为了保护控制文件，必须要注意一下几个方面：
每一个数据库都要使用多路复制的控制文件；
把每一个控制文件的复件保存在不同的物理磁盘上；
使用操作系统的镜像机制；
监控备份；
在SQL*PLUS中查询控制文件
select name from V$control_file；
Oracle数据库的物理结构——构成文件
2007-04-20 10:50
Oracle数据库由以下驻留在磁盘上的文件构成：控制文件(Control files)、数据文件(Datafiles)和重做日志文件(Redo logs)，与数据关联但不是数据构成部分的文件有：password file(口令文件)、Archived Log、Oracle Net等。
一、控制文件(Control Files):控制文件是数据中非常关键的组件，它存储
了数据库中非常重要的信息：
·数据库的名字
·数据文件和重做日志文件的名字、位置和大小、当前日志序列号，备份细节，所有重要的系统改变号(system change number)。
·出现错误时，恢复数据使用的信息
控制文件是创建数据库时，通过参数文件中的control_files参数来进行设置、建立的。控制文件的丢失会影响到数据库的恢复能力，因此，Oracle
使用CKPT后台进程自动地更新控制文件，保持它们内容的同步。可以查看动态性能视图v$controlfile查看数据库中控制文件的位置和名字。
如下图：
以上查询显示了数据库中三个控制文件及其位置。控制文件的后缀是ctl。控制文件通常非常小，一般在1M在5M之间，可以修改参数文件中的参数：controlfile_record_keep_time让控制文件更大些。
控制文件在Oracle数据库管理系统中管理数据库的状态，是Oracle数据库中重为重要的一个文件，只有Oracle能向控制文件中写入信息，只有Oracle 服务器进程在数据库操作时能刷新控制文件。
一个数据库实例启动时，先找控制文件，然后由控制文件找到数据文件和日志文件，加载数据库和打开数据库。
二、数据文件(Datafiles)
数据文件是存储在磁盘上的插入到表中的数据。这些数据文件与数据库中表的数据相关。查询视图v$datafile,如下图：
通过查询视图v$datafile可以看到数据库中的数据文件。它们是以
dbf(Database file)为后缀。
三、重做日志文件(Redo Log Files) 用来恢复数据用，记录数据库的改变。可以分为两类日志文件：在线重做日志文件(online redo log files):记录数据库当前的改变，如当前的数据库有三个redo log文件，在数据库运行，先写入第一个文件，如果写满了，再写第二个，到第三个也写满了，就再回头写入到第一个日志文件，把原来的数据覆盖掉。归档日志文件(archived redo logs)：把前面的日志文件另存储起来，就变成了归档日志文件。
查询视图v$logfile，如下图：
当出现以下事件时，LGWR后台进程写入到当前日志文件组：
·每三秒钟
·一个用户确定一个事务
·重做日志缓存使用三分之一
·重做日志缓存有1MB的重做信息
·任何时候数据库检查点发生时，DBWN进行程写入数据。
四、服务器参数文件
参数文件对于Oracle数据库非常重要，当数据库实例启动时，先找到参数文件，根据参数文件内的初始化参数来初始化实例，如找到数据文件和控制文件等。Oracle允许DBA在数据库实例启动后修改参数的值，这些可以在启动被修改的值称为动态初始化参数(dynamic initialization parameters)。
SPFILE(server parameters file)可以自动动态地记录动态参数的值。通过查看视图v$parameter查询初始化参数的值。
五、口令文件(Then Password File)
口令文件是可选的，不是必需的。
六、告警日志文件
每一个Oracle数据库有一个告警文件，名字为alterdb_name.log(db_name 是数据库的名字），这个日志文件存放位置由参数文件中的参数BACKGROUND_DUMP_DEST的值确定，如果没有设置这个参数，Oracle把它放置在默认的位置：$oracle_home/rdbms/log
七、跟踪文件(Trace Files)
Oracle需要DBA在初始化参数中建立三个不同的跟踪文件目录参数：backgroud dump directory(参数：BACKGROUND_DUMP_DEST)、core dump directory(CORE_DUMP_DEST)、user dump directory(参数：USER_DUMP_DEST)。深入分析Oracle数据库日志文件（1）
【12/24/2004 11:33:25】【程永新】【赛迪网】
作为Oracle DBA，我们有时
候需要追踪数据误删除或用户的恶意操作情况，此时我们不仅需要查出执行这些操作的数据库账号，还需要知道操作是由哪台客户端（IP地址等）发出的。针对这些问题，一个最有效实用而又低成本的方法就是分析Oracle数据库的日志文件。本文将就Oracle日志分析技术做深入探讨。
一、如何分析即LogMiner解释
从目前来看，分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner 来进行， Oracle数据库的所有更改都记录在日志中，但是原始的日志信息我们根本无法看懂，而LogMiner就是让我们看懂日志信息的工具。从这一点上看，它和tkprof差不多，一个是用来分析日志信息，一个则是格式化跟踪文件。通过对日志的分析我们可以实现下面的目的：
1、查明数据库的逻辑更改；
2、侦察并更正用户的误操作；
3、执行事后审计；
4、执行变化分析。
不仅如此，日志中记录的信息还包括：数据库的更改历史、更改类型（INSERT、UPDATE、DELETE、DDL等）、更改对应的SCN号、以及执行这些操作的用户信息等，LogMiner在分析日志时，将重构等价的SQL语句和UNDO语句（分别记录在V$LOGMNR_CONTENTS视图的SQL_REDO和SQL_UNDO中）。这里需要注意的是等价语句，而并非原始SQL语句，例如：我们最初执行的是“delete a where c1 <>'cyx';”，而LogMiner重构的是等价的6条DELETE语句。所以我们应该意识到V$LOGMNR_CONTENTS视图中显示的并非是原版的现实，从数据库角度来讲这是很容易理解的，它记录的是元操作，因为同样是“delete a where c1 <>'cyx';”语句，在不同的环境中，实际删除的记录数可能各不相同，因此记录这样的语句实际上并没有什么实际意义，LogMiner重构的是在实际情况下转化成元操作的多个单条语句。
另外由于Oracle重做日志中记录的并非原始的对象（如表以及其中的列）名称，而只是它们在Oracle数据库中的内部编号（对于表来说是它们在数据库中的对象ID，而对于表中的列来说，对应的则是该列在表中的排列序号：COL 1, COL 2 等），因此为了使LogMiner重构出的SQL语句易于识别，我们需要将这些编号
转化成相应的名称，这就需要用到数据字典（也就说LogMiner本身是可以不用数据字典的，详见下面的分析过程），LogMiner利用DBMS_LOGMNR_D.BUILD()过程来提取数据字典信息。
LogMiner包含两个PL/SQL包和几个视图：
1、dbms_logmnr_d包，这个包只包括一个用于提取数据字典信息的过程，即dbms_logmnr_d.build()过程。
2、dbms_logmnr包，它有三个过程：
add_logfile(name varchar2, options number) - 用来添加/删除用于分析的日志文件；
start_logmnr(start_scn number, end_scn number, start_time
number,end_time number, dictfilename varchar2, options number) - 用来开启日志分析，同时确定分析的时间/SCN窗口以及确认是否使用提取出来的数据字典信息。
end_logmnr() - 用来终止分析会话，它将回收LogMiner所占用的内存。
与LogMiner相关的数据字典。
1、v$logmnr_dictionary，LogMiner可能使用的数据字典信息，因logmnr可以有多个字典文件，该视图用于显示这方面信息。
2、v$logmnr_parameters，当前LogMiner所设定的参数信息。
3、v$logmnr_logs，当前用于分析的日志列表。
4、v$logmnr_contents，日志分析结果。
二、Oracle9i LogMiner的增强：
1、支持更多数据/存储类型：链接/迁移行、CLUSTER表操作、DIRECT PATH插入以及DDL操作。在V$LOGMNR_CONTENTS的SQL_REDO中可以看到DDL操作的原句（CREATE USER除外，其中的密码将以加密的形式出现，而不是原始密码）。如果TX_AUDITING初始化参数设为TRUE，则所有操作的数据库账号将被记录。
2、提取和使用数据字典的选项：现在数据字典不仅可以提取到一个外部文件中，还可以直接提取到重做日志流中，它在日志流中提供了操作当时的数据字典快照，这样就可以实现离线分析。
3、允许对DML操作按事务进行分组：可以在START_LOGMNR()中设置
COMMITTED_DATA_ONLY选项，实现对DML操作的分组，这样将按SCN的顺序返回已经提交的事务。
4、支持SCHEMA的变化：在数据库打开的状态下，如果使用了LogMiner的
DDL_DICT_TRACKING选项，Oracle9i的LogMiner将自动对比最初的日志流和当前系统的数据字典，并返回正确的DDL语句，并且会自动侦察并标记当前数据字典和最初日志流之间的差别，这样即使最初日志流中所涉及的表已经被更改或者根本已经不存在，LogMiner同样会返回正确的DDL语句。
5、在日志中记录更多列信息的能力：例如对于UPDATE操作不仅会记录被更新行的情况，还可以捕捉更多前影信息。
6、支持基于数值的查询：Oracle9i LogMiner在支持原有基于元数据（操作、对象等）查询的基础上，开始支持基于实际涉及到的数据的查询。例如涉及一个工资表，现在我们可以很容易地查出员工工资由1000变成2000的原始更新语句，而在之前我们只能选出所有的更新语句。
三、Oracle8i/9i的日志分析过程
LogMiner只要在实例起来的情况下都可以运行，LogMiner使用一个字典文件来实现Oracle内部对象名称的转换，如果没有这个字典文件，则直接显示内部对象编号，例如我们执行下面的语句：
如果想要使用字典文件，数据库至少应该出于MOUNT状态。然后执行
dbms_logmnr_d.build过程将数据字典信息提取到一个外部文件中。下面是具体分析步骤：
1、确认设置了初始化参数：UTL_FILE_DIR，并确认Oracle对改目录拥有读写权限，然后启动实例。示例中UTL_FILE_DIR参数如下：
这个目录主要用于存放dbms_logmnr_d.build过程所产生的字典信息文件，如果不用这个，则可以不设，也就跳过下面一步。
2、生成字典信息文件：
其中dictionary_location指的是字典信息文件的存放位置,它必须完全匹配UTL_FILE_DIR的值，例如：假设UTL_FILE_DIR=/data6/cyx/logmnr/，则上面这条语句会出错，只因为UTL_FILE_DIR后面多了一个“/”，而在很多其它地方对这一“/”是不敏感的。
dictionary_filename指的是放于字典信息文件的名字，可以任意取。当然我们也可以不明确写出这两个选项，即写成：
如果你第一步的参数没有设，而直接开始这一步，Oracle会报下面的错误：
需要注意的是，在oracle817 for Windows版中会出现以下错误：
解决办法：
保存文件，然后执行一遍这个脚本：
然后重新编译DBMS_LOGMNR_D包：
3、添加需要分析的日志文件
这里的options选项有三个参数可以用：
NEW - 表示创建一个新的日志文件列表
ADDFILE - 表示向这个列表中添加日志文件，如下面的例子REMOVEFILE - 和addfile相反。
4、当你添加了需要分析的日志文件后，我们就可以让LogMiner开始分析了：
如果你没有使用字典信息文件（此时我们只需要启动实例就可以了），那么就不需要跟dictfilename参数：
当然dbms_logmnr.start_logmnr()过程还有其它几个用于定义分析日志时间
/SCN窗口的参数，它们分别是：
STARTSCN / ENDSCN - 定义分析的起始/结束SCN号，
STARTTIME / ENDTIME - 定义分析的起始/结束时间。
例如下面的过程将只分析从 '2003-09-21 09:39:00'到'2003-09-21 09:45:00'这段时间的日志：
上面过程第一行结尾的“-”表示转行，如果你在同一行，则不需要。我们可以
看到有效日志的时间戳：
这里需要注意的是，因为我之前已经设置NLS_DATE_FORMAT环境变量，所以上面的日期可以直接按这个格式写就行了，如果你没有设，则需要使用to_date函数来转换一下。
STARTSCN 和ENDSCN参数使用方法类似。
5、好了，在上面的过程执行结束之后，我们就可以通过访问与LogMiner相关的几个视图来提取我们需要的信息了。其中在v$logmnr_logs中可以看到我们当前分析的日志列表，如果数据库有两个实例（即OPS/RAC），在v$logmnr_logs中会有两个不同的THREAD_ID。
而真正的分析结果是放在v$logmnr_contents中，这里面有很多信息，我们可以根据需要追踪我们感兴趣的信息。后面我将单独列出来讲常见的追踪情形。
6、全部结束之后，我们可以执行dbms_logmnr.end_logmnr过程退出LogMiner 分析过程，你也可以直接退出SQL*PLUS，它会自动终止。
四、如何利用LogMiner分析Oracle8的日志文件
虽然说LogMiner是Oracle8i才推出来，但我们同样可以用它来分析Oracle8的日志文件，只不过稍微麻烦了一点，并且有一定的限制，下面是具体做法：
我们首先复制Oracle8i的$ORACLE_HOME/rdbms/admin/dbmslmd.sql脚本到Oracle8数据库所在主机的同样目录；这个脚本用于创建dbms_logmnr_d包（注意，Oracle9i中还将创建dbms_logmnr包），如果是8.1.5脚本名字为dbmslogmnrd.sql。然后在Oracle8的数据库上运行这个脚本，之后使用
dbms_logmnr_d.build过程创建字典信息文件。现在我们就可以把Oracle8的归档日志连同这个字典信息文件复制到Oracle8i数据库所在的主机上，之后在Oracle8i数据库中从上面分析过程的第三步开始分析Oracle8的日志，不过
dbms_logmnr.start_logmnr()中使用的是Oracle8的字典信息文件。
按照我前面所说的那样，如果不是字典文件，我们则可以直接将Oracle8的归档日志复制到Oracle8i数据库所在主机，然后对它进行分析。
其实这里涉及到了一个跨平台使用LogMiner的问题，笔者做过试验，也可以在Oracle9i中来分析Oracle8i 的日志。但这些都是有所限制的，主要表现在：
1、LogMiner所使用的字典文件必须和所分析的日志文件是同一个数据库所产生的，并且该数据库的字符集应和执行LogMiner数据库的相同。这很好理解，如果不是同一个数据库所产生就不存在对应关系了。
2、生成日志的数据库硬件平台和执行LogMiner数据库的硬件平台要求一致，操作系统版本可以不一致。笔者做试验时（如果读者有兴趣可以到我网站https://www.doczj.com/doc/d04771756.html,上下载试验全过程，因为太长就不放在这里了），所用的两个数据库操作系统都是Tru64 UNIX，但一个是V5.1A，另一个则是V4.0F。如果操作系统不一致则会出现下面的错误：
五、分析v$logmnr_contents
前面我们已经知道了LogMiner的分析结果是放在v$logmnr_contents中，这里面有很多信息，我们可以根据需要追踪我们感兴趣的信息。那么我们通常感兴趣的有哪些呢？
1、追踪数据库结构变化情况，即DDL操作，如前所述，这个只有Oracle9i才支持：
2、追踪用户误操作或恶意操作：
例如我们现实中有这样需求，有一次我们发现一位员工通过程序修改了业务数据库信息，把部分电话的收费类型改成免费了，现在就要求我们从数据库中查出到底是谁干的这件事？怎么查？LogMiner提供了我们分析日志文件的手段，其中v$logmnr_contents的SESSION_INFO列包含了下面的信息：
虽然其中信息已经很多了，但在我们的业务数据库中，程序是通过相同的login_username登录数据库的，这样单从上面的信息是很难判断的。
不过我们注意到，因为公司应用服务器不是每个人都有权限在上面写程序的，一般恶意程序都是直接通过他自己的PC连到数据库的，这就需要一个准确的定位。IP追踪是我们首先想到的，并且也满足我们的实际要求，因为公司内部IP地址分配是统一管理的，能追踪到IP地址我们就可以准确定位了。但从面的SESSION_INFO中我们并不能直接看到IP，不过我们还是有办法的，因为这个SESSION_INFO里面的内容其实是日志从V$SESSION视图里提取的，我们可以在生产数据库中创建一个追踪客户端IP地址的触发器：
现在，我们就可以在V$SESSION视图的CLIENT_INFO列中看到新登录的客户端IP地址了。那么上面的提出的问题就可以迎刃而解了。假如被更新的表名为HMLX，我们就可以通过下面的SQL来找到所需信息：
好了，到此为止，这篇文章就要结束了，如果读者朋友还有什么疑问，可以登录我的个人网站（https://www.doczj.com/doc/d04771756.html,）来获得最新消息，也可以通过MSN（gototop_ncn@https://www.doczj.com/doc/d04771756.html,）直接和我联系。
六、参考资料：
1、Technical White Paper Oracle9i LogMiner
2、Metalink文档：How to Setup LogMiner（文档ID：111886.1）