|
|
|
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 |
|