Vous vous connectez à un serveur et vous découvrez que plusieurs process utilisent 100% de CPU. Vous décidez d’y mettre un terme avec un « kill -9 » et… rien : les process ne s’arrêtent pas ! Et ce sont de vrais process, pas des « defunct » ou une autre étrangeté. Savez-vous que ça peut arriver ? Que ces process peuvent être des process Oracle ? Que c’est arrivé à l’un d’entre-nous aujourd’hui ?

Je préfère quand on vient me voir après que le problème ait été réglé ; surtout avec la solution. Alors me voilà au milieu de cet imbroglio, pour reconstituer l’histoire du problème à travers tous les fichiers de trace et pour expliquer le comportement de RAC dans cette situation particulière, qui a raté son suicide malgré une tentative évidente.

• L’OS est Linux RHEL4 x86_64 mais , j’imagine que ça pourrait aussi bien arriver sous Windows
• La base de données Oracle 10.2.0.3 RAC mais ça n’a rien a voir avec, ni RAC, ni même Oracle

Vous trouverez la réponse dans le man de la commande « ps ». Voici ci-dessous la ligne qui vous intéressera :

PROCESS STATE CODES
       Here are the different values that the s, stat and state output
       specifiers (header "STAT" or "S") will display to describe the state of
       a process.
       D    Uninterruptible sleep (usually IO)

Quand un process fait certaines opérations, il devient ininterrompable, même par un « kill -9 ». C’est ce qu’on appelle le « D-State ». Google donne quelques résultats intéressants notamment à propos de NFS. après quelques investigations, il apparaît que la couche SCSI est partie en live juste au moment de l’apparition du problème. Pourquoi ? J’aimerais avoir la réponse…

Le résultat est assez loin du monde idéal que l’on imagine. Hasard du calendrier, le multipath du noyau 2.6 est utilisé et Jeremy expliquait justement il y a 2 jours comment le configurer avec RHEL/OEL 5. Et RAC dans tout ça ? RAC n’a pas pu se suicider pourtant les autres noeuds savaient qu’il fallait le faire. C’est un de ces cas borderline, comme évoqué par Kirk McGowan l’an dernier à propos du STONITH (Le premier cas réel que je rencontre en 10.2) où RAC ne réagit pas beaucoup mieux qu’une single instance.

En fait pour résoudre ce problème, il n’y avait pas d’autre alternative que de rebooter le serveur ce qui a été fait dans les minutes qui ont suivi la découverte du problème. Voilà une preuve de plus que RAC n’est qu’une brique dans la mise en œuvre d’une solution hautement disponible et que la supervision a, elle ausi, son importance, même au 21e siècle.