Skip to Main Content

Breadcrumb

Question and Answer

Chris Saxon

Thanks for the question, Radoslav.

Asked: October 10, 2016 - 11:35 am UTC

Last updated: October 12, 2016 - 3:40 am UTC

Version: 11.2.0.3.6

Viewed 1000+ times

You Asked

Hi There,

I found slow performing pl/sql functionality indicated to be slow only when a backup of rachivelog is in progress.

Checking the events using AWR and ASH reports there is clear indication for "Log file sync" waiting event for a delete from temporary table. As this is always happening while the archivelog backup is running I just decided to check the backup script.

And here it is:

run{
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
backup current controlfile;
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
backup archivelog all not backed up 1 times;
DELETE archivelog UNTIL TIME 'SYSDATE-1' BACKED UP 1 TIMES TO DEVICE TYPE DISK;
}


I do not see a valid reason why this backup have "ALTER SYSTEM ARCHIVE LOG CURRENT" 3 times in the backup script.
As I am aware the "ARCHIVE LOG CURRENT" is automatically initiated when "BACKUP ARCHIVELOG ALL" is used.

Also I am while the checkpoint is in progress no one can write to the redo logs and this is happening every 1h. on this database for really long time.

Could you please provide with your opinion on this backup setup and advice for the best way to backup the archives on hourly base.

My option is:

run{
backup archivelog all not backed up 1 times;
DELETE archivelog UNTIL TIME 'SYSDATE-1' BACKED UP 1 TIMES TO DEVICE TYPE DISK;
backup current controlfile;
}

and Connor said...

log file sync is waiting for a response from the log writer...which *might* be due to IO, but *might* be due to other things.

So firstly, check "log file parallel write" for the lgwr process to see how it is going during these backup times. If it is slowing down, then you potentially have an I/O load issue, so whether you are doing archivelog current or not might not be the issue, more just that during backups you are pounding your I/O subsystem.

If log file parallel write does *not* change, but log file sync does, then it might be a CPU issue (lgwr not getting enough action) - once again, this means a different issue to tackle.

Outside of this discussion, I dont see an issue with your proposed script.

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

log file sync + log file parallel write

Radoslav Stanoev, October 11, 2016 - 2:42 pm UTC

Thanks Connor,

I have checked "log file parallel write" and it has avg of 0ms in the AWR reports.

The log file sync is 4ms per transaction and I am having 11 "user calls" per transaction.
The log switches per hour are 4 with a redo log size of 10gb.
The redo group is on SSD drives.


I do not see ant LGWR I/O issue based on the above numbers. Already removed the "alter system archive log current" command from the backups to see what will be the result.

Will let you know tomorrow how the event looks after this change.

Regards
Chris Saxon
October 12, 2016 - 3:40 am UTC

Keep us posted

More to Explore

Backup/Recovery

Check out the complete guide to all of the Backup & Recovery techniques in the Oracle Database.