RE: Excessive archvelog creation

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <dba@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 7 Sep 2017 18:17:54 -0400

Just in case anyone missed that:

 

Using certain features that operate on securefiles do require the relevant
licenses.

 

Just using securefiles for the storage of lobs in and of itself: no
additional license.

 

Good luck.

 

mwf

 

PS: Mike, that's worth a white paper, in particular:  the storage details
you used with basicfiles to get better behavior than securefiles might be
alchemy.

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Michael Brown
Sent: Thursday, September 07, 2017 3:42 PM
To: Mark Farnham
Cc: gogala.mladen@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Excessive archvelog creation

 

I agree with both Mark and Mladen about testing.

 

Be aware that features of securefiles (compression, deduplication) do
require licensing advanced compression.    Also, securefiles are a mixed
blessing with e-Business Suite (at least in my case), I had significantly
more wasted space and growth with securefiles than with basicfiles.  

--
Michael Brown
dba@xxxxxxxxxxxxxxxxx
http://www,ebs-dba.com

 

 

On Sep 7, 2017, at 12:52 PM, Mark W. Farnham <mwf@xxxxxxxx> wrote:

 

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




--
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com

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


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


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



 

Other related posts: