Merhaba
Bu yazımız da Microsoft SQL Server 2022 Always ON yapısına Database ( Veritabanı ) Attach (Bağlama) ya da Restore (Geri Yükleme) işlemini yaptığınızda alınan Full Recovery Mode Is Required hatasının düzeltmek için yapılması gereken süreci adım adım anlatıyor olacağız.
Daha önceki yazı dizimizde Microsoft SQL Server 2025 Always On Availability Group mimarisini detaylı şekilde kurulumu ve yapılandırmasını anlatmıştık. High Availability (Yüksek Erişebilirlik) ve Disaster Recovery (Felaket Kurtarma) senaryolarını örnek bir mimari üzerinden açıklayacak ve üretim ortamları için gerekli tüm ön koşulları ele almıştık.
Daha önceki yazımızda
W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Windows Server Failover Cluster (WSFC) yapısının kurulum ve yapılandırma adımlarını tamamlamıştık.
Daha sonraki yazımızda
W25SQL25NOD1 ve W25SQL25NOD2 isimli Windows Server 2025 sunucularımız üzerinde Microsoft SQL Server 2025 kurulum ve yapılandırma adımlarını başarıyla tamamlamıştık.
Daha sonraki yazımızda
W25SQL25NOD1 ve W25SQL25NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2025 Always On Availability Group yapılandırması öncesinde, her iki sunucu üzerindeki Microsoft SQL Server 2025 servisleri için gerekli tüm ön yapılandırmaları başarıyla tamamladık.
ve en son yazımızda
Microsoft SQL Server 2025 Always On Availability Group Kurulumu 4
Microsoft SQL Server 2025 SQL Always On Availability Group mimarisinin kurulum ve yapılandırma adımlarını, Availability Group oluşturma sürecini ve dikkat edilmesi gereken teknik noktaları detaylı olarak ele almıştık.
Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz. Always On High Availability bölümü altında yer alan Availability Groups üzerinde sağ tuşa tıklayarak Add Database seçeneğini seçiyoruz.
Bu adım ile Add Database to Availability Group Wizard başlatılır ve veritabanını Availability Group yapısına ekleme sürecine geçilmiş olur.
Add Database to Availability Group Wizard başlatıldığında ilk olarak Introduction ekranı karşımıza gelir.
Introduction ekranıında mevcut bir Availability Group yapısına yeni bir veritabanı ekleme süreci hakkında genel bilgilendirme sunar.
Introduction ekranında bu sihirbazın mevcut Availability Group yapısına bir veya birden fazla availability database eklemek için kullanılacağı belirtilmektedir. Ayrıca veritabanını Availability Group’a ekleyebilmek için izlenecek temel adımlar özetlenir. Bu adımlar arasında; SQL Server instance üzerindeki uygun veritabanının seçilmesi, başlangıç veri senkronizasyon yönteminin belirlenmesi, varsa secondary replica’lara bağlantı sağlanması, doğrulama kontrollerinin yapılması ve son olarak yapılandırma özetinin gözden geçirilmesi yer alır.
Introduction ekranı yalnızca bilgilendirme amaçlıdır ve herhangi bir yapılandırma işlemi içermez. NIHATCUBUKDB isimli Database (Veritabanı) için gerekli tüm ön koşul Full Recovery Mode Is Required hatasının kontrolü için Next seçeneğine tıklayarak Select Databases adımına geçiyoruz.
Select Databases ekranında Availability Group yapısına dahil edeceğimiz Database (Veritabanı)’nı seçmemiz gerekmektedir. Select Databases ekranında SQL Server instance üzerinde bulunan tüm kullanıcı veritabanları listelenir ve her bir veritabanının Availability Group’a uygunluk durumu Status sütununda görüntülenir.
Daha önce Availability Group yapısına dahil ettiğimiz BAKICUBUK isimli Database (Veritabanı) Status bölümünde Already part of this availability group olarak görüyoruz. Bu ifade, ilgili veritabanlarının halihazırda SQL Server Always On Availability Group üyesi olduğunu ve yeniden eklenemeyeceğini gösterir.
Select Databases ekranında Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarı Full olarak yapılandırılmazsa, New Availability Group Wizard içerisinde yer alan Select Databases ekranında Availability Group’a dahil etmek istediğimiz NIHATCUBUKDB isimli Database (Veritabanı)’in Status bölümünde Full recovery mode is required hatasını görürüz. Bu durumda veritabanı Availability Group’a eklenemez.
Bu nedenle, SQL Server Always On Availability Group yapılandırmasına geçmeden önce NIHATCUBUKDB isimli Database (Veritabanı)’in Recovery model ayarının Full olduğunun doğrulanması ve gerekirse bu şekilde yapılandırılması kritik bir adımdır.
Select Databases ekranında NIHATCUBUKDB isimli veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına eklemek istediğimizde, Status sütununda Full recovery mode is required uyarısını görüyoruz. Bu uyarı, ilgili veritabanının Always On mimarisi için gerekli olan ön koşulları sağlamadığını göstermektedir.
SQL Server Always On Availability Group, veritabanları arasındaki senkronizasyonu Transaction Log üzerinden gerçekleştiren bir High Availability (Yüksek Erişilebilirlik) mimarisidir. Bu nedenle, sisteme dahil edilecek tüm veritabanlarının Recovery Model ayarının Full olması zorunludur. Simple veya Bulk-Logged recovery model ile çalışan veritabanları, işlem günlüklerini sürekli ve eksiksiz şekilde tutmadığı için Always On yapısına dahil edilemez.
Ekranda ayrıca açılan uyarı penceresinde, veritabanının Availability Group’a eklenebilmesi için Recovery Model ayarının Full olarak yapılandırılması gerektiği ve bu işlemden sonra mutlaka Full veya Differential Backup alınması gerektiği belirtilmektedir. Bunun yanı sıra, transaction log zincirinin korunabilmesi için düzenli Log Backup planlarının da aktif olması gerekir.
Özetle, NIHATCUBUKDB isimli Database (Veritabanı)’i Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için önce Full Recovery Model yapılandırılmalı, ardından gerekli yedekleme işlemleri tamamlanmalıdır. Bu adımlar gerçekleştirilmeden veritabanı Always On ortamına eklenemez ve Select Databases ekranında seçim yapılamaz.
Microsoft SQL Server Management Studio (SSMS) konsolunda Databases bölümü altında yer alan NIHATCUBUKDB isimli Database (Veritabanı) üzerinde sağ tuşa tıklayarak Properties seçeneğine tıklıyoruz.
Database Properties – NIHATCUBUKDB ekranın geliyor karşımıza.
Database Properties – NIHATCUBUKDB ekranında sol menüde yer alan Options seçeneğine tıklıyoruz.
Database Properties – NIHATCUBUKDB ekranda NIHATCUBUKDB isimli Database (Veritabanı) ait Recovery Model, Auto Close, Auto Shrink, Compatibility Level gibi SQL Server Always On Availability Group yapılandırması açısından kritik olan seçenekleri görüntüleyebilir ve gerekli yapılandırmaları gerçekleştirebiliriz.
Database Properties – NIHATCUBUKDB ekranında Options sekmesine geldiğimizde, Recovery model ayarının Simple olarak yapılandırıldığını görüyoruz.
Ancak NIHATCUBUKDB isimli Database (Veritabanı)’nı Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edebilmek için Recovery model ayarının mutlaka Full olarak yapılandırılması gerekmektedir. Always On mimarisi, transaction log zinciri üzerinden çalıştığı için Simple Recovery Model ile yapılandırılmış veritabanları bu yapıya dahil edilemez.
Bu nedenle, SQL Server Always On Availability Group yapılandırmasına devam edebilmek için Recovery model ayarını Simple’dan Full’a çevirerek gerekli yapılandırmayı yapmamız gerekir.
Recovery model bölümünde Full, Simple ve Bulk-Logged olmak üzere üç farklı seçenek bulunmaktadır. Bu modeller, SQL Server’da transaction log yönetiminin nasıl yapılacağını ve olası bir felaket durumunda verinin ne kadar geri döndürülebileceğini belirler.
Full: Full Recovery Model’de yapılan tüm işlemler transaction log dosyasına eksiksiz olarak kaydedilir ve manuel müdahale edilmedikçe silinmez. Bu sayede veritabanı, istenilen herhangi bir zamana kadar geri döndürülebilir. Bu model, SQL Server’da en güvenilir recovery model olarak kabul edilir ve özellikle SQL Server Always On Availability Group, Log Shipping ve kritik Production sistemleri için zorunludur.
Ancak Full Recovery Model’de transaction log yönetimi manuel yapılır. Bu nedenle transaction log dosyalarının kontrolsüz şekilde büyümemesi için düzenli olarak işlem yapılmalıdır. SQL Server’da transaction log temizliği için iki temel yöntem vardır:
- Transaction Log Backup almak
- Transaction Log Shrink işlemi yapmak
SQL Server 2005 ve sonrası sürümlerde, transaction log shrink işlemi uygulanacaksa, veritabanının Recovery Model’i geçici olarak Simple yapılmalı, shrink işlemi tamamlandıktan sonra tekrar Full olarak ayarlanmalıdır. Full Recovery Model’de INSERT, DELETE, UPDATE gibi DML işlemlerinin yanı sıra; Index oluşturma, Index Rebuild, BCP, Bulk Insert gibi bakım ve toplu işlemler de transaction log’a detaylı şekilde yazılır. Bu durum transaction log dosyasının hızla büyümesine ve işlemlerin bir miktar yavaşlamasına neden olabilir.
Bulk-Logged: Bulk-Logged Recovery Model, Full Recovery Model’e benzer şekilde çalışır; ancak bulk işlemler sırasında önemli bir fark ortaya çıkar. Bulk işlemler esnasında yapılan tüm işlemler tek tek loglanmaz, bunun yerine tek bir kayıt transaction log’a yazılır. Bu sayede bulk işlemler, Full Recovery Model’e kıyasla daha hızlı gerçekleştirilir ve transaction log büyümesi daha kontrollü olur. Ancak bu modelde, bulk işlem yapılan zaman aralığına point-in-time restore yapmak mümkün değildir.
Bu nedenle Bulk-Logged Recovery Model, Production ortamları için kalıcı bir çözüm değildir. Ancak yaygın bir kullanım senaryosu şu şekildedir:
- Bulk işlem öncesinde Transaction Log Backup alınır
- Recovery Model geçici olarak Bulk-Logged yapılır
- Bulk işlem tamamlanır
- Recovery Model tekrar Full olarak ayarlanır
Bu yaklaşım sayesinde hem performans kazanılır hem de veri güvenliği korunur. Bu nedenle Bulk-Logged Recovery Model’i geçici olarak tercih edilen bir recovery model olarak tanımlamak yanlış olmaz.
Simple: Simple Recovery Model’de çalışan veritabanlarında, transaction log kayıtları Checkpoint işlemi sonrasında otomatik olarak temizlenir. Bu nedenle transaction log dosyasının sürekli büyümesi söz konusu değildir ve log yönetimi oldukça kolaydır. Burada sıkça yanlış anlaşılan önemli bir noktaya değinmek gerekir. Simple Recovery Model dahil olmak üzere tüm recovery modellerinde transaction log tutulur. Ancak Simple Recovery Model’de bu loglar, checkpoint işleminden sonra otomatik olarak silinir. Simple Recovery Model’in en büyük dezavantajı, transaction log backup alınamamasıdır. Bu nedenle point-in-time restore (belirli bir zamana geri dönüş) mümkün değildir. Olası bir felaket durumunda, en iyi ihtimalle yalnızca en son alınan Full veya Differential Backup’a kadar geri dönülebilir. Bu da ciddi veri kaybı riskine yol açar.
Bu sebeple Simple Recovery Model, Production ortamlarında kesinlikle önerilmez.
Database Properties – NIHATCUBUKDB ekranında Options sekmesi altında yer alan Recovery model bölümünden Full seçeneğini seçiyoruz.
Database Properties – NIHATCUBUKDB ekranında Options sekmesinde gerekli yapılandırmayı tamamladıktan sonra OK diyerek ayarları kaydediyoruz.
Bu işlem ile NIHATCUBUKDB isimli Database (Veritabanı), Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi için gerekli olan Full Recovery Model ile yapılandırılmış olur.
Microsoft SQL Server Management Studio (SSMS) konsolunda, Databases bölümü altında yer alan NIHATCUBUKDB isimli Database (Veritabanı) üzerinde sağ tuş Tasks menüsüne giriyoruz ve Back Up… seçeneğine tıklıyoruz.
Bu adım ile Microsoft SQL Server 2025 Always On Availability Group yapılandırmasına NIHATCUBUKDB isimli Database (Veritabanı)’ni ekleyebilmek için gerekli olan Full Backup (Tam Yedek) işlemini başlatmış oluyoruz.
Back Up Database – BAKICUBUKDB ekranında Backup Type bölümünü Full olarak seçiyoruz. Ardından Destination alanında yer alan Back up to seçeneğini Disk olarak belirliyoruz. Bu yapılandırma ile veritabanının Full Backup (Tam Yedek) işleminin disk üzerine alınacağını belirtmiş oluyoruz.
Destination bölümünde, yedekleme işleminin gerçekleştirileceği dizinin H:\BACKUP olarak yapılandırıldığını görüyoruz. Bu dizin, Microsoft SQL Server 2025 Always On Availability Group kurulumu sırasında daha önce belirlemiş olduğumuz varsayılan Backup klasörüdür.
Gerekli kontrolleri tamamladıktan sonra, Back Up Database – BAKICUBUKDB ekranında OK seçeneğine tıklayarak Full Backup (Tam Yedek) alma işlemini başlatıyoruz.
BAKICUBUKDB isimli Database (Veritabanı) üzerinde Full Backup (Tam Yedek) işleminin başarıyla tamamlandığını görüyoruz.
Full Backup (Tam Yedek) işlemin sorunsuz şekilde tamamlanmasının ardından OK seçeneğine tıklayarak Back Up Database – BAKICUBUKDB ekranını kapatıyoruz.
Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı) için gerekli tüm ön hazırlıkları tamamladık. Bu kapsamda, veritabanının Recovery Model ayarını Full olarak yapılandırdık ve ardından Full Backup (Tam Yedek) işlemini aldık.
Bu adımların tamamlanmasıyla birlikte NIHATCUBUKDB isimli Database (Veritabanı), artık Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilmeye hazır hale gelmiştir.
Bu işlem için Microsoft SQL Server Management Studio (SSMS) konsolunu açıyoruz. Always On High Availability bölümü altında yer alan Availability Groups üzerinde sağ tuşa tıklayarak Add Database seçeneğini seçiyoruz.
Bu adım ile Add Database to Availability Group Wizard başlatılır ve veritabanını Availability Group yapısına ekleme sürecine geçilmiş olur.
Add Database to Availability Group Wizard başlatıldığında ilk olarak Introduction ekranı karşımıza gelir.
Introduction ekranıında mevcut bir Availability Group yapısına yeni bir veritabanı ekleme süreci hakkında genel bilgilendirme sunar.
Introduction ekranında bu sihirbazın mevcut Availability Group yapısına bir veya birden fazla availability database eklemek için kullanılacağı belirtilmektedir. Ayrıca veritabanını Availability Group’a ekleyebilmek için izlenecek temel adımlar özetlenir. Bu adımlar arasında; SQL Server instance üzerindeki uygun veritabanının seçilmesi, başlangıç veri senkronizasyon yönteminin belirlenmesi, varsa secondary replica’lara bağlantı sağlanması, doğrulama kontrollerinin yapılması ve son olarak yapılandırma özetinin gözden geçirilmesi yer alır.
Introduction ekranı yalnızca bilgilendirme amaçlıdır ve herhangi bir yapılandırma işlemi içermez. NIHATCUBUKDB isimli Database (Veritabanı) için gerekli tüm ön koşullar (Full Recovery Model ve Full Backup) sağlandığı için, bu aşamada Next seçeneğine tıklayarak Select Databases adımına geçebiliriz.
Select Databases ekranında Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database (Veritabanı)’nin Status bölümünde Meets prerequisites ifadesini görüyoruz.
Bu durum, NIHATCUBUKDB isimli Database (Veritabanı) için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli tüm ön koşulların eksiksiz olarak sağlandığını gösterir. Başka bir ifadeyle, Recovery Model ayarı Full olarak yapılandırılmış, Full Backup (Tam Yedek) alınmış ve veritabanı Always On yapısına eklenmeye hazır hale gelmiştir.
Bu aşamadan sonra NIHATCUBUKDB isimli Database (Veritabanı)’ni seçerek Availability Group yapısına güvenle dahil edebilir ve yapılandırma adımlarına sorunsuz şekilde devam edebiliriz.
Add Database to Availability Group Wizard içerisinde yer alan Select Databases ekranında NIHATCUBUKDB isimli Database (Veritabanı)’nin Status bölümünde Meets prerequisites ifadesini görüyoruz.
Bu ifade, NIHATCUBUKDB isimli Database (Veritabanı)’i için Microsoft SQL Server 2025 Always On Availability Group yapısına dahil edilebilmesi adına gerekli olan tüm ön koşulların eksiksiz olarak sağlandığını göstermektedir. Bu kapsamda;
- Recovery Model ayarının Full olarak yapılandırıldığı,
- Veritabanı üzerinde en az bir adet Full Backup (Tam Yedek) alındığı,
- Veritabanının çevrimiçi (Online) ve erişilebilir durumda olduğu,
SQL Server tarafından doğrulanmış olur.
Ekranda açılan bilgilendirme penceresinde de belirtildiği üzere, This database meets the availability-database prerequisites mesajı, veritabanının Availability Group’a eklenmeye hazır olduğunu açıkça ifade etmektedir.
Bu aşamadan sonra NIHATCUBUKDB isimli veritabanını seçerek Next seçeneği ile devam edebilir ve veritabanını Microsoft SQL Server 2025 Always On Availability Group yapısına sorunsuz bir şekilde dahil edebiliriz.
Bu ekran, SQL Server Always On Availability Group yapılandırmasında en kritik eşiklerden biridir ve veritabanının mimariye teknik olarak uygunluğunun SQL Server tarafından onaylandığını gösterir.
Başka bir yazımızda görüşmek dileğiyle…
