– Bonjour Albert, ça va ?

– Bonjour Gilbert , que puis je faire pour toi ?

– Tu sais si Oracle a enfin sorti son premier patchset pour leur version 12c de l’Oracle Database ?

– Oui, depuis le 22 juillet, j’étais en vacances mais j’ai vu passé un message de @stforlong d’Easyteam qui retweetait l’information, au début je n’ai rien compris car le lien fourni était sur un site hollandais ! Mais la voilà, elle est disponible, en fait c’est carrément une nouvelle release tellement il y a des nouveautés !

– On peut la récupérer où ?

– Sur edelivery.oracle.com par exemple. Tiens, regardes: depuis l’url , tu te connectes avec ton compte MOS ou  OTN,  tu valides les restrictions d’usage et de licence en cochant les bonnes cases, tu cherches le pack produit “Oracle Database” pour la plateforme voulue :  “ linux x86-64”,  un clic sur le bouton “GO”  et te voilà avec la liste de ce qui est disponible, dont le media pack pour la toute dernière  version 12.1.0.2.0  :

– Si tu le sélectionnes,  tu as tous les composants du pack, avec deux zips qu’il faut télécharger pour la
base  et deux autres pour la partie grid infra :

–  Tu vois, c’est de plus en plus volumineux avec 2,6 Go et 2,3 Go en compressé !

–  Et est ce qu’il y a d’autres plateforme disponible ? Du Windows par exemple ?

– Pas encore, c’est prévu pour la fin de l’année,  on le voit mieux sur l’url de téléchargement d’OTN , regarde ici : http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html , non seulement il n’y a que la version Enterprise Edition ,  mais on ne la trouve que pour linux 64 et  Solaris (SPARC et x86 64) :

– Tu crois que ça vaut vraiment le coup ?

– Alors ce n’est pas seulement un patchset qui corrige les premiers bugs,  j’ai fait un tour de la doc sur les nouveautés, il  y en a 21 de décrites , celle pour laquelle Oracle a fait le plus de bruit c’est bien sur “In-Memory Column Store”  aka “In-Memory Database” , l’utilisation d’un nouveau cache en mémoire pour le stockage des données d’une table en colonne (et on plus en ligne) avec de la compression en plus. C’est encore tôt pour évaluer l’apport de performance mais Oracle l’annonce comme un index killer !  Ce devrait intéresser nos financiers pour leurs analyses. Pour la mise en œuvre rien de très complexe, un paramètre pour la taille de la zone (INMEMORY_SIZE), un rebounce de la base et une alteration des objets à mettre dedans. Tu peux voir le site de OAKtable Network, ils ont déjà testé le fonctionnel.  Reste à justifier son coût auprès de la direction car c’est une nouvelle option !

– Aie ! Encore des prises de têtes pour le ROI !

– Eh oui, on commence à être habitué. L’option “Oracle Database In-Memory” comprend aussi la fonctionnalité “In-memory aggregation”   une nouvelle méthode de l’optimiseur pour  traiter les tables de dimensions dans les requêtes en étoiles, elle se contrôle par des “hints” spécifiques :  VECTOR_TRANSFORM_FACT et VECTOR_TRANFORM_DIMS, pour plus de détail je te conseille la doc, elle est explicite :  Tuning Guide SQL Chapitre 5 .  Pour la gestion de la mémoire , il y a un autre  truc qui semble pas mal dans le cas ou la taille de la base est plus petite que la mémoire disponible, tu vois comme pour ce progiciel de gestion des automates ou les données ne représente que 10Go,  on peut maintenant forcer le moteur à monter tous les blocs dans le cache quelque soit la taille des tables avec la fonctionnalité “Full Database Caching” . Pour cela un arrêt de la base est nécessaire, avec la commande “ALTER DATABASE FORCE FULL DATABASE CACHING”  quand la base est montée. Tu peux voir ici pour quelques détails ou encore la doc dans le Tuning Guide DBA chapitre 13.5

– Et celle-là c’est une autre option ?

– Non pas cette fois, mais je ne suis pas sur qu’elle soit disponible pour les versions Standard ou Standard One !

– C’est pas mal,  quoi d’autre  ?

– Si on reste sur la mémoire, et si on ne peut pas mettre toute la base en mémoire , il y a “Automatic Big Table Caching” , sous ce terme barbare on trouve le paramètre DB_BIG_TABLE_CACHE_PERCENT_PARAMETER qui réserve le pourcentage défini du cache des données au FTS (Full Table Scan) et conserve le reste pour le fonctionnement traditionnel. Il y a deux modes de fonctionnement:  avec des bases de données RAC seul les requêtes parallélisées peuvent en profiter, à condition de définir PARALLEL_DEGREE_POLICY sur AUTO ou ADAPTATIVE , et pour les bases mono instance, il peut s’appliquer sur les requêtes sérialisée ou parallèle la doc dans Oracle Database VLDB and Partitionning Guide chapitre “Using Parallel Execution” est bien détaillée.

– Cette fois c’est vraiment le maximum pour conserver les données en mémoire, même pour  les lectures massives !

– Oui d’ailleurs , il y a deux fonctionnalités pour dénormaliser les données et les stockées dans les mêmes zones des disques afin de favoriser encore plus les lectures massives :  “Attribute clustering”   et “Zone maps”  , la première est une directive de construction de la table (la nouvelle directive CLUSTERING avec toutes ses options) qui va permettre de ranger les lignes dans des zones physiques proches en relation avec le contenu d’une colonne de la table voir d’une colonne d’une autre table, une extension des tables de type CLUSTER en quelque sorte, c’est pour le Datawarehouse et c’est décrit dans  Oracle Database Datawarehouse Guide chapitre 12.  De même la seconde permet de définir une cartographie de la table (avec la directive WITH ZONEMAPS, dans l’ordre de  création de la table) qui référencera les blocs contigus pour un ensemble de valeurs, permettant si le critère de la requête le permet d’éliminer rapidement les zones qui ne correspondent pas au critère, un peu comme le “pruning” des partitions. Attention cela ne fonctionne que sur les serveurs Exadata et Supercluster et nécessite l’option “Partitionning”

– Ca peut devenir gênant de faire dépendre le modèle du stockage, ce n’est pas normal !

– Il va falloir voir si le jeu en vaut la chandelle ! Sur les très gros volumes la différence doit être sensible.

– Après il y a toute une série de petites touches pour améliorer l’utilisation de l’architecture multitenant, et ça tombe bien notre projet de consolidation est en route,  comme :

• Le maintien de l’état des PDBs lors du redémarrage de l’ensemble “PDB State Management accross CDB Restart”

– Ah oui fini l’utilisation de ce trigger de démarrage,  ça c’est bien , ils auraient pu le mettre dés le début !

– Il ne faut jamais désespérer des développeurs. Ensuite nous avons :

• La clause CONTAINERS dans les requêtes, pour que les DBAs interrogent en une fois les mêmes tables présentent dans tous les PDBs, du style “SELECT CON_NAME,* FROM CONTANERS(clients)” ou dans un sous ensemble des containers par “SELECT CON_NAME,* FROM CONTAINERS(clients) WHERE CONT_ID in (1,3)”

• La simplification du placement des fichiers des PDBS via la nouvelle clause  CREATE_FILE_DEST de l’ordre CREATE PLUGGABLE DATABASE. C’est plus facile à scripter que FILE_NAME_CONVERT , mais cela implique que le nom des fichiers est géré par Oracle (OMF Files), documenté dans Oracle Database Administrator Guide , chapitre 38

• L’attribut LOGGING ou NOLOGGING défini pour le PDB que l’on peut spécifier dans les ordres CREATE ou ALTER PLUGGABLE DATABASE.

• Le clonage des seules métadonnées pour les PDBs  “PDB Metadata Clone” , ce qui permet de ne prendre que la définition de la base sans aucune données avec la clause NO DATA de l’ordre CREATE PLUGGABLE DATABASE.

• La création d’un nouveau PDB  au travers d’un DBLINK “PDB Remote Clone” , simplement en précisant le lien dans la clause FROM , comme : “CREATE PLUGGABLE DATABASE PDB2 FROM pdb1@pdb1_link”  , que la source soit de type PDB ou non , pas mal pour une transformation rapide de l’architecture !

• Le clonage d’un sous ensemble des tablespaces de  la base PDB source lors du clonage :  “PDB Subset cloning”  . En utilisant l’attribut USER_TABLESPACES=’ .,..’  dans l’ordre CREATE PLUGGABLE DATABASE … FROM ..

• La possibilité de ne plus faire du tout ou rien pour les configurations Dataguard avec la clause STANDBYS=NONE dans l’ordre CREATE PLUGGABLE DATABASE  , tu peux ainsi avoir une configuration ou dans un même conteneur racine, certaines PDBs sont protégées par des bases de secours  et les autres non.  Cela risque d’être galère pour les basculement et certaines récupérations , mais ça a le mérite d’exister maintenant.

• L’extension de l’utilisation de l’option SNAPSHOT COPY dans l’ordre CREATE PLUGGABLE DATABASE  à plus de matériel, ce qui permet d’utiliser les capacités de snapshot du stockage pour les nouveaux fichiers de la base.  A ce propos ce serait bien que l’on étudie cette méthode pour provisionner certains environnements,  certains bloggers ont envisagés cette solution et le montre ici , avec les fichiers de la base de données sur de l’ACFS.

– On commence à voir tout et n’importe quoi sur la blogosphère !

– L’utilisation de Flashback Database Archive, FDA,  avec les bases de types containeurs qui n’était pas possible dans la version initiale.

– On voyait bien qu’il y avait quelques manques !

– Et il en reste encore comme la possibilité d’utiliser l’optimisation automatique des données, ADO pour “Automatic Data Optimization” Automatic Data Placement, ADP,  avec l’architecture multitenant !

– D’autres nouveautés dans d’autres domaine ?

– Quelques éléments divers oui, comme:

• La compression avancée des indexes, Il existait déjà depuis la version 8i  la possibilité de compresser les indexes, en version Enterprise Edition seulement , mais la méthode ne concernait que la déduplication d’un préfix , via une commande de type  “CREATE INDEX …. USING PREFIX COMPRESSION” , le nouvel algorithme permet  lui une véritable compression de la totalité de la clé réalisée au niveau du bloc permettant un réel gain de place.  Attention cette fonctionnalité nécessite l’option ACO (Advanced Compression Option) et a quelques contraintes d’utilisation, elle ne s’applique pas sur les indexes de type bitmap ou fonctionnel,  ni sur un index unique mono colonne par exemple.

• Une nouvelle fonction pour compter les valeurs distinctes : APPROX_COUNT_DISTINCT() , le résultat est obtenu beaucoup plus rapidement à l’aide d’un nouvel algorithme, mais c’est une approximation, la précision n’est pas clairement documentée, il va falloir mettre quelqu’un la dessus si l’on veut pouvoir la proposer aux développeurs.

• Le support du standard de cryptage FIPS 140 pour les fanas du codage qui veulent être conforme à la norme fédéral américaine, je ne crois pas que l’on ait ce genre de besoin chez nous.

• Le support des objets JSON, JavaScript Object Notation dans la base XML DB , avec la possibilité de faire des recherches du type : Donnez moi le troisième élément du tableau dans la propriété “plats chauds”

– Je crois que tu m’as convaincu , je vais de ce pas faire mon installation et vérifier que la mise à niveau  de mes bases de tests vers cette nouvelle release  se déroule bien.

– Tiens moi au courant et si tout va bien on en parle aux responsables applicatifs à la réunion de rentrée, il ne faudra oublier le plan de formation pour nos équipes, ça commence à faire pas mal d’évolutions !

– T’inquiètes , en plus notre partenaire  habituel est déjà prêt.

– Un dernière chose Albert,  il y a un index de toutes les informations sur la 12CR1 sur le site MOS c’est la note « Information Center: Oracle Database 12c Release 1, Doc ID 1595421.2 » jettes y un œil, ça vaut le coup. Allez à plus, on se retrouve au self.

– Yep , à plus .