Dela via


Datakomprimering

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Microsoft Fabric

SQL Server, Azure SQL Database och Azure SQL Managed Instance stöder rad- och sidkomprimering för radlagringstabeller och index, samt stöd för kolumnarkiv- och kolumnarkivarkivarkivskomprimering för kolumnlagringstabeller och index.

För radlagringstabeller och index använder du funktionen för datakomprimering för att minska databasens storlek. Förutom att spara utrymme kan datakomprimering hjälpa till att förbättra prestanda för I/O-intensiva arbetsbelastningar eftersom data lagras på färre sidor och frågor behöver läsa färre sidor från disken. Extra processorresurser krävs dock på databasservern för att komprimera och dekomprimera data när data utbyts med programmet. Du kan konfigurera rad- och sidkomprimering på följande databasobjekt:

  • En hel tabell som lagras som en heap.
  • En hel tabell som lagras som ett grupperat index.
  • Ett helt icke-grupperat index.
  • En hel indexerad vy.
  • För partitionerade tabeller och index kan du konfigurera komprimeringsalternativet för varje partition och de olika partitionerna i ett objekt behöver inte ha samma komprimeringsinställning.

För kolumnlagringstabeller och index använder alla kolumnlagringstabeller och index alltid kolumnlagringskomprimering och detta är inte användarkonfigurerbart. Använd columnstore-arkiveringskomprimering för att ytterligare minska datastorleken för situationer när du har råd med extra tid och CPU-resurser för att lagra och hämta data. Du kan konfigurera kolumnarkivets arkiveringskomprimering på följande databasobjekt:

  • En hel kolumnlagringstabell eller ett helt grupperat kolumnlagringsindex. Eftersom en kolumnlagringstabell lagras som ett grupperat kolumnlagringsindex har båda metoderna samma resultat.
  • Ett helt icke-grupperat kolumnlagringsindex.
  • För partitionerade columnstore-tabeller och kolumnlagringsindex kan du konfigurera alternativet för arkiveringskomprimering för varje partition, och de olika partitionerna behöver inte ha samma inställning för arkiveringskomprimering.

Anmärkning

Data kan också komprimeras med GZIP-algoritmformatet. Det här är ytterligare ett steg och passar bäst för att komprimera delar av data vid arkivering av gamla data för långsiktig lagring. Data som komprimeras med COMPRESS funktionen kan inte indexeras. Mer information finns i KOMPRIMERA (Transact-SQL).

Överväganden för rad- och sidkomprimering

Tänk på följande när du använder rad- och sidkomprimering:

  • Information om datakomprimering kan komma att ändras utan föregående meddelande i Service Pack eller efterföljande versioner.

  • Komprimering är tillgängligt i Azure SQL Database

  • Komprimering är inte tillgängligt i varje utgåva av SQL Server. Mer information finns i listan över utgåvor och funktioner som stöds i slutet av det här avsnittet.

  • Komprimering är inte tillgängligt för systemtabeller.

  • Komprimering kan tillåta att fler rader lagras på en sida, men ändrar inte den maximala radstorleken för en tabell eller ett index.

  • Det går inte att aktivera en tabell för komprimering när den maximala radstorleken plus komprimeringskostnaderna överskrider den maximala radstorleken på 8 060 byte. Till exempel en tabell som har kolumnerna c1 CHAR(8000) och c2 CHAR(53) inte kan komprimeras på grund av extra komprimeringskostnader. När vardecimalt lagringsformat används utförs kontrollen av radstorlek när formatet är aktiverat. För rad- och sidkomprimering utförs kontrollen av radstorlek när objektet först komprimeras och kontrolleras sedan när varje rad infogas eller ändras. Komprimering tillämpar följande två regler:

    • En uppdatering av en typ av fast längd måste alltid lyckas.
    • Inaktivering av datakomprimering måste alltid lyckas. Även om den komprimerade raden passar på sidan, vilket innebär att den är mindre än 8 060 byte. SQL Server förhindrar uppdateringar som inte får plats på raden när den inte är komprimerad.
  • Data utanför rad komprimeras inte när datakomprimering aktiveras. Till exempel använder en XML-post som är större än 8 060 byte sidor som inte komprimeras.

  • Flera datatyper påverkas inte av datakomprimering. Mer information finns i Hur radkomprimering påverkar lagring.

  • När en lista över partitioner har angetts kan komprimeringstypen anges till ROW, PAGEeller NONE på enskilda partitioner. Om listan över partitioner inte har angetts anges alla partitioner med den datakomprimeringsegenskap som anges i -instruktionen. När en tabell eller ett index skapas anges datakomprimering till NONE om inget annat anges. När en tabell ändras bevaras den befintliga komprimering om inget annat anges.

  • Om du anger en lista över partitioner eller en partition som ligger utom räckhåll genereras ett fel.

  • Icke-grupperade index ärver inte komprimeringsegenskapen för tabellen. Om du vill komprimera index måste du uttryckligen ange komprimeringsegenskapen för indexen. Som standard är komprimeringsinställningen för index inställd på NONE när indexet skapas.

  • När ett klustrat index skapas på en heap ärver det klustrade indexet heapens komprimeringstillstånd om inte ett alternativt komprimeringstillstånd anges.

  • När en heap har konfigurerats för komprimering på sidnivå får sidorna endast komprimering på sidnivå på följande sätt:

    • Data massimporteras med massoptimeringar aktiverade.
    • Data infogas med hjälp av INSERT INTO ... WITH (TABLOCK) syntax och tabellen har inget icke-grupperat index.
    • En tabell återskapas genom att instruktionen ALTER TABLE ... REBUILD körs med komprimeringsalternativet PAGE .
  • Nya sidor som allokerats i en heap som en del av DML-åtgärder använder PAGE inte komprimering förrän heapen har återskapats. Återskapa heapen genom att ta bort och återanvända komprimering, eller genom att skapa och ta bort ett grupperat index.

  • Om du ändrar komprimeringsinställningen för en heap måste alla icke-grupperade index i tabellen återskapas så att de har pekare till de nya radplatserna i heapen.

  • Du kan aktivera eller inaktivera ROW eller PAGE komprimera online eller offline. Aktivering av komprimering på en heap är en tråd för en onlineåtgärd.

  • Kraven på diskutrymme för att aktivera eller inaktivera rad- eller sidkomprimering är desamma som för att skapa eller återskapa ett index. För partitionerade data kan du minska det utrymme som krävs genom att aktivera eller inaktivera komprimering för en partition i taget.

  • Om du vill fastställa komprimeringstillståndet för partitioner i en partitionerad tabell frågar du data_compression kolumnen i sys.partitions katalogvyn.

  • När du komprimerar index kan sidor på lövnivå komprimeras med både rad- och sidkomprimering. Sidor på icke-lövnivå får inte sidkomprimering.

  • På grund av deras storlek lagras datatyper med stora värden ibland separat från normala raddata på specialsidor. Datakomprimering är inte tillgängligt för de data som lagras separat.

  • Tabeller som implementerade vardecimalt lagringsformat i SQL Server 2005 (9.x) behåller den inställningen när den uppgraderas. Du kan använda radkomprimering i en tabell som har vardecimalt lagringsformat . Men eftersom radkomprimering är en superuppsättning av lagringsformatet vardecimalt finns det ingen anledning att behålla lagringsformatet vardecimalt . Decimalvärden får ingen ytterligare komprimering när du kombinerar lagringsformatet vardecimalt med radkomprimering. Du kan använda sidkomprimering för en tabell som har vardecimalt lagringsformat . Kolumnerna för vardecimalt lagringsformat uppnår dock förmodligen inte ytterligare komprimering.

    Anmärkning

    Alla versioner av SQL Server som stöds stöder vardecimalt lagringsformat. Men eftersom datakomprimering uppnår samma mål är det vardecimala lagringsformatet inaktuellt. Den här funktionen tas bort i en framtida version av SQL Server. Undvik att använda den här funktionen i nytt utvecklingsarbete och planera att ändra program som för närvarande använder den här funktionen.

En lista över funktioner som stöds av versionerna av SQL Server i Windows finns i:

Kolumnarkiv- och kolumnarkivarkivkomprimering

Kolumnlagringstabeller och index lagras alltid med kolumnlagringskomprimering. Du kan minska storleken på kolumnlagringsdata ytterligare genom att konfigurera en extra komprimering som kallas arkiveringskomprimering. För att utföra arkiveringskomprimering kör SQL Server Microsoft XPRESS-komprimeringsalgoritmen på data. Lägg till eller ta bort arkiveringskomprimering med hjälp av följande typer av datakomprimering:

  • Använd COLUMNSTORE_ARCHIVE datakomprimering för att komprimera kolumnlagringsdata med arkiveringskomprimering.
  • Använd COLUMNSTORE datakomprimering för att dekomprimera arkiveringskomprimering. Resulterande data fortsätter att komprimeras med kolumnlagringskomprimering.

Om du vill lägga till arkiveringskomprimering använder du ALTER TABLE (Transact-SQL) eller ALTER INDEX (Transact-SQL) med REBUILD alternativet och DATA COMPRESSION = COLUMNSTORE_ARCHIVE.

Till exempel:

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = 1 WITH (
    DATA_COMPRESSION = COLUMNSTORE_ARCHIVE
);

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE_ARCHIVE
);

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE_ARCHIVE ON PARTITIONS (2, 4)
);

Om du vill ta bort arkiveringskomprimering och återställa data till kolumnlagringskomprimering använder du ALTER TABLE (Transact-SQL) eller ALTER INDEX (Transact-SQL) med REBUILD alternativet och DATA COMPRESSION = COLUMNSTORE.

Till exempel:

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = 1 WITH (
     DATA_COMPRESSION = COLUMNSTORE
);

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE
);

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE ON PARTITIONS (2, 4)
);

I nästa exempel anges datakomprimering till columnstore på vissa partitioner och till columnstore-arkivering på andra partitioner.

ALTER TABLE ColumnstoreTable1
REBUILD PARTITION = ALL WITH (
    DATA_COMPRESSION = COLUMNSTORE
        ON PARTITIONS (4, 5),
    DATA COMPRESSION = COLUMNSTORE_ARCHIVE
        ON PARTITIONS (1, 2, 3)
);

Prestanda

När du komprimerar kolumnlagringsindex med arkiveringskomprimering gör detta att indexet går långsammare än kolumnlagringsindex som inte har arkiveringskomprimering. Använd endast arkivkomprimering när du har råd att använda extra tid och CPU-resurser för att komprimera och hämta data.

Fördelen med arkiveringskomprimering är minskad lagring, vilket är användbart för data som inte används ofta. Om du till exempel har en partition för varje månad med data, och det mesta av din aktivitet är för de senaste månaderna, kan du arkivera äldre månader för att minska lagringskraven.

Metainformation

Följande systemvyer innehåller information om datakomprimering för klustrade index:

Proceduren sp_estimate_data_compression_savings (Transact-SQL) kan också tillämpas på kolumnlagringsindex.

Påverkan på partitionerade tabeller och index

När du använder datakomprimering med partitionerade tabeller och index bör du tänka på följande:

  • När partitioner delas med hjälp av -instruktionen ALTER PARTITION ärver båda partitionerna datakomprimeringsattributet för den ursprungliga partitionen.

  • När två partitioner slås samman ärver den resulterande partitionen datakomprimeringsattributet för målpartitionen.

  • Om du vill växla en partition måste datakomprimeringsegenskapen för partitionen matcha komprimeringsegenskapen för tabellen.

  • Det finns två syntaxvariationer som du kan använda för att ändra komprimering av en partitionerad tabell eller ett index:

    • Följande syntax återskapar endast den refererade partitionen:

      ALTER TABLE <table_name>
      REBUILD PARTITION = 1 WITH (
          DATA_COMPRESSION = <option>
      );
      
    • Följande syntax återskapar hela tabellen med hjälp av den befintliga komprimeringsinställningen för alla partitioner som inte refereras till:

      ALTER TABLE <table_name>
      REBUILD PARTITION = ALL WITH (
          DATA_COMPRESSION = PAGE ON PARTITIONS(<range>),
          ...
      );
      

    Partitionerade index följer samma princip med hjälp av ALTER INDEX.

  • När ett klustrat index tas bort behåller motsvarande heappartitioner sin datakomprimeringsinställning om inte partitioneringsschemat ändras. Om partitioneringsschemat ändras återskapas alla partitioner till ett okomprimerat tillstånd. För att släppa ett klustrat index och ändra partitioneringsschemat krävs följande steg:

    1. Släpp det klustrade indexet.
    2. Ändra tabellen med det ALTER TABLE ... REBUILD alternativ som anger komprimeringsalternativet.

    Att släppa ett klustrat index OFFLINE är en snabb åtgärd eftersom endast de övre nivåerna av klustrade index tas bort. När ett klustrat index tas bort ONLINEmåste SQL Server återskapa heapen två gånger, en gång för steg 1 och en gång för steg 2.

Hur komprimering påverkar replikering

När du använder datakomprimering med replikering bör du tänka på följande:

  • När ögonblicksbildsagenten genererar det första schemaskriptet använder det nya schemat samma komprimeringsinställningar för både tabellen och dess index. Komprimering kan inte aktiveras på bara tabellen och inte på indexet.

  • För transaktionsreplikering avgör artikelschemaalternativet vilka beroende objekt och egenskaper som måste skriptas. Mer information finns i sp_addarticle.

    Distributionsagenten söker inte efter prenumeranter på låg nivå när skript tillämpas. Om replikeringen av komprimering har valts misslyckas det att skapa tabellen på nednivåprenumeranter. För en blandad topologi aktiverar du inte replikering av komprimering.

  • För sammanslagningsreplikering åsidosätter publiceringskompatibilitetsnivån schemaalternativen och avgör vilka schemaobjekt som är skriptade.

    För en blandad topologi, om det inte krävs för att stödja de nya komprimeringsalternativen, bör publiceringskompatibilitetsnivån anges till prenumerantversionen på lägre nivå. Om det behövs komprimerar du tabeller på Prenumeranten när de har skapats.

I följande tabell visas replikeringsinställningar som styr komprimering under replikeringen.

Avsikt för användare Replikera partitionsschema för en tabell eller ett index Replikera komprimeringsinställningar Skriptbeteende
För att replikera partitionsschemat och aktivera komprimering på prenumeranten på partitionen. Sann Sann Skript både partitionsschemat och komprimeringsinställningarna.
Replikera partitionsschemat men inte komprimera data på Prenumeranten. Sann Falsk Skriptar ut partitionsschemat men inte komprimeringsinställningarna för partitionen.
Inte för att replikera partitionsschemat och inte komprimera data på prenumeranten. Falsk Falsk Skriptpartitioner eller komprimeringsinställningar används inte.
Om du vill komprimera tabellen i Prenumeranten om alla partitioner komprimeras i Publisher, men inte replikerar partitionsschemat. Falsk Sann Kontrollerar om alla partitioner är aktiverade för komprimering.

Skript ut komprimering på tabellnivå.

Effekt på andra SQL Server-komponenter

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Komprimering sker i databasmotorn och data presenteras för de flesta av de andra komponenterna i SQL Server i ett okomprimerat tillstånd. Detta begränsar effekten av komprimering på de andra komponenterna till följande faktorer:

  • Massimport- och exportåtgärder
    • När data exporteras, även i internt format, matas data ut i okomprimerat radformat. Detta kan göra att storleken på den exporterade datafilen blir betydligt större än källdata.
    • När data importeras konverterar databasmotorn data till komprimerat radformat om måltabellen har aktiverats för komprimering. Detta kan orsaka ökad CPU-användning jämfört med när data importeras till en okomprimerad tabell.
    • När data massimporteras till en heap med sidkomprimering försöker massimportåtgärden komprimera data med sidkomprimering när data infogas.
  • Komprimering påverkar inte säkerhetskopiering och återställning.
  • Komprimering påverkar inte loggleveransen.
  • Datakomprimering är inte kompatibel med glesa kolumner. Därför kan tabeller som innehåller glesa kolumner inte komprimeras och inte heller kan glesa kolumner läggas till i en komprimerad tabell.
  • Om du aktiverar komprimering kan frågeplaner ändras eftersom data lagras med ett annat antal sidor och antal rader per sida.