SQL SERVER 2008 LOG SHIPPING -2

Merhaba,

Bu yazımda önceki yazımda başladığım SQL Server 2008 de Log Shipping teknolojisini anlatmaya devam edeceğim. Bu yüzden bu yazıyı okumadan önce önceki yazıyı okumanız gerekmektedir.

Bir önceki yazımda Log Shipping konfigürasyonunu yapmış ve başarılı bir şekilde kurulumu tamamlamıştım. Şimdi database lere bakıp log Shipping çalışıyor mu çalışmıyor mu durumu nedir ? Önceki yazıda başlatmış olduğum aşağıdaki örnek data insert scripti yine çalışmaktadır. Böylece sizlere dataların karşı tarafa gittiğini göstereceğim.

Her 1 dakika da bir Transaction Log Backup alınması için Job da schedule düzenlemiştik. Şimdi Log ların atılacağı share dosyasına baktığımızda aşağıdaki gibi log backup ların buraya geldiğini(Resimde Sağ taraftaki kısımda) ve aynı zamanda da Secondary Server da belirttiğimiz yere de(Resimde Sol tarafta) kopyalandığını görüyoruz. Aşağıda Sol taraftaki Resimde TransactionLog_Files dizini Secondary Server da Sağ taraftaki LogShipping_Share dosyası ise Primary Server da bulunan log dosyalarının bulunduğu paylaşımlı dizinimizdir.

Diğer yandan çalışan Backup, Copy ve Restore job larının history sine aşağıdaki gibi bakarak joblarda hata alınıp alınmadığını kontrol ediyoruz.

Primary Database de çalışan Backup Job history:

Secondary database de çalışan Copy ve Restore Job History:

Yukarda job ların history sinden de görüldüğü gibi joblar başarılı bir şekilde çalışıyor. Diğer yandan Log Shipping in durumunu aşağıdaki gibi de kontrol edebilirsiniz. Burada son alınan backup ve secondary server için ise son gerçekleştirilen copy ve Restore job ın tarihini göstermektedir.

Primary Database için alınan durum raporu:

Secondary Database için alınan durum raporu:

Ayrıca bu job ları schedule ederken 15 dakikadan eski dosyaların silinmesini istemiştik. Aşağıda da görüldüğü gibi 15 dakikadan daha eski dosyalar job tarafından silinmektedir.

Şimdi dataların birebir aynısı olup olmadığını görelim. Bunun için üstte başlattığım insert data scripti ni manuel olarak durduruyorum. Bir süre sonra secondary database den aşağıdaki sorguyu çektiğim zaman resimde görülen hatayı alıyorum. Bu hatanın sebebi secondary server o an gelen transaction log backup ı restore aşamasında olduğu için sorguya izin vermiyor. Bunu ilk yazımda Restore job ını schedule ederken Secondary Database ini Standby Mode olarak seçtiğimiz zaman Disconnect users in the database when restoring backups ı işaretlediğim için şuanda bizim sorgumuza cevap vermiyor database…

Bu sorgudan bir süre sonra tekrar aynı sorguyu çektiğim zaman aşağıdaki gibi cevap alıyorum. Tabloda 3404 kayıt olduğunu söylüyor aynı sorguyu primary database ine attığım zaman aynı sayıda kayıt olduğunu görüyoruz.

Secondary(Standby) Database için atılan sorgu ve cevabı:

Primary(Production) Database için atılan sorgu ve cevabı:

Tabloya gelen kayıt sayıları aynı aşağıdaki gibi datalara da baktığımız zaman Primary database ine gelen tüm datalar aynı zamanda Secondary database ine de gelmiş.

Primary(Production) Database için atılan sorgu ve cevabı:

Secondary(Standby) Database için atılan sorgu ve cevabı:

Dataların da aynı data olduğunu gördükten sonra Log Shipping in başarılı bir şekilde çalışmış olduğunu uygulamalı olarakta görmüş olduk. Dataları birebir görebilmek için ya tüm transactionları durdurmak gerekiyor yada Log Shipping i durdurmak gerekiyor. Tüm transactionları durdurmak production veritabanlarında çok yanlış bir davranış olduğundan log Shipping i durdurmak daha mantıklıdır.

Log Shipping le işimiz bitti kaldırmak istiyorsak eğer aşağıdaki gibi kaldırabiliriz.

Log Shipping i kaldırdıktan sonra istenildiği takdirde manuel failover için standby mode da olan Secondary database i normal mode a alıp Uygulamayı buraya bağlayabiliriz.

Aşağıda görüldüğü gibi TestDatabase veritabanı Standby Mode da sadece Read-Only olarak hizmet vermektedir.

Secondary olarak seçtiğimiz bu database eğer primary database herhangi bir sebepten dolayı down olmuşsa yada crash olmuşsa secondary database i aşağıdaki gibi normal mode a çekip direk olarak uygulamayı buraya bağlayabiliriz. Standby mode da olan TestDatabase veritabanımıza son Transaction Log Backup ı RESTORE WITH RECOVERY mode da restore ediyoruz ve aşağıdaki resimde yan da da görüldüğü gibi TestDatabase adlı veritabanımız normal mode a geçmiş oldu.

SQL Server 2008 de Log Shipping konulu yazımı burada tamamlıyorum. Bir sonraki yazı da görüşmek dileğiyle Esen Kalın…

Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi İhtiyacınız var [email protected] adresine mail atarak Bizimle iletişime geçebilirsiniz.

– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri