Zresetuj ziarno tożsamości po usunięciu rekordów w SQL Server

Wstawiłem rekordy do tabeli bazy danych SQL Server. W tabeli zdefiniowano klucz podstawowy, a ziarno tożsamości automatycznego przyrostu jest ustawione na „Tak”. Odbywa się to przede wszystkim dlatego, że w SQL Azure każda tabela musi mieć zdefiniowany klucz podstawowy i tożsamość.

Ale ponieważ muszę usunąć niektóre rekordy z tabeli, ziarno tożsamości dla tych tabel zostanie zakłócone, a kolumna indeksu (która jest generowana automatycznie z przyrostem 1) zostanie zakłócona.

Jak mogę zresetować kolumnę tożsamości po usunięciu rekordów, aby kolumna miała sekwencję w kolejności rosnącej?

Kolumna tożsamości nie jest używana jako klucz obcy w dowolnym miejscu w bazie danych.

Polecenie DBCC CHECKIDENTzarządzania służy do resetowania licznika tożsamości. Składnia polecenia jest następująca:

DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]

Przykład:

DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO

Nie był obsługiwany w poprzednich wersjach bazy danych SQL Azure, ale jest teraz obsługiwany.

Należy pamiętać, że new_reseed_valueargument jest różny w różnych wersjach SQL Server zgodnie z dokumentacją :

Jeśli wiersze są obecne w tabeli, następny wiersz jest wstawiany z wartością new_reseed_value . W wersji SQL Server 2008 R2 i wcześniejszych, następny wstawiony wiersz używa nowej_reseed_value + bieżąca wartość przyrostu.

Jednak uważam tę informację za mylącą (właściwie po prostu błędną), ponieważ zaobserwowane zachowanie wskazuje, że przynajmniej SQL Server 2012 nadal używa nowej_reseed_value + bieżącej logiki wartości przyrostowej. Microsoft zaprzecza nawet własnej Example Cznalezionej na tej samej stronie:

C. Zmuszenie bieżącej wartości tożsamości do nowej wartości

Poniższy przykład wymusza bieżącą wartość tożsamości w kolumnie AddressTypeID w tabeli AddressType na wartość 10. Ponieważ tabela zawiera istniejące wiersze, następny wstawiony wiersz użyje 11 jako wartości, czyli nowej bieżącej wartości przyrostu zdefiniowanej dla wartość kolumny plus 1.

USE AdventureWorks2012;  
GO  
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);  
GO

Mimo to wszystko pozostawia opcję odmiennego zachowania w nowszych wersjach SQL Server. Myślę, że jedynym sposobem, aby się upewnić, dopóki Microsoft nie wyjaśni rzeczy we własnej dokumentacji, jest wykonanie rzeczywistych testów przed użyciem.

DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO

Gdzie 0 to identitywartość początkowa

Należy zauważyć, że JEŻELI wszystkie dane są usuwane z tabeli za pomocą DELETE(tj. Brak WHEREklauzuli), to tak długo, jak pozwalają na to uprawnienia, i b) nie ma żadnych FK odnoszących się do tabeli (która wydaje się być przypadek tutaj), użycie TRUNCATE TABLEbyłoby preferowane, ponieważ działa bardziej wydajnie DELETE i resetuje IDENTITYziarno w tym samym czasie. Poniższe szczegóły pochodzą ze strony MSDN dla TABELI OBCIĄŻENIA :

W porównaniu do instrukcji DELETE, TRUNCATE TABLE ma następujące zalety:

• Wykorzystywane jest mniej miejsca w dzienniku transakcji.

  Instrukcja DELETE usuwa wiersze pojedynczo i rejestruje wpis w dzienniku transakcji dla każdego usuniętego wiersza. TRUNCATE TABLE usuwa dane poprzez cofnięcie przydziału stron danych używanych do przechowywania danych tabeli i zapisuje tylko dezalokacje stron w dzienniku transakcji.

• Zazwyczaj stosuje się mniej blokad.

  Gdy instrukcja DELETE jest wykonywana przy użyciu blokady wierszy, każdy wiersz w tabeli jest blokowany do usunięcia. TRUNCATE TABLE zawsze blokuje tabelę (w tym blokowanie schematu (SCH-M)) i strony, ale nie każdy wiersz.

• Bez wyjątku w tabeli pozostaje zero stron.

  Po wykonaniu instrukcji DELETE tabela może nadal zawierać puste strony. Na przykład pustych stron w stosie nie można cofnąć bez przynajmniej wyłącznej blokady tabeli (LCK_M_X). Jeśli operacja usuwania nie korzysta z blokady tabeli, tabela (sterta) będzie zawierać wiele pustych stron. W przypadku indeksów operacja usuwania może pozostawić puste strony, chociaż strony te zostaną szybko zwolnione przez proces czyszczenia w tle.

Jeśli tabela zawiera kolumnę tożsamości, licznik dla tej kolumny jest resetowany do wartości początkowej zdefiniowanej dla kolumny. Jeśli nie zdefiniowano nasion, używana jest wartość domyślna 1. Aby zachować licznik tożsamości, użyj zamiast tego DELETE.

Więc następujące:

DELETE FROM [MyTable];
DBCC CHECKIDENT ('[MyTable]', RESEED, 0);

Staje się po prostu:

TRUNCATE TABLE [MyTable];

TRUNCATE TABLEDodatkowe informacje na temat ograniczeń itp. Znajdują się w dokumentacji (link powyżej).

Chociaż większość odpowiedzi sugeruje RESEED na 0, ale wiele razy musimy ponownie przejść do następnego dostępnego Id

declare @max int
select @max=max([Id])from [TestTable]
if @max IS NULL   //check when max is returned as null
  SET @max = 0
DBCC CHECKIDENT ('[TestTable]', RESEED,@max)

Spowoduje to sprawdzenie tabeli i zresetowanie do następnego ID.

Próbowałem @anil shahsodpowiedzieć, a to zresetowało tożsamość. Ale kiedy wstawiono nowy wiersz, dostał identity = 2. Zamiast tego zmieniłem składnię na:

DELETE FROM [TestTable]

DBCC CHECKIDENT ('[TestTable]', RESEED, 0)
GO

Wtedy pierwszy wiersz otrzyma tożsamość = 1.

Mimo, że większość odpowiedzi sugeruje RESEEDsię 0, a gdy niektórzy widzą to jako wada dla TRUNCATEDtabel, Microsoft ma rozwiązanie, która wykluczaID

DBCC CHECKIDENT ('[TestTable]', RESEED)

Spowoduje to sprawdzenie tabeli i zresetowanie do następnej ID. Jest to dostępne od MS SQL 2005 do chwili obecnej.

https://msdn.microsoft.com/en-us/library/ms176057.aspx

wydanie 2 polecenia może załatwić sprawę

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

pierwszy resetuje tożsamość do zera, a następny ustawi następną dostępną wartość - jacob

@Jakub

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

Pracowałem dla mnie, po prostu musiałem najpierw usunąć wszystkie wpisy z tabeli, a następnie dodać powyższe w punkcie aktywacji po usunięciu. Teraz za każdym razem, gdy usuwam, wpis jest pobierany stamtąd.

Truncate tabela jest preferowana, ponieważ czyści rekordy, resetuje licznik i odzyskuje miejsce na dysku.

Deletei CheckIdentpowinny być używane tylko wtedy, gdy klucze obce uniemożliwiają obcięcie.

Zresetuj kolumnę tożsamości z nowym identyfikatorem ...

DECLARE @MAX INT
SELECT @MAX=ISNULL(MAX(Id),0) FROM [TestTable]

DBCC CHECKIDENT ('[TestTable]', RESEED,@MAX)

To jest częste pytanie i odpowiedź jest zawsze taka sama: nie rób tego. Wartości tożsamości należy traktować jako arbitralne i jako takie nie ma „prawidłowej” kolejności.

Uruchom ten skrypt, aby zresetować kolumnę tożsamości. Musisz wprowadzić dwie zmiany. Zastąp tableXYZ dowolnym stołem, który chcesz zaktualizować. Ponadto nazwa kolumny tożsamości musi zostać usunięta z tabeli tymczasowej. Było to natychmiastowe na stole z 35 000 wierszy i 3 kolumnami. Oczywiście wykonaj kopię zapasową tabeli i najpierw wypróbuj ją w środowisku testowym.

select * 
into #temp
From tableXYZ

set identity_insert tableXYZ ON

truncate table tableXYZ

alter table #temp drop column (nameOfIdentityColumn)

set identity_insert tableXYZ OFF

insert into tableXYZ
select * from #temp

DBCC CHECKIDENT (<TableName>, reseed, 0)

Spowoduje to ustawienie bieżącej wartości tożsamości na 0.

Po wstawieniu następnej wartości wartość tożsamości zwiększa się do 1.

Użyj tej procedury składowanej:

IF (object_id('[dbo].[pResetIdentityField]') IS NULL)
  BEGIN
    EXEC('CREATE PROCEDURE [dbo].[pResetIdentityField] AS SELECT 1 FROM DUMMY');
  END
GO

SET  ANSI_NULLS ON
GO
SET  QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE [dbo].[pResetIdentityField]
  @pSchemaName NVARCHAR(1000)
, @pTableName NVARCHAR(1000) AS
DECLARE @max   INT;
DECLARE @fullTableName   NVARCHAR(2000) = @pSchemaName + '.' + @pTableName;

DECLARE @identityColumn   NVARCHAR(1000);

SELECT @identityColumn = c.[name]
FROM sys.tables t
     INNER JOIN sys.schemas s ON t.[schema_id] = s.[schema_id]
     INNER JOIN sys.columns c ON c.[object_id] = t.[object_id]
WHERE     c.is_identity = 1
      AND t.name = @pTableName
      AND s.[name] = @pSchemaName

IF @identityColumn IS NULL
  BEGIN
    RAISERROR(
      'One of the following is true: 1. the table you specified doesn''t have an identity field, 2. you specified an invalid schema, 3. you specified an invalid table'
    , 16
    , 1);
    RETURN;
  END;

DECLARE @sqlString   NVARCHAR(MAX) = N'SELECT @maxOut = max(' + @identityColumn + ') FROM ' + @fullTableName;

EXECUTE sp_executesql @stmt = @sqlString, @params = N'@maxOut int OUTPUT', @maxOut = @max OUTPUT

IF @max IS NULL
  SET @max = 0

print(@max)

DBCC CHECKIDENT (@fullTableName, RESEED, @max)
go

--exec pResetIdentityField 'dbo', 'Table'

Powracam do mojej odpowiedzi. Natknąłem się na dziwne zachowanie na serwerze SQL Server 2008 R2, o którym powinieneś wiedzieć.

drop table test01

create table test01 (Id int identity(1,1), descr nvarchar(10))

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

delete from test01

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

Pierwszy wybór produkuje 0, Item 1 .

Drugi produkuje 1, Item 1. Jeśli wykonasz reset zaraz po utworzeniu tabeli, następna wartość to 0. Szczerze mówiąc, nie jestem zaskoczony, że Microsoft nie może tego poprawnie zrobić. Odkryłem go, ponieważ mam plik skryptu, który zapełnia tabele referencyjne, które czasem uruchamiam po ponownym utworzeniu tabel, a czasem po ich utworzeniu.

Aby to zrobić, używam następującego skryptu. Jest tylko jeden scenariusz, w którym spowoduje „błąd”, czyli usunięcie wszystkich wierszy z tabeli, a IDENT_CURRENTobecnie jest ustawiony na 1, tzn. Na początku był tylko jeden wiersz w tabeli.

DECLARE @maxID int = (SELECT MAX(ID) FROM dbo.Tbl)
;

IF @maxID IS NULL
    IF (SELECT IDENT_CURRENT('dbo.Tbl')) > 1
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 0)
    ELSE
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 1)
    ;
ELSE
    DBCC CHECKIDENT ('dbo.Tbl', RESEED, @maxID)
;

Do pełnego usunięcia wierszy i zresetowania liczby TOŻSAMOŚCI używam tego (SQL Server 2008 R2)

USE mydb

-- ##################################################################################################################
-- DANGEROUS!!!! USE WITH CARE
-- ##################################################################################################################

DECLARE
  db_cursor CURSOR FOR
    SELECT TABLE_NAME
      FROM INFORMATION_SCHEMA.TABLES
     WHERE TABLE_TYPE = 'BASE TABLE'
       AND TABLE_CATALOG = 'mydb'

DECLARE @tblname VARCHAR(50)
SET @tblname = ''

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @tblname

WHILE @@FETCH_STATUS = 0
BEGIN
  IF CHARINDEX('mycommonwordforalltablesIwanttodothisto', @tblname) > 0
    BEGIN
      EXEC('DELETE FROM ' + @tblname)
      DBCC CHECKIDENT (@tblname, RESEED, 0)
    END

  FETCH NEXT FROM db_cursor INTO @tblname
END

CLOSE db_cursor
DEALLOCATE db_cursor
GO

Resesekcja do zera nie jest zbyt praktyczna, chyba że czyścisz stół jako całość.

w przeciwnym razie odpowiedź udzielona przez Anthony'ego Raymonda jest idealna. Zdobądź najpierw kolumnę maks. Tożsamości, a następnie zapisz ją maks.

Podczas programowania starałem się to zrobić dla dużej liczby tabel, a to działa jak urok.

DBCC CHECKIDENT('www.newsType', RESEED, 1);
DBCC CHECKIDENT('www.newsType', RESEED);

Najpierw wymuszasz ustawienie go na 1, a następnie ustawiasz go na najwyższy indeks wierszy obecnych w tabeli. Szybka i łatwa reszta ideksu.

Zawsze lepiej jest użyć TRUNCATE gdy jest to możliwe, zamiast usuwać wszystkie rekordy, ponieważ nie wykorzystuje również miejsca w dzienniku.

W przypadku, gdy potrzebujemy usunąć i zresetować ziarno, zawsze pamiętaj, że jeśli tabela nigdy nie została zapełniona i użyłeś, DBCC CHECKIDENT('tablenem',RESEED,0) to pierwszy rekord uzyska tożsamość = 0, jak podano w dokumentacji msdn

W twoim przypadku odbuduj tylko indeks i nie martw się o utratę serii tożsamości, ponieważ jest to częsty scenariusz.

Po pierwsze: specyfikacja tożsamości Tylko: „Nie” >> Zapisz bazę danych Wykonaj projekt

Następnie: Specyfikacja tożsamości Tylko: „TAK” >> Zapisz bazę danych Wykonaj projekt

Twój identyfikator bazy danych, PK Zacznij od 1 >>