Workshop Exadata V2

Oracle Colombes , salle Amandier vendredi 5 février, c’est là que 22 partenaires ont assistés à cette présentation de l’offre Exadata.

Easyteam y était bien sur et ne pouvait laisser passer cet événement car l’intérêt n’était pas tant dans l’explication théorique réalisée magistralement par l’animateur Robert Pastijn (du groupe Oracle PTS, Platform Technology Solutions) que dans la possibilité de manipuler directement les commandes sur un Exadata server et d’appréhender ainsi son utilisation.

L’agenda fut chargé et nous avons parcouru à grand pas les thèmes suivants :

• Exadata High Level Overview
• Hardware and setup
• Controlling resources
• Monitoring – Maintenance – Migration – Backup
• Best Practices

présentations que vous pouvez retrouvez en grande partie depuis cette page sur le site d’Oracle

Ayant à notre disposition l’équivalent de 2 Exadata Server, nous avons déroulé les ateliers suivants :

• Création de cellules et de « Grid disks » ,  création des groupes ASM correspondant, création d’une base de données utilisant ces groupes.
• Visualisation des effets des smart scan IO, de la compression , de l’utilisation du Flash cache et des « storage index »
• Mise en œuvre de la gestion des ressources et de la sécurité
• Suppression et remise en route d’un disque
• Visualisation des métriques et mises en place des alertes.

Pour vous en donner un rapide aperçu, voici un exemple sur l’utilisation des « storage index » , cette fonctionnalité consiste en la mise en mémoire dans l’Exadata server des valeurs minimum et maximum des colonnes pour les blocs des tables les plus accédées.

large_table est une table d’ 1 million d’enregistrements

La statistique associée à l’utilisation de la fonctionnalité se nomme ‘cell physical IO bytes saved by storage index’.

La requête SQL est simple : select count(*) from large_table where id between 100 and 200

La valeur de la statistique avant la première requête est :

SQL> select value from v$sysstat where name='cell physical IO bytes saved by storage index';
VALUE
----------
1032192

Exécution de la requête une première fois

SQL> select count(*) from large_table where id between 100 and 200 ;
COUNT(*)
----------
101

Elapsed: 00:00:00.73

Noter bien la durée de 0.73 secondes, la valeur de la statistique n’a pas bougé.

SQL> select value from v$sysstat where name='cell physical IO bytes saved by storage index';
VALUE
----------
1032192

Voici maintenant la seconde exécution de la requête :

SQL> select count(*) from large_table where id between 100 and 200 ;
COUNT(*)
----------
101

Elapsed: 00:00:00.03

Un temps écoulé bien inférieur.

SQL> select value from v$sysstat where name='cell physical IO bytes saved by storage index';
VALUE
----------
48005120

Soit  48005120 – 1032192 =  46972928 octets qui n’ont pas fait l’objet d’une lecture physique sur les disques ( 45Mo de moins) et un temps d’exécution divisé par 25!

Comme tous les POC (Proof Of Concept) ou les benchs déjà effectués par les équipes d’Oracle, les possibilités et les performances de cette machine sont exceptionnelles, à l’issue de ce genre de journée, il me tarde d’avoir la possibilité d’implémenter une production sur ce genre d’architecture, messieurs les ingénieurs d’affaires à vous de jouer !

Et s’il n’y a qu’une chose à retenir ce sont les 3 ordres de grandeurs suivants :

• Bande passante des disques d’une database machine : 21 Go/s
• Bande passante carte Flash : 50 Go/s
• et surtout grâce au flash cache : 1 Million d’IO/s