MAJ du 17/10/2013 export/import
Voilà un bout de temps que je n'ai rien posté à cause du boulot et surtout à cause du manque de motivation à parler d'un sujet.
Entre les migrations IFS Applications, les installations et développement sur SAP B1, il y a SAP HANA qui est apparu en début d'année dans ma sphère de compétence.
Je ne vais pas expliquer ce qu'est SAP HANA, SAP le fait bien, d'autres aussi mais je vais plutôt tenter de décrire les points sympa de la technologie par rapport à SQL Server, Oracle ainsi que les soucis de jeunesse.
Mais SAP HANA est un serveur, une base de données et un outil de BI.
1. Le matériel
Un serveur SAP HANA est une machine certifiée par SAP qui est vendue par certains fabriquants ( Fujitsu, IBM, HP, ...).
Ces machines sont conçues pour garantir des performances ce qui explique leur prix.
2. La base de données SAP HANA
La base de données se compose de différents services sous Linux. Son fonctionnement relationnel se base sur Oracle avec une gestion de fichiers de log identique. Contrairement aux SGBDR existants, pas,besoin d'index ou de temp car l'accès aux données en mémoire est immédiat et les calculs sont immédiats.
2.1 installation
Ayant fait l'expérience d'une installation from scratch d'un serveur HANA au final, c'est relativement simple compte tenu de la puissance de l'outil.
Je m'explique. Jusqu'à présent le plus gros serveur de base de données ( enfin les 2 ) sur lequel j'avais bossé étaient un RAC Oracle 10GR2 de 2 noeuds sous Windows avec 2x 28 Go de RAM et un SAN HP EVA.
Le serveur HANA que l'on possède contient 96 Go de RAM, 2 To de disque et 20 coeurs. Celui que j'ai installé pour un client n'avait que 64 Go de RAM.
Ces configurations sont prévues pour SAP Business One. Par rapport aux machines pour SAP R3, ce sont des joujoux car ils ont accès à des clusters de machine ayant jusqu'à 1 To de mémoire.
Le serveur du client ayant été reçu vierge de toute configuration. J'ai du donc :
- créer le RAID et les partitions
- installer Suse 10 Enterprise
- créer les points de montage
- vérifier les pré requis pour SAP HANA ( comme Oracle sous Linux, on installe les packages manquants )
Arrive le moment où on peut réellement se planter : l'installation de SAP HANA. Dans les quelques informations à saisir ( 5 ou 6 ), les fichiers du runtime et de la base doivent être mis où il y a le plus d'espace disque : les 2 To servent à ça. A ce propos, le master des Fujistsu n'est pas bon.
Une fois les quelques informations saisies, 10 minutes plus tard, SAP HANA tourne.
Reste l'installation du client et du studio pour l'administration / modélisation de la BI / développement HTML5 et notre environnement HANA est prêt.
2.2 Administration de la base de données
Administrer un serveur SAP HANA c'est aussi simple que Sql Server d'un point de vue base de données. L'administration se fait depuis le Hana Studio qui permet de voir l'état des services sous Linux, les alertes, les logs des backup ( depuis le SP 06), ...
Jusque là, pas besoin d'aller sous Linux.
Mais il est préconisé par SAP de planifier un script de backup sous Linux avec cron ( voir la note SAP
1651055).
2.3 Limitations / Problèmes
SAP HANA est un produit jeune. Du coup, d'un point de vue sauvegarde, toutes les bases sont sauvegardées ensemble. Il n'est pas possible de sauvegarder une base uniquement.
La seule méthode est l'export / import. A partir du SP06 la syntaxe suivante permet de créer un nouveau schéma à partir d'un export :
export "SBODEMOGB"."*" as binary into '/home/SBODEMOGB' with replace threads 10;
import "SBODEMOGB "."*" as binary from '/home/SBODEMOGB' with replace threads 10 rename schema "SBODEMOGB" to "SBODEMOGB_NEW";
L'autre problème que j'ai rencontré conçerne le SP 05 rev 53. La sauvegarde ne se terminait plus car le service statisticsserver ne se sauvegardait plus. En upgradant en SP 6 rev 60, le problème est résolu.
