• EN
Question

SQL restart when doing Instant DB recovery

  • 18 September 2023
  • 3 comments
  • 82 views
S
Userlevel 6
Badge +1

SQL restart when doing Instant DB recovery

The Database went offline and in Recovery Pending state. It is currently doing Instant DB Recovery. 

Is it safe to restart SQL to bring the Database online without affect transactions already in the cache folder? Would it affect the Instant DB recovery process (I don’t think so but better to ask). What other processes should we consider before doing a restart of the SQL? 

Thanks.

3 comments

Chris.Childerhose
Userlevel 7
Badge +20

I have never used Instant Recovery for SQL so cannot comment but would think restarting SQL services would be a bad idea regardless.  I would also think a restart would break the instant recovery connection to SQL server as well but again never used this method.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
S
Userlevel 6
Badge +1

This is a new feature in v12 and apparently, Veeam does not have enough information what happens if the DB in Recovery Pending is restarted. I think the FLR running the background would not get affected but not sure what happens to the data in the IR cache or what state will the DB be after the restart. 

 

 

S
Userlevel 6
Badge +1

This feature is actually 2 processes. One is connecting a read-only version of the DB (updates are written to a cache), the 2nd part is the actual file restore of the DB files.

For our case, the read-only version DB went off-line due unable to access Veeam created pointers to the DB files. But the file restore continued. However, when it is time to merge, Veeam threw an error related to the errors that caused the DB to be offline

 

Error    Failed to instant recovery item asdfasdf (Type: Database; Source: server1; Target: server1). Database restore failed: Asynchronous read operation failed.  The request failed due to a fatal device hardware error.  

 

The system failed to flush data to the transaction log. Corruption may occur in VolumeId: C:\VeeamFLR\server1_5c8d2abc\Volume9, DeviceName: \Device\HarddiskVolume450.
(The request failed due to a fatal device hardware error.)

 

We verified that there is no error on vSphere/storage side. 

 

So now all of the new data that got stored in the Instant Recovery Cache are corrupted :-(

 

Wondering how do we salvage the situation. Definitely we can bring the DB online but need to recover most of the data if not all.

Comment


Terms & Conditions