Re: parallel recovery slaves waiting on undo reads

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_at_gmail.com <mailto:frits.hoogland_at_gmail.com> Mobile: +31 6 14180860

> On 27 Feb 2020, at 12:51, Noveljic Nenad <nenad.noveljic_at_vontobel.com> 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_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org>> On Behalf Of Jonathan Lewis
> Sent: Donnerstag, 27. Februar 2020 11:08
> To: oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>
> 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_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
> Sent: 27 February 2020 10:04
> To: oracle-l_at_freelists.org
> 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/>.
>
> --
> http://www.freelists.org/webpage/oracle-l <http://www.freelists.org/webpage/oracle-l>

--
http://www.freelists.org/webpage/oracle-l