Table UNK | Domlike

Lundi, 8. Janvier 2007

Table UNK

En ce moment je participe (entre autre…) à une migration V5 -> V7. Lorsque l’on migre un domaine il y a au préalable une série de vérifications à réaliser. Par mis elles, il y a la taille et la configuration de la table UNK de tout vos names. J’ai décidé de faire un petit billet dessus car je me suis rendu compte que cette table n’était pas forcément connue de tous.

La table UNK (UNique Key) est une table interne qui stocke tout les noms de champs contenus dans une base. Pour ceux qui connaissent le client designer, c’est la liste des champs qui apparaît lorsque l’on veut donner à une colonne la valeur d’un champ en particulier. Cette liste est constituée des noms de tous les champs insérés dans les masques de notre base ajoutée à ceux des documents.

Pourquoi s’intéresser à cette table ?
Bien tout simplement car elle a une taille limite et qu’une migration modifie certain template en y ajoutant des masques et que l’on risque de s’approcher voir dépasser cette fameuse limite. Peut-être êtes vous déjà tombé devant ce type d’erreur :

Database has too many unique field names
Cannot Store Document; Database has too many unique field names. Please ask your administrator to compact the database.

Quelle est donc sa limite ?
La limite de cette table est de 64ko ce qui correspond à environ 3000 champs ayant des noms de 10 caractères en moyenne. Cette limite est valable pour toutes les versions de base Domino.

Que faire pour éviter de passer cette limite ?
Le plus simple est d’activer l’option "Autoriser davantage de champs dans la base" ou en anglais « allow more fields in database » :

Cette option augmente la limite à 22,893 champs on a donc de la marge. Cette option n’est présente qu’à partir de la V5. Vous pouvez l’activer à partir de l’interface notes ou faire un « load compact –K ».
Pour l’activation, il ne faut pas que la base soit indexée. Si elle l’est, désactivez l’indexation, lancez le compact et relancez l’indexation.

Comment savoir si on est prés de la limite ?
A défaut de l’inclure dans Domino (ce qui au passage est vraiment dommage), IBM nous a développé un petit outil du nom de Itemdef.exe. Vous pouvez le télécharger ici.

Doit-on vraiment s’inquiéter de cette limite ?
Pas pour les bases applicatives. Il faut vraiment avoir une application hors du commun pour atteindre cette limite. Mais si vous doutez ou même par curiosité, n’hésitez pas à faire le test.

Par contre le vrai danger se situ au niveau de l’annuaire du domaine. Le names possède énormément de champs et en ajoute un bon paquet dans le template de la version 6.

Pour vous en persuader voici un petit test. J’ai créé une base sur mon serveur à partir du modèle pubnames V6. Voici ce que m’indique Itemdef juste après cette création sans qu’il n’y ai un seul document dans la base :

Comme vous pouvez le voir, la table UNK est déjà pleine à 81%.

J’ajoute simplement un document de policies et regardez le résultat :

On est déjà au maximum. Imaginez donc l’impact que cela peut avoir lors d’une migration.

Si sur la même base j’active « allow more fields in database » je retombe à 11% :

Conclusion
La taille de la table UNK de l’annuaire du domaine est loin d’être un facteur à négliger. Certain l’on fait et ils s’en sont mordus les doigts. C’est arrivé chez un très gros client Français qui a planté plus de 400 serveurs en moins d’une demie journée. So be careful of this F@ !$ ?@! limitation.

Commentaires

1. Michael 09/01/2007 13:22:53

Question subsidiaire...

comment fait-on pour faire le ménage dans cette fameuse Table UNK...

2. Massilia 09/01/2007 14:01:37

Cette table peut-elle être mise à jour?

On créer parfois des champs qui ne servent plus par la suite.. Mais on les retrouve toujours dans les colonnes de vues....

3. YoGi 09/01/2007 14:43:48

Et si on cochait systématiquement "allow more fields" et qu'on ne s'en souciait pas ?

4. kday 09/01/2007 18:57:14

Merci beaucoup pour cette note, car je ne connaissais la table UNK.

k

5. Denandre 09/01/2007 20:02:41

Moi je connais un outil qui devrait offrir la possibilité de voir (et éditer) cette table ...

6. julien 10/01/2007 11:00:08

@Michael et Massilia : Pour mettre à jour cette table il faut faire un compactage par copie : Load compact database.nsf -c

@Yogi : Oui tu as raison sauf que ce n'est pas une option par défaut, il faut donc penser à la mettre. De plus je ne pense pas que du coup ta base soit compatible avec des clients V4 aprés un downgrade de ton ODS. En V5 il y a aussi une limitation liée à la rechercher sur les noms de champ et de masques.

@Kday : Merci.

@Denandre : C'est cool mais c'est quoi l'outil ?

7. Michel 10/01/2007 21:06:37

Merci beaucoup Julien pour ce super article et les différents articles publié sur ton blog.

8. Jacques 11/01/2007 08:50:59

Il y a un rès bon article à ce sujet dans the view d'avril 2003

9. Benoit 11/01/2007 10:31:28

Julien, un truc qui n'a rien à voir, ya peut etre un bug sur ton blog : sur l'article "ARP spoofing", il y a affiché "19 commentaires", mais si on clique sur l'article on n'en voit que 4 !

10. julien 11/01/2007 11:55:45

@Michel : Thanks !

@Jacques : J'aimerai être assez riche pour être abonné à The View mais ce n'est malheureusement pas le cas . Mais si tu as l'article en pdf il m'intéresse énormément (comme tout les articles de The View) !

@Benoit : Oui j'ai un pb avec les robots qui me bombardent de commentaire. Ce devrais être réglé bientôt.