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@xxxxxxxxx
On Mar 23, 2021, at 7:22 AM, Laurentiu Oprea <laurentiu.oprea06@xxxxxxxxx>
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.
