SQL Server 2008 / R2 kurtarma modeli

Belirli sunuculardaki hemen hemen tüm veritabanlarımız Tam Kurtarma modeli gerektirmez (işlem günlüğü yedeklemeleri yapmayız) ve varsayılan değer her zaman veritabanı oluşturmak ve Basit Kurtarma modelini belirtmek olmalıdır.

Oldukça sık ve bazı pratik nedenlerden dolayı SSMS kullanılarak birçok veritabanı oluşturulur. Ancak hatalar yapılabilir ve operatör Basit Kurtarma modelini belirlemeyi unutabilir. Bu, birkaç gün sonra, kutu hiç kesilmemiş üç veya dört 60 GB günlük dosyası nedeniyle disk alanı ile mücadele ettiğinde bir "sürpriz" e yol açar.

Basit Kurtarma modelini, veritabanındaki kurtarma modelini yapılandırarak yeni veritabanları için varsayılan ayar yapabilirim model. Ancak, bu tavsiye edilir, eğer bunu yaparsam geri gelip beni herhangi bir şekilde ısırır mı?

Burada üç seçenekten birini görüyorum:

1) kurtarma modelini açıkça içeren veritabanları oluşturmak için şablonlanmış bir komut dosyanız olabilir .

2) veritabanını basit olarak ayarlayabilirsiniz vemodel bu konuda endişelenmenize gerek yoktur.

3) Herkesin hatırladığını umabilirsiniz, ki bu yaptığınız gibi görünür. (tavsiye edilmez)

Şahsen iki numara ile giderdim. Model veritabanı bunun için var.

@ Surfer513'e ekleniyor

4) Basit kurtarma modelini uygulamak için ilke tabanlı yönetim ilkesi veya bir DB olmadığında en fazla bilgi

Her ne kadar basit ayar modelini tercih etsem de bu T-SQL komutunun kullanılmasını ve başka bir şeye ayarlanmasını engellemez. Kurtarma modelinin Basit olup olmadığını değerlendirmek için bir politika kullanabilir ve politikanın sizin için değiştirmesini seçebilirsiniz.

Bu MSSQLTip.com makalesi Tam için denetleniyor, ancak kolayca basitçe sizinki kontrol edebilirsiniz. Veritabanında da bir yedekleme olup olmadığını görmek için bir onay işareti de atabilirsiniz.

Güvenli bahis, DB'nizi tam moda geçirmektir, ancak o zaman günlük büyüme sorununuz vardır. Şimdi bazı seçenekler var:

• Günlük dosyanızın maksimum boyutuna bir sınır koyun. Bu sınıra ulaşıldığında işlemleri etkileyecektir. Avantajı, diskin alanının bittiği senaryoları önleyecek ve daha büyük sorunlarınız olacaktır.
• Günlük dosyanız bir filigranın üzerine çıktığında tetiklenen uyarılar oluşturun ve ardından yönetin.
• Günlük küçültme işlerini zamanlama. Günlük kaydı DB'nizin performansını azaltır. Ben tavsiye etmem.

DBA olarak, kurtarmaya yardımcı olan tüm seçenekleri kullanmalısınız. Aynı zamanda işletme ile SLA'nıza da bağlıdır.

Tüm bunlar söyleniyor, basit modda birkaç DB yönetiyorum. Bunun nedeni, SLA'da belirtilen yasal uyarılardır. İşletme, günlük dosyaları için sürücülere harcama yapmamaya karar verdi (suya bir at alabilirsin, ama içemezsin). İşletme, yedekleme, geri yükleme ve DR'yi yönetir. Bir DR vardı ve kaybedilen para ekstra disk alanında maliyetinden daha büyüktü.