February 9, 2011 at 6:51 am
Ninja's_RGR'us (2/9/2011)
Well at my rates, 4 days of work would be worth that 1000$ for that single incident.
Depends whether the person is willing to fess up to the manager and whether the manager will approve the expenditure. $1000 may be trivial for a company, but it's a lot for an individual.
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
February 9, 2011 at 6:52 am
kasaranenikiran-725528 (2/9/2011)
Thnanks for all the Info. I did a reload of the table from other source.Regards
Kay
Excellent. I'm glad you were able to recover it.
If this is a development system, can I suggest you get the structure into source control? That will ensure that you can rebuild it as needed. If it's a production system, I strongly suggest you reexamine your backup strategies as I first said. You really don't want to be in a situation where you can't recover the table next time.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 9, 2011 at 7:27 am
Ninja's_RGR'us (2/9/2011)
One more option maybe the op didn't consider.Do you have by any chance a copy of the script you use the create or load the table? In that case you could at the very least do a select into and then adjust the missing constraints / indexes from there.
That would be perfect if the OP and others are using TFS or Visual Source Safe (or another script versioning tool). That's one way to get structure back, even if you can't rescue the data.
EDIT: Opps. I'm too late. Sorry.
February 9, 2011 at 8:45 am
Brandie Tarvin (2/9/2011)
Ninja's_RGR'us (2/9/2011)
One more option maybe the op didn't consider.Do you have by any chance a copy of the script you use the create or load the table? In that case you could at the very least do a select into and then adjust the missing constraints / indexes from there.
That would be perfect if the OP and others are using TFS or Visual Source Safe (or another script versioning tool). That's one way to get structure back, even if you can't rescue the data.
EDIT: Opps. I'm too late. Sorry.
Not late. It's a great piece of advice. Repeating it is not bad. It's one of those pieces of advice that needs repeating.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 10, 2011 at 1:09 am
THanks for the Info... This was DEV envoronment . ANd I have already revised the Backup strategy as Full Backup once a week. I will also look in to putting it in to source control.
thanks
kay
February 10, 2011 at 3:58 am
Ok 🙂
NEVER NEVER EVER GIVE UP;-)
February 10, 2011 at 5:22 am
kasaranenikiran-725528 (2/10/2011)
THanks for the Info... This was DEV envoronment . ANd I have already revised the Backup strategy as Full Backup once a week. I will also look in to putting it in to source control.thanks
kay
Even once weekly is up to 60-70 hours of lost work PER programmer.
I'd also add at least daily diff and also use full instead of simple... you can't always dump the log right after the backup runs, but at least that way you can quickly recover.
February 10, 2011 at 5:36 am
Ninja's_RGR'us (2/10/2011)
kasaranenikiran-725528 (2/10/2011)
THanks for the Info... This was DEV envoronment . ANd I have already revised the Backup strategy as Full Backup once a week. I will also look in to putting it in to source control.thanks
kay
Even once weekly is up to 60-70 hours of lost work PER programmer.
I'd also add at least daily diff and also use full instead of simple... you can't always dump the log right after the backup runs, but at least that way you can quickly recover.
True, but if they have it under source control they should be in good shape. That data in dev is seldom important.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 10, 2011 at 5:55 am
Grant Fritchey (2/10/2011)
Ninja's_RGR'us (2/10/2011)
kasaranenikiran-725528 (2/10/2011)
THanks for the Info... This was DEV envoronment . ANd I have already revised the Backup strategy as Full Backup once a week. I will also look in to putting it in to source control.thanks
kay
Even once weekly is up to 60-70 hours of lost work PER programmer.
I'd also add at least daily diff and also use full instead of simple... you can't always dump the log right after the backup runs, but at least that way you can quickly recover.
True, but if they have it under source control they should be in good shape. That data in dev is seldom important.
I totally agree. Yet since he's only looking into it it means it's not done for now. I'd take the 2 minutes to setup the diffs!
February 10, 2011 at 5:58 am
Ninja's_RGR'us (2/10/2011)
kasaranenikiran-725528 (2/10/2011)
This was DEV envoronment . ANd I have already revised the Backup strategy as Full Backup once a week. I will also look in to putting it in to source control.Even once weekly is up to 60-70 hours of lost work PER programmer.
I'd also add at least daily diff and also use full instead of simple... you can't always dump the log right after the backup runs, but at least that way you can quickly recover.
I have this discussion once every couple of months with another DBA. He's of the opinion that it's just Dev and if the developers aren't saving their code or throwing it up into TFS then it's their problem. But then we just ran into the issue of losing a developer who hadn't done any of that and didn't tell anyone all the things he'd changed in Dev, so when we went up to test, there was missing stuff we had to retrieve from Dev.
I understand both POVs, but there are situations where even backups and TFS combined won't help. You just have to muddle through and do things right as often as you can to minimize the WHOOPS moments.
February 10, 2011 at 6:33 am
Brandie Tarvin (2/10/2011)
Ninja's_RGR'us (2/10/2011)
kasaranenikiran-725528 (2/10/2011)
This was DEV envoronment . ANd I have already revised the Backup strategy as Full Backup once a week. I will also look in to putting it in to source control.Even once weekly is up to 60-70 hours of lost work PER programmer.
I'd also add at least daily diff and also use full instead of simple... you can't always dump the log right after the backup runs, but at least that way you can quickly recover.
I have this discussion once every couple of months with another DBA. He's of the opinion that it's just Dev and if the developers aren't saving their code or throwing it up into TFS then it's their problem. But then we just ran into the issue of losing a developer who hadn't done any of that and didn't tell anyone all the things he'd changed in Dev, so when we went up to test, there was missing stuff we had to retrieve from Dev.
I understand both POVs, but there are situations where even backups and TFS combined won't help. You just have to muddle through and do things right as often as you can to minimize the WHOOPS moments.
No arguments. I've always done both (boots & laces, belts & braces, belts & suspenders, pick your metaphor), but I don't sweat the backups a whole lot as long as I've also got the code under source control.
The one sure way to know that all developers are using source control for database objects? Only deploy from source. If it ain't there, it's no moving. The screams are a quick way to pinpoint the non-compliant.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 11 posts - 16 through 25 (of 25 total)
You must be logged in to reply to this topic. Login to reply