24 Nisan 2016 Pazar

Microsoft Kurumsal Çözümler Zirvesi Etkinliği hakkında (2016)

Selam arkadaşlar,

Geçen hafta Swissotel'de katıldığım Microsoft Kurumsal Çözümler Zirvesi etkinliğindekilere dair bir özet geçmek istedim sizlere. Aslında içerik zengin olmadığı için çok anlatacak bir şey yok, ama yine de ne oldu, ne bitti paylaşalım. Bu arada önümüzdeki Salı günü de Oracle Cloud Forum etkinliği var, ondan da ayrıca bahsederim. 

Microsoft Kurulsam Çözümler Zirvesi etkinliğinde Microsoft'un CRM, ERP çözümlerinin yeni versiyonlarının yanında SQL Server 2016'nın da lansmanı yapıldı. Belli ki bu seneki bütçe çok düşüktü. Çünkü örneğin SQL Server 2014'ün lansmanı yapıldığında düzenlenen etkinlikte sadece SQL Server 2014'den bahsedilmişti, yani ona özel bir lansman yapılmıştı. Fakat bu seferki etkinlikte SQL Server 2016'nın lansmanı neredeyse 15-20 dakikalık bir oturuma sıkıştırıldı. İşin daha komik tarafı, SQL Server 2016'nın lansmanının Cory Hrncirik adında ve Microsoft'un finans departmanından olan biri tarafından yapılıyor olmasıydı. Tabii ki teknik olarak yeni özelliklerden falan hiç bahsedilmeden, tamamen pazarlama konularından bahsedildi. SQL Server'ın Oracle'a Gartner grafiklerinde nasıl fark attığı, karşılaştırıldıklarında fiyat açısından 11 kat daha ucuz olduğu ve Microsoft'un ürününde her şey entegre çalışırken, Oracle'ın çözümünde her şeyin add-on şeklinde derme çatma olduğu gibi.

Microsoft bu etkinlikte daha ziyade CRM ürünlerine, bu ürünlerin bulut ortamındaki versiyonlarına ve PowerBI gibi ürünlere odaklanmıştı. Zaten sponsor olan ve standları olan firmaların çoğu da CRM projeleri yapan firmalardı.

Öğlen bildiğiniz tarzda yemek verilmedi, "lunchbox"lar içerisinde sandviçler dağıtıldı. Yani THY ile değil de KLM ile uçuyorsunuz gibi oldu. Öğlene kadar süren ana salondaki sunumlardan sonra "lunchbox" almaya gittiğimde kalmadığını gördüm. Çünkü ana salonda sunumları izleyenlerden çok, dışarıda sunumu izlemeyip "networking" yapan kişi vardı. Belli ki biz ana salondan çıkıp "lunchbox" almaya gidene kadar onlar hepsini silip süpürmüştü. Ben de öğlene kadar tek bir salonda süren oturumlardan sonra, diğer salonlarda paralel devam eden sunumlardan sadece birine katılabildim. Açlıktan başımın ağrıdığını hissetmeye başlar başlamaz "aç aç devam edemem" deyip etkinlikten ayrılmak zorunda kaldım.

Etkinliğe hesapsız bir şekilde çok fazla, alakalı alakasız herkes gelmişti. Bu nedenle yiyecek, içecek yetmedi, her yer çok kalabalıktı, sunumlar bir lansman için ne kadar yeterliydi tartışılır.

Umuyorum Oracle'ın etkinliğinde aç kalmayız.

Not: Sunumlarda Machine Learning (ML) ile sosyal medyanın nasıl takip edilebileceğinden, sosyal medyanın takip edilmemesi yüzünden United'ın kargo bölümünün Kanada'lı bir müzisyenin gitarını taşırken kırdığını ve müzisyenin bunu sosyal medya hesabından duyurduğunu, United'ın bundan çok geç haberinin olduğunu ve sonrasında United'ın çok müşteri kaybedip milyonlarca dolar zarar ettiğinin örneği verildi. Microsoft başkalarından örnek veriyor, fakat belli ki ML'i henüz kendi sosyal hesapları için kullanmaya başlamamış.

Sevgiler,
Ekrem Önsoy

24 Mart 2016 Perşembe

Enterprise Edition olmak ya da olmamak! Keşke tüm mesele bu olsa...

Selam arkadaşlar,

Bir süre önce ortamlardan birindeki bir sistemci arkadaş şöyle dedi: "X sunucusunda işlemci kaynağının yarısı kullanılıyor".

Dün de aynı ortamda bir sorun olunca ancak o zaman bakabildim işlemci kullanım sorununa. Sorunu incelerken ilk yaptığım şey ilgili SQL Server Instance'ındaki Affinity Mask ayarlarını kontrol etmekti. Orada her şey doğru görünüyordu.

Bu sunucuda bu noktada Hyperthreading etkin değildi. Sunuda toplam 40 Core vardı ve SQL Server da toplamda 40 tane Core görüyor olmalıydı. Windows Server 40 Core görüyordu, yani Windows Server tarafında sorun yoktu. Hal böyle olunca tamamen SQL Server'a odaklandım. sys.dm_exec_schedulers DMV'sinin ürettiği sonuçları inceledim, gerçekten de sadece 20 tane işlemcinin durumu "VISIBLE ONLINE", diğer 20 işlemcinin durumu ise "VISIBLE OFFLINE" idi. Eğer sys.dm_exec_scheduler ile yaptığınız kontrolde bir işlemcinin durumunu "VISIBLE OFFLINE" olarak görüyorsanız, o işlemciye bir iş atanamaz demektir. Daha fazla bilgi için BOL'ün ilgili sayfasını inceleyebilirsiniz.

Ardından Error Log'u inceledim ve aşağıdaki bilgiyi gördüm:
"SQL Server detected 4 sockets with 10 cores per socket and 10 logical processors per socket, 40 total logical processors; using 20 logical processors based on SQL Server licensing. This is an informational message; no user action is required."

Bu SQL Server'ın Edition'ı Enterprise Edition idi. Lisanslama ile ilgili ne gibi bir sorun olabilirdi ki? Evet, bu SQL Server Enterprise Edition'dı ve aşağıdaki komut:

SELECT SERVERPROPERTY('edition')

Aşağıdaki sonucu üretiyordu:

Enterprise Edition (64-bit)

Fakat yeni terminolojide bu ibare, SQL Server'ın 20 adet Core ile sınırlandığı anlamına geliyor. Eğer sınırsız Core lisanslaması istiyorsanız o zaman sorgunuzun sonucu aşağıdakini üretmeli:

Enterprise Edition: Core-based Licensing (64-bit)

Her ne kadar bu iki Edition da Enterprise Edition olsa, eğer Instance'ınız ilk sonucu üretiyorsa o zaman 20 adet Core ile sınırlandırılırsınız demektir. Eğer Hyperthreading etkinse, o zaman bu sayı 2'ye katlanarak 40 Core oluyor. SQL Server lisanslama açısından Hyperthreading'in etkin mi yoksa kapalı mı olduğunu kontrol ediyor. Bu senaryoda eğer Hyperthreading etkin olsaydı o zaman yukarıdaki mesaj şöyle olacaktı:

"SQL Server detected 4 sockets with 10 cores per socket and 20 logical processors per socket, 80 total logical processors; using 40 logical processors based on SQL Server licensing. This is an informational message; no user action is required."

Eğer Instance'ınızı "Enterprise Edition: Core-based Licensing (64-bit)"a Upgrade ederseniz, o zaman yukarıda Error Log'ta görmüş olduğunuz (Hyperthreading'in etkin olmadığı) mesaj aşağıdaki gibi değişir:
"SQL Server detected 4 sockets with 10 cores per socket and 10 logical processors per socket, 40 total logical processors; using 40 logical processors based on SQL Server licensing. This is an informational message; no user action is required."

Peki Instance'ınızı nasıl "Enterprise Edition (64-bit)"den "Enterprise Edition: Core-based Licensing (64-bit)"e Upgrade edeceksiniz? 

Bunun için SQL Server Installation Center'ı kullanabilirsiniz. Installation Center'ı açtıktan sonra ekranın solundaki Maintenance bölümündeki Edition Upgrade'e tıklayın ve devam edin. Core-based lisans anahtarınızı girdiğinizde Setup bunu otomatik olarak algılayacaktır. Yani Upgrade için farklı bir medyaya ihtiyacınız yok. Ayrıca SQL Server Setup medyasının sürücüye "mount" edilmiş olmasına da ihtiyaç yok.

Dikkat edin, bu işlem kesinti gerektiriyor. İşlem boyunca SQL Server servisleri kapatılıp açılıyor. İşlem çok kısa, 1-2 dakika sürüyor.

Eğer AlwaysOn AG kullanıyorsanız işlem sırasında aşağıdaki gibi bir uyarı görebilirsiniz:


Gözünüzü korkutmasın, bu sadece bir uyarı ve AlwaysOn AG'ye herhangi olumsuz bir etkisi olduğunu gözlemlemedim. Bununla birlikte beklenmedik bir kesintiye neden olmamak için işlemi önce Secondary Replica(lar)'da yaptığınızdan emin olun, sonra Failover yapıp önceki-Primary Replica'da da uygulayabilirsiniz.

Güncelleme (2016.03.24): Bu yazıya mevzu bahis olan SQL Server versiyonu 2012'dir.

Sevgiler,
Ekrem Önsoy

9 Mart 2016 Çarşamba

How to remove a replica from an AlwaysOn AG routing list?

Hello people,

There are a lot of blog posts about creating readonly routing lists for AlwaysOn AGs out there and some about modifying them, but I failed to spot a blog post about removing a specific replica from a routing list. So this is the reason of this post.

I have a client who has started using AlwaysOn AGs for some time ago. They had their 2 node traditional Failover Clustered Instances before their current AlwaysOn AG replicas. We performed the upgrade side by side. We used two servers temporarily to perform this task. After the upgrade, we set up the old servers from scratch and have configured them as other AlwaysOn replicas. Now there are 5 replicas in this SQL Server 2012 environment. Temporary replicas will be removed soon. But before that, I wanted to see if I can remove the temporary replicas from the readonly routing lists or not?

Here's the result of the routing list (sorry, most of it is blurred):


And there's the query itself:
SELECT ag.name as "Availability Group", ar.replica_server_name as "When Primary Replica Is",
        rl.routing_priority as "Routing Priority", ar2.replica_server_name as "RO Routed To",
        ar.secondary_role_allow_connections_desc, ar2.read_only_routing_url
FROM sys.availability_read_only_routing_lists rl
        inner join sys.availability_replicas ar on rl.replica_id = ar.replica_id
        inner join sys.availability_replicas ar2 on rl.read_only_replica_id = ar2.replica_id
        inner join sys.availability_groups ag on ar.group_id = ag.group_id
ORDER BY ag.name, ar.replica_server_name, rl.routing_priority

As I said, I wanted to remove a specific replica from this list, but frankly I had not done it before, because I did not need to do so, then I asked Google to find a working method. But it came up with nothing. Maybe it's my bad, but this led me to go to Books Online and I started digging about "ALTER AVAILABILITY GROUP" command. Then I saw the following section:

READ_ONLY_ROUTING_LIST = { (  [ ,...n ] ) | NONE }



NONE
Specifies that when this availability replica is the primary replica, read-only routing will not be supported. This is the default behavior. When used with MODIFY REPLICA ON, this value disables an existing list, if any.
Then I tested the following code block and that did the trick.

ALTER AVAILABILITY GROUP  
MODIFY REPLICA ON
N'' WITH 
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST= NONE));

That specific replica is not on my routing list anymore and it's still part of the AG, everything's working fine.

I know this is not that deep and may look easy peasy, but I wanted to blog about it anyway, so that it may make someone's life easier some day.

Cheers,
Ekrem Önsoy

1 Şubat 2016 Pazartesi

HATA: The computer 'xxx' is joined to a cluster

Selam millet!

Geçen gün bir ortamda bir Cluster'a yeni bir düğüm ekleme işimiz vardı. Bu işlem sırasında aşağıdaki ekran görüntüsünde de göreceğiniz hata ile karşılaştım.


Bu sunucu yeni kurulan bir sunucu değildi, bununla birlikte benim ortama girmemden önce kurulmuş bir sunucuydu. İlgili arkadaşlara sorduğumda bu sunucunun önceden herhangi bir Cluster'a katılmadığını söylediler. Ayrıca Windows Server Failover Cluster servisleri de kurulu değildi, ben kendim kurmuştum. Bu nedenlerle ben de bu hata ile karşılaştığıma şaşırdım.

Bu hatayı aşağıdaki ekran görüntüsünden göreceğiniz Powershell komutlarını kullanarak atlatabildim.

Tim Radney'in çözümünden alıntıdır.
Önemli not: Yukarıdaki komutu sorun yaşadığım düğümde çalıştırdım.

Sevgiler,
Ekrem Önsoy

28 Ocak 2016 Perşembe

Database Mirroring'ten Log Shipping'e geçiş senaryosu

Selamlar,

Çalıştığımız bir şirkette ilginç bir gereklilik hasıl oldu, sizlere de bahsedeyim.

Ortam büyük ve dinamik. En kritik veritabanları 6TB'a yakın bir boyutta. İş ve haliyle veritabanı beklenmedik şekilde büyümüş. Müşteri sayısı, gelen iş ve iş yoğunluğu çok kısa zamanda, çok fazla artmış. Böyle olunca bazı noktalarda hazırlıksız yakalanılmış. Yeni Storage alımında geç kalınmış.

Gelinen noktada elde bir üretim SQL Server sunucusu, bir de ikincil bir SQL Server sunucusu var; üretim sunucusundan ikincil sunucuya Database Mirroring yapılıyor. Yani birincil sunucuda (üretim sunucusu) gerçekleşen tüm işlemler gerçek zamanlıya yakın olarak ikincil sunucuya aktarılıyor. Fakat varolan kullanılabilecek Storage alanı o kadar az ki, örneğin birincil sunucuda bir tablo silinse ve geri getirilmek istense bu yapılamaz; çünkü elde yedek olduğu halde bunu Restore edebilecek müsait disk alanı yok.

Böyle bir senaryo için, en azından kişilerin, misal yazılımcıların (her yazımda size sataşmazsam olmuyor) yapabileceği olası bir hatalı silme veya güncelleme senaryosunda ilgili kayıtların eski versiyonlarına ulaşabilmeleri için bu arkadaşlara gecikmeli olarak işletilen bir Log Shipping uygulamasını tavsiye ettim. Database Mirroring'in ve Log Shipping'in nasıl çalıştığını ayrıntısıyla anlattım. Yeni Storage siparişi verildi; fakat en azından Storage gelip kullanılabilir oluncaya kadar ve hatta sonrasında da böyle sıkıntılar yaşanırsa hızlı aksiyon alınabilmesi ve zarar gören verinin ılık yedeklerden geri getirilebilmesi için Log Shipping işlerini görecektir.

Geçenlerde bu geçişi yaptık, hem de o en büyük veritabanını tekrar Restore etmeye gerek kalmadan. Çünkü anlayacağınız üzere zaten bu veritabanı Database Mirroring sayesinde ikincil sunucuda Restoring durumdaydı. Varolan Transaction Log yedekleme işlemlerini sonlandırıp yeni Log Shipping yapılandırmasını uyguladıktan sonra beklendiği gibi tıkır tıkır çalıştı. Tabii ki öncesinde gerekti tüm testleri yaptım. Her ne kadar yeni Storage'tan gelecek diskler devreye girene kadar Restore yapamayacak olsalar da, gecikmeli çalışan Log Shipping'ler sayesinde şimdi kendilerini daha güvende hissediyorlar.

Umarım tüm IT direktörleri ve / veya sistemci arkadaşlarım gerekli kapasite planlama işlerini aksatmadan yapar ve tabii ki yönetimden bütçe kopartabilir ve bu öyle sıkıntılar yaşamaz, gerçekten zor bir durum.

Sevgiler,
Ekrem Önsoy