新网创想网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
oracle日志查看
创新互联专注为客户提供全方位的互联网综合服务,包含不限于网站设计制作、成都网站建设、方山网络推广、微信小程序开发、方山网络营销、方山企业策划、方山品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等,从售前售中售后,我们都将竭诚为您服务,您的肯定,是我们最大的嘉奖;创新互联为所有大学生创业者提供方山建站搭建服务,24小时服务热线:18982081108,官方网址:www.cdcxhl.com
一.oracle日志的路径:
登录:sqlplus
"/as
sysdba"
查看路径:sql
select
*
from
v$logfile;
sql
select
*
from
v$logfile;(#日志文件路径)
二.oracle日志文件包含哪些内容:(日志的数量可能略有不同)
control01.ctl
example01.dbf
redo02.log
sysaux01.dbf
undotbs01.dbf
control02.ctl
redo03.log
system01.dbf
users01.dbf
control03.ctl
redo01.log
shttest.dbf
temp01.dbf
三.oracle日志的查看方法:
sqlselect
*
from
v$sql
(#查看最近所作的操作)
sqlselect
*
fromv
$sqlarea(#查看最近所作的操作)
oracle
数据库的所有更改都记录在日志中,从目前来看,分析oracle日志的唯一方法就是使用oracle公司提供的logminer来进行,因为原始的日志信息我们根本无法看懂,oracle8i后续版本中自带了logminer,而logminer就是让我们看懂日志信息的工具,通过这个工具可以:查明数据库的逻辑更改,侦察并更正用户的误操作,执行事后审计,执行变化分析。
logminer作为相关的日志分析工具集成与oracle中,我们可通过该工具清楚的分析重做相关日志和归档日志中的所有事物变化,并且可以准确的确定各种DML和DDL操作的具体时间和SCN值。
通过logminer我们可以实现:
1,确定数据的逻辑损坏的时间
2,跟踪用户执行的事务变化操作
3,跟踪表的DML操作
如果我们要分析归档日志,我们首先修改oracle归档日志的模式,我们要把默认的归档路径改成我们自己的路径:
start mount;
alter database archivelog;
alter database open;
alter system set log_archive_dest_1='location=d:\oracle' scope=spfile;
alter system set log_archive_format='arch_%t_%s_%r.trc' scope=spfile;
查看我们修改过的归档路径:
archive log list;
查看归档日志:
select name,dest_id from v$archived_log;
如果查询的没有更改,我们需要重启一下数据库
安装logminer,安装logminer需要我们安装下面的几个包:
$ORACLE_HOME/rdbms/admin/dbmslm.sql
$ORACLE_HOME/rdbms/admin/dbmslmd.sql
$ORACLE_HOME/rdbms/admin/dbmslms.sql
这几个脚本必须是sys用户运行
@$ORACLE_HOME/rdbms/admin/dbmslm.sql
@$ORACLE_HOME/rdbms/admin/dbmslmd.sql
@$ORACLE_HOME/rdbms/admin/dbmslms.sql
添加数据字典,需要添加参数utl_file_dir,
alter system set utl_file_dir='/home/oracle/dir' scope=spfile;
添加supplement logging
首先查看
select name,supplemental_log_data_min from v$database;是否是yes
YES为打开状态,会记录session_info,username等信息
NO为关闭状态,不会记录sesion_info,username等信息
添加
alter database add supplemental log data;
关闭
alter database drop supplemental log data;
重启数据库,这样我们刚才的两个参数就会生效;
查看数据字典:
show parameter utl;
添加数据字典:
SQL begin
2 dbms_logmnr_d.build(
3 dictionary_filename='logminer_dict.dat',
4 dictionary_location='/home/oracle/logminer');
5 end;
6 /
PL/SQL procedure successfully completed.
或是:
execute dbms_logmnr_d.build(dictionary_filename='logminer_dict.dat',dictionary_location='/home/oracle/logminer');
创建登录触发器:
SQL create or replace trigger on_logon_tigger
2 after logon on database
3 begin
4 dbms_application_info.set_client_info(sys_context('userenv','ip_address'));
5 end;
6 /
Trigger created.
我们就可以在V$SESSION视图的CLIENT_INFO列中看到新登录的客户端IP地址了。那么现在就可以在
添加要分析的归档日志文件
SQL begin
2 dbms_logmnr.add_logfile(
3 logfilename='/home/oracle/arch/arch_6_758944049_1.trc',options=dbms_logmnr.new);
4 end;
5 /
PL/SQL procedure successfully completed.
SQL begin
2 dbms_logmnr.add_logfile(
3 logfilename='/home/oracle/arch/arch_7_758944049_1.trc',
4 options=dbms_logmnr.addfile);
5 end;
6 /
PL/SQL procedure successfully completed.
切换归档日志:
alter system switch logfile;
开启分析:
execute dmbs_logmnr.start_logmnr(dictfilename='/home/oracle/logminer/logminer_dict.dat');
或是:
execute dbms_logmnr.start_logmnr;
查询归档日志:
SQL select name from v$archived_log;
NAME
--------------------------------------------------------------------------------
/home/oracle/arch/arch_6_758944049_1.trc
/home/oracle/arch/arch_7_758944049_1.trc
/home/oracle/arch/arch_8_758944049_1.trc
为了节约pga的空间,当我们分析完日志后,移除不需要的日志:
SQL begin
2 dbms_logmnr.add_logfile(
3 logfilename='/home/oracle/arch/arch_7_758944049_1.trc',
4 options=dbms_logmnr.removefile);
5 end;
6 /
PL/SQL procedure successfully completed.
查询结果在v$logmnr_contents;
查询数据库上面的操作
select scn,sql_redo,timestamp from v$logmnr.contents;
关闭分析
execute dbms_logmnr.stop_logmnr;
查询的时候最好使用plsql查询。
登录:sqlplus "/as sysdba"
查看路径:SQL select * from v$logfile;
什么是oracle 日志文件?就是ORACLE 对于一切数据库的操作的记录 方便以后查找分析错误。有可以恢复数据等作用。
Oracle日志文件
1.查询系统使用的是哪一组日志文件:
select * from v$log;
2.查询正在使用的组所对应的日志文件:
select * from v$logfile;
环境:
AIX6.1
Oracle 11g RAC
故障:
数据库频繁出现归档日志空间不够,导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁,操作系统空间不够。
确定原因:
[aix01@oracle]/oracledf -g
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 0.50 0.28 44% 13674 17% /
/dev/hd2 3.00 0.67 78% 49208 23% /usr
/dev/hd9var 1.00 0.37 63% 9285 10% /var
/dev/hd3 2.00 1.03 49% 2407 1% /tmp
/dev/fwdump 1.00 0.99 2% 30 1% /var/adm/ras/platform
/dev/hd1 0.25 0.18 28% 465 2% /home
/dev/hd11admin 0.25 0.25 1% 5 1% /admin
/proc - - - - - /proc
/dev/hd10opt 0.50 0.28 44% 10241 14% /opt
/dev/livedump 0.25 0.25 1% 12 1% /var/adm/ras/livedump
/dev/oraclelv 30.00 11.29 63% 161681 6% /oracle
/dev/installlv 15.00 3.38 78% 6478 1% /install
/dev/crslv 10.00 3.35 67% 7807 1% /crs
/dev/wmsapplv 30.00 17.49 42% 15537 1% /wmprod
/dev/archivelv 29.25 29.25 1% 4 1% /arch1
/dev/backuplv 400.00 107.13 74% 306 1% /sysbackup
aix02:arch2 30.25 0.64 99% 3 1% /arch2
可以看到,/arch2里文件系统空间已经达到99%,/arch2是用来存放归档日志的文件系统,进而导致数据库出错。
提出问题:
这下问题来了,/arch2的空间是30G,每天备份脚本都会自动rman备份归档日志,并自动清除归档日志文件,按照正常情况下,数据库不可能一天产生这么大的归档日志量。
如何查询归档日志都是由什么应用产生的,这就是logminer的用途。
使用方法:
-- 1.指定要分析的日志文件
exec sys.dbms_logmnr.add_logfile(logfilename = '/arch2/2_825_733092736.dbf',options = dbms_logmnr.new);
-- 2.使用本地的在线数据字典分析归档日志
exec sys.dbms_logmnr.start_logmnr(options = sys.dbms_logmnr.dict_from_online_catalog);
-- 3.查询分析出来的归档日志内容,例如统计最大修改量的Schema
select seg_owner,count(*) from v$logmnr_contents group by seg_owner;
-- 4.增加别的日志文件
exec sys.dbms_logmnr.add_logfile(logfilename='/arch2/2_825_733092736.dbf');
-- 5.结束分析归档日志
exec sys.dbms_logmnr.end_logmnr;
下面是具体的过程:
SQL exec sys.dbms_logmnr.add_logfile(logfilename = '/arch2/2_825_733092736.dbf',options = dbms_logmnr.new);
PL/SQL procedure successfully completed
SQL exec sys.dbms_logmnr.start_logmnr(options = sys.dbms_logmnr.dict_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_logmnr.end_logmnr ;
PL/SQL procedure successfully completed
结论:
从上面查询结果可以看出操作量最大的用户是WAS用户,再具体看下v$logmnr_contents可以发现基本修改的内容是一致的。
与开发人员沟通后,最终确认是一个执行update过程存在问题,where条件未正确定位到记录,每执行一次都会导致大规模的修改数据。