19 Ekim 2014 Pazar

Etkili Rapor Tasarlama Teknikleri - 1 ('Dashboard'lar ve Mükerrer Tasarım Hataları)

Raporlamanın çok daha elit hali olan dashboardlar, organizasyonların bilgi ihtiyacını etkili bir biçimde karşılayabilen benzersiz ve çok güçlü çözümlerdir. Dashboardlar bir veya daha fazla hedefi gerçekleştirmek için gereken en önemli bilgileri görsel olarak ifade ederler. Örneğin bir aracın dashboardu yakıt, hız, motor devri ve sıcaklığı gibi en önemli bilgileri görüntüler.


Bu değerli çözümler ancak doğru şekilde kullanıldığında etkileyici olabilir. Ancak maalesef beklenen etkileyiciliği çok az tasarımda görebiliyoruz. Bu durum bazı organizasyonlar için o kadar içler acısı ki, veriler üzerinde çalışması gereken kullanıcılar artık mevcut dashboardları kullanmak yerine, kendi anlık ihtiyaçlarını karşılayabilen yöntemlerden faydalanma yoluna gitmekte ve hatta ciddi manada yatırım yapılan bu dashboardları tamamen terk edebilmektedir.

Neden?

Bugünkülere benzer formatta kullanılan grafiklerin geçmişi 200 yıl öncesine dayanmaktadır. Grafikler ilk olarak istatiksel bilgilerin gösterimi ile kullanılmaya başlanmış ve günümüzde ön plana çıkan iş zekâsı sayesinde hemen her alanda talep edilir hale gelmiştir. William Playfair, Florence Nightingale, John Snow, Charles Joseph Minard şimdilerde kullandığımız grafiklerin ilk hallerini finans, sağlık gibi alanlardaki istatistiki verileri sunmak için yayınlamışlardır. (http://en.wikipedia.org/wiki/Statistical_graphics)


Grafikler çok uzun zamandır var olmasına rağmen, bir araya getirilip etkileyici halde kullanılabilmesinin standartları daha yeni yeni oturtulabilmiştir. Bu konuda estetik, kullanılabilirlik ve algı yönetimi başlıklarında ciddi gelişmeler yaşanmıştır. Nihayet çeşitli felsefi teoriler ve insan kavrama becerisi ile ilgili çeşitli bilimsel araştırmaların sonuçlarından faydalanılarak belli başlı standartlar ortaya konulabilmiştir.

Verilerin etkili bir şekilde sunulması sadece dashboard tasarımı ile ilgili bir şey değildir. Dashboard tasarlamadaki amaç karar vermeyi kolaylaştırıcı çıktıların üretilebilmesidir. Bu da öncelikli olarak veri kaynaklarının hedefe uygun cevaplar üretebiliyor olmasını gerektirir. Yıllarca, depolanan verilerin nasıl analiz edilebileceği üzerinde kafa yorulmuş, hatta yorulmaya da devam edilmektedir. Ancak günümüzde her analizci tarafından kabul gören bir şey var ki; veriyi esnek bir şekilde analiz etmenin en güzel yolu veriambarı tasarımından geçer. Bu kapsamda rahatça şunu söyleyebiliriz; çoğunlukla etkili bir dashboardun arkasında doğru tasarlanmış bir veriambarı yatar.

İş zekası trendi stratejik, taktik ve operasyonel yönde bir trend izlediği için dashboard kullanıcı kitlesi de bir hayli genişledi. Artık yöneticilerden tüm beyaz yakalılara herkes aksiyonlarını dashboardlardan yardım alarak yapmayı tercih etmektedir. Ek olarak dashboardların eskisi gibi sadece kâğıt üzerinde değil, aynı zamanda web, tablet ve cep telefonlarında sunulması beklenmektedir. Bu kadar talep ve çekişmenin olduğu ortamda tasarım kalitesinin artması çok elzem bir konu haline gelmiştir.

Peki, kaliteyi arttırma konusunda neler yapabiliriz?

Dashboard tasarımcıları ile kullanıcılar arasında bir iletişim söz konusudur. Öncelikle bu iletişimin net, sade, gerektiği kadar ve anlaşılır olması çok önemlidir. Konuya edebiyat bakış açısı ile yaklaşırsak, özetle fesih ve beliğ bir anlatım benimsenmelidir.

Bir dil filozofu olan Herbert Paul Grice(1913-1988) etkileşim hakkında şu görüşleri öne sürmüştür;

Quantity: Sadece ihtiyaç olunan kadar bilgi ver. İhtiyaçtan fazlasını verme.
Quality: Yanlış olacağına inandığını söyleme. Yeterli kanıt olmayan şeyleri söyleme
Relation: Etkileşim şekli konu ile ilgili olsun.
Manner: Belirsiz ifadelerden, birden fazla anlama gelen tanımlardan, laf kalabalığından kaçın. Sistemli ol.

Bu görüşler dashboard tasarlarken dikkat edilmesi gereken noktaları da işaret etmektedir. Çünkü bu tasarımlar da sonuç itibari ile kullanıcılarla kurulan bir tür etkileşimdir.

Dashboardların üretimi sırasında aktarılmak istenen bilginin doğru, hızlı ve akılda kalıcı sadelikte olması gerektiği nedense çoğu zaman göz ardı edilir. Bunun yerine özellikle geliştiriciler çok renkli, vurgusu yüksek veya şekil itibari ilk bakışta göze hoş gelen ancak bilgi aktarımı konusunda kafa karıştıran tasarımlara yönelme hatasına düşerler. Aradığı bilgiye değil de tasarıma odağını kaptıran kullanıcılar ise ilk başlarda etkilense de bir süre sonra sıkılarak beklenen ilgiyi göstermeyecek hatta dashboardu kullanmayı tamamen terk ederek kendi çözümlerine yöneleceklerdir.

Tasarımlarda sayısız hatalar yapılabilir. Bunlardan birçoğu kullanıcıları kaçırmaz. Ancak sıkça yapılan aşağıdaki hatalar bir süre sonra dashboardlarınızın yalnızlığa terkedilmesine sebep olabilir.

Stephen Few’in “Information Dashboard Design” adlı kitabında bahsi geçen hatalardan bazıları şunlardır:

Bilgilerin tek bir ekranda sunulmaması:

Dashboardlarda kaydırma çubuğu (scroll) yardımıyla diğer alanların görüntülenmesine gerek kalmamalıdır. Gereken tüm bilgi ilk bakış görülecek şekilde tek ekranda sunulmalıdır. Bu hatayı bilgiyi bir menü yardımıyla farklı ekranlara bölerek de yapıyor olabilirsiniz.



Elbette sunulmak istenen bilgi tek ekrana sığmayacak kadar fazla olabilir. Bu durumda veriler üzerinde çalışıp ihtiyaç duyulan kadarını tam da işe yarayan formatta sunmak gerekir. Mümkün olduğunca detay bilgi ile özet bilgi birlikte verilmemelidir. Detay bilgiye sadece ihtiyaç duyulduğunda gidilebilmelidir. Tasarlanan dashboardun vermek istediği ana fikir mümkünse birden fazla olmamalıdır. Bu ana fikri focal point dediğimiz noktalarda bulundurarak algıyı güçlendirmek isteriz. Bir ekranda çok fazla focal point mevcut değildir. Sayı arttıkça etki azalır.

Verinin anlaşılmasını noksan kılan görsellerin kullanılması:

Mesela aşağıdaki görsellerde bir takım sayısal veriler ifade edilmiş. Soldaki gauge da elimizde sadece bir sayı var. Gaugeun bu değeri göstermesi iyi bir şey mi yoksa kötü bir şey mi? iyi ise ne kadar iyi? Bu sayının anlamı hakkında hiçbir fikrimiz yok. Sağdaki gaugeda ise şirket ortalamasının üzerinde bir değere sahip olduğumuzu ilk bakışta görebiliyoruz. Elimizde iyi bir sayı varmış. Harika!



Gereksiz detayların ve hassasiyetin gösterilmesi:

Örneğin sayısal verilerde gereğinden fazla basamak gösterilmemelidir. Benzer şekilde tarihsel verilerde eğer ihtiyaç yoksa milisaniye gibi bir hassasiyet belirtilmemelidir. Eğer F1 yarışlarındaki gibi hassas sonuçları raporlamanız gerekiyorsa o zaman da saat, gün, ay, yıl bilgisi gereksiz detay olacaktır.



Aktarılmak istenen bilgiye uygun görselin kullanılmaması:

Örneğin bir biri ile karşılaştırılması amaçlanan gruplar pasta grafiği ile gösterilmemelidir. Bunun yerine bar grafik tercih edilmelidir. Soldaki pasta grafiği ile sağdaki bar grafik aynı veriyi göstermesine rağmen gruplar arasındaki farkı en rahat sağdaki bar grafikte görebilmekteyiz. Bu tür yatay bar grafiklerde önemli olan daha büyük barın olduğu grupsa, büyükten küçüğe aksi halde, küçükten büyüğe sıralayabiliriz. Pasta grafiğinde ise değerlerin bir birine yakın olduğu durumda gruplar arasındaki farkı anlamamız bile mümkün olmayacaktır.



Kullanışsız dekorasyon:

Aşağıdaki örnekte en çok dikkat çeken alan mavi, gri baloncukların olduğu alandır. Ancak asıl verinin bulunduğu işe yarayan alan ise sol taraf değil, sağdaki grafiklerin bulunduğu kısımdır.



Renklerin yanlış ve yersiz kullanımı:

Bu örnekte ise soldaki grafikte ülkeler arasında hiçbir anlamı olmamasına rağmen farklı renkler kullanılmış. Gereksiz yere dikkat dağıtmaktadır. Hatta kullanıcıların, bu renklerin bir anlamı olacağı hissine kapılarak anlam kargaşası yaşaması ve fazladan anlam çıkarması olasıdır. Belki de kendilerini dashboardın diğer kısımlarındaki renklerle alaka kurmaya zorlarlar. Sağdaki grafik ise daha az kafa karıştırıcı ve istenen mesajı iletme konusunda daha başarılıdır.



Sayısal verilerin hatalı ifade edilmesi:

Aşağıdaki öreğimizde Revenue ve Costs değerleri sunulmakta. Ocak ayına baktığımızda Revenue, Costun yaklaşık 4 katı olarak görünüyor değil mi? Güzel. Tekrar grafiğe odaklanalım. Grafik 0’dan değil 500.000’den başlatılmış. Bu durumda 4 kat değil 2 kattan az bir farkın olduğu ortaya çıkıyor. Bu tarz gösterimler kullanıcıları şaşırtarak yanlış anlam çıkarmasına sebep olacaktır.


Üç boyutlu grafik kullanımı ve yanıltıcı yönlendirmeler:

Bu seferki örneğimizde birden fazla hatayı bir arada görmekteyiz. İlk grafiğimizde renklerin toplam değeri ve bir birine göre büyüklükleri kolayca anlaşılabilmektedir. İkinci grafikte ise aynı verilere anlamı olmayan bir bakış açısıyla bakıyoruz. Üç boyutlu çizimler bir yetenek göstergesi olabilir. Ancak bu raporda kalabalıktan başka bir işe yaramamış ve vermek istediğimiz mesajın netliğini bozmuş.

Üçüncü ve dördüncü grafiklerdeki perspektifin etkisi ise farklı bir konu. Bu grafiklerdeki perspektif yüzünden grupları karşılaştırmak oldukça güç hale gelmiş durumda. İki boyutlu bir pasta grafiğinden bile daha etkili karşılaştırma sonuçları elde edebilirdik.

Üçüncü ve dördüncü grafiklerdeki bir başka problem ise verideki renk gurupları ile pasta dilimleri üzerindeki renklerin bir biriyle uyumlu olmamasıdır. Burada dilimlerdeki renk kullanımı gereksiz ve daha kötüsü anlamsız olup, sonuç itibari ile kafa karıştırıcı ve dikkat dağıtıcıdır. Birinci ve dördüncü grafik aynı veriyi göstermesine rağmen, birinci grafiğin mesajı doğru iletmedeki etkisi çok daha üstündür.


Sıkça yapılan bu hataları terk etmek bile etkili dashboard tasarımı yapmak adına bir hayli yol kat ettirecektir. Ancak istenen güçlü etkiyi oluşturabilmek için çok daha fazlasına ihtiyacımız olacak.

Şimdilik burada duralım istiyorum.

Serinin devamında; görme ve kavrama becerilerinin nasıl çalıştığına, stratejik, analitik ve operasyonel dashboard rollerine, iyi bir tasarım için bilinmesi gereken “veri-mürekkep oranı” yaklaşımına ve raporların kullanılabilirliğinin arttırılmasını sağlayan ipuçlarına odaklanacağız.

Keyifli bir seri olacağa benziyor. Faydalı olması dileğiyle…

"Serinin çoğu yerinde fikirlerinden faydalandığım Stephen Few'e teşekkürlerimi sunuyorum."

23 Eylül 2014 Salı

SQL Server 2014 Yenilikleri - 6 (Buffer Pool Extension)

SQL Server verileri 8Kb'lık yapılar halinde tutmaktadır. Bu yapılara "page" adı verilir. İşlem görmek için talep edilen veriler öncelikle memory'e yüklenir. Mamory'deki pagelere "buffer", tüm veritabanlarındaki veri ve index pagelerinin toplandığı ortak havuza ise "buffer cache" veya "buffer pool" adı verilir.

Buffer Pool'un varlık amaçlarından birisi, I/O yükünü azaltıp veri üzerindeki işlem taleplerinin mümkün olduğunca hızlı gerçekleştirilebilmesini sağlamaktır.

Bir değişiklik talebi oluştuğunda önce veri diskten okunup Buffer Pool'a alınır ve değişiklikler uygulanır. Tam bu noktada veri diskte farklı, Buffer Pool'da farklı olabilmektedir. Buffer Pool'daki farklı verinin tutulduğu pagelere "dirty page" adı verilir. Bu dirty pageler bir takım şartların sağlanmasıyla Checkpoint adı verilen işlem sayesinde diske yazılarak kalıcı hale gelmiş olur. Aksi halde bir felaket durumunda Buffer Pooldaki pageler diske yazılmadığı için kaybedilirdi.

Verilerin Buffer Pool'da olması hızlı erişim için büyük avantaj sağlamakta. Daha büyük memory, daha geniş bir Buffer Pool ve bu da daha çok veri ile daha az gecikmeli çalışma anlamına gelir.

SQL Server'ın performansını arttırmak için donanımsal çözümlere sarılmak en son yapılacak işlerdendir. Ancak bazen konu memory artırımına kadar gelmiş olabilir. Eğer imkan varsa memory arttırımı gerçekleştirilir.

Peki ya daha geniş bir Buffer Pool ihtiyacı doğmasına rağmen, memory arttırımı yapılamıyorsa veya yapılması istenmiyorsa?

Bu konudaki talepleri değerlendiren Microsoft, SQL Server 2014 ile birlikte Buffer Pool'u diske genişletebilme özelliğini duyurmuştur. 

Buffer Pool'u genişletmeniz gerekmesine rağmen, anakart gibi donanımsal limitlere, çeşitli kurallara, yüksek fiyatlara takılarak memory arttırımını gerçekleştiremiyorsanız "Buffer Pool Extension (BPE)" özelliğine bir göz atmak isteyebilirsiniz. Belki de sadece kısa bir dönem için daha geniş bir Buffer Pool'a ihtiyacınız vardır. Bu durumda donanım değişikliğine gitmenize gerek kalmayacaktır.

SQL Server 2014 ile birlikte gelen "Buffer Pool Extension (BPE)" özelliği kolayca konfigure edilebilir. Bu sebeple esnek depolama alanı imkanı sunar. Disk ile memory fiyat bakımından karşılaştırıldığında da ceplerin daha sıcak kalacağı malumdur.

Memoryi diske genişletme fikri yüksek performans kazanılacağı konusunda pek ikna edici olmayabilir. Ancak bardağın dolu tarafından bakarsak eğer; çok daha büyük bir veri kümesini toplamda, memorye nazaran daha yavaş, diske nazaran daha hızlı şekilde kullanabiliriz. Buradan anlaşılıyor ki, BPE özelliğinin getirisini arttırmak için disk seçimi de bir hayli önem arz etmektedir. Klasik HDD yerine yaklaşık 100 kat daha hızlı SSD diskler tercih edilmelidir. 

BPE, özellikle okuma ağırlıklı OLTP iş yükleri için performans kazancı sağlamaktadır. Diskte ayırdığımız BPE alnında clean pageler yani commit edilmiş veriler saklandığı için herhangi bir anomali beklenmez. Özetle veri kaybı riski memoryde olduğundan fazla değildir. Eğer diskin başına bir şey gelirse BPE otomatik olarak disable olur. Dolayısıyla serverın çalışmasını engelleyecek bir durum beklenmez. Manual olarak yönetilebildiği gibi, instance başlatıldığında da yeniden aktif olacaktır(belirtilen yol varsa). Bu özelliğin güzel taraflarından birisi de herhangi bir uygulama taraflı değişiklik yapmaya gerek kalmadan ihtiyaç duyulduğunda aktif edilebilmesi ve kaldırılabilmesidir.

Nasıl yapıyoruz?

Oldukça basit şu script yardımıyla diskte "EkHavuz.BPE" isminde 10 GB boyutunda bir alan rezerve edebiliriz. BPE'yi hatasız aktif edebilmek için SIZE parametresi her defasında mevcut Buffer Pool'dan büyük olarak belirtilmelidir.

ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION ON
     (
         FILENAME = 'D:\EkHavuz.BPE',
         SIZE = 10 GB

     )



Böylece EkHavuz.BPE alanını memory Buffer Pool'umuza extend etmiş olduk. Şu DMV yardımıyla BPE konfigurasyonu hakkında bilgi alabilirsiniz:

SELECT
path,
file_id,
state,
state_description,
current_size_in_kb
FROM sys.dm_os_buffer_pool_extension_configuration;


EkHavuz.BPE'nin hangi veritabanından kaç tane page barındırdığını görmek isterseniz aşağıda gibi DMV'den faydalanabilirsiniz:

SELECT
COUNT(*)AS cached_pages_count
    ,CASE database_id
        WHEN 32767 THEN 'ResourceDb'
        ELSE db_name(database_id)
     END AS database_name
FROM sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id) ,database_id
ORDER BY cached_pages_count DESC;

BPE özelliğini pasif hale getirmek isterseniz şu scripti çalıştırmanız yeterli:

ALTER SERVER CONFIGURATION
SET BUFFER POOL EXTENSION OFF

SQL Server 2014 ile gelen "Buffer Pool Extension" özelliği memory arttırımına gerek kalmadan diski kullanarak Buffer Pool'u genişletmemizi sağladı. İşe yarar bir özellik.

Bu faydalı ve esnek depolama hizmeti Enterprise, Standart ve Business Intellingence sürümlerinde kullanılabilmektedir.

Bir gün sizin de işinize yarayabilir.

16 Eylül 2014 Salı

Hibrit Bulut - Hybrid Cloud (Azure ve SQL) Web Semineri - (Video)

09 Temmuz 2014 Çarşamba günü düzenlediğimiz web semineridir. Bu web seminerinde Azure ile SQL Server'ın bir arada neler yapabildiğini şu başlıklar altında inceledik:

  • SQL Azure Database
  • Backup to Cloud
  • SQL Server Data Files in Windows Azure
  • Deploy DB to Windows Azure VM
  • Cloud HA-DR

Microsoft Azure ile ilgilenen, hakkında araştırma yapan, kaydı merakla bekleyen herkese keyifli seyirler dilerim.




Azure ile ilgili şu yazılara da bir göz atmak isteyebilirsiniz:

SQL Server 2014 Yenilikleri - 1 (Hybrid Cloud)

SQL Server 2005, 2008, 2008 R2 ve 2012 Yedeklerinizi SQL Server 2014 Yedekleme Özellikleri ile Azure'da Saklayabilirsiniz!

SQL Server 2014 Yenilikleri - 5 (Backup Encyrption)

20 Ağustos 2014 Çarşamba

SQL Server 2014 Yenilikleri - 5 (Backup Encyrption)

Veritabanları üzerinde çalışan hemen hemen herkes bir şekilde backup/restore işlemleriyle muhatap olmuştur. Yedekler çoğu zaman farklı lokasyonlara taşınır. Zaten işi sağlama almak için yedeklerin kopyalarının farklı lokasyonlarda tutulması iyi bir şeydir.

Ancak farklı lokasyonlara dağıtılan yedekler veri güvenliğini riske atar. Eğer bilgilerin gizli kalması önemli ise, belli alanların okunamamasını arzu ederiz. Hatta veritabanının farklı bir serverda açılamamasını isteriz. Bu tür istekler Microsoft Azure Storageler gibi bulut teknolojileri kullanılmaya başlandıkça daha da artmaktadır. Microsoft Azure tarafında yeterli güvenlik alınmasına rağmen içi rahat etmeyenler için şifreleme yoğun şekilde başvurulabilecek bir konu haline gelecektir.

Veri güvenliğini, şifreleme yaparak sağlamamız gereken durumlar olduğunda; Önemli verilerin kolayca okunamamasını istiyorsak Column-Level Encrytpion yöntemini, veritabanının farklı bir serverda komple açılamamasını istiyorsak TDE (Transparent Data Encryption) yöntemini tercih ederiz.

TDE yöntemi ile şifreleme yaptığımızda pageler diskte encyrpt edilmiş, memoryde decrypt edilmiş olarak tutulur. Bu işlem sürekli tekrarlandığı için CPU’ya %5-10 civarı yük biner. Zamanla CPU konusunda zaten problemi olan serverlar için tercih edilemeyecek bir yöntem haline gelir. Eğer önemli olan sadece yedeklerin şifreli olarak saklanabilmesi ise o zaman SQL Server 2014 ile birlikte gelen backup encyrption özelliği tam ihtiyacımız olan şey demektir.

Hem veritabanın başka serverda kullanılamamasını hem de yedeklerin şifrelenmesini istiyorsak, bu durumda TDE ve Backup Encyrption özelliklerini birlikte kullanabiliriz. Tabi her şeyden önce şifrelemede kullanılan sertifika ve keylerin yedeklerini sağlıklı yerlerde saklamamız gerekir. Aksi halde şifreleme yaptığımız veritabanlarını tekrar kullanamayız.

Şifreleme konusu ile ilgili 5 bölümlük bir makale serisi hazırlamıştım. İlgililer son bölüm olan TDE yöntemine şu linkten bir göz atabilirler.


Biz bu yazımızda SQL Server 2014 ile birlikte gelen Backup Encyrption özelliğine yoğunlaşalım ve yedeklerimizi nasıl şifreleyeceğimizi inceleyelim.

Yedeklerimizi bir certificate veya asimetrik key yardımıyla şifrelemekteyiz. Yedek alırken WITH seçeneklerinden ENCRYPTION ifadesi ile şifreleme algoritmasını ve certificate veya asymmetric keyi belirtiyoruz. Tabi bu certificate veya asymmetric keyinde korunmaya ihtiyacı var. Bunları da master veritabanının Database Master Key’i (DMK)  ile şifreliyoruz. Database Master Key kolayca oluşturulabilen private bir keydir.

Database Master Key (DMK), certificate ve asymmetric key hakkında daha fazla bilgi almak isterseniz şifreleme serimizdeki ilk yazıdan başlayabilirsiniz.

İlk adım olan master veritabanın Database Master Keyini oluşturalım:

--master veritabanının "Database Master Key"i :
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Password1';

Burdaki Password, DMK’yı korumak için kullanılır ve Windows Password Policy mekanizmasına uygun olmalıdır.

DMK oluşturduktan hemen sonra bir certificate veya asymmetrik key oluşturuyoruz. Biz burada certificate ile ilerliyor olacağız.

--Yedeklemede kullanılacak sertifika:
USE Master;
GO
CREATE CERTIFICATE YedekSifrelemeCert
   WITH SUBJECT = 'yedekleme sertifikası;

Sertifikaların da korunmaya(şifrelenmeye) ihtiyacı vardır. Çeşitli şekillerde şifrelenebilirler. Eğer bu konuda bir şey belirtilmezse otomatik olarak DMK yardımıyla şifrelenmiş olurlar. Bizim oluşturduğumuz certificate master veritabanın DMK’sı ile korunmaktadır.

Şimdi sıra geldi backup alırken bu sertifikayı göstermeye ve şifreleme algoritmasını seçmeye.

BACKUP DATABASE veritabani
TO  DISK = N'C:\yedeklerim\veritabani_enc.bak'

WITH
      ENCRYPTION
         (
              ALGORITHM = AES_128, --AES_192, AES_256, Triple DES kullanılabilir.
              SERVER CERTIFICATE = [YedekSifrelemeCert]
         )

Bu örneğimizde AES_128 algoritmasını kullandık. Siz ihtiyaca göre sisteminiz için diğer algoritmaları da (AES_192, AES_256, Triple DES) tercih edebilirsiniz.

Yedek almak için scripti çalıştırdıktan hemen sonra bir uyarı ile karşılaşacaksınız. Bu uyarı yedek almaya engel değil ancak çok önemli bir hatırlatmayı içeriyor. Şifrelemede kullandığımız sertifikanın bir yedeği alınmadı. Sertifika kullanılamaz hale gelirse yedek de açılamaz hale gelir. Yani certificate ve onu koruyan private keyin (bu örnekteki DMK) yedeğinin felaket durumunda veya başka bir servera taşınma durumunda kullanılmak üzere alınması gerekir. Bu konuya birazdan döneceğiz.

Artık yedeklerimizi şifrelenmiş olarak saklayabiliyoruz. Oluşan yedek dosyası üzerine başka yedekler alamıyoruz. Yeni bir media set oluşturmamız ve içeriği ezmemiz gerekir. Bu yedek dosyasında bulunan bir önceki yedeğin silineceği anlamına gelir.

Peki, yedekten nasıl döneceğiz?

Eğer yedek alırken kullandığınız DMK ve certificatenın bulunduğu serverda iseniz yedekten dönmek için normalden farklı bir şey yapmanıza gerek yok. En basit haliyle aşağıdaki scripti kullanarak veritabanını yedekten döndürebilirsiniz.

USE [master]
RESTORE DATABASE [veritabani]
FROM  DISK = N'C:\yedeklerim\veritabani_enc.bak'

Eğer veritabanının yedeğini farklı bir serverda açmak istiyorsanız veya şifrelemede kullandığınız certificate silinmiş ise yukarıdaki scriptten daha fazlasını yapmanız gerekecek.

Sertifikaları nasıl koruyup yedekleyebilirim?

Şifrelemede kullandığımız sertifikanın yedeğini güvenli bir ortama almamız gerekir. Yedek alırken WITH PRIVATE KEY ifadesi ile sertifikayı koruyan private key de belirttiğimiz password yardımıyla şifrelenmelidir. Bu ifade kullanılmadan sertifika yedeği alınabilir ancak bu esnada sertifikanın private keyi diske alınmadığından sertifikadaki PrivateKeyEncryptionType özelliği NoKey olarak işaretlenir. Bu da sertifikayı restore işleminde kullanılamayacak hale getirir. Bu konuda çeşitli derinliklerde çalışmalar yapılabilmektedir. Biz amacımızın dışına çıkmadan aşağıdaki şekilde yedekleme yapmamızın doğru olacağını kabul etmiş olalım.

Sertifikaların yedeğini şu script yardımıyla alıyoruz:

--sertifikanın yedeğini alalım
USE master
GO
BACKUP CERTIFICATE YedekSifrelemeCert
TO FILE ='C:\yedeklerim\YedekSifrelemeCert.cer'

WITH PRIVATE KEY
     (
          FILE ='C:\yedeklerim\YedekSifrelemeCert.pvk',
          ENCRYPTION BY PASSWORD=N'pass@word1'
     )

Sertifikayı tekrar(yedekten) oluşturmak için şu komutu kullanmamız gerekecek:

--sertifikayı yedekten dönelim
USE master
GO
CREATE CERTIFICATE YedekSifrelemeCert
FROM FILE = 'C:\yedeklerim\YedekSifrelemeCert.cer'


WITH PRIVATE KEY
     (
          FILE ='C:\yedeklerim\YedekSifrelemeCert.pvk',
          DECRYPTION BY PASSWORD='pass@word1'
     )

DMK silinmiş ise öncesinde mutlaka DMK oluşturulmalıdır. Çünkü bu şekilde yedek aldığımızda sertifikanın, MasterKey olarak işaretlenen PrivateKeyEncryptionType özelliği DMK’yı isteyecektir.

Eğer ihtiyaç duyarsanız, DMK’nın yedeklenmesi ile ilgili bilgilere şu linklerden ulaşabilirsiniz.


Eğer Certificate ve DMK’yı kaldırmak isterseniz şu drop komutları işinizi görecektir.

USE master;
GO
--Certificate yı kaldırmak için
DROP CERTIFICATE YedekSifrelemeCert

-- DMK yı kaldırmak için
DROP MASTER KEY

Master veritabanı altında konumlanan sertifikamızın PrivateKeyEncryptionType özelliğini şuradan görüntüleyebilirsiniz:



Sertifikayı kullanılabilir hale getirdiğinizde klasik restore scriptini kullanarak yedeklerinizi istediğiniz serverda açabilirsiniz.

Tabi ki backup encrption özelliği sadece SQL Server 2014’ün desteklediği bir özelliktir. Hatta bu versiyondaki Web ve Express editionlarda backup encription desteklenmemektedir.

Eğer yedeklerin şifrelenmesi ilginizi çektiyse ve SQL Server 2014 öncesi versiyonlarda kullanmak isterseniz Microsoft Download Centerdan indireceğiniz Microsoft SQL Server Backup to Windows Azure Tool’u kullanabilirsiniz. Bu araç yardımıyla SQL Server 2014 yedeklerindeki tüm özellikler SQL Server 2005, 2008, 2008 R2 ve 2012 yedeklerine de uygulanabilir. Bu konuda gereken tüm bilgiye şu yazımdan erişebilirsiniz:


Yedeklerin şifrelenmesi ilerleyen günlerde bir hayli önem kazanacak bir konu.

Faydalı olması dileğiyle…


10 Ağustos 2014 Pazar

Kısaca Hakkımda (Abdullah Kise) - 2014

Technet için yaptığım bir tanıtımdır burada da olsun istedim.

Çorum’da doğdum ve 1 yaşından beridir İstanbul’dayım. İlkokul yıllarında bir akrabamda gördüğüm ve şuanda nasıl bir şey olduğunu bile hatırlayamadığım bir bilgisayarla etkileşim kurduğumdan beri elektronik cihazlara ilgim mevcut. Şimdilerde her çeşidine sahip olduğum bilgisayarlara aslında çok geç kavuştum. Ancak evimde istediğim gibi kurcalayabileceğim bir bilgisayarım var olmadan çok önce nasıl kullanıldıklarını kitaplar ve ilk internet kafelerden öğrenmiştim. O zamanlar küçük virüsler yazmak ve şifre kırmak ilgimi çekse de şimdilerde kurumlara ve insanlara katkı sağlamak çok daha fazla ilgimi çekiyor.

Abdullah Kise

Bir matematikçi olarak algoritmaları daha rahat anlayabiliyorum. Dolayısıyla zaten küçüklük yaştan beri işimin parçası olsun istediğim bilgisayarları programlamak bana daha fazla keyif verdiği için kariyer seçimimi de bu yönde yaptım. Freelance olarak C, C++, VB, ActionScript, C# dilleri ile program geliştirdim ve sattım. 2008 yılında mezun olduktan kısa bir süre sonra bir sürü testin ardından meşhur Netron Akademi’de yazılım eğitmenliğine başladım. 2010 yılı Ağustos ayında askere gidene kadar eğitim verdim ve freelance olarak projeler ürettim. Kaç saat eğitim verdiğimi hatırlamıyorum ancak oranın en yüksek seviyeli eğitimi olan ve süresi 1 yılı aşan “Developer Factoring” derslerine tümüyle giren tek eğitmendim. Bu eğitimlerde core yazılımdan, veritabanına, web sitelerinden, iş zekâsına tüm başlıklar yer almaktaydı.

Askerliğimi yedek subay olarak İstanbul’da yaptım ve bitirir bitirmez Bahçeşehir Üniversitesi’nde eğitmenliğe başladım. Üniversite yıllarından beridir irili ufaklı projeler yapmaktaydım ancak eğitmenlik tarafı daha fazla ağır basıyordu.

Abdullah Kise


Askerden sonraki birkaç ayın ardından BilgeAdam Kurumsal’da eğitmen ve danışman olarak işe başladım. Bilgeadam’da 4. Yılıma giriş yapıyorum. Kurduğumuz “Veri Yönetimi” ekibi ile çok yoğun bir şekilde kurumsal firmalara veri odaklı danışmanlık hizmetleri veriyoruz ve bu tecrübelerimizi paralel olarak eğitim, seminer, makale ve webcastler vasıtası ile bizi takip edenler ile paylaşıyoruz. Proje geliştirmekden müşteri yönetimine, eğitimden satışa, ekip yönetiminden piyasaya aktif katkı sağlayan yazarlığa kadar birçok alanda etkin ve yetkin olan bu ekibe liderlik etmekten çok memnunum.

Sorumluluklarım; ekip koordinasyonu, yetenek alanlarının genişletilmesi, danışmanlık hizmetlerinin geliştirilmesi, eğitim çeşitliliğinin arttırılması ve hizmetlerin projelendirilmesi gibi yönetimsel ağırlıklı olmaktadır. Bununla beraber teknik taraftan kopmayıp aşağıdaki başlıklarda kurumsal firmalara danışmanlık ve eğitimler de vermekteyim.

OLTP/OLAP sistemlerinin;
·         Tasarımı
·         Yönetimi
·         Performansı
·         Sağlık testleri
·         Veri kalitesinin arttırılması
·         Veri madenciliği
·         Etkili raporlama yöntemleri
·         Güncel iş zekâsı teknolojileri

Abdullah Kise

Daha çok Microsoft teknolojilerinde etkin oluyorum. Türkiye'de ilk olarak SQL Server 2012 ve SQL Server 2014 ürünleri hakkında yurt içi/yurt dışında düzenlenen Train-the-Trainer eğitimlerinden edindiğim bilgileri Microsoft Hot-Lab’ler ve diğer paylaşımlar vasıtasıyla ilgili katılımcı kitlesine aktardım.

Kurumsal bir firma için yürüttüğüm iş zekâsı projesi Microsoft'da başarı hikâyesi olarak anlatıldı. Microsoft tarafından düzenlenen tanıtım ve seminerlerde konuşmacı olarak görev aldım.

Abdullah Kise

Son dönemlerde Oracle, Big Data, NoSQL ve Cloud sistemleri üzerinde çalışmalar yapmaktayım. Sistem mimarilerinin oluşturulması konusunda da aktif rol alıyorum.

Güncel teknolojik gelişmeleri ve kurumsal tecrübelerimizi eğitimler, seminerler ve teknik yazılar vasıtası ile paylaşmak bu aralar keyif aldığım bir aktivite haline geldi. “Data Platform” ve “Business Intelligence” alanında MCSE unvanına sahibim ve MCT’liğimi kesintisiz devam ettirmekteyim.

Sosyal hayatta yüzmek, balık tutmak, farklı doğal mekânları gezmek, karakalem ve şiir kendimi dinlendirdiğim aktiviteler arasında yer alıyor. Küçük yaşlardan beri yaptığım karatenin yerini de son zamanlarda kickbox ve zorlu şartlarla mücadele etmeyi gerektiren sporlar aldı diyebilirim.

Abdullah Kise

Danışmanlık Hizmeti Verdiğim Bazı Kurumlar

Sabancı Holding, Pfizer, Kordsa, Ibtech, Innova, Boydak Holding
Turkcell, Avea, Türk Telekom, azerfon, Azercell
İş Bankası, Finans Bank, Teb, Garanti Teknoloji, ABank, INTERTECH, Akbank, RBS,
Citibank, Eureko Sigorta, Anadolu Sigorta Merkezi, ACIBADEM,
Koç Sistem, Mercedes Benz, Assan Hanil,
e-bebek.com, Kariyer.net,
Bahçeşehir Üniversitesi, Kültür Üniversitesi,
Tema Mağazacılık, Boyner, Metro Market, Tesco Kipa, Promat Basım, Boyteks
Linda Gaz, Fritolay, Uğur Derin Dondurucu, Hes,Boyçelik
Medyanet, Cardif, İSKİ, UEDAŞ, Sağlık Bakanlığı, Diyanet İşleri, Sağlık Bakanlığı, NATO

Temel Olarak Şu Yetkinliklere Sahibim

Microsoft Azure (SQL Azure, Big Data-HDInsight, Hybrid Cloud)
Power BI (PowerPivot, PowerQuery, PowerView, PowerMap), Data Mining
Business Intelligence, DataWarehouse, MDX, DAX
SharePoint (SSRS, Powerpivot, Powerview, PerformancePoint)
Data Quality Services, Master Data Services
Microsoft SQL Server 2000-2005-2008-2012-2014 SQL - T-SQL
Microsoft SQL Server 2000-2005-2008-2012-2014 Administration
Microsoft SQL Server 2000-2005-2008-2012-2014 Analysis Services
Microsoft SQL Server 2000-2005-2008-2012-2014 Integration Services
Microsoft SQL Server 2000-2005-2008-2012-2014 Reporting Services
Oracle SQL – PL/SQL – Administration
Agile Software Development with Scrum
Proje Yönetimi Temelleri
.NET Framework
C#, Visual Basic .NET
Sharepoint 2010 Programming
Asp.NET, Asp.NET MVC, XML, XML Web Services, WCF
WinForm, Wpf, Silverlight
N-Tier Programming Architecture
OOP, SEO

Blog

Mayıs 2013’ten beri teknik yazılarla doldurmaya karar verdiğim blogum:

çeşitli platformlardan da yazılarımın kopyasına ulaşabilirsiniz.

TechNet Wiki

Yazılarım:

Profilim:

Sertifikalarım

Microsoft Certified Solutions Expert(Business Intelligence)
Microsoft Certified Solutions Expert(Data Platform)
Microsoft Certified Solutions Associate
Microsoft Certified Trainer
Microsoft Certified IT Professional
Microsoft Certified Technology Specialist

İletişim

Linkedin:

e-mail


Mini CV’im: