Ocak ayında oluşturduğum Microsoft SQL Server hata kayıtları

Sizlerle Ocak ayında oluşturduğum SQL Server'a ait hata (bug) kayıtlarını paylaşmak istiyorum. Ocak ayı hata kayıtları açısından biraz yoğun geçti.

Hata 1:
Aşağıdaki hata kaydı, SQL Server Management Studio'nun yeni versiyonlarında Task List'in hatalı oluşuyla ilgili. Hatalı derken kastettiğim şu, mesela yeni görev oluşturma düğmesi ve görevin türünün belirlendiği aşağı açılır kutu Task List penceresinde görünmüyor.

https://connect.microsoft.com/SQLServer/feedback/details/3118202/task-list-seems-incomplete


Hata 2:
Aşağıdaki diğer hata kaydı da veritabanınızı yerel sunucunuzda oluşturup, dosyalarını Microsoft Azure Blob Storage'da sakladığınızda oluşuyor. Hata, veritabanınız için oluşturduğunuz Database Snapshot'tan dönüş yapmaya çalıştığınızda oluşuyor. Aynı senaryo, veritabanı dosyaları yerel sunucuda konumlandığında oluşmuyor. İpucu: Database Snapshot'tan nasıl geri dönüş yapılacağı da ayrı bir blog konusu.

https://connect.microsoft.com/SQLServer/feedback/details/3117785/reverting-from-a-database-snapshot-when-database-files-on-azure-blob-storage


Hata 3:
Bu hata da Transparent Data Encryption özelliği etkinleştirildiğinde ve kapatıldığında SQL Server 2014 SP2 ve SQL Server 2016 SP1'deki sys.databases ve sys.dm_database_encryption_keys catalog view'lerinin farklı sonuçlar döndürmesiyle ilgili.

https://connect.microsoft.com/SQLServer/feedback/details/3118734/tempdb-looks-encrypted-but-it-shouldnt-have-been

Güncelleme 01.02.2017: Ben 13 Ocak tarihinde bu konuda yukarıdaki hata kaydını açtıktan sonra Microsoft'tan Bob Ward yine bu konuda 27 Ocak tarihinde bu konuyu incelemiş. Merak edenler yazıya buradan ulaşabilir.

Eğer açtığım hata kayıtlarına oy vermek isterseniz, bir Microsoft hesabı açmanız yeterli.


Ekrem Önsoy

SSMS yenileniyor! Artık daha yeni, daha dinamik, daha güncel!

Merhabalar,

Enterprise Manager'dan sonra SQL Server 2005 ile birlikte hayatımıza giren SQL Server Management Studio (SSMS) artık daha güncel ve dinamik olacak. Nasıl mı?

Şöyle efendim, şimdiye kadar SSMS'in yeni versiyonları hep SQL Server Database Engine'in yeni versiyonlarıyla birlikte, yani son versiyonlara göre bakarsak, iki senede bir çıkardı piyasaya. Özellikle Azure SQL Database gibi, 2 yıl gibi uzun aralıkları beklemeden sürekli yeni özelliklerin eklendiği dinamik bir servisin de devreye girmesiyle, SSMS'in de böyle dinamik bir şekilde güncellenmesi ihtiyacı hasıl oldu. Çünkü SSMS, Azure SQL Database servisinin yönetimi ve bu ortamda yapılacak geliştirme işleri için de kullanılacak en temel araç. Bu nedenle Azure SQL Database servisine yeni bir özellik eklendiğinde, bu özelliğin SSMS tarafından da desteklenmesi gerekiyor ve bu destek artık içinde bulunduğumuz bu süreçte 2 yıl gibi bir süre bekleyemez.

Bu kapsamda ben de Microsoft'un ilgili sayfasından SSMS'in bu yeni versiyonunu test makimene indirdim ve kurdum. SSMS'in bu versiyonu (SQL Server 2016 CTP 2.2 - 31,5MB), SSMS'in önceki versiyonlarıyla yanyana çalışabiliyor, yani bunu kurmadan önce eski versiyonları kaldırmanız şart değil. Ayrıca, SSMS'in bu versiyonu SQL Server 2005 versiyonundan itibaren tüm SQL Server servislerini de destekliyor.

SSMS SQL Server 2016 CTP 2.2

Yukarıdaki ekran görüntüsünden de görebileceğiniz gibi SSMS'in bu yeni versiyonu, güncellemeleri otomatik olarak yapabiliyor. Bunun yanında, aşağıdaki ekran görüntüsünde "Check for Updates…" menüsünü de görebilirsiniz. Eğer güncellemeleri kendiniz kontrol etmek isterseniz, bu yöntemi seçebilirsiniz.

SSMS'in özellikle Azure SQL Database ile birlikte gelecek olan yeni özellikleri destekleyebilmesi için ve bununla sınırlı kalmayarak SQL Server'ın kendi makinelerimizde kurulu olan versiyonlarındaki henüz desteklenmeyen bazı özelliklerin arayüz olarak desteklenmesi ve zaten var olan arayüzlerin iyileştirilmesi / geliştirilmesi için Microsoft'un bu hamlesi sevindirici. Böylece birçok iş için kullanıyor olduğumuz SSMS, genel SQL Server yüklemelerinden bağımsız bir hale geldi. Bakalım zaman, daha nelere gebe?

Ekrem Önsoy

Transaction Log Shipping Status report

Hello there,

I realise that a good amount of DBAs do not take advantage of the built-in reports in the SQL Server Management Studio (SSMS). I have been using Log Shipping in the production servers for more than 7 years. I have used in-house developer tools to monitor the status of my log shipped databases and SSMS' built-in reports. Every shop can not build their own monitoring tools and some do not have a budget to buy a 3rd party tool; but everyone can benefit from the built-in reports of SSMS!

When it comes to IT generally, monitoring is crucial; with this in mind, to a DBA, monitoring is everything. We manage our systems with monitoring tools. Some need to act proactively and others to react to problems before our managers or users start yelling at us.

Oh , yea, I would write something about monitoring Log Shippings. If yours is a small shop and if you are a small shop probably you will have a primary production server and probably you will configure Log Shipping only on that primary server, then you can use SSMS' Transaction Log Shipping Status report. I wanted to stress out this report because I do not see people write about it on the internet. So I thought this report could be beneficial to junior DBAs or some shops who does not have a DBA or some IT professionals (I call them "all-in-one", no offence!) who has to carry about every IT related stuff in the office.

Here's a screen shot about the report I am talking about:

Transaction Log Shipping Status report

I had to crop the left side of the report because it was too large to fit on my screen, besides I would blur it all that column as they are the database names of one of my production servers.

Anyway, as you can see from the screenshot above, you can see everything you need to know about the status of a database's Log Shipping. How long it's been the last backup has been performed, the threshold and if the alert would be triggered if the threshold was crossed and the details about other fundamental jobs, Copy and Restore of Log Shipping.

Here's how you can open this report:

- Open SSMS and go to Object Explorer,

- Right click on the SQL Server Instance name and select "Reports" and then "Standard Reports"

- You will see "Transaction Log Shipping Status" report at the bottom of the list, click on it and there you go.

You will see much more reports about server monitoring in this chest, you can play with them to learn more.

I hope it helps!

Cheers,

Ekrem Önsoy

SQL Server 2012: Target Recovery Time

SQL Server 2014'ü incelerken farkettiğim, fakat aslında ilk defa SQL Server 2012 ile geldiğini öğrendiğim bir özellik, Target Recovery Time'a değinmek istiyorum.

SQL Server 2012'deki yeniliklerden bahsedilirken veya herhangi başka bir makalede hiç rastlamamıştım bu özelliğe. Bu özellik CHECKPOINT ile ilgili. Bu vesileyle SQL Server'daki Checkpoint'lere de değinmiş olayım.

Veritabanı moturunda veri sayfalarında yaptığı işlemleri RAM'de yapar (Data Cache'te) ve yaptığı her değişiklikten sonra hemen diske yazmaz bu değişiklikleri. Zaman zaman, aşağıda çeşitlerini açıkladığım gibi değişik Checkpoint tiplerini kullanarak yapar değişiklikleri diske yazma işlemini. Checkpoint işlemi, hafızadaki o anda bulunan (kirli sayfalar da denilen) veri sayfalarını ve Transaction Log bilgisini hafızadan diske yazma işlemidir. 

SQL Server'da 4 çeşit Checkpoint var, bunlar:

- Automatic: Otomatik Checkpoint'ler "EXEC sp_configure 'recovery interval', 'seconds'" ayarına bağlı olarak tetiklenir. Ayrıca veritabanı motoru yazma işlemlerindeki gecikme 20 milisaniyeyi geçtiğinde de bunu tetikler.

- Indirect: Bu, veritabanı bazında bir ayardır ve "ALTER DATABASE … SET TARGET_RECOVERY_TIME = target_recovery_time { SECONDS | MINUTES }" komutuyla belirlenir. Bu ayar, Instance düzeyinde belirlenen Automatic ayarı ezer. Varsayılan değeri 0'dır ve bu durumda diğer tipler işler.

- Manuel: Transaction SQL komutu olan CHECKPOINT komutu çalıştırılarak tetiklenebilir.

- Internal: Yedek alma veya veritabanı Snapshot'ı oluşturma gibi işlemlerde otomatik olarak veritabanı moturu tarafından tetiklenir. Bu tip için sizin müdahale etme şansınız yok.

Target Recovery Time özelliğini SQL Server Management Studio (SSMS) arayüzünden de değiştirebilirsiniz. Bunun için ilgili veritabanının özelliklerine gidip, Options sayfasındaki Recovery bölümünden aşağıdaki ekran görüntüsünde işaretlediğim ayarı değiştirmelisiniz. Örneğin bu ayarı 30 yaparsanız, her 30 saniyede bir veritabanınız için Checkpoint komutu çalıştırılacaktır ve Dirty Page'ler diske yazılacaktır. 

Bu komutu gerçekten ne yaptığınızı biliyorsanız kullanmanızı tavsiye ederim. Checkpoint işleminin her işlem gerçekleştiğinde tek tek değil de toplu toplu yapılmasının bir nedeni var, performans! Bu nedenle gerçekten ihtiyacınız olduğundan emin değilseniz Checkpoint işlemini bırakın SQL Server varsayılan ayarlarıyla halletsin.

SSMS: Target Recovery Time

Checkpoint'ler hakkında daha fazla bilgi için benim de bu yazıyı yazarken yararlandığım BOL sayfasını kullanabilirsiniz: http://msdn.microsoft.com/en-us/library/ms189573%28v=sql.120%29.aspx

Ekrem Önsoy

SSMS'te kişiselleştirilmiş ortam rengi kullanımı

Bu kullanımdan genelde bihaber olunduğunu düşünüyorum. Neden bahsettiğimi biraz daha açıklayayım, SQL Server Management Studio'nun 2008 versiyonuyla birlikte, "Connect to Server" penceresinde bağlandığımız ortam için renk seçimi yapabiliyoruz. Bu özellik, bağlandığımız ortamın ne kadar kritik bir ortam olduğunu bize görsel olarak da hatırlatıyor. Bazen, bazı ortamlarda o kadar çok SQL Server Instance'ı oluyor ve o kadar çok farklı Instance'a sürekli bağlanmamız gerekiyor ki, bazen feleğimiz şaşıyor ve nerede olduğumuzu karıştırıyoruz. Özellikle böyle ortamlar için bunun çok işe yarayabilecek bir özellik olduğunu düşünüyorum.

Aşağıdaki ekran görüntüsünde gördüğünüz Options >> düğmesine tıklayın.

Connect to Server penceresi

Aşağıdaki ekran görüntüsüyle karşılaşırsınız.

Connection Properties

Bu sekmede, yukarıda işaretlediğim alanı göreceksiniz. Eğer SQL Server Management Studio kullanarak bir SQL Server Instance'ına bağlanırken bu pencereden Select... düğmesine tıklayıp bir renk seçerseniz ve Use custom color kutucuğunu işaretlerseniz bağlandığınız SQL Server Instance'ı için hemen Query Editor penceresinin alt bölümündeki Status Bar aşağıdaki gibi renk değiştirecektir.

Tabii ki bu değişikliği Registered Servers penceresinde sakladığınız bağlantılar için de yapmanız bu özelliğin kullanımını pratikleştirecektir. Aksi takdirde her seferinde bu ayarı değiştirmeniz gerekir.

SSMS 2012'de olası bir BUG?

Selam arkadaşlar,

Ortamlardan birinde Log Shipping uyguluyoruz ve T-Log yedeklerinin Restore edildiği hedef sunucudaki veritabanlarının durumlarının yanlış göründüğünü gözlemledim. Ekran görüntüsü aşağıda.

Ekran görüntüsünden de görebileceğiniz üzere, bu makinede 2 tane Log Shipping ile aktarılan veritabanı mevcut. İlki, yani "Standby / Read-Only" durumunda olan beklendiği gibi, gri veritabanı simgesi ile gösteriliyor; fakat diğerinin yanında "Restoring... / Standby / Read-Only" yazacağına sadece "Standby" yazıyor ve veritabanı simgesi de sarı renk, sanki Log Shipping ile aktarılan bir veritabanı değil gibi.

Örneğin bir işlem yapmaya kalktığımda, bekleneceği gibi aşağıdaki hatayı veriyor:


Msg 927, Level 14, State 6, Line 1
Database '' cannot be opened. It is in the middle of a restore.
Msg 8985, Level 16, State 1, Line 1
Could not locate file '' for database 'master' in sys.database_files. The file either does not exist, or was dropped. 

Böyle bir davranışı önceki versiyonlarda görmemiştim. Böyle bir şey sizin dikkatinizi çekti mi hiç?

Ekrem Önsoy

"The server principal 'LoginAdı' is not able to access the database 'VeritabanıAdı' under the current security context. (.Net SqlClient Data Provider)

HATA MESAJI:
"The server principal 'LoginAdı' is not able to access the database 'VeritabanıAdı' under the current security context. (.Net SqlClient Data Provider)"

AÇIKLAMA:
SQL Server Management Studio 2008 (RTM) kullanarak bir SQL Server 2005 Instance' ına bağlandığınızda ve "Object Explorer" penceresindeki "Databases" düğümü genişlettiğinizde bu hata ile karşılaşabilirsiniz.

ÇÖZÜM:
Bu, maalesef SSMS 2008 (RTM) ' in çok önemli başka bir hatası.

Bu hata ile her zaman karşılaşmazsınız. Şayet bağlandığınız SQL Server 2005 Instance' ındaki herhangi bir veritabanının "Auto Close" özelliğinin değeri "True" ise o zaman "Object Explorer" penceresindeki "Databases" düğümünü genişlettiğinizde bu hata ile karşılaşırsınız.

Üzgünüm, ama bu konuda herhangi bir çözüm şu anda yok. Bu ürün de piyasaya daha yeni sürüldüğü için, henüz yama veya güncellemesi yok. Bu konuda bir çözüm bulunduğunda, yine sitemde duyuracağım.