Selam millet,
Müşterilerimin birinde SQL Server 2014 kullanılıyor ve çok kritik bir sunucu. Bu kritik sunucuda saliselerin hesabı yapılıyor, tam bir klasik OLTP ortamı.
Bu canlı ortamda, test ortamına kıyasla daha fazla CPU kullanıldığını gözlemliyorduk ve nedenini de henüz bulamamıştık. Derken geçenlerde SQL Server 2014 SP1 CU7 yayınlandı ve bu CU'daki bir KB (3162589) "FIX: High CPU usage on SQL queries after install SQL Server 2014 Service Pack 1" çok dikkat çekiciydi. CU'yu inceledikten sonra ve tabii ki önce test ortamına da uyguladıktan sonra ilgili yöneticilerle konuşup, planlamamızı yapıp canlı ortama da uyguladık. Sonrasında en kritik Stored Procedure'lerimizin işlem sürelerinin 200-400 milisaniyelerden 40-60 milisaniyelere düştüğünü gözlemledik. Yani bu Bug bu ortamda bizi vurmuştu.
Yayınlanan Service Pack ve Cumulative Update'leri yakınen izlemenizi, KB'leri incelemenizi ve ortamlarınızdaki ihtiyaçlarınızla karşılaştırmanızı öneririm. Bu örnekte de görüldüğü gibi, güncellemeler bilinçli ve planlı bir şekilde uygulandıklarında çok şeyi değiştirebiliyorlar.
Sevgiler,
Ekrem Önsoy
30 Haziran 2016 Perşembe
13 Haziran 2016 Pazartesi
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
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
10 Haziran 2016 Cuma
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
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
3 Haziran 2016 Cuma
HATA: DCOM was unable to communicate with the computer server_name.domain_name using any of the configured protocols; requested by PID 5cac (C:\Windows\system32\ServerManager.exe).
HATA:
DCOM was unable to communicate with the computer "server_name.domain_name" using any of the configured protocols; requested by PID 5cac (C:\Windows\system32\ServerManager.exe).
Windows System Event Log'undaki Event Id'si: 10028.
AÇIKLAMA:
Bu hata ile AlwaysOn Availability Groups olan bir ortamdan 3 tane düğümü kaldırdıktan sonra karşılaşmaya başladık. Aklına "Toplamda kaç tane düğüm vardı da 3 taneyi kaldırdın?" sorusu gelenler için söyleyeyim, SQL Server 2012'nin izin verdiği tavan sayısındaydı düğüm sayısı.
Vel hasıl ben bu hatayı fark etmemiştim, sistem tarafından arkadaşlar haber verdi. Sorunu incelemeye tabii ki hata mesajıyla başladım. Hata mesajında en dikkat çekici şey, mesajın sonundaki "ServerManager.exe" idi. Demek ki sorun bir şekilde Server Manager aracıyla ilgiliydi. Server Manager'ı açınca "All Servers" bölümünde AlwaysOn ve Cluster'dan kaldırdığımız 3 düğümün adını gördüm. Her ne kadar AlwaysOn ve Cluster'dan bu düğümleri kaldırsam da, bunlar Server Manager'da kalıyor sanırım. Neden, niçin henüz bilemiyorum.
ÇÖZÜM:
Sorunu çözmek için basit bir şekilde Server Manager'daki All Servers bölümünden artık sistemde olmayan sunucuların üstüne giredek "Remove Server" seçeneğiyle bunların ikisini kaldırdım. Fakat üçüncüyü kaldırmama izin vermiyordu sistem. Aslında veriyordu, fakat seçili düğümü ve diğer tüm düğümleri Cluster'dan kaldırmak isteyip istemediğimi soruyordu. Yeterince korkutucu bir mesaj, değil mi? Tabii ki iptal ettim işlemi. Sonradan aklıma bu sorunun yaşandığı sunucularda açık olan Server Manager'ları, bu sorun çıkartan düğümü henüz Cluster'dan çıkarmadan önce açmış olabileceğim geldi aklıma. Bu nedenle Server Manager bu sorun çıkartan düğümün hala etkin bir şekilde Cluster'da olduğunu düşünüyor diye düşündüm. Server Manager'ı kapatıp açtım ve tam isabet! Sahiden de öyleymiş. Böylece üçüncü sunucuyu da All Servers'dan şutladım ve sorunum çözüldü.
Ayrıca şunu da belirteyim. Tüm bunları yapmanıza rağmen hala System Event Log'una aynı hatanın geldiğini görürseniz anlayın ki sizin Windows oturumunuzdan başka birilerinin daha oturumu açık ve onlarda da Server Manager açık. Bunu kontrol etmek için Task Manager'ı kullanabilirsiniz. Eğer farklı bir kullanıcıda da açık olduğunu görürseniz, o oturumu tamamen kapatmak yerine doğrudan o kullanıcıya ait olan o Server Manager uygulamasını uzaktan Task Manager ile sonlandırabilirsiniz.
DCOM was unable to communicate with the computer "server_name.domain_name" using any of the configured protocols; requested by PID 5cac (C:\Windows\system32\ServerManager.exe).
Windows System Event Log'undaki Event Id'si: 10028.
AÇIKLAMA:
Bu hata ile AlwaysOn Availability Groups olan bir ortamdan 3 tane düğümü kaldırdıktan sonra karşılaşmaya başladık. Aklına "Toplamda kaç tane düğüm vardı da 3 taneyi kaldırdın?" sorusu gelenler için söyleyeyim, SQL Server 2012'nin izin verdiği tavan sayısındaydı düğüm sayısı.
Vel hasıl ben bu hatayı fark etmemiştim, sistem tarafından arkadaşlar haber verdi. Sorunu incelemeye tabii ki hata mesajıyla başladım. Hata mesajında en dikkat çekici şey, mesajın sonundaki "ServerManager.exe" idi. Demek ki sorun bir şekilde Server Manager aracıyla ilgiliydi. Server Manager'ı açınca "All Servers" bölümünde AlwaysOn ve Cluster'dan kaldırdığımız 3 düğümün adını gördüm. Her ne kadar AlwaysOn ve Cluster'dan bu düğümleri kaldırsam da, bunlar Server Manager'da kalıyor sanırım. Neden, niçin henüz bilemiyorum.
ÇÖZÜM:
Sorunu çözmek için basit bir şekilde Server Manager'daki All Servers bölümünden artık sistemde olmayan sunucuların üstüne giredek "Remove Server" seçeneğiyle bunların ikisini kaldırdım. Fakat üçüncüyü kaldırmama izin vermiyordu sistem. Aslında veriyordu, fakat seçili düğümü ve diğer tüm düğümleri Cluster'dan kaldırmak isteyip istemediğimi soruyordu. Yeterince korkutucu bir mesaj, değil mi? Tabii ki iptal ettim işlemi. Sonradan aklıma bu sorunun yaşandığı sunucularda açık olan Server Manager'ları, bu sorun çıkartan düğümü henüz Cluster'dan çıkarmadan önce açmış olabileceğim geldi aklıma. Bu nedenle Server Manager bu sorun çıkartan düğümün hala etkin bir şekilde Cluster'da olduğunu düşünüyor diye düşündüm. Server Manager'ı kapatıp açtım ve tam isabet! Sahiden de öyleymiş. Böylece üçüncü sunucuyu da All Servers'dan şutladım ve sorunum çözüldü.
Ayrıca şunu da belirteyim. Tüm bunları yapmanıza rağmen hala System Event Log'una aynı hatanın geldiğini görürseniz anlayın ki sizin Windows oturumunuzdan başka birilerinin daha oturumu açık ve onlarda da Server Manager açık. Bunu kontrol etmek için Task Manager'ı kullanabilirsiniz. Eğer farklı bir kullanıcıda da açık olduğunu görürseniz, o oturumu tamamen kapatmak yerine doğrudan o kullanıcıya ait olan o Server Manager uygulamasını uzaktan Task Manager ile sonlandırabilirsiniz.
Kaydol:
Kayıtlar (Atom)