RE: To set events or not set events, that is the question

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 15 Jun 2004 10:05:42 -0500

Yep, tkprof has a hard time dealing with wrapped tim values. It's one of the
umpteen reasons we don't use it (www.hotsos.com/products/profiler.html).  


Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *

Upcoming events:
- Performance Diagnosis 101: 6/22 Pittsburgh, 7/20 Cleveland, 8/10 Boston
- SQL Optimization 101: 5/24 San Diego, 6/14 Chicago, 6/28 Denver
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jamadagni, Rajendra
Sent: Tuesday, June 15, 2004 5:57 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: To set events or not set events, that is the question

Rich,

The times are probably micro/milli/centi/deca seconds. Since Oracle
can't make up its mind on one standard, choose one. But I have seen
things like this before. I even have a SQL that tkprof claims has been
running for 67 years (and Cary will love this with 63 years of Wait time
BTW). So, go figure. It is hard to figure them out. 

Since so many people wrote various papers about 1555 e.g.

1. Cats Dogs and 1555
2. 155 Explained
3. 1555 Demystified etc ... 

Oracle has a compelling reason to make it even more obscure and with RAC
it is even easier. See how conveniently they moved deadlock graph dumps
to lmd0 trace files rather than process trace files? Makes sense ... But
to whom is still the open question.

Raj
------------------------------------------------------------------------
-------- 
Rajendra dot Jamadagni at nospamespn dot com 
All Views expressed in this email are strictly personal. 
select standard_disclaimer from company_requirements; 
QOTD: Any clod can have facts, having an opinion is an art !
 

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jesse, Rich
Sent: Monday, June 14, 2004 5:12 PM
To: ORACLE-L (E-mail)
Subject: To set events or not set events, that is the question

9.2.0.5.0 on HP/UX 11.11, newly created from an 8.1.7.4.0 export.  After
a week of uptime, we get an ORA-1555 today.  The alert.log says:

ORA-01555 caused by SQL statement below (Query Duration=8581 sec,
SCN:0x0000.0090c189):

...followed by what I'm hoping is a partial statement (because it's a
nasty FTS):

SELECT PARTNO,WHOUSE,ENT_CODE FROM MY_TABLE

(schema/table/column names changed to protect the innocent).  Now any
query that takes 2+ hours to complete during the day on our nice new
fast server *deserves* to die a horrible ORA-1555 death, IMHO, but I'd
still like to be able to track these down in the future.  And without a
trace file generated, that's just not gonna happen.

So, I'll set event 1555 as an errorstack.  But the last time I did this,
then had a Support call a year later, I was told that setting events
permanently like this is not a good idea, although I was not able to
find out *why* it's not.

I've got a TAR open to get the Official Word, but does anyone have a
good reason why this or other "error" event (like 1652 to determine who
the hell used up 2GB of TEMP) should NOT be in an init.ora for any
version of Oracle???

TIA!
Rich

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: