We have 2 databases. Database 1 is used by our intranet webpage and ourWeb Development team use Entity Shell for their intranet programming method on this website to the database.
I can see that in database 1 the Web Dev Team has created some views that query database 1 but they also join to some tables in database 2 using Entity Shell.
The DBA’s must restore nightly at 12:30 AM a new copy of database 2 (to support another business need) and this is where the trouble begins. We DBA’s kill all sessions in database 2 by putting it into single user mode “ALTER DATABASE [database2] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;” and then we run the restore command. We are able to get the database 2 into single user mode successfully but the restore sometimes fails and we get “Msg 1205, Sev 13, State 68, Line 38 : Transaction (Process ID 87) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.”
We “think” that the cause of the restore step failure is that a query from the intranet page has begun that uses one of those views that joins database 1 and database 2 which we are trying to restore over. Even though we have database 2 in Single mode, we think a session from the view in database 1 prevents the restore from happening in database 2, and the job is chosen as the deadlock victim. This restore is so critical that the On-Call DBA must login and manually try to get the restore to work. We have tried all kinds of things but it seems that we are not able to prevent these views from database 1 from interfering in the restore. We do not see an actual session id into database 2 just a session in database 1 that appears to be using one of those views.
What do we need to do consistently restore this database in this condition? We do not feel that we can kill all users sessions in database 1 also to get this done.
The DBA’s must restore nightly at 12:30 AM a new copy of database 2 (to support another business need) and this is where the trouble begins. We DBA’s kill all sessions in database 2 by putting it into single user mode “ALTER DATABASE [database2] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;” and then we run the restore command. We are able to get the database 2 into single user mode successfully but the restore sometimes fails and we get “Msg 1205, Sev 13, State 68, Line 38 : Transaction (Process ID 87) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.”
We “think” that the cause of the restore step failure is that a query from the intranet page has begun that uses one of those views that joins database 1 and database 2 which we are trying to restore over. Even though we have database 2 in Single mode, we think a session from the view in database 1 prevents the restore from happening in database 2, and the job is chosen as the deadlock victim. This restore is so critical that the On-Call DBA must login and manually try to get the restore to work. We have tried all kinds of things but it seems that we are not able to prevent these views from database 1 from interfering in the restore. We do not see an actual session id into database 2 just a session in database 1 that appears to be using one of those views.
What do we need to do consistently restore this database in this condition? We do not feel that we can kill all users sessions in database 1 also to get this done.