Would you like to be able to do minimally logged deletes?

I think its not such a good idea as although you say "This is not being advocated for production machines",  it will happen and people will get stung.

I think this would be an awesome thing expecially if you could use the delete with a where cluase to only delete stuff say older than 3 months for testing purposes, yet not take an enternity to return since it all being logged.

I'd love that, especially if it were implemented along the lines of the existing Bulk operations (bulk logged mode + bulk delete = minimal logging)

What is the drawback of incomplete Logging?

Unable to rollback on aborted deletes? Or is there also a more basic consitency problem involved?

Bernd

[quote]

This is being advocated for testing.

[/quote]

Such a guideline is absolute rubbish !

Remember what happened to updatable catalogs.... most of the problems occured in prod !

More and more, db management is being done by "the general public".

With the current dumb and dumber copy/paste - execute attitude, if something is possible, they will do it, no matter what the cost or impact will be.

I can see the need for the minimally logged deletes, but how do you manage that with point in time restores ?

Most of the PIT restores I need to perform, actually are restores of the dev db itself, where the testing teams did discover a "strange" behavior in the apps and needed to repro the situation to help fixing the software.

As long as the data is consistent, DRI is maintained, ... I guess it should be OK, but that would actually need a RID to be mentioned somewhere for the time of the operation itself.

It should be a fully supported feature and maybe be implemented as a "sp_configure" feature. Off by default.

PingBack from http://www.pythian.com/news/3404/log-buffer-154-a-carnival-of-the-vanities-for-dbas

As you mentioned we already have minimally logged table truncation (TRUNCATE TABLE statement).  Taking some limitations into consideration I don't see why we shouldn't be able to get similar minimally logged functionality out of DELETE statements in some circumstances, and personally I don't see how it would cause problems if we did have that functionality.

Of course there may be those who don't believe it's impossible and of course those who feel they need to be saved from themselves...

Maybe a good place to start is eliminating the confusion about TRUNCATE being a "non-logged operation". That little phrase popped into quite a few resources over the years. At some point I believed it -- up until very recently when someone challenged that assertion.

Mea culpa.