Kent, The normal procedure is to run the INACTIVATELOGS command after a full backup so that only the logs necessary to restore the active full backups, remain active.
It will only "break" the PIT restores if you do not have your policy settings correct. If your policy settings are set up so that you keep the inactive log backups, they still can be used to apply to the inactive backups to which they are associated. On the flip side, if you have your settings so that the inactive logs are deleted (RETONLY=0), then they will be deleted and not available for recovery. With Bill's strategy... he will be able to restore any database and apply logs (with PIT, if desired) for up to 1 week. For any database backup older than a week, he will only be able to restore the full database backup... which is what I think his goal was. Keep in mind... you can always restore a full backup without applying any logs. In this case, the database restored will be at the point of backup. Thanks, Del ---------------------------------------------------- Won't running INACTIVATELOGS immediately after a full backup potentially break PIT restores from the prior full backups? To preserve PIT restore capability, it seems to me INACTIVATELOGS should be scheduled just before a full backup, rather than after, and perhaps less frequently. Also, for PIT restores from older backups, don't you need to keep all transaction logs at least as long as the oldest full backup?
