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
Hiç yorum yok:
Yorum Gönder