Re: RAC - Global Cache Transfer Times
Date: Wed, 7 Aug 2019 10:42:36 +1000
Message-ID: <CAFeFPA9N-H8jNQmGfzQ2NMM_pnjfe3e2kYEfJOaFwYBXUhW5Lw_at_mail.gmail.com>
Hi Jonathan,
We don't have a reporting node and an update node.
between midnight and 6 am we have an etl that loads all the changes from our main database and after that the users run their reports (including scheduled reports)
this was between midnight and 00:30 so there is no reports running at the time.
parallel_force_local is set to TRUE.
unless I am going blind I am not seeing gc cr disk read waits in outrageous numbers
can this also be skewed by the fact that there weren't many blocks going across the interconnect?
Mind you this question is for education purpose more than anything
[image: image.png]
Jack van Zanen
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Thank you for your cooperation
On Tue, Aug 6, 2019 at 7:47 PM Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> wrote:
>
> Definitely on the slow side.
>
> The simplest rule of thumb is "if it's slower than a single block read we
> probably shouldn't be using RAC".
>
> You can see this type of repsonse (slow busy CR transfers) if you've got a
> reporting node and an update node and the update node gets very busy. The
> reporting node starts a "long" query and the update node has to do a lot of
> work on pinning busy blocks, copying them, then making the copy
> read-consistent.
>
> In a single instance I think you'd see a lot of buffer busy waits, and a
> lot of "consistent gets - undo records applied" (both of which you may see
> on node 2 while node 1 is reporting these slow gc cr gets). Are you also
> seeing a lot of "gc cr disk read" waits ?
>
> Regards
> Jonathan Lewis
>
>
>
> ________________________________________
> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
> behalf of Jack van Zanen <jack_at_vanzanen.com>
> Sent: 06 August 2019 01:08
> To: oracle-l_at_freelists.org
> Subject: RAC - Global Cache Transfer Times
>
> Hi All,
>
>
> Below is from AWR report and I was wondering if the CR Avg Time was on the
> slow side.
>
> Anyone have any rule of thumb as to what it "should" be?
>
> BTW, this is during the ETL load into our DWH.
>
>
> Global Cache Transfer Times (us)
>
> * Avg Time - average time of all blocks (Immed,Busy,Congst) in us
> * Immed, Busy, Congst - Average times in us
> * ordered by CR + Current Blocks Received desc
>
> CR Avg Time (us) Current Avg Time (us)
> Inst No Block Class All Immed Busy Congst All Immed
> Busy Congst
> 2 data block 26907 592 151759 942 392
> 9890 6391
> 2 undo header 2612 193 241481 1361
> 1361
> 2 others 11129 268 489014 54862 247 81818
> 2 undo block 201 201
>
> Jack van Zanen
>
> [
> https://docs.google.com/uc?id=0BwovDucFT1fXaEREVHNWRWZyNjg&export=download
> ]
> -------------------------
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient. If you are not the intended recipient,
> please be aware that any disclosure, copying, distribution or use of this
> e-mail or any attachment is prohibited. If you have received this e-mail in
> error, please contact the sender and delete all copies.
> Thank you for your cooperation
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Aug 07 2019 - 02:42:36 CEST
- image/png attachment: image.png
