I hope not,
This is from the Oracle documentation (quite a lot is about RAC so to get
the general idea is OK but details are difficult to grasp).
Since the note: said setting that parameter to anything else but the default
would disable cache fusion in Oracle 9i RAC clusters, My question was if we
should temper with this setting. My gut feeling tells me no.
Also if anybody has links to sites that have useful scripts to monitor the
RAC portion of the database, please let me know.
TIA
Jack
-Original Message-
Sent: Wednesday, October 01, 2003 1:39 PM
To: Multiple recipients of list ORACLE-L
GC_FILES_TO_LOCKS? Sounds familiar from some other times. Why do you use
hashed (static) locks? I thought that releasable locks are default in 9i? Is
there a reason to revert to the Oracle 7 OPS behvior?
On 2003.10.01 06:13, Jack van Zanen wrote:
Hi All,
I am trying to figure out what and why to monitor in a 9i RAC
environment. Could any of you guys please comment on the following:
**
**
V$FALSE_PING
is an Oracle9i Real Application Clusters view.
This view displays buffers that may be getting false pings. That is,
buffers pinged more than 10 times that are protected by the same lock
as another buffer that pinged more than 10 times. Buffers identified
as getting false pings can be remapped in GC_FILES_TO_LOCKS to
reduce lock collisions.
--
--
Note:
Setting this parameter to any value other than the default will disable
Cache Fusion processing in Oracle9i Real Application Clusters.
!Does this mean we should not temper with this???
--
--
I guess the number OF ROWS returned BY this query should be AS close
to zero AS possible, Right?
From the rows returned I guess the forced_reads/writes should be as
close
to
zero as possible, Right ?
Select name
, partition_name
, kind
, file#
, block#
, status
, xnc
, forced_reads
, forced_writes
From GV$FALSE_PING
**
**
V$CACHE_TRANSFER
This is an Oracle9i Real Application Clusters view.
The V$CACHE_TRANSFER view is identical to the V$CACHE view but only
displays blocks that have been pinged at least once. This view
contains information from the block header of each block in the SGA of
the current instance as related to particular database objects.
I guess the number OF ROWS returned BY this query should be AS close
to zero AS possible, Right?
From the rows returned I guess the forced_reads/writes should be as
close
to
zero as possible, Right ?
select name
, partition_name
, kind
, file#
, block#
, status
, xnc
, forced_reads
, forced_writes
from gv$cache_transfer;
**
**
There are many views based on global cache etc.. That are not really
clear to me what I can use to figure out cache fusion problems.
I did find in the documentation that information could be collected
from v$sysstat about global cache/locks that can be used to calculate
certain response times etc..
TIA
Jack
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jack van Zanen
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L (or the
name of mailing list you want to be removed from). You may also send
the HELP command for other information (like subscribing).
--
Mladen Gogala
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from). You may also send the HELP
