Log-Shipping: Why would you choose No Recovery mode?
Asked Answered
H

1

20

When configuring LogShipping for SQL Server, you can choose for the secondary database to be in No Recovery mode or Standby mode. No Recovery means you have no access to the database while log shipping is going on. Standby gives you read-only access, and if you select the option to disconnect users whenever a restore is about to happen, would appear not to interfere with the log shipping process. This looks to me like an extra benefit of standby mode, but as far as I can see the documention mentions no adverse affects.

I'm therefore wondering why anyone would choose to use No Recovery mode? The only plausible reasons I can think of are if Standby mode caused a significant performance degredation (but there's no mention of anything like that in the docs), or if there is some security requirement to actively prevent anyone seeing the contents of the secondary database (which would seem rare/unlikely).

Can anyone enlighten me what the advantage of choosing No Recovery mode is supposed to be?

Hemp answered 21/1, 2013 at 21:48 Comment(1)
I don't understand why this is considered off-topic. The FAQ linked to includes the criteria '•software tools commonly used by programmers'. Log-Shipping is a part of SQL Server which is very definitely commonly used by programmers, and indeed a search of StackOverflow shows that questions about LogShipping are asked and answered here.Hemp
E
25

When you use NORECOVERY mode, no access will be given to the target database, so the database does not have to care about uncommitted transactions. The log can just be restored "as is" and left in that state.

When you use STANDBY mode, the database restores as NORECOVERY, then analyzes and rolls back all uncommitted transactions in the log. It can then give read only access to users. When the next log is restored, the database disconnects all users and rolls the uncommitted transactions from the last log forward again before restoring.

As you can see, STANDBY has potentially large extra overhead at restore, depending on your transaction volume.

More details at this article at My World of SQL.

Exploiter answered 21/1, 2013 at 21:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.