SAP Identity Management: Datenbankmigration – Systemkopie (mit Checkliste)

Sie sind unzufrieden mit Ihrer aktuellen Datenbank in SAP IDM und möchten diese gerne umstellen, aber trotzdem Ihre historischen Daten nicht verlieren – vielleicht sogar im Zuge eines SAP IDM Upgrades? Dann gibt Ihnen dieser Blog einen Überblick über mögliche Szenarien (hier konkret: Datenbankmigration von Oracle zu MS SQL), einen Link zu einer nützlichen SAP-Dokumentation, eine Checkliste zum Download am Ende des Beitrags, sowie Hinweise zum Error Handling.

Problemstellung

Die Gründe für einen Wechsel Ihrer Datenbank können vielseitig sein, sei es nun aufgrund von Kosten, der Performance, des Nutzungsumfangs oder anderweitigen Gründen. Die Herausforderungen, die dabei entstehen, dürfen nicht unterschätzt werden! Die Frage was mit Ihrem SAP IDM-System und den Daten, die in der SAP IDM-Datenbank gesichert sind, passiert, steht für Sie als SAP IDM-Anwender im Vordergrund. Gerade auditrelevante Tabellen oder solche, die historische Werte sichern, wie die OLD_VALUE Tabelle, müssen auch bei einem Wechsel der Datenbank erhalten bleiben. Leider ist dieses relevante Szenario nur für Kunden möglich, die noch ein SAP IDM 7.2 im Einsatz haben! Bitte beachten Sie die Hinweise dazu im Fazit. Der Wechsel der Datenbank lässt sich auch mit dem unumgänglichen Upgrade auf IDM 8.0 verbinden. Auch hierbei liefern wir Ihnen gerne kompetente Unterstützung. Die nachfolgenden Hinweise sind momentan nur relevant, wenn Sie ein SAP IDM 7.2 mit SP07 oder höher im Einsatz haben und Sie Ihre Datenbank nach einer dieser Konstellationen umstellen wollen:

Abb. 1: Migrationsmöglichkeiten

Die SAP bietet für diese Konstellationen eine Dokumentation, sowie bereits erstellte Jobs an. Diese sind unter folgendem Link verfügbar.

Der nächste Abschnitt enthält eine detaillierte Beschreibung der Punkte, die zu erledigen sind sowie Hinweise zum Error Handling.

Lösung

In der SAP-Dokumentation erhalten Sie eine Übersicht über Voraussetzungen, die Sie unbedingt berücksichtigen sollten. Die Checkliste im Anhang dieses Blogs geht bzgl. der Tätigkeiten weiter ins Detail.

Analyse der Quelldatenbank

Mit dem folgenden Statement kann die Größe der einzelnen Tabellen ermittelt werden:

Abb. 2: Oracle Statement

Die großen Tabellen können dann hinsichtlich ihrer Anzahl an Einträgen erneut geprüft werden. Die MXI_OLD_VALUES ist typischerweise eine der größten Tabellen.

Abb. 3: SQL Statement

Neuen Dispatcher konfigurieren

Die folgenden Screenshots zeigen die Konfiguration des neuen Dispatchers, der speziell für die Datenbankmigration benötigt wird:

Abb. 4: Dispatcher – Options
Abb. 5: Dispatcher – Policy

Repository-Konstanten bearbeiten

Nach dem Import des entsprechenden Jobs von der SAP ist ein neues Repository verfügbar. Die Konstanten müssen angepasst werden:

Abb. 6: Repository Constants
  1. JDBC URL des Admin User der Quelldatenbank
  2. JDBC URL des Oper User der Quelldatenbank
  3. Prefix der Quelldatenbank
  4. JDBC URL des Runtime User der Quelldatenbank
  5. JDBC URL des Oper User der Zieldatenbank
  6. Prefix der Zieldatenbank
  7. JDBC URL des Runtime User der Zieldatenbank

Tabellen bereinigen

Um zu verhindern, dass unnötiger Ballast mitkopiert wird, sollten einige Tabellen/Views bereinigt bzw. leer sein. Folgende Tabellen sollten vor der Datenbankmigration leer bzw. bereinigt sein:

  • idmv_entry_simple ⇾ sollte leer sein, hinsichtlich Pending-Value-Objekten
  • idmv_approvals_ext ⇾ sollte leer sein
  • mxp_provision ⇾ sollte leer sein
  • Audittabellen ⇾ bereinigen, z.B. alles, was älter als 2 Jahre ist entfernen
    • mxp_audit_variables
    • mxp_ext_audit
    • mxi_link_audit
    • mxp_audit

Jobs ausführen

Die Jobs müssen nacheinander, in der entsprechenden Reihenfolge, ausgeführt werden:

Abb. 7: Joblog – Job 1-5

Sobald diese fünf Jobs erfolgreich ausgeführt wurden, können die eigentlichen Copy Jobs der Oper- und Runtime-Tabellen starten. Es empfiehlt sich hierbei die Jobs aufzuteilen und einzelne Tabellen in einem eigenen Job auszuführen. Dabei sollten möglichst die großen Tabellen einzeln durchlaufen, diese wurden bereits bei der Analyse der Quelldatenbank identifiziert. Es kann sogar ratsam sein, einzelne Tabellen noch weiter aufzuteilen und diese dann als aufeinanderfolgende Passes im Job auszuführen. Sobald alle Tabellen kopiert wurden, kann auch der letzte Job ausgeführt werden:

Abb. 8: Joblog – Job 8

Bitte beachten Sie, dass sich das SAP IDM-System während der Durchführung der Jobs in der Downtime befindet und zwar so lange bis die Checkliste vollständig und fehlerfrei abgearbeitet wurde. Die Dauer der Copy Jobs richtet sich nach der Größe der Tabellen und kann variieren. Daher ist es schwer abzuschätzen wie lange die Downtime dauert. In besonderen Fällen kann allein die Kopie einer Tabelle bis zu vier Tagen dauern.

Error Handling, bei der Ausführung der Copy Jobs:

  • Message:

…„java.lang.Throwable: Der Treiber konnte keine sichere Verbindung mit SQL Server über die SSL (Secure Sockets Layer)-Verschlüsselung herstellen. Fehler: ‚SQL Server hat eine unvollständige Antwort zurückgegeben.“…

Lösung:

Der Pass, der fehlgeschlagen ist, muss kopiert und in einem neuen Job erneut ausgeführt werden. Der Fehler entsteht aufgrund einer Überlastung der Datenbank und kann nur durch das erneute Ausführen des Passes gelöst werden.

  • Message:

Keine Message, aber Fehler beim Kopieren der Audittabellen

Lösung:

Audittabellen vorab bereinigen

  • Message:

…“putNextEntry failed storing XXX und putNextEntry failed storing XXX

Exception from Add operation:com.microsoft.sqlserver.jdbc.SQLServerException: The INSERT statement conflicted with the CHECK constraint „CK_MXP_TASKLNK“. The conflict occurred in database „mxmc_db“, table „dbo.MXP_TASKLNK“.

Exception from Modify operation:com.microsoft.sqlserver.jdbc.SQLServerException: The UPDATE statement conflicted with the CHECK constraint „CK_MXP_TASKLNK“. The conflict occurred in database „mxmc_db“, table „dbo.MXP_TASKLNK“…

Lösung:

Die Einträge müssen manuell, per Datenbank Insert, eingefügt und kontrolliert werden. Falls das Einfügen tatsächlich nicht möglich sein sollte, kann dies aufgrund von Datenbank Constraints passieren. Hier muss im Einzelfall geprüft werden, wie die weitere Vorgehensweise ist.

Weitere Fehlerquelle:

Zu kleine Rollbacksegmente und zu wenig Tablespace (Einstellung: autoextend).

Identity Center anpassen

Im Identity Center muss an mehreren Stellen die neue Datenbankverbindung gepflegt werden:

  • Tools >> Options
  • In Ihrem angelegten System in der Management Console (Einstellungen zur Datenbank):
Abb. 9: Anpassungen Identity Center

VDS Konfigurationen

Falls der Virtual Directory Server (VDS) benutzt wird, müssen hier die Konfigurationen ebenfalls angepasst werden: Aus diesem Grund darf der Size Limit Type nicht vergessen werden (TOP bei MSSQL):

Abb. 10: VDS Einstellung

Fazit

Die Datenbankmigration ist eine empfehlenswerte Möglichkeit für Sie, um ihre SAP IDM-Datenbank zu wechseln. Leider gibt es ein paar Schwachstellen, wie bspw. die große Unsicherheit über die Dauer der Downtime oder die nicht vorhandene Möglichkeit, dieses Szenario in der SAP IDM 8.0 Umgebung umzusetzen. An genau diesem Punkt arbeiten wir aktuell. Wir möchten es Ihnen auch in der SAP IDM 8 Umgebung ermöglichen, eine Datenmigration durchführen zu können. Aktuell befindet sich dieses Projekt in der Entwicklungsphase und sobald die Entwicklung abgeschlossen ist, werden wir Sie auf unserer Website informieren. Haben wir Ihr Interesse geweckt? Dann informieren Sie sich auf unserer Website oder besuchen Sie eines unserer Webinare.

Checkliste zum Download

Valerie Neunheuser
Kontakt

Nehmen Sie Kontakt mit uns auf!

Haben Sie Fragen zu unseren Produkten?

+41 43 422 8803
[email protected]
+49 7656 8999 002
[email protected]
+1 855 594 84 64
[email protected]
+44 1454 838 785
[email protected]
Kontakt
Webinare

Besuchen Sie unsere Live-Webinare und lernen Sie von unseren Experten mehr zu SAP-Berechtigungen, XAMS, SAP IDM und zu vielen weiteren Themen im Kontext von SAP Security.

Hier anmelden