SQL Server Dedicated Admin Connection (DAC): Sunucu Yanıt Vermezken Nasıl Bağlanılır?

SQL Server kilitlendiğinde, yeni bağlantıları kabul etmediğinde ya da CPU %100’e takıldığında SSMS ile bağlanmak çoğu zaman mümkün olmaz. Tam bu anlar için SQL Server’ın içinde ayrılmış küçük bir kapı vardır: Dedicated Admin Connection (DAC). DAC, kendi zamanlayıcısı ve ayrılmış kaynaklarıyla çalışan, yalnızca sysadmin üyelerinin kullanabildiği tek kişilik bir tanılama bağlantısıdır.

Bu rehberde DAC’in ne zaman işe yaradığını, neden önceden açılması gerektiğini, nasıl bağlanılacağını ve bağlandıktan sonra ne yapılıp ne yapılmaması gerektiğini anlatıyoruz.

DAC Ne Zaman İşe Yarar?

• Worker thread’ler tükendiği için SQL Server yeni bağlantıları kabul etmiyorsa.
• Ağır bir blocking zinciri ya da kaçak bir sorgu sunucuyu kilitlediyse.
• Logon trigger’daki bir hata yüzünden kimse oturum açamıyorsa.
• Normal bağlantılar zaman aşımına uğruyor ama servis hâlâ çalışıyorsa.

Bu durumlarda ilk refleks çoğu zaman servisi yeniden başlatmaktır. Ancak yeniden başlatma, uzun transaction’ların geri alınmasına ve veritabanlarının uzun bir recovery sürecine girmesine yol açabilir; sorunun nedeni de kaybolur. DAC, yeniden başlatmadan önce içeri girip neyin olduğunu görmenizi sağlar.

Önce Açın: Remote Admin Connections

DAC varsayılan olarak yalnızca sunucunun kendisinden kullanılabilir. Uzak bir makineden, örneğin kendi bilgisayarınızdaki SSMS’ten DAC ile bağlanmak için remote admin connections ayarının açık olması gerekir:

EXEC sys.sp_configure N'remote admin connections', 1;
RECONFIGURE;

Bu ayar yeniden başlatma gerektirmez; DAC dinleyicisi hemen uzak bağlantıları kabul etmeye başlar. Aynı ayarı SSMS’te sunucuya sağ tıklayıp Facets › Surface Area Configuration altındaki RemoteDacEnabled özelliğiyle de yapabilirsiniz:

DAC ile Nasıl Bağlanılır?

sqlcmd ile

Kriz anında en güvenilir yol sqlcmd’dir; az kaynak kullanır ve ek bağlantı açmaz. -A parametresi DAC’i, -d master ise varsayılan veritabanını atlayıp doğrudan master’a bağlanmayı sağlar:

sqlcmd -S SUNUCU -E -A -d master
sqlcmd -S SUNUCU\InstanceAdi -E -A -d master

Login’in varsayılan veritabanı erişilemez durumdaysa bağlantı 4060 hatasıyla düşer; -d master bunu önler, çünkü master instance ayaktayken her zaman erişilebilirdir.

SSMS ile

1. Yeni bir SSMS penceresinde Tools › Options altındaki Transact-SQL IntelliSense ayarlarından IntelliSense’i kapatın.
2. Object Explorer’ı kullanmayın; File › New › Database Engine Query ile bir sorgu penceresi açın.
3. Server name alanına admin:SUNUCU ya da admin:SUNUCU\InstanceAdi yazın.

Port ve adlandırılmış instance’lar

DAC, mümkünse TCP 1434’ü, değilse başlangıçta dinamik olarak atanan bir portu dinler. Hangi portu kullandığı error log’da yazar:

EXEC sys.xp_readerrorlog 0, 1, N'Dedicated admin connection';

Uzaktan bağlanırken bu portun güvenlik duvarında açık olması gerekir. Adlandırılmış instance’larda istemci portu SQL Server Browser’dan öğrenir; Browser kapalıysa portu açıkça yazın: sqlcmd -S tcp:SUNUCU,PORT -E. SQL Server Express, kaynak tasarrufu için DAC portunu yalnızca trace flag 7806 ile başlatıldığında dinler.

DAC’te Neler Yapılmalı?

DAC’e ayrılan kaynaklar bilerek sınırlı tutulur. Paralel sorgular çalışmaz, BACKUP ve RESTORE 3637 hatası verir. DAC’in amacı tanılamadır: ne olduğunu görmek ve gerekiyorsa sorunu yaratan oturumu sonlandırmak.

Önce DAC ile bağlı olduğunuzu doğrulayın, ardından kilitlenmeye neden olan istekleri bulun:

-- DAC ile bağlıysanız sonuç DACGroup olur
SELECT wg.name AS workload_group
FROM sys.dm_exec_sessions AS s
JOIN sys.dm_resource_governor_workload_groups AS wg ON wg.group_id = s.group_id
WHERE s.session_id = @@SPID;

-- Kendi oturumunuzun bloklanmaması için
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET LOCK_TIMEOUT 2000;

-- Çalışan istekler, bekleme türleri ve blocking zinciri
SELECT r.session_id, r.blocking_session_id, r.status, r.command,
       r.wait_type, r.wait_time, r.cpu_time, r.total_elapsed_time,
       DB_NAME(r.database_id) AS database_name,
       s.login_name, s.host_name, s.program_name,
       SUBSTRING(t.text, 1, 400) AS sql_text
FROM sys.dm_exec_requests AS r
JOIN sys.dm_exec_sessions AS s ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id <> @@SPID
ORDER BY r.total_elapsed_time DESC;

Microsoft’un önerisi de bu çerçevededir: hafif DMV ve katalog sorguları, DBCC SQLPERF gibi temel komutlar ve gerekirse KILL. DBCC CHECKDB, index rebuild ya da version store’u tarayan ağır DMV’ler gibi kaynak tüketen işlemler DAC’te çalıştırılmamalıdır.

KILL Kullanmadan Önce

Sorunu yaratan oturumu bulduğunuzda KILL tek seçenek gibi görünebilir. Ancak KILL bir transaction’ı silmez, geri alır. Saatlerdir çalışan bir işlemi sonlandırmak, en az o kadar sürecek bir rollback başlatabilir ve oturum KILLED/ROLLBACK durumunda takılı kalabilir. Bu yüzden önce oturumun ne yaptığına, ne kadar süredir çalıştığına ve kimin başlattığına bakın; mümkünse sahibiyle konuşun. Kesinti anında bu kararları nasıl verdiğimizi kesinti runbook’umuzda anlatıyoruz.

DAC Hazırlık Kontrol Listesi

• remote admin connections tüm üretim sunucularında ve cluster düğümlerinde 1.
• DAC portu error log’da doğrulandı ve yönetim ağından güvenlik duvarında açık.
• Ekipte DAC’i kimin kullanacağı belli; sqlcmd komutu runbook’ta hazır.
• Kriz sorguları (yukarıdaki gibi) önceden test edildi.
• Express sürümlerde gerekiyorsa trace flag 7806 ile başlatma planlandı.