Skip to main content
commvault.com commvault.com
Answer

is there a way to a drop a DB as part of a scheduled restore?

  • April 20, 2022
  • 4 replies
  • 111 views
christopherlecky
Novice
Forum|alt.badge.img+16

is there any way of dropping a DB prior to a scheduled restore?

 

I don’t think there is an option to do this but is there a simple way to capture the list of drops a drop them ahead of the restore starting?

Best answer by Chris Hollis

Apologies @christopherlecky, I didn’t see this reply.


Confirming your query was answered under a support incident. 

Issue Findings:

Support determined that there is something creating a constant logon request for that DB, meaning it is always in use regardless of the paramaters leveraged in our restore process. 

Unfortunately, there is no option built into SQL agent to drop the DB prior to restore. If this is going to be a scheduled operation then to resolve this particular issue, you can look at scripting the restore with a pre-process script. You can wrap a SQLCMD call in a .bat file.

I would be interested in finding out if you managed to try this and if this worked as you hoped?


Thanks,


Chris ​​​​​​​

I blame auto-correct for all misspellings, grammatical errors, and half-baked opinions.

4 replies

Chris Hollis
Vaulter
Forum|alt.badge.img+14

@christopherlecky mind confirming what would be the purpose of doing so? Can’t you just restore with overwrite enabled (and drop connections) to allow it to go thru? 

Is there some failure you’re intermittently getting or just curious?

christopherlecky
christopherlecky
Novice
Forum|alt.badge.img+16

@Chris Hollis Unable to gain exclusive access.
this is with unconditional overwrite and drop connections enabled.

Not completely clear why but dropping the DB in the past has saved time as typically restores are done under duress.

 

in this case its a scheduled restore that is failing.

I blame auto-correct for all misspellings, grammatical errors, and half-baked opinions.
Chris Hollis
Vaulter
Forum|alt.badge.img+14
  • Chris HollisVaulter
  • Vaulter
  • Answer
  • May 16, 2022

Apologies @christopherlecky, I didn’t see this reply.


Confirming your query was answered under a support incident. 

Issue Findings:

Support determined that there is something creating a constant logon request for that DB, meaning it is always in use regardless of the paramaters leveraged in our restore process. 

Unfortunately, there is no option built into SQL agent to drop the DB prior to restore. If this is going to be a scheduled operation then to resolve this particular issue, you can look at scripting the restore with a pre-process script. You can wrap a SQLCMD call in a .bat file.

I would be interested in finding out if you managed to try this and if this worked as you hoped?


Thanks,


Chris ​​​​​​​

christopherlecky
Novice
Forum|alt.badge.img+16

Apologies @christopherlecky, I didn’t see this reply.


Confirming your query was answered under a support incident. 

Issue Findings:

Support determined that there is something creating a constant logon request for that DB, meaning it is always in use regardless of the paramaters leveraged in our restore process. 

Unfortunately, there is no option built into SQL agent to drop the DB prior to restore. If this is going to be a scheduled operation then to resolve this particular issue, you can look at scripting the restore with a pre-process script. You can wrap a SQLCMD call in a .bat file.

I would be interested in finding out if you managed to try this and if this worked as you hoped?


Thanks,


Chris

Hi Chris,

That is exactly the approach I took, but I have seen this issue often enough that I was just wondering if the functionality had been baked into the product. 

 

Thanks for the follow up.

I blame auto-correct for all misspellings, grammatical errors, and half-baked opinions.
Terms & ConditionsCookie settingsAccessibility statement