Trace files ( .trc ) for Explorer

Hi,
We have trace enabled for our polestar servers and the traces are getting created.
but, the trace files are in .trc format.
i am not sure how to read that format..Can somebody explain me how to read .trc files ?

If webi isn't working either, then its definitely a security issue outside of Explorer. You'll need to check into your authorizations set within BW. I believe the authorizations can be set at different levels, so its possible on field is causing the error. Maybe try to create the report in webi one field at a time until it breaks again. If it doesn't work with any, then there's a higher level authorization that needs to be corrected in BW.
The Information Space is "owned" by the user that created it. However just like a webi or CR document, you can assign security to the object within the CMC. If you go into the properties of the InformationSpace under Manage Spaces > Configure, you'll find the Enterprise folder the Information Space is saved into. By default, I believe they get saved to a favorites folder for the user that created it. But this can be changed to a public folder. Once in a public folder, the users that have rights to view this object will be able to see the Information Space within the Explorer ui.

Similar Messages

Getting trace file names for a conc program

Hi All,
We are using Oracle EBS 11i with Oracle 9i database.
The Apps version is 11.5.9 and database version is Release 9.2.0.6.0.
I am trying to trace a custom program which runs the pl/sql procedure.
I have enabled the tracing in the custom program definition.
This procedure has several blocks inside and also has many commits.
Due to this the SID for the session changes frequently.
Now my question is how can I get all the SIDs for this conc program and get the trace files for each SID.
My goal is to get all the trace file generated for this conc program and use them for analysis.
Any help is appreciated !
Thanks,
DR.

Sending again with formatting.
SELECT c.*, b.accounting_date,
          a.segment1
       || '.'
       || a.segment2
       || '.'
       || a.segment3
       || '.'
       || a.segment4
       || '.'
       || a.segment5 accrual_account
FROM gl_code_combinations a,
       ARCHIVE.ap_ae_headers b,
       ARCHIVE.ap_ae_lines c,
       ARCHIVE.po_distributions d,
       ARCHIVE.ap_invoice_distributions e
WHERE e.po_distribution_id IS NOT NULL
   AND d.po_distribution_id = e.po_distribution_id
   AND c.source_table = 'AP_INVOICE_DISTRIBUTIONS'
   AND c.source_id = e.invoice_distribution_id
   AND b.ae_header_id = c.ae_header_id
   AND b.accounting_date <= :b1
   AND a.code_combination_id = d.accrual_account_id
   AND a.segment3 = '3010'
UNION ALL
SELECT c.*, b.accounting_date,
          a.segment1
       || '.'
       || a.segment2
       || '.'
       || a.segment3
       || '.'
       || a.segment4
       || '.'
       || a.segment5 accrual_account
FROM gl_code_combinations a,
       apps.ap_ae_headers b,
       apps.ap_ae_lines c,
       apps.po_distributions d,
       apps.ap_invoice_distributions e
WHERE e.po_distribution_id IS NOT NULL
   AND d.po_distribution_id = e.po_distribution_id
   AND c.source_table = 'AP_INVOICE_DISTRIBUTIONS'
   AND c.source_id = e.invoice_distribution_id
   AND b.ae_header_id = c.ae_header_id
   AND b.accounting_date <= :b1
   AND a.code_combination_id = d.accrual_account_id
   AND a.segment3 = '3010'
SQL>select * from table(dbms_xplan.display);
| Id | Operation                        | Name                         | Rows | Bytes | Cost | Inst   |IN-OUT|
|   0 | SELECT STATEMENT                 |                               |    20 | 7545 | 7708 |        |      |
|   1 | UNION-ALL                       |                               |       |       |       |        |      |
|   2 |   NESTED LOOPS                   |                               |    19 | 7201 |   825 |        |      |
|   3 |    NESTED LOOPS                  |                               |    19 | 6612 |   787 |        |      |
|   4 |     NESTED LOOPS                 |                               |    93 | 28737 |   694 |        |      |
|   5 |      NESTED LOOPS                |                               |   119 | 32130 |   456 |        |      |
|* 6 |       FILTER                     |                               |       |       |       |        |      |
|   7 |        REMOTE                    |                               |       |       |       | AJINNI | R->S |
|* 8 |       FILTER                     |                               |       |       |       |        |      |
|   9 |        REMOTE                    |                               |       |       |       | AJINNI | R->S |
|* 10 |      FILTER                      |                               |       |       |       |        |      |
| 11 |       REMOTE                     |                               |       |       |       | AJINNI | R->S |
|* 12 |     FILTER                       |                               |       |       |       |        |      |
| 13 |      REMOTE                      |                               |       |       |       | AJINNI | R->S |
|* 14 |    TABLE ACCESS BY INDEX ROWID   | GL_CODE_COMBINATIONS          |     1 |    31 |     2 |        |      |
|* 15 |     INDEX UNIQUE SCAN            | GL_CODE_COMBINATIONS_U1       |     1 |       |     1 |        |      |
| 16 |   NESTED LOOPS                   |                               |     1 |   344 | 6883 |        |      |
| 17 |    NESTED LOOPS                  |                               |     6 | 1878 | 6871 |        |      |
| 18 |     NESTED LOOPS                 |                               |   572 |   156K| 5727 |        |      |
| 19 |      NESTED LOOPS                |                               |   988 |   248K| 3751 |        |      |
|* 20 |       TABLE ACCESS BY INDEX ROWID| AP_AE_HEADERS_ALL             |   978 | 17604 |   817 |        |      |
|* 21 |        INDEX RANGE SCAN          | AP_AE_HEADERS_N3              | 17595 |       |    82 |        |      |
|* 22 |       TABLE ACCESS BY INDEX ROWID| AP_AE_LINES_ALL               |     1 |   240 |     3 |        |      |
|* 23 |        INDEX RANGE SCAN          | AP_AE_LINES_U2                |     8 |       |     2 |        |      |
|* 24 |      TABLE ACCESS BY INDEX ROWID | AP_INVOICE_DISTRIBUTIONS_ALL |     1 |    23 |     2 |
|* 25 |       INDEX UNIQUE SCAN          | AP_INVOICE_DISTRIBUTIONS_U2   |     1 |       |     1 |        |      |
|* 26 |     TABLE ACCESS BY INDEX ROWID | PO_DISTRIBUTIONS_ALL          |     1 |    32 |     2 |        |      |
|* 27 |      INDEX UNIQUE SCAN           | PO_DISTRIBUTIONS_U1           |     1 |       |     1 |        |      |
|* 28 |    TABLE ACCESS BY INDEX ROWID   | GL_CODE_COMBINATIONS          |     1 |    31 |     2 |        |      |
|* 29 |     INDEX UNIQUE SCAN            | GL_CODE_COMBINATIONS_U1       |     1 |       |     1 |        |      |
Predicate Information (identified by operation id):
   6 - filter(NVL("AP_AE_HEADERS_ALL_H"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
   8 - filter(NVL("AP_AE_LINES_ALL_H"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
10 - filter(NVL("AP_INVOICE_DISTRIBUTIONS_ALL_H"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
12 - filter(NVL("PO_DISTRIBUTIONS_ALL_H"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
14 - filter("A"."SEGMENT3"='3010')
15 - access("A"."CODE_COMBINATION_ID"="PO_DISTRIBUTIONS_ALL_H"."ACCRUAL_ACCOUNT_ID")
20 - filter(NVL("AP_AE_HEADERS_ALL"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
21 - access("AP_AE_HEADERS_ALL"."ACCOUNTING_DATE"<=:Z)
22 - filter("AP_AE_LINES_ALL"."SOURCE_TABLE"='AP_INVOICE_DISTRIBUTIONS' AND
              NVL("AP_AE_LINES_ALL"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
23 - access("AP_AE_HEADERS_ALL"."AE_HEADER_ID"="AP_AE_LINES_ALL"."AE_HEADER_ID")
24 - filter("AP_INVOICE_DISTRIBUTIONS_ALL"."PO_DISTRIBUTION_ID" IS NOT NULL AND
              NVL("AP_INVOICE_DISTRIBUTIONS_ALL"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
25 - access("AP_AE_LINES_ALL"."SOURCE_ID"="AP_INVOICE_DISTRIBUTIONS_ALL"."INVOICE_DISTRIBUTION_ID"
26 - filter(NVL("PO_DISTRIBUTIONS_ALL"."ORG_ID",NVL(TO_NUMBER(DECODE(SUBSTRB(:B1,1,1),'
              ',NULL,SUBSTRB(:B2,1,10))),(-99)))=NVL(TO_NUMBER(DECODE(SUBSTRB(:B3,1,1),' ',NULL,SUBSTRB(:B4
27 - access("PO_DISTRIBUTIONS_ALL"."PO_DISTRIBUTION_ID"="AP_INVOICE_DISTRIBUTIONS_ALL"."PO_DISTRIB
28 - filter("A"."SEGMENT3"='3010')
29 - access("A"."CODE_COMBINATION_ID"="PO_DISTRIBUTIONS_ALL"."ACCRUAL_ACCOUNT_ID")
Note: cpu costing is off
67 rows selected.
{code}

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

How to get the trace file name for current running application?

Hi, I want to know if it is possible to get the file name directly for current running application instance which is launched by javaws.
There is a property "deployment.user.logdir" tells the log directory, it would be great if a file name property
is available. something like "instance.trace.file".
Our application wants it because we would like our client send use the application log by clicking a "send error"
button, the codes finds the trace file and compress it and send it by using a smtp server.
In 1.5, we can do it by using a shell program.

I found other asked it before, but I tried to set both properties, but neither works. my sun JRE version :java version "1.6.0_04"
<property
name="deployment.javaws.traceFileName"
value="abcfefsfdsf"/>
<property
name="deployment.javapi.trace.filename"
value="235235235"/>
But it always write to one trace file with name lik javaws63645.trace

Oracle Trace File generation for a session

Hi,
I am using oracle 10g(10.2.0.5) in RHEL5 server. i have used the exec dbms_system.set_sql_trace_in_session(147,3,TRUE); statement to trace a particular session. i am able to trace successfully but i have created a new table in that session where i am not able to find any create table statement in the generated trace file but i can find the insert statements which i performed on the newly created table in the trace file.
Does DDL statements not recorded in the trace events???
Regards,
007

Hi;
Please see below doc which may helps you
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION DOES NOT GENERATE TRACE FOR ACTIVE SESSION [ID 236178.1]
How To Enable SQL Trace for All New Sessions [ID 178923.1]
Tracing Sessions in Oracle Using the DBMS_SUPPORT Package [ID 62160.1]
Regard
Helios

Trace file created for the wrong session

DB version : 10.2.0.3.0
OS version: Solaris 5.10
2 node RAC
Using DBMS_MONITOR.SESSION_TRACE_ENABLE, I have been trying to trace an oracle session spawned by a C++ application.
So, i determined which instance this session is connected by querying gv$session. I logged in as SYS in that instance's Node and then issued
execute dbms_monitor.session_trace_enable(4371,98124, true, false);After enabling, i saw new A trace file being generated. But this trace is actually tracing SYS's session which executed dbms_monitor.session_trace_enable and not the session (4371,98124) !!! I tested few basic queries in SYS's session like
select sysdate from dualAnd i can see all these queries appearing in the trace file. What could be the cause of this issue?
I have noticed that
SHARED_SERVERS = 1 on both nodes. Is this causing this weird issue? For tracing, If i disable SHARED_SERVERS using
alter system set SHARED_SERVERS = 0
will it cause any connection problems for the client applications because of their tnsnames.ora file setting?

John_75 wrote:
Thank you DBMS_DIRECT.
trace is enabled only on the instance to which the caller is connected
So, how do i enable tracing for sessions spawned by Java or C++ applications.
According to the documentation, i can use DBMS_MONITOR for tracing applications
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm
Your 2 node RAC has two instances (e.g. INST1 and INST2). My understanding of that is that with the above command, to be able to trace session 123 connected to INST1, your SYS need to be connected to INST1. To be able to trace session 456 connected to INST2, your SYS need to be connected to INST2.

Trace file analysis: High cpu timings for FETCH

Hi!
I am doing a 10046 trace file analysis for a performance problem we see on a customer site, but we can't reproduce the problem on our local reference test system.
Basically, the cpu timings for FETCH calls for a SELECT statement are ten times as high on the customer system. There are no WAIT events in the trace file (for this statement), only a high cpu timing for the FETCHES:
Customer instance:
FETCH #19:c=140625,e=140189,p=0,cr=3358,cu=0,mis=0,r=1,dep=1,og=1,tim=1500177409
Reference system;
FETCH #4:c=15625,e=7984,p=0,cr=2262,cu=0,mis=0,r=1,dep=1,og=1,tim=5624714062
I see that the number of consistant reads is 50% higher, but I don't see why this result in 10 times the CPU time and about 20 times the elapsed time. This is does not seem to be a general problem with all statements, so the general timings are comparable to our reference system. The problem seems to be this Select statement only which only joins two tables.
I had the idea that a long running transaction that didn't commit would lead to this problem, since Oracle would need to reconstruct blocks from undo, but there are no such transactions on the system.
With no WAIT events emitted, where does the time go?
Thanks for your help,
Marcus

MMarcus wrote:
Here is the execution plan for the query. It is the same on both systems, with slightly different total costs (8 or 10).
| Id | Operation                      | Name                | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                     |     1 |    35 |    10 (10)| 00:00:01 |
|   1 | SORT ORDER BY                 |                     |     1 |    35 |    10 (10)| 00:00:01 |
|* 2 |   FILTER                       |                     |       |       |            |          |
|* 3 |    TABLE ACCESS BY INDEX ROWID | PLANHIERARCHIE      |     1 |    35 |     5   (0)| 00:00:01 |
|* 4 |     INDEX RANGE SCAN           | PLANHIERARCHIEINDEX |    21 |       |     2   (0)| 00:00:01 |
|   5 |    NESTED LOOPS                |                     |     1 |    39 |     4   (0)| 00:00:01 |
|* 6 |     TABLE ACCESS BY INDEX ROWID| PLANSCHRITTFOLGE    |     1 |    21 |     3   (0)| 00:00:01 |
|* 7 |      INDEX RANGE SCAN          | PLANSCHRITTFOLGEPK |    11 |       |     2   (0)| 00:00:01 |
|* 8 |     TABLE ACCESS BY INDEX ROWID| PLANHIERARCHIE      |     1 |    18 |     1   (0)| 00:00:01 |
|* 9 |      INDEX UNIQUE SCAN         | PLANHIERARCHIEPK    |     1 |       |     0   (0)| 00:00:01 |
You have omitted the predicate section from the execution plan - and [+*there may be important clues*+|http://jonathanlewis.wordpress.com/2008/12/03/predicate-problems/] in the predicate section.
In your case the problem may +(*for example*+) simply be the way in which the predicates apply to the PLANSCHRITTFOLGEPK index range scan.
Imagine you have 250 index entries per leaf block, and the predicates that apply to the index identify an index range scan that spans 25 entries in one system but 25000 entries (100 leaf blocks) in the other. It is possible that filter predicates against the index eliminate most of the index entries before you go to the table. The CPU used to examine (filter) large numbers of index leaf entries can be significant - and since that index range scan is part of a filter subquery it could many several time - escalating the CPU usage. A check of the access and filter predicates may give you some clue about whether you are seeing that type of problem.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

SQL Developer generates strange trace files on server

Hello out there,
I observed the generation of some strange trace files on the database server (Oracle 11.0.2.0.2 64bit on Win 2008R2).
Whenever I start SQL Developer (3.2.20.09.87 64bit with JDK 1.7.0_17 64bit on Win7 64bit) for each connection I defined one trace file like this is generated:
Trace file C:\ORACLE\diag\rdbms\ora\ora\trace\ora_ora_8500.trc
Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
Windows NT Version V6.1 Service Pack 1
CPU : 2 - type 8664, 2 Physical Cores
Process Affinity : 0x0x0000000000000000
Memory (Avail/Total): Ph:990M/3959M, Ph+PgF:3743M/7918M
Instance name: ora
Redo thread mounted by this instance: 1
Oracle process number: 23
Windows thread id: 8500, image: ORACLE.EXE (SHAD)
*** 2013-03-06 08:04:13.842
*** CLIENT ID:() 2013-03-06 08:04:13.842
*** SERVICE NAME:() 2013-03-06 08:04:13.842
*** MODULE NAME:() 2013-03-06 08:04:13.842
*** ACTION NAME:() 2013-03-06 08:04:13.842
Breaking the connection before proto/dty negotiation, error raised 3113I enabled listener log to find out the origin of this and it contains lines like the following:
06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49320)) * establish * ora.vu * 0
06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49322)) * establish * ora.vu * 0
06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49323)) * establish * ora.vu * 0
06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49325)) * establish * ora.vu * 0
06-MRZ-2013 08:04:14 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49329)) * establish * ora.vu * 0
06-MRZ-2013 08:04:14 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49331)) * establish * ora.vu * 0The IP address is mine and I have excatly 6 connections defined for that server. On other servers, similar trace files are generated, one for each connection in my SQL Developer.
This also occurred with JDK 1.6 so I don't think it's a Java issue.
Besides the generation of the trace files there seem to be no other problems.
Any ideas?

Hi,
I think Srini is probably correct. The noted bug applies to 11.2.0.1 and up, is fixed in 12c, and included in an 11.2.0.3 patch. However the version of SQL Developer also affects the creation of trace files on product startup (prior to any user initiated db connect attempts).
For example,
A. SQL Developer 3.1.07.42 - no such trace files created.
B. SQL Developer 3.2.20.09.87 - such trace files created for 11.2.0.1 connections, but not 10g XE or 12c connections.
So I presume an OCIServerAttach call got added in 3.2.2, not sure in support of which feature, but the bug will only impact users of 11.2.0.1, 11.2.0.2, and unpatched 11.2.0.3 DB releases.
Regards,
Gary
SQL Developer Team

Naming trace file

I have generated many trace files for analysis using tkprof. However, I have a difficulty in locating the exact trace file (.trc) from 100s of trace files. Naming my trace file will save time. Is there a way to name the trace file when I start tracing? (i.e. when I set sql_trace to true).
thanks
Srinidhi Rao

You can use tracefile_identifier feature:
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'traceid';When this parameter value is set, the trace file name has the following format:
sid_ora_pid_traceid.trc
Best Regards,
Gokhan
If this question is answered, please mark appropriate posts as correct/helpful and the thread as closed. Thanks

Trace file not found

using linux 5.7 (32bit) and oracle 11g relase 2
SQL> select name,value from v$diag_info;
NAME
VALUE
Diag Enabled
TRUE
ADR Base
/home/oracle/u01/app/oracle
ADR Home
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4
NAME
VALUE
Diag Trace
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/trace
Diag Alert
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/alert
Diag Incident
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/incident
NAME
VALUE
Diag Cdump
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/cdump
Health Monitor
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/hm
Default Trace File
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/trace/looking4_ora_4327
.trc
NAME
VALUE
Active Problem Count
0
Active Incident Count
0
11 rows selected.
now when i check
ls -al looking4_ora_43*
-rwxrwxr-x 1 oracle oinstall 2960 Aug 22 09:59 looking4_ora_4300.trc
-rwxrwxr-x 1 oracle oinstall 182 Aug 22 09:59 looking4_ora_4300.trm
-rwxrwxr-x 1 oracle oinstall 2957 Aug 17 10:29 looking4_ora_4306.trc
-rwxrwxr-x 1 oracle oinstall 180 Aug 17 10:29 looking4_ora_4306.trm
-rw-r----- 1 oracle oinstall 2957 Aug 30 10:38 looking4_ora_4325.trc
-rw-r----- 1 oracle oinstall 181 Aug 30 10:38 looking4_ora_4325.trm
-rw-r----- 1 oracle oinstall 2956 Aug 24 15:56 looking4_ora_4380.trc
-rw-r----- 1 oracle oinstall 181 Aug 24 15:56 looking4_ora_4380.trm
-rwxrwxr-x 1 oracle oinstall 2942 Aug 14 10:18 looking4_ora_4394.trc
-rwxrwxr-x 1 oracle oinstall 178 Aug 14 10:18 looking4_ora_4394.trm
[oracle@unknown485b39d0b515 trace]$ pwd
/home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/trace
so where is
looking4_ora_4327??
thanks in advance

There is no trace file at your /home/oracle/u01/app/oracle/diag/rdbms/looking4/looking4/trace/looking4_ora_4327, because your current user's session is not being under tracing. See example below :
I logged in as scott user and below is the output :
SQL> column value for a50;
SQL> /
NAME                                                             VALUE
Diag Enabled                                                     TRUE
ADR Base                                                         e:\app\serverroom
ADR Home                                                         e:\app\serverroom\diag\rdbms\orcl\orcl
Diag Trace                                                       e:\app\serverroom\diag\rdbms\orcl\orcl\trace
Diag Alert                                                       e:\app\serverroom\diag\rdbms\orcl\orcl\alert
Diag Incident                                                    e:\app\serverroom\diag\rdbms\orcl\orcl\incident
Diag Cdump                                                       e:\app\serverroom\diag\rdbms\orcl\orcl\cdump
Health Monitor                                                   e:\app\serverroom\diag\rdbms\orcl\orcl\hm
Default Trace File                                               e:\app\serverroom\diag\rdbms\orcl\orcl\trace\orcl_
                                                                 ora_8056.trcIt means, if my session is being trace, then I have to check e:\app\serverroom\diag\rdbms\orcl\orcl\trace\orcl_ora_8056.trc file for this session right? Ok, what if I log out and re-connect :
NAME                                                             VALUE
Diag Enabled                                                     TRUE
ADR Base                                                         e:\app\serverroom
ADR Home                                                         e:\app\serverroom\diag\rdbms\orcl\orcl
Diag Trace                                                       e:\app\serverroom\diag\rdbms\orcl\orcl\trace
Diag Alert                                                       e:\app\serverroom\diag\rdbms\orcl\orcl\alert
Diag Incident                                                    e:\app\serverroom\diag\rdbms\orcl\orcl\incident
Diag Cdump                                                       e:\app\serverroom\diag\rdbms\orcl\orcl\cdump
Health Monitor                                                   e:\app\serverroom\diag\rdbms\orcl\orcl\hm
Default Trace File                                               e:\app\serverroom\diag\rdbms\orcl\orcl\trace\orcl_
                                                                 ora_8752.trcIt means, now I shall look into e:\app\serverroom\diag\rdbms\orcl\orcl\trace\orcl_ora_8752.trc for any tracing info; only if it is being trace see :
SQL> host dir e:\app\serverroom\diag\rdbms\orcl\orcl\trace\orcl_ora_8752.trc;
Volume in drive E is HCL_DISK3
Volume Serial Number is A62A-F491
Directory of e:\app\serverroom\diag\rdbms\orcl\orcl\trace
File Not Found
SQL> alter session set events '10046 trace name context forever,level 12';
Session altered.
SQL> host dir e:\app\serverroom\diag\rdbms\orcl\orcl\trace\orcl_ora_8752.trc;
Volume in drive E is HCL_DISK3
Volume Serial Number is A62A-F491
Directory of e:\app\serverroom\diag\rdbms\orcl\orcl\trace
30-08-2012 13:39                 0 orcl_ora_8752.trc
               1 File(s)              0 bytes
               0 Dir(s) 121,181,003,776 bytes free
SQL> alter session set events '10046 trace name context off';
Session altered.
SQL> host dir e:\app\serverroom\diag\rdbms\orcl\orcl\trace\orcl_ora_8752.trc;
Volume in drive E is HCL_DISK3
Volume Serial Number is A62A-F491
Directory of e:\app\serverroom\diag\rdbms\orcl\orcl\trace
30-08-2012 13:39                 0 orcl_ora_8752.trc
               1 File(s)              0 bytes
               0 Dir(s) 121,181,003,776 bytes free
SQL>So, in short, you will only get the trace file, if the current session is under tracing.
Regards
Girish Sharma

Generate Trace file when doing RMAN

OS AIX 5.3L with Oracle 10g (10.2.0.1), Since beginning of the RMAN backup, the Oracle generated trc file in udump and it is quite big ( over my dump_file_size limit). According to Metalink, it is a bug (Bug:4529700), since 2005 and it seems happening to all platforms. So does this bug have patch yet? How can I aovid the dump trace file to avoid exploring the storage directory?

Here is first 30 lines
$ head -30 baan_ora_2654306.trc
Dump file /oracleapp/apps/admin/baan/udump/baan_ora_2654306.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracleapp/apps/oracle/product/10.2.0/db_1
System name: AIX
Node name: baan
Release: 3
Version: 5
Machine: 000D6DB6D600
Instance name: baan
Redo thread mounted by this instance: 1
Oracle process number: 23
Unix process pid: 2654306, image: oracle@baan (TNS V1-V3)
*** ACTION NAME:(0000001 STARTED1) 2007-07-12 03:00:09.240
*** SERVICE NAME:(SYS$USERS) 2007-07-12 03:00:09.240
*** SESSION ID:(1078.11893) 2007-07-12 03:00:09.240
ksfqxc:ctx=0x106a29f0 flags=0x30000000 dev=0x0 lbufsiz=1048576 bp=0x10566548
*** ACTION NAME:(0000008 STARTED1) 2007-07-12 03:00:18.381
ksfqxc:ctx=0x106a29f0 flags=0x30000000 dev=0x0 lbufsiz=1048576 bp=0x10566548
*** 2007-07-12 03:00:20.267
*** ACTION NAME:(0000013 STARTED62) 2007-07-12 03:00:20.267
ksfqfret:ctx=0x106a29f0 filename=/remote/solar/flash_recovery/baan_standby/baan627362170_82_1.bkf blksiz=8192 startblk=1
ksfqqrd:offset=1 nblocks=127 filsiz=194148
ksfqrd:ctx=0x106a29f0 nblocks=0 wait=1
ksfqrd:buf=0x10aec000 offset=1 blksread=127
*** ACTION NAME:(0000014 STARTED62) 2007-07-12 03:00:21.112
ksfqfret:ctx=0x106a29f0 filename=/remote/solar/flash_recovery/baan_standby/baan627363196_83_1.bkf blksiz=16384 startblk=1
ksfqqrd:offset=1 nblocks=63 filsiz=75
ksfqrd:ctx=0x106a29f0 nblocks=127 wait=1
...(and bottom of 20 lines)
ksfqrd:ctx=0x1065cc08 nblocks=0 wait=0
ksfqrd:buf=0x1172c000 offset=217601 blksread=64
ksfqrd:ctx=0x107cfae8 nblocks=0 wait=0
ksfqrd:buf=0x1196c000 offset=89601 blksread=64
ksfqrd:ctx=0x108dc440 nblocks=0 wait=0
ksfqrd:ctx=0x108dc440 nblocks=0 wait=1
ksfqrd:buf=0x10bfc000 offset=473665 blksread=64
ksfqrd:ctx=0x10adc538 nblocks=0 wait=0
ksfqrd:buf=0x10e9c000 offset=217665 blksread=64
ksfqrd:ctx=0x1069dff8 nblocks=0 wait=0
ksfqrd:buf=0x110ec000 offset=217665 blksread=64
ksfqrd:ctx=0x1069ccc8 nblocks=0 wait=0
ksfqrd:buf=0x1132c000 offset=217665 blksread=64
ksfqrd:ctx=0x1065df38 nblocks=0 wait=0
ksfqrd:buf=0x1157c000 offset=217665 blksread=64
ksfqrd:ctx=0x1065cc08 nblocks=0 wait=0
ksfqrd:buf=0x117bc000 offset=217665 blksread=64
ksfqrd:ctx=0x107cf
*** DUMP FILE SIZE IS LIMITED TO 5242880 BYTES ***
because of the limit of my dump_file_size, so it stopped and Oracle generates another small one.
and these trace file always were generated at the end of the RMAN backup.
If you read the bottom of the note, it mention the bug: 4529700 -- Trace File Created During Rman Database Backup and in that note: it gave an example content of the file. You probably refereed to another bug: 4596065, which generated an empty trace.

Start/stop trace between removing trace files

Hi,
I have the following problem.
I put some Oracle session on trace (I use sys.dbms_support.start_trace_in_session). Then I make some test. I close the trace (I use sys.dbms_support.stop_trace_in_session). I analyze the trace files (tkprof) and I make some tuning.
Then I'd like to remove the trace files (*.trc) and start the trace again for checking if the tuning was efficient.
It seems not possible. Event if I start the trace again I can't see and trc files.
In order to solve the problem I must to bounce the application I want to trace (so that the Oracle sessions start again).
Any hint?
Thanks, Max

In that case, you will need to parse the trace file to identify the start and stop of the trace. Below is an example from a 10gR2 trace. Notice the line starting with the *** that contains the date. It comes between the stop of the trace and the start of another trace. You cannot use this line alone to signify the start of a trace as similar lines are emitted in the trace file when there are long delays between writes to the file.
=====================
PARSING IN CURSOR #2 len=55 dep=0 uid=0 oct=42 lid=0 tim=330900979 hv=2217940283 ad='2fdd5ef8'
alter session set events '10046 trace name context off'
END OF STMT
PARSE #2:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=330900976
BINDS #2:
EXEC #2:c=0,e=85,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=330901247
*** 2007-02-20 11:55:55.026
=====================
PARSING IN CURSOR #4 len=69 dep=0 uid=0 oct=42 lid=0 tim=386816222 hv=3164292706 ad='2fdd6980'
alter session set events '10046 trace name context forever, level 12'
END OF STMT
EXEC #4:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=386816218
WAIT #4: nam='SQL*Net message to client' ela= 2 driver id=1111838976 #bytes=1 p3=0 obj#=258 tim=386816593
WAIT #4: nam='SQL*Net message from client' ela= 105 driver id=1111838976 #bytes=1 p3=0 obj#=258 tim=386816748
=====================

Name of trace file from trace enabled concurrent program

Hi all,
I am looking for a sql script or method to find the name of a trace file in udump for trace enabled concurrent programs. I know the trace files show 11i logon (user_name from fnd_user) in the name of the trace file but I am looking for a sql that would give the exact name of the raw trace file with request id as input.
I have 11.5.10.2.
Any help?
Thanks,

Please see these docs.
11i-How to find the Trace file generated for a concurrent program [ID 270446.1]
How to find the Trace file generated for a concurrent program? [ID 967966.1]
FAQ: Common Tracing Techniques within the Oracle Applications 11i/R12 [ID 296559.1]
Thanks,
Hussein

.wid file opens for some developers Web Intell Rich Client but not others

4 developers with same BO client installs @ 12.2.7.598** (server at 3.2 SP 2.7)
2 can read demo .wid files and 3rd party supplied .wid file, 2 cannot!*
Error produced when running:
An internal error occured while calling 'openDocumentMDP' API. (Error: ERR_WIZ_30270).
Last few lines of Trace file produced for the 2 that cannot run the .wid(s):.
ERROR COMPONENT="WIS" ERRORCODE="30270" ERRORTYPE="USER" MESSAGE="An internal error occured while calling 'openDocumentMDP' API. (Error: ERR_WIS_30270)" PREFIX="ERR">
<DEBUGINFO BORESULT="5" FILENAME="kdgWICDZ_i2.cpp" LINEPOSITION="792" MODULENAME="WICDZServer_i"/>
<REQUESTINFO COMMANDID="" COMMANDNAME="" DPID="" DPLONGNAME="" DPNAME=""/>
-Tried removing all files under LocData, the error still produces and
creates a new trace file.
-tried 2 that can open .wid to "open and save for all" a .wid and send back to us 2 that can't open, still no success
Please Advise,
MAC

Hi,
First of all, you'll need to work out if the problem is install/machine based, or user-based. Get the users than can't open the file to log in on the machines of the two people that can open the report. What happens?
If they can open the report on the other machine, it's a client issue, I'd suggest a double-check that the versions match and/or a re-install.
If they can't open the reports on the other machines then it's a server/user problem. Either examine the user accounts to identify the differences, or just re-create the users from scratch to match the two users who can open the reports.

Trace files being truncated after 18mb

I have enabled trace file debugging for my application and after the trace file has reached approx 18mb, it stops writing to the file. Im also doing logging and the log file is usually around 80mb. Is there some sort of maximum file size restriction? How do I fix this?

You gave almost no details but as a general statement there are no limits on file sizes, at least with the size of files you're dealing with. Some O/S's and file systems might have an issue after 2GB.
What is your application? What kind of logging does it use (i.e. log4j, jdk logging, etc). What O/S are you on? How much free disk space do you have?

Trace files ( .trc ) for Explorer

Similar Messages

Maybe you are looking for