Recovery Models: FULL, BULK LOGGED, SIMPLE

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