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

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

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

Gereği kadar yetki vermek...

Merhabalar,

Bugün, çalıştığım bir firmaya hizmet veren başka bir firmadaki bir arkadaştan şöyle bir e-posta aldım:

"Ekrem Bey Merhaba,
SQL bağlantısı için izin istiyoruz. Bir de dün açılan X_user yetkisi yeterli olmadı sanırım. X veritabanı için mi sysadmin hakkıyla bağlantı izni rica ediyoruz."

Kendi içimde verdiğim ilk ilkel tepkiyi pas geçiyorum, medeni tepkimin yansıması aşağıdaki gibi oldu:

"Merhabalar,

…

"sysadmin" yetkisi yapacağınız işin boyutunu çok aşan bir yetki ve bu yetkiyi size tabii ki veremeyiz. Dün arkadaşınıza verdiğim yetkiyi verdim yine X_user'a, işlemlerinizi kendi kullanıcınız olan bu kullanıcıyla yapabilirsiniz. Eğer bir yetki sorunuyla karşılaşırsanız bana danışın lütfen."

Ardından yine aynı firmada çalışan, ama başka bir arkadaştan şöyle bir e-posta geldi:

"Ekrem Bey,
Büyük bir ihtimalle dün X beye verdiğiniz yetki ile işlemleri yapamadığı için sorun oldu. Aşağıda sizin sunucuya bağlanıp tablonun dizaynını açtığımdaki görüntü ve hata mesajı var (Görüldüğü gibi kolonlar yok)."

Yukarıdaki e-postayı gönderen arkadaş aşağıdaki ekran görüntüsünü eklemiş:

Designer

Cevabım şöyle oldu:

"Designer için db_owner yetkisi gerekli, sizde bu yetki yok, ama yeni alan eklemeniz için gerekli yetkiler var. Bu işlemler Designer kullanarak yapılmamalı, çok tehlikeli. Misal Designer, yerli yersiz bazı işlemler için tüm tabloyu silip sıfırdan oluşturma yöntemini uyguluyor.

Bunun yerine yapacağınız işlemleri kod ile yapmalısınız.

ALTER TABLE ... ADD ... gibi"

5 dakika sonrasında aynı arkadaşlardan gelen e-posta şöyle:

"Tamamdır Ben düzeltmeleri yapabildim Ekrem Bey. işim bitti. Bilginize."

Diyeceğim o ki arkadaşlar, sevgili yazılımcı arkadaşlarımız veritabanı yöneticilerini hep az yetki vermekle suçlar, yokuş yapmakla suçlar (yıllar oldu, beni Denizbank'ta hala "Yokuş Ekrem" diye ananlar varmış, geliyor kulağıma ha!); ama çoğu zaman aslında verilen yetkiler yeterlidir. Sırf birileri yetki istiyor diye hemen vermeyin onlara istedikleri yetkiyi. Talebi sorgulayın, her şeyi sorgulayın (biraz felsefe).

Fazla yetki sahibi olmak, büyük sorumluluk, çoğu zaman yazılımcılar ilk etapta bunun yükünü anlayamıyorlar. Ancak ne zaman bir veritabanını, tabloyu vs siliyorlar veya yanlış işler yapıyorlar, o zaman anlıyorlar fazla yetkinin sıkıntısını. Günlük kullanımlık aracınızın 1000 beygirlik olması gibidir "sysadmin" yetkisiyle üretim ortamında çalışmak. Bunun tehlikelerini lütfen yeri geldiğinde yazılımcılarınıza anlatın.


Ekrem Önsoy