Dela via

Krymp tempdb-databasen

  • Artikel

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

I den här artikeln beskrivs olika metoder som du kan använda för att krympa tempdb-databasen i SQL Server.

Du kan använda någon av följande metoder för att ändra storleken på tempdb. De första tre alternativen beskrivs i den här artikeln. Om du vill använda SQL Server Management Studio (SSMS) följer du anvisningarna i Krympa en databas.

Metod Kräver omstart? Mer information
ALTER DATABASE Ja Ger fullständig kontroll över storleken på standardfilerna tempdb (tempdev och templog).
DBCC SHRINKDATABASE Nej Fungerar på databasnivå.
DBCC SHRINKFILE Nej Gör att du kan krympa enskilda filer.
SQL Server Management Studio Nej Krymp databasfiler via ett grafiskt användargränssnitt.

Anmärkningar

Som standard konfigureras tempdb-databasen så att den växer automatiskt efter behov. Därför kan den här databasen oväntat växa i tid till en storlek som är större än önskad storlek. Större tempdb databasstorlekar påverkar inte prestandan för SQL Server negativt.

När SQL Server startar återskapas tempdb med hjälp av en kopia av model-databasen och tempdb återställs till den senast konfigurerade storleken. Den konfigurerade storleken är den sista explicita storleken som angavs med hjälp av en ändringsåtgärd för filstorlek, till exempel ALTER DATABASE som använder alternativet MODIFY FILE eller DBCC SHRINKFILE- eller DBCC SHRINKDATABASE-instruktioner. Om du inte behöver använda olika värden eller få en omedelbar lösning på en stor tempdb-databas kan du därför vänta till nästa gång SQL Server-tjänsten startas om, vilket kommer att minska storleken.

Du kan krympa tempdb medan tempdb aktivitet pågår. Du kan dock stöta på andra fel, till exempel blockering, dödlägen och så vidare, som kan förhindra att processen att krympa slutförs. För att säkerställa att en krympning av tempdb lyckas rekommenderar vi därför att du gör detta när servern är i enanvändarläge eller när du stoppar all tempdb aktivitet.

SQL Server registrerar endast tillräckligt med information i tempdb transaktionsloggen för att återställa en transaktion, men inte för att göra om transaktioner under databasåterställningen. Den här funktionen ökar prestandan för INSERT-uttalanden i tempdb. Dessutom behöver du inte logga information för att göra om några transaktioner eftersom tempdb återskapas varje gång du startar om SQL Server. Därför har den inga transaktioner att rulla framåt eller återställa.

Mer information om hur du hanterar och övervakar tempdbfinns i Kapacitetsplanering och Övervaka tempdb-användning.

Använd kommandot ALTER DATABASE

Notera

Det här kommandot fungerar endast på standard tempdb logiska filer tempdev och templog. Om fler filer läggs till i tempdbkan du krympa dem när du har startat om SQL Server som en tjänst. Alla tempdb filer återskapas under starten. De är dock tomma och kan tas bort. Om du vill ta bort ytterligare filer i tempdbanvänder du kommandot ALTER DATABASE med alternativet REMOVE FILE.

Den här metoden kräver att du startar om SQL Server.

  1. Stäng av SQL Server.

  2. Starta instansen i minsta konfigurationsläge i en kommandotolk. Gör detta genom att följa dessa steg:

    1. I en kommandotolk ändrar du till mappen där SQL Server är installerat (ersätt <VersionNumber> och <InstanceName> i följande exempel):

      cd C:\Program Files\Microsoft SQL Server\MSSQL<VersionNumber>.<InstanceName>\MSSQL\Binn

    2. Om instansen är en namngiven instans av SQL Server kör du följande kommando (ersätt <InstanceName> i följande exempel):

      sqlservr.exe -s <InstanceName> -c -f -mSQLCMD

    3. Om instansen är standardinstansen av SQL Server kör du följande kommando:

      sqlservr -c -f -mSQLCMD

      Notera

      Parametrarna -c och -f gör att SQL Server startar i ett minsta konfigurationsläge som har en tempdb storlek på 1 MB för datafilen och 0,5 MB för loggfilen. Parametern -mSQLCMD förhindrar att andra program än sqlcmd tar över enanvändaranslutningen.

  3. Anslut till SQL Server med sqlcmdoch kör sedan följande Transact-SQL kommandon. Ersätt <target_size_in_MB> med önskad storlek:

    ALTER DATABASE tempdb MODIFY FILE
(NAME = 'tempdev', SIZE = <target_size_in_MB>);

ALTER DATABASE tempdb MODIFY FILE
(NAME = 'templog', SIZE = <target_size_in_MB>);

  4. Stäng av SQL Server. Det gör du genom att trycka på Ctrl+C i kommandotolkens fönster, starta om SQL Server som en tjänst och sedan kontrollera storleken på tempdb.mdf- och templog.ldf-filerna.

Använd kommandot DBCC SHRINKDATABASE

DBCC SHRINKDATABASE tar emot parametern target_percent. Det här är den önskade procentandelen ledigt utrymme som finns kvar i databasfilen när databasen har krympts. Om du använder DBCC SHRINKDATABASEkan du behöva starta om SQL Server.

  1. Fastställ det utrymme som för närvarande används i tempdb med hjälp av den sp_spaceused lagrade proceduren. Beräkna sedan procentandelen ledigt utrymme som är kvar för att användas som en parameter till DBCC SHRINKDATABASE. Den här beräkningen baseras på önskad databasstorlek.

    Not

    I vissa fall kan du behöva köra sp_spaceused @updateusage = true för att beräkna om det utrymme som används och hämta en uppdaterad rapport. Mer information finns i sp_spaceused.

    Tänk på följande exempel:

    Anta att tempdb har två filer: den primära datafilen (tempdb.mdf) som är 1 024 MB och loggfilen (tempdb.ldf) som är 360 MB. Anta att sp_spaceused rapporterar att den primära datafilen innehåller 600 MB data. Anta också att du vill minska den primära datafilen till 800 MB. Beräkna önskad procentandel ledigt utrymme efter krympningen: 800 MB – 600 MB = 200 MB. Dividera nu 200 MB med 800 MB = 25 procent, och det är din target_percent. Transaktionsloggfilen krymps i enlighet med detta, vilket ger 25 eller 200 MB ledigt utrymme efter att databasen har krympts.

  2. Anslut till SQL Server med SSMS, Azure Data Studio eller sqlcmdoch kör sedan följande Transact-SQL kommando. Ersätt <target_percent> med önskad procentandel:

    DBCC SHRINKDATABASE (tempdb, '<target_percent>');

Det finns begränsningar med kommandot DBCC SHRINKDATABASE på tempdb. Målstorleken för data och loggfiler får inte vara mindre än den storlek som angavs när databasen skapades eller mindre än den senaste storleken som uttryckligen angavs med hjälp av en filstorleksförändrande åtgärd, till exempel ALTER DATABASE som använder alternativet MODIFY FILE. En annan begränsning för DBCC SHRINKDATABASE är beräkningen av parametern target_percentage och dess beroende av det aktuella utrymmet som används.

Använda DBCC SHRINKFILE-kommandot

Använd kommandot DBCC SHRINKFILE för att krympa enskilda tempdb filer. DBCC SHRINKFILE ger mer flexibilitet än DBCC SHRINKDATABASE eftersom du kan använda den på en enda databasfil utan att påverka andra filer som tillhör samma databas. DBCC SHRINKFILE tar emot parametern target_size. Det här är den önskade slutliga storleken för databasfilen.

  1. Fastställa önskad storlek för den primära datafilen (tempdb.mdf), loggfilen (templog.ldf) och extra filer som läggs till i tempdb. Kontrollera att utrymmet som används i filerna är mindre än eller lika med önskad målstorlek.

  2. Anslut till SQL Server med SSMS, Azure Data Studio eller sqlcmdoch kör sedan följande Transact-SQL kommandon för de specifika databasfiler som du vill krympa. Ersätt <target_size_in_MB> med önskad storlek:

    USE tempdb;
GO

-- This command shrinks the primary data file
DBCC SHRINKFILE (tempdev, '<target_size_in_MB>');
GO

-- This command shrinks the log file, examine the last paragraph.
DBCC SHRINKFILE (templog, '<target_size_in_MB>');
GO

En fördel med DBCC SHRINKFILE är att den kan minska storleken på en fil till en storlek som är mindre än dess ursprungliga storlek. Du kan utfärda DBCC SHRINKFILE på något av data- eller loggfilerna. Du kan inte göra databasen mindre än storleken på den model databasen.

Fel 8909 när du kör krympningsåtgärder

Om tempdb används och om du försöker krympa den med hjälp av kommandona DBCC SHRINKDATABASE eller DBCC SHRINKFILE kan du få meddelanden som liknar följande, beroende på vilken version av SQL Server du använder:

Server: Msg 8909, Level 16, State 1, Line 1 Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page ID (6:8040) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).

Det här felet tyder inte på någon verklig skada i tempdb. Det kan dock finnas andra orsaker till fel med skadade fysiska data, till exempel fel 8909, och att dessa orsaker omfattar problem med I/O-undersystemet. Om felet inträffar utanför krympningsåtgärder bör du därför göra mer undersökning.

Även om ett 8909-meddelande returneras till programmet eller till den användare som utför krympningsåtgärden misslyckas inte krympningsåtgärderna.

Relaterat innehåll