Fragensteller
SQL-Server Restore ohne Unterbruch

Allgemeine Diskussion
-
Hallo Leute
Ich habe eine SQL-Server DB die regelmässig gesichert wird (per SQLCMD Backup) und auf einen anderen SQL-Server Restored.
Die Clients die auf den zweiten SQL-Server zugreifen, haben nur Leserechte (nur Datenanzeige für eine Website).
Mein Problem: Ich kann die DB nur Restoren wenn keine Verbindungen (TCP) auf die DB vorhanden sind. Wie schaffe ich es die DB trotzdem zu restoren (SINGE_USER zeugs ist nicht wirklich brauchbar, da es mit die Verbindungen trennt und dann bekomme ich Fehlermeldungen auf der Website....)
SQL-Express 2012.
Danke
- Typ geändert Raul TalmaciuMicrosoft contingent staff Dienstag, 1. April 2014 08:47 Warten auf Feedback
Alle Antworten
-
Hallo,
ein Restore über eine vorhandene Datenbank ist nur möglich, wenn absolute keine Verbindung zu der Datenbank offen ist; da führt nichts daran vorbei.
Um die Downtime gering zu halten, könntest Du das Restore als neue Datenbank durchführen, die alte Datenbank dann droppen, und die neue Umbenennen. Aber auch dazu brauchst Du kurzzeitig exklusiven Zugriff auf die DB's; heisst vorhandene Verbindungen müssen beendet werden. Wenn Die Applikation damit nicht klar kommt, sollte dort nachgebessert werden, denn es kann immer mal zu einem kurzfristigen Verbindungsabbruch kommen.
Olaf Helper
[ Blog] [ Xing] [ MVP] -
Mit der Express Edition des SQL Servers hast Du nur eingeschränkte Möglichkeiten, so was wie Change Data Capture gibt es da nicht.
Das hängt etwas von der Datenbank mit ab. Wenn es nur ein paar Tabellen sind, könntest Du das Restore auf eine andere (neue) Datenbank durchführen und von dort die fehlenden Daten rüber kopieren / Änderungen aktualisieren etc.
Olaf Helper
[ Blog] [ Xing] [ MVP] -
Ich würde hier 2 Ansätze evaluieren:
entweder, wenn die eigentlich neuen daten geringen Umfanges gegenüber der Gesamtmenge sind, eine Synchronisation nur dieser Daten mittels beispielsweise T-SQL zu implementieren
Oder mittels Logshipping im Standby-Modus eine kürzere Ausfallzeit erreichen.
Ansonsten ist die Express Edition halt nicht für "Hochverfügbarkeitsszenarien" gedacht und ausreichend. Da muss es dann schon Standard Edition mit dem alten Mirroring, oder Enterprise mit AlwaysOn sein.
Das ist dann natürlich eine ganz andere Preiskategorie. Aber wenn Sekunden Ausfall ein Problem sind, befindet man sich im Bereich der Hochverfügbarkeit" mit den bekannten "9en", und die rechtfertig eben schon "Enterprise"
Andreas Wolter (Blog | Twitter)
MCM - Microsoft Certified Master SQL Server 2008
MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.andreas-wolter.com | www.SarpedonQualityLab.com -
Hi zusammen
Danke für die Antworten.
Was ich mir auch überlegt habe, ist 2 Instanzen zu laufen zu lassen, danach immer Abwechselnd Restore auf den nicht benutzten Server machen und per Portforwarding immer auf die richtige Instanz Switchen... Aber wenn halt Verbindungen bestehen, würden die wahrscheinlich durch den Switch abgebrochen...
Bezüglich T-SQL Lösung:
Gibt es eine relativ simple Möglichkeit das per T-SQL hinzukriegen? Das Problem ist sicher nicht die Datenmenge, aber ich habe relativ viele Beziehungen...
- Bearbeitet Beni_i Donnerstag, 27. März 2014 07:13
-
Aber wenn halt Verbindungen bestehen, würden die wahrscheinlich durch den Switch abgebrochen...
Nicht nur würde, sie werden es garantiert. Der Client bau eine Verbindung zum Server auf und erhält eine Session; die kann nicht von einem auf den anderem Server wechseln.
Im SQL Server besteht mit Hilfe von 3-Part-Qualifiern = "DatenbankName.Schema.Tabelle" die Möglichkeit, Datenbank-übergreifend zu arbeiten (Berechtigungen vorausgesetzt. Also z.B. als ganze Simples Beispiel um fehlende Datensätze von der "KopieDB" in die "HauptDB" zu kopieren:
INSERT INTO HauptDB.dbo.Tabelle (Col1, Col2, ...) SELECT Col1, Col2, ... FROM KopieDB.dbo.Tabelle AS SRC WHERE NOT PKCol IN (SELECT PKCol FROM HauptDB.dbo.Tabelle)
Und wenn Du dabei den MERGE (Transact-SQL) Befehl verwendest, kann Du in einem Rutsch fehlende einfügen, vorhandene aktualisieren und gelöscht ebenso entfernen.
Am Besten dies für alle Tabellen in eine Stored Procedure in der "HauptDB" packen und die nach dem Restore auf die "KopieDB" aufrufen.
Olaf Helper
[ Blog] [ Xing] [ MVP]- Bearbeitet Olaf HelperMVP Donnerstag, 27. März 2014 17:18
-
Hallo,
bist Du hier weitergekommen?
Gruss,
RaulRaul Talmaciu, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.