Je me suis replongé cet après-midi dans un de mes anciens posts non publiés (En attendant 11g, il faut bien s’occuper). Celui-ci abordait les niveaux d’isolation (encore ?), mais cette cette fois-ci à propos d’IBM DB2. le papier qui m’avait alors « titillé » était celui-ci mais pour plus de sécurité, je me suis reporté aussi à la documentation associée de la dernière version : pour Unix et Windows ; j’imagine que z/OS est encore bien différent.

Je ne me rappelle plus pourquoi j’ai arrêté ce post, mais mes certitudes viennent encore de tomber aujourd’hui. Le papier dit en substance que DB2, c’est mieux qu’Oracle et que, en plus, c’est plus rapide ! Jusque là rien à reprocher ça semble objectif et comme je dis toujours: « si c’est écrit, c’est que c’est vrai ».

Ensuite le document explique comment Oracle génère plus d’I/O à cause des modifications stockées dans les UNDO. Ce n’est pas entièrement faux, même si ce n’est pas parce qu’Oracle lit les données des UNDO sur disques mais plutôt qu’au bout d’un certain temps et selon le paramètrage il pourrait bien les écrire avant de les lire. Et de conclure « Even committed transactions are not seen by the reader if the reading statement started before the updating statement ». DB2 arriverait à donner l’image de votre SELECT tel qu’il est à la fin de son exécution ? (Je ne suis pas objectif ! Oublions cette phrase…)

Là ou je me perds vraiment, c’est quand il dit . « DB2 implements the ANSI standard isolation levels (RR, RS, CS and UR) ». C’est toujours le cas, j’ai verifié dans DB2 v9. Malheureusement il faut payer pour accèder aux normes ANSI SQL. Il ajoute, comme dans la documentation, que Repeatable Read n’autorise pas les lignes fantômes. Je croyais, et Wikipedia comme moi, que dans la norme ANSI c’était « serializable ». Quelqu’un peut-il avec certitude définir les niveaux d’isolation Standard ANSI ?

Bon pour conclure à propos de « Multi Version Read Consistency » :

• Oracle genère ORA-1555 à cause des UNDO
• Le modèle de concurrence d’Oracle est au niveau page et pas ligne [sic]
• Dans la vrai vie vous préférez avoir un verrou et alors il faut utiliser SELECT… FOR UPDATE alors qu’avec DB2 un SELECT suffit

S’il vous plait, ne prenez pas ces 3 points au premier degré ! Je voulais à l’époque pointer un autre document beaucoup plus intéressant et réaliste : « IBM DB2 Universal Database Porting Guide:Oracle to DB2 Version » et en particulier le chapitre Concurrency Control assez bien écrit.

Aujourd’hui, ce type d’argument est sans doute plus difficile à tenir dans la mesure ou SQL Server 2005 offre désormais ce que Microsoft appelle Snapshot Isolation et MySQL/InnoDB le Consistent Non-Locking Read.

Ah oui, ça y est ! Je me souviens ce que je voulais faire quand j’ai relevé cet article : Des tests pour montrer d’autres différences. Bon assez pour aujourd’hui. Je le note et je reviendrai. Pour ça il va falloir que je vérifie les conditions de licences de prêt de DB2 ou trouver une base de données et des utilisateurs coopératifs : il va sans doute falloir patienter quelques mois ; vous pouvez sans doute m’aider si vous avez une base DB2

Encore une chose avant que j’oublie : regardez comme lui les resultats et configurations des benchmarks TPC-C et TPC-H, c’est souvent très très instructif !