Bir Tool daha... DBAToolkit

Selam!

Dosya arşivimde dolanırken buldum bu uygulamamı. Bu uygulamayı birkaç sene önce, çalıştığım bir şirkette eksikliğini gördüğüm bir uygulamada gördüğüm lüzum üzerine yazmaya başlamıştım. Sorunu maddelerle anlatayım:
- Yazılımcılara veya iş analistlerine, geliştirme, kalite kontrol ve üretim veritabanlarında kalıcı veya geçici yetkiler veriliyordu; fakat bu yetkilendirme işlemleri tamamen elle yapılıyor ve bu yetkilendirmelerin kayıtları bazı metin dosyalarında elle girilerek tutuluyordu. Verilen yetkilerin kayıtları metin dosyalarında tutulduğu için, verilen geçici yetkilerin geri alınmaları gerektiği zaman bu işlem atlanabiliyordu, tabii ki böyle bir işin takibi de çok zor oluyor.
- Yüzlerce veritabanı sunucusunun olduğu, işe giriş ve çıkış sirkülasyonunun da yoğun olduğu böyle bir ortamda tek tek SQL Server Instance'larına bağlanıp yetki vermek de çok zaman alıyordu.
- Hangi yetkinin kim tarafından, tam olarak ne zaman, kimin onayıyla, neye istinaden ve hangi açıklamayla verildiği bilinemiyordu.

Yukarıda sıraladığım temel sorunları çözmek için bir uygulama yazmaya karar verdim. Boş vakitlerimde uygulamayı adım adım geliştirdim. Uygulamayı kendim kullandığım için, işimi kolaylaştıracak özellikleri bulduğum boş bir vakitte hemen ekliyordum. Aynı şekilde bulduğum hataları da düzeltiyordum.

Zamanla uygulamayı tüm ekip arkadaşlarım da kullanmaya başladı. Tabii zamanla daha farklı ihtiyaçlarımız da oldukça, uygulamaya yeni bölümler ekleyerek bu ihtiyaçlarımızı da gidermeye başladık. Bu kadar konuşmanın ardından, en azından uygulamadan bir ekran görüntüsünü aşağıda paylaşmak istiyorum.

DBAToolkit

Bu gördüğünüz ekran, yetki verme işlemlerinin yapıldığı ekran. Uygulamanın bu hali, tamamen o şirkete özel halidir. Henüz paket programa çevirmedim, şimdilik öyle bir niyetim de yok. Bununla birlikte, biraz elden geçirmeyle yeni bir şirkete rahatlıkla uyarlanabilir ve hatta paket programa da çevrilebilir.

Yukarıdaki yetkilendirme ekranını aşağıda madde madde anlatayım. Şimdiden söyleyeyim vereceğim bilgiler özettir, uygulamanın daha birçok ayrıntısı bulunmaktadır.
- Yetkiler "Geçici" veya "Kalıcı" olarak verilir. Yetkinin alınacağı tarih "Alınma tarihi" alanında belirtilir.
- "Sunucu adı" listesinden sunucu seçildiğinde "Veritabanı adı" listesi otomatik olarak dolar, keza veritabanı seçildiğinde de "Roller" listesi seçili veritabanındaki Database Role'leriyle dolar. Bu işlem ve hedef sunucu ile ilgili yapılan tüm işlemler o anda uygulamayı kullanan kişinin Windows oturumu açtığı kullanıcı ile yapılır, bu nedenle yetkisiz bir kullanıcı bu uygulamayı zaten kullanamaz.
- "Açıklama" bölümüne, yetkinin kimin onayıyla verildiği bilgisi yazılabilir.
- "Çağrı numarası" alanına, yetkinin bir çağrı ile talep edildiği varsayılarak hangi çağrı kaydıyla talep edildiyse o çağrının numarası girilir. Böylelikle yetkilendirme işlemi, ilgili çağrı ile ilişkilendirilmiş olur ve örneğin teftiş yetkinin neye istinaden verildiğini sorduğunda kanıt hemen bulunabilir.
- Bazı senaryolarda, bazı sunuculara doğrudan uygulama ile erişemeyebilirsiniz ve yetkilendirmeyi o sunucuya RDP yapıp vermeniz veya başka bir şekilde vermeniz gerekebilir. Böyle durumlarda ise yetkilendirme işleminin yine de kayıt altına alınabilmesi için "Kayıt şekli" açılır kutusunda "Sadece kaydet" seçeneğini seçebilirsiniz. Eğer hem işlemi kaydetmek isterseniz hem de yetkiyi uygulamaya verdirtmek isterseniz o zaman "Kaydet ve yetkilendir" seçeneğini seçebilirsiniz.
- "Ara" düğmesini kullanarak önceden vermiş olduğunuz bir yetkiyi ID'sine, Çağrı numarasına, Kullanıcı adına göre veya iki tarih arasında arayabilirsiniz.
- "Yetkileri eşleştir" seçeneği ile, bir veritabanında (veya tüm veritabanlarında) DBAToolkit ile verilen yetkileri ve o veritabanlarında verilmiş yetkileri karşılaştırabilirsiniz. Böylece DBAToolkit ile verilmemiş, yani kayıt dışı yetkileri tespit edebilirsiniz.
- "Yetkilendirme listesi"ndeki kayıtların üstünde farenin sağ tuşuna tıklarsanız çeşitli seçenekler bulursunuz. Örneğin bazen kullanıcılar "işimi bitiremedim, yetki iznimin uzatılması gerekiyor" gibi taleplerle gelebiliyor, yöneticisi de onayladığında yetki alınma süresi gelmiş bir kaydın yetki alınma süresini 1-2 fare tıklamasıyla erteleyebilirsiniz.
- Aşağıdaki "İşlem tarihçesi" listesinde, yapılan işleme ait ayrıntılı bilgileri bulabilirsiniz. Örneğin yetki verilen kişinin önceden hedef SQL Server Instance'ında bir Login'i yoksa, bunun oluşturulduğu bilgisi, veritabanına önceden erişimi yoksa, veritabanı erişim yetkisinin verildiği, ilgili role üye yapılma onayı ve eğer işlem hata aldıysa alınan hata mesajı bu şekilde kaydedilir.
- "Listeleme kriterleri", "Yetkilendirme listesi"ndeki kayıtların ne şekilde listeleneceğini belirler. Örneğin sadece bu ayki kayıtlar veya son 100 kayıt gibi. Ayrıca sadece hata alan yetkilendirme işlemleri ve/veya geçici yetkilendirmelere ait işlemler de listelenebilir.

Yukarıdaki ekran görüntüsündeki her sekmeden ayrı ayrı bahsetmeyeceğim, ama bazılarından bahsedeyim,
- "Log Shipping" sekmesinde Log Shipping'lerinizin ne durumda olduğunu görebilirsiniz. Ne kadar geride kalmışlar, Restore'lar devam ediyor mu vs.
- "Disk talepleri" sekmesinde, SAN ekibinden yaptığınız disk taleplerini takip edebilirsiniz. Özellikle yoğun ortamlarda SAN ekiplerinden bol bol disk talepleri yaparız, yeni bir disk veya varolan diskin büyütülmesi gibi. Bu talepler için çağrılar açarız, fakat açtığımız çağrıların takibini yapmak, tabii ki kullandığımız Service Desk uygulamasına da bağlı olarak oldukça zor olabilir. Bu sekmeden yaptığımız talepleri takip etmemiz kolaylaşıyor.
- "Sunucu karşılaştır" sekmesini daha ziyade Side-by-side Upgrade işlemlerinde yeni kurduğumuz sunucu ile eski sunucunun Server Configuration ayarlarını karşılaştırmak için kullanıyordum. Örneğin X1 isimli sunucu varolan SQL Server 2008 sunucumuz, o anda adı X2 olan yeni donanımlı sunucumuz da SQL Server 2012 sunucumuz. X1 Instance'ındaki ayarlarımızı X2'ye aktarmak istediğimizde, bu sekme ile doğrudan iki Instance'ı karşılaştırabiliriz. Farklılıklar farklı renklerle işaretleniyor ve doğrudan ve tek tek X2 Instance'ına uygulanabiliyor.
- "Müşteriler" sekmesi, özellikle birden fazla müşteriniz olduğunda çok kullanışlı olabiliyor. Müşterilere ait sunucu ve kullanıcı isimleri, bunların hangi ortamlara (geliştirme, üretim vs) ait oldukları gibi bilgiler bu sekmeden yönetiliyor.

Bu yazıyı kısa kesmek için birçok şeyi sadece özet olarak paylaştım, her sekmenin veya özelliğin ekran görüntüsünü de paylaşamadım. Uygulama birçok açıdan daha da güzelleştirilebilir ve uygun bir ortam olduğunda bunu da yapacağım. Önceden belirttiğim gibi, uygulama bu haliyle ortam-spesifik olduğu için herhangi bir yerde paylaşamıyorum.

Nasıl? Bir DBA olarak bu uygulama hakkında ne düşünüyorsunuz? Kendi ortamlarınızda böyle bir uygulamaya ne kadar ihtiyacınız var?

Sevgiler,
Ekrem Önsoy

The EXECUTE permission was denied on the object 'sp_sqlagent_update_agent_xps', database 'msdb', schema 'dbo'

HATA:
[298] SQLServer Error: 229, The EXECUTE permission was denied on the object 'sp_sqlagent_update_agent_xps', database 'msdb', schema 'dbo'. [SQLSTATE 42000] (DisableAgentXPs)

AÇIKLAMA:
SQL Server Agent servisini çalıştırmayı denediğinizde böyle bir hata ile karşılaşabilirsiniz. Sorun, SQL Server Agent servisini çalıştırması için kullandığınız Windows (Local veya Domain) hesabının ilgili SQL Server Instance'ında "sysadmin" Fixed Server Role üyesi olmadığından kaynaklanıyor.

ÇÖZÜM:
SQL Server Configuration Manager veya Services.msc'yi kullanarak SQL Server Agent servisi için hangi hesabın kullanıldığını bulabilirsiniz. Daha sonra bu hesap için, bu SQL Server Agent'ın bağlı bulunduğu SQL Server Instance'ınızda bir Login olduğuna ve bu Login'in de "sysadmin" Fixed Server Role'ünün üyesi olduğuna emin olun. Yetkiyi verdikten sonra SQL Server Agent servisini tekrar çalıştırmayı deneyebilirsiniz.

SQL Server 2016'da bir başka tempdb değişikliği

Merhabalar,

Geçenlerde SQL Server 2016 ile birlikte, kurulum ekranından tempdb dosya sayısının arttırılabilir olduğundan bahsetmiştim.

Bildiğiniz gibi tempdb'de, özellikle yoğun ortamlarda yaşanan kronik SGAM (Shared Global Allocation Map) ve PFS (Page Free Space) çekişme sorunu vardır. Yeni bir nesne yaratıldığında ilk 8 sayfa için farklı Extent'ler kullanılıyor. Daha sonraki sayfalar için ise tek bir Extent kullanılıyor. SGAM sayfası da tüm bu Extent'leri takip etmek için kullanılıyor ve çok sık ve fazla yeni nesne oluşturulduğunda bu da sıkışıklığa neden oluyor. Bu sorunu TF 1118 kullanarak atlatıyoruz. Yine çok sık ve fazla nesnenin oluşturulduğu ortamlarda PFS sorunları yaşanıyor, bunu aşmak için de CPU sayımıza göre tempdb'ye yeni veri dosyaları ekliyoruz.

SQL Server 2016'da tempdb ile ilgili yapılan tek değişiklik yukarıda bahsettiğim kurulum ekranından tempdb için yeni veri dosyası eklemek değilmiş. SQL Server 2016'da tempdb'de yapılan tüm sayfa ayırma işlemleri aynı Extent'lerde gerçekleştirilecekmiş. Hal böyle olunca, SQL Server 2016'da artık TF 1118 kullanmamıza gerek kalmayacak. Gereği kadar veri dosyalarını da kurulumda eklersek, tempdb'de yaşanan kronik sorunların büyük bir kısmı işin en başında atlatılmış olacak.

Sevgiler,
Ekrem Önsoy

2 iş görüşme tecrübesi

Merhaba arkadaşlar,

Son 10 gündür iş görüşmeleri açısından biraz hareketli geçiyor, yabancı firmalarla yaptığım bu son 2 iş görüşme tecrübelemi sizlerle de paylaşmak istedim. Bugün, yarın sizin de böyle planlarınız olursa, az çok neyle karşılaşacağınız hakkında bir fikriniz veya tecrübenize tecrübe katar.

Öncelikle yaklaşık 10 gün önce Amsterdam'dan, Boeing'in iştiraki olan ve havacılık alanında yazılım üreten bir firma ile Skype üzerinden bir iş görüşmesi yaptık. Pozisyon, Senior SQL Server DBA pozisyonuydu. 160 kişilik bir şirket, 2 DBA'den biri olacakmışım. Standart, OLTP üretim veritabanı yöneticisinden beklenilenleri beklediklerini söylediler, kolayca bulunabileceği için madde madde yazmıyorum bunları.

Bunların karşılığında da bana, eşim ve benim için oturum ve çalışma iznini ayarlayacaklarını, benim için sağlık sigortası (150Eur) ödeyeceklerini (bunu bildiğim kadarıyla Hollanda'da insanlar genelde kendileri ödüyor), emeklilik fonuma para yatıracaklarını (bu da orada senelerce yaşamış olan teyzemin dediğine göre genelde yabancılara yapılmıyormuş), toplu taşıma masraflarımı ödeyeceklerini, senelik bir maaş kadar tatil parası vereceklerini, biraz da ikramiye vereceklerini söylediler. Her fırsatta Hollanda'ya gittiğim için oradaki masrafları biliyorum, net ücret teklifleri maalesef ihtiyaçların çok gerisinde kaldığı için o teklifi kabul edemedim. Hollanda'ya iş için göçecek arkadaşlarıma tavsiyem, özellikle eşinizle gidecekseniz küçük de olsa mobilyalı bir ev tutmanız gerekecek. Bunun için de (tabii ki yerine göre değişir) ortalama 1250-1700 Euro gibi bir ev kirası ödeyeceğinizi unutmayın. Eğer tek gidecekseniz oda da kiralayabilirsiniz, Hollanda'da bu çok yaygındır ve bunun için de 300-500 Eur arasına anlaşabilirsiniz. Yani tabiri caizse "aa ne güzel maaş xxx Eur'muş lan" deyip balıklama atlamayın, hesabınızı kitabınızı iyi yapın.

Bugün de Hindistan menşeli bir firma ile Senior SQL Server Escalation Engineer pozisyonu için telefonda teknik mülakat yaptık. Hemen söyleyeyim, bu pozisyon için Hindistan'a taşınmam beklenmiyor. Microsoft CSS (Customer Service & Support)'u biliyorsanız, onun gibi. Sene 2010 idi sanırım, Microsoft CSS için de iş görüşmesi yapmıştık, fakat o zaman da çalıştığım kurum tabiri caizse "taş koyduğu" için olmamıştı o iş. Açıkçası Hollanda ile yaptığım iş görüşmesinden önce de Skype üstünden yurtdışındaki bazı firmalarla iş görüşmeleri yapmıştım; ama ilk defa telefonla bir teknik mülakat yaptım. İlginç bir tecrübe oldu. Skype ile iş görüşmesi yaptığınızda yine birisinin yüzünü, gözünü görüyorsunuz; fakat telefonda sadece ses var. Hintlilerin şivesini bilen bilir, neyse ki yıllardır Hintlilerin verdiği seminer ve konferanslardan kulağımız aşina, yoksa ilk duyan birisi için gerçekten zorlayıcı olabilir; hele ki bir de telefondan sesin boğuk geldiğini düşünürseniz, gerisini siz hesap edin…

Neyse, bu mülakatta bana sorulan soruların başlıklarının aklımda kalan kadarını sizlerle paylaşayım.
- Bir DBA olarak günlük yaşadığın sorunlar nelerdir?
- Log Shipping, Database Mirroring, Replication gibi teknolojileri kullandın mı?
- Replication'ın hangi modellerini kullandın?
- Replication'da karşılaştığın bazı sorunlardan bahseder misin?
- Failover Clustered Instance'larla çalıştın mı?
- Bir Cluster'daki Node'larda güncelleme yapacağın zaman, kesinti süresini en aza indirmek için neler yaparsın?
- Bir SQL Server Instance'ını Komut İstemcisi'nden nasıl çalıştırırsın?
- Bir SQL Server Instance'ını kullanıcı veritabanlarını açmadan nasıl çalıştırırsın?
- Policy Based Management'tan günlük işlerinde faydalanıyor musun?
- İstatistikler ne işe yarar?
- Index bakımını ne sıklıkta yapıyorsun ve bu işlemi neden yapman gerekiyor?
- Bir TempDB'yi nasıl yapılandırırsın?
- Örneğin bir yazılımcı veya kullanıcı seni aradı, şu şu SP geçen hafta iyi çalışıyordu, ama bu hafta rezalet dedi, ne yaparsın? Sorunlu SP'yi nasıl bulursun? Bu SP'ye nasıl müdahale edersin?
- Bana RAID'lerden bahseder misin? Örneğin Transaction Log'unu nasıl bir RAID yapılandırmasında barındırmak isterdin? Neden?
- Bir sunucuya tam erişimin var ve sana bu sunucunun CPU, RAM ve IO kaynaklarında sıkıntı olduğu söylendi, bunları kontrol etmen gerekiyor, ne yaparsın? Hangi uygulamayı kullanırsın?
- Kullandığın 3. parti uygulamalar var mı? Örneğin yedekleme veya sistem izleme için? Varsa bunlardan bahseder misin?
- Sistem izleme konusunda neler yapıyorsun, hangi Tool'lardan faydalanıyorsun, nasıl tedbirler alıyorsun?
- SQL Server Instance düzeyinde CPU ve RAM ile yapılabilecek yapılandırma ayarlarından bahsedebilir misin?
- Ne zamandan beri sorgu iyileştirme çalışmaları yapıyorsun? Bir sorguyu iyileştirmek için neler yaparsın?
- Deadlock'ları nasıl tespit edersin?

Not: Mülakat 40dk sürdü. Soruları, bana sorulan sıraya göre değil, şimdi aklıma geldiği sırada yazdım.

Açıkçası ben şu konu başlıklarından da soru gelmesini beklerdim, ama bu sefer gelmedi:
- Index yapıları ve çeşitleri
- AlwaysOn Availability Groups
- Table Partitioning
- Service Broker
- Dynamic Management View/Function'lar
- SQL Server'da Güvenlik
- Yedekleme stratejileri
- High Availability ve Disaster Recovery senaryoları
gibi...

Aklımda bunlar kalmış, sıcağı sıcağına yazayım en azından meraklılar için bir fikir verir dedim.

Bu arada, aklıma geldi de yazmadan edemedim. Sene 2011 idi sanırım, o zaman bizim bölüm müdürü olan arkadaş bir aday ile iş görüşmesine girmişti. Görüşmede bizim müdür, adaya "Cluster'lar hakkında ne düşünüyorsun?" diye sormuş ve aday da "Bence gereksizler" demiş. Bizim müdür bana şöyle demişti "Benim için iş görüşmesi o anda bitmişti". Haha ne gülmüştüm. Lütfen böyle durumlara düşmemek için dersinizi iyi çalışın. Hepinize mutlu kariyerler, mutlu ve huzurlu hayatlar dilerim!

Sevgiler,
Ekrem Önsoy

Verilerinizi ne kadar verimli depoluyorsunuz?

Selam millet,

Leaf Level'daki sayfalarınızın doluluk oranının ne olduğuna en son ne zaman baktınız? Veya hiç baktınız mı? Index Fragmentation konusunun başlığı altındaki Dahili Parçalanma, tam da anlatıyor olacağım şeylerden bahseder. Şimdi Index Fragmentation konusuna girmeyeceğim, sadece atıfta bulunmak istedim, çünkü birbirleriyle alakalı konular. Size, gerek B-Tree elemanlarının sayfa sayılarını nasıl bulabileceğinizi ve bu sayfalardaki ortalama sayfa doluluk oranına nasıl bakacağınızı anlatmak istiyorum.

Bu bilgilere ulaşmak için sys.dm_db_index_physical_stats DMV'sinden faydalanıyoruz. Burada sizlere örneklerle anlatmak için, Production ortamındaki bir tablomuzu kullanacağım. Bu tabloda verinin yanında bol bol da Index var. Tablom ise Clustered yapıda. Elbette tablonuz Heap yapıda olduğunda veya BLOB veriler tuttuğunuzda veya bir kaydın tek başına bir sayfaya sığmadığında farklı bazı sonuçlarla da karşılaşıyor olacaksınız, fakat hepsini bir yazıya sığdırmak zor. O nedenle bu yazıda sadece Clustered yapıdaki bir tablomdan örnek vereceğim ve bu tablodaki tüm kayıtlar bir sayfaya sığacak küçüklükte.

Kullandığım sorgu şöyle:

SELECT index_id, partition_number, index_type_desc, index_level, page_count, avg_page_space_used_in_percent, record_count, min_record_size_in_bytes, max_record_size_in_bytes, avg_record_size_in_bytes FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('tablo_adı'), NULL, NULL, 'detailed')

Not: sys.dm_db_index_physical_stats DMV'sinin ayrıntıları için BOL'dan faydalanabilirsiniz.

Bu sorguyu çalıştırdığımda dönen sonuç da aşağıda:

Önceden de dediğim gibi, bu yazımda Fragmentation'a değinmeyeceğim, maksadım gerek Leaf Level'da, gerekse diğer Level'larda sayfa doluluk oranı, ortalama sayfa boyutu gibi ayrıntıları göstermek. Bu nedenle sorguya sadece ilgili alanları ekledim. Şimdi bu alanlardan nasıl bilgilere ulaşabileceğinizi izah etmeye çalışayım.

index_id: Bu alanı sys.indexes tablosundaki index_id alanıyla birleştirip Index'in adını bulabilirsiniz. İlgili kaydın, hangi Index'e ait olduğunu belirtiyor.

partition_number: Eğer tablonuzun birden fazla Partition'ı varsa (ki SQL Server 2005'ten beri tüm tablolar varsayılan olarak 1 Partition'dır) o zaman burada ilgili kaydın hangi Partition'a ait olduğu belirtilir. sys.dm_db_index_physical_stats DMV'sinin 4. parametresi (ben NULL kullandım yukarıda) Partition numarası içindir, eğer tablom Partitioned olsaydı, o zaman sadece belli bir Partition için de çalıştırabilirdim sorgumu.

index_type_desc: (Varsa) Index'imizin tipinin açıklamasını belirtiyor. Eğer tablomuz Clustered ise zaten index_id'si de 1 olacaktır, eğer daha büyük bir sayı ise o zaman bu kayıt Nonclustered bir Index ile ilgilidir. Heap tablolarda ise bu değer 0'dır.

index_level: B-Tree'deki katmanları simgeler. 0, Leaf Level'dır, yani tüm gerçek verinin (sayfalar içerisinde) bulunduğu katman. Yukarısında Branch Level (Intermediate Level da denir)'lar vardır ve en üstte de Root Level vardır. Yani buradaki en yüksek değer Root Level'ı temsil eder. En yüksek değer ile 0 arasında kalanlar da Brach Level'ları. Ben bu sorguya ekran görüntüsü çok genişliyor diye index_depth alanını katmadım, o alanda ilgili Index'in toplam kaç katmandan oluştuğu belirtiliyor. Örneğin index_id = 1'in index_depth'i 4'tür.

page_count: İlgili katmanda kaç adet sayfa (Page) olduğunu gösterir. Haliyle tüm kayıtlar Leaf Level'da bulunduğu en çok page_count değeri olanlar index_level'ı = 0 olanlardır. Burada hemen bilmeyen arkadaşlar için belirteyim, SQL Server'da veriler sayfalarda tutulur. Bir sayfanın içerisinde birçok kayıt barındırılabilir, bu tamamen kayıtların büyüklükleriyle ilgilidir. 1 sayfanın boyutunun 8kb olduğu notunu da ekleyeyim.

avg_page_space_used_in_percent: İlgili katmandaki sayfaların ortalama doluluk oranını belirtir. Örneğin yukarıdaki ekran görüntüsündeki Clustered Index'imin Leaf Level'ınındaki sayfalarımın ortalama doluluk oranı yuvarlarsak %92.88 imiş, fena bir oran değil. Eğer bu oran yeterince yüksel değilse, o zaman öncelikle kullandığınız Fillfactor değerlerine bir gözatın. Bunun yanında, tablolarınızdan yüksek miktarda veri silme işlemi yaptığınızda da bu oranın düştüğünü gözlemleyebilirsiniz. Sayfalarınızın doluluk oranları ne kadar düşükse, sadece disk altyapınızı değil, hafıza kaynaklarınızı da verimsiz kullanmış olursunuz. SQL Server önceden de belirttiğim gibi kayıtlarınızı sayfalar şeklinde saklar. Her sayfanın da 8kb olduğunu belirtmiştim, yani diskten veri okuyacağı veya yazacağı zaman sayfanın doluluk oranı fark etmeksizin yapacaktır bu işlemi. Örneğin 100 kayıtlık bir sorgu çalıştırıldığında, bu 100 kayıt sadece 1 sayfadan da okunabilir, yani maliyeti 8kb olur, onlarca sayfadan da, onlarca kb. Tabii ki maliyet çok daha büyük kayıt sayılarında duruma göre katlanacaktır.

record_count: sayfalarınızda tutulan toplam kayıt sayısını belirtmektedir. Bu sefer aşağıdaki ekran görüntüsüne bakın lütfen. Bu sefer bu tablo için hem sp_spaceused komutunu, hem de sys.dm_db_index_physical_stats sorgusunu birlikte çalıştırdım. Ekran görüntüsünden görebileceğiniz üzere, sp_spaceused komutuyla dönen kayıt sayısı ile (rows) sys.dm_db_index_physical_stats'ten dönen kayıt sayısı (record_count) birebir aynı. Yine aşağıdaki ekran görüntüsündeki ilk kaydı örnek olarak alırsak, 8.152.785 adet kaydın 600.059 adet sayfada tutulduğunu görebiliriz. Bu bilgilerle de tablomuzdaki verinin boyutunu x 8kb işlemiyle öğrenebiliriz. Bu hesabı ve sonucunu ve sp_spaceused'tan gelen sonuç ile nasıl eşleştiğini aşağıdaki ekran görüntüsünde bulabilirsiniz.

min_record_size_in_bytes: Bu değer, sayfalarımız içerisindeki en küçük kaydın boyutunun bilgisini verir. Örneğin Clustered Index'imizin Leaf Level'ın'daki en küçük kaydımız 277 byte imiş.

max_record_size_in_bytes: Bu değer de sayfalarımız içerisindeki en büyük kaydın boyutunun bilgisini verir. Örneğin Clustered Index'imizin Leaf Level'ın'daki en büyük kaydımız 844 byte imiş.

avg_record_size_in_bytes: Adından da anlaşılacağı üzere tüm sayfalardaki tüm kayıtların ortalama boyutu bilgisini veriyor.

Bu yazımda sizlere sayfalarımızı içerisindeki verilerin genel durumu hakkında bilgi alabileceğimiz ve bununla ilgili neler yapabileceğimiz hakkında genel bir bilgi paylaşmaya çalıştım. Umarım verilerinizin nasıl saklandığına ve bunun nasıl optimize edilebileceğine dair bir fikir edinmişsinizdir.

Sevgiler,
Ekrem Önsoy

Azure SQL veritabanının versiyonunu v11'den v12'ye yükseltmek

Merhabalar,

Haftasonu Azure SQL Database sunucumuzun v11'den v12'ye sürüm yükseltme (Upgrade) işlemini yaptım. Bu deneyimi sizlerle de paylaşmak sitedim.

v12 versiyonunda, birçok özellik eklendi. Temel olarak amaç, buluttaki SQL veritabanlarını kendi sunucularımızda kullandığımız özelliklerle kullanabilmemiz, en azından olabildiği ölçüde. Çünkü sonuçta Azure SQL veritabanlarını veritabanı bazında yönetebiliyoruz, Instance veya sunucu bazında değil. Bu nedenle illa ki birebir aynı olmayacaklardır. Bunun yanında, Row Level Security veya Data Masking özelliklerinde gördüğümüz gibi SQL Server'ın yeni versiyonunda gelecek olan özellikler ilk olarak Azure SQL Veritabanlarında kullanıma açılıyor. Bir taraftan da bu özellikler olgunlaşmış oluyor. Neyse, konumuza dönersek, öncelikle Azure SQL veritabanınızın versiyonunu, kendi sunucularımızda kullandığımızdaki gibi aşağıdaki şekilde ile bulabilirsiniz:

Eğer versiyon v11 ise, o zaman bir sonraki kontrolümüze, yani eski (Retired) Tier'lardan herhangi bir veritabanınızın olup olmadığı kontrolüne geçebiliriz. Eski Tier'lar derken kastettiğim Web ve Business Tier'ları, v12'ye sürüm yükseltme için bu Tier'ları terk etmeniz gerekiyor.

Eğer yukarıdaki Pricing Tier listesinde Web veya Business Tier'larından veritabanlarınız varsa, o zaman v12'ye Upgrade işlemini yapmaya devam edemezsiniz. Ya bu veritabanlarının Tier'ını Basic, Standard veya Premium olarak değiştireceksiniz veya benim gibi işe yaramayan eski Tier'dan kalma veritabanlarınızı silersiniz. Bu gereksinimi de tamamladıktan sonra sürüm yükseltme işlemine devam edebilirsiniz.

Sürüm yükseltme işlemini portal.azure.com adresinden yapabilirsiniz. Fakat bu işi yapmadan önce hazırlık ve planlama için bu makaleyi okumanızı tavsiye ederim. Temel olarak bilmeniz gereken ise, Sürüm yükseltme işleminin saatler ve günler aralığında sürebilecek olma olasılığı ve bu süreçte veritabanlarınız Online olarak kalacak olsa bile bazı yönetimsel kısıtlarla karşılaşacak oluyor olmanız. Bunun yanında şayet varsa geo-replikasyonu da sürüm yükseltme işleminden önce kaldırmanız, sonrasında tekrar kurmanız gerekiyor. Tüm bunlardan sonra (en azından 08 Haziran 2015 tarihi itibariyle) şu yolu takip ederek sürüm yükseltme işlemini gerçekleştirebilirsiniz.

Sol taraftaki menüden Browse'a tıklayın, ardından SQL Servers ve sonra da sağ tarafta çıkan Azure SQL veritabanlarınızı barındıran ve sürüm yükseltme işlemini yapmak istediğiniz sunucuya tıklayın.

Ekran sağ tarafa genişleyecek ve karşınıza aşağıdaki gibi bir ekran çıkacak. Burada "Server version" kısmında v12 görüyorsunuz, çünkü ben bu ekran görüntüsünü sürüm yükseltme işleminden sonra aldım. Sizin senaryonuzda burada v11 yazıyor olacak. En azından v11'den v12'ye sürüm yükseltme işlemi esnasında.

Sürüm yükseltme işlemine devam etmek için "Latest SQL database update" etiketli düğmeye tıklayın.

Eğer eski Tier'lardan kalma (Retired) bir veritabanınız yoksa o zaman karşınıza aşağıdaki gibi bir ekran çıkacaktır. Sürüm yükseltme işlemini gerçekleştirmek bu işlemi yapıyor olduğunuz sunucunun adını teyit etmek için "TYPE THE SERVER NAME" metin kutusuna yazmanız gerekiyor. Yani yeni bir sunucu oluşturmuş veya sunucunun adını değiştirmiş olmuyorsunuz, sadece teyit için varolan ve Upgrade etmek istediğiniz sunucunuzun adını giriyorsunuz. Sürüm yükseltme işlemini gerçekleştirmek için sunucu adınızı eksiksiz olarak girdikten sonra aşağıdaki OK düğmesine tıklayın.

Yukarıdaki ekranda, önceden de değindiğim gibi bu işlemin duruma göre saatler ve hatta günler sürebildiğine dair bir mesaj göreceksiniz. Fakat örneğin benim senaryomda v11'den v12'ye sürüm yükseltme işlemi 30dk içinde tamamlandı.

Sevgiler,
Ekrem Önsoy

SQL Server 2016: AlwaysEncrypted

Merhaba arkadaşlar,

İlgili birçok arkadaşımın bildiği gibi kısa bir süre önce Microsoft Ignite'ta SQL Server 2016 resmen duyuruldu. Bu ürün, birçok yeni özellikle gelecek, bunlardan biri de AlwaysEncrypted özelliği.

Bugün AlwaysEncrypted konusunda bir Online seminere katıldım. Bu seminerde aldığım notlarımı sizlerle de paylaşmak istedim.

Önceden bu özelliği hiç duymamış arkadaşlarım için çok özet bilgi vereyim. AlwaysEncrypted, SQL Server 2016 ile birlikte gelen yeni bir güvenlik özelliği. Bu özellik ile vaad edilen, verinin diskte dururken de, uygulama ile veri alışverişi yapılırken yolda da şifreli halde olması. Böylece hassas verinin sistem yöneticileri, veritabanı yöneticileri, Hacker'lar ve diğerlerinden korunması amaçlanıyor. Temel olarak veri, uygulama ile veritabanı arasında veri alış verişinin yapılmasını sağlayan Provider aracılığı ile, Column Master Key ve Column Encryption Key adı verilen Key'ler ile korunuyor. Henüz bu özelliğin ilk versiyonu olduğu için bazı sınırlamalar var, bunları aşağıdaki notlarımda da görebilirsiniz.

- Veri henüz veritabanına yazılmadan önce, Client tarafındaki ADO.Net Driver'ı tarafından şifreleniyor. Bunun kullanılabilmesi için Client tarafında .Net Framework 4.6'nın kurulu olması gerekiyor. Şimdilik desteklenen tek Provider bu.

- Veritabanında ilgili alanlar açık metinler olarak görünmüyor, 0x039723EN2D2087D286DB283B... gibi bir şekilde görünüyorlar.

- Client tarafında şifreleme için kullanılan Column Master Key için mesela Azure Key Vault gibi Key barındırma mekanizmaları kullanılabiliyor. Sadece Column Encryption Key, şifreli bir şekilde veritabanında tutuluyor. Veritabanı yöneticisinin veya diğer sistem yöneticilerinin Column Master Key'e ulaşamıyor olması gerekiyor.

- Bu özelliğin bu ilk versiyonunda, şifrelenmiş veri sorgulanırken bazı sınırlamalar var. Örneğin şimdilik sadece eşitlilik karşılaştırmaları yapılabiliyor, Join'ler, Group By ve Distinct operatörleri kullanılabiliyor.

- Şifreleme alan bazında yapılıyor, veritabanı veya tablo bazında değil.

- İki çeşit şifreleme yöntemi var, birisi Randomized, diğeri ise Deterministic. Eğer veriyi sadece şifreli bir şekilde saklamak istiyorsanız, Randomized; eğer sakladığınız şifreli veriyi sorgulamak istiyorsanız Deterministic. Çünkü veri Randomized şekilde şifrelendiğinde, bu veriye bir eşitlik sorgulamasıyla ulaşılamıyor, çünkü aynı metin için her seferinde farklı bir şifreli metin üretiliyor. Veri Randomize olarak şifrelendiğinde, bu alan için bir Index bile tanımlanamıyor.

- Mesela aşağıdaki gibi sorgular: 

DECLARE @SSN1 VARCHAR(11) = '111-22-3333'; SELECT * FROM Customers WHERE SSNS = @SSN1; 

INSERT INTO Customers VALUES('John Doe', '012-34-5678') 

AlwaysEncrypted devreye alındıktan sonra çalışmayacak. Uygulamadan veritabanına parametrelerin ADO.NET'teki SqlParameter ile gönderilmesi gerekiyor. Şifreleme ve şifreli metinin çözülmesi bu şekilde sağlanıyor.

- Sınırlı Conversion desteği var.

- Örneğin VARCHAR bir alanı şifreleyecekseniz, o zaman bu alan için Binary Collation'ını kullanmanız gerekiyor.

- XML, GEOGRAPHY, GEOMETRY, TEXT, NTEXT gibi bazı alanlar desteklenmiyor. Bu alanların bazıları zaten Depricated, yani bir süre sonra kaldırılacak. 

Şimdilik bu konu hakkında edindiğim bilgiler böyle.

Sevgiler,

Ekrem Önsoy

The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. (System.Data)

HATA:
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. (System.Data)

AÇIKLAMA:
Microsoft SQL Server 2014 - 12.0.2000.8 (X64) ile *.xlsx uzantılı bir Microsoft Excel dosyasını Import etmek isterken böyle bir hata mesajı aldım.

Excel Version listesinde Excel 2007 zaten vardı, fakat belli ki bir şeyler eksikti.

ÇÖZÜM:
Ben de çözümü bir forumda buldum, fakat özellikle daha derli toplu olsun diye burada da kayıt altına almak istedim. Eğer aşağıdaki dosyayı indirip kurarsanız, hiç sunucuyu veya SQL Server Management Studio'yu yeniden başlatmaya bile gerek kalmadan sorununuz çözülmüş oluyor.

2007 Office System Driver: Data Connectivity Components

Sevgiler,
Ekrem Önsoy