Notfallwiederherstellung für SAP auf IBM Db2 einrichten auf AWS

Erstellt von Ambarish Satarkar () und Debasis Sahoo () AWS AWS

Umwelt: Produktion	Technologien: Datenbanken; Betrieb	Arbeitslast: SAP
AWSDienstleistungen: AmazonEC2; AWS Elastic Disaster Recovery

Übersicht

Dieses Muster beschreibt die Schritte zur Einrichtung eines Disaster Recovery-Systems (DR) für SAP Workloads mit IBM Db2 als Datenbankplattform, die in der Amazon Web Services (AWS) Cloud ausgeführt werden. Ziel ist die Bereitstellung einer kostengünstigen Lösung zur Gewährleistung der Geschäftskontinuität im Falle eines Ausfalls.

Das Muster verwendet den Pilotlampenansatz. Durch die Aktivierung von Pilot Light DR können Sie Ausfallzeiten reduzieren und die Geschäftskontinuität aufrechterhalten. AWS Der Pilot-Light-Ansatz konzentriert sich auf die Einrichtung einer minimalen DR-UmgebungAWS, einschließlich eines SAP Systems und einer Standby-Db2-Datenbank, die mit der Produktionsumgebung synchronisiert wird.

Diese Lösung ist skalierbar. Sie können sie nach Bedarf auf eine umfassende Notfallwiederherstellungsumgebung erweitern.

Voraussetzungen und Einschränkungen

Voraussetzungen

• Eine SAP Instance, die auf einer Amazon Elastic Compute Cloud (AmazonEC2) -Instance läuft

• Eine IBM Db2-Datenbank

• Ein Betriebssystem, das von der SAP Produktverfügbarkeitsmatrix () PAM unterstützt wird

• Verschiedene physische Datenbank-Hostnamen für Produktions- und Standby-Datenbank-Hosts

• Ein Amazon Simple Storage Service (Amazon S3) -Bucket in jeder AWS Region mit aktivierter regionsübergreifender Replikation (CRR)

Produktversionen

• IBMDb2-Datenbankversion 11.5.7 oder höher

Architektur

Zieltechnologie-Stack

• Amazon EC2

• Amazon-Simple-Storage-Service (Amazon-S3)

• Amazon Virtual Private Cloud (VPCPeering)

• Amazon Route 53

• IBMDb2-Notfallwiederherstellung mit hoher Verfügbarkeit () HADR

Zielarchitektur

Diese Architektur implementiert eine DR-Lösung für SAP Workloads mit Db2 als Datenbankplattform. Die Produktionsdatenbank wird in AWS Region 1 bereitgestellt und eine Standby-Datenbank wird in einer zweiten Region bereitgestellt. Die Standby-Datenbank wird als DR-System bezeichnet. Db2-Datenbank unterstützt mehrere Standby-Datenbanken (bis zu drei). Es verwendet Db2 HADR für die Einrichtung der DR-Datenbank und die Automatisierung des Protokollversands zwischen der Produktions- und der Standby-Datenbank.

Im Notfall, bei dem Region 1 nicht verfügbar ist, übernimmt die Standby-Datenbank in der DR-Region die Rolle der Produktionsdatenbank. SAPAnwendungsserver können im Voraus oder mithilfe von AWSElastic Disaster Recovery oder einem Amazon Machine Image (AMI) erstellt werden, um die Anforderungen an die Recovery Time Objective (RTO) zu erfüllen. Dieses Muster verwendet einAMI.

Db2 HADR implementiert ein Produktions-Standby-Setup, bei dem die Produktion als primärer Server fungiert und alle Benutzer mit ihm verbunden sind. Alle Transaktionen werden in Protokolldateien geschrieben, die mithilfe von /IP auf den Standby-Server übertragen werden. TCP Der Standby-Server aktualisiert seine lokale Datenbank, indem er die übertragenen Protokolldatensätze weiterleitet, wodurch sichergestellt wird, dass die Datenbank mit dem Produktionsserver synchron bleibt.

VPCPeering wird verwendet, damit Instances in der Produktionsregion und der DR-Region miteinander kommunizieren können. Amazon Route 53 leitet Endbenutzer zu Internetanwendungen weiter.

1. Erstellen Sie einen AMI Anwendungsserver in Region 1 und kopieren Sie ihn in Region 2. AMI Verwenden Sie denAMI, um im Notfall Server in Region 2 zu starten.

2. Richten Sie die HADR Db2-Replikation zwischen der Produktionsdatenbank (in Region 1) und der Standby-Datenbank (in Region 2) ein.

3. Ändern Sie im Notfall den EC2 Instanztyp so, dass er der Produktionsinstanz entspricht.

4. In Region 1 LOGARCHMETH1 ist auf eingestelltdb2remote: S3 path.

5. In Region 2 LOGARCHMETH1 ist auf gesetztdb2remote: S3 path.

6. Die regionsübergreifende Replikation wird zwischen den S3-Buckets durchgeführt.

Tools

AWSDienste

• Amazon Elastic Compute Cloud (AmazonEC2) bietet skalierbare Rechenkapazität in der AWS Cloud. Sie können so viele virtuelle Server wie nötig nutzen und sie schnell nach oben oder unten skalieren.

• Amazon Route 53 ist ein hochverfügbarer und skalierbarer DNS Webservice.

• Amazon Simple Storage Service (Amazon S3) ist ein cloudbasierter Objektspeicherservice, der Sie beim Speichern, Schützen und Abrufen beliebiger Datenmengen unterstützt.

• Amazon Virtual Private Cloud (AmazonVPC) hilft Ihnen dabei, AWS Ressourcen in einem von Ihnen definierten virtuellen Netzwerk bereitzustellen. Dieses virtuelle Netzwerk ähnelt einem herkömmlichen Netzwerk, das Sie in Ihrem eigenen Rechenzentrum betreiben würden, und bietet die Vorteile der Nutzung der skalierbaren Infrastruktur vonAWS. Dieses Muster verwendet VPCPeering.

Bewährte Methoden

• Das Netzwerk spielt eine Schlüsselrolle bei der Entscheidung über den HADR Replikationsmodus. Für AWS regionsübergreifende DR empfehlen wir die Verwendung von Db2 HADR ASYNC oder SUPERASYNC Mode. 

• Weitere Informationen zu den Replikationsmodi für Db2 HADR finden Sie in der IBM Dokumentation.

• Sie können die AWS Managementkonsole oder die AWS Befehlszeilenschnittstelle (AWSCLI) verwenden, um ein neues System AMI Ihres vorhandenen SAP Systems zu erstellen. Anschließend können Sie das verwendenAMI, um Ihr vorhandenes SAP System wiederherzustellen oder einen Klon zu erstellen.

• AWSSystems Manager Automation kann Sie bei den allgemeinen Wartungs- und Bereitstellungsaufgaben von EC2 Instanzen und anderen AWS Ressourcen unterstützen.

• AWSbietet mehrere native Dienste zur Überwachung und Verwaltung Ihrer Infrastruktur und AnwendungenAWS. Dienste wie Amazon CloudWatch und AWS CloudTrail können zur Überwachung Ihrer zugrunde liegenden Infrastruktur bzw. Ihres API Betriebs verwendet werden. Weitere Informationen finden Sie SAPunter AWS — IBM Db2 HADR mit Pacemaker.

Epen

Bereite die Umgebung vor

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Überprüfen Sie das System und die Protokolle.	Vergewissern Sie sich, dass die Produktion SAP auf dem Db2-System eingerichtet ist. Vergewissern Sie sich, dass die Protokollsicherung aktiviert und so konfiguriert ist, dass die Protokolle im S3-Bucket gespeichert werden. Dies kann mit dem Db2-Parameter LOGARCHMETH1 überprüft werden. Erstellen Sie einen AMI der zusätzlichen Anwendungsserver.	AWSAdministrator, SAP Basisadministrator

Richten Sie die Server und die Replikation ein

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Erstellen Sie die SAP und Datenbankserver.	Um die Infrastruktur für die DR-Region bereitzustellen, verwenden Sie ein AWS CloudFormation Skript oder eine AMI der Produktionsinstanzen. Im Rahmen des Pilotprojekts können Sie eine kleinere EC2 Instanz derselben Familie wie die Produktionsinstanz verwenden. Wenn Ihr Produktions-Instance-Typ beispielsweise istr6i.12xlarge, können Sie den r6i.xlarge Instance-Typ für den DR-Build verwenden. Stellen Sie jedoch sicher, dass Sie der DR-Instance dieselbe Speicherkapazität zuweisen, um das Backup der Produktionsdatenbank wiederherzustellen. Erstellen Sie Bereitstellungspunkte für Amazon Elastic File System (AmazonEFS) und stellen Sie sicher/sapmnt/<SID>/, dass sie so eingestellt sind, dass sie vom Primärsystem aus repliziert werden. Erstellen Sie ein FULL Datenbank-Backup (online oder offline) vom Produktionssystem. Sie werden dieses Backup verwenden, um die DR-Datenbank zu erstellen. Verwenden Sie im DR-System die Systemkopiermethode SAP Software Provisioning Manager (SWPM) mit der Option Systemkopie mit Sicherung/Wiederherstellung für HA/DR-Zwecke verwenden, um das DR-System zu erstellen. SAP Wenn Sie von dazu aufgefordert werdenSWPM, stellen Sie die Datenbank in DR mit dem Backup wieder her, das Sie aus der Produktion erstellt haben. Die DR-Datenbank befindet sich im Status „Rollforward ausstehend“. Der Status „Rollforward ausstehend“ ist standardmäßig festgelegt, nachdem die vollständige Sicherung wiederhergestellt wurde. Der Status „Rollforward ausstehend“ gibt an, dass die Datenbank gerade wiederhergestellt wird und dass möglicherweise einige Änderungen übernommen werden müssen. Weitere Informationen finden Sie in der IBMDokumentation.	SAPBasisadministrator
Überprüfen Sie die Konfiguration.	Um die Protokollarchivierung für einzurichtenHADR, müssen sowohl die Produktions- als auch die DR-Datenbank in der Lage sein, Protokolle automatisch von allen Protokollarchivspeicherorten abzurufen. Stellen Sie sicher, dass der LOGARCHMETH1 Parameter in der DR-Datenbank auf denselben Speicherort wie in der Produktionsdatenbank gesetzt ist. Wenn auf denselben Standort aufgrund regionaler Beschränkungen nicht zugegriffen werden kann, stellen Sie sicher, dass das DR-System automatisch Protokolle vom Primärsystem abrufen kann. Um TCP /IP-Ports für die Aktivierung der Datenbankreplikation zu aktivieren, ändern Sie /etc/services die Produktions- und DR-Hosts, indem Sie die folgenden beiden Einträge hinzufügen. <SID>Bezieht sich im Code auf die System-ID (SID) der Db2-Datenbank (z. B.). PR1 <SID>_HADR_1 55001/tcp # DB2 HADR Port1 <SID>_HADR_2 55002/tcp # DB2 HADR Port2 Vergewissern Sie sich, dass beide Ports eingehenden und ausgehenden Verkehr zwischen dem Primär- und dem Standby-Port zulassen. Überprüfen Sie /etc/hosts die Produktions- und DR-Hosts, um sicherzustellen, dass die Hostnamen sowohl für die Produktions- als auch für die Standby-Hosts auf die richtigen IP-Adressen verweisen.	AWSAdministrator, SAP Basisadministrator
Richten Sie die Replikation von der Produktions-Datenbank zur DR-DB ein (ASYNCim Modus).	Führen Sie in der Produktionsdatenbank die folgenden Befehle aus, um die Parameter zu aktualisieren. db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST1 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid> db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120 db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000 db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240 db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON Führen Sie in der DR-Datenbank die folgenden Befehle aus, um die Parameter zu aktualisieren. db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST2 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid> db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120 db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000 db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240 db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON Diese Parameter sind erforderlich, um verwandte HADR Informationen für beide Datenbanken bereitzustellen. HADRWird in der Db2-Datenbank basierend auf den Werten für jeden der zuvor festgelegten Parameter aktiviert. Weitere Informationen zu diesen Parametern finden Sie in der IBMDokumentation. Starten Sie HADR zunächst in der neu erstellten Standby-Datenbank, indem Sie den folgenden Befehl verwenden. db2 deactivate db <SID> db2 start hadr on db <SID> as standby Starten Sie mit HADR dem folgenden Befehl in der Produktionsdatenbank. db2 deactivate db <SID> db2 start hadr on db <SID> as primary Überprüfen Sie, ob die Produktions- und Standby-Db2-Datenbanken synchron sind und ob der Protokollversand läuft. Verwenden Sie den folgenden db2pd Befehl, um den HADR Replikationsstatus zu überwachen. db2pd -d <SID> -hadr Weitere Informationen zur Überwachung HADR finden Sie in der IBMDokumentation.	SAPBasisadministrator

Testen Sie DR-Failover-Aufgaben

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Planen Sie die Ausfallzeiten des Produktionsbetriebs für den DR-Test ein.	Stellen Sie sicher, dass Sie die erforderlichen Betriebsausfälle in der Produktionsumgebung einplanen, um das DR-Failover-Szenario zu testen.	SAPBasisadministrator
Erstellen Sie einen Testbenutzer.	Erstellen Sie einen Testbenutzer (oder beliebige Teständerungen), der auf dem DR-Host validiert werden kann, um die Protokollreplikation nach einem DR-Failover zu bestätigen.	SAPBasisadministrator
Stoppen Sie auf der Konsole die EC2 Produktionsinstanzen.	In diesem Schritt wird ein unsachgemäßes Herunterfahren eingeleitet, um ein Katastrophenszenario nachzuahmen.	AWSSystemadministrator
Skalieren Sie die EC2 DR-Instanz entsprechend den Anforderungen.	Ändern Sie auf der EC2 Konsole den Instance-Typ in der DR-Region. Stoppen Sie die Instance: Wenn die Instance läuft, müssen Sie sie beenden, bevor Sie ihren Instance-Typ ändern können. Wählen Sie auf der EC2 Konsole die Instance aus und klicken Sie auf Stopp. Ändern Sie den Instanztyp: Wählen Sie auf der EC2 Konsole die Instance aus und klicken Sie dann auf Actions, Instance Settings, Change Instance Type. Wählen Sie den Instanztyp aus, der der primären Instance entspricht, und klicken Sie auf Anwenden. Starten Sie die Instance: Nachdem die Änderung des Instance-Typs abgeschlossen ist, starten Sie die Instance von der EC2 Konsole aus, indem Sie die Instanz auswählen und Start wählen. Verwenden Sie den folgenden Befehl, um die Db2-Datenbank zu starten. db2start db2 start HADR on db <SID> as standby	SAPBasis-Admin
Übernahme einleiten.	Initiieren Sie vom DR-System (host2) aus den Übernahmeprozess und rufen Sie die DR-Datenbank als primäre Datenbank auf. db2 takeover hadr on database <SID> by force Optional können Sie die folgenden Parameter festlegen, um die Speicherzuweisung der Datenbank automatisch auf der Grundlage des Instance-Typs anzupassen. Der INSTANCE_MEMORY Wert kann auf der Grundlage des dedizierten Speicherbereichs festgelegt werden, der der Db2-Datenbank zugewiesen werden soll. db2 update db cfg for <SID> using INSTANCE_MEMORY <FIXED VALUE> IMMEDIATE; db2 get db cfg for <SID> | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE; db2 update db cfg for <SID> using self_tuning_mem ON IMMEDIATE; Überprüfen Sie die Änderung mithilfe der folgenden Befehle. db2 get db cfg for <SID> | grep -i MEMORY db2 get db cfg for <SID> | grep -i self_tuning_mem	SAPBasisadministrator
Starten Sie den Anwendungsserver für SAP in der DR-Region.	Starten Sie mit demAMI, was Sie aus dem Produktionssystem erstellt haben, einen neuen zusätzlichen Anwendungsserver in der DR-Region.	SAPBasisadministrator
Führen Sie eine Validierung durch, bevor Sie die SAP Anwendung starten.	Überprüfen Sie die /etc/fstab Einträge /etc/hosts und. /sapmnt/<SID>/Auf dem DR-System montieren. Stellen Sie sicher, dass das DR-Dateisystem mit der Produktion /sapmnt/<SID>/ synchronisiert /sapmnt/<SID>/ ist. Melden Sie sich beim <sid>adm Benutzer anR3trans -d, führen Sie die Ausführung aus und überprüfen Sie die Ausgabe in der trans.log Datei. Die trans.log Datei wird an derselben Stelle generiert, an der Sie den R3trans -d Befehl ausgeführt haben.	AWSAdministrator, SAP Basisadministrator
Starten Sie die SAP Anwendung auf dem DR-System.	Starten Sie die SAP Anwendung auf dem DR-System mithilfe des <sid>adm Benutzers. Verwenden Sie den folgenden Code, der die Instanznummer Ihres SAP ABAP SAP Central Services (ASCS) -Servers und die Instanznummer Ihres SAP Anwendungsservers YY darstellt. XX sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem	SAPBasisadministrator
Führen Sie die SAP Validierung durch.	Dies wird als DR-Test durchgeführt, um Beweise zu liefern oder um den Erfolg der Datenreplikation in die DR-Region zu überprüfen.	Testingenieur

Führen Sie DR-Failback-Aufgaben aus

Aufgabe	Beschreibung	Erforderliche Fähigkeiten
Starten Sie die Produktions SAP - und Datenbankserver.	Starten Sie auf der Konsole die EC2 Host-Instances SAP und die Datenbank im Produktionssystem.	SAPBasisadministrator
Starten Sie die Produktionsdatenbank und richten Sie sie einHADR.	Melden Sie sich beim Produktionssystem (host1) an und stellen Sie mithilfe des folgenden Befehls sicher, dass sich die Datenbank im Wiederherstellungsmodus befindet. db2start db2 start HADR on db P3V as standby db2 connect to <SID> Stellen Sie sicher, dass der HADR Status lautetconnected. Der Replikationsstatus sollte seinpeer. db2pd -d <SID> -hadr Wenn die Datenbank nicht inkonsistent ist und sich nicht im connected peer Status N befindet, sind möglicherweise eine Sicherung und Wiederherstellung erforderlich, um die Datenbank mit der aktuell aktiven Datenbank (host2in der DR-Region) zu synchronisieren (aktiviert). host1 Stellen Sie in diesem Fall das DB-Backup aus der Datenbank in der host2 DR-Region auf die Datenbank in der host1 Produktionsregion wieder her.	SAPBasisadministrator
Führen Sie ein Failback der Datenbank zur Produktionsregion durch.	In einem normalen business-as-usual Szenario wird dieser Schritt während einer geplanten Ausfallzeit ausgeführt. Anwendungen, die auf dem DR-System ausgeführt werden, werden gestoppt, und für die Datenbank wird ein Failback in die Produktionsregion (Region 1) durchgeführt, um den Betrieb von der Produktionsregion aus wieder aufzunehmen. Melden Sie sich beim SAP Anwendungsserver in der DR-Region an und beenden Sie die SAP Anwendung. Trennen Sie die /sapmnt/<SID> Installation vom DR-System und stellen Sie sicher, dass die Änderungen auf das Produktionssystem rückwirkend repliziert werden. /sapmnt/<SID> Melden Sie sich beim Datenbankserver (host1) in der Produktionsregion an, und führen Sie die Übernahme durch. db2 takeover hadr on database <SID> Überprüfen Sie den HADR Status: HADR_ROLE sollte PRIMARY aktiviert host1 und StandBy aktiviert seinhost2. db2pd -d <SID> -hadr	SAPBasisadministrator
Führen Sie eine Validierung durch, bevor Sie die SAP Anwendung starten.	Überprüfen Sie die /etc/fstab Einträge /etc/hosts und. /sapmnt/<SID>/Auf dem Produktionssystem montieren. Stellen Sie sicher, dass es mit dem DR-System synchronisiert ist/sapmnt/<SID>/. Melden Sie sich beim <sid>adm Benutzer anR3trans -d, führen Sie die trans.log Datei aus und überprüfen Sie die Ausgabe. Die trans.log Datei wird an derselben Stelle generiert, an der Sie den R3trans -d Befehl ausgeführt haben.	AWSAdministrator, SAP Basisadministrator
Starten Sie die SAP Anwendung.	Starten Sie die SAP Anwendung auf dem Produktionssystem mit dem <sid>adm Benutzer. Verwenden Sie den folgenden Code, der die Instanznummer Ihres SAP ASCS Servers und die Instanznummer Ihres SAP Anwendungsservers YY darstellt. XX sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem  Um zu überprüfen, ob Anwendungsserver verfügbar sind, melden Sie sich an SAP und führen Sie mithilfe der SM51 Transaktionen SICK und Prüfungen durch.	SAPBasisadministrator

Fehlerbehebung

Problem	Lösung
Wichtige Protokolldateien und Befehle zur Behebung HADR verwandter Probleme	db2 get db cfg | grep -i hadr db2pd -d sid -hadr Db2diag.log(Diese Datei befindet sich in der Regel innerhalb des db2dump Verzeichnisses, und der db2dump Pfad wird durch den Parameter definiertDIAGPATH.)
SAPHinweis zur Behebung von HADR Problemen auf Db2 UDB	Weitere Informationen finden Sie im SAP Hinweis 1154013 -DB6: DB-Probleme in der Umgebung. HADR (Sie benötigen SAP Portalanmeldedaten, um auf diese Notiz zugreifen zu können.)

Zugehörige Ressourcen

• Ansätze zur Notfallwiederherstellung für Db2-Datenbanken auf AWS (Blogbeitrag)

• SAPan AWS — IBM Db2 HADR mit Pacemaker

• Schrittweises Verfahren zum Einrichten der HADR Replikation zwischen Datenbanken DB2

• Db2-Wiki HADR

Zusätzliche Informationen

Mit diesem Muster können Sie ein Disaster Recovery-System für ein SAP System einrichten, das auf der Db2-Datenbank läuft. In einer Notfallsituation sollte das Unternehmen in der Lage sein, die von Ihnen definierten Anforderungen bezüglich Wiederherstellungszeit (RTO) und Wiederherstellungsziel (RPO) einzuhalten:

• RTOist die maximal zulässige Verzögerung zwischen der Betriebsunterbrechung und der Wiederherstellung des Dienstes. Damit wird festgelegt, was als akzeptables Zeitfenster gilt, wenn der Service nicht verfügbar ist.

• RPOist die maximal zulässige Zeitspanne seit dem letzten Datenwiederherstellungspunkt. Damit wird festgelegt, was als akzeptabler Datenverlust zwischen dem letzten Wiederherstellungspunkt und der Serviceunterbrechung gilt.

FAQsNäheres dazu HADR finden SAPSie in Anmerkung #1612105 -DB6: FAQ zu Db2 High Availability Disaster Recovery (HADR). (Sie benötigen SAP Portalanmeldedaten, um auf diesen Hinweis zugreifen zu können.)