La mémoire n'est pas suffisante

Même chez SAP, on s'est rendu compte que l'idée initiale, qui semblait si simple et géniale, de conserver en permanence toutes les données en mémoire, était en partie irréalisable et en partie insuffisante.

Elle n'est par exemple pas réalisable lorsqu'une base de données contient un grand nombre de données historiques dont le chargement en mémoire entraînerait une explosion des coûts de la mémoire nécessaire.

En outre, il ne suffit pas de conserver les données en permanence dans la mémoire, car toute base de données doit garantir la persistance des données qui y sont stockées.

Il est donc nécessaire d'utiliser des supports de stockage persistants et judicieux de réfléchir à l'utilisation la plus efficace possible de ce stockage. Dans la base de données Oracle, il existe depuis de nombreuses versions déjà deux technologies qui servent à cette utilisation efficace :

Le partitionnement et la compression. Et il y a deux technologies, car le mot "efficace" peut avoir deux significations différentes.

Ce qui va ensemble : le partitionnement

"Utilisation efficace de l'espace mémoire" - cela peut tout d'abord signifier : les données doivent être stockées de manière à ce que l'accès aux informations qui ne se trouvent pas encore en mémoire nécessite le moins d'opérations d'E/S possible.

"Optimisation du stockage des données" signifie alors que les données ne sont pas stockées dans un ordre aléatoire (comme c'est le cas par défaut), mais en tenant compte de la question de savoir quels groupes de données seront à nouveau nécessaires ensemble ultérieurement.

Partager une table signifie la diviser en sous-groupes de ce type. Une partition contient alors, par exemple, toutes les données qui ont été ajoutées au cours d'un mois donné ou qui sont attribuées à une filiale particulière.

Pour les clients SAP-on-Oracle, le partitionnement est activé par défaut dans SAP BW, ils en profitent donc immédiatement. Le partitionnement Oracle est toutefois autorisé et supporté pour toutes les applications SAP NetWeaver. Il peut donc également être utilisé dans des systèmes non-BW. Pour l'implémentation, il existe par exemple le SAP Partitioning Engine.

Compression

"Utilisation efficace de l'espace de stockage" peut également signifier : les données doivent être stockées de manière à occuper le moins d'espace possible et à freiner la croissance gigantesque des bases de données.

Si l'on considère plusieurs versions du logiciel de base de données, cela signifie que l'efficacité du stockage des données doit être augmentée en permanence, de sorte que le même ensemble de données utilise de moins en moins d'espace de stockage d'une version à l'autre.

Et une exigence supplémentaire signifie que tout cela doit se faire sans que le client doive payer le prix d'une dégradation des performances.

Oracle Database 11g misait déjà sur le concept de ne pas écrire plusieurs fois les valeurs qui apparaissent plusieurs fois. Cela vaut aussi bien pour les tables que pour les index. Le taux de compression qui peut ainsi être atteint dépend des caractéristiques des données et de l'application.

En général, les données de SAP BW (BI) peuvent être davantage comprimées que celles de SAP ERP (ECC), et SAP CRM permet de réaliser des économies encore plus importantes. En moyenne, une base de données entièrement comprimée avec Oracle Database 11g dans l'environnement SAP nécessite 55% d'espace de stockage en moins que la base de données correspondante non comprimée.

Tout dépend de la température

Une question fréquemment posée est la suivante : pourquoi le stockage de données compressées n'est-il pas devenu la norme ?

Une partie de la réponse se trouve dans les tables SAP BW utilisées pour le chargement de nouvelles données. On aimerait bien comprimer ces tables, mais cela ralentirait considérablement le processus de chargement.

C'est ici qu'intervient Oracle Database 12c, grâce à l'introduction d'un nouveau paramètre. Dans la version 11g, l'utilisateur peut, en ce qui concerne chaque table et chaque index, répondre à la question de savoir si cet objet doit être compressé.

Les réponses possibles sont "oui" ou "non". Dans la version 12c, la question supplémentaire est de savoir quand les données nouvelles ou modifiées doivent être comprimées. Les réponses possibles sont donc désormais du type : "Oui, mais pas avant une semaine".

Ce n'est que grâce à ce nouveau paramètre que les tables nécessaires au chargement des données peuvent être incluses dans la compression : Les données chargées sont d'abord des données non comprimées (pas de prolongation de la durée d'exécution), qui ne sont comprimées qu'ultérieurement, c'est-à-dire au moment approprié (compression différée).

Cette solution a été conçue de manière si générale dans Oracle Database 12c qu'elle permet d'implémenter une gestion complète du cycle de vie de l'information (ILM). Elle s'appuie sur deux nouvelles fonctionnalités :

• La carte de chaleur surveille automatiquement l'intensité de l'utilisation des données. Elle distingue les "données chaudes", qui sont souvent utilisées en lecture et en écriture, les "données chaudes", qui ne sont utilisées qu'en lecture, et les "données froides", qui sont très rarement utilisées, voire plus du tout.
• Automatic Data Optimization (ADO) permet de définir plus précisément ce que doivent signifier "chaud", "chaud" et "froid" et de déterminer ce qui doit se passer lorsque les données passent de l'état chaud à l'état chaud ou de l'état chaud à l'état froid.

Les données peuvent être transférées vers d'autres systèmes de stockage lorsque leur "température" change, un processus également appelé "Storage Tiering". Les données froides, par exemple, peuvent être transférées sur des disques plus lents et donc moins coûteux.

Grâce à l'optimisation automatique des données, l'administrateur de la base de données définit des règles qui décrivent les différents "états de température", par exemple que les données qui n'ont pas été modifiées pendant 180 jours sont considérées comme "froides".

Le "Compression Tiering" détermine en outre le degré de compression appliqué ; ici aussi, le facteur temps peut jouer un rôle. Si les données n'ont pas été manipulées depuis plus de 360 jours, la compression la plus forte est appliquée.

"À l'intérieur" est mieux que "à proximité".

Ces concepts et technologies de compression complets pour Oracle Database 12c offrent des avantages, notamment par rapport aux solutions propres à SAP. Ainsi, avec Hana, la croissance continue de la base de données devient également un problème.

Pour ne pas entraver l'exploitation productive, SAP mise sur le "Near-Line-Storage", ce qui ne signifie rien d'autre que de retirer les données de la base de données productive et de les stocker séparément, même si elles sont "proches" de la base de données. Avec Oracle Database, les données peuvent être conservées beaucoup plus longtemps dans la base de données productive, car elles peuvent être comprimées beaucoup plus fortement.

Oracle Exadata

Ceux qui souhaitent exploiter encore davantage la base de données Oracle sont bien servis par les Engineered Systems d'Oracle. Le moteur de base de données Exadata optimisé pour l'exploitation de la base de données maîtrise encore d'autres méthodes d'optimisation et d'augmentation de l'efficacité :

Avec la compression hybride en colonnes, les systèmes Exadata offrent des algorithmes de compression supplémentaires et plus puissants, ce qui permet de réaliser de nombreux niveaux de compression en colonnes.

De plus, un Exadata étend la base de données avec le "Smart Storage". Cela permet de transférer une partie des calculs nécessitant beaucoup de données du serveur de la base de données vers les serveurs de stockage. Ainsi, lors de requêtes, les tables et les index qui ne sont pas pertinents peuvent déjà être filtrés au niveau du stockage afin de réduire considérablement les entrées/sorties.

Oracle Database offre donc de nombreuses possibilités d'optimisation et d'augmentation de l'efficacité pour le stockage des bases de données. Celui qui utilise ces possibilités pour ses systèmes SAP peut mieux utiliser les ressources sans pour autant renoncer à la performance de la base de données.