Forum
Bildirimler
Hepsini Temizle
SQL Server
8
Yazılar
3
Üyeler
0
Reactions
902
Görüntüleme
Konu başlatıcı
Selamlar;
Üstadlara 3 sorum olacak;
Çalıştığım şirkette yaklaşık 30 sql server var. Plansızlıktan böyle olmuş. Gelen her danışman firma bir server kurdutmuş. Çoğu serverda 2-3 db var. Tek db çalışan makineler bile var.
Tüm dbleri sql 2008 r2 kurulu bir makinede birleştirme sürecim var. Daha doğrusu test ve canlı sistem şeklinde 2 makine.
Böyle büyük bir serverın donanımsal özellikleri en az ne olmalı.? Marka ve model belirtmeksizin ram ve cpu önerinizi bekliyorum.
Bir diğer sorum;
Tek serverda DBlerin kritikliğine / kullanımına göre farklı instancelar kurmak mantıklı mıdır? Yada bu strateji nasıl olmalı? (Sanallaştırma? Farklı fiziksel server?)
Son sorum;
Reporting Service dbleri için nasıl bir çözüm uygulayabilirim? Yani bir çok dbnin raporları tek bir tane "ReportServer" ve "ReportServerTempDB" üstünde olur mu yoksa bunlarıda farklı instance ile mi kurmam gerek?
Kısaca birden çok sql serverı 2 ana serverda birleştirme projem var. Canlı ve test olarak. En baştan iyi bir strateji geliştirmek istiyorum. Ve önerilerinizi bekliyorum.
Teşekkürler.
Gönderildi : 20/12/2010 19:27
Merhaba Ahmet,
Ne yazıkki küçükten büyüğe, kurumsalından kurumsal olmayanına her firmada aynı problem var. 3rd party firmaların her biri senin de dediğin gibi bir app ve db server kurmuş durumda. Bizde durmadan bunları konsolide etme çalışmaları içine girmek durumunda kalmaktayız.
Aslında bakarsan bizede iş çıkıyor. Fena olmuyor 🙂
İlk olarak şunu belirlemek lazım. Virtual server mı yapacaksın yoksa fiziksel mi? Eğer virtual yapacaksan kaynakları başta belirlemek gibi bir zorunluluğun yok aslında. Duruma göre arttırırsın. ama dersen ki fiziksel server kurucam o zaman bu server üzerine koyacağın DB lerin şu anki bulundukları server ların CPU ve memory değerlerini kontrol etmen lazım.
CPU kontolü için processor time,cpu queue length performans counter larını kullanabilirsin. Ayrıca sql server tarafında da kullanabileceğin birkaç DMV var. Aşağıdaki makalelerimi okumanı tavsiye ederim.
http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMV-Gun-20-e28093-sysdm_os_schedulers-ile-CPUe28099da-Bekleyen-Isleri-Sorgulama.aspx
http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMV-Gun-18-e28093-dm_os_sys_info-ile-Database-Server-Bilgileri.aspx
http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMV-Gun-24-e28093-sysdm_os_performance_counters-ile-Performance-Countere28099lar.aspx
http://www.turgaysahtiyan.com/post/SQL-Server-e28093-Her-Gun-1-DMV-Gun-6-sysdm_os_wait_stats.aspx
Memory kontrollerini gelirsek eğer, burada direk bir kontrolümüz yok ne yazıkki. Yani "şu an SQL Server ne kadar memory kullanıyor diye task managerdan bakayım ve benim sql server ımın ihtiyacı budur diyeyim" tarzı bir yaklaşım sergileyemiyoruz. Çünkü SQL Server olan memory nin tamamını kullanır. Çok fazla detaya girmek istemiyorum bu kullanım ayrı bir makale konusu 🙂 Kontrol için yapabileceğin buffer cache hit ratio ve page life expectency performans counterları analiz etmek.
Direk bir RAM CPU önerisinde bulunamayacağım, çünkü db sayısına, db lerin kullanılış davranışlarına göre bu değerler değişir. Yukarıdaki kontrollerle ihtiyacın olan ram ve cpu değerlerine yaklaşık değerler belirleyebilirsin.
Konsolidasyon esnasında dikkat edilmesi gereken hususlardan biride collation konusu. Gerçi bildiğin üzere DB lerde kendine has collation seçebilme şansın var. Ama kişisel tecrübelerime dayanarak user database lerinin collation ının tempdb nin collation ından farklı yapmanı tavsiye etmem. Sorting gibi bazı işlemlerde sıkıntı çıkabilmekte. Dolayısıyla her collation için bir instance yapmanı öneririm.
Son olarak şu tavsiyede bulunabilirim. Bir test bir Production güzel bir şema. Ayrıca availability i arttırmak için prod sunucunu cluster lamanıda öneririm.
Umarım açıklayıcı olmuştur.
Gönderildi : 22/12/2010 12:37
Konu başlatıcı
Turgay Hocam üşenmeyip uzun uzun yazdığın için çok teşekkür ederim. Tavsiyeler çok işime yarayacak.
Fiziksel bir server olacak. Bu yüzden dediğin gibi tek tek bir inceleme yapıp ona göre bir sistem çıkartmayı düşündüm.
DMV'ler çok iyi geldi.
Collation sıkıntılı bir konuydu benim için. Kararsızdım. Ama dediğin gibi en güzeli farklı instance yapmak sanırım. DBleri kategorize edip bunuda halledicem.
Cluster bizimde gündemimizde var aslında. Ama tamda belli değil ne yapacağımız. Her serverı kasete (IBM TSM) yedeklediğimiz için yapılmayabilir. Tabi dataların ne kadarının uçmasına tahammül edilebilir, tartışılacak.
İş konusunda da aynen katılıyorum 🙂
Çok teşekkürler.
Saygılar.
Gönderildi : 22/12/2010 13:02
Rica ederim Ahmet, işine yaradıysa memnun oldum:)
Yalnız cluster konusunda bir hususa düzeltelim:) Cluster Servis avaibility sidir. Data avaibility sine örnek ise mirroring yada log shipping i verebiliriz. O yüzden tape e yedekleme çözümününüzün yanına birde servis avability si yani failover cluster koymak güzel olur gibi.
Rica ederim tekrar
Gönderildi : 22/12/2010 14:25
Konu başlatıcı
Hmm..
Çok doğru. Haklısınız. Bu şekilde öneride bulunucam abilerime 🙂
Çok teşekkürler tekrardan.
Saygılar.
Gönderildi : 22/12/2010 15:14
Rica ederim kolay gelsin
Gönderildi : 22/12/2010 16:53
soyle dusunebilirsin failover cluster icin
elinde 30 tane sql instances var diyelim
1- 2 cpu 30 sql instances icin single node 60 tane cpuya ihtiyac duyar
2 30 sql instances 2gb ram kullaniyorsa single cluster node 60 gb RAMa ihtiyac duyar arti en az 4gb OS icin.
3. 30 sql instances 4 tane disk kullaniyorsa senin cluster disk arrayin 120 tane diske ihtiyac duyar
Bu durumdaki hardware oneri HP icin
2 X HP ProLiant DL580 G7 High Performance - Xeon E7540 2 GHz(48 cpu) 4X HP StorageWorks Disk Enclosure D2700 - storage enclosure, 1 X HP StorageWorks Modular Smart Array P2000 G3 FC/iSCSI Dual Combo Controller
arti bunlar icin baglanti fiber baglantilar, enterprise r2 ve OS lisanslarinida ekle
Kolay gelsin
Gönderildi : 22/12/2010 19:53
Konu başlatıcı
Çok teşekkürler cevap için.
Bizde de HP kullanılıyor zaten sadece. Dediklerinizi not aldım.
Saygılar.
Gönderildi : 22/12/2010 23:04
