en tant qu’expert sur l’archivage et l’optimisation des systèmes SAP, je vais vous partager un cas qui doit concerner la majeur partie des systèmes non optimisé.
Vous constatez que la table n°1 en terme de taille est la table SOFFCONT1. Kezako ?
Le fonctionnement standard SAP n’aide pas à réduire cette table. Sur certains systèmes où rien n’a été fait et on dépasse facilement les 100GB pour une seule table, voir plus.
pour vérifier sa taille , tcode ST04
Sur une base HANA, cette table ne sera pas la plus critique en raison du type de stockage de la colonne qui contient le binaire. Mais sur les bases de données classiques, c’est du stockage rapide dédié au transactionnel qui sera monopolisé. Une solution est d’utiliser un serveur de contenu avec un espace de stockage classique ou d’envisager la suppression des données.
Présentation : il s’agit d’une table qui va contenir les fichiers binaires PDF, CSV, JPEG, DOCX… provenant de vos utilisateurs via le GOS ; puis les fichiers transmis par Email et enfin les documents binaires transmis par SAPOffice (transaction SBWP).
Le standard SAP permet de stocker les pièces jointes dans la base de donnée, mais lorsque le système commence à être utilisé massivement, on constate une croissance de la base de données transactionnelle alors que le business ne croit pas d’autant.
Contrôles : tcode ST04 et TAANA
Afin de réduire la volumétrie de cette table et donc de la base de données transactionnelle, il va falloir suivre quelques étapes :
- décider d’une rétention de ces données ou envisager l’archivage
- installer un serveur de contenu (SAP Content Server)
- effectuer le paramétrage en OAC0 pour déclarer ce stockage externe
- appliquer la note 530792 (Storing documents in the generic object services) ou planifier un job de transfert des données SOFFDB vers SOFFHTTP
- transmettre les documents binaires existants vers le content server : 389366 : Relocation of documents
- et au préalable, s’assurer que les emails sont supprimés régulièrement : 966854 (Reorganization – New report)