Microsoft SQL Server 2022 Always ON Database Restore

bakicubuk

2 yıl önce

Merhaba

Peki Nedir SQL Server Always ON :

Microsoft SQL Server Always ON yapısı High Availability ( Yüksek Erişebilirlik ) ve Disaster Recovery ( Felaket Kurtarma ) çözümüdür.

High Availability ( Yüksek Erişebilirlik ) şirket ortamlarınızda bulunan Datacenter ( Veri Merkezi ) üzerinde birden fazla sunucu ile yapılır. Sunuculardan birinin Donanımsal ya da Yazılımsal bir sorun nedeniyle arızalanması durumunda diğer sunucunuzun devreye girmesini sağlayan teknolojidir.

Disaster Recovery ( Felaket Kurtarma ) şirket ortamlarınızda bulunan Datacenter ( Veri Merkezi ) üzerinde oluşabilecek herhangi beklenmedik bir felaket sonucu ( Deprem, Sel, Yangın ) Datacenter ( Veri Merkezi ) tamamen hizmet veremez duruma gelme ihtimaline karşı farklı bir uzak lokasyonda Datacenter ( Veri Merkezi ) kurularak sağlanır. Örneğin Datacenter ( Veri Merkezi ) Istanbul’da ise Disaster Recovery ( Felaket Kurtarma ) olarak İstanbul’da farklı bir lokasyonu ya da Ankara,İzmir gibi uzak ve daha az riskli bir lokasyonu Disaster Recovery ( Felaket Kurtarma ) için tercih edebilirsiniz. Microsoft Azure Cloud ve Amazon Cloud gibi Cloud ( Bulut ) hizmetlerinde Disaster Recovery ( Felaket Kurtarma ) Datacenter ( Veri Merkezi ) olarak yapılandırabilirsiniz.

Microsoft SQL Server Always ON yapısı kurulum ve yapılandırması için ortamınızda Windows Server Failover Cluster yapısı içinde en az iki sunucuya ihtiyac duymakdır.

Availability Group yapısını Synchronous ( Senkron ) olarak yapılandırırsanız Availability Group yapısı içindeki tüm Database ( Veritabanı ) Synchronous ( Senkron ) bir şekilde çalışacaktır. Yani ortamdaki Primary Database ( Veritabanı ) gelen bir istek Secondary Database ( Veritabanı ) işlenmeden kullanıcıya işlem tamamlandı bilgisi iletilmeyecektir. Bu çok yoğun Transaction ( İşlem ) alan Database ( Veritabanı ) biraz performans kaybına neden olabilir. Ama Automatic ( Otomatik ) Failover Synchronous ( Senkron ) Availability Group yapısı yapılabildiği için herhangi bir sorun yaşamazsınız. Sunucularda herhangi bir Donanımsal ya da Yazılımsal bir sorun olması durumunda herhangi bir kesinti yaşanmadan Availability Group yapısı diğer sunucudan Automatic ( Otomatik ) bir şekilde hizmet vermeye devam edecektir.

Availability Group yapısını Asynchronous ( Asenkron ) olarak yapılandırısanız eğer. Primary Database ( Veritabanı ) veritabanına gelen bir istek Secondary Database ( Veritabanı ) işlenmeyi beklemeden direk kullanıcıya işlem tamamlandı bilgisi iletilecektir ve arka tarafta Synchronous ( Senkron ) yapılacaktır. Asynchronous ( Asenkron ) olarak yapılandırılan Availability Group yapısında Secondary Database ( Veritabanı ) yazma işlemi için belli bir süresi yoktur. Buradaki yazma işlemi ortamınızda mevcut Donanım ve Network yapınızın Performansına bağlı olarak değişkenlik gösterebilir.

Availability Group yapısını Automatic ( Otomatik ) ya da Manual ( Manuel ) olarak Failover yapabilirsiniz. Automatic ( Otomatik ) Failover yapabilmek için Availability Group yapısını Synchronous ( Senkron ) olarak yapılandırmanız gerekmektedir. Çok yoğun Transaction ( İşlem ) içeren sistemlerde Availability Group yapısını Synchronous ( Senkron ) ve Automatic ( Otomatik ) olarak yapılandırabiliriz. Index Rebuild ( Dizin Yeniden Oluşturma ) işlemlerinde Performans kaybı daha fazla olduğu için sıkıntı yaşayan yapılarda Index Rebuild ( Dizin Yeniden Oluşturma ) öncesinde Availability Group yapısını Asynchronous ( Asenkron ) olarak yapılandırabilirsiniz.

Automatic ( Otomatik ) Failover işlemi Availability Group yapısını dahil bir Database ( Veritabanı ) oluşan bir hata sonucu gerçekleşmez. Availability Replica seviyesinde gerçekleşir. Availability Group yapısında Database ( Veritabanı ) biri Corrupt ( Bozulma ) olması Transaction Log ( İşlem Logu ) dolmuş, Database ( Veritabanı ) bulunduğu Data dizini dolmuş gibi sebeplerde Automatic ( Otomatik ) Failover işlemi gerçekleşmez.

High Availability ( Yüksek Erişebilirlik ) ve Disaster Recovery ( Felaket Kurtarma ) SQL ServerAlways ON’da nasıl kullanıldığını için örnek vermemiz gerekirse.

Datacenter ( Veri Merkezi ) iki Adet sunucumuz var. Bu iki sunucumuzu Windows Server Failover olarak yapılandırdınız. Bu iki sunucumuz üzerinde SQL Server Always ON yapılandırdınız ve Synchronous ( Senkron ) olarak yapılandırdınız. Bu yapılandırmaya High Availability ( Yüksek Erişebilirlik ) yapılandırması deriz.

Datacenter ( Veri Merkezi ) iki Adet sunucumuz var. Bu iki sunucumuzu Windows Server Failover olarak yapılandırdınız Datacenter ( Veri Merkezi ) bir sıkıntı olma ihtimaline karşı başka bir lokasyonda Datacenter ( Veri Merkezi ) üzerinde bir sunucuz var. Bu sunucuyuda mevcut Windows Server Failover yapınıza dahil ettiniz ve mevcut SQL Server Always ON yapınıza Replica ( Kopya ) olarak yapılandırdınız ve Asynchronous ( Asenkron ) olarak yapılandırdınız. Bu yapılandırmaya Disaster Recovery ( Felaket Kurtarma ) yapılandırması deriz. SQL Server Always ON yapısında aynı Availability Group yapısı içinde birden fazla Secondary yapılandırması yapabilirsiniz.

Daha önceki yazımız da

W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerinde Windows Failover Cluster kurulumu ve yapılandırmasını yapmıştık.

Daha sonraki yazımız da

W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerinde Microsoft SQL Server 2022 kurulumlarını tamamladık.

Daha sonraki yazımız da

Microsoft SQL Server 2022 SQL Always ON yapılandırması öncesinde W22SQL22NOD1 ve W22SQL22NOD2 isimli sunucularımız üzerindeki gerekli yapılandırmayı tamamladık.

Bu yazımız da Microsoft SQL Server 2022 Always ON yapısına Database ( Veritabanı ) Restore işlemini anlatıyor olacağız.

Microsoft SQL Server 2022 Always ON yapısına NIHATCUBUKDB isimli Database ( Veritabanı ) Restore işlemini gerçekleştireceğiz.

W22SQL22NOD1 isimli sunucumuz üzerinde Microsoft SQL Server Management Studio ( SSMS ) konsolunu açıyoruz.

Connect to Server ekranın da Server name bölümüne W22SQL22NOD1 isimli sunucumuzun ismini yazıyoruz.

W22SQL22NOD1 isimli sunucumuz üzerine Microsoft SQL Server 2022 Always ON kurulumu ve yapılandırması için Authentication bölümünü Windows Authentication seçiyoruz ve Connect diyoruz.

W22SQL22NOD1 isimli sunucumuz da Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database seçeneği altında sadece BAKICUBUKDB isimli Database ( Veritabanı ) görüyoruz.

W22SQL22NOD1 isimli sunucumuz da Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database seçeneği üzerinde sağ tuş Restore Database diyerek NIHATCUBUKDB isimli Database ( Veritabanı ) Restore işlemini başlatıyoruz.

Restore Database ekranı geliyor karşımıza.

Restore Database ekranın da Device bölümün de .bak uzantılı Database ( Veritabanı ) NIHATCUBUKDB.bak ( Backup dosyasının ismi farklılık gösterebilir. Burada önemli olan .bak uzantılı olmasıdır. ) isimli Backup dosyasını göstermek için üç noktaya tıklıyoruz.

Select backup devices ekranın da Backup media type bölümünü File ya da URL olarak yapılandırabilirsiniz.

Select backup devices ekranın da Backup media type bölümünü File olarak seçiyoruz ve Add tıklıyoruz.

Locate Database File – W22SQL22NOD1 ekranın da NIHATCUBUKDB.bak isimli .bak uzantılı Backup dosyasını seçiyoruz ve OK diyoruz.

Select backup devices ekranın da Backup media bölümü altına NIHATCUBUKDB.bak isimli .bak uzantılı Backup dosyasının geldiğini görüyoruz. OK diyoruz.

Restore Database ekranın da Database bölümün de NIHATCUBUKDB isimli Database ( Veritabanı ) geldiğini görüyoruz.

Restore plan bölümü altında bulunan Backup sets to restore bölümünde NIHATCUBUKDB isimli Database ( Veritabanı ) bilgilerini görüyoruz.

Restore Database ekranın da Verify Backup Media tıklayarak NIHATCUBUKDB.bak isimli .bak uzantılı Backup dosyasını kontrol ediyoruz.

Restore Database ekranın da Verify Backup Media tıklayarak NIHATCUBUKDB.bak isimli .bak uzantılı Backup dosyasını kontrol ettiğimiz de Backup media verified successfully olarak görüyoruz.

Restore Database ekranın da General menüsün de gerekli yapılandırmayı tamamladıktan sonra Files menüsüne tıklıyoruz.

Restore Database ekranın da Files menüsünde NIHATCUBUKDB isimli Database ( Veritabanı ) hangi dizin altına Restore edileceğini yapılandıracağız.

Restore Database ekranın da Files menüsün de Original File Name bölümün de NIHATCUBUKDB isimli Database ( Veritabanı ) hangi dizin altında Backup alındığını görüyoruz.

Restore Database ekranın da Files menüsün de Restore As bölümün de NIHATCUBUKDB isimli Database ( Veritabanı ) hangi dizin altında Restore yapılacağını görüyoruz.

Restore Database ekranın da Restore database files as seçeneğini seçerek NIHATCUBUKDB isimli Database ( Veritabanı ) hangi dizin altına Restore ( Geri Yükleme ) edileceğini yapılandırıyoruz.

Restore Database ekranın da Restore database files as seçeneğini seçerek Microsoft SQL Server 2022 Always ON yapısındaki F:\DATA ve H:\LOG dizinlerini Restore edilmesi için yapılandırıyoruz.

Restore Database ekranın da Restore database files as seçeneğini seçtiğimiz de Original File Name bölümün de NIHATCUBUKDB isimli Database ( Veritabanı ) hangi dizin altında Backup alındığını görüyoruz.

Restore Database ekranın da Restore database files as seçeneğini seçtiğimiz de Restore As bölümün de NIHATCUBUKDB isimli Database ( Veritabanı ) hangi dizin altında Restore yapılacağını görüyoruz.

Restore Database ekranın da Files menüsün de gerekli yapılandırmayı tamamladıktan sonra Options menüsüne tıklıyoruz.

Restore Database ekranın da Files menüsünde NIHATCUBUK isimli Database ( Veritabanı ) Restore ( Geri Yükleme ) işlemi için ne tür opsiyonların olacağını yapılandırıyoruz.

Overwrite the existing database (WITH REPLACE) : Bu seçeneği seçerek Restore işlemini gerçekleştirdiğiniz de Database ( Veritabanı ) zaten var ise yüklediğiniz Restore dosyasında var olan Database ( Veritabanı ) ezmesini sağlar.

Preverse the replication settings (WITH KEEP_REPLACATION) : Bu seçeneği seçerek Restore dosyasında var olan Replikasyon ayarlarını korunmasını sağlar.

Restrict access to the restored database (WITH RESTRUCTED_USER) : Bu seçeneği seçerek Restore dosyasına erişimi kısıltlar.

Recovery State : Bu seçenekte eğer Restore işlemimiz tek adımlık bir işlemse o zaman Restore With Recovey seçeneği ile devam ediyoruz. Fakat Full Backup’ımızın üzerine Differential Backup ve ya Transaction Log Backup Backupları da yükleyeceksek o zaman son adıma kadar gerçekleştirdiğimiz son Restore işlemine kadar her seferinde Restore With Norecovery seçeneğini seçiyoruz, Bu veritabanımızın Restore modda olduğunu ve işlemin bitmediğini temsil eder ta ki son Log Backup’ları yükleme kısmına geçene kadar son adımda tekrar Restore With Recovery seçeneğinde bırakıp Restore işlemini sonlandırıyoruz ve veritabanımızın son haline ulaşmış oluyoruz.

Tail Log Backup : Bu seçenekte Database ( Veritabanı ) da herhangi bir sorunla karşılaştığımız zaman aldığımız backuplardan geri dönmek isteriz ve ilk olarak Full Backup restore ederiz. Microsoft SQL Server restore işlemine başladığımız zaman bize bu işlem başlatılmadan önce Tail Log Backup alma seçeneği sunar bu da son Log backupımızdan sonra yapılan değişiklikleri kapsayan backup anlamına gelir eğer restore işlemine başlamadan önce son olarak bir Log backup daha alma şansımız olursa o zaman Tail Log Backup’a herhangi bir ihtiyacımız olmaz çünkü zaten Database ( Veritabanı ) son haline kadar tüm kayıtları yedeklemiş oluruz. Restore işlemine başlarken Options kısmında Tail Log Backup seçeneğini tıklarsak Microsoft SQL Server belirttiğimiz klasöre bir log dosyası daha yazar bu aslında Full Backup, Differential Backup ve Transaction Log Backup’larımızın tamamının son adımı anlamına gelir yani restore işlemlerinde en son bu dosyayı yükleyip Database ( Veritabanı ) Recovery moda çekebiliriz.

Restore Database ekranın da gerekli yapılandırmayı tamamladıktan sonra OK diyoruz.

Restore Database ekranın da NIHATCUBUKDB isimli Database ( Veritabanı ) Restore ( Geri Yükleme ) işleminin başarılı bir şekilde tamamlandığını görüyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database bölümü altında NIHATCUBUKDB isimli Database ( Veritabanı ) Restore işleminden sonra W22SQL22NOD1 isimli sunucumuz üzerine geldiğini görüyoruz.

W22SQL22NOD1 isimli sunucumuz üzerinde NIHATCUBUKDB isimli Database ( Veritabanı ) Restore işleminden sonra Microsoft SQL Server 2022 Always ON yapısına dahil etmeden önce NIHATCUBUKDB isimli Database ( Veritabanı ) bir kaç işlemi yapmanız gerekmektedir.

NIHATCUBUKDB isimli bir Database ( Veritabanı ) Microsoft SQL Server 2022 Always ON yapısına dahil edebilmek için Recovery model bölümünün Full olarak yapılandırmamız gerekiyor.

Eğer NIHATCUBUKDB isimli bir Database ( Veritabanı ) Recovery model bölümünü Full yapılandırmazsanız. Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full recovery mode is required hatası alıyoruz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full recovery mode is required tıkladığımız da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) uygun olmadığı bilgisini görüyoruz.

NIHATCUBUKDB isimli bir Database ( Veritabanı ) Microsoft SQL Server 2022 Always ON yapısına dahil edebilmek için Full Backup almamız gerekiyor.

Eğer NIHATCUBUKDB isimli bir Database ( Veritabanı )Full Backup almazsanız. Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full backup is required hatası alırsınız.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Full backup is required tıkladığımız da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) uygun olmadığı bilgisini görüyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database bölümü altında NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde sağ tuş Properties seçeneğine tıklıyoruz.

Database Properties – NIHATCUBUKDB ekranın da Options seçeneğine tıklıyoruz.

Recovery model bölümünü Simple olarak görüyoruz.

ecovery model bölümün de Full, Simple ve Bulk-Logged olarak 3 farklı seçenek bulunmaktadır.

Simple : Simple Recovery modeldeki veritabanlarında tutulan transaction loglar Checkpoint işleminden sonra silinirler. Bu nedenle Simple Recovery modelde transaction logların sürekli büyümesi söz konusu değildir. Fakat burada bir çok kişi tarafından yanlış anlaşılan bir noktaya değinmek istiyorum. Simple Recovery model de dahil olmak üzere tüm recovery modellerde transaction loglar tutulur. Fakat diğerlerinden farklı olarak Simple Recovery modelde transaction loglar checkpoint işleminden sonra otomatik olarak silinirler.

Simple Recovery modelde log yönetimi kolay olmasına rağmen Simple Recovery modelin dezavantajı ise geriye dönük transaction loglar silindiği için transaction logların yedeklenmesi ve dolayısıyla restore işlemleri mümkün değildir. Bu nedenle veri kaybı olaslığı çok büyüktür. Çünkü herhangibir felaket durumunda en iyi ihtimalle bir önceki aldığımız Full veya Differential backup tarihine kadar veritabanımızı restore edebiliriz. Bu nedenle Simple Recovery model Production ortamlarında tercih edilmemelidir.

Full Recovery Model : Full Recovery Modeldeki bir veritabanında yapılan tüm işlemler transaction log dosyasına kaydedilir ve manuel olarak müdahale etmedikce silinmez. Bu nedenle Full Recovery Modeldeki bir veritabanı için belli bir zaman veya işlem öncesine veritabanımızı restore etmek mümkündür. Full Recovery Modelde her işlem transaction loglara yazıldığı için en güvenilir Recovery modeldir. Fakat Full Recovery Modelde transaction logların yönetimi manuel yapıldığını söylemiştik. Bu nedenle belli aralıklar transaction loglar silinmelidir. SQL Serverda transaction logların silinmesi için iki farklı yöntem izleyebiliriz. Birinci yöntem olarak transaction log backup alabiliriz. İkinci yöntem ise veritabanımızın transaction loglarının Shrink edilmesidir.

SQL Server 2005 sonrası sürümlerinde Transaction logların shrink edilmesi için veritabanımızın Recovery modelini önce Simple olarak set edip daha sonra Shrink işlemini bitirdikten sonra Recovery modelimizi tekrar Full olarak set etmeliyiz.

Full Recovery Modelde insert,delete ve update gibi DML işlemlerinin yanında index oluşturma gibi Maintenance işlemleri, bcp veya bulk insert işlemleri de loglandığı için bu tür işlemlerden sonra transaction loglar hem aşırı büyümekte hem de bu işlemler transaction loga yazıldığı için işlemleri de az da olsa yavaşlatmaktadır. Bu nedenle bu tür toplu işlemlerin transaction loga yansıtılmaması için üçüncü recovery mkodelimiz olan Bulk Logged Recovery Modeli kullanmalıyız.

Bulk Logged Recovery Model : Bulk Logged Recovery Modelde Full Recovery modelden farklı olarak bulk işlmeler dışında tüm işlemler loglanırken herhangibir bulk işlem yapıldığında tüm işlem için tek bir kayıt log dosyasına yazılır. Bu gibi durumlarda veritabanımızı herhangibir zamana restore etmek mümkün olmaz. Bulk Logged Recovery Modelde bulk işlemler tek tek transaction log dosyasına yazılmadığı için Full Recovery modele göre bulk işlemler daha hızlı yapılır.

Bulk Logged Recovery Modelde bulk işlem içeren bir zamana veritabanımızı restore etmemiz mümkün olmadığı için bu model de Production ortamları için pek uygun değildir. Fakat Production ortamlarında herhangibir bulk işlem yapmadan önce veritabanımızın transaction log backupını alıp daha sonra recovery modelini Bulk Logged olarak değiştirip bulk işlemimizi yapmak ve daha sonra veritabanımızın recovery modelini tekrar full olarak set etmek tercih edilebilir. Diğer bir değişle Bulk Logged Recovery Model için kalıcı değil ama gecici olarak tercih edilebilecek bir Recovery modeldir demek yanlış olmaz.

Son olarak Bulk Logged Recovery Modelden bahsederken sürekli bulk işlemler diye genellediğimiz işlemlerden bir kaçını şu şekilde sıralayabiliriz. Index oluşturma, Silme, Rebuild, Select Into, bulk insert, bcp ile yapılan işlemler gibi işlemler bulk işlem olarak adlandırılırlar.

Recovery model bölümünü Full olarak seçiyoruz ve OK diyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunda NIHATCUBUKDB isimli Database ( Veritabanı ) Microsoft SQL Server 2022 Always ON yapısına dahil etmeden önce Full Backup alıyoruz.

Eğer Microsoft SQL Server 2022 Always ON yapısına dahil etmeden önce NIHATCUBUKDB isimli Database ( Veritabanı ) Full Backup almazsanız.

NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde sağ tuş Tasks menüsünden Back Up… diyoruz.

Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Back up-to seçeneğine altında direkt olarak Backup dizini gelecektir. Biz Backup alınacak olan dizin yapılandırmasını göstermek istediğimiz için burada herhangi bir yapılandırma görünmemektedir.

Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Back up-to seçeneğinde Disk olarak seçiyoruz.

Eğer daha önce Backup almışsanız Destination bölümünü altında dizin görünecektir. Biz Backup alınacak olan dizin yapılandırmasını göstermek istediğimiz için burada herhangi bir yapılandırma görünmemektedir.

Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Back up-to seçeneğinde Disk ve ya URL olarak seçebilirsiniz.

Back Up Database – NIHATCUBUKDB ekranın da Destination bölümün de Backu up-to seçeneğinde Disk olarak seçiyoruz. Microsoft SQL Server 2022 Always ON yapılandırması sırasında yapılandırmış olduğumuz Disk üzerinde Backup almak için Add diyoruz.

Select Backup Destination ekranın da Destinations on disk bölümü altında File name bölümü altında Backup alınacak dizini görüyoruz.

Select Backup Destination ekranın da Destinations on disk bölümü altında File name bölümünde Backup alınacak dizini yapılandırmak için üç noktaya tıklıyoruz.

Locate Database Files – W22SQL22NOD1 ekranın da Select the file bölümü altında W22SQL22NOD1 isimli sunucumuz üzerinde Backup alabileceğimiz dizinleri görüyoruz.

Selected patch bölümünde Backup alınacak dizini görüyoruz. File of type bölümünde Backup türünü ( .bak, .trn ) olarak görüyoruz. File name bölümüne alınacak Backup için bir isim belirlememiz gerekiyor.

Locate Database Files – W22SQL22NOD1 ekranın da File name bölümüne alınacak Backup için bir isim belirliyoruz ve OK diyoruz.

Select Backup Destination ekranın da Destinations on disk bölümü altında File name bölümü altında Backup alınacak dizini yapılandırdıktan sonra OK diyoruz.

Back Up Database – NIHATCUBUKDB üzerinde Destination bölümün de Backup alınacak dizini yapılandırdık.

BAKICUBUKDB isimli Database ( Veritabanı ) üzerinde Backup işleminin başlatmak için OK diyerek Backup işlemini başlatıyoruz.

NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde Backup işleminin tamamlandı. OK diyerek kapatıyoruz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Meets prerequisities olarak görünüyoruz. Yani artık NIHATCUBUKDB isimli Database ( Veritabanı ) Availability Group yapısına dahil edebiliriz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Status bölümün de Meets prerequisities tıkladığımız da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) uygun olduğu bilgisini görüyoruz.

Microsoft SQL Server 2022 Always ON yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) Recovery model seçeneğini Full olarak yapılandırdık ve NIHATCUBUKDB isimli Database ( Veritabanı ) üzerinde Full Backup aldıktan sonra Microsoft SQL Server 2022 Always ON yapısına dahil ediyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability bölümü altında bulunan Availability Groups üzerinde sağ tuş Add Database tıklıyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolunu üzerinde Always On High Availability bölümü altında bulunan Availability Groups bölümün de BAKICUBUKAO ismi ile yapılandırmış olduğumuz Availability Group yapılandırmasını,

Availability Databases bölümü üzerinde sağ tuş Add Database tıklıyoruz.

Introduction ekranın da Always On High Availability yapısı için gerekli yapılandırma için bilgileri görüyoruz. Next diyerek devam ediyoruz.

Select Databases ekranın da Availability Group dahil edeceğimiz Database ( Veritabanı ) seçmemiz gerekiyor. Daha önce Availability Group yapısına dahil ettiğimiz BAKICUBUK ve MUGECUK isimli Database ( Veritabanı ) Status bölümünde Already part of this availability group olarak görüyoruz. Availability Group yapısına dahil edeceğimiz NIHATCUBUK isimli Database ( Veritabanı ) Status bölümünde Meets prerequisities olarak görünüyor. Eğer Database ( Veritabanı ) üzerinde Full Backup almazsanız Status bölümü Full backup is required olarak görünecektir ve Database ( Veritabanı ) üzerinde Full Backup almadığınız için Availability Group yapısına ekleyemezsiniz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) seçmemiz gerekiyor.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Meets prerequisities olarak görünmesi gerekmektedir.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Full recovery mode is required hatası alırsanız. Database ( Veritabanı ) üzerinde Recovery model seçeneğini Full yapmanız gerekmektedir.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Full backup is required hatası alırsanız. Database ( Veritabanı ) üzerinde Full Backup almadığınız için Availability Group yapısına ekleyemezsiniz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) Status bölümün de Meets prerequisities tıkladığımız da Availability Group yapısına dahil edeceğimiz Database ( Veritabanı ) uygun olduğu bilgisini görüyoruz.

Select Databases ekranın da Availability Group yapısına dahil edeceğimiz NIHATCUBUKDB isimli Database ( Veritabanı ) seçiyoruz ve Next diyerek devam ediyoruz.

Connect to Existing Secondary Replicas ekranın da W22SQL22NOD2 isimli sunucumuzu Secondary olarak yapılandıracağımız için bu sunucularımız üzerine bağlanmamız gerekiyor.

Connect to Existing Secondary Replicas ekranın da Connect diyerek Microsoft SQL Server 2022 Always ON bağlanmak istediğiniz sunucuyu bağlayabilirsiniz. Connect All diyerek Microsoft SQL Server 2022 Always ON yapısındaki bütün sunucularınıza bağlantı sağlayabilirsiniz.

Connect to Existing Secondary Replicas ekranın da W22SQL22NOD2 isimli sunucumuzu Secondary olarak yapılandıracağımız için bu sunucumuz üzerine Connect diyerek bağlanıyoruz.

Connect to Server ekranın da Server name bölümüne W22SQL22NOD2 olarak geliyor ve Connect diyoruz.

Connect to Existing Secondary Replicas ekranın da W19SQL19NOD2 isimli sunucumuzu Secondary olarak yapılandırdık sonra Next diyerek devam ediyoruz.

Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine Database ( Veritabanı ) senkronizasyonun ilk yapılandırmasını nasıl yapılacağını yapılandırdığımız ekrandır.

Automatic seeding : Bu seçenek ile devam edersek eğer Secondary sunucusu üzerine Database ( Veritabanı ) senkronizasyonu için gerekli olan bütün işlemler Automatic ( Otomatik ) olarak gerçekleştirilecektir.

Full database and log backup : Bu seçenek ile devam edersek eğer her Database ( Veritabanı ) Full Backup ve Log Backup dosyalarını yapılandırmış olduğumuz Share ( Paylaşım ) üzerinden alarak Secondary sunucumuz üzerine kendisi aktarır ve bu işlem için sunucularımız üzerindeki Instance’ın SQL Server Servis hesaplarının Write ( Yazma ) ve Read ( Okuma ) yetkisi olan bir Share ( Paylaşım ) istemektedir. Yapılandırdığınız Share ( Paylaşım ) diskinde bulunan Database ( Veritabanı ) Full Backup ve Log Backup sığacağı kadar yer olmalıdır.

Join only : Bu seçenek ile seçtiğimiz her Database ( Veritabanı ) Full Backup ve Log Backup Manuel ( Manuel ) olarak alıp Manuel ( Manuel ) olarak Secondary sunucusuna bu adımı geçmeden önce kopyalamamız gerekir.

Skip initial data synchronization : Bu seçenek ile yine her Database ( Veritabanı ) Full Backup ve Log Backup Manual ( Manuel ) olarak alıp Manual ( Manuel ) olarak Secondary sunucumuz üzerine kopyalamamız gerekir. Ancak Join only seçeneğinden farklı olarak bu işlemi sonra yapabiliriz.

Select Initial Data Synchronization ekranın da Secondary sunucusu üzerine senkronizasyonun otomatik olarak yapılması için Automatic seeding seçeneğini seçiyoruz ve Next diyerek devam ediyoruz.

Validation ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için gerekli kontroller yapılıyor.

NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için bütün adımları Success olarak görüyoruz. Eğer bir sorun varsa Error olarak görürdük ve Previous diyerek geri gidebilirsiniz ve yanlış yaptığınız bir yapılandırma varsa yapılandırmayı düzelttikten sonra Re-run validation diyebilirsiniz.

Validation ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için herhangi bir sorun olmadığı için Next diyerek devam ediyoruz.

Summary ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için gerekli olan yapılandırmanın bir özetini görüyoruz.

Summary ekranın da Finish diyerek NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına dahil etmek için işlemi başlatıyoruz.

Script bölümünde Database ( Veritabanı ) Availability Group yapısına dahil etmek için yapılandırmış olduğunuz yapılandırmayı Script ( Senaryo ) olarak alabilirsiniz.

Results ekranın da NIHATCUBUK isimli Database ( Veritabanı ) Availability Group yapısına başarılı bir dahil edildiğini görüyoruz.

Results ekranın da Close diyerek Add Database to Availability Group Wizard ekranını kapatıyoruz.

Microsoft SQL Server Management Studio ( SSMS ) konsolun da Database seçeneği altında NIHATCUBUKDB isimli Database ( Veritabanı ) geldiğini ve NIHATCUBUKDB (Synchronized) olarak görüyoruz.

Availability Databases bölümü altında NIHATCUBUKDB isimli Database ( Veritabanı ) geldiğini görüyoruz.

Başka bir yazımızda görüşmek dileğiyle….