Avamar v7 ve üzeri - Atık Toplama, veriler kullanılırken "Hash Referenced Bit Maps" (Karma Referanslı Bit Eşlemeleri) nedeniyle silinamayan "atlanmış karmalar" bildirmektedir

Hash Referenced Bit Maps (Karma Referanslı Bit Eşlemeleri) özelliği, atık toplama (GC) bakım etkinliği sırasında yedeklemelerin gerçekleştirilmelerini sağlayan Avamar v7.x özelliğiyle birlikte kullanıma verilen bir özelliktir. 

Bu özellikten önce, veri çakışmaları olasılığı nedeniyle atık toplama işlemi aynı anda çalıştırılemedi. 

Atık toplama aşamasında yeni özellik, eklenen veya değiştirilen veriler hakkında bellekte bilgi sağlar ("referans karmaların haritası"). Atık toplama, hangi karmaların (ve bunların referans verileri) kaldırılamaması gerektiği hakkında bilgi almak için bu bilgileri kontrol eder.  

Bu özelliğin bir gereksinimi, bu "haritalar"ın sıfırlanması için yedeklemelerin yapılamama süresinin en az 5 dakika "sessiz" olmasıdır. Bu sıfırlama gerçekleştiğinde, içinde kilitli olan veriler, değişmeden kalmaya devam ettikleri sürece sonraki atık toplama döngüsü sırasında taranabilir.

Bu sessiz süre, günlük Avamar yedekleme ve bakım programı tasarlanıyorken göz atın. 
Sıfırlanması gereken eşlemelerin başarısızlığı, atık toplamanın süresi dolan verileri temizlemeyi önlenebilir.
Karma referans haritası sıfırlama fırsatına sahip değilse atık tarafından kaldırmaya uygun olan veriler işlenmez ve kapasite kullanımı artmış olabilir. Harita uzun bir süre sıfırlayamadığında atık toplama günlüğünde artan sayıda "atlanan karma" gösterlanabilir.

Yedeklemelerin süresi doldu ancak atık toplama işlemi, o anda bazı veriler kullanımda olduğundan silinmeye uygun tüm verileri kurtarmamış.

Bunu kontrol etmek için aşağıdaki komutu çalıştırın:
Komut, atık toplama bakım günlüğünü 7 gün dökümler ve bunu gösterecek şekilde ayrıştırarak ayrıştırın.

• Kaç karma atlandı?
• Ne kadar veri silindi?
• Atık toplama işleminin kaç geçiş işlemi aldı?
• Atık toplamanın ne kadar süreyle çalıştırması

dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

Analiz:

Çıktı, 16 Şubat 2014 tarihinde karma referans eşlemesi sıfırlanana kadar zaman içinde atlanan karmaların sayısını gösterir.
Karmalar boşaltıldıktan sonra temizlenen veri miktarının "megabayttan kurtarıldı" atlayarak ve atık toplama işleminin süresi dolan veriler için işlenmelerini de esnetebilir.

Anında çözüm

1. Eşlemelerin sıfırlanana kadar sıfırlanana kadar atık toplama işleminin yeniden çalıştırılana kadar devam etmesini sağlar.
2. Sisteme veri ekleyen avtar oturumlarının çalışma olmadığından emin olun (yedekleme veya gelen çoğaltma verileri). GUI Etkinlik Monitörü'ne gidin ve yalnızca "avmaint sessions --full" komutuyla görülen askıda kalma oturumlarını kontrol edin.
3. Tüm yedeklemeleri ve gelen çoğaltma oturumlarını durdurur.
4. Karma Referanslı Bit Eşleştirmeleri'nin sıfırlanması için yeterli süreye izin vermek için en az beş dakika bekleyin.  
5. GC tekrar çalıştırıldığında, atlanan karmaların=0 Atlanmış karmaların sıfıra sıfırlanmadığında yukarıdaki adımları çift kontrol etmek için Destek ile birlikte çalışarak atlanmış karmaların=0

olduğunu onaylamak için GC bakım günlüğünü kontrol edin. Atık toplama işlemi MSG_ERR_TRYAGAINLATER, Destek bunun dizin şeridi bölme etkinliği nedeniyle mi olduğunu doğrular. 
 

Uzun vadeli çözüm

Karma referanslı bit eşlemenin sıfırlanması için normal "boşta" olacak şekilde yedekleme ve bakım programlarını tasarlayın.

Başka bir deyişle, yedekleme zamanlamaları 7/24 çalışmamalıdır. Sisteme yedekleme veya gelen çoğaltma verileri yazıldığında kısa süre veren bir zamanlama oluşturun. 

Notlar: 

• Karma referanslı bit eşlemeleri, sıfırlananın olup olmadığını yalnızca avtar oturumu sona erdikten sonra kontrol eder. Hiçbir avtar oturumu devam ederken harita yalnızca şu durumda sıfırlanır:

• Atlanan karma sayısının geçici olarak yüksek olması için bir neden, dizin şeridinin bölünmesidir. Bunun nedeni, bölünmüş hedefe taşınmış karmaların korunmasıdır. Dizin şeridi bölünmesi, hala büyüyen veya verilerle dolu olan sistemlerde gerçekleşir. 
• Dizin şeritleri bölünen MSG_ERR_TRYAGAINLATER atık toplama işlemi de başarısız olabilir:  
• MCS, Avamar Sunucusu üzerinde yapılan tüm avtar oturumlarının farkında olmayabilir.