Malentendus dans le contexte Hana

Le temps de démarrage jusqu'à la disponibilité du système SAP peut être plus long que 30 à 60 min pour charger toutes les données dans la mémoire principale : Oui, pour charger toutes les données dans la mémoire principale, il faut un certain temps, mais cela n'est pas différent pour une AnyDB.

Celle-ci a également besoin d'un certain temps pour remplir la mémoire tampon. Cela se produit généralement après le premier accès aux données et celles-ci y restent jusqu'à ce que l'algorithme LRU (Least Recently Used) entre en action et les supplante.

Hana charge la mémoire de ligne complète (Row Store) dans la RAM à chaque démarrage. Le système est ensuite immédiatement disponible. Brève description du processus de démarrage :

1. Ouverture des fichiers de données ;
2. Lecture des informations du dernier point de sauvegarde réussi (affectation des pages logiques aux pages physiques dans les fichiers de données et chargement de la liste pour les transactions ouvertes) ;
3. Chargement du Row Store (en fonction du sous-système d'E/S - environ cinq minutes pour 100 Go) ;
4. Rejouer les redologs ;
5. Retour en arrière des transactions qui n'ont pas été enregistrées avec succès (commit) ;
6. Écriture d'un point de sauvegarde ;
7. Chargement du Column Store marqué comme Preload
8. "lazy load" des tables restantes (chargement asynchrone des tables de colonnes qui étaient déjà chargées avant le redémarrage).

Le système de test est un BW on Hana sur IBM Power. La taille de la base de données est de 40 Go, Row Store a 6 Go et le processus de démarrage dure environ 60 secondes, le processus d'arrêt environ 75 secondes.

Lors de la deuxième exécution, une table de colonnes de 5 Go (REPORSRC) est ajoutée, ainsi que SQL pour le préchargement : alter table REPOSRC preload all. Une fois de plus, le processus de démarrage a duré environ 60 secondes et le processus d'arrêt environ 75 secondes.

Pourquoi le processus de démarrage n'a-t-il pas été nettement plus long alors qu'il y a plus de données à charger ?
Depuis SPS7, le processus de préchargement, ainsi que le rechargement des tables, ont lieu de manière asynchrone, juste après la fin du processus de démarrage de la BD Hana.

De cette manière, le système est immédiatement à nouveau disponible, sans attendre le chargement des tables orientées colonnes. Si l'on veut tester le temps nécessaire pour que toutes les tables soient chargées en RAM, on peut le faire avec le script loadAllTables.py (emplacement : /usr/sap/HDB/SYS/exe/hdb/python_support/) (en tant que sidadm) : python ./loadAllTables.py -user=Système -password= -address= -port=3xx15 -namespace=

Les statistiques ne sont plus nécessaires avec Hana ; il n'est plus nécessaire de planifier des cycles de collecte de statistiques : partiellement correct. Pour les tableaux orientés colonnes, l'affirmation est correcte. Il n'y a pas besoin d'exécutions collectives spéciales, car l'optimiseur connaît très rapidement la répartition grâce au dictionnaire.

Pour la mémoire de ligne, les statistiques sont générées automatiquement dès qu'elles sont nécessaires (à la volée). Elles ne doivent donc pas non plus être planifiées par le biais de collectes. Actuellement, il n'existe pas de documentation officielle sur la manière d'influencer ces statistiques (par ex. taille d'échantillon, exécution manuelle des statistiques, etc.)

Sauvegarde

Une restauration nécessite toujours des logs pour une récupération cohérente ! Faux. Les sauvegardes Hana sont basées sur une technologie de snapshot. Il s'agit donc d'un état complètement figé de la base de données, déterminé par la position du log au moment de l'exécution de la sauvegarde.

La sauvegarde est donc dans un état cohérent sans aucun log. Certes, les logs sont nécessaires pour une remontée en amont, par exemple Point in Time Recovery ou vers le dernier état possible avant une panne.

Catalogue de sauvegarde : Les informations du catalogue sont sauvegardées comme pour Oracle (fichier *.anf), qui sont absolument nécessaires pour la restauration. Le catalogue de sauvegarde est sauvegardé avec chaque sauvegarde de données et de logs !

Il ne s'agit pas d'un fichier lisible normalement. Même sans ce fichier original de la sauvegarde, une restauration peut avoir lieu (voir note SAP 1812057, Reconstruction du catalogue de sauvegarde avec hdbbackupdiag).

Elle se trouve dans l'emplacement de sauvegarde (pour la sauvegarde sur disque) ou dans le jeu de sauvegarde d'un fournisseur tiers et est reconnaissable à son nom. log_backup_0_0_0_0..

Le catalogue contient toutes les informations nécessaires à une restauration, comme par exemple quels logs sont nécessaires à quel moment ou quels fichiers appartiennent à quel jeu de sauvegarde.

Si les sauvegardes sont physiquement supprimées au niveau du disque, du VTL ou de la bande, le catalogue de sauvegarde conserve tout de même ces informations non valides. Actuellement, il n'y a pas d'automatisme livré qui nettoie cela.

Quelle est la taille de ce fichier catalogue dans le système ? On peut le tester soi-même ! On peut en avoir un aperçu avec Hana-Studio dans l'éditeur de sauvegarde, en affichant toutes les sauvegardes, y compris les logs.

Si ce fichier dépasse 20 Mo, il faut faire attention au housekeeping, car comme nous l'avons déjà mentionné, il est également sauvegardé à chaque sauvegarde. Cela signifie plus de 200 fois par jour ! 200 fois 20 MB fois 3 (car paysage à 3 systèmes), cela fait déjà 12.000 MB.

Le résultat du sizing report doit être doublé : Les nouveaux résultats de sizing des rapports SAP sont définitifs et ne doivent plus être doublés à nouveau, comme cela peut encore ressortir d'anciennes documentations.

On peut prendre comme exemple une solution BW scale-up. Cela signifie que les nœuds maître et esclave se trouvent sur un serveur. Selon les recommandations de SAP, une approche scale-out dans l'environnement BW se compose d'un nœud maître qui supporte la charge transactionnelle et d'au moins deux nœuds esclaves qui sont responsables du reporting.

Le sizing de la mémoire principale SAP se compose d'une partie statique et d'une partie dynamique. La partie statique est constituée d'index ainsi que de données de colonnes et de lignes, ce qui correspond à la somme des données utiles.

La partie dynamique est constituée de fichiers temporaires pour le reporting (OLAP BW Queries), la fusion delta ainsi que le tri et le regroupement, ce qui correspond en somme à la mémoire temporaire qui est libérée une fois l'action terminée.

Un exemple : le Row Store avec 53 Go fois 2 correspond à 106 Go ; Master-Column a 11 Go fois 2 correspond à 21 Go (arrondi) plus 67 Go fois 2 correspond à 135 Go (arrondi). Le total est de 156 Go. 50 Go de caches et de services sont nécessaires pour chaque serveur. Ce qui donne au final 312 Go au total.