Die Computer, auf denen Primär- und Spiegelserver laufen, sollten mit ähnlicher Hardware (Prozessor, Festplatte, Speicher etc.) konfiguriert sein. Der auf einem der Computer laufende Datenbankserver kann jederzeit als Primärserver für die gespiegelte Datenbank fungieren. Die Auslastung des Spiegelservers ist normalerweise niedrig und hängt von der Häufigkeit der Aktualisierungen auf dem Primärserver ab und von der Verarbeitungslast, die durch schreibgeschützte Verbindungen mit dem Spiegelserver erzeugt wird.

Die Performance von Transaktionen, die die Datenbank aktualisieren, hängt von der Größe der Transaktionen und der Häufigkeit von Festschreibungen ab. Wenn die Größe der Transaktionen oder der Häufigkeit der Festschreibungen erhöht wird, interagiert der Primärserver mehr mit dem Spiegelserver, wodurch zusätzliche Möglichkeiten von Verzögerungen auf dem Primärserver entstehen und der Benutzer diese möglicherweise bemerkt.

Die Abfrageperformance auf dem Primärserver wird von einer Spiegelung im Allgemeinen nicht beeinflusst. Wenn Ihre Anwendung mehr Lesevorgänge als Aktualisierungen hat und Auditing nicht aktiviert ist, werden Sie wahrscheinlich keine Veränderung der Performance des Primärservers feststellen. Wenn für die Datenbank das Auditing aktiviert ist, kann eine Veränderung der Performance feststellbar werden, weil beim Auditing zusätzliche Informationen in das Transaktionslog geschrieben werden.

Die Performance Ihrer Clientanwendungen kann durch die Netzwerkverbindung zwischen den Servern im Spiegelungssystem beeinflusst werden, v. a. wenn sich die Server an verschiedenen Standorten befinden. Eine langsame Netzwerkverbindung zwischen den Servern kann die Performance Ihrer Clientanwendungen ebenfalls beeinträchtigen.

Ein Spiegelungssystem, das im asynchronen oder Asynchron-Ganzseiten-Modus (asyncfullpage) läuft, veranlasst den Primärserver weniger häufig zu Wartephasen als wenn der synchrone Modus verwendet wird. Jedoch auch im asynchronen oder asyncfullpage-Modus muss bei gesendeten Nachrichten vom Primärserver an den Spiegelserver auf eine Bestätigung vom Spiegelserver gewartet werden, wodurch sich Verzögerungen ergeben könnten. Außerdem ist das Senden von Paketen an den Spiegelserver mit einem geringen Overhead verbunden. Der asynchrone Modus und der Asynchron-Ganzseiten-Modus werden nicht empfohlen, da Transaktionen verloren gehen können.

Unvollständige Transaktionen müssen zurückgesetzt werden, wenn der Spiegelserver Eigentümer der Datenbank wird, und je länger eine Transaktion ist, desto länger dauert das Rollback. Die Wiederherstellungsgeschwindigkeit bei einem Failover hängt von der Anzahl der Clients und von der Länge ihrer Transaktionen ab, die zurückgesetzt werden müssen. Wenn die Wiederherstellungsgeschwindigkeit wichtig ist, sollten Sie Ihre Anwendung so planen, dass sie nach Möglichkeit kurze Transaktionen verwendet.