Re: dbms_diskgroup read very slow on exa

I think some other things to consider is how many storage cells are there? How many disks make up the RECO diskgroup where the redo / archive logs are stored? It's very possible that attunity is flooding the IO for where those files are stored.

If you back off the concurrency, does it get better or worse?

---

Thanks,


Shane Borden
sborden76_at_yahoo.com





> On Mar 23, 2021, at 7:22 AM, Laurentiu Oprea <laurentiu.oprea06_at_gmail.com> wrote:


> 

> Hello all,

> 

> I received complaints about Attunity doing the ingestion very slowly. The way is configured is to connect directly to ASM instance and get the archivelog files.This is an exa X7

> 

> My observations wre:

> -> is using dbms_diskgroup.read  to perform the reads from asm

> -> mainly the wait time is ASM Fixes Package I/O (and some CPU)

> -> Is using 16 sessions distributed over 2 nodes each reading with an estimate speed (based on ASH numbers) of around 10MBPS

> -> in case a smart scan starts (for example smart incremental backup)  the I/O speed of these sessions drops to around 1MBPS

> -> session level stats shows a very low number for "cell flash cache read hits" so looks like all reads are from spinning disks 

> 

> To me it looks like the reading speed even in normal conditions(without heavy competition)  is very low, can someone help me with some hints on what can be the culprit?

> 

> Thank you. 


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