Ⅰ 如何查看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就是讓我們看懂日誌信息的工具,通過這個工具可以：查明資料庫的邏輯更改，偵察並更正用戶的誤操作，執行事後審計，執行變化分析。