Log Shipping teknolojisi SQL Server 2000 den belli gelen ve SQL Server 2014 ile devam eden bir teknolojidir. Log Shipping teknolojisi SQL Server da hem High Availability hemde Disaster Recovery çözümü olarak geçerlidir. Bu iki özelligi su sekilde saglamaktadir.

Ana veritabanimizin transaction log larindan belli araliklarla beslenen bir yedek yada ikincil veritabani olasi bir felaket aninda Ana veritabani olarak hemen hizmet verebilmektedir. Ayrica datalarimiz da korundugu için ayni zamanda da Disaster Recovery çözümünü de saglamis oluyor.

Log Shipping in çalisma stratejisini teorik olarak söyle ifade edebiliriz. Production ortaminda bulunan bir veritabanimizin Felaket aninda bir kopyasinin tutulmasini istiyorsak ve felakete ugrayan database in bir an önce data kaybi olmadan yada minimum data kaybiyla tekrar hizmet vermesini istiyorsak Log Shipping teknolojisini kullanmamiz gerekmektedir. Bu teknolojide Production database in belli araliklarla birebir kopyasi farkli bir sunucuda ki instance da tutulur ve bu secondary database dedigimiz database belli araliklarla sürekli olarak Production veritabanindan beslenir. Böylece felaket aninda production database ine erisim yoksa eger direk secondary veritabanimiz ana veritabani olarak kullanima açilabilir.

Genel itibariyle Log Shipping in avantajlari ve dezavantajlarini asagidaki gibi siralayabiliriz.

Avantajlar

1.Hem Disaster Recovery hemde High Availability çözümü sunar.
2.Maliyet açisindan çok ucuz bir teknolojidir. SQL Server 2008 den itibaren express sürümü hariç tüm versiyonlarda bu teknoloji kullanilabilir.
3.Kurulumu ve bakimi kolay bir teknolojidir.
4.Bir veritabani için sinirsiz sayida log ship yapilacak yedek database imkani sunmaktadir. Buda bir uygulamanin downtime süresini en minimuma indirmek için bir imkandir.
5.Standby mode da olan Secondary database hiçbir manuel islem yapmadan read-only modda reporting imkani sunmaktadir.
6.Kullanici hatalarina karsi eski transaction log backuplar ile hatadan dönülebilir.

Dezavantajlar

1.Log Shipping de otomatik failover yok bu durumda failover durumu gerçeklestiginde database admini hemen manuel failover yapmak zorunda.
2.Manuel Failover durumundan dolayi Downtime olasiligi senkron mirroring e göre daha fazladir.
3.Belirlenen schedule araligina bagli olarak ana veritabani down oldugu zaman veri kaybi yasanabilir.

Genel olarak özetleyecek olursak Log Shipping ;