Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Ağustos 2017  >>
PaSaÇaPeCuCuPa
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910
Keywords

2008 sunucularımıza SP2 geçiş projesinde cluster ortamlarımızdan birine SP2 geçerken bir hata ile karşılaştık. Servisin tekrar online olmasını engelleyen bu hata neredeyse bizi cluster kurulumunu tekrar yapmaya götürüyordu ki…

[more]

Tek node cluster yapıdaki sunucumuza yaptığımız SP2 upgrade’i sorunsuz bir şekilde tamamlandı. Setup ekranında herhangi bir hata almadan upgrade sonlandı.

Fakat ilgili resource group online olurken sürekli hata alıp tekrar offline duruma geliyordu. Event viewer’ı incelediğimizde şu hata mesajları ile karşılaştık.

Script level upgrade for database 'master' failed because upgrade step 'sqlagent100_msdb_upgrade.sql' encountered error 598, state 1, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.

Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.

Görünen o ki, her ne kadar setup başarılı bir şekilde tamamlandığını söylese de SP geçişinde bir sıkıntı oluşmuş ve sqlagent100_msdb_upgrade.sql script’i tamamlanmadığı için SP geçişi yarım kalmıştı. Bu yüzden de servis açılamamaktaydı.

İlk aklımıza gelen, sistemi upgrade’i başlamadan önceki haline çekmek amacıyla SP2 kurulumunu uninstall yapmak oldu. Fakat uninstall işlemi de SP geçişi tamamlanmadığı için başarılı bir şekilde bitemedi.

Daha önce başka bir sunucumuzda bu problem ile karşılaşmış ve MS’e açtığımız case ile cluster kurulumunun tekrar yapılması önerisi gelmişti. Bu problemde de cluster kurulumunu tekrar yapacakken aklımıza şöyle bir şey denemek geldi.

Hata alan script sqlagent100_msdb_upgrade.sql scripti idi. Ama hata mesajını tam olarak göremiyorduk. Bir şekilde bu script’i çalıştırabilirsek hata mesajını açık bir şekilde görebileceğimizi düşündük.

İlk aklımıza gelen normal bir şekilde açılmayan servisi single user mode ile açmak oldu. –m parametresi ile servisi açmaya çalıştığımızda yukarıdaki “recover the master database” hata mesajı ile tekrar karşılaştık.

Daha sonra aklımıza 902 Trace Flag’i geldi. Undocumented olan bu trace flag system database’lerindeki hataları göz ardı edip servisi açmaya yaramakta.

Servisi command promptan 902 trace flag’i ile çalıştırdığımızda online oldu. Şimdi geriye script’i çalıştırmak kaldı.

sqlagent100_msdb_upgrade.sql script’ini osql ile command promptan çalıştırıp sonucu –o parametresi ile bir text dokümanı attık. Script hatalı bittiğinde txt dokümanda gördüğümüz hata mesajı şu şekilde idi.

Msg 5184, Level 16, State 2, Server SPRECBDB01, Line 103
Cannot use file 'C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Data\temp_MS_AgentSigningCertificate_database.mdf' for clustered server. Only formatted files on which the cluster resource of the server has a dependency can be used. Either the disk resource containing the file is not present in the cluster group or the cluster resource of the Sql Server does not have a dependency on it.

SP geçişlerinde setup.exe geçici bir veritabanı oluşturmakta. Hata mesajının detayına baktığımızda da bu geçici veritabanı C:\ altındaki bir klasöre oluşturulmaya çalışılmakta ve C:\ klasörü, sql server servisinin dependency listesinde olmadığından dolayı da hata alınmakta.

Peki ama bu temporary veritabanı niye C:\ klasörüne oluşturulmaya çalışılıyor?

Üzerinde çalıştığımız cluster ortamı daha önce de söylediğim gibi tek node’lu bir cluster ortamı. Tek node’lu olduğundan dolayı yani failover yapılmayacağından dolayı biz bu ortamı kurarken system database’lerini C:\ folder’ı altına create etmiştik. Normalde bildiğiniz gibi cluster ortamlarda system database’leri shared disk’lerden birinin içinde bulunmalı ki failover yapıldığında servis çalışabilsin.

Yani sonuç olarak bizim bu cluster ortamımızda master veritabanı C:\ folder’ında bulunmaktaydı. Yukarıda bahsettiğim geçici veritabanı da master veritabanının olduğu yerde oluşturulmaya çalışıldığı ve bu folder’da servisin dependency listesinde bulunmadığından dolayı hata alınmaktaydı.

Burada şu soru aklınıza gelebilir. “Hiç cluster’ın system database’leri C diskinde olur mu yahu?”.

Ortam tek node olduğu ve failover ihtiyacı olmadığı için neden olmasın? Ayriyeten eğer olmaması gerekiyorsa kuruluma da izin verilmemesi gerekiyor. Yani bu soruyu bir cevap olarak kabul etmiyorum Smile

Bu sorunun master database’inin C:\ diskinde olmasından kaynaklandığını farkettikten sonra master database’i dependency disklerden birine taşıyıp servisi tekrar çalıştırdık ve güncellenme işlemleri tamamlanarak servis sorunsuz bir şekilde çalıştı.

Aklımıza gelen bu çözümle en az 4-5 saat sürecek reinstallation’dan kurtulmuş olduk.

Şimdi bu durumu MS Connect’e bug kaydı olarak açacağım. En azından bu durumun SP kurulumu yapılırken check edilmesini ve uyarı verilerek kurulumun engellenmesi gerektiğini bildireceğim. Bakalım cevapları ne olacak?

Daha önce bu tarz bir bug kaydımı ByDesign diyerek reddetmişlerdi. Ama bu sefer bu kadar kolay olmayacak Smile

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2008 Failover Cluster’ı denetim masasından remove ederken şöyle bir hata ile karşılaşabilirsiniz.

[more]

The SQL Server failover cluster instance name '' could not be found as a cluster resource.

Temiz bir uninstallation yapmak için kurulum programı içindeki Remove node from a SQL Server failover cluster kısmını kullanın.

image

image

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server – Her Gün 1 DMV - Gün 10 - sys.dm_io_cluster_shared_drives adlı yazımda Cluster bir environment’ta bulunan drive’ların neler olduklarına TSQL komutları ile nasıl bakabileceğimizi görmüştük. Bugün üzerinde duracağımız sys.dm_os_cluster_nodes DMV’si ile cluster bir environment’taki node’ların neler olduklarını TSQL komutu ile nasıl sorgulayacağımızı görüyor olacağız.

[more]

Failover Cluster olarak kurulmuş bir SQL Server’da minimum 2 adet node bulunmaktadır. Aktif olan node’da bir problem olduğunda failover cluster sistemi devreye girer ve servis’leri 2.node’a otomatik olarak yönlendirerek yüksek erişebilirliği sağlar.

Cluster environment’taki node listesine windows server üzerindeki ClusterAdmin ekranından bakabiliriz. Ama bizim amacımız bu kontrolü TSQL komutları ile yapabilmek.

SQL Server 2000’de gelen fn_virtualservernodes() fonksiyonu ile bu isteğimize cevap bulabiliyoruz. Lakin Microsoft artık bu fonksiyon yerine aşağıdaki DMV’in kullanılmasını önermekte çünkü bu fonksiyon ileriki SQL Server versiyonlarında bulunmayabilir.

select * from sys.dm_os_cluster_nodes

select * from fn_virtualservernodes()

 

Her 2 sorgumuzun sonucuda aşağıdaki gibi bir sonuç olacaktır.

1


Küçük ama önemli olduğunu düşündüğüm bu DMV’ide bilgi dağarcığımızı ekleyerek bugünkü yazımıda noktalıyorum.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Cluster ortamlarda bir disk drive sadece bir instance’ın resource grubuna eklenebilmektedir. Hangi Instance’da hangi drive kullanıldığı bilgisi Cluster Administration ekranından sorgulanabilir. Aslında bir server üzerindeki bir cluster environment için problem yok. Bütün drive lar bu cluster ortamı için kullanılıyor diyebiliriz. Fakat aynı server üzerinde birden fazla instance kurulu ise hangi instance’ın hangi drive lara sahip olduğunu sorgulamamız gerekebilir. Bugünkü yazımda sys.dm_io_cluster_shared_drives DMV si ile bu isteğimizi TSQL ile nasıl karşılayacağımızı görüyor olacağız.

[more]

Giriş paragrafında belirttiğim gibi hangi instance ın hangi drive ları kullandığı bilgisine Cluster Administration ekranından bakmak mümkün.

1


Bizim isteğimiz ise bu drive ları TSQL ile öğrenmek. Bunun için sys.dm_io_cluster_shared_drives DMV sini kullanacağız.

select * from sys.dm_io_cluster_shared_drives

 

Benim kontrolleri yapacağım server üzerinde 2 instance bulunmakta. Bu server’ın drive listesi aşağıdaki gibi;

2


Peki hangi Instance ım hangi drive kullanıyor.

1.Instance

select * from sys.dm_io_cluster_shared_drives

 

3
 

2.Instance

select * from sys.dm_io_cluster_shared_drives

 

4  

Gördüğünüz gibi Cluster Administration’a bulaşmadan Instance ların kullandıkları drive bilgilerine erişebiliyoruz.


İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2008 Cluster bir ortamda node un UP olup olmadığı belirli aralıklarla check edilir. Bugünkü yazımda Windows Server level ında ve SQL Server level ında bu kontrollerin ne olduklarını ve eğer kontrol başarılı olmazsa nasıl fail edildiğini anlatıyor olacağım.

[more]

Validation amaçlı Windows Server ve SQL Server level ında farklı kontroller yapılmaktadır.

Windows Level Check

  • Pasif olan node aktif olan node a “heartbeat” sinyali göndererek UP olup olmadığını kontrol eder.

SQL Server Level Check

  • Looks Alive : SQL Server Service inin UP olup olmadığı kontrol edilir. Default kontrol sıklığı 5 sn dir. Bu değerin değiştirilmesi mümkündür. Yazımın ilerleyen bölümlerinde bunu anlatıyor olacağım.
  • ISAlive : DB Engine üzerinde “Select @@servername” gibi basit bir sql komut çalıştırılarak DB Engine in UP olup olmadığı kontrol edilir. Default kontrol sıklığı 60 sn dir ve Looks Alive gibi bunun da değiştirilmesi mümkündür. Bu kontrol ile sadece SQL Server ın ve master db nin up olup olmadığı kontrol edilir. User Database ler ile ilgili bir kontrol yapılmaz. 

SQL Server profiler dan IsAlive kontrolünün 60 sn de bir nasıl gerçekleştiğini trace edebiliriz. Bu aşamada not düşmek istediğim bir konu var. IsAlive kontrolünü Windows Cluster Service Account u yapmaktadır. Dolayısıyla bu account un SQL Server login lerinde olması ve best practise olarak sysAdmin olması önerilmektedir.

Clipboard01 

Eğer Looks Alive hata alırsa IsAlive kontrolü hemen gerçekleştirilir. Eğer IsAlive kontrolüde hata alırsa bu kontrol 5 kez daha gerçekleştirilmeye çalışır. 5 kontrolün sonucunda da hata alınmaya devam ederse SQL Server Resource grubu fail eder. Bunun neticesinde yapılan ayarlamalara göre grup restart olmaya çalışır yada diğer node a taşınmaya çalışır.

Looks Alive ve IsAlive Ayarları

Looks Alive ve IsAlive kontrollerinin ayarlandığı yer her resource grubun advance tabıdır. Örneğin SQL Server Resource Grubunun advance tab ına bakacak olursak;

Clipboard02

Interval değerlerinin resource type dan alınsın şeklinde set edildiğini görüyoruz. Bu ekranda specify value değerleri ile oynayarak bu resource gruba has interval değerleri kullanabiliriz.

Yukarıdaki örnekte olduğu gibi resource type dan bu bilgi alınsın dendiğinde ise SQL Server resource örneği için Cluster Configuration >> Resource Types >> SQL Server >> Sağ Tık >> Properties ekranından bu değerlere erişebiliriz.

Clipboard03

Bu ekranda yapacağınız değişiklikler “Use Value from Resource Type” seçeneği işaretlenmiş bütün SQL Server Resource ları için geçerli olacaktır.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan