It is recommended that you use a transaction log mirror when running high-volume or extremely critical applications. For example, at a consolidated database in a SQL Remote setup, replication relies on the transaction log, and if the transaction log is damaged or becomes corrupt, data replication can fail.
If you are using a mirrored transaction log, and an error occurs while trying to write to one of the logs (for example, if the disk is full), the database server stops. The purpose of a transaction log mirror is to ensure complete recoverability in the case of media failure on either log device; this purpose would be lost if the server continued with a single log.
You can specify the -fc option when starting the database server to implement a callback function when the database server encounters a file system full condition. See -fc server option.
There is a performance penalty for using a mirrored log as each database log write operation must be performed twice. The performance penalty depends on the nature and volume of database traffic and on the physical configuration of the database and logs.
A transaction log mirror should be kept on a separate device from the transaction log. This improves performance. Also, if either device fails, the other copy of the log keeps the data safe for recovery.
Alternatives to a mirrored transaction log are to use a disk controller that provides hardware mirroring, or operating-system level software mirroring, as provided by Windows and NetWare. Generally, hardware mirroring is more expensive, but provides better performance.
Live backups provide additional protection that has some similarities to transaction log mirroring. See Differences between live backups and transaction log mirrors.
For information about creating a database with a mirrored transaction log, see Initialization utility (dbinit).
For information about changing an existing database to use a mirrored transaction log, see Transaction Log utility (dblog).