none
Datenbank kopieren SQL Server 2005 auf 2008 R2 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo NG,

    wir würden gerne von SQL Server 2005 auf SQL Server 2008 R2 migrieren (auch neue Hardware).

    Nun versuche ich unsere Produktionsdatenbank mittels des Database Copy Wizard (SMO Methode) vom 2005 Server auf den 2008 zu kopieren. Im Internet findet man ja einige Anleitungen dazu. Leider wehrt sich dies sehr.
    Am Anfang erhielten wir immer folgenden Fehler:

     

    FEHLER : errorCode=-1073548784 description=Fehler beim Ausführen der Abfrage 'CREATE VIEW [dbo].[viewFPDPI3_n]
AS SELECT     d...': 'Ungültiger Objektname 'dbo.tblFPDPI'.'.

    Wie es aussieht hat er zuerst versucht die Views zu generieren anstelle der Tabellen.
    Durch diesen Link konnte ich diesen Fehler lösen (sp_refreshview).

    Nun erhalte ich leider aber folgenden Fehler.

    FEHLER : errorCode=-1073548784 description=Fehler beim Ausführen der Abfrage 'ALTER TABLE [dbo].[tblFPDMH]  WITH CHECK ADD  CONS...': 'Die ALTER TABLE-Anweisung steht in Konflikt mit der FOREIGN KEY-Einschränkung 'FK_tblFPDMH_tblFPBZPPM'. Der Konflikt trat in der Hostlst-Datenbank, Tabelle 'dbo.tblFPBZPPM', column 'NrMA' auf.'. Mögliche Ursachen sind folgende: Probleme bei der Abfrage, nicht richtig festgelegte ResultSet-Eigenschaft, nicht richtig festgelegte Parameter oder nicht richtig hergestellte Verbindung

    Diese angegebenen Tabellen stehen in einer 1:n Beziehung und wie ich das herauslese wird hier wiederum versucht zuerst die falsche Tabelle zu erzeugen (in diesem Fall tblFPDMH). Bevor es aber nicht die Tabelle tblFPBZPPM' gibt kann man keine Beziehung einrichten.  Diese zwei Tabellen sind jetzt nur ein Beispiel. Das tritt bei den anderen 1:n Beziehungen auch auf.

    Wie kann ich das lösen? Gibt es eine analoge Funktion zu sp_refreshview für Tabellen?
    Vielen Dank im Voraus für eure Hilfe. Schön langsam nervt mich das Ganze. MS macht es einem gar nicht leicht mit der Migration ;).

    LG
    Bernhard

    Dienstag, 25. Oktober 2011 08:18
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Bernhard,

    eine Sicherung funktioniert auch während des laufenden Betriebs,
    nur bei einer Wiederherstellung darf niemand mit der Datenbank arbeiten
    (die es hier noch gar nicht geben sollte).

    Wenn später auf dem neuen Server weitergearbeitet werden soll,
    sollte man den Zugriff vorher beenden, da ansonsten das Abgleichen kompliziert wird.

    Du kannst die Datenbank dazu in den Einzelbenutzermodus setzen:
    Vorgehensweise: Festlegen des Einzelbenutzermodus für eine Datenbank (SQL Server Management Studio)

    und ggf. auch die Anwender "rauswerfen".

    Allerdings würde ich den Termin vorher absprechen, damit keine "wichtigen" Dinge mehr offen sind.

    Auch empfiehlt sich, eine Migration zunächst einmal testhalber zu machen
    und zu schauen ob alles wie gewünscht funktioniert, wie z. B. das Ändern der Verbindung usw.

    Das Sichern und Wiederherstellen kann man mehrmalig durchführen, bis alles rundläuft

    Gruß Elmar

    • Als Antwort markiert BernhardW Dienstag, 25. Oktober 2011 12:14
    Dienstag, 25. Oktober 2011 12:06
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Bernhard,

    wenn die Datenbank komplett umziehen soll, ist es einfacher eine Sicherung zu machen
    und sie auf dem neuen Rechner wiederherzustellen.
    Beim Wiederherstellen kannst Du auch den Speicherort anpassen, siehe dazu:
    Kopieren von Datenbanken durch Sichern und Wiederherstellen

    Empfehlenswert ist bei einer Migration vorher den Updateratgeber die Datenbanken prüfen zu lassen.

    Das Problem, dass Du beim Kopieren via SMO hast, passiert dabei nicht.
    Häufig ist dort die Ursache, dass die Liste der abhängigen Objekte nicht mehr stimmt,
    wodurch solche Fehler auftreten können, was bei älteren Versionen von SQL Server häufiger auftrat.

    Nach der Übertragung solltest Du die Statistiken via sp_updatestats aktualisieren,
    siehe dazu auch Überlegungen zum Aktualisieren des Datenbankmoduls

    Gruß Elmar

    Dienstag, 25. Oktober 2011 09:23
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Elmar,

     

    vielen Dank für die schnelle Antwort. 

    Aha, dann werde ich das mittels Sichern und Wiederherstellen machen. Vielen Dank für den Tipp.

     

    LG Bernhard

    Dienstag, 25. Oktober 2011 09:41
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Bernhard,
    ich würde einfach ein Backup/Restore machen. Dann hast Du keine Probleme mit den Abhängigkeiten.

    Danach den Kompatibilitätslevel hochsetzen und die Statistiken aktualisieren:

    exec sp_dbcmptlevel meineDatenbank, 100;
ALTER DATABASE meineDatenbank SET PAGE_VERIFY CHECKSUM WITH NO_WAIT;

exec sp_updatestats;
dbcc updateusage ('meineDatenbank');

     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu

    • Als Antwort markiert BernhardW Dienstag, 25. Oktober 2011 09:57
    • Tag als Antwort aufgehoben BernhardW Dienstag, 25. Oktober 2011 11:56
    Dienstag, 25. Oktober 2011 09:49
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    eine schnelle Frage noch.

    Während des Backup/Restore Prozesses darf ja kein Benutzer mehr auf die alte Datenbank zugreifen (vor allem schreibend).

    Mit welchem Befehl kann ich das machen? Wenn ich die Datenbank offline schalte funktioniert die Sicherung ja auch nicht mehr.

    Vielen Dank.

    MfG

    Dienstag, 25. Oktober 2011 11:56
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Bernhard,

    eine Sicherung funktioniert auch während des laufenden Betriebs,
    nur bei einer Wiederherstellung darf niemand mit der Datenbank arbeiten
    (die es hier noch gar nicht geben sollte).

    Wenn später auf dem neuen Server weitergearbeitet werden soll,
    sollte man den Zugriff vorher beenden, da ansonsten das Abgleichen kompliziert wird.

    Du kannst die Datenbank dazu in den Einzelbenutzermodus setzen:
    Vorgehensweise: Festlegen des Einzelbenutzermodus für eine Datenbank (SQL Server Management Studio)

    und ggf. auch die Anwender "rauswerfen".

    Allerdings würde ich den Termin vorher absprechen, damit keine "wichtigen" Dinge mehr offen sind.

    Auch empfiehlt sich, eine Migration zunächst einmal testhalber zu machen
    und zu schauen ob alles wie gewünscht funktioniert, wie z. B. das Ändern der Verbindung usw.

    Das Sichern und Wiederherstellen kann man mehrmalig durchführen, bis alles rundläuft

    Gruß Elmar

    • Als Antwort markiert BernhardW Dienstag, 25. Oktober 2011 12:14
    Dienstag, 25. Oktober 2011 12:06
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Elmar,

    danke, genau das habe ich gesucht.

    Ist klar dass der Termin vorher abgesprochen wird. Ich teste das Ganze jetzt auch ausgiebig. Die Umstellung selbst muss dann eh in einer Nachtschicht erledigt werden :). Nur da sollte dann alles so schnell und reibungslos wie möglich ablaufen.

    LG

    Bernhard

    Dienstag, 25. Oktober 2011 12:14
    |
  • Question
    Anmelden
    1
    Anmelden

    Wenn Du die Sache beschleunigen willst und die Datenbank sehr groß ist, kannst Du auch tagsüber eine vollständige Sicherung ziehen und die Datenbank mit NORECOVERY restoren.

    Abends ziehst Du dann noch eine differentielle Sicherung und machst den letzten Restore mit RECOVERY. Das kann schon einiges an Zeit sparen.
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu

    Dienstag, 25. Oktober 2011 12:29
    |
    Beantworter