TRANSACTION | DBA von Nebenan

TRUNCATE TABLE – DDL vs DML – deep dive in operations and practical tips

Gabriel — Mon, 26 May 2025 13:14:32 +0000

Recently, I stumbled across a LinkedIn post about truncate vs. delete, just like many others out there. Typically, random members post simple SQL Server tips, nicely packaged in graphics and kept general. Although for beginners this is absolutely legitimate – since these simple entry points can help many newcomers understand and provide a great starting point – nevertheless, the fact that the same topics then go viral across various accounts is clearly another matter entirely.

Anyway. If you’re a bit further along in the topic and already know that the pronunciation isn’t „SQL“ but „sequel“ , you should fundamentally question these posts, as they mostly generalize.

This was also the case in a post about the top 3 SQL mistakes that „everyone“ makes. And here we are, getting to the point.

The same happened with Vedran Kesegic, who gave the hint that TRUNCATE is apparently rollback-capable when encapsulated in a transaction. Then Carsten Saastamoinen-Jakobsen jumped in and things got wild. So wild that the whole topic hooked me so much that I did a deep dive into it. Furthermore, so much knowledge dropped in this exchange that it would be a shame if it disappeared in a comment section.

What to expect here

I compared the exchange and looked at the core statements. I also texted separately with both of them a bit more, and Carsten gave me excerpts from one of his publications where the topic is covered technically.

Technically speaking, both agree, even if they don’t say it . But what was really wild in the end was the question:

I can say it upfront. This question is an philosophical one. I was able to form an opinion based on my research, more on that later, but basically it’s up to everyone to decide for themselves.

The Discussion – DML or DDL ?

Vedran Kesegic

Core Position: TRUNCATE is DDL

„TRUNCATE modifies internal system tables sys.sysallocunits and sys.sysrowsets. DELETE modifies indexes and stats“

„DML writes data (rows in user tables), while DDL writes metadata (rows in system tables, data that describes other/user objects). Truncate happens to write metadata (system tables) and thus is classified as DDL.“

Technical Arguments

Uses SCH-M (Schema Modification) lock
Modifies system metadata tables
Microsoft documentation classifies it as DDL
Logs page deallocations, not row deletions

Key Statement

„TRUNCATE modifies internal system tables sys.sysallocunits and sys.sysrowsets. DELETE modifies indexes and stats – see attached“

Carsten Saastamoinen-Jakobsen

Core Position: TRUNCATE is DML

„It is not an argument to call TRUNCATE a DDL statement because a certain lock is used! When statements are categorized, it must be based on what happens and not how a given database system solves the task.“

„We may have to recognize that a previous error categorization should not continue to call TRUNCATE a DDL, but recognize that it is a DML.“

Logical Arguments

Data is deleted, structure is preserved
No table definition changes occur
Follows semantic rules of data manipulation
Can delete only some partitions (not all data)

Key Statement

„I say that MS is right in the documentations because they are not telling that TRUNCATE is as DDL, because they know that TRUNCATE is a DML!“

NOTE Gabriel
I think this is really a bit questionable because the documentation is absolutely clear on this point –> DDL (microsoft.com)

Quote from publication

„As of version 2016, it is possible to delete only some of the data in a table with TRUNCATE, so it is even more correct to call it manipulation than definition, because it is changing some of the data but not changing the structure.“

Points of Agreement

TRUNCATE can be rolled back in a transaction
- general demo at sqlauthority.com
- deep dive demo sqlshack.com
TRUNCATE is a logged operation
TRUNCATE is faster than DELETE for large datasets
Both understand the technical implementation

Core Disagreement

Classification criteria
- Implementation details
Authority
- Vendor documentation (Vedran) vs. Logical reasoning (Carsten)
Perspective
- How it works internally (Vedran) vs. What it does functionally (Carsten)

My 50 Cent

So as you can see, technically it fits, but how do you view the whole thing? Maybe it’s good that I’m not preloaded with as much knowledge as both of them because from my perspective it’s quite clear: DDL!!

Contrary to Carsten’s statement that no system tables are changed, Vedran’s statement is absolutely correct. See why…

… and of course because MS says it’s DDL ( microsoft.com )

And partitioning is DML… I don’t know, here too it’s at least system columns that define the partitioning.

How TRUNCATE works

I’d like to say I’ll describe it simply, but that’s just my normal description. The topic is really complex

1 – TRUNCATE Command Initiated

TRUNCATE TABLE dbo.MyTable;

First action: Acquire SCH-M (Schema Modification) lock on entire table
Effect: Table is completely locked – no reads, no writes, nothing

2 – Identify Extents

DEEP DIVE Extents –> microsoft.com
SQL Server reads IAM pages
Lists all extents belonging to the table
Still holding: SCH-M lock on table

3- Lock Individual Extents

Places X (Exclusive) locks on each extent
These are regular data locks, NOT schema locks
Now holding:
- SCH-M lock on table (prevents access)
- X locks on extents (marks them for deallocation)

4 – Log the Operation

Writes to transaction log: „Deallocate extents 8:8, 8:16, etc.“
Still holding: Both lock types

5a – If COMMIT

Updates IAM – marks extents as free
Releases all X locks on extents
Releases SCH-M lock on table
Table is accessible again

5b – If ROLLBACK

Discards deallocation markers
Releases all X locks on extents
Releases SCH-M lock on table
Everything unchanged

Why Two Different Lock Types?

SCH-M Lock:

„Nobody touch this table AT ALL“
Typical for DDL operations
Prevents even metadata queries

X Locks on Extents:

„These specific data blocks are being modified“
Typical for data operations
Ensures extents aren’t reused until commit/rollback by other sessions

My humble Opinion

Given this knowledge, the case is actually clear for me, but how do you see it? Indeed, here no user data is being manipulated; instead, system-level assignments are being adjusted. Consequently, I’ll allow myself, despite my new half-knowledge, to make the following comparison:

„I also don’t say I’m deleting text in a Word document when I quick format the disk and only delete the block allocation.“

Yes, I think that’s a nice comparison… Case closed, now a few technically interesting aspects and solutions

Technical Part, Hacks and How2

… practical, not technical

TRUNCATE with Survivor Table (Temporary Table)

Data that is still required is simply moved to a temporary table and retrieved after TRUNCATE

-- Step 1: Create temp table with rows to keep
	SELECT * INTO #SurvivorRows 
	FROM 
		MyTable 
	WHERE
		DateColumn >= '2024-01-01'

-- Step 2: Truncate the entire table
	TRUNCATE TABLE MyTable

-- Step 3: Re-insert survivor rows
	INSERT INTO MyTable
	SELECT * FROM #SurvivorRows

-- Step 4: Clean up
	DROP TABLE #SurvivorRows

TRUNCATE with PARTITION option (2016++)

Since SQL Server 2016 (every edition) it is possible to specify partitions or ranges of partitions

-- Truncate specific partitions
	TRUNCATE TABLE MyPartitionedTable 
	     WITH (PARTITIONS (2, 4 TO 6))

-- Check partition status
	SELECT 
		 partition_number
		,rows 
	FROM
		sys.partitions 
	WHERE 
		OBJECT_NAME(OBJECT_ID) = 'MyPartitionedTable'

TRUNCATE is always a transaction…

…. and must be considered during RESTORING. Carsten illustrated this whole thing very nicely in his publication. I’m just describing it, that has to suffice at this point

Even though we only write TRUNCATE TABLE, SQL Server still uses BEGIN and COMMIT TRANSACTION, which of course is recorded in the TLog. Accordingly, during a POINT IN TIME RECOVERY, the data in the table remains available until the TLog with the corresponding TRANSACTION is restored, or the time of the TRUNCATE transaction has been exceeded.

So you can also restore the data

Continuously read Transaction log file data with fn_dblog and fn_dump_dblog

Vedran wrote in one of his posts that there’s an undocumented function where you can read log records at runtime. There’s also a very cool article about this on sqlshack.com

NOT recommended for production but only for test / education.

https://www.sqlshack.com/how-to-continuously-read-transaction-log-file-data-directly-in-a-sql-server-database-with-fn_dblog-and-fn_dump_dblog/

Finally

Let’s get to my initially mentioned point that all these SQL Server tips from randoms should be questioned. Because the statement that truncate is not rollback safe is simply wrong. The path to this realization was long for me, initiated by the conversation between Vedran and Carsten. I really learned a lot left and right, which I also wanted to record here again for posterity.

In the end, it doesn’t matter whether it’s DDL or DML. In the general SQL Server standard, for example, it’s described as DML, most RDBMSs in dialect with DDL. We’ll just agree on DDL and that’s it. Much more exciting is what happens under the hood.

Best comment from Vedran

„Or you are trying to argue with SQL Certified Master about SQL? Good luck Mr :)“

Links from the text

https://learn.microsoft.com/en-us/sql/t-sql/statements/statements?view=sql-server-ver17#data-definition-language https://learn.microsoft.com/en-us/sql/t-sql/statements/truncate-table-transact-sql?view=sql-server-ver17 https://blog.sqlauthority.com/2010/03/04/sql-server-rollback-truncate-command-in-transaction/ https://www.sqlshack.com/the-internals-of-sql-truncate-and-sql-delete-statements/ https://www.sqlshack.com/how-to-continuously-read-transaction-log-file-data-directly-in-a-sql-server-database-with-fn_dblog-and-fn_dump_dblog/ https://en.wikipedia.org/wiki/Truncate_(SQL) https://learn.microsoft.com/en-us/sql/relational-databases/pages-and-extents-architecture-guide?view=sql-server-ver17

Full Conversation

Expand

TRUNCATE TABLE Operationen im Detail – ROLLBACK ist doch möglich

Gabriel — Mon, 26 May 2025 08:16:15 +0000

Kürzlich bin ich über einen LinkedIn-Post zu TRUNCATE vs. DELETE gestolpert, wie so viele andere auch. Typischerweise posten zufällige Mitglieder einfache SQL Server Tipps, schön verpackt in Grafiken und allgemein gehalten. Obwohl das für Anfänger absolut legitim ist – da diese einfachen Einstiegspunkte vielen Neulingen helfen können zu verstehen und einen großartigen Startpunkt bieten – ist die Tatsache, dass dieselben Themen dann viral über verschiedene Accounts gehen, klar eine ganz andere Sache.

Wie auch immer. Wenn du beim Thema schon etwas weiter bist und bereits weißt, dass die Aussprache nicht „SQL“ sondern „Sequel“ ist , solltest du diese Posts grundsätzlich hinterfragen, da sie meist verallgemeinern.

So war es auch bei einem Post über die Top 3 SQL-Fehler, die „jeder“ macht. Und hier kommen wir zum Punkt – TRUNCATE TABLE und seine Besonderheiten.

Dasselbe passierte mit Vedran Kesegic, der den Hinweis gab, dass TRUNCATE TABLE anscheinend rollback-fähig ist, wenn es in einer Transaktion gekapselt wird. Dann sprang Carsten Saastamoinen-Jakobsen ein und die Sache wurde wild. So wild, dass mich das ganze Thema dermaßen gepackt hat, dass ich einen Deep Dive gemacht habe. Außerdem fiel in diesem Austausch so viel Wissen ab, dass es schade wäre, wenn es in einem Kommentarbereich verschwindet.

Was dich hier erwartet – TRUNCATE TABLE im Detail

Ich habe den Austausch verglichen und mir die Kernaussagen angeschaut. Ich habe auch separat mit beiden etwas mehr getextet, und Carsten gab mir Auszüge aus einer seiner Publikationen, wo das Thema technisch behandelt wird.

Technisch gesehen sind sich beide einig, auch wenn sie es nicht sagen . Aber was am Ende wirklich wild war, war die Frage zum TRUNCATE TABLE Befehl:

Ich kann es vorwegnehmen. Diese Frage zur TRUNCATE TABLE Klassifizierung ist eine philosophische. Ich konnte mir basierend auf meiner Recherche eine Meinung bilden, mehr dazu später, aber grundsätzlich liegt es an jedem selbst zu entscheiden.

Die Diskussion – TRUNCATE TABLE als DML oder DDL?

Vedran Kesegic

Kernposition: TRUNCATE TABLE ist DDL

„TRUNCATE modifies internal system tables sys.sysallocunits and sys.sysrowsets. DELETE modifies indexes and stats“

„DML writes data (rows in user tables), while DDL writes metadata (rows in system tables, data that describes other/user objects). Truncate happens to write metadata (system tables) and thus is classified as DDL.“

Technische Argumente für TRUNCATE TABLE als DDL

Verwendet SCH-M (Schema Modification) Lock
Modifiziert System-Metadaten-Tabellen
Microsoft-Dokumentation klassifiziert es als DDL
Loggt Page-Deallocations, nicht Row-Deletions

Kernaussage zum TRUNCATE TABLE Befehl

„TRUNCATE modifies internal system tables sys.sysallocunits and sys.sysrowsets. DELETE modifies indexes and stats – see attached“

Carsten Saastamoinen-Jakobsen

Kernposition: TRUNCATE TABLE ist DML

„It is not an argument to call TRUNCATE a DDL statement because a certain lock is used! When statements are categorized, it must be based on what happens and not how a given database system solves the task.“

„We may have to recognize that a previous error categorization should not continue to call TRUNCATE a DDL, but recognize that it is a DML.“

Logische Argumente für TRUNCATE TABLE als DML

Daten werden gelöscht, Struktur bleibt erhalten
Keine Änderungen an der Tabellendefinition
Folgt semantischen Regeln der Datenmanipulation
Kann nur bestimmte Partitionen löschen (nicht alle Daten)

Kernaussage zur TRUNCATE TABLE Klassifizierung

„I say that MS is right in the documentations because they are not telling that TRUNCATE is as DDL, because they know that TRUNCATE is a DML!“

ANMERKUNG Gabriel
Ich denke, das ist wirklich etwas fragwürdig, weil die Dokumentation absolut klar zu diesem Punkt ist –> DDL (microsoft.com)

Zitat aus der Publikation zum TRUNCATE TABLE

„As of version 2016, it is possible to delete only some of the data in a table with TRUNCATE, so it is even more correct to call it manipulation than definition, because it is changing some of the data but not changing the structure.“

Einigungspunkte bei TRUNCATE TABLE

TRUNCATE TABLE kann in einer Transaktion zurückgerollt werden
- allgemeine Demo bei sqlauthority.com
- detaillierte Demo sqlshack.com
TRUNCATE TABLE ist eine geloggte Operation
TRUNCATE TABLE ist schneller als DELETE bei großen Datensätzen
Beide verstehen die technische Implementierung

Hauptstreitpunkt bei TRUNCATE TABLE

Klassifizierungskriterien für TRUNCATE TABLE
- Implementierungsdetails
Autorität
- Vendor-Dokumentation (Vedran) vs. Logische Begründung (Carsten)
Perspektive zum TRUNCATE TABLE Befehl
- Wie es intern funktioniert (Vedran) vs. Was es funktional macht (Carsten)

Meine Einschätzung zu TRUNCATE TABLE

Wie du siehst, passt es technisch, aber wie betrachtest du das Ganze? Vielleicht ist es gut, dass ich nicht mit so viel Wissen vorab beladen bin wie beide, denn aus meiner Sicht ist es ziemlich klar: TRUNCATE TABLE ist DDL!!

Entgegen Carstens Aussage, dass keine Systemtabellen geändert werden, ist Vedrans Aussage absolut korrekt. Sieh warum…

… und natürlich weil Microsoft sagt, dass TRUNCATE TABLE DDL ist ( microsoft.com )

Und Partitionierung ist DML… ich weiß nicht, auch hier sind es zumindest Systemspalten, die die Partitionierung definieren.

Wie TRUNCATE TABLE funktioniert – Schritt für Schritt

Ich würde gerne sagen, dass ich es einfach beschreibe, aber das ist einfach meine normale Beschreibung. Das Thema TRUNCATE TABLE ist wirklich komplex

1 – TRUNCATE TABLE Befehl initiiert

TRUNCATE TABLE dbo.MyTable;

Erste Aktion: Akquiriert SCH-M (Schema Modification) Lock auf gesamte Tabelle
Effekt: Tabelle ist komplett gesperrt – keine Reads, keine Writes, nichts

2 – Extents identifizieren bei TRUNCATE TABLE

DEEP DIVE Extents –> microsoft.com
SQL Server liest IAM-Pages
Listet alle Extents auf, die zur Tabelle gehören
Hält weiterhin: SCH-M Lock auf Tabelle

3 – Einzelne Extents bei TRUNCATE TABLE sperren

Platziert X (Exclusive) Locks auf jeden Extent
Das sind reguläre Data-Locks, KEINE Schema-Locks
Hält jetzt:
- SCH-M Lock auf Tabelle (verhindert Zugriff)
- X Locks auf Extents (markiert sie für Deallocation)

4 – TRUNCATE TABLE Operation loggen

Schreibt ins Transaction-Log: „Deallocate extents 8:8, 8:16, etc.“
Hält weiterhin: Beide Lock-Typen

5a – Bei COMMIT der TRUNCATE TABLE Operation

Aktualisiert IAM – markiert Extents als frei
Gibt frei alle X Locks auf Extents
Gibt frei SCH-M Lock auf Tabelle
Tabelle ist wieder zugänglich

5b – Bei ROLLBACK der TRUNCATE TABLE Operation

Verwirft Deallocation-Marker
Gibt frei alle X Locks auf Extents
Gibt frei SCH-M Lock auf Tabelle
Alles bleibt unverändert

Warum zwei verschiedene Lock-Typen bei TRUNCATE TABLE?

SCH-M Lock:

„Niemand rührt diese Tabelle ÜBERHAUPT an“
Typisch für DDL-Operationen
Verhindert sogar Metadaten-Abfragen

X Locks auf Extents:

„Diese spezifischen Datenblöcke werden modifiziert“
Typisch für Daten-Operationen
Stellt sicher, dass Extents nicht von anderen Sessions wiederverwendet werden bis commit/rollback

Meine bescheidene Meinung zu TRUNCATE TABLE

Mit diesem Wissen ist der Fall eigentlich klar für mich, aber wie siehst du es? Tatsächlich werden hier keine Benutzerdaten manipuliert; stattdessen werden System-Level-Zuweisungen angepasst. Folglich erlaube ich mir, trotz meines neuen Halbwissens, den folgenden Vergleich zu ziehen:

„Ich sage auch nicht, dass ich Text in einem Word-Dokument lösche, wenn ich die Festplatte schnell formatiere und nur die Block-Allocation lösche.“

Ja, ich denke das ist ein schöner Vergleich… Fall abgeschlossen, jetzt ein paar technisch interessante Aspekte und Lösungen zum TRUNCATE TABLE Befehl

Technischer Teil, Hacks und TRUNCATE TABLE How-To

… praktisch, nicht technisch

TRUNCATE TABLE mit Survivor Table (Temporary Table)

Daten, die noch benötigt werden, werden einfach in eine temporäre Tabelle verschoben und nach TRUNCATE TABLE wieder abgerufen

-- Step 1: Create temp table with rows to keep
	SELECT * INTO #SurvivorRows 
	FROM 
		MyTable 
	WHERE
		DateColumn >= '2024-01-01'

-- Step 2: Truncate the entire table
	TRUNCATE TABLE MyTable

-- Step 3: Re-insert survivor rows
	INSERT INTO MyTable
	SELECT * FROM #SurvivorRows

-- Step 4: Clean up
	DROP TABLE #SurvivorRows

TRUNCATE TABLE mit PARTITION Option (2016++)

Seit SQL Server 2016 (jede Edition) ist es möglich, Partitionen oder Bereiche von Partitionen bei TRUNCATE TABLE zu spezifizieren

-- Truncate specific partitions
	TRUNCATE TABLE MyPartitionedTable 
	     WITH (PARTITIONS (2, 4 TO 6))

-- Check partition status
	SELECT 
		 partition_number
		,rows 
	FROM
		sys.partitions 
	WHERE 
		OBJECT_NAME(OBJECT_ID) = 'MyPartitionedTable'

TRUNCATE TABLE ist immer eine Transaktion…

…. und muss beim RESTORE berücksichtigt werden. Carsten hat das ganze sehr schön in seiner Publikation illustriert. Ich beschreibe es nur, das muss an dieser Stelle reichen

Obwohl wir nur TRUNCATE TABLE schreiben, verwendet SQL Server trotzdem BEGIN und COMMIT TRANSACTION, was natürlich im TLog aufgezeichnet wird. Entsprechend bleiben bei einer POINT IN TIME RECOVERY die Daten in der Tabelle verfügbar, bis das TLog mit der entsprechenden TRANSACTION wiederhergestellt wird, oder die Zeit der TRUNCATE TABLE Transaktion überschritten wurde.

Du kannst also auch die Daten wiederherstellen

Transaction Log File Daten kontinuierlich lesen mit fn_dblog und fn_dump_dblog

Vedran schrieb in einem seiner Posts, dass es eine undokumentierte Funktion gibt, wo du Log-Records zur Laufzeit lesen kannst. Es gibt auch einen sehr coolen Artikel dazu auf sqlshack.com

NICHT empfohlen für Produktion, sondern nur für Test / Bildung.

https://www.sqlshack.com/how-to-continuously-read-transaction-log-file-data-directly-in-a-sql-server-database-with-fn_dblog-and-fn_dump_dblog/

Fazit zu TRUNCATE TABLE

Kommen wir zu meinem eingangs erwähnten Punkt, dass all diese SQL Server Tipps von randoms hinterfragt werden sollten. Denn die Aussage, dass TRUNCATE TABLE nicht rollback-sicher ist, ist schlichtweg falsch. Der Weg zu dieser Erkenntnis war für mich lang, eingeleitet durch die Unterhaltung zwischen Vedran und Carsten. Ich habe wirklich viel links und rechts dazugelernt, was ich auch hier nochmal für die Nachwelt festhalten wollte.

Am Ende ist es egal, ob TRUNCATE TABLE DDL oder DML ist. Im allgemeinen SQL Server Standard wird es beispielsweise als DML beschrieben, die meisten RDBMSs im Dialekt mit DDL. Wir einigen uns einfach auf DDL und gut ist. Viel spannender ist, was unter der Haube beim TRUNCATE TABLE Befehl passiert.

Bester Kommentar von Vedran

„Or you are trying to argue with SQL Certified Master about SQL? Good luck Mr :)“

Links aus dem Text

Full Conversation

Expand