Enfin, Oracle sort une option « InMemory » pour fournir une base vectorielle digne de ce nom à sa base transactionnelle classique.

Comment ça marche ?

On garde le stockage en ligne classique et on apporte une couche supplémentaire de stockage en colonnes et en mémoire. En fonction de la requête SQL qui est exécutée, le moteur Oracle va chercher les données sur le stockage classique en lignes ou en mémoire dans un stockage en colonnes.
Ce stockage en mémoire et colonnes rappelle celui de solutions déjà existantes, comme Qlikview, Microsoft PowerPivot, SAP HANA et bien d’autres.
Comme la mémoire est limitée seules certaines tables seront montées en mémoire. C’est au DBA ou à l’architecte/concepteur BI de sélectionner les tables candidates. A priori on peut aussi ne choisir que certaines partitions.

Le résultat

Les requêtes sont bien plus rapides sur des volumétries importantes, ce qui n’est pas étonnant quand on compare avec les solutions similaires.
Mais les requêtes transactionnelles gagnent aussi en rapidité ! En effet certains index ne sont plus d’utilité et sont donc supprimés (a priori les index bitmap).

Les contraintes

• C’est une option, ce n’est donc pas gratuit. Mais comme pour le partitionnement c’est une option obligatoire pour une base décisionnelle.
• Il faut une base en 12c, donc il est probable qu’il faudra monter de version les bases existantes …

Le reste de la famille

Exalytics est une appliance qui jouait le rôle de cette couche inmemory pour analyser les données rapidement. Le packaging est différent, mais ça fait doublon.
Cela signe aussi la fin des cubes Oracle (Essbase ou OLAP) si le temps de réponse est satisfaisant avec le inmemory.

Pour les autres (TimesTen, Big Data) le terrain de jeu n’est pas le même.

Et le reste du monde

SAP HANA est clairement visée. Il est vrai que SAP vend sa base comme LA base pour l’analytique et le transactionnel, et marchait sur les plate-bandes d’Oracle.
Ce dernier a vite mis en ligne un comparatif entre les deux bases de données, à son avantage évidemment.
SAP a vite rétorqué en commentant directement dans le document incriminé.

Loin de cette querelle fratricide on retiendra juste que :

• Oracle 12c inmemory n’est pas une base gérée totalement en mémoire comme HANA, c’est plus ce qu’on appellera « un cache » pour l’analytique.
• HANA n’est disponible que sur appliance ou cloud, ce qui est normal car il faut un matériel de compétition pour la faire tourner. Ce n’est pas le cas d’Oracle.

Les deux bases sont bien différentes, le choix va être difficile …

Oui mais …

L’idée est intéressante sur le papier. On bénéficie des deux modes de stockage, les applications transactionnelles et analytiques cohabitent sans problème. On peut récupérer instantanément tout un enregistrement en ligne pour une application transactionnelle, et on pourra calculer des agrégats complexes sur des volumétries importantes en un clin d’oeil.
L’application idéale semble le reporting opérationnel en temps réel, soit des états qui attaquent directement une base transactionnelle de production avec un temps de réponse instantané.

Pourtant quand on connait les bases en colonnes existantes, on sait qu’il existe un goulot d’étranglement quand on ajoute ou modifie une seule ligne. Or c’est ce qui se passe tout le temps sur une base transactionnelle classique. Alors comment va réagir la base Oracle inmemory ? Y a-t-il un temps de latence pour prendre en compte ces ajouts/modifications de ligne ? A-t-on vraiment du temps réel ?

Néanmoins il faut avouer que c’est une excellente pour le monde BI, les bases Oracle étant bien implantées dans notre univers.

cf l’actu oracle sur developpez

Exemple :

With emp as (
  select 20 deptno, 'SMITH' ename from dual UNION ALL
  select 30 deptno, 'ALLEN' ename from dual UNION ALL
  select 30 deptno, 'WARD' ename from dual UNION ALL
  select 20 deptno, 'JONES' ename from dual UNION ALL
  select 30 deptno, 'MARTIN' ename from dual UNION ALL
  select 30 deptno, 'BLAKE' ename from dual UNION ALL
  select 10 deptno, 'CLARK' ename from dual UNION ALL
  select 20 deptno, 'SCOTT' ename from dual UNION ALL
  select 10 deptno, 'KING' ename from dual UNION ALL
  select 30 deptno, 'TURNER' ename from dual UNION ALL
  select 20 deptno, 'ADAMS' ename from dual UNION ALL
  select 30 deptno, 'JAMES' ename from dual UNION ALL
  select 20 deptno, 'FORD' ename from dual UNION ALL
  select 10 deptno, 'MILLER' ename from dual )
SELECT deptno, LISTAGG(ename, ',') WITHIN GROUP (ORDER BY ename) AS employees
FROM emp
GROUP BY deptno;
 
    DEPTNO EMPLOYEES
---------- --------------------------------------------------
        10 CLARK,KING,MILLER
        20 SMITH,FORD,ADAMS,SCOTT,JONES
        30 ALLEN,BLAKE,MARTIN,TURNER,JAMES,WARD

La syntaxe est assez simple, en 1er paramètre on a la colonne à concaténer et en 2ème on a le séparateur.
La clause WITHIN GROUP() spécifie le tri à appliquer.
La clause OVER() permet de rajouter une partition, comme pour les autres fonctions analytiques.

Liens :
Documentation Oracle sur la fonction
Autres techniques d’agrégation pour les versions antérieures

Pour générer des lignes on utilise souvent la table DUAL, par exemple pour simuler une table de dimension contenant un nombre limité de valeurs :

On peut aussi utiliser cette méthode pour générer des séquences de chiffres, mais il faut dans ce cas écrire autant de lignes qu’on veut de valeurs :

Dans ce cas il vaut mieux passer par une boucle en PL/SQL, mais ça devient compliqué …
On peut simplifier en une seule ligne en détournant les requêtes hiérarchiques, et le code précédent se résume alors à :

SELECT level FROM dual connect BY level <= 10000

Les utilisations sont diverses et variées, on peut par exemple :

- générer des données de test pour des tests de perf :

SELECT 1 FROM dual connect BY level <= 1000000

ou aléatoires pour des tests :

select dbms_random.random() from dual connect BY level <= 1000

- incrémenter une séquence de manière élégante

select sequence.nextval FROM dual connect BY level <= 1000

– simuler une dimension temps sans avoir de table calendrier sous la main :

Simple non ?

• créer les ordres INSERT INTO, Toad le fait très bien ( via un Save as … ), mais quand il faut copier des tables de milliers de lignes on peut passer la journée :p
• passer par des export/import, mais généralement ces outils sont réservés aux DBA …

Un autre utilitaire existe depuis Oracle 9i, la commande copy sous Sql*Plus.

La syntaxe est la suivante :

copy from <cnxsrc> insert <tabdst> using select <col> from <tabsrc>;

ordre SQL à lancer sur l’instance de destination, où

Exemple :
copy from userprod/pwdprod@prod insert dwh.ventes using select * from dwh.ventes;
récupérer les données de la table ventes de prod en dev

Sortie:

Taille tableau extrait/lié est 15. (taille du tableau est 15)
Sera validé après opération. (COPYCOMMIT = 0)
Taille maximum (LONG) est 80. (longueur est 80)
   371225 lignes sélectionnées à partir de userprod@prod.
   371225 lignes insérées dans DWH.VENTES.
   371225 lignes validées en DWH.VENTES lors de la connexion DEFAULT HOST

Remarques :

• le commit est automatique
• à lancer sous Sql*Plus, ça ne marche pas sous Toad
• il faut préciser les colonnes dans le select si la structure est différente
• il faut ajouter des – en fin de ligne si on est sur plusieurs lignes

Exemple :

copy from userprod/pwdprod@prod -
insert dwh.ventes using -
select * from dwh.ventes;

Voir la doc Oracle pour plus d’infos comdab

TOAD est un outil merveilleux pour tout décisionneux oraclien qui se respecte, mais j’ai pu remarquer qu’il n’était pas utilisé à 100% de ses possibilités, et c’est dommage.
J’avoue bien sûr ne pas connaître tout ce que peut donner l’outil, mais je vais livrer ici quelques astuces bien utiles au quotidien.

Je vais commencer par l’ajout d’un raccourci vers sqlplus.

On peut être amené à lancer sqlplus quand on veut utiliser certaines fonctionnalités comme le spool, ou quand la sécurité bloque certains ordres SQL comme update et delete – c’est là qu’on a le fameux message

This version of TOAD provides READONLY access !

Par défaut la barre d’outils ressemble à ça :

On va y rajouter un bouton Sql*plus

En allant dans le menu Utilities / External Tools / Configure
on a la fenêtre TOAD Tool Options :

Cliquons sur le bouton « Add … » et rajoutons les paramètres suivants :

Bien sûr, les répertoires peuvent changer en fonction de votre installation …

Voilà, on a un bouton sqlplus dans la barre d’outils et quand on clique dessus une session se lance sous sqlplus avec la même connexion Oracle que sous TOAD sans devoir saisir ni le login, ni le mot de passe !!!

Petite astuce aujourd’hui sur les raccourcis clavier sous TOAD.
On tape régulièrement les mêmes ordres SQL dans l’éditeur, comme les SELECT FROM- quel manque de temps !

Avec les raccourcis clavier il suffit de taper quelques lettres et le tour est joué.

Par exemple j’ai configuré un raccourci spécial pour le « SELECT * FROM » que j’utilise au quotidien.

Pour cela, dans l’éditeur un petit clic droit fait apparaître un menu contextuel dans lequel il faut aller sur « Editing Options ». Dans Editor/Behavior on a 2 possibilités :

• les Code templates, qui sont appelés en appuyant sur la combinaison Ctrl + Espace.
• les Auto replace, qui remplacent automatiquement certains mots

A fortiori on utilise les Code template pour des modèles de Code PL/SQL ou de requête SQL, alors qu’on utilise les auto replace pour les jours où on a des moufles et qu’on ne sait pas taper sur le clavier.
Pour ma part je préfère les Code templates, allez on clique sur le bouton.

On atterrit sur une liste de raccourcis, comme vous le voyez pas mal de squelettes sont déjà définis.
On rajoute la ligne sf avec « SELECT * FROM« .

Maintenant dans l’éditeur si on commence la ligne par sf et qu’on tape sur Control et Espace en même temps le mot sf est remplacé par « SELECT * FROM » … Magique
Avec le temps cette astuce rend bien des services.

On peut en rajouter d’autres, moi j’ai rajouté
sat pour

SELECT * FROM ALL_TABLES
WHERE (1=1)
AND TABLE_NAME LIKE '%'
--AND TABLE_OWNER=''

satc pour

SELECT *
FROM ALL_TAB_COLUMNS
WHERE (1=1)
  AND OWNER LIKE '%'
  AND TABLE_NAME LIKE '%'
  AND COLUMN_NAME LIKE '%'

A personnaliser bien sûr !

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 !

Problématique :
On a un indicateur annuel, on connait un certain historique et on aimerait estimer les valeurs de cet indicateur dans le futur.

Exemple :

select * from test_regr

Ici on ajoute 2 à Y chaque année, donc on peut prévoir qu’en 2011 on aurait Y=10, en 2012 Y=12 etc …
Evidemment ici on a une suite logique, c’est un exemple parfait.

Dans la vraie vie ce n’est pas si facile, par exemple on aurait :

On n’a pas ici la même différence entre 2 années successives, On ne peut déduire la valeur de 2011 ou 2012 simplement.

Oracle propose des fonctions permettant de calculer une droite de régression. En résumé il s’agit d’établir une droite qui représenterait la courbe d’évolution de l’indicateur.

Séquence Nostalgie des cours de stats : La méthode s’appuie sur le calcul des moindres carrés, je ne vais pas rentrer dans les détails, d’autres le faisant mieux que moi comme sur wikipedia.

L’équation de cette droite est du type y= p x + y0, p étant la pente et y0 l’ordonnée à l’origine.
Sous Oracle la fonction REGR_SLOPE donne la pente, et REGR_INTERCEPT y0.
Une fois qu’on les a déterminés on peut estimer une valeur dans le futur en remplaçant x dans l’équation.

— ce qui donne avec l’exemple

with v as
  (   select 2010 annee, 8 y from dual
union select 2009, 6 from dual
union select 2008, 4 from dual
union select 2007, 2 from dual )
SELECT regr_slope( y, annee ) p, regr_intercept( y, annee ) y0 from v;
 
-- p=2 et y0=-4012

estimation pour 2011 :

ou en sql :

with v as
  (   select 2010 annee, 8 y from dual
union select 2009, 6 from dual
union select 2008, 4 from dual
union select 2007, 2 from dual )
SELECT regr_slope( y, annee )*2011 + regr_intercept( y, annee ) from v;

et le tout en one-shot :

with a as
  ( select to_char(sysdate,'YYYY') annee from dual union
    select to_char(add_months(sysdate,-12),'YYYY') annee from dual union
    select to_char(add_months(sysdate,-24),'YYYY') annee from dual union
    select to_char(add_months(sysdate,-36),'YYYY') annee from dual union
    select to_char(add_months(sysdate,+12),'YYYY') annee from dual union
    select to_char(add_months(sysdate,+24),'YYYY') annee from dual union
    select to_char(add_months(sysdate,+36),'YYYY') annee from dual
  ), v as
  (   select 2010 annee, 8 y from dual
union select 2009, 6 from dual
union select 2008, 4 from dual
union select 2007, 2 from dual )
select
  a.annee,  
  v.y  volume,  
  s.p * a.annee + s.y0 estim
from
  v,
  ( select regr_slope( y, annee ) p, regr_intercept( y, annee ) y0 from v ) s,
  a
where v.annee(+)=a.annee
order by a.annee;

Remarques :

• intuitivement on a une progression linéaire,
  ce qui veut dire que si on sortait le graphe on pourrait tracer une ligne droite pour représenter l’évolution de l’indicateur.
  Sinon les estimations ne donnent pas les bons résultats
• les fonctions regr sont des fonctions analytiques, on peut les utiliser comme telles avec la clause over( … )
  cela réduit le nombre de passages sur la table d’historique et peut jouer sur les performances

SOUS Business Objects :

On trouve bien les fonctions REGR_% dans l’éditeur des objets BO du designer

Mais les contraintes réduisent le champ d’action :

• on peut avoir des sum() en paramètre ( ex : regr_slope( sum( montant ), annee) ), mais la gestion est assez complexe, on mélange 2 fonctions d’agrégation et souvent cela pose problème car il manque une colonne dans le GROUP BY du select généré par BO.
  On oublie donc cela, et on a déjà des tables agrégées dans l’univers.
• quand on rajoute des dimensions ( dans l’éditeur SQL du rapport ) il faudrait les mettre dans la clause over(partition by (dimensions)) de la formule de l’objet dans Designer.
  Il faut donc être synchro entre l’éditeur de rapport et l’univers.
• il faut avoir des tables agrégées au grain de la dimension en x. Cela signifie qu’on doit avoir une seule valeur dans la table pour un x donné.

Par exemple si on a 10 opérations pour une année, on n’aura pas d’erreur mais les fonctions se feront sur une sorte de moyenne des indicateurs ( au lieu de la somme ).

Cela implique :

• il faut des tables agrégées au grain de la dimension en x. On peut s’en arranger avec des vues ou des tables dérivées qui font les sommes.
• il faut exactement les mêmes dimensions dans le fournisseur de données que celles utilisées pour les objets de régression.
• si on utilise d’autres objets la requête tombera en erreur
  Cela peut donc multiplier le nombre de tables et d’objets dans l’univers.
  Il est donc important de bien connaître les besoins au départ, de se limiter à ce périmètre et d’expliquer les contraintes aux utilisateurs finaux.

En conclusion l’implémentation des fonctions Oracle de régression dans BO pour établir un modèle prévisionnel est assez limitée.
Il faut définir l’état final et à partir de là définir les objets de l’univers en utilisant les fonctions regr_slope() et regr_intercept().
L’univers utilisé est un univers technique, on ne pourra créer facilement d’autres états prévisionnels à partir de celui-ci. Il faudra généralement à chaque fois créer de nouveaux objets.

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