Veritabanı yöneticileri için tanılama bağlantısı

Şunlar için geçerlidir:SQL Server Azure SQL Veritabanı Azure SQL Yönetilen Örneği

SQL Server, sunucuya standart bağlantılar mümkün olmadığında yöneticiler için özel bir tanılama bağlantısı sağlar. Bu tanılama bağlantısı, sql server standart bağlantı isteklerine yanıt vermediğinde bile bir yöneticinin tanılama sorguları yürütmek ve sorunları gidermek için SQL Server'a erişmesine olanak tanır.

Bu ayrılmış yönetici bağlantısı (DAC), SQL Server'ın şifrelemesini ve diğer güvenlik özelliklerini destekler. DAC yalnızca kullanıcı bağlamını başka bir yönetici kullanıcı olarak değiştirmeye izin verir.

SQL Server, DAC'nin başarıyla bağlanmasını sağlamak için her girişimi yapar, ancak aşırı durumlarda başarılı olmayabilir.

DAC ile bağlanma

Varsayılan olarak, bağlantıya yalnızca sunucuda çalışan bir istemciden izin verilir. sp_configure sunucu yapılandırma seçeneğiyle saklı yordam kullanılarak yapılandırılmadığı sürece ağ bağlantılarına izin verilmez.

DAC kullanarak yalnızca SQL Server sysadmin rolünün üyeleri bağlanabilir.

DAC, özel bir yönetici anahtarı (sqlcmd ) kullanılarak komut istemi yardımcı programı aracılığıyla -A kullanılabilir ve desteklenir. kullanma sqlcmdhakkında daha fazla bilgi için bkz. sqlcmd - Betik oluşturma değişkenleriyle kullanma. Ayrıca, ön ekini admin: biçiminde örnek adına sqlcmd -S admin:<instance_name>bağlayabilirsiniz. Ayrıca, öğesine bağlanarak admin:<instance_name>SQL Server Management Studio Sorgu Düzenleyicisi'nden daC başlatabilirsiniz.

SQL Server Management Studio'dan bir DAC oluşturmak için:

Nesne Gezgini ve tüm açık sorgu pencereleri dahil olmak üzere ilgili SQL Server örneğine yönelik tüm bağlantıların bağlantısını kesin.
Menüden Dosya > Yeni > Veritabanı Altyapısı Sorgusu'na tıklayın
Sunucu Adı alanındaki bağlantı iletişim kutusunda, varsayılan örneği kullanıyorsanız veya admin:<server_name> adlandırılmış bir örnek kullanıyorsanız girinadmin:<server_name>\<instance_name>.

DAC bağlantı noktası

SQL Server, varsa TCP bağlantı noktası 1434 veya Veritabanı Altyapısı başlatıldığında dinamik olarak atanmış bir TCP bağlantı noktası üzerinde DAC'yi dinler. Hata günlüğü, DAC'nin dinlediği bağlantı noktası numarasını içerir. Varsayılan olarak DAC dinleyicisi yalnızca yerel bağlantı noktasında bağlantıyı kabul eder. Uzaktan yönetim bağlantılarını etkinleştiren bir kod örneği için bkz . Sunucu yapılandırması: uzak yönetici bağlantıları.

Uzaktan yönetim bağlantısı yapılandırıldıktan sonra, DAC dinleyicisi SQL Server yeniden başlatılmadan etkinleştirilir ve bir istemci artık DAC'ye uzaktan bağlanabilir. ÖNCE DAC'yi yerel olarak kullanarak SQL Server'a bağlanıp ardından uzak bağlantılardan gelen bağlantıyı kabul etmek için saklı yordamı yürüterek SQL Server yanıt vermese bile DAC dinleyicisinin sp_configure bağlantıları uzaktan kabul etmesi için etkinleştirebilirsiniz.

Küme yapılandırmalarında DAC varsayılan olarak kapalı olur. Kullanıcılar, DAC dinleyicisinin sp_configure uzak bağlantıya erişmesini sağlamak için öğesinin uzaktan yönetici bağlantısı seçeneğini yürütebilir. SQL Server yanıt vermiyorsa ve DAC dinleyicisi etkin değilse, DAC'ye bağlanmak için SQL Server'ı yeniden başlatmanız gerekebilir. Bu nedenle, kümelenmiş sistemlerde uzak yönetici bağlantıları yapılandırma seçeneğini etkinleştirmenizi öneririz.

DAC bağlantı noktası, başlatma sırasında SQL Server tarafından dinamik olarak atanır. Varsayılan örneğe bağlanırken DAC, bağlanırken SQL Server Tarayıcı Hizmeti'ne SQL Server Çözümleme Protokolü (SSRP) isteği kullanmaktan kaçınıyor. İlk olarak 1434 numaralı TCP bağlantı noktası üzerinden bağlanır. Bu başarısız olursa, bağlantı noktasını almak için bir SSRP çağrısı yapar. SQL Server Tarayıcısı SSRP isteklerini dinlemiyorsa, bağlantı isteği bir hata döndürür. DAC'nin dinlediği bağlantı noktası numarasını bulmak için hata günlüğüne bakın. SQL Server uzaktan yönetim bağlantılarını kabul etmek üzere yapılandırılmışsa, DAC'nin açık bir bağlantı noktası numarasıyla başlatılması gerekir:

sqlcmd -S tcp:<server>,<port>

SQL Server hata günlüğü, DAC için varsayılan olarak 1434 olan bağlantı noktası numarasını listeler. SQL Server yalnızca yerel DAC bağlantılarını kabul etmek üzere yapılandırılmışsa, aşağıdaki komutu kullanarak geri döngü bağdaştırıcısını kullanarak bağlanın:

sqlcmd -S 127.0.0.1,1434

Sınırlamalar

DAC yalnızca nadir durumlarda sunucu sorunlarını tanılamak için mevcut olduğundan, bağlantıda bazı kısıtlamalar vardır:

Bağlantı için kullanılabilir kaynaklar olduğundan emin olmak için SQL Server örneği başına yalnızca bir DAC'ye izin verilir. Bir DAC bağlantısı zaten etkinse, DAC üzerinden bağlanmaya ilişkin yeni istek 17810 hatasıyla reddedilir.
Kaynakları korumak için SQL Server Express, izleme bayrağı 7806 ile başlatılmadığı sürece DAC bağlantı noktasını dinlemez.
DAC başlangıçta oturum açma bilgileriyle ilişkilendirilmiş varsayılan veritabanına bağlanmayı dener. Başarıyla bağlandıktan sonra veritabanına bağlanabilirsiniz master . Varsayılan veritabanı çevrimdışıysa veya başka bir şekilde kullanılamıyorsa, bağlantı 4060 hatasını döndürür. Ancak, aşağıdaki komutu kullanarak veritabanına bağlanmak master için varsayılan veritabanını geçersiz kılarsanız başarılı olur:
```
sqlcmd -A -d master
```
Veritabanı Altyapısı örneği başlatılırsa kullanılabilir olacağı garanti edildiğinden veritabanına DAC master ile bağlanmanızı master öneririz.
SQL Server, DAC ile paralel sorguların veya komutların çalıştırılmasını yasaklar. Örneğin, DAC ile aşağıdaki deyimlerden birini yürütürseniz 3637 hatası oluşturulur:
- RESTORE...
- BACKUP...
DAC ile yalnızca sınırlı kaynakların kullanılabilir olması garanti edilir. Diğer sorguları engelleyebilecek yoğun kaynak kullanan sorgular veya sorgular çalıştırmak için DAC kullanmayın. Bu, DAC'nin mevcut sunucu sorunlarının bileşimini önlemeye yardımcı olur. Olası engelleme senaryolarını önlemek için engelleyebilecek sorgular çalıştırmanız gerekiyorsa sorguyu anlık görüntü tabanlı yalıtım düzeyleri altında çalıştırın; aksi takdirde, işlem yalıtım düzeyini olarak READ UNCOMMITTED ayarlayın ve değeri 2000 milisaniye veya her ikisi gibi kısa bir değere ayarlayın LOCK_TIMEOUT . Bu, DAC oturumunun engellenmesini engeller. Ancak, SQL Server'ın bulunduğu duruma bağlı olarak, DAC oturumu bir mandal üzerinde engellenebilir. CTRL-C kullanarak DAC oturumunu sonlandırabilirsiniz ancak bu garanti değildir. Bu durumda tek seçeneğiniz SQL Server'ı yeniden başlatmak olabilir.
DAC ile bağlantıyı ve sorun gidermeyi garanti etmek için SQL Server, DAC'de çalıştırılacak komutları işlemek için sınırlı kaynaklar ayırır. Bu kaynaklar genellikle yalnızca aşağıda listelenenler gibi basit tanılama ve sorun giderme işlevleri için yeterlidir.

DAC üzerinde paralel olarak yürütülmesi gerekmeyen herhangi bir Transact-SQL deyimini teorik olarak çalıştırabilirsiniz, ancak kullanımı aşağıdaki tanılama ve sorun giderme komutlarına kısıtlamanızı kesinlikle öneririz:

Kilitleme durumu için sys.dm_tran_locks gibi temel tanılamalar için dinamik yönetim görünümlerini sorgulama, önbelleklerin durumunu denetlemek sys.dm_os_memory_cache_counters ve etkin oturumlar ve istekler için sys.dm_exec_requests ve sys.dm_exec_sessions . Yoğun kaynak kullanan (örneğin, sys.dm_tran_version_store tam sürüm depoyu tarar ve kapsamlı G/Ç'ye neden olabilir) veya karmaşık birleşimler kullanan dinamik yönetim görünümlerinden kaçının. Performans etkileri hakkında bilgi için, belirli dinamik yönetim görünümü belgelerine bakın.
Katalog görünümlerini sorgulama.
DBCC FREEPROCCACHE, DBCC FREESYSTEMCACHE, DBCC DROPCLEANBUFFERS ve DBCC SQLPERF gibi temel DBCC komutları. DBCC CHECKDB, DBCC DBREINDEX veya DBCC SHRINKDATABASE gibi yoğun kaynak kullanımlı komutlardan kaçının.
KILL <spid>Transact-SQL komutu. SQL Server'ın durumuna bağlı olarak, KILL komut başarılı olmayabilir. Tek seçenek, SQL Server veya Azure SQL Yönetilen Örneği söz konusu olduğunda örneği yeniden başlatmak olabilir. Bazı genel yönergeler şunlardır:
- SORGUlanarak SELECT * FROM sys.dm_exec_sessions WHERE session_id = <spid>;SPID'nin öldürüldüğünü doğrulayın. Satır döndürmezse, oturumun öldürüldüğü anlamına gelir.
- Oturum hala oradaysa sorgusunu SELECT * FROM sys.dm_os_tasks WHERE session_id = <spid>;çalıştırarak bu oturuma atanmış görevler olup olmadığını doğrulayın. Görevi orada görüyorsanız, büyük olasılıkla oturumunuz şu anda öldürülüyordur. Bu önemli miktarda zaman alabilir ve hiç başarılı olmayabilir.
- Bu oturumla ilişkilendirilmiş hiçbir görev sys.dm_os_tasks yoksa, ancak komutu yürüttkten sys.dm_exec_sessions sonra oturumda KILL kalıyorsa, kullanılabilir bir çalışanınız olmadığı anlamına gelir. Çalışmakta olan görevlerden birini (görünümde sys.dm_os_taskssessions_id <> NULLlistelenmiş bir görev) seçin ve çalışanı serbest bıraktırmak için onunla ilişkili oturumu kapatın. Tek bir oturumu sonlandırmak yeterli olmayabilir: Birden çok oturumu öldürmeniz gerekebilir.

Azure SQL Veritabanı'nda sınırlama

DAC ile Azure SQL Veritabanı'na bağlanırken, seçeneğini kullanarak -d bağlantı dizesinde veritabanı adını da belirtmeniz gerekir.

Azure SQL Yönetilen Örneği'nde sınırlama

DAC, Azure SQL Yönetilen Örneği için özel bir uç nokta üzerinde çalışmaz. SQL yönetilen örneklerinde DAC, 1434 numaralı bağlantı noktasını dinler. SQL yönetilen örneklerine yönelik özel uç noktalar yalnızca bağlantı noktası 1433'te bağlantılara izin vermediğinden, DAC bağlantısı kurmak için özel uç nokta kullanamazsınız. DAC'ye bağlanmak için SQL yönetilen örneğiyle aynı sanal ağda olmanız gerekir.

Örnekler

Bu örnekte, bir yönetici sunucunun contoso-server yanıt vermediğini fark eder ve sorunu tanılamak ister. Bunu yapmak için kullanıcı komut istemi yardımcı programını etkinleştirir sqlcmd ve DAC'yi belirtmek için kullanarak contoso-server sunucuya -A bağlanır.

sqlcmd -S contoso-server -U sa -P <StrongPassword> -A

Yönetici artık sorunu tanılamak ve yanıt vermeyen oturumları sonlandırmak için sorgu yürütebilir.

SQL Veritabanı'na bağlanan benzer bir örnek, veritabanını belirtmek için parametresini -d de içeren aşağıdaki komutu kullanır:

sqlcmd -S serverName.database.windows.net,1434 -U sa -P <StrongPassword> -d AdventureWorks

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2025-08-28