locked
How to recover suspect database which is a part of Always ON ? RRS feed

  • Question

  • How to recover suspect database which is a part of Always ON ?
    Saturday, October 14, 2017 8:28 AM

Answers

  • Even I have faced the same situation, 

    My case - disk bytes 0 on both replicas, and the database become suspect on Primary replica and showing not synchronizing on  secondary replica.

    Removed the database from AlwaysOn. After removing the database from AG, the primary replica DB came to online automatically - Ran the t-log back, resolved the disk space issue and re-added the database.

    If your case is different - yes you need to remove the DB from AG. Restore from last good backup and re-add it to AG.

    If no backups available, its ur turn to repair the database with data loss.


    Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue :)

    • Marked as answer by Mayur-DEW Friday, March 2, 2018 11:40 AM
    Saturday, October 14, 2017 5:53 PM
  • How to recover suspect database which is a part of Always ON ?

    By backup and restore if you feel comfortable. Drop the old database if it is not accessible at all and restore from backup and log backups new database and then join it to availability group you would have to reinitialize the secondary replicas.

    If you can afford data loss and this is a test system you may try repair_allow_data_loss but this should be your LAST resort this is very bad for database it may delete data and also affect constraints and keys


    Cheers,

    Shashank

    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    My TechNet Wiki Articles

    MVP

    Saturday, October 14, 2017 2:39 PM

All replies

  • How to recover suspect database which is a part of Always ON ?

    By backup and restore if you feel comfortable. Drop the old database if it is not accessible at all and restore from backup and log backups new database and then join it to availability group you would have to reinitialize the secondary replicas.

    If you can afford data loss and this is a test system you may try repair_allow_data_loss but this should be your LAST resort this is very bad for database it may delete data and also affect constraints and keys


    Cheers,

    Shashank

    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it

    My TechNet Wiki Articles

    MVP

    Saturday, October 14, 2017 2:39 PM
  • Even I have faced the same situation, 

    My case - disk bytes 0 on both replicas, and the database become suspect on Primary replica and showing not synchronizing on  secondary replica.

    Removed the database from AlwaysOn. After removing the database from AG, the primary replica DB came to online automatically - Ran the t-log back, resolved the disk space issue and re-added the database.

    If your case is different - yes you need to remove the DB from AG. Restore from last good backup and re-add it to AG.

    If no backups available, its ur turn to repair the database with data loss.


    Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue :)

    • Marked as answer by Mayur-DEW Friday, March 2, 2018 11:40 AM
    Saturday, October 14, 2017 5:53 PM
  • if you still failed with the method as Shashank suggested, I think you're next port of call should be to contact Microsoft to see if they can help you or you may see some troubleshooting steps here: http://rameshbabu.in/disaster-recovery/how-to-recover-suspect-msdb-database-in-sql-server/
    Monday, October 16, 2017 5:42 AM