Re: Archive Log Size

RAC doesn't use private redo - so with 32 CPUs we'd expect two public threads with (granule - fixed - overheads)/2 as the log buffer size. Is this happening on all three instances (redo threads)? If you report the "first_time" from v$archived_log can you see a pattern to the timing of the switch.
Is there any clue in the "creator" from v$archived_log ?

One possible explanation for this (assuming you've discounted all the usual suspects): Are all three instances active when this happens? I haven't checked recently but when an instance is down the active instances may be "kicking" it (KK lock) on a regular basis to do a log file switch so that all instances have archived log files with SCNs that are reasonably close to each other. Maybe there's a side effect (or timing issue, or bug) related to this that means the kicking is happening too frequently and you're not getting through a lot of redo before it happens.

Regards
Jonathan Lewis

On Fri, 5 Mar 2021 at 20:39, Henry Poras <henry.poras_at_gmail.com> wrote:

>
> - I was just rereading this thread and ran into a slightly different
> case I am just starting to dig into. My environment is 11.2.0.4 RAC (3
> nodes).
>
> The rough breakdown:
> Granule size: 256M
> > select * from v$sga;
>
> NAME VALUE
> -------------------- ----------
> Fixed Size 2269072
> Variable Size 3.9460E+10
> Database Buffers 8.8584E+10
> Redo Buffers 227807232
> cpu_count: 32
> log_buffer: 220798976
> public threads: 2 public (no private) 105M each
>
> primary:sys_at_ohcops1> l
> 1 select
> 2 indx,
> 3 total_bufs_kcrfa,
> 4 strand_size_kcrfa,
> 5 index_kcrf_pvt_strand,
> 6 space_kcrf_pvt_strand
> 7 from
> 8* x$kcrfstrand
> primary:sys_at_ohcops1> /
>
> INDX TOTAL_BUFS_KCRFA STRAND_SIZE_KCRFA INDEX_KCRF_PVT_STRAND
> SPACE_KCRF_PVT_STRAND
> ---------- ---------------- ----------------- ---------------------
> ---------------------
> 0 215624 110399488 0
> 0
> 1 215624 110399488 0
> 0
>
> redo logs: 256M
> archive logs: 40-43M
>
> So if each public thread takes 105M, I have ~~46M left over. Filling one
> thread and switching, as discussed in Jonathan's article, should give me
> archive logs of ~105 M. Instead, I am getting an archive log of ~ the rump
> size in the redo (256-105-105=46M).
>
> I checked the obvious (not a manual log switch, not archive_lag_target).
> I'll chime in if I find something interesting. Also wondering if any
> obvious things I'm missing off the top.
>
> Henry
> ===================================================================
>
>

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