It’s quite common for a company that experiences a corruption-causing disaster, but has no valid backups to restore from and no ability to fail over to a redundant secondary, to just run repair and then immediately start running in production again.
Over the years I’ve taught countless classes and conference sessions that talk about corruption and how it happens, how to run consistency checks, using DBCC CHECKDB, and running repair. When I’m talking about repair, I explain that if you have to run REPAIR_ALLOW_DATA_LOSS and it actually deletes data records, you need to reinitialize any affected replication topologies, and validate