Le village Informix est un blog technique consacré aux technologies Informix et tout ce qui tourne autour. C'est une zone de news, d'échange d'idées, de questions, de coups de coeurs et pourquoi pas de coups de gueule, techniques bien entendu! Après tout nous sommes en Gaule, nous sommes connus pour cela, alors mettons nos talents à profit!
vendredi 30 décembre 2011
jeudi 29 décembre 2011
Informix et Perl: un vieux couple plein de ressources
Le shell unix c’est bien, mais il y a beaucoup mieux et vous l'avez déjà
En tant que DBA émérite, vous avez développé à coup sûr un certain nombre de scripts en command shell. Ce langage est très pratique et versatile pour assurer vos tâches d’administration IBM Informix Dynamic Server. En le combinant avec les commandes habituelles comme onmode, onstat, oncheck, onparams et autres, vous avez mis en place toute une gamme de scripts qui vous permettent de gérer automatiquement vos sauvegardes, l’exécution des UPDATE STATISTICS, la gestion de certaines alarmes, le démarrage-arrêt de vos instances, ainsi que la connexion auxdites instances. Vous avez probablement ajouté des scripts de monitoring basés sur onstat et oncheck.
Mais soyons sincères, quand nous relisons ces scripts pour les maintenir, ou pire quand nous devons modifier un script écrit par quelqu’un d’autre, le niveau de complexité de l’écriture est très souvent inversement proportionnel à la facilité de lecture. Il est vrai qu’après le 7ème niveau d’imbrication de « pipe », on ne sait plus trop où l’on est arrivé.
En fait, si le shell unix comprend un très grand nombre de commandes extrêmement utiles et pertinentes, le ciment ( matérialisé généralement le « pipe », assorti de ls, grep, awk, cat, echo et expr ) qui les unit pour en faire de véritables applications est loin d’être simple à comprendre et encore moins simple à débugger. De plus, si vous devez installer ces scripts sur un autre parfum d’Unix, tout se complique car une foule de commandes soit ne réagissent pas de la même manière, soit produisent directement des erreurs de syntaxe. Je n’évoque même pas le scénario catastrophe du déploiement d’une instance sous Windows ou Mc Intosh, qui font désormais partie des plateformes habituelles de IBM Informix, où vous devrez probablement tout réécrire…
Vous l’avez sous les yeux, et il en fait des choses!
C’est vrai, le shell Unix répond efficacement aux besoins immédiats quand il faut obtenir rapidement un résultat, cependant trop de problèmes de compatibilité, performance et facilité de maintenance viennent impacter négativement l’industrialisation de ces fonctionnalités d’administration. Je commençais à mesurer la véritable portée de ce problème quand, en 1997, un ami m’a recommandé de regarder de près le langage Perl ( Practical Extraction Report Langage).
Il a tout d’un grand
Au-delà du rôle originel de Perl qui est le parsing de texte, j’ai très rapidement compris que j’avais entre les mains un véritable langage de développement qui combinait les attributs d’un langage évolué comme C, les utilitaires awk et sed, incluant la majorité des commandes du shell. Gérant les variables scalaires, tableaux, hash, visibilité des variables, opérateurs binaires, unaires, logiques, blocs d’ordres, gestion de fonctions avec passage et réception de paramètres par référence ou non, un système de gestion d’entrées-sorties très proche du système et enfin les très puissantes expressions régulières, on sent fortement le lien de parenté avec C, mais tout cela reste malgré tout beaucoup plus facile et rapide à coder et à lire ( adieu aussi les core dumped !)
Même pas peur !
Vous disposez également d’un très bon debugger interactif ( adieu les « set –x » oubliés dans le code !). Au sujet performance, Perl n’a pas la rapidité de C puisque les modules ne sont pas compilés, mais reste cependant très honorable ( Ex 2 sec. pour lire entièrement un fichier de 32 Mb/640 000 lignes).
Mais quel est le véritable intérêt par rapport au shell ?
Perl peut déjà faire tout ce que le shell peut faire, mais de façon beaucoup plus simple. Finies les contorsions et galipettes entre cat, awk, sort ,grep ls, read etc… ! Avec Perl, le code va directement au but recherché.
Par contre, Perl sait faire des choses que le shell ne sait pas faire, notamment dans le domaine de la programmation-système. Par exemple, il est simple de gérer la communication entre processes via les IPC, gérer des files de messages In/Out et autres friandises du genre.
Il se sent bien partout
Un autre avantage de Perl réside dans sa portabilité. Dans la mesure où vous n’incluez pas dans vos programmes Perl des commandes shell spécifiques à telle ou telle plateforme, votre programme Perl fonctionnera à l’identique sur des plateformes différentes, que ce soit sur n’importe quel Unix, Windows ou Mac Intosh, pour ce qui nous intéresse.
Mais l’argument de poids est la richesse de la librairie de modules disponible gratuitement pour la communauté. Ces modules couvrent les fonctionnalités les plus diverses et variées, allant d’extrêmement utiles à plus anecdotiques. Des fonctionnalités indispensables comme une fonction qui traduit n’importe quelle date en format caractère ( ex « lun. Déc 26 17 :45 :14 2011 CET » ) en un nombre entier de type « epoch », permettant en autres de calculer des intervalles entre deux timestamps (Time ::¨ParseDate, utile quand on parse un fichier log par exemple), ou bien obtenir toutes les propriétés d’un fichier ( stat ), ou bien lire et se déplacer dans un fichier en mode binaire ( IO ::Handle ), mais aussi lire les propriétés d’une image (Image::ExifTool ), et la très puissante Win32::OLE qui permet d’accéder en lecture ou écriture à pratiquement tous les objets Microsoft comme boite email Outlook, documents Word, Excel etc...
Dans cette foule de modules, il en existe un qui nous intéresse particulièrement : DBD::Informix. Vous l’avez compris, ce module est le module de communication avec les bases de données IBM Informix. Développé et maintenu par un Informixien de longue date, et maintenant vénérable IBMer barbu, ce module contient toutes les fonctionnalités nécessaires à pouvoir utiliser le langage SQL pratiquement comme avec Esql/C, Informix 4GL ou dbaccess, dans vos applications Perl.
On essaye ?
Pour des raisons que vous imaginez sans doute, le module DBD:Informix ne fait pas partie des packages de base généralement livrés avec Perl ( pas plus que le module du « Evil Empire kind of database » d'ailleurs ). Il faudra aller le chercher sur CPAN, l'immense répositoire de packages Perl. Après avoir « éprouvé quelque difficulté » avec la version précédente de l'installation, il suffit de savoir comment faire et l'installation se fait sans sueur ni larmes.
Les prérequis obligatoires:
- avoir Perl version supérieure ou égale à 5.14 pour être en totale conformité,
- avoir esql/C > 7.31 ou mieux Informix CSDK 3,X ( généralement inclus dans IDS à partir de la version 10.00 )
- avoir un moteur Informix ou IBM Informix ( SE ou IDS ) « on-line »
- avoir créé la base de démonstration stores
- avoir créé l'utilisateur informix
- une connexion internet en état de marche,
- Sans problème sous Linux, et à ma connaissance sous les autres plateformes Unix, plus délicat pour l'instant sur plateforme Windows, mais affaire à suivre...
Avant de lancer l’installation, vous devez, sous l’utilisateur root, pouvoir vous connecter à la base stores avec dbaccess, donc avoir les variables d’environnement $INFORMIXDIR, $INFORMIXSERVER et $PATH correctement valorisées. Vous devez également pouvoir exécuter un binaire esql/c, donc avoir la variable $LD_LIBRARY_PATH ( linux , AIX) ou $LIBPATH ( solaris etc ) valorisée à « $INFORMIXDIR/lib :$INFORMIXDIR/lib/esql :$INFORMIXDIR/lib/tools »
Une fois ces test préliminaires accomplis, vous pouvez taper :
perl -MCPAN -e 'install Bundle::DBD::Informix'
Laissez ensuite le système ( l’outil CPAN ) gérer l'affaire. Dans la mesure où les prérequis sont respectés, l'installation se fait sans aucune anicroche. Par contre, en cas d'oubli, les messages d'erreur sont quelque peu démotivants. Il suffit alors de remédier aux prérequis manquants et relancer la commande citée plus haut. Perl CPAN reprendra l'installation là où il s'était arrêté.
Quelques messages d'erreur peuvent apparaître en cours de route. Tant que l'installation ne s'arrête pas, tout va bien. L'installation se termine par « /usr/bin/make install -- OK ».
A la vue de ce message, vous êtes prêt à utiliser le module DBD::Informix. Une petite vérification par un find /usr –name Informix.pm, pour vous assurer que vous avez bien Informix.pm quelque part dans /usr…lib64 … /DBD/Informix.pm.
Vous pourrez aussi le trouver dans ~root/.cpan/build/DBD-Informix-2011.0612-*, qui est la directory d’installation, mais il doit être absolument dans /usr/…libXX.
Installation OK! voyons les rudiments.
Pour pouvoir utiliser DBD::Informix, il faut l’inclure dans le programme Perl, en notant en tête du module :
use DBD::Informix qw(:ix_types) ;
Pour se connecter à une base :
$dbh=DBI-connect(« dbi:Informix:$databasename »,$username,$password) ;
Pour préparer un SELECT :
$stmt=sprintf «SELECT col1,col2,col3,col4 FROM mytable ORDER BY col2» ;
$sth = $dbh->prepare($stmt);
$sth->execute() ;
Pour lire le curseur, et afficher le contenu :
$sqlcode=0;
while ( $sqlcode != 100 ) {
($var1,$var2,$var3,$var4) = $sth->fetchrow_array() ;
printf “%s %s %s %d\n”,$var1,$var2,$var3,$var4 ;
$sqlcode=$sth->{ix_sqlcode};
}
Mais vous pouvez également remplir un array contenant le résultat complet du curseur, pour le traiter ensuite en mémoire comme une structure organisée à l’image de la table, à l’image du RECORD LIKE d’Informix 4GL :
$array_ref = $sth->fetchall_arrayref ( {col1=>1,col2=>1,col3=>1,col4=>1}) ;
foreach $row ( @$array_ref ) {
printf “%s %s %s %d\n”,$row->{col1},$row->{col2},$row->{col3},
$row->{col4} ;
}
Pour ce qui est du SQL habituel , INSERT, UPDATE, DELETE, vous alliez le trouver tout seul :
$stmt=sprintf «INSERT INTO mytable ( col1,col2,col3) VALUES (?,?,? )» ;
$sth = $dbh->prepare($stmt);
$sth->execute($val1,$val2,$val3) ;
Vous verrez au passage que l’utilisation des placeholders est extrêmement simple, puisqu’il suffit d’en mettre les valeurs entre parenthèses lors de l’execute.
Pour consolider l’utilisation des placeholders, voici un exemple avec UPDATE
$stmt=sprintf «UPDATE mytable SET (col2,col3) = (?,?) WHERE col1=?» ;
$sth = $dbh->prepare($stmt);
$sth->execute($val2,$val3,$val1) ;
Les transactions? Très simple:
$dbh->commit;
$dbh->rollback;
A moins que vous ne désiriez simuler le mode ANSI, en ouvrant la connexion de cette manière, le comportement de vos transaction est identique à celui dont vous avez l’habitude.
$dbh = DBI->connect("dbi:Informix:$databasename",$username,$password,
{ AutoCommit => 1});
Et mon CURSOR WITH HOLD ?
Trivial, il suffit de le passer comme argument lors du PREPARE, comme ceci :
$sth = $dbh->prepare("SELECT col1,col2 FROM mytable",{'ix_CursorWithHold' => 1});
Et les BLOBS ?
Soyons francs : l’implémentation des BLOBS n’est pour l’instant pas aussi riche qu’avec ESQL/C, mais on s’en approche.
Pour le type TEXT, ou tout autre BLOBS dont le contenu peut être mis dans une variable Perl, on utilisera le bind de paramètres, comme ce qui suit :
$textlocation = sprint “/home/informix/textfiles/file1.txt” ;
fopen TEXT,$textlocation or die “Cannot open file “ . $texlocation ;
@FileContents=<TEXT>;
$text_val = join ( @FileContents ) ;
$pkey = 13452 ;
$timestamp = «2011-12-28 15:00:00» ;
$stmt = sprint “INSERT mytable VALUES (?,?,?)” ;
$sth = $dbh->prepare($stmt);
$sth->bind_param(1, $pkey);
$sth->bind_param(2, $timestamp ) ;
$sth->bind_param(3, $text_val, { ix_type => IX_TEXT });
$sth->execute;
Pour la lecture des blobs, ceux-ci sont mappés dans une variable Perl de type string. On peut toutefois procéder à un LOCATE, de la façon suivante :
$sth->{ix_BlobLocation} = 'InMemory'; # Comportement par défaut
$sth->{ix_BlobLocation} = 'InFile'; # dans un fichier dont le nom est rendu
$sth->{ix_BlobLocation} = 'DummyValue'; # retourne <text> ou <byte>
$sth->{ix_BlobLocation} = 'NullValue'; # retourne valeur indéfinie
Les SMARTBLOBS ne sont pas (encore ?) supportés directement, MAIS on peut les manipuler avec les fonctions LOTFILE pour lire, FILETOBLB ou FILETOCLOB pour écrire.
Pour insérer:
$stmt = qq!INSERT INTO item2 VALUES (1234,'Desk', FILETOBLOB('image.bmp','client'))!;
$sth = $dbh->prepare($stmt);
$sth->execute();
Pour lire:
$stmt = qq!SELECT LOTOFILE(myimage, ?,'client') FROM mytable!;
$sth = $dbh->prepare($stmt);
$sth->execute($imagefilename) ;
$sth->bind_columns($Image));
while($sth->fetch) {
print $Image;
…..
}
Alors finalement, quel est l’intérêt d’utiliser Perl avec DBD::Informix ?
En conclusion, nous pourrions continuer longtemps comme cela, mais le réveillon approche et la concentration commence à s’évaporer.
Pour un DBA Informix, cette combinaison permet de développer des scripts beaucoup plus puissants en terme de fonctionnalités, notamment pour les facilités de programmation système « abordables » qu’il offre. Les objets comme les tableaux, les tableaux de hachage, les expressions régulières et surtout l’immense bibliothèque de modules traitant de pratiquement tout ce qui peut se faire, confèrent au développeur une puissance que le shell n’atteindra jamais.
Il permet également de rationaliser les scripts d’administration, de les rendre beaucoup plus lisibles et simples à maintenir. Enfin, argument non négligeable, Perl offre une grande portabilité de vos développements approchant des 100%, pour autant que l’on n’utilise pas de syntaxe spécifique à chaque OS. Un script fonctionnant sur Linux fonctionnera sans mauvaises surprises sur AIX, hp-ux, Solaris, Mac OS X et même Windows !
La cerise sur le gâteau est la possibilité d’accéder en mode natif à vos bases de données Informix comme le fait Informix 4GL, ESQL/C ou java. A partir de ce point s’ouvrent des perspectives de développements encore plus vastes, comme parser et intégrer des documents Microsoft Office dans une base de données Informix, typifier et classer des images dans une base Informix, mais aussi aller fouiller dans vos favoris et historique de Mozilla Firefox, en les intégrant dans une base de données Informix. De façon plus générale vous pouvez envisager de développer très rapidement et à coût très réduit un gateway entre d’autres bases de données et votre base de données préférée, par exemple !
Des exemples concrets sont disponibles sur mon autre blog www.vercelletto.com , ainsi que sur le site de l'UGIF www.informix.fr .
N'hésitez pas à les télécharger et à les utiliser.
En attendant, et pendant que vous réflechissez à tout cela, je vous souhaite plein de bonnes choses pour l’année 2012 !
A lire :
le document de référence de Jonathan Leffler:
http://search.cpan.org/~johnl/DBD-Informix-2011.0612/Informix.pm
sa présentation à la conférence IIUG 2001:
Chez O’reilly:
- Programming perl DBI by Alligator Descartes and Time Bunce,
- Learning Perl, by Tom Phoenix, Randal L. Schwartz
- La doc Perl en français: http://perl.enstimac.fr/DocFr.html
- Rechercher dans la bibliothèque CPAN : http://search.cpan.org/
- Et toute une foule de turoriels perl sur le net
En tant que DBA émérite, vous avez développé à coup sûr un certain nombre de scripts en command shell. Ce langage est très pratique et versatile pour assurer vos tâches d’administration IBM Informix Dynamic Server. En le combinant avec les commandes habituelles comme onmode, onstat, oncheck, onparams et autres, vous avez mis en place toute une gamme de scripts qui vous permettent de gérer automatiquement vos sauvegardes, l’exécution des UPDATE STATISTICS, la gestion de certaines alarmes, le démarrage-arrêt de vos instances, ainsi que la connexion auxdites instances. Vous avez probablement ajouté des scripts de monitoring basés sur onstat et oncheck.
Mais soyons sincères, quand nous relisons ces scripts pour les maintenir, ou pire quand nous devons modifier un script écrit par quelqu’un d’autre, le niveau de complexité de l’écriture est très souvent inversement proportionnel à la facilité de lecture. Il est vrai qu’après le 7ème niveau d’imbrication de « pipe », on ne sait plus trop où l’on est arrivé.
En fait, si le shell unix comprend un très grand nombre de commandes extrêmement utiles et pertinentes, le ciment ( matérialisé généralement le « pipe », assorti de ls, grep, awk, cat, echo et expr ) qui les unit pour en faire de véritables applications est loin d’être simple à comprendre et encore moins simple à débugger. De plus, si vous devez installer ces scripts sur un autre parfum d’Unix, tout se complique car une foule de commandes soit ne réagissent pas de la même manière, soit produisent directement des erreurs de syntaxe. Je n’évoque même pas le scénario catastrophe du déploiement d’une instance sous Windows ou Mc Intosh, qui font désormais partie des plateformes habituelles de IBM Informix, où vous devrez probablement tout réécrire…
Vous l’avez sous les yeux, et il en fait des choses!
C’est vrai, le shell Unix répond efficacement aux besoins immédiats quand il faut obtenir rapidement un résultat, cependant trop de problèmes de compatibilité, performance et facilité de maintenance viennent impacter négativement l’industrialisation de ces fonctionnalités d’administration. Je commençais à mesurer la véritable portée de ce problème quand, en 1997, un ami m’a recommandé de regarder de près le langage Perl ( Practical Extraction Report Langage).
Il a tout d’un grand
Au-delà du rôle originel de Perl qui est le parsing de texte, j’ai très rapidement compris que j’avais entre les mains un véritable langage de développement qui combinait les attributs d’un langage évolué comme C, les utilitaires awk et sed, incluant la majorité des commandes du shell. Gérant les variables scalaires, tableaux, hash, visibilité des variables, opérateurs binaires, unaires, logiques, blocs d’ordres, gestion de fonctions avec passage et réception de paramètres par référence ou non, un système de gestion d’entrées-sorties très proche du système et enfin les très puissantes expressions régulières, on sent fortement le lien de parenté avec C, mais tout cela reste malgré tout beaucoup plus facile et rapide à coder et à lire ( adieu aussi les core dumped !)
Même pas peur !
Vous disposez également d’un très bon debugger interactif ( adieu les « set –x » oubliés dans le code !). Au sujet performance, Perl n’a pas la rapidité de C puisque les modules ne sont pas compilés, mais reste cependant très honorable ( Ex 2 sec. pour lire entièrement un fichier de 32 Mb/640 000 lignes).
Mais quel est le véritable intérêt par rapport au shell ?
Perl peut déjà faire tout ce que le shell peut faire, mais de façon beaucoup plus simple. Finies les contorsions et galipettes entre cat, awk, sort ,grep ls, read etc… ! Avec Perl, le code va directement au but recherché.
Par contre, Perl sait faire des choses que le shell ne sait pas faire, notamment dans le domaine de la programmation-système. Par exemple, il est simple de gérer la communication entre processes via les IPC, gérer des files de messages In/Out et autres friandises du genre.
Il se sent bien partout
Un autre avantage de Perl réside dans sa portabilité. Dans la mesure où vous n’incluez pas dans vos programmes Perl des commandes shell spécifiques à telle ou telle plateforme, votre programme Perl fonctionnera à l’identique sur des plateformes différentes, que ce soit sur n’importe quel Unix, Windows ou Mac Intosh, pour ce qui nous intéresse.
Mais l’argument de poids est la richesse de la librairie de modules disponible gratuitement pour la communauté. Ces modules couvrent les fonctionnalités les plus diverses et variées, allant d’extrêmement utiles à plus anecdotiques. Des fonctionnalités indispensables comme une fonction qui traduit n’importe quelle date en format caractère ( ex « lun. Déc 26 17 :45 :14 2011 CET » ) en un nombre entier de type « epoch », permettant en autres de calculer des intervalles entre deux timestamps (Time ::¨ParseDate, utile quand on parse un fichier log par exemple), ou bien obtenir toutes les propriétés d’un fichier ( stat ), ou bien lire et se déplacer dans un fichier en mode binaire ( IO ::Handle ), mais aussi lire les propriétés d’une image (Image::ExifTool ), et la très puissante Win32::OLE qui permet d’accéder en lecture ou écriture à pratiquement tous les objets Microsoft comme boite email Outlook, documents Word, Excel etc...
Dans cette foule de modules, il en existe un qui nous intéresse particulièrement : DBD::Informix. Vous l’avez compris, ce module est le module de communication avec les bases de données IBM Informix. Développé et maintenu par un Informixien de longue date, et maintenant vénérable IBMer barbu, ce module contient toutes les fonctionnalités nécessaires à pouvoir utiliser le langage SQL pratiquement comme avec Esql/C, Informix 4GL ou dbaccess, dans vos applications Perl.
On essaye ?
Pour des raisons que vous imaginez sans doute, le module DBD:Informix ne fait pas partie des packages de base généralement livrés avec Perl ( pas plus que le module du « Evil Empire kind of database » d'ailleurs ). Il faudra aller le chercher sur CPAN, l'immense répositoire de packages Perl. Après avoir « éprouvé quelque difficulté » avec la version précédente de l'installation, il suffit de savoir comment faire et l'installation se fait sans sueur ni larmes.
Les prérequis obligatoires:
- avoir Perl version supérieure ou égale à 5.14 pour être en totale conformité,
- avoir esql/C > 7.31 ou mieux Informix CSDK 3,X ( généralement inclus dans IDS à partir de la version 10.00 )
- avoir un moteur Informix ou IBM Informix ( SE ou IDS ) « on-line »
- avoir créé la base de démonstration stores
- avoir créé l'utilisateur informix
- une connexion internet en état de marche,
- Sans problème sous Linux, et à ma connaissance sous les autres plateformes Unix, plus délicat pour l'instant sur plateforme Windows, mais affaire à suivre...
Avant de lancer l’installation, vous devez, sous l’utilisateur root, pouvoir vous connecter à la base stores avec dbaccess, donc avoir les variables d’environnement $INFORMIXDIR, $INFORMIXSERVER et $PATH correctement valorisées. Vous devez également pouvoir exécuter un binaire esql/c, donc avoir la variable $LD_LIBRARY_PATH ( linux , AIX) ou $LIBPATH ( solaris etc ) valorisée à « $INFORMIXDIR/lib :$INFORMIXDIR/lib/esql :$INFORMIXDIR/lib/tools »
Une fois ces test préliminaires accomplis, vous pouvez taper :
perl -MCPAN -e 'install Bundle::DBD::Informix'
Laissez ensuite le système ( l’outil CPAN ) gérer l'affaire. Dans la mesure où les prérequis sont respectés, l'installation se fait sans aucune anicroche. Par contre, en cas d'oubli, les messages d'erreur sont quelque peu démotivants. Il suffit alors de remédier aux prérequis manquants et relancer la commande citée plus haut. Perl CPAN reprendra l'installation là où il s'était arrêté.
Quelques messages d'erreur peuvent apparaître en cours de route. Tant que l'installation ne s'arrête pas, tout va bien. L'installation se termine par « /usr/bin/make install -- OK ».
A la vue de ce message, vous êtes prêt à utiliser le module DBD::Informix. Une petite vérification par un find /usr –name Informix.pm, pour vous assurer que vous avez bien Informix.pm quelque part dans /usr…lib64 … /DBD/Informix.pm.
Vous pourrez aussi le trouver dans ~root/.cpan/build/DBD-Informix-2011.0612-*, qui est la directory d’installation, mais il doit être absolument dans /usr/…libXX.
Installation OK! voyons les rudiments.
Pour pouvoir utiliser DBD::Informix, il faut l’inclure dans le programme Perl, en notant en tête du module :
use DBD::Informix qw(:ix_types) ;
Pour se connecter à une base :
$dbh=DBI-connect(« dbi:Informix:$databasename »,$username,$password) ;
Pour préparer un SELECT :
$stmt=sprintf «SELECT col1,col2,col3,col4 FROM mytable ORDER BY col2» ;
$sth = $dbh->prepare($stmt);
$sth->execute() ;
Pour lire le curseur, et afficher le contenu :
$sqlcode=0;
while ( $sqlcode != 100 ) {
($var1,$var2,$var3,$var4) = $sth->fetchrow_array() ;
printf “%s %s %s %d\n”,$var1,$var2,$var3,$var4 ;
$sqlcode=$sth->{ix_sqlcode};
}
Mais vous pouvez également remplir un array contenant le résultat complet du curseur, pour le traiter ensuite en mémoire comme une structure organisée à l’image de la table, à l’image du RECORD LIKE d’Informix 4GL :
$array_ref = $sth->fetchall_arrayref ( {col1=>1,col2=>1,col3=>1,col4=>1}) ;
foreach $row ( @$array_ref ) {
printf “%s %s %s %d\n”,$row->{col1},$row->{col2},$row->{col3},
$row->{col4} ;
}
Pour ce qui est du SQL habituel , INSERT, UPDATE, DELETE, vous alliez le trouver tout seul :
$stmt=sprintf «INSERT INTO mytable ( col1,col2,col3) VALUES (?,?,? )» ;
$sth = $dbh->prepare($stmt);
$sth->execute($val1,$val2,$val3) ;
Vous verrez au passage que l’utilisation des placeholders est extrêmement simple, puisqu’il suffit d’en mettre les valeurs entre parenthèses lors de l’execute.
Pour consolider l’utilisation des placeholders, voici un exemple avec UPDATE
$stmt=sprintf «UPDATE mytable SET (col2,col3) = (?,?) WHERE col1=?» ;
$sth = $dbh->prepare($stmt);
$sth->execute($val2,$val3,$val1) ;
Les transactions? Très simple:
$dbh->commit;
$dbh->rollback;
A moins que vous ne désiriez simuler le mode ANSI, en ouvrant la connexion de cette manière, le comportement de vos transaction est identique à celui dont vous avez l’habitude.
$dbh = DBI->connect("dbi:Informix:$databasename",$username,$password,
{ AutoCommit => 1});
Et mon CURSOR WITH HOLD ?
Trivial, il suffit de le passer comme argument lors du PREPARE, comme ceci :
$sth = $dbh->prepare("SELECT col1,col2 FROM mytable",{'ix_CursorWithHold' => 1});
Et les BLOBS ?
Soyons francs : l’implémentation des BLOBS n’est pour l’instant pas aussi riche qu’avec ESQL/C, mais on s’en approche.
Pour le type TEXT, ou tout autre BLOBS dont le contenu peut être mis dans une variable Perl, on utilisera le bind de paramètres, comme ce qui suit :
$textlocation = sprint “/home/informix/textfiles/file1.txt” ;
fopen TEXT,$textlocation or die “Cannot open file “ . $texlocation ;
@FileContents=<TEXT>;
$text_val = join ( @FileContents ) ;
$pkey = 13452 ;
$timestamp = «2011-12-28 15:00:00» ;
$stmt = sprint “INSERT mytable VALUES (?,?,?)” ;
$sth = $dbh->prepare($stmt);
$sth->bind_param(1, $pkey);
$sth->bind_param(2, $timestamp ) ;
$sth->bind_param(3, $text_val, { ix_type => IX_TEXT });
$sth->execute;
Pour la lecture des blobs, ceux-ci sont mappés dans une variable Perl de type string. On peut toutefois procéder à un LOCATE, de la façon suivante :
$sth->{ix_BlobLocation} = 'InMemory'; # Comportement par défaut
$sth->{ix_BlobLocation} = 'InFile'; # dans un fichier dont le nom est rendu
$sth->{ix_BlobLocation} = 'DummyValue'; # retourne <text> ou <byte>
$sth->{ix_BlobLocation} = 'NullValue'; # retourne valeur indéfinie
Les SMARTBLOBS ne sont pas (encore ?) supportés directement, MAIS on peut les manipuler avec les fonctions LOTFILE pour lire, FILETOBLB ou FILETOCLOB pour écrire.
Pour insérer:
$stmt = qq!INSERT INTO item2 VALUES (1234,'Desk', FILETOBLOB('image.bmp','client'))!;
$sth = $dbh->prepare($stmt);
$sth->execute();
Pour lire:
$stmt = qq!SELECT LOTOFILE(myimage, ?,'client') FROM mytable!;
$sth = $dbh->prepare($stmt);
$sth->execute($imagefilename) ;
$sth->bind_columns($Image));
while($sth->fetch) {
print $Image;
…..
}
Alors finalement, quel est l’intérêt d’utiliser Perl avec DBD::Informix ?
En conclusion, nous pourrions continuer longtemps comme cela, mais le réveillon approche et la concentration commence à s’évaporer.
Pour un DBA Informix, cette combinaison permet de développer des scripts beaucoup plus puissants en terme de fonctionnalités, notamment pour les facilités de programmation système « abordables » qu’il offre. Les objets comme les tableaux, les tableaux de hachage, les expressions régulières et surtout l’immense bibliothèque de modules traitant de pratiquement tout ce qui peut se faire, confèrent au développeur une puissance que le shell n’atteindra jamais.
Il permet également de rationaliser les scripts d’administration, de les rendre beaucoup plus lisibles et simples à maintenir. Enfin, argument non négligeable, Perl offre une grande portabilité de vos développements approchant des 100%, pour autant que l’on n’utilise pas de syntaxe spécifique à chaque OS. Un script fonctionnant sur Linux fonctionnera sans mauvaises surprises sur AIX, hp-ux, Solaris, Mac OS X et même Windows !
La cerise sur le gâteau est la possibilité d’accéder en mode natif à vos bases de données Informix comme le fait Informix 4GL, ESQL/C ou java. A partir de ce point s’ouvrent des perspectives de développements encore plus vastes, comme parser et intégrer des documents Microsoft Office dans une base de données Informix, typifier et classer des images dans une base Informix, mais aussi aller fouiller dans vos favoris et historique de Mozilla Firefox, en les intégrant dans une base de données Informix. De façon plus générale vous pouvez envisager de développer très rapidement et à coût très réduit un gateway entre d’autres bases de données et votre base de données préférée, par exemple !
Des exemples concrets sont disponibles sur mon autre blog www.vercelletto.com , ainsi que sur le site de l'UGIF www.informix.fr .
N'hésitez pas à les télécharger et à les utiliser.
En attendant, et pendant que vous réflechissez à tout cela, je vous souhaite plein de bonnes choses pour l’année 2012 !
A lire :
le document de référence de Jonathan Leffler:
http://search.cpan.org/~johnl/DBD-Informix-2011.0612/Informix.pm
sa présentation à la conférence IIUG 2001:
http://www.ibdk.dk/seminar/DBD-Informix-20010508.ppt
Chez O’reilly:
- Programming perl DBI by Alligator Descartes and Time Bunce,
- Learning Perl, by Tom Phoenix, Randal L. Schwartz
- Programming Perl, by Larry Wall ( l'inventeur de Perl), Tom Christiansen, Jon Orwant
- Perl advanced Programming, By Simon Cozens
- Perl for System Administration by David Blank-Edelman - La doc Perl en français: http://perl.enstimac.fr/DocFr.html
- Rechercher dans la bibliothèque CPAN : http://search.cpan.org/
- Et toute une foule de turoriels perl sur le net
vendredi 9 décembre 2011
Bon anniversaire le village Informix
Bonjour à tous,
eh oui, 1 an déjà! c'est avec émotion que le premier anniversaire du Village Informix a vu le même jour son compteur d'accès passer les 5000 visites! Une goutte d'eau face à d'autres sites consacrés à l'Empire du Mal ( dont le nom se compose de O....e ), ou à d'autres rouleaux compresseurs, mais cela prouve aussi un regain d'intérêt pour cette technologie qui nous tient tous à coeur, dans nos terres francophones et gaulophones.
Nous en profitons pour saluer nos cousins Helvètes, Belges, Africains et Canadiens qui n'hésitent pas à braver montagnes, océans ou péages de voies romaines pour venir nous visiter.
Nous en profitons pour saluer nos cousins Helvètes, Belges, Africains et Canadiens qui n'hésitent pas à braver montagnes, océans ou péages de voies romaines pour venir nous visiter.
En tous cas merci à tous de vous arrêter chez nous, en espérant que vous y trouvez votre compte.
N'oubliez pas dans vos tablettes Mercredi 14 et Jeudi 15, la réunion de l'UGIF chez IBM à Bois Colombes.
Et si nous ne nous croisons pas d'ici là, nous vous souhaitons de belles fêtes de fin d'année.
N'oubliez pas dans vos tablettes Mercredi 14 et Jeudi 15, la réunion de l'UGIF chez IBM à Bois Colombes.
Et si nous ne nous croisons pas d'ici là, nous vous souhaitons de belles fêtes de fin d'année.
A bientôt,
mardi 29 novembre 2011
réunion de l'UGIF le 14 et 15 décembre
Bonjour à tous,
Le User Group Informix France (UGIF) se réunira le 14 décembre prochain au Forum IBM de Bois Colombes*.
Après la sortie de Informix Warehouse Accelerator et de GENERO au mois d’avril dernier, Informix avec son module Time Series est devenu la solution unique et incontournable du marché dans le domaine de la gestion des compteurs intelligents dans le domaine des donnés temporelles comme les compteurs électriques, l’eau, le gaz, les marchés financiers, la médecine, etc.
Venez découvrir une démonstration temps réel du Data Warehouse par le patron R&D du produit en personne.
L'agenda de la journée est le suivant :
Nous conclurons l'après-midi entre 16 heures 15 et 16 heures 45 par un dernier tour de table, animé par Khaled Bentebal. Ceci vous permettra de dialoguer directement avec les intervenants de la journée.
Toutes les sessions techniques de l'après-midi de l'événement de l'UGIF le 14 décembre seront totalement gratuites.
Inscrivez vous vite en envoyant un simple mail de confirmation à notre correspondant technique IBM :
Fabrizio Danusso : fabrizio.danusso@fr.ibm.com
ou
Khaled BENTEBAL : khaled.bentebal@consult-ix.fr
* Plan d'accès : http://www-05.ibm.com/fr/ibmforum/Plan_acces_IBM_Forum_BC.pdf
A noter le Proof of Technology le 15 décembre sur Informix Warehouse Accelerator, que je reconseille vivement!
A bientôt
Le User Group Informix France (UGIF) se réunira le 14 décembre prochain au Forum IBM de Bois Colombes*.
Après la sortie de Informix Warehouse Accelerator et de GENERO au mois d’avril dernier, Informix avec son module Time Series est devenu la solution unique et incontournable du marché dans le domaine de la gestion des compteurs intelligents dans le domaine des donnés temporelles comme les compteurs électriques, l’eau, le gaz, les marchés financiers, la médecine, etc.
Venez découvrir une démonstration temps réel du Data Warehouse par le patron R&D du produit en personne.
L'agenda de la journée est le suivant :
9h00 - 9h15
|
Accueil
|
||
9h30 - 9h40
|
Introduction
|
Khaled Bentebal
|
Président UGIF
|
9h40 - 9h55
|
Information management et importance d'Informix dans
l’offre IBM
|
Matthieu Maurice
|
Directeur Information Management - IBM
|
9h55-10h30
|
Informix et la stratégie au sein de l’offre IBM
|
Jerry Keesee
|
WW Director
Informix Software - IBM
|
10h30 – 11H15
|
Nouvelles directions stratégiques: Time Series...
|
Jacques Roy
|
Manager et Architecte IDS Application Development Services
- IBM
|
11H15 – 11h45
|
Pause café
|
||
11h45 – 12h30
|
Informix Warehouse
|
Sandor Szabo
|
Manager IBM Informix Database Development - IBM
|
12h30 - 13h00
|
Genero : Stratégie et Roadmap
|
Bryn Jenkins
|
COO – Four Js Developement
|
13h00 - 14h30
|
Déjeuner
|
||
14h00 - 14h45
|
Session technique : Timeseries
|
Jacques Roy
|
Manager et Architecte IDS Application Development Services
- IBM
|
14h00 - 14h45
|
GENERO
|
Christian Geyer
|
Senior System Engineer chez Four J's Development Tools
|
14H45 – 15h15
|
Pause
|
||
15h15 - 16h00
|
Informix Warehouse Accelerator
|
Sandor Szabo
|
Manager IBM Informix Database Development - IBM
|
15h15 - 16h00
|
Session technique : Informix V11.70
|
Olivier Bourdin
|
EMEA
Informix L3 Advanced Support - IBM
|
16h15 - 16h45
|
Conclusion
|
Khaled Bentebal
|
|
Nous conclurons l'après-midi entre 16 heures 15 et 16 heures 45 par un dernier tour de table, animé par Khaled Bentebal. Ceci vous permettra de dialoguer directement avec les intervenants de la journée.
Toutes les sessions techniques de l'après-midi de l'événement de l'UGIF le 14 décembre seront totalement gratuites.
Inscrivez vous vite en envoyant un simple mail de confirmation à notre correspondant technique IBM :
Fabrizio Danusso : fabrizio.danusso@fr.ibm.com
ou
Khaled BENTEBAL : khaled.bentebal@consult-ix.fr
* Plan d'accès : http://www-05.ibm.com/fr/ibmforum/Plan_acces_IBM_Forum_BC.pdf
A noter le Proof of Technology le 15 décembre sur Informix Warehouse Accelerator, que je reconseille vivement!
A bientôt
mardi 15 novembre 2011
La version 11.70 xC4 est sortie et disponible
Bonjour à tous,
IBM annonce la sortie de Informix Dynamic Server version 11.70 xC4. Elle est disponible depuis le 25 octobre 2011 sur les canaux habituels.
Que faut-il retenir principalement de cette release?
- l'emphase sur TimeSeries continue, des nombreuses améliorations et nouveautés sont apportés sur le datablade, qui rappelons-le est sorti en 1998...
- apparition du "Open Admin Tools Health Advisorplugin": une nouvelle fonctionnalité de OAT dont le but est d'observer les métriques de santé de l'instance et de vous prévenir en cas de non-conformité/problème. Ces vérifications sont planifiables dans le temps, et rangées par catégories.
- OAT est maintenant inclus dans la distribution du Client Software Development Kit ( CSDK), ce qui facilite énormément son installation.
- un nouvel ensemble de paramètres ONCONFIG peut désormais être modifié "on the fly", c'est-à-dire sans devoir arrêter et démarrer l'instance. La liste s'allonge avec les paramètres suivants: WSTATS, AUTO_REPREPARE, CKPTINTVL, DIRECTIVES, OPTCOMPIND, SHMADD, qui peuvent désormais être modifiés avec la commande onmode -wm. L'objectif final étant le "zero downtime", cette liste devrait encore s'allonger dans la prochaine release
- améliorations dans les algorithmes de creation des statistiques, spécialement dans la technique d'échantillonnage pour les très grosses tables/index.
- rajout de colonnes indiquant la progression d'une opération de compression de table, ainsi que la date/heure estimé de fin d'opération
- améliorations sur la réplication: rapidité de démarrage du Connection Manager, rapidité de la vérification de consistance, facilité d'exploitation des alarmes du Connection Manager, détection de fausses situations de failover vers le Primary empêchant un basculement inopportun, amélioration de la gestion de la sécurité avec la réplication.
- améliorations dans la gestion du Global Security Kit: plus de souplesse dans le paramètrage
La release embarque plein d'autres améliorations, ainsi que des bug fixes ( eh: oui ça existe aussi!). Je vous invite donc à aller voir la release note sur le site IBM
Pour un SGBD dont les mauvaises langues ( jaloux!) disent qu'il fait partie du passé et qu'il n'est même plus maintenu, je trouve quand-même que ça fait beaucoup d'améliorations depuis la sortie de la 11.70 il y a un an:
- Nov 2010: sortie de 11.70 xC1
- mars 2011: sortie de 11.70 xC2
- juin 2011: sortie de 11.70 xC3
- octobre 2011: sortie de 11.70 xC4
Enfin! ceci est une autre histoire :-)
A bientôt
vendredi 11 novembre 2011
La technologie IBM Informix reconnue par le géant Cisco
Bonjour à tous,
nous venons d'apprendre qu'IBM Informix s'est vu décerner un "Software Excellence Recognition" par la compagnie Cisco Inc., le géant de l'industrie du réseau et de la téléphonie.
Pourquoi? Parce que Cisco travaille depuis de nombreuses années, dans la branche téléphonie, avec IBM Informix Dynamic Server embarqué dans ses téléphones, et que ça marche.
Bien que Cisco ait, il y a quelque temps, effectué une réévaluation de toutes les autres plateformes SGBD, ( il est toujours bon de se poser les bonnes questions ) ils ont confirmé le choix de IDS 11.70 comme SGBD pour leurs systèmes téléphoniques. Leurs critères étaient simples: simplicité d'administration, fiabilité, performance et facilité de déploiement.
Donc ils sont contents, et ils le disent et ils n'en ont pas peur!
Allez voir la page IBM Informix sur Facebook
A propos de téléphones, saviez-vous que le système téléphonique de l'avion présidentiel américain 'Air Force One', se repose sur Informix Dynamic Server ?
Il en est de même pour le système téléphonique de la Maison Blanche à Washington, ainsi que le fameux '911' américain, qui est le système national des appels d'urgence.
Il en est de même pour le système téléphonique de la Maison Blanche à Washington, ainsi que le fameux '911' américain, qui est le système national des appels d'urgence.
Des systèmes qui ne peuvent pas se permettre une quelconque panne sous peine de conséquences catastrophiques...
A bientôt!
mercredi 9 novembre 2011
Informix Warehouse Accelerator désormais disponible avec la Growth Edition
Bonjour à tous,
Vous avez vraisemblablement entendu parler de IBM Informix Ultimate Warehouse Edition, cet "add-on" révolutionnaire basé sur la combinaison des technologies de base de données colonnaire, de compression de données et de "tout en mémoire", dont la fonction est de réduire plus que drastiquement les temps de réponse dans un contexte décisionnel, infocentre ou data warehouse, suivant le terme qui vous convient le mieux.
Nous avions décrit les grandes lignes de IWA ( Informix Warehouse Accelerator) dans cet article il y a quelques mois. Il est vrai que les résultats obtenus font rêver. Cependant, le problème majeur était plus d'ordre budgétaire, dans la mesure où l'on était obligé de l'installer sur une Ultimate Edition.
Répondant aux architectures de haut de gamme, le pricing de l'édition Ultimate n'est pas adapté aux environnements de moindre taille, privant par là-même ces environnements d'utiliser Informix Warehouse Accelerator.
IBM a décidé de combler ce vide en créant désormais une nouvelle édition: Informix Growth Warehouse Edition. Avec un pricing beaucoup plus accessible et surtout adapté à une grande partie de la base installée IBM Informix Dynamic Server, cette édition permet donc, comme le fait sa grande soeur Ultimate Warehouse Edition, d'intégrer les données d'infocentre dans un serveur Linux 64Bits et traiter les requêtes avec des temps de réponses qui ressemblent plus à un mensonge qu'à la vérité.
Et pourtant! les résultats sont bien là: une campagne de benchmarks chez des clients existants montre des résultats fulgurants, comme par exemple:
L'Accelerator s'installe en général sur un autre serveur physique que l'instance OLTP. C'est un serveur Linux, donc à priori x86, sans gros besoins en disque ( les données proviennent de l'instance OLTP et sont directement chargées en mémoire ), et le poste important du chiffrage est la RAM. En règle générale, un serveur pour Informix Warehouse Accelerator se chiffre nettement en dessous des 10.000 Euros ( pour la Growth Edition ).
L'Accelerator est une extension logique du moteur Informix, effectuant le travail de requêtes sur un autre serveur physique faisant partie de la même entité de traitement. l'avantage est donc d'exécuter les requêtes décisionnelles les plus lourdes sans impacter aucunement votre instance OLTP.
C'est l'optimiseur Informix qui décide qui, entre le serveur OLTP ou l'Accelator, exécute la requête. Ceci implique qu'il n'y a aucune modification à apporter à vos applications décisionnelles, donc des économies en termes de projets.
Il n'ya a pas de duplication de données, ne demandant ni beaucoup d'espace disque supplémentaire, ni d'administration lourde d'un autre système.
Informix Warehouse Accelerator ne se "tune" pratiquement pas. Il ne constitue pas une charge supplémentaire pour les DBA, contrairement à d'autres systèmes à fonctionnalité similaire
Le coût d'administration se limite à la gestion des datamarts ( conception, chargement) avec l'interface graphique très bien conçu IBM Smart Analytics Studio.
En conclusion, Informix Warehouse Accelerator vous permettra de faire cohabiter votre charge transactionnelle et votre charge décisionnelle sans problèmes de voisinage ni surcoût d'administration, et qui divisera suivant les cas par 10,100 et parfois plus, les temps de réponses sur vos requêtes d'infocentre.
Dans ces conditions, il est parfaitement envisable de considérer une utilisation toute autre de vos requêtes OLAP:
Si une requête répond en 4 secondes au lieu de 20 minutes, vous pouvez utiliser le temps économisé pour lancer d'autres requêtes auxquelles vous n'auriez même pas pensé, faute de temps.
Par ailleurs, une requête qui répond en quatre heures peut être exécutées au maximum 6 fois par jour. Dans les faits, elle ne sera d'ailleurs lancée qu'une fois par jour, au cas où... Par contre si la requête répond en 5 minutes, la donne est radicalement différente: elle peut être planifiée avec une fréquence beaucoup plus élevée dans la journée, et contribuera à l'amélioration drastique de la réactivité de votre infocentre. Réagir vite pour corriger vite.
Bien sûr ces faits valent aussi pour IBM Informix Ultimate Edition que pour la Growth Edition.
Tout ceci pique votre curiosité? Eh bien lancez-vous et venez au PoT Deep Drive on IWA and Informix Data Warehouse dans les locaux de IBM Forum Paris, le 15 décembre prochain. Ce "Proof of technology" comportera une présentation du produit ainsi que des exercices pratiques qui vous feront voir la technologie de près.
Renseignements et inscriptions ici
A bientôt
Vous avez vraisemblablement entendu parler de IBM Informix Ultimate Warehouse Edition, cet "add-on" révolutionnaire basé sur la combinaison des technologies de base de données colonnaire, de compression de données et de "tout en mémoire", dont la fonction est de réduire plus que drastiquement les temps de réponse dans un contexte décisionnel, infocentre ou data warehouse, suivant le terme qui vous convient le mieux.
Nous avions décrit les grandes lignes de IWA ( Informix Warehouse Accelerator) dans cet article il y a quelques mois. Il est vrai que les résultats obtenus font rêver. Cependant, le problème majeur était plus d'ordre budgétaire, dans la mesure où l'on était obligé de l'installer sur une Ultimate Edition.
Répondant aux architectures de haut de gamme, le pricing de l'édition Ultimate n'est pas adapté aux environnements de moindre taille, privant par là-même ces environnements d'utiliser Informix Warehouse Accelerator.
IBM a décidé de combler ce vide en créant désormais une nouvelle édition: Informix Growth Warehouse Edition. Avec un pricing beaucoup plus accessible et surtout adapté à une grande partie de la base installée IBM Informix Dynamic Server, cette édition permet donc, comme le fait sa grande soeur Ultimate Warehouse Edition, d'intégrer les données d'infocentre dans un serveur Linux 64Bits et traiter les requêtes avec des temps de réponses qui ressemblent plus à un mensonge qu'à la vérité.
Et pourtant! les résultats sont bien là: une campagne de benchmarks chez des clients existants montre des résultats fulgurants, comme par exemple:
- temps sur IDS : 20 minutes, temps avec l'Accelerator: 4 secondes
- temps sur IDS: 105 minutes, avec Accelerator: 9 minutes 48sec.
- temps sur IDS: 106 minutes, avec Accelerator : 20 secondes
- Le serveur Linux hébergeant l'Accélérateur est limité à 16 coeurs,
- l'Accélerator peut être configuré à un maximum de 48 Gb de RAM, ce qui suivant le principe de compression des données, permet de charger jusqu'à 250 Gb de données utiles ( les index sont inutiles pour l'Accelerator, donc ils ne sont pas chargés).
L'Accelerator s'installe en général sur un autre serveur physique que l'instance OLTP. C'est un serveur Linux, donc à priori x86, sans gros besoins en disque ( les données proviennent de l'instance OLTP et sont directement chargées en mémoire ), et le poste important du chiffrage est la RAM. En règle générale, un serveur pour Informix Warehouse Accelerator se chiffre nettement en dessous des 10.000 Euros ( pour la Growth Edition ).
L'Accelerator est une extension logique du moteur Informix, effectuant le travail de requêtes sur un autre serveur physique faisant partie de la même entité de traitement. l'avantage est donc d'exécuter les requêtes décisionnelles les plus lourdes sans impacter aucunement votre instance OLTP.
C'est l'optimiseur Informix qui décide qui, entre le serveur OLTP ou l'Accelator, exécute la requête. Ceci implique qu'il n'y a aucune modification à apporter à vos applications décisionnelles, donc des économies en termes de projets.
Il n'ya a pas de duplication de données, ne demandant ni beaucoup d'espace disque supplémentaire, ni d'administration lourde d'un autre système.
Informix Warehouse Accelerator ne se "tune" pratiquement pas. Il ne constitue pas une charge supplémentaire pour les DBA, contrairement à d'autres systèmes à fonctionnalité similaire
Le coût d'administration se limite à la gestion des datamarts ( conception, chargement) avec l'interface graphique très bien conçu IBM Smart Analytics Studio.
En conclusion, Informix Warehouse Accelerator vous permettra de faire cohabiter votre charge transactionnelle et votre charge décisionnelle sans problèmes de voisinage ni surcoût d'administration, et qui divisera suivant les cas par 10,100 et parfois plus, les temps de réponses sur vos requêtes d'infocentre.
Dans ces conditions, il est parfaitement envisable de considérer une utilisation toute autre de vos requêtes OLAP:
Si une requête répond en 4 secondes au lieu de 20 minutes, vous pouvez utiliser le temps économisé pour lancer d'autres requêtes auxquelles vous n'auriez même pas pensé, faute de temps.
Par ailleurs, une requête qui répond en quatre heures peut être exécutées au maximum 6 fois par jour. Dans les faits, elle ne sera d'ailleurs lancée qu'une fois par jour, au cas où... Par contre si la requête répond en 5 minutes, la donne est radicalement différente: elle peut être planifiée avec une fréquence beaucoup plus élevée dans la journée, et contribuera à l'amélioration drastique de la réactivité de votre infocentre. Réagir vite pour corriger vite.
Bien sûr ces faits valent aussi pour IBM Informix Ultimate Edition que pour la Growth Edition.
Tout ceci pique votre curiosité? Eh bien lancez-vous et venez au PoT Deep Drive on IWA and Informix Data Warehouse dans les locaux de IBM Forum Paris, le 15 décembre prochain. Ce "Proof of technology" comportera une présentation du produit ainsi que des exercices pratiques qui vous feront voir la technologie de près.
Renseignements et inscriptions ici
A bientôt
vendredi 7 octobre 2011
Load et unload sous Informix-4GL: des talents cachés
Bonjour à tous,
une fois n'est pas coutume, aujourd'hui nous allons faire très court. Vous connaissez tous les commandes SQL load et unload, utilisées pour charger et décharger le contenu de/vers une table à partir de/vers un fichier ascii plat et délimité.
Dans la document Informix 4GL, cette commande est qualifiée comme "non préparable", c'est à dire qu'on ne peut pas écrire de choses du genre:
LET statement = "LOAD FROM /tmp/monfichier.unl INSERT INTO matable"
PREPARE monordre FROM statement
EXECUTE monordre
Oui mais... ce qui n'est pas dit dans la documentation, mais qui est quand même supporté et qui marche très bien, c'est la forme suivante:
LET monfichier="/tmp/monfichier.unl"
LET ins_statement = "INSERT INTO matable"
LOAD FROM monfichier ins_statement
Même principe pour unload:
LET monfichier="/tmp/monfichier.unl"
LET sel_statement = "SELECT * FROM matable"
UNLOAD TO monfichier sel_statement
Pas de quoi vous changer la vie, j'admets, mais quand même de quoi rendre bien des services, nommément quand on a besoin d'avoir des load et unload dont la stucture est conditionnée par l'application, ou bien réécrire un simili dbexport en 4GL à partir de la table systables par exemple.
C'est tout :-)
A bientôt
Eric
vendredi 30 septembre 2011
Une alternative sérieuse aux bases de données gratuites
Bonjour à tous,
La rentrée des classes est passée, et malgré le contexte
quelque peu morose, l'activité
redémarre, les budgets IT se concoctent comme bien souvent à cette période
de l'année.
Au vu de la forte tendance à réduire les budgets dans
les départements IT, mais à l'encontre de la tendance "fonctionnelle"
qui a pour effet de générer de plus en plus de projets IT, se pose souvent la
question de la réduction des coûts de licences, notamment en ce qui concerne
les serveurs de bases de données.
Naissance des SGBD « GNU Public License » et assimilés.
Apparus il y a quelques années, et majoritairement issus
de transfuges des grands éditeurs de SGBD, des produits tels que MySql,
PostgreSQL et Sqlite qui évolue dans un autre registre, ont conséquemment
grimpé en popularité, parce que ce sont de bons produits et surtout parce
qu'ils sont gratuits. Le besoin est réel, principalement axé sur projets de
petite à moyenne taille, n'entrant pas dans la catégorie "business
critical", et dont la capacité d'investissement reste volontairement
limitée.
La raison majeure pour un tel choix est la restriction
budgétaire, zéro Euros étant toujours d'une grande aide pour faire des
économies substantielles.
Une autre raison souvent invoquée est clairement
politique: ne plus être empêtrés dans les griffes de ces vilains gros éditeurs et pouvoir faire
ses choix sans devoir courber l'échine ni se soumettre servilement à leur volonté.
Argument fort louable et totalement en phase avec l'air du temps. Mais les
faits correspondent-ils vraiment
Ce qui se montre et ce qui se cache derrière la gratuité
A travers notre prisme, PostgreSql joue véritablement le
jeu de l'open source, n'étant à ce jour dépendant d'aucun "grand éditeur"
qui peut à n'importe quel moment décider soit d'arrêter le produit, soit de le
rendre payant. Il faut l'avouer, le produit est sympa, moderne, plein de
fonctionnalités intéressantes que ce soit au niveau du moteur comme au niveau
de son langage SQL extensible.
Il est par contre un autre SGBD "open source"
faisant partie des 2 principaux SGBD open source, donc "l'autre",
c-a-d MySql, qui ne peut plus prétendre à une telle indépendance. MySql,
autrefois totalement indépendant, a été acquis par Sun Microsystems (
propriétaire à l'époque de Java ), lequel a été à son tour, comme vous le
savez, acquis par un éditeur de Software dont il me coûte encore de prononcer
le nom ( éducation Informixienne où il était interdit de dire des gros mots,
soit en anglais: " the Evil Empire" ).
Peut-on vraiment être rassuré par les intentions de cet
éditeur qui n'hésite à arrêter le portage de son SGBD sur la plateforme HP Itanium, laissant pour
compte toute une partie de sa fidèle clientèle, et briser aabruptement une collaboration
de plus de 20 ans avec ce constructeur ? Et que se passe-t-il si l'éditeur
décide de revenir à ses valeurs fondamentales et de rendre le produit
payant ?
Le système croît au-delà des prévisions : on fait quoi ?
Au delà de ces deux arguments reste un gros problème: il
est reconnu de tous que ces produits sont des produits d'entrée de gamme, et
conçus comme tels. Donc tant que l'on reste "dans les clous", tout le
monde est content.
Mais que se passe-t-il si l'on sort des clous, si la
volumétrie explose, ou bien si le nombre d'utilisateurs dépasse de façon
constante les prévisions initiales ? On se retrouve avec un SGBD qui ne répond
plus au besoin et il faut en changer, c'est à dire passer cette fois-ci à un
SGBD "éditeur".
Solution sans doute facile pour certains décideurs ( il
n'y a qu'à migrer, ce n'est qu'une question de temps et de nombre de
consultants qui se feront un plaisir de relever le défi ), mais le risque
induit est important, et le temps pour "retomber sur ses pattes" n'est
que trop souvent bien supérieur aux estimations initiales, laissant le champ à
de probables mauvaises surprises : revoir le(s) schéma(s) de base,
traduire les types de données, modifier les procédures stockées, les triggers,
les comportements face au niveau d'isolation, au verrouillage, la gestion des
erreurs. Sans oublier l'énoncé des requêtes Sql des 40 000 lignes de cette
petite application.
Bref, je crois que je me fais comprendre : la date
de livraison du projet de migration peut être qualifiée de au mieux de
« potentiellement variable », et quelques grincements de dents sont
dans ce cas à prévoir.
La surprise générale : IBM publie une version gratuite d'IDS.
C'est à ce stade qu'IBM a joué un coup de maître en
Novembre 2010, au moment du lancement de Panther ( la 11.70): contre toute
attente, IBM a publié une version gratuite d'Informix Dynamic Server:
Innovator-C Edition. Contrairement à la
« Developper Edition » qui imposait des restrictions de volume de données,
et surtout une licence destinée exclusivement à l'utilisation dans un
environnement de développement, vous
avez entre les mains une licence d'utilisation
en production, sans restriction de volume de données, si ce n'est celles
de IBM Informix Dynamic Server.
Un produit gratuit, donc c'est un jouet ?
Situons le terrain de jeu. Il existe effectivement une
liste clairement identifiée de fonctionnalités non disponibles, qui peut
éventuellement effrayer le décideur. Cependant, après analyse, nous allons
comprendre qu'il nous reste un excellent produit entre les mains.
Le postulat de départ est que vous avez entre les mains
le même produit que la « Ultimate Edition », mais que certaines
fonctionnalités ont été désactivées.
1) Le volume de données est illimité, vous êtes donc
tributaire de l'espace disque de votre machine. Un de mes serveurs est monté en
11.70FC3, linux 64, avec 3 dbspaces de 1 chunk : 1 de 60 Gb, 1 de 80 Gb et
1 de 100 Gb. Evidemment créer un dbspace de 100Gb prend un peu de temps, mais
ça marche. Je n'ai pas été plus loin faute de place sur la machine.
2) La ressource CPU est limitée à 1 socket avec au
maximum 4 cores ( en français 1 processeur physique avec 4 coeurs). Si l'on parle d'un exemple d'un serveur Intel
based Linux dédié, cela représente quand même pas mal de réserve de puissance,
d'autant que la vitesse d'horloge n'est pas limitée. Vous pourrez alors
affecter sans problème 4 CPU VP's à IDS si le serveur est dédié.
3) La ressource mémoire est effectivement limitée à 2
Gb. Il s'agit là du total de la taille occupée par les BUFFERS de données et de
la SHMVIRTSIZE. Sachant que nous ne disposons malheureusement pas des Parallel
Data Query, les besoins en extension de cette dernière seront limités aux
besoins des opérations de tri, groupe et autres agrégations, qui peuvent être estimés
à 25% de ces 2 Gb. Sincèrement, avec 1,5 Gb de BUFFERS, cela fait de la place
pour quelques bonnes dizaines d'utilisateurs, voire plus.
4) La fonctionnalité PDQ n'est pas utilisable. Au
premier abord, ce manque parait regrettable. Mais si l'on se place dans le
contexte d'une application OLTP, on se console rapidement car cette
fonctionnalité est surtout utile dans un contexte décisionnel. De toutes façons
vu le nombre maximum de cœurs utilisables, il ne serait pas rentable d’en tirer
parti.
Comme l'explique un IBM Informix Champion (*), DBA chez
un très gros client Informix aux Etats-Unis) , ces limitations lui permettent
quand même d'effectuer 4.000.000 de transactions ( commits) par 24heures en
24x24, 7X7, tout en ayant ses CPU à 99% idle la plupart du temps. Je pense qu'à
ce stade on reste dans le champ de ce pour quoi Innovator-C est recommandée et
aussi de notre sujet : les applications départementales.
Si c'est un jouet, alors c'est vraiment un beau jouet !
1) Vous disposez de la fonctionnalité de Enterprise
Replication ( avec un maximum de 2 « root nodes », et pas de
limitation pour les « leaf nodes ».
Il en est de même pour la HDR ( high availability data replication
) : vous disposez d'un couple de serveurs en HDR Primary/ Secondary en read/write.
De quoi garantir la haute disponibilité de votre serveur départemental. Avoir
cette technologie pour ce prix était inespéré.
2) Le produit est livré avec un ensemble confortable de
datablades :
* Spatial apporte les types de données et un ensemble
très complet de méthodes d'accès aux données de géolocalisation, très en vogue
en ce moment
* Basic Text Search : mettez vos données
« ASCII imprimables » dans un clob (character large object, taille
maxi 2Gb) et effectuez des recherches indexées dessus avec un ensemble de
fonctions très utiles et surtout très efficaces.
* Binary : gérez les données opaques binaires
* MQ Series : un ensemble de types de données et
fonctions destinés à la communiquer avec MQ series
* TimeSeries : le buzz du moment. Gestion des
données basées sur le temps, qui pulvérise tous les records de benchmarks (
exemple : gérer la prise de mesure toutes les 15 mn de 100 millions de
compteurs électriques).
* Web Datablade : on ne le présente plus. Permet
d'inclure des appels Sql dans html et aussi diverses méthodes d'accès à XML.
3) le Scheduler
Introduit dans la version 11,70, il agit comme un cron,
mais il est interne au serveur. Couplé avec l'introduction de commandes d'administration exécutables à
partir de dbaccess, un grand nombre de ces opérations peut désormais être
préprogrammées directement dans IDS
4) le Storage Provisionning : gérez de façon
proactive l'allocation d'espace disque. A froid, vous préparez un ensemble de
chunks dans une réserve d’espace disque, et au moment où IDS en a besoin, il va
affecter la ressource au dbspace,blobspace ou sbspace qui est en manque
d'espace. Plus de blocage du moteur à 3h00 du matin du à un dbspace
plein !
4) Open Admin Tool
Le petit bijou pour le DBA. Parti sur une base de
conception « open source », cette application en php est la tour de
contrôle de votre architecture Informix Dynamic Server. Tous les points de
contrôle importants y sont traités, et ce pour toutes les instances Informix
déclarées. Au delà des indicateurs de performances, vous pouvez également gérer
votre espace disque, l'allocation de ressources, effectuer une approche
top-down de la performance d'une session par exemple.
C'est aussi le point de contrôle et de gestion de votre Cluster ou Flexible Grid.
C'est aussi le point de contrôle et de gestion de votre Cluster ou Flexible Grid.
Je ne nomme pas toutes les fonctionnalités, mais si vous
utilisez déjà IDS, vous savez pourquoi vous aimez ce produit. Comment ne pas
reconnaître que pour zéro Euros, vous avez déjà un produit qui joue sans
ambigüité dans la cour des grands ?
Alors pourquoi choisir Innovator-C Edition dès le début du projet ?
Voici les questions à se poser quand on effectue un
choix de SGBD:
1) vous manque-t-il des fonctionnalités dans
Innovator-C par rapport aux autres SGBD gratuits ?
2) quel SGBD vous coûtera le moins de temps en administration ?
3) quel SGBD affiche le plus long temps de
« uptime » ou temps entre deux interruptions « non
volontaires » ( chez IDS, on l'exprime souvent en années ), meilleur
indicateur de la stabilité du produit ?
4) Quel est le SGBD dont l'architecture de base est la
plus performante ?
5) Comment le SGBD escalade-t-il ? Avec ce bel
anglicisme, je parle du comportement du moteur face à l’augmentation de la
demande en ressources système? Ce dernier est-il
intrinsèquement conçu pour réagir à l'augmentation de charge ? Est-il
possible de répondre à cette augmentation, et si oui, quels sont la
difficulté et le risque techniques de la solution à mettre en
oeuvre ?
Vous l'avez compris, IDS arrive probablement en première
place aux questions 1 à 4. Mais la question critique est la dernière, nous allons ci-dessous détailler la réponse.
Quand la ressource système est poussée dans ses derniers
retranchements, on peut toujours changer pour une machine plus puissante et
voir jusqu'à quel point le SGBD tiendra la charge. C'est à ce stade que l'on
constate que les maximum affichés ( taille de tables etc...), sont théoriques
et jamais atteints ( même pas en rêve).
Donc on change de marque de SGBD, on acquiert un produit
de classe « Workgroup » ou « Enterprise » et on refait tout
ou presque, comme détaillé dans le début de cet article. Scénario catastrophe,
le système ne répond plus ou très mal, les utilisateurs sont mécontents. Le
temps de mettre en production une solution stable est inacceptable. Prévoir de
lourdes retombées depuis le haut de la pyramide hiérarchique, et dans le
meilleur des cas, les nerfs en prennent un bon coup !
Et si j'avais démarré avec Innovator-C ?
Si j'avais démarré avec Innovator-C, je n'aurais
pas dépensé d'argent pour mon SGBD, mais
j'aurais eu depuis le départ un produit IBM Informix Dynamic Server, une
application et une infrastructure conçus pour ce produit.
La demande en ressources augmente et les limitations
sont atteintes ou en passe de l'être ?
Je commande la Growth Edition ou bien la Ultimate
Edition, suivant le besoin. J'arrête mon instance IDS, j'installe le nouveau
produit et je redémarre mon instance sur la même machine et sur les mêmes
disques. Temps de l'opération : aux alentours de 10mn probablement !
Prévoir quand même des tests dans un environnement de staging surtout en cas de
changement de version.
J'ai maintenant toute latitude pour rajouter de la
puissance CPU nécessaire et surtout je peux l'utiliser efficacement grâce à
l'architecture Dynamic Scalable Architecture, universellement reconnue
pour sa capacité à optimiser
l'utilisation des ressources disponibles lors de la montée en charge. Je ne
touche pas à mon application, mais je peux par contre rajouter des CPU VP,
augmenter le BUFFERPOOL par exemple ou bien utiliser le PDQ, partionner les tables et autres
fonctionnalités livrées avec Ultimate Edition.
Dans tous les cas, en démarrant avec Innovator-C je suis
préparé à faire face à une très importante montée en charge, basé sur le
principe que je ne changerai pas de SGBD. Sans modifier l’application, il
suffira de débloquer et paramètrer les nouvelles ressources dont j'ai besoin.
Il faut payer les licences, c'est sûr, mais pour tous les autres SGBD, il faut
payer les nouvelles licences mais aussi retoucher fortement (refaire ?)
l'application et son infrastructure, subir une lourde charge de tests
fonctionnels et de performance, et parer aux imprévus.
Alors, on fait quoi ?
(*)Merci à Andrew Ford pour le partage de son expérience
vendredi 26 août 2011
Pocket guide Informix sur Android
Bonjour à tous,
Aujourd'hui je vais aller vite: pour ceux qui n'ont pas la syntaxe complète de onstat, onspaces, onparams, onmode et oncheck en tête,et qui n'ont pas envie de se promener avec la doc, voici un petit outil sympathique qui est téléchargeable sur tout device android:
http://kazer.com/android.html
Edité par un gros partenaire IBM Informix des Etats Unis.
A bientôt
Aujourd'hui je vais aller vite: pour ceux qui n'ont pas la syntaxe complète de onstat, onspaces, onparams, onmode et oncheck en tête,et qui n'ont pas envie de se promener avec la doc, voici un petit outil sympathique qui est téléchargeable sur tout device android:
http://kazer.com/android.html
Edité par un gros partenaire IBM Informix des Etats Unis.
A bientôt
dimanche 7 août 2011
Choix du type de file system sur linux: au cas où vous auriez des doutes...
Bonjour à tous,
c'est sous ce ciel menaçant que je prends ma plume pour me lancer dans un test que je voulais refaire depuis déjà quelque temps: l'incidence du choix de type de file system pour implémenter nos chunks Informix Dynamic Server, dans notre cas sur Linux.
Comme vous le savez sans doute, le raw device est depuis quelque temps une technologie obsolète sur la plupart des distributions Linux. Fait typique du conflit d'intérêts entre les éditeurs de base de données qui préconisent son utilisation,et les éditeurs d'OS et fabricants de hardware qui vont dans le sens contraire.
La manière d'implémenter des chunks sous IDS n'est pas sans effet, dans la mesure où elle impacte directement la performance d'entrées-sorties, donc la performance globale. Pour rappel, il est toujours bon de répartir au maximum les données sur le plus grand nombre possible de disque, et d'en maîtriser la disposition physique.
C'est pour celà qu'il est préférable d'éviter de créer les chunks sur des disque gérés de façon sans doute sécurisée ( RAID 0/1, RAID 5, file system journalisé etc..), mais qui vont coûter cher en termes de performance.
A priori, il est déjà inutile de sécuriser les dbspaces de données, sauf si vos bases de données ne sont pas journalisées ou si vous ne sauvegardez pas vos logical logs. Dans ces deux cas, il est probablement urgent de réviser votre stratégie sauf si la perte d'une journée de travail ou plus ne cause pas de problème.
Question sécurité de vos données, IDS est très bien fait. En "backupant" les logical logs en continu sur un device externe, et bien sur en faisant régulièrement vos sauvegardes avec ontape ou onbar, vous pouvez affronter un crash total avec un indice de confiance élevé quant à la pérennité de votre emploi.
Le gros intérêt de ce système est que IDS garantit la cohérence des données ( par le biais des transactions), et que la phase de restauration d'une instance se base sur ces mêmes transactions pour restaurer les données. L'intervalle effectif entre chaque backup de logical log sur une device externe est donc important, puisqu'il déterminera combien de temps de travail pour pouvez perdre en cas de crash de tous les disques de l'instance.
Bref, il est inutile de sécuriser vos file system hôtes de vos données, cela ne sert pas à grand chose, sauf éventuellement pour le rootdbs et/ou le dbspace contenant physical et logical logs pour garantir la disponibilité ( RAID 0/1 par exemple ).
Pour les dbspaces de données, je me suis donc livré à un exercice comparatif, qui a consisté à effectuer le dbimport d'une base de données de taille réduite ( 1.7 Gb), mais à indexation très complexe.
Le plan de test était le suivant:
1) création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
2)création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée
3)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
4)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée.
Je vois pointer la question: "qu'est-ce que DIRECT_IO ". C'est un paramètre onconfig qui permet de passer outre la couche de gestion des file systems, de telle sorte qu'IDS écrit et lit en utilisant le Kernel IO, offrant donc pratiquement les mêmes avantages que si l'on utilisait des raw devices, à savoir sécurité d'écriture ( c'est IDS qui écrit dans le cooked file, pas le file system ), et un gain de performance variable en IO. Ce paramètre est disponible à partir de la Growth Edition,et malheureusement pas sur Innovator-C Edition :-(
faisons court:
test 1: durée du traitement = 91m41s
test 2: durée du traitement = 195m57s
test 3: durée du traitement = 54m49s
test 4: durée du traitement = 49m54s
Le vainqueur est donc sans appel le file system en ext2, avec direct_io activé.
La surprise a été le test en ext4 avec direct_io activé: combinaison à éviter absolument.
A noter que chaque test a été répété 2 fois, en prenant soin de redémarrer l'instance entretemps. Les temps obtenus pour chaque test ont été à chaque fois très cohérents.
Vous avez donc maintenant des éléments de décision pour vos prochaines implémentations.
A bientôt sur notre station pour de nouveaux défis.
c'est sous ce ciel menaçant que je prends ma plume pour me lancer dans un test que je voulais refaire depuis déjà quelque temps: l'incidence du choix de type de file system pour implémenter nos chunks Informix Dynamic Server, dans notre cas sur Linux.
Comme vous le savez sans doute, le raw device est depuis quelque temps une technologie obsolète sur la plupart des distributions Linux. Fait typique du conflit d'intérêts entre les éditeurs de base de données qui préconisent son utilisation,et les éditeurs d'OS et fabricants de hardware qui vont dans le sens contraire.
La manière d'implémenter des chunks sous IDS n'est pas sans effet, dans la mesure où elle impacte directement la performance d'entrées-sorties, donc la performance globale. Pour rappel, il est toujours bon de répartir au maximum les données sur le plus grand nombre possible de disque, et d'en maîtriser la disposition physique.
C'est pour celà qu'il est préférable d'éviter de créer les chunks sur des disque gérés de façon sans doute sécurisée ( RAID 0/1, RAID 5, file system journalisé etc..), mais qui vont coûter cher en termes de performance.
A priori, il est déjà inutile de sécuriser les dbspaces de données, sauf si vos bases de données ne sont pas journalisées ou si vous ne sauvegardez pas vos logical logs. Dans ces deux cas, il est probablement urgent de réviser votre stratégie sauf si la perte d'une journée de travail ou plus ne cause pas de problème.
Question sécurité de vos données, IDS est très bien fait. En "backupant" les logical logs en continu sur un device externe, et bien sur en faisant régulièrement vos sauvegardes avec ontape ou onbar, vous pouvez affronter un crash total avec un indice de confiance élevé quant à la pérennité de votre emploi.
Le gros intérêt de ce système est que IDS garantit la cohérence des données ( par le biais des transactions), et que la phase de restauration d'une instance se base sur ces mêmes transactions pour restaurer les données. L'intervalle effectif entre chaque backup de logical log sur une device externe est donc important, puisqu'il déterminera combien de temps de travail pour pouvez perdre en cas de crash de tous les disques de l'instance.
Bref, il est inutile de sécuriser vos file system hôtes de vos données, cela ne sert pas à grand chose, sauf éventuellement pour le rootdbs et/ou le dbspace contenant physical et logical logs pour garantir la disponibilité ( RAID 0/1 par exemple ).
Pour les dbspaces de données, je me suis donc livré à un exercice comparatif, qui a consisté à effectuer le dbimport d'une base de données de taille réduite ( 1.7 Gb), mais à indexation très complexe.
Le plan de test était le suivant:
1) création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
2)création du dbspace sur sur un file system linux ext4 ( journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée
3)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 0, puis dbimport dans une base non journalisée
4)création du dbspace sur sur un file system linux ext2 ( non journalisé ), avec le paramètre onconfig DIRECT_IO à 1, puis dbimport dans une base non journalisée.
Je vois pointer la question: "qu'est-ce que DIRECT_IO ". C'est un paramètre onconfig qui permet de passer outre la couche de gestion des file systems, de telle sorte qu'IDS écrit et lit en utilisant le Kernel IO, offrant donc pratiquement les mêmes avantages que si l'on utilisait des raw devices, à savoir sécurité d'écriture ( c'est IDS qui écrit dans le cooked file, pas le file system ), et un gain de performance variable en IO. Ce paramètre est disponible à partir de la Growth Edition,et malheureusement pas sur Innovator-C Edition :-(
faisons court:
test 1: durée du traitement = 91m41s
test 2: durée du traitement = 195m57s
test 3: durée du traitement = 54m49s
test 4: durée du traitement = 49m54s
Le vainqueur est donc sans appel le file system en ext2, avec direct_io activé.
La surprise a été le test en ext4 avec direct_io activé: combinaison à éviter absolument.
A noter que chaque test a été répété 2 fois, en prenant soin de redémarrer l'instance entretemps. Les temps obtenus pour chaque test ont été à chaque fois très cohérents.
Vous avez donc maintenant des éléments de décision pour vos prochaines implémentations.
A bientôt sur notre station pour de nouveaux défis.
vendredi 1 juillet 2011
Objectif Performance
Bonjour à tous,
je me propose aujourd'hui de mettre en ligne un case study que j'ai écrit pour la Newsletter du User Group Informix France ( petit nom UGIF ), auquel je vous recommande de vous abonner car elle contient plein d'infos intéressantes. Pour s'abonner, c'est très simple: envoyez un email à ifmxnewsletter@fr.ibm.com avec "ABONNER" dans le sujet.
Bonne lecture et bons tests.
Eric
Etude de cas : Objectif performance…
"Bonjour, merci de vous être connecté sur notre station. Votre mission est, si vous l'acceptez, d'implémenter une nouvelle table dans la base de données, d'en faire un chargement initial avec un temps d'opération inférieur à 10 minutes, et de fournir à l'équipe de développeurs une manière de gérer au mieux les temps de réponses sur une requête imposée qui, selon le comité des testeurs de l'application reportant au Directeur des Opérations, a un temps de réponse inacceptable. Vous disposez d'IBM Informix Dynamic Server V11.70 FC2 Innovator-C Edition, un serveur Linux avec un processeur 4core, 16 Gb de RAM entièrement à votre disposition. Ah! J’oubliais, la table à charger comporte environ 70 millions de rangées, mais n'est pas très complexe quant à son schéma et son indexation. Il faudra de plus y charger environ 500 000 rangées tous les soirs"
Ce genre de demande vous rappellera très certainement des situations vécues soit en tant que DBA, soit en tant que développeur. On constate généralement, à ces instants précis, un certain flottement dans le regard du destinataire de cette requête, de même que des symptômes caractéristiques du découragement ou d'une féroce envie de décliner la demande sous le chef de « ça n'est pas réaliste ». Il est vrai que dans les versions antérieures d'IDS cette demande représentait un véritable défi, difficile à relever.
Mis à part peut-être l'utilisation de High Performance Loader, pas trop simple à mettre en oeuvre dans l'urgence, il faut avouer qu'il y avait au minimum de quoi être troublé par cette demande. Fort heureusement, nous sommes en 2011 et les laboratoires IBM Informix nous ont concocté un certain nombre d'améliorations très utiles, qui vont nous permettre de relever le défi avec IDS 11.70.
Analysons tout d'abord la demande: 1) La nouvelle table contient tous les billets d’avion sur les liaisons entre la France, l’Allemagne, l’Angleterre, l’Italie, l’Espagne et les Etats-Unis depuis le 1er janvier 2005. en voici le schéma : create table tickets (
ticketno bigint, # N° unique de ticket
lastname varchar(60), # Nom voyageur
firstname varchar(30), # Prénom voyageur
gender char(3), # MR/MRS/INF
flightdate date, # Date du vol
flightno char(6), # N° du vol
fileno char(8), # N° de dossier
price money(8,2), # Prix du vol
carrier char(2), # Compagnie aérienne
departfrom char(3), # aéroport de départ
destination char(3) # aéroport de destination );
create index tickets3 on tickets (flightdate);
create index tickets7 on tickets (destination);
Et enfin la requête qui pose des problèmes à nos amis développeurs:
select destination , count(*)
from tickets,airports
where tickets.destination = airports.code
and tickets.destination between "AAA" and "ZZZ"
and airports.country = 'France'
and flightdate between "21/03/2006" and "31/07/2010"
group by 1
J’avais au préalable réussi à convaincre les développeurs de fournir des indexes mono-colonne, de façon à éviter l’obtention de trop nombreux niveaux de B-Tree affaiblissant la performance. L'évocation du chiffre de 70 millions de rangées initiales, grossissant environ d'un million tous les 2 jours, est par contre de nature à susciter au minimum de l'intérêt, au maximum de l'inquiétude quant à l'atteinte des objectifs définis.
Nous ne parlerons pas aujourd’hui de fragmentation de cette table qui pourrait nous apporter une solution ultérieurement en cas de détection de problèmes d'IO sur celle-ci. Nous ne parlerons pas non plus de la compression des tables, technique provenant de XPS et implémentée à partir de la version 11.50.xC6 qui, tout en réduisant environ de moitié (ou plus) l'espace disque, permet d'augmenter de façon significative les performances sur les "grosses" tables. Cette fonctionnalité est pour l'instant « optionnelle » (lire payante), et ne fait donc pas partie des options à envisager dans notre cas.
Concentrons-nous donc sur la première partie du défi : le chargement de 70 millions de rangées en moins de 10 minutes. Nous avons pensé à High Performance Loader, qui est un outil très efficace, mais un peu complexe à mettre en oeuvre pour une première fois et dans le temps imparti.
Je voulais donc évoquer ici l'utilisation des tables externes, provenant également de XPS et implémentées depuis la version 10.50. Le principe est très simple, vous créez votre table, sauf qu'au lieu de résider dans l'instance IDS, celle-ci est constituée par un fichier sur file system, structuré soit par l'existence de délimiteurs de champs, soit par une structure fixe. Vous créez la table externe qui pointe sur ce(s) fichier(s) et qui en décrit la structure comme une table « normale ». Nous avons donc appliqué ceci pour le cas d'aujourd'hui :
CREATE EXTERNAL TABLE ext_tickets
SAMEAS tickets
USING (DATAFILES ("DISK:/home/eric/StagingArea/ObjectifPerf/tickets.unl"), DELIMITER "|",EXPRESS,MAXERRORS 10,REJECTFILE "/tmp/x_tickets.out")
Expliquons :
« SAMEAS tickets » veut dire créer la table à l'image du schéma de la table déjà existante tickets.
« DATAFILES DISK » : notre fichier est sur disque et se nomme...
« DELIMITER » : c'est une structure avec délimiteurs de champs, ici le « pipe »
« EXPRESS » : le mode de chargement. Il s'oppose au mode DELUXE. Ce mode évite l'utilisation des pages de buffers lors de la lecture dans cette table, ce qui va muscler fortement la performance de notre chargement.
« MAXERRORS » : au-delà de ce nombre d'erreurs, la création de la table s'arrête.
« REJECTFILE » : le fichier où sont consignées les erreurs de chargement.
Une table externe peut donc être manipulée par des tous types de requêtes SELECT ( order by, group by, prédicats) , mais ne peut pas être UPDATED,DELETED ni INSERTED. Résultat , avec table raw la commande de chargement est :
INSERT INTO tickets SELECT * FROM ext_tickets
70000000 row(s) inserted.
real 6m20.937s user 0m0.005s sys 0m0.005s
Nous avons comparé avec la méthode insert into table load from file, et le résultat est sans appel : nous avons arrêté le chargement au bout de 24 minutes : seulement 24 Millions de rangées étaient chargées.
Autre point important à relever : nous avons crée une table de type « RAW ». Ce type de table a la particularité de désactiver la journalisation de la table incriminée. En conséquence, la performance de chargement est drastiquement améliorée du fait de l'absence d'IO à cause de la journalisation (logical logs). La différence est plus que notoire. Le gros intérêt est qu'il est possible de changer en type STANDARD (journalisation) après le chargement par un simple ALTER TABLE, puis repasser en RAW pour les chargements consécutifs.
Nous évitons également l’écueil de la ‘long transaction’.
Nous avons donc atteint le premier objectif de passer sous les 10mn de temps de chargement, et restons sereins pour les chargements journaliers.
Passons maintenant au deuxième défi : la requête La table tickets a un nombre de rangées respectable ( 70 millions de rangées ), et à cette échelle il convient de veiller à optimiser les ressources ainsi que les accès.
Nous partirons de la baseline proposée par l'équipe des développeurs et prendre une mesure de performance.
Nous avons de fait renoncé à la baseline, comprenant les plaintes des développeurs : la requête a été abortée au bout de 60 mn sans qu’elle soit terminée, voici son plan de requête :
Estimated Cost: 3126460
Estimated # of Rows Returned: 775663
Temporary Files Required For: Group By
1) eric.airports: INDEX PATH
Filters: (eric.airports.code >= 'AAA' AND eric.airports.code <= 'ZZZ' )
(1) Index Name: eric.i_airp3
Index Keys: country (Serial, fragments: ALL)
Lower Index Filter: eric.airports.country = 'France' 2) eric.tickets:
INDEX PATH Filters: (eric.tickets.flightdate >= 21/03/2006 AND eric.tickets.flightdate <= 31/07/2010 )
(1) Index Name: eric.tickets7
Index Keys: destination (Serial, fragments: ALL)
Lower Index Filter: eric.tickets.destination = eric.airports.code
NESTED LOOP JOIN
Nous obtenons donc une nested loop (boucle imbriquée pour la jointure ), avec utilisation de l’index sur les pays pour la table airports ( 10000 rangées ), et l’index date du vol pour la table des tickets. Onstat - p nous donne 7509528 rangées lues (read).
C’est à ce moment que nous introduisons la nouvelle directive d’optimiseur MULTI_INDEX, qui va nous permettre d’utiliser plusieurs indexes sur une même table, contrairement à ce qui se faisait auparavant. La syntaxe :
SELECT --+multi_index(tickets tickets3 tickets7)
distinct(destination) , count(*) ....
from tickets,airports etc....
Nous allons dire à l’optimiseur d’utiliser les index tickets3 ET tickets7 pour la table tickets afin de lire un minimum de pages de données, et par conséquence réduire les IO sur cette requête. Voici le résultat du set explain :
DIRECTIVES FOLLOWED: MULTI_INDEX ( tickets tickets3 tickets7 )
DIRECTIVES NOT FOLLOWED:
Estimated Cost: 113176408
Estimated # of Rows Returned: 775663
Temporary Files Required For: Group By
1) eric.tickets: MULTI INDEX PATH (SKIP SCAN)
(1) Index Name: eric.tickets7
Index Keys: destination (Serial, fragments: ALL)
Lower Index Filter: eric.tickets.destination >= 'AAA'
Upper Index Filter: eric.tickets.destination <= 'ZZZ' AND
(2) Index Name: eric.tickets3 Index Keys: flightdate (Serial, fragments: ALL)
Lower Index Filter: eric.tickets.flightdate >= 21/03/2006
Upper Index Filter: eric.tickets.flightdate <= 31/07/2010
2) eric.airports: INDEX PATH
Filters: Table Scan Filters: (eric.airports.code >= 'AAA' AND eric.airports.code <= 'ZZZ' )
(1) Index Name: eric.i_airp3
Index Keys: country (Serial, fragments: ALL)
Lower Index Filter: eric.airports.country = 'France'
DYNAMIC HASH JOIN
Dynamic Hash Filters: eric.tickets.destination = eric.airports.code
La physionomie du plan de requête a totalement changé : nous voyons l’activation de la directive multi-index sur la table tickets, qui a pour effet l’utilisation de l’index tickets7 + l’index tickets3 et finalisant le plan par un HASH JOIN pour la jointure.
Onstat -p nous indique que seulement 2.294.947 de rangées ont été lues, ce qui devrait signifier un progrès sensible. Et le temps de réponse ????
Le voici :
155 row(s) unloaded
real 5m22.672s user 0m0.005s sys 0m0.008s
Oui ! c’est bien 5 mn 22s. L’objectif d’amélioration du temps de réponse est atteint. N’ayant pas de données implémentées sur plusieurs disques, nous ne pourrons pas profiter du multiplexage des scan threads qui auraient pu améliorer encore notre performance. N’ayant pas lancé ce test sur la Ultimate Edition, nous ne pouvons pas bénéficier du PDQPRIORITY qui aurait sans doute amélioré légèrement les résultats.
Nous avons clairement profité de la directive MULTI INDEX, qui a diminué le temps d’attente de plus d’une heure (peut-être beaucoup plus ) à 5 mn 22s.
Il faut savoir également que cette technique est extrêmement efficace dans des requêtes avec prédicat « OR » portant sur des indexes différents d’une même table. Combien de fois nous a-t-il fallu réécrire une requête de ce type en incluant une UNION ? Avec cette technique, plus la peine de tout réécrire, il suffit d’ajouter la directive d’optimiseur qu’il faut, et le tour est joué !
Nous vous encourageons également à utiliser l’option de onmode ‘-Y sessionid 1 output file’, qui produira le fichier d’explain de la session ‘sessionid’ sans avoir à rajouter le ‘SET EXPLAIN ON’ dans le code de l’application. A utiliser toutefois avec modération en environnement production, car ce mode est très volubile et peut générer une charge d’IO qui pourra parasiter la performance.
Voilà, mission accomplie ! Merci aux techniques de tables externes en mode EXPRESS, de table de type RAW qui suppriment temporairement la journalisation, et la nouvelle directive d’optimiseur MULTI_INDEX. A bientôt sur notre station pour de nouveaux défis.
Inscription à :
Articles (Atom)