Recent comments

None


İçerik Ara











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

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

Bu makale, Index kullanımının amacını ve faydalarını sorguladıktan sonra, Index tiplerinin arasındaki farkları derinlemesine inceleyip, bakım işlemlerinin nasıl yapılacağı üzerinde duracaktır.

[more]

Makaledeki ana başlıklar şu şekildedir.

  • Neden Index ?
  • Index Nasıl Çalışır ? (B-Tree – Balanced Tree Yapısı)
  • Clustered Index
  • Non-Clustered Index
  • Index’lere Göre Page’lerin Yapısı
    • Clustered Index’te Page’lerin Yapısı
    • NonClustered Index’te Page’lerin Yapısı
  • NonClustered Index’te Included Kolon Kullanımı
  • Index Maintenance (Index Defragmentation)
    • Fragmentation Oranlarının Belirlenmesi – Rebuild – ReOrganize Kararı
    • Reorganize Index
    • Rebuild Index
    • Defragmentation Script’i
    • Özet
  • Index’lerin Kullanım İstatistikleri
  • DMV’ler ile Eksik Index’leri Sorgulama (Missing Index)
  • Sonuç

 

Makale çok uzun olduğu için word formatında yayınlayacağım. Dosyayı buradan indirebilirsiniz. (doc uzantılı halini ise buradan indirebilirsiniz.)

Bu arada makalenin teknik incelemesini yapan Batuhan Yıldız’a tekrar teşekkür etmek isterim.

 

İ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 beraber gelecek olan özelliklerden biri de Distributed Replay Utility’dir. Bu yapı ile database sunucular üzerinde yük testi yapılabilir. Daha önceleri bu işlemler için load runner gibi 3rd party tool’lar kullanılmaktaydı. Denali ile beraber gelecek olan bu yapı sayesinde bir SP’nin sisteme geçilmeden önce canlı testini yapabilir, ya da canlı yapı üzerinde topladığınız trace’leri yük testi yapmak için istediğin sayıda makinada paralel olarak çalıştırıp sonuçları analiz edebilirsiniz.

[more]

Distributed Replay Utility, SQL Server Profiler tarafından toplanan trace sonuçları üzerinden çalışır. SQL Server 2000 ve önceki sürümlerden toplanan trace dosyaları Distributed Replay Utility’de kullanılamaz.

Toplanan trace dosyası Distributed Replay Utility sayesinde 1’den fazla client’da paralel olarak çalıştırılarak yük testi yapılabilir.

Aslında SQL Server Profiler’da da daha önce toplanmış bir trace dosyası tekrar çalıştırabilir. Fakat bu trace dosyasının aynı anda sadece 1 client’tan çalıştırılmasını izin verilir. Oysaki Distributed Replay Utility’de aynı trace dosyasını 1’den fazla client’ta aynı anda çalıştırarak yük testi yapabilirsiniz.

Mesela şöyle bir senaryo düşünelim. Web den satış yapan bir e-Ticaret siteniz var. Kullanılar ürünleri seçiyor ve daha sonra siparişlerini tamamlıyorlar. Sipariş modülüne yeni bir ekleme yaptınız. Yaptığınız bu eklemenin sisteme etkisini tam olarak kestiremiyor ve performans problemi çıkarıp çıkarmayacağını bilmiyorsunuz. İşte bu aşamada sipariş ekranı üzerinden yapılan bir işlemi SQL Server Profiler ile trace alıp kaydediyoruz. Aldığımız bu trace’i Distributed Replay Utility vasıtasıyla test ortamında birden fazla client üzerinden aynı anda çalıştırırak gerçek hayatı simule ediyoruz ve performans sıkıntısı olup olmadığını anlamaya çalışıyoruz.

Distributed Replay Utility aşağıdaki senaryolarda kulanılabilir.

  • Hali hazırda SQL Server 2008 kullanıyorsunuz. 2008 R2’ya geçmek istiyorsunuz ama bu geçişin performanca olarak etkisini tahmin edemiyorsunuz. Böyle bir durumda Distributed Replay Utility ile olayı simule edebilirsiniz.
  • Performance debugging işlemleri için kullanabilirsiniz.
  • Kapasite planlama için kullanabilirsiniz.

Distributed Replay Utility mimarisi aşağıdaki gibidir.

image

Administration Tool bir konsol uygulamasını göstermektedir ve Distributed Replay operasyonunu kontrol etmeye yarar.

Controller, üzerinde SQL Server Distributed Replay Controller adında bir windows service’in çalıştığı bir makineyi işaret etmektedir. Bu makinanin görevi simulasyonu yapacak client’ları organize etmektir. Her Distributed Replay Utility ortamında sadece 1 adet Controller bulunabilir.

Client’lar üzerlerinde SQL Server Distributed Replay Client adında bir windows service’inin çalıştığı, simulasyonu gerçekleştirecek makinelerdir. Fiziksel ya da sanal olabilirler. Aynı anda çalışarak hedef sunucu üzerinde gerçeğe yakın bir yük oluşturmaya çalışırlar.

Target Server, yük testine maruz kalacak veritabanı sunucusudur. Gerçek ortamla karşılaştırma yapabilmek açısından hardware olarak gerçek ortamla yakın özelliklerde olması avantajdır.

Daha sonraki makalelerimde adım adım bu utility’nin kullanılmasını incelemeye çalışacağım.

 

İ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


Dün, Microsoft’un Levent’teki binasında düzenlenen SQL Server İş kritik Uygulamalar İçin Performans Semineri’i oldukça ilgi çekiciydi. Değişik konuların ele alındığı bu tam gün seminerde aşağıdaki konu başlıkları en ilgimi çeken noktalardı.

  • Resource Governer’da Resource’ların Kullanılma Oranlarının Hesabı ve İzlenmesi
  • Partitioning
  • Data Compression
  • Transparent Data Encryption
  • Parallel Query Execution

İmkan buldukça ileriki makalelerimde bu konulara değinmeye çalışacağım.

İyi Çalışmalar

TS

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 SQL Server 2011 Denali ile beraber gelecek olan yeni bir tool’dan bahsetmek istiyorum. Juneau kod adıyla anılan bu tool’un açık adı SQL Server Developer Tool (SSDT). Bu yeni tool vasıtasıyla, developer’lar, SSMS (SQL Server Management Studio) kullanma ihtiyacı duymadan bütün işlemlerini bu yeni tool ile karşılayabilecektir.

[more]

Microsoft, developer arkadaşlara gerçekten oldukça fazla önem vermekte. DBA olarak bu önemi kıskanmamak mümkün değil :) Bizde bu yeni tool’lar istiyoruz. :)

Konumuza dönecek olursak, Juneau (cuno olarak okunuyor), developer’lara hem Visual Studio’nun özelliklerini sunmakta hem de SSMS üzerinden yapılabilecek işlemleri kapsamakta.

Juneau’nun kapsamı için aşağıdaki resme bakabiliriz.

image

Juneau’nun gözüme çarpan bir diğer özelliği ise DB’ler arasında schema karşılaştırması yapılabilmesi. Bildiğiniz gibi şu anda bu işlemi 3rd Party Tool’lar ile yapmaktayız. (Apex,Redgate vs.). Bu özellik sayesinde live DB’yi proje DB’si ile karşılaştırıp eksik olan değişiklikleri otomatik eşleyebilirsiniz.

Sözü fazla uzatmadan Teched 2010’da yapılan bir sunuma link vermek istiyorum. Bu sunumda yapılan demolar oldukça açıklayıcı bir şekilde Juneau’yu anlatmış.

http://www.msteched.com/2010/Europe/DAT314

İ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


Column Based Query Accelarator,iş kritik uygulamalarının DWH ayağında performans iyileştirmek amacıyla, 2011 Denali ile beraber gelen en önemli özelliklerden biridir. Microsoft’un belirttiğine ve bazı demolara göre yoğun data içeren tablolarda 10 kata kadar daha iyi performans almak mümkündür.

[more]

Colum Based Query Accelarator, adından da anlaşılacağı üzere datayı page’lerde satır(row) bazında saklamaktansa, kolon (column) bazında saklayarak bu kolon üzerinden çekilen sorgularda 10 kata kadar performans artışı sağlamaktadır.

Bugünkü makalemde, bu yapının detayına değinip,avantajlarına baktıktan sonra Microsoft’un yaptığı bir demodan bahsedip yazımı noktalayacağım.

SQL Server 2011 Denali’de bu özelliği yeni gelecek olan columnstore index tipi ile sağlayacağız. columnstore index tanımlaması yapıldığında data, page’ler de satır bazında değil kolon bazında saklanmaktadır. Bunun ne demek olduğunu aşağıdaki resimde görmeye çalışalım.

1

Resimde de gördüğünüz gibi bir tablo için oluşturulmuş klasik index’lerde datalar page’lerde row yani satır bazlı olarak tutulurlar.

Oysaki columnstore index yapısında datalar page’lerde column yani kolon bazlı olarak tutulurlar.

Bu şekilde bir yapı şu avantajları sağlamaktadır;

  • Sadece istenen kolon ile ilgili page’ler disk’ten okunabilir. Bu durumda gereksiz kolonların okunması engellenmiş olur.Bu da daha az page okunması yani performans artışı manasına gelmektedir.
  • Page’lerin içinde aynı kolona ait bilgiler tutulduğu ve bu bilgilerin birbirinin aynısının olma ihtimali yüksek olduğu için columnstore page’ler çok iyi sıkıştırılabilir. Bu da gene diskten daha az datanın okunması anlamına gelmektedir.
  • Daha az page memory’e alındığı için buffer cache hit ratio performance counter’ı yani istenen bilgilerin memory’den karşılanması counter’ı çok artacaktır. Bu da performans artışına delalettir.

Columnstore index içeren tablolarda delete,insert,update işlemleri yapılamaz. Bu işlemleri yapabilmek için ilk olarak columnstore index’in disable edilmesi gerekmektedir. Table üzerinde update işlemlerini bitirdikten sonra index’i rebuild etmeniz yeterli olacaktır.

Şimdi, Microsoft’un verdiği sunumlarda kullandığı bir demo işleminden bahsedelim. Bu demoda 1,3 milyar row’dan oluşan, 1 TB boyutunda bir tablo kullanılmış. Ve bu tablo üzerinde şu şekilde bir columnstore index create edilmiş.

CREATE COLUMNSTORE INDEX cstore on [dbo].[catalog_sales] 
           ([cs_sold_date_sk] 
           ,[cs_sold_time_sk] 
           ,[cs_ship_date_sk] 
           ,[cs_bill_customer_sk] 
           ,[cs_bill_cdemo_sk] 
           ,[cs_bill_hdemo_sk] 
           ,[cs_bill_addr_sk] 
           ,[cs_ship_customer_sk] 
           ,[cs_ship_cdemo_sk] 
           ,[cs_ship_hdemo_sk] 
           ,[cs_ship_addr_sk] 
           ,[cs_call_center_sk] 
           ,[cs_catalog_page_sk] 
           ,[cs_ship_mode_sk] 
           ,[cs_warehouse_sk] 
           ,[cs_item_sk] 6 
           ,[cs_promo_sk] 
           ,[cs_order_number] 
           ,[cs_quantity] 
           ,[cs_wholesale_cost] 
           ,[cs_list_price] 
           ,[cs_sales_price] 
           ,[cs_ext_discount_amt] 
           ,[cs_ext_sales_price] 
           ,[cs_ext_wholesale_cost] 
           ,[cs_ext_list_price] 
           ,[cs_ext_tax] 
           ,[cs_coupon_amt] 
           ,[cs_ext_ship_cost] 
           ,[cs_net_paid] 
           ,[cs_net_paid_inc_tax] 
           ,[cs_net_paid_inc_ship] 
           ,[cs_net_paid_inc_ship_tax] 
           ,[cs_net_profit]) 

 

32 logical CPU ve 256 GB Ram üzerinde bulundurulan bu tabloda şu sorguyu çekerek sonucun gelme süreleri birbirleriyle karşılaştırılmış.

select w_city, w_state, d_year, SUM(cs_sales_price) as cs_sales_price 
from warehouse, catalog_sales, date_dim 
where w_warehouse_sk = cs_warehouse_sk 
and cs_sold_date_sk = d_date_sk 
and w_state in ('SD','OH') 
and d_year in (2001,2002,2003) 
group by w_city, w_state, d_year 
order by d_year, w_state, w_city; 

 

Şimdi columnstore index’in olduğu ve olmadığı durumlara göre sorgu sürelerini görelim.

  Total CPU Time (seconds) Total Elapsed Time (seconds)
Columnstore varken 31 1,10
Columnstore yokken 502 501
Hızlanma 16 Kat Hızlanma 455 Kat Hızlanma

 

16 Kat hızlanma. Gerçekten müthiş değil mi?

İ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 11 Mart 2011 İstanbul Kongre Merkezinde Microsoft Tirkiye Bilişim Zirvesi 2011 gerçekleşti.

3000’den fazla bilişimcinin katıldığı bu etkinlikte 11 farklı salonda 66 paralel session gerçekleştirildi.

Eğer etkinliği kaçırdıysanız üzülmenize gerek yok. MS session’ların video çekimlerini ve sunum dosyalarını aşağıdaki adreste paylaşmış durumda.

http://www.microsoft.com/turkiye/cloud/localEvents.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


SQL Server Magazine’in Ocak 2011 sayısında Paul Randal’ın üzerinde durduğu, bir database’i aynı server üzerinde yeni bir lokasyona taşımanın güvenli yolu yöntemini, bu yazıyı okuduğumdan beri ben de sıklıkla kullanmaktayım. Bugün size bu yöntemin adımlarını gösteriyor olacağım.

[more]

Daha önceleri DB taşımalarını backup-restore ya da attach-detach yöntemleriyle yapmaktaydım. Bu yöntemlerde sıkıntı duyduğum noktalar, backup-restore seçeneğinde işlemin uzun sürmesi, detach-attach yönteminde ise yetkisel problemlerdi.

Paul Randal’ın yöntemini okuduktan sonra artık aynı makina içindeki DB taşımalarında bu yöntemi kullanmaktayım.

Yöntem şu şekilde;

  1. DB’yi offline’a çekiyoruz.
    		
    ALTER DATABASE AdventureWorks SET OFFLINE
    	
  2. Data ve log dosyalarını yeni lokasyona kopyalıyoruz. Yedek kalması açısından şu an için eski lokasyonda bir kopyasını bırakıyoruz.
  3. System Catalog’larında data ve log dosyalarının yeni lokasyonlarını ALTER DATABASE komutu ile belirtelim.
    USE master
    GO
    ALTER DATABASE [AdventureWorks]	
    	MODIFY FILE (NAME = 'AdventureWorks_Data', FILENAME = 'D:\Data\AdventureWorks_Data.mdf')
    GO
    ALTER DATABASE [AdventureWorks]	
    	MODIFY FILE (NAME = 'AdventureWorks_Log', FILENAME = 'D:\Data\AdventureWorks_Log.ldf')
    GO

  4. DB’yi online’a çekiyoruz.
    		
    ALTER DATABASE AdventureWorks SET ONLINE
    	

İ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


Şu sıralar bir konsolidasyon projesi üzerinde çalışmaktayım. Bu proje kapsamında SQL Server Instance’larını ortak pool sunucularda konsolide etmeye çalışıyorum. Ana amaçlarımdan biri lisans maliyetini azaltmak, bir diğer kazancımız ise disk ve maintenance kazancı olacak.

Bu kazançları hesaplarken şöyle bir bilgiye ihtiyacım oldu. Biz genelde SQL Server backup’larımızı direk tape’e almaktayız. Ama hala bazı ortamlarımızda disk’e backup çıkılmakta. Bu durum da gereksiz disk kullanımı demek.

Amacım, tüm SQL Server database’lerimi dolaşmak, her database için en son alınan backup eğer disk’e alındıysa bu backup’ın boyutunu raporlamak. Çıkan rapor sonucunun genel toplamı da benim şu andaki disk’e backup almanın disk açısından maliyeti olacak.

[more]

Bu amaçla aşağıdaki scriptleri yazdım. SQL Server versiyonu olarak 2000,2005,2008 kullandığım için her biri için ayrı ayrı scriptler hazırladım.

--SQL Server 2008
SELECT DatabaseName, backup_finish_date, UserName, Duration_second
	,backup_size_MB
	,compressed_backup_size_MB, Compress_Gain_percentage 
	,physical_device_name 
from
(
	SELECT 
		row_number() over(partition by T1.name order by T2.backup_finish_date desc) as rn
		,T1.Name as DatabaseName
		,T2.backup_finish_date		
		,COALESCE(Convert(varchar(12), T2.user_name, 101),'NA') as UserName
		,DATEDIFF(ss,T2.backup_start_date,T2.backup_finish_date) as Duration_second
		,Round(T2.backup_size/1024./1024,2) as backup_size_MB
		,Round(T2.compressed_backup_size/1024./1024,2) as compressed_backup_size_MB
		,Round(((T2.backup_size-T2.compressed_backup_size)*100.)/T2.backup_size,2) as Compress_Gain_percentage
		,T3.physical_device_name 
	FROM sys.sysdatabases T1 
	LEFT OUTER JOIN msdb.dbo.backupset T2 ON T2.database_name = T1.name
	LEFT OUTER JOIN msdb.dbo.backupmediafamily T3 ON T3.media_set_id = T2.media_set_id
	where T1.dbid>4 and type='D'
		and T3.device_type in (2,102)
)xx	
where rn=1


--SQL Server 2005
SELECT DatabaseName, backup_finish_date, UserName, Duration_second
	,backup_size_MB
	,physical_device_name 
from
(
	SELECT 
		row_number() over(partition by T1.name order by T2.backup_finish_date desc) as rn
		,T1.Name as DatabaseName
		,T2.backup_finish_date		
		,COALESCE(Convert(varchar(12), T2.user_name, 101),'NA') as UserName
		,DATEDIFF(ss,T2.backup_start_date,T2.backup_finish_date) as Duration_second
		,Round(T2.backup_size/1024./1024,2) as backup_size_MB
		,T3.physical_device_name 
	FROM sys.sysdatabases T1 
	LEFT OUTER JOIN msdb.dbo.backupset T2 ON T2.database_name = T1.name
	LEFT OUTER JOIN msdb.dbo.backupmediafamily T3 ON T3.media_set_id = T2.media_set_id
	where T1.dbid>4 and type='D'
)xx	
where rn=1 and T3.device_type in (2,102)


--SQL Server 2000
SELECT xx.*
	,COALESCE(Convert(varchar(12), T2.user_name, 101),'NA') as UserName
	,COALESCE(Convert(varchar(12), T2.user_name, 101),'NA') as UserName
	,DATEDIFF(ss,T2.backup_start_date,T2.backup_finish_date) as Duration_second
	,Round(T2.backup_size/1024./1024,2) as backup_size_MB
	,T3.physical_device_name 
FROM
(
	SELECT 
		T1.Name as DatabaseName,MAX(T2.backup_finish_date) as backup_finish_date, 
		COALESCE(Convert(varchar(20), MAX(T2.backup_finish_date)),'Not Yet Taken') as LastBackUpTaken
	FROM sysdatabases T1 
	LEFT OUTER JOIN msdb.dbo.backupset T2 ON T2.database_name = T1.name
	where T1.dbid>4 and type='D'		
	GROUP BY T1.Name
)xx
LEFT OUTER JOIN msdb.dbo.backupset T2 ON T2.database_name = xx.DatabaseName and T2.backup_finish_date=xx.backup_finish_date
LEFT OUTER JOIN msdb.dbo.backupmediafamily T3 ON T3.media_set_id = T2.media_set_id
WHERE T3.device_type in (2,102)
ORDER BY xx.DatabaseName

 

SQL Server 2008 için hazırladığım script te fazladan compress backup boyutu ve compress backup’tan dolayı yaptığımız kazançta var. Bildiğiniz gibi compress backup özelliği 2008 ile beraber geldiği için 2005 ve 2000’de bu özelliği kullanamamaktayız.

Şimdi SQL Server 2008 olan bir sunucumda script’i çalıştırınca gelen sonuca bakalım.

back

Son alınan backup’ın boyutunu ve süresini görmekteyiz. Rapor sonucunu excel’e atıp backup_size ları toplarsak toplam disk maliyetimizi alabiliriz.

Ayrıca son backup’ın fiziksel diskte nereye alındığını da rapor sonucunda görebilmekteyiz.

Bu scriptleri bütün sunucularda tek seferde çalıştırıp raporlamak için Registered Servers özelliğini kullanabilirsiniz. Bu konuyla alakalı makaleye şuradan erişebilirsiniz.

 

İ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


İstanbul Teknik Üniversitesinde Corporate Finance dersimize giren Doç. Dr. Oktay Taş, 12 Mart Cumartesi günü 10:00-11:30 saatleri arasında HALKA ARZ SÜRECİNE YÖNETSEL BAKIŞ başlıklı bir seminer verecek.

Konuyla ilgilenen arkadaşları bekliyoruz.

Yönetsel Bilimleri Kongresi’nin tüm programına aşağıdaki adresten erişebilirsiniz.

http://www.ybk.org.tr/index.php?option=com_content&view=article&id=110&Itemid=61

 

İ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 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


Bugünkü yazımda Database seviyesinde Select,Update gibi işlemler için verilen GRANT,DENY gibi yetkilerin, sys.sysprotects tablosundan nasıl sorgulanacağına bakıyor olacağız.

[more]

AdventureWorks için aşağıdaki yetki verme scriptlerini çalıştıralım.

--ka user'ı için Sales.Customer tablosunda delete deny
DENY DELETE ON [Sales].[Customer] TO [ka]
--ka user'ı için Production.Product tablosunda insert deny
DENY INSERT ON [Production].[Product] TO [den]
--ka user'ı için Person.Contact tablosunda select grant
GRANT UPDATE ON [Person].[Contact] TO [def]

 

Şimdi verdiğimiz bu yetkileri sorgulayalım.

select OBJECT_SCHEMA_NAME(id) as SchemaName
	,OBJECT_NAME(id) as ObjectName
	,su1.name as UserName
	,sp.action
	,(case sp.action when 26 then 'REFERENCES' 
					when 178 then 'CREATE FUNCTION' 
					when 193 then 'SELECT' 
					when 195 then 'INSERT' 
					when 196 then 'DELETE' 
					when 197 then 'UPDATE' 
					when 198 then 'CREATE TABLE' 
					when 203 then 'CREATE DATABASE' 
					when 207 then 'CREATE VIEW' 
					when 222 then 'CREATE PROCEDURE' 
					when 224 then 'EXECUTE' 
					when 228 then 'BACKUP DATABASE' 
					when 233 then 'CREATE DEFAULT' 
					when 235 then 'BACKUP LOG' 
					when 236 then 'CREATE RULE' 
					else 'na' end) as Action_desc	
    ,sp.protecttype
	,(case sp.protecttype when 204 then 'GRANT_W_GRANT' 
					when 205 then 'GRANT' 
					when 206 then 'DENY' 
					else 'na' end) as ProtectType_desc	
	,sp.columns										
	,su2.name as Grantor
from sys.sysprotects sp
LEFT join sysusers su1 on su1.uid=sp.uid
LEFT join sysusers su2 on su2.uid=sp.grantor
where su1.name<>'public'

 

aa1(1)

 

İ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


Troubleshoot amaçlı, Visual Studio ile SQL Server üzerinde debug yapılmak istendiğinde aşağıdaki gibi bir hata alınabilir.

[more]

image

Unable to start T-SQL Debugging. Could not attach to SQL Server process on … The RPC server is unavailable.

Bu hatanın nedeni, debug yapmaya çalışan windows account’un SQL Server üzerinde yeterli hakka sahip olmamasıdır.

Debug yapan windows account’un SQL Server üzerinde sysAdmin olması gerekmektedir. Aşağıdaki örnek script ile bu yetki verilebilir.

sp_addsrvrolemember 'Domain\Name', 'sysadmin'

 

İ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


Geçenlerde ihtiyacım olan bir konu idi bu. Aşağıdaki makale çok güzel anlatmış. Paylaşmak istedim.

http://blogs.msdn.com/b/karang/archive/2009/09/05/sql-server-analysis-services-port-sql-2005-2008.aspx?CommentPosted=true#commentmessage

 

İ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 Azure, Windows Azure Platform’u üzerinde konuşlanan SQL Server’ın bulut (cloud) tabanlı çözümüdür.

[more]

az1

SQL Azure’un, bulut tabanlı olmasından dolayı, uygun maliyetli ölçeklenebilirlik, yüksek erişilebilirlik ve yönetimsel maliyetlerin düşürülmesi gibi yararları vardır.

SQL Azure servisinin sunucu üzerindeki fiziksel yönetimi, MSITS (Microsoft Information Technology Services) tarafından yapılmaktadır. Biz veritabanı, login, kullanıcı ve rolleri yönetmeye devam ederken sunucu, disk ve memory gibi fiziksel kaynakların yönetimi MSITS tarafında yapılmaktadır. Kurulum (installation), SP ve Cumulative Update geçilmesi gibi işlemlerden de MSITC sorumludur. Bu mimari bize, SQL Server’ı kendimiz barındırdığımız durumdan daha hesaplı bir şekilde yüksek sürekliliğe, yüksek güvenliğe sahip veritabanları sunmaktadır. Dolayısıyla altyapıya yatırım yapacak kaynağı olmayan, veritabanı yöneticisi bulundurmayan kurumlar için Azure mimarisi iyi bir çözümdür.

Her ne kadar fiziksel yönetimi MSITS yapsa da bulut mimarisinde SQL Server veritabanı yöneticileri önemli rol oynamaya devam etmektedir. Index iyileştirmesi, sorgu optimizasyonu ve güvenlik işlemleri (login,role vs.) veritabanı yöneticileri tarafından yürütülmeye devam eden operasyonlardır. Daha sonraki makalelerimde bu işlemlerin hepsine adım adım değiniyor olacağım.

Bu makalenin ana başlıkları :

  • Neden SQL Azure?
    • Uygun Maliyetli Ölçeklenebilirlik
    • Yüksek Süreklilik (High Availability)
    • Yönetimsel Maliyetlerin Düşürülmesi
  • Topoloji
  • Ring Topology
  • Veri Merkezleri
  • SQL Azure’da Güvenlik
  • Migration – Deployment
  • SQL Azure’da T-SQL Kapsamı
  • SQL Server – SQL Azure Farklılıkları

Neden SQL Azure ?

SQL Azure, bulut mimarisinin sunduğu altyapıyı kullanarak uygun maliyetli ölçeklenebilirlik, yüksek süreklilik ve yönetimsel maliyetlerin düşürülmesi gibi avantajlar sunmaktadır. Bu avantajları detaylı inceleyelim.

Uygun Maliyetli Ölçeklenebilirlik

SQL Azure’da, bulut mantığının temelinde yatan “kullandığın kadar öde yaklaşımı” bulunmaktadır. Bu şekilde daha uygun maliyetli bir ölçeklenebilirlik sunulmaktadır. Bir örnek vererek ne demek istediğimi daha net açıklamaya çalışayım. Bir proje geliştirdiniz ve hayata geçirdiniz. Daha veri girişi yeni yeni yapıldığı için 1 GB’lık bir veritabanı işinizi görmekte. Azure’dan 1 GB’lık bir veritabanı alıyorsunuz ve bu boyuta göre ödeme yapmaya başlıyorsunuz. Daha sonra veri girişleri arttıkça, 1 GB yetmemeye başlıyor ve veritabanı boyutunu 10 GB’a çıkartıyorsunuz. Ve bundan sonraki faturalarınız da 10 GB üzerinden kesiliyor. Proje bir süre kullanıldıktan sonra projenin modüllerinden biri çıkartılıyor ve artık size 5 GB’lık bir alan yetmeye başlıyor. Veritabanı boyutunu küçültüyorsunuz ve 5 GB üzerinden fatura ödemeye devam ediyorsunuz.

Gördüğünüz gibi bu şekilde veritabanı boyutunu kolayca ölçekleyebiliyor, ayrıca “kullandığın kadar öde mantığıyla” uygun maliyetli bir hizmet alıyorsunuz.

Kullandığın kadar öde mantığında ücretlendirme konusunda bir parantez açmak istiyorum. SQL Azure üzerinde veritabanı ücretlendirmesi veritabanının sürüm (edition) bilgisine göre ve boyutuna göre yapılmaktadır. SQL Azure’da 2 tip sürüm bulunmaktadır. Bunlar Web Edition (1GB ve 5GB) ve Business Edition (10GB- 20GB-30GB-40GB-50GB) veritabanı seçeneğidir. Hizmet kullanım faturası aylık olarak kesilir ama günlük olarak hesaplanır. Yani örneğin Mart ayının ilk 10 günü Web Edition-2GB kullandıktan sonra veritabanını Business Edition-10GB’a taşırsanız, ay sonunda faturanız 10 gün Web Edition-2GB + 20 gün Business Edition-10GB şeklinde ücretlendirilecektir. Ayrıca master veritabanı için ek bir ücretlendirme yapılmadığını belirtelim. (Bu arada şu bilgiyi de geçmekte fayda görüyorum, veritabanı maksimum boyuta eriştiğinde artık insert,update işlemleri yapılamaz. Select ile görüntülemeye ve delete ile silmeye devam edebilirsiniz.)

Ücretlendirmede etkili olan bir diğer parametre veri transferi hacmidir. Bunu klasik web hosting paketlerinde uygulanan bandwith mantığına benzetebiliriz. Kullandığınız veri transferinin hacmine göre ekstra bir ücretlendirme yapılır. Bu aşamada, Azure’da bulunan veritabanına bağlantı kuracak uygulamanızın bulunacağı lokasyonun 2 farklı model olabileceğinden bahsedebiliriz. Birinci modelde uygulamanızı kendi lokasyonunuzda bulundurup web üzerinden SQL Azure’da bulunan veritabanına erişebilirsiniz. Bu modele code-far model denmektedir. Adından da anlaşılacağı gibi uzakta barındırılan veritabanı anlamına gelmektedir. İkinci modelde ise uygulamayı Windows Azure’da bulundurabilirsiniz ki böyle bir durumda uygulama ile SQL Azure’da bulunan veritabanı aynı veri merkezinde barındırılacak ve veri transfer ücreti minimize edilecektir. Bu modele de code-near model denmektedir. Dolayısıyla code-near modelini uygulamak hem veri transferi ücretini düşürecek hem de uygulama ile veritabanı aynı veri merkezinde olacağı için büyük miktardaki verinin transferini çok hızlandıracaktır.

Yüksek Süreklilik (High Availability)

SQL Azure veritabanları % 99.9 oranında yüksek süreklilik sunmak amacıyla özel bir replication metodu kullanmaktadır.Bu yapıda 3 adet replika bulundurulmaktadır. Bunlar 1 adet ana (primary) ve 2 adet yedek (secondary) replika’dır. Bu şekilde bir verinin kopyası 3 farklı replikada bulundurularak yüksek süreklilik sağlanmaktadır.

2

Bu yapının gerçekleşebilmesi ve replication’ın yapılabilmesi için tablolarda Clustered Index bulundurulması zorunludur. Tablo tanımlanırken bu kontrol yapılmaz. Yani Clustered Index’siz bir tablo tanımlayabilirsiniz, ama tabloya veri girişi yaptığınız anda veri girişi gerçekleşmez. Dolayısıyla SQL Azure veritabanı tablolarında Clustered Index bulundurulması zorunludur. TempDB’de oluşturulan geçici (temporary) tablolar ise Heap yani Clustered Index içermeyen tablolar olabilir. Bununla ilgili bir kısıtlama bulunmamaktadır.

Yüksek Süreklilik Mimarisinin Çalışma mekanizması

Ana (primary) sunucu çalışamaz duruma geldiğinde, Partition Manager, yedek (secondary) sunuculardan bir tanesini ana sunucu yapmakta ve yedekte fazladan bekletilen sunuculardan bir tanesi ise yedek (secondary) yapılmaktadır. Bu operasyon gerçek zamanlı gerçekleşir ve kesinti yoktur.

Secondary sunuculardan biri çalışamaz duruma geldiğinde ise gene Partition Manager görevi üstlenir ve yeni bir yedek (secondary) sunucu oluşturmaya çalışır. Yeni yedek (secondary) sunucu hemen oluşturulmaz. Çünkü çalışamaz duruma gelen secondary replica kısa süreli olarak servis dışı kalmış olabilir (Örneğin Upgrade). Çalışamaz duruma geldiği sanılan bu sunucu tekrar geri döndüğünde bu sunucu üzerinde checkdisk gibi kontroller yapılır ve sunucunun sağlığı kontrol edilir. Bir problem yok ise bu sunucu ile devam edilir. Tersi durumda eğer sunucu 2 saatten fazla süre çalışamamışsa Partition Manager yeni bir sunucuyu yedek (secondary) olarak atar.

Replica’lardan birinin (Primary veya Secondary farketmez) bu şekilde değiştirilme işlemine reconfiguration denmektedir. Sunucunun çalışamaz duruma gelmesi, bir donanım hatası olabileceği gibi aynı zamanda işletim sisteminde ya da SQL Server servisinde oluşabilecek bir problemi ifade etmektedir.

Şimdi SQL Azure’da okuma ve yazma işleminin nasıl gerçekleştiğine bakalım.

3

Okuma (Select) işlemleri direk primary replikadan yapılmaktadır. Yazma (insert-update) işlemi ise bütün replikalarda gerçekleştirilmektedir ve yazma işleminin tamamlanabilmesi için primary replika ve secondary replikalardan en az birinde commit işleminin tamamlanmış olması gerekmektedir. Buna Quorum Commit denmektedir.

Yüksek süreklilik alt başlığını özetleyecek olursak, SQL Azure 3 replikadan oluşan yapısıyla ve çalışmayan sunucuların yerine yenilerini atayan teknolojisiyle kesintisiz bir ortam sunmaktadır.

Yönetimsel Maliyetlerin Düşürülmesi

Yazımın başında da belirttiğim gibi SQL Azure’da fiziksel yönetim MSITS (Microsoft Information Technology Services) tarafından yapılmaktadır. Bu şekilde disk,memory gibi yönetimler için kaynak kullanmak zorunluluğumuz ortadan kalkmakta ve bu da maliyetlerin düşürülmesi anlamına gelmektedir.

Disk,memory gibi fiziksel yönetimin yanında sunucudaki kurulum (Installation) ve kurulum yükseltmeleri de (SP,Cumulative Update vs.)  MSITS kontrolündedir.

Bu bilgileri verdikten sonra aklınıza şöyle bir soru gelebilir. "Peki ama SQL Server veritabanı yöneticileri ne yapacak?”

Veritabanı yöneticilerinin SQL Azure’da da önemi devam etmektedir. Index iyileştirmesi, sorgu optimizasyonu ve güvenlik işlemleri (login,roller vs.) veritabanı yöneticileri tarafından yürütülmeye devam etmektedir.

Yönetimsel maliyetlerinin düşürülmesinin avantajları olduğu gibi bazı dezavantajları da vardır. Örneğin disk yönetimi MSITS’de olduğundan, bir tablo ya da index’i istediğimiz bir fiziksel disk ya da filegroup’ta bulundurma şansımız bulunmamaktadır. Ayrıca şu an için yedek de alamamaktayız. Backuplar MSITS yönetiminde olup otomatik olarak alınmaktadır ve son kullanıcılar bu yedek dosyalarına erişemez. (Sonraki versiyonlarda mantıksal yedeklerin ve yedekleri indirmenin (restore) destekleneceği konuşulmaktadır.)

Topoloji

Ağ topolojisi (Network Topology), yükün dağıtımı (Load Balancing) ve Failover gibi yüksek süreklilik özelliklerini aşağıdaki grafikteki gibi özetleyebiliriz.

4

İstemci uygulamaları isteği Internet üzerinden ODBC, ADO.Net protokolleri ile Azure’a ulaşır. Bu protokollerin her biri Tabular Data Stream (TDS) oluşturur. SQL Gateway’e ulaşan istek ilgili veritabanı sunucusuna yönlendirilir.

Aslında bağlantı kurulmak istenen sunucu bir mantıksal sunucudur. Bu mantıksal sunucuya gelen istek SQL Gateway’e gelir ve SQL Gateway’da gelen isteği fiziksel sunucu üzerindeki veritabanına yönlendirir.

Load Balancing’i biraz detaylandırırsak eğer; yeni bir SQL Azure DB oluşturma isteği geldiğinde Load Balancer, sunucular üzerindeki yükü analiz ederek bu yeni veritabanının primary ve secondary replikalarını nereye koyacağına karar verir.

Ayrıca eğer bir sunucu ağır bir yük altında kalırsa, Load Balancer bu sunucu üzerinde bulunan primary replikayı alır ve daha az yük altında olan başka bir sunucunun üzerine yerleştirir.

Ring Topology

Bu aşamada SQL Azure’da bulunan Ring Topolojisinden bahsetmek istiyorum. Ring Topology, sunucuları mantıksal bir halka halinde birbirini bağlamaktadır. Bu yapıda her sunucu 2 komşusunu (neighbor) kontrol etmekte, aynı zamanda her sunucuda 2 komşusu tarafından kontrol edilmektedir. Bu kontroller sırasında bir sunucunun çalışamaz durumda olduğu belirlenirse bu sunucu halkadan çıkartılıp yerine yeni bir sunucu atanmaktadır.

5

Örneğin bu yapıda, 15 numaralı sunucu 84 ve 34 numaralı sunucular tarafından izlenmektedir ve eğer 15 numaralı sunucunun çalışamaz olduğunu 84 ya da 34 numaralı sunucu fark ederse bu sunucu halkadan çıkarılmaktadır.

Eğer bir sunucunun yeniden başlatılması gerekiyorsa bu durum sunucunun çalışamaması olarak değerlendirilmemekte, clean failure olarak düşünülmektedir. Çünkü böyle bir durumda sunucu yeniden başlatılmadan önce bu durumu komşularına (neighbor) bildirmektedir.

Ayrıca yeri gelmişken SQL Azure Veri Merkezleri ve Sunucuları hakkında biraz konuşalım.

Veri Merkezleri Hakkında

Microsoft’un dünya genelinde sahip olduğu veri merkezi sayısı güvenlik sebebiyle tam olarak açıklanmamaktadır. Sadece, 10’dan fazla 100’den az olduğu belirtilmekte, ayrıca gene güvenlik nedeniyle bu veri merkezlerinden sadece 6 tanesinin yeri bilinmektedir. Bu 6 veri merkezi Chicago, San Antonio, Dublin, Amsterdam, Singapore ve Hong Kong’da konuşlanmış durumdadır.

Veri Merkezlerin mimarisi hakkında genel bir bilgi edinmek için aşağıdaki videoları izlemenizi tavsiye ederim.

Chicago veri merkezi hakkında bazı detaylar bulunmakta. Microsoft’un bu veri merkezi için 500 milyon dolar gibi bir rakam harcadığı söylenmekte. 65.000 m2 alana yayılı bu devasa yapıda 112 adet 40’lık sunucu konteynırları bulunmakta ve bu konteynırların içinde de toplamda 224 bin sunucu yer alıyor. Aşağıda resimde Chicago veri merkezinde bulunan çiftli konteynırları görebilirsiniz.

6

Aşağıda ise Dublin veri merkezinin kuş bakışı çekilmiş bir fotoğrafını görebilirsiniz.

7

Şimdi biraz da konteynırlar içinde bulunan sunucular hakkında bilgi verelim. Azure’da bulunan sunucular 32 GB RAM, 8 core CPU ve 12 fiziksel disk içeren sunuculardır ve fiyatları yaklaşık olarak 3500 dolardır. Fiyatının böyle uygun olmasından dolayı Ring Topology sayesinde çalışamaz durumda olduğu belirlenen bir sunucu çalışmama sebebi ister fiziksel disk bozulması gibi büyük bir sıkıntı olsun, ister SQL Azure Servisinin çalışmaması gibi küçük bir sıkıntı olsun, veri merkezinden çıkartılmaktadır. Tamir yapılması gibi bir durumla uğraşılmamaktadır. Çünkü sunucuyu tamir etme maliyetinin sunucunun kendi maliyetinden daha yüksek olduğu düşünülmektedir.

SQL Azure’da Güvenlik

Veritabanını bulutta bulundurmak herkesin kafasında bir soru işareti bırakmaktadır: SQL Azure’da gerçekten verinin güvenliği sağlanabiliyor mu?

SQL Azure’un hatta tüm bulut mimarisinin baş etmeye çalıştığı en önemli sorun ya da insanların aklındaki kırılması en zor tabu bu konudur.

Örneğin, SQL Azure Türkiye kullanımına açılsa dahi bankaların kullanımı için uygun değildir. Çünkü BDDK, banka verilerinin yurtdışında barındırılmasına onay vermemektedir. Kısa vade de Türkiye’de bir veri merkezi kurulması öngörülmediği için bankalarda SQL Azure kullanımı oldukça zor gözükmektedir. Tabii ki ana bankacılık dışında kalan veritabanları SQL Azure’a taşınabilir. Bu konuda BDDK’nın herhangi bir yaptırımı bulunmamaktadır. Örneğin banka içi geliştirilen, iç kontrol ile alakalı, finansal bilgi içermeyen veritabanları SQL Azure üzerinde bulundurulabilir.

Güvenlik açısından Windows Azure sunucusu ile SQL Azure sunucusu arasında SQL Azure Firewall bulunmaktadır. Yapıyı şu şekilde özetleyebiliriz.

8

Bağlantının sağlanması için bağlantı kuracak istemcinin ya da sunucunun ip bilgisinin SQL Azure üzerinde yapılandırılması gerekir. (Daha sonraki demolarımızda bu işleme adım adım değineceğiz) Bu sayede denial-of-service (DoS) ataklarının önüne geçilmesi amaçlanmaktadır.

Ayrıca uygulama ile SQL Azure arasında kurulan bütün bağlantıların SSL encrypted olması şarttır. Uygulama sunucusu  Encrypt = True anahtar kelimesi ile bağlantı kurmalı ve bu şekilde de man-in-the-middle atakların önüne geçilmelidir.

Migration – Deployment

SQL Azure kullanmaya karar verdikten sonra, hali hazırda kullandığımız veritabanlarını SQL Azure’a taşımamız gerekmekte. Ya da yeni geliştirdiğimiz uygulamaların veritabanı olarak SQL Azure’u kullanmalıyız.

Microsoft, Migration ve Deployment için şu seçenekleri bizlere sunmaktadır.

  • Generate Script Wizard : SQL Server 2008 R2 ve sonraki versiyonlarda Generate Script Wizard kullanılarak schema (tablo,sp vs.) ve veri için deployment scripti oluşturulabilir. 2008 R2’dan önceki versiyonlarda da Generate Script özelliği bulunmasına rağmen bu versiyonlarda SQL Azure’a özel script oluşturulamamaktadır. Dolayısıyla SQL Azure’a yapacağımız taşımalarda eğer Generate Script Wizard kullanmak istiyorsak Management Studio için 2008 R2 versiyonunu kullanmamız gerekmektedir. Ayrıca şu notu da düşmemizde fayda var. Çok fazla veri içeren veritabanlarını bu yöntem ile taşımak biraz zor olabilmektedir. Bu durumda SSIS çözümünü değerlendirmenizi tavsiye ederim.
  • SQL Azure Migration Wizard (SQLAzureMW) : SQL Azure Migration Wizard, 2005 ve 2008 SQL Server veritabanlarını Azure’a taşımak için kullanabileceğiniz, CodePlex üzerinden dağıtılan ücretsiz bir araçtır. Ayrıca SQLAzureMW ile SQL Azure üzerine taşınmak istenen veritabanının SQL Azure ile uyumlu olup olmadığı kontrolü de yapılabilmektedir.
  • SSIS : SQL Server Integration Service ile veritabanında bulunan verilerin SQL Azure’a taşınması mümkündür. Bu yöntemle ayrıca periyodik olarak veritabanından SQL Azure’a otomatik veri gönderme imkânı sunulabilmektedir.
  • Bulk Copy: Bu yöntemle de verilerin “bulk insert” mantığıyla SQL Azure’a taşınması mümkündür.

Gördüğünüz gibi hali hazırda kullandığınız ya da yeni geliştirdiğiniz veritabanlarını SQL Azure’a taşımak için birden fazla çözüm sunulmakta.  Her bir çözümün farklı artıları ve eksileri bulunmaktadır. Bu çözümleri değerlendirip hangisi sizin ortamınız için en uygunsa o çözümü kullanmanızda fayda vardır.

Uygulama Geliştirme konusunda şöyle bir not düşmek istiyorum: SQL Azure’da barındıracağınız veritabanlarına erişen uygulamaları daha önce konuştuğumuz gibi kendi sunucularınızda (code-far) ya da Windows Azure’da (code-near) barındırma şansınız var. Hangi yapıyı kullanacak olursanız olun uygulamayı geliştirirken veritabanını nerede barındıracağınızı düşünerek işe başlamanızı tavsiye ederim. Bu size daha hızlı bir uygulama geliştirme süreci oluşturacaktır. En son taşıma (deployment) aşamasında yukarıda bahsettiğim yöntemlerden birini kullanarak veritabanını taşıyıp, uygulamada da gerekli connection string değişikliğini yaparak taşıma işlemini tamamlayabilirsiniz.

T-SQL Kapsamı

SQL Azure’da T-SQL kapsamı, SQL Server’ın seçilmiş alt kümesi diyebiliriz. T-SQL komutlarını SQL Server mantığında kullandığımız şekliyle SQL Azure’da da kullanabiliriz. Yalnız burada bazı kısıtlamalar bulunmakta: bazı syntax’ları kullanamamaktayız. Bunların detayına daha sonraki makalelerde ayrıntılı olarak değineceğim.

SQL Server – SQL Azure Farklılıkları

SQL Azure’da bütün SQL Server özellikleri(feature) desteklenmemektedir. Örneğin Analysis Services, Replication, SQL Server Agent ve Service Broker SQL Azure’da şu an için bulunmamaktadır. (Bu özelliklerden bazılarının sonraki versiyonlarda geleceği söylenmektedir.)

Fiziksel yönetim Microsoft’ta olduğu için, fiziksel kaynakları direk ilgilendiren Resource Governer gibi özellikler de SQL Azure’da yer almamaktadır.

Ayrıca SQL trace flags, SQL Server Profiler ve Database Tuning Advisor‘da SQL Azure’da yer almayan özelliklerdir.

Şimdi SQL Server ile SQL Azure karşılaştırmasına daha detaylı bakalım:

  • Oluşturulacak veritabanı boyutu açısından SQL Server kullanımında bir sınırlama yoktur, SQL Azure’da ise veritabanı boyutu en fazla 50 GB olabilir. Bu maksimum boyut SQL Azure sürümüne göre değişiklik göstermektedir. SQL Azure’da bulunan Sharding teknolojisi ile veritabanını yatay olarak farklı fiziksel sunucularda partition yaparak sınırsız boyutta bir veritabanı oluşturmak mümkündür. Sharding teknolojisine daha sonraki makalelerimde daha detaylı olarak değiniyor olacağım.
  • SQL Azure’a, Management Studio’nun 2008 R2 veya daha üst versiyonları ile bağlanılabilir. Ayrıca web tabanlı Database Manager (Project Code-Named “Houston”) ile de SQL Azure’a bağlantı yapmak mümkündür.
  • SQL Azure sadece SQL Server Authentication’ı desteklemekte, Windows Authentication’ı desteklememektedir.
  • SQL Azure’da heap tablo bulunmasına izin verilmemektedir. Yani her tabloda Clustered Index bulundurulması zorunludur. Bu zorunluluğun detaylarına daha önce değinmiştim. Kısaca üzerinden geçmek gerekirse, yüksek süreklilik için tablo üzerinde bir anahtar alana ihtiyaç vardır. Bu yüzden her tabloda bir Clustered Index bulundurulması istenmektedir.
  • Use komutu SQL Azure’da kullanılamamaktadır. Veritabanları arası geçiş yapılmak isteniyorsa, geçilmek istenen veritabanına doğrudan bağlantı yapılması gerekir. Use komutunun kullanılamamasının sebebi, veritabanlarının her birinin farklı fiziksel sunucularda bulunabilme ihtimalidir (Load Balancing). Use komutunu kullanmak istediğimizde veritabanı farklı fiziksel sunucuda olduğu için farklı bir bağlantı kurmamız gerektiğinden Use komutunun kullanılmasına izin verilmemektedir.
  • Use komutu kullanılamadığı için application connection string’de initial catalog bilgisi verilmesi ve hangi veritabanına bağlantı kurulmak isteniyor ise bunun belirtilmesi gerekmektedir.
  • Sunucuya bağlantı 1433 numaralı port üzerinden yapılmaktadır ve bu port değiştirilememektedir. Yani dynamic port kullanılamamaktadır.
  • Transactional Replication, Log Shipping ve Mirroring SQL Azure’da desteklenmemektedir.
  • SQL Server Agent, SQL Azure’da bulunmamaktadır.
  • SSIS‘da SQL Azure’da bulunmayan bir özelliktir.
  • Kullandığın kadar öde yaklaşımı sayesinde veritabanı boyutuna ve aylık veri transfer hacmine göre ücretlendirme yapılır. Bu şekilde kullanılmayan bir disk kaynağı için yatırım yapılmamış olur.
  • Collation olarak sadece SQL_Latin1_General_CP1_CI_AS desteklenmektedir. Şu anda bu sıkıntı kolon bazında collation verilerek aşılabilir. Daha sonraki sürümlerde yeni collation’ların destekleneceği belirtilmektedir.
  • SQL Azure’a özel yeni bazı monitoring DMV’leri bulunmaktadır. (sys.bandwidth_usage, sys.dm_database_copies vs.)
  • SQL Azure’da veritabanları default olarak Read Committed SnapShot Isolation Level’dadır. SQL Server’larda ise varsayılan (default) olarak Read Committed’dır. Ayrıca SQL Server’ların seçenek kısmından isolation level değiştirebiliyor iken, SQL Azure’da seçenek değişikliği yapılamadığı için isolation level değişikliği sadece explicitly olarak yani connection için değiştirebilir. Bu değişiklik transaction başlamadan önce “SET TRANSACTION ISOLATION LEVEL” komutu kullanılarak yapılır.

Son olarak yararlı bir kaç SQL Azure kaynağı vererek yazımı sonlandırmak istiyorum. Daha sonraki yazılarımda SQL Azure kullanımını canlı demolar yaparak daha detaylı inceliyor olacağız.

 

Yazan : Turgay Sahtiyan

Teknik İnceleme : Önder Yıldırım

Yayınlanma Tarihi: Mart 2011

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’de örnek database olarak kullanmak için AdventureWorks DB’sini aşağıdaki adresten indirebilirsiniz.

[more]

http://msftdbprodsamples.codeplex.com/releases/view/55330

Bu kurulum sadece Denali üzerinde kullanılabilir, diğer SQL Server versiyonlarında kullanılamaz.

Ayrıca Denali kurulumu yapılırken Full Text Search’ün de kurulmuş olması gerekmektedir.

 

İ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 aralar sıkça kullandığım ve işimi oldukça kolaylaştıran ufak bir syntax’tan bahsetmek istiyorum.

GO komutu ile belirli bir kod bloğunu n kere çalıştırmak.

[more]

Fazla uzatmadan syntax’ı görelim.

insert tblGoDeneme 
  select 1,'a' 
GO 100

 

Bu script, GO’nun yanına yazılan 100 rakamı sayesinde tabloya 100 kayıt insert edecektir.

Aynı işlemi while döngüsü kurarakta yapmak mümkün. Ama sizin de görebileceğiniz gibi GO ile yapmak çok daha temiz ve kısa bir script sağlamakta.

 

İ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