C
ChUIMonster
Guest
Since you brought it up... I don't like purging archived after image logs. I especially don't like purge periods measured in days. If you must do it at all try 3 months as a minimum. They probably don't take up all that much space relative to your db size. (And they zip very nicely.) On several occasions I have been able to rescue customers whose backups had failed one way or another (usually bad scripts, but sometimes hardware problems) only because there was an old forgotten copy of a backup somewhere on the hard drive and a lot of archived ai files. The most spectacular is the one that Tim refers to. In that case roughly a year's worth of ai files were rolled forward against the *original* backup. That happened because the off-site destination for the ai logs disappeared at some point shortly after the sysadmin left the company. When he left nobody replaced him so all of the alert messages were going to an unread e-mail. (There are several very important lessons here...) Then the hard drive with the db on it crashed. The customer dug out their recovery procedures and discovered that the backup server was nowhere to be found. (So far as I know they never did find it.) At that point I got a call... Lucky for the customer they had two drives in that server and when I had originally setup the server I put a copy of that 1st backup on the 2nd drive. And the first part of getting the ai files offsite was to copy them to that 2nd server. Since nobody ever purged them there was a year or so of ai logs ready and willing to roll forward. It took all weekend to get through the roll-forward but that was much preferable to having no data at all. Some Important Lessons: 1) Keep as many ai files and old backups as you can. One old backup that works and lots of ai files can work wonders. 2) Don't put all of your alerting eggs in one mailbox. 3) When key personnel leave get someone to make sure loose ends get taken care of.
Continue reading...
Continue reading...