C
ChUIMonster
Guest
I've been double checking systems after the index corruption bulletin came out: knowledgebase.progress.com/.../Critical-Alert-Index-manager-defect-can-corrupt-large-indexes-where-dbkeys-straddle-32-64-bit-boundary If I am correctly interpreting the bulletin it seems like it is fair to say that a good *quick* check is to run: prostrct statistics dbname | grep "Active blocks:" | sort -nb -k3 The "worst case" is a storage area with 256 rows per block. In that case 8,388,608 blocks is the limit (2^31 / 256). So if *none* of your storage areas are larger than that you're fine and you don't need to do a detailed area by area check. And for more detailed checks the following table could be used: RPB Max Active Blocks (in a storage area containing indexes) === ================= 256 8,388,608 128 16,77,216 64 33,554,432 32 67,108,864 16 134,217,728 8 268,435,456 4 536,870,912 2 1,073,741,824 1 2,147,483,648 Does this match other people's understanding? If the table above is correct then another "quick" filter is that if your 4k db is less than 32GB or your 8k db is less than 64GB you need not bother checking.
Continue reading...
Continue reading...