by
Krull >> Tue, 10 Jul 2001 0:17:20 GMT
Initially we always set quisce to true, so it would not need the logfiles when recovering the database. However this locked the entire database for the duration of the backup( ~16 mins for our largest system, with verification and compression set to true), and when the system is a busy global web site logging each hit, that was soon thrown out the window. We now have quisce set to false which does not lock the database but does require the logfiles when recovering the database, which means ArchivalRecovery must be turned on and you must keep old logfiles at least up until your last online backup.
If ArchivalRecovery is disabled, the JADE backup process ensures that only a single transaction log is required for backup recovery and takes a backup of this transaction to the default backup directory automatically. That is the only log required to recover an online backup to a consistent state. If you believe that you don't need roll-foward capability ( normally only the case for non-business critical systems), then you can leave ArchivalRecovery disabled without invalidating your online backups.
I have been meaning to for a while now,
writting in some code to delete the old logfiles after the online backup, since I don't think Jade does this itself.
It certainly doesn't remove the logs if ArchivalRecovery is enabled, that's what the option means "don't remove the logs so that they can be used for archival or roll-forward recovery". Most sites with business (or mission) critical systems require that transaction logs are retained so that they can perform a roll-forward recovery in the event of a disk subsystem failure (media or controller etc.).
It is worth pointing out here that if you are depending on being able to use roll-forward recovery in the event of a catastrophic failure to the disk-subsystem hosting your data files, it is *essential* that the transaction logs are on a completely separate disk-subystem with a separate cables and controller. It is also *essential* that the transaction-log subsystem is mirrored and highly recommended that the data file subsystem is mirrored as well. This typically means use of RAID 1 combinations with striping for performance e.g RAID 10 or 0+1. Some sites have located tran logs and data on a common RAID 5 subsystem with the belief that RAID 5 will protect them against media failure, However, RAID 5 can only handle single drive failures; whereas a common controller or cable failure can corrupt the entire array!
One of our apps produces ~10-15
12Mb logfiles a day (and every Monday ~35-40 files). As you can probably imagine if we forget to manually delete the old logfiles for a week or so, we have about 2Gb+ of logfiles waiting for us!