Discussion :

[clasix]

Bonjour,

Suite à une panne de courant, le compteur d'incrément auto d'une colonne d'une table de notre base de donnée c'est embrouillé (il a rajouté +500000)...apparement, c'est normal, c'est pour eviter d'éventuel probleme...

2 petites questions (ambigues ) :

###la prochaine valeur d'un enregistrement n'est pas le resulttat de la fonction MAX()+1 ni de COUNT()+1 (bien entendu)...le serveur de base de donnée doit donc sauvegarder cette valeur dans une variable à lui...laquelle???

### Comment est il possible de changer le pas (actuellement de +500000) en quelque chose de bien plus petit ?


Merci d'avance pour vos réponses

Guillaume

[clasix]

dejas une réponse :

Pour configurer le pas, il faut faire :
je cite :

* How do I Configure the burn factor?: The number of identity values that
gets "burned" upon a crash or a shutdown can by found by logging into the
server and typing:
1> sp_configure "identity burning set factor"
2> go

the Default value set upon install is 5000. The number "5000" in this case
is read as ".05% of all the potential identity values you can have in this
particular case will be burned upon an unexpected shutdown." The actual
number depends on the size of the identity field as you specified it when
you created your table.

To set the burn factor, type:

1> sp_configure "identity burning set factor", [new value]
2> go

This is a static change; the server must be rebooted before it takes
effect.



Ma premiere Question tiens toujours

merci

Guillaume

[mpeppler]

L'information est stockées dans une des pages de "garde" de la table (je ne me rappelle plus exactement où - mais je pense que le site de Rob Vershoor doit avoir la réponse - www.sypron.nl/idgaps.html).

Pour gérer le pas, on peut aussi (en 12.0 et plus) utiliser l'attribut "identity_gap" qui est positionable pour chaque table qui a une colonne de type IDENTITY.

Michael

[clasix]

MAGNIFIQUE

probleme réglé grace à mpeppler

Merci

Guillaume

[Fabien Celaia]

C'est dans la page OAM (Object Allocation Map), sauf erreur.

Et le saut vient bien effectivement de ce facteur : le serveur attribue des plages de données pour des raisons de performances. Lors d'un crash, il saute à la plage suivante pour s'éviter un rique de doublon.

En terme de norme, l'identity est garant de l'unicité et non de la séquence.