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.

Güncelleme (2018:03.12): Bir SQL Server 2016 ortamında SQL Server Setup'ın SQL Server servislerini otomatik başlatmadığını, bu değişikliğin gerçekleşmesi için SQL Server Database Engine servisinin elle, sizin tarafınızdan yeniden başlatılması gerektiğini gördük.

Sevgiler,
Ekrem Önsoy

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