Après de nombreuses années d’utilisation, la taille de la base de données SAP HANA sur un serveur SAP BW peut accroitre fortement. Il existe des moyens pour la surveiller, l’optimiser et maitriser sa croissance. Nous allons décrire dans cet article tous ces aspects.
En simplifiant, HANA stocke les données techniques dans la zone Row Tables et les données applicatives dans la zone Columns tables. HANA utilise une zone temporaire pour réaliser ces calculs (agrégations filtres, etc.) et il reste une zone libre que HANA peut utiliser en fonction des besoins d’allocation de mémoire.
HANA studio ne doit plus être privilégié pour ce genre d’activité. Trop de restrictions sont présentes.
Cet outil a pour avantage d’être facilement accessible. Il va remonter des indicateurs similaires à ceux de HANA Studio.
HANA Cockpit est maintenant l’outil officiel pour monitorer et administrer la base de données SAP HANA. Les indicateurs mémoires restent à un niveau agrégé. Il faudra utiliser un autre outil pour une analyse plus fine
C’est l’outil avec lequel on aura le plus de visibilité. Solution manager peut stocker une granularité fine avec un historique important. Solution manager propose un business content dédié à SAP HANA.
Exemple d’infoproviders :
–> 0HDB_MP01 : Host memory usage
–> 0HDB_MP17 : Service Memory Component
Par défaut les infoproviders de solution manager ne sont pas alimentés. Il faut les paramétrer pour une alimentation automatique.
Pour avoir un reporting dynamique et détaillé on peut jumeler Solution Manager avec SAP Analytics Cloud en utilisant des requêtes Bex.
A travers les EWA on retrouve certains graphiques générés automatiquement. Ceux-ci peuvent nous aider à analyser certains indicateurs. Les indicateurs restent statiques.
Pour analyser et identifier les objets les plus volumineux on peut utiliser :
La note OSS 1969700 permet de télécharger la collection de scripts SQL.
Le script SQL HANA_Tables_LargestTables_2.00.040+ permet d’identifier les tables les plus consommatrices en mémoire / disque.
Cet outil est amené avec les plug-in techniques ST-A/PI
Il permet d’avoir rapidement une vision structurée des tables les plus importantes par catégorie (PSA / Change Log / aDSO / ..). L’analyse est cependant limitée au schéma HANA de BW.
Un serveur BW peut grossir rapidement si on ne nettoie pas régulièrement les tables techniques.
Une fois les tables identifiées, la note OSS 2388483 – How-To: Data Management for Technical Tables permet d’implémenter les solutions pour purger le contenu des tables non nécessaire.
La mise en place d’une « process chain » dédiée à cette activité est souvent très utile.
La règle de base est de définir une période de rétention pour chaque cible de données.
Mais on peut aussi stocker les données sur différents types de supports (stockage chaud, tiède et froid).
6.1 Stockage chaud
Le stockage chaud est un stockage en mémoire HANA, c’est le plus performant mais aussi le plus onéreux.
–> Non active data
La note OSS 1767880 – Non-active data concept for BW on SAP HANA DB décrit le concept. Par défaut les tables de changelog et PSA et de DSO write optimised sont « flaguées » comme EARLY UNLOAD » afin de minimiser l’impact sur la mémoire HANA. On peut « flaguer » un DSO, mais de nouvelles technologies plus récentes sont décrites plus bas.
6.2 Stockage tiède
–> Extension node
L’extension node est un serveur HANA classique que l’on transforme en extension node. Cette caractéristique lui permet de stocker entre 2 et 4 fois plus de données qu’un nœud HANA classique.
Sur un serveur BW powered on HANA (7.40 ou 7.50), on utilise l’extension node comme solution de stockage tiède. Il peut aussi être déployé sur BW/4HANA mais une technologie plus récente existe.
2415279 – How-To: Configuring SAP HANA for the SAP HANA Extension Node
Nous vous conseillons d’être au moins en HANA 2.0 SPS04. Un extension node s’installe sur un scale-up (simple serveur) ou un scale-out (multiserveurs).
Le paramétrage de la mémoire tiède se fait au niveau des outils de modélisation des aDSO. Les outils type Data Distribution Optimisation (DDO) peuvent aussi être utilisés pour déplacer les tables/partitions de la mémoire chaude vers la mémoire tiède.
–> Native Storage Extension (NSE)
Cette fonctionnalité arrive avec HANA 2.0 SPS04. Elle permet de stocker une partie des tables en mémoire et une autre sur les disques du serveur HANA.
Attention : Aucune infrastructure supplémentaire n’est nécessaire.
2799997 – FAQ: SAP HANA Native Storage Extension (NSE)
Cette fonctionnalité est intégrée avec SAP BW4/HANA 2.0 SP04 et est activable via les outils de modélisation BW dans les aDSO.
On peut utiliser le NSE tuning advisor pour identifier les aDSO candidats.
6.3 Stockage froid
On peut aussi stocker les données vers une solution de stockage froid.
On utilise le Near Line Storage pour archiver une partie des données. Les 2 principaux supports sont Sybase IQ et Hadoop.
La mise en place est plus complexe que le stockage tiède.
Si vous êtes intéressés par une présentation, une démo, n’hésitez pas à nous écrire à l’adresse suivante : coe_sap_lead@aosis.net
Article écrit par Marc – Consultant Expert SAP BW
Pour suivre nos aventures sur LinkedIn :