Let me tell you a story...
Not too long ago a company (who was not a customer of mine) was in the habit of disabling after-imaging every weekend, making a new backup, and the re-enabling after imaging. This is a process that they inherited from the application vendor. I think it might have been created because they liked having the ai sequence numbers restart with 1 on a regular basis. But I'm just guessing.
It just so happens that various things related to Super Storm Sandy resulted in various power outages and other unpleasantness at around the same time that this weekly process was being executed.
They ended up with disabled after-imaging and a week-old backup. But nobody noticed the disabled after-imaging until the data center was under water a couple of days later. So several days worth of data was simply not recoverable...
A friend called looking for some help. There really wasn't anything that could be done except to learn from the experience.
Do not routinely disable after-imaging.
And if you do disable after-imaging for non-routine reasons be damned sure that it is properly re-enabled and running correctly before you let production transactions resume.
To answer your questions above -- backups cause an extent switch. Disabling after-imaging causes the ai sequence number to be reset. There is NO reason to disable after-imaging in order to backup. You can attempt to apply any ai log file to a restored db -- if it is the wrong sequence you will get an error message that, happily, tells you which sequence number you should have used. No harm is done to your target db.
