Исключение таблицы из отката транзакции

Question

У нас есть таблица и набор процедур, которые используются для генерации pk-идентификаторов.Таблица содержит последний идентификатор, и процедуры получают идентификатор, увеличивают его, обновляют таблицу и затем возвращают вновь увеличенный идентификатор.

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

Есть ли способ исключить таблицу генерации идентификатора из родительской транзакции, чтобы этого не происходило?

Чтобы добавить подробности в нашу текущуюпроблема ...

Во-первых, у нас есть система, в которую мы готовимся перенести много данных.Система состоит из базы данных ms-sql (2008) и базы данных textml.База данных sql хранит данные менее 3 дней, в то время как textml выступает в качестве архива для всего более старого.База данных textml также использует базу данных sql для предоставления идентификаторов определенных полей.Эти поля в настоящее время являются Identity PK и генерируются при вставке перед публикацией в базу данных texml.Мы не хотим стирать все перенесенные данные через sql, поскольку записи будут заполнять текущую систему, как с точки зрения трафика, так и данных.Но в то же время мы не можем сгенерировать эти идентификаторы, поскольку они являются автоматически увеличивающимися значениями, которые контролирует сервер sql.

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

Answer 1

процедуры получает идентификатор, увеличивает его, обновляет таблицу, а затем возвращает вновь увеличенный идентификатор

Это приведет к взаимоблокировке.Процедура должна увеличиваться и возвращаться в один атомарный шаг, например.с помощью предложения OUTPUT в SQL Server:

update ids
set id = id + 1
output inserted.id
where name= @name;

Вам не нужно беспокоиться о параллелизме.Тот факт, что вы генерируете идентификаторы таким способом, подразумевает, что только одна транзакция может увеличивать идентификатор, потому что обновление будет блокировать только строку.Вы не можете получить дубликаты.Вы получаете полную сериализацию всех операций (т.е. без производительности и низкой пропускной способности), но это другая проблема.И именно поэтому вы должны использовать встроенные механизмы для генерации последовательностей и идентичностей.Они специфичны для каждой платформы: AUTO_INCREMENT в MySQL, SEQUENCE в Oracle, IDENTITY и SEQUENCEв SQL Server (только последовательность в Denali) и т. д.вставить обратно заархивированные записи.Это уже возможно, просто используйте IDENTITY_INSERT:

Позволяет вставлять явные значения в столбец идентификаторов таблицы

Превратить егокогда вы вставляете обратно старую запись, затем выключаете ее:

SET IDENTITY_INSERT recordstable ON;
INSERT INTO recordstable (id, ...) values (@oldid, ...);
SET IDENTITY_INSERT recordstable OFF;

Что касается того, почему сгенерированные вручную идентификаторы сериализуют все операции: любая транзакция, которая генерирует идентификатор, будет блокировать только строку в таблице идентификаторов.Никакая другая транзакция не может прочитать или записать эту строку, пока первая транзакция не зафиксируется или не откатится назад.Поэтому в любой момент может быть только одна транзакция, генерирующая идентификатор таблицы, т.е.сериализации.