December 21, 2016 at 7:49 am
I have a SQL 2012 R2 standard runtime edition server non VM using Virtual Drives for all dat and log files on a Cybernetics SAN. One of the databases became corrupt (cause still unknown). The IT company rolled back the virtual drive to a earlier version while the SQL server was up and running. SQL then put several of the database in Recovery Pending Mode. I had them turn off SQL Services, stop the iSCSI services, restore the drive again, bring the virtual drive back on line and then restart SQL Services. Still the same problem. I tried running ALTER DATABASE dbXYZ SET ONLINE and received the error
Msg 5120, Level 16, State 101, Line 1
Unable to open the physical file
Looking at the Security Tab under properties in file explorer shows "The requested security information is either unavailable of can't be displayed". I think SQL is not happy that the data changed without its permission or knowledge and is a little "pissed off". Any advice will be greatly appreciated.
Kevin
December 21, 2016 at 8:30 am
kchaplin (12/21/2016)
I have a SQL 2012 R2 standard runtime edition server non VM using Virtual Drives for all dat and log files on a Cybernetics SAN. One of the databases became corrupt (cause still unknown). The IT company rolled back the virtual drive to a earlier version while the SQL server was up and running. SQL then put several of the database in Recovery Pending Mode. I had them turn off SQL Services, stop the iSCSI services, restore the drive again, bring the virtual drive back on line and then restart SQL Services. Still the same problem. I tried running ALTER DATABASE dbXYZ SET ONLINE and received the errorMsg 5120, Level 16, State 101, Line 1
Unable to open the physical file
Looking at the Security Tab under properties in file explorer shows "The requested security information is either unavailable of can't be displayed". I think SQL is not happy that the data changed without its permission or knowledge and is a little "pissed off". Any advice will be greatly appreciated.
Kevin
I suspect the only way forward would be to shut down that machine and restore it's OS and other data back to a point in time prior to the bad actor doing a bad thing, and then have the SAN drive restored again, and then and only then bring SQL Server back up. Not sure that's going to be either easy or possible. The idea is to have the entire server go back to the state it was in at a point prior to the problem taking place.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
December 21, 2016 at 9:16 am
Thank you for the suggestion.
I do not know what options they have for restoring the OS. One thing I noticed is that the SQL Agent is not running. I think the account it is using to run its services needs to be changed. I read somewhere the SQL Agent may be part of the Recovery Mode Process. I am waiting for another volume restore to finish before I can look a the SQL Agent issue.
December 21, 2016 at 12:42 pm
Problem solved by restoring the virtual volume from an earlier date. Somehow the data on SAN had become corrupt. SQL is now all happy.
Thanks for your help.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply