Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: 9i RAC Scripts.// LONG

RE: 9i RAC Scripts.// LONG

From: Jack van Zanen <JACK_at_QUANTSYSTEMS.NL>
Date: Wed, 01 Oct 2003 04:11:04 -0800
Message-ID: <F001.005D1ADD.20031001041104@fatcity.com>

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: JACK_at_QUANTSYSTEMS.NL
>
> 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: ListGuru_at_fatcity.com (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: mgogala_at_adelphia.net

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: ListGuru_at_fatcity.com (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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jack van Zanen
  INET: JACK_at_QUANTSYSTEMS.NL

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: ListGuru_at_fatcity.com (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).
Received on Wed Oct 01 2003 - 07:11:04 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US