SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Database stuck "in recovery"


Database stuck "in recovery"

Author
Message
GilaMonster
GilaMonster
SSC Guru
SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)

Group: General Forum Members
Points: 87357 Visits: 45272
Cool. So go and take one of those backup exec backups and your log backups and see if you can restore to a point in time.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62588 Visits: 19111
While I haven't used BackupExec 12, I've had experience with 11, 10, a few other versions. I've always had issues doing restores with BackupExec, especially when I had a disaster.

As Gail mentioned, Backup Exec might work, and I hope it does for you, but I would not bet my job on it. I'd make regular full and log backups with SQL Server, or one of the non-agent based systems.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Rich Mechaber
Rich Mechaber
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1553 Visits: 3665
GilaMonster (9/8/2010)
yessen (9/8/2010)
Well my sysadmin uses backup-exec software to save the mdf and ldf files every day, which is not the full backup of the database. If lets say everything crashes, will I be able to recover within 15 minutes of time if I have mdf and ldf daily copy and unbroken chain of log backups?


There's a good chance you won't be able to recover anything with that 'backup' strategy. SQL locks those files while it's running which means they are not accessible. While some backup software can read through file locks, the common result of doing that is backed up database files that will not attach or are corrupt when you go to recover.

Without a full backup (the result of BACKUP DATABASE ... TO DISK), log backups are completely useless (if they'll even run at all)

Stop backing up the mdf and ldf (unless you're using a SAN-based snapshot backup that's integrated with SQL) and put a proper backup plan in place - full and log backups at regular intervals. Let the sysadmin copy those backup files elsewhere for retention and tell him to exclude all the sql database files from the backup tool.


At the risk of sounding a "me too" (but taking that risk if it saves your bacon someday:-)):
I've found the usual commercial network backup software applications (Backup Exec, Yosemite) to be extremely unreliable for backing up SQL databases. As Gail Shaw pointed out -- and hers is some of the most thorough and experienced advice you'll get on this entire website -- SQL Server locks the files and interferes with commercial backup software. I've encountered service errors in the Windows event log, un-backed-up files, and even worse: aborted backup jobs.

All of the commercial packages have some kind of add-on or module that claims to allow you to perform live backups of SQL Server. I've never had any luck with them. I won't bet the integrity and security of my company's digital lifeblood on software I don't understand and cannot make work.

Again, to echo Gail's suggestion: test and restore and test some more. If it works, it works. If not, use SQL to back up your databases to disk, then use BackupExec to back up those SQL backup files to tape.

Rich
Elliswhite
Elliswhite
SSC-Enthusiastic
SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)SSC-Enthusiastic (161 reputation)

Group: General Forum Members
Points: 161 Visits: 54
Here are few steps by which you can drive out your SQL database from recovery mode and perform action on it.
First step is to stop the SQL Services
Then change the location of log files
Start the Server services and makes databases offline
Place the log file in previous location
Now bring the SQL database Online
Within few clock pulse rate you can access SQL database and back to work.

SSMS Expert
GilaMonster
GilaMonster
SSC Guru
SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)

Group: General Forum Members
Points: 87357 Visits: 45272
Elliswhite (5/12/2014)
Here are few steps by which you can drive out your SQL database from recovery mode and perform action on it.
First step is to stop the SQL Services
Then change the location of log files
Start the Server services and makes databases offline
Place the log file in previous location
Now bring the SQL database Online
Within few clock pulse rate you can access SQL database and back to work.


Excellent waste of time, won't do much else.

If you were to follow that recommendation, then when SQL restarts it will mark the databases as recovery pending, because of the missing log. Take it offline, replace the log and bring it back online and SQL will run recovery on the database, from the very beginning. So if you were to do that after the DB had been in recovery for 4 hours, after doing that it will be back at the beginning of recovery, with 4+ hours to go. It definitely won't come online immediately.

Please refrain from posting advice on database recovery if you're not familiar with how SQL behaves.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search