LogMiner在图书馆集成管理系统中的应用

2022-09-12

Oracle数据库因其卓越的性能被广泛地应用于企业级用户, 我馆使用“金盘图书馆集成管理系统 (GDLIS) ”时选择Linux平台下的Oracle 10g作为后台数据库, 在应用GDLIS过程中由于人为或计算机设备故障等原因, 可能会出现一些原因不明的数据异常[1,2,3], 比如:某读者还书时操作员发现此读者的借书证上并没有该书的借阅记录。一般出现此情况我们会认为是由于借书时漏扫该书扫码造成的, 但应注意到在GDLIS后台数据库出现安全性问题时, 数据库中借阅记录有可能被SQL语句直接删除, 而在前端应用程序GDLIS上很难查出痕迹。由此我们引申出的问题是, 如何在图书馆集成管理系统中发现非正常数据的更改, 解决这个问题对保护图书馆资源具有一定的意义。

在Oracle中对数据做异常更改行为可以在数据库层被追踪到, 因为用户对Oracle数据库所有的更改都被记录到日志文件中, LogMiner是分析这些日志的工具。本文以GDLIS为例, 演示如何使用LogMiner实现对图书馆数据更改行为的追踪以及对更改数据的恢复。

1 LogMiner简介

1.1 LogMiner的功能

LogMiner用于将日志中对象ID号和数据类型转变为对象名和外部格式, 如果不使用该工具, Oracle日志无法被读懂[4]。通过LogMiner分析数据库日志主要可以完成以下功能: (1) 精细逻辑恢复操作。通过执行得到的UNDO语句进行相应的事务级精确恢复。 (2) 优化和扩容计划。可通过分析日志文件中的数据得出数据的增长模式, 以此为依据进行优化扩容。 (3) 执行后续审计。通过LogMiner可以跟踪所有的DML、DDL及DCL操作, 能够得到这些操作的时间顺序和执行这些操作的用户信息等, 本文中的实例就是这个功能的一个应用。

1.2 LogMiner基本组成对象

(1) 源数据库 (Source Database) :被分析日志的所属数据库, 本文中的GDLIS数据库。

(2) 分析数据库 (Mining Database) :执行LogMiner操作要使用的数据库, 要求与源库处于相同的硬件平台, 版本不低于源数据库且具有相同字符集, 分析数据库和源数据库可以是同一数据库。

(3) LogMiner字典:将内部对象ID号和数据类型转换为可读的对象名和外部数据格式。

2 GDLIS数据库逻辑结构

为了解决本文前面所举例子中的问题需要理解数据库表结构, 在GDLIS中, 图书借阅信息分别由“流通库”和“流通日志库”表的数据来记录, 其部分字段如下。

[流通库]登录号, 读者条码, 图书条码, 外借时间, 应归还时间, 主键码, 续借次数……

[流通日志库]操作类型, 登录号, 读者条码, 图书条码, 处理时间, 操作员, 罚款金额…

在“流通库”中记录了读者条码与图书的登录号, 这两个字段把读者与其所借图书关联在一起, 还书时GDLIS系统会使用delete语句将相应的记录删除。在表“流通日志库”中同样包含了登录号与读者条码, 当读者借还书时GDLIS都是使用insert语句添加一条借书记录。由此可知, 若想在数据库级将“读者X借了图书Y”这样的事实除去, 需要同时用delete语句删除这两个表中

3使用LogMiner分析Linux平台下GDLIS后台数据库日志文件

在本文所举例中, 假设该读者还书与此书上次还回时间间隔为5日, 而本馆已保存了期间的归档日志。数据库使用Oracle10g且补充日志处于激活状态, 使用源数据库数据字典的方式进行日志分析。

3.1确定要分析的归档日志文件

首先要确定出要分析的归档日志。在SQLPlus中, 通过限定日期查询动态视图v$archived_logs, 取得要分析归档日志的位置及名称编号[5]:

S Q L>s e l e c tn a m ef r o m v$archived_logs

2 where next_time>to_date ('2009030915:39:00', 'yyyymmdd hh24:mi:ss')

3 and first_time

3.2建立日志分析列表

日志分析列表用于制定要分析的重做日志或归档日志。

SQL>execute dbms_logmnr.add_logfile (logfilename=>-

>'/oracle/arc/10_1_527600919.arc', options=>dbms_logmnr.new)

使用上面的语句逐一将需要分析的归档日志加入分析列表, 需要注意的是除第一个日志外, 添加其他的归档日志要使用dbms_logmnr.new选项。

3.3启动LogMiner

将日志文件增加到日志分析列表后, 启动LogMiner分析日志, 执行如下语句:

S Q L>e x e c u t ed b m s_l o g m n r.start_logmnr (-

>o p t i o n s=>d b m s_l o g m n r.dict_from_online_catalog) ;

dict_from_online_catalog选项表示使用源数据库数据字典方式分析日志。

3.4查看日志分析结果

假设本文举例中的那位读者还书的登录号为503265, 图书证号为11120080910。通过查询动态性能视图v$logmnr_contents取得日志分析结果, 先查询日志中记录的对“流通库”的操作, 使用如下语句:

SQL>select timestamp, session_info, sql_redo from v$logmnr_contents

2 where seg_name='流通库'and operation='DELETE'and

3dbms_logmnr.mine_value (undo_value, 'GDLIS.流通库.登录号') ='503265'

得到如下查询结果: (图1)

从SQL_REDO可以看出, 在给定的日志中, 找到一次对“登录号”为503265的图书借阅记录进行的删除操作。由S E S S I-ON_INFO可知此操作发生在图书馆的机器名为TSG/L05的终端机上。读者条码与假设不相符, 可以判断出这是该图书上一次正常归还的事务。

我们还需要查询“流通日志库”的分析结果, 在GDLIS中借还图书都是添加记录以保证能够显示一本图书的借阅历史, 所以若日志中出现了对该表的删除操作就很可能是异常更改行为。查询语句如下:

S Q L>s e l e c ts q l_r e d of r o m v$logmnr_contents where

2 seg_name='流通日志库'and operation='DELETE'and

3d b m s_l o g m n r.m i n e_v a l u e (undo_value, 'GDLIS.流通库.登录号') ='503265'

该语句在数据字典中查找对“流通日志库”所做的delete操作, 并且被删除记录的登录号限定为503265, 执行后SQLPLUS提示“未选定行”, 意思是没有符合条件的日志记录。

从以上两个查询结果可以得出结论:没有人在数据库级删除图书证号为11120080910的读者的借书记录, 读者借书的那本书确实被漏扫了条码。

4结语

LogMiner作为Oracle日志分析工具, 其功能十分强大, 在本文的例中利用它对本馆“金盘图书馆集成管理系统”数据库的归档日志做了一次审计, 使对于读者还书时系统显示未借该书的现象能够做出准确的解释, 排除了在数据库级直接删除数据的可能性。同时应该看出, 图书馆DBA应该定期对数据库日志文件进行分析核实, 这样有利于保证资源的安全性, 并可以了解一些图书馆管理系统运行中的细节。

摘要：许多图书馆管理系统使用Oracle作为后台数据库, 图书资源、借阅记录及上机费用等信息被存储其中。软件故障或数据库级非正常更改, 可能会造成数据异常或丢失从而为图书馆带来损失。LogMiner是Oracle日志分析工具, 以金盘图书馆集成管理系统为例, 提出一种通过LogMiner分析日志文件的方式, 来审计图书馆数据资源是否被异常更改的方法。

关键词：LogMiner,图书馆,Oracle,日志