Re: parallel recovery slaves waiting on undo reads

  • From: Frits Hoogland <frits.hoogland@xxxxxxxxx>
  • To: Noveljic Nenad <nenad.noveljic@xxxxxxxxxxxx>
  • Date: Fri, 28 Feb 2020 09:52:45 +0100

Not sure how relevant this is, because you are looking for the reason your 
recovery worker processes do a lot of IO I assume. 

Below is a description of the what happens when you see db file parallel read:

With newer oracle versions (12+), you’ll see plan lines indicating the word 
‘BATCHED’. I believe it’s these points where oracle knows it has to read 
multiple non-adjacent blocks that it is getting these all at once. However, I 
read indications it might be happening outside of the ‘BATCHED’ lines, and is 
implemented at any time it knows multiple non-adjacent blocks are needed, which 
would have been read serially in the past.

This can be implemented on the OS level as asynchronous IO requests via the 
regular asynchronous IO mechanism (io_submit-io_getevents), or uses a 
synchronous version to submit a a batch of IO requests: preadv. The mechanism 
of requesting multiple non-adjacent blocks has its own wait event: db file 
parallel read, which is a reasonable accurate description of what it actually 
does: it wants to read data from multiple places at the same time.

From a performance perspective, the problem with this wait event is that the 
timing of the wait event has no absolute meaning: waiting for a single IO is 
something different that waiting for let’s say 70 IO requests submitted at the 
same time. p2 tells you the amount of oracle blocks, p3 the amount of requests.

Frits Hoogland

http://fritshoogland.wordpress.com ;<http://fritshoogland.wordpress.com/>
frits.hoogland@xxxxxxxxx <mailto:frits.hoogland@xxxxxxxxx>
Mobile: +31 6 14180860

On 27 Feb 2020, at 12:51, Noveljic Nenad <nenad.noveljic@xxxxxxxxxxxx> wrote:

The half of the reads are indeed on only three index partitions:

SQL> select obj#,dataobj#,value,100*ratio_to_report(value) over() perc from 
v$segstat where statistic_name = 'physical reads' order by value desc fetch 
first 5 rows only ;

     OBJ#   DATAOBJ#      VALUE       PERC
---------- ---------- ---------- ----------
4294967295   35894092   10644378  18.892159
4294967295   35894903    9141720 16.2251686
4294967295   35894891    8487867 15.0646786
4294967295   35894096    2833553 5.02912748
4294967295   35894095    2719772 4.82718344

Executed on the primary database:

SQL> select data_object_id, object_type from dba_objects where data_object_id 
in ( 35894092, 35894903, 35894891, 35894096, 35894095 );

DATA_OBJECT_ID OBJECT_TYPE
-------------- -----------------------
     35894092 INDEX PARTITION
     35894095 INDEX PARTITION
     35894096 INDEX PARTITION
     35894891 INDEX PARTITION
     35894903 INDEX PARTITION

Many thanks,

Nenad

https://nenadnoveljic.com/blog/ ;<https://nenadnoveljic.com/blog/>



-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx
<oracle-l-bounce@xxxxxxxxxxxxx <mailto:oracle-l-bounce@xxxxxxxxxxxxx>> On 
Behalf Of Jonathan Lewis
Sent: Donnerstag, 27. Februar 2020 11:08
To: oracle-l@xxxxxxxxxxxxx <mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: parallel recovery slaves waiting on undo reads

In general I would expect it to be indexes that are the target for "db file 
parallel read", but possiby parallel recovery processes are allowed to behave 
completely differently.

Regards
Jonathan Lewis

________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf 
of Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
Sent: 27 February 2020 10:04
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: parallel recovery slaves waiting on undo reads


Can you get access to v$segstat / v$segment_statistics  to see what's 
changing most ?

Regards
Jonathan Lewis

____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.

Important Notice

This message is intended only for the individual named. It may contain 
confidential or privileged information. If you are not the named addressee 
you should in particular not disseminate, distribute, modify or copy this 
e-mail. Please notify the sender immediately by e-mail, if you have received 
this message by mistake and delete it from your system.
Without prejudice to any contractual agreements between you and us which 
shall prevail in any case, we take it as your authorization to correspond 
with you by e-mail if you send us messages by e-mail. However, we reserve the 
right not to execute orders and instructions transmitted by e-mail at any 
time and without further explanation.
E-mail transmission may not be secure or error-free as information could be 
intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also 
processing of incoming e-mails cannot be guaranteed. All liability of 
Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively 
referred to as "Vontobel Group") for any damages resulting from e-mail use is 
excluded. You are advised that urgent and time sensitive messages should not 
be sent by e-mail and if verification is required please request a printed 
version.
Please note that all e-mail communications to and from the Vontobel Group are 
subject to electronic storage and review by Vontobel Group. Unless stated to 
the contrary and without prejudice to any contractual agreements between you 
and Vontobel Group which shall prevail in any case, e-mail-communication is 
for informational purposes only and is not intended as an offer or 
solicitation for the purchase or sale of any financial instrument or as an 
official confirmation of any transaction.
The legal basis for the processing of your personal data is the legitimate 
interest to develop a commercial relationship with you, as well as your 
consent to forward you commercial communications. You can exercise, at any 
time and under the terms established under current regulation, your rights. 
If you prefer not to receive any further communications, please contact your 
client relationship manager if you are a client of Vontobel Group or notify 
the sender.
Please note for an exact reference to the affected group entity the corporate 
e-mail signature.
For further information about data privacy at Vontobel Group please consult 
www.vontobel.com <http://www.vontobel.com/>.

--
//www.freelists.org/webpage/oracle-l ;
<//www.freelists.org/webpage/oracle-l>

Other related posts: