archive_lag_target is set to 0
the log sizes are 500 mb
the alert logs only indicate the lgwr switch. nothing else. if we dont switch logs we dont see this happen

Could there be multiple log_archive_dest parameters/locations defined? That would generate multiple archived logs.

Even with archived logs for Data Guard going to a (hopefully) remote destination, there could be other locations defined that may have served a purpose at some stage but no longer do so. Maybe another diskgroup within ASM or even on the OS filesystem like in the $ORACLE_HOME/dbs directory?

We used to have multiple log_archive_dest defined in our pre-Data Guard, raw logical volume, 10G days before we moved to ASM and 11G. One set of logs would go to the local filesystem (before being backed up to tape) and then another would reside in a remote filesystem presented from a server located in our other data centre.

When you get multiple archived log files from one log switch how big are the resulting files ? Is it one big and lots of tiny, or all roughly the same size with the final one being smaller ? (or any other pattern).

Are you running RAC - you get a reguler "log file kick" from every node to keep log files synch'ed. It shouldn't make a dramatic difference, though.

Can you check sessions to see if you have any that generate significant redo over their lifetime: (v$sesstat, statistic "redo size") - a running instance is never really idle. If you don't have any sessions generating significant redo can you check the rate at which sessions connect and disconnect.

Remember on non-RAC that "private redo" reserves space in log files. If you have a very high setting for sessions you get a lot of private threads, which means a large amount of space reserved in the online log file, so could waste a LOT of space on each log file switch.


Regards
Jonathan Lewis

Audit alter system.

Check to whom alter system or DBA is granted.

Check scheduler jobs

Check triggers