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.
--

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. vue mandant USR02

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

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.
la transaction SCCL : SCCL

les optimisations classiques sont le nombre de processus à utiliser ( goto \ parallel processes ) SCCL option parallel

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

SCCL experts settings

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)

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.
homme musclé


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.

SCCL : Exclude tables SCCL exclude tables
ST04 : Large tables ST04 Large tables

Maintenant, vous devriez avoir une copie de mandant réalisée à 90%.
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 10% 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.

Bon et comment on fait ça ? comme ça : SQL Copy client

  • 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).

usage CPU DB

  • 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

SQL insert Hana

  • 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

MARC

--

--

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

--

--

--