İş değişikliği

Temmuz 2009 tarihinde Veritabanı Mühendisi olarak çalışmaya başladığım Denizbank - Intertech firmasından Eylül 2012 tarihi itibari ile ayrılmış bulunuyorum. Ekim 2012'den itibaren Aktif Grup altındaki Softaktif firması için çalışmaya başlayacağım.

Intertech, gerçekten "profesyonel" diyebileceğim birçok insanın çalıştığı ve her ne kadar zaman zaman çok yorulsam ve yıpransam da, benim de çalışmaktan memnunluk duyduğum bir firma. Kas, ağrısız büyümüyor. Intertech'teki çalışma ortamının yoğunluğu, neredeyse tamamen pratikte çalışmamıza neden oldu. Bu süreçte teorik konularda pek çalışamadım ne yazık ki. Ben en sağlıklı çalışma sürecinin, pratik ve teorik çalışmaların dengeli sürdürülebildiği bir süreç olduğunu düşünüyorum. Tabii ki sadece bu nedenle değil, ama daha ziyade bu nedenle Intertech'teki çalışma sürecimi sonlandırdım. Görevlerini sürdüren arkadaşlarıma başarılı çalışmalarının devamını diliyorum.

Softaktif'te ise Veritabanı Uzmanı olarak çalışacağım. Yine SQL Server sunucularını yöneteceğim, ama bunun yanında SQL Azure, MySQL ve PostgreSQL ile de ilgileneceğim. Bu konularda bilgi edinip, ilgili arkadaşlarımla ve belki bazılarını da sizlerle paylaşacağım.

Ayrıca, SQL Server ile ilgili küçük, orta ve büyük ölçekli tüm projelerinizde (yarım zamanlı olarak), yaşanılan sorunların çözümünde, yerinde doğaçlama veya belirlenecek olan bir müfredata göre eğitim verilmesinde, planlamalarda\kurulumlarda artık birlikte çalışabiliriz. Bu yeni işimde bu çeşit danışmanlık işleri de yapabileceğim. Lütfen ayrıntılar konusunda iletişim kurmaktan çekinmeyin. İletişim bilgilerimi, Blog'umun ana sayfasında bulabilirsiniz.

Umarım herkes için hayırlısı olur.

Kitap: SQL Server 2008 Query Performance Tuning Distilled

Arkadaşlar, 4-5 gündür Grant Fritchey'in yazdığı "SQL Server 2008 Query Performance Tuning Distilled" isimli kitabı okuyorum, elimden bırakamadım.

Grant bu eserinde, çok güzel ve açık örneklerle, gerçek hayatta en çok karşılaşılan SQL Server performans sorunlarını işlemiş. Bu yazılar, gerçekten bu sorunlarla karşılaşmış birisinin elinden yazıldığı için gerçekten kıymetli. Aynı kitabın SQL Server 2012 versiyonu için yazılmış olanı da var. Konu başlıklarına baktım, aynı konular işlenmiş. İşlenilen konuların çok temel olması nedeniyle iki kitap arasında çok fark olacağını düşünmesem de, onu da okuyacağım. En kötü ihtimal aynı kitabı iki kere okumuş olurum ;)

Daha yeni başlayan arkadaşlarıma bu kitabın biraz ağır gelebileceğini düşündüğüm için, orta ve ileri seviyedeki tüm arkadaşlarıma bu kitabı okumalarını tavsiye ederim.

http://www.amazon.com/Server-Performance-Tuning-Distilled-Experts/dp/1430219025

SQL Server'da Server Collation değiştirme

Dün akşam yine böyle bir iş denk geldi. SQL Server 2008 R2 versiyon, hem de Clustered şekilde kurulmuş bir SQL Server Instance'sının Server Collation'ını değiştirmem istendi.

Bu işlemi gerçekleştirmek için öncelikle SQL Server Setup dosyalarına ihtiyacınız olduğunu unutmayın. Bu dosyaların, SQL Server Instance'ının kurulu olduğu sunucudaki bir diskte olduğundan emin olun. Yani Network'te olmasın, doğrudan sunucu üstünde olsun.

Bu işlemi gerçekleştirmeden önce, sistem veritabanlarındaki her şeyin yedeğini aldım. Login'lerin, Job'ların... Eğer olsaydı, bu veritabanlarındaki oluşturulmuş tablo, SP ve diğer nesnelerin de yedeklerini almam gerekirdi. Tüm bunlardan sonra tabii ki sistem veritabanlarının kendilerinin yedeklerini de almakta fayda var. Ardından, Attach ve Detach Script'leri oluşturulmalı ki, Server Collation değiştirme işleminden önce veritabanları Detach edilmeli ve işlem tamamlandıktan sonra tekrar Attach edilmeli.

Bu işlemleri gerçekleştirmek için aşağıdaki adımları izledim:
- Öncelikle Login'lerin Script'lerini çıkardım. Bunun için sp_helprevlogin kullanılabilir (http://support.microsoft.com/kb/246133 , http://support.microsoft.com/kb/918992)
- Job'ların Script'leri alınır. Bunu pratik bir şekilde yapmak için Object Explorer Details penceresini de kullanabilirsiniz.
- Veritabanlarının Attach Script'lerini oluşturmak için ben veritabanlarının CREATE Script'lerini çıkarıyorum ve CREATE DATABASE ... FOR ATTACH komutunu kullanarak CREATE Script'lerinin sonuna FOR ATTACH komutlarını ekliyorum. Böylece hem aynı dosya yollarını ve hem de özelliklerini korumuş oluyorum. Çünkü böyle durumlarda TRUSTWORTHY veya SSB gibi özelliklerin Attach'ten sonra tekrar etkinleştirilmesi unutulabiliyor.
- Veritabanlarının Detach Script'lerini de çıkardık mı, işlemler genel olarak tamamdır. Eğer ortamınızda Linked Server vb. sunucu düzeyinde nesneler varsa, bunları da hesaba katmanız gerekmektedir. Benim senaryomda bunlar yoktu, ama sizin hesaba katmanız gerekebilir.

Daha sonra, eğer SQL Server Instance'ınız benimki gibi Failover Clustered ise, o zaman Failover Manager'dan SQL Server Resource'unu OFFLINE duruma getirmelisiniz. Ardından da, aşağıdaki gibi bir komutu çalıştırarak sistem veritabanlarını yeniden derlemeyi sağlayabilirsiniz, tabii ki istediğiniz Server Collation ile. Aşağıdaki örnekte de görebileceğiniz üzere SQL Server Instance'ım bir Default Instance. Bu işlemde SQLSYSADMINACCOUNTS parametresi ile "sysadmin" rolünün üyesi olarak birden fazla kişi tanımlayabilirsiniz (çift tırnak içinde ve eğer birden fazla kullanıcı olacaksa aralarında aşağıdaki örnekte olduğu gibi boşluk bırakarak). SAPWD parametresi ile de "sa" şifrenizi değiştirebilir veya yeniden belirleyebilirsiniz. SQLCOLLATION parametresi ile de değiştirmek istediğiniz yeni Server Collation değerini (çift tırnağa gerek kalmadan) girebilirsiniz. Aşağıdaki örnekte de görüleceği üzre, Setup dosyaları "C:\SQLSetup\x64" klasörünün içindeydi. Bu komut, Setup.exe'nin olduğu klasörde Command Prompt'ta çalıştırılmalıdır.

C:\SQLSetup\x64>Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS= "DOMAIN\HESAP1" "DOMAIN\HESAP2" /SAPWD="GucluSAsifrem" /SQLCOLLA TION=SQL_Latin1_General_CP1254_CS_AS

Deneyimli SQL Server DBA?

Selam millet,

Bizimle aynı takımda çalışacak SQL Server DBA arıyoruz. Aradığımız profil ise en azından 5 bin kullanıcısı olan bir ortamda Production DBA olarak çalışmış ve 2 sene tecrübesi olan birisi. Bu kriterlere uyan arkadaşlar doğrudan benimle irtibat kursun lütfen.

enaksanamun AT gmail DOT com

Ekrem

"Timeout (30000 milliseconds) waiting for the SQL Server (MSSQLSERVER) service to connect."

HATA:
"Timeout (30000 milliseconds) waiting for the SQL Server (MSSQLSERVER) service to connect."

AÇIKLAMA: Bugün, bir SQL Server 2005 yüklemesi yaparken çok ilginç bir hata ile karşılaştım. Windows System Event Log'daki Hata mesajı, yukarıda belirttiğim gibiydi; fakat kurulum esnasında, ekranda karşıma çıkan hata mesajı daha başkaydı. O anda maalesef ekran görüntüsünün resmini kaydetmediğim için burada sizinle paylaşamıyorum.

Hata mesajı tam olarak Database Engine yüklenmesi esnasında, Database Engin servisi çalıştırılmaya çalışılırken ekrana geliyordu.

SQL Server 2005'i yüzlerce kez kurmuşumdur, buna benzer sorunlarla da karşılaşmıştım; ama bu onların hepsinden farklıydı. Farklı servis hesapları kullansam da, sorunu bir türlü aşamıyordum. Sonra, elimdeki oldukça genel olan bu hata mesajını çaresizce Google'da arattım ve SQL Server 200 RTM'in CPU sayılarıyla sorunları olduğunu gördüm.

Kurulum yaptığım sunucuda 12 adet işlemci çekirdeği vardı ve Microsoft'un kb954835 isimli KB'sinde, bu tür sorunlarla karşılaşabileceği yazıyordu. Ben önce KB'de bahsedilen birinci yöntemi kullandım, fakat işe yaramadı. Sonra ikinci yöntemi kullandım ve VOILA!

ÇÖZÜM: Microsoft'un kb954835 isimli KB'sindeki 2. yöntem ile sorunu çözmeyi başardım. Olur da hâlâ aranızda benim gibi 2012 senesinde SQL Server 2005 kurulumu yapan olur ve böyle bir durumla karşılaşırsanız diye sorunu kaydetmek istedim.

SQL Server 2012 RTM dün yayınlandı!

Arkadaşlar bence Microsoft çok sönük bir şekilde yaptı bu işi, ama SQL Server 2012 RTM dün yayınlandı.

SQL Server 2012 Evaluation Edition: http://www.microsoft.com/download/en/details.aspx?id=29066

MSDN'den de MSDN versiyonunu indirebilirsiniz, orada da olduğunu gördüm.

Volume License versiyonu da çıkmıştır sanırım, ama henüz bunu teyit edemiyorum.

Kendinize bir iyilik yapın ve bu versiyonu indirip kurcalayın. Çok tatlı yenilikler var, keyfini çıkarın!

SQL Server 2012: Product Update

SQL Server 2012 ile birlikte, Setup tarafında güzel bir yenilik geliyor "Product Update"!

Bu özellik, SQL Server 2008 ile birlikte gelen SlipStream özelliğinin çok daha basitleştirilmiş ve Setup'a entegre edilmiş hali. Bu özellik sayesinde, SQL Server yükleme işlemi sırasında, vereceğiniz parametrelere göre SQL Server Update'leri internetten indirilme yoluyla veya zaten önceden indirilmişse belirtilen yoldan kullanılır ve bir yüklemede tüm güncellemeler de yünlenmiş olur.

Aşağıdaki örneğe bakın: Setup.exe /Action=Install /UpdateEnabled=TRUE /UpdateSource="C:\MyUpdates"

Bu örnekte, "UpdateEnabled=TRUE" parametresiyle güncelleme yapılması yapılması, "/UpdateSource="C:\MyUpdates"" parametresi ile de "C:\MyUpdates" yolundaki SP ve CU'ların kullanılması gerektiği belirtiliyor. Böylece tek seferde hem SQL Server yüklenmiş oluyor, hem de istediğiniz tüm güncellemeleri.

Konu hakkındaki daha ayrıntılı bilgiyi aşağıdaki Books Online sayfasından bulabilirsiniz: http://msdn.microsoft.com/en-us/library/hh231670(v=sql.110).aspx

SQL Server 2012 Edition'ları

Merhaba,

Bugün SQL Magazine okurken dikkatimi çekti, sizlerle de paylaşmak istedim. SQL Server'ın bu yeni versiyonunda, yine farklı Edition'lar göreceğiz.

Öncelikle şunu belirtmekte fayda var ki, SQL Server 2012 ile birlikte, artık SQL Server'ın yeni versiyonlarında Itanium desteklenmeyecek.

Ayrıca, SQL Server 2008 R2 ile icat edilmiş olan Datacenter Edition da, artık yeni versiyonun Edition'ları arasında yok. En büyük Edition olarak tekrar Enterprise Edition'a geri dönüldü.

Workgroup Edition ve Small Business Edition'lar da artık yok.

Business Intelligence Edition adında yeni bir Edition olacak. Bu Edition'da, ek SSAS ve SSRS işlevsellikleri ve ek Data Quality Services, Data Services, Tabular mode ve Sharepoint PowerPivot özellikleri olacak.

SQL Server Express Edition artık kalkıyor, yerine SQL Server Express LocalDB adındaki Edition geliyor. Bu Edition'da sadece Database Engine olacak. Servis olarak yüklenmeyecek, bu nedenle servislerle ve servis hesaplarıyla uğraşmanıza da gerek kalmayacak. Bildiğimiz SQL Server'dan herhangi bir farkı olmayıp, tamamen uyumlu olacak. Yüklemesi ve kullanılması daha kolay olacak.

SQL Server Enterprise, Standard, Evaluation, Developer ve Compact Edition'lar gene var olacaklar.

Web Edition da sadece Web Hosting firmalarına, özel bir lisanslama modeliyle verilecek.

Anket: Kaç yıllık SQL Server deneyiminiz var?

Merhaba,

Blogumu takip edenlerin ortalama deneyim seviyesini merak ettiğimden dolayı Aralık ve Ocak ayları süresince devam eden böyle bir anket hazırlamıştım. Ankete katılanlar da katılmayanlar da sağolsun.

Toplamda 31 oy kullanılmış, dağılım şöyle:
- 1 Yıllık deneyim = 4 oy
- 2 Yıllık deneyim = 4 oy
- 3 Yıllık deneyim = 8 oy
- 4 Yıllık deneyim = 3 oy
- 5 (veya daha fazla) Yıllık deneyim = 12 oy

Bu sonuçların doğru olduğunu düşünürsek, değindiğim konuların ortalamayı dahi baz aldığımızda insanları tatmin edebilmesi için biraz daha derinlemesine olmasında fayda olduğu sonucu çıkıyor =)

Hadi bakalım, ha gayret!

"Executed as user: DOMAIN\ServiceAccountName. Cannot open backup device 'X:\BACKUP\BackupFileName'. Operating system error 5(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 3201) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed."

HATA: "Executed as user: DOMAIN\ServiceAccountName. Cannot open backup device 'X:\BACKUP\BackupFileName'. Operating system error 5(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 3201) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed."

AÇIKLAMA: SQL Server veritabanlarında yedek alırken, böyle hatalar alabilirsiniz. Bu hata mesajında öncelikle benim dikkatimi çeken "Operating system error 5" mesajıydı. Bu mesajı gördüğünüzde, "Access is denied" cümleciği gelmeli aklınıza. Normalde hemen bu mesajın yanındaki parantez içerisinde yazmalıydı "Access is denied", fakat benim de bilmediğim bir nedenden dolayı hata mesajının alınamadığına dair bir mesaj var parantez içerisinde. Bu sonuca göre belli ki ilgili yola erişilemiyor. Bu da akla (en azından benimkine) iki şey getirir hemen

1- SQL Server servis hesabının ilgili yola erişim yetkisi yok,
2- Belirtilen yol yok, bir şekilde disk veya klasör uçmuş.

Normalde, hata mesajındaki parantez içerisinde

ÇÖZÜM: Yukarıda da belirttiğim aklıma gelen şeyleri kontrol ederken, diskin ve klasörün yerinde olduğundan emin olduktan sonra, SQL Server servis hesabının ilgili klasöre yetkisinin olup olmadığını kontrol ettim ve ilgili yetkinin olmadığını gördüm. SQL Server servis hesabı için o klasöre okuma\yazma yetkisi verdikten sonra yedek alma işlemi başarıyla tamamlandı ve sorun çözümlenmiş oldu.

Uzun süren maliyetli işlerin takibi

SQL Server Kurulumlarında Gözden Kaçanlar - 8 başlıklı yazımda bir DBA'in veritabanı sunucusunda takip etmek isteyeceği şeylerden bahsetmiştim, bunlardan bir diğeri de uzun süren maliyetli işlerin takibiydi. Bu yazımda da bu konuya değineceğim.

Uzun süren maliyetli işler, genelde:
- Eksik veya yanlış Index'lerden,
- Zamanla ilgili tablolara yeni sorguların gelmesinden,
- Gelen sorgularda değişiklik yapılıp Index'lerde değişiklik yapılmasının unutulmasından,
- Implicit Conversion'lar...

gibi nedenlerden dolayı kaynaklanır.

Geçmişe dönük olarak bu maliyetli işleri sorgulamayı ise, Server Side Trace kullanımıyla görebilirsiniz. Tabii ki kullanacağınız süzgeç değerlerinin kendi ortamınıza göre değişiklik gösterebileceği unutulmamalıdır. Örneğin biz genel olarak kendi ortamlarımızda Batch işlemlerin tamamlanma sürelerini yarım saniyeyi aştığı durumları yakalamayı uygun görüyoruz.

Uzun süren maliyetli işlerin geçmişe dönük takibi için aşağıdaki ekran görüntüsünde de görüleceği gibi bir Server Side Trace ayarlamanız çoğu durum için uygun olacaktır:

Çok temel olarak, gelen sorguların şayet Duration değerleri yüksekse, sorguda kullanılan Function'lara, Implicit Conversion'lara dikkat edin; şayet Reads fazlaysa, o zaman da eksik veya yanlış Index kullanımına odaklanabilirsiniz.

Konuyla ilgili yazılar:
Server Side Trace hazırlamak

Server Side Trace hazırlamak

Deadlock takibi ve Blocking takibi yazılarımda bahsettiğim ve önerdiğim Server Side Trace kullanımı hakkında bilgi vermek için de bir yazı yazacağımı söylemiştim, bu işte o.

Bir Server Side Trace hazırlamanın en pratik yolu, SQL Server Profiler aracını kullanmaktır. Öncelikle Profiler'ı açar, istediğiniz Event'leri ve alanları seçer, istediğiniz süzgeci koyarsınız.

Ardından "Trace Properties" penceresindeki "Run" düğmesine tıklayıp Trace'i başlatır ve anında durdurursunuz. Trace'in Script'ini almak için "File->Export->Script Trace Definition->(kullanacağınız versiyona göre...)For SQL Server 2005 - 2008 R2..." komutunu seçebilirsiniz. Oluşturulan Script'i, Script içerisindeki "InsertFileNameHere" değerini değiştirdikten sonra (Script içerisindeki açıklamaları okuyun lütfen) doğrudan Query Editor'de çalıştırabilirsiniz ve Server Side Trace'iniz çalışmaya başlayacaktır.

Bu Trace'leri ağınızdaki başka bir sunucuda barındırmak mantıklı olacaktır. Hem üretim sunucunuzun disklerini meşgul etmezsiniz, hem eğer birden fazla SQL Server sunucunuz varsa tüm dosyaları merkezi bir yerde tutabilir ve üretim sunucunuzu etkilemeden tetkiklerde bulunabilirsiniz.

Ben ayrıca kritik sunucularım için bu Server Side Trace'lerinin çalışıp çalışmadığını kontrol ettirmeyi de yeğliyorum. "sys.traces" Catalog View'ünü kullanarak çalışan Trace'leri zaman zaman sorgulattırıp, çalışmayan Trace'ler için haberdar olmanızı sağlayabilirsiniz. Böylece Blocking, Deadlock, uzun süren sorguların kaydedilmesi gibi bir DBA için çok elzem olan bilgileri toparlama işini de garantiye almış olursunuz.

Deadlock takibi

SQL Server Kurulumlarında Gözden Kaçanlar - 8 yazısında izlenmezse olmaz diye bahsettiğim şeylerden bir diğeri de Deadlock takibi.

Bir kullanıcı size aşağıdaki gibi bir hata mesajı gösterip, sorun yaşadığını söyleyebilir:

Transaction (Process ID 845) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Şayet Deadlock takibi için bir Trace Flag veya bir Profiler\Server Side Trace kullanmıyorsanız, bu sorunun nedenini anlamanız pek mümkün değildir. Bu nedenle SQL Server'da Deadlock takibi için Trace Flag veya tercihen bir Server Side Trace kullanmak çok yerinde olacaktır. Çünkü bu sayede Deadlock sorunlarıyla ilgili tüm veriler tek bir yerde tutulmuş olur ve yönetimi ve ulaşılabilirliği kolay olur. Trace Flag kullandığınız zaman ise veriler SQL Server Error Log'a yazılacaktır ve diğer tüm verilerle karışacak ve Error Log'u da şişirmiş olacaktır.

Aşağıdaki kod ile, hiç SQL Server servisini kapatıp açmaya gerek kalmadan anlık Deadlock takibi yapabilirsiniz. Anlık diyorum, çünkü bunu bir Oturum (Session) açarak takip etmiş olacaksınız. Oturum kapanabilir, ama Server Side Trace daha sağlamdır.

dbcc traceon (1204, 3605, -1)
go
dbcc tracestatus(-1)
go

Bu takibi Profiler ile yapmak için, "Locks" Event'i altındaki "Deadlock graph" Event'ini kullanabilirsiniz.

Bu takipleri yaptığınız takdirde, geçmişe dönük Deadlock verilerine de ulaşabilir durumda olursunuz ve bu sayede Deadlock sorunlarını çözecek veriye sahip olursunuz.

Konuyla ilgili yazılar:
Server Side Trace hazırlamak

Blocking takibi

Yine SQL Server Kurulumlarında Gözden Kaçanlar - 8 yazısına istinaden, bu yazıda Blocking takibini nasıl yapabileceğinizden bahsedeceğim.

Blocking takibinin geçmişe dönük olsun, anlık olsun yapılmasında büyük fayda vardır. Örneğin kullanıcılar veya sistemciler size gelip "bugün şu saatte zaman aşımı sorunu yaşadık (time-out), acaba veritabanı tarafında bir sorun olabilir mi?" diye sorduklarında, şayet elinizde geçmişe dönük veri yoksa cevap veremezsiniz. Bu da pek hoş bir durum değil. Özellikle bu gibi durumlarda Deadlock, Blocking, uzun çalışan işlemler gibi bilgilere geçmişe dönük şekilde sahip olmak istersiniz. İşte bu yazıda bu 3 temel gereksinimden birisi olan Blocking takibinden bahsedeceğim.

Anlık Blocking takibini iki pratik araçla yapabilirsiniz. Bunlardan biri, Microsoft'un aracı olan "sp_blocker_pss08" isimli SP. Bu SP'ye aşağıdaki adresten ulaşabilirsiniz:

http://support.microsoft.com/kb/271509/tr

Diğer araç ise, SQL Server konusunda dünya çapındaki duayenlerden Adam Machanic'in yazdığı "sp_WhoIsActive" isimli araç. Bu aracı da aşağıdaki adresten edinebilirsiniz.

http://sqlblog.com/tags/Who+is+Active/default.aspx

sp_WhoIsActive isimli Stored Procedure (SP)'ün birçok parametresi bulunmaktadır ve temel maksadı o anda çalışan tüm işlemleri ayrıntılı şekilde göstermektir. Bu SP ile Blocking takibi yapabilmek için "@find_block_leaders" ve "@sort_order" parametrelerini kullanmalısınız, örnek:

EXEC sp_WhoIsActive @find_block_leaders = 1, @sort_order = '[blocked_session_count] DESC'

Geçmişe dönük Blocking takibi ihtiyacınızı karşılamak için ise bir Server Side Trace* kullanabilirsiniz. Bu Trace'te "Errors and Warnings" Event grubunun içindeki "Blocked process report" Event'ini kullanabilirsiniz.

Fakat bu Event'i kullanabilmek için öncelikle SQL Server Kurulumlarında Gözden Kaçanlar - 2 yazımda bahsettiğim "blocked process threshold (s)" ayarını yapmalısınız.

Sonuç olarak, eğer Microsoft'un aracı olan "sp_blocker_pss08" veya Adam Machanic'in çok amaçlı aracı olan (ki favorim) "sp_WhoIsActive" araçlarından birini veya hepsini kullanarak anlık Blocking takibi yapabilir ve "Blocked process report" Event'ini kullanarak oluşturacağınız bir Server Side Trace'i de geçmişe dönük verileri tutmak için kullanabilirsiniz.

*Bir Server Side Trace oluşturma ve yönetme konusunda da başka bir gün (belki yarın?) bir yazı yazacağım. Bu konuda deneyimi olmayan arkadaşlarım o yazıdan da yararlanabilir.

Konuyla ilgili yazılar:
Server Side Trace hazırlamak

Transaction Log doluluk oranını tespit etmek

"SQL Server Kurulumlarında Gözden Kaçanlar - 8" başlıklı yazımda belirttiğim maddelerden biri olan Transaction Log dosyasının doluluk oranını takip etmek için örneğin 3. parti bir yazılım olan Quest'in Stoplight ürününü de kullanabilirsiniz, aşağıda anlattığım yöntemi de. 3. ürün paralı, anlatacağım yöntem beleş ;)

Normal şartlar altında Transaction Log dosyalarının boyutları ve içlerinin doluluk oranları gibi bilgileri DBCC SQLPERF(LOGSPACE) komutuyla alabilirsiniz. Zaten yazdığım Script'te de bunu kullandım. Ayrıca bu işlemi parametrik bir hale getirdim. Parametreler için bir tablo ve sonuçları almak için de bir SP iş görüyor. Eğer her SQL Server Instance'ınızda DBA araçları için oluşturduğunuz bir DBA veritabanınız varsa bu iki nesneyi de o veritabanında tutabilirsiniz.

Ben DBA isimli bir SCHEMA kullanıyorum DBA araçları için, siz de isterseniz böyle yapabilirsiniz veya kendi standardınız varsa onu kullanabilirsiniz.

Tüm bu işlemlere başlamadan önce, komutları nesneleri yaratmak istediğiniz veritabanında çalıştıracağınızdan emin olun. Yeni bir SCHEMA yaratmak için (örneğin DBA):

CREATE SCHEMA [DBA]

Tablonun Script'i şöyle:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON GO
CREATE TABLE [DBA].[GET_USED_LOG_PERCENTAGE_PARAMS](
[dbname] [nvarchar](250) NOT NULL,
[major] [tinyint] NOT NULL,
[critical] [tinyint] NOT NULL
) ON [PRIMARY]
GO

dbname: Bu alana, hangi veritabanının Transaction Log doluluk oranını izlemek istiyorsak, o veritabanının adını yazıyoruz.
major: Bu alana, kritik hatadan önce gelmesini istediğimiz uyarı değerini giriyoruz. Yani örneğin dosyanın boyutu 10GB ve dosyanın %60'ı doldu ve eğer major değer olarak "60" girdiyseniz, kendinize bu eşik değere ulaşıldığında (örneğin Database Mail ile) e-posta göndertebilirsiniz.
critical: Bu alana da kritik eşik değerini giriyoruz. Bu değere ulaşıldığında artık kesinkes haberdar edilmek istersiniz, bu değeri buna göre ayarlamalısınız. Örneğin "85" gibi.

Tabloyu oluşturduktan sonra, Transaction Log'ların doluluk oranını denetleyecek Stored Procedure (SP)'u da oluşturabilirsiniz:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [DBA].[GET_USED_LOG_PERCENTAGE]
AS
IF EXISTS(SELECT * from tempdb..sysobjects where name like '#LogSpaceUsed%')
DROP TABLE #LogSpaceUsed
CREATE TABLE #LogSpaceUsed (dbname nvarchar(200) not null, logsize dec not null, spaceused dec not null, [status] tinyint, )
INSERT INTO #LogSpaceUsed exec sp_executesql N'dbcc sqlperf(logspace)'
SELECT PRM.dbname [Database], spaceused [Percentage Used], PRM.[major], PRM.[critical], 'CRITICAL' AS [Severity] FROM #LogSpaceUsed AS LSU
INNER JOIN DBA.GET_USED_LOG_PERCENTAGE_PARAMS AS PRM ON PRM.dbname = LSU.dbname
WHERE PRM.dbname NOT IN ('model') AND LSU.[spaceused] >= PRM.[critical]
Union all
SELECT PRM.dbname [Database], spaceused [Percentage Used], PRM.[major], PRM.[critical], 'MAJOR' AS [Severity] FROM #LogSpaceUsed AS LSU
INNER JOIN DBA.GET_USED_LOG_PERCENTAGE_PARAMS AS PRM ON PRM.dbname = LSU.dbname
WHERE PRM.dbname NOT IN ('model') AND (LSU.[spaceused] >= PRM.[major] AND LSU.[spaceused] < PRM.[critical])

Bu SP ile, önceden oluşturduğumuz [DBA].[GET_USED_LOG_PERCENTAGE_PARAMS] isimli tablodaki parametreler kullanılarak takip edilmesi istenen veritabanlarının Transaction Log'larını her bir veritabanı için ayrı ayrı belirlediğiniz Major ve Critical değerlere göre sorgulayabilirsiniz. Çıkan sonucu ister HP Openview gibi bir izleme uygulaması ile alırsınız, isterseniz Database Mail ile kendinize e-posta göndertebilirsiniz veya RAISERROR ile Log'lara da kaydettirebilirsiniz ihtiyacınıza göre.

İlgili bağlantılar:
SQL Server Kurulumlarında Gözden Kaçanlar - 8

Tüm "sysadmin"ler silinirse ne yapmak gerek?

Aşağıdaki gibi bazı durumlarda bir SQL Server Instance'ınız için tüm sistem yöneticiliği yetkilerini kaybedebilirsiniz:

- "sysadmin" rolüne sahip tüm kullanıcılar yanlışlıkla silinebilir,

- "sysadmin" rolüne sahip kullanıcılar şirketten ayrılır veya şirkete bağlanamıyor durumda olabilirler,

- "sa" hesabı pasiftir (disabled) ve kimse de şifresini bilmiyordur.

Böyle bir durumda kurulu olan SQL Server Instance'ını kaldırıp tekrar kurabilir ve kullanıcı veritabanlarını tekrar Attach edebilirsiniz. Fakat bu seçenek oldukça zaman kaybına neden olacaktır. Ayrıca sistem veritabanlarını kullanmazsanız tüm sunucu düzeyindeki ayarları ve nesneleri kaybedebilirsiniz.

Daha iyi bir çözüm ise, SQL Server Instance'ını "Single-user Mode"da çalıştırıp (-f veya -m parametresiyle), Local Administrators grubunun üyesi olan bir kullanıcıyı kullanarak bu Instance'a bağlanmaktır. Bu sayede yetkisi olsun olmasın, bu kullanıcı SQL Server Instance'ına "sysadmin" olarak bağlanacaktır. Bu noktadan sonra istediğiniz işlemi yapabilir, "sa" hesabını etkinleştirebilir ve şifresini değiştirebilir veya yeni kullanıcılar yaratıp veya varolan kullanıcılara "sysadmin" rolüne üyelik verebilirsiniz. Ayrıca bu parametre değişikliğini yaptıktan sonra, SQL Server servisini durdurup tekrar başlatmanız gerektiğini unutmamalısınız.

Bu işlemi yaparken (SQL Server'ı başlattığınızda) SQL Server Agent servisinin veya başka bir servisin çalışmadığından emin olmalısınız. Çünkü SQL Server'ı tek kullanıcı durumunda açmış oluyorsunuz ve eğer sizden önce başka bir servis veya kişi bağlanırsa o zaman sunucuya bağlanamaz durumda olursunuz. Bu nedenle sunucuya sizden başka kimsenin bağlanamadığından emin olmalısınız.

Bir SQL Server Instance'ını nasıl Single-user mode'a alabileceğinizi gösteren ekran görüntüsü aşağıdadır: