Hello Peter,
based on the provided information this is impossible to say as LOB redo
behavior varies a lot (e.g. CACHED vs. NOCACHED, ARCHIVELOG vs. NOARCHIVELOG,
etc.).
Here is a blog post of mine about this (http://tinyurl.com/no28vgc) and here is
another one by Jonathan Lewis
(https://jonathanlewis.wordpress.com/2014/01/06/lob-changes/).
However it is very easy to verify as you just need to dump one of these archive
log files and check the content (see my blog post).
Best Regards
Stefan Koehler
Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Twitter: @OracleSK
"Schauss, Peter [US] (ES&CSO)" <peter.schauss@xxxxxxx> hat am 6. September--
2017 um 20:27 geschrieben:
Environment: Oracle 12.1.0.2 (January 2017 PSU)
Redhat Linux 6.2
Application (in case it matters Deltek Cobra)
I came into the office one morning a few weeks ago and discovered that the
above application had devoured 500 gb of archivelog space in a period of
about five hours over the previous night. Fortunately, this was on the
development database server.
I ran an awr report for the time period in question and it listed the
following statement executed 3740 times:
UPDATE PROCESSLOG SET DATA = CONCAT(DATA,:B2 ) WHERE ROW_UID = :B1
The DATA column is clob and, based on timestamps that the application writes
to the table I located the row to which that data was being added.
DBMS_CLOB.GETLENGTH shows the size of the clob in that row as 48 mb.
So my questions are:
1. If the application was adding the data with CONCAT in small increments,
say 100 characters at a time, would this account for the large volume of redo
that we saw?
2. If the application had added the 48 mb all at once would it have
generated less redo?
Thanks,
Peter
--
//www.freelists.org/webpage/oracle-l
