2 Removed obsolete references; incorporated suggest edit in a comment
source | link

Based on your comment:

The backups was failed and the time of failure huge transactions were logged logged which rapidly grows the DB.

If this was a one-time occurrence and your log file (LDF) is grotesquely huge, take a log backup and then shrink the log file (only) to its pre-bloat level just this once. Otherwise, leave it the way it is.

The reason you don't want to shrink your data file is because it fragments your indexes, which can affect performance. TheIn addition, because your indexes get fragmented when you shrink your database. the next time your re-indexing kicks off, your datafile will grow for rebuilds and your log file will grow for reorgs.

The reason you don't want to shrink your log file to a size smaller than its usual working size is because instant file initialization works for data files, but not for log files, so if the log file is going to grow to that size again it'll be a performance hit while it grows.

As squillman points out in his comment, there'sThere's a lot of information on why shrinking is bad. Only do it if you have a good reason.

Based on your comment:

The backups was failed and the time of failure huge transactions were logged which rapidly grows the DB.

If this was a one-time occurrence and your log file (LDF) is grotesquely huge, take a log backup and then shrink the log file (only) to its pre-bloat level just this once. Otherwise, leave it the way it is.

The reason you don't want to shrink your data file is because it fragments your indexes, which can affect performance. The reason you don't want to shrink your log file to a size smaller than its usual working size is because instant file initialization works for data files, but not for log files, so if the log file is going to grow to that size again it'll be a performance hit while it grows.

As squillman points out in his comment, there's a lot of information on why shrinking is bad. Only do it if you have a good reason.

The backups was failed and the time of failure huge transactions were logged which rapidly grows the DB.

If this was a one-time occurrence and your log file (LDF) is grotesquely huge, take a log backup and then shrink the log file (only) to its pre-bloat level just this once. Otherwise, leave it the way it is.

The reason you don't want to shrink your data file is because it fragments your indexes, which can affect performance. In addition, because your indexes get fragmented when you shrink your database. the next time your re-indexing kicks off, your datafile will grow for rebuilds and your log file will grow for reorgs.

The reason you don't want to shrink your log file to a size smaller than its usual working size is because instant file initialization works for data files, but not for log files, so if the log file is going to grow to that size again it'll be a performance hit while it grows.

There's a lot of information on why shrinking is bad. Only do it if you have a good reason.

    Post Migrated Here from serverfault.com
1
source | link

Based on your comment:

The backups was failed and the time of failure huge transactions were logged which rapidly grows the DB.

If this was a one-time occurrence and your log file (LDF) is grotesquely huge, take a log backup and then shrink the log file (only) to its pre-bloat level just this once. Otherwise, leave it the way it is.

The reason you don't want to shrink your data file is because it fragments your indexes, which can affect performance. The reason you don't want to shrink your log file to a size smaller than its usual working size is because instant file initialization works for data files, but not for log files, so if the log file is going to grow to that size again it'll be a performance hit while it grows.

As squillman points out in his comment, there's a lot of information on why shrinking is bad. Only do it if you have a good reason.