Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Ekim 2017  >>
PaSaÇaPeCuCuPa
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
Keywords

Biraz uzun bir makale başlığı oldu değil mi? Ama bir o kadar da ilginç. Peki ne demeye çalışıyorum?

[more]

Kısa bir “recovery model” bilgi tazelemesi yaparak konuya gireyim.

Bildiğiniz gibi SQL Server’da Full, Simple ve BulkLogged olmak üzere 3 adet recovery model bulunmakta. Simple recovery model’de commit edilmiş transaction’lar checkpoint’ten sonra otomatik olarak truncate edilirken Full recovery model’de commit edilmiş transaction’ların truncate edilebilmesi için log backup alınması gerekmekte.

Peki Full Recovery Model, Simple Recovery Model gibi davranabilir mi? Yani Full Recovery Model’de transaction log backup almadan transaction’ların otomatik olarak truncate olması mümkün mü?

Makale başlığına bakmadan yukarıdaki soruyu okusaydınız büyük ihtimal cevabınız “hayır” olacaktı. Smile Ama evet böyle bir şey mümkün.

Full Recovery Model’e sahip database’in eğer full backup’ı hiç alınmadı ise bu veritabanı recovery model’i simple gibi davranmakta ve commit edilmiş transaction’lar checkpoint’ten sonra silinmekte.

İlginç değil mi?

Bir örnek vererek konuyu pekiştirelim. Örneğimde full recovery model’e sahip bir veritabanı create edeceğim ve insert’ten önceki ve sonraki log boyutlarına ve doluluk oranlarına bakacağım. Bu şekilde log’un otomatik olarak truncate edilip edilmediğini görmüş olacağım.

Önce bir çalışma DB’si create edip Recovery Model’ini Full olarak set ediyorum.

CREATE DATABASE FullRecDB ON PRIMARY (
    NAME = FullRecDB_data,
    FILENAME = N'C:\SQLData\FullRecDB_data.mdf')
LOG ON (
    NAME = 'FullRecDB_log',
    FILENAME = N'C:\SQLData\FullRecDB_log.ldf',
    SIZE = 50MB);
GO

USE [master]
GO
ALTER DATABASE [FullRecDB] SET RECOVERY FULL WITH NO_WAIT
GO

Şu an ki log doluluk oranı bakıyorum.

dbcc sqlperf(logspace)
go

Daha herhangi bir işlem yapmadığım için log doluluk oranı %1 in altında.

Full1

Şimdi bir çalışma tablosu create ediyorum ve daha sonra bir transaction başlatıp bu tabloya 8000 adet veri insert ediyorum.

use FullRecDB
GO
create table abc(a char(4000))
go

begin tran
GO
insert abc select 'a'
go 8000

Başka bir session’dan log doluluk oranına tekrar bakıyorum

dbcc sqlperf(logspace)
go

ve beklediğim gibi log'un kullanımı %80'ler seviyesinde

Full2

Şimdi açtığım transaction’ı commit edip checkpoint gönderiyorum ve sonrasında log doluluk oranına bir daha bakıyorum.

commit tran

checkpoint

dbcc sqlperf(logspace)
go

Normalde recovery model’im Full olduğu ve log backup almadığım için log doluluk oranımın gene %80’ler civarında gelmesini bekliyordum. Ama hiç full backup almadığım için database’im simple recovery model gibi davranıyor ve commit edilmiş transaction’ları siliyor. Bu yüzden log’un doluluk oranının düşmüş olduğunu görüyorum.

Full3

Aynı işlemleri en başta full backup alarak deneseydim log truncate olmayacaktı. Denemesi bedava Smile

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


You can find the free ebooks below.

clip_image002  clip_image003  clip_image004 

clip_image005  clip_image007  clip_image008

clip_image009  clip_image010  Moving to Visual Studio 2010

Programming Windows Phone 7

Enjoy Smile

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Policy Based Management and Central Management Server feature can be used together to monitor some best practices over all SQL Server environment.

[more]

Today we are going to talk about how can we use policy based management to monitor Last Successful DBCC CheckDB date for all databases.

Basically we will use DBCC DBINFO() command to check last successful DBCC CheckDB date. In the result set, we will use the value of “dbi_dbcclastknowngood” field.

Here is the script which is used for condition;

ExecuteSql('Numeric', '
CREATE TABLE #tmp
	(ParentObject varchar(1000) NULL,Object varchar(1000) NULL,Field varchar(1000) NULL,Value varchar(1000) NULL)
insert into #tmp
EXEC (''DBCC DBINFO() WITH TABLERESULTS'')
select cast(value as datetime) from #tmp where field=''dbi_dbcclastknowngood''
drop table #tmp
')

Condition;

pbm1

and the policy;

pbm2

and a sample evaluation report for this policy;

pbm3

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


12 Eylül 2012 Çarşamba günü yapacağım webcast’in duyurusunu yapmak istiyorum.

SQL Server 2012 ile beraber gelen yeni High Availability çözümü olan AlwaysOn üzerine konuşacağımız bu webcast 10:00’da başlayacak.

Kayıt olmak için aşağıdaki linki kullanabilirsiniz.

Başlangıcı: 12 Eylül 2012 Çarşamba 10:00
Saat dilimi: (GMT+02:00)
Süre: 1 saat 30 dakika
Kayıt Linki : https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032527839&Culture=TR-TR&community=0

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan