Nach nun schon einigen Jahren an der SAP Basis, werde ich zur Zeit immer häufiger mit der Anfrage konfrontiert, eine Mandantenkopie vom Produktionssystem (Mandanten) auf einen zusätzlichen Mandanten im Sntwicklungssystem bereitzustellen (Kopierprofil SAP_ALL). Besonders die Formularentwickler machen immer wieder Druck, dass sie ohne die Daten (also z.B. im eigentlichen Entwicklungsmandanten) kaum Formulare entwickeln könnten.

Ich selbst stehe dazu sehr distanziert, da nach meinem Verständnis komplette Stamm- und Bewegungsdaten auf einem Entwicklungssystem nichts zu suchen haben. Ich denke dabei vor allem an Datensicherheit und daran, dass Entwicklungssysteme nicht zum Testen da sind. In einer 3 Systmlandschaft gibt es dafür die Testsysteme. Und wenn etwas an Daten getestet werden soll, dann muss es halt ins Testsystem transportiert werden.

Wie handhabt ihr das bei euch? Würdet ihr eine Kopie des PRD Mandanten in die Entwicklung machen bzw. wird das bei euch gemacht?

Für Antworten und Anregungen bin ich euch sehr dankbar.

GBerndt

Moin zusammen,

da muss ich meinem emsländischen Kollegen recht geben. Wegen der Berechtigungsprobleme werden FI, CO und HR Daten gelöscht, bzw. verfälscht. Die HR-Daten werden beispielsweise mit HRSEL heruntergeladen, verfälscht und dann ins Testsystem gespielt. Wie wir das allerdings mit FI und CO Daten machen weiss ich leider nicht. Hatten bisher mit keiner Prüfung Probleme wegen der Kopie des Prod-Mandanten, da, wie gesagt, alle sensiblen Daten verfälscht werden.

Gruß nikibert

Hallo, wir haben bei uns volle Systemkopien in den D Systemen. Der Zugriff ist allerdings auf Entwickler reduziert, da wir

uns nicht durch jedes Customizing, daß dann ggf. nicht funktioniert, die Q Umgebung zerschreddern lassen wollen. Eine Lösung des Problems kann das Toll DISTILLERY von SNP sein. Hiermit kann ich Daten abziehen, verfällschen und zudem noch reduzieren auf das Notwendige. Fürs Testen in der D Umgebung allemal gut genug. Nachteil ist aber, es kostet ein wenig Geld. Wir haben imer ein Jahr Daten vorrätig. Kritische Daten werden nicht mit übertragen bzw. falls doch mal erforderlich verfällscht.

Gruß

Siggi

Hallo,

wir haben ähnliche Forderungen von Formular(-/Entwicklern), dass ohne eigentliche Daten nicht anständig entwickelt werden kann. Das Problem lag hauptsächlich darin, dass die Zeiten für den Transport zu langwierig waren.

Wir haben daher versucht, einen direkteren Weg zu finden und sind auf den Transportworkflow gestossen. Mit diesem konnten, wir die Forderungen der Entwickler besser abdecken, da diese nun selbständig einen Transportantrag stellen konnten und diesen auch mit Prioritätsvermerken versehen konnten. Zudem lässt sich die Entwicklung der Transporthistorie für den Antragsteller besser nachvollziehen.

Wenn es denn unbedingt notwendig ist, kann man ja auch Auszüge einzelner Tabellen ins E-System transportieren.

Eine Kopie des P-Systems in das E-System lehnen wir aber auch ab.

Viele Grüsse,
Sebastian

Wir haben bei uns 3 Systeme.

Entwicklungssystem, Abnahme (Test) und eben Produktivsystem.

Es wird also im Entwicklungssystem entwickelt, dann ins Abnahme transportiert und dort getestet und wenn dies erfolgreich war gehts ins Produktivsystem.

Auf dem Testsystem sind irgendwelche uralt Daten...gab aber noch nie irgendwelche Probleme und ging immer mit dem Testen. Originaldaten sind meiner Meinung nach nicht unbedingt erforderlich und haben vor allem in einem Entwicklersystem nichts zu suchen.

Noch eine Bemerkung: Die SAP Mandante-Kopie funktioniert nicht bei wirklich großen Mandanten.

Gruß

wirklich großen Mandanten

wirklich großen Mandanten

^^ was ist denn ein großer Mandant? Größer 100 GiB? Größer 500 GiB? Größer 1 TiB?

Ciao, OldSAPGuru

Ich glaube das ist abhängig vom Zeitpunkt der Frage. Heute vielleicht ein paar Terabyte, morgen zweistellige Terabytes und übermorgen dreistellig...

- Größe der Datenbank und zur Verfügung stehend Hardwareressourcen

- Anzahl der Einträge in besonders grßen Tabellen (COEP, etc.)

- sind bestimmte z.B. controllinglastige funktionen aktiviert, wie Ergebnisfortschreibung, Reportings, welche ebenfalls Tabellen mit vielen Einträgen (bis weit über 10 Mio) erzeugen -> bei so großen Tabellen steigt die Laufzeit beim kopieren der Einträge stark an

- haben Quell- und Zielmandant die gleiche Nummer, wenn nicht kann sich das negativ auf die Laufzeiten auswirken

- Bei einer Remote Kopie kann mit parallelen Prozessen und Speicherparametrisierung einiges für die Performance getan werden. Muss die Methode Kopie als Transport angewendet werden, wird es diesbezüglich zäh, weil nur mit einem Prozeß der in die Transportdatei schreibt gearbeitet werden kann.

Das ganze kann vorab getestet werden damit es keine unliebsamen Überaschungen gibt, weil die Kopie zum Wochenende gestertet wurde und nun in die Woche hinein andauert und keiner weiss wann sie fertig ist.

Gruessle

GBerndt