MERGE Type 1 Slowly Changing Dimension (SCD) Kullanımı

Serinin daha önceki yazılarında MERGE komutunun genel kullanımını ve performans önerilerini ele almıştık. İncelemek isterseniz aşağıdaki linkten erişebilirsiniz:

http://www.abdullahaltintas.com/index.php/sql-server-merge-komutu-kullanimi-ve-performans-onerileri/

Veritabanı sistemlerinde ETL süreçleri ile veri aktarımı çok sık karşılaştığımız durumlardan biridir. Özellikle OLTP sistemlerden DataWarehouse yapılarına veri aktarırken ETL süreçlerini ve toollarını kullanarak aktarımlar gerçekleştirmekteyiz. Microsoft SQL Server ürün ailesinde de bu amaçla kullanabileceğimiz SQL Server Integration Services (SSIS) adında bir servis bulunmaktadır. SSIS servisi ve SQL Server Data Tools (eski adıyla Business Intelligence Development Studio) kullanılarak ETL süreçleri tasarlanabilmektedir.

Temel ETL süreçlerinde en sık karşılaştığımız noktalardan biri daha önce aktarımı yapılmış olan bir tablodaki verilerin incremental bir yapıda (sadece değişen verilerin) ele alınması sürecidir. Daha önce kaynak sistemden verileri alınmış ve hedef sisteme yüklenmiş bir tablo için bütün verinin doldur boşalt yöntemiyle (verilerin silinip tekrar yüklenmesi) tekrar yüklenmesi performans açısından bizleri olumsuz etkilemektedir. Dolayısıyla en son aktarımdan sonra sadece değişikliğe uğramış olan kayıtların ve yeni eklenen kayıtların ele alınması performansımızı arttıracaktır. Bu işleme literatürde Slowly Changing Dimension (SCD) denilmektedir. SSIS içerisinde de bu işlemi gerçekleştirmek için kurulumla birlikte gelen SCD komponenti bulunmaktadır. Ancak bu SCD komponenti row by row çalıştığı için büyük boyutlara sahip tablolarda işlem yaparken performans açısından oldukça yavaş çalışmaktadır. SCD kullanımına alternatif olarak SQL Server 2008 ile birlikte hayatımıza giren MERGE komutu kullanılarak çok daha performanslı bir çözüm üretilebilmektedir. Bu yazımızda MERGE komutunu kullanarak Type 1 SCD çözümünü nasıl gerçekleştirebileceğimizi ele alacağız.

Öncelikle örnekleri yapabilmemiz için gerekli olan kaynak ve hedef tablolarımızı oluşturalım. Örneğimizde EmployeeSource isminde bir kaynak tablomuzu ve aynı yapıya sahip EmployeeTarget isminde bir hedef tablomuzu kullanacağız. Bu iki tablonun scriptleri aşağıdaki gibidir:

create table EmployeeSource
(
EmployeeID int,
FirstName nvarchar(50),
LastName nvarchar(50),
Title nvarchar(100),
RecruitmentDate datetime,
Salary decimal,
IsActive bit
)
GO


create table EmployeeTarget
(
EmployeeID int,
FirstName nvarchar(50),
LastName nvarchar(50),
Title nvarchar(100),
RecruitmentDate datetime,
Salary decimal,
IsActive bit
)
GO

Bu iki tabloyu create ettikten sonra içine örneğimizi gerçekleştireceğimiz birkaç tane veri girişi yapalım:

insert into dbo.EmployeeTarget 
values
(1, N'Abdullah', N'Altıntaş', N'Takım Lideri', '20120721', 1000, 1),
(2, N'İsmail', N'Adar', N'DBA', '20090101', 1500, 1),
(3, N'Yusuf', N'Boğatepe', N'Danışman', '20140103', 1000, 1),
(4, N'Merve', N'Sağlam', N'Kıdemli Danışman', '20150618', 1800, 1)
GO

insert into dbo.EmployeeSource
values
(1, N'Abdullah', N'Altıntaş', N'Takım Lideri', '20120721', 2000, 1),
(2, N'İsmail', N'Adar', N'DBA', '20090101', 1500, 1),
(3, N'Yusuf', N'Boğatepe', N'Danışman', '20140103', 1000, 1),
(5, N'Şeydanur', N'Sandıkçı', N'Danışman', GETDATE(), 1000, 0)
GO

Ardından bu komutları da çalıştırdıktan sonra tablolarımız üzerindeki verileri kontrol edelim:

select * from dbo.EmployeeSource
select * from dbo.EmployeeTarget

Sorguyu çalıştırdığımızda verileri aldığımız kaynak tablomuzu temsil eden EmployeeSource tablosu ile verileri aktarmayı amaçladığımız hedef tablomuz EmployeeTarget tablosunda bazı verilerin farklı olduğunu görebilirsiniz. Örneğimizde 1 nolu id ye sahip Abdullah Altıntaş’ın kaynak tablodaki maaş bilgisi değişmiş ve 1000 yerine 2000 değerini almış, 2 ve 3 nolu id ye ait kayıtlarda herhangi bir değişiklik yapılmamıştır. Ayrıca kaynak tabloda hedef tablosunda henüz bulunmayan 5 nolu id ye sahip Şeydanur Sandıkçı eklenmiş olmakla beraber hedef tablosunda artık kaynak tabloda bulunmayan 4 nolu id ye sahip Merve Sağlam kaydı bulunmaktadır.

kaynak ve hedef

Örneğimizdeki amacımız kaynak EmployeeSource tablomuza yeni eklenen ve henüz hedef tablomuz EmployeeTarget‘a eklenmemiş olan kayıtların INSERT edilmesini sağlamak ve daha önce aktarımı yapıldıktan sonra kaynak EmployeeSource tablomuzda güncellenmiş kayıtların güncel hallerinin EmployeeTarget tablosuna aktarılmasını sağlamak olacaktır. Böylece Type 1 SCD yapısını MERGE komutu ile kullanarak sadece değişikliğe uğramış olan kayıtların işlenmesini sağlamış olacağız. Bu açıdan tablomuzda sadece maaş kolonu üzerinde yapılan değişikliklerin hedef tablo üzerinde halihazırda bulunan kayıt için overwrite edilerek güncellenmesini sağlayacağız.

 Bu işlemi gerçekleştirmek için aşağıdaki kod bloğunu çalıştırmamız gerekmektedir;

MERGE INTO dbo.EmployeeTarget as t
USING dbo.EmployeeSource as s
ON t.EmployeeID = s.EmployeeID
WHEN MATCHED AND t.Salary <> s.Salary  THEN
	UPDATE SET  t.Salary = s.Salary
WHEN NOT MATCHED BY TARGET THEN
	INSERT (EmployeeID, FirstName, LastName, Title, RecruitmentDate, Salary, IsActive)
	VALUES (s.EmployeeID, s.FirstName, s.LastName, s.Title, s.RecruitmentDate, s.Salary, s.IsActive);

Yukarıdaki kod bloğu ile kaynak ve hedef tablolarımızda bulunan veriler EmployeeID kolonları üzerinden kontrol edilerek ilgili kaydın daha önce aktarımının yapılmış olup olmadığını kontrol edilmektedir. Ardından her iki tabloda da eşleşen EmployeeID’ler daha önce aktarımı yapılmış olan kayıtları temsil ettiği için bu kayıtların Salary kolonunda değişiklik yapılıp yapılmadığını kontrol edilmektedir. Değişikliğe uğramış olan kayıtlar için UPDATE komutu ile ilgili kaydın maaş bilgisi güncellenmektedir. Bu şekilde ilgili kayıt overwrite edilerek maaş bilgisi güncellenmekte ve Type 1 SCD gerçekleştirilmektedir.

Aynı zamanda EmployeeID’leri eşleşmeyen kayıtlar için de henüz aktarımı yapılmadığı için INSERT komutu kullanılarak hedef tabloya eklenmesi sağlanmaktadır. Yukarıdaki komutu çalıştırdığımızda aşağıdaki gibi bir çıktı üretmektedir;

merge type1

Görüldüğü üzere 1 nolu kayıt Abdullah Altıntaş’a ait Salary kolonundaki bilgi 2000 olarak update edilmiş ve ilgili kayıt overwrite edilerek bu güncelleme yapılmıştır. Aynı zamanda 5 nolu kayıt Şeydanur Sandıkçı da yeni gelen bir kayıt olduğu için EmployeeTarget tablosuna INSERT edilmiştir.

Bu yazımızda MERGE komutunu kullanarak Slowly Changing Dimension (SCD) Type 1 işlemini nasıl gerçekleştirebileceğimizi ele almış olduk. Yaptığımız örnek üzerinde de değişikliğe uğrayan kayıtların nasıl overwrite edildiğini görmüş olduk. Bir sonraki yazımızda MERGE komutu kullanılarak Type 2 SCD işlemini nasıl gerçekleştirebileceğimizi göstereceğiz. Umarım faydalı olur.

Keyifli okumalar…

Yazar: Abdullah ALTINTAŞ

 

Veritabanı Kavramı ve Veritabanı Yönetim Sistemleri (Level 1 – 01) – Video

Uzun zamandır teknik konularla ilgili makaleler yazmaktayım. Makale yazmak ve sorunlara ait çözümleri sunmak gerçekten keyifli oluyor. Ancak bazen bir sorunun çözümü için çok fazla ekran görüntüsü ekleme ihtiyacı olabiliyor. Bu nedenle bazı konuları makale olarak yazmak yerine video çekimi yaparak paylaşmanın da oldukça yararlı olacağının farkına vardım. Bu nedenle uzun süredir yapmak istediğim video serisine bu hafta itibarıyla başlıyorum. İlk olarak Microsoft SQL Server’a ait konuları Level – 1 (Başlangıç),  Level – 2 (Orta) ve Level – 3 (İleri Seviye) olacak şekilde sınıflandırarak çekeceğim. Çektiğim video serilerini youtube kanalım üzerinden sizlerle paylaşıyor olacağım. Ayrıca içeriğin dağılmaması açısından çektiğim videoları fırsat buldukça www.abdullahaltintas.com adlı blogumda da paylaşıyor olacağım.

İlk olarak Başlangıç düzeyi konuları ele aldığım videoları bu video ile birlikte yayınlamaya başlıyorum. Umarım faydalı olur.

Bu video içinde;

  • Data & Database Concepts
  • Relational Database Management Systems (RDBMS)
  • SQL Server as a RDBMS
  • SQL Server Editions & Versions
  • SQL Server Management Studio (SSMS)

konularını bulabilirsiniz. Ayrıca slayt setini de aşağıya ekliyorum.

Keyifli izlemeler 🙂

SlideShare Linki:

http://www.slideshare.net/AbdullahALTINTA/veritaban-kavram-ve-veritaban-ynetim-sistemleri-level-1-01-63526506

Ayrıca slayta aşağıdan da erişebilirisniz;

SQL Server Execution Plan Mimarisi Kitabımız Yayınlandı!!!

SQL Server ile çalışırken dikkat ettiğimiz en önemli konulardan biri SQL Server’da çalıştırdığımız sorguların performansıdır. Yazdığımız sorguların performanslı bir şekilde çalışması bizler için oldukça önem arz etmektedir. Bu nedenle çoğu uygulama geliştirici ve veritabanı yöneticisi tarafından çalıştırılan sorguların hangi çalıştırılma yöntemini kullanarak işleme alındığını incelemek ve buna uygun müdahalelerde bulunmak gerekebilir. İşte bu nedenle SQL Server’ın bir sorguyu nasıl çalıştıracağının veya nasıl çalıştırdığının yöntemi Execution Plan olarak bilinmektedir. Bu kitabımızda SQL Server’a ait Execution Plan Mimarisi’ni detaylı olarak ele aldık. Kitabın yazılmasında hem arkadaşım hem de meslektaşım olan İsmail Adar ile birlikte rol almak benim için büyük bir keyifti. Umarım okurken sizler de aynı keyfi alırsınız…

 Kitabı aşağıdaki linkten indirebilirsiniz. Keyifli okumalar…

SQL Server Execution Plan Kitabı

kitap kapak

SQL Server Performance – Tarih Dönüştürme İşlemleri

SQL Server‘da kullanılan en yaygın veri tiplerinden birisi de tarihsel veri tipleridir. Microsoft SQL Server 2008 ile birlikte yeni gelen tarihsel veri tipleri de dahil SQL Server 2016‘da hala kullanımda olan 6 adet tarihsel veri tipi (date, datetime, datetime2, smalldatetime, datetimeoffset, time) bulunmaktadır. Bu veri tiplerinden uygun olan seçilerek tarihsel veriler tutulabilmekte ve gerektiğinde sorgularda kullanılarak istenilen veriler getirilebilmektedir. Ancak çoğu zaman tarihsel veri tiplerini sorgularken kullanılan yönteme bağlı olarak sorgu performansı olumsuz etkilenebilmektedir. Bu yazımızda SQL Server’da tarihsel verileri sorgularken performans açısından dikkat etmemiz gereken noktalardan birini ele alacağız.

SQL Server’da tarih verileri üzerinde dönüşüm işlemleri bazen formatlama bazen de filtreleme gereksinimleri yüzünden çok sık yapılmaktadır. Özellikle bir tabloda datetime tipinde kullanılmış olan bir kolon varsa ve belli bir gündeki tüm verilere ihtiyaç duyuluyorsa bu durumda sık başvurulan yöntemlerden biri convert() fonksiyonunun kullanılmasıdır. Genellikle convert() fonksiyonu style 112 parametresi ile kullanılarak ilgili tarih verisinin sadece gün ay yıl bilgisi alınıp gerekli tarih verisi ile karşılaştırılır.

Yazım bakımından çok pratik olan ve sık kullanılan bu yöntem bazı durumlarda bize performans sorunu yaratacaktır. Bunun yerine ya cast(), convert() gibi fonksiyonları kullanmadan değeri manuel yapmamız gerekir ya da cast(), convert() gibi dönüşüm fonksiyonlarını kullanırken veri tipini doğru seçmemiz gerekir.

Konuyu bir örnek ile daha detaylı ele alalım. Aşağıdaki gibi üç kolondan oluşan bir tablo oluşturup tablodaki tarih kolonuna rastgele 500000 tarih verisini insert edelim.

-- Tablomuzu oluşturalım
create table tarihTest
(
id int identity primary key,
tarih datetime,
deger char(500) default 'Abdullah'
)


-- Tablomuza 500000 adet kayıt ekleyelim
insert into tarihTest (tarih)
select DATEADD(MI, RAND()*10000, GETDATE())
GO 500000


-- Tarih kolonundaki performansı incelemek için index oluşturalım
create index ix_tarih on tarihTest (tarih)

Yukarıdaki kod bloğundaki gibi tablomuzu oluşturup 500000 kaydı rastgele insert ettik. Daha sonra tarih kolonu üzerinde sorgularımızda kullanmak üzere index oluşturduk.

Tablomuz hazır olduğuna göre bu aşamada ilk olarak sık kullanılan convert() fonksiyonunu 112 style parametresi ile kullanarak varchar veri tipine dönüştürerek işlem yapalım. Ardından aynı sorguyu yine cast() veya convert() fonksiyonu ile birlikte, bu sefer varchar veri tipine değil date veri tipine dönüştürelim. Sorgumuzun başında IO değerlerini karşılatırmak için set statistics io on ifadesini de eklemeyi unutmayalım.

Sorgularımız aşağıdaki gibi olacaktır:


set statistics io on;

declare @sdate datetime = '2016-06-16 11:19:39.530'

select tarih from tarihTest
where CONVERT(varchar, tarih, 112) = CONVERT(varchar, @sdate, 112)

select tarih from tarihTest
where CAST(tarih as date) = CAST(@sdate as date)

Her iki sorguyu da çalıştırdığımızda ikisinden de aynı sonucun döndüğü görebiliyoruz. Şimdi sorgu penceremizin Messages kısmına geçerek IO değerlerini inceleyelim:

tarihsonuc1

Yukarıdaki resimde de görebileceğimiz üzere ilk sorgumuz 1127 IO yaparak sorgu sonucuna erişirken ikinci yazdığımız sorgu aynı sonuca sadece 3 IO yaparak erişmiştir. Şimdi de sorgularımızın execution planlarını inceleyelim:

tarihsonuc2

Execution planları yukarıdaki resimde görüldüğü gibi incelediğimizde ilk sorgu için index scan işlemi yapılırken ikinci sorgu için aynı index üzerinde index seek işlemi yapılmıştır. Bu sebeple IO değerleri arasında bu denli fazla fark oluşmaktadır. Ayrıca dikkatinizi çekmek istediğim bir başka nokta da ilk execution planda Select operatörü üzerinde bir Warning yani uyarı çıkmaktadır. O uyarıyı incelediğimizde bize aşağıdaki gibi bir dönüşüm işleminin execution plan seçimine etki edeceğini belirtmektedir:

tarihsonuc3

Görüldüğü üzere tarihsel veriler üzerinde cast() ve convert() gibi fonksiyonlarla dönüşüm işlemi yaparken dönüşüm yapmak istediğimiz veri tipinin doğru bir şekilde tercih edilmesi performanslı sorgu oluşturmak için hayli önemlidir.

Bu yazımızda SQL Server‘da kullanılan tarihsel verileri dönüşüm fonksiyonları ile dönüştürerek karşılaştırma yaparken dikkat edilmesi gereken noktalardan biri olan hedef veri tipinin doğru belirlenmesi konusunu ele aldık. Oluşturduğumuz tablo üzerinde yapılan örnekte yazılan iki farklı sorgunun performans karşılaştırmasını gösterdik. Umarım faydalı olur.

Bir sonraki yazımızda görüşmek dileğiyle. Keyifli okumalar…

Yazar: Abdullah ALTINTAŞ

SQL Server’da Fast N Seçeneğinin Kullanımı

SQL Server‘da yazılan sorguların performanslı bir şekilde çalışmalarını sağlamak için kullanılan çeşitli seçenekler bulunmaktadır. Bu seçenekleri kullanarak daha optimize sorgular yazılabilmekte ve Execution Plan‘lar incelenerek  yazılan sorguların karşılaştırmaları yapılabilmektedir. Bu yazımızda bu seçeneklerden biri olan Fast N seçeneğini ele alacağız.

SQL Server’da Execution Plan’a müdahale ederken kullanılan faydalı kullanımlardan biri de Fast N seçeneğidir.  Sıkça karıştırılan bu operatörü kullanarak, SQL Server’ın sorgu sonucunda gösterilecek olan sonuç kümesinin içinde N (N pozitif bir sayı) tane kaydı en hızlı getirecek şekilde Execution Planı optimize etmesini sağlayabiliriz. Fakat dikkat edilmesi gereken nokta burada verilen N pozitif bir sayı olmakla beraber gösterilecek kayıt sayısı ile alakalı değildir. Şöyle ki sorgumuzun sonucunda 1000 tane kayıt döndüğü durumda bu 1000 kaydın ilk 10 tanesinin olabilecek en hızlı bir şekilde ekrana getirilmesi ve kalan 990 tanesinin de ilk 10 tane hızlı bir şekilde gösterildikten sonra normal bir şekilde ekranda gösterilmesi isteniyorsa SQL Server’da bulunan Fast N seçeneği kullanılarak bu işlem çok daha performanslı bir şekilde gerçekleştirilebilmektedir. Ancak bu operatör çoğu zaman kayıt kümesinin N tane kayıt ile sınırlandırılacağı olarak düşünülmektedir. Bu yanılgıya düşülmemeli ve buna göre sorgular yazılmalıdır.

Şimdi Fast N operatörünün nasıl kullanıldığını bir örnek üzerinde görelim. İlk sorgumuzda Fast N operatörünü kullanmadan Execution Planımızı inceleyelim daha sonra aynı sorgumuzu Fast N operatörünü kullanarak SQL Server’ın kullanacağı Execution Planı inceleyelim ve karşılaştıralım.

select *
from Production.Product p
inner join Sales.SalesOrderDetail sod
on p.ProductID = sod.ProductID

Yukarıdaki sorgumuzda Production.Product tablosu ile Sales.SalesOrderDetail tablosunu Inner Join ile birleştirdik. Şimdi Execution Planımızı inceleyelim.

execution plan1

Yukarıdaki resimde sorgumuzun Execution planını incelediğimizde Sales.SalesOrderDetail tablosundaki veriler Clustered Index Scan işlemi ile okunup Compute Scalar operatörü ile tabloda bulunan Computed Column (Hesaplanmış Sütun) değeri hesaplanarak elde edilen sonuç kümesi ile Production.Product tablosu üzerinde yapılan Clustered Index Scan işleminin sonucu ile Hash Match Join işlemi ile birleştirilmiştir. Şimdi sorgumuza Fast 5 değerini ekleyerek SQL Server’a ilk 5 kaydın en hızlı geleceği şekilde sorgumuzun Execution Planını optimize ettirelim ve çıkan Execution Planı inceleyelim. 

select *
from Production.Product p
inner join Sales.SalesOrderDetail sod
on p.ProductID = sod.ProductID
option(fast 5)

Yukarıdaki sorgumuza farklı olarak sadece option(fast 5) operatörünü ekledikten sonra şimdi Execution Planımızdaki değişiklikleri inceleyelim.

execution plan2

Yukarıdaki resimdeki Execution Planımızı incelediğimizde öncekine benzer olarak Sales.SalesOrderDetail tablosundaki veriler Clustered Index Scan işlemi ile okunup Compute Scalar operatörü ile tabloda bulunan Computed Column (Hesaplanmış Sütun) değeri hesaplanarak elde edilen sonuç kümesi önceki Execution planımızdan farklı olarak Production.Product tablosu üzerinde Clustered Index Seek işlemi yapılmış ve elde edilen sonuçlar Nested Loop Join operatörü ile birleştirilmiştir.

Aslında iki Execution Planımızda farklı olan kısımları incelediğimizde ilk planda Production.Product tablosu üzerinde Clustered Index Scan işlemi yapılmıştır. SQL Server’ın bunu seçmesinin sebebi bu tablodaki tüm kayıtlara erişmemiz gerektiğinden dolayıdır ve bu sebeple SQL Server Scan işlemini daha hızlı sonuçlandıracağı için Clustered Index Scan işlemini tercih etmiştir. Fakat Fast 5 seçeneğini kullandığımız sorgumuzda Product tablosu üzerinde Clustered Index Scan yerine Clustered Index Seek işlemi tercih edilmiştir. Bunun sebebi ise Fast 5 operatörünü kullandığımız için SQL Server ilk 5 kaydı en hızlı getirmek için Clustered Index Seek işlemini tercih etmesidir. Genel kanı olarak Seek işleminin Scan işlemine göre daha iyi olduğu düşünülse bile Seek işleminin yapıldığı veri kümesi büyüdükçe sorgumuzun performansı da düşecektir. Aynı zamanda iki Execution Plan arasındaki bir diğer fark ise seçilen Join tipidir. İlkinde Hash Match Join seçilmesinin sebebi sıralı olmayan iki büyük veri kümesinin birleştirilmesidir. Fakat ikinci Execution planda ise Nested Loop Join seçilmiştir. Bunun sebebi ise Fast 5 ile yaptığımız optimizasyonda SQL Server beş kaydın okunması senaryosuna göre sorgumuzun Execution planını optimize etmiş ve Sales.SalesOrderDetail gibi büyük bir tablo ile 5 kayıt içeren bir veri kümesinin birleştirilmesinde doğal olarak Nested Loop Join işlemini seçmiştir.

Fakat Fast 5 seçeneği yerine sonuç kümesine yakın bir değer kullanmış olsaydık SQL Server Execution Planı değiştirmeyecekti. Örneğin aynı sorgumuzu Fast 1000 olarak çalıştırıp Execution planını inceleyelim.

select *
from Production.Product p
inner join Sales.SalesOrderDetail sod
on p.ProductID = sod.ProductID
option(fast 1000)

execution plan3

Fast N operatörü özellikle bazı durumlarda sorgu performansını beklenenden fazla artırmaktadır. Örneğin sorgularımızda top kullandığımızda gelen sonuç kümesinin sıralı olması önemli değilse ve bu sebeple order by operatörünü kullanmıyorsak Fast N operatörü performans açısından yararlı olacaktır. Şimdi bunu bir örnek üzerinde görelim.

set statistics io on;

select top 5 p.*
from Production.Product p
inner join Sales.SalesOrderDetail sod
on p.ProductID = sod.ProductID


select top 5 *
from Production.Product p
inner join Sales.SalesOrderDetail sod
on p.ProductID = sod.ProductID
option(fast 5)

Yukarıdaki iki sorgumuzdan da 5 kayıt gelecektir. Şimdi sorgularımızı çalıştırdıktan sonra sonuçları IO açısından değerlendirelim.

execution plan4

Yukarıdaki resimde gösterilen IO sonuçlarını incelediğimizde sadece Top 5 ile çalıştırdığımız sorgumuzdaki logical read değeri 468 iken Top 5 operatörünü aynı yazanda Fast 5 ile kullandığımızda ise logical read değerimiz 10 olacaktır.

Bu yazımızda SQL Server’da performans açısından bazı durumlarda faydalı olabilecek bir seçenek olan Fast N operatörünü ele aldık. Umarım faydalı olur. Bir sonraki yazımızda görüşmek dileğiyle.

Keyifli okumalar…

Yazar: Abdullah ALTINTAŞ

Microsoft Türkiye Yaz Okulu 2016 Etkinliği’nde Buluşalım…

Microsoft Türkiye tarafından düzenlenen ve her yıl yaz döneminde Türkiye’nin çeşitli üniversitelerinden öğrencilerin katılımıyla gerçekleştirilen Microsoft Türkiye Yaz Okulu’nun 2016 yaz dönemi için kayıtlar tamamlanmak üzere. Bu yıl da sektörde deneyimli bir çok profesyonelin katılımıyla düzenlenecek olan etkinlik yine dolu dolu geçecek. Biz de sunumlarımızla bu yıl da sizlere destek olacağız. Kayıt olmak ve detaylı bilgi sahibi olmak için aşağıdaki linkten faydalanabilirsiniz.

https://www.microsoft.com/turkiye/yaz-okulu/

summer-school

Etkinlikte görüşmek üzere…

Abdullah ALTINTAŞ