Specify a particular node for a trace file to be created

When creating a trace file, is it possible to specify a node where the trace file will reside? fi so, pls give example...
thank u

I believe that is relative to the instance you are actually connected to/through.

Similar Messages

Question for lmd0 trace file

Hi All,
Our db is 2 nodes RAC db on window 2003 server. The database version is 10.2.0.3 Enterprise Edition. My question is: we have the following messages in our db alert log but when I tried to look into the trace file I can’t find the trace file in that directory at all. Then I did the search and found this file in Recycle Bin folder. So I restored the file to d:\oracle\admin\avprod\bdump\ directory. The strange thing is that the modify date of the file is 9/26/09 but it contains data from 10/01/09. Can anybody tell me what is going here? Why this trace file can’t be regenerated after deletion?
Thu Oct 01 18:02:37 2009
Global Enqueue Services Deadlock detected. More info in file
d:\oracle\admin\avprod\bdump\avprod1_lmd0_5472.trc.
Thu Oct 01 18:05:49 2009
Global Enqueue Services Deadlock detected. More info in file
d:\oracle\admin\avprod\bdump\avprod1_lmd0_5472.trc.
Thanks a lot for your help and have a great weekend!
Shirley

Thanks Srini, for your response. The following is some of the content in lmd0 trace file:
*** 2009-10-01 18:00:42.343
* kjdrchkdrm: found an RM request in the request queue
Dissolve pkey 498214
DRM(480) ignoring dissolve of 498214
* kjdrchkdrm: found an RM request in the request queue
Dissolve pkey 498215
DRM(480) ignoring dissolve of 498215
*** 2009-10-01 18:02:37.171
Global Wait-For-Graph(WFG) at ddTS[0.12b] :
BLOCKED 00000002C399D470 5 [0xe4000b][0x237682],[TX] [1A2000-0003-0004049C] 1
BLOCKER 00000002C399D320 5 [0xe4000b][0x237682],[TX] [1C2000-0003-00021E4B] 1
BLOCKED 00000002C38B3760 5 [0x107001d][0x5db6],[TX] [1C2000-0003-00021E4B] 1
BLOCKER 00000002C38B34A8 5 [0x107001d][0x5db6],[TX] [1A2000-0003-0004049C] 1
*** 2009-10-01 18:05:08.375
Setting 3-way CR grants to 0 global-lru off? 0
*** 2009-10-01 18:05:39.781
Setting 3-way CR grants to 1 global-lru off? 0
Global Wait-For-Graph(WFG) at ddTS[0.12b] :
BLOCKED 00000002C36CAB68 5 [0xde000f][0x198822],[TX] [1B2000-0003-00025BA2] 1
BLOCKER 00000002C36CAA00 5 [0xde000f][0x198822],[TX] [1A2000-0003-0004048B] 1
BLOCKED 00000002C358C0C8 5 [0x1000017][0x5bbb6],[TX] [1A2000-0003-0004048B] 1
BLOCKER 00000002C358BF78 5 [0x1000017][0x5bbb6],[TX] [1B2000-0003-00025BA2] 1
*** 2009-10-01 18:06:10.812

Triple Combo GUI tool for CUCM trace files analysis

Hi folks,
the link to the Triple Combo GUI tool to analyze CUCM trace files appears to be broken:
www.employees.org/~tiryaki/tc
any idea where the tool is gone or with whaht was is replaced?
thanks
best wishes
Lucio

Hi Lucio,
you can try TranslatorX.
http://translatorx.cisco.com/index.html
//Suresh
Please rate all the useful posts.

How to specify a particular index for DB2 database when using SQL in ABAP

Is this format for Oracle?
select *
   into -
   from vbrk CLIENT SPECIFIED
where erdat in erdat
    and mandt EQ sy-MANDT
    %_HINTS ORACLE 'INDEX("VBRK" "VBRK~ZER")'
For the index 'VBRK~ZER' was defined before,it only includes one field 'VBRK-ERDAT'.
How can i tell Sap to use this index while processing SQL in DB2?
Thanks advance.

There are different hints for the different database platforms.
For up-to-date information please read the SAP notes, search 'hint DB2'.
Siegfried

Trace file in RAC environment

When creating a trace file, is it possible to specify a node where the trace file will be created? If so, please give example?
thank u

Like Chandra mentioned i dont think we can have a trace file get generated on a specific node. however you can do the following.. you can identify your trace files using..
ALTER SESSION SET TRACEFILE_IDENTIFIER ='MV'
Then you can use the 'trcsess' utility to bring down the trace files from multiple instances (if any) into one file and then run a TKPROF.
Refer to metalink Note # 280543.1 on how to use trcsess

How to stop the generation of the trace files relate to the particular user

Dear All,
Please advice:
Is it possible to stop the trace file created by a user for a particular job (sql/exp)
For example :
Trace files create whenever the user run the sql/exp command from his application server.
This will created a huge files and caused the file system getting full (not in bdump but it is generation in application user home directory).
Is there any method to stop the generation of the trace files relate to the particular user base on that job.
thanks,
Shanoj

Dear SHANOJ
This trigger will created for that specific user by dba or person who have sysdba privs. it will triggered at the login time of that user and alter the sqltrace.
for example we have write one trigger in our database for every ddl operation in database.
CREATE OR REPLACE TRIGGER "SYS"."SYS$DDLTRIG" after DDL on database
declare
v_machinename VARCHAR2(100);
v_osuser VARCHAR2(100);
v_dbuser VARCHAR2(100);
v_host VARCHAR2(100);
v_program VARCHAR2(100);
v_instance VARCHAR2(100);
v_date VARCHAR2(100);
begin
select to_char(sysdate, 'mm-dd-yyyy HH24:MI:SS'),user,sys_context('userenv','OS_
USER'),sys_context('userenv','HOST'), (select instance_name from v$instance),(se
lect program from v$session where sid = (select distinct sid from v$mystat)),(se
lect machine from v$session where sid = (select distinct sid from v$mystat)) int
o v_date,v_dbuser,v_osuser,v_host,v_instance,v_program,v_machinename from dual;
IF ora_sysevent = 'DROP' or ora_sysevent = 'REVOKE' or ora_sysevent = 'GRANT' or
ora_sysevent = 'CREATE' or ora_sysevent = 'TRUNCATE' or ora_sysevent = 'ALTER'
Then
insert into ddl_log_new(v_date,v_dbuser,v_osuser,v_host,v_instance,v_program,v_m
achinename,V_EVENT,V_OBJECT_NAME,V_OBJECT_TYPE,V_OBJECT_OWNER) values (v_date,v_
dbuser,v_osuser,v_host,v_instance,v_program,v_machinename,ora_sysevent,ora_dict_
obj_name,ora_dict_obj_type,ora_dict_obj_owner);
END IF;
END;
i hope above example will helpful for u,
Regards
Ambrish
Edited by: ambrishr24 on Dec 5, 2012 5:02 PM
Edited by: ambrishr24 on Dec 5, 2012 5:05 PM
Edited by: ambrishr24 on Dec 5, 2012 5:20 PM

Trace files generated for every session in 11g

Hi
I have two databases - both 11.1.0.7, both on RHEL5
Database A runs on Server A
Database B runs on Server B
Both installation of 11g and each database are new installations.
On Database A a trace file is being created for every session in ADR_HOME.../trace.
On Database B - this is not happening
The problem I have is Database A. As every session connection creates a trace file (or 2 - being *.trc and *trm), at the end of the day we have 1000's of unnecessry trace files.
A trace file is created for every user - SYS, SYSTEM, application users, etc... It's being created immediately - even if no SQL statements are run in the session.
I've compared the init.ora parameters running in each database - and can find no differences. btw - SQL_TRACE is set to FALSE.
Any ideas why a trace file is being generated for every session on Database A? And how to switch this off?
TIA
Regards
Paul

What type of content is in generated trace files? Is it SQL trace or something different?
Have you any AFTER LOGON trigger? It can be checked with:
col text format a100
select name, text
from dba_source
where name in (select trigger_name from dba_triggers where triggering_event like 'LOGON%')
order by name, line

Unable to generate trace file

Hi,
I have written the stored procedure for starting sql trace on a given session for say n number of seconds.
create or replace procedure start_trace
v_sid in number,
v_serial# in number,
seconds in number)
IS
v_user varchar2 (32);
duration number;
dump_dest varchar2 (200);
db_name varchar2 (32);
no_session_found exception;
stmt varchar2(100);
stmt1 varchar2(100);
BEGIN
begin
select username into v_user
from v$session
where sid= v_sid and
serial# = v_serial#;
exception
when NO_DATA_FOUND then
raise no_session_found;
end;
dbms_output.put_line('Tracing Started for User: '|| v_user);
dbms_output.put_line('Tracing Start Time: '|| TO_CHAR(SYSDATE, 'MM-DD-YYYY HH24:MI:SS'));
dbms_system.set_sql_trace_in_session(v_sid,v_serial#,true);
if seconds is null then
duration := 60;
else
duration := seconds;
end if;
dbms_lock.sleep(duration);
dbms_system.set_sql_trace_in_session(v_sid,v_serial#,false);
dbms_output.put_line ('Tracing Stop Time: '|| TO_CHAR(SYSDATE, 'MM-DD-YYYY HH24:MI:SS'));
select value into dump_dest
from v$parameter
where name = 'user_dump_dest';
dbms_output.put_line('Trace Directory: ' || dump_dest);
exception
when no_session_found then
dbms_output.put_line('No session found for sid and serial# specified');
END start_trace;
The above procedure compiles successfully and when I call it from sql prompt it gives me the message that the pl/sql procedure was completed successfully and all put_line statements are displayed.
Real problem comes when I check udump for the trace file. I can not find it there. It seems all the statements in the procedure are executed successfully except dbms_system.set_sql_trace_in_session(v_sid,v_serial#,true) and dbms_system.set_sql_trace_in_session(v_sid,v_serial#,false) for some strange reasons.
Any help will be appreciated.
Thanks.

Thanks for the reply.
I do not get any error message. The following is the output:
SQL> exec start_trace(118,6243,30);
Tracing Started for User: SVCWRK
Tracing Start Time: 09-26-2011 16:28:29
Tracing Stop Time: 09-26-2011 16:28:59
Trace Directory: /orasoft/app/oracle/admin/testsvcb/udump
PL/SQL procedure successfully completed.
But the trace file is not generated.
I am using Oracle 10.2.0.4.0.
Will try using DBMS_MONITOR.
Thanks again.

Changing trace file name giving odd results - 10.2.0.2

Hello,
I'm trying to run a trace on a particular session. Using this:
execute dbms_monitor.session_trace_enable(122, 58)
It creates a tracefile in udump just fine. I turn tracing off:
execute dbms_monitor.session_trace_disable(122, 58)
Then the trace usually catches the next sql statement after I issued the disable and I've got a complete trace file.
If I use the statement:
alter session set tracefile_identifier = 'TEST';
With or without quotes, what ends up happening is the tracefile is created with TEST tacked onto the end but what's inside the file is the full path to the file itself, no trace. The previous trace file before setting the identifier then gets all the trace output. This is on Red Hat. After this the only way to get tracing to work again is to close both sessions and start over.
Am I forgetting to set another parameter when doing this? The litteral set of steps is:
-open session 1
-open session 2
-session 1 run alter session set tracefile_identifier = 'TEST';
-session 1 run execute dbms_monitor.session_trace_enable(122, 58)
-session 2 run some sql
-session 1 run execute dbms_monitor.session_trace_disable(122, 58)
-session 2 run another sql statement
-check the udump for the trace file
Now the ultimate goal here is to be able to tag a trace with a name so I can trace a specific session (made by an application) and then find it later in udump. If the tracefile_id needs to be set in the offending session...well then I need another solution.
Thanks

Once the session starts writing to the trace file it
is going to write to the same file until the session
is closed.
Until the session is closed...aaahhhh gotcha. Well that explains that.
I tried the above with a new session and immediately set the identifier and got the same result, except it created the default trace file name as well as the new identifier copy with the path in it.
The logon trigger might be a workaround but it's not killing me at the moment.

Trace File Created Upon Execution of "alter system kill session sid, serial# immediate;"

A problem within a third-party application is causing it to create and abandon Oracle sessions. At times three hundred or more abandoned sessions accumulated in the instance. The software company is working on the problem. Oracle's background processes will get rid of those sessions after several hours, but at times there were so many they caused the server to start using paging space. We wrote a SQL*Plus script to identify the abandoned sessions and kill them with command "alter system kill session <sid, serial#> immediate;". We automated the execution of the script a week ago. Today I noticed that in my udump directory an Oracle trace file has been created each time our script kills a session. A single trace file is created regardless of how many sessions are killed. No errors appear in the trace file.
Is the creation of these trace files an indication that problems have occurred or are they there for information only?
Since I know how and why the sessions are being killed, is it safe to ignore the trace files?
Thank you,
Bill

The OS is AIX 5.2. The database server is 10.2.0.2. We are in the processing of upgrading to AIX 7.1 and database server 11.2.0.3.6.
The script does not enable tracing for the SQL*Plus session.
Below is the alert log message from a session killed at 11:22, and the corresponding trace file created at that same time:
From alert_<sid>.log:
Wed Jul 31 11:22:01 2013
Immediate Kill Session#: 1119, Serial#: 59885
Immediate Kill Session: sess: 70000014dc4a7e0 OS pid: 267254
/u02/admin/EXPRESS/udump $ ls -l express_ora_113358.trc
-rw-r----- 1 oracle dba 2276 Jul 31 11:22 express_ora_113358.trc
/u02/admin/EXPRESS/udump $ pg express_ora_113358.trc
Dump file /u02/admin/EXPRESS/udump/express_ora_113358.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0
System name: AIX
Node name: navis
Release: 2
Version: 5
Machine: 0005CD8C4C00
Instance name: EXPRESS
Redo thread mounted by this instance: 1
Oracle process number: 225
Unix process pid: 113358, image: oracleEXPRESS@navis
*** ACTION NAME:() 2013-07-31 11:22:01.181
*** MODULE NAME:(SQL*Plus) 2013-07-31 11:22:01.181
*** SERVICE NAME:(EXPRESS.WORLD) 2013-07-31 11:22:01.181
*** SESSION ID:(1723.61000) 2013-07-31 11:22:01.181
SO: 70000014d44d278, type: 2, owner: 0, flag: INIT/-/-/0x00
(process) Oracle pid=463, calls cur/top: 0/700000139166298, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 108 0 4
last post received-location: kslpsr
last process to post me: 70000014d36c398 1 6
last post sent: 0 0 24
last post sent-location: ksasnd
last process posted by me: 70000014d36c398 1 6
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 70000014d6aec00
O/S info: user: oracle, term: UNKNOWN, ospid: 267254
OSD pid info: Unix process pid: 267254, image: oracleEXPRESS@navis
Short stack dump:
ksdxfstk+002c<-ksdxcb+04e4<-sspuser+0074<-00004CB0<-nttrd+0120<-nsprecv+0750<-ns
rdr+0114<-nsdo+1714<-nsbrecv+0040<-nioqrc+04a8<-opikndf2+0688<-opitsk+088c<-opii
no+0990<-opiodr+0adc<-opidrv+0474<-sou2o+0090<-opimai_real+01bc<-main+0098<-__st
art+0090
Dump of memory from 0x070000014D2CC3B0 to 0x070000014D2CC5B8
70000014D2CC3B0 00000004 00000000 07000001 39DA8D48 [............9..H]
70000014D2CC3C0 00000010 0003139D 07000001 39166298 [............9.b.]
70000014D2CC3D0 00000003 0003139D 07000001 4C73D508 [............Ls..]
70000014D2CC3E0 0000000B 0003139D 07000001 4DC4A7E0 [............M...]
70000014D2CC3F0 00000004 00031291 00000000 00000000 [................]
70000014D2CC400 00000000 00000000 00000000 00000000 [................]
Repeat 26 times
70000014D2CC5B0 00000000 00000000 [........]
Thanks,
Bill

Excessive trace files in 11G on AIX 6.1

Hello friends,
I have a few new Oracle 11g (11.1.0.7) databases running on IBM P560's, AIX 6.1.
After a few weeks of running these databases, I've noticed an excessive amount of trace files generated in the $ORACLE_BASE/diag/.../trace directory for various background processes and wondered if I might have a parameter set incorrectly. Note that there are no errors noted or references to the trace files in the alert logs, and I'm seeing the same behavior on two separate similar servers and databases.
I recall on HP-UX, setting ASYNC IO will cause thousands of trace files to be generated, but this seems new with 11g since we are not getting the trace files in our 10G environment.
For every trace file, there is also a 'trm' file.
E.g.,
DBAtst_dbrm_172144.trc
DBAtst_dbrm_172144.trm
The trm file is a binary file, and the trc file is ascii.
Inside of the trace file, the contents are similar to:
=========================================================
System name: AIX
Node name: DBAos2_test
Release: 1
Version: 6
Machine: 00C2AAF44C00
Instance name: DBAtst
Redo thread mounted by this instance: 1
Oracle process number: 5
Unix process pid: 172144, image: oracle@DBAos2_test (DBRM)
*** 2009-05-12 14:17:03.072
*** SESSION ID:(551.1) 2009-05-12 14:17:03.072
*** CLIENT ID:() 2009-05-12 14:17:03.072
*** SERVICE NAME:() 2009-05-12 14:17:03.072
*** MODULE NAME:() 2009-05-12 14:17:03.072
*** ACTION NAME:() 2009-05-12 14:17:03.072
kgsksysstop: from KGSKWT_INTSTATECHNG8 retry TRUE mode
kgsksysstop: Succeeded
kgsksysstop: from KGSKWT_INTSTATECHNG8 retry TRUE mode
*** 2009-05-12 22:00:00.177
kgsksysstop: Succeeded
kgskreset: Threshold setting
low[0] = 8, high[0] = 12
*** 2009-05-12 22:00:37.480
kgsksysstop: from KGSKWT_INTSTATECHNG7 retry FALSE mode
kgsksysstop: Succeeded
Running Count dump BEFORE recalc
Running cnt[0]: 1, Runnable cnt[0]: 0
Running Count dump AFTER recalc
Running cnt[0]: 1, Runnable cnt[0]: 0
kgsksysstop: from KGSKWT_INTSTATECHNG7 retry FALSE mode
Don Burleson has a great web page addressing trace files in 11G, but it doesn't mention anything about excessive trace files.
http://www.praetoriate.com/t_debugging_adr_monitoring_tools.htm
I'm concerned that something is wrong and I should not be getting all these trace files. Plus, they will eventually fill up my disks if I don't keep them pruned down.
Thanks.

According to an article on Metalink, this is not a bug. This is what was posted on metalink
"Solution:
The bug 9056228 was closed as 'Not a bug'.
The messages are expected behavior due to the way the code is written. According to Development, these are not errors but some information Oracle dumps into trace files.
Customers need not to worry about anything about these messages. These are expected.
As a corrective action, these traces can be deleted at any time or ignored. "
I hope this helps.

Abnormal trace file generation.

I am facing this problem for some time now ….. i am having trouble with trace files on only one node ….
SYSTEM DETAILS
i have a 2 node production server …
IBM power 7 P750 servers
oracle version 11.2.0.3 RAC
RMAN not yet configured but logged in once to delete archiving logs
The issue is that on node 2 the trace files are generating on a huge level and i have to manually delete them every 2 hours other wise the space is filling up fast. And to add to my misery the trace files are generating in two separate locations
One location is the default oracle location folder which has a space of 200 gb and it is some how manageable by adrci
The main issue with me is that some files are getting created in the '/var' folder under '/tmp/oradiag_oracle/../../..' forlder also
and this /var folder is only 5 gb
if i ignore it for one hour the space reaches 100%
i am trying to find what traces are enabled on the system so i can disable any unwanted traces.
Can anyone help me by telling me how to check for enable tracing events and how to disable them manually
Thank you .

i would like to add a couple of points here.
1. these trace files have no mention in my original alert log file. However there is log file in the trace folder in the /var filesystem where only this error is logged.
2. here is the complete trace file output.
Dump file /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1_i3877017.trc
Dump continued from file: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1.trc
ORA-07445: exception encountered: core dump [ksmpclrpga()+23296] [SIGSEGV] [ADDR:0x109A1BD28] [PC:0x101E2E540] [Invalid permissions for mapped object] []
========= Dump for incident 3877017 (ORA 7445) ========
----- Beginning of Customized Incident Dump(s) -----
----- End of Customized Incident Dump(s) -----
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
Executing ASYNC actions
----- START DDE Action: 'dumpFrameContext' (Sync) -----
----- START Frame Context DUMP -----
Status: 0
<Empty>
----- END Frame Context DUMP -----
----- END DDE Action: 'dumpFrameContext' (SUCCESS, 0 csec) -----
----- START DDE Action: 'dumpBuckets' (Sync) -----
Trace Bucket Dump Begin: default trace bucket
TIME(*=approx):SEQ:COMPONENT:FILE@LINE: DATA
Trace Bucket Dump End: default trace bucket
----- END DDE Action: 'dumpBuckets' (SUCCESS, 0 csec) -----
----- START DDE Action: 'dumpDiagCtx' (Sync) -----
------- Diag Context Dump -------
----- General DiagCtx Dump -----
Serial#: 3
Status: 3
Flags: 0x15
Usage type: 0
Diag Fixed SGA information:
Status: 2
Flags: 0x0
Incident Flag: UNSET
Heap: 0x1106c96f0
Flood Control information:
Initialized: NO
Enabled: NO
Diag init parameters:
Flags: 0x1
Base Flag: 0x1
Options: 0x86
ADR option: 1
ADR Base: '/var/tmp/oradiag_oracle'
Product Type: 4
Product ID: 'user_oracle'
Instance ID: 'host_1545611351_80'
Flood Control Gate: 0x0
Flood Control Ctx size: 0
ADR default lib ID: 0
UTS in mem trace enabled: TRUE
UTS default bucket size: 4294967295
UTS default bucket: 0x0
Incident ID cache cbf: 0x0
Incident ID cache pop init: FALSE
UTS default trace file attr:
Flags: 0x0
Prefix: ''
PIDStr: ''
Suffix: ''
Notify cbk: 0x0
Size limits: 0
Size cbk: 0x0
DDE alive update cbk: 0x0
DDE alive start cbk: 0x0
DDE alive clear cbk: 0x0
Custom Flood Control cbk: 0x0
----- END General DiagCtx Dump -----
----- DDE Diagnostic Information Dump -----
Depth: 1
DDE flags: 0x0
Heap: 0x1106e84b8
Incident Context pointer in diag: 0x11083ea98
Incident ID Cache: 0x1106f96d8 (PGA)
Invocation Context #: 0
----- Invocation Context Dump -----
Address: 0x1106f02f8
Phase: 3
flags: 0x10E0005
Incident ID: 3877017
Error Descriptor: ORA-7445 [ksmpclrpga()+23296] [SIGSEGV] [ADDR:0x109A1BD28] [PC:0x101E2E540] [Invalid permissions for mapped object] [] [] [] [] [] [] []
Error class: 0
Problem Key # of args: 0
Number of actions: 9
----- Incident Context Dump -----
Address: 0x11083ea98
Incident ID: 3877017
Problem Key: ORA 7445
Error: ORA-7445 [ksmpclrpga()+23296] [SIGSEGV] [ADDR:0x109A1BD28] [PC:0x101E2E540] [Invalid permissions for mapped object] [] [] [] [] [] [] []
[00]: dbgexExplicitEndInc [diag_dde]
[01]: dbgeEndDDEInvocationImpl [diag_dde]
[02]: dbgeEndDDEInvocation [diag_dde]
[03]: ssexhd []
[04]: 47f8 []<-- Signaling
[05]: opidcl []
[06]: opidrv []
[07]: sou2o []
[08]: opimai_real []
[09]: ssthrdmain []
[10]: main []
[11]: __start []
MD [00]: 'Client ProcId'='[email protected]_1' (0x0)
Impact 0:
Impact 1:
Impact 2:
Impact 3:
Derived Impact:
----- END Incident Context Dump -----
----- END Invocation Context Dump -----
Invocation Context #: 1
----- Invocation Context Dump -----
Address: 0x1106f24b0
Phase: 0
flags: 0x0
Incident ID: 0
Error Descriptor:
Error class: 0
Problem Key # of args: 0
Number of actions: 0
----- END Invocation Context Dump -----
----- END DDE Diagnostic Information Dump -----
----- UTS Diagnostic Information Dump (addr=0x11087f670) -----
flags_dbgtc=0x44 seq_ptr_dbgtc=0x11068c248
def_bucket_dbgtc=0x1106d6858 gid_dbgtc=20
defTraceFile_dbgtc=0x1106e8f60 fstack_dbgtc=0x11087f600
lastEpochTsOutputted_dbgtc=412011185194127 lastRecWriteDumpMs_dbgtc=0
recWriteDepth_dbgtc=0 numRecWriteDumps_dbgtc=0
==== Dumping UTS file=0x1106e8f60 desc=default ====
Type=2 flags=0 err=0 cbk=0x11036c140 sctx=0x0
--- Dumping UTS file (ADR type) file=0x1106e8f60 ---
File name: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1.trc
flags=0x1106e8f60 needInit=515 nfyMasked=0 bytes=0
attrib: flags=0x0 pref=ora pid=24838300_1 suffix=
limit=18446744073709551615 nfy=0x0
--- Dumping file stack addr=0x11087f600 cnt=1 ---
Pos=0 fileP=0x1106f0ba8
==== Dumping UTS file=0x1106f0ba8 desc=stack ====
Type=2 flags=0 err=0 cbk=0x11036c140 sctx=0x0
--- Dumping UTS file (ADR type) file=0x1106f0ba8 ---
File name: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1_i3877017.trc
flags=0x1106f0ba8 needInit=555 nfyMasked=0 bytes=0
attrib: flags=0x0 pref=ora pid=24838300_1 suffix=i3877017
limit=18446744073709551615 nfy=0x0
----- END UTS Diagnostic Information Dump -----
----- Events Diagnostic Information Dump -----
Active Fast Chk Desc in DiagCtx is 0x0
Active Event group is Default Group
--- Dump of Event Group ---
Event Group desc : Default/Active Event Group
Located at Address 0x11087f5b0
Event group id 1
Event group version 1
Event group heap 0x1106c9470
Fast Check Descriptor is NULL
----- END Events Diagnostic Information Dump -----
----- ADR Diagnostic Information Dump -----
ADR Flags: 0x1e01
Retries: 1
ADR Home #0
ADR Id: 1688299656
Create Id: 3016083015
Base Flag: 0x1
Product Type: 4
Product Name: clients
Product Id: user_oracle
Instance Id: host_1545611351_80
Base Directory: /var/tmp/oradiag_oracle
Home Directory: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80
Relative Path: diag/clients/user_oracle/host_1545611351_80/
Home Loc #0: 0
Test Action: 0x0, 0
----- ADS Open Files Dump -----
################ Open Stream File: 0 ################
PathFile: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1.trc
OpFlag: 10, Status: 1, MagicBeg: 2153609765, MagicNum: 3593058129
Stream Access
----- ADS Stream Desc Dump -----
fd: 23
----- END ADS Stream Desc Dump -----
File Name Fragment: 51_80/trace/ora_24838300_1.trc
################ Open Stream File: 1 ################
PathFile: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1.trm
OpFlag: 136, Status: 1, MagicBeg: 2153609765, MagicNum: 3593058129
Stream Access
----- ADS Stream Desc Dump -----
fd: 27
----- END ADS Stream Desc Dump -----
File Name Fragment: 51_80/trace/ora_24838300_1.trm
################ Open Stream File: 2 ################
PathFile: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1_i3877017.trc
OpFlag: 10, Status: 1, MagicBeg: 2153609765, MagicNum: 3593058129
Stream Access
----- ADS Stream Desc Dump -----
fd: 28
----- END ADS Stream Desc Dump -----
File Name Fragment: ce/ora_24838300_1_i3877017.trc
################ Open Stream File: 3 ################
PathFile: /var/tmp/oradiag_oracle/diag/clients/user_oracle/host_1545611351_80/trace/ora_24838300_1_i3877017.trm
OpFlag: 136, Status: 1, MagicBeg: 2153609765, MagicNum: 3593058129
Stream Access
----- ADS Stream Desc Dump -----
fd: 29
----- END ADS Stream Desc Dump -----
File Name Fragment: ce/ora_24838300_1_i3877017.trm
----- END ADS Open Files Dump -----
----- END ADR Diagnostic Information Dump -----
----- ADL Diagnostic Information Dump -----
ADL Flags: 0x4
Timestamp: -1569355021
Host Name: sihibmn2
NW Address: 172.25.25.64
----- END ADL Diagnostic Information Dump -----
----- Diag Context Memory -----
1106C93A0 00000001 00000000 00000000 00000000 [................]
1106C93B0 00000003 00000001 03000000 00000000 [................]
1106C93C0 00000001 106DF1E0 00000001 10693A98 [.....m.......i:.]
1106C93D0 00000000 00000000 00000000 00000000 [................]
1106C93E0 00000001 106F4670 00000001 106F8830 [.....oFp.....o.0]
1106C93F0 00000001 106CB008 00000001 1087F360 [.....l.........`]
1106C9400 00000001 1087EB88 00000001 1087EC78 [...............x]
1106C9410 00000001 1087ED40 00000001 1087EE3F [.......@.......?]
1106C9420 00000001 106CB2A8 00000001 106CB3A7 [.....l.......l..]
1106C9430 00000001 106CBA60 00000001 106CBB5F [.....l.`.....l._]
1106C9440 00000001 106CA250 00000001 106CA34F [.....l.P.....l.O]
1106C9450 00000001 106CAA08 00000001 106CAB07 [.....l.......l..]
1106C9460 00000001 1087F670 00000001 1087DAE0 [.......p........]
1106C9470 00000001 106C9500 00001040 00000000 [.....l.....@....]
1106C9480 00000000 00000000 00000001 108522B0 [..............".]
1106C9490 00000001 106F8810 00000000 00000000 [.....o..........]
1106C94A0 00000000 00000000 00030103 00000000 [................]
1106C94B0 00000000 00000000 000008C0 64696167 [............diag]
1106C94C0 20706761 00000000 00000020 7FFF7FFF [ pga....... ....]
1106C94D0 7FFF7FFF 00000000 00000000 00000000 [................]
1106C94E0 00000000 00000000 00000001 1087EB48 [...............H]
1106C94F0 00000001 106F8F30 00000000 00000000 [.....o.0........]
1106C9500 00000000 00000000 000020C0 00000000 [.......... .....]
1106C9510 00000000 00000000 00000001 10854368 [..............Ch]
1106C9520 00000001 1087DA40 00000000 00000000 [.......@........]
1106C9530 00000000 00000000 00021002 00000000 [................]
1106C9540 00000000 00000000 000020C0 70676120 [.......... .pga ]
1106C9550 68656170 00000000 00000060 00007FFF [heap.......`....]
1106C9560 7FFF7FFF 00000000 00000000 00000000 [................]
1106C9570 00000000 00000118 00000001 1087DA20 [............... ]
1106C9580 00000001 106D67B8 00000000 00000218 [.....mg.........]
1106C9590 00000001 106C9590 00000001 106C9590 [.....l.......l..]
1106C95A0 00000000 00000418 00000001 106C95A8 [.............l..]
1106C95B0 00000001 106C95A8 00000000 00000818 [.....l..........]
1106C95C0 00000001 106C95C0 00000001 106C95C0 [.....l.......l..]
1106C95D0 00000000 00001018 00000001 106C95D8 [.............l..]
1106C95E0 00000001 106C95D8 00000000 00002018 [.....l........ .]
1106C95F0 00000001 106C95F0 00000001 106C95F0 [.....l.......l..]
1106C9600 00000000 00004018 00000001 106C9608 [[email protected]..]
1106C9610 00000001 106C9608 00000000 00008018 [.....l..........]
1106C9620 00000001 106C9620 00000001 106C9620 [.....l. .....l. ]
1106C9630 00000000 00010018 00000001 106C9638 [.............l.8]
1106C9640 00000001 106C9638 00000000 00020018 [.....l.8........]
1106C9650 00000001 106C9650 00000001 106C9650 [.....l.P.....l.P]
1106C9660 00000000 00040018 00000001 106C9668 [.............l.h]
1106C9670 00000001 106C9668 00000000 00080018 [.....l.h........]
1106C9680 00000001 106C9680 00000001 106C9680 [.....l.......l..]
1106C9690 00000000 00100018 00000001 106C9698 [.............l..]
1106C96A0 00000001 106C9698 00000000 00200018 [.....l....... ..]
1106C96B0 00000001 106C96B0 00000001 106C96B0 [.....l.......l..]
1106C96C0 00000000 00400018 00000001 106C96C8 [[email protected]..]
1106C96D0 00000001 106C96C8 00000000 00800018 [.....l..........]
1106C96E0 00000001 106C96E0 00000001 106C96E0 [.....l.......l..]
1106C96F0 00000000 00000000 000020C0 00000000 [.......... .....]
1106C9700 00000000 00000000 00000001 106EA3F8 [.............n..]
1106C9710 00000001 106EA458 00000001 106C98E0 [.....n.X.....l..]
1106C9720 00000000 00000000 00021002 00000000 [................]
1106C9730 00000000 00000000 00002058 73676120 [.......... Xsga ]
1106C9740 68656170 00000000 00000020 00107FFF [heap....... ....]
1106C9750 7FFF7FFF 00000000 00000000 00000000 [................]
1106C9760 00000000 00000118 00000001 106EA438 [.............n.8]
1106C9770 00000001 106EA438 00000000 00000218 [.....n.8........]
1106C9780 00000001 106C9780 00000001 106C9780 [.....l.......l..]
1106C9790 00000000 00000418 00000001 106C9798 [.............l..]
1106C97A0 00000001 106C9798 00000000 00000818 [.....l..........]
1106C97B0 00000001 106C97B0 00000001 106C97B0 [.....l.......l..]
1106C97C0 00000000 00001018 00000001 106C97C8 [.............l..]
1106C97D0 00000001 106C97C8 00000000 00002018 [.....l........ .]
1106C97E0 00000001 106C97E0 00000001 106C97E0 [.....l.......l..]
1106C97F0 00000000 00004018 00000001 106C97F8 [[email protected]..]
1106C9800 00000001 106C97F8 00000000 00008018 [.....l..........]
1106C9810 00000001 106C9810 00000001 106C9810 [.....l.......l..]
1106C9820 00000000 00010018 00000001 106C9828 [.............l.(]
1106C9830 00000001 106C9828 00000000 00020018 [.....l.(........]
1106C9840 00000001 106C9840 00000001 106C9840 [[email protected].@]
1106C9850 00000000 00040018 00000001 106C9858 [.............l.X]
1106C9860 00000001 106C9858 00000000 00080018 [.....l.X........]
1106C9870 00000001 106C9870 00000001 106C9870 [.....l.p.....l.p]
1106C9880 00000000 00100018 00000001 106C9888 [.............l..]
1106C9890 00000001 106C9888 00000000 00200018 [.....l....... ..]
1106C98A0 00000001 106C98A0 00000001 106C98A0 [.....l.......l..]
1106C98B0 00000000 00400018 00000001 106C98B8 [[email protected]..]
1106C98C0 00000001 106C98B8 00000000 00800018 [.....l..........]
1106C98D0 00000001 106C98D0 00000001 106C98D0 [.....l.......l..]
1106C98E0 00000001 106C98F0 00000001 106C98F0 [.....l.......l..]
1106C98F0 00000001 106C98E0 00000001 106C98E0 [.....l.......l..]
1106C9900 00000000 00000000 00000000 00000000 [................]
1106C9910 00000000 00000000 00000000 7FFFFFFF [................]
1106C9920 00000000 00000000 00000000 00000000 [................]
Repeat 2 times
1106C9950 00000000 00000000 00000001 106C9958 [.............l.X]
1106C9960 00000001 106C9958 00000000 00000000 [.....l.X........]
1106C9970 00000000 00000000 00000000 00000000 [................]
Repeat 63 times
1106C9D70 00000000 00000000 00000001 106C9D78 [.............l.x]
1106C9D80 00000001 106C9D78 00000000 00000000 [.....l.x........]
1106C9D90 00000001 106C9D90 00000001 106C9D90 [.....l.......l..]
1106C9DA0 00000000 00000000 00000001 106C9DA8 [.............l..]
1106C9DB0 00000001 106C9DA8 00000000 00000000 [.....l..........]
1106C9DC0 00000001 106C9DC0 00000001 106C9DC0 [.....l.......l..]
1106C9DD0 00000000 00000000 00000001 106C9DD8 [.............l..]
1106C9DE0 00000001 106C9DD8 00000000 00000000 [.....l..........]
1106C9DF0 00000001 106C9DF0 00000001 106C9DF0 [.....l.......l..]
1106C9E00 00000000 00000000 00000001 106C9E08 [.............l..]
1106C9E10 00000001 106C9E08 00000000 00000000 [.....l..........]
1106C9E20 00000001 106C9E20 00000001 106C9E20 [.....l. .....l. ]
1106C9E30 00000000 00000000 00000001 106C9E38 [.............l.8]
1106C9E40 00000001 106C9E38 00000000 00000000 [.....l.8........]
1106C9E50 00000001 106C9E50 00000001 106C9E50 [.....l.P.....l.P]
1106C9E60 00000000 00000000 00000001 106C9E68 [.............l.h]
1106C9E70 00000001 106C9E68 00000000 00000000 [.....l.h........]
1106C9E80 00000001 106C9E80 00000001 106C9E80 [.....l.......l..]
1106C9E90 00000000 00000000 00000001 106C9E98 [.............l..]
1106C9EA0 00000001 106C9E98 00000000 00000000 [.....l..........]
1106C9EB0 00000001 106C9EB0 00000001 106C9EB0 [.....l.......l..]
1106C9EC0 00000000 00000000 00000001 106C9EC8 [.............l..]
1106C9ED0 00000001 106C9EC8 00000000 00000000 [.....l..........]
1106C9EE0 00000001 106C9EE0 00000001 106C9EE0 [.....l.......l..]
1106C9EF0 00000000 00000000 00000001 106C9EF8 [.............l..]
1106C9F00 00000001 106C9EF8 00000000 00000000 [.....l..........]
1106C9F10 00000000 00000000 00000000 00000000 [................]
1106C9F20 00000001 106C4D10 00000001 106EFF88 [.....lM......n..]
1106C9F30 00000001 106EA478 00000000 00000000 [.....n.x........]
1106C9F40 00000001 106E34E0 00000001 106C8F88 [.....n4......l..]
1106C9F50 00000001 106C8EE8 00000015 00000000 [.....l..........]
1106C9F60 00000001 106E8558 00000001 106F02F8 [.....n.X.....o..]
1106C9F70 00000001 106F24B0 00000001 00000000 [.....o$.........]
1106C9F80 00000001 1087F8E8 00000001 106E8640 [.............n.@]
1106C9F90 00000000 00000000 00000001 1083EA98 [................]
1106C9FA0 00000001 1087F5B0 00000001 1087F5B0 [................]
1106C9FB0 00000001 106C93A8 00000000 00000001 [.....l..........]
1106C9FC0 00000000 00000000 00000000 00000000 [................]
1106C9FD0 00000003 00000000 00000001 1036C230 [.............6.0]
1106C9FE0 00000001 1036C380 00000001 106EC538 [.....6.......n.8]
1106C9FF0 00000001 106DF1E0 00000000 00000000 [.....m..........]
1106CA000 00000000 00000000 00000000 00000000 [................]
Repeat 1 times
----- Diag Context Init Params Memory -----
1106EFF80 00000001 00000001 [........]
1106EFF90 2F766172 2F746D70 2F6F7261 64696167 [var/tmp/oradiag]
1106EFFA0 5F6F7261 636C6500 00000000 00000000 [_oracle.........]
1106EFFB0 00000000 00000000 00000000 00000000 [................]
Repeat 20 times
1106F0100 00000004 75736572 5F6F7261 636C6500 [....user_oracle.]
1106F0110 00000000 00000000 00000000 00000000 [................]
1106F0120 00000068 6F73745F 31353435 36313133 [...host_15456113]
1106F0130 35315F38 30000000 00000000 00000000 [51_80...........]
1106F0140 00000000 00000000 00000000 00000000 [................]
1106F0150 00000000 00000086 01000000 00000000 [................]
1106F0160 00000000 00000000 00000000 00000000 [................]
Repeat 1 times
1106F0180 00000000 00000001 FFFFFFFF 00000000 [................]
1106F0190 00000000 00000000 00000000 00000000 [................]
Repeat 14 times
1106F0280 00000000 00000000 [........]
----- Diag Thread Local Root Dump -----
Sequence#: 4
Flags: 0x0
Diag Pointers by type:
[0]: 0x1106c93a0
[1]: 0x0
[2]: 0x0
Library References:
[00]: ID=0 (0x1106c8f08):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[01]: ID=0 (0x1106c8f18):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[02]: ID=2 (0x1106c8f28):
Precedence: 2
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[03]: ID=3 (0x1106c8f38):
Precedence: 3
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[04]: ID=0 (0x1106c8f48):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[05]: ID=0 (0x1106c8f58):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[06]: ID=0 (0x1106c8f68):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[07]: ID=0 (0x1106c8f78):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[08]: ID=8 (0x1106c8f88):
Precedence: 8
Reference Count: 1
Usage type: 0
Usage flags: 0x0
[09]: ID=0 (0x1106c8f98):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[10]: ID=0 (0x1106c8fa8):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[11]: ID=0 (0x1106c8fb8):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[12]: ID=0 (0x1106c8fc8):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[13]: ID=0 (0x1106c8fd8):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[14]: ID=0 (0x1106c8fe8):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[15]: ID=0 (0x1106c8ff8):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[16]: ID=0 (0x1106c9008):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[17]: ID=0 (0x1106c9018):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[18]: ID=0 (0x1106c9028):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[19]: ID=0 (0x1106c9038):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
[20]: ID=0 (0x1106c9048):
Precedence: 0
Reference Count: 0
Usage type: 0
Usage flags: 0x0
----- Diag Thread Local Root Memory -----
1106C8EE0 3B9EF5C8 00000000 [;.......]
1106C8EF0 00000001 106C93A0 00000000 00000000 [.....l..........]
1106C8F00 00000000 00000000 00000000 00000000 [................]
Repeat 2 times
1106C8F30 00000002 02000000 00000000 00000000 [................]
1106C8F40 00000003 03000000 00000000 00000000 [................]
1106C8F50 00000000 00000000 00000000 00000000 [................]
Repeat 2 times
1106C8F80 00000000 00000000 00000001 106EFF88 [.............n..]
1106C8F90 00000008 08010000 00000000 00000000 [................]
1106C8FA0 00000000 00000000 00000000 00000000 [................]
Repeat 10 times
1106C9050 00000000 00000000 00000004 00000000 [................]
----- END Diag Thread Local Root Dump -----
----- Diag Context Flood Control Memory -----
1106EA480 00000000 00000000 [........]
1106EA490 00000000 00000000 00000000 00000000 [................]
Repeat 5 times
1106EA4F0 00000000 00000000 [........]
------- END Diag Context Dump -------
----- END DDE Action: 'dumpDiagCtx' (SUCCESS, 0 csec) -----
----- START DDE Action: 'dumpGenralConfiguration' (Sync) -----
========= General Configuration ========
--------- GC Source: [generic GC] --------
[0000]: item 0=ORACLE_HOME = /u0/app/oracle/product/11.2.0/dbhome_1
[0000]: item 1=System name:     AIX
[0000]: item 2=Node name:     sihibmn2
[0000]: item 3=Release:     1
[0000]: item 4=Version:     7
[0000]: item 5=Machine:     00F7694C4C00
--------- GC Source: [unittest_GC] --------
--------- GC Source: [kernel_GC] --------
[0003]: banner=Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
[0003]: product_str=Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
[0003]: product_version=11.2.0.3.0
[0003]: installed_feature_1=Partitioning
[0003]: installed_feature_2=Real Application Clusters
[0003]: installed_feature_3=OLAP
[0003]: installed_feature_4=Data Mining
[0003]: installed_feature_5=Real Application Testing
[0003]: installed_features_num=5
[0003]: instance_name=SIH2
[0001]: os_name=AIX
[0001]: number_core_cpu=4
--------- GC Source: [Non_Default_Kernel_Parameters] --------
--------- GC Source: [Visible_Default_Kernel_Parameters] --------
========= End of General Configuration ========
----- END DDE Action: 'dumpGenralConfiguration' (SUCCESS, 0 csec) -----
----- START DDE Action: 'dumpKernelDiagState' (Sync) -----
------- Kernel Diag Dump -------
dbkcBSExt: 0
dbkedDefDump info:
Internal err count: 0
Error Flags: 0x0
Exception: FALSE
No Bootstrapping info (SGA is not mapped)
------- END Kernel Diag Dump -------
----- END DDE Action: 'dumpKernelDiagState' (SUCCESS, 0 csec) -----
----- START DDE Action: 'xdb_dump_buckets' (Sync) -----
----- END DDE Action: 'xdb_dump_buckets' (FAILURE, 0 csec) -----
----- START DDE Action: 'dumpKGERing' (Sync) -----
----- END DDE Action: 'dumpKGERing' (SUCCESS, 0 csec) -----
----- START DDE Action: 'dumpKGEState' (Sync) -----
kgepgtfr 0x11083b260
kgepgtba 0x110841a90
kgepgter 0
kgepgpar kgepgbpa 0x1106dfaa4
kgepgepa 0x1106e02a4
kgepgtfd 4
kgepgdmc 0
kgepgflg 0x0
kgepg_stkgfr 0x0
kgepgkgsmp 0x1106df1e0
kgepgspm 4
kgepg_ba_set_in_eh 0x0
kgepg_kgecatch_set_in_eh_ba 0x0
kge_ba_set_in_eh_funcloc 0x0
kge_ba_set_in_eh_fileloc 0x0
------------------- start error stack dump with barriers
<error barrier> at 0x110841a90
------------------- end error stack dump with barriers
----- END DDE Action: 'dumpKGEState' (SUCCESS, 0 csec) -----
----- START DDE Action: 'kpuActionDefault' (Sync) -----
Begin OCI Current State Dump
End OCI Current State Dump
Begin OCI Call Context Dump
End OCI Call Context Dump
Begin Process state dump.
ttcdrvdmplocation: msg-0 ln-0 reporting 0
HST is NULL or no two task connection
End Process state dump.
----- END DDE Action: 'kpuActionDefault' (SUCCESS, 0 csec) -----
----- END DDE Actions Dump (total 0 csec) -----
End of Incident Dump
Any advices please.
Thank you.

Java Plug-In Trace File names

According to this URL, http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html , the plug-in trace file should be named as indicated:
The names of the trace and log files are
plugin<modified version number>.trace
plugin<modified version number>.log
where the <modified version number> includes the major, minor and patch version numbers; e.g., plugin142_06.trace or plugin150.log
But this is not what we're seeing. We see the trace and log files, but here are their names:
plugin28434.trace
plugin28435.log
We are using JRE 1.6.10 on Windows.
We also have the following questions:
1. Is there any way to set the maximum file size for a trace file?
2. Is there a way to set how many backups of the trace file are used?
3. Is there a way to set the rolling behavior of the trace files? Right now, old trace files are re-written completely at random.

Any one has found any solutions ?

Do trace files need to be purged in Oracle 11g DB

We have the Oracle 11g database setup. I have a query as to if it is required to purge the trace files found in adump, Bdump & Cdump administration file subdirectories or there is automatic log rotation of the trace files?
I hope my query is clear that if it is required to manually purge the trace files or is there an automatic log rotation for the trace files.
Please revert with the reply to my query.
Regards

starting with 11g and ADRCI there are two Parameters which controls the purging of old log and / or trace files:
SHORTP_POLICY (default 720 hours) and LONGP_POLICY (default 8720 hours). As with the Default most traces and logs stay an entire year it might be worth changing those values like follows:
adrci> set control (SHORTP_POLICY = 168)
adrci> set control (LONGP_POLICY = 720)
you can verify the current values with
adrci> show control
Unfortunately those parameters are only valid for components managed with ADR (Automatic Diagnostic Repository). So adump or any log locations under $ORACLE_HOME are still not managed automatically.

[10g - XE] Why is my disk full of trace files?

Just in case there's another silly person like me out there who encounters this problem...
I have XE 10g installed on my local machine (Windows XP), as my own personal test environment.
My computer was acting really weird yesterday, then today I got an error while using Excel that my disk was full.... and after some investigating, I discovered that I have 39 GB (gasp!) of trace files! These are all located in the directory C:\oraclexe\app\oracle\product\10.2.0\server\NETWORK\trace
...and some of them are quite large (obviously, since I have 39 GB of them...); one of them by itself is 2 GB.
Almost all of the files are named like: sqlnet_trace.txt_3132_1.trc And, for example, I already have 5 trace files from today, totaling 15 MB.
I vaguely recalled setting my trace level to 16 or SUPPORT a LONG time ago, and funny thing, I couldn't remember changing it back to OFF.
So, if you've been silly like me, check your sqlnet.ora file, and set TRACE_LEVEL_CLIENT=OFF

Thanks for the tip. I checked listener.ora, and it doesn't appear that any trace files are enabled there. I don't know what Net manager is.
At least in this case, the server/database is just my personal PC, so the only person it impacted was me. It took 7 months for the trace files to grow to that size with just me using the database, so I can only imagine what it would do to a database in an actual environment.

Specify a particular node for a trace file to be created

Similar Messages

Maybe you are looking for