Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456

Database stuck "in recovery" Expand / Collapse
Author
Message
Posted Wednesday, September 8, 2010 2:56 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:54 AM
Points: 42,813, Visits: 35,932
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 2008, MVP
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

Post #982674
Posted Wednesday, September 8, 2010 3:55 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 6:37 PM
Points: 33,189, Visits: 15,329
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
Post #982708
Posted Thursday, September 9, 2010 6:26 AM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Thursday, July 17, 2014 2:01 PM
Points: 687, Visits: 3,002
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
Post #983032
Posted Monday, May 12, 2014 12:40 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, July 24, 2014 10:47 PM
Points: 22, Visits: 37
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
Post #1569693
Posted Monday, May 12, 2014 4:33 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:54 AM
Points: 42,813, Visits: 35,932
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 2008, MVP
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

Post #1569752
« Prev Topic | Next Topic »

Add to briefcase «««23456

Permissions Expand / Collapse