Was sind typische Fehlerquellen, während einer Inplace Migration und wie können diese gelöst werden?

Erneut ein spannendes Themenfeld, mit welchem sich PRODATO beschäftigen darf und in folgendem Blogbeitrag alle wesentlichen Fakten für Sie zusammenfasst.
Im Gegensatz zu anderen Migrationsvarianten birgt die Inplace Migration, aufgrund der direkten Umstellung im Produktivsystem ein erhöhtes Fehlerpotenzial für den laufenden Betrieb. Das Risiko besteht darin, dass z.B. Berichte, Auswertungen oder Datenmodelle bei auftretenden Fehlern während der Migration entweder nicht mehr verfügbar sind oder Einschränkungen aufweisen. Im folgenden Blogbeitrag werden verschiedene Fehlerquellen und ihre Lösungsansätze behandelt, mit dem Ziel, die Ausfallzeit zu minimieren.

Unvollständiger Data Mart Status

Ein sich häufig wiederholender Fehler ist die Vollständigkeit des Data Mart Status und der damit verbundenen Delta Verbuchungen. Zur Behebung dieses Problems wird empfohlen, die Delta DTPs entlang des gesamten Datenflusses erneut auszuführen und zu aktivieren. Häufiger sind jedoch die Vorsysteme, wie zum Beispiel Entwicklungs- und Qualitätssysteme, betroffen, da es hier in der Regel nur Testdaten gibt, die oft nicht vollständig konsistent sind.

Systemkopien und deren Folgearbeiten

Während eines Migrationslaufs können Probleme im Zusammenhang mit veralteten oder fehlerhaften INITs auftreten. Diese sind meistens auf Systemkopien zurückzuführen, da diese wiederum dazu führen können, dass die Verbindung zwischen DTP/InfoPackage und dem INIT verloren geht. Diese Probleme sollten vor der Migration bereinigt werden, indem man in der Tabelle „rssdlinit“ im BW-System überprüft, ob ein veralteter INIT-Eintrag vorhanden ist. Falls der Eintrag in der Spalte „LAST_DELTA“ keinen Wert aufweist, wird empfohlen, diesen Eintrag zu entfernen.

Semantische Gruppen im DTP

Wenn ein DTP von einer Persistent Staging Area (PSA) Daten lädt und semantische Gruppen definiert sind, ist es ratsam, ein Staging ADSO (Advanced DataStore Object) zu verwenden, damit die Nutzung der semantischen Gruppen beibehalten werden kann. Unterlässt man jedoch das Einfügen eines Staging ADSO und behält gleichzeitig die semantischen Gruppen bei, erfolgt keine Übertragung von Datensätzen von der ODP-Datenquelle in das ADSO. Für die Gewährleistung der Datenübertragung ist es notwendig, die semantischen Gruppen aus dem DTP zu entfernen.

DSOs mit Datenarchivierung

Vor der Migration eines DSOs mit Datenarchivierung sind verschiedene Aspekte zu beachten.
Das klassische Request- und Status-Management (RSSM) mit der Request ID (0REQUID) existiert nicht mehr unter BW/4HANA und wird durch das neue Request-Status-Management (RSPM) auf Basis der Request Transaction Sequence Number (0REQTSN) ersetzt. Dabei dient die Request ID als eindeutige Identifikation für einen bestimmten Request, während die Request Transaction Number dazu dient, die zeitliche Reihenfolge der Requests zu repräsentieren. Dies erfordert eine Anpassung der Requestverwaltung im BW-System für Archivdaten auf RSPM.
Es ist zusätzlich erforderlich, dass die Archivierungsdaten im SAP-Format (CESU-8) vorliegen, um Probleme bei der Migration zu vermeiden, insbesondere wenn zuvor nicht die SAP-Standard-Archivierungsklasse verwendet wurde. Bei der Archivierung von Zeitscheiben muss darauf geachtet werden, dass das DSO ein Zeitmerkmal im Schlüssel hat und somit die Eindeutigkeit der archivierten Sätze gewährleistet ist.
Wenn der folgende Fehler auftritt, resultieren Inkonsistenzen in der Tabelle RSDANLREQ, was zu einer fehlerhaften Befüllung der Tabelle RSDAARCHREQ führt.

Die Tabelle RSDANLREQ enthält die Daten für ein Archivierungsobjekt, während in der Tabelle RSDAARCHREQ die Archivierungs-Request-Informationen abgelegt sind. Die Ursache für die Fehlermeldung liegt darin, dass in der Tabelle RSDANLREQ mehrere Datensätze mit dem Wert „0“ in der Spalte ARCHREQUID_SID (Archivierungs-Request ID) vorhanden sind. Zur Fehlerbehebung sollte dieser Eintrag mithilfe der Tabelle RSDAARCHREQ und des Schlüssels (REQUID_SID) für den gleichen Request (NLREQUID_SID) vervollständigt werden.

Transformation mit HANA-Runtime

 Beim Versuch, eine Transformation mit einer InfoSource als Quelle zur HANA-Runtime zu ändern, kann ein Fehler auftreten, wenn die Option „Aggregierte Sätze bezüglich InfoSource-Schlüsselfelder“ in der InfoSource aktiviert ist. Diese Option ist technisch notwendig, um inkonsistente Ergebnisse aufgrund von Aggregation und RECORDMODE-Behandlung zu vermeiden. Seit dem Release von BW/4 HANA 1.0 SP08 wird diese Einstellung jedoch nicht mehr unterstützt.
Falls die Option beibehalten werden muss, ist es erforderlich, den Laufzeitmodus auf ABAP zu setzen. Andernfalls ist eine Neumodellierung notwendig.
Als Lösungen können in Betracht gezogen werden:

• Die Einführung eines Staging ADSO anstelle der InfoSource ermöglicht die Nutzung des Standard ADSO Verhaltens und der Aggregation.
• Die Schlüsseldefinition der InfoSource entfernen, wodurch alle vorhandenen Merkmale als Schlüssel behandelt werden, und keine Aggregation stattfindet.
• Entfernen der Option „Aggregierte Sätze bezüglich InfoSource-Schlüsselfelder“ in der InfoSource selbst.

Migrationslauf stoppt

Des Weiteren kommt es gelegentlich vor, dass der Migrationslauf stoppt und sich nicht mehr fortsetzen lässt. Zwei typische Fehler und ihre teilweise gemeinsame Fehlerbehebung werden im Folgenden beschrieben.
Der erste Fehler bezieht sich auf eine ungültige ChangeLog-Version von einer früheren Export Data Source in der Tabelle RSTSODS. Dies tritt auf, wenn versucht wird, ein DSO zu migrieren, welches zuvor von einer Export DataSource befüllt wurde. Dadurch kann es vorkommen, dass noch ein alter Eintrag mit ungültiger Version in der Tabelle RSTSODS vorhanden ist.

Bei dem zweiten Fehler kann der Datenbankindex für ein DSO nicht gefunden werden

Als Lösung für diese Fehler wird empfohlen, die betroffenen DSOs erneut zu aktivieren, um die Metadatenobjekte, wie zum Beispiel Tabellenstrukturen, Indizes und die Referenzen zu aktualisieren. Jedoch sollte beachtet werden, dass ab dem Schritt „Alle Datenänderungen sperren“ des Migrationslaufs keine Änderungen am DSO mehr möglich sind. Zur Umgehung dieser Einschränkung ist ein direkter Eingriff in die Sperrtabelle RSMIGROBJ für Migrationsobjekte erforderlich, um den Eintrag für das jeweilige Objekt zu entfernen. Nach dieser Maßnahme ist die Aktivierung wieder möglich.
Die Lösung für den Fehler bezüglich des fehlenden Datenbankindex besteht darin, das DSO einfach zu aktivieren. Anschließend kann der Migrationslauf fortgesetzt werden.
Die Aktivierung des DSOs allein behebt nicht den Fehler mit der ungültigen Version des ChangeLogs. Für die Deaktivierung der ungültigen Einträge in der Tabelle RSTSODS steht ein PSA Reparatur Programm namens „RSAR_RSTSODS_CHANGELOG_VRS“ zur Verfügung. Dieses Programm überprüft, ob ein Standard DSO einen versionierten ChangeLog hat, und deaktiviert anschließend die Version des ChangeLogs, die keine Daten besitzt. Nach dieser Anpassung kann der Migrationslauf auch in diesem Fall fortgesetzt werden. Es sei darauf hingewiesen, dass neben diesem Programm weitere PSA Reparatur Programme für unterschiedliche Szenarien zur Verfügung stehen (siehe: https://help.sap.com/docs/SUPPORT_CONTENT/bwdabc/3361383485.html).

Unterschiedliche DTP IDs zwischen Systemen

Ein weiteres potenzielles Problem bei der Inplace Migration betrifft die unterschiedlichen IDs der Delta- und Full-DTPs zwischen den Systemen. Dies kann zur Konsequenz haben, dass nach der Migration und einem notwendigen Transport ein neuer DTP im Produktivsystem erstellt wird, was beispielsweise zur Existenz von zwei Delta-DTPs führen kann. Wenn gleichzeitig die Prozesskette des jeweiligen DTPs mittransportiert wird, besteht die Gefahr, dass der falsche DTP beladen wird und der Delta-Status verloren geht.
Der fehlende Referenzeintrag zum originalen DTP in der Tabelle TADIR im Produktivsystem ist hierfür der Grund. Dieses Problem entsteht, da durch die Migration der Eintrag für die Spalte DTP_ORIGINAL in der Tabelle RSBKDTP überschrieben wird, wodurch die Verbindung der DTPs zwischen den Systemen verloren geht.

Die Lösung für dieses Problem besteht darin, die Referenz DTP ID des DTPs im Produktivsystem in der Tabelle RSBKDTP zu setzen. Dadurch wird eine Verbindung zwischen den beiden DTPs hergestellt und es ist möglich, den bestehenden DTP zu ändern, anstatt einen neuen anzulegen. Dies gewährleistet die korrekte Fortsetzung des Delta-Prozesses nach der Migration. Des Weiteren wird empfohlen, das Transfer-Cockpit immer aktuell zu halten, da hier häufig Fehlerkorrekturen eingespielt werden.

Aktivierung der V2-Struktur eines DSOs

Im Verlauf einer Migrationsausführung können Probleme bei der Aktivierung der V2-Struktur eines DSOs auftreten. In einem solchen Fall wird die Fehlermeldung ausgegeben:

Das DSO enthält eine Kennzahl, die standardmäßig eine Referenz zum Standard-InfoObjekt 0BASE_UOM mit dem Typ UNIT aufweist. Allerdings gibt es auch ein benutzerdefiniertes InfoObjekt BASE_UOM ohne die Zusätze Z oder Y, das beispielsweise den Typ CHAR hat. Während der Auflösung der Währungsreferenz kommt es zu dem Fehler, dass die 0 von 0BASE_UOM ignoriert wird, und somit das benutzerdefinierte InfoObjekt mit dem falschen Typ verwendet wird.
Die Behebung dieses Fehlers erfolgt durch das Einspielen des entsprechenden Support Packages für die derzeitige SAP BW-Version, wodurch die Referenz anschließend wieder korrekt aufgelöst wird. Welches Support Package benötigt wird, kann der folgenden SAP Note entnommen werden: https://me.sap.com/notes/3376988/D

Fazit

Die Inplace-Migration zu SAP BW/4HANA bringt aufgrund der direkten Umstellung im Produktivsystem Risiken für den Betrieb und die Datenkorrektheit mit sich. Daher ist es besonders wertvoll, bereits Lösungen für häufig auftretende Fehler zu haben, um die Ausfallzeit möglichst zu minimieren. Andererseits zeigen sich vor allem individuelle Fehler während eines Migrationslaufs, die eine umfassendere Suche nach Lösungen erfordern.
Durch unsere erfolgreich abgeschlossenen und laufenden Migrationsprojekte erweitern wir kontinuierlich unser Fachwissen. In zahlreichen Projekten haben wir vielfältige Fehler identifiziert und erfolgreich behoben. Dies ermöglicht uns, zukünftige Migrationen effizienter durchzuführen und dank unserer langjährigen Erfahrung schnell auf mögliche Probleme zu reagieren.

Sind Sie auf der Suche nach einem zuverlässigen Partner für Ihre anstehende Migration auf BW/4HANA oder Datasphere? Vielleicht ist unsere Systemanalyse genau das Richtige für Sie: Quickstart BW/4HANA Migration
Oder sind Sie bereits mitten in einer Migration und brauchen einen Experten, der Sie auf den restlichen Schritten begleitet? Melden Sie sich bei uns!
SAP | PRODATO verbindet