Merhaba arkadaşlar,
Bir DBA olarak en sık duyduğum cümle şudur: “Sunucu yavaşladı, bir bakar mısın?” Bakarsınız; SSMS’i açar, birkaç DMV sorgusu çalıştırır, blocking var mı, hangi sorgu CPU yiyor, yedek alınmış mı diye tek tek kontrol edersiniz. Peki bu işi yapay zeka istemcinize yaptırabilseydiniz, hem de elle sorgu yazmadan, doğal dille konuşarak?
Bu rehberde tam olarak bunu yapan, açık kaynak ve salt-okunur (sunucunuza hiçbir şey yazmaz, yalnızca okur) bir MCP sunucusundan bahsedeceğim: mssql-health. Hem komut satırından (
npx
ile, paket npm’de değil, doğrudan GitHub’dan gelir), hem de teknik olmayan kullanıcılar için çift tıkla kurulan bir Windows uygulamasıyla. Üstelik gerçekten çalıştığını lafla değil; hem Docker’da (gerçek bir SQL Server 2022’ye bilerek sorun enjekte ederek) hem de canlı bir production SQL Server 2025 ortamında kanıtlayacağız. Başlayalım 🙂
Özet, kısaca mssql-health
- mssql-health, herhangi bir MCP istemcisini (Claude, ChatGPT, Gemini…) canlı SQL Server’ınıza bağlayan salt-okunur bir teşhis sunucusudur.
- 18 uzman DBA aracı: blocking, wait stats, eksik index (hazır
CREATE INDEXile), pahalı sorgular, yedek durumu, deadlock, konfig denetimi ve daha fazlası. - Tasarımı gereği salt-okunur: yazma/DDL/keyfi sorgu yok; en az ayrıcalıklı bir login ile çalışır.
- İki kurulum yolu: çift tıkla Windows uygulaması (kolay) veya MCP istemcinize (Claude, Cursor, VS Code)
npxile GitHub’dan ekleme (teknik). - Gerçek SQL Server 2022’de (Docker) uçtan uca test edildi: 18 aracın hepsi + 8 sorun senaryosu doğrulandı.
🔗 Proje açık kaynak
Motor (npm paketi): github.com/dmcteknoloji/mssql-health-mcp
Windows uygulaması ve indirme: github.com/dmcteknoloji/dmc-sql-saglik
İçindekiler
- mssql-health MCP nedir?
- Neden? “Bilgi” değil “erişim”
- Salt-okunur tasarım: neden bu kadar önemli
- Mimari nasıl çalışır?
- 18 teşhis aracı
- Ön gereksinimler
- Adım 1: Salt-okunur login oluşturun
- Adım 2: MCP’yi bağlayın
- Adım 3: Yapay zekaya sorun
- Örnek bir diyalog
- Docker’da gerçek test: cidden çalışıyor mu?
- Docker değil, gerçek bir production sunucusunda test
- Bu DMV’ler production’ı yorar mı?
- Üretim için güvenlik önerileri
- Anlık fotoğraf, bir de film
- Sınırları, ne yapmaz
- Sık sorulan sorular (SSS)
- Kapanış
mssql-health MCP nedir?
mssql-health, yapay zeka istemcilerinin canlı bir SQL Server üzerinde teşhis yapmasını sağlayan, açık kaynak bir MCP sunucusudur. Tek bir cümleyle: modele sunucunuzu okutur, ama asla yazdırmaz.
Bir adım geri çekilelim. Model Context Protocol (MCP), yapay zeka istemcilerinin dış araçlara nasıl bağlanacağını tanımlayan açık bir standart. Burada her “araç” tek bir işlem demek: sunucu sağlığını oku, aktif sorguları getir, eksik index’leri bul gibi. Araçların sözleşmesi baştan bellidir, dolayısıyla istemci ne yapacağını tahmin etmek zorunda kalmaz.
mssql-health’in araçları yalnızca DMV (Dynamic Management Views) sorgularından oluşur. DMV’ler SQL Server’ın kendi içini gösteren, salt-okunur sistem görünümleridir; bir DBA’in “sunucuya bakarken” kullandığı şeylerin tam olarak aynısı. Fark şu: artık bunları siz değil, doğal dille konuştuğunuz yapay zeka çağırıyor.
Bu kimin işine yarar?
- DBA’ler, rutin “neden yavaş / yedek / konfig” kontrollerini doğal dille, saniyeler içinde.
- Geliştiriciler, kendi veritabanlarını SSMS uzmanı olmadan teşhis etmek için.
- Danışman / ajanslar, birden çok müşteri sunucusunu hızlıca taramak için.
- Teknik olmayan ekipler, çift tıkla kurulan uygulama + “Hızlı Tara” ile.
Neden? “Bilgi” değil “erişim”
ChatGPT’ye “transaction log’um neden büyüyor” diye sorabilirsiniz; size gayet doğru bir cevap verir. Çünkü bu bilgi internette var. Ama “benim sunucumda log neden büyüyor” sorusuna cevap veremez, çünkü bu bilgi internette değil, sizin sunucunuzun o anki durumunda.
Modelin zaten bilgisi var. Ona verdiğimiz şey erişim, internetin asla göremeyeceği tek şeye: sizin veritabanınızın canlı durumuna.
İşte MCP’nin asıl değeri bu. “Index nasıl oluşturulur” sorusu bilgidir; “benim sunucumda hangi index eksik ve onun
CREATE
cümlesi nedir” sorusu ise erişim gerektirir. mssql-health bu erişimi, güvenli ve salt-okunur biçimde sağlar.
Bilgi değil erişim: istemci → salt-okunur MCP → canlı SQL Server → gerçek cevap.
Peki bu, elimizdeki diğer yöntemlerden ne kadar farklı? Kısa bir karşılaştırma:
| Yetenek | ChatGPT (tek başına) | SSMS (elle) | mssql-health |
|---|---|---|---|
| Sunucunuzun canlı durumunu görür | ✗ | ✓ | ✓ |
| Doğal dille konuşulur | ✓ | ✗ | ✓ |
| DMV sorgusu yazmak gerekir | , | ✓ (siz) | ✗ (AI çağırır) |
| Blocking / deadlock’u anında bulur | ✗ | ✓ (manuel) | ✓ |
Sunucunuza özel
CREATE INDEX
üretir | ✗ (genel) | ✗ | ✓ |
| Salt-okunur güvence | , | ✗ (tam yetki) | ✓ |
| Teknik bilgi ihtiyacı | Düşük | Yüksek | Düşük |
Özetle mssql-health, ChatGPT’nin doğal dilini SSMS’in canlı erişimiyle birleştiriyor, üstelik salt-okunur güvenle.
Salt-okunur tasarım: neden bu kadar önemli
Bir yapay zekaya production sunucunuza erişim vermek ilk başta ürkütücü gelir, çok da haklısınız. O yüzden bu işin tek doğru yolu salt-okunur olmasıdır. mssql-health’te bu iki katmanlı bir tasarımdır:
- Araç yüzeyinde yazma yoktur. Sadece DMV/SELECT teşhis araçları vardır.
INSERT,UPDATE,DELETE,DROP, “rastgele SQL çalıştır” gibi araçlar hiç tanımlı değildir. Model isteseydi bile çağıracağı bir yazma aracı yok. - Login seviyesinde en az ayrıcalık. Sunucuya yalnızca
VIEW SERVER STATEizni olan, veri okuyamayan bir login ile bağlanır. Yani araç da yazamaz, hesap da yazamaz. - Veri sizde kalır. Bağlantı sizin makinenizde kurulur; bağlantı diziniz ve verileriniz üçüncü bir servise gitmez.
Bu yüzden mssql-health’i gönül rahatlığıyla bir müşteriye bile teslim edebilirsiniz. En kötü senaryoda yapabileceği tek şey, okumaktır.
“Ya AI’a ‘her şeyi sil’ dersem?” Diyebilirsiniz, ve hiçbir şey olmaz. Silecek bir araç yok. Model isteyebilir, ama çağıracağı bir yazma fonksiyonu bulunmadığı için istek havada kalır. Güvenlik niyete değil, yapıya dayanır.
Mimari nasıl çalışır?
Motor, Node ile yazılmış, stdio üzerinden konuşan küçük bir MCP sunucusudur. İstemci bir araç çağırdığında, sunucu ilgili DMV sorgusunu çalıştırır ve sonucu Markdown tablo olarak geri verir. Hepsi bu kadar, ne sihir, ne kara kutu.
Teknik olmayan kullanıcılar için bir de Windows uygulaması var ve burada hoş bir numara dönüyor: tek bir
.exe
, iki rol oynuyor.
- Normal açılış: kurulum sihirbazı açılır, SQL bilgilerini girersiniz, “Kur” dersiniz, uygulama AI istemcinizin ayar dosyasını kendisi yazar.
-
ELECTRON_RUN_AS_NODE=1ile çağrılınca: aynı.exesaf Node moduna geçip gömülü MCP sunucusunu çalıştırır. Böylece müşteriye ayrıca Node.js kurmak gerekmez; tek dosya her şeyi yapar.
Uygulamanın içinde ayrıca bir “Hızlı Tara” ekranı var: AI istemcisine hiç ihtiyaç duymadan, teşhisleri doğrudan uygulama içinde çalıştırıp özet bir panelde gösterir.
18 teşhis aracı
İnternette ya da ChatGPT’de bulamayacağınız, sizin sunucunuza özel cevaplar. Hepsi salt-okunur.
Tek bir komut,
tam_teshis
, tüm kontrolleri çalıştırıp şöyle bir Sağlık Karnesi üretir:
Yapay zeka bu karneyi düz dile çevirir: “Önce yedeği düzelt, sonra şu iki ayarı değiştir.” Tek tek araç çağırmanıza gerek kalmaz. Aşağıda bu karneyi oluşturan 18 aracın tamamı var:
| Grup | Araç | Ne bulur |
|---|---|---|
| Başlangıç |
tam_teshis
| Tek çağrıda sağlık karnesi, tüm kontrolleri önceliklendirilmiş (kritik/uyarı) tek raporda toplar |
| Genel durum |
sunucu_sagligi
| Sürüm, edition, CPU, bellek, uptime, DB sayısı |
aktif_sorgular_blocking
| Çalışan sorgular + blocking zinciri (“şu an neden yavaş?”) | |
bekleme_istatistikleri
| Wait stats, sunucu neyi bekliyor (idle wait’ler hariç) | |
| Performans |
pahali_sorgular
| En çok CPU/okuma/süre yiyen sorgular + metin |
eksik_indexler
| Eksik index’ler, etki skoruna göre (kolonlarıyla listeler) | |
eksik_index_create
| Eksik index’ler, çalıştırılabilir
CREATE INDEX
cümlesiyle | |
index_sagligi
| Kullanılmayan index’ler (yazma maliyeti var, hiç okunmuyor) | |
| Sağlık ve risk |
yedek_durumu
| Son full/diff/log yedeği, yedeksiz DB’ler en üstte |
disk_dosya
/
log_kullanimi
| Disk boş alanı, dosya boyutları, log kullanımı | |
tempdb_kullanimi
| tempdb alan kullanımı (version store dahil) | |
deadlock
| system_health’ten son deadlock’lar | |
acik_transactionlar
| Uzun/açık transaction’lar (log şişiren) | |
bellek_baskisi
/
vlf_log_sagligi
| PLE, bekleyen bellek talebi; VLF sayısı | |
| Denetim |
konfig_denetimi
| MAXDOP, cost threshold, max memory… değere göre öneri |
| Yönlendirme |
surekli_izleme
| Sürekli izleme için SentinelDB360’a yönlendirir |
Araç ne döndürür?
Araçlar size ham veri verir; yapay zeka onu sade dile çevirir. Örneğin
konfig_denetimi
şuna benzer bir çıktı döndürür (Docker testimizden, gerçek):
ÇIKTI| ayar | deger | durum |
| ------------------------------ | ---------- | ------------------------------------ |
| cost threshold for parallelism | 5 | DIKKAT: cok dusuk; 25-50 onerilir |
| max degree of parallelism | 0 | DIKKAT: 0=sinirsiz; OLTP icin riskli |
| max server memory (MB) | 2147483647 | DIKKAT: sinirsiz; OS icin RAM birak |
| optimize for ad hoc workloads | 0 | DIKKAT: 1 onerilir |
Yapay zeka bu tabloyu okuyup “şu dört ayarı düzeltmelisin, sebepleri şunlar” diye anlatır. Siz ham tabloyla uğraşmazsınız.
Ön gereksinimler
- Bir SQL Server (2016+ önerilir; bazı araçlar 2016 ile gelen DMV’leri kullanır).
- Teknik yol için: Node.js (npx ile gelir) ve bir MCP istemcisi (Claude Desktop, Cursor, ChatGPT vb.).
- Kolay yol için: yalnızca Windows uygulamasını indirmek, başka hiçbir şey gerekmez.
1-Salt-okunur login oluşturun
Önce sunucuda en az ayrıcalıklı bir login açıyoruz. SSMS’te (sysadmin olarak) şunu çalıştırın:
SQL-- Sunucu geneli teşhis için salt-okunur login
CREATE LOGIN mcp_readonly WITH PASSWORD = 'GucluBirParola_2026!';
GRANT VIEW SERVER STATE TO mcp_readonly; -- DMV'leri okuyabilsin
GRANT VIEW ANY DEFINITION TO mcp_readonly; -- metadata görebilsin
-- yedek_durumu aracı için msdb okuma izni
USE msdb;
CREATE USER mcp_readonly FOR LOGIN mcp_readonly;
ALTER ROLE db_datareader ADD MEMBER mcp_readonly;
Not: Bu login veri okuyamaz, yalnızca sunucu durumunu görür. Yine de parolayı güçlü seçin ve yalnızca teşhis için kullanın.
2-MCP’yi bağlayın
Üç yol var; teknik bilginize göre seçin. Hepsi npm’e gerek olmadan, doğrudan GitHub’dan çalışır.
Yol 1, Çift tıkla Windows uygulaması (en kolay)
Teknik olmayan kullanıcılar (ya da müşteriler) için: kurulum uygulamasını indirin, çift tıklayın, SQL bilgilerini girin, “Kur” deyin. Uygulama AI istemcinizin ayarını kendisi yazar, Node, git, hiçbir şey gerekmez. GitHub Releases’ten (en son sürüm)
.exe
olarak indirin.
Yol 2, Claude Desktop / Cursor
Önce Node.js 18+ ve git kurun. Sonra istemcinizin ayar dosyasına (Claude Desktop’ta: Settings → Developer → Edit Config →
claude_desktop_config.json
) şu bloğu ekleyin:
JSON{
"mcpServers": {
"mssql-health": {
"command": "npx",
"args": ["-y", "github:dmcteknoloji/mssql-health-mcp"],
"env": {
"MSSQL_CONNECTION_STRING": "Server=SUNUCU,1433;Database=master;User Id=mcp_readonly;Password=***;Encrypt=true;TrustServerCertificate=true;ApplicationIntent=ReadOnly;"
}
}
}
}
Kaydedip istemciyi yeniden başlatın.
npx
paketi doğrudan GitHub’dan çekip çalıştırır; npm registry’ye gerek yoktur.
git yoksa: Repoyu ZIP olarak indirip açın, klasörde
npm installçalıştırın; sonra ayarı"command": "node","args": ["C:\\yol\\mssql-health-mcp\\index.js"]şeklinde yazın. Tek gereken Node.js olur.
Yol 3, VS Code (GitHub Copilot, Agent mode)
Komut Paleti (
Ctrl+Shift+P
) → “MCP: Open User Configuration” → açılan
mcp.json
‘a ekleyin (VS Code
servers
biçimini, parolayı sormak için de
inputs
kullanır):
JSON{
"inputs": [
{ "type": "promptString", "id": "sql-pass", "description": "SQL parolasi", "password": true }
],
"servers": {
"mssql-health": {
"type": "stdio",
"command": "npx",
"args": ["-y", "github:dmcteknoloji/mssql-health-mcp"],
"env": {
"MSSQL_CONNECTION_STRING": "Server=SUNUCU,1433;Database=master;User Id=mcp_readonly;Password=${input:sql-pass};Encrypt=true;TrustServerCertificate=true;ApplicationIntent=ReadOnly;"
}
}
}
}
Sonra Copilot Chat’i açın → modu Agent yapın → araç çubuğundaki Configure Tools (🎛️, “Auto”nun yanındaki sürgülü simge) ile
mssql-health
araçlarını işaretleyin.
İpucu (başımıza geldi): Agent “sunucuya erişimim yok” deyip kod yazmaya kalkarsa, araçlar kapalı demektir. Configure Tools’tan açın ya da açıkça “mssql-health araçlarını kullan,
tam_teshis‘i çağır” deyin.
3-Yapay zekaya sorun
İstemcinizi yeniden başlatın ve doğrudan günlük dilde sorun:
- “SQL sunucumun sağlığını göster”
- “Sunucum şu an neden yavaş? Blocking var mı?”
- “Hangi index’ler eksik?
CREATE INDEXcümlelerini ver” - “Yedeğim güncel mi? Konfig ayarlarımda düzeltmem gereken var mı?”
Yapay zeka uygun aracı kendisi seçip çağırır ve sonucu yorumlar. Siz tek bir DMV sorgusu yazmazsınız.
Örnek bir diyalog
Teori yeter; gerçek bir oturum nasıl görünüyor? Aşağıda, bugün Docker’da kurduğumuz sunucuya sorduğum birkaç soru ve yapay zekanın, uygun aracı kendisi seçerek, verdiği cevaplar var. Çıktılar gerçek:
Küçük bir netlik: buradaki “Yapay zeka”, sizin kullandığınız istemcidir (Claude, ChatGPT, Gemini…). mssql-health (MCP) konuşmaz, yalnızca yukarıdaki gibi ham veri döndürür. O veriyi okuyup sade dile çeviren, sizin istemcinizin yapay zekasıdır.
→ ... çağrıldısatırı, yapay zekanın hangi MCP aracını çalıştırdığını gösterir.
Dikkat edin: tek bir DMV sorgusu yazmadım. Soruyu sordum; yapay zeka doğru aracı seçip çalıştırdı ve sonucu sade bir dille yorumladı.
Döngüyü kapatmak da bir o kadar basit: önerilen
CREATE INDEX
‘i çalıştırın, sonra aynı pahalı sorguyu tekrar sorun. Yapay zeka artık o sorgunun tabloyu baştan sona taramak yerine doğrudan index’e gittiğini (scan yerine seek) gösterir. Teşhisten çözüme, tek bir sohbette.
Docker’da gerçek test: cidden çalışıyor mu?
Güzel soru, ben de aynısını sordum 🙂 O yüzden lafla bırakmayıp Docker’da gerçek bir SQL Server 2022 ayağa kaldırdım (Apple Silicon’da amd64 emülasyonuyla):
BASHdocker run -d --name sqltest --platform linux/amd64 \
-e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=Guclu!Parola2026" \
-p 14333:1433 mcr.microsoft.com/mssql/server:2022-latest
Ardından
mcp_readonly
login’ini açıp MCP’yi bağladım ve 18 aracın hepsini çağırdım. Hepsi hatasız çalıştı. Sonra işi ciddiye alıp bilerek sorun enjekte ettim: iki oturumu çapraz kilitleyip gerçek bir deadlock yarattım, blocking oluşturdum, yedeksiz bir veritabanı bıraktım, optimizer’ı tetikleyip eksik index önerisi ürettim. Araçlar hepsini doğru yakaladı:
Gerçek çıktılar: 18 aracın hepsi, yakalanan blocking ve deadlock, üretilen CREATE INDEX cümlesi ve konfig denetimi.
Bu arada uygulamanın “Hızlı Tara” paneli de aynı sunucuya bağlanıp anlık bir özet çıkardı, burada gerçek bulgular var: bir eksik index önerisi ve yedeği hiç olmayan bir veritabanı (kırmızıyla):
“Hızlı Tara” paneli: AI istemcisine gerek kalmadan, uygulama içinde anlık teşhis.
Docker değil, gerçek bir production sunucusunda test
Docker güzel ama “ya gerçek bir sunucuda?” sorusu havada kalmasın diye, mssql-health’i canlı bir müşteri ortamında da çalıştırdım: SQL Server 2025 (Standard Edition), 4 vCPU / 16 GB RAM, varsayılan dışı bir port üzerinden. Aşağıdaki sonuçlar bu gerçek sunucudan alındı; yalnızca sunucu ve veritabanı adları gizlilik için anonimleştirildi, sayılar olduğu gibi.
Bağlantı Docker’dakiyle birebir aynı, tek fark gerçek bir adres/port ve salt-okunur login:
JSON{
"mcpServers": {
"mssql-health": {
"command": "npx",
"args": ["-y", "github:dmcteknoloji/mssql-health-mcp"],
"env": {
"MSSQL_CONNECTION_STRING": "Server=MUSTERI-SQL01,14987;Database=master;User Id=mcp_readonly;Password=***;Encrypt=true;TrustServerCertificate=true;ApplicationIntent=ReadOnly;"
}
}
}
}
“SQL sunucumun sağlığını göster” dediğimde
tam_teshis
tek çağrıda şu karneyi çıkardı (gerçek veri, anonimleştirilmiş):
Bu tablo, Docker demosundan bambaşka bir hikaye anlattı. Orada ayarlar bozuktu; burada tam tersine konfigürasyon zaten özenle yapılmış (biri bu sunucuya emek vermiş). Ama yedekler iki gündür alınmıyor, gözden kaçan, üstelik en kritik konu. İşte mssql-health’in değeri tam burada: her sunucunun kendi gerçeğini, dakikalar içinde, hiçbir şeye dokunmadan önünüze koyuyor.
Gerçek sunucudan ham bir kesit,
konfig_denetimi
çıktısı (anonimleştirilmiş):
ÇIKTI| ayar | deger | durum |
| ------------------------------ | ----- | -------------------------------- |
| cost threshold for parallelism | 50 | OK |
| max degree of parallelism | 4 | OK (cekirdek sayisi ile uyumlu) |
| max server memory (MB) | 11264 | OK (16 GB RAM icin makul sinir) |
| optimize for ad hoc workloads | 1 | OK |
Yani aynı araç, kurgulanmış bir Docker kutusunda da, canlı bir SQL Server 2025 production sunucusunda da aynı netlikte çalışıyor, biri “şu ayarları düzelt” derken, diğeri “ayarların iyi, sen yedeğe bak” diyor.
Bu DMV’ler production’ı yorar mı?
Ciddi bir DBA’in ilk sorusu budur. Kısa cevap: hayır, çünkü tasarım bunu gözetiyor.
- Hepsi hafif DMV sorgusudur. Sistem görünümlerinden okurlar; tablolarınızı taramazlar.
- ReadOnly intent + zaman aşımı. Bağlantı salt-okunur niyetle açılır, sorgulara timeout konur; ağır bir teşhis bile production’ı kilitlemez.
- Tek seferlik ve anlıktır. Sürekli bir yük bindirmez; yalnızca siz sordukça çalışır.
Yani bir DBA’in SSMS’te elle çalıştıracağı sorguların aynısı, sadece bu kez tetikleyen yapay zeka.
Üretim için güvenlik önerileri
- Her zaman
mcp_readonlykullanın. Aslasaya da yetkili bir hesapla bağlamayın, gereği de yok. - Bağlantıyı şifreleyin.
Encrypt=truebırakın; kendi sertifikanız varsaTrustServerCertificate‘i kapatın. - Parola ayar dosyasında düz metindir. Bu MCP’nin doğasıdır; o makineyi koruyun, paylaşılan ortamlarda dikkatli olun.
- Salt-okunur kalın. Araç eklerken DML/DDL kapısı açmayın; ürünün değeri tam da bu sınırda.
Anlık fotoğraf, bir de film
Son bir nokta. mssql-health size anlık bir fotoğraf verir: “şu an ne oluyor”. Çok değerli, ama bazen “dün gece neydi”, “bu hafta trend ne”, “sorun büyümeden bana haber ver” dersiniz. İşte orada DMC’nin ürünü SentinelDB360 devreye giriyor, 7/24 izleme, geçmiş ve uyarı. Anlık bakış = bu MCP; sürekli koruma = SentinelDB360.
Sınırları, ne yapmaz
Dürüst olalım; her araç gibi bunun da sınırları var:
- Keyfi SQL çalıştırmaz (NL2SQL yok). Yalnızca tanımlı teşhis araçları vardır; “şu sorguyu çalıştır” diyemezsiniz. Bilinçli bir güvenlik kararı.
- Yazmaz. Index oluşturmaz, ayar değiştirmez, önerir, uygulamayı size bırakır.
- Anlık fotoğraftır. Geçmiş trend, “dün gece neydi” yoktur; o iş sürekli izleme (SentinelDB360) işidir.
- Azure SQL / yönetilen hizmetlerde bazı sunucu-seviyesi DMV’ler kısıtlıdır; o araçlar sessizce boş döner, gerisi çalışır.
- Eksik index önerisi optimizer’a bağlıdır; basit (trivial) planlarda öneri oluşmayabilir.
Bir aracın ne yapmadığını bilmek, ne yaptığını bilmek kadar önemli.
Sık sorulan sorular (SSS)
Yapay zekaya production sunucusu vermek güvenli mi?
mssql-health özelinde evet, çünkü yazma araçları hiç yok ve login salt-okunur. En kötü ihtimalle okur. Yine de en az ayrıcalık ilkesine sadık kalın.
Hangi yapay zeka istemcileriyle çalışır?
MCP açık bir standart olduğu için Claude, ChatGPT, Gemini, Cursor gibi MCP destekleyen tüm istemcilerle. Aynı
mcpServers
bloğunu kullanırlar.
Azure SQL ile çalışır mı?
Çoğu araç çalışır. Ancak
disk_dosya
ve bazı sunucu seviyesi DMV’ler yönetilen hizmetlerde kısıtlı olabilir; o araçlar sessizce boş döner, gerisi çalışır.
Eksik index aracı boş dönerse?
SQL Server, eksik index önerisini ancak optimizer bunu kaydettiğinde verir; basit ve “trivial” planlarda öneri oluşmayabilir. Araç doğrudur, sadece o an önerilecek bir şey yoktur.
Node.js kurmam gerekiyor mu?
Teknik yol için evet (npx ile gelir). Windows uygulamasını kullanırsanız hayır, tek
.exe
her şeyi içerir.
Kapanış
Özetle: yapay zekaya bilgi vermeye gerek yok, onda zaten var. Asıl değerli olan ona erişim vermek, hem de güvenli, salt-okunur biçimde. Sunucunuzu delik deşik etmeden, “şu an neden yavaş” sorusunun gerçek cevabını alabiliyorsunuz. Üstelik bunun lafta kalmadığını Docker’da gördük.
Denemek isterseniz repo ve indirme bağlantıları aşağıda. Sorularınızı yorumlara bekliyorum, kolay gelsin 🙂
Hemen deneyin 👇
- ⬇️ Windows uygulaması: Releases’ten indirin, çift tıklayın, gerisi sihirbazda.
- ⌨️ Teknik kullanıcı:
npx -y github:dmcteknoloji/mssql-health-mcp(Node 18+ ve git ile), repoyu GitHub’da bir yıldızla destekleyin. - 📈 Sürekli izleme mi lazım? SentinelDB360.
- 💬 Denediyseniz yorumda deneyiminizi paylaşın, hangi araç işinize yaradı?
Kaynaklar ve bağlantılar
Sürekli izleme: SentinelDB360
MCP standardı: modelcontextprotocol.io
Motor (açık kaynak, npm): github.com/dmcteknoloji/mssql-health-mcp
Windows uygulaması + indirme: github.com/dmcteknoloji/dmc-sql-saglik