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
<<  Aralık 2017  >>
PaSaÇaPeCuCuPa
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567
Keywords

SQL Server 2012’den önceki versiyonlarda varchar(max), nvarchar(max) ya da varbinary(max) tipinde kolon içeren index’lerde create ya da rebuild gibi online Index operasyonları yapılamıyordu. SQL Server 2012 ile beraber artık bu işlemleri yapabileceğiz.

[more]

SQL Server 2012’den önceki versiyonlarda bu işlemi yapmak istediğimizde şu şekilde bir hata almaktaydık.

create table tblOnlineIndex(a int,b varchar(max))
go
insert tblOnlineIndex
	select 1,'abc'
go
create clustered index IX_1 on tblOnlineIndex (a)
	with (Online=ON)
GO

 

Msg 2725, Level 16, State 2, Line 1
An online operation cannot be performed for index 'IX_1' because the index contains column 'b' of data type text, ntext, image, varchar(max), nvarchar(max), varbinary(max), xml, or large CLR type. For a non-clustered index, the column could be an include column of the index. For a clustered index, the column could be any column of the table. If DROP_EXISTING is used, the column could be part of a new or old index. The operation must be performed offline.

SQL Server 2012 ile beraber bu işlemi hatasız gerçekleştirebiliyoruz. Yani SQL Server 2012, içeriğinde varchar(max), nvarchar(max) ya da varbinary(max) tipinde kolon içeren Index’lerde online operasyonları desteklemekte.

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


SQL Server 2012 ile Database Engine Tuning Advisor (DTA) aracını kullanarak Plan Cache’de hali hazırda toplanmış veriler üzerinden performance tuning analizi yapabiliriz.

[more]

SQL Server 2012’den önce DTA ile, daha önce hazırlanmış workload bir tablo ya da dosya kullanılarak analiz yapılabiliyordu. SQL Server 2012 ile beraber bu seçeneklerin yanına Plan Cache analiz seçeneği de gelmiş durumda. Bu seçeneği kullanarak herhangi bir workload oluşturmadan hali hazırda Plan Cache’de bulunan planlar üzerinden performance tuning çalışması yapabiliriz.

1

Plan Cache kullanılarak yapılan analizde varsayılan olarak ilk 1000 plan kullanılmaktadır. Bu rakam DTA programının –n parametresi ile değiştirilebilir.

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


Dünyada pek çok ülkede faaliyet gösteren SQL PASS topluluğunun Türkiye şubesi olarak kurulan SQL Server Öncüleri Topluluğu'nun tanıtım toplantısı 21 Ekim'de gerçekleşti.

Hayata geçtikleri kısa bir sürede SQL Server Öncüleri, teknik türkçe içeriklerini 100'e yakın makale, 4 video, onlarca sunum web seminer aracılığı ile tüm Türkiye’den geniş bir katılımcı kitlesine ulaştırdılar.

21 Ekim’de Microsoft İstanbul ofisinde gerçekleştirdikleri topluluk lansmanına ise, 123 kişilik rekor bir katılım gerçekleşti. Lansman katılımcıları SQL Server 2012, Database Consolidation Appliance, SQL Azure da dahil olmak üzere, İş Zekası ve İş Kritik Uygulamalar konusunda 9 oturuma katıldılar

Etkinlik kapsamında gerçekleştirilen sunumların video ve sunum dosyalarına aşağıdaki linkten erişebilirsiniz.

http://www.sqlserveronculeri.com/5/Activity/285/sql-server-onculeri-istanbul-lansmani-sunum-kayitlari.aspx

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


SQL Server 2012 kurulumu yaptığımızda hali hazırda bulunan database’ler Contained Database değildir. Bu database’leri istersek Contained Database haline dönüştürebiliriz. Fakat hali hazırda kullandığımız login’leri de Contained Database User haline dönüştürmeliyiz ki user’ları server’dan izole edip database taşımalarında sıkıntısız bir şekilde bu user’ları kullanmaya devam edebilelim.

[more]

Bir önceki yazımda Contained olmayan user’ları nasıl bulabileceğimizi görmüştük.

Sorgu sonucu bulduğumuz user’ları sp_migrate_user_to_contained SP’sini kullanarak Contained hale getirebiliriz.

Bir önceki yazımdaki örnekten devam edecek olursak, login_turgay isimli login’i Contained hale getirmek için şu kodu kullanabiliriz. Tabiki ilk olarak database’i Contained hale getirmemiz gerekmekte. Aksi halde user dönüştürme SP’si hata alacaktır.

ALTER DATABASE AdventureWorks SET CONTAINMENT=PARTIAL;
GO
EXEC sp_migrate_user_to_contained
	@username = N'login_turgay',
	@rename = N'keep_name',
	@disable_login = N'disable_login'

 

Bu işlem sonucunda login_turgay isimli login Contained User haline dönecek ve ilgili login nesnesi disable edilecektir.

Bu şekilde Contained hale dönüştürmeyi düşündüğümüz database’lerde bulunan kullanıcıları da Contained hale getirebiliriz.

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


Daha önceki yazılarımda bahsetmiştim. Contained Database, SQL Server 2012 ile gelen güzel özelliklerden biri. Kısaca üstünden geçmek gerekirse; Contained Database ile database engine’den izole edilmiş bir database oluşturabilir ve instance’lar arasında sıkıntısız bir şekilde taşıma işlemi gerçekleştirilebilir.

Peki her database’i contained hale dönüştürebilir miyiz? Yani contained database’lerde desteklenmeyen bir özellik var mı?

[more]

SQL Server’da kullanılan bütün objeler Contained olarak desteklenmezler. Örneğin aşağıdaki url’de Partial Containment Type tarafından desteklenmeyen entity listesine erişebilirsiniz.

http://msdn.microsoft.com/en-us/library/ff929071%28v=sql.110%29.aspx

Peki benim halihazırda kullandığım bir database var bu database contained olarak destekleniyor mu? Ya da soruyu değişik bir şekilde sorarsak; database’imde Contained olmayan bir obje var mı?

Bu sorumuza sys.dm_db_uncontained_entities DMV’si ile cevap bulabiliriz. Bu DMV üzerinde çalıştırıldığı database’de contained olmayan entity’leri listelemektedir.

Kullanımı şu şekildedir;

select * from sys.dm_db_uncontained_entities

 

Şimdi bir örnek yaparak konuyu daha iyi anlamaya çalışalım. Örneğimde normal bir login ve bu login’e bağlı bir user create edeceğim. Dolayısıyla Contained olmayan yani server’a bağımlı bir obje sahibi olacağım.

Daha sonra da yukarıdaki DMV’yi kullanarak Contained olmayan obje listesinde bu login’i görmeye çalışacağım.

Use AdventureWorks
GO
--Login create ediyorum
create login login_turgay with password='password'
GO
--User create ediyorum
create user login_turgay for login login_turgay
go

 

Şimdi DMV’yi kullanarak contained olmayan objeleri listeliyorum.

select dp.principal_id,dp.name,dp.type_desc,dp.default_schema_name,dp.create_date 
from sys.dm_db_uncontained_entities ue
join sys.database_principals dp on dp.principal_id=ue.major_id
join sys.server_principals sp on sp.sid=dp.sid
where ue.class=4
	  and dp.authentication_type = 1
	  and sp.is_disabled = 0 

 

image

Gelen sonuca baktığımda az önce create etmiş olduğum “loginx” isimli login’in beklediğim gibi Contained olmayan bir obje olduğunu görüyorum.

Bir sonraki yazımda Contained olmayan bu user’ları Contained hale nasıl dönüştürebileceğimize bakıyor olacağız.

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


Tablolar üzerinde çalışacağım hemen hemen her makalemde bir örnek çalışma tablosu oluşturuyorum. Bu makalemde ise bu çalışma tablolarını daha hızlı bir şekilde nasıl oluşturabileceğimizi görüyor olacağız.

[more]

Normalde şu ana kadar çalışma tablomu hep şu tarz bir script ile dolduruyordum.

Create Table DenemeTbl1 (Col1 int, Col2 char(15), Col3 char(25), Col4 char(20))
GO
SET NOCOUNT ON
GO
declare @i int=1
while @i<=100000 begin
  insert DenemeTbl1
    select @i
	  ,'turgay'+cast(@i as varchar(6))
	  ,'sahtiyan'+cast(@i as varchar(6))
	  ,'SQLServerDBA'+cast(@i as varchar(6))
  set @i=@i+1
end

 

100.000 kayıt insert eden yukarıdaki işlem benim laptop’ımda 13 saniye sürmekte.

Şimdi aynı işlemi değişik bir teknik ile yapacağım.

Create Table DenemeTbl2 (Col1 int, Col2 char(15), Col3 char(25), Col4 char(20))
GO
INSERT DenemeTbl2 WITH (TABLOCKX)
	SELECT rn
		  ,'turgay'+cast(rn as varchar(6))
		  ,'sahtiyan'+cast(rn as varchar(6))
		  ,'SQLServerDBA'+cast(rn as varchar(6))
	FROM
	(SELECT TOP (100000) rn = ROW_NUMBER() OVER (ORDER BY c1.number)
	FROM master..spt_values AS c1 CROSS JOIN master..spt_values AS c2
	ORDER BY rn)
	AS x;

 

Bu işlem ise sadece 167 milisaniye sürmekte.

Sürekli performanstan bahseden biri olarak kendi işlemlerimizi performansız yapmak bize yakışmaz :) Bu yüzden bundan sonraki makalelerimde bu tekniği kullanacağım.

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


sp_configure sistem prosedürü ile “max server memory (MB)” veya “min server memory (MB)” parametrelerini değiştirdiğimizde Plan Cache silinir yani cache’lenmiş Query Plan’lar memory’den atılır. Bu durum da yeni gelen sorgular için planların tekrar oluşturulması anlamına geleceği için performans sıkıntısı oluşabilir. Bu yüzden memory paremetrelerinin planlanarak uygun bir zamanda örneğin mesai saatleri dışında yapılması daha anlamlı olacaktır.

[more]

Memory parametresini değiştirdiğimizde Plan Cache’in silindiğini gözlemlemek için şöyle bir örnek yapalım.

--Aktif olan min_server_memory değerini alıyorum.
--İşlemlerim bittiğinde eski haline çevirmek için kullanacağım.
declare @Actual_Min_Server_Memory int=0
select @Actual_Min_Server_Memory=cast(value_in_use as int)
from sys.configurations
where name = 'min server memory (MB)'

--Basit bir sorgu çekelim
select * from sys.databases

--Cache'lenmiş planlara bakalım
select cp.usecounts,
	   st.text,
	   qp.query_plan,	   
	   cp.cacheobjtype,
	   cp.objtype,
	   cp.size_in_bytes
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_query_plan(cp.plan_handle) qp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st
where st.text like '%select * from sys.databases%'
	and st.text not like 'select cp.usecounts%'
order by cp.usecounts desc

--Min Server Memory parametresini değiştirelim
exec sp_configure 'min server memory (MB)',1
reconfigure with override

--Cache'lenmiş planlara tekrar bakalım
select cp.usecounts,
	   st.text,
	   qp.query_plan,	   
	   cp.cacheobjtype,
	   cp.objtype,
	   cp.size_in_bytes
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_query_plan(cp.plan_handle) qp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st
where st.text like '%select * from sys.databases%'
	and st.text not like 'select cp.usecounts%'
order by cp.usecounts desc

--Min Server Memory parametresini eski haline çevirelim.
exec sp_configure 'min server memory (MB)',@Actual_Min_Server_Memory
reconfigure with override

 

Sorgu sonuçlarında da gördüğünüz gibi ilk plan cache sorgumuz sonuç döndürürken min server memory parametresini değiştirdikten sonra çektiğimiz plan cache sorgusu sonuç döndürmedi.

Bu yüzden min ve max server memory parametrelerini mesai saatlerinde değiştirmektense sistemin daha az yoğun olduğu bir saatte değiştirmeniz anlamlı bir hareket olacaktır.

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


Daha önce duyurduğum gibi SQL Server 2012 ile beraber “Business Intelligence” adında yeni bir sürüm geliyor. Hem bu yeni sürümün hem de Enterprise ve Standart sürümlerinin içerdikleri özellikleri aşağıda paylaşacağım BOL dokümanında bulabilirsiniz.

[more]

SQL Server 2012 ile beraber gelen yeni özellikler ve diğer göze çarpan değişiklikleri özetlemek gerekirse;

  • Express edition için max db boyutunda herhangi bir yükseltme olmamış. 10 GB’lık sınır devam etmekte.
  • SQL Server 2008 R2 ile beraber backup compression özelliği standart edition’a inmişti. SQL Server 2012’de de durum bu şekilde.
  • Always On özelliği sadece Enterprise edition’da mevcut.
  • Distributed Replay Utility’nin değişik component’leri değişik edition’lar tarafından desteklenmekte. Detayları BOL sayfasında bulabilirsiniz.
  • SSDT(SQL Server Data Tools) bütün edition’larda mevcut.
  • File Table bütün edition’larda mevcut.
  • Master Data Services sadece 64 bit Enterprise ve Business Intelligence edition’larda mevcut.
  • ColumnStore Index sadece Enterprise edition’da mevcut.

Daha detaylı bilgiye aşağıdaki BOL linkinden erişebilirsiniz.

http://msdn.microsoft.com/en-us/library/cc645993(v=sql.110).aspx

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


14 Aralık 2012 Çarşamba günü yapacağım webcast’in duyurusunu yapmak istiyorum.

SQL Server 2012 ile Gelen Yeni Özellikler başlıklı webcast’im 14.12.2011 tarihinde 21:00-22:00 saatleri arasında gerçekleşecek.

Aşağıdaki url’i kullanarak vereceğim bu webcast’e katılabilirsiniz.

https://www.livemeeting.com/cc/mvp/join?id=4S9MBN&role=attend&pw=2NM%7E%60JK%7Bt

Konu ile ilgili CozumPark linki ise şu şekilde;

http://www.cozumpark.com/forums/thread/272620.aspx

SQL Server’ın 2012’nin ilk yarısında çıkması beklenen yeni versiyonu üzerinde konuşacağımız bu webcast’i kaçırmamanızı tavsiye ederim.

 

İyi Çalışmalar

Turgay Sahtiyan

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


Bildiğiniz gibi SQL Server’da şifreler hash’lenmiş olarak saklanırlar. Dolayısıyla login’lerin şifrelerinin ne olduklarını, güçlü mü yoksa zayıf mı oldukları direk olarak bilmemiz mümkün değildir. İşte bu amaçla PWDCOMPARE fonksiyonunu kullanabiliriz. Bu fonksiyon ile şifreyi istediğimiz bir şifre ile karşılaştırıp zayıf olup olmadığını kontrol edebiliriz.

[more]

Örneğin sistemde şifresi boş olan login’leri bulmak için;

SELECT name FROM sys.sql_logins 
WHERE PWDCOMPARE('', password_hash) = 1 ;

 

Ya da şifresi “password” olan login’leri bulmak için;

SELECT name FROM sys.sql_logins 
WHERE PWDCOMPARE('password', password_hash) = 1 ;

 

sorgularını kullanabiliriz.

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


SQL Server varsayılan olarak, deny verilmiş bir tablo üzerinde bir kolona grant verildiyse bu kolonun sorgulanmasına izin vermektedir. “Common Criteria Compliance Enabled” parametresi ile bu davranış değiştirilebilir.

[more]

Common Criteria Compliance Enabled parametresi sp_configure ile değiştirilebilir.

sp_configure 'common criteria compliance enabled', 1;
GO
RECONFIGURE
GO

 

Sadece Enterprise Edition’da bulunan bu parametrenin default değeri 0 yani Disabled’dır.

Şimdi bu parametrenin enabled ya da disabled olması durumuna göre table-column level permission’ların ne şekilde etkili olduklarını görelim.

“'common criteria compliance enabled” Enabled – 1

Bu durumda table level permission column level permission’ı ezer. Yani eğer tabloya deny verildiyse, kolonlara grant verilse dahi bu kolonlar sorgulanamaz.

“'common criteria compliance enabled” Disabled – 0 (Default değer 0’dır)

Bu durumda column level permission table level permission’ı ezer. Yani tabloya deny verilmesine rağmen grant verilen kolonlar sorgulanabilir.

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


Temenos 125 ülkede 1500 client’ı ile bankacılık yazılımı üreten en büyük şirket durumunda. Aşağıda detayları bulunan benchmark’ta, OLTP işlemlerinde saniyede 11592 Transaction’a erişilmiş. Test sırasında CPU utilization’ları %50’nin altında seyretmiş

[more]

Benchmark yapılan veritabanında bulunan datanın detayları;

image

OLTP Test Sonucu

image

Test sırasında CPU Utilization’ları

image

Daha detay bilgiye şu dokümandan erişebilirsiniz.

Ayrıca Benchmark Team’in videosunu da şuradan erişebilirsiniz.

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


SQL Server’da temel olarak 3 backup tipi bulunmaktadır. Bunlar Full, Differential ve Log Backup’tır. Her transaction’ın işlem bilgilerini içeren Transaction Log Backup ile istenilen bir ana dönmek mümkündür. Bu makalemde Transaction Log Backup kullanarak istenen bir zamana nasıl dönebileceğimize bakıyor olacağız.

[more]

Gerçekleştireceğim örnekte bir tabloya değişik zamanlarda kayıtlar gireceğim. Ve daha sonra bu tabloyu istediğim bir ana geri döndüreceğim.

İlk olarak bir çalışma tablosu oluşturuyorum.

create database DBLogBackup
GO
--Log Backup kullanabilmek için recovery model'i Full yapıyorum
ALTER DATABASE [DBLogBackup] SET RECOVERY FULL 
GO
Use DBLogBackup
GO
Create table tbl1(DatetimeX datetime, Value int)
GO

 

Log Backup’ların restore edilebilmesi için ilk olarak bir Full Backup’ın restore edilmesi gerekmektedir. O yüzden işlemlere başlamadan önce bir Full Backup alıyorum.

--İşlemlere başlamadan önce Full Backup alıyorum
backup database DBLogBackup to disk='D:\DBLogBackup_Full.bak'

 

Şimdi farklı zamanlarda 3 adet insert yapacağım.

insert tbl1 select GETDATE(), 1
GO
insert tbl1 select GETDATE(), 2
GO
insert tbl1 select GETDATE(), 3
GO

 

Insert işlemlerinden sonra elimde şöyle bir tablo olacak.

image

Şimdi bir Log Backup alıyorum.

--Insert işlemlerinden sonra Log Backup alıyorum
backup Log DBLogBackup to disk='D:\DBLogBackup_Log.trn'

 

Şimdi zaman bazlı restore işlemi yapacağım. Yukarıdaki resme bakıyorum ve saat 16:16:35’e dönmeye karar veriyorum ve bu ana döndüğümde tablomda sadece 1 nolu kayıtın olması gerektiğini biliyorum.

Restore işleminde ilk olarak Full Backup’ı restore edip daha sonra Log Backup’ı restore edeceğim. Eğer birden fazla Log Backup var ise istediğim ana gelene kadar bütün Log Backup’ları sırası ile restore etmem lazım. Benim 1 adet Log Backup'ım olduğu için sadece Full ve Log Backup’ı restore edeceğim.

use master
GO
--Önce Full Backup'ı restore ediyorum.
--Bu işlemden sonra Log Backup'ı da restore edeceğim için.
--   WITH NORECOVERY seçeneğini kullanıyorum.
RESTORE DATABASE [DBLogBackup] FROM  DISK = N'D:\DBLogBackup_Full.bak' 
	WITH  NORECOVERY, REPLACE
GO
--Şimdi Log Backup'ı restore ediyorum.
--İstenilen bir ana dönmek için STOPAT seçeneğini kullanıyorum
RESTORE LOG [DBLogBackup] FROM  DISK = N'D:\DBLogBackup_Log.trn' 
	WITH  STOPAT = '2011-12-04 16:16:35.000'
GO

 

Restore’den sonra tablodaki kayıtlara baktığımda;

image

16:16:35’e döndüğüm için beklediğim gibi sadece 1 nolu kayıt bulunmakta.

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


İstatistiklerin Query Plan oluşturulması aşamasında üstlendikleri rolü SQL Server’da İstatistik Kavramı adlı makalemde detaylı olarak incelemiştik. Güncel olmayan istatistiklerin yanlış Query Plan’lar oluşturulmasına dolayısıyla performans sıkıntısına sebebiyet verdiğini belirtmiştik. Bu yüzden Auto_Update_Statistics gibi istatistiklerin otomatik olarak güncellenmesini sağlayan parametrelerin aktif yapılmasının çoğu ortam için oldukça önemli olduğunun özellikle üzerinde durmuştuk.

İstatistikler güncellendikten sonra sorgular Recompile edilir. (Sorguların ReCompile edilme nedenlerine şu makaleden erişebilirsiniz.) Fakat eğer tablo update görmesine rağmen istatistiğin dağılımında çok fazla değişiklik olmuyorsa bu durumda boşu boşuna istatistiği update etmeye ve sorgunun ReCompile edilmesini tetiklemeye gerek yoktur.

Bu makalemde Index create edilirken verilen STATISTICS_NORECOMPUTE parametresi ile create edilen Index’e bağlı istatistiğin otomatik olarak update edilmesinin nasıl engellendiğini görüyor olacağız.

[more]

STATISTICS_NORECOMPUTE parametresinin varsayılan değeri OFF’dur. Yani Auto_Update_Statistics parametresi ON durumdaysa ilgili istatistiğe bağlı tabloda %20+500 kayıt update olduğunda istatistik update olacaktır.

Eğer Index create edilirken STATISTICS_NORECOMPUTE özelliği OFF yapılırsa istatistik otomatik olarak update olmayacaktır.

Şimdi bu durumu gerçekleştirmek için bir çalışma tablosu oluşturup bu tablo üzerinde birbirinin aynısı olan 2 Index create edeceğiz. Index’lerin ilkini STATISTICS_NORECOMPUTE=OFF olarak create ederken, ikincisini ON olarak create edeceğiz. Daha sonra tabloda belirli bir sayıdaki kaydı update edip istatistiklerin otomatik olarak update olup olmadığını gözlemleyeceğiz.

Üzerinde çalışacağımız çalışma tablosunu hazırlayalım.

Create Database DBTest
GO
ALTER DATABASE [DBTest] SET AUTO_UPDATE_STATISTICS ON
GO
Use DBTest
GO
Create Table tbl_Test (Col1 int identity(1,1), Col2 varchar(10))
GO
Insert tbl_Test
	select 'a'
GO 10000

 

2 index create edelim. İlkini STATISTICS_NORECOMPUTE=OFF ikincisini ON olarak create ediyoruz.

--İlk index STATISTICS_NORECOMPUTE=OFF 
Create NonClustered Index IX_1 on tbl_Test(Col2)
	WITH (STATISTICS_NORECOMPUTE=OFF)
GO

--İkinci index STATISTICS_NORECOMPUTE=ON 
Create NonClustered Index IX_2 on tbl_Test(Col2)
	WITH (STATISTICS_NORECOMPUTE=ON)
GO

 

İstatistiklerin şu anki son güncellenme tarihlerine bakalım.

--İstatistiklerin şu anki güncellenme tarihlerine bakalım
select name, STATS_DATE(object_id,stats_id) as last_update_date
from sys.stats s
where s.object_id = object_id('dbo.tbl_Test')

 

image

Şimdi tablodaki kayıtların %20+500’ünü update ederek istatistiklerin otomatik güncellenmesini sağlayalım.

--Tablonun %20+500 kaydını update edelim
update top (2500) tbl_Test set Col2='b'

--İstatistikleri kullanarak otomatik güncellenmelerini tetikleyelim.
select * from tbl_Test With (INDEX=IX_1) where Col2='x' 
GO
select * from tbl_Test With (INDEX=IX_2) where Col2='x' 
GO

 

İstatistiklerin güncellenme tarihlerine tekrar bakalım.

--İstatistiklerin güncellenme tarihine tekrar bakalım
select name, STATS_DATE(object_id,stats_id) as last_update_date
from sys.stats s
where s.object_id = object_id('dbo.tbl_Test')

 

image

Gördüğünüz gibi NORECOMPUTE özelliği OFF olan istatistik güncellenmişken ON olan istatistik güncellenmedi.

 

Tablodaki kayıtlar güncellenmesine rağmen istatistiğin dağılımında çok fazla değişiklik olmuyorsa STATISTICS_NORECOMPUTE özelliğini ON yapmayı düşünebilirsiniz. Bu şekilde istatistik boşu boşuna güncellenmeyecek dolayısıyla da sorgulara ReCompile olmayacaktır.

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


23.11.2011 tarihinde gerçekleştirmiş olduğum SQL Server Performans İpuçları başlıklık webcast’imin videosuna ve diğer dosyalarına aşağıda erişebilirsiniz.

 

 

 

Scriptler

 

Not : Webcast videosu yakın bir zamanda www.cozumpark.com portalinde de yayınlanacaktır.

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


Bu yazımda Plan Cache’de bulunan Plan’ları ve Memory’de bulunan clean data page’leri hangi komutlar ile temizleyebileceğimize bakıyor olacağız.

[more]

DBCC FREEPROCCACHE

Plan Cache’in tamamını ya da belirli bir plan’ı silmek için kullanılır. Kullanım şekilleri aşağıdaki gibidir.

Belirli bir Plan’ı Plan Cache’den silmek için;

DBCC FREEPROCCACHE (0x060006001ECA270EC0215D05000000000000000000000000);
GO

 

Tüm Plan Cache’i temizlemek için;

DBCC FREEPROCCACHE
GO

 

Daha önce bu komut ile alakalı yazdığım şu detaylı makaleyi okuyabilirsiniz.

DBCC FREESYSTEMCACHE

Belirli bir grup cache’i silmek için kullanılabilir. Örneğin “SQL Plans” ilişkili cache’lerin silmek için;

DBCC FREESYSTEMCACHE(‘SQL Plans’)
GO

 

Daha önce bu komut ile alakalı yazdığım şu detaylı makaleyi okuyabilirsiniz.

DBCC DROPCLEANBUFFERS

Clean yani checkpoint konularak disk’e yazılmış bütün page’leri cache’den temizlemek için kullanılır.

DBCC DROPCLEANBUFFERS
GO

 

DBCC FLUSHPROCINDB

Sadece bir veritabanı ile alakalı clean data page’lerin silinmesi için kullanılabilir. Örneğin aşağıdaki kod ile memory’den AdventureWorks ile alakalı clean data page’ler silinebilir.

declare @dbid int=1
select @dbid=DB_ID('AdventureWorks')
DBCC FLUSHPROCINDB(@dbid)
GO

 

İyi Çalışmalar

Turgay Sahtiyan

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