Re: RAC - Global Cache Transfer Times

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Tue, 6 Aug 2019 09:45:26 +0000
Message-ID: <CWXP265MB10323A3D2EEC2D124E325003A5D50_at_CWXP265MB1032.GBRP265.PROD.OUTLOOK.COM>

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

Received on Tue Aug 06 2019 - 11:45:26 CEST