Послідовність повторного використання

У мене є послідовність, яка генерує номери для відстеження об'єктів у моїй системі. Це працювало чудово протягом досить тривалого часу.

Минулого тижня ми помітили, що він починає повторно використовувати значення.

Що, здається, трапляється, що в різні моменти ввечері воно відкинеться до тієї величини, яку він мав попередній день. Потім він продовжить генерувати значення з цієї точки.

Так, наприклад, я міг отримати щось подібне:

10112
+10113
10114
10 115
10116
10 117
+10118
+10113
10114
10 115
10116
...

Здається, не існує жодної схеми, коли це відбувається, тривалість між першим використанням і другим використанням (всього 10 хв. Або кілька годин) або кількість повернутих назад (цілих 1 і кілька сотень).

Я думав про те, щоб простежити трасування (і все ще можливо), але не думаю, що об'єкт послідовності безпосередньо змінюється. Я вважаю, що причина цього полягає в тому, що дата модифікації становить декілька днів і вказує на час, коли ми вручну стикалися зі значенням, щоб спробувати усунути дублікати. (І відтоді ця проблема виникала кілька разів.)

Хтось має уявлення про те, що може спричинити відхилення послідовності та повторне використання значень щовечора?

ОНОВЛЕННЯ: Щоб відповісти на кілька запитань у коментарях:

• @@Version:

  Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 19 жовтня 2012 13:38:57

• Створити сценарій:

  CREATE SEQUENCE [schemaName].[SequenceName] 
    AS [bigint]
    START WITH 410014104
    INCREMENT BY 1
    MINVALUE 410000000
    MAXVALUE 419999999
    CYCLE 
    CACHE 
  GO

• У мене немає унікального обмеження (але я планую його вкласти). Однак це допоможе мені знати лише тоді, коли я повторно використав значення. Не те, що спричинило скидання значень. Я поставив роботу, яка б отримувала нову цінність кожні 5 хв, заощаджуючи її. Скачки часу та вартості не відповідають шаблону.

• Я перевірив Журнали подій, щоб побачити, чи є помилка. Єдина думка, що відбувається: http://support.microsoft.com/kb/2793634 Ми застосовуємо виправлення сьогодні. Я не думаю, що це пов'язано, але це могло бути.

По-перше, якщо ви не хочете дублікатів у цьому стовпці, вкажіть це прямо .

ALTER TABLE dbo.whatever ADD CONSTRAINT uq_that_column UNIQUE (that_column);

(Або ви можете зробити це первинним ключем, або змінити кластерний індекс, або що у вас є ...)

У будь-якому випадку, помилка під час створення дубліката набагато краща, ніж просто сліпо вставлення дубліката, з яким вам просто доведеться розібратися пізніше.

Далі, врахуйте, що SEQUENCE - це просто генератор чисел, і за замовчуванням він має кеш-пам'ять у 50 значень. Залежно від того, як налаштовані ваші транзакції та які інші критичні події відбуваються на сервері, можливо, SQL Server може «забути», що він створив певні значення для вас. Вибачте, але я не знаю, які саме критерії впливають на відтворення цієї помилки. Спосіб обійти це (поки ця помилка не буде вирішена / пояснено ), щоб змінити послідовність для використання NO CYCLEі NO CACHE, наприклад:

ALTER SEQUENCE dbo.mysequence NO CYCLE NO CACHE; 

Зауважте, що NO CACHEможе вплинути на продуктивність та одночасність, але допоможе усунути прогалини, втрачені блоки та, хто знає, можливо, і вашу проблему.

Ви також можете переконатися, що ви перебуваєте на останньому пакеті обслуговування та на CU. На даний момент я рекомендую SP1 та CU10 з 3437 ; Пакет SP2 відсутній, але все ще існує важлива проблема з перебудовами в Інтернеті, які можуть торкнутися вас .