Sql-server – SQL Server Internal Inconsistency on GROUP BY

Is there any way at all to restore these files?

No.

The long answer is like this:

• you first will have to fix the MDFs. Attempt to attach it with ATTACH_REBUILD_LOG
• as you encounter errors (like incorrect pageid (expected 1:134; actual 0:0). It occurred during a read of page (1:134)) you have to edit the file and fix it. This, of course, requires you to know in fairly much detail the (undocumented) MDF format. Anatomy of Page is a decent starting point, but it really just skims the surface. I really hope your MDF boot page is correctly 'restored'.
• after you fix all the errors, try to evaluate the consistency of the MDF, if possible with a CHECKDB. Fix any error, some will require again manual repair.
• in theory you can try to attempt to see how much of the recovered LDFs can be repaired and applied. I estimate this task something 10x the complexity of fixing the MDF, due to the complexities of the LDF format and because of the LSN chain requirement. I would abandon the idea of trying to rebuild the 'restored' log, just try to 'rebuild' the restored data.

You can use OrcaMDF to attempt to browse the MDFs 'cold' and see if OrcaMDF complains about structure issues, then attempt to fix them.

It is critical that the 'restore' process kept the MDF file size, and restores 0s for bad sectors. If they simply removed the unrecoverable sectors you stand no chance.

Is the corruption gone?

If DBCC CHECKDB returns no errors the corruption is gone.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'BFEnterprise'.

Is the loss of data a problem?

This is the real question, the only way to tell is to test in your system. Presumably if the corrupted data was not causing issues before the repair deleted it, loss of the data is not going to cause issues either.

Optimally you will want to test in your dedicated test system.