Ist es möglich, einen sekundären Server in einem Protokollversand-Szenario als schreibgeschützt verfügbar zu haben?

Question

Ich untersuche den Protokollversand in einer SQL Server 2005-Umgebung. Die Idee war, häufigen Protokollversand zu einem sekundären Server einzurichten. Die Absicht: Verwenden Sie den sekundären Server, um Berichtsabfragen auszuführen, wodurch der primäre Datenbankserver ausgelagert wird.

stieß ich auf dieses auf einem sqlservercentral forum thread:

Wenn Sie den Protokollversand Sie die Wahl zwischen 2 haben erstellen. Sie können den Wiederherstellungsprotokoll-Vorgang so konfigurieren, dass er mit der Option "Wiederherstellung" oder mit der Standby-Option ausgeführt wird. Wenn Sie die Option "Wiederherstellen" verwenden, können Sie keine Select-Anweisungen für sie ausgeben. Wenn Sie statt der Wiederherstellung die Standby-Option verwenden, können Sie ausgewählte Abfragen in der Datenbank ausführen. Bedenken Sie mit der Standby-Option, wenn Protokolldateiwiederherstellungen auftreten Benutzer werden ohne Warnung durch den Wiederherstellungsprozess rausgeschmissen. Wenn Sie die Option Protokollversand mit Standby konfigurieren, können Sie auch zwischen zwei Optionen wählen: Alle Prozesse in der sekundären Datenbank beenden und eine Protokollwiederherstellung durchführen oder keine Protokollwiederherstellung durchführen, wenn die Datenbank verwendet wird. Wenn Sie die zweite Option auswählen, wird die Wiederherstellungsoperation möglicherweise nie ausgeführt, wenn jemand eine Verbindung zur Datenbank öffnet und sie nicht schließt. Daher ist es besser, die erste Option zu verwenden.

Also meine Fragen sind:

• Ist die oben wahr? Können Sie den Protokollversand wirklich nicht so verwenden, wie ich es vorschlage?
• Wenn es wahr ist, könnte jemand erklären, warum Sie SELECT-Anweisungen nicht in einer Datenbank ausführen können, während das Transaktionsprotokoll wiederhergestellt wird?

EDIT:

Erste Frage ist Duplikat this serverfault question. Aber ich möchte immer noch die zweite Frage beantwortet: Warum ist es nicht möglich, SELECT-Anweisungen auszuführen, während das Transaktionsprotokoll wiederhergestellt wird?

Answer 1

könnte jemand erklären, warum man nicht auf eine Datenbank SELECT-Anweisungen ausführen, während das Transaktionsprotokoll gestellt werden?

Kurze Antwort ist, dass die RESTORE-Anweisung eine exklusive Sperre für die wiederherzustellende Datenbank übernimmt.

Für schreibt, ich hoffe, es gibt keine Notwendigkeit für mich zu erklären, warum sie nicht mit einer Wiederherstellung kompatibel sind. Warum erlaubt es auch keine Lesevorgänge? Erstens gibt es keine Möglichkeit zu wissen, ob eine Sitzung, die eine Sperre für eine Datenbank hat, eine Lese- oder Schreiboperation ausführen wird. Aber selbst wenn es möglich wäre, ist die Wiederherstellung (Protokoll oder Sicherung) ein Vorgang, bei dem die Datenseiten in der Datenbank direkt aktualisiert werden. Da diese Aktualisierungen direkt zum physischen Speicherort (der Seite) gehen und nicht der logischen Hierarchie (Metadaten-Partition - Seitenzeile) folgen, würden sie mögliche Absichtssperren anderer Datenleser nicht berücksichtigen und somit die Möglichkeit haben, Strukturen zu ändern wie sie gelesen werden. Ein SELECT-Tabellen-Scan, der auf die Zeiger der nächsten Seite folgt, würde in Unordnung geraten, was zu einem fehlerhaften Lesevorgang führen würde.

Answer 2

Ja, es ist wahr.

Ich denke, folgendes passiert:
Während das Transaktionsprotokoll wiederhergestellt wird, ist die Datenbank gesperrt, da große Teile davon aktualisiert werden.
Dies ist aus Leistungsgründen mehr als alles andere.

kann ich zwei Optionen:

1. Verwenden der Datenbankspiegelung.
2. Planen Sie den Protokollversand nur dann ein, wenn das Berichtssystem nicht verwendet wird.

Answer 3

Nun ja und nein.

Sie können genau das tun, was Sie tun möchten, indem Sie Reporting-Workloads auf einen sekundären Server übertragen, indem Sie den Protokollversand auf eine schreibgeschützte Kopie einer Datenbank konfigurieren. Ich habe diese Art von Architektur früher schon mehrmals eingerichtet und es funktioniert wirklich sehr gut.

Der Nachteil besteht darin, dass für die Wiederherstellung einer Transaktionsprotokollsicherungsdatei keine weiteren Verbindungen zu der fraglichen Datenbank bestehen dürfen.Wenn der Wiederherstellungsprozess ausgeführt wird, besteht daher die Möglichkeit, dass entweder ein Fehler auftritt, wodurch Benutzerverbindungen priorisiert werden, oder es wird erfolgreich ausgeführt, indem die gesamte Benutzerverbindung getrennt wird, um die Wiederherstellung durchzuführen.

Abhängig von Ihrer Wiederherstellungsfrequenz ist dies nicht unbedingt ein Problem. Sie bringen Ihre Benutzer einfach dazu, dass Sie sagen, dass jede Stunde um 10 Uhr die Möglichkeit besteht, dass Ihr Bericht fehlschlägt. In diesem Fall führen Sie den Bericht einfach erneut aus.

EDIT: Sie möchten vielleicht auch alternative Architekturlösungen für Ihre Geschäftsanforderungen bewerten. Beispiel: Transaktionsreplikation oder Datenbankspiegelung mit einem Datenbanksnapshot

Answer 4

Geringfügige Verwirrung darin, dass das Flag für Wiederherstellung bei der Wiederherstellung bedeutet, dass Ihre Datenbank nicht aus einem Wiederherstellungsstatus und in einen Onlinestatus versetzt wird - aus diesem Grund Die Select-Anweisungen funktionieren nicht - die Datenbank ist offline. Mit dem Flag "Keine Wiederherstellung" können Sie mehrere Protokolldateien in einer Zeile (in einem DR-Szenario) wiederherstellen, ohne die Datenbank wieder online zu schalten.

Wenn Sie nicht Schiff/die Nachteile protokollieren möchten, können Sie zu einer Einweg-Transaktionsreplikation wechseln, aber der Overhead/Setup wird insgesamt komplexer sein.

Answer 5

Wenn Sie über die Enterprise-Version verfügen, können Sie mithilfe der Datenbankspiegelung + Snapshot eine schreibgeschützte Kopie der Datenbank erstellen, die für Berichte usw. verfügbar ist. Die Spiegelung verwendet den "kontinuierlichen" Protokollversand "unter der Haube". Es wird häufig in dem von Ihnen beschriebenen Szenario verwendet.

Answer 6

Würde Peer-to-Peer-Replikation funktionieren. Dann können Sie Abfragen für eine Instanz ausführen und so die Auslastung für die ursprüngliche Instanz speichern.