Wie gehen Sie in großen Serverumgebungen mit dem Problem der Sicherung von SQL Server-Datenbanken um, die möglicherweise nicht mit anderen Datenbanken synchronisiert sind, auf die sie angewiesen sind?
Wenn ich also DB1 von einem Server sichere und es wird eine andere Datenbank verwendet, die nicht gesichert ist, könnte eine Wiederherstellung, wenn die Datenbanken in unterschiedlichem Zustand sind, Probleme verursachen? Es scheint, als ob alle abhängigen Datenbanken gesichert werden sollten, unabhängig von ihrer Größe usw., aber in meinem aktuellen Job (wir sind ein Rechenzentrumsunternehmen und ich bin ein .NET-Entwickler) sichere ich nur einige von mehreren abhängigen Datenbanken auf einer SQL Server-Instanz.
Danke
Antwort1
Als Erstes müssen Sie ALLE Datenbanken sichern, Punkt. Insbesondere, wenn Abhängigkeiten von anderen Datenbanken bestehen. Ihre abhängigen Datenbanksicherungen sind nutzlos, wenn sie auf dem Status anderer Datenbanken basieren, die nicht gesichert sind.
Allerdings gibt es eine Vielzahl von Möglichkeiten, das beschriebene Statusproblem zu beheben, je nachdem, welche Art von Anwendung Ihre Datenbanken unterstützen. Ihre Sicherungsstrategie muss mit der Architektur Ihrer Anwendung Hand in Hand gehen. Idealerweise ist Ihre Anwendungsarchitektur auf Sicherungen ausgelegt.
Handelt es sich bei Ihrer Anwendung um ein Echtzeit-Eingabesystem (beispielsweise ein Online-Shop), stehen Sie vor der Aufgabe, alle relevanten Datenbanken auf einen bestimmten Zeitpunkt zurückzusetzen.
Wenn Ihre Anwendung eher ein berechnetes Berichtssystem ist, bei dem der Systemstatus zum Zeitpunkt der letzten Berechnung stabil ist, können Sie möglicherweise einige Zeit nach Abschluss der Berechnungen vollständige Datenbanksicherungen durchführen. Sie müssen auch Benutzereingaben nach Abschluss der Berechnungen berücksichtigen, möglicherweise eine Wiederherstellung aus einer vollständigen Sicherung und anschließend rollierende Übertragungsprotokolle.
Dies sind einige Ideen. Hoffentlich können sie Ihnen helfen, eine Lösung zu finden.