Migrieren von Datenbanken mit den Befehlen exportConcurrent und importConcurrent

Sie können die Datenbank von „ Engineering Lifecycle Management “-Anwendungen mithilfe der Befehle exportConcurrentimportConcurrent und von einem Anbieter zu einem anderen migrieren.

Vorbereitende Schritte

  • Für die Durchführung einer Testmigration ist eine nicht produktive Testumgebung mit einer Kopie der Daten aus der Produktion erforderlich.
    • Die Kopie der Produktionsdaten muss aktuell genug sein, damit Sie sicher sein können, dass sie alle Daten im Produkt-Repository enthält – beispielsweise innerhalb der letzten Monate für Teams, die etablierte Entwicklungsprozesse befolgen.
    • Sie benötigen Testdaten für jede Anwendung und jede Anwendungsinstanz, die Sie migrieren. Wenn Sie beispielsweise über zwei RM-Server verfügen, müssen Sie für jeden Server eine Testmigration durchführen. Diese Aussage gilt nicht für Cluster-CCM- oder QM-Server, da Cluster-Server eine Datenbankinstanz gemeinsam nutzen.
    • Eine Staging-Umgebung mit Hardware, die der Produktionsumgebung entspricht, ist der zuverlässigste Indikator für die zu erwartende Migrationszeit.
  • Die Migration muss von einem Benutzer mit Administratorrechten durchgeführt werden.
  • Die Server von „ ELM “ müssen offline sein, daher ist ein Ausfallfenster erforderlich.
  • Die Migration erfordert den Export und Import aller Repository-Daten zusammen. Eine teilweise Migration wird nicht unterstützt, ebenso wenig wie das Online-Schalten der Server zwischen Export und Import.
  • Die Server von „ ELM “ müssen über ausreichend Speicherplatz für die Exportdateien verfügen. Die Datenbankdaten werden beim Export komprimiert, jedoch nicht bei allen Datenbanken mit derselben Komprimierungsrate. Eine gute Richtlinie ist es, bei der Berechnung des für Exportdateien erforderlichen Speicherplatzes die Größe der Datenbank zugrunde zu legen.
  • Für eine schnelle Migration ist leistungsfähige Hardware erforderlich.
Server vorbereiten
Während der optimierte Repotools-Migrationscode überarbeitet wurde, um die Ausfallzeit für eine Migration zu reduzieren, spielt auch die Betriebsumgebung eine entscheidende Rolle dabei, wie schnell eine Migration abgeschlossen werden kann. Die neuen Befehle repotools -exportConcurrent-importConcurrent und repotools nutzen mehrere CPU-Kerne sowie schnelle Festplatten- und Netzwerk-E/A.
Plattenspeicher
  • Verwenden Sie nach Möglichkeit eine lokale Festplatte zum Schreiben und Lesen von Exportdateien. Das Exportieren in oder Importieren aus einem Netzwerkfreigabe- oder Netzwerkspeichergerät kann die Verarbeitungsgeschwindigkeit der Migration einschränken.
  • Für die Migrationsspeicherung werden Solid-State-Disks (SSD) empfohlen. Die Festplattengeschwindigkeit ist ein wichtiger Faktor bei der Migration, sowohl auf dem ELM -Server, auf dem die repotools-Befehle ausgeführt werden, als auch auf dem Datenbankserver. Verweisen Sie Ihren „ ELM “-Serveradministrator und Ihren Datenbankadministrator auf unseren Artikel zum Thema Festplatten-Benchmarking.
CPU-Kerne
Die optimierte Migration stützt sich stark auf Parallelität, um die Laufzeit zu verkürzen. Es wird empfohlen, den Server „ ELM “ und die Datenbankserver mit mindestens 8 bis 16 Kernen zu betreiben.
Systemspeicher

Die gleichzeitige Ausführung der Befehle zur Datenbankmigration (-exportConcurrent, und -compare) kann einen Großteil -importConcurrentdes Systemspeichers beanspruchen. Es ist wichtig, andere Prozesse, die um Systemressourcen konkurrieren, während der Ausführung dieser Befehle auf ein Minimum zu reduzieren. Unter Linux kann der Out Of Memory Killer die gleichzeitigen Migrationsprozesse vorzeitig beenden. Administratoren sind dann gezwungen, das Problem zu beheben, indem sie den Speicherverbrauch reduzieren und den beendeten Befehl erneut ausführen.

Um die Ausführungspläne auf Db2 zu löschen, lassen Sie entweder den Job „ DB2 AUTO_MAINT” aktiviert oder führen Sie die folgenden Schritte aus, um runstats in einem Skript auszuführen:

  1. Stellen Sie eine Verbindung zur Datenbank her, indem Sie den Befehl „ db2 connect“ verwenden.
  2. Erstellen Sie ein Skript (wie in diesem Beispiel):
    db2 -x "SELECT 'RUNSTATS ON TABLE ' || TRIM(TABSCHEMA) || '.' || TRIM(TABNAME) || ' AND INDEXES ALL;' FROM SYSCAT.TABLES WHERE TYPE = 'T' AND TABSCHEMA NOT LIKE 'SYS%' ORDER BY TABSCHEMA, TABNAME" > db2_runstats.sql.out
  3. Überprüfen Sie, ob die Datei „ db2_runstats.sql.out “ alle Tabellennamen enthält, für die Runstats ausgeführt werden soll.
  4. Führen Sie das Skript mit „ db2 -tvf“ aus:
    db2 -tvf db2_runstats.sql.out > outcomestats.txt

Prozedur

  1. Beenden Sie alle „ Engineering Lifecycle Management “-Server.
  2. Mit dem Befehl exportConcurrent repotools können Sie die Daten exportieren.
    /server/repotools_[app] -exportConcurrent -clean multipleZips toFile=../export/[app].zip.

    Statistische Informationen zur Migration werden erfasst und im repotools-Protokoll gespeichert. Diese Informationen können vom IBM Support zur Fehlerbehebung verwendet werden.

    Hinweis: Der Parameter „ statsLogFrequency “ wird verwendet, um die Standardprotokollierungsdauer auf einmal alle 60 Minuten zu ändern./server/repotools_[app] -exportConcurrent -clean multipleZips toFile=../export/[app].zip statsLogFrequency=60

    Um die statistischen Daten beim Exportieren der Daten zu ignorieren, verwenden Sie die folgenden Befehle:

    /server/repotools_[app] -exportConcurrent multipleZips statsEnabled=false -clean toFile=../export/[app].zip

    /server/repotools_[app] -exportConcurrent multipleZips statsEnabled=no -clean toFile=../export/[app].zip

  3. Überprüfen Sie die Protokolle auf Fehler und Laufzeitstatistiken.
    /server/repotools_[app]_exportConcurrent.log
  4. Aktualisieren Sie den Server „ Engineering Lifecycle Management “ mit den neuen Datenbankeinstellungen.
    Sie können einen neuen „ Engineering Lifecycle Management “-Server einrichten, der dieselbe Version wie die exportierten „ Engineering Lifecycle Management “-Daten hat, oder den bestehenden „ Engineering Lifecycle Management “-Server verwenden, von dem Sie die Daten exportiert haben. Wenn Sie den vorhandenen „ Engineering Lifecycle Management “-Server verwenden, müssen Sie die teamserver.properties Dateien sichern. Diese Dateien werden im Befehl comparerepotools verwendet.

    Wenn Sie einen neuen „ Engineering Lifecycle Management “-Server einrichten, stellen Sie sicher, dass Sie dieselbe URI verwenden, indem Sie die Konfiguration von „ IBM HTTP Server “ (IHS) entsprechend anpassen. Aktualisieren Sie die folgenden Eigenschaften in der server/conf/[app]/teamserver.properties Datei, damit sie auf den neuen Speicherort verweisen:

    com.ibm.team.repository.db.vendor com.ibm.team.repository.db.jdbc.location

    com.ibm.team.repository.db.jdbc.password

  5. Importieren Sie die Daten mit dem Befehl importConcurrent repotools .
    /server/repotools_[app] -importConcurrent -clean fromFile=../export/[app].zip
    Statistische Informationen zur Migration werden erfasst und im repotools-Protokoll gespeichert. Diese Informationen können vom IBM Support zur Fehlerbehebung verwendet werden.
    Hinweis: Mit der Option statsLogFrequency kann der Standardzeitraum für die Protokollierung auf einmal in 60 Minuten geändert werden.

    /server/repotools_[app] -importConcurrent -clean fromFile=../export/[app].zip statsLogFrequency=60

    Um die statistischen Daten beim Exportieren der Daten zu ignorieren, verwenden Sie die folgenden Befehle:

    /server/repotools_[app] -importConcurrent statsEnabled=false -clean fromFile=../export/[app].zip

    /server/repotools_[app] -importConcurrent statsEnabled=no -clean fromFile=../export/[app].zip

  6. Überprüfen Sie die Protokolle auf Fehler und Laufzeitstatistiken.
    /server/repotools_[app]_importConcurrent.log
  7. Erstellen Sie die Datenbankindizes erneut.
    Die Datenbankindizes werden nicht automatisch erneut erstellt, wenn das Argument [skipRebuildIndices] im Befehl concurrentImport vorhanden ist. Wenn die Datenbankindizes nicht erneut erstellt werden, führen Sie den Befehl -rebuildIndices in der importierten Umgebung aus.

    /server/repotools-[app] -rebuildIndices

  8. Löschen Sie die Ausführungspläne für die importierte Datenbank.
    Datenbank Schritte
    Oracle Führen Sie den folgenden Befehl aus:

    alter system flush shared_pool;
    Db2
    1. Stellen Sie eine Datenbankverbindung her.
    2. Erstellen Sie ein Script, um den Ausführungsplan zu löschen. Beispiel:

      db2 -x "SELECT 'RUNSTATS ON TABLE ' || TRIM(TABSCHEMA) || '.' || TRIM(TABNAME) || ' AND INDEXES ALL;' FROM SYSCAT.TABLES WHERE TYPE = 'T' AND TABSCHEMA NOT LIKE 'SYS%' ORDER BY TABSCHEMA, TABNAME"> db2_runstats.sql.out

    3. Stellen Sie sicher, dass die Tabelle db2_runstats.sql.out die Namen aller Tabellen enthält, für die Sie Ihr Script ausführen möchten.
    4. Führen Sie das Script mit dem Befehl db2 -tvf aus, z. B.:

      C:\IBM\SQLLIB\BIN>db2 -tvf db2_runstats.sql.out> outcomestats.txt
  9. Verwenden Sie den Befehl -compare repotools , um sicherzustellen, dass es keine Abweichungen zwischen der Quellen-und der Zieldatenbank gibt.
    ExportJazzServerInstall/server/repotools_[app] -compare target.teamserver.properties=/opt/IBM/ImportJazzServerInstall/server/conf/jts/teamserver.properties
    Sie müssen den Befehl -compare in der Testumgebung ausführen, bevor Sie die Daten in der Produktionsumgebung migrieren. Führen Sie den -compare -Befehl in der Produktionsumgebung nicht aus, da die erforderliche Ausfallzeit möglicherweise zu lang ist. Der Befehl -compare führt einen umfassenden zellenweisen Vergleich der Quellen-und Zieldatenbanken durch. Es sind zwei teamserver.properties -Dateien erforderlich, eine mit den Verbindungsinformationen der Quellendatenbank und eine mit den Verbindungsinformationen der Zieldatenbank. Stellen Sie sicher, dass beide Datenbanken vom Server „ Engineering Lifecycle Management “ aus zugänglich sind.
    Wichtig: Starten Sie Ihre „ Engineering Lifecycle Management “-Anwendungen, die Quell- oder Zieldatenbanken verwenden, erst, wenn der -compare Befehl vollständig ausgeführt wurde. Wenn Sie eine der Anwendungen von Engineering Lifecycle Management verwenden, kann es vorkommen, dass diese die Daten in den Datenbanken aktualisieren und dadurch einen Fehlalarm im Vergleichsprotokoll verursachen.

    Um die Leistung zu verbessern, geben Sie die MS SQL Server-Datenbank im Argument source.teamserver.properties und die Oracle -oder Db2 -Datenbank im Argument target.teamserver.properties an.

  10. Führen Sie den Befehl -verify aus, um die Integrität der Datenbanken zu überprüfen.
    /server/repotools_[app] -verify level=5
Informationen zur Fehlerbehebung finden Sie unter „Fehlerbehebung bei der Datenbankmigration “.