SQL Server sunucu kiralama teklifinde yalnızca “8 vCPU, 32 GB RAM, 500 GB SSD” gibi bir kaynak listesine bakmak yanıltıcı olabilir. Veritabanı yanıt süresini sorgu tasarımı, işlemci gücü, bellek baskısı, disk gecikmesi, IOPS, uygulama bağlantısı, lisanslama ve geri yükleme mimarisi birlikte belirler. Logo, Mikro, Zirve ve benzeri iş uygulamalarında kararın gerçek iş yüküne dayanması gerekir.
Kısa cevap: Önce mevcut SQL Server sürümünü, veritabanı büyüklüğünü, eşzamanlı kullanıcıları, yoğun saatleri ve disk bekleme sürelerini ölçün. Sonra VPS / bulut sunucu ile ayrılmış kaynakları aynı lisans, depolama, yedekleme ve destek koşullarıyla karşılaştırın. Sunucu kapasitesini uygulama testinde doğrulayın. SQL Server barındırma için teknik teklif alın ve firmalardan yalnız donanımı değil, operasyon sorumluluğunu da yazılı isteyin.
Bu rehber, Türkiye'deki BT yöneticileri, CTO'lar, ERP çözüm ortakları ve satın alma ekipleri için hazırlandı. Hedef yalnız SQL Server'ı bir sanal makinede çalıştırmak değil; kurumsal veriye güvenli erişim, öngörülebilir performans, geri dönüş ve ölçülebilir hizmet kapsamı sağlamaktır.
1. SQL Server için VPS mi, dedicated sunucu mu seçilmeli?
Sanal sunucu, kaynakları sanallaştırma katmanında tahsis ederek kolay kapasite artışı ve operasyon esnekliği sağlayabilir. Dedicated sunucu kiralama ise fiziksel işlemci, bellek ve disk kaynaklarının kuruma ayrılmasının istendiği sürekli veya yoğun iş yüklerinde değerlendirilebilir. Ancak “dedicated daima hızlıdır” ya da “VPS daima ucuzdur” demek doğru değildir.
Önemli olan üretim yükünde sürdürülebilir CPU performansı, disk gecikmesi, belleğin gerçekten ayrılması, depolama paylaşım modeli ve hata durumunda hizmetin ne olacağıdır. İyi tasarlanmış sanal bir SQL Server, gereksinimi karşılayabilir. Kötü yapılandırılmış fiziksel sunucu ise sorgu darboğazını çözmeyebilir.
| Kriter | SQL Server VPS | Dedicated SQL Server |
|---|---|---|
| Kaynak modeli | Tahsisli sanal kaynaklar, altta paylaşımlı platform olabilir | Kuruma ayrılmış fiziksel sistem |
| Ölçekleme | Platforma bağlı olarak daha esnek olabilir | Fiziksel kapasite ve yükseltme sınırına bağlı |
| Performans kanıtı | VM ve depolama yük testi | Fiziksel CPU, disk ve uygulama yük testi |
| Lisanslama | Sanallaştırma ve erişim hakları ayrıca incelenmeli | Fiziksel çekirdek ve kullanım modeli incelenmeli |
| İş sürekliliği | Platform HA ve yedek tasarımına bağlı | Donanım arızası ve kurtarma mimarisine bağlı |
Bu modellerin hiçbiri tek başına yüksek erişilebilirlik garantisi değildir. Teklifte olası host arızası, veri taşıma, geri yükleme ve kapasite artırma koşullarını ayrıntılı sorun.
2. CPU ve eşzamanlı kullanıcı sayısı nasıl boyutlandırılır?
SQL Server işlemleri her zaman tüm CPU çekirdeklerine eşit biçimde dağılmaz. Karmaşık raporlar, kilit beklemeleri, paralel sorgular, indeks yapısı ve uygulamanın sorgu oluşturma yöntemi kapasiteyi etkiler. Bu nedenle yalnız işlemci kullanım yüzdesi ile “daha çok vCPU gerekiyor” kararı vermek isabetli olmayabilir.
Teklif öncesinde yoğun iş saatlerinde işlemci ortalaması ve tepe değeri, kritik sorgu süreleri, çalışan iş sayısı ve bekleme türleri izlenmelidir. Sunucu performans sorunu ile tek bir SQL sorgusunun oluşturduğu yükü ayrı değerlendirin. Çok kullanıcılı ERP ortamlarında işlemciye ek olarak bağlantı sayısı, uzun işlemler ve kilitlenmeler ölçülmelidir.
İlk kurulum için kaynak sınıfı seçimi yapıldıktan sonra müşteri iş yükünü temsil eden rapor alma, fiş kaydetme, stok sorgulama ve toplu veri işleme gibi senaryolar test edilmelidir. Tek bir sentetik CPU benchmark sonucu bu iş akışlarını temsil etmez.
3. SQL Server kaç GB RAM ister? Max server memory neden ayarlanır?
SQL Server belleği, sık erişilen veri sayfalarının önbellekte tutulmasına ve sorguların bellek kullanmasına yardımcı olur. Ancak aynı Windows sunucusunda işletim sistemi, yedekleme ajanı, antivirüs, başka SQL örnekleri veya ERP servisleri de bellek kullanır. Mevcut RAM'in tamamını SQL Server'a bırakmak doğru varsayılan yaklaşım değildir.
Microsoft, max server memory (MB) ayarının sunucunun diğer tüketicilerine de alan bırakacak şekilde yapılandırılmasını önerir. Gerçek gereksinim SQL Server instance sayısına, bellek tüketimi raporuna ve uygulama servislerine göre hesaplanmalıdır. Microsoft SQL Server bellek yapılandırma rehberi bu yaklaşımı açıklar.
Bir SQL Server'a “32 GB yeter” veya “64 GB şart” demek iş yükü bilinmeden mümkün değildir. Bellek baskısı varsa veritabanı önbelleği, çalışma kümeleri, sorgu planları ve işletim sistemi kullanımı incelenir. Aşırı bellek tahsisi de gereksiz aylık maliyet oluşturabilir.
4. SSD, NVMe, IOPS ve disk gecikmesi arasındaki fark nedir?
IOPS, saniye başına giriş/çıkış işlemi sayısını; latency, bir disk işleminin tamamlanması için geçen süreyi; throughput ise birim zamanda aktarılabilen veri miktarını ifade eder. SQL Server'ın küçük rastgele okuma ve yazma işlemleri, yalnız sıralı disk hızından farklı sonuçlar verebilir.
NVMe kullanılması depolama teknolojisini anlatır, fakat her kiralama paketinin aynı IOPS ve gecikme değerini garanti ettiği anlamına gelmez. Paylaşımlı storage katmanı, disk doluluğu, yedek yükü, disk kuyruğu ve ağ üzerinden depolama erişimi sonuçları etkileyebilir. Teklifte ölçüm koşulunu ve yoğun saat davranışını açıkça belirtin.
Microsoft, uygun koşullarda veri dosyaları ile transaction log dosyalarının farklı mantıksal sürücülerde tutulmasını önerir; amaç olası I/O rekabetini azaltmaktır. Ayrı sürücü tanımı tek başına farklı fiziksel diskleri garanti etmediğinden alttaki depolama mimarisini de sorun. Microsoft veri ve log ayırma önerisi.
5. SQL veri, log, tempdb ve yedek alanları nasıl planlanmalı?
SQL Server altyapısında işletim sistemi diski, veritabanı veri dosyaları, transaction log dosyaları, tempdb ve yedekleme hedefi birbirinden farklı görevler üstlenir. Her ortamda ayrı fiziksel disk zorunlu değildir; fakat depolama kapasitesi ve performansının hangi katmanlarda paylaşıldığı bilinmelidir.
Log alanındaki gecikme, işlem tamamlanma süresini etkileyebilir. tempdb ise sorgu ara işlemleri ve çeşitli dahili işlevler için yük oluşturabilir. Büyüme tahmininde yalnız mevcut MDF boyutunu değil log büyümesi, indeks bakım ihtiyacı, tempdb, yedekler ve operasyonel boş alanı da değerlendirin.
Satıcıya veri büyüme prosedürünü sorun: SSD alanı artışı kesinti gerektiriyor mu, veritabanı dosyalarının büyütülmesi kimin sorumluluğunda, kapasite eşiği kim tarafından izleniyor? İzleme eksikliği, disk teknolojisinden bağımsız şekilde hizmet kesintisine neden olabilir.
6. SQL Server 2022, 2025 Standard ve Enterprise nasıl karşılaştırılır?
Ürün sürümü seçimi yalnız “en yeni sürüm” kararı değildir. Logo, Mikro veya başka bir ERP uygulamasının desteklediği SQL Server sürümü, veritabanı uyumluluk seviyesi, yedek geri yükleme yönü ve üretici onayı da kontrol edilmelidir. Uygulamanın belirli SQL sürümüne bağımlı olması geçişin kapsamını değiştirebilir.
Microsoft'un SQL Server 2025 belgelerinde Standard sürüm için tek örnekte azami hesaplama sınırı 4 soket veya 32 çekirdeğin düşük olanı, buffer pool bellek sınırı ise 256 GB olarak açıklanır. SQL Server 2022 ve öncesinde Standard işlem çekirdeği sınırı farklıdır. Bu rakamlar donanım paketi tavsiyesi değildir; ürün sürümü/sürüm tipinin kapasite üst sınırlarıdır. SQL Server 2025 sürüm karşılaştırması.
Enterprise sürümü özellik ve ölçek ihtiyaçları olan iş yüklerinde değerlendirilebilir; ancak gerçek lisans maliyeti ayrı inceleme gerektirir. Express veya Developer sürümlerinin ücretsiz olması, her üretim senaryosunda aynı haklara sahip oldukları anlamına gelmez. Özellikle Developer sürümü üretim kullanımı için lisanslı değildir.
7. SQL Server kiralamada lisans maliyeti nasıl hesaplanır?
Microsoft SQL Server'ın lisanslanması, sürüm ve kullanım modeline göre farklı kurallara tabidir. Standard için Server + CAL veya core bazlı lisans seçenekleri bulunabilen senaryolar vardır; fakat kiralık sunucuda bunların uygulanabilirliği, sanallaştırma, erişen kullanıcı/cihaz sayısı, tedarikçinin lisanslama anlaşması ve geçerli üretici kullanım haklarına bağlıdır.
Özellikle “Windows Server dahil, SQL de dahildir” ifadesi doğrulanmadan kabul edilmemeli. Windows Server, SQL Server ve varsa Remote Desktop Services lisansları ayrı kalemlerdir. Firmadan SQL ürün sürümü, edition, fiziksel veya sanal çekirdek kapsamı, varsa CAL, bakım ve yükseltme haklarını yazılı isteyin.
Nihai lisans koşullarını Microsoft SQL Server lisans belgeleri ve sözleşmenize uygun yetkili lisans değerlendirmesi üzerinden doğrulayın. Bu rehber genel satın alma kontrol listesi sunar; belirli kiralık ortam için hukuki lisans uygunluk kararı vermez.
8. SQL sorguları yavaşsa daha büyük sunucu her zaman çözüm mü?
Hayır. Disk veya bellek kaynak baskısı olmadan da hatalı sorgu planı, eksik indeks, parameter sniffing, yoğun kilitlenme veya uygulama katmanındaki bekleme nedeniyle kullanıcı gecikmesi oluşabilir. Donanımı yükseltmeden önce darboğazın kaynağını görmek gerekir.
Microsoft'un Query Store özelliği, sorgu planlarının ve yürütme istatistiklerinin zaman içindeki değişimini incelemeye yardımcı olur. Uygun sürüm ve veritabanı yapılandırmasında yavaşlayan sorguları, plan regresyonlarını ve beklemeleri anlamak için kullanılır. Microsoft Query Store performans izleme rehberi.
Netsun Bilişim'den teklif isterken yavaşlık şikâyetini “sunucu yavaş” diye özetlemek yerine hangi ekranın, hangi raporun, kaç eşzamanlı kullanıcıyla ve hangi saatlerde yavaşladığını belirtin. Bu, gereksiz kaynak yükseltmesini önleyen teknik keşfin başlangıcıdır.
9. SQL Server yedekleme, log backup ve RPO/RTO nasıl ele alınmalı?
Günlük tam yedek almak birçok kurumsal sistem için başlangıç olabilir, ancak iş gereksinimine göre tek başına yeterli olmayabilir. Uygun recovery model ile differential ve transaction log yedekleri farklı geri dönüş noktaları sağlayabilir. SQL Server'ın Full ve Simple kurtarma modellerinin desteklediği geri yükleme seçenekleri farklıdır; seçimi iş yükü ve bakım kapasitesi belirler.
RPO kabul edilebilir veri kaybı aralığını, RTO hizmetin yeniden kullanıma hazır hale gelmesi için hedeflenen süreyi ifade eder. Yalnız veritabanının geri yüklenmesi değil, uygulamanın ve kullanıcı erişiminin de ayağa kaldırılması hesaba katılmalıdır. Microsoft SQL Server recovery models.
Yedeklerin üretim ortamından ayrılması ve belirli aralıklarla gerçekten test edilmesi gerekir. Microsoft, yedek stratejisinin test sisteminde geri yükleme ve DBCC CHECKDB gibi kontrollerle değerlendirilmesini önerir. Microsoft yedekleme ve geri yükleme rehberi. Kurumsal yedekleme ve felaket kurtarma seçeneklerini de teklif kapsamına dahil edin.
10. ERP sunucusu ile SQL veritabanını aynı sunucuda mı tutmalı?
Küçük bir kurulumda uygulama ve SQL Server'ın aynı Windows sunucusunda bulunması operasyonu basitleştirebilir. Daha yoğun iş yüklerinde ayrı sanal makineler, bağımsız kaynak tahsisi, güvenlik segmentasyonu ve bakım planlaması açısından yararlı olabilir. Ancak ayrı sunucu kullanımı ağ bağlantısı ve lisans maliyetini artırabilir.
İşletmeler için önemli olan, SQL Server ile ERP yazılımının hangi katmanlarda çalıştığını ve uygulama üreticisinin bu mimariyi destekleyip desteklemediğini doğrulamaktır. ERP ve muhasebe uygulamaları için sunucu altyapısını tasarlarken kullanıcı erişimi, entegrasyonlar, SQL sürümü ve kurumsal raporlama birlikte değerlendirilmelidir.
Kritik uygulamalarda SQL ve uygulama ağlarının ayrılması, servislere yalnız gerekli portlardan erişilmesi ve dış dünyaya doğrudan veritabanı bağlantısı açılmaması temel tasarım yaklaşımı olabilir. Ağ güvenliği ve VPN hizmetleri ile veritabanının erişim yolunu ayrıca tasarlayın.
11. Sunucu taşıma, SQL lisansı ve kullanıcı kesintisi
Mevcut ofis sunucusundan, başka bir veri merkezinden veya Azure VM'den taşıma yapılırken veritabanı dosyalarını doğrudan kopyalamak her zaman güvenli geçiş yöntemi değildir. Uygulamanın gereksinimlerine uygun backup/restore, replikasyon veya alternatif geçiş yaklaşımı planlanmalıdır.
Önce işletim sistemi, SQL sürümü, veritabanı uyumluluk seviyesi, SQL Agent işleri, linked server tanımları, login ve yetkiler, bağlantı dizeleri, sertifikalar ve uygulama bağımlılıkları envanterlenmelidir. Kaynak ve hedef SQL sürümleri ile desteklenen geri yükleme yönü doğrulanmadan taşıma taahhüdü verilmemelidir.
Geçiş için hazırlık testi, bakım penceresi, son veri eşitlemesi, uygulama kabul testi ve geri dönüş planı gerekir. Eski sunucuyu ilk başarılı bağlantıdan hemen sonra silmek yerine veri tutarlılığı ve yedek zincirini doğrulayın.
12. SQL Server sunucu kiralama teklifinde hangi kalemler bulunmalı?
Teklif karşılaştırması için aynı teknik gereksinim belgesini bütün sağlayıcılara gönderin. Aşağıdaki tablo satın alma ekibinin kapsam farklarını açıkça görmesi içindir; sabit paket veya fiyat listesi değildir.
| Teklif kalemi | Yazılı olarak istenecek bilgi |
|---|---|
| İşlemci | vCPU/çekirdek, fiziksel işlemci sınıfı, tahsis politikası |
| Bellek | RAM, büyütme seçeneği, SQL instance başına plan |
| Depolama | Kullanılabilir GB/TB, veri/log/tempdb ayrımı, IOPS ve gecikme |
| SQL lisansı | Sürüm, edition, core/CAL koşulları, kiralama modelindeki haklar |
| Windows lisansı | Lisans kapsamı, güncelleme ve bakım sorumluluğu |
| Güvenlik | Firewall, VPN, erişim kontrolü, izleme ve kayıt |
| Yedekleme | Full/diff/log planı, saklama, uzak kopya, geri yükleme testi |
| Operasyon | SQL ve Windows yama, kapasite raporu, olay müdahalesi |
| Taşıma | Uygulama testi, veri transferi, kesinti ve geri dönüş |
| Sözleşme | SLA, fiyat değişiklikleri, veri teslimi ve çıkış masrafları |
12 aylık örnek karşılaştırma yaklaşımı: 12 × (aylık sunucu + lisans + yedekleme + yönetim) + kurulum/taşıma + öngörülen ek giderler. Bu yalnız maliyet kategorilerini gösterir; gerçek hizmet fiyatı değildir. Vergi, kur artışı ve sözleşme hükümleri ayrıca hesaba katılmalıdır. Sunucu fiyatlandırma yaklaşımını inceleyerek aynı kapsam için teklif karşılaştırabilirsiniz.
13. Teknik keşif talebine hangi bilgileri eklemeliyim?
Kurumunuzun SQL Server sürümü ve edition bilgisi, toplam veritabanı boyutu, son üç aydaki büyüme, eşzamanlı kullanıcı sayısı, uygulama ve ERP sürümleri, işlemci/RAM kullanım aralığı, mevcut disk gecikmeleri, bakım penceresi ve kurtarma hedefleri iyi bir başlangıçtır.
Uygulama yöneticisinin bağlantı gereksinimleri, sunucuya uzaktan erişen şubeler, IPsec VPN ihtiyacı, veritabanı yedek politikasının bugünkü durumu ve veri lokasyonu koşulları da verilmelidir. Şifre, tam veritabanı dökümü veya kişisel müşteri verileri genel teklif formuna gönderilmemelidir; gerekiyorsa güvenli yetkilendirilmiş kanal kullanılmalıdır.
Netsun Bilişim ile SQL Server altyapı keşfi: Önce uygulama bağımlılıklarını ve performans sorunlarını analiz edin; sonra yönetilen sunucu hizmetleri dahil ya da hariç seçeneklerin kapsamını yazılı karşılaştırın. SQL Server sunucu kiralama teklifi için ihtiyaçlarınızı iletin; CPU, RAM ve disk kadar lisans, güvenlik, yedekleme ve taşıma sorumluluklarını da netleştirin.
Resmî teknik kaynaklar
Bu rehberin teknik açıklamalarını doğrulamak için Microsoft SQL Server bellek ayarları, SQL Server 2025 edition karşılaştırması, Query Store izlemesi, SQL yedekleme ve geri yükleme ve Microsoft SQL Server lisans dokümanları kullanılabilir. Üretici koşulları ve yazılım destek matrisi zamanla değişebileceği için gerçek kurulumdan önce güncel sürüm ve anlaşmaları yeniden kontrol edin.
Sık sorulan sorular
1. SQL Server sunucu kiralama için kaç vCPU ve RAM gerekir?
Sabit bir sayı yoktur. Eşzamanlı kullanıcı, sorgu tipi, veritabanı büyüklüğü, veri değişim hızı, bellek baskısı ve uygulama gereksinimleri ölçülmelidir. Performans testi yapmadan belirli paket garanti edilemez.
2. SQL Server için NVMe SSD şart mı?
Her iş yükü için şart değildir. Yoğun rastgele okuma/yazma ve düşük gecikme ihtiyacında avantaj sağlayabilir; ancak depolamanın gerçek IOPS, latency ve performans izolasyonu ölçülmelidir.
3. SQL Server Standard mı Enterprise mı seçmeliyim?
Uygulamanın ihtiyaç duyduğu özellikler, işlemci/bellek sınırları, yüksek erişilebilirlik hedefi, büyüme ve lisans bütçesi karşılaştırılmalıdır. Ürün sürümüne göre edition özellikleri farklıdır.
4. SQL Server lisansı kiralama ücretine dahil mi?
Sağlayıcıya göre değişir. Windows Server ve SQL Server lisansları ayrı incelenmeli; çekirdek, kullanıcı erişimi, sanallaştırma ve tedarikçi anlaşması koşulları yazılı doğrulanmalıdır.
5. Logo veya Mikro muhasebe SQL Server üzerinde çalışabilir mi?
İlgili uygulamanın belirli sürümü ve üreticisinin desteklediği veritabanı sürümü esas alınmalıdır. Bu nedenle SQL sürümü, ERP sürümü, kullanıcı sayısı ve entegrasyon bağımlılıkları birlikte değerlendirilir.
6. SQL Server yedeklerinde RPO ve RTO nasıl belirlenir?
İşletmenin kabul edilebilir veri kaybı ve kesinti sınırı belirlenir. Sonra recovery model, tam/fark/log yedekleri, ayrı kopyalar ve geri yükleme testleri bu hedefe göre planlanır.
7. SQL Server'ı Azure'dan veya ofisten taşırken kesinti olur mu?
Tam süre ve kesinti, veri hacmi, bağlantı, replikasyon/restore yöntemi, uygulama bağlantıları ve geçiş stratejisine bağlıdır. Pilot test ve geri dönüş planı gerekir.
8. SQL Server sunucu kiralama teklifi nasıl alabilirim?
SQL sürümü, mevcut işlemci/RAM, veri hacmi, uygulama, kullanıcı sayısı, hedef RPO/RTO, lisans ve yönetim beklentilerinizi paylaşın. SQL Server kiralama teklif formunu doldurun ve teknik keşif talep edin.