none
Datenbank kopieren unter 2008 R2 RRS feed

  • Frage

  • Hallo,

    Zunächst mal der IST-Zustand:

    Ich habe 2 Server (ServerA und ServerB, beide befinden sich in der selben Domäne). ServerA ist der produktive Server, ServerB ist momentan noch nackig. Auf beiden läuft SQL Server 2008R2.

    ServerB soll ein "Echtzeit"-Backupserver werden und im Falle eines Ausfalls von ServerA einspringen.
    Das "Echtzeit-Backup" wollte ich über ein Transaction-Log-Shipping realisieren, da vor einiger Zeit entschieden wurde die Enterprise Lizenzen down zu graden, da eh keine Enterprise-Only Features genutzt wurden und denen einen Clustering zu teuer war. Zudem habe ich auch an eine Spiegelung gedacht. Nur habe ich da Angst, falls es auf ServerA zu einem Transaction-Log überlauf kommt, dass das System abstürtzt und es zu Datenverlusten kommt (ist nämlich schon einmal passiert). Da liefen mehrere Jobs gleichzeit (u.a. Rebuild Index, transaction.log backup, etc) Das kam dann dazu, dass das Transaction-Log so voll wurde das der Festplattenspeicher nicht mehr ausreichte.

    Nun möchte ich die bestehenden Datenbanken vom ServerA auf den ServerB, samt Logins, Jobs, Stored Procedures etc, kopieren. Dies habe ich zunächst mit den Copy Database Wizard versucht, der jedoch jedes mal fehlschlägt.

    Mit einem Backup/Restore könnte ich es auch machen, ABER da ich ja Log-Shipping nutzen möchte UND weiterhin lesenden und schreibenden Zugriff haben möchte, weiß ich ehrlich gesagt nicht welchen Modus ich da für das Restore nutzen soll.

    Detach und attach ist nicht möglich, da sich es auf dem ServerA um produktive 24/7/365 laufende Datenbanken handelt.

    Was gibt es für Möglichkeiten die Datenbanken samt Logins, Stored Procedures etc, zu kopieren und auch fürs Log-Shipping und lesend/schreibend Modus benutzbar zu machen?

    Wir haben extra einen Service-User in unserer Domäne eingerichtet, der solche Jobs erledigen soll. Dieser User hat sysadmin-Rechte auf beiden Systemen.

    Vielen Dank schon mal im voraus.

    Montag, 2. Dezember 2013 11:17

Antworten

  • Okay. In einem Technik-Forum muss ich das halt schon genau nehmen ;)

    Ja, bei der Spiegelung kann das passieren, da sie eben "synchron" läuft.

    Ist aber kein problem der Spigelung, sondern ein prinzipielles:

    Man sollte einen Job haben, der sein log auf Füllstand überwacht (dafür gibt es PerfLog Counter) und dann entsprechend reagiert wenn es eng wird.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Montag, 2. Dezember 2013 13:49
  • ...

    ServerB soll ein "Echtzeit"-Backupserver werden und im Falle eines Ausfalls von ServerA einspringen.
    (1) Das "Echtzeit-Backup" wollte ich über ein Transaction-Log-Shipping realisieren, da vor einiger Zeit entschieden wurde die Enterprise Lizenzen down zu graden, da eh keine Enterprise-Only Features genutzt wurden und denen einen Clustering zu teuer war. Zudem habe ich auch an eine Spiegelung gedacht. Nur habe ich da Angst, (2) falls es auf ServerA zu einem Transaction-Log überlauf kommt, dass das System abstürtzt und es zu Datenverlusten kommt (ist nämlich schon einmal passiert). Da liefen mehrere Jobs gleichzeit (u.a. Rebuild Index, transaction.log backup, etc) Das kam dann dazu, dass das Transaction-Log so voll wurde das der Festplattenspeicher nicht mehr ausreichte.

    (3) Nun möchte ich die bestehenden Datenbanken vom ServerA auf den ServerB, samt Logins, Jobs, Stored Procedures etc, kopieren. Dies habe ich zunächst mit den Copy Database Wizard versucht, der jedoch jedes mal fehlschlägt.

    (4) Mit einem Backup/Restore könnte ich es auch machen, ABER da ich ja Log-Shipping nutzen möchte UND weiterhin lesenden und schreibenden Zugriff haben möchte, weiß ich ehrlich gesagt nicht welchen Modus ich da für das Restore nutzen soll.

    (5) Detach und attach ist nicht möglich, da sich es auf dem ServerA um produktive 24/7/365 laufende Datenbanken handelt.

    (6) Was gibt es für Möglichkeiten die Datenbanken samt Logins, Stored Procedures etc, zu kopieren und auch fürs Log-Shipping und lesend/schreibend Modus benutzbar zu machen?

    Wir haben extra einen Service-User in unserer Domäne eingerichtet, der solche Jobs erledigen soll. Dieser User hat sysadmin-Rechte auf beiden Systemen.

    ...

     

    Ich versuche auf die einzelnen Punkte mal kurz einzugehen

    1. Log-Shipping kann niemals „Echtzeit“ sein. Die einzige Möglichkeit „Echtzeit“ synchron zu sein, ist Datenbankspiegelung/eine AlwaysOn Availability Group im synchronen Modus. Jede andere Technik hat vom Ansatz her schon Versatz, egal wie niedrig.
    2. SQL Server stürzt nicht aufgrund eines vollen Logs ab. Das kann maximal eine darauf zugreifende Applikation tun, die mit den dabei auftretenden Fehlern nicht umgehen kann. Ansonsten gehört es zu den absoluten Basics, wenn man schon über HA nachdenkt, einen solchen Umstand schon im Entstehen abzufangen.
    3. + 6 Logins gehören nicht zu Datenbank. Die liegen auf Server-Ebene. Datenbanken mit dem Wizard zu „kopieren“ ist nur für wirklich kleine Systeme brauchbar. Ansonsten haben wir dafür ja extra backup & restore ;-) Für die Logins und andere Server-Objekte brauchst Du einen Script. (sp_revlogins gibt’s als download von MS: http://support.microsoft.com/kb/918992)
    4. Der Zusammenhang ist mir nicht klar hier. Ich glaube da herrscht noch einige Unsicherheit bezüglich der Natur von Logshipping und der benötigten HA-Architektur.
    5. Richtig, und das wäre auch nicht wirklich sinnvoll, insofern da nichts weiter probieren :-)
    6. Hier darf gern noch jemand anderes ausführlich drauf eingehen, sofern es sich noch nicht aus dem genannten erschließt. Log-Shipping und Schreibbare Kopie geht natürlich nicht.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com



    Montag, 2. Dezember 2013 13:13

Alle Antworten

  • ...

    ServerB soll ein "Echtzeit"-Backupserver werden und im Falle eines Ausfalls von ServerA einspringen.
    (1) Das "Echtzeit-Backup" wollte ich über ein Transaction-Log-Shipping realisieren, da vor einiger Zeit entschieden wurde die Enterprise Lizenzen down zu graden, da eh keine Enterprise-Only Features genutzt wurden und denen einen Clustering zu teuer war. Zudem habe ich auch an eine Spiegelung gedacht. Nur habe ich da Angst, (2) falls es auf ServerA zu einem Transaction-Log überlauf kommt, dass das System abstürtzt und es zu Datenverlusten kommt (ist nämlich schon einmal passiert). Da liefen mehrere Jobs gleichzeit (u.a. Rebuild Index, transaction.log backup, etc) Das kam dann dazu, dass das Transaction-Log so voll wurde das der Festplattenspeicher nicht mehr ausreichte.

    (3) Nun möchte ich die bestehenden Datenbanken vom ServerA auf den ServerB, samt Logins, Jobs, Stored Procedures etc, kopieren. Dies habe ich zunächst mit den Copy Database Wizard versucht, der jedoch jedes mal fehlschlägt.

    (4) Mit einem Backup/Restore könnte ich es auch machen, ABER da ich ja Log-Shipping nutzen möchte UND weiterhin lesenden und schreibenden Zugriff haben möchte, weiß ich ehrlich gesagt nicht welchen Modus ich da für das Restore nutzen soll.

    (5) Detach und attach ist nicht möglich, da sich es auf dem ServerA um produktive 24/7/365 laufende Datenbanken handelt.

    (6) Was gibt es für Möglichkeiten die Datenbanken samt Logins, Stored Procedures etc, zu kopieren und auch fürs Log-Shipping und lesend/schreibend Modus benutzbar zu machen?

    Wir haben extra einen Service-User in unserer Domäne eingerichtet, der solche Jobs erledigen soll. Dieser User hat sysadmin-Rechte auf beiden Systemen.

    ...

     

    Ich versuche auf die einzelnen Punkte mal kurz einzugehen

    1. Log-Shipping kann niemals „Echtzeit“ sein. Die einzige Möglichkeit „Echtzeit“ synchron zu sein, ist Datenbankspiegelung/eine AlwaysOn Availability Group im synchronen Modus. Jede andere Technik hat vom Ansatz her schon Versatz, egal wie niedrig.
    2. SQL Server stürzt nicht aufgrund eines vollen Logs ab. Das kann maximal eine darauf zugreifende Applikation tun, die mit den dabei auftretenden Fehlern nicht umgehen kann. Ansonsten gehört es zu den absoluten Basics, wenn man schon über HA nachdenkt, einen solchen Umstand schon im Entstehen abzufangen.
    3. + 6 Logins gehören nicht zu Datenbank. Die liegen auf Server-Ebene. Datenbanken mit dem Wizard zu „kopieren“ ist nur für wirklich kleine Systeme brauchbar. Ansonsten haben wir dafür ja extra backup & restore ;-) Für die Logins und andere Server-Objekte brauchst Du einen Script. (sp_revlogins gibt’s als download von MS: http://support.microsoft.com/kb/918992)
    4. Der Zusammenhang ist mir nicht klar hier. Ich glaube da herrscht noch einige Unsicherheit bezüglich der Natur von Logshipping und der benötigten HA-Architektur.
    5. Richtig, und das wäre auch nicht wirklich sinnvoll, insofern da nichts weiter probieren :-)
    6. Hier darf gern noch jemand anderes ausführlich drauf eingehen, sofern es sich noch nicht aus dem genannten erschließt. Log-Shipping und Schreibbare Kopie geht natürlich nicht.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com



    Montag, 2. Dezember 2013 13:13
  • Danke für Erläuterung. :)

    Ja ich weiß das Logshipping nicht ganz Echtzeit ist. :) Aber ich habe halt etwas Angst wegen einer Spiegelung. Es kam halt schon mal zu einem Totalausfall. Zwar glaube ich immer noch nicht das es an der Spiegelung lag, aber laut Kollegen soll das so gewesen, da er den Datentransfer nicht "Commiten" konnte. Das transaction-log auf ServerA lief voll und somit natürlich auch die Spiegelung ServerB.

    Wenn ich nochmal eine Spiegelung einrichten soll, dann muss ich verhindern können das so etwas nochmal passiert. Kann mir jemand da sagen was ich da machen kann um solches zu vermeiden?

    Montag, 2. Dezember 2013 13:43
  • Okay. In einem Technik-Forum muss ich das halt schon genau nehmen ;)

    Ja, bei der Spiegelung kann das passieren, da sie eben "synchron" läuft.

    Ist aber kein problem der Spigelung, sondern ein prinzipielles:

    Man sollte einen Job haben, der sein log auf Füllstand überwacht (dafür gibt es PerfLog Counter) und dann entsprechend reagiert wenn es eng wird.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Montag, 2. Dezember 2013 13:49