Handling log files is another concern. You must either identify the log files that need to be replayed into the databases or remove the checkpoint file so that all transaction logs are replayed. I prefer the latter method, which is more foolproof and which replays committed log files at as fast a rate as 4 seconds per file (the rate I achieve on my servers by using a hardware RAID controller with a mirrored pair of log disks). Of course, your mileage might vary—I've seen some servers run up to 1 minute per log file when dealing with many files—but as long as you don't let outstanding transaction log files grow to some ridiculous number, you're looking at an outage of minutes instead of hours. The key is to purge your log files with an online APIbased backup before you perform your nightly clone split. You'll then know that you have a BCV for recovery and that the log files have been purged.
If you want to reduce log-replay time by finding only the exact log sequence numbers to replay, you must run
eseutil /mh <database name>
to find the Log Signature value in the database header, then match this value to the log sequence. Doing so will ensure that you're specifying the correct log files (e.g., E00xxxxx.log) for that database. This method is more difficult, though, because you must dump the signature, match it to the log files, and remove the log files that don't need to be replayed. These processes can introduce error, when instead you can remove the checkpoint and let Exchange blast through the log files. . . .
