clarification:
old way == basicfiles
new way == securefiles
and NO, securefiles does NOT require extra licensing despite a long standing
rumor that it requires advanced security.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mark W. Farnham
Sent: Thursday, September 07, 2017 10:31 AM
To: gogala.mladen@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Excessive archvelog creation
... And (implying agreement with Mladen on this) when you test, be sure all the
DDL about that column DATA is exactly the same. (Presumably you need to create
a test table to test this on your exact system with your code in place of the
application code.)
And probably check getlength before and after some number of updates and track
whether the redo generation per update of the same size continues to rise.
Which sort of storage are you using for the clob? (Just a question. And I don't
mean the physical storage. There is an old way to store CLOBs from the Oracle
software point of view and a completely revised way that is much superior in
many ways. Whether or not the application which you may not control uses the
old way is a useful question.)
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mladen Gogala
Sent: Thursday, September 07, 2017 7:43 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Excessive archvelog creation
Peter, the only real way to find out is to test. That sounds like an
interesting thing to test. Please, let us know what you found out, once you're
done testing.
Regards
On 09/06/2017 02:27 PM, Schauss, Peter [US] (ES&CSO) wrote:
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