tempdb-databas

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

I den här artikeln beskrivs tempdb systemdatabas, en global resurs som är tillgänglig för alla användare som är anslutna till en databasmotorinstans i SQL Server, Azure SQL Database eller Azure SQL Managed Instance.

Overview

Den tempdb systemdatabasen är en global resurs som innehåller:

• Användarobjekt som uttryckligen skapas. De omfattar:

  • Globala eller lokala temporära tabeller och index i dessa tabeller
  • Tillfälliga lagrade procedurer
  • Stora variabler, inklusive tabellvariabler
  • Tabeller som returneras i tabellvärdesfunktioner
  • Cursors

  Användarobjekt som kan skapas i en användardatabas kan också skapas i tempdb, men de skapas utan hållbarhetsgaranti och tas bort när databasmotorinstansen startas om.

• Interna objekt som databasmotorn skapar. De omfattar:

  • Arbetstabeller för att lagra mellanliggande resultat för spolar, markörer, sorteringar och tillfällig lagring av stora objekt (LOB).
  • Arbetsfiler för hashmatchning eller hash-aggregeringsåtgärder.
  • Mellanliggande sorteringsresultat för åtgärder som att skapa eller återskapa index (om SORT_IN_TEMPDB har angetts) eller vissa GROUP BY, ORDER BYeller UNION frågor.

  Varje internt objekt använder minst nio sidor: en IAM-sida och en åttasidig omfattning. Mer information om sidor och omfattningar finns i Sidor och omfattningar.

• Version lagrar, som är samlingar med datasidor som innehåller de datarader som stöder radversionering. Versionsarkiven innehåller:

  • Radversioner som genereras av dataändringstransaktioner i en databas som använder radversionsbaserade READ COMMITTED eller SNAPSHOT isoleringstransaktioner.
  • Radversioner som genereras av transaktioner för datamodifieringar i funktioner, såsom onlineindexoperationer, flera aktiva resultatuppsättningar (MARS) och AFTER-utlösare.

  Från och med SQL Server 2025 (17.x) förhandsversion, när accelererad databasåterställning (ADR) är aktiverad i tempdb, tempdb innehåller två olika och oberoende versionslager:

  • Det traditionella versionsarkivet, som används för radversioner som genereras av transaktioner i användardatabaser som inte har ADR aktiverat.
  • Det beständiga versionsarkivet (PVS), som används för radversioner som genereras av transaktioner i tempdb.

  Se till att avsätta tillräckligt med diskutrymme för tempdb så att datafilerna kan innehålla båda versionsarkiven om ADR är aktiverat i tempdb. Beroende på din arbetsbelastning kan storleken på tempdb datafiler behöva ökas för att innehålla PVS-data.

  Mer information om hur tempdb utrymme används av det traditionella versionsarkivet finns i Utrymme som används i tempdb. Mer information om utrymme som används av PVS finns i Space used by the persistent version store (PVS).

Åtgärder inom tempdb loggas minimalt. tempdb återskapas varje gång databasmotorn startas så att systemet alltid börjar med en tom tempdb databas. Tillfälliga lagrade procedurer och lokala temporära tabeller tas bort automatiskt när sessionen som skapade dem kopplas från.

tempdb har aldrig något att spara från en drifttidsperiod för databasmotorn till en annan. Säkerhetskopierings- och återställningsåtgärder tillåts inte på tempdb.

Fysiska egenskaper för tempdb i SQL Server

I följande tabell visas de inledande konfigurationsvärdena för tempdb data och loggfiler i SQL Server. Värdena baseras på standardvärdena för model-databasen. Storleken på dessa filer kan variera något för olika utgåvor av SQL Server.

Alla tempdb datafiler ska alltid ha samma initiala storlek och tillväxtparametrar.

Antal tempdb-datafiler

Beroende på vilken version av databasmotorn, dess konfiguration och arbetsbelastningen är kan tempdb kräva flera datafiler för att minska allokeringskonkurrationen.

Det rekommenderade totala antalet datafiler beror på antalet logiska processorer på datorn. Som allmän vägledning:

• Om antalet logiska processorer är mindre än eller lika med åtta använder du samma antal datafiler.
• Om antalet logiska processorer är större än åtta använder du åtta datafiler.
• Om tempdb tilldelningskonflikt fortfarande observeras ökar du antalet datafiler med multiplar av fyra tills konflikten minskar till acceptabla nivåer, eller gör ändringar i arbetsbelastningen.

Mer information finns i rekommendationer för att minska allokeringskonkurrationen i SQL Server tempdb-databasen.

Om du vill kontrollera aktuella storleks- och tillväxtparametrar för tempdbanvänder du sys.database_files katalogvyn i tempdb.

Flytta tempdb-data och loggfiler i SQL Server

Information om hur du flyttar tempdb data och loggfiler finns i Flytta systemdatabaser.

Databasalternativ för tempdb i SQL Server

I följande tabell visas standardvärdet för varje databasalternativ i tempdb-databasen och om alternativet kan ändras. Om du vill visa de aktuella inställningarna för de här alternativen använder du sys.databases katalogvy.

¹ Inställning ACCELERATED_DATABASE_RECOVERY till ON i tempdb stöds från och med SQL Server 2025 (17.x) Förhandsversion. I tidigare versioner av SQL Server är det inte tillåtet att ACCELERATED_DATABASE_RECOVERY ändra alternativet för tempdb databasen.

En beskrivning av dessa databasalternativ finns i ALTER DATABASE SET Options (Transact-SQL).

tempdb i Azure SQL Database

I Azure SQL Database skiljer sig vissa aspekter av tempdb beteende och konfiguration från SQL Server.

För enskilda databaser har varje databas på en logisk server sin egen tempdb. I en elastisk pool är tempdb en delad resurs för alla databaser i samma pool, men temporära objekt som skapats av en databas är inte synliga för andra databaser i samma elastiska pool.

Objekt i tempdb, inklusive katalogvyer och dynamiska hanteringsvyer (DMV:er), är tillgängliga via en referens mellan databaser till tempdb-databasen. Du kan till exempel fråga sys.database_files vy:

SELECT file_id,
       type_desc,
       name,
       size,
       max_size,
       growth
FROM tempdb.sys.database_files;

Globala temporära tabeller i Azure SQL Database är databasomfattande. Mer information finns i Databasomfattande globala temporära tabeller i Azure SQL Database.

För att lära dig mer om tempdb-storlekar i Azure SQL Database, se:

• Köpmodell för virtuella kärnor: enkla databaser, pooldatabaser
• DTU-inköpsmodell: enkla databaser, pooldatabaser

tempdb i SQL Managed Instance

I Azure SQL Managed Instance skiljer sig vissa aspekter av tempdb beteende och standardkonfiguration från SQL Server.

Du kan konfigurera antalet tempdb filer, deras tillväxtökningar och deras maximala storlek. Mer information om hur du konfigurerar tempdb inställningar i Azure SQL Managed Instance finns i Konfigurera tempdb-inställningar för Azure SQL Managed Instance.

Azure SQL Managed Instance stöder tillfälliga objekt på samma sätt som SQL Server, där alla globala temporära tabeller och globala tillfälliga lagrade procedurer är tillgängliga för alla användarsessioner i samma SQL-hanterade instans.

För att lära dig mer om tempdb storlekar i Azure SQL Managed Instance kan du granska resursbegränsningar.

tempdb i SQL-databasen i Fabric

Mer information om tempdb storlekar i SQL Database i Förhandsversionen av Microsoft Fabric finns i avsnittet resursgränser i Funktionsjämförelse: Azure SQL Database och SQL Database i Microsoft Fabric.

På samma sätt som Azure SQL Database är globala temporära tabeller i SQL Database i Microsoft Fabric Preview databasspecifika. Mer information finns i Databasomfattande globala temporära tabeller i Azure SQL Database.

Restrictions

Följande åtgärder kan inte utföras på tempdb-databasen:

• Lägga till filgrupper.
• Säkerhetskopiera eller återställa databasen.
• Ändra sortering. Standardsorteringen är serversorteringen.
• Ändra databasägaren. tempdb ägs av sa.
• Skapa en ögonblicksbild av databasen.
• Ta bort databasen.
• Ta bort gäst användare från databasen.
• Aktivera insamling av ändringsdata.
• Deltar i databasspegling.
• Tar bort den primära filgruppen, den primära datafilen eller loggfilen.
• Byter namn på databasen eller den primära filgruppen.
• Kör DBCC CHECKALLOC.
• Kör DBCC CHECKCATALOG.
• Ställa in databasen på OFFLINE.
• Ange databasen eller den primära filgruppen till READ_ONLY.

Permissions

Alla användare kan skapa temporära objekt i tempdb.

Användare kan bara komma åt sina egna icke-tillfälliga objekt i tempdb, såvida de inte får ytterligare behörigheter.

Det går att återkallaCONNECT behörighet för tempdb för att förhindra att en databasanvändare eller roll använder tempdb. Detta rekommenderas inte eftersom många åtgärder kräver användning av tempdb.

Optimera tempdb-prestanda i SQL Server

Storleken och den fysiska placeringen av tempdb filer kan påverka prestanda. Om den ursprungliga storleken på tempdb till exempel är för liten kan tid och resurser tas upp för att automatiskt växa tempdb till den storlek som krävs för att stödja arbetsbelastningen varje gång instansen av databasmotorn startas om.

• Använd om möjligt omedelbar initiering av filer för att förbättra prestanda för datafilernas tillväxtoperationer.
  • Från och med SQL Server 2022 (16.x) kan transaktionsloggfilens tillväxthändelser upp till 64 MB också dra nytta av omedelbar filinitiering. För mer information, se Omedelbar filinitiering och transaktionsloggen.
• Förallokera utrymme för alla tempdb filer genom att ange filstorleken till ett värde som är tillräckligt stort för att rymma den typiska arbetsbelastningen i miljön. Förallokering förhindrar att tempdb växer automatiskt för ofta, vilket kan påverka prestanda negativt.
• Filerna i tempdb-databasen ska ställas in på autogrow för att ge utrymme under oplanerade tillväxthändelser.
• Att dela upp tempdb i flera datafiler med samma storlek kan förbättra effektiviteten för åtgärder som använder tempdb.
  • För att undvika obalans i dataallokering bör datafiler ha samma initiala storlek och tillväxtparametrar eftersom databasmotorn använder en proportionell fyllningsalgoritm som gynnar allokeringar i filer med mer ledigt utrymme.
  • Ställ in ökning av filtillväxt till en rimlig storlek, till exempel 64 MB, och gör att tillväxten ökar på samma sätt för alla datafiler för att förhindra obalans i tillväxten.
• Från och med SQL Server 2025 (17.x) Preview kan du överväga att aktivera accelererad databasåterställning för tempdb att få fördelarna med omedelbar återställning av transaktioner och aggressiv loggtrunkering för transaktioner i tempdb. Mer information finns i ADR i tempdb.
  • Aktivering eller inaktivering av ADR i tempdb kräver en omstart av databasmotorn för att börja gälla.

Om du vill kontrollera aktuella storleks- och tillväxtparametrar för tempdbanvänder du följande fråga:

SELECT name AS file_name,
       type_desc AS file_type,
       size * 8.0 / 1024 AS size_mb,
       max_size * 8.0 / 1024 AS max_size_mb,
       CAST(IIF(max_size = 0, 0, 1) AS bit) AS is_autogrowth_enabled,
       CASE WHEN growth = 0 THEN growth
            WHEN growth > 0 AND is_percent_growth = 0 THEN growth * 8.0 / 1024
            WHEN growth > 0 AND is_percent_growth = 1 THEN growth
       END
       AS growth_increment_value,
       CASE WHEN growth = 0 THEN 'Autogrowth is disabled.'
            WHEN growth > 0 AND is_percent_growth = 0  THEN 'Megabytes'
            WHEN growth > 0 AND is_percent_growth = 1  THEN 'Percent'
       END
       AS growth_increment_value_unit
FROM tempdb.sys.database_files;

Placera tempdb-databasen på ett snabbt I/O-undersystem. Enskilda datafiler eller grupper av tempdb datafiler behöver inte nödvändigtvis finnas på olika diskar om du inte stöter på I/O-flaskhalsar på disknivå.

Om det finns I/O-konkurrens mellan tempdb- och användardatabaser placerar du tempdb filer på diskar som skiljer sig från de diskar som användardatabaser använder.

Förbättringar i tempdb för SQL Server

Introducerades i SQL Server 2025 (17.x) förhandsversion

• Tempdb utrymmesresursstyrning framtvingar en gräns för den totala mängden tempdb utrymme som förbrukas av ett program eller en användararbetsbelastning. Detta förbättrar tillförlitligheten och undviker avbrott genom att förhindra att skenande frågor eller arbetsbelastningar förbrukar mycket utrymme i tempdb. Mer information finns i Tempdb-resursstyrning för utrymme.
• Accelererad databasåterställning stöds i tempdb, vilket ger omedelbar återställning av transaktioner och aggressiv loggtrunkering för transaktioner i tempdb.

Introducerades i SQL Server 2022 (16.x)

• Introducerade förbättrad skalbarhet med systemsidans samtidighetsförbättringar. Samtidiga uppdateringar av sidor med global allokeringskarta (GAM) och SGAM-sidor (delad global allokeringskarta) minskar spärrkonkurkurensen vid allokering/frigörande av datasidor och omfattningar. De här förbättringarna gäller för alla användardatabaser och gynnar särskilt tunga arbetsbelastningar i tempdb. Mer information om GAM- och SGAM-sidor finns i Under omslagssidorna: GAM, SGAM och PFS. Om du vill ha mer information kan du titta på Förbättringar av systemsidans samtidighet (ep. 6) | Data som exponeras.

Introducerades i SQL Server 2019 (15.x)

• Databasmotorn använder inte alternativet FILE_FLAG_WRITE_THROUGH när tempdb filer öppnas för maximalt diskdataflöde. Eftersom tempdb återskapas vid start behövs inte det här alternativet för att tillhandahålla datahållbarhet. Mer information om FILE_FLAG_WRITE_THROUGHfinns i loggnings- och datalagringsalgoritmer som utökar datatillförlitligheten i SQL Server.
• Minnesoptimerade TempDB-metadata tar bort konkurrens om temporära objektmetadata i tempdb.
• Samtidiga uppdateringar av sidfritt utrymme (PFS) minskar sidlåsstridigheter i alla databaser, ett problem som oftast ses i tempdb. Den här förbättringen ändrar samtidighetshanteringen av PFS-siduppdateringar så att de kan uppdateras under en delad spärr i stället för en exklusiv spärr. Det här beteendet är aktiverat som standard i alla databaser (inklusive tempdb) från och med SQL Server 2019 (15.x). Mer information om PFS-sidor finns i Under omslag: GAM, SGAM och PFS-sidor.
• Som standard skapar en ny installation av SQL Server på Linux flera tempdb datafiler, baserat på antalet logiska kärnor (med upp till åtta datafiler). Detta gäller inte för uppgradering av lägre eller större versioner på plats. Varje tempdb datafil är 8 MB, med en automatisk tillväxt på 64 MB. Det här beteendet liknar standardinstallationen av SQL Server i Windows.

Introducerades i SQL Server 2017 (14.x)

• SQL-installationsupplevelsen förbättrar vägledningen för inledande tempdb-filtilldelning. SQL-installationsprogrammet varnar kunder om den ursprungliga filstorleken är inställd på ett värde som är större än 1 GB och om omedelbar filinitiering inte är aktiverad, vilket förhindrar fördröjningar vid start av instanser.
• Vyn sys.dm_tran_version_store_space_usage dynamisk hanteringsvy övervakar användningen av versionslagret per databas. Den här DMV:en är användbar för DBA:er som proaktivt vill planera tempdb storleksändring baserat på användningskravet för versionsarkivet per databas.
• Intelligent frågebearbetning funktioner som adaptiva kopplingar och feedback om minnesbidrag minskar minnesutsläppen vid efterföljande körningar av en fråga, vilket minskar tempdb användning.

Introducerades i SQL Server 2016 (13.x)

• Temporära tabeller och tabellvariabler cachelagras. Cachelagring gör att operationer som tar bort och skapar tillfälliga objekt kan köras mycket snabbt. Cachelagring minskar också sidallokering och metadata-konflikter.
• Spärrprotokollet för allokeringssidan förbättras för att minska antalet UP (uppdatering) låsningar som används.
• Loggningskostnaderna för tempdb minskas för att minska diskens I/O-bandbreddsförbrukning på tempdb loggfilen.
• SQL-installationsprogrammet lägger till flera tempdb datafiler under en ny instansinstallation. Granska rekommendationerna och konfigurera din tempdb på sidan Database Engine Configuration i SQL Setup eller använd kommandoradsparametern /SQLTEMPDBFILECOUNT. Som standard lägger SQL-installationsprogrammet till så många tempdb datafiler som antalet logiska processorer eller åtta, beroende på vilket som är lägre.
• När det finns flera tempdb datafiler växer alla filer automatiskt samtidigt och med samma mängd, beroende på tillväxtinställningar. spårningsflagga 1117 krävs inte längre. Mer information finns i -T1117 och -T1118 ändringar i TEMPDB och användardatabaser.
• Alla allokeringar i tempdb använder enhetliga omfattningar. spårningsflagga 1118 krävs inte längre. Mer information om prestandaförbättringar i finns i tempdbbloggartikeln TEMPDB – Filer och spårningsflaggor och uppdateringar, Oh My!.
• Egenskapen AUTOGROW_ALL_FILES är alltid aktiverad för PRIMARY-filgruppen.

Minnesoptimerade TempDB-metadata

Konkurrens om temporära objektmetadata har historiskt sett varit en flaskhals i skalbarheten för många SQL Server-arbetsbelastningar. För att åtgärda detta introducerade SQL Server 2019 (15.x) en funktion som ingår i minnesintern databas funktionsfamilj: Minnesoptimerade TempDB-metadata.

Om du aktiverar funktionen Minnesoptimerade TempDB-metadata tar du bort den här flaskhalsen för arbetsbelastningar som tidigare begränsats av konkurrens om temporära objektmetadata i tempdb. Från och med SQL Server 2019 (15.x) kan systemtabellerna som används för att hantera tillfälliga objektmetadata bli spärrfria, icke-hållbara, minnesoptimerade tabeller.

Följande diagnostikfråga returnerar en eller flera rader om det förekommer en konkurrens om temporära objektmetadata. Varje rad representerar en systemtabelloch returnerar antalet sessioner som kämpar för åtkomst till tabellen vid den tidpunkt då den här diagnostikfrågan körs.

SELECT OBJECT_NAME(dpi.object_id, dpi.database_id) AS system_table_name,
       COUNT(DISTINCT(r.session_id)) AS session_count
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.fn_PageResCracker(r.page_resource) AS prc
CROSS APPLY sys.dm_db_page_info(prc.db_id, prc.file_id, prc.page_id, 'LIMITED') AS dpi
WHERE dpi.database_id = 2
      AND dpi.object_id IN (3, 9, 34, 40, 41, 54, 55, 60, 74, 75)
      AND UPPER(r.wait_type) LIKE N'PAGELATCH[_]%'
GROUP BY dpi.object_id, dpi.database_id;

Titta på den här sju minuter långa videon för en översikt över hur och när du ska använda minnesoptimerad TempDB-metadatafunktion:

Konfigurera och använda minnesoptimerade TempDB-metadata

Följande avsnitt innehåller steg för att aktivera, konfigurera, verifiera och inaktivera den minnesoptimerade TempDB-metadatafunktionen.

Enable

Om du vill aktivera den här funktionen använder du följande skript:

ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON;

Mer information finns i ALTER SERVER. Den här konfigurationsändringen kräver att tjänsten startas om för att börja gälla.

Du kan kontrollera om tempdb är minnesoptimerad eller inte med hjälp av följande T-SQL-kommando:

SELECT SERVERPROPERTY('IsTempdbMetadataMemoryOptimized');

Om det returnerade värdet är 1 och en omstart har inträffat när funktionen har aktiverats aktiveras funktionen.

Om servern inte startar av någon anledning när du har aktiverat minnesoptimerade TempDB-metadata kan du kringgå funktionen genom att starta database engine-instansen med minimal konfiguration med hjälp av startalternativet -f. Du kan sedan inaktivera funktionen och ta bort alternativet -f för att starta om databasmotorn i normalt läge.

Binda till resurspoolen för att begränsa minnesanvändningen

För att skydda servern mot potentiella minnesbrister rekommenderar vi att du binder tempdb till en resursguvernör resurspool som begränsar det minne som förbrukas av minnesoptimerade TempDB-metadata. Följande exempelskript skapar en resurspool och anger maximalt minne till 20%, aktiverar resursguvernöroch binder tempdb till resurspoolen.

I det här exemplet används 20% som minnesgräns för demonstration. Det optimala värdet i din miljö kan vara större eller mindre beroende på din arbetsbelastning och kan ändras med tiden om arbetsbelastningen ändras.

CREATE RESOURCE POOL tempdb_resource_pool
WITH (MAX_MEMORY_PERCENT = 20);

ALTER RESOURCE GOVERNOR RECONFIGURE;

ALTER SERVER CONFIGURATION 
SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON 
(RESOURCE_POOL = 'tempdb_resource_pool');

Den här ändringen kräver också att en omstart av tjänsten börjar gälla, även om minnesoptimerade TempDB-metadata redan är aktiverade.

Verifiera resurspoolsbindning och övervaka minnesanvändning

Om du vill kontrollera att tempdb är bunden till en resurspool och för att övervaka minnesanvändningsstatistik för poolen använder du följande fråga:

WITH resource_pool AS
(
SELECT p.pool_id,
       p.name,
       p.max_memory_percent,
       dp.max_memory_kb,
       dp.target_memory_kb,
       dp.used_memory_kb,
       dp.out_of_memory_count
FROM sys.resource_governor_resource_pools AS p
INNER JOIN sys.dm_resource_governor_resource_pools AS dp
ON p.pool_id = dp.pool_id
)
SELECT SERVERPROPERTY('IsTempdbMetadataMemoryOptimized') AS is_tempdb_memory_optimized_metadata_enabled,
       rp.name AS resource_pool_name,
       rp.max_memory_percent,
       rp.max_memory_kb,
       rp.target_memory_kb,
       rp.used_memory_kb,
       rp.out_of_memory_count
FROM sys.databases AS d
LEFT JOIN resource_pool AS rp
ON d.resource_pool_id = rp.pool_id
WHERE d.name = 'tempdb';

Ta bort resurspoolbindning

Om du vill ta bort resurspoolbindningen samtidigt som minnesoptimerade TempDB-metadata är aktiverade kör du följande kommando och startar om tjänsten:

ALTER SERVER CONFIGURATION 
SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON;

Disable

Om du vill inaktivera minnesoptimerade TempDB-metadata kör du följande kommando och startar om tjänsten:

ALTER SERVER CONFIGURATION 
SET MEMORY_OPTIMIZED TEMPDB_METADATA = OFF;

Begränsningar för minnesoptimerade TempDB-metadata

• Aktivering eller inaktivering av den minnesoptimerade TempDB-metadatafunktionen kräver en omstart.

• I vissa fall kan du observera hög minnesanvändning av MEMORYCLERK_XTP minneshanterare, vilket orsakar minnesfel i din arbetsbelastning.

  För att se minnesanvändning av MEMORYCLERK_XTP-minnesklient jämfört med alla andra minnesklienter och i förhållande till målserverns minne, kör följande fråga:

  SELECT SUM(IIF(type = 'MEMORYCLERK_XTP', pages_kb, NULL)) / 1024. AS memoryclerk_xtp_pages_mb,
         SUM(IIF(type <> 'MEMORYCLERK_XTP', pages_kb, NULL)) / 1024. AS other_pages_mb,
         SUM(committed_target_kb) / 1024. AS committed_target_memory_mb
  FROM sys.dm_os_memory_clerks
  CROSS JOIN sys.dm_os_sys_info;
  

  Om MEMORYCLERK_XTP minne är högt kan du åtgärda problemet på följande sätt:

  • Binda tempdb-databasen till en resurspool som begränsar minnesförbrukningen med minnesoptimerade TempDB-metadata. Mer information finns i Konfigurera och använda minnesoptimerade tempdb-metadata.
  • En system lagrad procedur kan köras regelbundet för att frigöra MEMORYCLERK_XTP minne som inte längre behövs. Mer information finns i sys.sp_xtp_force_gc (Transact-SQL).

  Mer information finns i minnesoptimerad tempdb-metadata (HkTempDB) vid fel på grund av minnesbrist.

• När du använder In-Memory OLTP-tillåts inte en enda transaktion komma åt minnesoptimerade tabeller i mer än en databas. På grund av detta kan alla läs- eller skrivtransaktioner som omfattar en minnesoptimerad tabell i en användardatabas inte heller komma åt tempdb systemvyer i samma transaktion. Om detta inträffar får du fel 41317:

  A user transaction that accesses memory optimized tables or natively compiled modules cannot access more than one user database or databases model and msdb, and it cannot write to master.
  

  Den här begränsningen gäller även för andra scenarier där en enskild transaktion försöker komma åt minnesoptimerade tabeller i mer än en databas.

  Du kan till exempel få fel 41317 om du frågar sys.stats katalogvy i en användardatabas som innehåller minnesoptimerade tabeller. Detta beror på att frågan försöker komma åt statistikdata i en minnesoptimerad tabell i användardatabasen och minnesoptimerat metadata i tempdb.

  Följande exempelskript genererar det här felet när minnesoptimerade TempDB-metadata är aktiverat:

  BEGIN TRAN;
  
  -- Create an In-memory OLTP transaction that accesses a system view in tempdb
  SELECT name
  FROM tempdb.sys.tables;
  
  -- An attempt to create an In-memory OLTP transaction in the user database fails
  INSERT INTO <user database>.<schema>.<memory-optimized table>
  VALUES (1);
  
  COMMIT TRAN;
  

  Note

  Den här begränsningen gäller inte för temporära tabeller. Du kan skapa en tillfällig tabell i samma transaktion som kommer åt en minnesoptimerad tabell i en användardatabas.

• Frågor mot systemkatalogvyer använder alltid READ COMMITTED isoleringsnivå. När minnesoptimerade TempDB-metadata är aktiverade, använder frågor mot systemkatalogvyer i tempdb isoleringsnivån SNAPSHOT. I båda fallen efterlevs inte låsningstips.

• Kolumnbutiksindex kan inte skapas på tillfälliga tabeller när minnesoptimerade TempDB-metadata har aktiverats.

  • Därför stöds inte användningen av den sp_estimate_data_compression_savings systemlagrade proceduren med parametern COLUMNSTORE eller COLUMNSTORE_ARCHIVE datakomprimering när minnesoptimerade TempDB-metadata aktiveras.

Kapacitetsplanering för tempdb i SQL Server

Att bestämma lämplig storlek för tempdb beror på många faktorer. Dessa faktorer inkluderar arbetsbelastningen och databasmotorfunktionerna som används.

Vi rekommenderar att du analyserar tempdb utrymmesförbrukning genom att utföra följande uppgifter i en testmiljö där du kan återskapa din vanliga arbetsbelastning:

• Aktivera automatisk tillväxt för filer tempdb. Alla tempdb datafiler ska ha samma initiala storlek och autogrow-konfiguration.
• Återskapa arbetsbelastningen och övervaka tempdb utrymmesanvändning.
• Om du använder periodiskt indexunderhållkör du underhållsjobben och övervakar tempdb utrymme.
• Använd det maximala utrymmet som använts från föregående steg för att förutsäga din totala arbetsbelastningsanvändning. Justera det här värdet för den beräknade samtidiga aktiviteten och ange sedan storleken på tempdb därefter.

Övervaka tempdb-användning

Slut på diskutrymme i tempdb kan orsaka betydande avbrott och programavbrott. Du kan använda den dynamiska hanteringsvyn sys.dm_db_file_space_usage för att övervaka utrymmet som används i tempdb-filerna.

Följande exempelskript hittar till exempel:

• Ledigt utrymme i tempdb (överväger inte ledigt diskutrymme som kan vara tillgängligt för tempdb tillväxt).
• Utrymme som används av det traditionella versionslagret.
  • Information om hur du övervakar storleken på det beständiga versionsarkivet (PVS) när accelererad databasåterställning (ADR) är aktiverad i finns i tempdbGranska storleken på PVS.
• Utrymme som används av interna objekt.
• Utrymme som används av användarobjekt.

SELECT SUM(unallocated_extent_page_count) * 8.0 / 1024 AS tempdb_free_data_space_mb,
       SUM(version_store_reserved_page_count) * 8.0 / 1024 AS tempdb_version_store_space_mb,
       SUM(internal_object_reserved_page_count) * 8.0 / 1024 AS tempdb_internal_object_space_mb,
       SUM(user_object_reserved_page_count) * 8.0 / 1024 AS tempdb_user_object_space_mb
FROM tempdb.sys.dm_db_file_space_usage;

Om du vill övervaka sidallokering eller deallokering i tempdb på sessions- eller aktivitetsnivå kan du använda sys.dm_db_session_space_usage och sys.dm_db_task_space_usage dynamiska hanteringsvyer. De här vyerna kan hjälpa dig att identifiera frågor, temporära tabeller eller tabellvariabler som använder stora mängder tempdb utrymme.

Använd till exempel följande exempelskript för att hämta det tempdb utrymme som allokeras och frigörs av interna objekt i alla aktiviteter som körs i varje session:

SELECT session_id,
       SUM(internal_objects_alloc_page_count) AS task_internal_objects_alloc_page_count,
       SUM(internal_objects_dealloc_page_count) AS task_internal_objects_dealloc_page_count
FROM sys.dm_db_task_space_usage
GROUP BY session_id;

Använd följande exempelskript för att hitta tempdb allokerat och för närvarande förbrukat utrymme av interna objekt och användarobjekt för varje session och begäran, för både aktiviteter som körs och slutförs:

WITH tempdb_space_usage AS
(
SELECT session_id,
       request_id,
       user_objects_alloc_page_count + internal_objects_alloc_page_count AS tempdb_allocations_page_count,
       user_objects_alloc_page_count + internal_objects_alloc_page_count - user_objects_dealloc_page_count - internal_objects_dealloc_page_count AS tempdb_current_page_count
FROM sys.dm_db_task_space_usage
UNION ALL
SELECT session_id,
       NULL AS request_id,
       user_objects_alloc_page_count + internal_objects_alloc_page_count AS tempdb_allocations_page_count,
       user_objects_alloc_page_count + internal_objects_alloc_page_count - user_objects_dealloc_page_count - user_objects_deferred_dealloc_page_count - internal_objects_dealloc_page_count AS tempdb_current_page_count
FROM sys.dm_db_session_space_usage
)
SELECT session_id,
       COALESCE(request_id, 0) AS request_id,
       SUM(tempdb_allocations_page_count * 8) AS tempdb_allocations_kb,
       SUM(IIF (tempdb_current_page_count >= 0, tempdb_current_page_count, 0) * 8) AS tempdb_current_kb
FROM tempdb_space_usage
GROUP BY session_id, COALESCE (request_id, 0)
ORDER BY session_id, request_id;

Relaterat innehåll

• SORT_IN_TEMPDB alternativ för index
• Systemdatabaser
• sys.databases
• sys.master_files
• Flytta databasfiler