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

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.:)

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ı.

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.

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.

@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. 

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/

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.