[Sequence] Encore et toujours des sauts

Version imprimable

15/10/2009, 13h19
elkamaro

[Sequence] Encore et toujours des sauts
Bonjour à tous,
j'ai été confronté à un problème de saut de séquence il y'a quelques jours.
Comme la séquence n'est pas souvent utilisé je l'ai modifié en enlevant le cache comme ceci :
Code:

1 2 3 4 5 6 7 CREATE SEQUENCE seq_unit START WITH 41089 MAXVALUE 999999999999999999999999999 MINVALUE 1 NOCYCLE NOCACHE NOORDER;
Aujord'hui encore soit un mois plutard, un utilisateur m'appelle et me dit "j'ai encore des sauts dans mes numéro .... :("
Je revérifie la table et je m'apercois qu'il y'a encore des sauts régulier et de valeur différents (4, 10 ....)
1- avec le script ci-dessous, vous me validez bien qu'il n'y aura pas de problème de cache etc .... ?

Ma sequence n'est utilisé par aucun élément de la base (sauf deux trigger inactif et qui font un appel seq_unit.currval)

J'en suis donc à penser que le problème pourrait venir du coté développeur mais je n'ai pas accés à leur code.
Ce que je veux donc faire avant de leur taper dessus , et c'est pour cela que je demande votre aide et voici mes questions
2- Les developpeurs ont ils la possibilité de faire directement dans leur code "seq_unit.nextval" quel que soit le language utilisé
3- est il possible de mettre en place un mécanisme qui me permet de savoir quand est ce que la séquence est appelé avec "un nextval" (je n'ai pas la possibilité d'activer l'audit de la base ..... infogérance problème de paperasse ....) ?
4- Y'a t il d'autres objet/spécificité à vérifié dans la base qui pourrait généré ses sauts ?

Merci de m'avoir lu et merci pour vos réponses
15/10/2009, 13h57
mnitu

Utiliser une séquence pour une série numérique où il ne doit pas y avoir des trous est une erreur de conception. Une séquence ne pourrait jamais garantir ça.
Donc la question est: avez-vous vraiment besoin d'une série numérique monotone est sans perte des valeurs ?
15/10/2009, 14h37
elkamaro

Citation:

Envoyé par mnitu

Utiliser une séquence pour une série numérique où il ne doit pas y avoir des trous est une erreur de conception. Une séquence ne pourrait jamais garantir ça.
Donc la question est: avez-vous vraiment besoin d'une série numérique monotone est sans perte des valeurs ?

Bonjour et merci pour votre réponse

Oui effectivement, on a besoin d'une série numérique incrémentale par 1 sans perte de valeur (il n'y jamais de suppression sur cette table d'ailleurs)

Je pense que la conception de cette base a besoin de cette séquence car en effet elle génère une clé qui est utilisée dans plusieurs tables pour la même donnée (qu'on retrouve donc dans plus table)

qu'en dites vous ?
15/10/2009, 14h53
Waldar
Vous pouvez conserver la séquence (avec des trous) et après coup calculer la série avec un simple select :
Code:

1 2 select row_number() over(order by seq_unit asc) from MaTable
Evidement celà peut s'avérer coûteux si votre table comporte des millions de lignes.

Qu'est-ce qui est dérangeant pour vous dans les trous ?
15/10/2009, 15h02
elkamaro
Bonjour,

En fait, c'est l'utilisateur qui a besoin de garder tous le temps une serie de numéro qui s'incrémente (un genre de numéro de commande qui s'incremente de 1 à chaque fois)
il a besoin de cette cohérence car il voudrait par exemple effectué des traitement derrière (lesquels je ne sais pas)

8-)
Citation:
Envoyé par Waldar

Vous pouvez conserver la séquence (avec des trous) et après coup calculer la série avec un simple select :

Code:

1 2 select row_number() over(order by seq_unit asc) from MaTable

Evidement celà peut s'avérer coûteux si votre table comporte des millions de lignes.

Qu'est-ce qui est dérangeant pour vous dans les trous ?
15/10/2009, 15h19
elkamaro

Bon, en cherchant un peu a droite a gauche, j'en arrive a ceci

1/ soit il y'a des sessions qui commence une transaction utilisant cette séquence puis qui ne se termine pas, un rollback est donc joué sur oracle (une séquence est toujours incrémenté indépendamment du commit/rollback d'une transaction (cf mealink 1026750.6)

2/ soit les développeurs se sont gouré dan le code en incrémentant la dite séquence avant d'en avoir réellement besoin et ensuite il ne l'utilise pas

qu'en pensez vous ?
15/10/2009, 15h21
GoLDoZ

Dans les deux cas, il va être compliqué de gérer ces utilisations "abusives"...
15/10/2009, 15h52
elkamaro

Citation:

Envoyé par GoLDoZ

Dans les deux cas, il va être compliqué de gérer ces utilisations "abusives"...

encore pour le second cas, je vais peut etre allé voir cela avec les développeurs pour revoir leur code :calim2:

mais le premier cas, c'est cause perdu 8O
15/10/2009, 16h23
mnitu

Citation:

Envoyé par elkamaro

encore pour le second cas, je vais peut etre allé voir cela avec les développeurs pour revoir leur code :calim2:

mais le premier cas, c'est cause perdu 8O

Il me semble que j'ai le déjà dit dans ma première intervention.
Rien dans ce que vous avez écrit n'implique pas que vous avez vraiment besoin d'une série sans trous. Dans ce cas utilisez la séquence et oubliez les trous :lol:
15/10/2009, 16h48
elkamaro

Effectivement mnitu tu avait et tu as toujours raison :D

sinon avez vous une solution pour ceci :

Citation:

3- est il possible de mettre en place un mécanisme qui me permet de savoir quand est ce que la séquence est appelé avec "un nextval" (je n'ai pas la possibilité d'activer l'audit de la base ..... infogérance problème de paperasse ....) ?
4- Y'a t il d'autres objet/spécificité à vérifié dans la base qui pourrait généré ses sauts ?
15/10/2009, 17h18
mnitu

Citation:

Envoyé par elkamaro

...sinon avez vous une solution pour ceci :

Je ne pense pas. Les séquences sont gérés via la table sys.seq$ Pour une séquence avec nocache ( ?!) la valeur de la colonne HighWater est incrémentée à chaque nextval. Mais quelque un qui pourrait utiliser cette information pourrait très probablement activer l’audit.
Dans le cas général, oui : pour exemple le mécanisme de cache. Mais au lieu de chercher que est-ce que fait une séquence de perdre des valeurs, je me poserais la question : ai je besoin ou pas. Et ensuite, en fonction de la réponse j’adopterais la séquence ou pas.
16/10/2009, 11h12
elkamaro

Citation:

Envoyé par mnitu

Je ne pense pas. Les séquences sont gérés via la table sys.seq$ Pour une séquence avec nocache ( ?!) la valeur de la colonne HighWater est incrémentée à chaque nextval. Mais quelque un qui pourrait utiliser cette information pourrait très probablement activer l’audit.
Dans le cas général, oui : pour exemple le mécanisme de cache. Mais au lieu de chercher que est-ce que fait une séquence de perdre des valeurs, je me poserais la question : ai je besoin ou pas. Et ensuite, en fonction de la réponse j’adopterais la séquence ou pas.

pour déclenchez l'audit de la base, il faut la redémarrer et ceci est quasiment impossible pour le moment (car base de haute disponibilité h24 et tout et tout ...).
De plus je ne suis que dba junior sur cette base infogérée, tout ne m'est donc pas permis. Je dois juste essayer de fournir une explication du problème dans la mesure du possible

L'autre problème c'est qu'il s'agi d'une base qui tourne depuis des lustre et dont la conception a déjà validé bien avant que je ne sois arrivé.
L'utilisateur nous explique qu'il a forcément besoin que les numéros délivré par cette séquence soient dans l'ordre et sans saut pour ces besoins.

Bon je vais essayer de comprendre comment ces tables sont alimentées et aller taper sur les développeurs en espérant que ces de leur faute :mouarf:

Si ce n'est pas eu, cela voudrait peut être dire que c'est à cause de session qui saute juste aprés avoir appelé la séquence

Merci
16/10/2009, 12h15
elkamaro

Re-moi

je viens de récupérer le code source (vb) utilisé.

Et rien qu'en regardant un tout petit peu, le problème vient des développeur, ils lance des requête d'insert (avec seq_unit.nextval) et dés que la base leur renvoie une erreur (généralement d'inégrité référentiel) il font un rollback

:mrgreen:
16/10/2009, 13h08
mnitu

Citation:

Envoyé par elkamaro

...
Et rien qu'en regardant un tout petit peu, le problème vient des développeur, ils lance des requête d'insert (avec seq_unit.nextval) et dés que la base leur renvoie une erreur (généralement d'inégrité référentiel) il font un rollback
...

Non, le problème vient probablement de la conception. Mais, je suis curieux comment, après avoir découvert ça, vous allez arriver à éliminer le problème.
16/10/2009, 15h17
elkamaro

Citation:

Envoyé par mnitu

Non, le problème vient probablement de la conception. Mais, je suis curieux comment, après avoir découvert ça, vous allez arriver à éliminer le problème.

Le problème ne sera pas effectivement pas éliminer à 100% mais au moins, on va le diminuer de bcp.

Problème de conception, effectivement, nous sommes d'accord la-dessus mais bon, je travaille avec ce que j'ai trouver ici

Je vais devoir en discuter avec le chef de ce projet et ensuite s'il souhaite reconceptualiser sa base, je viendrais vous voir surement pour de l'aide .... :mrgreen:
16/10/2009, 15h24
pachot

Bonjour,

Je résume ce qui a été dit par plusieurs:
Il n'est pas possible d'assigner des numéros de sequence sans trous en mutli-utilisateurs. Le seul moyen serait d'avoir 1 table avec 1 ligne. Chaque transaction commencerait par incremeter le numéro en le vérouillant (update set n=n+1) et donc bloquerait toute transaction concurrente jusqu'à son commit. Car il faut forcément attendre le commit pour avoir le numéro suivant ou le rollback pour avoir le numéro en cours.
-> les sequences ne sont pas faites pour celà puisqu'elles sont faites pour avoir un générateur de numéros performant en forte concurrence.
-> celà peut s'implémenter, mais sérialize tous les traitements (gros pb de scalabilité), comme si tu n'avais qu'une seule session qui accédait à la base.

Cordialement,
Franck.