Re: Redo Generation

From: Niall Litchfield <niall.litchfield_at_gmail.com>
Date: Wed, 11 Oct 2017 09:48:03 +0100
Message-ID: <CABe10sbN6oQOdVqP42c+A-SsPggmTtrtf9NGhSAiCrAzO6kWwA_at_mail.gmail.com>



I *do* like that. Having said that, as John also suggests, we can use the Fermi method and make sensible assumptions as a first start (and then measure on which more later). We might say

  1. Redo will record the block changes for the data we change, the undo blocks plus a bit for the transaction tables
  2. If there is an index, then redo must also record change vectors for that
  3. If there are out of line LOB columns then redo will record changes for the affected LOB chunks (this may have changed in more recent versions)
  4. If there are triggers affected by the transaction that affect other tables then add something for that.

So if you have an idea of how much data/how many blocks you will change, how many indexes you have, and if there are any LOBS then you can start to estimate a sensible value for redo generated ahead of time.

This won't be *accurate* but it will help you think about likely levels of redo.

I've hardly ever met anyone who actually does this mind, the usual approach is to add more storage as becomes necessary :)

On Wed, Oct 11, 2017 at 7:13 AM, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> Here is the best method for estimating the redo space that the statement
> will consume:
>
> http://dilbert.com/strip/2008-05-08
>
> On 10/10/2017 05:27 PM, Michael Calisi wrote:
>
> I don't have a test system for this particular sql stmt
>
> Thanks,
>
>
> --
> Mladen Gogala
> Oracle DBA
> Tel: (347) 321-1217
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 11 2017 - 10:48:03 CEST

Original text of this message