Performans sıkıntısı oluşan sorguları bulmak ve SQL Server'ın performansını arttırmak için DMV lerden faydanılabilir.
sys.dm_exec_requests, sys.dm_exec_sessions : Her iki view de server'da şu an çalışan istekleri getirir. Anlık olarak, uzun süren ve düşük performans gösteren sorguları bulmak için kullanılabilir.
sys.dm_exec_query_stats : Çalışan sorguların cache planlarını getirir.
sys.dm_exec_sql_text En kötü performanslı sorguyu tespit ettiğinizde, bu view i kullanarak sorgunun tam metnine ulaşabilirsiniz. DBCC INPUTBUFFER a benzer ve query handle parametresi alır. Query handle a sys.dm_exec_requests ve sys.dm_exec_query_stats view lerinde ulaşılabilir.
sys.dm_os_wait_stats Server bazında bekleme istatistiklerini getirir ve dar boğazları tepit etmek için kullanılabilir.
sys.dm_db_index_usage_stats Her bir indeksin kullanım istatistiklerini gösterir. Kullanılmayan ve az kullanılan indeksleri bulmak için kullanılabilir. Kullanılmayan indeklerin kaldırılması, veri güncelleme performansını arttırır, disk kullanımını azaltır.
DMV ler, SQL server'ın son açılışından itibaren olan istatistikleri gösterir.
sys.dm_db_missing_index_details Yeni indeks ihtiyacını tespit etmek için kullanılır.
4 Kasım 2010 Perşembe
31 Ekim 2010 Pazar
Partitioning Nedir?
SQL Server'da partitioning yapısını, bir kitapevinde, birbirleriyle ilgili kitapları aynı raflara, ilgili olmayan kitapları farklı raflara koymaya benzetebiliriz. Romanlar bir rafa, Bilgisayar kitapları başka bir rafa gibi.
Çok büyük bir tablomuz varsa, tablolarımızı bazı özelliklerine farklı partitionlara bölebilir ve performansımızı arttırabilir ve tablonun yönetemini kolaylaştırabiliriz. Örneğin bir satış tablosunu düşünün. Üzerinde binlerce kayıt olabilir. Ancak en çok bu yılın kayıtlarına bakar, diğer kayıtları daha az sorgularız. Sorgularımızda sql server'ın bir tablonun tüm kayıtlarını aramak yerine sadece daha az sayfayı taramasını, tabloyu bölerek sağlayabiliriz. Hatta eski kayıtlar ve yeni kayıtlar için farklı zamanlarda backup alabiliriz. Satırlara göre farklı bölümlere ayırmaya horizontal partitioning denir.
Eğer bir tablo üzerinde çok sık kullandığımız kolonların yanında çok ender sorguladığımız kolonlar varsa, tabloyu kolonlara göre de bölümlere ayırabiliriz. Buna da vertical partioning denir. Bir tabloyu satırlardan ve sütünlardan oluşan bir yapı olarak düşünürsek, bu durumda tabloyu dikey olarak bölmüş oluruz. Vertical partioning ismi de buradan gelir.
Çok büyük bir tablomuz varsa, tablolarımızı bazı özelliklerine farklı partitionlara bölebilir ve performansımızı arttırabilir ve tablonun yönetemini kolaylaştırabiliriz. Örneğin bir satış tablosunu düşünün. Üzerinde binlerce kayıt olabilir. Ancak en çok bu yılın kayıtlarına bakar, diğer kayıtları daha az sorgularız. Sorgularımızda sql server'ın bir tablonun tüm kayıtlarını aramak yerine sadece daha az sayfayı taramasını, tabloyu bölerek sağlayabiliriz. Hatta eski kayıtlar ve yeni kayıtlar için farklı zamanlarda backup alabiliriz. Satırlara göre farklı bölümlere ayırmaya horizontal partitioning denir.
Eğer bir tablo üzerinde çok sık kullandığımız kolonların yanında çok ender sorguladığımız kolonlar varsa, tabloyu kolonlara göre de bölümlere ayırabiliriz. Buna da vertical partioning denir. Bir tabloyu satırlardan ve sütünlardan oluşan bir yapı olarak düşünürsek, bu durumda tabloyu dikey olarak bölmüş oluruz. Vertical partioning ismi de buradan gelir.
SQL Server da Index Türleri
Index, SQL Server tablolarındaki verilere kolayca ulaşmamızı sağlayan yapılardır. Bir kitabın sonundaki indekse benzetilebilir. Hangi verinin nerede bulunduğu indeksler üzerinde tutulur.
Temel olarak SQL Server'da iki tür indeks vardır.
Clustered Index ve Nonclustered Indeks. Clustered Index, tablonun aynısıdır ve tablodaki tüm alanlar yer alır, sadece veriler, clustered indeks olarak tanımlanmış alanların sırasında tutulur, ancak nonclustered index'de sadece indeksteki veriler ve o verilerin nerede bulunduğuna dair işaretler tutulur.
Üzerinde clustered indeks tanımlı olmayan tabloya heap tablo denir. Ve heap tablolarda veriler sıralı değildir. Üzerinde clustered indeks tanımlı olan bir tablonun iki versiyonu olur, heap orijinal tablodur ve bu tablonun sıralı hali de clustered indekste durur. Özel birşey söylenmezse, primary key yaratılırken, primary key alanına göre clustered indeks yaratılır. Bir tablo için sadece 1 tane clustered indeks yaratılabilir.
Bu genel ayrımdan sonra içeriklerine göre indeksler aşağıdaki şekilde gruplandırılabilir.
Simple
Tek kolondan oluşan bir indekstir. Örneğin sadece ad kolonundan oluşan veya ad ve soyad birleşiminden oluşur.
Compound
2 veya daha fazla kolondan oluşan indekstir.
Unique
Unique indeks olarak tanımlı alanlar için, aynı verilerden sadece bir tane girilmesine izin veren indeks türüdür.
Temel olarak SQL Server'da iki tür indeks vardır.
Clustered Index ve Nonclustered Indeks. Clustered Index, tablonun aynısıdır ve tablodaki tüm alanlar yer alır, sadece veriler, clustered indeks olarak tanımlanmış alanların sırasında tutulur, ancak nonclustered index'de sadece indeksteki veriler ve o verilerin nerede bulunduğuna dair işaretler tutulur.
Üzerinde clustered indeks tanımlı olmayan tabloya heap tablo denir. Ve heap tablolarda veriler sıralı değildir. Üzerinde clustered indeks tanımlı olan bir tablonun iki versiyonu olur, heap orijinal tablodur ve bu tablonun sıralı hali de clustered indekste durur. Özel birşey söylenmezse, primary key yaratılırken, primary key alanına göre clustered indeks yaratılır. Bir tablo için sadece 1 tane clustered indeks yaratılabilir.
Bu genel ayrımdan sonra içeriklerine göre indeksler aşağıdaki şekilde gruplandırılabilir.
Simple
Tek kolondan oluşan bir indekstir. Örneğin sadece ad kolonundan oluşan veya ad ve soyad birleşiminden oluşur.
Compound
2 veya daha fazla kolondan oluşan indekstir.
Unique
Unique indeks olarak tanımlı alanlar için, aynı verilerden sadece bir tane girilmesine izin veren indeks türüdür.
29 Ekim 2010 Cuma
OUTPUT INTO
OUTPUT INTO ile, UPDATE,INSERT,DELETE ve MERGE işlemleri sırasında etkilenen verileri bir tabloya kopyalayabiliriz. Log almak, son değişiklik yapılan verilen ile ilgili işlem yapmak için iyi bir yöntemdir.
UPDATE Production.Product
SET Color = 'blue'
OUTPUT inserted.ProductID,
inserted.Name,
inserted.Color,
deleted.Color
INTO ProductLog
WHERE ProductID= 134
inserted ve deleted sanal tabloları, trigger lardan bildiğimiz tabloların aynısıdır. Yeni değerler inserted tablosunda, eski değerler deleted tablosunda bulunur.
INTO da verilen tablonun yapısı, OUTPUT da getirilen kolonlarla aynı yapıda olmalıdır.
OUTPUT INTO da kullanılamayacak ifadeler
UPDATE Production.Product
SET Color = 'blue'
OUTPUT inserted.ProductID,
inserted.Name,
inserted.Color,
deleted.Color
INTO ProductLog
WHERE ProductID= 134
inserted ve deleted sanal tabloları, trigger lardan bildiğimiz tabloların aynısıdır. Yeni değerler inserted tablosunda, eski değerler deleted tablosunda bulunur.
INTO da verilen tablonun yapısı, OUTPUT da getirilen kolonlarla aynı yapıda olmalıdır.
OUTPUT INTO da kullanılamayacak ifadeler
- Başka bir veri tabanından olan bir tablo
- View
- CTE (Common Table Expression)
- Üzerine trigger yazılmış bir tablo
- Foreign key constraint i tanımlı bir tablo
- Merge veya Transaction replicationda yer alan bir tablo.
DBCC CHECKIDENT
DBCC CHECKIDENT (table_name, NORESEED | RESEED, [new_reseed_value])
DBCC CHECKIDENT ('myTableName',NORESEED) şeklinde çalıştırılsa, ilgili tablonun mevcut ve en yüksek identity değerini getirir. Eğer hatalı insert nedeniyle identity alanının değeri artmış, ancak tabloya yazılmamışsa bu tarz durumlar olabilir. Bu durumda DBCC CHECKIDENT, reseed parametresi ile çağrılarak, identity alanı istenilen değere geri çekilebilir.
DBCC CHECKIDENT ('myTableName',RESEED, 50) ile identity değeri 50 ye alınır, bundan sonra oluşacak identity değerleri 51 den başlar.
DBCC CHECKIDENT ('myTableName',RESEED) ise mevcut identity değerini maximum identity değeri ile eşitler.
İçinde identity alanı olan bir tablonun içindeki tüm kayıtları sildiğinizde identity alanı sıfırlanmaz. Sıfırlanması için truncate table kullanabilirsiniz ancak tablo üzerinde foreign key ler tanımlı ise, truncate table kodu çalışmaz. Bu durumda tablodaki kayıtları sildikten sonra reseed ile identity alanını baştan başlatabilirsiniz.
DBCC CHECKIDENT ('myTableName',NORESEED) şeklinde çalıştırılsa, ilgili tablonun mevcut ve en yüksek identity değerini getirir. Eğer hatalı insert nedeniyle identity alanının değeri artmış, ancak tabloya yazılmamışsa bu tarz durumlar olabilir. Bu durumda DBCC CHECKIDENT, reseed parametresi ile çağrılarak, identity alanı istenilen değere geri çekilebilir.
DBCC CHECKIDENT ('myTableName',RESEED, 50) ile identity değeri 50 ye alınır, bundan sonra oluşacak identity değerleri 51 den başlar.
DBCC CHECKIDENT ('myTableName',RESEED) ise mevcut identity değerini maximum identity değeri ile eşitler.
İçinde identity alanı olan bir tablonun içindeki tüm kayıtları sildiğinizde identity alanı sıfırlanmaz. Sıfırlanması için truncate table kullanabilirsiniz ancak tablo üzerinde foreign key ler tanımlı ise, truncate table kodu çalışmaz. Bu durumda tablodaki kayıtları sildikten sonra reseed ile identity alanını baştan başlatabilirsiniz.
Son eklenen kayıtda oluşan otomatik sayıyı öğrenmek
CREATE TABLE Table1(ID int identity(1,1), Name nvarchar(50))
INSERT INTO @Table1(Name) VALUES('Test')
SELECT @@IDENTITY , SCOPE_IDENTITY(), IDENT_CURRENT('Table1')
Identity tanımlanmış bir alanı olan bir tabloya kayıt eklediğimizde, en son eklediğimiz kayıt ile birlikte oluşan Identity alanının değerini öğrenmek ihtiyacımız olduğunda 3 farklı yöntem kullanabiliriz.
@@IDENTITY : Son oturumda oluşan son identity numarasını döndürür. Eğer bu tablo üzerinde bir trigger olsaydı ve trigger da üzerinde identity olan bir tabloya kayıt ekliyor olsaydı, @@Identity bize, Table1 tablosuna eklediğimiz kaydın identity değerini değil, trigger da kayıt eklenen tablonun identity değerini getirecekti.
SCOPE_IDENTITY : Adından anlaşılacağı üzere, scope_identity fonksiyonu, mevcut oturumda ve mevcut kapsamda (scope) son oluşan identity değerini döndürür. Table1 üzerinde trigger olsa, ve başka bir identity alanı olan bir tabloya insert yapılsa bile, Table1 ile ilgili iş yaptığımız için, Table1 üzerinde oluşan son identity değerini bize verecektir.
IDENT_CURRENT : Bu fonksiyon ise hem oturumdan, hem de kapsamdan bağımsız çalışır. Bu nedenle bir tablo adı parametresi ister. Verilen tabloda oluşmuş son identity değerini getirir.
INSERT INTO @Table1(Name) VALUES('Test')
SELECT @@IDENTITY , SCOPE_IDENTITY(), IDENT_CURRENT('Table1')
Identity tanımlanmış bir alanı olan bir tabloya kayıt eklediğimizde, en son eklediğimiz kayıt ile birlikte oluşan Identity alanının değerini öğrenmek ihtiyacımız olduğunda 3 farklı yöntem kullanabiliriz.
@@IDENTITY : Son oturumda oluşan son identity numarasını döndürür. Eğer bu tablo üzerinde bir trigger olsaydı ve trigger da üzerinde identity olan bir tabloya kayıt ekliyor olsaydı, @@Identity bize, Table1 tablosuna eklediğimiz kaydın identity değerini değil, trigger da kayıt eklenen tablonun identity değerini getirecekti.
SCOPE_IDENTITY : Adından anlaşılacağı üzere, scope_identity fonksiyonu, mevcut oturumda ve mevcut kapsamda (scope) son oluşan identity değerini döndürür. Table1 üzerinde trigger olsa, ve başka bir identity alanı olan bir tabloya insert yapılsa bile, Table1 ile ilgili iş yaptığımız için, Table1 üzerinde oluşan son identity değerini bize verecektir.
IDENT_CURRENT : Bu fonksiyon ise hem oturumdan, hem de kapsamdan bağımsız çalışır. Bu nedenle bir tablo adı parametresi ister. Verilen tabloda oluşmuş son identity değerini getirir.
LOCK Türleri
Veritabanında satır, sayfa veya tablo düzeyinde locklar oluşabilir. Bu locklar iki gruba ayrılırlar.
Basic Locks :
Shared Lock : Bir tablo üzerinde select sorgusu çalışırken oluşur. Bu lock, okuma yapacak diğer sorguların çalışmasına izin verir. Ancak shared lock çözülene kadar hiç bir transaction okunan kayıtları güncelleyemez.
Update lock : Bir tablo üzerinde update işleri yapılırken oluşur. SQL Server, güncellenen verileri okumaya kalktığında kullanılır. Güncelleme sırasında, update lock, exclusive lock a dönüşür. Exclusive lock, birden fazla transaction ın aynı satırları güncellemeye çalışıp, deadlock oluşturmasını engeller.
Exclusive lock : Diğer işlemlerin kilitlenmiş kaynaklara ulaşmasını engeller. Okuma işlemi sırasında, tabloda NOLOCK kullanıldıysa veya Isolation Level, READ UNCOMMITTED olarak ayarlandıysa, exclusive lock konulmuş olsa da veri okunur. Ancak diğer işlemler, exclusive lock kalkana kadar yapılamaz.
Intent Lock : 6 farklı türde intent lock vardır.
Intent shared (IS) lock istekleri veya shared lock ları korur. Bir kayıtda bir shared lock oluşmuş ise, ilgili kaydın bulunduğu page üzerinde intent shared lock oluşur.
Intent exclusive (IX) lock Intent shared lock ın bir üstü seviyesidir. Bir kayıtda exclusive lock varsa, ilgili kaydın bulunduğu page üzerinde Intent Exclusive Lock konulur.
Shared with intent exclusive (SIX) lock kilitleme hiyerarşisinde daha alt seviyede duran shared lock ları korur. Bir tabloda shared with intent exclusive lock oluşursa, değişiklik yapılan page üzerinde intent exclusive lock da yer alır.
Intent update (IU) lock güncellenen tablonun bulunduğu pagelerdeki, shared ve istenilelen diğer lockları korur.
Shared intent update lock, shared ve intent update locklarının birleşimininden oluşur. Bir transaction bir tablodan okuma yaptığında shared lock oluşur, daha sonra aynı transaction bir update işlemi yaparsa o zaman shared intent update lock a dönüşür. Bir tabloda select cümlesi çalıştırılırken, PAGLOCK hint i kullanılarak çekildiğinde de oluşan lock türüdür.
Birbirini kapsayan birden fazla lock olmasının nedeni, SQL Server'ın aynı anda bir tablo üzerinde oluşan birçok lock yerine, tek bir lock ile çalışmasının daha verimli olmasındandır.
Basic Locks :
- S:Shared
- U:Update
- X:Exclusive
- I : Intent
- Sch: Schema
- BU: Bulk Update
- KR : Key Range
Shared Lock : Bir tablo üzerinde select sorgusu çalışırken oluşur. Bu lock, okuma yapacak diğer sorguların çalışmasına izin verir. Ancak shared lock çözülene kadar hiç bir transaction okunan kayıtları güncelleyemez.
Update lock : Bir tablo üzerinde update işleri yapılırken oluşur. SQL Server, güncellenen verileri okumaya kalktığında kullanılır. Güncelleme sırasında, update lock, exclusive lock a dönüşür. Exclusive lock, birden fazla transaction ın aynı satırları güncellemeye çalışıp, deadlock oluşturmasını engeller.
Exclusive lock : Diğer işlemlerin kilitlenmiş kaynaklara ulaşmasını engeller. Okuma işlemi sırasında, tabloda NOLOCK kullanıldıysa veya Isolation Level, READ UNCOMMITTED olarak ayarlandıysa, exclusive lock konulmuş olsa da veri okunur. Ancak diğer işlemler, exclusive lock kalkana kadar yapılamaz.
Intent Lock : 6 farklı türde intent lock vardır.
Intent shared (IS) lock istekleri veya shared lock ları korur. Bir kayıtda bir shared lock oluşmuş ise, ilgili kaydın bulunduğu page üzerinde intent shared lock oluşur.
Intent exclusive (IX) lock Intent shared lock ın bir üstü seviyesidir. Bir kayıtda exclusive lock varsa, ilgili kaydın bulunduğu page üzerinde Intent Exclusive Lock konulur.
Shared with intent exclusive (SIX) lock kilitleme hiyerarşisinde daha alt seviyede duran shared lock ları korur. Bir tabloda shared with intent exclusive lock oluşursa, değişiklik yapılan page üzerinde intent exclusive lock da yer alır.
Intent update (IU) lock güncellenen tablonun bulunduğu pagelerdeki, shared ve istenilelen diğer lockları korur.
Shared intent update lock, shared ve intent update locklarının birleşimininden oluşur. Bir transaction bir tablodan okuma yaptığında shared lock oluşur, daha sonra aynı transaction bir update işlemi yaparsa o zaman shared intent update lock a dönüşür. Bir tabloda select cümlesi çalıştırılırken, PAGLOCK hint i kullanılarak çekildiğinde de oluşan lock türüdür.
Birbirini kapsayan birden fazla lock olmasının nedeni, SQL Server'ın aynı anda bir tablo üzerinde oluşan birçok lock yerine, tek bir lock ile çalışmasının daha verimli olmasındandır.
TRY - CATCH ve TRANSACTION kullanımı
Try Catch yapısını, transactionlar ile kullanmak hem yapılan kontrol sayısını azaltır, hem de daha anlaşılır bir kod yazmanızı sağlar.
Try Catch kullanılmazsa (SQL 2005 öncesi versiyonlarda zaten try catch olmadığı için mecburan) her bir statementdan sonra @@Error den gelen hata kodunu bir değişkene atmanız, bir sorun varsa rollback yoksa kodun devam etmesi veya commit etmesi için if cümleleri ile uğraşmanız gerekir.
TRY/CATCH ile hataları yönetmek ve transactionlar ile çalışmak daha da kolaylaştı.
İşte birkaç örnek.
DECLARE @ErrorNumber int = 0 , @ErrorMessage nvarchar(max)
BEGIN TRANSACTION
BEGIN TRY
…
END TRY
BEGIN CATCH
SELECT @ErrorNumber = ERROR_NUMBER(), @ErrorMessage = ERROR_MESSAGE()
END CATCH
IF @ErrorNumber<>0
ROLLBACK TRANSACTION
ELSE
COMMIT TRANSACTION
-------------------------------
DECLARE @ErrorNumber int = 0 , @ErrorMessage nvarchar(max)
BEGIN TRANSACTION
BEGIN TRY
…
COMMIT TRANSACTION
END TRY
BEGIN CATCH
SELECT @ErrorNumber = ERROR_NUMBER(), @ErrorMessage = ERROR_MESSAGE()
IF @@TRANCount>0 ROLLBACK TRANSACTION
END CATCH
Try Catch kullanılmazsa (SQL 2005 öncesi versiyonlarda zaten try catch olmadığı için mecburan) her bir statementdan sonra @@Error den gelen hata kodunu bir değişkene atmanız, bir sorun varsa rollback yoksa kodun devam etmesi veya commit etmesi için if cümleleri ile uğraşmanız gerekir.
TRY/CATCH ile hataları yönetmek ve transactionlar ile çalışmak daha da kolaylaştı.
İşte birkaç örnek.
DECLARE @ErrorNumber int = 0 , @ErrorMessage nvarchar(max)
BEGIN TRANSACTION
BEGIN TRY
…
END TRY
BEGIN CATCH
SELECT @ErrorNumber = ERROR_NUMBER(), @ErrorMessage = ERROR_MESSAGE()
END CATCH
IF @ErrorNumber<>0
ROLLBACK TRANSACTION
ELSE
COMMIT TRANSACTION
-------------------------------
DECLARE @ErrorNumber int = 0 , @ErrorMessage nvarchar(max)
BEGIN TRANSACTION
BEGIN TRY
…
COMMIT TRANSACTION
END TRY
BEGIN CATCH
SELECT @ErrorNumber = ERROR_NUMBER(), @ErrorMessage = ERROR_MESSAGE()
IF @@TRANCount>0 ROLLBACK TRANSACTION
END CATCH
İsimlendirilmiş Transactionlar
İsimlendirilmiş transactionlar, bir transactiona belli bir isim atanmış transactionlardır. İçiçe transactionlar ile çalışıldığında, hangi transactionın, ne durumda olduğunu bulabilirsiniz. Ayrıca lockları izlemek kolaylaşır, hangi transaction uzun süreli locklara neden olduğu tespit edilebilir.
BEGIN TRANSACTION myTranName
-- Transaction içinde çalışacak kodlar.
COMMIT TRANSACTION myTranName
şeklinde kullanılır.
Transactiona verilen isim, SQL Server'ın objelere isim verme kurallarına uygun olmalıdır ve 32 karakterden uzun olamaz.
BEGIN TRANSACTION myTranName
-- Transaction içinde çalışacak kodlar.
COMMIT TRANSACTION myTranName
şeklinde kullanılır.
Transactiona verilen isim, SQL Server'ın objelere isim verme kurallarına uygun olmalıdır ve 32 karakterden uzun olamaz.
TRANSACTION Türleri
SQL Server 2 tür transaction yapısını destekler.
Local Transaction : Aynı server üzerinde kalan transactionlardır. BEGIN TRANSACTION veya daha kısa yazımıyla BEGIN TRAN ifadesi ile başlatırlar.
Distributed Transaction : BEGIN DISTRIBUTED TRANSACTION veya BEGIN DISTRIBUTED TRAN ifadesi ile başlatırlar. Bu tür transaction türleri, eğer bir transaction içerisinde server dışına çıkılacak ise kullanılır. Bu daha çok bir query, linked server ile başka bir servera bağlanıyorsa veya OPENROWSET kullanılıyorsa oluşur. Bu transactionlar sadece SQL Server için değil, distributed transaction yapısını destekleyen Oracle, DB2 gibi veri tabanlarına bağlanılıyorsa da kullanılabilir.
Local Transaction : Aynı server üzerinde kalan transactionlardır. BEGIN TRANSACTION veya daha kısa yazımıyla BEGIN TRAN ifadesi ile başlatırlar.
Distributed Transaction : BEGIN DISTRIBUTED TRANSACTION veya BEGIN DISTRIBUTED TRAN ifadesi ile başlatırlar. Bu tür transaction türleri, eğer bir transaction içerisinde server dışına çıkılacak ise kullanılır. Bu daha çok bir query, linked server ile başka bir servera bağlanıyorsa veya OPENROWSET kullanılıyorsa oluşur. Bu transactionlar sadece SQL Server için değil, distributed transaction yapısını destekleyen Oracle, DB2 gibi veri tabanlarına bağlanılıyorsa da kullanılabilir.
Transactionlar Hakkında Doğru Bilinen Yanlışlar
Eğer transaction içerisinde bir komut hata verirse, diğer komutların dataları da işlenmez.
Eğer bir hata yakalama mekanizması kullanmadıysanız ve hata durumunda rollback yapmadıysanız, commit cümlesi çalıştığında sorun olmayan komutlar çalışır ve işlemlerini yaparlar.
Bir stored procedure zaten bir transaction dır.
Bir prosedür içerisindeki her bir kod tek başına bir transaction dır. Aslında bu stored procedure içinde olmasa da, tüm yazılan insert, update ve delete kodları otomatik commit edilen bir transaction olarak çalışırlar. Ancak stored procedure kodunun tümü tek bir transaction değildir. Eğer bir stored procedure, tek bir transaction olarak çalıştırılmak isteniyorsa, Begin Transaction ve Commit Transaction bloğu içine yazılmalıdır. Ancak unutmamak gerekir ki, transaction isolation levela göre bu tablolarda uzun süreli lock oluşmasına, bu arada diğer kullanıcıların hiç bir işlem yapamamasına neden olabilir.
Bir transaction yaratılırsa ve bu transaction içinde bir select ifadesi çalıştırılırsa, kimse select ile çekilen satırlara ulaşamaz.
Bu transaction isolation level'a göre doğru da olabilir, yanlış da. Bunun için Transaction Isolation Level ile ilgili yazıma bakabilirsiniz.
Eğer bir hata yakalama mekanizması kullanmadıysanız ve hata durumunda rollback yapmadıysanız, commit cümlesi çalıştığında sorun olmayan komutlar çalışır ve işlemlerini yaparlar.
Bir stored procedure zaten bir transaction dır.
Bir prosedür içerisindeki her bir kod tek başına bir transaction dır. Aslında bu stored procedure içinde olmasa da, tüm yazılan insert, update ve delete kodları otomatik commit edilen bir transaction olarak çalışırlar. Ancak stored procedure kodunun tümü tek bir transaction değildir. Eğer bir stored procedure, tek bir transaction olarak çalıştırılmak isteniyorsa, Begin Transaction ve Commit Transaction bloğu içine yazılmalıdır. Ancak unutmamak gerekir ki, transaction isolation levela göre bu tablolarda uzun süreli lock oluşmasına, bu arada diğer kullanıcıların hiç bir işlem yapamamasına neden olabilir.
Bir transaction yaratılırsa ve bu transaction içinde bir select ifadesi çalıştırılırsa, kimse select ile çekilen satırlara ulaşamaz.
Bu transaction isolation level'a göre doğru da olabilir, yanlış da. Bunun için Transaction Isolation Level ile ilgili yazıma bakabilirsiniz.
Transaction nedir?
Transaction, bir veri tabanına aynı anda işlenen (commit) veya işlenmesi geri alınabilen (rollback) bir grup komuttur.
Transaction yapısı ile farklı tablolara kayıt ekleyebilir, güncelleme yapabilir veya kayıt silebiliriz ve bu işlemlerden herhangi birinde bir sorun olursa, tüm yapılan işlemleri geri alabiliriz.
Transaction sırasında, tablolar üzerinde olabilecek lock ları, transaction isolation level'ını değiştirerek kontrol edebiliriz.
Transaction yapısı ile farklı tablolara kayıt ekleyebilir, güncelleme yapabilir veya kayıt silebiliriz ve bu işlemlerden herhangi birinde bir sorun olursa, tüm yapılan işlemleri geri alabiliriz.
Transaction sırasında, tablolar üzerinde olabilecek lock ları, transaction isolation level'ını değiştirerek kontrol edebiliriz.
28 Ekim 2010 Perşembe
ASSEMBLY Yaratmak ve Permission Set
Diyelim CLR ile SQL Server da çalışmak için bir assembly yazdınız ve bu assembly yi register ediyorsunuz.
CREATE ASSEMBLY MyCLRFunction
AUTHORIZATION [dbo]
FROM 'C:\MyCLRFunction.dll'
WITH PERMISSION_SET = SAFE;
Yukarıdaki örnekte göründüğü gibi, CREATE ASSEMBLY ile yazabildiğimiz parametrelerden biri de PERMISSION_SET.
Permission Set, SQL Server'da oluşturduğumuz assembly için, hangi güvenlik kısıtılarının uygulanacanı belirlediğimiz yer. Bu güvenlik kısıtları, tabii ki sadece bu assembly yi SQL Server da kullanırken uygulanıyor olacak (Bir CLR fonksiyonun içinde örneğin)
SQL Server 2008 de 3 farklı set var
Bu şekilde ayarlanmış bir assembly, network, dosya veya windows registry gibi dış kaynaklara ulaşamaz. Hesaplama işleri veya kullanıcı tanımlı veri tipi için yazılmış bir assembly için en uygun ayardır.
EXTERNAL_ACCESS seçeneği ile kayıt edilmiş olan assembly ler, dosya sistemine ulaşıp, değiştirebilirler, event log'a, registry ye veya active directory ye ulaşabilirler, web veya smtp bağlantıları kurabilirler.
Assembly şe dış kaynaklara ulaşırken, SQL Server service account u ile bu bağlantıyı kurarlar. Ayrıca unsafe olarak işaretlenmiş kodları da çalıştıramazlar.
UNSAFE : EXTERNAL_ACCESS ile izin verilern her şeyi yapabilir. Aralarındaki tek fark, UNSAFE, unsafe olarak işaretlenmiş ve unmanaged kod denilen kodları da çalıştırabiliyor olmasıdır. Gerçekten gerekli olmadıkça, unmanaged bir kodu unsafe olarak sql server a tanıtmamak gerekir. Bu kodlar sql server'ın hem güvenliğine, hem de çalışmasına zarar verebilirler.
Assembly kodları, SQL Server servisi tarafından , SQL Server Service Account u ile çalıştırılırlar. Eğer SQL Server, Local System kullanıcısı gibi yetkileri kısıtlı bir kullanıcı ile çalıştırılıyorsa, network gibi yetkisi olmayan kaynaklara ulaşamaz. Assembly kodu içerisinden, başka bir kullanıcı olarak çalıştırmaya izin vardır ancak burada da, windows un güvenlik kısıtları devreye girer.
CLR çağırırken, dışarıdaki bir kaynağa ulaşabilmek için, SQL Server'a windows kullanıcısı ile bağlanmak gerekir. Windows login'i ile giriş yapılmış olsa da, assembly tarafından giriş yapılan kullanıcının değil, sql server servisini çalıştıran kullanıcının yetkileri kullanılır.
SQL Server 2008 veritabanlarının TRUSTWORTHY özellikleri vardır. Bu özellik, veritabanı objelerinin (fonksiyonlar ve prosedürler gibi), dış kaynaklara ulaşıp ulaşamayacağını belirler. TRUSTWORTHY özelliği ON ise CLR kullanan veritabanı nesneleri, sql server servis kullanıcısının yetkileri dahilinde dış kaynaklara ulaşabilir , eğer "OFF" ise, CLR nesneleri, dış bir kaynağa ulaşmaya çalışırsa, hata alırlar.
CREATE ASSEMBLY MyCLRFunction
AUTHORIZATION [dbo]
FROM 'C:\MyCLRFunction.dll'
WITH PERMISSION_SET = SAFE;
Yukarıdaki örnekte göründüğü gibi, CREATE ASSEMBLY ile yazabildiğimiz parametrelerden biri de PERMISSION_SET.
Permission Set, SQL Server'da oluşturduğumuz assembly için, hangi güvenlik kısıtılarının uygulanacanı belirlediğimiz yer. Bu güvenlik kısıtları, tabii ki sadece bu assembly yi SQL Server da kullanırken uygulanıyor olacak (Bir CLR fonksiyonun içinde örneğin)
SQL Server 2008 de 3 farklı set var
- SAFE
- EXTERNAL_ACCESS
- UNSAFE
Bu şekilde ayarlanmış bir assembly, network, dosya veya windows registry gibi dış kaynaklara ulaşamaz. Hesaplama işleri veya kullanıcı tanımlı veri tipi için yazılmış bir assembly için en uygun ayardır.
EXTERNAL_ACCESS seçeneği ile kayıt edilmiş olan assembly ler, dosya sistemine ulaşıp, değiştirebilirler, event log'a, registry ye veya active directory ye ulaşabilirler, web veya smtp bağlantıları kurabilirler.
Assembly şe dış kaynaklara ulaşırken, SQL Server service account u ile bu bağlantıyı kurarlar. Ayrıca unsafe olarak işaretlenmiş kodları da çalıştıramazlar.
UNSAFE : EXTERNAL_ACCESS ile izin verilern her şeyi yapabilir. Aralarındaki tek fark, UNSAFE, unsafe olarak işaretlenmiş ve unmanaged kod denilen kodları da çalıştırabiliyor olmasıdır. Gerçekten gerekli olmadıkça, unmanaged bir kodu unsafe olarak sql server a tanıtmamak gerekir. Bu kodlar sql server'ın hem güvenliğine, hem de çalışmasına zarar verebilirler.
Assembly kodları, SQL Server servisi tarafından , SQL Server Service Account u ile çalıştırılırlar. Eğer SQL Server, Local System kullanıcısı gibi yetkileri kısıtlı bir kullanıcı ile çalıştırılıyorsa, network gibi yetkisi olmayan kaynaklara ulaşamaz. Assembly kodu içerisinden, başka bir kullanıcı olarak çalıştırmaya izin vardır ancak burada da, windows un güvenlik kısıtları devreye girer.
CLR çağırırken, dışarıdaki bir kaynağa ulaşabilmek için, SQL Server'a windows kullanıcısı ile bağlanmak gerekir. Windows login'i ile giriş yapılmış olsa da, assembly tarafından giriş yapılan kullanıcının değil, sql server servisini çalıştıran kullanıcının yetkileri kullanılır.
SQL Server 2008 veritabanlarının TRUSTWORTHY özellikleri vardır. Bu özellik, veritabanı objelerinin (fonksiyonlar ve prosedürler gibi), dış kaynaklara ulaşıp ulaşamayacağını belirler. TRUSTWORTHY özelliği ON ise CLR kullanan veritabanı nesneleri, sql server servis kullanıcısının yetkileri dahilinde dış kaynaklara ulaşabilir , eğer "OFF" ise, CLR nesneleri, dış bir kaynağa ulaşmaya çalışırsa, hata alırlar.
26 Ekim 2010 Salı
Transaction Isolation Level lar nedir?
SQL Server'da verilerimizi güncellerken, diğer transaction ların verilere nasıl ulaşacağı, lock ların nasıl ve na kadar süre tutulacağı, verilerin nasıl okunacağı "transaction isolation level" ile karar verilir.
Isolation için eş zamanlı olarak veri güncellemesi yapan transactionların etkilerinden, diğer transactionları koruma yeteneğidir diyebiliriz.
Her transaction, transaction tamamlanana kadar, güncellen veriyi kilitler. Veri okuma işlemlerinde, "transaction isolation levels", diğer transaction lar tarafından yapılan değişikliklerin etkilerinden koruma seviyeleridir.
Daha düşük seviye bir isolation level seçilirse, aynı anda birçok kullanıcı veriyer ulaşabilir ancak okunan veriler tutarlı veya güncel olmayabilir.
Yüksek seviye bir isolation level, okunan verinin tutarlılığını arttırken, bir transaction'ın başka transaction ları kilitlemesine neden olabilir.
Veri tutarlılığının üç temel yan etkisi vardır.
dirty read : Bir transaction tarafından bir veri güncellenirken verinin okunmasıdır ve veri güncel olmayabilir
nonrepeatable read: Bir başka transaction, aynı satırı birçok kez okur ve her seferinde başka bir veri okursa oluşur.
phantom read : Bir silme veya yeni kayıt ekleme işlemi sırasında, aynı anda okuma işlemi yapılıyorsa ve bu kayıtlar da okunan kayıt setinin içerisindeyse oluşur. Bu kullanıcının kayıtları eklemediğini düşünmesine ve ikince kez kayıt eklemeye çalışmasına neden olabilir.
En üst seviye isolation "SERIALIZABLE" dır. Tüm transaction her zaman aynı datayı alırlar ancak çok kullanıcılı sistemlerde, bir kullanıcının yaptığı işlem, diğer kullanıcıların işlemlerini etkiler.
En alt seviye isolation ise "READ UNCOMMITTED" dır. Diğer transactionlar tarafından güncellenmeye başlamış, ancak henüz commit işlemi tamamlanmamış veriler okunabilir.
READ UNCOMMITTED Başka transactionlardan tarafından güncellenmekte olan, ancak henüz güncelleme işlemleri tamamlanmamış veriler okunabilir.
READ COMMITTED Başka transactionlar tarafından güncellenmekte olan veriler, güncelleme işlemi tamamlanana kadar okunamazlar. Bu "dirty read" i engeller. Veri, her bir transaction arasında başka bir transaction tarafından güncellenebilir. Bu seviyede nonrepeatable veya phantom read ler oluşabilir.
READ COMMITTED seviyesi, SQL Server'ın varsayılan isolation seviyesidir.
REPEATABLE READ Güncellenen ancak henüz commit edilmeyen veriler, commit edilene kadar okunamaz veya başka transaction lar tarafından güncellenemez.
SNAPSHOT Veri herhangi bir zamanda okunabilir. Okuma işlemi başladığında verinin son hali ne ise, o veri okunur. Okuma için başlayan transaction, sadece başlamadan önce commit edilmiş verileri farkeder. Transaction başladıktan sonra başka bir transaction veriyi güncellerse, bu güncellemeleri görmez.
SERIALIZABLE Commit edilmemiş veri okunamaz veya güncellenemez. Bir transaction, okunan veri aralığına ait key ile, okuma işlemi tamamlanana kadar insert işlemi yapamaz.
Isolation için eş zamanlı olarak veri güncellemesi yapan transactionların etkilerinden, diğer transactionları koruma yeteneğidir diyebiliriz.
Her transaction, transaction tamamlanana kadar, güncellen veriyi kilitler. Veri okuma işlemlerinde, "transaction isolation levels", diğer transaction lar tarafından yapılan değişikliklerin etkilerinden koruma seviyeleridir.
Daha düşük seviye bir isolation level seçilirse, aynı anda birçok kullanıcı veriyer ulaşabilir ancak okunan veriler tutarlı veya güncel olmayabilir.
Yüksek seviye bir isolation level, okunan verinin tutarlılığını arttırken, bir transaction'ın başka transaction ları kilitlemesine neden olabilir.
Veri tutarlılığının üç temel yan etkisi vardır.
dirty read : Bir transaction tarafından bir veri güncellenirken verinin okunmasıdır ve veri güncel olmayabilir
nonrepeatable read: Bir başka transaction, aynı satırı birçok kez okur ve her seferinde başka bir veri okursa oluşur.
phantom read : Bir silme veya yeni kayıt ekleme işlemi sırasında, aynı anda okuma işlemi yapılıyorsa ve bu kayıtlar da okunan kayıt setinin içerisindeyse oluşur. Bu kullanıcının kayıtları eklemediğini düşünmesine ve ikince kez kayıt eklemeye çalışmasına neden olabilir.
En üst seviye isolation "SERIALIZABLE" dır. Tüm transaction her zaman aynı datayı alırlar ancak çok kullanıcılı sistemlerde, bir kullanıcının yaptığı işlem, diğer kullanıcıların işlemlerini etkiler.
En alt seviye isolation ise "READ UNCOMMITTED" dır. Diğer transactionlar tarafından güncellenmeye başlamış, ancak henüz commit işlemi tamamlanmamış veriler okunabilir.
READ UNCOMMITTED Başka transactionlardan tarafından güncellenmekte olan, ancak henüz güncelleme işlemleri tamamlanmamış veriler okunabilir.
READ COMMITTED Başka transactionlar tarafından güncellenmekte olan veriler, güncelleme işlemi tamamlanana kadar okunamazlar. Bu "dirty read" i engeller. Veri, her bir transaction arasında başka bir transaction tarafından güncellenebilir. Bu seviyede nonrepeatable veya phantom read ler oluşabilir.
READ COMMITTED seviyesi, SQL Server'ın varsayılan isolation seviyesidir.
REPEATABLE READ Güncellenen ancak henüz commit edilmeyen veriler, commit edilene kadar okunamaz veya başka transaction lar tarafından güncellenemez.
SNAPSHOT Veri herhangi bir zamanda okunabilir. Okuma işlemi başladığında verinin son hali ne ise, o veri okunur. Okuma için başlayan transaction, sadece başlamadan önce commit edilmiş verileri farkeder. Transaction başladıktan sonra başka bir transaction veriyi güncellerse, bu güncellemeleri görmez.
SERIALIZABLE Commit edilmemiş veri okunamaz veya güncellenemez. Bir transaction, okunan veri aralığına ait key ile, okuma işlemi tamamlanana kadar insert işlemi yapamaz.
24 Ekim 2010 Pazar
SQL Server 2008 de View Türleri
SQL Server 2008 de birkaç çeşit view yaratabiliriz.
Standard view Bir veya birden fazla tablo içerebilir ve tablolar join ler ile birbirlerine bağlanabilir. WHERE ifadesi ile filtreleme yapılabilir, TOP ve ORDER BY ifadeleri ile kayıt sayısı sınırlandırılabilir (Order By View lerde TOP olmadan kullanılamaz)
Updateable view Tek bir tablodan oluşur ve üzerinde INSERT, UPDATE, DELETE, ve MERGE gibi veriyi değiştiren ifadeler direk olarak çalışabilir. Ayrıca, birden fazla tablodan oluşan bir view üzerine INSTEAD OF trigger yazılarak, View deki hangi verinin hangi tabloyu güncelleyeceği bu trigger üzerinde yazılabilir.
Indexed view Bazen, bir view e index koymak optimizasyon için iyi sonuçlar üretebilir. View le üzerine indexler tıpkı tablolarda olduğu gibi "CREATE INDEX" ifadesi ile yaratılırlar. Indexed Viewler WITH Schemabinding seçeneği ile oluşturulmalıdırlar. Bu da view in içerisinde kullanılan kolonların yapısının değiştirilmesini engeller. Viewlerde kullanılan kolonun veri tipi değişitirilemez, drop edilemez veya kullanılan tablo drop edilemez. Öncelikle view drop edilmeli, tablolardaki gerekli değişikliklerden yapıldıktan sonra yeniden yaratılmalıdır.
Partitioned view Bir tabloyu horizontal olarak (yani satırlarına göre) parçalamış isek bu view ile farklı parçalara ayrılmış tabloları tek bir view de biraraya getirebiliriz.
Örneğin bu yılın satışlarını 1 tabloda, geçen yılın satışlarını başka bir tabloda, 2 yıl ve daha eski satışları da başka bir tabloda saklıyor isek, partitioned view ile bu 3 tablodakii verileri birarada gösterebiliriz.
Standard view Bir veya birden fazla tablo içerebilir ve tablolar join ler ile birbirlerine bağlanabilir. WHERE ifadesi ile filtreleme yapılabilir, TOP ve ORDER BY ifadeleri ile kayıt sayısı sınırlandırılabilir (Order By View lerde TOP olmadan kullanılamaz)
Updateable view Tek bir tablodan oluşur ve üzerinde INSERT, UPDATE, DELETE, ve MERGE gibi veriyi değiştiren ifadeler direk olarak çalışabilir. Ayrıca, birden fazla tablodan oluşan bir view üzerine INSTEAD OF trigger yazılarak, View deki hangi verinin hangi tabloyu güncelleyeceği bu trigger üzerinde yazılabilir.
Indexed view Bazen, bir view e index koymak optimizasyon için iyi sonuçlar üretebilir. View le üzerine indexler tıpkı tablolarda olduğu gibi "CREATE INDEX" ifadesi ile yaratılırlar. Indexed Viewler WITH Schemabinding seçeneği ile oluşturulmalıdırlar. Bu da view in içerisinde kullanılan kolonların yapısının değiştirilmesini engeller. Viewlerde kullanılan kolonun veri tipi değişitirilemez, drop edilemez veya kullanılan tablo drop edilemez. Öncelikle view drop edilmeli, tablolardaki gerekli değişikliklerden yapıldıktan sonra yeniden yaratılmalıdır.
Partitioned view Bir tabloyu horizontal olarak (yani satırlarına göre) parçalamış isek bu view ile farklı parçalara ayrılmış tabloları tek bir view de biraraya getirebiliriz.
Örneğin bu yılın satışlarını 1 tabloda, geçen yılın satışlarını başka bir tabloda, 2 yıl ve daha eski satışları da başka bir tabloda saklıyor isek, partitioned view ile bu 3 tablodakii verileri birarada gösterebiliriz.
SQL Server da Constraint ler Nasıl Çalışır?
SQL Server'daki tablolara konulmuş constraint(kısıtlar)ler, bir tabloda bir DML kodu (INSERT, DELETE, UPDATE, MERGER) çalışırken kontrol edilir.
Eğer gelen veri, tablodaki tüm kurallardan geçiyorsa işlem tamamlanır, eğer herhangi bir kolondaki, herhangi bir kısıta takılıyorsa o zaman transaction rollback edilir ve hiç bir veri güncelleme işlemi yapılmaz.
Örneğin email alanına bir check constraint koyduysanız ve aynı anda 10 kayıt birden insert ediyorsanız, ancak sadece 1 tanesi sorunluysa, tüm insert cümlesi rollback edilir ve hiç bir kayıt tabloya eklenmez.
Eğer gelen veri, tablodaki tüm kurallardan geçiyorsa işlem tamamlanır, eğer herhangi bir kolondaki, herhangi bir kısıta takılıyorsa o zaman transaction rollback edilir ve hiç bir veri güncelleme işlemi yapılmaz.
Örneğin email alanına bir check constraint koyduysanız ve aynı anda 10 kayıt birden insert ediyorsanız, ancak sadece 1 tanesi sorunluysa, tüm insert cümlesi rollback edilir ve hiç bir kayıt tabloya eklenmez.
Unique Constraint
Unique constraints, PRIMARY KEY e çok benzer. Tek farkı bir tabloda bir tane primary key olabiliyorken, gerektiği kadar unique constaint olabilmesidir.
Örneğin Müşteri tablonuzdaki, Ad, Soyad ve TelefonNo birleşiminden bir unique constraint yapıbilir, aynı zamanda email adreslerinin tutulduğu kolon için ayrı bir unique constraint yaratabilir ve email adreslerinin her müşteri kaydı için farklı olmasını garanti altına alabilirsiniz.
Unique constraint olan bir tabloda sadece 1 tane null değer olabilir.
Örneğin Müşteri tablonuzdaki, Ad, Soyad ve TelefonNo birleşiminden bir unique constraint yapıbilir, aynı zamanda email adreslerinin tutulduğu kolon için ayrı bir unique constraint yaratabilir ve email adreslerinin her müşteri kaydı için farklı olmasını garanti altına alabilirsiniz.
Unique constraint olan bir tabloda sadece 1 tane null değer olabilir.
Primary Key Nedir?
Primary Key aslında bir constraint (kısıt) dır. Bir tablonun bir satırını temsil eden tekil bir belirleyici kolondur.
Bir tabloda tek bir primary key olabilir. Ancak bir primary key tek bir kolondan veya birden fazla kolonun biraraya gelmesinden oluşabilir.
Bir tabloda tek bir primary key olabilir. Ancak bir primary key tek bir kolondan veya birden fazla kolonun biraraya gelmesinden oluşabilir.
CHECK Constraint Nedir?
SQL Server'da bir çok constraint (kısıt) kullanılabilir.
"Check Constraint" verinin doğruluğunu ve bütünlüğünü korumak üzere kullanılan bir kısıttır. Check constraint eklenmiş bir kolona yeni bilgi eklenirken veya bilgi güncellenirken, veri yazılmış olan kurallara göre kontrol edilir ve kurala uymuyorsa bir hata verilir ve veri kaydedilmez.
Check constraint ifadesi, true veya false döndüren bir kural setidir. Bu bir scalar function olabileceği için bir query de olabilir. Check constraint sadece false değer döndüğünde hata verir. Eğer ifade null döndürürse, bunu true gibi değerlendirir ve herhangi bir hata vermeden veriyi günceller.
Örneğin bir kolonda sınavlardan alınacak notları tutacak olalım. Notlar da 0-100 arasında değişiyor olmalı. Grade alanına bu kısıtı ekleyelim ve 100 ün üzerinde data girilmesini engelleyelim.
ALTER TABLE myTable ADD CONSTRAINT
CK_Grade CHECK(Grade <= 100 AND Grade >= 0)
Eğer tablomuzda veriler varsa ve daha önceden girilmiş verilerin kontrol edilmesini istemiyorsak with nocheck ifadesiyle bunu yapabiliriz. Aksi takdirde, veriler eklenen kurala uygun hale getirilene kadar check constraint eklenemez.
ALTER TABLE myTable WITH NOCHECK ADD CONSTRAINT
CK_Grade CHECK(Grade <= 100 AND Grade >= 0)
"Check Constraint" verinin doğruluğunu ve bütünlüğünü korumak üzere kullanılan bir kısıttır. Check constraint eklenmiş bir kolona yeni bilgi eklenirken veya bilgi güncellenirken, veri yazılmış olan kurallara göre kontrol edilir ve kurala uymuyorsa bir hata verilir ve veri kaydedilmez.
Check constraint ifadesi, true veya false döndüren bir kural setidir. Bu bir scalar function olabileceği için bir query de olabilir. Check constraint sadece false değer döndüğünde hata verir. Eğer ifade null döndürürse, bunu true gibi değerlendirir ve herhangi bir hata vermeden veriyi günceller.
Örneğin bir kolonda sınavlardan alınacak notları tutacak olalım. Notlar da 0-100 arasında değişiyor olmalı. Grade alanına bu kısıtı ekleyelim ve 100 ün üzerinde data girilmesini engelleyelim.
ALTER TABLE myTable ADD CONSTRAINT
CK_Grade CHECK(Grade <= 100 AND Grade >= 0)
Eğer tablomuzda veriler varsa ve daha önceden girilmiş verilerin kontrol edilmesini istemiyorsak with nocheck ifadesiyle bunu yapabiliriz. Aksi takdirde, veriler eklenen kurala uygun hale getirilene kadar check constraint eklenemez.
ALTER TABLE myTable WITH NOCHECK ADD CONSTRAINT
CK_Grade CHECK(Grade <= 100 AND Grade >= 0)
Computed Columns Nedir? Nasıl Kullanılır?
Computed column, bir tablonun aynı satırındaki diğer alanlara referans ederek hesaplama yapan bir formüldür aslında. Scalar fonksiyonlar da (tek bir değer döndüren fonksiyon), computed column tanımlarken kullanılabilir. Bir computed column, başka bir tablodaki verilere (tabii fonksiyon kullanmıyorsa) ulaşamaz veya sub query içeremez.
Varsayılan olarak, SQL Server'daki computed column lar sanaldır. Yani içerdikleri değerler diskte saklanmazlar, veri çekildiği zaman hesaplanırlar. Bu nedenle computed column içeren bir tabloyu SELECT * FROM ile çekmek performans sıkıntılarına yol açabilir.
Computed kolonları daha etkin tutmak ve performansını arttırmak için, disk üzerinde de saklayabiliriz. Bunun için PERSISTED anahtar kelimesi kullanılabilir.
SQL Server, persisted ile işaretlenmiş computed alanları, gerçek bir değer olarak disk üzerinde saklar ve bu alanı etkileyecek herhangi bir değişiklik olduğunda veya yeni kayıt eklendiğinde bu alanı da günceller.
Sadece deterministic fonksiyon kullanan computed kolonlar PERSISTED olarak işaretlenebilir.
Deterministic fonksiyon, aynı değer verildiğinde aynı sonucu döndüren fonksiyondur. Örneğin avg fonksiyonu, aynı değerler ile her zaman aynı sonucu döndürür. Oysa getdate(), deterministic bir fonksiyon değildir.
Bir computed column, deterministic olsun veya olmasın içerisindeki veri güncellenemez. Dolayısıyla hiçbir zaman insert veya update cümlesi içerisinde güncellenecek alanlar içerisinde yer alamaz.
Bir örnek ile nasıl computed kolon yaratıldığını görelim.
Bir tabloda ürünün birim satış fiyatı ve vergi oranı olsun. Vergi eklenmiş hali kaç fiyata satılacağını computed kolon kullanarak bulabiliriz.
ALTER TABLE myTable ADD PriceWithTax as UnitPrice + (UnitPrice*TaxRatio)
Varsayılan olarak, SQL Server'daki computed column lar sanaldır. Yani içerdikleri değerler diskte saklanmazlar, veri çekildiği zaman hesaplanırlar. Bu nedenle computed column içeren bir tabloyu SELECT * FROM ile çekmek performans sıkıntılarına yol açabilir.
Computed kolonları daha etkin tutmak ve performansını arttırmak için, disk üzerinde de saklayabiliriz. Bunun için PERSISTED anahtar kelimesi kullanılabilir.
SQL Server, persisted ile işaretlenmiş computed alanları, gerçek bir değer olarak disk üzerinde saklar ve bu alanı etkileyecek herhangi bir değişiklik olduğunda veya yeni kayıt eklendiğinde bu alanı da günceller.
Sadece deterministic fonksiyon kullanan computed kolonlar PERSISTED olarak işaretlenebilir.
Deterministic fonksiyon, aynı değer verildiğinde aynı sonucu döndüren fonksiyondur. Örneğin avg fonksiyonu, aynı değerler ile her zaman aynı sonucu döndürür. Oysa getdate(), deterministic bir fonksiyon değildir.
Bir computed column, deterministic olsun veya olmasın içerisindeki veri güncellenemez. Dolayısıyla hiçbir zaman insert veya update cümlesi içerisinde güncellenecek alanlar içerisinde yer alamaz.
Bir örnek ile nasıl computed kolon yaratıldığını görelim.
Bir tabloda ürünün birim satış fiyatı ve vergi oranı olsun. Vergi eklenmiş hali kaç fiyata satılacağını computed kolon kullanarak bulabiliriz.
ALTER TABLE myTable ADD PriceWithTax as UnitPrice + (UnitPrice*TaxRatio)
sys.Objects View ile veritabanındaki nesnelerin görüntülenmesi
SELECT * FROM sys.objects
kodunu çalıştırarak veritabanındaki tüm nesnelerin listesine ulaşılabilir.
Bu kodun döndürdüğü alanlardan bazılarına bakalım.
name :nesnesnin adı
object_id: SQL Server'deki her bir nesnenin tek bir id si vardır. Sistem tablolarında veya view lerinde bu id ile kullanırlar. Örnein bir tablonun içindeki kolonlar sys.columns view i kullanılarak görülebilir. Bir kolonun hangi tabloya ait olduğu bilgisi saklanırken, objenin adı değil, id si saklanır. Bir nesnenin id sini öğrenmek için de object_id sistem fonksiyonu kullanılabilir.
SELECT object_id('myobjectname')
type : SQL Server objesinin ne tür bir obje olduğunu gösterir. Aşağıda bu türlerin listesini bulabilirsiniz.
C Check constraint
D Default constraint
F Foreign Key constraint
FN Transact-SQL scalar function
FS Clr scalar function
IT Internal table
P SQL stored procedure
PK Primary Key constraint
S System table
SQ Service queue
TF SQL table valued function
TR SQL trigger
U User table
UQ Unique constraint
V View
kodunu çalıştırarak veritabanındaki tüm nesnelerin listesine ulaşılabilir.
Bu kodun döndürdüğü alanlardan bazılarına bakalım.
name :nesnesnin adı
object_id: SQL Server'deki her bir nesnenin tek bir id si vardır. Sistem tablolarında veya view lerinde bu id ile kullanırlar. Örnein bir tablonun içindeki kolonlar sys.columns view i kullanılarak görülebilir. Bir kolonun hangi tabloya ait olduğu bilgisi saklanırken, objenin adı değil, id si saklanır. Bir nesnenin id sini öğrenmek için de object_id sistem fonksiyonu kullanılabilir.
SELECT object_id('myobjectname')
type : SQL Server objesinin ne tür bir obje olduğunu gösterir. Aşağıda bu türlerin listesini bulabilirsiniz.
C Check constraint
D Default constraint
F Foreign Key constraint
FN Transact-SQL scalar function
FS Clr scalar function
IT Internal table
P SQL stored procedure
PK Primary Key constraint
S System table
SQ Service queue
TF SQL table valued function
TR SQL trigger
U User table
UQ Unique constraint
V View
Performance Data Management ve Resource Governor
Performance data management SQL Server 2008 ile gelen yeni bir tool.
Bu tool, zamanla, SQL Server üzerinden performans ile ilgili veri toplamımızı sağlıyor.
Bir datawarehouse (toplandığı sonuçları saklamak için) ve "data collector" (belli zamanlarda çalışarak veri toplamak için) parçalarından oluşuyor.Data Collector sadece SQL Server 2008 versiyonlarındaki veritabanları için çalışıyor.
Resource Governor ise süreçlerin kaynak kullanımlarını sınırlandırarak, iş yüklerinin yönetilmesine olanak veriyor.
Resource Governor u kullanmak için, DBA bir "workload group" ve bir "resource pool" yaratır. Workload group ları kullanıcıların oturumlarını tutan yapılardır. Workload groupları, resource pool ları ile eşleştirilirler. Bu eşleştirmeler sınıflandırıcı fonksiyonlara göre (classifier functions) yapılır. Sınıflandırıcı fonksiyonlar IP, kullanıcı adı, uygulamanın adı olabilir.
Resource Governence tool'u kullanarak, kritik uygulamalara daha fazla ram, cpu gibi kaynaklar ayırıp, çok fazla performansa ihtiyacı olmayan uygulamalar için daha az kaynak ayırabiliriz örneğin.
Bu tool, zamanla, SQL Server üzerinden performans ile ilgili veri toplamımızı sağlıyor.
Bir datawarehouse (toplandığı sonuçları saklamak için) ve "data collector" (belli zamanlarda çalışarak veri toplamak için) parçalarından oluşuyor.Data Collector sadece SQL Server 2008 versiyonlarındaki veritabanları için çalışıyor.
Resource Governor ise süreçlerin kaynak kullanımlarını sınırlandırarak, iş yüklerinin yönetilmesine olanak veriyor.
Resource Governor u kullanmak için, DBA bir "workload group" ve bir "resource pool" yaratır. Workload group ları kullanıcıların oturumlarını tutan yapılardır. Workload groupları, resource pool ları ile eşleştirilirler. Bu eşleştirmeler sınıflandırıcı fonksiyonlara göre (classifier functions) yapılır. Sınıflandırıcı fonksiyonlar IP, kullanıcı adı, uygulamanın adı olabilir.
Resource Governence tool'u kullanarak, kritik uygulamalara daha fazla ram, cpu gibi kaynaklar ayırıp, çok fazla performansa ihtiyacı olmayan uygulamalar için daha az kaynak ayırabiliriz örneğin.
Encryption Konusunda İyileştirmeler
SQL Server 2008 den önceki versiyonlarında, tüm veri tabanını etkin olarak kriptolamak için 3. parti bir araç almak gerekiyordu.
SQL Server 2008 ile birlikte, Transparent data encryption (TDE) özelliği geldi.
TDE ile tüm veritabanının içeriğini kolayca şifrelemek mümkün ve bunu yaparken uygulamalarınızda bir değişiklik yapmanız da gerekmiyor.
TDE kullanmak için, öncelikle "master key" ve "certificate" yaratmak gerekiyor. Master Key ve sertifikanızı oluşturduktan sonra,
ALTER DATABASE myDatabase SET ENCRYPTION ON
kodunu kullanarak veritabanınızda encrpytion ı açabilirsiniz.
Encryption , veritabanını "key" kullanarak güvenlik altına alır. Bu key ler korunmalı, backup ı alınmalıdır. Sistemde herhangi bir sorun olduğunda, veriye ulaşabilmek için bu key ler gerekli olacaktır. Bu nedenle key leri daha güvenli ve daha farklı bir donanımda tutmak, güvenliği arttıracaktır.
SQL Server 2008 ile birlikte, Transparent data encryption (TDE) özelliği geldi.
TDE ile tüm veritabanının içeriğini kolayca şifrelemek mümkün ve bunu yaparken uygulamalarınızda bir değişiklik yapmanız da gerekmiyor.
TDE kullanmak için, öncelikle "master key" ve "certificate" yaratmak gerekiyor. Master Key ve sertifikanızı oluşturduktan sonra,
ALTER DATABASE myDatabase SET ENCRYPTION ON
kodunu kullanarak veritabanınızda encrpytion ı açabilirsiniz.
Encryption , veritabanını "key" kullanarak güvenlik altına alır. Bu key ler korunmalı, backup ı alınmalıdır. Sistemde herhangi bir sorun olduğunda, veriye ulaşabilmek için bu key ler gerekli olacaktır. Bu nedenle key leri daha güvenli ve daha farklı bir donanımda tutmak, güvenliği arttıracaktır.
Sparse Columns ile NULL kolonlarınız daha az er kaplasın
Sparse Column Support
Sparse column desteği, SQL Server 2008 ile gelen yeni özelliklerden.
Null içeren kolonlarımızı daha optimize bir şekilde saklıyor.
İyi bir özellik olmak ile birlikte, gerçekten null içermeyen kolonlarda kullanılmazsa, veritabanımızın disk üzerinde kapladığı alan küçülmek yerine daha fazla da büyüyebilir.
Sparse kolon özelliğini kullanmak için bir kolonu yaratırken "SPARSE" yazmak yeterli.
CREATE TABLE dbo.myTable
(
ID int NULL,
MyValue varchar(50) SPARSE NULL
)
GO
Sparse column desteği, SQL Server 2008 ile gelen yeni özelliklerden.
Null içeren kolonlarımızı daha optimize bir şekilde saklıyor.
İyi bir özellik olmak ile birlikte, gerçekten null içermeyen kolonlarda kullanılmazsa, veritabanımızın disk üzerinde kapladığı alan küçülmek yerine daha fazla da büyüyebilir.
Sparse kolon özelliğini kullanmak için bir kolonu yaratırken "SPARSE" yazmak yeterli.
CREATE TABLE dbo.myTable
(
ID int NULL,
MyValue varchar(50) SPARSE NULL
)
GO
SQL Serrver 2008 ile FileStream Veri Türü
Normalde DB Engine, tüm veriyi, kolon ile ilişkilendirerek, diskteki bir dosyada tutar.
FileStream veri türü ile her türlü veriyi (özellikle binary) SQL Server da saklamak daha kolay hale geldi.
FileStream i kullanabilmek için öncelikle enable etmemiz gerekiyor.
Management Studio'dan Advanced Settings den bunu yapabilir veya
sp_FILESTREAM_configure sistem prosedürünü çalıştırabiliriz.
Bundan sonra, veri tabanına yeni bir file group eklemek gerekiyor. FileStream veri tipi ile tutacağımız veriler, bu yeni açacağımız file group içinde saklanacaklar.
Ancak FileStream kullanmanın birkaç sınırlaması da var. has the following limitations:
FileStream veri türü ile her türlü veriyi (özellikle binary) SQL Server da saklamak daha kolay hale geldi.
FileStream i kullanabilmek için öncelikle enable etmemiz gerekiyor.
Management Studio'dan Advanced Settings den bunu yapabilir veya
sp_FILESTREAM_configure sistem prosedürünü çalıştırabiliriz.
Bundan sonra, veri tabanına yeni bir file group eklemek gerekiyor. FileStream veri tipi ile tutacağımız veriler, bu yeni açacağımız file group içinde saklanacaklar.
Ancak FileStream kullanmanın birkaç sınırlaması da var. has the following limitations:
- FileStream verisi içeren bir veritabanı ile "Database mirroring" yapılamıyor.
- Database snapshots, FileStream verilerini desteklemiyor.
- Encryption , FileStream verileri için desteklenmiyor. En azından bunu SQL Server'ın encrpytion yöntemlerini kullanarak yapamıyorsunuz. Başka bir encryption metodu bulmanız gerekiyor.,
SQL Server 2008 - CDC (Change Data Capture) ile Verilerinizdeki Değişikliklerden Haberdar Olun
CDC, SQL Server 2008 ile gelen bir başka önemli özellik.
Verilerinizdeki değişiklikleri CDC kullanarak denetleyebilirsiniz.
CDC, bir tablodaki, insert, update ve delete işlemlerini yakalayıp, değişiklikleri başka bir tabloya yazar.
Aşağıdaki kodu kullanarak bir tablodaki değişikliklerin kayıtlarını tutmaya başlayabilirsiniz.
--Bir veritabanında CDC seçeneği açık değilse aşağıdaki sistem prosedürü çalıştırılır ve CDC o veri tabanı için aktif hale getirilir.
EXEC sys.sp_cdc_enable_db_change_data_capture
--Değişiklikleri kaydetmek istediğiniz her tablo için de, aşağıdaki prosedürü çalıştırarak, ilgili tablo için CDC yi aktif hale getirebilirsiniz.
EXEC sys.sp_cdc_enable_table_change_data_capture
@source_schema = 'dbo',
@source_name = 'myTable',
@role_name = 'cdc'
CDC tablosundaki verileri okuyabilmek ve diğer CDC işlemleri için hazırlanmış bir çok sistem prosedürü ve fonksiyonu hazır olarak sunulur.
Sistem prosedürleri :
Verilerinizdeki değişiklikleri CDC kullanarak denetleyebilirsiniz.
CDC, bir tablodaki, insert, update ve delete işlemlerini yakalayıp, değişiklikleri başka bir tabloya yazar.
Aşağıdaki kodu kullanarak bir tablodaki değişikliklerin kayıtlarını tutmaya başlayabilirsiniz.
--Bir veritabanında CDC seçeneği açık değilse aşağıdaki sistem prosedürü çalıştırılır ve CDC o veri tabanı için aktif hale getirilir.
EXEC sys.sp_cdc_enable_db_change_data_capture
--Değişiklikleri kaydetmek istediğiniz her tablo için de, aşağıdaki prosedürü çalıştırarak, ilgili tablo için CDC yi aktif hale getirebilirsiniz.
EXEC sys.sp_cdc_enable_table_change_data_capture
@source_schema = 'dbo',
@source_name = 'myTable',
@role_name = 'cdc'
CDC tablosundaki verileri okuyabilmek ve diğer CDC işlemleri için hazırlanmış bir çok sistem prosedürü ve fonksiyonu hazır olarak sunulur.
Sistem prosedürleri :
- sys.sp_cdc_add_ job
- sys.sp_cdc_ generate_wrapper_ function
- sys.sp_cdc_change_ job
- sys.sp_cdc_ get_captured_columns
- sys.sp_cdc_cleanup_change_table
- sys.sp_cdc_ get_ddl_history
- sys.sp_cdc_disable_db
- sys.sp_cdc_help_change_data_capture
- sys.sp_cdc_disable_table
- sys.sp_cdc_help_ jobs
- sys.sp_cdc_scan
- sys.sp_cdc_enable_db
- sys.sp_cdc_start_ job
- sys.sp_cdc_enable_table
- sys.sp_cdc_stop_ job
- sys.sp_cdc_drop_ job
- cdc.fn_cdc_ get_all_changes_<capture_instance>
- sys.fn_cdc_has_column_changed
- cdc.fn_cdc_ get_net_changes_<capture_instance>
- sys.fn_cdc_increment_lsn
- sys.fn_cdc_decrement_lsn
- sys.fn_cdc_is_bit_set
- sys.fn_cdc_ get_column_ordinal
- sys.fn_cdc_map_lsn_to_time
- sys.fn_cdc_ get_max_lsn
- sys.fn_cdc_map_time_to_lsn
- sys.fn_cdc_ get_min_lsn
Copy Only Backup
"Copy Only Backup", development veya test için tek seferlik backup a ihtiyacınız olduğunuzda kullanabileceğiniz bir seçenektir. Avantajı, transaction log veya Differential backup lardan etkilenmemesidir. Transaction Log veya Differential backup lar için temel bir backup olarak da kullanılamaz.
Management Studio'daki Backup Interface'inden "Copy Only Backup" seçeneğini işaretleyerek, backup alabilirsiniz.
Kodla yapmak için de:
BACKUP DATABASE [myDatabaseName] TO DISK = N'C:\Backup\myDatabaseName.bak' WITH
COPY_ONLY, NOFORMAT, NOINIT, NAME = N'myDatabaseName-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
Management Studio'daki Backup Interface'inden "Copy Only Backup" seçeneğini işaretleyerek, backup alabilirsiniz.
Kodla yapmak için de:
BACKUP DATABASE [myDatabaseName] TO DISK = N'C:\Backup\myDatabaseName.bak' WITH
COPY_ONLY, NOFORMAT, NOINIT, NAME = N'myDatabaseName-Full Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10
SQL Server 2008 ile Compressed Backups
Compressed Backups (Sıkıştırılmış Yedekler), SQL Server 2008 ile gelen en iyi yeniliklerden biri.
Sıkıştırılmış backup alarak, zaman ve disk yeri tasarrufu yapabilirsiniz. Alınmış backuplarınızı daha sonra başka bir sıkıştırma uygulaması kullanarak sıkıştırmanıza veya sıkıştırılmış bir backup almak için 3. parti bir uygulama kullanmanıza gerek kalmaz.
Sıkıştırılmış backup almak, daha uzun sürecek izlenimi uyandırsa da, backup süresince diskte darboğazlar oluştuğunu biliyoruz, sıkıştırılmış backup ile, diske daha az veri yazılayacağı için backup süresi, normal backup işlemine göre genelde daha az sürer.
Sıkıştırılmış bir backup almak için de, tek yapmanız gereken management studio da backup aldığınız ekranda "Compressed Backup" seçeneğini işaretlemek.
Eğer t-SQL kodu ile backup alıyorsanız aşağıdaki kodu kullanmanız yeterli.
BACKUP DATABASE [myDatabaseName] TO DISK = N'C:\Backup\myDatabaseName.bak' WITH
NOFORMAT, NOINIT, NAME = N'myDatabaseName-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
Sıkıştırılmış backup alarak, zaman ve disk yeri tasarrufu yapabilirsiniz. Alınmış backuplarınızı daha sonra başka bir sıkıştırma uygulaması kullanarak sıkıştırmanıza veya sıkıştırılmış bir backup almak için 3. parti bir uygulama kullanmanıza gerek kalmaz.
Sıkıştırılmış backup almak, daha uzun sürecek izlenimi uyandırsa da, backup süresince diskte darboğazlar oluştuğunu biliyoruz, sıkıştırılmış backup ile, diske daha az veri yazılayacağı için backup süresi, normal backup işlemine göre genelde daha az sürer.
Sıkıştırılmış bir backup almak için de, tek yapmanız gereken management studio da backup aldığınız ekranda "Compressed Backup" seçeneğini işaretlemek.
Eğer t-SQL kodu ile backup alıyorsanız aşağıdaki kodu kullanmanız yeterli.
BACKUP DATABASE [myDatabaseName] TO DISK = N'C:\Backup\myDatabaseName.bak' WITH
NOFORMAT, NOINIT, NAME = N'myDatabaseName-Full Database Backup', SKIP,
NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
13 Ekim 2010 Çarşamba
DBCC Input Buffer ile Tablolarımızı Loglayalım
"DBCC INPUTBUFFER", SQL Server'a client'dan gelen son sql cümleciğini gösterir.
Syntax :
DBCC INPUTBUFFER (session_id [ , request_id ])
[WITH NO_INFOMSGS ]
Parametreleri :
session_id
Son aktif connection'daki oturumun id'sidir.
@@SPID global değişkeni ile, sql server'daki son request'in id si ni alabilirsiniz.
SELECT @@SPID
kodunu çalıştırarak örneğini görebilirsiniz.
request_id
Aktif oturumdaki, son istedğin id sidir.
Son gelen isteğin id sini aşağıdaki kodu kullanarak alabilirsiniz.
SELECT request_id
FROM sys.dm_exec_requests
WHERE session_id = @@spid
Aşağıdaki kod ise, son request ile ilgili daha fazla detay verir. Durumu ne, hangi veri tabanına gelmiş, kim çalıştırmış, ne kadar süre beklemiş gibi.
SELECT *
FROM sys.dm_exec_requests
WHERE session_id = @@spid
WITH
With, diğer DDL komutlarında olduğu gibi bir özellik vereceğimizi ifade eder.
NO_INFOMSGS
Hata seviyesi 0-10 arasında olan yani server tarafında bilgi mesajı olarak kabul edilen seviyede bir mesaj gelirse, bunu gizler.
Bu kadar teorik bilgiden sonra, "DBCC INPUTBUFFER" ın ne işimize yarayacağına ve nasıl kullanılacağımıza bakalım.
CDC kullanmadan, bir tablodaki değişiklikleri log'luyor isek, bu değişikliğin hangi sql cümlesi kullanılarak (Bu bir update/insert/delete statement olabileceği gibi, bir stored procedure de olabilir) yapıldığını saklayabiliriz.
Veya bir tablo, nedenini bulamadığımız bir şekilde güncelleniyor ise, bu güncelleme işleminin hangi kod tarafından yapıldığını yakalayabiliriz.
Aşağıdaki örnek SQL cümlesi, testCustomer isimli bir tablodaki her değişikliği loglayıp, değişiklikleri de testCustomer_Log isimli bir dosya da saklayacağız.
Önce kodlarımızı hazırlayalım.
Acaba log tablomuzda neler olmuş?
İşte tüm yaptığımız değişikliker burada görünüyor.
İlk başta çalıştırdığımız insert cümlesi 2 kayıt birden insert edecek bir batch şeklinde yazılmıştı. Customer 1 ve Customer 2 kayıtlarında bu her iki cümlenin de yazdığını görebiliyoruz.
En ilginci de, 4 nolu CustomerID nin update cümlesi. Burada ilgili müşteri numarasını bulduktan sonra bunu bir procedure e veriyor ve onun güncelleme yapmasını bekliyorduk. Yazdığımız tüm kod da burada aynen görünebiliyor.
Peki testCustomer tablosunu TRUNCATE TABLE ile temizlersek ne olur? Log tablosuna hiç bir şey gelmez. Çünkü truncate kodu herhangi bir trigger'ı tetiklemez. Biz de işlerimizi trigger ile yaptığımız için log tablosunun herhangi birşeyden haberi olmaz.
Bir sonraki post'da DBCC INPUTBUFFER a benzer iş yapan fn_get_sql sistem fonksiyonundan ve ikisi arasındaki farklardan bahsedeceğiz.
Syntax :
DBCC INPUTBUFFER (session_id [ , request_id ])
[WITH NO_INFOMSGS ]
Parametreleri :
session_id
Son aktif connection'daki oturumun id'sidir.
@@SPID global değişkeni ile, sql server'daki son request'in id si ni alabilirsiniz.
SELECT @@SPID
kodunu çalıştırarak örneğini görebilirsiniz.
request_id
Aktif oturumdaki, son istedğin id sidir.
Son gelen isteğin id sini aşağıdaki kodu kullanarak alabilirsiniz.
SELECT request_id
FROM sys.dm_exec_requests
WHERE session_id = @@spid
Aşağıdaki kod ise, son request ile ilgili daha fazla detay verir. Durumu ne, hangi veri tabanına gelmiş, kim çalıştırmış, ne kadar süre beklemiş gibi.
SELECT *
FROM sys.dm_exec_requests
WHERE session_id = @@spid
WITH
With, diğer DDL komutlarında olduğu gibi bir özellik vereceğimizi ifade eder.
NO_INFOMSGS
Hata seviyesi 0-10 arasında olan yani server tarafında bilgi mesajı olarak kabul edilen seviyede bir mesaj gelirse, bunu gizler.
Bu kadar teorik bilgiden sonra, "DBCC INPUTBUFFER" ın ne işimize yarayacağına ve nasıl kullanılacağımıza bakalım.
CDC kullanmadan, bir tablodaki değişiklikleri log'luyor isek, bu değişikliğin hangi sql cümlesi kullanılarak (Bu bir update/insert/delete statement olabileceği gibi, bir stored procedure de olabilir) yapıldığını saklayabiliriz.
Veya bir tablo, nedenini bulamadığımız bir şekilde güncelleniyor ise, bu güncelleme işleminin hangi kod tarafından yapıldığını yakalayabiliriz.
Aşağıdaki örnek SQL cümlesi, testCustomer isimli bir tablodaki her değişikliği loglayıp, değişiklikleri de testCustomer_Log isimli bir dosya da saklayacağız.
Önce kodlarımızı hazırlayalım.
CREATE TABLE testCustomer(CustomerID int identity(1,1),
FirstName varchar(100),
LastName varchar(100))
GO
--DROP TABLE testCustomer_Log
CREATE TABLE testCustomer_Log(ID int identity(1,1),
CustomerID int,
OldFirstName nvarchar(100),
OldLastName nvarchar(100),
NewFirstName nvarchar(100),
NewLastName nvarchar(100),
SqlCommand nvarchar(4000),
ChangedOn datetime default(GetDate())
)
GO
CREATE TRIGGER trTestCustomer ON testCustomer
AFTER UPDATE,INSERT,DELETE
AS BEGIN
DECLARE @InputBuffer TABLE(EventType nvarchar(30),
Parameters int,
EventInfo nvarchar(4000))
INSERT INTO @InputBuffer
exec ('DBCC INPUTBUFFER(@@SPID) WITH NO_INFOMSGS')
DECLARE @SQLCommand nvarchar(4000)
SELECT @SQLCommand = EventInfo
FROM @InputBuffer
INSERT INTO testCustomer_Log(CustomerID,OldFirstName,OldLastName,
NewFirstName,NewLastName,SqlCommand)
SELECT isNull(i.CustomerID,d.CustomerID),d.FirstName,d.LastName,
i.FirstName,i.LastName,@SQLCommand
FROM inserted i
FULL JOIN deleted d on d.CustomerID = i.CustomerID
END
GO
CREATE PROCEDURE spTEST_UpdateCustomerName @FirstName nvarchar(100),@CustomerID int
AS BEGIN
UPDATE testCustomer SET FirstName = @FirstName WHERE CustomerID = @CustomerID
END
Data ve Log tablolarını yarattıktan sonra, Data tablomuz olan testCustomer üzerine bir trigger yazıyoruz. Bu trigger de @@SPID ile son oturumun id sini alıp, DBCC INPUTBUFFER a veriyoruz. Bize uyarı mesajları vermesin diye de mesajları "WITH NO_INFOMSG" yazarak kapatıyoruz.
DBCC INPUTBUFFER 3 kolondan, 1 satırdan oluşan bir tablo döndürür. Bu tablodan dönen değerleri @InputBuffer isimli bir değişken tabloya yazıyoruz ki, sonra DML kodunu çalıştıran kodu alabilelim.
EventInfo kolonunda, nvarchar(4000) tipinde bir bilgi gelir. İşte datayı değiştiren kod da bu kolonda bulunur. Yani çalışan script eğer 4000 karakterden fazla ise, ilk 4000 karakterini görebiliriz. Bu kodu @SQLCommand değişkenine atıyoruz.
Sonra değişen bilgilerin eski ve yeni bilgilerini yazabilmek için de, trigger içerisinde kullanılan inserted ve deleted tablolarını full join ile bağlıyoruz.
Unutmamak gerekir ki, bir tabloya insert kodu ile bir kayıt ekliyorsak, sadece inserted tablosunda kayıtlar olur, deleted tablosundan birşey gelmez. Aynı mantıkla, delete ile kayıt siliyorsak, sadece deleted tablosunda silinen kaydın bilgisi olur, inserted tablosunda birşey olmaz. Update ile tabloyu güncelliyor isek, yeni bilgiler inserted tablosunda, eski bilgiler de deleted tablosunda bulunur.
Birkaç örnek ile trigger ın log tablosuna neler yazdığını bulalım.
INSERT INTO testCustomer(FirstName,LastName) VALUES('Abc','DEF')
INSERT INTO testCustomer(FirstName,LastName) VALUES('Abc','fsfdsfdsf')
GO
INSERT INTO testCustomer(FirstName,LastName) VALUES('TestFN','TestLN')
GO
INSERT INTO testCustomer(FirstName,LastName) VALUES('TestFN2','TestLN2')
GO
UPDATE testCustomer SET FirstName = 'Abc Updated' WHERE FirstName = 'Abc'
GO
DELETE FROM testCustomer WHERE FirstName='TestFN'
GO
DECLARE @CustomerID int
SELECT @CustomerID = CustomerID
FROM testCustomer
WHERE FirstName='TestFN2'
exec spTEST_UpdateCustomerName @CustomerID = @CustomerID, @FirstName = 'TestFN3'
GO
SELECT * FROM testCustomer
SELECT * FROM testCustomer_Log
İşte Customer tablosunun son hali. 4 kayıt ekledik. Kayıtlardan birini update cümlesi ile güncelledik. Sonra başka bir kayıt sildik. Daha sonra da adı TestFN2 olan kaydın adını yazdığımız stored procedure ile güncelledik.
| CustomerID | FirstName | LastName |
| 1 | Abc Updated | DEF |
| 2 | Abc Updated | fsfdsfdsf |
| 4 | TestFN3 | TestLN2 |
| ID | CustomerID | OldFirstName | OldLastName | NewFirstName | NewLastName | SqlCommand | ChangedOn |
| 1 | 1 | Abc | DEF | INSERT INTO testCustomer(FirstName,LastName) VALUES('Abc','DEF') INSERT INTO testCustomer(FirstName,LastName) VALUES('Abc','fsfdsfdsf') | 13.10.2010 | ||
| 2 | 2 | Abc | fsfdsfdsf | INSERT INTO testCustomer(FirstName,LastName) VALUES('Abc','DEF') INSERT INTO testCustomer(FirstName,LastName) VALUES('Abc','fsfdsfdsf') | 13.10.2010 | ||
| 3 | 3 | TestFN | TestLN | INSERT INTO testCustomer(FirstName,LastName) VALUES('TestFN','TestLN') | 13.10.2010 | ||
| 4 | 4 | TestFN2 | TestLN2 | INSERT INTO testCustomer(FirstName,LastName) VALUES('TestFN2','TestLN2') | 13.10.2010 | ||
| 5 | 2 | Abc | fsfdsfdsf | Abc Updated | fsfdsfdsf | UPDATE testCustomer SET FirstName = 'Abc Updated' WHERE FirstName = 'Abc' | 13.10.2010 |
| 6 | 1 | Abc | DEF | Abc Updated | DEF | UPDATE testCustomer SET FirstName = 'Abc Updated' WHERE FirstName = 'Abc' | 13.10.2010 |
| 7 | 3 | TestFN | TestLN | DELETE FROM testCustomer WHERE FirstName='TestFN' | 13.10.2010 | ||
| 8 | 4 | TestFN2 | TestLN2 | TestFN3 | TestLN2 | DECLARE @CustomerID int SELECT @CustomerID = CustomerID FROM testCustomer WHERE FirstName='TestFN2' exec spTEST_UpdateCustomerName @CustomerID = @CustomerID, @FirstName = 'TestFN3' | 13.10.2010 |
İşte tüm yaptığımız değişikliker burada görünüyor.
İlk başta çalıştırdığımız insert cümlesi 2 kayıt birden insert edecek bir batch şeklinde yazılmıştı. Customer 1 ve Customer 2 kayıtlarında bu her iki cümlenin de yazdığını görebiliyoruz.
En ilginci de, 4 nolu CustomerID nin update cümlesi. Burada ilgili müşteri numarasını bulduktan sonra bunu bir procedure e veriyor ve onun güncelleme yapmasını bekliyorduk. Yazdığımız tüm kod da burada aynen görünebiliyor.
Peki testCustomer tablosunu TRUNCATE TABLE ile temizlersek ne olur? Log tablosuna hiç bir şey gelmez. Çünkü truncate kodu herhangi bir trigger'ı tetiklemez. Biz de işlerimizi trigger ile yaptığımız için log tablosunun herhangi birşeyden haberi olmaz.
Bir sonraki post'da DBCC INPUTBUFFER a benzer iş yapan fn_get_sql sistem fonksiyonundan ve ikisi arasındaki farklardan bahsedeceğiz.
28 Eylül 2010 Salı
Relations (Veritabanı ilişkileri)
Bu konudan önce, Normalization başlıklı yazıyı okumanızı öneririm.
Relation, veri tabanı tasarımcılarının, normalize edilmiş bir veri tabanı yaratırken, veri tekrarını önlemek için kullandıkları bir araçtır. Basitçe, relation, tekrarlanan verinin, veritabanında hangi tabloların, hangi alanlarında bulunacağını gösteren bir yoldur.
Ana verinin bulunduğu tabloya parent table denir. Normalization yazısında örneğini yaptığımız ve müşteri bilgilerinin tutulduğu Customer tablosu, bir parent tablodur.
Parent tabloda bulunan asıl veriye ulaşmak için pointerların tutulduğu tabloya Child tablo denir. Parent ve Child tablolar birbirleriyle ilişkilidirler. Yine normalizasyon yazısındaki, normalize edilmiş Order tablosu, bir child tablodur. Order tablosundaki CustomerID ile Customer tablosundaki CustomerID alanıyla ilişkilidir.
Customer tablosundaki, CustomerID nin her bir müşteri için ayrı olduğunu ve Customer ID den müşterinin tüm bilgilerine ulaşabileceğimizi söylemiştik. Yani Customer tablosundaki CustomerID unique'dir ve başka tablolar ile CustomerID alanı ile ilişkilendirilir. Bu neden Customer tablosundaki CustomerID'yi primary key yapabiliriz.
Bu durumda, diğer tablolardaki (Örneğin Order tablosundaki) CustomerID alanı, Customer tablosundaki, CustomerID yi işaret eder ve buna da foreign key denir.
Birkaç çeşit veritabanı ilişkisi vardır.
One-To-One (1 - 1) : Parent tablodaki bir satıra karşılık, child tablodada sadece 1 satır bulunur. Örneğin Müşteri tablosundaki adres bilgisini başka bir tabloda tutsaydık ve sadece tek bir adres girilmesine izin verseydik, Müşteri ve Adres tablosu arasında "Bire - Bir" ilişki kuracaktık.
One-To-Many (1 - *) : Parent tablodaki bir satıra karşılık, child tabloda birden fazla satır olabilir. Tıpkı Müşteri ve Sipariş tablosundaki ilişki gibi. Bir müşteri 1 veya daha fazla sipariş verebilir.
Many-To-Many (*-*) : Parent tablodaki bir satıra karşılık, child tabloda birden fazla satır olabildiği gibi, child tablodaki bir satıra karşılık da, parent tabloda birden fazla satır olabilir. Many-To-Many ilişki aslında birden çok One-To-Many ilişkinin bir araya gelmesinden oluşur. Bu ilişkileri bir araya getirecek olan ve Many-To-Many ilişkiyi sağlayacak olan bir ara bağlantı tablosudur. Bu tablo sadece ilişkide gerekli olan alanları tutar.
Aşağıdaki şekil, many to many ilişki kurulmuş bir örnek gösteriyor. Asp.Net 'in user - role leri yönetmemiz için hazırladığı aspnetservices veri tabanından bir gösterim.
Users ve Roles tabloları var. Bir kullanıcı birden fazla role'de yer alabileceği gibi, bir role için de birden fazla kullanıcı tanımlanabilir.
Kullanıcı bilgileri aspnet_Users tablosunda tutuluyor. Yanında anahtar resmi görünen UserId alanı, tablonun primary key'i.
Role'ler, aspnet_Roles tablosunda tutuluyor. RoleId alanı ise, bu tablonun primary key'i.
Many-To-Many ilişkiyi sağlayan ise aspnet_UserInRoles tablosu. Bu tabloda sadece her iki tablonun da primary key'leri tutuluyor.
Bu gösterimi, SQL Server Management Studio'da, "Database Diagram" kullanarak hazırladım. Tüm veri tabanı tasarım toolları tablolar arasındaki ilişkinin varlığını araya çizgi çekerek ifade eder. Sadece ilişki türleri biraz farklı gösterilebilir. SQL Server, Tek bir kayıt olacağını gösterdiği yerler için anahtar şeklini, çoklu kayıt olacak yerlerde ise sonsuz işaretini kullanmış.
aspnet_Users ile aspnet_UsersInRoles arasındaki ilişkide, aspnet_Users tarafında bir anahtar işareti görünüyor. Bu, ilişkinin o tarafında tek bir satırın olacağını gösteriyor. aspnet_UsersInRoles tablosuna bağlanan yerde ise bir sonsuz işareti var, bu tabloda bir kullanıcıya karşılık istediğimiz kadar role ekleyebileceğimiz anlamına geliyor.
Aynı türde ilişki aspnet_Roles ve aspnet_UsersInRoles tabloları arasında da kurulmuş. Bu ilişki de bir role'ün birden fazla kullanıcıya verilebileceğini ifade ediyor.
Sonuç olarak, bu 3 tablo ile, bir kullanıcıya birden fazla görev verilebilirken, bir görevde de birden fazla kullanıcının olabileceği bir yapı sağlanmış oluyor.
Primary key, foreign key ve ilişkilerin SQL Server'da nasıl tanımlandığına daha sonra değineceğiz.
Relation, veri tabanı tasarımcılarının, normalize edilmiş bir veri tabanı yaratırken, veri tekrarını önlemek için kullandıkları bir araçtır. Basitçe, relation, tekrarlanan verinin, veritabanında hangi tabloların, hangi alanlarında bulunacağını gösteren bir yoldur.
Ana verinin bulunduğu tabloya parent table denir. Normalization yazısında örneğini yaptığımız ve müşteri bilgilerinin tutulduğu Customer tablosu, bir parent tablodur.
Parent tabloda bulunan asıl veriye ulaşmak için pointerların tutulduğu tabloya Child tablo denir. Parent ve Child tablolar birbirleriyle ilişkilidirler. Yine normalizasyon yazısındaki, normalize edilmiş Order tablosu, bir child tablodur. Order tablosundaki CustomerID ile Customer tablosundaki CustomerID alanıyla ilişkilidir.
Customer tablosundaki, CustomerID nin her bir müşteri için ayrı olduğunu ve Customer ID den müşterinin tüm bilgilerine ulaşabileceğimizi söylemiştik. Yani Customer tablosundaki CustomerID unique'dir ve başka tablolar ile CustomerID alanı ile ilişkilendirilir. Bu neden Customer tablosundaki CustomerID'yi primary key yapabiliriz.
Bu durumda, diğer tablolardaki (Örneğin Order tablosundaki) CustomerID alanı, Customer tablosundaki, CustomerID yi işaret eder ve buna da foreign key denir.
Birkaç çeşit veritabanı ilişkisi vardır.
One-To-One (1 - 1) : Parent tablodaki bir satıra karşılık, child tablodada sadece 1 satır bulunur. Örneğin Müşteri tablosundaki adres bilgisini başka bir tabloda tutsaydık ve sadece tek bir adres girilmesine izin verseydik, Müşteri ve Adres tablosu arasında "Bire - Bir" ilişki kuracaktık.
One-To-Many (1 - *) : Parent tablodaki bir satıra karşılık, child tabloda birden fazla satır olabilir. Tıpkı Müşteri ve Sipariş tablosundaki ilişki gibi. Bir müşteri 1 veya daha fazla sipariş verebilir.
Many-To-Many (*-*) : Parent tablodaki bir satıra karşılık, child tabloda birden fazla satır olabildiği gibi, child tablodaki bir satıra karşılık da, parent tabloda birden fazla satır olabilir. Many-To-Many ilişki aslında birden çok One-To-Many ilişkinin bir araya gelmesinden oluşur. Bu ilişkileri bir araya getirecek olan ve Many-To-Many ilişkiyi sağlayacak olan bir ara bağlantı tablosudur. Bu tablo sadece ilişkide gerekli olan alanları tutar.
Aşağıdaki şekil, many to many ilişki kurulmuş bir örnek gösteriyor. Asp.Net 'in user - role leri yönetmemiz için hazırladığı aspnetservices veri tabanından bir gösterim.
Kullanıcı bilgileri aspnet_Users tablosunda tutuluyor. Yanında anahtar resmi görünen UserId alanı, tablonun primary key'i.
Role'ler, aspnet_Roles tablosunda tutuluyor. RoleId alanı ise, bu tablonun primary key'i.
Many-To-Many ilişkiyi sağlayan ise aspnet_UserInRoles tablosu. Bu tabloda sadece her iki tablonun da primary key'leri tutuluyor.
Bu gösterimi, SQL Server Management Studio'da, "Database Diagram" kullanarak hazırladım. Tüm veri tabanı tasarım toolları tablolar arasındaki ilişkinin varlığını araya çizgi çekerek ifade eder. Sadece ilişki türleri biraz farklı gösterilebilir. SQL Server, Tek bir kayıt olacağını gösterdiği yerler için anahtar şeklini, çoklu kayıt olacak yerlerde ise sonsuz işaretini kullanmış.
aspnet_Users ile aspnet_UsersInRoles arasındaki ilişkide, aspnet_Users tarafında bir anahtar işareti görünüyor. Bu, ilişkinin o tarafında tek bir satırın olacağını gösteriyor. aspnet_UsersInRoles tablosuna bağlanan yerde ise bir sonsuz işareti var, bu tabloda bir kullanıcıya karşılık istediğimiz kadar role ekleyebileceğimiz anlamına geliyor.
Aynı türde ilişki aspnet_Roles ve aspnet_UsersInRoles tabloları arasında da kurulmuş. Bu ilişki de bir role'ün birden fazla kullanıcıya verilebileceğini ifade ediyor.
Sonuç olarak, bu 3 tablo ile, bir kullanıcıya birden fazla görev verilebilirken, bir görevde de birden fazla kullanıcının olabileceği bir yapı sağlanmış oluyor.
Primary key, foreign key ve ilişkilerin SQL Server'da nasıl tanımlandığına daha sonra değineceğiz.
27 Eylül 2010 Pazartesi
Normalizasyon
RDBMS (Relational Database Management System) ın en önemli kavramlarından biridir normalizasyon(normalization).
Normalizasyonun ne olduğuna örnek üzerinden bakalım.
Diyelim ki bir Customer tablomuz var. İçerisinde Müşteri Numarası, Adı - Soyadı ve Adres alanları var.
Customer Tablosu
Eğer bir müşterinin siparişi için bir tablomuz varsa, sipariş özeti için bize gerekli olan bilgiler Müşterinin Adı, Soyadı, Adresi, Sipariş Tarihi ve Sipariş Tutarı.
Müşteri bilgilerini "Sipariş " bilgilerini tuttuğumuz Order tablosuna da kopyalayacak mıyız o zaman? Müşteri bilgilerini Order tablosunda da taşınırsa ne olur peki? Bir müşterinin her bir siparişi için, Order tablosunda müşterinin tüm bilgileri tekrarlanır. Bu Order tablosunun gereksiz yere fazla bilgi ile dolmasına ve verilen diskte gerektiğinden fazla yer kaplamasına neden olacaktır. Tabii bu bilgiler sadece tabloda değil, aynı zamanda index tablolarında da tekrarlanacaktır. Ancak daha da önemlisi, müşterinin bilgilerinde bir değişiklik olduğunda sadece Customer tablosunu güncellememiz yeterli olmayacak, Order tablosunda da o müşteriye ait tüm sipariş kayıtlarını bulmamız ve onları da güncellememiz gerekecektir. Bunu unutmamız durumunda ve update işlemi sırasında bir hata ile karşılaşırsak ve bu da kayıtların bir kısmını güncelleyip, bir kısmını da güncellemez ise ortaya çıkacak karmaşayı düşünebiliyor musunuz?
İşte tüm bu karmaşadan ve sorunlardan kaçınmak için tablolar normalize olarak tutulur. Normalizasyon, bir grup tablo tanımlama kuralıdır. Normalizasyon kurallarına göre, tablolar tasarlanırken, bağlantılı oldukları tabloların her birinden sadece tek bir alan içerirler. Tabii bu alan tek olunca, bağlantılı oldukları tablodaki doğru kaydı bulabilecek bir bilgi tutmalıdırılar. Örneğin sipariş tablosundan, müşteri bilgisi olarak müşterinin sadece adını tutmamız, aynı isimde birden fazla müşteri olacağı için bir işe yaramaz. Bunun için Müşteri numarası gibi, her bir müşteri için tek olan ve değişmeyecek bir alan seçilmelidir.
İşte normalize edilmiş Sipariş tablosu :
Normalizasyonun da çeşitleri vardır. 3rd Normal Form, 4th Normal Form gibi.
Bu detaylara daha sonra gireceğiz. Ancak akılda tutulması gereken şey, normalizasyon, veri tekrarının önlemek için konulan bir veri tabanı tasarım kuralı olmasıdır. .
Normalizasyonun tam tersine, yani bir tabloda, diğer tablolardaki birçok bilginin tekrarlandığı, kayıt tekrarına izin verilen tablolara denormalize edilmiş tablolar denir.
Veri güncellemesi yapılmayan, daha çok raporlama için kullanılan veri tabanlarında, hızlı sorgulama yapılmak için tablolar denormalize edilebilir.
Bu da denormalize edilmiş bir sipariş tablosu
Normalizasyon ile ilgili daha detaylı bilgiler yakında burada olacak.
Normalizasyonun ne olduğuna örnek üzerinden bakalım.
Diyelim ki bir Customer tablomuz var. İçerisinde Müşteri Numarası, Adı - Soyadı ve Adres alanları var.
Customer Tablosu
| Customer ID | FirstName | LastName | Address |
| 1 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
| 2 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
| 3 | Birsen | Tunç | 1825 Sk. No:5/6 Konak / İzmir |
| 4 | Erdem | Yazar | Test Sk. No:5/6 Şişli / İstanbul |
Eğer bir müşterinin siparişi için bir tablomuz varsa, sipariş özeti için bize gerekli olan bilgiler Müşterinin Adı, Soyadı, Adresi, Sipariş Tarihi ve Sipariş Tutarı.
Müşteri bilgilerini "Sipariş " bilgilerini tuttuğumuz Order tablosuna da kopyalayacak mıyız o zaman? Müşteri bilgilerini Order tablosunda da taşınırsa ne olur peki? Bir müşterinin her bir siparişi için, Order tablosunda müşterinin tüm bilgileri tekrarlanır. Bu Order tablosunun gereksiz yere fazla bilgi ile dolmasına ve verilen diskte gerektiğinden fazla yer kaplamasına neden olacaktır. Tabii bu bilgiler sadece tabloda değil, aynı zamanda index tablolarında da tekrarlanacaktır. Ancak daha da önemlisi, müşterinin bilgilerinde bir değişiklik olduğunda sadece Customer tablosunu güncellememiz yeterli olmayacak, Order tablosunda da o müşteriye ait tüm sipariş kayıtlarını bulmamız ve onları da güncellememiz gerekecektir. Bunu unutmamız durumunda ve update işlemi sırasında bir hata ile karşılaşırsak ve bu da kayıtların bir kısmını güncelleyip, bir kısmını da güncellemez ise ortaya çıkacak karmaşayı düşünebiliyor musunuz?
İşte tüm bu karmaşadan ve sorunlardan kaçınmak için tablolar normalize olarak tutulur. Normalizasyon, bir grup tablo tanımlama kuralıdır. Normalizasyon kurallarına göre, tablolar tasarlanırken, bağlantılı oldukları tabloların her birinden sadece tek bir alan içerirler. Tabii bu alan tek olunca, bağlantılı oldukları tablodaki doğru kaydı bulabilecek bir bilgi tutmalıdırılar. Örneğin sipariş tablosundan, müşteri bilgisi olarak müşterinin sadece adını tutmamız, aynı isimde birden fazla müşteri olacağı için bir işe yaramaz. Bunun için Müşteri numarası gibi, her bir müşteri için tek olan ve değişmeyecek bir alan seçilmelidir.
İşte normalize edilmiş Sipariş tablosu :
| OrderID | CustomerID | OrderDate | OrderAmount |
| 1001 | 1 | 15.02.2010 | 150 |
| 1002 | 3 | 15.02.2010 | 250 |
| 1003 | 1 | 16.02.2010 | 500 |
| 1004 | 2 | 17.02.2010 | 100 |
| 1005 | 4 | 18.02.2010 | 1250 |
| 1006 | 2 | 19.02.2010 | 85 |
| 1007 | 2 | 20.02.2010 | 950 |
| 1008 | 1 | 21.02.2010 | 120 |
Normalizasyonun da çeşitleri vardır. 3rd Normal Form, 4th Normal Form gibi.
Bu detaylara daha sonra gireceğiz. Ancak akılda tutulması gereken şey, normalizasyon, veri tekrarının önlemek için konulan bir veri tabanı tasarım kuralı olmasıdır. .
Normalizasyonun tam tersine, yani bir tabloda, diğer tablolardaki birçok bilginin tekrarlandığı, kayıt tekrarına izin verilen tablolara denormalize edilmiş tablolar denir.
Veri güncellemesi yapılmayan, daha çok raporlama için kullanılan veri tabanlarında, hızlı sorgulama yapılmak için tablolar denormalize edilebilir.
Bu da denormalize edilmiş bir sipariş tablosu
| OrderID | CustomerID | OrderDate | OrderAmount | FirstName | LastName | Address |
| 1001 | 1 | 15.02.2010 | 150 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
| 1002 | 3 | 15.02.2010 | 250 | Birsen | Tunç | 1825 Sk. No:5/6 Konak / İzmir |
| 1003 | 1 | 16.02.2010 | 500 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
| 1004 | 2 | 17.02.2010 | 100 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
| 1005 | 4 | 18.02.2010 | 1250 | Erdem | Yazar | Test Sk. No:5/6 Şişli / İstanbul |
| 1006 | 2 | 19.02.2010 | 85 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
| 1007 | 2 | 20.02.2010 | 950 | Can | Demir | Test Mah. Deneme Sk. No:5/6 Lüleburgaz / Kırklareli |
| 1008 | 1 | 21.02.2010 | 120 | Ali | Veli | Deneme Mah. Deneme Sk. No:5/6 Kadıköy / İstanbul |
Normalizasyon ile ilgili daha detaylı bilgiler yakında burada olacak.