ÇözümPark'a hoş geldiniz. Oturum Aç | Üye Ol
 
Ana Sayfa Makale Video Forum Resimler Dosyalar Etkinlik Hizmetlerimiz Biz Kimiz

SQL Server

Sql Server 2005 ‘de Ship Transaction Logs Özelliğinin Aktif Hale Getirilmesi ( Log Shipping)

Bu makalemde Sql Server 2005 ‘de Ship Transaction Logs özelliğinin aktif hale getirilmesini göreceğiz. Bu özelliği aktif hale getirmeden once bu özelliğin bize sağlayacağı yararlar hakkında kısa bir bilgi paylaşmak istiyorum.

Biliyorsunuz ki veri kaybı hiç istenmeyen bir olaydır. Özellikle şirketlerin muhasebe birimlerinde bu hiç istenmez. Çünkü muhasebe birimi için veri kaybı geriye dönük işlem demektir.Sistemimizde bulunan muhasebe verilerinin bulunduğu veritabanının yapılan her işlemden sonra yedeğini almamız mümkün değil ( her 5 dk vb.)  ama firma tarafından bizden istenen de veri tabanı üzerinde “0” veri kaybı ise bu özelliği kullanmanızda yarar var. Bu özelliği aktif hale getirdiğimizde hangi veritabanı üzerinde bu özelliği aktif hale getiriyorsak o veritabanının bir kopyası farklı bir pc / sunucuda saklanır ve herhangi bir felaket durumunda bizi büyük bir sıkıntıdan kurtarır. Şimdi bu özelliği aktif hale getirelim.

Bunun için mevcut Sql Server 2005 kurulu sunucu dışında bir pc ya da bir sunucuya ihtiyacımız var. Bu sunucu / pc yi bulduktan sonra ise üzerine Sql Server 2005 kuruyoruz. Bu kısa kurulumdan sonra ise iki sunucu içinde herhangi bir sürücüde birer tane logların kopyalanacağı klasör oluşturuyoruz ve paylaşım izni olarak Everyone  full Control veriyoruz.

 

1.) Sql Server Management Studio açılır ve hangi veritabanı üzerinde bu özellik aktif hale getirilecek ise sağ butona tıklanır Tasks > Ship Transactions Logs seçeneği seçilir,

 

image001

 

2.) Gelen ekranda “ Enable this as a primary database in a log shipping configuration “ seçeneği aktif hale getirilir

 

image002

 

3.) Bu seçenek aktif hale getirildikden sonra Backup Settings butonuna basılır,

 

image003

4.) Gelen ekranda Primary Server için Transaction Log dosyalarının kopyalanacağı klasör bilgileri tanımlanır ve bu kopyalama işlemi ile ilgili herhangi bir zamanla tanımlanmak istenirse Schedule butonuna basılır,

image004

 

5.) Gelen ekranda backup işlemini belirtilen zaman aralıkları ile yapabilme olanağına sahibiz. Bizim amacımız mümkün olduğunca “0” kayıp sağlamak olduğu için Daily Frequency bölümünden Occurs every değerinni tanımlıyoruz. İsterseniz bu bölümü 5 dk / 10 dk işlem yapması için tanımlama yapabilirsiniz , ama Microsoft’un bize sunduğu default değer 15 dk  olduğu için ben bu değeri bozmadan işlemime OK butonu ile onaylayarak devam ediyorum,

 

image005

 

6.) Şimdi sıra geldi Secondary  sunucu bilgilerini tanımlamaya. Bu işlem için ise Ship Transaction Logs ana ekranında  Secondary Databases bölümünde yar alan Add butonuna tıklıyoruz,

 

image006

 

7.) Connect butonuna tıklıyoruz,

 

image007

 

8.) Gelen ekrana sunucu adını ya da ip adresini yazarak Connect butonuna tıklıyoruz,

 

image008

 

9.) Bağlantı kurulduktan sonra gelen ekranda Initianize  Secondary Database sekmesinde Yes generate a full backup of the primary database and restore it into the secondary database seçeneği aktif hale getirilir ve Restore Options butonuna basılır ,

 

image009

 

10.) Buraya Secondary sunucu üzerinde daha önce oluşturulmuş klasör bilgileri tanımlanır ve OK butonu ile onaylanarak çıkılır ,

 

image010

 

11.) Yine Secondary Database Settings bölümünde Copy Files sekmesine geçilerek yine Secondary sunucu üzerinde oluşturulan klasör bilgileri tanımlanır, bu işlemi zamanlandırmak için ise Schedule butonuna basılır ve gerekli zaman ayarları yapılır ,

 

image011

 

12.) Secondary Database Settings bölümünde Restore Transaction Log sekmesine geçilir , Database state when restoring backups  ‘de yer alan Standby mode ve ardından Disconnect users in the database when restoring backups seçenekleri işaretlenir. Daha önceki işlem adımlarından da hatırlarsanız bu işleminde belirli zamanlarda yapılmasını istiyorsanız Schedule butonuna basıyoruz ve gerekli zaman ayarlarını yapıyoruz,

 

image012

 

13.) Gelen ekranda bu örneğimizde yine Micrsosft’un default ayarları dışına çıkmıyoruz ve kopyalanan log dosyalarının her 15 dk restore işlemi yapmasını onaylıyoruz,

 

image013

  

14.) Gerekli tanımlamalar bitti. Şimdi ise ana ekranda ( Database Properties – Muhasebe ) OK butonuna basarak Log Shipping işlemini aktif hale getiriyoruz,

 

image014

 

15.) OK butonuna basarak işlemi başlattığımızda aşağıdaki resimdeki gibi sistem 4 aşamadan geçerek log shipping için yapılan konfigrasyonu kaydedecektir , burada bu 4 aşamadan birinde herhangi bir hata mesajı vermediği için işlemimiz başarılı bir şekilde sonlanıyor,

image015

 

16.) Bu aşamadan sonra ise Secondary olarak tanımladığımız sunucu üzerinde Sql Server Management Studio  yönetim aracına gelerek Database bölümüne bakıyoruz. Aşağıdaki resimde de görüldüğü gibi Primary sunucuda bulunan veritabanını bire bir Secondary sunucuda oluşturduğunu görüyoruz. 

 

image016

 

17.) Yine aynı ekranda iken Sql Server Agent yanında bulunan işaretine tıklıyoruz ve altında sistemin Log shipping işlemi için otomatik olarak oluşturduğu job ‘ları görüyoruz. Bizim için önemli olan bu job ların sorunsuz olarak çalışması. Bu job larda yaşanacak herhangi bir hata da log dosyaları karşı sunucuya kopyalanmayabilir ve data kaybına neden olabilir.

 

image017

 

NOT :  Bu özellik aktif hale getirilirken veritabanının büyüklüğü, iki sunucu arasındaki hat hızı gözönünde bulundurularak Schedule tanımlamaları yapılmalıdır.

Bu sayede bizler için kritik olan veri tabanı sunucumuzu yüksek erişilebilirlik seviyesine çekmiş olduk.

Yorumlar

 

Ugur DEMIR

Eline sağlık.

Ocak 17, 2010 22:58
 

Aykut Sinan ES

Eline SAglik.

Ocak 17, 2010 23:01
 

Cemal Tuncel

Eline sağlık, Haydar hocam

senide MVP olarak görmek dileklerimizle :)

Ocak 18, 2010 09:49
 

Ozgur KOLUKISA

Elinize sağlık

Ocak 18, 2010 21:16
 

KaiN

çok güzel bir makale olmuş klavyenize sağlık

Ocak 19, 2010 00:08
 

mehmet özçifçi

teşekürler elinize sağlık

Ocak 19, 2010 11:44
 

ismail OZER

Güzel bir çalışma, teşekkürler...

İlgili klasör için Everyone  full Control, paylaşım güvenliği açısından problem olmaz mı?

Şubat 10, 2010 19:05
 

Anonymous

Emeğiniz için teşekkürler.

* Hangi SQL Server sürümlerinde ve versiyonlarında bu özelliğin kullanılabildiği,

* Mirroring gibi diğer felaket anı (failover) çözümlerine göre avantaj ve dezavantajları,

* Monitor Server yardımıyla 3'lü transaction log shipping yapısının nasıl kurulacağı,

* felaket anında (failover discovery) geri dönüşün nasıl yapılacağı,

* hangi ölçekte firmaların tercih etmesi gerektiği,

* tercih ederken seçilmesi gereken donanım yapısı,

* ağa ve sisteme getireceği ek yük ile ilgili ayrıntılar

da anlatılsa daha özel ve çok daha keyifle okunan bir makale olurdu. 2. sürümde olması muhteşem olacaktır.

Haziran 1, 2010 15:34
Kimliksiz yorumlar seçilemez kılınmış durumdadır.
 

Hızlı aktarma

Etiketler