Cet article présente une solution technique dans le cadre d’une copie de mandant qui n’arrivait pas à son terme chez un client. La reco vue la taille de la DB était une copie de système via « System Copy DB » , néanmoins le challenge technique à relever était intéressant et motivant. il a été ainsi possible avec un peu d’effort et d’actions manuelles de réaliser une copie de mandant d’un environnement de SAP ECC de 1TB.
—

Une copie de mandant consiste à dupliquer les données sur une même base de données en affectant les données à un mandant SAP.

la méthode décrite ci dessous est maintenant disponible en standard à partir des notes OSS suivantes :

2761821 – Performance improvement for HANA and Oracle systems : Client copy
[…]
This note will replace the OPEN CURSOR and FETCH statement with a native INSERT FROM SELECT and DELETE statement.
[…]
3019660 – PITCABAPBPF-3492: Oracle/HANA-Performance-Note: Make native DELETION/COPY-statement switchable
[…]
After implementation of this note you have a new Expert Setting called « NATIVECOPY » in « Expert Settings » of Local Client Copy available.
[…]

---

pour notre culture, d’un point de vue logique, voici la modélisation à garder en tête :

Lorsque la taille de la DB dépasse les 300GB, et que certaines tables contiennent plusieurs millions d’enregistrements voir quelques milliards, l’opération de copie qu’on lance par la transaction SCCL peut prendre un temps certain ou voir un certain temps. à savoir que chez SAP Hana Cloud, au dessus de 300GB, un system copy sera requis. Pour les autres et si vous souhaitez tout de même procéder à une copie de mandant, il existe quelques solutions.

les optimisations classiques sont d’activer le parallélisme et définir le nombre de processus à utiliser ( goto \ parallel processes )

Ensuite nous avons les options expertes décrites dans la note oss « 446485 – CC-ADMIN: Special copying options » :

Il vous faudra appliquer les quelques bonnes pratiques issues des notes :

• 67205 – CC-INFO: Copying large and productive clients ».
• 2555451 – Performance improvement in Client Copy for HANA

nous allons cocher les options suivantes : CWITH_CURS ; DWITH_CURS ; LARGEBLOCK ; SKIP_EMPTY ( note oss 2555451 ) et SINGLECOPY (Copy tables with exclusion mode ‘S’ first)

Et si ça ne suffit pas :

Extraire rapidement une table très volumineuse de la base Hana n’est plus vraiment possible par rapport à une DB Oracle et son mode bulk export ; l’option remap (note 1712612). C’est là que la manipulation SQL vous permettait d’atteindre le graal de réussir la copie de mandant

Lorsque vous aurez fait quelques tests de copie de mandant via la SCCL et pris les temps des tables qui posent problèmes, après une analyse de leurs fonctionnalités et des données résidentes, si une réduction de la volumétrie n’est pas envisageable, il restera à les exclure et à les traiter séparément. Par exemple prenons le TOP 20 de la volumétrie en mémoire de notre DB.

Maintenant, vous devriez avoir une copie de mandant réalisée à 50%.
Vous aurez pris le soin de bloquer le mandant source pendant toute la durée de l’opération afin de rendre la copie consistante.

Intéressons nous maintenant à vos 50% restants que constituent les tables que nous avons exclus et que la SCCL n’arrive pas à traiter correctement.

1. exporter les données n’est pas optimale ; entre la volumétrie ; le temps nécessaire à l’export et à l’import ; et l’impossibilité de faire un remap de la colonne MANDT ; notre fenêtre de tir ne sera pas optimale;
2. une solution consiste à utiliser la pleine puissance de la DB Hana pour monter en mémoire la table et manipuler le champ MANDT et enfin faire un insert dans la table.

• le point positif : très rapide et très simple à mettre en oeuvre.
• le point négatif : va utiliser deux fois la taille de la table en mémoire et un peu de CPU. La taille des log va augmenter de tout autant pendant le traitement (passer la db en archivelog overwrite).

un exemple concret : 1 table ayant une taille mémoire : 4GB avec 202 millions entrées occupant un espace disque de 3,4GB => 105h export / import via R3trans ; impossible via la SCCL ; et en requête SQL sous Hana : 49 minutes

un autre exemple : 1 table ayant une taille mémoire : 18GB avec 660 millions d’entrées occupant un espace disque de 20GB => 900h d’export / import via R3trans ; impossible via la SCCL ; et en requête SQL sous Hana : 4h30. taille occupée après copie et compression : 25GB

Bonne manipulation ! et n’hésitez pas à me contacter si vous avez des questions.