Category Archives: SQL SERVER

SQL SERVER 2005 ‘DE FILLFACTOR KAVRAMI

Posted by Ä°brahim DEMÄ°R on 18/07/2007 No comments

sqlserver.jpgBlogumdaki SQL Server 2005 ile ilgili önceki yazılarımda SQL Server Storage Engine ‘in biraz sorunlu olduÄŸundan bahsetmiÅŸtim. Hal böyle olunca verilerimizi SQL Server üzerinde tutarken daha da dikkatli olmamız gerekiyor. Ben de bu konuda dikkat etmeniz gereken noktalardan bir kaçına deÄŸinmeye karar verdim.

SQL Server verileri diskten EXTENT dediğimiz formatta okur ve yazar . (the smallest unit of data that SQL Server can allocate is 64 KB) Extent ise bünyesinde 8 tane Page barındırır. Windows işletim sistemi ortamında 8*Page_Size=64K eder (İşletim Sistemleri dersini alan arkdaşların kulaklarını da çınlatmış olduk) ki bu da diskten bir defada okunabilecek veri boyutuna denk gelir.

Fillfactor kavramı ise verilerin page üzerinde ne kadarlık bir alanı kaplayacağını belirler. Yani veritabanı yönetim sisteminiz bir page ‘in ne kadarlık kısmını (yüzde olarak 1..100 aralığında) dolduracak ne kadarlık kısmını boÅŸ bırakacak bunu belirleyen parametredir. Fillfactor deÄŸeri index oluÅŸturulurken veya rebuild edilirken karar verilen bir deÄŸerdir. Mesela indeks oluÅŸtururken 70 ‘lik bir fillfactor deÄŸeri belirlediÄŸinizde page üzerinde yüzde 30 ‘luk bir alan sonradan eklenecek veriler için ayrılmış olacaktır. Burada dikkat edilmesi gereken en önemli nokta fillfactor deÄŸerini 100 vermek ile 0 (sıfır) vermek arasında bir fark olmadığıdır. Fillfactor deÄŸerleri 1-100 arasındadır o nedenle 0(sıfır) verdiÄŸinizde bu 100 olarak kabul edilir ve tüm page doldurulur.

Gelelim bu kavramların önemine: EÄŸer veritabanınızdaki okuma sayısı fazla ise bu deÄŸerin yüksek olması çok önemli yani 100 seviyesinde olması en ideali (Zaten server bazında default deÄŸer 100 ) ama okuma iÅŸlemlerinin yanı sıra sıklıkla veri ekleme ve güncelleme (yazma) da yapıyorsanız böyle zamanlarda PAGE SPLIT dediÄŸimiz vakit kaybettirici bir durumla karşılaÅŸmanıza neden olabilir.(Elbette kaybettiÄŸiniz vakti anlamanız o kadar kolay deÄŸil) Nasıl ki multi-threading yapabilen bir iÅŸletim sistemi CPU ‘da processleri çalıştırırken context-switching yapıyorsa (Ä°ÅŸletim Sistemleri dersini alan arkadaÅŸların kulaklarını bir kez daha  çınlatmış oldum) aynı durum veriler okunurken ve yazılarken de geçerli. Tam dolu bir page’de sorgulama yaptığınızda aradığın verinin o page içerisinde olma olasılığı daha fazla olur. Öte yandan tam dolu bir page ‘e yazmaya kaltığınızda dolu olduÄŸu için diÄŸer page ‘e geçilir (Page Split) ve page split iÅŸlemi sırasındaki hesaplamalar vakit kaybına neden olur.

Tablolarınızın fillfactor bilgilerini incelemek için SQL Server üzerinde dbcc showcontig komutundan faydalanabilirsiniz. Aşağıdaki örnekte Northwind veritabanınki Categories tablosuna ait bilgiler çağırılmıştır:

use Northwind
go
dbcc showcontig (Categories) with tableresults  (tableresults parametresi seçimliktir)

*Pages Scanned:1 Extent ‘i aşıyor mu aÅŸmıyor mu görmenizi saÄŸlar
*Extent Switches: 1 ise switch var demektir (tehlikeli bir durum :) )
*Scan Density: Düşükse indeksleri yeniden oluşturmak faydalı olabilir (ALTER INDEX REBUILD )
*Avg Page Density: Bu bilgi aracılığıyla pagelerin doluluk oranları hakında bilgi sahibi olabilirsiniz.

Fill factor kullanarak index oluşturmak isterseniz de aşağıdaki örnek size yol gösterebilir:

CREATE CLUSTERED INDEX deneme_indx ON my_table (col1, col2) WITH FILLFACTOR = 50 

Yazımı bitirmeden evvel neden bu konuyu bloguma taşığıma da deÄŸineyim. JDBC_TR mail grubumuzda arkadaşım Emrah Åžeker yapacağı proje için performanslı bir DBMS arayışına girmiÅŸti ve ona cevap verirken Flickr ‘ın altyapısını anlatan bir sunumda bahsi geçen yazma ve okuma deÄŸerlerinin oranına deÄŸindim. (Kullanıcılar her 14 okumya (select) karşılık 1 yazma (insert,delete,update) yapılıyorlarmış) Yani aldığınız bir DBMS ‘i default deÄŸerlerle kullanmak her zaman akıllıca olmuyor. Ä°ÅŸinizi ve kullanıcılarınızı iyi analiz etmek gerekir diye düşünüyorum. Yine aynı ÅŸekilde perfomans sorunlarını çözerken olayları donanım güncellemeleri ile ölçeklemeye kalkmak her zaman beklenen sonuçları doÄŸurmayacaktır. Diyorsanız ki kim bu kadar detaylı ÅŸeylere dikkat ediyor? Ben de diyorum ki Dikkat Eden Kazanır!

Åžimdilik benden bu kadar saÄŸlıcakla kalın…

-Tavsiye-
Who Cares about FillFactor?
SQL Server 2005 Books On-Line
Understanding SQL Server’s DBCC SHOWCONTIGÂ

NOT: Yukarıda bahsi geçen konu diÄŸer DBMS ‘leri kapsayacağı gibi kapsamaya da bilir. O nedenle bu yazıyı sadece bilgi sahibi olduÄŸum SQL Server ‘i örnekleyerek yazdım.

PROJE KABUSU SÃœRÃœYOR

Posted by Ä°brahim DEMÄ°R on 02/06/2007 12 comments

proje-kabusu.pngGeçen hafta cuma günü başlayan proje kabusum hala sürüyor. Aksilikler, sorunlar bir türlü yakamı bırakmadı. Tüm bu sorunlardan kurtulup rahata ereceğim zamanda yenileri katılıyor aramıza. Ama yaşanan bu sorunlardan da kendime çok ders çıkardım.
(Keşke başka türlü çıkarsaydım o dersleri)

Önceki hafta bilgisayarları kapıp hocamızın asistanına bitirme projemizin son halini göstermeye gittik. Projeyi iki kiÅŸi yaptığımız için CETURK ‘ün kurucu Mehmet ACA bize database hosting saÄŸladı. Aynı database üzerinde çalışmak hem senkronizasyon hem de tablolara veri girme derdinden bizi kurtaracaktı. Fakat okula gidince bunun böyle olmadığını gördük. (Çok geç oldu ama neyse) Okuldaki internet çıkışı üzerinden bizim verilerimizin bulunduÄŸu hosta eriÅŸilemiyormuÅŸ. “muÅŸ” dedim çünkü bu problemi Mehmet ‘e anlatınca “ Evet abi doÄŸru bizim okuldan ne yaptıysam ben de eriÅŸememiÅŸtim ” dedi. (Eeee be adam ÅŸunu baÅŸtan söylesene)

Åžimdi aklınıza “Neden bu veritabanın aynısını kendi bilgisayarında oluÅŸturmadın?” gibi bir soru gelir. Elbette oluÅŸturdum. Fakat remote hostta bulunan verileri kendi bilgisayarıma transfer ederken oradaki schema ile aynı schema ismine taşımışım. (Ben de o schema tanımlı olmamasına raÄŸmen) SaÄŸolsun SQL Server Management Studio bu konuda beni hiç uyarmadı.

Verileri kendi bilgisayarıma aktardıktan sonra bu defa da yeni gelen schema üzerinden tablolara eriÅŸemedim. Güvenlik gerekçesiyle izin verilmeyen bu duruma kendimce remote hosttaki kullanıcının aynısını yerel sunucumda da tanımlayarak çözüm bulmak istedim ama nafile. (Microsoft benden uyanık çıktı anlayacağınız…) Bundan ötürü o gün nasılsa veriler remote hostta var ve okulda da internet baÄŸlantısı var diyerek evden çıktım.

Okulda veritabanına eriÅŸemediÄŸimizden dolayı projenin çalışır halini gösteremediÄŸimiz için bu cuma bir kere daha gittik. (Yani dün) Verileri kendi bilgisayarıma bu defa aktarmıştım. (En azından aktardım sanıyordum) Fakat bu defa da tablolardaki constraint ‘ler aktarılmamıştı ve bundan ötürü çoÄŸu veri ekleme iÅŸleminde hata oldu. Anlayacağınız rezillik dizboyuydu. Artık asistana bahane sunacak halim kalmamıştı.

Öte yandan proje arkadaşımın bilgisarındaki virüs yüzünden tüm gece boyunca yazdığı kodları Visual Studio kaydedememişti ve yaptığı değişiklikleri gösteremedik. (Muhtemelen şu anda bilgisayarını geri yüklemekle meşgüldür)

Bir de bütün bu olanların üstüne hocamızın asistanı benden saçma sapan şeyler isteyince (Burada şu da olsa burada bu da olsa şeklinde) bu haftasonumu da projeye feda etmek zorunda kaldım.

Tüm bunları yazmamın nedeni ise bloguma bir müddet yeni yazı ekleyemeyeceÄŸim için ÅŸimdiden özür dilemek ve kendimi az da olsa haklı göstermek. Fakat proje sonlanınca (Yani 8 haziranda) hem proje sırasında öğrendiklerimi (SQL server ve proje gerçekleÅŸtirme sanatı ile ilgili) hem de Arden AGOPYAN tarafından davet edildiÄŸim BiliÅŸim Kongresi ‘nden izlenimlerimi paylaÅŸacağım. Åžimdilik benden bu kadar. Bir sonraki yazıya kadar saÄŸlıcakla kalın…

SQL SERVER 2005 DATABASE DIAGRAM SORUNSALI

Posted by Ä°brahim DEMÄ°R on 09/05/2007 No comments

İzmir tatilimin sona ermesiyle uzun zamandan beri açıklık getirmeyi düşünüp durduğum bir konuyu da bloguma taşıyorum.
SQL SERVER 2005 DATABASE DIAGRAM HATASI konulu yazımdan sonra beklemediğim sayıda e-mail aldım. Sanırım arama motorlarında aşağıdaki cümleyi arayanlar blogumu karşılarında buldular:

DATABASE DIAGRAM SUPPORT CAN NOT BE INSTALLED BECAUSE THIS DATABASE DOES NOT HAVE A VALID OWNER. TO CONTINUE FIRST USE FILE PAGES OF THE DATABASE DIALOG BOX OR USE ALTER AUTHORIZATION STATEMENT TO SET THE DATABASE OWNER TO A VALID LOGIN….

Ben önceki yazımda bunun kullandığınız veritabanının Compatibility Level ‘i ile alakalı olduÄŸunu ve ayarlardan 90 seviyesine getirilmesini söylemiÅŸtim. Bu sayede SQL Server ‘ın 2005 sürümüyle birlikte görsel yönden daha da iyileÅŸtirilmiÅŸ olan yeni diyagramlardan faydalanabilecektiniz. Fakat o yazıdaki çözüm bazıları için geçerli olmadı. EÄŸer o çözüm ile bir sonuç alamadıysanız ve zaten uyumluluk seviyeniz 90 ise o zaman hata mesajını dikkate almakta fayda var. Database için bizden geçerli bir OWNER atamamızı istiyor. Sakın ola ben bu database ‘i kendim oluÅŸturdum , zaten owner da benim gibi hayallere kapılmayın ve iÅŸinizi saÄŸlama alın. Bunun için:

ALTER AUTHORIZATION ON DATABASE::MyDatabaseName TO [MyServerName\Administrator];
 komutunu çalıştıırmanız yeterli olacaktır.

Umarım bu yazı ile bu sorun burada kapanır ve herkes hayalindaki veritabanı diyagramına kavuşur. Gerçi bu diyagramlar için kullanabileceğiniz pek çok ücretsiz araç da mevcut ama tablolar arasında tasarımla oluşturduğunuz ilişkileri arka tarafta veritabanına yansıtanlar var mı onu bilemiyorum.

Ä°stanbul ‘a geri döndüğüme göre blogumu da eski hızımda güncellemeye devam edeceÄŸim. Åžimdilik benden bu kadar. SaÄŸlıcakla kalın…

SQL SERVER 2005: MASTER.MDF IS COMPRESSED

Posted by Ä°brahim DEMÄ°R on 01/04/2007 3 comments

sqlhata.jpg Bir süredir SQL Server 2005 maceralarımı yazmıyordum. Bu zaman sürecinde çok fazla malzeme birikti :) Bunlardan birini blogumda paylaşmak istedim. Cumartesi sabah projeme ait veritabanını bulunduğu sunucudan kendi makinama aktarmak için SQL Server servisini başlatmak istedim fakat ne mümkün. Servisin time-out süresini doldurduğunu ve başlatılamadığını söyleyen hoş bir hata mesajı (artık alıştım ben bu hata mesajlarına ondan dolayı HOŞ dedim).

Ben bu hata mesajını daha önce de almıştım. Hatta o zaman sorunu çözmeye üşenmiÅŸ ve bir gece öcde aldığım sistem yedeÄŸimi geri yükleyerek çalışmaya devam etmiÅŸtim. Bu defa sorunu çözeyim delikanlı gibi dedim ve neler olup bittiÄŸini nasıl anlarım diye düşünürken APPLICATION LOG ‘larına bakmayı akıl ettim. Eventvwr.msc komutuyla açtığım Event Viever üzerinden Application sekmesine gelince gördüğüm hata iÅŸaretleri ve yanında yazan MSSQL$SQL2005 yazısını görünce doÄŸru yolda olduÄŸumu anladım. Öyle de oldu ve resimde gördüğünüz (lütfen tıklayınız) ekran karşıma çıktı.

Burada master.mdf dosyasının sıkıştırılmış olduğunu ve decompress edilmesi gerektiği yazıyordu. İyi hoş ama ben bu dosyanın bulunduğu dizinde sıkıştırma uygulamamıştım ki. Hatta işletimim sistemimin kurulu olduğu disk bölmesinde herhangi bir disk sıkıştırması uygulamıyordum. Yeri gelmişken söyleyeyim; NTFS dosya sistemi ile hayatımıza giren disk sıkıştırma olayı disk alanı açısından bizlere kazanç sağlarken okuma-yazma performansı açısından olumsuz sonuçlar doğurabiliyor. Bu nedenden ötürü işletim sisteminizin bulunduğu disk bölümünde sıkıştırma uygulamanızı önermiyorum.

Konuya dönecek olursak SQL Server 2005 master.mdf (SQL Server ‘ın hayati veritabanı dosyasıdır ve mutlaka yedeklenmelidir) dosyasını sıkıştırmıştı. Gidip dosya özelliklerinden sıkıştırma iÅŸlemini iptal edince SQL Server hayat döndü ve servis rahatlıkla baÅŸladı.

Bir kaç kere daha bahsetmiÅŸtim hatta Microsoft yetkilileri de bunu kabul etmiÅŸtir ki SQL Server 2005 ‘in Stroge Engine ‘i malesef biraz pürüzlü. Büyüyen dosya boyutlarına çare olarak disk sıkıştırması kullanan sevgili RDBMS ‘im malesef kendi sıkıştırdığı dosyayı açamamıştır.

SQL Server 2005 maceralarımı burada paylaÅŸmaya devam edeceÄŸim. Çok güzel ve çok özel hata mesajları yakaladım sizin için. Beni okumaya devam edin…