3 replaced http://dba.stackexchange.com/ with https://dba.stackexchange.com/
source | link

Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?

Suggestion: give these posts a good read...

Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?

Suggestion: give these posts a good read...

Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?

Suggestion: give these posts a good read...

2 added 695 characters in body
source | link

Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?

Suggestion: give these posts a good read...

Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?

Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?

Suggestion: give these posts a good read...

1
source | link

Simple recovery model doesn't "turn off the log" - so generally, unless you're going to break any of these activities into very small chunks, just pre-size the log large enough to deal with the largest rebuilds, and don't bother messing with the recovery model.

Also, and again generally, unless your data will never grow again, freeing up the space temporarily is of little benefit (given that I don't know what you mean by "reasonable"). You're going to need to leave free space on the drive, in case the database grows again, right? Why shrink it only to have it grow again? Are you going to provide short-term rental on that space until the database grows? Are you just trying to avoid free space % alerts?