Welche objektiven Faktoren weisen darauf hin, dass es Zeit ist, die SQL Server-Replikation zu implementieren?

Ich versuche, ein Gleichgewicht zwischen der hohen Leistung unserer Datenbank und der einfachen Wartung zu finden. Wir erwägen, die Replikation zu verwenden, um die Leistung zu verbessern, indem wir unsere SSRS-Berichte in eine physisch von unserer Transaktionsdatenbank getrennte Datenbank replizieren. Das Aktivieren der Replikation weist jedoch aus Entwicklersicht eine Reihe von Nachteilen auf:

• Dies erschwert Schemaänderungen
• Es stört unseren automatisierten Integrations- / Build-Server
• Es scheint schwierig zu sein, die SQL-Quellcodeverwaltung zu implementieren

Meine Frage lautet : Wann wissen Sie, dass es angesichts dieser Nachteile an der Zeit ist, mit der Replikation zu beginnen? Wie entscheiden Sie, ob die zusätzliche Komplexität die Gewinne rechtfertigt?

Wir haben es bereits verwendet, daher ist das Einrichten kein Problem. Hier geht es mehr darum, die Entscheidung zu treffen, es zu aktivieren oder nicht. Ich suche nach einigen Objektleistungsmetriken, die andere bei der Replikation beobachtet haben.

Das Beste wäre natürlich, einige simulierte Lasttests auf unseren eigenen Servern durchzuführen und es selbst herauszufinden, aber ich hoffe, dass es da draußen einige allgemeine Richtlinien gibt.

Die Replikation sollte während der Entwurfsphase der Anwendung berücksichtigt werden. Wenn Sie über eine geografisch verteilte Belegschaft / Nutzerbasis verfügen, kann es sinnvoll sein, regionale Datenbanken und zentrale Datenbanken zu haben. Getrennte Datenbanken auf Laptops können "synchronisiert" werden, wenn sie sich endlich wieder mit dem Netzwerk verbinden (denken Sie an Vertriebsmitarbeiter unterwegs).

Für Berichtszwecke ist die Replikation NICHT die Antwort. Die meisten Leistungsprobleme in einer Berichtsumgebung sind darauf zurückzuführen, dass die Berichte für ein System geschrieben werden, das für die Online-Transaktionsverarbeitung (OLTP) konfiguriert ist.

Bei der Replikation für Berichtszwecke werden Ihre OLTP-Daten einfach auf einen anderen Server verschoben, wobei jedoch die gleiche unfreundliche Struktur beibehalten wird. Im Wesentlichen werfen Sie mehr Hardware auf das Problem und erhöhen Ihre Wartungskosten, aber für marginale Gewinne.

Was Sie sich ansehen sollten, ist, wie Sie die spezifischen Daten, die Ihre Berichte benötigen, abrufen und in ein nützlicheres Format umwandeln können. Erstellen Sie einen Feed, der neue Transaktionen aus Ihrer Produktionsdatenbank abruft und in einer Berichtsdatenbank speichert, vorzugsweise auf einem separaten Server. Jedes Mal, wenn der Feed ausgeführt wird, sollte er alle Daten erfassen, die neuer als beim letzten Ausführen sind, diese Daten transformieren und speichern. Die Berichte, die Sie derzeit ausführen, geben Ihnen einen guten Überblick über die Arten der erforderlichen Transformationen.

Wenn Sie diesem Ansatz folgen, profitieren Sie von enormen Leistungsvorteilen.

Wir haben festgestellt, dass die Replikation in einer ähnlichen Situation hilfreich ist, da die Berichtsersteller die Indizes für die replizierte Datenbank "besitzen" können. Dies hat uns die Möglichkeit gegeben, die Abfrageleistung durch Hinzufügen von Indizes zu verbessern, die die Anwendungsentwickler aufgrund ihrer negativen Auswirkungen auf INSERTS und UPDATES in der Produktion niemals genehmigt hätten.

Vielleicht besteht ein Teil Ihres Anwendungsfalls darin, einige Transaktionstabellen zu kopieren, die Indizierung zu ändern und zu prüfen, ob es sich lohnt?

Hoffe das hilft!