Dela via

tempdb-databas

  • Artikel

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceSQL-databas i 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.

Överblick

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
    • Tabellvariabler
    • Tabeller som returneras i tabellvärdesfunktioner
    • Markörer

    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 hash-koppling eller hash-aggregering.
    • 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. Det finns två typer: ett gemensamt versionslager och ett versionslager för att bygga index online. 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.

Å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.

Fil Logiskt namn Fysiskt namn Ursprunglig storlek Filtillväxt
Primärdata tempdev tempdb.mdf 8 megabyte Skala automatiskt med 64 MB tills disken är full
Sekundära datafiler temp# tempdb_mssql_#.ndf 8 megabyte Skala automatiskt med 64 MB tills disken är full
Logg templog templog.ldf 8 megabyte Utöka automatiskt med 64 megabyte till ett maximum av 2 terabyte

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.

Databasalternativ Standardvärde Kan ändras
ACCELERATED_DATABASE_RECOVERY OFF Nej
ALLOW_SNAPSHOT_ISOLATION OFF Ja
ANSI_NULL_DEFAULT OFF Ja
ANSI_NULLS OFF Ja
ANSI_PADDING OFF Ja
ANSI_WARNINGS OFF Ja
ARITHABORT OFF Ja
AUTO_CLOSE OFF Nej
AUTO_CREATE_STATISTICS ON Ja
AUTO_SHRINK OFF Nej
AUTO_UPDATE_STATISTICS ON Ja
AUTO_UPDATE_STATISTICS_ASYNC OFF Ja
AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN) OFF Nej
CHANGE_TRACKING OFF Nej
COMPATIBILITY_LEVEL Beror på databasmotorns version.

Mer information finns i ALTER DATABASE (Transact-SQL) kompatibilitetsnivå.		 Ja
CONCAT_NULL_YIELDS_NULL OFF Ja
CONTAINMENT NONE Nej
CURSOR_CLOSE_ON_COMMIT OFF Ja
CURSOR_DEFAULT GLOBAL Ja
Databastillstånd ONLINE Nej
Databasuppdatering READ_WRITE Nej
Databasanvändaråtkomst MULTI_USER Nej
DATE_CORRELATION_OPTIMIZATION OFF Ja
DB_CHAINING ON Nej
DELAYED_DURABILITY DISABLED

Oavsett det här alternativet är fördröjd hållbarhet alltid aktiverad på tempdb.		 Ja
ENCRYPTION OFF Nej
MIXED_PAGE_ALLOCATION OFF Nej
NUMERIC_ROUNDABORT OFF Ja
PAGE_VERIFY CHECKSUM för nya installationer av SQL Server

Befintliga PAGE_VERIFY värde kan behållas när en instans av SQL Server uppgraderas på plats.		 Ja
PARAMETERIZATION SIMPLE Ja
QUOTED_IDENTIFIER OFF Ja
READ_COMMITTED_SNAPSHOT OFF Nej
RECOVERY SIMPLE Nej
RECURSIVE_TRIGGERS OFF Ja
Service Broker ENABLE_BROKER Ja
TARGET_RECOVERY_TIME 60 Ja
TEMPORAL_HISTORY_RETENTION ON Ja
TRUSTWORTHY OFF Nej

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:

Accelererad databasåterställning är alltid aktiverad för tempdb i Azure SQL Database. Mer information finns i Förbättra Azure SQL Database-tillförlitligheten med accelererad databasåterställning i tempdb.

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-databaserna i Microsoft Fabric finns i avsnittet begränsningar för resurser i Funktionsjämförelse: Azure SQL-databasen och SQL-databasen i Microsoft Fabric.

På samma sätt som Azure SQL Databaseär globala temporära tabeller i SQL-databaser i Microsoft Fabric inriktade på databaser. Mer information finns i Databasomfattande globala temporära tabeller i Azure SQL Database.

Inskränkningar

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

  • Lägga till filgrupper.
  • Säkerhetskopiera eller återställa databasen.
  • Ändra sorteringsordning. 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.

Behörigheter

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.
  • 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.

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.

Not

För att förbättra prestandan aktiveras alltid fördröjd hållbarhet på tempdb även om databasalternativet DELAYED_DURABILITY är inställt på DISABLED. Eftersom tempdb återskapas vid start går den inte igenom en återställningsprocess och ger ingen hållbarhetsgaranti.

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

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 tempdbfinns i bloggartikeln TEMPDB – Filer och spårningsflaggor och uppdateringar, Oh My!.
  • Egenskapen AUTOGROW_ALL_FILES är alltid aktiverad för PRIMARY-filgruppen.

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 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 2022 (16.x)

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.

Tips

På grund av aktuella begränsningarrekommenderar vi att du aktiverar minnesoptimerade TempDB-metadata endast när objektmetadatakonkurration inträffar och påverkar dina arbetsbelastningar avsevärt.

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:

Not

För närvarande är den minnesoptimerade TempDB-metadatafunktionen inte tillgänglig i Azure SQL Database, SQL Database i Microsoft Fabric och Azure SQL Managed Instance.

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.

Möjliggöra

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;

Inaktivera

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:

    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;

    Obs

    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 tempdb filer . 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 (utan att ta hänsyn till ledigt diskutrymme som kan vara tillgängligt för tempdb:s ökning)
  • Utrymme som används av versionslagret
  • 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