Failing over a database in Standby mode - will it remain in standby mode?

  • Hi,

    We have implemented custom log shipping between the primary and secondary database. The secondary database in on a SQL Server 2005 cluster with the data/log/undo files all on disk which are configured as a shared resource. The secondary database is in read-only/standby mode so we can apply log files in bulk once a day.

    Will failing the cluster of the server which hosts this secondary database affect the database in any away? We need to ensure that subsequent log files can be applied correctly.

    My gut feeling is that the database will remain in the same state and the LSN won't be affected.

  • aaa-322853 (9/20/2012)


    Hi,

    We have implemented custom log shipping between the primary and secondary database. The secondary database in on a SQL Server 2005 cluster with the data/log/undo files all on disk which are configured as a shared resource. The secondary database is in read-only/standby mode so we can apply log files in bulk once a day.

    What do you mean by custom?

    have you implemented a SQL Server Log Shipping plan or your own version of this technology?

    aaa-322853 (9/20/2012)


    Will failing the cluster of the server which hosts this secondary database affect the database in any away? We need to ensure that subsequent log files can be applied correctly.

    My gut feeling is that the database will remain in the same state and the LSN won't be affected.

    Ordinarily, no.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • This is what I mean by custom:

    We have Redgate SQL backup product installed on both servers.

    There is no direct connection permitted between the primary and secondary servers so we invoke the Redgate extended stored prodcedure once a day to restore the log files from a network share to the secondary database.

  • In other words this log shipping process is not controlled by Redgate SQL Backup!

  • ok, so what checks are in place to validate files that have been or not been restored.

    If you're doing this completely manual then it is very easy to get out of step and miss a log. At this point you'll have issues.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Ok so monitoring is a separate issue here.

    The Redgate procs will attempt to apply the log files in the 'ToBeProcessed' folder and move them to a 'Restored' folder as for example as they are successfully processed. It sorts and attempts to apply to log files automatically. It then skips over older log files and raises a warning (if they have already been applied) before continuing to the next one in order.

    If one file cannot be restored for any reason it will remain in the ToBeProcessed folder.

    Maybe I am missing the point you are making here?

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply