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.

Bir kaydın Data Cache'te olduğunu nasıl anlarsınız?

Belli bir veritabanındaki, belli bir tablodaki, belli bir kaydın Buffer Pool / Data Cache'te mi yoksa diskte mi olduğunu nasıl anlarsınız?

Öncelikle ilgilendiğiniz kaydın Page ID'sini bulmanız gerekiyor. Bunun için aşağıdaki gibi bir komut kullanabilirsiniz:

SELECT Teslim_Alan, sys.fn_physlocformatter(%%physloc%%) FROM dbo.tabloAdi WHERE xxx_No = 8071030185

Bu komutun sonucu aşağıdaki ekran görüntüsündeki gibi olacaktır:

İlgilendiğimiz kayıt ve Page bilgileri

sys.fn_physlocformatter(%%physloc%%) ile dönen veri bize ilgili kaydın fiziksel olarak nerede durduğunu gösteriyor. Açıklaması şöyle:

1 - Page'in bulunduğu dosyanın ID'si (File ID).
2 - Page ID
3 - Slot numarası

Artık elimizde ilgili kaydın gereken tüm fiziksel bilgileri var. Bu bilgileri kullanarak, önceki bir yazımda bahsettiğim gibi DBCC PAGE komutuyla ilgili Page hakkında daha fazla bilgiye de ulaşabilirsiniz, aşağıdaki DMV ile ilgili Page'in Data Cache'te olup olmadığını da kontrol edebilirsiniz.

SELECT * FROM sys.dm_os_buffer_descriptors WHERE page_id = 8867992 AND database_id = DB_ID()

Yukarıdaki komutu çalıştırdığınızda aşağıdaki gibi bir sonuç dönecektir:

İlgili Page'in Cache'te olup olmadığının sonucu

Eğer bir sonuç dönüyorsa, ilgili kayda ait Page, Cache'te demektir. Yani bu kayıt ile ilgili bir işlem yapmak istediğinizde, SQL Server diske gidip fiziksel IO yapmak zorunda kalmayacak, çok daha hızlı bir şekilde çalışabileceği RAM'e gidecek ve işlemi orada gerçekleştirecektir.

Not: sys.fn_physlocformatter(%%physloc%%) komutuna ait resmi Microsoft dokümanları bulamazsınız, çünkü Microsoft tarafından dokümante edilmemiş bir komuttur.

Ekrem Önsoy

Identity Key sorunu

Bugün bir iş arkadaşım aşağıdaki gibi bir hata aldıklarını söyledi:


Msg 2627, Level 14, State 1, Procedure SP_adi, Line 33
Violation of PRIMARY KEY constraint 'PK_tabloAdi_log'. Cannot insert duplicate key in object 'dbo.tabloAdi_log'. The duplicate key value is (19).

Yukarıdaki hata mesajını şöyle yorumladım: dbo.tabloAdi_log isimli tabloda PK_tabloAdi_log adında bir Primary Key Constraint'i var ve PK olarak belirlenen alana, bu alanda zaten olan 19 değeri tekrar girilmeye çalışılıyor.

Önce bu tablodaki Primary Key alanının hangisi olduğunu belirledim. Sonra bu alanın IDENTITY özelliğinin açık olup olmadığına baktım. Bunları belirledikten sonra bu alana kayıt girmeye çalışan SP'yi kontrol ettim. Her şey doğru görünüyordu, SP açık olarak ilgili PK alanına bir değer INSERT etmeye çalışmıyordu, yani sıradaki Identity değeri neyse onun oluşturulması gerekiyordu.

Daha sonra aşağıdaki komut ile bu tabloda otomatik olarak oluşturulan Identity değerinin ne olduğunu kontrol ettim:

SELECT IDENT_CURRENT('dbo.tabloAdi_log')

Yukarıdaki komutun sonucu 19 olarak geldi. Yani hata mesajımda aldığım değer ile aynı. SQL Server bu tablodaki PK alanında 19 değerini oluşturmaya çalışıyordu, fakat tabloda bu değer zaten olduğu için hata alıyordum.

ve aşağıdaki komut ile de tablodaki o anda bulunan en büyük değeri buldum:

SELECT MAX(id) FROM dbo.tabloAdi_log

Yukarıdaki komutun sonucu da 13617043 çıktı.

Henüz bulamadım, ama bir şekilde bir işlem tablonun SEED'ini değiştirmişti ve yeni oluşturulan Identity değerleri 19'dan devam ediyordu. Hata da bu nedenle alınıyordu. Aşağıdaki komut ile SEED değerini 13617044'ten devam ettirdim.

DBCC CHECKIDENT (dbo.tabloAdi_log, reseed, 13617044)

Ve sorunumuz çözülmüş oldu.

IO sorunu yaşanan mantıksal ve fiziksel veritabanı kaynağını bulma

İlginç bir başlık, değil mi?

Anlık olarak çalışan işlemleri görmek isteriz, özellikle de sorun yaşanıyorken. Bu gibi durumlarda sys.dm_exec_request DMV'sini de kullanabilirsiniz, sys.sysprocesses Catalog View'ünü de.

SELECT * FROM sys.dm_exec_requests WHERE session_id>50

veya

SELECT * FROM sys.sysprocesses WHERE spid>50 and status<>'sleeping'

kullanarak o anda çalışıyor olan işlemlere ait ayrıntıları görebiliriz. Örneğin bir tablonuz var diyelim ve bu tablo büyük bir tablo ve çok önemli bir Index'i eksik olduğu için SELECT ile veri okunurken bu tabloda çok PAGEIOLATCH_SH beklemesi yaşanıyor diyelim. Bu iki sorguyu da kullanarak, o anda  IO kaynağı yüzünden beklenen bu nesneye ait ayrıntıları bulabilirsiniz. Bu nesnenin, yani tablonun ID'sini, dolayısıyla adını ve sıkıntının hangi kayıtlarda yaşandığını, File ve Page ID'lerinden bulabilirsiniz.

Size örnek bir IO beklemesini yakalamak için bir SQL Server Instance'ında aşağıdaki gibi bir kod çalıştırdım:

SELECT * FROM sys.dm_exec_requests WHERE session_id>50 AND wait_type LIKE 'PAGE%'

Bu sorgu bana aşağıdaki sonucu verdi. Benzer bir komutu sys.sysprocesses kullanarak da yazıp çalıştırabilirdim, yine bana wait_resource alanındaki sonucun aynısını verirdi. Özellikle SQL Server 2000 ve altı versiyonlar için, DMV'ler SQL Server 2005 ve sonrasında geldiğinden, sys.sysprocesses'i kullanmanız gerekecek.

Buradaki wait_time değerinin küçüklüğüne bakmayın lütfen, dediğim gibi sadece örnek olsun diye gösteriyorum, bir sorun anında bu süre çok daha uzun olacaktır.

PAGEIOLATCH_SH, özet olarak bize sorgulanan kaydın içinde bulunduğu Page'in o anda RAM'de olmadığını, diskten okunup RAM'e aktarılıyor olduğunu söyler. Tabii ki bu anda ilgili SPID de Waiter List'te Suspended olarak diskten okuma işlemin yapılmasını bekliyordur. Diskten okuma işlemi yapıldıktan sonra CPU kaynağından 4ms'lik Quantum'unu kullanabilmek için Runnable Queue'da sıraya geçecek ve daha sonra da Running olacaktır, daha da merak edenler için, eğer 4ms'lik CPU kaynağı yetmezse ve başka bir IO vb kaynağa ihtiyacı yoksa, o zaman tekrar Runnable Queue'a geçecek ve Runnable durumda CPU kullanımı için sırasını bekleyecektir, eğer IO vb. başka bir kaynağa ihtiyacı varsa da o zaman tekrar Waiter List'e geçecek ve Suspended durumda o kaynağı kullanacak ve akabinde tekrar Runnable Queue'ya geçecektir. Eğlenceli, değil mi?

Burada odaklanmanızı istediğim şey, wait_resource alanındaki değer. Burada gördüğünüz 11:5:15921857 değerini tek tek açıklayayım.

11, veritabanının ID'sidir, aşağıdaki gibi bir sorgu ile veritabanının ID'sinden adını bulabilirsiniz:

SELECT DB_NAME(11)

5, Veritabanının dosyasının ID'sidir, yani File ID. Aşağıdaki sorgu ile dosya ID'sinin hangi diskteki dosyaya ait olduğunu bulabilirsiniz.

SELECT * FROM sys.sysfiles WHERE fileid = 5

15921857, 11 ID'li veritabanının 5 ID'li dosyasında bulunan ve işlem yapmak için diskten RAM'e aktarılmasını beklediğimiz Page'in ID'sidir.

DBCC PAGE komutu, Microsoft tarafından resmen dokümante edilmemiş, fakat çok eskiden beri SQL Server'da bulunan ve kullanılan bir komuttur. Bu komutu kullanabilmek için öncelikle işlem yapacağınız oturumda 3604 numaralı Trace Flag'i etkinleştirmelisiniz, aşağıdaki gibi:

DBCC TRACEON(3604)

Daha sonra DBCC PAGE komutu ile ilgili sayfaya ait ayrıntılara ulaşabilirsiniz:

DBCC PAGE(11, 5, 15921857, 3)

Bu komutu çalıştırdıktan sonra karşınıza aşağıdaki ayrıntılar gelecek:

Metadata: ObjectId bölümünde, okuma işleminin yapıldığı mantıksal alan olan ilgili tablonun ID'sini görebilirsiniz. Bu tablonun adını da ilgili veritabanının içinde aşağıdaki komut ile bulabilirsiniz:

SELECT OBJECT_NAME(1777701681, 11)

Bu örnekte 1777701681 nesnemizin ID'si, 11 ise hatırlarsanız veritabanımızın ID'sidir.

DBCC PAGE komutu her ne kadar dokümante edilmemiş bir komut olsa da, gerek Microsoft'ta çalışmış veya çalışıyor olan kişilerce, gerekse diğer bazı araştırmacı arkadaşlarca kendisi hakkında bayağı yazılıp çizilmiştir. Eğer ilginizi çektiyse bu komut hakkında aşağıdaki 2 sayfadan daha fazla bilgi edinebilirsiniz:

http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/10/625659.aspx
http://support.microsoft.com/kb/83065/en-us

DBCC PAGE komutunu çalıştırabilmeniz için System Administrator (sysadmin) yetkisine sahip olmanız gerektiğini de hatırlatmalıyım.

Ekrem Önsoy

SQL Server 2014 Nisan 1'de yayınlanıyor!

Bu duyuru Microsoft tarafından dün yapıldı.

Bu Relase ile ilgili Microsoft'un yayınladığı notlardan birkaç alıntı paylaşmak istiyorum.

Microsoft'un TAP programı vardır, henüz yeni bir SQL Server versiyonu geliştirilirken bazı büyük şirketlere yapılır bu teklif. Eğer o şirket TAP programına katılmayı kabul ederse, o zaman SQL Server'ın o yeni versiyonu daha piyasaya çıkmadan kullanmaya başlar. Yaşınılan sorunlar doğrudan Microsoft'a bildirilebilir ve düzeltmeler yapılır vs. Bu kapsamda SQL Server 2014'ü kullanan bazı şirketlere ait bazı istatistikler paylaşıldı. In-Memory hakkında olanlar aşağıda.

• Bwin, is the world’s largest regulated online gaming company. SQL Server 2014 lets bwin scale its applications to 250K requests a second, a 16x increase from before, and provide an overall faster and smoother customer playing experience.
• Ferranti, which provides solutions for the energy market worldwide, is collecting large amounts of data using smart metering. They use In-Memory OLTP to help utilities be more efficient by allowing them to switch from the traditional meter that is measured once a month to smart meters that provide usage measurements every 15 minutes. By taking more measurements, they can better match supply to demand. With the new system supported by SQL Server 2014, they increased from 5 million transactions a month to 500 million a day.
• TPP, a clinical software provider, is managing more than 30 million patient records. With In-Memory OLTP, they were able to get their new solution up and running in half a day and their application is now seven times faster than before, peaking at about 34,700 transactions per second.

Transaction'ları ölçme açısından size şöyle bir örnek verebilirim, çalıştığım bankalardan birinde en çok Transaction yapılan zamanlarda 6.600 Batch per second görüyorduk bu bankanın o zaman 600 tane şubesi ve 2.000 kusür ATM'si varken, tabii ki internet şubesi de dahil buna.

Ayıca aşağıdaki gibi bir not da düşmüşler, henüz pratikte nasıl kullanıldığını görmedim; ama teftiş açısından en azından şimdilik teoride kullanılabilir diyebiliriz.

• Enhanced security – Achieve greater compliance with new capabilities for separation of duties.  For example, a database administrator can manage data without seeing the sensitive data itself.

Yine yeni bir özellik olarak Backup'ların Encrypt edilebilme özelliği gelmiş. Böylece yedekler daha güvenli bir şekilde buluttaki sunucularda konumlandırılabilecek.

• Backup to Windows Azure enables customers to configure backups, which are compressed and encrypted, directly to Azure for greater data protection, taking advantage of Microsoft’s global datacenter.
• Beyond SQL Server 2014, this technology will also be generally available as a standalone tool, SQL Server Backup to Windows Azure Tool, on April 1 supporting prior versions of SQL Server.

Daha fazla ayrıntı için:

http://blogs.technet.com/b/dataplatforminsider/archive/2014/03/18/sql-server-2014-releases-april-1.aspx

Ekrem Önsoy