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
<<  Haziran 2017  >>
PaSaÇaPeCuCuPa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
Keywords

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


SQL Server Profiler üzerinden aldığımız trace’i T-SQL komutları ile sorgulayabilmek, istediğimiz aramaları yapmak için büyük avantaj sağlamakta. Trace sonuçlarını bir tabloya kaydederek bu sorgulamayı yapmamız mümkün. Ya da bugün anlatacağım diğer bir yöntem olan fn_trace_gettable fonksiyonu ile trace dosyasını tabloymuş gibi sorgulayabiliriz.

[more]

Örnek kullanımı aşağıdaki gibidir.

select * from fn_trace_gettable('D:\TraceFile.trc',default)

 

Gördüğünüz gibi bu şekilde where,group by gibi istediğimiz T-SQL komutlarını kullanabiliriz.

SQL Server 2005 ile beraber default trace uygulanmaya başlandı. Siz hiç bir trace başlatmasanız dahi SQL Server default olarak bir trace başlatmış durumdadır.

Default trace’in topladığı event’lerde herhangi bir değişiklik yapılamaz. Yani şu event’leri toplama, ekstra şu event’ları topla diye customize etmek mümkün değildir.

Yukarıdaki fonksiyon ile bu default trace’i de sorgulayabiliriz.

İlk olarak default trace’in nerede olduğuna bakalım.

select * from sys.traces
where is_default=1

 

Sorgu sonucu çıkan path bilgisini alıp fn_trace_gettable fonksiyonuna parametre olarak vererek table gibi sorgulayabiliriz.

select * 
from fn_trace_gettable('C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\log_39.trc',default)

 

Bir başka şekilde de default trace’in dosya adını alabiliriz.

select * from fn_trace_getinfo(default)

 

Default olarak alınan bu trace’i sp_configure ile kapatmamız mümkün. Bunun için aşağıdaki kod bloğunu kullanabilirsiniz.

EXEC master.dbo.sp_configure 'show advanced options', 1;
GO 
EXEC master.dbo.sp_configure 'default trace enabled', 0;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC master.dbo.sp_configure 'show advanced options', 0;
GO

 

Bu işlemden sonra default trace kapanacaktır. Kontrol etmek için aşağıdaki sorguyu tekrar çekebiliriz. Sorgu sonucu boş gelecektir.

select * from sys.traces
where is_default=1

 

Default trace ile toplanan verilerin bir kısmı server seviyesinde bulunan Configuration Changes ve Schema Changes raporlarında kullanılmaktadır. Örneğin herhangi başka bir çözüm geliştirmeden, DB bazında yapılan index create işlemlerinin default trace ile toplanan veriler ve Schema Changes vasıtasıyla raporlanması mümkündür. Bu yüzden default trace’i açık bırakmanızı önerebilirim.

sp_trace_setstatus ile kullanıcıların açtığı trace’leri durdurmak mümkün. Bu komutu default trace için kullanabilir miyiz?

exec sp_trace_setstatus 1,0

 

Msg 19070, Level 16, State 1, Procedure sp_trace_setstatus, Line 1
The default trace cannot be stopped or modified. Use SP_CONFIGURE to turn it off.

Gördüğünüz gibi bir hata verdi ve default trace’in durdurulamayacağını, kapatmak için sp_configure kullanılması gerektiğini detayda belirtiyor. Zaten biz de bir önceki adımda öyle yapmıştık Smile

 

İ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 2000 Desktop (MSDE) sürümünde TCP/IP ya da Named Pipes’ı enable etmek için aşağıdaki adımları kullanabilirsiniz.

[more]

  1. Start / Run kısmını açalım.
  2. Gelen ekranda svrnetcn yazıp OK’e basalım.

    msde
  3. İstediğimiz protokelleri seçip Enable tuşuna basıyoruz.
  4. Daha sonra OK’e basıp bu ekranı kapatıyoruz.
  5. Son olarak değişikliklerin geçerli olabilmesi için DB Engine Service’ini restart ediyoruz.

 

İ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’ın response vermediği durumlarda troubleshooting amacıyla DAC ile bağlantı kurulabilir. Daha önce bu konuyla ilgili bir yazı yazmıştım.

Bugünkü yazımda aktif bir DAC connection’ı olup olmadığınının script ile nasıl sorgulanacağını göreceğiz.

[more]

Aynı anda bir tane DAC connection’ı kurulabilir. Dolayısıyla bir DAC connection kurmadan önce hali hazırda kurulmuş bir DAC connection’ı var mı diye bakmamız gerekebilir.

Aşağıdaki script ile Server üzerinde bir DAC connection kurulmuş mu diye sorgulayabiliriz.

SELECT es.session_id  
FROM sys.tcp_endpoints ep 
JOIN sys. dm_exec_sessions as es ON ep.endpoint_id = es.endpoint_id 
WHERE ep.name='Dedicated Admin Connection'

Eğer bir DAC connection varsa sorgu bu connection’ın session id’sini verecektir.

Eğer herhangi bir aktif DAC connection’ı yoksa sorgu sonucu boş gelecektir.

 

İ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 2011 “Denali” ile gelen yeni özelliklerden biride, SQL Server Configuration Manager’da service in startup parameter’larını ayarlayabileceğimiz ekran. Bu ekran vasıtasıyla yeni startup parameter’ları eklemek, silmek, değiştirmek eski versiyonlara göre daha kolay hale getirilmiş.

[more]

Denali’den önceki versiyonlarda startup parametre ayarları SQL Server Configuration >> SQL Server Services >> SQL Service >> Advanced tab’ından yapılmaktaydı.

1

SQL Server 2011 “Denali” de ise startup parameter için ayrı bir tab bulunmaktadır.

2

Örneğin service’i single user mode’da açmak için Add butonunun yanındaki alana –m yazıyoruz ve sonra Add’e basıyoruz. Daha sonra service’i restart ettiğimizde yeni service single user mode’da açılacaktır.

3

Az önce tanımladığımız parametreyi kaldırmak için existing parameters listesinde –m parametresini seçiyoruz ve remove’a basıyoruz. Tabiki değişikliğin geçerli olması için service’i tekrar restart etmemiz gerekmekte.

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


Daha önceki bir çok yazımda da belirttiğim gibi, SQL Server çalıştırdığı query’ler için oluşturduğu query planları daha sonra kullanmak için Plan Cache’de yani memory de saklar. Daha sonraki kullanımlarda tekrar query plan oluşturmakla zaman kaybetmez, daha önce plan cache’e kaydettiği plan’ı kullanır ve buda performans artışı olarak bize geri döner.

Hem procedureler gibi parameterize edilebilen sorgular için hemde ad hoc gibi yani parameterize edilemeyen sorgular için query plan’lar oluşturulur ve plan cache’de saklanır. Procedure’ler için oluşturulmuş query plan’lar bize çok fazla problem çıkarmayacaktır. Çünkü bu planlar, sorguların parametrik olmalarından dolayı binlerce kez kullanılacaktır. Ama Ad Hoc sorgular içerdikleri parametreler ile cache’lenir ve aynı sorgu farklı bir parametre ile geldiğinde yeni bir plan cache oluşturulur. Dolayısıyla çok büyük ihtimalle ad hoc query’ler için oluşturulmuş query plan’lar sadece bir kez kullanılacaktır. Buda bize memory’de gereksiz yere yer işgali olarak geri dönecektir.

Bugünkü yazımda Ad Hoc için oluşturulan query plan’larının daha az yer kaplamasını nasıl sağlayacağımızı ve dolayısıyla memory’nin daha randımanlı nasıl kullanabileceğini görüyor olacağız.

[more]

Ufak bir örnekle Ad Hoc - Procedure kullanımının farkını açıklamaya çalışayım. Örneklerimde DBCC FREEPROCCACHE ve sys.dm_exec_cached_plans komutlarını kullanacağım için daha önce bu komutlar üzerine yazdığım makaleleri okumanızı tavsiye ederim.

Örneğimizde AdventureWorks’teki bir sp’yi 3 kez, birde Ad Hoc Query’i farklı where statement ile 2 kez çalıştıracağım.

--Her satır ayrı ayrı çalıştıralacaktır.
use AdventureWorks
--SP yi 3 kez çalıştır
exec dbo.uspGetEmployeeManagers 11;
exec dbo.uspGetEmployeeManagers 11; 
exec dbo.uspGetEmployeeManagers 11; 
--Ad Hoc sorguyu farklı parametre ile 2 kez çalıştır.
select * from Person.Address where City='Bothell';
select * from Person.Address where City='Portland';

 

Şimdi cache’len query plan’larını sorgulayalım.

select st.text,* 
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st
where (st.text like '%uspGetEmployeeManagers%'
or st.text like '%select * from Person.Address%')
and st.text not like '%select st.text%'

 

1(1)

Gördüğünüz gibi SP için bir query plan oluşturuldu ve 3 kez aynı plan kullanıldı. Ad Hoc query’ler için ise, her bir query için bir plan oluşturuldu.

İşte bu şekilde Ad Hoc query’lerin her biri için plan oluşturulmakta ve bir çoğu 1 den fazla kullanılmamakta. Bizim amacımız bu 1 kez kullanılan plan’ların cache’de kapladığı boyutu düşürerek memory’nin diğer objeler için kullanılmasını sağlamak.

Bu amacımıza erişmek için kullanacağımız parametre “optimize for ad hoc workloads” server parametresi. Önce bir örnek yapıp daha sonra bu parametrenin ne işe yaradığını açıklayalım.

Örneğimizde Person.Address tablosuna 5 değişik where statement’ı ile select çekeceğiz.

--Her satır ayrı ayrı çalıştıralacaktır.
use AdventureWorks
--Once Plan Cache'i Temizleyelim.
DBCC FREEPROCCACHE 
--Ad Hoc sorguyu farklı parametre ile 5 kez çalıştır.
select * from Person.Address where City='Bothell';
select * from Person.Address where City='Portland';
select * from Person.Address where City='Orlando';
select * from Person.Address where City='Montreal';
select * from Person.Address where City='Calgary';

 

Cache’lenmiş planlara bakalım.

2(1)

Beklediğimiz gibi 5 ad hoc sorgusuda ayrı ayrı cache’lendi. Asıl acı olan belki bir daha hiç kullanılmayacak bu plan’ların her birinin memory’de 24 KB yer kaplaması. Bu boyut gözünüze küçük gözükebilir “24 KB mı kurtaracak benim memory’i” diyebilirsiniz. Production ortamında bu gereksiz planların 1-2 GB’a kadar yer kapladığına gözüyle şahit olan biri olarak şunu söyleyebilirim ki, 24 KB diyip geçmemek lazım :)

Bir kez kullanılan bu ad hoc query’lerin daha az yer kaplaması için “optimize for ad hoc workloads” parametresini 1 yapalım.

sp_configure 'optimize for ad hoc workloads',1
reconfigure

 

Şimdi select cümlelerinin olduğu sorgu bloğunu tekrar çalıştıralım.

--Her satır ayrı ayrı çalıştıralacaktır.
use AdventureWorks
--Once Plan Cache'i Temizleyelim.
DBCC FREEPROCCACHE 
--Ad Hoc sorguyu farklı parametre ile 5 kez çalıştır.
select * from Person.Address where City='Bothell';
select * from Person.Address where City='Portland';
select * from Person.Address where City='Orlando';
select * from Person.Address where City='Montreal';
select * from Person.Address where City='Calgary';

 

Cache’lenen planlara bakalım.

3

Vay ki vay. Az önce 24 KB yer kaplamakta olan planlar şimdi sadece 320 byte yer kaplamakta. Yani nerdeyse 100’de 1. Süper dimi :)

Peki ama nasıl oluyor bu.

Orlando ve Montreal sorgularını 1 kez daha çalıştıralım.

select * from Person.Address where City='Orlando';
select * from Person.Address where City='Montreal';

 

4

Gördüğünüz gibi 2 defa çalıştırdığım sorguların planları “Compiled Plan” halini dönüşüp 24KB yer kaplar hale geldiler. Diğer planlarım ise “Compiled Plan Stub” tipindeler.

İşin özü şu. Bu parametre aktif hale getirildikten sonra çalıştırılan sorgular için oluşturulan query plan’ların sadece belli bir kısmı cache’lenmekte. Bu kısımda, bir sonraki aynı sorgunun çalıştırılmasında eşleştirebilmek için gerekli olan kısım. Bu kadar basit :)

Detaylı ve açıklayıcı bir örnek olduğunu düşünüyorum. Umarım faydalı bir yazı olmuştur.

Benim için best practice olan bu parametreyi sizinde sunucularınızda kullanmanızı tavsiye ederek yazımı burada sonlandırıyorum.

 

İ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


SQL Server 2008 Cluster bir ortamda node un UP olup olmadığı belirli aralıklarla check edilir. Bugünkü yazımda Windows Server level ında ve SQL Server level ında bu kontrollerin ne olduklarını ve eğer kontrol başarılı olmazsa nasıl fail edildiğini anlatıyor olacağım.

[more]

Validation amaçlı Windows Server ve SQL Server level ında farklı kontroller yapılmaktadır.

Windows Level Check

  • Pasif olan node aktif olan node a “heartbeat” sinyali göndererek UP olup olmadığını kontrol eder.

SQL Server Level Check

  • Looks Alive : SQL Server Service inin UP olup olmadığı kontrol edilir. Default kontrol sıklığı 5 sn dir. Bu değerin değiştirilmesi mümkündür. Yazımın ilerleyen bölümlerinde bunu anlatıyor olacağım.
  • ISAlive : DB Engine üzerinde “Select @@servername” gibi basit bir sql komut çalıştırılarak DB Engine in UP olup olmadığı kontrol edilir. Default kontrol sıklığı 60 sn dir ve Looks Alive gibi bunun da değiştirilmesi mümkündür. Bu kontrol ile sadece SQL Server ın ve master db nin up olup olmadığı kontrol edilir. User Database ler ile ilgili bir kontrol yapılmaz. 

SQL Server profiler dan IsAlive kontrolünün 60 sn de bir nasıl gerçekleştiğini trace edebiliriz. Bu aşamada not düşmek istediğim bir konu var. IsAlive kontrolünü Windows Cluster Service Account u yapmaktadır. Dolayısıyla bu account un SQL Server login lerinde olması ve best practise olarak sysAdmin olması önerilmektedir.

Clipboard01 

Eğer Looks Alive hata alırsa IsAlive kontrolü hemen gerçekleştirilir. Eğer IsAlive kontrolüde hata alırsa bu kontrol 5 kez daha gerçekleştirilmeye çalışır. 5 kontrolün sonucunda da hata alınmaya devam ederse SQL Server Resource grubu fail eder. Bunun neticesinde yapılan ayarlamalara göre grup restart olmaya çalışır yada diğer node a taşınmaya çalışır.

Looks Alive ve IsAlive Ayarları

Looks Alive ve IsAlive kontrollerinin ayarlandığı yer her resource grubun advance tabıdır. Örneğin SQL Server Resource Grubunun advance tab ına bakacak olursak;

Clipboard02

Interval değerlerinin resource type dan alınsın şeklinde set edildiğini görüyoruz. Bu ekranda specify value değerleri ile oynayarak bu resource gruba has interval değerleri kullanabiliriz.

Yukarıdaki örnekte olduğu gibi resource type dan bu bilgi alınsın dendiğinde ise SQL Server resource örneği için Cluster Configuration >> Resource Types >> SQL Server >> Sağ Tık >> Properties ekranından bu değerlere erişebiliriz.

Clipboard03

Bu ekranda yapacağınız değişiklikler “Use Value from Resource Type” seçeneği işaretlenmiş bütün SQL Server Resource ları için geçerli olacaktır.

 

İ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 Mirroring yapılan server lar arasında otomatik olarak heartbeat kontrolu bulunmaktadır. Principal server belirli aralıklarla mirroring server ı ping eder ve eğer cevap alamazsa bununla alakalı hata mesajı döndürür.

Otomatik olarak yapılacak bu heartbeat kontrolü için default bir frequency değeri vardır. Bu değer default olarak 10 sn dir ve principal server 10 sn de bir mirroring server a ping yaparak ayakta olup olmadığını kontrol eder.

Çok yoğun transaction alan DB lerde 10 sn lik bu değer yetmemekte ve Event Viewer a aşağıdaki TimeOut hatası düşmektedir.

The mirroring connection to "TCP://ServerName.DomainName:5022" has timed out for database "DBName" after 10 seconds without a response. Check the service and network connections.

Yapılması gereken işlem default 10 sn olan Partner Timeout değerini arttırmaktır.

Aşağıdaki script MyDB veritabanı için Partner Timeout değerini 60 sn ye set eder.

ALTER DATABASE MyDB SET PARTNER TIMEOUT 40

 

İ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


Siz hiç SQL Server Service ini –m parametresi ile single user olarak açtıktan sonra tek user hakkını alamadan başka bir user a kaptırdınız mı? Cevabınız evetse buyrun yazının devamına :) [more]

Bildiğiniz üzere bazı sistemsel işlemleri yapmak için SQL Server Service ini single user mode da açma ihtiyacı duymaktayız. Ve bu işlemi aşağıdaki kodu command prompt ta yazıp çalıştırırarak gerçekleştirmekteyiz.

…./sqlservr.exe –m

SQL Server bu parametre ile çalıştırıldığında sadece bir user ın girişine izin vermektedir. Ve eğer sizin bazı application larınız sürekli server a bağlantı kurmaya çalışıyorsa, bu tek user hakkını siz alamadan başkasına kaptırabilirsiniz.

–m "Client Application Name" ile bu tek user ın hangi application ile bağlantı kurabileceğini belirtmiş oluyorsunuz.

Örneğin servisi -m"sqlcmd" ile start ederseniz bu tek user ancak sqlcmd ile sisteme bağlanabilir.

Yada bu tek user ın SSMS-Query ile bağlanmasını istiyorsanız servisi -m"Microsoft SQL Server Management Studio - Query" şeklinde açmanız gerekmekte.

 

Bir örnek vererek yazımızı pekiştirelim ve sonlandıralım.

  1. Servisi -m"Microsoft SQL Server Management Studio - Query" ile start edelim.
  2. SSMS te new query ile bağlanmaya çalıştığımızda olduğunu göreceğiz.
  3. Bu bağlantıyı kapatalım ve osql ile deneyelim. Aşağıdaki gibi bağlanamadığınızı göreceksinizdir.
    image

 

İ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 ın cevap vermediği,yeni connection kabul etmediği ve dolayısıyla adminlerin dahi normal şartlarda bağlanamadığı durumlarda admin ler için troubleshoot amacıyla özel bir bağlantı şekli sunar. Bu bağlantı şekline Dedicated Administrator Connection (DAC) denmektedir.

Local makinadan DAC connection ı yapabilmek için herhangi bir configure ayarı yapmaya gerek yoktur. Fakat remote connection yapılabilmesi için sp_configure ile remote admin connections enable edilmesi gereklidir.

Remote admin connection ın aldığı değerler ve bu değerlerin açıklaması aşağıdaki gibidir.

Değer

Açıklama

0

DAC ile sadece local bağlantı kurulmasını işaret eder

1

DAC ile remote connection da kurulabilmesini sağlar.

Remote admin connection ın value değişikliği için aşağıdaki örnek script i kullanabilirsiniz.

sp_configure 'remote admin connections', 1;
GO
RECONFIGURE;
GO

Bu script ile DAC ile remote connection ı aktif etmiş oluyoruz.

DAC ile Remote connection kuracak user ın sysAdmin rolünde olması gereklidir. Ayrıca DAC connection 1 tane olmak zorundadır. Bir instance a haliahazırda bir DAC kurulduysa ikinci bir DAC connection talebi 17180 error koduyla reddedilir.

Bağlantı kurulurken normalde sadece ServerAdi verilirken DAC bağlantı şeklinde Admin:ServerAdi verilerek bağlantı kurulur. Örn. Admin:sahtiyan_t\SQL10Ent

SQLCMD ile command prompt tan bağlantı kurmak için ise –A parametresi kullanılmalıdır.

Örn: sqlcmd -S sahtiyan_t\SQL10Ent -E –A

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


Merhaba arkadaşlar,

Bu yazımda SQL Server 2008 ile beraber gelen Table ve BackUp larda ki compression yani sıkıştırma işlemlerinin nasıl yapılacağını anlatmaya çalışacağım.

İlk olarak neden sıkıştırma yaptığımıza değinelim. Büyük boyutlu mdf dosyalarının yedeğini aldığımızda oldukça büyük boyutlu yedek dosyaları oluşabilmektedir. Örneğin 2.5gb boyutundaki bir datanın yedeği 1 gb boyutlarında olabilmekte. Bu da bize storing problemi yaşatmakta.

Aynı şekilde compression işlemi sayesinde büyük boyutlu dataları sıkıştırarak daha az yer kaplamasını sağlayabilmekteyiz.

SQL Server bize 2 farklı konuda sıkıştırma şansı vermekte. Bunlar Tablo Sıkıştırması ve BackUp Sıkıştırması. Şimdi bunları anlatmaya çalışalım.

Table Compression

Data içerisindeki tabloları sıkıştırarak datanın daha az yer kaplamasını sağlayabiliriz. Tabloyu 2 türlü sıkıştırma şansımız var. Kayıt veya sayfa bazında. Heap,Clustered Index,Non-Clustered Index,Index Views ve Partition lar sıkıştırılabilmekte. Şimdi bu işlemi management studio üzerinde nasıl yapabileceğimizi görelim.

Örneğin AdventureWorks2008 database inde ki Sales.SalesOrderDetail tablosunda sıkıştırma yapalım. Bunun için management studio da tabloya sağ tıklayıp Storage kısmından Manage Compression a tıklayalım. Gelen ekrana next diyelim ve aşağıdaki ekrana geçelim.

cmp1

Eğer sıkıştırma yapacağımız table birden fazla partition da ise bunları liste halinde bu ekranda görebilirsiniz.

İlk olarak Row compression un bize sağlayacağı faydaya bakalım. Bunun için Compression Type kısmından Row u seçip calculate butonuna basıyoruz.

cmp2

Current Space kısmında table in şu anda kapladığı yeri, Requested Compressed Space kısmında ise Row compression yapılırsa table ın kaplayacağı yeri görebiliriz. Bu table için Row sıkıştırmasıyla %12 lik bir sıkıştırma yapabiliyormuşuz.

Şimdide Compression Type kısmından page i seçip calculate basalım. Gördüğünüz gibi page sıkıştırması bu table için daha iyi bir sonuç veriyor ve yaklaşık olarak %32 lik bir sıkıştırma sağlıyor.

Sıkıştırma tipine karar verdikten sonra next e basıyoruz ve aşağıdaki ekrana geçiyoruz.

cmp3

Buradaki seçeneklere değinecek olursak;

Create Script : Bu işlem için bir T-SQL script i oluşturmakta. Bu oluşan script i daha sonra management studio dan uygulayabiliriz.

Run immediately : Sıkıştırma işlemini hemen gerçekleştirmekte.

Schedule : Bu sıkıştırma işlemi için bir görev oluşturulabilir ve örneğin her hafta aynı gün ve saatte bu sıkıştırma işlemini tekrarlatabiliriz.

Biz bu örneğimiz için Run immediately i seçiyoruz ve next e basıyoruz. Gelen ekranda yapılacak olan sıkıştırma işlemi için bir summary bulunmakta. Bu ekranda finish e basıyoruz ve işlemi bitiriyoruz.


Table Compression işlemi management studio ile yapılabildiği gibi sql script ile de yapılabilmekte.

İlk olarak sıkıştırma yapacağımız table da ne kadar yer kazanabileceğimize bakalım.

EXEC sp_estimate_data_compression_savings
	@schema_name = 'Sales'
	,@object_name = 'SalesOrderDetail'
	,@index_id = null
	,@partition_number = null
	,@data_compression = 'ROW';

Bu script vasıtasıyla Sales.SalesOrderDetail table ında ROW table compression yapılırsa kazanılacak yerleri görebilmekteyiz.

Gelen sonuç ekranında index_id 1 olan satır clustered index i göstermekte ve her bir index için kazanılacak yerleri görebilmekteyiz.

Aynı işlemi PAGE compression type kullanarakta yapabiliriz.

Şimdi ise sıkıştırma işlemini script ile gerçekleştirelim. Bunun için aşağıdaki kod bloğunu kullanabiliriz.

ALTER TABLE [Sales].[SalesOrderDetail] REBUILD PARTITION = ALL
WITH (DATA_COMPRESSION = PAGE);


Bu arada table ları create ederken compression özelliğini verebilmekteyiz. Bu sayede her defasında table ı compress yapmamıza gerek kalmamakta. Bunun içinde table create scriptinde WITH (DATA_COMPRESSION = PAGE) komutunu kullanabiliriz.

Table compression işlemlerimiz bu kadar. Şimdi BackUp Compression işlemlerine geçelim.

BackUp Compression

Dataların yedeği alınırken sıkıştırma işlemi yapılabilir. Bu şekilde sıkıştırılmış datalar herhangi bir SQL Server 2008 Edition unda restore edilebilir.

SQL Server ın BackUp alınırken sıkıştırma yapılıp yapılmayacağını belirleyen default bir özelliği bulunmaktadır. Bu özelliğin şu andaki değerinin ne olduğunu görmek için aşağıdaki script i uyguluyalım.

EXEC sp_configure 'backup compression default'

 

 

 

 

 

Gelen sonuç ekranında config_value kısmında 0 var ise backup işlemlerinde sıkıştırma yapılmamakta,1 var ise sıkıştırma yapılmaktadır.

Bu default değeri değiştirmek için ise aşağıdaki script i uygulayabilirsiniz.

EXEC sp_configure 'backup compression default', 1
RECONFIGURE WITH OVERRIDE;


Yukarıdaki script i uyguladıktan sonra tekrar bir önceki script i uygularsak config_value nun 1 olarak değiştiğini dolayısıyla bundan sonra yapacağımız backup işlemlerinin compress edilip backup lanacağını bilebiliriz.


Şimdi 3 değişik şekilde backup alalım ve aralarındaki farkları görelim.

İlk backup ı with clause kullanarak compressed halde alacağız.

İkinci backup ta ise server default u kullanacağız. Şu an server default umuz compress seçili.

Üçüncü back upda ise with clause kullanarak uncompressed yani sıkıştırılmamış backup alacağız.

Bu işlemler için aşağıdaki script bloklarını sırasıyla uygulayınız.

--With clause ile compress edilmiş backup
BACKUP DATABASE AdventureWorks2008
TO DISK = 'D:\temp\Compressed.bak'
WITH COMPRESSION

--default compression type ile back up
BACKUP DATABASE AdventureWorks2008
TO DISK = 'D:\temp\Default.bak'

--With clause ile compress edilmemiş backup
BACKUP DATABASE AdventureWorks2008
TO DISK = 'D:\temp\No_Compressed.bak'
WITH NO_COMPRESSION

Şimdi aldığımız backup ların boyutlarına bakalım.

cmp4

Gördüğünüz gibi Default backup compress edilmiş halde çünkü server default unu buna göre ayarlamıştık.

Bu arada aklınızda bulunmasında fayda var. BackUp compression özelliği sadece SQL Server 2008 Enterprise ve Developer edition da bulunmakta. Fakat sıkıştırılmış bir backup bütün SQL Server editionlarında restore edilebilmektedir.

 

 

SQL Server 2008 de Table ve BackUp Compression işlemleri bu şekilde. Aklınıza takılan bir şey olursa yorum kısmından sorabilirsiniz.

Kolay gelsin

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


Merhabalar,

SQL Server 2000 de Service Manager üzerinden server ı start etmeye çalışırken “The service did not start due to a logon failure” hatası alınabilmekte.

Bu hata SQL Server start up account unun yada SQL Server Agent start up account unun kullanıcı adı veya şifresinin hatalı olduğunu göstermekte. Böyle bir şeyde account un şifresinin değiştirilmesine rağmen start up account unun şifresinin değişmediği durumlarda ortaya çıkmakta.

Problemi çözebilmek için start up accountlarda ki password bilgilerinin update edilmesi gerekmektedir.

Bunun içinde Control Panel/Administrative Tools/Services kısmına girilir.

Default instance için MSSQLServer, instance lar için ise MSSQL$InstanceAdi satırları bulunur.

Bulunan satıra çift tıklandıktan sonra gelen ekranda Log On sekmesine geçilip doğru password yazılır.

psw1

Bu işlemlerden sonra SQL Server problemsiz bir şekilde start olacaktır.

Kolay gelsin

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


Merhaba arkadaşlar

http://www.turgaysahtiyan.com/post/Sql-Server-2008-de-Network-Uzerinden-Baglantc4b1-%28Remote-Connection%29.aspx adresli yazımda SQL Server 2008 de Remote connection yapabilmek için hangi ayarların yapılmasını gerektiğini belirtmiştim.

Bu ayarların haricinde Express edition da bir ayar daha yapmak gerekiyor.

Bu ayarda gerekli protocol ü açmak ile ilgili.

Bunun için Programların altındaki SQL Server bölümünden SQL Server Configuration Manager i çalıştırıyoruz.

Sql Server Network Configuration ın altından server ımızı tıklıyoruz.

Yan tarafta protocol ler açılmış olması lazım. Sql Server 2008 Express edition da TCP/IP default olarak false gelmekte.

Burdan istediğimiz protocol lere sağ tıklayıp enable yapıyoruz.

rc1

Bu işlemden sonrada server i restart etmemiz gerekiyor. Bunun içinde aynı ekrandaki SQL Server Services kısmına geliyoruz ve server a sağ tıklayıp stop ve start yapıyoruz.

Kolay gelsin.

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


Merhaba arkadaşlar,

Sql 2008 kurulu makinaya network üzerinden bağlantı kurmaya çalıştığınızda aşağıdaki gibi bir hata alabilirsiniz.

“Sunucuyla bağlantı kurulurken ağ ile ilgili veya örneğe özel bir hata oluştu. Sunucu bulunamadı veya sunucuya erişilemiyor. Örnek adının doğru olduğunu ve SQL Server’ın uzak bağlantılara izin verdiğini doğrulayın.”

rc2

Bu durumda yapılması gerekenler.

1 – Kurulu olan makinada Management Studio yu açıp Server sağ tıklayıp properties/connections sekmesine geliyoruz.

rc1

Bu ekranda “Allow remote connections to this server” yazısını işaretliyoruz.

Ayrıca SQL Server ın kurulu olduğu makinadaki firewall ın kapatılması yada 1433 nolu port un açılması gerekmektedir.

Bu ayarları yaptıktan sonra bağlantıda bir problem yaşanmayacaktır.

Kolay gelsin

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


Merhaba arkadaşlar.

SQL Server 2000 e internet üzerinden ulaşmak için aşağıda ki adımları yapmamız gerekmektedir.

Çok önceden internetten indirdiğim bu dökümanı hangi sayfadan aldığımı bilmediğimden ne yazık ki kaynak gösteremiyorum.

Yapılacak işlemler aşağıdadır.

1.Server Network Utility

1.Başlat >> Programlar >> Microsoft SQL Server >> Server Network Utility (*) SQL Server Desktop Edition için ‘Server Network Utility’ uygulamasına ‘C:\Program Files\Microsoft SQL Server\80\Tools\Binn\svrnetcn.exe’ yolundan erişilebilir.

sql1

2.TCP/IP aşağıdaki gibi sağ tarafta değilse sağ tarafa taşınır. Bunu yapmak için TCP/IP seçildikten sonra ortadaki ‘enable >>’ butonuna basılır.

sql2

3.TCP/IP seçildikten sonra
(1)’Properties’ butonuna basılır.Açılan pencerede
(2)’default port’ kısmının ‘1433’ olduğuna emin olduktan sonra
(3)’OK’ butonuna basılır.
‘SQL Server Network Utility‘ penceresinde ‘Apply’ ve ‘OK’ butonlarına sırayla basılır.

sql3

 

2.Client Network Utility

1. Başlat >> Programlar >> Microsoft SQL Server >> Client Network Utility(*) SQL Server Desktop Edition için ‘Client Network Utility’ uygulamasına ‘C:\WINDOWS\system32\cliconfg.exe’ yolundan erişilebilir.

sql4

2. TCP/IP aşağıdaki gibi sağ tarafta değilse sağ tarafa taşınır. Bunu yapmak için TCP/IP seçildikten sonra ortadaki ‘enable >>’ butonuna basılır.

sql5

3. TCP/IP seçildikten sonra
(1)’Properties’ butonuna basılır.Açılan pencerede
(2)’default port’ kısmının ‘1433’ olduğuna emin olduktan sonra
(3)’OK’ butonuna basılır.

sql6

4.’Alias’ kısmında kayıt yoksa ‘Add…’ butonuna , kayıt varsa (aşağıdaki gibi) ‘Edit…’ butonuna basılır.

sql7

5.Açılan pencerede Sol taraftaki seçeneklerden TCP/IP seçilir. (2) ‘Server Alias’ kısmına static IP adresi veya varsa domain ismi yazılır.‘Server Name’ kısmının doğru ve ‘Dynamically determine port’ seçeneğinin seçili olduğundan emin olduktan sonra (3) ‘OK’ butonuna basılır. ‘SQL Server Client Network Utility‘ penceresinde ‘Apply’ ve ‘OK’ butonlarına sırayla basılır.

sql8

 

Kolay gelsin

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