SQL Server: How to avoid or detect database restore while application is running

Question

It is required to shut down the system I'm working on before the database gets restored. If a customer does not do this, he may run into serious problems, because the in-memory state of the application server does not match the database. It may take some time until the corrupt database causes errors and the system stops working and the database is unusable.

So I try to detect this situation and avoid the problem.

• The application server does not necessarily keep a connection alive, so single user mode and stuff like this most probably wont help.
• I don't care if the restore would fail or the server would shut down or whatever. It just shouldn't ignore it.
• the database may be restored by any sql server tool on any machine. I can't rely on my own tools.

Did anyone already solve such a problem?

I'm using SQL Server 2005 and above, .NET (C#), SMO.

---

Edit:

Because of some misconceptions and discussions about application design, I need to explain where the problem comes from.

The Hi-Lo generator: The application uses NHibernate, which has a cache of Hi-Values of the Hi-Lo id generator. The Hi-Values are read from the database and allows the application to generate a specific number of primary keys until it requires to go back to the database and get another range of numbers. The Hi-Values stored in the database are only incremented, but never decremented (unless when a older version of the database is restored). This is the concept of the Hi-Lo generator, it is neither invented nor implemented by myself.

Caches: In caches, primary keys are used to identify records in the database. Primary keys do never change in normal use of the database. In case of a restore, the primary keys do not identify the same record anymore and the caches are just plain wrong. It can't even detect this. It might result, for instance, in setting wrong foreign keys in new records.

A DB restore can't be compared to any other normal use of the database. A restore breaks all the rules of data handling.

I guess that many applications keep connections open while they are running, making restore impossible. Most other applications would probably just crash when the database is restored and it tries to access the database afterwards. In my case, it may keep running for awhile, which is a problem.

I guess that most people don't even try to restore the database when the application is running.

There is a theoretical, an in my case proven, risk that something is going completely wrong when a database is restored while the application is still in memory. I don't want to be told that this is not a problem at all, just because most applications do not handle it.

Answer 1

I didn't get a useful answer, so I assume that there is no general solution to this problem.

I only see two ways to solve it:

• Executing a query at the begin of every transaction to see if the database is another one. E.g. the last time when it had been restored as described here. This may hurt performance and may also be a permissions problem
• I open a "keep-alive" connection to the database which avoids that the database is restored. This may be much easier to implement. It is not very nice, because it wastes a connection.

Answer 2

Not knowing how you are connecting to the database you could build into your connection logic a check run in a separate state or system database to validate the status of a database.

Maybe do a try / catch around the connection and on a failure check the status and report it back to the user at that point; not sure how often you are restoring so determining the optimum place in your code would require some thought.

SELECT DATABASEPROPERTYEX ('DatabaseName', 'Status')

http://msdn.microsoft.com/en-us/library/ms186823.aspx

Answer 3

You cannot do a full restore on a database in SQL Server while there are any connections to it.

And SQL Server will never allow itself to corrupt the in-memory state of the SQL Server. And you would have to work pretty d**n hard to even trick it into something like that.