Mustafa Acungil

Yeni adresim

2010-12-24T05:44:00.001-08:00

Merhaba arkadaşlar

SQL ve Microsoft iş zekası alanlarındaki yazılarımı artık https://acungilsqlbi.wordpress.com/ adresindeki günlüğümden takip edebilirsiniz. Buradaki yazıları ve yorumlarınızı da aktardım oraya. Yeni yazılarıma orada devam edeceğim.

Siz değerli izleyicileriminse yeni bloguma abone olmanızı tavsiye ederim.

PerformancePoint'te KPI tipleri

2010-12-15T04:56:00.000-08:00

PerformancePoint uygulaması yaparken KPI tiplerini iyi anlamak önemli. Özellikle Scorecard'larda KPI'ları hiyerarşik görüntülerken bu tipler önem kazanıyor.

3 temel tip var: Yaprak seviye KPI, Ara seviye KPI ve Objective KPI.

Yaprak seviye KPI'lar zaten bir KPI hiyerarşisinin en ucunda olacak noktaları ifade ediyor. Bunlarda herhangi bir özetleme sözkonusu değil.

Eğer KPI'larınız bir doğal hiyerarşi içindeyse, yani aynı değerler yukarıya doğru doğal olarak özetlenerek gidiyorsa napacaksınız? Mesela satış organizasyonu hiyerarşisi bazında satış ve hedef verilerini düşünün. Satışlar yukarıya doğru toplanabilir. Hedefler yukarıya doğru toplanabilir. Bu durumda bunu tek bir KPI yapıp, arkada küpte bununla ilgili hiyerarşiye bağlamayı düşünebilirsiniz. Ara levellarla ilgili scorecard'da hiyerarşiyi koyduğunuz anda otomatik olarak ara seviyeler oluşacaktır.

Ya peki bu scorecard'la ilgili bir de strategy map yapmak istiyorsanız? O zaman ara KPI'lar oluşturmanız gerekir ki, strategy map'teki şekillerel bunları eşleyebilesiniz. Dolayısıyla scorecard'a hiyerarşiyi ekleme senaryosu burada çöker. Ama merak etmeyin o kadar da büyük bir çöküş değil bu. Çünkü veriambarı ve küp yapısında değişiklik yapmanıza gerek yok. Sadece hiyerarşinin her member'ı (ya da göstermek istediğiniz memberları) için yeni KPI create etmeniz gerekir. Bu yeni KPI'ları create ederken member filterla bağlamak istediğiniz hiyerarşi member'ını seçebilirsiniz. Böylelikle ara seviyelerde özetleri doğru olarak özetlemiş ara KPI'lar yaratmış olursunuz.

Peki o zaman Objective KPI'ları ne için kullanıyoruz?

Elmayla armutu beraber özetlemek için Objective KPI'ları kullanıyoruz. Objective KPI'larda actual ya da target özetlenmez. Sadece hesaplanan score özetlenir. (Score hesaplamayı belki başka bir yazıda yazarım, vakit bulabilirsem :( )

Yani diyelim elma satışlarında actual 50 sandık, hedef 200 sandık. Armut satışlarında da actual 20 adet, hedef de 20 adet. 50 sandık elmayla 20 adet armut beraber özetlenmez. 200 sandık elmayla 20 adet armut da beraber özetlenmez. Ama elma hedefini tutturma oranı 50 / 200 = 0,25 olarak ve armut hedefini tutturma oranı da 20 / 20 = 1,00 olarak hesaplanabilir. Diyelim ki elma KPI'ının ayarladığınız ağırlığı 80, armutunki de 20. Objective seviyesinde özetleme şöyle yapılabilir: (0,25 * 80) + (1. 20) / 100 = 0,40.

Umarım hesap hatası yapmamışımdır : ) Ve mantığı anlamanıza katkım olmuştur.

SharePoint 2010'da Decomposition Tree nereye kayboldu?

2010-12-07T07:31:00.000-08:00

Decomposition Tree'yi kullanabilmek için şunlara dikkat etmelisiniz:

Tarayıcınız Silverlight 3.0 ya da üstünü destekliyor olmalı.
Scorecardlar için actual ve target değerleri SSAS kübünden beslenmeli ve hesaplama tipi Data Value olmalı.
Raporlar için, rapor SSAS kübüne bağlı olmalı ve query modunda geliştirilmiş olmamalı.

Analysis Services'ın 'soğuk' ve 'sıcak' performansı

2010-12-02T07:10:00.000-08:00

Diyelim ki Analysis Services'ta bir sorguyu test etmek istiyorsunuz. Ama ilk çalıştırdığınızda süresi uzunken, tekrar denediğinizde zaten kısa sürede cevap veriyor. Böylelikle yaptığınız değişikliklerin etkisini anlama şansınız olmuyor.

Bunun sebebi Analysis Services'in verdiği cevapları önbelleğe (cache) almasıdır. Size önbellekten değil de sorguyu tekrar çalıştırarak cevap vermesini nasıl sağlarsınız? Bunun için şu XMLA kodunu kullanabilirsiniz:


               Adventure Works DW 2008         Adventure Works


Database ve Cube'ün ismini değil ID'sini kullanmanız gerekiyor. Bunun için SSMS'te bu nesnelerin property sayfalarına erişerek bilgiyi alabilirsiniz.

Benzer bir etki veritabanı performansı ölçümü yaparken SQL Server Database Engine'de de sözkonusudur. Orada da (tabii ki bir test ortamında) DBCC FREEPROCCACHE komutunu kullanmayı düşünebilirsiniz. Ayrıca sayfalar da buffer'dan mı geliyor diye (procedure cache'i ve buffer cache'in her ikisi de boşalmış mı diye kontrol etmek için) merak ederseniz, set statistics io on ifadesini sorgudan önce kullanarak sorgu sonucuyla birlikte dönen mesajlarda io'ların diskten mi (physical ve read ahead) yoksa memory'den mi (logical) yapıldığını anlayabilirsiniz.

Backup Compression Standard'a indi.

2010-09-27T07:31:00.000-07:00

SQL Server 2008 R2'de Standard Edition'da da backup compression kullanılabiliyor! 2008'de bu özellik Enterprise Edition'la kısıtlıydı.

Yedek dosyalarının büyüklüğünü beşte birine falan indirdiği düşünülürse, güzel haber!

SQL Server 2008 R2'ye geçmeyi düşünen 'enterprise'ların dikkatine

2010-09-27T07:28:00.000-07:00

SQL Server 2008 R2'de gelen yeni bir edition var: Datacenter Edition. Yeni bir üst edition gelmesi güzel, daha üst yeteneklere ulaşmamızı sağlayabilir, ama dikkat edilecek bir nokta daha var: Tavan artık Enterprise Edition değil.

Mesela CPU desteğine bakarsanız, SQL Server 2008 için Enterprise Edition'ın işletim sistemi maksimumuna kadar desteklediğini görüyorsunuz. Ama SQL Server 2008 R2 için Enterprise Edition'ın limiti 8 CPU. İşletim sistemi maksimumuna kadar destekleyen edition Datacenter Edition.

Yani bazı kurumlar SQL Server 2008 Enterprise Edition'dan SQL Server 2008 R2 Enterprise Edition'a upgrade etmekle yetinebilecekken, bazılarının Datacenter Edition'a upgrade etmesi gerekecek. Fiyat farkını araştırmadım ama incelemeniz gerekebilir.

CPU sayılarıyla ilgili şu linke bakabilirsiniz: http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx

Daha detaylı bir karşılaştırmayı, SQL Server Books Online'da Features Supported by the Editions of SQL Server 2008 R2 başlıklı yazıda bulabilirsiniz.

SQL Server 2008 R2 için SysPrep

2010-09-15T08:03:00.000-07:00

Bir istemçi işletim sistemi kadar çok sayıda SQL Server kurulumu yapılacak olması her ne kadar imkansızsa da, bazı kurumlar için sık sık SQL Server kurulumu yapıyor olmak bir sıkıntı olabilir. Acaba bu kurulumları hızlandırmanın bir yolu olabilir mi?

SQL Server 2008 R2'de Microsoft çok sayıda SQL Server kurulumuna sahip müşterilerini -doğal olarak :) - çokça düşünmüş. Bu düşünceli yaklaşımın bir sonucu da SQL Server için SysPrep imkanı getirmek olmuş. Installation Center'ın Advanced sekmesine tıkladığınızda iki yeni bağlantının geldiğini görüyorsunuz:

Image Preparation ile binary kurulumu bitmiş bir imaj hazırlayabilir, Image Completion ile de kurulumu tamamlayabilirsiniz.

Çoğu DBA için çok önemli bir özellik olmasa da sık sık SQL kurulumu yapması gereken DBA'ler için bu özellik faydalı olabilir.

Books Online bu SysPrep'in desteklediği bazı senaryoları şöyle sıralıyor:

Prepare Image adımını kullanarak aynı bilgisayarda bir ya da daha çok konfigürasyonu tamamlanmamış SQL Server kurulumu hazırlayabilirsiniz. Bu hazırlanmış kurulumlar Complete Image adımıyla aynı makinede daha sonra tamamlanabilir.

Hazırlanmış kurulumun SQL Server kurulum konfigürasyon dosyasını yakalayabilir ve bunu başka makinelerde sonradan konfigür edilmek üzere başka konfigürasyonu tamamlanmamış SQL Server kurulumları oluşturmak için kullanabilirsiniz.

Windows SysPrep aracıyla birlikte kullanarak, içinde SQL Server SysPrep'i de barındıran bir işletim sistemi SysPrep'i hazırlayabilirsiniz. Bu işletim sistemi imajını çok sayıda makineye yayıp, işletim sistemi seviyesinde kurulum ayarlarını tamamlar, ardından da SQL Server kurulum ayarlarını tamamlayabilirsiniz.

Çoklu Veritabanı Sunucu Yönetimi için SQL Server 2008 R2

2010-09-15T07:29:00.000-07:00

Çok sayıda SQL Server kurulumu yönetmeniz gerekiyorsa, SQL Server 2008 R2'ye geçmeyi istemeniz için önemli bir sebebiniz var demektir. Ama hayalkırıklığı yaratacak bir unsuru da en baştan söyleyeyim: Sadece kontrol noktanızın SQL Server 2008 R2 olması -en azından şimdilik- yeterli değil. Kontrol etmek istediğiniz noktaların da SQLServer 2008 R2 olması gerekiyor.

Peki tüm bir organizasyonunuzda bu geçişi yaptınız diyelim; ne elde edeceksiniz?

SQL Server kurulumlarınızdan birini Utility Control Point (UCP) olarak ayarlayabileceksiniz. Sonra da SQL Server kurulumlarını ve DAC'ları (Data-tier Application Component) bu UCP'ye kaydedebileceksiniz. CPU kullanımı, disk dosyalarının kullanımı gibi birtakım hayati bilgiler kaydını yaptığınız tüm kaynaklar için varsayılan ayarı değiştirmediyseniz 15 dakikada bir toplanacak ve size hazır bir konsol olarak UCP üzerinden sunulacak.

Buradaki amacım, işin nasıl yapıldığını anlatmak değil, en azından bu yazıda böyle bir amacım yok. Sadece neler olabileceğinin farkındalığını oluşturmayı hedefliyorum. Onun için şimdilik teknik detaylara takılmayın. Sizin için bu önemli bir özellik mi ona odaklanın: Eğer en az on civarında takip altında tutmanız gereken SQL Server kurulumunuz varsa, bu kurulumlar üzerindeki bazı veritabanlarını ayrıca özel olarak takip altında tutmak istiyorsanız ve mevcut imkanlarınız bunları derli toplu tek bir yerde görmeye imkan tanımıyorsa, UCP kullanmak çok işinize yarayabilir.

Resim sanırım nasıl bir şey elde edebileceğiniz konusunda bir parça fikir vermiştir. Üstelik bu genel görünümü sadece yönettiğiniz SQL Server kurulumları (instance) için değil, deploy ettiğiniz veri katmanı uygulama bileşenleri için de (DAC) elde edebileceksiniz.

Peki bu genel görünümün yanısıra, tekil olarak bu kaynakların herhangi biriyle ilgili neler görebileceksiniz. Onun da bir örneğini sunalım:

Burada storage sekmesini görüyorsunuz, benzer şekilde CPU kullanımını da zaman bazında değişim olarak incelemek mümkün.

Ayrıca uyarı durumu kurallarını (policy'ler) da istediğiniz gibi ayarlayabiliyorsunuz:

Böylelikle yönetmek zorunda olduğunuz belki de yüzün üzerinde kurulumun ve uygulamanın hangilerinin gereğinden fazla ya da gereğinden düşük yükle çalışıyor olduğunu çok kolay takip edebileceksiniz.

Uygulama ya da instance'ları sunucular arasında taşıyarak yükü dengelemek, bazı uygulama ya da instance'ları aynı sunucuda birleştirmek gibi pek çok senaryoda UCP'ler size değerli bilgileri çok hızlı bir şekilde sunuyor olacaktır.

Tatilden ve anılardan bir şişe...

2010-08-01T16:04:00.000-07:00

Bu yazıyı senelerce önce şimdi erişim parolasını bile unuttuğum bir blogda yazmıştım. Giriş yazısıydı. Rahat bi on sene olmuş mudur acaba? O kadar yaşlandım sanırım.

Hayli iddialı bir İngilizce'yle yazmışım. Eminim hatalar vardır. Üzerinde çok durarak yazmamıştım. Ama şimdi okuyunca, içeriği, tonu, akışı çok hoşuma gitti. Buranın teknik günlüğüm olduğunu ben de biliyorum ama kesintisiz 35 günlük (bir Cumartesi boştum ama o gün de 8 saatlik şehirler arası bir yola iki şoförden biri olarak gidip aynı gece otobüsle İstanbul'a geri döndüm...) bir çalışma döneminden sonra çıktığım üç haftalık tatilin ilk haftasını bitirdiğim şu günde biraz da geyik paylaşayım sizinle dedim.

Fırsat bulur da elimi değdirebilirsem, Türkçesini de yazarım belki, ama orijinalini İngilizce olarak yazmıştım zaten... Öylece paylaşayım en iyisi sizinle...

BOTTLE IN THE WILD

Now, now… that famous phenomenon! How come it is so famous? You know, there is this guy, alone in an island. In a damn place that is so out of reach like deep in a desert! But it is covered all over by water; that is some difference. Some difference that doesn’t matter much!

This guy has always a bottle, some material to be used as paper, or maybe paper itself. (But that would not be a good idea, to use plain paper and trust it to the mercy of tones of water.) And something to write on it too! When I think of the times I have found myself in a building of offices with nothing to write with or write on when needed, this happenance seems just a bit unlikely. (Happenance is used on purpose; I like the sound of it. Why not? This is not my language I will be decomposing, if it is deemed so. Or if it will have a life of its own as a new word, it is always good to produce something.)

Let’s get back to the subject. This guy… Off course a guy! Don’t you watch movies, or read books! Never ever a lass is alone in an island. This guy finds a way to close a bottle that has been opened so that it won’t get water in. Oh boys… and girls, come to that… This needs a factory and a few hundred workers! Has anybody ever seen a bottle that had been opened that has been closed watertight again by some regular ordinary ‘man alone in the island’ chap?

Ok! Don’t play with our phenomena. This guy is in the island. Alone… Not so alone… He has some writing device and a thing to write on that is durable enough. And, he has a means to close the bottle! But, he has the bottle in the first place, you know… I didn’t forget it. Just wrote it a bit down in the general list. The shopping list or the list of the producer’s assistant for the scene continuity. Whatever!

That is POTS, plain old telephony system, or plain odd testimonial-type sketching. I made it and so did it happen.

One impossible is becoming nothing again. Lights, camera, can all the curious cell phone-come-camera owners catch it? HE SAILED THE BOTTLE! Off you go! What a bitch of a bottle! Off you go! Don’t get back! I know it is the tides or waves or whatever the oceanologists call that shoved me off to this island keeping you come back! But you have to go!

If a man with such limited means can find the necessary devices and be able to sail that message… If this is such a well-known phenomenon all over the world… That means such things happen, and happen them frequently, doesn’t it! If there is such an unlikely reader for such an unlikely piece of written word… THEN I KNOW YOU HAVE TO BE THERE! MY DEAR DEAR READER! I KNOW YOU WILL BE READING THIS. I AM HERE. DAMN, I WAS NEARLY FORGETTING TO WRITE THE COORDINATES. I AM BURIED UNDER ORDINARY DAIL JOB’S DOINGS. I AM UNDER SO MUCH WORK THAT IS MEANINGFUL BUT UNMEANINGFUL WHEN COMPARED TO MY DESIRE TO WRITE AND TO WRITE AND TO READ AND WRITE AND READ AND READWRITEREAD.

If that is possible, that has been possible, then I am putting this on. I am sailing, man! To the internet ocean! My only fear is, this ocean may consist of alone guys in lonely islands.

I have opened up my blog space. I have written my words. Surely this must be more than enough, compared to the ordinary regular ‘man alone in the island’ chap’s bottle message.

Or do I have to do something to promote my corner? Not now! I am busy. You know, the day job!

Transaction Log'um neden virtual logları yeniden kullanamayıp büyüyor?

2010-06-23T08:20:00.000-07:00

SQL Server'da çeşitli sebeplerle transaction log içindeki virtual logları yeniden kullanıma alamayıp logu büyütmeye başlayabilir. DBA olarak yönetimi iyi yaparsak böyle bir durumla karşılaşma ihtimalimiz son derece düşüktür. Ancak hangi durumlarda böyle bir sorunla karşılaşabileceğimizi bilmiyorsak, sıkıntılar yaşayabiliriz.

Eğer bir veritabanının logunda böyle bir sorun yaşıyorsanız, sys.databases katalog görünümünde log_reuse_wait_desc sütünuna bakın. Books Online'da bu katalog görümün tanımına bakarsanız, kolonun alabileceği olası değerlerle ilgili hayli geniş açıklamalar da içeren bir bağlantıyla işinize yarayacak bir sayfaya ulaşabilirsiniz.

Buffer cache hit ratio ve read-ahead read

2010-06-05T15:57:00.000-07:00

Öncelikle buffer cache hit ratio ne demek?

SQL Server'ın performansını ölçerken kullanılan önemli performans sayaçlarından biridir. Gelen sayfa taleplerinin yüzde kaçının zaten bellekte var olduğuna dair bir oran verir. Bunun yüzde 90'ın üzerinde olmasını bekleriz. Servis ilk açıldığında oran düşük olup zamanla yükselebilir. Sık kullanılan sayfaların belleğe yerleşmiş olmasıyla...

Bir sistemin zaman içindeki değişimini izlediğim ve kendi normallerimi oluşturduğum bir durum varsa, buffer cache hit ratio için yüzde 90'ın da üzerinde bir hedefim de olabilir.

Peki read-ahead read ne demek? SQL Server'ın yaptığı üç tür okuma vardır: logical, physical, read-ahead.
Logical okuma her zaman yapılır, ilgili sayfanın bellekten okunması demektir. Eğer gerekli sayfa bellekte yoksa, logical read'den önce diskten belleğe okunması gerekir. SQL Server bir sıra sayfanın diskten okunması gerektiği durumlarda sadece ilkini fiziksel okuma olarak yapar, diğerlerini daha logical olarak okunmaları gerekmeden read-ahead read'le (önden okuma denebilir) okur. Ama sadece milisaniyeler önce yapmış olacaktır bu okumayı muhtemelen.

Bu iki bilgiyi bir araya getirirsek: SQL Server buffer cache hit ratio'yu hesaplarken, read-ahead read'leri de hit sayar! Bu durumda buffer cache hit ratio'yu tek başına kullanmak yeterli olmaz. Beraberinde mesela normalin üstünde bir disk aktivitesi olup olmadığı gibi konuları da incelemek gerekir.

SharePoint 2010 BI araçları: Excel ve PowerPivot Eklentisi

2010-05-31T05:25:00.000-07:00

Excel 2010 ile analist bir son kullanıcı organizasyon verilerini görüntüleyebilir, değiştirebilir, analiz edebilir, raporlayabilir. Bu verilerden 'zeka' üretebilir. Bu tür amaçlarla en yaygın tercih edilen uygulama da Excel'dir.

Excel bu yüksek terhcih edilirliğiyle, Microsoft'un BI araçları içinde de önemini koruyor ve giderek geliştiriyor.

Özellikle Excel 2010'la kullanılabilen yeni bir ek çok önemli: PowerPivot. 10 birimlik veriyi 1 birime kadar sıkıştırarak bellekte kullanabilmesiyle, yüksek miktarlarda veriyle çalışmak için uygun bir seçenek. (Gigabyte'larca veriyle çalışabilirsiniz, ama yüzlerce Gig'le değil.)

PowerPivotla gigabytlar büyüklüğünde veriyi bağlanıp belleğe çekebilir ve bellekte OLAP benzeri bir yapı oluşturarak özet tablolar ve özet grafiklerle bu veriyi raporlayabilirsiniz. Üstelik sayfa dilimleyicilerini kullanarak Excel 2007'de yapabildiğinize göre çok daha zengin olarak...

Eğer SharePoint 2010 da kullanıyorsanız, oluşturduğunuz bu Excel dosyalarını SharePoint 2010 üzerine entegre kurulabilen Analysis Services imkanıyla doğrudan SharePoint'e yayımlayabilirsiniz de.

SharePoint 2010'da artık kullanıcı, bilgisayarında Excel yüklü değilse bile Excel belgesini tarayıcıda açabiliyor. Hatta tarayıcıda açtığı bu belgede (yetkisi varsa) içerikte değişiklik de yapabiliyor. Başka kullanıcılar da belgedeki bu değişiklikleri görebiliyor. (Aslında bu değişiklik kısmının iş zekası açısından tehlike de oluşturabileceğini belirtmek lazım...)

PowerPivot eklentisiyle ilgili de önemli bir notum var. PowerPivot, gerilla tipi ve çok etkili bir silah gibi. Onu doğru yerlerde kullanmak gerekli. Nasıl ki düzenli ordu kullanılması gereken bir cephe savaşında sadece gerilla taktikleriyle hareket etmek yanlış olursa, kurumsal bir veriambarı ve küp yapısına sahip olması gereken bir şirketin de sadece PowerPivot'la çalışması tehlikeli olur. Aynı benzetimden yola çıkarsak: Düzenli ordunun çalışmaları gerilla taktikleriyle desteklenebileceği gibi... Kurumsal bir yapı da mevcut veri ambarı ve küp yapısının zaman bağlamında yavaş tepki verdiği durumlar için, ara zaman dilimlerinde yeni ihtiyaçları PowerPivot'la kısa sürede karşılayıp sonraki çevrimde bunları normal veri ambarı ve küp yapısının içine alabilir.

Öte yandan kurumsal ölçekte bir veriambarı ve küp yapısına sahip olmasına gerek olmayan daha küçük şirketler PowerPivot'la analitik ihtiyaçlarını büyük ölçüde karşılayabilirler.

PowerPivot'un Microsoft'un 'BI for the masses' yani kitleler için İş Zekası sloganına büyük katkısı var. Ama yine Microsoft'un veri ambarı için kullandığı 'one version of truth' yani 'gerçeğin tek versiyonu' sloganına büyük zararlar verme ihtimali de var. Bu yeni teknolojiyle ilgili temel çekincem, veri marketleri (data martlar) benzeri birbiriyle uyumsuz olabilecek veri adacıklarının ortaya çıkması...

SQL 2008 R2 çıktı

2010-05-04T00:17:00.000-07:00

MSDN ya da TechNet üyesiyseniz, hemen indirebilirsiniz.

İşin çapına göre BI

2010-04-27T03:45:00.000-07:00

İş zekası deyince daha çok akla kurumsal zeka ve büyük sistemler geliyor. Ama Microsoft 'BI for the Masses' yani 'Kitleler için İş Zekası' sloganıyla sahayı genişletiyor.

SharePoint 2010 Insights kapsamında kitleler için iş zekası kavramının altının dolmaya başladığını görüyoruz.

Microsoft üç kademe iş zekası öngörüyor:
- Kendin Yap tipi kişisel çalışmaya dayalı iş zekası
- Topluluk için iş zekası
- Kurumsal iş zekası

Bunları ayrı ayrı ele alacak olursak:

Kendin Yap tipi kişisel çalışmaya dayalı iş zekası:
İhtiyaç duydukları anda kişilerin kullanımına açık ya da onlara sunulan bilgidir. IT ekibinin katılımı bu tip çalışmada yok gibi ya da çok kısıtlıdır. Kullanıcılardan gelen talepleri tekil tekil karşılamak yerine IT ekibi kendi başlarına iş zekası raporları oluşturmaları için insanlara bütüncül bir ortam sunmak için çalışma yapabilir.
Bu tip bir çalışmada bir veri ambarı çalışması hiç olmayabilir, ya da düşük kapsamlı olarak var olabilir. Muhtemelen veri ambarı dışındaki birtakım kaynaklara da erişim sağlanacaktır. Kullanıcılar araçları kullanarak kendi kendilerine veri ambarına paralel ya da veri ambarı yerine küp benzeri yapılar oluşturabilirler. (In-Memory OLAP tipi çalışmalar buna örnektir.)

Topluluk için iş zekası:
İnsanlar projeleri tamamlamak için takımlar ve gruplar halinde çalışırlar. Topluluk için iş zekası bu tür ortak çalışmalara yönelir. Ortak kararlara varmak için işbirliğini ve bilginin hızlı paylaşımını geliştirmeye yönelik iş istihbaratı sunar.

Kurumsal iş zekası:
Kurumsal ya da organizasyonel iş zekası, insanların hedeflerini ve etkinliklerini genel şirket amaçları, hedefleri ve ölçütleriyle uyumlu hale getirmelerine yardımcı olan bir seri aracı içerir. Şirketin bütüncül bir görünümü karneler, strateji haritaları, konsollar, raporlar, pivot görünümler gibi araçlar kullanılarak şirket içindeki ya da şirket çıkarlarıyla ilgili insanlara sunulur.

Microsoft'un SharePoint Insights kapsamında sunduğu araçların bu iş zekası tiplerine yönelik kullanımlarını nasıl sınıflandırmamız gerektiğine biraz kafa yoracak olursak:

Kendin Yap tipi iş zekasının birincil ve en önemli aracı Excel ve PowerPivot eklentisidir. Bu eklentiyle birlikte Excel'i kullanan insanlar, gerek veri ambarından olsun gerek normal veritabanlarından olsun yüksek miktarda veriyi tek bir Excel dosyasına alıp bu dosya kapsamında OLAP küpleri benzeri yapılar kurabilirler. Ortaya çıkan dosya SharePoint'e yüklenirse, arka planda zaten SharePoint'e entegre kurulmuş bir SSAS motoru üzerinde çalışır. Ayrıca Excel ve Excel Servisleri, Visio ve Visio Servisleri ve Report Builder da Kendin Yap tipi iş zekası çözümlerinde belirli ölçeklerde kullanılabilirler.

Topluluk için iş zekası kapsamında ağırlıklı olarak Excel ve Excel Servisleri, Report Builder, Visio ve Visio Servisleri kullanılır. Kurumsal bir yapının altında topluluk alt destekleri için PerformancePoint Services ve Reporting Services'tan da yararlanılabilir.

Kurumsal iş zekası için temel Insight araçları ise PerformancePoint Services ve Reporting Services'tır. Ama bunların altındaki yapılarda ve kurum içindeki topluluk iş zekası destekleri için Excel ve Excel Servisleri, Report Builder, Visio ve Visio Servisleri de yoğun olarak kullanılabilir.

Her bir aracı ne tür durumlarda kullanmak gerektiğini de başka yazılarda ayrıca paylaşmayı planlıyorum.

SharePoint Insights

2010-04-27T03:03:00.000-07:00

Güzel isim...

SharePoint artık iş zekasıyla ilgili kısmını tek bir kavramsal isim altında birleştirdi: SharePoint Insights.
İnsights, anlayışlar, kavrayışlar, içgörüler olarak çevrilebilir: Şirketinizle, işinizle ilgili kavrayışlar. Bana anlayış ya da içgörüden ziyade kavrayışlar yakın geliyor.

Bence SharePoint bir iş zekası sistemi için veri ambarının kendisi kadar önemli.

Veri ambarını ve SharePoint'i iş zekasının iki temel 'toplanma noktası' olarak düşünüyorum.

Microsoft'un sloganıyla veri ambarı 'one version of truth'tur. Yani gerçeğin tek versiyonu. Ama ufak bir sorun var: Bir veri ambarı sistemini şirketin tamamını kapsayacak şekilde geliştirmek onyıllar alabilir. Ve aslında biten bir süreç de değildir. Bunun pratikte anlamı şu: Her zaman için raporlama bütününüz veri ambarı bütününüzden daha geniş olacaktır.

Çalışmaya yeni başladığınız sıralarda şirkette var olan bir raporlama yapısı vardır. Siz bunu yavaş yavaş veri ambarı yapısına geçirirsiniz. Bu geçiş sürecinde raporlama sisteminde yer alıp veri ambarı sisteminde yer almayan kısımlar olacaktır.

Başka bir açıdan, mevcut raporlama yapısını veri ambarıyla yakalasanız bile, yeni istekler gelmeye, yeni oluşumlar ortaya çıkmaya devam eder. Bunları raporlama sistemine almak bazı durumlarda veri ambarına dahil etmekten daha hızlı şekilde yapılabilir. Bu hız farkı döneminde de raporlama sistemi veri ambarından en azından bir müddet daha geniş olacaktır.

SharePoint'in bize sunduğu bu: Veri ambarı kökenli olan raporlarımızla veri ambarı kökenli olmayan raporlarımızı tek bir sistem olarak bir araya getirip tek bir iş zekası sistemi önyüzüne sahip olabiliyoruz. Burada özellikle 2010 sürümünde SharePoint'e bir servis olarak tamamen dahil olan PerformancePoint'in büyük önemi var.

Pek çok iş zekası projesinde başlarken veriambarına paralel olarak mevcut yapının SharePoint'te bütüncül olarak oluşturulması fayda sağlayacaktır. Bir yandan sistemin müşterileri bütüncül bir yapıya kavuştukları izlenimini taşırken, siz arka planda çalışmaya devam ederek veri ambarı katmanında gerçekten bütüncül bir sisteme doğru ilerleyebilirsiniz.

Şirketim için uygun KPI'Lar

2010-02-21T08:16:00.000-08:00

Bir arkadaşın sorduğu bir soru üzerine yazdığım cevabı sizlerle de paylaşmak istedim:

Küp yaklaşımında kpi’dan çok measure’lar ve dimension’lar yani ölçütler ve boyutlar önemlidir.

Öncelikle hangi sayısal değerleri (measure) takip etmek istediğinizi ve bunları ne kırılımda incelemek istediğinizi belirlemelisiniz. Buradan zaten KPI’lar üretilir sonradan.

Şöyle bir örnek vereyim.

Konu olarak satışları incelemek istiyorsunuz. Satışlarla ilgili hangi sayıları takip etmek istersiniz? Mesela şunlar olabilir:

Satış tutarı
Satış adedi
İndirim tutarı
Vergi tutarı
Nakliye tutarı
Satışın ürün maliyeti
…

Peki bunları ne açılardan incelemek istiyorsunuz? Şunlar olabilir:

Zaman
Satış organizasyonu (Mağaza? Reyon? Kişi?)
Ürün
Müşteri
Vb…

Tabii bu boyutların attribute’ları da olacaktır. Mesela ürün boyutunun bir attribute’u marka olabilir. Böylelikle satışınızı marka bazında da kırılımlı inceleyebilirsiniz.

Bu yapıyı oluşturduktan sonra bunun üzerine KPI’lar tanımlanabilir.

Mesela:

Satışın geçen sene aynı döneme göre artış oranı
Satış brüt karının ürün maliyetine oranı
İndirim oranı

Bunlarla ilgili güncel değer, hedef değer, kpi durum formülü ve kpi trend formülü oluşturabilirsiniz.

Şirketin veri ambarı yapısıyla ilgili ön analizle ana hatların çıkarılması konusunda Ralph Kimball’den The Microsoft Data Warehouse Toolkit’in ilk bölümü çok iyi fikir verebilir. Analizin nasıl bir yöntemle yapılması gerektiğini iyi anlatıyor.

KPI’lar konusunda da Philo Janus’un Pro PerformancePoint Server 2007 adlı kitabında güzel bir anlatım var.

Tekstilde kullanılan KPI’lar konusunda bir kaynak bulmak biraz zor olabilir. Bu tür kaynak listeleri ya çok profesyonel çalışan firmalar tarafından yüksek fiyatlı danışmanlıklar olarak veriliyor, ya da çok basmakalıp genel geçer listeler oluyorlar.
Şirketiniz için doğru KPI listesi ancak şirket içinde bir çalışmayla ve zamanla sağlıklı bir şekilde gelişir. Şirket kültürleri birbirinden farklı olabildiği için yabancı bir ülkede işe yarayan bir KPI sizde işe yaramayabilir. Hatta Türkiye’de aynı sektörde faaliyet gösteren iki firma için bile aynı KPI’lar geçerli olmayabilir.

Veri ambarı hazırlık sürecinden itibaren yapılacak çalışmalar KPI’ların belirlenmesini de beraberinde getirecektir.

SSAS Writeback

2010-02-10T03:40:00.001-08:00

Analysis Services Writeback özelliği Türkiye'de pek kullanılan bir özellik değil. Ama artık bu değişicek gibi.

Diyelim bir senaryo analizi çalışması yapıyorsunuz. Küpte ilgili senaryoyla ilgili veriler işlenmiş durumda. Excel'den bağlanıp görebiliyorsunuz. Acaba şu değer şöyle değişseydi, yukarıya doğru etkisi nasıl olurdu? diye incelemek isteyebilirsiniz. Writeback işte bunu yapabilmenizi sağlayan özellik.

Excel 2010'la Excel üzerinden writeback yapmak mümkün hale geliyor küplere. Konu ilginizi çektiyse şu blog girdisine göz atın: http://blogs.msdn.com/excel/archive/2009/10/12/excel-2010-pivottable-what-if-analysis.aspx

SQL Server'da Profiler kullanmadan nasıl trace alabiliriz?

2010-01-06T05:45:00.000-08:00

Profiler trace'leri SQL Server'daki pek çok sorun giderme, performans iyileştirme gibi çalışmaların en önemli araçlarından biridir.

Ancak yükü zaten fazla olan sistemlerde trace'leri alıyor olmanın yükünü mümkün olduğunca düşük tutmak gerekir ve Profiler arayüzünü kullanıyor olmak da belirli bir ek yük getirir.

Bu durumda eğer rutin olarak kullandığınız, zaman zaman başlatıp bir müddet sonra durdurduğunuz trace'ler falan varsa, Profiler arayüzünü devreden çıkararak kullanmak istiyor olabilirsiniz bunları.

Yapmanın basit bir yöntemi var:
Profiler'de trace'inizi istediğiniz gibi ayarlayın. Trace'i başlatın. Sonra hemen durdurun. File menüsünden şu yolu izleyin -> Export -> Script Trace Definition -> For SQL Server 2005 - 2008.

Server side'da çalıştırmak üzere trace'in scriptini size dosya olarak verecek.

Change Data Capture (CDC) ve Change Tracking

2010-01-06T03:14:00.000-08:00

SQL Server 2008'le gelen bu iki özelliğin isimlerinin bir parça benziyor olması, biraz kafa karışıklığına sebep olabilir.

Aralarındaki farkı net bir şekilde belirtmek faydalı olacaktır.

Change Tracking sadece değişiklikleri takip eder ama değişimin tarihçesini tutmaz. Yani belirli bir tablo için belli bir zamandan beri hangi satırların değiştiğini, bu değişimin update mi insert mi olduğu gibi bilgileri ve son hallerini alabilirsiniz, ama satırların önceki hallerini değil.

CDC ise çok daha kapsamlı bir iş yapar ve değişmiş olan satırların önceki hallerinin ne olduğu bilgisini de tutar sizin için.

SQL Server 2008 Resource Governor'da Workload Groupların Özellikleri

2010-01-04T06:29:00.000-08:00

Resource Governor'la ilgili daha önce yazmıştım. Başka kaynaklarda da denk gelmişsinizdir belki, ya da hatta kullanıyor da olabilirsiniz.

Bu yazıda genel olarak Resource Governor'dan bahsetmek yerine, pek dikkat edilmeyen bazı yönlerine dikkat çekeceğim.

Resource Governor'ın temel mantığını hatırlarsak:

Resource Pool'lar tanımlanır ve bunlara CPU ve memory ile ilgili limitler atanır.
Workload Group'lar tanımlanır ve bunlar Resource Pool'larla ilişkilendirilir. Bir workload group tek bir resource pool'a ait olabilir. Ama bir resource pool'un birden fazla workload group'u olabilir.
Bir classifier function tanımlanır ve resource governor'a atanarak, resource governor aktif hale getirilir. Classifier function SUSER_SNAME(), IS_SRVROLEMEMBER(), IS_MEMBER() gibi sistem fonksiyonlarını ve LOGINPROPERTY ve CONNECTIONPROPERTY gibi property fonksiyonlarını kullanarak her sessionı bir workload group'a atar.

Böylelikle her session ilgili workload group'a atanır, onun da bağlı olduğu resource pool'daki ayarla kullanabileceği toplam pool limitleri belli olur.

Buraya kadarkiler sadece bir özetti. Asıl belirtmek istediğim şu:
Workload Group'lar sadece isimli birer torba değiller! Workload groupların da çok ilginç şekillerde kullanabileceğiniz özellikleri var.

Bu özellikler altı adet:

1. IMPORTANCE: Low, Medium, ya da High olarak atayabilirsiniz. Böylelikle aynı pool içinde bulunan workload group'ların pool'un limitlerini aralarındaki paylaşım şeklini de derecelendirme şansınız olur.

2. REQUEST_MAX_MEMORY_GRANT_PERCENT: Bu gruptaki tek bir görevin pool limitinin yüzde kaçıyla sınırlı olacağını belirler.

3. REQUEST_MAX_CPU_TIME_SEC: Gruptaki tek bir görev tarafından kullanılabilecek CPU zamanını kısıtlamak için kullanılabilir.

4. REQUEST_MEMORY_GRANT_TIMEOUT_SEC: Bu ayar sayesinde kaynaklar için beklerken timeout olma ayarını workload group seviyesinde yapabiliriz.

5. MAX_DOP: Grup bazında paralel CPU kullanım sınırıyla ilgili ayar yapma imkanı sağlar. MAX_DOP biraz karmaşık bir konudur ve çoğu durumda otomatik ayarda bırakmak faydalı olacaktır. Bu ayarı değiştirmeyi düşünüyorsanız, istediğiniz etkiyi sağlayacağını test etmiş olduğunuza emin olun.

6. GROUP_MAX_REQUESTS: Bu grup içinde eşzamanlı olarak çalışabilecek taleplerin sayısını kısıtlamak için kullanılabilir.

Bu özelliklerden daha önceden haberdar olmadığınıza bahse girerim. Tanıtım, eğitim materyallerinde pek geçmiyorlar. Ama bazı özel durumlarda çok önemli faydalar sağlayabilirler.

SQL Server'da DMV'ler (Dynamic Management Views) üzerine

2010-01-04T01:18:00.001-08:00

Öncelikle DMV demek aslında tam doğru değil. Dynamic Management Views eksik bir tanımlama olur, aslında dynamic management objects demek gerekiyor. Ama bu nesnelerin büyük bir kısmı view olduğu için DMV kısaltmasını kullanacağız. Kalan az kısım ise dynamic management functionlar.

DMV'ler (hem viewler hem functionlar) tablolara dayalı değildir. SQL Server'ın iç çalışma mekanizmasıyla ilgili birtakım yapılardan bilgiler sunarlar bize. Üstelik bu nesnelerin bir kısmı sadece anlık bilgiler değil kaynak tarihçesiyle ilgili bilgiler de sunarlar.

DMV'leri genel olarak bilmek, hangi kategorilerde bilgi sunduklarından haberdar olmak ve çok işimize yarayacak bazılarını da kullanmayı detaylı bilmekte fayda var.

DMV'lere sys şeması altında erişebilirsiniz. sys.dm_ diye başlayan bir isim standartları vardır. İsim standardının önemli bir parçası da dm_'den sonra konu grubuna göre bir kısaltma gelmesidir. Mesela sys.dm_exec diye başlayan viewler kullanıcı isteklerinin gerçekleştirilmesi (execute edilmesi) ile ilgili çeşitli unsurlar hakkında bize detaylı bilgiler verirler.

Bu yazının asıl amacı da bu kategorilerin neler olduğunu belirtmek ve dynamic management viewlerini incelemeye başlamak için size bir giriş sağlamak.

dm_exec_*
Kullanıcı kodlarının çalıştırılmasıyla doğrudan ya da dolaylı olarak ilgili unsurlar hakkında bilgi verirler. Mesela sys.dm_exec_sessions SQL Server'a açılmış oturumların herbiri ile ilgili bir satır ve her satırda pek çok bilgi döndürür. dm_exec_* grubu size en fazla fayda sağlayacak gruplardan biri olabilir. Oturumlardan tutun, sorgu istatistiklerine kadar pek çok önemli bilgiye bu gruptan ulaşabilirsiniz.

dm_os_*
Alt seviye sistem bilgilerine erişim ihtiyacınız olursa bakacağınız yer burasıdır. SQL Server'ın işletim sistemi tarafıyla ilgili konuları bu kapsama girer. Mesela bellek kullanımının ince detayları üzerine incelemeler yapmak istiyorsanız, bu grup sizin için.

dm_tran_*
Güncel transactionlar hakkında detaylı bilgiler verirler. Mesela sys.dm_tran_locks transactionların verilmiş ya da sıra bekleyen kilitlerinin herbiri için bir satır döndürür.

dm_io_*
Sistemdeki io (input output, disk aktivitesi) işlemleri ile ilgili bilgiler içerirler. Sayıları fazla değildir. Kullanma ihtimaliniz en yüksek olan: sys.dm_io_virtual_file_stats size data ve log dosyalarının io istatistiklerini verir.

dm_db_*
Veritabanları ve indeksler gibi veritabanı objeleri ile ilgili detaylı bilgiler sunarlar. Mesela sys.dm_db_index_usage_stats indekslerin nasıl kullanılıyor olduğuyla ilgili önemli bilgiler verir. Ayrıca indekslerle ilgili view'ler altında göremeyeceğiniz iki önemli dm nesnesi daha vardır. Orada göremezsiniz, çünkü bunlar function: sys.dm_db_index_physical_stats ve sys.dm_db_index_operational_stats. Bu ikisi de size indekslerin fragmentasyon durumu ve kullanımlarının detaylı analizi ile ilgili bilgiler verirler.

En yaygın kullanılan gruplar bunlar olmakla birlikte, full-text kataloglar, change data capture (cdc), service broker, replication, CLR gibi konularda da dynamic management objeleri bulunmaktadır.

DMV'lerin size getireceği imkanlar, bir DBA olarak altıncı bir duyu edinmek gibi olacaktır. Ufkunuzu açacak bu araçlara göz atmanızda fayda var.

Not: DMV'leri kullanmak için 2005 ya da sonrası bir sürümde olmanız gerekir. 2000'de bu nesneler yok.

SQL Server 2008 R2 November CTP

2009-11-19T06:50:00.000-08:00

SQL Server 2008 R2'nin November CTP'si (Community Technology Preview) çıktı. İlk bağlantı R2 için, ikinci bağlantı ise Feature Pack'i için...

http://www.microsoft.com/downloads/details.aspx?FamilyID=fe0c6a31-5ad6-4eea-a865-73bbe2608bd1&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=020EE0D5-BCE4-4A45-9D64-B0C49C8831E5&displaylang=en

Ortak boyut (conforming dimension) kullanımında bir ipucu

2009-09-09T11:30:00.000-07:00

Veri ambarı ve küp tasarımında en önemli ilkelerden birisi, farklı fact tablolarında aynı bakış açısını yani boyutu kullanıyorsak, bunlar için ortak bir boyutun kullanılmasıdır.

Yani bir ürün boyutunuz varsa, ürünle ilgili tüm fact tabloları aynı ürün boyutuna bağlı olsun istenir. Ya da bir zaman boyutunuz varsa, zamanla ilgili tüm fact tabloları aynı zaman boyutuna bağlı olsun istenir.

Peki ya bazı fact'lerinizin zaman kırılımı ay, bazı factlerinizin zaman kırılımı ise çeyrekse? O zaman ne yapacaksınız?

Veritabanı kurallarına göre düşünecek olursanız, fact tablolarında foreign key ataması yapmak için karşılık tabloda primary key ya da unique constraint ataması yapmanız gerekir. Zaman tablosunda diyelim ki en küçük kırılımınız ay olsun. AyID'yi primary key yapabilirsiniz. Peki ya çeyreğe bağlı fact için foreign key atamasını nasıl yapacaksınız. Bir ÇeyrekID kolonunuz olabilir, ama satırlarda doğal olarak tekrar edeceği için (aynı çeyrekte üç ay var) bu kolonu unique yapamazsınız. Bu durumda da foreign key yapamazsınız!

Ama... Veritabanı kısıtlarıyla düşünmeyi bırakın. Bir iş zekası çözümü gerçekleştiriyorsunuz ve küplerin dünyasındasınız. Kübün data source view'inde bu tür karşılığı unique olmayan bir foreign key ilişkisi oluşturabilirsiniz. Ardından da bir fact'te zaman boyutunu AyID bazında bağlarken diğerinde ÇeyrekID bazında bağlantı yapabilirsiniz.

Küçük bir ipucu: Küplerin dünyasında bir boyutla bir fact arasında many to many ilişki de tasarlayabilirsiniz. Bunu daha önceki bir yazımda anlatmıştım.

DÜZELTİ:

Yukarıda ufak bir hata var. Anlatılan ilişki kurma şekli yapılabiliyor ama sonucu biraz farklı. Bu yaklaşımla da yine many to many ilişki kurmuş oluyorsunuz.

Şöyle bir durum düşünün: Haftalık nöbet ataması yapıyorsunuz. Ama günlük olarak nöbetleri sayıyorsunuz. Yani atamalarda nöbet hafta bazında bağlı olsa da bir haftaya bağladığınızda o değer alttaki günler için de tekrar etmeli. Bu durumda tarih boyutunda haftaID alanıyla data source view üzerinden bir ilişki kurabilirsiniz. Kübün içinde dolaşırken, gün bazında bu ilişkiye girerseniz, atama bilgisinin altındaki günlerde tekrar ettiğini görürsünüz. Yani bir yedi olur.

Peki yapmak istediğiniz gerçekten bir fact'te zamanla gün bazında, bir başkasında ise hafta kırılımında ilişki kurmaksa ne yapacaksınız. Çözüm yine data source view'de. Hafta bazında kırılımın kolonlarını içeren bir named query yaratın. Aynı zaman tablosundan türetildiği için veri yüklerken tek bir tabloyu yüklemeniz yeterli olacak ve bir update her iki boyutu beraber etkileyebilecektir

Üstelik günlük boyutunuzda haftaID'yi de bulundurup, bu boyutu haftalık fact'le haftaID attribute'ü ve haftalık boyut üzerinden haftalık fact'le de ilişkilendirebilirsiniz. Böylelikle haftalık fact ve günlük fact'ten measure'ları, haftadan aşağıya inmemek koşuluyla aynı raporda yanyana getirebilirsiniz.

Belki biraz karışık oldu ama bu konuyla ilgili kafa yormanız gerekmişse, çözümü anlayacağınızı düşünüyorum. Çözmeniz gereken bir sorunsa ve yazdıklarımı anlamadıysanız, bir yorum bırakın bu yazıma. Anlamadığınız noktaları belirtin. Açıklama yaparım.

Veri madenciliğinde model kümesi gerçeği ne kadar iyi temsil ediyor olmalı?

2009-08-19T08:08:00.000-07:00

Öncelikle gerçeği iyi temsil etmek ne demek? Buna kafa yormak gerekir.

Diyelim ki, kredi ödemesini geri hiç yapmayacak, geciktirerek yapacak, bir de hiç bir sorun olmadan yapacak kişileri ayrıştırmak istiyorsunuz. Geçmiş deneyimlerinizden yüzde 2 geri ödemeyi hiç yapmayacak, yüzde 5 sorunlu yapacak, yüzde 93 de sorunsuz yapacak insan olacağını biliyorsunuz. Model kümenizde her üç durumla sonuçlanmış kayıt örnekleri bulunmalı. Bu kesin. Her üçünden de yeteri kadar örnek bulunmalı bu da kesin.

Peki bunların oranları gerçekte olduğu gibi mi olmalı? Hayır.

Her üç duruma ilişkin yeterince kayıt olması yeterli. Hatta sorunsuz geri ödeyenlerin oranı üçte bir gibi falan olmalı, yüzde 93 değil.

Biraz kafa karıştırıcı gibi geliyor belki, ama amacınız insanların yüzde kaçının geri ödeme sorunu çıkaracaklarını bulmak değil! Amacınız, kişilerin hangi özelliklerinin kredi geri ödemesinde belirleyici olduğunu bulmak.

Veri madenciliği başlığı altında hangi tür işler yapılabilir?

2009-08-19T06:55:00.000-07:00

Veri madenciliği, reklam etkisi de hayli yüksek olan bir kalıp. Ama acaba ne demek? Veri madenciliği yaparken, aslında hangi alt görevleri gerçekleştiriyoruz.

Bunları şu şekilde sıralayabiliriz:

- Classification
- Estimation
- Prediction
- Affinity Grouping
- Clustering
- Description and Profiling

Terimlerin Türkçelerini tabii ki düşünmeliyiz.

Classification sınıflandırma olarak adlandırılabilir. Clustering ise kümeleme.

Sınıflandırma ve kümeleme birbirlerine bir hayli yakın kavramlar. Ama aralarında önemli bir fark var: Sınıflandırma yaparken elimizde referans sınıflar var ve yeni kayıtların bu sınıflardan hangisine uygun olduğunu tahmin etmeye çalışıyoruz. Kümelendirme yaparken ise elimizde belirli sınıflar yok. Verinin içindeki anlamlı kümeleri bulmaya çalışıyoruz.

Örnek düşünelim. Diyelim ki müşterilerimizin şirkete toplam getirisine göre belirli sınıflarımız henüz yok. Bu durumda kümeleme çalışması yaparak anlamlı sınıflandırma nasıl yapılmalı diye belirlemeye çalışabiliriz. Ama eğer altın, gümüş ve bronz müşteriler olarak zaten bir sınıflama yapmışsak, o zaman yeni müşteri adaylarının hangi sınıfa karşılık geldiğini tahmin etmek için sınıflandırma çalışması yapabiliriz.

Birbirine yakın bir başka kavram ikilisi de Estimation ve Prediction. Estimation'a tahmin, prediction'a ise öngörü diyebiliriz. Ama estimation için tahmin yerine çıkarsama da diyebiliriz. Aralarındaki en önemli fark şudur: Estimation şu an var olan veriler içindeki desenleri tahmin etmek içindir. Prediction ise, şu anki veriler ışığında gelecekteki bir durumu tahmin etmek içindir. Bu fark projenin geliştirilmesini de çok derinden etkiler. Estimation (çıkarsama) yaparken, şu anki verilerin içinde şu an geçerli olan desenleri bulmaya çalışırsınız. Oysa prediction (tahmin) yaparken, verilerin mesela 6 ay önceki hallerinin şu an ne sonuç doğurduğuna bakıp, şu anki verilerin 6 ay sonra ne sonuç doğuracağını tahmin etmeye çalışırsınız.

Estimation ve Classification arasında da bir hayli benzerlik var. Burdaki farkı bir örnekle anlatmak daha iyi olacak:
Diyelim ki kredileri risk açısından değerlendiriyorsunuz. Eğer risk sınıfları oluşturup kredileri bunlara eşlemeyi düşünüyorsanız, classification yapıyorsunuz demektir. Bunun yerine tüm krediler için 1-100 arasında bir risk puanı verecekseniz, estimation yapmanız gerekir.

Affinity Grouping Association Rules olarak da adlandırılabilir. Birliktelik kuralları olarak çevirebiliriz. Neler birlikte olur? Hangisi hangisini tetikler? Hangi ürün diğer ürününün satışını tetikler? Hangi suçlar bir arada işlenir? Bu gibi soruların yanıtı aranır bu görev tipinde.

Profiling ise, profil çıkarımı olarak düşünülebilir. 40 yaş üstü ekonomik durumu iyi bayanların oy verirken yoğunlukla belirli bir partiyi tercih etmesi bir profil örneği olarak verilebilir.

Data Mining (veri madenciliği) konusunda kitap tavsiyesi

2009-08-19T06:51:00.000-07:00

Wiley'den çıkmış olan Data Mining Techniques Second Edition for Marketing, Sales, and Customer Relations Management çok iyi bir kitap. Yazarları Michael J. A. Berry ve Gordon S. Linoff.

Blogda ileride yazacağım bazı girdilerde kaynak olarak da yararlanacağım önemli bir kitap. Her seferinde kaynak belirtmeyebilirim yazılarımda, ama tamamen alıntı niteliğinde birşeyler yazarsam, tabii ki belirtmiş olurum. : )

SQL Server 2008 R2

2009-08-17T22:55:00.001-07:00

SQL Server 2008 R2'nin Ağustos CTP'si (Community Technology Preview) indirime hazır.

İlgili bir yazıyı şu adresten okuyabilir ve aynı yazıdan indirme bağlantılarına ulaşabilirsiniz:

http://redmondmag.com/articles/2009/08/10/microsoft-offers-sql-server-2008-r2-test-bits.aspx

İş zekası projeleri için önemli bazı başlıklar

2009-06-30T00:54:00.000-07:00

Her projede ele alınması gereken konular vardır. İster kişisel bir çalışma yapın, ister büyük bir kamu kurumu için beş yıllık bir projeye giriyor olun, bazen sadece düşünce seviyesinde bazen yüzlerce yazılı sayfa şeklinde ele almanız gereken konular vardır.

Biz de bu unsurlardan bazıları açısından iş zekası projelerini inceleyelim:

PROJE GETİRİLERİ (ya da hedefleri)

Finansal sonuçların yanısıra finansal olmayan sonuçlar da hedeflenebilir.

Sektörüne, içeriğine ve şirketin yaklaşımına bağlı olarak değişiklikler göstermesi mümkün olmakla birlikte iş zekası projelerinden beklenebilecek bazı hedefleri sıralayalım. Tabii ki bu liste bütüncül değil, yani olası tüm getirileri listelemiyor. Ama size bir fikir verebilir:

- Şirket gelirlerinin daha iyi anlaşılıp artırılabilmesi.

- Şirket maliyetlerinin daha iyi anlaşılıp azaltılabilmesi.

- Müşteriler, çalışanlar, departmanlar gibi unsurların özellikleri bazında performans açısından incelenebilmesi sonucu, müşteri ödül programlarının, çalışan ödül programlarının ve departmanlar arası kaynak paylaşımının daha iyi yönetilebilmesi.

- Şirketin stratejik, taktik ve operasyonel seviyede aldığı kararların bilgisiz fikirlerden çok bilgi temelli fikirlere dayanmasını sağlamak.

- Şirkette bilgi şeffaflığını artırmak.

- Performans ölçümlerinin daha sağlıklı olmasını sağlamak ve sorunlar konusunda sahiplenme sorunlarını iyileştirmek.

- Sorun oluşan konuların erken fark edilmesini sağlamak.

- Olası kar modellerinin erken ve daha iyi anlaşılmasını sağlamak, böylelikle fırsat süreci kapanmadan faydayı ençoklamak.

- Konsol ve karne gibi izleme sistemleri ile işi doğru izlemek ve işin izlendiği bilincini tüm şirkette oturtmak.

- Finansal başarıyı sağlayan müşteri, üretim ve insan kaynakları kriterlerini belirleyerek finansal sonuçlar gibi ardıl ölçütlerin yanısıra bu tür öncül ölçütleri de denetim altında tutabilmek.
...

Bu liste daha çok uzayabilir. Ama sanırım bir fikir verecek seviyeye gelmiştir.

PROJE RİSKLERİ

- Kullanıcıların güvenini kazanamamak. Haklı ya da haksız olarak iş zekası sisteminin yanlış sonuçlar verdiği düşüncesi yayılırsa proje ölü doğmuş olabilir.

- Kullanıcıların alışkanlıklarını değiştirememek. Eski sistemlerini daha rahat bulan kullanıcılar yeni sistemin getirdiği faydalardan yararlanmayabilir. Kullanılmayan bir iş zekası sistemi yok hükmündedir.

- Projenin çok uzun süreli ve çok kapsamlı olarak ele alınması, sürümlü yaklaşıma gidilmemesi sonucu bir türlü bitmeyen canavar bir projeyle başbaşa kalmak.

- Projenin başarılı olması durumunda ortaya çıkaracağı birtakım rahatsızlık verici gerçekleri öngörememek ve bunların hazmedilebilmesi için şirket yönetiminde gerekli hazırlıkları yapmamak. (Örneğin örtülü ve küçük çaplı birtakım yolsuzlukların ortaya çıkması...)

- Bilginin kolay ulaşılmasının getireceği fazladan güvenlik sorunlarını öngörememek. Yanlış kişiler yanlış bilgilere çok kolaylıkla ulaşır hale gelebilir.

- İş zekası sistemini şirket çapında bütüncül bir yapı gibi öngörmek yerine, departman bazlı ve birbiriyle ilişkisiz küçük iş zekası adacıkları oluşturmak. Bu durum, iş zekasının pek çok faydasını sıfırlayacaktır.

- Raporlama ve analiz alanında çalışan insanların kendilerinin daha kalifiye analize yöneleceklerini fark edememeleri, aksine işlerinden olacakları, işlerinin tamamen otomatikleşerek kendilerine gerek kalmayacağı fikrine kapılmaları ve projeye direnmeleri sonucu hatalı, yanlış ya da eksik sistemlerin ortaya çıkması.

Risklerle ilgili olarak da yukarıdaki liste tabii ki tüm riskleri 'tüketen' konumunda değil. Ama yine fikir vermek açısından iyi bir başlangıç olduğunu düşünüyorum.

PROJE VARSAYIMLARI

Bir projede dikkatle ele alınması gereken çok önemli bir konu varsayımlardır. Varsaymak anlamındaki ASSUME kelimesiyle ilgili İngilizce'de şöyle bir anlam da verilir: make an ASS of U and ME. Türkçesini burada yazmayacağım. Ama varsaymanın ne kadar sakıncalı olabileceğiyle ilgili önemli bir uyarı olarak aklınızda kalsın.

Varsayımlarla ilgili sorun şudur: Yanlış olabilirler.

Bir varsayımı veri olarak kabul edip sonraki yaklaşımlarınızı ona göre geliştirdiğiniz için sıkıntılı durumlara düşebilirsiniz sonradan.

Şunu düşünün: Şirkette iş zekası projesine başlayacaksınız, o ana kadar sürekli Microsoft ürünleri kullanılmış durumda. Ama iş zekasına yeni giriyor şirket. Microsoft ürünleriyle devam edileceğini varsayıp ona göre bir proje hazırlığına girişiyorsunuz, ama üst yönetim projenizle ilgili hazırlık sunumunu yaparken böyle bir seçim yapılmış olduğunu nereden çıkardığınızı soruyor. Öğreniyorsunuz ki, daha önce yapılmış tüm yatırımlarda hangi teknolojinin kullanılacağı da proje kapsamında incelenerek karara varılmış. Burada da Microsoft teknolojileri kullanılabilecek olduğu gibi belki başka teknoloji de kullanılabilecek. Proje kapsamında bunun da incelenip karara bağlanması gerekiyor.

Varsayımlar hakkında bir liste vermek pek mümkün değil. Şirketin kendine özgü şartları çok etkili çünkü bu alanda. Ama birkaç tehlikeli varsayım örneği verebiliriz:

- Kullanıcıların sisteme büyük bir hevesle atlayacağını varsaymak. Oysa çoğu durumda onlara projenin 'satışını' yapmak gerekir.

- Ekibin becerisinin bu konuda yeterli olduğunu varsaymak, hazırlıkla ilgili yeterli öngörüde bulunmamak. İş zekası projeleri disiplinler arası projelerdir. Çoğu durumda yakın projeler yapmış kişilerin bile bakış açılarında önemli değişiklik yapmayı gerektirirler.

- IT kaynakları ve IT liderliğinin başarılı bir iş zekası projesi için yeterli olduğunu varsaymak. Oysa değildir. İş zekası projelerinin sahibi iş tarafı olmalıdır. Tabii ki IT'nin büyük desteği, emeği ve mesaisi gerekir. Ama işin sahibi IT olmamalıdır.

PROJE BAŞARI KRİTERLERİ

Bir iş zekası projesinin başarı kriterleri teknik ya da işle ilgili olmak üzere iki grupta ele alınabilir.

Hangi gruptan olursa olsun, her başarı kriterinde zaman bağlamının da olması çok önemlidir.

Teknik başarı kritelerlerine örnek olarak birkaç şey sayalım:

- Proje kapsamının x ayda tamamlanması- x, y, z raporlarının t günde eski sistemden yeni sisteme sorunsuz hale çalışır halde aktarılması.

- Daha önceki ortamda alınamayan t1, t2 raporlarının yeni sistemde alınır hale getirilmesi ve z ayda iş süreçlerinde etkin olarak kullanım alışkanlığının geliştirilmesi.

Asıl iş tarafındaki başarı kriterlerine göz atalım:

- x ay içinde, şirket için karlılık ölçütlerine göre müşterilerin sıralanabilir hale gelmesi.

- x ay içinde, gereksiz masraf kalemlerinin yakalanması yoluyla satışların maliyetlerinin yüzde y düşürülmesi.

- x ay içinde büyüme potansiyeline sahip bayilerin temel belirleyici özelliklerinin belirlenmesi ve bu profile uyan bayilere yönelik özel satış programı geliştirilmesi.

Gördüğünüz gibi business hedefleriyle olayı ele aldığınızda işin sahibinin neden IT değil de business olması gerektiği net bir şekilde ortaya çıkıyor.

DEĞİŞİM YÖNETİMİ

İş zekası projeleri bitmez. Başarılı iş zekası projeleri sürekli yeni isterlere sebep olur ve yeni fazlarla yaşamlarına devam ederler.

Bu durumda iş zekası projelerini sürümlü olarak ele almak ve sürüm sürelerini kısa tutmak faydalı olacaktır. Benim önerim bir faz için 4 ila 6 aylık bir süre öngörmek yönünde.

Öte yandan iş zekası projeleri çok dinamiktir ve iş kraldır. Bu durumda projenin akışına zarar vermeyecek şekilde iş taraflarının isterleri çok önemlidir.

Bir başka önemli gerçek ise, değişimi yönetemeyen bir projenin asla başarılı olamayacağı.

O zaman değişim yönetimi konusunda önerimiz nedir?

Kesinlikle ilkeleri önceden belirlenmiş bir değişim yönetimi süreci bulunmalıdır. Her faz için kapsam dışı bırakılmış unsurları kapsama almakta isteksiz davranmakta fayda var. Özellikle sürüm aralıkları yeterince kısa tutulduysa bu tür istekler sonraki sürümlere ertelenmelidir.

Projenin ilgili fazında hata, yaklaşım farkı gibi konuları ilgilendiren değişim istekleri ise çok daha istekli ele alınmalıdır. İş tarafının işine yaramayacak, iş zekasına inançlarını sarsacak, yanlış, eksik bir şey sunmayı hiçbir zaman istemeyiz.

Hazırlık üzerine...

2009-06-30T00:21:00.001-07:00

Benjamin Franklin der ki:
"By failing to prepare, you are preparing to fail."

Hazırlanmakta başarısız olmakla, başarısızlığa hazırlık yapmış olursunuz. (Bu kulağa hoş gelen çevirisi)

Hazırlanmayı ihmal etmekle, başarısızlığa hazırlık yapmış olursunuz. (Bu da vurgusu biraz azalmış ama anlam olarak daha doğru bir çeviri)

İşin zaman boyutu

2009-06-22T04:24:00.000-07:00

İş zekası sistemlerinde herhangibir veriye baktığımız ilk boyut zamandır. Zaman boyutu olmadan herhangi bir şeyin ölçümü anlam taşımaz.

Basitçe iki inşaat firmasını düşünün. Binalarını tamamen aynı birim fiyatlarla üretebiliyor ve satabiliyor olsunlar. İkisinin de eleman ve müşteri derdi yok. Ama bir tanesi daha iyi organize olabiliyor ve bir binayı üretip satma süresi bir yıl. Diğeri ise aynı binayı iki yılda üretip satabiliyor. Tamamen aynı maliyetlerle ve aynı fiyatlarla çalışan iki firmadan bir yılda işi bitirebilen diğerininin iki katı para kazanıyor ve kar ediyor olacaktır.

David A. J. Axson, Best Practices in Planning and Performance Management adlı kitabında zaman bazlı rekabetin bileşenlerini listelemiş. O listeyi buraya tercüme ederek aktaracağım. Bakın bir şirketi 'bitirebilecek' zaman bağlamında ne tür rekabet unsurları var:

- Yeni ürün ve hizmetlerin kavramdan gerçeğe dönüştürülme süresi
- Ürün ve hizmetlerin müşteriye sunulabilme süresi
- Hesap (dönem) kapatma süresi
- Yeni elaman alma süresi
- Yeni eleman sahaya alma süresi
- Yeni elemanın tam üretkenliğe erişme süresi
- Anahtar kararların alınma süresi
- Büyük işlerin (satış, proje vb) bitirilme süresi
- Ekipman ve ürünlerin yararlı ömürlerini bitirme süresi
- Satın almaları bünyeye entegre etme süresi
- Rekabetçi eylemlere karşılık verebilme süresi
- Yeni teknoloji yatırımlarından değer üretebilme süresi
- Yeni bir pazara girme süresi

Project Server 2007'de bir kuyruk sorunu ve çözümü

2009-06-19T00:26:00.000-07:00

Project Server 2007, 2003'e göre önemli bir yenilik olarak kuyruklama sistemini getirdi. Performans algısı açısından önemli bir fayda sağlanmış olsa da bazı konularda karışıklık seviyesi de yükselmiş oldu.

Yaşanan önemli sorunlardan biri, bazı durumlarda bazı job'ların "getting queued" durumunda takılı kalması. Bu joblar belirli bir projeyle ilgili olarak sonraki jobların da yapılmasını engelleyebilir. İlgili projenin checked out durumda kalmasına sebep olabilir. Hatta admin olarak force check-in yapmaya çalıştığınızda bile kuyruktaki iş yüzünden force check-in'i gerçekleştiremeyebilirsiniz.

İki önemli soru var:
1. Bu durumu yaşadığımda sorunu nasıl aşabilirim?
2. Bu durumun sebebi nedir? Tekrar oluşmasını nasıl engelleyebilirim.

Birinci sorudan başlayalım. Sorunu çözmek için "getting queued" durumunda takılı kalan job'ı iptal etmelisiniz. Ama bunu normal ayarlarla yapamazsınız. Aşagıdaki yolu izlemeniz gerekir:

Project Web Access Server Settings sayfasında, Queue bölümünde Manage Queue'yi tıklayın.
Gelen sayfada Advanced Options bölümünü açın.
Advanced Options bölümünde Cancel jobs getting enqueued seçeneğini seçili hale getirin.

Bu işlem, bu tür işlerin iptal edilebilmesi için gereklidir.

Daha yukarıdan hangi zaman aralığındaki işleri görüntüleyeceğinizle ilgili kısımda da kuyruğa alınırken takılı kalmış işi görecek şekilde tarih aralığını değiştirmeniz gerekebilir.

Bu işlemleri yaptıktan sonra "getting enqueued" durumundaki işi seçip 'cancel' edebilirsiniz.

Aslında cancel etmeden önce denenecek bir şey daha var. Ama bunu anlatmak için ikinci ana sorumuza gelmemiz gerekiyor: Bu tür sorunlar nasıl oluşur ve nasıl tekrar oluşmamalarını sağlayabiliriz?

Bir işin bu durumda olmasının sebebi şudur: Kuyruk işlenecek bir işi almak üzere bilgilendirilmiştir ama yapılacak iş için gerekli tüm veriyi henüz alamamıştır. Bu yüzden de işi kuyruklama konumunda beklemektedir. Mesela büyük, satır sayısı ve custom alanları fazlaca olan bir proje kaydedilmeye başlamış olabilir. Ama kullanıcı kayıt işlemi yüzde yüz bitmeden project professional'ı kapatmış ya da server ile bağlantıyı kesmiştir. Bu durumda kayıt işlemi kuyruklanmaya devam etmektedir, henüz tamamlanamamıştır. Böyle bir işi yukarıda belirttiğimiz gibi cancel etmeden önce ilgili istemciyi sunucuya tekrar bağlayarak işin bitmesini sağlamaya çalışabilirsiniz. Bunu yapamıyorsanız, cancel yoluna gitmelisiniz.

Tekrar bu durumla karşılaşmamak için, kullanıcılarınız status bar'ı kontrol etmeyi alışkanlık haline getirmeli. Project Professional'ın status barında kuyrukla ilgili bilgiler görülür. Kaydetme gibi sunucuda kuyruklama ile yapılan işlerde işin yüzde yüz bittiğinden emin olmadan bağlantınızı kesmeyin.

Veri madeninde ve analysis services kübünde many to many dimension uygulaması

2009-06-15T00:35:00.000-07:00

Fact tabloları ile boyutlarımız arasında çoğunlukla 'regular' ilişkiler vardır. Ama bazen regular ilişkiler yeterli olmaz, farklı yaklaşımlar gerekir. Bu yazıda o ilişki tiplerinden biri üzerinde duracağım: Many to many dimensions yani çoklu ilişkili boyutlar.

Örneği basit alacağız ki konuya odaklanabilelim. Bu yüzden anlatacağım örnekte slowly changing dimension gibi kavramları da yok sayacağım. Bunun bütüncül bir örnek olmadığını unutmayın. Tüm amacımız many to many dimension'ın net bir örneğini görmenizi sağlamak.

Öncelikle ele alacağımız problemi ifade edelim: Bir hastane için hastalara yapılan işlemleri ve bunların tutar bilgilerini analiz etmek istiyoruz. Analizimizin önemli bir konusu da işlemi hangi doktor ya da doktorların yapmış olduğu. Tek bir doktor da işlem yapabilir bir grup doktor da. Yani işlemlerle hastalar arasında regular bir ilişki varken işlemlerle doktorlar arasında çokluya çoklu (many to many) bir ilişki var.Kurmamız gereken veriambarının basit tasarımı yukarıdaki gibi. Her hastanın bir id'si ve adsoyadı var. Her doktorun da bir id'si ve ad soyadı var. Hasta işlemleri fact'i hasta boyutuna doğrudan bağlı. Bu fact'te doktor bilgisini ise tutmuyoruz. Yani hangi doktorun işlemi yaptığına dair bilgi işlem fact'inde yok. Bunun yerine işlem facti ile doktor boyutu arasına ikinci bir fact olacak olan bir ara köprü tablosu koyuyoruz. Bu tablo hem işlemle hem doktorla ilişkili ve iki foreign key kolonunu birlikte primary key olarak kullanıyor.

Şimdi bu tablolara örnek kayıtlar ekleyelim. Ben 1. Doktor1, 2. Doktor2, 3.Doktor3 olarak doktor kayıtlarını ve 1.Hasta1, 2.Hasta2, 3.Hasta3 olarak hasta kayıtlarını ekledim.

İşlem tablosunun verileri şöyle:

İşlemID / HastaID / Tutar
1 1 100
2 2 200
3 3 300
4 1 500
5 1 800

İşlem Doktor'un verileri ise şöyle (Facthastadoktor isimli tablo. Aslında işlemdoktor deseymişim daha uygun bir isim olacakmış. İdare edin artık :) ):

İşlemID / DoktorID
1 1
2 2
3 3
4 1
4 2
5 1
5 2
5 3

İlk 3 işlemi birer doktor yapmış. 4 nolu işlem Hasta1'e 2 doktor tarafından yapılmış. 5 nolu işlem Hasta3'e 3 doktor tarafından yapılmış.

Şimdi bunun küp sisteminde görünümüne bakalım. İki temel yer var bakacağımız: Dimension usage ve datanın görünümü: Gördüğünüz gibi ara tablomuz da bir measure group olarak yapılandırılmış. Bunun da bir fact olduğunu söylemiştik. Ayrıca hasta işlem fact'indeki işlem id de bir boyut olarak yapılandırılmış. Bu özel bir boyut. Verisini factteki bir kolondan alıyor. Buna Kimball degenerate dimension, Microsoft ise fact dimension der. Daha önceki yazılarımda bahsettiğimi hatırlıyorum. Kısaca söylemek gerekirse, bağlı olduğu tüm attribute'ler başka boyutlara dağıldığı ve fact satırlarıyla ilişkisi de bire bir ya da birebire yakın olduğu için bu özel boyutun verisini fact'te bırakırız.
Bizim için şu an kritik olan nokta, dim doktor ile fact hasta işlem arasında fact hasta doktor measure grubu üzerinden many to many ilişki oluşturulmuş olması.
Peki böyle bir küp bize nasıl bir veri görünümü sunuyor:Genel toplamların doğru olduğuna da dikkat edin lütfen.
Doktor1'in dahil olduğu hasta1 tutarları 1400. Ama doktor1 zaten hasta1'in tüm tutarlarına dahil olmuştu. Bu yüzden hasta1'in toplam tutarı da 1400.

Bu veri ambarından küp oluştururken ne yapmak gerekli?

AS projenizde data source ve data source view'i oluşturun. Dört tabloyu da alın view'e. Sonra new cube diyerek wizard'ı başlatın. Fact olarak her iki tabloyu seçin. Wizardın kalan adımlarında hiçbir değişiklik yapmayın. (Wizard bittikten sonra fact boyutunun isminiuygun bir şekilde değiştirebilirsiniz.)

Bu kadar. Sonuç yukarıdaki gibi olacaktır.

SQL 2008 upgrade webinarı

2009-04-22T01:47:00.001-07:00

Bugün 15.00'te SQL 2008'e upgrade ile ilgili bir webinar (web semineri) veriyorum.

Seminerde de referans vermek üzere birkaç bağlantı noktasını burada aktarmak istiyorum:

Scalability Experts'in Upgrade Assistant'ıyla ilgili giriş ve indirme sayfaları:

http://www.scalabilityexperts.com/default.asp?action=article&ID=43
http://www.scalabilityexperts.com/default.asp?action=article&ID=45

Upgrade Assistant'ın kullanımı biraz karışık. İndirme sayfasında nasıl kullanılacağına ilişkin doküman da var. Ama yine de Türkçe bir özet görmek isterseniz:

http://mustafaacungil.blogspot.com/2008/05/sql-2008e-upgrade-ediyoruz.html

Türkçe özeti tek başına kullanmayı denemeyin. Sadece tamamlayıcı nitelikte bir açıklama var o yazımda. Upgrade Assistant'ı ve dokümanının indirdikten sonra, onları kullanırken takılabileceğiniz noktalara destek amacıyla bu yazıyı kullanabilirsiniz.

Sistem tablolarını, metadata ile ilgili fonksiyonları, görünümleri vb kullanmak gibi özelleştirme işlerine girmişseniz, ya da veritabanı motoru haricinde diğer servisleri de kullanıyorsanız, pek çoğunda en az birkaç tane 'breaking change' bulunduğunu dikkate almanız gerekir. Büyük olasılıkla bunların pek çoğu sizi hiç etkilemeyecektir, ama bir tanesi bile etkiliyorsa, kodunuzda birtakım (az ya da çok) değişiklikler yapmanız gerekebilir.

Bu 'kıran değişikliklerin' yani 'breaking change'lerin neler olduğunu öğrenmek için SQL Server 2008 Books Online'ı açın ve indekste 'breaking changes' yazın. Farklı servislerle ilgili girdiler çıkacak karşınıza, sizi ilgilendirenleri inceleyin.

Bir başka önemli araçsa, Upgrade Advisor. Upgrade Assistant çok daha yetenekli, ama Upgrade Advisor'ı da kullanmak istersiniz. Upgrade Advisor'un kullanımı ile ilgili olarak da SQL Server 2008 Books Online'da indekste 'Upgrade Advisor' yazdığınızda geniş bilgi olan bir sayfaya ulaşıyorsunuz. Başlangıç noktası olarak bu sayfayı inceleyin.

Project Professional'da kazayla kısıt oluşturmak

2009-04-20T02:35:00.000-07:00

Projenizdeki bazı görevlerin standart ilişkiler dışında da zaman bağlamında kısıtları olabilir. Mesela bir görev kendisinin öncülleri daha önce bitse bile belirli bir tarihten önce başlayamayacak olabilir. Bu durumda Start No Earlier Than kısıtı oluşturursunuz. Ya da bir görevin belirli bir tarihten sonraya kalmaması gerekiyordur ve Finish No Later Than kısıtı oluşturursunuz.

Bu iki tür kısıt yarı esnek kısıtlar sınıfındadır. Yarı esnektirler çünkü bir uçtan bağlıyken diğer uçtan bağlamamış olurlar.

Ancak bu kısıtları kazara da projenize ekleme olasılığınız var. Hem de hayli yüksek bir olasılık!

Eğer projenin başlangıç ya da bitiş tarihi görülen bir tablodaysanız ve niyetiniz bu olmadığı halde bu tarihlerden birini elle girerseniz, bu kısıtlardan birini oluşturmuş olursunuz.

Benzer şekilde gant diyagramında bir görevin çubuğunu sürükleyerek tarihini değiştirirseniz, yine bu kısıtlardan oluşturmuş olursunuz.

Küçük bir hareket, bazen beklenmedik sonuçlar doğurabilir. Dikkat etmenizde fayda var.

Project Professional takvimleriyle ilgili bir uyarı

2009-04-20T01:09:00.000-07:00

Project Professional'da bazı hatalar vardır ki, bu hataları yaparsanız kafanız fena halde karışabilir. Aslında sadece hatalar değil, bazen programın çalışma mantığıyla ilgili eksik teorik bilgiler de kafa karışıklığına sebep olabilir.

Kafa karıştırıcı hatalara bir örnek verelim:

Tools -> Options -> Calendar yoluyla eriştiğiniz sekmeden, gündeki saat sayısını ve haftadaki saat sayısını değiştirebilirsiniz. Böylelikle mesela 1 günlük iş girdiğinizde bunun 8 saat olduğunu, ya da 1 haftalık iş girdiğinizde bunun 40 ya da 45 saat olduğunu Project Professional bilebilir.

Benzer bir ayarı da standart proje takviminiz için yapabilirsiniz. Burada da günlük çalışma zamanı ve haftalık çalışma zamanını ayarlarsınız.

Eğer bu iki ayar birbiriyle çelişiyorsa, fena halde karışık zaman çizelgeleri oluşabilir.

Mesela düşünün ki, iş kanunundan yola çıkarak bir haftayı options'da 45 saat olacak şekilde girdiniz. Böylece hafta deyince 45 saat olarak algılar Project Professional. Ama belki de takvime girdiğiniz fiili çalışma saatleri haftada 40 saate denk geliyor. Bu durumda hafta birimiyle girdiğiniz işlerin takvime yansıması beklemediğiniz şekilde olabilir.

Bir de Project Server'daki kurumsal takvim ayarları devreye girince, bu tür karışıklıklar yapma ihtimaliniz daha da artar. Çünkü proje dosyanızın yerel takvimlerini değil, Server'ın takvimlerini kullanmanız gerekir. Server'ın takvimlerini kullanmaya geçmezseniz, yine kafa karıştırıcı sorunlar ortaya çıkmaya başlayabilir. Mesela kurumun kurumsal takvimine işlenmiş bir kurum özel gününden kaynaklanan tatil, sizin yerel takviminizde yer almıyor olabilir...

Proje yönetimi denince, sadece araçlara güvenmeyin. Project Professional ya da ve hatta Project Server sadece birer araç. At sahibine göre kişner. At binmeyi iyi bilmiyorsanız, at ne yapsın!

XML'i XML mi tutmalı nvarchar(max) mı?

2009-04-06T02:18:00.001-07:00

SQL 2008 için konuşuyorum. Diyelim ki XML veri tutmanız gerekiyor. Acaba bunu veritipi XML olan bir kolonda tutmakla nvarchar(max) olan bir kolonda tutmak arasında depolama alanı açısından bir fark var mıdır?

Vardır. Hem de esaslı bir fark vardır.

XML dokümanları çoğu zaman etiket yoğunluğu fazla dokümanlardır. Pek çok uzun etiket, pek kere tekrar eder doküman içinde. Eğer nvarchar(max) olarak tutarsanız, bu tekrarlar önemli bir depolama alanına mal olur. Ama XML tipinde tutarsanız işler biraz değişir. Çünkü XML tipi veriyi gereksiz tekrarlardan soyduktan sonra arka planda varbinary olarak tutar. Yani tekrar eden etiketleri aradan çıkarır, dokümanı sıkıştırır...

Ortalama bir XML dokümanında, XML tipi kullanmak varchar(max) kullanmaya göre yüzde 70'lere varan veri büyüklüğü tasarrufu sağlayabilir.

SQL Server Cluster ve Mirror çözümleri hakkında bir lisanslama uyarısı

2009-04-03T04:48:00.000-07:00

SQL Server Cluster ve Mirror çözümlerinde lisanslama ile ilgili çok güzel bir avantaj sunuyor:
Cluster'da pasif node olarak ya da Mirror'da mirror olarak kullandığınız sunucu için SQL Server lisansına ihtiyacınız yok. Çünkü bir anda sadece birisi aktif olarak kullanılıyor.

Bu çünkü önemli! Eğer yedekteki node'da her hangi bir şekilde data erişimi yapıyorsanız, mesela mirror'a shapshot koyup oradan sorgulama yapıyorsanız ya da pasif node'da Reporting Services gibi bir servis çalıştırıyorsanız, sınır dışına çıkmış oluyorsunuz. Yani bu durumda ikinci node için lisans ihtiyacı oluşuyor.

Bilginize! Tam olarak lisansa uygun kullanıyorum sanıyorken, lisans dışı bir durumda bulmayın kendinizi.

SQL Server 2008'de persisted columns

2009-04-03T04:44:00.000-07:00

Karmaşık fonksiyonlarla oluşan birtakım değerleri her seferinde hesaplamak istemeyebiliriz. Eskiden bu tür hesaplanmış kolonlara sahip olan tablolar için hesaplanmış kolon üzerinde indeks tanımlayabiliyorduk. Şimdi daha da verimli çalışan bir yöntem var: Kolonu 'persist' etmek.

Tabloya eklediğimiz hesaplanmış (computed) kolonun tanımının sonuna PERSISTED kelimesini ekliyoruz. Böylece insert ya da update sırasında hesaplanan değer doğrudan fiziksel olarak kolona kaydedilip tutuluyor. Kullanımı çok basit. Siz değer vereceğinize mesela nasıl ki default bir değer fiziksel olarak tabloya yazılıyorsa, bu da öyle yazılıyor.

Hoş.

SQL Server 2008'de filtrelenmiş indeksler

2009-04-03T03:32:00.000-07:00

Bazı kolonlar indeks kullanıp kullanmamak konusunda bizi şüphede bırakır.

Şöyle bir durum düşünün:

Müşterilerinizi tuttuğunuz bir tablo var. Bir kolonda da şehir bilgisi var. Müşterilerinizin yüzde 60'ı İstanbul'da, yüzde 20'si Kocaeli'de, kalan yüzde 20 ise 30-40 ile birbirine yakın oranlarda dağılmış durumda.

İstanbul ya da Kocaeli dışındaki illerdeki müşteri oranınız yüzde 1'in altında olacaktır. Bu illerle ilgili şehre göre kısıtlama getiren sorgular, şehir alanında bulunacak bir nonclustered indeksten fayda sağlayabilir. Ama kayıtların yüzde 80'ini içeren İstanbul ve Kocaeli müşterileri için indeksin faydası değil zararı olur. Hem sorgu kısıtında bu şehirlerin geçmesi durumunda indeksten yararlanılmayacak hem de bu büyük kütlede yaşanacak değişiklikler bu indeksi de etkileyebilecektir.

İndeksi oluştururken filtre kullanabilme imkanımız, bize İstanbul ve Kocaeli dışındaki kayıtlar için şehir kolonunda nonclustered indeks oluşturma imkanı sağlar.

Hoş bir özellik. Büyük kısmı null olan kolonlarda sadece null olmayan değerleri indekslemek için de aynı özelliği kullanabilirsiniz.

Bir başka kullanım ise kayıtların sadece ilgi çeken bölümünü indekslemek olabilir bu teknikle. Yine müşterilerle ilgili kredi puanı kolonu olduğunu düşünün. Diyelim ki sorgularınız -her nedense- kredi puanı 0 ila 20 arasında olan müşterilere odaklanıyor. Kredi puanı kolonunu sadece bu aralıktaki değerler için indekslemeniz düşünülebilir.

Performance Counter'ları doğrudan T-SQL'den sorgulamak ister misiniz?

2009-04-01T03:35:00.000-07:00

SELECT *
FROM sys.dm_os_performance_counters
WHERE object_name = 'SQLServer:Deprecated Features'

Bu sorguda iki ilginç yön var:

Birincisi, sys.dm_os_performance_counters dynamic management view'ini kullanarak performance counterları artık T-SQL'den kolayca sorgulayabiliyorsunuz. (Management Warehouse uygulaması ile birlikte çok enteresan imkanlar doğurabilir.)

İkincisi ise, Microsoft'un artık bunları kullanmayın diye ilan ettiği SQL Server özelliklerini kullanıp kullanmıyor olduğunuzu performance counterlar üzerinden takip etmeniz mümkün.

Sorguyu bir çalıştırın, bakın neler var neler...

SQL Server 2008'de Query Plan'ları görmek istiyorsanız...

2009-04-01T02:54:00.000-07:00

Diyelim ki, SQL Server'ın cache'indeki query planları görmek istiyorsunuz.

Şu sorguyu deneyin:

SELECT p.query_plan
FROM sys.dm_exec_cached_plans
OUTER APPLY sys.dm_exec_query_plan (plan_handle) p
WHERE plan_handle IS NOT NULL

Eğer cache'dekileri değil de o an aktif talep olan sorguların planlarını görmek istiyorsanız:

SELECT p.query_plan
FROM sys.dm_exec_requests
OUTER APPLY sys.dm_exec_query_plan (plan_handle) p
WHERE plan_handle IS NOT NULL

Gün gelir lazım olur. Temel bilgiler: sys.dm_exec_query_plan verilen bir plan handle'ı için xml olarak sorgu planını veriyor. XML'i tıklayınca da Management Studio planı size görsel olarak gösteriyor.

Bu fonksiyona plan_handle verebilecek üç adet dinamik yönetim görünümü var. İkisini zaten yukarıdaki sorgularda gördünüz. Bir diğeri de dm_exec_query_stats.

Onunla ilgili de mesela şöyle bir sorgu çok işinize yarayabilir:

SELECT p.query_plan
FROM sys.dm_exec_query_stats s
OUTER APPLY sys.dm_exec_query_plan (plan_handle) p
WHERE plan_handle IS NOT NULL and s.max_elapsed_time > 1000000

İstatistiksel olarak belirli eşiklerin üzerinde olan sorguların planlarını çat diye bulmak hoş olsa gerek....

SQL Server 2008'de bir nesne üzerinde en son ne zaman ALTER yapıldığını bulmak

2009-04-01T01:53:00.001-07:00

Mesela bir tabloda en son ne zaman ALTER yapıldığını bulmanız gerekiyor. Ya da belki bir procedure ya da view'de...

Bunu bulmak artık çok kolay. sys.objects ve diğer pekçok sistem görünümü (view) artık modify_date bilgisini içeriyor. İlgili sistem görümünden bu kolonun değerine bakmanız yeterli.

SQL Server 2008'de değişken atamalarına ilişkin birkaç küçük yenilik

2009-04-01T01:15:00.000-07:00

SQL Server'da şu kod çalışır mı?

declare @i int = 5
print @i
set @i+=1
print @i

Eğer SQL Server 2008 kullanıyorsanız sorun yok. Sırasıyla 5 ve 6 değerlerini veriyor.

varchar(max) ve benzerlerinin farkında mısınız?

2009-04-01T00:41:00.000-07:00

SQL 2000'de 8000 byte'a sığmayan kolonlar için TEXT ya da IMAGE gibi veritiplerini kullanmanız gerekiyordu.

Artık onlar yerine varchar(max), nvarchar(max) ya da varbinary(max) var. Bu veritiplerini kullanmak çok daha kolay. Çünkü normal bir karakter ya da binary kolonmuş gibi işlemler yapabiliyorsunuz kodunuzda.

Peki ya gerçekten çok büyük bir varchar(max) değerle uğraşmanız gerekirse? Mesela 2 GB'a yaklaşan bir metin? Bu durumda normal kullanım pek hoş olmaz. Çok yük getirir. SQL 2000'de kullanılan READTEXT, WRITETEXT gibi fonksiyonları kullanmayı aramaya başlayabilirsiniz. Ama merak etmeyin, aramanıza gerek yok bunları...

Böyle bir kolonun belirli bir parçasını okumak istiyorsanız, basitçe substring fonksiyonunu kullanmanız yeterli. Yok eğer içinde belirli bir offset'e yazmanız gerekiyorsa, update ifadesinde set <(max)column>.WRITE sintaksını kullanabilirsiniz. Buradaki WRITE parametre olarak, ne yazacağınızı, hangi offsetten başlayacağınızı ve byte sayısını alıyor.

Her zaman olduğu gibi detaylı uygulamasını yazmıyorum. Boşuna çaba olur. Books Online'da rahatlıkla buna ulaşabilirsiniz. Benim sağlayacağım fayda, böyle imkanlarınızın olduğunu duyurmak...

SQL Server 2008'de Time tipiyle ilgili küçük bir uyarı

2009-03-31T03:46:00.001-07:00

SQL Server 2008'de date ve time bilgilerini ayrı tiplerde tutmanız mümkün.

Eskiden sadece tarih bilgisine ihtiyaç duyup saat kısmına gerek duymuyorsanız ya da sadece zamana ihtiyaç duyup tarih kısmına ihtiyaç duymuyorsanız bile datetime tipi kullanmak zorunda idiniz. Bu da gereksiz yere alan işgali ve kırpmayla ilgili yazılacak kodlar anlamına geliyordu.

Şimdi date ve time diye ayrı ayrı veri tipleri var. Sadece tarih tutmak için date tipini, sadece zaman tutmak için time tipini kullanabilirsiniz.

Hem veritabanında 6 yerine 3 byte kullanarak hem de gereksiz kırpma kodlarını yazma zorunluluğundan kurtulduğunuz için yeni uygulama faydalı.

Ancak dikkat edilmesi gereken bir detay var: Time tipinin kapladığı yer değişken, 3 ila 5 byte yer kaplayabiliyor. Bunu belirleyen hangi detayda bilgi tuttuğunuz. Saniyenin kaçta birini tutmak istersiniz? Hassasiyetiniz bir saniyeden 100 nanosaniyeye kadar değişiklik gösterebilir.

Değişken tipini belirlerken time(n) tipiyle yapıyoruz bu işi. Mesela time(3) için 4 byte, time(5) için 5 byte kullanmaya başlayabiliyor. Eğer bu kadar hassas olmak istemiyorsanız, boş yere time(2)'den daha hassas kullanıp boşuna byte'larınızı harcamayın.

Küçük bir not: Benzer bir kaygıya datetimeoffset(n) ve datetime2(n)'i kullanırken de sahip olmalısınız. Buralarda da n'de belirttiğiniz hassasiyete göre 2 byte'a kadar tasarruf etmeniz mümkün.

SQL 2008'de de full text indekslerde Türkçe desteği yok...

2009-03-31T01:44:00.000-07:00

Ne yazık ki!

select * from sys.fulltext_languages sorgusu ile full text indekslerde desteklenen dilleri öğrenebilirsiniz. Listeyi görünce benim gibi siz de isyan edeceksiniz muhtemelen. Çince gibi zor diller var. Ekonomisi ve nüfusu bizden çok daha küçük sürü sepet dil var.

Peki neden Türkçe desteği yok? Aslında biraz dilimizin yapısıyla ilgili. Bizim dilimiz eklemeli bir dil. İndekslemek açısından hayli zor. Çekoslavakyalılaştıramadıklarımızdan mıydınız? ifadesi zorluğu yeterince ortaya koyabiliyor olsa gerek.

Kısacası, teknoloji dilimizin yapısına uyum sağlamakta henüz yeterince gelişmiş değil gibi görünüyor.

Ufak bir ekleme: Full text indeksleri Türkçe kolonlarda yine de kullanabilirsiniz. Sadece ileri bazı sorgu imkanlarını yeterince verimli kullanmanıza engeldir Türkçe desteğinin olmaması.

Management Studio'da SQLCMD mode

2009-03-30T05:09:00.000-07:00

SQLCMD scriptleri kullanmak bazı durumlarda bir hayli işe yarayabiliyor. Ama bu scriptleri SQLCMD'nin komut satırı ekranında yazmak biraz sıkıntılı.

Bunun yerine Management Studio'da SQLCMD sorguları yazabilirsiniz. Tek yapmanız gereken Query menüsünden SQLCMD mode'unu seçmek!

SQL 2008'de Agent jobları için ortak schedule

2009-03-30T03:44:00.000-07:00

SQL Server 2008'de gelen küçük ama bazılarımızın gündelik hayatında çok etkili olabilecek bir yenilik var.

Veritabanı yönetiminin otomasyonunda SQL Server Agent jobları temel bir göreve sahiptir. Bu joblara schedule belirtebiliriz, böylelikle istediğimiz işin yapılması istediğimiz zaman tetiklenir. Zamanlanacak işlerimiz genelde onlarcadır. Ve bunların belirli ritimleri vardır. Mesela her gece çalıştırdıklarımız, her sabah çalıştırdıklarımız, her ay kapanışında çalıştırdıklarımız...

Eskiden aynı zamanlamaya sahip olması gereken jobların her birinin zamanlamasının ayrı ayrı birbirinin aynısı olacak şekilde ayarlanması gerekirdi. Bu durumda bir değişiklik gereğinde de hepsini tek tek değiştirmek gerekirdi. Oysa şimdi, aynı hesap tarafından sahip olunan job'larda ortak schedule kullanılabiliyor. Job'ı tanımlarken Schedule sekmesinde Pick düğmesini tıklayarak önceden tanımla schedule'larınızdan birini seçebiliyorsunuz.

SSIS paketleriniz BIDS'te çalışırken, SQL Server Agent Job'ında çalışmıyorsa...

2009-03-30T03:21:00.001-07:00

Ne güzel, SSIS paketinizi tamamladınız. Tüm testleri yaptınız, doğru ve istediğiniz performansta çalışıyor. Hatta loglama, istisna ve hata yönetme (exception ve error handling), konfigürasyon dosyaları gibi işleri bile yaptınız. Şimdi sıra geldi otomasyona...

Bunun için bir SQL Server Agent job'ında SSIS paketi çalıştıran bir job step oluşturmanız gerekir. Onu da oluşturdunuz. Ama o da ne, job altında normalde tıkır tıkır çalışmakta olan paketiniz çalışmıyor!

Bunun birkaç sebebi olabilir:
- Dosya sistemine deploy ettiyseniz paket dosyasına ya da yine dosya sisteminde bulunan çeşitli csv dosyalarınıza kendi hesabınızın erişimi vardır ama SQL Server Agent'ın kullandığı hesabın bunlara erişim yetkisi yoktur.
- Bağlandığınız çeşitli veri kaynaklarıyla ilgili olarak yine etkileşimli çalıştırmada kullandığınız hesap yetkiye sahiptir ama SQL Server Agent'ın hesabının bunlar üzerinde yetkisi yoktur.

Peki ne yapmak lazım?

Ana adımları sıralayacağım, herbirinin nasıl yapıldığı gibi ekran görüntülerine falan girmiyorum. Özünde yapmanız gereken şeyin sebebini aktarayım önce: SQL Server Agent'ın paketi çalıştırmayla ilgili gerekli tüm yetkileri yok. Ama sakın bu yetkileri düşünmeden vermeye kalkmayın Agent hesabına. Bir paket için 3 yetki, başka bir paket için 5 yetki derken, bir de bakarsınız SQL Server Agent'ın kullandığı hesabın herbi şeye yetkisi var. Onun yerine kademeli bir yetkilendirme süreci gerekiyor.

Şimdi o yetkilendirme sürecinin ara kavramların ve izlenmesi gereken aşamaları anlatıyorum.

1. Öncelikle Management Studio'da SQL Server'ınızın altındaki Security düğümünden erişebileceğiniz Credential'larla ilgili ekrandan yeni bir credential tanımlayın. Bir credential login'in tersidir. Yani veritabanına erişim için değil, veritabanından dışarıya erişim için kullanılır. Standart bir credential, domain ismi, hesap ismi ve hesap parolasından oluşur.
2. SQL Server Agent altındaki proxy'lere gelerek, tanımladığınız credential'ı kullanan bir proxy oluşturun ve bu proxy'i SSIS paketleriyle ilgili subsysteme oluşturduğunuz ekrandan atayın.
3. Artık SSIS'le ilgili job step'te runas kısmında bu proxy bir seçenek olarak gelecektir.

Aradaki izinleri de doğru bir şekilde verdiyseniz (paket içindeki yetki gereksinimleriyle ilgili olarak credential'a karşılık gelen hesaba gereken yetkileri vermek ya da proxy'i kullanmak için job sahibine izin vermek gibi) otomasyonda artık bir sorununuz olmayacaktır.

Yapılması gereken bir başka çalışma da, yetki ihtiyaçlarına ve önemlerine bağlı olarak job stepleri gruplamak ve bunlar için uygun proxy'ler tasarlamaktır.

SQL Server 2008'de şifreleme için hangi yöntemi kullanmalı?

2009-03-30T01:25:00.000-07:00

SQL Server 2008'de şifrleme için kullanabileceğiniz iki ana yöntem var:
- TDE: Transparent Data Encryption. Tüm veritabanını uygulamalarda değişikliğe gerek kalmadan şifrelemek.
- Column-Level Encrytion: Kolon bazında kendi şifrelemenizi yapmak.

Bunlar arasında çeşitli durumlarda farklı tercihlerde bulunmak mümkün. TDE'nin en büyük avantajı, programlama işi değil yönetsel bir iş olması. Kurulması ve kullanılması herhangi bir veritabanı yöneticisinin rahatlıkla öğrenebileceği seviyede. Uygulamaya da hızla almak mümkün. Ama herşeyi şifrelemiş oluyorsunuz.

Kolon seviyesinde şifreleme kullanma durumunda ise herşeyin çok daha fazla detayına girebiliyorsunuz, ama çok ciddi programlama yükü çıkıyor ortaya.

Bazı senaryoları düşünecek olursak:

- Veritabanının sadece küçük bir kısmının şifrelenmesi gerekiyorsa ve bu şifrelenecek kısımlar sorgularda yoğun olarak geçmiyorsa, kolon seviyesinde şifrelemeyi tercih etmeniz biraz daha yüksek ihtimal. Kolon seviyesinde şifrelemenin en önemli dezavantajlarından birisi, indeksleri pratik olarak anlamsız kılması ve o kolonla ilgili sorguların hep tüm tablonun (ya da indeksin) taranmasına yol açıyor olması. Şifreli olması gereken kolonlarınız az sayıda ve sık sorgulanmayan kolonlarsa bu sıkıntı sizin için önemini kaybediyor. Ayrıca az miktarda verinin şifrelenmesi gereken durumda tüm veritabanını TDE yoluyla şifrelemek performansa gereksiz bir etki yapabilir.

- Şifrelenmiş kolonlarda yoğun arama yapmanız gerekiyorsa TDE'ye yönelme olasılığınız artar. Çünkü TDE uygulanmış veritabanlarında indeksler eskisi gibi kullanılmaya devam edebilir.

- Yasal, yönetmelik ya da sözleşme gereği olan durumlar: Bu tür durumlarda genelde pek şansınız yoktur. Düzenleme hangisini zorunlu kılıyorsa, o tarzda şifrelemeye gitmek zorundasınız. Ama çoğunlukla bu tür zorunluluklar sözel ifadeler olacaktır. Onları doğru yorumlayıp yorumlamadığınızdan emin olun.

- Kod tabanını değiştirme şansınız hiç olmayan uygulamaları desteklemek zorundaysanız, şifreleme için yalnız TDE'yi düşünebilirsiniz. Çünkü kolon bazlı şifreleme için uygulamalarda değişiklikler yapmanız gerekecektir.

Tüm bunların yanısıra son bir ek bilgi: TDE geçici bilgilerin tempdb'den kırılmaması için tempdb'yi de şifreler. Bu durumda birden fazla veritabanınız bulunan bir SQL Server'da, tempdb şifrelendiği için normalde TDE kullanmayan veritabanlarınız da TDE'nin etkisini hissedebilir. Böyle bir sıkıntı yaşarsanız, TDE'li veritabanlarınızı farklı bir SQL Server instance'a almayı düşünebilirsiniz.

SQL Server 2008'de uzak dosya paylaşımına audit

2009-03-27T06:58:00.000-07:00

SQL Server 2008'de başka bir bilgisayardaki dosya paylaşımına da audit alınabiliyor. Yeni audit sisteminin getirdiği pek çok yenilikten biri de bu.

Peki bu performansı etkilemez mi? Öyle ya, çokça veri üretmesi mümkün bir audit sistemini etkinleştiriyorsunuz ve bunun yazmasını yerel bilgisayara değil uzaktaki bir bilgisayara yapıyorsunuz. Araya network giriyor, tabii ki performansa olumsuz bir etkisi olacaktır.

O zaman bu türde kullanım imkanının ne anlamı var? Çok anlamı var. Güvenlikle ilgili dış yönetmeliklere uyum sağlamak zorunda olan sistemlerde DBA'lerin yetki seviyesinin genişliği önemli bir sorundur. Bu yetki seviyesini kısıtlamak da pek mümkün değildir. Çünkü SQL Server'ın güvenlik sistemi, DBA'in güvenilir bir kişi olduğu üzerine kurgulanmıştır. İşte bu noktada uzaktaki bir bilgisayarda audit loglarının kaydedilmesi, önemli bir açılım sağlıyor.

Uzaktaki bilgisayarda SQL Server auditini yazan hesaba sadece ekleme yetkisi verilebilir. Böylelikle bu ya da DBA'in erişimi olan başka bir hesapla loga yazılmış bilgilerin silinmesi ya da üzerine yazılması mümkün olmayacaktır. DBA tabii ki loglamayı kapatabilir. Ama loglama kapatma girişimi de loglanabilir.

Auditi uzaktaki bir bilgisayara loglamak, belirttiğimiz güvenlik ayarlarıyla birlikte yapıldığında, SQL Server üzerinde sınırsız kontrole sahip olan DBA'ye yönelik bir güvenlik mekanizması oluşturulmuş olacaktır.

SQL 2008'de XML'i rahatça kullanmak

2009-03-19T01:51:00.000-07:00

Veritabanında XML kullanmanız gerekiyor ama kullanım şekli size rahat gelmediği için sıkıntı yaşıyorsanız, yalnız değilsiniz. Benzer durumda pek çok kişi var.

Microsoft SQL 2008'de tablolarda XML kullanımını hayli kolaylaştıran bir yöntem geliştirmiş. Biraz başka konular altında gizli bir bilgi gibi. Nasıl yapıldığını burada detaylı anlatmayacağım, ama konuyla ilgili kişilere yol gösterecek kadar ipucu vereceğim.

Öncelikle bir tablonuz var. Bu tabloda standart kolonlarınızın yanısıra, XML olarak tutulmasını istediğiniz kolonlar da var. XML olarak tutulmasını istediğiniz kolonları SPARSE olarak tanımlayın. Sonra da tabloda XML tipinde bir kolon tanımlayın ve buna COLUMN_SET FOR ALL_SPARSE_COLUMNS deyin.

Bu işlemler sonucunda neler elde ediyorsunuz:

- Sparse kolonlara her zamanki şekilde insert, update gibi işlemlerinizi yapabiliyorsunuz.
- Bu tabloya Select * ile başlayan bir sorgu çektiğinizde, sparse olmayan kolonlar sıralanıyor, sparse kolonlar ise sadece xml tek bir kolon gibi sıralanıyor.
- Tabloya for xml auto ile sorgu çektiğinizde, sparse olmayan kolonlar attribute olarak, sparse olan kolonlar ise embedded elementler olarak görüntüleniyor.

Veritabanında XML'le işiniz olmuyorsa, bu kadarcık bilgi genel kültür olarak bulunsun. Veritabanında XML'le işiniz oluyorsa, bu konuyu Books Online'dan hemen araştırın. Yukarıda yazdıklarım nelere bakmanız gerektiği ve ne elde edebileceğiniz konusunda umarım yeterince ipucu olmuştur.

SQL 2008'de veritabanı yedeğini compressed alınca ne olur?

2009-03-18T08:26:00.000-07:00

Çeşitli yerlerden SQL Server 2008'de veritabanı yedeğini alırken sıkıştırma uygulanabileceğini okumuş ya da duymuşsunuzdur. Ama hiç denediniz mi?

SQL 2008'de AdventureWorks veritabanının yedeğini her iki şekilde aldım. Sıkıştırılmamış yedek 267 MB. Sıkıştırılmış yedek ise 56.6 MB. Kazanım oranı: Yüzde 78.8!

Üstelik kazanımınız sadece daha az disk alanı kullanmakta değil. Muhtemelen yedek alma sürenizde hissedilir şekilde kısalacaktır. Çünkü disk yazma miktarı da bu oranda düşmüş olacak.

Ama tabii sıkıştırmanın getireceği bir işlemci yükü de olacaktır. İşlemci yükü hafif disk okuma/yazma yükü ağır bir veritabanı için sıkıştırmalı yedek muhtemelen sizi hayli rahatlatacaktır.

Kaçak sorgularınızı spotlar altına alın!

2009-03-18T07:55:00.001-07:00

SQL Server performansı ile ilgili sorununuz varsa, bunu iyileştirmek için yapabileceğiniz çeşitli şeyler vardır.

Öncelikle darboğaz olan alanı belirlemeniz gerekir. İşlemci mi? Bellek mi? Disk okuma yazmaları mı? Belki de -küçük bir ihtimal- network erişimi mi?

Darboğaz olan alanı bulunca sakın o alanı genişletmeyi düşünmeyin hemen. Öncelikle darboğaza sebep olan sorguları bulmaya odaklanın.

Özellikle kullanıcıların oluşturduğu raporların da çalışabildiği sistemlerde bazen birkaç sorgu sorunun tüm sebebi olabilir. Onları yani kaçak sorguları bulup spotların altına alın. İnceleyin. Bazen bu sorguları tamamen kaldırmak, bazen eksik bir where ifadesini yazmak, bazen bir indeks oluşturmak ya da bir indeksi biraz geliştirmek performanta büyük etkiler yapabilir. Tekil olarak o sorgunun hızı yüz katına bile çıkabilir. Çokça çalışan bir sorguysa sistemin tüm performansında yüzde onlara, yirmilere ulaşan tasarruflar sağlanabilir.

Bir sorgunun neler yapabileceğine basit bir örnek. Biraz karikatür bir sorgu. Tıpkı bir karikatürdeki gibi bazı hatları fazlaca vurgulamış olacağız. Ama sisteminizde böyle bir sorgunun yazılmayacağını kim garanti edebilir? Bakın:

USE Adventureworks

SELECT *
FROM Production.ProductCategory, Production.ProductSubcategory, Production.Product,
Sales.SalesOrderHeader, Sales.SalesOrderDetail

SQL'i şöyle sağdan soldan biraz görmüş ve doğrudan sorgu yazmaya yetki verilmiş bir kullanıcı böyle bir sorgu yazmaya kalkabilir. Bu seviyeden biraz daha derin bir SQL bilginiz varsa, sorgunun bir cinayet olduğunu anlamışsınızdır. Ama önemli olan, olası etkisi.

AdventureWorks örnek veritabanı büyüklüğü 200 MB'ın altında bir veritabanıdır. Bu sorgu, bu veritabanın beş tablosu ile bir cross join'e sebep oluyor. 280 trilyondan fazla satır döndürüyor. Toplam veri büyüklüğü 200 petabyte. Yani 1024 kere 1024 GB. Bir yerlerde YouTube'un bir günde tüm dünyaya yaptığı yayının 2-3 petabyte civarında olduğunu okumuştum. İki satır sorguyla YouTube'un 100 günlük yayını kadar yük oluşturulmuş durumda.

Çalışan bir sistemde bu kadar büyük hatalı sorgular muhtemelen hemen fark edilir. Ama sık çalışan bir sürü sorgunuzda bu kadar vahim olmayan, ama sorgunun iş yükünü gereksiz yere yüzde yirmiler civarında artıran hatalar varsa ne olacak?

Kaçak sorgularınızı yakalayın, ve sorgulayın onları.

SQL Server Resource Pool ayarlarıyla ilgili birkaç püf noktası

2009-03-16T08:42:00.000-07:00

SQL Server 2008'deki Resource Governor özelliği, eş zamanlı çalışan sorguların performansa etkisi konusunda yöneticiye söz hakkı tanıması yönünden çok önemli. Ama bir yöneticinin bu özelliği etkin kullanabilmesi için dikkat etmesi gereken birkaç nokta var.

Burada Resource Governor özelliğinin nasıl kullanılabileceğinden bahsetmeyeceğim. Bunu bildiğinizi ya da araştıracağınızı varsayıyorum. Resource Governor'ı kullanmakta en önemli unsurlardan birisi, resource pool'ların minimum ve maksimum değerlerini doğru ayarlamaktır ve bu yazıda bundan bahsetmek istiyorum.

İki temel kaynak konusunda yani CPU ve RAM'le ilgili olarak resource pool'ların minimum ve maksimum değerlerini ayarlayabilirsiniz. Ama bu ayarları yaparken o kadar da serbest değilsiniz. Dikkat etmeniz gereken bir kaç püf noktası var.

Öncelikle minimumlar: Minimumları belirlerken serbest değilsiniz. Minimum toplamları yüzde 100'ü geçemiyor. Eş zamanlı çalışmaları durumunda herbirine istediği minimum kaynak oranını vermeye çalışacak olan SQL Server, işini dürüstçe yapabilmek için size böyle bir kısıtlama getiriyor. Mantıklı da zaten, aksi taktirde bu minimumları garanti etmesi imkansız hale gelirdi.

Gelelim maksimumlara: Maksimumların isterseniz hepsini yüz de yapabilirsiniz. Ama etkili maksimum diye bir kavram da var.

Diyelim ki 3 poolunuz ve bir de default pool var. Ayarları şu şekilde yaptınız:

Pool (min değer, max değer):
Default (0, 100)
Pool1 (20, 90)
Pool2 (40, 100)
Pool3(40, 50)

Acaba etkin maksimum değerler ne olur?

Pool1'i düşünelim. Diğerlerinin minimumlarının toplamı 40+40 = 80'dir. Bu durumda pool1'e kalan etkin maksimum 100-80 = 20'dir. Yani aslında minimum değeriyle maksimum değeri aynı.

Pool2 için diğerlerinin minimum toplamı 20+40 = 60'tır. Bu durumda pool2 için de hem minimum hem maksimum değeri 40'tır. Pool3 için de benzer hesapla hem minimum hem maksimum değeri 40'tır.

Peki ya örneğimiz şöyle olsaydı:

Pool (min değer, max değer):
Default (0, 100)
Pool1 (20, 90)
Pool2 (25, 100)
Pool3(30, 50)

Bu durumda pool1'in etkin maksimumu benzer hesapla 45'tir. Pool2 için etkin maksimum 50'dir. Pool3 için ise ilginç bir durum var: Diğerlerinin minimumları toplamı 45. Yani etkin maksimum 55 olabilecek gibi duruyor. Ama kendiniz maksimumu 50 olarak belirtmişsiniz. Etkin maksimum hesaplanan olası maksimumla sizin belirttiğiniz maksimumdan en düşük olan hangisi ise odur. Yani 50 olur.

Mirroring yüzünden transactionlarım ne kadar gecikiyor

2009-02-10T00:56:00.000-08:00

Mirroring'de akla takılan temel bir soru vardır:

Tavsiye edilen yöntemi kullandığınızda mirror'da birincil sunucuda commit edilmiş olan tüm transactionlar bulunur ama bu iki fazlı commit anlamına gelir ve birincil sunucu ikincil sunucudan da onay alıp ondan sonra istemciye onay döner. Bunun anlamı transactionlarda bir miktar gecikmedir. Acaba bu gecikmenin bize maliyeti nedir?

Cevabı öğrenmek için bir performance monitor counterımız var. SQL Server:Database Mirroring altındaki Transaction Delay sayacını deneyin.

Database Mirroring Monitor

2009-02-10T00:49:00.000-08:00

Özellikle test aşamalarında ya da yoğun kullanım durumlarında ne olacağını incelediğiniz sırada mirror yapısında neler olup bittiğini yakından takip etmek istersiniz.

Bu takip için kullanabileceğiniz database mirroring monitor adında bir araç var.

Şu adımlarla erişebilirsiniz:

1. Management Studio'da birincil sunucuya bağlandıktan sonra Object Explorer'da sunucunun altında ilgili veritabanını seçin.

2. Veritabanını sağ tıklayıp Tasks'i ve oradan da Launch Database Mirroring Monitor'ü seçin.

3. Gerekiyorsa açılan ekranda Register Mirrored Database'i tıklayarak mirror'lı veritabanlarını ekleyin.

SQL Server mirroring'de istemci yeniden yönlendirme

2009-02-10T00:35:00.000-08:00

Mirroring çok konuşulan bir uygulama... Ve mirroringde uygun istemci sürücülerini kullanıyorsanız, connection string'de mirror'ın da belirtilebileceği de sıkça tekrarlanan bir bilgi.

Ama işin sadece bundan ibaret olmadığını biliyor muydunuz? Uygun istemci sürücüleri mirroring'den haberdar oldukları için mirror'lı bir bağlantı yapıldığında mirror'ın bilgisini de alıp bellekde bulunduruyorlar. Üstelik bu uygulama, connection string'de mirror server belirtilmiş olsa da olmasa da yapılıyor.

Bu çalışma şeklinin birkaç önemli anlamı var:

- Uygun istemci sürücüleriyle çalışıyorsanız, mirrorla ilgili hiçbir bağlantı bilgisi girmeseniz de sisteminiz mirrordan yararlanabilir.

- Connection string'e mirrorın bilgisini girmiş olsanız bile, bağlantı sağlandığında mirrorla ilgili farklı bir bilgi alınırsa, bu farklı bilgi bellekte tutulur ve gerektiğinde kullanılır.

- İlk bağlantı sağlandığında ya da uygulama kapanıp -yani belleği boşalıp- yeniden açıldığında, connection string'de mirror bilgisini belirtip belirtmediğiniz önem kazanır. Eğer birincil sunucuya bağlantıda sorun olmazsa, bağlantının sağlanmasıyla mirrorın bilgisi de belleğe alınmış olacaktır. Ancak birincil sunucuya bağlantı sağlanamıyorsa, mirror bilgisi de ondan alınamayacağı için, -eğer connection string'de belirtilmemişse- mirror'ın devreye girmesi mümkün olmayacaktır.

- Her durumda initial catalogue'un yani hangi veritabanına bağlanacağınızın connection string'de belirtilmesi gerekir.

- Mirror'dan tam anlamıyla yarar sağlamak için -mirror'a özel olmasa da- iyi programlama standartlarına uyulmuş olması gerekir. Burada kastettiğimiz temel konu şu: Birincil sunucudan mirrora otomatik devir sırasında devam etmekte olan transactionlar hata döndürecek ve geri alınacaklardır. Uygulamanızın bu hatayı yakalayıp transaction'ı yeniden deniyor olması gerekir ki mirror hizmetinden kesintisiz bir şekilde faydalanabilsin...

SQL 2008'de mirrroringle ilgili birkaç bonus:

- Data aktarımı sırasında eğer sıkıştırma yüzde 12,5'dan fazla fayda sağlayacaksa mirroring sırasında compression (sıkıştırma) kullanır SQL 2008. Network trafiği açısından faydası olabilecek bir durum. Ve tabii mirror'ın performansı açısından...

- SQL 2008'de page seviyesinde bazı bozulma durumlarında SQL Server otomatik olarak ilgili sayfayı mirror'dan isteyip kurtarabiliyorsa oradan kurtarmayı dener.

- Mirror'ın genel olarak performansını iyileştirmeye yönelik başka çalışmalar da yapılmıştır. Eğer 2005 mirror kullanıyorsanız ve performansın daha iyi olması sizin için önemliyse, 2008'de yakın zamanda bir test yapmanızı öneririm.

SQL Server policy'lerinde kullanılabilecek best practiceler

2009-01-28T06:02:00.001-08:00

SQL Server'ın kullanabileceğiniz birtakım hazır policy'ler ile geldiğini biliyor muydunuz?

Management Studio'da Policies'i sağ tıklayıp Import Policy'yi seçin. Gelen ekranda Files to Import'un karşısındaki ...'yı tıklayın. İlk denemenizse zaten kısayol gelecektir, oradan bulabilirsiniz. Ya da ilgili yol şöyle: C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Policies

Tabii sizin yaptığınız kurulumda ufak tefek farklar olabilir. İlgili yeri bulmak zor değil. Burada hazır kullanılabilecek policy'ler var. Test etmeden sisteminize uygulamaya kalkmayın. Mevcut çalışmanız policy'ye uygun olmadığı için sorunlar yaşayabilirsiniz. Ama amaç da bu zaten di mi? Mevcut çalışmanız olmasını istediğiniz politikayaya uyuyor mu? İyi bir başlangıç noktası olabilir best practice analizi açısından...

Bu arada bir sunucuda oluşturduğunuz bir politikayı sağ tıklayıp export policy ile bir xml dosyasına alabilir, o dosyayı da başka bir sunucu da import policy diyerek sunucuya yükleyebilirsiniz.

Bu politikalar SQL Server DBA'leri için group policy'nin domain adminleri için önemli olduğu kadar önemli olacak. Demedi demeyin...

SQL Server Policy Based Management'ı eğitim amaçlı da kullanabileceğinizi biliyor muydunuz?

2009-01-28T04:41:00.001-08:00

Özellikle developer'ları kısıtlayan policy'ler oluştururken, description alanını nasıl doldurduğunuza dikkat edin. İlgili policy'i ihlal edip (eğer otomatik yasaklamaya ayarlanmışsa) hata mesajı alacak olan developer'a davranışının neden bir engele takıldığını ve bundan sonra neye dikkat etmesi gerektiğini hatırlatabilirsiniz...

SQL Server 2008 ile geocluster

2009-01-28T03:57:00.000-08:00

Cluster'ların en önemli dezavantajlarından birisi, aynı subnette ve çoğunlukla aynı ortamda bulunmalarıdır. Bu durumda ortamla ilgili fiziksel bir sorun cluster'ın tüm nodlarını aynı anda etkileyebilir.

Geocluster, bu sorunu azaltmak için, cluster nodlarının coğrafyada farklı noktalarda bulundurulmasıdır. SQL Server 2008 Windows Cluster'ın imkanlarının artması sayesinde burada biraz daha zenginlik kazanmış. Windows Server 2008'de geocluster yönünde kolaylıklar geldiği söyleniyor. Konu sizin için önemliyse, bir windows cluster uzmanından fikir sorabilir ya da biraz araştırmayı düşünebilirsiniz.

Görsel iş zekası ile ilgili bir blog

2009-01-14T04:52:00.001-08:00

İş zekasının görselliği ile yakından ilgileniyorsanız, bu blog hoşunuza gidebilir:

http://www.perceptualedge.com/blog/

Konuyla ilgili kitapları da olan Stephen Few, girdilerin büyük kısmını oluşturuyor. Ama zaman zaman başkaları da katkıda bulunuyor.

İş zekasında görsellik, insan algısına doğru ve hızlı ulaşım çok önemli. Altyapısı olmayan bir sistemde görsellik işe yaramayabilir, ama altyapısı iyi bir sistem de görsellik hataları yüzünden kötü bir kadere mahkum olabilir.

İncelemenizi tavsiye ederim.

Şiirlerim

2009-01-04T01:29:00.000-08:00

Cemal Süreya Şiir Ödülü'ne başvuruda bulunmuştum bu sene. Dereceye giremedim. Ama yıllardır saklı kalmış şiirlerimin artık gün yüzüne çıkması gerektiğini biliyorum.

Başvuru için 83 şiirimi düzenleyip bir araya getirmiştim. Başkaları da var. Biraz hızlı bir hazırlık süreci olduğu için tamamına göz atamamıştım.

Bu 83 şiiri webde yayınladım. Birkaç tanesini daha önce webe koymuştum. Ama büyük bir kısmı şimdiye kadar sadece birkaç insan tarafından okundu.

Şiire ilgi duyuyorsanız, beş ana bölüm halindeki şiirlerime aşağıdaki bağlantılardan erişebilirsiniz:

1. Bölüm: Birinci tekil şahıs kitabı
2. Bölüm: Dünya kitabı
3. Bölüm: İsyan kitabı
4. Bölüm: Aşk kitabı
5. Bölüm: Peri kitabı
6. Bölüm: Varlık kitabı

Organizasyonlarda Business Intelligence projelerinin başarısız olmasındaki başlıca etkenler

2009-01-02T01:24:00.000-08:00

Bir arkadaşım üzerinden, başlıktaki konu hakkında çalışma yapan bir üniversiteli arkadaşın talebi ulaştı elime. Sektör profesyonellerinin görüşlerini almak istiyor.

Kendisine kişisel bir cevap yazmak yerine bu konuda bir blog girdisi yazmak ve bağlantısını ona da göndermek daha mantıklı geldi. Deneyimlerim başka insanlara da yararlı olabilir.

Öncelikle genel olarak Kimball'in dikkat çektiği hata noktalarını aktardığım iki yazının bağlantısını vereyim. Daha önce okumuş olsanız da bir göz atmayı düşünebilirsiniz:

http://mustafaacungil.blogspot.com/2008/06/i-zekas-iin-boyutlu-model-tasarmnda.html
http://mustafaacungil.blogspot.com/2007/08/bir-i-zekas-projesinde-kanlmas-gereken.html

Şimdi gelelim Türkiye'de iş zekası projelerinin başarısız olma nedenlerinden bazılarına. Ben bir önem sırasına koymayacağım ve teknik detaylara da pek girmeyeceğim. Ama söylediklerim size daha 'yerli' gelebilir. (Ama yine de emin olun, başka ülkelerde de yaşanan sorunlar bunlara hayli paralel.)

1. Farkındalık:

Özellikle KOBİ ölçeğinde, firmalar iş zekası diye bir konunun farkında bile olmayabiliyorlar. Hatta biraz ölçekli firmalarda bile iş zekası etkinlikleri iş zekası başlığı altında yapılmayabiliyor. Genellikle 'raporlama' konusu etrafında yoğun çaba sarf ediliyor ama bu yapılırken iş zekasının sistematik yaklaşımlarından hiç haberdar olunmayabiliyor.

İş zekasının farkında bile olunmadığı bir firmada iş zekası projelerinin başarısızlığından söz edilebilir mi peki? Evet edilebilir. Adını doğru koymamış olsalarda yapmak istedikleri şey iş zekasıdır ve büyük bir karavana atışla başarısızlık sözkonusudur.

2. Şirket içi bilgi işleme ve değerlendirme tutarsızlıkları:

Şirketler çoğu durumda derebeylikler halinde yönetilmektedir. Farklı departmanların kendi verileri, kendi doğruları, kendi hesaplama şekilleri, kendi tanımları vardır. Herşey yolunda yürüyor gibidir. Ama sağlıklı bir iş zekası projesi ortak standartlar oluşturmaya çalışacağı için derebeylik döneminin sona ermesine sebep olan barut ve top kullanımı gibi bir etki yapar.

Bu, çekilmesi gereken bir acıdır. Başarılı olan firmalar, ortak tanımlara, ortak bilgi işleme standartlarına ve ortak değerlendirme yaklaşımlarına doğru kendilerini evrimleştirirler. Ama pek çok firma da iş zekasının imkanlarının farkında olsa bile bir noktada 'Bırak dağınık kalsın' demek zorunda kalır ve biz böyle gördük diye eski usül çalışmaya devam ederler.

3. Amerika'yı yeniden keşfetme sendromu:

İş zekasında yaklaşımlar bellidir. Yirmi yıla yaklaşan birikmiş tecrübeler vardır. Ralph Kimball ve grubunun ortaya koyduğu kendini kanıtlamış yaklaşımlar ortadadır. Ama pek çok firma bu yaklaşımlara bakmadan kendi başına bir yol çizmeye kalkar.

Sadece müşteri firmalardan bahsetmiyorum, iş zekası konusunda danışmanlık yapan firmalarda da boyutlu tasarımı pek de kavramamış insanlar iş yapabilmektedir.

Bu sorun aslında biraz da yetişmiş eleman eksikliği ile ilgilidir.

4. Yetişmiş eleman eksikliği:

Yukarıda iş zekasının yirmi yıldır gelişmekte olduğunu söylemiş olsak da, araçların olgunlaşmaya başlaması son beş yıl gibi bir süreye denk gelmektedir. Bu da bu alanda yetişmiş yeterince insan olmaması anlamına gelir.

Yetişmiş eleman eksikliği sadece sektörün genç olmasından kaynaklanmaz. Disiplinler arası bir yaklaşım gerektirmesi de yeni eleman yetişmesini güçleştirmektedir.

Yetişmiş eleman eksikliğini danışman ve firma çalışanı olarak ikiye ayırabiliriz. Danışman, bir danışmanlık firmasında çalışıp tamamen iş zekasına odaklanan kişidir. Firma çalışanı ise tam zamanlı ya da zamanının bir kısmında şirketindeki iş zekası uygulamalarıyla ilgilenen kişidir.

Danışmanlık yapan firmalar kendilerini ve kadrolarını hızla geliştirseler de, yetişmiş eleman eksikliğini gidermek için bu tek başına yeterli değildir. Çünkü iş zekası projeleri doğaları gereği tamamen firma dışından kaynaklarla yaşatılamazlar. Firma içinde birilerinin de bu konuda uzmanlaşması şarttır. Firma içi çalışanlar anlamında yetişmiş eleman eksikliği çok daha uzun vadeli bir problem olacak gibi görünmektedir.

5. Firmaların iç kaynak ayırmadaki isteksizliği:

Pek çok firma bilişimle ilgili işlerini artık dış kaynaklarla yaptırıyor. İçeride bir proje yöneticisi ve outsource çalışan kişiler...

Yazılım geliştirme gibi projeler için bu çok iyi bir model olabilir. Aslında iş zekası projeleri için de dış kaynak kullanımı önemlidir. Çünkü pek çok firma iş zekasında ileri derecede uzman danışmanları sürekli olarak kadrolarında taşıyamaz. Ancak iş zekası projelerinde firma içi uzmanlık gereksinimi yazılım projelerine göre daha yüksektir.

6. Proje sahipliği:

İş zekası projesinin sahipliği IT'de ise bu da bir problem olabilmektedir. İş zekası şu anki uygulamalarıyla IT imkanlarından çok büyük ölçüde yararlanıyor olsa da, hatta proje ekibinde IT'nin büyük bir ağırlığı olsa bile, bir IT projesi değildir. İş zekası projelerinin sahipliğinin iş kanadında olması gerekir. Ya da en azından proje sorumluluğu iş tarafı ve IT tarafından ortak kurulan bir takım tarafından yüklenilmiş olmalıdır. En başından itibaren sistemi asıl kullanacak kişilerin dahli olmayan bir iş zekası projesinin yaşaması çok zordur.

7. Şirket kültüründe değişim zorlukları:

ERP, CRM, Proje ve portföy yönetimi uygulamalarında olduğu gibi iş zekası projeleri de sadece teknik birer proje değildir. Diğerleri gibi iş zekası da şirket kültürünün yeni felsefeye göre dönüşmesini gerektirir. Asıl zorluk çoğu zaman buradadır. Veriyle yönetilmeyen bir şirketin, iş zekası yaklaşımlarına sıcak bakması göstermelik olacaktır.

8. İş zekasının raporlamadan ibaret görülmesi:

Bazı durumlarda iş zekası yapısının sadece raporlama önyüzünden ibaretmiş gibi görülmesi sözkonusudur. Çeşitli raporlama araçlarını deneyip istedikleri verimi alamamış pek çok firma vardır. Bunun temel sebebi, raporlama araçlarının arkada güçlü bir veri yapısı üzerinde asıl hünerlerini sergileyebilmeleridir. Veri ambarı sistemleri ve üzerlerindeki küpler olmadan, raporlama sistemleri kendi potansiyellerini sergileme şansını tam olarak bulamazlar.

9. İş zekasının veri yapısından ibaret görülmesi:

İş zekası veri yapısı ve raporlama önyüzüyle bir bütündür. Performanslı, hızlı çalışan, zamanında doğru bilgiyi aktarabilen bir veri sisteminiz olabilir. Ama önyüzü yeterince basit, bilgilendirici ve alımlı olmazsa, kullanıcılar bu sistemi kullanmak istemeyebilir. İşin bir bütün olduğu hiçbir zaman gözden kaçırılmamalıdır.

10. Ölçek problemi

Başka önemli bir problem de nasıl başlayacağını bilememektir.

Burada iki aşırı uç vardır: Kimisi iş zekasını bir bütün olarak bir lokmada ortaya çıkarmaya çalışır. Devasa projeler ve yılları bulan süreler konuşulmaya başlanır. Oysa o kadar sürede zaten yapılan işin şeklinde önemli değişiklikler olacaktır. Diğer uçta ise departman çapında bağımsız uygulamaların ortaya çıkması söz konusudur. Oysa iş zekasının en önemli yapılarından birisi firma çapında bir veri ambarı sisteminin zamanla ortaya çıkmasıdır.

Her iki yaklaşım yerine yapılması gereken, önce genel bir vizyon oluşturulması sonra da eklemli olacak şekilde sürüm sürüm bu vizyona yönelik uygulamaların yapılmasıdır.

Ne monolitik ne yamalı sistem uygundur. Doğru olan eklemli bir yapının ortaya konulmasıdır. Bu kavramı daha detaylı incelemek için Kimball'in 'bus matrix' yaklaşımına bakılmalıdır.

11. Neden best practice?

Sadece iş zekası projelerimde değil tüm danışmanlıklarımda zaman zaman best practice'lerin neden böyle diye insafsızca sorgulandığını görürüm. Oysa best practice deneysel bir uygulama değildir. Zaten senelerdir oturmuş, genel kabul görmüş yaklaşımlardır. Best practice'e aykırı bir uygulama düşünülüyorsa, bu uygulamanın nedeni düşünülmeli ve sorgulanmalıdır. İş zekasında da oturmuş best practice'ler zaman zaman öylesine konulmuş ilkeler gibi rahatlıkla çiğnenebilmektedir. Mesela bu anlamda Türkiye'de en yaygın uygulama slowly changing dimension ihtiyacının göz ardı edilmesidir. Zamanla acısı çok kötü çıkar.

12. GIGO

Garbage In Garbage Out: Çöp girerse çöp çıkar. İş zekası çabalarının önemli bir kısmı veri temizliğini sağlamaya yöneliktir. Temiz olmayan veriler temiz sonuçlar doğuramazlar.

Eğer sağlıklı veri oluşturabilen sistemler yoksa, bunlar üzerinde iş zekası sistemleri oluşturmaya çalışmak beyhude çabadır.

Yukarıda saydıklarım önem sırasında ya da tüm sorunları kapsayan nitelikte bir liste oluşturmuyor. Ama en önemli konulara değindiğimi düşünüyorum.

Bloguma abone olduğunu bildiğim her yazıyı takip eden arkadaşlar var. Bu konuda profesyonel olarak çalışan insanlar da var yazdıklarımı takip eden. Hatalarım eksiklerim varsa, lütfen yorumlarınızla bu yazıyı zenginleştirin. Katkılarınız beni çok sevindirecektir.

PerformancePoint Server'da ProClarity görünümlerini kullanmak isteyenler için birkaç ipucu

2008-12-30T01:12:00.001-08:00

Öncelikle SharePoint için ProClarity'nin viewerını ilgili SharePoint makinesine deploy etmeyi unutmayın.

Bunu yaptıktan sonra yine dikkat etmeniz gereken bazi ipuçları var:

ProClarity görünümlerini ProClarity Web Professional'la görüntüleyebilmek, çok hoş bir kullanım deneyimi sunuyor. Bunu yapabilmek için ProClarity admin aracından user properties'den ilgili kullanıcılara professional kullanma hakkı atamış olmalısınız. Ayrıca aynı araçta components tarafında da web professional'ı required hale getirmeniz gerekiyor.

(http://social.technet.microsoft.com/forums/en-US/proclarity/thread/c4c02ef1-88eb-41c0-b773-7ec5c4600887/)

Bunları yaptıktan sonra bir de PerformancePoint Server'da ProClarity raporunu ekledikten sonra Server URL'ini toolbarı gösterecek şekilde özelleştirmeniz gerekiyor. Bunu nasıl yapacağınızı da şu bağlantıda bulabilirsiniz:

http://hmorgenstern.spaces.live.com/blog/cns!28A6BE83102A0EB3!200.entry

(Temelde yaptığınız şey http://pas-server/pas gibi bir bağlantı yerine http://pas-server/pas/en/src/proclarity.asp?uiConfig=tb;ht;fs; şeklinde bir bağlantı kullanmak...)

Biliyorum, PerformancePoint'le ilgilenmediyseniz, bu yazı çok anlamsız geldi. Ne denmek istediği ile ilgili hiçbir fikriniz yok. Ama yukarıdaki sorunları yaşayıp aratarak gelmiş bir kişiyseniz, bana teşekkür edeceğinizi tahmin ediyorum. : )

Attribute Relationship Type: Rigid mi yapmalı flexible mı?

2008-12-01T04:28:00.000-08:00

SQL Server 2008'de dimension tasarladığınızda, Attribute Relationship'larla ilgili yeni bir sekme geldiğini görmüş olabilirsiniz. Belki de henüz fark etmediniz. Ya da şu ana kadar yazdığım cümlelerden hiçbir şey anlamadınız. O zaman muhtemelen Analysis Services'la işiniz yok, bu yazıyı da okumanıza gerek yok.

Ama o sekmeyi fark edip içindeki konuları merak edenler için birkaç bilgi:

1. Attribute Relationships yeni bir kavram değil. Analysis Services'in 2005 versiyonunda da vardı. Ancak ayarlandığı yer biraz karışık ve hafif gizliydi. Şimdi açık açık ortaya çıkmış durumda.

2. Attribute relationshipler doğal hiyerarşilerle gezinim hiyerarşilerini birbirinden ayırmanızı sağlar. Yıl, çeyrek, ay, gün, saat seviyelerini düşünün. Bu beş seviyenin kullanılabilecek tek dizilim şekli (çok özel durumlar hariç) budur. Yani bu bir doğal (ve zorunlu) hiyerarşidir. Tabii ki sadece yıl ve ay alabilirsiniz. Ya da benzerleri... İçinden birkaç seviyeyi seçmek bu doğal hiyerarşinin yönünü bozan bir şey değildir. Ama mesela ay, gün, yıl gibi bir kullanımınız olmaz.

Eğer bu beş hiyerarşi seviyesi şunlar olsaydı: Cinsiyet, saç rengi, göz rengi, medeni hal, yaş grubu... Bu durumda bu beş seviye içinde olması gereken doğal bir sıralama yoktur. Herhangi bir sırada ele alınabilir. Bu tür hiyerarşilere ben gezinim hiyerarşisi diyorum. Kullanıcı bu tür veriler üzerinde istediği bakış açısıyla gezebilir.

Attribute relationshipleri oluşturduğunuz zaman, bir hiyerarşinin doğal hiyerarşi olduğunu Analysis Services'a söylemiş olursunuz.

Peki ne fark eder? Zamanla ilgili 5 seviyede tek bir dizilim olabiliyorken, fiziksel özelliklerle ilgili ikinci örnekteki 5 seviye 120 farklı şekilde (5 * 4 * 3 * 2 * 1) gezilebilir.

Analysis Services'in performansla ilgili sunduğu en önemli avantajlardan birisi, özetleri (aggregations) önceden hesaplamaktır. Doğal hiyerarşiler hesaplanacak özetleri seçmek için çok önemlidir. Çünkü gezinim hiyerarşilerinin hepsi hesaba katılarak özetler hesaplanamaz. Bunu yapmaya kalksak, 1 GB verimiz için 99 GB özet hesaplayıp kaydetmek zorunda kalabilirdik.

3. Yine bu sekmede ayarlanan ilişki tipinin Rigid ya da Flexible olması da yeni bir konu değildir. Ne işe yarar rigid ya da flexible yapmak? Rigid yaptığınızda o ilişki tipinde oluşmuş bir ikilinin asla bozulamayacağı anlaşılır. Mart her zaman birinci çeyreğin ayıdır gibi... Flexible ise ilişki ikilisinin bozulabileceği anlamına gelir. Çorum bayiniz bugün Orta Anadolu bölgeye bağlıyken yarın Kuzey Anadolu bölgesine bağlı olarak değiştirilebiliyorsa flexible yaparsınız.

Bir ilişkinin asla değişemeyeceğini biliyorsanız, rigid yapın. Belki de sizin bayilerinizin bölgesi değişemez bir ilişkidir. Rigid yapmanız iyi olur.

Peki rigid yapmanın ne faydası vardır? Boyutla ilgili incremental process'lerde önceki aggregateleri doğru kabul ederek çalışma şansı olur Analysis Services'ın. Böylelikle zaten asla değişmeyecek bir ilişki için her seferinde tekrar tekrar hesap yapmamış olur.

Benzin 2 YTL'nin altına inene kadar Cuma günleri benzin almıyoruz

2008-11-27T14:21:00.000-08:00

Facebook'ta yeni bir grup başlattım: Benzin 2 YTL'nin altına inene kadar Cuma günleri benzin almıyoruz!

Yukarıdaki bağlantıya tıklayarak gruba ulaşabilir ve üye olabilirsiniz.

Bakalım bu tüketici hareketini, petrol firmaları ne kadar zamanda algılayabilecekler 'iş zekaları' ile.

Sayıyı yüzbinin üzerine bir çıkaralım, daha onlara çok iyi mesajlar ulaştırabilecek ne fikirlerim var!

Sizin için bu önemli bir konu ise, katılın gruba arkadaşlar ve başkalarını da davet edin. Grupla ilgili internet günlüklerinizde ve yazabildiğiniz yerlerde yazın. İş arkadaşlarınıza duyurun.

Bilinçli tüketici satıcının hakkını verir ve onun yaşamasından, zenginleşmesinden, daha iyi hizmet verebilir hale gelmesinden mutlu olur. Ama kazıklandığı zaman da bunu anlar! O zaman pek mutlu olmaz ve mutlu olmadığını satıcıya hissettirmesi gerekir.

RFID'ye dikkat

2008-11-22T02:11:00.000-08:00

Satış gibi temel konular hakkındaki analizlerden öte iş zekası uygulamalarına girmişseniz, RFID'ye dikkat etmenizde büyük fayda var.

Üretim hattı, lojistik gibi alanlarda RFID'nin kullanımı büyük faydalar getiriyor. Bu da kullanımın giderek yaygınlaşmasına sebep oluyor. RFID barkod gibi bir sistem aslında. Ama farklı yönleri benzer yönlerinden önemli. Barkod'da okuyucunun etiketi 'görmesi' gerekiyor. Bu da hayli zahmetli olabilen bir süreç. Oysa RFID radyo frekansı üzerinden bu işi yapıyor. Yani görmek yerine duymaya benzetebiliriz. Bir şeyi görmeniz için doğrudan bakmanız gerekir, ama duymak çok daha kolaydır.

Mesela havaalanlarında bavul ve eşyaların RFID ile takibi uygulamalarına başlanmış. Kayıp bağaj konusunda önemli iyileşmeler sağlamış bu durum.

Peki bize etkisi nedir? İş zekası insanları olarak? Barkod verisini yönetmek ile RFID verisini yönetmek arasında ne fark olabilir ki?

Azla çok arasındaki farktır bu. Barkod verisi az olmaya eğilimlidir. Çünkü barkodla okuma yapmak maliyeti biraz yüksek bir eylemdir ve mümkün olduğunca az yapılmasına çalışılır. Oysa RFID okumalarının maliyeti (en azından insan emeği anlamında maliyeti) çok daha düşük olabilir. Bu da RFID kullanan sistemlerde çok daha fazla noktada okuma yapılacağı anlamına gelir. Hem altyapınızın teknik olarak daha fazla yükü kaldıracak şekilde yapılandırılması gerekebilir, hem de tasarımlarınızın ölçüm hassasiyetinin artması gerekebilir.

RFID'li bir sistemle ilgili çalışacak olursanız, ekstra yük ve ekstra hassasiyet gereksinimleri doğabileceğini unutmayın.

SSIS'te gelen tek satırı çok satıra dönüştürmek

2008-10-30T02:21:00.001-07:00

Başınıza gelmiş olabilir. Ya da bundan sonra gelebilir.

Flatfile şeklindeki bir dosyada, satırlar 'çok akıllı' olabilir. Relational formatta alt alta olması gereken bazı satırlar yanyana birleşmiş olabilir. One to many ilişkide olacak iki ayrı tablonun verisi tek bir satırda yanyana tekrar edebilir.

Şunu düşünün mesela: Kişiler ve telefonları:

Mustafa,0212...,0532...,0554....

Oysa siz şöyle istiyorsunuz:

Mustafa 0212...
Mustafa 0532...
Mustafa 0554....

Bunu yapmanın bir yolu unpivot kullanmak. Ama standart bir desene uymuyorsa veriniz, unpivot da işinizi görmeyebilir.

http://bi-polar23.blogspot.com/2008/06/splitting-delimited-column-in-ssis.html adresinde bu konuda script component'ın nasıl kullanıbileceği örneğiyle birlikte çok güzel açıklanmış.

SSIS'le uzmanlık seviyesinde ilgileniyorsanız, incelemenizi öneririm.

KPI özellikleri

2008-10-09T07:38:00.000-07:00

KPI'larınız S.M.A.R.T. olmalı.

Zeki olmalılar evet ama herbir harfin de anlamı var:

Specific: Belirli bir ölçüte odaklanmış olmalı.

Measurable: Yeterince ölçülebilir olmalı. Güneşli, yağışlı, karlı da bir ölçümlemedir. Sağnak yağışlı, karla karışık yağışlı, gök gürültülü sağnak yağışlı vb... de.

Achievable: Başarılamayacak bir hedef yok hükmündedir. Hedefe yönelttiğiniz kişiler ulaşılamayacağını düşünüyorlarsa, en fazla ulaşmaya çalışır gibi yapma taklidi yaparlar. Hedeflerin başarılabilir olması yetmez, gerekli kişilerin başarılabilir olduğuna inanç duymaları da sağlanmalıdır.

Realistic: Başarılabilir ve gerçekçi? Bu da yine inanç kısmıyla ilgili. Başarılabilir olduğuna inandırdığınız bir hedef aslında hiç de gerçekçi olmayabilir. Ya da tekrarlanabilir olmayabilir.

Timely: Zaman bağlantısı olmayan bir hedef hedef değildir aslında.

Scorecard ve dashboard farklarına ek bir madde

2008-10-09T07:22:00.000-07:00

Teknik olarak çok derinlerine indiğim konularda bile okumaya devam etmeyi severim. En basitinden alarak başlayan kitapları bile. Çünkü onlar yeni bir bakış açısı sunar. Ufak eksiklikleri tamamlar, katkıda bulunur.

Bir şeyi ilk kez öğreniyorken, her çabanızda aldığınız marjinal fayda yüksektir. Ama ilerledikçe bir birim öğrenme için daha fazla çaba sarf etmek zorunda kalırsınız.

İş zekasına ister yeni başlıyor olun, isterseniz ilerlemiş olun, fayda sağlayacağınız bir eser keşfettim:

Pro PerformancePoint Server 2007, Building Business Intelligence Solutions, Philo Janus, APress.

İşte ilk sayfalardan benim daha önce dikkat etmediğim bir ayrıntı...

Önceki yazılarımdan birinde KPI nedir diye girip, dashboard ve scorecard olaylarından da bahsetmiştim.

Scorecardların ve dashboardların önemli bir farkına Philo dikkatimi çekti:

Scorecardlar daha stratejik seviyede. Haftalık veya hatta aylık güncellemeye uygun, uzun vadeli gidişinizi gösteren araçlar.

Dashboardlar ise taktik seviyede araçlar. Yerine göre saatlik güncellemeye bile açık olabilirler.

Bu ayrıntıya dikkat etmeme engel olan şey ise, genelde scorecard'ların dashboard'lar içinde kullanılması. Burdaki mantık şu: Hızlı güncellenen sistemin (dashboard) içinde uzun vadeli gidişe dair daha durağan ama belki daha önemli bilgiler de (scorecard) veriliyor.

Başlangıçta mantık biraz ters gibi, ama doğru. Ağacı görürken ormanı da hatırlamak gibi bir şey.

SQL Server 2008 daha az disk alanı kullanıyor!

2008-09-15T05:55:00.000-07:00

SQL Server 2008'in en iddialı olduğu alanlardan birisi de disk alanı ihtiyacı yönünde.

4 ayrı uygulama var:

- Row Level Compression: SQL Server sayısal tipleri ve sabit uzunluktaki tipleri değişken uzunlukta tipleri tuttuğu mantıkla tutuyor. Böylece mesela pek çok satırda 0 değeri alan bir Integer daha az yer kaplayabiliyor. Ya da değişken olarak tanımlanmamış kolonlardaki tamamlama karakterlerini boş yere tutmuyor.

- Page Level Compression: Belirli desenlerin sık görüldüğü kolonlar için çok uygun. Sık tekrarlanan bu desenlere bir gösterim atayıp, uzun desen örgüsünü her seferde tekrar ettireceğine kısa gösterimi tekrarlıyor.

- BackUp Compression: SQL Server 2008 yedekleme sırasında veriyi sıkıştırabiliyor ve daha az alan isteyebiliyor.

- Mirroring Compression: Aynalama kurulumlarında iki sunucu arasında aktarılan veri sıkıştırılıyor, böylece aynalama maliyeti azaltılmış oluyor.

Bir test ortamında kendi veritabanlarınızla bu özelliklerin sağlayacağı avantajları incelemenizi tavsiye ederim.

SQL Server 2008 veritabanlarında date correlation optimization seçeneği

2008-09-15T05:47:00.000-07:00

SQL Server 2008'de veritabanları için ayarlayabileceğiniz yeni bir opsiyon var: date_correlation_optimization. Varsayılan ayarı kapalı.

İki büyük tablonuzda birbiriyle işlevsel ilişkisi olan tarih kolonlarınız varsa ve bu iki tablo arasında tek kolon üzerinden foreign key ilişkisi varsa, date_correlation_optimization tarihle ilgili kısıtlama yapan sorgularınızda (many tarafında) önemli faydalar getirebilir.

Konu sizinle ilgili gibi duruyorsa, Books Online'dan ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.en/s10de_4deptrbl/html/275fb44b-417a-426a-bf7c-f23308ed72c0.htm adresinde detaylarına bakabilirsiniz.

Temelde yaptığı, tarih kolonları arasındaki işlevsel bağı istatistiksel olarak tutmak ve sizin yazdığınız sorguya arkada bir kısıt daha ekleyerek çalıştırmak.

Diyelim bir tabloda sipariş tarihiniz ve bu tabloya bağlı detay tablodaki herbir satırda da nakliyeye teslim tarihi bilgisi var. Doğal olarak bunlar arasında işlevsel bir bağ olacaktır.

Daha geniş çaplı örneği verdiğim Books Online bağlantısında.

Reporting Services'i scale-out etmek (dağıtıklaştırmak)

2008-09-10T23:57:00.000-07:00

Raporlama yükünüz fazla ise, Reporting Services'i tüm unsurlarıyla tek sunucuya kurmanız yeterli gelmeyebilir. Yüksek kullanılabilirlik/uygunluk (high availability) için ya da iş yükü fazla olduğu için Reporting Services'i dağıtık hale getirmek isteyebilirsiniz.

Bunun için ilk yapmanız gereken uygulama ve veritabanı katmanlarını ayrı makinelere kurmaktır. Reporting Services'i uygulama olarak tutacak sunucuya kurarsınız, ama kurulum sırasında ayarları otomatik yapmazsınız. Sonradan Reporting Services Configuration Manager'ı açıp ayarları yaparsınız. Database sayfasında Reporting Services'in iki veritabanını tutacak sunucuyu seçerken de lokal değil veritabanlarınızı tutacak ve uygun SQL Server veritabanı sürümünün yüklenmiş olduğu ikinci sunucuyu seçersiniz.

Böylelikle veri ve uygulama katmanlarını ayrı sunuculara yapılandırmış oldunuz ama henüz burada yedeklilik yok.

Veritabanı katmanında yedekliliği SQL Cluster kurarak sağlayabilirsiniz. Cluster şu an burada konumuz olmadığı için daha fazla detayına girmiyorum.

Uygulama katmanında ise başka uygulama sunucularını da aynı gruba dahil etmeniz gerekir. Bunun için dahil etmek istediğiniz sunucuya Reporting Services'ı kurar ama kurulum sırasında ayarları otomatik yapmazsınız. Kurulum yaptığınız bu sunucuda da Reporting Services Configuration Manager'ı açar ve elle ayarları yaparsınız. Database sayfasında yeni bir veritabanı oluşturmak yerine, daha önceki sunucuyu bağladığınız veritabanı sunucundaki oluşmuş Reporting Services veritabanlarına yönlendirme yapmanız gerekir.

Buraya kadar güzel, ama SQL Server 2005'te tam burada çoğu insan takılıyordu. İkinci uygulama sunucusu initialize olamıyordu çünkü. Initialize'ı ancak bu gruba daha önce dahil olmuş bir Reporting Services kurulumunun Reporting Services Configuration Manager'ından yapabirsiniz.

SQL Server 2008'deki Reporting Services Configuration Manager'da bu durum daha açık bir şekilde belirtilmiş. Scale-out Deployment sayfasında şöyle yazıyor:

"... Servers that are waiting to join the scale-out deployment must be added by a Report Server instance that is already part of the deployment."

SQL Server Integration Services'ta Data Profiling

2008-09-10T03:51:00.000-07:00

Veri ambarı projelerinde proje vaktinin ve harcanan emeğin yüzde 70-80'ini veri ambarının tasarlanması, tarihi aktarımın yapılması ve periyodik aktarmaların tasarlanıp otomasyona bağlanması oluşturur.

Bu sürecin bu kadar uzun sürmesindeki en önemli sebeplerden birisi de veri kalitesidir. Çoğu durumda verilerde beklenmedik değerlerle karşılaşılır, başka problemler de olur, ve otomasyonu oluşturana kadar ha bire karşınıza çıkan bu veri problemleriyle uğraşırsınız.

Veri profili çıkarmak, bu tür sorunları daha derli toplu bir şekilde bulup çözebilmeyi sağlar. Microsoft, SQL Server 2008'de Integration Services'a bu yeteneği kazandırmış.

İki temel araç kullanıyoruz: Bir paketin içinde Data Profiling görevini kullanarak çıkarmak istediğimiz profili oluşturuyoruz. Oluşanlar aslında xml dosyaları. Bu xml dosyalarını da dataprofileviewer adlı araçla inceliyoruz.

Çıkarabileceğiniz profillemelere bazı örnekler:

- Null değerlerin oranı
- Kolondaki verilerin dağılımı
- Sayısal kolonlar için kolon istatistikleri
- Metin kolonları için regular expression karşılaştırmaları
- Kolonlar arasındaki ilişkilerin doğrulanması
- Aday anahtar kolonlar
- Kolonlar arasında işlevsel bağımlılıklar (ilçe ve posta kodu bağımlılığı gibi)
- Bir kolondaki değer kümesinin bir başka kolondaki değer kümesinin alt kümesi olup olmadığının incelenmesi

SSIS açısından MERGE ifadesi

2008-09-10T03:15:00.000-07:00

SQL Server 2008'de gelen yeniliklerden birisi de MERGE ifadesi.

Merge, temelde bir hedef tabloyu ve bir kaynak sorguyu karşılaştırır. Kaynak ile hedefte bir kolonun değerinin aynı olmasına (ve istenen olası ek koşullara) bakarak MERGE ifadesi INSERT, UPDATE ya da DELETE olarak çalışabilir.

Komutun kullanım örneklerini SQL Server Books Online'da bulabilirsiniz. Ben burada bu komutun Integration Services paketleri açısından önemine değinmek istiyorum.

Aşağıdaki kısım bu konuda SQL Server Books Online'da yer alan makalenin giriş kısmından çevrilmiştir:

SQL Server 2008 Integration Services'ta, bir Execute SQL görevindeki SQL ifadesi MERGE ifadesini içerebilir...

"Tipik olarak MERGE ifadesini bir tabloya bir başka tablodan kaynaklı INSERT, UPDATE ve DELETE işlemleri yapmak istediğinizde kullanırsınız. SQL 2008'den önce bunun için hem bir Lookup dönüşümü kullanmanız hem de birden fazla OLE DB Command dönüşümü kullanmanız gerekirdi. Lookup dönüşümünün görevi satır satır bir karşılaştırma yaparak her bir satırın değişmiş mi yoksa yeni mi olduğunu belirlemekti. Bu sonuca bağlı olarak da OLE DB Command dönüşümleri gerekli INSERT, UPDATE ya da DELETE'leri yapmak için kullanılırdı. SQL Server 2008'de bunlar yerine tek bir MERGE ifadesi kullanılabilir.

Bunun için genelde bir ara tablo oluşturmanız gerekse de özellikle yüklü Lookup işlemlerine göre daha performanslı bir çalışma elde edebilirsiniz."

Konuyu daha geniş çaplı incelemek isterseniz, SQL Server Books Online'da "Using Merge in Integration Services Packages" başlığını aratabilirsiniz.

SQL Server 2008 veri ambarları için önemli bir yenilik: Change Data Capture

2008-09-10T02:36:00.000-07:00

Bir veri ambarınız varsa, bir de yükleme periyodunuz vardır. Belirli aralıklarla kaynak sistemlerdeki yeni verileri veri ambarına taşımanız gerekir.

Ne kadar da zahmetli bir iştir bu. Kullanımı pahalı triggerlar ve joinler gerektirir. Hatta eğer tablolarınızda son değişiklik zamanını tutan bir kolonunuz yoksa, tabloya kolon eklemeniz de gerekebilir.

SQL Server 2008 bu periyodik yüklemeleri kolaylaştırmak için bir özellik getiriyor: Change Data Capture; sizin için kaynak sistemlerdeki belirlediğiniz tablolarda oluşan değişimleri gerekli ayrıntılarıyla birlikte sorgulayabileceğiniz şekilde log'lar.

Ancak! CDC özelliği kaynak veritabanında bulunması gereken bir şeydir. Yani diyelim ki 3 veri kaynağınız ve bir veri ambarınız var. Veri ambarınızın SQL 2008 olmasıyla bu işi yapamazsınız. Değişiklikleri takip ettiğiniz veri kaynaklarınızın SQL Server 2008 olması gerekir.

Bu sebeple CDC'nin hayatımıza tam olarak girişi, veri kaynağı sistemlerimizin yükseltmelerinin yapılmasıyla gündeme gelebilecektir. Ayrıca SQL Server dışında veri kaynakları kullanıyorsanız, onlarda Change Data Capture benzeri bir özelliğin bulunması gerekecektir bu imkanlardan yararlanmak için.

CDC insert, update ve delete komutlarını yakalar. Hatta takip ettiğiniz tablodaki DDL değişikliklerini de loglar.

Kullanabilmek için ilgili veritabanında bir kere aktive etmeniz gerekir. Bunun ardından da takip etmek istediğiniz tabloların herbiri için CDC'yi aktive etmelisiniz.

Değişiklikleri bildiğimiz ilişkisel tablo biçiminde tutar. Update işlemleri için önceki hali ve sonraki hali ifade eden birer satır tutar.

Yaptığınız ayara bağlı olarak tüm değişiklikleri ya da net değişiklikleri sorgulama şansı sunar. Ne demektir bu? Diyelim ki bir kayıt eklediniz ve aynı gün içinde o kaydı bir de güncellediniz. Gece veri aktarımı paketini çalıştırırken ister tüm değişiklikleri alırsınız (yani her iki değişikliği) isterseniz sadece net değişiklikleri alırsınız (yani satırın sadece son halini).

Değişiklikleri sorgularken LSN (Log Sequence Number) aralığına göre sorgularsınız. Belirttiğiniz zamanlara en yakın LSN'leri veren fonksiyonlardan yararlanma şansınız bulunmaktadır.

Ayrıca CDC tablolarının belirli aralıklardaki değerlerini boşaltmak için kullanabileceğiniz fonksiyonlar da vardır.

Son bir not: SQL 2000'den SQL 2005 ya da SQL 2008'e geçmek konusunda karar vermeniz gerekirse, 2008'de olup 2005'de olmadığına dikkat etmeniz gereken önemli bir özelliktir CDC. Sadece CDC yüzünden bile doğrudan 2008'e geçmeyi düşünme ihtimaliniz vardır. Tabii veritabanlarınızın ve uygulamalarınızın 2008'e uyumlu olduğundan emin olduktan sonra...

Balanced scorecard'ın balanced'ı nedir?

2008-09-09T02:06:00.001-07:00

Öncelikle balanced scorecard (dengeli karne) nedir?

Balanced scorecard Robert Kaplan ve David Norton'un ortaya koyduğu bir kavramdır. İlk olarak Harvard Business Review'de 1992'de yayınladıkları bu yaklaşımla ilgili 1996'da bir kitap da yazmışlardır: The Balanced Scorecard: Translating Strategy into Action.

Temel yola çıkış noktaları şudur: Ölçemediğiniz bir şeyi iyileştiremezsiniz. Yani işin scorecard kısmı bununla ilgili. Firmalar ana metriklerini ölçmeli ve bunları iyileştirmeye çalışmalıdırlar.

Peki ya balanced kısmı nedir?

Şirketler onlarca yıldır zaten ölçümler yapmaktadırlar ama ağırlıklı olarak finansal ölçümlerdir bunlar ve üç aylık dönemler halinde incelenirler. Oysa diyelim Ocak-Mart dönemi kötü geçtiyse, bunun sonucu ancak Nisan ortaları gibi ortaya çıkmakta ve bu kötü duruma katkıda bulunan bazı veriler neredeyse 4 aylık, çok eski veriler olmaktadır. Yani finansal veriler gecikmeli verilerdir.

Bu durumda önerilen, dört ana başlıkta dengeli bir ölçümlemedir:

- Finansal ölçütler
- Müşteri ölçütleri
- İç süreç ölçütleri
- Öğrenme ve gelişme ölçütleri

Finansal ölçütler gecikmeli ölçütlerken diğerleri gerçek zamanlı hatta öncül ölçütler olabilmektedir. Mesela güçlü satış verileri ve artan müşteri şikayetleri, ileriki dönemlerde satış sıkıntıları yaşanacağını gösterebilir.

İş zekası raporlarının gösterimlerinde kavramlar

2008-09-09T01:37:00.000-07:00

KPI, scorecard, dashboard, report, portal... Hepsi biraz birbirine karışıyor sanki değil mi?

Bu tür yapıları etkin bir şekilde kullanan bir organizasyondaysanız, kafanız berrak olabilir. Ama konuya yeni girenler için kavramlar biraz birbirine karışabiliyor.

Eğer zaten bu kavramları net olarak biliyorsanız, pas geçebilirsiniz bu yazıyı.

KPI nedir başlıklı bir yazı yayınlamıştım zaten. Orada çok daha geniş bilgi veriyorum, ama kısaca söylemek gerekirse, KPI değer, hedef, eğilim ve grafik gösterimden oluşan bir bilgidir. Trafik ışığı, kadran gibi verinin sayısal değerinden çok hedefe göre durumu görsel olarak gösteren unsurlardır KPI'lar.

Report yani rapor ise görsel yönleri de olabilmekle birlikte daha çok sayısal verileri sunar ve genelde KPI'lardan daha detaylıdırlar.

Scorecard yani karne, KPI'ların belirli perspektiflere göre gruplanarak sunulmasıdır. Bazı durumlarda KPI'lara ağırlık puanları verilerek detaylardan özete doğru KPI seviyeleri de oluşturulabilir. (Şirketin genel görünümü sarı, detaya baktığınızda satışlar sarı, müşteri memnuniyeti yeşil, yeni ürün geliştirme süresi kırmızı vb gibi.)

Dashboard yani konsol, karneler, raporlar ve KPI'lar içerebilir. Konsol ve portal bazen birbirlerinin yerine kullanılan kavramlar haline de gelebilir. Ama genelde portal, konsolun yanısıra kişilerin duyurulara, epostalarına vb erişebileceği alanlar da içeren daha üst bir yapıdır.

Bir iş zekası uygulamasının en zor kısmı, veriambarı oluşturmak ve sağlıklı olarak güncellenmesini sağlamaktır. Ama iş burada bitmez. Görece daha kolay olmakla birlikte, iyi bir sunum da çok önemlidir. Unutmayın ki algı gerçektir ve arkadaki yapı ne kadar iyi olursa olsun, asıl önemli olan kullanıcıların sistemi nasıl algıladığıdır. Bu da tamamen iş zekası sisteminin önyüzü ile ilgilidir.

Hatalı veriler veriyorsanız, kimse sisteme güvenmez. Bu anlamda altyapı çok önemlidir. Doğru bilgiyi, doğru zamanda, doğru kişilere ulaştırmanız gerekir. Ama iyi bir arayüzünüz yoksa, bu kadar büyük başarıyla ilerlediğiniz bir işte, son anda havluyu atmışsınız gibi olur. Bu maraton koşan bir kişinin, stada girdikten sonra çöküp kalması gibidir. Yarışı bitirmediği için stada ilk giren olmasının hiçbir değeri olmaz.

Kullanılmayan iş zekası sistemi, yok hükmündedir.

SQL 2008'de RTM'de Change Data Capture stored procedure isimlerinde değişiklikler

2008-09-07T02:24:00.000-07:00

SQL 2008'in ctp'lerinde change data capture özelliğini incelemiş olabilirsiniz. Temelde yaptığı şey, sadece birkaç konfigürasyon prosedürünü çalıştırarak, veritabanında istediğiniz tablolardaki değişiklikleri loglayan tablolar oluşturmaktır. Böylece triggerlarla falan uğraşmanıza gerek kalmaz.

CTP ile RTM arasında bir takım farklılıklar var. Şu an elimin altında CTP kurulu bulunmadığı için tam bir liste veremeyeceğim. Ama yaygın kullanılan iki procedure'ün isminin kısaldığını söyleyebilirim.

sp_cdc_enable_db_change_data_capture yerine sp_cdc_enable_db

sp_cdc_enable_table_change_data_capture yerine sp_cdc_enable_table

Önceden kullandığınız script'ler böyle bir stored procedure yok hatası verdiğinde şaşırmayın.

KPI nedir?

2008-09-03T23:57:00.000-07:00

Key Performance Indicator'ın kısaltılmışıdır.

Türkçesi: Anahtar performans göstergesi. Adının açılımından anlaşılacağı üzere hedefe göre nerede olduğumuzu değerlendirmek için kullanılır.

Teknik olarak bir KPI çok basittir. Bir değer içerir. Şu anki değerin ne olduğunu. Ama bu tek başına çok anlamlı değildir. Bir de hedef içerir. Bu değer hedefe göre ne durumdadır. Şimdi bilgi biraz zenginleşti. Ama bu kadarla kalmaz, bir de trend (eğilim) bilgisini içerir. Yani değer hedefe göre belirli bir konumda, ama bir önceki konumuna göre daha olumlu durumda mı yoksa daha olumsuz durumda mı? Bu bilgi de KPI'da vardır. Değer, hedef ve eğilimin yanı sıra KPI bu sayısal bilgilerin grafiksel gösterimlerini de içerir.

Şu ikili KPI'yı tek bir grafik olarak düşünün mesela:

Bir şirketin satış hedefleri ve karlılık hedefleri var. İki ibreli hız kadranı şeklinde bir KPI yapılıyor. Kadranın sağ tarafı hedefi ifade ediyor. İbrenin açısının oraya ne kadar yakınlaşmış olduğu hedefe ne kadar yakın olduğunuzu gösteriyor. Ve ibrenin renginin yeşil olması iyileşmekte olduğunu, kırmızı olması ise kötüleşmekte olduğunu gösteriyor.

Bir de şunu düşünün, bu kadran yuvarlak bir duvar saati gibi, satış ofisinin duvarına kocaman asılmış.

Basitçe değer, hedef, eğilim ve grafikten olan bir KPI'ın ne kadar derin bir anlamı ve etkisi olabileceğini hayal edebildiniz mi?

Basit güzeldir. Bu güzel KPI'ların bizi yönlendirdiği iki derinlik var: Birisi teknik derinlik diğeri ise işle ilgili derinlik. Şimdi bunları anlatalım:

Teknik derinlik:

Bir KPI'ın işe yarar olması için iki koşul vardır. Bu koşullardan birisi tamamen teknikle ilgili, diğeri ise hem teknik hem iş yönüyle ilgili. Teknik yönle ilgili koşul, KPI'ın veri beslemesinin tam otomatik olması, insan eli değmemesidir. Hem teknik hem de iş yönüyle ilgili ikinci koşul ise KPI'ın durumlarına karşılık aksiyon alınabilecek sistemler bulunmasıdır.

Kafamızda iyi canlanması için herkesin sıklıkla gördüğü KPI'lardan birini örnek verelim: Arabanızın hız göstergesi. Evet, hız göstergesi her yönüyle tipik bir KPI'dır. Üstelik basit görünümünden öte yukarıda belirttiğimiz iki şart açısından düşünüldüğünde mükemmel bir KPI'dır.

Hız göstergeniz hızınız neyse onu gösterir. Bunu tam otomatik olarak yapar ve gerçekleşen durumu bilgi olarak size çok hızlı yansıtır. Birinci şartı bu şekilde yerine getirmiş oluyor.

İstediğinizden fazla bir hızda olduğunuzu görünce gazdan ayağınızı çekerek ya da frene basarak hızınızı düşürebilirsiniz. Düşük bir hızda gittiğinizi görürseniz, gaza biraz daha basarak hızınızı artırabilirsiniz. Bir köprü nasıl çevre yollarıyla birlikte işe yararsa, KPI da kendisiyle doğrudan ilgili olmayan bu tür tepki sistemleriyle birlikte değerlidir. Hız göstergemiz bu yan sistemler sayesinde ikinci şartı da yerine getirmiştir.

İşle ilgili derinlik:

KPI'ya verilebilecek tepkiler tamamen işle ilgilidir. Bunlar çoğu durumda sadece teknik sistemler değildir. Ödül sistemleri, performans değerlendirmeleri, iş akti fesihleri, SLA'ler (Service Level Agreement) hep bununla ilgilidir. Kimi zaman bilgisayar programları ya da otomasyon, robot sistemlerinde otomatik olarak bazı önleyici ya da düzeltici rutinlerin tetiklenmesi de bu tür tepkilerin örnekleri olabilir.

Ama işle ilgili derinlik burada bitmez. KPI'lar bütçelerin yerine geçme potansiyeline sahiptir.

İşe alma konusunu düşünelim. Hayal edin:

Bulunduğunuz ülkede en yakın bir rakibinizle diş dişe mücadele eden bir şirketsiniz. Kesin ve katı bütçe kurallarıyla yönetiliyorsunuz. Dönemin ortasında karşı şirketten önemli bir satış yöneticisi şirketiyle anlaşmazlığa düştü ve işten ayrılmak üzere. Bunun tüyosunu aldınız. Ama o da ne. Bütçenizde bu insanı alabilecek kaynak yok. Sene başlamadan altı ay önce öngörebilip bütçeye koymuş olsaydınız, alabilirdiniz, kimse sorgulamazdı. Ama şimdi bütçenizde böyle bir kaynak yok. Bu kaynağın ayrılması için bütçe değişiklik sürecini tetikleseniz, en az 3 ay sürecek. Bu kadar baş ağrısına değmeyeceğini düşünüp elemanı pas geçiyorsunuz. O da tutup kendi şirketini kuruyor. Uzun vadede rakip olamayacağından eminsiniz. Ama batana kadar birkaç sene hem sizin hem de rakip firmanın kar paylarını sallayacak.

Bir de işe alma kararlarının bütçe ile değil KPI'yla yönetildiğini düşünelim. Mesela işe alma için 6 aylık getiri beklentisi, 1 yıllık getiri beklentisi, kişiye yatırım maliyetleri beklentisi gibi konularda KPI'larınız olsun. Kuralınız da bu KPI'ları karşılayan kişileri, gerekirse kredi alarak işe almak olsun. Aradaki farkı hissedebiliyor musunuz?

Bütçeyi tamamen ortadan kaldırmış olarak çalışan şirketler var bugün dünyada.

İşte böyle... KPI hem çok basit hem çok derin bir şeydir. Ve basit güzeldir.

Teknik yol haritası:

KPI'lar gerçekten hoşunuza gitti ve yararlanmayı düşünüyorsunuz. Ürün olarak Microsoft teknolojileri kullandığınızı düşünelim. Hatta belki yola çıktınız bile, kullanımın bir yerlerindesiniz.

Olası duraklarınızı söyleyeyim:

Muhtemelen Excel'de tutuyor olduğunuz bazı verileri, değer-hedef-eğilim-grafik dörtlüsüne büründürerek elle üretilen KPI'lar kullanmaya başlayacaksınız. Sonra fark edeceksiniz ki, Microsoft'un SharePoint diye çok iyi bir ürünü var. SharePoint üzerinde raporlarınızı ve KPI'larınızı birlikte bir portal ortamında sunabilirsiniz. Başka bir sürü yararlı özelliği de cabası.

Ama zamanla fark edeceksiniz ki, elle oluşan veriler üzerinde KPI oluşturmak çok anlamlı değil. İnsanlar makyaj çalışmaları yapabiliyorlar böyle bir durumda. Üstelik incelediğiniz hedefler de daha zenginleşmeli. Sadece gerçekleşen satışların KPI'larını tutmanın faydası sınırlı. Bunun yerine satışları tetikleyen etkinliklerinizi belirleyip bunlarla ilgili KPI'lar kullanmak istiyorsunuz. Mesela aylık yeni tanışılan müşteri sayısı, mesela çalışılan bir müşteriyle gerçekleştirilen ciro için aylık artış oranı hedefleri, mesela satış eğitimlerinde başarı seviyesi...

Bu durumda iki yönde derinleşmeniz gerekiyor:
Planlama ve karneleme. Bunun için PerformancePoint Server kullanabilirsiniz.
Tam otomasyonlu bir iş zekası (veri ambarı) sistemi. Bunun için de veritabanları, diğer veri kaynakları, SQL Server Analysis Services ve SQL Server Integration Services kullanabilirsiniz.

Bu ürünlerin derinliklerine bu yazıda girmeyeceğim. Ama web günlüğümde (http://mustafaacungil.blogspot.com) sağdaki etiketler kısmında iş zekasını, SSAS'i, SSIS'i ve PerformancePoint Server'ı etiket olarak görebilirsiniz.

İyi okumalar.

Excel data mining add in for SQL Server 2008

2008-09-03T03:20:00.000-07:00

Excel'in data mining add-in'inden sanırım daha önce de bahsetmişimdir. Ben bahsetmemiş olsam da, veri madenciliğiyle ilgiliyseniz umarım duymuşsunuzdur.

Bu aracı kullanarak veri madenciliğinin detayları hakkında neredeyse hiçbir şey bilmeden, binlerce satırlak bir veri tablonuzda desen analizleri yapmanız, aykırı verileri belirlemeniz, eğilim analizleri yapmanız, etkin faktörleri belirlemeniz mümkün.

SQL 2008'e yönelik olarak Excel data mining add-in'in yeni bir sürümü çıktı. Bu sürümdeki en önemli fark bence tekil örnekleri puanlandırma olayı. Şöyle ki: Diyelim ki, bir satın alma kararını etkileyen faktörlerin hangi kolonlar olduğunu tespit ettiğiniz. SQL 2008'e yönelik add-in bunların ağırlıklarını belirleyerek, elinize gelen yeni bir veri örneğinin detaylarını girdiğinizde satın almasının olası olup olmadığıyla ilgili tahmini size kolaylıkla veriyor. (Bu özelliğin adı: Prediction Calculator)

Yani ne yapabilirsiniz? Mesela telefonla arayarak satış yaptığınız insanların çeşitli özellikleri elinizde olsun. Diyelim ki bir kolonda, bu insanların yaptıkları alışveriş tutarına göre (sıfır dahil) sınıflandırıldıkları bir bilgi var. Bu kolonu etkileyen önemli diğer kolonları araç üzerinden analiz ettiniz. Etkin faktörler ve ağırlıkları belirlendi. Anlaşmalı olduğunuz bir firmadan aranacak yeni kişilerle ilgili bilgiler geldi. Bu kişilerin etkin olarak belirlediğiniz özelliklerle ilgili bilgileri de dolu. Kişilerin bu belirli bilgilerini sisteme girerek satın almada dereceleri ile ilgili bir tahmin elde etmeniz mümkün.

Excel data mining add-in'i incelemediyseniz Microsoft'tan ücretsiz olarak indirip bir inceleyin derim.

Gereklilikler:

- Excel 2007'ye sahip olmanız. Önceki sürümlerde çalışmıyor.
- Arkada bir SQL Server 2008 (ya da önceki sürüm için SQL Server 2005) bulunması ve bunun üzerinde Analysis Services'in kurulu olması.
- Bağlanacağınız araçta kurulum sihirbazının çalıştırılmış olması. Bu kurulum sihirbazı hangi Analysis Services'a bağlanılacağını belirliyor ve bu Server üzerinde geçici hesapların yapılacağı veritabanını belirleyip kullanacak kişiye bu veritabanı üzerinde hak veriyor.

SQL Server 2008 mirroring'de otomatik sayfa kurtarma

2008-09-03T01:58:00.000-07:00

SQL Server 2005'te bozulmuş bir sayfayı tek başına yedekten dönebiliyorduk. SQL 2008'de bunun daha da ilerisi yapılmış durumda.

Diyelim ki bir veritabanının mirror'ını oluşturmuş durumdasınız. Bu durumda veri sayfalarında oluşabilecek bir fiziksel bozukluk durumunda, SQL Server 2008 otomatik olarak (sizin müdahalenize hiç gerek olmadan) sayfayı mirror'dan tekrar yüklüyor. Sorunu hissetmeden çalışmaya devam edebiliyorsunuz.

Ayrıca SQL Server 2008'de mirror iki veritabanı arasındaki network iletişim yükünü hafifletecek şekilde sıkıştırarak veri gönderme imkanı da kullanılıyor.

Mirroring (aynalama) kullanıyorsanız SQL Server 2008'in size getireceği imkanları inceleyin. Sadece bu sebeple bile daha erken bir tarihte SQL 2008'e yükseltme yapmayı düşünebilirsiniz.

SQL Server 2008'de spatial data (uzam verisi)

2008-09-03T01:15:00.000-07:00

Bir önceki yazıda veritabanlarının artık yapısal olmayan verileri de yoğunlukla tutmaya başladığını söylemiştim. Spatial data ya da uzam verisi de bu tür veriler sınıfına sokulabilir. Ama filestream kadar yapısal olmayan bir veri değil karşımızdaki. Daha çok yeni yeni yapısallaştırılan, standartları oturan bir veri tipiyle karşı karşıyayız.

SQL Server 2008 uzam verisi için iki veri tipi sunuyor: geometry ve geography. Aralarındaki fark şu: Geometri Euclid sistemini esas alıyor, yani bir düzlem üzerinde çalışıyor. Geography ise dünya yüzeyini esas alıyor, yani dünya yüzeyinin bükümünü de dikkate alıyor.

Basit bir arsa hesabı için geometriyi kullanmanız düşünülebilecekken, şehirler arası ya da ülkeler arası seviyede bir çalışmada geography'yi kullanmanız daha uygun olacaktır.

Uzam verisinin standartlaşmaya başladığını söylemiştik. SQL Server bu veri biçimlerinden OGC (Open Geospatial Consortium), WKT (well known text) ve WKB (well known binary) ile konuşabiliyor.

Bu tür sistemlerden gelmiş verileri STGeomFromText, STPointFromWKB, STPolyFromText gibi çeşitli yöntemlerle SQL Server geometry ve geography tiplerine dönüştürmek mümkün.

Uzam verisini sorgulamak ya da üzerinde çalışmak için çok güzel imkanlar sunuluyor. Bunlardan bazıları:

- STIntersection: Var olan iki örneğin kesişimini yeni bir örnek olarak verir. Bu şekilde mesela yeni satın aldığınız bir şirketin satış bölgeleri ile kendi şirketinizin satış bölgelerinin kesişim alanlarını bulmanız mümkün olabilir.
- STIntersects: İki örneğin kesişip kesişmediği bilgisini verir. Diyelim kendi süpermarket noktalarınızın hizmet verdiği alanlar ve rakip bir süpermarket zincirinizin noktalarının hizmet verdiği alanlar bir saha çalışması sonucu elinizde oluştu. Bunların kesişimlerinin olup olmadığını inceleyebilirsiniz.
- STDistance: İki nokta arasındaki en kısa mesafeyi verir.
- STLength: Bir çizginin uzunluğunu verir.
- STArea: Bir örneğin toplam yüzey alanını verir.

Uzam verilerini kullanarak yapılabilecek o kadar iş var ki!

Yer belirleme sistemlerini düşünün... Lojistik hizmetlerini düşünün... Depolama hizmetlerini düşünün...

Küçük bir örnek:

Türkiye'de özel bir liman konteyner'ların yerleşimini üç boyutlu olarak bilgisayardan takip edebildiği için konteynerları birbirlerinin görünümünü kapatacak şekilde yerleştirebiliyor. Oysa kimi büyük limanlarda bu imkan olmadığı için konteynerlar görüntüleri kapanmayacak şekilde yerleştirilmek zorunda kalıyor. Çok değerli liman alanının ne kadar etkin kullanılabildiği, doğrudan karlılığı etkileyecek bir unsurdur. Ayrıca bir konteynerın konumunu belirlemek için o koca konteyner kuleleri arasında insanların dolaştırılması kaza riskini de artırmaktadır.

Küçük bir örnek sadece... Başka neler yapılabileceğini düşünün!

SQL Server 2008'de filestream

2008-09-03T00:52:00.000-07:00

Veritabanı sunucuları artık sadece yapısal verileri değil yapısal olmayan verileri de tutmaya yöneliyor. Bu da gayet normal, hatta gerekli. Çünkü günümüzde oluşan verilerin büyük bir kısmı yapısal olmayan veriler kapsamına giriyor: Ses dosyaları, görüntü dosyaları, resimler...

SQL Server 2008 bu tür verileri tutmak için özel bir yapı getiriyor: Filestream.

Temel mantık şu: Veriler SQL Server'da değil, NTFS disk sisteminde duruyor. Ama bu verilere erişimi SQL Server üzerinden yapıyorsunuz. Böylelikle hem verileriniz daha bütüncül oluyor, hem onlara daha hızlı erişebiliyorsunuz hem de SQL Server'ın sağladığı transaction yönetiminden yararlanmış oluyorsunuz.

Aşağıdaki kod filestream'i nasıl kullanabileceğinize dair bir örnek içeriyor.

-- Öncelikle sunucuda filestream özelliğini açmanız gerekiyor. 0 kapatmak, 1 sadece TSQL erişimine izin vermek,
-- 2 hem TSQL hem de API erişimine izin vermek anlamına geliyor.

EXEC sp_configure filestream_access_level, 2
RECONFIGURE

CREATE DATABASE Archive
ON
PRIMARY ( NAME = Arch1,
FILENAME = 'c:\data\archdat1.mdf'),
-- Veritabanı filestream destekleyen bir filegroup'a sahip olmalı
-- Bu örnekteki C'nin altında data klasörü önceden oluşturmuş olmalısınız
-- Onun altındaki filestream1 klasörünü ise oluşturmamış olmalısınız
-- Bu alt klasörü SQL Server kendisi oluşturacak
FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM( NAME = Arch3,
FILENAME = 'c:\data\filestream1')
LOG ON ( NAME = Archlog1,
FILENAME = 'c:\data\archlog1.ldf')
GO

CREATE TABLE Archive.dbo.Records
(
-- filestream içeren tabloda uniqueidentifier kullanılması zorunlu
[Id] [uniqueidentifier] ROWGUIDCOL NOT NULL UNIQUE,
[SerialNumber] INTEGER UNIQUE,
-- filestream veri tipini varbinary(max) filestream diyerek belirtiyorsunuz
-- varbinary(max)'ın normalde limiti olan 2GB filestream için geçerli değil
-- filestream'de sınırınız kullandığınız diskin kapasitesi
[Chart] VARBINARY(MAX) FILESTREAM NULL
)
GO

-- Null değer girmek için:
INSERT INTO Archive.dbo.Records
VALUES (newid (), 1, NULL);
GO

-- empty string, varbinary(max)'a cast ederek giriyoruz
INSERT INTO Archive.dbo.Records
VALUES (newid (), 2,
CAST ('' as varbinary(max)));
GO

-- Normal metin, varbinary(max)'a cast ederek giriyoruz
INSERT INTO Archive.dbo.Records
VALUES (newid (), 3,
CAST ('Seismic Data' as varbinary(max)));
GO

SELECT * FROM Archive.dbo.Records
GO

-- Update ve delete işlemlerini nasıl yapacağınız aşağıda:
UPDATE Archive.dbo.Records
SET [Chart] = CAST('Xray 1' as varbinary(max))
WHERE [SerialNumber] = 2;

DELETE Archive.dbo.Records
WHERE SerialNumber = 1;
GO

Dosya sisteminde oluşan dosyaları notepad'le açarak içinde doğru metinlerin bulunduğunu görebilirsiniz. Ufak bir konu daha: Filestream'in bulunduğu yere normalde sadece SQL Server'ın servisine NTFS izni verilmiş olacaktır. Başka izinler vermeniz tavsiye edilmez.

SQL Server 2008'de zengin audit yetenekleri

2008-09-02T07:29:00.000-07:00

Veritabanı yönetiminde önemli konulardan biri de veri ile neler yapıldığını denetleme gereksinimleridir. SQL Server 2008 bu konuda zengin imkanlar sunuyor.

Management Studio'da Server'ın altında Security düğümünde Audits'i sağ tıklayarak new audit dediğinizde bir dosyaya, security log'a ya da application log'a audit oluşturabiliyorsunuz. Bu sadece bilgileri nereye yazacağınızla ilgili bir ayar.

Bunu yaptıktan sonra diyelim ki, belirli bir tabloda update işlemlerini audit'e dahil etmek istediniz.

İlgili veritabanında Security düğümünün altında Database Audit Specifications'ı sağ tıklayarak yeni bir örnek oluşturabilirsiniz. Ekleyeceğiniz bu audit spec'te öncelikle daha önce oluşturduğunuz audit'e yazacağını belirtiyorsunuz. Ardından audit action type'tan Update'i seçebilirsiniz. Object class'ından Object'i seçin. (Diğer seçenekler Database ve Schema.) Sonra da istediğiniz tabloyu seçin. Hatta takip etmek istediğiniz belirli bir principal'ı da seçebilirsiniz.

Hem audit'i hem de spec'i enable ettikten sonra, artık bu tablo ile ilgili belirttiğiniz kişi tarafından yapılan update'leri belirttiğiniz audit yerinden izleyebilirsiniz.

Ne tür işlemleri audit'e alabileceğinizi incelemek için SQL Server 2008 Books Online'da "SQL Server Audit Action Groups and Actions" ifadesini aratabilirsiniz. Audit gereksinimleri olan bir dba'seniz, ya da güvenlik biriminde SQL Server'da audit yapma ihtiyacı olan bir kişiyseniz, karşınıza çıkan seçeneklerden hoşlanacağınızı düşünüyorum.

Virtual Server 2008'e bağlanma problemi yaşıyorsanız

2008-09-02T05:11:00.000-07:00

Virtual Server 2008'i kurdunuz. Herhangi birhata mesajı da almadınız. Şimdi yönetim bağlantısını açmaya çalışıyorsunuz. Ancak bağlanamıyorsunuz.

Öncelikle proxy ayarlarınıza bakın. Proxy'den pek hoşlanmıyor Virtual Server. Eğer aldığınız hata mesajı proxy kaynaklı ise bu şekilde aşabilirsiniz.

Bir diğer konu ise yetkiler. http://support.microsoft.com/kb/891609 adresinde yetkiler konusunda nereden düzenleme yapabileceğinizi bulabilirsiniz. Benim sorunumu çözdü. Denemenizi tavsiye ederim.

SQL Server 2005'te cache'te bulunan sorguları görmek

2008-08-30T01:58:00.000-07:00

SQL Server 2005'te cache'te bulunan sorguları görüntülemek, bunlarla ilgili çeşitli bilgileri almak için dynamic management view'leri kullanabilirsiniz.

sys.dm_exec_cached_plans size o an cache'te yüklü olan sorguları verecektir, ama metinlerini değil. Plan handle'larını gördüğünüz bu sorguların metinlerine de ulaşmak için kullanmanız gereken bir function var: sys.dm_exec_sql_text.

İkisini birlikte şu sorgudaki gibi kullanabilirsiniz:

SELECT cached.*, sqltext.*
FROM sys.dm_exec_cached_plans cached
CROSS APPLY sys.dm_exec_sql_text (cached.plan_handle) AS sqltext

Plan handle veren başka dynamic management view'ler de vardır. Mesela query istatistikleriyle ilgili olan. Onda da benzer şekilde sql metinlerine ulaşmanız mümkün.

sys.dm_ diye başlayan dynamic management view'ler güzel imkanlar sunuyor. Özellikle dm_exec diye devam edenler o anki yürütme işlemleriyle ilgili önemli bilgiler verebilmekte. Session'lar, query planlar, query istatistikleri gibi...

SQL Server 2008'te Resource Governor'ı kullanarak ne yapabilirsiniz?

2008-08-22T03:19:00.000-07:00

Resource Governor'ın temel amacı, SQL Server'ın çalışan oturumlar arasında kaynak kullanımını daha optimum seviyede yönetebilmesidir.

SQL Server kaynakları en optimum şekilde kullanmaya zaten çalışır, ama oturumlar arasında önceliklerle ilgili SQL Server'ın bilemeyeceği konular vardır. Hangi uygulamaların, hangi oturumların, hangi istemci makinelerin daha önemli olduğunu SQL Server bilemez. Resource Governor'ı kullanarak şirketinize özel bu tür bilgileri SQL Server'a tanıtabilir ve oturumları nasıl kısıtlayacağını tarif edebilirsiniz.

Öncelikle oturumlar arasında bir sınıflama yapmanız gerekir. Bu sınıflamaya bağlı olarak da hangi tip oturumların kaynakların ne kadarını kullanacağını belirler ve bu doğrultuda SQL Server üzerinde Resource Governor'ı uygularsınız.

Sıklıkla olduğu gibi burada da planlama ve uygulama süreçleri birbirinin tersine işler. Planlama yaparken öncelikle oturumların sınıflamasından yola çıkarsınız. Oysa uygulama yaparken önce kaynak kısıt gruplarını oluşturursunuz.

Biz burada iki sıralamadan birini tercih etmek zorunda olduğumuzdan, uygulama sırasıyla anlatacağız. Bu aşamaya gelmeden önce planlamayı kendi sırasına göre yapmış olmanız gerektiğini unutmayın.

Uygulamada öncelikle Resource Governor'ı enable edersiniz. (Resource Governor'la ilgili işlerin neredeyse tamamına yakınını SQL Server Management Studio'da servera bağlı management düğümü altındaki Resource Governor bölümünden gerçekleştirirsiniz.)

Ardından Resource Pool'ları oluşturursunuz. Bir resource pool minimum ve maksimum CPU yüzdesini ve yine minimum ve maksimum bellek yüzdesini ifade etmekte kullanılır. Bu kısıtlar yarışma durumunda kullanılır. Eğer sistemde yarışan bir istek yoksa bu limitlerle sınırlı kalınmaz, ama yarışma durumu olduğu anda bu limitler uygulanır.

Resource Pool'larla kaynakların kullanım limitlerini sınırladıktan sonra, herbirinin altında Workload groupları (işyükü grupları) oluşturabilirsiniz. İşyükü gruplarının da kendine özel bazı seçenekleri belirtilebilmektedir.

Önemli bir eksiklik var: Oturumları işyükü gruplarına nasıl atayacaksınız? Öyle ya, bir oturum öncelikle bir işyükü grubuna dahil olmalı ki, o iş yükü grubunun özellikleriyle ve atanmış kaynak kısıtlarıyla çalışabilsin.

Bu kısmı Management Studio'dan yapmak mümkün değil. Bunun için bir classifier function (sınıflandırıcı fonksiyon) yazmak gerekiyor. Sistemde bir anda tek bir sınıflandırıcı fonksiyon etkin olabiliyor. Yani tek bir fonksiyonda oturumları sınıflandırmak için kullandığınız ne kadar koşul varsa belirtmek durumundasınız. Bu fonksiyonu yazarken aşağıdaki bağlantı özelliklerini kullanabiliyorsunuz:

HOST_NAME
APP_NAME
SUSER_NAME
SUSER_SNAME
IS_SRVROLEMEMBER
IS_MEMBER

Yani grup üyelikleri, bağlanan kullanıcı, hangi iş istasyonundan bağlandığı, hangi uygulamanın bağlandığı gibi seçeneklere göre oturumun hangi işyükü grubuna dahil olacağını belirlemiş oluyorsunuz.

Önemli bir konu aklınıza gelmiş olabilir: Resource Pool'lar işlemci ve bellek bazında kısıtlama yapıyorlar. Yani disk IO bazında kısıtlama yapmıyorlar. Çoğu durumda bu sorun olmayacaktır. Çünkü işlemci ve bellek kullanımı ile disk IO kullanımı paralellik gösterecektir. Ama bazı durumlarda işlemci ve bellek yükü sınırlar dahilindeyken IO yükü fazla olabilir. Aklınızda bulunsun.

Not: Resource governor'ı adım adım nasıl kullanacağınızı anlatmadım. Bununla ilgili olarak Books Online'da yeterince detaylı açıklamalar bulabilirsiniz. Kavramı ve temel bileşenlerini anladıktan sonra uygulamak son derece kolay.

SQL Server 2008'de Surface Area Configuration nereye gitti?

2008-08-21T05:35:00.000-07:00

Artık yok diye duymuş olabilirsiniz. Kısmen doğru.

Aslında Surface Area Configuration hala var. Ama ayrı bir konfigürasyon arayüzü olarak değil. Surface Area Configuration'la ilgili olarak yaptığınız işleri artık Policy Based Management ile yapıyorsunuz. Policy Based Management'ta Facet diye bir kavram geliyor. Facet'ler birer özellik kümesi olarak düşünülebilir. Biribiriyle bağlantılı olan özellikleri paketleyen unsurlar.

Surface area configuration da artık bir facet. Ve Policy Based Management'ın sağladığı imkanlar içinde bir imkan.

Ayrı bir surface area configuration arayüzünüz yok ama onun yaptığından yüzlerce kat fazlasını yapabileceğiniz yeni bir ortam var, ve o da bu yeni ortamın bir parçası olarak yaşamına devam ediyor.

SQL Server 2008'de policy based management

2008-08-21T05:17:00.000-07:00

SQL Server'ın Türkçe sürümü olmadığı için arayüzde kullanacağınız unsurlarla ilgili kavramların İngilizce isimlerini kullanıyorum.

2008'in getirdiği önemli bir yenilikte policy based management.

Policy based management'ın üç önemli faydası var:

- Bir kuralı baştan belirleyip buna aykırı bir eylemin gerçekleşmesini en baştan engelleyebilirsiniz.
- Gözetim amaçlı kullanabilirsiniz. Yani yasaklamazsınız, ama belirli aralıklarla kural dışı uygulama olup olmadığını hızlı bir şekilde inceleyebilirsiniz.
- Engelleme ya da gözetim işlerini merkezi olarak birden fazla sunucu üzerinde yapabilirsiniz.

Policy'leri anlamak için öncelikle üç temel nesneyi kavramamız gerekiyor: Facet, Condition ve Target.

Facet sadece bir özellikler demeti. Birbiriyle ilişkili olan özellikler bir facet altında guruplanıyor. Ama tek başına facet bu özelliklerin değerlerine ilişkin hiçbir şey ifade etmiyor.

Condition belirli bir facet altındaki bir ya da birkaç özelliğin hangi değerlerde olmasını istediğinizi ayarladığınız nesne.

Target ise policy'i hangi nesnelere uygulayacağınızı belirliyor.

Bir policy, bir condition'ın belirlenen target'ta bir evaluation mode'u ile uygulanması anlamına geliyor. Target alanında filtreleme yapabiliyorsunuz. Ayrıca policy'lerin category'leri de olabiliyor. Policy'leri enable ya da disable etmeniz mümkün.

Öncelikle evaluation mode'dan bahsedelim. Bu ayar, policy'nin çalışma şekliyle ilgili dört seçenek sunuyor:

- On demand: Bu durumda policy ile ilgili bir otomasyon yok. Değerlendirilmesini istediğiniz zaman elle tetikliyorsunuz.

- On schedule: Bir SQL Server Agent job'ı ile zamanlanarak policy kontrol edilir.

- On change log only: Bu seçenek event notifications altyapısını kullanır. Değişiklik durumunda sadece loglama yapılır.

- On change prevent: Bu seçenekse DDL triggerlarını kullanır. Değişiklik yapılmak istenen transaction roll back edilir ve policy ile ilgili bir hata mesajı verilir. Bunu kullanabilmeniz için sunucu seçeneklerinden olan nested triggers'ın enabled durumda olması gerekir. (Zaten varsayılan değeri budur.)

Policy'lere category atayabileceğinizden bahsetmiştik. Bunun en temel faydası, category bazında Mandate Database Subscriptions seçeneğini enable ya da disable edebilmenizdir. Mandate etmiş durumdaysanız, targettaki veritabanları zorunlu olarak bu policy'e abone olur. Aksi durumda veritabanı yönetimi seviyesinde politikaya abone olunabilir ya da abone olunmayabilir.

Policy based management, özellikle güvenlik bölümlerinin SQL Serverlarla ilgili belirledikleri kuralların uygulanmasını denetleyebilmeleri açısından büyük fayda sağlayacaktır.

SQL Server 2008'de çoklu sunucu sorguları

2008-08-21T04:59:00.000-07:00

SQL Server 2008'de Central Management Server diye bir kavram var. Mantık şu: Bir sunucuyu Central Management Server olarak atıyorsunuz. Ardından bu sunucu altında diğer sunucuları istediğiniz gibi gruplar halinde oluşturuyorsunuz.

Peki niye böyle bir şey yapalım? İki temel faydası var:

- Bir sorguyu birden fazla sunucuya eş zamanlı olarak gönderip cevapları almak.
- Policy bazlı yönetimde, sunucuları tek lokasyondan kontrol etmek.

Uygulamayı nasıl yapıyorsunuz:

Öncelikle Management Studio'da, View menüsünden Registered Servers'ı seçin. Central Management Servers'ı sağ tıklayıp Register Central Management Server deyin. Merkezi sunucu olarak atamak istediğiniz sunucuyu bu şekilde oluşturun. Ardından oluşturduğunuz sunucuyu sağ tıklayıp New Server Registration diyerek, istediğiniz sunucuları bu sunucuya bağlı olarak oluşturabilirsiniz.

Bir merkezi sunucuya bağlı tüm sunuculara sorgu göndermek için, merkezi sunucuyu sağ tıklayarak New Query demeniz gerekiyor. Sorgu gruptaki sunuculara gönderilip sonuçları size getiriliyor.

Tools > Options > Query Results > SQL Server > Multiserver Results'tan dönen sonuçların nasıl görüntüleneceği ile ilgili 3 özelliği ayarlamanız da mümkün. Sonuçlara login name'ini dahil ettirebilirsiniz. Server name'i dahil ettirebilirsiniz. Sonuçları her sunucu için ayrı sonuç olarak ya da tek bir sonuçta birleşmiş olarak alabilirsiniz.

Çoklu sunucu sorguları için en önemli iki çekince:

- Windows Authentication kullanmak durumundasınız. Ve kullandığınız kişinin yetkileri nelerse onunla kısıtlı alabileceğiniz sonuçlar.

- Bence daha önemlisi: Central management server'ı kendi altına registered server olarak ekleyemiyorsunuz. Bunun Türkçesi: 4 sunucunuz varsa ve birini merkez yapıp diğer üçünü altına eklediyseniz, sorgularınızı bu alttaki üçüne yönelik çalıştırabilirsiniz. Merkez sunucunun kendisined sorgunuz çalışmamış olur. Ya da yönetmek istediğiniz sunucuları merkezi olarak yöneteceğiniz sunucu içlerinden biri olamaz. Başka bir sunucu olması gerekiyor. Aslında başka bir sunucu değil de, en azından başka bir instance olması gerekiyor.

Bunun küçük bir istisnası var: Registered Servers penceresinde Local Server Groups grubuna istediğiniz instance'ları ekleyerek bunlara toplu sorgu göndermeniz mümkün.

SQL Server Installation Center

2008-08-21T02:11:00.000-07:00

SQL Server 2008'le birlikte gelen yeni kavramlardan biri de Installation Center.

SQL Server 2008'i kurmuş olduğunuz makinede, Start > All Programs > Microsoft SQL Server > Configuration Tools altından SQL Server Installation Center'a erişebilirsiniz.

Installation Center'da Planning sayfasında System Configuration Checker'ı tetiklemeniz mümkün. Tabii ki bunun için Setup dosyalarına erişiminiz olmalı, size onları soracaktır. Burada yapabileceğiniz bir başka konu ise Upgrade Advisor'ı kurmak. Bunun haricinde Internette çeşitli SQL Server dokümanlarına erişim için linkler de var.

Installation sayfasında da bir internet bağlantısı var. Bu bağlantıyı kullanarak ürünle ilgili güncellemeler olup olmadığını internetten araştırabiliyorsunuz. Diğer seçenekleri kullanarak ise, Yeni bir SQL Server kurulumu yapmanız, yeni SQL Server failover cluster'ı kurmanız, bir SQL Server failover cluster'a düğüm eklemeniz, SQL 2000 ya da SQL 2005'ten upgrade etmeniz mümkün.

Maintenance sayfası size edisyon güncelleme (edition upgrade), tamir etme ve SQL Server failover clusterından düğüm çıkarma şansları sunuyor.

Tools sayfasından tetikleyebileceğiniz üç araç var: System Configuration Checker'ı başlatabilirsiniz. Installed SQL Server features discovery report'u kullanarak SQL Serverla ilgili (2000, 2005, 2008) kurulu unsurları inceleyebilirsiniz. Upgrade Integration Services packages'ı kullanarak da 2005 paketlerini 2008 paketlerine yükseltebilirsiniz.

Resources sayfasında erişmek isteyebileceğiniz çeşitli SQL Server kaynaklarının bağlantıları bulunuyor.

Advanced sayfasında konfigürasyon dosyasıyla kurulum ve cluster kurulumunu özelleştirerek yapmak gibi imkanlar sağlanıyor.

Options sayfasında ise yapmak isteyeceğiniz kurulumun işlemci tipini ve kurulum medyasının yerini belirtmek seçeneklerin bulunuyor.

Bu tür imkanları derli toplu bir yerde bulmak hoş olsa gerek.

Windows Server 2008'de görsel ortamda runas yapmak istiyorsanız

2008-08-21T00:34:00.000-07:00

Windows Server 2008'de görsel ortamlarda (windows explorer) gibi sağ tıklayarak run as komutunu kullanma şansınız ne yazık ki yok. En azından standart kurulumda yok.

Komut satırından run as yapmanız mümkün olmakla birlikte görsel ortamlarda da bu imkana kavuşmak istiyor olabilirsiniz.

Bununla ilgili küçük bir eklenti kullanmanız mümkün.

http://technet.microsoft.com/en-us/sysinternals/cc300361.aspx adresinden ilgili dosyayı indirebilirsiniz.

İndirdiğiniz dosyayı açıp içindeki exe uzantılı dosyayı \Windows\System32 klasörüne kopyalamanız gerekli. Ancak henüz iş bitmedi. Bir de bir komut satırı açıp shellrunas /reg komutunu çalıştırmanız gerekiyor. Eğer makinede birden fazla kullanıcı oturum açıyorsa ve herbirinin menüde runas'e erişmesini istiyorsanız, onlar için de / reg işlemini tekrarlamanız gerekli.

SQL Server 2008 örnek veritabanları için bağlantı

2008-08-19T01:51:00.000-07:00

Önceki bir kaç yazımda kitap reklamına biraz fazla yer verince, izleyicilerimden bu konuda tepki geldi.

Sevindirici. Blogumu takip edenler olduğunu biliyorum, ama yorum pek yazılmadığı için sadece hit sayılarından anlıyordum durumu.

Son günlerde SQL 2008'e yoğunluğum hayli artmış durumda. Fırsat buldukça bu konuda yazılarımın sayısını artıracağım. (Zaten yazmaya başlamıştım.)

Kısa bir faydalı olabilecek bilgiyle başlayalım. SQL Server'da örnekler artık çok daha hareketli. SQL 2005'te bile Service Pack'le birlikte örnek veritabanlarının da yeni versiyonları geliştirilmişti.

SQL 2008'in (ve SQL 2005'in de) örnek veritabanlarını edinebileceğiniz link aşağıda:

http://www.codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=16040

AdventureWorks ve AdventureWorks DataWarehouse veritabanları yanısıra artık AdventureWorks'ün Lite bir versiyonu da var.

"Felaketten dönebilmek ya da orada kalmak. İşte bütün mesele bu!" üzerine

2008-08-18T04:44:00.000-07:00

Etkilendim.

Alfa Yayınlarından çıkan "Türk MVP'lerden Çözüme Giden Yolda En Değerli Deneyimler" başlıklı kitabın ikinci yazısı da bana ait. İlk iki yazı bana aitti ve sıradan gittiğim için şimdi "Felaketten dönebilmek ya da orada kalmak. İşte bütün mesele bu!" adlı bana ait yazıda sıra.

Yazalı epey olduğu için kendi eserim filtresinin dışına çıkarak okuyabildim. Güzel yazmışım. : )

IT ile ilgili alanlarda felaketten geri dönüş (disaster recovery) önemli bir kavramdır. Bu yazıda disaster recovery hakkında akıcı ve eğlenceli bir içerikle karşılaşacaksınız.

Yoksa siz Türkiye'de IT alanında çalışıyorsunuz ya da IT alanında çalışmayı düşünüyorsunuz ve bu kitabı hala okumadınız mı? Bir an önce almanızı tavsiye ederim.

İş Zekasına Zekice Yaklaşın hakkında...

2008-08-11T12:17:00.001-07:00

Benim yazım diye değil. Kitaptaki sıralamada ilk yazı olduğu için kendi yazımı ilk okudum.

Türk MVP'ler olarak yazdığımız Çözüme Giden Yolda En Değerli Deneyimler adlı kitaptan bahsediyorum. Kendime ait nüshaları henüz almaya vaktim olmadı, ama sağolsun dostum Kadir Çamoğlu, yayıneviyle bir başka konuda yaptığımız toplantıya bir nüsha getirdi. Ben de böylece okumaya başlayabildim.

Aklımda her yazıyla ilgili birer girdi girmek var buraya. En azından bir kısmıyla ilgili girmeye çalışacağım. İlk yazı benim olduğu için ilk onu okudum ve bu girdi de ona ilişkin.

İş zekası kavramlarını çok iyi sunan bir yazı olduğunu düşünüyorum. Özellikle konuya çok uzak ya da çok yakın olmayanlar için ideal. Yani iş zekasını duymuş da acaba bir kariyer olarak düşünsem mi diye kafa yoranlar... Koşa koşa bir kitapçıya gidin, ya da internetten kitap alışverişi yaptığınız yerli sitelerden birine girin. Henüz almadıysanız, Çözüme Giden Yolda En Değeri Deneyimler adlı kitaptan bir tane alın, ya da sipariş edin. İlk yazı olan "İş Zekasına Zekice Yaklaşın" çok işinize yarayacak.

Bu kitabı almanız için onsekiz iyi sebep daha var. Onlardan da sonraki girdilerde bahsetmeye çalışacağım.

Çözüme giden yolda en değerli deneyimler

2008-07-21T06:52:00.000-07:00

Türkiye'de Microsoft MVP'ler olarak ilk kitabımız raflarda yerini aldı. Kitap henüz elime geçmedi, ama rafta gördüm. : )

Yazarlardan biri olarak şu günlerde elime birkaç kopyanın ulaşmasını bekliyorum. Kendi yazdığım iki makaleyi zaten biliyorum. Diğer arkadaşlarınkileri henüz okumadım. Okudukça sizlerle de kitapla ilgili paylaşımlar yapacağım.

Şimdi, kitapla ilgilenenler için buyrun bağlantısı:

http://alfakitap.com/kitap.asp?id=&kitapID=3433
http://www.ideefixe.com/Kitap/tanim.asp?sid=W5T7TZ3X0G3GLMTJJ1NH
http://www.yenisayfa.com/pgs/prda/prd_detail.asp?fr_prdSID=sYsnnCr

İş zekası için boyutlu model tasarımında kesinlikle kaçınılması gereken on önemli hata

2008-06-12T05:01:00.000-07:00

Yine Kimball'den.

Ralph Kimball, iş zekası alanında temel yaklaşımların geliştirilmesinde ekibiyle birlikte çok önemli rol oynayan bir insan.

The Data Warehouse Toolkit (Second edition) başlıklı kitapta 15. bölümün sonunda kaçınılması gereken yaygın boyutlu model hatalarını sıralamış.

Detayına fazla girmeyeceğim, çünkü detayına girebilmek için bu kitabın 15. bölümüne gelmiş olmanız gerekiyor. Ancak iş zekası ile ilgili halen çalışmakta olan ve veri ambarı tasarımı sorumluluğu olan kişiler bu hataların listesini görmekten yarar sağlayabilirler.

İşte kaçınılması gereken temel hatalar. Bu listedekinden başka hatalar da yapabilirsiniz tabii, ama yapmanız durumunda en çok zarar göreceğiniz hatalar aşağıda her adımda daha da kritik bir tanesi olmak üzere sıralanıyor:

Hata 10: Filtreleme ve gruplama için kullanılan metinsel özellikleri fact tablosuna koymak.

Hata 9: Boyutlardaki geniş tarifli özellikleri yer kazanmak amacıyla kısıtlamak.

Hata 8: Hiyerarşileri ve hiyerarşi seviyelerini birden fazla tabloya bölmek (snowflaking).

Hata 7: Boyutlarda yer alan özelliklerin (attribute) zamanla değişimlerini takip etme ihtiyacını göz ardı etmek (slowly changing dimensionları gereği gibi ele almamak.

Hata 6: Sorgu performans sorunlarını doğrudan ve sadece daha fazla donanım ekleyerek çözmeye çalışmak.

Hata 5: Boyut tablolarını fact tablolarına bağlamak için operasyonel anahtarları ya da akıllı anahtarları kullanmak.

Hata 4: Fact tablosunun en küçük birimini (grain) deklare etmeyi ihmal etmek ve ardından fact tablosunun sahip olması gereken en küçük birime her zaman sadık kalmayı ihmal etmek.

Hata 3: Belirli bir raporu esas alarak boyutlu modeli onun için tasarlamak.

Hata 2: Kullanıcıları en detay seviyedeki veriye erişim için normalize sistemlere yönelmek zorunda bırakmak.

Hata 1: Farklı fact tabloları arasında boyutların ve fact kolonlarının ortak kullanımı ilkesine uygun davranmamak.

RCSI ve SI arasında seçim (Bir önceki yazıdan devam)

2008-06-03T07:26:00.000-07:00

Ne zaman READ COMMITTED SNAPSHOT ISOLATION (RCSI), ne zaman SNAPSHOT ISOLATION (SI) kullanmalı?

Öncelikle eğer okuyucular ve yazıcılar arasında bloklama olayı çok fazla olmuyorsa, optimistic concurrency uygulamalarına girmemekte fayda var.

Eğer girmeniz gerekiyorsa, RCSI'yı tercih etmeniz şu açılardan daha iyi olacaktır:

* RCSI tempdb'de SI'ya göre daha az yer kaplar. (Satır büyüklüğü aynı olmakla birlikte, bir satırın tempdb'de kalma süresi tipik olarak daha kısa olacaktır.)

* RCSI dağıtık transactionlarla çalışır, SI çalışmaz.

* RCSI'da update çatışmaları oluşmaz.

* RCSI için uygulamanızda her hangi bir kod değişikliğine ihtiyaç yoktur. Veritabanı opsiyonunu değiştirdikten sonra eğer zaten READ COMMITTED modda (varsayılan mod) çalışıyorsanız, hiçbir değişiklik yapmadan çalışmalarınıza devam edip RCSI'nın nimetlerinden yararlanmaya başlayabilirsiniz.

Ama öte yandan şu durumlarda SI'yı kullanmayı düşünebilirsiniz:

* Uygulamalarınızın satırlarda eş zamanlı update girişimleri oluşturma ihtimalleri düşükse...

* Uzun süren ve belirli bir andaki verinin sabit olarak transaction boyunca erişilebilmesi gereken durumlarda...