Cumulative update package 5 for SQL Server 2014

Microsoft SQL Server 2014 için Cumulative Update Paketi  yayınladı.(build number: 12.0.2456.0)  Paket aşağıdaki linkde bulunan düzeltmeleri içermektedir.

http://support.microsoft.com/kb/3011055/en-us#hfi   

SQL Server 2014 kullanıcıları Update paketini Live ortamda kullanmadan önce test ortamında uygulamaları önerilmektedir.

En son güncelleme daha önce yayınlanmış tüm güncellemeleri  ve tüm düzeltmeleri içermektedir.

Bu update aşağıda bulunan SQL Server sürümlerini kapmaktadır.

• Microsoft SQL Server 2014 Enterprise
• Microsoft SQL Server 2014 Developer
• Microsoft SQL Server 2014 Standard
• Microsoft SQL Server 2014 Express
• Microsoft SQL Server 2014 Web
• SQL Server 2014 Reporting Services
• Microsoft SQL Server 2014 Business Intelligence

Update işlemi uygulandıktan sonra bilgisayar restart edilmelidir. SQL Serverımızın versiyon bilgisini aşağıdaki T-SQL kodu kullanarak görebiliriz.

SELECT @@Version as ProductName, 
SERVERPROPERTY('ServerName') AS 'ServerName', 
SERVERPROPERTY('Edition') AS 'Edition', 
SERVERPROPERTY('ProductVersion') AS 'ProductVersion' 

Always-on, Replication, Failover Cluster ve Mirroring kullanıcılarının yukarıda bulunan indirme linkindeki açıklamaları okuyarak uygulamaları önerilir.

SQL Saturday 359 -5(Monitoring and Assessing SQL Server with extended events)

5.seminer ise Batuhan YILDIZ'ın yaptığı Extended Event semineriydi.  Bugüne kadar SQL Profiler kullandığım için extended eventları hiç kullanmamıştım ancak Microsoft bir sonraki versiyonda Profilerı kaldıracağı için Extended Event konusuna bundan böyle daha sık eğilmemiz gerekecek gibi gözüküyor.

Extended Event ilk olarak 2008 versiyonu ile karşımıza çıkmış ancak o zaman bir arayüze sahip olmadığı için DBAler için pek tercih edilmemiş. 2012 versiyonu ile bir arayüze kavuşmuş.

Extended Events ile SQL Server sorgularını takip edebilir, performans analizi yapabilir, deadlock problemlerini çözebilir ve T-SQL statement’larını debug edebilirsiniz.

Extentet event bir wizarda sahip. Wizard kullanarak istediğimiz session oluşturup kullanabiliriz. Bu wizarda yardımı ile capture edeceğimiz veriyi seçerek analiz imkanını çok kolay bir şekilde yapabiliyoruz. Bu konu ile ilgili ileriki günlerde derinlemesine bir makale yazmak istiyorum

SQL Saturday 359 -4 (Write Quick, Readable and High Performance Queries Using Window Function)

4.seminer ise kitaplarından tandığımız İsmail ADAR hocanın semineriydi. Window functionları konusunda örnekler yapıldı.

Bu konuda bütün fonskiyonları yazmayacağım sadece Ranking Fonksiyonları yani derecelendirme fonksiyonları üzerine bir şeyler yazmak istiyorum.

Ranking fonksiyonları bir veri kümesi üzerinde kriter belirterek veri kümesinin gruplara bölünmesini sağlayan ve her gruba geçici bir numara veren fonksiyonlardır. SQL Server ile kullanılmaya başlayan ranking fonksiyonlarını şu şekilde listeleyebiliriz.

ROW_NUMBER:Veri kümesindeki gruplanmış her değer için numerik ve artan bir değer üretir. Bu değer istenirse tüm veri kümesi bir parça olarak alınabilir yada veriler belli kolona göre gruplanabilir.

SELECT FirstName,LastName ROW_NUMBER() OVER (ORDER BY SalesYTD
DESC) AS 'Row Number',
SalesYTD,JobTitle
FROM Sales.vSalesPerson

SELECT FirstName,LastName ROW_NUMBER() OVER (PARTITION BY JobTitle
ORDER BY SalesYTD
DESC) AS 'Row Number',
SalesYTD,JobTitle
FROM Sales.vSalesPerson

RANK:fonksiyonuda ROW_NUMBER fonksiyonu gibi bir veri kumesi icinde

gruplama yaparak her bir veriyi belirtilen kritere gore siralama yaparak

numaralandirir. ROW_NUMBER fonksiyonundan farki ise siralama yaparken ayni degere sahip olan

satirlara ayni sira numarasi vermesidir. RANK fonksiyonunda siralama icin kullandigimiz alandaki ayni

degerler icin ayni sira numarasi kullanilir.

select i.ProductID,p.Name,i.LocationID,i.Quantity,
RANK() OVER (PARTITION BY i.LocationID ORDER BY i.Quantity DESC) AS
'RANK'
FROM
Production.ProductInventory i INNER JOIN Production.Product p
ON i.ProductID=p.ProductID

DENSE_RANK fonksiyonu RANK fonksiyonundan farklı olarak aynı sıra numarası verilse bile bir sonraki gelen kayda sıra numarası verilirken araya tekrar eden kayıt sayısı kadar boşluk ekleyen fonksiyondur.

select i.ProductID,p.Name,i.LocationID,i.Quantity,
DENSE_RANK() OVER (PARTITION BY i.LocationID ORDER BY i.Quantity DESC) AS
'RANK'
FROM
Production.ProductInventory i INNER JOIN Production.Product p
ON i.ProductID=p.ProductID where
i.ProductID in(436,461,443)

 

NTILE fonksiyonu diğer ranking  yani derecelendirme fonksiyonlarından farklı olarak veri kümesini gruplarken her bir grup içinde en fazla kayıt olacağı bilgisini dışarıdan parametre olarak almaktadır.

SELECT p.FirstName, p.LastName,s.SalesYTD,a.PostalCode,
NTILE(5) OVER(ORDER BY SalesYTD DESC) AS 'Ntile'
FROM Sales.SalesPerson s
INNER JOIN
Person.Person p ON s.BusinessEntityID=P.BusinessEntityID
INNER JOIN Person.Address a on a.AddressID=p.BusinessEntityID

SQL Saturday 359 -3( How Latch Contention Affects the Performance? )

3. Katıldığım seminer Turgay SAHTİYAN hocanın How Latch Contention Affects the Performance? adlı semineriydi. 

Bu seminerde öncelikle olarak latch nedir ve lock nedir ve aralarındaki farklar konuşuldu. 

Latch nedir tanımına bakacak olursak birden fazla process memoryde bulunan bir page'i değiştirmek isterse SQL Server ilk isteyen process için latch koyar.  Diğer processlerinde işlem yapmasını engeller. Aynı anda bir fazla process page üzerinde değişiklik yapabilseydi page tutarlılığı bozulurdu. Bu koyulan Latch'e PageLatch_EX adı verilir.

Aynı işlem bir page'in diskten memorye getirilmesi sırasındada olur. Bunada PageIOLatch_EX adı verilir.

DB serverda birden fazla Cpu varsa aynı objeye paralel olarak erişen process sayısı artacaktır. Aynı objeye birden fazla process erişmek isteyebileceğinden dolayı latch yaşanması kaçınılmazdır.

Latchler ile locklar birbirine oldukça benzerler ancak aralarında bir fark vardır. SQL Server lock'ı transaction tamamlanana kadar koyarken latch'i fiziksel operasyon bitene koyar.  İlgili page'de fiziksel işlem bitince latch kalkarken lock transaction tamamlanıncaya kadar durur.

Latchler üzerinde kullanıcılar hiçbir işlem yapamazken locklar üzerinde transaction level ile oynayarak değişiklikler yapabilirler.

Latch analizi için  Sys.dm_exec_wait_stats ve sys.dm_exec_latch_stats DMVleri kullanılırken  lock analizi için ise sys.dm_tran_locks ve sys.dm_exec_sessions DMVleri kullanılır.

Ayrıca Latch Contentiondan Hash partitioning yöntemi üzerine konuşuldu. Bir bankada DBA olarak çalışıyoruz. 1400 tane bankamatik şubemiz var. Her yapılan işlem bir identity kolonda veya bir sequence nesnesinden bir numara alarak ID kolonuna üzerine veri olarak işlenmektedir. Bu kolon clustered indexdir.

Her yapılan işlemi her zaman son page üzerine yapılacağı için latch contention'dan kaçmak nerdeyse imkansızdır.

Bundan kaçmak için Clustered Index'te değişiklik yaparak BankamatikID ekleyebiliriz. Ancak bu durumda  leading kolon olarak non-sequential bir kolon seçildiği için Page Split ve index fragmentation ile karşılaşılacağız.

Burada çözüm tablodaki bir kolon üzerinden oluşturulan bir hash value üzerine partitioning yapmaktır. Bu şekilde gelen insert’ler sıralı olarak farklı partition’lara dağılacak ve hep aynı page’e erişim olmayacağından dolayı contention çözümlenmiş olacaktır.

SQL Saturday 359 -2( How to understand if the storage is a problem on the database server)

İkinci seminerde Türkiye'de SQL Serverın en büyük gurularından birisi olan Yiğit AKTAN hocanın Troubleshooting: How to understand if the storage is a problem on the database server? Adlı seminerine katıldım. Şimdiye kadar teknik açıdan olsun sürükleyicilik açısından olsun  en iyi seminerlerden birisiydi.

 

 

Seminerde Sql Serverda yaşanabilecek IO problemleri ve bunların çözüm yöntemleri üzerine konuşuldu.  Bir işlem bir kayıt üzerinde değişlik yapacağı zaman ilk olarak kaydın olduğu page'i bulmak için memorye bakar. Burda yoksa  diskten okuyarak memory'e alır. SQL Server kayıtları direk diskten okumaz. Öncelikle memory'e alır. Burdan okur. Okuma devam ederken bir başka işlem bu page erişmek isterse ilk işlemin okuma işlemini bitirmesini bekler. Buna PageIOLatch_EX denir.  Aynı anda iki işlem aynı page'e erişip memory'e alamaz.

Bu PageIOLatch_EX problemlerinin nasıl tespit edileceği ve nasıl çözümler bulunacağı üzerine çok güzel bir seminer oldu.

I/O problemlerinde DBAler öncelikli olarak çözümü storage yöneticileri ile konuşarak bulmak isterler. Ancak genellikle çözüm bulunamaz. Çünkü storage yöneticileri hatalarını genellikle kabul etmezler. Bu gibi durumlarda problemin ne olduğu ve çözümün ne olacağı konusunda demo yapıldı.

Çözüm Örnekleri

1. IO hızınızı artırmak ve hızı yüksek bir altyapıya sistemimizi taşımak. Disk yapımızı SSD ile değiştirmek.(Bu ilk etapta pek kolay gözükmüyor.)
2. Eksik Indexleri yeniden oluşturmak
3. Kullanılmayan Indexleri silmek
4. İstatiktikleri Update Etmek
5. MDF ve LDF disklerini ayrı diskler üzerine koymak ve TempDB veritabanını hızlı disklere taşımak.

Seminerde  sp_WhoIsActive  stored prosedürü üzerine bilgi verildi. Bu prosedür  Adam Machanic tarafından yazılmış. Sistemde o anda çalışan activiteleri görüntülüyor.

SQL Saturday 359 -1(SQL Server 2014: HA and DR Solutions)

Bu yazı dizimde 06.12.2014 tarihinde gittiğim SQL Saturday gününde katıldığım seminerlerden bahsetmek istiyorum. SQL Saturday  konusunda kısaca bilgi verecek olursak SQL Pass tarafından her Cumartesi dünyanın bir şehrinde düzenlenen bu etkinlikde  SQL Server konusunda hem lokal hemde uluslararası konusunda derin deneyime sahip uzmanlar eğitimler veriyorlar.

Türkiye'de 4.sü düzenlenen bu eğitim Microsoft Türkiye ofisinde yapıldı. 5 ayrı salonda toplam  30 'a yakın seminerden oluşmakta. Bende bu  etkinliği 4 senedir katılıyorum.

4 senedir gittiğim bu etkinlikde her yıla oranla katılımcı sayısı arttığını görmek çok sevindirici. Ancak Microsoft'un verdiği destek konusunda baya sıkıntılı. Kötü bir organizasyon ,kayıt yaptırıp kapılarda kalan insanlar, 45 dakika beklenen yemek sırası, salonların ısıtma ve havalandırma problemi gibi bir sürü problem.  Ancak gerek SQL Server Öncülerinin gösterdiği çaba gerekse eğitmenlerin teknik bilgisi ve tecrübeleri hepsine bedel diye düşünüyorum.

Katıldığım seminerlerden bahsedecek olursam ilk  katıldığım seminer Levent OKTAR hocanın SQL Server 2014: High Availability and Disaster Recovery Solutions semineriydi.

 

SQL Server ilk versiyonlarından bu yana bu konu ile ilgili bazı çözümler sunmakta.   Ancak son yıllarda iş sürekliliğinin sağlanması ve felaket senaryoları konusunda önemin artması ile birlikte database üreticileride  bu konularda baya geliştirmeler yapmışlardır.

1. Replication
2. Log Shipping
3. Mirroring
4. Failover Cluster
5. Always-on

Seminerde bu 5 konu üzerinde teorik bilgiler anlatıldı.  Ancak 2012 ile birlikte gelen Always-On demosu yapılabildi. 2012 öncesinde High Availability konusunda ve Disaster Recovery konusunda ilk 4 madde birlikte kullanılarak çözümler geliştirilmekteydi. 2012 ile birlikte gelen Always-on ile birlikte bu 4 teknolojinin birlikte kullanılması ile elde edilen HADR çözümlerini tek başına yapabilmektedir.

 

Bu yapı bize Server seviyesinde koruma, Sql Server seviyesinde koruma sağlayabildiği gibi database seviyesinde koruma ve client connection seviyesinde koruma sağlar.

Always-on konusunda kısaca değinecek olursak öncelikle AlwaysOn Availability Groups arka planda Windows Failover Clustering teknolojisi üzerinde çalışmaktadır. Ancak Failover Cluster yapısı gibi ortak disk alanı olmasına gerek yoktur. İster shared disklere ister lokal diskler üzerinde çalıştırılabilmektedir.

Always-On kurulumunda öncelikle kurulacak server üzerinde yukarıdada belirttiğim gibi Windows Failover Cluster teknolojisi kurulu olmalıdır.   Windows Server Failover cluster yapısı kurulumunda 2 serverda da aynı versiyon işletim sistemi kurulu olmalıdır.  Aynı updateler yapılmış olmalıdır.Ancak failover cluster yapısında olduğu gibi  ortak bir shared disk alanı bulunmasına gerek yoktur.

Bu yapıda yer alacak tüm serverlar aynı domain içinde bulunmalıdır. Ayrıca tüm serverlar Failover Cluster yapısına eklenmelidir.   Üzerilerinde domain yapısı kurulu olmamalıdır. Tüm veritabanları Full Recovery modda olmalıdır.

Avalibality groupu senkron ve asenkron olarak iki farklı  şekilde tanımlayabiliyoruz.  Senkron modda  bir transactionın başarılı olması için tüm replicalarda tamamlanmış olması gerekmektedir. Ancak buda transaction'un geç bitmesine neden olmaktadır. Ancak replikalar arasında veri tutarlılığı sağlar.  Asenkron modda ise primary serverda tamamlanan her transaction replicalarda da tamamlanmış sayılacağı için işlemler hızlı olmaktadır ancak veri bütünlüğü ve tutarlılık garanti edilmez. 

 

Yukarıdada anlattığım gibi failover cluster yapısından farklı olarak shared disk gereksinimi olmadığı farklı subnetlerde kurulum yapılabilir. Ve hatta Azure üzerine bile replika kurulumu yapılabilir. 

DMV-DMF Kullanımı-3(Kullanılmayan Indexlerin Tespit Edilmesi)

Bir önceki makalemde kullanılmayan  veya çok az kullanılan indexlerin query performansını  düşürdüğünü belirtmiştim. Sadece Select işlemleri için değil hatta özellikle insert ve update işlemlerinde kullanılmayan indexler performansı aşağılara çekmektedir.

Indexlerin bütün kullanım bilgileri sys.dm_db_index_usage_stats adlı  DMV'de tutulmaktadır. Bu DMV diğer sys.indexes, sys.objects, sys.schemas ve sys.partitions adlı DMVlerle birlikte sorgulandığında bize index kullanımları ile ilgili ayrıntılı bir bilgi verebilir.

Aşağıdaki script bize index kullanımı ile geniş bir kullanım bilgisi vermektedir. Bu tablo kullanılarak  kullanılmayan indexler silinebilir.  Ancak önceki makalelerimde belirttiğim gibi DMV ve DMFler her SQL Server restart olduğunda yeniden doldurulduğu için SQL Server başladıktan sonra belirli bir süre çalıştırılmış olması Best Practicedir.

SELECT TOP 250 db_name(dm_ius.database_id) As DbName
,o.name As ObjectName
,i.name As IndexName
,i.index_id As IndexID
,dm_ius.user_seeks As UserSeek
,dm_ius.user_scans As UserScans
,dm_ius.user_lookups As UserLookups
,dm_ius.user_updates As UserUpdates
,p.TableRows
FROM sys.dm_db_index_usage_stats dm_ius
INNER JOIN sys.indexes i ON i.index_id=dm_ius.index_id and
dm_ius.object_id=i.object_id
INNER JOIN sys.objects o ON dm_ius.object_id=o.object_id
INNER JOIN sys.schemas s on o.schema_id=s.schema_id
INNER JOIN (SELECT SUM(P.ROWS) TableRows,p.index_id,p.object_id
FROM sys.partitions p GROUP BY p.index_id,p.object_id)p
on p.index_id=dm_ius.index_id and dm_ius.object_id=p.object_id
where OBJECTPROPERTY(dm_ius.object_id,'IsUserTable')=1
and i.type_desc='nonclustered'
and i.is_primary_key=0
and i.is_unique_constraint=0
order by (dm_ius.user_seeks+ dm_ius.user_scans+dm_ius.user_lookups) ASC

DMV-DMF Kullanımı-2(Eksik Indexlerin Tespit Edilmesi)

Bir databasede sorgu performanslarını artırmak için öncelikle index yapısını gözden geçirip eklememiz index ekleyebilmek içinse  eksik olan indexleri ekleyebilmemiz için öncelikle eksik indexleri bulmamız gerekmektedir.  SQL Servera gönderilen sorgular için SQL Server bir query plan oluşturur. Bu query plan en iyi index kullanarak sorgu yapmaya çalışmakta eğer sorgu için index bulamadığı takdirde aşağıdaki DMV ve DMFler üzerinde depolama yapmaktadır.

Aşağıda bulunan 4 DMV ve DMF kullanarak eksik indexlerimizi belirleyebiliyoruz.

•  sys.dm_db_missing_index_group_stats - DMV-Eksik index’ler hakkında özet bir bilgi sunar.

• sys.dm_db_missing_index_groups - DMV-sys.dm_db_missing_index_group_stats ile sys.dm_db_missing_index_details arasında ilişki kurmamızı sağlar.

• sys.dm_db_missing_index_details-DMV-Eksik index hakkında kolon bilgileri gibi detaylı bilgileri döndürür.

•  sys.dm_db_missing_index_columns - DMF-Eksik index kolonları hakkında bilgi döndüren fonksiyondur. Diğer 3 tanesi ise  viewdir.

Örnek Sorgu

Aşağıdaki sorgu mevcut databasede bulunan eksik indexlerin bir listesini döndürür.

SELECT so.name
    , (avg_total_user_cost * avg_user_impact) * (user_seeks + user_scans) as Impact
    , mid.equality_columns
    , mid.inequality_columns
    , mid.included_columns
FROM sys.dm_db_missing_index_group_stats AS migs
INNER JOIN sys.dm_db_missing_index_groups AS mig ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid ON mig.index_handle = mid.index_handle
INNER JOIN sys.objects so WITH (nolock) ON mid.object_id = so.object_id
WHERE migs.group_handle IN (
    SELECT     TOP (5000) group_handle
    FROM sys.dm_db_missing_index_group_stats WITH (nolock)
    ORDER BY (avg_total_user_cost * avg_user_impact) * (user_seeks + user_scans) DESC)

DMVler her instance başlatıldığında yeniden doldurulduğu için bu DMVler SQL Server başlatıldıktan sonra ve belirli bir süre çalıştırıldıktan sonra kontrol edilmelidir.

SQL Server IQ oranı o kadar iyi olmadığı için bu sorguda önerilen indeksleri körü körüne uygulamak doğru değildir. Öncelikle bir test sunucusu üzerinde index oluşturulmalı ve iş yükü test edilmelidir. Eğer olumlu sonuçlar alınırsa teyit edilmeli ve kullanılmaya başlanmalıdır.

Eğer kullanılmayan bir index oluşturulursa boş yere disk alanı israfı veya dahada önemlisi tabloya yapılan diğer sorgularda performansı düşüreceği için index oluşturulma işi çok iyi analiz edilerek yapılmalıdır.

Not:Kullanılmayan indekslerin tespit edilmesi konusunu DMV-DMF Kullanımı-3 nolu makalede ayrıntılı olarak inceleyeceğiz.

DMV-DMF Kullanımı-1(Indexlerde Fragmentation Oranlarını Bulma)

Bu yazı dizimde DBAlerin hayatlarında çok önemli yer kaplayan kavramlar olan DMV (Database Management View) ve DMF(Database Management Function) kavramlarından bahsetmek istiyorum.

Bu kavramlar hayatımıza SQL Server 2005 ile beraber girmiş ve DBAlerin işlerini kolaylaştırmıştır.  Sql Server üzerindeki aktiviteler depolanmakta ve DMVler sayesinde bir view gibi kullanılabilmektedir.  Çalıştırılan sorguların hangi indexleri kullandığı, ne kadar I/O yaptığı veya ne kadar CPU tükettiği gibi bir çok veriye ulaşmamız mümkün.

DMVler bir view gibi kullanılabilir demiştik ancak  veriler databasede değilde bellekte tutulduğu için veritabanı her yeniden başladığında veriler yeniden toplanmaya başlamaktadır.

Ayrıca DMV ile DMF birbirine çok benzesede DMVler view gibi sorgulanabildiği ancak  DMFler dışarıdan aldığı parametreye göre veri döndüren fonksiyonlardır desek doğru olur.

DMV ve DMF Sql Serverımız üzerinde bir çok işlem için kullanılabilir.  Bu konu çok detaylı ve ayrıntılı bir konu. Bir veya birkaç makale ile anlatmak imkansız. Ben sizlere bugün indexler üzerinde fragmentation oranlarının bulunması için nasıl kullandığımızı anlatacağım.

Tablolarımız üzerinde bulunan indexler zamanla çalışan sorgular neticesinde bozulmalara uğramaktadır. Bu indexlerin belirli periyotlarla rebuild veya reorganize edilmesi gerekir. %5 ile %30 arası bozulmalarda reorganize %30 üzeri bozulmalarda ise rebuild işlemi yapılması Microsoft'un meşhur deyimi ile Best Practicedir. Bu yazımda indexlerin nasıl Rebuild veya reorganize edildiğinden bahsetmeyeceğim. Hangi indexin fragmentationa uğradığını ve bu oranın nekadar olduğunun nasıl tespit edileceğinden bahsetmek istiyorum.

Yukarıdada bahsettiğim gibi  oluşturduğumuz indexlerde veri eklenmesi silinmesi gibi işlemler oldukça indexlerimiz pageleri arasında boşluklar oluşacak ve btree veri yapımızın dengesi bozulacaktır. Bu nedenle düzenli olarak bozulan indexlerimizi bulup bozulma oranlarına göre rebuild veya reorganize etmemiz gerekir.

Bozulma oranlarınıda aşağıdaki sorguyu kullanarak görebiliriz.  Bu sorguda indexler üzerinde bozulma oranlarını görebildiğimiz sys.dm_db_index_physical_stats fonksiyonu ile  sys.indexes adlı view birlikte sorgulanmakta ve bizlere  index fragmentation yani dağılma oranlarını verecektir.

sys.dm_db_index_physical_stats sistem fonksiyonu bize istediğimiz bir indexte, bir databasede tüm indexler veya tüm databaselerdeki tüm indexlerin fragmentation oranlarını verebilir.

sys.dm_db_index_physical_stats sistem fonksiyonu 5 tane parametre almaktadır.

Bunlar database_id,object_id,index_id,partition_id ve modedur.

database_id: Bu parametre ile database seçebiliyoruz. NULL olarak verilirse bütün dbler seçilmiş olur

object_id:Bu parametre ile tablo seçebiliyoruz. NULL olarak verilirse bütün tablolar seçilmiş olur.

index_id:Bu parametre ile index seçebiliryoruz. NULL olarak verilirse bütün indexler seçilmiş olur.

partition_id:Bu parametre ile partition seçebiliryoruz. NULL olarak verilirse bütün indexler seçilmiş olur.

mode:İşlem sonucunun detayını belirleyebiliriz. DEFAULT, NULL, LIMITED, SAMPLED, or DETAILED değerlerini alabilir. NULL olarak geçilirse LIMITED mode kullanılır.

SELECT TOP 200
DB_NAME() AS databaseName
,OBJECT_SCHEMA_NAME(s.object_id) AS SchemaName
, OBJECT_NAME(s.[object_id]) As TableName
,i.name As IndexName
,ROUND(s.avg_fragmentation_in_percent,2) AS [Fragmentation %]
FROM sys.dm_db_index_physical_stats(db_id(),null,null,null,null) s
INNER JOIN sys.indexes i on s.[object_id] =i.[object_id]
and s.index_id=i.index_id
INNER JOIN sys.indexes o on i.object_id=o.object_id
WHERE s.database_id=DB_ID()
and i.name is not null
and OBJECTPROPERTY(s.[object_id],'IsMsShipped')=0
order by [Fragmentation %] desc

Üst Sürümde bulunan bir Database'in Alt Sürümlere Taşınması

Üst sürümde oluşturulmuş bir database alt sürümlere restore yapılamamakta veya attach edilmemektedir.Restore edilmek istendiğinde aşağıdaki gibi bir hata ile karşılaşmaktayız.

 

SQL Server Version listesine aşağıdaki tablodan bakabiliriz. Aralarda çıkan cumulative updatelere internet üzerinden ulaşabiliriz.

 

Şimdi gelelim taşıma işleminin nasıl olacağı bölüme. Taşıma işlemini yukarıda anlattığımız gibi backup-restore veya deattach-attach yöntemi ile yapamıyoruz.

Öncelikle deneme2014 adında bir database oluşturalım.  Daha sonra bunun üzerinde 1 tane table oluşturup üzerine veri kaydı yapalım.

 

Bu database taşımak için database üzerine sağ tuşla tıklayıp Generate Scripts linkini tıklıyoruz. Daha sonra next diyoruz. 

Script entire database and all database objects seçili olarak zaten karşımıza geliyor. Next buttonuna tıklayarak işleme devam ediyoruz.

Karşımıza çıkan ekranda  scripti kaydedeceğimiz dosya seçimini yapabiliriz. Clipboard kopyalayabilir veya new query olarak ekranımızda açtırabiliriz. Biz single file seçerek işleme devam ediyoruz.

Daha sonra Advanced kısmını seçerek uyumluluk ayarlarını script for versiyon kısmından seçiyoruz. 

Ayrıca datalarında gelmesini istediğim için Types of data to Script kısmına Schema and data seçerek işlemimize devam ediyoruz.

Bu şekilde script dosyamızı oluşturmuş olduk.

Bu scripti taşımak istediğimiz yerde çalıştırdığımızda database create edilecek ve içindeki tablo ve datalar oluşturulacaktır.

 

SQL Server Policy Management

Bugün sizlere SQL Server2008 ile bir özellik olan SQL Server policy management özelliğinden bahsetmek istiyorum. Policy Management kurumsal bazda yönetim ve yapılandırma  policyler tanımlamak ve uygulamak için izin verir.

Örnek olarak bir tablo oluşturulurken indekse sahip olma zorunluluğu olsunmu veya tablo adının bir ön ekle başlama zorunluluğu gibi policyleri tanımlayabiliriz.

Policy Management ekranına Sql Server Management Studio kullanarak erişebiliriz. Object Explorer'ın  altında Management sekmesinin altında bulunan Policy Management'ın altında bulunan Policies, Conditions ve Facets menulerini kullanarak Policyler oluşturup onları yönetebiliriz.

Facet sekmesini genişletiğimizde Facetlar listesini görebiliriz. Facetlar SQL Serverla birlikte gelen yönetilebilir  özelliklerdir. SQL Server'da Facetların özelliklerini görmek için üzerini çift tıklamamız gerekir.

 

Facetın özelliğini çift tıkladığımızda özelliklerini görebiliriz.

Condition Oluşturmak

Bir policy oluşturmak için öncelikle condition oluşturmalıyız. Bir condition için bir tane facet seçilebiliyor.  Facet kısmında Database kısmını seçiyoruz. Expression  field kısmında AutoShrink kısmını seçiyoruz. True veya False olabilir.

Policy Oluşturmak

Policy oluşturmak için new policy seçiyoruz.  Az önce oluşturduğumuz conditionu seçiyoruz.  Targets olarak database seçebileceğimiz gibi bizim yaptığımız gibi tüm databaseleri seçebiliyoruz.

Policynin üzerine sağ tıklayıp Evaulate seçerek policyimize uygun olup olmayan databaseleri görebiliriz.

Policyimize uygun olmayan databaseler kırmızı olarak karşımıza gelecektir.

TempDb Veritabanının Konfigürasyonu

TempDb Veritabanı Dosya İşlemleri

Bugün sizlere SQL Server sistem veritabanlarından birisi olan ve geçici işlemler için kullanılan TempDb  veritabanından , dosya yapısının nasıl konfigüre edilmesi gerektiğinden ve nasıl taşıyacağımızdan bahsetmek istiyorum. TempDb her instance yeniden başlatıldığında yeniden başlatılır ve geçici işlemler için kullanılır.

 

Sistem  veritabanlarından olan ve her instance için bir tane olan TempDb'de aşağıdaki veriler tutulur.

• Cursor, Temp Table , Join , Aggregation ve INSTEAD OF Trigger gibi objeler
• Read Commited Snapshot Isolation ,Snapshot Isolation ve Online Index  işleminde tutulan row version bilgileri
• Sorting, Hash Matches ve spools işlemleri için oluşturulan tablolar
• XML variables ve LOB kullanımında oluşturulan sorgular

TempDb veritabanı yukarıdada bahsettiğim gibi  geçici işlemler için kullanılır.   Bu nedenle çok yoğun geçici işlem kullanan Axapta, Sap gibi uygulamaların kullanmış olduğu SQL Server databaselerde yüksek performans sağlayabilmek için  TempDb  database yapısının  çok iyi yapılandırılması gerekmektedir.

Bunun için yapılacak işlemleri sıralayacak olursak 3-4 adımda tempdb veritabanından maksimum performans sağlayabiliriz.

Birinci adımda disk bant genişliğini maksimum seviyede kullanabilmek için tempdb dosyası birden fazla oluşturulmalıdır. Bu sayede tempdb veritabanında yapılacak işlemlerin paralel olarak yapılması sağlanır ve iş yükü önemli bir ölçüde ölçeklendirilebilir. Ancak çok fazla sayıda oluşturmak ise yönetim yükünü artırır ve performansda düşmeye sebeb olur. 

 

Bunun için genel kural tempdb veritabanı dosyaları oluşturulurken her CPU için bir dosya olarak yapılandırılmalı ve dosya adeti sekizi geçmemelidir.(Dual Core işlemciler iki CPU olarak kabul edilir.) (CPU sayısı sekizden fazla ise TempDB performans sorunu devam ediyorsa 4'er  4'er artırılabilir.)

Oluşturulan dosya boyutları bütün hepsinde aynı boyutta olmalıdır. Bu sayede dosya doluluk oranında optimizasyon sağlanmış olur.

 

Oluşturma esnasında datafile boyutları uygun olarak verilmeli ve autogrowth oranı çok iyi ayarlanmalıdır. Çok büyük dosya boyutu verildiğinde ise restart durumunda TempDb veritabanı yeniden oluşturulacağı için SQL Server'ın hazır duruma geçmesi esnasında biraz beklemek zorunda kalabiliriz.

Çok küçük verilir ise dosya boyutu devamlı büyüme gereksinimi duyar. Bu  işlem dosya seviyesinde exclusive lock’a neden olur buda auto growth işlemi sırasında file’a erişim engellenir ve eğer çok fazla auto growth oluşursa performans olumsuz etkilenir.

Bunun için genel uygulanan yöntem

tempdb file size	FILEGROWTH increment
0 to 100 MB	10 MB
100 to 200 MB	20 MB
200 MB or more	10%*

İkinci adımda ise dosyanın koyulacağı disk yapısı seçimi. Diskler yüksek oranda I/O yapacağı için hızlı bir I/O sistemi üzerine konulması tavsiye edilir. Bu disklerin yapılandırması stripping olması önerilmektedir. Ayrıca Tempdb  veritabanı diğer kullanıcı veritabanlarından farklı alanlar üzerine konulmalıdır ve tempdb data dosyaları ve log dosyalarıda bir birinden farklı disklere konulmalıdır. Bu sayede yüksek I/O elde ederek maksimum performans elde etmiş oluruz.

 

Üçüncü adımda ise 1117 numaralı trace flag aktif edilmelidir.  Bu sayede veritabanımızdaki tüm dosyaların büyüme oranları sabitlenmiş olur. Örneğin 400 MB lık 8 tane dosyamız var. Her birinin otomatik büyüme değerleri 100MBlık olarak verilmiş. Eğer flag kapalı ise TempDb dolduğunda sadece bir tanesi 100 MB büyür. Bu dosya tamamen dolmadan diğerlerine veri yazılmazki buda ister istemez performans kaybına yol açar.

Bu işlem için  aşağıdaki T-SQL komutu kullanılabilir.  1117 numarası Trace Flag numarasını temsil ederken -1 parametresi ise yapacağımız işlemin sadece o bağlantıya ait değilde global olarak yapılacağı anlamına gelir.

DBCC

TRACEON(1117,-1)

Trace Flag global olarak aktifleştirildiği için sadece TempDb değil diğer birden fazla dosyaya sahip veritabanlarıda otomatik olarak büyür. Bunuda DBA arkadaşların göz önünde bulundurması gerekir.

Dördüncü adımda ise TempDb'nin yoğun kullanılmasının anlaşılması ve yeniden yapılandırılması gerekirse query tarafında düzeltilmeye gidilmesi gerekmektedir.

TempDb Dosya Boyutlarını ve Büyüme Parametrelerini Görmek

TempDb dosya boyutlarını ve otomatik büyüme parametrelerini görmek için aşağıdaki T-SQL kodunu kullanabiliriz veya Sql Server Management Studio kullanabiliriz.

SELECT     name AS FileName,
size*1.0/128 AS FileSizeinMB,
CASE max_size         WHEN 0 THEN 'Autogrowth is off.'
WHEN -1 THEN 'Autogrowth is on.'       
ELSE 'Log file will grow to a maximum size of 2 TB.'   
END,    growth AS 'GrowthValue',    'GrowthIncrement' =        
CASE            WHEN growth = 0 THEN 'Size is fixed and will not grow.'          
 WHEN growth > 0 AND is_percent_growth = 0                
 THEN 'Growth value is in 8-KB pages.'           
 ELSE 'Growth value is a percentage.'      
 END
FROM tempdb.sys.database_files;

TempDb Veritabanının Taşınması

TempDb veritabanını diğer veritabanlarını taşıdığımız yöntemlerle taşıyamayız. TempDb veritabanını taşımak için aşağıdaki scripti kullanabiliriz. Aşağıdaki kodu uyguladıktan SQL Server instance yeniden başlatılınca yeni TempDb ayarları geçerli olacaktır.

USE master
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev, FILENAME = 'C:\SQLTEMP\tempdb.mdf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev2, FILENAME = 'C:\SQLTEMP\tempdb1.ndf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev3, FILENAME = 'C:\SQLTEMP\tempdb2.ndf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev4, FILENAME = 'C:\SQLTEMP\tmpdb3.ndf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev5, FILENAME = 'C:\SQLTEMP\tempdb4.ndf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev6, FILENAME = 'C:\SQLTEMP\tempdb5.ndf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev7, FILENAME = 'C:\SQLTEMP\tempdb6.ndf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = tempdev8, FILENAME = 'C:\SQLTEMP\tempdb7.ndf')
GO

ALTER DATABASE tempdb   MODIFY FILE (NAME = templog, FILENAME = 'C:\SQLTEMP\templog.ldf') 

TempDB VeriTabanında Neler Yapılamaz?

• TempDb Veritabanı asla silinmemelidir.
• Backup alınmamalıdır.
• Simple olan Recovery Modu asla değiştirmemelidir.
• Birden fazla FileGroup oluşturulmamalı sadece Primary File Group kullanılmalıdır.
• Database Owner olan SA kullanıcısı değiştirilmemelidir.
• TempDB databasenin Snapshotu alınamaz
• DBCC CHECKALLOC T-SQL komutu çalıştırılamaz.
•  DBCC CHECKCATALOG T-SQL komutu çalıştırılamaz.
• TempDB veritabanı Offline yapılamaz.

DAC ( Dedicated Admin Connection)

Bugun sizlere DAC konusunda bilgi vermek istiyorum. DAC nedir diyecek olursak SQL Server'da yöneticiler için tahsis edilmiş bir bağlantıdır diyebiliriz. SQL Server'da oluşabilecek yavaşlıklarda ve yetersiz kaynak durumlarında DAC kullanılarak SQL Server'a ulaşılabilir ve  sorunlar giderilebilir.

Yani DAC SQL Server'a bağlantı sorunları olduğunda ve ciddi performans kaybı durumlarında temel queryler çalıştırılmak üzere inşa edilmiştir.

DAC kullanabilmek için önceden açılmış olması gerekmektedir. Ancak çoğu DBA açmayı unuttuğu için 1-2 tecrübe sonunda DAC yapısı DBAler tarafından kullanılmaya başlanmaktadır.

DAC'ı iki yöntemle açabiliyoruz. Birinci yöntem T-SQL komutu kullanarak DAC bağlantısını aktif hale getirebiliyoruz.

İkinci yöntem ise Server Properties'de Facet altında Surface Area Configuration sekmesini seçerek RemoteDACEnable True-False seçilebilir.

 

Bu iki seçenekten birini kullanarak Dedicated Admin Connection aktif ettikten sonra artık bağlantı sağlanabilir duruma geldi. Buradada iki tane yöntemle sisteme bağlanıyoruz. SSMS kullanarak bağlanarak aşağıdaki yöntemle bağlantı sağlayabiliyoruz.

SQLCMD kullanarak aşağıdaki yöntemle bağlantı sağlayabiliriz.

 

DAC bağlantısı sadece sysadmin kullanıcıları için bağlantı hakkı sağlar.

Sadece bir tane DAC bağlantısı sağlanabilir.

DAC bağlantısı kullanılarak BACKUP ve RESTORE yapılamaz.

Windows Server Technical Preview Evaluations

Windows Server Technical Preview Evaluations'ın SQL Serverla ne alakası var diyeceksiniz. Ancak hangi veritabanı olursa olsun DBAlerin iyi hatta çok iyi bir sistem yöneticisi olması gerekmektedir. SQL Server'ın Oracle'ın üzerinde çalıştığı platformlardan oluşabilecek hatalarda ve iyileştirmelerde  DBAlerden işin içine müdahil olması beklenmektedir.

Windows Server Technical Preview 2015 yılında aramızda olması bekleniyor. Ancak şu anda beta aşamasında. Yani live ortamlarda kurulup üzerinde bir takım uygulamalar çalıştırmak doğru değil.Beta sürümünü burdan indirip kurmamız mümkün.



Yeni işletim sistemi ile beraber aşağıdaki rol ve servislerde bir çok özellikler ve iyileştirmeler geldi.

Active Directory Federation Services
Microsoft Hyper-V Server 5.0
Windows Defender
Remote Desktop Services
Storage Services
Failover Clustering
Web Application Proxy
Windows PowerShell 5.0
DHCP, DNS ,IP Address Management gibi Networking Services

Yeni Gelen Özellikler

SQLSaturday #359, ISTANBUL

Dünyanın en büyük SQL Server topluluğu PASS tarafından düzenlenen ve tam gün süren SQLSaturday etkinliği 06 Aralık 2014 tarihinde İstanbulda yapılacak.


Kayıt Olmak İçin Tıklayabilirsiniz.

Kesinleşen Sessionlar ;

Title	Speaker	Level
SQL Server Deep Dive	Denis Reznik	Intermediate
AlwaysOn Unplugged: Scalability Solutions with SQL Server 2012/2014	Yigit Aktan	Advanced
Backups for Azure SQL Databases and SQL Server instances running on Azure Virtual Machines	Chandra Mohan Situmalli	Intermediate
Building abstract layers for data protection and business logic	Uwe Ricken	Intermediate
Common TSQL Mistakes	Kevin Boles	Intermediate
Connection – Session – Request	Uwe Ricken	Advanced
Correcting Database Corruption: Advanced Techniques	Yigit Aktan	Advanced
CSI Indexes	Chandra Mohan Situmalli	Intermediate
Data quality with DQS components in Integration Services	Alexander Karl	Intermediate
Database Recovery: Backup and Restore Basics	Andrey Zavadskiy	Beginner
Deadlocks. Everything that developer needs to know	Denis Reznik	Intermediate
Deep dive to SQL Server configuration for SharePoint Server	Gokan Ozcifci	Advanced
Developerlar için SSDT kullanımı	Çağlar Özenç	Beginner
Dive into the Query Optimizer-Undocumented Insight	Benjamin Nevarez	Advanced
DMV for administration of indexes	Uwe Ricken	Advanced
DQS step-by-step with Domain Management, Knowledge Discovery and Matching Policies	Alexander Karl	Intermediate
Effective T-SQL. To be effective or not to be.	Denis Reznik	Intermediate
Execution Plans Detail From Zero to Hero	Ismail ADAR	Beginner
Handling data types in SQL Server	tomaz kastrun	Intermediate
How does SQL 2014 In Memory OLTP enhance Performance?	Işıl Efe	Intermediate
How to tune your applications before moving your database to Microsoft Azure SQL Database (PaaS)	Faruk Celik	Beginner
INSERT / UPDATE / DELETE – deep dive	Uwe Ricken	Advanced
Introducing Microsoft Azure HDInsight	Belkis Ozhorasan	Intermediate
Introduction to Reporting Services for SharePoint	Gokan Ozcifci	Beginner
Let’s cook ‘best SQL Server DBA practices’	Satya (SQLMaster) Shyam Jayanty	Intermediate
Making customer segmentation using SQL Server SSAS	tomaz kastrun	Advanced
Microsoft Analytics Platform System	Serdar Altug	Beginner
Monitoring and Assessing SQL Server with extended events	Batuhan Yildiz	Advanced
Optimizing SQL Server 2012 for SharePoint 2013	Gokan Ozcifci	Advanced
Practical Tips when Troubleshooting AlwaysOn issues	Sibel Nal	Intermediate
Query Processing in In-Memory OLTP (Hekaton)	Benjamin Nevarez	Intermediate
Relational Data Management on Microsoft Azure	Mine Tokus	Beginner
Replay your workload and save the business!	Boris Hristov	Intermediate
SharePoint – from distrust to acceptance	Gokan Ozcifci	Intermediate
SQL 2014 Column Store Index Enhancements	Işıl Efe	Intermediate
SQL 2014 Enhancements Overview	Mine Tokus	Intermediate
SQL Injections and Penetration Testing on SQL Server 2014	Ismail Adar	Advanced
SQL Server 2014 New Features	Kevin Boles	Intermediate
SQL Server 2014: High Availability and Disaster Recovery Solutions	Levent Oktar	Intermediate
SQL Server AlwaysOn and Clustering,Mirroring and Log Shipping	Yusuf Kahveci	Advanced
SQL Server Data platform upgrade Techniques, best practices & notes from the field	Satya (SQLMaster) Shyam Jayanty	Intermediate
SQL Server Performance Troubleshooting	Batuhan Yildiz	Advanced
SQL Server Query Design and Optimization Recommendations For Developers	Ismail ADAR	Intermediate
SQL Server ve Azure ML ile Tahminleme Modelleri	Koray Kocabas	Advanced
SQL Server: Performance Tuning and Troubleshooting	Denis Reznik	Advanced
The nightmare of locking, blocking and isolation levels!	Boris Hristov	Intermediate
Transaction Isolation Levels Deep Dive	Yigit Aktan	Intermediate
Transaction Log Basics	Andrey Zavadskiy	Intermediate
Understanding Parameter Sniffing	Benjamin Nevarez	Intermediate
Unit Testing SQL Server	Kevin Boles	Intermediate
Unit Testing with SQL Server Data Tools	Andrey Zavadskiy	Intermediate
Usage of R in SQL Server for better data understanding	tomaz kastrun	Intermediate
Useful Dynamic Management Views and Functions for SQL Server 2014	Ismail Adar	Intermediate
Windowing Functions: THE Reason to Upgrade to 2012+	Kevin Boles	Advanced
Write Quick, Readable and High Performance Queries Using Window Functions with SQL Server 2014	Ismail Adar	Intermediate
You want rules? You want Policy-Based Management!	Boris Hristov	Intermediate