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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
