Microsoft Azure: Query Editor

30 Ocak 2017 tarihinde Microsoft, Query Editor'ün ilk sürümü hakkında bir duyuru yayınladı.

Bugün bu yeni özelliği biraz inceleme fırsatım oldu, sizlerle de paylaşmak istedim.

Peki neden SQL Server Management Studio (SSMS) gibi, diğer benzeri araçlara nazaran çağlar ötesinde olan bir uygulama varken Query Editör gibi bir araca ihtiyaç duyulabilir? Eğer Azure Portal'da çalışıyorken portalı hiç terk etmeden, SSMS gibi harici bir uygulamaya geçiş yapmak zorunda kalmadan, güvenlik duvarı ayarlarıyla uğraşmadan Azure SQL Database veya Azure SQL Data Warehouse veritabanlarınızda komut çalıştırmak istiyorsanız Query Editor pratik bir seçenek olabilir.

SQL Database veya SQL Data Warehouse içerisinden Query Editor'e ulaşabilirsiniz. SQL Data Warehouse'taki ekran biraz daha farklı, ama Overview'üne giriş yapınca hemen fark edeceksinizdir.

Eğer Query Editor'ü ilk defa kullanacaksanız, özellik henüz deneme aşamasında olduğu için sizden onay istenecek. Sonrasında ise komutları çalıştırmak için aşağıdaki görselde gösterildiği gibi sisteme giriş yapmanız gerekecek.

Sisteme giriş ekranı

Sisteme başarılı bir şekilde giriş yaptıktan sonra SSMS'teki gibi yeni tablo oluşturabilir, SP yazabilirsiniz. Tabii SSMS gibi bir ortam beklemeyin, yani Object Explorer veya diyaloglar yok, adından da anlaşılabileceği gibi sadece kod yazılıyor Query Editor'de. Komutların sadece seçtiğiniz bölümlerini çalıştırabiliyorsunuz, yani kısmi kod çalıştırma özelliği mevcut. Ayrıca "Open query" düğmesine tıklayarak makinenizde varolan Script'lerinizi açıp çalıştırabilirsiniz ve "Save query" düğmesiyle de yeni Script'lerinizi yine kendi makinenizde saklayabilirsiniz.

Bir komutu çalıştırdığınızda "Authenticated as eonsoy" yazan bölümde saniye işlemeye başlıyor.

Sorguları çalıştırmak için alışkanlıkla F5'e basmayın sakın, tahmin edeceğiniz gibi tüm sayfa yenileniyor, yazdığınız onca Script'i kaybedebilirsiniz! Maalesef bu versiyonda henüz bu konuda bir önlem yok. Yani F5'e bastığınızda "Henüz kaydedilmemiş veriniz silinecektir" gibi bir uyarı gelmiyor. Microsoft'un ilgili bölümüne bu konuda geribildirimde bulundum, bunu dikkate almamaları imkansız. Bu konuda bir gelişme olursa, yine burada ayrıca paylaşırım.

Güncelleme: Az önce Microsoft'taki ilgili takımdan cevap geldi, bu sorunun farkındalarmış ve zaten üstünde çalışmaktalarmış.

Ekrem Önsoy

Ocak ayında oluşturduğum Microsoft SQL Server hata kayıtları

Sizlerle Ocak ayında oluşturduğum SQL Server'a ait hata (bug) kayıtlarını paylaşmak istiyorum. Ocak ayı hata kayıtları açısından biraz yoğun geçti.

Hata 1:
Aşağıdaki hata kaydı, SQL Server Management Studio'nun yeni versiyonlarında Task List'in hatalı oluşuyla ilgili. Hatalı derken kastettiğim şu, mesela yeni görev oluşturma düğmesi ve görevin türünün belirlendiği aşağı açılır kutu Task List penceresinde görünmüyor.

https://connect.microsoft.com/SQLServer/feedback/details/3118202/task-list-seems-incomplete


Hata 2:
Aşağıdaki diğer hata kaydı da veritabanınızı yerel sunucunuzda oluşturup, dosyalarını Microsoft Azure Blob Storage'da sakladığınızda oluşuyor. Hata, veritabanınız için oluşturduğunuz Database Snapshot'tan dönüş yapmaya çalıştığınızda oluşuyor. Aynı senaryo, veritabanı dosyaları yerel sunucuda konumlandığında oluşmuyor. İpucu: Database Snapshot'tan nasıl geri dönüş yapılacağı da ayrı bir blog konusu.

https://connect.microsoft.com/SQLServer/feedback/details/3117785/reverting-from-a-database-snapshot-when-database-files-on-azure-blob-storage


Hata 3:
Bu hata da Transparent Data Encryption özelliği etkinleştirildiğinde ve kapatıldığında SQL Server 2014 SP2 ve SQL Server 2016 SP1'deki sys.databases ve sys.dm_database_encryption_keys catalog view'lerinin farklı sonuçlar döndürmesiyle ilgili.

https://connect.microsoft.com/SQLServer/feedback/details/3118734/tempdb-looks-encrypted-but-it-shouldnt-have-been

Güncelleme 01.02.2017: Ben 13 Ocak tarihinde bu konuda yukarıdaki hata kaydını açtıktan sonra Microsoft'tan Bob Ward yine bu konuda 27 Ocak tarihinde bu konuyu incelemiş. Merak edenler yazıya buradan ulaşabilir.

Eğer açtığım hata kayıtlarına oy vermek isterseniz, bir Microsoft hesabı açmanız yeterli.


Ekrem Önsoy

Azure Standard Storage'larınızda TRIM etkin mi?

Microsoft Azure sanal makinelerinizde kullandığınız Standard Storage (HDD)'lerdeki TRIM özelliğinden haberdar mısınız? Eğer değilseniz, Microsoft Azure'da sanal diskleriniz varsa ve Storage maliyetlerinizi düşürmek istiyorsanız okumaya devam edin.

Efendim artık öyle veya böyle bulut projelerine bulaşmak kaçınılmaz oldu. Bu konuda da edindiğim tecrübe ve bilgileri olabildiğince sizlerle paylaşıyor olacağım.

Bu aralar benim de dahil olduğum bir Azure projesinde çalışırken oluşturulan bazı disklerde TRIM kullanılmadığını gördüm. Eğer TRIM kullanılmazsa ne mi olur? Diskiniz için ne kadar alan tanımlandıysa, ki bu alan miktarı an itibariyle azami 1TB'tır, o kadar alan boyutu için ücretlendirilirsiniz. Fakat o disk için TRIM özelliği etkinleştirilmişse, o zaman sadece o diskte kullandığınız alanlar kadar ücretlendirilirsiniz.

Misal yeni veya varolan bir sanal makineniz için 1TB boyutunda bir Standard Storage disk oluşturdunuz ve kullanmaya başladınız. Bu diskteki dosya veya dosyalar sabit belli bir boyutta değil, zaman zaman büyüyor, zaman zaman küçülüyor. İşte özellikle böyle senaryolar için TRIM özelliğini kullanırsanız Azure faturanız azalır.

Peki TRIM özelliğinin etkin olup olmadığını nasıl anlayabilirsiniz? Diskin bağlı olduğu sanal makineye bağlanın ve Command Prompt'tan aşağıdaki komutu çalıştırın:

fsutil behavior query DisableDeleteNotify

Eğer yukarıdaki komut sonuç olarak 0 döndürüyorsa o zaman TRIM etkin demektir, eğer sonuç olarak 1 dönüyorsa o zaman TRIM etkin değildir. TRIM'i etkinleştirmek için aşağıdaki komutu çalıştırabilirsiniz.

fsutil behavior set DisableDeleteNotify 0

Kaynak:
https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-attach-disk-portal?toc=%2fazure%2fvirtual-machines%2fwindows%2ftoc.json


Ekrem Önsoy

Bir Azure SQL Database'i yerel bir Instance'a taşımak

Selam millet,

Bugün bir yazılımcı arkadaş, Azure SQL Database'de bulunan bir veritabanını verileriyle birlikte yerel bir sunucumuza taşıma talebinde bulundu.

Yaptığım işlem çok özetle ilgili SQL Database'i Azure'daki müsait bir Storage'a Export etmek ve sonrasında üretilen *.bacpac dosyasını yerel ortamdaki uygun bir sunucuya indirmek ve daha sonra da Restore/Import edilmesi istenen yerel SQL Server Instance'ına Restore etmek oldu.

Bu yazıda daha ziyade değinmek istediğim şey ise *.bacpac dosyasının marifeti. Azure SQL Database'deki veritabanının versiyonu 12.0.2000.8, yani V12 idi, *.bacpac dosyasını Restore ettiğim Instance'ın versiyonu ise 11.0.5582.0 idi. Deneyimli her SQL Server DBA'in bildiği gibi, üst bir versiyonda oluşturulmuş olan *.bak dosyaları alt bir versiyona Restore edilemez. Daha net olmak gerekirse ve bu örnek üstünden gidersek 12.0.2000.8 versiyonunda olan bir Instance'ta oluşturduğunuz bir *.bak dosyası 11.0.5582.0 versiyonlu bir Instance'a Restore edilemez. Fakat 12.0.2000.8 versiyonunda oluşturulmuş bir *.bacpac dosyası pekala ve başarıyla 11.0.5582.0 versiyonlu bir Instance'a Restore edilebiliyor.

Bununla birlikte, bu Restore (aslında Import) işlemini doğrudan 11.0.5582.0 üstündeki SQL Server Management Studio'dan yapmaya çalıştığımda şöyle bir hata aldım:

TITLE: Microsoft SQL Server Management Studio
------------------------------
Count not load schema model from package. (Microsoft.SqlServer.Dac)
------------------------------
ADDITIONAL INFORMATION:
Internal Error. The database platform service with type Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider is not valid. You must make sure the service is loaded, or you must provide the full type name of a valid database platform service. (Microsoft.Data.Tools.Schema.Sql)

Bu sorun *.bacpac dosyasından ziyade SQL Server Management Studio'nun versiyonuyla ilgiliydi. Aynı *.bacpac dosyasını SQL Server Management Studio'nun daha yeni bir versiyonunda Import etmeyi denediğimde hiçbir sorunla karşılaşmadan işlem başarıyla tamamlandı. Eğer olur da biri böyle bir hata ile karşılaşırsa diye burada not etmek istedim.

Sevgiler,
Ekrem Önsoy

Stretch Database denemeleri

Selam millet,

SQL Server 2016 ile gelen Stretch Database ile ilgili tecrübelerimi kısmen de olsa sizlerle de paylaşmak istedim.

Stretch Database özelliğinin nasıl etkinleştirileceği ve benzeri konuları zaten önceden birçok arkadaş (mesela Yusuf'un yazısına bakabilirsiniz) anlattı, Microsoft'un bu konudaki dokümantasyonları da gayet yeterli. Bu özelliğin tecrübesiyle ilgili yazı ise çok az, şahsen ben sadece Gail Shaw'un bir yazısını okumuştum bir süre önce. Her neyse, aşağıda sizlerle bulgularımı paylaşayım.

Öncelikle Stretch Database özelliği dediğim gibi SQL Server 2016 ile birlikte geldi. Yani bu, bu özelliğin ilk versiyonu. Özelliklerin ilk versiyonlarında da çoğu zaman birçok sınırlama olur. Bu sınırlamalara da yine Books Online'dan ulaşabilirsiniz.

Çok özetle Stretch Database nedir, onu belirteyim. Bu özellikle hedef, kendi SQL Server sunucularımızda barındırdığımız soğuk verilerin, bize hissettirilmeden, Azure'daki bir SQL Database'e aktarılması. Böylece kendi sunucularımızdaki soğuk veriyi Azure'daki ucuz Storage alanına taşımış olacağız. Böylece kendi sunucularımızdaki değiştirilmeyen veri için disk alanı harcamamış olacağız, Index bakımı ve benzeri masraflı ve uzun süren işleri yapmamış olacağız.

Not: Index bakımı için parçalanma olmayan tablolara tekrar tekrar Index bakımı yapmak zaten gereksiz bir iştir ve Ola Hallengren'inki veya MidnightDBA'in Minion Reindex'i gibi ücretsiz Script'lerle bu sorunu bertaraf edebilirsiniz.

Efendim konumuza geri dönersek, X tablonuzdaki soğuk verinizi Azure'daki bir SQL Database'e taşıdınız diyelim, peki sonra bu veriye nasıl ulaşıyorsunuz? Tablonuzu eskiden nasıl sorguluyorsanız, aynı şekilde sorgulamaya devam ediyorsunuz. Azure'daki verinin sorgulanması, "akıllı sorgulama" adı verilen bir yöntem ile size "pek" hissettirilmeden yapılıyor. "Pek"i vurgulamamdaki maksat, soğuk veriniz Azure'da olduğu için bu verinin getirilmesi sırasında bir yavaşlık yaşayacaksınız. Tabii ki ağ bağlantılarınıza göre değişebilir bu yavaşlık. Mesela test ortamımdan sizin için aşağıdaki ekran görüntüsünü aldım.

Yukarda sorguladığım "st" isimli tablodaki verilerin (OrderDate alanına göre) 2 Şubat 2015 tarihinden eski olan kayıtları Stretch Database özelliği ile Azure'a aktarılmış durumda ve oradan sorgulanıyor, bu sorgunun çalıştırılma planını da yukarıdaki ekran görüntüsünde mavi renk ile işaretlenmiş kısımlarda görebilirsiniz. 2 Şubat 2015'ten daha yeni tarihli olan veriler de kendi test makinemde. Gördüğünüz gibi doğrudan ve sadece makinemden sorgulanıyor, çalıştırılma planı yine yukarıdaki ekran görüntüsünde kırmızı ile işaretli ve hiç Azure SQL Database'e gitmeden çalışıyor... MU ACABA?

Bunu test etmek istedim ve bu amaçla testlerimi yaptığım sanal makinenin ağ bağlantısını kestim. Ağ bağlantısını kesince, kendi makinemde barındırılıyor olan veriyi sorgulamak için SQL Server'ın her şeye rağmen Azure SQL Database'e gitmeye çalıştığını gözlemledim. Aşağıdaki ekran görüntüsüne bakın lütfen.

Kendi yerelimdeki veriyi sorgulamaya başladığımda cevap gelmediğini, sorgunun beklediğini gördüm. Hemen işlemin durumunu sorguladım ve baktım ki Azure'dan cevap bekliyor. Tabii ağ bağlantımı kestiğim için bunu yapamıyor ve bir süre sonra çat! Aşağıdaki hata.

OLE DB provider "SQLNCLI11" for linked server "(null)" returned message "Login timeout expired".
OLE DB provider "SQLNCLI11" for linked server "(null)" returned message "A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.".
Msg 67, Level 16, State 1, Line 3
Named Pipes Provider: Could not open a connection to SQL Server [67]. 

Yani kendi yerel disklerinizdeki verilerin sorgulanması için bile Azure'a gidiliyor. Bu atlatılabilir mi, atlatılmalı mı, bir yöntemi var mı, henüz bu ayrıntıları ben de bilmiyorum. Bir dokümanda veya makalede de rastlamadım şimdiye kadar. Bilen varsa lütfen benimle paylaşsın.

Bu arada bu özelliğin SQL Server Management Studio ile kolaylıkla etkinleştirilebileceğini ve durdurulabileceğini de belirteyim. Ayrıca yine bu özellik için bir Monitor Dashboard'u da var.

Söylemek istediğim bir başka şey ise, bu özelliği etkinleştirdiğinizde Azure'da bir SQL Database oluşturulduğundan bahsetmiştim. Bunu SQL Server oluşturuyor, yani siz kontrol edemiyorsunuz hangi veritabanı olacağını veya adının ne olacağını. Ayrıca yine bu veritabanında soğuk verinin aktarıldığı bir de tablo oluşturuyor. Veritabanının adı: "RDAStretchTestDB47AFAFFF-4B4C-4F0C-9CE2-3E7B8D32FFA2" gibi ve tablonun da adı "dbo_ST_565577053_928B0242-E66A-43C1-A73C-F40A8D512A89" gibi oluyor. Buradan gelmek istediğim önemli nokta şu, bir tablo için Stretch özelliğini "Leave data in Azure" diyerek durdurduğunuzda ve daha sonra aynı tablo için farklı bir süzme fonksiyonuyla (süzme fonksiyonları, bir tablodaki verileri Stretch Database özelliği ile kısmen Azure SQL Database'e göndermek istediğiniz zaman kullanılır) tekrar bu özelliği etkinleştirdiğinizde, Azure SQL Database'te bu tablo için farklı bir kopya oluşturuluyor. Örneğin kaynaktaki tablonuzun adı "st" ve 2 Şubat 2015 tarihinden eski verileri soğuk veri olarak belirlediniz ve bunları bir süzme foksiyonuyla ve Stretch Database özelliğiyle Azure SQL Database'e gönderiyorsunuz diyelim. Daha sonra bu özelliği "Disable" duruma getirdiniz ve bunu yaparken de "Leave data in Azure"u seçtiniz. Ardından bir süre sonra bu özelliği "st" tablosu için tekrar etkinleştirmek istediniz, fakat süzme fonksiyonunu için 1 Ocak 2016 tarihinden eski kayıtların Azure'a gönderilmesi şeklinde ayarladınız. İşte o zaman Azure SQL Database'te "st" tablonuz için farklı bir tablo daha oluşturuluyor. Aşağıdaki ekran görüntüsüne bakın:

Ayrıca, bir tablo için Stretch Database özelliğini "Disable" duruma getirirken "Bring data back from Azure" seçeneğini seçerseniz veriniz (Azure'da oluşturulan en son tablodan) tekrar yerel disk alanınıza kopyalanır. Fakat Azure SQL Database'de oluşturulan tablo olduğu yerde kalır ve o tablo yüzünden hem SQL Database servisi için hem de Azure'daki Storage için para ödersiniz. Eğer ödeme yapmak istemiyorsanız o verileri elle gidip silmeniz gerekir. Bu paragrafta birkaç cümle önce "Azure'da oluşturulan en son tablodan" dedim, bunu özellikle dedim çünkü yukarıdaki ekran görüntüsünden de görebileceğiniz gibi aynı tablo için ("st" tablosu) 3 tane tablo oluşturuldu Azure SQL Database'de. Siz SQL Azure Database özelliğini "st" tablosu için "Disable" ettiğinizde ve bunu yaparken de "Bring data back from Azure" seçeneğini seçtiğinizde "st" tablosu için Azure SQL Database'te oluşturulan en son tablo kullanılıyor, eğer önceki "Disable"larınızda "Leave data in Azure"u seçtiyseniz ve en sonuncuda "Bring data back from Azure" seçtiyseniz önceden oluşturulan tablolardaki verilerinizi başka bir şekilde ve elle kendiniz geri yerel tablolarınıza aktarmalısınız. Stretch Database'in kendisi yapmıyor bunu.

Bu yazımda sizlerle paylaştığım bilgilerin bir çoğu dokümantasyonda yok, bu bilgileri ben kendi testlerim sırasında edindim. Eğer olur da dediklerimin aksi bir senaryo ile karşılaşırsanız lütfen bunu bana da bildirin, hepbirlikte öğrenelim.

Sevgiler,
Ekrem Önsoy

Azure Managed Backup testi sonucunda oluşan 1TB'lık dosya

Selam arkadaşlar,

Bir süre önce Microsoft Türkiye'den Osman Çokakoğlu ile görüştük. Sağolsun benim Bizspark programına dahil olmamı sağladı. Böylece Azure'u rahat rahat kurcalayabilmem için gerekli zemin de hazır olmuş oldu. Eğer 5 yaşını geçmemiş bir Startup'ınız varsa, Azure ile yazılım geliştiriyorsanız ve güzel projeleriniz varsa Osman ile iletişim kurmanızı tavsiye ederim.

Bu kapsamda bir süre önce bazı testlere başladım. SQL Server 2014 test ortamlarımım da Managed Backup'ı test ettim.

Öncelikle belirtmeliyim ki bu yazıdaki maksadım özelliğin baştan sona nasıl kurulacağını ve özelliğin ayrıntılı nasıl çalıştığını anlatmak değil, fakat testler sırasında karşılaştığım bir durumdan bahsetmek.

Efendim Managed Backup özelliği SQL Server 2014 ile birlikte geldi ve SQL Server Management Studio'yu açtıktan sonra ilgili SQL Server Instance'ınıza bağlanıp, Object Explorer'daki Management altında bulabilirsiniz bu özelliği.

Peki bu özellik ne işe yarar? Bu özellik, yedekleme ve stratejileriyle uğraşmak istemeyen ve yedeklerinin buluttaki (Azure) bir alanda barındırılmasını isteyenler için kullanılabilir. Yedekleme için herhangi bir zamanlama vs belirtmiyorsunuz. SQL Server belli kriterlere göre kendi uygun gördüğü zamanlarda Full Database ve Transaction Log yedeklerini kendi alıp Azure'daki belirteceğiniz Storage alanına sıkıştırarak kopyalıyor. Özelliği kullanabilmeniz için ilgili yerel SQL Server Instance'ınızda Azure hesabınıza erişim için bir Credential oluşturuyorsunuz, Storage adresinizi yazıyorsunuz ve tabii ki ilgili Azure hesabınızda, bu yerel ağınız için güven duvarı tanımlarını yapıyorsunuz, sonra özellik kullanıma hazır.

Tüm bu yazıyı yazmamdaki tek neden ise şu. Bu testi yaptığım makine bir sanal makine ve kendi dizüstü bilgisayarımda bulunuyor bu sanal makine. Yani zaman zaman dizüstü bilgisayarımı çat diye kapattığımda, test ortamı olarak kullandığım sanal makine de çat diye dondurulmuş oluyor. İnternet bağlantısı çat diye gidiyor. O sırada örneğin Azure'daki Storage alanıma bir yedek dosyası kopyalıyorsa, o da yarım kalıyor. Peki o zaman ne oluyor? İşte bugün o zaman ne olduğunu öğrendim.

Bugün ilgili test ortamımdaki Azure Storage Explorer'ı bir açtım, bir de ne göreyim!

Sıkıştırılmamış hali 300MB olan veritabanımın yedeği 1TB görünüyor! Bu nasıl olabilir diye düşündüm, taşındım, mantıklı bir neden bulamadım. Acaba bu test veritabanında bir işlem yapmıştım da veritabanının boyu ben farkında olmadan artmış mıydı? Aklıma ilk gelen bu oldu, ama baktım hayır, hala 300MB. Ayrıca 1TB'lık yedeklerden sonra da yine (sıkıştırıldığı için) 48,56MB'lık yedek alındığını ekran görüntüsünden siz de görebilirsiniz.

Bu duruma anlam veremediğim için arkadaşlara danıştım ve sağolsun Denny Cherry gayet akla yatkın bir yanıt verdi. Buraya kadar gelinceye dek test ortamımın özelliklerinden bahsetmemin bir nedeni vardı tabii ki, Denny'nin cevabının altyapısını oluşturmak. Efendim şimdi SQL Server, Azure Storage'a yedek alırken (henüz iç işleyişini bilmiyorum) yedek almaya başlıyor (muhtemelen Streaming şeklinde) ve eğer bu işlemi sağlıklı bir şekilde tamamlayamazsa, o zaman Azure dosyayı varsayılan bir boyut ile kapatmak zorunda kalıyor. Yani bu 1TB'lık dosyalar aslında Corrupt, tamamlanamamış yedekler. Bu 1TB da bu BLOB alanda oluşturulabilecek azami dosya boyutu. Sonuç olarak tüm bunlardan anladığım kadarıyla eğer yedek kopyalanması sırasında bu işlem başarıyla tamamlanamazsa, Azure bu dosyayı 1TB olarak kapatıyor. Haberiniz olsun!

Sevgiler,
Ekrem Önsoy

SSMS yenileniyor! Artık daha yeni, daha dinamik, daha güncel!

Merhabalar,

Enterprise Manager'dan sonra SQL Server 2005 ile birlikte hayatımıza giren SQL Server Management Studio (SSMS) artık daha güncel ve dinamik olacak. Nasıl mı?

Şöyle efendim, şimdiye kadar SSMS'in yeni versiyonları hep SQL Server Database Engine'in yeni versiyonlarıyla birlikte, yani son versiyonlara göre bakarsak, iki senede bir çıkardı piyasaya. Özellikle Azure SQL Database gibi, 2 yıl gibi uzun aralıkları beklemeden sürekli yeni özelliklerin eklendiği dinamik bir servisin de devreye girmesiyle, SSMS'in de böyle dinamik bir şekilde güncellenmesi ihtiyacı hasıl oldu. Çünkü SSMS, Azure SQL Database servisinin yönetimi ve bu ortamda yapılacak geliştirme işleri için de kullanılacak en temel araç. Bu nedenle Azure SQL Database servisine yeni bir özellik eklendiğinde, bu özelliğin SSMS tarafından da desteklenmesi gerekiyor ve bu destek artık içinde bulunduğumuz bu süreçte 2 yıl gibi bir süre bekleyemez.

Bu kapsamda ben de Microsoft'un ilgili sayfasından SSMS'in bu yeni versiyonunu test makimene indirdim ve kurdum. SSMS'in bu versiyonu (SQL Server 2016 CTP 2.2 - 31,5MB), SSMS'in önceki versiyonlarıyla yanyana çalışabiliyor, yani bunu kurmadan önce eski versiyonları kaldırmanız şart değil. Ayrıca, SSMS'in bu versiyonu SQL Server 2005 versiyonundan itibaren tüm SQL Server servislerini de destekliyor.

SSMS SQL Server 2016 CTP 2.2

Yukarıdaki ekran görüntüsünden de görebileceğiniz gibi SSMS'in bu yeni versiyonu, güncellemeleri otomatik olarak yapabiliyor. Bunun yanında, aşağıdaki ekran görüntüsünde "Check for Updates…" menüsünü de görebilirsiniz. Eğer güncellemeleri kendiniz kontrol etmek isterseniz, bu yöntemi seçebilirsiniz.

SSMS'in özellikle Azure SQL Database ile birlikte gelecek olan yeni özellikleri destekleyebilmesi için ve bununla sınırlı kalmayarak SQL Server'ın kendi makinelerimizde kurulu olan versiyonlarındaki henüz desteklenmeyen bazı özelliklerin arayüz olarak desteklenmesi ve zaten var olan arayüzlerin iyileştirilmesi / geliştirilmesi için Microsoft'un bu hamlesi sevindirici. Böylece birçok iş için kullanıyor olduğumuz SSMS, genel SQL Server yüklemelerinden bağımsız bir hale geldi. Bakalım zaman, daha nelere gebe?

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

Sneak peak: Strecthing tables into Azure!

Merhaba arkadaşlar,

Maalesef bu sene de PASS Zirvesine katılamadım, fakat arayı kapatmak için PASSTV'den faydalanmaya çalışıyorum. PASS'ın başındaki adam olan Thomas LaRock'ın Keynote'unu izlerken ilginç bir şey dikkatimi çekti; Rengarajan, bir mühendis yardımıyla bir veritabanındaki tablodaki sıcak verinin (güvenlik veya performans amacıyla) yerel sunucunuzda barındırılıp soğuk verinin (örneğin arşivlenecek veya seyrek olarak sorgulanacak veya hassas olmayan) Azure'a uzatılabileceğinden bahsetti. Konu başlığında da belirttiğim gibi bu yeni ve adı resmen konmuş bir özellik değil; yani ne Azure'un ne de SQL Server'ın bir sonraki versiyonuna gelecek diye bir şey denmedi. Sadece ucundan tanıtımı yapılmış oldu, ama bence gelecek vaadeden ve yakın gelecekte yeni versiyonlara eklenecek bir özellik gibi görünüyor.

Sunumdan bir ekran görüntüsünü aşağıda paylaşıyorum:

Bahsini ettiğim Keynote'u da buradan izleyebilirsiniz:

http://www.sqlpass.org/summit/2014/PASStv.aspx?watch=7Pum0vfYtSk

Bu özelliğin altyapısının nasıl olduğundan falan da bahsedilmedi, fakat sunumda birkaç komut görülebiliyor. Örneğin replikasyon şu şekilde dondurulabiliyor:

ALTER TABLE PAUSE STRETCH;

Veya aşağıdaki komut ile tekrar devam ettirilebiliyor:

ALTER TABLE RESUME STRETCH;

Şunu da eklemek isterim, replikasyon devam ederken tabloda işlem yapmaya devam edebiliyorsunuz.

Kolay gelsin,
Ekrem Önsoy

SQL Server 2014 (CTP2)'de Öne Çıkan Yeniliklere Özet Bakış - 2

SQL Server 2014'teki yeni özellik ve yeteneklerden bahsetmeye devam ediyorum.

* Artık gerek Windows Azure'daki sanal makinenizde bulunan SQL Server veritabanlarının gerekse istediğiniz başka bir Veri Merkezindeki veya kendi sunucunuzdaki SQL Server veritabanlarınızın Data ve Transaction Log dosyalarını Windows Azure Blob Storage denilen yerde tutabilirsiniz.

Yani örneğin şirketinizin, fiziksel olarak da şirketinizde bulunan sunucularında yüklü olan SQL Server Instance'ınızda oluşturacağınız veritabanlarının Data ve Transaction Log dosyaları Windows Azure'un bulut ortamında barındırılabilir hale geliyor.

* Bir diğer yenilik, aslında SQL Server 2012 Service Pack 1, Cumulative Update 2 ile birlikte gelmişti. Bir veritabanının yedeğinin Windows Azure Blog Storage'ına alınabilmesinden bahsediyorum. Fakat bu versiyonda buluta yedek alma işlemi yalnızca T-SQL, Powershell ve SMO ile destekleniyordu. SQL Server 2014 ile birlikte bu özellik SQL Server Management Studio arayüzünden de yapılabilecek.

* Yine veritabanı yedeklemesiyle ilgili bir başka ve güzel yenilik ise artık veritabanları yedeklenirken aynı zamanda bir sertifika veya asimetrik anahtar ile şifrelenebilecek. Şifreleme algoritması olarak da şunlar destekleniyor: AES 128, AES 192, AES 256, and Triple DES.