Ripristina seed identità dopo aver eliminato i record in SQL Server

Ho inserito i record in una tabella del database di SQL Server. La tabella aveva una chiave primaria definita e il seed dell'identità di incremento automatico è impostato su "Sì". Questo viene fatto principalmente perché in SQL Azure, ogni tabella deve avere una chiave primaria e un'identità definite.

Ma dal momento che devo eliminare alcuni record dalla tabella, il seme identità per quelle tabelle sarà disturbato e la colonna dell'indice (che viene generata automaticamente con un incremento di 1) verrà disturbata.

Come posso ripristinare la colonna identità dopo aver eliminato i record in modo che la colonna abbia una sequenza in ordine numerico crescente?

La colonna Identity non viene utilizzata come chiave esterna in nessun punto del database.

Il DBCC CHECKIDENTcomando di gestione viene utilizzato per ripristinare il contatore di identità. La sintassi del comando è:

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

Esempio:

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

Non era supportato in una versione precedente del database SQL di Azure, ma ora è supportato.

Si noti che l' new_reseed_valueargomento è variato tra le versioni di SQL Server in base alla documentazione :

Se le righe sono presenti nella tabella, la riga successiva viene inserita con il valore new_reseed_value . Nella versione SQL Server 2008 R2 e precedenti, la riga successiva inserita utilizza new_reseed_value + il valore di incremento corrente.

Tuttavia, trovo queste informazioni fuorvianti (in realtà è semplicemente sbagliato) perché il comportamento osservato indica che almeno SQL Server 2012 utilizza ancora new_reseed_value + la logica del valore di incremento corrente. Microsoft è persino in contraddizione con la propria Example Ctrovata sulla stessa pagina:

C. Forzare il valore di identità corrente su un nuovo valore

L'esempio seguente forza il valore di identità corrente nella colonna AddressTypeID nella tabella AddressType su un valore di 10. Poiché la tabella ha righe esistenti, la riga successiva inserita utilizzerà 11 come valore, ovvero il nuovo valore di incremento corrente definito per il valore della colonna più 1.

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

Tuttavia, tutto ciò lascia un'opzione per comportamenti diversi nelle versioni più recenti di SQL Server. Immagino che l'unico modo per essere sicuri, fino a quando Microsoft non chiarirà le cose nella sua stessa documentazione, sia quello di eseguire test effettivi prima dell'uso.

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

Dove 0 è il identityvalore iniziale

Va notato che SE tutti i dati vengono rimossi dalla tabella tramite la DELETE(ovvero nessuna WHEREclausola), quindi fino a quando le autorizzazioni lo consentono, e b) non ci sono FK che fanno riferimento alla tabella (che sembra essere il caso qui), TRUNCATE TABLEsarebbe preferibile usare come fa un più efficiente DELETE e reimposta il IDENTITYseme allo stesso tempo. I seguenti dettagli sono presi dalla pagina MSDN per TRUNCATE TABLE :

Rispetto all'istruzione DELETE, TRUNCATE TABLE presenta i seguenti vantaggi:

• Viene utilizzato meno spazio per il registro delle transazioni.

  L'istruzione DELETE rimuove le righe una alla volta e registra una voce nel registro delle transazioni per ogni riga eliminata. TRUNCATE TABLE rimuove i dati deallocando le pagine di dati utilizzate per archiviare i dati della tabella e registra solo le deallocazioni di pagine nel registro delle transazioni.

• Vengono generalmente utilizzati meno blocchi.

  Quando l'istruzione DELETE viene eseguita utilizzando un blocco di riga, ogni riga nella tabella viene bloccata per l'eliminazione. TRUNCATE TABLE blocca sempre la tabella (incluso un blocco dello schema (SCH-M)) e la pagina ma non ogni riga.

• Senza eccezioni, nella tabella rimangono zero pagine.

  Dopo l'esecuzione di un'istruzione DELETE, la tabella può ancora contenere pagine vuote. Ad esempio, le pagine vuote in un heap non possono essere deallocate senza almeno un blocco tabella esclusivo (LCK_M_X). Se l'operazione di eliminazione non utilizza un blocco tabella, la tabella (heap) conterrà molte pagine vuote. Per gli indici, l'operazione di eliminazione può lasciare indietro pagine vuote, sebbene queste pagine vengano rapidamente dislocate da un processo di pulizia in background.

Se la tabella contiene una colonna identità, il contatore per quella colonna viene reimpostato sul valore seed definito per la colonna. Se non è stato definito alcun seme, viene utilizzato il valore predefinito 1. Per conservare il contatore di identità, utilizzare invece CANC.

Quindi il seguente:

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

Diventa solo:

TRUNCATE TABLE [MyTable];

Si prega di consultare la TRUNCATE TABLEdocumentazione (collegata sopra) per ulteriori informazioni sulle restrizioni, ecc.

Sebbene la maggior parte delle risposte stia suggerendo RESEED a 0, ma molte volte è necessario eseguire il resed al prossimo ID disponibile

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)

Questo controllerà la tabella e ripristinerà l'ID successivo.

Ho provato a @anil shahsrispondere e ha ripristinato l'identità. Ma quando è stata inserita una nuova riga ha ottenuto il identity = 2. Quindi invece ho modificato la sintassi in:

DELETE FROM [TestTable]

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

Quindi la prima riga otterrà l'identità = 1.

Anche se la maggior parte delle risposte sono suggerendo RESEEDa 0, e mentre alcuni vedono questo come un difetto per TRUNCATEDle tabelle, Microsoft ha una soluzione che esclude laID

DBCC CHECKIDENT ('[TestTable]', RESEED)

Questo verificherà la tabella e ripristinerà alla successiva ID. Questo è disponibile da MS SQL 2005 ad oggi.

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

l'emissione del comando 2 può fare il trucco

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

il primo reimposta l'identità su zero e il successivo la imposterà sul prossimo valore disponibile - jacob

@Giacobbe

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

Ha funzionato per me, ho solo dovuto cancellare tutte le voci prima dalla tabella, quindi ho aggiunto quanto sopra in un punto di trigger dopo l'eliminazione. Ora ogni volta che cancello una voce viene presa da lì.

Truncate la tabella è preferita perché cancella i record, reimposta il contatore e recupera lo spazio su disco.

Deletee CheckIdentdovrebbe essere usato solo dove le chiavi esterne ti impediscono di troncare.

Reimposta colonna identità con nuovo ID ...

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

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

Questa è una domanda comune e la risposta è sempre la stessa: non farlo. I valori di identità devono essere trattati come arbitrari e, come tali, non esiste un ordine "corretto".

Esegui questo script per ripristinare la colonna identità. Dovrai apportare due modifiche. Sostituisci tableXYZ con qualunque tabella devi aggiornare. Inoltre, il nome della colonna identità deve essere eliminato dalla tabella temporanea. Questo è stato istantaneo su una tabella con 35.000 righe e 3 colonne. Ovviamente, esegui il backup della tabella e prima prova questo in un ambiente di test.

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)

Ciò imposterà il valore dell'identità corrente su 0.

Inserendo il valore successivo, il valore dell'identità viene incrementato a 1.

Utilizzare questa procedura memorizzata:

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'

Sto solo rivisitando la mia risposta. Mi sono imbattuto in un comportamento strano in SQL Server 2008 R2 di cui dovresti essere a conoscenza.

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

La prima selezione produce 0, Item 1.

Il secondo produce 1, Item 1. Se si esegue il ripristino subito dopo la creazione della tabella, il valore successivo è 0. Onestamente, non mi sorprende che Microsoft non riesca a ottenere correttamente queste cose. L'ho scoperto perché ho un file di script che popola le tabelle di riferimento che a volte eseguo dopo aver ricreato le tabelle e talvolta quando le tabelle sono già state create.

Per fare questo uso il seguente script. C'è solo uno scenario in cui produrrà un "errore", ovvero se hai eliminato tutte le righe dalla tabella, ed IDENT_CURRENTè attualmente impostato su 1, ovvero c'era solo una riga nella tabella per cominciare.

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)
;

Per una completa ELIMINA righe e reimpostare il conteggio IDENTITÀ, utilizzo questo (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

Reseeding a 0 non è molto pratico a meno che non si stia ripulendo il tavolo nel suo insieme.

altro saggio la risposta data da Anthony Raymond è perfetta. Ottieni prima il massimo della colonna identità, quindi esegui il seeding con max.

Ho provato a farlo per un gran numero di tavoli durante lo sviluppo, e questo funziona come un incantesimo.

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

Quindi, devi prima impostarlo su 1, quindi impostarlo sull'indice più alto delle righe presenti nella tabella. Riposo facile e veloce dell'idex.

È sempre meglio usare TRUNCATE quando possibile invece di eliminare tutti i record in quanto non utilizza anche lo spazio di registro.

Nel caso in cui sia necessario eliminare e ripristinare il seed, tenere sempre presente che se la tabella non è mai stata popolata e si è utilizzato, il DBCC CHECKIDENT('tablenem',RESEED,0) primo record otterrà identità = 0 come indicato nella documentazione di msdn

Nel tuo caso ricostruisci solo l'indice e non preoccuparti di perdere la serie di identità in quanto questo è uno scenario comune.

Primo: specifica dell'identità Solo: "No" >> Salva Database Esegui progetto

Successivamente: Specifica dell'identità Solo: "SÌ" >> Salva database Esegui progetto

Il tuo ID database, PK Inizia da 1 >>