12 haftalık SQL Server 2025 serisinin kapanış yazısı. Azure SQL Managed Instance ile on-prem SQL Server 2025’i update policy, feature parity, maliyet, SLA, Managed Instance Link ve Fabric Mirroring açısından karşılaştırıyor; üç workshop ve bir karar matrisiyle bitiriyoruz.

1. Başlıyoruz

Nisan’da başladığımız 12 haftalık SQL Server 2025 serisinin son yazısına geldik. İlk üç hafta vector search‘ün içine girdik, dördüncü hafta optimized locking‘i, beşinci hafta native JSON‘ı konuştuk; altıncı, yedinci ve sekizinci haftalarda execution plan, index stratejisi ve tempdb ile performans avcılığı yaptık; son üç haftada da SQL Injection, Always Encrypted ve Audit + Ledger ile güvenliği sıfırdan kurduk. Bu hafta, o 11 konunun hepsinin üstünde duran bir soruyla kapatıyoruz: bu motoru nerede çalıştıracağız? Bulutta mı, kendi veri merkezimizde mi, yoksa ikisinin arasında bir yerde mi?

Danışmanlık verdiğim yıllar boyunca bu sorunun tek bir cevabı olmadığını gördüm. Regülasyon, ekibin DBA derinliği, mevcut donanımın amortisman durumu, uygulamanın instance seviyesindeki özelliklere ne kadar bağımlı olduğu ve en önemlisi maliyeti kimin, hangi bütçeden ödediği cevabı değiştiriyor. Bu yazıda amacım size ‘buluta geçin’ ya da ‘on-prem’de kalın’ demek değil; Azure SQL Managed Instance (bundan sonra kısaca MI) ile on-prem SQL Server 2025’i aynı kriterlerle yan yana koyup, kendi karar matrisinizi çıkarabileceğiniz kadar somut bilgi vermek.

Bu yazıyı Mayıs’ta ilk yayımladığım hâlinden neredeyse üç kat genişlettim; çünkü o tarihten bu yana bazı önemli şeyler değişti. MI için SQL Server 2025 update policy Mart 2026’da GA oldu, Free MI teklifi netleşti, provisioning süreleri saatlerden dakikalara indi ve Fabric Mirroring’in SQL Server 2025’teki mimarisi tamamen değişti. Bu yazıdaki her rakamı Eylül 2026 itibarıyla Microsoft Learn ve resmi fiyat listelerinden doğruladım; yine de fiyatlar bölgeye ve anlaşmanıza göre değiştiği için kendi hesabınızı Azure Pricing Calculator ile yapmanızı isteyeceğim.

Üç workshop yapacağız. Workshop 1’de Free Azure SQL MI kurup update policy’sini ve engine sürümünü T-SQL ile doğrulayacağız. Workshop 2’de on-prem SQL Server 2025 ile MI arasında Managed Instance Link kurup hibrit bir DR senaryosu çalıştıracağız. Workshop 3’te SQL Server 2025’in yeni Fabric Mirroring mimarisini Azure Arc ve managed identity ile ayağa kaldıracağız. Sonunda 11 haftanın konularını ‘nerede çalışıyor’ tablosunda birleştirip karar matrisini vereceğim.

Kimler için bu yazı? Elinde on-prem SQL Server olan ve ‘buluta taşımalı mıyız’ sorusunu yöneticisine cevaplamak zorunda olan her DBA için; ayrıca Azure SQL Database ile MI arasında kalmış mimarlar ve TCO hesabı yapmak isteyen IT yöneticileri için. Her zamanki gibi terimleri İngilizce bırakıyorum: update policy, failover, lift-and-shift, vCore gibi kelimelerin Türkçe karşılıkları sektörde kullanılmadığı için çeviri yapmak okumayı zorlaştırıyor.

2. Üç Seçenek Bir Masada — Azure SQL Database, Azure SQL MI, SQL Server 2025

Azure SQL ailesinde üç ana ürün var ve karar vermeden önce hangisinin ne olduğunu netleştirmek gerekiyor. Azure SQL Database tek bir database’i birim alan, en cloud-native seçenek. Serverless ve Hyperscale gibi tier’ları var, ama SQL Agent, cross-database query, linked server, CLR gibi instance seviyesindeki özellikler yok; uygulama tek bir database içinde yaşıyorsa ve sıfırdan yazılıyorsa ideal. Azure SQL Managed Instance ise tam bir SQL Server instance’ı: Agent job’larınız, Service Broker’ınız, cross-database sorgularınız, CLR assembly’leriniz olduğu gibi çalışır; üstüne Microsoft OS patch, engine güncelleme, backup ve yüksek erişilebilirliği sizin yerinize yönetir. On-prem’den taşınacak bir uygulama için doğal hedef budur. Üçüncü seçenek SQL Server 2025’in kendisi: kendi donanımınızda, bir Azure VM’de ya da Azure Arc ile Azure’a bağlanmış bir sunucuda; OS, network, trace flag, registry dahil her şeyin kontrolü sizde.

MI tarafında 2025 itibarıyla iki değil üç service tier var ve bunu bilmek karar için önemli. General Purpose, compute ile storage’ı ayıran, veriyi Azure Blob üzerinde tutan ekonomik tier; Business Critical, veriyi yerel SSD’de tutan ve Always On AG teknolojisiyle dört replica çalıştıran, 1-2 ms I/O gecikmeli mission-critical tier. Bunlara Next-gen General Purpose eklendi: Elastic SAN üzerinde çalışan, 128 vCore’a, 32 TB’a ve instance başına 500 database’e kadar çıkan, IOPS’u ayrıca ölçeklendirebildiğiniz ve ‘flexible memory’ ile vCore’dan bağımsız RAM seçebildiğiniz bir GP yükseltmesi. Eski GP’nin 100 database ve 16 TB sınırına takılan müşterilerin büyük kısmı için Next-gen GP artık doğru varsayılan.

Şunu baştan söyleyeyim: MI ile on-prem 2025 arasındaki feature parity tarihte hiç bu kadar yakın olmamıştı. Native JSON, optimized locking, vector tipi, regex fonksiyonları, sp_invoke_external_rest_endpoint, ledger; hepsi iki tarafta da var. ‘Buluta gidersek özellik kaybederiz’ korkusu büyük ölçüde eski hikâye. Kaybettiğiniz şey özellik değil, kontrol; kazandığınız şey de zaman. Kararı bu iki eksende vermek gerekiyor.

3. Update Policy — MI’ın Hangi Motoru Çalıştıracağını Siz Seçiyorsunuz

MI’da on-prem DBA’lerin aşina olmadığı ama en kritik kavram update policy. Bu ayar, instance’ınızın database engine’inin hangi SQL Server sürümüyle hizalanacağını ve yeni özelliklerin hangi hızda geleceğini belirliyor. Üç seçenek var ve Eylül 2026 itibarıyla durum şöyle:

• SQL Server 2022 update policy: hâlâ varsayılan. Engine 16.x ile hizalı, güncellemeler cumulative update mantığıyla gelir, compatibility level 160. Database’i SQL Server 2022’ye restore edebilir, SQL Server 2022 ile iki yönlü MI Link kurabilirsiniz.
• SQL Server 2025 update policy: Mart 2026’da GA oldu. Engine 17.x ile hizalı, compat level 170. On-prem 2025 ile birebir aynı internal format; dolayısıyla SQL Server 2025’e restore ve iki yönlü Link mümkün. Bu serideki konuların tamamı bu policy’de çalışır.
• Always-up-to-date (AUTD): sürekli dağıtım. Yeni engine özellikleri Azure SQL Database’e geldiği anda MI’a da gelir; internal format artık herhangi bir SQL Server sürümüyle hizalı değildir. Bugün AUTD’ye özel iki özellik var: Automatic index compaction ve secondary replica’larda Query Store.

Burada en çok atlanan nokta şu: geçiş tek yönlü. 2022’den 2025’e veya AUTD’ye geçtiğinizde internal database format kalıcı olarak yükselir ve geri dönemezsiniz. Microsoft’un kendi önerisi ‘belirli bir sürüme bağımlılığınız yoksa AUTD kullanın’ yönünde; ben ise biraz daha temkinliyim. AUTD’ye geçtiğiniz anda MI’dan SQL Server’a restore yapma ve MI Link ile on-prem’e geri failover etme yeteneğini kaybediyorsunuz. Yani AUTD, ‘çıkış kapısı olmayan’ bir karar. Regülasyon gereği veriyi on-prem’e geri alabilmeniz gereken bir sektördeyseniz, veya hibrit DR planınız varsa, 2025 update policy’de kalın. Sadece bulutta yaşayacak, en yeni AI ve engine özelliklerini hemen production’a almak isteyen bir uygulama için AUTD doğru tercih.

Pratik bir öneri: farklı ortamlarda farklı policy kullanabilirsiniz. Development instance’ınızı AUTD’de tutup yeni özellikleri erkenden test eder, production’ı 2025 policy’de tutup on-prem ile failover uyumluluğunu korursunuz. Update policy’yi deployment template’lerinize (Bicep/ARM/Terraform) açıkça yazın; varsayılan zamanla değişebilir ve ‘sistem varsayılanına güvenen’ bir template ileride beklenmedik bir instance üretebilir.

Hangi policy’de olduğunuzu T-SQL ile anlamak için serverproperty yeterli. ProductUpdateType değeri CU dönüyorsa 2022 veya 2025 policy’desiniz, Continuous dönüyorsa AUTD. Workshop 1’de bunu birlikte çalıştıracağız.

4. Feature Parity — Serideki 11 Konu Nerede Çalışıyor?

Bu seride 11 haftada işlediğimiz her konuyu üç sütunda topladım: on-prem SQL Server 2025, MI 2025 update policy ve MI AUTD. Tabloyu Microsoft Learn’deki güncel dokümanlarla satır satır doğruladım.

Tablodan çıkan sonuç net: 2025 update policy’deki MI ile on-prem 2025 arasında engine seviyesinde fark yok denecek kadar az. Farklar iki yerde toplanıyor. Birincisi, PaaS’ın doğası gereği sizin dokunamadığınız katman: tempdb’nin tmpfs’e alınması, Resource Governor ile tempdb kotası gibi OS/dosya sistemi seviyesindeki ayarlar MI’da yok, çünkü o katmanı Microsoft yönetiyor. İkincisi, AUTD’ye özel gelen özellikler: automatic index compaction ve secondary replica’da Query Store bugün sadece AUTD’de. Buna karşılık AUTD’de SQL Server’a restore ve geri failover yok.

Hafta 3’te vector index için PREVIEW_FEATURES database scoped configuration’ı açmıştık; on-prem’de hâlâ öyle. MI’da vector tipi ve fonksiyonlar 2025 policy ile doğrudan geliyor. Hafta 4’teki optimized locking on-prem’de database seviyesinde açtığınız bir ayar; MI’da 2025 policy veya AUTD ile tüm kullanıcı database’lerinde varsayılan olarak açık. Hafta 11’deki ledger digest storage endpoint’i her iki tarafta da var, ama MI’da Azure Storage’a immutable yazmak managed identity ile birkaç tıklık iş; on-prem’de Arc üzerinden managed identity kurmanız gerekiyor.

5. MI’da Olmayanlar — Migration’da Sürpriz Yaşamamak İçin

Feature parity tablosu iyimser bir resim çiziyor, ama migration projelerinde canımızı yakan şeyler genellikle engine özellikleri değil, instance’ın etrafındaki alışkanlıklar oluyor. Aşağıdaki liste, danışmanlık projelerinde ‘assessment’ aşamasında en çok karşıma çıkan kalemler; her birini migration öncesi kontrol listenize koyun.

• FILESTREAM ve FileTable yok. FILESTREAM filegroup’u olan bir backup MI’a restore edilemez; dosyaları Azure Blob’a taşıyıp metadata’yı tabloda tutacak şekilde uygulamayı değiştirmeniz gerekir.
• SSIS, SSRS ve SSAS servis olarak yok. SSIS paketleri Azure Data Factory’deki SSIS Integration Runtime’a, SSRS raporları Power BI paginated report’a veya bir Azure VM’deki Report Server’a taşınır (MI, SSRS katalog database’ini barındırabilir), SSAS için Azure Analysis Services veya Fabric semantic model’e geçilir.
• PolyBase external table yok; Azure Blob’dan BULK INSERT / OPENROWSET var. Linked server sadece SQL Server ailesine ve Synapse’e kurulabilir; Oracle, dosya ya da Analysis Services hedeflenemez.
• Trace flag’ler sınırlı: DBCC TRACEON sadece belirli global flag’lerle çalışır. Registry, sp_configure’ın bazı seçenekleri (remote access, filestream_access_level, allow polybase export) ve xp_cmdshell gibi extended stored procedure’ler yok.
• DBCC CHECKDB’nin REPAIR seçenekleri yok, çünkü database SINGLE_USER moda alınamıyor; corruption şüphesinde Azure Support devreye giriyor.
• CREATE DATABASE’de dosya ve filegroup tanımlayamazsınız; FOR ATTACH ve AS SNAPSHOT OF desteklenmez. Dosya yerleşimini MI kendisi yapar.
• Extended Events’te event_file ve etw_classic_sync target yok; .xel dosyalarını Azure Blob’a yazarsınız.
• Windows Authentication yerine Microsoft Entra ID authentication. Agent job’larını Entra kullanıcıları için düzenlerken kullanıcının doğrudan login’e map edilmesi gerekiyor; grup üyeliği üzerinden gelen yetki job oluşturmaya yetmiyor.
• Instance collation ve time zone deployment sırasında seçilir ve sonradan değiştirilemez. On-prem’de Turkey Standard Time’a ayarlı sunucudan gelen GETDATE() bağımlı kodlar için MI’ı deploy ederken time zone’u seçmeyi unutmayın; varsayılan UTC.
• General Purpose’da In-Memory OLTP yok (Business Critical’da var). NATIVE_COMPILATION kullanan procedure’ler GP’ye taşınamaz.

Bu listenin uzun görünmesine aldanmayın; tipik bir OLTP uygulamasında bunlardan bir-ikisine takılırsınız, çoğunlukla SSRS ve linked server. Azure Arc ile Azure’a bağladığınız bir SQL Server’da ‘Database migration’ paneli bu assessment’ı her hafta sonu otomatik çalıştırıp size hazır bir rapor veriyor; Bölüm 11’de göreceğiz.

6. Maliyet Modellemesi — Lisans, vCore, Storage ve Gizli Kalemler

Maliyet karşılaştırması bu kararın en çok yanlış yapılan kısmı, çünkü iki taraf farklı birimlerle konuşuyor. On-prem’de sermaye harcaması (donanım) ile sürekli gider (lisans, SA, elektrik, personel) karışık; MI’da her şey saatlik vCore ücretine dönüşmüş durumda. Önce rakamları koyalım, sonra eşitleyelim.

SQL Server 2025 lisansı 18 Kasım 2025’ten itibaren volume licensing’de satışta. Liste fiyatları (ABD, tahmini perakende): Enterprise 15.123 USD / 2-core pack, Standard 3.945 USD / 2-core pack, Standard Server + CAL modelinde sunucu 989 USD ve CAL 230 USD. Yıllık subscription seçeneğinde Enterprise 5.434 USD/yıl, Standard 1.418 USD/yıl (yine 2-core pack). Üçüncü bir yol da var: Azure Arc üzerinden pay-as-you-go, Enterprise 274 USD, Standard 73 USD core-ay başına. Software Assurance kalıcı lisansta ayrıca ödenir ve Azure Hybrid Benefit’in ön koşuludur. Bir de güzel haber: SQL Server 2025 ile gelen Standard Developer edition ücretsiz; Standard edition’a taşınacak bir uygulamanın test ortamı için artık Enterprise Developer’ın ‘gizli özellik’ riskini taşımadan ücretsiz bir seçeneğiniz var.

MI tarafında birim vCore-saat. Yaklaşık rakamlarla (Batı Avrupa, pay-as-you-go, lisans dahil): General Purpose 4 vCore ayda 700 USD civarı, 8 vCore 1.400 USD; Business Critical aynı vCore sayısında yaklaşık üç katı, 4 vCore için 2.000 USD civarı. Storage GP’de GB başına yaklaşık 0,115 USD/ay ve 32 GB’lık artışlarla rezerve edersiniz; ilk 32 GB dahildir. Backup storage, rezerve storage’ın %100’üne kadar ücretsiz, üstü GB başına ücretli. Next-gen GP’de IOPS ayrı bir kalem: rezerve storage × 3 kadar IOPS dahil, üstünü ayrıca ödüyorsunuz.

İndirimler işte burada devreye giriyor ve resmi tamamen değiştiriyor. Azure Hybrid Benefit, SA’lı mevcut lisansınızı MI’a taşımanıza izin verir ve lisans bileşenini düşürerek toplamda %55’e kadar tasarruf sağlar. Reserved capacity ile 1 veya 3 yıllık compute taahhüdünde %33’e kadar; ikisi birlikte kullanıldığında Microsoft’un kendi rakamıyla %82’ye kadar. Instance stop/start ile kullanılmadığı saatlerde sadece storage ödersiniz; MI Link ile kurduğunuz pasif DR replica için ‘hybrid failover benefit’ aktifse lisans ücreti hiç ödemezsiniz. Dev/Test subscription’larda ayrıca %55’e kadar indirim var.

Şekil 4’ü gerçek bir teklif olarak değil, kalemlerin ağırlığını göstermek için çizdim. On-prem tarafında insanların genellikle unuttuğu üç kalem var: DBA ve SysAdmin’in patch, backup doğrulama, DR testi için harcadığı saatler; HA/DR için ikinci bir donanım seti ve ikinci lisans; bir de downtime’ın iş maliyeti. Bir müşterimde ‘on-prem ucuz’ diye başlayan hesap, iki yıllık DR tatbikat maliyeti ve yedek sunucunun Enterprise lisansı eklenince MI Business Critical + AHB + 3 yıl reservation’ın üstüne çıkmıştı. Tersini de gördüm: Standard edition’la mutlu, 4 core’luk, yılda bir patch alan küçük bir uygulama için MI’ın en küçük GP instance’ı bile fazlaydı; orası için Azure SQL Database serverless daha mantıklıydı.

TCO hesabını kendi verinizle yapın: Azure Pricing Calculator’a bölgenizi, tier’ı ve vCore’u girin, AHB ve reservation seçeneklerini açıp kapatın; on-prem tarafına donanım amortismanını, DC/hosting kirasını, lisans + SA’yı ve DBA saat maliyetini ekleyin. Üç yıllık toplamları yan yana koyduğunuzda karar genellikle kendiliğinden çıkar.

7. SLA, Yüksek Erişilebilirlik ve DR — Rakamların Arkasındaki Mimari

MI’ın SLA’i her iki tier’da da %99.99; Business Critical’ı zone-redundant kurduğunuzda %99.995’e çıkıyor. Bu rakamlar Microsoft’un finansal taahhüdü, tutmadığında service credit alıyorsunuz. Ama SLA’in arkasındaki mimariyi bilmeden tier seçmek hata olur; çünkü iki tier failover’ı bambaşka yaşıyor.

General Purpose’da compute stateless: SQL engine süreci bir node’da çalışır, data ve log dosyaları Azure Storage’da durur. Bir arıza veya patch anında Service Fabric süreci başka bir node’da başlatır, dosyalar yeniden bağlanır. Veri kaybı yok ama buffer pool sıfırdan dolduğu için birkaç dakika performans düşüşü yaşarsınız; management operasyonlarında instance 2 dakikaya kadar erişilemez olabilir. Business Critical’da ise veri yerel SSD’de ve Always On AG mantığıyla dört replica’da tutulur; failover saniyeler içinde biter, kesinti 20 saniyenin altındadır ve replica’lardan biri ücretsiz read-scale olarak raporlama yükünü üstünüzden alır. Kısacası: GP ‘kesinti küçük, ama hissedilir’, BC ‘kesinti fark edilmez’. Uygulamanızda retry logic yoksa BC’nin bile failover’ını hissedersiniz; bu yüzden hangi tier olursa olsun connection string’de retry ve uygulama katmanında idempotent yeniden deneme şart.

Zone redundancy her iki tier’da (Next-gen GP’de şimdilik preview) replica’ları veya storage’ı üç availability zone’a yayar; bir veri merkezi tamamen düşse bile instance ayakta kalır. Bölgesel felaket için failover group (ikinci bölgede sürekli senkron ikinci MI, sabit listener adresleri) veya geo-restore (geo-redundant backup’tan yeni bölgede restore) kullanılır. On-prem tarafında aynı seviyeye ulaşmak için WSFC, AG, witness, listener, secondary lag monitoring ve düzenli DR tatbikatı gerekir; bunların hepsini önümüzdeki üç hafta Yüksek Erişilebilirlik serisinde adım adım kuracağız.

Bir de arada bir köprü var: Managed Instance Link. On-prem SQL Server 2025 ile MI arasında distributed availability group kurar; primary on-prem’de kalır, MI near real-time secondary olur. Felakette MI’a planlı veya plansız failover yapar, kriz bitince on-prem’e geri dönersiniz. SQL Server 2022 ile de çalışan bu özellik, 2025 + 2025 update policy kombinasyonunda iki yönlü ve online. Workshop 2’nin konusu bu.

8. Workshop 1 — Free Azure SQL MI Kurmak ve Update Policy’yi Doğrulamak

Microsoft’un Free Azure SQL Managed Instance teklifi Mayıs 2025’te GA oldu ve bu yazıdaki her şeyi denemek için yeterli. Kapsamı: subscription başına bir instance, General Purpose veya Next-gen GP, 4 ya da 8 vCore, ayda 720 vCore-saat (4 vCore’da yaklaşık 7,5 gün kesintisiz çalışma, ya da ‘standard workday’ start/stop takvimiyle bütün ay), 64 GB data storage, 100 (GP) veya 500 (Next-gen GP) database, 7 güne kadar backup retention, lisans dahil. Olmayanlar: SLA, zone redundancy, failover group, long-term retention. 12 ay sonunda instance durur; 30 gün içinde paid’e yükseltmezseniz instance ve database’ler silinir. Aylık vCore-saat bittiğinde instance ‘Stopped – Insufficient credit’ durumuna geçer ve bir sonraki ay kendiliğinden başlar.

Ön hazırlık: bir Azure subscription, subscription seviyesinde SQL Managed Instance Contributor rolü ve MI’a delege edilmiş bir subnet. İlk MI’ı bir subnet’e kurmak virtual cluster oluşturduğu için en uzun süren adımdır; Eylül 2026 itibarıyla operasyonların %95’i 30 dakikada bitiyor (zone-redundant kurulumda 4 saate kadar). Aynı subnet’e ikinci instance kurmak çok daha hızlıdır.

Portal yolu: Azure SQL hub’da ‘SQL managed instances’ → Create; Basics’te resource group, ad, bölge; Compute + storage’da ‘Free offer’ seçeneğini işaretleyin (pricing tier alanında ‘Free’ görünür); Networking’de yeni bir VNet/subnet oluşturun; Additional settings sekmesinde ‘SQL engine updates’ altından update policy’yi seçin (Eylül 2026’da sihirbaz SQL Server 2025’i seçili getiriyor; doküman hâlâ 2022’yi varsayılan sayıyor, yani API/CLI/template ile kurarken policy’yi açıkça belirtin), collation ve time zone’u da burada belirleyin. Review + create’te ‘Update policy’ satırını mutlaka kontrol edin.

Aynı işi PowerShell ile yapmak isteyenler için (Cloud Shell’de Az.Sql modülü hazır gelir):

# Free Azure SQL MI — SQL Server 2025 update policy ile
$rg      = 'rg-sql-lab'
$loc     = 'westeurope'
$miName  = 'free-mi-lab'
$cred    = Get-Credential -UserName 'sqladmin' -Message 'MI admin parolasi'
New-AzResourceGroup -Name $rg -Location $loc | Out-Null
# MI'a delege edilmis subnet (VNet'i onceden olusturmus olmalisiniz)
$vnet   = Get-AzVirtualNetwork -Name 'vnet-sql-lab' -ResourceGroupName $rg
$subnet = Get-AzVirtualNetworkSubnetConfig -Name 'snet-mi' -VirtualNetwork $vnet
New-AzSqlInstance -Name $miName -ResourceGroupName $rg -Location $loc `
    -SubnetId $subnet.Id -AdministratorCredential $cred `
    -Edition GeneralPurpose -ComputeGeneration Gen5 -VCore 4 -StorageSizeInGB 64 `
    -DatabaseFormat SqlServer2025 `      # update policy: SqlServer2025 | AlwaysUpToDate
    -PricingModel Freemium `             # free offer
    -LicenseType LicenseIncluded
# Durum kontrolu (Ready gorene kadar bekleyin)
(Get-AzSqlInstance -Name $miName -ResourceGroupName $rg).State

Instance Ready olduğunda SSMS veya VS Code mssql extension ile bağlanın. Adres <miName>.<dnszone>.database.windows.net formatındadır; VNet dışından bağlanıyorsanız ya point-to-site VPN kurun ya da Networking altından public endpoint’i açıp 3342 portunu NSG’de sadece kendi IP’nize izin verecek şekilde kısıtlayın. Bağlandıktan sonra ilk sorgumuz update policy ve engine doğrulaması:

-- Azure SQL MI: hangi update policy, hangi engine?
SELECT
    SERVERPROPERTY('ProductUpdateType')   AS update_policy,   -- CU = 2022/2025 policy, Continuous = AUTD
    SERVERPROPERTY('ProductVersion')      AS product_version, -- 17.x = SQL Server 2025 ile hizali
    SERVERPROPERTY('ProductUpdateLevel')  AS update_level,
    SERVERPROPERTY('EngineEdition')       AS engine_edition,  -- 8 = Azure SQL Managed Instance
    SERVERPROPERTY('Edition')             AS edition,
    compatibility_level                   AS db_compat        -- 170 bekliyoruz
FROM sys.databases WHERE name = 'AppDB';

Şimdi serinin özelliklerini bu instance’da test edebilirsiniz: Hafta 5’teki json tipiyle bir tablo yaratın, Hafta 4’teki optimized locking’in sys.databases.is_optimized_locking_on kolonunda açık geldiğini görün, Hafta 1’deki vector tipini PREVIEW_FEATURES’a gerek kalmadan deneyin. Portal’ın Overview sayfasında ‘Free vCore hours’ sayacını ve ‘Free offer expires in’ alanını görürsünüz; laboratuvar bitince instance’ı Stop edin, kredi yanmasın.

9. Workshop 2 — Managed Instance Link ile Hibrit DR

Senaryo: production on-prem SQL Server 2025’te kalacak (SQLPROD01), MI ise near real-time secondary olarak Azure’da bekleyecek. Felakette MI’a failover yapıp uygulamayı oraya yönlendireceğiz, kriz bitince geri döneceğiz. Aynı kurulum, ‘hazır olduğumuzda cutover’ mantığıyla migration için de kullanılıyor.

Ön koşullar önemli, çünkü hataların çoğu burada çıkıyor: SQL Server 2025 RTM veya üstü (2022’de CU10+), Windows Server üzerinde Always On özelliği açık (Windows 10/11 istemcide AG kurulamadığı için Link de kurulamaz), database FULL recovery model’de ve en az bir full backup alınmış, MI ile on-prem arasında VPN veya ExpressRoute (public endpoint Link trafiği taşımaz), on-prem’den MI’a 5022 portu ve MI’dan on-prem’e mirroring endpoint portu (örnekte 5022) açık. MI’ın update policy’si SQL Server 2025 olmalı; AUTD’deki bir MI’a link kurabilirsiniz ama failover sonrası geri dönemezsiniz.

Link’i SSMS’te New Managed Instance link sihirbazıyla kurmak mümkün (database’e sağ tık → Azure SQL Managed Instance link → New); sihirbaz sertifikaları, endpoint’i, AG ve DAG’ı sizin yerinize oluşturuyor. Ben yine de script yolunu gösteriyorum, çünkü production’da ne olduğunu bilmeden sihirbaza güvenmenizi istemem. Sıra şöyle: on-prem’de master key ve sertifika üret, sertifikanın public key’ini MI’a yükle, MI’ın endpoint sertifikasını ve Azure root CA’lerini on-prem’e al, mirroring endpoint’i sertifika ile kur, AG ve distributed AG yarat, son olarak MI’ı Azure tarafından DAG’a katıl.

-- 1) On-prem SQL Server 2025 (master): master key + endpoint sertifikasi
USE master;
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong-password>';
GO
DECLARE @cert NVARCHAR(MAX) = N'Cert_' + @@SERVERNAME + N'_endpoint';
DECLARE @sql  NVARCHAR(MAX) =
    N'CREATE CERTIFICATE [' + @cert + N'] WITH SUBJECT = ''MI link endpoint'', EXPIRY_DATE = ''2027-09-30''';
IF NOT EXISTS (SELECT 1 FROM sys.certificates WHERE name = @cert) EXEC sp_executesql @sql;
-- Public key'i al: bu degeri Azure tarafina yukleyecegiz
SELECT @cert AS cert_name, CERTENCODED(CERT_ID(@cert)) AS public_key;
GO

# 2) Azure Cloud Shell (PowerShell): on-prem sertifikasini MI'a tanit, MI sertifikasini al
$mi = 'mi-dr-westeu'
$rg = (Get-AzSqlInstance -InstanceName $mi).ResourceGroupName
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $rg -InstanceName $mi `
    -Name 'Cert_SQLPROD01_endpoint' -PublicKey '<0x... on-prem public_key>'
# MI'in mirroring endpoint sertifikasi (PublicKey alanini kopyalayin)
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $rg -InstanceName $mi `
    -EndpointType 'DATABASE_MIRRORING' | Out-String

-- 3) On-prem: MI sertifikasi + Azure root CA'ler (DigiCert Global Root G2, Microsoft RSA Root CA 2017 ...)
USE master;
CREATE CERTIFICATE [mi-dr-westeu.a1b2c3d4e5f6.database.windows.net]   -- ad = MI FQDN olmak ZORUNDA
    FROM BINARY = <0x... MI public key>;
CREATE CERTIFICATE [DigiCert Global Root G2] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt';
DECLARE @id INT = CERT_ID('DigiCert Global Root G2');
EXEC sp_certificate_add_issuer @id, N'*.database.windows.net';
-- Ayni adimi listedeki diger root CA'ler icin tekrarlayin (uzun sureli link icin 7'sini de ekleyin)
GO
-- 4) Mirroring endpoint (varsa ALTER ile CERTIFICATE auth ekleyin)
CREATE ENDPOINT database_mirroring_endpoint
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE [Cert_SQLPROD01_endpoint],
        ENCRYPTION = REQUIRED ALGORITHM AES);
GO
-- 5) AG + distributed AG (database FULL recovery + full backup alinmis olmali)
CREATE AVAILABILITY GROUP [AG_AppDB]
WITH (CLUSTER_TYPE = NONE)
FOR DATABASE [AppDB]
REPLICA ON N'SQLPROD01' WITH (
    ENDPOINT_URL = 'TCP://10.10.1.21:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL,
    SEEDING_MODE = AUTOMATIC);
GO
CREATE AVAILABILITY GROUP [DAG_AppDB_MI]
WITH (DISTRIBUTED)
AVAILABILITY GROUP ON
    N'AG_AppDB' WITH (
        LISTENER_URL = 'TCP://10.10.1.21:5022',
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC, SESSION_TIMEOUT = 20),
    N'AG_AppDB_MI' WITH (
        LISTENER_URL = 'tcp://mi-dr-westeu.a1b2c3d4e5f6.database.windows.net:5022;Server=[mi-dr-westeu]',
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC);
GO

# 6) Azure Cloud Shell: MI'i distributed AG'ye katil (link olusur)
New-AzSqlInstanceLink -ResourceGroupName $rg -InstanceName $mi -Name 'DAG_AppDB_MI' `
    -PrimaryAvailabilityGroupName 'AG_AppDB' -SecondaryAvailabilityGroupName 'AG_AppDB_MI' `
    -TargetDatabase 'AppDB' -SourceEndpoint 'TCP://10.10.1.21:5022'

Link kurulduktan sonra seeding başlar; database boyutuna ve hat kapasitesine göre dakikalar veya saatler sürer. Sağlığı on-prem tarafından DMV’lerle izliyoruz. Aşağıdaki sorgu hem AG’yi hem DAG’ı gösterir; MI tarafındaki replica SYNCHRONIZING görünüyorsa ve log_send_queue küçülüyorsa her şey yolunda demektir.

-- Run on SQL Server 2025 (primary): Link'in sagligi ve replication lag
SELECT
    ag.name                                   AS ag_name,
    ar.replica_server_name                    AS replica,
    ars.role_desc                             AS role,
    ars.connected_state_desc                  AS connected,
    drs.synchronization_state_desc            AS sync_state,
    drs.log_send_queue_size                   AS log_send_queue_kb,
    drs.redo_queue_size                       AS redo_queue_kb,
    DATEDIFF(SECOND, drs.last_commit_time, GETUTCDATE()) AS lag_seconds
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar  ON drs.replica_id = ar.replica_id
JOIN sys.availability_groups ag    ON ar.group_id = ag.group_id
JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id;

DR tatbikatı için planlı failover kullanın: primary’deki bağlantıları kesin, Azure portal’da MI → Managed Instance link → Failover (veya Invoke-AzSqlInstanceLinkFailover) ile MI’ı primary yapın, uygulamanın connection string’ini MI FQDN’ine çevirin, yazma testlerini yapın, sonra aynı yoldan on-prem’e failback edin. Planlı failover veri kaybı yaratmaz; bu yüzden tatbikatı production’da yapabilirsiniz. Plansız (felaket) failover’da ise async commit olduğu için son birkaç saniyelik veri kaybı olabilir; RPO’nuzu buna göre yazın.

Maliyet notu: MI’ı sadece DR replica olarak kullanıyorsanız Compute + storage sayfasında ‘Hybrid failover rights’ seçeneğini açın; pasif replica için SQL lisans ücreti kalkar, sadece compute ve storage ödersiniz. Sertifikaların expiry tarihini takvime yazın; süresi dolan sertifika link’i sessizce düşürür.

10. Workshop 3 — Fabric Mirroring: SQL Server 2025’te Yeni Mimari

Fabric Mirroring, on-prem operational database’inizi Microsoft Fabric’in OneLake’ine sürekli ve zero-ETL olarak kopyalıyor; analytics ekibi Power BI, Spark notebook ve Warehouse ile Delta Parquet üzerinde çalışırken OLTP sunucunuza raporlama yükü binmiyor. SQL Server 2016-2022’de bu iş CDC üzerinden ve SQL Agent’a bağımlı çalışıyordu; SQL Server 2025’te mimari değişti. Artık engine’in içindeki ‘change feed’ log’u okuyor, CDC’ye ve Agent’a ihtiyaç yok, veri doğrudan SQL Server’dan OneLake’e outbound HTTPS ile gidiyor ve kimlik doğrulama Azure Arc’ın managed identity’siyle yapılıyor. On-premises data gateway hâlâ gerekli, ama rolü veri taşımak değil kontrol düzlemi. Synapse Link’in 2025’te kaldırıldığını da not edin; Microsoft’un yolu artık burası.

Ön koşullar: aktif bir Fabric capacity (trial olur), tenant ayarlarında ‘Service principals can use Fabric APIs’ ve ‘Users can access data stored in OneLake with apps external to Fabric’ açık, SQL Server 2025’in Azure Arc’a bağlı ve Azure Extension for SQL Server’ın kurulu olması, sunucu için system-assigned managed identity’nin SQL Server’a tanıtılmış olması, gateway makinesinin SQL Server’a erişebilmesi. Mirror’lanacak database’de CDC veya replication açık olmamalı, delayed durability kapalı olmalı. AG kullanıyorsanız sadece primary mirror’lanır, tüm node’lar Arc’a bağlı olmalı ve her secondary’nin managed identity’sine Fabric workspace’te Contributor verilmeli. FCI, Azure VM üzerindeki SQL 2025 ve Linux henüz desteklenmiyor.

Arc bağlantısı Azure portal’daki ‘Add a server with Azure Arc’ script’iyle yapılıyor; sonrasında SQL Server tarafında managed identity’nin görünüp görünmediğini kontrol edelim ve Fabric’in bağlanacağı login’i en az yetkiyle oluşturalım:

-- master: Arc managed identity SQL Server tarafindan goruluyor mu? (1 satir, System-assigned bekliyoruz)
USE master;
SELECT identity_type, client_id, tenant_id FROM sys.dm_server_managed_identities;
-- Fabric'in kullanacagi login (Entra login onerilir; SQL auth da olur)
CREATE LOGIN [fabric_login] WITH PASSWORD = '<strong-password>';
GO
-- Mirror'lanacak database'de kullanici + minimum yetki (SQL Server 2025)
USE AppDB;
CREATE USER [fabric_user] FOR LOGIN [fabric_login];
GRANT SELECT, ALTER ANY EXTERNAL MIRROR,
      VIEW DATABASE PERFORMANCE STATE, VIEW DATABASE SECURITY STATE TO [fabric_user];
GO

Fabric tarafında: workspace’te Create → Mirrored SQL Server database → database adını girin → New connection’da sunucu adı (AG’de listener adı), database, gateway ve authentication’ı seçin, ‘Use encrypted connection’ işaretli olsun → Connect. Tabloların tamamını ya da seçtiklerinizi mirror’layın; managed identity’ye ‘Read and write’ izni otomatik verilir (bunun için workspace’te member veya admin olmanız gerekir, contributor yetmez).

Mirroring başladıktan sonra initial snapshot ve ardından sürekli change feed akar. Durumu iki yerden izleyin: Fabric’te mirrored database’in Monitor replication sayfası ve SQL Server tarafında change feed DMV’leri.

-- AppDB: change feed akiyor mu? Son 3 log scan oturumu
SELECT TOP (3) session_id, start_time, end_time, transaction_count, command_count, latency
FROM sys.dm_change_feed_log_scan_sessions ORDER BY session_id DESC;
-- Sorun varsa sirasiyla:
SELECT * FROM sys.dm_change_feed_errors;   -- hata var mi?
EXEC sp_help_change_feed;                  -- tablo bazinda state; 4 disinda bir deger = problem

İki pratik uyarı. Birincisi, change feed log’u okuduğu için transaction log ‘REPLICATION’ log reuse wait’iyle dolabilir; Fabric’in ‘automatic reseed’ özelliğini açın ve log büyümesini izleyin. İkincisi, SQL Server 2025’te mirroring iş yükünü Resource Governor ile bir pool’a hapsedebiliyorsunuz; Hafta 8’de tempdb için kullandığımız aynı mekanizma burada da production sorgularını korumak için var. Bir de küçük gotcha: workspace’i silerseniz mirroring durur ama SQL Server tarafında change feed açık kalabilir; sp_change_feed_disable_db ile kapatmayı unutmayın.

11. Migration Yolları — Boyuta ve Downtime’a Göre Seçim

Buluta gitmeye karar verdiyseniz sıradaki soru ‘nasıl’. Cevap database boyutuna ve kabul edebileceğiniz downtime’a göre değişiyor; Şekil 17 bunu iki eksende özetliyor.

Küçük ve downtime’a toleranslı database’lerde en basit yol BACPAC (sqlpackage export/import); şema ve veri gider, ama büyük tablolarda yavaştır. Orta boy için native backup: BACKUP TO URL ile .bak dosyasını Azure Blob’a yazıp MI’da RESTORE FROM URL çalıştırırsınız; MI .bak’ı doğrudan Blob’dan restore edebilen tek PaaS servisi ve bu yüzden lift-and-shift’in omurgası. Downtime’ı dakikalara indirmek istiyorsanız Log Replay Service (LRS) veya Azure DMS: full backup’ı ve ardından log backup’ları Blob’a atmaya devam edersiniz, MI arka planda restore eder, cutover anında son tail-log backup’ı alıp tamamlarsınız. Sıfıra yakın downtime ve terabaytlık database’ler için tek gerçekçi yol Workshop 2’deki Managed Instance Link: sürekli senkron, planlı failover ile saniyeler içinde cutover.

2026’da bu yolların hepsi Azure Arc’a bağlı bir SQL Server’ın portal sayfasındaki ‘Database migration’ panelinde toplanmış durumda: Assess source instance (her hafta sonu otomatik assessment ve MI sizing önerisi), Select target (mevcut MI’ı seç ya da yeni yarat), Migrate data (LRS ile ‘log shipping’ ya da Link ile ‘real-time replication’), Monitor and cutover. Link yolunda extension sürümü 1.1.3348.364 ve üstüyle aynı anda 10 database seçebiliyorsunuz; 50 database’lik bir projede bunu beş dalgada bitirmek, tek tek sihirbaz koşturmaktan çok daha hızlı.

Migration’da unutulanlar: login’ler ve Agent job’ları Link ile taşınmaz (dbatools’un Copy-DbaLogin ve Copy-DbaAgentJob komutları burada hayat kurtarır), linked server tanımları yeniden yazılır, collation ve time zone MI’da kurulumda seçildiği için önceden karar verilmelidir, Windows login’leri Entra login’lerine çevrilir. Cutover’dan önce uygulamanın MI’a karşı bir load test’i mutlaka yapılmalı; GP tier’ın I/O gecikmesi on-prem NVMe’den yüksektir ve ‘on-prem’de 200 ms olan rapor MI’da 900 ms’ şikâyetinin nedeni çoğunlukla tier seçimi olur.

12. Karar Matrisi — Hangi Senaryoda Hangi Seçenek?

Danışmanlık projelerinden damıttığım pratik matris aşağıda. Her satır bir senaryo, karşısında önerdiğim seçenek ve kısa gerekçesi var. Satırlar birbirini dışlamıyor; gerçek hayatta ‘production on-prem, DR MI’da, analytics Fabric’te’ gibi kombinasyonlar giderek yaygınlaşıyor ve SQL Server 2025’in MI Link + Fabric Mirroring ikilisi tam da bunu kolaylaştırmak için var.

Matrisi kullanırken sırayla üç soru sorun. Birincisi, veri yurt dışına çıkabilir mi? Cevap hayırsa ve bölgenizde Azure yoksa karar bitmiştir, on-prem’desiniz; ama Fabric Mirroring veya MI Link gibi hibrit köprüler için de hukuk ekibinizle konuşun, çünkü ‘DR kopyası bulutta’ da veri transferi sayılır. İkincisi, uygulama instance seviyesinde neye bağımlı? Agent, cross-DB query, CLR varsa Azure SQL Database elenir, MI kalır. Üçüncüsü, ekibiniz OS’yi yönetmekten değer mi üretiyor, yoksa zaman mı kaybediyor? Patch, backup doğrulama ve DR tatbikatına harcanan saatler bir mühendisin yarısını yiyorsa PaaS’ın fiyatı o saatlerin karşılığıdır.

13. Sınırlar ve Pratik Uyarılar

• Update policy geçişi tek yönlü: 2022 → 2025 → AUTD. AUTD’ye geçtikten sonra SQL Server’a restore ve Link ile geri failover yok.
• Free MI’da SLA yok, zone redundancy ve failover group yok; 12 ay sonunda durur, 30 gün içinde upgrade etmezseniz silinir. Aylık 720 vCore-saat bitince instance kendiliğinden durur.
• MI provisioning artık ~30 dakika, ama zone-redundant kurulum 4 saate kadar; ilk instance’ın subnet’e kurulması en uzun adımdır.
• MI’da collation ve time zone kurulumda seçilir, sonradan değişmez. Varsayılan time zone UTC; DATEADD/GETDATE bağımlı kodları gözden geçirin.
• Public endpoint (3342) ve private endpoint sadece istemci trafiği taşır; MI Link ve failover group için VPN/ExpressRoute şart.
• MI Link’te sertifikaların expiry’si var; süresi dolan sertifika link’i düşürür. Root CA listesi de zamanla değişir, 7’sini birden import edin.
• Fabric Mirroring 2025: CDC açık database mirror’lanamaz, FCI desteklenmez, Azure VM üzerindeki SQL 2025 ve Linux henüz yok. Log reuse için automatic reseed açın.
• GP tier I/O gecikmesi 5-10 ms; on-prem NVMe alışkanlığıyla gelen raporlar yavaşlayabilir. Next-gen GP (3-5 ms) veya BC (1-2 ms) ile test edin.
• Backup storage rezerve storage’ın %100’üne kadar ücretsiz; uzun retention (LTR, 10 yıla kadar) ayrı ücretlidir ve Free MI’da yoktur.
• SQL Server 2025’te Web edition, Express with Advanced Services, MDS, DQS ve Synapse Link kaldırıldı; on-prem’de kalacaksanız bile upgrade planınızı buna göre yapın.

14. 12 Haftanın Kapanışı ve Sırada Ne Var?

Geriye dönüp bakalım. İlk üç hafta vector tipi, embedding üretimi ve DiskANN ile SQL Server’ın içinde semantic search kurduk. Dördüncü hafta optimized locking ile lock sayısının nasıl %90 düştüğünü, beşinci hafta native json tipiyle nvarchar(max) döneminin bittiğini gördük. Altı, yedi ve sekizinci haftalarda execution plan okumayı, index stratejisini ve tempdb’yi; dokuz, on ve on birinci haftalarda SQL Injection savunmasını, Always Encrypted’ı ve Audit + Ledger’ı laboratuvarda çalıştırdık. Bu hafta da bütün bunların nerede çalışacağına karar verdik.

Seriden çıkarmanızı istediğim üç ana fikir var. Birincisi, SQL Server 2025 iç mekaniği köklü şekilde değişmiş bir sürüm; compatibility level 170’e ve yeni özelliklere ezbere geçmeyin, her birini production’a açmadan önce Query Store’la ölçün. İkincisi, MI’ın 2025 update policy’si artık ‘eksik sürüm’ değil, on-prem’in eşiti; karar özellik üzerinden değil kontrol, maliyet ve ekip kapasitesi üzerinden veriliyor. Üçüncüsü, hibrit artık bir uzlaşma değil, bir tasarım seçeneği: MI Link ile DR’ı, Fabric Mirroring ile analytics’i buluta taşıyıp OLTP’yi yerinde bırakmak 2025’in en güçlü mimari kalıplarından biri.

Bir sonraki seriye gelince: bu yazıda ‘on-prem’de HA/DR’ı siz kurarsınız’ dedim ama nasıl kurulacağını göstermedim. Önümüzdeki üç hafta Yüksek Erişilebilirlik serisiyle tam da bunu yapacağız: Hafta 13’te Always On Availability Groups’u WSFC, quorum, listener ve read-only routing ile sıfırdan kuracağız; Hafta 14’te backup ve recovery stratejisini RTO/RPO ve point-in-time restore ile ele alacağız; Hafta 15’te multi-subnet, read-scale replica ve gerçek bir DR tatbikatıyla seriyi kapatacağız. Ardından SQL Server 2025 yeniliklerine Change Event Streaming, Fabric Mirroring’in derinleri ve regex + JSON aggregate fonksiyonlarıyla devam edeceğiz.

12 hafta boyunca okuyup yorum yazdığınız, LinkedIn’de paylaştığınız ve eğitim/danışmanlık için ulaştığınız için teşekkür ederim. Türkçe SQL Server içeriği hâlâ az; bu serinin o boşluğa bir tuğla koyduğunu umuyorum. Cloud kararıyla ilgili kendi senaryonuzu yorumlara yazın: ‘şu regülasyon var, şu kadar database, şu kadar DBA’ diye anlatın, karar matrisine yeni satırlar ekleyip bir sonraki yazıda örneklerle cevaplamaya çalışırım. Kendi ortamınız için birebir değerlendirme isterseniz de SQL Server danışmanlık sayfasından bana ulaşabilirsiniz.

Kendi ortamınız için Azure SQL MI / on-prem / hibrit değerlendirmesi ve migration planı isterseniz SQL Server danışmanlık hizmetimi inceleyebilirsiniz; serinin tüm yazıları SQL Server 2025 rehberi sayfasında.