是的,数据库可以查看日志。数据库会记录所有对其进行的 *** 作和事件,这些记录被称为“日志”。数据库日志可以用于多种用途,例如:
恢复:如果数据库崩溃或发生其他问题,可以使用日志来还原数据库到崩溃前的状态。
故障排除:日志可以帮助确定发生故障的原因。如果数据库中的某些 *** 作失败了,可以查看日志以了解是哪个 *** 作出了问题。
安全审计:日志可以记录数据库中的所有活动,包括登录尝试、查询和更新 *** 作等。这些记录可以用于安全审计和法律合规性。
在大多数数据库系统中,可以使用特定的命令或工具来查看日志文件。例如,在MySQL中,可以使用“SHOW BINARY LOGS”命令来查看二进制日志文件。
Oracle 数据库的所有更改都记录在日志中,从目前来看,分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner来进行,因为原始的日志信息我们根本无法看懂,Oracle8i后续版本中自带了LogMiner
而LogMiner就是让我们看懂日志信息的工具,通过这个工具可以:
查明数据库的逻辑更改,侦察并更正用户的误 *** 作,执行事后审计,执行变化分析。
1、日志分析:就是通过分析数据库系统中业务数据的交易、 *** 作日志,来发现违规的风险;通过分析数据库系统自身的各种日志,然后提前发现黑客攻击、系统故障等数据库风险。
2、风险分析:风险分析是使用的比较广泛的一种分析方法,它同时涵盖了日志分析方法。它主要就是依据一套风险分析理论,来对数据库的管理、技术等方面进行比较全面的分析,看它们存在的风险有哪些,并针对这些风险进行审计。
3、数据核对:数据核对也可以称之为数据验证,主要是针对数据风险而言的,采用的方法也比较多,如重新计算、倒推法、比对法、程序分析、重新执行等,这些方法在使用起来可能会比较耗时、耗力。但是这些方法缺失非常有价值的,因为数据库最终是为数据服务的,数据不准、有问题只有两种情况下才能知道,验算之后或者使用过程中。
4、数据流分析:就是利用数据的生命周期,从数据的需求来分析、审批、更新、权限分配、流转等,分析数据存在的风险,验证数据控制措施的有效。
5、测试:首先设置一个关键的测试点,然后来验证数据库对数据的管理过程是否有效。有效性测试、穿行测试、实质性测试等是常见的测试方法。
环境:
AIX61
Oracle 11g RAC
故障:
数据库频繁出现归档日志空间不够,导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁, *** 作系统空间不够。
确定原因:
[aix01@oracle]/oracle>df -g
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 050 028 44% 13674 17% /
/dev/hd2 300 067 78% 49208 23% /usr
/dev/hd9var 100 037 63% 9285 10% /var
/dev/hd3 200 103 49% 2407 1% /tmp
/dev/fwdump 100 099 2% 30 1% /var/adm/ras/platform
/dev/hd1 025 018 28% 465 2% /home
/dev/hd11admin 025 025 1% 5 1% /admin
/proc - - - - - /proc
/dev/hd10opt 050 028 44% 10241 14% /opt
/dev/livedump 025 025 1% 12 1% /var/adm/ras/livedump
/dev/oraclelv 3000 1129 63% 161681 6% /oracle
/dev/installlv 1500 338 78% 6478 1% /install
/dev/crslv 1000 335 67% 7807 1% /crs
/dev/wmsapplv 3000 1749 42% 15537 1% /wmprod
/dev/archivelv 2925 2925 1% 4 1% /arch1
/dev/backuplv 40000 10713 74% 306 1% /sysbackup
aix02:arch2 3025 064 99% 3 1% /arch2
可以看到,/arch2里文件系统空间已经达到99%,/arch2是用来存放归档日志的文件系统,进而导致数据库出错。
提出问题:
这下问题来了,/arch2的空间是30G,每天备份脚本都会自动rman备份归档日志,并自动清除归档日志文件,按照正常情况下,数据库不可能一天产生这么大的归档日志量。
如何查询归档日志都是由什么应用产生的,这就是logminer的用途。
使用方法:
-- 1指定要分析的日志文件
exec sysdbms_logmnradd_logfile(logfilename => '/arch2/2_825_733092736dbf',options => dbms_logmnrnew);
-- 2使用本地的在线数据字典分析归档日志
exec sysdbms_logmnrstart_logmnr(options => sysdbms_logmnrdict_from_online_catalog);
-- 3查询分析出来的归档日志内容,例如统计最大修改量的Schema
select seg_owner,count() from v$logmnr_contents group by seg_owner;
-- 4增加别的日志文件
exec sysdbms_logmnradd_logfile(logfilename=>'/arch2/2_825_733092736dbf');
-- 5结束分析归档日志
exec sysdbms_logmnrend_logmnr;
下面是具体的过程:
SQL> exec sysdbms_logmnradd_logfile(logfilename => '/arch2/2_825_733092736dbf',options => dbms_logmnrnew);
PL/SQL procedure successfully completed
SQL> exec sysdbms_logmnrstart_logmnr(options => sysdbms_logmnrdict_from_online_catalog);
PL/SQL procedure successfully completed
SQL> select seg_owner,count() from v$logmnr_contents group by seg_owner;
SEG_OWNER COUNT()
-------------------------------- ----------
2237
SYS 688
TMS 60
SPHSY 70
SINOSYNEW 30
SINOSY 381
WAS 4551934
7 rows selected
SQL> execute dbms_logmnrend_logmnr ;
PL/SQL procedure successfully completed
结论:
从上面查询结果可以看出 *** 作量最大的用户是WAS用户,再具体看下v$logmnr_contents可以发现基本修改的内容是一致的。
与开发人员沟通后,最终确认是一个执行update过程存在问题,where条件未正确定位到记录,每执行一次都会导致大规模的修改数据。
以上就是关于数据库能查看日志吗全部的内容,包括:数据库能查看日志吗、oracle里怎么对sql查询的日志进行查看、哪些审计方法适合用审计软件实现等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)