Ideally, the computers running the primary and mirror servers should be configured with similar hardware (processor, disk, memory, and so on). At any given time, the database server running on either computer can be acting as the primary server for the database being mirrored. The mirror server utilization is typically be low, depending on update activity on the primary.

The performance of transactions that update the database depends on the size of the transaction and the frequency of commits. Increasing either the size of the transactions or the frequency of the commits causes the primary server to interact more with the mirror server, creating more opportunities for the primary server to be delayed and for the user to notice those delays.

The performance of queries against the primary server is usually not affected by mirroring. If your application does more reads than updates and auditing is not enabled, you are unlikely to experience a change in the performance of the primary server. But, if database auditing is enabled, you may experience a change in performance because auditing writes additional information to the transaction log.

A mirroring system running in either asynchronous or asyncfullpage mode requires the primary server to wait in fewer cases than when running in synchronous mode. But, even in asynchronous or asyncfullpage mode, some of the messages sent from the primary server to the mirror server wait for an acknowledgement from the mirror, potentially introducing delays. In addition, there is a small amount of overhead in sending packets to the mirror.

The performance of your client applications can be affected by the network connection between the servers in the mirroring system, especially when the servers are located in different geographic locations. A slow network connection between the servers can degrade the performance of your client applications.

 See also