Oracle databases (as well as application servers and oracle applications) are fully measurable, and this measurable response in the database is in the following areas:
V$ Views Most V$ views contain "debug" information
Audit commands can specify which events are to be logged by the database for later analysis
The resource manager (dbms_resource_manager) allows micro-management of resources (cpu, I/O, etc.) in the database
oracle "events" are based on oracle events and enable oracle to generate the required trace or diagnostic information
dbms_trace This is a tool in the pl/sql engine, which comprehensively records the call tree of the stored procedure, the exceptions generated, and the errors encountered
Database Event Triggers These triggers (such as on servererror) allow you to monitor and log events that you perceive as "unexpected" or abnormal
The sql_trace sql trace tool can also be used in an extended way, that is, through the 10046 oracle event
Requested trace file
The general trace files are generated by setting sql_trace=true, or by using the extended trace tool through the 10046 event:
sys@ORCL>alter session set events 2 '10046 trace name context forever,level 12'; Session changed.
1. File location
Whether using sql_trace or the extended trace facility, oracle generates a trace file in the following two locations on the database server host:
Dedicated server connection -- generates trace files in the directory specified by the user_dump_dest parameter
Shared server connection -- generates trace files in the directory specified by the background_dump_dest parameter
sys@ORCL>select name,value from v$parameter where name like '%dump_dest%' 2 / NAME -------------------------------------------------------------------------------- VALUE -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ---------------------------------------- background_dump_dest d:\app\administrator\diag\rdbms\orcl\orcl\trace user_dump_dest d:\app\administrator\diag\rdbms\orcl\orcl\trace core_dump_dest d:\app\administrator\diag\rdbms\orcl\orcl\cdump
If you don't have access to the v$parameter view, you can also use dbms_utility to access the values of most (but not all) parameters:
least_privs@ORCL>declare
2 l_string varchar2(255);
3 l_dummy number;
4 begin
5 l_dummy := dbms_utility.get_parameter_value
6 ('background_dump_dest', l_dummy,l_string);
7 dbms_output.put_line('background:'||l_string);
8 l_dummy := dbms_utility.get_parameter_value
9 ('user_dump_dest',l_dummy,l_string);
10 dbms_output.put_line('user:'||l_string);
11 end;
12 /
background:d:\app\administrator\diag\rdbms\orcl\orcl\trace
user:d:\app\administrator\diag\rdbms\orcl\orcl\trace
PL/SQL procedure completed successfully.
2. Naming Conventions
The first part of the filename is oracle_sid
The second part of the filename is ora
The number in the trace file name is the process id of the dedicated server, which can be obtained from the v$process view
Because, in practice (assuming dedicated server mode is used), four views need to be accessed:
v$parameter Find the trace file location specified by user_dump_dest
v$process find process ID
v$session correctly identifies session information in other views
v$instance get oracle_sid
scott@ORCL>alter session set sql_trace=true;
Session changed.
scott@ORCL>select c.value||'/'||d.instance_name||
2 '_ora_'||a.spid||'.trc'trace
3 from v$process a, v$session b, v$parameter c ,v$instance d
4 where a.addr=b.paddr
5 and b.audsid=userenv('sessionid')
6 and c.name='user_dump_dest'
7 /
TRACE
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------------------------
d:\app\administrator\diag\rdbms\orcl\orcl\trace/orcl_ora_4404.trc
3. Mark the trace files
There is a way to "tag" trace files so that you can find them even if you don't have access to v$process and v$session.
Assuming you can read the user_dump_dest directory, you can use the session parameter tracefile_identifier . In this way, you can add a uniquely identifying string to the trace file name:
scott@ORCL>alter session set tracefile_identifier='Look_For_Me'; Session changed. scott@ORCL>alter session set sql_trace=true; Session changed.
Trace files generated for internal errors
They are useful for oracle support.
If you get an internal error, the only way to fix the error is to submit an iTAR
----------------------------------------------------------------------
Alarm log file
Is a special type of trace file (trace file), named generally alert_<SID>.log, where SID is the name of the ORACLE database instance. The database alarm log records message and error information in chronological order.
Alarm log location
In ORACLE 10g, the BACKGROUND_DUMP_DEST parameter determines the location of the alarm log, but the file name of the alarm log cannot be modified. The name of the alarm log is: alert_<SID>.log , where <SID> is the name of the instance. The BACKGROUND_DUMP_DEST parameter is dynamic.scott@ORCL>show parameter background_dump_dest;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
background_dump_dest string d:\app\administrator\diag\rdbm
s\orcl\orcl\trace
In ORACLE 11g and ORACLE 12c, the location of the alert log file has changed. Mainly because of the introduction of ADR (Automatic Diagnostic Repository: a directory for storing database diagnostic logs and trace files) , the directory location corresponding to ADR can be viewed by viewing the v$diag_info system view:
scott@ORCL>select * from v$diag_info;
INST_ID NAME
---------- ----------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------------------------
1 Diag Enabled
TRUE
1 Basic ADR
d:\app\administrator
1 ADR Home
d:\app\administrator\diag\rdbms\orcl\orcl
1 Diag Trace
d:\app\administrator\diag\rdbms\orcl\orcl\trace
1 Diag Alert
d:\app\administrator\diag\rdbms\orcl\orcl\alert
1 Diag Incident
d:\app\administrator\diag\rdbms\orcl\orcl\incident
1 Diag Cdump
d:\app\administrator\diag\rdbms\orcl\orcl\cdump
1 Health Monitor
d:\app\administrator\diag\rdbms\orcl\orcl\hm
1 Default Trace File
d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4928.trc
1 Active Problem Count
0
1 Active Incident Count
0
11 rows have been selected.
The directory corresponding to Diag Trace is the directory where the alert log file in text format is located, and the directory corresponding to Diag Alert is the alert log in XML format (corresponding to log_x.xml)
The following code creates an external table for querying the warning log:
scott@ORCL>create or replace directory data_dir as 'D:\app\Administrator\diag\rdbms\orcl\orcl\alert'; Directory has been created.
scott@ORCL>create table alert_log 2 ( 3 text_line varchar2(255) 4 ) 5 organization external 6 ( 7 type oracle_loader 8 default directory data_dir 9 access parameters 10 ( 11 records delimited by newline 12 fields 13 reject rows with all null fields 14 ) 15 location 16 ( 17 'alert_AskUs.log' 18 ) 19 ) 20 reject limit unlimited 21 / Table has been created.
This information can be queried at any time:
select to_char(last_time,'dd-mon-yyyy hh24:mi') shutdown, to_char(start_time,'dd-mon-yyyy hh24:mi') shutup, round((start_time-last_time)*24*60,2) mins_down, round((last_time-lag(start_time) over(order by r)),2) days_up, case when (lead(r) over(order by r) is null) then round((sysdate-start_time),2) end from ( select r, to_date(last_time,'Dy Mon DD HH24:MI:SS YYYY') last_time, to_date(start_time,'Dy Mon DD HH24:MI:SS YYYY') start_time from( select r, text_line, lag(text_line,1) over(order by r) start_time, lag(text_line,2) over(order by r) last_time from( select rownum r,text_line from alert_log where text_line like '____:__:__20__' or text_line like 'Starting ORACLE instance %' ) ) where text_line like 'Starting ORACLE instance %' ) /