Dela via


Säkerhetskopieringskomprimering (SQL Server)

gäller för:SQL Server

I den här artikeln beskrivs komprimering av SQL Server-säkerhetskopior, inklusive begränsningar, prestandavägning av komprimering av säkerhetskopior, konfiguration av säkerhetskopieringskomprimering och komprimeringsförhållande. Säkerhetskopieringskomprimering stöds i SQL Server-utgåvor: Enterprise, Standard och Developer. Varje utgåva av SQL Server 2008 (10.0.x) och senare kan återställa en komprimerad säkerhetskopia.

Fördelar

  • Eftersom en komprimerad säkerhetskopia är mindre än en okomprimerad säkerhetskopia av samma data kräver komprimering av en säkerhetskopia vanligtvis mindre enhets-I/O och ökar därför vanligtvis säkerhetskopieringshastigheten avsevärt.

    Mer information finns i Prestandapåverkan av att komprimera säkerhetskopior senare i den här artikeln.

Begränsningar

Följande begränsningar gäller för komprimerade säkerhetskopior:

  • Komprimerade och okomprimerade säkerhetskopior kan inte samexistera i en medieuppsättning.

  • Tidigare versioner av SQL Server kan inte läsa komprimerade säkerhetskopior.

  • NTbackups kan inte dela ett band med komprimerade SQL Server-säkerhetskopior.

ZSTD-komprimeringsalgoritm som introducerades i SQL Server 2025

Från och med förhandsversionen av SQL Server 2025 (17.x) är en ny komprimeringsalgoritm, ZSTD, tillgänglig för säkerhetskopieringskomprimering. Den här algoritmen är snabbare och effektivare än föregående MS_XPRESS algoritm.

Du kan använda ZSTD-algoritmen för säkerhetskopieringskomprimering på något av följande sätt:

  • Genom att ange alternativet WITH COMPRESSION (ALGORITHM = ZSTD) i kommandot BACKUP Transact-SQL för en specifik säkerhetskopia.
  • Genom att ställa in serverkonfigurationsalternativet för komprimeringsalgoritm för säkerhetskopiering till 3. Det här alternativet anger standardkomprimeringsalgoritmen för säkerhetskopiering till ZSTD för alla säkerhetskopior som använder WITH COMPRESSION alternativet.

Anmärkning

ZSTD-algoritmen är för närvarande i förhandsversion och är endast tillgänglig i förhandsversionen av SQL Server 2025 (17.x).

Prestandapåverkan vid komprimering av säkerhetskopior

Komprimering ökar som standard cpu-användningen avsevärt, och den ytterligare PROCESSOR som förbrukas av komprimeringsprocessen kan påverka samtidiga åtgärder negativt. Därför kanske du vill skapa komprimerade säkerhetskopior med låg prioritet i en session vars CPU-användning begränsas av Resource Governor. För mer information, se Använd Resource Governor för att begränsa CPU-användning med säkerhetskopieringskomprimering (Transact-SQL).

Från och med SQL Server 2022 (16.x) kan du använda integrerad avlastning och acceleration för att komprimera säkerhetskopior och avlasta CPU-resurserna för säkerhetskopieringen.

För att få en bra bild av säkerhetskopieringens I/O-prestanda kan du isolera säkerhetskopieringens I/O till eller från enheter genom att utvärdera följande typer av prestandaräknare:

Information om Windows-räknare finns i Windows-hjälpen. Information om hur du arbetar med SQL Server-räknare finns i Använda SQL Server-objekt.

Beräkna komprimeringsförhållandet för en komprimerad säkerhetskopia

Om du vill beräkna komprimeringsförhållandet för en säkerhetskopia använder du värdena för säkerhetskopieringen i de backup_size och compressed_backup_size kolumnerna i tabellen för säkerhetskopieringsuppsättningens historik enligt följande:

backup_size:compressed_backup_size

Ett 3:1-komprimeringsförhållande anger till exempel att du sparar cirka 66% på diskutrymme. Om du vill fråga efter dessa kolumner kan du använda följande Transact-SQL-instruktion:

SELECT backup_size/compressed_backup_size FROM msdb..backupset;  

Komprimeringsförhållandet för en komprimerad säkerhetskopia beror på vilka data som har komprimerats. En mängd olika faktorer kan påverka det erhållna komprimeringsförhållandet. Viktiga faktorer är:

  • Typ av data.

    Teckendata komprimerar mer än andra typer av data.

  • Överensstämmelse av data mellan rader på en sida.

    Om en sida vanligtvis innehåller flera rader där ett fält innehåller samma värde kan betydande komprimering ske för det värdet. För en databas som innehåller slumpmässiga data eller som bara innehåller en stor rad per sida skulle däremot en komprimerad säkerhetskopia vara nästan lika stor som en okomprimerad säkerhetskopia.

  • Om data krypteras

    Krypterade data komprimerar betydligt mindre än motsvarande okrypterade data. Om data till exempel krypteras på kolumnnivå med Always Encrypted, eller med annan kryptering på programnivå, kanske komprimerade säkerhetskopior inte minskar storleken nämnvärt.

    Mer information om att komprimera databaser som krypterats med transparent datakryptering (TDE) finns i Komprimering av säkerhetskopiering med TDE.

  • Om databasen är komprimerad.

    Om databasen komprimeras kanske inte komprimerade säkerhetskopior minskar deras storlek med mycket, om alls.

Komprimering av säkerhetskopiering med TDE

Från och med SQL Server 2016 (13.x) aktiverar inställningen MAXTRANSFERSIZEstörre än 65536 (64 KB) en optimerad komprimeringsalgoritm för transparent datakryptering (TDE) krypterade databaser som först dekrypterar en sida, komprimerar den och sedan krypterar den igen. Om MAXTRANSFERSIZE inte anges, eller om MAXTRANSFERSIZE = 65536 (64 KB) används, komprimerar säkerhetskopieringskomprimering med TDE-krypterade databaser direkt de krypterade sidorna och kanske inte ger bra komprimeringsförhållanden. Mer information finns i Säkerhetskopieringskomprimering för TDE-aktiverade databaser.

Från och med SQL Server 2019 (15.x) CU5 krävs inte längre inställningen MAXTRANSFERSIZE för att aktivera den optimerade komprimeringsalgoritmen med TDE. Om säkerhetskopieringskommandot har angetts WITH COMPRESSION eller standardserverkonfigurationen för säkerhetskopieringskomprimering är inställd på 1 MAXTRANSFERSIZE ökas automatiskt till 128 000 för att aktivera den optimerade algoritmen. Om MAXTRANSFERSIZE anges i säkerhetskopieringskommandot med värdet > 64K respekteras det angivna värdet. Med andra ord kommer SQL Server aldrig automatiskt att minska värdet, det ökar bara det. Om du behöver säkerhetskopiera en TDE-krypterad databas med MAXTRANSFERSIZE = 65536måste du ange WITH NO_COMPRESSION eller se till att standardinställningen för säkerhetskopieringskomprimering serverkonfiguration är inställd på 0.

Mer information finns i BACKUP (Transact-SQL).

Varning

Om du utför flera säkerhetskopior till en enda säkerhetskopieringsmediauppsättning efter att du har tillämpat SQL Server 2019 CU5 installerar du SQL Server 2019 CU9 (KB13768244) för att lösa ett känt återställningsproblem. Om du inte gör det kan det resultera i säkerhetskopieringar som inte kan återställas. När du har tillämpat SQL Server 2019 CU9 framtvingar INIT säkerhetskopieringsprocessen alternativet, vilket förhindrar att du kombinerar säkerhetskopior av databaser som använder TDE eller har olika databaskrypteringsnycklar (DEK: er) i en enda uppsättning säkerhetskopieringsmedia.

Allokering av utrymme för säkerhetskopieringsfilen

För komprimerade säkerhetskopior beror storleken på den slutliga säkerhetskopieringsfilen på hur komprimerade data är, och detta är okänt innan säkerhetskopieringen är klar. När du säkerhetskopierar en databas med komprimering använder databasmotorn därför som standard en förallokeringsalgoritm för säkerhetskopieringsfilen. Den här algoritmen förallokerar en fördefinierad procentandel av databasens storlek för säkerhetskopieringsfilen. Om det behövs mer utrymme under säkerhetskopieringen växer filen med databasmotorn. Om den slutliga storleken är mindre än det allokerade utrymmet krymper databasmotorn filen till den faktiska slutliga storleken på säkerhetskopian i slutet av säkerhetskopieringen.

Använd spårningsflagga 3042 för att tillåta att säkerhetskopieringsfilen bara växer efter behov för att nå sin slutliga storlek. Spårningsflagg 3042 gör att säkerhetskopieringsåtgärden kringgår eller hoppar över standardalgoritmen för förallokering vid säkerhetskopieringskomprimering. Den här spårningsflaggan är användbar om du behöver spara utrymme genom att endast allokera den faktiska storlek som krävs för den komprimerade säkerhetskopieringen. Att använda den här spårningsflaggan kan dock orsaka en liten prestandaförsevisning (en möjlig ökning av säkerhetskopieringsåtgärdens varaktighet).

Relaterade uppgifter

Nästa steg

Säkerhetskopieringsöversikt (SQL Server)
Ange spårningsflaggor med DBCC TRACEON (Transact-SQL)