SQL Server Collation Değişikliği: Sunucu, Veritabanı ve Kolon Collation’ı Güvenle Nasıl Değiştirilir?

Collation, SQL Server’ın metni nasıl karşılaştırıp sıraladığını belirler: “a” ile “A”nın eşit sayılıp sayılmayacağını, “e” ile “é”nin aynı olup olmadığını, karakterlerin hangi sırayla dizileceğini ve varchar verinin hangi kod sayfasıyla saklanacağını. Kurulumda bir kez seçilir ve genellikle unutulur; ta ki bir join collation conflict hatası verene, bir sorgu id adlı kolonu bulamayana ya da bir migration veritabanını farklı varsayılan collation’a sahip bir sunucuya taşıyana kadar.

Bu rehberde collation adındaki parçaların ne anlama geldiğini, collation’ın uygulandığı dört seviyeyi, sunucu, veritabanı ve kolon collation’ını güvenle nasıl değiştireceğinizi, conflict’lerin çoğunun neden tempdb’den kaynaklandığını, Türkçe “I” sorununu ve SQL collation’larında varchar ile nvarchar‘ı karıştırmanın performans tuzağını anlatıyoruz.

Kısa Cevap: SQL Server Collation Değişikliği Güvenle Nasıl Yapılır?

SQL Server collation değişikliği, önce seviyeye karar verildiğinde güvenlidir; çünkü her seviyenin etki alanı farklıdır:

• Veritabanı: ALTER DATABASE ... COLLATE metadata’yı ve yeni nesnelerin varsayılanını değiştirir. Mevcut kullanıcı kolonlarının collation’ını değiştirmez.
• Kolon: ALTER TABLE ... ALTER COLUMN her seferinde tek kolonu değiştirir, bağımlı index’ler, key’ler ve constraint’ler tarafından engellenir ve yoğun bir tabloyu bloklayabilir.
• Sunucu: değiştirmek master, model, msdb ve tempdb’nin yeniden oluşturulması demektir. Microsoft’un prosedürü veriyi dışa aktarmak, kullanıcı veritabanlarını silmek, yeniden oluşturmak, tekrar kurmak ve içe aktarmaktır. Çoğu ekip bunun yerine yeni bir instance’a taşınır.
• Hangi seviye olursa olsun: önce envanter çıkarın, tam yedek alıp restore’u test edin, uygulamayı test edin ve başlamadan önce geri dönüş planını belirleyin. En düşük riskli geri dönüş, onay alınana kadar özgün veritabanını ya da instance’ı olduğu gibi bırakmaktır.

Aşağıdaki karar tablosu seçenekleri karşılaştırır. Her satır Microsoft dokümanı ya da Saha pratiği (bizim önerimiz, Microsoft gereksinimi değil) olarak etiketlenmiştir.

Bir Collation Adını Okumak

Collation adı aslında bir kurallar listesidir. Örneğin Turkish_100_CI_AS_SC_UTF8:

SQL_Latin1_General_CP1_CI_AS gibi SQL_ ile başlayan collation’lar geriye uyumluluk için tutulan eski SQL collation‘larıdır. Bu ön eki taşımayanlar Windows collation‘larıdır ve varchar ile nvarchar‘a aynı kuralları uygular. Yeni veritabanlarında Windows collation’ı, tercihen 100 veya daha yeni bir sürümü kullanın.

-- Instance'ta kullanılabilen collation'lar
SELECT name, description
FROM sys.fn_helpcollations()
WHERE name LIKE N'Turkish%' OR name LIKE N'Latin1_General_100%'
ORDER BY name;

Collation’ın Dört Seviyesi

Collation dört seviyede belirlenir; bir seviyede belirtilmediğinde bir üstteki seviyeden miras alınır:

• Sunucu (instance): kurulumda seçilir. master, model, msdb ve tempdb‘nin collation’ıdır ve yeni veritabanları için varsayılandır. Değişken, GOTO etiketi ve geçici tablo adlarını da bu collation yönetir.
• Veritabanı: CREATE DATABASE ... COLLATE ile belirlenir. Veritabanının metadata’sına (nesne ve kolon adları) uygulanır ve yeni kolonlar için varsayılandır.
• Kolon: her char, varchar, nchar ve nvarchar kolonun, oluşturulduğunda sabitlenen kendi collation’ı vardır.
• İfade: sorgudaki COLLATE, tek bir karşılaştırma ya da ORDER BY için collation’ı geçersiz kılar.

-- Sunucu, veritabanı ve kolon collation'larına genel bakış
SELECT SERVERPROPERTY('Collation') AS server_collation;

SELECT name, collation_name
FROM sys.databases
ORDER BY name;

-- Collation'ı veritabanının varsayılanından farklı olan kolonlar
SELECT
    s.name  AS schema_name,
    t.name  AS table_name,
    c.name  AS column_name,
    c.collation_name
FROM sys.columns AS c
JOIN sys.tables  AS t ON t.object_id = c.object_id
JOIN sys.schemas AS s ON s.schema_id = t.schema_id
WHERE c.collation_name IS NOT NULL
  AND c.collation_name <> CONVERT(sysname, DATABASEPROPERTYEX(DB_NAME(), 'Collation'))
ORDER BY schema_name, table_name, column_name;

Son sorgu göründüğünden daha önemlidir. Bir veritabanının collation’ı değiştirildiğinde mevcut kolonlar eski collation’ında kalır; bu yüzden eski veritabanlarının çoğunda kimsenin planlamadığı bir collation karışımı bulunur.

Collation Conflict’leri ve tempdb’nin Rolü

Farklı collation’lara sahip iki ifade karşılaştırıldığında ve hiçbirinin önceliği yoksa SQL Server hangi kuralı uygulayacağına karar veremez ve 468 numaralı hatayı verir:

En yaygın neden tempdb’dir. Geçici tablolar tempdb’de oluşturulduğu için metin kolonları kullanıcı veritabanının değil, sunucunun collation’ını alır. SQL_Latin1_General_CP1_CI_AS ile kurulmuş bir sunucuda Turkish_CI_AS kullanan bir veritabanı varsa, geçici tablo ile gerçek tablo arasındaki her join hata verir.

Çözüm her sorguda değil, geçici tablonun tanımında olmalıdır:

CREATE TABLE #Customers
(
    CustomerCode varchar(20) COLLATE DATABASE_DEFAULT NOT NULL,
    CustomerName nvarchar(200) COLLATE DATABASE_DEFAULT NULL
);

-- Ya da tek bir sorguda conflict'i açıkça çözün
SELECT o.OrderID
FROM dbo.Orders AS o
JOIN #Customers AS c
  ON o.CustomerCode = c.CustomerCode COLLATE DATABASE_DEFAULT;

İpucu: SELECT … INTO #temp kaynak kolonların collation’ını kopyaladığı için conflict’e yol açmaz. Sorun, metin kolonları COLLATE belirtilmeden tanımlanan CREATE TABLE #temp ifadelerinden çıkar. Contained veritabanlarında bu sorun hiç yaşanmaz; geçici tabloları veritabanının collation’ını kullanır.

Bir WHERE ya da JOIN içinde kolona COLLATE uygulamanın bir maliyeti vardır: ifade artık index’li kolon olmadığından o kolondaki index seek, scan’e dönüşebilir. COLLATE‘i index’li olmayan tarafa koyun; bu genellikle geçici tablo ya da parametredir.

Türkçe “I” Sorunu

Türkçede çoğu dilde iki olan harf dörttür: noktalı i/İ ve noktasız ı/I. Türkçe collation’larda i‘nin büyük harfi I değil İ‘dir. Bu, Türkçe metin için doğru davranıştır; ancak İngilizce kurallarla yazılmış kod için sürprizdir:

SELECT
    CASE WHEN N'istanbul' = N'ISTANBUL' COLLATE Latin1_General_100_CI_AS
         THEN 'eşit' ELSE 'eşit değil' END AS latin_ci,   -- eşit
    CASE WHEN N'istanbul' = N'ISTANBUL' COLLATE Turkish_100_CI_AS
         THEN 'eşit' ELSE 'eşit değil' END AS turkish_ci, -- eşit değil
    UPPER(N'id' COLLATE Turkish_100_CI_AS)   AS upper_tr; -- İD

Metadata veritabanının collation’ını izlediği için aynı kural nesne adlarına da uygulanır. Turkish_CI_AS kullanan bir veritabanında ID adlı bir kolon, id yazan bir sorgu tarafından bulunamaz; Latin collation üzerinde geliştirilmiş bir uygulama ya da ORM “Invalid column name” hatası alır. Paket yazılımların Türkçe varsayılanlı sunuculara kurulmasında ya da Türkçe bir veritabanının başka ortamda test edilmiş bir uygulamanın arkasına taşınmasında en sık karşılaşılan sorunlardan biri budur.

Tersi hata da yaygındır: Türkçe metni Latin collation altında saklamak. Sıralama Ç, Ğ, İ, Ö, Ş ve Ü harflerini yanlış yerlere koyar; büyük-küçük harf duyarsız arama da “ı” ile “I”yı Türk kullanıcıların beklediği şekilde eşleştirmez. Türkçe iş verisi için Turkish_100_CI_AS gibi Türkçe bir Windows collation’ı, uygulama buna göre yazıldığı sürece genellikle doğru seçimdir.

SQL Collation’larında varchar/nvarchar Tuzağı

SQL_Latin1_General_CP1_CI_AS gibi bir SQL collation altında varchar ve nvarchar farklı kurallarla karşılaştırılır. Bir uygulama varchar bir kolona karşı nvarchar parametre gönderdiğinde (birçok sürücü ve ORM’de varsayılan davranış budur) SQL Server parametreyi değil kolonu dönüştürür ve index seek, index’in tamamının taranmasına dönüşür.

Windows collation altında aynı karşılaştırma yine seek kullanabilir, çünkü iki tip de aynı kuralları izler. Bu, yeni veritabanlarında Windows collation’larını tercih etmek ve uygulamaların parametreleri kolonla aynı tipte göndermesini sağlamak için bir neden daha.

Veritabanı Collation’ı Nasıl Değiştirilir?

ALTER DATABASE SalesDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE SalesDB COLLATE Turkish_100_CI_AS;
ALTER DATABASE SalesDB SET MULTI_USER;

Bu komutun yaptığı ve yapmadığı:

• Metadata’nın collation’ını ve yeni kolonların varsayılanını değiştirir.
• Mevcut kolonları değiştirmez; verileri ve index’leri eski collation’da kalır.
• Veritabanına özel (exclusive) erişim gerektirir.
• Mevcut collation’a bağımlı schema-bound nesneler varsa başarısız olur: schema-bound view ve fonksiyonlar, computed column’lar ve CHECK constraint’ler. Bunların önce silinip sonra yeniden oluşturulması gerekir.

Kolon Collation’ı Nasıl Değiştirilir?

ALTER TABLE dbo.Customers
ALTER COLUMN CustomerName nvarchar(200) COLLATE Turkish_100_CI_AS NOT NULL;

Kolon bir index’in, primary ya da foreign key’in, bir istatistik nesnesinin, computed column’ın veya CHECK constraint’in parçasıysa komut başarısız olur. Pratikte bir kolon değişikliği küçük bir projedir: bu nesnelerin script’ini alın, silin, kolonu değiştirin, yeniden oluşturun ve istatistikleri güncelleyin. Büyük tablolarda bu, tablonun tamamını log’a yazan, veri boyutuyla orantılı bir işlemdir.

Bir veritabanındaki tüm kolonları değiştirmek gerekiyorsa, yerinde yüzlerce ALTER COLUMN çalıştırmak yerine hedef collation ile yeni bir veritabanı oluşturup şemayı orada kurmak ve veriyi taşımak çoğu zaman daha temizdir.

Sunucu Collation’ı Nasıl Değiştirilir?

Sunucu collation’ı sistem veritabanlarının collation’ıdır. Değiştirmek, onları yeniden oluşturmak anlamına gelir:

.\setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER `
  /SQLSYSADMINACCOUNTS="DOMAIN\DBA-Admins" /SAPWD="<GucluParola>" `
  /SQLCOLLATION=Turkish_100_CI_AS

Bu yüzden sunucu collation’ı değişikliği genellikle doğru collation ile yeni bir instance kurulup ona taşınarak, çoğu zaman da bir upgrade ile birlikte yapılır. Taşınması gereken sunucu seviyesi nesneleri SQL Server upgrade rehberimizde listeliyoruz.

Risk ve Geri Dönüş: Hangi Collation Değişikliği Uygun?

Sistem Veritabanları, tempdb ve Contained Veritabanları

Sunucu collation’ı tüm sistem veritabanlarının ve yeni kullanıcı veritabanlarının varsayılan collation’ıdır. Ayrıca tempdb içindeki nesnelerin, örneğin geçici tabloların collation’ını da belirler. Sunucudan farklı collation’a sahip bir veritabanının geçici tablo join’lerinde neden bu kadar sık 468 hatası aldığı budur.

-- Sunucu ve tempdb collation'ı, her veritabanının collation'ı ve containment durumu
SELECT SERVERPROPERTY('Collation')            AS server_collation,
       DATABASEPROPERTYEX('tempdb', 'Collation') AS tempdb_collation;

SELECT name, collation_name, containment_desc
FROM sys.databases
ORDER BY database_id;

Değişiklik planlarken iki sonuç önemlidir:

• Sunucu rebuild’i yalnızca sunucu varsayılanını ve tempdb’yi değiştirir. Mevcut kullanıcı veritabanları kendi collation’larını korur; bu yüzden rebuild sonrası gidermeye çalıştığınız uyumsuzluğun tam kendisini oluşturabilirsiniz.
• Veritabanı collation’ını değiştirmek tempdb’yi değiştirmez. Metin kolonları COLLATE belirtilmeden tanımlanan geçici tablolar sunucu collation’ını izlemeye devam eder.

Contained veritabanı, instance ve tempdb collation’larına olan bağımlılığı ortadan kaldırır. Microsoft bu davranışı şöyle belgeler:

Saha pratiği: containment’ı taşınabilirlik için alınan bir tasarım kararı olarak görün ve önce Microsoft dokümanındaki özellik kısıtlarını inceleyin. Bir veritabanını yalnızca collation conflict’lerini gizlemek için dönüştürmeyin.

Migrasyon Yaklaşımı: Collation’ı Rebuild ile Değil, Taşıyarak Değiştirin

Bu bir Saha pratiğidir. Özgün veritabanını ya da instance’ı bozmadan bırakır; böylece geri dönüş bir restore değil, bir cutover olur:

1. Envanter. Sunucu, tempdb, veritabanı ve kolon collation’larını, containment durumunu ve ALTER COLUMN‘u engelleyecek index’li kolonları kaydedin (aşağıdaki sorgular).
2. Veritabanı başına hedef collation’ı seçin ve uygulama üreticisinin neyi desteklediğini doğrulayın. Identifier büyük-küçük harf ve Türkçe “I” davranışını geri yüklenmiş bir kopyada test edin.
3. Hedefi hazırlayın. Yeni veritabanını CREATE DATABASE ... COLLATE ile oluşturun ya da yeni instance’ı hedef SQLCOLLATION ile kurun. Index’ler, constraint’ler, izinler ve sunucu seviyesi nesneler dahil şemanın script’ini alın.
4. Veriyi yükleyin: bcp ya da INSERT ... SELECT ile. Microsoft’un kendi sunucu collation prosedürü dışa ve içe aktarma için bcp kullanır.
5. Doğrulayın. Satır sayılarını ve örnek sorgu sonuçlarını karşılaştırın, uygulama test setini çalıştırın ve tip ya da collation uyumsuzluğundan doğan yeni scan’ler için planlara bakın.
6. Cutover yapın ve eski kopyayı saklayın. İş birimi onay verene kadar salt okunur ya da offline tutun, sonra kaldırın.

1. adım için salt okunur envanter sorguları. Bunlar Saha pratiğidir, Microsoft örneği değildir; çıktısına güvenmeden önce test ortamında çalıştırın. Aday listesi verirler, kapsamlı bir bağımlılık taraması değildir: computed kolonlar, CHECK constraint’ler, schema-bound nesneler ve foreign key’ler ayrıca incelenmelidir.

-- Her kullanıcı veritabanında çalıştırın: kaç metin kolonu hangi collation'ı kullanıyor?
SELECT c.collation_name, COUNT(*) AS column_count
FROM sys.columns AS c
JOIN sys.tables  AS t ON t.object_id = c.object_id
WHERE c.collation_name IS NOT NULL
GROUP BY c.collation_name
ORDER BY column_count DESC;

-- Veritabanı varsayılanından farklı index'li ya da key'li metin kolonları
-- (index ya da key script'lenip silinene kadar ALTER COLUMN'u engeller)
SELECT s.name AS schema_name, t.name AS table_name, c.name AS column_name,
       i.name AS index_name, i.is_primary_key, i.is_unique_constraint, c.collation_name
FROM sys.index_columns AS ic
JOIN sys.indexes AS i ON i.object_id = ic.object_id AND i.index_id = ic.index_id
JOIN sys.columns AS c ON c.object_id = ic.object_id AND c.column_id = ic.column_id
JOIN sys.tables  AS t ON t.object_id = c.object_id
JOIN sys.schemas AS s ON s.schema_id = t.schema_id
WHERE c.collation_name IS NOT NULL
  AND c.collation_name <> CONVERT(sysname, DATABASEPROPERTYEX(DB_NAME(), 'Collation'))
ORDER BY schema_name, table_name, index_name;

Bu makaledeki yerinde çalışan ifadeler Microsoft dokümantasyonundan gelir: ALTER DATABASE ... COLLATE, ALTER TABLE ... ALTER COLUMN ve setup /ACTION=REBUILDDATABASE ... /SQLCOLLATION. Hangisini olursa olsun önce geri yüklenmiş bir kopyada çalıştırın.

Yeni Bir Sunucu veya Veritabanı İçin Collation Seçimi

• Önce uygulama üreticisinin gereksinimine uyun. ERP’ler ve paket yazılımlar çoğu zaman tek bir collation’ı destekler.
• Mümkünse sunucu ve kullanıcı veritabanları için aynı collation’ı kullanın; tempdb conflict’lerini ortadan kaldırır.
• SQL collation yerine Windows collation’ı, eski sürümler yerine 100 veya 140 sürümünü tercih edin.
• Türkçe veri için, uygulamayı “I” sorununa karşı test ettikten sonra Türkçe bir collation kullanın.
• _SC_UTF8 collation’larını ancak test ettikten sonra düşünün; ağırlıklı olarak Latin karakterli metinde varchar için yer kazandırırlar, ama her iş yükünde değil.
• Büyük-küçük harf duyarlılığına bilinçli karar verin. CS bir collation nesne adlarını, veri karşılaştırmalarını ve sunucu seviyesinde değişken adlarını büyük-küçük harfe duyarlı hale getirir.

Collation Değişikliği Öncesi Kontrol Listesi

• Mevcut sunucu, veritabanı ve kolon collation’ları dokümante edildi.
• Bağımlı index’ler, key’ler, constraint’ler, computed column’lar ve schema-bound nesnelerin script’i alındı.
• Full backup alındı ve restore testi yapıldı.
• Uygulama, tanımlayıcıların büyük-küçük harf kullanımı ve LIKE aramaları dahil yeni collation’a karşı test edildi.
• Geçici tablo tanımları COLLATE DATABASE_DEFAULT kullanıyor.
• Bakım penceresi, etkilenen tabloların yeniden yazılmasına yetecek şekilde planlandı.
• Sunucu değişikliğinde, yeniden oluşturmadan önce tüm sunucu seviyesi nesnelerin script’i alındı.

Kaynaklar ve Gözden Geçirme Tarihi

Bu makale 19 Ekim 2026 tarihinde aşağıdaki Microsoft Learn sayfalarına karşı kontrol edildi. Saha pratiği olarak etiketlenen ifadeler bizim önerilerimizdir ve bu sayfalarda yazmaz. Bu makaledeki katalog sorguları salt okunurdur. T-SQL örnekleri SQL Server 2025 (build 17.0.4055.5) üzerinde test edilmiştir.

• Set or change the server collation
• Set or change the database collation
• Set or change the column collation
• Contained database collations
• Rebuild system databases