当前位置:首页 » 数据仓库 » oracle数据库日志分析
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

oracle数据库日志分析

发布时间: 2022-08-01 13:03:18

Ⅰ 如何查看oracle数据库的系统日志

记录系统日志,比如日志切换的记录,修改系统参数等系统事件。
位置在参数background_mp_dest指定的路径下,一般为: %ORACLE_BASE%\admin\%ORACLE_SID%\bmp

Ⅱ 怎么获取oracle数据库变化日志

Oracle数据库诊断文件(日志)查看

Diagnostic File(诊断文件)
1:诊断文件的作用
Diagnostic files :
包含了后台遇见重大事件的信息。
被用于解析问题,
被用于日常管理日志文件。
2:诊断文件日志的分类
分为两类:
1: alterSID.log
-----background trace files (后台进程跟踪文件)
2: trace files ---
-----user trace file (用户trace 文件)
1:对于Background trace files文件的命名:
命名方式: SID_processname_PID.trc 对应解释 SID_进程名_进程号.trc

2: 对于user trace files 的文件命名为:
SID_ora_PID.trc 解释: SID_ora_进程号.trc

3:对于 alertSID.log 说明:
这个文件是为了记录: 1:记录一些操作命令
2:记录主要事件的结果
3:以及日常的操作信息
4:被用于诊断数据库错误
每一个entry 都有一个time stamp(时间戳)和它关联
该文件必须被ORACLE DBA管理
这个文件的位置在: BACKGROUND_DUMP_DEST
通过 show parameter mp 查看这个文件的位置:

这个文件中也包含数据库的启动信息相当于pfile或者spfile的内容。
用管理员登录:

2:下面是实战操作:
首先用sysdba登录后执行:
[sql]
SQL> show parameter mp

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
background_core_mp string partial
background_mp_dest string d:\app\topwqp\diag\rdbms\orcl\
orcl\trace
core_mp_dest string d:\app\topwqp\diag\rdbms\orcl\
orcl\cmp
max_mp_file_size string unlimited
shadow_core_mp string none
user_mp_dest string d:\app\topwqp\diag\rdbms\orcl\
orcl\trace
可以看到这些文件的路径信息。
根据显式的信息我找到我的文件位置:
目录结构如下:

下面说一下如何才能记录信息到这些日志文件,需要一些开关,如果不开,记录的只是
一点点信息而已:
两种方式 能够让用户tracing

1:session 级别的:
使用如下命令:
ALTER SESSSION SET SQL_TRACE = TRUE
第二种是执行如下存储过程:
dbms_system.SET_SQL_TRACE_IN_SESSION

第二个方式是 instance级别的:
设置初始化参数: SQL_TRACE = TRUE

一般采用session级别的。因为设置instance级别的容易造成log文件过大;

可以通过alterSID.log文件中的信息制作pfile 或者spfile文件启动
数据库。

下面采用session级别的修改sql_trace为true即可在user_mp_dest中对应文件中看到相应的信息。
[sql]
SQL> conn /as sysdba
已连接。
SQL> alter session set sql_trace = true;

会话已更改。

执行过后:查看
orcl_ora_7188.trc文件信息 PS:如果不知道哪个文件就把这个目录下的全部删除,再执行sql就会看到生成的文件:
查看这个文件信息如下:
很详细的执行信息:
比如一个语句为:select * from al
这个文件中会生成如下信息:
[plain]
*** 2013-06-13 22:58:20.776
=====================
PARSING IN CURSOR #1 len=18 dep=0 uid=0 oct=3 lid=0 tim=9184375464 hv=942515969 ad='232363f8' sqlid='a5ks9fhw2v9s1'
select * from al
END OF STMT
PARSE #1:c=0,e=32,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184375458
EXEC #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184376205
FETCH #1:c=0,e=109,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=9184376423
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=115 op='TABLE ACCESS FULL DUAL (cr=3 pr=0 pw=0 time=0 us cost=2 size=2 card=1)'
FETCH #1:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=9184376893

是对这个sql的执行的详细解读分析

下面贴上今天的部分执行的信息:
[plain]
*** 2013-06-13 22:58:20.776
=====================
PARSING IN CURSOR #1 len=18 dep=0 uid=0 oct=3 lid=0 tim=9184375464 hv=942515969 ad='232363f8' sqlid='a5ks9fhw2v9s1'
select * from al
END OF STMT
PARSE #1:c=0,e=32,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184375458
EXEC #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9184376205
FETCH #1:c=0,e=109,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=9184376423
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=115 op='TABLE ACCESS FULL DUAL (cr=3 pr=0 pw=0 time=0 us cost=2 size=2 card=1)'
FETCH #1:c=0,e=2,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=9184376893

*** 2013-06-13 23:15:15.474
=====================
PARSING IN CURSOR #1 len=289 dep=0 uid=0 oct=3 lid=0 tim=10199053291 hv=2462394820 ad='232017e0' sqlid='7cfz5wy9caaf4'
SELECT NAME
NAME_COL_PLUS_SHOW_PARAM,DECODE(TYPE,1,'boolean',2,'string',3,'integer',4,'file',5,'number',
6,'big integer', 'unknown') TYPE,DISPLAY_VALUE
VALUE_COL_PLUS_SHOW_PARAM FROM V$PARAMETER WHERE UPPER(NAME) LIKE
UPPER(:NMBIND_SHOW_OBJ) ORDER BY NAME_COL_PLUS_SHOW_PARAM,ROWNUM
END OF STMT
PARSE #1:c=0,e=438,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=10199053285
=====================
PARSING IN CURSOR #2 len=210 dep=1 uid=0 oct=3 lid=0 tim=10199056088 hv=864012087 ad='29162590' sqlid='96g93hntrzjtr'
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,
timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival,
density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and
intcol#=:2
END OF STMT
PARSE #2:c=0,e=568,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,tim=10199056084
EXEC #2:c=0,e=1024,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,tim=10199057412
FETCH #2:c=0,e=30,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=3,tim=10199057533
STAT #2 id=1 cnt=0 pid=0 pos=1 obj=411 op='TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=2 pr=0 pw=0 time=0 us)'
STAT #2 id=2 cnt=0 pid=1 pos=1 obj=413 op='INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=0 us)'
=====================
PARSING IN CURSOR #2 len=210 dep=1 uid=0 oct=3 lid=0 tim=10199057848 hv=864012087 ad='29162590' sqlid='96g93hntrzjtr'
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,
timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival,
density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and
intcol#=:2
END OF STMT
EXEC #2:c=0,e=25,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=3,tim=10199057844
FETCH #2:c=0,e=13,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=3,tim=10199058128
EXEC #1:c=0,e=7034,p=0,cr=4,cu=0,mis=1,r=0,dep=0,og=1,tim=10199060756
FETCH #1:c=15600,e=13882,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=10199075783
FETCH #1:c=0,e=21,p=0,cr=0,cu=0,mis=0,r=5,dep=0,og=1,tim=10199076326
STAT #1 id=1 cnt=6 pid=0 pos=1 obj=0 op='SORT ORDER BY (cr=0 pr=0 pw=0 time=0 us cost=2 size=2115 card=1)'
STAT #1 id=2 cnt=6 pid=1 pos=1 obj=0 op='COUNT (cr=0 pr=0 pw=0 time=8 us)'
STAT #1 id=3 cnt=6 pid=2 pos=1 obj=0 op='HASH JOIN (cr=0 pr=0 pw=0 time=6 us cost=1 size=2115 card=1)'
STAT #1 id=4 cnt=35 pid=3 pos=1 obj=0 op='FIXED TABLE FULL X$KSPPI (cr=0 pr=0 pw=0 time=70 us cost=0 size=81 card=1)'
STAT #1 id=5 cnt=1915 pid=3 pos=2 obj=0 op='FIXED TABLE FULL X$KSPPCV (cr=0 pr=0 pw=0 time=19 us cost=0 size=203400 card=100)'

关于alter_SID.log中的内容如下: 今天的:
注意这个文件中包含Oracle启动的参数信息:可以利用这些信息配置spfile或者pfile文件尝试用这个配置的文件启动数据库也可以的
[plain]
Thu Jun 13 22:13:43 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as D:\app\topwqp\proct\11.1.0\db_1\RDBMS
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 11.1.0.6.0.
Using parameter settings in server-side spfile D:\APP\TOPWQP\PRODUCT\11.1.0\DB_1\DATABASE\SPFILEORCL.ORA
System parameters with non-default values:
processes = 150
memory_target = 412M
control_files = "D:\APP\TOPWQP\ORADATA\ORCL\CONTROL01.CTL"
control_files = "D:\APP\TOPWQP\ORADATA\ORCL\CONTROL02.CTL"
control_files = "D:\APP\TOPWQP\ORADATA\ORCL\CONTROL03.CTL"
db_block_size = 8192
compatible = "11.1.0.0.0"
db_recovery_file_dest = "D:\app\topwqp\flash_recovery_area"
db_recovery_file_dest_size= 2G
fast_start_mttr_target = 0
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
audit_file_dest = "D:\APP\TOPWQP\ADMIN\ORCL\ADUMP"
audit_trail = "DB"
db_name = "orcl"
open_cursors = 300
diagnostic_dest = "D:\APP\TOPWQP"
Thu Jun 13 22:13:46 2013
PMON started with pid=2, OS id=1888
Thu Jun 13 22:13:46 2013
VKTM started with pid=3, OS id=4296 at elevated priority
Thu Jun 13 22:13:46 2013
DIAG started with pid=4, OS id=6804
VKTM running at (20)ms precision
Thu Jun 13 22:13:46 2013

Ⅲ oracle数据库中日志的作用是什么简单描述Oracle二级日志结构的特点 (二级日志是啥东东)

Oracle数据库的日志有:
Redo logfile ----重做日志
Archive logfile ----归档日志
Trace file ---- 跟踪日志
backupground_mp_dest ---- 后台进程跟踪
core_mp_dest ---- Oracle内核日志
User_mp_dest ---- 用户跟踪(服务器进程)

简称日志一般指的是联机重做日志文件(Redlog)。主要功能是恢复异常关闭的数据库和保证数据的完整性、一致性。还有可恢复近期丢失的数据(这要看重做日志文件的容量)。
重做文件的原理是:把DML(Insert、Update、Delete)语句所处理的前后记录都写入重做日志文件中。当数据库的数据出故障时利用重做日志文件中的数据重新运行一次之前做过的业务,以此来恢复数据库中除了故障的数据。
重做日志文件至少要有两组,一般是三组。写满第一组写第二组,写满第二组写第三组,写满第三组返回覆盖写第一组,以此类推。

Ⅳ oracle数据库的警告日志如何查看

告警日志文件是一类特殊的跟踪文件(trace file)。告警日志文件命名一般为alert_<SID>.log,其中SID为ORACLE数据库实例名称。数据库告警日志是按时间顺序记录message和错误信息。
http://www.cnblogs.com/kerrycode/p/3899558.html

Ⅳ 怎么分析 oracle 归档日志

环境:
AIX6.1
Oracle 11g RAC
故障:
数据库频繁出现归档日志空间不够,导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁,操作系统空间不够。
确定原因:
[aix01@oracle]/oracle>df -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/fwmp 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/livemp 0.25 0.25 1% 12 1% /var/adm/ras/livemp
/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 procere successfully completed
SQL> exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);
PL/SQL procere 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 procere successfully completed
结论:
从上面查询结果可以看出操作量最大的用户是WAS用户,再具体看下v$logmnr_contents可以发现基本修改的内容是一致的。
与开发人员沟通后,最终确认是一个执行update过程存在问题,where条件未正确定位到记录,每执行一次都会导致大规模的修改数据。

Ⅵ Oracle数据库有哪些日志啊包括监听服务的日志和RAC的日志。都怎么查啊

(1)alert 日志
sqlplus>show parameter background;
(2)监听日志
lsnrctl>status
ps:如果想重命名监听日志的话,要执行set log_status off命令,取走过后,执行set log_status on
(3)CRS日志(grid):
首选查看alertlog:
$CRS_HOME/grid/log/hostname/alertdbserver1.log
Clusterware后台进程日志:
crsd.Log: $ORA_CRS_HOME/grid/log/hostname/crsd/crsd.Log
ocssd.Log: $ORA_CRS_HOME/grid/log/hostname/cssd/ocsd.Log
evmd.Log: $ORA_CRS_HOME/grid/log/hostname/evmd/evmd.Log

Ⅶ 如何分析oracle日志文件

Oracle日志查看

一.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日志的查看方法:

SQL>select * from v$sql (#查看最近所作的操作)

SQL>select * fromv $sqlarea(#查看最近所作的操作)

Oracle 数据库的所有更改都记录在日志中,从目前来看,分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner来进行,因为原始的日志信息我们根本无法看懂,Oracle8i后续版本中自带了LogMiner,而LogMiner就是让我们看懂日志信息的工具,通过这个工具可以:查明数据库的逻辑更改,侦察并更正用户的误操作,执行事后审计,执行变化分析。

Ⅷ oracle如何查看日志文件

oracle日志查看
一.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日志的查看方法:
sql>select
*
from
v$sql
(#查看最近所作的操作)
sql>select
*
fromv
$sqlarea(#查看最近所作的操作)
oracle
数据库的所有更改都记录在日志中,从目前来看,分析oracle日志的唯一方法就是使用oracle公司提供的logminer来进行,因为原始的日志信息我们根本无法看懂,oracle8i后续版本中自带了logminer,而logminer就是让我们看懂日志信息的工具,通过这个工具可以:查明数据库的逻辑更改,侦察并更正用户的误操作,执行事后审计,执行变化分析。