Chuck Bell wrote:
> Rafal,
>
> ...
>
>> 1. Please explain what is your idea of how the PURGE statements will
>> behave if there is an ongoing BACKUP/RESTORE operation and vice versa
>> (how BACKUP/RESTORE should behave if there is ongoing PURGE operation).
>
> This has been tested. If a backup is running and a PURGE BACKUP LOGS
> command is issued at the same time, the normal locks on the logs will
> apply. The logs are designed to handle this situation. Indeed, a test I
> have been able to reproduce where I stop a backup after it has initiated
> the log handle and then issue a PURGE BACKUP LOGS; shows that upon
> completion of the backup, the backup history table has 1 row (the
> correct one), and the backup_progress has the corresponding progress rows.
>
This sounds good. I expected that table locks should handle the situation and
good to hear that you have a test for that - I think it should be included in
the test script. The test should not forget to check what happens in this
situation when logging is done to files instead of tables.
> However, it is possible to construct a scenario where the PURGE occurs
> near the end of the backup (or restore) and thereby (if a PURGE BACKUP
> LOGS; has been issued) it is possible that there will be no rows in the
> backup_progress log and under the right circumstance no rows in the
> backup_history log. But such is the power of the PURGE BACKUP LOGS command.
>
I agree - this is OK because DBA has issued PURGE BACKUP LOGS so no one should
be surprised that logs are empty after that :)
> Note: I am talking about the least restrictive form of the command
> designed to remove all log entries.
>
> If you feel strongly this is not desired, then we can add a new
> requirement that the purge may not run at the same time as a backup or
> restore, but I really don't see the need for such a limitation.
>
No, no need for new requirement. Just make sure that the test script covers this
scenario.
Rafal
