SQL Server – Understanding DBCC CHECKDB, Snapshots, and Standard Edition

Seems like you have a serious database corruption as CHECKDB points it out

repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB

The only feasible options are :

1. Restore from backup or
2. Repair with data loss => Might leave the database in a transactionally inconsistent state.

In both cases, you will have data loss (provided you have good full and T-log backups before that guy pushed green button instead of blue).

I would go for option 1 => Restore from a know latest good backup !

Refer to IAM pages, IAM chains, and allocation units and IAM page corruption examples

UAT looks like as with success, no data missing

If you regularly have UAT in sync with PROD, best is to use that dataset to restore PROD - unless you are masking PROD data in UAT.

There is an internal snapshot that SQL Server will try to create when you run certain DBCC commands. There is really good information about this on the BOL reference for DBCC.

When you execute one of these DBCC commands, the Database Engine creates a database snapshot and brings it to a transactionally consistent state. The DBCC command then runs the checks against this snapshot. After the DBCC command is completed, this snapshot is dropped.

Sometimes an internal database snapshot is not required or cannot be created. When this occurs, the DBCC command executes against the actual database. If the database is online, the DBCC command uses table-locking to ensure the consistency of the objects that it is checking. This behavior is the same as if the WITH TABLOCK option were specified.

The master database is particularly interesting with this, as if the internal snapshot can't be created then DBCC CHECKDB will fail against master. As per the above reference:

DBCC CHECKDB fails when it is run against master if an internal database snapshot cannot be created.

So, what can cause the internal snapshot creation to fail? The above reference has a nice list:

An internal database snapshot is not created when a DBCC command is executed:

• Against master, and the instance of SQL Server is running in single-user mode.

• Against a database other than master, but the database has been put in single-user mode by using the ALTER DATABASE statement.

• Against a read-only database.

• Against a database that has been set in emergency mode by using the ALTER DATABASE statement.

• Against tempdb. In this case, a database snapshot cannot be created because of internal restrictions.

• Using the WITH TABLOCK option. In this case, DBCC honors the request by not creating a database snapshot.

The DBCC commands use table locks instead of the internal database snapshots when the command is executed against the following:

• A read-only filegroup

• An FAT file system

• A volume that does not support 'named streams'

• A volume that does not support 'alternate streams'

My recommendation is to look at that information and find which one is applying to your situation. That should answer your question and move towards the resolution.