Hata: Version store is full. New version(s) could not be added. A transaction that needs to access the version store may be rolled back. Please refer to BOL on how to configure tempdb for versioning.

HATA:
Version store is full. New version(s) could not be added. A transaction that needs to access the version store may be rolled back. Please refer to BOL on how to configure tempdb for versioning.

AÇIKLAMA:
Always On Availability Group kullandığınızda eğer Secondary Replica'larınız Readable ise o zaman bu hata ile karşılaşabilirsiniz.

Bunun yanısıra Read Committed Snapshot Isolation Level kullandığınız ve Always On Availability Group olmayan senaryolarda da bu hata ile karşılaşabilirsiniz. Çünkü bu hata temel olarak hata mesajında da iletildiği gibi Version Store ile ilgilidir.

ÇÖZÜM:
Eğer bu hata ile karşılaşıyorsanız ya iş yükünüz için tempdb'ye fazla küçük bir disk kapasitesi ayırmışsınız demektir ya da tempdb'de herhangi bir nedenle kullanılabilecek alan kalmamıştır ve/veya tempdb'nin bulunduğu disk kapasitesi dolmuştur.

tempdb veritabanı dosyalarınızın bulunduğu disk kapasitesini kontrol etmenizi, tempdb kapasite doluluğu ile ilgili sorunu çözmenizi tavsiye ederim. Ondan sonra büyük olasılıkla bu hata mesajından da kurtulacaksınız.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

SQLBits'ten notlar

SQLBits uzun yıllardır İngiltere'de gerçekleştirilen bir SQL Server etkinliğidir, Microsoft ve uluslararası topluluk bu etkinliğe oldukça ilgi gösterir. Bu etkinliğin sonuncusu 27 Şubat - 2 Mart 2019 tarihleri arasında gerçekleştirildi. Bu yazımda etkinlik boyunca sergilenen oturumlarda benim dikkatimi çeken konular hakkındaki notlarımdan bazılarını sizlerle de paylaşacağım.

Not: Bu etkinliğe fiziksel olarak gitmediğimi, oturumları uzaktan izlediğimi belirteyim. Yani bunu siz de yapabilirsiniz. Oturumların kayıtlarına buraya tıklayarak ulaşabilirsiniz.

Not: Etkinlik sırasında SQL Server 2019'un CTP 2.3'ü yayınlandı.

1- Sunuculuğunu Buck Woody'nin üstlendiği açılış konuşmasında Bob Ward'tan SQL Server 2019 ile birlikte artık sistem veritabanlarının da Always On Availability Groups'a katılabileceğini öğrendim. Bu sayede Instance seviyesindeki Login, Job ve benzeri nesneler de ikincil sunuculara otomatik olarak aktarılabilecek. Bunu Script'lerle yapmak gerçekten pek eğlenceli değildi, nihayet bu özelliğin geliyor olduğunu bilmek güzel. CTP 2.3'te yok, ama gelecek CTP'lerde görecekmişiz.

2- SQL Server 2019 ile birlikte 

"String or binary data would be truncated." * 

hata mesajının çok daha anlamlı bir hale getirileceğini zaten duymuştuk; ama tam olarak nasıl olacağını ben bilmiyordum. 

* Bilmeyenler için, bu hata mesajı örneğin 20 karakter uzunluğundaki bir metin alanına 21 karakterlik veri yazmak istediğinizde oluşur. Eğer bu işlemi yaptığınız kod bloğu içerisinde, ki SP veya toplu bir komut olabilir, tam olarak hangi kod satırındaki hangi tabloda hangi alanda işlem yaparken bu hatanın oluştuğunu bilemezsiniz ve bu sıkıcı bir "debug" çalışmasıdır.

Bu hata mesajının yeni biçimi şöyle oluyor 

"String or binary data would be truncated in table 'tablo adı', column 'sütun adı'. Truncated value: 'değer'." 

Nihayet! Hatta bunun için SQL Server 2017 ve 2016'ya kadar geriye dönük güncelleme çıkacaklarmış. Bu konuda Microsoft'un bir blog yazısını da buldum, okumak isteyenler buyursun.

3- Tempdb'de de güzel bir değişiklik var. SQL Server 2019 ile birlikte artık bu sistem veritabanındaki tüm sistem tabloları in-memory OLTP "Schema_Only" olarak oluşturulacak. Böylece sistem tablolarında Latch Contention sorunu oluşmayacak. Sonuçta tempdb yeniden başladığında boş olarak başlıyor, yani verinin kalıcı olmasına (durability) ne gerek var? Şu anki CTP 2.3'te yok bu özellik, ama gelecek CTP'lerde görecekmişiz.

4- Yine SQL Server 2019'da Accelerated Database Recovery (ADR) adında yeni bir özellik geliyor. SQL Server ile özellikle yoğun ortamlarda çalışanların ve yöneticilerin illa tecrübe ettiği bir hadisedir, çok uzun bir veri değişikliği sorgusu çalışır, bunun sahayı felç ettiği biraz geç anlaşılır, sonra yukarıdan büyük baskı gelir ve sorunlu sorgu tespit edilir ve durdurulmaya çalışılır; fakat sorgu durur mu? Durmaz. Çünkü Rollback süreci başlamıştır. Duruma göre bu oldukça uzun bir süre devam edebilir ve bu süreçte Blocking'ler, ciddi yavaşlıklar gibi sıkıntılar yaşanabilir. Hatta bazıları umutsuzca SQL Server Database Engine servisini yeniden çalıştırmayı dener, tabii ki bu beyhude bir girişimdir, çünkü Recovery süreci tamamlanmadan eski mutlu günlere dönemezler. İşte SQL Server 2019 ile birlikte gelecek olan ADR tüm bu sorunları çözüyor. Tabii ki her şeyin bir bedeli var, ADR'ın da. Bunun için bir çeşit "row versioning" yöntemi kullanılmış, ama SQL Server 2005 ile birlikte gelen gibi değil, çünkü ADR'ın Database Engine servisi yeniden başlatıldığında da işe yaraması gerekiyor; ama malum servis yeniden başladığında tempdb sıfırlanıyor, bu nedenle işe yaramaz. İşte bu yüzden ADR için "row versioning" işlemi ADR'ın etkinleştirildiği veritabanının içinde gerçekleştiriliyor, tempdb'de değil. Geçen gün Brent Ozar bunun demosunu yayınlamıştı, merak edenler buyursun.

5- Profesör Mark Whitehorn'un "Graph databases - What, how and why" isimli sunumunu çok keyifli bulduğumu belirtmek isterim. Konuyu SQL Server özelinde değil, genel olarak "Graph Database" modeli çerçevesinde anlatıyor; fakat sonuç itibariyle Node'lar, Edge'ler ve bunların birbiriyle ilişkisi. O yüzden birebir alakalı.

6- Microsoft'ta Program Manager olarak çalışan Pedro Lopez sunumunda ISV'lere uygulamalarınızı SQL Server versiyonuna, bulut veya on-prem olmasına göre değil, SQL Server Compatibility Level'a göre sertifikalandırın diyor. SQL Server versiyonunu yükselttiğinizde uygulamanın performansının daha kötü olabileceğinden çekinerek versiyon yükseltmemeyi düşünmeyin, misal bir uygulama veritabanı sunucusunu SQL Server 2012'den SQL Server 2016'ya yükselttiğinizde eğer veritabanının Compatibility Level'ını SQL Server 2012 seviyesine getirirseniz veritabanınızdaki kodlar yine SQL Server 2012'deki performansla çalışacaktır diyor (mealen). Çünkü yeni versiyonlarda Query Processor'da yapılan performans ile ilgili geliştirmeler ancak Compatibility Level'ın değiştirmesiyle devreye giriyor. Pedro Lopez Microsoft'un ISV'lerin sertifikalandırma konusundaki bakış açısını değiştirmek için çalışmalara devam ettiğini, hatta Sharepoint'in gelecek versiyonunun da bu şekilde sertifikalandırılacağını söylüyor.

Bununla birlikte "discontinued feature" olarak adlandırılan özelliklerin Compatibility Level'dan bağımsız olarak yeni versiyonlarda çalışmayacağını vurgulamakta fayda var. Örneğin SQL Server 2012'de Discontinued Feature olarak belirlenen bir özellik, veritabanını bir SQL Server 2019 Instance'ına taşıdıktan sonra Compability Level'ı 110 da yapsanız çalışmayacaktır. Bu nedenle versiyon yükseltme çalışmasının ön analizini dikkatlice yapmalısınız.

"Deprecated" özellikler ise Compability Level Protection kapsamında yeni versiyonlarda da desteklenmeye devam ediyor, yani SQL Server 2012'de "Deprecated Feature" listesine giren bir özellik, veritabanı sunucunuzu SQL Server 2019'a yükseltseniz bile Compability Level'ını 110 olarak ayarladığınızda çalışmaya devam ediyor.

7- SQL Server on Linux ilk duyurulduğunda hemen bir VM oluşturmuş, üstüne Ubuntu kurmuş ve SQL Server 2017'yi de onun üstüne kurup Host'taki SQL Server Management Studio'dan Ubuntu kurulu VM'deki SQL Server 2017'ye bağlanmış ve bunun da yazısını yazmıştım. Fakat Container nedir, SQL Server ile neden ve nasıl kullanılır açıkçası pek bilgim yoktu. Bob Ward'un "Inside SQL Server Containers" isimli oturumunu izlediğimde ise oldukça güzel bir resim oturdu kafamda. Bir veya daha fazla imajdan bir veya daha fazla Container'ın nasıl çalıştırılabileceğini, nasıl saniyeler içerisinde SQL Server'ın güncellenebileceğini veya daha üst bir versiyona yükseltilebileceğini, neden farklı imajlar oluşturmak isteyebileceğimi, Container kapandığında veritabanlarımı kaybetmemek için neler yapabileceğimi ve ne gibi senaryolarda SQL Server'ı bir Container'da (misal Docker) çalıştırmak isteyeceğimi öğrendim. Eğer bu konuda merakınız varsa, bu oturumu kaçırmamanızı özellikle tavsiye ederim.

Not: Bu oturumun seviyesi 400'dür. Yani ileri seviye.

Önemli hatırlatma:
SQL Server 2008 ve SQL Server 2008 R2 versiyonları için Microsoft Extended Support Temmuz 2019'da bitiyor, yani 4 ay kaldı. SQL Server veritabanı sunucularınızın SQL Server'ın yeni versiyonlarına Microsoft'un önerilerine %100 uyumlu olarak, ama saha tecrübesini de göz ardı etmeden yükseltilmesi, bu yükseltme çalışmasının en verimli, risksiz, hızlı ve profesyonel şekilde yapılması konusunda desteğe ihtiyacınız varsa lütfen tıklayın. Şirketinizin ihtiyaçlarına en uygun SQL Server Edition'ını birlikte belirleyelim, en düşük lisans maliyetiyle, en kısa kesinti süresiyle ve hiç veri kaybetmeden SQL Server sunucularınızın versiyonunu yükseltelim.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

"Always On" olacak diye umulan Availability Groups

Geçen hafta çok ilginç bir Always On Availability Groups (AG) sorunu ile karşılaştım, bunu yazmazsam olmazdı.

Önce ortam hakkında özet bilgi vereyim. Bu ortamda SQL Server 2014 + Service Pack 2 kurulu ve 2 Replica'dan oluşan bir Always On AG yapısı var; geçen senenin sonlarına doğru kurmuştuk. Müşteri, 2. Replica'yı sürekli kullanılabilirlik için değil, sadece raporlama için istemişti, bu nedenle Always On AG temel amacından birazcık saparak sürekli kullanılabilirlik için kullanılmıyor.

Sorun yaşandığı anda ben de başka bir şeyle meşguldüm, kesintiye dair telefon geldi ve ilk müdahaleyi telefonda yaptık. Fakat temel şeyler sonuç vermeyince kısa bir süre sonra sisteme ben bağlandım ve kontrollere başladım.

Canlı sunucuya bağlandığımda SQL Server Database Engine servisi çalışıyordu, fakat Always On AG Resource Group Offline durumdaydı. Cluster Resource'u bir türlü Online duruma gelmiyordu ve çok ilginç bir şekilde SQL Server Error Log'ta, Windows System Event Log'larında ve Cluster Log'larında aradığım ayrıntıları bulamadım. Bir taraftan da kesinti devam ediyordu, tüm Login'ler veritabanlarına erişemediğine dair hata alıyordu. En temel genel Microsoft sorun çözücü yöntem olarak sunucuyu yeniden başlattım. Çok ilginç bir şekilde sorunu bu hamle de çözmemişti (tabii ki takılıyorum)...

SQL Server Database Engine'e bağlanıp veritabanlarını kontrol edeyim dedim...

ve yukarıdaki ekranla karşılaşınca açıkçası çok şaşırdım, çünkü yazımın girişinde belirttiğim gibi bu ortamda Always On AG vardı ve bu da tek Primary Replica olabilecek makineydi, nasıl veritabanları "Restoring" durumda olabilirdi ki? Secondary Replica'daki veritabanları da "Not synchronizing" durumdaydı.

Henüz bunun şaşkınlığını atlatamadan bir de ne göreyim:

Yukarıdaki ekran görüntüsü Primary Replica'ya ait. Always On AG yapılandırmam yok olmuş!

Bunun nasıl olabileceği konusunda en ufak bir fikrim yok. Yani ne, nasıl tetiklenir de Always On AG yapısını bu şekilde siler hiç bilemedim. Secondary Replica'yı kontrol etmek geldi aklıma, bağlandım baktım, orada duruyor yapılandırma. Bulguları birleştirince Always On AG Cluster Resource'unun da neden bir türlü Online olmadığı anlaşıldı.

Sahadaki servis kesintisi sorununu gidermek için "RESTORE DATABASE" komutuyla hemen veritabanlarını Online duruma getirdim* ve servislerin ayağa kalktığını teyit ettim. Artık sahada kesinti yoktu. Bundan sonraki aşama Always On AG'yi ayağa kaldırmaktı. 

* Dikkatinizi çekerim veritabanları Restoring durumdaydı, öyle veya böyle bu duruma gelmişti, veritabanlarına ulaşmaya çalışan Login'ler de bu nedenle hata alıyordu ve Database Engine servisinin açılışında da herhangi bir sorun yoktu, bu nedenle basit bir RESTORE DATABASE ile veritabanlarını açabilir ve sahadaki kesintiyi engelleyebilirdim, temel öncelik her zaman kesintiyi güvenli bir şekilde sona erdirmektir.

Primary Replica'daki Database Engine servisinin Always On AG için Enabled durumunda olup olmadığını teyit ederek başladım işe. Daha sonra veritabanları açıldıktan sonra Primary Replica'da herhangi bir Transaction Log dosyası yedeği alınmış mı diye kontrol ettim. Eğer alınan bir yedek varsa bu yedekler Secondary Replica ile senkronizasyonun sağlanabilmesi için Secondary Replica'daki veritabanlarına da uygulanmalıydı. Komple yeniden kuruluma gerek yoktu, çünkü Secondary Replica'daki veritabanları duruyordu, sadece iki Replica'daki veritabanları arasında herhangi bir Log Sequence Number (LSN) boşluğu olmadığından emin olmak yeterliydi, eğer boşluk varsa da bu eksikler Transaction Log yedekleri Secondary Replica'da Restore edilerek giderilebilirdi.

İki Replica'daki veritabanlarının arasında LSN boşluğu olmadığından da emin olduktan sonra Always On AG'yi ilgili veritabanlarıyla tekrar oluşturdum ve tüm eksiklikler giderilmiş oldu. Artık sistem kesinti olmadan önceki gibi çalışıyordu.

Tabii bu noktadan sonra sorunun nedenini araştırmak gerekiyordu. Ne olmuştu da kesinti oluşmuştu?

Always On AG, diğer birçok Microsoft teknolojisi gibi kurulumu nispeten kolaydır, bu nedenle birçok şirkette şık arayüzler kullanılarak "ileri, ileri" denilerek kurulur; fakat birçok senaryoda ya doğru tasarlanmaz, ya doğru yönetilmez, ya da sistem işlerliği doğru takip edilmez. Bazen de bizim senaryomuzda olduğu gibi ne yaparsanız yapın, birileri bir şekilde bir şeyleri bozabilir. Bizim senaryomuzda birisi bir sorgu çalıştırmış ve sunucu bu aşırı garip sorgu nedeniyle birkaç dakika cevap veremez duruma gelmiş. Bu nedenle Cluster, SQL Server'dan cevap alamamış ve "lease" yenilenememiş ve Cluster tarafından bu sunucu sağlıksız sayılıp servis kapatılmış. (Ödev: Böyle senaryolar için de bu garip sorguları çalıştırabilecek Login'ler tespit edilip Resource Governor'ın kullanımı düşünülmelidir, bu sayede bu potansiyel tehlikeli kullanıcıların işlemci kaynağını azami kullanım miktarı sınırlanabilir, bu aşamada müşteri ile bunu görüşüyoruz.)

Yeri gelmişken tekrar vurgulamak istedim. Always On AG, Log Shipping, Replication, Database Mirroring veya Failover Clustered Instance'larınızı sadece kurup kendi hallerine bırakmayın. Yakından izleyin. Aktarımlar geride kaldığında, yapının parçalarından birinde kesinti olduğunda, uygulamalar Virtual Network Name / Listener gibi sunucu agnostik elemanlar yerine doğrudan üye sunuculara bağlandığında haberiniz olsun istersiniz. Daha sürdürülebilir, daha sağlıklı ve daha kesintisiz ortamlar için bunlar sadece en temel kontrollerden birkaçıdır.

Yazıyı yazarken eşim de o anda bir fotoğraf çekmiş, bu yazıyı sevgili Tuncel Kurtiz'in Zeytinbağı'ndayken yazmıştım, nur içinde yatsın.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

Hata: Servis hesabının Always On Availability Groups kurulumuna etkisi

Geçen gün bir müşterimde Always On Availability Groups kurulumu yaparken önceden karşılaşmadığım bir sorun ile karşılaştım. Müsait olunca konu hakkında bir blog yazısı yazarım diye o anda ekran görüntüsünü almıştım. Soruna dair ilgili ekran görüntüsünü aşağıda paylaşıyorum.

Kurulum yaparken karşılaştığım sorun

Bilgi mesajı şöyle diyordu:

"The Endpoints tab lists at least one endpoint that uses only Windows Authentication. However, the server instance might be running under a nondomain account. To use the listed endpoint, change the corresponding SQL Server service account to a domain account. To continue using the nondomain account, after the endpoint to use a certificate."

SQL Server bir nedenden dolayı Replica'lardan birinin Domain hesabıyla çalışmadığını düşünüyordu. Fakat "SQL Server Service Account" sütununda da görülebileceği üzere iki hesap da Domain hesabı. Kuruluma bu şekilde devam ettiğimde kurulum bir türlü tamamlanmıyordu. Bir hata da vermiyordu veya verinceye kadar bekleyememiştim, ama bir yerlerde sıkıntı olduğu artık çok netti.

Kurulumu sadece arayüzle değil, T-SQL ile denediğimde de aynı sonuç ile karşılaşıyordum. Yukarıdaki bilgi mesajı gelmiyordu, ama kurulum da tamamlanmıyordu.

Endpoint'leri de kontrol etmiştim, herhangi bir anormallik yoktu.

Yukarıdaki ekran görüntüsündeki gibi farklılıkları oldum olası hiç sevmem. Yani örneğin Replica'lardan birinin servis hesabı "servis_hesap_adi@domain_adi" biçimindeyken diğerininkinin "domain_adi\servis_hesap_adi" olması benim için rahatsız edici bir durum. O anda tabii ki sorunun nedeninin bu olduğundan %100 emin olmasam da, %90'lık çok güçlü bir tahminle sorunun bu olacağını düşünmüştüm. 

Sonra test etmek için bir SQL Server kurulu sunucuda SQL Server Configuration Manager kullanarak 2. Replikanın servis hesabınının biçimini de canlı sunucudaki gibi "servis_hesap_adi@domain_adi" olarak değiştirmek istedim ve bunun yapılamadığını gördüm. Yani istesem de SQL Server Configuration Manager ile bir servis hesabını bu yazım biçimiyle atayamıyordum. O anda anladım ki birisi bu hesap değişikliğini SQL Server Configuration Manager yerine Services.msc ile yapmıştı, ki bu hiç iyi bir pratik değildir. Tüm SQL Server servis hesabı değişikliği işlemlerini SQL Server Configuration Manager aracıyla yapmalısınız. Çünkü bu sırada sadece servis hesabı değiştirilmez, aynı zamanda bu hesaba arkaplanda gerekli bazı yetkiler ve rol üyelikleri uygulanır. Eğer bu işi Services.msc ile yaparsanız sadece servis hesabı değişmiş olur. Ayrıca bu örnekte de görülebileceği üzere SQL Server servis hesabı değişikliğini "domain_adi\servis_hesap_adi" yerine "servis_hesap_adi@domain_adi" biçimiyle yapmış olabilirsiniz, ki bu örnekten de görülebileceği gibi bu biçimi kullanmak ilginç sorunlara neden olabiliyor.

Not: Bu noktada bir belirsizliğe dikkat çekmek istiyorum. Bu yazıya konu olan sorun SQL Server servis hesabının SQL Server Configuration Manager yerine Services.msc'den değiştirilmesinden de kaynaklanıyor olabilir, servis hesabının "domain_adi\servis_hesap_adi" biçimi yerine "servis_hesap_adi@domain_adi" biçimiyle belirlenmiş olmasından da kaynaklanıyor olabilir. Örneğin SQL Server servis hesabını Services.msc'den değiştirip, bu işlemi yaparken de "domain_adi\servis_hesap_adi" biçimini kullansaydım da sorun çözülebilirdi belki? Bu, ayrı bir test gerektiriyor. Ortam canlı olduğu için o anda bunun testini yapamadım. Eğer başka bir ortamda bunu test edebilirsem bu yazıyı güncelleyeceğim.

Servis hesabı değişimi (normal şartlar altında) kısa da olsa kesinti gerektiren bir değişiklik. İlgili yöneticilerle planlı bir kesinti için anlaştık ve zamanı geldiğinde canlı sunucudaki SQL Server Database Engine servis hesabını SQL Server Configuration Manager kullanarak ve "domain_adi\servis_hesap_adi" biçiminde değiştirdim. Bu değişiklikten sonra Always On Availability Groups kurulumunu tekrar denedim ve yukarıda paylaştığım ekran görüntüsündeki hata ile karşılaşmadım.

Yukarıdaki bilgi mesajıyla karşılaşmadığım gibi kuruluma devam ettikten sonra da kurulumun başarıyla tamamlandığını gördüm. Yani bu değişiklikle sorunum çözüldü. Olur da bir gün başka bir arkadaşım karşılaşırsa diye paylaşmak istedim.

Ekrem Önsoy

Microsoft SQL Server Danışmanı

www.ekremonsoy.com