Oracle Database In-memory dans l'utilisation SAP

Un regard attentif montre qu'il existe des différences considérables dans les concepts en mémoire de SAP et d'Oracle. Cela commence déjà par la dénomination officielle :

Alors que Hana est désignée comme "In-memory Database", Oracle parle de "Database In-memory". Quelles sont les possibilités offertes par la "Database In-memory" d'Oracle, fraîchement certifiée SAP, pour une utilisation avec SAP ?

Le point commun fondamental, car concept théorique de base pour le stockage d'une base de données dans la mémoire physique principale (RAM), est le stockage des données orienté vers les colonnes.

Cela explique pourquoi In-memory n'est devenu si populaire que récemment. Jusqu'à récemment, on renonçait à l'in-memory dans presque toutes les bases de données relationnelles en raison des inconvénients considérables de l'orientation en colonnes dans l'environnement OLTP.

Ce n'est que la nécessité d'évaluer rapidement de grandes quantités de données, la chute des prix de la RAM ainsi que la disponibilité de processeurs multicœurs qui ont rendu ce concept intéressant.

Hana charge la base de données complète dans la mémoire principale, c'est pourquoi la solution est également appelée base de données en mémoire. Ce concept nécessite un matériel spécifique, énormément de RAM, et en cas de crash du serveur, il faut prévoir beaucoup de temps pour restaurer la base de données.

Pour une utilisation avec Hana, une base de données doit être entièrement migrée. Le retour n'est possible qu'à grands frais. La taille de la mémoire principale nécessaire ne se mesure d'ailleurs pas uniquement en fonction de l'espace requis par la base de données. En effet, les fonctionnalités internes à Hana (processus de fusion, zone Temp) nécessitent 50 pour cent de RAM supplémentaires.

RAM pas nouveau pour la BD Oracle

La base de données Oracle n'a jamais été uniquement "basée sur disque". Afin d'optimiser les performances, elle utilisait également dans les versions précédentes des structures de mémoire telles que le buffer-cache, le row-cache et le result-cache.

Avec la base de données Oracle dans sa version 12.1.0.2, l'option In-memory a en outre été introduite. Oracle Database In-memory est ainsi, comme Hana, particulièrement adaptée à l'analyse ou à l'agrégation plus rapide de grandes quantités de données.

Oracle n'appelle pas sa base de données "in-memory", mais place délibérément le terme "in-memory" à la fin du nom. Il s'agit de montrer clairement qu'Oracle est le seul fabricant de bases de données à conserver la technologie existante sans la modifier et à l'enrichir d'une composante en mémoire.

Le principe actuel de la mise en mémoire tampon orientée ligne dans la mémoire principale et de son stockage sur disque ou mémoire flash est alors entièrement conservé. Le In-memory Column Store est installé dans une zone de RAM supplémentaire.

Il est possible d'y stocker des tables complètes, des colonnes individuelles ou des partitions individuelles au format colonne. Oracle réunit ainsi les avantages des bases de données orientées lignes et colonnes dans un seul produit et crée - contrairement à SAP - une "base de données hybride".

Celle-ci convient comme d'habitude et sans modification pour les applications OLTP et offre malgré tout, grâce à Column Store, des gains de performance significatifs pour les requêtes analytiques.

Simplicité : installation et fonctionnement

Pour utiliser l'in-memory dans une base de données existante, il suffit de suivre deux étapes : (1) la taille du In-memory Column Store doit être définie par un paramètre dans le fichier d'initialisation de la base de données. (2) Ensuite, il faut sélectionner les tables qui doivent être disponibles en format colonne.

Il est ainsi clair qu'il n'est pas nécessaire de modifier les applications ou les infrastructures existantes, par exemple pour les opérations de sauvegarde et de restauration, pour utiliser Oracle Database In-memory.

Toutes les options d'une base de données Oracle sont conservées dans cette approche, comme la compression, le cryptage, les Real Application Clusters ou Data Guard.

Il faut ici dissiper le malentendu largement répandu selon lequel la technologie in-memory conduit généralement "tout simplement" à des améliorations de la performance : Ce n'est pas le cas de Hana ni d'Oracle Database In-memory.

Dans la base de données Oracle, l'Oracle In-memory Advisor aide à l'installation. Il donne des informations sur la taille du In-memory Column Store nécessaire ainsi que des indications sur les tables qui doivent être créées en tant qu'objets In-memory.

L'Oracle Database Optimizer peut désormais utiliser en plus le Column Store pour trouver le chemin d'accès optimal pour la requête analytique concernée.

La base de données peut ainsi exécuter une requête via le Buffer Cache traditionnel (Unique Index, Index Range Scan) ou via le In-memory Column Store. Les transactions OLTP continuent à être exécutées dans le Buffer Cache.

La base de données peut être réglée individuellement en fonction de sa répartition de charge. Le rapport entre la charge de travail analytique et la charge de travail OLTP peut être représenté par le rapport entre le Buffer Cache et le In-memory Store.

Oracle Database In-memory fonctionne sur toutes les plates-formes supportées par Oracle : UNIX, Linux, Windows. Pour les utilisateurs SAP, la base de données Oracle est donc une alternative attrayante à Hana, car elle ne comporte aucun risque.

Oracle recommande son Exadata Database Machine comme plate-forme matérielle optimale. Elle permet d'exploiter pleinement tous les avantages de la base de données Oracle, y compris l'option in-memory. Elle offre différents niveaux de stockage pour la base de données : In-memory, Flash et Disk.

Nous parlerons en détail de l'Oracle Exadata Database Machine pour SAP dans le prochain numéro. Vous trouverez plus d'informations dans la note SAP 2178980 ainsi que sur http://bit.ly/oracleinfo