none
Datenmigration von SQL 2005 Cluster (Itanium) nach SQL 2012 HA - 2.5TB RRS feed

  • Frage

  • Guten Abend,

    ich habe hier einen alten SQL 2005 Cluster auf Itanium Basis mit 3 Knoten, diese halten etwa 1.3TB an Daten.
    2 Weiter Cluster Knoten halten noch etwa 1.2TB an Daten.

    Diese Datenbanken sollen alle auf den SQL2012 HA überführt werden.

    SQL 2012 HA besteht auf einem Cluster mit 6 Maschinen, 2 paare bilden je eine HA Gruppe.

    Welcher Weg wäre hier denn am besten zu beschreiten, die Migration soll reibungslos, zügig und offline erfolgen.
    Bisher habe ich folgende Wege durchdacht.

    A: Sichern aller Datenbanken auf das Zielstorage, Rücksicherung, Wizard für HA verwenden (30 Stunden Zeit).
    B: Trennen der Datenbanken, kopieren auf Zielstorage Knoten 1 und Attach der Datenbanken.
    C: Migration mit dem SQL Mgmt Studio und Kopieren von Quelle/Ziel.

    Danach die HA Gruppen mit dem Wizard einrichten (7 Stunden).

    Die Verbindung zwischen den Systemen ist eine 1GB Strecke (Hausnetzt).
    Die neuen Server sind mit 1GBit ans Haus und mit 8GB FC ans Storage gebunden.

    Welche Lösung wäre denn hier am besten zu wählen.

    Wäre eine Spiegelung zwischen SQL 2005 und SQL 2012 möglich?

    Backup/Restore ist nicht möglich, die neue Software bietet keinen Agent mehr für Itanium, die alte Software keinen mehr für SQL 2012...


    Montag, 24. September 2012 15:15

Antworten

  • Hallo Jürgen,

    wir machen das in der Bank so, daß wir über einen Spiegel zunächst die neue PROD einrichten. Anschließend dann einen Failover und den Spiegel wieder brechen.

    Grundsätzlich gibt es aber bei der Menge an Daten, die Du nennst, ein paar Besonderheiten zu beachten:

    1. Fullbackup / Differential backup während des Backup- und Restoreprozesses anhalten
    2. Logsicherungen während des Backup- und Restoreprozesses anhalten

    Während der Einrichtung des Spiegels wird - je nach Anzahl der Transaktionen - das Log entsprechend wachsen, da ja keine Logsicherung gemacht werden kann.

    Da ich nicht weiß, wie die 1,3 TB aufgeteilt sind (eine DB oder mehrere) kann man  hier nicht detailliert vorgehen.

    Ich habe mir ein SQLCMD-Script dafür geschrieben, um den Backup- und den Restorevorgang zu automatisieren.
    Anschließend geht das Script her und richtet den Spiegel ein.

    :SETVAR Principal Server1.mycompany.local
    :SETVAR Mirror Server2.mycompany.local
    :SETVAR Share '\\myserver\backupshare'
    :SETVAR MirrorPort 5022
    -- Verbinden auf Principal und Backup durchführen
    :CONNECT $(Principal)
    BACKUP DATABASE MyDB TO DISK = '$(Share)\Mydb_full.bak' WITH STATS, COMPRESSION, INIT, FORMAT
    BACKUP LOG MyDB TO DISK = '$(Share)\MyDdb_log.trn' WITH STATS, COMPRESSION, INIT, FORMAT
    GO
    -- Verbinden auf Mirror und Restore der Datenbank
    :CONNECT $(Mirror)
    RESTORE DATABASE MyDB FROM DISK = '$(Share)\mydb_full.bak' WITH REPLACE, NORECOVERY, STATS
    RESTORE LOG MyDB FROM DISK = '$(Share)\mydb_log.trn' WITH NORECOVERY, STATS
    GO
    -- Einrichten des Spiegel
    ALTER DATABASE MyDB SET PARTNER = 'TCP://$(Principal):$(MirrorPort)'
    GO
    :CONNECT $(Principal)
    ALTER DATABASE MyDB SET PARTNER = 'TCP://($Mirror):$(MirrorPort)'
    GO

    Bitte folgendes dabei beachten:

    - ich habe das "aus dem Bauch" programmiert, da ich das Script selbst momentan nicht vor mir habe
    - Principal und Mirror haben identische Verzeichnisstrukturen (Ev. mußt Du den Restore mit WITH MOVE durchführen!)

    DU MUSST DAS SCRIPT in SQLCMD-Modus laufen lassen!


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de



    Mittwoch, 26. September 2012 15:25

Alle Antworten

  • Hallo Jürgen,

    wir machen das in der Bank so, daß wir über einen Spiegel zunächst die neue PROD einrichten. Anschließend dann einen Failover und den Spiegel wieder brechen.

    Grundsätzlich gibt es aber bei der Menge an Daten, die Du nennst, ein paar Besonderheiten zu beachten:

    1. Fullbackup / Differential backup während des Backup- und Restoreprozesses anhalten
    2. Logsicherungen während des Backup- und Restoreprozesses anhalten

    Während der Einrichtung des Spiegels wird - je nach Anzahl der Transaktionen - das Log entsprechend wachsen, da ja keine Logsicherung gemacht werden kann.

    Da ich nicht weiß, wie die 1,3 TB aufgeteilt sind (eine DB oder mehrere) kann man  hier nicht detailliert vorgehen.

    Ich habe mir ein SQLCMD-Script dafür geschrieben, um den Backup- und den Restorevorgang zu automatisieren.
    Anschließend geht das Script her und richtet den Spiegel ein.

    :SETVAR Principal Server1.mycompany.local
    :SETVAR Mirror Server2.mycompany.local
    :SETVAR Share '\\myserver\backupshare'
    :SETVAR MirrorPort 5022
    -- Verbinden auf Principal und Backup durchführen
    :CONNECT $(Principal)
    BACKUP DATABASE MyDB TO DISK = '$(Share)\Mydb_full.bak' WITH STATS, COMPRESSION, INIT, FORMAT
    BACKUP LOG MyDB TO DISK = '$(Share)\MyDdb_log.trn' WITH STATS, COMPRESSION, INIT, FORMAT
    GO
    -- Verbinden auf Mirror und Restore der Datenbank
    :CONNECT $(Mirror)
    RESTORE DATABASE MyDB FROM DISK = '$(Share)\mydb_full.bak' WITH REPLACE, NORECOVERY, STATS
    RESTORE LOG MyDB FROM DISK = '$(Share)\mydb_log.trn' WITH NORECOVERY, STATS
    GO
    -- Einrichten des Spiegel
    ALTER DATABASE MyDB SET PARTNER = 'TCP://$(Principal):$(MirrorPort)'
    GO
    :CONNECT $(Principal)
    ALTER DATABASE MyDB SET PARTNER = 'TCP://($Mirror):$(MirrorPort)'
    GO

    Bitte folgendes dabei beachten:

    - ich habe das "aus dem Bauch" programmiert, da ich das Script selbst momentan nicht vor mir habe
    - Principal und Mirror haben identische Verzeichnisstrukturen (Ev. mußt Du den Restore mit WITH MOVE durchführen!)

    DU MUSST DAS SCRIPT in SQLCMD-Modus laufen lassen!


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de



    Mittwoch, 26. September 2012 15:25
  • Hallo Uwe,
    Hallo Raul,

    Danke für der Beitrag, der ist schon sehr gut für eine Migration.

    Leider erlaubt eine Firewall der Netzwerke keinen SQL Traffic zwischen den Systemen.
    Auch ein Spiegel zwischen SQL 2005 (Itanium) und SQL 2012 HA (Intel) wird nicht realisierbar sein.

    Ein Technical Advisory mit MS hat auch ergeben, das der einzige sinnvolle Weg aus Backup/Restore besteht.

    Am Samstag (Testmigration) liefen dann auch alle Backups auf das Zielsystem, Datenmenge war etwa 2.9TB.
    Der Durchsatz war unterirdisch, meist bei 30MB/sec. (Lag aber nicht am Netz, sondern an der alten HW).

    Bei dem größten System (1TB) sogar nur 16MB/sec (huhu..)

    Ein Restore Test läuft grade...

    Danke aber an alle für die Info.

    Gruß

    Jürgen

    Montag, 1. Oktober 2012 10:30