SQL Server Taşıma: Minimum Kesintiyle Geçiş Yöntemleri, Cutover ve Geri Dönüş

Veritabanlarını yeni bir sunucuya kopyalamak, SQL Server taşımanın kolay kısmıdır. Zor kısım; sistem 7/24 çalışırken, veritabanları terabaytlarla ölçülürken ve iş birimi saatlerce değil, yalnızca birkaç dakikalık bir kesintiye izin verdiğinde başlar. O noktada asıl sorular değişir:

• Üretim eski sunucuya yazmaya devam ederken yeni sunucuyu nasıl güncel tutarsınız?
• Geçiş yapmadan önce son transaction’ın hedefe ulaştığını nasıl kanıtlarsınız?
• Kimsenin aynı anda iki sunucuya birden yazmadığından nasıl emin olursunuz?
• Hangi ana kadar geri dönebilirsiniz ve o andan sonra geri dönmenin bedeli nedir?

Bu rehber, verinin büyük kısmını üretim çalışırken taşıyan teknikleri, geçişin (cutover) nasıl yürütüleceğini ve geri dönüşün nasıl planlanacağını anlatıyor. Sürüm kararının kendisi için SQL Server 2025 upgrade rehberimizle başlayın; bu yazı taşıma kısmına daha derinden giriyor.

Teknikle Değil, Kesinti Bütçesiyle Başlayın

Bir taşımadaki ilk karar “backup mı, Always On mu” değildir. İlk karar, uygulamanın ne kadar süre erişilemez olabileceği (geçişin RTO’su) ve varsa ne kadar veri kaybının kabul edilebileceğidir (RPO). Geri kalan her şey bu iki sayıdan çıkar.

8 TB’lık bir veritabanının 15 dakikada geçmesi gerekiyorsa, onu geçiş gecesi kopyalamak imkânsızdır. Verinin büyük kısmı günler önce, üretim çalışırken taşınmalı; kesinti sırasında yalnızca son değişiklikler aktarılmalıdır. Bu yüzden yöntem seçmeden önce iki ölçüm şarttır:

• Veritabanı boyutu ve ağ kapasitesi, ilk kopyanın ne kadar süreceğini belirler.
• Transaction log üretim hızı, hedefin sonrasında yetişip yetişemeyeceğini belirler. Kaynak, ağın ya da hedefin redo kapasitesinin kaldırabileceğinden hızlı log üretiyorsa aradaki fark sürekli büyür.

-- Veritabanı bazında log üretim hızını 60 saniye boyunca ölçün
DECLARE @t1 TABLE (db sysname, bytes bigint);
INSERT @t1 SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Log Bytes Flushed/sec' AND instance_name <> '_Total';

WAITFOR DELAY '00:01:00';

SELECT p.instance_name AS database_name,
       (p.cntr_value - t.bytes) / 60 / 1024 AS avg_log_kb_per_sec
FROM sys.dm_os_performance_counters AS p
JOIN @t1 AS t ON t.db = p.instance_name
WHERE p.counter_name = 'Log Bytes Flushed/sec'
ORDER BY avg_log_kb_per_sec DESC;

Bu ölçümü sakin bir öğleden sonra değil; yoğun saatlerde, ay sonunda ve index bakımı sırasında yapın. Aynı anda CPU, bellek, disk gecikmesi ve kritik sorguların sürelerini de kaydedin; bu baseline olmadan yeni sunucunun gerçekten daha iyi olup olmadığını sonradan söyleyemezsiniz.

Veritabanında Olmayan Her Şeyin Envanterini Çıkarın

Veritabanları seçtiğiniz teknikle taşınır. İlk sabah bozulan şeylerin neredeyse hepsi ise veritabanlarının dışında yaşar. Taşımadan önce listeleyin:

• SID’leriyle birlikte login’ler, sunucu rolleri ve veritabanı kullanıcılarıyla eşleşmeleri
• SQL Server Agent job’ları, zamanlamaları, sahipleri, proxy’ler ve credential’lar
• Linked server’lar, provider’lar ve login eşlemeleri (bkz. linked server rehberimiz)
• SSIS kataloğu, Reporting Services, Database Mail ve bakım planları
• TDE sertifikaları, database master key’ler ve yedek şifreleme sertifikaları
• Service Broker, replication ve CDC yapılandırmaları
• CLR assembly’leri ve xp_cmdshell çağıran her şey
• SQL Server dışında çalışan işler, örneğin Windows Görev Zamanlayıcı görevleri; bunlarla birlikte dosya paylaşımları ve servis hesapları
• Connection string’ler, DNS alias’ları, SPN’ler ve TLS sertifikaları

Kullanıcı veritabanlarının dışında kalan nesnelerin tam tablosu upgrade rehberinde.

Yöntem Seçimi

Tail-Log Backup ile Yedek Zinciri

Bir iki saate kadar kesintiye izin verilen sistemlerin çoğu için bu hâlâ en basit ve en güvenilir yöntemdir. Fikir, neredeyse her şeyi önceden geri yükleyip geçiş gecesine yalnızca son log backup’ı bırakmaktır.

1. Günler önce: hedefe bir full backup’ı WITH NORECOVERY ile geri yükleyin.
2. Tarih yaklaşınca: bir differential ve ardından düzenli log backup’ları, hepsi WITH NORECOVERY ile geri yükleyin; hedef yalnızca birkaç dakika geride kalsın.
3. Geçiş: uygulamayı durdurun, kaynakta NORECOVERY ile bir tail-log backup alın, hedefe geri yükleyin ve veritabanını açın.

-- Kaynakta, geçiş anında: tail-log backup kaynak veritabanını
-- RESTORING durumuna alır; artık kimse yazamaz
BACKUP LOG SalesDB
    TO DISK = N'X:\Migration\SalesDB_tail.trn'
    WITH NORECOVERY, CHECKSUM, INIT;

-- Hedefte: son log'u uygulayın ve veritabanını açın
RESTORE LOG SalesDB
    FROM DISK = N'X:\Migration\SalesDB_tail.trn'
    WITH NORECOVERY, CHECKSUM;
RESTORE DATABASE SalesDB WITH RECOVERY;

NORECOVERY ile alınan tail-log backup iki işi birden görür. Kaynak veritabanı artık değişiklik kabul edemediği için yerleşik bir yazma durdurma mekanizmasıdır. Geri dönüşü de basit tutar: hedef canlıya alınana kadar kaynakta RESTORE DATABASE SalesDB WITH RECOVERY çalıştırmak, eski veritabanını veri kaybı olmadan yeniden açar.

Veritabanını son adıyla geri yükleyin ki geçişten sonra yeniden adlandırma gerekmesin; gerekiyorsa önce veritabanı adını güvenle değiştirme yazımızı okuyun. Dosya konumlarını MOVE ile değiştiriyorsanız mantıksal dosya adlarını tutarlı tutun; uyumsuz dosya metadata’sı Error 5161 hatasının nedenlerinden biridir. RESTORE seçeneklerinin ayrıntısı restore rehberimizde.

Log Shipping

Log shipping aynı zinciri Agent job’larıyla otomatikleştirir: kaynakta log backup alır, kopyalar, hedefte geri yükler. Geçiş son bir log backup’ı bekleyebiliyorsa ve ekip bu teknolojiyi zaten tanıyorsa iyi bir seçimdir. Düşük sürümden yüksek sürüme çalıştığı için yaygın bir upgrade yoludur.

Bir kısıt sık sık sürpriz yaratır: hedef daha yüksek bir sürümde çalışıyorsa, secondary veritabanı STANDBY (salt okunur) modda tutulamaz, çünkü onu salt okunur açmak veritabanını yükseltmeyi gerektirir. Geçişe kadar NORECOVERY durumunda kalır; yani veriyi önceden sorgulayarak doğrulayamazsınız. Doğrulamayı ayrı bir geri yüklenmiş kopya üzerinde planlayın.

Distributed Availability Group

Distributed availability group, her biri kendi cluster’ı ve listener’ı olan iki ayrı availability group’u birbirine bağlar. Kaynak AG’nin primary replica’sı (global primary) log kayıtlarını hedef AG’nin primary replica’sına (forwarder) gönderir; forwarder da bunları kendi secondary’lerine iletir. Üretim kaynağa yazmaya devam ederken hedef, başka bir veri merkezinde, yeni donanımda ya da yeni bir Windows sürümünde bile olsa güncel kalır.

Bu, onu büyük ve kritik veritabanları için en güçlü seçeneklerden biri yapar. Koşullar önemli; tasarımı buna göre kurmadan önce kontrol edin:

• Sürümler: SQL Server 2017 ve sonrası farklı ana sürümleri karıştırabilir. Yazılabilir primary’yi barındıran AG, hedefle aynı ya da daha düşük sürümde olmalıdır. SQL Server 2016 AG kaynak olabilir; SQL Server 2012 ya da 2014 üzerindeki AG’ler hiç katılamaz.
• Edition: Enterprise edition’a göre planlayın. Standard edition yalnızca Azure servislerine bağlanan belirli senaryolarda destekleniyor.
• Kendi listener’ı yok: alttaki her AG’nin listener’ı vardır, distributed AG’nin yoktur. Uygulamalar listener’ı yeniden adlandırarak ya da yeniden oluşturarak, veya hedef AG’nin listener’ına yönlendirilerek taşınır.
• Yalnızca manuel failover ve yalnızca FORCE_FAILOVER_ALLOW_DATA_LOSS ile. Aşağıda anlatıldığı gibi önce senkronize ederseniz veri kaybolmaz.

Daha yüksek bir sürüme taşıma

Hedef AG kaynaktan daha yeni bir SQL Server sürümünde çalışıyorsa, Microsoft birkaç kısıtı belgeliyor:

• Automatic seeding desteklenmez. Seeding modunu MANUAL yapın, global primary’de bir full ve bir log backup alın ve ikisini de forwarder’a WITH NORECOVERY ile geri yükleyin. Aksi halde taşıma 946 hatasıyla başarısız olur.
• Hedef okunamaz; kaynak düşük sürümde olduğu sürece. Secondary AG Partially Healthy, veritabanları da senkron modda bile Synchronizing / In Recovery görünür.
• Geri dönüş (failback) yoktur. Yüksek sürüme failover’dan sonra değişiklikler artık eski AG’ye akmaz; eski AG’yi aynı sürüme yükseltmeden ona geri dönemezsiniz.

Veri kaybı olmadan failover

SQL Server 2022 ve sonrasında distributed AG, failover sırasında veri kaybı olmamasını garanti etmek için tasarlanmış REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ayarını destekliyor. Özet akış:

-- 1. Global primary VE forwarder üzerinde: distributed AG için senkron commit
--    (iki taraftaki yerel AG'ler de senkron commit olmalı)
ALTER AVAILABILITY GROUP [distributedAG] MODIFY AVAILABILITY GROUP ON
    'ag1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    'ag2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

-- 2. synchronization_state_desc = SYNCHRONIZED olana kadar bekleyin, sonra global primary'de:
ALTER AVAILABILITY GROUP [distributedAG] SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

-- 3. Global primary'de: primary rolünü bırakın (distributed AG artık erişilemez)
ALTER AVAILABILITY GROUP [distributedAG] SET (ROLE = SECONDARY);

-- 4. Forwarder'da: rolü devralın
ALTER AVAILABILITY GROUP [distributedAG] FORCE_FAILOVER_ALLOW_DATA_LOSS;

-- 5. Yeni forwarder'da (eski global primary):
ALTER AVAILABILITY GROUP [distributedAG] SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);

SQL Server 2019 ve öncesinde bu ayar distributed AG için kullanılamıyor. Orada global primary’deki tüm transaction’ları durdurur, senkron commit’e geçer ve yalnızca last_hardened_lsn değeri her veritabanı için global primary ile forwarder’da aynı olduğunda failover yaparsınız. Değerler eşleşmiyorsa global primary’ye geri döner ve baştan başlarsınız.

İki tarafın sağlık durumu Management Studio panosunda değil, yalnızca DMV’lerde görünür:

SELECT ag.name AS ag_name, ag.is_distributed,
       ar.replica_server_name AS replica_or_underlying_ag,
       DB_NAME(drs.database_id) AS database_name,
       drs.synchronization_state_desc, drs.synchronization_health_desc,
       drs.log_send_queue_size, drs.redo_queue_size,
       drs.last_hardened_lsn, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups   AS ag ON ag.group_id   = drs.group_id
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
ORDER BY ag.name, database_name;

Senkron commit’e geçmek, her commit’e ağ gidiş-dönüş süresini ekler. Bunun transaction gecikmesine etkisini geçiş gecesi değil, dry run sırasında test edin. SQL Server 2025 ayrıca bir contained availability group’un distributed AG’ye katılmasına izin veriyor; bu yapı login’leri ve Agent job’larını AG’nin kendi sistem veritabanlarında taşır. Buna güvenmeden önce ön koşullarını kontrol edin.

Transactional Replication

Transactional replication, kaynak log’dan commit edilmiş değişiklikleri okur ve bunları sırasıyla bir subscriber’a uygular. Cluster gerektirmez ve yalnızca seçtiğiniz tabloları taşıyabilir; kaynakta availability group yoksa ya da veritabanının yalnızca bir kısmı taşınacaksa işe yarar.

Tam bir veritabanı taşıma yöntemi değildir ve uygun olup olmadığını sınırları belirler:

• Yayınlanan her tablonun primary key’i olmalıdır.
• Kapsam: publication dışındaki tablolar, sunucu düzeyi nesneler, Agent job’ları ve yetkiler taşınmaz.
• Şema değişiklikleri: bazı DDL’ler replike olur ama hepsi değil; taşıma süresince bir şema dondurma (schema freeze) üzerinde anlaşın.
• Sürümler: publisher, distributor ve subscriber kombinasyonu Microsoft’un replication uyumluluk matrisi içinde olmalıdır.
• Distributed AG ile: forwarder replica publisher olarak yapılandırılamaz.
• Subscriber, geçişe kadar uygulama için salt okunur kalmalıdır; orada yapılan bağımsız yazmalar tutarlılığı bozar.

Geçiş anında monitördeki düşük gecikme yeterli değildir. Kaynakta yazmayı durdurun, açık transaction’ların bitmesini bekleyin, sonra bir tracer token gönderin ve subscriber’a ulaştığını doğrulayın:

-- Publisher'da, yayınlanan veritabanında, yazma durdurulduktan sonra
DECLARE @token_id int;
EXEC sys.sp_posttracertoken
     @publication = N'SalesPublication',
     @tracer_token_id = @token_id OUTPUT;

-- Her subscriber için gecikme değeri dolana kadar tekrarlayın
EXEC sys.sp_helptracertokenhistory
     @publication = N'SalesPublication',
     @tracer_id = @token_id;

Henüz ulaşmamış bir token boş gecikme gösterir; bu “bitti” değil, “henüz değil” demektir. Token ancak her subscriber’a ulaştığında, ondan önce yazılan her şeyin de orada olduğunu bilirsiniz.

Üçüncü Parti CDC Araçları

Oracle GoldenGate ya da AWS Database Migration Service gibi araçlar, bir ilk yüklemeyi sürekli değişiklik yakalamayla birleştirir. Asıl olarak platformlar arası taşımalarda ya da verinin yolda filtrelenip dönüştürülmesi gerektiğinde anlamlıdırlar. SQL Server’dan SQL Server’a taşımada ise lisans maliyeti ve işletilecek ikinci bir teknoloji eklerler. Üreticinin sürümünüz için desteklenen veri tipleri ve işlemler listesini kontrol edin; DDL değişiklikleri, veri tipi kapsamı ve kaynaktaki log saklama süresi en sık görülen boşluklardır. Replikasyon gecikmesinin sıfır olacağı hiçbir zaman garanti değildir; bu yüzden geçiş yine bir yazma durdurma ve mutabakat adımı gerektirir.

Geçiş (Cutover) Runbook’u

Runbook yalnızca bir komut listesi değildir. Bir sonraki adıma hangi koşullarda geçileceğini ve kararı kimin vereceğini tanımlar.

1. Keşif ve değerlendirme: envanter, kullanılan sürümler ve özellikler, RTO/RPO, veri boyutu ve log hızı, seçilen yöntem.
2. İlk senkronizasyon: hedef bir kurulum kontrol listesiyle kurulur, seeding ya da ilk yükleme yapılır, senkronizasyon sağlığı günlerce izlenir.
3. Dry run: geri dönüş dahil tüm geçiş, kopyalar üzerinde adım adım ve süresi ölçülerek prova edilir.
4. Devam/vazgeç (go/no-go): senkronizasyon sağlıklı, doğrulama geçti, uygulama sahipleri hazır, geri dönüş sorumlusu belli.
5. Yazma durdurma: uygulamaları durdurun, kaynakta uygulama login’lerini devre dışı bırakın ve açık transaction’ların bitmesini bekleyin.
6. Son senkronizasyon ve kanıt: tail-log geri yüklendi, hardened LSN’ler eşit ya da tracer token ulaştı.
7. Geçiş: hedef yazılabilir, listener ya da DNS alias’ı taşındı, connection string’ler değişti.
8. Kabul: üzerinde anlaşılmış bir süre içinde duman testleri (smoke test) ve iş birimi onayı.

Geri Dönüş: Başlamadan Önce Karar Verin

Ne kadar kolay geri dönebileceğiniz, hangi anda olduğunuza bağlıdır:

• Hedef yazma kabul etmeden önce geri dönmek ucuzdur: geçişi iptal edip kaynağı kullanmaya devam edersiniz. Tail-log yönteminde kaynak veritabanını recover edersiniz; distributed AG’de kaynak zaten olduğu gibi durur.
• Hedef yazma kabul ettikten sonra geri dönmek; o yazmaları kaybetmek, yeniden girmek ya da ayrı bir ters senkronizasyon kurmak demektir. Daha yüksek bir sürüme taşındıktan sonra yedekler eski sürüme geri yüklenemez ve distributed AG geri dönemez.

Devam/vazgeç anında anlaşın, geri dönüşü kimin başlatabileceğini yazın ve dry run’da test edin. Aynı tuzağı sürüm yükseltmeleri için SQL Server 2016 destek sonu rehberimizde de anlatıyoruz.

İlk Yedi Gün

• İlk 24 saat: error log’daki bağlantı hataları ve başarısız login’ler, yeni sunucuda çalışan yedekler, kritik job’lar, blocking.
• İlk 72 saat: Query Store‘da plan regresyonları, log ve tempdb büyümesi, deadlock’lar, entegrasyonlar ve linked server’lar.
• İlk hafta: haftalık job’lar ve raporlar, yeni yedeklerden bir restore testi ve baseline ile karşılaştırma.

Yeni sunucu, eski sunucunun adını devralmak için yeniden adlandırıldıysa @@SERVERNAME değerini kontrol edin; replication, bazı job’lar ve izleme araçları buna dayanır. Sunucu adı değiştikten sonra @@SERVERNAME düzeltme yazımız nasıl yapılacağını gösteriyor. Sistem stabil olana kadar veritabanlarını eski compatibility level’larında tutun, sonra compatibility level rehberimizi izleyerek bilinçli olarak yükseltin.

Aryasoft Bunu Nasıl Yapıyor?

Aryasoft’un kıdemli DBA ekibi yöntemi seçmeden önce log üretimini, veri boyutunu ve ağ kapasitesini ölçer ve veritabanlarının dışında yaşayan her şeyin envanterini çıkarır. Her taşıma, geri dönüş dahil, üretimin kopyaları üzerinde baştan sona prova edilir; geçiş, adı belli bir devam/vazgeç sorumlusuyla yazılı bir runbook’u izler. Geçişten sonra ekip, gerçek iş yükünün ilk haftası boyunca sistemle birlikte kalır.