Mühelose Migration nach SAP® S/4HANA
Traditionelles Datenvolumenmanagement für SAP®
Datenvolumenmanagement in SAP mit SAP Datenarchivierung ist ein etabliertes Verfahren für SAP Kunden seit den Tagen von SAP R/3 und gängige Praktik ebenso für die SAP Business Suite.
Der Grund hierfür liegt auf der Hand und der Nutzen von Datenarchivierung ist offensichtlich: Mit jeder Transaktion werden Daten in der Datenbank gespeichert und das Volumen der transaktionalen Daten steigt beständig. Mit dem Wachstum der Datenbank steigt auch der Bedarf an Hardware-Ressourcen und der Aufwand für die Datenbank-Administration, während sich gleichzeitig die Leistung der Applikation und damit die Antwortzeiten für die Benutzer verschlechtern. Das war die Situation mit den traditionellen Datenbanken der SAP Business Suite. Aber ist das heute noch gültig zu Zeiten von SAP HANA und SAP S/4HANA?
Die neue Welt von “Big Data” mit SAP HANA
Seit SAP SAP® HANA® eingeführt hat, eine neue In-Memory-Datenbank, und Kunden auf “SAP Business Suite on HANA” und SAP S/4HANA migriert sind, gehören einige der Probleme der Vergangenheit an. Hohe Leistungsfähigkeit und schnelle Antwortzeiten sind Kennzeichen von SAP HANA. Ebenso hat sich das Problem der benötigten Ressourcen verbessert, da SAP HANA einen Kompressionsfaktor von etwa 50% hat.
ABER: Als In-Memory-Datenbank erfordert SAP HANA eine robuste Hardware-Plattform. Wenn Ihre traditionelle Datenbank heute eine Größe von 2 Terabyte hat, wird sie mit SAP HANA etwa 1 Terabyte haben und der erforderliche Hauptspeicher wird entsprechend etwas größer bei 1.25 TB sein (Formel: DB Größe (traditionelle DB) / 2 + 20% + 50 GB) gemäß des SAP QuickSizer for HANA SAP OSS Note 1793345). Während sich der Ressourcen-Verbrauch in der Vergangenheit sich auf teure Hochleistungs-Festplatten bezogen hat, bedeutet es heute eine leistungsstarke und teure HANA-Hardware-Plattform.
Bewährte Praktik 1: Datenarchivierung vor der Migration nach HANA
Daher ist es eine gängige und bewährte Praktik, die SAP Datenbank mittels Datenarchivierung von alten transaktionalen Daten zu säubern und diese zu archivieren, bevor die Migration nach SAP HANA bzw S/4HANA durchgeführt wird. Die archivierten Daten bleiben bei einer System-Konvertierung über die SAP Standard-Tools und -Schnittstellen wie dem SAP Archive Information System zugreifbar.
Sollten Sie noch keine Datenarchivierung für Ihre SAP Applikation etabliert haben, ist jetzt ein guter Zeitpunkt damit zu starten, wenn Ihre Datenbank eine relevante Größe von einem Terabyte oder größer erreicht hat.
Bewährte Praktik 2: Verwendung einer rechtskonformen Archivierungsplattform
Und wenn Sie das tun, stellen Sie sicher, dass die erzeugten Dateien mit den archivierten Daten über die ArchiveLink Schnittstelle auf eine sicheren Archivierungsplattform gespeichert werden, die geeignet für die rechtskonforme Ablage und Aufbewahrung der Daten ist. Eine solche Plattform bietet OpenText mit OpenText Archiving and Document Access for SAP Solutions als on-premise Lösung beziehungsweise mit OpenText Core Archive for SAP Solutions als Cloud-Service.
Beide OpenText Lösungen sichern die Authentizität mit Hilfe von Hash-Werten und Zeitstempeln, schreiben automatisch Sicherungskopien der gespeicherten Dateien und bieten mit dem Zugriff über eine Dokumenten-ID eine Abstraktion des physischen Ablageortes. Das ist ein wesentlicher Unterschied dazu, die Datenarchivierungsdateien einfach im Filesystem zu speichern, wo diese Dateien nicht geschützt sind und Sie für den Backup selbst sorgen müssen, ebenso für eine etwaige Migration wenn ein anderer File-Server verwendet werden soll.
Bewährte Praktik 3: Entfernen von unstrukturiertem Content aus der Datenbank
Ein anderer Bereich der Datenbank verdient ebenfalls Ihre Aufmerksamkeit, die Ablage von unstrukturiertem Content. Sofern Sie die Ablage für GOS Attachments (GOS = Generic Object Services) nicht explizit definiert haben, wird aller unstrukturierter Content den Ihre Anwender über GOS speichern, in einer Tabelle Ihrer SAP Datenbank abgelegt und trägt zu dem Volumen der Datenbank bei. Sie können die Größe der Tabelle SOFFCONT1 überprüfen und sollten ebenfalls die Tabelle DRAO für SAP DMS (Document Management System) prüfen.
GOS-Attachments ebenso wie DMS-Dokumente können mit OpenText Core Archive bzw. OpenText Archiving and Document Access gespeichert werden. Hierzu müssen Sie lediglich eine neue Ablage (TA SKPR08) konfigurieren. Und für die Migration von existierendem Content in der Datenbanktabelle zu einer Archivierungsplattform gibt es den SAP Report RSIRPIRL. Damit wird der Content in der OpenText Lösung gespeichert und Ihre Datenbank wird von der Last des unstrukturierten Content befreit.
Fazit: Etablieren Sie Datenvolumenmanagement und Reduzieren Sie Ihren TCO
Unsere Empfehlung ist Datenvolumenmanagement zu etablieren. Datenarchivierung hilft Ihnen die Größe Ihrer SAP Datenbank zu reduzieren und zu kontrollieren. Damit reduzieren Sie die Administrations- und Hardware-Kosten und können die Gesamtkosten Ihrer SAP-Landschaft signifikant senken. Und wenn Sie nach SAP HANA bzw. S/4HANA migrieren, können Sie erhebliche Einsparungen realisieren indem Sie den Hauptspeicherbedarf der HANA Datenbank reduzieren und damit die Dimensionieren und Kosten für die entsprechende Hardware.
Mehr Information über SAP Daten- und Dokumenten-Archivierung mit OpenText finden Sie unter folgenden Links:
Kundenreferenzen zum Thema SAP-Datenarchivierung finden Sie hier.
