Migrer IDENTITY-kolonner til Fabric datalager

Gjelder for:✅ Lager i Microsoft Fabric

Denne artikkelen beskriver hvordan man kan bruke SET IDENTITY_INSERT og DBCC CHECKIDENT for å bevare eksisterende identitetsverdier under migrering fra SQL Server, Azure SQL Database eller Azure Synapse Analytics, og sikre referanseintegritet.

Viktige forskjeller fra andre plattformer

Før du migrerer, forstå disse forskjellene i implementeringen IDENTITY i Fabric datalager:

  • IDENTITY Kolonner støtter kun bigint-datatypen .
  • SEED INCREMENT og parametere støttes ikke. Systemet håndterer verdier internt.
  • Verdier er garantert unike, men ikke nødvendigvis sekvensielle. Hull kan oppstå på grunn av den distribuerte beregningsarkitekturen.
  • Fabric datalager håndhever ikke viktige begrensninger.

Migrasjonsstrategi

Ved å bruke IDENTITY_INSERT support kan du migrere identitetsverdier direkte til Fabric datalager tabeller som bruker IDENTITY kolonner:

  1. Lag destinasjonstabeller i Fabric datalager med IDENTITY kolonner.
  2. Bruk SET IDENTITY_INSERT ON den til å sette inn historiske data med de opprinnelige identitetsverdiene bevart.
  3. Kjør DBCC CHECKIDENT med RESEED for å justere identitetsområdet etter migrering.
  4. Oppdater fremmednøkkelreferanser om nødvendig.

Denne tilnærmingen bevarer de opprinnelige identitetsverdiene, opprettholder referanseintegritet på tvers av tabeller, og lar Fabric datalager fortsette å generere unike verdier etter migrering.

Eksempel: Migrer tabeller med IDENTITY-kolonner

Følgende eksempel migrerer en Orders tabell fra en kildeplattform til Fabric datalager samtidig som identitetsverdier bevares.

Trinn 1: Lag en destinasjonstabell med en IDENTITY-kolonne

Lag destinasjonstabellen i Fabric datalager. Primærnøkkelkolonnen bruker:IDENTITY

CREATE TABLE dbo.Orders (
    OrderID BIGINT IDENTITY,
    OrderDate DATE,
    CustomerID BIGINT,
    TotalAmount DECIMAL(18, 2)
);

Trinn 2: Migrer data med IDENTITY_INSERT

Bruk SET IDENTITY_INSERT den til å sette inn historiske data med de opprinnelige identitetsverdiene. Denne metoden bevarer eksisterende ID-er slik at relasjonene mellom tabellene forblir intakte.

-- Migrate Orders with original IDs
SET IDENTITY_INSERT dbo.Orders ON;

INSERT INTO dbo.Orders (OrderID, OrderDate, CustomerID, TotalAmount)
VALUES (101, '2025-01-15', 1, 5000.00),
       (102, '2025-02-20', 2, 3200.00),
       (103, '2025-03-10', 1, 7800.00),
       (104, '2025-04-05', 3, 1500.00);

SET IDENTITY_INSERT dbo.Orders OFF;

For større datasett kan du bruke COPY INTO med IDENTITY_INSERT:

COPY INTO dbo.Orders (OrderID 1, OrderDate 2, CustomerID 3, TotalAmount 4)
FROM 'https://storage.blob.core.windows.net/migration/orders.csv'
WITH (
    FILE_TYPE = 'CSV',
    IDENTITY_INSERT = 'ON'
);

Trinn 3: Såd identitetskolonner på nytt

Etter å ha migrert data, kjør DBCC CHECKIDENT med RESEED på hver tabell. Denne operasjonen skanner alle brukte identitetsområder og justerer neste verdi for å unngå kollisjoner med migrerte data:

DBCC CHECKIDENT('dbo.Orders', RESEED);

Trinn 4: Verifiser migreringen og test nye innsettinger

Bekreft at de migrerte dataene er intakte og at nye innsettinger mottar automatisk genererte verdier som ikke overlapper med migrerte verdier:

-- Verify migrated data
SELECT * FROM dbo.Orders ORDER BY OrderID;

-- Insert a row that receives an automatically generated ID
INSERT INTO dbo.Orders (OrderDate, CustomerID, TotalAmount)
VALUES ('2025-05-01', 1, 2500.00);

-- Verify that new IDs don't overlap with migrated data
SELECT * FROM dbo.Orders ORDER BY OrderID;

Beste fremgangsmåter

  • Alltid så etter migrasjon. Kjør DBCC CHECKIDENT('table_name', RESEED) etter hver tabellmigrering for å forhindre identitetsverdikollisjoner.
  • Bruk COPY INTO for store datasett. For massemigrering av store tabeller COPY INTO gir bedre IDENTITY_INSERT ON ytelse enn rad-for-rad-setninger INSERT .
  • Valider referanseintegritet. Etter migrering, verifiser at fremmede nøkkelverdier i barnetabeller refererer til gyldige rader i foreldretabeller.

Relatert innhold

  • Last updated on