I believe the way SLOB works is that the column updated in not indexed. It was
done on purpose for precisely the same reason that you have described below but
the goal of the tool is to drive IO and not to spend time on CPU operations.
Thanks
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mladen Gogala
Sent: Saturday, March 10, 2018 10:01 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: "db file sequential read" latency during reads versus update
activity
Well, when you have updates, your index block may need to be rebuilt. The "db
file sequential read" is an index read. If the block has been updated, not only
does the block need to be rebuilt, the index block also needs to be rebuilt. It
takes time, even if both are cached in memory. However, the precise answer to
your question is not possible. For the precise answer, one would need to
profile the running code and see exactly where the time is spent. Only Oracle
developers can do that. You may try with strace, to see whether there is
another IO that somehow creeps in.
Regards
On 03/08/2018 09:54 AM, Hameed, Amir wrote:
I am running SLOB to gauge latency of the storage array. When I configure my
test for SELECT only run (no updates), I see average latency of db file
sequential read consistently around 3ms. However, as I start to add UPDATE
activity to the run, I see average latency of db file sequential read go up in
the vicinity of 5ms. Is the cause of this increase in latency due to the commit
cleanouts phenomena? The database version is 12.1.0.2. My DB_CACHE size is set
to 128M to drive physical IOs and I am running my tests with 64 concurrent
users.
Thanks,
Amir
--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
