Re: New to RAC and need some ideas/suggestions
- From: Chris Taylor <christopherdtaylor1994@xxxxxxxxx>
- To: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxx>
- Date: Tue, 21 Aug 2012 16:16:40 -0500
Mark,
What's a good way to determine what 'other' sessions would have been
inserting into the same table? Is there way to track this back through
history when the sessions are no longer connected? I'm looking at
V$ACTIVE_SESSION_HISTORY where event like '%FB%' and I see several
SESSION_IDS that had this particular wait but none of them seem to be
connected at the moment.
I've got my investigator hat on at the moment, but I'm not sure where to
begin (or how to begin) looking for culprits. Two of the SESSION IDS had
the same SQL_ID but on different INSTANCES - but I'm not sure they were
running CONCURRENTLY - is there some way I can determine that?
(ugh - I just realized it looks like GMAIL screwed up my formatted table I
sent in my original message - my apologies for that)
Chris
On Tue, Aug 21, 2012 at 4:07 PM, Bobak, Mark <Mark.Bobak@xxxxxxxxxxxx>wrote:
> Hi Chris,
>
> The 'gc' waits are an indicator of traffic going across the interconnect.
> This is generally to be avoided, as much as possible.
>
> If you have other sessions inserting into the same table or set of tables,
> from a different node, you're likely to see this, and see performance
> suffer. Try to isolate the workload of this type to a particular node.
>
> Also, consider hash partitioning heavily used indexes (number of
> partitions equal to smallest power of 2 greater than or equal to the number
> of nodes in the cluster). Remember, you can hash partition indexes, even
> for columns of tables that are not partitioned at all.
>
> Welcome to the wonderful world of RAC.
>
> Hope that helps,
>
> -Mark
--
//www.freelists.org/webpage/oracle-l
Other related posts:
