Masters Of SQL

SQL Server ile ilgili bilgiler, hayata dair paylaşımlar ve birazda eğlence tabii...
Deadlock’sız, Blocking’siz, Contention’sız günler diliyoruz :)
Sysadmin sizinle olsun

SQL Server Page Life Expectancy (PLE) Nedir?

Merhaba MastersOfSQL okuyucuları,


Query Query nereye kadar? demiştik en son herhalde :) buna o kadar inanmışız ki Biz bile yazmayı bırakıp hayatın güzelliklerine dalmışız hatta Padawan'ım Jedi'lik yolunda ilk adımlarını attı Kendisini buradan da kutluyorum.


Padawan'ım la geçen yine şiddetli bir şekilde SQL konuşurken :):) nedir bu PLE diye bir soru sordum? Kendisine yakışan bir şekilde tıkır tıkır (kimin öğrencisi) cevaplar versede baktım ki bu konu tam siteye yazmalık :).


Evet Page Life Expectancy kısaca PLE diyeceğiz kendisine. DBA ler için önemli bir performans counter değeridir peki ne işe yarar daha doğrusu neyi gösterir. PLE page'lerin memory üzerinde tutulma zamanını saniye cinsinden gösterir, sorgu sonucunda aldığınız değerin 300 den büyük olması beklentidir eğer sonuç 300 ve altındaysa burada bakmanız gereken 5dk boyunca alt sınırda olup olmadığıdır counter değeri bu kadar uzun süre alt değerde seyrediyorsa birazdan anlatacağımız sıkıntılara bakmanız gerekecektir.

Tüm performance counter lar için

select * from sys.dm_os_performance_counters

PLE'nin bir performance counter olduğundan bahsetmiştik aşağıdaki sorgu sonucuyla rahatlıkla bu değer ulaşabiliriz.


SELECT 	[object_name],
		[counter_name],
		[cntr_value] 
FROM sys.dm_os_performance_counters
WHERE 
[object_name] LIKE '%Manager%' AND 
[counter_name] = 'Page life expectancy'

Sorgu sonucunda PLE değerimizin 682881 saniye olduğunu görüyoruz. uuuuuuu Her genç DBA in rüyası :):):)

Sorgu sonucunda PLE değerimizin 283 saniye olduğunu görüyoruz. Sebebine bakacağız :)

Biraz daha detaylı bir sorgu yapalım bu rakamları şimdi böl, çarp zor olacak.

SELECT  
	@@servername AS INSTANCE
	,[object_name]
	,[counter_name]
	, UPTIME_MIN = CASE WHEN[counter_name]= 'Page life expectancy'
		      THEN (SELECT DATEDIFF(MI, MAX(login_time),GETDATE())
			  FROM   master.sys.sysprocesses
			  WHERE  cmd='LAZY WRITER')
		ELSE ''
END
	,[cntr_value] AS PLE_SECS
	,[cntr_value]/ 60 AS PLE_MINS
	,[cntr_value]/ 3600 AS PLE_HOURS
	,[cntr_value]/ 86400 AS PLE_DAYS
FROM  sys.dm_os_performance_counters
WHERE   [object_name] LIKE '%Manager%'
    AND [counter_name] = 'Page life expectancy'

Biraz daha okunaklı oldu.

PLE verisini izleyebilmek için bir job yapıp SQL tarafında kayıt altına alabileceğiniz gibi Windows içrisinde bulunan PerfMon'u kullanarak da izleyebilirsiniz.

Çeşitli counterlar eklenmiş bir PerfMon görüntüsü.

Gelelim counter değeri 300 civarlarındaysa nelere bakacağımıza.

  • SQL Server sunucusunun MaxMemory ayarı yapılmamış olabilir. SQL Server config ayarları için tıklayınız.
  • Sisteminizde bolca AD-Hoc query kullanılıyor olabilir. SP (Stored Procedure) ye geçiş yapmanız sistemi rahatlatabilir.
  • Yüksek Execution Plan oluşturan sorgularınız olabilir. Sistem analizi yapıp query leri parçalamanız çözüm olabilir.
  • Index bakımı yapılmamış olabilir
    - Drop Unused Indexes
    - Merge Duplicate Indexes
    - Index Maintenance 
    - Defrag (Rebuild, reorganize)
    - Statistics
  • Sorgularınız çok fazla re-compile oluyordur.
  • Çok büyük boyutlu datanız vardır. Data arşiv çalışması yapabilirsiniz 
  • RAM'iniz gerçekten yetmiyordur:):). Sistem yöneticilerinden RAM talebinde bulunabilirsiniz.


Sevgili SQL ve Performans severler :) uzun bir ardan sonra yazmak zorda olsa bu yazımızında sonuna geldik. Okurken zevk almanız dileğiyle topu Padawan'ıma atıyorum bir güzelce yazı da kendisinden bekliyoruz değil mi?



SQL Server sp_change_users_login :)

Selamlar MastersOfSql okucuları :) 

Sizlere faydalı olacağını düşündüğümüz bir yazı ile karşınızdayız. Her DBA’nin karşılaşmasının kaçınılmaz olduğu, karşılaşmamışsa da yakın bir zamanda karşılaşabileceği bir sorun olan Database User SID ile Server Login SID’nin uyuşmamasından kaynaklanan hatanın çözümünün, anlatacağımız sp ile ne kadar kolay olduğunu sizlere de göstermiş olacağız. 

Başka bir sunucuda aldığımız backup’ı kendi sunucumuza restore ettiğimizde SID’lerin uyuşmaması sorunu ile karşılaşırız. Sp_change_users_login sp si ile bu durumu düzeltebiliriz. 

Nasıl yaparız? 

İsterseniz sizin de deneyebilmeniz için adım adım başlayalım. 

İlk olarak, bu durumla karşılaşacağımız case’i oluşturalım. Bunun için birkaç yol mevcut. Ben size birkaç tane seçenek sunacağım. Siz kolayınıza geleni seçersiniz :) 
  • Başka bir sunucudan aldığımız backup’ı kendi sunucumuza restore edebiliriz. Başka sunucudan geldiği için, restore ettiğimiz database’de bu sunucuda login’i olmayan user’lar mevcut olur. Halk arasında Orphan User dediğimiz olay :) 
  • Benim bir tane SQL’im var. Nereden bulayım farklı 2 tane instance’ı derseniz eğer; aynı sunucuda database’in backup’ını alarak, loginleri silip restore edebilirsiniz. 
  • Backup restore’u anlatmadınız ama biz bu konuyu görmedik henüz(:P) derseniz; ona da bir yöntemimiz mevcut :D (Kendimi şu an 1 değil 2 değil 3 değil tam tamına 5 kavanoz bal 100 TL reklamlarında gibi hissettim :)) Sunucunuzda loginler oluşturarak, bunlara database’de bazı haklar verin. Bu şekilde o database’de user’ı oluşturmuş olacaksınız. Sonrasında loginleri silerseniz, database’in içindeki user’ları silmiş olmazsınız, bu sebeple de loginleri olmayan user’lar elde etmiş olursunuz. Bir login’i bile olmadığı için, öksüz kalmış olurlar. Orphan user dediğimiz olayın oluştuğunu görürüz. 
Gerekli yeter ve şartları sağladıysak, konu başlığımız olan sp_change_users_login ile neler yapabileceğimize bakalım. Benim yapacağım örnekte, denek olarak kullanacağım 2 tane user’ım mevcut.   

DARTHVADER’ı kırmızı kutu içine alırken PADAWAN’ı mavi kutu içine aldım. Bunun sebebi iyi ve kötü diye ayırmak gibi görünse de öyle değil :) İkisi de GALAXY database’inin user’ları olsa da, PADAWAN’ın ne yazık ki bir Logini yok. DARTHVADER için durumlar biraz daha karışık. Onun bir Login’i var ama eskiden bildiği parolası ile sunucuya giriş yapmak istese de yapamaz, çünkü isim olarak aynı gözükse de, parola ve SID olarak bambaşka iki login aslında.

Bakınız, login kısmında sevgili PADAWAN’dan eser dahi yok :(
                                                                 





O zaman sp_change_users_login ile bu duruma bir çözüm yolu bulabiliyor muyuz bakalım :) 
Sp_change_users_login 4 parametre (@Action, @UserNamePattern, @LoginName, @Password) barındıran bir prosedürdür. Kullanımlarını örneklerle açıklayacağız. @Action parametresine 3 seçenek yazarak kullanabiliriz. Report parametresi ile kullanırsak, bize Orphan User’ları verecektir.
use GALAXY
GO
EXEC sp_change_users_login @Action='Report'
Bakınız DARTHVADER ve PADAWAN nasıl da hemen kendini belli etti. 
İlk olarak Darth Vader’dan başlayalım isterseniz. İşini hemen çözelim de sonumuz, nefesini kestiği zavallı askerler gibi olmasın :P Hiç belli olmaz, bir bakmışız configuration manager’dan servisimiz stop edilmiş, sql server’ımız uninstall olmuş olabilir :P :D 

Sysusers’dan ve syslogins’den sid’leri karşılaştırdığımızda sid’lerin aynı olmadıklarını görüyoruz.


Sid’leri eşitleyelim de DARTHVADER rahat rahat GALAXY database’ini kullanabilsin :P Bunun için, @Action parametresi yerine Update_One yazarak yapabiliriz.
exec sp_change_users_login 'Update_One','DARTHVADER','DARTHVADER'



Bakalım olmuş mu?


Sid’ler eşitlendiğine göre DARTHVADER’ın Galaxy’e erişmesindeki engel de kalkmış oldu. Gelelim, zavallı PADAWAN’a. Onun bir login’i bile yok. Ona bir login verebilir miyiz bakalım. @Action parametresindeki Auto_Fix seçeneği ile yapabiliriz.
EXEC sp_change_users_login 'Auto_Fix', 'PADAWAN', NULL, 'MasterYoda*R2D2*'



Artık Sevgili PADAWAN da Orphan User olmaktan kurtuldu :)

Geldik, bir konumuzun daha sonuna :) 

DARTHVADER Login olsa da GALAXY database’indeki hakkı data_reader :) Ne yazık ki SELECT çekmekten öteye geçemeyecek :D Şimdilik endişelenecek bir şey yok diyelim o vakit :) 

Yoda diyor ki boşverin Darth Vader’ı, Olsun Güç Sizinle;)


Star Wars: The Force Awakens 2015

Merhaba MastersOfSql okuyucuları :) 

SELECT'lere EXECUTE'lere, kısacası SQL'e biraz ara vererek, Aralık ayında bizleri bekleyen güzel bir haberi sizlerle paylaşalım.

Blog'umuzda kullandığımız isimlerin Star Wars'a dayandığını fark etmişsinizdir. (Padawan ve Yoda)

Star Wars fanları olarak, Yıldız Savaşları Serisinin 17 Aralık'ta çıkacak Güç Uyanıyor filminin duyurusunu buradan da yapalım istedik. 

Uzun bir aradan sonra Star Wars Fanlarının heyecanla beklediği Güç Uyanıyor Filmi, Üçleme şeklinde çekilmesi planlanan serinin ilk filmi. Gelecek yıllarda serinin diğer iki filmini de heyecanla bekleyeceğiz bu gidişle :) 

Star Wars ile ilgili bakın ne buldum bu arada :D Karakterin küçük ikonlarını yapmışlar. En sağdaki Ahsoka Tano'yu gördünüz mü ne kadar sevimli :) Bir Padawan olarak, benim ikonuma bayıldım.

MastersOfSql ekibi olarak şimdiden iyi seyirler dileriz. Güç sizinle olsun :)