• PSS won't be able to do anything different.

    One of the steps of emergency mode repair is to try forcing recovery with the equivalent of WITH CONTINUE_AFTER_ERROR - looks like in this case it's caused the recovery code to hang. This is only the second time I've seen it fail since I wrote it - but it's a last ditch effort when everything's corrupt and there's no backup so I'm not surprised there are some cases where even it can't 'fix' things.

    Your only options at this point are:

    1 EMERGENCY mode and extract into a new database

    2 delete the log file and run repair

    #2 should only be attempted if you're comfortable. It's really ok as the log and database are corrupt anyway, so you're not losing anything by manually throwing away the transaction log. Follow these steps:

    - shutdown

    - make a complete copy of all database files on separate storage (in case you want to go back to your current state)

    - delete the log file from the database

    - start up

    - put the database in emergency mode

    - run repair - this won't try to run recovery this time, but will simply create a new log file and then run a full repair

    Your data will be transactionally inconsistent and you'll have lost some but the database will be usable by SQL Server (not necessarily your application).

    Do all of this at your own risk. The most important thing is to make a copy of all the database files before you start so you can go back to your current state.

    Thanks

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005