Forum

SQL Server yedekler...
 
Bildirimler
Hepsini Temizle

SQL Server yedeklerinde hata anından 1 sn önceye dönmek ister misiniz?

14 Yazılar
6 Üyeler
0 Reactions
2,157 Görüntüleme
(@sinankahraman)
Gönderiler: 5224
Illustrious Member
Konu başlatıcı
 

Çoğumuz SQl yedeklerini Haftalık (genelde Pazar Complete Backup) ve Günlük (haftanın diğer günleri Differential Backup) olarak alırız. Peki şöyle bir senaryoda ne yaprsınız;

Günlerden Perşembe ve saat 14:43, muhasebeci arkadaşımız telefonla patronun çok acil bir rapor beklediğini ama kendisinin 1 dk kadar önce hatalı bir giriş yaptığını ve bu girişin raporun seyrini tamamen değiştireceğini ; şayet silme yada değiştirme yapar ise başka değişikliklerde yapması gerektiğini ve işin en az 1 saat tutacağını ama raporun en geç 10 dk içinde patrona ulaştırılması gerektiğini bu yüzden backuptan geri dönmemiz gerektiğini  bildirdi. Böyle bir durumla karşılaşılma ihtimali ne kadardır bilemem ama diyelimki Sistem Yöneticisi olarak size böyle bir talep geldi. Ne yapardı nız? Sanki en mantıklısı muhasebeci arkadaşımızın yaptığı işlemi geri alması ve patrondan ek süre istemesi. Çünkü bizim backup tan geri dönmemiz hem zaman alacak hemde bir önceki güne dönmüş olacağımızdan Perşembe 14:43 e kadar yapılan işlemlerin tekrar yapılması gerekecek.

Aslında izlenecek başka bir yol daha var. Transaction_Log larında günlük hatta gün içerisinde belirli saatlerde yedeğini almak. Bu işlem bize ne kazandıracak? Bir önceki örneğimizde benim elimde Transaction_Loglar var ise yapacağım işlemler şunlar olurdu;

  1. Muhasebeci arkadaşıma sakin olmasını ve tüm bilgisayarlarda muhasebe programını kapatmaları ve 2 adet kahve alıp yanıma gelmesini söylerim.
  2. Ayrı bir yere Complete Backup ve Trasaction_Logların yedeğini alırım
  3. DB üzerinde Restore işlemini başlatır ve son aldığım backup ı gösteririm
  4. Restore Database kısmında Point in time restore kısmını seçerek geriye dönmek istediğim tarihi ve saat-dakika-saniyeyi belirler ve işelemi sonlandırırım.

 

 
Gönderildi : 11/08/2008 13:29

(@rahmidilli)
Gönderiler: 2458
Famed Member
 

Teşekkürler Sinan hocam.

 
Gönderildi : 11/08/2008 15:58

(@haticeakgul)
Gönderiler: 983
Noble Member
 

   Sinan Bey çok güzel özetlemiş buna ek bir önerim.

 Elinizdeki  Complete Backup a dönmeniz ve Differential Backup backup la birleştirmenizde zaman alacaktır.

  Genelikle bilgi akışı yoğun firmalarda teknik altyapı yeterliyse Database Mirroring yapmalarını  tavsiye ediyoruz bu şekilde elinizde hep bir önceki haliyle elinizde hazırda olacaktır.

 Yedekleri sadece son hafta açısından bakmayıp resmi muhasebe tutuluyorsa ay sonu işlemleri yapıldıktan sonrasında alınıp her ayı ayrıca saklanmanızı da tavsiye ederim.

 

Yedeklerinizi belli aralıklarda farklı isimlerde restore edip güvenirliğini kontrol etmeyi unutmayın.

iyi çalışmalar.

iyi çalışmalar.

 

 

 

 

 

 

 

 

 
Gönderildi : 12/08/2008 00:38

(@mesutsariyar)
Gönderiler: 2515
Co-Founder
 

Yanlış girilen kayıt SQL içerisinden sorgu ile veya girildiği gibi.. program aracılığı ile de silinebilir.

Ancak database sorunlarına karşı yukarıdaki yöntemi bende kullanırım, kullanmak nasip olmasın.

Teşekkürler..

 

 
Gönderildi : 12/08/2008 21:50

(@barissaygin)
Gönderiler: 106
Estimable Member
 

Sinan Hocam ,acılan forum konusu çok ilgimi çekti, ve transaction log un önemini daha cok kavradığımı zannediyorum, yalnız bu anlattıgınız konunun mantıgını tam anlamak istiyorum aklımda ufak bir soru işareti kaldı sebebp sonuc ilişkisi acısından, şunları sormak istiyorum, evet ya da hayır da yeetrli benim için, dogrumu dusunuyorum diye.


1.a)SQL serverın herhangi bir andaki backup ından restore ederken transaction log yardımıyla belli bir ana dönerken, REcovery modumuz illaki Full mü olmalıdır.?


 


b).Restore edeceğimiz backup diyelimki ayın 10 unda alınmıs olsun, bugun ayın 12 sindeyiz diyelim. ayın 11 ine donmek istiyoruz. Ayın 10 u ile 11 arasında transaction logdan database yazılmıs olan  ve artık transaction logda pasif olan kayıtlar varsa bu dönüş şekliyle loglardaki ayın 10 u ile 11 arasındaki pasif veriler de restore edilecek olan ayın 10undaki backup üzerine ilave olarak yazılmıs olacak mı?


 


2.Bu şekilde değil de mesela ayın 10 undaki databse için restore işlemini yaptıktan sonra, en sonki haliyle transaction loglarını manuel olarak ilgili yere kopyalayıp database ile ilişkilendirsek, bu durumda transaction logdaki ayın 10 undan sonra giren pasif durumdaki kayıtlar  restore edilen database girmez, ancak aktif kayıtlar varsa onlar mı restore edilen  database e yazılır sadece? Bu şekilde veri kaybı yaşanır demek doğru mudur?


çok teşekkür ederim

 
Gönderildi : 28/08/2008 02:42

(@sinankahraman)
Gönderiler: 5224
Illustrious Member
Konu başlatıcı
 

Sinan Hocam ,acılan forum konusu çok ilgimi çekti, ve transaction log un önemini daha cok kavradığımı zannediyorum, yalnız bu anlattıgınız konunun mantıgını tam anlamak istiyorum aklımda ufak bir soru işareti kaldı sebebp sonuc ilişkisi acısından, şunları sormak istiyorum, evet ya da hayır da yeetrli benim için, dogrumu dusunuyorum diye.

1.a)SQL serverın herhangi bir andaki backup ından restore ederken transaction log yardımıyla belli bir ana dönerken, REcovery modumuz illaki Full mü olmalıdır.?  Evet

 

b).Restore edeceğimiz backup diyelimki ayın 10 unda alınmıs olsun, bugun ayın 12 sindeyiz diyelim. ayın 11 ine donmek istiyoruz. Ayın 10 u ile 11 arasında transaction logdan database yazılmıs olan  ve artık transaction logda pasif olan kayıtlar varsa bu dönüş şekliyle loglardaki ayın 10 u ile 11 arasındaki pasif veriler de restore edilecek olan ayın 10undaki backup üzerine ilave olarak yazılmıs olacak mı? Şayet ayın 11 ine dönmek istiyorsanız elinizde o tarihten önce alınmış bir full backup ve o tarihe ait  Differential Backup ' ın bulunması yeterli olacaktır. Full ve Differential Backup ı birleştirdiğinizde ayın 11 ine ve öncesine bire bir dönmüş olacaksınız. Ama ayın 11 inde saat 14:00 de döneyim derseniz şayet o güne ait Transaction_Loglar ın da elinizde olması gerekir. Not olarak aktif ve pasif verilerden neyi kastettiğinizi anlamadım.

 

2.Bu şekilde değil de mesela ayın 10 undaki databse için restore işlemini yaptıktan sonra, en sonki haliyle transaction loglarını manuel olarak ilgili yere kopyalayıp database ile ilişkilendirsek, bu durumda transaction logdaki ayın 10 undan sonra giren pasif durumdaki kayıtlar  restore edilen database girmez, ancak aktif kayıtlar varsa onlar mı restore edilen  database e yazılır sadece? Bu şekilde veri kaybı yaşanır demek doğru mudur? Aktif ve pasif verilerden neyi kastettiğinizi anlamadım. Transaction_Loglar dan geriye dönebilmek için öncelikle Complete Backup ın alınmış olması gereklidir.

çok teşekkür ederim

Ben yedekleme ve geri dönme işlemlerini şu şekilde uyguluyorum:

1 - Her hafta Pazar günleri  Complete Backup (Owerwrite existing media); haftanın diğer günleri Differential Backup (Append to media)

2- Her ayın son günü Complete Backup (Owerwrite existing media), her hafta Pazartesi Differential Backup (Append to media)

3-Her yılın ilk günü Complete Backup (Owerwrite existing media), her ayın son günü Differential Backup (Append to media)

Şayet bir hata ile karşılaşılır ise ve benim hata anından önceye dönmem gerekirse, hata anında ayrı bir yere  Complete Backup ve Append to media olarak Transaction_Log alır ve geri hata anından önceye geri dönerim.Yani ben Transaction_Log ları sadece hata anından hemen önceye dönme ihtiyacı doğduğunda alıyorum.

Backup ve Restore işlemini farklı uygulayan arkadaşım olur ise mutlaka onlarda cevap yazacaklardır.

 

 

 
Gönderildi : 28/08/2008 12:07

(@barissaygin)
Gönderiler: 106
Estimable Member
 

Hocam cok tesekkur ederim .


1.b ve 2.ci sorularım icin aktif pasif kavramından söz ederken benim bildigim kadarıyla sunu anlatmak istedim. Pasif kayıt transaction logdan database yazılmıs kayıt, aktif kayıt da henüz yazılmamıs olan kayıt olarak algılıyorum.


Tabi bu anlayısım yanlıs olabilir ama bu dogrultuda sormak istedim. Yani bir database var, transaction logdaki kayıtlar database yazılmıs, ama biz daha onceki tarihe restore ile donerken, bugun transaction logdan database yazılanları bulamıycaz normalde restore edilen databse icinde. Full olarak tutugumuz transaction log sistemi ,  restore edilen database de bugun olması gereken kayıtları farkedip bunları yazıyor mu restore edilen database e.


1.a ve 2.ci sorularımı bu baglamda sordum hocam 

 
Gönderildi : 29/08/2008 16:54

(@sinankahraman)
Gönderiler: 5224
Illustrious Member
Konu başlatıcı
 

Diyelimki elinizde 28.08.2008 tarihine ait full backup var ama transaction log yok; 29.08.2008 tarihinde saat 13:00 e kadar her şey normaldi ama bu saatte bir problem oldu ve geri dönmeniz lazım

  • Şayet 28.08.2008 tarihindeki backupı kullanırsanız sadece backupın alındığı saate dönersiniz.
  •  28.08.2008 tarihinde full backup ve transaction log u almışsanız 28.08.2008 tarihinde istediğiniz saate dönebilirsiniz.
  • Hata anında örneğimize göre 29.08.2009 tarihinde full backup ve transaction log alırsanız 29.08.2009 tarihinde istediğiniz saate dönersiniz.

Umarım açıklayabilmişimdir.

 
Gönderildi : 29/08/2008 17:14

(@barissaygin)
Gönderiler: 106
Estimable Member
 

Teşekkür ederim, 


Hocam cok oluyorum ama 2 sorum daha var


1...Bahsettiğiniz "28.08.2008 tarihinde full backup ve transaction log u almışsanız 28.08.2008 tarihinde istediğiniz saate dönebilirsiniz."  yontemine benzer sekilde  database i restore edip fakat sonra manuel olarak baska bir yere kopyaladıgımız transaction log dısyasını yine manuel olarak ilgili database in bulundugu yere kopyalarsak da baska hicbisey yapmadan transaction logdaki varsa database yazılmamıs ama yazılması gereken kayıtlar da yazılırmı?Yani Manuel kopyalama işe yarayan bir yontemmidir?


2..sizin hata anı orneginizde transaction log un da yedeginiz alıyorsunuz ama bu sanırım olası problemlere karsı bir yedek sadece, yoksa log dosyasının kendisi saglam ve yerinde duruyor ,degilmi?


NOT:benim aktif kayıt aklımda neden kalmıs buldum, aslında aktif sanal kayıt ve aktif olmayan sanal kayıt varmış


http://www.cozumpark.com/forums/thread/36749.aspx   burda sizin cevabınız icinde geciyor asagıdaki gibi


"SIMPLE Recovery Model Program geliştiriciler, veritabanını test edenler, raporlama amaçlı kullanılan DB ler, üzerinde çok nadir güncelleme yapılan DB ler için en uygun Recovery Model' dır. Her işlem Transaction Log' a kaydedilir. SIMPLE Recovery Model' da da aynen FULL Recovery Model' da olduğu gibi tüm işlemler Transaction Log' a kaydedilir, fakat her Checkpoint' ten Inactive Virtual Logs Transaction Log dosyası içinden silinirler. Böylece Transaction Log dosyanız sürekli büyümez. Aktif olmayan sanal kayıtlar, temizleme esnasında Transaction Log dosyası içindeki dosyanın en sonunda bulunan aktif sanal kaydına kadar temizlenebilir."


 

 
Gönderildi : 29/08/2008 17:54

(@sinankahraman)
Gönderiler: 5224
Illustrious Member
Konu başlatıcı
 

Teşekkür ederim, 

Hocam cok oluyorum ama 2 sorum daha var

1...Bahsettiğiniz "28.08.2008 tarihinde full backup ve transaction log u almışsanız 28.08.2008 tarihinde istediğiniz saate dönebilirsiniz."  yontemine benzer sekilde  database i restore edip fakat sonra manuel olarak baska bir yere kopyaladıgımız transaction log dısyasını yine manuel olarak ilgili database in bulundugu yere kopyalarsak da baska hicbisey yapmadan transaction logdaki varsa database yazılmamıs ama yazılması gereken kayıtlar da yazılırmı?Yani Manuel kopyalama işe yarayan bir yontemmidir? Bu şekilde şimdiye kadar hiç uygulama yapmadım

2..sizin hata anı orneginizde transaction log un da yedeginiz alıyorsunuz ama bu sanırım olası problemlere karsı bir yedek sadece, yoksa log dosyasının kendisi saglam ve yerinde duruyor ,degilmi? Transaction logun yedeği alınır çünkü ancak Transaction log sayesinde istediğim zamana hatta saniyeye dönebilirim. Şayet Transaction log olmaz ise sadece yedeğin alındığı zamana dönebilirim.

NOT:benim aktif kayıt aklımda neden kalmıs buldum, aslında aktif sanal kayıt ve aktif olmayan sanal kayıt varmış

http://www.cozumpark.com/forums/thread/36749.aspx   burda sizin cevabınız icinde geciyor asagıdaki gibi

"SIMPLE Recovery Model Program geliştiriciler, veritabanını test edenler, raporlama amaçlı kullanılan DB ler, üzerinde çok nadir güncelleme yapılan DB ler için en uygun Recovery Model' dır. Her işlem Transaction Log' a kaydedilir. SIMPLE Recovery Model' da da aynen FULL Recovery Model' da olduğu gibi tüm işlemler Transaction Log' a kaydedilir, fakat her Checkpoint' ten Inactive Virtual Logs Transaction Log dosyası içinden silinirler. Böylece Transaction Log dosyanız sürekli büyümez. Aktif olmayan sanal kayıtlar, temizleme esnasında Transaction Log dosyası içindeki dosyanın en sonunda bulunan aktif sanal kaydına kadar temizlenebilir."

 

 
Gönderildi : 29/08/2008 18:15

(@barissaygin)
Gönderiler: 106
Estimable Member
 

Hocam cok tesekkur ederim bayagı bilgi sahibi oldum.


En son olarak şunu sorabilir miyim.


Gerek Full, gerek Incremental veya Differential backup alındıgında bunların 3 ü içinde , transaction log da database e kaydedilmemiş bir veri varsa önce bunlar database kaydediliyor ve sonra database dosyamızın yedegi alınıyor diyebilir miyiz, bu şekilde mi calısıyor MS SQL server?


Bütün cevap veren arkadaslara cok tesekkur ediyorum.

 
Gönderildi : 30/08/2008 00:59

(@sinankahraman)
Gönderiler: 5224
Illustrious Member
Konu başlatıcı
 

Hocam cok tesekkur ederim bayagı bilgi sahibi oldum.

En son olarak şunu sorabilir miyim.

Gerek Full, gerek Incremental veya Differential backup alındıgında bunların 3 ü içinde , transaction log da database e kaydedilmemiş bir veri varsa önce bunlar database kaydediliyor ve sonra database dosyamızın yedegi alınıyor diyebilir miyiz, bu şekilde mi calısıyor MS SQL server?

Bütün cevap veren arkadaslara cok tesekkur ediyorum.

Öncelikli olarak şunu bilmeniz gerekir SQL de  Incremental Backup diye bir yedekleme seçeneği yoktur. SQl deki yedekleme seçenekleri; Complete, Differential, Transaction log  tur. Taransaction Log; Database'de gerçekleşen değişikliklerin tutulduğu log dosyasıdır. Yani Transaction Log yedeği aldığımızda yedeği aldığımız zamana kadar DB üzerinde yapılan değişikliklerin logunu almış oluruz.

 

 
Gönderildi : 01/09/2008 11:18

(@Anonim)
Gönderiler: 0
 

Hocam güzel bilgiler için teşekkür ederim.

 
Gönderildi : 28/01/2010 20:52

(@sinankahraman)
Gönderiler: 5224
Illustrious Member
Konu başlatıcı
 

Rica ederiz.

 
Gönderildi : 28/01/2010 20:53

Paylaş: