Forum
Bildirimler
Hepsini Temizle
SQL Server
8
Yazılar
2
Üyeler
0
Likes
3,534
Görüntüleme
Konu başlatıcı
Merhabalar,
Bir sorgumuzda bu hatayı alıyorum. DbCheck ile kontrol ettiğimde ekte ki hataları almaktayım. Aşağıda ki mesajlar PHYSICAL_ONLY mesajlarıdır. NO_INFOMSGS, ALL_ERRORMSGS mesajları çok daha uzun olduğu için koymadım. NO_INFOMSGS, ALL_ERRORMSGS mesajlarında Primary key indexleri haricinde olan indexleri yeniden oluşturdum.
Önerilerinizi rica ederim.
Table error: page (1:2774642) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:2774643) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:2809812) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:2809813) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:2945732) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:2945733) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3431779) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3941691) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:4197982) allocated to object ID 102408280, index ID 1, partition ID 72057596583608320, alloc unit ID 72057596606808064 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
CHECKDB found 0 allocation errors and 11 consistency errors in table 'Sistem.JobHistoryLog' (object ID 102408280).
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3395146) allocated to object ID 212508136, index ID 47, partition ID 72057596489498624, alloc unit ID 72057596497625088 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Finans.FaturaKalem' (object ID 212508136).
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:2774712) allocated to object ID 399405288, index ID 12, partition ID 72057596542713856, alloc unit ID 72057596561195008 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'LIS.TestIslem' (object ID 399405288).
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3885617) allocated to object ID 1202975512, index ID 20, partition ID 72057596451880960, alloc unit ID 72057596449587200 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3885618) allocated to object ID 1202975512, index ID 20, partition ID 72057596451880960, alloc unit ID 72057596449587200 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3941984) allocated to object ID 1202975512, index ID 1, partition ID 72057595785576448, alloc unit ID 72057596437397504 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3941985) allocated to object ID 1202975512, index ID 1, partition ID 72057595785576448, alloc unit ID 72057596437397504 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:3941986) allocated to object ID 1202975512, index ID 1, partition ID 72057595785576448, alloc unit ID 72057596437397504 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
CHECKDB found 0 allocation errors and 5 consistency errors in table 'Finans.VezneIslemKalem' (object ID 1202975512).
Msg 2533, Level 16, State 1, Line 1
Table error: page (1:2781324) allocated to object ID 1596949161, index ID 241, partition ID 72057596449652736, alloc unit ID 72057596447031296 (type In-row data) was not seen. The page may be invalid or may have an incorrect alloc unit ID in its header.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Hasta.Protokol' (object ID 1596949161).
CHECKDB found 1 allocation errors and 19 consistency errors in database 'DatabaseAdi'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (DatabaseAdi).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Gönderildi : 27/09/2018 18:27
Konu başlatıcı
Bu arada aldığım son backup'ı restore edebiliyorum. birazdan checktable ile bu hataları gidermeye çalışacağım restore ettiğim test dbsinde.Gelişmeleri daha sonra kaynak oluşması için buraya yazacağım. Yine de değerli önerilerinizi rica ederim.
Gönderildi : 27/09/2018 18:47
Merhaba,
Geçmiş olsun öncelikle. index ID si 1 olan tabloları geri dönebiliyorsanız dönmelisiniz. Listede index idsi 1 den büyük consistency hataları var.
Veri tabanı versiyonunuz nedir ? 2017 de columnstore index olan bir tabloda bizde yaşadık böyle kötü dir durumu. Sonra fix yayınlandı. Umarım sizde de böyle bir durum vardır ve fixleyip geçersiniz.
Gönderildi : 27/09/2018 18:55
Konu başlatıcı
,Merhabalar,
Merhaba,
Geçmiş olsun öncelikle. index ID si 1 olan tabloları geri dönebiliyorsanız dönmelisiniz. Listede index idsi 1 den büyük consistency hataları var.
Veri tabanı versiyonunuz nedir ? 2017 de columnstore index olan bir tabloda bizde yaşadık böyle kötü dir durumu. Sonra fix yayınlandı. Umarım sizde de böyle bir durum vardır ve fixleyip geçersiniz.
Teşekkür ederim.
2012 Standart kullanılıyor. Alınan hatalar Primary key üzerinden gittiği için içeride ki ilişkisel yapıdan dolayı dbcheck yetersiz kalır diye düşünüyorum. Object yani tablo bazında checktable üzerinden ilerlemek daha mantıklı gibi geldi. Eğer bir problem yaşamaz ve dataları kurtarabilirsem, runtime da aynı işlemleri yapıyı düşünüyorum.
Bu arada aldığım son backup'ı restore edebiliyorum. birazdan checktable ile bu hataları gidermeye çalışacağım restore ettiğim test dbsinde.Gelişmeleri daha sonra kaynak oluşması için buraya yazacağım. Yine de değerli önerilerinizi rica ederim.
Muhtemele en son yedek de bozuk olabilir, test ortamında repair edip, daha sonra canlı ya geçmek iyi olur. Test ortamında repair allw data loss parametresi ni deneyip, bakarsınız
Benim kontrolümde olmayan bir sunucu. Yaklaşık 15 gündür bu durumdaymış. Biz dün derinmesine inceleyebildik. Biraz önce aldığım backup'ı restore edebildim.
Gönderildi : 27/09/2018 19:42
Konu başlatıcı
Table bazından repair etmem rağmen index 1 lerden kaynaklı olarak data kayıpları gerçekleştir maalesef.
Gönderildi : 28/09/2018 18:37
Konu başlatıcı
Bazılarını Repair edebildim. Bazılarındaysa data kaybı yaşandı. Data kaybı yaşanan indexler Clustered.
Gönderildi : 30/09/2018 15:24
Geçmiş olsun. Hepimiz buradan ders çıkmalıyız. Düzenli Checkdb geri dönüşü olmayan hata kayıplarının önüne geçer.
Gönderildi : 30/09/2018 16:14
Konu başlatıcı
Destekleriniz ve önerileriniz için teşekkür ederim. Sıkıntılı bir süreç. Başımıza gelenleri not olarak aktarmak isterim.
İlk olarak, Rebuild edebildiğimiz objectleri tablo bazında rebuild ettik, edemedilerimizi repair ettik. Burada data kayıpları yaşandı. İlk yaptığımız rebuild ve repair işlemlerinden sonra sorun düzelmişti. databasei check etttiğimizde sorun ile karşılaşmadık. 2 gün backup alamama durumu ile karşılaştık ve database'in tümüyle corrupt olduğunu gördük. Bozulma yaklaşık 20 gün önce başladığı için sağlam son yedeğimiz 1 ay öncesine aitti. Bizde önce ki yedeklerde de sıkıntı olabileceğini düşündük ve database i yeniden datasız olarak yeniden kurduk. Bir scp ile tüm dataların okunabilir olanları içeri aldık. Yakşalık 3 günlük bir çalışam neticesinde data kayıtlarıyla birlikte tekrar ayaklandırabildik. Aldığımız hatalar ve gözlemlerimiz data kayıplarının page ve partition boyutunda olduğu için fiziksel bir disk bozulmasından kaynaklı olduğunu düşündük. Diskleri check ettiğimizde herhangi bir problem ile karşılaşmadık. Yinede hala fiziksel bir sorun olduğunu düşünüyoruz. Veeam isimli bir uygulama ile sunucunun snapshotları alınıyor. Bu yedekleme sırasında partition boyutunda bozulma olduğunu düşüyoruz. Fakat hala tam nedenini tespit edemedik.
Çalışma yaptığımız sunucunun kontrolü bizde olmadığı için elimizden daha önce birşey gelmezdi. Ama yinede bu durumlarla karşılaşmamak ve sağlıklı database için aşağıda ki adımların sık sık yapılması çok önemli.
- Disklerinizi sürekli olarak belirli periyotlar ile kontrol ediniz.
- DBCC ile sürekli olarak online databaselerinizi check ediniz.
- 3.part uygulamalar ile sunucularını sık sık kontrol ediniz.
- Indexlerinizi en az haftada 1 kez rebuild ediniz.
- Database'inizi sürekli olarak 3.part uygulamalar ile dinleyiniz.
Gönderildi : 05/10/2018 17:03
