Hi Saurabh,
Try running $ORACLE_HOME/rdbms/admin/catperf.sql first.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http://www.christianity.net.au/ - For all
-Original Message-
Sent
Hi All,
Oracle uses direct I/O on W2K so the O/S block size is an irrelevance.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http://www.christianity.net.au/ - For all
-Original Message
Hi Jack,
It is a background wait, so unless user processes are waiting for DBWn in 'free buffer
waits' or 'write complete waits'
then you don't have a problem, no matter how big the 'db file parallel wait' numbers
are.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au
to another object.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http://www.christianity.net.au/ - For all
-Original Message-
Sent: Monday, 29 October 2001 13:55
To: Multiple recipients
Hi Riyaj,
The checkpoint object call is used prior to a direct read of an object. DBW0 scans the
cache once based on the obj#.
This was introduced in 8.0 as an optimization for parallel query. Previously each
extent was checkpointed separately.
@ Regards,
@ Steve Adams
@ http
the sessions holding the pins. See
executing_packages.sql at
http://www.ixora.com.au/scripts/misc.htm#executing_packages for an example.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http
the sessions holding the pins. See
executing_packages.sql at
http://www.ixora.com.au/scripts/misc.htm#executing_packages for an example.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http
Hi Rahul,
0 means not pinned; 3 means pinned in exclusive mode.
I don't know what 1 means. I'm not accustomed to seeing it.
Do you have any examples?
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
Hi Rahul,
Ah, I see. You're looking at KGLHDLMD instead of KGLHDPMD.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http://www.christianity.net.au/ - For all
-Original Message-
Sent
Hi Nirmal,
There is some information about the X$ tables available on the Ixora web site.
However, knowledge of the X$ tables is not really important for most DBAs.
They are only useful in rare, advanced tuning and diagnostic situations.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au
Hi Tamas,
When a session is waiting for a row-level lock you can see the row required in the
V$SESSION columns ROW_WAIT_OBJ#,
ROW_WAIT_FILE#, ROW_WAIT_BLOCK# and ROW_WAIT_ROW#. A script like Oracle's utllockt.sql
can be used to identify the
blocker.
@ Regards,
@ Steve Adams
@ http
of cache available for the archival writes. You would also do well to avoid
RAID-S of course!
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
-Original Message-
Sent: Thursday, 1 November 2001 5:45
.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
-Original Message-
Sent: Thursday, 1 November 2001 10:10
To: Multiple recipients of list ORACLE-L
Greg,
I may be way off here but FIRST_ROWS
hardware
diagnostic logs for evidence of
either memory or network errors, and make sure that you don't have someone trying to
use some old client software that
is not compatible with the RDBMS version.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http
that you scanned already
had a large number of block in the cache.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
-Original Message-
Sent: Friday, 2 November 2001 6:39
To: Steve Adams; Multiple recipients
Hi All,
Does anyone have an email address for Bert? I looked for his email address when I
first read that article a week ago,
but did not find one. I think I know what was wrong with his test, but it is hard to
be sure because he left out a lot
of the details.
@ Regards,
@ Steve Adams
Hi Andrea,
Don't do it! Adding commits makes the code more complex, much less efficient and risks
violating transactional
integrity. See http://www.ixora.com.au/newsletter/2001_09.htm#commits for a detailed
explanation of the problems.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au
doubled
db_block_buffers, but unless going from about 600M to about 1.2G, then it was not a
level playing field. Unfortunately,
he does not give those numbers.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
,
although it is in the V$ views, nor is it visible in the trace files because
the waiting session does not have a corresponding process that is waiting).
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
-Original Message
to be returned from the first row piece.
Although it is possible for that to be the case with row chaining, it's more
likely a symptom of migration.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
accept OwnerName prompt Owner
of chunks
and thus the relative size of these and other shared pool areas depends
entirely how recently objects have been used, because they all share the
same LRU mechanisms (although there is an additional subordinate LRU
mechanism for the dictionary cache).
@ Regards,
@ Steve Adams
@ http
can see chunks moving
from the transient to recurrent list. My best guess at the moment is that
when new recreatable chunks are first unpinned, they go onto the transient
list, and then when they have been reused, they go back onto the recurrent
list.
@ Regards,
@ Steve Adams
@ http
is that the ADDR column of the X$ output now returns addresses which
map into your PGA rather than the SGA. In fact, that is in general a good
way to work out whether you are looking at an X$ table or an X$ interface.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
; others like these ones you've mentioned do not
need to, but some of them do so anyway.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Steve Adams
, but there is no corresponding metadata in the dictionary cache.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
-Original Message-
Steve
Sent: Wednesday, 1 October 2003 12:49 AM
To: Multiple recipients of list ORACLE-L
Hi
. So yes, package variables
and bind variable are there (although the bind meta-data is in the SGA) but
sort areas, row source buffers, and runtime state data are also major space
consumers.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http
was under way when the PGA heap dump was
taken.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au/ - For all
-Original Message-
Satav, Pawan
Sent: Tuesday, 11 November 2003 8:55 PM
To: Multiple recipients of list ORACLE-L
Good
not notice all of this unless you start doing
library cache dumps.
That is, the use of public synonyms is a major scalability threat, but
does not normally cause performance problems.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.christianity.net.au
101 - 128 of 128 matches
Mail list logo
