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

The transaction log does not automatically shrink because you did a backup. This is actually a good thing because processes actually stop when the log grows. Your log has grown to the current size because you had processes that required the log to grow to that size. These could have been long running units of work that generated a lot of log records (like index maintenance). The log 'truncation' you're referring to means that, after a log backup, log space is available for 'reuse'. Again, this process does not automatically reduce the size of the log. To reduce the log size,, you'd need to 'shrink' the log file. Repeated shrinking of the log is discouraged because it typically just re-grows, which affects performance. If you do 'shrink' the log, you should monitor the growth rate. Here is a helpful article. I also found this articlethis article that provides additional information.

The transaction log does not automatically shrink because you did a backup. This is actually a good thing because processes actually stop when the log grows. Your log has grown to the current size because you had processes that required the log to grow to that size. These could have been long running units of work that generated a lot of log records (like index maintenance). The log 'truncation' you're referring to means that, after a log backup, log space is available for 'reuse'. Again, this process does not automatically reduce the size of the log. To reduce the log size,, you'd need to 'shrink' the log file. Repeated shrinking of the log is discouraged because it typically just re-grows, which affects performance. If you do 'shrink' the log, you should monitor the growth rate. Here is a helpful article. I also found this article that provides additional information.

The transaction log does not automatically shrink because you did a backup. This is actually a good thing because processes actually stop when the log grows. Your log has grown to the current size because you had processes that required the log to grow to that size. These could have been long running units of work that generated a lot of log records (like index maintenance). The log 'truncation' you're referring to means that, after a log backup, log space is available for 'reuse'. Again, this process does not automatically reduce the size of the log. To reduce the log size,, you'd need to 'shrink' the log file. Repeated shrinking of the log is discouraged because it typically just re-grows, which affects performance. If you do 'shrink' the log, you should monitor the growth rate. Here is a helpful article. I also found this article that provides additional information.

1
source | link

The transaction log does not automatically shrink because you did a backup. This is actually a good thing because processes actually stop when the log grows. Your log has grown to the current size because you had processes that required the log to grow to that size. These could have been long running units of work that generated a lot of log records (like index maintenance). The log 'truncation' you're referring to means that, after a log backup, log space is available for 'reuse'. Again, this process does not automatically reduce the size of the log. To reduce the log size,, you'd need to 'shrink' the log file. Repeated shrinking of the log is discouraged because it typically just re-grows, which affects performance. If you do 'shrink' the log, you should monitor the growth rate. Here is a helpful article. I also found this article that provides additional information.