Migration von SAP ERP 6.0 mit IBM Db2 zu IBM Power Virtual Server
Verwenden Sie die folgende Anleitung, um Ihr SAP Enterprise Resource Planning 6 (ERP)-System von einem IBM Db2 zu einem IBM Power Virtual Server zu migrieren. Sie haben verschiedene Möglichkeiten, IBM Db2-Datenbanken auf ein Zielsystem zu migrieren.
IBM Db2 SAP migrationsoptionen
Für SAP ERP mit IBM Db2 haben Sie zwei Migrationsmöglichkeiten:
-
Migrationsoption 1 – Sichern und Wiederherstellen basiert auf Standardverwaltungsaufgaben wie Starten, Stoppen, Sichern und Wiederherstellen. Es handelt sich um einen weniger komplizierten Ansatz, der jedoch während der Migration Ausfallzeiten erfordert.
-
Migrationsoption 2 – IBM Db2 Hochverfügbarkeit und Notfallwiederherstellung(HADR ) ist ein Ansatz zur Optimierung von Ausfallzeiten für SAP-Produktionssysteme. Es basiert auf IBM Db2 Hochverfügbarkeit und Notfallwiederherstellung ( IBM Db2 HADR) Datenbanksynchronisierung und einer Online-Sicherung. Die Ausfallzeit des Systems wird minimiert, aber die Methode erfordert einen höheren Konfigurationsaufwand im Vergleich zu Option 1.
Migrationsoption 1 – Sichern und Wiederherstellen
Das Sichern und Wiederherstellen ist eine typische Option für die Migration von Entwicklungs- oder Test- SAP-Systemen. Diese Migrationsoption basiert auf einer Sicherung der Datenbank aus dem Quellsystem und einer Datenbankwiederherstellung, um die Datenbank auf einem vorinstallierten Zielsystem zu füllen.
Die folgenden Schritte sind erforderlich, um die Migration abzuschließen:
- Vorbereitungen für die Migration
- Beenden der Anwendung SAP und Deaktivieren der Datenbank auf dem Quellserver
- Verwendung der Offline-Sicherung von IBM Db2 auf dem Quellsystem
- Übertragung der Sicherungsdateien
- Wiederherstellung der Datenbank auf dem Zielsystem
- Starten des Zielsystems SAP
Merkmale der Migrationsoption 1 – Sicherungs- und Wiederher stellungsansatz:
- Ausfallzeit: Eine geplante Ausfallzeit des SAP-Systems ist erforderlich, da das SAP-System während des Migrationsprozesses nicht verfügbar ist.
- Fallback: Es wurden keine Änderungen am Quellensystem SAP vorgenommen. Die Notfallmaßnahme stoppt bei Bedarf die Migration und startet das Quell SAP-System neu.
- Komplexität: basiert auf Standard-Verwaltungsaufgaben. Diese Migrationsoption ist die unkomplizierteste.
Vorbereitungen für die Migration
Führen Sie die folgenden Schritte zur Vorbereitung der Migration durch.
Sie benötigen alle definierten Umgebungsvariablen auf dem Quell- und Zielserver. Speichern Sie die Befehle in einer temporären Textdatei, während Sie sie auf dem Quellserver SAP ausführen. Auf dem Zielserver sind genau dieselben Befehle erforderlich, wie in Kapitel "Wiederherstellen der Datenbank auf dem Zielsystem " beschrieben.
Legen Sie die folgenden Umgebungsvariablen entsprechend Ihren Anforderungen fest.
-
Starten Sie eine C-Shell-Sitzung als
root
-Benutzer auf dem Quellsystem:csh
Die Befehlssyntax zur Definition von Umgebungsvariablen hängt vom Shell-Typ ab. Standard-Shell-Typ für Db2- und SAP-Administratorbenutzer
db2<sid>
und<sid>adm
ist die C-Shell. Wenn Sie dieselbe Shell verwenden, können Sie die Befehlsbeispiele kopieren und in Ihre Sitzungsumgebung einfügen. -
Definieren Sie den Hostnamen des Ziel-Migrationssystems (Beispiel:
cdb6ecc1
) und ersetzen Sie ihn durch Ihren Ziel-Hostnamen:set TARGETSERVER=cdb6ecc1
SAP Stellen Sie sicher, dass auf den Quell- und Zielsystemen von SAP die gleichen Versionen der ERP-Software und der IBM Db2-Datenbank ausgeführt werden.
-
Definieren Sie den SAP-Instanzadministrator (dieses Beispiel gilt für die SAP-Instanz
th1
) und ändern Sie ihn entsprechend Ihrem System.set SIDADM=th1adm
-
Definieren Sie den Datenbanknamen IBM Db2 – auch hier ist
th1
das Beispiel – und ändern Sie ihn entsprechend Ihrem System:set DBNAME=th1
-
Definieren Sie den Datenbankadministrator für IBM Db2:
set DB2ADM=db2th1
-
Legen Sie ein Verzeichnis zum Speichern der Sicherungsdateien fest:
set BACKUPDIR=/db2/backup
-
Erstellen Sie das folgende Verzeichnis, falls es nicht existiert:
mkdir -p $BACKUPDIR
und das Backup-Verzeichnis an den Administrator von Db2 übertragen:
chown $DB2ADM $BACKUPDIR
Dieses Sicherungsverzeichnis muss über ausreichend Speicherplatz verfügen, um die komprimierten Sicherungsdateien zu speichern. Ermitteln Sie die aktuelle IBM Db2-Datenbankgröße, indem Sie das
GET_DBSIZE_INFO
-Verfahren aufrufen. Weitere Informationen finden Sie in der GET_DBSIZE_INFO-Prozedur.
Beenden der Anwendung SAP und Deaktivieren der Datenbank auf dem Quellserver
Führen Sie die folgenden Schritte aus, um die Anwendung SAP zu beenden und die Datenbank auf dem Quellserver zu deaktivieren.
-
Um das SAP-System zu starten oder zu stoppen, verwenden Sie das SAP-Instanz-Administratorkonto
$SIDADM
:su - $SIDADM
-
Um das System SAP zu stoppen und die Datenbank am Laufen zu halten, verwenden Sie den folgenden Befehl:
stopsap r3
Optional können Sie überprüfen, ob sich SAP im erforderlichen Zustand befindet, indem Sie den folgenden Befehl ausführen:
stopsap check
Die erwartete Ausgabe sieht wie das folgende Beispiel aus:
Checking db6 Database Database is running ------------------------------------------- Checking SAP TH1 Instance ASCS01 ------------------------------------------- Instance ASCS01 is not running Checking SAP TH1 Instance D00 ------------------------------------------- Instance D00 is not running
-
Für die Db2-Befehle beenden Sie die
$SIDADM
-Benutzersitzung:exit
-
Wechseln Sie zum Benutzer
$DB2ADM
:su - $DB2ADM
Optional können Sie überprüfen, ob noch Anwendungen mit der Datenbank verbunden sind, bevor Sie die Datenbank deaktivieren, indem Sie den folgenden Befehl ausführen:
db2 list applications
Das folgende Beispiel zeigt die erwartete Ausgabe.
SQL1611W No data was returned by Database System Monitor.
Wenn die Anwendungen immer noch aufgeführt sind, beenden Sie die Anwendungen und überprüfen Sie sie erneut. Nur wenn die externen Anwendungen immer noch nicht aufhören, versuchen Sie, die Anwendungen vom Datenbankserver mit
db2 force applications all
zu trennen. -
Definieren Sie die Umgebungsvariablen für den Benutzer DB2ADM erneut:
set DBNAME=th1
set BACKUPDIR=/db2/backup
-
Für die Offline-Sicherung von IBM Db2 muss die Datenbank deaktiviert werden. Verwenden Sie den folgenden Befehl, um die Datenbank zu deaktivieren:
db2 deactivate database $DBNAME
Die folgende Ausgabe wird erwartet.
DB20000I The DEACTIVATE DATABASE command completed successfully.
Verwendung der Offline-Sicherung von IBM Db2 auf dem Quellsystem
Führen Sie die folgenden Schritte aus, um die Offline-Sicherung von Db2 auf dem Quellsystem zu verwenden.
Im Vorbereitungsschritt "Vorbereitung der Migration" wurde ein Sicherungsverzeichnis erstellt, in dem die komprimierte Offline-Sicherung gespeichert wurde.
-
Vergewissern Sie sich, dass das Sicherungsverzeichnis über ausreichend Speicherplatz zum Speichern von Sicherungsdateien verfügt:
df -m $BACKUPDIR
-
Starten Sie die IBM Db2 Offline-Sicherung:
db2 backup database $DBNAME to $BACKUPDIR compress
Dieser Befehl dauert je nach Größe der Datenbank sehr lange.
Der Fortschritt der Sicherung kann mit dem Befehl
db2 list utilities show detail
Am Ende der Ausgabe des Sicherungsbefehls finden Sie einen Zeitstempel. Dieser Zeitstempel ist erforderlich, um die Datenbank auf dem Zielsystem wiederherzustellen.
Beispielausgabe:
Backup successful. The timestamp for this backup image is : 20240730170709
Merken Sie sich diesen Zeitstempel, Sie müssen ihn in den nächsten beiden Schritten angeben.
-
Verwenden Sie eine Umgebungsvariable, um den Zeitstempel zu speichern:
set TIMESTAMP=<your timestamp>
Der Sicherungs-Zeitstempel von IBM Db2 hat das Format JJJJMMTTHHMMSS (Jahr-Monat-Tag-Stunde-Minute-Sekunde) und sieht wie folgt aus:
20240730170709
. Dieser Zeitstempel wird erneut auf dem Zielserver SAP benötigt. Fügen Sie diesenTIMESTAMP
-Definitionsbefehl der Liste der gespeicherten Befehle aus "Vorbereitung auf die Migration" hinzu. -
Wechseln Sie mit dem folgenden Befehl in den Sicherungsordner:
cd $BACKUPDIR
-
Suchen Sie nach Dateien, die Ihren Zeitstempel im Namen enthalten:
ls -l *$TIMESTAMP*
Beispielausgabe:
TH1.0.db2th1.DBPART000.20240730170709.001
Die in der Ausgabe aufgeführten Dateien sind die Sicherungsdateien, die im nächsten Schritt auf das Zielsystem übertragen werden.
Übertragung der Sicherungsdateien
Verwenden Sie den folgenden Schritt, um die Sicherungsdateien zu übertragen.
-
Kopieren Sie die Sicherungsdateien vom Quell-System SAP auf das Zielsystem:
scp ${BACKUPDIR}/*${TIMESTAMP}* \ ${TARGETSERVER}:${BACKUPDIR}
In diesem Beispiel wird Secure Copy (SCP) verwendet, eine langsamere Version der Datenübertragung. Sie können Sicherungsdateien entweder direkt an eine IBM AIX LPAR in Power Virtual Server oder an IBM Cloud Object Storage übertragen. Wenn Sie SCP oder SFTP mit IBM Cloud Object Storage verwenden, wird davon ausgegangen, dass Sie einen IBM FileManage Gateway-Dienst verwenden oder einen SFTP-Server innerhalb oder neben der Zielumgebung IBM Power Virtual Server installiert und konfiguriert haben, um die Übertragung zu empfangen.
Die schnellere Option ist IBM, das leistungsstarke Aspera-Produkt für die Datenübertragung. In vielen Situationen kann IBM Aspera Daten um ein Vielfaches schneller übertragen als herkömmliche TCP-basierte Protokolle. Weitere Informationen erhalten Sie unter IBM Aspera Technologies.
Diese Referenz enthält auch den Leitfaden für die beschleunigte Netzwerkübertragung.
Wiederherstellung der Datenbank auf dem Zielsystem
Führen Sie die folgenden Schritte aus, um eine Datenbank auf dem Zielsystem wiederherzustellen.
-
Melden Sie sich beim Zielserver an, um den Wiederherstellungsvorgang zu starten:
ssh $DB2ADM@$TARGETSERVER
Der Zielserver kann die Umgebungsvariablen, die auf dem Quellsystem definiert sind, nicht kennen. Aber die Variablen
$DBNAME
,$TIMESTAMP
und$SIDADM
werden auf dem Zielsystem benötigt. Um diese Variablen zu definieren, führen Sie die Liste der Befehle aus, die Sie in Schritt "Vorbereitung der Migration" und "Verwendung der IBM Db2-Offline-Sicherung" auf dem Quellsystem gespeichert haben, oder definieren Sie die Umgebungsvariablen erneut. -
Für die vollständige Wiederherstellung ist eine deaktivierte IBM Db2-Datenbank erforderlich. Führen Sie dieselben Schritte wie zuvor auf dem vorinstallierten Zielsystem SAP aus:
db2 list applications
Die folgende Ausgabe wird erwartet:
SQL1611W No data was returned by Database System Monitor.
-
Deaktivieren Sie die IBM Db2-Datenbank:
db2 deactivate database $DBNAME
-
Führen Sie eine vollständige Datenbankwiederherstellung durch:
db2 restore database $DBNAME \ from $BACKUPDIR \ taken at $TIMESTAMP
Durch Anhängen von
replace existing
an den Wiederherstellungsbefehl wird die Aufforderung zum Überschreiben vermieden. -
Db2 die Abfrage fragt, ob Sie die vorhandene Datenbank durch Wiederherstellen der Sicherung überschreiben möchten:
SQL2523W Warning! Restoring to an existing database that is different from the database on the backup image, but have matching names. The target database is overwritten by the backup version. The Roll-forward recovery logs associated with the target database is deleted. Do you want to continue ? (y/n)
Geben Sie
y
ein und drücken Sie die Eingabetaste.Die folgende Ausgabe wird erwartet:
DB20000I The RESTORE DATABASE command completed successfully.
Wenn die Wiederherstellung nicht erfolgreich war, löschen Sie die Datenbank auf dem Zielsystem im Voraus mit
db2 drop database $DBNAME
und wiederholen Sie den Wiederherstellungsbefehl. -
Verwenden Sie den folgenden Befehl, um die Wiederherstellung abzuschließen:
db2 rollforward db $DBNAME to end of backup and stop
Die Zieldatenbank enthält nun die Daten des Quellsystems.
Starten von SAP Zielsystem
Führen Sie die folgenden Schritte aus, um das Zielsystem zu starten
-
Wechseln Sie zum SAP-Instanzadministrator:
login $SIDADM
-
Starten Sie die Anwendung SAP:
startsap
Das folgende Beispiel zeigt die erwartete Ausgabe:
Checking db6 Database Database is running ------------------------------------------- Starting Startup Agent sapstartsrv OK Instance Service on host <TARGET> started ------------------------------------------- starting SAP Instance ASCS01 Startup-Log is written to /home/th1adm/startsap_ASCS01.log ------------------------------------------- /usr/sap/TH1/ASCS01/exe/sapcontrol -prot NI_HTTP -nr 01 -function Start Instance on host <TARGET> started Starting Startup Agent sapstartsrv OK Instance Service on host <TARGET> started ------------------------------------------- starting SAP Instance D00 Startup-Log is written to /home/th1adm/startsap_D00.log ------------------------------------------- /usr/sap/TH1/D00/exe/sapcontrol -prot NI_HTTP -nr 00 -function Start Instance on host <TARGET> started
Passen Sie den DNS-Eintrag des Systems SAP so an, dass er auf den Zielserver SAP verweist, um sicherzustellen, dass die Clientsysteme (die ausgeführte SAP-Anmeldungs-GUI) mit dem Zielserver verbunden sind.
Die Migration ist abgeschlossen.
- SAP das System auf dem Quellserver ist ausgefallen
- SAP das System auf dem Zielserver ist betriebsbereit
Migrationsoption 2 – IBM Db2 Hochverfügbarkeit und Notfallwiederherstellung (HADR)
Migrationsoption 2 ist ein für Ausfallzeiten optimiertes Verfahren. Es handelt sich um eine Kombination aus Sicherung, Wiederherstellung und Synchronisierung der Datenbanken auf beiden Seiten unter Verwendung von IBM Db2 HADR. Wenn die Datenbanken synchronisiert sind und die Umgebung für die Migration vorbereitet ist, wechselt die Kernmigration zum vorinstallierten Zielserver SAP.
Wenn das Quellsystem einen IBM Db2-Cluster verwendet oder IBM Db2 HADR aktiviert hat, wird die vorhandene HADR-Konfiguration durch die Migration erweitert. Sonderfall – Migration einer Quelle IBM Db2-Cluster beschreibt und verlinkt zu den erforderlichen Schritten.
Wenn IBM Db2 HADR auf der Quellseite nicht aktiviert ist, sind die folgenden Schritte erforderlich:
- Vorbereitungen für die Migration
- Sicherstellen, dass die Protokollierung des Archivs von IBM Db2 aktiviert ist
- Erstellen eines Online-Backups aus der Datenbank des Quellsystems
- Übertragung von Sicherungsdateien auf das Zielsystem
- Wiederherstellung des Zielsystems
- Definition von HADR-Ports für lokale und Remote-Dienste auf dem Ziel- und Quellsystem
- Konfigurieren von HADR auf den Ziel- und Quellsystemen
- HADR starten und synchronisierte Daten überprüfen
- Durchführung des Kernmigrationsschritts
Merkmale der Migrationsoption 2 – IBM Db2 HADR:
- Allgemeine Ausfallzeit: Es kommt zu einer kurzen Ausfallzeit, wenn der Server von der Quelle zum Ziel wechselt. Vor dem Wechsel läuft das Quellsystem SAP. Nach dem Wechsel übernimmt das Zielsystem SAP.
- Ausfallzeiten, zirkuläre Protokollierung: HADR erfordert, dass sich die Datenbank IBM Db2 im
archive logging
-Modus befindet. Wenn sich Ihre IBM Db2-Datenbank imcircular logging
-Modus befindet, müssen Sie die IBM Db2-Datenbank in denarchive logging
-Modus migrieren, bevor Sie HADR verwenden können. Dieser Schritt erzwingt eine einmalige Ausfallzeit der Datenbank. - Fallback: bedeutet, dass das Quellsystem SAP während der gesamten Migration bis zum Wechsel ausgeführt wird. Bevor Sie den Wechsel vornehmen, ist keine spezielle Ausweichoption erforderlich. Wenn Schritte vor oder nach dem Wechsel nicht erfolgreich sind, können Sie die Schritte rückgängig machen, um das SAP-Quellsystem wieder zum Laufen zu bringen.
Sonderfall – Migration eines Quell- IBM- Db2-Clusters
Wenn das Quellsystem SAP ein IBM Db2 HADR-Cluster ist, muss die HADR-Konfiguration erweitert werden, um den Zielserver einzuschließen. Die Schritte sind in diesem Fall einfacher.
Die meisten der beschriebenen Konfigurationsschritte sind bereits eingerichtet. Das Zielsystem muss als Hilfsknoten zur bestehenden HADR-Konfiguration IBM Db2 hinzugefügt werden. Weitere Informationen finden Sie im IBM Db2 Supportartikel „Schritte zum Hinzufügen eines neuen Hilfs-Standbys zu einem vorhandenen Db2 HADR-Paar“.
Vorbereitungen für die Migration
Führen Sie die folgenden Schritte aus, um das SAP-System auf die Migration vorzubereiten.
Beachten Sie bei der Vorbereitung auf die Migration die folgenden Informationen.
-
Sie müssen zwei TCP-Portnummern definieren, die Sie in Ihrem Setup verwenden können.
-
Für die Synchronisierung mit HADR sind zwei offene Netzwerkports erforderlich:
- Ein lokaler Hafen für ausgehenden Verkehr
- Ein entfernter Port für eingehenden Datenverkehr
-
Beide Ports sind auf jedem der beiden IBM Db2-Systeme konfiguriert, jedoch in vertauschter Reihenfolge. In diesem Beispiel werden die Portnummern
5920/tcp
und5921/tcp
verwendet, aber Sie können diese Ports an Ihre Bedürfnisse anpassen. -
Firewalls müssen TCP-Datenverkehr zwischen dem Quell- und Zielsystem zulassen. Stellen Sie sicher, dass die erforderlichen Firewall-Regeln auf allen beteiligten Firewalls sowie auf dem Quell- und Zielsystem konfiguriert sind.
Legen Sie die folgenden Umgebungsvariablen entsprechend Ihrer Konfiguration fest.
Alle definierten Umgebungsvariablen werden sowohl auf dem Quell- als auch auf dem Zielserver benötigt. Speichern Sie die Befehle, während Sie sie auf dem Quellserver SAP in einer temporären Textdatei ausführen. Auf dem Zielserver sind dieselben Befehle erforderlich wie unter "Wiederherstellen der Datenbank auf dem Zielsystem " angegeben.
-
Definieren Sie den Hostnamen für das Ziel-Migrationssystem.
cdb6ecc1
ist ein Beispiel und muss durch den Hostnamen Ihres Zielsystems ersetzt werden. Verwenden Sie dazu den folgenden Befehl:set TARGETSERVER=cdb6ecc1
Stellen Sie sicher, dass auf Ihrem Zielserver die ERP-Software SAP und die Datenbank IBM Db2 mit derselben Version wie das Quellsystem SAP ausgeführt werden.
-
Definieren Sie den SAP-Instanzadministrator und ändern Sie ihn mit dem folgenden Befehl so, dass er Ihrem System entspricht (dieses Beispiel gilt für die SAP-Instanz
th1
):set SIDADM=th1adm
-
Definieren Sie den Datenbanknamen IBM Db2 – auch hier ist
th1
ein Beispiel. Ändern Sie es so, dass es zu Ihrem System passt:set DBNAME=th1
-
Definieren Sie den Datenbankadministrator für IBM Db2:
set DB2ADM=db2th1
-
Legen Sie ein Verzeichnis zum Speichern von Sicherungsdateien fest:
set BACKUPDIR=/db2/backup
-
Erstellen Sie das folgende Verzeichnis, falls es nicht existiert:
mkdir -p $BACKUPDIR
und das Backup-Verzeichnis an den Administrator von Db2 übertragen:
chown $DB2ADM $BACKUPDIR
Dieses Sicherungsverzeichnis muss über ausreichend Speicherplatz verfügen, um die komprimierten Sicherungsdateien zu speichern. Ermitteln Sie die aktuelle IBM Db2-Datenbankgröße, indem Sie das
GET_DBSIZE_INFO
-Verfahren aufrufen. Weitere Informationen finden Sie in der GET_DBSIZE_INFO-Prozedur.
Sicherstellen, dass die Protokollierung des Archivs von IBM Db2 aktiviert ist
IBM Db2 Für Hochverfügbarkeit und Notfallwiederherstellung (HADR) muss archive logging
aktiviert sein.
circular logging
ist standardmäßig aktiviert, nachdem Sie IBM Db2 HADR installiert haben. Die meisten SAP Systeme mit IBM Db2 haben archive logging
aktiviert.
Überprüfung der Archivprotokollierungsmethoden
Führen Sie die folgenden Schritte aus, um zu überprüfen, welche Protokollierungsmethode konfiguriert ist.
-
Wechseln Sie zur IBM Db2 Datenbank admin:
su - $DB2ADM
-
Rufen Sie beide Konfigurationsoptionen für die Protokollarchivierungsmethode ab:
db2 get db cfg for th2 | grep LOGARCHMET
-
Fahren Sie mit dem nächsten Abschnitt fort, wenn mindestens eine der Protokollarchivierungsmethoden auf
ON
eingestellt ist. Stellen Sie sicher, dass beide nicht aufOFF
eingestellt sind. Dieses Beispiel zeigt, wie die Ausgabe für die aktivierte Archivprotokollierung aussieht:First log archive method (LOGARCHMETH1) = DISK:/db2/logarch/ Second log archive method (LOGARCHMETH2) = OFF
-
Wenn beide Methoden für die Protokollarchivierung
OFF
sind, müssen Sie zuerst die Archivprotokollierung konfigurieren. Das folgende Beispiel zeigt die Ausgabe:First log archive method (LOGARCHMETH1) = OFF Second log archive method (LOGARCHMETH2) = OFF
Konfigurieren der Archivprotokollierung
Für IBM Db2 HADR ist eine Archivprotokollierung erforderlich. Wenn LOGARCHMETH1 und LOGARCHMETH2 auf OFF
eingestellt sind, führen Sie die folgenden Schritte aus, um die Archivprotokollierung zu aktivieren.
Für die Archivprotokollierung ist eine Ausfallzeit erforderlich.
-
Starten Sie als SAP-Administrator, um das SAP-System zu stoppen:
su - $SIDADM
-
Stoppen Sie das SAP-System, aber lassen Sie die Datenbank laufen:
stopsap r3
-
Beenden Sie den administrativen Benutzer SAP:
exit
-
Wechseln Sie zum Administratorkonto IBM Db2:
su - $DB2ADM
-
Verwenden Sie die gespeicherten Befehle, um sicherzustellen, dass Umgebungsvariablen wie
DBNAME
undBACKUPDIR
festgelegt sind. -
Legen Sie ein Verzeichnis für die Log-Archivdateien fest:
set LOGARCHDIR=/db2/log_archive
Erstellen Sie das Protokollarchivverzeichnis nach Möglichkeit auf einer separaten Partition. Die Partition des Archivprotokolls hängt von der LPAR-Festplattenkonfiguration ab, die nicht in den Rahmen dieses Dokuments fällt. Beachten Sie, dass das Protokollarchiv ein gemeinsam genutztes Verzeichnis zwischen den Knoten ist, wenn das Quellsystem ein IBM Db2-Cluster ist.
-
Erstellen Sie das Protokollarchivverzeichnis mindestens mit diesem Befehl:
mkdir $LOGARCHDIR
-
Überprüfen Sie das erstellte Verzeichnis:
ls -ld $LOGARCHDIR
Beispielausgabe:
drwxr-xr-x 7 db2th1 dbth1adm 256 Aug 30 11:24 /db2/log_archive
-
Überprüfen Sie, ob der Verzeichnisbesitzer der Db2-Administrator ist, der in der Beispielausgabe
db2th1
ist. Überprüfen Sie dann, ob der Eigentümer über die vollständigen Berechtigungen verfügtrwx
. -
Konfigurieren Sie Db2 so, dass ein Festplattenlaufwerk mit diesem Verzeichnis für die Archivprotokollierungsmethode 1 verwendet wird:
db2 "update db cfg for $DBNAME using LOGARCHMETH1 DISK:$LOGARCHDIR"
Erwartete Ausgabe:
DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.
IBM Db2 die Datenbank erzwingt nach dieser Änderung eine Sicherung:
db2 backup database $DBNAME to $BACKUPDIR compress
Die Sicherung dauert je nach Größe der Datenbank eine Weile.
-
Verwenden Sie das SAP-Administratorkonto $SIDADM, um die Datenbank und das SAP-System neu zu starten:
su - $SIDADM
startsap
Erstellen eines Online-Backups aus der Datenbank des Quellsystems
Um die Ausfallzeit des SAP-Systems zu minimieren, erstellen Sie eine Online-Datenbank-Sicherung von Db2.
-
Wechseln Sie zum Db2-Admin-Benutzer:
su - $DB2ADM
-
Starten Sie die Online-Sicherung, einschließlich der Protokolldateien:
db2 backup db $DBNAME online to $BACKUPDIR compress include logs
Beachten Sie, dass die Sicherung einige Zeit in Anspruch nimmt.
Wenn die Sicherung abgeschlossen ist, wird ein Zeitstempel gedruckt:
Backup successful. The time stamp for this backup image is : 20240913091058
Merken Sie sich diesen Zeitstempel. Sie benötigen es in den nächsten beiden Schritten.
-
Verwenden Sie eine Umgebungsvariable, um den Zeitstempel zu speichern:
set TIMESTAMP=<your timestamp>
Der Sicherungs-Zeitstempel von IBM Db2 verwendet das Format JJJJMMTTHHMMSS (Jahr-Monat-Tag-Stunde-Minute-Sekunde) und sieht wie folgt aus:
20240913091058
. Dieser Zeitstempel wird erneut auf dem Zielserver SAP benötigt. Fügen Sie diesenTIMESTAMP
-Definitionsbefehl der Liste der gespeicherten Befehle aus Schritt "Vorbereitung der Migration" hinzu.
Übertragung von Sicherungsdateien auf das Zielsystem
Verwenden Sie den folgenden Schritt, um die Sicherungsdateien auf das Zielsystem zu übertragen.
-
Kopieren Sie die Sicherungsdateien vom Quell-System SAP auf das Zielsystem:
scp ${BACKUPDIR}/*${TIMESTAMP}* \ ${TARGETSERVER}:${BACKUPDIR}
Wiederherstellung des Zielsystems
Führen Sie die folgenden Schritte aus, um das Zielsystem wiederherzustellen.
-
Die Datenbankwiederherstellung erfolgt auf dem Zielserver:
ssh $DB2ADM@$TARGETSERVER
Der Zielserver kann die Umgebungsvariablen, die auf dem Quellsystem definiert sind, nicht kennen. Aber die Variablen
$DBNAME
,$TIMESTAMP
und$SIDADM
werden auf dem Zielsystem benötigt. Um diese Variablen zu definieren, führen Sie die Liste der Befehle aus, die Sie in den Schritten "Vorbereitung der Migration" und "Erstellen einer Online-Sicherung aus der Quelldatenbank " gespeichert haben, oder definieren Sie die Umgebungsvariablen erneut. -
Verwenden Sie die Online-Sicherung, um die Datenbank wiederherzustellen.
db2 restore database $DBNAME \ from $BACKUPDIR \ taken at $TIMESTAMP
Db2 die Abfrage fragt, ob Sie die vorhandene Datenbank durch Wiederherstellen der Sicherung überschreiben möchten:
SQL2523W Warning! Restoring to an existing database that is different from the database on the backup image, but have matching names. The target database will be overwritten by the backup version. The Roll-forward recovery logs associated with the target database will be deleted. Do you want to continue? (y/n)
-
Geben Sie
y
ein und drücken Sie die Eingabetaste.Das folgende Beispiel zeigt die erwartete Ausgabe:
DB20000I The RESTORE DATABASE command completed successfully.
Wenn die Wiederherstellung nicht erfolgreich war, löschen Sie die Datenbank auf dem Zielsystem im Voraus mit
db2 drop database $DBNAME
und wiederholen Sie den Wiederherstellungsbefehl.Im Gegensatz zu Option 1 werden Archivprotokolle nicht vorgerollt. HADR verwendet diesen Status, um geänderte Daten zu synchronisieren, die im nächsten Schritt bearbeitet werden. Wenn das Quellsystem SAP betriebsbereit ist, ändern sich die Quelldaten.
Um die neuesten Änderungen zu übertragen, konfigurieren Sie die IBM Db2 HADR-Datenbanksynchronisierung.
Definition von HADR-Ports für lokale und Remote-Dienste auf dem Ziel- und Quellsystem
Verwenden Sie die folgenden Schritte, um lokale und Remote-HADR-Service-Ports auf dem Ziel- und Quellsystem zu definieren.
HADR verwendet zwei TCP-Ports, um Daten zu synchronisieren.
-
Überprüfen Sie, ob
/etc/services
auf beiden Systemen diese TCP-Portnummern enthält. Konfigurieren Sie die Portnummern in dieser Datei auf beiden Servern.Wenn lokale und Remote-HADR-Ports in
/etc/services
, IBM, Db2 konfiguriert sind, ist die Konfiguration besser lesbar, wenn Dienstnamen anstelle von Nummern verwendet werden.Im Beispiel werden die Ports
5920/tcp
und5921/tcp
verwendet, aber Sie können auch andere Ports definieren.Übersichtstabelle der zu konfigurierenden Portnummern:
TCP-Portzuweisung in /etc/services auf beiden Servern Servicename Wert auf dem Quellserver Wert auf Zielserver Kommentar db2th1ha_l 5921/tcp
5920/tcp
Lokaler Port db2th1ha_r 5920/tcp
5921/tcp
Ferner Port -
Verwenden Sie Ihren bevorzugten Editor, um
/etc/services
auf beiden Servern zu ändern. -
Überprüfen Sie, ob die Konfigurationsdateien korrekt sind, indem Sie den folgenden Befehl verwenden:
grep -e '592[01]/' /etc/services
Die folgenden Zeilen sind die erwartete Ausgabe auf dem Quellserver:
db2th1ha_l 5921/tcp # Db2 HADR local port db2th1ha_r 5920/tcp # Db2 HADR remote port
Portnummern müssen auf dem Zielserver aktiviert sein. Das folgende Beispiel ist die erwartete Ausgabe auf dem Zielknoten:
db2th1ha_l 5920/tcp # Db2 HADR local port db2th1ha_r 5921/tcp # Db2 HADR remote port
Konfigurieren von HADR auf dem Ziel- und Quellsystem
HADR benötigt die folgenden Konfigurationen.
Db2 HADR-Parameter | Wert auf dem Quellserver | Wert auf Zielserver | Kommentar |
---|---|---|---|
HADR_LOKAL_HOST |
|
|
Hostname des Systems, auf dem Sie sich befinden |
HADR_LOCAL_SVC | db2th1ha_l | db2th1ha_l | Lokaler Hafen gemäß Definition in /etc/services |
HADR_REMOTE_HOST |
|
|
Der Hostname des anderen Hosts |
HADR_REMOTE_SVC | db2th1ha_r | db2th1ha_r | Remote-Port, wie in /etc/services |
HADR_REMOTE_INST | <db2 instanzname> | <db2 instanzname> | Der Instanzname des anderen Knotens IBM Db2 (nicht der Datenbankname) |
LOGINDEXBUILD | ON |
ON |
Für beide Hosts auf ON einstellen |
HADR_SYNCMODE | <ein gültiger Synchronisierungsmodus> | <ein gültiger Synchronisierungsmodus> | Siehe HADR-Synchronisationsmodus |
Lokale und Remote-Hostnamen (HADR_LOCAL_HOST
und HADR_REMOTE_HOST
) müssen für beide Systeme aktiviert werden. HADR_LOCAL_HOST
ist immer der Hostname des Knotens. Der Konfigurationsbefehl wird auf dem
Remote-Host ausgeführt, der der Hostname des jeweils anderen Systems ist.
Die lokalen und Remote-Service-Einträge (HADR_LOCAL_SVC
und HADR_REMOTE_SVC
) sind identisch, da der Switch bereits in /etc/services
konfiguriert ist.
Der HADR-Synchronisationsmodus(High Availability Disaster Recovery) erläutert verschiedene IBM Db2 HADR-Synchronisationsoptionen und ihre Vorteile.
Verwenden Sie die folgenden Befehle, um beide Systeme zu konfigurieren:
-
Der lokale Host ist das System, an das der Befehl
hostname
berichtet:db2 "update db cfg for $DBNAME using HADR_LOCAL_HOST `hostname`"
-
Der lokale Port ist die lokale Port-Definition von
/etc/services
:db2 "update db cfg for $DBNAME using HADR_LOCAL_SVC db2th1ha_l"
-
Überprüfen Sie für den Remote-Host, ob
$TARGETSERVER
auf den anderen Server verweist:db2 "update db cfg for $DBNAME using HADR_REMOTE_HOST $TARGETSERVER"
-
Der Remote-Port ist die Remote-Port-Definition von
/etc/services
:db2 "update db cfg for $DBNAME using HADR_REMOTE_SVC db2th1ha_r"
-
Konfigurieren Sie die Remote-Instanz IBM Db2.
Zur Orientierung: Wenn der Datenbankname
th1
lautet, dann sieht der Instanzname wie folgt aus:db2th1
:db2 "update db cfg for $DBNAME using HADR_REMOTE_INST $DBINST"
-
Stellen Sie sicher, dass die Protokollindexerstellung auf beiden Systemen auf EIN gesetzt ist:
db2 "update db cfg for $DBNAME using LOGINDEXBUILD ON"
-
Definieren Sie den HADR-Synchronisationsmodus. Der Wert
async
ist ein Beispiel. Ändern Sie ihn entsprechend dem HADR-Synchronisierungsmodus, der für Ihre Umgebung geeignet ist:db2 "update db cfg for $DBNAME using HADR_SYNCMODE async"
HADR starten und synchronisierte Daten überprüfen
Führen Sie die folgenden Schritte aus, um HADR zu starten und zu überprüfen, ob die Daten synchronisiert werden.
-
Starten Sie HADR auf dem Zielserver im Standby-Modus. Wechseln Sie zum Zielserver als
$DB2ADM
und führen Sie den folgenden Befehl aus:db2 start hadr on db $DBNAME as standby
Die erwartete Ausgabe sieht wie das folgende Beispiel aus:
DB20000I The START HADR ON DATABASE command completed successfully.
-
Starten Sie HADR auf dem Quellserver als primären Server. Wechseln Sie zum Quellserver als
$DB2ADM
und führen Sie den folgenden Befehl aus:db2 start hadr on db $DBNAME as primary
Die erwartete Ausgabe sieht wie das folgende Beispiel aus:
DB20000I The START HADR ON DATABASE command completed successfully.
-
Überprüfen Sie den HADR-Status mit:
db2pd -d $DBNAME -hadr
Und achten Sie auf diese Felder:
HADR-Statuswerte, beide Server Feld Quellenserver Zielserver HADR_ROLE PRIMARY
STANDBY
HADR_STATE PEER
PEER
HADR_CONNECT_STATUS CONNECTED
CONNECTED
Durchführung der Kernmigration
Führen Sie die folgenden Schritte aus, um mit der Migration des SAP-Systems vom Quellserver auf den Zielserver zu beginnen.
Passen Sie den DNS-Eintrag des SAP-Systems so an, dass er auf den Zielserver SAP verweist. Diese Anpassung stellt sicher, dass Client-Systeme (wie das System, das die Anmelde-GUI von SAP ausführt) eine Verbindung zum Zielserver herstellen.
-
Stoppen Sie das Quellserver-System SAP, das die Datenbank Db2 enthält.
Melden Sie sich auf dem Quellsystem als
$SIDADM
an und führen Sie den folgenden Befehl aus:stopsap
Warten Sie, bis der Befehl abgeschlossen ist.
-
Wechseln Sie zum Zielserver als
$DB2ADM
und starten Sie eine Übernahme mit dem folgenden Befehl:db2 takeover hadr on database $DBNAME
Der Übernahmebefehl verfügt über eine Option
by force
, die helfen kann, wenn das Quellsystem nicht sauber heruntergefahren wurde. Weitere Informationen finden Sie unter "TAKEOVER HADR-Befehl ". -
Als
$DB2ADM
auf dem Zielserver. Überprüfen Sie, ob die HADR-Rolle von IBM Db2 vonstandby
zuprimary
geändert wurde, indem Sie den folgenden Befehl verwenden:db2pd -d th2 -hadr | grep ROLE
-
Wenn die HADR-Rolle IBM Db2 auf dem Zielserver
primary
lautet, können Sie das SAP-System auf dem Zielserver starten. Wechseln Sie zum Benutzer$SIDADM
und führen Sie den folgenden Befehl aus:startsap
Die Datenbanksynchronisierung von IBM und Db2 ist noch konfiguriert, aber derzeit nicht aktiv.
Lassen Sie die HADR-Konfiguration unverändert, wenn das Zielsystem für eine Rückmigration vorgesehen ist (wie bei einem Katastrophenszenario). Wenn das Quellsystem nach der Migration entfernt wird, entfernen Sie die HADR-Konfiguration wie unter "So entfernen Sie eine vorhandene HADR-Konfiguration " beschrieben.
Die Migration ist abgeschlossen.
- SAP das System auf dem Quellserver ist ausgefallen
- SAP das System auf dem Zielserver ist betriebsbereit