Home/Hata Teşhis Kütüphanesi/sqlserver-8152-string-or-binary-data-truncated

SQL Server

SQL Server 2016–2022Veri Bütünlüğü & Tipler

7 dk okuma

Msg 8152, Level 16, State 14: String or binary data would be truncated

SQL Server Msg 8152 — Hangi Satır, Hangi Kolon Taşıyor?

8152 hatasında suçlu kolonu ve satırı bulma, 2019'daki 2628 mesajı ve 460 izleme bayrağı, sessiz kırpmanın gizli veri kaybı riski.

İnceleyen:Principal Database Reliability Architect

Test Edilen Sürümler: SQL Server 2022 CU15 & 2019 CU28 (Uyumluluk Düzeyi 150 & 160) | Tarihsel: SQL Server 2016 SP2 CU6 (Trace Flag 460)

Operasyonel Doğrulama & Güvenilirlik Standardı

Son Teknik İnceleme: 30 Ekim 2026

Test Edilen SürümlerSQL Server 2022 & 2019 (Compat 150/160, Msg 2628) | SQL Server 2016 SP2 CU6 (Trace Flag 460)

Gerekli YetkiALTER TABLE yetkisi; DBCC TRACEON için sysadmin; ALTER DATABASE SCOPED CONFIGURATION için ALTER DATABASE

Risk Seviyesi

HighANSI_WARNINGS OFF yaparak hatayı susturmak sessiz veri kaybına ve yasal/denetim ihlallerine yol açar

Beklenen ÇıktıMsg 2628 veya DATALENGTH analizi ile suçlu kolon ve satırın tespiti; kolonun kontrollü genişletilmesi

Geri Dönüş (Rollback) Planı:ANSI_WARNINGS ON tutulmalı, hedef kolon ALTER TABLE ile ölçülü genişletilmeli veya staging doğrulama katmanı kurulmalı

Microsoft Docs: Message 2628 Truncation Details

İlk 60 Saniye Teşhis Protokolü:

Hata mesajı semptomdur, kök neden değildir. Sunucuyu yeniden başlatmadan veya rastgele ayar değiştirmeden önce aşağıdaki "Nedeni ayırt eden tek sorgu"yu çalıştırarak gerçek senaryoyu netleştirin.

▸Belirti

plaintext

Msg 8152, Level 16, State 14, Line 1
String or binary data would be truncated.
The statement has been terminated.

Bu hatanın veritabanı mühendislerini en çok uğraştıran tarafı, mesajın hangi kolonu, hangi satırı ve taşan hangi veriyi söylememesidir. Onlarca kolon içeren bir tabloya binlerce satırlık bir INSERT ... SELECT veya ETL aktarımı çalıştırıyorsanız elinizde hiçbir ipucu kalmaz.

ÖNEMLİ

En Değerli Hızlı Tavsiye: SQL Server 2019+ Msg 2628 ve Trace Flag 460 SQL Server 2019 ve üzerinde, veritabanı uyumluluk düzeyi (compatibility level) 150 ve üzeri ise SQL Server bu hatayı sessizce geçiştirmek yerine suçlu tabloyu, kolonu ve taşan metni doğrudan söyler: ``

plaintext
Msg 2628, Level 16, State 1, Line 1
String or binary data would be truncated in table 'app.dbo.Musteri', column 'Ad'.
Truncated value: 'Mehmet Yılmaz Kara...'.


Eski sürümlerde (SQL Server 2016 SP2 CU6 ve 2017 CU12+) aynı detaylı çıktı **460 izleme bayrağı (Trace Flag 460)** ile açılabilir:

sql
DBCC TRACEON (460, -1);
-- veya veritabanı düzeyinde:
ALTER DATABASE SCOPED CONFIGURATION SET VERBOSE_TRUNCATION_WARNINGS = ON;

`` Bu tek yapılandırma teşhis süresini saatlerden saniyelere indirir!

▸Msg 2628 Etkin Değilse: Kolonu ve Satırı Tespit Etme

Eğer eski bir sürümdeyseniz veya izleme bayrağı açık değilse suçluyu iki adımda bulun:

1. Hedef Tablonun Kolon Sınırlarını İnceleyin

sql

SELECT c.name AS kolon, t.name AS tip, c.max_length AS bayt,
       CASE WHEN t.name LIKE 'n%' THEN c.max_length / 2 ELSE c.max_length END AS karakter_siniri,
       c.is_nullable
FROM sys.columns c
JOIN sys.types t ON t.user_type_id = c.user_type_id
WHERE c.object_id = OBJECT_ID('dbo.Musteri')
ORDER BY c.column_id;

UYARI

Bayt vs Karakter Tuzağı: sys.columns.max_length sütunu bayt cinsindendir. nvarchar(50) bir kolon için bu değer 100 görünür (Unicode her karakter için 2 bayt tüketir). Bu ayrımı kaçırmak yanlış kolondan şüphelenilmesine yol açar.

2. Kaynak Veride Sınırı Aşan Satırları Sorgulayın

Hedefe yazılmaya çalışılan kaynak veya staging tablosunda uzunluğu test edin:

sql

SELECT TOP 10 Ad, LEN(Ad) AS karakter_sayisi, DATALENGTH(Ad) AS bayt_boyutu
FROM staging.Musteri
WHERE DATALENGTH(Ad) > 100        -- hedef nvarchar(50) = 100 bayt
ORDER BY DATALENGTH(Ad) DESC;

LEN() karakter sayısını verirken, DATALENGTH() bayt boyutunu ölçer.

▸En Tehlikeli Senaryo: Sessiz Kırpma (Silent Truncation)

Bazı geliştiriciler hatadan kurtulmak için oturum başında uyarıları kapatır:

sql

SET ANSI_WARNINGS OFF;
INSERT INTO dbo.Musteri (Ad) VALUES ('Çok uzun ve kritik bir müşteri soyadı metni');
-- Sıfır hata ile tamamlanır, veri SESSİZCE kırpılır!

DİKKAT / TEHLİKE

Veri Kaybı Felaketi: SET ANSI_WARNINGS OFF yapmak sorunu çözmez; sistemi körleştirir. Hata almak aslında bir güvenlik kalkanıdır: verinizin bozulmadan korunduğunu kanıtlar. Bu ayarın kapalı olduğu bir sistemde haftalarca hiçbir alarm çalmadan finansal ve kimlik verileri sessizce eksik kaydedilmiş olabilir.

▸Adım Adım Kalıcı Çözüm

1. Kolonu Ölçerek Genişletin (Refleks Olarak nvarchar(max) Yapmayın!)

Hata alındığında kolonu doğrudan nvarchar(max) yapmak planlayıcı ve depolama açısından kötüdür:

•(max) kolonlar B-Tree indeks anahtarı olamaz.
•Bellek tahsisi (memory grant) hesaplamalarında SQL Server bu kolon için devasa tampon ayırır ve diğer sorguları bekletir.
•Doğru yaklaşım, verinin gerçek dağılımını ölçüp bir tavan belirlemektir:

sql

SELECT MAX(LEN(Ad)) AS en_uzun,
       PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY LEN(Ad)) OVER () AS p99_boyut
FROM staging.Musteri;

Ölçüm sonrası hedef kolonu büyütün:

sql

ALTER TABLE dbo.Musteri ALTER COLUMN Ad nvarchar(150) NULL;

Büyük tablolarda kilit süresini sıfıra indirmek için Enterprise sürümde WITH (ONLINE = ON) kullanın.

2. Kaynak ve Staging Katmanında Doğrulama Kurun

ETL boru hattında hedefe yazmadan önce otomatik bir kolon uzunluk validasyon adımı çalıştırın. Böylece işlem ortasında toplu bir ROLLBACK yaşamak yerine, geçersiz kayıtlar hemen staging aşamasında karantinaya alınır.

▸İlgili Hata Rehberleri & Hub Bağlantıları

•SQL Server Foreign Key Constraint 547 (H-23) — Veri bütünlüğü ve kısıt ihlalleri
•SQL Server Duplicate Key Unique Index 2601 (H-26) — Benzersiz anahtar ihlalleri
•SQL Server Hub — Veri tipleri ve şema optimizasyon rehberleri

Diğer Veritabanı Hata Teşhisleri

Kriz anında başvurabileceğiniz diğer doğrulanmış hata rehberleri.

Tüm Hatalar (50)

SQLSERVER5 dk