You have a hardware problem. Corruption is mostly a hardware problem. It's got nothing whatsoever to do with the size of the index.
windows team test RAM with stress test and there was without errors . After 7.5h of ram stress (and 2 rounds) no error was detected (or corrected).
Look at the IO subsystem. Memory corruptions are rare, because memory has its own error correction.
So really could not be with this size of this index and size of this table? Or it can be that this machine is old and this RAM is DDR2 333Mhz ( 😀 ) , so it can be slow for these big operations?
No. SQL does not corrupt its own indexes, and slow memory will just give you slow results.
Except for certain SP/CU levels in SQL Server 2012 while trying to do an ONLINE index rebuild.;)
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row. First step towards the paradigm shift of writing Set Based code: ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Change is inevitable... Change for the better is not.