Исправьте SQL идентификацию сервера и восстановите правильный порядок нумерации

Question

У меня SQL Server 2014 неожиданно перезапустился, и это сломало прямые последовательности идентификаторов с автоматическим приращением на объектах. Все новые сущности, вставленные в таблицы, имеют увеличенные идентификаторы на 10 000.

Скажем, если были сущности с идентификаторами «1, 2, 3», теперь все вновь вставленные сущности похожи на «10004, 10005».

Вот реальные данные:

..., 12379, 12380, 12381, (after the restart) 22350, 22351, 22352, 22353, 22354, 22355

(Дополнительный вопрос: почему он вставил самую первую сущность после перезапуска с 22350? Я подумал, что это должен был быть 22382, поскольку это последний идентификатор к этому моменту 12381 + 10001 = 22382)

Я искал и выяснял причины произошедшего. Теперь я хочу предотвратить подобные ситуации в будущем и исправить текущий скачок. Это рабочий сервер, и пользователи постоянно добавляют новые данные в БД.

ВОПРОС 1

Какие у меня есть варианты?

Мои мысли о как это предотвратить:

1. Использовать последовательности вместо столбцов идентификаторов
2. Отключить флаг T272, повторно заполнить идентификатор, вызывая его запуск с последнего правильного значения (я полагаю, есть такая опция)

Каковы недостатки двух вышеупомянутых? Пожалуйста, посоветуйте несколько новых способов, если есть.

ВОПРОС 2

Я не эксперт в SQL Сервер. А теперь мне нужно нормализовать и скорректировать нумерацию сущностей, поскольку это бизнес-требование. Я думаю, что мне нужно написать скрипт, который обновляет неправильные значения идентификаторов, устанавливая их как правильные Опасно ли обновлять значения идентичности? Некоторые таблицы имеют зависимые записи. Как может выглядеть этот сценарий?

ДРУГАЯ ИНФОРМАЦИЯ

Вот как объявлены мои столбцы идентификаторов (получено с помощью параметра «Создать сценарии» в SSMS):

CREATE TABLE [dbo].[Tasks]
(
    [Id] [uniqueidentifier] NOT NULL,
    [Created] [datetime] NOT NULL,
    ...
    [TaskNo] [bigint] IDENTITY(1,1) NOT NULL

    CONSTRAINT [PK_dbo.Tasks] 
        PRIMARY KEY CLUSTERED ([Id] ASC)
                    WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
                          IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
                          ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

Я также использую Entity Framework 6 для управления базами данных.

Я буду рад предоставить любую другую информацию по запросу, если это необходимо.

Answer 1

Я делал это один раз в выходные дни простоя, и в итоге мне пришлось заново заполнить всю таблицу, отключив вставку идентификатора, а затем обновив каждую строку номерами строк. Это основывалось на правильном порядке сортировки таблиц, чтобы убедиться, что последовательность была правильной.

При обновлении всей таблицы (500 миллионов строк) было создано огромное количество данных журнала транзакций. Убедитесь, что у вас достаточно места для этого, и при необходимости запустите журнал.

Как уже говорилось выше, если вы должны полагаться на столбец идентификаторов, измените его на последовательность. Кроме того, убедитесь, что ваш механизм отката исправен, если во время вставки произошла ошибка и вся последовательность была готова к приращению.