RE: Excessive archvelog creation

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Thu, 7 Sep 2017 18:17:54 -0400
Message-ID: <036201d32827$277968a0$766c39e0$_at_rsiz.com>



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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael Brown
Sent: Thursday, September 07, 2017 3:42 PM To: Mark Farnham
Cc: gogala.mladen_at_gmail.com; oracle-l_at_freelists.org 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_at_michael-brown.org
http://www,ebs-dba.com    

On Sep 7, 2017, at 12:52 PM, Mark W. Farnham <mwf_at_rsiz.com> 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham
Sent: Thursday, September 07, 2017 10:31 AM To: gogala.mladen_at_gmail.com; oracle-l_at_freelists.org 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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala
Sent: Thursday, September 07, 2017 7:43 AM To: oracle-l_at_freelists.org
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
--

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

--

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

--

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

--

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

--

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

--

http://www.freelists.org/webpage/oracle-l Received on Fri Sep 08 2017 - 00:17:54 CEST

Original text of this message