Recover SQL Server database from SUSPECT mode

Question

Hi Expert DBAs,
As I know the database should be restored from backup and logs reapplied. That’s the first and generally recommended approach any time a DB is suspect, whether it’s from log or data file corruption.
But if I have no backups then we follow below steps ( after Googling I found these steps on most of the websites ):
1.EXEC sp_resetstatus ‘yourDBname’;
2.ALTER DATABASE yourDBname SET EMERGENCY
3.DBCC checkdb(’yourDBname’)
4.ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
5.DBCC CheckDB (’yourDBname’, REPAIR_ALLOW_DATA_LOSS)
6.ALTER DATABASE yourDBname SET MULTI_USER
Now my question is, 
1. If after executing DBCC CHECKDB at 3rd step, it shows inconsistency.Then I will execute SET SINGLE USER WITH ROLLBACK & if after executing DBCC CHECKDB at 3rd step, no errors found. Then what will be the steps?
2. When we execute DBCC CHECKDB (' DBNAME ', REPAIR_ALLOW_DATA_LOSS) how can we recover lost data during process.As far as I know some data will loss and if it will happen then business will get suffered.
3. Why run DBCC CHECKDB() WITH REPAIR_ALLOW_DATA_LOSS if there are no consistency errors in the database?
I am stucked in these questions....
Regards,
Yashwant Vishwakarma | SQLOcean.com
Yashwant Vishwakarma | www.sqlocean.com

Answer 1

There is no easy or same steps, it all depends on what error and what caused suspect. 
Example is below:
http://www.sql-server-performance.com/2015/recovery-sql-server-suspect-mode/
2) Straight answer would be no you cant recover if no backup. Again it all depends what error checkdb returns and some things can be tried as explained earlier but no guarantee.
The REPAIR_ALLOW_DATA_LOSS option is not the best option for bringing a database to a physically consistent state. If successful, the REPAIR_ALLOW_DATA_LOSS option may result in some data loss. In fact, it may result in more data lost than if a user were to
restore the database from the last known good backup. Microsoft always recommends a user restore from the last known good backup as the primary method to recover from errors reported by DBCC CHECKDB. The REPAIR_ALLOW_DATA_LOSS option is not an alternative
for restoring from a known good backup. It is an emergency “last resort” option recommended for use only if restoring from a backup is not possible.
Certain errors, that can only be repaired using the REPAIR_ALLOW_DATA_LOSS option, may involve deallocating a row, page, or series of pages to clear the errors. Any deallocated data is no longer accessible or recoverable for the user, and the exact contents
of the deallocated data cannot be determined. Therefore, referential integrity may not be accurate after any rows or pages are deallocated because foreign key constraints are not checked or maintained as part of this repair operation. The user must inspect
the referential integrity of their database (using DBCC CHECKCONSTRAINTS) after using the REPAIR_ALLOW_DATA_LOSS option.
https://msdn.microsoft.com/en-us/library/ms176064.aspx