Alors, quel est le rapport entre GPU et la BI me direz-vous ?

Et bien le GPU ne sert pas qu’à afficher de jolies scènes en 3D, et les fabricants comme nVidia ou AMD offrent la puissance de calcul du GPU aux développeurs. Ainsi de nombreuses applications permettent d’encoder des vidéos plus rapidement via le GPU comme Nero Move It ou Cyberlink MediaShow Espresso. Un article sur Clubic explique très bien l’intérêt des GPU et on en parle aussi sur developpez.

En résumé le GPU est bien plus performant dans les calculs simples sur de grosses volumétries comme en 3D …
Et là on comprend mieux l’intérêt de l’utiliser pour la BI où les données se comptent en Téra !

C’est du côté de l’opensource que les éditeurs se sont lancé avec Jedox et PALO 3.2 qui offre un serveur OLAP de bonne facture. Optimisé avec des cartes nVidia le gain annoncé est important : de 20 à 30 fois … Mais comme d’habitude il faudra attendre un certain temps avant de connaître les performances réelles.

Deux bémols à propos de cette solution :
– la solution est propre à un seul constructeur, en l’occurence nVidia
– les GPU sont du côté serveur et non du côté client. Donc pas de partie du dernier Call Of Duty au boulot :p

Pour optimiser le refresh des vues matérialisées en refresh full, il vaut mieux les supprimer et les recréer que de les rafraîchir …( en 10g )
Ainsi un refresh d’une VM prend 1h, alors que la suppression / création prend moins de 10 minutes !

La solution made in DBA consiste généralement à rajouter un hint, c’est à dire une petite ligne de code pour forcer le plan d’exécution.

Exemple :

SELECT /*+ FULL(SALES) */
  ...
FROM  
  SALES,  
  ....
-- ici on ne passe par les index, on lit la table complètement

Pour coder ce hint dans Business Objects, on peut :

• modifier le sql généré
  C’est dommage, on perd la fonctionnalité de sql dynamique de BO, avec tous les inconvénients que cela engendre : maintenance difficile, désynchronisation de la requête avec l’univers.
• modifier la propriété hint de la connexion.
  Mais toutes les requêtes seront impactées, ou il faut créer une nouvelle connexion.
• créer un nouvel objet

Cette dernière solution est à privilégier.
Il suffit de créer un objet technique pointant sur une constante ( 0, 1 ou NULL ), à mettre en 1ère position dans l’éditeur de requête.

La formule de l’objet est

/*+ FULL(SALES) */ 0

Et on le définit sur la table SALES ( bouton Tables … ) pour éviter les alertes lors de la vérification de l’intégrité de l’univers.

UPDATE avenir
SET montant=(SELECT sum(montant) FROM echeancier
WHERE echeancier.id=avenir.id
AND echeancier.datecheance > :dateparametre
AND ( autres filtres ) ;

Oracle utilise bien les index, mais comme la volumétrie est importante, la mise à jour est très longue ( 1h15 ).

La solution classique est de passer par une table temporaire, puis de faire l’update. Mais il faut pouvoir créer une table, voire gérer les droits … Bref, pas très pratique.

Le Merge permet de faire un update massif, sans passer par une table intermédiaire.

Le sql transformé donne :

MERGE INTO avenir  
USING  
( SELECT id, sum(montant) montant
FROM echeancier
WHERE echeancier.datecheance > :dateparametre
AND ( autres filtres )   ) x
ON ( avenir.id = x.id )
WHEN MATCHED THEN UPDATE SET montant=x.montant;

Oracle n’utilise plus les index, mais on passe de 1h 15 à 2′ 20.
( 2’40 en passant par une table temporaire )

Que du bonheur

/* exemple **
with operations
as (  
select 1 idclient, sysdate dat, 4 val from dual union all
select 1 idclient, sysdate+1 dat, 8 val from dual union all
select 1 idclient, sysdate+2 dat, 7 val from dual union all
select 2 idclient, sysdate dat, 2 val from dual ) */
select idclient, max(dat) from operations group by idclient

Par contre si on veut récupérer d’autres informations de cet enregistrement, il faut passer par une sous-requête :

select idclient,  dat,  val
from operations a
where a.dat=(select max(b.dat) from operations b where b.idclient=a.idclient )

Le problème est ( entre autres ) qu’on passe 2 fois sur la table operations, ce qui dégrade les performances.

Oracle propose depuis la 9i les fonctions analytiques, ce qui est bien pratique pour gérer ce type de problème.
On utilisera par exemple la fonction row_number(), mais on aura toujours une sous-requête :

select idclient, dat, val from (
  select idclient, dat, val,
    row_number() over(partition by idclient order by dat desc) num
  from operations
)
where num=1

Cette solution n’est pas forcément simple à implémenter du fait de la sous-requête. Un ETL comme Sunopsis/ODI ne gère pas les sous-requêtes, il faut passer par des vues et du coup on perdra le lien dans l’analyse d’impact de l’outil.
Solution miracle, on a une requête en one-shot avec la clause keep :

select idclient,
  max(dat),
  max(val) keep (dense_rank last  order by dat) val
from operations
group by idclient

Cerise sur le gâteau, on peut aussi utiliser ce type de clause dans un univers Business Objects, cela évite de passer par une table dérivée ou du sql en dur.

Que du bonheur.