Fooling SQL Server

Question

Fooling SQL Server

Steve Jones - SSC Editor

SSC Guru

Points: 736212
More actions
August 9, 2010 at 8:37 pm

#141373

Comments posted to this topic are about the item Fooling SQL Server

Viewing 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic. Login to reply

majorbloodnock SSCrazy Eights Points: 9389 More actions · Answer 1

I think this is one of those grey areas. I like my editorials to provoke thought, not to advertise. In this case, I think there is enough substance in the editorial for it to work, but I think it's a pretty close run thing. Taking the editorial in isolation, I'm glad I had the chance to read it, but I hope this doesn't signal a subtle shift towards using editorials as an extra bit of advertising real estate in the daily newsletter.

Semper in excretia, suus solum profundum variat

James Stover Hall of Fame Points: 3393 More actions · Answer 2

In the publishing game, they call this an "advertorial". You've done it justice.

James Stover, McDBA

Steph Locke SSCrazy Points: 2963 More actions · Answer 3

It's a bit on the heavy handed side in terms of the endorsement but it is an interesting concept- I was going to take a look to see if it might be beneficial for use during development phases of changes. When I went to click on the link however, the site won't redirect me.

Time to google.

Aaron C. Sentell Ten Centuries Points: 1267 More actions · Answer 4

I thought the same thing that others did when I read this editorial: Why is it that this capability to restore a virtual database from a backup is being treated as a new capability when Idera's SQL Virtual Database product has been out for several months? Other than the fact that Red Gate sponsors this web site (which I very much appreciate), what is it that makes Red Gate's product worthy of highlight over Idera? Is there something I'm missing that makes it that much better?

Aaron

Charles Kincaid SSChampion Points: 13593 More actions · Answer 5

This might be a cool tool to save your bacon on a bad day. I see one danger that has not been pointed out. This could get abused by someone just letting it run like this in production. They might think "Oh look. It's backed up all the time". Uh, no. It's not.

As to advertorializing well... Look at editorial columns in newspapers. They advocate positions and promote ideas (if not products) all the time. So what if people you know happen to spit out something good. How can you keep silent?

Shill this might turn out to be something needed when naught else will do. :rolleyes:

ATBCharles Kincaid

Steve Jones - SSC Editor SSC Guru Points: 736212 More actions · Answer 6

Apologies to anyone that feels I crossed the line into too much advertising. I was asked to write something on this product, and I think I failed to editorialize on it properly.

I did think this particular feature was cool, and it is different. Idera's product is very cool as well, but it gives you a read only look. This one actually allows write back, so you could in fact, "mount" a database and test, or run your application against it and see where something failed. It's unique (for now), and I think a fairly innovative integration into SQL Server.

Aaron C. Sentell Ten Centuries Points: 1267 More actions · Answer 7

So that's the difference between the two products. Thanks for clarifying. That is a significant difference and one worth taking into consideration when making a purchase.

majorbloodnock SSCrazy Eights Points: 9389 More actions · Answer 8

Reading the other replies, I think you're safe, Steve. Far better, though, that we let you know early (and when you haven't crossed the line) than after the fact.

Semper in excretia, suus solum profundum variat

jeff.mason SSCrazy Eights Points: 9585 More actions · Answer 9

Speaking not about the product but the idea behind the editorial, I can't tell you how painful the size issue is. It causes reindex havoc for me because in my last job I HAD to restore the DB on a weekly basis to an environment that didn't have enough disk space for the expanded DB (but did for the data) so I had to shrink the files after a reindex, even though I knew it could make more problems for the fragmentation. I had no choice as the dang thing wouldn't restore otherwise. Something like what the editorial is about is critical to support developement environments IMO.

SQLRNNR SSC Guru Points: 281334 More actions · Answer 10

Steve Jones - Editor (8/10/2010)
Apologies to anyone that feels I crossed the line into too much advertising. I was asked to write something on this product, and I think I failed to editorialize on it properly.
I did think this particular feature was cool, and it is different. Idera's product is very cool as well, but it gives you a read only look. This one actually allows write back, so you could in fact, "mount" a database and test, or run your application against it and see where something failed. It's unique (for now), and I think a fairly innovative integration into SQL Server.

This seems like a cool feature.

My concern, are you writing back to the BAK file? I would be very leery about being able to change data in the backup file. I am curious to know how the whole thing works.

Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events

steve block SSCertifiable Points: 7698 More actions · Answer 11

jeff,

I found that if you back up the transaction log after each Index Rebuild you don't have the log growing very much at all.

Steve

Steve Jones - SSC Editor SSC Guru Points: 736212 More actions · Answer 12

The backup file isn't changed. What happens when you do the restore is that the mdf/ldf/ndf are created as sparse files. All reads from these files are redirected to the backup file, while the writes go to the sparse files. So the backup file is intact, but your changes are recorded, similar to a database snapshot.

jeff.mason SSCrazy Eights Points: 9585 More actions · Answer 13

If only it were just a growing log file. We have separate files for very large tables on separate LUNs and spindles, and I found that those files double in size on a reindex. Data files, not log files. The distribution works great in live, but then there's tons of empty space that the restore has to consume on a restore and that space isn't there in dev.

Charles Kincaid SSChampion Points: 13593 More actions · Answer 14

Steve Jones - Editor (8/11/2010)
The backup file isn't changed. What happens when you do the restore is that the mdf/ldf/ndf are created as sparse files. All reads from these files are redirected to the backup file, while the writes go to the sparse files. So the backup file is intact, but your changes are recorded, similar to a database snapshot.

Thanks for the clarification. I take it that in order to remove the restored database you DROP DATABASE just like anything else.

So your backup checkup of doing the fast restore and DBCC does not go far enough, IMHO. One should go a step farther and use SQL Compare to match the objects and the contents. Then you can say that your backups work.

ATBCharles Kincaid