S/4 Hana et SAP Adaptive Server Enterprise

Les entreprises qui utilisent jusqu'à présent pour leurs systèmes SAP des bases de données homogènes de fournisseurs tels qu'Oracle ou IBM risquent, lors de l'introduction de Hana ou de SAP Business Suite 4 Hana (S/4 Hana), de devoir payer deux fois les frais de licence et de maintenance pour leurs bases de données : d'une part pour Hana, d'autre part pour celles des autres fournisseurs.

La licence pour ASE est déjà incluse dans Hana Runtime Edition for Applications and SAP BW (REAB) - une base de données alternative pour les anciens systèmes restants est pour ainsi dire livrée gratuitement. En raison de sa stabilité, cette dernière est particulièrement appréciée dans l'environnement financier et est parfois utilisée depuis des décennies.

De plus, la feuille de route de SAP est claire pour elle - contrairement à MaxDB par exemple - et elle dispose d'une très bonne compression, ce qui entraîne un encombrement relativement faible. Un changement est donc évident. Mais lors de la migration vers ASE, il faut tenir compte de quelques écueils.

Pour et contre la migration vers ASE

Comme le montre notre expérience de plus de 100 migrations et de l'exploitation de plus de 70 systèmes clients, les coûts de la migration vers ASE sont généralement amortis assez rapidement en raison de la baisse durable des coûts de licence et de maintenance.

De plus, le modèle de licence de SAP ne pose aucun obstacle à la virtualisation de la base de données. D'autres avantages sont l'acquisition de l'application et de la base de données auprès d'un seul et même fournisseur ainsi que des avantages considérables en termes d'espace, par exemple par rapport à MaxDB qui, contrairement à ASE, ne supporte pas la compression des données.

De plus, il n'est pas nécessaire de procéder à des réorganisations coûteuses comme c'est le cas avec Oracle. L'administration intégrée se fait via le cockpit DBA courant, avec lequel la plupart des administrateurs sont familiarisés.

En revanche, des investissements obligatoires dans l'infrastructure informatique sont généralement nécessaires, car ASE nécessite beaucoup plus de ressources CPU du côté matériel. Comme le montre la pratique, une puissance de calcul supérieure de plusieurs centaines de pour cent est parfois nécessaire.

A cela s'ajoute le fait que la base de données ne peut pas vider son journal pendant la sauvegarde complète, de sorte qu'il faut accorder une attention particulière à la conception de la sauvegarde.

Toutefois, dans l'ensemble, les avantages de l'ASE l'emportent sur les inconvénients pour la plupart des entreprises, notamment en termes de coûts totaux permanents.

Conception : l'expérience est nécessaire

En raison des exigences matérielles spécifiques, il convient, malgré les instructions de migration bien documentées, de faire appel à des spécialistes expérimentés dès les premières phases de la planification et de s'en tenir strictement aux recommandations publiées par SAP, par exemple pour le dimensionnement des caches.

Une attention particulière devrait également être accordée à la conception du concept de sauvegarde. Pour les sauvegardes basées sur des snapshots, l'idéal est de se baser sur le "prepare database mode".

Il est préférable au "quiesce mode", car ce dernier ne fait que mettre la base de données en mode lecture seule. Pour permettre une récupération ponctuelle, il faut veiller, lors de la conception, à ce que les logs soient récupérables de manière autonome.

Comme la base de données ne peut pas vider ses logs pendant une sauvegarde complète, la durée de la sauvegarde est un facteur critique : tant que la sauvegarde est en cours, les modifications sont écrites dans les logs.

Si la sauvegarde dure trop longtemps, les logs débordent. Il est donc recommandé d'effectuer les sauvegardes pendant les périodes de faible charge et de dimensionner suffisamment la zone de log. En outre, il est possible de mettre en place des sauvegardes de logs contrôlées par le degré de remplissage.

Les paramètres de surveillance doivent également être strictement adaptés aux exigences spécifiques de SAP. Si ces conditions sont remplies, ASE permet des sauvegardes très rapides et, par expérience, sans problème.

Les points délicats de l'administration

Les administrateurs familiarisés avec SAP peuvent gérer et surveiller ASE via le Cockpit DBA habituel. Cependant, les changements très fréquents dans les notes SAP concernant les différents paramètres sont typiques de la base de données.

Il convient de souligner que près de 95 % des paramètres ASE peuvent être modifiés en ligne. Cela vaut même pour la mémoire de travail à utiliser (max_memory) et les ressources CPU (syb_default_pool). Cette propriété permet - en particulier en interaction avec la virtualisation - d'adapter les ressources de manière dynamique à l'augmentation des besoins.

Pour la réduction des ressources, un redémarrage est nécessaire, comme on le sait aussi dans la virtualisation - mais celui-ci peut généralement être placé dans une fenêtre de maintenance planifiée.

La fréquence des correctifs est également relativement élevée chez ASE, ce qui implique d'une part un certain effort lors de l'installation, mais a également pour conséquence que les corrections de bugs sont généralement assez rapides et que les nouvelles fonctionnalités sont rapidement disponibles.

En cas de panne des systèmes SAP ou du cockpit DBA, les outils d'administration habituels pour ASE font également défaut. Dans ce cas, la base de données ne peut plus être administrée que par iSQL.

Cela peut poser des difficultés, en particulier aux petits départements informatiques qui ne disposent pas de personnel ayant les compétences iSQL adéquates.

Conclusion

Dans l'ensemble, les entreprises disposent avec ASE d'une base de données qui - notamment en raison de la situation avantageuse en matière de licences en combinaison avec S/4 Hana - constitue une alternative judicieuse à l'exploitation parallèle de Hana et de bases de données de fournisseurs tiers.

Si quelques étapes sont respectées (voir encadré), l'expérience montre que rien ne s'oppose à une migration vers ASE. Peu importe que l'exploitation soit assurée par l'entreprise elle-même ou par un prestataire de services.

Migration ASE : approche classique

• Conseil en matière de licences et calcul du retour sur investissement
• Conseil en architecture : infrastructure et détermination des dépendances de versions
• Si nécessaire : mise à niveau vers au moins SAP Netwea- ver 7.0 (EHP 2), SAP ECC (EHP 5), SAP CRM (EHP 1) et SAP SRM (EHP 1).
• Migration technique
• En cas d'exploitation propre : formation des administrateurs - en particulier si aucune connaissance d'iSQL n'est disponible.