Prosedür (SQL Stored Procedure) Parametreleri Nasıl Sorgulanır

Veritabanı hakkında bilgi toplayan veya bazı kod parçacıklarını dinamik olarak oluşturan araçlar yazamamız gerektiğinde, bir Stored Procedure'den parametre bilgilerini almamız gerekebilir. Bu durum pek sık karşılaşılan bir durum olmasada, başımıza gelirse ne şekillerde bu sorunu çözebiliriz, ben nasıl çözdüm paylaşmak istedim.

Öncelikle elimizin altında her zaman "sp_helptext" SP'si var. Bu şekilde hakkında bilgi almak istediğimiz SP'leri sorgulayabiliriz. "sp_helptext SP_ADI" şeklinde sorguladığımız zaman SP'nin tüm içeriğini text olarak bize dönecektir. Buradan sonra string işlemleri ile gereken bilgilere ulaşabiliriz. Bu durum sorunumuz için kullanabileceğimiz en kötü yöntem ama genede bir çözüm. Özellikle standart bir kod yazım stiline sahip olmayan kodlamalarda, bir çok kez sıkıntı yaşamamız olasıdır.

Enterprise Library kullanıyorsak eğer, burada oluşurduğumuz Database'in GetStoredProcCommand metodundan bir DBCommand (adı cmd olsun) oluşturduktan sonra, gene Database'in DiscoverParameters metodunu oluşturduğumuz cmd ile kullanarak SP'mizin tüm parametrelerini alabiliriz. Bu yöntem yukarıdaki ilk öneriden çok daha garantili ve performanslı bir yöntemdir. 
DiscoverParameters metodu bize basitçe bir DbParameterCollection'ı hazırlayacaktır. Artık cmd.Parameters dediğimizde istediğimiz parametrenin her bilgisine ulaşabiliriz.

Peki Enterprise Library bu bilgileri nasıl alıyor derseniz. En bağımsız son yöntem direk veritabanına SP parametrelerini sormak. SQL Server versiyonu bu sorgularda önemlidir.

2000 İçin;
[sp_procedure_params_rowset]
Örnek:

USE MYDB

exec [sp_procedure_params_rowset] @procedure_name = 'SP_NAME', @procedure_schema = 'SP_SCHEMA'

2005 ve Muhtemelen 2008 İçin
[sys].[sp_procedure_params_managed]

Bu SP'ler detaylı parametre bilgilerini bizim seçtiğimiz SP'ler için dönecektir.

SQL 2005 üzerinde bulunan bu tür diğer kullanışlı sys SP'leri;
[sys].sp_procedure_params_90_rowset
[sys].sp_procedures_rowset
[sys].sp_procedures_rowset2 
[sys].sp_procedure_params_90_rowset2
[sys].sp_procedure_params_rowset
[sys].sp_procedure_params_rowset2

Tabloların Fiziksel Yapıları

SQL 2005 ve muhtemelen SQL 2008 için, tablo dediğimiz yapılar nasıldır, mantıksal ve fiziksel olarak nasıl işlenir dersek...

Büyükten küçüğe doğru gidersek Tablo, Extent, Page olarak sıralamamızı yapabiliriz. Bu sıradan da anlaşılacağı gibi Page'ler ile Extent'ler oluşur. Extent'ler ile de tablo dediğimiz yapı oluşur.

SQL'de tabloların oluşabileceği 3 çeşit allocation unit vardır. Tablo bunlardan bir veya daha fazlası ile oluşturulabilir. Her tabloda mutlaka olan tek allocation unit IN_ROW_DATA'dır. Diğerleri ise LOB_DATA ve ROW_OVERFLOW_DATA'dır.

IN_ROW_DATA türü allocaion unitler; büyük olmayan veri tiplerini barındırır. Eğer varchar, nvarchar, varbinary, sql_variant veri tiplerinin toplam satır boyutu 8KB üzerinde çıkarsa, ROW_OVERFLOW_DATA kullanılmaya başlanır. Bu kısımların detaylarını Page'leri incelerken göreceğiz.

LOB_DATA türü allocation unit'ler; text, ntext, image, xml, varchar(max), nvarchar(max), varbinary(max) türlerini barındırır.

SQL'de Page boyutu 8KB'dir. Disk işlemleri Page üzerinden yapılır yani Page üzerinde okuma veya yazma işlemleri yapılır. Her Page 96 byte'lık bir header bilgisi ile başlar ve bu bilginin hemen ardından Data Row'lar gelir. Header içerisinde Page Number, Page Type, Page için kalan boş alan, ve Page'ın owner (Extent) bilgisi tutulur. Her bir Data Row'un, Page üzerindeki ilk Data Row'dan ne kadar sonra başladığı bilgisi Page'in en altındaki offset tablosunda tutulur. Bu tablodaki sıralama Data Row'ların Page içerisindeki sıralamasının tam tersidir.

Bir Data Row birden fazla Page içerisinde olamaz. Peki o zaman bizim 8K'dan büyük satır veya alanlarımız ne olacak derseniz. Büyük veri barındıran Data Row'lar farklı tür bir allocation unit içerisindeki Page'lerde saklanır. text, ntext, image, nvarchar(max), varchar(max), varbinary(max), ve xml veri tipleri LOB_DATA türünde, varchar, nvarchar, varbinary, sql_variant veri tiplerinden toplam içeriği 8KB üzerinde olanlar ROW_OVERFLOW_DATA türündeki allocation unit içerisindeki Page'lerde saklanır.

Normal şartlarda varchar, nvarchar, varbinary, sql_variant veri tiplerin tek başına uzunluğu 8K'yı geçemez ancak birlikte toplam uzunlukları bu değeri geçebilir. Bir INSERT veya UPDATE işlemi toplam row boyutunu (tüm kolonlar ile) 8K üzerine taşırsa, bu row ROW_OVERFLOW_DATA üzerindeki bir Page'e taşınır, bu taşımada en büyük olan kolon uzunluğuna göre bir yeni Page uzunluğu belirlenir. Taşınmadan önceki IN_ROW_DATA üzerindeki değeri de 24 byte'lık bir pointer ile güncellenir. Toplam row boyutu 8K altına düştüğünde ise, ilgili işlemler geri alınır ve row tekrar IN_ROW_DATA allocation unit üzerindeki Page' taşınır.

IN_ROW_DATA ve ROW_OVERFLOW_DATA arasındaki yazma işlemleri zaman alıcı işlemlerdir. Ayrıca taşınan kolonlar sorgu için kullanıldıklarında bu işlemde normal IN_ROW_DATA üzerindeki veri okumasına göre daha uzun sürmektedir. Bu sebeplerden tablo oluştururken bu tür toplam değerlerin 8K'yı geçip geçmediği ayrıca kontrol edilmelidir.
Bu alanların ne sıklıkla sorgulara dahil edildiği düşünülmelidir. Hem IN_ROW_DATA hemde ROW_OVERFLOW_DATA üzerinden senkron okumalar yapmak maliyetli ve zaman alıcı işlemlerdir. Eğer yapılabiliyorsa bu alanlar farklı bir tabloya çekilmelidir. Bu şekilde senkron okuma sayısı azaltılabilir. Farklı tablo join edildiğinde asenkron okuma kullanılacak, iki farklı tablo okunacak ve birleştirilecektir, kısaca ana tablo değerleri daha hızlı elde edilecektir.
Buradaki bir kritik nokta da şudur; Clustered Index Key alanları ROW_OVERFLOW_DATA üzerinde asla olamaz, eğer varchar alanımız Clustered Index Key ise, toplam uzunluğun 8K'yı geçirdiği durumunda, işlemler başarısız olacaktır. Bu konu ile ilgili daha detaylı bilgiye buradan ulaşılabilir.

Page'lerin gruplanmasıyla Extext'ler oluşur. Extent'ler (boş) alan yönetimlerinin kullanımı için kullanılır. Bir extent 8 ardışık Page'den veya 64K'dan oluşur. Verimli kullanımlar için Extent'ler birden fazla tablo Page'lerini barındırabilir, bu tür Extent'lere Mixed Extent denir. Sadece tek tablo Page'lerini bulunduran Extent'lere Uniform Extent denir. Mixed Extent'ler genelde ufak tablolar için kullanılır. Bir tablo 8 Page boyutunu aşarsa, ilgili tabloya ait Mixed Extent'ler Uniform Extent'lere dönüştürülür. Bu konunun detayını burada bulabilirsiniz.

Peki tablo türlerine göre daha kabaca yapıları incelersek nasıl bir durum ile karşılaşırız...

Heap
Heap dediğimiz aslında Clustered Index'i olmayan bir tablodur, bu tabloda kayıtlar herhangi bir sırada değildir. Heap'ler yukarıdaki üç allocation unit türlerine sahip olabilir. Hangisi veya hangilerine sahip olacaklarını yukarıda anlatılan row boyutu ve veri türleri belirler. Heap'lerin Clustered Index veya Non-Clustered Index'lerden farkları; Heap Data Page kayıtları sıralı ve birbirleri ile bağlantılı değildir. (Not Linked.) sys.partitions içerisinde, tek Partition'lı Heap'ler için 1 kayıt gelir ve index_id alanının değeri 0'dır. Birden fazla partition kullanılmış ise Partition sayısı kadar kayıt gelecektir.
Aşağıdaki Heap veri tutma şeması size bir fikir verebilir. Konu ile ilgili detaya buradan ulaşabilrisiniz.
Aşağıdaki şema bir Partition içindir, Heap eğer birden fazla Partition'dan oluşuyorsa, her bir Partition üzerinde aşağıdaki yapıdan birer tane vardır.

Clustered Index
Clustered Index'lerde, Index'ler B-tree mantığı ile tutulur. En üstte bir Root Node, en altta verileri tutan Leaf Node ve araların Intermediate Level denilen yerde bağlantı Node bulunur.
Leaf Node verileri barındıran Data Page'leri tutarken, Intermediate ve Root Level Node'lar Index bilgilerini barındıran Index Page'lerini tutar. Her bir Index Row, bir değer ve bir pointer tutar. Bu pointer B-tree üzerindeki Intermediate Level Page veya Leaf üzerindeki bir Data Row olabilir. Clustered Index'lerde Page'ler, birbirlerine çift olarak bağlıdır. (Doubly-Linked) Clustered Index üzerinde yapılan aramalarda, bu bağlı olma durumu, aramanın çok hızlı bir şekilde yapılmasına olanak vermektedir.
sys.partitions içerisinde, tek Partition'lı Clustered Index için 1 kayıt gelir ve index_id alanının değeri 1'dir. Birden fazla partition kullanılmış ise Partition sayısı kadar kayıt gelecektir. Aşağıdaki şema tek Partition içindir, çoklu Partition kullanımında, aşağıdaki şemadan her bir Partition için ayrı ayrı olacaktır.Konu ile ilgili detaya buradan ulaşabilrisiniz.

Non-Clustered Index
Non-Clustered Index'ler aslında Clustered Index'ler gibi B-tree yapısındadır. Aralarındaki en önemli fark ise Non-Clustered Index'ler veri tutmazlar, Key kolonları ve Clustered Index'e veya Heap'e referans bilgisini tutarlar. Dolayısıyla Leaf Node Data Page yerine Index Page'lerden oluşur. (Include kolonlar hariç.)
sys.partitions içerisinde, index_id alanı 0'dan büyüktür. Partition'lara göre davranışı Clustered Index ile aynıdır. Bir Partition için oluşan yapısının şeması aşağıdaki gibidir.
Detaylı bilgiye buradan ulaşabilirsiniz. Non-Clustered Index'lerin key kolon sayısı en fazla 16 olabilir ve bu kolonların toplam uzunluğu 900 byte'ı geçemez.

Non-Clustered Index'lerin Heap, Unique Clustered Index ve Non-Unique Clustered Index'ler ile nasıl eşleştiğinin detaylarını buradaki yazımdan bulabilirsiniz. Include kolonları ve işleyişleri ile ilgili olarak da buradaki yazımdan faydalanabilirsiniz.

Non-Clustered Index ve Include Kullanımı

SQL Server 2005 ve 2008'de Non-Clustred Index'lere Include kolonları ekleme şansımız var. Clustered Index'ler üzerinde ise Include kullanma imkanımız yok. Zaten Clustered Index verilerimizin kendisi olduğundan dolayı, tüm kolonlarımız Clustered Index'imize Include edilmiş haldedir diyebiliriz.

Non-Clustered Indexlerde, Index'i belirleyen Key kolonların yanında nonkey kolonları "Include" edebiliyoruz. Bu NonKey kolonlar sadece Leaf Node üzerinde saklanıyor. Non-Clustered Index'lerin key kolon sayısı en fazla 16 olabilir ve bu kolonların toplam uzunluğu 900 byte'ı geçemez. Bu kurala uymayan durumlarda Include kullanımı gene bize yardımcı oluyor. Include olarak kullanılan kolonlar Index Size'a dahil edilmiyor.

Bir Müşteri tablosu düşünelim. MüşteriNo alanımız Clustered Index Key'imiz ve Müşteri Soyadı artı İsmi alanları üzerinde bir Non-Clustered Index tanımımız var. İsimle yaptığımız bir aramada bu Non-Clustered Index kullanılıyor. Örneğin; İsmi Can Uzun olan müşterilerimizi ünvanları ile ekrana dökmek istediğimizde (Emin olun sayıları çok fazladır :). Non-Clustered Index üzerinde hızlı bir şekilde ismi uygun olan kayıtlar bulunuyor, bu kayıtlardaki Clustered Index'e ait Logical RID ile Clustered Index'e ulaşılıyor, sonrasında disk üzerinde kaydın yerini bildiğimizden tüm satırı okuyor ve Ünvan bilgisine ulaşıyoruz. Bay Can Uzun şeklinde bir çok kaydı listelemiş oluyoruz.

Peki Non-Clustered Index'imize Unvan alanını Include edersek ne olur. Bu durumda Non-Clustered Index üzerinde uygun olan kayıtlar gene hızlı bir şekilde bulunacak ancak bundan sonra Unvan bilgisi Index'imiz içerisinde zaten olduğundan, Clustered Index üzerinden daha fazla I/O işlemi yapmamıza gerek kalmayacak. Eğer isim aramalarının çoğunda Unvan bilgisi de bize gerekli ise, bu alanı Include yaparak çok ciddi bir performans kazanımı elde edebiliriz.

Bu noktada şunu unutmamak lazım, sorgumuzda tablodaki beş alan bize gerekli ama Index'imizde key ve nonkey alanlarda sadece dördü varsa, SQL motoru Clustered Index üzerinden satırı okumak zorunda kalacaktır. Bu sorguda Include kolonlarımızın olması bizim için bir avantaj olmayacaktır. Diğer yandan Include edilen her kolon Index boyutumuzu arttıracaktır, her Non-Clustered Index'e birçok Include yapmamız bir süre sonra disk sıkıntısı yaşamamıza sebep olacaktır. Özellikle varchar(max) gibi büyük veri tipleri bize çok fazla yer sıkıntısı yaşatacaktır. Bunun yanında Include için kullanılan kolonlar güncellendiğinde Non-Clustered Index'lerin de Include alanları güncellenecektir. 
Kısacası Include alanlar uygun şekilde kullanıldığında bize büyük performans artışı sağlayacaktır. Ancak bu kolonların verileri diskte hem Clustered Index hemde Non-Clustered Index üzerinde olacağından INSERT, UPDATE işlemleri bu durumdan etkilenecektir.

Hangi alanları Include yapmalıyız dersek.

SQL motoru, istatistiklere göre key kolon önerilerinde ne kadar başarılıysa, nonkey kolon önerilerinde de o kadar başarısızdır. Neredeyse tüm tablo kolonlarını size Include edin şeklinde önerecektir. Key kolonlarımıza eklemek istemediğimiz veya gerek duymadığımız, ancak key kolonlarımız ile sürekli veya çok sık kullanılan alanları Include olarak ekleyebiliriz.


Mevcut bir Index'i silip baştan oluşturmadan, Include alanları değiştiremediğimizi de unutmamalıyız.

Clustered Index Seçimi

Clustered Index seçimi tablolarımızdaki en önemli seçimdir diyebiliriz. Clustered Index, fiziksel olarak disk üzerindeki sıralamanın oluşturulmasında kullanılan clustered key veya clustered key'ler içerir. Detayını buradaki yazımda okuyabilirsiniz.

Peki Clustered Index seçerken nelere dikkat etmeliyiz, veya kesinlikle önerilen bir yöntem varmıdır dersek. Genel veritabanı kuralı olan duruma göre değişir lafı burada da geçerli :)

Öncelikle hangi tablolarda Clustered Index kullanmamalıyız konusunu aradan çıkaralım. Sürekli güncellenen veya tablolar arası taşıma durumlarının çok olduğu tablolarda Clustered Index kullanılmayabilir, bu sadece bir öneridir, uygun durum sistemden sisteme değişebilir, bu sebepten iki seçenekte denenerek daha verimli olan tercih edilmelidir. Bir diğer durum ise, büyük kolonlardan oluşan tablolarda her Non-Clustered Index için Clustered Index Key Logical RID kullanılacağından, index boyutları çok büyük olacaktır. Bu tür tablolarda da Clustered Index ve Heap denenmeli, daha verimli olan yöntem tercih edilmelidir.

Clustred Index kullanmaya karar verdiysek, şimdi hangi kolon veya kolonları seçmemiz gerektiğine karar vermemiz kalıyor geriye.

Örneğin çok sayıda INSERT alan tablolarda yeni gelen kaydın tablonun en altına eklenmesi genellikle tercih edilen bir yöntemdir. Bu durumda giderek artan değerlerden oluşan bir Clustered Index yapısı tercih edilebilir. Bu tür bir seçimde seçilen key'in Unique olup olmaması konusuda önemlidir, onun detaylarını da buradan okuyabilirsiniz.

Clustered Index key güncellenen bir kolon olmamalıdır. Bu her güncelemede kaydın fiziksel olarak yer değiştirmesi demektir, bu hem performansı çok kötü etkileyecek hemde index üzerindeki fragmantation'ı arttıracaktır.

Clustered Index, disk üzerindeki fiziksel sıralama demek olduğundan, BETWEEN, >, >=, <, <= gibi sorgu filtreleri eğer Clustered Index Key üzerinden sorgulama yaparlarsa SQL kaynak kullanımı en alt seviyede olacak ve disk üzerinden fiziksel okuma ile kayıtlar çok hızlı elde edilebilecektir. Clustered Index Key aynı şekilde Sort işlemlerinde kullanıldığında, veriler zaten sıralı olduğundan ek bir işleme gerek kalmayacaktır. Group By kullanımında gene sıralı verilerin gruplanması çok daha hızlı olacaktır.

Bu bilgilerin dışında ben kişisel olarak, bu tabloların ne kadar sürede bakım görecekleri ile de çok ilgilenirim. Uygun şartlarda veritabanları haftada bir veya en azından iki haftada bir bakımdan geçmelidir. Ancak benim çalıştığım neredeyse hiç bir şirket bu şekilde bir bakımı düzgün olarak yapmamaktadır. Index yapıları bozulduğunda index'ler sisteme destek değil köstek olmaya başlarlar. Fragmantation değerlerinin %10'lara geldiği nice kritik kullanılan tablo görmüşümdür ve bu şirketler günde yüzbinler veya bazen milyonlarca transaction alan şirketler. Bakım yapmama konusunda inatçı veya umursamaz olan müşterilere veritabanı tasarlarken Clustered Index Key kesinlikle artan bir değer olmalıdır diyebilirim. Non-Clustered Index'ler bozulduğunda buna yapabileceğimiz birşey yok ama en azından bu şekilde Clustered Index'lerin bozulmamasını sağlamış oluyoruz.

Düzgün bakım yapıldığını varsayarak ilerlersek. Az INSERT alan tablolarda INSERT maliyeti kesinlikle ihmal edilmelidir. Yani müşteri bilgilerini tutan bir tablo ile müşterilerin satın alma bilgilerini tutan tablo aynı şekilde değerlendirilmemelidir.

Bir bankayı düşünelim, sizce bir banka günde kaç yeni müşteriyi veritabanına ekleyebilir. Bir de şunu düşünelim, bu bankanın tüm müşterileri bir günce kaç kredi kartı işlemi yapabilir. Bu şekilde düşündüğümüzde sürekli INSERT alan ve az INSERT alan tabloları kafamızda canlandırabilmiş oluyoruz.

Bankamız eğer müşteri numarası ile işlemleri yapıyorsa MüşteriNo alanımızı Clustered Index Key olarak seçebiliriz, ama genellikle isim ve soyad bilgisi ile sorgularımızı yapıyorsak o zaman burada İsim ve Soyad alanları beraber Clustered Key Index olarak seçilebilir. Bu şekilde isim ile yapılan aramalarımız çok daha hızlı sonuçlanacaktır. Soyad bilgisinin isme göre daha değişken olduğunu da düşünürsek Soyad ve İsim sırası ile Clustered Key Index oluşturmamız daha da mantıklı olacaktır. Buradaki amacımız isim ve soyad ile yapılan aramalarda en üst performansı almaktı ve bunu başardık. 
Peki dezavantajlarımız neler oldu?
Öncelikle Soyad ve İsim Unique değildir, bir çok kişi aynı Clustered Index Key'e sahip olacaktır, SQL bunu engellemek için uniquifier denilen 4 byte'lık bir görünmez kolonu Clustered Index'imize ve dolayısıyla tüm Non-Clustred Index'imize ekleyecektir.
Tablomuza az da olsa yeni eklenen kayıtlar sıralı olmadığından, fiziksel olarak diğer kayıtların aralarına girmek durumunda kalacak, kayıt kaydırma işlemleri başlayacak ve tablomuzda fragmantation oluşacaktır, bunu engellemek için düzenli bakım yapmamız ve fill factor değerini yüksek tutmamız gerekecektir.

Peki sırayla artan bir Müşteri No bizim Clustered Index Key'imiz olsaydı ve Soyad İsim alanına Non-Clustered bir index tanımlamış olsaydık olmaz mıydı?

Olurdu, bu şekilde uniquifier alanına gerek kalmazdı ve Clustered Index fragmantation derdimizde ortadan kalkardı, müşteri no ile gelen sorgular çok hızlı olurdu ve sıralı çok sayıda müşteri numarasını çok hızlı bir şekilde sorgulayabilir, gruplayabilir ve sıralayabilirdir.

Kısacası bunlar bizim tercihlerimiz ile ilgili. Bizim tercihlerimizi de sistemin kullanılma şekli, ve sistemden beklelenlerin öncelikleri belirlemeli. Burada ilk başta yapılan tasarım daimi olacak diye bir kural yok, yaptığımız hatanın farkına varınca gerekli değişiklikleri yapma şansımız olabilir, sonuçta bazı durumlar denenmeden bilinemiyor.

Sürekli çalışan sistemlerdeki tablolara dokunmak son derece zor veya bazen imkansız olabiliyor, bu tür durumlarda SQL 2005 ile gelen ve çeşitli durumlarda kullanılabilen ONLINE ve MAXDOP parametrelerini araştırmakta fayda var.

Temel Index İşlemleri

Index'ler üzerinde ne yapabiliz konusuna başlamadan önce, clustered ve non-clustered index'ler nelerdir diyorsanız sizi buraya davet ediyoruz, bu yazıda anlatılan Physical RID ve Logical RID mantığı bir kere oturduktan sonra büyük ihtimalle SQL'in nasıl davranacağını tahmin edebilir hale geliyoruz. Tek fark versiyonların çalışma şekillerinin değişebiliyor olması.

Sonradan Clustered Index Oluşturmak 
Bir tabloda clustered index sonradan oluşturulduğunda, bu değişiklik tüm kayıtların fiziksel oladak disk üzerinde sıralamalarının değişmesi ve tüm non-clustered indexlerin de eskiden kullandıkları physical RID alanlarının clustered key Logical RID bilgisi ile güncellenmesi manasına gelir. Bu durumda tüm non-clustered index'ler Rebuild edilir(baştan oluşturulur).

Clustered Index'imiz Var Ama Siliyoruz 
Bir tabloda varolan bir clustered index'i sildiğimizde, yani heap'e geçerken; üstteki işlemin tersine, non-clustered indexlerde bulunan Logical RID bilgileri Physical RID bilgileri ile değiştirilir. Bu durumda da tüm non-clustered index'ler Rebuild edilir.

Unique Clustered Index ve Non-Unique Clustered index farkları için buradaki yazımı okuyabilirsiniz.

Index Rebuild çalışmalarında öncelikle Clustered Index Rebuild edilmeli, sonrasında Non-Clustered Index'ler rebuild edilmelidir. Clustered Index ilk oluşturulurken, işlem tamamen bitene kadar disk üzerindeki eski veriler saklı kalır. Büyük tablolarda yeterli disk alanının olduğu kontrol edildikten sonra, Clustered Index oluşturulmalı veya değiştirilmelidir.

Clustered Index Rebuild İşlemi
Varolan bir Unique Clustered Index'imizi Rebuild ettiğimizde, disk üzerinde clustered key bilgisine göre, Clustered Index sıralamasına uygun olarak düzenlenir. Burada Logical RID değişmediği için Non-Clustered Index'ler bu işlemden etkilenmezler.

Non-Unique Clustered Index Rebuild edildiğinde ise, SQL 2000 buradaki uniquifier alanını günceller ve bu sebepten tüm Non-Clustered Index'ler Rebuild edilir. Ancak bilğim kadarıyla SQL 2005 ve SQL 2008 aynı uniquifier'ı kullanmaya devam ettiği için Non-Clustered Index'ler bu işlemden etkilenmezler.

Clustered Index Değişimi
Clustered Index için kullanılan kolon veya kolonlar değiştirildiğinde, -barındırdığı veri değil, clustered key olarak seçilen kolonların yerine farklı kolonlar seçildiğinde, eklendiğinde, çıkarıldığında- Clustered Index baştan oluşturulur, bu disk üzerindeki sıralamanın değişmesi ve dolayısıyla Non-Clustered Index'lerde bulunan Logical ID'lerin artık geçersiz olması demek, çünkü barındırdıkları Logical ID eski clustered key için gerçerli olarak kalacak. Bu sebepten Non-Clustered Index'ler Rebuild edilir.

SQL 2005 ile gelen table partition işlemleri, sadece clustered key alanının disk yerini etikelediği için bu durumlarda Non-Clustered Index'ler tekrar Rebuild edilmezler. Kullandıkları Logical RID partition sonrasında da geçerli olacaktır. Aynı durum filegroup değiştirilmesi içinde geçerlidir.

Clustered ve Non-Clustered Index

Index'ler konusuna gelirsek iki index örneğimiz var, clustered index bir anlamda tablonun kendisi demek, non-clustered index ise, kabaca belirli alanların direk clustered key ile eşleştirilerek tüm tablonun taranmasına engel olmak demek diyebiliriz. Yazımın sonunda basit bir örnek vereceğim.

Detaylara girmeden önce sıkça kullanılan bir kısaltma RID : Record ID anlamına gelir. İki türlü karşımıza çıkar, Physical ve Logical. Bildiğim kadarıyla Physical RID disk bilgisini içerirken, Logical RID clustered index bilgisini içerir.

Heap : Bir tabloda eğer clustered index yoksa bu tabloya heap diyebiliriz. Bu tablolarda bir kaydı bulmanın tek yolu full table scan yapmaktır. Pek rastlanmaz ama, tablomuzda clustered index yok ama non-clustered index var diye düşünürsek, SQL her non-clustered index kullanımında table scan yapmaktansa, non-clustered index'in heap üzerindeki Physical RID ile eşleştirir. Bu non-clustered index key için kullanılacak olan satır bu disk alanındadır şeklinde bir işaretleme olarak düşünebiliriz bu durumu.

Clustered Index: Disk üzerinde fiziksel olarak tablodaki kayıtların sıralanmasını sağlayan index'tir, aslında tablonun kendisidir de diyebiliriz. Buradaki sıralamayı sağlayan alana cluster key diyebiliriz. Cluster key olabiliyorsa unique olmalıdır. Ancak bazı durumlar için bu şekilde bir yapı kullanılamayabilir. Non-Unique Clustered Index Kullanımı için buradaki yazımı okuyabilirsiniz. Clustered index ve non-clustered index barındıran tablolarda, non-clustered index'ler clustered index'lerin Logical RID bilgisini tutarlar. Heap durumunda bu Physical RID idi. Bu non-clustered index key için kullanılacak olan satır bu Logical RID ile eşleşen clustered index alanındadır diye bunu düşünebiliriz. Clustered index zaten bulunduğu disk bilgisine sahiptir ve bu şekilde uygun disk alanına ulaşılır. Clustered index eğer araya kayıt alırsa disk üzerinde belirli kaydırma işlemleri yapmak durumunda kalacaktır, bu kaydırma işlemlerini, clustered index disk bilgilerinin güncellenmesi olarak düşünebiliriz. Non-clustered index'ler disk alanı (Physical RID) ile değil, clustered index'in Logical RID bilgisi ile eşleştiği için, bu kaydırmalarda non-clustered index'ler etkilenmezler.
Heap kullanımında ise emin olmamakla beraber sanırım bütün yeni kayıtlar disk üzerindeki son tablo kaydının sonrasına aktarılır. Zaten kayıtlar için belirli bir sıra gerekmediğinden yeni kayıt, son kayıt ardına yazılır ve bir kaydırma işlemi olmaz. Yani ben yapsam böyle yapardım :)

Heap ve Clustered Index arasındaki bir fark da Read performansındadır. Clustered Index üzerinde kayıtlar sırayla bulunduğundan dolayı, Heap'e kıyasla 8 kat daha hızlı veri okunabilir. Bunu güzel ama eski bir yazıdan okumuştum, yeni SQL versiyonları ile bu değerler değişmiş olabilir. Kaynak.

Basit bir örnek vermeyi deneyeyim;
Can diye bir müşteri olsun ve bu müşterinin 1000 tane alış işlemi olsun, oldukça iyi bir müşteri :)
Alım işlemleri tablomuzda 20.000 işlem olsun, ve işlem numaramız bizim clustered key alanımız olsun. Örneğimizi basit tutmak için müşterilerin de isimle bu tabloda tutulduğunu varsayalım. 

Bu durumda 5 numaralı alım işlemini bulmak istediğimizde clustered index scan yaparak SQL olabilecek en hızlı şekilde bize kayıt bilgilerini dönecektir.

Can'ın işlemlerini bulmak istediğimizde, sistem tüm tabloyu tarayacak ve 20.000 kaydı inceledikten sonra bulduğu kayıtları işlem numarası ile eşleştirerek yukarıdaki senaryodaki gibi devam edecektir. 

Peki biz Can'ın isim bilgisinin olduğu alana bir non-clustered index eklersek ne olacak? Gene 20.000 kaydı incelemeyecek miyiz?

Cevap hayır, sebebi ise non-clustered index alanlarının sıralı olarak saklanıyor olması. Kabaca düşünürsek ismi C ile başlamayan kayıtların SQL'in incelemesine gerek kalmayacaktır. Gene kabaca düşünürsek; tabloyu tararken D harfine geldiğimizi varsaysak devam etmemize gerek kalmacayaktır.

Non-Unique Clustered Index Kullanımı

SQL server işleyişinde önerilen, clustered index'in olabiliyorsa unique olmasıdır. Peki eğer biz unique olmayan bir clustered index tanımlamayı seçersek neler olur. Bu durumda SQL tabloya yeni bir kolon daha ekler, bu kolona uniquifier denir ve 4 byte yer kaplar. Bu kolon tablodaki her satırda vardır ve clustered index'in aynı olabildiği durumlar için belirleyici görevi görür. Satırın belirleyici olmasında rol aldığı için, diğer non-clustered indexlerde de bu kolon vardır. Bu sebeplerden non-unique clustered index kullanımlarında ek bir disk alanı kullanımı olacağı unutulmamalıdır. Bu ek kolonun performansa da az da olsa etkisi olacaktır.

Non-Unique Clustered Index'leri belirli durumlarda kullanmanız gerekebilir, örneğin veritabanına bakım yapmama konusunda inatçı bir müşteri ile çalışıyorsanız :)

Tablolar için fragmantation çok önemlidir, ve önerilen durum clustered index'in artan değerler alması ve dolayısıyla yeni kaydın her zaman tablonun en alt kısmında yer almasıdır. Genellikle sorun yaşanan veritabanları eski ve bir çok yeni geliştirme geçirmiş, ilk tasarlanırken akla gelmeyen bir çok işi de yapar hale gelmiş veritabanlarıdır. Bu tür durumlarda performans çalışmalarında tablolarda kritik değişiklikler yapmak sistemin işleyişini tümden etkileyebilir. Örneğin, tüm sistemde unique'lik bir GUID ile sağlanıyorsa ve bu GUID sizin işlem tablolarınızda bir clustered index ise, aynı zamanda önceki örnekteki gibi bakım yapmayan bir müşteri ile karşı karşıyasanız, kısaca durum şudur: tabloda artık düzgün çalışan bir clustered index kalmamış demektir.

Bu tür durumlarda, GUID'i clustered index olmaktan çıkartarak unique index olarak eklemek uygun olabilir, clustered index olarak bir artan ID veya işlem zamanı kullanılabilir. Ancak farklı kayıtlar için, işlem zamanı -zor da olsa- sistemde aynı olabilir, aynı olmasa bile  SQL aynı olabilme ihtimaline karşı yukarıdaki uniquifier kolonunu tabloya eklemek zorunda kalacaktır.

Sonuç olarak her neredeyse tabloda bir clustered index olmalıdır ancak clustered index her zaman unique olmalıdır diye bir gereklilik yok, imkan varsa unique olması sisteme büyük performans sağlayacaktır. Bu bilgileri düşünerek non-unique clustered index kullanılabilir, veya kullanılmayabilir :)

SQL 2008 ve Date, Time Veri Tipleri

Time : SQL 2008 ile aramıza katılan bir veri tipi. Sadece saati veya sadece tarihi tutmak istediğimizde char kullanmak yerine bu tipleri kullanabilyoruz. Ancak Time 3-5 byte yer kaplıyor, eski dostumuz smalldatetime 4 byte, yani Time tipini kullanırken amacımız yerden kazanmak değil. 100 nanosaniyeye kadar hassas bir saat bilgisi tutabiliyor. Bu bilgiyi işletim sisteminden sorguluyormuş, ne kadar hassas bilgi alacağı biraz da işletim sistemine bağlı. Ancak bu kadar hassas saat bilgisi kolay kolay ihtiyaç duyulacak bir bilgi gibi gelmedi bana, belki bilimsel çalışmalarda önemli olabilir.

Date : Bu veri tipide SQL 2008 ile geldi. Gün bazında tarih bilgisini tutuyor ve 3 byte yer kaplıyor. char(8) olarak tutulan tarih bilgilerinin aslında bu şekilde tutulması hem yer kazanımı açısından hemde SQL'in tarih kıyaslamalarının hızlanması açısından faydalı olacaktır gibi geldi bana, ama sonuçta SQL bu, en iyisini bulmak için bolca denemek gerekiyor :)

Eski veritiplerinin yukarıdaki yeni tiplere nasıl çevrileceği konusunuda araştırmak gerekli.

MSDN sayfasına buradan ulaşabilirsiniz.

Temmuz 2009 Favorilerim

Garenth Emery - Exposure

Armin van Buuren vs. Cosmic Gate - FAV Rain (AvB Mashup)

Chephren Blake feat. Meighan Nealon - Year After

Cressida - Onyric (Stoneface & Terminal Remix)

Michael Jackson - Stranger In Moscow (Jerome Isma-Ae Bootleg)

Three Drives – Automatic City

Enrique Iglesias feat. Ciara – Taking Back My Love (Robert Burian dubleg)

Rank 1 – Symfo

M6 – Opus Sectrum

22 Haziran Trafiği

Yazmadan edemeyeceğim, 07:45'de bindiğim servisimden 11:25'de indim. Yorum ve espri yapma gereği duymuyorum...

Richard Duran'dan Albüm : Always The Sun

Mayıs başında Richard Duran tarafından çıkarılmış olan bir albümdür. İnternetten indirmek dışında pek bir edinme şansınız yok sanırım. Ülkemizde satılan yer bulursanız bana da söyleyin :)

edit: İngiltere'den toplam £11.93 karşılığında sipariş verdim, 5 günde elime geçti.

Parça listesi şu şekilde...

01. divine
02. always the sun
03. papillon
04. into something
05. ancient garden
06. no way home
07. the cube
08. slow geisha
09. city never sleeps
10. mouseville
11. silver key
12. the trigger
13. chaos
14. dr. gorgo
15. no way home (unplugged bonus track)

always the sun, into something, ancient garden, chaos, the cube, no way home benim favorilerim. dr. gorgo'da sonlara doğru sağlam bir ritim yakalıyor. slow geisha bir şarkıya benziyor ama çıkartamadım...

Albüm genel olarak başarılı bence, tavsiye ederim.

Saga Of The Seven Suns

Bu kitap serisi ile tanışmam sanırım 2007 yılında Remzi Kitabevi'nde öylesine bilim kurgu kitaplarına bakarken olmuştu. İlgimi çeken bir kitabı inceledikten sonra, bunun bir seri olduğunu farkettim ve serinin ilk kitabını aramaya başladım. Biraz zorlu da olsa kitabı buldum, okumaya başladım, o kadar sardı ki, hemen diğer üç kitabını daha aramaya başladım, pek kolay değil bulunmaları. Remzi'de serinin ilk dört kitabı mevcut. Ancak aynı anda bulmanız çok zor, isterseniz farklı şubelerinden sizin için kitapları getirebiliyorlar. Seri aslında yedi kitaptan oluşuyor. Tamamına merak sararsanız ebay.co.uk'yi size öneririm, yaklaşık 6-10 gün arası kitap elinizde oluyor. Ansiklopedi gibi kocaman bir kitap istemiyorsanız Pocket Books olarak yayıncıyı seçmenizde fayda var :)

İncelemek isterseniz kitaplar şu şekilde;

• Book 1: Hidden Empire (2002)
• Book 2: A Forest of Stars (2003)
• Book 3: Horizon Storms (2004)
• Book 4: Scattered Suns (2005)
• Book 5: Of Fire And Night (2006)
• Book 6: Metal Swarm (2007)
• Book 7: The Ashes of Worlds (2008)

http://en.wikipedia.org/wiki/Saga_of_Seven_Suns

Bu kitaplardan önce ben yazarı olan Kevin J. Anderson'ı hiç tanımıyordum, Dune serisinde yazmış sanırım geçmişte ama haberim yoktu. Saga'ya gelirsek, okuduğum en harika romanlardan birisi diyebilirim. Şu anda altıncı romandayım, bitirmek içinde acele etmiyorum :)

Bana göre romanların en büyük özelliği karakter zenginliği ve bu karakterlerin nasıl bir araya geldikleri. Özellikle ilk karakterler hiç beklenmedik şekillerde aramızdan ayrılabiliyorlar.

Temel olarak galaksimizde bizden başka ırklar var. Farklı ırklarla beraber yaşamaları sonucu değişen, farklı insan ırkları da mevcut. İnsanlar lldiran stardrive ile yüksek hızlarda uzayda seyredebiliyorlar.

Bu teknolojiyi bize hediye eden ırk, fiziksel olarak insanlara biraz benzeyen ama farklı bir kültüre sahip olan lldiran ırkı. lldiran'lar bilimsel gelişmelerini uzun yıllar önce tamamladıklarına inanıyorlar, yeterli rahatlığa ve yaşamsal kaliteye eriştiklerini düşünüyorlar, dahasını aramıyorlar. Geleneklerine çok bağlılar, yedi rakamı onlar için herşey demek. Bunun sebebi ana gezegenleri olan Mijistra'nın yedi güneş görüyor olması. Askeri birimlerinden tutun, sarayın etrafındaki yukarı doğru akan nehir sayısına kadar herşeyde yedi rakamı var. Gemileri ve askerleri yedişer olarak gruplanır. Başlarında Mage-Imperator vardır. Mage-Imperator Thism sayesinde tüm lldiran'ları yönetir. Thism ile tüm lldiran'lar aslında birbirlerine bağlıdırlar. Mage-Imperator ise, thism bağlarını oluşturan soul-thread'leri kontrol eder. Çok uzaklarda dahi olsa diğer lldiran'ları sezebilir, hissettiklerini hissedebilir. Ancak thism asla bir telink gibi anlık iletişime izin vermez.

lldiran'lar karanlıktan ve yalnızlıktan çok korkarlar, onlar için en büyük korku bunlardır, en büyük ceza da bunlardır, ancak bir lldiran diğerini asla yalnız bırakmak gibi bir ceza veremez, bunu aklına dahi getirmek istemez, düşmanına bile yapmaz. lldiran'lar thism ile yanlarında veya yakınlarınki diğer lldiran'ları hissedebilirler, Mage-Imperator'larını da hissedebilirler. Ne kadar çok lldiran bir arada olursa thism o kadar kuvvetli olur ve Mage-Imperator'da onları o kadar güçlü sezebilir. Mage-Imperator, kendi soyundan gelenleri çok daha iyi sezer, hisseder. Yaşadıklarını anlayabilir ama onlara mesaj iletemez.

lldiran'lar kith lere ayrılmıştır, savaşçı, soylu, hizmetkar, hatırlayıcı, işçi vs. Bu kithlerin bir veya iki harflik kısaltmaları vardır. Her lldiran isminin sonunda bu bilgiyi taşır. Örneğin, Mage-Imperator Jora'h, 'h soylu kith demek, bu kişiler Mage-Imperator olabilir, designate denilen gezegenleri yöneten kişiler olabilir. 'n ise asker demektir, ismi 'n ile bitenler askerlik yaparken, ismi 'nh ile bitenler soylu ve asker olan iki kişinin çocuğudur ve bu kişiler askeri liderlerdir.

Adar, lldiran askeri yönetiminin en üstündeki kişidir. Mage-Imperator'un çocuklarından biridir. Mage-Imperator'un ilk soylu çocuğu prime designate olur. Prime designate, Mage-Imperator öldükten sonra onun yerini alacaktır. Prime designate'in görevlerinden biri, özenle seçilen çeşitli kithlerden kişilerle ilişkiye girmektir, bu ilişkilerden doğan çocuklar ileride o kithlerin yöneticileri olacaklardır, veya ileriki designateler hatta prime designateler olacaklardır.

lldiran'lar için yaşananları uygun bir şekilde kaydetmek çok önemlidir. Hatırlayıcı kithler lldiran geçmişini ezbere bilirler, işte bu geçmişte saga of the seven suns adı altında kaydedilir.

lldiran'ların yanında, verdani'yi anlatmak gerekiyor. Verdani telink sayesinde anında birbirleriyle iletişim kurabilen bitkisel bir ırk diyelim kısaca. Sınırsız bilgi depolama yetenekleri var, aklınıza gelebilecek tüm bilgileri depolamak istiyorlar. Worldtree olarak bilinen ağaçlardan oluşuyorlar, bu ağaçlar aslında tek bir birey gibi, Theroc adındaki bir gezende yaşıyorlar, ilerleyen zamanlarda görüyoruzki sadece yaşadıkları yerler buralar ile sınırlı değil. Romanın ilerki kısımlarını buraya yazarak okuma hevesi olan insanların heyecanını azaltmak istemiyorum :)

Verdani ile beraber Theroc üzerinde yaşayan insanlar da var. Bu insanlar zamanla worldtree'ler ile iletişime geçmenin yolunu buluyorlar ve ağaçlara tüm bildiklerini anlatmaya başlıyorlar, Verdani zaten bilgiye aç olduğu için bu onları çok mutlu ediyor. Kendilerine bu şekilde hizmet eden insanları ödüllendiriyorlar, onları bir çeşit değişime tabi tutarak Green Priest olmalarını sağlıyorlar. Green priest'ler Verdani'ye dokundukları zaman, istedikleri bilgiye erişebiliyorlar ve zihinlerini açarak konuşma hızından çok hızlı, düşünme hızı ile tüm istediklerini bir anda Verdani hafızasına boşaltabiliyorlar veya tam tersi istedikleri bilgiye erişebiliyorlar. Tabi bilgiyi öğrenmek anlatmaktan çok daha uzun zaman alıyor. Bunun yanında ufak bir Worldtree'yi saksı içerisinde yanlarında taşırlarsa istedikleri anda Verdani zihni veya bu zihne bağlı diğer green priest'ler ile telink aracılığı ile mesafeden bağımsız bir şekilde anlık iletişim kurabiliyorlar. Green priestlerin değişimi sadece telink erişiminden ibaret değil, bedensel olarak açık yeşil bir renge dönüyorlari güneş ışığı ile kendilerini besleyebiliyorlar. Güneş ışığı altında kalmayı tercih ediyorlar.

Theroc üzerinde Verdani ve green priestler uyumlu bir şekilde yaşıyorlar. Dışarıya ihtiyacı olmayan, kendi kendisine yetebilen bir gezegen Theroc. Üzerinde kocaman Worldtree'lerden oluşan Worldforest'ları var, kitapta anlatıldığı kadarıyla tam bir cennet. Ağaçlarla dans eden insanlar, büyük hayvanların kozalarından yapılmış evler, çok azı tehlikeli olan onca egzotik hayvan...

Theroc üzerindeki her insan green priest değil. Sadece isteyen ve hak edenler green priest oluyor, geri kalanlar ise normal insanlar. Mother of Theroc ve Father of Theroc adı altında iki yönetici tarafından yönetiliyorlar, Theroc'da yaşayanlara kısada Theron deniliyor. Theroc bir zamanlar Hansa'ya bağlı iken uzun zaman önce özgürlüğünü almış bir gezegen artık. Hansa nedir? az sonra :)

Verdani, düşmanlarından korunmak, bilgi dağarcığını geliştirmek amacıyla, green priestlerin galaksiye dağılmalarını ve yeni yerleşim yerlerine Worldtree'leri ekmelerini, orada olup bitenleri aktararak zamanla o gezegende de bir worldforest oluşturmalarını istiyor. Theroc'tan ayrılmaya razı olan green priestlerde bu isteğe uyuyorlar. lldiran ve Verdani arasında belirli bir ilişki yok diyebiliriz, lldiran'ların pek ilgisini çekmiyor Verdani.

Hansa yani "The Terran Hanseatic League", insanların kurduğu ve insanların yaşadığı çoğu gezegeni kendine bağlayan bir kurum. Bir kralı var, birde chairman var. Kral bir kukla ve işleri yöneten kişi aslında chairman. Bu yönetim şekli bence günümüzün yönetim şekillerine de sağlam bir gönderme yapıyor.

Aslında hikayeyi başlatan, onbir generation ship'in dünyadan uzaya gönderilmesidir. Kalabalıklaşan dünyadan, yeni düyalar bulma ümidiyle ayrılan, hızlı lldiran stardrive'ı olmayan bu gemiler yavaş yavaş, nesiller boyu uzayda ilerlemişlerdir. Tüm gemiler yola çıkmadan önce Hansa'ya bağlılık yemini etmişlerdir. Bu gemiler gelişmiş dönüşüm sistemleri ile yüzyıllarca yol almışlardır. Sonunda bazıları bir yerler ulaşmış bazılarından ise haber alınamamıştır. Örneğin Theron'lar beşinci gemi olan Caillié ile Theroc'a ulaşmışlardır.

Roamer'lar ise Kanaka adlı son gemi ile yola çıkmışlardır, tabi yola çıkarken onlarda sadece insandı. Hikayede Roamer'lar çok önemli bir yer kaplarlar. Çok zorlu yaşam şartlarından gelmeleri sebebi ile çok zeki ve basit çözümler üreten bir ırktır. Tamamen insandır. Ticaret ile uğraşırlar, Hansa ile pek iyi geçinemezler, zaten Hansa'ya bağlı kalma eğilimleri yoktur. lldiran stardrive için gerekli olan ekti adı verilen bir yakıtı gas giant denilen gezegenlerden, zorlu ama zekice yöntemler ile elde ederler. Bu yakıtı EDF (Earth Defense Forces), lldiran'lar gibi yerlere satarlar. Gizliliklerine çok önem verirler, kimse bunların nerede olduklarını bulamaz, onlar ihtiyaç duyduklarında sizi bulur. Klanlara ayrılmışlardır, aile soyadı genelde klan adıdır, klanlar birbirleri ile savaşmazlar, tam tersi birbirlerine destek olurlar. Hansa insanları Roamer'ları aşağılık, basit, cahil ve tiskinç insanlar olarak bilirler, ikinci sınıf insan olarak görürler ve her seferinde de yanılırlar. Başlarında Speaker dedikleri biri vardır. Yanılmıyorsam Speaker kendisinin yerine geçecek olan kişiyi kendi seçer ve yıllarca yanında eğitir.

11 generation ship'ten çoğu lldiran'lar tarafından bulunmuştur. Daha sonra insanlar ve lldiran'lar iletişime geçmişlerdir. lldiran'ların bu gemilere ve insanlara hediyesi olan stardrive ile insanlar her yere el atmaya başlamışlardır.

Hydrogues, Faeros, Wentals, Klikiss, Black Robots gibi hikayede çok önemli yeri olan ve insanlardan tamamen ayrı olan ırklarda vardır. Bunları şimdi detaylandırmak demek hikayeyi anlatmak demek, bu yüzden bu ırklara değinmiyorum.

Bu harika serinin tanıtım özeti bu şekildedir...

Haziran 2009 Favorilerim

Rex Mundi feat. Susana - Nothing At All (Beat Service Juicy Remix)
Richard Durand - Ancient Garden
Richard Durand - Always The Sun
Richard Durand - Into Something
Gaia - Tuvan
Fabio XB & Ronnie Play feat. Gabriel Cage - Inside Of You (Cosmic Gate Remix)
Josh Gabriel pres. Winter Kills - Deep Down
Marco V - Unprepared (Full Prepared Mix)
The Killers - Spaceman (Sander van Doorn Remix Part 2)
Alex M.O.R.P.H. feat. Ana Criado - Sunset Boulevard
Ronski Speed - Are You? (Sun Decade Dub)
Airbase - Back
John O'Callaghan feat. Lo-Fi Sugar - Never Fade Away
John O'Callaghan feat. Lo-Fi Sugar - Never Fade Away (Andy Duguid Remix)
Temple One - String Theory Original / (M6 Remix)
Armin van Buuren feat. Jacquline Goavert - Never Say Never (Alex Gaudino Remix)
R.E.N.O.I.S.E. - Dead Wishes
tyDi feat. Audrey Gallagher - You Walk Away
Purple Haze - Bliksem
Ben Nicky - Special Moment (Steve Allen Remix)
Lolo - Trampoline
Alex M.O.R.P.H. feat. Ana Criado - Sunset Boulevard (Ilya Malyuev Sunset Remix)
Misja Helsloot vs. Onova - Mel-Ody

Mayıs 2009 Favorilerim

Fabio XB & Andrea Mazza - Light To Lies (Gareth Emery Remix)
tyDi & Dennis Sheperd feat. Marcie - Somehow
Above & Beyond pres. OceanLab - Lonely Girl (Gareth Emery Remix)
John O'Callaghan feat. Sarah Howells - Find Yourself (Cosmic Gate Remix)
Moonbeam feat. Avis Vox - About You
Armin van Buuren feat. Cathy Burton vs. Cosmic Gate - F.A.V. Rain (Armin van Buuren Mashup)
Dakota - Chinook (Uplifting Mix)
Ohmna feat. Nurlaila - Key Of Life (Marlo Remix)
Rex Mundi feat. Susana - Nothing At All
Chicane Ft Tom Jones - Stoned In Love
Sasha Virus feat. Dilara - 2gether We Are (Sindre Eide Remix)

İstanbuldere Alabalık Evi

4 Nisan cumartesi günü Lale Otel'e giriş yaptıktan sonra, kendilerine çevrede doğa olarak güzel ne olduğunu sorduğumuzda bize ilk olarak burayı önerdiler.

Bizde tavsiyelerini dinleyerek İstanbuldere'ye gittik. Tüm yol boyunca benzer yerlerin reklam panoları ile karşılaştık, tamamına yakını, aile yeridir, alkolsüzdür gibi özelliklerini gözümüze sokunca İstanbuldere daha da ilgimizi çekti.

İki tarafından dere akan harika bir yerle karşılaştık. Sadece alabalık vardır diye düşünürken zengin menüleri ile karşılaştık. Sorduğumda kışında çok gelen olduğunu söylediler, sadece iç kısımda oturulabiliyormuş, tesis bel boyu kar altında oluyormuş ama geleni eksik olmuyormuş.

Akşama doğru hava serinleyince derenin yanındaki masamızda biraz üşüdük, ufak ufak sıcak otelin çekiciliğine kapıldık.

Tek sorunu hesap öderken yaşadık, kafalarına göre yazdıkları bolca meze vardı, belirli mezelerin fiyatları menüde belirtilmemesine rağmen farklıydı. Bunlar bir yana, o vakte kadar sürekli güleryüzlü olan garsonumuz bakın fazla yazmışsınız, yanlış toplamışsınız dediğimizde hiç oralı dahi olmadı. Yaklaşık 10-15 TL için normalde bu kadar söylenen kişiler değiliz, ama bu adamlar kadar yüzsüz kazık atmaya çalışan kişilerle ilk defa karşılaştık. Kasaya gittik orada rahatsızlığımızı dile getirdik, oradaki kişiler daha samimi şekilde ilgilendiler, en azından suratlarında bir pişmanlık vardı, pişkinlik değil, mırın kırın ettiler, ellerinde menu ve hesap makinası ile asla ödediğimiz fiyata ulaşamadılar. Sonunda içlerinden biri fazla olan kısmı geri ödemeyide teklif etti. Tüm bunları geçtim ama bir kişi bile özür dilemedi, kusura bakmayın demedi. Ayıp ettiniz dedik ve oradan ayrıldık.

Fırsatım olursa buraya tekrar gideceğim ama hesabı detaylıca incelemeden asla ödemeyeceğim.

http://www.istanbuldere.net/

sözlük

Club Lale Otel

İstanbul'a yaklaşık 2 saat mesafedeki bir otel. Sapanca Gölü kıyısında hoş manzarası olan bir yer. Göl manzaralı olan toplam sekiz odası bulunduğu için önceden -on onbeş gün- rezervasyon yapılması gerekiyor. Göl kıyısında çim kaplı bir bahçesi var, burada yemek yemek, hamakta uzanmak, cesaret edebilirseniz göle girmek mümkün :)

İki kişilik oda fiyatı 210 TL idi. Sanırım 10 oda civarı doluydu, veya biz o kadarına denk geldik. Yemekleri fena değildi, çok fazla çeşit yoktu ama zaten oraya gitme amacınız harika bir açık büfe değil. Hava soğuk olduğundan otelin içerisindeki yemek salonunda yemek yedik. Bu salonun yanında dışarı çıkarak geçilebilen bir restoran var, burası otelde kalmayan kişilerinde gelebilmesi için yapılmış, şöminesi vardı ama yanmıyordu. Restoranda denize sıfır 5 6 masa var, akşamları oldukça değerli oluyor bu masalar. Yemekten sonra bir şeyler içmek için restorana geçtik. Rezerve yazmasına rağmen bize yardımcı oldular. 2 kadeh kırmızı şarap ve bir soda için 20 TL ödedik, fiyatlar ortama göre gayet uygundu ve hiç rahatsız etmedi bizi. Birde odada su içmiştik 231 TL ile Lale Otel'den ayrıldık.

Bahçesinde iki tane de köpek vardı, kafeslerin içinde olduklarını görünce gittik biraz mıncıkladık, zaten pek şımardılar, sevgiye hasret tüy yumakları.

Yoğun trafik zamanında İstanbul'un bir yakasından diğer yakasına geçilebilen sürede gidilebilen bir yer Lale Otel, havalar biraz ısındığında göl kıyısındaki bahçesi gerçekten çok cazip olacaktır. Etrafıda bolca gezerek yaklaşık 100 TL'lik benzin ile bu haftasonunu tamamladık.

Otelden çıkınca ne yapabilirsiniz onlarıda şu şekilde özetleyelim,

• Yaklaşık 50 mt yanında karting imkanı var
• İstanbuldere
• Kartepe

Kartingi yapmadık, içimizde kalmadı değil :)