Forum

Mikro v16xx da sık ...
 
Bildirimler
Hepsini Temizle

[Çözüldü] Mikro v16xx da sık sık SQL data recovery pending hatası

8 Yazılar
4 Üyeler
6 Likes
3,097 Görüntüleme
Nazmi KAVALCI
(@nazmikavalci)
Gönderiler: 171
Reputable Member
Konu başlatıcı
 

Merhaba; Mikro v16xx kullanan müşterilerimizin bir çoğunda elektrik kesintileri yada sunucunun ani kapanması durumunda sql dataların bazıları recovery pending hatası vermekte;

Yöntem1

EXEC SP_RESETSTATUS 'databasename';

ALTER DATABASE databasename SET EMERGENCY

DBCC CHECKDB('databasename')

ALTER DATABASE databasename SET SINGLE_USER WITH ROLLBACK IMMEDIATE

DBCC CHECKDB ('databasename', REPAIR_ALLOW_DATA_LOSS)

ALTER DATABASE databasename SET MULTI_USER

 

Yöntem 2

ALTER DATABASE [databasename] SET SINGLE_USER WITH NO_WAIT
ALTER DATABASE [databasename] SET EMERGENCY;
DBCC checkdb ([databasename], REPAIR_ALLOW_DATA_LOSS )
ALTER DATABASE [databasename] SET online;
ALTER DATABASE [databasename] SET Multi_USER WITH NO_WAIT

 

Yukarda belirtilen yöntem 1 yada 2 ile dataları onarıyorum ve çalışmaya başlıyor. Bu durum bir kaç müşterimde var Vmware sanallaştırma üzerine kurulu yerde de var fiziksel sunucu olan yerlerde de var ve sunucularda yeni sunucu disklerinde v.s bir arıza yok. Ani kapanmalarda data bozulabilir fakat kullandığımız çeşitli farklı farklı ticari yazılımlar var mikronun eski versiyonlarında böyle bir sıkıntı yoktu diğer mikro bayisi arkadaşlarımıza da sordum onlarda da bazı müşterilerinde oluyor. Ben neyi ve ne şekilde kontrol etmem gerekiyor be bu durumu yazılım firmasına nasıl izah etmeliyim ?

 
Gönderildi : 08/05/2021 09:26

ibrahim yildiz
(@ibrahimyildiz)
Gönderiler: 3670
Üye
 

Bence onlarda benzer yaklaşacaktır. Bence sorunu bütçeye sığınmadan sektörün ve tekniğin temellerine dayanarak çözmek lazım. Burada ki risk oranı çünkü DB repairing değil sadece OS çöktüğünde bir sürü vakit ve işlev kaybı ortaya çıkar.
"sunucu disklerinde v.s bir arıza yok" diskler fiziksel arızlanmaz zaten sadece uzmanlarca ömür kaybeder denilir. Ancak özellikle cache altında olmayan Raid'de disk tablosu çökme oranı çok yüksektir. Bu da repairing yada recovery gerektiriyor yine para kaybı. ECC bellekler ve güncel OS'lar bu oranı düşürse bile sıfırlamıyor. O anda CPU ve OS'un ne işlem yaptığını kimse bilemez malum. SSD'lerde de bu enerji kaybı konusu önemlidir.
Bu konuyu öncelikle birkaç kVA'lık bu sunucu önlerine daha küçük ölçekli online ups'ler ile çözerseniz sorunu baştan elimine etmiş olursunuz. Bir model seçimiyle usb vs yazılımla tanımlanırsa da batch ve shutdown komutu verdirilerek enerji kaybı güvenlice halledilmiş olur. Bu uzun vade de diğer firmalara göre hizmet kalitenizin arttırıldığını farkedilmesine de sebep olur. Paradan kaçan kobilere vs bir bela bin nasihatten evladır 🙂 yaklaşımıyla db repair etmeden önce online ups aldırılırsa bence herkes kazanmış olur.:)

****************************************************************
Probleminiz Çözüldüğünde Sonucu Burada Paylaşırsanız.
Sizde Aynı Problemi Yaşayanlar İçin Yardım Etmiş Olursunuz.
Eğer sorununuz çözüldü ise lütfen "çözüldü" olarak işaretlerseniz diğer üyeler için çok büyük kolaylık sağlayacaktır.
*****************************************************************

 
Gönderildi : 08/05/2021 13:13

Ömer ÇOLAKOĞLU
(@omercolakoglu)
Gönderiler: 49
Trusted Member
 

Sorun aslında belli elektrik kesilmesi. Onun önüne geçecek önlem almak gerek.

Peki elektrik kesilince ne oluyor?

Sanallaştırma ortamlarının bir çoğunda storage lar var. Bu storage lar okuma yazma yapılan işlemleri cache bellek üzerinde yapıyor ve belli zamanlarda disklere yazıyor. Şayet storage ın bataryası da zayıflamış ise bu bilgiyi diske yazamadan kapanıyor. Tekrar açıldığında da veri tutarsızlığı sebebi ile sql bu hatayı veriyor. Storage larınız eski ise bataryaları mutlaka kontrol edilmeli. Elektrik kesilmelerine de önlem alınmalı.

 
Gönderildi : 10/05/2021 17:01

Nazmi KAVALCI
(@nazmikavalci)
Gönderiler: 171
Reputable Member
Konu başlatıcı
 

Tekrardan merhaba yine aynı konuyu açıyorum fakat halen bir çözüm bulmuş değilim verilen cevaplara istinaden UPS i çalışır duruma getirdik, sunucuya 3 adet ssd disk alıp raid5 olarak yeni bir grup oluşturdum sanal makinelerimi bu grup üzerine taşıdım şunu sadece ani kapanmalarda değil sunucuyu normal koşullarda yeninden başlattık dan sonrada sql de bulunan 40 a yakın veri tabanından 4 tanesi sadece bozuluyor. Mikro üzerinden güncellemeleri sürekli yapıyorum veri tabanı bakım ve onarımı mikro üzerinden çalıştırıyorum veri tabanlarını SHRINK yaptım. acaba ne kaçırıyorum nelere daha bakmam lazım.

 
Gönderildi : 06/02/2022 18:12

ibrahim yildiz
(@ibrahimyildiz)
Gönderiler: 3670
Üye
 

Senaryonuz biraz garip değil mi? 40 db tek bir sunucuda mı? ve neden o kadar çok.
Bu tip bir durumda performans ve eşlikçi görünenleri kontrol edilmeli, OS'un yönettiği prosedürler yetişmeden servisler down oluyorsa tabi ki o an da beklemede kalan db write işlemlerinden dolayı bozulma görülebilir. Normal de shutdown komutu verdiğinizde servislere paralel session'lar düşer fakat 40'a takıldım ben hiç görmedim, duymadım olayların analiz edilmesi için bu ilk soru işaretidir.

Sunucunun power modlarını ve sihhatini kontrol edin. Shutdown, restart verdiğinizde ve uyku modlarına üzerinde yük yokken sihhatli şekilde geçiyor olmalı. Örneğin disklerin enerjisini dengesiz şekilde kesmiyor olmalı.

Raid'i nasıl yapıyorsunuz bilmiyorum ama yukarıda işaret edildiği gibi üzerinde varsa cache battery sihhatli durumda olmalı. 

SSD ile oluşturduğunuz raid array'e write testleri uygulayın bir yapılandırma probleminiz olabilir.

Shrink konusunda geçen bir konuda linkler paylaştım onları inceleyin.

Ve tabi bu yaygın ve donanım, ortamdan bağımsız bir durum ise db'ler bağlamında ki analizi Mikro yazılımcılarıyla yapmanız lazım tasarımlarını en iyi onlar bilir.

****************************************************************
Probleminiz Çözüldüğünde Sonucu Burada Paylaşırsanız.
Sizde Aynı Problemi Yaşayanlar İçin Yardım Etmiş Olursunuz.
Eğer sorununuz çözüldü ise lütfen "çözüldü" olarak işaretlerseniz diğer üyeler için çok büyük kolaylık sağlayacaktır.
*****************************************************************

 
Gönderildi : 06/02/2022 20:19

Nazmi KAVALCI
(@nazmikavalci)
Gönderiler: 171
Reputable Member
Konu başlatıcı
 

@ibrahimyildiz  cevaplarınız için teşekkür ederim, Mikroda aslında iki db aktif olarak kullanılıyor. Her yıl devir yapılınca eski yıllar da sunucuda kalıyor pek kullanılmıyor. mikro db de hem programın kendi db si var hem de her yeni yılda açılan yeni iki veritabanı geriye dönük 5 yıl yapıyor. bir db nin ayriyetten logdatası ve work datası da var. açılan her yeni yıl de 3 tane db oluşturuyor. mikro v16xx e geçtikden sona da lisanslamada değişikliğe gitti veri tabanlarını farklı bir sunucuya ayıramıyoruz lisans düşüyor. mecbur son 5 yılı da aynı sunucuda tutmak zorundayız geriye dönük gerekiyor. sistemde storage yok. Sunucunun kendi diskleri üzerinde 3x300 gg sas raid5 mevcuttu bu sorunu yapınca ve yer sıkıntısı yaşayınca  1x3 tb ssd disk alıp ayrı bir grup oluşturup raid5 yaptım ve vcenter a ekledim. Sonra makineleri kapatıp ssd lerin üzerine sistemi taşıdım. sorun yine düzelmedi. 

 
Gönderildi : 06/02/2022 20:39

ibrahim yildiz
(@ibrahimyildiz)
Gönderiler: 3670
Üye
 

Anladım. Yukarıda ki kontrollere şuan ki kafa yoğunluğuyla ekleyebileceğim çok fazla birşey yok açıkçası. Sanki sunucu da veri yoğunluğuna karşın fiziksel yapılandırma yeterli değil gibi geliyor hiç görmeden atıyorum. Çok fazla yapılması gereken fiziksel kontrol var. 
Sadece takıldığım o umarım yazım hatasıdır 🙂 3x1TB ssd'dir herhalde. Yoksa ssd'i sas'larla umarım birleştirmemişsinizdir tahminen.:) Umarım maliyet kaygısıyla qlc son kullanıcı türü ssd'lerden almamışsınızdır (samsung qvo gibi) bunlar doldukça özellikle raid altında saçma sapan sonuçlar doğurabiliyor. 
Bir de Bench ile disk performansının dengeli olup olmadığına bakabilirsiniz.

https://flings.vmware.com/storage-performance-tester
https://www.mssqltips.com/sqlservertip/2127/benchmarking-sql-server-io-with-sqlio/

****************************************************************
Probleminiz Çözüldüğünde Sonucu Burada Paylaşırsanız.
Sizde Aynı Problemi Yaşayanlar İçin Yardım Etmiş Olursunuz.
Eğer sorununuz çözüldü ise lütfen "çözüldü" olarak işaretlerseniz diğer üyeler için çok büyük kolaylık sağlayacaktır.
*****************************************************************

 
Gönderildi : 10/02/2022 00:33

Serkan Ateş
(@serkanates)
Gönderiler: 1137
Estimable Member
 
Gönderen: @nazmikavalci

1x3 tb ssd disk alıp ayrı bir grup oluşturup raid5 yaptım

Bu raid yapısı ile büyük risk alıyorsunuz, dikkatli olun. 2 tanesi ile raid 1 yapıp kalanı spare bırakmak çok daha güvenli olur. Evet performans düşer ama ben güvenlik derim.

Mikro tecrübem yok ancak "veritabanları bozuluyor" olarak tanımladığınız şey aslında sistemin işletmesi gereken süreçlerini sağlıklı olarak yürütemediğini gösteriyor. SQL servisleri için yeterli kaynak var mı? Donanım, işletim sistemi, SQL servisi olması gereken uyumluluklara sahip mi bilemiyoruz. Ancak elektrik kesilince kapanan sunucudan buraya gelmiş olmak ta bir iyileştirme aslında. @ibrahimyildiz belirtmişti kullandığınız güç kaynağının desteği varsa sunucunuz ile entegre edebilir, güç kaynağı tamamen tükenip enerjiyi kesmeden önce sunucunuzu güvenli bir şekilde kapatabilir. Aksi takdirde güç kaynağı bitince sunucunuz konrolsüz kapanırsa aldığınız önlem eksik kalmış olur.

Veritabanlarının bozulması konusuna dönecek olursak, eski yıllara ait birden fazla veritabanından bahsetmiştiniz. İlk olarak kaynak tüketimini optimize etmek için kullanılmayan veritabanlarını pasif'e çekebilirsiniz. Bu durumda servisin üzerindeki yükü azaltmış olacaksınız. Kullandığınız yazılımın bu duruma ne tepki vereceği ile ilgili hiç bir fikrim yok, lütfen işlem öncesi teknik destek alın.

Kolay gelsin.

 
Gönderildi : 10/02/2022 08:19

Paylaş: