Discussion :

[supertom]

Salut à tous.

J'ai une table de ma base de donnée qui possède un champ auto-incrémenté.
Lorsque j'insère des valeurs, tous se passe bien. Mais à un moment, pour une insertion comme les autres, le champ auto-incrémenté passe de valeurs "normales "(1,2,3,4,5...) à une valeurs bizarre (qqc comme : 500000000002). Et il continue à s'incrémenter à partir de cette valeur ensuite.
Non pas que cela gêne le fonctionnement de mon application, mais je trouve ce fonctionnement bizarre et j'aimerai le comprendre.
Si quelqu'un pouvait me l'expliquer il serait le bienvenue.
Merci d'avance

[Roller]

Pour éviter ce saut, il te faut modifier la propriété identity_gap de ta table.
Plus de détails ici:
http://sypron.nl/idgaps.html

[mpeppler]

La valeur du champ identity le plus élevé est enregistré sur la page de guarde de la table. Pour éviter d'écrire cette page chaque fois qu'il y a un insert ASE pré-alloue un range de valeur.

Quand le serveur est arrêté normalement ASE écrit la valeur la plus élevée effectivement utilisée, mais quand ASE est arrêté brutalement (shutdown with nowait) ASE ne sait pas quelle est la valeut la plus élevée utilisée, et de ce fait repart à partir du bloc suivant.

Par défaut la préallocation se fait sur 0.5% de la taille possible du champ (p.ex. si c'est un numeric(10) l'allocation est de 5000000).

Tout ceci est configurable. Premièrement via l'option 'identity burning set factor' (sp_configure). Deuxièment, pour ASE 12.x on peut spécifier un gap maximum lors de la création de la table (with identity_gap = xxx), ou via sp_chgattribute.

Plus d'info sur ces problèmes à http://www.sypron.nl/id_gaps.html

Michael

[Fabien Celaia]

A relever cependant que l'identity doit être garant de l'unicité et non de la séquence. Le comportement est donc bizarre, mais tout à fait correct...

[mpeppler]

Absolument.

Il faut cependant faire attention - il y a une tendance à déclarer les colonnes identity comme numeric(18,0) voir numeric(36,0). Si ces colonnes sont ensuites utilisées dans des applications (VB, C, Java, etc) et que les valeurs sont mappées sur des variables applicatives de type "int" (soit 32 bit) alors on risque d'avoir un overflow.

Le numeric() le plus grand qui tient dans une variable 32 bit est numeric(9,0).

Michael

[matta]

Bonjour a tous,

tout d'abord je tiens a vous dire
combien la compétence des personnes qui
animent ce forum me surprend toujours

Dans le cadre d'une action corrective d'identity
qui font des sauts importants.

est ce quelqu'un connait
sp_configure "identity burning set factor", 10
(ou sp_configure "identity burning set factor", 1)
a quoi correspond cette commande ?

est elle identique a sp_chgattribute 'MA_TABLE', 'identity_gap', 1 ?

ASE 12.5

[mpeppler]

Non, ce n'est pas identique.

Le "identity burn set factor" est un ratio - la valeur par défaut (5000) implique que l'on va pré-allouer un range qui correspond à 5000 * 10^-7 * 10^(precision de la colonne identity). Donc pour 5000 on va préallouer 5000000 valeurs.

Le "identity_gap" est au contraire une valeur absolue - 1, 10, 100, etc. et c'est le gap maximal qui peut se produire en cas d'arrêt brutal du serveur.

A noter que les gaps se produisent parce que la valeur de l'identity la plus élevée est enregistrée sur la page de garde (OAM page) de la table, et que plus le gap possible est petit, plus cette page doit être mise à jour souvent. Si c'est une table avec un grand nombre d'insert par minute il faut mettre un gap relativement important pour ne pas compromettre la performance des inserts.

Michael