|
|
|
Recovery Models: FULL, BULK LOGGED,
SIMPLE
|
Son güncelleme tarihi: 08 Ocak 2008
Merhaba arkadaşlar,
SQL Server' da veritabanlarınız için duruma
göre kullanabileceğiniz üç adet Recovery Model bulunmaktadır. Size
bu yazımda Recovery Model' lardan bahsedeceğim. Ne işe yaradıklarından ve hangisini
ne gibi durumlarda kullanabileceğinizi anlatacağım.
SQL Server' da üç adet Recovery Model kullanabileceğinizi söylemiştim, bunlar:
- FULL
- BULK LOGGED ve
- SIMPLE' dır.
Peki nedir Recovery Model, ne işe
yarar?
Recovery Model, bir veritabanı özelliğidir ve istenildiğinde değiştirilebilir.
Yedekleme ve açma (Backup ve Restore) işlemleri
Recovery Model bağlamında gerçekleşir. Veritabanınız için belirlediğiniz Recovery
Model, veritabanınızın yedeğini alma ve açma seçeneklerinizi belirleyecektir. Bu
nedenle özellikle trafiği yoğun olan veritabanlarında çok dikkat etilmesi gereken
bir ayardır. Bir veritabanının Recovery Model ayarı, Transaction Log' ların nasıl
kaydedileceğini belirler. SQL Server' da, Transaction Log' un tutulmaması
diye bir
şey yoktur. Her halükârda Transaction Log' a veriler kaydedilir (BULK LOGGED' da
bazı istisnalar göreceksiniz), ama bu kayıtların nasıl işleneceğini ve yönetileceğini
Recovery Model' larla belirlersiniz.
Not
Yeni oluşturduğunuz bir veritabanı, diğer ayarlar ve nesneler gibi Recovery
Model ayarını da Model sistem veritabanından alır.
FULL Recovery Model
Eğer veritabanınız bir üretim (Production)* veritabanıysa, veritabanında
bir sorun olduğunda veri kaybına tahammül yoksa ve sıkı bir yedekleme gerekiyorsa
veritabanınızın Recovery Model' ının FULL olması gerekmektedir. Böylece, veritabanınız
üzerinde gerçekleştirilen her işlem tam olarak kaydedilir ve yedeği alınabilir.
Böylece, hata anına kadarki verilerinizi yedekleyebilir ve Hata Anı (Point of Failure)
denilen ana kadar verilerinizin yedeğini alabilir ve o ana yedekleriniz ile tekrar
ve tam olarak dönebilirsiniz. Bunu en güvenli şekilde FULL Recovery Model ile sağlayabilirsiniz.
* Üretim (Production) ortamı = Bunun anlamı,
veritabanınızın çalışan ve dinamik bir sistemde kullanıldığıdır. Meselâ bir fabrikada
veya bir hastanedeki veritabanını örnek olarak verebilirim. Bunlar üretim ortamlarıdır.
Test ortamı ise farklıdır. Test ortamında veri kaybı genellikle sorun olmaz ama
üretim ortamlarında veri kaybı genellikle kabul edilebilir değildir ve bu nedenle
işinizden olabilir, hatta ve hatta çok ciddi yaptırımlar ile karşılaşabilirsiniz.
BULK LOGGED Recovery Model
BULK LOGGED Recovery Model' ı toplu (BULK) işlemler yapmak istediğimizde, ama bu
toplu işlemlerin Transaction Log dosyamızı büyütmesini istemediğimizde kullanırız.
Peki hangi toplu işlemler BULKED LOGGED Recovery Model kullanıldığında en az şekilde
Transaction Log dosyasına kaydedilir? Şunlar:
- bcp, INSERT ... SELECT * FROM OPENROWSET(BULK...), ve BULK INSERT.
- WRITETEXT ve UPDATETEXT ile text, ntext ve image veritiplerine yeni veri oluşturduğunuzda
ve eklediğinizde. Dikkat edin, güncelleme işlemi yaptığınızda Transaction Log' unuzda
tam kayıt yapılır.
- SELECT INTO
- CREATE INDEX, ALTER INDEX REBUILD veya DBCC DBREINDEX, DROP INDEX
- UPDATE kullanarak büyük değerli veritiplerine yapılan kısmi güncellemeler (varchar(max),
text, ntext gibi...)
Bu Recovery Model, FULL Recovery Model ile birlikte kullanılmalıdır. Şöyle ki, FULL
Recovery Model' da her işlemin kaydının tutulduğunu ve Hata Anına dönebileceğimizi
söylemiştim. BULK LOGGED' da ise toplu (BULK) bir işlem yapıldığında ve o anda veritabanında
bir hasar oluştuğunda hata anına geri dönemezsiniz. Bu nedenle normalde, eğer Hata
Anına dönebilmeyi istiyorsanız ve verileriniz sizin için çok önemliyse ve sürekli
INSERT\UPDATE\DELETE işlemleri yapılıyorsa üretim ortamları için FULL Recovery Model'
ı öneriyorum. Ama geçici olarak BULK işlemlerin Transaction Log' a kaydedilmemesi
için BULK LOGGED' a geçiş yapıp, sonra toplu işlemleri bitirdikten sonra hemen FULL' e dönüş yapabilirsiniz. Böylece, Transaction Log' unuzun şişmesini engellersiniz
ve işlemleri hızlandırırsınız çünkü yapılan her toplu işlem Transaction Log' a kaydedilmemiş
olacak; bu da işlemleri hızlandıracak.
SIMPLE Recovery Model
Program geliştiriciler ve veritabanını test edenler için en uygun Recovery Model'
dır. Her işlem Transaction Log' a kaydedilir, hangi Recovery Model' ı seçerseniz
seçin veritabanına karşı yapılan işlemler kaydedilir demiştim, BULK LOGGED' da da
bazı istisnaları gördük.
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 sonra aktif olmayan sanal
kayıtlar (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. Aktif sanal kayıt da, Transaction Log dosyasında o
anda hâlâ işlem görüyor olan bir Transaction işlemidir. (Açık işlemler DBCC OPENTRAN
komutuyla görüntülenebilir.) Temizleme işlemi dosyanın sonundan başına doğru yapılır,
bu nedenle yukarıdaki satırlarda Transaction Log dosyası içindeki en son aktif sanal
kayda vurgu yaptım. Aktif sanal kayıtlar, işlem bitene kadar temizlenemezler.
Bu Recovery Model, OLAP olarak kullanılan veritabanları için de uygundur. Bu tür
veritabanları sadece raporlama amaçlı kullanıldığından ve üzerlerinde güncelleme
yapılmadığından, ki yapılsa bile çok nadir yapıldığından ve genelde de Salt-Okunur
(Read Only) olduklarından dolayı Recovery Model' larının SIMPLE olması oldukça olağandır.
Çünkü bu tür veritabanları zaten pek yedeklenmezler, çünkü üzerlerinde güncelleme
yapılmaz.
Sistem Veritabanları (master, msdb, model, tempdb)
Sistem veritabanlarının varsayılan Recovery Model ayarları aşağıdaki gibidir:
- "master" = SIMPLE : Çünkü bu veritabanını sürekli yedeklemeye gerek yoktur. Sadece
SQL Server düzeyinde değişiklikler yaptığınızda (Login, Linked Server gibi...) tam
yedekleme yapmanızı öneririm.
- "msdb" = SIMPLE : Bu veritabanı bazı durumlarda çok kullanılıyor olabiliyor, yani
istisnalarını gördüm. Ama genel olarak SIMPLE kalmasında bir sakınca yok.
- "model" = FULL : Yazıma başlarken yukarıda da söylemiştim, yeni veritabanlarınız
"model" sistem veritabanı model alınarak oluşturulur. Bu nedenle yeni veritabanlarınızın
eğer varsayılan olarak FULL Recovery Model' ı kullanılarak oluşturulmasını istiyorsanız,
o zaman "model" veritabanının Recovery Model' ını buna göre ayarlayın veya başka isteğinize göre...
- "tempdb" = SIMPLE : Bu veritabanı zaten her SQL Server servisini durdurup başlattığınızda
otomatik olarak silinip tekrar oluşturulduğu ve üzerinde sadece geçici işlemler
yapıldığı için SIMPLE olması en iyisidir.
Peki bir veritabanının Recovery Model ayarını nasıl değiştirebilirsiniz?
Bu ayar değişikliği için ister SQL Server 2005 ile birlikte gelen (Express
Edition hariç) ve SQL Server' ı yönetmek için kullanabileceğimiz arayüz aracı olan
SQL Server Management Studio (SQL Server 2005 veya 2000) kullanarak, isterseniz
SQL Server 2000 ile birlikte gelen Enterprise Manager arayüzünü kullanarak veritabanınızın
özelliklerine (Properties) gidip, seçenekler (Options)' den Recovery Model' ı değiştirebilirsiniz.
Bu ayarı SQL Server 2005' teki Query Editor veya SQL Server 2000' deki Query Analyzer
ile de değiştirebilirsiniz. Aşağıdaki örneklere bakın:
Recovery Model' ı FULL yapmak için:
ALTER DATABASE DenemeVT SET RECOVERY FULL
Recovery Model' ı BULK LOGGED yapmak için:
ALTER DATABASE DenemeVT SET BULK_LOGGED FULL
Recovery Model' ı SIMPLE yapmak için:
ALTER DATABASE DenemeVT
SET RECOVERY SIMPLE
Ekrem Önsoy
|
|
Anasayfa |
|