none
SQL-Server Restore ohne Unterbruch RRS feed

  • 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

    Mittwoch, 26. März 2014 14:15

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]

    Mittwoch, 26. März 2014 14:21
  • Hi

    Gibt es eine Möglichkeit nicht die gesamte DB zu restoren sondern Zeilenweise die Änderungen? DB hat leider recht viele Beziehungen...

    Würde "Failover Partner" etwas bringen?

    Danke

    Mittwoch, 26. März 2014 14:48
  • 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]

    Mittwoch, 26. März 2014 15:14
  • 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

    Mittwoch, 26. März 2014 19:33
  • 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
    Donnerstag, 27. März 2014 07:12
  • 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]


    Donnerstag, 27. März 2014 17:17
  • Hallo zusammen

    danke für die antworten. werde jetzt die Datenbank gleichwohl kurz mit single_user trennen und dann denn restore mache...

    gruss

    Mittwoch, 9. April 2014 09:08