Toplu güncelleştirme 3 ile SQL Server 2005 SP4 çalıştıran iki üretim SQL Sunucumuz var. Her iki sunucu da aynı fiziksel makinelerde çalışıyor. DELL PowerEdge R815, 4 x 12 çekirdekli CPU'lu ve 512 GB (evet GB) ramlı, tüm SQL veritabanları ve günlükleri için 10 GB iSCSI SAN bağlı sürücüler ile. İşletim sistemi, tüm SP ve Windows güncellemelerine sahip Microsoft Windows Server 2008 R2 Enterprise sürümüdür. İşletim sistemi sürücüsü, RAID 50'de yapılandırılmış, 2 SQL Sunucusu için çeşitli LUN'lara dilimlenmiş ve ayrıca paylaşılan, 48 x 10K SAS 3.5 "sürücülü RAID 5 dizisidir. bir Exchange makinesi ve birkaç VMWare sunucusu ile.
Bir tanık sunucu kullanılarak, 11 tanesi yüksek kullanılabilirlikle yansıtılmış 20'den fazla veritabanımız var. Tanık sunucusu, tanık hizmetleri sunmaktan başka hiçbir şey için kullanılmayan bir SQL Server örneğini çalıştıran daha düşük güçlü bir makinedir. Yansıtılmış en büyük veritabanı 450 GB'dir ve yaklaşık 100-300 iops üretir. Veritabanı Aynalama İzleyicisi, saniyede 100kb ile 10mb arasında bir geçerli gönderme hızı ve (genellikle) 0 milisaniyelik ek yükler gerçekleştiren bir ayna bildirir. Ayna sunucusunun ana sorumluluğu yerine getirmede bir sorunu yoktur.
Aynalı yıkıcıları sürekli olarak deneyimliyoruz. Bazen tek bir veritabanı yerine çalışma yapar, bazen de tüm veritabanları eşzamanlı olarak yerine çalışma yapar. Mesela, dün gece, 11 veritabanından 10'unda yük devretme yaptık, kalan veritabanı manuel olarak başarısız olana kadar erişilebilir kaldı.
Sorunu tanımlamak için birkaç sorun giderme adımından geçtim, ancak şu ana kadar sorunu çözemedim:
1) Makine, ilk başta birincil ağ bağlantısı olarak kullandığımız bir Broadcom BCM5709C NetXtreme II 4 portlu Gigabit ağ adaptörü ile geldi. NIC'yi sorun olarak ortadan kaldırmak için o zamandan beri her iki makineye de bir Intel (R) PRO / 1000 PT Çift Bağlantı Noktalı Sunucu Adaptörü kurduk.
2) Tüm veritabanları, yansıtmada yer alan veritabanları için bir günlük yedeğiyle birlikte otomatik olarak tam bir yedeklemeye sahiptir. Günlük dosyası kullanımı izlenir ve nadiren kullanılan% 15'in üzerine çıkar. Ana veri tabanı için günlük dosyası, 511 MB ile 1 GB arasında değişen 159 sanal günlük dosyasından oluşan 125 GB'dir. TempDB kendi LUN'unda ve 24 x 2GB dosyadan oluşuyor.
3) Tanıktaki SQL Server günlüğü, aşağıdakilerden başka hatalar göstermez: "TCP: //SQL02.DOMAIN.INET: 5022" ile olan bağlantı yansıması, 30 saniye sonra yanıt vermeden "Veri" veritabanı için zaman aşımına uğradı. Servis ve ağ bağlantılarını kontrol edin.
Birincil ve ikincil sunuculardaki SQL Server günlüğü yansıtma ile ilgili mesajları gösterir:
Yansıtma bağlantısı "TCP: //SQL01.DOMAIN.INET: 5022", "Veri" veritabanı için 30 saniye sonra yanıt vermeden zaman aşımına uğradı. Servis ve ağ bağlantılarını kontrol edin.
Yansıtılmış veritabanı "Veri", Rol Eşitlemesi nedeniyle rolleri "İLKELİDİR" den "AYIRTICI" ye değiştiriyor. (Senkronizasyon burada bilerek yanlış yazılmıştır, çünkü gerçek mesajın tam olarak bu şekilde görüntülenmesidir.)
Yansıtılmış veri tabanı "Data", Yük Devretme nedeniyle "PRINCIPAL" den "MIRROR" a dönüşüyor.
Yansıtılmış veritabanı "Veri", iş ortağından Devretme nedeniyle, "MIRROR" dan "PRINCIPAL" a değiştiriyor.
SQL Server hizmetleri çalışmaya devam ediyor ve ağ bağlantıları açık görünüyor. Her sunucuya bağlı olarak 500 ila 2500 seans arasında sürekli iletişim kuruyoruz (öncelikle, tek bir veritabanında servis aracısı sıralarına bağlanan robotik uygulamalar).
4) TCP kanalı ve RSS vb. NET SH sözdizimi kullanılarak devre dışı bırakılır.
5) SQL Server 2005 Best Practices Analyzer'ı her iki makineye de karşı koydum ve bunların hiçbiri yerine çalışma olaylarıyla çakışmayan, çok nadiren Uygulama Olay Günlüğü 833 hatası dışında bir şey bulamadım:
SQL Server, [Data] (9) veritabanındaki [F: \ Data.MDF] dosyasında tamamlanması 15 saniyeden uzun süren 1 G / Ç isteği oluşumu ile karşılaştı. İşletim sistemi dosya tanıtıcısı 0x00000000000010A0'dır. En son uzun G / Ç'nin ofseti: 0x000007d4b10000).
6) Arada sırada "İstemci, bağlantı havuzu için sıfırlanmış bir SPID XXX oturumunu yeniden kullanamadı. Bu hata, daha önceki bir işlemin başarısız olmasından kaynaklanmış olabilir. Bu hata iletisinden hemen önce başarısız olan işlemler için hata günlüklerini denetleyin. ." her iki sunucu tarafından da oluşturulmuştur. Herhangi bir sorunu belirten "önceki" hiçbir mesaj yok gibi görünüyor.
7) Bazen veritabanı postası Uygulama olay günlüğüne bir hata yazar:
Özel Durum Türü: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException İleti: Bağlantıda bir hata oluştu. Sebep: Zaman aşımı süresi doldu. İşlemin tamamlanmasından önce geçen zaman aşımı süresi veya sunucu yanıt vermiyor., Bağlantı parametreleri: Sunucu Adı: MGSQL02, Veritabanı Adı: msdb Veri: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common. SqlConnectionInfo) Yardım Bağlantı: NULL Kaynak: DatabaseMailEngine
Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) 'deki StackTrace Bilgileri ) şirketinde Microsoft.
Zaman aşımlarının yük devretmeye neden olduğuna inanıyorum; Bu zaman aşımlarına neden ne olabilir? Açıkçası, kötü bir kablo ya da kötü bir anahtar gibi paket ağına ve dolayısıyla bir zaman aşımına neden olabilecek gerçek bir ağ sorunu olsaydı, başka ne zaman zaman aşımına neden olabilir? Engelleme? MSDB veya başka bir sistem veritabanında G / Ç zaman aşımı varsa, bu yansıtma başarısızlığına neden olabilir mi?
Herhangi bir tavsiye için teşekkür ederiz!
MSDN, zaman aşımı mekanizmasının kendisi hakkında söyleyecekleri vardır :
Yansıtma Zaman Aşımı Mekanizması
Yazılım hataları bir sunucu örneği tarafından doğrudan algılanamadığından, yazılım hatası bir sunucu örneğinin süresiz olarak beklemesine neden olabilir. Bunu önlemek için, veritabanı yansıtma, her bir açık bağlantıya sabit bir aralıkta ping gönderen bir yansıtma oturumundaki her sunucu örneğine dayanarak kendi zaman aşımı mekanizmasını uygular.
Bir bağlantının açık kalması için, bir sunucu örneğinin belirtilen zaman aşımı süresi içinde bir bağlantıya ping alması ve bir ping daha göndermek için gereken süreyi alması gerekir. Zaman aşımı süresi boyunca ping almak, bağlantının hala açık olduğunu ve sunucu örneklerinin bunun üzerinden iletişim kurduğunu gösterir. Ping aldığınızda, bir sunucu örneği bu bağlantıdaki zaman aşımı sayacını sıfırlar.
Zaman aşımı süresi boyunca bağlantıda ping alınmazsa, bir sunucu örneği bağlantının zaman aşımına uğradığını düşünür. Sunucu örneği zaman aşımına uğramış bağlantıyı kapatır ve zaman aşımı olayını oturumun durumuna ve çalışma moduna göre işler.
netsh interface tcp show global gösterileri:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled
netsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510
SELECT name, value_in_use FROM sys.configurations
Geçici Dağıtılmış Sorgular 0
yakınlık G / Ç maskesi 0
yakınlık maskesi 0
affinity64 I / O maskesi 0
affinity64 maske 0
Ajan XP'ler 1
güncellemelere izin ver 0
huşu etkin 0
engellenen işlem eşiği 5
c2 denetim modu 0
clr etkin 1
ortak kriterlere uygunluk etkin 0
paralellik 4 için maliyet eşiği
çapraz db sahipliği zinciri 0
imleç eşiği -1
Veritabanı Posta XP'leri 1
varsayılan tam metin dili 1033
varsayılan dil 0
varsayılan izleme etkin 1
tetikleyicilerden gelen sonuçlara izin vermeme 0
doldurma faktörü (%) 0
ft tarama bant genişliği (maks.) 100
ft tarama bant genişliği (dak) 0
ft bant genişliğini bildir (en fazla) 100
ft bant genişliğini bildir (dk) 0
Dizin bellek oluştur (KB) 0
şüphesiz xact çözünürlük 0
hafif havuz 0
kilitleri 0
maksimum paralellik derecesi 6
maksimum tam metin tarama aralığı 4
maksimum sunucu belleği (MB) 393216
maksimum metin repl boyutu (B) 65536
max işçi iş parçacığı 0
medya tutma 0
sorgu başına minimum hafıza (KB) 2048
min sunucu belleği (MB) 52427
iç içe tetikleyiciler 1
ağ paket büyüklüğü (B) 1400
Ole Otomasyon Prosedürleri 1
0 nesneleri aç
PH zaman aşımları 60
ön hesap sırası 0
öncelik artışı 0
sorgu valisi maliyet sınırı 0
sorgu bekle -1
iyileşme aralığı (dak) 0
uzaktan erişim 1
uzaktan yönetici bağlantıları 0
uzaktan oturum açma zaman aşımları 20
uzaktan işlem trans 0
uzak sorgu zaman aşımları 600
Çoğaltma XP'leri 0
başlangıç işlemleri için tarama 0
sunucu tetikleyici özyineleme 1
çalışma seti büyüklüğü 0
gelişmiş seçenekleri göster 1
SMO ve DMO XP'ler 1
SQL Mail XP'ler 0
gürültü kelimelerini 0 dönüştürmek
iki haneli yıl kesme 2049
kullanıcı bağlantıları 0
kullanıcı seçenekleri 4216
Web Asistanı Prosedürleri 0
xp_cmdshell 1
Bir süre önce, mirroring_connection_timeoutsorunu çözmek için tüm yansıtılmış veritabanlarının değerini el ile 30 saniye olarak değiştirdim; bu, yerine çalışma olayları arasındaki süreyi artırdı. İle mirroring_connection_timeout10 saniyelik varsayılan olarak ayarlama seti, bir bakın çok daha yük devirlerinin.
Bir yorum, IPSec'in devre dışı bırakıldığından emin olmamı istedi, bu yüzden netshişletim sisteminin IPSec yapılandırmasını görüntüleyen birkaç komutun içeriğini gönderiyorum :
C: \> netsh ipsec dinamik hepsini göster Şu anda atanmış hiçbir Politika yok Ana Mod İlkeleri mevcut değil. Hızlı mod İlkeleri mevcut değil. Genel Ana Mod Filtreleri mevcut değil. Belirli Ana Mod Filtreleri mevcut değil. Genel Quickmode Filtreleri mevcut değil. Belirli Quickmode Filtreleri mevcut değil. IPsec MainMode Güvenlik İlişkileri mevcut değil. IPsec QuickMode Güvenlik İlişkileri mevcut değil. IPsec Yapılandırma Parametreleri ------------------------------ GüçlüCRLCheck: 1 IPsecempt: 3 IPsec İstatistikleri ---------------- Aktif Doç: 0 Boşaltma SAs: 0 Bekleyen Anahtar: 0 Anahtar Ekler: 0 Anahtar Silme: 0 ReKeys: 0 Aktif Tüneller: 0 Kötü SPI Pkts: 0 Pkts Şifresi Çözülmedi: 0 Kimliği doğrulanmamış pkts: 0 Tekrar Algılamalı Pkts: 0 Gönderilen Gizli Bayt: 0 Alınan Gizli Bayt: 0 Doğrulanan Gönderilen Bayt: 0 Kimliği Doğrulanan Bayt Sayısı: 0 Gönderilen Bayt Sayısı: 0 Alınan Aktarım Baytı: 0 Tünellerde Gönderilen Bayt Sayısı: 0 Tünellerde Alınan Bayt: 0 Gönderilen Boşaltılmış Bayt: 0 Alınan Boşaltılmış Bayt: 0 C: \> netsh ipsec statik hepsini göster ERR IPsec [05072]: Politika Deposunda Politika Yok
GÜNCELLEME: 2012-12-20
Şimdi üretim sistemlerimizi SQL Server 2012'ye taşıdık. 17 Aralık sabahından bu yana çalışıyoruz - şu ana kadar hiçbir arıza yok. Ancak, 2005 tabanlı sistemlerde gördüklerimize birkaç gün kaldı.
Yeni sistemlerimizin performansını belgelemek amacıyla sys.dm_os_wait_statsdaha dikkatli bakıyorum ; ve DBMIRROR_DBM_EVENTbelgelenmemiş bir bekleme türü olan fark . Microsoft’tan Graham Kent’in beklenmedik arızalara ve bu bekleme türlerine ilişkin sorun giderme ile ilgili ilginç bir makalesi var . Bulgularını burada özetleyeceğim:
Müşteri, tüm kafa blokerlerinin DBMIRROR_DBM_EVENT’de beklediği yüksek hacimli bir OLTP veritabanında kurulu büyük bir engelleme zinciri yaşıyordu. İşte yaşadığım olayların sırası:
Engelleme zincirinin kendisini gözden geçirin - burada görebildiğimiz kadarıyla DBMIRROR_DBM_EVENT bekliyoruz
Belgelenmemiş bekleme türünün kaynağını inceleyin. Açıkçası bunu MS'in dışında yapamazsınız, ancak şunu söyleyebilirim ki, bu bekleme türünü yazarken, asıl ayna bir LSN'yi sertleştirmek için beklerken, bu işlemin yapamayacağı bir işlem anlamına gelir. . Bu durum derhal özellikle müdürün aynayı beklerken işlem yapamayacağı sorununa işaret eder. Şimdi aynanın neden işlem yapmadığını ya da müdürün bunun olup olmadığını neden bilmediğini araştırmamız gerekiyor.
Msdb sistem tablolarını gözden geçirin
(a) Problem sırasında üretilen kütüklerin boyutunun normalden önemli ölçüde yüksek olup olmadığını görmek için [backupset] tablosuna bakın. Son derece genişlerse, aynada işlemlerle dolup taşmış olabilir ve hacme ayak uyduramıyor olabilir. Bu nedenle, çevrimiçi kitapların bazen dizin oluşturma gibi son derece büyük bir günlüğe kaydetme işlemi yapmanız gerekiyorsa yansıtmayı devre dışı bırakmanızı söylemesi gerekir. (Bunun neden http://technet.microsoft.com/en-us/library/cc917681.aspx adresinde bulunduğuna dair referans ). İşte şu TSQL kullandım
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(b) ikinci olarak, [dbm_monitor_data] tablolarındaki verilere baktım. Buradaki anahtar, sorun yaşadığımız zaman dilimini bulmak ve sonra aşağıdakilerden herhangi birinde önemli bir değişiklik yaşanıp yaşanmadığına bakmaktır:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateBunların hepsi (a) kısmına benzer göstergelerdir, çünkü cevap vermeyen bir bileşen veya mimari parça gösterebilirler. Örneğin, send_queue aniden büyümeye başlar, ancak re_do kuyruğu büyümezse, o zaman müdürün günlük kayıtlarını aynaya gönderemeyeceği ve belki de bağlantıya bakmak isteyebileceğiniz veya hizmet komisyoncusu sıralarına bakabileceği anlamına gelir. Gerçek iletimlerle başa çıkmak.
Bu özel senaryoda, tüm sayaçların garip değerlere sahip olduğunu belirttik, çünkü normal boyutlarda kütük yedeklemelerinin yapıldığı, ancak durum değişikliği, 0 gönderme kuyruğu, 0 yineleme kuyruğu, sabit gönderme hızı ve sabit olmadığından oranı yinele. Bu, DBM Monitor'ün problem süresi boyunca herhangi bir yerden herhangi bir değeri kaydedemediğini ima ettiğinden çok gariptir.
SQL Server hata günlüklerini inceleyin. Bu durumda, hiçbir hata veya bilgi mesajı yoktu, ancak bunun gibi diğer senaryolarda, diğer ayna bloglarımda başka yerlerde bulabileceğiniz örnekler gibi diğer raporlama bloglarımda bildirilmesi gereken 1400 aralığındaki hatalar için çok yaygındır. bu Hata 1413 örneği
Varsayılan izleme dosyalarını gözden geçirin - bu senaryoda bana varsayılan izler verilmedi, ancak tüm ortaklara durum değişikliği olaylarını kaydettikleri için DBM sorun bilgilerinin fantastik kaynaklarıdır. Bu belgede belgelenmiştir:
Veritabanı Yansıtma Durum Değişikliği Olay Sınıfı
Bu, genellikle ortakların biri veya tümü arasında ağ bağlantısının başarısız olduğu ve daha sonra ortaklığın durumunun ne hale geldiği gibi senaryoların harika bir resmini verir.
SONUÇLAR:
Bu özel senaryoda şu anda 2 anahtar noktayı kaçırıyorum, ancak bunun dışında yukarıdaki bilgiler üzerinde hala makul bir hipotez yapabilirim. Engellemenin, DBM'nin DBMIRROR_DBM_EVENT bekleme türünde bekleyen tüm engelleyiciler nedeniyle etkinleştirilmiş olmasından kaynaklandığını kesinlikle söyleyebiliriz. Aynayı büyük bir günlüğe kaydetmiş işlemle taşmadığımızı ve bu dağıtımın normalde bu modda mutlu bir şekilde çalıştığını bildiğimizden, olağandışı büyük işlemleri hariç tutabiliriz. Bu, bu aşamada 2 potansiyel adayımız olduğu anlamına gelir:
Ortakların bazıları veya tümü arasındaki bağlantıdaki donanım sorunları.
Yansıtma sunucusundaki CPU tükenmesi - yalnızca redolara ayak uyduramazsınız - CPU tükenmesi, SQL Server dışındaki bir süreçten veya bu ayna ortaklığının dışındaki bir işlem olabilir.
Yansıtma kodunun kendisinde bir sorun var (bunu onaylamak için gerçekten bazı bellek dökümlerine ihtiyacımız var).
Tecrübelerime dayanarak 1 veya 2 şüpheleniyorum, ama her zaman 3 hakkında da açık fikirliyim, bu soruna daha detaylı bakmak için şimdi daha fazla veri toplamaya çalışıyoruz.