Well, let's hope the session does some work! ;-)
You can check v$sesstat for time spent on various operations, for
example, 'CPU used by this session'. That certainly is to be added to
the total wait time. But now that you mention it, I don't know which
stats should add up to equal time
yep, look at CPU used by this session in V$sesstat.
CPU + WAIT should get close to the logon_secs. There are a number of reasons
why it can't and shouldn't but for simplicity go with it.
Anjo.
On Wednesday 04 September 2002 22:59, you wrote:
I run the following query to compare the total
Title: Message
First, youre missing user-mode CPU time
consumed by the Oracle session. The statistic that is supposed to hold this
number is CPU used by this session from v$sesstat. But there are
bugs in that statistic. Second, some of the time that an Oracle process spends
sleeping
Could be SQL*Net message from client
Query v$session_event to see what else a
session has waited on:
select
sess.username,
sess.sid,
se.event,
se.total_waits,
se.total_timeouts,
se.time_waited/100 time_waited,
se.average_wait
from v$session_event se, v$session sess
where
Internal code changes= additional features=fine grained (event) reporting?
Best Regards,
K Gopalakrishnan
Bangalore, INDIA
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Thursday, May 16, 2002 9:13 PM
Has anyone noticed that the number of event
Isn't that something to do with 9i being able to report wait times in
nanoseconds instead of (milliseconds? or microseconds?) in previous versions
??
Raj
__
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Not exactly. The granularity of capturing times increased in 9i, but as
Gopal implied, there are just a lot more wait events in 9i as compared to
the previous releases.
Check this link out to see what new events were introduced in 9i :
http://www.oraperf.com/reference.html and click on Wait
Raj:
Oracle9i gives timing information in Micro Seconds. Not Nano Seconds
though modern CPUs clocks ticks in nano seconds.
The older versions (8i and below) give timing info in Centi Seconds
(1/100th of a second) .
Best Regards,
K Gopalakrishnan
Bangalore, INDIA
- Original Message -
You might notice more total event completions in 9i because there are
about 50% more segments of kernel code that are instrumented in 9i than
there were in 8i (~200 events in 8i, ~300 in 9i).
Clock granularity is 0.01 in 8i, so events that complete in the same
0.01-sec quantum as they began will
There is microsecond granularity in some of the columns, but not all platforms
support microsecond timing.
So some of these are centi seconds multipled by 1. There are ofcourse
exceptions (like Compaq Alpha, that suppports msec clocks).
There are more wait events in Oracle9i but the top
List,
--- [EMAIL PROTECTED] wrote:
Check out the statspack viewer tool at
http://www.geocities.com/alexdabr/
The tool (at least the screen snapshots) does look nice, but the author
seems to belong to the CHR camp (see tip 2 cut and paste below). I would
take the recommendations with a
That's neat. I working on HTML/GUI interface to
statspack. I think I've got most of the thing figured
out. Right now, I'm able to display phys read/write
IO directly from one of the statspack tables every
hour displayed in graphincal format on a web page.
Working on other reports as well.
I'm able to display phys read/write IO directly from... statspack
I started with data from StatsPack but instead went directly to the V$
tables to get it real time, or at least every minute. I get physical
writes, physical reads, db block and consistent gets, queries executed with
soft and hard
: RE: WAITS
root@fatcity.
com
:
Sent by: Subject:
RE: WAITS
root@fatcity
On Thu, May 09, 2002 at 03:23:24PM -0800, MacGregor, Ian A. wrote:
I have learned some rudimentary gnuplot skills. Each morning I
produce graphs of what went on the in the databases the previous day on
and hour by hour basis. If something is really askew I break the
hour down into ten
Each morning I produce graphs...
I think this is key. Having historical data graphically presented helps to
establish the norm and when there may be performance issues to investigate.
This follows step 2 of Gaja's Oracle Performance Tuning 101 Methodology
which says, Measure and document current
Seema - The SQL*Net more data to client means Oracle is waiting for the
client to send something back so Oracle can do something more. I looked
single-task message up on google and received:
single-task message
When running single task, this event indicates that the session waits for
the client
There is a vital piece of information missing, namely how long
was the accumulated wait time for each wait, and over what
period of time?
Jared
Seema Singh [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
05/09/2002 11:18 AM
Please respond to ORACLE-L
To: Multiple recipients of
what does netstat -i tell you, on both client and server.
On Thu, May 09, 2002 at 10:18:31AM -0800, Seema Singh wrote:
Hi
I checked wait in my database and found the following are top 5 waits.
Event Waits
single-task message
Well why do you want to do something ? To look busy ? Or are there
complaints about response times or throughput problems ?
Anjo.
Seema Singh wrote:
Hi
I checked wait in my database and found the following are top 5 waits.
Event Waits
In general There are two problems in using the top five waits out of statspack: it
reports idle waits; no matter how well-tuned your database there will always be a top
five. The numbers presented show total time-waited in csecs for the time period. As
Jared said we don't know the time
Jack,
I was going to suggest, what you did, but then I noticed the version Rahul
was using.
Igor Neyman, OCP DBA
Perceptron, Inc.
(734)414-4627
[EMAIL PROTECTED]
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, July 24, 2001 5:58 PM
Rahul,
If I'd known that there were only 8 columns in the table, I'd have included
the recommendation to investigate an Index-Organized Table. That is where
the table IS the index and the index IS the table. This saves disc space
and cuts I/O in half for DML on the table, since a separate
Title: RE: waits on sequential scans - how did i solve it
Is this table/index now suitable to be a IOT, it will certainly save some space on an 18M row table
John
-Original Message-
From: Rahul [mailto:[EMAIL PROTECTED]]
Sent: 24 July 01 14:53
To: Multiple recipients of list
I don't think, 7.3.2 supports Index-Organized tables.
Igor Neyman, OCP DBA
Perceptron, Inc.
(734)414-4627
[EMAIL PROTECTED]
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Tuesday, July 24, 2001 10:36 AM
Rahul,
If I'd known that there were
I was going to say the same thing until I saw what version of Oracle
he was running. Its a Oracle8 and up feature so Rahul is SOL.
-Original Message-
Sent: Tuesday, July 24, 2001 7:36 AM
To: Multiple recipients of list ORACLE-L
Rahul,
If I'd known that there were only 8 columns in
Hi Bruce,
Not sure whether you got a response on this, so here
is one. First of all, I am hoping that you have some
kind of performance problem on your hand, that you are
trying to solve and that led you to checking out the
wait events in your database. If so, great. If not
our discussion is
Hi Gaja,
I notice that you have advised Bruce to increase
SORT_AREA_SIZE to gain proformance lost due to
frequent allocation of temp segments. I too belived in
the theory that disk sorts are always faster than
memory sorts untill I stumbled on my own problem
which leaves me a little confused.
Hi Bruce
You need to find what blocks are hanging from the particular latch. You could get this information by joining x$bh and v$session_wait tables while the sessions are waiting for this latch.
select distinct ts#, file#, dbarfil,dbablk from x$bh
where hladdr in
(select p1raw from
Hi Johnson,
I think you may be reading just a tad bit too much
into what I wrote regarding the SORT_AREA_SIZE
increase recommendation. The rationale for that was
not based on disk sorts are always faster than memory
sorts or vice versa. It was based on the fact that
data for global temporary
Hi Gaja and thanks also to Riyaj,
If I didn't make it clear before we were having a major performance problem.
A package call that should (ie normally / used to) take less than 1 second
starting taking between 20 - 60 seconds.
I appreciate your comments on logical IO and will look into that
Bull's eye .
Will Check out the Steve Adams' Book revert
Thanks
-Original Message-
From: yong huang [SMTP:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 10:30 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Waits on latch free for shared_pool library
33 matches
Mail list logo
