Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Re: Difference on ArchiveLog (I'm rewriting the question)

Re: Re: Difference on ArchiveLog (I'm rewriting the question)

From: Tim Gorman <tim_at_sagelogix.com>
Date: Thu, 08 Jan 2004 06:34:36 -0800
Message-ID: <F001.005DC264.20040108063436@fatcity.com>


Mauricio,

Variances of 1G of redo generation (i.e. 4G one day, 2G another day, 3G another day) are not indicative of anything unusual. I've seen systems that generate 4T of redo one day, 6T of redo another day, and then only 0.5T of redo the following day. All without changing the size of the online redo log files... :-) Oh yes, the size of the particular database involved was about 6T, so there is also little correlation between the size and number of datafiles in the database and the volume of redo generation.

More likely than not, your hypothesis that changes in online redo log size are the cause of (or even factors in) these variations in redo generation is just plain incorrect. It is much more likely that the real cause is simply variations in application workload and activity.

You may have already done this, but I think you might want to summarize the volume of redo archived over longer periods of time using:

    select trunc(first_time), sum(blocks*block_size)/1048576 mb

    from v$archived_log group by trunc(first_time)

I imagine you'll find that such variations occur all the time, completely unrelated to the size of the online redo log files or changes made to those sizes. If you have any job-execution records, you might find a closer correlation between certain batch jobs and the volume of redo generated, for example.

Don't look for bugs in the database or the operating system when application user behavior is a much more probable cause of the effect you are seeing.

Hope this helps...

-Tim

> Hello everybody thank for your answers,
>
> the size I'm talking about is summing up real sizes of
> archivelogs files, and I had each configuration of redo
> logs for one week, and the first one was for many months.
>
> There was not any change on database objects and the
> database is small, the summing up real sizes of datafiles
> is 13G.
>
> I think It not should be happennig, because the archive
> generation shouldn't be dependent on redolog size. But in
> this case yes (Could be an Oracle 9i bug?) .
>
> Regards
>
> Mauricio Vélez
>
>
> Tanel Poder <tanel.poder.003_at_mail.ee> wrote:
> Is your system overloaded e.g. there is a continuous queue
> of transactions waiting? In that case, with bigger
> redologs, full checkpoints happen less frequently,
> allowing database to work faster, thus generating more
> redo.
>
> But, othervise, the archive generation shouldn't be
> dependent on redolog size.
>
> How are you measuring your archive size, just counting
> number of files/entries from v$archived_log or summing up
> real sizes of archivelogs? (´these may differ
noticeably,
> especially when frequent manual logswitches occur or
> archive_lag_target is set).
>
> Tanel.
>
> ----- Original Message -----
> To: Multiple recipients of list ORACLE-L
> Sent: Wednesday, January 07, 2004 10:49 PM
>
>
>
> Hello Everybody
>
>
>
> I’m rewriting the question,
>
>
>
> Some days ago the database I work on had 3 logfiles that
> sized 100M and the database was generating 4G of archive
> daily.
> I changed the size to 20M and the database began to
> generate 2G of archive daily, then I changed to 50M and It
> began to generate 3G of archive daily.
>
>
> I think I’ts not logical that archive size change.
>
>
>
> The database I'm working on is oracle 9i and I'is on
> Windows NT.
>
>
> Regards
>
> Mauricio Vélez
>
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tim Gorman
  INET: tim_at_sagelogix.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Thu Jan 08 2004 - 08:34:36 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US