Yeni adresim

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

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?

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ı

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:


  
     
  


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.

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

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

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.