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.

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.

Ces petites choses qui ne font pas de bruit, mais qui évitent d'en faire

Bonjour à tous,

aujourd'hui nous allons faire très court. Je voulais juste vous parler d'un paramètre de votre onconfig préféré qui retiendra toute votre attention si l'on pose le problème dans les termes suivants: vous est-il déjà arrivé de détruire une instance Informix Dynamic Server en vous trompant d'option de la commande oninit ? La réponse est très certainement non, mais "seulement au cas où l'avenir vous réserve de mauvaises surprises" ( cette énorme pression lors d'une intervention d'urgence à 3h00 du matin par exemple...), sachez que IDS 11.70 xC1 a introduit un nouveau paramètre dans le onconfig, dont le but est de vous protéger de ce genre de mésaventure. Ce paramètre s'appelle FULL_DISK_INIT.

C'est très simple, si vous le valorisez à 0 ( valeur par défaut ), et que l'instance en question est déjà existante, , oninit -i vous enverra un message vous disant que l'initalisation est impossible: "oninit: fatal error in shared memory creation".
Warning: server initialization failed or possibly timed out ..."
Même si celà ressemble à un message d'erreur, vous êtes sauvé, le chunk root n'a pas été détruit.

Bien sûr s'il s'agit d'une vraie initialisation, c'est-à-dire que c'est la première fois que vous créez ce root chunk, le processus ira jusqu'au bout comme auparavant.

Si vous avez vraiment besoin d'écraser le root chunk, vous pouvez donc modifier ledit paramètre à 1, TEMPORAIREMENT, pour pouvoir arriver à vos fins.

Voilà encore une bonne raison pour upgrader vers la version 11.70. Cette amélioration ne représente cependant qu'une goutte noyée dans un grand nombre de nouvelles fonctionnalités apportée par la 11.70

Mais ça, c'est une autre histoire...

Des nouvelles du front

Bonjour à tous,

vu chez mon ami et néanmoins gourou Fernando Nunes de Lisbonne, des nouvelles d' "une autre compagnie éditant des SGBD commençant par O".

En effet, la nouvelle est tombée fin mars 2011: ladite compagnie citée plus-haut abandonne le développement des versions futures dudit SGDB sur plateforme HP-UX tournant sur le processeur Intel Itanium, tout en garantissant "quand-même" le support sur les versions existantes. Selon HP, la base installée représente environ 140000 clients qui peuvent se poser des questions quand à la pérennité de leur choix.

Fernando évoque les 3 solutions possibles:
1) sauter dans le train dudit fabricant de SGDB, par ailleurs fabricant de matériel ( SPARC ), et advienne que pourra pour ce qui est des coûts "annexes".
2) changer de constructeur, en priant pour que la même plaisanterie ne survienne pas d'ici quelque temps.
3) Migrer vers IBM Informix, pour différentes raisons parmi lesquelles
* la fiabilité,la robustesse, le faible coût à l'exploitation
* la feuille de route claire d'IBM, venant d'accomplir 10 ans d'améliorations constantes du produit depuis le rachat.
* parce que Informix et HP sont "deux mots qui vont très bien ensemble" depuis plusieurs décennies et les faits l'ont démontré et continuent à le démontrer.

Comme quoi, cet éditeur qui accusait il y a 10 ans IBM d'abandonner définitivement ses clients Informix ( ce qui ne s'est de fait pas produit) , parait à ce jour adopter les pratiques qu'il était si prompt à dénoncer...

L'article est un peu dense et en anglais, mais il vaut le coup. Pour y accéder cliquez sur le titre de cet article

A bientôt

Eric

IDS enfin sur facebook

Bonjour à tous,

je sors le nez de mes métriques sur un système de production pour vous informer que enfin Informix Dynamic Server a sa page sur Facebook.

N'hésitez pas à aller sur cette page et dire que vous aimez!
http://www.facebook.com/pages/IBM-Informix-Dynamic-Server-IDS/23461144288

La page pointe vers les news interessantes sur votre SGBD favori.

A bientôt

Informix Dynamic Server existe vraiment à partir de dorénavant

Bonjour à tous

je passais juste vous signaler que le wiki sur Informix Dynamic Server a été profondément remanié et comporte dorénavant des informations plus complètes.
Pour vous y rendre, cliquez sur le titre de ce message ( plus haut ), ou bien allez à

La vie de Informix Dynamic Server




A bientôt

IWA ? Informix Warehouse Accelerator

Un jeu nommé VITESSE!             Présentation de Informix Ultimate Warehouse Edition Mais qu'ont-ils donc tous à s'agiter autour de cette annonce? L'offre  IBM Informix Ultimate Warehouse apporte de fait des améliorations de performance qualifiables d'extrêmes pour la solution décisionnelle d'Informix, utilisant une technologie d'accélération à couper le souffle. Bon allez! Encore un qui exagère pour vendre sa camelote.. Ok, gardez vos questions pour l'instant! Laissez-moi d'abord explorer le contenu de cette offre avant de rentrer dans les détails. Elle consiste à la base en une édition flambant neuve qui se décompose ainsi: Informix Ultimate Edition 11.70 XC2 ou supérieure (notre moteur légendaire) Informix Warehouse Accelerator (contenant Smart Analytics Studio)  Informix Storage Optimization Feature (en 2 mots: Informix Compression) La composante majeure de l'offre est l'"Accélérateur de Dépôt Informix" ( En version Québecoise, Warehouse en version Française ). Cette technologie révolutionnaire issue des laboratoires de recherche IBM, vous permet de charger totalement en mémoire votre data mart (celui sur lequel vous exécutez vos requêtes), et ceci dans  un format compressé. L'organisation de la mémoire ainsi que ses accès utilisent intensément une approche de base de données orientée colonne. Les requêtes peuvent être exécutées à volonté sans avoir à décompresser les données en mémoire. Et concrètement, celà donne quoi ? Dans bien des cas ( une écrasante majorité NDT), les temps de réponses des requêtes changent radicalement d'ordre de grandeur, ceci étant du à de considérables gains en performance. Certains des clients travaillant sur le programme Beta nous ont communiqué des résultats de performances se démarquant clairement de ce qui a pu se voir jusqu'à ce jour. Dans ce programme Beta, il a pu être observé 2 ordres de grandeur en ce qui concerne l'amélioration des temps de réponses: pour certains clients, de 100 à 300 fois plus rapide ( oui j'ai bien dit FOIS ), pour d'autres, des gains de 10 à 100 fois. La cerise sur le gâteau: vos applications de BI connectées à Informix restent en l'état, sans devoir y apporter quelque modification que ce soit! Informix  Warehouse Accelerator est fortement optimisé pour la plateforme Linux/Intel est doit fonctionner sur un système qui répond aux prérequis suivants Voici en un mot comment tout celà s'articule vous upgradez ( si vous avez  déjà déployé Ultimate Edition pour votre warehouse ) vers la version introduisant  IWA ( 11.70 XC2 ou supérieure ) vous installez Informix Warehouse Accelerator sur un système Linux/Intel  vous configurez Informix Warehouse Accelerator à partir de l'interface graphique intuitif de Ultimate Edition ( nommé IBM Smart Analytics Studio ) vous chargez votre(s) data mart(s) dans Informix Warehouse Accelerator vous exécutez vos applications de BI sur l'instance Informix comme avant Grâce à la fonctionnalité d'optimisation du stockage Informix ( la compression), vous pourrez compresser l'espace de votre warehouse sur disque et réaliser de substantielles économies de stockage. Votre warehouse reste géré par l'instance Informix et vos requêtes de BI sont toujours exécutées par cette dernière. Quand une requête est identifiée comme devant être exécutée sur un data mart configuré pour l'accélération, l'optimiseur Informix passe la requête à l'accélérateur, lequel retourne les résultats à l'application BI. Le graphique ci-dessous vous donnera un bon aperçu des opérations Informix Ultimate Edition est supporté en version 64-bit sur les OS suivants: AIX, Solaris, HP-UX et Linux: Processor/System Operating System Informix 11.70 IBM Power (IBM System p) AIX 6.1 (64-bit) 64-bit Sun Sparc Solaris 10 (64-bit) 64-bit Intel x64 (Intel EM64T) Linux RHEL 5 (64-bit, SUSE 11 (64-bit) 64-bit HP Itanium HP-UX  11.31 (64-bit) 64-bit Le composant IWA est supporté sur la plateforme suivante: Processor/System Operating System Informix Warehouse Accelerator Intel x64 (Intel EM64T) Linux RHEL 5 (64-bit, SUSE 11 (64-bit) 64-bit Pour en savoir plus sur Informix Ultimate Warehouse Edition visitez la page Informix Warehouse ou bien participez aux évènements Discover Informix et IIUG près de chez vous, ou encore sur les divers blogs d'experts informix. Egalement visible à la IIUG Conference à partir du 15 Mai 2011. Pour terminer sur une note philosophique, voici ma favorite pour votre environnement de warehouse: "choisissez le NON comme unique réponse possible!!!"                                                                                                      #

Cet article a été écrit par Rajesh Nair, chef de produit Informix chez IBM.
L'humble traduction a été réalisée avec son accord par votre serviteur

Version originale ici:
US announcement