J'utilise DB2 V9 sur LUW.
J'ai une colonne définie comme ceci:
J'aimerais connaître la meilleure façon de déterminer la valeur suivante pour la colonne ID la prochaine fois qu'un enregistrement est inséré dans la table.
J'utiliserai ces informations pour écrire un script pour faire une vérification "de santé mentale" sur la table que l'identité est toujours intacte et que sa valeur suivante est supérieure à la valeur la plus élevée dans la colonne ID.
Je ne veux pas simplement réinitialiser la valeur aveuglément. Si la table ne passe pas la vérification de la santé mentale, je veux être notifiée afin que je puisse déterminer ce qui cause l'identité "wacked".
"ID" Bigint Not NULL généré par défaut de
Comme identité (commencez par 1, incrément de 1, cache 20,
Pas de mintane, pas de maxvalue, pas de cycle, sans ordre),
3 Réponses :
Vous ne pouvez pas déterminer la prochaine identité. Même si vous pouvez utiliser le risque des données étant hors de synchronisation au moment où vous essayez de créer un nouvel enregistrement. La seule chose à faire est de créer un nouvel enregistrement et d'obtenir la nouvelle identité, faites votre chèque, puis mettez à jour l'enregistrement avec le reste des données.
Vous pouvez utiliser SELECT IDEN_CURRENT ("YOURBABENAME") pour obtenir le dernier généré. Cela a la même réserve que celle ci-dessus. Cela fonctionne dans T-SQL, pas sûr de la saveur DB2.
Je ne pense pas que l'identité précédente fonctionnera car, dans le cas d'une charge fraîche, il n'aurait peut-être pas été une identité précédente. Sauf si une réparation définit également l'identité précédente?
Votre idée de créer un nouvel enregistrement pourrait fonctionner. Je ne veux pas remplir le record cependant. Ceci est juste un chèque et non impliqué dans la création d'enregistrements. Je pourrais créer un nouvel enregistrement, obtenir la valeur de la colonne Identifier, puis faire une annulation. Est-ce que quelqu'un sait si faire un rollback fait aussi un retour sur la valeur de la graine? Je préférerais ne pas avoir d'incrément de valeur de semences à chaque fois que je passe le test.
C'est la voie à suivre. Ne vous inquiétez pas des lacunes. Même avec un entier non signé 32 bits, vous pouvez insérer 1000 rangées par seconde, 24 heures par jour, pendant 136 ans avant de s'épuiser.
Je ne pense pas que cela fonctionnera comme vous vous attendez. Considérez le cas où une ligne est insérée, puis avant que une autre ligne soit insérée, cette rangée est supprimée. À ce stade, l'ID autogénéré sera (au moins) 2 supérieur à la valeur la plus élevée dans la DB et ce sera correct. Si vous pouvez garantir qu'aucune suppression n'a eu lieu, cela pourrait fonctionner, mais je ne suis pas sûr de quoi l'utilisation serait.
Essentiellement, vous vérifiez si les opérations très élémentaires du logiciel DB fonctionnent et, si elles ne sont pas, qu'allez-vous faire? Changer les vendeurs?
Si le cas est que vous souhaitez simplement réexécuter la colonne d'identité, effectuez une sélection de SELECT (ID) et réessayez la colonne dans la même transaction. Vous pouvez être sûr que aucun nouveau enregistrement n'est inséré lorsque la colonne est réalisée en appliquant une sémantique de transaction de niveau d'isolement sérialisable.
Je ne vérifie pas si les opérations de base de DB2 fonctionnent. Un exemple de ce que je pourrais attraper est une opération de charge mal exécutée. Je peux courir mon script tous les jours avant le début des affaires. Si je trouve un problème, je peux suivre qui / ce qui modifie la table touchée et que vous avez une discussion de la manière appropriée de charger des données. Je serai heureux d'obtenir quelques faux positifs pour le cas des données supprimées. Si je reçois trop de faux positifs, je ne peux que tester une plus grande gamme que 1.
@Michael - Donc, ce que vous dites, c'est que quelqu'un pourrait activer l'insertion d'identité, puis oublie de réexécuter la colonne pour la définir plus haut que le dernier identifiant dont ils ont inséré ensuite? Vous pouvez tester cela en lisant simplement la valeur ID max, en faisant un insertion avec des données "valides", vérifiant si elle réussit ou échoue et a un identifiant supérieur à celui que vous avez observé, puis supprimant cette ligne - tout dans une seule transaction. Cela introduirait quelques identifiants «vides» dans la séquence, mais détecterait le type de problème que j'ai décrit.
Oui, c'est le type de problème que j'essaie de piéger. J'espère que quelqu'un a une solution qui ne créera pas d'identifiants vides. Ce ne serait pas la fin du monde si je me suis retrouvé avec une pièce d'identité vide chaque fois que je dirigeais le script, mais idéalement, je voudrais éviter cela.
Si la colonne ID est définie sur générée par toujours, vous n'auriez pas de problème avec une charge / importation incorrecte. En outre, la fonction identity_val_local peut être utilisée pour obtenir la valeur d'identité.
Plus sur cette fonction ici
Ceci est pour un test hors ligne à effectuer pendant que la base de données n'est pas utilisée autrement. Il n'y a pas de problèmes avec les personnes insérant des enregistrements de suppression lorsque le test est en cours d'exécution.