trace file question

Hi Master,

Please help me understand the TKProf file. How to identify what / my query takes a lot of time in the trace file. Trace file with over 100 queries. How can I understand?

Please advise me.

Concerning

TKProf utility takes sorting option, you can sort your queries using exeela (run time) or other people and find that question / questions first.

Tags: Database

Similar Questions

Question about errors stored in our trace files

DB version: 12.1.0.2.5 Linux
I'm looking for trace files for one of our production database and I see entries that are similar to the following:
kjgcr_StatCheckLCP: getweinfo returned error, kjzsret = 0 x 0
I Googled, searched this forum and the research in the MOD and I can't find what it means.
Does anyone have an idea of what they show?
Thank you
Thomas

Thomas Morgan wrote:

DB version: 12.1.0.2.5 Linux

I'm looking for trace files for one of our production database and I see entries that are similar to the following:

kjgcr_StatCheckLCP: getweinfo returned error, kjzsret = 0 x 0

I Googled, searched this forum and the research in the MOD and I can't find what it means.

Does anyone have an idea of what they show?

Thank you

Thomas

submit the Service request to MOS

Cannot generate the SQL * Net trace file on Linux

Oracle 11 g 1 material
RHEL 6.3
--------------------
SQLNET.ora file:
SQLNET. AUTHENTICATION_SERVICES = (DOB, TCPS, NTS)
SSL_VERSION = 0
SSL_CLIENT_AUTHENTICATION = TRUE
SSL_CIPHER_SUITES = (SSL_RSA_EXPORT_WITH_RC4_40_MD5)
LOG_DIRECTORY_CLIENT = / home/oracle
LOG_FILE_CLIENT = SQLNET.log
TRACE_DIRECTORY_CLIENT = / home/oracle
TRACE_FILE_CLIENT = SQLNET.trc
DIAG_ADR_ENABLED = OFF
TRACE_UNIQUE_CLIENT = WE
The sqlnet.ora file above does not create a trace file when you try to use SQL * more to connect to the remote database.
What could be the problem? (The user has write access to the directory where the log file and the Commission of truth and reconciliation must be created)

Answered my own question. It was that o/s was THAT RHEL 5.3 and that caused some compatibility problems. Updated to 6.5 and all is fine.

How simple extraction do more consistent results in trace file,

Hello Experts,
In my trace file, one thing I don't understand is clearly why a single extraction contains more than 1 get consistent results? Can someone just explain this please? As you can see only the first and the last extraction get over a uniform result (cr = 5, cr = 2).
Is this possible? Why is that?
My last question is to make recursive calls is the value of cr (consisten GETS) increase? If so, what fetch is done of this? first? second? third?

=====================

PARSING IN CURSOR #2 len = 23 dep = uid 0 = 85 oct = cover 3 = 85 tim = hv 2197698804 = ad 4069246757 = "7ff5f323410" sqlid = "f34thrbt8rjt5."

Select * from employees

END OF STMT

ANALYSIS # 2: c = 0, e = 80, p = 0, cr = 0, set cu = 0, = 0, r = 0, dep = 0, og = 1, plh is 1445457117, tim = 2197698803

# 2 EXEC: c = 0, e = 37, p = 0, cr = 0, set cu = 0, = 0, r = 0, dep = 0, og = 1, plh is 1445457117, tim = 2197698938

WAITING #2: nam ='SQL * Net message to client' ela = driver id 6 = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197699018

FETCH # 2: c = 0, e = 92, p = 0,cr = 5, cu = 0, = 0, r = 1, dep = 0, og = 1, plh is 1445457117, tim = 2197699158

WAITING #2: nam ='SQL * Net client message' ela = 464 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197699670

WAITING #2: nam ='SQL * Net message to client' ela = 2 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197699751

FETCH # 2: c = 0, e = 92, p = 0, cr = 1, cu = 0, = 0, r = 15, dep = 0, og = 1, plh is 1445457117, tim = 2197699827

WAITING #2: nam ='SQL * Net client message' ela = driver id 10342 = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197710219

WAITING #2: nam ='SQL * Net message to client' ela = 4 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197710375

FETCH # 2: c = 0, e = 82, p = 0, cr = 1, cu = 0, = 0, r = 15, dep = 0, og = 1, plh is 1445457117, tim = 2197710435

WAITING #2: nam ='SQL * Net client message' ela = 6642 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197717124

WAITING #2: nam ='SQL * Net message to client' ela = 3 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197717210

FETCH # 2: c = 0, e = 59, p = 0, cr = 1, cu = 0, = 0, r = 15, dep = 0, og = 1, plh is 1445457117, tim = 2197717249

WAITING #2: nam ='SQL * Net client message' ela = 5954 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197723240

WAITING #2: nam ='SQL * Net message to client' ela = 2 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197723350

FETCH # 2: c = 0, e = 53, p = 0, cr = 1, cu = 0, = 0, r = 15, dep = 0, og = 1, plh is 1445457117, tim = 2197723389

WAITING #2: nam ='SQL * Net client message' ela = 5356 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197728775

WAITING #2: nam ='SQL * Net message to client' ela = 1 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197728843

FETCH # 2: c = 0, e = 54, p = 0, cr = 1, cu = 0, = 0, r = 15, dep = 0, og = 1, plh is 1445457117, tim = 2197728882

WAITING #2: nam ='SQL * Net client message' ela = 5827 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197734740

WAITING #2: nam ='SQL * Net message to client' ela = 3 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197734899

FETCH # 2: c = 0, e = 83, p = 0, cr = 1, cu = 0, = 0, r = 15, dep = 0, og = 1, plh is 1445457117, tim = 2197734956

WAITING #2: nam ='SQL * Net client message' ela = 6038 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197741053

WAITING #2: nam ='SQL * Net message to client' ela = 2 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197741166

FETCH # 2: c = 0, e = 117, p = 0, cr = 2, set cu = 0, = 0, r = 15, dep = 0, og = 1, plh is 1445457117, tim = 2197741264

WAITING #2: nam ='SQL * Net client message' ela = 4365 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197745665

WAITING #2: nam ='SQL * Net message to client' ela = 1 driver id = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2197745714

FETCH # 2: c = 0, e = 37, p = 0,cr = 2, cu = 0, = 0, r = 1, dep = 0, og = 1, plh is 1445457117, tim = 2197745738

"STAT #2 = 1 cnt = 107 pid = 0 pos = 1 obj id = 73948 op ='TABLE ACCESS FULL EMPLOYEES (cr = 15 pr = 0 pw = time 0 = 0 cost = US size 3 = 7383 card = 107)"

2014-01-04 23:34:20.251

WAITING #2: nam ='SQL * Net client message' driver ela = id 4200655 = 1111838976 #bytes = 1 p3 = 0 obj #=-1 tim = 2201946471

ISSUE # 2: c = 0, e = 32, dep = 0, type = 0, tim = 2201946695

=====================

Thanks in advance.

Franck,

Looks like you think of the freelist management.

Under the SAMS, the cr number gets reported in the first extraction could be much higher - probably up to 16 - and it still is missing a number of visits due to the segment header block and the blocks of space management. Unfortunately I don't know of a mechanism to track the visit of each block in 11g (which I think is using the OP).

Concerning

Jonathan Lewis

filling on server trace files

11.1.0.7 - 64-bit on Solaris
It seems tracing has been enabled on our database in the last week that trace the directory is to fill to the top.
However, it is what it is to show:
SQL > wear track of parameter
VALUE OF TYPE NAME
------------------------------------ ----------- ------------------------------
log_archive_trace integer 0
sec_protocol_error_trace_action string PATH
SQL_Trace boolean FALSE
trace_enabled Boolean TRUE
tracefile_identifier chain
It seems 11g have trace_enabled set to true by default.
My question is how can I find out who a session is drawn?
Thank you

Thank you all for your contributions.

It is now resolved by disabling tracking tab Top consumer of the control (GC) 11g of the grid as it was where he seems to be activated in the first place.

It has been activated for upper module which was the main application module and it was written several trace files every minute.

It would have been very difficult to resolve outside GC where it has been activated and it's a simple click is enough to accomplish on GC.

Thank you all

Phase of extraction in a trace file

Oracle version: 11.2.0.3.0 Enterprise Edition
Operating system - IBM/AIX RISC System/6000

I'm trying to generate a trace file from a piece of code executed by the java server. What I asked the java developer to do is to place this block immediately after a connection is established:

BEGIN
  EXECUTE IMMEDIATE 'ALTER SESSION SET TRACEFILE_IDENTIFIER = ''M1''';
  dbms_monitor.session_trace_enable(waits => FALSE, binds => TRUE);
END;

And at the end of the block of logic java code:

BEGIN
  dbms_monitor.session_trace_disable;
END;

I want to know is how many lines the java Server recovers after executing a particular select statement, because they complain about getting less account lines select statement waits.
For example, if I run the same query sql in the sqlplus session, then we'll, I extract say 1000 rows.
When the same query is executed on the side of java, the lines of recoveries are less in number, let's say 500.
And because I doubt it, I wanted to trace to see what is actually executed and how.
The extract of the trace file I see exactly the same query that I myself run in a sqplus session.
There is no precise control over the udnerlying tables in the query.

And my question is, how to interpret the phase EXTRACTION of the slider (for the select statement)?
For example, if I see a FETCH for this cursor, this means that the java server retrieves a single row?
If I see 100 extractions, this means that they recovered 100 lines of the cursor?

Here's a short excerpt from the trace file (please don't crucify me for obvious denormalized tables design, and the request it is not invented by me):

PARSING IN CURSOR #4573587152 len=667 dep=0 uid=737 oct=3 lid=737 tim=17685516462413 hv=954980718 ad='70000006d3e4940' sqlid='69pm96nwfrqbf'
select /* ordered */ o.id, nvl(o.par_id, -1) as par_id, o.NAME_GER, o.NAME_ENG, o.NAME_ESP, o.NAME_ITL,o.NAME_FRA, decode(lo.lflag, 'Y', 'L', 'N') as leaf_or_node, lo.distance + 1 as "LEVEL",  to_char(o.beg_date, 'DD.MM.YYYY HH24:MI:SS'),  o.mais_id, l.path, nvl(o.non_selectable, 'N')  from   st_prod o, lprod_new l, lprod lo where  o.end_date = to_date('31.12.3999', 'DD.MM.YYYY') and   (lo.id, lo.beg_date) in (select id, beg_date from st_prod where par_id is null and end_date = to_date('31.12.3999', 'DD.MM.YYYY')) and   lo.lid = o.id and lo.lid_beg_date = o.beg_date and   l.st_prod_id = o.id and l.st_prod_beg_date = o.beg_date order by lo.distance, o.name_ger
END OF STMT
PARSE #4573587152:c=31,e=152,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2027551050,tim=17685516462412
EXEC #4573587152:c=80,e=375,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2027551050,tim=17685516462936

*** 2013-03-11 11:28:09.122
FETCH #4573587152:c=519446,e=892645,p=0,cr=113446,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517355715
FETCH #4573587152:c=37,e=59,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517359109
FETCH #4573587152:c=39,e=63,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517361128
FETCH #4573587152:c=29,e=46,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517362849
FETCH #4573587152:c=31,e=48,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517364621
<162 more FETCH-es here>
<STAT phase>
CLOSE #4573587152:c=533,e=849,dep=0,type=1,tim=17685517671878

It is possible based on the trace file (if I have to change something in the way of tracing) to determine the number of rows retrieved?

FETCH #4573587152:c=519446,e=892645,p=0,cr=113446,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517355715
FETCH #4573587152:c=37,e=59,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517359109
FETCH #4573587152:c=39,e=63,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517361128
FETCH #4573587152:c=29,e=46,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517362849
FETCH #4573587152:c=31,e=48,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517364621

Each FETCH call returns r = number of lines.

Run TKPROF trace file for a readable activity summary.

How to interpret the phase EXTRACTION of the slider (for the select statement)?

The java code uses a default fetchsize to 10 (lines per extraction).

I can control the Trace files in bdump
Experts in good morning...

Question of BDUMP

In BDUMP, I have the following files...

-rw - r - 1 oracle oinstall 112687 19 Feb 13:41 alert_testdb.log
-rw - r - r - 1 oracle oinstall 33068 Feb 19 12:03 alert_TSH1.log
-rw - r - 1 oracle oinstall 20301 14 Feb 09:13 testdb_arc0_15379.trc
-rw - r - 1 oracle oinstall 632 5 Feb 04:56 testdb_arc0_17339.trc
-rw - r - 1 oracle oinstall 2118 Feb 5 05:22 testdb_arc0_17409.trc
... ..
.... ..

Totally 294 trace files...

I checked some .trc files; Almost have the same information.

ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
Name of the system: Linux
Name of the node: xxxxxxxxxxxxxx
News Release: xxxxxxxxxxxxxxxxxxxxxxxxxx
Version: xxxxxxxxxxxxxxxxxxxxxxxxx
Machine: xxxxxx
Instance name: testdb
Redo thread mounted by this instance: 1
Oracle process number: 0

My question clear is:

1. If the alert log contains details of the error, what is the purpose of trace in bdump files?
2. why "n" no trace files created without useful information? (Almost with the same information]
3. what type of information is usually stored in .trc files?

What I know about tracefiles:

Each background process writes the trace files if an internal error has occurred.
If I'm wrong, please correct.
Trace files and log alerts serve a different purpose. A simple way to think about it, is that the trace files are used when diagnosing problems. The alert log shows you what are the events are occurring in the database in general, flooding you don't not with unnecessary details. If the database crashed, the alerts log will tell you when the event happened, but the details of the process that crashed would be (I hope) in a trace file.

Some trace files are huge, and you certainly don't want them in the log of alerts because it would make it too big to be manageable or read.

For example, if a process crashes, the dumping process trace file to would be useful when you are working with Oracle Support to identify the problem. Or, if you want to see what a specific session, you can turn on tracing on it and and then format the trace with tkprof file to understand what made the session.

The documentation is a good summary:

Trace files

A trace file is an administrative file containing diagnostic data used to investigate the problems. Trace can also, provide guidance for tuning applications or an instance, as explained in "Diagnostic and performance optimization.

Types of Trace files

Each server and the background process can periodically write to a trace file. File information on the environment in the process, status, activities and errors.

The SQL trace facility also created trace files, which provide information of performance on individual SQL statements. To enable tracing for an identifier of the client, service, module, action, session, instance or database, you must run the procedures in the DBMS_MONITOR package or use Oracle Enterprise Manager.

A dump is a special type of trace file. Considering that track tends to be out of diagnostic data, a dump is usually a unique data output of diagnosis in response to an event (for example, an incident). When an incident occurs, the database writes one or more landfills in the incident directory created for the incident. Incident of discharges also contain the case number in the file name.

Blocker withdraws the deadlock trace file (self)

Hello

Recently, I had a problem on a 10.2.0.4 database to single instance where blockages are produced. The following test case reproduced the problem (I create three tables parent, a child table with foreign keys indexed to all parents three tables and a procedure that performs an insert in the child table in a standalone transaction):

create table parent_1(id number primary key);

create table parent_2(id number primary key);

create table parent_3(id number primary key);
 
create table child( id_c number primary key,
                   id_p1 number,
                   id_p2 number,
                   id_p3 number,
                   constraint fk_id_p1 foreign key (id_p1) references parent_1(id),
                   constraint fk_id_p2 foreign key (id_p2) references parent_2(id),
                   constraint fk_id_p3 foreign key (id_p3) references parent_3(id)
                   );
 
create index i_id_p1 on child(id_p1);

create index i_id_p2 on child(id_p2);

create index i_id_p3 on child(id_p3);

create or replace procedure insert_into_child as
pragma autonomous_transaction;
begin
  insert into child(id_c, id_p1, id_p2, id_p3) values(1,1,1,1);
  commit;
end;
/
 
insert into parent_1 values(1);

insert into parent_2 values(1);

commit;

And now the action that causes the deadlock:

SQL> insert into parent_3 values(1);

1 row created.

SQL> exec insert_into_child;
BEGIN insert_into_child; END;

*
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
ORA-06512: at "SCOTT.INSERT_INTO_CHILD", line 4
ORA-06512: at line 1

My question is: How can I determine which integration into the CHILD table waiting for? He could wait on a combination of these, PARENT_3, PARENT_2, PARENT_1, or even on the CHILD if I tried to insert a primary key that is duplicated in the CHILD. Since we have the full test case, we know that he was waiting on PARENT_3 (or better said, he expected to perform a commit / rollback of the transaction 'parent'), but is it possible to determine that only from the deadlock trace file? I ask that because to identify the problem, I had to perform redo log mining, tracing pl/sql with DBMS_TRACE and manual debugging on a clone of the production database that has been restored to a SNA just before blocking is product. So, I had to do a lot of work to get to the trainer table and if this information is already in the deadlock trace file, it would have saved me a lot of time.

Here is the deadlock trace file. In section "DML LOCK", I assumed that the child table (tab = 227042) holds a 3 way locks (SX), all other tables of three parents have a mode 2 locks (SS), but from this excerpt, I see that parent_3 (tab = 227040) blocks the children insert:

Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00070029-00749150        23     476     X             23     476           S
session 476: DID 0001-0017-00000003     session 476: DID 0001-0017-00000003
Rows waited on:
Session 476: obj - rowid = 000376E2 - AAA3biAAEAAA4BwAAA
  (dictionary objn - 227042, file - 4, block - 229488, slot - 0)
Information on the OTHER waiting sessions:
End of information on OTHER waiting sessions.
Current SQL statement for this session:
INSERT INTO CHILD(ID_C, ID_P1, ID_P2, ID_P3) VALUES(1,1,1,1)
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
3989eef50         4  procedure SCOTT.INSERT_INTO_CHILD
391f3d870         1  anonymous block
.
.
.
.
        SO: 397691978, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227042 flg=11 chi=0
                  his[0]: mod=3 spn=35288
        (enqueue) TM-000376E2-00000000  DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x6
        res: 0x398341fe8, mode: SX, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x398341ff8
        ----------------------------------------
        SO: 397691878, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227040 flg=11 chi=0
                  his[0]: mod=2 spn=35288
        (enqueue) TM-000376E0-00000000  DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x6
        res: 0x3983386e8, mode: SS, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x3983386f8
        ----------------------------------------
        SO: 397691778, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227038 flg=11 chi=0
                  his[0]: mod=2 spn=35288
        (enqueue) TM-000376DE-00000000  DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x6
        res: 0x398340f58, mode: SS, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x398340f68
        ----------------------------------------
        SO: 397691678, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227036 flg=11 chi=0
                  his[0]: mod=2 spn=35288
        (enqueue) TM-000376DC-00000000  DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  res_flag: 0x6
        res: 0x39833f358, mode: SS, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x39833f368
      ----------------------------------------

Thanks in advance for your comments,
Swear

user633661 wrote:

My question is: How can I determine which integration into the CHILD table waiting for? He could wait on a combination of these, PARENT_3, PARENT_2, PARENT_1, or even on the CHILD if I tried to insert a primary key that is duplicated in the CHILD. Since we have the full test case, we know that he was waiting on PARENT_3 (or better said, he expected to perform a commit / rollback of the transaction 'parent'), but is it possible to determine that only from the deadlock trace file?

There is no way to get the answer from the deadlock trace.

At this stage and with your example, the waiting session waits for a lock of the TX (transaction) - this means that he has no idea (and uninteresting) in the involved actual data, that it is simply waiting for a location of transaction undo segment header table clear.

An easy way to demonstrate, it is as follows:-

create the parent and child tables with the activated FK constraint
Session 1 - set a save point, then insert line into parent but do not commit
Session 2 - insert a load line in the child - the session will pass a waiting for TX lock on the parent transaction
Session 1-restoration to the point of backup

Because restoration is a save point, session 1 always held a TX lock in exclusive mode, even if it will take is more all lock TM (table).
Session 2 will still wait for session 1 to commit or rollback - even if the parent required row does not exist, even in a State that is not validated.

Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
Author: core Oracle

Remove the alert logs and trace files
Hello world!

I noticed that in all the databases oracle, the trace files are pious and alert log is more and more like what...

Thought of making a copy of the trace of the files somewhere and remove hard drive other than the most recent.

For the alerts log, thought to make a copy and rename the current file as well as Oracle can create a new.

Advice if there are better approaches in the treatment of this?

Thanks in advance.
user645399 wrote:
or zipping what old files? is it possible to automate this process using winzip or another utility or even windows?

Appreciate if someone has a suggestion?

Thanksssssssssssssss

Well, I can tell it's not a question of ORACLE, you can get many things by Googling. ;-)
ZIP or whatever it is you need to automate scripts by creating a * .bat files. you have some third-party tools where you can plan all those.
example: -.
PKZIP-ex txtfiles.zip *.txt

Discover the traces files when DBMS. TRACE is used

Hi all
How can I view trace file when DBMS_TRACE. SET_PLSQL_TRACE is run?

Suppose I have the following procedure

create or replace procedure some_proc is
first varchar(10);
begin
select first_name into first from employees where first_name='Eleni';
dbms_output.put_line(first);
end some_proc;

running the static sql query and I want to see how the DBMS_TRACE exports information about the trace file. I run the tracetab.sql

SQL> @/usr/local/oracle/product/11.2.0/dbhome_1/rdbms/admin/tracetab.sql

recompile the procedure

SQL> alter procedure some_proc compile debug reuse setting;

Start the trace

SQL> exec dbms_trace.set_plsql_trace(dbms_trace.trace_all_sql)

Run the procedure

SQL> exec hr.some_proc

get the location of the file record of the session in question

SELECT value
FROM v$diag_info
  3  WHERE name = 'Default Trace File';

VALUE
-------------------------
/usr/local/oracle/diag/rd
bms/inara/inara/trace/ina
ra_ora_6309.trc

but when I view the file, I can't find information on the sql statement. Here is the last part of inara_ora_6309.trc which shows the debatable part:

*** 2011-09-08 12:56:29.712
*** SESSION ID:(132.70) 2011-09-08 12:56:29.712
*** CLIENT ID:() 2011-09-08 12:56:29.712
*** SERVICE NAME:(SYS$USERS) 2011-09-08 12:56:29.712
*** MODULE NAME:(sqlplus@firefly (TNS V1-V3)) 2011-09-08 12:56:29.712
*** ACTION NAME:() 2011-09-08 12:56:29.712
 
--NOTICE  ---------------------------------------
--PL/SQL TRACE INFORMATION IS NOW IN THE DATABASE
-- To create the trace tables, use the script  --
-- rdbms/admin/tracetab.sql under ORACLE_HOME  --

The part that I've done wrong? The procedure is sufficient so that the trace info does not appear? I have consulted the wrong trace file?

Best regards
Val

Published by: Valerie good-natured Sep 8, 2011 12:15 AM

Hello

The message seems pretty clear to me:

--PL/SQL TRACE INFORMATION IS NOW IN THE DATABASE

You can view trace information by querying the tables that you created by using the tracetab.sql script.

SELECT * FROM plsql_trace_events;
SELECT * FROM plsql_trace_runs;

Trace files showing the bind variable value =""
10g on solaris

Hi all

We have a problem with an informatica workflow brings an update statement in Oracle in trems of performace.

I started using DBMS_SUPPORT tracing with lie the TRUE value. He captured the trace files accordingly against a controlled set of data. Trace TWOT files were produced.

Trace files first shows the SELECT statement are questions that identifies the records that will be updated.

The 2nd trace file shows the actual UPDATE statement published as a PL/SQL loop to do the update.

There are 20 records that users have rigged last updated and the update statement lists 20 cases where updates taking place. All updates occurred successfully after reviewing the results of the post. However my question is why the trace files are showing the values of bind as the value ""?... any ideas appreciated!

an excerpt of the file trace...
PARSING IN CURSOR #1 len = 123 dep = uid 0 = 1482 oct = 6 lid = tim 1482 = 994827916280 = ad 3649357857 hv = "8b5b98f0."
UPDATE / * + index (FCT_TASK IDX_FCT_TASK_CASE_SBL_ROW_ID) * / FCT_TASK SET DWH_LAST_UPD_DT = SYSDATE WHERE CASE_SBL_ROW_ID =: 1
END OF STMT
# 1 ANALYSIS: c = 10000, e = 980, p = 0, cr = 0, cu = 0, put = 1, r = 0, dep = 0, og = 1, tim = 994827916264
=====================
PARSING IN CURSOR #5 len = 227 dep = 1 uid = 0 oct = cover 3 = 0 tim = hv 994827919231 = ad 2190775527 = "8e622670".
Select obj$ o, user$ u u.name, o.name, t.update$, t.insert$, t.delete$, t.enabled, trigger$ t where t.baseobject =: 1 and t.obj #= o.obj # and o.owner # u.user = # and bitand (property, 16) = 0 and bitand (property, 8
) = 0 order by o.obj #.
END OF STMT
ANALYSIS #5:c = 0, e = 1310, p = 0, cr = 0, cu = 0, put = 1, r = 0, dep = 1, og = 1, tim = 994827919223
LINKS FOR #5:
bind 0: dty = 2 mxl = 22 (22) bad = 00 scl = 00 pre = 00 = 00 = 0001 size = 24 offset = 0 oacfl2 oacflg
BFP = bln ffffffff7c058d98 = 22 avl = flg 04 = 05
value = 425212
EXEC #5:c = 10000, e = 9476, p = 0, cr = 0, cu = 0, put = 1, r = 0, dep = 1, og = 4, tim = 994827928883
FETCH #5:c = 0, e = 104, p = 0, cr = 1, cu = 0, set = 0, r = 0, dep = 1, og = 4, tim = 994827929051
"STAT id #5 = 1 cnt = 0 pid = 0 pos = 1 obj = 0 op =' SORT ORDER BY (cr = 1 pr = 0 pw = time 0 = 172 en)"
"STAT id #5 = 2 cnt = 0 pid = 1 pos = 1 obj = 0 op ='NESTED LOOPS (cr = 1 pr = 0 pw = time 0 = 110 US)"
"STAT id #5 = 3 cnt = 0 pid = 2 pos = 1 obj = 0 op ='NESTED LOOPS (cr = 1 pr = 0 pw = time 0 = 105 en)"
STAT id #5 = 4 cnt = 0 pid = 3 pos = 1 obj = op 79 ='$ TABLE ACCESS BY INDEX ROWID TRIGGER (cr = 1 pr = 0 pw = time 0 = 103 US)'
"STAT id #5 = 5 cnt = 0 pid = 4 pos = 1 obj = 123 op ='INDEX RANGE SCAN I_TRIGGER1 (cr = 1 pr = 0 pw = time 0 = 78 US)"
"STAT id #5 = 6 cnt = 0 pid = 3 pos = 2 obj = op 18 ='TABLE ACCESS BY INDEX ROWID OBJ$ (pr = 0 pw = time cr = 0 0 = 0 US)"
"STAT id #5 = 7 cnt = 0 pid = 6 pos = 1 obj = op 36 ='INDEX SCAN SINGLE I_OBJ1 (cr = 0 pr = 0 pw = time 0 = 0 US)"
"STAT id #5 = 8 cnt = 0 pid = 2 pos = 2 obj = op 22 =' CLUSTER ACCESS USER TABLE $ (pr = 0 pw = time cr = 0 0 = 0 US)"
"STAT id #5 = 9 cnt = 0 pid = 8 pos = 1 obj = op 11 ='INDEX UNIQUE SCAN I_USER # (pr = 0 pw = time cr = 0 0 = 0 US)"
LINKS FOR #1:
bind 0: dty = 1 mxl = 32 (30) bad = 00 scl = 00 pre = 00 oacflg = 01 oacfl2 = 800000 size = 32 offset = 0
BFP = bln ffffffff7c17b0a0 = 32 avl = flg 04 = 05
value =""
# 1 EXEC: c = 8390000, e = 8740989, p = 55593, cr = 55610, cu = 3, put = 1, r = 1, dep = 0, og = 1, tim = 994836657483
LINKS FOR #1:
bind 0: dty = 1 mxl = 32 (30) bad = 00 scl = 00 pre = 00 oacflg = 01 oacfl2 = 800000 size = 32 offset = 0
BFP = bln ffffffff7c17b0a0 = 32 avl = flg 04 = 05
value =""
# 1 EXEC: c = 7980000, e = 7962369, p = 55591, cr = 55608, cu = 1, SIG = 0, r = 1, dep = 0, og = 1, tim = 994844621479
LINKS FOR #1:
bind 0: dty = 1 mxl = 32 (30) bad = 00 scl = 00 pre = 00 oacflg = 01 oacfl2 = 800000 size = 32 offset = 0
BFP = bln ffffffff7c17b0a0 = 32 avl = flg 04 = 05
value =""

ect ect ect...

Concerning
Satnam
```
BINDS #1:
bind 0: dty=1 mxl=32(30) mal=00 scl=00 pre=00 oacflg=01 oacfl2=800000 size=32 offset=0
bfp=ffffffff7c17b0a0 bln=32 avl=04 flg=05
value=""
```
'dty = 1' indicates that the data type is VARCHAR or NVARCHAR. As the timestamp data types data types BLOB, and various other, bind variables defined as NVARCHAR will not have their values dumped in a 10046 trace file. I suspect that the: 1 binding variable is passed as an a NVARCHAR2.

Charles Hooper
Co-author of "Expert Oracle practices: Oracle Database Administration of the Oak Table.
http://hoopercharles.WordPress.com/
IT Manager/Oracle DBA
K & M-making Machine, Inc.

LMS huge trace file created
Hi all

2 CARS db in window Server 2003 nodes. The version of db is 10.2.0.3. My question is why we get huge lms trace files in the bdump directory and they become bigger and bigger. In the trace file, we have something like the following. Thanks a lot for your help, Shirley

2009-12-29 10:11:01.926
KJM_HISTORY: OP (12) of STALL RCVR context 0 elapsed 651716247 US
KJM HIST LMS3:
12:651716247 7:1 6:0 10:1 17:1 16:0 15:1 12:15475015 7:1 6:1
10:0 17:2 16:1 15:291 12:651692189 7:1 6:1 10:0 17:1 16:1
12:12345971 15:1 7:0 6:1 10:0 17:1 16:0 15:1 12:12020 7:0
6:1 10:0 17:1 16:1 15:0 12:11977 7:1 6:0 10:0 17:1
16:1 15:0 12:12054 7:1 6:0 10:0 17:1 16:1 15:0 12:12016
7:1 6:0 10:0 17:1 16:1 12:12017 7:1 6:0 10:0 15:0
17:1 16:1 15:0 12:11692
----------------------------------------
SO: 000000012A3B11D8, type: 4, owner: 000000012A0041B8, flag: INIT /-/-/ 0x00
(session) sid: 543 trans: 0000000000000000, creator: 000000012A0041B8, flag: (51) USR /-BSY /-/ - /-/ - / -.
DID: 0000-0000-00000000, DID short term: 0000-0000-00000000
TXN branch: 0000000000000000
Oct: 0, prv: 0, sql: 0000000000000000, psql: 0000000000000000, users: 0/SYS
last wait "gcs remote message" blocking sess = 0 x 0000000000000000 seq = 10 wait_time = 651716241 seconds since then started to wait = 300
waittime = 18, survey = 0, event = 0
Dumping history of waiting for Session
for "BSC remote messages" number = 1 wait_time = 651716241
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 15475008
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 651692179
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 12345963
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 12017
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 11974
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 12052
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 12013
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 12014
waittime = 18, survey = 0, event = 0
for "BSC remote messages" number = 1 wait_time = 11688
waittime = 18, survey = 0, event = 0
the temporary object counter: 0
----------------------------------------
UOL used: 0 locks (used = 0, free = 0)
KGX atomic operation Log 000007FFE6FF5600
Mutex 0000000000000000 (0, 0) oper idn 0 NONE
Library Cache 543 DTS uid 0 w/h 0 slp 0
KGX atomic operation Log 000007FFE6FF5648
Mutex 0000000000000000 (0, 0) oper idn 0 NONE
Library Cache 543 DTS uid 0 w/h 0 slp 0
KGX atomic operation Log 000007FFE6FF5690
Mutex 0000000000000000 (0, 0) oper idn 0 NONE
Library Cache 543 DTS uid 0 w/h 0 slp 0
check metalink note:
excessive LMS and lmd of sizes of trace files generated on windows rac - 437101.1

HTH
-André

How to find db file scatered read in the trace file?
Hi all

Was just going through the basic concepts...

1 lines of the created table T1with 1000 in LMT block size of 8 k.
2. followed enabled - change the context name of session set Event 10046 trace forever, level 12';
3. done - select * from T1;
"4 ALTER SYSTEM SET EVENTS ' trace 10046 name context off."

Now I have not found any scatered db file read in trace, as select opted for full table scan... What is the problem here?

I have found that sql * net messages in the trace file.

-Yasser
1. Yes, the table name (tt1 vs t1) is strange.

2. in addition, from 10 g, your application would be sampled, dynamically, without collecting statistics. While sampled dynamcially, blocks would be loaded into the cache. Collect statistics, RAS buffer cache, then trace with Event 10046.

================================
Dion Cho - Oracle Performance storyteller

http://dioncho.WordPress.com (English)
http://ukja.tistory.com (Korean)
http://dioncho.blogspot.com (Japanese)
http://ask.ex-EM.com (questions)
================================

ADR TRACE FILES ARE FILL SPACE CUSTOMER BOXES
I'm relatively new to 11g and the use of ADR. I realize of diagnosis of ADR, traces, newspapers, etc. are written in
directories as specified in the diagnostic_dest parameter. In our case,.
Under apps/oracle/diag/rdbms/rac1/rac13 where rac1 is our DNAME and
rac13 is one of the names of the instance. I am also aware that tracking files are
written under this path under the /trace and/incident/incdir_xxxxx
directories.

No HW or SW patches have been made recently.

We know the problem of the our client application SW related boxes having
their directory/root filled. As a result, all applications on these
boxes of 'freeze '. Maybe it's something new for me, but I thought that the type of ADR
diagnosis was only written to / exist ON DB SERVERS. We are witnessing to the
the same type of files on CUSTOMERS - but in different directories. On the
customer, for example, I see the following directories and the associated trace files
by:
1.) / root/oradiag_root/diag/clients/user_root/host_1204843186_11/incident/incdir_ *.
and

2.)/root/oradiag_root/diag/clients/user_root/host_1204843186_11/trace/ora__*.TRC & .trm

ALL of these files and directories are user ny ROOT property. 4-5 of these files are created EVERY MINUTE in the track and incident
directories, filling to the top/root. As a result, boxes of teas client application
are suspended until the trace files are deleted.

Here are my questions:
1. What are these files?
2.) why they are on the clients?
(3.) if they are part of the ADR process g 11, can (and how) if we limit the frequency of their creation?
I just need to put in place the crons to clean periodically?

Thank you for any comments.

Matt
Hi Matt

Wouw! I'm glad that you managed to solve this problem with the aid provided.

Would you please so kind a also to mark my answer as correct or useful?
Because this will help others to find a quick answer to questions and also ;) increase my rank

On your other question:

user10387007 wrote:

After that I installed the adrci (assuming that there is a checkbox in the dbca client install for it), I'll start managing the adr and incident log file. Another question: do you suggest not to have to be running on the clients and servers in an environment operational adr? Logic for sure to development and test, but to question overhead compared to an OPS environment. Thank you!

It makes sense on the server when it is a dev, test or pre-production environment. But on the production, I recommend you turn it on when you have a problem with the server or the client.

Ask more questions if you have something to say!

Thanks you also.

Kind regards
Hub

Published by: Hub on November 22, 2008 10:46

CoreTelephony error in trace file as a file for coretelephony tracing operation has failed, perhaps you need more disk space. Details "error opening the file/tmp/ct.shutdown, err = operation not permitted

I got this error:

"CoreTelephony Trace file error
A file for CoreTelephony tracing operation failed, you might run out of disk space. Details "error opening the file/tmp/ct.shutdown, err = operation not permitted"

I tried to solve it by searching for CoreTelephony errors. Could not resolve yet.
Software does not, especially of photoshop...

Any ideas?

Same thing here, iMac with OS X 10.11.6. All started a couple days ago. Have not found any valid solution online yet, I tried rebooting in recovery mode and check disk, but it seems that everything is ok with the drives and permissions.

trace file question

Similar Questions

Maybe you are looking for