Bir SQL Server veritabanının versiyonunu bulma

Selam!

Zaman zaman bir veritabanının versiyonunu bulmamız gerekebiliyor, özellikle de versiyonu daha yüksek olan bir veritabanını versiyonu daha düşük olan bir SQL Server Instance'ına Attach etmeye kalktığımızda ve aşağıdakine benzer bir hata ile karşılaştığımızda:

The database 'veritabanı_adı' cannot be opened because it is version 665. This server supports version 661 and earlier. A downgrade path is not supported.

Böyle bir hata ile karşılaştığımızda buradaki 661 ile (artık sizin ortamınızda ne olursa?) bizim Instance'ımızın versiyonu kastediliyor diye bunun hangi versiyon olduğunu az çok bildiğimizi düşünüyorum. Fakat 665 de nedir?

Maalesef bu veritabanı bilgileri Microsoft tarafından resmi olarak kayıt altında alınmadı, çünkü BOL'de de belirtildiği üzere bu bilgi Internal.

Bununla birlikte, sağolsun bir arkadaş bunları bir kenara not etmiş, ben de gerektiği anda ulaşabilelim diye burada değinmek istedim!

http://weblogs.sqlteam.com/dang/archive/2011/07/17/internal-sql-server-database-version-numbers.aspx

Bu Blog'da bir SQL Server 2012 veritabanın versiyonunun ne olduğu yazılı değil, bunu da ben eklemiş olayım:

SQL Server Version:                    Internal Database Version:
SQL Server 2012 + SP1                 706

Veritabanınızın versiyonunun ne olduğunu öğrenmek için aşağıdaki kodu kullanabilirsiniz:

SELECT DatabasePropertyex ('veritabanı_adı', 'version');

Bazı arkadaşlarım bu versiyon bilgisini SQL Server Instance versiyonu ile karıştırabilir diye aşağıdaki bilgiyi de paylaşmak istedim. SQL Server Instance'ının versiyon bilgisi aşağıdaki kod ile bulunabilir:

SELECT @@version

veya

SELECT SERVERPROPERTY('productversion')

Kolay gelsin,
Ekrem Önsoy

SQL Server 2014 (CTP2)'de Öne Çıkan Yeniliklere Özet Bakış - 1

Selam arkadaşlar,

Sizlerle birkaç yazıdan oluşan bir seri ile SQL Server 2014 Community Tehcnology Preview 2 (CTP2) sürümünde de bulunan ve şimdiye kadar açıklanan öne çıkmış bazı Database Engine özelliklerini paylaşmak istiyorum.

Bu ilk yazıda In-Memory OLTP'den bahsedeceğim.

"Hekaton" kod adıyla ortaya çıkan ve bazılarınca böyle kalması da istenen; fakat Microsoft tarafından "In-Memory OLTP" olarak adlandırılan, bildiğimiz Database Engine'e gömülmüş olan alternatif bir Engine dersek yanlış olmaz sanırım. Bildiğimiz klasik SQL Server Database Engine'ine tam olarak entegre edilmiştir. Şu anda halihazırda kullandığımız tablo ve SP yapılarına kıyasla birçooook limitasyonu bulunsa da, zamanla birçoğunun aşılacağına inanıyorum.

Bu yenilikle gelen şeyler temel olarak bir tablonun Memory Optimized Table (MOT) olarak oluşturulabilmesi. Bizim klasik tabloların da adları artık Disk Based Tables (DBT) oluverdi. MOT'lar temel olarak SQL Server servisi başlar başlamaz RAM'e yükleniyorlar. Bildiğiniz gibi DBT'lar, o tablolar üstünde işlem yapıldıkça yavaş yavaş yüklenirlerdi Buffer Pool'a, MOT'lar ile daha servis açılışında yükleniyorlar. Peki ne yararı var? diye sorarsanız hemen şöyle diyebilirim: MOT'lar için artık Blocking sorunu yaşamayacaksınız! Latch'miş, Lock'muş, artık yokmuş. Ayrıca MOT'lardaki verileri Durable olmak ve olmamak üzere saklayabiliyorsunuz. Eğer bir MOT'taki verileri Durable olmayacak şekilde saklarsanız o zaman o veriler ile ilgili işlemler sadece hafızada yapılıyor olacak ve diske işlenmeyecek. Veriler diske işlenmeyeceği için de hiç IO sorununuz olmayacak.


Peki bu teknolojiden en iyi hangi senaryolarda faydalanabilirsiniz? Birçok senaryo olabilir, fakat özellikle alışveriş sepeti, doldur boşalt, oturum yönetimi gibi senaryolar ilk aklıma gelenler; tabii ki çok daha yaratıcı olunabilir!

Tabii ki her tablo öyle kolayca MOT'a çevrilemiyor. Bu konuda bizlere kolaylık sağlayan AMR (http://msdn.microsoft.com/en-us/library/dn205133(v=sql.120).aspx) isimli bir Tool var, bu kullanılabilir. Hangi tabloların MOT'a, hangi SP'lerin Natively Compiled SP'ye çevrilebileceği konusunda fikir veriyor.

In-Memory OLTP ile gelen bir başka yenilik ise hemen bir üst pragrafta da bahsettiğim Natively Compiled SP'ler (NCSP). Bizim bildiğimiz klasik SP'lerin NCSP'ye çevrilmesiyle %70 oranında iyileştirmeler yaşandığını gördüm, Microsoft çok daha fazla iyileşme yaşanabileceğini söylüyor. Bu iyileşme de temel olarak hem MOT'ların NCSP ile daha entegre çalışabilmesinden hem de NCSP'lerin doğrudan C koduna çevrilip (bir SP NCSP'ye çevrildiğinde bu SP için NTFS'te bir *.dll dosyası oluşturuluyor) çok daha kestirme ve etkin bir şekilde çalıştırılıyor olmasından kaynaklanıyor.

Bu konuda şimdilik son olarak söylemek istediğim şey ise gerçekten çoook kısıtlama var! Kesinlikle bu teknolojiyi kullanmadan önce kısıtlamalarına bakmalısınız ve nasıl çalıştığını iyice anladığınızdan emin olmalısınız.

Hex kodundan SQL Server Agent Job adını bulma

Çoğu SQL Server veritabanı yöneticisinin aşağıdaki gibi bir görüntüyle gerek sys.dm_exec_requests, gerek master..sysprocesses ve gerekse 3. parti uygulamalarla çalışan işlemleri kontrol ederken karşılaştığına eminim.

Bunu gördüğümüzde tabii ki ilk bakışta bunun SQL Server Agent ile çalıştırılan bir Job'ın Step 1 isimli adımı olduğunu anlıyoruz. Fakat bu Job'ın adı nedir? Nasıl buluruz? Kolay bir yolu var!

Aşağıdaki ekran görüntüsünden de görebileceğiniz gibi doğrudan msdb veritabanındaki sysjobs tablosundaki job_id alanını sorgulayarak elinizde Hex kodu olan Job'ın ayrıntılarına ulaşabilirsiniz.

Kolay gelsin!
Ekrem Önsoy

İpucu: Güç Yönetimi

Bugün Glen Berry'nin bir kursunu izlerken gördüm ve sizlerle de paylaşmak istedim. Glen Berry, özellikle SQL Server OLTP sistemleri için Windows Server düzeyindeki Control Panel'daki Power Options planlarının çok kritik olmasından bahsediyor. Varsayılan Power Options planı Balanced, fakat SQL Server OLTP sistemler için seçili olması gereken plan High Performance planıymış. Glen, bu değişiklikle işlemciye göre %15 - %25 arası performans iyileşmesi gördüğünü kaydediyor.

Ayrıca, eğer fiziksel sunucunuzun BIOS'una erişebiliyorsanız Glen oradaki Power Management ayarının da OS Control veya Disabled olarak işaretlenmesini tavsiye ediyor.

Muhakkak denemeye değer! Bu değişiklik hakkındaki tecrübelerinizi benimle de paylaşırsanız çok sevinirim.

Ekrem Önsoy

Bir Transactional replikasyona yeniden tüm Article'lar için Snapshot oluşturmadan Article eklemek

Bu sefer sizinle kısa da olsa önemli olduğunu düşündüğüm bu konuyu paylaşmak istiyorum. Replikasyon modelleri arasında Transactional Replication en çok kullandığım ve kullanıldığını gördüğüm model. Burada Transactional Replication'ın nasıl kurulduğundan veya çalıştığından değil, ama kurulduktan sonra nasıl tüm Publication'daki Article'lar için Snapshot oluşturulmadan yeni Article (yani bir tablo gibi yeni bir nesne) eklenebileceğini anlatacağım. Bu noktada, Transactional Replication ve terimleri konusunda bilgi sahibi olduğunuzu varsayıyorum.

Transactional Replication'ı genelde arayüzden kuruyoruz. Bu kurulum sırasında New Publication Wizard'taki Snapshot Agent penceresindeki "Create a snapshot immediately and keep the snapshot available to initialize subscriptions" isimli seçeneği, kurulumu hemen tamamlamak için çoğu zaman işaretliyoruz. Fakat bu seçeneğin işaretlenmesi yüzünden, oluşturduğumuz bu Publication'a her yeni Article eklemek istediğimizde Snapshot tüm Article'lar için oluşturuluyor. Bu da hem Publication'ı oluşturduğumuz kaynak veritabanında daha çok Blocking ve işlem yükü, hem de hedef sunucudaki replike edilen veritabanında daha fazla kesinti olacağı anlamına gelir.

Eğer siz de Transactional Replication kurulumunuz esnasında  "Create a snapshot immediately and keep the snapshot available to initialize subscriptions" seçeneğini işaretlediyseniz aşağıdaki komutu replike edilen veritabanında çalıştırdığınızda aşağıdaki ekran görüntüsündeki gibi "immediate_sync" seçeneğini 0 olarak değil 1 olarak göreceksiniz.

EXEC sp_helppublication @publication = 'Publication adı'

Bu durumu engellemek ve Snapshot'ın sadece eklediğimiz yeni Article'lar için oluşturulmasını sağlamak için "immediate_sync" seçeneğine ek olarak "allow_anonymous" seçeneğini de FALSE duruma getirmemiz gerekiyor. Bunun için yine replike edilen kaynak veritabanında aşağıdaki komutları çalıştırmanız yeterlidir.

EXEC sp_changepublication
@publication = '',
@property = 'allow_anonymous', @value = 'False'

EXEC sp_changepublication
@publication = '',
@property = 'immediate_sync', @value = 'False'

Bu komutları çalıştırdıktan sonra tekrar aşağıdaki komutu çalıştırdığınızda bu sefer bu iki parametrenin değerlerini de yukarıdaki ekran görüntüsündeki gibi 0 (FALSE) olarak göreceksiniz.

EXEC sp_helppublication @publication = 'Publication adı'

Artık kaynak veritabanından yeni bir Article'ı Publication'a ekleyip hedef sunucuya da replikasyon ile aktarmak için tüm Article'lar için Snapshot oluşturulması ve Reinitialization işlemi yapmanıza gerek kalmadı! Sadece eklemek istediğiniz Article'ı Publication'a ister SSMS arayüzünden ister T-SQL komutuyla ekleyin ve Snapshot Agent'ı çalıştırın. Snapshot Agent'ı çalıştırdığınızda göreceğiniz gibi sadece eklediğiniz Article'lar için Script'ler oluşturulacak ve kuyrukta bekleyen replike edilecek Transaction yoksa hemen bu Script'ler hedef veritabanında da uygulanacaktır.

Not: Bazı terimleri kasti olarak size kolaylık sağlaması açısından Türkçeye çevirmedim, bu bir edebi yazı değil, teknik bir makale ve bu terimler bu uygulamayı yaparken her yerde karşınıza çıkacak olan terimlerdir.

Kolay gelsin!
Ekrem Önsoy