C'est une question que plusieurs d'entre nous (admistrateurs de base de données ou adminstrateurs systèmes) se posent. Quelques éléments de réponses évoqués dans cette article.
Pour rappel, il s'agit d'une option cachée dans la base de données Oracle (_enable_numa_optimization en Oracle 11g et _enable_numa_optimization en Oracle 10g). Cette option lorsqu'elle est activée permet de découper la mémoire partagée par les processus Oracle en plusieurs segments (la fameuse SGA). Cependant ce découpage dépend exclusivement de l'architecture matérielle sur laquelle la base Oracle s'exécute. En Oracle 10g jusqu'à la version 10.2.0.3, cette option était active par défaut. Bizarrement, cette option a été désactivé dans toutes les autres versions (encore actuellement avec la 11gr2). Pourtant, activer cette option peut s'avérer fort utile (voir le workaround concernant un bug dans l'ISM avec Solaris x86).
Que devons nous faire alors ? Si vous posez la question au support Oracle bases de données la réponse est clair : ne pas l'activer. Par contre si vous posez la question su support Oracle système la réponse est légérement différente : oui vous pouvez l'activer si votre architecture est NUMA. Cette option active par défaut dans les versions inférieurs à la 10.2.0.4 pose plusieurs problèmes si la base de données s'exécute sur une architecture non NUMA (bizarrement, c'est ce qu'il s'est notamment produit avec les serveurs HP Superdome). Suite à plusieurs incidents remontés au support Oracle bases de données, les équipes de dev ont tout simplement décidé de désactiver cette option (bien avant le rachat de Sun par Oracle).
Pour répondre à un besoin particulier, nous avons décidé de l'activer sur plusieurs bases de données. Pour le moment aucun disfonctionnement nous a été remonté vis-à-vis de la gestion de la mémoire partagée mais voilà ce que nous avons détecté lors de sa mise en place sur des serveurs Solaris 10u9...
Lors du démarrage de la base de données, nous avons constatés les messages suivants dans le fichier d'alertes d'Oracle :
[...]
2012-01-20 14:52:17.564000 +01:00
WARNING: Local memory allocation shmadvice failure, errno = 22
2012-01-20 14:52:32.994000 +01:00
WARNING: Local memory allocation shmadvice failure, errno = 22
2012-01-20 14:52:49.119000 +01:00
WARNING: Local memory allocation shmadvice failure, errno = 22
2012-01-20 14:53:04.047000 +01:00
WARNING: Local memory allocation shmadvice failure, errno = 22
[...]
Les différents segments ont tous été activés correctement ( 4 segments + 1 pour la gestion) :
# pmap -x 2993
[...]
0000000060000000 14024704 14024704 - 14024704 2M rwxsR [ism shmid=0x7000003]
00000003C0000000
11796480 11796480 - 11796480 2M rwxsR [ism shmid=0x7000004]
00000006A0000000 11796480 11796480 -
11796480 2M rwxsR [ism shmid=0x7000005]
0000000980000000 11927552 11927552 - 11927552 2M rwxsR [ism
shmid=0x7000006]
0000000C60000000 11796480 11796480 - 11796480 2M rwxsR [ism
shmid=0x7000007]
0000000F40000000 20 20 -
20 4K rwxsR [ism shmid=0x7000008]
[...]
En traçant le démarrage de la base Oracle, on obtient les informations suivantes :
[...]
shmget(IPC_PRIVATE, 12079595520,0640|IPC_CREAT|IPC_EXCL) = 117440545
shmsys(5, 0x07000021, 0x00000001, 0xFFFFFC7FFFDFA2F8) = Err#22 EINVAL
[...]
Le syscall shmsys() est uniquement utilisé lorsque l'option NUMA est activée dans la base. Le 1er argument de shmsys() permet de déterminer quelle sous fonction est exécutée. Il y a 4 choix possible et un par défaut. Etrangement le code retour du choix par défaut est EINVAL (code source). Pourquoi Oracle base de données utilise la valeur 5 pour cet argument ? S'agit'il d'un bug ? Pour info, l'erreur se produit autant de fois qu'il y a de segments.
Réponse du support Oracle : il s'agit d'un problème d'interfaçage entre Oracle bases de données et Solaris (bug 12596470). Ce bug est corrigé dans Solaris 10u10 et Solaris 11.
Malgré la présence de ce bug, l'activation de NUMA ne semble pas poser de problème. Les segments de la base de données utilisent les lgrps de Solaris. Mais les utilisent-ils correctement ?
En attendant un statut officiel d'Oracle sur l'activation ou non de cette option, vous pouvez tenter de l'activer au moins sur vos architectures de dev/test/uat avant de franchir le cap en production. Pour l'heure, plusieurs bases en production fonctionnent avec cette option active sans avoir eu de problème (à l'exception du bug cité ci-dessus).
Ci-joint quelques références sur ce sujet :
- You Buy a NUMA System, Oracle Says Disable NUMA! What Gives? Part I
- You Buy a NUMA System, Oracle Says Disable NUMA! What Gives? Part II
- You Buy a NUMA System, Oracle Says Disable NUMA! What Gives? Part III
