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

Başlıktanda rahatça anlaşılacağı üzere bugün göreceğimiz sorgu ile Server’da bulunan bütün login’lerin server ve database role’lerini sorgulayacağız.

[more]

Server Role kapsamında aşağıdaki role’leri sorgulayacağız.

ServerRole         Description
========       ============
sysadmin           System Administrators
securityadmin     Security Administrators
serveradmin       Server Administrators
setupadmin        Setup Administrators
processadmin     Process Administrators
diskadmin          Disk Administrators
dbcreator           Database Creators
bulkadmin          Bulk Insert Administrators

Database Role kapsamında ise aşağıdaki gibi database rollerini sorgulayacağız.

1

Dolayısıyla bu role’ler dışındaki örneğin object bazında verilmiş yetkilendirmeler bu sorgulama dışındadır.

create table #ServerLogins (name sysname, is_disabled int, type_desc varchar(60), create_date datetime, modify_date datetime, server_roles varchar(500), db_roles varchar(max))
create table #DBLevelPermissions (DBName sysName, DBRole sysname, MemberName sysName)
declare @str1 varchar(max)=''
	   ,@str2 varchar(max)=''
	   ,@name sysname
	   ,@is_disabled int
	   ,@type_desc varchar(60)
	   ,@create_date datetime
	   ,@modify_date datetime

select lgn.name as Name, SUSER_NAME(rm.role_principal_id) as RoleName
into #ServerLevelPermissions
FROM SYS.SERVER_ROLE_MEMBERS RM, SYS.server_principals LGN  
WHERE RM.role_principal_id >=3 AND RM.role_principal_id <=10 AND  
  RM.member_principal_id = LGN.principal_id  
      			
select name,is_disabled,type_desc,create_date,modify_date
into #ServerPrincipals
from sys.server_principals
where type not in ('C','R')
and name not in ('sa','##MS_PolicyTsqlExecutionLogin##','##MS_PolicyEventProcessingLogin##','NT AUTHORITY\SYSTEM'
	,'NT AUTHORITY\NETWORK SERVICE','NT SERVICE\MSSQLSERVER','NT SERVICE\SQLSERVERAGENT')
order by name

exec sp_msforeachdb 'use ?; 
	insert #DBLevelPermissions
	select ''?'',g.name as DBRole, u.name as MemberName
		from sys.database_principals u, sys.database_principals g, sys.database_role_members m  
	where g.principal_id = m.role_principal_id  
		and u.principal_id = m.member_principal_id  
	order by 1, 2'

declare CursorX cursor for
select name,is_disabled,type_desc,create_date,modify_date from #ServerPrincipals
open Cursorx
fetch from Cursorx into @name,@is_disabled,@type_desc,@create_date,@modify_date
while @@FETCH_STATUS=0
begin
  set @str1=''
  select @str1+=RoleName+',' from #ServerLevelPermissions where name=@name
  if @str1<>''
    select @str1=SUBSTRING(@str1,0,len(@str1))
  
  set @str2=''
  select @str2+=DBName+'('+DBRole+')'+',' from #DBLevelPermissions where MemberName=@name
  if @str2<>''
    select @str2=SUBSTRING(@str2,0,len(@str2))
    
  insert #ServerLogins
    select @name,@is_disabled,@type_desc,@create_date,@modify_date,@str1,@str2
  
  fetch next from Cursorx into @name,@is_disabled,@type_desc,@create_date,@modify_date
end
close CursorX
deallocate CursorX
   
select * from #ServerLogins order by name

drop table #ServerPrincipals
drop table #ServerLevelPermissions
drop table #ServerLogins
drop table #DBLevelPermissions

 

Sorgu sonucu ise şu şekilde birşey olacaktır.

2

 

İ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


Genellikle sipariş listesi, cari hesap hareketi listesi gibi raporlarda her bir satır için kümülatif toplam hesabı yapmak raporun okunulurluğunu dahada arttırmaktadır. Bugünkü yazımda herhangi bir fetch gibi döngü kullanmadan bu kümülatif toplam kolonunu nasıl hesaplatabileceğimizi görüyor olacağız.

[more]

Örneğinde AdventureWorks DB’sinde 676 nolu müşterinin siparişlerini listeletelim.

select SalesOrderID,OrderDate,TotalDue 
from sales.SalesOrderHeader oh
where CustomerID=676
order by SalesOrderID

 

1

Benim istediğim ise son kolonda kümülatif bir toplam kolonu yapmak ve her satırdaki tutarın toplanarak devam etmesini sağlamak. Aşağıdaki gibi;

2

Bunun için Common Table Expressin ve row_number() kullanacağım. Dolayısıyla bu konular ile ilgili yazdığım aşağıdaki makalelerimi okumanızı tavsiye ederim.

http://www.turgaysahtiyan.com/post/SQL-Server-2008-de-Common-Table-Expressions(CTE).aspx

http://www.turgaysahtiyan.com/post/SQL-Server-2008-Ranking-Fonksiyonlarc4b1-(row_number-e28093-rank-e28093-dense_rank-e28093-ntile-e28093-partition-by).aspx

Şimdi sorgumuza geçelim.

WITH tblCTE
AS
(
select SalesOrderID,OrderDate,TotalDue 
,ROW_NUMBER() OVER (ORDER BY SalesOrderID) AS RowNumber
from sales.SalesOrderHeader oh
where CustomerID=676
)
SELECT SalesOrderID,OrderDate,TotalDue
  ,(Select SUM(t2.TotalDue) as SumX 
		from tblCTE t2 
		where t2.RowNumber<=t1.RowNumber
    ) as CumTotalDue 
FROM tblCTE t1

 

Rapor sonucuna baktığımızda istediğimiz sonuca erişmiş olduğumuzu görüyoruz.

3

 

İ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


Bu sıralar suspect duruma düşmüş DB’lerin nasıl kurtarılabileceği üzerine oldukça fazla soru görmekteyim. Bu konu üzerine Paul Randal’ın yazdığı aşağıdaki yazıyı paylaşmak istiyorum.

Not olarak şunu düşmek istiyorum ki, eğer bir database suspect durumdaysa sakın detach etmeyin, yoksa bir daha attach etme şansınız olmayabilir.

http://sqlskills.com/blogs/paul/post/TechEd-Demo-Creating-detaching-re-attaching-and-fixing-a-suspect-database.aspx

 

İ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


Bugün size okuyucularımdan biri olan Aşkın Bey’in paylaştığı SSD performans değerlerinden bahsedeceğim. Track Disk’te bulunan veritabanlarını SSD’ye geçirdikten sonra yaptıkları performans değerlerini değerlendireceğiz.

[more]

Bildiğiniz gibi Track Disk’ler üzerinde yapılan sorgulamalarda en çok süreyi Seek Time yani okuyucu kafanın datayı okumak için diskte üzerinde kanumlanması almaktadır. SSD yani Solid State Diskler de ise herhangi bir kafa mekanizması yoktur ve memory gibi çalışmaktadır. Dolayısıyla Track Disk’lere oranla çok ciddi performans artışı sağlamaktadır.

Solid State Diskler ile ilgili daha fazla detaya aşağıdaki linkten erişebilirsiniz.

http://www.chip.com.tr/blog/worldpc/solid-state-disk-ssd-nedir_3969.html

Aşkın Bey yaklaşık 2 hafta kadar önce SATA Track Disk’te bulunan database’ini SSD üzerine taşımış. Ve aldığı sonuçlar aşağıdaki gibi.

 

Eski Disk

Yeni Disk

 

Seagate GB0250EAFJF 7200 rpm SATA 250 Gb. Disk.

OCZ 50GB Vertex Limited Edition Serisi Sata2 SSD  / 50 GB

Sorgu 1 – Bir çok tablonun joinlendiği bir sorgu

8 dk. 21 sn

38 sn.

Sorgu 2 – Tek tablodan select çeken bir sorgu

63 sn.

17 sn.

 

Gerçekten ciddi performans artışları gerçekleşmiş. Hatta bazı makalelerde 100 kata kadar performans artışı sağlayan kullanıcılarada rastlamak mümkün.

Aşkın Bey’e paylaştığı bilgiler için tekrar teşekkür etmek istiyorum.

 

İ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


Data bütünlüğü açısından DBCC CheckDB’nin nasıl kullanılacağını şu yazımda görmüştük. Bugünkü yazımda DBCC CheckDB yapıldığında Error Log’a kayıt olarak düşen rolled back ve rolled forward mesajlarının neler olduklarına ve bu konuyla alakalı herhangi bir aksiyon alınmasının gerekip gerekmediğini tartışıyor olacağız.

[more]

Konuyu bir örnekle açıklamakta fayda var.

Yeni bir DB ve table create edelim.

create database DBCCDeneme
GO

Use DBCCDeneme
GO

Create table tblDeneme(a int, b varchar(10))
GO

 

Bir transaction başlatıp sonlandırmayalım.

begin tran
insert tblDeneme select 1,'a'

 

Şimdi başka bir query window açıp bu DB için DBCC CheckDB başlatalım.

DBCC CheckDB('DBCCDeneme')

 

Şimdi error log’a baktığımızda ;

1

1 transactions rolled back in database 'DBCCDeneme' (24). This is an informational message only. No user action is required.

Gördüğünüz gibi bir transaction’ın rolled back yapıldığı bilgisi gözükmekte. Bunun nedeni ise şu;

DBCC CheckDB işlemi bir internal snapshot üzerinden gerçekleştirilir ve data consistency açısından bu internal snapshot oluşturulurken active olan transaction’lar rolled forward yada rolled back yapılır. Ana DB üzerinde herhangi bir işlem yapılmaz. Dolayısıyla bu mesaj için bir aksiyon alınmasına gerek yoktur.

Dediğimizi doğrulamak için transaction’ı başlattığımız yerde commit edip select çekelim.

commit tran

select * from tblDeneme

 

2

Görüldüğü gibi DB üzerinde bulunan transaction’a herhangi bir şey olmamış :)

 

İ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


SQL Server 2008 R2 Best Practices Analyzer, instance inizi best practice değerlerine göre kontrol edip size önerilerde bulunan bir tooldur. Bugünkü makelemizde bu tool un kullanımını inceliyor olacağız.

Best practise kavramını biraz açalım. Best practise bahsi geçen teknolojik ürün üzerinde kabul görmüş genel konfigurasyonlardır. Örneğin SQL Server ı ele alacak olursak; Database Data ve Log dosyalarını performans amaçlı farklı fiziksel disklerde bulundurmak best practice dir. Ya da TempDB Data file larını core cpu sayısı kadar yapmak gene bir SQL Server Best Practice dir.

Microsoft SQL Server 2005 Best Practise tool unu release ettikten sonra 2008 Best Practice tool u için çok uzun süre bekledi ve ancak 18.06.2010 tarihinde release edebildi. Çok uzun bir süre 2008 ortamlarımızda hala 2005 best practice tool unu kullanmak zorunda kalırken artık şimdi elimizde 2008 best practice tool u var. Ve bu yazımızda bu tool un detaylarına iniyor olacağız.

[more]

Makalemi 4 başlık altında toplayacağım

  • Kurulum
  • MBCA’ya İlk Bakış
  • MBCA ile Network’teki Bir DB Server’a Bağlanma
  • Tarama Sonucu Bulguları

Kurulum


Öncelikle tool u bilgisayarımıza kuralım. Best Practice Analyzer 2008 R2, Microsoft Baseline Configuration Analyzer (MBCA) 2.0 çatısı altında çalışmaktadır. Dolayısıyla ilk olarak bu tool u bilgisayarımıza kuralım. Download için aşağıdaki MSDN linkini kullanabilirsiniz. Bu linkten sisteminiz için uygun olan tool u indirip kurunuz.

http://www.microsoft.com/downloads/details.aspx?FamilyID=1B6E9026-F505-403E-84C3-A5DEA704EC67&amp;displaylang=en&displaylang=en

Eğer kurulumda “Microsoft Baseline Configuration Analyzer 2.0 is not supported on this SKU.” gibi bir hata alıyorsanız işletim sistemi uyumluluğunu kontrol etmenizde fayda var. Çünkü MBCA sadece aşağıdaki OS larda support edilmektedir.

Supported Operating Systems: Windows 7 Enterprise; Windows 7 Professional; Windows 7 Ultimate; Windows Server 2003; Windows Server 2003 R2 (32-Bit x86); Windows Server 2008; Windows Server 2008 R2; Windows Vista Business; Windows Vista Enterprise; Windows Vista Ultimate

MBCA kurulumunu bitirdikten sonra şimdi Best Practice Analyzer 2008 R2 kurulumuna geçebiliriz. Download için aşağıdaki Microsoft linkini kullanabilirsiniz. Bu linkten sisteminiz için uygun olan tool u indirip kurunuz.

http://www.microsoft.com/downloads/details.aspx?FamilyID=0FD439D7-4BFF-4DF7-A52F-9A1BE8725591&amp;displaylang=en&displaylang=en

Gene Supported Operating Systems kısmını kontrol ederek operating sisteminizin desteklenenler listesinde olduğunu teyit etmenizde fayda var.

Supported Operating Systems: Windows 7; Windows Server 2003; Windows Server 2008; Windows Server 2008 R2; Windows Vista

 

MBCA’ya İlk Bakış


MBCA’yı çalıştıralım. Home ekranında SQL Server 2008 R2 BPA’yı seçelim.

1

Enter Parameters ekranında server ve instance bilgilerini dolduralım. İlk örneğimde kendi makinam üzerinde bulunan DB Engine’i analiz edeceğim.

Daha sonra analiz edilmesini istediğimiz service’lerin yanındaki enable seçeneklerini işaretleyelim.

2

Start Scan yazısına tıkladığımızda MBCA seçtiğimiz DB Server’ı analiz etmeye başlayacak ve ekran görüntüsü bu analiz süresi boyunca aşağıdaki gibi olacaktır.

3

Analiz işlemi tamamlandığında aşağıdaki gibi bir sonuç ortaya çıkacaktır.

4

Ekran detayına inersek;

1 – Select Report Type

Collected Data seçeneği seçilirse tarama sonuçlarını ağaç yapısında görebiliriz.

5

Biz bu makalemizde genelde Results seçeneğini kullanacağız.

2 – Noncompliant – All

All seçeneğinde analiz sonucu best practise değerlerimize uygun olan kayıtlarda gösterilir. Noncompliant seçeneğinde gösterilmez.

6

3 – Export Report

Tarama sonucunu XML file olarak export edebilirsiniz.

4 – Filter

Tarama sonucu çıkan ifadelerde belirli bir ifadeyi aratabilirsiniz. Örneğin aşağıdaki örnekte tempdb ifadesi aratılmıştır.

7

5 – Arrange by

Tarama sonucu çıkan bulguları neye göre dizeceğimizi belirler. Severity, önem derecesini göstermektedir. Genelde bu kritere göre dizim yapmakta fayda vardır. İstersek Category’e görede dizme yapabiliriz.

8

6 – Tarama Sonucu

Tarama sonucu çıkan bulguları bu ekranda görebilir, bu bulguların detayına erişerek Etki(Impact) ve Resolution(Çözüm) bilgilerine ulaşabiliriz.

9

MBCA ile Network’teki Bir DB Server’a Bağlanma


MBCA ile Network üzerindeki bir DB Server’a ayar yapmadan bağlanmaya çalışırsak aşağıdaki gibi bir hata mesajı ile karşılaşmamız mümkün.

10

Hata mesajının detayında da görebileceğiniz gibi MBCA yı kullanan kullanıcın remote makinada local admin olması gerekmektedir. Ayrıca remote makinada powershell’in enable edilmesi gerekmektedir.

Bunun için hem local hemde remote makinalarda powershell’de şu komutların çalıştırılıp powershell’in remote kullanıma açılması gerekmektedir.

1. Enable-PSRemoting –f

2. winrm set winrm/config/winrs `@`{MaxShellsPerUser=`"10`"`}

11

Bu ayarlamalar yapıldıktan sonra analiz işlemi problemsiz gerçekleştirilecektir.

12

Tarama Sonucu Bulguları


Makalemin bu bölümünde tarama sonucu çıkan bazı önemli bulguların detayına inip, bu bulgunun neden geldiğine, neye sebep olabileceğine ve nasıl düzeltilebileceğine bakıyor olacağız.

Engine - Database files and backup files exist on the same volume

13

Best practice olarak disklerde bir sıkıntı olma ihtimalinden dolayı data ve log dosyalarının farklı fiziksel disklerde bulundurulması önerilir. Aynı şekilde alınan backup’larında farklı bir fiziksel diskte bulundurulması best practice’dir. Bu error sonucu bize data ve backup dosyalarının aynı diskte olduğunu göstermekte.

Engine – SQL Server tempdb database not configured optimally

14

Best practice olarak tempdb datafile larının core CPU sayısı kadar yapılması önerilir. Yani 4 CPU lu 8 core lu bir sunucuda tempdb datalarını birbirlerine eşit boyutta 8 adet dosya yapmanızı öneririm.

Engine – Authentication Mode

15

Authentication Mode’un Windows Authentication olması best practice’dir. Lakin hemen hemen her firmada SQL Login’ler ile login olunmaya çalışıldığı için bu bulgu üzerinde çok durmayabiliriz.

Engine – Database consistenct check not current

16

Issue kısmında belirtilen DB’ler için hiç DBCC CHECKDB yapıldığını göstermektedir. DBCC CheckDB DB consistency ve integrity’sini kontrol eden bir sistem komutudur. Best practice olarak periyodik olarak bu kontrolün DB’ler üzerinde yapılması önerilir.

Engine – Backups outdated for databases

17

Bu bulguda uzun zamandır backup alınmayan DB’ler hakkında bilgi verilmektedir. Diskte ve DB’de oluşabilecek problemlerden dolayı her daim iyi bir backup policy üzerinde çalışma yapılması gerekmektedir.

Engine – Databases using simple recovery model

18

Point in time recovery ve disaster anında minimum data kaybı ile sıyrılmak için production DB’lerinde full recovery model kullanılması önerilmektedir. Bu bulguda simple recovery model kullanan DB’ler raporlanmaktadır.

 

ÖZET


Best practise bahsi geçen teknolojik ürün üzerinde kabul görmüş genel konfigurasyonlardır. SQL Server 2008 R2 Best Practices Analyzer ile Database Server’larınızı periyodik olarak kontrol edip, best practice’lere uymayan durumları sorgulayabilirsiniz.

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


Bugünkü makalemde bana çok sorulan sorulardan birine değineceğim. “Bir tablomdan örneğin cari kart tablomdan bir cari silindiğinde bu durumdan mail yoluyla haberdar edilebilir miyim, yada yeni bir cari insert edildiğinde bu bilgi mail olarak gelebilir mi?”

Cevabımız tabiki evet. Mantalitemiz SQL Server da yapamayacağınız şey yok. :)

[more]

Bu alert işlemini trigger vasıtasıyla mail göndererek yapacağız. Önce sunucumuzda database mail ayarlarını yapacağız. Daha sonra tabloya bir insert trigger yazarak yeni bir kayıt insert edildiğinde insert edilen kayıdın bilgilerini mail olarak göndereceğiz.

İlk olarak database mail ayarlarını yapmamız gerekmekte. Bunun için aşağıdaki makaledeki adımları izleyebilirsiniz.

http://www.turgaysahtiyan.com/post/SQL-Server-2008-den-Mail-Gonderme.aspx

Deneme yapmak için bir table create ediyoruz.

create table userTable(name varchar(100), surName varchar(100))
GO

 

Daha sonra bu table için bir insert trigger yazıyoruz. Bu trigger table’a yeni bir insert olduğunda insert edilen kullanıcının ad ve soyad bilgisini bize mail olarak gönderecek.

CREATE TRIGGER dbo.trgUserTable ON  dbo.userTable
   AFTER INSERT
AS 
BEGIN
  declare @msg varchar(max)=''
		 ,@subjectx varchar(100)='Yeni user''lar oluþturuldu'
  select @msg += name+' '+surName + ', ' from inserted
  set @msg=substring(@msg,0,len(@msg))
  
  EXECUTE msdb.dbo.sp_send_dbmail           
			 @profile_name = 'Control'            
			,@recipients = 'aaa@bbb.com'
			,@body = @msg
			,@subject = @subjectx
			,@body_format = 'TEXT'  
			,@importance    ='HIGH'  
END
GO

 

Son olarak deneme yapmak için bir insert yapıyoruz.

insert userTable 
  select 'Turgay','Sahtiyan'

 

Mailiimizi kontrol ettiğimizde insert işlemi ile ilgili mail’in geldiğini görüyoruz.

image

Bu mantıkta update ve delete trigger’larıda yazarak güncellenen ve silinen kayıtlarıda kontrol edebilmemiz mümkün.

 

İ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


Bugün size basit ama bana çok sorulan bir konudan bahsetmek istiyorum. Bildiğiniz gibi SQL Server’da otomatik backup alınabilmektedir. Örneğin her akşam saat 20.00’de backup alınsın diye bir job tanımlanabilir. Bu job’ı işleten servis ise SQL Server Agent’tır ve SQL Server’ın Express yani ücretsiz sürümünde SQL Server Agent’ı bulunmamaktadır.

Bugünkü makalemde SQL Server Express sürümünde Windows Scheduler servisini kullanarak nasıl otomatik backup alınacağını anlatıyor olacağım.

[more]

Express edition dışındaki SQL Server sürümlerinde SQL Server Agent servisi kullanılarak otomatik backup işleminin nasıl yapılacağı ile alakalı yazdığım aşağıdaki makaleyi okuyabilirsiniz.

http://turgaysahtiyan.com/post/SQL-Server-2008-de-Otomatik-BackUp-icin-Job-Olusturma-(Schedule).aspx

Giriş paragrafında da belirttiğim gibi Express sürümlerinde SQL Server Agent bulunmamaktadır. Dolayısıyla otomatik backup işlemini Windows’un kendi scheduler servisi ile yapacağız.

Yapacağımız işlem aslında basit. Backup alacak script i hazırlayıp bu scripti sqlcmd ile windows scheduler servisi vasıtasıyla istediğimiz zamanlar tetikleyeceğiz. Bu arada windows scheduler task SQL Server Agent gibi verilen taskları belirli periyotlarda çalıştırmaya yarar.

Ben bugünkü örneğimi Windows Server 2008 Standart ve SQL Server 2005 Express üzerinde gerçekleştireceğim. Diğer edition’larda ufak ekran farklılıkları olmakla birlikte işin ana mantığı aynıdır.

Şimdi adımlarımıza geçelim.

Backup almak istediğimiz DB için backup script i hazırlıyoruz.

BACKUP DATABASE [AdventureWorks]
TO DISK = N'C:\AdventureWorksDailyBackup.bak'
WITH INIT
GO

 

Bu script i "E:\SQLBackups\DailyBackup.sql" olarak kaydediyoruz.

Windows scheduler task’ında bu dosyayı aşağıdaki komutlar eşliğinde çalıştıracağız. İlk komut DB Server’a windows authentication bağlanmakta, 2.komut ise belirli bir SQL Login ile bağlanmakta. Hangisi sizin için uygunsa onu kullanabilirsiniz. Ben ilkini kullanacağım.

sqlcmd -S serveradi\instanceadi -i "E:\SQLBackups\DailyBackup.sql"

sqlcmd -S serveradi\instanceadi -U BackupAdmin -P sifre -i "E:\SQLBackups\DailyBackup.sql"

Bu arada serveradi\instance adi kısmını kendi server bilgilerinize göre düzenleyiniz. Instance adı Express sürümlerde genelde SQLExpress olmaktadır. Tam olarak ne olduğuna SQL Server Configuration Manager’dan bakabilirsiniz.

Şimdi Task tanımlamalarına başlamak için Task Scheduler’ı açıyoruz.

1

Yani bir task tanımlamak için Task Scheduler Library >> Create Task a basıyoruz.

2

General kısmını aşağıdaki gibi ihtiyacımıza göre dolduruyoruz.

3

Schedule kısmında hangi sıklıkla bu task’ın çalışacağını belirliyoruz. Bizim taskımız her gece 11 de çalışacak.

4

Action kısmında New Action’a basarak işi yapacak işlemi tanımlıyoruz. Bu işlemimiz bir program çalıştıracak. Browse kısmında sqlcmd.exe’sini seçiyoruz. Bu exe genelde C:\Program Files\Microsoft SQL Server\90\Tools\binn klasöründe bulunmaktadır. Son olarakta Add arguments kısmına daha önce yazdığım komutlardan hangisi size uyuyorsa o komutun sqlcmd den sonraki kısmını yazıyoruz. Örneğin aşağıdaki gibi;

sqlcmd -S serveradi\instanceadi -i "E:\SQLBackups\DailyBackup.sql"

Ok’e basarak bu ekranı kapatıyoruz.

5

Artık Scheduler’ımız hazır. Scheduler’a sağ tıklayarak manuel olarak tetikliyoruz.

6

Task çalışmasını bitirip sonlandığında ilgili klasöre backup’ların alındığını göreceğiz.

 

İ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


Database lerin integrity kontrollerinin (veritabanı bütünlüğü) DBCC komutları ile nasıl yapılacağını SQL Server – DBCC Komutlarıyla Veritabanı Bütünlüğü Kontrolü – DBCC CHECKDB adlı yazımda incelemiştik.

Peki bir database için en son ne zaman CheckDB yapıldığını nasıl kontrol edeceğiz.

Bunun için kullanacağımız DBCC komutu DBCC INFO

[more]

Örneğin AdventureWorks DB’si için en son ne zaman DBCC CHECKDB yapıldığına bakmak için

DBCC DBINFO('AdventureWorks') WITH TABLERESULTS 
GO

 

Result set te gelen dbi_dbccLastKnownGood field kısmındaki value değeri bize en son ne zaman checkDB yapıldığını göstermekte.

1

Görüldüğü gibi AdventureWorks DB si için en son 04.10.2010 tarihinde CheckDB ile integrity kontrolü gerçekleştirmişim.

Sizinde Production DB’lerinizi periyodik olarak CheckDB ile kontrol etmenizi, hangi DB’lerin en son ne zaman CheckDB yapıldığını sorgulayarak uzun süredir yapılmıyorsa yapmanı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


SQL Server’daki Locking işlemlerinden en can sıkıcı olan deadlock’tır. Ölümcül kitlenme olarak nitelendirdiğimiz deadlock’ta birbirlerinin kaynaklarını kilitleyen 2 session sonunda ilerleyemez duruma gelir ve SQL Server bu session’dan rollback maliyeti en az olanı victim seçerek rollback yapar ve diğer session’ın işine devam etmesini sağlar.

Bugünkü makalemizde sistemimizde oluşan deadlock’ları Data Collector ile nasıl monitor edebileceğimizi görüyor olacağız.

[more]

Bu yazımda deadlock’ın detaylarını inmiyorum. Belki bu konuda daha sonra bir makale yayınlarım. Bugünkü ana konumu oluşan deadlock’ları nasıl izleyeceğimiz.

Bunun için Data Collector yapısını kullanacağız. ServerSide trace kullanarak deadlock işlemlerini data collector’un datawarehouse’unda toplayacağız ve buradan raporlayacağız.

Daha önce Data Collector’de serverside trace nasıl tanımlanır konulu makalemi incelemenizi öneririm. Çünkü bugün çok fazla detaya girmeyeceğiz.
http://www.turgaysahtiyan.com/post/SQL-Server-2008-e28093-Performance-Data-Collection.aspx
http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Trace-Collection-Set-ile-Server-Side-Trace-Kullanc4b1mc4b1.aspx

İlk olarak SQL Server Profiler üzerinden trace file’ımızı oluşturalım. Daha sonra bu sql dosyayı data collector sisteminde execute edeceğiz ve Deadlock Collection Set’ini create etmiş olacağız.

SQL Server Profiler’ı açıp Events Selection kısmından aşağıdaki seçenekleri seçiyoruz.

1

Daha sonra bu trace’i data collection set’i için SQL Script olarak kaydetmek için File >> Export >> Script Trace Definition >> For SQL Trace Collection Set kısmından bir isim vererek kaydediyoruz.

2

Kaydettiğimiz script aşağıdaki gibi bir yapıda olacaktır.

USE msdb
GO

BEGIN TRANSACTION
BEGIN TRY

-- Define collection set
-- ***
-- *** Replace 'SqlTrace Collection Set Name Here' in the following script
-- *** with the name you want to use for the collection set.
-- ***
DECLARE @collection_set_id int;
EXEC [dbo].[sp_syscollector_create_collection_set]
    @name = N'SqlTrace Collection Set Name Here',
    @schedule_name = N'CollectorSchedule_Every_15min',
    @collection_mode = 0, -- cached mode needed for Trace collections
    @logging_level = 0, -- minimum logging
    @days_until_expiration = 5,
    @description = N'Collection set generated by SQL Server Profiler',
    @collection_set_id = @collection_set_id output;
SELECT @collection_set_id;

-- Define input and output varaibles for the collection item
DECLARE @trace_definition xml;
DECLARE @collection_item_id int;

-- Define the trace parameters as an XML variable
SELECT @trace_definition = convert(xml, 
N'

  
    
    
    
  


  
</FILTERS>

');

-- Retrieve the collector type GUID for the trace collector type
DECLARE @collector_type_GUID uniqueidentifier;
SELECT @collector_type_GUID = collector_type_uid FROM [dbo].[syscollector_collector_types] WHERE name = N'Generic SQL Trace Collector Type';

-- Create the trace collection item
-- ***
-- *** Replace 'SqlTrace Collection Item Name Here' in the following script
-- *** with the name you want to use for the collection item.
-- ***
EXEC [dbo].[sp_syscollector_create_collection_item]
   @collection_set_id = @collection_set_id,
   @collector_type_uid = @collector_type_GUID,
   @name = N'SqlTrace Collection Item Name Here',
   @frequency = 900, -- specified the frequency for checking to see if trace is still running
   @parameters = @trace_definition,
   @collection_item_id = @collection_item_id output;
SELECT @collection_item_id;

COMMIT TRANSACTION;
END TRY

BEGIN CATCH
ROLLBACK TRANSACTION;
DECLARE @ErrorMessage nvarchar(4000);
DECLARE @ErrorSeverity int;
DECLARE @ErrorState int;
DECLARE @ErrorNumber int;
DECLARE @ErrorLine int;
DECLARE @ErrorProcedure nvarchar(200);
SELECT @ErrorLine = ERROR_LINE(),
       @ErrorSeverity = ERROR_SEVERITY(),
       @ErrorState = ERROR_STATE(),
       @ErrorNumber = ERROR_NUMBER(),
       @ErrorMessage = ERROR_MESSAGE(),
       @ErrorProcedure = ISNULL(ERROR_PROCEDURE(), '-');
RAISERROR (14684, @ErrorSeverity, 1 , @ErrorNumber, @ErrorSeverity, @ErrorState, @ErrorProcedure, @ErrorLine, @ErrorMessage);
END CATCH;
GO

 

Kaydettiğimiz bu dosyayı deadlock monitoring yapacağımız sunucuda execute ediyoruz ve Data Collection Set’in oluşmasını sağlıyoruz.

Oluşan Data Collection seti start ediyoruz.

3

Tanımlamalarımız tamam. Şimdi bir deadlock oluşturup bunu veri topladığımız yani datawarehouse’un olduğu sunucuda raporlamaya çalışacağız.

Deadlock oluşturmak için bir tablo create ediyoruz ve 2 farklı session’da sırası ile şu işlemleri yapıyoruz.

CREATE TABLE lockDeneme (a varchar(1))
GO

 

Script çalıştırma adımları

  1. 1.Sessionda
    begin tran
    insert lockdeneme select 'x'
  2. 2.Sessionda
    begin tran
    insert lockdeneme2 select 'y'
  3. 1.Sessionda
    select * from lockdeneme2
  4. 2.Sessionda
    select * from lockdeneme

 

4.adımı uyguladığımızda Database Engine belli bir süre bekleyecek ve daha sonra 2.Session’ı victim seçerek rollback edecektir.

Msg 1205, Level 13, State 45, Line 1
Transaction (Process ID 273) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Deadlock oluştu. Şimdi bu oluşan deadlock bilgisini Collection Set’i tetikleyerek datawarehouse’a gönderelim.

4

Job’lar işlerini tamamladıktan sonra oluşan bu deadlock bilgisi Datawarehouse’a gitmiş olacaktır.

Şimdi bu datewarehouse’u sorgulayarak deadlock bilgilerini görmeye çalışalım.

select convert(xml,TextData),duration,td.trace_info_id,ti.source_id,td.*,ti.*,si.* 
from core.source_info_internal si
left join snapshots.trace_info ti on ti.source_id=si.source_id
left join snapshots.trace_data td on td.trace_info_id=ti.trace_info_id and td.snapshot_id=ti.last_snapshot_id
where si.instance_name = 'EBTCLUSCBSQL01'
and textdata like '%deadlock%'
order by starttime desc

 

5

Gördüğünüz gibi deadlock bilgileri toplanmış. İlk kolon olan TextDataXML’de bilgisine tıklayarak XML içeriği görüntüleyelim.

<deadlock-list>
  <deadlock victim="process9045048">
    <process-list>
      <process id="process9045048" taskpriority="0" logused="236" waitresource="RID: 23:1:115:2" waittime="4234" ownerId="1662737575" transactionname="user_transaction" lasttranstarted="2010-09-07T10:40:35.470" XDES="0x4fa2af970" lockMode="S" schedulerid="7" kpid="18048" status="suspended" spid="273" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2010-09-07T10:40:40.100" lastbatchcompleted="2010-09-07T10:40:35.470" clientapp="Microsoft SQL Server Management Studio - Query" hostname="SAHTIYAN_T" hostpid="6792" loginname="EBT\U02664" isolationlevel="read committed (2)" xactid="1662737575" currentdb="23" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">
        <executionStack>
          <frame procname="adhoc" line="1" sqlhandle="0x020000001e3eb416128ab587ebf6de659c302be988772bd6">
select * from lockdeneme     </frame>
        </executionStack>
        <inputbuf>
select * from lockdeneme
    </inputbuf>
      </process>
      <process id="process90274c8" taskpriority="0" logused="444" waitresource="RID: 23:1:1561:0" waittime="6392" ownerId="1613777247" transactionname="user_transaction" lasttranstarted="2010-09-06T17:37:07.733" XDES="0x2e687e3b0" lockMode="S" schedulerid="4" kpid="4912" status="suspended" spid="515" sbid="0" ecid="0" priority="0" trancount="3" lastbatchstarted="2010-09-07T10:40:37.950" lastbatchcompleted="2010-09-07T10:40:33.303" clientapp="Microsoft SQL Server Management Studio - Query" hostname="SAHTIYAN_T" hostpid="6792" loginname="EBT\U02664" isolationlevel="read committed (2)" xactid="1613777247" currentdb="23" lockTimeout="4294967295" clientoption1="671090784" clientoption2="390200">
        <executionStack>
          <frame procname="adhoc" line="1" sqlhandle="0x020000002e50cb2999e2e5110a2e4c518d57e2fc6611f33f">
select * from lockdeneme2     </frame>
        </executionStack>
        <inputbuf>
select * from lockdeneme2    </inputbuf>
      </process>
    </process-list>
    <resource-list>
      <ridlock fileid="1" pageid="115" dbid="23" objectname="EBTDBA.dbo.lockDeneme" id="lock3cf165780" mode="X" associatedObjectId="72057594043170816">
        <owner-list>
          <owner id="process90274c8" mode="X" />
        </owner-list>
        <waiter-list>
          <waiter id="process9045048" mode="S" requestType="wait" />
        </waiter-list>
      </ridlock>
      <ridlock fileid="1" pageid="1561" dbid="23" objectname="EBTDBA.dbo.lockdeneme2" id="locka4cba80" mode="X" associatedObjectId="72057594043236352">
        <owner-list>
          <owner id="process9045048" mode="X" />
        </owner-list>
        <waiter-list>
          <waiter id="process90274c8" mode="S" requestType="wait" />
        </waiter-list>
      </ridlock>
    </resource-list>
  </deadlock>
</deadlock-list>

 

Sarı işaretli satırlarda gördüğünüz gibi session’ların çalıştırdıkları ve deadlock’a sebep olan query’leri görebiliyoruz.

Son olarak deadlock graph’ı nasıl çıkartabileceğimize bakarak yazımızı sonlandıralım.

Bunun için az önce baktığımız xml çıktıyı xdl uzantısı ile kaydediyoruz.

Kaydettiğimiz dosyayı çift tıklayıp açtığımızda deadlock graph’a erişmiş olacağız.

6

7

 

Sizde sisteminizde oluşan deadlock’ları bu yöntemle serverside olarak toplayıp monitor edebilirsiniz.

 

İ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


Locking işlemlerini nasıl trace edebileceğimizi SQL Server Profiler ile Bloklanan İşlem Raporu (Blocked Prosess Report) adlı yazımda görmüştük. Bu trace tanımlamasını yaptıktan sonra bu işlemi Data Collector’etoplatmak için Server Side Trace tanımlaması yapmaya başladım. Lakin işlemi yaparken bir hata aldım. Bugünkü yazımda bu hatayı ve çözümünün ne olduğunu görüyor olacağız.

[more]

Trace’i server side olarak toplatmak için aşağıdaki ilgili script’i execute ettiğimizde

/*************************************************************/
-- SQL Trace collection set generated from SQL Server Profiler
-- Date: 03/09/2010  17:17:40
/*************************************************************/

USE msdb
GO

BEGIN TRANSACTION
BEGIN TRY

-- Define collection set
-- ***
-- *** Replace 'SqlTrace Collection Set Name Here' in the following script
-- *** with the name you want to use for the collection set.
-- ***
DECLARE @collection_set_id int;
EXEC [dbo].[sp_syscollector_create_collection_set]
    @name = N'ServerSideLockTrace',
    @schedule_name = N'CollectorSchedule_Every_15min',
    @collection_mode = 0, -- cached mode needed for Trace collections
    @logging_level = 0, -- minimum logging
    @days_until_expiration = 5,
    @description = N'Collection set generated by SQL Server Profiler',
    @collection_set_id = @collection_set_id output;
SELECT @collection_set_id;

-- Define input and output varaibles for the collection item
DECLARE @trace_definition xml;
DECLARE @collection_item_id int;

-- Define the trace parameters as an XML variable
SELECT @trace_definition = convert(xml,
N'<ns:SqlTraceCollector xmlns:ns="DataCollectorType" use_default="0">
<Events>
  <EventType name="Errors and Warnings">
    <Event id="137" name="Blocked process report" columnslist="3,15,51,4,12,24,32,60,64,1,13,41,14,22,26" />
  </EventType>
</Events>
</ns:SqlTraceCollector>
');

-- Retrieve the collector type GUID for the trace collector type
DECLARE @collector_type_GUID uniqueidentifier;
SELECT @collector_type_GUID = collector_type_uid FROM [dbo].[syscollector_collector_types] WHERE name = N'Generic SQL Trace Collector Type';

-- Create the trace collection item
-- ***
-- *** Replace 'SqlTrace Collection Item Name Here' in the following script
-- *** with the name you want to use for the collection item.
-- ***
EXEC [dbo].[sp_syscollector_create_collection_item]
   @collection_set_id = @collection_set_id,
   @collector_type_uid = @collector_type_GUID,
   @name = N'ServerSideLockTrace',
   @frequency = 900, -- specified the frequency for checking to see if trace is still running
   @parameters = @trace_definition,
   @collection_item_id = @collection_item_id output;
SELECT @collection_item_id;

COMMIT TRANSACTION;
END TRY

BEGIN CATCH
ROLLBACK TRANSACTION;
DECLARE @ErrorMessage nvarchar(4000);
DECLARE @ErrorSeverity int;
DECLARE @ErrorState int;
DECLARE @ErrorNumber int;
DECLARE @ErrorLine int;
DECLARE @ErrorProcedure nvarchar(200);
SELECT @ErrorLine = ERROR_LINE(),
       @ErrorSeverity = ERROR_SEVERITY(),
       @ErrorState = ERROR_STATE(),
       @ErrorNumber = ERROR_NUMBER(),
       @ErrorMessage = ERROR_MESSAGE(),
       @ErrorProcedure = ISNULL(ERROR_PROCEDURE(), '-');
RAISERROR (14684, @ErrorSeverity, 1 , @ErrorNumber, @ErrorSeverity, @ErrorState, @ErrorProcedure, @ErrorLine, @ErrorMessage);
END CATCH;
GO

 

Aşağıdaki gibi bir hata almaktayız.

Msg 3903, Level 16, State 1, Line 58
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.
Msg 14684, Level 16, State 1, Line 71
Caught error#: 14684, Level: 16, State: 1, in Procedure: sp_syscollector_create_collection_item, Line: 144, with Message: Caught error#: 6908, Level: 16, State: 1, in Procedure: -, Line: 1, with Message: XML Validation: Invalid content. Expected element(s): 'Filters'. Location: /*:SqlTraceCollector[1]

Hatanın sebebi data collector setini tanımlayacak olan SP’nin gelen XML kod’da Filter bekliyor olması. Yani biz trace i hazırlarken filter verdiğimizde herhangi bir hata ile karşılaşmadan collection seti hazırlayabiliyorken, filter vermezsek yukarıdaki gibi bir hata ile kaşılaşıyoruz.

Hatayı çözmek için yapacağımız işlem basit. XML kod’da filter varmış gibi göstermek için şu şekilde bir şekilde değişiklik yapacağız.

SELECT @trace_definition = convert(xml,
N'<ns:SqlTraceCollector xmlns:ns="DataCollectorType" use_default="0">
<Events>
  <EventType name="Errors and Warnings">
    <Event id="137" name="Blocked process report" columnslist="3,15,51,4,12,24,32,60,64,1,13,41,14,22,26" />
  </EventType>
</Events>
<Filters>
</Filters>
</ns:SqlTraceCollector>
');

Bu değişiklik yaptıktan sonra query’i tekrar execute ettiğimizde Collection Set’in hatasız oluşturulduğunu göreceğiz.

 

İ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


SQL Server’da yazılan uygulamalarda en çok canımızı sıkan noktalardan biride locking yani kilitlenme durumlarıdır. Kullanıcı tablonun birine transaction açar ve update-insert işlemine başlar, diğer kullanıcı bu tabloya erişmek istediğinde ilk kullanıcının işlemini bitirip COMMIT etmesine bekler. İşte buna locking denir. Hatta bu 2 kullanıcı birbirlerine lock’larsa olay deadlock yani ölümcül kitlenmeye kadar gidebilirki bu durumda SQL Server kullanıcılardan birini victim seçer ve rollback yapar.

Isolation Level yada nolock kullanımı ile en azından select işlemlerinde locking i çözmek mümkündür. Fakat bu durumda dirty yani kirli data okunma durumu ortaya çıkar.

Biz bugünkü yazımızda bu yaşanan locking işlemlerini nasıl monitör edip yorum yapabileceğimizi görüyor olacağız.

[more]

Monitor işlemini SQL Server Profiler kullanarak yapacağız. Ve kullanacağımız Event Blocked Prosess Report. Bu event kaç sn den fazla süren blocking leri raporlayacağını server parametrelerinden biri olan blocked process threshold dan almaktadır. Bu parametrenin default değeri 0 sn dir. Yani ne kadar sürdüğüne bakılmaksızın her locking işlemini loglar.

Microsoft best practise olarak bu değeri 5 sn’ye set etmemizi öneriyor. 5 sn den fazla süren lock işlemleri performans problemi çıkartabilir diye threshold u 5 sn yapıyoruz.

Bu değişikliği sp_configure sistem prosedürüne kullanarak yapıyoruz.

sp_configure 'show advanced options',1 ; 
GO 
RECONFIGURE; 
GO 
sp_configure 'blocked process threshold',5 ; 
GO 
RECONFIGURE; 
GO

 

Şimdi gelin locking loglamayı yapacak trace’i hazırlayalım.

Daha öncede bahsettiğim gibi bu loglama için Blocked Prosess Report event’ini kullanacağız. Parametremiz 5 sn olduğu için 5 sn den uzun süren locking işlemlerini loglamasını bekliyoruz.

SQL Server Profiler’ı çalıştırıp Event kısmından Blocked Process Report ‘ u seçiyoruz. Show all columns kısmını tıklayıp bütün kolonların bilgisini toplamak için işaretliyoruz.

1

Bu SQL Server Profiler’ı aşağıdaki script ile de oluşturabilirsiniz. Bu script C:\LockingTrace.trn file’ını oluşturacaktır.

-- Create a Queue
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 5 

-- Please replace the text InsertFileNameHere, with an appropriate
-- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension
-- will be appended to the filename automatically. If you are writing from
-- remote server to local drive, please use UNC path and make sure server has
-- write access to your network share

exec @rc = sp_trace_create @TraceID output, 0, N'C:\LockingTrace.trn', @maxfilesize, NULL 
if (@rc != 0) goto error

-- Client side File and Table cannot be scripted

-- Set the events
declare @on bit
set @on = 1
exec sp_trace_setevent @TraceID, 137, 3, @on
exec sp_trace_setevent @TraceID, 137, 15, @on
exec sp_trace_setevent @TraceID, 137, 51, @on
exec sp_trace_setevent @TraceID, 137, 4, @on
exec sp_trace_setevent @TraceID, 137, 12, @on
exec sp_trace_setevent @TraceID, 137, 24, @on
exec sp_trace_setevent @TraceID, 137, 32, @on
exec sp_trace_setevent @TraceID, 137, 60, @on
exec sp_trace_setevent @TraceID, 137, 64, @on
exec sp_trace_setevent @TraceID, 137, 1, @on
exec sp_trace_setevent @TraceID, 137, 13, @on
exec sp_trace_setevent @TraceID, 137, 41, @on
exec sp_trace_setevent @TraceID, 137, 14, @on
exec sp_trace_setevent @TraceID, 137, 22, @on
exec sp_trace_setevent @TraceID, 137, 26, @on


-- Set the Filters
declare @intfilter int
declare @bigintfilter bigint

-- Set the trace status to start
exec sp_trace_setstatus @TraceID, 1

-- display trace id for future references
select TraceID=@TraceID
goto finish

error: 
select ErrorCode=@rc

finish: 
go

 

Threshold değerimiz 5 sn olduğu için 5 sn’den fazla sürecek lock lar trace file a düşecektir.

Şimdi 5 sn den fazla sürecek bir lock oluşturalım. Yapacağımız adımlar şunlar

  1. Deneme yapmak için bir table create ediyoruz.
    create table lockDeneme(a varchar(1))
  2. 1. Query ekranında begin tran ile bir insert işlemi başlatıp commit etmeyerek table’ı lock’lı bırakıyoruz.
    begin tran
    insert lockDeneme select '1'
  3. 2.Query ekranında da select çekmeye çalışacağız ve lock lı olduğu için sonucu alamayacağız. Ve bunun da profiler’e düşmesini bekliyoruz.
    select * from lockdeneme

Adımları uyguladıktan sonra profiler’a geçiyoruz ve belli bir süre bekliyoruz.5 sn dolduktan sonra her 5 saniyede bir blocking report’un geldiğini göreceksiniz.

2

Text data kısmında bu block işlemi ile alakalı detaylar tamamını bulabiliriz.

3

Blocked-process ve blocking-prosess diye 2 başlık göreceksiniz. Bunlar block ‘ a sebep olan ve block’a maruz kalan işlemlerin detaylarını içermekte. Her 2 işleminde session id lerini görmemiz mümkün. Bunun ötesinde en güzeli her 2 işleminde query detaylarını görebilmekteyiz.

 

Locking işlemlerini SQL Server Profiler üzerinden monitor edip aksiyon olmak DBA olarak ana görevlerimizden birisi. Sizde bu makaledeki adımları uygulayarak uygun bir Profiler hazırlayabilirsiniz. Ayrıca bu profiler script ini Data Collector üzerinden Server Side Trace olarak tutabilmekte mümkün. Bu işlemin nasıl yapılacağı ile alakalı daha önce yazdığım aşağıdaki makaleyi inceleyebilirsiniz.

http://turgaysahtiyan.com/post/SQL-Server-e28093-Trace-Collection-Set-ile-Server-Side-Trace-Kullanc4b1mc4b1.aspx

 

İ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


Instance ım birinde çalışan Data Collector Disk Usage Data Collection Set’inde aşağıdaki gibi bir hata almaktaydım.

SSIS error. Component name: DFT - Collect Query 0, Code: -1073450974, Subcomponent: SSIS.Pipeline, Description: SSIS Error Code DTS_E_PROCESSINPUTFAILED. The ProcessInput method on component "Raw File Destination" (48) failed with error code 0xC020205D while processing input "Raw File Destination Input" (53). The identified component returned an error from the ProcessInput method. The error is specific to the component, but the error is fatal and will cause the Data Flow task to stop running. There may be error messages posted before this with more information about the failure.

Hata ile ilgili yaptığım araştırmalar sonucunda hatanın Cache Directory’de tutulan cache dosyalarının bozulmasından kaynaklandığı sonucuna ulaştım.

[more]

Bu bozulma şu durumlarda gerçekleşebilir;

  • Data Collector bir exception ile karşılaştığında
  • Data Collector cache file a yazarken disk’in dolması
  • Bir firmware yada driver problemi

Bu hata için çözümümüz ise Cache dosyaları cache’lendikleri klasörden silmek. Bu silme işleminide aşağıdaki adımlar eşliğinde yapabiliriz.

  1. Management >> Data Collection item’ına sağ tıklayıp Properties’i açıyoruz. 
    1
  2. Cache Directory kısmından cache dosyaların nerede tutulduğunu öğreniyoruz. 
    2
  3. Bu directory’e gidip cache dosyaları siliyoruz. 
    3
  4. Disk Usage collection Set’ini Collect and UploadNow işlemi ile tekrar çalıştırıyoruz ve hata almadan job’ların problemsiz çalıştığını görüyoruz. 
    4

İ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


SQL Server’da trace flag’lar bazı davranışları değiştirmek için kullanılırlar. Örneğin 3226 trace flag’ı ile backup işlemlerinin sonucunun error log’a yazılması engellenebilir. Bu konuyla alakalı yazdığım makaleye buradan erişebilirsiniz.

Bugünkü yazımda bir trace flag’ın açık olup olmadığını, global mi session bazındamı açıldığı gibi bilgilerini nasıl sorgulayacağımıza bakacağız. Bu işlem için DBCC TRACESTATUS komutunu kullanacağız.

DBCC TRACESTATUS(-1)

 

[more]

Şimdi bu komutu deneyelim. 2 tane trace flag’i açacağız. İlkini global olarak 2. yi ise session bazında açıp daha sonra status’lerini sorgulayacağız.

DBCC TRACEON(3622,-1) -- Global
DBCC TRACEON(3604) -- Session

 

Şimdi Trace Flag’leri sorgulayalım.

DBCC TRACESTATUS(-1)

 

1


Rapor sonucunda görüldüğü gibi 2 trace flag açık durumdaymış. Ayrıca 3622’nin global, 3604’ün ise session bazında açıldığını görüyoruz.

Trace flag’ların listesi için aşağıdaki BOL dokümanını okuyabilirsiniz.

http://msdn.microsoft.com/en-us/library/ms188396.aspx

 

İ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