Volume de journaux plein. Le message apparaît dans le journal système à 14 h 22 un mercredi. À 14 h 23, la base de données HANA s’est arrêtée en urgence. Aucune alerte préalable, aucune dégradation progressive, aucun avertissement visible pour les utilisateurs avant la déconnexion des sessions. Le volume de journaux n’avait cessé de croître depuis trois semaines. Personne ne le surveillait.
Ce scénario spécifique illustre une catégorie de pannes HANA qui sont tout à fait évitables et d’une simplicité presque embarrassante à détecter. Le volume de journaux se remplit, la base de données s’arrête. Définissez une alerte à 70 % d’utilisation et vous ne verrez jamais ce mode de défaillance en production.
Mais le volume de journaux n’est qu’un élément parmi une longue liste de métriques où l’écart entre l’état actuel et l’incident de production est à la fois mesurable et exploitable. Cet article traite des signaux de surveillance spécifiques à HANA qui ont une véritable valeur prédictive : il ne s’agit pas de métriques génériques de performance de base de données rebaptisées pour HANA, mais de mesures qui reflètent la manière dont HANA gère réellement la mémoire, la persistance et la concurrence. Pour chacune d’entre elles, l’objectif est d’expliquer non seulement ce qu’il faut mesurer, mais aussi pourquoi cette mesure est importante et ce qu’elle vous apprend sur des conditions qui n’ont pas encore donné lieu à des incidents.ts.
En quoi la surveillance de HANA diffère-t-elle de la surveillance d’une base de données classique ?
La mémoire n’est pas une abstraction dans HANA
Dans une base de données traditionnelle à stockage en lignes, la mémoire constitue une couche de performance. Les données résident sur le disque. Les requêtes lisent les données du disque dans un cache tampon, et lorsque la mémoire est saturée, la base de données transfère les données sur le disque. Les performances diminuent progressivement. Le système reste opérationnel.
SAP HANA ne fonctionne pas de cette manière. Les données stockées en colonnes résident en mémoire. Elles sont chargées au démarrage et y restent. Lorsque la mémoire est saturée, HANA ne transfère pas les données sur le disque comme le ferait une base de données classique. Il utilise un mécanisme interne de déchargement pour évacuer de la mémoire les données des tables de colonnes peu utilisées, ce qui fonctionne dans des limites définies. Mais si la demande totale en mémoire provenant des requêtes actives, du stockage en lignes, du tas de code et du stockage en colonnes combinés dépasse la limite d’allocation configurée, HANA déclenche un événement de mémoire insuffisante et s’arrête.
Cette distinction modifie les exigences en matière de surveillance. Vous ne surveillez pas la mémoire pour optimiser les performances. Vous surveillez la mémoire pour éviter un arrêt brutal. Le seuil à partir duquel un indicateur devient critique est différent de celui de toute autre plateforme de base de données, et la relation entre la pression sur la mémoire et la stabilité du système est plus directe et moins tolérante.
Les indicateurs qui semblent normaux jusqu’à ce qu’ils ne le soient plus
Plusieurs indicateurs HANA se comportent de manière stable sur une large plage, puis changent brusquement de comportement à l’approche de leurs limites. L’utilisation du volume de journaux reste stable pendant des semaines, puis devient soudainement critique. Le retard dans la fusion des deltas augmente lentement pendant des mois sans impact visible sur les performances, puis les plans de requêtes commencent à se dégrader. Le tas de code augmente progressivement à chaque nouveau déploiement et ne diminue jamais, jusqu’à ce que le total cumulé franchisse un seuil qui pousse l’allocation totale de mémoire au-delà d’un plafond de sécurité.
Ce schéma, une dérive lente suivie d’une conséquence brutale, est ce qui fait que la surveillance de HANA porte spécifiquement sur la détection des tendances plutôt que sur la simple alerte de seuil. Un indicateur à 65 % qui est passé de 40 % en trois mois est une situation différente d’un indicateur qui est resté stable à 65 % pendant deux ans. Les deux affichent la même valeur au moment de la mesure. Un seul d’entre eux représente un problème imminent.
Toute configuration de surveillance de HANA qui se contente de comparer les valeurs actuelles à des seuils statiques est incomplète. La dimension de la tendance, c’est-à-dire la vitesse à laquelle un indicateur évolue et vers quelle limite, est souvent le signal le plus utile.
Indicateurs de mémoire : d’où proviennent la plupart des incidents HANA ?
La différence entre la mémoire utilisée, la mémoire allouée et la limite
HANA fournit plusieurs indicateurs de mémoire qu’il est facile de confondre. Comprendre ce que chacun d’entre eux représente permet de déterminer sur lequel vous devez configurer des alertes.
La limite d’allocation de mémoire correspond au plafond que HANA a été configuré pour utiliser. Elle est définie via le paramètre global_allocation_limit du fichier global.ini et est généralement fixée à 90-95 % de la RAM physique disponible afin de laisser une marge de manœuvre au système d’exploitation. Il s’agit d’une limite stricte. Si elle est dépassée, HANA s’arrête.
La mémoire allouée correspond à la part de cette limite que HANA a actuellement réclamée au système d’exploitation. Elle augmente à mesure que HANA charge des données et ne diminue que partiellement lorsque les données sont déchargées. Le fait que la mémoire allouée reste proche de la limite après le déchargement des données indique une accumulation de fragmentation de la mémoire.
La mémoire utilisée correspond à la partie de la mémoire allouée qui contient activement des données ou qui est utilisée par des processus en cours d’exécution. C’est cette mémoire qui fluctue en fonction de l’activité des requêtes et de la charge des connexions. Un pic de mémoire utilisée lors d’une requête analytique volumineuse est normal. Une mémoire utilisée qui ne revient pas à son niveau de base une fois la requête terminée indique une fuite ou un schéma d’accumulation qui mérite d’être examiné.
La métrique sur laquelle baser l’alerte est la mémoire utilisée en pourcentage de la limite d’allocation, et non en pourcentage de la RAM physique. La limite d’allocation correspond au plafond opérationnel réel. Déclencher une alerte à 85 %. Escalader à 90 %. Au-delà de 90 %, une seule requête volumineuse non optimisée peut faire dépasser la limite au système.
| Attention : la vue M_MEMORY_OVERVIEW offre une vue d’ensemble de la mémoire, mais ne détaille pas la consommation par composant. Pour analyser les causes profondes d’un problème de pression sur la mémoire, les vues M_HEAP_MEMORY (tas de code), M_RS_MEMORY (stockage en lignes) et M_CS_UNLOADS (candidats au déchargement du stockage en colonnes) sont indispensables pour identifier les éléments qui occupent de l’espace. |
Stockage en colonnes et stockage en lignes : les surveiller séparément
La mémoire du stockage en colonnes est dynamique. HANA charge et décharge les données des tables en colonnes en fonction des modèles d’accès et de la mémoire disponible, grâce au mécanisme de déchargement automatique. Lorsque la pression sur la mémoire augmente, HANA évacue automatiquement les partitions de stockage en colonnes peu utilisées. Il s’agit d’un comportement normal qui n’indique pas de problème. Le problème survient lorsque l’ensemble de données de travail, c’est-à-dire les données activement requises par les requêtes de production, est plus volumineux que la mémoire disponible, ce qui oblige HANA à charger et décharger les mêmes pages à plusieurs reprises. Cela se traduit par une augmentation des E/S disque sur le volume de données et une latence accrue des requêtes sur certaines tables, et non par un message d’erreur.
La mémoire du magasin de lignes se comporte différemment et fait l’objet d’une surveillance pour une raison distincte. Les tables du magasin de lignes, qui comprennent les tables de catalogue internes de HANA et toutes les tables d’application configurées avec le stockage ROW, ne bénéficient pas du mécanisme de déchargement automatique. La mémoire consommée par les données du magasin de lignes reste allouée même après la suppression des lignes. L’espace est marqué comme libre en interne, mais n’est pas restitué au système. Au fil du temps, dans les environnements présentant un taux de renouvellement élevé des tables de stockage en lignes, la taille de celles-ci augmente jusqu’à ce qu’une réorganisation explicite soit effectuée via HANA Studio ou la commande SQL HANA ALTER TABLE … RECLAIM DATA SPACE.
Une mémoire de stockage en lignes qui augmente régulièrement dans un système où les volumes de données sont stables indique que la réorganisation du stockage en lignes n’a pas été effectuée depuis longtemps. Si ce problème n’est pas traité, il contribue à une pression globale sur la mémoire sans augmentation correspondante des données réelles. La surveillance de l’espace de stockage en lignes utilisé par rapport à l’espace alloué, et la génération d’alertes lorsque l’écart entre les deux s’élargit, permettent d’identifier cette situation avant qu’elle ne devienne un problème de marge de mémoire.
Code heap : la métrique qui s’accumule en silence
Le code heap est la mémoire utilisée par HANA pour les objets de code compilés, notamment les procédures stockées ABAP, les vues de calcul scriptées et le code d’application XS. Il augmente à mesure que de nouveaux objets sont chargés ou recompilés et n’est pas libéré automatiquement. Le code heap n’est pas soumis au mécanisme de déchargement du magasin de colonnes. Il est pris en compte dans la limite d’allocation totale.
Dans les systèmes en développement actif où les procédures stockées ou les vues de calcul sont fréquemment déployées et mises à jour, le tas de code augmente à chaque cycle de déploiement. Les anciennes versions compilées ne sont pas immédiatement purgées. Un système fonctionnant depuis deux ou trois ans avec un développement régulier de procédures stockées ABAP peut accumuler plusieurs gigaoctets de tas de code qui ne servent aucun objectif actif.
Un tas de code supérieur à 8-10 Go dans un système de production mérite d’être examiné. La solution consiste généralement à redémarrer le service sur le serveur d’index, ce qui libère les objets compilés qui ne sont plus utilisés. Dans un système bien entretenu, le tas de code doit être examiné dans le cadre de contrôles de santé réguliers, en particulier après le déploiement de versions majeures.
Indicateurs de stockage : ceux qui provoquent des arrêts brutaux
Volume de journaux : l’indicateur qui provoque la fermeture des bases de données sans avertissement
SAP HANA utilise un journal de reprise pour garantir la durabilité des transactions. Chaque transaction validée est enregistrée dans le volume de journaux avant que l’accusé de réception ne soit envoyé à l’application. Ce journal doit être sauvegardé régulièrement sur un support de sauvegarde, après quoi les segments sauvegardés peuvent être écrasés. Si les sauvegardes du journal cessent de s’exécuter, que ce soit en raison d’un problème de configuration, d’un problème lié au support de sauvegarde ou d’une désactivation délibérée, le volume de journaux se remplit continuellement sans mécanisme de libération.
Lorsque le volume de journal atteint 100 % d’utilisation, HANA effectue un arrêt d’urgence immédiat. Il ne s’agit pas d’un arrêt progressif. Ni d’une suspension des écritures. Mais d’un arrêt. Les fichiers journaux ne peuvent pas être étendus. Aucune nouvelle transaction ne peut être validée. Le système est hors ligne jusqu’à ce que de l’espace soit libéré dans le journal, ce qui nécessite soit une restauration à partir d’une sauvegarde, soit la suppression manuelle de segments de journal, aucune de ces deux options ne devant constituer la première réponse dans un environnement de production.
Le seuil d’alerte pour l’utilisation du volume de journaux est de 70 %. Pas 80 %, ni 90 %. À 70 %, vous disposez de temps pour vérifier si les sauvegardes des journaux s’exécutent correctement, si le support de sauvegarde dispose d’un espace suffisant et si l’intervalle de sauvegarde des journaux est adapté au volume actuel de transactions. À 90 %, vous êtes en mode correction. Au-delà de 95 %, vous êtes en mode incident.
| En pratique : la fréquence des sauvegardes du journal détermine la vitesse à laquelle le volume de journal se remplit dans des conditions normales de charge d’écriture. Un système présentant un volume de transactions élevé et dont les sauvegardes du journal sont configurées toutes les 15 minutes verra son volume de journal se remplir beaucoup plus lentement qu’un système où les sauvegardes du journal s’effectuent toutes les heures. Si l’utilisation du volume de journal reste constamment élevée alors même que les sauvegardes s’exécutent correctement, il peut s’avérer nécessaire de réduire l’intervalle entre les sauvegardes ou d’augmenter la taille du volume de journal. |
Croissance du volume de données et comportement des points de sauvegarde
Le volume de données HANA contient les données persistantes du magasin de colonnes, le magasin de lignes et les structures d’annulation/rétablissement nécessaires à la reprise après sinistre. Son taux de croissance en conditions normales d’exploitation est prévisible et lié aux variations du volume de données dans la base de données. Une accélération soudaine de la croissance du volume de données indique soit un chargement massif de données, soit une modification de la configuration d’archivage, soit un processus incontrôlé créant d’importantes structures temporaires qui ne sont pas nettoyées.
Les points de sauvegarde constituent le mécanisme par lequel HANA transfère périodiquement les pages modifiées de la mémoire vers le volume de données. Ils s’exécutent automatiquement à des intervalles configurables (par défaut : 5 minutes) et lors d’événements spécifiques tels que les sauvegardes de journaux. La durée d’un point de sauvegarde est une métrique que la plupart des configurations de surveillance ne suivent pas, mais qui présente une valeur prédictive significative.
Un point de sauvegarde qui s’exécute normalement en 15 secondes et commence à prendre 3 minutes vous indique quelque chose : soit le delta entre le dernier point de sauvegarde et le point actuel est beaucoup plus important que la normale (ce qui indique un volume d’écriture élevé ou une opération en masse importante), soit le chemin d’E/S vers le volume de données est saturé. Ces deux conditions ont tendance à précéder des problèmes de performances plus généraux. Une durée de point de sauvegarde prolongée est souvent visible dans la surveillance HANA avant que les utilisateurs ne signalent un ralentissement, ce qui en fait un indicateur précoce utile de la dégradation liée aux E/S.
Surveillance des sauvegardes : l’indicateur qui compte précisément au moment où l’on souhaite le moins le découvrir
L’importance de la surveillance des sauvegardes apparaît clairement en cas de panne de la base de données, lorsque le délai de restauration dépend entièrement de l’ancienneté de la dernière sauvegarde réussie. Découvrir à ce moment-là que la dernière sauvegarde réussie remonte à quatre jours, parce que la tâche de sauvegarde échouait silencieusement depuis lors, est une situation que la surveillance des sauvegardes est justement là pour éviter.
Deux indicateurs de sauvegarde justifient une surveillance continue. L’ancienneté de la dernière sauvegarde complète réussie ne devrait jamais dépasser 24 heures dans un environnement de production. L’intégrité de la chaîne de sauvegardes des journaux doit être vérifiée en permanence : une lacune dans la séquence de sauvegardes des journaux signifie qu’une restauration à un instant donné postérieur à cette lacune est impossible, même si les sauvegardes de journaux suivantes sont présentes et valides.
Ces deux indicateurs sont disponibles dans la vue M_BACKUP_CATALOG. Il est facile de configurer des alertes pour chacun d’eux. Et pourtant, ils sont systématiquement sous-surveillés, car les échecs de sauvegarde ont tendance à être traités comme des problèmes d’infrastructure plutôt que comme des problèmes de disponibilité de la base de données. Une sauvegarde qui a échoué n’affecte pas les performances actuelles du système. Les conséquences n’apparaissent qu’après l’échec suivant, au moment de la restauration.
Indicateurs de performance : SQL, fusion des deltas et contention sur les verrous
Les requêtes de longue durée et ce qu’elles révèlent au-delà de leur propre exécution
Une instruction SQL coûteuse dans HANA ne se contente pas de consommer des ressources pendant son exécution. Une requête qui effectue un balayage complet d’un magasin de colonnes sur une table de plusieurs milliards de lignes tout en conservant des verrous partagés bloque l’accès parallèle à ces structures. Elle retarde les opérations de fusion delta qui doivent traiter les mêmes données. Elle peut déclencher le déchargement automatique d’autres partitions du magasin de colonnes pour libérer de la mémoire, ce qui génère des opérations d’E/S lorsque ces partitions sont rechargées pour la requête suivante qui en a besoin.
La vue M_EXPENSIVE_STATEMENTS enregistre les instructions qui ont dépassé une durée ou un seuil de ressources configurable. Par défaut, ce seuil est trop élevé pour la plupart des environnements de production pour détecter les requêtes qui comptent. Définir le seuil des instructions coûteuses à 30 secondes dans les environnements OLTP et à 5 minutes dans les environnements analytiques permet d’obtenir un enregistrement des instructions méritant d’être examinées, sans la charge liée à la journalisation de chaque requête.
Une alerte de surveillance qui se déclenche lorsqu’une instruction s’exécute depuis plus de 5 minutes en production donne à l’équipe opérationnelle le temps de vérifier si l’instruction est attendue (un traitement par lots volumineux) ou inattendue (un utilisateur exécutant accidentellement un rapport non optimisé sur un système de production). Cette distinction détermine la réponse à apporter, mais dans tous les cas, l’équipe doit en être informée pendant que l’instruction est encore en cours d’exécution.
Retard dans la fusion des deltas : une dégradation progressive que personne ne remarque à temps
Le magasin de colonnes de HANA utilise un magasin de deltas optimisé pour l’écriture afin de stocker les nouvelles lignes avant de les fusionner dans le magasin principal compressé. Le processus de fusion des deltas s’exécute automatiquement en fonction de déclencheurs configurables : lorsque la taille des deltas atteint un seuil, selon un calendrier défini ou manuellement. Les lectures sur les tables du magasin de colonnes interrogent à la fois le magasin principal et le magasin de deltas, ce dernier étant moins optimisé pour les lectures que le magasin principal.
Lorsque les fusions delta prennent du retard, que ce soit parce que les opérations de fusion sont annulées par des demandes de ressources concurrentes, parce que le seuil de fusion est fixé trop haut ou parce que la configuration de la fusion automatique a été modifiée par inadvertance, le magasin delta grossit. Les performances des requêtes sur les tables concernées se dégradent progressivement à mesure que le magasin principal optimisé pour la lecture diminue en proportion de la taille totale de la table. Il n’y a pas d’erreur. Aucune alerte ne se déclenche. Les plans d’exécution s’aggravent légèrement. Les utilisateurs perçoivent le système comme lent, sans pouvoir l’expliquer précisément.
La surveillance des fusions delta en attente et du nombre d’échecs de fusion via M_DELTA_MERGE_STATISTICS permet de détecter cette dérive avant qu’elle n’atteigne le point où la dégradation du plan de requête devient visible dans les métriques de temps de réponse. Un nombre d’échecs de fusion delta en hausse, ou une file d’attente de fusions en attente constamment supérieure à 50 à l’échelle du système, justifie une enquête pour déterminer ce qui bloque ou retarde le processus de fusion.
Attentes de verrouillage et transactions bloquées
L’architecture de contrôle de concurrence multiversion de HANA est conçue pour minimiser les conflits de verrouillage par rapport aux bases de données traditionnelles à stockage par lignes. Les lectures ne bloquent généralement pas les écritures, et les écritures ne bloquent pas les lectures. Les conflits de verrouillage qui surviennent dans HANA ont tendance à se concentrer sur des schémas spécifiques : modifications simultanées d’une même ligne dans une charge de travail OLTP, verrous au niveau de la table détenus par des opérations DDL, ou verrous d’enregistrements détenus par des transactions de longue durée qui n’ont pas été validées.
La vue M_BLOCKED_TRANSACTIONS affiche les transactions actuellement en attente de verrous. Un blocage de verrou qui se résout en moins d’une seconde est normal. Un blocage de verrou qui persiste pendant 30 secondes ou plus dans un système OLTP de production indique un schéma de blocage qui s’aggravera en cas d’augmentation de la charge simultanée. La vue affiche à la fois la transaction bloquée et la transaction bloquante, ce qui permet à l’équipe opérationnelle de décider s’il faut attendre que la transaction bloquante se termine ou intervenir.
Les attentes de verrouillage persistantes en production sont presque toujours le symptôme d’un problème plus large : une transaction qui a été lancée mais non validée (transaction ouverte laissée par une erreur d’application), un traitement par lots qui maintient des verrous sur de grands ensembles d’enregistrements sans validations intermédiaires, ou une conception de table qui crée des points chauds de mise à jour. La surveillance de la fréquence et de la durée des attentes de verrouillage permet de mettre en évidence ces schémas avant qu’ils n’entraînent des erreurs visibles par l’utilisateur.
État de la réplication et santé du service
Le décalage de réplication du système comme signal d’alerte précoce
Dans les environnements utilisant la réplication système SAP HANA pour assurer la haute disponibilité, le décalage de réplication est un indicateur crucial tant sur le plan opérationnel qu’architectural. Dans des conditions normales, avec le mode de réplication SYNC ou SYNCMEM, le décalage devrait être proche de zéro. Le serveur secondaire reçoit et applique en continu les entrées de journal provenant du serveur principal. Tout décalage persistant indique que le serveur secondaire prend du retard.
Le décalage de réplication peut s’accumuler pour plusieurs raisons : saturation de la bande passante réseau entre le serveur principal et le serveur secondaire, goulot d’étranglement d’E/S sur le stockage du serveur secondaire, ou pic de volume d’écriture sur le serveur principal dépassant temporairement la capacité de traitement du serveur secondaire. Chaque cause nécessite une solution différente.
L’intérêt de la surveillance du décalage de réplication va au-delà de la simple vérification de l’intégrité du serveur secondaire. Un secondaire qui accuse systématiquement un retard de 5 à 10 secondes par rapport au primaire en charge normale sera encore plus en retard lors d’un événement à forte écriture, ce qui correspond précisément au moment où un basculement est le plus susceptible de se produire en raison de l’épuisement des ressources sur le primaire. Le décalage au moment du basculement correspond au RPO pratique pour les configurations SYNCMEM et ASYNC. La surveillance de la tendance du décalage permet d’alerter à l’avance que le RPO de facto s’écarte de l’hypothèse de conception.
La disponibilité des services au-delà de la simple question « HANA fonctionne-t-il ? »
Un système HANA qui répond à un test de connectivité n’est pas nécessairement un système en parfait état de fonctionnement. HANA est composé de plusieurs services qui s’exécutent en tant que processus distincts : le serveur d’index (stockage en colonnes et traitement SQL), le serveur de noms (topologie et routage), le serveur de statistiques (surveillance et alertes en interne), le serveur de prétraitement (recherche textuelle) et, dans certaines configurations, le moteur XS pour les applications HTTP.
Chacun de ces services peut tomber en panne ou voir ses performances se dégrader indépendamment, alors que le système dans son ensemble reste accessible. Un serveur d’index qui a redémarré à la suite d’un événement lié à la mémoire indiquera que le système est disponible lors d’un test ping, alors que les données du magasin de colonnes sont en cours de rechargement depuis le disque, un processus qui peut prendre de quelques minutes à plusieurs heures selon le volume de données concerné. Pendant ce rechargement, les performances des requêtes peuvent être fortement dégradées sans qu’aucune alerte de disponibilité ne se déclenche.
La surveillance au niveau des services via M_SERVICES suit individuellement l’état, la disponibilité et la consommation de mémoire de chaque service HANA. Le déclenchement d’alertes lors des redémarrages du serveur d’index, même lorsque le service se rétablit automatiquement, permet de consigner des événements d’instabilité qui seraient autrement invisibles. Deux ou trois redémarrages du serveur d’index par mois, chacun se résolvant automatiquement, constituent un schéma qui justifie une enquête avant qu’il ne provoque un arrêt irrémédiable.
Référence des indicateurs de surveillance HANA
Le tableau ci-dessous rassemble les indicateurs clés abordés dans cet article, avec les seuils d’alerte recommandés, la vue système HANA qui fournit les données, ainsi que la raison opérationnelle pour laquelle chaque indicateur est important. Les seuils constituent des points de départ. Les valeurs appropriées pour votre environnement dépendent du profil de votre système, du volume de données et des objectifs de votre SLA.
| Métrique | Seuil d’alerte | Vue / source | Pourquoi c’est important |
| Mémoire utilisée / limite allouée | > 85% | M_MEMORY_OVERVIEW | Indicateur principal de risque d’OOM. Un niveau supérieur à 90 % pendant une période prolongée signifie qu’une requête sans restriction peut déclencher un arrêt d’urgence. |
| Mémoire utilisée par le stockage en lignes | 70 % de la taille du magasin de lignes | M_RS_MEMORY | Le stockage par lignes ne libère pas automatiquement la mémoire lors de la suppression d’une ligne. L’augmentation de la taille de la mémoire est permanente jusqu’à ce qu’une réorganisation soit explicitement effectuée. |
| Heap de code utilisé | > 8 GB (absolu) | M_HEAP_MEMORY | L’augmentation de la taille du tas de code est le signe de fuites de mémoire dans les procédures stockées ABAP ou les applications XS. Elle ne diminue pas sans redémarrage du service. |
| Volume de journaux utilisé | > 70% | M_DISK_USAGE | L’épuisement de l’espace disque réservé aux journaux entraîne un arrêt complet de la base de données sans arrêt progressif. Aucun avertissement visible par l’utilisateur ne précède cet arrêt. |
| Volume de données utilisé | > 80% | M_DISK_USAGE | Permet de suivre l’évolution globale du volume de données stockées. En combinant ces données avec le taux de croissance mensuel, il est possible de prévoir à quel moment une extension de capacité sera nécessaire. |
| Dernière sauvegarde de données réussie | > 24 heures | M_BACKUP_CATALOG | Un système HANA dépourvu de sauvegarde récente présente un RPO indéterminé. En l’absence de surveillance active, les échecs de sauvegarde passent souvent inaperçus. |
| Intervalle entre les sauvegardes des journaux | Tout écart > intervalle de sauvegarde | M_BACKUP_CATALOG | Les lacunes dans la chaîne de sauvegardes des journaux compromettent la restauration à un instant donné. Chaque lacune représente un risque potentiel de perte de données. |
| Les requêtes qui s’exécutent longtemps | Activité > 5 minutes (prod) | M_EXPENSIVE_STATEMENTS | Une seule instruction coûteuse peut monopoliser les E/S, bloquer d’autres requêtes et provoquer une cascade de conditions d’attente dans tout le système. |
| Fusions delta en attente | > 50 en attente sur l’ensemble des tables | M_DELTA_MERGE_STATISTICS | Le retard accumulé par Delta entraîne une dégradation progressive des performances de lecture. Lorsque le nombre de lignes est élevé, les plans de requête optent pour des chemins sous-optimaux sans générer d’erreur. |
| Nombre d’attentes de verrou | Tout blocage de plus de 30 secondes | M_BLOCKED_TRANSACTIONS | Les attentes de verrouillage persistantes dans un environnement OLTP de production indiquent des phénomènes de contention qui s’aggravent en période de pointe. |
| Blocage de thread / threads coincés | Tout thread dont le statut est « Attente du sémaphore » depuis plus de 5 minutes | M_SERVICE_THREADS | Les threads bloqués mobilisent des ressources sans produire de résultat. Lorsqu’ils sont trop nombreux, ils empêchent les requêtes légitimes d’aboutir. |
| Décalage de réplication du système (SYNCMEM/ASYNC) | > 10 secondes en continu | M_SERVICE_REPLICATION | Un décalage de réplication lors d’une défaillance du serveur principal SYNC/SYNCMEM signifie que le serveur secondaire est en retard. La précision de la prise de relais dépend du décalage au moment de la défaillance. |
| État de la connexion secondaire | Toute déconnexion | M_SERVICE_REPLICATION | Un serveur secondaire déconnecté n’assure aucune couverture HA. La reconnexion peut nécessiter une intervention manuelle selon la raison de la déconnexion. |
| Durée du point de sauvegarde | > 5 minutes | M_SAVEPOINTS | Des points de sauvegarde prolongés indiquent une saturation des E/S ou des conflits de verrouillage au niveau de la couche de persistance. Ils annoncent des problèmes de performances plus généraux. |
| Augmentation de la taille d’écriture des points de sauvegarde | Tendance mois par mois | M_SAVEPOINTS | L’augmentation de la taille d’écriture des points de sauvegarde indique que l’ensemble de données de travail s’étend. Cet élément est pertinent pour la planification des capacités. |
Établir une base de référence pour la surveillance de HANA : à quoi ressemble une bonne couverture ?
Les indicateurs présentés dans le tableau ci-dessus ne doivent pas tous être mis en œuvre avec la même urgence. Dans les environnements ne disposant actuellement d’aucune surveillance HANA ou dont la surveillance se limite à la disponibilité, il convient de donner la priorité à la limite d’allocation de mémoire (le point de blocage le plus critique), à l’utilisation du volume des journaux (la cause la plus fréquente d’interruptions imprévues) et à l’ancienneté de la dernière sauvegarde réussie (l’indicateur qui détermine la capacité de reprise). Ces trois indicateurs, associés à des alertes correctement configurées et acheminées, permettent d’éliminer la catégorie la plus courante d’incidents HANA.
À partir de cette base de référence, la surveillance de la fusion des deltas et la durée des points de sauvegarde ajoutent une visibilité sur les tendances qui permet de détecter une dégradation progressive des performances avant qu’elle ne devienne perceptible pour l’utilisateur. La surveillance des instructions s’exécutant sur une longue durée ajoute un signal au niveau de la requête qui explique pourquoi la pression sur la mémoire atteint des pics à des moments précis de la journée.
L’ensemble complet des indicateurs figurant dans le tableau de référence couvre de manière exhaustive un environnement HANA de production, mais sa mise en œuvre correcte nécessite plusieurs semaines de travail de configuration et de réglage des seuils. L’intérêt de ce travail est proportionnel au coût des incidents qu’il permet d’éviter. Pour un système S/4HANA de production gérant des opérations financières, la paie ou l’exécution logistique, la réponse à la question de savoir si ce travail en vaut la peine n’est pas compliquée.
Deux remarques pratiques concernant la mise en œuvre. Premièrement, plusieurs de ces indicateurs nécessitent l’accès à des vues du système HANA qui requièrent des privilèges HANA spécifiques, distincts de l’autorisation standard de l’application SAP. La configuration des utilisateurs de surveillance est une condition préalable souvent sous-estimée dans les calendriers de projet. Deuxièmement, les valeurs de référence pour des indicateurs tels que la durée des points de sauvegarde et la fréquence de fusion des deltas nécessitent au moins deux à quatre semaines de collecte de données avant que les seuils d’alerte ne soient significatifs. Commencer la surveillance avant la mise en production, même en environnement de test, permet d’obtenir des données de référence qui rendent les alertes de production immédiatement utiles, plutôt que de nécessiter une période de recalibrage après le lancement.
La valeur prédictive réside dans la tendance, et non dans le seuil
Les performances de HANA ne s’effondrent généralement pas du jour au lendemain. La dégradation s’accumule. Le tas de code s’épaissit au fil des cycles de déploiement. Les fusions delta prennent progressivement du retard. Le volume des journaux augmente à mesure que les fenêtres de sauvegarde s’allongent. L’espace de stockage des lignes se remplit à mesure que la réorganisation est reléguée au second plan. Chaque indicateur, surveillé individuellement, semble gérable jusqu’à ce qu’il atteigne son point critique. Surveillés ensemble sous forme de tendance, ils brossent un tableau cohérent d’un système se dirigeant vers une limite.
Les configurations de surveillance qui détectent les problèmes HANA avant que les utilisateurs ne les signalent partagent une caractéristique : elles traitent la tendance comme un signal de premier ordre au même titre que l’état actuel. Un indicateur à 70 % qui est passé de 40 % en six semaines mérite la même attention qu’un indicateur à 85 % qui est stable depuis des mois. L’indicateur stable correspond à une condition connue. Celui qui suit une tendance correspond à un événement imminent.
Les métriques abordées dans cet article ne nécessitent pas d’instrumentation au-delà de ce que HANA expose déjà via ses vues système. Les données sont là. La question est de savoir si la couche de surveillance est configurée pour les lire, les corréler et les transmettre aux bonnes personnes à un moment où l’action est encore préventive plutôt que réactive.
Redpeaks se connecte à SAP HANA via des API SQL natives, sans agents ni transports, et collecte en temps réel des indicateurs relatifs à la mémoire, au stockage, aux performances et à la réplication. Les alertes sont basées sur des valeurs de référence, et non sur des seuils par défaut.
